"하네스 부록 E4 — Subagent와 Agent Teams 구분하기: 멀티에이전트 설계에서 언제 위임하고 언제 팀을 짤까"

-

멀티에이전트 이야기가 나오면 많은 사람이 subagent와 agent team을 거의 같은 뜻으로 쓴다. 하지만 둘은 운영 철학도, 비용 구조도, 필요한 통제 표면도 다르다. 이 글은 "언제는 위임이면 충분하고, 언제는 역할이 분리된 팀 구조가 필요한가"를 Q&A 형식으로 정리한 appendix finale다.

핵심 요약

  • subagent는 보통 본 에이전트가 경계가 있는 하위 작업을 위임하는 구조다.
  • agent team은 보통 역할이 분리된 여러 에이전트가 더 지속적인 협업 루프를 이루는 구조다.
  • 복잡해 보인다고 무조건 team이 필요한 것은 아니다. 많은 경우는 잘 설계된 delegation이면 충분하다.
  • 팀 구조는 역할 분리의 가치가 coordination 비용보다 클 때만 정당화된다.
  • 멀티에이전트 설계의 핵심 질문은 "몇 명이 필요한가"가 아니라 어디서 실패 도메인을 분리해야 하는가다.

1. 왜 이 구분이 중요한가

docs/blog_series_하네스엔지니어링_총괄_design.md는 E4를 "delegation vs persistent teams, Q&A형 정리"로 정의한다. 이 표현이 핵심을 잘 잡고 있다.

실무에서 자주 생기는 오해는 이렇다.

  • subagent를 쓰면 곧 멀티에이전트 팀이라고 생각한다
  • 역할을 나누기만 하면 자동으로 품질이 좋아질 것이라 기대한다
  • orchestration 비용, handoff 비용, 검증 비용을 과소평가한다

이 구분을 먼저 하지 않으면, 시스템은 쉽게 화려해지고 어렵게 운영된다.

2. 가장 짧은 정의

구조 짧은 정의
subagent 본 에이전트가 제한된 하위 작업을 맡기기 위해 잠시 띄우는 위임 단위
agent team 여러 역할이 비교적 지속적으로 협업하며 상태와 책임을 나누는 팀 구조

한 줄로 더 줄이면 이렇다.

  • subagent는 worker
  • agent team은 operating model

3. Q&A 1: subagent는 언제 충분한가

아래 조건에 가까우면 subagent만으로 충분한 경우가 많다.

  • 하위 작업 범위가 명확하다
  • 결과물을 본 에이전트가 다시 통합할 수 있다
  • 하위 작업끼리 서로 지속적으로 대화할 필요가 없다
  • 역할보다 격리와 병렬화가 더 중요하다

예:

  • 문서 섹션별 초안 분리 작성
  • 코드베이스 내 독립 파일 조사
  • 서로 충돌하지 않는 병렬 리서치

여기서는 "팀"보다 "위임 가능한 작업 조각"이 핵심이다.

4. Q&A 2: agent team은 언제 정당화되는가

반대로 아래 조건이면 team 구조를 고려할 만하다.

  • 서로 다른 역할이 장기간 유지돼야 한다
  • planning, execution, evaluation이 분리될수록 품질 이점이 크다
  • 상태 공유와 인계 규칙이 지속적으로 필요하다
  • coordination 비용을 감당할 만큼 산출물의 가치가 크다

예:

  • 장기 research orchestration
  • planner, generator, evaluator가 반복 루프를 이루는 구조
  • 여러 전문 역할이 각자 다른 tool surface를 가져야 하는 환경

이 경우에는 단순 위임보다 역할과 책임의 운영 모델이 더 중요하다.

5. Q&A 3: 격리와 협업은 어떻게 다른가

sources/260518_하네스엔지니어링_15장_블로그활용노트.md의 Claude 관련 메모는 "Skill is the manual, Subagent is the worker"라는 구분이 유용하다고 짚는다. 여기에 한 줄을 더 붙이면 이렇게 된다.

  • skill은 절차를 담는다
  • subagent는 하위 작업을 수행한다
  • team은 역할 간 협업 구조를 담는다

즉, subagent의 핵심 가치는 협업 그 자체보다 격리와 위임에 있다.

