매니지드 에이전트 스케일링: 뇌와 손을 분리해서 관리하기

개발자 뉴스레터를 받아보세요

제품 업데이트, 사용 방법, 커뮤니티 스포트라이트 등 다양한 소식을 매월 이메일로 받아보세요.

클로드 매니지드 에이전트 시작하기 문서를 참고해주세요.

앤트로픽 팀의 이전 연구에서 발견했던 것 중 하나는 클로드 소네트 4.5가 컨텍스트 제한에 가까워지면 작업을 조기에 끝내는 경향이 있다는 점이었어요. 이를 '컨텍스트 불안(context anxiety)'이라고 부르기도 하죠. 앤트로픽 팀은 이 문제를 해결하기 위해 하네스에 컨텍스트 리셋 기능을 추가했어요. 하지만 같은 하네스를 클로드 오푸스 4.5에 사용했을 때는 이런 행동이 사라졌다는 것을 발견했어요. 리셋 기능은 더 이상 필요 없는 '데드 웨이트'가 되어버린 거죠.

하네스는 계속 진화할 것으로 예상하고 있어요. 그래서 앤트로픽 팀은 매니지드 에이전트를 구축했어요. 매니지드 에이전트는 클로드 플랫폼에서 제공하는 호스팅 서비스로, 현재 앤트로픽 팀이 사용하고 있는 구현 방식을 포함해서 특정 구현에 얽매이지 않고 오래 지속될 수 있는 소수의 인터페이스를 통해 여러분을 대신해서 장기적인 에이전트를 실행해주죠.

매니지드 에이전트를 구축하는 것은 컴퓨팅 분야의 오래된 문제, 즉 "아직 생각지도 못한 프로그램"을 위한 시스템을 어떻게 설계할 것인가 하는 문제를 해결하는 것을 의미했어요. 수십 년 전, 운영 체제는 하드웨어를 아직 존재하지 않는 프로그램에 충분히 일반적인 추상화—프로세스, 파일—로 가상화함으로써 이 문제를 해결했죠. 그 추상화는 하드웨어를 넘어 오래 지속되었어요. read() 명령어는 1970년대의 디스크 팩에 액세스하는지 현대의 SSD에 액세스하는지에 상관없이 작동하죠. 위에 있는 추상화는 안정적으로 유지되었고, 아래의 구현은 자유롭게 변경될 수 있었던 거예요.

매니지드 에이전트도 같은 패턴을 따릅니다. 앤트로픽 팀은 에이전트의 구성 요소를 가상화했어요. 세션(발생한 모든 일의 append-only 로그), 하네스(클로드를 호출하고 클로드의 도구 호출을 관련 인프라로 라우팅하는 루프), 그리고 샌드박스(클로드가 코드를 실행하고 파일을 편집할 수 있는 실행 환경) 말이죠. 이를 통해 각 구성 요소의 구현을 다른 구성 요소에 영향을 주지 않고 교체할 수 있게 됐어요. 앤트로픽 팀은 이러한 인터페이스의 형태에 대해서는 확고한 의견이 있지만, 그 뒤에서 어떤 것이 실행되는지에 대해서는 크게 관여하지 않는다는 의미죠.

앤트로픽 팀은 처음에는 모든 에이전트 구성 요소를 단일 컨테이너에 넣었어요. 이는 세션, 에이전트 하네스, 샌드박스가 모두 하나의 환경을 공유한다는 것을 의미했죠. 이 접근 방식에는 파일 편집이 직접적인 시스템 호출로 이루어지고, 설계해야 할 서비스 경계가 없다는 등의 이점이 있었어요.

하지만 모든 것을 하나의 컨테이너에 묶어버리면서 오래된 인프라 문제에 부딪혔어요. 펫(pet)을 들인 셈이었죠. 펫 대 가축(pets-vs-cattle) 비유에서 펫은 이름이 있고 직접 관리해야 하며 잃어버릴 수 없는 개체를 의미하고, 가축은 상호 교체 가능한 개체를 의미해요. 앤트로픽 팀의 경우, 서버가 바로 그 펫이 되었죠. 컨테이너가 실패하면 세션이 손실되었고, 컨테이너가 응답하지 않으면 다시 살려내야 했어요.

컨테이너를 돌본다는 건 응답 없는 멈춘 세션을 디버깅해야 한다는 뜻이었어요. 유일한 창구는 WebSocket 이벤트 스트림이었지만, 이 스트림만으로는 어디서 실패가 발생했는지 알 수 없었죠. 하네스의 버그, 이벤트 스트림의 패킷 드롭, 또는 컨테이너 오프라인이 모두 똑같이 보였다는 의미예요. 무엇이 잘못되었는지 파악하려면 엔지니어가 컨테이너 내부에서 셸을 열어야 했지만, 그 컨테이너는 종종 사용자 데이터도 포함하고 있었기 때문에 사실상 디버깅을 할 수 없는 상황이었어요.

