에이전트는 똑똑함보다 분업이 먼저다 — Managed Agents 설계에서 배운 것

에이전트를 만들다 보면 쉽게 한쪽으로 기운다. 더 긴 프롬프트, 더 많은 도구, 더 큰 컨텍스트, 더 좋은 모델로 하나의 에이전트를 계속 강하게 만드는 방향이다. 처음에는 이 접근이 꽤 잘 먹힌다. 작은 자동화, 짧은 작업, 한두 개 도구를 쓰는 흐름에서는 특히 그렇다.

문제는 시스템이 커질 때다. 작업 길이가 길어지고, 도구 종류가 늘고, 실패 지점이 많아지면 단일 슈퍼 에이전트는 금방 운영 비용이 커진다. 성능보다 먼저 무너지는 건 구조다.

Anthropic이 최근 공개한 Managed Agents, parallel Claudes, 그리고 agent evals 사례를 보면 공통점이 있다. 더 똑똑한 단일 에이전트를 만드는 것보다, 역할을 나누고 경계를 분리하는 쪽으로 설계를 밀고 있다는 점이다. 이건 마케팅 문구가 아니라 시스템 설계 이야기다.

하나의 거대한 프롬프트가 먼저 부딪히는 한계

단일 에이전트 접근은 겉으로 단순하다. 세션 하나, 컨텍스트 하나, 도구 목록 하나면 된다. 하지만 실제 운영에서는 여러 문제가 한 번에 겹친다.

첫째, 모든 책임이 한 루프에 몰린다. 계획, 실행, 상태 관리, 오류 복구, 도구 선택, 결과 정리를 한 에이전트가 다 맡는다. 이 구조에서는 문제를 분리해서 보기 어렵다.

둘째, 도구 경계가 흐려진다. 코드 실행 환경, 외부 API, 인증 자격, 파일 시스템, 세션 상태가 한 덩어리로 붙으면 에이전트는 편해진다. 대신 보안과 복구가 어려워진다.

셋째, 실패가 전체 실패가 된다. 세션이 꼬이거나 실행 환경이 죽으면 계획도, 작업 상태도, 중간 맥락도 같이 날아간다.

Anthropic이 Managed Agents에서 강조한 것도 이 지점이다. brain, hands, session을 한 컨테이너에 넣는 방식은 처음엔 빠르지만 결국 “pet server” 문제가 생긴다. 세션도, 하네스도, 샌드박스도 서로 강하게 묶여 있어서 하나가 죽으면 전체를 살려야 한다.

분업 구조가 운영상 유리한 이유

좋은 에이전트 시스템은 똑똑한 개인보다 팀에 가깝다. 중요한 건 역할 분리다.

1. 실패를 국소화할 수 있다

하네스가 죽어도 세션 로그가 남아 있으면 다시 깨어날 수 있다. 샌드박스가 죽어도 도구 호출 실패로 처리하고 새 실행 환경을 띄우면 된다. 세션이 외부에 있고, 실행 환경이 교체 가능하고, 오케스트레이션이 상태를 다시 읽을 수 있으면 복구 단위가 작아진다.

단일 에이전트 구조에서는 실패가 곧 리셋이다. 분업 구조에서는 실패가 교체 가능한 컴포넌트 하나의 문제로 내려온다.

2. 병렬화가 가능해진다

Anthropic의 C compiler 사례가 좋은 예다. 하나의 Claude 세션은 한 번에 한 가지 일만 한다. 하지만 여러 에이전트를 병렬로 돌리면 다른 failing test, 다른 모듈, 다른 품질 문제를 동시에 밀 수 있다.

여기서 중요한 건 “에이전트를 여러 개 띄웠다”가 아니다. 각 에이전트가 서로 다른 작업을 집도록 task boundary를 만든 것이다. 락 파일로 현재 작업을 잡고, 문서 담당, 성능 담당, 구조 개선 담당처럼 역할을 분리하자 병렬화가 실제 효율로 바뀌었다.

즉, 병렬성은 모델 개수에서 나오지 않는다. 작업을 나눌 수 있는 구조에서 나온다.

3. 모델 향상에 덜 취약하다

Managed Agents 글에서 흥미로운 포인트는 하네스의 가정이 모델이 좋아질수록 낡는다는 점이다. 예전에는 필요했던 context reset이 새 모델에서는 오히려 dead weight가 되기도 한다.

그래서 오래 가는 시스템은 특정 모델의 약점에 너무 강하게 맞춘 하네스보다, 세션, 도구 호출, 샌드박스 같은 인터페이스를 안정적으로 두는 편이 낫다. 모델은 바뀌어도 분업 구조는 남는다.

tool boundary를 잘못 설계하면 생기는 문제

에이전트 시스템에서 tool boundary는 API 설계와 비슷하다. 무엇을 어디까지 도구로 노출할지, 어떤 자격 증명을 누가 들고 있을지, 실패를 어떤 형태로 반환할지 정하는 일이다.

이걸 잘못 설계하면 세 가지 문제가 바로 생긴다.

권한이 한곳에 몰린다

코드 생성 에이전트가 셸도 쓰고, Git 토큰도 보고, 외부 SaaS 자격도 직접 만질 수 있게 두면 편하다. 대신 prompt injection이나 오작동이 곧바로 권한 남용으로 이어진다.

