20. 실전 n8n: 메모리·도구·앱 연동·프로덕션

비유로 시작하기: 기본 봇에 능력을 더하기

19장의 요약 봇은 똑똑하지만 단발성입니다. 대화를 기억하지 못하고, 외부 정보를 모르며, 결과를 다른 시스템에 넘기지도 못합니다. 이번 장은 그 봇에 기억(메모리), 손발(도구·앱 연동), 규격(구조화 출력), 안전장치(승인)를 차례로 달아 실전 워크플로로 키웁니다. 1~6부에서 코드로 했던 일을, n8n에서는 서브 노드를 연결해 합니다.

메모리 달기

AI Agent 노드에 Memory 서브 노드를 연결하면 대화 맥락이 유지됩니다. n8n은 여러 메모리 종류를 제공하니 용도에 맞게 고릅니다.

참고: Redis는 데이터를 메모리에 두어 매우 빠르게 읽고 쓰는 데이터베이스로, 빠른 응답이 필요한 세션·캐시 저장에 자주 쓰입니다.

⚠️ 흔한 실수: 프로덕션에서 Simple Memory를 쓰는 것. Simple Memory는 n8n을 재시작하거나 워크플로를 저장하면 사라집니다. 사용자 연속성이 필요하면 세션ID로 분리되는 Postgres Chat Memory를 쓰세요. "메모리 손실" 버그로 몇 주를 허비하는 흔한 함정입니다.

📌 핵심: 4장(메모리)·13장(단기/장기 메모리)에서 배운 개념이 그대로입니다. Window Buffer는 슬라이딩 윈도우, Summary는 요약 전략, Postgres는 영속 저장에 해당합니다. n8n은 이를 노드 선택만으로 바꿉니다.

도구와 검색 달기

AI Agent 노드의 Tool 커넥터에 도구를 연결합니다. 웹 검색, HTTP 요청(내부 API 호출), 벡터 스토어(RAG) 등을 붙일 수 있습니다. 여기서 벡터 스토어는 문서를 의미 기반으로 검색할 수 있게 숫자 벡터(임베딩)로 변환해 저장하는 데이터베이스이고, RAG(Retrieval-Augmented Generation, 검색 증강 생성)는 질문과 관련된 문서 조각을 검색해 그때그때 모델에 넣어주는 기법입니다(자세한 내용은 21장).

flowchart TB
    classDef agent fill:#80DEEA,stroke:#00838F,color:#000
    classDef tool fill:#90CAF9,stroke:#1565C0,color:#000
    classDef mem fill:#A5D6A7,stroke:#2E7D32,color:#000

    AG[AI Agent 노드]:::agent
    S[웹 검색 도구]:::tool
    H[HTTP 요청 도구<br/>내부 API]:::tool
    V[벡터 스토어 도구<br/>RAG 지식베이스]:::tool
    M[Postgres Memory]:::mem

    S --> AG
    H --> AG
    V --> AG
    M --> AG

💡 팁: 실시간 데이터가 필요하면 HTTP 요청 도구를 내부 API에 연결합니다. 에이전트가 쿼리 파라미터를 채워 호출하고 구조화된 데이터를 받습니다. $fromAI() 표현식으로 도구 파라미터를 AI가 동적으로 채우게 할 수도 있습니다.

외부 앱 연동: Sheets·Calendar·Gmail

n8n의 강점은 500개 이상의 앱 노드입니다. 강의에서 다루는 Google Sheets·Calendar·Gmail 연동이 대표적입니다. 이들을 도구로 붙이면 에이전트가 스프레드시트에 기록하고, 일정을 잡고, 메일을 보낼 수 있습니다.

예를 들어 "회의 일정 자동화" 워크플로는 이렇게 구성됩니다. 채팅으로 일정 요청을 받고, AI Agent가 날짜·참석자를 파악해 Google Calendar 노드로 이벤트를 만들고, Gmail 노드로 확인 메일을 보냅니다. 코드 한 줄 없이 노드 연결만으로 완성됩니다.

📌 핵심: 5장에서 도구를 "직접 코딩"했고 6부에서 "MCP로 표준화"했다면, n8n은 "이미 만들어진 앱 노드를 연결"합니다. 가장 빠른 통합 방식이지만, n8n이 지원하는 앱 범위 안에서만 가능하다는 제약이 있습니다.

