에이전트 워크플로를 하드코딩하지 마세요 (혹은 하지 마세요): 개발자를 위한 Supervisor Delegation 가이드

만약 여러분이 지금 LLM 에이전트(LLM agents)를 활용해 무언가를 구축하고 있다면, 아마도 다음과 같은 갈림길에 서 있을 것입니다. 어떤 에이전트가 무엇을 처리할지 하드코딩(hardcode)할 것인가, 아니면 "Supervisor(관리자)" 에이전트가 런타임(runtime)에 결정하도록 할 것인가?

영리한 해결책을 선택하고 싶은 유혹이 생깁니다. 동적 위임(dynamic delegation)은 마치 좋은 객체 지향 프로그래밍(OOP)처럼 "제대로 된" 방식처럼 느껴지기 때문입니다. 하지만 이러한 시스템을 몇 개 출시해 본 결과, 정답은 짜증 날 정도로 문맥(context)에 따라 달라진다는 것을 고통스럽게 배웠습니다.

여러분이 토큰 예산(token budget)을 낭비하기 전에 결정을 내릴 수 있도록, 그 트레이드오프(trade-offs)를 안내해 드리겠습니다.

두 가지 접근 방식 (60초 요약)

**하드코딩된 라우팅(Hardcoded routing)**은 이름 그대로입니다:

def route_task(task):
    if "refund" in task.lower():
        return refund_agent.handle(task)
...

단순합니다. 결정론적(Deterministic)입니다. 라우팅 로직에 소모되는 토큰이 전혀 없습니다.

**Supervisor 위임(Supervisor delegation)**은 LLM을 라우팅의 책임자로 둡니다:

