n8n Human in the Loop 템플릿 — AI가 쓴 답장, 사람이 승인해야 나간다

n8n.io 공식 템플릿 마켓플레이스에 공개된 이 워크플로우를 가져오면, 메일함에 새 메일이 도착했을 때 AI가 요약과 답장 초안까지 자동으로 만들고, 승인자가 그 초안을 확인해 승인해야만 실제 발신자에게 메일이 나가는 이메일 응대 구조를 만들 수 있습니다. 이 시리즈에서 지금까지 다룬 템플릿은 트리거가 울리면 사람 손을 거치지 않고 끝까지 자동으로 완결됐는데, 이번 템플릿은 처음으로 그 흐름 한가운데에 사람을 세워둡니다.

이 템플릿 하나로 보여줄 수 있는 것

"AI가 고객 메일에 자동으로 답장한다"고 말하면 면접관이 바로 되묻는 질문이 있습니다. "그럼 AI가 이상한 소리를 하면 어떻게 막나요?" 지금까지 이 시리즈에서 본 템플릿들은 이 질문에 뾰족한 답이 없었습니다. 트리거가 울리면 문서가 색인되고, 리드가 쌓이고, 알림이 나가는 흐름 전부가 사람 확인 없이 끝까지 자동으로 도는 구조였기 때문입니다. 이 템플릿은 다릅니다. "AI가 답장을 쓰지만, 사람이 승인해야만 나갑니다"라고 답할 수 있습니다.

문장 하나지만 안에 들어간 역량은 세 가지입니다.

• AI 초안 파이프라인 — 긴 메일 본문을 요약하고, 그 요약을 근거로 답장 초안을 자동 생성하는 두 단계 체인을 구성한 경험
• 승인 게이트 설계 — 흐름 한가운데 조건 분기 노드를 두고, 사람의 승인 여부에 따라 다음 단계로 갈지 여기서 멈출지를 명시적으로 나눈 경험
• 실패 안전 설계 — 승인이 나지 않으면 자동으로 발송되지 않게 막아, AI의 실수가 곧바로 고객에게 나가는 사고를 구조적으로 차단한 경험

이 세 가지가 중요한 이유는 간단합니다. AI 자동화 프로젝트가 실제 운영에 들어가지 못하고 데모 단계에서 멈추는 가장 흔한 이유가 "AI가 틀리면 누가 책임지나"라는 질문이기 때문입니다. 모든 자동화가 끝까지 사람 손 없이 도는 게 정답이 아니라, 되돌리기 어려운 액션 앞에 확인 단계를 넣는 것도 설계의 일부라는 걸 보여주는 템플릿이 바로 이것입니다. 이 판단력은 이메일 응대뿐 아니라 계약서 발송, 결제 처리, SNS 게시물 업로드처럼 "AI가 잘못 만들면 되돌리기 번거로운" 모든 작업에 그대로 적용됩니다.

이 템플릿은 무엇인가

이 워크플로우는 데이터팝콘이 만든 게 아닙니다. n8n 공식 템플릿 마켓플레이스(n8n.io/workflows)에 A very simple "Human in the Loop" email response system using AI and IMAP라는 이름으로 공개된 템플릿이고, 제작자는 Davide Boizza입니다. 카테고리는 Ticket Management와 Multimodal AI로 등록돼 있어서, 고객 문의 대응 자동화를 찾아보다가 마주치는 경우가 많은 템플릿입니다.

공식 설명에 따르면 이 템플릿은 IMAP 이메일 서비스(Gmail, Outlook 등)로 들어오는 메일을 자동으로 요약하고, AI 모델로 적절한 답장을 생성한 뒤, 그 답장을 "Human-in-the-Loop" 시스템으로 검증받는 워크플로우입니다. 모든 AI 생성 답장이 발송 전에 사람의 검토를 거치도록 만들어져 있어서, 이메일이 많이 몰리지만 답장 품질은 놓칠 수 없는 업무에 맞춰 설계됐다고 소개돼 있습니다.

