目錄
AI를 활용해 해외 뉴스를 정리하고 요약, 분류, 출처를 Notion 데이터베이스에 저장하는 작업은 자동화에 적합합니다. 하지만 매일 수십 건의 기사를 처리해야 하는 경우, Claude가 뉴스 내용을 정확하게 이해했더라도 JSON 형식 오류, 필수 필드 누락, API 요구사항에 맞지 않는 데이터 유형 때문에 마지막 데이터 저장 단계에서 전체 작업이 중단될 수 있습니다.
2026년 10월 19일, AWS는 기술 블로그를 통해 Amazon Bedrock의 Anthropic Claude에 대한 구조화 출력(Structured Outputs) 지원을 확대한다고 발표했습니다. 이를 통해 모델이 개발자가 지정한 JSON Schema에 따라 데이터를 생성할 수 있게 되었습니다. 다음 날 발표된 공식 공지에서도 이 기능이 Bedrock Runtime과 Bedrock Mantle 두 가지 엔드포인트를 모두 지원한다는 점이 확인되면서, 모델 출력을 안정적으로 처리해야 하는 애플리케이션의 선택지가 넓어졌습니다.
이번 업데이트가 콘텐츠 자동화에 미치는 실질적인 영향은 AI와 외부 시스템 사이에서 데이터를 주고받을 때 발생하는 형식 관련 문제를 줄일 수 있다는 점입니다. 과거에는 프롬프트 지시, 프로그램 검증, 반복적인 재시도에 의존해야 했던 필드 정리 작업을 이제는 모델이 콘텐츠를 생성하는 과정에서부터 제약할 수 있습니다. 덕분에 후속 시스템이 예상한 구조에 맞는 데이터를 더 쉽게 확보할 수 있습니다.
다만 구조화 출력이 형식 오류를 줄여준다고 해서 모델이 제공하는 정보가 반드시 정확하다는 의미는 아닙니다. Claude가 반환한 모든 데이터를 Notion API에 그대로 전달할 수 있다는 뜻도 아닙니다. 모델이 JSON을 생성한 뒤 실제로 Notion 데이터베이스에 저장되기까지는 필드 변환, 콘텐츠 사실 확인, 권한 관리, 오류 처리 등의 과정이 여전히 필요합니다. 모델이 JSON Schema를 지원한다고 해서 이러한 작업이 자동으로 사라지는 것은 아닙니다.
Claude 구조화 출력이란? 일반 JSON 출력과 무엇이 다를까?
Claude의 구조화 출력은 모델이 미리 지정된 형식에 따라 데이터를 반환하도록 하는 기능입니다. 개발자는 JSON Schema를 통해 필드 이름, 데이터 유형, 필수 항목, 허용되는 선택지를 정의할 수 있으며, AI가 애플리케이션에 필요한 구조에 맞춰 결과를 생성하도록 할 수 있습니다.
예를 들어 뉴스 정리 시스템에서 각 기사에 요약, 주제 분류, 사람의 검토 필요 여부를 포함해야 한다고 가정해 보겠습니다. 요약은 문자열이어야 하고, 분류는 지정된 선택지 중 하나만 사용할 수 있으며, 검토 필요 여부는 반드시 true 또는 false로 표시해야 합니다. 이러한 규칙을 사전에 Schema에 작성해 두면 모델이 일반적인 문장 표현 습관에 따라 필드 내용을 자유롭게 생성하는 상황을 방지할 수 있습니다.
AI에 JSON으로 출력하라고 지시해도 형식 오류가 발생하는 이유는?
기존에 흔히 사용하던 방법은 프롬프트에서 모델에 'JSON만 출력하고 다른 설명은 추가하지 마세요'라고 직접 지시하는 것이었습니다. 때로는 완성된 예시를 함께 제공해 모델이 지정된 형식을 따르도록 유도하기도 했습니다. 이 방법은 대체로 효과적이지만, 프롬프트 자체에는 형식을 강제로 준수하게 만드는 기능이 없습니다. 특히 입력 내용이 복잡하거나 필드 수가 많아지는 경우, 또는 모델이 여러 작업을 동시에 처리해야 하는 경우에는 예상과 다른 결과가 생성될 수 있습니다.
예를 들어 시스템에서 뉴스 분류를 'AI 모델', 'AI 산업', '개발 도구'로 고정했는데 모델이 임의로 '생성형 AI 기술'이라는 분류를 출력할 수 있습니다. 또 다른 필드에서는 원래 불리언 값이 필요하지만, 모델이 '사람의 검토가 필요함'이라는 문자열을 입력할 수도 있습니다. 이러한 응답은 의미상 문제가 없고 사람이 읽기에도 자연스러울 수 있지만, 고정된 데이터 유형에 따라 정보를 처리해야 하는 프로그램에서는 파싱이나 검증 실패의 원인이 될 수 있습니다.
문제는 필드 내용에만 국한되지 않습니다. 모델이 JSON 앞에 설명 문장을 추가하거나 Markdown 코드 블록으로 결과를 감싸는 경우도 있습니다. 이 때문에 JSON을 직접 파싱하도록 설계된 프로그램은 먼저 불필요한 문자열을 제거해야 합니다. 이러한 문제를 후처리로 수정할 수 있더라도 데이터양이 늘어나면 추가 검증, 수정, 재시도 작업이 실행 효율에 영향을 미치게 됩니다.
Constrained Decoding은 Claude가 JSON Schema를 준수하도록 어떻게 도울까?
이번에 AWS가 강조한 기술은 **Constrained Decoding(제약 디코딩)**입니다. 전체 응답이 완성된 뒤 다른 프로그램이 형식을 수정하는 방식이 아니라, 모델이 콘텐츠를 생성하는 과정에서 Schema에 맞지 않는 출력을 제한하는 기술입니다.
일반적인 언어 모델은 문맥을 바탕으로 다음 토큰을 예측하지만, 제약 디코딩은 형식 규칙을 생성 과정에 반영해 현재 구조적 제약에 부합하는 선택지 안에서만 다음 내용을 생성하도록 합니다. 예를 들어 특정 필드가 불리언 값만 허용한다면 생성 과정에서 해당 데이터 유형에 맞지 않는 출력을 제한하므로, 모델이 이를 일반적인 문장 표현으로 바꾸는 상황을 방지할 수 있습니다.
AWS 공식 설명에 따르면 서비스는 구조화 출력 요청을 받은 뒤 먼저 Schema가 지원되는 규격에 부합하는지 확인하고, 이를 생성 과정에서 사용하는 문법 제약으로 컴파일합니다. 컴파일된 결과는 캐시할 수 있으므로 이후 동일한 구조를 사용하는 요청에서는 매번 다시 처리할 필요가 없습니다. 모델 역시 이러한 제약 안에서 지정된 형식에 맞는 콘텐츠를 생성할 수 있습니다.
이 방법은 형식 오류를 줄일 수 있지만, 필드 안에 담긴 정보가 사실인지는 검증하지 못합니다. 예를 들어 Schema는 날짜가 지정된 형식을 따르도록 요구할 수 있지만, 원본 뉴스에 발행 시간이 없다면 모델이 출처에 근거하지 않은 날짜를 입력할 가능성은 여전히 존재합니다. JSON 구조의 유효성과 정보의 사실 여부는 별도로 처리해야 하는 문제입니다.
Amazon Bedrock은 2026년 10월에 Claude의 어떤 기능을 업데이트했을까?
Amazon Bedrock이 구조화 출력을 제공하기 시작한 시점이 2026년 10월인 것은 아닙니다. AWS는 같은 해 2월 4일 이미 관련 기능을 발표했으며, 당시 Claude 4.5 시리즈와 일부 오픈 웨이트 모델을 지원하고 Converse, ConverseStream, InvokeModel 등의 인터페이스를 통해 사용할 수 있도록 했습니다.
10월 19일 기술 블로그와 20일 공식 공지는 Claude 모델의 지원 범위 확대와 여러 Bedrock 엔드포인트에서 기능을 사용하는 방식에 초점을 맞췄습니다. AWS는 해당 모델을 사용할 수 있는 환경이라면 Bedrock Runtime이나 Bedrock Mantle을 통해 Claude를 호출할 때 모두 구조화 출력 기능을 사용할 수 있다고 발표했습니다.
이번 업데이트에는 주로 JSON Schema Output Format과 Strict Tool Use가 포함됩니다. 두 기능 모두 데이터 형식과 관련이 있지만, 각각 처리하는 단계는 다릅니다.
JSON Schema Output Format과 Strict Tool Use의 차이점은?
JSON Schema Output Format은 모델이 최종적으로 반환하는 데이터 구조를 제한하는 기능으로, 콘텐츠 요약, 문서 정보 추출, 분류 결과 생성, 보고서 정리 등에 적합합니다. 반면 Strict Tool Use는 모델이 도구를 호출할 때 전달하는 매개변수에 초점을 맞춥니다. 도구 정의에 strict: true를 설정하면 입력값이 미리 지정된 Schema를 따르도록 요구할 수 있습니다.
Notion 자동화를 예로 들면 Claude는 먼저 JSON Schema Output Format을 사용해 뉴스 요약과 분류를 정리한 다음, Strict Tool Use 규칙에 부합하는 도구 매개변수를 전달해 외부 프로그램에 Notion 페이지 생성을 요청할 수 있습니다. 다만 도구 매개변수가 정확하더라도 작업이 반드시 성공하는 것은 아닙니다. 실제 실행 과정에서는 API 권한, 대상 데이터 소스, 서비스 응답 등을 추가로 확인해야 하기 때문입니다.
| 비교 항목 | JSON Schema Output Format | Strict Tool Use |
| 주요 용도 | 모델이 반환하는 데이터 구조 제한 | 모델이 도구를 호출할 때 사용하는 매개변수 제한 |
| 적용 상황 | 요약, 분류, 데이터 추출, 보고서 정리 | API 호출, AI 에이전트, 다단계 자동화 |
| 제한 대상 | 필드 이름, 데이터 유형, 필수 항목, 허용값 | 도구 이름 및 입력 매개변수 구조 |
| 일반적인 활용 | 규격에 맞는 뉴스 데이터 생성 | 페이지 생성 또는 데이터 업데이트 도구 호출 |
| 보장할 수 없는 사항 | 데이터 내용의 사실 여부 | 도구 실행 성공, 적절한 권한 또는 비즈니스 요구사항에 부합하는 작업 |
여러 시스템 사이에서 데이터를 처리하는 애플리케이션은 작업 흐름에 따라 두 기능 중 하나를 사용하거나 함께 사용할 수 있습니다. 실제로 두 기능을 모두 사용해야 하는지는 AI가 단순히 데이터를 생성하는 역할만 하는지, 아니면 외부 시스템을 조작할 권한까지 부여받았는지에 따라 달라집니다.
Claude 구조화 출력은 Notion 뉴스 데이터베이스 자동화를 어떻게 개선할까?
매일 해외 기술 뉴스를 정리해야 한다면 이상적인 작업 흐름은 보통 원본 콘텐츠를 확보한 뒤 AI가 요약을 작성하고 주제를 분류하도록 한 다음, 최종 결과를 Notion에 저장하는 방식입니다. 이렇게 저장된 정보는 이후 편집, 조사, 분류 관리 등에 활용할 수 있습니다.
이러한 작업 흐름에서 가장 까다로운 문제는 데이터가 전달되는 단계에서 자주 발생합니다. 모델이 원래 지정된 분류를 의미가 비슷한 다른 표현으로 바꾸거나 필수 필드를 누락할 수 있기 때문입니다. 요약 자체가 잘 작성되었더라도 후속 프로그램에서는 이러한 차이를 별도로 처리해야 합니다. 구조화 출력은 이 중 일부 문제를 줄여 AI가 제공하는 데이터를 데이터베이스에서 요구하는 고정 형식에 더 가깝게 만들어 줍니다.
JSON Schema로 뉴스 데이터의 어떤 필드를 제한할 수 있을까?
뉴스 정리 시스템에서 Claude가 생성해야 하는 정보가 번체 중국어 요약, 기사 분류, 사람의 검토 필요 여부, 검토가 필요한 이유 등 네 가지라고 가정해 보겠습니다. 이 경우 다음과 같은 JSON Schema를 사용할 수 있습니다.
{
"type": "object",
"properties": {
"summary": {
"type": "string",
"description": "根據來源內容撰寫繁體中文摘要"
},
"category": {
"type": "string",
"enum": [
"AI 模型",
"AI 產業",
"開發工具",
"資安隱私",
"其他"
]
},
"requires_review": {
"type": "boolean"
},
"review_note": {
"type": "string",
"description": "需要審核的原因，沒有疑慮時使用空字串"
}
},
"required": [
"summary",
"category",
"requires_review",
"review_note"
],
"additionalProperties": false
}이 Schema에서는 네 개의 필드가 모두 반드시 포함되어야 합니다. 그중 category는 정해진 다섯 가지 분류만 사용할 수 있고, requires_review는 반드시 불리언 값이어야 하므로 '필요함'이나 '필요하지 않음' 같은 자유로운 문자열로 바꿀 수 없습니다. additionalProperties: false는 정의되지 않은 추가 필드를 금지하는 설정으로, AWS 구조화 출력에서 객체 Schema에 요구하는 조건이기도 합니다.
분류에 '其他(기타)'를 남겨둔 이유는 기존 범주에 합리적으로 포함하기 어려운 기사를 처리하기 위해서입니다. 선택지가 몇 가지 고정된 항목뿐인데 모델이 매번 그중 하나를 반드시 선택해야 한다면, 실제로는 해당하지 않는 기사까지 억지로 잘못된 주제에 분류될 수 있습니다.
뉴스 원본 URL, 수집 시간, 출처 식별자는 데이터 수집 시스템에서 이미 제공하고 있다면 모델이 다시 생성하도록 할 필요가 없습니다. 이러한 필드는 원본 데이터를 그대로 보존하는 편이 일반적으로 더 신뢰할 수 있으며, AI가 존재하지 않는 정보를 임의로 추가할 위험도 줄일 수 있습니다.
Claude가 생성한 JSON을 Notion에 바로 저장할 수 없는 이유는?
Claude와 Notion API는 모두 JSON으로 데이터를 주고받지만, 두 시스템에서 사용하는 구조는 서로 다릅니다. Claude의 JSON Schema는 모델이 어떤 필드를 생성해야 하는지 정의하는 반면, Notion Data Source Schema는 데이터 소스에 실제로 어떤 속성이 존재하고 각 속성이 어떤 유형의 데이터를 허용하는지 정의합니다.
예를 들어 Claude가 summary라는 문자열 필드를 반환하더라도 Notion에서는 대상 데이터 소스의 설정에 따라 요약을 해당 rich_text 속성으로 변환해야 합니다. 기사 분류 역시 Notion의 select 속성이 요구하는 구조로 변환해야 합니다. 모델이 올바른 JSON을 생성했더라도 이러한 필드 매핑 작업은 여전히 프로그램이 담당해야 합니다.
또 한 가지 확인해야 할 부분은 Notion API의 데이터 소스 구조입니다. Notion은 2025년 9월 API 업데이트에서 Database와 Data Source를 더욱 명확하게 구분했습니다. 현재 문서에서도 데이터 페이지를 생성할 대상을 지정할 때 data_source_id를 사용합니다. 따라서 기존 자동화 시스템이 과거의 데이터베이스 식별 방식에 의존하고 있다면, 실제 도입 전에 사용 중인 API 버전과 데이터 소스 설정을 확인해야 합니다.
Notion Select 속성 때문에 AI가 의도치 않게 분류를 추가할 수 있다
Notion의 분류 속성에는 놓치기 쉬운 동작 방식이 있습니다. 공식 문서에 따르면 연동 서비스에 해당 데이터 소스에 대한 쓰기 권한이 있는 경우, select 또는 multi_select 속성에 존재하지 않는 선택지 이름을 입력하면 시스템이 새로운 선택지를 데이터 소스의 Schema에 직접 추가할 수 있습니다.
이는 분류 이름이 일치하지 않더라도 반드시 오류가 반환되는 것은 아니라는 뜻입니다. 경우에 따라 기사는 정상적으로 저장되지만, 데이터베이스에 'AI 기술', '인공지능 기술', '생성형 AI 도구'처럼 의미가 비슷한 태그가 점점 늘어나면서 원래 정돈되어 있던 분류 체계가 혼란스러워질 수 있습니다.
JSON Schema의 enum을 사용하면 모델이 임의로 새로운 분류를 만드는 상황을 줄일 수 있습니다. 하지만 애플리케이션에서도 데이터를 저장하기 전에 선택지가 Notion의 현재 설정과 일치하는지 확인해야 합니다. 특히 데이터베이스의 분류가 사람에 의해 변경될 수 있다면 Schema를 만들 당시의 선택지 목록에만 의존해서는 안 됩니다.
검토 절차에서 Notion의 status 속성을 사용한다면 상황은 조금 다릅니다. 공식 문서에 따르면 페이지에 데이터를 쓸 때는 기존 상태만 지정할 수 있고, 새 페이지 생성 요청을 통해 새로운 Status 선택지를 만들 수는 없습니다. 따라서 '검토 대기'와 같은 상태가 미리 존재하는지 확인해야 합니다.
Amazon Bedrock API는 어떤 구조화 출력 방식을 지원할까?
Claude 구조화 출력을 사용할 때는 실제로 선택한 API에 주의해야 합니다. Amazon Bedrock은 인터페이스마다 요청 형식이 완전히 같지 않기 때문입니다.
예를 들어 Converse API를 통해 모델을 호출할 때는 구조화 출력 설정에 outputConfig.textFormat을 사용합니다. 반면 InvokeModel API에서 Anthropic 형식의 요청을 보낼 때는 output_config.format을 사용합니다. Mantle의 Anthropic Messages API도 후자를 사용하지만, 엔드포인트 지원 여부는 별도로 확인해야 합니다.
Bedrock Runtime과 Mantle의 지원 문서가 일치하지 않는 이유는?
2026년 10월 22일 기준, Mantle의 구조화 출력 지원 여부에 관한 AWS 공식 문서에는 서로 일치하지 않는 내용이 존재합니다.
AWS가 10월 19일 공개한 기술 블로그와 20일 공식 공지, 주요 Bedrock Structured Outputs 사용자 가이드에서는 bedrock-runtime과 bedrock-mantle을 모두 지원 범위에 포함하고 있습니다. 그러나 Claude Messages Structured Outputs 전용 문서에는 Mantle의 Anthropic Messages API 경로가 output_config.format을 지원하지 않으며, 사용 시 HTTP 400이 반환될 수 있다는 설명이 여전히 남아 있습니다.
이 자료들은 모두 AWS 공식 문서이므로 Mantle에서 해당 기능을 사용할 수 없다고 단정하기보다는 문서 간 업데이트가 아직 완전히 동기화되지 않은 문제로 보는 편이 합리적입니다. 실제 배포 시에는 대상 AWS Region, Claude Model ID, SDK 버전, 엔드포인트 설정을 확인하고 간단한 Schema를 이용한 테스트 요청이 성공하는지 검증해야 합니다.
먼저 안정적인 개념 증명(PoC) 환경을 구축하려면 Bedrock Runtime의 Converse 또는 InvokeModel 경로를 우선 검토하고, 실제 테스트 결과에 따라 Mantle로 확장할지 결정할 수 있습니다.
Claude 구조화 출력의 제한 사항과 비용 고려 요소는?
구조화 출력은 형식의 안정성을 개선할 수 있지만, 실제 환경에 적용하기 전에는 JSON Schema의 지원 범위, 모델의 출력 완료 상태, 새로운 Schema를 처음 사용할 때 추가로 발생할 수 있는 지연 시간을 확인해야 합니다.
JSON Schema의 모든 규칙이 강제로 적용되는 것은 아니다
AWS 문서에 따르면 Bedrock은 기본 데이터 유형, enum, const, 일부 조합 규칙, 내부 참조 등 JSON Schema Draft 2020-12의 일부 기능을 지원합니다. 하지만 재귀적 Schema, 외부 $ref, 숫자 범위와 문자열 길이 제한에는 명확한 제약이 있습니다.
예를 들어 minimum, maximum, minLength, maxLength가 생성 과정에서 반드시 강제로 적용된다고 가정해서는 안 됩니다. 지원하지 않는 규칙을 처리하는 방식에 대해서도 AWS 문서마다 설명이 일부 다릅니다. 경우에 따라 요청 검증 단계에서 거부될 수 있으며, 규칙 자체는 허용되더라도 실제 생성 과정에서는 결과를 제한하지 못할 수도 있습니다.
따라서 뉴스 요약의 글자 수를 특정 범위로 제한해야 하거나 숫자 필드가 지정된 범위 안에 있어야 한다면, 애플리케이션에서 별도로 검증해야 합니다. Schema는 첫 번째 형식 제한 장치로 활용할 수 있지만, 모든 데이터 검증을 맡기기에는 적합하지 않습니다.
모델의 응답 거부나 출력 중단으로 불완전한 결과가 생성될 수 있다
모델이 정상적으로 생성을 완료한 경우 구조화 출력은 지정된 Schema에 부합하는 결과를 제공할 수 있지만, 이 기능에도 예외는 존재합니다.
모델이 안전 정책에 따라 응답을 거부하거나 출력이 max_tokens 제한에 도달해 조기에 중단된다면 완전한 JSON을 얻지 못할 수 있습니다. AWS도 모범 사례에서 애플리케이션이 매 요청의 중단 이유를 확인해야 한다고 안내합니다. API가 성공 상태를 반환했다는 이유만으로 모델이 모든 데이터를 완전히 생성했다고 판단해서는 안 됩니다.
또한 Bedrock에서 Anthropic 모델의 구조화 출력과 Citations 기능 사이에는 호환성 제한이 존재하며, 두 기능을 동시에 활성화하면 HTTP 400이 발생할 수 있습니다. 작업 흐름에서 뉴스 원문의 출처를 추적할 수 있는 근거를 보존해야 한다면 데이터 수집 시스템에서 출처 링크와 원본 콘텐츠를 저장하고, 필요할 경우 별도의 인용 검증 절차를 마련해야 합니다.
새로운 Schema를 처음 사용할 때 처리 시간이 길어질 수 있는 이유는?
AWS 구조화 출력은 먼저 Schema를 생성 과정에서 사용할 Grammar로 컴파일해야 합니다. 따라서 새로운 구조를 처음 사용하는 요청은 일반 요청보다 시간이 더 걸릴 수 있습니다. 컴파일이 완료되면 결과가 동일 계정 범위에서 캐시되며, 캐시 유지 기간은 최초 접근 후 24시간입니다. 이후 같은 Schema를 사용하는 요청에서는 컴파일에 드는 비용을 줄일 수 있습니다.
자동화 프로그램이 실행될 때마다 필드 구조를 동적으로 수정한다면 새로운 컴파일 과정이 반복적으로 발생할 수 있습니다. 매일 대량의 뉴스, 고객 문의 티켓, 제품 정보를 처리하는 시스템에서는 지속적으로 새로운 구조를 생성하기보다 고정되고 버전 관리가 이루어지는 Schema를 사용하는 편이 일반적으로 성능과 운영·유지보수 비용을 관리하기 쉽습니다.
전체 비용은 실제 사용하는 모델, 리전, 토큰 사용량에 따라 추산해야 합니다. 구조화 출력은 형식 오류로 인한 재시도를 줄일 수 있고, 불필요한 필드를 제한해 출력량을 감소시킬 수도 있습니다. 하지만 최초 컴파일로 인한 지연, 외부 API 호출, 콘텐츠 검증, 사람의 검토에 드는 비용도 전체 비용에 포함해야 합니다.
매일 정리할 기사가 몇 건에 불과하고 이미 편집과 게시를 담당하는 인력이 있다면 Bedrock 기반의 전체 자동화 시스템을 도입하는 것이 수작업보다 반드시 경제적인 것은 아닙니다.
Claude 구조화 출력을 Notion 뉴스 데이터베이스에 도입하는 방법
실제 작업 흐름을 설계할 때는 뉴스 수집, 모델 처리, 데이터 검증, Notion 저장 과정을 분리하는 것이 좋습니다. 각 단계에서 입력, 출력, 오류 기록을 별도로 보존해야 특정 기사의 페이지 생성이 실패하더라도 원본 데이터, 모델 출력, 외부 API 중 어디에서 문제가 발생했는지 파악할 수 있습니다.
뉴스 원본 데이터는 Claude에 전달하기 전에 정제해야 한다
해외 뉴스는 RSS, 공식 공지, 언론사 API 또는 합법적으로 접근할 수 있는 다른 출처에서 가져올 수 있습니다. 수집한 콘텐츠에는 HTML 태그, HTML 엔티티, 중복 문단이 포함되거나 일부 텍스트가 잘려 있을 수 있습니다. 이러한 데이터를 그대로 모델에 전달하면 요약 품질에 영향을 주고 모델이 원문을 잘못 이해할 가능성도 커집니다.
따라서 Claude를 호출하기 전에 데이터를 정제하고 출처 URL, 원본 제목, 발행 날짜, 수집 시간을 보존하는 편이 더 안정적입니다. 특히 뉴스 발행 날짜와 데이터 가져오기 날짜는 서로 다른 필드로 구분해야 합니다. 그래야 시스템이 다시 수집한 과거 뉴스를 새로운 사건으로 잘못 인식하는 일을 방지할 수 있습니다.
정제 작업이 끝나면 Claude가 요약, 분류, 검토 필요 여부 판단을 담당하도록 합니다. 출처에서 날짜, 숫자, 인물 정보를 명확하게 제공하지 않은 경우에는 알 수 없음 또는 재검토 필요로 표시할 수 있어야 하며, 모델에 누락된 정보를 임의로 채우도록 요구해서는 안 됩니다.
Notion API에 저장하기 전에는 필드 매핑을 완료해야 한다
Claude가 Schema에 부합하는 결과를 생성하면 프로그램은 Notion 데이터 소스에 실제로 존재하는 속성에 맞춰 데이터를 변환한 다음 페이지 생성 API를 호출해야 합니다.
다음은 요청 본문의 예시입니다. 대상 데이터 소스에 Name, Category, Review라는 세 가지 속성이 이미 존재한다고 가정합니다.
{
"parent": {
"data_source_id": "YOUR_DATA_SOURCE_ID"
},
"properties": {
"Name": {
"title": [
{
"text": {
"content": "AWS 擴展 Claude 結構化輸出支援"
}
}
]
},
"Category": {
"select": {
"name": "開發工具"
}
},
"Review": {
"status": {
"name": "待審核"
}
}
}
}이 예시는 주로 Notion의 필드 구조를 보여주기 위한 것이며, 완전한 API 호출 프로그램은 아닙니다. 실제 사용 시에는 속성 이름을 데이터 소스 설정에 맞게 변경하고, 연동 서비스에 콘텐츠 추가 권한이 있는지 확인해야 합니다. 또한 요청 헤더에 유효한 인증 정보와 적절한 Notion API 버전을 제공해야 합니다.
뉴스 요약을 페이지 콘텐츠에 저장해야 한다면 별도의 rich_text 속성을 만들거나 필요에 따라 페이지 블록을 사용해 전체 텍스트를 저장할 수도 있습니다. 모델의 출력 형식과 Notion의 최종 저장 방식은 분리해서 설계할 수 있으므로 Claude가 Notion API 요청 전체를 직접 생성하도록 할 필요는 없습니다.
API 오류 발생 시 재시도로 인한 중복 기사를 방지해야 한다
자동화 작업에서는 성공 응답뿐만 아니라 권한 부족, 데이터 검증 실패, 요청 속도 제한, 네트워크 타임아웃 등의 상황도 고려해야 합니다.
Notion 공식 문서에 따르면 API에는 워크스페이스 요금제에 따라 연동 요청 한도가 설정되어 있으며, 일부 엔드포인트에는 별도의 제한도 있습니다. 요청이 지나치게 자주 발생하면 HTTP 429가 반환될 수 있으므로 프로그램은 Retry-After 지시에 따라 이후 재시도를 예약해야 합니다.
하지만 페이지 생성 작업에서 실패가 발생했다고 해서 단순히 같은 요청을 즉시 다시 보내서는 안 됩니다. 예를 들어 Notion에서 이미 기사 페이지를 성공적으로 생성했지만 결과가 반환되기 전에 네트워크 연결이 끊겼다고 가정해 보겠습니다. 이때 프로그램이 동일한 요청을 다시 실행하면 내용이 완전히 같은 페이지가 두 개 생성될 수 있습니다.
이러한 문제는 출처 식별자, 정규화된 URL, 중복 검사 등을 통해 위험을 줄일 수 있습니다. 페이지를 성공적으로 생성한 뒤에는 Notion이 반환한 페이지 ID도 저장해야 합니다. 그래야 이후 작업에서 매번 새로운 기사를 추가하는 대신 기존 기사를 업데이트할 수 있습니다.
Claude 구조화 출력은 도입할 가치가 있을까? 효과는 어떻게 평가해야 할까?
Claude 구조화 출력은 고정된 필드를 가진 대량의 데이터를 처리하고, 모델의 결과를 다른 시스템에 직접 전달해야 하는 작업에 적합합니다. 예를 들어 뉴스 분류, 고객 문의 티켓 정리, 문서 필드 추출, 제품 데이터 처리 등이 있습니다. 필드 하나의 데이터 유형만 잘못되어도 후속 프로그램에 영향을 줄 수 있는 업무라면 형식의 안정성이 실질적인 가치를 갖습니다.
하지만 도입 효과를 JSON 파싱 성공 여부만으로 판단해서는 안 됩니다. 예를 들어 기존에는 매일 많은 기사가 형식 오류 때문에 Notion에 저장되지 못했다면 구조화 출력 도입 후 이러한 문제는 실제로 줄어들 수 있습니다. 그러나 요약에 잘못된 숫자가 계속 포함되거나 분류가 편집 요구사항에 부합하지 않는다면 전체 업무 효율이 반드시 개선되는 것은 아닙니다.
보다 합리적인 평가 방법은 대표성 있는 뉴스 기사 여러 건을 선정해 동일한 입력 데이터로 기존 프롬프트 방식과 구조화 출력 방식을 테스트하는 것입니다. 이후 형식 오류, 분류 정확도, 사람의 수정 시간, 총처리 비용의 차이를 관찰할 수 있습니다.
| 평가 항목 | 확인해야 할 사항 |
| 형식 실패율 | 모델이 지정된 Schema에 맞지 않는 결과를 생성하는가 |
| 분류 정확도 | AI가 선택한 분류가 편집자의 판단과 일치하는가 |
| 콘텐츠 사실 오류율 | 요약에 원문으로 뒷받침되지 않는 정보가 포함되는가 |
| Notion 저장 성공률 | 검증을 통과한 데이터로 페이지를 정상적으로 생성할 수 있는가 |
| 평균 처리 시간 | 뉴스 수집부터 초안 완성까지 얼마나 걸리는가 |
| 사람의 수정 시간 | 편집자가 기사 한 건을 수정하는 데 여전히 얼마나 많은 시간을 투입해야 하는가 |
| 기사당 처리 비용 | 모델 비용, API 사용 비용, 인건비가 합리적인가 |
테스트 결과 형식 오류가 눈에 띄게 줄고 사람의 수정 시간도 함께 감소했다면 사용 범위를 더욱 확대할 근거가 됩니다. 반대로 데이터 형식만 정돈되었을 뿐 콘텐츠 품질과 전체 처리 시간이 개선되지 않았다면 실제 문제가 모델의 출력 형식에 있는지, 아니면 원본 데이터 품질이나 작업 흐름 설계에 있는지 다시 확인해야 합니다.
결론: Claude 구조화 출력은 데이터 전달을 개선하지만 완전한 검증 절차는 여전히 필요하다
Amazon Bedrock은 2026년 10월 Claude 구조화 출력 지원을 확대했습니다. 이를 통해 고정된 데이터 형식이 필요한 AI 애플리케이션은 모델 응답을 더 쉽게 처리할 수 있게 되었으며, 프롬프트 지시나 형식 수정 프로그램에 의존하던 일부 작업도 줄일 수 있게 되었습니다. 이미 Notion으로 뉴스, 연구 자료, 프로젝트 콘텐츠를 관리하는 팀이라면 이 기능을 활용해 요약, 분류, 데이터베이스 저장 과정 사이에서 발생하는 데이터 전달 문제를 개선할 수 있습니다.
다만 JSON Schema는 정보가 사실인지 확인할 수 없으며, Strict Tool Use 역시 외부 도구의 실행 성공을 보장하지 않습니다. 뉴스 출처 확인, 필드 매핑, 권한 설정, 중복 데이터 처리, 사람의 검토는 여전히 전체 자동화 작업 흐름에서 담당해야 합니다.
Claude 구조화 출력을 Notion에 도입하려 한다면 먼저 고정된 Schema로 소수의 기사를 처리하고, 결과를 검토 대기 데이터베이스에 저장하는 것부터 시작하는 편이 적절합니다. 이후 실제 오류율과 처리 비용을 관찰하고 형식, 콘텐츠, API 작업이 모두 안정적으로 작동한다는 점을 확인한 다음 자동화 수준을 단계적으로 높이는 것이 좋습니다. 처음부터 AI가 모든 기사를 직접 생성하고 공개하도록 하는 것보다 운영과 유지보수가 수월합니다.
자주 묻는 질문
Claude 구조화 출력(Structured Outputs)은 모델이 지정된 JSON Schema에 따라 필드, 데이터 유형, 고정 선택지를 반환하도록 하는 기능입니다. JSON 형식 불일치로 발생하는 자동화 오류를 줄일 수 있습니다.
일반 프롬프트는 모델에 형식을 지키도록 요청하는 방식이지만, 구조화 출력은 Constrained Decoding을 통해 생성 과정에서 Schema에 부합하지 않는 내용을 제한합니다. 이를 통해 필드 누락이나 데이터 유형 오류가 발생할 가능성을 낮춥니다.
전자는 모델이 최종적으로 반환하는 데이터 구조를 규정하고, 후자는 AI가 외부 도구를 호출할 때 사용하는 입력 매개변수를 규정합니다. 작업 흐름에 따라 각각 사용하거나 함께 사용할 수 있습니다.
보장하지 않습니다. Schema는 형식에 초점을 맞추며 콘텐츠가 원문과 일치하는지 판단할 수 없습니다. 존재하지 않는 날짜, 숫자, 인물 정보가 생성되는 것도 방지하지 못하므로 출처 확인과 사람의 검토가 여전히 필요합니다.
일반적으로 Notion API에 그대로 전달할 수 없습니다. 애플리케이션에서 모델 필드를 데이터 소스의 title, rich_text, select, status 등의 속성으로 매핑하고 API 권한과 응답을 처리해야 합니다.
연동 서비스에 해당 쓰기 권한이 있다면 Notion이 select 또는 multi_select 선택지를 자동으로 추가할 수 있습니다. 따라서 모델 단계에서 enum으로 분류를 제한하고, 저장 전에 기존 선택지와 다시 대조해야 합니다.
AWS는 2026년 10월 공지에서 두 가지 모두 지원 대상으로 명시했습니다. 하지만 일부 Claude 전용 문서에는 Mantle의 제한 사항이 여전히 남아 있습니다. 실제 도입 전에는 모델, 리전, 엔드포인트에 따라 테스트해야 합니다.
아닙니다. AWS는 JSON Schema의 일부 기능만 지원합니다. 재귀 구조, 외부 $ref, 일부 문자열 길이와 숫자 범위 제한이 그대로 작동한다고 가정해서는 안 되며, 프로그램에서도 별도로 검증해야 합니다.
새로운 Schema를 처음 사용하면 Bedrock이 Grammar를 컴파일해야 합니다. 컴파일 결과는 약 24시간 동안 캐시할 수 있지만, Schema를 자주 변경하면 최초 컴파일로 인한 지연이 반복적으로 발생할 수 있습니다.
반드시 그렇지는 않습니다. 형식 오류와 재시도는 감소할 수 있지만, 모델 사용량, Schema 컴파일, API 호출, 사람의 재검토에는 여전히 비용이 발생합니다. 실제 형식 실패율, 처리 시간, 기사당 비용을 기준으로 평가해야 합니다.
출처 식별자와 정규화된 URL을 보존하고 페이지 생성 전에 중복 검사를 수행해야 합니다. 생성에 성공한 뒤에는 Notion 페이지 ID를 저장해 요청 타임아웃 이후 단순 재시도로 중복 기록이 생성되는 상황을 방지해야 합니다.