AI 상담 에이전트 2종 — 네이버 톡톡 · 스마트스토어

2025.09 ~ 2026.08 · FastAPI · LangGraph · LangChain · OpenAI · Gemini · Supabase · Cloud Run
팀 구성 — 개발 1(본인) · 운영 2 · 3인

상담사가 받던 1차 응대를 봇이 맡게 했습니다. 운영 로그 28,017턴 기준 자동 응답률 89.1%,
상담이 돌지 않는 시간에도 6,238명이 답을 받았습니다.
답의 내용은 서버가 확정하고 모델은 문장으로만 옮기게 해서입니다.

이 문서는 배경 → 문제정의 → 해결방안 → 결과 → 정직하게 순서입니다. 이력서의 AI 상담 절과 같은 틀이고, 이력서의 각 줄은 아래 ①②③ 블록의 첫 문장입니다.

배경 — 상담사가 받던 1차 응대

문의는 한꺼번에 몰리고, 상담사는 한 번에 한 사람을 상대합니다. 하루 중 가장 붐빈 한 시간에는 중앙값 6명, 열에 하루는 11명 이상, 많게는 25명이 같은 한 시간 안에 묻습니다(운영 로그 28,716턴). 그 시간에 나머지는 기다립니다. 그리고 상담 운영시간(평일 10:00~17:00) 밖이면 아예 받지 못합니다 — 문의의 49.8%가 그 시간에 들어옵니다.

그래서 봇이 초기 대응을 맡고, 상담사는 판단이 필요한 것만 받게 했습니다. 채널은 둘입니다. 톡톡은 말로 답하고, 스마트스토어는 취소 사유를 판정합니다(주문 캡처 이미지 판독 포함). 하는 일은 같습니다 — 상담사가 하던 1차 응대를 대신합니다. 톡톡에서 먼저 만들고 같은 구조를 스마트스토어로 옮겼습니다.

문제정의 — 왜 어려운가

1차 응대를 봇에게 맡기면 처리량 문제는 풀리지만, 봇이 틀린 금액이나 날짜를 자신 있게 말하면 그대로 사고가 됩니다. 고객은 그 답을 믿고 움직이고, 답은 화면에 남습니다. 처리량과 신뢰 사이의 이 긴장을 셋으로 나눴습니다.

① 문의를 어떻게 분류하고, 의도마다 무엇을 볼까

• 문의는 한 종류가 아닙니다 — 상품 상세, 예약 가능 여부, 예약 확인, 바우처, 취소와 환불, 상품 요청사항 전달, 후기, 범위 밖. 의도마다 답의 출처가 다릅니다. 상품 상세는 상품 시스템, 예약 확인은 예약 시스템, 취소 수수료는 서버가 계산한 규칙, 상품 요청사항 전달은 상담사. 착수 전 현업이 정리한 문의 유형 33종의 확인 경로가 이걸 보여줬고, 14종은 예약 시스템을 봐야 답이 나왔습니다.
• 봇이 예약을 바꾸거나 취소하면 되돌릴 수 없습니다. 그래서 봇에게는 조회와 안내만 맡기고, 예약·주문을 바꾸는 일은 처음부터 범위 밖에 둬야 했습니다.
• 어디까지 봇이 답할지 선을 그어야 합니다. 전부 상담사에게 넘기면 봇을 둔 의미가 없고, 전부 봇이 답하면 사고가 납니다.
• 스마트스토어는 3개월치 문의 198건 중 자동화 가능 판정이 116건(58.6%)이었습니다. 나머지는 처음부터 봇의 일이 아니었습니다.

② 답의 사실은 어디서 올까