n8n 설치나 기본 노드 조작법은 n8n으로 반복업무 자동화 포트폴리오 만들기에 정리돼 있으니, 이 글은 이 템플릿의 승인 게이트 구조 자체에 집중합니다.

구조 — Trigger / Task / Target

공식 문서의 "How it works" 6단계를 데이터팝콘 방식인 Trigger/Task/Target 세 칸으로 정리하면 이렇습니다. 이 템플릿의 핵심은 Task 중간에 사람이 개입하는 지점이 명시적인 분기 노드로 박혀 있다는 점입니다.

• Trigger — Email Trigger(IMAP) 노드가 메일함을 감시하다가 새 메일이 도착하면 흐름을 시작합니다.
• Task — 메일 본문을 텍스트로 정리(Markdown) → 100단어 이내로 요약(Email Summarization Chain) → 100단어 이내 답장 초안 작성(Write email) → 승인용 텍스트 준비(Set Email text) → 승인자에게 원본 메일과 AI 초안을 함께 담아 승인 요청 메일 발송(Approve Email) → 승인 여부 확인(Approved?)까지가 Task입니다. 여기서 흐름이 둘로 갈립니다.
• Target — 승인되면 Send Email 노드가 원래 발신자에게 최종 답장을 보냅니다. 승인되지 않으면 공식 설명대로 "그렇지 않으면 멈춘다(otherwise stops)"는 원칙에 따라 여기서 흐름이 끝나고, 메일은 나가지 않습니다.

만들기

이 템플릿의 공식 페이지에는 번호가 매겨진 별도의 Setup 섹션이 없습니다. 대신 "How it works"의 6단계 설명 안에 무엇을 준비해야 하는지가 그대로 녹아 있어서, 이 6단계를 순서대로 따라가며 준비물을 정리하는 방식으로 재구성했습니다.

1. IMAP 수신함 연결

Email Trigger(IMAP) 노드에 메일함 자격 증명을 연결합니다. 공식 설명에는 Gmail, Outlook 등 IMAP을 지원하는 서비스를 예로 들고 있습니다. 두 서비스 모두 계정 설정에서 IMAP 접근을 별도로 허용해야 하는 경우가 많으니, 트리거를 처음 실행하기 전에 메일함 쪽 IMAP 설정부터 확인해두는 게 안전합니다.

2. 본문을 AI가 읽기 좋은 형태로

Markdown 노드가 메일의 HTML 본문을 일반 텍스트로 바꿉니다. 사람이 보는 메일은 서식이 섞인 HTML이지만, 다음 단계에서 AI에게 넘길 입력은 서식 없는 텍스트가 다루기 쉽기 때문에 이 변환 단계가 따로 들어가 있습니다.

3. 요약 — Email Summarization Chain

이 노드가 OpenAI를 사용해 메일 내용을 100단어 이내, 전문적인 톤으로 요약합니다. 메일이 길어도 승인자가 나중에 확인할 때 핵심만 빠르게 읽을 수 있게 하는 단계입니다.

4. 답장 초안 — Write email

역시 OpenAI를 사용해 메일 내용을 바탕으로 100단어 이내의 전문적인 답장 초안을 작성합니다. 요약과 초안 둘 다 같은 단어 수 제한을 두고 있어서, 이 템플릿은 애초에 "짧고 명확한 응대"를 목표로 설계됐다는 걸 알 수 있습니다.

5. 사람 승인 게이트 — Set Email text → Approve Email → Approved?

여기가 이 템플릿의 핵심입니다. Set Email text 노드가 앞서 만든 답장 초안을 승인 요청용 형태로 정리하면, Approve Email 노드가 원본 메일과 AI가 작성한 답장 초안을 함께 담아 승인자(내부 담당자 이메일 등)에게 검토 요청 메일을 보냅니다. 이후 Approved? 노드가 승인 여부를 확인해, 승인됐으면 다음 단계로 넘기고 아니면 흐름을 멈춥니다.

