AI가 소셜 계정에 접근하기 전에 모든 에이전시가 추가하는 n8n 노드

제가 n8n에서 보는 'AI가 소셜 게시물을 작성해주는' 워크플로우들은 대부분 비슷한 형태를 가지고 있습니다. 트리거(Trigger) → LLM 노드 → 그리고 바로 발행(Publish) 호출로 이어집니다. 데모에서는 훌륭하게 작동합니다. 하지만 일요일 아침 7시에 클라이언트의 LinkedIn에 플레이스홀더 링크가 포함된 초안을 게시하면, 누군가는 아주 힘든 월요일을 맞이하게 됩니다.

해결책은 지루합니다. 사람을 중간에 배치하고, 워크플로우가 그 사람을 건너뛰는 것을 물리적으로 불가능하게 만드는 것입니다.

제가 에이전시 팀과 사용하는 패턴입니다. 이는 바로 가져다 쓸 수 있는 템플릿(endpoints, credentials 및 승인 도구는 다를 것이므로)이라기보다는, 20분 만에 재구성할 수 있는 배선 가이드에 가깝습니다.

구조

1. 브리프가 들어옴 (Notion 트리거, 웹훅 또는 테스트 중 수동 트리거)
2. 예측 가능한 단일 객체로 정규화(Normalize)함
3. 브리프를 검증하고, 누락된 정보가 있으면 조기에 중단시킴
4. AI가 초안을 작성함 (사용하는 모델에 대한 HTTP Request)
5. 아무도 보기 전에 AI 출력을 확인함
6. 예약 게시물이 아닌, 스케줄링 도구의 **초안(draft)**으로 저장함
7. 검토자에게 알림(Ping)을 보냄
8. 결정을 기다림
9. 승인됨 / 거부됨 / 수정 필요에 따라 경로를 분기시킴(Route)
10. 승인된 항목만 스케줄 또는 발행 노드에 도달하게 함
11. 모든 것을 기록함(Log everything)

6단계부터 10단계까지가 핵심입니다. 나머지 모든 것은 배관 공사(plumbing)일 뿐입니다.

먼저 정규화하면 나중에 절약됩니다

Notion, 양식, Slack 메시지에서 온 브리프들은 모두 다르게 보입니다. 다른 어떤 것이 건드리기 전에 'Edit Fields' 또는 'Code' 노드를 사용하여 이들을 하나의 형태로 매핑해야 합니다. 예를 들면 다음과 같습니다:

{
  "briefId": "brief-001",
  "client": "acme",
...

그리고 briefId, client, channels, owner가 없으면 계속 진행하지 않는 IF 노드를 추가합니다. 까다롭게 들릴 수 있지만, 제가 디버깅했던 이상한 AI 출력 중 절반은 기본적으로 내용이 비어있는 브리프에서 비롯되었습니다.

단순 코드로 AI 출력을 확인하기

사람이 초안을 보기 전에, 명백한 것들을 찾는 작은 Code 노드를 실행합니다:

단순 코드로 AI 출력을 확인하기

사람이 초안을 보기 전에, 명백한 것들을 찾는 작은 Code 노드를 실행합니다:

• 해당 채널의 플랫폼 제한보다 긴 텍스트
• [LINK]나 {{name}}과 같은 남겨진 플레이스홀더
• 클라이언트가 허용하는 도메인 목록에 없는 링크
• 클라이언트가 금지한 단어 (모든 클라이언트는 목록을 가지고 있으니 요청하세요)

만약 실패하면, 이유와 함께 AI 단계로 다시 보내거나, 그냥 멈추고 소유자에게 알림을 보냅니다. 여기서 첫 번째 LLM의 출력을 판단하기 위해 또 다른 LLM이 필요하지 않습니다. 정규 표현식(regex)으로 대부분 처리할 수 있습니다.

초안 작성, 예약 금지

이것은 사람들이 건너뛰는 단계입니다. 어떤 도구가 게시를 하든, 워크플로우의 첫 번째 작업물은 예정된 게시물이 아니라 초안이나 보류 중인 항목을 생성해야 합니다. 만약 AI 노드와 워크플로우가 동시에 작동하지 않게 되어도, 최악의 경우 실시간으로 올라간 게시물이 아니라 지저분한 초안일 뿐입니다.

실제 게시(publish) 노드는 테스트하는 동안 비활성화 상태로 유지하세요. 말 그대로 n8n에서 토글을 꺼두는 것입니다. 마지막에 켜세요.

승인 게이트

n8n은 일시 중지할 수 있는 몇 가지 방법을 제공합니다: 웹훅(webhook)으로 재개되는 Wait 노드, n8n Form, 또는 버튼과 함께 Slack에 게시하는 하위 워크플로우입니다. 어떤 것이든 작동합니다. 중요한 것은 다음과 같습니다:

• 검토자가 정확한 최종 사본, 미디어, 채널 및 시간을 볼 수 있어야 합니다. 요약이 아닙니다.
• 결정은 세 가지 정확한 값 중 하나여야 합니다: approved, rejected, needs_revision. 자유 텍스트 필드에 대한 Switch 노드는

기록하기 (Log it)

마지막 노드는 간략한 ID(brief ID), AI 출력물, 수정 사항, 검토자, 결정 시간 및 게시 호출(publish call)의 응답을 기록 보관하는 곳에 작성합니다. Notion 데이터베이스, n8n Data Store, Postgres, 또는 Google Sheet 등 원하는 곳이 될 수 있습니다. 3개월 후에 고객이 '누가 이것을 승인했나요?'라고 물었을 때 10초 안에 답변할 수 있기를 바랍니다.

자격 증명 (Credentials)

말할 필요는 없지만 말씀드리겠습니다. 모델 키와 API 토큰은 n8n 자격 증명(credentials) 또는 환경 변수(env vars)에 보관해야 하며, 코드 노드(Code node)나 내보낸 JSON 파일에 절대 붙여넣으면 안 됩니다. 워크플로우를 공유할 때는 내보내서 키처럼 보이는 것이 있는지 grep 검색을 수행한 후 게시하세요. 하드 코딩된 비밀 정보가 포함된 템플릿은 n8n 갤러리에서 어차피 거부됩니다.

실제 적용 사례 (What this looks like in practice)

에이전시 팀에게 잘 작동하는 스택: Notion을 간략한 내용(briefs)용으로, 중앙에는 n8n을 두고, 초안 작성은 Claude를 사용하며, 검토자 알림은 Slack을 이용하고, 승인된 후 초안 보관 및 일정 관리는 ContentStudio가 담당합니다 (공개: 저는 ContentStudio에 근무하기 때문에 당연히 그곳을 선택했습니다). 이 중 어떤 것을 다른 것으로 교체해도 됩니다. 패턴 자체는 어떤 스케줄러를 사용하든 상관없으며, 단지 실제 초안 상태(real draft state)를 가지고 있고 AI 노드를 게시 엔드포인트(publish endpoint)에 직접 연결하지 않는다면 말입니다.

만약 여러분이 이와 비슷한 것을 구축했고 수정 루프(revision loop)를 처리하는 더 나은 방법을 찾았다면, 정말 듣고 싶습니다. 저의 방식은 아직 두 번째 라운드를 넘어서면 조금 투박하게 느껴집니다.