팀장님이 QA 100번 시키길래 만들었습니다.

커머스 플랫폼에 연동해 쓰는 앱 태스크를 주에 3개씩 만들어야 하는 FDE가, 매번 주문 있는 사용자와 없는 사용자, 환불 조건이 안 맞는 사용자, 중간에 딴소리하는 사용자까지 손으로 타이핑해 검증하던 일을 자동화한 기록이다. 비결정적 LLM 노드가 끼어 있는 워크플로우를 어떻게 자동 검증하느냐가 문제였고, 답은 태스크를 그래프로 보고 DFS로 경로를 뽑은 뒤 사용자 역할을 LLM에 맡겨 봇끼리 대화시키는 것이었다.

핵심 포인트

태스크는 시작 발화로 출발해 여러 노드가 순서대로 이어지는 흐름이라, 텍스트와 아이콘을 걷어내면 그래프다. 모든 경로를 빠짐없이 방문하면 되는 문제로 바뀐다.
대본을 미리 짜두는 방식은 실패했다. 봇이 예상 못 한 되물음을 하는 순간 대본이 어긋나기 때문이다.
대신 LLM에게 목표만 주고 사용자 역할을 맡겨, 딴소리하는 사용자까지 AI가 연기하게 했다.
시나리오를 돌리려면 그에 맞는 주문이 실제로 존재해야 하는데 시나리오마다 필요한 상태가 달라 비현실적이었다.
폴링은 대화 하나면 괜찮지만 경로 수십 개를 병렬로 돌리면 시나리오당 수백 개의 호출이 쌓인다.

상세 정리

대상: 주문 조회나 반품 접수처럼 고객사가 앱을 설치만 하면 작동하는 시나리오이며, 대표 예시인 만큼 한 번 잘 도는 것으로는 부족하다.
자동화 이전의 부담: 여러 사용자 유형을 일일이 타이핑해 검증하는 일이 주 3개씩 반복됐다.
태스크와 일반 봇의 차이: 고객이 주문 상태를 물으면 일반 봇은 마이페이지에서 확인하라고 안내만 하지만 태스크는 실제로 처리한다.
자동 검증이 막막했던 이유: 사람마다 발화가 다르고 들고 오는 데이터도 제각각인데 그 흐름에 매번 다르게 반응하는 비결정적 노드까지 끼어 있다.
관점 전환: 태스크를 그래프로 보면 모든 경로를 방문하는 그래프 순회 문제가 된다.
대본 방식의 실패 지점: 전화번호를 주면 이 번호가 맞는지 되묻고 확실한 입력값을 받으려 다시 요청하는 식으로 멀티턴이 몇 차례씩 오가는데, 예상 못 한 되물음 하나에 대본이 무너진다.
채택한 방식: 사용자를 흉내 내는 AI가 봇의 답을 읽고 다음 발화를 스스로 만들어, 결국 봇끼리 대화시키는 구조가 됐다.
데이터 문제: 주문 목록이 있는 사용자 시나리오를 돌리려면 그런 주문이 실제로 존재해야 한다는 전제를 보장하기 어려웠다.
해법: DFS가 뽑아낸 경로를 보고 시나리오 생성 단계에서 "이 경로를 가려면 주문 목록에 이런 게 있어야 한다"는 기대값을 미리 만들어 둔다.
응답 수신 문제: 사용자를 흉내 내는 AI가 다음 말을 하려면 봇이 뭐라고 답했는지 받아와야 하는데, 가장 단순한 폴링은 병렬 실행에서 호출량이 폭증한다.