AWS Context는 RAG를 건너뛴다. Continuum은 CVE를 직접 검증한다.

뉴욕 AWS Summit에서 아마존이 내놓은 메시지는 이례적으로 직설적이었다. 오늘날 AI 에이전트가 프로덕션에서 실패하는 이유는 모델이 약해서가 아니라, 에이전트가 당신의 비즈니스를 모르기 때문이며, 에이전트가 생성하는 코드는 누구도 다 치우기 어려울 만큼 빠르게 보안 부채를 쌓고 있다는 것이다.

AWS가 본 문제: AI 에이전트는 왜 자신 있게 틀린 답을 내놓는가

AI 에이전트가 자신 있지만 틀린 답을 내놓는 이유는 모델과 도구를 호출할 수는 있어도 조직의 데이터 관계, 소유권, 권위 있는 출처를 보여주는 지도가 없기 때문이다. 그래서 에이전트는 추측하고, 그 추측을 유창하게 말한다. 이것이 AWS가 뉴욕 AWS Summit에서 2026년 6월 17일 제시한 프레임이었다. AWS는 기업용 에이전트 도입을 가로막는 두 가지 공백을 짚고, 각각에 대응하는 서비스인 비즈니스 맥락 부족을 겨냥한 AWS Context와 보안 부족을 겨냥한 AWS Continuum을 공개했다 .

첫 번째 공백은 맥락이다. 에이전트는 도구를 호출하거나 데이터베이스를 질의할 수 있지만, 관리되는 관계 데이터가 없으면 어떤 레코드가 권위 있는지, 누가 시스템을 소유하는지, 어떤 비즈니스 규칙이 적용되는지 판단할 수 없다. AWS는 그 결과를 "자신 있지만 부정확한" 추천이라고 설명한다. 모델이 빈틈을 올바른 답이 아니라 그럴듯한 답으로 메우는 것이다 (source: The Decoder, 2026-06). Context는 런타임에서 지식 그래프를 통해 조직 내 관계를 노출함으로써 이 문제를 직접 겨냥한다.

두 번째 공백은 보안 대응 속도다. AI는 이제 사람이 결과물을 선별할 수 있는 속도보다 더 빠르게 코드를 작성하고, 검토되지 않은 산출물은 CVE 백로그로 쌓인다. AWS는 Continuum을 사람이 검토 주기를 기다리는 방식이 아니라, 지속적인 발견, 우선순위 지정, 익스플로잇 검증, 수정까지 기계 속도로 처리해 그 백로그를 줄이는 서비스로 포지셔닝한다 (source: About Amazon, 2026-06).

개발자가 이를 평가할 때 중요한 점이 하나 있다. 두 서비스 모두 새로운 인프라가 아니다. 둘 다 Amazon Bedrock AgentCore 위에 올라간다. AgentCore는 2025년 10월 13일부터 정식 제공되었으며, 에이전트가 이미 실행되는 런타임, 메모리, 아이덴티티 기본 요소를 제공한다 . Context와 Continuum은 그 스택을 대체하는 것이 아니라 애플리케이션 계층에 더해지는 요소다. 이 구분은 도입 방식과 도입 여부를 결정하는 데 영향을 준다.

AWS Context는 조직의 관계를 그래프로 어떻게 매핑하는가

AWS Context는 회사의 기존 데이터 전반에 걸친 관계를 자동으로 매핑하고, 런타임에서 "agentic search"를 통해 에이전트에 노출하는 관리형 지식 그래프 서비스다 . 직접 구축한 검색 파이프라인 대신, 에이전트는 그래프를 바로 질의해 관리되는 조직 관계, 비즈니스 규칙, 도메인 지식을 가져온다. AWS가 "자신 있지만 부정확한" 추천의 원인으로 지목한 바로 그 빠진 계층이다 .

빠른 답변: AWS Context는 데이터베이스, CRM, 문서, 이메일, Slack 같은 이기종 소스를 수집하고, 수동 ETL이나 청킹 없이 그 관계를 자동으로 추론해 지식 그래프로 만든다. 에이전트는 "agentic search"로 여기에 접근하며, 비즈니스 규칙과 접근 제어가 수집 단계에서 적용되기 때문에 자신의 아이덴티티가 허용하는 데이터만 검색한다 .

