분钟 내 첫 번째 작동 가능한 에이전트에 도달: Amazon Bedrock AgentCore의 새 기능 발표

Amazon Bedrock AgentCore는 에이전트 개발의 전 생명주기(프로토타입 → 프로덕션)에서 반복적으로 부딪히는 인프라 장벽을 제거하기 위해 설계된 관리형 런타임이다. 기존에는 개발자가 LLM 기반 에이전트를 실제 서비스로 배포하려면 세션 상태 관리, 메모리 저장소, 툴 호출 샌드박싱, 관측성(Observability), ID/권한 연동, 장시간 실행(long-running) 작업 처리 등을 직접 구축해야 했다. AgentCore는 이러한 공통 컴포넌트(Runtime, Memory, Gateway, Identity, Observability, Code Interpreter, Browser Tool)를 모듈 단위로 제공하며, 특정 프레임워크(LangGraph, CrewAI, Strands, LlamaIndex 등)나 특정 모델에 종속되지 않도록 설계된 것이 핵심이다. 이번 업데이트는 이 구조 위에 "몇 분 안에 첫 동작하는 에이전트"를 띄울 수 있도록 부트스트래핑 경로를 단축하는 데 초점이 맞춰져 있다.

실무 관점에서 가장 큰 영향은 "에이전트를 위한 Heroku/Vercel" 수준으로 배포 러닝커브가 낮아진다는 점이다. 한국 엔지니어들이 자주 겪는 문제인 ① 세션/대화 컨텍스트를 Redis에 직접 얹어 관리, ② 툴 실행을 위한 격리된 컨테이너/Firecracker VM 구성, ③ 에이전트 간 MCP/함수 호출 라우팅 구현, ④ 사용자별 OAuth 토큰 보관 및 재발급 로직이 AgentCore의 관리형 서비스로 대체 가능하다. 특히 Memory 서비스는 단기(Short-term) 대화 컨텍스트와 장기(Long-term) 사용자 프로파일을 분리해 저장하고 의미 기반 검색까지 제공하므로, 기존에 Pinecone/OpenSearch + 자체 요약 파이프라인으로 구성하던 스택을 크게 단순화할 수 있다. 또한 세션당 최대 8시간까지 지속되는 장시간 실행 지원은 웹 스크래핑, 리서치 에이전트, 코드 생성-검증 루프처럼 Lambda의 15분 제한에 걸리던 워크로드에 유효한 해법이 된다.

개발자가 실제로 확인해야 할 포인트는 "AgentCore가 주는 추상화의 대가"다. 첫째, 프레임워크 중립을 표방하지만 런타임 배포 시 제공되는 BedrockAgentCoreApp 래퍼와 요청/응답 스키마를 준수해야 하므로, 기존 FastAPI 기반 에이전트를 올릴 때 엔드포인트 어댑팅이 필요하다. 둘째, 과금 모델이 요청 수가 아닌 CPU/메모리 사용 시간 기반이므로, 장시간 실행 기능을 남용하면 Lambda 대비 비용이 오히려 커질 수 있다. 셋째, Identity 서비스가 OAuth2/OIDC 토큰을 대리 보관(vault)하는 구조이기 때문에, 국내 금융·공공 프로젝트처럼 "외부 SaaS에 인증 토큰을 위탁 저장"하는 것이 컴플라이언스상 허용되는지 사전에 확인해야 한다.

따라서 지금 취해야 할 액션은 두 가지다. 신규 프로젝트라면 PoC 단계부터 Runtime + Memory + Observability만이라도 AgentCore로 시작해 "내재화할 컴포넌트"와 "위임할 컴포넌트"의 경계를 조기에 긋는 것이 유리하다. 반대로 이미 자체 에이전트 인프라를 운영 중이라면 전면 이관보다는 Gateway(MCP 호환 툴 서버)와 Browser/Code Interpreter 같은 격리 실행 환경만 선택적으로 도입해 보안 리스크를 낮추는 접근이 현실적이며, AWS Bedrock이 아닌 타 리전·타 모델(Claude, Gemini)을 혼용할 때의 레이턴시와 데이터 주권 이슈도 함께 벤치마킹해 두는 것이 좋다.