Amazon Bedrock AgentCore를 붙이기 전, 사내 에이전트 권한표부터 만들어야 합니다

사내 AI 에이전트 PoC는 "무슨 모델을 쓸까"보다 "누가 어떤 도구와 데이터에 접근할 수 있나"를 먼저 표로 고정해야 운영 단계로 넘어갈 수 있습니다.

들어가며 — 독자가 지금 이 문제를 검색하는 이유

AI 에이전트를 사내 업무에 붙이려는 팀이 처음 부딪히는 질문은 대개 모델 성능입니다.

"어떤 LLM이 더 똑똑한가?"

"툴 호출을 얼마나 잘하나?"

"업무 자동화를 어디까지 맡길 수 있나?"

그런데 작은 PoC를 넘어서려는 순간, 질문은 달라집니다.

에이전트가 사내 문서를 읽어도 되는가. 외부 SaaS에 대신 로그인해도 되는가. 어떤 API를 호출할 수 있는가. 실패했을 때 누가 어떤 로그를 볼 수 있는가.

AWS가 2025년 7월 16일 발표한 Amazon Bedrock AgentCore preview는 이 질문을 꽤 직접적으로 다룹니다. AWS는 AgentCore를 "AI 에이전트를 안전하게 배포하고 운영하기 위한" 서비스로 소개합니다. 공식 문서에서도 Identity, Gateway, Runtime IAM permissions, Observability를 주요 구성요소로 설명합니다.

출처: AWS News Blog, Amazon Bedrock AgentCore 개발자 가이드

다만 작성 시점 기준으로 AgentCore의 GA 여부와 리전별 제공 범위는 확인 필요입니다. 따라서 이 글은 "당장 모든 환경에서 쓸 수 있다"는 도입 안내가 아닙니다. AgentCore 문서를 기준으로 사내 에이전트 운영 권한표를 어떻게 설계할지 정리한 가이드에 가깝습니다.

에이전트 권한은 사람 계정이 아니라 실행 역할부터 봐야 합니다

사내 자동화에서 흔한 실수는 에이전트를 "사용자 대신 일하는 챗봇" 정도로 보는 것입니다. 하지만 운영 관점에서는 에이전트도 하나의 실행 주체입니다.

AWS 문서에 따르면 Bedrock AgentCore Runtime은 IAM 권한을 사용합니다. 즉, 에이전트가 런타임에서 무엇을 할 수 있는지 정하려면 먼저 실행 역할과 권한 범위를 정해야 합니다.

출처: AgentCore Runtime IAM permissions

그래서 권한표의 첫 열은 "사용자"가 아니라 "에이전트 실행 역할"이어야 합니다.

예를 들어 사내 리서치 요약 에이전트를 만든다고 가정해보겠습니다. 이 에이전트가 할 수 있는 일은 다음처럼 나눠야 합니다.

구분	권한표에 적어야 할 질문
실행 역할	이 에이전트는 어떤 IAM 역할로 실행되는가?
내부 데이터 접근	어떤 문서, 저장소, 데이터 소스에 접근할 수 있는가?
도구 호출	어떤 API나 도구를 호출할 수 있는가?
외부 서비스 인증	외부 SaaS 인증은 어떤 방식으로 연결되는가?
로그 조회	누가 실행 로그와 트레이스를 볼 수 있는가?
실패 대응	실패한 실행을 누가 재시도하거나 중단할 수 있는가?

이 표가 없으면 PoC는 빠르게 만들 수 있습니다. 대신 운영 전환 때 막힙니다. 보안팀은 접근 범위를 확인해야 하고, 현업은 결과를 신뢰할 수 있어야 하며, 운영자는 실패 원인을 추적할 수 있어야 하기 때문입니다.

Identity와 Gateway는 "연결 편의 기능"이 아니라 통제 지점입니다

AgentCore 문서에서 Identity는 에이전트가 사용자와 외부 리소스에 접근할 때 필요한 인증·인가 흐름과 관련됩니다.

