AWS AgentCore가 대신해 주는 것과 안 해 주는 것 (LLM이 아닌 에이전트 운영 틀)

"AWS AgentCore로 AI 에이전트를 만든다"는 말을 들었을 때, AgentCore가 실제로 무엇을 맡아 주고 무엇은 여전히 직접 골라야 하는지 정리한 글입니다.

사내 문서를 검색해서 답하는 챗봇을 이야기하다 보면 요즘 AgentCore 라는 이름이 자주 나옵니다. "RAG도, 그래프 DB도 AWS 안에서 다 된다더라" 같은 이야기와 함께 들으면, AgentCore 하나로 모델부터 검색까지 전부 해결되는 것처럼 느껴집니다.

공식 문서를 읽어 보면 AgentCore는 에이전트 코드를 올려 돌리고 운영하는 틀에 가깝습니다. 답을 만들어 내는 LLM도, 그 LLM을 돌리는 GPU도 AgentCore가 아닙니다. 이걸 구분하지 않으면 지금 겪는 문제가 AgentCore로 풀리는지 판단이 엇갈립니다.

- AgentCore = 에이전트를 실행하고, 기억하고, 인증하고, 추적하는 운영 기반

- 어떤 모델이든, 어떤 프레임워크든 붙일 수 있다는 것이 특징이다

- 모델 호출, RAG 저장소, 리랭커는 각각 별도 서비스이고 따로 고르고 따로 과금된다

- 내 문제가 "모델과 GPU" 쪽이라면 AgentCore로는 풀리지 않는다

1. AgentCore가 맡아 주는 것

AgentCore는 여러 구성 요소의 묶음입니다. 이름만 보면 많아 보이지만, 공통점은 전부 에이전트를 서비스로 운영할 때 필요한 주변 기능이라는 점입니다.

- Runtime: 에이전트 코드를 서버 없이 올려 실행한다

- Gateway: 이미 있는 API를 에이전트가 부를 수 있는 도구(MCP)로 감싼다

- Memory: 대화의 단기, 장기 기억을 저장한다

- Identity: 사용자와 도구 접근 권한을 관리한다

- Observability: 호출 흐름과 구간별 지연을 추적한다

- Policy, Evaluations: 에이전트 행동을 정책으로 통제하고 응답 품질을 평가한다

정리하면 "질문을 받아 도구를 부르고, 결과를 모아 모델에게 넘기고, 답을 돌려주는" 에이전트의 뼈대를 대신 운영해 주는 서비스입니다. 서울 리전도 지원 대상에 들어 있어서, 국내 리전 안에서 쓰는 데는 큰 걸림돌이 없습니다.

2. AgentCore 밖에 있는 것

반대로 챗봇의 품질을 실제로 좌우하는 부분은 대부분 AgentCore 바깥에 있습니다.

- 모델(LLM): Bedrock에서 제공하는 모델을 호출하거나, 다른 곳의 모델을 직접 연결한다

- RAG 저장소: Bedrock Knowledge Bases 같은 별도 서비스를 쓴다

- 리랭커: 검색 결과 순서를 다시 매기는 Bedrock Rerank도 별도 서비스다

여기서 주의할 점은 리전입니다. 글을 쓰는 시점의 공식 문서 기준으로 Bedrock Rerank 모델은 서울 리전이 지원 목록에 없고, 가장 가까운 곳이 도쿄 리전입니다. 리랭커를 쓰면 질문과 검색 결과가 국외 리전으로 나가는 구조가 되므로, 데이터 위치에 제약이 있는 조직이라면 먼저 확인해야 합니다.

3. 내 문제가 AgentCore로 풀리는지 가르는 법

AgentCore를 검토할 때는 "지금 무엇이 고장 나 있는가"부터 적어 보면 판단이 쉬워집니다.

- 응답이 느리다, 모델을 돌릴 장비가 없다: 모델 서빙 문제라 AgentCore로는 안 풀린다

- 애매한 질문에 엉뚱한 문서를 가져온다: 검색 품질 문제라 리랭커나 검색 설계를 봐야 한다

- 에이전트 서버 운영, 인증, 대화 기억 구현이 부담이다: AgentCore가 맞는 자리다

- 어디서 시간이 걸리는지 추적이 안 된다: Observability가 도움이 된다

결국 AgentCore는 잘 돌고 있는 뼈대를 대신 운영해 주는 서비스입니다. 막혀 있는 곳이 모델과 GPU라면, 진짜 선택지는 AgentCore냐 아니냐가 아니라 모델을 API로 빌려 쓸지, 장비를 사서 직접 올릴지입니다.

4. 모델을 직접 올려야 하는 경우

보안 때문에 외부 LLM을 쓸 수 없거나, 특정 모델을 써야 한다는 조건이 있는 프로젝트도 많습니다. 이런 경우에는 AgentCore의 "어떤 모델이든 붙일 수 있다"는 장점이 오히려 핵심이 아닙니다. 모델을 어디에서 돌릴지가 먼저 정해져야 하기 때문입니다.

그렇다고 AgentCore에서 가져올 것이 없는 건 아닙니다. 요청마다 구간별 지연을 남기는 추적 방식이나, 기존 API를 도구로 감싸는 도구화 설계는 자체 서버로 운영하더라도 그대로 참고할 만합니다.

5. 정리

AgentCore는 LLM이 아니라 에이전트를 운영하는 틀입니다. 실행, 기억, 인증, 추적은 맡아 주지만 모델과 RAG 저장소, 리랭커는 따로 고르고 따로 비용을 내야 합니다.

검토를 시작하기 전에 지금 막힌 곳이 뼈대인지, 모델과 검색인지부터 나눠 보면 됩니다. 그리고 리랭커처럼 서울 리전에 없는 서비스가 끼어 있는지는 공식 문서의 리전 목록으로 꼭 확인해야 합니다. 리전 지원은 자주 바뀌므로, 이 글의 리전 정보도 쓰는 시점에 다시 확인하시길 권합니다.

여기까지 AWS AgentCore가 무엇을 맡고 무엇은 맡지 않는지에 대해서 작성해봤습니다. 여기까지 읽어주셔서 감사합니다!