57편 · 약 18분

Amazon Bedrock AgentCore: 에이전트 세션을 서비스로 분리하고 Agents Classic 종료 전에 확인할 것

왜 지금 봐야 하나

2026년 7월 30일, AWS가 Amazon Bedrock Agents Classic의 신규 고객 수용을 중단한다. 기존 고객은 계속 쓸 수 있지만, 새로운 에이전트를 Bedrock Agents Classic 방식으로 만들 수 없게 된다. AWS가 내건 후계자는 Amazon Bedrock AgentCore다.

이름만 바뀐 게 아니다. 아키텍처 패러다임이 바뀌었다. Agents Classic은 에이전트 로직, 메모리, 도구 호출, 오케스트레이션을 AWS가 관리하는 단일 서비스 안에 모두 넣는 방식이었다. 반면 AgentCore는 이 역할을 다섯 개의 독립적인 서비스 컴포넌트로 쪼갠다. 에이전트 코드는 어떤 프레임워크(Strands, LangChain, LlamaIndex, 순수 Python 등)로 쓰든 상관없이 AgentCore 위에서 동작한다.

두 가지 변화가 실질적으로 중요하다.

첫째, 에이전트 세션이 클라우드 서비스가 됐다. 이전에는 에이전트 프로세스가 살아 있는 동안만 상태가 유지됐다. AgentCore Runtime은 세션 식별자를 HTTP 헤더로 관리하고, 세션 간 상태를 Memory 서비스에 저장한다. 프로세스가 죽어도 대화가 이어진다.

둘째, 가드레일이 도구 호출 경계마다 적용된다. 2026년 6월 GA된 AgentCore Gateway의 Guardrails 정책 지원으로, 에이전트가 도구를 호출하거나 응답을 받을 때마다 프롬프트 인젝션, 유해 콘텐츠, 민감 정보 노출을 실시간으로 차단할 수 있다. 같은 달 출시된 InvokeGuardrailChecks API는 가드레일 리소스를 미리 생성하지 않고도 요청별로 특정 검사를 선택적으로 적용하는 방식을 가능하게 했다.

이 글은 AgentCore의 다섯 컴포넌트가 어떻게 작동하는지, 그리고 Agents Classic에서 전환하기 전에 팀이 확인해야 할 사항을 다룬다.

배경: Agents Classic에서 AgentCore로

Bedrock Agents Classic(2023년 11월 출시)은 에이전트 작동에 필요한 모든 것을 AWS가 관리하는 방식이었다. 개발자는 Foundation Model, Action Group(도구), Knowledge Base를 선택하고, 오케스트레이션 로직은 AWS가 담당했다.

이 접근의 문제는 유연성이었다. 자체 메모리 전략을 쓰거나, 커스텀 오케스트레이션 패턴(반복 계획, 반성, 구조화된 출력)을 적용하거나, 특정 프레임워크의 추상화를 활용하기가 어려웠다. 에이전트 패러다임이 빠르게 진화하면서 고정된 AWS 오케스트레이션 레이어가 병목이 됐다.

AgentCore는 이 구조를 뒤집는다. 오케스트레이션은 개발자 코드가 담당하고, AWS는 인프라 서비스(실행 환경, 메모리, 도구 접근, 인증, 관측성)를 제공한다.

항목	Agents Classic	AgentCore
오케스트레이션	AWS 관리	개발자 코드
에이전트 프레임워크	N/A (AWS 자체)	Strands, LangChain, 직접 구현 등 자유 선택
메모리 관리	세션 내 제한적	Short-term + Long-term 분리
도구 연결	Action Group	AgentCore Gateway (Lambda/OpenAPI)
가드레일 적용 지점	입출력 레벨	모든 도구 호출 경계
신규 고객 수용	2026.07.30 종료	현재 GA

AgentCore의 다섯 컴포넌트

개발자 에이전트 코드
Strands / LangChain / 직접 구현

↕ 배포 / 호출

AgentCore CLI
dev · deploy · invoke

→

Amazon Bedrock AgentCore

① Runtime
서버리스 실행 · 세션 격리
MCP / HTTP / A2A / AG-UI

② Memory
Short-term (세션 범위)
Long-term (의미 검색)

③ Gateway
Lambda / OpenAPI 래핑
Guardrails 정책 GA

④ Identity
IAM 기반 접근 제어
엔터프라이즈 권한

⑤ Observability
통합 성능 모니터링
트레이스 · 메트릭

관리형 도구
Web Search
Code Interpreter
Knowledge Base

AgentCore 5개 컴포넌트 아키텍처

① AgentCore Runtime: 에이전트 실행과 세션 격리

Runtime은 에이전트 코드를 실행하는 서버리스 환경이다. 개발자는 에이전트 코드를 컨테이너 이미지로 패키징하거나, AgentCore CLI가 제공하는 빌드 파이프라인을 쓴다.

# 로컬 테스트
agentcore dev

