E2E Test And Log Analysis Runbook
이 문서는 LLM 운영 담당자가 실제 기기에서 발화 테스트를 수행하고, 로그 기반으로 원인을 분리하는 절차입니다. 목표는 “증상 보고”가 아니라 “원인 후보와 근거를 포함한 개선 요청”을 만드는 것입니다.
1. 테스트 전 준비
1. 앱 버전 확인
2. DB 버전 확인
3. 브랜치/커밋 확인
4. 언어 설정 확인
5. Wi-Fi 연결 상태 확인
6. 맵 파일 존재 여부 확인
7. 청정 가능 공간 존재 여부 확인
8. 기기 에러 코드 확인
9. 현재 기기 상태 확인
10. Cloud LLM 서버/프롬프트 버전 확인
2. 권장 logcat 필터
현재 소스 기준으로 STT raw, STT processed라는 문자열이 항상 직접 출력되는 것은 아닙니다. 운영 문서에서 말하는 raw/processed는 분석 관점입니다.
| 분석 항목 | 현재 확인 근거 |
|---|---|
| STT raw 관점 | 테스트 발화 원문, originalSttResult, setAILogData의 STT 로그, Cloud request의 user content |
| STT processed 관점 | processLLAMA() 입력 흐름, 구두점 제거, contains.json 치환, [DICTIONARY_MATCH] 로그 |
| token 관점 | parsedLlamaResponse, Cutted parsedLlamaResponse, HI_NAMUH_LLMResponseParser |
| Cloud 관점 | send json, API Response, case, rewrite_query, 로컬 재진입 로그 |
| 실행 관점 | ApiCallValidator, FunctionCallHandler, DeviceCommunicator input/output |
adb logcat | grep -E "setAILogData|DICTIONARY_MATCH|parsedLlamaResponse|Cutted parsedLlamaResponse|LLMResponseParser|ApiCallValidator|FunctionCallHandler|DeviceCommunicator|REQ size|send json|API Response|rewrite_query|rewriteQuery|ttsText|resetState|determineMultiTurn|skipResume"
PowerShell:
adb logcat | Select-String "setAILogData|DICTIONARY_MATCH|parsedLlamaResponse|Cutted parsedLlamaResponse|LLMResponseParser|ApiCallValidator|FunctionCallHandler|DeviceCommunicator|REQ size|send json|API Response|rewrite_query|rewriteQuery|ttsText|resetState|determineMultiTurn|skipResume"
3. 1차 판정 순서
아래 순서대로만 판단합니다. 순서를 건너뛰면 잘못된 담당 부서로 이슈가 넘어갈 가능성이 높습니다.
1. 발화 원문과 STT raw 관점 근거 비교
2. STT raw 관점과 processed 관점 근거 비교
3. `[DICTIONARY_MATCH]` 확인
4. `parsedLlamaResponse` 확인
5. `<sk_xx>`와 parameter 확인
6. Cloud fallback 여부 확인
7. Cloud response JSON 확인
8. ApiCallValidator 결과 확인
9. FunctionCallHandler 분기 확인
10. Device API input/output 확인
11. TTS/화면/상태 결과 확인
12. 원인 분류
4. 원인 분류표
| 증상 | 근거 로그 | 1차 원인 |
|---|---|---|
| 사용자가 말한 단어가 raw 관점 근거에 없음 | original STT/AI Log/Cloud user content | STT/전처리 |
| raw 관점은 맞고 processed 관점이 틀림 | raw/processed 관점 비교 | substitution/후처리 |
| processed는 맞고 토큰이 틀림 | [DICTIONARY_MATCH], parsedLlamaResponse |
딕셔너리/로컬 LLM |
| 토큰은 맞고 에러 TTS | ApiCallValidator, errorcode |
기기 상태/에러 핸들러 |
| Device API 호출이 없음 | FunctionCallHandler 분기 없음 |
기능 구현 누락 |
| Device API 호출은 있음, 동작 없음 | API input/output | SoC/API |
| Cloud Case 오분류 | API Response |
Cloud prompt/router |
| Cloud Case 2 후 로컬 실패 | rewrite_query 후 processLLAMA 결과 |
Cloud rewrite 또는 온디바이스 dictionary |
| TTS 문구만 다름 | ttsText, string resource |
리소스/문구 |
| 화면만 안 뜸 | setLauncherScreen 호출 여부 |
화면 API/분기 |
5. 리포트 양식
제목:
테스트 날짜:
앱 버전:
DB 버전:
기기 시리얼:
언어:
네트워크:
맵/공간 상태:
기기 errorcode:
발화 원문:
STT raw:
STT processed:
기대 토큰:
실제 토큰:
딕셔너리 매칭 로그:
Cloud 호출 여부:
Cloud response:
ApiCallValidator 결과:
Device API input:
Device API output:
기대 TTS:
실제 TTS:
화면 전환:
재현 횟수:
원인 분류:
개선 요청:
첨부 로그:
6. 회귀 테스트 최소 세트
1. 오늘 날씨 알려줘
2. 등록된 스케줄 보여줘
3. 청정 스케줄 등록해줘
4. 전체 청정 스케줄 등록해줘
5. 공기질 맵 히스토리 보여줘
6. Please show me the air quality map history
7. 공간이 몇 개 있어?
8. How many spaces are set?
9. 보안모드 켜줘
10. 홈 잠금 상태 알려줘
11. Tell me about the all time mode
12. What time is it?
7. 실습 절차
1. 같은 발화를 3회 반복 테스트
2. 로그에서 STT/토큰/TTS를 찾음
3. 원인 분류를 비교
4. 관련 소스 파일 위치를 확인
5. 개선 요청서 초안 작성
6. 누락 필드와 잘못된 원인 분류를 보정