대부분의 고객 지원 자동화 프로젝트는 잘못된 질문에서 시작하기 때문에 실패합니다.

그들은 다음과 같이 질문합니다:

어떻게 하면 AI가 고객에게 자동으로 답변하게 만들 수 있을까?

더 나은 질문은 다음과 같습니다:

지원 팀이 고객의 문제를 실제로 해결하기 전에 반복적인 시간을 어디에 소비하고 있는가?

많은 지원 팀에게 정답은 답변 생성(reply generation)이 아닙니다.

그것은 분류(triage)입니다.

들어오는 메시지를 읽고, 문제를 이해하며, 적절한 카테고리를 할당하고, 긴급도를 감지하며, 티켓을 라우팅(routing)하고, 민감한 사례를 에스컬레이션(escalating)하며, 첫 번째 응답 방향을 준비하는 과정입니다.

이것이 바로 AI가 고객과의 커뮤니케이션에 대한 완전한 제어권을 갖지 않으면서도 진정으로 유용하게 쓰일 수 있는 부분입니다.

Zestminds에서 우리는 최근 다음과 같은 도구들을 사용하여 AI 지원 분류 자동화 워크플로우(workflow)를 구축했습니다:

• 워크플로우 오케스트레이션 (workflow orchestration)을 위한 n8n
• 메시지 분석을 위한 OpenAI/GPT API
• 티켓 관리를 위한 Freshdesk/Zendesk 스타일의 헬프데스크 시스템
• 인테이크 소스 (intake sources) 중 하나로 Gmail/지원 받은 편지함 사용
• 에스컬레이션 (escalation)을 위한 Slack 및 이메일 알림
• 민감한 사례를 위한 인간 검토 (Human review) 규칙
• 가시성 및 디버깅 (debugging)을 위한 워크플로우 로그

이 글에서는 우리가 기술적으로 워크플로우에 어떻게 접근했는지, 어떤 로직을 사용했는지, AI가 어디에서 도움을 주었는지, 그리고 왜 의도적으로 인간을 루프 안에 유지했는지(humans in the loop)를 상세히 설명합니다.

문제 (The Problem)

클라이언트는 다음과 같은 여러 채널로부터 지원 메시지를 받고 있었습니다:

• 지원 이메일
• 웹사이트 양식
• 채팅 문의
• 내부 에스컬레이션 요청

모든 들어오는 메시지는 지원 팀에 의해 수동으로 검토되어야 했습니다.

수동 흐름은 다음과 같았습니다:

새로운 지원 메시지 수신
  -> 지원 담당자가 메시지 읽기
  -> 담당자가 문제 식별
...

이 방식은 요청량이 적을 때는 작동했습니다.

하지만 지원 요청이 증가함에 따라, 이 프로세스는 예측 가능한 문제들을 만들어냈습니다:

• 에이전트들이 메시지를 읽고 분류하는 데 너무 많은 시간을 소비했습니다.
• 티켓 카테고리가 항상 일관되지는 않았습니다.
• 긴급한 티켓이 일반 요청과 섞일 수 있었습니다.
• 일부 티켓이 늦게 라우팅되거나 잘못된 큐(Queue)로 전달되었습니다.
• 관리자가 에스컬레이션(Escalation)이 빈번한 사례에 대해 가시성을 확보하기 어려웠습니다.
• 첫 응답 준비에 필요 이상의 시간이 소요되었습니다.
• 민감한 사례에는 여전히 인간의 판단이 필요했습니다.

고객은 AI가 지원 에이전트를 대체하는 것을 원하지 않았습니다.

그들은 AI가 팀이 더 나은 상태에서 업무를 시작할 수 있도록 돕기를 원했습니다.

핵심 아이디어 (The Core Idea)

핵심 아이디어는 간단했습니다:

AI가 티켓의 컨텍스트(Context)를 준비합니다. 자동화가 작업을 라우팅(Routing)합니다. 인간은 민감한 고객 커뮤니케이션에 대한 책임을 유지합니다.

