AI 표·JSON 검증: 누락·단위·합계 오류 찾기

가지런한 표와 정상적으로 읽히는 JSON에도 누락과 오역, 잘못된 합계가 남습니다. 결과를 다른 문서나 시스템에 넘기기 전에 확인할 데이터 기준을 짚습니다.

AI가 정리한 견적표를 복사하거나 JSON을 프로그램에서 읽었을 때, 오류 없이 열렸다는 사실만으로 각 값의 근거까지 확인되지는 않습니다. RFC 8259가 정하는 것은 JSON으로 데이터를 표현하는 문법입니다. 견적의 수량이 원문과 같은지, 합계에 배송비가 들어갔는지는 업무 규칙과 원자료를 대조해 판단합니다.

출력 형식을 지정하는 요청법은 프롬프팅 가이드의 구조화 출력 설명에 있습니다. 결과를 받은 뒤에는 읽을 수 있는지, 약속한 필드를 갖췄는지, 그 값이 원문에 맞는지를 별도로 확인합니다. 이 세 판단을 한 번의 ‘정상’ 표시로 합치면 오류가 어느 단계에서 생겼는지 찾기 어려워집니다.

문법 검사와 스키마 검사가 확인하는 범위

문법 검사는 문자열을 JSON 데이터로 읽을 수 있는지 확인합니다. 닫는 괄호가 빠졌거나 마지막 값 뒤에 불필요한 쉼표가 있으면 여기서 실패합니다. 응답 앞에 설명 문장이 붙은 경우도 JSON만 받기로 한 입력 처리에서는 실패 원인이 됩니다.

스키마 검사는 읽어 들인 데이터가 필드 이름과 자료형, 허용값 같은 계약에 맞는지 확인합니다. JSON Schema의 객체 설명에 따르면 properties에 이름을 적는 것만으로 그 필드가 필수가 되지는 않습니다. 필수 목록은 required로 정하고, 추가 필드를 막으려면 그에 맞는 additionalProperties 규칙도 둡니다.

의미 검사는 같은 모양의 값 중에서 어떤 값이 옳은지 따집니다. 날짜처럼 생긴 문자열이 주문일인지 출고일인지, 숫자 12가 원인지 천 원인지는 필드와 원문 사이의 관계입니다. 스키마에 업무 제약을 많이 담을수록 일부 의미 오류도 잡을 수 있지만, 원문에 없는 사실을 채웠는지까지 구조만으로 판단할 수는 없습니다.

다음 표는 검사 규칙을 정할 때 쓰는 구분입니다.

검사 단계	확인할 것	통과해도 남는 오류	실패 뒤의 조치
문법	JSON 파싱 가능 여부, 응답 경계	틀린 수량과 날짜, 빠진 기록	원응답 보존 후 형식 오류만 수정
스키마	필수 필드, 자료형, 범위와 허용값	허용 범위 안의 잘못된 값	실패 필드와 기대 규칙을 전달
업무 규칙	단위, 계산식, 필드 사이 관계	원문 자체의 오류	식과 단위를 원문 조건으로 재검산
원문 대조	값의 출처, 모든 대상 행의 반영	원자료의 진위와 작성자의 착오	근거 위치를 확인하고 미확인을 분리

업무 규칙과 원문 대조를 나눈 이유는 원문에서 옮긴 값도 서로 맞지 않을 수 있기 때문입니다. 원문에 잘못 적힌 합계를 그대로 추출했다면 전사는 맞고 계산은 틀립니다. 이때 원문 값과 재계산 값을 함께 남겨야 잘못 옮긴 경우와 원자료가 잘못된 경우를 구분할 수 있습니다.

빈값과 단위까지 적어야 데이터 계약이 됩니다

null, 빈 문자열, 숫자 0, 필드 부재는 다른 상태입니다. JSON Schema의 객체 설명도 null이 들어 있는 필드와 필드가 없는 경우를 구분합니다. 출고일을 모르는 주문에 빈 문자열을 넣을지 null을 넣을지, 아예 필드를 생략할지를 받는 쪽과 맞추지 않으면 후속 처리가 제각각이 됩니다.