def route_task(task):
    supervisor_prompt = f"""
    Given this task: {task}
...

유연합니다. 예상하지 못한 엣지 케이스(edge cases)를 처리합니다. 또한, 모든 요청마다 토큰 비용이 발생합니다.

Supervisor가 실제로 제값을 하는 경우

동적 위임은 입력 공간(input space)이 진정으로 예측 불가능할 때 의미가 있습니다. 다음과 같은 경우를 말합니다:

리서치 워크플로(Research workflows): 쿼리가 웹 검색(web search), 데이터베이스 조회(database lookup), 또는 코드 실행(code execution) 중 무엇이 필요한지 사전에 알 수 없는 경우
멀티 도메인 고객 지원(Multi-domain customer support): 단일 티켓이 결제, 기술 지원, 계정 관리를 모두 다룰 수 있는 경우
데이터 파이프라인(Data pipelines): 들어오는 데이터의 형태에 따라 어떤 변환 에이전트(transformation agents)가 실행될지 결정되는 경우

핵심 신호는 다음과 같습니다: 패턴을 진정으로 알 수 없기 때문에 if/else 트리를 작성할 수 없는 경우입니다.

만약 여러분이 이 부류에 속한다면, supervisor and sub-agents 방식이 유지보수 불가능한 라우팅 로직의 혼란으로부터 여러분을 구해줄 수 있습니다.

그냥 if 문을 작성해야 하는 경우

솔직히 말해서: 대부분의 엔터프라이즈 사용 사례는 우리가 생각하는 것보다 훨씬 제약적입니다.

고객 서비스 분류(triage)? 아마 6~10개의 의도 카테고리가 있을 겁니다. 문서 분류? 20개 미만의 유형일 가능성이 높습니다. 내부 도구 자동화? 사용자에게 어떤 질문을 할지 정확히 알고 있기 때문에 인터페이스를 통제할 수 있습니다.

계획 문서를 작성하면서 케이스들을 열거(enumerate)할 수 있다면, 라우팅은 하드코딩할 수 있습니다.

하드코딩된 라우팅이 제공하는 이점:

예측 가능한 비용: 예상치 못한 토큰 급증 방지
빠른 실행 속도: LLM 호출을 완전히 건너뛸 수 있음
쉬운 디버깅: 스택 트레이스가 '슈퍼바이저가 이상한 선택을 했다'보다 낫습니다.
간단한 관측 가능성(Observability): 어떤 코드 경로가 실행되었는지 정확히 알 수 있습니다.

여기서 시작하세요. 실제로 필요할 때 슈퍼바이저를 나중에 추가해도 됩니다.

아무도 말해주지 않는 숨겨진 비용들

동적 위임(dynamic delegation)이 작동하더라도, 이는 여러분에게 치명적인 방식으로 비용을 증가시킵니다:

슈퍼바이저 추론: 모든 요청에 대한 토큰 비용 발생
서브 에이전트 컨텍스트: 각 에이전트는 작업할 충분한 컨텍스트가 필요하며, 종종 슈퍼바이저의 입력을 중복합니다.
에이전트 간 통신: 에이전트들이 협업한다면, 서로에게 이야기하는 과정에서 토큰을 소모합니다.
재시도 로직(Retry logic): 위임이 실패할 때마다 다시 비용을 지불해야 합니다.

저는 슈퍼바이저가 모든 라우팅 결정 시 동일한 500단어 분량의 입력을 재분석하느라 팀들이 한 주 만에 월별 OpenAI 예산을 모두 소진하는 것을 본 적이 있습니다.

관측 가능성(Observability)이야말로 진짜 문제입니다

'왜 슈퍼바이저가 이것을 잘못된 에이전트에게 보냈지?'를 디버깅하는 것은 정말 고통스럽습니다. 처음부터 결정론적이지 않았던 추론 과정을 재구성하기 위해 LLM 로그 속을 탐험해야 합니다.

하드코딩된 라우팅? grep으로 충분합니다. 슈퍼바이저 위임(Supervisor delegation)? 무엇이 일어났는지 이해하려면 구조화된 로깅, 트레이스 ID, 그리고 아마도 벡터 데이터베이스가 필요할 것입니다.

만약 이미 관측 가능성을 잘 구현하고 있지 않다면, 슈퍼바이저를 추가하는 것은 오히려 독이 될 수 있습니다.

저의 기본 권장 사항

하드코딩된 라우팅 (hardcoded routing)부터 시작하세요. 알려진 케이스를 처리하는 가장 단순한 if/elif/else 체인을 작성하세요. 알 수 없는 입력(unknown inputs)을 로그로 남기는 catch-all 로직을 추가하세요.

그 다음, 집중적으로 계측(instrument)을 수행하세요:

if match := extract_intent(task):
    logger.info(f"Routing {task_id} to {match.agent}", 
                intent=match.intent, confidence=match.score)
...

더 나은 규칙을 작성할 수 _없음_을 보여주는 한 달 치의 운영(prod) 데이터가 확보되었을 때, 그때 슈퍼바이저(supervisor) 도입을 검토하세요.

만약 여러분이 AI 자동화 및 소프트웨어 개발을 전문으로 하는 팀과 협업하고 있다면, 그들도 아마 똑같은 말을 할 것입니다. 똑똑해 보이는 문제가 아니라, 여러분이 실제로 겪고 있는 문제를 해결하세요.

요약 (TL;DR)

슈퍼바이저 위임 (Supervisor delegation) $\neq$ 항상 더 나음
도메인이 제한적이라면 먼저 하드코딩하세요
입력이 진정으로 예측 불가능할 때 동적 라우팅 (Dynamic routing)의 가치가 증명됩니다
관측 가능성 (Observability)과 비용 제어는 생각보다 어렵습니다
단순하게 시작하고, 모든 것을 계측하며, 데이터가 필요함을 증명할 때 업그레이드하세요

미래의 여러분(그리고 여러분의 토큰 예산)이 고마워할 것입니다.

에이전트 워크플로를 하드코딩하지 마세요 (혹은 하지 마세요): 개발자를 위한 Supervisor Delegation 가이드

요약

핵심 포인트