n8n + AI: LLM 워크플로우 구축 실전 가이드

'우리 서비스에도 AI 기능 붙여봐.' 기획자나 대표에게 이런 요청을 받으면 어디서부터 시작해야 할지 막막합니다. ChatGPT API 호출하는 건 어렵지 않은데, 실제 업무에 녹이려면 생각할 게 많거든요. 프롬프트는 어떻게 관리하지? 비용은 어떻게 추적하지? 에러 나면 어떻게 처리하지?

n8n이 그 문제를 꽤 잘 풀어줍니다. 오픈소스 워크플로우 자동화 플랫폼인데, 최근 AI/LLM 노드가 크게 강화됐습니다. 물론 '코드 없이 AI 에이전트를 만든다'는 마케팅 문구는 좀 과장입니다. 간단한 챗봇은 노드 몇 개로 뚝딱이지만, 프로덕션 수준의 파이프라인을 만들려면 LLM 동작 원리, 토큰 비용 관리, RAG 설계 같은 기본기가 필요하거든요.

이 글에서는 n8n으로 AI 워크플로우를 구축할 때 개발자가 알아야 할 것들을 정리합니다. LLM 연동 설정, 프롬프트 설계, RAG 파이프라인, AI Agent 노드, 비용 최적화까지. 직접 헤매면서 배운 것들을 담았습니다. 토큰 비용이 예상의 10배가 나와서 당황했던 경험, 에이전트가 엉뚱한 Tool을 호출해서 반나절을 날렸던 일까지. 공식 문서에는 안 나오는 우회법도 함께 공유합니다.

왜 n8n인가: 개발자 관점에서

AI 워크플로우 도구는 많습니다. Zapier AI, Make, LangChain 직접 코딩, 그리고 n8n. 각각 장단점이 있는데, 간단히 비교하면 이렇습니다. Zapier AI는 설정이 가장 쉽습니다. 다만 커스터마이징 한계가 명확하고, 비용이 빠르게 늘어납니다. Make는 시각적 빌더가 좋지만 AI 노드가 아직 n8n만큼 성숙하지 않았습니다. LangChain 직접 코딩은 유연성이 최고입니다. 대신 디버깅할 때 console.log 지옥에 빠지기 쉽죠.

n8n의 강점은 시각적 디버깅과 코드 하이브리드입니다. 각 노드의 입출력을 실시간으로 볼 수 있어서 어디서 문제가 생겼는지 바로 파악됩니다. 노코드로 안 되는 복잡한 로직은 JavaScript/Python Code 노드로 채우면 됩니다. 그리고 셀프호스팅이 가능합니다. 민감한 데이터를 다루는 환경에서도 쓸 수 있다는 뜻이죠. AWS, GCP, 온프레미스 어디든 Docker 하나로 띄울 수 있습니다.

n8n 1.82.0 버전부터는 AI Agent 노드가 'Tools Agent' 방식으로 통일됐습니다. 예전에는 여러 Agent 타입(Conversational, ReAct, OpenAI Functions 등) 중에서 선택해야 했는데, 이제는 하나로 정리됐습니다. 혼란이 줄었고, LangChain의 추상화 레이어를 그대로 가져왔기 때문에 LangChain 경험이 있으면 금방 적응합니다.

LLM 연동 설정: OpenAI vs Anthropic vs Gemini

n8n에서 LLM을 쓰려면 먼저 Credential을 등록해야 합니다. OpenAI, Anthropic, Gemini 모두 API 키 하나로 연동할 수 있는데, 각각 알아두면 좋은 점이 있습니다.

OpenAI 설정은 간단합니다. Settings > Credentials > OpenAI API에서 API 키를 입력하면 끝. 다만 Organization ID를 넣으면 해당 조직의 usage로 잡히니까, 여러 프로젝트/팀이 있다면 구분해서 관리하세요. Rate limit은 조직 단위로 적용되거든요.

Anthropic 설정도 비슷합니다. Anthropic Console에서 API 키 발급받고 n8n Credential에 입력하면 됩니다. Claude Opus 4, Claude Sonnet 4 등 최신 모델을 바로 쓸 수 있습니다. 예전에는 한국에서 API 호출이 제한되는 경우가 있었는데, 2025년 기준으로 한국은 공식 지원 국가에 포함되어 있어서 직접 호출이 가능합니다. 다만 중국, 러시아, 북한, 이란 등 일부 국가는 여전히 제한됩니다.

