AI 응답을 JSON으로 받더라도 검증이 필요한 이유
AI가 유효한 JSON을 반환해도 업무 시스템에 바로 저장하면 안 됩니다. 키가 빠지거나 금액 단위가 틀리고, 형식은 맞지만 허용되지 않은 고객 ID가 들어갈 수 있습니다. 출력 형식 검증과 업무 규칙 검증은 별도 단계입니다.
문법과 스키마를 구분한다
JSON 파싱은 중괄호와 따옴표가 맞는지만 확인합니다. 필수 필드, 자료형, 허용 값, 중첩 구조, 추가 필드 허용 여부는 스키마로 검사해야 합니다. 스키마 버전도 저장해 오래된 결과를 재처리할 때 혼동을 줄입니다.
업무 규칙을 한 번 더 적용한다
수량이 정수형이어도 음수 주문은 거절해야 할 수 있습니다. 고객 ID가 존재하는지, 요청자가 그 고객을 볼 수 있는지, 날짜가 허용 기간인지 서버의 원천 데이터와 대조해야 합니다.
자동 수정은 제한한다
누락 필드를 모델에 다시 묻는 재시도는 가능하지만 조용히 기본값을 채우면 잘못된 계약이나 발주가 만들어질 수 있습니다. 수정 가능한 필드와 사람 확인이 필요한 필드를 분리합니다.
실패 결과도 관측한다
파싱 오류, 스키마 오류, 업무 규칙 위반을 다른 코드로 남깁니다. 모델·프롬프트 변경 뒤 어떤 오류가 늘었는지 보면 형식 강제 기능이 개선됐어도 실제 업무 품질이 나빠지는 상황을 찾을 수 있습니다.
쓰기는 마지막 단계에 둔다
검증을 통과한 결과라도 외부 API 호출과 DB 변경은 별도 권한으로 처리합니다. 원문 출력, 검증 결과, 승인 여부를 연결해 두면 사고가 났을 때 어디서 판단이 잘못됐는지 추적할 수 있습니다.
현장에 적용할 때의 순서
- 출력 스키마와 버전을 정의
- 원천 데이터·권한·업무 규칙 검증
- 승인 후에만 외부 시스템 변경
주의할 실패: 형식이 맞으면 업무상 안전하다고 판단
관찰할 지표: 스키마 실패율·업무 규칙 위반·수동 수정률
적용 전 체크리스트
- JSON 파싱·스키마·업무 규칙을 단계별로 검사한다
- 권한과 원천 데이터로 ID·금액·날짜를 대조한다
- 검증 실패를 조용히 기본값으로 덮지 않는다
참고 자료
JSON Schema — Understanding JSON Schema. 자료형·필수 필드 등 구조 검증 개념은 JSON Schema 공식 문서를 참고했습니다. 업무 규칙과 권한 검사는 별도 적용 제안입니다.
이미지와 도식은 이해를 돕기 위한 개념 시각화입니다. 특정 고객의 실제 설비·데이터·화면을 재현한 것이 아닙니다.
#AI응답 #JSONSchema #구조화출력 #데이터검증 #LLM운영 #업무자동화 #스키마 #접근권한 #품질관리 #AI안전
이 주제를 실제 시스템으로 옮기려면 AI 알고리즘 개발 살펴보기
