AI TOP 100에서 「교동마을 산지직송」의 고객 문의를 처리하는 카카오톡 상담 에이전트를 만들었습니다. 배송 조회나 환불 안내부터 개인정보 보호, 가격 차액 보상, 규정 충돌까지 다뤄야 하는 과제였습니다.

처음에는 고객 질문에 맞는 문서를 찾아 답하면 될 것처럼 보였습니다. 하지만 실제로는 필요한 지식부터 직접 모아야 했고, 답변뿐 아니라 조회·접수·이관까지 정확하게 처리해야 했습니다. 고객의 요구를 어디까지 받아들일지, 어떤 사실을 확인한 뒤 행동할지도 구현해야 했습니다.

개발과 자료 정리에는 Claude를 활용했습니다. 다만 실제 상담을 수행한 모델은 gpt-4o-mini였습니다. 작업 기록상 사용할 수 있는 채팅 모델에 제약이 있어, Claude와 함께 개발하면서 상담 모델의 한계를 프롬프트 구성과 코드로 보완하는 방향으로 진행했습니다.

1. 문제 유형: 정보를 모으고, 판단하고, 실제로 처리하기

과제는 마을 관계자를 인터뷰해 운영 지식을 확보하고, 그 지식을 바탕으로 고객 상담을 수행하는 것이었습니다. 공개된 자체 검증용 테스트케이스는 15개였고, 별도의 비공개 시나리오로 평가하는 방식이었습니다.

테스트케이스를 읽을 때 먼저 구분한 것은 에이전트가 아는 정보와 모르는 정보였습니다. 고객의 첫 메시지와 인입 계정 정보는 알 수 있지만, 시나리오에 적힌 숨은 상황과 기대 대응은 미리 아는 정보가 아니었습니다. 필요한 사실은 고객에게 묻거나 API로 조회하고, 판단 기준은 인터뷰와 문서에서 확보해야 했습니다.

문제 유형을 풀이 관점에서 묶으면 다음과 같습니다.

예를 들어 “배송이 늦으니 환불해 주세요”라는 요청에서도 어떤 주문인지, 실제 배송 상태가 어떤지, 고객이 환불과 재출고 중 무엇을 원하는지 확인해야 했습니다. 말로 환불을 안내하는 것과 실제 접수 API를 실행하는 것은 서로 다른 단계였습니다.

2. 첫 번째 풀이: 사람 → 문서 → 다시 사람

가장 먼저 한 일은 운영 지식을 모으는 것이었습니다. 상담 담당자에게 담당 영역을 묻고, 소개받은 관계자에게 질문했습니다. 문서에 근거가 있다는 답을 받으면 자료를 확보하고, 읽은 뒤 빠진 부분을 다시 물었습니다.

질문하는 방식도 바뀌었습니다. 처음에는 담당 업무나 규정을 넓게 물었는데, “하나만 골라 달라”는 답이 돌아오는 경우가 있었습니다. 이후에는 “송장 알림은 왔는데 이틀째 조회되지 않는다면 어떻게 처리하나요?”처럼 실제 상황을 좁혀 질문했습니다.

인터뷰 내용은 사람별 원문 기록으로 보존하고, 상담에 사용할 지식은 배송·환불·결제·프로모션·개인정보 등 주제별 정책으로 다시 정리했습니다. 사실마다 담당자와 문서 조항을 출처로 남겼고, 서로 다른 답은 지우지 않고 충돌 또는 모호한 항목으로 표시했습니다.

최종 디브리프에는 관계자 11명, 문서 45건, 주제별 정책 10개, 130여 건의 문답을 정리한 것으로 기록돼 있습니다. 자료가 쌓일수록 중요한 것은 수량뿐 아니라, 그 내용을 어디에 반영했고 어떤 질문이 아직 남아 있는지 관리하는 일이었습니다.

이를 위해 카카오톡 대화를 붙여 넣으면 인터뷰 기록, 질문 수, 질문 큐를 함께 갱신하는 반자동 콘솔도 만들었습니다. 질문 발송은 직접 하고, 반복되는 기록 정리를 도구가 맡도록 했습니다.

3. Claude 활용: 코드 작성과 지식 정리를 함께 진행하기

Claude와 함께한 작업은 서버 구현부터 인터뷰 문서 정리, TC 근거 보강, 문서 간 충돌 점검까지 이어졌습니다. 작업 이력에는 다른 Claude 세션에서도 인터뷰 기록과 문서 정리를 함께 진행한 내용이 남아 있습니다.