Google Gemini는 두 가지 경로가 있습니다. Google AI Studio에서 API 키를 발급받는 방법과, GCP의 Vertex AI를 통하는 방법. 전자는 빠르게 테스트할 때 좋고, 후자는 기업 환경에서 IAM/VPC 연동이 필요할 때 씁니다. Gemini만의 특징은 Safety Settings를 세밀하게 조절할 수 있다는 점입니다. 유해 콘텐츠 차단 수준을 카테고리별로 설정할 수 있어서, CS 챗봇 같은 용도에서 불필요한 필터링을 줄일 수 있습니다.

모델 선택은 유스케이스에 따라 달라집니다. 분류/라우팅 같은 단순 작업에는 GPT-4o-mini나 Gemini 2.0 Flash가 좋습니다. 둘 다 100ms 대 응답 속도에 비용이 저렴합니다. 복잡한 추론이나 긴 문서 처리에는 Claude Sonnet 4가 낫습니다. Instruction following 성능이 좋아서 구조화된 JSON 출력을 뽑을 때 실패율이 낮거든요. 실제로 한 프로젝트에서 GPT-4o로 JSON 출력을 뽑다가 파싱 실패율이 8%나 됐는데, Claude Sonnet 4로 바꾸니까 1% 미만으로 떨어졌습니다. 다만 속도는 GPT-4o-mini 대비 3~5배 느립니다. 트레이드오프를 고려해서 선택하세요.

프롬프트 엔지니어링 in n8n: 변수 활용하기

n8n의 AI 노드에서 프롬프트를 작성할 때 가장 중요한 건 표현식(Expression)을 통한 동적 변수 삽입입니다. 이전 노드의 출력값을 프롬프트에 주입할 수 있는데, 이게 n8n AI 워크플로우의 핵심입니다. 정적인 프롬프트가 아니라 런타임에 컨텍스트가 바뀌니까요.

// AI Agent 노드의 System Prompt 예시
당신은 {{ $json.company_name }}의 고객 지원 담당자입니다.

[역할]
- 고객 문의를 분류하고 적절한 부서로 라우팅합니다.
- 간단한 문의는 직접 답변합니다.
- 복잡한 문의는 티켓을 생성합니다.

[컨텍스트]
회사 정책 문서: {{ $json.policy_context }}
고객 이전 문의 내역: {{ $json.customer_history }}

[출력 형식]
반드시 아래 JSON 형식으로 응답하세요:
{
  "category": "billing|technical|general|escalate",
  "priority": "low|medium|high",
  "response": "고객에게 보낼 응답",
  "internal_note": "내부 메모 (선택)"
}

{{ $json.xxx }}가 n8n의 표현식 문법입니다. 이전 노드의 출력 데이터를 프롬프트에 삽입하는 방식이죠. $json은 직전 노드의 JSON 출력을, $('노드명').item.json은 특정 노드의 출력을 참조합니다. 복잡한 워크플로우에서는 후자를 많이 씁니다.

프롬프트 설계 팁 몇 가지를 공유합니다. 첫째, 시스템 프롬프트는 300토큰 이하로 유지하세요. 시스템 프롬프트는 매 호출마다 입력 토큰에 포함됩니다. 하루에 1만 건 호출하는 워크플로우라면, 시스템 프롬프트 100토큰 줄이는 게 월 수십 달러 차이를 만듭니다. 변하지 않는 긴 지시사항은 RAG로 빼세요.

둘째, JSON 출력 형식을 명시하고 스키마를 검증하세요. 프롬프트에 JSON 형식을 지정해도 LLM이 가끔 형식을 어깁니다. 특히 긴 출력을 요청하면 중간에 잘리거나, 마크다운 코드블록으로 감싸서 내보내는 경우가 있습니다. 한번은 이걸 몰라서 '정상 동작하다가 가끔 실패하는' 버그를 잡느라 하루를 날린 적도 있습니다. n8n의 IF 노드로 JSON.parse() 성공 여부를 체크하고, 실패하면 재시도하거나 폴백 처리하는 분기를 넣어두세요. 프로덕션에서 이거 안 해두면 워크플로우가 멈춥니다.