6. Q&A 4: 멀티에이전트가 항상 더 낫지 않은 이유는

대부분의 과대설계는 여기서 시작된다.

늘어나는 것 왜 비용이 되는가
조정 비용 누가 무엇을 언제 넘기는지 정해야 한다
검증 비용 출력이 늘수록 통합 검증이 어려워진다
상태 비용 공통 기억과 handoff 규칙이 필요해진다
책임 비용 실패 원인을 추적하기 어려워진다

그래서 멀티에이전트는 기능 확장이 아니라, 비용 구조의 변화다.

7. Q&A 5: 실무에서 먼저 물어야 할 질문

팀 구조를 고민할 때는 "몇 개 에이전트를 만들까"보다 아래 순서가 낫다.

  1. 실패를 정말 역할 분리로 줄일 수 있는가
  2. 아니면 좁은 tool surface와 좋은 검증만으로도 해결되는가
  3. 하위 작업끼리 지속 협업이 필요한가
  4. coordination 비용을 감수할 만큼 가치가 큰가
  5. 사람이 이해하고 운영할 수 있는가

첫 두 질문에서 예가 아니면, 대개 team보다 subagent 또는 단일 agent가 낫다.

8. 빠른 비교표

기준 subagent agent team
목적 위임, 격리, 병렬화 역할 분리, 지속 협업, 책임 분산
지속성 상대적으로 짧음 상대적으로 김
상태 공유 제한적이어도 됨 명시적 설계 필요
orchestration 가벼운 편 무거운 편
적합한 문제 독립 하위 작업 장기적 협업 문제
주된 위험 위임 경계 불명확 조정 비용 폭증

9. 우리 시리즈 맥락에서 다시 보면

이 시리즈의 다른 편들과 연결하면 구분이 더 또렷해진다.

  • C2는 긴 작업에서 handoff가 먼저라고 설명했다
  • C4는 메모리 소유권과 상태 통제권을 설명했다
  • D1은 역할 분리를 late-stage pattern으로 다뤘다
  • D4는 공개 사례에서 orchestrator-worker와 장시간 지속성 문제를 함께 보여 줬다

이 흐름을 보면 E4의 결론은 자연스럽다. 멀티에이전트 설계는 "많이 나누기"가 아니라, 필요할 때만 책임 경계를 분리하는 것이다.

10. Q&A 6: 언제 단일 agent가 더 낫나

의외로 많은 경우다.

  • 작업 범위가 좁다
  • 입력과 출력이 안정적이다
  • 검증이 명확하다
  • 역할 분리가 큰 이득을 주지 않는다

이 상황에서 team을 붙이면 얻는 것보다 잃는 것이 많다. D2에서 다룬 것처럼, 하네스 두께는 얇을수록 좋은 경우가 자주 있다.

11. Q&A 7: subagent를 써도 여전히 필요한 것

subagent는 편리하지만 공짜가 아니다. 최소한 아래는 필요하다.

  • 무엇을 맡길지 분명한 경계
  • 결과물 통합 책임자
  • 실패 시 상위 에이전트의 중단 규칙
  • 서로 충돌하지 않는 tool permission

즉, subagent는 팀보다 가볍지만 여전히 하네스 설계를 필요로 한다.

12. Q&A 8: agent team을 쓴다면 무엇을 먼저 설계해야 하나

team 구조로 갈 때는 멤버 수보다 먼저 아래를 정해야 한다.

먼저 정할 것 이유
역할 정의 planner, executor, evaluator가 왜 분리되는지 명확해야 함
산출물 계약 서로 무엇을 넘길지 형식이 정해져야 함
공통 상태 어떤 memory와 handoff를 공유할지 필요
승인 경계 누가 실행하고 누가 최종 승인하는지 분리 필요
종료 조건 언제 루프를 멈출지 명시해야 함

이 다섯 가지가 흐리면 team은 쉽게 시끄럽고 불투명해진다.

13. 최종 판단 규칙

빠르게 판단하려면 아래 한 줄 규칙이 유용하다.

  • 하위 작업을 잠깐 떼어 맡기면 되면 subagent
  • 역할 간 지속 협업과 상태 조율이 핵심이면 agent team