수집 모델이야말로 이것을 직접 만든 RAG 스택과 구분하는 지점이다. Context는 데이터베이스, CRM 시스템, 문서, 이메일, Slack 같은 채팅 도구 등 구조화 및 비구조화 소스 전반에서 관계를 수집하고 추론한다. 이를 위해 스키마 매핑, ETL 작업, 청킹 로직을 직접 작성할 필요가 없다 . 임베딩 파이프라인과 재청킹 전략을 손으로 유지해 온 개발자에게 실질적인 제안은 이것이다. AWS는 Context를 검색 파이프라인 개발이나 인프라 프로비저닝이 필요 없는 관리형 대안으로 내세운다 .

거버넌스는 나중에 덧붙이는 것이 아니라 소스 단계에서 강제된다. Context는 수집 중에 비즈니스 규칙과 접근 제어를 적용하므로, 에이전트는 항상 관리되는 데이터만 보게 된다. 에이전트와 그래프 사이에 별도의 권한 부여 계층을 연결하지 않아도, 에이전트는 자신의 아이덴티티에 허용된 것만 검색한다 . 실제로 이는 개발자가 보통 따로 다루는 두 가지 작업, 즉 검색 인덱스를 만드는 일과 행 또는 문서 수준 접근을 강제하는 일을 하나의 관리형 경계 안으로 합친다.

AWS는 Context가 사용할수록 개선되는 것으로도 설명한다. 그래프가 시간이 지나며 에이전트의 질의 패턴에서 학습한다는 것이다. AWS는 그 가치를 이렇게 요약한다.

"Context is what makes your agent's tenth decision better than its first." — AWS, AWS Summit New York 2026 (source: AWS News Blog)

이는 이미 전달된 결과라기보다 검증해야 할 주장으로 보는 편이 맞다. AWS는 그래프 품질이나 검색 정확도에 대한 벤치마크를 공개하지 않았고, Context 자체도 정식 출시일 없이 "coming soon"으로만 설명되어 있다 . 아키텍처는 그럴듯하고 개발자 경험도 매력적이지만, "질의 패턴에서 학습한다"는 동작은 에이전트가 실행에 옮길 의사결정에 신뢰하기 전에 자신의 데이터 관계 위에서 직접 측정해야 할 부분이다.

기술 내부 구조: Apache Iceberg, S3 Tables, Glue Catalog

AWS Context는 완전히 새로운 연구 프로젝트가 아닙니다. 이미 Amazon Quick을 구동하는 지식 그래프 기술 위에서 실행되며, 이를 에이전트용 관리형 서비스로 다시 패키징한 것입니다 . 이 재사용은 평가에서 중요합니다. 데모가 아니라 운영 경험이 있는 그래프 엔진에 거는 셈이므로, "핵심 기술이 실제로 작동하는가"라는 위험은 낮아지고 남는 질문은 여러분의 데이터와 접근 규칙 쪽으로 이동합니다.

스토리지 계층은 익숙한 AWS 기반 요소로 구성되며, 바로 그 점이 핵심입니다. Context는 메타데이터를 S3 Tables 위의 Apache Iceberg 형식으로 저장하고, 스키마와 계보 추적을 위해 AWS Glue Data Catalog와 통합됩니다 . 개발자 입장에서는 다음과 같은 실질적 의미가 있습니다:

• S3 Tables 위의 Iceberg는 그래프 메타데이터가 에이전트를 통해서만 접근할 수 있는 블랙박스 저장소가 아니라, 쿼리하고 버전 관리할 수 있는 오픈 테이블 형식에 놓인다는 뜻입니다.
• Glue Data Catalog 통합은 이미 관리 중일 수 있는 카탈로그에서 스키마와 계보를 가져온다는 뜻입니다. 따라서 그래프는 컬럼 정의와 출처 정보를 새로 정의하지 않고 그대로 상속합니다.
• 두 선택 모두 Context를 별도 원천 시스템으로 만들지 않고 기존 AWS 레이크하우스 안에 머물게 합니다.

