사내 n8n을 외부에서 호출하기 (Webhook 분리 + AWS API Gateway 아키텍처)

n8n을 사내에 구축해 운영하다 보면 거의 반드시 마주치는 요구가 있다. "외부 SaaS / 파트너 시스템에서 n8n 워크플로를 직접 호출하고 싶다". 이 글은 내부 인프라는 그대로 보호한 채 Public 호출을 안전하게 받기 위해, n8n 내부 구조 분리 + AWS API Gateway 도입을 어떻게 조합했는지를 정리한 기록이다.

---

1. 배경과 목적

n8n은 사내 인프라에 구축되어 있으며, 내부 네트워크에 위치한 Private ALB를 통해서만 접근 가능하도록 구성되어 있었다. 그러나 외부 시스템(SaaS, 파트너 시스템, 외부 이벤트 소스 등)에서 n8n 워크플로를 직접 호출해야 하는 요구가 지속적으로 발생했다.

이를 해결하기 위해 다음 두 가지 구조적 개선을 진행했다.

1. n8n 내부 구조 개선
   • Main / Worker 프로세스 분리
   • Webhook 수신 역할을 Main 인스턴스에서 독립적으로 분리
2. 외부 접근 경로 개선
   • AWS API Gateway를 활용해 Public Domain 발행
   • Public → Private 네트워크로 안전하게 요청을 전달

이 글은 위 두 개선 사항의 설계 이유와 동작 방식을 설명한다.

---

2. n8n 내부 아키텍처 분리

2.1 Main / Worker 분리 이유

기존 단일 프로세스 구조에서는 다음과 같은 문제가 있었다.

• Webhook 수신과 실제 워크플로 실행이 동일 프로세스에서 수행됨
• 실행 부하 증가 시 Webhook 응답 지연 가능성 존재
• 수평 확장 시 역할 구분이 불명확

이를 해결하기 위해 n8n을 다음 역할로 분리했다.

구성 요소	역할
Main 인스턴스	Webhook 수신, 실행 요청 큐잉
Worker 인스턴스	큐에 적재된 워크플로 실행 처리

Main 인스턴스는 빠른 요청 처리와 안정적인 수신에 집중하고, Worker 인스턴스는 비즈니스 로직 실행에만 집중하도록 설계했다.

2.2 Webhook 프로세스 분리

Main 인스턴스 내부에서도 Webhook 처리를 별도 포트/프로세스로 분리하여 다음을 보장한다.

• 외부 요청은 Webhook 전용 엔드포인트에서만 수신
• Webhook 수신 시 즉시 응답 가능
• 실행은 Queue를 통해 Worker로 위임

이를 통해 Webhook 수신이 워크플로 실행 상태에 영향을 받지 않도록 했다.

---

3. Public Call을 위한 API Gateway 도입

3.1 기존 구조의 한계

• n8n은 사내 VPC 내부에 위치
• Private ALB를 통해서만 접근 가능
• 외부 시스템에서 직접 호출 불가
• 보안상 Private ALB를 Public으로 전환하는 것은 부적절

따라서 외부 접근은 허용하되, 내부 인프라는 그대로 보호하는 구조가 필요했다.

3.2 API Gateway를 선택한 이유

AWS API Gateway는 다음 요구사항을 충족한다.

• Public Domain 발급 가능
• HTTPS 기본 지원
• 인증, Rate Limit, 로깅 등 정책 적용 용이
• VPC Link를 통해 Private ALB와 안전하게 연결 가능

즉, 외부와 내부를 분리하는 경계 계층(boundary layer) 으로 적합했다.

---

4. 최종 아키텍처

4.1 전체 흐름

                  External System
                         │
                       HTTPS
                         ▼
              ┌──────────────────────┐
              │     API Gateway      │  ← Public Domain
              │  (인증/Rate Limit/    │
              │       로깅)           │
              └──────────┬───────────┘
                         │
                      VPC Link
                         ▼
              ┌──────────────────────┐
              │     Private ALB      │  ← VPC 내부
              └──────────┬───────────┘
                         │
                         ▼
              ┌──────────────────────┐
              │  n8n Webhook         │
              │  (Main Instance,     │
              │   별도 프로세스)       │
              └──────────┬───────────┘
                         │ enqueue
                         ▼
              ┌──────────────────────┐
              │  Execution Queue     │
              │      (Redis)         │
              └──────────┬───────────┘
                         │ dequeue
                         ▼
              ┌──────────────────────┐
              │     n8n Worker       │  (N개 확장 가능)
              └──────────────────────┘

4.2 동작 흐름 상세

1. 외부 시스템이 API Gateway의 Public Domain으로 요청을 보낸다.
2. API Gateway는 VPC Link를 통해 Private ALB로 요청을 전달한다.
3. Private ALB는 요청을 n8n Main 인스턴스의 Webhook 프로세스로 라우팅한다.
4. Webhook 프로세스는 요청을 수신하고 즉시 응답한다.
5. 해당 실행 요청은 Queue에 적재된다.
6. Worker 인스턴스가 Queue에서 Job을 가져와 워크플로를 실행한다.

이 구조에서 외부 시스템은 n8n 내부 구조를 전혀 알 필요가 없다. API Gateway의 Public 엔드포인트만 알면 되고, 그 뒤에 n8n이 있는지 Lambda가 있는지 아예 신경 쓸 필요가 없는 구조다.

---

5. 설계 효과

5.1 안정성

• Webhook 수신과 실행 분리로 응답 지연 최소화
• Worker 장애 시에도 Webhook 수신은 가능 (이후 Worker 복구 시 큐 잔여분 처리)
• 실행은 재시도 및 큐 기반으로 안정성 확보

5.2 확장성

• Worker 인스턴스 수평 확장 가능
• Webhook 트래픽 증가와 실행 부하 증가를 독립적으로 대응 가능

5.3 보안

• n8n은 여전히 Private Network에 유지
• Public 노출 지점은 API Gateway로 한정 — 공격 표면 최소화
• 인증, Rate Limit, IP 제어 등 정책을 API Gateway 레벨에서 일괄 적용 가능

---

6. 정리

이번 구조 개선의 목표는 다음 세 가지였다.

• n8n 내부 역할을 명확히 분리하여 안정성과 확장성 확보
• 사내 Private 환경을 유지하면서 외부 시스템과의 연동 가능
• Public 접근 지점을 API Gateway로 단일화하여 보안과 운영 편의성 확보

결과적으로,

"n8n은 내부 시스템으로 유지하면서, 외부에서는 Public API처럼 안전하게 호출할 수 있는 구조"

를 완성했다.

n8n을 운영하면서 외부 트리거가 필요해지는 순간은 거의 필연적이다. 그때 Private ALB를 Public으로 바꾸는 손쉬운 길을 택하는 대신, 내부 보호와 외부 노출을 분리할 경계 계층을 두는 편이 길게 보면 훨씬 안전하다는 것을 다시 한 번 확인할 수 있었다.