n8n으로 자동화 파이프라인을 처음 짤 때 가장 많이 걸리는 지점이 있다. 루프가 한 번만 돌고 끝난다거나, 에러가 나도 워크플로우가 멈추지 않는다거나. 대부분 노드 사이 데이터 흐름 구조를 파악하지 않은 채 시작해서 생기는 문제다. n8n은 자바스크립트로 세밀하게 제어할 수 있고, 직접 서버에 올리면 운영 비용도 낮출 수 있다.

배열로 흐른다는 걸 먼저 알아야 한다

노드 사이를 흐르는 데이터는 배열 형태다. 목록으로 쏟아지는 결과를 하나씩 처리하려면 Split In Batches로 분리해야 한다. 흩어진 데이터를 다시 합칠 때는 Merge 노드를 쓴다. 이 흐름을 놓치면 반복 작업이 단발성 실행에 그친다.

표현식 매핑은 조건문과 텍스트 가공을 즉석에서 처리할 수 있다. 정규식이 복잡하게 얽히기 시작하면 Code Node로 전환하는 게 낫다. 긴 수식보다 명시적으로 작성한 스크립트가 나중에 훨씬 읽기 편하다.

키를 워크플로우 안에 박으면 안 된다

인증 키를 워크플로우 내부에 직접 넣는 방식은 위험하다. Credentials 메뉴에서 별도로 관리하고, 환경 변수로 개발과 운영 서버 주소를 분리해야 한다. 유통업 API를 붙이다가 테스트 데이터가 운영 환경에 섞인 적이 있다. 그때 이 분리가 얼마나 중요한지 체감했다.

트리거 선택도 명확해야 한다. 외부 신호에 반응할 때는 Webhook, 주기 실행에는 Schedule 노드를 쓴다. 폴링 방식으로 데이터를 가져올 때는 마지막으로 처리한 지점을 반드시 저장해서 중복을 막아야 한다. 에러 전용 워크플로우를 별도로 만들고 메신저 알림까지 연결해두면 장애 대응 속도가 달라진다.

Docker로 올릴 때 볼륨 빠뜨리면 생기는 일

재시작 시 워크플로우가 사라지는 상황은 볼륨 마운트가 빠져서 생기는 경우가 많다. 무거운 파일을 다룰 때는 메모리 할당량도 미리 점검해야 프로세스가 죽는 걸 막을 수 있다.

이미지나 PDF를 다룰 때는 Binary Data 모듈을 쓴다. 파일 이름이 깨지거나 형식을 못 읽는 문제는 MIME 타입 헤더를 명시하면 대부분 해결된다. 금융 업종 프로젝트에서 영수증 파이프라인을 구축하다 이 지점에서 시간을 꽤 썼다. 자주 쓰이는 패턴은 Sub-workflow로 묶어 재사용한다.

핵심만 뽑으면

  • 노드 사이 데이터가 배열로 흐르니까 Split In Batches 없이는 루프가 한 번만 돌고 끝난다
  • 표현식이 복잡해지면 Code Node로 옮기는 게 나중에 훨씬 손보기 쉽다
  • Credentials 분리와 Error Workflow를 갖춰야 운영 단계에서 사고가 안 난다

관련 글

소스