구조화 출력 파서

에이전트 결과를 다음 노드에서 분기·라우팅에 쓰려면 정해진 형식이 필요합니다. AI Agent 노드에서 Require Specific Output Format을 켜고 Structured Output Parser를 연결하면, 결과가 검증된 JSON으로 나옵니다.

flowchart LR
    classDef agent fill:#80DEEA,stroke:#00838F,color:#000
    classDef parse fill:#90CAF9,stroke:#1565C0,color:#000
    classDef route fill:#FFE082,stroke:#F9A825,color:#000
    classDef out fill:#A5D6A7,stroke:#2E7D32,color:#000

    A[AI Agent<br/>리드 평가]:::agent --> P[Output Parser<br/>JSON 필드 추출]:::parse
    P --> R{Switch 노드<br/>분기}:::route
    R -->|hot| H[Slack 알림]:::out
    R -->|nurture| E[이메일 시퀀스]:::out

이것이 n8n 에이전트의 핵심 패턴입니다. 모델이 하나의 판단(리드가 hot인가?)을 내리고, 출력 파서가 그것을 필드로 만들고, 일반 워크플로 노드(Switch)가 결과에 따라 라우팅합니다. 7장(output_type)·16장(output_pydantic)과 같은 아이디어가 노드로 구현된 것입니다.

💡 실습 아이디어(강의의 구조화 출력 대응): 고객 문의를 받아 {category, urgency, summary} 형식으로 분류하는 에이전트를 만들고, Switch 노드로 urgency가 high면 즉시 Slack, 아니면 시트에 기록하도록 분기해 보세요.

휴먼 승인

민감한 작업(메일 발송, 레코드 수정, 데이터 삭제)은 사람의 승인을 받아야 합니다. n8n은 도구에 Human review 단계를 붙일 수 있습니다. AI가 게이트된 도구를 쓰려 하면 워크플로가 일시정지하고, 선택한 채널(채팅·Slack·Telegram 등)로 승인 요청을 보냅니다.

⚠️ 보안 원칙: 외부로 나가거나 되돌릴 수 없는 작업에는 반드시 승인 게이트를 두세요. 13장(LangGraph interrupt)·18장(MCP 승인 정책)과 동일한 휴먼 인 더 루프 원칙입니다.

프로덕션 운영 원칙

n8n을 실서비스로 운영할 때의 핵심을 정리합니다.

📌 핵심: 프로덕션 에이전트는 "AI가 똑똑한가"보다 "실패해도 안전하게 실패하는가"가 중요합니다. n8n의 재시도·폴백·승인·실행 이력이 이 안전성을 받쳐 줍니다. 한 지원팀 사례에서는 n8n 에이전트가 1차 티켓의 약 31%를 자동 해결하고 나머지는 요약과 함께 사람에게 넘겼습니다.

💡 팁: AI Agent 노드에 Fallback Model을 연결하면, 주 모델이 실패하거나 사용 불가일 때 백업 모델로 자동 전환됩니다. 프로덕션 안정성의 기본기입니다.

이 장에서 배운 것

• 메모리는 용도별로 고른다. 개발은 Simple, 프로덕션은 세션ID로 분리되는 Postgres를 쓴다.
• 도구는 Tool 커넥터로, 외부 앱은 500+ 앱 노드로 연결한다. 가장 빠른 통합 방식이다.
• 구조화 출력 파서 + Switch 노드가 "판단→필드→라우팅"이라는 n8n 에이전트 핵심 패턴을 이룬다.
• 민감 작업엔 휴먼 승인 게이트를 두고, 영속 메모리·반복 제한·폴백 모델로 프로덕션 안정성을 확보한다.

✍️ 확인 문제

1. 프로덕션 고객 봇에 Simple Memory를 쓰면 어떤 문제가 생기며, 올바른 대안은?
2. "판단 → 필드 → 라우팅" 패턴에서 각 단계를 담당하는 n8n 노드를 짝지어라.
3. 되돌릴 수 없는 작업(예: 데이터 삭제)을 에이전트가 수행하기 전에 n8n에서 둘 수 있는 안전장치는?

이전 장: 19. n8n 입문
다음 부: 8부 · 프로덕션과 베스트 프랙티스 — 모든 도구에 공통으로 적용되는 프롬프팅·비용·보안·트러블슈팅을 정리합니다.