매니저 에이전트 하나로 수십 에이전트 관리하기

에이전트 하나 추가하는 데는 몇 분이면 됩니다. 그런데 마흔 명과 일하면 하루가 다 갑니다. 누군가는 에이전트를 고르고, 지시하고, 결과를 확인해야 하는데 그 누군가가 나이기 때문입니다.

매니저 에이전트는 이 일의 대부분을 대신 맡습니다. 나는 한 명과 이야기하고, 나머지는 매니저가 상대합니다. 플라이휠 예시는 에이전트 17명과 사람 한 명으로 한 해를 마쳤습니다. 이 글은 사람 한 명이 어떻게 거기까지 가는지를 다룹니다.

짧게 요약하면

1. 에이전트가 몇 명을 넘어가면 병목은 내 시간입니다.
2. 매니저 에이전트가 하는 일은 네 가지입니다. 고르고, 나누고, 나에게 올리고, 결과를 모읍니다.
3. 매니저 한 명이 한 번에 맡는 수는 여덟 명 안팎입니다. 층을 쌓으면 계산상 수백 명까지 늘지만, 비용과 실수도 함께 늡니다.
4. 예산, 되돌릴 수 없는 일, 매니저의 규칙은 내 몫으로 남습니다.
5. 지금 endue 에서는 비서를 쓰거나, 내 매니저를 MCP 로 붙일 수 있습니다. 50명 안팎까지는 지금 있는 기능으로 됩니다. 수백 명은 아직 검증하지 못했고, 이유는 마지막 절에 적었습니다.

1. 병목이 나에게로 옮겨 옵니다

에이전트를 하나 늘릴 때마다 잔일이 따라옵니다. 맞는 일에 고르기, 지시 쓰기, 결과 읽기, 질문에 답하기. 하나하나는 1, 2분이면 끝납니다.

다섯 명이면 커피 한 잔 마시는 동안 끝납니다. 이 예시의 마흔 명이면 하루가 다 갑니다. 에이전트는 동시에 돌지만 나는 그럴 수 없습니다. 팀이 커질수록 나를 기다리는 시간이 길어집니다.

해결책은 에이전트를 한 명 더 두는 것입니다. 이 에이전트는 그 모든 일을 읽고, 사람이 봐야 할 것만 넘깁니다.

2. 매니저 에이전트가 하는 일 네 가지

• 고르기. 각 에이전트가 무슨 일을 하는지 읽고 맞는 에이전트를 고릅니다. 에이전트 소개를 잘 써 둔 만큼만 잘 고릅니다.
• 나누기. 요청 하나를 여러 조각으로 나눠 각자에게 지시를 줍니다. 에이전트끼리는 서로의 대화를 보지 못하므로, 지시에 목표, 맥락, 완료 기준이 다 들어 있어야 합니다.
• 올리기. 답할 수 있는 건 직접 답하고 나머지는 나에게 넘깁니다. 내가 정해야 할 선택, 되풀이되는 실패, 돈이 걸린 일이 그렇습니다.
• 모으기. 결과를 답 하나로 모읍니다. 나는 한 번만 읽으면 됩니다.

좋은 매니저는 직접 하는 일이 적습니다. 매니저가 보도자료를 쓰기 시작하면 나머지 일곱 명은 아무도 보지 않게 됩니다.

3. 매니저 한 명이 맡을 수 있는 범위

사람을 관리하는 매니저도 직속 인원이 여덟 명 안팎이면 한계에 이릅니다. 에이전트에게는 다른 이유로 비슷한 한계가 있습니다. 매니저가 읽는 결과마다 맥락 공간을 차지하고, 어느 선을 넘으면 흐름을 놓칩니다. 처음에는 한 번에 여덟 명으로 시작하면 좋습니다.

한 번에 여덟 명이어도 명단은 훨씬 길 수 있습니다. 매니저가 마흔 명을 알고, 이번 요청에는 세 명만 부르면 됩니다. 층을 더 쌓을 때는 매니저 한 명이 진행 중인 일을 따라가지 못할 때입니다. 명단이 길다는 것만으로는 층이 필요하지 않습니다.

계산만 보면 넉넉합니다. 8명, 64명, 512명. 대신 비용이 두 가지 따라옵니다.

• 매니저도 토큰을 씁니다. 이 예시에서 512명을 굴리려면 매니저가 73명 필요합니다.
• 실수가 곱해집니다. 넘길 때마다 95% 맞는다면, 세 번 넘긴 일이 온전히 도착할 확률은 86%입니다.

그러니 층은 가능한 한 늦게 쌓으세요.

4. 내 몫으로 남는 일

• 예산. 매니저는 빠르게 쓸 수 있습니다. 팀이 얼마까지 쓸지는 사람이 정합니다.
• 되돌릴 수 없는 일. 고객에게 보내기, 데이터 지우기, 돈 옮기기. 직접 승인하거나, 어떤 것을 통과시킬지 미리 정해 둡니다.
• 매니저의 규칙. 혼자 정해도 되는 일과 나에게 가져와야 하는 일을 정합니다.
• 표본 확인. 매니저가 괜찮다고 한 결과 몇 개를 직접 읽습니다. 자기 팀을 평가하는 매니저도 틀릴 수 있습니다.

