AI 에이전트 서비스를 오픈하기 전에는 사용자의 요청을 정확하게 이해하고, 기획된 기능을 정상적으로 수행하는지 검증해야 합니다. 하지만 실제 개발 현장에서는 테스트할 질문은 준비되어 있어도, 어떤 응답과 동작을 정상으로 판단해야 하는지 명확하지 않은 경우가 있습니다.
TEXTNET이 참여한 AI 에이전트 QA 프로젝트에서도 비슷한 상황이 있었습니다. 저희는 서비스의 1차·2차 오픈 준비 과정에서 AI 에이전트의 응답과 기능을 검증하는 QA 업무를 담당했습니다. 1차 오픈 당시에는 제공된 테스트 발화 중 과반수 이상에 기대답변이 정의되어 있지 않았고, 프로젝트 투입과 동시에 테스트를 시작해야 했습니다. 이후 2차 오픈에서는 신규·변경 기능에 대한 검증과 함께 기존 기능의 정상 동작 여부도 확인해야 했습니다.
이번 글에서는 이처럼 오픈 단계별로 달라지는 상황과 잦은 요구사항 변경에 대응하며, 테스트케이스 작성과 테스트 수행 방식을 유연하게 조정한 과정을 소개하겠습니다.
1차 오픈, 기대결과가 부족한 상황에서 검증 기준을 마련했습니다
AI 에이전트를 테스트하려면 단순히 발화를 입력하고 응답을 확인하는 것만으로는 부족합니다. 사용자의 요청을 어떤 의도로 인식해야 하는지, 어떤 정보를 안내하거나 기능을 실행해야 하는지 등 정상 동작을 판단할 수 있는 기준이 필요합니다. 하지만 이번 프로젝트에서는 테스트 발화별 기대답변이 충분히 정리되지 않은 상태에서 AI 에이전트의 기능과 응답을 검증해야 했습니다.
이에 저희는 기획서와 요구사항을 기반으로 기대 결과를 확인하고 구체화하며, 실제 AI 에이전트 테스트를 병행하는 방법으로 진행했습니다. 고객사가 제공한 발화를 검토하며 각 발화에 필요한 응답과 기능 동작을 확인하고, 기존 발화만으로 검증하기 어려운 조건은 테스트 발화를 보완하는 식이었습니다.
이 과정에서 확인한 검증 조건과 기대 결과는 테스트케이스(Test Case)로 정리했습니다. 기획서와 요구사항에서 확인한 기대 결과를 실제 테스트 결과와 비교해 정상 여부를 판단하고, 테스트 과정에서 새롭게 확인한 조건도 TC에 반영하며 검증 기준을 구체화했습니다.
실제 테스트에서는 다음 항목을 중점적으로 확인했습니다.
사용자의 요청에 적절히 답변하는지
사용자의 요청을 올바르게 인식하는지
필요한 정보를 안내하고 기획된 기능을 수행하는지
웹·앱 연계 기능이 잘 동작하는지
예상하지 못한 발화에 대응할 수 있는지
멀티턴 대화에서 이전 맥락을 유지하는지
이때 주의할 점은 AI 에이전트가 질문에 적절한 답변을 제공했다고 해서 반드시 정상적으로 동작한 것은 아니라는 점입니다. 응답 내용만 확인하면 실제로 수행해야 할 기능이 누락되거나, 특정 조건에서 잘못된 동작이 발생하는 문제를 놓칠 수 있습니다.
예를 들어 사용자가 "요금제 변경해 줘"라고 요청했다고 가정해 보겠습니다. AI 에이전트가 요금제 변경 방법을 안내했더라도, 기획상 가입 정보를 조회하거나 변경 화면으로 연결해야 한다면 정상적인 처리라고 보기 어렵습니다.
따라서 테스트케이스를 작성할 때는 기획서와 요구사항에 정의된 기능 및 처리 범위를 바탕으로 검증 항목과 기대 결과를 구체화해야 합니다. 이때 서비스 특성과 검증 범위에 따라 필요한 테스트 조건을 추가하여 검증의 정확성을 높일 수 있습니다.
📄
잦은 요구사항 변경에 대응하며 검증 기준을 관리했습니다
서비스 오픈을 준비하는 과정에서는 처음 기획했던 내용과 기능들이 달라지는 일이 발생하곤 합니다. 이때는 정리해 놓았던 테스트케이스도 함께 수정해야 합니다. 변경 사항에 따라 정상으로 판단해야 할 응답이나 기능 동작도 달라지기 때문입니다.
이번 프로젝트에서도 다음 세 가지 상황에 대응하며 검증 기준을 관리했습니다.
기획 및 요구사항 변경 : 기존에 정상으로 판단했던 응답도 변경된 요구사항에 따라 다시 검증해야 하는 경우
담당자 간 판단 차이 : 동일한 응답이나 기능 동작을 두고 정상 여부에 대한 해석이 달라지는 경우
테스트 환경 반영 시차 : 변경된 요구사항에 따른 개발 내용이 테스트 환경에 아직 반영되지 않아 기대 결과와 실제 동작이 일치하지 않는 경우
이러한 상황에서 중요한 것은 실제 응답이나 기능 동작이 기대 결과와 다르다고 해서 모두 기능 오류로 판단하지 않는 것입니다. 동일한 테스트 실패라도 원인에 따라 필요한 조치가 달라지기 때문입니다.
예를 들어 변경된 기획에 따라 AI 에이전트가 새로운 응답을 제공해야 하지만, 테스트 환경에서는 이전 응답이 출력되는 상황을 생각해 볼 수 있습니다. 변경 사항이 아직 배포되지 않았다면 기능 자체의 오류로 보기 어렵지만, 배포가 완료된 이후에도 이전 응답이 출력된다면 실제 구현에 문제가 있는지 확인해야 합니다.
이에 저희는 최신 요구사항과 테스트 환경의 반영 상태를 함께 확인해 불일치 원인을 파악했습니다. 특히 담당자마다 정상 동작에 대한 해석이 다른 경우에는 관련 담당자들과 적용할 기준을 확인하고, 개발자와는 실제 구현 내용과 배포 상태를 점검했습니다. 예상과 다른 동작이 발생했을 때는 재현 조건과 검증 결과를 공유해 원인을 확인하는 과정도 거쳤습니다.
확인된 원인에 따라 테스트케이스의 기대 결과를 수정하거나 불필요한 항목을 제외하고, 새롭게 검증해야 할 조건을 추가했습니다. 실제 결함으로 확인된 사항은 수정 여부를 추적하고 재검증하는 방식으로 관리했습니다.
또한 테스트 수행 결과는 일별 현황과 누적 검증 현황으로 구분해 관리했습니다. 당일 진행한 테스트뿐 아니라 이전 검증 결과와 추가 확인이 필요한 항목까지 함께 파악하기 위해서였습니다. 특히 요구사항 변경과 재검증이 반복되는 상황에서는 개별 테스트의 성공 여부만큼 현재 전체 검증이 어디까지 진행됐는지 확인하는 일도 중요했습니다.
이를 통해 기획이 계속 변경되는 상황에서도 테스트케이스를 최신 요구사항에 맞춰 관리하고, 확인된 근거를 바탕으로 실제 수정이 필요한 문제를 구분할 수 있었습니다.
1차와 2차 오픈에 따라 테스트케이스 작성 방식을 달리했습니다
1차 오픈에서는 테스트를 먼저 수행하고 그 결과를 바탕으로 테스트케이스를 작성했다면, 2차 오픈에서는 기획서와 요구사항을 바탕으로 테스트케이스를 미리 작성하고 이를 기준으로 검증을 진행했습니다.
새롭게 추가되거나 변경된 기능을 중심으로 기획서와 요구사항을 분석하고, 각 기능의 동작 조건과 기대결과를 테스트케이스에 반영했습니다. 이후 작성한 테스트케이스를 기준으로 AI 에이전트의 응답과 기능 동작이 요구사항에 부합하는지 확인했습니다.
새로운 기능뿐 아니라 기존 기능도 다시 확인해야 했습니다. 기능을 추가하거나 수정하는 과정에서 이전에 정상적으로 동작하던 부분에도 영향을 줄 수 있기 때문입니다. 이때 1차 오픈에서 작성한 테스트케이스를 활용해 회귀 테스트(Regression Test)를 수행하며 기존 기능의 정상 동작 여부를 점검했습니다.
이와 함께 테스트 수행 결과와 결함 이력을 지속적으로 관리하며, 검증 기준의 변경 사항과 테스트 결과를 추적할 수 있도록 했습니다.
이번 프로젝트에서 의미 있었던 점은 1차 오픈에서 작성한 테스트케이스를 2차 오픈의 회귀 테스트에 활용했다는 것입니다. 처음에는 개별 발화의 정상 여부를 판단하기 위해 작성했던 테스트케이스가 이후에는 기존 기능을 재검증하는 기준으로 쓰이게 됐습니다. 이를 통해 테스트 과정에서 정리한 검증 조건과 기대 결과가 일회성 산출물에 그치지 않고, 후속 오픈에서도 활용할 수 있는 QA 자산으로 이어졌습니다.
📄
마치며
이번 프로젝트는 오픈 단계별 상황과 검증 환경에 따라 테스트케이스 작성 및 테스트 수행 방식을 유연하게 조정하며, 검증 기준을 수립하고 체계화한 사례입니다.
AI 에이전트 QA에서 중요한 것은 단순히 응답이 정상적으로 출력되는지 확인하는 데 그치지 않습니다. 어떤 조건에서 어떤 응답과 기능 동작이 이루어져야 하는지 판단 기준을 명확히 하고, 기획이나 요구사항이 변경되더라도 이를 지속적으로 관리할 수 있어야 합니다.
이번 프로젝트에서도 이러한 과정을 통해 구축한 테스트케이스를 2차 오픈의 회귀 테스트에 활용할 수 있었습니다. 검증 기준을 명확하게 수립하는 것뿐 아니라, 이후에도 활용할 수 있도록 관리하는 일이 중요하다는 점을 확인한 경험이었습니다.
AI 에이전트의 검증 기준을 마련하거나 테스트를 준비하고 있다면, 이번 사례가 참고가 되기를 바랍니다. TEXTNET은 다양한 AI 서비스 구축·운영 프로젝트 경험을 바탕으로, 서비스 특성에 맞는 QA 업무를 지원하고 있습니다. 비슷한 고민을 하고 계시거나 QA 업무와 관련해 궁금한 점이 있다면 TEXTNET에 문의해 주세요.