Managed Agents가 brain과 hands를 분리하고, 토큰을 sandbox가 아니라 vault와 proxy 쪽에 둔 이유가 여기 있다. 에이전트가 도구를 호출할 수는 있어도, 자격 증명 자체를 만지게 하면 안 된다.

도구가 상태 저장소가 된다

실행 환경 안에 세션 상태까지 같이 넣으면, 도구가 죽는 순간 상태도 같이 사라진다. 샌드박스는 교체 가능한 hands여야지, 시스템의 기억 장소가 되면 안 된다.

오케스트레이션이 추론을 대신한다

도구 경계가 나쁘면 오케스트레이터가 에이전트 대신 세세한 규칙을 계속 떠안게 된다. 처음에는 정교해 보이지만 곧 brittle해진다. 모델이 달라지거나 작업 유형이 늘어나면 하네스 전체를 다시 손봐야 한다.

결국 좋은 tool boundary는 세 가지를 만족해야 한다.

• 권한은 최소화한다
• 상태는 외부에 둔다
• 실패는 재시도 가능한 형태로 돌려준다

orchestration과 evals는 같이 설계해야 한다

에이전트 시스템에서 orchestration은 작업을 분배하고 상태를 이어붙이는 층이다. 그런데 이 층을 evals 없이 설계하면 거의 반드시 감으로 운영하게 된다.

Anthropic의 evals 글이 강조하는 것도 비슷하다. 에이전트를 평가한다는 건 모델만 보는 게 아니라, 하네스와 도구와 환경이 함께 만든 결과를 평가하는 일이다. 다시 말해, 오케스트레이션을 바꾸면 eval도 같이 바뀌어야 한다.

예를 들어 병렬 에이전트를 도입했다면 평가해야 할 건 단순 정답률이 아니다.

• 작업 충돌이 줄었는가
• 같은 실패를 여러 에이전트가 중복 해결하려 들지 않는가
• 도구 호출 수와 비용이 어떻게 변했는가
• 특정 역할 분리가 실제 품질 개선으로 이어졌는가
• 복구 후 재개가 안정적으로 되는가

C compiler 사례에서도 결국 핵심은 테스트 하네스였다. 병렬 에이전트가 계속 앞으로 가려면 각자 “무엇이 진전인지”를 알 수 있어야 했다. 테스트가 나쁘면 에이전트는 틀린 문제를 열심히 푼다. 오케스트레이션이 좋아도 eval이 약하면 시스템은 금방 헛돈다.

그래서 실무에서는 orchestration과 evals를 분리해서 생각하면 안 된다. 작업 단위를 나누는 순간, 각 단위의 성공 조건도 같이 잘라야 한다.

팀처럼 동작하는 agent 시스템에서 진짜 중요한 것

여기까지 정리하면 중요한 건 모델 IQ가 아니라 운영 구조라는 점이 보인다. 실제로 중요한 건 아래 다섯 가지다.

1. 역할 분리

planner, executor, reviewer처럼 꼭 이름을 붙이지 않아도 된다. 대신 계획, 실행, 검증, 상태 기록을 한 루프에 다 넣지 말아야 한다.

2. 작은 작업 단위

병렬화가 되려면 작업이 서로 덜 엉켜야 한다. 큰 문제를 작은 단위로 쪼개고, 각 단위가 독립적으로 성공과 실패를 가질 수 있어야 한다.

3. 안정적인 인터페이스

세션 로그, 도구 호출 규약, 샌드박스 provision, 이벤트 기록 같은 인터페이스는 모델보다 오래 간다. 이 층이 안정적이어야 하네스를 갈아끼울 수 있다.

4. 복구 가능한 상태

세션은 컨텍스트 윈도우 안에만 있으면 안 된다. 외부에 남아야 재개가 가능하다. 에이전트가 잠시 멈추거나 하네스가 죽어도 다시 깨울 수 있어야 한다.

5. 구조를 검증하는 evals

정답률만 보면 늦다. 역할 충돌, 중복 작업, 비용 폭증, 복구 실패 같은 시스템 수준 지표를 같이 봐야 한다.

마무리

좋은 AI Agent는 하나의 거대한 프롬프트가 아니다. 더 정확히 말하면, 오래 버티는 agent 시스템은 그렇게 만들면 안 된다. 단일 슈퍼 에이전트는 데모에서는 강해 보이지만, 운영으로 가면 도구 경계, 복구, 병렬화, 평가에서 금방 한계가 드러난다.

반대로 분업 구조는 처음 설계가 조금 더 어렵다. 하지만 한 번 역할과 경계를 나누고 나면, 모델이 좋아져도 구조를 유지할 수 있고, 실패를 국소화할 수 있고, 여러 에이전트를 실제 팀처럼 굴릴 수 있다.

에이전트 설계에서 먼저 봐야 할 건 똑똑함이 아니다. 누가 무엇을 맡고, 어떤 경계 안에서 움직이며, 실패했을 때 어디서 다시 시작할 수 있는가다. 결국 좋은 agent 시스템은 좋은 프롬프트보다 좋은 조직도에 더 가깝다.

참고 자료

• Scaling Managed Agents: Decoupling the brain from the hands : 세션, 하네스, 샌드박스를 분리한 managed agents 구조와 interface 설계
• Building a C compiler with a team of parallel Claudes : 병렬 에이전트, 역할 분리, 테스트 하네스, 장기 자율 작업 설계 사례
• Demystifying evals for AI agents : agent harness와 eval harness를 함께 보는 평가 구조와 실무적 grader 설계