금융 콜봇·챗봇을 구축할 때는 시나리오 흐름도를 바탕으로 고객의 요청과 업무 처리 순서를 구현하게 됩니다. 하지만 흐름도에 필요한 단계와 분기가 잘 정리되어 있어도, 실제 솔루션에 적용하는 과정에서 예상하지 못한 문제들이 발생하곤 합니다.
예를 들어, API에서 반환된 데이터만으로 필요한 내역이 무엇인지 구분하기 어렵거나, LLM이 고객의 발화를 정확히 이해했는데도 해당 값이 업무 처리에 반영되지 않는 경우 등 입니다. 또한, 정상적인 요청에서는 문제가 없었지만, 예상하지 못한 발화가 입력되자 응답이 중단될 수도 있습니다.
TEXTNET은 최근 국내 금융사의 콜봇·챗봇 구축 프로젝트에서 기획된 흐름도를 분석하고, 실제 솔루션에서 동작하는 시나리오로 구현하고 검증하는 업무를 담당했습니다. 해당 서비스는 LLM을 활용해 고객 발화의 의도와 필요한 정보를 파악하고, 그 결과를 정해진 업무 시나리오에 연결하는 구조였습니다.
이번 글에서는 프로젝트를 진행하며 실제로 발견한 문제와 이를 해결하거나 개선 방향을 도출한 과정을 소개합니다.
API 응답값만으로는 필요한 데이터를 구분하기 어려웠습니다
콜봇·챗봇 시나리오를 구현하다 보면 데이터를 조회하는 것보다 조회한 데이터 중 어떤 정보를 고객에게 보여줘야 하는지 판단하는 과정이 더 까다로울 때가 있습니다. 특히 API 호출 횟수를 줄이기 위해 여러 유형의 데이터를 한 번에 조회한다면, 응답값만으로 필요한 항목을 정확히 구분할 수 있는지 확인해야 합니다.
이번 금융 거래 취소 시나리오에서는 미체결 내역이 있으면 해당 목록을 먼저 안내하고, 없으면 당일 체결 내역을 보여주어야 했습니다. 저희는 먼저 API 호출 횟수를 줄이기 위해 전체 거래내역을 한 번에 조회하고, '미체결 수량'을 기준으로 목록을 구분하는 방법을 활용했습니다.
하지만 실제 응답을 확인해 보니 정정·취소 이력이 있는 원주문에서는 미체결 수량이 0으로 표시되는 경우가 있었습니다. 이 값만으로 분류하면 일부 주문을 잘못 구분할 가능성이 있었습니다.
이에 전체 거래내역을 조회해 분류하는 대신, API 호출 시점에 조회 대상을 지정하는 방식으로 변경했습니다. 미체결 내역을 먼저 조회하고, 해당 내역이 없을 때만 체결 내역을 추가 조회하도록 구현했습니다.
이 과정에서는 API 호출 횟수를 줄이는 것보다, 실제 업무 조건에 맞는 데이터를 정확하게 조회하는 것이 중요했습니다. 따라서, 응답값만으로 거래 상태를 구분하기 어려운 상황에서 조회 방식을 변경함으로써, 정정·취소 이력에 따른 오분류 가능성을 줄이고 필요한 거래내역을 안내할 수 있도록 했습니다.
LLM이 추출한 정보가 시나리오에 반영되지 않았습니다
LLM 기반 콜봇·챗봇에서는 고객의 발화에서 필요한 정보를 추출하고, 이를 시나리오의 변수나 처리 조건에 연결합니다. 하지만 LLM이 정보를 정확하게 추출하더라도 응답값을 잘못 연결하면 실제 업무 처리에 반영되지 않을 수 있습니다.
이번 프로젝트에서는 고객이 “십주”, “이주”라고 이야기했을 때 수량이 정상적으로 반영되지 않는 문제가 발생했습니다. 처음에는 LLM의 숫자 인식 문제를 의심했지만, 응답 데이터를 확인해 보니 LLM은 각각 10과 2를 정상적으로 추출하고 있었습니다.
원인은 LLM 응답 항목의 역할을 잘못 이해한 데 있었습니다. 개발 과정에서 참조한 num_type 항목은 구체적인 수량이 아니라 '전체·절반·수량 없음'을 구분하는 값이었습니다. 반면 고객이 말한 숫자는 별도의 num_count 항목에 반환되고 있었지만, 시나리오에는 해당 값이 연결되지 않았습니다.
이에 수량 유형과 구체적인 숫자를 각각 올바른 응답 항목에서 가져오도록 처리 로직을 수정했습니다. 이후 “십주”, “이주”와 같은 숫자 발화뿐 아니라 기존의 전체·절반·수량 없음 경로도 정상적으로 동작하는지 확인했습니다.
이처럼 LLM의 정보 추출 결과와 시나리오의 처리 결과를 구분해 검증해야 업무 처리 과정에서 오류를 줄일 수 있습니다. 또한, 특히 LLM 응답에 여러 항목이 있다면 각 항목의 의미와 값이 반환되는 조건까지 확인하는 것이 중요합니다.
예상하지 못한 고객 발화에 대화가 중단됐습니다
콜봇·챗봇 시나리오를 테스트할 때는 정상적인 요청뿐 아니라 업무와 관련 없는 발화가 입력됐을 때도 대화가 이어지는지 확인해야 합니다. 고객은 설계된 흐름대로만 질문하지 않기 때문에, 예상하지 못한 입력을 처리하는 예외 분기가 필요합니다.
이번 프로젝트에서는 시나리오를 직접 실행하며 “자장면”, “배고파”, “대한민국”처럼 업무와 무관한 문장을 입력해 보았습니다. 그 결과 일부 발화에서 다음 응답으로 연결되지 않고 ‘응답 미출력’ 오류가 발생하는 것을 확인했습니다.
원인을 살펴보니 고객 발화를 분류하는 조건문에 어느 조건에도 해당하지 않을 때 실행되는 기본 분기(else)가 누락되어 있었습니다. 정상적인 요청은 처리할 수 있었지만, 분류되지 않은 발화가 들어오면 다음 안내로 연결할 경로가 없었던 것입니다.
저희는 해당 오류를 개발 담당자에게 공유하고, 분류되지 않은 발화가 입력되면 고객에게 다시 질문하거나 이전 단계로 돌아가도록 예외 경로를 추가하는 방안을 제안했습니다.
이처럼 정상적인 대화 흐름이 동작하는 것만으로 시나리오 구현이 완료됐다고 판단하기 어렵다는 점을 보여줍니다. 특히 발화 분류 단계에서는 어떤 조건에도 해당하지 않는 입력이 들어왔을 때의 처리 경로까지 확인해야 합니다.
정상적인 숫자 입력이 다른 데이터 유형으로 잘못 인식됐습니다
금융 콜봇·챗봇에서는 고객이 입력한 숫자가 수량, 금액, 계좌번호 등 어떤 정보에 해당하는지 정확하게 구분해야 합니다. 특히 자릿수가 긴 숫자는 입력 형식이 비슷해, 업무 맥락과 다르게 인식되면 의도하지 않은 응답으로 이어질 수 있습니다.
이번 프로젝트에서는 주식 주문·취소 시나리오를 테스트하며 수량이나 가격에 큰 숫자를 입력했습니다. 그 결과 일부 숫자가 주문 수량이나 금액이 아닌 전화번호 등 다른 데이터 유형으로 잘못 인식되는 문제가 발생했습니다.
이 과정에서 잘못 인식된 값이 정상적으로 처리되지 않고, 전화번호를 나타내는 솔루션 내부 코드가 고객 응답에 그대로 노출되는 오류도 확인했습니다. 저희는 해당 오류가 발생한 입력값과 응답 결과를 정리해 솔루션 개발 담당자에게 전달하고 개선을 요청했습니다.
이와 같이 시나리오 테스트에서는 고객 발화의 인식 결과뿐 아니라 최종 응답 화면까지 확인해야 합니다. 특히 숫자·전화번호·계좌번호처럼 정해진 형식의 입력값은 실제 고객 정보 대신 테스트용 데이터를 활용해 출력 결과를 점검하면 예상하지 못한 오류를 발견하고 개선할 수 있습니다.
오류 수정 후에도 전체 시나리오를 다시 검증해야 합니다
콜봇·챗봇 시나리오에서는 하나의 조건이나 변수를 수정하더라도 연결된 다른 대화 흐름에 영향을 줄 수 있습니다. 따라서 발견한 오류가 해결됐는지 확인하는 것뿐 아니라, 기존에 정상적으로 동작하던 경로에도 문제가 없는지 검증해야 합니다.
이번 프로젝트에서도 API 조회 조건과 LLM 응답값 연결 방식을 수정한 뒤, 해당 기능만 확인하지 않고 거래 취소 시나리오의 전체 흐름을 다시 테스트했습니다.
실제 솔루션에서 시나리오를 직접 실행하며 정상적인 거래 요청과 수량 입력은 물론, 업무와 무관한 발화나 임의의 숫자를 입력하는 경우까지 확인했습니다. 특히 수정한 조건이 다른 분기에 영향을 주지 않는지, 고객의 입력에 따라 다음 안내가 정상적으로 이어지는지를 중점적으로 점검했습니다.
이 과정에서 발견한 응답 중단이나 내부 표기 노출 등의 오류는 발생 조건과 결과를 정리해 개발 담당자에게 전달하여 개선했습니다.
이번 사례를 통해 시나리오 검증은 개별 기능의 정상 동작을 확인하는 데서 끝나지 않고, 고객이 실제로 경험하는 전체 대화 흐름을 기준으로 진행해야 한다는 점을 확인했습니다.
마무리하며
콜봇·챗봇 시나리오는 흐름도에 따라 구현하지만, 실제로 동작시키는 과정에서는 예상하지 못한 문제들이 발생할 수 있습니다. API 응답값이 업무 조건과 일치하지 않거나, LLM이 추출한 정보가 시나리오에 제대로 연결되지 않는 경우가 대표적입니다.
이번 프로젝트에선 거래내역 조회 방식과 수량 처리 로직을 수정하고, 다양한 발화를 직접 입력하며 예외 분기와 응답 출력 문제를 확인했습니다. 이 과정에서 저희가 집중한 것은 개별 기능의 정상 동작뿐 아니라 고객의 요청이 실제 업무 처리와 최종 안내까지 올바르게 이어지는지 검증하는 것이었습니다.
이러한 작업을 통해 기획된 업무 흐름을 실제 솔루션에서 구현하는 과정의 문제를 해결하고, 정상적인 입력뿐 아니라 예외 상황까지 검증할 수 있었습니다. 특히 수정한 기능뿐 아니라 연결된 대화 흐름을 함께 점검하며 시나리오의 완성도를 높일 수 있었습니다.
TEXTNET은 다양한 기업의 콜봇·챗봇 프로젝트에서 시나리오와 학습 데이터 구축, 구현 및 품질 검증 업무를 수행해 왔습니다. 콜봇·챗봇 시나리오 설계나 구현, 테스트 과정에서 어려움을 겪고 계신다면 TEXTNET에 문의해 주세요. 실제 운영 환경과 업무 요구사항에 맞는 구축·검증 방안을 함께 검토하겠습니다.