셋째, Few-shot 예시는 2~3개가 적당합니다. 예시가 많으면 토큰만 먹고 성능 향상은 미미합니다. 특히 분류 작업에서는 각 카테고리별로 하나씩 예시를 넣어주면 정확도가 확 올라갑니다. 예시 없이 분류하면 경계 케이스에서 LLM이 흔들리거든요.

RAG 파이프라인 구축: Pinecone vs Supabase

프롬프트 설계를 했으니 이제 RAG 이야기를 해야겠네요. 시스템 프롬프트를 짧게 유지하라고 했는데, 그럼 회사 정책이나 FAQ 같은 긴 컨텍스트는 어디에 넣을까요? 바로 RAG(Retrieval-Augmented Generation)입니다. 전체 문서를 다 넣는 대신, 질문과 관련된 부분만 검색해서 프롬프트에 넣는 패턴이죠.

n8n에서 RAG를 구축하려면 벡터 DB가 필요합니다. n8n이 네이티브로 지원하는 건 Pinecone, Supabase(pgvector), Qdrant, Weaviate 등이 있는데, 현실적으로 많이 쓰는 건 Pinecone과 Supabase입니다.

• Pinecone: 완전 관리형이라 세팅이 빠릅니다. 5분이면 인덱스 만들고 데이터 넣을 수 있어요. 단점은 비용(월 $70~ 시작)과 메타데이터 필터링 제약입니다. 날짜 필터링하려면 UNIX 타임스탬프로 변환해야 하고, 복잡한 조건 쿼리가 좀 제한적입니다.
• Supabase: pgvector 기반이라 PostgreSQL 쿼리 그대로 씁니다. 이미 Supabase 쓰고 있으면 추가 비용 없이 바로 적용 가능합니다. 다만 인덱스 튜닝(HNSW vs IVFFlat)을 직접 해야 해서 초기 세팅이 좀 더 손이 갑니다.

추천을 정리하면: 빠르게 MVP 만들고 싶으면 Pinecone, 이미 PostgreSQL/Supabase 쓰고 있거나 복잡한 메타데이터 필터링이 필요하면 Supabase입니다. 어차피 n8n 노드 바꾸는 건 어렵지 않으니까 나중에 마이그레이션해도 됩니다.

// RAG 데이터 인제스션 워크플로우 예시 (Code 노드)
// Google Drive에서 문서를 가져와 Pinecone에 저장

const documents = $input.all();

// 문서를 청크로 분할
function chunkText(text, chunkSize = 1000, overlap = 200) {
  const chunks = [];
  let start = 0;

  while (start < text.length) {
    const end = Math.min(start + chunkSize, text.length);
    chunks.push({
      text: text.slice(start, end),
      start_index: start
    });
    start += chunkSize - overlap;
  }

  return chunks;
}

// 각 문서를 청크로 분할하고 메타데이터 추가
const chunkedDocs = documents.flatMap(doc => {
  const chunks = chunkText(doc.json.content);
  return chunks.map((chunk, idx) => ({
    json: {
      text: chunk.text,
      metadata: {
        source: doc.json.filename,
        chunk_index: idx,
        // Pinecone용 UNIX 타임스탬프 변환
        created_at: Math.floor(new Date(doc.json.created_at).getTime() / 1000),
        category: doc.json.category
      }
    }
  }));
});

return chunkedDocs;

RAG 파이프라인은 보통 두 개의 워크플로우로 분리합니다. 인제스션 워크플로우(문서를 청킹 -> 임베딩 -> 벡터 DB 저장)와 검색 워크플로우(질문 임베딩 -> 유사 문서 검색 -> LLM에 컨텍스트로 전달)입니다. 위 코드는 청킹까지만 보여주는데, 실제로는 이 다음에 Embeddings OpenAI 노드(또는 다른 임베딩 모델)를 연결해서 각 청크를 벡터로 변환하고, Pinecone 노드나 Supabase Insert 노드로 저장합니다. n8n UI에서 Code 노드 출력을 Embeddings 노드 입력에 드래그해서 연결하면 됩니다. 인제스션은 문서가 추가/수정될 때 트리거되고, 검색은 사용자 요청마다 실행됩니다. 각각 별도 워크플로우로 만들어서 관리하는 게 깔끔합니다.