배포 측면의 핵심 메시지는 파이프라인이 필요 없다는 점입니다. AWS는 Context를 검색 파이프라인 개발, 임베딩 인프라, 프로비저닝할 벡터 스토어가 필요 없는 서비스로 설명하며, 직접 구축한 RAG 스택의 관리형 대안으로 포지셔닝합니다 . RAG를 만들어 본 적이 있다면, 청킹, 임베딩, 인덱스 튜닝, 재임베딩 유지보수 루프가 로드맵에서 빠지는 것입니다. 대신 일반적인 관리형 서비스의 절충이 따릅니다. 관계를 어떻게 추론하고 순위화하는지에 대한 제어권은 줄어들지만, 검색 기반 요소를 직접 운영하지 않아도 됩니다.

가장 큰 단서는 가용성입니다. 2026년 6월 기준 AWS Context는 아직 "coming soon"으로만 설명되며, 정식 출시일, 리전 목록, 가격이 공개되지 않았습니다 . 이는 사용량 기반 가격이 이미 공개된 AWS의 다른 에이전트 스택과 비교하면 의미 있는 공백입니다. 지금 아키텍처를 검토할 수는 있지만, AWS가 숫자와 날짜를 붙이기 전까지는 비용 모델이나 리전별 지연 시간 테스트를 실행할 수 없습니다.

Continuum의 CVE 수명주기: 우선순위 지정, 익스플로잇 검증, 맞춤형 수정

AWS Continuum은 취약점의 전체 수명주기, 즉 발견, 우선순위 지정, 악용 가능성 검증, 수정을 기계 속도로 관리하는 AI 네이티브 보안 서비스입니다. 2026년 6월 17일 뉴욕 AWS Summit에서 "AWS Continuum for code vulnerabilities"로 소개되었습니다 . 핵심 전제는 병목이 더 이상 취약점을 찾는 일이 아니라 분류하는 일이라는 점입니다. Continuum은 추상적인 CVSS식 심각도 점수 대신 비즈니스 우선순위, 시스템 의존성, 위험 프로필 같은 조직 맥락을 기준으로 발견 항목의 순위를 매깁니다 .

이 관점 전환은 중요합니다. 배포 환경에서 도달할 수 없는 의존성의 높은 CVSS 점수는 잡음에 가깝지만, 고객 데이터를 보유한 인터넷 노출 서비스의 중간 심각도 결함은 그렇지 않습니다. Continuum이 오탐을 줄이기 위해 제시한 방식은 익스플로잇 재현입니다. 발견 항목을 드러내기 전에 격리된 샌드박스 환경에서 공격을 재현해, 해당 취약점이 실제 맥락에서 악용 가능한지 입증하려고 합니다 . 이는 벤더의 주장으로 봐야 합니다. AWS는 오탐률이나 샌드박스 충실도가 운영 환경에서만 나타나는 조건을 얼마나 잘 반영하는지에 대한 벤치마크를 공개하지 않았습니다.

수정 방식도 마찬가지로 맞춤형입니다. Continuum은 일반적인 "라이브러리를 업그레이드하라"는 조언 대신, 해당 CVE 유형에 맞는 구체적 조치, 예를 들어 네트워크 구성 변경, 권한 조정, 코드 패치를 권장합니다 .

AWS는 특화 보안 모델이 사람의 분류 속도를 앞지르고 있다는 점에서 긴급성을 설명합니다. 회사는 Anthropic의 "Claude Mythos"가 팀이 수정할 수 있는 속도보다 더 빠르게 취약점을 찾아낼 수 있다고 언급했습니다. 바로 이 백로그를 Continuum이 줄이도록 설계됐다는 설명입니다 .

"Claude Mythos 같은 특화 모델은 팀이 고칠 수 있는 속도보다 더 빠르게 취약점을 찾을 수 있다" — Summit에서의 AWS 설명, CIO Dive 보도. 독립적 측정이 아니라 벤더 포지셔닝으로 봐야 합니다.

