고객 문의 메일, AI가 분류하고 답장 초안까지 — CS 이메일 자동응답 워크플로우
이 글과 연결된 글 보기
드래그로 이동 · 휠/두 손가락으로 확대 · 방향키로 글 선택 · 0으로 맞춤. 실선: 본문 링크, 점선: 시리즈·주제의 대표 연결.표시된 글 7편 목록
Gmail로 들어온 고객 문의 메일을 AI가 읽고 환불·기술·영업 세 갈래로 분류한 뒤, 문의 유형에 맞는 답장 초안까지 만들어 담당팀 슬랙 채널로 전달하는 n8n 워크플로우입니다. 다만 답장을 고객에게 바로 보내지는 않습니다. 초안은 담당자가 검토한 뒤 직접 발송하도록 사람이 마지막에 확인하는 단계를 남겨 뒀습니다. 이 구조를 따라 만들면 분류 결과로 흐름을 나누는 Switch 노드 활용법과, 자동화에서 어디까지를 AI에게 맡기고 어디서부터 사람 손을 거치게 할지 판단하는 기준을 포트폴리오에 넣을 수 있습니다.
이 워크플로우 하나로 보여줄 수 있는 것
지난 Gmail 자동 분류 편이 받은 메일을 유형별로 나눠 데이터베이스에 쌓는 데서 끝났다면, 이 편은 그 분류 결과를 실제 업무 동선으로 한 단계 더 밀어 넣습니다. 문의가 환불이면 환불 담당 채널로, 기술 문제면 기술 지원 채널로, 영업 문의면 영업팀 채널로 — 분류가 곧 담당자 배정이 되고, 그 자리에 AI가 미리 써 둔 답장 초안까지 따라갑니다.
- 분기 설계(Switch 노드) — 분류 결과값 하나로 워크플로우의 다음 경로를 나누는 경험
- AI 구조화 출력으로 초안까지 생성 — 분류와 동시에 답장 문안까지 뽑아내는 한 번의 LLM 호출 설계
- 사람 확인 지점 설계 — 어디까지 자동화하고 어디서 사람이 검증하게 할지 정하는 판단
이 세 가지를 하나로 묶으면 "분류만 하는 자동화"와 "분류 결과로 다음 행동까지 만드는 자동화"의 차이를 설명할 수 있게 됩니다. 후자가 실제 업무에서 훨씬 더 자주 요구되는 형태이고, 그만큼 면접에서도 더 깊게 물어보는 지점입니다.
배경 — 분류만으로는 일이 끝나지 않는다
고객 문의가 쌓이는 회사는 대개 담당자가 메일함을 열어 하나씩 읽고, 어디로 보낼지 판단하고, 답장을 씁니다. 문의를 유형별로 분류하는 것만으로는 이 일이 줄지 않습니다. 분류된 메일도 결국 누군가 읽고 답장을 써야 하기 때문입니다. 이 워크플로우는 교육 플랫폼 구름의 n8n 강의용으로 만들어 둔 것으로, 캔버스의 스티키 노트에 "고객의 문의를 AI가 읽고 판단하여, 담당자에게 답변 초안을 즉시 배달합니다"라는 목표가 적혀 있습니다. 분류에서 멈추지 않고 담당팀 배정과 답장 초안까지 한 번에 처리하겠다는 설계 의도가 그대로 드러나는 문장입니다.
설치와 기본 노드 설명은 n8n으로 반복업무 자동화 포트폴리오 만들기에 정리돼 있으니, 이 글에서는 이 워크플로우 자체만 다룹니다.
구조 — Trigger / Task / Target
이 그림은 스티키 노트가 설명하는 설계입니다. 원본 export에 실제로 저장된 연결이 이 그림과 어디서 갈라지는지는 아래 "원본 캔버스에 남아 있는 흔적"에서 따로 다룹니다.
- Trigger — Gmail Trigger, 받은편지함(INBOX)을 1분마다 폴링
- Task — 메일 필드 정리 → AI가 category(REFUND/TECHNICAL/SALES)·urgency(LOW/MEDIUM/HIGH)로 분류하고 답장 초안까지 생성 → 분류값으로 세 팀 채널에 분기
- Target — 담당팀 슬랙 채널(알림 + 초안), 구글시트(처리 이력)
만들기
1. Gmail Trigger — 받은편지함 폴링
Gmail Trigger 노드에서 Poll Times를 Every Minute으로, Filters의 Label을 INBOX로 지정합니다. 매 분 받은편지함을 확인해 새 메일이 있으면 바로 다음 노드로 넘깁니다. 원본에는 같은 설정의 Gmail Trigger가 두 개 나란히 붙어 감시하는 받은편지함이 두 곳입니다. 새로 만들 때는 감시할 Gmail 계정 하나에 트리거 하나면 충분합니다.
2. Set — 메일 필드 정리
Edit Fields(Set) 노드에서 뒤 단계에서 반복해서 참조할 필드 다섯 개를 미리 정리합니다.
emailSubject = {{ $json.Subject }}
emailFrom = {{ $json.From }}
emailBody = {{ $json.snippet }}
emailDate = {{ $json.internalDate.toDateTime('ms') }}
emailId = {{ $json.id }}
Gmail의 internalDate는 밀리초 단위 유닉스 타임스탬프라 .toDateTime('ms')로 바로 날짜 형식으로 바꿀 수 있습니다. 여기서 눈여겨볼 부분은 emailBody입니다. 메일 본문 전체가 아니라 Gmail이 미리보기용으로 잘라주는 snippet 필드를 그대로 씁니다. 짧은 문의는 문제없지만, 긴 문의라면 AI가 뒷부분을 아예 못 본 채로 분류하고 답장을 씁니다. 이 부분은 한계 섹션에서 다시 다룹니다.
3. AI Agent + Structured Output Parser — 분류와 답장 초안을 한 번에
AI Agent 노드의 Prompt를 Define으로 두고, Text에 앞서 정리한 제목·발신자·본문을 조합해 넣습니다. Chat Model에는 OpenAI gpt-4.1-mini가 연결돼 있고, Require Specific Output Format을 켠 뒤 Structured Output Parser를 붙여 출력을 강제합니다. 파서의 스키마는 다음과 같습니다.
{
"type": "object",
"properties": {
"category": { "type": "string", "enum": ["REFUND", "TECHNICAL", "SALES"] },
"urgency": { "type": "string", "enum": ["LOW", "MEDIUM", "HIGH"] },
"reasoning": { "type": "string" },
"draftResponse": { "type": "string" }
},
"required": ["category", "urgency", "reasoning", "draftResponse"]
}
분류 값 하나(category)만 뽑는 게 아니라 긴급도(urgency), 분류 이유(reasoning), 답장 초안(draftResponse)까지 한 번의 호출로 같이 받는 구조입니다. reasoning을 스키마에 넣어 둔 이유는 명확합니다. AI가 왜 이 메일을 REFUND로 분류했는지 담당자가 슬랙 알림에서 바로 확인하고, AI 판단을 신뢰할지 검증할 수 있게 하기 위해서입니다.
원본에서 이 Agent의 System Message 칸을 열어보면, 실제로는 이 분류 작업과 무관한 다른 내용이 들어 있어 참고할 수 없습니다. 직접 채울 때는 최소한 세 가지를 System Message에 명시해야 합니다. 어떤 기준으로 REFUND·TECHNICAL·SALES를 가르는지, 답장의 톤(정중하게·간결하게 등), 그리고 답장에 넣을 회사·서비스 관련 기본 정보입니다. 이 세 가지가 빠지면 스키마는 지켜도 내용은 쓸 수 없는 초안이 나옵니다.
4. Switch — category로 담당팀 나누기
Switch 노드(원본 이름 "Route by Category")에 조건 세 개를 넣습니다. 왼쪽 값은 모두 {{ $json.output.category }}이고, 각각 REFUND·TECHNICAL·SALES와 문자열이 같은지(equals) 비교합니다. Structured Output Parser를 붙인 Agent의 결과는 output 객체 안에 들어오기 때문에 $json.category가 아니라 $json.output.category로 참조해야 합니다. 이 한 글자 차이를 놓치면 세 조건 모두 계속 거짓으로 평가됩니다.
세 조건의 출력에는 각각 환불팀 알림, 기술지원팀 알림, 영업팀 알림 노드를 연결합니다.
5. Slack — 담당팀별 알림 + 초안 전달
세 개의 Slack 메시지 노드는 구조가 같습니다. 발신자·제목·긴급도·날짜·AI가 판단한 분류 이유·답장 초안·메일 ID를 한 메시지에 담아 각 팀 채널로 보냅니다. 답장 초안 부분은 메시지 안에서 별도 블록으로 감싸, 담당자가 초안 텍스트와 나머지 메타 정보를 한눈에 구분해서 읽을 수 있게 했습니다. 채널은 팀별 전용 슬랙 채널을 고르면 됩니다.
6. Merge → Set → Google Sheets — 처리 이력 쌓기
세 팀 알림 뒤에 Merge 노드(입력 3개)를 두어 어느 경로로 갔든 하나의 흐름으로 다시 모읍니다. 그다음 Set 노드에서 Timestamp({{ new Date().toISOString() }}), 발신자, 제목, category, urgency, reasoning, draftResponse, 메일 ID를 시트 컬럼에 맞춰 정리하고, Google Sheets 노드(Operation: Append)로 한 행씩 추가합니다. 이렇게 이력을 쌓아두면 나중에 "이번 달 환불 문의가 몇 건이었는지" 같은 질문에 시트만 열어도 답할 수 있습니다.
원본 캔버스에 남아 있는 흔적 — 스위치가 실제로는 연결돼 있지 않습니다
방금 설명한 구조는 스티키 노트와 각 노드의 설정을 근거로 재구성한 "완성된 형태"입니다. 원본 export의 connections를 열어보면 실제로 저장된 연결은 다릅니다. Classify Email & Generate Draft 노드의 출력이 Switch를 거치지 않고 곧장 기술지원팀 알림 노드로 직결돼 있습니다. Switch 노드 자체는 캔버스에 남아 있고 REFUND·TECHNICAL·SALES 조건도 다 설정돼 있지만, 그 노드로 들어오는 연결이 어디에도 없습니다. 이 export를 그대로 실행하면 분류 결과와 무관하게 모든 메일이 기술지원팀 채널로만 알림이 갑니다.
Switch 안쪽에도 흔적이 하나 더 있습니다. REFUND와 SALES 조건의 출력에는 각각 환불팀·영업팀 알림 노드가 연결돼 있는데, TECHNICAL 조건의 출력에는 애초에 아무 노드도 연결돼 있지 않습니다. 지금 새로 만든다면 Switch를 Classify 뒤에 연결하고, TECHNICAL 출력에 기술지원팀 알림 노드를 붙이는 두 가지를 직접 채워야 완성됩니다.
연결 하나가 더 빠져 있습니다. Merge 노드는 환불·영업 두 알림의 출력을 받도록 설계돼 있는데, 이 노드의 출력 자체는 어디로도 이어지지 않고 끝납니다. 반면 시트에 기록을 남기는 Set → Google Sheets 경로는 기술지원팀 알림 노드에서만 직접 이어져 있습니다. 원본 상태 그대로면 환불·영업 문의는 슬랙 알림까지만 가고 시트 이력에는 남지 않습니다. 세 팀 모두의 처리 이력을 시트에 쌓으려면 Merge 노드 뒤에 시트 정리용 Set 노드로 가는 연결을 하나 추가해야 합니다.
한계
- 본문이 잘린 채로 분류됩니다 —
emailBody가 Gmail의snippet필드(미리보기용으로 잘린 본문)를 그대로 씁니다. 문의가 길면 AI는 뒷부분 내용을 아예 못 보고 분류와 답장 초안을 만듭니다. 본문 전체가 필요하면 Gmail 노드의 Get Message 조작으로 본문을 따로 가져오는 단계를 추가해야 합니다. - 자동 발송 노드가 없습니다 — 이 워크플로우 어디에도 답장을 실제로 발송하는 노드가 없습니다. 세 팀 채널로 가는 알림은 모두 초안이고, 실제 발송은 사람이 합니다. 완전 자동 답장을 원한다면 urgency가 LOW이고 category가 특정 유형일 때만 Gmail 노드로 실제 발송까지 잇는 조건을 직접 설계해야 합니다. 이 조건을 어떻게 잡을지가 이 워크플로우를 한 단계 더 완성하는 핵심 판단입니다.
- 분기·집계 연결이 빠져 있습니다 — 위에서 설명한 대로 Switch가 연결돼 있지 않고, Merge 뒤의 시트 적재 경로도 끊겨 있습니다. 그대로 두면 절반은 알림이 안 가고, 절반은 이력이 안 쌓입니다.
포트폴리오·면접 포인트
이 워크플로우는 "분류만 하는 자동화"와 "분류 결과로 다음 행동까지 만드는 자동화"를 한 캔버스에서 비교해 보여줄 수 있어서 포트폴리오 가치가 높습니다. 같은 구조로 사내 문의 티켓 분류나 파트너사 제휴 문의 라우팅에도 그대로 옮겨 쓸 수 있고, 위 한계에서 짚은 자동 발송 조건을 직접 설계해 붙이면 원본보다 한 단계 더 나아간 버전을 만든 셈이 됩니다.
면접에서는 "AI가 답장 초안까지 쓰는데 왜 자동 발송은 안 시켰나요?"라는 질문이 올 수 있습니다. 답은 이 워크플로우의 구조 자체에 있습니다. 분류와 초안 작성은 AI가 맡되, 그 결과가 맞는지 확인하고 실제로 고객에게 보내는 판단은 사람이 하도록 설계했다는 점을 말하면 됩니다. 어디까지 자동화하고 어디서 사람이 검증하게 할지를 스스로 정해본 경험이라는 게 이 답변의 핵심입니다.
다음 액션
메일 하나가 슬랙 알림과 시트 한 행으로 끝나는 이 흐름 다음에는, 구글시트에 쌓인 매출 데이터를 AI가 매일 읽고 리포트로 요약해 보내는 편으로 넘어갑니다. 입력이 이메일 한 통에서 시트 전체로, 출력이 알림 한 줄에서 리포트 문서로 커지지만 "데이터를 모아서 AI에게 판단을 맡기고, 사람이 보기 좋은 형태로 전달한다"는 뼈대는 이 편과 같습니다.