AI Agent 노드 제대로 활용하기

n8n의 AI Agent 노드는 단순한 LLM 호출이 아닙니다. Tool을 호출하고, 결과를 분석하고, 다음 행동을 결정하는 ReAct 패턴 에이전트를 노드 하나로 만들 수 있습니다. LangChain으로 직접 짜면 수십 줄인 걸 노드 연결로 끝낼 수 있죠.

AI Agent 노드의 핵심은 Tool 연결입니다. 웹 검색, DB 조회, HTTP API 호출, 심지어 다른 n8n 워크플로우까지 Tool로 연결할 수 있습니다. 에이전트는 사용자 요청을 분석해서 어떤 Tool을 쓸지 스스로 결정합니다. n8n UI에서는 AI Agent 노드 아래에 Tool 노드들을 드래그해서 연결하면 됩니다.

예를 들어 '데이터 분석 도우미' 에이전트를 만든다고 하면, DB 조회 Tool(Postgres 노드), 웹 검색 Tool(HTTP Request + SerpAPI), 알림 Tool(Slack 노드)을 연결합니다. 사용자가 '지난달 매출 알려줘'라고 하면 에이전트가 DB 조회 Tool을 호출하고, '최신 AI 트렌드 알려줘'라고 하면 웹 검색 Tool을 호출하는 식입니다. 여기서 중요한 건 각 Tool의 description입니다. 에이전트는 description을 보고 어떤 Tool을 쓸지 결정하거든요. 한번은 'DB에서 데이터를 가져옵니다'라고만 썼다가, 에이전트가 웹 검색이 필요한 질문에도 계속 DB Tool을 호출해서 반나절을 헤맸습니다. 'PostgreSQL 데이터베이스에서 매출, 주문, 고객 데이터를 조회합니다. 외부 뉴스나 트렌드 정보는 이 도구로 얻을 수 없습니다'처럼 명확하게 써야 합니다.

실무에서 AI Agent를 쓸 때 가장 중요한 건 권한 제한입니다. 에이전트의 자율성은 양날의 검이거든요. 이메일 발송, 결제, 데이터 삭제 같은 중요한 액션에는 반드시 Human-in-the-loop 승인 단계를 넣으세요. n8n에서는 Wait 노드로 사람의 승인을 기다리게 할 수 있습니다. 에이전트가 '이메일 보낼게요'라고 하면 Wait에서 멈추고, 담당자가 확인 후 승인하면 진행되는 식입니다.

Memory 설정도 비용과 직결됩니다. Buffer Window Memory는 최근 N개의 대화만 기억합니다. 10개면 10개, 그 이전 대화는 사라집니다. 긴 대화가 필요하면 Summary Memory(이전 대화를 LLM이 요약해서 저장)를 쓰거나, 중요한 정보만 별도 DB에 저장하는 패턴을 씁니다. Memory가 길어지면 매 호출마다 토큰을 먹으니까, window_size를 5~10 정도로 시작해서 필요에 따라 조절하세요.

비용 최적화 전략: 토큰 관리와 캐싱

AI 워크플로우에서 비용 관리는 프로덕션 배포 전에 반드시 고려해야 합니다. 개발 환경에서 하루 100건 테스트할 때는 몇 달러지만, 프로덕션에서 하루 1만 건 처리하면 월 수백~수천 달러가 나갑니다. 미리 계산하고, 최적화 전략을 세워두세요.

1. 모델 캐스케이딩: 모든 요청에 GPT-4o를 쓸 필요 없습니다. 먼저 GPT-4o-mini로 요청을 분류하고(분류 작업은 저렴한 모델로 충분합니다), 복잡한 요청만 상위 모델로 라우팅하세요. Switch 노드로 분기하면 됩니다. 경험상 50~70% 요청이 간단한 분류로 끝나서, 비용을 절반 이하로 줄일 수 있습니다.