이는 중요한 차이점입니다.

우리는 챗봇(Chatbot)을 만드는 것이 아니었습니다.

우리는 모든 고객에게 맹목적으로 답변하는 시스템을 만드는 것도 아니었습니다.

우리는 들어오는 지원 메시지와 헬프데스크(Helpdesk) 시스템 사이에 위치하는 AI 지원 분류(Triage) 레이어를 구축하고 있었습니다.

워크플로우(Workflow)는 비정형(Unstructured) 고객 메시지를 정형(Structured) 지원 티켓 데이터로 변환해야 했습니다.

상위 수준 아키텍처 (High-Level Architecture)

워크플로우는 다음과 같았습니다:

Incoming Support Message
        |
        v
...

n8n은 오케스트레이션(Orchestration) 레이어 역할을 했습니다.

OpenAI/GPT는 분류(Triage) 지능 레이어 역할을 했습니다.

헬프데스크 시스템은 운영 기록 시스템(System of record) 역할을 했습니다.

Slack과 이메일은 알림 채널 역할을 했습니다.

인간의 검토(Human review)는 안전 레이어(Safety layer) 역할을 했습니다.

n8n이 적합했던 이유

이 워크플로우에는 기본적인 통합 이상의 기능이 필요했습니다.

다음과 같은 요소들이 요구되었습니다:

• 다중 유입 소스 (Multiple intake sources)
• API 호출 (API calls)
• 데이터 변환 (Data transformation)
• 조건부 분기 (Conditional branching)
• 티켓 생성 (Ticket creation)
• 티켓 업데이트 (Ticket updates)
• 큐 할당 (Queue assignment)
• 우선순위 매핑 (Priority mapping)
• Slack 알림 (Slack alerts)
• 이메일 알림 (Email alerts)
• 검토 플래그 (Review flags)
• 실패 로깅 (Failure logging)

n8n은 단순히 도구 간의 데이터 이동뿐만 아니라 조건부 로직 (conditional logic)이 필요한 워크플로였기 때문에 매우 효과적이었습니다.

예를 들어:

IF urgency = high
  -> 지원 매니저에게 Slack 알림 전송

...

이러한 유형의 분기 (branching) 처리는 워크플로 자동화가 단순한 통합 (integration)보다 더 가치 있어지는 지점입니다.

AI 계층 (AI Layer)의 역할

AI 계층은 고객 메시지를 읽고 구조화된 티켓 정보 (structured ticket intelligence)를 반환하는 역할을 담당했습니다.

모든 수신 메시지에 대해, 우리는 AI 출력이 다음 내용을 포함하기를 원했습니다:

• 이슈 요약 (Issue summary)
• 티켓 카테고리 (Ticket category)
• 긴급도 (Urgency level)
• 고객 감정 (Customer sentiment)
• 제안된 우선순위 (Suggested priority)
• 제안된 대기열 또는 팀 (Suggested queue or team)
• 누락된 정보 (Missing information)
• 에스컬레이션 플래그 (Escalation flag)
• 인간 검토 필요 여부 (Human review requirement)
• 답변 초안 방향 (Draft response direction)

중요한 부분은 AI 출력이 자동화에 사용할 수 있을 만큼 충분히 구조화되도록 만드는 것이었습니다.

모호한 AI 응답은 워크플로 내부에서 유용하지 않습니다.

구조화된 JSON 응답은 유용합니다.

AI 출력 예시

가공되지 않은 고객 메시지는 다음과 같을 수 있습니다:

비밀번호를 이미 두 번이나 재설정했지만, 여전히 계정에 접속할 수 없습니다.
오늘 무언가를 제출해야 하기 때문에 매우 급한 상황입니다.

AI 분류 (triage) 출력은 다음과 같을 수 있습니다:

