Prove It, 3부: 자동 추론 구현을 위한 단계별 가이드

이 가이드에서는 기존 비즈니스 문서에서 자동 추론 정책을 생성하고, Amazon Bedrock Guardrails를 통해 배포하고, ApplyGuardRail을 사용하여 LLM 답변을 검증하고, 감사 추적을 구축하고, AgentCore Policy를 사용하여 AI 에이전트를 보호하는 방법을 알아봅니다. 이 프로세스를 사용하면 팀이 규정 준수 문서로 프로덕션 검증을 완료하기까지 단 30분밖에 걸리지 않습니다.

1부(‘‘아마도 맞을 것이다’는 충분하지 않은 이유’)에서는 Startup에 결정론적 검증이 필요한 이유에 대해 다루었습니다. 2부(‘형식 로직, Cedar 정책, 검증의 경제학’)에서는 검증 파이프라인과 그 바탕이 되는 수학 이론에 대해 설명했습니다. 이제 구축할 차례입니다.

시작하기 전에 무엇이 필요한가요?

시작하기 전에 다음이 준비되었는지 확인하세요.

• Amazon Bedrock 액세스 권한이 있는 AWS 계정. AWS Activate에 가입한 경우 여기에 사용할 크레딧을 이미 제공받았습니다.
• Python 3.9+(boto3 포함). MVP를 출시한 적이 있다면 이미 가지고 있습니다.
• 비즈니스 규칙을 설명하는 정책 문서(PDF, 마크다운 또는 일반 텍스트). 규정 준수 검토 또는 투자자 실사를 통과한 경우 이미 가지고 있습니다.

1단계: AR 정책 생성

가장 빠른 경로는 AWS Console을 이용하는 것입니다. Bedrock은 소스 문서를 형식 로직 규칙으로 자동 변환하므로, 형식 로직을 작성할 필요가 없습니다.

1. Bedrock 콘솔을 열고 왼쪽 사이드바의 자동 추론으로 이동합니다.
2. 새 정책을 생성합니다. 알아보기 쉬운 이름(예: mortgage-eligibility-policy)을 지정합니다.
3. 소스 문서를 업로드합니다. 비즈니스 규칙을 설명하는 PDF, Word 문서 또는 일반 텍스트 파일입니다. 핀테크 Startup의 경우 이 문서가 대출 기준 문서일 수 있습니다. 의료 분야에서는 중요한 임상 프로토콜일 수 있습니다.
4. 지침을 제공합니다. 정책에서 검증하는 내용을 설명하는 의도를 간략하게 작성하고, 2~3개의 질문과 답변 예를 포함합니다. 이는 시스템이 사용자가 정책과 상호 작용하는 방식을 이해하는 데 도움이 됩니다.

콘솔을 사용하지 않으려는 팀을 위해, 자연어로 형식화하는 과정을 안내하는 정책 생성용 대화형 인터페이스도 제공됩니다. 몇 가지 전제 조건(Kiro-CLI 포함)이 있지만 워크플로에서 콘솔이 완전히 배제할 수 있습니다.

의도 예:

이 정책은 모기지 자격 질문을 검증합니다. 사용자는 재무 세부 정보를 바탕으로 고객이 특정 유형의 모기지를 이용할 자격이 있는지 여부를 묻습니다.

Q&A 예:

Q: 한 고객이 3만 USD 계약금으로 35만 USD의 주택을 구매하려고 합니다. 일반 모기지를 받을 자격이 있나요?

A: 아니요. 일반 모기지를 받으려면 최소 20%의 계약금(35만 USD 구매 시 7만 USD)이 요구됩니다.

충실도 보고서 검토:

시스템은 문서를 처리한 후 두 가지 점수가 포함된 충실도 보고서를 생성합니다.

• 커버리지 점수(0.0~1.0): 정책에 제시된 소스 문서의 양
• 정확도 점수(0.0~1.0): 추출한 규칙이 문서의 의도와 일치하는 정도

이 보고서는 소스 문서의 정확한 설명을 바탕으로 추출된 특정 변수와 규칙도 보여줍니다. 이를 통해 시스템이 규칙을 제대로 이해했는지 확인할 수 있습니다.

