원문 정보
- 제목: Structured outputs on the Claude Developer Platform
- 링크: claude.com/blog/structured-outputs-on-the-claude-developer-platform
- 발행: 2025년 11월 14일 (2026년 2월 4일 GA)
- 카테고리: Claude Platform
글의 요지
Structured Outputs 공식 출시. JSON 스키마나 도구 정의에 응답이 완벽히 일치하도록 보장하는 기능. Sonnet 4.5, Opus 4.1 우선 지원, 이후 Haiku 4.5도 추가. 베타 헤더 structured-outputs-2025-11-13.
풀려는 문제
LLM 사용 시 흔한 함정:
- 잘못된 JSON 응답 (파싱 실패)
- 필드 이름 불일치
- 누락된 필드
- 타입 불일치 (number → string)
- 멀티스텝 워크플로 깨짐이전 해결책 (불완전):
- 프롬프트로 요청 ("please return valid JSON")
- 재시도 로직
- 정규표현식 파싱
- Tool use 우회
기술적 작동 원리 — Constrained Decoding
핵심 통찰:
"Unlike prompting the model to 'please return valid JSON,' structured outputs compile your JSON schema into a grammar and actively restrict token generation during inference. The model literally cannot produce tokens that would violate your schema."
번역: 단순 "JSON 반환해주세요" 가 아니라, 스키마를 grammar로 컴파일 → 인퍼런스 중 유효 토큰만 생성.
비유: 계약자에게 "예산 내 시도해주세요" (요청) vs 승인된 금액 이상 자금 접근 물리적 차단 (강제).
스키마 캐싱
- 첫 요청 시 스키마 컴파일
- 24시간 캐시
- 같은 스키마 재사용 시 빠름
Python 예시
from pydantic import BaseModel
from anthropic import Anthropic
class ContactInfo(BaseModel):
name: str
email: str
plan_interest: str
demo_requested: bool
client = Anthropic()
response = client.messages.parse(
model="claude-opus-4-7",
max_tokens=1024,
messages=[{
"role": "user",
"content": "Extract from email: John Smith (john@acme.com)..."
}],
output_format=ContactInfo,
)
print(response.parsed_output)TypeScript (Zod)
import { anthropic } from "@ai-sdk/anthropic";
import { generateObject } from "ai";
import { z } from "zod";
const { object } = await generateObject({
model: anthropic("claude-opus-4-20250514"),
prompt: "Extract ingredients for vegetarian lasagna recipe",
schema: z.object({
ingredients: z.array(z.string()),
prepTime: z.number(),
difficulty: z.enum(["easy", "medium", "hard"]),
}),
});두 가지 모드
1) JSON Outputs:
- 스키마에 맞는 JSON 객체 반환
- 데이터 추출, 응답 포맷팅
2) Strict Tool Use:
- 도구 호출 시 입력 파라미터 검증
- 도구 실행 실패 0
OpenRouter (Chris Clark, COO) 인용
"Structured outputs have become a really valuable part of the agentic AI stack. Agents constantly ingest and produce structured data, so Anthropic's structured outputs close a real gap for developers. Agent workflows run reliably, every time, and teams can focus on their customers rather than debugging tool calls."
번역: 에이전트는 끊임없이 구조화된 데이터를 받고 생성. structured outputs가 진짜 갭을 메움. 에이전트 워크플로 안정적, 팀이 고객에 집중 가능.
GA 일정
- 2025년 11월 14일: Public beta
- 2025년 12월 4일: Haiku 4.5 추가, Microsoft Foundry 지원
- 2026년 2월 4일: GA (Sonnet 4.5, Opus 4.5, Haiku 4.5)
2026년에 다시 읽으며 — 내가 본 것
1. "OpenAI 추격" 패턴
이 출시가 흥미로운 이유 — OpenAI는 1년 전에 같은 기능 출시.
타임라인:
- 2024년 8월: OpenAI Structured Outputs 출시
- 2024년 후반: Google Gemini 같은 기능
- 2025년 11월 (이 글): Anthropic 마지막 채택
이게 "Anthropic이 OpenAI 따라잡기" 의 명확한 사례다.
Tessl 인용:
"It's catch-up with OpenAI"
이전 Anthropic 패턴:
- 자기 표준 만들고 따라오게 함 (MCP, Skills)
- 모델 능력 우선
이 글의 패턴:
- 시장에서 검증된 기능 채택
- 개발자 페인 포인트 해결
이 변화가 "성숙한 enterprise AI 플랫폼" 으로 진화 신호. 모든 표준 자기가 만들 수 없음. 일부는 따라가는 게 합리적.
2. "Tool Use와 같지 않나?"의 명확한 답
Reddit·Hacker News에서 자주 나온 질문:
"Tool use로 이미 구조화 강제하는데 뭐가 달라?"
답:
- Tool use: 모델이 "도구 호출하기로 결정" 시 구조화. 그러나 모델이 도구 호출 안 할 수도.
- Structured Outputs: 모든 응답이 강제로 구조화. 모델 "선택" 의 영역 아님.
비유:
- Tool use = "계약서 양식 권장"
- Structured Outputs = 계약서 양식 강제, 다른 형식 작성 불가능
특히 JSON outputs 는 도구 호출 의도 없이 데이터 추출만 하는 워크플로에서 결정적이다. "이 이메일 분석" → 항상 같은 스키마 JSON.
3. "Constrained Decoding"의 기술적 우아함
Thomas Wiegold 인용:
"Compile your JSON schema into a grammar and actively restrict token generation during inference."
이게 진짜 우아한 기술 솔루션이다.
전통적 접근 (불완전):
- 모델이 자유롭게 출력
- 사후 검증 (validation)
- 실패 시 재시도
Constrained Decoding:
- 매 토큰 생성 시 유효 토큰만 후보
- 잘못된 토큰 "수학적으로 불가능"
- 출력 = 보장된 유효
이게 결정론적 LLM 출력 의 진짜 시작이다. 이전엔 "확률적, 운에 맡김". 이제는 수학적 보장.
4. "다양한 SDK 지원"의 enterprise 친화성
본문이 강조한 SDK 지원:
- Python: Pydantic +
messages.parse() - TypeScript: Zod + Vercel AI SDK
- Ruby: BaseModel
- PHP: StructuredOutputModel
- CLI, C#, Go: Raw JSON schema
이 폭넓은 지원이 enterprise 친화성 시그널. 기업 코드베이스가 다양한 언어 — 하나라도 지원 빠지면 도입 어려움.
OpenAI는 출시 시 Python·TypeScript만. Anthropic은 6개 언어 동시. enterprise-first 전략의 디테일.
5. "데이터 추출의 진짜 ROI"
본문이 든 사례 — 이메일 정보 추출:
Input: "John Smith (john@acme.com) is interested in
our Enterprise plan and wants to schedule a
demo for next Tuesday at 2pm."
Output:
{
"name": "John Smith",
"email": "john@acme.com",
"plan_interest": "Enterprise",
"demo_requested": true
}이게 사소해 보이지만 B2B SaaS의 거대 시장이다:
기존 워크플로:
- 영업 직원이 이메일 읽고 CRM 입력
- 한 이메일당 5-10분
- 100개 이메일/일 = 8시간
AI 자동화 후:
- LLM이 자동 추출
- 100개 이메일 = 5분
- 영업 직원은 고객 대화에 집중
이런 자동화가 100% 신뢰 가능하려면 structured outputs 가 필수. "가끔 JSON 깨짐" 이면 자동화 불가능.
6. "Haiku 4.5 지원의 의미"
본문이 강조 — Haiku 4.5 지원이 "notable".
이유:
- Haiku = 가장 빠르고 저렴한 모델
- 고볼륨 작업 (분류, 추출, 라우팅)
- 비용 민감 use case에 사용
이런 작업에 structured outputs 필수:
- 100만 이메일 분석 = Haiku 사용
- 단 0.1% 깨진 JSON = 1,000 실패
- 재시도 비용 + 실패 케이스 운영 부담
Haiku 지원이 "production-grade" 시그널. 모든 모델 티어에서 동일 보장.
7. "AI = Deterministic Software" 의 시대
Hands-On Guide 인용:
"By enforcing strict JSON schemas, we can now treat Large Language Models less like chatbots and more like deterministic software components."
번역: 엄격한 JSON 스키마 강제로, LLM을 챗봇이 아니라 결정론적 소프트웨어 컴포넌트로 다룰 수 있음.
이 변화가 깊다:
LLM as Chatbot (이전):
- 응답 매번 다름
- "마술 같은" 출력
- production 사용 어려움
LLM as Component (지금):
- 같은 입력 → 같은 형식 출력
- 다른 시스템과 결합 신뢰
- production 인프라
이게 AI가 소프트웨어 인프라 표준 부분이 되는 진화다. "AI를 가끔 사용" → "AI가 모든 워크플로 포함".
마무리
이 글은 "또 하나의 API 기능 추가" 같지만, 실제로는 AI가 production 인프라가 되는 결정적 단계다.
- Constrained Decoding: 수학적 보장의 우아한 기술
- OpenAI 추격: 모든 표준 만들 수 없음, 따라가는 것도 합리
- Tool Use와의 명확한 차이: 도구 호출 X, 모든 응답 구조화
- 6개 SDK 지원: enterprise 친화성
- Haiku 4.5 포함: 모든 티어 동일 보장
- AI as deterministic component: 인프라 신뢰성
2025년 11월 시점은 "AI 출력 신뢰 못함" 이라는 1년간의 페인 포인트가 해결된 시기다. "가끔 깨진 JSON" 이 "수학적으로 불가능" 이 됨.
이 변화의 함의가 크다 — 자동화의 새 단계. 이전엔 "AI가 잘못해도 사람이 검토" 가 안전망. 이제는 자동화 워크플로 신뢰 가능.
흥미로운 건 이 기능이 별로 "섹시" 하지 않다는 점이다. 새 모델, 새 능력, 새 인터페이스 같은 화려한 발표 X. 그러나 production AI 시스템에는 이런 신뢰성 기능이 결정적이다. CIO가 "이 시스템 우리 핵심 워크플로에 둬도 되나?" 결정 시 모델 능력보다 "보장된 출력 형식" 이 더 중요. Anthropic이 그 신호를 정확히 줬다.