• 취소하면 얼마가 빠지는지, 언제까지 무료인지를 모델이 지어내면 고객은 믿습니다.
• 프롬프트로 막는 것은 확률적 방어입니다. 계산 금지를 걸어 두고 실제 대화를 재생하니 세 번에 한 번은 모델이 그대로 계산해서 답했습니다.
• 모델이 틀리는 원인이 둘로 갈립니다. 주지 말았어야 할 것을 준 경우와 믿을 수 없는 것을 사실로 준 경우입니다.
• 시간 표현이 특히 위험합니다. 한 문장에 관광지 운영시간·소요시간·상담센터 시간이 섞여 나오는데 모델은 이 셋을 곧잘 헷갈립니다. "불광산 월,수~금 09:00~18:00" 과 "10:30 소요" 는 생김새가 비슷합니다.
• 스마트스토어는 취소 사유가 세 시스템에 흩어져 남습니다. 어디를 믿을지가 먼저입니다.

③ 문제가 생겼을 때 확인부터 검증까지 어떻게 빠짐없이 돌릴까

• 봇의 오답은 상담사 제보로 알게 됩니다. 그다음이 문제입니다 — 같은 사고를 풀려면 처리 기록 · 서버 로그 · 대화 로그 세 곳을 열어 대조하고, 원인을 찾고, 인접한 곳에 같은 버그가 없는지 보고, 고치고, 고객이 실제로 받을 문장으로 검증해야 합니다. 사람이 손으로 하면 느리고 단계를 빠뜨립니다.
• 단위 테스트로는 안 끝납니다. 핸들러 · 에이전트 · 도구 · 프롬프트 렌더링까지 다 태워야 실제 고객이 받는 문장이 나옵니다. 업무시간·마감 같은 시각 의존 버그는 지금 시계로는 재현되지 않습니다.
• 고친 뒤 과거에 같은 패턴이 얼마나 있었는지, 개선안이 정말 나은지도 감으로는 모릅니다.

해결방안 — 무엇을 했나

전체 그림부터 봅니다. 아래는 지금 돌고 있는 모습입니다. 어떻게 이 모양이 됐는지는 ①②③에서 다루고, 여기서는 조각의 위치만 봅니다.

• 봇과 사내 시스템 사이의 화살표는 조회뿐입니다. 예약을 만들거나 바꾸는 선은 없습니다(→ ①).
• 모델은 마지막에만 있습니다. 상품 상세든 바우처 절차든 취소 수수료든, 답의 내용은 앞에서 확정되고 LLM은 그것을 문장으로 바꾸는 자리에만 섭니다(→ ②).
• 상담사 이관은 실패 경로가 아니라 정식 출구입니다. 분기에서 갈라져 나가는 선으로 그려져 있습니다(→ ①).
• 모든 턴이 로그로 남습니다. 봇이 답했는지 넘겼는지, 범위 안이었는지가 함께 적재됩니다. 자동 응답률과 운영시간 외 응대를 나중에 잴 수 있었던 근거입니다(→ 결과).

① 문의를 의도별로 분류해 의도마다 필요한 조회 도구만 붙였고, 판단이 서지 않으면 상담사에게 넘기게 했습니다

봇은 읽기만 합니다. 도구는 전부 조회입니다. 예약 상태, 상품 상세와 옵션, 바우처 발급 여부, 환불 규정을 읽어 오는 것까지이고, 예약이나 주문을 바꾸는 일 — 변경·취소·환불 처리 — 은 어느 의도에도 없습니다. 스마트스토어의 "취소 사유 판정"도 판정 결과를 내놓는 것까지이고 시스템에 쓰지 않습니다. 잘못 판단해도 되돌릴 수 없는 일이 생기지 않게 하려는 경계입니다.

범위는 착수 전에 정했습니다. 톡톡은 현업이 문의 유형 33종을 "이 답이 어디에 있는지"로 매핑한 표로 연결할 도구를 정했고, 스마트스토어는 3개월치 문의 198건을 분류·판정한 표로 자동화 범위를 잡았습니다 — 무엇을 안 할지가 먼저 정해진 셈입니다.

두 채널은 문의를 분류하는 방식이 다릅니다.

