엔터프라이즈 리더들과 나누는 모든 대화에서 저는 같은 이야기를 듣습니다. 에이전트에게 더 많은 일을 시키고 싶지만, 항상 제대로 해낼 것이라고 신뢰하지는 못한다는 것입니다.
그건 당연합니다. 에이전트를 유용하게 만드는 창의성과 자율성이 동시에 신뢰하기 어렵게 만듭니다. 에이전트에 작업을 맡기면 개발자가 미리 스크립트로 정해 놓지 않은 도구를 선택하고 단계를 배열하며 자신만의 경로로 작업을 완료합니다. 같은 작업을 두 번 실행하면 매번 다른 경로를 택할 수도 있습니다. 오늘 통과한 테스트는 내일 에이전트가 무엇을 하는지 거의 알려주지 못합니다.
흔한 해답은 사람이 루프에 들어가 에이전트가 하는 모든 일을 승인하는 것입니다. 이는 소규모에서는 통하지만, 에이전트가 더 많은 업무를 맡게 되면 인간의 승인 요청이 쌓이고 검토 피로가 시작됩니다. 모든 것을 확인하라는 요청을 받은 사람들은 정말 중요한 것을 놓치게 됩니다. 신중함이 병목이 되고, 훨씬 더 많은 것을 해낼 수 있는 에이전트들은 더 큰 영향을 줄 수 있는 가치 있는 업무를 앞두고 놀고 있게 됩니다.
해결책은 행동을 검증할 수 있을 때 에이전트가 자율적으로 행동하도록 하고, 필요한 의사 결정은 인간의 판단에 맡기는 것입니다. 금융 거래처럼 위험도가 높은 업무를 에이전트가 맡게 되면 잘못된 행동의 피해는 점점 커집니다. 조직은 아무도 지켜보고 있지 않을 때에도 에이전트가 설정된 한도 내에 머무를 것이라는 확신을 가지고 중요한 업무를 AI 에이전트에 맡길 수 있어야 합니다. 그 확신은 만들어져야 합니다.
콘텐츠 필터링, 테스트, 모니터링은 각각 중요한 목적을 수행하지만, 이 기능들 중 어느 하나만으로는 에이전트가 다음 실행에서 올바르게 행동할 것을 보장할 수 없습니다. 신뢰는 서로를 강화하는 독립적인 계층에서 나옵니다. 이는 업계가 Defense in Depth라는 이름으로 20년간 실천해 온 바로 그 계층화 원칙이, 새로운 목적으로 전환된 것입니다. Defense in Depth가 잘못될 수 있는 것을 제한한다면, 이 방식은 안전하게 허용할 수 있는 범위를 확장합니다. AWS는 이를 Trust in Depth라고 부릅니다.
Trust in Depth: 검증할 수 있는 신뢰
신뢰는 에이전트의 라이프사이클 전반의 여러 시점에 걸쳐 일련의 질문에 답함으로써 구축됩니다:
- Scope(범위 지정), 실행 전: 이 에이전트는 무엇을 위한 것이며, 그 작업에 어떤 기능이 필요하고, 절대 해서는 안 되는 일은 무엇인가?
- Know(파악), 배포 시: 누가 승인했으며, 어떤 신원을 가지고 있는가? 그리고 귀하를 대신해 행동하는 모든 에이전트를 추적할 수 있는가?
- Bound(경계 설정), 실행 중: 에이전트의 행동이 설정한 한도 내에 머무르는가? 그리고 여전히 업무를 수행할 수 있는가?
- Observe(관찰), 각 실행 후: 에이전트가 무엇을 했고 왜 그랬는지 재구성할 수 있는가? 그리고 그로부터 배울 수 있는가?
이러한 질문들 가운데 일부 요구 사항은 정확한 규칙으로 표현할 수 있지만, 다른 것들은 판단을 필요로 합니다. 회사는 매니저만 접근 권한을 승인할 수 있다거나, 직원의 로그인이 차단되기 전에는 사서함을 공유할 수 없다는 규칙을 요구할 수 있습니다. 반면 친근한 어조를 유지하거나 민감한 상황을 적절히 처리하는 것과 같은 기대치는 맥락과 인간의 판단에 의존합니다.
정확하게 정의된 규칙의 경우, 테스트는 예상되는 사례에서 통제가 작동하는지 보여주지만, 에이전트는 예상하지 못한 경로를 택합니다. 더 나아가는 기술은 자동 추론(automated reasoning), 즉 규칙이 모든 가능한 사례에서 성립하는지 검사하는 수학적 논리입니다. 이는 시스템과 그 가정에 대한 정확한 기술이 다루는 모든 경로에서 규칙이 성립함을 입증하거나, 실패하는 정확한 사례를 밝혀낼 수 있습니다. 그 결과는 증명이며, 그 증명은 그 뒤에 있는 규칙과 가정만큼만 좋습니다. 그렇기 때문에 가장 어려운 작업은 에이전트가 실행되기 전에 이루어집니다.
AWS는 10년 넘게 프로덕션 환경에서 자동화된 추론을 운영해 왔습니다, 초당 2.1십억 회 이상의 요청을 처리하는 Identity and Access Management(IAM)부터 AWS Nitro Hypervisor, Amazon S3 Block Public Access, VPC Reachability Analyzer 같은 핵심 시스템에 이르기까지 적용되었습니다. 이제 우리는 이를 에이전트에 적용하고자 합니다. 에이전트의 규칙을 정확하게 서술할 수 있는 곳이라면 어디서든 자동 추론이 그 규칙을 검증할 수 있습니다.
그러나 모든 규칙을 정확하게 표현할 수 있는 것은 아닙니다. "매니저만 접근 권한을 승인할 수 있다"는 증명할 수 있습니다. "친근한 어조를 유지하라"는 증명할 수 없습니다. 증명이 적용되지 않는 곳에서는 에이전트의 접근과 행동을 제한하고, 그 행동을 평가하며, 진정한 모호성은 사람에게 보내 판단하게 하십시오. 관련 규칙이 강제되고 있음이 확인되고, 에이전트가 해당 작업에서 안정적으로 수행하며, 실패를 감지하고 처리할 수 있음이 확립되면 더 많은 자율성을 부여하십시오.
다음은 각 Trust in Depth 계층이 요구하는 것과 AWS가 그 답을 찾도록 돕는 방법입니다.
에이전트를 업무에 필요한 범위로만 지정하십시오
신뢰는 에이전트가 실행되기 전에 시작되며, 가장 많은 노력을 투자해야 할 부분이 바로 여기입니다. 이 단계에서 발견된 문제는 수정 비용이 저렴합니다. 범위 지정(scoping)이란 에이전트가 담당할 업무, 에이전트가 접근할 수 있는 도구·데이터·서비스, 준수해야 할 규칙, 그리고 사람에게 남겨둘 의사 결정을 정하는 것을 의미합니다.
"고객의 문제를 해결하라"는 무엇을 달성해야 하는지 말해줄 뿐, 에이전트가 그것을 달성하기 위해 어떻게 행동할 수 있는지는 말해주지 않습니다. 에이전트는 여전히 무엇을 볼 수 있고, 무엇을 할 수 있으며, 언제 멈추고 물어야 하는지에 대한 제한이 필요합니다. 업무에 필요한 접근 권한만 부여하고, 그 이상은 주지 마십시오. 누구도 의도적으로 부여하지 않은 기능, 즉 도구나 역할에 묶여 따라오는 기능을 주의하십시오. 한 작업을 위해 관리자 역할을 부여하면 에이전트가 전체 환경에 걸친 권한을 상속받을 수 있습니다.
스코핑(범위 설정)은 빌드 단계에서, 즉 에이전트를 정의하는 방식에서 시작됩니다. Kiro는(는) 에이전트 빌드 단계에 엄격함과 성숙한 엔지니어링 관행을 도입하는 에이전트코딩(코딩) 시스템입니다. Kiro는 상위 수준의 의도를 구조화되고 사양 기반의 요구사항으로 변환하고, 자동화된 추론을 사용하여 코드가 작성되기 전에 모순, 모호성, 누락된 부분을 드러냅니다. Kiro는 또한 속성 기반 테스트를 도출하여 광범위한 입력 범위에서 구현이 해당 요구사항을 충족하는지 검증함으로써 탐지하기 어려운 버그를 잡아냅니다. Strands 는(은) 에이전트의 모델, 지침, 도구를 정의하기 위한 오픈소스 툴킷과 이를 운영하기 위한 관리형 런타임을 제공합니다. 어떤 프레임워크를 선택하든, 에이전트의 작업과 그 경계를 정의할 책임은 동일합니다.
다음 단계는 이러한 경계를 에이전트에게 요구할 수 있는 규칙으로 전환하는 것입니다. Amazon Bedrock AgentCore 는(는) 에이전트를 안전하게 확장하기 위한 거버넌스 제어를 제공하고 에이전트가 수행하는 작업을 거버넌스합니다. Bedrock AgentCore의 Policies를 사용하면 에이전트가 접근할 수 있는 도구, API, 데이터를 일반 언어로 기술할 수 있으며, 자동화된 추론이 정책이 발효되기 전에 과도한 권한을 부여하는 규칙과 같은 누락된 부분을 잡아내고, 규칙이 결코 충족될 수 없게 만드는 모순이 있는지 검사합니다.
에이전트의 범위를 설정하는 것이 가장 어려운 부분입니다. 인간의 의도를 지속적이고 강제 가능한 정책으로 전환하려면 정확성과 완전성이 필요하기 때문입니다. 그러나 이것이 가장 큰 성과를 내는 부분이기도 합니다. 여기서 설정한 내용을 기반으로 모든 것이 구축되며, 정책이 정교할수록 에이전트가 스스로 더 안전하게 수행할 수 있는 작업이 많아집니다.
당신을 대신해 행동하는 모든 에이전트와 그 권한의 근거를 파악하십시오
볼 수 없는 것은 거버넌스할 수 없습니다. 팀들은 누구도 추적할 수 없을 만큼 빠르게 에이전트를 만들어내고 있으며, 아무도 모르는 에이전트는 아무도 통제하지 못하는 에이전트입니다. 모든 에이전트는 자신의 고유한 신원이 필요하며, 행동할 때마다 검증되어야 합니다. 어떤 행동도 고아 상태로 남아서는 안 됩니다. 문제가 발생했을 때 어떤 에이전트가 무엇을 했는지, 누가 그것을 승인했는지 알 수 있어야 합니다.
AWS Agent Registry 는(은) 조직 전체의 에이전트, Model Context Protocol (MCP) 서버, 도구, 스킬에 대한 관리형 승인 카탈로그를 제공합니다. 관리자는 승인 워크플로우를 사용하여 검색 가능해지는 항목을 통제하고 보안, 컴플라이언스, 품질 기준을 더 이상 충족하지 못하는 항목을 제거합니다. 사람과 에이전트 모두 기존에 있는 것을 재구축하는 대신 찾아 재사용할 수 있습니다. 하지만 카탈로그는 존재하는 것만 알려줍니다. 에이전트들이 파악되면 AgentCore가 각 에이전트에게 고유한 신원을 발급하고 모든 요청에서 이를 검증하여, 모든 행동이 알려진 권한 하에서 작동하는 특정 에이전트로 추적될 수 있도록 합니다. 이것이 바로 당신을 대신해 행동하는 모든 에이전트를 파악하는 방법입니다.
에이전트가 말하고 행동하는 것을, 설정한 한도 내에서 제한하십시오
경계를 설정하는 것이 중요한 이유는, 에이전트가 승인한 10 단계를 수행하면서도 아무도 의도하지 않은 결과에 도달할 수 있기 때문입니다. 민감한 데이터를 노출하거나, 주제를 벗어나거나, 정책이 금지하는 방식으로 허용된 행동들을 결합할 수 있습니다. 한도는 양방향으로 실패할 수 있습니다. 너무 느슨하면 에이전트가 해서는 안 되는 일을 할 수 있습니다. 너무 엄격하면 아예 제 역할을 하지 못합니다. 따라서 에이전트가 작업을 수행하는 방식은 스스로 선택하게 하되, 자신의 한도를 스스로 집행하도록 의존해서는 안 됩니다. 그 한도는 에이전트의 경계를 정의하는 것이며, 에이전트를 둘러싼 환경에 속해 결정론적으로 집행되고, 한 번에 한 단계씩이 아니라 행동의 전체 시퀀스에 걸쳐 평가되어야 합니다.
여기서 Scope 단계에서 정의한 정책이 발효됩니다. Policy in AgentCore 는(은) AgentCore Gateway를(을) 통해 라우팅되는 모든 도구 호출에서 이를 집행합니다. AgentCore Gateway는 에이전트, 도구, 모델을 위한 보안 진입점입니다. 집행이 에이전트의 추론 외부에 위치하기 때문에, 에이전트에 버그가 있거나 조작되었거나 프롬프트 인젝션을 받았을 때도 동일한 검사가 유지됩니다. 에이전트는 자신이 실행하지 않는 제어를 끌 수 없습니다. 권한이 고정되어 있을 필요도 없습니다. 작업의 위험도는 진행됨에 따라 변하기 때문에, temporal policies 는(은) 세션에서 이미 발생한 일을 가중 평가하고 작업이 계속됨에 따라 권한을 조정합니다. Amazon Bedrock Guardrails 는(은) 에이전트가 말하는 내용과 에이전트에게 전달되는 내용을 거버넌스합니다. 유해하거나 주제를 벗어난 콘텐츠를 필터링하고 민감한 데이터를 편집(마스킹)합니다. Automated Reasoning checks 는(는) 한 걸음 더 나아가, 응답이 모델의 해석이 아니라 설정한 정책과 일치함을 증명합니다.
경계는 또한 에이전트가 애초에 접근할 수 있는 범위, 즉 어떤 파일을 건드릴 수 있는지, 어떤 서비스를 호출할 수 있는지, 어떤 자격 증명을 사용할 수 있는지를 규제합니다. Strands Box는(은) 오픈소스 샌드박스로, 에이전트의 지침 외부에서 이러한 경계를 집행하여, 에이전트가 실제 도구와 데이터로 작업하면서도 허용된 것에만 접근하도록 합니다. 동일한 경계가 개발자의 첫 로컬 세션부터 프로덕션까지 유지되므로, 에이전트는 개발 환경에서 할 수 없었던 일을 프로덕션에서 할 수 없습니다.
에이전트가 한 일을 관찰한 후 개선하십시오
범위 지정, 식별, 경계가 모두 갖춰져 있더라도 에이전트는 밀리초 단위로 응답할 수 있고, 오류 없이 모든 대시보드가 초록불인 상태에서도 여전히 잘못된 일을 할 수 있습니다. 잘못된 정보를 검색했거나, 잘못된 도구를 선택했거나, 아무도 예상하지 못한 경로를 따랐을 수 있습니다. 건강한 시스템이 성공적인 작업과 동일한 것은 아닙니다. 이 둘을 구별하려면 에이전트가 실제로 무엇을 했는지 재구성해야 합니다. 즉, 수신한 컨텍스트, 호출한 도구, 적용된 정책 결정, 그리고 그 결과를 말입니다. 배포 전 테스트는 여전히 필수적입니다. 프로덕션은 실제 조건에서의 동작에 대한 증거를 추가하며, 운영자에게 조사하고 개입하며 개선하는 데 필요한 것을 제공합니다.
Amazon CloudWatch Omni 지속적인 관찰을 위해 설계되었습니다. 모든 흔적을 포착하고 모델 호출부터 도구 호출까지 에이전트가 거친 각 단계를 팀이 조사할 수 있는 타임라인으로 펼쳐 보여줍니다. 내장된 평가기는 정확성, 충실도, 에이전트가 올바른 도구를 선택했는지 여부 등 표준 모니터링이 놓치는 품질 기준으로 에이전트의 응답을 채점합니다. 그리고 에이전트가 잘못된 흔적은 수정 사항을 테스트하는 데이터셋이 되어, 에이전트 운영과 개선이 동일한 증거에 기반하게 됩니다.
실제로 신뢰의 깊이(Trust in Depth)가 어떤 모습인지
한 관리자가 회사를 떠나는 계정 관리자인 Sam의 퇴사 처리를 헬프데스크 상담원에게 요청합니다. 상담원은 Sam의 접근 권한을 제거하고, 그의 사서함을 후임자에게 이전하며, 회사가 더 이상 필요로 하지 않는 라이선스를 해제해야 합니다. 하지만 Sam의 이메일에는 고객 분쟁에 필요한 증거가 포함되어 있을 수도 있습니다. 잘못된 순서로 처리하면 Sam이 퇴사한 후에도 접근 권한을 갖게 되거나 그 증거가 위험에 처할 수 있습니다. 보안, 메시징, 법무, 재무 각 부서의 요구 사항을 상담원이 따라야 하지만, 아무도 전체 워크플로를 스크립트로 작성해 준 적은 없습니다.
이 순서를 지배하는 두 가지 규칙이 있다. Sam의 로그인은 그의 사서함이 후임자에게 전환되고 공유되기 전에 차단되어야 한다. 이메일 라이선스를 변경하기 전에 에이전트는 법적 보존, 즉 분쟁을 위해 기록을 보존해야 하는 요구 사항을 확인해야 하며, 해당 변경이 그 기록들을 보호 상태로 유지하는지 확인해야 한다.
범위. 에이전트가 실행되기 전에 팀은 이러한 규칙을 AgentCore에 정책(policy)으로 작성합니다. 각 정책은 다음 단계가 실행되기 전에 전제 조건 단계가 Sam의 계정에 대해 이미 성공했음을 요구합니다. 에이전트에는 정확히 여섯 가지 도구가 부여됩니다: 로그인 차단, 법적 보존(legal hold) 여부 확인, 보존 설정, 사서함 변환, 후임자에게 접근 권한 부여, 라이선스 변경입니다. 계정을 삭제하는 도구는 부여되지 않는데, 공유 사서함이 계정이 유지되기를 필요로 하기 때문입니다.
알아보기. 에이전트는 자체 식별 정보를 가지므로, Sam의 계정에 대한 모든 변경 사항은 그 에이전트로 거슬러 올라가 추적될 수 있습니다.
바운드(Bound). 에이전트는 Sam의 사서함을 후임자인 Priya용 공유 사서함으로 전환하려고 시도합니다. AgentCore 게이트웨이에서 시행되는 AgentCore 정책이 이 호출을 차단합니다: Sam은 여전히 로그인할 수 있고, 사서함을 전환해도 그의 비밀번호는 바뀌지 않으므로 기존 자격 증명으로 여전히 열 수 있기 때문입니다. 에이전트는 Sam의 로그인을 차단한 후 사서함을 전환하고 Priya에게 접근 권한을 부여합니다. 다음으로 관리자의 실제 요청인 라이선스 회수로 넘어가지만, 아무도 법무팀의 보존 목록을 확인하지 않았기 때문에 게이트웨이가 이 역시 차단합니다. 에이전트는 확인한 결과 법무팀이 고객 분쟁과 관련하여 Sam의 이메일을 보존할 것을 요구하고 있음을 발견합니다. 에이전트는 보존 조치를 적용하고 그것이 효력이 있음을 확인한 뒤, Sam의 라이선스를 해당 보호를 지원하는 라이선스로 변경합니다. 회사는 증거를 그대로 유지하면서 더 넓은 범위의 라이선스를 회수할 수 있습니다.
관찰하십시오. 모든 단계가 기록됩니다: 에이전트가 수행하려 했던 것, 규칙이 결정한 것, 보류(hold), 그리고 결과입니다.
에이전트는 사람이 모든 단계를 승인하지 않아도 작업을 완료했습니다. 에이전트의 권한이 변경할 수 있는 범위를 제한했고, 에이전트의 신원이 해당 변경 사항을 추적 가능하게 만들었으며, 정책이 필요한 안전장치가 마련되기 전에 에이전트가 작동하지 못하도록 차단했습니다. 기록된 단계를 통해 팀은 Sam의 접근이 차단되었는지, 후임자가 메일박스를 사용할 수 있는지, 그리고 요구되는 증거가 계속 보호되고 있는지 검증할 수 있었습니다.
에이전트를 신뢰할 수 있게 되면 가능해지는 것들
AWS는 이러한 계층들을 하나로 통합하여, 에이전트를 해당 업무에 맞게 범위를 지정하고, 어떤 에이전트가 사용자를 위해 작동하는지 알 수 있으며, 에이전트가 하는 일과 말하는 것에 경계를 설정하고, 에이전트가 수행한 일을 확인하고 시간이 지남에 따라 개선할 수 있으며, 규칙을 정확하게 명시할 수 있는 곳이라면 어디서든 그 규칙이 유지됨을 입증할 수 있게 합니다. 어떤 단일 계층도 그 신뢰를 스스로 얻을 수 없습니다. 이 계층들이 함께 신뢰의 다층 방어(Trust in Depth)를 이루며, 이것이 유능한 에이전트를 중요한 작업을 수행할 수 있도록 신뢰받는 에이전트로 만드는 것입니다.
경계선은 사용자가 그립니다: 에이전트가 스스로 할 수 있는 일, 사람의 승인이 필요한 일, 그리고 에이전트가 반드시 멈춰야 하는 시점입니다. 이를 통해 사용자의 사람들은 사람만이 할 수 있는 일에 집중할 수 있습니다: 어려운 판단을 저울질하고, 모호한 영역을 해결하며, 사용자가 인간의 손에 맡기기로 선택한 결정을 소유하는 것입니다. 에이전트가 그 경계선 안에 머무른다는 증거가 쌓이면, 책임 범위를 넓히거나 좁힐 수 있습니다.
AWS에서는 에이전트를 배포하는 모든 조직이, 어떤 플랫폼에서든, 이 네 가지 질문에 증거를 바탕으로, 그리고 적용되는 곳에서는 증명을 바탕으로 답할 수 있어야 한다고 믿습니다. 이것이 AWS가 고객을 위해 구축하고 있는 기준이자, 업계 전체가 스스로에게 요구하도록 초대하는 기준입니다. 다층 방어(Defense in Depth)는 시스템을 세계와 연결하는 것을 안전하게 만들었습니다. 신뢰의 다층 방어(Trust in Depth)는 에이전트가 그 안에서 자율적으로 작동하는 것을 안전하게 만듭니다.
하나의 에이전트, 하나의 워크플로, 그리고 증명할 수 있는 하나의 경계부터 시작하십시오. 그런 다음 신뢰가 쌓이면 확장하십시오.
실행 가능한 규칙 구현을 시작하려면 다음을 살펴보십시오 Amazon Bedrock AgentCore의 Policy 및 Amazon Bedrock Guardrails의 Automated Reasoning checks.