n8n 고급 실전: Webhook 트리거와 IF/Switch 조건 분기 설계

주황색 “Test Workflow” 버튼을 벌써 열일곱 번째 눌렀습니다.

매번 수동으로 한 번 눌러야 트리거됩니다. 이걸 제대로 된 API처럼 다른 곳에서 한 번 호출하면 자동으로 실행되게 할 수는 없을까요? 나중에야 n8n에 Webhook이라는 것이 있다는 걸 알았습니다. 쉽게 말해 초인종과 같습니다. 누군가 버튼을 누르면 워크플로가 울리며 시작됩니다.

이 글에서는 이 초인종을 설치하는 방법과, 설치한 뒤 방문자에 따라 서로 다른 방으로 안내하는 방법을 이야기합니다. n8n의 기본 노드는 사용할 줄 알지만 워크플로가 늘 “수동적으로 기다리는” 것 같았다면, 이 글이 새로운 접근법을 찾는 데 도움이 될 것입니다.

살펴볼 내용은 다음과 같습니다.

• 복잡해 보이는 Webhook 노드 매개변수를 설정하는 방법
• IF와 Switch, 두 노드 중 언제 무엇을 써야 하는지
• 그대로 가져다 쓸 수 있는 완전한 주문 처리 사례
• 프로덕션 환경에서 피해야 할 함정

1. Webhook 노드 심층 설정

먼저 짚고 넘어갈 것이 있습니다. Webhook과 정기 트리거는 완전히 다릅니다.

정기 트리거는 알람 시계처럼 밖에서 무슨 일이 있든 일정한 간격으로 울립니다. Webhook은 초인종이라서 누군가 눌러야 울립니다. 이것이 바로 이벤트 기반 방식입니다. 초인종을 사용하면 택배가 왔는지 5분마다 문 앞에 나가 볼 필요가 없습니다. 택배 기사가 도착해 초인종을 누르면 바로 알 수 있습니다. 공식 데이터에 따르면 Webhook은 폴링 오버헤드를 90~95% 줄일 수 있습니다. 즉, 리소스와 시간을 모두 아낄 수 있습니다.

1.1 어떤 HTTP 메서드를 선택할까

Webhook 노드를 열면 가장 먼저 입력해야 하는 항목이 HTTP Method입니다. n8n은 표준 DELETE, GET, HEAD, PATCH, POST, PUT을 지원합니다.

무엇을 선택할지는 하려는 작업에 따라 달라집니다.

• POST: 폼 제출이나 새 주문 알림처럼 데이터를 수신할 때 사용합니다. 가장 흔한 용도입니다.
• GET: 단축 링크를 생성하고 사용자가 링크를 클릭하면 워크플로를 실행하는 등의 간단한 트리거에 사용합니다.
• PUT/PATCH: 주문 상태 변경처럼 데이터를 업데이트할 때 사용합니다.

저는 대부분 body 데이터를 함께 받을 수 있는 POST를 사용합니다.

1.2 네 가지 응답 모드

“Response Mode”라는 이 매개변수는 n8n이 호출자에게 어떻게 응답할지를 결정합니다.

주의할 함정이 있습니다. “Immediately”를 선택하면 호출자는 200을 받고 연결을 끝내지만, 이후 노드에서 오류가 나도 알 수 없습니다. 따라서 백그라운드 작업에는 오류 알림 체계를 함께 설정하는 것이 좋습니다.

1.3 RESTful 라우트 매개변수 활용

Path 매개변수에는 orders/:orderId처럼 동적 라우트를 작성할 수 있습니다. 콜론 뒤의 이름이 변수명이 되며 URL 속 값을 자동으로 추출합니다.

KiloClaw - 기업용 매니지드 OpenClaw, AI Agent 오케스트레이션 및 스마트 라우팅

시작하기 →광고

예를 들어 /orders/12345를 호출하면 워크플로에서 {{ $params.orderId }}로 12345를 가져올 수 있습니다. 매번 query string에 매개변수를 넣는 것보다 훨씬 깔끔합니다.

1.4 Payload 크기 제한

Webhook의 최대 payload는 16MB입니다. 이를 넘으면 오류가 발생합니다.

큰 파일을 꼭 전송해야 한다면 두 가지 방법이 있습니다.