톡톡은 프롬프트 한 파일이 분류·슬롯·결정 트리·응답 규칙을 다 들고 있어 1,356줄까지 자랐습니다. 그래서 톡톡에도 스마트스토어식 라우팅을 넣어 봤습니다(2026-05) — 의도 판별기와 의도별 라우터, 골든 대화 234건, 섀도우·단계 배포 장치까지 만들고 기본은 꺼 둔 채 올렸습니다. 일주일 뒤 전부 되돌렸습니다. 결과가 나빠서가 아닙니다. 의도마다 책임이 하나로 분명해지는(단일 책임) 대신, 라우팅된 의도끼리 공유해야 할 대화 메모리를 따로 설계해야 했고 그 부가 설계가 이득보다 컸습니다. 톡톡의 프롬프트 하나짜리 의도 판별을 개선하려고 스마트스토어는 라우팅으로 만들었지만, 둘 다 득과 실이 있었습니다. 라우팅은 의도마다 책임이 분명한 대신 의도끼리 공유할 대화 메모리를 따로 설계해야 하고, 하나의 창구는 그 설계가 필요 없는 대신 프롬프트가 자랍니다. 톡톡은 하나의 창구로, 스마트스토어는 라우팅으로 둔 채, 처리 측면에서는 하나의 창구로 받는 편이 낫다는 것이 지금의 판단입니다.

판단이 서지 않으면 상담사에게 넘깁니다. 이관은 봇이 못 해서 생기는 실패가 아니라 설계된 출구입니다. 취소·환불 의도는 처음부터 "요청은 처리 불가 → 규정 안내 후 상담사 연결" 로 정해 두었습니다 — 조회와 처리의 경계가 분류 단계에 박혀 있습니다. 로그로 확인하면 그렇습니다 — 업무 범위 밖 문의는 전부 봇이 응답했고, 이관은 전부 범위 안에서 일어났습니다. 봇은 "모르는 것"을 넘긴 게 아니라 "알지만 확신이 안 서는 것"을 넘겼습니다.

대신 포기한 것 — 자동화율입니다. 이관 10.9%를 남겼습니다. 이 숫자는 0으로 만들 수도 있었습니다. 넘기지 않으면 됩니다. 그 대가를 고객이 치릅니다.

② 답의 내용은 서버가 확정하고 모델은 문장으로만 옮기게 했고, 애매하거나 믿을 수 없는 값은 모델에 주기 전에 뺐습니다

환각을 막는 방법으로 "프롬프트에 조심하라고 쓴다"는 통하지 않습니다. 실제 대화를 여러 번 재생해 확인한 사실입니다. 프롬프트에 계산 금지를 걸어 두고 재생하니 세 번에 한 번은 모델이 그대로 계산해서 답했습니다. 프롬프트는 확률적 방어라 언제 뚫릴지 알 수 없고, 뚫린 그 한 번이 고객 화면에 남습니다.

그래서 결론을 만드는 자리를 모델 밖으로 옮겼습니다. 다루는 주제는 상품 상세·예약 상태·예약 가능 여부·바우처·취소와 환불까지 넓지만, 어느 주제든 답의 재료는 두 종류뿐입니다.

모델은 이 둘을 받아 문장으로 바꾸기만 합니다. 계산도 판단도 모델 밖에 있으니 같은 입력이면 같은 답이 나오고, 사후에 "왜 이 답이 나갔나"를 코드에서 되짚을 수 있습니다.

무엇을 답하게 할지보다 무엇을 주느냐가 먼저였습니다. 모델이 틀린 두 사건 모두 프롬프트를 고치지 않고 컨텍스트에서 뺐습니다.

주지 말았어야 할 것 — 고객이 현지 가이드 이름을 묻자 봇이 사내 담당자 이름을 "배정된 가이드"라고 단언했습니다. 고객이 정정하자 없는 명단까지 지어냈습니다. 처음에는 환각으로 보였지만, 처리 기록을 열어 보니 그 이름이 실제로 도구 응답 안에 들어 있었습니다. 환각이 아니라 데이터 누출이었습니다. 원인은 필드 필터가 막을 것을 나열하는 방식이었다는 데 있습니다. 결제·연락처 몇 개만 막아 두었으니 그 목록에 없는 내부 필드는 전부 통과했습니다. 내부 전용 필드를 목록으로 세워 응답을 만드는 세 경로 전부에서 일관되게 제거하고, 프롬프트에는 "가이드 인명 데이터는 갖고 있지 않다" 는 백스톱을 뒀습니다. 구조로 한 번, 문장으로 한 번입니다.

