# 프로세스 3 — 자동 검증

> **이 장에서 배우는 것**
> 자가 치유 루프가 어떻게 도는지, 그리고 이 루프가 "통과"를 만들어내는 위험한
> 경우.

## 테스트가 유일한 판정 기준

[IntentOps](/guide/ha-intentops)에서 정한 테스트가 여기서 판정자가 됩니다.

> **전부 통과하면 완료. 하나라도 실패하면 미완료.**

"거의 다 됐다", "이 정도면 됐다"가 없습니다. 이 명확함이 자동화를 가능하게
합니다 — 사람이 판정하지 않아도 다음 단계로 넘어갈 수 있습니다.

## 자가 치유 루프

실패하면 사람을 부르는 게 아니라 **스스로 고칩니다.**

```mermaid
graph TD
  T["테스트 실행"] --> F{"전부 통과?"}
  F -->|"아니오"| D["실패 원인 진단"]
  D --> R["코드 재생성"]
  R --> T
  F -->|"예"| N["배포 단계로"]
```

한 사이클이 이렇게 돕니다.

```
1회전: 테스트 3번 실패 — "만료 쿠폰 메시지가 다름"
       → 진단: 메시지 문구가 명세와 불일치
       → 수정 후 재실행

2회전: 테스트 5번 실패 — "총액 갱신 안 됨"
       → 진단: 상태 갱신 누락
       → 수정 후 재실행

3회전: 전부 통과 → 다음 단계
```

**사람이 이 루프에 없습니다.** 사람은 루프를 돌리는 대신 **루프의 판정 기준이
옳은지**를 봅니다.

## 여기가 가장 자주 무너집니다

이 방법론의 최대 취약점입니다.

> **테스트가 얕으면 루프는 "통과"를 만들어냅니다.**

무슨 뜻인지 예로 보겠습니다.

```
테스트: "쿠폰 적용 후 총액이 원가보다 작아야 한다"

AI가 만든 통과 코드:
  총액 = 원가 - 1원

→ 테스트는 통과합니다. 의도는 완전히 어긋났습니다.
```

극단적인 예지만 원리는 같습니다. **루프의 목표는 테스트 통과이지 의도 충족이
아닙니다.** 둘이 어긋나면 루프는 테스트 쪽으로 갑니다.

### 왜 이게 위험한가

| | 사람이 만들 때 | 자가 치유 루프 |
|---|---|---|
| 테스트가 얕으면 | 사람이 상식으로 보완 | **빈틈을 정확히 파고듦** |
| 결과 | 대체로 의도대로 | 테스트만 만족 |

사람은 "이건 아니지"라고 알지만 루프는 모릅니다. **얕은 테스트가 사람보다 AI에게
더 위험한 이유**입니다.

## 그래서 테스트를 어떻게 쓰나

### 1. 테스트를 명세로 취급하세요

```
✗ 코드가 안 통과하니 테스트를 고친다     ← 방어선이 사라짐
✓ 코드가 안 통과하면 코드를 고친다
✓ 테스트가 의도와 다르면 명세부터 고친다
```

**테스트를 코드에 맞추는 순간** 이 방법론의 전제가 무너집니다.

### 2. 층을 겹치세요

한 층만으로는 통과와 정상을 구분 못 합니다.

| 층 | 잡는 것 |
|---|---|
| 단위 | 함수 하나의 동작 |
| 통합 | 여러 부분이 함께 도는지 |
| E2E | 사용자 관점에서 실제로 되는지 |

E2E가 있으면 위의 "총액 = 원가 - 1원" 같은 것이 걸립니다. 실제 화면에서 이상하기
때문입니다.

### 3. 샌드박스에서 돌리세요

문제 있는 코드가 **프로덕션에 닿기 전에** 격리된 곳에서 돕니다. 루프가 도는
동안에는 실제 데이터에 손대면 안 됩니다.

### 4. 루프에 한계를 거세요

```
□ 최대 재시도 횟수 (예: 5회)
□ 초과하면 사람 호출
```

무한히 돌면 비용만 씁니다. 다섯 번 고쳐도 안 되면 **명세나 테스트에 문제가 있는
것**이라 사람이 봐야 합니다.

## AI 출력 자체를 평가할 때

여기까지는 **코드**에 대한 테스트입니다. 만드는 것이 AI 응답 자체라면(고객 응대
문구 등) 테스트가 아니라 [평가(Evals)](/guide/ai-evaluation)를 씁니다. 둘을
헷갈리지 마세요.

---

## 확인

**1. 자가 치유 루프에서 사람은 무엇을 합니까?**

<details>
<summary>답</summary>

**루프를 돌리는 게 아니라 루프의 판정 기준이 옳은지를 봅니다.** 테스트가 의도를
제대로 표현하고 있는지가 사람의 일입니다.
</details>

**2. "얕은 테스트가 사람보다 AI에게 더 위험한" 이유는?**

<details>
<summary>답</summary>

사람은 테스트에 빈틈이 있어도 **상식으로 보완**하지만, 루프는 목표가 테스트
통과라서 **빈틈을 정확히 파고듭니다.** "총액 = 원가 - 1원"처럼 통과하지만 의도와
어긋난 코드가 나옵니다.
</details>

**3. 테스트를 고쳐서 통과시키면 왜 안 됩니까?**

<details>
<summary>답</summary>

**테스트가 유일한 방어선이기 때문**입니다. 코드에 맞춰 테스트를 고치는 순간
"테스트가 완료를 판정한다"는 전제가 무너지고, 그러면 [코드를
재생성](/guide/ha-fluid-software)해도 맞는지 확인할 수 없게 됩니다.
</details>

---

우리 산출물에 관문을 직접 세워봅니다. 40분입니다 →
[검증 관문을 설계해보기](/guide/ha-try-validation)