🚀 n8n으로 VSCODE / Claude Code 릴리스 노트 번역 파이프라인 만들기

📌 한 줄 요약: VS Code와 Claude Code 릴리스 노트를 자동으로 한국어 번역하여 Ghost 블로그에 발행하는 n8n 워크플로우를 만든 과정과, 그 과정에서 마주친 실전 트러블슈팅을 정리합니다.

개발 도구의 릴리스 노트는 대부분 영어로만 제공됩니다. 매주 업데이트되는 VS Code 릴리스 노트와 거의 매일 나오는 Claude Code 변경 로그(Changelog)를 매번 직접 읽고 번역하는 것은 번거로운 반복 작업입니다.

**"반복 작업이 보이면 자동화하라"**는 원칙에 따라, RSS 피드를 감시하고, AI 모델로 번역한 뒤, Ghost CMS에 자동으로 발행하는 파이프라인을 n8n을 활용해 구축해 보았습니다.

💡 파이프라인 구축 핵심 포인트

1. 소스별 특성에 맞춘 독립적인 워크플로우 설계

워크플로우를 설계하기 전, 피드 데이터의 실제 구조를 파악하는 것이 중요합니다. VS Code와 Claude Code 모두 Atom 피드를 제공하지만, 담고 있는 정보의 깊이가 달랐습니다.

• VS Code (code.visualstudio.com/feed.xml): 요약된 한 줄과 링크만 제공합니다. 실제 릴리스 노트 전문을 얻으려면 HTTP 요청으로 code.visualstudio.com/updates/v1_xxx 페이지를 가져와 <main> 태그에서 본문을 추출하는 과정이 추가로 필요합니다. 대신 rel="related" 링크에 릴리스 하이라이트 이미지가 있어 Ghost의 feature_image로 바로 활용할 수 있는 장점이 있습니다.
• Claude Code (raw.githubusercontent.com/anthropics/claude-code/main/feed.xml): 피드 자체에 변경 로그 HTML이 통째로 들어있습니다. 별도의 페이지 Fetch가 필요 없어 워크플로우 노드를 2개 줄일 수 있지만, 릴리스 빈도가 높아 중복 발행 방지가 훨씬 중요합니다.

이러한 차이점 때문에 하나의 통합 워크플로우가 아닌 소스별 독립 워크플로우로 분리했습니다. 이를 통해 한쪽 피드 구조가 바뀌거나 장애가 발생해도 다른 쪽은 영향을 받지 않습니다.

2. 미래 날짜(Insiders 빌드) 필터링 함정

VS Code 피드에는 종종 Insiders(프리 릴리스) 빌드가 섞여 들어오며, 이 항목에는 미래 날짜가 찍혀 있는 경우가 있습니다. (예: 오늘이 9월 11일인데 v1.138 (Insiders)의 <updated>가 9월 16일로 설정됨)

제목에 "(Insiders)"가 포함된 경우 필터 노드에서 1차적으로 걸러내지만, 태그 없이 사전 등록되는 이론적 예외 상황을 방어하기 위해 날짜 기반 검증 코드를 추가했습니다.

// 미래 날짜 항목을 건너뛰는 안전장치
const updatedAt = item.json.isoDate || item.json.pubDate || '';
if (updatedAt && new Date(updatedAt) > new Date()) continue;

이러한 예방 차원의 로직 덕분에 미래 날짜 항목은 다음 폴링(Polling) 시기에 자연스럽게 처리됩니다.

3. Supabase를 활용한 중복 발행 완벽 차단

n8n 스케줄러를 6시간마다 실행하면, 같은 릴리스가 여러 번 최신 항목으로 잡힐 수 있습니다. RSS Read 노드가 자체적으로 본 항목을 메모리에 기록하긴 하지만, 워크플로우를 수정하거나 n8n이 재시작되면 이 데이터는 초기화됩니다.

확실한 **발행 이력의 원장(Single Source of Truth)**이 필요했기에, Supabase에 published_releases 테이블을 생성하여 관리했습니다.

CREATE TABLE published_releases (
  id              BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  slug            TEXT UNIQUE NOT NULL,
  source          TEXT NOT NULL CHECK (source IN ('vscode', 'claude-code')),
  version         TEXT NOT NULL,
  title           TEXT NOT NULL,
  original_url    TEXT NOT NULL,
  release_date    TIMESTAMPTZ NOT NULL,
  change_count    INT,
  content_length  INT,
  ghost_post_id   TEXT,
  ghost_url       TEXT,
  status          TEXT NOT NULL DEFAULT 'published',
  feature_image   TEXT,
  published_at    TIMESTAMPTZ DEFAULT NOW(),
  created_at      TIMESTAMPTZ DEFAULT NOW()
);

핵심 흐름:

