계층형 아키텍처와 분해 드리프트(Hierarchical Architecture and Decomposition Drift)

계층형(Hierarchical) 구조는 감독자(supervisor)를 중첩한 형태입니다. 관리자 에이전트(manager agent) 아래에 하위 관리자(sub-manager)가 있고, 그 아래에 작업자(worker)가 있는 형태입니다. CrewAI의 Process.hierarchical이 교과서적 사례입니다. manager_llm이 동적으로 작업(task)을 위임하고 산출물(output)을 검증합니다. LangGraph의 대응 구현은 create_supervisor(create_supervisor(...))처럼 중첩된 호출입니다. 작업 자체가 실제 조직도(org chart)를 닮았을 때 자연스럽게 들어맞는 패턴입니다. 동시에 관리자 루핑(managerial looping)으로 무너질 가능성이 가장 높은 패턴이기도 합니다. 관리자 에이전트가 작업을 잘못 배정하거나, 하위 산출물을 잘못 해석하거나, 합의(consensus)에 도달하지 못하는 일이 자주 일어납니다. 차라리 순차형(Sequential) 파이프라인이 더 나은 결과를 내는 경우도 흔합니다.

유형: Learn + Build 언어: Python(stdlib) 선수 지식: Phase 16 · 05 (감독자 패턴; Supervisor Pattern) 예상 시간: 약 60분

문제

감독자 패턴이 익숙해지면 자연스럽게 떠오르는 다음 질문은 "작업자 자체가 또 다른 감독자라면 어떻게 될까?"입니다. 팀에는 하위 팀(sub-team)이 있고, 회사에는 부서 아래 또 다른 부서가 있습니다. 계층형 아키텍처는 바로 그 모습을 그대로 반영한 구조입니다.

문제는 LLM 기반 관리자가 인간 관리자와 같지 않다는 데서 시작합니다. 인간 관리자는 자기 팀원(report)들이 무엇을 알고 있는지에 대한 안정적인 사전 지식(prior)을 가지고 있습니다. 반면 LLM 관리자는 매 턴(turn)마다 자신의 컨텍스트(context)에 들어 있는 내용만 보고 조직 구조를 다시 추론합니다. 그 컨텍스트에 아주 작은 드리프트(drift)만 생겨도 트리(tree) 전체가 일감을 잘못 배정하기 시작합니다.

개념

형태

                 Manager
                 ┌─────┐
                 └──┬──┘
           ┌────────┴────────┐
           ▼                 ▼
       Sub-Mgr A         Sub-Mgr B
       ┌─────┐           ┌─────┐
       └──┬──┘           └──┬──┘
         ┌┴──┬──┐          ┌┴──┐
         ▼   ▼  ▼          ▼   ▼
       W1  W2  W3         W4  W5

모든 내부 노드(internal node)는 계획을 세우고, 일을 위임하고, 결과를 종합(synthesize)합니다. 실제 작업은 잎(leaf) 노드만 수행합니다.

잘 맞는 경우

• 명확한 조직 매핑(Clear org mapping): 실제 작업이 부서 단위로 나뉠 때 잘 맞습니다. 예를 들어 "법무(legal)가 문서를 검토하고, 재무(finance)도 검토하고, 엔지니어링(engineering)도 검토한 뒤 경영진(executive)을 위한 요약을 작성"하는 작업이라면 계층 구조가 그대로 드러납니다.
• 국소 요약(Local summarization): 각 하위 관리자가 자기 팀의 산출물을 먼저 종합한 뒤 최상위 관리자(top manager)에게 전달합니다. 최상위 관리자는 작업자 산출물 15개가 아니라 하위 관리자 요약 3개만 보면 됩니다.

깨지는 지점

2026년의 사후 분석(post-mortem)에서 반복적으로 발견되는 실패 모드는 다음 세 가지입니다.