Continuum은 단독으로 존재하지 않습니다. AWS Security Agent는 이제 Continuum과 통합되며 설계부터 배포까지 적용 범위를 확장합니다. 여기에 STRIDE 프레임워크 기반 위협 모델링, 풀 리퀘스트 스캔, IDE 통합이 추가됩니다 . 다만 실제 적용 범위에는 제한이 있습니다. 2026년 6월 기준 Continuum은 일부 파일럿 고객에게만 제한적 프리뷰로 제공되며, 가격이나 정식 출시일은 공개되지 않았습니다 .

Continuum이 사람 승인 없이 작동할 때: 감독형 운영에서 독립 운영으로

AWS Continuum은 처음부터 자율 복구 엔진으로 움직이지 않습니다. 먼저 "learning mode"에서 시작하며, 이 단계에서는 제안된 모든 수정 사항이 실행되기 전에 명시적인 사람 승인을 받아야 합니다 . 이 감독 단계는 보정 구간입니다. 팀은 Continuum이 제안하는 네트워크 구성 변경, 권한 조정, 코드 패치 등을 지켜보며, 실제 권한을 부여하기 전에 그 판단 근거가 타당한지 평가합니다. 신뢰를 높이는 과정은 암묵적이지 않고 의도적으로 진행됩니다.

그다음 Continuum은 각 작업마다 승인을 받지 않고 복구를 적용하는 "enforcement mode"로 넘어갈 수 있습니다 . 이를 평가하는 사람에게 중요한 점은, 이 전환 기준을 AWS가 정하는 것이 아니라 고객이 정한다는 것입니다. 어떤 탐지 유형, 어떤 환경, 어떤 위험 프로필에 대해 사람 개입 없는 복구를 허용할지, 또 어떤 항목은 계속 사람 검토를 거치게 할지 사용자가 결정합니다. 그래서 자율성의 경계는 벤더 기본값이 아니라 운영자의 통제 아래 남습니다.

이 아키텍처는 그 경계를 감사할 수 있도록 만들어졌습니다. AWS는 Continuum이 전체 설명 가능성과 감사 로그를 제공하며, 어떤 enforcement 작업이 실행되기 전에 롤백을 미리 확인할 수 있다고 설명합니다 . 실제로는 검토자가 왜 특정 수정이 선택됐는지 확인하고, 무엇을 건드리는지 추적하며, 적용 전에 되돌리는 경로를 살펴볼 수 있다는 뜻입니다. 어떤 시스템이 스스로 프로덕션 보안 상태를 바꾸도록 허용하기 전에 기대할 만한 안전 장치입니다. 다만 이는 벤더가 밝힌 속성이라는 점도 짚어야 합니다. AWS는 아직 롤백이나 감사 보장에 대한 독립 검증 결과를 공개하지 않았습니다 .

Continuum은 설계상 특정 모델에 묶이지 않습니다 . AWS는 전문 보안 모델의 부상을 배경으로 이 제품을 소개하면서, 팀이 고치기보다 더 빠르게 취약점을 드러낼 수 있는 LLM의 예로 Anthropic의 "Claude Mythos"를 언급했습니다. Continuum은 바로 그런 백로그를 줄이기 위한 것입니다 . 이는 아키텍처 설명이라기보다 포지셔닝으로 읽는 편이 맞습니다. Claude Mythos는 위협 환경을 설명하기 위한 사례로 인용된 것이지, Continuum의 필수 엔진이거나 독점 엔진이라는 뜻은 아닙니다. 또한 이 언급은 AWS 제품 문서가 아니라 업계 보도에 등장합니다. 핵심은 모델 계층은 교체 가능하며, Continuum이 어디까지 행동할 수 있는지를 실제로 통제하는 것은 learning mode, 고객이 정하는 기준, 롤백 미리보기 같은 자율성 제어 장치라는 점입니다.

AWS Context와 Continuum은 기존 AgentCore 스택 위에 어떻게 올라가는가