믿을 수 없는 것 — 봇이 집결 시각을 "공식 확인된 시각"이라며 고객을 세 턴에 걸쳐 반박한 일이 있었습니다. 고객이 맞았습니다. 그래서 그 필드를 얼마나 믿을 수 있는지 상품 2,076건을 전수 대조했습니다.

필드 자체가 사실이 아니었습니다. 같은 방식으로 훑어 믿을 수 없는 필드를 골라내 컨텍스트에서 지웠습니다. 값이 있다고 사실인 것은 아니어서, 모델에 넣기 전에 그 값이 사실인지를 먼저 쟀습니다.

애매하면 버립니다. 시간 표현은 특히 위험해서 별도 게이트를 뒀습니다. 운영시간·소요시간·참고값처럼 헷갈리기 쉬운 표현이 걸리면 애매한 쪽을 버리고, "확인이 어렵다 + 바우처나 상담사로 안내"로 끝냅니다. 틀린 시간을 말하는 것보다 모른다고 말하는 편이 낫습니다.

스마트스토어는 취소 사유가 세 시스템에 흩어져 남습니다. 어디를 먼저 믿을지 순서를 정해 조회하고, 확정이 안 되면 추정하지 않습니다.

대신 포기한 것 — 커버리지와 모델의 자율성입니다. 게이트가 애매한 것을 버려서 답할 수 있었을지도 모르는 문의까지 "확인 어렵다"로 가고, 서버가 확정한 값만 말하니 문장이 뻣뻣해집니다. 그리고 누출을 막을 때 원칙(허용할 필드만 통과시키는 방식) 대신 막을 것을 넓히는 쪽을 골랐습니다 — 라이브에서 고객 응답이 나가는 중이라 쓰던 필드를 건드리지 않는 편이 안전했고, 데이터 출처마다 필드 이름 규칙이 달라 허용 목록 한 벌로 덮이지 않았습니다. 원칙과 지금 안전한 것이 갈릴 때 후자를 골랐고, 그 이유를 기록으로 남겼습니다.

③ 사고 대응을 제보 확인·로그 분석·원인·수정·검증의 워크플로우로 만들어 에이전트가 돌리고, 사람은 리뷰와 배포 판단만 맡게 했습니다

제가 직접 하던 절차를 워크플로우로 정의했습니다. 사고가 나면 제가 처리 기록과 서버 로그와 대화 로그를 차례로 열고, 대조하고, 고치고, 재현해 보던 일입니다. 매번 손에 익은 대로 하다 보니 순서가 달라지고 단계를 건너뛰었습니다. 그 절차를 확인 → 분석 → 수정 → 검증 네 단계로 고정해, 상담사 제보가 올라오면 에이전트가 받아서 돌리게 했습니다(2026-04). 검증은 웹훅 페이로드를 재생해 고객이 실제로 받을 문장으로 전후를 입증하고, 끝나면 과거 처리 기록을 소급 스캔해 같은 패턴이 남아 있는지 셉니다. 에이전트는 PR을 만드는 것까지 하고 머지와 배포는 사람이 합니다. 스마트스토어 봇도 같은 워크플로우를 씁니다. 사건마다 재생 테스트를 함께 남깁니다 — 프롬프트에 계산 금지를 걸어도 세 번에 한 번 뚫린다는 것도 이 재생으로 알았습니다. 어떻게 만들었고 무엇을 버렸는지는 별도 케이스로 다룹니다(→ 케이스 6 — 챗봇 인시던트 대응 에이전트).

실험해서 아니면 접습니다.

