LLM 정량평가하기(2) - 시나리오 기반의 AI 챗봇 테스트 자동화

1. 배경 및 문제

1-1. 항아리 게임

삐끗하면 추락한다…

1. A 프롬프트 - good. 여기에 ‘ 기능만 추가하면 될 듯?
2. A’ 프롬프트로 살짝 바꾸어 넣음
3. 이상한 응답을 내뱉기 시작 or 더 nice한 B’가 됨

 

1-2. 문제점

1. 주관적인 기준: 너 뭔가 달라진 느낌이다? ‘느낌’이 뭔데 그게 왜 그런 ‘느낌’이 나는 건데~ 뭘 한 건데~
2. 비효율성: 챗봇에 시나리오 검증을 해야 하는데, 하나하나 입력하자니 넘 오래 걸림
3. 재현성 부족: 분명 같은 버전인데 어제는 됐는데 오늘은 또 안됨 왜 이럴까…

한 줄 요약: 왜 되는지도 모르겠고 왜 안 되는 지도 모르겠음. 근데 드럽게 오래 걸림

 

1-3. 그나마 다행인 점

1. 로그를 전부 수집하고 있다. 구구절절 긴 raw data 그대로… 말 그대로 ‘전부’
2. 어쨌든 결과는 나온다. output을 모아서 문제를 분류하고 추정해 볼 수 있다.

 

2. 시나리오 설계하기

일단 실험실을 통제해야 한다.
결과 검증의 기준이 필요함 + 챗봇 테스트의 일관성을 위해 제대로 된 대본을 먼저 만들고자 했다.
 

 
사용자 A, B와 챗봇이 포함된 중재 시나리오가 필요했다. 단순히 대화가 이어지는 것에 그치면 안 되고, AI 챗봇(이하 도큐)이 갈등을 해결하고 합의를 이끌어내는지에 대한 검증이 이루어질 수 있도록 시나리오를 설계했다.
 

2-1. 갈등 해결 로직 (Conflict Resolution) 검증

• 단순히 사용자의 말을 받아적는 것이 아니라, 양측 조건이 충돌할 때 중재자로 끼어드는지 확인
• 가격(SCENARIO 1), 일정(SCENARIO 2), 업무 범위(SCENARIO 3) 등 다양한 갈등 유형별 대응 확보
• 예시) 예산 100만 원(Client) vs 150만 원(Provider) 충돌 시 → AI가 제3의 대안(130만 원)을 제시하거나 합의를 유도하는가?

 

2-2. 데이터 정합성 (Data Integrity) 검증

• 자연어 대화 속에 섞여 있는 핵심 계약 정보(금액, 기간, 수정 횟수, 권리 관계)를 정확히 추출하여 JSON 및 Contract Schema에 매핑할 수 있는지 검증.
• 예시) "수정 무제한"을 요구했으나 "3회"로 합의된 경우, 최종 계약서에 합의된 값(3회)이 정확히 기재되었는가?

 

2-3. 도메인 확장성 (Domain Scalability) 검증

아래 3가지 시나리오를 통해 DoQ 시스템이 범용적인 계약 구조를 가졌음을 검증

• SCENARIO 1: 단건 용역(로고) / 결과물 중심, 저작권 양도 이슈.
• SCENARIO 2: 프로젝트성 용역(웹사이트) / 기간 중심, 유지보수 조항 필수.
• SCENARIO 3: 정기 용역(포스터) / 구독형 계약, 월 단위 정산 로직.

 

2-4. 전시 체험용 롤플레잉 시나리오로 활용

과제전 부스 전시를 목표로 하고 있기 때문에, 테스트 시나리오를 롤플레잉 가이드로도 활용할 수 있도록 했다.

1. 체험 가이드 제공: 부스 방문객에게 막연히 자유롭게 대화하라고 요청하면 단답식으로 대충 입력하는 것에서 그침, 이때 롤카드를 현장에 비치하여 방문객들이 보다 몰입감 있게 서비스를 체험할 수 있도록 유도했다.
2. 리스크 최소화: 전시 현장은 변수가 많으므로, 모든 경우에 대해 시나리오를 open 해두는 것보다, 검증된 시나리오를 제공하여 시연 도중 예기치 않은 상황이 일어나는 것을 방지한다.

→ 테스트에 활용되는 시나리오는 무.조.건 돌아가도록 해서 관람객이 검증된 시나리오를 따라 도큐의 “계약서 작성 중재 및 자동 생성” 서비스를 확실하게 경험할 수 있도록 했다.
 

3. 테스트 자동화 아키텍처 설계

test/
├── test_full_scenario.py    # 전체 시나리오 통합 테스트
├── test_websocket_chat.py   # WebSocket 연결 테스트
└── test_rag.py              # RAG 검색 기능 테스트

