Amazon Bedrock Claude Structured Outputs, JSON 강제를 생성 단계로 이동

AWS에 따르면 Amazon Bedrock Claude structured outputs는 이제 두 Bedrock 엔드포인트를 모두 지원하며, JSON 형식 강제를 애플리케이션의 사후 복구 단계에서 모델 생성 단계로 옮긴다. 구조화된 출력은 응답을 선언된 형식으로 제한해 언어 모델과 후속 소프트웨어 간 계약을 더 명확하게 만든다. 이 변화는 형식 오류를 해결하지만, 반환된 정보를 해석하고 이에 따라 행동하는 책임은 여전히 개발자에게 남는다.

AWS는 2026년 10월 19일 지원 확대를 발표했다. 핵심 약속은 잘못된 형식의 응답을 복구하거나 재시도를 요청하는 맞춤형 코드를 유지하는 팀을 겨냥한다. 이러한 작업은 유용한 정보 추출, 요청 라우팅, 작업 조율이라는 애플리케이션 본연의 목적과 경쟁한다.

Google Gemini 역시 스키마 기반 응답을 제공하며, 유용한 업계 기준점이 된다. 당장의 압박은 여전히 모델 출력을 정리가 필요한 예측 불가능한 텍스트로 취급하는 애플리케이션 팀에 가해진다. 이제 이들이 결정할 문제는 어떤 복구 작업을 없앨 수 있는지, 어떤 검증이 여전히 필요한지, 그리고 이러한 책임을 어떻게 구분할지다.

Amazon Bedrock Claude Structured Outputs, 두 엔드포인트 지원

AWS는 이 기능이 bedrock-runtime 및 bedrock-mantle 엔드포인트에서 해당 모델을 사용할 수 있는 모든 곳의 모든 Anthropic Claude 모델을 지원한다고 설명한다. 엔드포인트는 애플리케이션이 요청을 보내는 서비스 주소다. 따라서 이번 발표는 응답 형식뿐 아니라 통합 범위에 관한 내용이기도 하다.

이번 릴리스는 JSON Schema 출력 형식과 엄격한 도구 사용을 결합한다. JSON Schema는 예상 데이터 구조를 기술하고, 엄격한 도구 사용은 모델이 생성한 도구 인수에 선언된 구조를 적용한다. AWS는 Claude structured outputs 발표에서 두 메커니즘을 함께 제시한다.

운영상의 변화는 개발자가 모델에 형식 지침을 반복적으로 따르라고 요청하는 대신, 강제된 구조를 요청할 수 있게 된다는 점이다.

이 차이는 모델이 더 큰 소프트웨어 프로세스 안에 들어갈 때 중요하다. 응답을 읽는 사람은 도입 문장을 간과하거나 명백한 형식 오류를 알아차릴 수 있다. 반면 특정 레코드를 기대하는 소프트웨어는 일반적으로 무엇이 도착하는지에 관한 더 명시적인 합의가 필요하다.

이러한 합의 아래에서는 기존 복구 로직을 새롭게 검토할 필요가 있다. 일부 코드는 모델이 가끔 설명 문구로 응답을 감싸기 때문에 존재한다. 다른 코드는 누락된 정보, 서비스 장애 또는 추가 증거가 필요한 판단을 처리한다. 이 범주들은 서로 다르게 다뤄야 한다.

이번 발표는 누적된 복잡성을 살펴볼 이유를 제공한다. 모든 애플리케이션이 같은 정리 부담을 안고 있다는 뜻은 아니다. 이미 다른 강제 출력 메커니즘을 사용하는 팀은 전적으로 프롬프트에 의존하는 팀과 다른 마이그레이션 결정을 마주한다.

여러 통합 경로를 유지하는 조직에서는 엔드포인트 전반의 지원 범위도 중요하다. 기능을 인프라 일부에서만 사용할 수 있다면 별도 구현이나 예외 처리가 필요할 수 있다. 더 넓은 가용성은 의도한 응답 계약을 더 일관되게 만들 기회를 제공한다.

