LLM이 요청한 JSON 모양으로 답해도 곧바로 데이터베이스에 저장하면 위험합니다. 필드 이름이 맞는 것과 값이 업무 규칙에 맞는 것은 다른 문제입니다. 구조 검증과 의미 검증을 분리해야 자동화가 안전해집니다.
문법이 맞아도 값은 틀릴 수 있다
JSON 파싱 성공은 괄호와 따옴표가 맞다는 뜻일 뿐입니다. 날짜 형식, 통화 단위, 필수 필드, 허용 열거값을 스키마로 검사합니다. 숫자처럼 보이는 문자열과 실제 숫자를 혼용하면 후속 계산에서 문제가 생깁니다.
업무 불변식을 별도로 검사한다
주문 총액은 품목 합계와 맞아야 하고 종료일은 시작일보다 앞설 수 없습니다. 이런 관계는 일반적인 필드 타입 검사만으로 충분하지 않습니다. 원본 문서와 외부 시스템의 기준값을 대조해 의미 오류를 찾아야 합니다.
모델의 설명과 데이터 필드를 구분한다
모델이 추측한 필드를 확정값처럼 채우면 누락이 숨겨집니다. 확인되지 않은 값은 null이나 별도 상태로 남기고 근거 위치를 함께 저장합니다. 저장 API는 근거 없는 필수값을 거부하거나 사람 검수 대기열로 보냅니다.
실패 시 자동 수정 범위를 제한한다
검증 오류가 나면 모델에 재요청할 수 있지만 무한 반복하면 비용과 지연이 커집니다. 형식 오류는 제한된 재시도로 고치고, 금액 불일치나 권한 문제는 사람 확인으로 넘깁니다. 모델이 자기 출력을 스스로 맞다고 주장해도 검증 기준은 바뀌지 않습니다.
계약 변경을 버전으로 다룬다
새 필드를 추가하거나 허용값을 바꾸면 기존 소비 시스템이 깨질 수 있습니다. 스키마 버전, 하위 호환 규칙, 오래된 입력의 처리 방식을 정합니다. 테스트에는 정상 예시뿐 아니라 누락·형식 오류·모순 사례를 넣습니다.
현장에 적용할 때의 순서
- 필드 타입·필수값 검증
- 원본·업무 불변식 대조
- 오류별 재시도·검수 분기
주의할 실패: JSON 파싱 성공을 업무 성공으로 간주
관찰할 지표: 검증 실패율과 오통과율
적용 전 체크리스트
- JSON 파싱과 스키마 검증을 분리하는가
- 필드 간 업무 불변식을 검사하는가
- 검증 실패의 재시도·사람 확인 경로가 있는가
참고 자료
JSON Schema documentation. 데이터 구조와 제약 검증의 기본 개념을 참고했습니다. LLM 출력의 업무 의미 검증은 별도로 설계해야 합니다.
이미지와 도식은 이해를 돕기 위한 개념 시각화입니다. 특정 고객의 실제 설비·데이터·화면을 재현한 것이 아닙니다.
#LLM #JSON검증 #스키마 #데이터계약 #생성형AI #업무자동화 #입력검증 #AI안전성 #백엔드 #구조화출력
