AI가 만든 JSON, 자동 실행 전에 무엇을 검증해야 할까

AI가 만든 JSON을 문의 분류나 업무 등록에 연결한다면, 정상적으로 읽히는지만 확인해서는 부족하다. 필수값과 자료형이 맞는지, 값이 원문과 일치하는지, 그 값으로 실행할 행동이 허용됐는지를 차례로 확인해야 한다. JSON은 정보를 담는 형식이고, 업무 실행의 정당성은 별도로 판단할 문제다.

이 글은 특정 모델의 구조화 출력 기능을 비교하는 글이 아니다. 어느 도구에서 받은 결과든 후속 자동화에 넣기 전에 확인할 검증 순서를 다룬다.

파싱 성공과 검증 통과는 다른 결과다

파싱은 문자열을 프로그램이 다룰 데이터로 읽는 과정이다. 중괄호와 쉼표가 맞아 읽혔더라도 필요한 항목이 빠졌거나, 숫자가 문자열로 들어왔거나, 업무에서 허용하지 않은 값이 섞일 수 있다.

JSON Schema의 객체 문서에 따르면 properties에 항목을 적는 것만으로 필수값이 되지는 않는다. 필수 항목은 required로 지정하고, 정의하지 않은 추가 항목을 거부하려면 해당 스키마에서 additionalProperties: false처럼 규칙을 명시해야 한다. 도구가 지원하는 스키마 범위도 따로 확인한다.

다음은 실제 고객 데이터나 운영 시스템이 아닌 설명용 가상 예시다. 문의를 배송·반품·기타 중 하나로 분류하고 수량을 정수로 받는다고 가정한다.

{
  "type": "object",
  "properties": {
    "request_type": {
      "type": "string",
      "enum": ["delivery", "return", "other"]
    },
    "quantity": {
      "type": "integer",
      "minimum": 1
    }
  },
  "required": ["request_type", "quantity"],
  "additionalProperties": false
}

enum은 허용된 값의 집합을 제한한다. 숫자형과 minimum 규칙은 수량처럼 숫자 조건이 있는 필드를 검사한다. 여기서 최소 수량 1은 가상 업무의 규칙이며 모든 서비스에 적용할 기준은 아니다.

형식이 맞아도 원문과 다른 값은 통과할 수 있다

원문이 “배송된 물건 세 개 중 하나를 반품하고 싶다”인데 AI가 {"request_type":"return","quantity":3}을 반환했다고 하자. 위 스키마는 이 값을 허용하지만, 반품 수량은 원문과 어긋난다. 자료형 검사만으로 ‘배송 수량’과 ‘반품 수량’을 구별할 수 없기 때문이다.

이 경우 수량 필드가 뜻하는 대상을 먼저 명확히 하고, 원문의 어느 구절에서 값을 가져왔는지 대조해야 한다. 근거를 출력에 포함한다면 스키마에도 그 필드를 정식으로 정의한다. AI가 제시한 인용문 역시 원문에 실제로 존재하는지 확인해야 한다. 출처 필드가 생겼다는 사실만으로 근거가 검증되는 것은 아니다.

입력 자체가 잘못 읽혔을 가능성이 있다면 OCR 오류와 LLM 해석 오류를 구분하는 순서로 돌아가 값이 처음 달라진 위치를 확인할 수 있다. 여기서는 추출 이후의 결과를 어떤 조건으로 후속 처리에 넘길지에 집중한다.

검사 결과에 따라 다음 행동을 다르게 정한다

아래 표는 이 글에서 제안하는 운영 판단표다. 사용하는 도구의 오류 응답과 업무 위험에 맞춰 적용한다.

확인 지점	가상 실패 예	다음 판단
응답·파싱	응답 중단, 비어 있는 결과, 깨진 JSON	완료 응답인지 확인하고 원본 응답을 보존한다. 값을 추정해 채우지 않는다.
스키마	필수값 누락, 허용 목록 밖 분류	실패 필드와 규칙을 특정한다. 무조건 같은 요청을 반복하지 않는다.
업무 의미	반품 수량 대신 배송 수량을 사용	해당 값과 원문 근거를 대조하고 불명확하면 보류한다.
실행 권한	분류 결과만으로 고객 상태를 변경	실행 주체가 허용된 작업·대상인지 별도로 확인한다.

특히 AI가 반환한 "approved": true 같은 값이 실제 승인을 대신하게 두면 안 된다. 승인 여부는 사용자의 위임이나 시스템의 권한 근거와 연결돼야 한다. 모델 출력이 자기 실행을 승인하는 구조는 형식 검증으로 해결되지 않는다.

검증 실패를 기록할 때 무엇을 남길까

처음에는 업무별로 파싱 실패, 스키마 실패, 근거 불일치, 실행 보류를 나눠 세는 것으로 시작할 수 있다. 비율을 비교하려면 같은 기간의 검사 대상 건수도 함께 남긴다. 형식 통과율이 높아져도 원문 불일치가 그대로라면 출력 모양만 개선된 것일 수 있다.

필요한 기록은 문제 필드, 적용 규칙, 비교한 원문 위치와 처리 결과다. 원본을 보존할 때에도 접근 권한과 보존 기간을 정하고, 일반 오류 로그에 민감한 본문 전체를 복사하지 않는 편이 좋다. 목표는 로그를 늘리는 것이 아니라 다음 담당자가 어떤 검사가 실패했는지 재확인할 수 있게 하는 것이다.

자주 묻는 질문

JSON Schema를 통과하면 AI 답변이 사실이라는 뜻인가요?

아니다. 스키마가 검사하는 것은 작성한 규칙에 맞는 데이터 구조와 값의 조건이다. 주문 수량이 원문과 같은지, 분류가 업무 의도와 맞는지는 별도의 근거 비교가 필요하다.

값이 없으면 0이나 빈 문자열을 넣어도 되나요?

업무에서 ‘없음’과 0이 같은 의미로 정의된 경우에만 가능하다. 확인하지 못한 수량을 0으로 바꾸면 실제로 수량이 없다는 뜻이 될 수 있다. 누락·미확인 상태를 어떻게 표현할지 먼저 정하고, 소비하는 쪽도 그 상태를 처리하게 한다.

형식 오류가 나면 AI에 다시 물어보면 해결되나요?

응답이 중간에 끊겼는지, 생성 지시와 스키마가 충돌하는지부터 확인한다. 원인을 고치지 않은 반복 호출은 같은 오류를 되풀이할 수 있다. 이미 외부 행동이 실행됐는지도 분리해 확인해야 한다.

값의 형식이 맞아도 외부 자료가 행동을 바꾸려 한다면 외부 문서의 지시문이 실행 권한으로 바뀌는 문제를 함께 점검해야 한다.

출력 형식을 고친 뒤 기존 사례까지 다시 확인하려면 프롬프트 변경 전 회귀 평가의 비교 방법을 적용할 수 있다.