Scaling cloud migrations with agentic AI on Amazon Bedrock AgentCore

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

AWS Professional Services가 구축한 Amazon Bedrock AgentCore 기반 4개 AI 에이전트 프레임워크는 300개가 넘는 애플리케이션의 마이그레이션 생애주기를 연결하고, 내부 프로젝트 추적 데이터 기준 IaC 개발 시간을 애플리케이션당 3~4주에서 수분으로 단축했다.

📌 핵심 요약

• 대규모 데이터센터 이전에서는 애플리케이션별로 수주가 걸리는 수동 탐색, 3~4주가 필요한 반복적인 IaC 개발, 마이그레이션 후의 대응형 운영이 핵심 병목으로 나타났으며, 300개가 넘는 애플리케이션과 고정된 회계연도 기한이 이 문제를 확대했다.
• 프레임워크는 탐색과 목표 아키텍처 정의를 담당하는 Intake Agent, 보안 모범 사례에 맞는 코드를 생성하는 IaC Agent, 포트폴리오 보고와 거버넌스를 담당하는 Migration Intelligence and Governance Agent, 선제적 운영을 담당하는 SRE Agent로 구성된다.
• 각 에이전트는 Strands Agents SDK로 정의되고 Amazon Bedrock AgentCore 런타임에서 실행되며, Amazon Bedrock 기반 모델, AgentCore Gateway·Identity·Memory를 통해 추론, 도구 호출 인증, 세션 상태와 공유 컨텍스트 보존을 처리한다.
• Intake Agent의 목표 AWS 아키텍처와 의존성 매핑은 공유 메모리를 통해 IaC Agent로 전달되며, IaC Agent는 조정 문서 해석, 목표 아키텍처 분석, IaC 생성, Cedar 규칙 기반 정책 검증, 중앙 실행과 결과 보고의 5단계를 수행한다.
• 모든 에이전트 작업은 범위가 제한된 IAM 역할, 입력 스키마 검증, 런타임 비밀정보 해석, 정의된 단일 작업 영향 임계값, AgentCore Observability와 AWS CloudTrail의 중앙 감사 기록으로 통제되며 인간은 의사결정 권한을 유지한다.

🧩 주요 포인트

1. 개가 넘는 애플리케이션에 수동 탐색과 애플리케이션당 3~4주의 IaC 개발이 반복되면 고정된 회계연도 기한을 맞추기 어려워지므로, 반복 작업을 목적형 AI 에이전트로 이전하는 것이 규모 확장의 핵심이다.
2. Intake Agent의 목표 아키텍처와 의존성 매핑을 AgentCore Memory에 저장하고 IaC Agent가 직접 읽는 구조는 탐색과 코드 생성 사이의 수동 인계를 제거해 마이그레이션 단계의 연속성을 높인다.
3. AgentCore Gateway의 MCP 도구, AgentCore Identity의 최소 권한 IAM 역할, Policy in AgentCore의 Cedar 규칙과 중앙 감사 기록은 자동 실행의 범위를 제한하면서도 대규모 실행과 추적을 가능하게 한다.

🧠 상세 정리

1. 대규모 마이그레이션의 세 가지 병목

원문은 대규모 클라우드 마이그레이션이 지연되는 원인을 수동 탐색, 반복적인 인프라 코드 개발, 대응형 사후 운영의 세 영역으로 구분한다. 애플리케이션 탐색 단계에서는 온프레미스 아키텍처, 자산 목록, 의존성, 접수 질문지를 파악하는 데 애플리케이션마다 수주가 소요된다. 목표 아키텍처가 정해진 뒤에도 자동화가 없다면 AWS 인프라를 구성할 IaC를 매번 처음부터 작성해야 하므로 애플리케이션당 통상 3~4주가 필요하다. 마이그레이션 이후에는 성능 저하를 선제적으로 감지하거나 문제를 자동으로 해결할 지능이 부족해 운영팀이 수동 모니터링과 사후 대응에 의존한다. 이러한 병목이 300개가 넘는 애플리케이션과 고정된 회계연도 기한에 걸쳐 반복되면 전체 일정과 엔지니어링 투입량이 감당하기 어려운 수준으로 늘어난다.

2. 생애주기별 다중 에이전트 구성