출처: AgentCore Identity

Gateway는 에이전트가 도구와 리소스에 접근하는 경로를 관리하는 구성요소로 설명됩니다.

출처: AgentCore Gateway

여기서 중요한 점은 Identity와 Gateway를 "에이전트에 도구를 붙이는 기능" 정도로만 보면 안 된다는 것입니다. 운영 기준에서는 둘 다 통제 지점입니다.

에이전트가 외부 CRM, 문서 저장소, 사내 API를 호출한다고 해보겠습니다. 이때 권한표에는 최소한 다음 항목이 있어야 합니다.

항목	기록할 내용
연결 대상	에이전트가 호출할 외부 서비스 또는 내부 API
인증 방식	IAM, OAuth 등 어떤 방식으로 인증하는지
사용자 위임 여부	사용자 권한을 위임하는지, 에이전트 전용 권한인지
허용 작업	읽기, 생성, 수정, 삭제 중 무엇을 허용하는지
차단 작업	에이전트가 절대 수행하면 안 되는 작업
승인 필요 조건	사람 승인이 필요한 호출 조건
감사 로그	호출 기록이 어디에 남는지

특히 OAuth로 외부 서비스를 연결하는 경우에는 "로그인만 되면 끝"이 아닙니다. 어떤 scope를 허용할지, 토큰을 누가 관리할지, 실패나 철회가 발생했을 때 에이전트가 어떻게 반응할지까지 정해야 합니다.

이 권한표의 목적은 개발을 느리게 만드는 문서 작업이 아닙니다. 나중에 장애가 났을 때 "이 에이전트가 왜 그 데이터를 읽었나", "왜 그 API를 호출했나", "누가 승인했나"를 추적할 수 있게 만드는 것입니다.

Observability는 실행 후 분석이 아니라 배포 전 요구사항입니다

AgentCore 문서는 Observability를 통해 에이전트 실행을 모니터링하고 디버깅할 수 있다고 설명합니다.

출처: AgentCore Observability

운영에서 관찰성은 "로그를 남기자"로 끝나지 않습니다. 에이전트는 일반 API 서버보다 실행 경로가 복잡합니다. 모델 응답, 도구 호출, 외부 인증, 사용자 입력, 중간 판단이 한 흐름 안에 섞입니다.

그래서 배포 전에 최소한 다음 질문에는 답해야 합니다.

관찰 항목	확인 질문
실행 단위	에이전트 실행 1건을 어떤 ID로 추적하는가?
사용자 요청	원 요청과 후속 도구 호출을 연결할 수 있는가?
도구 호출	어떤 도구를 어떤 인자로 호출했는가?
인증 실패	외부 서비스 인증 실패를 구분해서 볼 수 있는가?
권한 거부	IAM 또는 OAuth 권한 문제를 식별할 수 있는가?
결과 검증	최종 응답이 어떤 근거와 호출 결과에서 나왔는가?
접근 권한	로그와 트레이스를 누가 볼 수 있는가?

작은 PoC에서는 "잘 됐다"가 충분해 보입니다. 하지만 사내 업무에 붙는 순간 "왜 그렇게 답했나"가 더 중요해집니다. 특히 에이전트가 문서 검색, 외부 API 호출, 업무 시스템 입력까지 한다면 실행 흔적은 결과물만큼 중요합니다.

바로 적용하는 체크리스트 또는 비교 기준

아래 표는 Amazon Bedrock AgentCore 기반 PoC를 검토할 때 사용할 수 있는 권한·도구 연결 점검표입니다. 실제 도입 전에는 AgentCore의 현재 GA 여부, 리전별 제공 범위, 조직의 AWS 계정 정책을 별도로 확인해야 합니다.

