Migrate agentic workloads to Amazon Bedrock AgentCore

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Amazon Bedrock AgentCore로 LangGraph 고객 지원 에이전트의 실행·도구·상태 관리를 먼저 이전하고, 이후 Strands Agents의 모델 주도 계획으로 전환하는 단계적 마이그레이션을 설명한다.

📌 핵심 요약

• 기존 에이전트는 LangGraph로 메시지를 분류하고 화난 고객을 상담원에게 연결하며, 나머지 요청에는 lookup_order, process_return, search_faq 도구를 사용한다. 모델 추론은 이미 Amazon Bedrock에서 수행한다.
• 1단계는 그래프를 유지하면서 실행을 Runtime으로, 도구 2개를 Gateway로, 대화 상태를 Memory로 이전한다. 원문은 전체 운영 부담 10개 중 5개를 이 단계에서 넘긴다고 설명한다.
• 2단계는 Strands Agents의 모델 주도 계획으로 수동 분기를 대체한다. 3단계의 AgentCore 하네스 위임은 구현하지 않고 설명하며, 의존성 업데이트 책임은 3단계에서 이전된다.
• IAM 정책, VPC 구성, WAF 규칙, 비밀정보 교체는 모든 단계에서 사용자 책임으로 남는다. 운영 환경에서는 단계와 관계없이 Amazon Bedrock Guardrails를 적용하도록 안내한다.
• 기존 MemorySaver는 프로세스 종료 시 상태가 사라지고 복제본 간 대화를 공유하지 못한다. 이전 전에는 실행된 도구와 그래프의 최종 메시지를 기준선으로 기록하며, 제공된 본문은 1단계 Gateway 도구 공개 설명 도중 끝난다.

🧩 주요 포인트

1. 실행 환경 이전과 계획 방식 변경의 분리 → 1단계에서 기존 동작을 비교한 뒤 2단계에서 Strands Agents 전환을 진행할 수 있다.
2. 프로세스 내부 MemorySaver의 한계 → 대화 지속성과 복제본 간 상태 공유를 위해 상태 저장을 실행 프로세스에서 분리해야 한다.
3. Runtime·Gateway·Memory의 운영 책임 인수 → 인프라 부담은 줄지만 IAM 정책, VPC 구성, WAF 규칙, 비밀정보 교체 책임은 계속 남는다.

🧠 상세 정리

1. 노트북에서 운영 환경으로 넘어갈 때의 문제

원문은 노트북에서 작동하는 에이전트와 실제 사용자를 받는 운영 에이전트 사이에 추론 외의 책임이 생긴다는 문제에서 출발한다. 사용자별 세션을 분리하고 여러 차례의 대화와 여러 날에 걸쳐 상태를 유지해야 하며, 도구 호출 인증과 운영체제 패치도 관리해야 한다. 예제는 주문 조회와 반품 등을 처리하는 기존 LangGraph 고객 지원 에이전트로, 컨테이너와 웹 서버, 프로세스 내부 대화 상태를 사용자가 소유한다. 모델 호출은 이미 Amazon Bedrock으로 향하므로, 이번 이전의 핵심은 추론 경로보다 실행 기반과 운영 책임에 있다. 운영 환경에서는 어느 단계에서 멈추더라도 Amazon Bedrock Guardrails를 추가해 유해 콘텐츠를 걸러내고, 원본 문서에 대한 근거성을 검증하며, 프롬프트 주입 시도를 차단하도록 안내한다.

2. 단계별 이전과 계획 방식의 선택

이전은 에이전트가 실행되는 위치를 바꾸는 작업과 다음 행동을 결정하는 방식을 바꾸는 작업으로 나뉜다. 1단계에서는 LangGraph 그래프를 그대로 둔 채 Runtime, Gateway, Memory를 연결하므로, 이 단계에서 멈춰도 관리형 도구와 지속되는 상태를 갖춘 호스팅 에이전트를 얻는다. 2단계에서는 Strands Agents로 실행 루프를 다시 구성하고, 사람이 작성한 조건 분기를 모델 주도 계획으로 대체한다. Runtime 자체는 에이전트의 다음 행동을 결정하지 않으므로 수동 분기를 없애는 것은 별도의 선택이다. 원문은 실행 환경을 먼저 검증한 뒤 계획 방식을 변경하도록 권하지만, 이미 에이전트를 다시 작성하는 팀은 공통 Gateway와 도구 대상, Memory 저장소를 먼저 마련하고 2단계부터 시작할 수 있다고 설명한다. 3단계는 AgentCore 하네스에 루프를 넘기는 방향으로 소개되며 구현 대상에는 포함되지 않는다.

