Validation, Repair & Retry Loops
이 문서는 CCAF Domain 4를 이해하기 위한 개념 설명용 노트다.
여기서는 출력 검증을 단순 사후 검사로 보지 않고, 모델 출력의 신뢰성을 검증·복구·재생성을 통해 높여 가는 반복 루프로 이해하는 데 초점을 둔다.
왜 validation만으로는 충분하지 않은가
모델 출력은 스키마를 어길 수 있고, 필드를 누락할 수 있고, 형식은 맞지만 의미가 어긋날 수도 있다.
이때 validation은 중요한 첫 단계다.
하지만 validation만 하고 실패를 끝내버리면,
시스템은 쉽게 brittle해진다.
즉 중요한 것은 단순히 “틀렸는지 찾는 것”이 아니라,
틀렸을 때 어떻게 복구하거나 다시 생성할 것인가
까지 포함하는 것이다.
그래서 출력 신뢰성은 validation 하나가 아니라, validation + repair + retry 루프로 이해하는 편이 맞다.
validation은 무엇을 확인하는가
validation은 보통 아래를 확인한다.
- 필수 필드가 있는가
- 타입이 맞는가
- 허용된 값 범위 안에 있는가
- 형식이 맞는가
- 최소한의 의미 조건을 만족하는가
즉 validation은 단순 파싱 검사가 아니라,
출력이 계약을 지켰는지 확인하는 단계
다.
repair는 무엇을 뜻하는가
repair는 완전히 다시 생성하기 전에, 기존 출력을 수정 가능하게 고치는 단계를 뜻한다.
예를 들어:
- 문자열 숫자를 정수로 변환
- 허용되지 않은 enum 값을 가장 가까운 정규값으로 교정
- 빠진 optional field를 기본값으로 채움
- 형식은 맞지만 wrapper가 잘못된 경우 재정렬
이런 것은 전체 재생성보다 repair가 더 효율적일 수 있다.
즉 repair는:
유효하지 않은 출력을 가능한 한 계약에 맞게 되돌리는 중간 복구 단계
다.
retry는 언제 필요한가
어떤 실패는 repair로 해결되지 않는다.
예를 들어:
- required field가 통째로 누락됨
- 구조 자체가 크게 틀어짐
- 의미적으로 잘못된 분류가 반복됨
- 출력의 핵심 정보가 비어 있음
이런 경우는 부분 교정보다 새로운 생성 시도(retry) 가 더 적절하다.
즉 핵심은:
- 사소한 형식 문제 → repair
- 구조적/의미적 실패 → retry
로 나누는 것이다.
hard fail은 언제 필요한가
모든 실패를 계속 고치려 들면, 시스템이 오히려 불안정해질 수 있다.
예를 들어:
- 여러 번 retry해도 핵심 필드가 계속 빠지거나
- confidence가 낮은 결과를 억지로 복구하려 하거나
- 잘못된 출력을 반복적으로 보정하다 의미가 왜곡될 수 있다
이럴 때는 hard fail이 필요하다.
즉 좋은 루프는 무한 복구가 아니라,
어디까지 복구를 시도하고, 어디서 실패로 끊을지 경계를 정하는 구조
다.
왜 이게 reliability engineering인가
출력 신뢰성은 좋은 프롬프트 한 번으로 끝나지 않는다.
실제로는:
- 생성하고
- 검증하고
- 고치거나
- 다시 생성하고
- 일정 기준을 넘으면 실패로 중단하는
루프를 설계해야 한다.
즉 output reliability는 우연히 맞기를 기대하는 것이 아니라,
검증과 복구 루프를 통해 점진적으로 확보하는 것
에 가깝다.
이게 바로 D4의 핵심 중 하나이며, 장기 실행 에이전트의 reliability 패턴과도 직결된다.
schema, validation, repair는 어떻게 연결되는가
이 셋은 따로 떨어져 있지 않다.
- [[concepts/output-design/schema-design-for-reliability|schema]]는 무엇이 유효한지 정의하고
- validation은 실제 출력이 그 정의를 만족하는지 검사하고
- repair / retry는 만족하지 못한 출력을 어떻게 다룰지 결정한다
즉 schema만 있고 validation이 약하면 계약이 비어 있고,
validation만 있고 repair 전략이 없으면 시스템이 brittle해진다.
핵심은:
출력 계약은 정의만으로 완성되지 않고, 검사와 복구 루프까지 있어야 실제로 신뢰 가능해진다
는 점이다.
흔한 오해
“validation만 붙이면 신뢰성이 확보된다”
아니다. 실패 시 복구 전략이 없으면 시스템이 쉽게 깨진다.
“틀린 출력은 무조건 재생성하면 된다”
그렇지 않다. 사소한 형식 문제는 repair가 더 효율적일 수 있다.
“repair를 많이 할수록 좋다”
아니다. 의미 왜곡을 막기 위해 hard fail 경계도 필요하다.
한 문장 요약
출력 신뢰성은 validation 하나로 생기는 것이 아니라, 검증·복구·재생성·실패 경계를 포함한 루프로 만들어진다.