“챗봇은 잘 답변하는데, 왜 직접 해주지는 못할까?”
AI를 업무에 활용해 보신 분이라면 한 번쯤 이런 생각을 해보셨을 겁니다. ChatGPT나 클로드에게 “주문 취소하고 환불 처리해 주세요”라고 말하면, 돌아오는 대답은 대부분 “마이페이지에서 환불 요청을 올려주세요”입니다. 아무리 똑똑한 AI라도 결국 실행은 사람 몫이었던 거죠.
그런데 이제 그 한계가 깨지고 있습니다. AI가 직접 시스템에 접속해서 주문을 조회하고, 환불 가능 여부를 확인하고, 처리까지 완료하는 시대가 열렸습니다. 이것이 바로 에이전트 AI(Agentic AI) 의 핵심입니다.
이 글에서는 AWS가 제공하는 에이전트 AI 서비스 생태계를 한눈에 정리해 드리겠습니다. 개발자가 아니더라도 “아, 이런 구조로 돌아가는구나” 하고 흐름을 잡으실 수 있도록 쉽게 설명해 보겠습니다.
AI 에이전트, 기존 챗봇과 뭐가 다른 걸까
기존 생성형 AI는 질문에 답하고, 요약하고, 코드를 짜주는 단일 작업에 강했습니다. 하지만 “이렇게 하세요”까지만 알려줄 뿐, 직접 실행하지는 못했습니다.
AI 에이전트는 근본적으로 다릅니다. 목표를 받으면 스스로 계획을 세우고, 필요한 도구를 골라서, 업무가 완수될 때까지 자율적으로 실행합니다. 핵심 차이는 실행 주체입니다. 생성형 AI에서는 사람이 실행 주체였다면, 에이전트 AI에서는 AI 시스템 자체가 실행 주체가 됩니다.
구체적인 예를 하나 들어보겠습니다. 고객이 “환불해 주세요”라고 요청하면, AI 에이전트는 CRM에서 고객 정보를 확인하고, 주문 시스템에서 주문 상태를 조회하고, 결제 시스템에서 환불을 실행합니다. 사람이 탭 3개를 열어놓고 하던 일을 하나의 프로세스로 자동 처리하는 것입니다.
더 나아가면 멀티 에이전트 구조도 가능합니다. 팀장이 팀원에게 업무를 분배하듯, 상담 에이전트가 문의를 받고, 환불 전문 에이전트가 환불을 처리하고, 물류 확인 전문 에이전트가 배송 상태를 확인하는 식입니다.
실제로 쓰이고 있는 사례들
이미 국내외 기업들이 에이전트 AI를 적극 도입하고 있습니다.
배달의민족은 ‘물어보세’라는 사내 지식 에이전트를 운영하고 있습니다. 처음에는 단순한 질의응답 챗봇이었지만, 지금은 컨플루언스, 위키, 지라, 슬랙 등 업무 전반의 데이터를 통합해서 직원이 질문하면 에이전트가 스스로 어디서 정보를 찾을지 판단하고, 필요하면 SQL까지 생성해서 답변합니다. 전사 도입 후 업무 효율성이 30% 향상되었다고 합니다.
CJ온스타일은 라이브 커머스 방송 중 채팅방 응대에 멀티 에이전트를 적용했습니다. 사람이 물리적으로 다 응대하기 어려운 수많은 질문을 전문화된 에이전트들이 나눠서 처리하면서, 답변율이 3배 증가하고 평균 20초 내에 응답하는 성과를 거뒀습니다.
AI 에이전트의 세 가지 구성 요소
AI 에이전트를 만들려면 세 가지가 필요합니다.
첫째, 모델(Model) — 생각하는 두뇌에 해당합니다. 클로드, GPT 같은 파운데이션 모델이 여기에 속합니다.
둘째, 프롬프트(Prompt) — 모델에게 “너는 고객 상담 에이전트야, 이런 규칙에 따라 행동해”라고 지시하는 역할입니다.
셋째, 도구(Tool) — MCP 서버를 호출하거나, API를 호출하거나, 데이터베이스에 접근하는 팔다리 역할입니다.
기존 생성형 AI에는 모델과 프롬프트만 있었습니다. 여기에 도구가 추가되면서 에이전트가 실제 행동을 할 수 있게 된 것입니다.
AWS 에이전트 AI 서비스, 세 기둥으로 이해하기
AWS가 에이전트 AI를 위해 제공하는 서비스는 크게 세 가지 축으로 나뉩니다.
1. Amazon Bedrock — 파운데이션 빌딩 블록
Amazon Bedrock은 생성형 AI 애플리케이션을 만들 때 필요한 기반을 한곳에 모아 놓은 서비스입니다. 모델 선택, API 연동, 사내 데이터 연결, 보안 설정까지 하나의 서비스 안에서 처리할 수 있습니다.
다양한 파운데이션 모델 제공 — Bedrock 안에서 100개 이상의 모델을 사용할 수 있습니다. Anthropic의 클로드 모델, Amazon 자체 개발 모델인 Nova, 그리고 다양한 오픈소스 모델까지 선택지가 넓습니다. 중요한 건 개수가 아니라 선택권입니다. 복잡한 환불 판단은 클로드 Opus 같은 고성능 모델을 쓰고, 단순 FAQ 응답은 Nova Lite 같은 경량 모델을 쓰는 식으로, 하나의 에이전트 안에서도 작업에 따라 최적의 모델을 골라 쓸 수 있습니다.
RAG(검색 증강 생성) — LLM은 학습 시점까지의 일반 데이터만 알고 있기 때문에, 우리 회사의 인사 규정이나 고객 대응 가이드 같은 내부 데이터에 대해서는 답할 수 없습니다. RAG는 이 문제를 해결합니다. 사용자 질문이 들어오면, 먼저 내부 지식 베이스를 검색하고, 그 결과를 활용해서 정확한 답변을 생성하는 방식입니다.
실제 서비스에 RAG를 올리려면 문서를 어떻게 잘라야 하는지(청킹), 어떤 임베딩 모델을 쓸지, 어떤 벡터 데이터베이스가 적합한지, 검색 정확도를 어떻게 높일지 등 고려할 것이 굉장히 많습니다. Bedrock Knowledge Base는 이런 복잡한 구성을 콘솔에서 몇 번의 클릭만으로 구현할 수 있게 해줍니다.
프롬프트 캐싱 — 에이전트를 운영하면 매 요청마다 시스템 프롬프트가 반복됩니다. “너는 고객 상담 에이전트야, 이러한 규칙에 따라…” 이 부분이 매번 똑같은데 LLM은 매번 처음부터 처리합니다. 프롬프트 캐싱을 켜면 반복되는 부분을 한 번만 처리하고 캐시에 저장해서, 어떤 케이스에서는 비용 최대 90%, 응답 시간 최대 85%까지 절감됩니다.
보안과 가드레일 — Bedrock을 통해 보내는 모든 입출력 데이터는 파운데이션 모델 학습에 사용되지 않고, 모델 제공사에게도 전달되지 않습니다. 완전히 격리된 환경에서 관리됩니다. 추가로 Bedrock Guardrails를 통해 유해 콘텐츠 필터링, 개인 식별 정보(PII) 자동 감지 및 제거, 할루시네이션 검증까지 가능합니다.
2. Strands Agents — 에이전트 개발 프레임워크
Strands Agents는 몇 줄의 파이썬 코드만으로 AI 에이전트를 만들 수 있는 오픈 소스 SDK입니다. AWS가 2023년에 시작한 프로젝트로, 기존의 무겁고 복잡한 프레임워크와 차별화됩니다.
LangGraph나 CrewAI 같은 프레임워크는 입력과 출력을 명확하게 정의해야 하는 워크플로우 방식입니다. Strands는 다릅니다. 요즘 파운데이션 모델의 추론 능력이 워낙 뛰어나기 때문에, 이런 것들을 일일이 정의하지 않아도 모델이 알아서 판단하도록 설계되어 있습니다.
실제 코드를 보면 놀라울 정도로 간결합니다.
from strands import Agent
agent = Agent(tools=["calculator"])
result = agent("80 나누기 4는?")
모델을 따로 지정하지 않으면 Bedrock의 Anthropic Claude Sonnet 모델을 기본으로 사용합니다. 에이전트가 요청을 받아서 스스로 계획을 세우고, 필요한 도구를 호출하고, 결과를 반환하는 과정이 이 몇 줄 안에서 일어납니다.
MCP 서버, AWS 서비스와의 통합도 기본 내장되어 있고, 커스텀 도구도 자유롭게 연결할 수 있습니다.
3. Amazon Bedrock AgentCore — 배포와 운영 플랫폼
에이전트를 만들었으면 이제 프로덕션에 올려야 합니다. 그런데 PoC에서 잘 돌아가던 에이전트를 실제 서비스에 올리려고 하면 생각보다 많은 문제에 부딪힙니다. AgentCore는 이런 프로덕션 과제를 해결하는 엔터프라이즈 운용 플랫폼입니다.
AgentCore의 핵심 기능들을 하나씩 살펴보겠습니다.
AgentCore 핵심 기능 7가지
Runtime — 서버리스 배포
기존 에이전트 코드에 세 줄만 추가하면 서버리스로 바로 배포됩니다. 서버 세팅, 컨테이너 구성, 로드 밸런서, 오토 스케일링 같은 인프라 작업이 필요 없습니다.
특히 에이전트 워크로드는 일반 웹 서비스와 성격이 다릅니다. LLM 호출 한 번에 몇 초씩 걸리고, 복잡한 리서치 에이전트는 몇 시간이 걸릴 수도 있습니다. AgentCore Runtime은 최대 8시간까지 장기 실행을 지원합니다.
보안 측면에서 가장 눈에 띄는 특징은 마이크로VM 기반 세션 격리입니다. 일반 컨테이너 방식에서는 고객 A, B, C가 같은 컨테이너를 공유하기 때문에 보안 취약점이 생길 수 있습니다. AgentCore는 각 세션마다 독립된 마이크로VM을 생성해서 물리적으로 완전히 분리합니다. 세션이 종료되면 마이크로VM이 삭제되고 데이터도 완전히 소거됩니다.
Memory — 단기·장기 기억
AI 에이전트는 기억을 해야 합니다. 방금 한 말을 기억해야 하고, 과거 대화에서 학습해야 하고, 재시작해도 기억이 유지되어야 합니다.
장기 메모리를 직접 구현하려면 대화 내용 요약, 핵심 정보 추출, 저장·업데이트·삭제 로직, 별도 DB 구축까지 상당히 복잡한 작업이 필요합니다. AgentCore Memory는 대화가 끝나면 비동기로 핵심 정보를 자동 추출해서 장기 메모리에 저장하고, 다음 대화에서 자동으로 불러옵니다.
예를 들어 “이 고객은 강남에 살고, 매운 음식을 좋아하고, 지난번에 배송 문제가 있었다” 같은 정보를 자동으로 추출하고 관리하는 것입니다.
Gateway — 도구 통합 관리
에이전트가 사용하는 도구가 수십, 수백 개로 늘어나면 관리가 어려워집니다. 더 큰 문제는 LLM이 도구가 너무 많으면 혼란스러워한다는 것입니다. 시스템 프롬프트가 비대해지고, 비용이 늘고, 정확도가 떨어집니다.
Gateway는 REST API, Lambda 함수, MCP 서버 등 다양한 도구를 하나의 인터페이스로 통합하고, 시맨틱 검색을 통해 에이전트에게 300개 중 정말 필요한 4개만 골라서 제공합니다. OpenAPI 스펙만 있으면 기존 API를 도구로 변환할 수 있고, Salesforce, Slack, Jira 같은 인기 서비스는 원클릭 통합을 지원합니다.
Identity — 인증과 권한 관리
에이전트 세계에서 인증은 훨씬 복잡합니다. 사용자가 에이전트를 쓸 때도 인증이 필요하고, 다른 에이전트가 이 에이전트를 호출할 때도 인증이 필요하고, 에이전트가 구글 캘린더나 Salesforce 같은 외부 서비스에 접근할 때도 인증이 필요합니다.
AgentCore Identity는 이 전체를 대신 처리하는 통합 로그인 시스템입니다. 회사에서 이미 쓰고 있는 로그인 시스템(Okta, Cognito 등)을 그대로 연결할 수 있고, 모든 접근 기록이 로깅되어 감사 추적도 가능합니다.
Policy — 행동 경계 설정
에이전트가 자율적으로 행동하는 건 좋지만, 아무 제한 없이 모든 것을 할 수 있으면 위험합니다. AgentCore Policy는 에이전트에게 “여기까지만 해”라고 경계를 설정하는 서비스입니다.
예를 들어 환불 도구는 재무팀만 사용할 수 있게 하거나, 일반 직원이 호출했을 때는 1,000달러 이하의 환불만 처리하고 그 이상은 매니저 승인이 필요하도록 설정할 수 있습니다. 자연어로 정책을 작성하면 정책 언어로 자동 변환됩니다.
Observability — 실시간 모니터링
에이전트가 왜 그런 답변을 했는지 모르면, 문제가 생겼을 때 손을 쓸 수 없습니다. Observability는 에이전트의 각 단계별 추론을 기록하고, 어디서 문제가 발생했는지, 왜 특정 도구를 선택했는지까지 추적합니다.
세션 카운트, 동시 접속자, 응답 시간, 토큰 사용량, 에러율 등 핵심 지표를 AWS CloudWatch 대시보드에서 실시간으로 확인할 수 있습니다.
Evaluation — 품질 평가
에이전트가 잘하고 있는지 사람이 일일이 확인하는 건 비효율적입니다. AgentCore Evaluation은 LLM이 에이전트를 평가하는 방식을 씁니다. 에이전트가 실행한 내용을 다른 LLM이 보고, 목표 달성 여부, 정확성, 도구 사용 적절성 등을 자동으로 점수 매기고 이유까지 설명합니다.
13개의 기본 평가 기준이 제공되고, 비즈니스에 맞는 커스텀 기준도 추가할 수 있습니다. 프로덕션에서 실시간으로 평가가 돌기 때문에 품질 저하를 바로 감지할 수 있습니다.
빌드 → 배포 → 운영, 세 단계로 정리
정리하면 이렇습니다.
빌드 단계 — Gateway로 도구를 연결하고, Memory로 대화를 기억하고, Identity로 인증을 관리하고, Policy로 행동을 제어합니다.
배포 단계 — Runtime으로 서버리스 배포합니다. Browser Tool로 웹 자동화, Code Interpreter로 코드 실행도 지원됩니다.
운영 단계 — Observability로 모니터링하고, Evaluation으로 품질을 평가합니다.
이 모든 서비스는 독립적으로도 사용할 수 있습니다. 처음부터 전부 도입할 필요 없이, Runtime과 Memory만 먼저 쓰고 점차 확장하는 것도 가능합니다.
그래서 왜 AgentCore인가
핵심을 정리하면 이렇습니다.
프레임워크와 모델을 자유롭게 선택할 수 있는 완전 관리형 통합 플랫폼입니다. Strands뿐 아니라 LangGraph, CrewAI 등 어떤 프레임워크든, Bedrock뿐 아니라 OpenAI, Gemini 등 어떤 모델이든 사용할 수 있습니다.
직접 구축하면 수개월이 걸릴 수 있는 프로덕션 전환을 훨씬 빠르게 진행할 수 있습니다. 마이크로VM 격리와 Policy 정책으로 엔터프라이즈 보안도 확보됩니다. 서버리스 방식이라 비용 최적화와 운영 부담 경감도 함께 따라옵니다.
AI가 “이렇게 하세요”라고 알려주는 시대에서, AI가 “다 처리해 드렸습니다”라고 보고하는 시대로 넘어가고 있습니다. AWS의 에이전트 AI 서비스 생태계는 그 전환을 가장 빠르고 안전하게 실현할 수 있는 경로를 제시하고 있습니다.
에이전트 AI에 관심이 있으시다면, 먼저 Strands Agents로 간단한 에이전트를 만들어 보시고, Bedrock Knowledge Base로 RAG를 붙여보시고, AgentCore Runtime으로 배포해 보시는 것을 추천드립니다. 공식 GitHub 저장소에 샘플 코드와 핸즈온 가이드가 잘 정리되어 있어서 따라 하기 좋습니다.