빈값은 ‘미확인’, ‘해당 없음’, ‘원문에 미기재’를 구분할 필요가 있습니다. 날짜 값은 모두 null이어도 별도 상태 필드에 이유를 남길 수 있습니다. 반대로 금액을 모른다는 뜻으로 0을 넣으면 무료 항목으로 계산될 수 있으므로, 미확인 금액과 실제 0원을 구분합니다.

필드의 계약에는 이름과 자료형 외에 단위, 기준 시점, 허용된 변환도 들어갑니다. 금액을 원 단위 정수로 받는다면 ‘1.2만 원’을 12000으로 바꿀 수 있지만, 통화가 없는 숫자를 임의로 원화로 해석하는 것은 다른 판단입니다. 날짜도 원문이 월·일만 제시했다면 연도를 보충할 근거가 있는지 따로 적습니다.

JSON Schema의 자료형·형식 설명은 format이 기본적으로 주석 역할을 하며, 실제 검증은 구현과 설정에 따라 달라진다고 설명합니다. format: date를 적었다는 이유만으로 잘못된 날짜가 항상 거부된다고 가정하면 검사 범위를 잘못 이해하게 됩니다. 사용 중인 검증기의 형식 검사 설정과 지원 항목을 확인한 뒤 날짜 검증 범위를 정합니다.

표로 받을 때도 같은 계약을 머리글과 설명에 담습니다. ‘매출’ 대신 ‘매출액, 원, 부가세 제외’처럼 값을 해석하는 단서가 있어야 합니다. 단위가 열마다 다르면 열 이름에 적고, 모든 행이 같은 조건이라면 표 앞에 공통 조건을 둡니다.

형식은 맞지만 값이 틀린 JSON의 추적

다음은 검증 방법을 설명하기 위해 만든 가상 주문명세입니다. 원문에는 “기록 Q-17, 보관함 2개, 개당 12,000원, 배송비 3,000원, 작성일 10월 5일, 출고일 미정”이라고 적혀 있습니다. 합계는 상품 금액과 배송비를 더하는 것으로 정하고, 다른 금액 항목은 없다고 가정합니다.

json복사

{
  "record_id": "Q-17",
  "currency": "KRW",
  "quantity": 2,
  "unit_price": 12000,
  "shipping_fee": 3000,
  "total": 24000,
  "ship_date": "2026-10-05",
  "status": "confirmed"
}

이 JSON은 정상적으로 읽히며, 숫자와 문자열의 자료형도 구분돼 있습니다. status의 허용값에 confirmed가 들어 있고 날짜를 문자열로 허용한 느슨한 스키마라면 그 검사도 통과할 수 있습니다. 그런데 합계는 정한 식으로 계산하면 27,000원이고, 원문은 출고일이나 주문 확정을 알려 주지 않습니다.

오류를 찾은 뒤에는 “데이터가 틀렸다”는 한 줄 대신 필드별로 근거를 붙입니다. 아래 판정은 위 가상 원문과 명시한 합계 규칙에만 적용합니다.

필드	응답 값	원문·계약과의 차이	처리
total	24000	배송비를 더한 합계 27000과 다름	원문 합계가 아닌 계산값임을 기록하고 재계산
ship_date	2026-10-05	작성일을 출고일로 옮겼고 연도도 근거 없음	출고일 미정 상태로 되돌림
status	confirmed	원문에 주문 확정 근거 없음	계약에 정한 미확인 상태로 보류
record_id	Q-17	원문 식별자와 일치	원문 위치와 함께 유지

날짜 오류는 문자열의 생김새를 검사해 해결되지 않습니다. 같은 10월 5일이어도 어떤 사건의 날짜인지 연결이 잘못됐기 때문입니다. 원문 위치를 값마다 붙이면 이런 바꿔 옮기기를 검토할 수 있고, 출처 위치가 없는 생성값도 따로 모을 수 있습니다.