# AWS에 배포 (서버리스 환경으로 자동 패키징)
agentcore deploy

# 배포된 에이전트 호출 (세션 유지)
agentcore invoke --session-id my-session-001

세션 격리 메커니즘

세션은 HTTP 헤더로 전달된다. 프로토콜별 헤더 이름이 다르다.

프로토콜	세션 헤더
MCP	`Mcp-Session-Id`
HTTP / A2A / AG-UI	`X-Amzn-Bedrock-AgentCore-Runtime-Session-Id`

세션 식별자가 동일하면 Runtime은 같은 실행 컨텍스트를 재사용하거나, Memory 서비스에서 이전 대화 내용을 복원한다. 에이전트 프로세스가 종료되더라도 세션은 Memory에 보존된다.

Runtime은 MCP, A2A, AG-UI 프로토콜을 네이티브로 지원한다. 즉, MCP 호환 클라이언트에서 AgentCore에 배포된 에이전트를 직접 호출할 수 있고, A2A 프로토콜로 에이전트 간 태스크를 위임할 수 있다.

② AgentCore Memory: 단기 기억과 장기 기억의 분리

Memory는 AgentCore가 Agents Classic과 가장 명확하게 다른 지점이다. Agents Classic은 세션 내 대화 이력을 보존하는 수준이었다. AgentCore Memory는 두 계층으로 분리한다.

Short-term Memory (단기 기억)

범위: actorId + sessionId 조합으로 격리
내용: 현재 대화의 원시 이벤트 (메시지, 도구 호출, 응답)
접근: 동기식 — 에이전트가 응답할 때 바로 조회

Long-term Memory (장기 기억)

범위: actorId 기준 (세션 경계를 넘어 보존)
내용: 사용자 선호, 대화 요약, 도메인 지식 등 구조화된 인사이트
추출: 비동기식 — 응답 후 백그라운드에서 처리
검색: 의미(semantic) 검색으로 관련 장기 기억을 조회

에이전트 응답 반환
    ↓
Short-term Memory에 대화 이벤트 기록 (동기)
    ↓ (비동기, 백그라운드)
Long-term Memory에 인사이트 추출
(선호도, 요약, 패턴 → 구조화 저장)

이 구조의 실용적 의미는 이렇다. 사용자가 한 번 "답변은 짧게" 또는 "SQL 예시 포함"이라고 말하면, 다음 세션에서도 Long-term Memory가 이 선호를 제공한다. 개발자가 별도 선호 저장 로직을 구현하지 않아도 된다.

③ AgentCore Gateway: 도구를 서비스로 등록하기

Gateway는 기존 백엔드(Lambda 함수, OpenAPI 스펙)를 에이전트가 호출할 수 있는 도구 엔드포인트로 노출한다. 코드 재작성 없이 기존 Lambda를 에이전트 도구로 등록할 수 있다.

2026년 6월 GA: Guardrails 정책 지원

이것이 운영상 중요한 변화다. Gateway에 Guardrails 정책을 연결하면, 에이전트가 Gateway를 통해 도구를 호출하거나 결과를 받을 때마다 가드레일이 작동한다.

적용 지점:

에이전트 → Gateway 요청 (입력 검사: 프롬프트 인젝션, 민감 정보)
Gateway → 에이전트 응답 (출력 검사: 유해 콘텐츠, 개인정보)

이전 아키텍처에서는 이 검사를 애플리케이션 레이어에서 직접 구현해야 했다. Gateway Guardrails는 이 로직을 인프라 레이어로 내린다.

관리형 도구 세 가지

Gateway 없이 직접 쓸 수 있는 AWS 관리형 도구도 있다.

도구	설명
Web Search	완전 관리형. 데이터가 고객 AWS 환경 밖으로 나가지 않음. 현재 웹 정보 + 출처 인용
Code Interpreter	코드 실행 샌드박스. 에이전트가 코드를 작성하고 실행 결과를 확인할 수 있음
Bedrock Knowledge Base	문서 저장소 + RAG 검색

④⑤ Identity와 Observability

Identity: IAM 역할 기반으로 AgentCore 컴포넌트 간 접근을 제어한다. 에이전트 코드가 Memory, Gateway, 관리형 도구에 접근하는 권한을 IAM 정책으로 명시한다. 멀티 테넌트 환경에서 에이전트 간 데이터 격리를 강제하는 데 사용된다.

Observability: 별도 모니터링 설정 없이 런타임 레이턴시, 메모리 읽기/쓰기 빈도, Gateway 호출 결과, 가드레일 차단 횟수 등을 CloudWatch로 수집한다. X-Ray 트레이스도 자동으로 생성된다.

InvokeGuardrailChecks API (2026년 6월)

Gateway Guardrails와 별개로, Bedrock 레벨에서도 가드레일 적용 방식이 바뀌었다.

기존 Bedrock Guardrails는 가드레일 리소스를 미리 생성하고, 모델 호출 시 연결하는 방식이었다. 새로운 InvokeGuardrailChecks API는 리소스를 만들지 않고 요청별로 특정 검사만 선택적으로 적용할 수 있다.

