n8n Merge와 Loop Over Items: 데이터를 합치고 쪼개는 방법

여러 소스에서 들어온 데이터를 하나로 합치는 일과, 크기가 너무 큰 데이터를 처리 가능한 단위로 쪼개는 일은 방향이 정반대처럼 보인다. n8n에서는 이 둘이 각각 Merge 노드와 Loop Over Items 노드로 나뉘어 있지만, 결국 같은 문제 — 데이터의 크기와 구조를 워크플로우가 감당할 수 있는 형태로 맞추는 문제 — 를 반대쪽에서 접근한다는 점은 같다.

Merge 노드가 데이터를 합치는 방식

가장 단순한 병합은 Append다. 여러 데이터 소스의 항목을 그냥 순서대로 이어붙여 하나의 데이터셋으로 만든다.

Combine 방식은 좀 더 정교하다. Merge by Fields는 지정한 필드 값이 일치하는 데이터끼리 병합하고, Merge by Position은 순서를 기준으로 병합하며, Combine all possible combinations는 가능한 모든 조합을 만들어낸다. 어떤 방식을 쓸지는 두 데이터셋 사이에 공통 키가 있는지, 아니면 단순히 순서만 맞으면 되는지에 달려 있다.

Choose Branch는 병합이라기보다는 선택에 가깝다. 조건에 따라 여러 브랜치 중 하나의 데이터만 골라서 다음 단계로 넘긴다.

동기화는 방향이 전부다

시스템 두 개를 맞춰야 할 때는 단방향(One-way Sync)과 양방향(Two-way Sync) 중 하나를 고른다. 단방향은 한쪽 시스템을 단일 정보원(Single Source of Truth)으로 두고 그 변경사항만 다른 쪽에 반영하는 구조라 데이터 일관성을 지키기 쉽고 관리도 단순하다. 양방향은 어느 쪽에서 바뀌든 상대방에 자동으로 반영되어 실시간 일관성을 유지할 수 있지만, 그만큼 충돌 처리를 포함한 설계가 복잡해진다.

⤢✕

쪼개서 처리해야 하는 이유

n8n의 노드는 기본적으로 아이템 하나하나에 대해 자동으로 실행되기 때문에 별도의 루프를 짜지 않아도 반복 처리가 된다. 문제는 RSS Read 노드처럼 첫 번째 항목만 처리하는 예외적인 노드들이다. 이런 경우에는 Loop Over Items 노드로 명시적인 반복 처리를 붙여야 나머지 항목도 빠짐없이 돈다.

배치 크기는 아무렇게나 정할 수 없다. API 속도 제한에 걸리지 않는 선, 메모리 사용량, 처리 시간을 함께 고려해서 정해야 워크플로우가 안정적으로 돈다.

실무에서 만나는 조합

서로 다른 CRM 플랫폼 사이의 고객 데이터를 실시간으로 맞추는 작업은 Merge 노드로 중복을 제거하고 데이터 품질을 끌어올리는 전형적인 사례다. 여러 RSS 피드에서 콘텐츠를 모아 통합 대시보드를 구성할 때는 배치 처리로 부하를 분산시켜야 안정적으로 수집된다. 기존 시스템에서 신규 시스템으로 대량의 데이터를 옮기는 마이그레이션도 배치 단위로 나누면 시스템 중단 없이 진행할 수 있고, 여러 외부 API를 하나의 인터페이스로 통합하는 플랫폼에서는 호출 제한을 고려한 배치 처리가 서비스 안정성을 좌우한다.

이 두 축 — Merge로 합치고 Loop Over Items로 쪼개는 것 — 을 조합할 줄 알면 데이터 소스가 몇 개든, 크기가 얼마나 크든 워크플로우 하나로 감당할 수 있는 범위가 크게 늘어난다.