GPT-6 Luna 구조화 출력: JSON 형식과 추출 내용 검증하기

GPT-6 Luna는 구조화 출력을 지원하지만, JSON 형식이 맞는다고 추출값이 원문에 부합하는 것은 아닙니다. 이 글은 고객 문의에서 데이터를 추출하는 개발자를 위해 세 필드의 출력 규칙, 요청 예제와 로컬 검증 코드를 제공합니다. 유료 API 평가 전에 결과를 어떻게 판정할지 확인할 수 있습니다.

2026년 9월 24일 Luna 문서와 구조화 출력 가이드를 확인했습니다. 데이터와 기대 답안은 미리 작성한 합성 교육 자료입니다. 실행한 것은 검증기와 응답 파서이며, Luna의 정확도나 지연 시간을 측정하지 않았습니다.

스키마보다 분류 기준부터 정하기

교육용 문의는 중복 청구, 로그인 실패, 화면 색상 변경, 스키마를 무시하라는 지시가 섞인 알림 등 네 건입니다. 문의 안의 지시는 분석 대상 데이터이며 애플리케이션이 따라야 할 명령이 아닙니다.

category, order_id, evidence를 반환합니다. 분류는 billing, access, other 중 하나이고 주문 번호가 없으면 null, 근거는 원문에서 그대로 복사한 짧은 구절입니다. 이 연습에서는 도움을 요청하지 않은 배송 알림을 other로 봅니다. 실제 지원팀에 배송 분류가 있다면 기준을 다시 정의해야 합니다.

원문과 결과를 함께 보관해야 검토자가 담당 팀을 선택한 이유를 확인할 수 있습니다. 올바른 분류를 얻는 것과 환불이나 계정 변경을 실행할 권한이 있는 것도 별개입니다.

완전한 Responses 요청 구성하기

실습 ZIP의 request.json을 엽니다. 정확한 ID gpt-6-luna와 명시적인 reasoning.effort: none을 사용합니다. 재현 가능한 시작 설정이지 모든 추출 작업에 가장 적합하다고 증명한 값은 아닙니다.

출력 설정의 위치는 다음과 같습니다. 위치를 설명하는 조각이며, 그대로 실행할 수 있는 완전한 요청이나 스키마가 아닙니다.

"text": {
  "format": {
    "type": "json_schema",
    "name": "ticket",
    "strict": true,
    "schema": {"...": "use the complete schema.json in the lab"}
  }
}

출력 형식은 text.format에 json_schema로 지정하고 strict: true를 설정합니다. 세 필드가 모두 필수이며 주문 번호는 문자열 또는 null, additionalProperties는 false입니다. developer 메시지에 처리 규칙을 두고 user 메시지에는 문의 데이터를 넣습니다.

전체 요청과 전체 스키마를 사용하세요. 생략 부호가 들어간 설명용 조각은 실행 가능한 스키마가 아닙니다. 실제 전송에는 권한이 있는 API 계정을 사용해야 하며 비용이 생길 수 있습니다. 이 글에서는 전송하지 않았습니다. 프로토콜 차이는 Sol/Luna 이전 가이드에서 확인할 수 있습니다.

통신, 형식, 업무 의미를 따로 검사하기

HTTP 성공 이후에도 완료 상태와 거부 여부를 먼저 확인합니다. 실습의 extract_text는 메시지 내용을 순회하며 output 첫 항목에 답이 있다고 가정하지 않습니다. 합성 미완료·거부 응답에는 접수할 본문을 반환하지 않습니다.

validate는 좁은 교육용 조건을 검사하며 범용 JSON Schema 엔진이 아닙니다. 원문에 주문 번호가 있어도 null을 허용하므로 누락 여부는 추가 업무 규칙으로 확인해야 합니다. 파서도 공식 응답 구조를 전제로 하며 임의의 손상된 JSON을 모두 처리하지 않습니다.

실서비스에서는 JSON 파서, 유지 관리되는 스키마 검증 라이브러리, 업무 규칙을 차례로 적용합니다. 인증, 시간 초과, 호출 제한, 저장과 재시도는 API 클라이언트의 책임입니다.

로컬 테스트와 반례 확인하기

압축을 푼 디렉터리에서 실행합니다.

python3 lab.py test

Python 3만 필요하며 추가 의존성이나 네트워크 호출은 없습니다. 11개 단언은 없는 주문 번호, 지어낸 인용문, 추가 키, 미완료 응답과 거부 등을 확인합니다.

의도적인 반례는 중복 청구 문의의 분류를 access로 바꾸고 실제 인용문을 유지합니다. 구조와 문자 그대로의 근거 검사는 통과하지만 준비된 기대 분류와 다릅니다. 11개 단언 통과는 검증 코드의 결과이지 Luna가 11문제를 맞힌 성적이 아닙니다.

실제 평가에서는 실패도 남기기

누락 ID, 중복, 모순, 여러 언어, 모호한 사례를 포함해 독립 라벨을 붙인 표본을 준비합니다. 개발용과 보류 평가용을 나누고, 모호한 정답은 두 번째 검토자와 합의합니다.

모델 ID, 공급자, effort, 요청 ID, 상태, 원응답, 사용량과 최종 판정을 저장합니다. 형식 통과, 분류 정답, 근거 있는 ID, 근거 없는 주장, 거부와 미해결을 따로 집계합니다. 재시도에 성공해도 첫 실패는 분모와 비용에 남아야 합니다.

결과를 보기 전에 합격 기준을 정합니다. 청구 문의를 잘못 분류하는 비용이 크면 평균값 안에 숨기지 말고 분류별·언어별로 확인하세요. Luna 요금 설명은 비용 해석을, Luna에서 Sol로 넘기는 흐름은 추가 검토 설계를 돕습니다.