목차
이 글은 Anthropic 엔지니어링 블로그에 2026년 4월 8일 게재된 “Scaling Managed Agents: Decoupling the brain from the hands” 를 읽고, 내용을 정리한 글입니다. 원문: https://www.anthropic.com/engineering/managed-agents
한 줄로 말하면 #
에이전트의 뇌(harness)와 손(sandbox), 기억(session)을 따로 분리하니 어느 하나 죽어도 나머지가 살아남는다.
어떤 문제를 해결하려 했나 #
기존 장기 작업 에이전트의 구조는 모든 것이 한 컨테이너에 묶여 있었습니다. 모델 호출, 코드 실행, 세션 기록 — 한 통에 다.
“컨테이너 하나가 죽으면 세션도 같이 날아간다. 그래서 컨테이너를 ‘가축(cattle)‘이 아니라 ‘반려동물(pets)’ 처럼 정성껏 돌봐야 했다.”
원문이 짚은 더 큰 문제: “하네스는 모델이 발전하면서 가정이 낡아간다.” 한 번 만든 구조가 곧 비효율이 되는데, 모든 게 묶여 있으면 하나만 바꿀 수가 없어요.
해결책: 뇌·손·기억 가상화 #
1. 세 구성요소로 분리 #
| 구성 | 역할 | 상태 |
|---|---|---|
| Brain(뇌, Harness) | Claude + 오케스트레이션 루프 | 상태 없음, 별도 컨테이너 |
| Hands(손, Sandbox) | 코드 실행, 파일 편집 환경 | 필요할 때만 프로비저닝 |
| Session(세션) | 모든 활동의 append-only 이벤트 로그 | 뇌·손과 분리되어 영속 |
각각이 따로 실패하거나 교체돼도 나머지에 영향 없습니다.
2. 작동 방식 #
[Harness 호출]
execute(name, input) → string
- 컨테이너 죽으면 단순 도구 호출 에러로 처리
- 새 컨테이너는 provision({resources})로 생성
[Harness 자체도 회복 가능]
wake(sessionId) → 이벤트 로그에서 복원
getSession(id) → 진행 상황 재구성
- 크래시 나도 세션은 살아 있음세션 로그가 Claude 컨텍스트 창 밖의 컨텍스트 객체 역할을 합니다. getEvents() 같은 인터페이스로 필요한 부분만 잘라 모델에 넣을 수 있어요. 컨텍스트 엔지니어링(#10)이 인프라 수준으로 올라온 셈입니다.
3. 보안 경계 #
자격증명이 sandbox에 닿지 않게 분리:
- Git 토큰은 초기화 시점에만 사용
- OAuth 토큰은 보안 vault에 보관, MCP 프록시 통해서만 접근
- 뇌는 자격증명을 보지 못함
결과 / 효과 #
| 지표 | 개선 |
|---|---|
| TTFT(첫 토큰 도착 시간) p50 | 약 60% 개선 |
| TTFT p95 | 90% 이상 개선 |
비결: 매 세션마다 컨테이너 프로비저닝을 기다리지 않아도 추론 시작 가능. “손은 필요할 때만 만들면 된다” 는 분리 덕분이에요.
추가 이점:
- 여러 뇌가 여러 손에 연결 가능
- 뇌를 고객 VPC 같은 다른 네트워크에 배치 가능
- 무상태 하네스라 자유롭게 재시작
트레이드오프 #
- 복잡도 증가 — 모놀리식보다 운영이 복잡
- 인지 부담 — Claude가 “어느 sandbox에 일을 보낼지” 추론해야 함 (모델 발전으로 가능해진 일)
- 컨텍스트 분업 — 하네스가 컨텍스트 조직(프롬프트 캐싱 포함)을, 세션이 영속성을 책임
원문의 핵심 설계 철학: “향후 모델은 다른 컨텍스트 전략을 요구할 것이라는 가정 위에 분리했다.”
핵심 결론 #
장기 에이전트 인프라를 안정화하려 할 때 사람들은 본능적으로 “더 큰 컨테이너”, “더 좋은 모델"을 떠올립니다. 이 글의 답은 다릅니다.
“안정성 문제가 인프라 크기인 줄 알았는데, 사실은 모든 게 한 통에 묶여 있는 게 문제였다.”
뇌·손·기억을 분리하면 어느 하나 죽어도 나머지가 산다 — 이게 에이전트 인프라를 ‘반려동물’에서 ‘가축’으로 격상시키는 핵심입니다.
내 작업에 적용한다면 #
시나리오 1 — 일반적인 데이터 분석 과정 #
장기 분석 시스템에도 같은 분리 원칙이 적용됩니다.
[Before — 한 노트북에 모든 것]
한 Jupyter 세션에 데이터 적재·분석·시각화·결과 저장 다
→ 커널 죽으면 모든 진행 상황 날아감
[brain-hands-session 패턴]
[Brain — 분석 오케스트레이션]
- 어떤 가설을 검증하고, 다음에 뭘 할지 결정
- 자체 상태 없음, 언제 재시작해도 OK
[Hands — 실행 환경]
- 데이터 처리는 별도 컨테이너 (Docker, Modal 등)
- 죽어도 새로 띄우면 됨
[Session — 영속 로그]
- 모든 결정·결과를 파일/DB에 append-only로 기록
- "지금까지 무슨 가설을 어떤 결론으로 검증했나" 항상 복원 가능핵심: 장기 분석의 안정성은 “분석 로직과 실행 환경과 진행 기록의 분리” 에서 옵니다.
시나리오 2 — 웹 사이트를 자동으로 운영할 때 #
운영 자동화도 같은 구조로 격상시킬 수 있습니다.
[Before — 모놀리식 운영 봇]
한 프로세스에 콘텐츠 수집·생성·배포·모니터링 다
→ 한 부분 죽으면 전체 멈춤
[brain-hands-session 패턴]
[Brain — 운영 결정 로직]
- 무엇을 발행할지, 언제 배포할지 결정
- 무상태, 자유롭게 재시작
[Hands — 실행 환경]
- 빌드 컨테이너, 배포 컨테이너, 검수 컨테이너 분리
- 필요할 때 띄우고 끝나면 종료
[Session — 운영 이벤트 로그]
- 모든 운영 이벤트를 append-only로 기록 (PostgreSQL, Kafka 등)
- 봇 재시작 후에도 어디까지 했는지 복원
[보안 분리]
- 자격증명은 vault에 두고 프록시 통해서만 접근
- Brain은 자격증명 직접 못 봄핵심: 자동 운영의 신뢰성은 “무엇이 결정 / 무엇이 실행 / 무엇이 기록” 의 세 가지 분리에서 옵니다. 한 프로세스에 다 우겨넣으면 작은 사고가 전체를 마비시킵니다.
Anthropic 엔지니어링 블로그를 오래된 순서대로 읽고 정리합니다.
