Automated Reasoning policy refinement in Amazon Bedrock

🖼️ 인포그래픽

Automated Reasoning policy refinement in Amazon Bedrock 내용을 설명하는 본문 이미지

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Amazon Bedrock의 자동 정책 정제는 실패한 테스트의 원인을 규칙 문제와 번역 모호성으로 구분해 수정안을 만들고, 사용자가 승인한 변경만 DRAFT 정책에 반영함으로써 반복적인 수동 진단과 편집을 줄인다.

📌 핵심 요약

자동 정책 정제 기능은 실패한 테스트를 진단하고 형식 논리 기반의 수정안을 제안하지만, 실제 정책 변경은 사용자의 명시적인 승인 이후에만 적용된다.
정책 검증은 자연어를 정책 변수에 대응시키는 번역 단계와 해당 변수에 형식 규칙을 적용하는 검증 단계로 구성되며, 실패 원인도 이 두 단계 중 하나에 위치한다.
변수 번역은 올바르지만 결과가 기대와 다르면 Iterative Refinement를 사용하고, 복수의 자연어 해석이 서로 다른 결과를 만들면 Ambiguous Variable Refinement를 사용한다.
Iterative Refinement는 기존 정책 정의, 권위 있는 원문 문서, 선택적 자연어 피드백을 바탕으로 후보 변경을 만들고 저장된 테스트에 반복 적용해 수렴된 차이를 제시한다.
두 정제 방식은 비동기식 시작·상태 조회·결과 회수 흐름을 따르며, 콘솔에서는 제안된 변경을 검토한 뒤 수락하거나 폐기할 수 있다.

🧩 주요 포인트

테스트 실패 지점을 번역과 검증 단계로 분리한다 → 문제 유형에 맞지 않는 규칙 수정이나 변수 설명 수정을 피할 수 있다.
후보 변경을 전체 저장 테스트에 내부적으로 반복 시뮬레이션한다 → 사용자는 중간 시행착오 대신 수렴된 정책 차이와 테스트 영향을 검토한다.
자동 생성된 수정안과 실제 정책 반영 사이에 승인 절차를 둔다 → 진단·수정 작업은 자동화하면서도 변경 통제권은 사용자에게 남긴다.

🧠 상세 정리

1. 수동 정책 정제에서 자동 정제로의 전환

기존의 Automated Reasoning 정책 정제는 실패 원인을 진단하고, 형식 논리를 직접 편집하고, 다시 테스트하는 과정을 결과가 맞을 때까지 반복하는 방식이었다. 새 자동 정책 정제 기능은 이 주기에서 진단과 수정안 작성을 자동화해 실패한 테스트를 분석하고 형식 논리 변경을 제안한다. 다만 엔진이 만든 변경이 즉시 정책에 적용되는 것은 아니며, 사용자가 모든 제안을 검토하고 승인해야 효력이 발생한다. Automated Reasoning 검사는 자연어가 모호하지 않게 형식 논리로 번역되는 경우 형식 검증을 통해 답변의 정확성을 판정하며, 원문은 정식 출시 발표에서 최대 99%의 검증 정확도가 보고됐다고 설명한다. 정책 개발은 권위 있는 원문 문서로 정책을 만들고 기대 결과가 지정된 테스트 사례로 검증하는 방식으로 시작된다. 고객들은 이 과정에서 반복적인 조정 작업이 정책 개발의 가장 큰 마찰 지점이라고 전달했으며, 자동 정제는 바로 그 반복 부담을 줄이는 데 초점을 둔다.

2. 자연어 번역과 형식 검증의 2단계 구조

Automated Reasoning 검사는 자연어를 형식 논리로 바꾼 뒤 자동 추론을 적용해 VALID, INVALID, SATISFIABLE, IMPOSSIBLE 또는 TRANSLATION_AMBIGUOUS 결과를 생성한다. 핵심 구조는 번역과 검증으로 나뉘는 2단계 파이프라인이다. 번역 단계에서는 정책에 작성된 변수 설명을 이용해 자연어 입력과 출력을 변수 및 값에 대응시키고, 검증 단계에서는 그 변수 할당에 정책의 형식 규칙을 적용한다. 따라서 테스트가 실패했다면 자연어가 변수로 잘못 옮겨졌거나, 올바르게 옮겨진 변수에 잘못된 규칙이 적용된 것이다. 정책 테스트는 입력·출력 텍스트와 기대 결과를 한 묶음으로 구성하며 개별 실행과 일괄 실행을 모두 지원한다. 실패 결과는 현재 정책이 작성자의 의도와 어긋나는 위치를 드러내므로, 어떤 정제 방식을 선택할지를 결정하는 직접적인 진단 신호가 된다.