2. 응답 캐싱: LLM은 같은 입력에 (거의) 같은 출력을 냅니다. 자주 들어오는 질문이 있다면 캐싱하세요. n8n의 Static Data나 Redis 노드를 활용할 수 있습니다. 아래 코드처럼 입력을 해시해서 캐시 키로 쓰고, TTL을 1시간 정도로 설정합니다. 처음에는 '캐싱까지 필요할까?' 싶었는데, FAQ 봇을 운영해보니 캐시 히트율이 40~60%까지 나왔습니다. 토큰 비용이 예상의 10배가 나왔던 경험 이후로는 캐싱을 기본으로 넣습니다.

// 응답 캐싱 로직 - 캐시 체크 (Code 노드 1)
const crypto = require('crypto');

function generateCacheKey(input) {
  const normalized = JSON.stringify({
    prompt: input.prompt,
    system: input.system_prompt,
    model: input.model
  });
  return crypto.createHash('md5').update(normalized).digest('hex');
}

const cacheKey = generateCacheKey($input.item.json);
const staticData = await this.getStaticData();
const cached = staticData[cacheKey];

if (cached && Date.now() - cached.timestamp < 3600000) { // 1시간 TTL
  return [{ json: { ...cached.response, cached: true } }];
}

// 캐시 미스 - LLM 노드로 진행
return [{ json: { ...$input.item.json, cacheKey, shouldCache: true } }];

// -------------------------------------------
// LLM 응답 후 캐시 저장 (Code 노드 2 - LLM 노드 다음에 연결)
// -------------------------------------------
const staticData = await this.getStaticData();
const { cacheKey, shouldCache, ...response } = $input.item.json;

if (shouldCache && cacheKey) {
  staticData[cacheKey] = {
    response,
    timestamp: Date.now()
  };
  // 오래된 캐시 정리 (100개 초과 시)
  const keys = Object.keys(staticData);
  if (keys.length > 100) {
    const oldest = keys.sort((a, b) =>
      staticData[a].timestamp - staticData[b].timestamp
    )[0];
    delete staticData[oldest];
  }
}

return [{ json: response }];

3. 시스템 프롬프트 최적화: 앞서 말한 내용의 반복이지만 중요해서 다시 강조합니다. 시스템 프롬프트는 매 호출마다 토큰을 소비합니다. 긴 컨텍스트(회사 정책, 스타일 가이드 등)는 RAG로 빼고, 시스템 프롬프트에는 역할 정의와 출력 형식만 넣으세요.

4. 배치 API 활용: 실시간 응답이 필요 없는 작업(보고서 생성, 대량 분류 등)은 배치 API를 쓰세요. OpenAI Batch API는 동일 작업 대비 50% 저렴합니다. n8n에서는 요청을 Queue에 쌓아두고, Schedule Trigger로 정해진 시간에 배치 처리하는 패턴을 씁니다.

실전 예시: 이메일 분류 및 자동 응답

지금까지 설명한 내용을 종합해서 실전 예시를 하나 만들어봅시다. 가장 흔하면서도 효과가 바로 보이는 유스케이스인 이메일 자동 분류입니다. Gmail로 들어오는 이메일을 AI로 분류하고, 카테고리별로 다른 처리를 하는 워크플로우입니다.

// 이메일 분류기 시스템 프롬프트
당신은 이메일 분류 전문가입니다.

[분류 기준]
- urgent_support: 긴급한 기술 문제 또는 서비스 장애
- billing: 결제, 환불, 구독 관련
- feature_request: 기능 제안 또는 개선 요청
- general_inquiry: 일반 문의
- spam: 스팸 또는 무관한 이메일

[입력]
제목: {{ $json.subject }}
발신자: {{ $json.from }}
본문:
{{ $json.body }}

[출력 형식]
{
  "category": "카테고리명",
  "confidence": 0.0-1.0 사이 확신도,
  "summary": "이메일 내용 1줄 요약",
  "suggested_response": "카테고리가 general_inquiry일 경우만 응답 초안",
  "priority": "high|medium|low"
}

워크플로우 구조는 이렇습니다: Gmail Trigger -> OpenAI Chat Model (분류) -> Switch (카테고리별 분기) -> 각 카테고리별 처리. urgent_support는 슬랙 알림과 함께 즉시 담당자에게 할당하고, billing은 Stripe API로 고객 정보를 조회한 뒤 응답을 생성합니다. spam은 라벨만 붙이고 넘기고요.