1. 작업 배정 오류(Task assignment error): 관리자가 목표(goal)를 읽고 분해(decomposition)를 환각(hallucinate)한 뒤, 잘못된 하위 관리자에게 일을 위임합니다. 하위 관리자는 받은 일을 성실히 수행하기 때문에, 오류는 최상위 종합(top synthesis) 단계에서야 비로소 드러납니다. 사람이 잡을 수 있었던 지점보다 한 단계 위에서야 표면화되는 셈입니다.
2. 산출물 오해석(Output misinterpretation): 하위 관리자가 "주장(claim) X를 검증할 수 없음"이라고 반환했는데, 최상위 관리자는 이를 "주장 X는 확인되지 않음"이라고 요약합니다. 의미가 단계마다 조금씩 어긋나며 드리프트(drift)됩니다.
3. 합의 루프(Consensus loops): 두 하위 관리자가 의견이 갈립니다. 최상위 관리자는 조정(reconcile)을 요청합니다. 하위 관리자는 다시 아래로 일을 위임합니다. 작업자는 재실행합니다. 하위 관리자는 약간 다른 답을 다시 들고 올라옵니다. 그렇게 루프가 됩니다. CrewAI의 Process.hierarchical은 단계 제한(step limit)으로 이를 방어하지만, 이제는 그 한도(limit) 자체가 또 다른 하이퍼파라미터(hyperparameter)가 됩니다.

결정 질문

순차형(Sequential; 선형 파이프라인)과 계층형(Hierarchical) 가운데 무엇을 골라야 할까요? 핵심은 이렇습니다. 당신의 작업이 실제로 독립적인 하위 팀을 가지고 있는가, 아니면 트리(tree)인 척하는 하나의 선형 흐름(linear flow)에 불과한가? 후자라면 순차형을 쓰세요. 전자라면 계층형을 쓰되, 조정 규칙(reconciliation rule)에 명시적인 예산(budget)을 정해두세요.

CrewAI 구현

Process.hierarchical은 전문가 크루(specialist crew) 위에 관리자 LLM(manager LLM)을 얹어 연결합니다. 관리자는 다음과 같은 일을 합니다.

• 최상위 작업을 입력받습니다.
• 하위 작업(subtask)을 각 크루에 배정합니다.
• 크루가 만든 산출물을 평가합니다.
• 수용(accept), 재위임(re-delegate), 반복(iterate) 가운데 어느 쪽으로 갈지 결정합니다.

문서: https://docs.crewai.com/en/introduction 의 Core Concepts 아래 "Hierarchical Process" 항목을 확인하세요.

LangGraph 구현

LangGraph는 중첩된 create_supervisor 호출을 사용합니다. 안쪽 감독자(inner supervisor)는 자기 그래프(graph)를 따로 가지고, 바깥쪽 감독자(outer supervisor)는 안쪽 그래프를 불투명한 노드(opaque node)로 취급합니다. 이 방식은 CrewAI보다 디버깅이 쉽습니다. 각 그래프를 따로 한 단계씩(step through) 추적할 수 있기 때문입니다. 단점은 트리를 동적으로 재구성(reshape)하는 표현이 더 어렵다는 점입니다.

참고: https://reference.langchain.com/python/langgraph-supervisor.

직접 만들기

code/main.py는 3단계 계층(3-level hierarchy)을 실행합니다.

• 최상위 관리자(top manager): 작업을 "엔지니어링(engineering)"과 "법무(legal)" 분기(branch)로 나눕니다.
• 엔지니어링 하위 관리자(engineering sub-manager): "프런트엔드(frontend)"와 "백엔드(backend)" 작업자로 다시 나눕니다.
• 법무 하위 관리자(legal sub-manager): 작업자 한 명을 둡니다.

데모(demo)는 모두가 동의하는 정상 경로(happy path)와 교란 경로(perturbed path)를 비교합니다. 교란 경로에서는 최상위 관리자의 분해가 "legal"을 "finance"로 잘못 라벨링(label)합니다. 그 결과 오류가 어떻게 연쇄(cascade)되는지 관찰하게 됩니다. 하위 관리자는 성실히 재무 검토(finance review)를 수행하고, 최상위 종합자(top synthesizer)는 재무 관련 발견을 보고하지만, 원래 사용자가 묻고자 했던 법무 질문(legal question)은 끝내 답을 얻지 못합니다.

