6. 멀티에이전트 위임 — 무엇을 나누어 들게 하고 무엇은 직접 드는가

이 글은 시리즈 Alice 활용법의 6편이다. 5편 훅과 자동화까지가 한 명의 협업자(Alice)의 mind를 어떻게 설계할 것인가를 다뤘다면, 이 글은 그 한 명에게 모든 일을 맡기지 않는 구조 — mind를 수평으로 나누어 들게 하는 일에 대한 기록이다.

0. 위임은 mind를 한 컨텍스트가 다 들지 않게 나누는 일이다

한 명의 협업자에게 모든 일을 시키면, 그 협업자의 컨텍스트 윈도우가 빠르게 찬다. 차면 결정의 질이 떨어진다. 떨어진 결정은 운영자가 매번 점검해야 한다. 그러면 운영자의 mind 부담이 다시 늘어난다.

위임은 이 흐름을 끊는 구조다. 큰 작업을 잘게 나눠 서브 협업자에게 맡기고, 메인 협업자는 결과의 요약만 받는다. 각 서브는 자기 컨텍스트로 한 가지에 집중한다. 메인의 컨텍스트는 결정에 필요한 정보만 유지된다.

다만 위임에는 비용이 있다 — 위임 전 brief를 적어야 하고, 결과를 검증해야 하고, 통합해야 한다. 이 비용보다 분산의 이득이 크지 않으면 위임은 손해다.

이 글은 어떤 작업이 위임할 가치가 있는지, 위임이 약속을 지키게 하는 게이트는 어떻게 만드는지, 그리고 위임의 함정에 대한 기록이다.

서브에이전트 메커니즘 자체는 Anthropic Claude Code의 subagents 시스템에서 차용했다. 이 글은 그 메커니즘을 어떻게 활용했는가에 대한 기록이지, 그 자체의 발명이 아니다.

1. 메인-서브 분업 — 누가 무엇을 드는가

운영자가 수렴한 분업.

핵심은 — 메인은 결정 권한과 메모리를 들고, 서브는 작업과 깊은 컨텍스트를 든다. 둘이 같은 일을 들지 않는다. 중복은 곧 컨텍스트 낭비다.

이 분업이 깨지는 가장 흔한 경우 — 메인이 서브의 작업 디테일까지 다 알려고 들기. 그러면 메인의 컨텍스트가 차고, 서브를 둔 의미가 사라진다.

메인은 무엇을 모르는지 알고 있어야 한다. 모르는 부분은 서브가 들고 있다.

2. 어떤 작업이 위임 가능한가 — 5조건

모든 작업이 위임될 수 있는 것은 아니다. 다음 다섯 가지를 모두 통과하는 것만 서브로 내려간다.

2.1 입력이 닫혀 있는가

서브는 메인 컨텍스트의 일부를 일회성으로 받는다. 작업 도중 메인에게 "이거 더 알려 줘" 같은 양방향 대화가 어렵다. 그러니 시작 시점에 필요한 모든 입력이 brief 안에 닫혀 있어야 한다.

입력이 닫히지 않으면 서브는 추측으로 채운다. 추측은 자주 어긋난다.

2.2 출력이 요약 가능한가

서브의 결과가 메인 컨텍스트로 돌아올 때는 요약만 들어와야 한다. 결과 자체가 본질적으로 길고 요약 불가능하다면 — 예를 들어 "이 100개 파일 모두 검토" 같은 — 위임의 의미가 줄어든다. 결국 메인이 100개 파일 요약을 다 흡수해야 하기 때문.

2.3 결정 권한이 메인에 남는가

서브가 작업 중 운영자의 결정 권한 영역을 침범하지 않아야 한다. "DB 스키마 바꿔도 되나" 같은 질문은 서브가 결정할 수 없다. 그런 결정이 작업 중 나올 가능성이 있다면 — brief에 미리 권한 표를 명시하거나, 결정 지점에서 서브가 멈추고 메인에 보고하도록 설계해야 한다.

2.4 검증이 자동 가능한가