여기서 GPT-4o-mini를 쓰는 이유는 분류 작업이기 때문입니다. 복잡한 추론이 필요 없고, 속도와 비용이 중요합니다. 프롬프트에 Few-shot 예시를 2~3개 넣어두면 정확도가 95% 이상 나옵니다. 이메일당 비용은 약 0.001달러(입력 ~500토큰 + 출력 ~100토큰 기준) 이하입니다.

Switch 노드에서는 LLM 출력의 category 필드를 기준으로 분기합니다. JSON 출력이 가끔 깨지는 경우가 있으니, Switch 전에 IF 노드로 JSON 파싱 성공 여부를 체크하고, 실패 시 기본 카테고리(general_inquiry)로 보내는 폴백 로직을 넣어두세요.

이 패턴을 응용하면 다양한 워크플로우를 만들 수 있습니다. RAG 문서 봇(회사 문서를 벡터 DB에 인덱싱해두고 질문에 답변), GitHub PR 코드 리뷰(PR diff를 분석해서 코멘트 자동 작성), 미팅 요약(녹음 파일을 트랜스크립트하고 핵심 내용 정리) 등. 기본 구조는 같습니다: Trigger -> LLM 처리 -> 후속 액션.

정리: n8n AI 워크플로우 체크리스트

지금까지 n8n으로 AI 워크플로우를 구축하는 방법을 살펴봤습니다. 노드 연결하는 건 금방입니다. 진짜 어려운 건 프로덕션에서 안정적으로, 비용 효율적으로 운영하는 것입니다. 핵심 포인트를 정리합니다.

1. 모델 선택: 작업 복잡도에 맞게. 분류/라우팅은 GPT-4o-mini, 복잡한 추론이나 긴 문서는 Claude Sonnet 4.
2. 프롬프트 설계: JSON 출력 형식 명시, 시스템 프롬프트 300토큰 이하, Few-shot 예시 2~3개.
3. 에러 핸들링: JSON 파싱 실패 대비 폴백, Rate limit 대비 재시도 로직, 타임아웃 설정.
4. 비용 관리: 모델 캐스케이딩, 응답 캐싱, 토큰 사용량 모니터링 및 알림.
5. 에이전트 권한: 중요한 액션에 Human-in-the-loop, Tool 범위 최소화.

글 처음에 'AI 기능 붙여봐'라는 요청을 받으면 막막하다고 했는데요. n8n을 쓰면 그 막막함이 확 줄어듭니다. 이제 그 요청을 받아도 30분 안에 동작하는 프로토타입을 보여줄 수 있습니다. 하지만 '코드 없이'라는 말에 속으면 안 됩니다. LLM의 특성을 이해하고, 프롬프트를 잘 설계하고, 비용을 관리하는 건 여전히 개발자 몫입니다. n8n은 그 과정을 시각적으로 보여주고, 디버깅을 쉽게 해줄 뿐입니다.

다만 MVP를 만드는 것과 프로덕션에 배포하는 것 사이에는 꽤 큰 간극이 있습니다. 트래픽이 늘어나면 n8n 인스턴스 스케일링 문제가 생기고, 워크플로우가 복잡해지면 디버깅이 어려워지고, LLM 응답이 불안정해지면 사용자 경험이 나빠집니다. 실제로 저도 데모에서 잘 돌아가던 워크플로우가 프로덕션에서 하루에 수십 건씩 실패해서 야근했던 경험이 있습니다. Rate limit, 타임아웃, 예외 케이스 처리... 생각보다 신경 쓸 게 많습니다.

그래서 AI 워크플로우를 제대로 운영하려면 모니터링과 장애 대응 체계도 함께 구축해야 합니다. 단순히 '돌아가게 만드는 것'과 '안정적으로 운영하는 것'은 다른 영역이거든요. 처음부터 완벽하게 만들려고 하지 말고, 빠르게 시작해서 점진적으로 개선하되, 프로덕션 전환 시점에는 충분한 검증과 준비가 필요합니다. 그게 AI 자동화를 실무에 적용하는 현실적인 방법입니다.