{
  "issue_summary": "고객이 여러 번의 비밀번호 재설정 시도 후에도 계정에 접속할 수 없음.",
  "category": "계정 접속 (Account Access)",
...

이를 통해 지원 팀은 명확한 시작점을 가질 수 있었습니다.

상담원은 모든 메시지를 처음부터 읽는 대신, 즉시 다음 사항을 확인할 수 있었습니다:

• 어떤 일이 발생했는지
• 얼마나 긴급한지
• 어떤 대기열에서 처리해야 하는지
• 고객이 좌절한 것처럼 보이는지
• 어떤 정보가 누락되었는지
• 답변에 인간의 검토가 필요한지

프롬프트 구조 예시

이러한 유형의 워크플로에서는 프롬프트가 모델에게 먼저 "친절한 답변을 작성하라"고 요구해서는 안 됩니다.

첫 번째 작업은 분류 (classification)와 triage입니다.

단순화된 프롬프트 구조는 다음과 같을 수 있습니다:

당신은 지원 분류 (support triage) 어시스턴트입니다.

고객 메시지를 분석하고 유효한 JSON만 반환하세요.
...

모델이 최종 지원 에이전트 (support agent)로 취급되지 않기 때문에 이 방식이 더 안전합니다.

모델은 분류 어시스턴트 (triage assistant)로 사용됩니다.

권장 JSON 스키마 (Suggested JSON Schema)

실용적인 응답 스키마는 다음과 같습니다:

{
  "issue_summary": "string",
  "category": "technical | billing | account_access | refund | general | escalation | other",
...

confidence 필드는 신뢰도가 낮은 출력을 수동 검토 큐 (manual review queue)로 라우팅할 수 있게 해주므로 유용합니다.

예시:

IF confidence < 0.75
  -> human_review_required = true
  -> route to manual review queue

라우팅 로직 (Routing Logic)

AI가 구조화된 출력 (structured output)을 반환하면, n8n이 라우팅 규칙을 적용합니다.

규칙 예시:

IF urgency = critical
  -> Set priority = urgent
  -> Send Slack alert
...

이 지점에서 자동화가 실용적으로 변합니다.

AI가 워크플로 (workflow) 결정을 단독으로 내리지 않습니다.

AI는 구조화된 컨텍스트 (structured context)를 생성합니다.

워크플로는 비즈니스 규칙 (business rules)을 적용합니다.

사람은 민감한 케이스를 검토합니다.

헬프데스크 티켓 생성 (Helpdesk Ticket Creation)

분류 (triage) 후, 워크플로는 헬프데스크 시스템에 티켓을 생성하거나 업데이트합니다.

티켓 필드는 다음과 같이 매핑될 수 있습니다:

{
  "subject": "{{issue_summary}}",
  "description": "{{original_customer_message}}",
...

이를 통해 지원 에이전트들이 이미 사용 중인 시스템 내부에서 AI가 생성한 컨텍스트를 확인할 수 있도록 보장했습니다.

이것이 중요합니다.

목표는 아무도 확인하지 않는 별도의 AI 대시보드를 만드는 것이 아니었습니다.

목표는 기존의 지원 워크플로를 개선하는 것이었습니다.

Slack 알림 예시 (Slack Alert Example)

긴급하거나 에스컬레이션 (escalated)된 케이스의 경우, 워크플로는 Slack 알림을 보냅니다.

Slack 메시지 예시:

High Priority Support Ticket

Category: Account Access
...

이를 통해 관리자들은 하루 종일 헬프데스크를 수동으로 확인하지 않고도 긴급한 티켓을 더 빠르게 식별할 수 있었습니다.

인간 검토 규칙 (Human Review Rules)

가장 중요한 설계 결정은 AI가 어디에서 멈춰야 하는지를 결정하는 것이었습니다.

이 워크플로에서 인간의 검토가 필요한 경우는 다음과 같습니다:

• 결제 문제 (Billing issues)
• 환불 요청 (Refund requests)
• 계정 액세스 문제 (Account access problems)
• 보안 민감 사례 (Security-sensitive cases)
• 화가 나거나 좌절한 고객 (Angry or frustrated customers)
• SLA 민감 티켓 (SLA-sensitive tickets)
• 기술적 장애 (Technical incidents)
• AI 분류 신뢰도 낮음 (Low-confidence AI classification)
• 불분명한 고객 의도 (Unclear customer intent)
• 비즈니스 리스크를 초래할 수 있는 모든 고객 대응 메시지 (Any customer-facing response that could create business risk)

이를 통해 부주의한 자동화의 위험을 줄였습니다.

지원 팀은 다음과 같은 작업을 수행할 수 있었습니다:

• AI 요약 검토 (Review the AI summary)
• 제안된 답변 수정 (Edit the suggested response)
• 답변 전체 재작성 (Rewrite the response completely)
• 최종 메시지 승인 (Approve the final message)
• 필요한 경우 AI 제안 무시 (Ignore the AI suggestion if needed)

AI는 팀을 보조했습니다.

민감한 커뮤니케이션에 대한 책임은 AI가 지지 않았습니다.

오류 처리 및 로깅 (Error Handling and Logging)

비즈니스 워크플로에서 로깅 (Logging)은 선택 사항이 아닙니다.

자동화가 소리 없이 실패한다면, 팀은 더 이상 이를 신뢰하지 않을 것입니다.

우리는 다음 항목들을 추적했습니다:

• 메시지 수신 타임스탬프 (Message received timestamp)
• 소스 채널 (Source channel)
• AI 분류 상태 (AI triage status)
• AI 응답 페이로드 (AI response payload)
• 할당된 카테고리 (Category assigned)
• 할당된 우선순위 (Priority assigned)
• 할당된 큐 (Queue assigned)
• 티켓 생성/업데이트 상태 (Ticket creation/update status)
• Slack/이메일 알림 상태 (Slack/email alert status)
• 인간 검토 상태 (Human review status)
• 오류 메시지 (Error messages)
• 재시도 횟수 (Retry attempts)

로그 구조 예시:

{
  "source": "support_inbox",
  "message_id": "msg_12345",
...

무언가 실패했을 경우, 워크플로는 내부 팀에 알림을 보낼 수 있었습니다:

IF ticket_creation_status = failed
  -> 오류 로깅 (Log error)
  -> 내부 알림 전송 (Send internal alert)
...

이를 통해 워크플로의 디버깅 (Debug)과 유지보수 (Maintain)가 더 쉬워졌습니다.

결과 (Results)

이 워크플로는 고객이 지원 접수(Support intake)를 더 빠르고, 일관되게, 그리고 관리하기 쉽게 만드는 데 도움을 주었습니다.

그 영향은 다음과 같습니다:

• 1차 지원 분류 (First-level support triage) 시간이 메시지당 약 8~12분에서 2분 미만으로 단축되었습니다.
• 수동 티켓 생성 및 분류 작업 노력이 약 60~70% 감소했습니다.
• 긴급 티켓을 몇 분 내에 더 쉽게 식별할 수 있게 되었습니다.
• 티켓 라우팅 (Ticket routing)이 더욱 일관되게 변했습니다.
• 지원 에이전트들이 AI가 준비한 요약본과 제안된 답변 방향을 확인하며 업무를 시작할 수 있게 되었습니다.
• 에스컬레이션 (Escalation) 케이스가 관리자에게 더 잘 보이게 되었습니다.
• 민감한 티켓은 인간 검토 (Human review) 대상으로 표시되었습니다.
• 워크플로 로그 (Workflow logs)를 통해 팀이 라우팅 결정, 알림, 오류 및 검토 상태를 더 잘 파악할 수 있게 되었습니다.

가장 큰 개선 사항은 단순히 속도만이 아니었습니다.

그것은 바로 일관성이었습니다.

더 이상 모든 지원 에이전트가 카테고리, 긴급도, 우선순위 및 라우팅을 처음부터 독립적으로 결정할 필요가 없었습니다. 시스템이 구조화된 시작점을 만들어 주었습니다.

우리가 배운 점

1. 자동 응답 (Auto-replies)부터 시작하지 마세요

워크플로가 카테고리, 에스컬레이션 규칙, 신뢰도(Confidence) 및 검토 요구 사항을 먼저 이해하지 못한다면 자동 응답은 위험합니다.

분류 (Triage)부터 시작하세요.

그다음 통제된 응답 지원 단계로 나아가야 합니다.

2. 구조화된 출력 (Structured output)이 중요합니다

AI 출력은 예측 가능해야 합니다.

출력을 파싱 (Parse)하여 워크플로에 매핑할 수 없다면, 그 출력은 신뢰할 수 없게 됩니다.

JSON 기반의 출력이 긴 자연어 설명보다 훨씬 더 유용합니다.

3. 인간 검토는 제약이 아니라 기능입니다

인간을 루프 안에 포함시키는 것 (Human in the loop)이 시스템을 더욱 실용적으로 만들었습니다.

이는 판단력을 잃지 않으면서도 팀에 속도를 부여했습니다.

4. 로그는 신뢰를 구축합니다

지원 팀은 자동화 내부에서 어떤 일이 일어났는지 알 필요가 있습니다.

티켓이 라우팅되었거나, 에스컬레이션되었거나, 검토 대상으로 표시되었다면 그 이유가 가시적이어야 합니다.

5. AI는 기존 도구 내부에서 작동할 때 가장 효과적입니다

이 워크플로가 유용했던 이유는 컨텍스트 (Context)를 기존의 헬프데스크 및 Slack 채널로 전달했기 때문입니다.

지원 팀에게 또 다른 별도의 대시보드를 도입하도록 강요하지 않았습니다.

이러한 유형의 자동화가 잘 작동하는 곳

이러한 접근 방식은 여러 채널을 통해 지원 메시지를 받고 더 나은 분류(Triage)가 필요한 기업에 유용합니다.

일반적인 사용 사례는 다음과 같습니다:

• SaaS 지원 팀
• 이커머스 (E-commerce) 지원 팀
• B2B 서비스 기업
• 내부 IT 헬프데스크 (IT helpdesks)
• 운영 팀 (Operations teams)
• 고객 성공 팀 (Customer success teams)
• 고객 지원을 처리하는 에이전시 (Agencies)
• 지원 대기열 (Support queues)을 보유한 제품 기업

좋은 시작점은 다음과 같습니다:

• 티켓 분류 (Ticket categorization)
• 긴급도 감지 (Urgency detection)
• 감정 감지 (Sentiment detection)
• 대기열 라우팅 (Queue routing)
• 에스컬레이션 알림 (Escalation alerts)
• 누락된 정보 감지 (Missing information detection)
• 내부 노트 생성 (Internal note generation)
• 답변 초안 작성 가이드 (Draft response direction)
• 인간 검토 대기열 (Human review queues)

이 방식은 첫날부터 모든 고객 응대를 자동화하려고 시도하는 것보다 더 안전하고 실용적입니다.

마치며

최고의 AI 워크플로 자동화 (AI workflow automation) 프로젝트는 모든 곳에 AI를 추가하는 것이 아닙니다.

실제 비즈니스 프로세스 내부에서 반복되는 의사결정 지점을 찾아내어, 팀이 더 빠르고 일관되게, 그리고 더 나은 가시성을 가지고 이를 처리할 수 있도록 돕는 것입니다.

이 프로젝트에서:

• AI는 1차 분석을 담당했습니다.
• n8n은 워크플로 오케스트레이션 (Workflow orchestration)을 담당했습니다.
• 헬프데스크는 티켓 관리를 담당했습니다.
• Slack/이메일은 알림을 담당했습니다.
• 인간은 민감한 커뮤니케이션과 최종 판단을 담당했습니다.

그러한 균형이 워크플로를 실용적으로 만들었습니다.

AI가 지원 상담원을 대체하는 것이 아닙니다.