블로그 하나 운영하면서 "글 쓸 시간이 없다"는 말을 입에 달고 살던 시절이 있었습니다. 그때 n8n으로 콘텐츠 파이프라인을 구성했고, 3주 만에 하루 평균 4~5편의 포스트가 자동 발행되는 구조를 만들었습니다. 오가닉 트래픽은 23% 올랐지만, 솔직히 그게 전부 좋은 이야기는 아니었습니다. 이 글은 그 경험을 가능한 한 있는 그대로 정리한 것입니다.
워크플로우 설계와 에러핸들링: 실제로 부딪힌 것들
n8n을 처음 접했을 때 제가 받은 인상은 "Make보다 자유롭고, Zapier보다 저렴하다"였습니다. 특히 자가 호스팅(self-hosting) 옵션이 결정적이었는데, 이는 서버를 직접 운영함으로써 플랫폼 종속 없이 API 호출 횟수 제한 없이 워크플로우를 실행할 수 있는 방식을 말합니다. Railway에 n8n Docker 컨테이너를 올려서 월 약 7달러로 운영 중인데, 이 비용으로 무제한 워크플로우 실행이 가능하다는 점은 대규모 콘텐츠 파이프라인에 실질적인 강점입니다.
키워드 수집 단계에서는 Google Trends RSS 피드를 RSS Read 노드로 파싱하는 방식이 가장 안정적이었습니다. 비공식 pytrends API를 먼저 써봤는데, 429 오류가 너무 자주 터졌습니다. 여기서 429 오류란 서버가 단시간에 너무 많은 요청을 받았을 때 클라이언트에게 요청을 줄이라고 보내는 HTTP 상태 코드입니다. RSS 피드는 별도 인증 없이도 안정적으로 작동해서, 지금은 이쪽을 메인으로 쓰고 있습니다.
수집된 키워드는 Airtable에 저장하고, 이미 발행된 주제와 중복되는지 Filter 노드로 체크하는 중복 제거 로직을 반드시 붙였습니다. 이 단계를 빼먹었다가 동일 키워드로 포스트가 세 개나 올라가는 사고를 겪었습니다. 대수롭지 않아 보이는 부분이지만, 실제로 운영해보면 이런 곳에서 시간을 제일 많이 잡아먹습니다.
HTML 포맷팅 단계에서는 n8n의 Code 노드(JavaScript)를 써서 OpenAI의 마크다운 출력을 HTML로 변환했습니다. n8n 클라우드 환경에서는 외부 npm 패키지를 설치할 수 없기 때문에, marked.js 같은 경량 라이브러리를 코드 안에 인라인으로 붙여 넣는 방식으로 해결했습니다. 자가 호스팅 환경이면 npm 패키지를 직접 로드할 수 있어서 훨씬 유연합니다.
워크플로우 설계에서 제가 가장 공들인 부분은 에러핸들링(Error Handling) 브랜치였습니다. 에러핸들링이란 워크플로우 실행 중 발생하는 예외 상황을 감지하고 적절히 처리하는 로직을 가리킵니다. 노코드 도구의 함정은 에러가 조용히 발생한다는 점입니다. OpenAI 노드가 레이트 리밋(rate limit)에 걸리거나 WordPress 노드가 인증 오류를 반환해도, 잡아내는 브랜치가 없으면 워크플로우는 그냥 종료됩니다. 핵심 노드마다 Error Trigger 브랜치를 달고 Slack 노드로 즉시 알림을 받도록 설정하고 나서야 포스팅 누락 사고가 거의 사라졌습니다.
n8n 자체의 기술적 한계도 솔직히 말씀드리면, 노드 간 데이터 전달이 JSON 직렬화(JSON serialization)에 의존합니다. JSON 직렬화란 데이터 구조를 텍스트 형태로 변환해 노드 사이에서 주고받는 과정인데, 5,000자 이상 대용량 텍스트를 다루면 워크플로우가 눈에 띄게 느려지거나 메모리 오류가 발생하는 경우가 있었습니다. "노코드"라는 라벨이 붙어 있지만, 실제로 제대로 쓰려면 JavaScript 이해가 사실상 필수입니다. 이 부분은 진입 전에 알고 들어가는 것이 좋습니다.
n8n으로 콘텐츠 자동화를 구성할 때 제가 실제로 확인한 핵심 설정 단계는 다음과 같습니다.
- Google Trends RSS 피드 수집 및 키워드 파싱
- Airtable 연동을 통한 중복 키워드 제거 필터링
- OpenAI 노드로 초안 생성 후 Code 노드에서 HTML 변환
- Error Trigger 브랜치 설정 및 Slack 알림 연결
- WordPress 노드로 최종 발행 및 발행 로그 기록
애드센스 수익화와 콘텐츠 품질의 현실
자동화로 트래픽이 늘었다고 해서 애드센스 수익이 비례해서 오르지는 않았습니다. 이건 제가 직접 경험해봤기 때문에 단호하게 말씀드릴 수 있습니다. 수익을 결정하는 건 포스트 수가 아니라 RPM과 CTR입니다. RPM(Revenue Per Mille)이란 광고 1,000회 노출당 발생하는 수익을 뜻하는 지표로, 어떤 키워드를 다루느냐에 따라 몇 배 이상 차이가 납니다. 대량 자동화로 포스트를 쌓는 것보다 고단가 틈새 키워드 몇 개를 깊이 있게 다루는 쪽이 수익 관점에서 훨씬 효율적이라는 데이터가 많습니다.
콘텐츠 품질 편차도 현실적인 문제입니다. 제 경험상 트렌드 키워드 중 의료·법률 분야에서 생성된 글의 정확도가 특히 낮았고, 해당 카테고리에는 수동 검토 게이트를 따로 추가할 수밖에 없었습니다. 결국 "완전 자동화"라는 말은 조금 과장된 표현이고, 사람의 손이 닿아야 하는 지점이 반드시 남습니다.
구글 애드센스 정책상 프로그래밍 방식으로 생성된 콘텐츠도 독자에게 실질적 가치를 제공하면 정책 위반이 아닙니다(출처: Google AdSense 고객센터). 하지만 2024년 Google 코어 업데이트 이후 AI 대량 생산 콘텐츠 사이트들의 검색 순위가 집단적으로 하락한 사례가 다수 보고되었습니다(출처: Search Engine Journal). 여기서 코어 업데이트란 구글이 검색 품질을 전반적으로 재평가하기 위해 주기적으로 시행하는 대규모 알고리즘 변경을 말하는데, 이번 업데이트는 특히 자동 생성 콘텐츠를 집중적으로 겨냥한 것으로 분석됩니다.
'콘텐츠 공장'이라는 표현이 시사하듯, 이 접근법은 블로그를 독자와의 소통 공간이 아닌 광고 노출 기계로 보는 시각에서 출발합니다. 단기 수익 관점에서 유효한 전략이라고 생각하는 분들도 있는데, 저는 그 판단 자체를 부정하지는 않습니다. 다만 이 방식이 대규모로 확산될 경우 인터넷 정보 생태계 전체의 품질을 끌어내린다는 우려는 실제로 현실화되고 있다고 봅니다.
결국 n8n 자동화는 전략이 명확할 때 비로소 효과를 냅니다. 어떤 키워드를 다루고, 어느 카테고리에 사람의 검토를 남길 것인지 먼저 설계하고 자동화를 얹는 순서가 맞습니다. 파이프라인을 먼저 만들고 방향을 나중에 고민하면, 자동화는 그저 노력을 잘못된 곳으로 빠르게 옮기는 도구가 될 뿐입니다. 이미 한 번 그 방향으로 삽질을 해봤기 때문에, 이 순서만큼은 자신 있게 권장할 수 있습니다.
참고:
[1] n8n Documentation — LangChain & AI Nodes https://docs.n8n.io/integrations/builtin/cluster-nodes/root-nodes/n8n-nodes-langchain.agent/
[2] Google Trends RSS Feed (공식 비인증 엔드포인트) https://trends.google.com/trends/trendingsearches/daily/rss?geo=KR
[3] Google AdSense Program Policies — Automated & AI Content https://support.google.com/adsense/answer/1282110
[4] Search Engine Journal — Google Helpful Content Update Impact Analysis (2024) https://www.searchenginejournal.com/google-helpful-content-update/
[5] n8n Community — Self-Hosting on Railway 가이드 https://community.n8n.io/t/running-n8n-on-railway/