회의실 데모에서는 모델이 JSON을 잘 낸다. 운영에 올리면 다르다. 필드 하나가 빠지고, enum 값이 흔들리고, 날짜 형식이 섞인다. 더 큰 문제는 장애가 모델에서 끝나지 않는다는 점이다. 그 출력은 API 호출, DB 적재, 승인 화면, 알림 시스템으로 이어진다. 구조화 출력은 보기 좋은 JSON을 받는 기술이 아니다. 후속 시스템과 맺는 계약이다.
스키마는 프롬프트가 아니라 인터페이스다
“반드시 JSON으로 답하라”는 지시는 운영 장치가 아니다. JSON mode는 문법상 JSON을 만들게 할 수 있지만, 업무가 요구하는 필드·타입·enum·필수값을 보장하지 않는다. OpenAI 문서는 Structured Outputs를 JSON mode의 진화로 설명하며, JSON mode와 달리 스키마 준수를 보장한다고 구분한다. https://developers.openai.com/api/docs/guides/structured-outputs (platform.openai.com)
스키마는 모델에게 주는 요청서가 아니라 애플리케이션 인터페이스다. 그래서 업무 언어보다 시스템 언어로 써야 한다. “고객 의도”가 아니라 intent_type, “긴급함”이 아니라 urgency: low|medium|high다. 사람이 읽는 설명은 description에 넣고, 시스템이 판단하는 경계는 타입과 제약으로 둔다.
| 방식 | 운영에서의 의미 | 실패 양상 |
|---|---|---|
| 프롬프트 지시 | 모델에게 부탁 | 누락·형식 흔들림 |
| JSON mode | 파싱 가능한 JSON 확보 | 스키마 위반 잔존 |
| Structured Outputs | 필드·타입 계약 | 스키마 설계 품질이 병목 |
구조화 출력의 핵심은 모델을 믿는 것이 아니라, 모델이 통과해야 할 계약면을 좁히는 것이다.
검증은 후처리가 아니라 런타임 게이트다
스키마 강제가 있어도 검증은 별도로 둔다. 이유는 단순하다. 모델 제공자마다 지원하는 JSON Schema 범위가 다르고, 큰 스키마나 깊은 중첩은 제약을 받는다. Gemini 문서는 구조화 출력이 JSON Schema의 부분집합을 지원하며, 너무 크거나 깊은 스키마는 거절될 수 있다고 명시한다. https://ai.google.dev/gemini-api/docs/structured-output (ai.google.dev)
검증 계층은 세 가지를 나눠야 한다.
- 문법 검증: 파싱 가능한 JSON인가.
- 계약 검증: required, enum, type, pattern을 지켰는가.
- 업무 검증: 회사 정책, 권한, 금액 한도, 날짜 범위에 맞는가.
많은 팀이 1번에서 멈춘다. 운영 장애는 보통 2번과 3번에서 난다. “JSON은 맞는데 처리하면 안 되는 값”이 downstream을 오염시킨다. 검증 실패는 로그가 아니라 상태여야 한다. VALID, REPAIRABLE, REJECTED, NEEDS_HUMAN처럼 다음 행동을 정해야 한다.
자기수정 루프는 짧고 차갑게 설계한다
자기수정 루프는 모델에게 다시 생각하라고 말하는 장치가 아니다. 검증기가 반환한 오류 객체를 근거로, 복구 가능한 오류만 고치게 하는 장치다. Anthropic은 2025년 11월 Claude Developer Platform의 structured outputs를 발표했고, 2026년 2월 GA 업데이트에서 복잡한 스키마 지원을 확장했다고 밝혔다. 공식 문서는 현재 JSON 출력과 strict tool use를 별도 기능으로 제시한다. https://claude.com/blog/structured-outputs-on-the-claude-developer-platform, https://platform.claude.com/docs/en/build-with-claude/structured-outputs (claude.com)
루프는 이렇게 닫는다.
- 모델 출력 생성
- 스키마 검증
- 실패 시 오류 객체 생성
- 동일 스키마로 1회 수정 요청
- 재실패 시 사람 또는 안전한 fallback으로 전환
무제한 재시도는 비용 문제가 아니라 책임 문제다. 같은 오류를 반복하는 모델에게 더 많은 기회를 주면, 시스템은 조용히 느려지고 관찰 가능성은 흐려진다. 수정 루프의 입력에는 원문 전체보다 검증 오류, 실패 필드, 허용값, 기존 출력만 넣는다. 그래야 모델이 업무를 재해석하지 않고 계약 위반만 고친다.
도구 호출과 에이전트 연결에서는 출력 스키마가 더 중요해진다. MCP 2025-06-18 사양은 도구가 structuredContent와 outputSchema를 제공할 수 있고, 서버는 해당 스키마에 맞는 구조화 결과를 내야 하며 클라이언트는 검증해야 한다고 규정한다. https://modelcontextprotocol.io/specification/2025-06-18/server/tools (modelcontextprotocol.io)
참고는 운영 설계의 일부다
구조화 출력 강제는 모델 선택 항목이 아니다. 운영 설계 항목이다. 스키마는 인터페이스, 검증기는 게이트, 자기수정 루프는 제한된 복구 장치다. 이 세 가지가 함께 있어야 에이전트가 화면 밖 시스템으로 안전하게 연결된다.
참고:
- OpenAI, Structured model outputs, 2026 접근: https://developers.openai.com/api/docs/guides/structured-outputs
- Anthropic, Structured outputs on the Claude Developer Platform, 2025 발표·2026 GA 업데이트: https://claude.com/blog/structured-outputs-on-the-claude-developer-platform
- Anthropic, Claude API Structured outputs, 2026 접근: https://platform.claude.com/docs/en/build-with-claude/structured-outputs
- Google AI for Developers, Gemini API Structured outputs, 2026 접근: https://ai.google.dev/gemini-api/docs/structured-output
- Model Context Protocol, Tools specification 2025-06-18: https://modelcontextprotocol.io/specification/2025-06-18/server/tools
AX LABS는 이 설계를 프롬프트 가이드가 아니라 운영 계약으로 다룬다. 스키마·검증·수정 루프를 업무 흐름에 붙이는 방식은 AX Ops 방법론 →에서 이어진다.