애플리케이션의 실제 예시를 사용하여 변수 설명을 구체화합니다. 대표적인 질문을 테스트하고, 시스템에서 문항이 어떻게 변환되는지 살펴보고, 변환 결과가 의도와 다를 경우 설명을 수정합니다. 이는 정확도를 높이는 데 가장 큰 역할을 합니다. 가능하면 단위, 동의어, 변환 규칙, 도메인별 용어를 포함합니다. “대출자의 계약금 비율. 주택 구매 가격 대비 계약금의 백분율을 의미하며, 사용자가 USD 금액을 언급한 경우(downPayment/purchasePrice)*100을 사용하여 계산한다”와 같은 설명이 “대출자가 계약금으로 내는 금액”와 같은 단순한 설명보다 훨씬 나은 결과를 제공합니다.

이는 멀티 스프린트 엔지니어링 작업이 아닙니다. 기존 규정 준수 문서에서 실제 AR 정책이 적용되기까지는 30분이 걸립니다. 충실도 점수와 테스트 결과가 기대에 부합할 때까지 변수 설명을 반복하고 샘플 문항으로 테스트합니다.

API 경로(CI/CD 파이프라인에 유용)는 CreateAutomatedReasoningPolicy API 참조를 참조하세요. API에는 이름, 선택적 설명, 규칙, 변수, 사용자 지정 유형이 포함된 policyDefinition이 포함됩니다.

2단계: 가드레일에 배포

정책이 테스트를 잘 통과하면 프로덕션용으로 배포합니다.

변경 불가능한 버전을 저장합니다. 콘솔에서 ‘새 버전으로 저장’을 선택합니다. 이렇게 하면 번호가 매겨진 변경 불가능한 스냅샷(버전 1, 2, 3...)이 생성되므로, 초안을 계속 편집할 때 프로덕션 가드레일이 영향을 받지 않습니다. Startup이 빠르고 안전하게 배포하는 방법은 다음과 같습니다. 규정 준수 팀이 프로덕션 단계에서 버전 1을 검토하고 엔지니어링 팀은 초안에서 버전 2를 반복합니다. 배포가 중단되는 일은 없습니다. “배포할 때까지 정책을 건드리지 마세요”라는 상황도 발생하지 않습니다.

정책 버전을 게시한 후에는 런타임 검증 시에 사용할 수 있도록 가드레일에 연결합니다.

주요 세부 정보:

• policies는 객체가 아니라 정책 ARN 문자열의 배열(최대 2개)을 받습니다.
• confidenceThreshold(선택 사항, 0.0~1.0)는 번역 결과를 신뢰할 수 있다고 판단하기 위한 최소 일치 수준을 제어합니다. 낮은 값(0.3)을 설정하면 더 많은 결과를 더 빨리 발견할 수 있고, 높은 값(1.0)을 설정하면 엄격한 정확성에 최적화됩니다. 개발 중에는 낮은 값으로 시작했다가 프로덕션에서는 엄격하게 조정합니다.
• crossRegionConfig는 AR 검사에 필요하며, 가드레일 평가를 위한 리전 간 추론을 지원합니다. 지역에 맞는 프로필을 사용해야 합니다(예: 미국의 경우 us.guardrail.v 1:0, EU의 경우 eu.guardrail.v 1:0).
• blockedInputMessaging과 blockedOutputsMessaging은 필수입니다. 다른 가드레일 구성 요소(AR 아님)가 콘텐츠를 차단할 때 표시되는 대체 메시지입니다.
• 프로덕션에는 ARN에 번호가 매겨진 버전(:1)을 사용합니다. DRAFT는 개발용으로만 사용합니다.

3단계: ApplyGuardrail을 사용하여 LLM 답변 검증

권장 통합 패턴은 ApplyGuardrail 독립 실행형 API입니다. 이를 통해 어떤 콘텐츠를 언제 검증할지 완벽하게 제어할 수 있으며, 이는 AWS 설명서에서 AR 검사에 대해 명시적으로 권장하는 접근 방식입니다.

다음은 기존 추론 파이프라인에 추가되는 최소 통합의 예시입니다.

LLM이 답변을 생성한 후 사용자에게 제공하기 전에 다음을 직접 호출합니다.

중요: AR 검사는 감지 모드로 작동하며, 조사 결과와 피드백을 반환합니다. 답변을 자동으로 차단하거나 다시 작성하지는 않습니다. 애플리케이션이 조사 결과를 살펴보고 어떻게 할지 결정합니다.

4단계: 조사 결과 처리

각 조사 결과는 정확히 하나의 키가 있는 유니온 유형입니다. 구문 분석하고 실행하는 방법은 다음과 같습니다.

표준 수정 패턴은 검증-재작성 루프입니다. 즉, 답변을 검증하고, 위반 사항을 모델에 다시 피드로 제공하고, 답변을 재생성하고, 재검증합니다. 답변이 유효하거나 재시도 한도에 도달할 때까지 이 과정을 반복합니다.

