AWS가 리인벤트 2025에서 공개한 아마존 노바 2는 많은 사람이 예상한 바로 그런 AI 상품이며, 솔직히 말해 신중한 아키텍트라면 긴장해야 할 바로 그런 종류다. 노바 2는 프런티어급 모델로 자리매김했고, 아마존 베드록과 긴밀히 통합돼 있다. 또한, 리인벤트 2025에서 공개된 ‘프런티어 에이전트’와 에이전트코어(AgentCore) 프레임워크가 만들어 가는 생태계의 일부다. 이야기 자체는 매력적이다. 더 나은 모델과 더 나은 도구, 에이전틱 AI를 구축·배포·확장할 수 있는 단일 플랫폼을 약속하기 때문이다.

그럼에도 분명한 문제가 있다. 노바 2의 기술적 역량이 부족해서가 아니다. 독립성, 이식성, 장기적인 가치를 추구하는 기업을 완전히 잘못된 전략으로 이끌 수 있는 강력한 선택지라는 점이 문제다. AWS는 단순히 한 개의 모델만 파는 것이 아니다. 에이전트 패브릭과 데이터 흐름, 운영 패턴 전체를 단일 클라우드에 깊이 뿌리내리게 만드는 세계관까지 함께 판매하고 있다.

업체 종속 vs. 실제 가치

업체 종속은 흑백이 아니라 스펙트럼이다. 노바 2와 베드록, 에이전트코어가 구성하는 생태계는 그 스펙트럼 가운데 ‘긴밀하게 결합된’ 쪽 끝으로 기업을 강하게 끌고 간다. 겉으로 보기에는 각종 편의성이 따라온다. AWS가 정의한 에이전트 구성 방식을 이해하는 네이티브 통합, 관리형 인프라, 가시성, 보안 기본 기능을 모두 제공하기 때문이다. 하지만 실제로는 새롭게 구축하는 AI 역량의 핵심을 AWS 안에만 존재하는 API, 런타임, 오케스트레이션 방식에 고정시키게 된다.

필자가 기업에 던지는 질문은 단순하다. 앞으로 6분기를 최적화할 것인지, 향후 6년을 최적화할 것인지 스스로 물어야 한다. 앞으로 6분기 동안에는 노바 2와 관련 생태계 덕분에 생산성이 높아질 가능성이 크다. 하지만 향후 6년 동안에는 이 생태계에서 벗어나거나, AI를 위해 두 번째 클라우드를 의미 있게 활용하려 할 때 비용이 극적으로 치솟을 것이다. 에이전트는 AWS의 도구 API, 가시성 모델, 보안 태세, 그리고 AWS가 에이전트를 데이터와 이벤트에 연결하는 방식에 맞춰 작성된다. 이런 구조는 이론적인 종속이 아니다. 개발하는 모든 코드 한 줄, 구축하는 모든 워크플로우에 깊이 새겨지는 종속이다.

AI를 일시적인 실험 정도로만 본다면 이런 문제는 그리 크게 느껴지지 않을 수 있다. 하지만 필자처럼 에이전틱 AI 시스템이 대부분 기업의 운영 신경계 역할을 맡게 될 것이라고 본다면, 그렇게 중요한 역량을 단일 업체의 생태계 안에 집중시키는 선택은 기능이 아니라 전략적 위험이다.

에이전트 패브릭의 종속성

‘에이전트 패브릭’이라는 개념은 상당히 유용하다. 다양한 데이터 소스와 애플리케이션, 인프라 전반을 가로질러 추론하고, 실행하고, 협업하는 에이전트의 그물망을 뜻하기 때문이다. AWS가 제시하는 비전은 베드록 같은 서비스 안에서 에이전트가 일급 객체로 취급되고, 람다(AWS Lambda), 스텝 펑션(AWS Step Functions), 이벤트브리지(AWS EventBridge), 그리고 날로 증가하는 AI용 데이터 서비스에 연결된 클라우드 네이티브 패브릭이다. 이 패브릭은 기업이 그 울타리 안에 머무는 동안에는 매우 매끄럽게 작동한다.

대안은 클라우드 포터블(Cloud Portable) 패브릭이다. 폐쇄적인 업체 전용 에이전트 프레임워크에 의존해 구축하기보다, 모델에 중립적인 인터페이스, 여러 클라우드를 아우르는 오케스트레이션, 특정 업체의 스토리지나 이벤트 모델을 전제로 하지 않는 데이터 접근 계층 같은 더 개방된 추상화 위에서 에이전트를 정의하는 방식이다. 이렇게 하면 여전히 AWS에서 에이전트를 실행할 수 있고, 동시에 다른 클라우드나 온프레미스, 엣지 환경에서도 처음부터 다시 작성할 필요 없이 실행할 수 있다.