1. 환경 변수 N8N_PAYLOAD_SIZE_MAX 수정
2. 파일을 객체 스토리지에 업로드하고 Webhook에는 URL만 전달

솔직히 대부분의 상황에서는 16MB면 충분합니다. 정말 큰 파일을 보내야 한다면 두 번째 방법이 더 안정적입니다.

2. IF vs Switch: 조건 분기 노드 선택법

두 노드는 모두 데이터를 분기하므로 기능이 비슷해 보입니다. 하지만 잘못 선택하면 꽤 고생합니다. IF를 여러 겹 중첩해 스파게티 코드가 되거나, 사실 분기 두 개면 충분한데 Switch 설정에 시간을 허비할 수 있습니다.

2.1 IF 노드: 둘 중 하나

IF 노드에는 true와 false, 두 개의 출력만 있습니다.

문 앞에서 택배 기사에게 “신선식품인가요?”라고 물어보는 것과 같습니다. 맞으면 냉장고에 넣고, 아니면 문 앞에 둡니다. 단순하고 명확합니다.

IF는 String, Number, Date & Time, Boolean, Array, Object 등 다양한 조건 유형을 지원합니다. 예를 들면 다음과 같습니다.

• String: contains, starts with, ends with, matches regex
• Number: is greater than, is less than
• Boolean: is true, is false
• Array: contains, length greater than

2.2 Switch 노드: 여러 선택지

Switch 노드에는 여러 출력이 있을 수 있습니다. “어느 부서 소속인가요?”라고 묻고 재무팀은 이쪽, 기술팀은 저쪽, 운영팀은 또 다른 쪽으로 안내하는 상황에 적합합니다.

Switch에는 두 가지 모드가 있습니다.

• Rules: 양식을 채우듯 조건 하나에 출력 하나를 연결합니다. 직관적이어서 초보자에게 적합합니다.
• Expression: JavaScript 표현식을 작성해 출력 번호를 반환합니다. 유연해서 복잡한 로직에 적합합니다.

2.3 무엇을 선택할까? 이 표를 보세요

한 가지 요령이 있습니다. IF 뒤에 IF를 붙이고, 또 IF를 붙이고 있다면 이제 그만하고 Switch를 사용할 때입니다.

2.4 비교할 수 있는 데이터 유형

IF와 Switch 모두 다음 유형을 비교할 수 있습니다.

• String: exists, is empty, contains, matches regex…
• Number: 초과, 미만, 같음…
• Date & Time: 시간의 선후 비교
• Boolean: 참과 거짓
• Array: 길이, 특정 요소 포함 여부
• Object: 존재, 비어 있음, 비어 있지 않음

Date & Time은 꽤 유용합니다. 예를 들어 주문이 기한을 넘겼는지 날짜를 직접 비교해 판단할 수 있습니다.

3. 실전 사례: 주문 상태 자동 처리

실제 사례를 하나 소개하겠습니다. 작은 온라인 쇼핑몰을 운영하는 친구가 매일 관리자 화면을 직접 확인하고, 알림을 보내고, 전화를 걸며 주문을 처리했습니다. 이건 n8n으로 해결할 수 있다고 말했지만 친구는 반신반의했습니다.

2주 뒤, 창고 직원이 이렇게 말했습니다. “갑자기 주문 누락이 하나도 없네요?“

3.1 무엇을 할 것인가

요구 사항은 간단합니다.

• 새 주문(pending) → 창고에 상품 준비 알림
• 결제 완료(paid) → 고객에게 확인 이메일 발송
• 배송 완료(shipped) → 배송 정보 업데이트
• 취소됨(cancelled) → 환불 처리

상태가 네 가지이므로 Switch 노드로 분기하기에 알맞습니다.

3.2 Webhook 설정

먼저 Webhook 노드를 설정합니다.

Vultr - 고성능 NVMe 클라우드 서버, 전 세계 32개 노드, Docker 원클릭 배포

요금 보기 →광고

• HTTP Method: POST
• Path: orders/:orderId
• Response Mode: When Last Node Finishes(처리 결과를 반환해야 함)
• Authentication: Header Auth

보안에는 Header Auth를 사용했습니다. X-Shop-Secret이라는 사용자 지정 header를 만들고 임의의 문자열을 값으로 넣습니다. 이 secret을 아는 시스템만 호출할 수 있습니다.