단계	점검 항목	작성 예시
1. 적용 업무 정의	에이전트가 만들 최종 결과물 하나를 정했는가?	"사내 문서 기반 리서치 요약 초안"
2. 실행 역할 정의	에이전트 런타임의 IAM 역할을 정했는가?	확인 필요
3. 데이터 접근 범위	읽을 수 있는 문서와 데이터 소스를 제한했는가?	특정 저장소 또는 특정 문서 집합
4. 도구 연결 방식	Gateway를 통해 연결할 도구 목록을 정했는가?	사내 검색 API, 외부 SaaS API 등
5. 인증 방식	IAM, OAuth 등 인증 방식을 구분했는가?	내부 AWS 리소스는 IAM, 외부 서비스는 OAuth 검토
6. 허용 작업	읽기·생성·수정·삭제 중 허용 범위를 나눴는가?	초기 PoC는 읽기 중심 권장
7. 사람 승인 조건	민감 작업에 승인 단계를 둘지 정했는가?	외부 전송, 삭제, 권한 변경은 승인 필요
8. 관찰성 범위	실행 로그, 도구 호출, 오류, 권한 거부를 추적할 수 있는가?	Observability 설정 확인
9. 로그 접근 권한	누가 로그와 트레이스를 볼 수 있는가?	개발자, 운영자, 보안 담당자 구분
10. 실패 대응	인증 실패, 권한 거부, 도구 호출 실패 시 처리 기준이 있는가?	재시도, 중단, 사람 확인 요청 구분

최소 적용 단계는 다음 순서가 안전합니다.

1. 에이전트가 만들 결과물 하나를 정합니다.

예: "사내 문서 5개를 바탕으로 회의 준비 요약 초안 작성"

2. 그 결과물을 만들기 위해 필요한 데이터와 도구만 나열합니다.

"있으면 좋은 도구"는 제외합니다.

3. 각 도구별 인증 방식을 구분합니다.

AgentCore 문서 기준으로 IAM 권한, Identity, Gateway의 역할을 나눠 봅니다.

4. 허용 작업과 금지 작업을 표로 씁니다.

읽기와 쓰기, 내부 조회와 외부 전송을 같은 권한으로 묶지 않습니다.

5. Observability에서 확인할 실행 흔적을 미리 정합니다.

실행 ID, 도구 호출, 인증 실패, 권한 거부, 최종 결과 근거를 추적할 수 있어야 합니다.

6. PoC 실행 후 권한표와 실제 로그를 대조합니다.

표에 없는 도구 호출이나 예상하지 못한 접근이 있으면 기능 확장보다 권한 설계를 먼저 고칩니다.

보안 주의사항도 분명히 해야 합니다.

• 외부 발송, 삭제, 권한 변경은 초기 PoC에서 자동 실행 대상으로 두지 않는 편이 안전합니다.
• OAuth 연결은 scope를 넓게 잡지 말고, 필요한 작업 단위로 제한해야 합니다.
• 로그에는 민감 데이터가 포함될 수 있으므로 로그 조회 권한도 별도로 제한해야 합니다.
• "개발자가 테스트하기 편한 권한"과 "운영에서 허용할 권한"은 다르게 봐야 합니다.
• AgentCore의 제공 상태와 리전 지원 범위는 작성 직전 공식 문서에서 확인해야 합니다.

마무리 + 생각해볼 질문 1개

Amazon Bedrock AgentCore를 보면 사내 AI 에이전트 운영의 기준이 어디로 가고 있는지 보입니다. 모델 선택만으로는 부족합니다. 실행 역할, 인증, 도구 연결, 관찰성, 실패 대응이 함께 설계되어야 합니다.

작은 PoC라도 권한표 없이 시작하면 데모는 빠르게 만들 수 있습니다. 하지만 운영 전환 시점에는 거의 반드시 같은 질문으로 돌아옵니다.

"이 에이전트는 정확히 무엇을 할 수 있고, 무엇을 하면 안 되는가?"

생각해볼 질문: 지금 만들고 있는 AI 에이전트의 권한을 오늘 표로 적는다면, "허용 작업"보다 "금지 작업"을 더 명확히 설명할 수 있나요?