1. RSS 피드 폴링 및 필터링
2. Supabase에서 slug 조회 (이미 존재하면 즉시 종료)
3. 통과된 항목만 Gemini 번역 및 Ghost 발행
4. Supabase에 발행 이력(INSERT) 기록

이 구조의 가장 큰 장점은 비용 절감입니다. 이미 발행된 릴리스를 확인하여 Gemini API 호출 전에 차단하므로 불필요한 토큰 낭비를 막을 수 있습니다. 또한 slug에 UNIQUE 제약을 걸어두어, 레이스 컨디션(Race Condition)이 발생하더라도 DB 단에서 안전하게 차단됩니다.

4. Gemini 모델 마이그레이션과 파라미터 최적화

초기에는 gemini-2.5-flash 모델로 워크플로우를 구성했으나, API 정책 변경으로 인해 에러를 마주했습니다.

"This model models/gemini-2.5-flash is no longer available to new users. Please update your code to use models/gemini-3.6-flash."

이에 gemini-3.7-flash로 교체했더니 이번에는 과부하(high demand) 에러가 발생했습니다. 최종적으로 **gemini-3.6-flash**로 정착하고, n8n 노드 설정에서 자동 재시도(Retry On Fail, 3회, 10초 간격)를 활성화하여 일시적 API 장애에 유연하게 대응하도록 구성했습니다.

또한 Gemini 3.6+ 버전부터는 파라미터 구조가 변경되었습니다.

// 변경 전 (2.5 버전)
"generationConfig": { 
  "temperature": 0.3, 
  "topP": 0.95, 
  "maxOutputTokens": 32768 
}

// 변경 후 (3.6+ 버전) - thinkingConfig 활용
"generationConfig": { 
  "maxOutputTokens": 32768, 
  "thinkingConfig": { "thinkingLevel": "low" } 
}

번역 작업은 높은 창의성을 요구하지 않으므로 thinkingLevel: "low"로 설정하여 토큰 소모와 응답 속도를 최적화했습니다.

5. n8n 표현식 파서와 JSON 중첩(Mobiledoc) 이슈 해결

Ghost Admin API에 게시물을 등록할 때 본문은 mobiledoc 형식의 JSON 문자열로 전달해야 합니다. 이때 HTTP Request 바디(JSON) 안에 또 다른 JSON 구조(mobiledoc)가 문자열로 들어가야 하는 상황이 발생합니다.

JSON.stringify 안에 또 JSON.stringify가 중첩되면 n8n의 표현식 파서가 invalid syntax 에러를 발생시킵니다. 이 문제는 IIFE(즉시 실행 함수)를 사용하여 해결할 수 있습니다.

={{ (function() {
  var md = $json.markdownContent || '';
  var mobiledoc = '{"version":"0.3.1","markups":[],"atoms":[],' +
    '"cards":[["markdown",{"markdown":' + JSON.stringify(md) + '}]],' +
    '"sections":[[10,0]]}';
  
  return JSON.stringify({
    posts: [{ title: $json.title, mobiledoc: mobiledoc }]
  });
})() }}

JavaScript 코드 블록 안에서 mobiledoc 문자열을 미리 안전하게 조립한 뒤, 최종 객체만 반환하게 하면 파서가 정상적으로 동작합니다.

📐 최종 워크플로우 아키텍처

두 파이프라인의 전체적인 노드 흐름은 아래와 같습니다.

VS Code 워크플로우 - 총 11노드

Claude Code 워크플로우 - 총 9노드

Claude Code의 노드 수가 2개 더 적은 이유는 피드 자체에 전체 변경 로그가 포함되어 있어, 본문을 가져오는 Fetch 작업과 추출 과정이 생략되기 때문입니다.

사용된 필수 환경 변수 (4개)

GEMINI_API_KEY=...
GHOST_ADMIN_API_KEY={id}:{secret}
SUPABASE_URL=https://xxx.supabase.co
SUPABASE_ANON_KEY=...

💡 마무리하며

이 파이프라인 프로젝트의 진정한 가치는 단순한 '자동화'를 넘어선 **'구조화'**에 있습니다.
Supabase에 체계적으로 발행 이력이 적재되면서, 각 소스별 발행 빈도, 번역된 콘텐츠의 길이 추이, API 실패율 등을 데이터 기반으로 한눈에 파악할 수 있게 되었습니다. 앞으로 새로운 RSS 소스를 추가하더라도 기존 워크플로우를 복제한 후 피드 URL과 필터 로직만 수정하면 되므로 확장성도 매우 뛰어납니다.

다음 단계로는 공식 RSS가 없는 Anthropic 뉴스 피드 등을 추가하거나, 릴리스 간 Diff를 비교하여 **"이번 버전에서 주목해야 할 핵심 변화"**만 짚어주는 스마트 요약 모드를 도입해 볼 계획입니다.

"반복 작업이 보이면 자동화하라. 단, 피드의 실제 데이터를 꼼꼼히 열어보고 나서."