사례를 한 문단으로 고정합니다
워크플로를 만들기 전에 문장 하나로 적어두면 노드 선택이 쉬워집니다. 이번 사례는 이렇습니다. 매일 오전 8시, 지정한 피드들에서 최근 7일 안에 올라온 글 중 아직 보내지 않은 것만 골라, 제목과 링크를 묶어 메신저로 한 번 보낸다.
여기서 조건이 세 개 나옵니다. 시간(매일 8시), 범위(최근 7일), 상태(아직 보내지 않은 것). 앞의 두 개는 노드 설정으로 끝나고, 세 번째가 이 글의 본론입니다. n8n은 실행이 끝나면 기본적으로 기억을 갖지 않기 때문입니다.
| 정해야 할 것 | 이번 사례의 값 | 바꿀 때 영향 |
|---|---|---|
| 실행 주기 | 매일 08:00 | 잦을수록 중복 판정이 중요해짐 |
| 수집 범위 | 최근 7일 | 넓히면 첫 실행에서 대량 발송 |
| 중복 판정 키 | 글 주소(link) | 제목으로 잡으면 제목 수정 시 재발송 |
| 보내는 방식 | 여러 건을 한 메시지로 묶음 | 건별 발송이면 알림이 쏟아짐 |
노드는 다섯 개면 충분합니다
템플릿을 가져오면 노드가 열 개 넘게 들어 있는 경우가 많은데, 이 사례의 최소 구성은 다섯 개입니다.
| 순서 | 노드 | 역할 |
|---|---|---|
| 1 | Schedule Trigger | 매일 08:00 실행 |
| 2 | RSS Read | 피드를 읽어 항목별 아이템 생성 |
| 3 | Filter 또는 Code | 최근 7일 조건으로 걸러내기 |
| 4 | Remove Duplicates | 이전 실행에서 보낸 항목 제거 |
| 5 | Slack / Gmail 등 | 묶어서 한 번 발송 |
3번을 Code 노드로 짤지 Filter 노드로 할지는 취향 문제지만, 4번을 Code 노드로 직접 구현하려 들면 일이 커집니다. 실행과 실행 사이에 무언가를 저장해야 하는데, 그건 노드 하나가 아니라 저장소가 필요한 일이기 때문입니다. n8n이 이걸 전용 노드로 제공하는 이유가 여기 있습니다.
노드를 붙이기 전에 피드를 한 번 뜯어봤습니다
워크플로를 만들기 전에 대상 피드가 실제로 어떤 데이터를 주는지 확인하는 편이 시간을 아낍니다. 이 사이트의 RSS 주소로 실제 요청을 보내 받은 결과입니다.
HTTP 200 · 34,379 bytes
총 item 수: 50
최근 7일 이내: 14건
최근 30일 이내: 50건
pubDate 예시: Tue, 15 Sep 2026 00:00:00 +0000
이 네 줄에서 설계가 세 개 결정됩니다.
피드는 최근 50건만 준다피드에 담기는 항목 수는 사이트마다 다르고 보통 수십 건에서 끊깁니다. 실행 간격이 그보다 길면 사이에 올라온 글을 놓칩니다. 하루 한 번 실행에 50건이면 여유가 큽니다.
첫 실행은 조용하지 않다중복 기록이 비어 있는 첫 실행에서는 조건에 맞는 항목이 전부 신규로 잡힙니다. 7일 조건이면 14건, 30일로 넓히면 50건이 한 번에 나갑니다. 처음 켤 때 범위를 좁게 잡아야 하는 이유입니다.
날짜가 ISO 형식이 아니다RSS의 pubDate는 Tue, 15 Sep 2026 00:00:00 +0000 같은 RFC 822 형식입니다. 뒤에서 다룰 날짜 기반 중복 판정은 ISO 형식을 요구하므로 그대로 넣으면 안 됩니다.
같은 데이터로 중복 제거 동작도 미리 재현해봤습니다. 30일 범위 50건을 기준으로, 처리 기록을 비운 상태에서 한 번 돌리고 곧바로 한 번 더 돌린 결과입니다.
1회차 신규: 50건 → 기억한 키: 50개
2회차 신규: 0건 → 기억한 키: 50개
원하는 동작은 이겁니다. 두 번째 실행에서 0건이 나와야 알림이 조용합니다. 이 상태를 만드는 것이 4번 노드의 일입니다.
Remove Duplicates는 “같은 실행 안”과 “지난 실행까지”가 다릅니다
여기서 대부분이 한 번 헤맵니다. 이 노드에는 동작 모드가 세 가지 있고, 이름이 비슷해 보이지만 목적이 전혀 다릅니다.
| Operation | 비교 대상 | 이 사례에서 |
|---|---|---|
| Remove Items Repeated Within Current Input | 이번 실행에 들어온 아이템끼리 | 피드 여러 개를 합칠 때만 유용 |
| Remove Items Processed in Previous Executions | 이전 실행들에서 본 값까지 | 이걸 써야 합니다 |
| Clear Deduplication History | (비교 안 함) | 기록을 지울 때만 실행 |
두 번째 모드를 고르면 Keep Items Where 옵션이 나옵니다. 세 가지 중 어떤 걸 고르느냐에 따라 Value to Dedupe On에 넣어야 하는 값의 성격이 달라집니다.
| Keep Items Where | 넣어야 하는 값 | 맞는 상황 |
|---|---|---|
| Value Is New | 고유 ID 역할을 하는 필드 | 글 주소로 판정 (이번 사례) |
| Value Is Higher than Any Previous Value | 증가하는 숫자 | 순번·ID가 늘어나는 API |
| Value Is a Date Later than Any Previous Date | ISO 형식 날짜 | 갱신 시각으로 판정할 때 |
이번 사례는 첫 번째입니다. 판정 키로는 제목이 아니라 글 주소를 씁니다. 제목은 발행 후 수정되는 일이 흔하고, 그때마다 새 글로 인식돼 한 번 더 나갑니다.
두 가지 옵션을 같이 확인해야 합니다. Scope는 기록을 이 노드 단위로 둘지(Node, 기본값) 워크플로 전체에서 공유할지(Workflow) 정합니다. 같은 워크플로에 중복 제거 노드를 두 개 두고 서로 다른 목록을 관리하려면 기본값이 맞습니다. History Size는 기본 10,000건입니다. 하루 50건을 처리한다면 200일치가 쌓이는 셈인데, 한도를 넘어 밀려난 옛 항목이 다시 피드에 나타나면 신규로 판정될 수 있습니다. 실행 빈도가 높은 워크플로라면 이 숫자를 처리량 기준으로 다시 잡아야 합니다.
테스트 중에 알림이 쏟아졌다면 기록을 비우고 다시 시작할 수 있습니다. 세 번째 모드 Clear Deduplication History를 Clean Database로 한 번 실행하면 저장된 판정 기록이 초기 상태로 돌아갑니다. 이때 현재 입력 아이템은 건드리지 않습니다.
날짜로 판정하려다 막히는 지점
“주소 대신 발행 시각이 더 최신인 것만 통과시키면 되지 않나”라고 생각할 수 있습니다. 실제로 세 번째 옵션이 그 동작입니다. 그런데 앞에서 확인한 피드의 날짜는 이렇게 생겼습니다.
피드의 pubDate : Tue, 15 Sep 2026 00:00:00 +0000 (RFC 822)
노드 요구 형식 : 2026-09-15T00:00:00.000Z (ISO)
공식 문서는 날짜 기준 판정에서 ISO 형식의 날짜 값을 입력 필드로 요구한다고 명시합니다. 그래서 날짜로 판정하려면 중복 제거 노드 앞에 변환을 한 단계 넣어야 합니다. Code 노드에서 한 줄이면 됩니다.
for (const item of $input.all()) {
item.json.publishedIso = new Date(item.json.pubDate).toISOString();
}
return $input.all();
다만 이 사례에서는 날짜 판정을 권하지 않습니다. 같은 날짜에 여러 글이 올라오면 “더 나중” 조건에 걸려 뒤의 글이 빠질 수 있기 때문입니다. 실제로 확인한 피드에서도 같은 날짜에 세 건이 함께 올라와 있었습니다. 발행 시각이 중복되는 소스라면 고유 주소로 판정하는 쪽이 안전합니다. 날짜 판정은 “마지막으로 본 시점 이후 갱신된 레코드”를 가져오는 데이터베이스·API 연동에 어울립니다.
실패는 조용히 지나갑니다, 그래서 따로 붙입니다
예약 실행 워크플로의 가장 나쁜 실패는 에러가 아니라 아무 일도 일어나지 않는 것입니다. 피드 주소가 바뀌었거나 메신저 자격증명이 만료됐는데, 알림이 안 오니 “오늘은 새 글이 없나 보다”라고 넘어가게 됩니다.
n8n은 이걸 워크플로 단위 설정으로 해결합니다. 별도의 에러 워크플로를 만들어 두고 각 워크플로 설정에서 지정하는 방식입니다. 순서는 이렇습니다.
1. 새 워크플로의 첫 노드를 Error Trigger로 만든다이름은 Error Handler 정도로 두고 저장합니다. 하나를 만들어 여러 워크플로에서 함께 쓸 수 있습니다.
2. 알림 노드를 하나 붙인다받은 데이터에서 워크플로 이름과 에러 메시지, 마지막으로 실행된 노드를 꺼내 보냅니다.
3. 원래 워크플로의 Settings에서 Error workflow로 지정한다Options > Settings > Error workflow에서 선택하고 저장하면 연결됩니다.
에러 워크플로가 받는 데이터 구조도 알아두면 메시지를 짜기 쉽습니다. 실행 실패의 경우 execution 객체에 id, url, error.message, lastNodeExecuted가 들어오고, workflow 객체에 워크플로 이름이 들어옵니다.
워크플로 중간이 아니라 트리거 자체가 활성화에 실패한 경우에는 execution 대신 trigger 객체가 옵니다. 실행 자체가 없었으므로 execution.id와 execution.url도 없습니다. 알림 메시지에서 이 필드들을 무조건 참조하게 짜두면, 정작 가장 중요한 실패에서 알림 노드가 또 실패합니다.
특정 조건을 실패로 간주하고 싶다면 Stop And Error 노드로 일부러 실행을 실패시킬 수 있습니다. 예를 들어 “피드에서 0건이 나온 날이 사흘 연속이면 이상” 같은 규칙을 넣을 때 씁니다.
켜기 전에 확인하는 다섯 가지
| 확인 | 기준 |
|---|---|
| 첫 실행 발송량 | 범위를 좁혀 몇 건이 나가는지 수동 실행으로 먼저 확인 |
| 판정 키 | 제목이 아니라 변하지 않는 고유 주소 |
| History Size | 하루 처리량 × 보관하고 싶은 일수보다 큰지 |
| 에러 워크플로 | 지정됐는지, 트리거 실패 상황에서도 메시지가 만들어지는지 |
| 같은 날짜 항목 | 날짜 판정을 쓴다면 동시 발행 항목이 누락되지 않는지 |
활성화 직후 하루는 알림을 눈으로 확인하는 게 좋습니다. 중복 판정은 두 번째 실행부터 검증되는 기능이라, 첫 실행이 깔끔했다고 해서 끝난 게 아닙니다.
워크플로를 처음 만드는 단계라면 n8n 시작하기의 데이터 구조 설명을 먼저 보시고, 템플릿을 가져와 고치는 방식이라면 템플릿 고르는 기준을 함께 보세요. Code 노드에서 변환을 많이 하게 된다면 Code 노드 글에 입력·반환 모양을 정리해 두었습니다.
자주 묻는 질문
피드가 여러 개면 노드도 여러 개인가요?
RSS Read 노드를 피드 수만큼 두고 뒤에서 합치거나, 주소 목록을 아이템으로 만들어 한 노드에 흘려보내는 방법이 있습니다. 합치는 경우에는 서로 다른 피드가 같은 글을 싣는 일이 있어, 같은 실행 안 중복 제거도 한 번 거치는 구성이 깔끔합니다.
중복 기록은 워크플로를 복제하면 따라오나요?
기록은 노드 또는 워크플로 범위로 저장되므로, 복제한 워크플로는 기록이 비어 있는 상태에서 시작한다고 보는 편이 맞습니다. 복제본을 그대로 활성화하면 첫 실행에서 전체가 다시 나갑니다.
알림이 한 번에 여러 개 오는 걸 어떻게 막나요?
아이템 여러 건을 그대로 발송 노드에 넘기면 건별로 실행됩니다. 발송 전에 하나의 텍스트로 합치는 단계를 넣으면 메시지 한 통으로 정리됩니다.
피드 항목 수·날짜 형식·중복 판정 재현 결과는 2026년 9월 17일 실제 RSS 주소로 요청을 보내 확인한 값입니다. Remove Duplicates 노드의 동작 모드·옵션·기본 보관 건수와 에러 워크플로가 받는 데이터 구조는 n8n 공식 문서를 근거로 했으며, 노드는 n8n 1.64.0에서 개편된 버전 기준입니다.