두 번째 문제는 하네스가 클로드가 작업하는 모든 것이 자신과 같은 컨테이너 안에 있다고 가정했다는 점이었어요. 고객들이 클로드를 자신들의 가상 프라이빗 클라우드(VPC)에 연결해 달라고 요청했을 때, 그들은 네트워크를 앤트로픽 팀의 네트워크와 피어링하거나, 자신들의 환경에서 앤트로픽 팀의 하네스를 실행해야만 했죠. 하네스에 내재된 이러한 가정은 하네스를 다른 인프라에 연결하려 했을 때 문제가 되었어요.

그래서 앤트로픽 팀이 찾은 해결책은 소위 "뇌"(클로드와 그 하네스)를 "손"(샌드박스와 액션을 수행하는 도구들)과 "세션"(세션 이벤트 로그)으로부터 분리하는 것이었어요. 각각은 다른 구성 요소에 대해 거의 가정을 하지 않는 인터페이스가 되었고, 각각은 독립적으로 실패하거나 교체될 수 있었죠.

하네스가 컨테이너를 떠나다. 뇌와 손을 분리한다는 것은 하네스가 더 이상 컨테이너 안에 살지 않는다는 것을 의미했어요. 하네스는 다른 도구를 호출하는 방식과 동일하게 컨테이너를 호출했죠. execute(name, input) → string. 컨테이너는 가축이 되었어요. 컨테이너가 죽으면 하네스는 이를 도구 호출 오류로 감지하고 클로드에게 다시 전달했어요. 클로드가 재시도를 결정하면, 새로운 컨테이너가 표준 레시피인 provision({resources})를 통해 다시 초기화될 수 있었죠. 더 이상 실패한 컨테이너를 다시 살려내지 않아도 되었어요.

하네스 실패로부터 복구하기. 하네스 또한 가축이 되었어요. 세션 로그가 하네스 외부에 있기 때문에 하네스 안의 어떤 것도 충돌에서 살아남을 필요가 없었죠. 하네스가 실패하면 새로운 하네스가 wake(sessionId)로 재부팅될 수 있고, getSession(id)를 사용해서 이벤트 로그를 되찾아와 마지막 이벤트부터 재개할 수 있어요. 에이전트 루프 동안 하네스는 emitEvent(id, event)를 사용해서 세션에 이벤트를 기록하여 이벤트의 영구적인 기록을 유지합니다.

보안 경계. 결합된 설계에서는 클로드가 생성한 모든 신뢰할 수 없는 코드가 자격 증명과 같은 컨테이너에서 실행되었어요. 그래서 프롬프트 인젝션 공격은 클로드가 자신의 환경을 읽도록 설득하기만 하면 되었죠. 공격자가 해당 토큰을 손에 넣으면, 무제한의 새 세션을 스폰하고 그 세션에 작업을 위임할 수 있었어요. 범위 축소(Narrow scoping)는 명백한 완화책이지만, 이는 클로드가 제한된 토큰으로 무엇을 할 수 없는지에 대한 가정을 포함하고 있었고, 클로드는 점점 더 똑똑해지고 있어요. 구조적인 해결책은 클로드가 생성한 코드가 실행되는 샌드박스에서 토큰에 절대 접근할 수 없도록 하는 것이었어요.

앤트로픽 팀은 이를 보장하기 위해 두 가지 패턴을 사용했어요. 인증은 리소스와 함께 번들로 제공되거나 샌드박스 외부의 금고에 보관될 수 있어요. Git의 경우, 각 저장소의 액세스 토큰을 사용하여 샌드박스 초기화 중에 저장소를 복제하고 이를 로컬 Git 원격에 연결해요. Git push 및 pull은 에이전트가 직접 토큰을 처리하지 않고도 샌드박스 내부에서 작동합니다. 커스텀 도구의 경우, 앤트로픽 팀은 MCP를 지원하고 OAuth 토큰을 보안 금고에 저장해요. 클로드는 전용 프록시를 통해 MCP 도구를 호출하는데, 이 프록시는 세션과 연결된 토큰을 받아요. 그러면 프록시는 금고에서 해당 자격 증명을 가져와서 외부 서비스로 호출을 할 수 있죠. 하네스는 어떤 자격 증명도 알지 못하게 됩니다.