먼저 저장소의 자료를 역할별로 나눴습니다. 대회 원문은 contest/, 수집한 운영 지식은 knowledge/, 검증 시나리오는 testcases/, API 명세는 docs/로 정리했습니다. 원문과 인터뷰로 얻은 사실, 검증을 위한 기대 대응을 구분해 두는 구조였습니다.

그다음 상담 서버와 API 호출을 연결했습니다. Spring Boot와 Java 21을 사용하고, 카카오 봇 게이트웨이에서 메시지를 받아 LLM이 조회·접수 API를 도구로 호출하도록 구성했습니다. Docker로 배포하고, 지식 폴더를 읽기 전용으로 마운트해 문서를 수정한 뒤 다시 읽을 수 있도록 했습니다.

API 명세의 40종 액션은 도구 정의로 연결했습니다. 주문과 배송을 조회하고, 고객이 선택한 처리에 따라 접수하거나 담당자에게 이관하는 흐름입니다. 대화별 기억에는 도구 실행 결과도 남겨, 다음 턴에 접수번호나 처리 결과를 이어서 안내할 수 있게 했습니다.

Claude를 활용한 과정에서 글로 남길 만한 부분은 작업을 구체적으로 나눴다는 점입니다. 인터뷰 원문을 정리하는 일, TC에 필요한 근거가 있는지 확인하는 일, 실제 API 호출과 응답을 점검하는 일을 각각 진행했습니다. 이 과정을 거치며 단순히 기능을 추가하는 것보다, 빠진 근거와 잘못된 행동을 찾아 수정하는 작업의 비중이 커졌습니다.

4. 두 번째 풀이: 모든 문서를 넣는 대신 필요한 지식 고르기

자료를 충분히 모으면 상담 정확도가 좋아질 것이라고 기대했지만, 긴 프롬프트가 바로 해결책이 되지는 않았습니다. 작업 이력에는 약 12만 자의 프롬프트를 사용했을 때 gpt-4o-mini가 내용을 제대로 처리하지 못해 TC가 실패한 과정이 기록돼 있습니다.

이를 보완하기 위해 문의의 키워드로 주제를 선택하고, 관련 정책과 문서만 프롬프트에 넣도록 바꿨습니다. 공통 응대 원칙은 항상 포함하고, 배송 문의에는 배송 관련 지식을, 가격이나 할인 문의에는 프로모션·가격 정책을 추가하는 방식입니다. 선택된 문맥은 대략 2만~4만 자 수준으로 줄였습니다.

이때 사용한 것은 키워드 기반의 주제 선택입니다. 별도의 벡터 검색을 구축한 방식은 아니어서, 키워드가 드러나지 않거나 여러 주제가 섞인 문의에서 필요한 문서가 빠질 수 있다는 한계도 남았습니다.

처리 절차도 명확히 반복했습니다. 문의 대상 주문을 특정하고, API로 사실을 조회하고, 정책과 대조한 뒤, 필요한 확인이나 고객 선택을 거쳐 접수하고 답하도록 했습니다. 문서를 많이 제공하는 것과 모델이 필요한 근거를 올바른 순서로 사용하는 것은 별개의 문제였습니다.

5. 세 번째 풀이: 중요한 제약은 코드에서도 확인하기

에이전트의 중심 원칙은 다음과 같았습니다.

근거 없이 확답하지 않고, 근거가 있는 것은 끝까지 처리하는 상담원.

확인되지 않은 도착일이나 배상액을 지어내지 않되, 근거와 권한이 갖춰진 요청은 실제 처리까지 이어가도록 설계했습니다.

하지만 프롬프트에 적는 것만으로는 부족했습니다. 다른 회원의 주문을 노출하거나, 고객이 고르지 않은 환불·재배송을 접수하는 행동은 코드에서도 제한했습니다. 첫 메시지에서 바로 접수하지 못하도록 하고, 접수 대상은 고객이 지목한 주문으로 한정했습니다. 카드 결제에 대한 현금영수증 처리도 차단했습니다.

답변과 실행 결과가 어긋나는 문제도 다뤘습니다. 실제 접수하지 않았는데 “접수했습니다”라고 답하면 다시 생성하도록 했습니다. 고객에게 처리 완료를 안내하려면 실제 도구 실행 결과가 있어야 했습니다.