사용자는 재작성 루프를 볼 수 없습니다. 사용자에게는 첫 시도에 올바른 답변이 제시됩니다. 반복 작업은 백그라운드에서 몇 밀리초 만에 이루어집니다.

5단계: 감사 추적 구축

모든 검증 반복은 기록되어야 합니다. 기업 고객이 SOC 2 증거를 요청하거나 규제 기관이 특정 결정을 어떻게 검증했는지 물으면 JSON 로그를 가져옵니다. 모든 검증에는 타임스탬프가 찍히므로 추적이 가능합니다.

이 로그는 규정 준수 아티팩트가 됩니다. 사용자가 요청한 내용, LLM이 생성한 내용, AR에서 찾은 내용, 애플리케이션에서 수행한 작업을 보여 줍니다. SOC 2, HIPAA 규정 준수 또는 기업 판매를 추구하는 Startup에게 이 감사 추적은 선택 사항이 아닙니다. 이는 시스템이 문서화된 대로 작동한다는 증거입니다.

6단계: AgentCore Policy로 에이전트 보호

Startup이 단순한 챗봇을 넘어 에이전트 워크플로(AI가 일정을 예약하거나, 환불을 처리하거나, 데이터베이스를 쿼리하거나, 이메일을 전송)로 발전했다면, 에이전트가 말하는 내용뿐만 아니라 무엇을 수행할 수 있는지에 대한 한계도 설정해야 합니다.

Amazon BedRock AgentCore의 정책은 Cedar를 사용하여 이러한 경계를 정의합니다. 예를 들어 진료 예약 에이전트의 경우, 액세스할 수 있는 환자 기록을 제한하고, 예약 시간을 업무 시간 이내로 제한하고, 관리자의 승인 없이 기준액을 초과하여 환불을 처리하지 못하도록 하는 정책이 필요합니다. LOG_ONLY 모드로 시작하여 에이전트가 아무것도 차단하지 않고 어떻게 하는지 관찰합니다. 그런 다음 정책을 신뢰할 수 있으면 프로덕션용 ENFORCE 모드로 전환합니다.

게이트웨이는 에이전트와 해당 도구 사이의 적용 계층입니다. 모든 도구 간접 호출은 게이트웨이를 통과하며, 게이트웨이에서는 요청이 대상에 도달하기 전에 Cedar 정책이 평가됩니다. 이를 통해 정책이 결정론적으로, 에이전트의 추론과 독립적으로 적용됩니다. 에이전트는 게이트웨이를 우회하거나 무시하거나 지나칠 수 없습니다.

AgentCore CLI를 사용하여 게이트웨이 및 정책 엔진을 설정합니다.

Cedar 정책을 작성하여 정책 엔진에 연결합니다. 다음 예는 진료 예약 에이전트에 대한 예시 정책을 보여줍니다. 실제로 작업 이름은 게이트웨이 대상 및 도구 스키마(예: HealthTarget__get_patient_record)에서 자동으로 생성되며 리소스는 특정 게이트웨이 ARN을 참조해야 합니다.

Cedar는 기본적으로 거부하는 방식으로 작동합니다. 즉, 명시적인 허용 정책에서 허용하지 않는 한 모든 에이전트-도구 상호 작용이 차단됩니다. 허용 정책은 에이전트가 어떤 도구를 어떤 조건에서 직접 호출할 수 있는지를 정의합니다. 아래의 금지 정책은 예외를 명시하여 특정 시나리오를 차단합니다. 보다 광범위한 허용 정책이 존재하더라도 특정 상황에서는 요청을 차단합니다.

이 파일을 healthcare_policy.cedar로 저장한 다음 정책 엔진에 연결합니다.

또는 자연어로 규칙을 설명하고 시스템이 Cedar를 생성하도록 할 수도 있습니다(게이트웨이를 먼저 배포해야 함).

자동 추론은 작성 시 정책을 검증하여, 배포하기 전에 지나치게 허용적이거나 지나치게 제한적이거나 비효율적인 규칙을 찾아냅니다.

규제 대상 Startup에 중요한 주요 속성:

• 기본 거부: 어떤 정책도 작업을 명시적으로 허용하지 않는 경우 해당 작업이 차단됩니다.
• 항상 금지 우선: 강제 차단 규칙은 다른 어떤 정책으로도 재정의할 수 없습니다.
• 결정론적 적용: 에이전트의 추론 과정 외부에 있는 게이트웨이 경계에서 작동합니다. 따라서 프롬프트 인젝션, 할루시네이션 또는 소프트웨어 버그로도 우회할 수 없습니다.

