9 분 소요

Summary

n8n 을 처음 켜면 캔버스에 노드를 끌어다 선으로 잇는 화면이 나와요. 그런데 막상 “뭘 어떤 순서로 붙여야 원하는 자동화가 되는지” 는 노드 목록만 봐서는 잘 안 잡혀요. 결국 자주 쓰는 기능 몇 개가 워크플로우의 90% 를 차지하거든요.

이 글에서는 n8n 으로 워크플로우를 만들 때 실제로 손이 가장 많이 가는 핵심 기능들 을 한 번에 정리합니다. 노드 카탈로그를 전부 나열하는 게 아니라, “이건 알아야 워크플로우를 짤 수 있다” 수준의 기능만 골랐어요.

💡 이 글에서 다루는 것

  • n8n 의 데이터 모델 — 아이템(items) 배열이라는 단 하나의 개념
  • 트리거 / 액션 노드 / 만능 HTTP Request
  • 표현식(Expressions) — {{ $json.x }} 문법과 자주 쓰는 변수
  • 흐름 제어 — IF · Switch · Merge · Filter · Loop
  • 데이터 변환 — Edit Fields · Aggregate · Sort · Remove Duplicates
  • Code 노드 (JS/Python), 서브워크플로우, Wait
  • 에러 처리 — Error Trigger · continueOnFail · 재시도
  • 자격증명(Credentials) 과 AI Agent 노드

운영 모드(일반/큐) 이야기는 따로 정리해뒀어요. 스케일링이 궁금하면 n8n 일반 모드 vs 큐 모드 글을 같이 보시면 좋아요.



1. 먼저 데이터 모델부터 — 모든 게 “아이템 배열”

기능을 보기 전에 이거 하나만 잡고 가면 나머지가 전부 쉬워져요. n8n 에서 노드와 노드 사이를 흐르는 데이터는 항상 아이템(item)들의 배열 입니다.

아이템 하나는 이런 모양이에요.

[
  { "json": { "name": "Kayser", "age": 33 } },
  { "json": { "name": "Doru",   "age": 28 } }
]
  • json — 우리가 다루는 실제 데이터(키-값)
  • binary — (있을 때만) 파일 데이터. 이미지·PDF 같은 것

여기서 가장 중요한 동작은 노드는 들어온 아이템마다 한 번씩 실행된다 는 점이에요. 위처럼 아이템이 2개면, 다음 노드(예: HTTP Request)는 2번 실행됩니다. 반복문을 따로 안 짜도 자동으로 아이템 수만큼 돌아요.

✅ “왜 노드가 여러 번 실행되지?” 하고 헷갈리는 대부분의 원인이 이거예요. 들어온 아이템 개수만큼 돈다 — 이 한 줄만 기억하면 됩니다.



2. 트리거 — 워크플로우의 시작점

모든 워크플로우는 트리거 노드 하나로 시작해요. “언제 이 자동화가 돌 것인가” 를 정하는 노드입니다. 자주 쓰는 건 네 종류예요.

트리거 언제 쓰나
Manual Trigger 캔버스에서 직접 “Test workflow” 눌러 실행. 개발·디버깅용
Schedule Trigger 매일 09:00, 5분마다 등 주기 실행 (cron)
Webhook 외부에서 HTTP 요청이 오면 실행. 연동의 핵심
App Trigger Gmail 새 메일, Slack 메시지 등 서비스 이벤트 감지

Webhook 트리거가 특히 중요해요. URL 하나가 생기고, 거기로 누가 POST 를 쏘면 그 본문(body)이 첫 아이템의 json 으로 들어와요. 외부 시스템과 n8n 을 잇는 가장 기본적인 다리입니다.

💡 Schedule Trigger 의 주기는 “분/시/일” 단위 프리셋으로도 잡을 수 있고, 익숙하면 cron 표현식(0 9 * * 1-5 = 평일 9시)을 직접 넣어도 돼요.