한 가지 밝혀둘 부분이 있습니다. 공식 페이지 텍스트에는 승인자가 정확히 어떤 방식으로 "승인했다"는 신호를 남기는지까지는 나와 있지 않습니다. 직접 이 템플릿을 만들 때는 승인 요청 메일에 회신하게 할지, 별도의 승인 링크나 폼을 둘지, 승인 결과를 저장할 값을 어디에 둘지를 스스로 정해야 하는 부분이라는 뜻입니다.

6. 승인된 답장만 발송 — Send Email

Approved? 노드에서 승인으로 판정된 경우에만 Send Email 노드가 실행돼 원래 발신자에게 최종 답장이 나갑니다. 승인되지 않은 메일은 이 노드까지 도달하지 않습니다.

주의할 점 · 제약

공식 문서에서 확인되는 제약과, 직접 구현할 때 스스로 메워야 하는 빈틈을 나누면 이렇습니다.

• 답장 길이가 100단어로 고정돼 있다 — 요약과 초안 모두 100단어 이내로 제한돼 있습니다. 정중하지만 짧은 응대에는 맞지만, 상세한 설명이 필요한 문의라면 이 제한을 먼저 조정해야 합니다.
• 승인 판정 방식이 공식 텍스트에 명시돼 있지 않다 — 앞서 5단계에서 밝힌 대로, Approved? 노드가 무엇을 근거로 승인/거부를 판단하는지는 확인되지 않았습니다. 그대로 가져와도 이 부분은 자신의 메일 환경에 맞춰 직접 설계해야 합니다.
• AI 단계가 OpenAI에 고정돼 있다 — Email Summarization Chain과 Write email 노드 모두 OpenAI를 사용합니다. 다른 모델로 바꾸려면 두 노드를 각각 수정해야 합니다.
• IMAP 계정이 전제 조건이다 — Gmail이나 Outlook을 그대로 쓰려면 계정 쪽에서 IMAP 접근을 허용해야 트리거가 정상 동작합니다.

포트폴리오·면접 포인트

이 템플릿은 그대로 가져다 쓰기보다 응용했을 때 포트폴리오 가치가 더 커집니다. 반품·환불 문의처럼 답이 정형화돼 있지만 실수하면 고객 신뢰를 잃는 업무, 혹은 세일즈 초기 문의에 빠르게 응대하되 담당자가 최종 확인만 하는 업무에 그대로 옮겨 쓸 수 있습니다. 포트폴리오에는 AI가 만든 초안이 담긴 승인 요청 메일 캡처와, 승인 후 발신자에게 도착한 최종 답장 캡처 두 장을 함께 넣으면 승인 게이트가 실제로 작동한다는 걸 보여줄 수 있습니다.

면접에서는 "왜 AI가 답장을 바로 안 보내고 승인을 거치게 했나요?"라는 질문이 나올 수 있습니다. 답은 이렇게 정리할 수 있습니다. 한 번 나간 메일은 되돌릴 수 없고, AI가 톤이나 사실관계를 잘못 짚었을 때의 비용이 크기 때문에, 자동화의 목표를 "사람 개입 제로"가 아니라 "반복 작업은 줄이고 판단이 필요한 지점만 사람에게 남기는 것"으로 잡았다는 답입니다. 이렇게 답할 수 있으면 노드를 연결할 줄 안다는 인상을 넘어, 자동화를 어디까지 맡길지 스스로 판단할 줄 안다는 인상을 줍니다.

다음 액션

다음 편에서는 같은 마켓플레이스에 공개된, 웹사이트 콘텐츠를 기반으로 RSS 피드를 직접 만들어내는 템플릿을 다룹니다. 지금까지 시리즈에서 RSS는 "구독해서 읽는 대상"으로만 다뤘는데, 이번에는 반대로 "만들어내는 대상"이 되는 구조를 보게 됩니다. 이번 편에서 본 "흐름 중간에 조건 분기를 두고 사람의 판단을 명시적으로 반영한다"는 설계는, 다음 편 이후에도 승인이나 검수가 필요한 자동화를 만들 때 계속 참고할 만한 패턴입니다.