AWS Context와 Continuum은 AgentCore의 기본 요소를 대체하지 않는다. 더 넓은 범위에서 작동한다. 2025년 10월 13일부터 정식 제공된 Amazon Bedrock AgentCore는 Runtime, Memory, Observability, Identity, Gateway, Browser, Code Interpreter 같은 에이전트별 인프라를 제공한다 . 이 가운데 두 가지는 새 서비스가 겨냥하는 컨텍스트와 보안 공백과 겹치지만, 추상화 수준이 다르다.

AgentCore Memory는 에이전트 인스턴스별 관리형 메모리 계층이다. 단기 메모리는 하나의 세션 안에서 턴별 상호작용을 캡처하고 이를 actor ID와 session ID로 구성한다. 장기 메모리는 네임스페이스별로 세션을 넘나드는 사실과 요약을 추출하며, IAM은 네임스페이스 경로에 따라 검색 권한을 제한할 수 있다 . 이는 에이전트별 상태다. AWS Context는 데이터베이스, CRM, 문서, 채팅 전반에서 조직 단위의 관계를 매핑한다. 범위가 다를 뿐, 경쟁 기능은 아니다 .

보안에서도 같은 구분이 적용된다. AgentCore Identity는 자격 증명을 관리한다. KMS로 암호화된 토큰 볼트를 통해 AWS SigV4, OAuth 2.0, API 키를 다루며 Google, GitHub, Slack, Salesforce, Atlassian Jira용 공급자 템플릿도 제공한다 . Continuum은 취약점 선별을 맡는다. 둘 다 ID 및 접근 계층 가까이에 있지만, Identity는 토큰을 발급하고 저장하는 반면 Continuum은 악용 가능성과 조치 방안을 판단한다. 맞닿아 있지만 중복되지는 않는다.

실무에서 가장 분명한 차이는 가격 투명성이다. AgentCore는 사용량 기반 요금을 공개했지만, AWS Context와 Continuum은 아직 가격을 공개하지 않았다 .

Context와 Continuum만 Summit 발표의 전부는 아니었다. AWS는 AgentCore Harness가 정식 제공에 들어갔으며, Bedrock Managed Knowledge Base, AgentCore의 관리형 웹 검색, Strands 개선 사항도 함께 발표했다고 밝혔다 . 앞서 AWS는 2026년 4월 6일 DevOps Agent와 Security Agent를 정식 제공으로 전환했다. Security Agent는 이제 Continuum과 통합되며 STRIDE 위협 모델링, 풀 리퀘스트 스캔, IDE 통합도 추가했다 . 흐름은 이렇다. 오늘 바로 가격을 확인하고 프로비저닝할 수 있는 정식 제공 기본 요소들이 있고, 그 위에 아직 경제성이 공개되지 않은 두 프리뷰 서비스가 얹히는 구조다.

AWS가 아직 입증하지 못한 것, 그리고 먼저 물어야 할 질문

AWS Context와 AWS Continuum 모두 벤치마크를 공개하지 않았고, 이 공백은 두 서비스를 평가하는 방식에 반영되어야 한다. AWS는 Context를 서로 다른 조직 데이터 전반의 관계를 추론하는 지식 그래프라고 설명하지만, 복잡한 스키마 위에서 에이전트형 쿼리를 수행할 때 그래프 추론 정확도, 관계 커버리지의 빈틈, 환각률에 관한 공개 수치는 내놓지 않았다 . "에이전트의 열 번째 판단이 첫 번째 판단보다 좋아진다"는 메시지를 내세우는 서비스라면, 빠져 있는 숫자는 바로 핵심이다. 그래프가 얼마나 자주 틀리는지, 그리고 그 오류가 에이전트의 확신에 찬 출력으로 어떻게 전파되는지다.

Continuum도 더 높은 위험을 안고 같은 공백을 갖고 있다. 격리된 샌드박스 환경에서 공격을 재현해 실제 악용 가능성을 입증하고 오탐을 줄인다는 핵심 주장은 벤더가 제시한 설명이다 . 이 메커니즘을 독립적으로 재현하거나 반박한 연구는 없다. 샌드박스 재현은 신뢰할 만한 아이디어일 수 있지만, "악용 가능성을 입증한다"는 말은 강한 주장이다. 게다가 이 서비스는 제한된 프리뷰로 시작하며 , 공개된 true positive 비율이나 escape rate도 없다.