서브의 결과를 운영자가 매번 손으로 검증해야 한다면 위임의 이득이 사라진다. 자동 검증 스크립트가 함께 만들어질 수 있는 작업만 위임 가능. (§4 게이트 참조)

2.5 한 가지 일에 집중되는가

서브는 한 가지 일을 한다. "이 컴포넌트 리팩토링 + 테스트 추가 + 문서 갱신" 같은 복합 작업은 위임하지 않는다. 셋으로 쪼개서 각각 다른 서브에게. 한 서브가 여러 일을 들면 컨텍스트가 뒤섞이고 출력이 모호해진다.

3. 위임의 비용 — 언제 직접 하는 게 나은가

위임이 항상 이득은 아니다. 비용을 정리하면.

• Brief 작성 비용 — 무엇을, 왜, 어떻게, 어디까지를 글로 정리해야 함
• 컨텍스트 정리 비용 — 서브가 알아야 할 것만 추려서 전달
• 검증 비용 — 결과를 신뢰하기 위한 자동 검증 + 메인의 재확인
• 통합 비용 — 결과를 메인 컨텍스트로 흡수

이 네 비용의 합이 직접 하는 비용보다 작아야 위임이 이득이다. 운영자의 경험상 — 30분 이하로 끝나는 단순 작업은 위임이 손해, 2시간 이상 걸리거나 5+ 파일을 만지는 작업은 위임이 이득이다.

작업 크기로 나누지 않은 위임은, 위임이 아니라 단순 책임 회피다.

4. 위임 게이트 — 약속을 코드로 강제하기

위임이 가장 자주 실패하는 패턴은 — brief는 적었는데 검증과 머지 게이트가 빠진 것이다. 그러면 결과물에 약속과 다른 격차가 누적되어도 한참 뒤에야 발견된다.

운영자는 한 번 이 패턴으로 실제 손해를 본 후, 위임 시 항상 세 가지를 같은 PR에 묶는다.

4.1 위임서 (Brief)

무엇을, 왜, 어떻게, 어디까지를 명세한 문서. 서브가 시작 전 한 번 읽고 시작한다. brief에는 다음이 들어간다.

• 목표와 완료 조건 (Definition of Done)
• 입력 (메인 컨텍스트에서 추출된 것)
• 산출물 형식 (어떤 파일을, 어떤 구조로)
• 결정 권한 표 (자율 결정 / 메인 보고 / 절대 금지)
• 검증 방법 (자동 스크립트 명시)
• 머지 게이트 (CI에서 무엇이 통과해야 머지 가능한지)

4.2 자동 검증 스크립트

결과를 사람이 매번 확인하지 않아도 되도록 — 운영 가능한 스크립트로. 예를 들어 "이 컴포넌트 리팩토링" 위임이면 npm run verify:component-x 같은 스크립트가 brief와 같은 PR에 들어 있어야 한다.

검증 스크립트가 없는 brief는 brief가 아니다. 그냥 의사 표시일 뿐이다.

4.3 머지 게이트

검증 스크립트가 CI에서 실행되고, 통과하지 못하면 머지가 막히도록 설정. 검증을 약속만 하고 게이트를 안 만들면 — 결국 검증을 안 돌린 채로 머지되는 일이 생긴다.

이 세 가지(brief + 검증 + 게이트)는 같이 가야 한다. 하나라도 빠지면 약속이 코드로 강제되지 않고, 약속은 무너진다.

약속을 코드로 강제하지 않으면 격차가 누적된다.

5. 운영 중 위임 예시

운영자가 실제로 매주 위임하는 패턴 일부.

5.1 코드베이스 광범위 탐색

"X 키워드가 어디서 어떻게 쓰이는지 전부 찾아라" 같은 작업은 서브에게. 서브는 grep/glob/find로 전체를 훑어 결과를 정리한다. 메인은 정리된 요약만 받는다.

이런 작업을 메인이 직접 하면 — 메인 컨텍스트에 수백 개 매치 결과가 들어찬다. 결정에 쓸 자리가 사라진다.

5.2 빌드·테스트 실행