• 주문 캡처 이미지를 한 장으로 읽던 것을 나눠 읽게 바꿔 재보니 추출량이 405자 → 1,202자로 늘었습니다. 채택.
• 프롬프트 개정안을 만들어 같은 방식으로 재보니 24문항 중 정답이 23 → 22로 나빠졌습니다. PR을 접고 작업본을 버렸습니다.
• 특정 케이스를 사전에 등록해 두는 방식을 각 80회씩 4개 조건, 320회 돌려 봤습니다. 개선 0. 채택하지 않았습니다.
• 톡톡에 의도별 라우팅을 넣어 봤다가 일주일 뒤 되돌린 것(→ ①)도 같은 결입니다.

대신 포기한 것 — 손에 익은 즉흥 대응입니다. 정해진 순서는 빠르게 느껴지지 않을 때가 있습니다. 그리고 처음 발견은 여전히 사람 몫이고, 이 워크플로우가 시간을 얼마나 줄였는지는 재지 못했습니다(→ 정직하게).

무엇을 버리고 무엇을 샀나

결과 — 측정과 지금 상태

운영 로그를 세 번 집계했습니다(스냅샷이 달라 출처를 각각 적습니다).

상담이 돌지 않는 시간 (28,550턴 · 2025-10 ~ 2026-08)

• 상담 운영시간(평일 10:00~17:00) 밖에 들어온 문의 49.8% · 그중 봇이 답한 비율 90.7% — 운영시간 안(87.6%)보다 높습니다
• 그 시간에 봇의 답을 받은 사용자 6,238명

자동 응답 (28,017턴 · 사용자 10,457명)

• 자동 응답률 89.1% · 업무 범위 안 문의만 보면 85.7%
• 이관율 14.1% → 8.9%(2026-01 대비 37% 감소) · 타임아웃·오류 1.92% → 0.58%(70% 감소) · 응답 p50 8,008ms → 6,530ms

몰림 (28,716턴 · 306일) — 일별 사용자 중앙값 39명(최대 125명), 하루 중 가장 붐빈 한 시간의 사용자 중앙값 6명 · 열에 하루는 11명 이상 · 최대 25명.

스마트스토어가 받는 문의의 무게중심 (봇 대화 로그 1,094세션 · 2026-04-13 ~ 07-14) — 운영 석 달의 고객 발화 2,255건을 분류하니 취소·환불 계열(실행 요청 · 이의 · 규정 문의)이 23.4%로 1위였습니다. 라벨 신뢰도는 감사표본 124건을 세 번 다시 붙여 98.4% 일치. 봇을 놓기 전 근거가 아니라 운영 석 달 뒤에 확인한 것이고, 이 분류는 봇의 의도 체계와 독립적으로 데이터에서 만들었습니다.

어떻게 쟀나. 턴마다 봇이 답했는지 넘겼는지와 업무 범위 안이었는지를 함께 적재해 뒀습니다. 그래서 "자동 응답률"을 사후에 정의해 넣지 않고 로그에 이미 있는 축으로 나눠 셀 수 있었습니다. 상담 운영시간은 코드 상수에서 가져왔습니다.

지금 상태

