블로그 • AWS / Bedrock

Amazon Bedrock의 Claude 구조화 출력이 JSON 형태를 보장하는데, 배치 로그와 복사한 채팅에는 왜 로컬 3단계 검사가 필요한가?

2026년 10월 19일 AWS는 Bedrock의 Claude 구조화 출력을 발표했다. 추론 시 JSON Schema로 제한 디코딩, output_config로 schema, strict 도구, additionalProperties:false. 배치와 스트리밍 포함.

Structured Output 비교는 2026 구조화 출력 가이드. schema가 맞아도 권한은 별개, Agent schema 부족 글. JSON Schema 공용은 AI가 JSON Schema가 필요한 이유. 이 글은 Bedrock 이후 로컬 3단계만 다룬다.

• Bedrock 요청은 output_config.format에 JSON Schema와 additionalProperties:false를 넣는다.
• API는 한 번의 Invoke 응답 형태만 보장하며, 로그·배치·콘솔 복사는 아니다.
• 로컬: (1) JSON Schema 검증, (2) markdown fence 제거 후 JSON repair, (3) 배치 JSONL 행 검사.
• 같은 TICKET_SCHEMA로 API 샘플·로그·배치 행을 검증해 enum 오류·누락·추가 키를 막는다.

10월 19일 Bedrock이 Claude에 무엇을 추가했나?

AWS는 공식 What's New: Bedrock Claude 구조화 출력, 제한 디코딩, strict 도구, 배치·스트리밍.

기술 세부는 AWS Machine Learning 블로그. API 보장을 로그 파이프라인의 끝으로 보지 않는다.

output_config에 JSON Schema를 어떻게 붙이나?

Bedrock 요청은 output_config.format.type을 json_schema로 하고 schema에 객체 정의를 넣는다. 루트에 additionalProperties:false. 예시는 ticket_id, priority(enum), summary.

{
  "anthropic_version": "bedrock-2023-05-31",
  "max_tokens": 1024,
  "messages": [
    {
      "role": "user",
      "content": "Return one support ticket as JSON."
    }
  ],
  "output_config": {
    "format": {
      "type": "json_schema",
      "schema": {
        "type": "object",
        "additionalProperties": false,
        "required": ["ticket_id", "priority", "summary"],
        "properties": {
          "ticket_id": { "type": "string" },
          "priority": { "enum": ["low", "medium", "high"] },
          "summary": { "type": "string", "maxLength": 200 }
        }
      }
    }
  }
}

배치는 JSONL로 한 줄 한 레코드. 스트리밍은 클라이언트에서 이어 붙여 티켓에 붙여넣기 된다. Bedrock 디코더가 다시 검증하지 않는다.

API가 형태를 보장하는데 왜 로컬 검증?

Invoke 응답은 Bedrock에서 schema 형태지만 저장물은 변형된다. 로그 접두, CloudWatch 이스케이프, Playground ```json fence, 배치 빈 줄·잘린 줄.

{
  "ticket_id": "TCK-1042",
  "priority": "high",
  "summary": "Bedrock batch row passed constrained decoding"
}

priority가 urgent이거나 owner가 생기면 SLA가 오동작한다. SAMPLE_BAD는 enum 초과—같은 TICKET_SCHEMA로 막는다.

{
  "ticket_id": "TCK-1042",
  "priority": "urgent",
  "summary": "enum value not in schema"
}

로컬 검증용 TICKET_SCHEMA는?

JSON Schema로 필드와 enum을 고정한다. priority는 low/medium/high만. additionalProperties:false로 미선언 키 거부. 통과는 형태만 의미한다.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "additionalProperties": false,
  "required": ["ticket_id", "priority", "summary"],
  "properties": {
    "ticket_id": {
      "type": "string",
      "description": "Support ticket ID, e.g. TCK-1042"
    },
    "priority": {
      "enum": ["low", "medium", "high"]
    },
    "summary": {
      "type": "string",
      "maxLength": 200
    }
  }
}

로컬 3단계가 무엇을 고치나?

Bedrock은 온라인 디코더, JSONNote는 오프라인 검수대. 순서: schema 적합→fence repair→JSONL 행 검사.

JSONNote에서 3단계를 어떻게 돌리나?

1. 1
   1단계: Schema 검증

   JSON Schema. 1칸 TICKET_SCHEMA, 2칸 SAMPLE_OK 또는 로그 JSON. enum·누락·추가 키 즉시 표시.

2. 2
   2단계: fence repair

   JSON repair. ```json fence 채팅을 붙여 제거 후 다시 Schema 검증.

3. 3
   3단계: JSONL 행 검사

   JSONL 도구. Bedrock 배치를 올려 각 줄 parse 확인. BAD 행은 TICKET_SCHEMA로 enum/절단 구분.

자주 묻는 질문

Bedrock 구조화 출력이면 로컬 검증을 생략할 수 있나?

아니오. API는 해당 Invoke 응답만 보장한다. 로그·배치·복사·캐시는 같은 schema로 재검증해야 한다.

strict 도구와 output_config schema 관계는?

둘 다 JSON Schema로 token을 제한하지만 계층이 다르다. 도구 인자는 tool schema, 최종 텍스트는 output_config. 로컬에서는 schema를 분리 저장한다.

JSONL 한 줄 실패 시 전체 배치를 다시 돌려야 하나?

꼭 전체 재실행은 아니다. JSONL 도구로 행 번호, TICKET_SCHEMA로 enum·절단·문법 확인. 실패 행만 재시도.

로컬 schema에도 additionalProperties:false를 쓰나?

예. Bedrock 요청 schema와 로컬 TICKET_SCHEMA를 일치시킨다. 어긋나면 API 통과와 적재 거부가 엇갈린다.

스트리밍도 JSONL 검사가 필요한가?

스트리밍은 하나로 이은 뒤 Schema·Repair. JSONL은 배치가 여러 줄 파일일 때만.

정리

Bedrock 구조화 출력은 API 응답을 JSON Schema에 고정한다. 배치·스트리밍 결합·로그·붙여넣기는 형태를 깨뜨린다.

결론: 온라인은 Bedrock output_config, 오프라인은 같은 TICKET_SCHEMA 검증·Repair·JSONL.

블로그로 돌아가기