brief.ing.gg

BRIEFING

n8n을 주기적으로 호출하는 API처럼 써도 되는가

n8n을 주기적으로 호출하는 API처럼 써도 되는가

Scope

핵심 질문

n8n webhook workflow를 10초 단위 등 빈번한 API endpoint처럼 호출하는 것은 어떤 조건에서 괜찮고 언제 전용 서버가 필요한가?

Research

핵심 근거

  • n8n webhook은 HTTP trigger로 workflow 실행을 시작할 수 있다.
  • 각 요청이 workflow execution으로 관리되므로 실행기록과 DB write, node scheduling overhead가 일반 경량 HTTP handler보다 크다.
  • 낮은 QPS와 automation endpoint에는 적합하지만 고빈도 low-latency serving은 본래 최적화 목표가 아니다.

참고 자료

  • https://docs.n8n.io/

Draft

기술적으로는 가능하지만 호출 특성을 먼저 봐야 한다.

괜찮은 경우

10초마다 한 번처럼 전체 QPS가 매우 낮고 외부에서 접근할 수 없도록 네트워크를 제한한 내부용 workflow라면 n8n webhook이 실용적일 수 있다. 내부 호출자도 요청마다 식별·인증하고, 외부에 노출한다면 부작용을 일으키기 전에 인증과 권한을 확인한다. 입력 크기·호출 빈도·실행 권한을 제한하고 실패를 관찰해야 하며, 낮은 QPS만으로 접근 통제가 대체되지는 않는다.

비효율적인 경우

단순한 메모리 조회나 JSON 변환을 초당 수십, 수백 번 처리해야 한다면 workflow execution 생성, database 기록, node scheduling은 불필요한 overhead다. Latency tail도 일반 HTTP server보다 예측하기 어렵다.

저장정책

주기 호출이 많으면 execution history가 빠르게 증가할 수 있으므로 성공 실행 저장정책과 retention도 확인해야 한다.

결론

n8n webhook은 low-volume automation API로는 충분히 사용할 수 있다. 서비스의 핵심 serving path가 되거나 latency와 처리량 SLO가 생기면 전용 API로 분리하는 것이 낫다.