다만 엔드포인트 이름이 주변 기능까지 동일하다는 의미는 아니다. AWS의 추론 엔드포인트 비교는 두 엔드포인트 모두에서 구조화된 출력 지원을 명시적으로 확인하는 한편, 더 광범위한 기능은 구분한다. Runtime에는 리전 간 추론을, Mantle에는 서버 측 도구 실행을 나열한다.

이 차이는 이번 소식을 균형 있게 바라보게 한다. 엔드포인트를 선택하는 조직은 여전히 애플리케이션 운영 방식을 고려해야 한다. 응답 기능에 대한 공통 지원이 실행, 권한, 대화 관리 또는 배포 위치에 관한 결정을 없애지는 않는다.

“모든 Claude 모델”이라는 표현에도 가용성 조건이 붙는다. 독자는 이를 모든 모델이 모든 리전에 존재한다는 약속으로 해석해서는 안 된다. 실제 배포 경로에서 의도한 모델과 기능이 함께 작동하는지가 여전히 핵심 질문이다.

기존 Bedrock 고객에게 이는 주로 확립된 통합을 단순화할 기회다. 신규 프로젝트에는 응답 구조가 애플리케이션 복구 작업이 아니라 서비스 기능이 될 수 있다는 아키텍처적 가정을 바꾼다.

압박은 JSON 복구를 유지하는 팀으로 이동한다

가장 뚜렷한 압박 대상은 방어적 형식화 코드를 유지하는 엔지니어링 팀이다. 구조화된 데이터를 교환하는 텍스트 형식인 JSON은 흔히 모델 응답을 일반 애플리케이션 로직에 연결한다. 이 연결이 실패하면 개발자는 모델과 주변 소프트웨어를 모두 조사해야 한다.

서비스가 이미 필요한 계약을 제공한다면, 네이티브 구조 강제는 형식화 작업의 필요성을 더 엄격하게 따지게 만든다.

가상의 지원 라우팅 애플리케이션을 생각해 보자. 모델은 고객 메시지를 읽고 카테고리, 긴급도 평가, 설명을 생성한다. 이후 라우팅 시스템은 이 레코드를 적절한 대기열로 보낸다.

형식 오류가 발생하면 라우팅 시스템은 레코드 자체를 읽지 못한다. 분류 오류는 읽을 수는 있지만 잘못된 판단을 담은 레코드를 만든다. 둘 다 워크플로를 방해하지만, 해결책은 다르다.

따옴표를 바꾸는 재시도는 첫 번째 문제를 해결한다. 고객 요청이 선택된 대기열에 속한다는 보장은 제공하지 않는다. 두 실패를 같은 문제로 취급하면 신뢰성 보고서의 정보 가치가 떨어진다.

따라서 Amazon Bedrock Claude structured outputs의 실질적 이점은 부분적으로 조직적이다. 팀은 응답 계약과 관련된 실패를 해석과 관련된 실패에서 분리할 수 있다. 이러한 분리는 애플리케이션이 예기치 않게 동작할 때 책임 소재를 더 분명하게 한다.

인프라 팀은 실패한 요청이나 불완전한 응답을 조사할 수 있다. 애플리케이션 팀은 추출된 필드가 원본을 반영하는지 검토할 수 있다. 비즈니스 책임자는 분류 결과가 자동 조치에 적합한지 결정할 수 있다.

이 구분은 팀이 서비스 연결 소프트웨어인 기존 미들웨어를 평가하는 방식도 바꾼다. 응답 문법만 복구하는 구성 요소의 역할은 더 좁아진다. 워크플로를 조율하고, 권한을 관리하거나, 증거를 보존하는 구성 요소는 별도의 목적을 유지한다.