가격 인하 차액 보상은 이 흐름을 잘 보여주는 사례였습니다. 고객이 “20% 세일 중”이라고 말해도 그 수치를 사실로 받아들이지 않고, 주문의 구매가와 상품의 현재가를 조회해야 했습니다. 차액을 계산하고 정책에 맞는 보상 쿠폰을 검토한 뒤, 고객 동의를 받아 발급하도록 수정했습니다.

개인정보 문의도 일괄 거절로 끝낼 수 없었습니다. 타인의 주문이나 비공개 연락처는 보호하면서, 공시된 판매자 정보는 안내해야 했습니다. 요청한 정보의 성격과 조회 권한을 나누어 판단하는 것이 중요했습니다.

6. 검증: 근거 확보와 실제 동작을 나눠 확인하기

검증은 두 축으로 진행했습니다.

하나는 TC마다 필요한 지식의 근거가 있는지 확인하는 것이었습니다. 15개 TC의 기대 대응에 필요한 문서와 조항을 대조하고, 비어 있는 부분은 다시 인터뷰 질문으로 만들었습니다. 마지막까지 남았던 기상 결항 지연 시나리오도 운영 기준에서 근거를 찾아 채웠습니다.

다른 하나는 실제 상담과 API 호출의 동작을 확인하는 것이었습니다. 액션 데이터를 초기화한 뒤 테스트하고, 근거 없는 단정이나 도구를 호출하지 않는 문제를 수정했습니다. 마스킹된 전화번호의 별표가 사라지는 오류처럼 정책 판단 외의 문제도 발견됐습니다.

이 둘은 구분해서 봐야 했습니다. 15개 TC 모두에 근거 문서가 있다는 것이 15개 모두 안정적으로 통과했다는 뜻은 아닙니다. 작업 이력에는 일부 시나리오의 통과 기록이 있지만, 할인 중복과 하자 대응은 불안정한 항목으로 남아 있습니다. 할인 중복 사례는 세 번 중 두 번 통과한 기록도 있습니다.

전체 TC를 자동으로 반복 실행하고 채점하는 체계까지는 만들지 못했습니다. 대표 시나리오를 직접 넣어 보며 고쳤기 때문에, 숨은 시나리오나 다양한 표현에서도 같은 품질을 유지하는지는 충분히 확인하지 못했습니다.

문서 간 교차 검증도 필요했습니다. 같은 내용을 여러 사람과 문서에서 다르게 설명하는 경우가 있어, 충돌을 기록하고 확인 질문을 만들었습니다. 끝내 확인되지 않은 지식은 미확인 상태로 두고, 확답 대신 추가 확인이나 이관으로 처리하도록 했습니다.

7. 아쉬웠던 점과 다음에 바꾸고 싶은 것

모델 접근 제약으로 gpt-4o-mini를 유지한 상황에서, 주제별 문맥 선택과 코드의 제한으로 보완한 부분이 많았습니다. 여러 규정이 동시에 얽힌 문의나 표현이 달라진 문의는 여전히 취약할 수 있습니다.

다시 진행한다면 먼저 반복 검증 체계를 만들고 싶습니다. 같은 시나리오를 여러 번 실행하면서 답변뿐 아니라 조회 대상, 접수 여부, 고객 동의 시점까지 확인하고 싶습니다. 한 번의 성공보다 같은 조건에서 반복해서 올바르게 동작하는지가 더 중요하기 때문입니다.

지식 관리도 보완할 부분입니다. 출처와 충돌 표시는 남겼지만, 문서의 시행일과 적용 조건을 더 구조화하면 구판·개정판이 섞인 상황에서 판단 근거를 명확히 전달할 수 있을 것 같습니다. 키워드 기반 주제 선택 역시 필요한 근거를 놓치는 사례부터 모아 개선하고 싶습니다.

이번 과제에서는 인터뷰 질문을 만들고, 문서를 정리하고, 빠진 근거를 찾아 다시 묻는 과정이 구현만큼 큰 비중을 차지했습니다. Claude는 서버와 도구를 만드는 과정뿐 아니라 이 자료를 정리하고 점검하는 과정에서도 활용됐습니다.

고객의 요구를 이해한 뒤 무엇을 조회하고, 언제 동의를 받고, 어느 범위까지 처리할지 구체화하는 과정이었습니다. 다음에는 그 판단과 행동을 반복해서 검증할 수 있는 구조부터 더 일찍 준비해 보고 싶습니다.