n8n 으로 워크플로우 만들 때 쓰는 핵심 기능 총정리
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 / URL —
GET 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) 예요. “이 워크플로우의 다음 단계는 name 과 total 만 필요하다” 싶을 때, 여기서 필요한 필드만 추려서 깔끔한 모양으로 만들어 넘기면 뒤가 편해져요.
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 으로 워크플로우를 만들 때 쓰는 기능을 한 흐름으로 다시 묶으면 이래요.
- 트리거 로 시작점을 잡고 (Manual / Schedule / Webhook)
- 액션 노드·HTTP Request 로 실제 일을 시키고
- 표현식 으로 앞 노드의 결과를 뒤로 넘기고
- IF / Switch / Merge / Filter 로 흐름을 가르고
- Edit Fields / Aggregate 로 데이터 모양을 다듬고
- 노드로 안 되면 Code 노드, 반복되면 서브워크플로우
- Error Trigger·Retry 로 실패에 대비하고
- 비밀은 Credentials 로 빼두고, 필요하면 AI Agent 까지
전부 1장의 “데이터는 아이템 배열로 흐르고, 노드는 아이템마다 실행된다” 라는 한 문장 위에서 동작해요. 이 모델만 몸에 익으면 나머지 노드는 설명서 한 번 읽고 바로 갖다 쓸 수 있어요.
일단 오늘은 여기까지…..
다음 글에서는 실제로 자주 쓰는 워크플로우 패턴 몇 개를 예제로 만들어볼게요.