여기서 개발자 도구의 한 범주 전체가 쓸모없어졌다고 선언할 근거는 없다. 많은 통합은 형식화를 넘어 유용한 작업을 수행한다. 중요한 질문은 각 계층이 애플리케이션이 실제로 마주하는 실패를 여전히 처리하는지다.

엔터프라이즈 구매자도 공급업체 데모를 검토할 때 같은 구분을 적용해야 한다. 깔끔한 레코드는 통합이 사용할 수 있는 형태를 생성할 수 있음을 보여준다. 그러나 해당 레코드가 원본을 정확히 나타내거나 건전한 의사결정을 뒷받침한다는 사실까지 입증하지는 않는다.

이 구분은 지식 워크플로에서 특히 중요해진다. 문서에는 상충하는 날짜, 모호한 소유권 또는 다른 출처가 나중에 정정한 진술이 포함될 수 있다. 형식이 올바른 결과도 이러한 문제를 그대로 보존하거나 정돈된 필드 뒤에 숨길 수 있다.

추출 결과를 검색 가능한 지식 기반에 연결하는 팀은 원본 증거에 대한 접근을 유지해야 한다. 구조화된 레코드는 소프트웨어가 정보를 정리하도록 돕는다. 원본 문서는 그 정리가 실제로 작성된 내용을 반영하는지 사람이 판단하도록 돕는다.

따라서 가장 강력한 비즈니스 사례는 어떤 엔지니어링 작업이 사라지고, 확보된 관심이 어디로 향하는지를 밝힐 것이다. “형식 복구 감소”는 평가할 수 있는 구체적 주장이다. “신뢰할 수 있는 자동화”에는 정확성, 예외 및 조치 통제에 관한 더 폭넓은 설명이 필요하다.

제약된 생성이 통합 계약을 바꾼다

제약된 디코딩은 생성 중 모델이 선택할 수 있는 출력 범위를 제한해, 요청된 구조와 호환되도록 한다. 중요한 변화는 응답이 애플리케이션에 도달하기 전에 일어난다. 개발자는 더 이상 모델이 형식 지침을 따르려는 의지에만 의존하지 않는다.

생성 단계의 강제는 전달 후 각 응답을 복구하는 대신 형식 변동의 원인을 해결한다.

프롬프트는 원하는 구조를 신중한 언어로 설명할 수 있다. 하지만 이 지침은 여전히 응답이 설명을 준수하는지에 애플리케이션을 의존하게 만든다. 생성 제약은 설명의 지원되는 부분을 모델이 출력할 수 있는 내용에 대한 제한으로 바꾼다.

이 기능이 또 하나의 응답 형식 설정을 넘어 주목할 만한 이유가 여기에 있다. 애플리케이션과 모델의 관계가 바뀐다. 임의의 텍스트를 받아 레코드를 복구하려 하는 대신, 명시적 계약을 통해 레코드를 요청한다.

그렇다고 일반적인 JSON 파싱이 사라지는 것은 아니다. 파싱은 반환된 텍스트를 애플리케이션 코드가 사용할 수 있는 객체로 변환한다. 줄어드는 부담은 구조화된 데이터를 읽는 기본 행위가 아니라, 잘못된 형식의 출력에서 복구하는 맞춤형 작업이다.

Anthropic의 구조화된 출력 동작 방식은 응답 형식화와 엄격한 도구 입력을 구분한다. 개발자는 이 메커니즘을 독립적으로 또는 함께 사용할 수 있다. 문서에는 애플리케이션이 처리해야 하는 예외로 거부와 출력 길이 제한도 명시되어 있다.

이 구분은 보고서를 생성하고 조치를 요청하는 애플리케이션에서 중요하다. 최종 보고서에는 응답 계약이 있다. 제안된 도구 호출에는 입력 계약이 있다. 하나를 강제한다고 해서 다른 하나까지 자동으로 보장되는 것은 아니다.

송장을 추출하고 일치하는 계정 항목을 제안하는 가상의 문서 처리 워크플로를 생각해 보자. 추출 결과에는 예측 가능한 필드가 필요하다. 제안된 조치에는 수신 함수가 이해할 수 있는 인수가 필요하다.