생산성 수치도 같은 수준으로 따져봐야 한다. AWS는 Signal65 연구를 인용해 엔드투엔드 에이전트 개발이 2.1배 빨라지고, 인프라 및 통합 시간이 75% 줄며, 클라우드 배포가 5.2배 빨라졌다고 말한다 . 하지만 이 연구는 AWS가 의뢰한 것으로, 독립적으로 수행된 조사가 아니다. 중립적 측정이라기보다 벤더 지원 근거에 가깝다. 제3자가 재현하기 전까지 이 배수들은 방향성을 보여주는 마케팅 수치로 보는 편이 맞다.

AWS는 이 서비스에 대해 "Context is what makes your agent's tenth decision better than its first,"라고 말했다 (source: AWS Summit NYC 2026 announcements). 하지만 이 주장은 에이전트가 학습하는 그래프가 정확할 때만 성립하며, AWS는 아직 그것을 보여주지 않았다.

두 서비스 중 어느 하나라도 프로덕션 로드맵에 올리기 전에, 다음 네 가지 질문에 대한 구체적인 답을 받아야 한다.

• AWS Context: 확정된 GA 일정과 리전 목록. 아직 "coming soon" 상태이며 일반 출시 일정은 없다 .
• Continuum의 집행 모드: 실패 처리 방식과 롤백 SLA. 이 서비스는 롤백을 미리 보여줄 수 있고, 사람이 승인하는 학습 모드에서 자율 집행으로 넘어갈 수 있다 . 하지만 자율 remediation이 프로덕션을 망가뜨렸을 때 어떤 일이 벌어지는지는 문서화되어 있지 않다.
• 그래프 갱신 지연: 쿼리 시점의 지식 그래프가 얼마나 오래된 상태일 수 있는지, 그리고 부하가 걸렸을 때 그것이 답변 품질에 어떤 영향을 주는지.
• 가격: AgentCore가 이벤트 1,000건당 요금을 공개한 것과 달리 , 두 서비스는 아직 가격을 공개하지 않았다.

결론은 이렇다. 지금은 가격을 산정하고 감사할 수 있는 GA 기본 기능 위에 구축하고, Context와 Continuum은 배포 계획이 아니라 관찰 목록에 올려야 한다. AWS가 벤더의 주장에 그치지 않고 검증 가능한 근거가 될 벤치마크, 일정, SLA를 공개할 때까지는 그렇다.

자주 묻는 질문

AWS Context는 RAG 파이프라인을 직접 구축하는 것과 무엇이 다른가요?

직접 만든 RAG 파이프라인에서는 문서 청킹, 임베딩 생성, 검색 엔진 튜닝, 거버넌스를 별도 계층으로 붙이는 작업까지 모두 엔지니어링 부담이 됩니다. AWS Context는 그 방향을 뒤집습니다. 데이터베이스, CRM, 문서, 이메일, Slack 같은 서로 다른 조직 소스를 자동으로 수집하고, 그 사이의 관계를 지식 그래프로 추론하며, 수집 단계에서 비즈니스 규칙과 접근 제어를 적용해 에이전트가 항상 거버넌스가 적용된 데이터에만 접근하도록 합니다 . 트레이드오프는 일반적인 관리형 대 DIY의 차이입니다. Context를 쓰면 검색 파이프라인 코드를 만들 필요가 없는 대신, 청킹, 랭킹, 임베딩 선택에 대한 통제력은 줄어듭니다. 실무상 주의할 점도 있습니다. Context는 정식 출시일 없이 "coming soon"으로 설명되어 있는 반면 , RAG 스택은 지금 바로 배포할 수 있습니다.

Continuum의 익스플로잇 검증은 실제로 무엇을 하나요?