3. 첫 번째 실패 유형: 규칙 논리의 문제

규칙 문제에서는 자연어 번역이 정상적으로 수행되어 올바른 변수에 올바른 값이 들어가지만, 형식 규칙이 만들어 낸 검증 결과가 기대와 다르다. 규칙이 지나치게 허용적이거나 지나치게 제한적일 수 있으며, 필요한 규칙이 아예 빠져 있을 수도 있다. 예를 들어 잘못된 답을 차단하기 위해 INVALID를 기대했는데 SATISFIABLE이 반환됐다면, 누락되거나 느슨한 규칙이 잘못된 답을 통과시킨 상황일 수 있다. 반대로 올바른 답에 SATISFIABLE을 기대했는데 INVALID가 나왔다면, 과도하게 엄격한 규칙이 정상 답변을 막고 있을 수 있다. 이 유형에서는 시스템이 질문과 답변을 변수로 해석하는 데는 성공했으므로 변수 설명을 고치는 것이 아니라 정책의 규칙을 수정해야 한다. 원문은 이러한 규칙 문제를 더 일반적인 실패 유형으로 설명하며, 대응 기능으로 Iterative Refinement를 제시한다.

4. 두 번째 실패 유형: 변수 번역의 모호성

TRANSLATION_AMBIGUOUS는 자연어를 정책 변수에 대응시키는 과정에서 단일한 해석을 확정하지 못했음을 나타낸다. 일부 사례에서는 여러 번역 모델이 같은 자연어를 어떤 변수와 값으로 옮길지에 대해 서로 다른 해석을 만들고, 각 해석에 규칙을 적용했을 때 검증 결론까지 달라진다. 결과에는 둘 이상의 번역 선택지와 각 선택지의 결론이 함께 제시되며, differenceScenarios는 경쟁하는 해석이 실제로 어디에서 다른 결과를 만드는지 보여준다. 주요 원인으로는 tenure와 years of service처럼 의미가 겹치는 변수 정의, 충분히 명확하지 않은 설명, 그리고 5%를 5 또는 0.05로 표현하는 것과 같은 값 형식의 불일치가 제시된다. 이 경우 규칙 자체를 아무리 편집해도 불안정한 번역 문제가 해결되지 않으므로, Ambiguous Variable Refinement를 이용해 변수 설명과 변수 구조를 명확하게 만들어야 한다. 검증 대상 문장의 표현 자체에서도 모호성이 생길 수 있지만, 원문의 해당 설명은 정책 변수에서 비롯되는 모호성에 초점을 맞춘다.

Iterative Refinement는 번역 결과는 올바르지만 검증 논리가 기대와 다를 때 사용하는 정제 방식이며, 워크플로 유형으로 ITERATIVELY_REFINE_POLICY가 지정된다. 첫 번째 필수 입력은 현재 규칙, 변수, 자료형을 포함하는 기존 정책 정의이고, 두 번째 필수 입력은 정책이 어떻게 작동해야 하는지를 자연어로 규정한 권위 있는 원문 문서다. 세 번째 입력은 선택 사항인 자연어 피드백으로, 사용자가 원하는 변경 사항을 구체적인 지시 형태로 전달할 수 있다. 원문은 개정 문서의 특정 절에 따라 육아휴직에 필요한 근속 기간을 12개월에서 6개월로 바꾸라는 요청을 예로 든다. 엔진은 현재 정책과 원문 문서 및 피드백의 차이를 분석한 뒤 새로운 규칙, 수정된 규칙, 추가 변수 등 정책을 의도에 맞추는 후보 변경을 만든다. 이를 통해 10~30개의 규칙을 가진 정책에서 전문가가 SMT-LIB 형식 논리를 여러 차례 직접 추적하고 편집하던 작업을 하나의 검토·승인 단계로 압축할 수 있다고 설명한다.

6. 내부 수렴 반복과 사용자 승인 절차