장기적인 작업은 클로드의 컨텍스트 윈도우 길이를 초과하는 경우가 많고, 이를 해결하는 표준적인 방법들은 모두 무엇을 유지할지에 대한 되돌릴 수 없는 결정을 포함하고 있어요. 앤트로픽 팀은 컨텍스트 엔지니어링에 관한 이전 연구에서 이러한 기술들을 탐구했어요. 예를 들어, 압축(compaction) 기능을 통해 클로드는 컨텍스트 윈도우의 요약을 저장할 수 있고, 메모리 도구를 통해 클로드는 컨텍스트를 파일에 작성하여 세션 간 학습을 가능하게 합니다. 이는 오래된 도구 결과나 사고 블록과 같은 토큰을 선택적으로 제거하는 컨텍스트 트리밍과 함께 사용할 수 있죠.

하지만 컨텍스트를 선택적으로 유지하거나 버리는 되돌릴 수 없는 결정은 실패로 이어질 수 있어요. 미래의 턴에 어떤 토큰이 필요할지 알기 어렵기 때문이죠. 만약 메시지가 압축 단계를 통해 변환되면, 하네스는 클로드의 컨텍스트 윈도우에서 압축된 메시지를 제거하고, 이 메시지들은 저장되어야만 복구할 수 있어요. 이전 연구에서는 컨텍스트를 컨텍스트 윈도우 밖에 존재하는 객체로 저장하는 방식으로 이 문제를 해결하는 방법을 탐구했었어요. 예를 들어, 컨텍스트는 LLM이 코드를 작성하여 필터링하거나 슬라이스함으로써 프로그래밍 방식으로 접근하는 REPL의 객체가 될 수 있죠.

매니지드 에이전트에서는 세션이 바로 이와 동일한 이점을 제공해요. 클로드의 컨텍스트 윈도우 외부에 존재하는 컨텍스트 객체 역할을 하는 거죠. 하지만 샌드박스나 REPL 내부에 저장되는 대신, 컨텍스트는 세션 로그에 영구적으로 저장됩니다. getEvents() 인터페이스는 '뇌'가 이벤트 스트림의 위치적 슬라이스를 선택함으로써 컨텍스트를 질의할 수 있게 해줘요. 이 인터페이스는 유연하게 사용될 수 있어서, '뇌'는 마지막으로 읽기를 멈춘 곳부터 다시 시작하거나, 특정 순간 이전 몇 개의 이벤트를 되감아 흐름을 보거나, 특정 행동 이전에 컨텍스트를 다시 읽을 수 있어요.

가져온 이벤트는 클로드의 컨텍스트 윈도우로 전달되기 전에 하네스에서 변환될 수도 있어요. 이러한 변환은 하네스가 인코딩하는 모든 것이 될 수 있으며, 높은 프롬프트 캐시 적중률과 컨텍스트 엔지니어링을 달성하기 위한 컨텍스트 조직화 등을 포함하죠. 앤트로픽 팀은 복구 가능한 컨텍스트 저장을 세션에, 임의의 컨텍스트 관리를 하네스에 분리했어요. 미래 모델에서 어떤 특정 컨텍스트 엔지니어링이 필요할지 예측할 수 없기 때문이에요. 인터페이스는 해당 컨텍스트 관리를 하네스로 밀어 넣고, 세션이 영구적이고 질의 가능함을 보장할 뿐입니다.

많은 뇌. 뇌와 손을 분리하면서 앤트로픽 팀의 초기 고객 불만 사항 중 하나를 해결할 수 있었어요. 팀들이 클로드가 자신들의 VPC 내 리소스에 대해 작업하기를 원했을 때, 유일한 방법은 그들의 네트워크를 앤트로픽 팀의 네트워크와 피어링하는 것이었죠. 왜냐하면 하네스를 담고 있는 컨테이너는 모든 리소스가 자신의 옆에 있다고 가정했기 때문이에요. 하네스가 더 이상 컨테이너 안에 없게 되자, 그 가정은 사라졌어요. 같은 변화는 성능 면에서도 이득을 가져왔죠. 처음에 앤트로픽 팀이 뇌를 컨테이너에 넣었을 때는, 많은 뇌가 많은 컨테이너를 필요로 한다는 것을 의미했어요. 각 뇌에 대해 해당 컨테이너가 프로비저닝될 때까지 추론이 발생할 수 없었고, 모든 세션은 컨테이너 설정 비용을 선불로 전부 지불해야 했죠. 모든 세션은 샌드박스를 전혀 건드리지 않을 세션까지도 저장소를 복제하고 프로세스를 부팅하며 서버에서 대기 중인 이벤트를 가져와야 했어요.

이러한 대기 시간은 작업 수락 후 첫 응답 토큰을 생성하기까지 세션이 기다리는 시간을 측정하는 Time-to-First-Token(TTFT)으로 표현돼요. TTFT는 사용자가 가장 강하게 느끼는 레이턴시죠.