3.3 Switch 노드 분기 로직

Switch를 Rules 모드로 설정하고, 네 가지 상태에 각각 대응하는 규칙 네 개를 만듭니다.

규칙1: {{ $json.status }} equals "pending" → 출력: pending
규칙2: {{ $json.status }} equals "paid" → 출력: paid
규칙3: {{ $json.status }} equals "shipped" → 출력: shipped
규칙4: {{ $json.status }} equals "cancelled" → 출력: cancelled

Fallback Output은 Extra Output으로 설정합니다. “unknown” 같은 이상한 상태가 들어와도 워크플로가 멈추지 않습니다.

3.4 전체 워크플로 JSON

다음 내용을 n8n으로 바로 가져와 사용할 수 있습니다.

{
  "name": "Order Processing",
  "nodes": [
    {
      "name": "Webhook",
      "type": "n8n-nodes-base.webhook",
      "position": [250, 300],
      "parameters": {
        "httpMethod": "POST",
        "path": "orders/:orderId",
        "responseMode": "responseNode",
        "authentication": "headerAuth"
      }
    },
    {
      "name": "Switch",
      "type": "n8n-nodes-base.switch",
      "position": [500, 300],
      "parameters": {
        "mode": "rules",
        "rules": [
          { "output": "pending", "conditions": { "value1": "{{ $json.status }}", "operation": "equals", "value2": "pending" } },
          { "output": "paid", "conditions": { "value1": "{{ $json.status }}", "operation": "equals", "value2": "paid" } },
          { "output": "shipped", "conditions": { "value1": "{{ $json.status }}", "operation": "equals", "value2": "shipped" } },
          { "output": "cancelled", "conditions": { "value1": "{{ $json.status }}", "operation": "equals", "value2": "cancelled" } }
        ],
        "fallbackOutput": "extra"
      }
    },
    {
      "name": "Notify Warehouse",
      "type": "n8n-nodes-base.slack",
      "position": [750, 200]
    },
    {
      "name": "Send Confirmation",
      "type": "n8n-nodes-base.emailSend",
      "position": [750, 300]
    },
    {
      "name": "Update Tracking",
      "type": "n8n-nodes-base.httpRequest",
      "position": [750, 400]
    },
    {
      "name": "Process Refund",
      "type": "n8n-nodes-base.stripe",
      "position": [750, 500]
    }
  ],
  "connections": {
    "Webhook": { "main": [[{ "node": "Switch", "type": "main", "index": 0 }]] },
    "Switch": {
      "main": [
        [{ "node": "Notify Warehouse", "type": "main", "index": 0 }],
        [{ "node": "Send Confirmation", "type": "main", "index": 0 }],
        [{ "node": "Update Tracking", "type": "main", "index": 0 }],
        [{ "node": "Process Refund", "type": "main", "index": 0 }]
      ]
    }
  }
}

이 JSON을 복사해 n8n에 붙여 넣으면 가져올 수 있습니다. Slack, Email, HTTP Request, Stripe 노드는 자신의 설정으로 교체해야 합니다.

3.5 테스트 및 배포

n8n에는 두 가지 URL이 있습니다.

• Test URL: 개발 및 디버깅에 사용하며, 수동으로 테스트할 때만 실행됩니다.
• Production URL: 활성화한 뒤에야 작동하며, 실제 외부 서비스에 사용합니다.

진행 순서는 다음과 같습니다.

1. Test URL을 호출해 노드 실행 순서와 데이터 흐름 확인
2. 문제가 없으면 오른쪽 위의 “Active” 스위치 클릭
3. 전자상거래 플랫폼에 Production URL 전달(또는 Zapier를 거쳐 전달)

테스트할 때는 curl로 호출을 시뮬레이션할 수 있습니다.

curl -X POST https://your-n8n-instance.com/webhook/orders/12345 \
  -H "Content-Type: application/json" \
  -H "X-Shop-Secret: your-secret-key" \
  -d '{"status": "paid", "customer_email": "[email protected]"}'

200 응답과 실행 로그가 보이면 정상적으로 연결된 것입니다.

4. 프로덕션 환경에서 피해야 할 함정

워크플로가 정상적으로 실행된다고 바로 프로덕션에 올릴 수 있는 것은 아닙니다. 제가 겪었던 몇 가지 함정을 공유하겠습니다.