AWS Continuum은 알림을 보내기 전에 취약점이 실제인지 확인한다고 주장합니다. 추상적인 CVSS식 점수로 결과의 순위를 매기는 대신, 격리된 샌드박스 환경에서 공격 조건을 재현해 악용 가능성을 입증하려고 시도합니다. 그런 다음 실제로 입증할 수 있었던 문제만 표시하고, 네트워크 구성 변경, 권한 조정, 코드 패치 같은 구체적인 수정 방안을 권장합니다 . 원칙적으로는 CVSS 점수 기반 스캐너에서 쏟아지는 오탐 노이즈를 줄이는 방식입니다. 다만 중요한 단서가 있습니다. 이는 벤더가 밝힌 기능입니다. 2026년 6월 기준 샌드박스 재현이 실제로 오탐을 얼마나 줄이는지 측정한 독립 벤치마크는 없습니다 . 따라서 노이즈 감소 수치는 입증된 결과가 아니라 검증해야 할 주장으로 보는 것이 맞습니다.

AWS Context는 AgentCore Memory를 대체하나요?

아닙니다. 두 기능은 서로 다른 문제를 풀며, 함께 쓰도록 설계된 쪽에 가깝습니다. AgentCore Memory는 에이전트의 무상태성 문제를 다룹니다. 단기 메모리는 단일 세션 안의 턴별 상호작용을 캡처하고, 장기 메모리는 여러 세션에 걸친 사실, 선호도, 요약을 추출합니다. 이 범위는 액터 ID, 세션 ID, 네임스페이스를 기준으로 에이전트 인스턴스별로 정해집니다 . AWS Context는 한 단계 바깥에서 동작합니다. 시스템 전반의 조직 데이터 관계를 매핑하고, 이를 에이전트형 검색을 통해 노출합니다 . Memory는 에이전트가 자기 대화에 대해 기억하는 것이고, Context는 에이전트가 비즈니스 전반에서 접근할 수 있는 것입니다. 실제로는 둘 다 사용할 가능성이 큽니다. Memory는 에이전트 내부의 연속성을 위해, Context는 에이전트 외부의 조직 데이터에 거버넌스가 적용된 방식으로 접근하기 위해 쓰게 됩니다.

AWS Context나 Continuum은 언제 실제로 사용할 수 있나요?

둘 다 아직은 아닙니다. AWS Context는 GA 날짜 없이 "coming soon"으로 표시되어 있고, AWS Continuum은 2026년 6월 기준 일부 파일럿 고객으로 제한된 게이트형 프리뷰로 출시되었습니다 . 둘 다 가격이나 리전 제공 여부를 공개하지 않았습니다 . 지금 배포하고 예산까지 잡을 수 있는 것을 원한다면, 기반 AgentCore 구성 요소인 Memory, Identity, Gateway는 2025년 10월 13일 9개 AWS 리전에서 정식 출시되었고, 단기 메모리 이벤트 1,000건당 0.25달러, Identity 토큰 요청 1,000건당 0.010달러 같은 사용량 기반 가격도 문서화되어 있습니다 .

Continuum은 Snyk나 Semgrep 같은 취약점 스캐너를 대체하나요?

완전한 대체재라기보다는 그 위의 계층으로 포지셔닝되어 있습니다. Continuum은 전체 취약점 생애주기 플랫폼으로 설명됩니다. 지속적인 발견, CVSS 심각도가 아니라 비즈니스 우선순위, 시스템 의존성, 리스크 프로필 같은 조직 맥락에 따른 우선순위 지정, 악용 가능성 검증, 표적화된 수정까지 포함합니다 . 이제 Continuum과 통합되는 관련 AWS Security Agent는 STRIDE 프레임워크 기반 위협 모델링, 풀 리퀘스트 스캔, IDE 통합을 추가합니다 . 이는 Snyk나 Semgrep 같은 스캐너가 다루는 영역과 겹칩니다. Continuum이 기존 도구와 통합되는지, 아니면 이를 대체하려는 것인지는 현재 문서만으로는 명확하지 않습니다. 따라서 발표 내용만 보고 기존 스캐너를 중단할 수 있다고 가정해서는 안 됩니다.