뇌와 손을 분리한다는 것은 컨테이너가 필요한 경우에만 도구 호출(execute(name, input) → string)을 통해 '뇌'에 의해 프로비저닝된다는 것을 의미해요. 그래서 컨테이너가 즉시 필요하지 않은 세션은 기다리지 않았죠. 오케스트레이션 계층이 세션 로그에서 대기 중인 이벤트를 가져오자마자 추론이 시작될 수 있었어요. 이 아키텍처를 사용하면서 앤트로픽 팀의 p50 TTFT는 약 60%, p95는 90% 이상 감소했어요. 많은 뇌로 확장하는 것은 단순히 많은 무상태 하네스를 시작하고, 필요할 때만 손에 연결하는 것을 의미했습니다.

많은 손. 앤트로픽 팀은 또한 각 뇌를 여러 손에 연결할 수 있는 기능도 원했어요. 실제로 이는 클로드가 여러 실행 환경에 대해 추론하고 작업을 어디로 보낼지 결정해야 한다는 것을 의미하는데, 이는 단일 셸에서 작동하는 것보다 더 어려운 인지 작업이죠. 앤트로픽 팀은 초기 모델이 이런 능력이 없었기 때문에 뇌를 단일 컨테이너에 두는 것으로 시작했어요. 인텔리전스가 확장되면서 단일 컨테이너가 오히려 한계가 되었죠. 컨테이너가 실패했을 때, 뇌가 접근하고 있던 모든 손에 대한 상태를 잃었으니까요.

뇌와 손을 분리하면 각 손이 도구, execute(name, input) → string가 됩니다. 이름과 입력이 들어가면 문자열이 반환되는 식이죠. 이 인터페이스는 모든 커스텀 도구, 모든 MCP 서버, 그리고 앤트로픽 팀의 자체 도구를 지원해요. 하네스는 샌드박스가 컨테이너인지, 휴대폰인지, 아니면 포켓몬 에뮬레이터인지 알지 못해요. 그리고 어떤 손도 어떤 뇌와도 결합되어 있지 않기 때문에, 뇌들은 서로 손을 전달할 수 있습니다.

앤트로픽 팀이 직면했던 과제는 "아직 생각지도 못한 프로그램"을 위한 시스템을 어떻게 설계할 것인가 하는 오래된 문제였죠. 운영 체제는 하드웨어를 아직 존재하지 않는 프로그램에 충분히 일반적인 추상화로 가상화함으로써 수십 년 동안 지속되어 왔어요. 매니지드 에이전트를 통해 앤트로픽 팀은 미래의 하네스, 샌드박스 또는 클로드 주변의 다른 구성 요소를 수용할 수 있는 시스템을 설계하는 것을 목표로 했습니다.

매니지드 에이전트는 같은 맥락에서 메타-하네스라고 할 수 있어요. 미래에 클로드에게 필요한 특정 하네스에 대해서는 고집하지 않죠. 오히려 여러 다른 하네스를 허용하는 일반적인 인터페이스를 가진 시스템입니다. 예를 들어, 클로드 코드는 앤트로픽 팀이 다양한 작업에서 널리 사용하는 훌륭한 하네스예요. 또한 특정 작업에 특화된 에이전트 하네스가 좁은 영역에서 뛰어난 성능을 발휘한다는 것도 보여줬어요. 매니지드 에이전트는 클로드의 인텔리전스에 맞춰 이러한 모든 것을 수용할 수 있습니다.

메타-하네스 설계는 클로드 주변의 인터페이스에 대해 확고한 의견을 가지는 것을 의미해요. 앤트로픽 팀은 클로드가 상태를 조작(세션)하고 연산을 수행(샌드박스)할 수 있는 능력이 필요할 것이라고 예상합니다. 또한 클로드가 많은 뇌와 많은 손으로 확장될 능력이 필요할 것이라고 예상하고 있어요. 앤트로픽 팀은 이러한 것들이 장기적으로 안정적이고 안전하게 실행될 수 있도록 인터페이스를 설계했어요. 하지만 클로드에게 필요한 뇌나 손의 수 또는 위치에 대해서는 어떠한 가정도 하지 않습니다.

작성자: 랜스 마틴, 게이브 세마지, 마이클 코헨. 이 주제에 대한 유익한 대화를 나눠주신 노디르 투라쿨로프와 제레미 폭스께 감사드립니다. Agents API 팀과 제이크 이튼의 기여에 특별히 감사드립니다.

제품 업데이트, 사용 방법, 커뮤니티 스포트라이트 등 다양한 소식을 매월 이메일로 받아보세요.