AWS Kiro로 AI 에이전트 개발하기: Amazon Bedrock AgentCore 프로덕션 배포 완벽 가이드(2편)
- 3일 전
- 8분 분량
AWS Kiro로 AI 에이전트 개발하기: Amazon Bedrock AgentCore 프로덕션 배포 완벽 가이드(2편)
Written by Eunmin Jeon
들어가며
1편에서는 AWS Kiro와 Harness Engineering을 활용해 에이전트를 설계하는 방법을 다뤘습니다. Spec-Driven Development로 요구사항부터 설계·태스크 문서를 만들고, 역할을 나눈 5개의 멀티 에이전트가 협업해 음성 비서 코드를 구현하는 과정이었는데요. 구현까지 30분이 채 걸리지 않았죠.
그런데 여기서 끝이 아닙니다. 만든 에이전트는 아직 개발자의 노트북 안에만 있는데요. 실제 사용자들이 쓰려면 어딘가에 배포되어 안정적으로 운영되어야 합니다.
2편에서는 Amazon Bedrock AgentCore를 활용해 에이전트를 실제 프로덕션 환경에 배포하고 운영하는 방법을 다룹니다.
본 글은 AWS Unicorn Day 2026 Seoul 세션 내용을 재구성한 글입니다.
1. 왜 에이전트 운영이 어려운가요?
에이전트를 만드는 것 자체는 이제 어렵지 않습니다. 프레임워크도 다양하고, 1편에서 본 것처럼 Kiro 같은 도구의 도움을 받으면 기본적인 에이전트는 금방 만들 수 있습니다.
문제는 그다음입니다. 여기서 질문을 하나 던져보겠습니다.
지금까지 만든 프로토타입 에이전트를 프로덕션에서 운영하려면, 어떤 점들을 고려해야 할까요?
나 혼자 쓰는 에이전트라면 상관없습니다. 하지만 다수의 사용자가 동시에 사용하는 순간, 고려해야 할 것들이 한꺼번에 쏟아집니다.
고려 영역 | 어떤 문제인가요? |
세션 관리 | A 사용자와 나눈 대화가 B 사용자에게 이어지면 안 되겠죠. 사용자마다 대화를 분리해야 합니다. |
가용성 / 확장성 | 사용자가 갑자기 10배로 늘어나도 서비스가 멈추지 않아야 합니다. |
관찰가능성 | 에이전트가 지금 무엇을 하고 있는지, 어디서 문제가 생겼는지 추적할 수 있어야 합니다. |
인증 / 인가 | 아무나 에이전트에 접근하면 안 됩니다. 누가, 어디까지 쓸 수 있는지 통제가 필요합니다. |
보안 / 격리 | 사용자 간 데이터가 섞이거나 유출되면 안 됩니다. |
비용 관리 | 에이전트 특성상 낭비되는 비용이 생기기 쉽습니다. (뒤에서 자세히 다룹니다) |
여기에 에이전트만의 특수성이 하나 더 있는데요. 일반적인 소프트웨어는 정해진 순서대로 동작하지만, 에이전트는 상황에 따라 실행 흐름이 매번 달라집니다. 그래서 전체 실행 과정을 추적해야 하고, LLM을 사용하는 만큼 토큰 사용량이나 응답 품질 같은 것까지 모니터링해야 합니다.
에이전트 개발 자체도 새로운 영역인데, 익숙하지도 않은 인프라 영역까지 개발자가 전부 직접 만들기엔 현실적으로 어렵습니다.
이 문제를 해결하기 위해 나온 서비스가 바로 Amazon Bedrock AgentCore입니다.
2. Amazon Bedrock AgentCore란?
Amazon Bedrock AgentCore는 개발된 AI 에이전트를 프로덕션 환경에 배포하고 운영하는 데 필요한 기능을 제공하는 관리형 서비스입니다. 위에서 나열한 세션 관리, 확장성, 보안, 모니터링 같은 인프라 고민을 AWS가 대신 해결해 주는 서비스라고 이해하면 됩니다.
중요한 특징은 프레임워크와 모델에 제약이 없다는 점입니다. Strands Agents, LangGraph, CrewAI 등 어떤 프레임워크로 만든 에이전트든, 어떤 모델을 쓰든 상관없이 올릴 수 있습니다. 1편에서 Strands Agents로 만든 음성 비서도 그대로 배포할 수 있는 이유입니다.
2026년 1월 서울 리전에 정식 출시되어, Preview 단계인 Evaluations를 제외한 모든 기능을 서울 리전에서 사용할 수 있습니다.
📎 AgentCore 공식 문서: https://docs.aws.amazon.com/bedrock-agentcore/
3. AgentCore의 9가지 구성 요소
AI 에이전트를 만드는 것보다 어려운 일은 '운영'입니다. AgentCore는 이 운영 문제를 해결하기 위해 Runtime, Memory, Gateway 등 9가지 기능을 제공합니다. 이 9가지를 전부 세세하게 알아야 하는 건 아니며, 사용 사례에 맞게 필요한 기능만 조합해서 쓰면 되는데요. 각 기능이 어떤 역할인지 그룹으로 묶어서 보면 이해가 쉽습니다.
실행 환경 — 에이전트가 돌아가는 곳
Runtime — 에이전트 코드가 실제로 실행되는 공간입니다. 세션별로 격리된 서버리스 환경을 제공합니다. (핵심 기능이라 다음 장에서 자세히 다룹니다)
Memory — 세션이 바뀌어도 사용자와의 대화 맥락을 기억하게 해주는 단기/장기 메모리 기능입니다.
도구 연결 — 에이전트의 손과 발
Gateway — 이미 갖고 있는 API 서버, Lambda 함수, MCP 서버들을 하나의 MCP 서버 형태로 모아서 통합 관리해 줍니다. 에이전트 입장에서는 창구가 하나로 정리되는 셈이죠.
Browser — 에이전트가 웹을 탐색해야 할 때 쓰는 클라우드 기반 브라우저 환경입니다.
Code Interpreter — 에이전트가 코드를 실행해야 할 때 쓰는 격리된 샌드박스 환경입니다.
보안 / 제어 — 에이전트의 울타리
Identity — "적절한 권한을 가진 주체만 허용된 에이전트와 도구에 접근"하도록 인증과 인가를 담당합니다.
Policy — 에이전트가 도구를 호출할 때, 그 요청을 중간에서 가로채 사전에 정의한 규칙에 맞는지 검사합니다. 허용된 범위의 요청만 통과시키는 가드레일 역할입니다.
운영 / 품질 — 에이전트의 CCTV
Observability — 에이전트의 실행 단계를 추적하고 토큰 사용량, 지연시간, 에러율을 실시간 모니터링합니다. 결과는 대시보드로 볼 수 있고, OpenTelemetry를 지원해 별도 대시보드를 구축할 수도 있습니다.
Evaluations — Observability 결과를 기반으로 "에이전트가 정확하게 응답했는가", "적절한 도구를 사용했는가" 같은 품질을 평가합니다.
4. 핵심은 Runtime: 에이전트가 실제로 실행되는 공간
9가지 기능의 중심에는 Runtime이 있습니다.
구조를 그려보면 이렇습니다. 에이전트는 Runtime 안에서 동작하고, 필요할 때 Gateway·Browser·Code Interpreter 같은 도구를 호출합니다. 그 호출을 Identity와 Policy가 검증하고, Memory가 대화 맥락을 유지하며, Observability가 이 모든 과정을 지켜봅니다. 나머지 기능들이 전부 Runtime을 중심으로 연결되어 있는 셈이죠.
Runtime이 지원하는 통신 방식(프로토콜)은 3가지입니다.
프로토콜 | 언제 쓰나요? | 포트 | 경로 |
HTTP | 에이전트를 호출하고 응답받는 일반적인 사용 사례 | 8080 | /invocations (WebSocket은 /ws) |
MCP | 에이전트가 아니라 MCP 서버 자체를 호스팅하고 싶을 때 | 8000 | /mcp |
A2A | 에이전트끼리 서로 협업하는 멀티 에이전트 구성 | 9000 | / |
한 가지 흥미로운 점은 Runtime이 꼭 에이전트만을 위한 공간은 아니라는 건데요. MCP 프로토콜을 지원하기 때문에 MCP 서버를 호스팅하는 용도로도 쓸 수 있고, A2A(Agent-to-Agent)를 지원해 에이전트 간 협업 구조도 만들 수 있습니다. 프로토콜마다 포트와 경로가 다르니 구현할 때 이 점만 지켜주면 됩니다.
5. AgentCore Runtime의 3가지 특징
① 세션 격리 — 사용자마다 독립된 방을 제공합니다
Runtime은 MicroVM 기반의 서버리스 환경입니다.
세션(runtimeSessionId)마다 격리된 VM(가상 머신)이 하나씩 생성되어 에이전트가 실행됩니다. 같은 세션 안에서는 이 VM이 유지되며 대화 맥락도 이어지고, 세션이 달라지면 완전히 분리된 새 VM이 생깁니다. 사용자마다 독립된 방이 하나씩 생기는 구조라, 사용자 간 데이터가 섞일 일이 없습니다.
같은 runtimeSessionId → 같은 VM을 재사용해 대화 맥락 유지
다른 runtimeSessionId → 새로운 격리된 VM 생성
그리고 이 세션 관리는 놀랄 만큼 단순합니다. 개발자가 따로 세션 관리 로직을 구현할 필요 없이, 호출할 때 넘기는 runtimeSessionId 값 하나로 자동 처리됩니다.
VM의 생명주기는 이렇습니다.
요청 진입 → Active(처리 중) → Idle(대기) → Terminated(VM 완전 삭제)
Idle 상태로 15분이 지나거나 8시간이 경과하면 자동으로 삭제되고, 그 전에 직접 종료하고 싶다면 StopRuntimeSession으로 종료할 수 있습니다. 한 가지 기억할 점은, VM이 삭제되면 그 안의 데이터도 전부 사라진다는 것. 세션이 끝나도 유지해야 하는 정보가 있다면 별도의 데이터베이스나 앞서 소개한 AgentCore Memory를 사용하면 됩니다.
② 비용 최적화 — 기다리는 시간엔 돈을 받지 않습니다
Runtime의 가장 독특한 특징은 과금 방식입니다. 일반적인 에이전트의 실행 흐름을 한번 보겠습니다.
에이전트 호출 → LLM 응답 대기 → 도구 호출 → 도구 결과 대기 → LLM 응답 대기 → 응답
뭔가 눈에 띄는 부분이 있지 않으신가요? '대기'가 절반입니다. 실제로 AI 에이전트는 LLM 응답이나 도구, API 호출을 기다리느라 전체 실행 시간의 30~70%를 아무것도 하지 않고 보냅니다.
기존 클라우드 방식은 리소스를 미리 할당해 두는 구조라, 이렇게 기다리는 시간에도 비용이 그대로 청구됩니다. 문 열어놓고 손님을 기다리는 동안에도 임대료는 나가는 것과 같죠.
AgentCore Runtime은 이 구조 자체를 바꿨습니다.
사전 리소스 할당이 불필요합니다.
세션 중 실제로 사용한 활성 리소스에 대해서만 과금됩니다. (실제 CPU 사용량 + 해당 초까지 사용된 최대 메모리, 최소 1초 기준)
LLM 응답을 기다리며 CPU 사용량이 낮아지면, 그만큼 비용도 함께 낮아집니다. 대기 시간이 긴 에이전트일수록 절감 효과가 커지는 구조입니다.
③ 확장성 — 음성 에이전트 같은 실시간 사례까지
비동기 호출 시 최대 8시간까지 실행할 수 있고, 최대 100MB 페이로드와 WebSocket 양방향 스트리밍을 지원합니다. 덕분에 음성 비서처럼 실시간으로 데이터를 주고받아야 하는 에이전트도 문제없이 올릴 수 있습니다. 보안 측면에서는 IAM/OAuth 인증, PrivateLink, VPC 통합을 지원해 이미 AWS에 배포해 둔 리소스와도 안전하게 연결됩니다.
6. 에이전트 배포하기: 코드 세 줄이면 충분합니다
그럼 이제 실제로 배포해 보겠습니다. 배포 전에 딱 하나, 기존 에이전트 코드에 Runtime 인터페이스를 구성해 줘야 합니다.
Runtime은 에이전트를 API 서버 형태로 호스팅하는 방식입니다. 그런데 우리가 에이전트를 개발할 때 처음부터 API 서버 형태로 만들지는 않죠. 그래서 두 가지 방법을 제공합니다.
방법 1 — AgentCore SDK 사용 (권장)
AgentCore SDK를 사용하면 여러분이 작성한 에이전트 코드를 API 서버 형태로 자동 변환해 줍니다. 필요한 수정은 딱 세 줄입니다.
BedrockAgentCoreApp 생성
에이전트 진입점에 @app.entrypoint 데코레이터 추가
코드 마지막에 app.run() 추가
from bedrock_agentcore.runtime import BedrockAgentCoreApp
app = BedrockAgentCoreApp()
@app.entrypoint
def invoke(payload):
response = agent(payload.get("prompt"))
return str(response)
if __name__ == "__main__":
app.run()
방법 2 — API 서버 직접 구현
FastAPI 등으로 호출용 /invocations 엔드포인트와 헬스 체크용 /ping 엔드포인트를 직접 구현하는 방식입니다. 이미 API 서버 형태로 개발했거나 세밀한 제어가 필요할 때 선택하면 됩니다. (WebSocket을 쓴다면 /ws 경로로 구현합니다)
from fastapi import FastAPI
import uvicorn
app = FastAPI()
@app.post("/invocations")
async def invoke(request):
result = agent(request.input.get("prompt"))
return {"output": {"message": result.message}}
@app.get("/ping")
async def ping():
return {"status": "healthy"}
if __name__ == "__main__":
uvicorn.run(app, host="0.0.0.0", port=8080)
*(구조를 보여주기 위한 예시 코드로, 실제 구현 시에는 요청 본문 파싱 로직이 필요합니다)*
코드 구성이 끝나면 두 가지 방식으로 배포할 수 있습니다.
배포 방식 | 흐름 | 언제 쓰나요? |
Container 배포 | Dockerfile 작성 → 이미지 빌드 → Amazon ECR 업로드 → Runtime 생성 | 컨테이너 기반으로 환경까지 통제하고 싶을 때 |
Direct Code 배포 | 프로젝트를 Zip으로 압축 → Amazon S3 업로드 → Runtime 생성 | Python 기반 에이전트를 간단히 올리고 싶을 때 |
7. Starter Toolkit: 명령어 2개로 배포 끝내기
배포는 AWS SDK나 콘솔로도 할 수 있습니다. 하지만 매번 ECR, IAM Role, 네트워크 설정을 직접 구성하는 건 꽤 번거로운 일인데요. 이걸 위해 제공되는 것이 바로 AgentCore Starter Toolkit CLI입니다. 명령어 2개면 배포가 끝납니다.
# 1단계: 구성
# 리전, IAM Role, ECR, 배포 방식, 네트워크 설정 등을 대화형으로 설정
$ agentcore configure --entrypoint agent.py
# → .bedrock_agentcore.yaml 파일 생성
# 2단계: 배포
# yaml 파일 기반으로 이미지 빌드, 업로드, Runtime 생성까지 자동 처리
$ agentcore deploy
configure에서 설정을 마치면 배포 구성이 담긴 yaml 파일이 생성되고, deploy를 실행하면 이 파일을 기반으로 배포에 필요한 리소스 생성부터 이미지 빌드, 최종 배포까지 자동으로 진행됩니다.
배포가 완료되면 Runtime 엔드포인트가 생성됩니다. 에이전트를 호출할 수 있는 주소가 생기는 것이죠. 에이전트는 업데이트될 때마다 버전으로 발행되고, 버전마다 엔드포인트를 연결해 호출할 수 있어 버전 관리도 자연스럽게 해결됩니다.
호출 방법은 두 가지입니다.
AWS SDK로 호출 — 애플리케이션 코드에서 호출할 때
agentcore_client = boto3.client("bedrock-agentcore")
response = agentcore_client.invoke_agent_runtime(
agentRuntimeArn = agent_arn,
runtimeSessionId = str(uuid.uuid4()),
payload = payload,
qualifier = "DEFAULT"
)
URL로 호출 — 에이전트의 ARN을 URL 형태로 변환해 일반 API처럼 호출할 때
curl -X POST <https://bedrock-agentcore>.{region}.amazonaws.com/runtimes/{agent_arn}/invocations?qualifier=DEFAULT \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $YOUR_BEARER_TOKEN" \
-H "X-Amzn-Bedrock-AgentCore-Runtime-Session-Id: session-id" \
-d '{"prompt": "Tell me a joke"}'
8. 실습: Kiro로 만든 음성 에이전트 배포하기
이제 1편에서 Kiro의 멀티 에이전트로 구현한 음성 에이전트를 AgentCore Runtime에 실제로 배포해 보겠습니다.
음성 에이전트는 실시간으로 음성 데이터를 주고받아야 하기 때문에 WebSocket 방식으로 통신합니다. 그래서 @app.entrypoint 대신 @app.websocket 데코레이터를 사용했는데요. 앞서 본 것과 똑같이 ① 앱 생성, ② 데코레이터 추가, ③ 실행 코드 추가, 세 단계면 끝입니다.
from bedrock_agentcore.runtime import BedrockAgentCoreApp
app = BedrockAgentCoreApp()
@app.websocket
async def websocket_handler(websocket, context):
await websocket.accept()
model = create_bidi_model()
agent = create_bidi_agent(model)
await agent.start()
# 이후 WebSocket 통신 처리
이후 agentcore configure → agentcore deploy 명령어만 실행하면 배포가 완료되고, 생성된 엔드포인트로 음성 에이전트를 바로 호출할 수 있습니다. 1편에서 30분 만에 구현한 에이전트가, 몇 줄의 코드 수정과 명령어 2개로 프로덕션에 올라가는 셈입니다.
참고로 AgentCore 역시 Kiro의 Power 기능을 제공하고 있어서, AgentCore를 처음 시작한다면 개발과 배포 과정에서 함께 활용해 보는 것도 좋습니다.
9. 개발에서 운영까지: 전체 흐름 정리
1편과 2편을 합치면 개발부터 운영까지의 전체 흐름이 완성됩니다.
[1편] Kiro로 설계 및 구현
↓
Spec-Driven Development로 요구사항 → 설계 → 태스크 문서 생성
↓
MCP + Power + Steering으로 컨텍스트 관리
↓
Manager Pattern으로 5개 멀티 에이전트 구성 및 코드 구현
[2편] AgentCore로 배포 및 운영
↓
AgentCore SDK로 코드 최소 수정
↓
Starter Toolkit CLI로 configure → deploy
↓
Runtime 엔드포인트 생성 → 호출
↓
Observability로 모니터링 / Memory로 대화 맥락 유지
이 전체 과정은 세 줄로 정리할 수 있습니다.
1. Kiro 기반으로 Spec-Driven Development
3단계 Spec 문서를 만들어 살아있는 문서로 관리하고, Power로 필요한 Context를 그때그때 주입하면서 Hook으로 일관성을 유지합니다.
2. Kiro 기반으로 Harness 구성
역할이 분리된 Agent 구성과 적절한 Tool, Skill, MCP 설정으로 Context, Memory 관리가 가능하고 병렬 실행을 통해 구현 속도를 끌어올릴 수 있습니다.
3. AgentCore로 Production-Ready 에이전트 구축
AgentCore SDK와 Starter Toolkit으로 간단하게 구성하고 배포하고, 세션 격리·활성 리소스 기반 과금·다중 프로토콜 지원으로 안전하고 효율적으로 운영합니다.
결론: 만드는 것보다 "운영하는 것"이 핵심이다
1편과 2편을 관통하는 핵심 메시지는 한 문장으로 요약됩니다.
"Not knowledge transfer, But method transfer." 에이전트에게 지식을 전달하는 것이 아니라, 생각하는 방법을 전달해야 합니다.
에이전트를 만드는 것 자체는 이제 어렵지 않습니다. 중요한 건 그 에이전트가 제대로, 안전하게, 일관되게 작동하도록 환경을 설계하고(1편, Kiro와 Harness Engineering), 안정적으로 배포하고 운영하는 것(2편, AgentCore)입니다. Kiro와 AgentCore는 그 여정을 함께하는 도구입니다.
AI 에이전트 도입 또는 AWS 기반 아키텍처 설계에 대해 궁금한 점이 있으시다면 스마일샤크로 문의해 주시기 바랍니다.
문의: [전문가 상담 받아보기]
본 글은 AWS Unicorn Day 2026 Seoul 세션 내용을 재구성한 글입니다.