송장이 선택된 계정에 속하는지 여부는 여전히 비즈니스가 판단해야 한다. 이 질문은 증거와 비즈니스 규칙에 달려 있다. 유효한 계정 식별자를 담은 필드가 그 식별자가 올바른 고객을 가리킨다는 사실까지 입증하지는 않는다.

따라서 엄격한 도구 사용은 생성된 제안과 실행 가능한 소프트웨어 사이의 경계를 개선한다. 수신 시스템이 검토할 수 있는 더 예측 가능한 객체를 제공한다. 권한 부여는 제안된 작업을 진행할지에 대한 별도의 결정으로 남는다.

스키마 설계 역시 제품 결정이 된다. 필수 필드는 애플리케이션이 정보를 기대한다는 점을 전달할 수 있지만, 원본에 해당 정보가 없을 수도 있다. 설계자는 불확실성이나 누락된 증거를 표현할 명시적 방법이 필요하다.

그렇지 않으면 깔끔한 계약이 오해를 부르는 인터페이스를 조장할 수 있다. 예상되는 모든 위치에 값이 있으므로 애플리케이션은 완전해 보인다. 독자는 그 값이 원본에서 왔는지, 근거 없는 추론에서 나왔는지 간과할 수 있다.

관련된 설계 질문은 증거가 불완전할 때 레코드가 무엇을 의미하는지다. 불확실성을 수용하는 스키마는 후속 소프트웨어가 적절히 대응할 기회를 제공한다. 불확실성을 숨기는 스키마는 해당 소프트웨어에 유용한 선택지를 더 적게 남긴다.

이 지점에서 형식 개선과 제품 품질이 만납니다. 구조 강제는 선언된 계약의 신뢰도를 높입니다. 동시에 다른 시스템이 그 출력을 더 적은 마찰로 활용할 수 있기 때문에, 그 계약의 약점은 더 큰 영향을 미치게 됩니다.

AWS, 선언형 출력 계약으로 향하는 더 큰 흐름에 합류

Google의 Gemini structured outputs 문서도 제공된 JSON Schema에 따라 제어되는 응답을 설명합니다. 이 기능은 추출, 분류, 도구용 구조화 입력을 중심으로 제시됩니다. 따라서 AWS의 발표는 모델 통합 분야에서 이미 자리 잡은 방향에 속합니다.

경쟁의 핵심은 이제 모델이 JSON을 흉내 낼 수 있는지보다 계약의 품질과 적용 범위가 되고 있습니다.

구조화된 출력을 독자적인 모델 지능 주장으로 취급하는 것보다 이것이 더 유용한 비교 방식입니다. 기대한 형태를 생성하는 능력과 까다로운 문서를 해석하는 능력은 서로 다릅니다. 공급업체는 후자에서의 우위를 입증하지 않고도 전자를 개선할 수 있습니다.

구매자에게 이는 비교 과정의 변화를 뜻합니다. 올바르게 보이는 샘플 응답만으로는 플랫폼을 선택하기에 충분하지 않습니다. 실제 스키마, 실제 문서, 실제 배포 요구 사항을 함께 비교해야 합니다.

프로덕션 계약에는 필드 이름 이상이 포함되므로, 공급업체가 지원하는 스키마 하위 집합은 중요합니다. 일부 애플리케이션에는 범위가 제한된 값, 엄격히 통제된 텍스트 또는 복잡한 관계가 필요합니다. 다른 애플리케이션에는 예측 가능한 유형을 갖춘 비교적 단순한 레코드면 충분합니다.

이러한 애플리케이션을 동일한 호환성 기준으로 평가해서는 안 됩니다. 기능은 단순한 분류 작업에는 적합할 수 있지만, 더 까다로운 데이터 계약에는 추가 작업이 필요할 수 있습니다. 광범위한 마케팅 문구만으로는 애플리케이션별 질문에 답할 수 없습니다.