AWS Professional Services는 탐색부터 배포 후 운영까지 이어지는 병목을 각각 담당하도록 4개의 목적형 AI 에이전트를 구성했다. 마이그레이션 여정의 1단계인 Intake Agent는 애플리케이션 탐색, 목표 상태 아키텍처 정의, 의존성 매핑을 자동화하고, 2단계인 IaC Agent는 조직의 보안 모범 사례와 표준을 따르는 IaC를 생성한다. Migration Intelligence and Governance Agent는 Jira, Confluence, Webex를 아우르는 포트폴리오 보고, Well-Architected 평가, 마이그레이션 거버넌스를 제공한다. 운영 여정의 3단계인 SRE Agent는 마이그레이션 이후의 선제적 모니터링과 자동 문제 해결을 담당한다. 이와 별도로 AWS DMS는 데이터베이스의 생성형 AI 지원 스키마 변환과 자동 전환을, AWS Transform은 레거시 코드의 애플리케이션별 현대화를 보완한다.

3. 에이전트 실행과 공유 컨텍스트

각 에이전트는 기반 모델, 시스템 프롬프트, 기능별 도구 집합으로 정의되는 Strands 에이전트이며 Amazon Bedrock AgentCore의 서버리스 런타임에서 실행된다. 런타임은 세션 격리, 확장, 다중 에이전트 오케스트레이션을 담당하고, Amazon Bedrock 기반 모델은 문서 해석, 코드 생성, 여러 단계로 구성된 작업 흐름의 추론을 수행한다. 에이전트는 AgentCore Gateway가 API, AWS Lambda 함수, 기존 서비스를 변환해 제공하는 MCP 호환 도구를 호출하며, AgentCore Identity는 범위가 제한된 IAM 역할과 조직의 자격 증명 공급자를 이용해 호출을 인증한다. AgentCore Memory는 세션 상태와 공유 컨텍스트를 저장해 300개가 넘는 애플리케이션의 진행 상황과 산출물을 지속적으로 연결한다. Intake Agent가 목표 아키텍처와 의존성 매핑을 기록하면 IaC Agent가 이를 직접 읽기 때문에 별도의 수동 인계 없이 다음 단계의 코드 생성을 시작할 수 있다.

4. 코드로 정의된 IaC Agent

제시된 파이썬 예시는 BedrockAgentCoreApp, Strands Agent, BedrockModel, MCPClient를 사용해 IaC Agent를 AgentCore 런타임에 연결한다. MCP 클라이언트는 게이트웨이 주소와 클라이언트 자격 증명 방식을 사용하며, 정적으로 저장된 전달자 토큰 대신 만료 시 토큰을 다시 발급할 수 있도록 구성된다. BedrockModel에는 모델 식별자, AWS 리전, Guardrails 정책 식별자와 버전, 추적 설정이 전달되고, 요청의 prompt 필드가 비어 있으면 명시적인 오류를 반환한다. 에이전트는 MCP 게이트웨이를 도구로 받아 연결 수명주기와 도구 검색 페이지 처리를 SDK에 맡기며, Guardrails가 개입한 경우 차단 상태를 별도로 응답한다. 정상 실행에서는 생성된 IaC를 반환하고, 예외 발생 시 세션 식별자와 함께 오류를 기록한 뒤 오류 상태를 돌려준다.

5. 1단계: Intake Agent의 자동 탐색

Intake Agent는 마이그레이션 초기에 가장 많은 시간이 들어가는 온프레미스 현황 파악과 AWS 목표 상태 정의를 자동화한다. 입력으로는 온프레미스 아키텍처 문서, 애플리케이션 자산 목록, 접수 질문지, 의존성 지도를 사용하며, 서로 다른 자료에서 현재 구조와 연결 관계를 해석한다. 처리 결과에는 목표 AWS 아키텍처, 권장 마이그레이션 패턴, 리소스 크기 명세, 규정 준수 검증 보고서가 포함된다. 이 산출물은 탐색 단계에서 끝나는 별도 문서가 아니라 IaC Agent가 사용하는 직접 입력으로 전달된다. 따라서 원문이 지적한 애플리케이션별 수동 접수 병목을 줄이는 동시에 탐색 결과와 인프라 프로비저닝 사이에 자동화된 인계 경로를 형성한다.

6. 2단계: 조직 표준에 따른 IaC 생성

IaC Agent는 포트폴리오에서 먼저 배포된 에이전트이며 원문에서 가장 즉각적으로 측정 가능한 효과를 제공한 구성요소로 설명된다. 첫 단계에서는 웨이브 팀의 조정 문서를 읽어 배포 범위, 규정 준수 제약, 보안 조직이 승인한 웨이브별 예외를 추출한다. 다음으로 Intake Agent가 만든 목표 상태 아키텍처 도표를 해석해 필요한 인프라 구성요소와 구성요소 사이의 관계 및 의존성을 식별한다. 그 뒤 조직이 이미 정의하고 확립한 패턴을 이용해 IaC를 생성하고 웨이브별 매개변수, 원격 상태 관리, 필수 태그, 조직 표준이 요구하는 모니터링 설정을 반영한다. 이 자동화 결과로 내부 프로젝트 추적 데이터상 300개가 넘는 애플리케이션 포트폴리오의 IaC 개발 시간이 애플리케이션당 3~4주에서 수분으로 감소했다.