• 테스트 방식: Stub 기반 시뮬레이션 테스트
• 실행 환경: WebSocket 클라이언트로 실제 서버와 통신
• 검증 항목: 단계 전환, 데이터 수집, 응답 적절성

 

3-1. 동작 원리

1. 시나리오 정의: 기획한 시나리오를 바탕으로 사용자(Client/Provider)의 발화(Input)와 기대 반응(Expected)을 JSON 형태로 사전 정의함.
2. Stub 실행: 실제 사용자처럼 1~2초 간격으로 서버에 메시지 전송
3. 상태 전이 검증: AI가 Introduction → Work Scope → Budget 등 단계를 올바르게 넘기는지 체크

 
시나리오 테스트 예시 (접기)

[DoQ]:

안녕하세요, 용역 계약서 작성을 도와드릴 DoQ입니다.

양측 조건을 바탕으로 공정하고 명확한 계약서를 함께 만들어가겠습니다.

현재 이해한 내용은 다음과 같습니다

- 의뢰인: 고예경
- 용역자: 김영지

작업 범위, 기간, 대금 등을 순차적으로 확인하겠습니다.

먼저 질문드릴게요:
고예경님, 어떤 용역을 의뢰하실 계획인가요?

예: "브랜딩 로고 디자인", "웹 UI 디자인", "영상 편집 2건" 등

=== Step 1: Work Scope ===

[client]: 로고 디자인을 의뢰하고 싶습니다.

(System): Triggering DoQ (LLM)...
(System): Waiting for DoQ...

[DoQ]:
소개 내용이 잘 정리되었습니다. 이제 다음으로 작업 범위 확인 단계에 대해 이야기해 볼까요?

[provider]: 네, 가능합니다. 로고 스타일이나 레퍼런스가 있으신가요?

(System): Triggering DoQ (LLM)...
(System): Waiting for DoQ...

[DoQ]:
로고 디자인 작업에 대한 구체적인 내용을 확인하는 단계입니다. 고예경님, 혹시 원하시는 로고 스타일이나 참고하신 디자인이 있으신가요? 김영지님께서는 로고 디자인 작업 시 필요한 추가 정보가 있으실까요?

=== Step 2: Work Period ===

[client]: 작업 기간은 2주 정도로 생각하고 있습니다.

(System): Triggering DoQ (LLM)...
(System): Waiting for DoQ...

[DoQ]:
김영지님께서 로고 스타일이나 레퍼런스를 문의하셨는데요, 고예경님, 혹시 생각하신 스타일이 있으신가요? 아니면 참고할 만한 이미지나 웹사이트가 있다면 알려주세요.

[provider]: 2주면 충분합니다. 시작일은 계약 체결 직후로 할까요?

(System): Triggering DoQ (LLM)...
(System): Waiting for DoQ...

[DoQ]:
2주라는 기간을 말씀해주셨네요. 김영지님, 로고 디자인 작업에 2주 정도면 충분할까요? 혹시 추가적으로 필요한 기간이 있으시다면 말씀해주세요.

=== Step 3: Budget (Conflict) ===

[client]: 예산은 100만원입니다.

(System): Triggering DoQ (LLM)...
(System): Waiting for DoQ...

[DoQ]:
김영지님께서 계약 체결 직후를 작업 시작일로 제안하셨습니다. 고예경님, 괜찮으신가요? 아니면 원하시는 다른 시작일이 있으신가요?

[provider]: 보통 이 정도 작업이면 150만원은 받아야 합니다.

(System): Triggering DoQ (LLM)...
(System): Waiting for DoQ...

[DoQ]:
고예경님, 예산 100만 원을 말씀해주셨네요. 김영지님, 로고 디자인 작업에 100만 원으로 진행하는 것이 괜찮으신가요? 혹시 추가적으로 필요한 부분이 있다면 말씀해주세요.

[client]: 그럼 130만원으로 하시죠.

[provider]: 알겠습니다. 130만원에 진행하겠습니다.

(System): Triggering DoQ (LLM)...
(System): Waiting for DoQ...

[DoQ]:
김영지님은 150만 원을 희망하시는데요, 고예경님, 150만 원으로 조정하는 건 어떠신가요?

=== Step 4: Revisions ===

[client]: 수정은 무제한으로 해주세요.

(System): Triggering DoQ (LLM)...
(System): Waiting for DoQ...

[DoQ]:
고예경님께서 130만 원으로 조정하는 것을 제안하셨습니다. 김영지님, 130만 원으로 로고 디자인 작업을 진행하는 것으로 괜찮으신가요?

[provider]: 무제한은 어렵고, 3회까지 무료로 해드리겠습니다.

(System): Triggering DoQ (LLM)...
(System): Waiting for DoQ...

[DoQ]:
작업 범위 확인 내용이 잘 정리되었습니다. 이제 다음으로 작업 기간 설정 단계에 대해 이야기해 볼까요?

[client]: 네 알겠습니다. 3회로 하죠.