처음에는 LOG_ONLY 모드로 시작해 제품을 중단시키지 않고 에이전트가 실제로 무엇을 하고 있는지 확인합니다. 로그에는 Gateway로 들어오는 각 요청에 어떤 정책이 적용되었는지, 정책 결정 결과가 허용인지 거부인지, 도구 드리프트가 발생한 경우 불일치 정책이 기록됩니다. 이러한 로그를 검토하고 정책을 개선합니다. 확신이 들면 ENFORCE 모드로 전환합니다. 이렇게 하면 사용자에게 영향을 미치지 않으면서 프로토타입에서 프로덕션 환경으로 전환할 수 있습니다.

배포 스크립트 및 테스트 하네스를 포함한 전체 예시는 GitHub의 Amazon Bedrock AgentCore 샘플을 참조하세요.

자동 추론을 배포한 후에는 어떻게 되나요?

자동 추론 검사와 AgentCore Policy를 실행하기 시작하면 단순한 오류 방지보다 더 가치 있는, 단일 정보 소스라는 것을 얻게 됩니다.

AR 정책은 형식 로직으로 인코딩된 비즈니스 규칙입니다. 새로운 규정, 업데이트된 대출 기준, 개정된 임상 프로토콜 등의 규칙이 변경되어 소스 문서를 업데이트하고 정책을 재생성하면, 스택의 모든 AI 시스템이 즉시 새 규칙을 따릅니다. 프롬프트 엔지니어링을 업데이트할 필요가 없습니다. 모델을 다시 훈련한 필요도 없습니다. 누군가가 시스템 프롬프트를 수정했기를 기대할 필요도 없습니다.

이를 통해 드리프트 버그라는 문제 범주 자체를 없앨 수 있습니다. 문서와 AI의 동작이 수학적으로 연결되므로 서로 불일치한 상태가 될 수 없습니다.

가드레일은 모델에 구애받지 않으므로, 파운데이션 모델을 전환해도 검증 계층은 동일하게 유지됩니다. Claude의 응답을 검증하는 데 사용되는 것과 동일한 AR 정책이 Amazon Nova의 응답을 검증하는 데에도 사용되며, 규칙은 모델이 아니라 비즈니스 로직에 따라 달라집니다.

이 통합은 Bedrock 에코시스템 전반으로 확장됩니다. AR 정책은 검색 증강 생성을 위한 지식 베이스, 다단계 워크플로를 위한 AgentCore 에이전트, 다양한 파운데이션 모델 전반에 걸쳐 활용할 수 있습니다. 구축은 포인트 솔루션이 아니라 플랫폼을 기반으로 합니다.

자세히 알아보기

• 자동 추론 검사 설명서
• AR 개념(변수, 규칙, 조사 결과)
• 통합 가이드(ApplyGuardrail 패턴)
• AgentCore Policy 설명서
• GitHub의 AgentCore 샘플
• AWS의 입증할 수 있는 보안 개요
• 자동 추론이란
• Cedar 언어(CNCF)

이것으로 Startup을 위한 AR 시리즈를 마칩니다.

Prove It 시리즈 전반에 걸쳐 주제는 하나였습니다. AI를 기반으로 하는 Startup에는 확률론적 보호 장치뿐만 아니라 결정론적 수학적 검증이 필요하다는 것입니다.

1부에서는 Startup에 신뢰 문제가 존재하는 이유와 어떻게 AWS가 수십 년간 형식적인 방법을 다룬 결과로 Bedrock Guardrails과 AgentCore Policy가 탄생하게 되었는지를 살펴보았습니다.

2부에서는 형식 로직, 검증 파이프라인, 경제학에 대해 살펴보았습니다. 이 게시물에서는 기존 규정 준수 문서에서 프로덕션에 바로 사용할 수 있는 검증된 AI를 만들어내기까지, 전체 구현 경로를 살펴보았습니다.

Startup이 AI 시대에 성공을 거두려면 단순히 지능적인 시스템을 구축하는 것이 아니라, 시스템의 정확성을 증명할 수 있는 시스템을 구축해야 합니다. 자동 추론과 AgentCore Policy는 오늘날 대부분의 기업이 보유하고 있는 정책 문서와 규정 준수 문서를 활용해 이를 가능케 합니다. 이제 남은 질문은 하나뿐입니다. 바로 지금 시작할 것인지, 아니면 첫 번째 인시던트가 발생한 후 어쩔 수 없이 시작하게 될 것인지입니다.