Corca Medium 아카이브

VoC 대응 에이전트 구축기

들어가며

최근 문라이트 팀은 VoC 응대 과정을 에이전트와 함께 처리하고 있습니다. 이 글에서는 그 과정에서 무엇을 문제로 봤고, 어떤 구조로 풀었는지 정리해보려 합니다.

이 프로젝트를 시작하게 된 계기는 작은 팀에서 수많은 VoC를 처리하며 팀원들의 피로감이 누적되고 있었 고, 이를 어떻게 더 효율적으로 감당할 수 있을 지 문제 해결 방법을 고민하게 되었습니다.

VoC 대응 지원을 요청하는 모습

실제 VoC 응대는 답변 한 문장을 쓰는 일로 끝나지 않습니다. 문의를 읽고, 정책 문서를 확인하고, 코드베이스를 보고, 필요하면 DB를 조회하고, 그래도 판단이 어려우면 해당 맥락을 잘 아는 팀원에게 다시 질문해야 합니다. 즉, VoC 응대는 글쓰기보다 조회와 판단에 더 가까운 작업입니다.

최근에는 다양한 AI 기능을 가진 고객 응대 자동화 도구들이 있습니다. 다만 팀에 필요했던 건 일반적인 답변 생성기가 아닌 우리 서비스의 정책, 코드, 데이터, 맥락에 접근하면서 실제 팀원처럼 조회하고 질의할 수 있는 방식이 필요했습니다.

어떤 문제가 있었나?

문제는 세 가지였습니다.

첫째, 소수의 팀이 매일 10건 이상 들어오는 VoC를 처리하면서 시간 비용과 컨텍스트 전환 비용을 함께 감당해야 했습니다.

둘째, 팀원마다 갖고 있는 컨텍스트가 달라 확인하는 근거와 답변 방식에도 차이가 있었습니다. 필요한 근거를 어디서 확인해야 하는지 바로 떠오르지 않는 경우에는 다른 팀원에게 다시 질문해야 했습니다.

셋째, 답변 자동화를 시도하더라도 일반적인 AI 답변 기능만으로는 내부 맥락에 접근하기 어려웠습니다. 실 제 운영에서는 자연스러운 문장보다 근거가 있는 답변이 더 중요했기 때문에 이 한계가 분명했습니다.

그래서 우리가 풀고자 했던 문제는 두가지였습니다. 하나는 적은 인원으로 더 많은 VoC를 감당할 수 있게 만드는 운영 효율의 문제였고, 다른 하나는 실제 서비스 맥락과 내부 근거를 반영하는 품질의 문제였습니다.

이를 위해 문라이트 팀은 VoC를 수집하고, 필요한 근거를 탐색하고, 초안을 만들고, 마지막에 사람이 검수하 는 처리 플로우를 구성했습니다.

에이전틱 VoC 처리 플로우

이 프로젝트를 진행하면서 우선 집중한 부분은 응대 과정을 구조화하는 것이었습니다.

가장 먼저 고민한 것은 “무엇을 먼저 볼 것인가”였습니다. 실제 팀원들이 응대할 때 반복적으로 밟는 순서를 정리해보니, 대체로 아래 흐름을 보였습니다.

1. 1. 기존 대화 내역 확인
2. 2. 정책 문서 확인
3. 3. 코드베이스 확인
4. 4. 필요한 경우 DB 조회
5. 5. 답변 초안 정리

첫 번째 목표는 이 흐름을 에이전트가 재현할 수 있게 만드는 것이었습니다.

두 번째 목표는 책임을 여전히 사람이 가지도록 하는 것이었습니다. 자동 발송은 품질과 보안 측면에서 부담 이 있었기 때문에, 탐색과 초안 작성은 에이전트가 맡고 최종 판단은 사람이 하도록 구성했습니다. 흔히 말하 는 휴먼 인 더 루프 방식입니다.

그래서 이 프로젝트는 단순한 답변 생성기가 아니라, VoC를 수집하고, 근거를 탐색하고, 초안을 만들고, 사 람의 검수를 거쳐 발송하는 처리 플로우를 만드는 작업에 가까웠습니다.

Moonlight VoC 처리 흐름

고객 문의

1. 1. 고객 문의가 VoC 채널로 들어옵니다.
2. 2. 고객 문의는 웹훅으로 수신하고, 누락 복구를 위해 주기 조회를 보조적으로 사용합니다.
3. 3. 해당 VoC가 처리 대상인 지 판단합니다.
4. 4. 처리 대상인 경우, 사람이 수행하던 흐름과 유사한 순서로 근거를 탐색합니다.
5. 임베딩된 기존 대화 조회
6. 코드 베이스와 정책 문서 조회
7. 필요한 경우 데이터베이스 조회
8. 5. 탐색 결과 및 템플릿을 바탕으로 답변 초안을 만듭니다.
9. 6. 초안을 슬랙으로 전달합니다.

슬랙에 표시되는 답변 초안

1. 7. 담당자가 슬랙의 요약과 상세 내용을 확인한 뒤, Send, Retry, Deny 버튼을 통해 처리방식을 선택합니다.

Send 버튼 클릭 시, VoC 채널로 발송

에이전틱 플로우를 적용한 결과

