에이전트의 출력에 JSON Schema를 강제했습니다. 형식이 맞으면 도구 실행이나 최종 답변을 그대로 신뢰해도 되나요?

구조화 출력은 결과를 파싱 가능한 형태로 제한하는 수단이지 내용의 사실성·권한·업무 규칙을 증명하는 수단은 아닙니다. 주문 ID가 문자열이고 금액이 양수여도 다른 사용자의 주문이거나 환불 가능액을 넘을 수 있습니다. 문법, 스키마, 도메인 검증, 실제 실행 결과를 단계별로 확인하겠습니다.

형식 계약과 의미 계약

예를 들어 출력이 {"action":"refund","amount":1000}이라면 enum과 숫자 타입은 검사할 수 있습니다. 그러나 1000이 원인지 달러의 최소 단위인지, 해당 주문에 이미 환불이 있었는지는 별도 정보입니다. 통화·단위를 명시하고 주문의 현재 상태와 사용자 권한을 신뢰할 수 있는 저장소에서 확인해야 합니다. 외부 서비스의 허용 값은 최신 목록과 대조하며 모델이 그럴듯한 식별자를 만들어 냈을 가능성도 배제하지 않습니다.

API가 제공하는 스키마 강제 범위는 지원하는 JSON Schema 부분집합과 응답 상태에 따라 다를 수 있습니다. 거절·출력 길이 초과·스트림 중단을 일반적인 완성 JSON으로 취급하지 않습니다. 일부 문자열 조각이 도착했다고 실행하지 않고 응답이 완료되고 전체 검증이 끝난 뒤 도구 호출을 확정합니다. 형식 복구를 위해 다시 요청할 수 있지만 복구 재시도가 실제 변경을 반복 실행하는 경로와 섞이지 않아야 합니다.

유효하지 않음을 표현할 수 있어야 합니다

항상 결과를 하나 고르게 하면 자료가 없을 때도 유효한 형태의 허위 값을 만들 수 있습니다. not_found, needs_input, unsupported처럼 실제로 필요한 상태와 근거 필드를 두고, 빈 문자열이나 임의 숫자로 실패를 숨기지 않습니다. 모델이 내놓은 confidence 값 역시 보정된 확률이 아닐 수 있으므로 승인 기준으로 바로 쓰지 않습니다. 근거 문서 ID도 존재 여부와 주장에 대한 뒷받침을 따로 검사합니다.

검증 오류를 모델에 돌려줄 때는 잘못된 필드와 수정 가능한 조건만 좁게 전달합니다. 원본 비밀값·전체 DB 오류·내부 SQL을 포함하면 정보 노출 경로가 생깁니다. 반복 보정 횟수를 제한하고 의미가 모호한 금액·수신자 같은 항목은 사용자에게 확인합니다. 평가에서는 파싱 성공률과 별개로 올바른 대상 선택, 불확실한 상황의 보류, 잘못된 실행 거절률을 측정하겠습니다. 구조화 출력은 유용한 방어선이지만 그 뒤의 결정적 검증을 제거할 이유는 아닙니다.

실행 사례로 확인합니다

상태와 데이터의 조합도 검사해야 합니다. status=not_found인데 예약 번호가 들어 있거나 currency=KRW인데 소수 단위 정책과 맞지 않으면 개별 필드 타입이 맞아도 전체 결과는 모순입니다. 가능한 조합을 스키마로 표현할 수 있으면 표현하고, 지원 범위 밖 관계는 코드에서 검사합니다. 형식 오류를 자동 보정할 때 금액을 반올림하거나 임의 ID를 채우는 등 의미를 바꾸는 복구는 하지 않습니다. 기술적으로 파싱되지 않는 결과와 사용자의 추가 정보가 필요한 결과를 구분하면 모델을 다시 호출해야 할지 질문해야 할지도 명확해집니다. 서버 오류가 모델 보정으로 해결 가능한 인자 오류인지도 확인하겠습니다.