(System): Triggering DoQ (LLM)...
(System): Waiting for DoQ...

[DoQ]:
네, 김영지님. 이제 작업 일정 및 기한을 확정하는 단계입니다. 완료/납품 예정일(검수 요청일)은 언제로 하는 것이 좋을까요? 고예경님과 협의해서 정해주세요.

=== Step 5: Copyright ===

[client]: 저작권은 제가 가집니다.

(System): Triggering DoQ (LLM)...
(System): Waiting for DoQ...

[DoQ]:
고예경님, 수정 횟수를 무제한으로 요청하셨네요. 김영지님, 수정 횟수를 무제한으로 제공해주시는 것이 가능할까요?

[provider]: 네 동의합니다. 포트폴리오 사용은 가능하게 해주세요.

(System): Triggering DoQ (LLM)...
(System): Waiting for DoQ...

[DoQ]:
김영지님, 수정 횟수는 3회까지 무료로 제공해주신다고 말씀해주셨습니다. 고예경님, 이 조건으로 진행하는 것에 동의하시나요?

=== Step 6: Confidentiality ===

[client]: 비밀 유지 서약도 필요합니다.

(System): Triggering DoQ (LLM)...
(System): Waiting for DoQ...

[DoQ]:
고예경님, 수정 횟수는 3회로 합의되었습니다. 김영지님, 3회 수정으로 진행하는 것으로 괜찮으신가요?

[provider]: 네 알겠습니다.

(System): Triggering DoQ (LLM)...
(System): Waiting for DoQ...

[DoQ]:
고예경님, 저작권은 갑(고예경님)에게 귀속되는 것으로 말씀해주셨습니다. 김영지님, 이 부분에 대해서도 동의하시나요?

=== Step 7: Finalization ===

[client]: 이제 계약서 작성해주세요.

(System): Triggering DoQ (LLM)...
(System): Waiting for DoQ...

[DoQ]:
김영지님, 포트폴리오 사용에 대한 동의 감사합니다. 고예경님, 김영지님이 작업 결과물을 포트폴리오에 사용하는 것에 동의하시나요?

[client]: 특별한 내용은 없습니다. 표준 조항으로 해주세요.

(System): Triggering DoQ (LLM)...
(System): Waiting for DoQ...

[DoQ]:
고예경님, 김영지님께서 포트폴리오 사용을 허락해주시면 좋겠다고 하시네요. 이 부분은 어떻게 생각하시나요? 그리고 비밀유지 서약에 대한 내용도 계약서에 추가해야 할 것 같습니다.

 

 

4. 구현 상세

4-1. 시나리오 정의

단순 대화 나열이 아닌 '갈등(Conflict) → 협상(Negotiation) → 합의(Agreement)'의 논리적 흐름을 데이터 구조로 강제했다.

# 시나리오 정의 예시 (test_full_scenario.py)
SCENARIO_1 = {
    "name": "로고 디자인 계약",
    "steps": [
        ("client", "로고 디자인을 의뢰하고 싶습니다."),
        ("provider", "네, 가능합니다. 레퍼런스가 있으신가요?"),
        # ... (중략) ... 19단계 계속
    ]
}

 

4-2. 리얼 페르소나 매핑

테스트 데이터의 품질을 높이기 위해 무작위 문자열(asdf, test1) 대신 client_name="고예경", provider_name="김영지" 등 실제 팀원 및 구체적 실명을 동적으로 매핑했다.

1. 로그 가독성 확보: User_A, User_B 같은 식별자 대신 실명을 사용하여, 로그 분석 시 발화 주체와 맥락을 직관적으로 파악할 수 있도록 했다.
2. 아카이브 퀄리티 유지:
   - 테스트 수행 결과는 Redis에 저장되어 프론트엔드 '지난 계약 아카이브' 페이지에 게시되어 UI 테스트에도 활용할 수 있도록 했다.
   - 'ㅁㄴㅇㄹ', 'test1' 같은 무의미한 더미 데이터 적재를 방지하고, 실제 사용 사례 같은 고품질의 계약 스토리를 DB에 채워 완성도를 확보하려 했다.

 

4-3. 안정성 및 로그 시스템 이원화

테스트 결과의 신뢰성을 높이기 위해 로그를 두 곳으로 분리하여 저장했다.

• 서버 로그 (logs/doq_be.log): LLM 프롬프트 내용, 토큰 사용량, Redis 저장 상태 등 백엔드 내부 로직 기록
• 테스트 로그 (logs/doq_test.log): 시나리오 진행 단계, 클라이언트가 전송한 메시지, 응답 시간(RTT) 등 클라이언트 관점의 테스트 결과 기록

→ 두 로그를 교차 검증하여 이슈 발생 지점을 구체적으로 파악할 수 있도록 했다. 또한, 테스트 로그는 대본과 같이 기록, 가독성을 확보하여 시나리오를 평가하는데 우선적으로 활용할 수 있었다.