수정을 AI에 다시 맡길 때는 원문과 실패 필드, 기대 규칙을 함께 줍니다. “합계를 고쳐 달라”만 보내면 숫자 하나는 바뀌어도 출고일과 상태의 근거 부족이 남습니다. 수정된 결과는 원응답과 분리해 저장하고 문법 검사부터 다시 확인합니다.

표는 개별 셀과 전체 행을 함께 대조합니다

표에는 셀 하나하나가 그럴듯한데 대상 행이 빠진 오류가 있습니다. 원문에 주문이 열 건 있었다면 결과의 행 수뿐 아니라 식별자 집합이 같은지 확인합니다. 열 건이 나왔어도 한 주문을 두 번 넣고 다른 주문을 빼면 행 수 검사만 통과합니다.

일대일 추출에서는 원문 식별자와 결과 식별자를 비교해 누락, 중복, 새로 생긴 항목을 나눕니다. 집계 표라면 한 결과 행에 여러 원문 행이 묶이므로, 묶음 기준과 포함한 원문 식별자를 남깁니다. 일대일 규칙을 집계 결과에 그대로 적용하면 정상적인 묶음도 누락으로 오판합니다.

합계가 일치해도 행별 값은 틀릴 수 있습니다. 두 행의 금액을 서로 바꾸면 전체 합계는 유지됩니다. 금액뿐 아니라 상품명, 수량, 날짜, 식별자가 같은 원문 행에서 왔는지 확인해야 행끼리 섞인 오류를 찾습니다.

변환 과정에서 원문을 덮지 않는 방법은 업무 프롬프트의 데이터 통일 예시와 연결됩니다. 원본 열과 변환 열을 함께 두고, 애매한 날짜나 단위는 별도 상태로 남기면 재검토할 자리가 생깁니다. 표를 보기 좋게 정리한 뒤 원본을 버리면 잘못된 변환의 출발점을 찾기 어려워집니다.

재요청·보류·중단을 가르는 기준

재요청으로 해결할 수 있는 것은 원문과 계약이 충분한데 출력이 어긋난 경우입니다. 필수 필드 누락, 잘못된 자료형, 허용값 오타처럼 실패 지점을 구체적으로 알려 줄 수 있습니다. 자동 재시도 횟수는 업무의 비용과 지연 허용 범위에 맞춰 제한하고, 같은 오류가 반복되면 사람이 볼 대기열로 보냅니다.

원문에 없는 값이나 서로 모순되는 수치를 채워야 하는 경우에는 자료 보완이 먼저입니다. 모르는 출고일을 그럴듯한 날짜로 바꾸는 재시도는 근거를 늘리지 못합니다. 답을 받는 시스템이 미확인 상태를 처리하지 못한다면, 그 기록은 저장·실행을 보류하고 계약부터 수정합니다.

후속 작업의 성격도 중단 기준을 바꿉니다. 검토용 초안 표는 미확인 셀을 표시한 채 넘길 수 있지만, 주문 확정이나 외부 전송에 쓰는 값은 확인되지 않은 항목이 남았을 때 실행 경계를 넘기지 않습니다. 같은 필드라도 어디에 쓰이는지에 따라 허용되는 상태가 달라집니다.

실무에서는 통과 여부만 저장하기보다 원문 식별자, 규칙 버전, 실패 필드, 수정 전후 값, 재검사 결과를 한 묶음으로 남기는 편이 좋습니다. 그래야 다음 오류를 다시 질문하는 데서 끝내지 않고, 원문 추출·규칙 정의·후속 처리 중 어느 부분을 고칠지 정할 수 있습니다.

자료 확인 기준: 2026년 10월 28일. 예시 주문명세와 처리 기준은 설명용으로 구성했습니다.

블로그실전 활용