3. 서비스가 인수하는 책임과 남는 책임

Runtime은 컴퓨팅을 맡아 운영체제 패치, 자동 확장, 세션 격리를 처리하며 기본적으로 AWS 관리 인프라에서 실행되고 사용자 소유 VPC에도 연결할 수 있다. Gateway는 도구 인증을 맡고 자체 실행 역할로 함수를 호출하며, Memory는 대화 상태를 여러 턴과 프로세스, 여러 날에 걸쳐 저장한다. 다만 네트워크 설계와 진입점 보호, 접근 권한 결정은 사용자에게 남고, IAM 정책과 VPC 구성, WAF 규칙, 비밀정보 교체도 모든 단계에서 직접 관리해야 한다. 의존성 업데이트 책임은 3단계에서만 이전되므로 앞선 단계의 운영 범위와 구분해야 한다. 추가 서비스인 Identity는 자격 증명 중개와 OAuth 접근 토큰 갱신을 담당하지만, 예제는 에이전트의 IAM 자격 증명으로 Gateway 요청에 서명하고 Gateway가 자체 역할로 Lambda를 호출하므로 이를 사용하지 않는다. Policy는 Gateway에서 개별 도구 호출을 판단하고, Observability는 별도 구성 없이 Runtime 로그와 지표, 추적 정보를 Amazon CloudWatch로 보낸다.

4. 실습 준비와 설치 검증

실습에는 Amazon Bedrock 모델 접근이 활성화된 AWS 계정, Python 3.12, 필요한 자격 증명이 설정된 AWS CLI가 필요하다. 해당 자격 증명에는 AgentCore, Lambda, Amazon S3, IAM 리소스를 생성할 권한이 있어야 하며, 생성된 추적 정보를 보려면 계정에서 CloudWatch Transaction Search도 한 번 활성화해야 한다. 샘플 저장소를 복제하고 setup.sh를 실행하면 가상 환경을 만들고 일곱 개의 요구 패키지를 설치한다. 이미 LangGraph와 Amazon Bedrock을 사용하는 경우 새로 필요한 패키지는 strands-agents, bedrock-agentcore, mcp, langgraph-checkpoint-aws로 제시된다. 일부 패키지 두 개는 최소 버전 대신 고정 버전을 사용하는데, 원문은 langchain-aws 버전을 고정하지 않으면 더 높은 버전이 선택되면서 boto3 버전도 함께 올라간다고 설명한다. 설치 확인용 단위 테스트는 자격 증명 없이 실행할 수 있고, 저장소의 단계별 구성을 통해 이전 전후를 비교할 수 있다.

5. 0단계의 기존 동작과 상태 저장 한계

기존 에이전트는 컴파일된 StateGraph이며, classify_intent가 모델에 한 단어 분류를 요청하면 직접 작성한 route_intent가 결과를 읽어 경로를 정한다. 화난 고객은 escalate로 보내 고정된 상담원 연결 응답을 반환하며 추가 모델 호출은 하지 않고, 나머지 고객은 도구가 연결된 assist로 보낸다. HTTP 백엔드 위의 lookup_order, process_return, search_faq는 예외를 던지는 대신 오류 정보를 반환하는데, 도구 노드의 예외는 실행을 중단시키지만 오류 응답은 모델이 후속 행동에 활용할 수 있기 때문이다. 상태는 호출 시 전달하는 thread_id를 키로 MemorySaver에 저장하지만, 프로세스 내부 사전이므로 프로세스가 종료되면 사라지고 두 복제본이 서로의 대화를 볼 수 없다. 모델은 ChatBedrockConverse를 사용하며, OpenAI나 Anthropic을 직접 호출하던 경우에는 모델 식별자와 AWS 리전을 받는 생성자로 변경하는 경로를 안내한다. 이전 전에는 어떤 도구가 실행됐는지와 그래프 상태의 최종 메시지를 기록해야 하며, 단순히 모델의 응답만 기록하는 것과 구분한다.

6. 1단계의 변경 범위와 기존 코드 재사용

1단계의 목표는 기존 동작을 유지하면서 실행 프로세스, 일부 도구의 호출 경로, 대화 상태 저장 위치를 이전하는 것이다. Runtime이 프로세스를 맡고 세 도구 중 두 개를 Gateway 뒤로 옮기며, 대화 상태는 Memory에 저장한다. 이전된 패키지는 기존 코드를 복사하지 않고 0단계의 build_graph와 SUPPORT_TOOLS를 가져오므로 그래프 구조, 라우터, 상태 스키마, 세 프롬프트와 세 도구 본문을 공유한다. 원문은 커밋된 샘플을 기준으로 에이전트 내부 변경 45줄, SDK가 제공하지 않는 보조 코드 22줄, 변경 없이 가져오는 코드 85줄이라고 제시한다. 보조 코드가 작은 이유는 이전에 직접 작성해야 했던 AgentCore Memory용 LangGraph 체크포인터가 이제 패키지로 제공되어 도구 어댑터만 연결 코드로 남기 때문이다. 이 단계에서 운영 부담 10개 중 5개가 이전되며, 이미 Amazon Bedrock에서 수행하던 추론은 이동하지 않는다.