이 구조를 적용한 뒤 가장 크게 달라진 점은, 팀원이 응대 과정의 처음부터 끝까지 직접 수행하지 않아도 된다는 점입니다. 이전에는 문의를 읽고, 어떤 근거를 확인할지 판단하고, 필요한 정보를 찾아 초안을 정리하는 과정을 사람이 모두 맡아야 했습니다. 반면 현재는 전체 문의 중 50% 정도는 반복적인 조회와 초안 작성 단계를 에이전트가 먼저 처리하고, 담당자는 슬랙에서 최종 판단만 하면 됩니다.

이 변화는 응답 속도만의 문제는 아니었습니다. 팀원마다 달랐던 컨텍스트 차이를 줄이고, “이건 누구에게 물어봐야 하는가”에 대한 비용도 함께 낮출 수 있었습니다. 특히 기존 대화 내역, 정책 문서, 코드베이스, 데이터 조회를 하나의 흐름으로 묶으면서, 근거를 찾는 과정 자체를 더 일관되게 만들 수 있었습니다.

그래서 이 프로젝트는 답변을 자동으로 보내는 시스템이라기보다, VoC 응대 과정에서 반복되던 탐색과 초안 작성 비용을 줄이는 운영 도구로 자리 잡았습니다.

MoonClaw와의 연결

기본적인 VoC 수집, 근거 탐색, 초안 생성, 검수, 발송은 앞에서 설명한 VoC 처리 플로우만으로도 돌아갑니다. 다만 실제로 운영하다 보면 이 플로우만으로 끝나지 않는 경우가 있습니다. 초안을 조금 손봐야 할 때도 있고, 현재 문의와 관련된 프로젝트 맥락을 한 번 더 확인해야 할 때도 있습니다. 에이전트가 찾아온 근거가 지금 기준에서도 맞는지 다시 보고 싶은 경우도 있습니다.

이럴 때 위에서 같이 쓰고 있는 것이 MoonClaw입니다. MoonClaw는 VoC 처리 플로우 자체를 대신하는 도구

슈퍼바이저 에이전트

라기보다, 그 위에서 동작하는 에 가깝습니다. 평소에는 VoC 처리 플로우가 대부분의 문의를 처리하고, 추가 확인이나 수정이 필요한 순간에만 MoonClaw와 대화하면서 결과를 다듬는 방식입니다.

예를 들어 팀원은 MoonClaw에게 “이 답변에서 결제 정책 부분만 최신 코드 기준으로 다시 확인해줘”라고 요청할 수 있습니다. 혹은 에이전트가 참조한 근거가 현재 운영 맥락에서도 여전히 유효한지, 특정 표현이 실제 정책과 어긋나지 않는지 한 번 더 검토할 수도 있습니다. 즉, VoC 처리 플로우가 기본 경로라면, MoonClaw는 그 위에서 예외 상황이나 추가 질의를 받아주는 경로라고 볼 수 있습니다.

운영의 유연성

이러한 구조가 주는 가장 큰 이점은 입니다.

독립적 엔진

1. 1. : VoC 대응 플로우는 상위 에이전트 없이도 24시간 안정적으로 루틴한 업무를 처리합니다.

대화형 보강

1. 2. : 복잡한 판단이나 수정이 필요한 경우에만 MoonClaw를 통해 에이전트와 대화하며 결과물

을 다듬습니다.

맥락의 공유

1. 3. : MoonClaw는 프로젝트 전체의 컨텍스트를 쥐고 있으므로, 단순 VoC 처리를 넘어 서비스 전

체의 업데이트 방향에 맞는 응대를 보장할 수 있습니다.

상위 에이전트와의 느슨한 연결을 통해, 루틴한 처리는 자동화하고 복잡한 문제는 에이전트 간의 협업으로

확장 가능한 운영 구조

풀어내는 를 갖추게 되었습니다.

마무리

이번 구축에서 가장 크게 얻은 것은, 에이전틱 시스템이 사람의 일을 어떤 방식으로 나눠 맡을 수 있는지에 대한 감각이었습니다. 사람의 일을 통째로 대체하는 것이 아니라, 탐색, 근거 수집, 초안 작성, 승인으로 나누고 그중 반복 가능한 부분을 먼저 시스템에 맡기는 방식이 효과적이라는 점을 확인했습니다.

반대로 끝까지 사람에게 남겨둬야 하는 일도 분명했습니다. 고객에게 실제로 발송할지 결정하는 일, 예외 상황에서 어떤 맥락을 더 반영할지 판단하는 일, 잘못된 응대에 대한 책임을 지는 일은 여전히 사람의 몫이었습니다. 그래서 이번 프로젝트는 사람을 없애는 자동화가 아니라, 사람이 책임을 유지한 채 반복 작업을 줄이는 구조를 만드는 작업에 가까웠습니다.

결국 이 프로젝트는 VoC 자동화 자체보다, 실제 운영 업무를 에이전틱 시스템으로 어떻게 옮길 수 있는지 실험한 사례였습니다. 문라이트 팀에게는 이 경험이 단순한 응대 자동화를 넘어, 앞으로 다른 운영 영역을 다룰 때도 적용할 수 있는 기준이 되었습니다.