"이 변경에 lint + 빌드 + 테스트 돌려서 결과 요약해" 같은 작업도 서브로. 서브는 출력 전체를 받고, 메인에는 "통과" / "실패 (3건, 첫 두 줄: ...)" 같은 요약만 보낸다.

5.3 검토 (review)

"이 PR 보안 관점에서 검토해" 같은 작업. 서브가 코드를 다 읽고 issue 목록을 정리한다. 메인은 issue 개수와 가장 중요한 3개만 받는다.

5.4 광범위 자료 조사

"이 라이브러리의 알려진 보안 이슈와 대안" 같은 외부 조사. 서브가 여러 출처를 훑고 정리해 보고. 메인은 결정에 필요한 짧은 요약만 흡수.

5.5 누적된 효과

한 작업당 컨텍스트 절약은 크지 않다. 하지만 매일 5-6번 위임이 들어가면 — 메인 컨텍스트는 결정에만 집중된 상태로 하루 종일 유지된다. 운영자의 보고 받는 형식이 일관되고, "메인이 다 들고 있어서 헷갈리기 시작" 같은 사태가 사라진다.

6. 함정 — 위임이 잘못되는 패턴

운영자가 한 번씩 다 해본 실패 패턴.

6.1 검증 없는 위임

가장 흔한 함정. brief만 적고 위임. 결과를 받았는데 검증할 방법이 없어서 매번 손으로 확인. 위임의 이득이 모두 사라짐. → §4 게이트 3종이 답.

6.2 입력이 열린 위임

"이거 적당히 알아서 처리해 줘" 같은 위임. 서브는 추측으로 채우고, 추측은 어긋난다. → brief를 짧더라도 닫혀 있게.

6.3 결정 권한이 흐린 위임

서브가 작업 중 "이거 바꿔도 되나" 부딪힌 후 자기 판단으로 진행. 운영자가 봤을 때 의도와 다름. → brief에 권한 표 명시 + 결정 지점에서 멈추는 패턴.

6.4 너무 잘게 쪼갠 위임

5분짜리 작업까지 위임. brief 작성 비용이 작업 비용을 넘는다. 직접 하는 게 빠르다. → 30분 이하 작업은 위임 안 함.

6.5 통합 비용 무시

서브 결과를 한 번에 통합하기 어려운 경우. 5개 서브가 동시에 다른 파일을 만져 충돌. → 서브들의 작업 영역이 겹치지 않도록 brief에서 미리 분할.

7. 결정 — 위임 vs 직접의 판단 흐름

운영자가 새 작업을 받았을 때 따르는 결정 흐름.

새 작업
  ↓
30분 이하인가? → 예 → 직접
  ↓ 아니오
입력이 닫혀 있는가? → 아니오 → 직접 (또는 입력 정리부터)
  ↓ 예
검증 자동화 가능한가? → 아니오 → 직접 (위험 큼)
  ↓ 예
한 가지 일인가? → 아니오 → 분할 후 각각 위임
  ↓ 예
→ 위임 (brief + 검증 스크립트 + 머지 게이트 묶음)

이 흐름이 머릿속에 깔려 있으면 위임 vs 직접 결정이 빠르다. 매번 새로 고민하지 않아도 된다.

8. 한 원칙으로 압축

위임 설계의 핵심은 한 문장으로 줄어든다.

"메인이 결정과 메모리를 들고, 서브가 작업과 깊은 컨텍스트를 든다. 위임은 항상 brief + 검증 + 게이트 세 가지를 묶어서 보낸다."

이 원칙이 지켜지면 위임은 메인 컨텍스트를 결정 모드로 유지하는 가속기가 된다. 지켜지지 않으면 — 위임이 책임 회피가 되고, 결과 통합이 매번 운영자의 부담이 된다.

다음 글에서는 위임된 작업이 "끝났다"고 돌아왔을 때 그것이 진짜 끝났는지를 시스템이 강제하는 장치 — 검증 루프, 즉 코드 작업의 "완료" 정의를 어떻게 잡아 두는가에 대해 다룬다.