앤스로픽이 공개한 Managed Agents 설계에서 찾는, 에이전트의 장기 과제·상태 소실·컨텍스트 초과 해결책
앤스로픽이 최근 엔지니어링 블로그에서 에이전트의 핵심 아키텍처를 어떻게 재설계했는지 공개했습니다. 겉보기에는 인프라 관련 글이지만, 그 배경에 있는 설계 철학은 주목할 만합니다.
모델에 대한 패치는, 발전과 함께 무의미한 코드가 된다
에이전트 개발에 참여해 본 경험이 있다면, 이런 경험이 있을 것입니다. 모델이 특정 문제를 일으켜서 프레임워크 수준에서 로직을 추가해 회피합니다. 문제는 해결되었지만, 그 로직은 계속 코드베이스에 남게 됩니다.
앤스로픽 자신도 같은 문제에 직면했습니다. Claude Sonnet 4.5가 컨텍스트 상한에 접근하면 과제를 중도에 포기하는 현상을 발견했습니다. 마치 '시간이 없으니 급하게 마무리하자'는 행동과 같죠. 그들은 이것을 **컨텍스트 불안(context anxiety)**이라고 불렀습니다. 해결책으로, 하니스(harness)에 컨텍스트 초기화 로직을 넣고, 일정 간격으로 초기화하는 메커니즘을 도입했습니다.
그런데, 같은 하니스를 Claude Opus 4.5에서 실행해 보니, 이 행동이 사라져 있었습니다. 모델의 능력이 향상되어 컨텍스트 불안이 발생하지 않게 되었고, 그 초기화 로직은 의미 없는 데드 코드가 된 것입니다.
이 예시가 보여주는 것은, 더 일반적인 문제입니다. 아키텍처 내의 모든 설계 결정은 본질적으로 '모델에게 무엇이 불가능한가'에 대한 가설에 불과합니다. 모델은 진화하고, 가설은 구식이 되지만, 코드는 자동으로 비활성화되지 않습니다.
앤스로픽의 대응 방침은 이러합니다. 패치를 계속 붙이는 대신, 아키텍처를 재설계하여 어느 세대의 모델 변화에도 견딜 수 있을 만큼 안정적인 인터페이스를 제공하는 것. 이것이 이번에 공개된 Managed Agents입니다.
모든 것을 하나의 컨테이너에 담는 것은, 언젠가 갚아야 할 부채
앤스로픽의 초기 구현은 단순했습니다. 에이전트 실행에 필요한 모든 것—스케줄링 로직, 실행 환경, 대화 기록—을 하나의 컨테이너에 담았습니다. 장점은 단순함이었고, 파일 읽기/쓰기는 시스템 콜로 해결되어 서비스 간 통신이 필요 없었습니다.
문제는 이 컨테이너에 책임이 너무 집중되어 '움직일 수 없는 개체'가 되어 버렸다는 점입니다. 컨테이너가 충돌하면, 전체 세션이 손실되고 복원할 방법이 없습니다. 컨테이너가 멈출 경우, 엔지니어는 내부에 들어가 수동으로 조사해야 하는데, 컨테이너 내에는 사용자 데이터도 동시에 존재하기 때문에 디버깅은 복잡하고 보안 위험이 따르는 작업이 됩니다.
더 근본적인 문제로, 이 설계에서는 'Claude의 실행 환경은 하니스와 같은 장소에 있어야 한다'는 가설이 아키텍처에 하드코딩되어 있었습니다. 기업 고객이 자체 프라이빗 클라우드의 리소스에 Claude를 연결하고 싶다면, 선택지는 자체 네트워크와 앤스로픽의 네트워크를 직접 연결하거나, 하니스 전체를 자체적으로 배포하거나 두 가지 중 하나입니다. 암묵적 가설이 확장성의 장애물이 되었던 것입니다.
두뇌와 손을 분리하다
해결책은 세 부분으로 분리하는 것입니다.
- 뇌(Brain): Claude 본체와 이를 스케줄링하는 하니스
- 손(Hands): 구체적인 조작을 실행하는 샌드박스 환경(코드 실행, 파일 조작 등)
- 세션(Session): 이 에이전트 세션에서 발생한 모든 이벤트 로그
세 구성 요소 간에는 단순한 인터페이스로 통신합니다. Hands가 외부에 노출하는 인터페이스는 execute(name, input) → string뿐입니다. Brain은 Hands가 컨테이너인지, 스마트폰인지, 또는 다른 무언가인지 알 필요가 없습니다. 지시와 매개변수를 전달하고 결과를 받을 뿐입니다.
이 분리에는 두 가지 직접적인 이점이 있습니다.
1. 신뢰성 향상
샌드박스 컨테이너가 죽더라도, 하니스는 도구 호출 에러를 받을 뿐입니다. 재시도할지 판단하고, 새로운 컨테이너를 실행하여 계속 진행할 수 있습니다. 세션 로그는 외부에 저장되어 있으므로, 하니스 자체가 충돌해도 문제없습니다—새 하니스를 실행하고 세션 로그를 읽으면, 이전 중단 지점부터 상태를 조금도 잃지 않고 재개할 수 있습니다. 각 구성 요소가 독립적으로 실패하고, 독립적으로 재시작할 수 있습니다.
2. 성능 향상
기존 설계에서는, 각 에이전트 세션 시작 시 먼저 컨테이너를 실행시킨 후 추론을 시작해야 했습니다. 그러나 컨테이너가 온디맨드로 실행되게 되면, 세션이 일시적으로 코드 실행을 필요로 하지 않을 경우 컨테이너를 기다릴 필요가 없어집니다. 하니스가 세션 로그를 얻는 즉시 추론을 즉시 시작할 수 있습니다. 이 변경으로 인해, 첫 토큰 지연 시간의 p50은 약 60%, p95는 90% 이상 단축되었습니다.
인증 정보와 코드를 같은 장소에 두어서는 안 된다
이 부분은 조금 자세히 설명합니다. 관련 보안 로직은, 겉으로는 이해하기 어렵기 때문입니다.
기존의 결합된 설계에서는, Claude가 생성한 코드와 각종 API 토큰, 접근 인증 정보가 모두 같은 컨테이너 내에 존재했습니다. 즉, Claude가 프롬프트 인젝션 공격을 받는 경우—예를 들어 악의적인 콘텐츠에 유도되어 환경 변수를 읽는 코드를 실행한 경우—공격자는 컨테이너 내의 모든 토큰을 얻을 수 있고, 이를 이용해 통제 불가능한 요청을 발행할 수 있습니다.
새 아키텍처의 구조적 해결책은, 샌드박스에서 실행되는 코드가 물리적으로 어떠한 인증 정보에도 접근할 수 없도록 하는 것입니다.
Git을 예로 들어 설명해 보겠습니다. Claude는 코드의 push와 pull이 필요하지만, 이를 위한 토큰 자체를 '알' 필요는 없습니다. 앤스로픽의 방법은 이러합니다: 샌드박스 초기화 단계에서, 저장소의 접근 토큰을 이용해 clone을 실행하고, 토큰을 로컬 git의 remote 설정에 통합합니다. 그 후, Claude가 샌드박스 내에서 git push나 git pull을 실행하면, git 도구가 스스로 인증 처리를 수행하고, Claude가 생성한 코드는 토큰 그 자체에 일절 접촉하지 않습니다. 이것이 '토큰을 배선(wire)한다'는 의미입니다. 토큰은 초기화 단계에서 도구 설정에 내장되고, 실행 환경 변수로 노출되지 않습니다.
다른 외부 서비스의 경우, 앤스로픽은 MCP 프록시 방식을 채택하고 있습니다. OAuth 토큰은 하니스 외부의 보안 vault에 저장되고, Claude가 외부 도구를 호출할 때 요청은 먼저 프록시에 도달합니다. 프록시는 세션 식별자에 대응하는 인증 정보를 vault에서 얻어 외부 서비스로 전달합니다. Claude의 샌드박스 환경에도 하니스에도, 이 인증 정보는 보관되지 않습니다.
결과적으로, 설령 샌드박스 내의 코드가 탈취되더라도, 공격자는 아무것도 가져갈 수 없습니다. 보안 보증은 '모델이 속지 않을 것이라고 믿는 것'이 아니라, 구조적 분리를 통해 실현되고 있습니다.
세션은 이벤트 로그이지, 컨텍스트 윈도우의 복사본이 아니다
에이전트가 장기 과제를 처리할 때, 컨텍스트 길이 상한에 금방 부딪힙니다. 일반적인 대처법은 압축(compaction)—모델에게 현재 컨텍스트를 요약하게 하여, 요약본으로 원래 내용을 대체해 공간을 확보하는 것입니다. 문제는, 이것이 불가역적이라는 점입니다. 원래 정보는 일단 압축되면 되돌릴 수 없고, 후속 단계에서 어떤 세부 정보가 필요한지도 사전에 판단하기 어렵습니다.
Managed Agents의 세션 설계는 이 문제를 근본적으로 해결합니다. 세션은 외부에 완전히 저장된 이벤트의 연속이며, 컨텍스트 윈도우는 그 이벤트 연속에 대한 하나의 뷰(view)에 불과합니다.
구체적으로, 하니스는 getEvents()를 호출하여 세션의 임의 위치에서 이벤트의 슬라이스를 얻고, 어떤 내용을 Claude의 컨텍스트 윈도우에 넣을지 판단할 수 있습니다. 가장 최근 N개의 이벤트만 얻을 수도, 어떤 중요한 결정 이전의 컨텍스트를 다시 읽어들일 수도, 특정 액션 직전에 몇 개 더 참조할 수도 있습니다.
기존 압축과의 본질적인 차이는, 컨텍스트 윈도우 내의 내용에 대한 조작이 가역적이다는 점입니다. 압축, 잘라내기, 재구성은 모두 하니스가 '뷰' 수준에서 수행하는 선택이며, 원본 데이터는 항상 세션에 완전히 보존됩니다. 문제가 있으면 소급할 수 있고, 미래에 컨텍스트 관리 전략을 바꿔도 데이터 마이그레이션은 필요 없습니다.
인터페이스는 안정되고, 구현은 언제든 교체 가능하게
앤스로픽은, 이 설계의 목표를 설명하기 위해 운영체제의 유추를 사용하고 있습니다. 유닉스의 read() 시스템 콜은 1970년대 디스크 시대부터 오늘날 NVMe에 이르기까지, 인터페이스는 한 번도 바뀌지 않았습니다. 바뀐 것은 하위의 구현뿐입니다. 애플리케이션은 스토리지 미디어가 무엇인지 신경 쓸 필요가 없습니다.
Managed Agents가 지향하는 것도 같은 것입니다. 세션, 하니스, 샌드박스라는 세 가지 추상화에 대해 인터페이스를 정의해 버리면, 뒤에서 작동하는 구현은 언제든 교체 가능해집니다. Claude Code도 하나의 하니스에 불과하며, 과제 특화형 하니스도 연결할 수 있고, 아직 존재하지 않는 미래의 하니스도 마찬가지입니다. 아키텍처는 특정 구현에 베팅하지 않고, 인터페이스의 형태에만 베팅합니다.
에이전트 애플리케이션 개발자에게 주는 시사점
에이전트 애플리케이션 개발자에게, 이 설계 철학에서 얻을 수 있는 시사점은 매우 명확합니다. 현재 모델 능력에 대한 워크어라운드(workaround)를 아키텍처에 쓰지 않는 것. 그 대신, 정기적으로 자문하는 것입니다. 자신의 설계 결정 중 본질적으로 모델의 한계에 대한 가설인 것은 무엇이며, 그 가설은 현재에도 아직 성립하는지, 하고.
로딩 중...