93%를 사람에게 넘긴 고객지원 AI 시스템
라이너에서 첫 한 달, 회사 온보딩 과정 속에서 제가 진행한 첫 번째 프로젝트, 고객지원 AI 시스템 이야기를 소개드리고자 합니다. 상담도 자동으로 하고, 메일도 보내고 소비자와 상담하는 AI 에이전트를 머릿 속에 그리실 것 같습니다. 제가 만든 것은 그보다 단순하고, 조금은 투박한 무언가입니다.
제 시스템은 아직 93%의 문의를 답장하는 대신에 고객응대 담당자, 개발자들에게 전달합니다. 초기에는 75%의 자동 답장을 진행하고자 테스트하고 있었지만, 반대 방향의 결과물이 되었습니다.
저는 실패한걸까요?
저는 제 처음 목표에는 도달하지 못 했지만 팀의 더 중요한 병목을 발견하고 그것에 집중했습니다.
기존 우리 팀의 CS는 CS담당자가 인입을 체크하고, 자신의 지식 범주 내에서 대답하거나, 며칠에 한 번 공통 기능으로 이슈를 올려 팀에 전달했습니다. 팀은 처리하거나, 현재 문제 상 넘기거나 하는 과정들이 모두 문서화되지 않았습니다. 결국 고객 피드백이 짧게는 3시간, 길게는 48시간 이상 걸려서도 제품에 반영되지 못하고 있었던 것입니다. 제 고객지원 시스템은 10초 이내에 처리되기 시작해서 티켓 분류, 제품의 코드 레벨까지의 분석이 5분 안에 이루어지도록 했습니다.
직접적인 사람의 투입량이 1~2MM 에서 0.3~0.4MM으로 변하는 그 이상으로, CS와 팀 전체가 연결되었습니다.
저는 고객지원이라는 일로 시작했지만, 사람을 온전히 대체하는 것이 아니라 일을 시작하기 전까지 발생하던 리드타임부터 여러 시스템을 돌아다니며 정보를 모으는 작업을 줄였습니다.
제가 자동화한 것은 반복적으로 발생하던 대기시간과 조사 비용이었습니다.
기존 고객지원의 병목은 답변 작성이 아니었다
기존 고객지원은 Zendesk로 접수된 문의를 숙련된 담당자가 직접 처리하는 방식이었습니다.
문의 하나를 해결하려면 상황에 따라 여러 플랫폼을 오가야했습니다.
Zendesk에서 문의 내용을 확인하고, Back Office에서 사용자 정보를 조회한다. 결제 문제라면 Toss, Stripe, Paddle이나 LG U+를 확인합니다. 내부 지원 도구에서 추가 정보를 찾고, 원인을 알기 어려우면 Slack으로 개발자나 담당 팀에 도움을 요청합니다.
단순 문의는 1분 이내에 답할 수 있었습니다.
문제는 여러 시스템을 확인해야 하거나 다른 팀의 분석이 필요한 문의였습니다.
담당자가 티켓을 열어본 뒤에도 필요한 정보를 찾고, 누구에게 물어봐야 하는지 판단하고, 답변에 필요한 근거를 정리해야 했습니다.
첫 응답까지 3시간에서 48시간이 걸릴 수 있었습니다. 고객이 경험한 제품 문제처럼 담당 팀을 바로 특정하기 어려운 사안은 실제 대응까지 2주 이상 걸리기도 했습니다.
이 프로세스에서 가장 비싼 작업은 답변 문장을 작성하는 일이 아니었습니다.
- 문의를 처음 발견하기까지 기다리는 시간
- 여러 시스템에서 정보를 수집하는 시간
- 문제 유형과 처리 절차를 판단하는 시간
- 적절한 담당자를 찾는 시간
- 답변에 필요한 근거를 다시 정리하는 시간
하나의 처리를 하기 위해 매번 반복적으로 하고 있던 작업들이었습니다.
에이전틱한 플랫폼을 만들지 않았습니다.
저는 티켓의 처리 흐름을 분석하고, LangGraph 각각의 프로세스를 구현하도록 설계했습니다.
- 문의 유형을 분류한다.
- 사용자와 결제 정보를 조회한다.
- 처리에 필요한 내부 정보를 수집한다.
- 가능한 처리 절차를 선택한다.
- 답변 초안을 작성한다.
- 사람의 검토가 필요한 조건을 판단한다.
- 필요한 경우 관련 담당자에게 문제를 전달한다.
최근에는 openclaw와 같은 딥에이전트 시스템이 인기를 끌고 있지만, 의도적으로 그런 자율 행동 프레임워크를 피했습니다. 최근 10,000개의 티켓들을 기준으로 문의 분류, 데이터, 처리 순서 등 그래프 정의를 진행하고 그 과정 속에서 일부 프로세스만 소형 모델을 차용했습니다.
제 목표는, 유지보수 가능하고 통제 범위 이내에서만 제한적으로 사용하는 simple agent+graph 체계였습니다. 그래야만, 모델에 고객 응대의 특성이 결정되지 않고 우리가 결정한 프로세스가 이를 관리할 수 있기 때문입니다.
93%나 사람에게 전달하는 이유
초기에는 75%이상 자동 처리를 목적으로 했으나, 현재 버전에서는 7%를 제외한 93%케이스에서 CS담당자 혹은 팀에게 정보를 전달하고 있습니다.
그 이유는, 개발 및 테스트 과정에서 더 중요한 것이 응답을 진행하는 이상으로 중요한 것들을 발견했기 때문이었습니다.
- 환불이나 계정 변경처럼 정책 판단이 필요한 경우
- 제품이나 코드 문제를 담당 팀에 전달해야 하는 경우
- 기존 처리 규칙에 없는 예외가 발견된 경우
응답을 바로 하는 것보다, 티켓을 처리하는 데 필요한 조사와 분석이 오히려 병목인 것을 파악하여 이 과정의 파이프라인에 집중하고, 메시지 응답을 작성하는 것은 아직까지 사람의 검수 후에 발송하도록 했습니다. 앞으로 운영 뒤에는 자동 발송까지 할 수 있겠지만, 현재 단계에서 바로 하는 것이 적절치 않다는 것을 느꼈습니다.
초기 분석과 정보 제공이 빠르게 이루어지면서, 개별 근무자들의 관심, 분석이 달라졌고 VOC가 제품 개발에 반영 되는 비율도 75%이상으로 상승했습니다.
AI 자동 응답 비율을 성공 지표로 생각하지 않기
이 프로젝트를 처음으로 진행하면서 느꼈던 것은, 단순히 AI 시스템이 인간 근무자를 대체하는 것이 중요하지 않다는 점입니다. CS 매니저가 엑셀로 정리해서 누군가에게 전달해야되던 문서를 실시간으로 바꾸고, 매일 한 명씩 찾아보던 정보들이 한 곳에 조사되도록 하는 일들을 지속가능한 시스템으로 만드는 일이었습니다.
이번 프로젝트는 좁게 생각하기보다 우리 팀이 더 빠르고 정확하게 문제를 해결하고, 더 적은 반복 작업으로 더 많은 문제를 처리하게 만드는 것이었다고 생각합니다.
모든 조사가 즉시 시작됨으로써
CS 매니저는 빠르게 고객에게 메시지를 전달하는 데 집중하게 되었습니다.
개발자는 별개로 티켓의 문제를 인지하고 해결할 수 있게 되었습니다.
문제점과 의사소통이 기록되어 분석, 추적 가능해졌습니다.
문의가 접수되면 10초 이내에 분류, 정보 조회가 끝나고 슬랙에 정보와 제품 문제가 팀에 전달됩니다.
CS 효율화 → 라이너 운영 시스템
바이브 코딩의 실패
만들기 시작 후 첫 테스트까지 근무일 기준 10일 정도가 걸렸고, 저는 시급성에 집중했기 때문에 oh my claude code로 ralph loop 형태의 개발을 진행했습니다. 첫 테스트까지 80개의 pr을 통해 만들었는데, 배포 후 다시 2주 간 시스템의 문제를 해결하기 위해 150개의 pr을 적용 해야 했습니다.
빠른 구현이 예외 상황, 상태 전이, 기능 간 상호작용에서 많은 약점을 보였기 때문입니다.
저에게 전달 된 요구사항들이 완벽하지 않았기 때문에, 이것이 곧 설계상 허점으로 이어졌고, 테스트 케이스로 존재하지 않는 엣지 케이스들이 전체 케이스의 50% 이상이었습니다.
처음부터 과거 티켓들을 분석해서 설계했거나, 혹은 아키텍처 상의 플로우를 좀 더 인간이 개입해서 설계했다면 분명 나았을 부분들이 많이 있었습니다. 모호한 요구사항으로부터 진행한 에이전틱 코딩의 분명한 한계를 시험한 것 같습니다.
완벽함보다 단순한 해결책
초기에는 Zendesk Webhook과 Slack Interaction을 연결해 이벤트를 실시간으로 처리하려 했습니다.
구조적으로는 더 세련돼 보였습니다.
그러나 실제 운영에서는 Webhook이 누락되거나, 중간 단계만 실패하거나, Slack과 Zendesk의 상태가 서로 달라지는 문제가 발생했다. 실패한 이벤트를 다시 실행하기도 어려웠다.
고민 끝에 주기적인 polling 방식으로 변경했습니다.
인터페이스는 핵심 로직들이 제대로 돌아가고 난 뒤로 중요했던 것 같아서, 제가 초창기에 너무 완벽하게 만들려 했던 것은 확실히 아쉬웠더 부분입니다.
첫 AX 프로젝트 - 성공? 실패?
현재 시스템은 제가 생각하는 초기본하고는 많이 다른 것 같습니다.
자율 상담도 없고, self-healing도 없습니다. 많은 부분들을 사람들에게 전달하고 있고, 고도화 되어야 할 부분들
- 권한
- 감사 로그
- 중복 처리 방지
재처리 구조도 더 정교하게 만들어야 합니다. 그치만, 저에게는 작게나마 성공적인 부분들이 있는 것 같습니다. 이 프로젝트를 통해서 회사의 여러 이해 관계자들이 일하는 방식을 이해하고, 사람들의 중앙에서 연결하고 시간을 줄이는데 성공해서입니다.
- 티켓의 분석과 조사가 누군가를 기다리지 않아도 된다.
- 사람이 여러 시스템에서 정보를 직접 수집하는 작업이 줄었다.
- 직접적인 사람의 투입량이 줄었다.
이제 이 프로젝트는 사람의 개입을 조금 더, 점점 더 줄일 수 있도록 발전할 것입니다.
그러나, 사람이 문제를 발견하고 이해하고 판단하기까지 필요했던 마찰을 얼마나 제거했는가?
이것이 결론적으로는 가장 중요하다는 생각과 함께 이 글을 마칩니다.
댓글 남기기