# 기존 방식: 가드레일 리소스 생성 후 연결
response = bedrock_runtime.invoke_model(
    modelId="...",
    guardrailIdentifier="my-guardrail-id",  # 미리 만든 리소스
    guardrailVersion="1",
    body=...
)

# 새 방식: 리소스 없이 요청별 선택적 검사
response = bedrock_runtime.invoke_guardrail_checks(
    checks=[
        {"type": "PROMPT_INJECTION"},
        {"type": "SENSITIVE_INFORMATION"},
    ],
    content={"text": user_input}
)

이것이 유용한 상황: 에이전트 파이프라인의 각 단계마다 다른 검사 집합을 적용하고 싶을 때. 예를 들어 사용자 입력 단계에서는 프롬프트 인젝션만 검사하고, 응답 단계에서는 PII(개인정보)와 유해 콘텐츠를 검사하는 식이다. 매번 다른 가드레일 리소스를 만들 필요 없이 API 호출 파라미터로 제어한다.

Agents Classic에서 AgentCore로: 전환 체크리스트

2026년 7월 30일 이후 신규 Agents Classic 에이전트를 만들 수 없다. 기존 에이전트는 유지된다. 하지만 새 기능 추가나 새 프로젝트는 AgentCore로 시작해야 한다.

지금 해야 할 것

[ ] 팀의 현재 Agents Classic 에이전트 목록 파악 (AWS Console → Bedrock → Agents)
[ ] 신규 개발은 AgentCore 또는 Strands SDK로 시작
[ ] AgentCore Runtime에서 쓸 에이전트 프레임워크 결정 (Strands, LangChain, 직접 구현)
[ ] 기존 Action Group이 Lambda 기반이면 → AgentCore Gateway로 마이그레이션 경로 검토
[ ] Knowledge Base 연결이 있다면 → AgentCore Managed Knowledge Base 검토

판단 기준

상황	권장
새 에이전트 프로젝트	AgentCore + Strands 또는 선호 프레임워크
Agents Classic 기존 에이전트 운영 중	즉시 마이그레이션 불필요. 기능 추가 시 AgentCore 검토
Action Group이 복잡한 오케스트레이션	AgentCore Runtime + 자체 오케스트레이션 코드로 전환
세션 지속성이 필요	AgentCore Memory (Short-term + Long-term 구조 활용)
멀티 에이전트 협업 필요	AgentCore Runtime (A2A 프로토콜 네이티브 지원)

도구 연결 비교

Agents Classic
    ↓
Action Group (AWS 관리 오케스트레이션)
    └─ Lambda 함수 (AWS가 직접 호출)

AgentCore
    ↓
개발자 에이전트 코드 (프레임워크 자유 선택)
    └─ AgentCore Gateway 등록
        └─ Lambda 함수 (에이전트 코드가 Gateway를 통해 호출)

Gateway 등록은 AWS Console 또는 SDK로 한다. OpenAPI 스펙을 업로드하거나 Lambda ARN을 지정하면 Gateway가 에이전트 도구 엔드포인트로 노출된다.

운영 판단 기준

AgentCore Runtime이 적합한 경우

에이전트 로직이 복잡하거나 자주 바뀐다 (프레임워크 의존성 없이 배포 분리)
세션이 수시간 이상 지속된다 (Long-term Memory 활용)
멀티 에이전트 시스템을 구축한다 (A2A 프로토콜 지원)
도구 호출마다 보안 검사가 필요하다 (Gateway Guardrails)

AgentCore가 과도한 경우

단순한 단발성 LLM 호출 (Bedrock InvokeModel이면 충분)
에이전트 세션이 없는 배치 처리 (Lambda + Bedrock 직접 호출)
기존 Agents Classic이 잘 작동 중이고 새 기능 추가 계획이 없는 경우

비용 구조 주의사항 AgentCore는 Runtime 실행 시간, Memory 읽기/쓰기, Gateway 호출 횟수, Web Search 쿼리 수를 별도로 과금한다. Agents Classic의 단일 에이전트 호출 요금 구조와 다르다. 트래픽이 낮은 데모/개발 환경에서는 총 비용이 비슷하지만, 빈번한 도구 호출과 장기 세션이 있는 프로덕션에서는 Gateway와 Memory 비용을 먼저 추정해야 한다.

Open question

Agents Classic의 운영 종료(단순 신규 수용 종료가 아닌 서비스 전체 종료) 일정은 AWS가 아직 공표하지 않았다.
AgentCore Gateway의 Guardrails 정책에서 커스텀 Word 필터와 PII 감지의 레이턴시 영향은 워크로드마다 다르다. 프로덕션 도입 전 벤치마크 필요.
Long-term Memory의 의미 검색 정밀도와 인사이트 추출 품질은 사용 패턴에 따라 달라지며, 공개된 SLA 수치가 없다.