그리고 무엇보다:

  • 복잡한 구조는 기본값이 아니다
  • 단일 agent에서 해결 가능한 문제를 굳이 팀으로 만들지 않는다

14. 이 부록 시리즈의 마무리

E1은 용어를 정리했고, E2는 출처를 정리했고, E3는 설계 카드를 정리했다. E4는 이제 "언제부터 구조를 더 나눌 것인가"를 정리한다.

  • E1: 용어 경계
  • E2: 근거 경계
  • E3: 업무 설계 경계
  • E4: 역할 분리 경계

그래서 E4의 핵심 메시지는 단순하다. 멀티에이전트는 멋있어 보여서가 아니라, 분리 이익이 조정 비용을 이길 때만 써야 한다.

참고 자료

  • docs/blog_series_하네스엔지니어링_총괄_design.md
  • sources/260518_하네스엔지니어링_15장_블로그활용노트.md
  • drafts/blog/260519_Claude하네스B02_CLAUDEmd_Skills_Hooks_Permissions_블로그.md
  • drafts/blog/260519_하네스시리즈C02_장시간에이전트운영_블로그.md
  • drafts/blog/260519_하네스시리즈D01_하네스패턴12선_블로그.md
  • drafts/blog/260519_하네스시리즈D04_실전사례로배우는하네스엔지니어링_블로그.md

이 글은 부록 컴패니언 시리즈의 E4 편입니다. 이 편으로 부록 시리즈가 끝납니다.

시리즈 전체 안내: 하네스 엔지니어링 시리즈 안내

댓글

댓글 쓰기

이 블로그의 인기 게시물

"LLM 핵심 학습 (1/6) — 기본: 토큰화·임베딩·어텐션·위치 인코딩"

-
이미지
(시리즈 시작) 📚 시리즈 목차 2/6 파인튜닝 → 트랜스포머 한 블록의 데이터 흐름을 문자열 → 토큰 → 임베딩 → 어텐션 → 출력 표현 까지 손으로 풀어 본다. 이번 편이 끝나면 "왜 \(\sqrt{d_k}\)로 나누는가", "RoPE는 무엇을 회전시키는가", "한국어가 영어보다 토큰이 많은 까닭은 무엇인가"가 한 줄로 설명될 수 있다. 0. 학습 목표 이 편을 마치면 다음을 직접 할 수 있다. BPE 토크나이저 가 어휘를 어떻게 학습하고 새 문자열을 어떻게 자르는지 종이 위에서 시뮬레이션한다. 임베딩 행렬 의 모양과 초기화, weight tying의 의미를 한 줄로 설명한다. Scaled Dot-Product Attention 의 식을 차원 단위로 추적하고 PyTorch 30줄로 재현한다. Multi-Head Attention 이 한 헤드와 비교해 무엇이 다른지, 헤드 수가 늘면 어디가 비싸지는지 답한다. Sinusoidal·RoPE·ALiBi 세 위치 인코딩의 식과 외삽 성질을 구분한다. 컨텍스트 확장이 왜 \(O(N^2)\)인지, "Lost in the Middle"이 왜 발생하는지 설명한다. 1. 핵심 요약 트랜스포머의 입력은 문자열 이 아니라 정수 ID 시퀀스 다. 토크나이저가 문자열 → ID로 자른다. 임베딩은 정수 ID를 \(d\)차원 벡터로 lookup하는 학습 가능한 테이블이다. Self-Attention은 \(\text{softmax}(QK^\top / \sqrt{d_k}) V\) 한 줄이 핵심이고, 멀티헤드는 같은 연산을 여러 부분 공간에서 병렬화한 것이다. 위치 정보는 임베딩에 직접 더하거나(Sinusoidal), Q·K에 회전을 가하거나(RoPE), 어텐션 스코어에 거리 패널티를 더해서(ALiBi) 주입한다. 컨텍스트 길이 \(N\)에 대해 표준 어텐션은 \(O(N^2)\) 비용을 갖고, 긴 컨텍스트에서는 중간 위...
Read more »

"LLM 핵심 학습 (2/6) — 파인튜닝: LoRA·QLoRA·증류·Adapter"