독립 연구는 평가를 구성하는 데 유용한 방법을 제공합니다. JSONSchemaBench 연구는 효율성, 제약 조건 적용 범위, 생성된 출력 품질을 검토합니다. 이 차원들은 성공적으로 파싱된 응답 수를 세는 것보다 더 폭넓은 프레임워크를 제공합니다.

이 연구를 이번 10월 Bedrock 출시의 벤치마크로 제시해서는 안 됩니다. 이는 새 발표의 성능 판정이 아니라 평가 접근법을 뒷받침합니다. 더 강한 결론을 뒷받침하려면 AWS는 출시별 증거를 제시해야 합니다.

엔터프라이즈 팀에서 효율성은 사용 가능한 결과를 생성하는 데 필요한 리소스와 시간을 의미합니다. 적용 범위는 시스템이 의도된 계약을 준수하는지를 뜻합니다. 품질은 반환된 콘텐츠가 작업에 기여하는지를 뜻합니다.

이 차원들은 서로 영향을 주지만 하나로 합쳐지지는 않습니다. 잘 읽히는 레코드라도 고객 이름이 잘못되었다면 여전히 좋지 않은 결과입니다. 정확하게 추출했더라도 애플리케이션이 요구하는 계약을 반복적으로 충족하지 못하면 운영 작업이 발생합니다.

따라서 즉각적인 경쟁 압박은 취약한 통합 가정에 가해집니다. “정중하게 요청한 뒤 수정한다”는 방식으로 구축된 시스템에는 이제 또 다른 네이티브 대안이 생겼습니다. 팀은 남아 있는 각 수정 또는 변환이 왜 여전히 아키텍처에 포함되어야 하는지 설명할 필요가 있습니다.

그렇다고 구조화된 출력 지원만을 기준으로 공급업체를 선택해야 하는 것은 아닙니다. 기존 인프라, 모델 적합성, 운영 요구 사항은 여전히 중요합니다. 다만 응답 계약을 부수적인 프롬프트 동작으로 여기지 않고 플랫폼의 일부로 평가해야 합니다.

AWS에 이번 발표는 Claude를 위한 기존 배포 채널의 활용성을 확장합니다. 고객에게 중요한 질문은 선택한 배포 환경이 애플리케이션에 실제로 필요한 계약을 지원할 수 있는지입니다. 이는 어떤 모델이 더 깔끔한 JSON을 작성하는지에 관한 일반적인 주장보다 더 구체적인 판단입니다.

스키마 준수는 정확성과 문서화에 관한 질문을 남긴다

이번 출시는 AWS 자체 문서에 특정 검증 공백을 남깁니다. 발표와 엔드포인트 비교 자료는 Mantle 지원을 설명합니다. 그러나 일반 Bedrock structured-output guide는 Mantle의 Messages API가 관련 형식 지정 매개변수를 거부한다고 여전히 명시합니다.

이 진술들은 서로 충돌합니다. 더 새로운 발표와 명시적인 엔드포인트 안내는 지원 범위가 확대되었다고 보고하지만, 상충하는 가이드를 설명하지는 않습니다. 개발자는 문서 예시를 서로 바꿔 쓸 수 있다고 보기 전에 의도한 요청 경로를 검증해야 합니다.

증거는 보고된 확장을 뒷받침하지만, 상충하는 가이드는 독자가 모든 배포 세부 사항을 얼마나 확신할 수 있는지를 제한합니다.

같은 가이드는 무제한 지원이 아닌 JSON Schema의 지원되는 하위 집합을 설명합니다. 지원되지 않는 기능으로 숫자 범위와 문자열 길이 제약 조건을 나열합니다. 또한 문법 컴파일과 캐싱을 설명하므로, 스키마 복잡성은 요청 동작과 관련이 있습니다.