7. 정책 검증과 중앙 실행

생성된 IaC가 실행되기 전에는 Policy in AgentCore가 모든 도구 호출을 Cedar 규칙에 따라 평가한다. 정책 평가는 작업이 일으킬 수 있는 변경 범위를 계산하고, 동시에 진행되는 다른 웨이브와의 의존성 충돌 여부를 확인하며, 규정 준수 기간이 유효한지도 검증한다. 검증을 통과한 뒤 중앙 실행 영역이 IaC 실행을 시작하고 배포 상태를 감시하며, AgentCore Observability를 통해 결과를 보고한다. 배포 후 검증은 자동으로 수행되고 규정 준수 지표도 실시간으로 갱신된다. 이 과정은 코드 생성 자체뿐 아니라 실행 전 정책 판단, 배포, 사후 검증, 결과 관찰까지 하나의 작업 흐름으로 연결하면서 반복 작업은 에이전트에 맡기고 최종 의사결정 권한은 인간에게 남기는 접근을 따른다.

8. MCP 도구를 중심으로 한 보안 통제

프레임워크의 모든 작업은 AgentCore Gateway가 노출하는 사용자 정의 MCP 도구를 통과하며 AgentCore Identity와 Policy in AgentCore의 통제를 받는다. AgentCore Identity는 최소 권한 원칙에 맞춘 범위 제한 IAM 역할로 각 행동을 인증하고, 도구 경계에서는 정의된 스키마와 입력을 대조해 형식이 잘못된 요청을 거부한다. 자격 증명이나 민감한 값은 에이전트 컨텍스트에 전달하지 않고, 중앙 자격 증명 공급자에서 런타임에 비밀정보를 해석한다. AgentCore Observability와 AWS CloudTrail은 각 행동을 변경할 수 없는 중앙 감사 기록으로 남기며, Cedar 규칙은 하나의 작업이 정의된 임계값보다 넓은 범위에 영향을 주지 않도록 제한한다. IaC 생성에 사용되는 조직 패턴에는 네트워크 구성, 보안 그룹 규칙, IAM 역할, Amazon CloudWatch 경보 같은 기존 표준이 포함되어 자동화된 코드에도 조직별 통제가 반영된다.

🧾 핵심 주장 / 시사점

• 원문에서 정량적으로 제시된 가장 직접적인 성과는 IaC Agent의 코드 생성 자동화이며, 전체 마이그레이션 기간이 아니라 애플리케이션당 IaC 개발 시간이 3~4주에서 수분으로 줄었다는 내부 추적 결과다.
• 다중 에이전트 구조의 연결점은 AgentCore Memory에 저장되는 목표 아키텍처와 의존성 매핑이며, 이 공유 컨텍스트가 Intake Agent와 IaC Agent 사이의 수동 인계를 대체한다.
• 에이전트의 자동 실행은 무제한 자율성이 아니라 MCP 도구의 기능 범위, 최소 권한 IAM 역할, Cedar 규칙, 입력 검증, 중앙 감사 기록을 결합한 통제 구조 안에서 수행된다.

✅ 액션 아이템

• 300개가 넘는 애플리케이션에서 IaC 개발 시간이 3~4주에서 수분으로 단축됐다는 내부 프로젝트 추적 데이터의 측정 기준 확인.
• Intake Agent가 AgentCore Memory에 기록하고 IaC Agent가 읽는 목표 아키텍처와 의존성 매핑의 공유 범위 검토.
• AgentCore Gateway·Identity·Policy·Observability에 적용되는 MCP 도구 권한, Cedar 규칙, 단일 작업 영향 임계값의 운영 조건 확인.

❓ 열린 질문

• 300개가 넘는 애플리케이션의 IaC 개발 시간이 3~4주에서 수분으로 단축됐다는 결과는 내부 프로젝트 추적 데이터에서 어떤 기준으로 측정됐는가?
• AgentCore Memory가 Intake Agent와 IaC Agent 사이에서 보존하는 공유 컨텍스트의 구체적인 범위와 수명은 무엇인가?
• Policy in AgentCore의 Cedar 규칙이 제한하는 단일 작업 영향 임계값은 어떤 기준으로 결정되는가?