실행 방법:

python3 code/main.py

출력은 두 경로를 나란히 보여주면서 "무엇을 물었는가"와 "무엇이 전달되었는가"를 명확히 대조해 줍니다.

사용해보기

outputs/skill-hierarchy-fitness.md는 주어진 작업이 계층형(hierarchical), 순차형(sequential), 평면 감독자(flat supervisor) 가운데 어느 패턴에 적합한지 평가하는 스킬입니다. 입력은 작업 설명(task description), 조직 구조(org structure), 조정 예산(reconciliation budget)입니다. 출력은 패턴 추천과 함께, 반드시 방어해야 할 구체적인 실패 모드 목록입니다.

산출물 만들기

계층형을 실제로 배포(ship)한다면 다음 사항을 지키세요.

• 트리 깊이는 2단계로 제한: 단계가 3단계만 되어도 대부분의 오류가 관찰성(observability)에서 숨어 버립니다.
• 명시적인 조정 예산(reconciliation budget): 최상위 관리자가 결과를 확정(commit)하기 전 허용할 최대 라운드(round) 수를 정해 두세요. 보통 2회 정도가 적당합니다.
• 모든 종합에 출처(provenance) 표시: 각 노드의 요약은 어떤 잎(leaf) 산출물에서 비롯되었는지를 반드시 인용(cite)해야 합니다.
• 분해 드리프트(decomposition drift)에 대한 경고: 매 단계마다 관리자의 분해 결과를 로그(log)에 남기고, 사용자 질의(user query)와 차이(diff)를 비교하세요. 분해가 더 이상 원래 질의를 덮지 못하면(coverage 실패) 경고(alert)를 발생시켜야 합니다.

연습문제

1. (쉬움) code/main.py를 실행하고 정상 경로(happy path)와 교란 경로(perturbed path)를 비교하세요. 최상위 산출물이 사용자의 질문에서 완전히 벗어나(diverge)기까지 관리자 사이의 핸드오프(hand-off)가 몇 단계 필요했나요?
2. (중간) 세 번째 단계(top → sub → sub-sub → worker)를 추가해 보세요. 깊이가 깊어질수록 교란 경로가 스스로 회복하는 빈도와 완전히 벗어나는 빈도가 어떻게 변하는지 측정해 보세요.
3. (중간) 각 하위 관리자에 "카나리아(canary)" 작업자를 구현하세요. 이 작업자는 항상 원래 사용자 질문을 변경 없이 그대로 받습니다. 카나리아의 답을 사용해 분해 드리프트를 감지하세요. 카나리아의 답이 종합된 답과 어긋난다면, 관리자는 어떻게 반응해야 할까요?
4. (어려움) CrewAI의 Process.hierarchical 문서를 읽으세요. CrewAI가 실제로 적용하는 구체적인 가드레일(guardrail) 하나(예: 단계 제한, manager_llm 제약)를 찾아내고, 그것이 어떤 실패 모드를 겨냥하는지 설명하세요.
5. (어려움) 중첩된 LangGraph 감독자와 CrewAI 계층형 구현을 비교하세요. 조정 루프(reconciliation loop)를 더 저렴하게 감지할 수 있는 쪽은 어디인가요?

핵심 용어

더 읽을거리

• CrewAI introduction — Process.hierarchical — 관리자 LLM이 명시적으로 등장하는 교과서적 계층형 구조입니다.
• LangGraph supervisor reference — create_supervisor를 통한 중첩 감독자 구현입니다.
• Anthropic engineering — Research system — Anthropic이 계층형 대신 평면 감독자(flat supervisor)를 의도적으로 선택한 이유를 설명합니다.
• Cemri et al. — Why Do Multi-Agent LLM Systems Fail? — MAST 분류 체계(taxonomy)입니다. 조정 실패(coordination failure) 섹션에서 분해 드리프트를 문서화합니다.