3. 액션 노드와 만능 키 — HTTP Request

트리거가 “시작” 이라면, 그 뒤에 붙는 액션 노드 들이 실제 일을 합니다. Slack 으로 메시지 보내기, Google Sheets 에 행 추가, Notion 페이지 생성 같은 것들이죠. n8n 은 이런 서비스 연동 노드를 수백 개 내장하고 있어요.

그런데 정작 가장 많이 쓰게 되는 건 전용 노드가 아니라 HTTP Request 노드예요. 전용 노드가 없는 API 라도 이 노드 하나로 거의 다 호출할 수 있거든요.

[ Schedule Trigger ] → [ HTTP Request ] → [ Slack ]
   매일 9시              환율 API 호출       결과 전송

HTTP Request 노드에서 잡는 것들:

  • Method / URLGET https://api.example.com/rates
  • Query / Body — 파라미터, JSON 바디
  • Authentication — 뒤에서 설명할 자격증명을 여기 연결
  • Pagination — 다음 페이지를 자동으로 따라가며 전부 수집

✅ 어떤 SaaS 를 연동하려는데 전용 노드가 안 보여도 당황하지 마세요. API 문서만 있으면 HTTP Request 로 거의 다 됩니다. n8n 을 오래 쓰면 결국 이 노드를 제일 사랑하게 돼요.



4. 표현식(Expressions) — 노드끼리 데이터 넘기기

워크플로우의 진짜 묘미는 앞 노드의 결과를 뒤 노드에서 꺼내 쓰는 거예요. 이때 쓰는 게 표현식이고, {{ }} 안에 적어요. 입력칸 옆의 톱니/표현식 토글을 켜면 고정값 대신 표현식을 넣을 수 있어요.

자주 쓰는 변수들이에요.

표현식 의미
{{ $json.name }} 현재 아이템json.name
{{ $json["주문 번호"] }} 키에 공백/한글이 있으면 대괄호 표기
{{ $node["HTTP Request"].json.price }} 특정 노드의 결과에서 값 꺼내기
{{ $now }} 현재 시각 (Luxon DateTime)
{{ $itemIndex }} 지금 처리 중인 아이템의 순번

표현식 안에서는 자바스크립트가 거의 그대로 돌아가요. 그래서 이런 가공도 한 줄로 됩니다.

{{ $json.email.toLowerCase() }}
{{ $json.price * 1.1 }}
{{ $now.toFormat('yyyy-MM-dd') }}
{{ $json.tags.join(', ') }}

⚠️ 키 이름에 공백이나 한글이 있으면 $json.주문 번호 처럼 점 표기로 못 꺼내요. 반드시 $json["주문 번호"] 대괄호 표기를 쓰세요. 여기서 막히는 분들이 의외로 많아요.



5. 흐름 제어 — 조건·분기·합치기·반복

데이터를 그냥 한 줄로 흘려보내기만 하면 자동화라고 하기엔 약해요. “조건에 따라 다르게” 처리하는 게 진짜 워크플로우죠. 흐름을 제어하는 노드는 다섯 개만 알면 충분해요.

노드 하는 일
IF 조건 하나로 true / false 두 갈래로 분기
Switch 값에 따라 여러 갈래(케이스)로 분기
Filter 조건에 맞는 아이템만 통과, 나머지는 버림
Merge 두 갈래에서 온 데이터를 다시 하나로 합침
Loop Over Items 아이템을 정해진 크기씩 끊어서 반복 (배치)

IF 와 Filter 가 헷갈리기 쉬운데, 차이는 명확해요.

  • IF — 통과 못 한 아이템도 false 출력으로 따로 나옴 (양쪽 다 이어서 처리 가능)
  • Filter — 조건에 안 맞으면 그냥 사라짐 (통과한 것만 다음으로)
            ┌─ true ─→ [ Slack 알림 ]
[ IF ] ─────┤
   금액>10만  └─ false ─→ [ 로그만 남김 ]

