SMT-LIB 수동 편집을 대체하는 '검토 및 승인' 워크플로
정책 설계 전문가가 10~30개의 규칙을 수정하기 위해 SMT-LIB(Satisfiability Modulo Theories) 정형 논리 언어를 직접 편집하던 수동 사이클을 Amazon Bedrock이 단 한 번의 검토와 승인 단계로 압축했다. 기존 워크플로는 실패한 테스트를 진단하고 논리식을 수동으로 수정한 뒤 다시 테스트하는 반복 과정에 의존했으나, 이제는 시스템이 제안한 수정안을 사용자가 승인하는 방식으로 전환되었다. Amazon Bedrock의 자동 추론(Automated Reasoning) 엔진은 실패한 테스트 케이스를 분석하여 정형 논리 기반의 수정안을 자동으로 제안한다.
사용자는 시스템이 제안한 변경 사항을 검토한 후 '변경 사항 수락(Accept changes)' 또는 '변경 사항 폐기(Discard changes)'를 선택하여 정책에 반영한다. 수락된 변경 사항은 DRAFT 정책에 즉시 기록되며, 폐기 시에는 기존 상태가 그대로 유지된다. 이러한 변화는 정형 논리를 직접 작성하지 않고도 정책 최적화가 가능하게 하여, 정책 개발 과정에서 가장 큰 마찰 지점이었던 반복적인 튜닝 작업을 제거했다. 정형 검증 기반의 자동 추론은 자연어에서 정형 논리로의 번역이 명확할 때 최대 99%의 검증 정확도를 제공한다.
번역과 검증으로 구성된 2단계 정형 검증 파이프라인
Amazon Bedrock의 자동 추론 체크는 자연어 입출력을 변수 할당으로 매핑하는 '번역(Translate)' 단계와 정형 규칙을 적용하는 '검증(Validate)' 단계의 2단계 파이프라인으로 동작한다. 1단계 번역 과정은 정책에 정의된 변수 설명을 기준으로 자연어 입력값을 특정 변수 값으로 연결한다. 2단계 검증 과정은 할당된 변수 값들에 정형 규칙을 적용하여 최종 판단 결과를 도출한다. [Figure 1]에 명시된 이 구조는 자연어라는 비정형 데이터를 기계가 처리 가능한 정형 데이터로 변환한 뒤 수학적으로 증명하는 방식이다.
시스템은 검증 결과로 `VALID`, `INVALID`, `SATISFIABLE`, `IMPOSSIBLE`, `TRANSLATION_AMBIGUOUS`라는 다섯 가지 상태 값을 반환한다. `INVALID`나 `IMPOSSIBLE`은 번역은 성공했으나 적용된 정형 규칙이 입력값과 충돌함을 의미하며, `TRANSLATION_AMBIGUOUS`는 번역 단계에서 단일한 해석을 내리지 못했음을 나타낸다. 사용자는 이 결과 값을 통해 문제의 원인이 변수 정의의 모호함(번역 단계)에 있는지, 혹은 논리 규칙의 결함(검증 단계)에 있는지를 즉각적으로 구분할 수 있다.
규칙 오류를 자동 교정하는 Iterative Refinement의 작동 기제
Iterative Refinement(`ITERATIVELY_REFINE_POLICY`) 모드는 번역은 정확하지만 검증 결과가 예상과 일치하지 않는 '규칙 이슈'를 해결한다. 이 기능은 기존 정책 정의, 권위 있는 자연어 소스 문서, 그리고 선택적인 자연어 피드백(예: "육아휴직 근속 요건을 12개월에서 6개월로 변경")이라는 세 가지 입력을 기반으로 작동한다. 엔진은 현재 규칙이 소스 문서 및 피드백과 어떻게 다른지 분석하여 새로운 규칙 생성, 기존 규칙 편집, 변수 추가 등의 후보 수정안을 제안한다.
개선 엔진은 내부적으로 후보 수정안을 생성하고 저장된 테스트 케이스에 적용하여 효과를 시뮬레이션하는 반복 사이클을 수행한다. 엔진은 이전에 실패했던 테스트가 통과하는지 확인하고, 한 규칙의 수정이 다른 규칙에 영향을 주는 연쇄 반응이 발생하면 이를 다시 조정한다. 사용자는 이러한 내부 시뮬레이션 과정을 관찰할 필요 없이, 모든 조정이 완료되어 수렴된 최종 결과물인 '제안된 차이점(diff)'만 전달받는다. 이 모드를 실행하기 위해서는 정책에 최소 하나 이상의 실패한 테스트 케이스가 연결되어 있어야 한다.
언어적 모호성을 제거하는 Ambiguous Variable Refinement의 진단 방식
Ambiguous Variable Refinement 모드는 시스템이 `TRANSLATION_AMBIGUOUS` 신호를 반환하는 '언어 이슈' 상황을 해결한다. 이는 번역 모델들이 자연어 입력을 정책 변수로 매핑하는 과정에서 서로 다른 해석을 내놓고, 그 결과가 서로 다른 검증 결론으로 이어질 때 발생한다. 주요 원인으로는 '근속 연수'와 '서비스 기간'처럼 중복된 변수 정의, 모호한 설명, 또는 '5%'를 5로 처리할지 0.05로 처리할지와 같은 값 형식의 불일치가 꼽힌다.
시스템은 해석의 충돌 지점을 명시하기 위해 `differenceScenarios` 데이터를 제공하여 서로 다른 해석 경로와 그에 따른 결론을 대조해 보여준다. 사용자는 이 시나리오를 통해 모델이 어느 지점에서 혼란을 느꼈는지 기술적으로 확인하고, 변수 정의와 설명을 최적화하여 단일한 번역이 가능하도록 수정한다. 중복된 의미의 변수를 통합하거나 값 형식을 명확히 규정하는 텍스트를 추가함으로써 번역 모델의 판단 기준을 좁히면 `TRANSLATION_AMBIGUOUS` 상태가 해소된다.
Boto3 비동기 API 구현과 최적화 모드 선택 기준
실무자는 Boto3 SDK를 통해 `buildWorkflowType='ITERATIVELY_REFINE_POLICY'` 인자를 설정하여 비동기 최적화 워크플로를 시작하고 `buildWorkflowId`를 반환받는다. 이후 `get_automated_reasoning_policy_build_workflow` 함수를 반복 호출하여 상태가 `SCHEDULED` $
ightarrow$ `BUILDING` $
ightarrow$ `COMPLETED`로 전이되는지 폴링한다. 최종 상태 도달 후 `get_automated_reasoning_policy_build_workflow_result_assets` 함수로 `POLICY_DEFINITION` 에셋을 요청하면 수정된 규칙과 변수가 포함된 diff 결과물을 회수할 수 있다.
buildWorkflowType='ITERATIVELY_REFINE_POLICY'get_automated_reasoning_policy_build_workflowget_automated_reasoning_policy_build_workflow_result_assets정형 논리 전문가 없이도 소스 문서와 테스트 케이스만으로 가드레일 정책의 정확도를 높이려면 실패 신호에 따른 모드 선택이 핵심이다. 테스트 실패 신호가 '결과 불일치(기대 결과와 실제 결과가 다름)'라면 규칙 자체의 논리를 수정하는 Iterative Refinement를 선택하고, 신호가 `TRANSLATION_AMBIGUOUS`라면 변수 정의를 다듬는 Ambiguous Variable Refinement를 선택해야 한다.
