도구가 200을 반환해도, 그 안의 값이 틀릴 수 있다면 무엇을 검증해야 하는가
← 전체 목차 · 이전: 제3자 도구가 갑자기 요청을 제한하면, 재시도가 왜 오히려 눈사태를 키우는가 · 다음: 인터페이스가 200을 반환했는데 Agent 작업은 왜 여전히 실패하는가
try-catch는 "호출이 끊겼는가"를 판정할 뿐, "결과가 쓸 만한가"는 판정하지 못한다. 재고 수량이 음수로 돌아오거나, 사용자 이름이 빈 문자열로 돌아오거나, 조회한 가격이 30분 전 값이어도 — HTTP 200, 문법도 정상, 구조도 멀쩡하다. 이 문서는 도구 결과가 충돌하면 누구 말을 들어야 하나가 다루는 "여러 소스가 서로 다른 값을 줄 때 누구를 믿을 것인가"와는 다른 각도다 — 여기서는 소스가 하나뿐인데, 그 하나가 형식은 멀쩡하고 내용만 틀린 경우를 다룬다.
이상 캐치와 결과 검증은 다른 층위의 문제다
| 판정 기준 | 이상 캐치 | 결과 검증 |
|---|
| 무엇을 보는가 | 제어 흐름이 끊겼는가 | 값이 업무적으로 말이 되는가 |
| 놓치는 것 | 값이 비어 있거나 틀려도 형식이 맞으면 통과시킴 | — |
| 가장 위험한 유형 | — | 형식은 합법, 값은 비어 있음 — 이상 검사와 형식 검사를 동시에 통과함 |
결과 왜곡의 네 가지 차원
| 유형 | 예시 |
|---|
| 형식은 합법하나 업무 논리 위반 | 재고 수량이 음수, 상태 전이가 불가능한 값 |
| 필드는 있으나 값이 비어 있음(형식은 합법) | 이상 캐치로 못 잡음 |
| 결과에 강한 시효성이 있음 | 30분 전 가격을 지금 결정에 씀 |
| 부분 정답 + 부분 오류 혼재 | 하류가 근거를 추적하기 어려움 |
3층 검증 + 시효 관리 + 업무 대조
| 층위 | 검증 내용 | 불통과 시 동작 |
|---|
| 1층 · 기본 형식 검증 | 필드 완전성, 데이터 타입, 값의 범위 | 즉시 이상 판정, 재시도 트리거 |
| 2층 · 업무 규칙 검증 | 재고 비음수, 금액 일치, 상태 전이 합법 등 설정화된 규칙 | 규칙 위반 시 즉시 차단, 하류로 흘려보내지 않음 |
| 3층 · 의미 일관성 검증 | 비구조 결과 대상: 과거 결과와 대조, 컨텍스트 기대와 대조, 다른 도구 반환과 교차 검증 | 논리 모순 식별 |
여기에 두 메커니즘을 얹는다.
- 결과 시효 관리: 모든 도구 반환 결과에 타임스탬프를 찍고 유효 기간을 설정한다. 만료된 결과는 자동 실효 처리해 강제로 재조회하게 만든다.
- 업무 대조: 핵심 업무 노드에 대조를 배치해, 쓰기 작업 실행 완료 후 조회 도구를 호출해 대조함으로써 실행 결과가 기대와 일치하는지 확인한다.
비구조 결과 검증 난제
→ 교차 검증 전략: 핵심 결과를 여러 독립 도구로 교차 대조
또는 2차 조회 인터페이스로 검증
단일 반환 결과에 의존하지 않음
검증 규칙 반복 문제
→ 오류 결과 회류 메커니즘: 온라인에서 놓친 오류 결과를 자동 입고
검증 규칙을 반복 갱신
적발률을 지속적으로 끌어올림
오류 처리 체인
→ 검증 실패 → 자동 재시도
재시도 실패 → 강등: 대체 도구로 전환 / 사람 검토로 전환
어떤 경우든 오류 데이터의 하류 전달을 금지
핵심 통찰
- 이상 캐치는 "호출이 끝났는가"를 다루고, 검증은 "결과를 써도 되는가"를 다룬다 — 둘은 같은 층위가 아니다 — try-catch의 판정 근거는 제어 흐름이 끊겼는지 여부이고, "200 + 합법 JSON + 재고 음수"라는 조합에서는 제어 흐름이 전혀 끊기지 않는다. 신뢰성을 이상 처리 메커니즘에만 걸면, 가장 발견하기 쉬운 유형의 장애만 막게 된다.
- 합법성(형식)·합리성(업무)·시효성(시간)은 서로 독립적인 세 잣대이며, 하나만 빠져도 한 유형의 오류를 놓친다 — 형식이 합법한 데이터가 업무 상식을 위반할 수 있고, 업무상 합리적인 데이터가 30분 전의 죽은 값일 수 있다. 세 잣대는 서로를 함의하지 않는다.
- "필드는 있는데 값이 비어 있는" 것이 가장 음흉한 유형이다 — 이상 검사와 형식 검사를 동시에 통과하기 때문이다 — 필드가 존재하고, 타입이 맞고, 구조가 온전하지만 내용만 없다. 모델은 그대로 추론에 대입하고, 하류는 표류한 결론만 보게 되어 근본 원인을 찾기 어렵다.
- 모델로 모델을 검증하면 안 된다 — 고신뢰 시나리오에서 "모델이 결과를 받으면 먼저 한 번 검사해 보게 한다"는 신뢰 불가능한 소스 하나를 또 다른 신뢰 불가능한 소스로 바꾼 것일 뿐, 독립 정보를 전혀 더하지 못한다. 하드 검증의 가치는 정확히 모델의 자율 판단에 의존하지 않는다는 데 있다 — 규칙, 타임스탬프, 대조 조회는 모두 모델 바깥의 증거다.
- 대조 메커니즘의 본질은 "읽기로 쓰기를 검증하는 것"이다 — 쓰기 작업 실행 후 다시 조회 도구를 한 번 불러, 실제 상태와 기대 상태를 대조한다. 오류를 예측하지 않고 사실을 확인하는 방식이므로, 예상 못 한 유형의 왜곡에도 효과가 있다.
- 비구조 결과는 규칙을 쓸 수 없으니 "다중 출처 일관성"으로 대체한다 — 교차 검증(여러 독립 도구 대조), 2차 조회, 과거 결과·컨텍스트 기대와의 대조는 모두 같은 발상이다: 단일 출처는 스스로를 증명할 수 없고, 다중 출처의 모순이야말로 검출 가능한 신호다.
- 검증 규칙은 반드시 불완전하므로 스스로 반복 통로를 가져야 한다 — 오류 결과 회류 메커니즘이 온라인에서 놓친 샘플을 자동 입고시켜 규칙을 거꾸로 갱신하고 적발률을 끌어올린다. 이 회로가 없으면 규칙 집합은 온라인 개시일의 인식 수준에 영원히 머문다.
- 신뢰 가능한 시스템의 완성형은 "차단 + 안전망 + 가관측성 + 자체 강등" 네 가지의 조합이다 — 차단만 하면 검증 실패 시 멈춰 버리고, 안전망만 있으면 문제가 가려지고, 실패율·누락률 모니터링이 없으면 차단이 유효한지 알 수 없고, 검증 서비스 자체가 장애일 때 강등 경로(전량 사람 검토, 고위험 자율 실행 일시 중단)가 없으면 신뢰성 논증 전체가 순환 논리가 된다.
엔지니어링 실전 Tips
- 검증 규칙은 설정으로 만들 것, 코드로 하드코딩하지 말 것: 재고 비음수·금액 일치·상태 전이 합법 같은 규칙은 업무와 함께 진화하므로, 설정화해야 오류 회류에 맞춰 빠르게 갱신할 수 있다.
- 시효성은 도구 단위로 설정할 것, 전역 일괄 적용하지 말 것: 가격 조회와 사용자 프로필 조회의 유효 기간은 자릿수부터 다르다. 타임스탬프를 찍고 도구마다 유효 기간을 설정하는 방식이 옳다.
- 대조는 핵심 업무 노드에만 붙일 것: 대조는 조회 호출 한 번을 추가로 지불하는 비용이다. 쓰기 작업과 고위험 노드를 우선하고, 전체 링크에 일괄 배치하면 비용 대비 효율이 낮다.
- 교차 검증은 반드시 "독립된" 도구를 쓸 것: 같은 도구를 두 번 부르면 같은 오류의 사본 두 개를 얻을 뿐 검증이 성립하지 않는다.
- 모니터링은 세 가지 비율을 함께 볼 것: 결과 검증 실패율은 상류 품질을, 재시도 성공률은 일시적 장애 비중을, 오류 누락률은 검증 체계 자체의 퇴화를 반영한다 — 셋 중 하나만 보면 나머지가 반격한다.
- 강등 경로는 반드시 "사람"이어야지 "통과"이면 안 된다: 검증 실패 시 강등은 사람 검토로 향해야 한다. 강등의 목표는 정확성을 지키는 것이지 처리량을 지키는 것이 아니다.
- 고위험 자율 실행은 언제든 멈출 수 있어야 한다: 검증 서비스가 장애일 때 "핵심 노드 결과에 대해 고위험 자율 실행을 일시 중단"할 수 있어야 하며, 이는 Agent의 실행 권한이 외부에서 끌 수 있는 등급 설계여야 함을 뜻한다.