스키마는 출력 형식을 정하는 계약입니다
Gemini의 구조화 출력 문서는 JSON Schema에 맞춰 응답 형식을 지정하는 방법을 제공합니다. 이는 프로그램이 결과를 읽기 쉽게 만드는 기능입니다. 하지만 숫자 필드에 값이 들어 있다는 사실만으로 그 숫자가 원문과 일치하거나 업무상 유효하다고 판단할 수는 없습니다.
가상의 발주서에서 수량과 단가를 추출한다고 생각해 보세요. 수량 10, 단가 5,000원과 합계 60,000원이 모두 숫자로 반환돼도 관계가 맞는지 확인해야 합니다. 세금이나 배송비가 포함됐는지 원문을 확인하지 않고 합계를 자동으로 고치는 것도 잘못된 처리입니다.
검증을 세 단계로 나눕니다
| 단계 | 검사 내용 | 실패 시 처리 |
|---|---|---|
| 형식 | 필수 필드·타입·허용된 상태값 | 원문과 오류 정보를 가지고 제한적으로 재요청 |
| 업무 규칙 | 수량 범위·통화·합계 관계 | 불일치 표시 후 검토 대기 |
| 사실 확인 | 문서 위치·품목 코드·거래처 | 근거 확인 또는 담당자 검수 |
모르는 값을 표현할 방법을 둡니다
날짜를 읽을 수 없는데 필수 문자열만 허용하면 모델이 그럴듯한 값을 채울 수 있습니다. 제공자가 지원하는 스키마 범위 안에서 확인 불가 상태나 빈 값을 표현하도록 설계하세요. 원문에 없는 값과 추출에 실패한 값을 구분하면 사용자가 어떤 정보를 보완해야 하는지 알 수 있습니다.
응답 거절, 길이 제한에 따른 중단, 네트워크 오류도 정상적인 출력과 다른 경로로 처리합니다. 부분적으로 도착한 JSON을 완성된 업무 데이터처럼 저장하지 마세요. 스트리밍을 사용하더라도 최종 상태와 검증이 끝난 뒤에 실제 변경을 실행하도록 연결합니다.
날짜 필드도 구체적으로 설계해 보세요. 원문의 '10/11'이 어느 해의 날짜이며 월·일 순서가 무엇인지 불명확할 수 있습니다. 정규화한 날짜와 원문 표현을 함께 남기고, 기준 시간대나 누락된 연도를 확인할 수 없으면 확정 값으로 저장하지 않습니다.
모델 출력이 실행 권한을 결정하지 않게 합니다
모델이 반환한 사용자 ID나 조직 ID를 그대로 신뢰해 데이터를 저장하면 다른 범위의 레코드가 바뀔 수 있습니다. 로그인 정보에서 확정한 권한과 서버의 기준 데이터로 다시 검사하세요. 모델이 만든 파일 경로, URL이나 명령 문자열도 별도의 입력 검증이 필요합니다.
연동 검수 체크리스트
- 선택한 모델과 API가 지원하는 스키마 범위를 확인했는가
- 확인 불가 값을 표현할 수 있는가
- 숫자·날짜·통화와 필드 간 관계를 검증하는가
- 거절·중단·파싱 실패에 대한 처리 경로가 있는가
- 검증 실패가 반복되면 자동 저장을 멈추고 검토로 넘기는가
참고 자료
자료 확인일: 2026.10.07 · 본문의 적용 예시와 체크리스트는 참고 자료를 바탕으로 정리한 실무 제안입니다.
기술 동작은 아래 공식 문서를 참고했습니다. 적용 조건과 지원 버전은 프로젝트 환경에 맞게 확인하세요.
작성팀 소개
TOPPING 기술팀 · 개발 · 아키텍처 · QA
웹·앱·백엔드·IoT·데이터 연동을 수행하는 TOPPING의 개발·아키텍처 담당 팀입니다. 시스템 구조 설계, 기술 검수, 인수인계와 운영 안정화를 담당합니다.