Iterative Refinement는 하나의 수정안을 즉시 반환하는 대신 내부적인 수렴 반복을 수행한다. 엔진은 후보 변경을 생성하고 저장된 테스트에 미치는 영향을 시뮬레이션한 뒤, 기존에 실패했던 테스트가 통과하는지 확인하고 통과하지 않으면 다시 조정한다. 한 규칙의 수정이 다른 규칙에 연쇄적인 영향을 줄 수 있으므로 단일 요청 안에서도 여러 차례의 내부 반복이 일어날 수 있다. 사용자는 각각의 중간 시도를 관찰하거나 직접 안내할 필요가 없으며, 최종적으로 어떤 규칙과 변수가 바뀌었고 전체 테스트 결과가 어떻게 달라지는지를 보여주는 수렴된 차이를 받는다. 결과가 준비되면 정책 변경 검토 화면에서 변경 수락 또는 변경 폐기를 선택하며, 수락하면 변경이 DRAFT 정책에 기록되고 폐기하면 기존 상태가 그대로 유지된다. 이 방식에는 정책에 연결된 테스트가 최소 하나 필요하고, TRANSLATION_AMBIGUOUS가 발생한 경우에는 규칙 정제가 아니라 변수 언어 정제를 사용해야 한다.

7. 비동기 API와 콘솔 실행 흐름

API에서 Iterative Refinement는 현재 정책 정의를 내보내고, 빌드 워크플로를 시작하고, 완료 상태를 조회하고, 제안 결과를 회수하는 비동기 흐름으로 실행된다. iterativeRefinementContent에는 필수 원문 문서를 1개에서 5개까지 넣을 수 있고, 선택적 피드백은 최대 4,000자까지 제공할 수 있다. 시작 호출은 변경된 정책을 즉시 반환하지 않고 buildWorkflowId를 반환하며, 상태는 SCHEDULED에서 BUILDING으로 이동한 뒤 COMPLETED, FAILED 또는 CANCELLED 중 하나에 도달한다. 원문에 따르면 수렴에는 정책 크기에 따라 보통 1분에서 수분이 걸리며, 호출자는 get_automated_reasoning_policy_build_workflow로 종료 상태까지 주기적으로 확인한다. 완료 후 POLICY_DEFINITION 자산을 요청하면 전체 수정안이 반영된 정책 정의를 받고, BUILD_LOG를 요청하면 작업 기록을 확인할 수 있다. 반환값은 완전한 새 DRAFT 제안이므로 실제 반영에는 update_automated_reasoning_policy 호출이 필요하며, 시작 전에 내보낸 정의와 비교하면 구체적인 변경 내용을 볼 수 있다. 콘솔의 정책 변경 검토 화면도 같은 시작·조회·회수 절차를 감싸서 차이를 표시하고 수락 및 폐기 버튼을 제공한다.

Ambiguous Variable Refinement는 규칙 논리가 아니라 정책 변수의 언어가 불안정해 여러 번역이 만들어질 때 사용하는 방식이다. 실행 구조는 Iterative Refinement와 동일하게 비동기식 시작·상태 조회·결과 회수 순서를 따르고, 최종적으로 같은 검토 및 승인 화면에 도달한다. 차이점은 제안의 중심이 규칙 자체가 아니라 변수 설명의 명료화와 중복 변수의 병합에 있다는 점이며, 정책 일관성을 유지하는 데 필요하면 관련 규칙과 자료형도 함께 갱신된다. 대표적인 예로 tenureMonths와 monthsOfService가 모두 직원의 근속 기간을 뜻하도록 정의되면 번역 모델은 자연어를 어느 변수에 연결해야 할지 합의하지 못할 수 있다. 이런 중복은 동일한 내용에서 복수의 변수 할당을 만들고, 각 할당에 규칙을 적용했을 때 결론이 달라지는 TRANSLATION_AMBIGUOUS 결과로 이어질 수 있다. 따라서 이 정제 방식은 경쟁하는 해석을 하나로 수렴시킬 수 있도록 변수의 의미와 경계를 분명히 하는 데 목적이 있으며, 규칙 편집만으로 해결할 수 없는 번역 단계의 문제를 다룬다.

🧾 핵심 주장 / 시사점

정책의 정확성은 형식 규칙뿐 아니라 자연어를 변수로 옮기는 번역의 일관성에도 좌우되므로, 변수 설명은 단순한 문서가 아니라 검증 동작을 결정하는 정책 구성 요소다.
저장된 테스트는 정책을 평가하는 수단인 동시에 자동 정제의 수렴 신호로 사용되며, 각 테스트의 입력·출력과 기대 결과가 수정안의 효과를 확인하는 기준이 된다.
제안 생성과 실제 반영을 분리한 승인 절차는 자동화 범위를 진단과 수정안 작성까지 넓히면서도, 정책 변경 여부와 최종 DRAFT 반영 권한은 사용자에게 유지한다.