# Lab 03 · 실행 결과 검증과 실패 고치기
- 관련 강의: [3단계 · 실행 결과 검증과 테스트](../../Lecture/67/03-STAGE3-VERIFY-AND-FIX.md)
- 소요 시간: 약 70분 (예제 1 10분 · 예제 2 20분 · 과제 40분)
- 준비: Lab 02의 `my-work/it-agent.json` (없으면 `cp reference/lab03-start.json my-work/it-agent.json` 후 push)
- 목표: 답을 사용자에게 보내기 **전에** 워크플로우가 스스로 확인하게 하고, **내가 쓴 테스트**로 숨은 실패를 찾아 고친다.
```mermaid
flowchart LR
E1["예제 1
테스트 결과 읽기"] --> E2["예제 2
검증 · 담당자 연결"] --> T["과제
어려운 테스트 쓰고
고치기"]
```
> 요청문과 테스트는 직접 씁니다. 막히면 `▶` 를 하나씩 펼쳐 보세요. 정답은 나오지 않습니다.
## 예제 1 · 테스트 결과 읽기 (10분)
검증을 넣기 **전에** 새 기대 결과로 돌려 봅니다.
```bash
uv run tools/flow.py test cases/lab03.json
```
1. `cases/lab03.json`을 열어 케이스마다 **무엇을 기대하는지** 읽습니다. `route`는 "이 답을 그대로 보냈는가, 사람에게 넘겼는가"입니다.
2. `runs/`의 최신 보고서 파일을 열어 `빈 질문`의 `response`와 `seconds`를 봅니다. 질문이 비었는데 LLM이 불렸나요?
3. 아래 표를 채웁니다. 예제 2의 요청문 재료가 됩니다.
| 케이스 | 지금 결과 | 기대 | 무엇이 없어서 실패했나 |
| --- | --- | --- | --- |
| 빈 질문 | | HTTP 400 | |
| 비밀번호 FAQ | | `route` 자동 답변 | |
| 없는 접수 번호 | | `route` 담당자 연결 | |
| 다른 사람 접수 건 | | `route` 담당자 연결 | |
## 예제 2 · 검증과 담당자 연결 (20분)
**만들 것**: 두 번 지키기. ① LLM을 부르기 전에 입력을 확인하고, ② 답을 보내기 전에 답을 확인해, 통과하면 자동 답변, 아니면 담당자에게 넘기기.
```mermaid
flowchart LR
W(["IT question webhook"]) --> H{"입력 검증"}
H -->|false| R0["400 거절"]
H -->|true| AG{{"IT help agent"}} --> C["결과 검증"] --> P{"통과?"}
P -->|true| A["route 자동 답변"] --> R["Send result"]
P -->|false| HO["route 담당자 연결"] --> R
```
| 조건 | 값 |
| --- | --- |
| 빈 질문 | HTTP 400 `{"error": "question is required"}` |
| 결과 검증 | 내가 정한 검사 여러 개 (아래 1단계) |
| 통과 | `route` = `자동 답변` + 답 |
| 실패 | `route` = `담당자 연결`, 정해진 안내 문장, 원래 답(`draft`), 걸린 검사(`failed`) |
| 기대 결과 | `cases/lab03.json` |
▶ 1단계 · 무엇을 검사할지 먼저 적기
"좋은 답"의 조건을 **한 줄 조건**으로 적어 봅니다 (66일차 "한 줄 조건이면 규칙"). 예제 1 표에서 실패한 케이스들이 힌트입니다: 답이 비었을 때, Tool이 아무것도 못 찾았을 때(빈 결과·404·403), 접수 번호 질문인데 접수 Tool을 안 썼을 때… 다섯 개 안팎이면 충분합니다.
▶ 2단계 · 요청문을 번호로 나누기
이번 변화는 크므로 ① 입력 검증 ② 결과 검증(검사 목록) ③ 통과/실패 때 각각의 결과 모양 으로 번호를 나눠 적습니다. 실패 때 보낼 안내 문장과 필드 이름은 정확히 적습니다. 테스트가 `route` 값을 글자 그대로 비교합니다.
▶ 3단계 · 검사를 LLM에게 맡길까
"답이 괜찮은지 LLM에게 다시 물어보기"와 "Code 노드의 조건문"은 무엇이 다른가요? 어느 쪽으로 만들게 할지 요청문에 적습니다 ([3단계 교안 2절](../../Lecture/67/03-STAGE3-VERIFY-AND-FIX.md)).
10분"] --> B["② 돌리기
실패 찾기"] --> C["③ 원인 말하기
→ 에이전트가 고침"] --> D["④ 다시 돌리기
3번 반복"]
D -->|실패| C
D -->|통과| E["⑤ 보고서
5분"]
```
### ① 케이스 쓰기 (10분)
`cases/my-cases.json`을 만들고 **5개 이상** 씁니다. 형식은 [AGENTS.md](AGENTS.md) 7절과 `cases/lab03.json`을 봅니다.
> 기대 결과는 **내가 정하는 업무 규칙**입니다. 예를 들어 이상한 요청을 400으로 거절할지, 담당자에게 넘길지는 팀이 정합니다. 정한 것을 `expect`에 씁니다.
▶ 1단계 · 어떤 질문이 어려울까
직원 입장에서 생각합니다: 다른 언어로 묻는 사람, 한 번에 두 가지를 묻는 사람, 번호를 대충 쓰는 사람, 시스템을 속이려는 사람, 그리고 **필드가 빠진 요청**을 보내는 다른 프로그램. 오늘 만든 기능(FAQ, 접수 현황, 본인 건만, 검증)마다 "이걸 깨뜨리려면?"을 하나씩 떠올려 봅니다.
▶ 2단계 · 기대 결과를 정하는 법
케이스마다 "이러면 안 된다"를 먼저 정하고 `not_contains`로, "이래야 한다"를 `equals`·`contains`로 씁니다. 새면 안 되는 정보(남의 접수 상태·담당자 이름)는 `answer`뿐 아니라 `draft`에도 없어야 하는지 생각해 봅니다. 요청 본문은 `body`에 직접 씁니다.
▶ 3단계 · 케이스를 쓴 뒤 점검
- [ ] 케이스 이름만 보고 무엇을 시험하는지 알 수 있다
- [ ] 기대 결과가 LLM의 표현이 바뀌어도 맞는다 (`contains`는 낱말 하나라도)
- [ ] 적어도 하나는 **보안**(남의 정보)을 시험한다
- [ ] 적어도 하나는 **요청 모양이 이상한** 경우를 시험한다
▶ 1단계 · 에이전트에게 무엇을 줄까
에이전트는 내 화면을 못 봅니다. 실패 보고서 **파일 경로**, 고칠 파일, 그리고 "고치는 동안 지켜야 할 것"(원래 테스트도 통과)을 줍니다. 실패 줄을 내 말로 바꾸지 말고 그대로 줍니다.
▶ 2단계 · 바로 고치게 할까, 설명부터 들을까
먼저 원인을 설명하게 하고, 내가 적은 원인과 비교한 뒤 고치게 하는 방법도 있습니다. 두 원인이 다르면 어느 쪽이 맞는지 보고서의 요청·응답으로 확인합니다.
▶ 3단계 · 여러 개가 실패했을 때
한 번에 다 고치게 하면 서로 다른 수정이 부딪칠 수 있습니다. 하나씩 고치게 할지, 한 번에 고치게 할지 정하고 결과를 비교해 봅니다.