• 두 채널 모두 운영 중. 톡톡은 말로 답하고, 스마트스토어는 취소 사유를 판정합니다.
• 외부 연결 없이 도는 테스트로 실제 대화를 코드 안에서 재생해 봇이 보낼 문장을 검증합니다. 사건마다 회귀 테스트와 재생 테스트를 함께 남깁니다(집계는 케이스 6).
• 주문 링크에서 주문번호를 뽑을 때 도메인을 검증합니다. 유사 도메인을 거부하는 테스트가 함께 있습니다.
• 사고 대응 — 확인 → 분석 → 수정 → 검증 네 단계 워크플로우로 처리합니다(2026-04부터). 스마트스토어 봇도 같은 워크플로우를 씁니다(상세는 케이스 6).
• 어떻게 알아채나 — 처음 발견은 사람입니다. 이 케이스의 가이드 이름·시간대 오안내 두 사고 모두 상담사가 알렸고, 봇 전용 Slack 모니터링 채널은 사람이 봅니다. 제보가 오면 처리 기록(LLM 추적)과 서버 로그 두 곳을 엽니다 — 가이드 이름 사건은 추적에 그 값이 찍혀 있어서 환각이 아니라 누출로, 시간대를 정반대로 안내한 사건은 추적에 도구 호출이 한 건도 없어서 데이터가 아니라 프롬프트 문제로 판명됐습니다. 같은 증상이라도 어디를 보느냐로 원인이 갈립니다.
• 되돌리기 — 리비전 전환 한 번. 실제로 한 번 했습니다 — 배포 직후 대화 로그 적재가 전부 실패했을 때(적재 성공 0건, 고객 응답에는 영향 없음) 이전 리비전으로 즉시 되돌린 뒤 원인을 찾았습니다. 두 봇이 서로 다른 저장소를 본다는 것을 놓친 제 실수였고, 고친 뒤 다시 올렸습니다.
• 지금 누가 고치나 — 지금도 제가 고칩니다. 최근 변경은 2026-08입니다.

정직하게 — 한계와 다음 문제

• "전체 CS 문의의 몇 %를 자동화했나"는 답할 수 없습니다. 로그에는 봇에 들어온 문의만 있습니다. 전화·다른 채널로 간 문의는 이 집계 밖이라 자동화 비중을 말하려면 채널 전체 문의량이 필요한데, 그 소스를 아직 찾지 못했습니다. 그래서 대신 댄 숫자가 위의 "상담이 돌지 않는 시간"입니다 — 분모 논쟁이 없는 숫자입니다.
• "그 시간대에 종전 응대가 0건이었다"는 로그로 증명하지 못했습니다. 상담 운영시간이 평일 10~17시라는 것은 코드 상수로 확인되지만, 그 밖의 시간에 상담사가 한 건도 응대하지 않았다는 것은 로그에 없는 전제입니다. 그래서 "0에서 6,238로"라고 쓰지 않았습니다.
• 가이드 이름·시간대 오안내 두 사고 모두 상담사가 먼저 발견해 알렸습니다. 자동 탐지 시스템은 없고, 재발 탐지기는 알려진 패턴의 사후 스캔입니다(집계는 케이스 6). 자동 알람도 없습니다 — Slack 채널을 사람이 봅니다.
• 사고 대응 워크플로우가 시간을 얼마나 줄였는지는 재지 못했습니다. 제보 시각이 기록으로 남지 않아 전후 비교가 안 됩니다. 그 한계의 상세는 케이스 6의 정직하게에 있습니다.
• 이관율이 37% 줄어든 것이 전부 개선 덕이라고 말할 수 없습니다. 같은 기간에 문의 구성도 바뀌었고, 둘을 분리해 낼 비교 대상이 없습니다. 방향은 분명하지만 인과는 단정하지 않습니다.
• 스마트스토어의 판정 정확도는 못 쟀습니다. 대화 로그에 720턴만 적재돼 있어 대표성이 없습니다. 골든셋 대비 정확도를 낼 재료(벤치마크·오분류 탐지기)는 있으니 다음에 뽑을 수 있습니다.
• "현업 판정 58.6%"는 착수 근거이지 성과가 아닙니다. 현업이 "자동화할 수 있겠다"고 판단한 비율이고, 실제로 그만큼 자동화됐다는 뜻이 아닙니다. 성과는 위의 자동 응답률로 말합니다.
• "1,094세션 분류"는 착수 근거가 아니라 운영 석 달 뒤 분석입니다. 설계 중심을 정한 근거로 쓰지 않습니다.
• "같은 시간에 25명"은 정각 기준 한 시간 버킷입니다. 동시 접속이 아니고, 톡톡을 받는 상담사가 몇 명인지도 확인하지 못했습니다. 그래서 "상담사 한 명"이라고 쓰지 않고 "한 번에 한 사람을 상대한다"로만 썼습니다.