업무용 AI JSON 계약: 추가 키·불리언·근거 문장을 검증하는 여섯 문의
JSON이 파싱된다는 사실만으로 업무 결과를 사용할 수는 없습니다. 문의 ID가 두 번 나오거나, 우선순위 숫자 자리에 true가 들어가거나, 원문에 없는 근거를 적어도 겉모양은 JSON일 수 있습니다. 여섯 가상 문의의 계약을 작게 정하고 각각의 실패를 별도로 검산해 보겠습니다.
이 글은 API 호출 예제나 실제 모델 성능 평가가 아닙니다. 출력 계약과 기대 JSON을 직접 작성했으며, 첨부 Python은 로컬 파일만 읽습니다. 실제 키·계정·고객 문장은 필요하지 않습니다.
여섯 문의에만 적용할 정책
| ID | 원문 핵심 문자열 | category | priority | needs_followup |
|---|---|---|---|---|
| J901 | 중복 결제 | billing | 1 | false |
| J902 | 로그인 불가 | account | 2 | false |
| J903 | 도와주세요 | other | 3 | true |
| J904 | 영수증 재발급 | billing | 2 | false |
| J905 | 계정 정보 | account | 2 | true |
| J906 | 화면 색상 | other | 3 | false |
fixture.json의 실제 문장은 각 핵심 문자열 뒤에 ‘ 문의입니다.’를 붙인 값입니다. 이 정책은 연습용이며 일반적인 고객지원 우선순위 표준이 아닙니다. 한 문장에 여러 문제가 섞이거나 이 표 밖의 문장이 오면 자동 승인하지 않습니다.
여섯 키와 자료형을 닫아 두기
각 행은 id, category, priority, needs_followup, evidence, reason의 여섯 키만 갖습니다. priority는 정수 1·2·3, needs_followup은 JSON 불리언이어야 합니다. ‘1’이라는 문자열이나 숫자 1을 불리언 대신 넣지 않습니다.
{
"id": "J901",
"category": "billing",
"priority": 1,
"needs_followup": false,
"evidence": "중복 결제",
"reason": "고정 예제 정책과 일치"
}이 객체 여섯 개가 원문 순서의 배열로 반환되어야 합니다. reason도 이 고정 예제의 비교를 단순하게 하려고 문구를 정했습니다. 다른 유효한 설명까지 오답이라고 일반화하지 않습니다.
fixture.json의 여섯 문의를 명시된 정책으로만 변환한다.
각 항목은 id, category, priority, needs_followup, evidence, reason만 쓴다.
ID 순서와 개수를 유지하며 evidence는 해당 원문의 핵심 문자열을 복사한다.
reason은 '고정 예제 정책과 일치'로 쓴다.
모르는 값은 추정하지 말고 처리 중단 사유를 별도 확인한다.
JSON 배열 앞뒤 설명, 코드 울타리, 추가 키를 넣지 않는다.OpenAI의 Structured Outputs 안내는 지정한 JSON Schema에 맞는 응답 형식을 다룹니다. 여기서 작성한 검산기는 그 API 기능을 호출하거나 일반 JSON Schema 전체를 구현한 도구가 아닙니다. 형식 계약과 이 여섯 문의의 고정 정답을 직접 검사합니다.
파서 다음에 검사할 네 가지
첫째, 배열 길이와 ID를 확인합니다. J901이 두 번 있으면 여섯 행이라는 숫자는 맞아도 문의 한 건이 누락됩니다. 둘째, 키 집합과 자료형을 확인합니다. Python에서 bool이 int와 관계가 있다는 이유로 true를 우선순위 1처럼 받지 않도록 type(value) is int로 검사합니다.
셋째, evidence가 비어 있지 않고 해당 ID 원문에 실제 포함되는지 확인합니다. ‘익일 환불’은 J901 원문에 없으므로 거절합니다. 넷째, 전체 결과를 이 예제의 명시 정책으로 정한 expected.json과 대조합니다. 원문에 포함된 흔한 단어를 복사했다는 이유만으로 올바른 분류라고 인정하지 않습니다.
실습 순서: JSON 입력과 예상 출력 확인
-
ZIP 전체를 빈 폴더에 풀고 원본을 복사합니다. Python 환경을 준비하며 실제 검증 환경은 README에 기록했습니다. 외부 패키지는 설치하지 않습니다.
-
python3 verify.py를 실행합니다. 기본 정답이 맞고 반례 7건이 모두 거절되어야 합니다. -
실제 모델 답이 있다면 손으로 수정하지 않고 response.json으로 저장합니다.
python3 verify.py response.json을 실행합니다. -
기본 파일을 연습할 때는 expected.json의 사본에서 값을 한 개만 변경합니다. 원래 정답 파일은 보존합니다.
자료형·근거·ID 오류의 복구 절차
| 변경한 입력 | 기대 오류 | 복구 방법 |
|---|---|---|
| J901 priority를 true로 변경 | TYPE | 숫자 1과 불리언의 역할을 확인하고 사본을 원래 값으로 복구 |
| needs_followup을 숫자 1로 변경 | TYPE | 정책의 false/true 자료형으로 복구 |
| evidence를 익일 환불로 변경 | EVIDENCE | 해당 ID 원문에서 근거 문자열을 다시 확인 |
| 두 번째 ID를 J901로 변경 | DUPLICATE_ID | 원본 순서와 J902를 확인하고 중복을 제거 |
| unexpected 키 추가 | KEYS | 형식 계약을 확인하고 새 요청의 출력 조건을 명시 |
XLSX JSON정답 시트는 정책 참조표입니다. B15:D15의 분류 수 2·2·2는 COUNTIF의 계산 결과이며 JSON 검증 결과가 아닙니다. 셀을 입력했다고 서비스 요청이 전송되거나 담당자가 승인한 것은 아닙니다.
파싱 실패를 자동으로 덮지 않기
여는 코드 울타리나 설명문 때문에 JSON 파싱이 실패하면 원본 응답과 실패를 보존합니다. 따옴표·쉼표를 무작위로 고쳐 의미가 달라진 출력을 ‘모델 성공’으로 기록하지 않습니다. 필요하면 명시한 계약으로 새 응답을 요청하고 회차를 구분합니다.
본문의 검산기는 출력이 불일치하면 종료 코드 1을 반환하며 네트워크 재시도나 업무 처리 기능이 없습니다. 실패 출력을 결제 취소·메일 전송·파일 덮어쓰기에 연결하지 않습니다.
여섯 문의 검산기의 한계와 다른 업무의 조건
실제 업무에서는 새 분류·다중 이슈·불명확한 문의·거절 응답의 정책을 정해야 합니다. 그다음 원문과 독립적인 기대 결과를 만들고 부정 입력을 늘립니다. 이 예제의 완전 일치는 자료형과 고정 기대값을 지켰다는 뜻이며 보안 승인이나 자연어 의미 전체를 검증했다는 뜻이 아닙니다.
판정 기준과 실제 처리 권한은 분리합니다. reason 문자열을 그럴듯하게 만들거나 점수를 높이는 대신, 입력 사본·원본 출력·오류·사람이 승인한 값을 따로 보관하면 실패 원인을 다시 확인할 수 있습니다.
출처 원문 수집일: S1 2026-09-24.
작성자 소개
