구조화된 AI 출력은 스키마 검증만으로 끝나지 않는다

구조화된 AI 출력의 안전한 처리 방법은 모델 응답을 곧바로 데이터베이스에 넣지 않고, 문법·의미·업무 규칙을 순서대로 검증하는 것입니다. JSON Schema가 통과했다는 사실은 필드의 모양만 맞는다는 뜻이지 금액, 상태, 권한이 올바르다는 뜻은 아닙니다.

이 글에서는 입력 계약을 만들고, 모델 출력을 검증하고, 실패한 응답을 보류 큐로 보내는 흐름을 설명합니다. 목표 산출물은 검증 결과와 원문을 함께 추적할 수 있는 한 건의 판정 기록입니다.

구조화 출력 계약과 거절 파이프라인

첫째 문법 검증은 JSON 파싱과 필수 키, 타입, 열거값을 확인합니다. 둘째 의미 검증은 날짜 순서나 합계처럼 여러 필드의 관계를 확인합니다. 셋째 업무 검증은 현재 사용자의 권한과 시스템 상태에서 이 값을 저장해도 되는지 확인합니다. 한 층에서 실패하면 다음 단계로 넘기지 않는 것이 경계를 분명하게 만듭니다.

이 글의 가상 사례는 Chat Completions의 response_format에 JSON Schema와 strict 옵션을 주는 상황을 기준으로 합니다. Structured Outputs는 지원되는 스키마 하위 집합이 있으므로 애플리케이션의 최종 검증을 대체하지 않습니다. 자세한 제약은Structured Outputs API 참고 문서에 기록되어 있습니다.

검증기를 구현하고 판정 기록을 남깁니다

검증기는 통과 또는 실패만 반환하지 말고 request_id, schema_version, 원문 해시, 실패 단계, 사람이 확인할 사유를 남겨야 합니다. 원문 전체를 로그에 남길 수 없는 환경이라면 접근 통제된 보류 저장소와 해시를 분리합니다. 이 기록이 있어야 프롬프트 변경 뒤 실패율이 늘었는지 재현할 수 있습니다.

1. JSON을 파싱하고 스키마 버전을 확인한다.

2. 필드 간 관계와 허용 범위를 계산한다.

3. 권한·중복·현재 상태를 확인한 뒤 저장한다.

가상 사례: 문의 분류 결과를 저장하기

가상 사례의 입력은 고객 문의와 모델의 {category, urgency, summary} 응답입니다. 결정은 category를 네 개 값으로 제한하고 urgency가 high이면 담당자 배정이 필요한 것으로 정합니다. 중간 산출물은 세 검증층의 결과를 담은 판정 기록이며, 기대 결과는 통과 건만 티켓 테이블에 저장되고 나머지는 보류 큐에 쌓이는 것입니다.

실패하면 재시도보다 원인을 보존합니다

예를 들어 JSON은 유효하지만 urgency가 high이고 담당자 목록이 비어 있으면 업무 규칙에서 실패합니다. 같은 프롬프트를 무한 재시도하면 비용과 중복 처리가 늘어납니다. 오류 단계와 누락 필드를 기록하고, 재시도 횟수를 제한한 뒤 사람이 확인하는 보류 큐로 우회합니다. 스키마 버전이 바뀐 경우에는 이전 검증기로 재현할 수 있게 버전을 고정합니다.

반례도 있습니다. 자유 형식의 브레인스토밍처럼 후속 저장이 필요 없는 응답에는 이 파이프라인이 과합니다. 그 경우에는 출력 길이와 금칙어 정도만 검사하고 구조화 저장을 요구하지 않는 편이 낫습니다.

완료 조건

검증 완료는 샘플 성공 한 건이 아니라 정상·스키마 오류·의미 오류·업무 오류를 각각 재현하고, 모든 판정에 단계와 스키마 버전이 기록되며, 통과 건만 저장되는 것을 확인한 상태입니다. 이 기록을 테스트 결과에 남기면 프롬프트나 모델을 바꿀 때 다시 비교할 수 있습니다.