프로세스 3 — 자동 검증

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

테스트가 유일한 판정 기준

IntentOps에서 정한 테스트가 여기서 판정자가 됩니다.

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

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

자가 치유 루프

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

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

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

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

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

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

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

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

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

왜 이게 위험한가

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

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

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

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

2. 층을 겹치세요

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

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

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

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

4. 루프에 한계를 거세요

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

AI 출력 자체를 평가할 때

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

확인

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

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

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

우리 산출물에 관문을 직접 세워봅니다. 40분입니다 → 검증 관문을 설계해보기