노바 2와 그 주변 도구는 기업을 클라우드 네이티브 쪽으로 강하게 기울게 만들고, 클라우드 포터블 전략과는 점점 멀어지게 만든다. 에이전트가 베드록의 독점 에이전트 오케스트레이션 기본 기능이나 AWS 전용 플러그인 패턴 같은 AWS 특화 기능에 의존하게 되는 순간, 이식성 전략은 사실상 무너진다. 이때 이동 비용은 단순히 ‘모델 엔드포인트를 바꾸는’ 수준이 아니라, ‘에이전트가 어떻게 사고하고 행동하며 통합되는지 전체를 다시 구현하는’ 수준으로 커진다. 이런 종류의 비용은 파워포인트 슬라이드에서는 그럴듯해 보이는 멀티클라우드 전략을 실제 현장에서는 무력화한다.

운영 부담인가, 단순화인가

AWS는 노바 2와 에이전트코어를 복잡성을 단순화하는 해법으로 내세우고 있고, 몇 가지 측면에서는 사실이기도 하다. 통합된 가시성, 통합 보안, 안전한 프로덕션급 에이전트를 구축하기 위한 사전 패턴을 제공하기 때문이다. 하지만 지금 무슨 일이 벌어지는지 분명히 인식해야 한다. AWS는 복잡성을 제거하는 것이 아니라, 사용자가 통제할 수 없는 블랙박스 안에 복잡성을 가둬 넣고 있다.

그 블랙박스가 오작동하거나 성능이 변하거나 사양이 바뀌면, 기업은 AWS의 릴리스 주기와 운영 방식에 전적으로 의존할 수밖에 없다. 에이전트의 동작을 세밀하게 이해하는 팀은 여전히 필요하지만, 기업은 회사의 코드와 정책이 아니라 업체의 코드와 정책에 따라 동작하는 시스템을 진단해야 한다. 이것은 다른 종류의 취약성이다. 직접 보고 관리할 수 있는 복잡성을 소유하는 대신, 보이지 않는 복잡성을 빌려 쓰면서 아무 문제 없이 돌아가기를 바라는 구조이기 때문이다.

여기에 더해 운영 조직은 이제 분산 클라우드 네이티브 시스템뿐 아니라 그 안에 내장된 에이전트의 확률적이며 예측하기 어려운 행동까지 이해해야 하는 상황에 놓인다. 가시성과 거버넌스, 제어 메커니즘이 모두 AWS 전용 서비스에 묶이면, 여러 클라우드와 온프레미스 시스템 전반을 아우르는 통합 운영 뷰를 구축하는 능력을 잃게 된다. AWS는 단일 관리 화면이 되기를 원하지만, 현실에서 대부분 대기업은 여러 개의 화면이 필요하고 이 화면이 서로 연동돼야 한다.

장기적 관점에서 보기

노바 2와 그 생태계를 주요 에이전트 플랫폼으로 채택하는 순간, 기업은 수직 통합된 스택을 선택하는 셈이다. 즉각적인 이점은 부정하기 어렵다. 최적화된 성능, 깊은 통합, 바로 쓸 수 있는 보안 패턴, 줄어드는 연결용 코드가 뒤따른다. 특히 규모가 작거나 인력이 부족한 기업, 이미 AWS와 밀접하게 연결된 기업에는 단기적으로 매우 합리적인 선택일 수 있다.

단점은 시간이 지나면서, 개발 편의성 차원이 아니라 아키텍처 차원에서 드러난다. AWS 전용 에이전트 기능에 대한 의존도가 커질수록 가격 협상력은 약해진다. 에이전트와 도구에 대한 특정 업체 중심 모델을 기준으로 시스템을 설계했기 때문에, 다른 클라우드나 오픈소스 커뮤니티에서 등장하는 혁신을 도입하는 일도 점점 어려워진다. 결국 ‘멀티클라우드’ 전략은 ‘핵심 업무는 하나의 주요 클라우드에, 나머지 잔여 업무만 다른 곳에 두는 구조’로 퇴행하게 되는데, 이것이 바로 대형 클라우드 서비스 업체가 노리는 시나리오다.

더 개방적이고 이식 가능한 접근을 원한다면 초기 비용을 더 지불해야 한다. 업체 중립적인 오케스트레이션 계층을 만들거나 도입하고, 모델 제공업체를 추상화하는 프레임워크를 사용하며, 이기종 환경 전반을 관통하는 가시성 체계를 설계해야 한다. 겉으로 매우 세련돼 보이더라도 단일 업체 AI 패브릭의 중력에서 벗어나려는 노력이 필요하다. 그 대가로 얻는 것은 유연성이다. 경제성, 규제, 혁신의 요구에 따라 방향을 바꿔야 할 때 기업의 운영 신경계 전체를 다시 짜지 않고도 노선을 수정할 수 있는 능력이다.
dl-itworldkorea@foundryco.com