Loop Over Items 는 대량 데이터를 한꺼번에 처리하면 API 가 막히거나 메모리가 터질 때 써요. “100개를 10개씩 끊어서” 돌리는 식으로 부하를 조절합니다.

💡 1장에서 “노드는 아이템마다 자동으로 반복된다” 고 했죠? 그래서 단순 반복엔 Loop 가 필요 없어요. Loop 는 배치 크기 조절이나 루프 안에서 누적이 필요할 때만 꺼내면 됩니다.



6. 데이터 변환 — 모양 바꾸기

노드마다 출력 데이터 모양이 제각각이라, 다음 노드에 넘기기 전에 모양을 다듬는 일이 잦아요. 변환용 노드들도 단골이 정해져 있어요.

노드 하는 일
Edit Fields (Set) 필드 추가·이름변경·삭제. 출력 모양을 직접 설계
Aggregate 여러 아이템의 한 필드를 하나의 배열/값으로 모음
Split Out 배열 필드를 여러 아이템으로 펼침 (Aggregate 의 반대)
Sort 특정 필드 기준 정렬
Remove Duplicates 중복 아이템 제거
Limit 앞에서 N개만 남기기

가장 많이 쓰는 건 Edit Fields(Set) 예요. “이 워크플로우의 다음 단계는 nametotal 만 필요하다” 싶을 때, 여기서 필요한 필드만 추려서 깔끔한 모양으로 만들어 넘기면 뒤가 편해져요.

Aggregate ↔ Split Out 의 관계가 특히 유용해요. 예를 들어 아이템 3개의 email 을 Aggregate 로 한 배열로 모으면 이렇게 돼요.

입력 (아이템 3개)
  { email: "a@x.com" }
  { email: "b@x.com" }
  { email: "c@x.com" }

Aggregate(field: email) 출력 (아이템 1개)
  { emails: ["a@x.com", "b@x.com", "c@x.com"] }

이렇게 모아두면 “한 통의 메일에 수신자 3명” 같은 처리가 쉬워져요.



7. Code 노드 — 노드로 안 되면 코드로

내장 노드 조합으로 표현하기 어려운 가공은 Code 노드 로 해결해요. JavaScript 가 기본이고 Python 도 됩니다. 노코드의 마지막 탈출구라고 보면 돼요.

Code 노드는 두 가지 모드가 있어요.

  • Run Once for All Items — 전체 아이템 배열을 한 번에 받아 처리 (기본)
  • Run Once for Each Item — 아이템마다 한 번씩 실행

전체 모드에서는 $input.all() 로 들어온 아이템들을 받고, 똑같이 { json: {...} } 배열을 반환하면 돼요. 실제로 어떤 값이 들고 나는지 보면 이래요.

// Run Once for All Items 모드
const items = $input.all();

// 들어온 아이템: [{ json: { price: 1000 } }, { json: { price: 2000 } }]
const result = items.map(item => ({
  json: {
    price: item.json.price,
    priceWithVat: item.json.price * 1.1,
  },
}));

return result;

이 코드가 반환하는 값을 출력 패널에서 보면 이렇게 찍혀요.

[
  { "price": 1000, "priceWithVat": 1100 },
  { "price": 2000, "priceWithVat": 2200 }
]

💡 표현식({{ }})으로 한 줄이면 되는 건 굳이 Code 노드까지 안 가도 돼요. Code 노드는 여러 아이템을 가로질러 계산하거나, 외부 라이브러리 수준의 로직이 필요할 때 꺼내는 게 깔끔합니다.



8. 서브워크플로우 — 워크플로우를 함수처럼

워크플로우가 커지면 한 캔버스에 다 욱여넣기보다, 공통 로직을 별도 워크플로우로 떼어내 재사용하는 게 좋아요. 이걸 서브워크플로우 라고 하고, Execute Sub-workflow 노드로 호출합니다.

