문서 AI의 빈 값, null·빈 문자열·0으로 바꾸기 전에

문서 AI가 금액이나 수량을 JSON으로 옮길 때, 비어 있는 값을 모두 0으로 채우면 읽기 쉬운 데이터가 될 수는 있다. 그러나 확인하지 못한 값이 ‘확인된 0’으로 바뀌면 합계와 업무 판단도 달라진다. 필드가 없는 경우, null인 경우, 빈 문자열인 경우, 숫자 0인 경우를 구별하고, 그 뜻을 값을 받는 프로그램과 함께 정해야 한다.

이 글은 이미 추출된 값을 정리해 보고서나 갱신 요청으로 넘기는 담당자를 위한 설명이다. 아래 청구서와 연락처 사례는 설명용 가상 상황이다. 실제 회사 자료나 AI 모델의 처리 결과가 아니며, 제안한 업무 절차를 운영 서비스에 적용해 시험하지 않았다.

네 가지 표현은 저마다 다른 정보를 남긴다

JSON Schema의 null 안내는 null과 필드 부재를 구별한다. null은 JSON의 값 한 종류다. 그것만으로 ‘미입력’, ‘판독 불가’, ‘해당 없음’ 중 무엇인지는 정해지지 않는다. 그 구분은 문서의 항목 설명과 업무 계약에서 찾아야 한다.

받은 표현	형식으로 확인되는 것	추가로 확인할 것
{}	해당 키가 없다	선택 항목인지, 추출 실패인지, 응답이 일부인지
{"amount":null}	키는 있고 값은 null이다	알 수 없음·해당 없음·지우기 중 무엇을 뜻하는지
{"amount":""}	길이 0인 문자열이다	원문 공란인지, 입력 중간값인지, 숫자 필드의 오류인지
{"amount":0}	숫자 0이 있다	원문과 단위가 실제 0을 뒷받침하는지

원문에 ‘없음’이라고 적힌 것과 아무것도 적히지 않은 것도 같지 않다. ‘없음’이 해당 항목의 0을 뜻한다는 규칙이 있으면 변환할 수 있지만, 다른 문서의 같은 표현에 자동으로 확대하지 않는다. 공백 문자만 든 문자열도 길이 0인 문자열과는 다르다. 공백 제거가 허용된 항목인지 먼저 정한다.

가상 사례: 합계 12,000원과 총액 미확인을 함께 남긴다

가상의 비용 문서 세 건에서 A는 12,000원, B는 ‘추가 비용 없음’, C는 금액란 공란이라고 하자. 이 문서의 안내에서 ‘추가 비용 없음’을 0원으로 정의했다면 A와 B의 확인된 금액 합은 12,000원이다. C까지 0원으로 채워 ‘세 건의 총액 12,000원’이라고 쓰면 확인되지 않은 금액을 확정한 셈이다.

이 상황에서는 ‘금액 확인 2건, 미확인 1건, 확인된 금액 합계 12,000원’처럼 범위를 남길 수 있다. 전체 총액이 필요한 업무는 C의 근거를 확보할 때까지 해당 결론을 보류한다. 숫자를 계산할 수 있다는 것과 계산 대상이 완전하다는 것을 나누는 것이다. 원문 자체가 잘못 읽힌 경우에는 OCR 표의 값과 행·열 연결 확인으로 돌아가야 한다.

필수 항목과 null 허용, 기본값 적용은 각각 정한다

JSON Schema의 required 설명에서 필수 여부는 키의 존재에 관한 조건이다. 예를 들어 amount를 필수로 두면서 자료형을 number 또는 null로 허용하면, 키가 빠진 응답과 null을 담은 응답의 검증 결과가 달라질 수 있다. null을 허용했다는 사실이 금액 확인을 완료했다는 뜻은 아니다.

스키마에 default: 0을 적었다고 검증 과정에서 빠진 값이 자동으로 채워지는 것도 아니다. 공식 annotations 안내는 default를 누락값을 채우는 검증 동작으로 정의하지 않는다. 일부 도구가 별도 옵션으로 값을 주입한다면 그 동작을 따로 확인해야 한다. 파싱·검증 전후의 실제 객체를 비교하면 누가 값을 채웠는지 찾는 데 도움이 된다.

작성자는 원문 위치와 원래 표현, 변환한 값, 미확인 이유를 필요한 범위에서 연결할 것을 제안한다. 기존 레코드에 그 정보가 충분하면 새 관리 체계를 만들 필요는 없다. 원문에 개인정보가 있다면 일반 오류 로그에 본문 전체를 복사하지 않고 허용된 원문 위치를 참조한다.

같은 null이라도 갱신 요청에서는 삭제가 될 수 있다

가상의 연락처 원문에서 전화번호를 찾지 못해 {"phone":null}을 만들었다고 하자. 이 객체를 기존 연락처의 갱신 요청에 그대로 넣기 전에, API의 null 처리 계약을 확인해야 한다. RFC 7396의 JSON Merge Patch에서는 객체의 null 멤버가 기존 멤버 제거를 뜻한다. 미확인을 표현하려던 값이 저장된 전화번호를 지울 수 있는 구체적인 계약 사례다.

이 규칙은 application/merge-patch+json의 처리 방식이며 모든 JSON 요청이나 모든 PATCH API에 적용되는 규칙은 아니다. 변경할 정보가 없는 상태와 사용자가 삭제를 의도한 상태를 구별하고, 실제 API 문서가 정한 표현으로 요청을 만든다. 추출 결과의 키가 없다는 이유만으로 모든 API가 기존 값을 유지한다고 가정해서도 안 된다.

실무 점검에서는 같은 항목의 네 입력을 별도로 넣고, 생성된 JSON뿐 아니라 합계·누락 표시·실제 전송 대상 필드까지 확인한다. 이는 작성자의 검증 제안이다. 이 글에서 해당 서비스에 갱신 요청을 보내거나 삭제 결과를 시험하지는 않았다.

전체 검증 순서는 JSON의 형식·근거·실행 권한 검사와 연결된다. 값이 존재해도 식별자가 달라지는 문제는 선행 0과 큰 정수 식별자 보존, 날짜에 없던 시각을 더하는 문제는 날짜와 시간대 변환 판단에서 다룬다.

자주 묻는 질문

모든 미확인 값을 null로 통일하면 되나요?

받는 쪽이 그 뜻을 동일하게 처리하고, 필요한 미확인 이유도 구별할 수 있다면 가능한 설계다. 그러나 해당 없음과 판독 실패를 다른 경로로 처리해야 하거나 null이 삭제를 뜻하는 API라면 그대로 넘길 수 없다. null이라는 표현보다 소비자의 계약을 먼저 확인한다.

사용자가 ‘빈 값은 0’이라고 정하면 바로 계산해도 되나요?

어떤 항목과 어떤 공란에 적용하는지 정하고 원문 확인 실패까지 포함하는지 구별해야 한다. 확인된 업무 규칙에 따른 변환임을 남기고, 원래 확인된 0과 규칙으로 채운 0을 재검토할 수 있게 한다.

숫자 0이 있는데도 누락 검사에 걸릴 수 있나요?

값의 참·거짓 변환만으로 존재를 검사하면 그럴 수 있다. 키가 있는지, 값이 null인지, 자료형과 범위가 맞는지를 나누어 검사하고 실제 0인 사례를 검증 자료에 포함한다. 특정 언어의 편의 표현을 업무 의미의 정의로 대신하지 않는다.