Amazon Bedrock, Claude 전 모델에 구조화 출력 정식 지원

Amazon Bedrock이 Anthropic의 Claude 모든 모델에서 구조화 출력을 지원한다. bedrock-runtime과 bedrock-mantle 두 엔드포인트 모두에서, 해당 모델을 제공하는 곳이면 쓸 수 있다. AWS는 이 기능이 정식 출시(generally available) 상태라고 밝혔다.

개발자는 Boto3와 bedrock-runtime API로 Claude를 부르든, Messages API와 bedrock-mantle 엔드포인트를 쓰든 정해 둔 구조에 맞는 JSON 응답을 받는다. AWS는 별도의 파싱 코드, 재시도 로직, 후처리가 필요 없어진다고 설명했다.

제약 디코딩으로 스키마를 강제한다

구조화 출력은 제약 디코딩(constrained decoding)으로 JSON Schema를 토큰 생성 단계에서 강제한다. 생성이 끝난 뒤 검사하는 방식이 아니며, 모델은 스키마를 어기는 토큰을 만들지 않는다. AWS는 이로써 출력 형식이 확률적인 것에서 결정적인 것으로 바뀐다고 설명했다.

두 엔드포인트에서 쓸 수 있는 방식은 둘이다. JSON Schema 출력 형식은 응답 구조를 제어하며 데이터 추출, 보고서 생성, API 응답에 맞는다. 엄격한 도구 사용(strict tool use)은 도구 인자를 스키마로 검증하며 에이전트 워크플로, 함수 호출, 다단계 자동화에 쓴다.

AWS가 꼽은 효과는 이렇다. 응답은 유효한 JSON이어서 JSON.parse() 오류나 파싱 예외가 생기지 않는다. 필드 타입이 강제되고 필수 필드가 빠지지 않으며, 스키마 위반을 처리하려고 재시도할 필요도 없다. 다만 모델이 안전상 이유로 거절하거나 완성하기 전에 max_tokens에 닿으면 스키마에 맞지 않는 응답이 나올 수 있다. 스키마에 정의한 필드만 출력하므로 출력 토큰이 줄어, 대량 처리에서는 추론 비용이 낮아질 수 있다고 AWS는 밝혔다.

배치 추론에서도 작동해 대량 요청을 비동기로 처리하면서 스키마에 맞는 출력을 받는다. bedrock-runtime에서는 교차 리전 추론도 추가 설정 없이 쓸 수 있고, 실시간 응답이 필요하면 구조화된 응답을 타입이 있는 이벤트로 스트리밍할 수 있다.

처리 순서와 성능

요청이 들어오면 Bedrock은 먼저 스키마가 JSON Schema Draft 2020-12의 지원 부분집합에 맞는지 검증한다. 새 스키마는 문법 아티팩트로 컴파일하고, 컴파일된 문법은 24시간 캐시한 뒤, 모델이 스키마에 맞는 JSON을 생성한다.

새 스키마의 첫 요청은 컴파일 때문에 조금 더 걸릴 수 있다. 이후 같은 스키마를 쓰는 요청은 추가 부담이 거의 없다. 캐시는 계정 단위이고 처음 접근한 시점부터 24시간 유지된다. 스키마 구조를 바꾸면 캐시가 무효가 되어 다시 컴파일하지만, 이름이나 설명(description)만 바꾸면 캐시된 문법이 그대로 쓰인다.

사용법과 활용 사례

InvokeModel API는 Anthropic 고유 형식의 요청 본문을 받는다. 스키마는 JSON 문자열이 아니라 JSON 객체로 output_config.format에 넣는다. AWS 예제는 Python과 boto3로 고객 이메일에서 이름, 이메일, 관심 요금제, 데모 요청 여부를 뽑아 스키마에 맞는 결과를 받는다.