7. Runtime으로 기존 실행 루프 호스팅

Runtime 이전은 기존 루프를 BedrockAgentCoreApp으로 감싸고 진입점 함수를 추가하는 방식으로 설명된다. 진입점은 요청의 프롬프트를 HumanMessage로 전달해 기존 그래프를 호출하고, 그래프 상태에 남은 마지막 메시지를 결과로 반환한다. 그래프 호출 자체는 0단계와 같지만 thread_id는 기존의 직접 지정값 대신 Runtime이 전달하는 RequestContext의 context.session_id에서 얻으며, 예제에는 값이 없을 때 사용할 로컬 세션 값도 들어 있다. Runtime은 세션마다 하나의 microVM을 사용해 격리하고 기반 운영체제 패치 책임을 가져간다. 그래프는 한 번 구성한 뒤 유지해야 하는데, 요청마다 다시 만들면 모델 클라이언트를 재생성하고 도구에 필요한 MCP 세션을 종료시킬 수 있기 때문이다. 같은 래퍼 방식은 CrewAI, LlamaIndex 또는 직접 작성한 루프에도 적용할 수 있으며, 요청 사전을 받아 실행하고 결과 사전을 반환하는 형태를 따른다.

8. Gateway를 통한 도구 공개와 제공 범위

Runtime으로 실행 기반을 옮긴 뒤에도 도구 인증 책임은 남아 있으므로, 다음 설명은 Gateway를 통한 도구 공개로 이어진다. 예제에서는 lookup_order와 process_return을 Lambda 함수에서 제공하는 MCP 도구로 공개하고, 세 번째 도구인 search_faq는 이 이전 대상에 포함하지 않는다. 도구를 공개하면 인증 처리가 에이전트 코드 밖으로 이동하고, 같은 프로세스 안에서만 쓰던 함수를 다른 에이전트도 호출할 수 있게 된다. 앞선 구성 대응표는 Gateway가 공개하는 도구 이름을 supportTools___<name> 형식으로 제시하며, Strands에서는 MCPClient.list_tools_sync()로 얻은 도구를 Agent에 전달하는 관계를 보여 준다. 다만 제공된 본문은 Lambda 함수를 등록하고 코드를 변경하지 않는다는 설명 도중 끝나므로, 이후 Gateway 등록 절차나 Memory 연결의 구체적 구현은 확인할 수 없다. 따라서 2단계와 3단계 역시 본문 앞부분의 개요에서 확인되는 역할과 범위까지만 정리할 수 있다.

🧾 핵심 주장 / 시사점

• Amazon Bedrock에서 이미 추론을 수행하더라도 컨테이너, 인증, 상태 관리 부담은 별도로 남으므로 마이그레이션의 가치는 운영 책임의 변화로 판단해야 한다.
• 기존 그래프와 도구를 가져오는 방식은 동작 차이를 줄이고, 실행된 도구와 최종 메시지의 기준선은 1단계 이전 결과를 비교할 근거가 된다.
• Gateway에 공개한 도구는 다른 에이전트도 호출할 수 있으므로, 도구 이전은 인증 책임의 이동과 함께 재사용 범위의 확장을 의미한다.

✅ 액션 아이템

• 1단계 이전 전 실행된 도구와 그래프의 최종 메시지를 기준선으로 기록하고 이전 후 비교.
• MemorySaver의 프로세스 종료 시 상태 소실과 복제본 간 대화 공유 한계를 기준으로 Memory 이전 결과 확인.
• IAM 정책, VPC 구성, WAF 규칙, 비밀정보 교체의 운영 책임을 유지하고 Amazon Bedrock Guardrails 적용.

❓ 열린 질문

• 1단계 이전 후 실행된 도구와 그래프의 최종 메시지가 기존 기준선과 일치하는가?
• Memory 이전으로 MemorySaver의 프로세스 종료 시 상태 소실과 복제본 간 대화 공유 한계가 해소되는가?
• 그래프를 유지하는 1단계에서 멈출 것인가, Strands Agents의 모델 주도 계획을 사용하는 2단계까지 진행할 것인가?