4.1 보안 인증을 소홀히 하지 말 것

Header Auth는 첫 단계일 뿐입니다. 호출자의 IP 주소가 고정되어 있다면 IP Whitelist까지 추가하는 것이 더 안전합니다.

Webhook 노드의 고급 옵션에 “IP Whitelist” 매개변수가 있습니다. 여기에 호출을 허용할 IP 목록을 입력합니다. 다른 IP의 호출은 바로 거부되어 워크플로 자체가 트리거되지 않습니다.

JWT Auth도 꽤 유용하지만 설정이 조금 더 복잡합니다. 호출 시스템을 직접 관리한다면 Header Auth + IP Whitelist로 충분합니다.

4.2 오류는 반드시 알 수 있어야 한다

Webhook 노드에서 오류가 발생하면 호출자는 500 응답만 받을 수 있습니다. 하지만 정확히 어디에서 문제가 생겼는지는 직접 알아야 합니다.

워크플로에 Error Trigger 노드를 추가해 오류가 발생할 때 Slack 알림을 자동으로 보내면 됩니다. 대략 다음과 같이 구성합니다.

Error Trigger → Slack (오류 정보와 실행 ID 전송)

이렇게 하면 한밤중에 문제가 생겨도 휴대전화에서 확인할 수 있습니다. 아침에 사용자의 불만을 받고 나서야 알아차리는 일을 피할 수 있습니다.

Railway - 현대적인 배포 플랫폼, 번거로운 운영 없이 몇 분 만에 라이브

지금 시작 →광고

4.3 성능을 위한 작은 요령

워크플로 뒤에서 재고 조회, 이메일 발송, 결제 API 호출 등 여러 외부 API를 호출하면 응답이 매우 느려질 수 있습니다. 호출자가 기다리다 시간 초과를 겪을 수도 있습니다.

이때 Immediately 응답 모드를 사용하면 먼저 200을 반환하고 백그라운드에서 천천히 처리할 수 있습니다. 단, 호출자는 최종 결과를 알 수 없으므로 별도로 조회해야 합니다.

정기 일괄 작업이나 중요하지 않은 알림에 적합합니다. 결제 확인이나 실시간 조회에는 적합하지 않습니다.

4.4 디버깅은 Execution 로그에서

n8n은 모든 실행을 기록합니다. 왼쪽 메뉴의 “Executions”를 클릭하면 각 호출의 입력과 출력, 각 노드에 걸린 시간, 오류가 발생한 단계를 확인할 수 있습니다.

한 가지 세부 사항이 있습니다. 실행 로그는 기본 설정에서 최근 1,000개만 보관합니다. 호출량이 많다면 환경 변수 EXECUTIONS_DATA_MAX_AGE를 변경하거나 로그를 정기적으로 내보내는 것이 좋습니다.

또한 Test URL과 Production URL의 실행 로그는 별도로 확인해야 하므로 혼동하지 마세요.

마무리

이상입니다.

Webhook은 n8n에 초인종을 다는 것과 같습니다. 다른 시스템이 한 번 누르면 워크플로가 작업을 시작합니다. 설정할 때는 HTTP Method와 Response Mode를 주의하고, 라우트 매개변수를 사용할 수 있다면 적극 활용해 query string이 복잡해지지 않게 하세요.

IF와 Switch 중 무엇을 골라야 할까요? 분기가 두 개면 IF, 세 개 이상이면 Switch를 사용하세요. IF를 중첩하면 읽기만 해도 머리가 아픕니다.

앞의 주문 처리 워크플로는 그대로 가져다 써도 됩니다. 다만 Slack, Email, Stripe 설정은 자신의 환경에 맞게 바꿔야 합니다. 배포 전에는 Test URL로 여러 번 디버깅하고, 이상이 없을 때 활성화하세요.

마지막으로 보안을 소홀히 하지 마세요. Header Auth를 설정하고, 가능하다면 IP Whitelist도 추가하세요. 오류 알림 체계도 필요합니다. 그래야 문제가 생겼을 때 바로 알 수 있습니다.

질문이 있다면 댓글을 남기거나 n8n 커뮤니티에서 검색해 보세요. 실력 있는 사용자가 많이 활동하고 있습니다.