이 세부 사항들은 “스키마 준수”의 의미를 좁힙니다. 프로덕션 스키마는 서비스가 강제하지 않는 요구 사항을 표현할 수 있습니다. 애플리케이션은 강제되는 구조와 여전히 자체 책임으로 남는 요구 사항을 구분해야 합니다.

예를 들어, 예시 일정 관리 시스템은 허용된 업무 범위 안의 숫자형 기간을 기대할 수 있습니다. 숫자를 받는 것은 그 유형을 확립합니다. 그 기간이 허용 가능한지를 확립하려면 관련 제약 조건이 어딘가에서 강제되어야 합니다.

이는 사실 정확성과 다릅니다. 기간은 업무 범위를 충족하면서도 원본 문서를 잘못 나타낼 수 있습니다. 완전한 신뢰성 평가는 성공적인 검증을 최종 결과로 취급하지 않고 두 질문을 모두 유지해야 합니다.

AWS의 발표 자체도 거부와 토큰 제한을 처리해야 할 경우로 언급합니다. 토큰 제한은 생성되는 출력량을 제한합니다. 생성이 완료 전에 중단되면 애플리케이션은 약속된 완성 레코드를 받았다고 가정할 수 없습니다.

이 예외들은 애플리케이션이 전체 서비스 상호작용을 통해 응답을 접한다는 점에서 중요합니다. 응답 본문, 완료 상태, 후속 작업은 동일한 운영 순서에 속합니다. 본문만 보면 다음에 무엇을 할지 결정하는 데 필요한 정보를 놓치게 됩니다.

적절한 대응은 대상이 명확한 단순화입니다. 네이티브 강제가 형식 수정을 포괄하고 자체 테스트가 그 판단을 뒷받침하는 경우, 팀은 형식 수정 작업을 제거할 수 있습니다. 그러나 불완전한 실행, 지원되지 않는 요구 사항 또는 부정확한 해석을 다루는 검사는 유지해야 합니다.

보안 경계도 같은 방식으로 분리할 필요가 있습니다. 형식이 올바른 지시라도 사용자가 수행 권한이 없는 작업을 요청할 수 있습니다. 수신 시스템은 제안된 인수가 스키마에 얼마나 잘 부합하는지와 별개로 접근 권한을 강제해야 합니다.

측정 위험도 존재합니다. 마이그레이션 후 대시보드에는 파싱 실패가 줄어든 것으로 나타날 수 있지만, 추출 품질 변화는 간과할 수 있습니다. 더 깔끔한 기술 지표는 더 나은 비즈니스 결과를 입증하지 못한 채 워크플로가 더 건강해 보이게 만들 수 있습니다.

따라서 구매자는 오류가 중요한 수준의 증거를 요구해야 합니다. 애플리케이션이 요청을 라우팅한다면 라우팅 결정을 검토하십시오. 의무 사항을 추출한다면 해당 의무 사항을 원본과 비교하십시오. 형식 성공은 역할이 분명히 제한된 상태에서 이 작업을 위한 유용한 기반입니다.

Bedrock 출시 이후 주목할 점

향후 몇 달은 이러한 확장이 실제 배포 환경에서 어떻게 작동하는지를 분명히 해줄 것입니다. 가장 유용한 신호는 문서의 일관성, 애플리케이션 성능, 기존 수정 코드의 향방과 관련됩니다. 각각은 발표의 실질적 가치를 검증하는 서로 다른 방법을 제공합니다.

가장 강력한 증거는 정확한 결과와 통제된 작업을 유지하면서 어떤 작업이 사라지는지를 보여줄 것입니다.

첫째, AWS가 상충하는 Mantle 안내를 조정하는지 지켜보십시오. 일반 가이드, 엔드포인트 비교, 작동하는 예시가 일치하면 명시된 적용 범위에 대한 신뢰가 높아질 것입니다. 불일치가 계속된다면 통합 검증은 고객의 핵심 경로에 계속 남게 됩니다.