-
이미지
← 1/6 기본 📚 시리즈 목차 3/6 디코딩과 생성 → 사전학습된 LLM을 내 데이터 에 적응시키는 방법을 비용·메모리·일반화 관점에서 정리한다. Full FT의 한계 → Adapter → LoRA → QLoRA → Distillation 순으로 같은 그림을 점점 확대해 본다. 0. 학습 목표 Full fine-tuning의 메모리 병목을 옵티마이저 상태·그래디언트·가중치·활성화 의 4분할로 설명한다. Adapter(Houlsby 2019)와 LoRA(Hu 2021)의 식 차이를 한 줄로 적는다. LoRA의 \(A, B\) 행렬이 왜 저랭크 이고, rank \(r\) 선택이 무엇을 결정하는지 답한다. QLoRA(Dettmers 2023)의 NF4·double-quant·paged optimizer를 분리해서 설명한다. Catastrophic Forgetting을 분포 시프트 관점에서 정의하고 완화 기법을 두 개 이상 든다. Hinton 2015의 Knowledge Distillation 식을 손으로 유도한다. 1. 핵심 요약 Full FT는 메모리/디스크/시간 모두 비싸다. 7B 모델 full FT는 V100 8장 + A100 1장으로도 큰 부담이다. PEFT(파라미터 효율 파인튜닝) 일가족은 극히 일부 파라미터만 학습 해 같은 효과를 얻는다. LoRA: \(\Delta W = BA\) (rank \(r \ll \min(d_{\text{in}}, d_{\text{out}})\))로 가중치 업데이트를 저랭크 분해. QLoRA: 베이스 모델을 4-bit(NF4)로 양자화한 채 LoRA만 풀-정밀(BF16)으로 학습. Catastrophic Forgetting: 새 분포에 적응하느라 이전 능력이 무너지는 현상. PEFT 자체가 부분 완화책. Distillation: 큰 교사 모델의 soft target 을 학습 신호로 써서 작은 학생 모델 을 만든다. 2. 직관: 왜 사전학습만으로는 부족한가 사전학습은 일반...
Read more »

"ML 기초 학습 (1/9) — 머신러닝과 sklearn: 학습의 좌표계"

-
이미지
(시리즈 시작) 📚 시리즈 목차 2/9 이웃 알고리즘 → 이 시리즈는 신경망과 로컬 LLM으로 가기 전에 손에 익혀 둬야 할 머신러닝 기초 9편이다. 1편은 모든 ML 코드가 공유하는 공통 문법 을 잡는 데 쓴다. sklearn은 그 문법을 가장 일관되게 보여주는 도구다. 이번 편이 끝나면 어떤 모델을 만나도 fit → predict → score → 평가 흐름이 같다는 것이 손에 잡힌다. 0. 학습 목표 이 편을 마치면 다음을 할 수 있어야 한다. 지도학습·비지도학습·강화학습을 한 문장씩 구분해 설명한다. sklearn의 estimator 인터페이스 ( fit , predict , score , transform )를 코드 한 화면 안에서 쓸 수 있다. train/validation/test 분할을 왜 하는지, 어디서 데이터 누수가 생기는지 식과 그림으로 설명한다. 분류·회귀의 핵심 평가 지표(accuracy, precision, recall, F1, MSE, R²)를 정의에서 직접 계산할 수 있다. k-fold 교차검증 을 코드 한 줄로 돌리고, 결과의 평균과 표준편차를 함께 보고할 수 있다. Pipeline 으로 전처리와 모델을 묶어 데이터 누수를 구조적으로 막는 방법을 설명한다. 1. 핵심 요약 머신러닝은 데이터에서 함수 \(f: X \to Y\)를 찾는 작업 이다. 어떤 모델이든 이 본질은 같다. sklearn은 모든 모델을 같은 인터페이스( fit , predict , score )로 통일해, 모델을 바꿀 때 한 줄만 바꾸면 되게 한다. train/val/test 세 분할이 표준이다. 검증으로 하이퍼파라미터를 고르고, 테스트는 마지막에 한 번만 본다. 데이터 누수 (test 정보가 train에 새는 현상)는 ML 입문자가 가장 자주 만드는 실수이며, Pipeline + cross_val_score 조합으로 구조적으로 막을 수 있다. 평가 지표는 문제 유형 (분류/회귀) 과 클래스 불균형...
Read more »