Google AX · AWS Strands — 에이전트에도 '쿠버네티스'가 필요한 이유

왜 갑자기 에이전트를 개발하는 방식이 통째로 바뀌고 있을까요? 지금까지는 그저 프롬프트를 정교하게 짜거나 여러 API를 가볍게 연결하는 데 집중해 왔습니다. 하지만 에이전트가 실제 비즈니스 문제를 해결하려 하자마자, 네트워크가 중간에 끊기거나 서버가 죽으면 작업 흐름과 상태가 통째로 날아가 버리는 까다로운 인프라 한계에 부딪히기 시작했습니다.

최근 구글이 오픈소스로 전격 공개한 분산형 에이전트 런타임 'AX'와 AWS가 선보인 멀티클라우드 기반의 'Strands Harness'는 이러한 시스템 문제를 해결하기 위해 등장했습니다. 이제는 단순한 개발 라이브러리를 넘어, 마치 서버 인프라를 안정적으로 운영하는 쿠버네티스처럼 에이전트를 안전하게 복구하고 관리해 주는 '런타임' 기술이 핵심으로 떠오르고 있습니다. 이번 글에서는 에이전트 개발의 기본 문법을 바꿀 이 흥미로운 기술들을 쉽고 가볍게 짚어보겠습니다.

Google AX — 에이전트 세계에 찾아온 쿠버네티스

구글이 오픈소스로 전격 공개한 AX는 기존의 에이전트 프레임워크와 완전히 다르게 작동하는 '분산형 에이전트 오케스트레이션 런타임'입니다. 마치 컨테이너를 똑똑하게 관리하는 쿠버네티스처럼, 수많은 에이전트의 실행 상태와 리소스를 인프라 수준에서 안정적으로 제어하는 역할을 맡습니다.

그동안 AI 에이전트는 실전 비즈니스에 투입하기가 꽤 까다로웠습니다. 네트워크가 갑자기 끊기거나 서버가 죽으면, 지금까지 열심히 추론하고 도구를 실행하던 과정이 통째로 날아가 버렸기 때문입니다.

AX는 이 문제를 해결하기 위해 에이전트의 모든 행동과 도구 호출 기록을 데이터베이스에 이벤트 로그로 차곡차곡 기록해 둡니다. 덕분에 시스템 장애가 발생해도, 기록된 로그를 다시 재생하여 마지막에 멈춘 지점부터 귀신같이 작업을 이어 나갈 수 있습니다.

여기에 하나의 중앙 컨트롤러가 상태를 일관되게 관리하는 '단일 작성자 아키텍처'를 더해 복잡한 분산 환경에서도 데이터가 꼬이거나 도구가 중복 실행되는 충돌을 원천 차단했습니다. 이제 에이전트는 불안정한 일회성 스크립트가 아니라, 진정한 엔터프라이즈급 인프라 위에서 돌아가는 안정적인 시스템으로 거듭나고 있습니다.

AWS Strands Harness — 토큰 비용을 28% 아끼는 비결

구글에 AX가 있다면, AWS 진영에는 'Strands Harness'가 있습니다. 이 도구는 특정 클라우드나 AI 모델에 종속되지 않는 오픈소스 멀티클라우드 런타임입니다. 아마존 베드록부터 앤트로픽, 오픈AI, 구글 제미나이는 물론이고 개인 컴퓨터에서 가볍게 돌리는 올라마(Ollama) 모델까지 자유롭게 연결해 줍니다.

Strands Harness의 가장 큰 매력은 에이전트 개발자들의 최대 고민인 API 비용을 획기적으로 줄여준다는 점입니다. 에이전트가 외부 도구를 여러 번 실행해 복잡한 업무를 풀다 보면, 이전 실행 결과들이 눈덩이처럼 불어나 컨텍스트 윈도우를 가득 채우게 됩니다. 결국 매번 불필요한 토큰 요금을 계속 내야 하는 비효율이 발생합니다.

이 문제를 해결하기 위해 Strands Harness는 도구 실행 결과를 별도의 파일 형태로 안전하게 저장하고, 컨텍스트 윈도우를 실시간으로 똑똑하게 비워줍니다. 중복되는 프롬프트는 영리하게 캐싱하여 복잡한 작업을 할 때 발생하는 전체 토큰 비용을 약 28%나 아껴줍니다.

실제 Strands Harness의 설정 파일을 보면 그 구조를 직관적으로 이해할 수 있습니다.

덕분에 개발자는 모델마다 다른 API 연동 코드를 구구절절 새로 짜거나 컨텍스트 최적화 로직을 직접 구현할 필요가 없습니다. 인프라가 비용과 모델 전환 문제를 알아서 대행해 주니, 개발자는 오직 에이전트가 해야 할 핵심 비즈니스 로직에만 더 몰입할 수 있게 됩니다.

왜 그냥 프레임워크를 쓰면 안 될까?

지금까지 많은 개발자가 편리한 라이브러리를 사용해 AI 에이전트를 개발해 왔습니다. 하지만 이를 실제 서비스에 적용하려다 보면 곧바로 장벽에 부딪힙니다. 네트워크가 불안정해서 연결이 끊기거나 예외가 발생하면, 에이전트가 이전까지 작업하던 기억과 진행 상태가 허공으로 날아가 버리기 때문입니다. 마치 메모장에서 긴 글을 쓰다가 컴퓨터가 갑자기 꺼져 버리는 것처럼 말이죠.

구글 AX나 AWS Strands 같은 에이전트 런타임의 등장은 이 패러다임을 바꿉니다. 이들은 마치 작성하던 글을 실시간으로 자동 저장해 주는 구글 문서와 같습니다. 네트워크 연결이 잠시 끊겨도 실행 상태가 시스템 아키텍처 수준에서 안전하게 보존되기 때문에, 연결이 복구되면 에이전트가 하던 일을 즉시 이어서 실행할 수 있습니다.

이제 개발자는 복잡한 예외 처리, 세션 복구, 호출 비용 최적화 같은 인프라 문제를 매번 직접 코딩할 필요가 없습니다. 아래와 같이 단순한 런타임 설정 하나로 복잡한 환경을 손쉽게 구성할 수 있습니다.

결국 인프라 수준에서 안정성을 대행해 주는 도구가 확보되면서, 개발자는 에이전트가 실제로 해결해야 하는 비즈니스 로직과 똑똑한 행동 흐름을 정교하게 설계하는 본질적인 작업에만 온전히 몰입할 수 있게 됩니다.

프롬프트를 넘어 '에이전트 런타임'의 시대로

이제 AI 에이전트를 만드는 일은 단순히 프롬프트를 정교하게 다듬거나 여러 라이브러리를 연결하는 단계를 넘어섰습니다. 구글 AX와 AWS Strands가 보여주듯, 앞으로는 네트워크가 끊겨도 스스로 멈춘 지점부터 다시 실행하고 토큰 비용을 알아서 아껴주는 안정적인 인프라 엔진이 개발의 핵심이 될 것입니다.

과거 웹 서비스 시장이 쿠버네티스의 등장으로 운영 안정성을 획기적으로 높였던 것처럼, 에이전트 역시 견고한 시스템 런타임 위에서 진짜 실전용 비즈니스 도구로 거듭나고 있습니다. 이제 똑똑한 프롬프트 작성을 고민하는 단계를 지나 서비스의 뼈대가 될 새로운 에이전트 인프라에 관심을 가져볼 때입니다.