[ 메인 워크플로우 ]
      │
      └─ [ Execute Sub-workflow ] ─→ "고객 데이터 정규화" 워크플로우 호출
  • 호출하는 쪽에서 데이터를 넘기고, 서브워크플로우는 결과를 돌려줘요. 코드의 함수 호출과 똑같은 그림이에요.
  • “Slack 알림 보내기”, “에러 로그 적재” 같은 공통 동작을 한 번만 만들어두고 여러 워크플로우에서 부르면 유지보수가 훨씬 편해집니다.

✅ 같은 노드 묶음을 두 번째 복붙하고 있다면, 그게 서브워크플로우로 빼라는 신호예요.



9. Wait — 잠시 멈췄다 가기

중간에 시간을 두거나, 외부 응답을 기다려야 할 때 Wait 노드를 써요. 세 가지 방식이 있어요.

  • 시간 대기 — “30초 후” / “1시간 후” 진행
  • 특정 시각까지 — “내일 오전 9시까지” 멈췄다 재개
  • Webhook 수신까지 — 외부에서 콜백이 올 때까지 일시정지

마지막이 특히 강력해요. 예를 들어 “승인 요청 메일을 보내고, 사용자가 승인 링크를 누를 때까지 기다렸다가 다음 단계 진행” 같은 사람이 끼어드는 흐름(human-in-the-loop) 을 만들 수 있어요.

💡 Wait 로 일시정지된 실행은 메모리에 붙들고 있는 게 아니라 상태를 저장해뒀다가 재개해요. 그래서 “1시간 후” 같은 긴 대기도 부담 없이 쓸 수 있습니다.



10. 에러 처리 — 실패를 다루는 법

자동화는 결국 언젠가 실패 해요. API 가 5초 동안 안 떴거나, 응답 형식이 바뀌었거나. 그래서 에러 처리는 선택이 아니라 필수예요. n8n 은 세 단계로 다룰 수 있어요.

① 노드 단위 — Settings 탭

각 노드의 설정에서 실패 동작을 정할 수 있어요.

  • Retry On Fail — 실패하면 자동 재시도 (횟수·간격 지정)
  • Continue On Fail — 실패해도 워크플로우를 멈추지 않고 다음으로 (에러를 출력 데이터로 넘김)

② 분기 처리 — error 출력

Continue On Fail 을 켜면 노드에 에러 전용 출력이 생겨서, 성공/실패를 갈라 다르게 처리할 수 있어요.

                  ┌─ 성공 ─→ [ 다음 단계 ]
[ HTTP Request ] ─┤
                  └─ 에러 ─→ [ Slack 으로 실패 알림 ]

③ 워크플로우 단위 — Error Trigger

별도 워크플로우에 Error Trigger 노드를 두고, 메인 워크플로우의 설정에서 “에러 워크플로우” 로 지정하면, 어디서든 실패가 나면 그 워크플로우가 자동 호출돼요. 실패한 워크플로우 이름·에러 메시지·실행 ID 가 통째로 넘어와서, 모든 자동화의 실패를 한 곳에서 알림 받을 수 있어요.

🚨 운영에 올릴 워크플로우라면 Error Trigger 워크플로우 하나는 꼭 만들어 두세요. 이게 없으면 “어제부터 자동화가 죽어 있었는데 아무도 몰랐다” 가 됩니다.



11. 자격증명(Credentials) — 비밀은 노드 밖에

API 키, OAuth 토큰, DB 비밀번호 같은 민감 정보는 노드 안에 직접 박지 않아요. n8n 은 Credentials 라는 별도 저장소에 암호화해서 보관하고, 노드에서는 “이 자격증명을 쓴다” 고 연결만 합니다.

  • 한 번 등록한 자격증명을 여러 노드·여러 워크플로우에서 재사용
  • 워크플로우를 내보내기(export)해도 자격증명 값은 빠져서 안전하게 공유 가능
  • OAuth2 는 n8n 이 토큰 갱신까지 자동으로 처리