이는 공개되지 않은 로드맵에 관한 예측이 아니라 구체적인 공개 신호입니다. 문서는 개발자가 상충하는 지침을 역설계하지 않고도 지원되는 요청을 식별할 수 있게 해야 합니다. 명확한 예시는 실패 원인을 더 쉽게 진단하게도 합니다.

모델 및 리전 적격성도 같은 관찰 대상에 속합니다. 팀이 의도한 배포 환경과 그 제한 사항을 확인할 수 있을 때 광범위한 발표는 운영상 유용해집니다. 정확한 호환성 정보는 확대된 지원의 가치를 강화합니다.

둘째, 대표적인 애플리케이션 워크로드를 활용한 평가를 지켜보십시오. 유용한 결과는 형식 실패, 불완전한 응답, 잘못 추출된 값, 작업 실패를 구분할 것입니다. 이를 하나의 성공률로 합치면 시스템의 어느 부분이 개선되었는지 가려집니다.

성능 보고는 새 스키마와 재사용된 스키마도 구분해야 합니다. 컴파일은 일상적인 요청과는 다른 조건을 만듭니다. 계약을 자주 변경하는 애플리케이션에는 그러한 동작에 부합하는 증거가 필요합니다.

같은 원칙은 문서 난이도에도 적용됩니다. 깔끔한 예시는 통제된 사례에서 기능이 작동함을 보여줍니다. 지저분한 입력은 주변 워크플로가 누락된 정보, 모호성, 상충하는 증거를 처리할 수 있는지를 드러냅니다.

작업 정확성을 약화시키지 않으면서 형식 실패가 줄어든 결과는 마이그레이션의 근거를 강화할 것입니다. 수동 수정이 계속되는 결과는 스키마 설계, 지원되지 않는 제약 조건 또는 통합 선택을 더 면밀히 검토하게 할 것입니다. 어느 결과도 잘 다듬어진 시연만으로 추론할 수는 없습니다.

셋째, 팀이 동등한 복잡성을 다른 곳에 다시 구축하지 않고도 기존 형식 코드를 폐기할 수 있는지 지켜보십시오. 복구 루프를 제거하는 마이그레이션은 구체적인 유지보수 이점을 제공합니다. 단지 루프를 옮기는 마이그레이션은 더 신중한 평가가 필요합니다.

가장 설득력 있는 설명은 제거된 코드가 무엇을 했는지와 이제 무엇이 그 책임을 처리하는지를 설명할 것입니다. 또한 사실 정확성과 안전한 실행을 위해 유지된 검사를 식별할 것입니다. 이 구분은 개발자와 구매자 모두가 엔지니어링 개선을 이해하도록 돕습니다.

Amazon Bedrock Claude structured outputs는 팀이 유연한 언어 생성과 예측 가능한 소프트웨어 입력 사이에서 익숙하게 받아들였던 절충안을 재평가할 이유를 제공합니다. 즉각적인 기회는 어디서나 신뢰할 수 있는 자동화를 약속하는 것보다 더 좁고 실행 가능합니다. 이는 지원되는 형식 보장을 서비스 내부로 옮기는 일과 관련됩니다.

이미 이해하고 있는 형식 실패가 발생하는 워크플로부터 시작하십시오. 실제로 마주하는 문서와 예외를 사용해 기존 수정 부담을 새 응답 계약과 비교하십시오. 추출된 값과 원본을 연결하는 증거를 보존하고, 중요한 결과를 초래하는 작업 주위에는 권한 검사도 유지하십시오. 어떤 실패가 사라지고, 어떤 실패가 남으며, 어떤 실패가 더 쉽게 진단되는지 기록하십시오. 그런 다음 그 결과를 바탕으로 더 광범위한 마이그레이션이 애플리케이션에 도움이 되는지 결정하십시오. 남은 신뢰성 책임을 더 쉽게 파악하면서 팀은 형식 작업을 제거할 수 있습니까?