AWS가 뉴욕 서밋에서 공개한 Continuum과 Context는 AI 에이전트 논의의 온도를 조금 낮춘다. 더 똑똑한 코딩 에이전트, 더 빠른 자동화보다 앞에 놓인 문제가 있다는 뜻이다. 에이전트는 코드를 빠르게 만들 수 있지만, 그 코드가 실제 회사 시스템에서 어떤 의미를 갖는지, 어떤 권한과 데이터 경계를 건드리는지까지 자연스럽게 이해하지는 못한다.
Continuum은 그중 보안 쪽 문제를 겨냥한다. AWS 설명에 따르면 이 서비스는 열린 취약점과 새로 발견한 이슈를 모아 우선순위를 매기고, 영향을 받는 컴포넌트가 실제 프로덕션에서 쓰이는지, 외부에서 접근 가능한지 같은 업무 맥락을 함께 본다. 이후 격리된 테스트 환경에서 공격 재현을 시도해 실제 위험과 오탐을 나누고, 네트워크 설정 변경, 권한 조정, 코드 패치 같은 수정안을 제시한다. 처음에는 사람이 승인하는 학습 모드로 시작하고, 신뢰가 쌓이면 정해진 범위 안에서 자동 적용하는 enforcement mode로 넘어갈 수 있다.
Context는 다른 종류의 빈칸을 채운다. 기업 데이터베이스, 문서, 이메일, 채팅 메시지에서 관계를 뽑아 지식 그래프를 만들고, 여러 에이전트가 같은 업무 지식을 참조하도록 한다. 어떤 테이블이 어느 고객과 연결되는지, 어떤 소스가 특정 정보의 기준인지 모르는 에이전트는 그럴듯한 답을 만들 수는 있어도 믿을 만한 판단을 내리기 어렵다. AWS는 접근 제어와 신뢰도 학습을 함께 붙여, 이전 질의에서 좋은 결과를 낸 소스가 이후 에이전트에도 도움이 되게 하려 한다.
같은 흐름은 AWS DevOps Agent에도 들어간다. AI가 만든 코드가 배포되기 전에 Release Readiness Review로 운영 요구사항과 저장소 간 의존성을 확인하고, 변경 내용에 맞춘 테스트 계획을 만들어 프로덕션과 비슷한 환경에서 돌린다. 결과는 GitHub나 GitLab 코멘트로 남고, Kiro 또는 Claude Code 플러그인에서도 볼 수 있다. 단순히 테스트를 많이 돌리는 문제가 아니라, 어떤 변경이 어떤 운영 조건을 깨뜨릴 수 있는지 보는 쪽에 가깝다.
이 발표가 흥미로운 이유는 AWS가 에이전트의 약점을 제품화하고 있다는 점이다. 기사에는 Amazon 내부에서도 Kiro가 환경을 삭제하고 재구성하며 13시간 장애가 났다는 보도와, 이후 숙련 엔지니어가 AI 생성 코드를 승인해야 한다는 정책이 언급된다. 에이전트가 실제 운영에 들어오면 실패는 데모 화면이 아니라 장애, 권한 오남용, 취약점 누적으로 나타난다.
그래서 이번 발표의 메시지는 꽤 현실적이다. AI 에이전트 도입의 다음 단계는 더 많은 자동화가 아니라, 자동화가 멈춰야 할 위치를 정하는 일이다. 조직 지식을 어디까지 보여줄지, 어떤 수정은 사람이 승인해야 할지, 취약점 판단에 어떤 업무 맥락을 넣을지 정하지 않으면 속도는 곧 리스크가 된다. AWS Continuum과 Context는 에이전트를 운영 시스템 안에 넣기 위해 필요한 주변 장치가 점점 제품의 본체가 되고 있음을 보여준다.