🚨 표현식이나 Code 노드에 API 키를 그대로 적는 건 피하세요. 자격증명으로 빼두면 워크플로우 JSON 을 공유하거나 백업해도 비밀이 새지 않아요.



12. AI 노드 — 워크플로우 안에 LLM 끼우기

요즘 n8n 을 찾는 큰 이유 중 하나가 AI 노드 예요. LangChain 기반 노드들이 들어 있어서, 워크플로우 안에 LLM 호출이나 에이전트를 자연스럽게 끼울 수 있어요.

  • AI Agent — 도구(툴)를 붙여주면 알아서 판단하며 작업을 수행
  • Chat Model — OpenAI·Anthropic 등 모델을 연결하는 노드
  • Tool / Memory / Vector Store — 에이전트에 붙이는 도구·기억·검색 컴포넌트

예를 들어 “Webhook 으로 들어온 고객 문의 → AI Agent 가 내부 문서를 검색해 답변 초안 작성 → Slack 으로 담당자에게 전달” 같은 흐름을 노드 몇 개로 만들 수 있어요. AI Agent 에 HTTP Request 나 서브워크플로우를 도구로 물려주면, 모델이 필요할 때 그 도구를 직접 호출하게 만들 수도 있고요.

💡 AI 노드도 결국 1장의 아이템 모델 위에서 돌아요. 들어온 아이템의 텍스트가 프롬프트로 들어가고, 모델 응답이 다시 json 으로 나와서 뒤 노드로 흘러갑니다.



13. 디버깅을 편하게 — 알아두면 좋은 것들

마지막으로, 워크플로우를 만들 때 시간을 크게 아껴주는 편의 기능 몇 개만 짚을게요.

  • 노드별 실행 결과 패널 — 각 노드를 클릭하면 입력/출력 데이터가 표 또는 JSON 으로 보여요. 표현식이 왜 비었는지 여기서 바로 확인할 수 있어요.
  • Pin Data — 트리거나 노드의 출력을 “고정” 해두면, 매번 실제 API 를 다시 안 부르고 그 값으로 아래 노드들을 테스트할 수 있어요. 외부 호출이 느리거나 비용이 들 때 특히 유용.
  • Execute Step / 부분 실행 — 워크플로우 전체가 아니라 특정 노드까지만 돌려볼 수 있어요.
  • 실행 기록(Executions) — 과거 실행이 성공/실패 로그로 남아서, 실패한 실행을 열어 그 시점 데이터를 그대로 들여다볼 수 있어요.

✅ 특히 Pin Data 는 개발 속도를 체감으로 바꿔줘요. 트리거 데이터를 한 번 핀해두고 아래 노드들을 마음껏 고치다가, 다 되면 핀을 풀면 됩니다.



14. 정리

n8n 으로 워크플로우를 만들 때 쓰는 기능을 한 흐름으로 다시 묶으면 이래요.

  1. 트리거 로 시작점을 잡고 (Manual / Schedule / Webhook)
  2. 액션 노드·HTTP Request 로 실제 일을 시키고
  3. 표현식 으로 앞 노드의 결과를 뒤로 넘기고
  4. IF / Switch / Merge / Filter 로 흐름을 가르고
  5. Edit Fields / Aggregate 로 데이터 모양을 다듬고
  6. 노드로 안 되면 Code 노드, 반복되면 서브워크플로우
  7. Error Trigger·Retry 로 실패에 대비하고
  8. 비밀은 Credentials 로 빼두고, 필요하면 AI Agent 까지

전부 1장의 “데이터는 아이템 배열로 흐르고, 노드는 아이템마다 실행된다” 라는 한 문장 위에서 동작해요. 이 모델만 몸에 익으면 나머지 노드는 설명서 한 번 읽고 바로 갖다 쓸 수 있어요.

일단 오늘은 여기까지…..
다음 글에서는 실제로 자주 쓰는 워크플로우 패턴 몇 개를 예제로 만들어볼게요.