그럼 어떻게 하면 될까요?

1. 에이전트마다 일을 하나만 주고, 소개를 한 문장으로 쓰세요. 매니저는 그 소개를 보고 고릅니다. 소개가 흐리면 잘못 고릅니다.
2. 여덟 명 이하로 시작하세요. 일에 빈자리가 보일 때 한 명씩 늘립니다.
3. 나에게 꼭 와야 하는 일을 적어 두세요. 예를 들면 고객에게 나가는 것, 정한 금액을 넘는 것, 같은 실패가 두 번 난 것입니다.
4. 넘길 때마다 맥락을 다 담으세요. 목표, 지금까지 된 것, 완료 기준입니다.
5. 매주 숫자 세 개를 보세요. 나까지 온 일의 수, 다시 돌려보낸 결과의 수, 일 하나를 끝내는 데 든 비용입니다. 에이전트를 늘릴수록 첫 번째 숫자가 오르면, 더 늘리기 전에 규칙부터 고치세요.

endue 는 어디에 들어가나

endue 에 「매니저 에이전트」라는 설정은 없습니다. 지금은 두 가지 구성으로 같은 일을 할 수 있습니다. 비서, 그리고 MCP 로 붙인 내 매니저입니다.

비서: 바로 쓸 수 있습니다

계정마다 한 명씩 있습니다. 설정 › 일반 › 비서 의 「비서 사용」으로 켜고 끕니다. 어느 화면에서든 ⌥Space 를 누르고 필요한 일을 말하면 됩니다.

비서는 에이전트의 이름, 소개, 스킬 이름, 연결 종류를 보고 고릅니다. 요청 하나를 최대 8명에게 맡기고, 결과를 요약 하나로 모읍니다. 에이전트가 나를 찾으면 대화에 바로 뜹니다. 빼고 싶은 에이전트는 「비서에게 맡기지 않기」 목록에 넣습니다. 자세한 내용은 릴리스 노트에 있습니다.

이름과 말투는 내가 정할 수 있습니다. 지시문은 넣을 수 없고, 내가 말을 걸 때만 움직입니다. 예약이나 API 로는 부를 수 없습니다.

MCP 로 붙인 내 매니저: 규칙을 직접 씁니다

내가 쓴 규칙대로 움직이는 매니저를 원하면 Claude Code, Cursor, VS Code 를 MCP 로 endue 에 연결하세요. 설정 › 계정 › MCP 연결 에서 연결을 만들고, 부를 에이전트마다 「MCP 로 이 에이전트 실행」을 켭니다. 절차는 설정 안내에, 개념은 이 글에 있습니다.

이제 내 클라이언트가 에이전트 목록을 보고, 한 명을 읽고, 실행하고, 진행을 확인할 수 있습니다. 규칙은 이렇게 줍니다.

너는 내 endue 에이전트들의 매니저다.
- list_agents 로 목록을 보고 소개를 읽어 고른다. id 를 추측하지 않는다.
- 각 에이전트에게 목표, 맥락, 완료 기준을 준다.
  에이전트는 이 대화를 보지 못한다.
- 실행 결과가 running 이나 awaiting_approval 이면 get_session 으로
  확인한다. 다시 시작하지 않는다.
- 승인, 되풀이되는 실패, 고객에게 나가는 것은 나에게 가져온다.
- 모두 끝나면 링크를 담은 요약 하나를 준다.

스페이스에도 작은 방법이 하나 있습니다. Front Desk 의 에이전트가 요청을 받아 일을 시작하고, 방에서는 @지목으로 한 에이전트에게 맡깁니다.

매니저를 살펴보는 화면

매니저는 나에게 보고합니다. 그 매니저를 내가 확인하는 화면은 따로 있습니다.

활동에서는 대기, 진행, 실패, 완료를 에이전트별로 보고 멈추거나 다시 시도합니다. 알림은 내가 볼 일을 한 목록에 모읍니다. 사용량에서는 어느 에이전트가 크레딧을 쓰는지 봅니다.

아직 없는 것

• 층 쌓기. 일반 에이전트는 아직 다른 에이전트에게 일을 넘기지 못합니다. 3절의 층은 endue 안에서 만들 수 없습니다.
• 에이전트별 예산과 전체 멈춤. 크레딧은 계정 단위이고, 실행은 하나씩 멈춥니다. 에이전트별 크레딧 한도는 endue Live 에만 있습니다. 에이전트별 키를 쓰면 비용은 나눠 볼 수 있습니다.
• 수백 명. 그 규모는 검증하지 못했습니다. 지금은 여러 목록이 50명에서 멈춥니다. list_agents, 비서가 스스로 살피는 후보, 콘솔의 에이전트 목록입니다. 요금제의 크레딧도 따로 한계를 정합니다.

비서와 여덟 명으로 시작해 보세요. 일주일 동안 나까지 온 일을 세어 보고요. 팀이 커져도 그 숫자가 낮게 유지되면, 매니저가 제 역할을 하는 겁니다.