bedrock-mantle은 서버 측 도구, 백그라운드 추론, 상태가 있는 대화를 쓰는 에이전트 애플리케이션용이다. 도구 정의에 strict: true를 지정하면 도구 입력이 스키마와 정확히 일치한다. 예제의 날씨 도구에서 location은 항상 문자열이고 unit은 항상 celsius나 fahrenheit이며, 스키마에 없는 필드는 추가되지 않는다. AWS는 웹 검색이나 코드 인터프리터 같은 서버 측 도구로 다단계 작업을 조율하는 경우에 특히 유용하다고 밝혔다.

AWS가 제시한 활용 사례는 다음과 같다. 재무 실적 보고서와 컴플라이언스 문서에서 필수 항목을 모두 추출하기, 진료 기록을 전자건강기록(EHR)으로 변환하기, 상품 카탈로그 보강하기, 계약서의 핵심 조건·당사자·의무 분석하기, 의도·감정·개체가 애플리케이션 데이터 모델과 맞는 지원 티켓 분류하기. 오류 처리 부담이 가장 크게 주는 패턴으로는 송장·계약서·이메일·녹취록에서 DB나 CRM에 바로 넣을 수 있는 데이터 추출, 생성 시점에 인자를 검증하는 에이전트 도구 호출, 대량 분류를 들었다.

분류 예제는 Claude Haiku 5.5를 쓴다. AWS는 Haiku 5.5가 요약, 압축, 데이터베이스 질의, 분류처럼 빠르고 반복적인 작업을 안정적으로 처리한다고 설명했다. 예제에서는 지원 티켓을 category, priority, sentiment, escalate, reason 필드로 분류하며, enum으로 레이블을 고정한다. escalate는 사람이 즉시 검토해야 하는지를 나타내는 값이고, true이면 예제 코드가 당직(on-call) 에스컬레이션 메시지를 출력한다.

요구 사항과 지원하지 않는 기능

• 모든 객체에 additionalProperties: false를 지정해야 한다. 없으면 스키마가 받아들여지지 않는다.
• customer_email처럼 의미가 분명한 필드 이름과 설명을 쓴다. 모델이 이를 보고 추출할 데이터를 판단하며, field1 같은 이름보다 낫다고 AWS는 밝혔다.
• 값이 제한되면 enum을 쓰고, 필수 필드만 둔 단순한 스키마에서 시작해 늘려 간다. 단순한 스키마는 컴파일이 빠르고 디버깅이 쉽다. 스키마가 Converse API 페이로드 크기에 포함되므로, 스키마를 단순하게 유지해야 요청 페이로드도 가볍게 유지된다.
• 24시간 캐시를 활용하도록 스키마를 요청마다 재사용한다.
• 응답마다 stop reason을 확인한다. 모델이 안전상 이유로 거절하거나, 완성 전에 max_tokens에 닿으면 스키마에 맞지 않는 응답이 나올 수 있다.
• 배포 전에 실제 운영 데이터와 비슷한 입력으로 스키마를 시험한다.

지원하는 JSON Schema 기능은 object, array, string, integer, number, boolean, null 기본 타입, enum(문자열·숫자·불리언·null만), const, anyOf, allOf(제한 있음), 내부 참조에 한정한 $ref·$def·definitions, date-time·time·date·duration·email·hostname·uri·ipv4·ipv6·uuid 문자열 형식, 값이 0과 1인 minItems다.

재귀 스키마, 외부 $ref, 숫자 제약(minimum, maximum, multipleOf), 문자열 제약(minLength, maxLength), false 외의 additionalProperties는 API가 받아들이지만 생성 중에는 강제하지 않는다. 이런 키워드를 넣어도 요청은 성공하고, 모델이 제약을 어기는 값을 낼 수 있다. AWS는 이 제약을 스키마에 맡기지 말고 애플리케이션에서 검증하라고 안내했다.

개발자는 Amazon Bedrock 문서와 AWS가 제공한 샘플 노트북에서 Messages API 등 추가 예제와 스키마 설계 권장 사항을 볼 수 있다.