작성자 주: DeepSeek 슈퍼 에이전트 설계를 바탕으로 멀티 에이전트 시스템에서 router와 worker에 모델을 배분하는 방식을 살펴보고, 캐시 읽기 토큰이 아키텍처 비용에 미치는 영향을 설명해요.
멀티 에이전트 코딩 시스템을 구축할 때는 흔히 ‘총지휘자’에게 가장 강력한 모델을 배정하고, 실제 작업을 수행하는 에이전트에는 저렴한 모델을 쓰곤 해요. DeepSeek Harness 팀이 2026년 11월 공개한 슈퍼 에이전트 설계는 이와 반대예요. router에는 저렴한 모델을, worker에는 강력한 모델을 사용해요. 대화와 작업 배분을 맡는 router에는 경량 모델을, 실제로 코드를 작성하는 worker에는 가장 강력한 모델을 배정하는 방식이에요.
이 글은 단순히 뉴스를 전달하는 글이 아니에요. 이 아키텍처를 바탕으로 실제 모델 선택에 필요한 판단 기준을 살펴봐요. router와 worker에 각각 어떤 능력이 필요한지, 캐시 읽기 토큰은 어떻게 추산하는지, 언제 저렴한 모델을 선택해야 하는지 설명해요. 본문에서 인용한 테스트 데이터는 DeepSeek도 어디까지나 ‘참고용’ 결과라고 밝혔어요. 이 결과의 한계도 분명히 짚어볼게요.
핵심 가치: 이 글을 읽고 나면 자신의 멀티 에이전트 시스템에 맞춰 역할별 모델 배분안을 작성하고, 캐시 읽기 토큰 수를 바탕으로 대략적인 비용 규모를 추산할 수 있어요.
멀티 에이전트 모델 배분의 핵심
DeepSeek의 설계는 두 계층으로 나뉘어요. router는 장기간 유지되는 세션으로, 사람과 소통하고 작업을 배분하며 작업 간 관계를 추적해요. worker는 매번 작업 하나만 맡고 독립적인 클린 컨텍스트를 사용해요. 사람과 직접 대화하지 않고 router에게만 상태를 보고하죠. 이 역할 분담을 바탕으로 모델 배분의 기본 방향을 아래 표처럼 정할 수 있어요.
| 역할 | 핵심 책임 | 코드 작성 여부 | 추천 모델 수준 | 선택 이유 |
|---|---|---|---|---|
| router | 대화, 작업 배분, 작업 간 관계 추적 | 아니요. shell 권한을 주지 않아도 돼요 | 경량, 저비용, 고속 모델 | 작업은 단순하지만 호출이 잦아 지연 시간과 단가가 더 중요해요 |
| worker | 작업 하나를 맡아 코딩 완료 | 예 | 현재 사용할 수 있는 가장 강력한 코딩 모델 | 코드 품질이 결과물의 품질을 직접 결정해요 |
| 트리거 필터링 계층 | 그룹 채팅과 CI 알림의 노이즈 제거 | 아니요 | 1차는 일반 코드, 2차는 소형 모델 | 대부분의 이벤트는 모델까지 전달할 필요가 없어요 |
멀티 에이전트 모델 배분을 ‘뒤집어야’ 하는 이유
DeepSeek는 AI 보조 코딩의 병목이 모델 성능에서 사람의 주의력으로 옮겨갔다고 봐요. 보통 한 사람이 동시에 추적할 수 있는 활성 에이전트 세션은 3~5개예요. 그보다 많아지면 어느 세션이 승인을 기다리는지, 어느 세션이 막혔는지, 어떤 두 세션이 같은 PR을 동시에 수정하고 있는지 파악하기 어려워져요. 따라서 router의 가치는 ‘똑똑함’보다 ‘안정적인 작업 배분과 기록 관리’에 있어요. router는 작업을 세분화하지 않고 배분과 추적만 담당해요. 이는 흔히 쓰이는 ‘메인 에이전트가 작업을 단계별로 나누는’ 방식과 달라요.
router는 깊은 추론도, 코드 작성도 필요하지 않으므로 여기에 가장 비싼 모델을 쓰는 것은 낭비예요. 실제로 코드를 만드는 곳은 worker예요. 코드 품질이 결과물의 성패를 좌우하므로 강력한 모델을 위한 예산은 여기에 써야 해요. 이것이 바로 ‘모델 선택의 역전’이에요. 사용자에게 가까운 역할에는 가벼운 모델을, 코드에 가까운 역할에는 더 강력한 모델을 쓰는 거죠.
router와 worker에 각각 필요한 능력
역할별 책임을 구체적인 능력으로 나눠야 적합한 모델을 고를 수 있어요. 아래 체크리스트로 후보 모델을 평가해 보세요.
| 능력 항목 | router 요구사항 | worker 요구사항 | 선택 팁 |
|---|---|---|---|
| 지시 이행 및 분류 | 높음, 작업을 안정적으로 분류해야 함 | 중간 | router는 작업 분배 정확도를 우선 평가 |
| 긴 컨텍스트 및 이전 내용 추적 | 중간, ID 요약을 단계적으로 펼쳐 확인 | 높음, 많은 코드를 읽어야 함 | worker는 컨텍스트 윈도우와 코드 검색 능력 확인 |
| 코드 생성 품질 | 불필요 | 최우선 | worker 예산은 아끼지 않기 |
| 응답 지연 | 높은 우선순위, 의사결정이 빈번함 | 중간, 개별 작업은 다소 느려도 됨 | router는 Flash 계열의 빠른 모델 선택 |
| 단가 민감도 | 매우 높음, 캐시 읽기량이 많음 | 중간 | router의 단가가 총비용에 영향 |
| 도구 호출 | 적음, shell 권한이 없어도 됨 | 많음, 실행과 테스트가 필요함 | 권한 경계로 역할 제한 |
router에는 놓치기 쉬운 요구사항이 하나 더 있어요. 구조적으로 ‘직접 작업’할 수 없어야 한다는 점이에요. DeepSeek이 router에 shell 권한을 주지 않은 것도 직접 작업할 가능성을 없애기 위해서예요. 따라서 router 모델을 고를 때는 ‘모든 일을 할 줄 아는’ 모델보다 ‘작업 분배만 하는’ 모델을 선택해도 괜찮아요.
멀티 에이전트 모델 할당에서의 캐시 읽기 토큰 비용
router가 저렴하다고 해서 비용 문제가 해결되는 건 아니에요. 이 아키텍처에서 비용의 대부분은 캐시 읽기 토큰에서 발생해요. router는 장시간 유지되는 세션으로, 캐시에 저장된 컨텍스트를 반복해서 읽어요. 여러 worker도 병렬로 실행되면서 각자 대량의 컨텍스트를 읽고요. DeepSeek의 테스트 데이터에서 이 문제가 잘 드러나요.
| 테스트 지표 | 수치 | 설명 |
|---|---|---|
| 라운드당 메시지 수 | 약 300개 | 이 중 실제 작업 요청은 약 20개 |
| 슈퍼 에이전트 평균 완료 시간 | 12.4분 | 느린 쪽은 15.7분 |
| 단일 세션 기준 느린 쪽 소요 시간 | 29.5분 | 비교 기준 |
| router 의사결정 부하 | 분당 약 1회에서 약 40회로 증가 | 의사결정 한 건당 소요 시간은 6.4초에서 1.6초로 감소 |
| 캐시 읽기 토큰 | 2,320만 개 | pass-through 최적화 적용 |
| 최적화 미적용 시 캐시 읽기 | 3,180만 개 | worker가 스레드를 직접 구독하지 않는 경우 |
| 캐시 비용 | 약 7달러 | DeepSeek 자체 비혼잡 시간대 Flash 요금 기준 |
캐시 읽기량으로 멀티 에이전트 모델 할당 비용 추정하기
한 라운드의 실행 비용은 세 부분으로 나눠 계산할 수 있어요. 캐시 읽기 토큰에 캐시 읽기 단가를 곱하고, 캐시를 적중하지 않은 입력 토큰에 입력 단가를 곱한 금액과 출력 토큰에 출력 단가를 곱한 금액을 더하면 돼요. router-worker 아키텍처에서는 첫 번째 항목이 비용의 대부분을 차지하는 경우가 많아요. 따라서 모델을 선택할 때는 캐시 읽기 단가를 가장 주의해서 살펴봐야 해요.
보도된 수치로 역산하면, 캐시 읽기 토큰 2,320만 개에 약 7달러가 들었으므로 토큰 100만 개당 약 0.3달러 수준이에요. 이는 보도된 수치를 바탕으로 한 대략적인 추정치일 뿐 공식 요금이 아니에요. 실제 가격은 모델 제공업체의 최신 요금표를 확인해야 해요. 이 수치를 기준으로 후보 모델의 캐시 읽기 단가를 대입하면, 같은 작업량을 더 비싼 모델로 처리할 때 비용이 몇 배로 늘어나는지 빠르게 파악할 수 있어요.
pass-through 최적화 자체도 주목할 만해요. worker가 스레드를 구독하면 새 이벤트가 router를 거치지 않고 worker에 바로 전달돼요. 그 결과 캐시 읽기량이 3,180만 개에서 2,320만 개로 약 27% 줄었어요. 즉, 아키텍처 최적화도 저렴한 모델로 바꾸는 것처럼 비용을 직접 낮출 수 있어요.
원문 데이터에서 주의할 세 가지 한계
- 코딩 과정은 시뮬레이션됐어요: 테스트에서 ‘코드 작성’은 시간만 소비하는 도구로 대체됐어요. 코드 품질이 아니라 스케줄링 동작을 측정했으므로, 이 결과만으로 worker에 어떤 모델을 쓰는 게 가장 좋은지는 알 수 없어요.
- 데이터는 참고용이에요: DeepSeek은 이 수치가 엄격한 벤치마크가 아니라 대략적인 지표(indicative)라고 명시했어요.
- Sonnet 등급과의 가격 비교가 일관되지 않아요: 보도 요약에는 Sonnet 등급 기준 약 4.64달러로 추정된다고 되어 있지만, 본문에는 같은 사용량이라도 고가 등급에서는 “훨씬 더 비싸다”고 되어 있어요. 두 설명이 서로 모순되므로 DeepSeek 원문을 확인하기 전에는 이 구체적인 비교 수치를 인용하지 않는 것이 좋아요.
멀티 에이전트 모델 할당 빠른 시작
앞서 살펴본 로직을 자신의 시스템에 적용하려면 다음 단계를 따라 해보세요. 코드는 생략하고 설정 항목을 인라인으로 설명하므로, 사용 중인 프레임워크와 비교하기 편해요.
- 역할부터 나누고 모델을 선택하세요: 시스템에서 모델을 호출하는 모든 역할을 나열하세요. 최소한 router, worker, 트리거 필터링으로 구분하고, 각 역할이 코드를 작성하는지, 도구가 필요한지 적어보세요.
- 모델 이름을 설정 항목으로 만드세요: 각 역할에
router_model,worker_model,filter_model같은 파라미터를 따로 설정하세요. 모델 이름을 비즈니스 코드에 직접 넣지 않는 것이 좋아요. - 구조적으로 위임을 보장하세요: router에서 shell 같은 실행 도구를 제거하세요. DeepSeek 실험에서 단일 세션 에이전트는 중립적인 프롬프트로 5회 실행하는 동안 한 번도 위임하지 않았고, 가장 오래 걸린 실행은 30분에 가까웠어요. 프롬프트에 위임을 명시해도 5회 중 1회는 작업이 너무 작다고 판단해 직접 처리했어요.
- 먼저 필터링하세요: 트리거 이벤트는 일반 코드로 이벤트 출처와 허용 목록을 기준으로 노이즈를 걸러내세요. 남은 이벤트만 모델에 전달해 팀 규칙에 따라 판단하도록 하세요.
- 캐시 읽기량을 기록하세요: 매 실행마다 캐시 읽기, 캐시되지 않은 입력, 출력의 세 가지 Token 사용량을 기록하고, 앞서 소개한 공식으로 실행당 비용을 계산하세요.
- 모델을 바꿔 비교하세요: 작업 집합은 그대로 두고
router_model만 바꿔보세요. 분배 정확도, 지연 시간, 비용의 변화를 살펴본 뒤 더 낮은 등급의 모델로 바꿀지 결정하세요.
2단계와 6단계에서는 연동 방식이 실험 효율에 직접 영향을 줘요. router와 worker가 서로 다른 업체의 모델을 사용한다면, 각각 키와 SDK 설정을 관리해야 하므로 전환할 때마다 여러 곳을 수정해야 해요. APIYI apiyi.com 같은 통합 인터페이스 플랫폼을 이용하면 하나의 API 키와 동일한 OpenAI 호환 요청 형식을 사용하면서 model 파라미터만 바꿔 router와 worker에 서로 다른 업체의 모델을 할당할 수 있어요. 비교 실험에 드는 비용도 훨씬 줄일 수 있죠.
🚀 빠른 시작 팁: 프로토타입을 검증할 때는 APIYI apiyi.com에서 하나의 키로 router와 worker의 모델 파라미터를 각각 설정하고, 동일한 작업을 실행해 Token 사용량을 기록해보세요. DeepSeek의 Flash 등급 모델을 포함해 사용 가능한 모델은 플랫폼의 현재 모델 목록을 확인하세요.
멀티 에이전트에 저가 모델을 할당해야 할 때
저가 모델이 모든 역할에 적합한 것은 아니에요. 아래 기준을 참고해 각 역할에 더 저렴한 모델을 써도 될지 판단해 보세요.
| 상황 | 권장 사항 | 이유 | 이용 방법 |
|---|---|---|---|
| 역할이 작업 분배, 추적, 캐시된 컨텍스트 확인만 수행 | 저렴하고 빠른 모델 선택 | 작업이 단순해 단가와 지연 시간이 경험을 좌우함 | APIYI apiyi.com 또는 제공사 공식 API |
| 역할이 코드 생성과 수정을 담당 | 성능이 뛰어난 모델 선택 | 코드 품질이 결과물의 품질을 좌우함 | APIYI apiyi.com 또는 제공사 공식 API |
| 캐시 읽기량이 수천만 수준이고 매일 반복 실행 | 캐시 읽기 단가를 낮추는 데 우선순위 | 실행 횟수에 비례해 캐시 비용이 증가함 | 제공사 가격표를 기준으로 계산 |
| 가끔 수행하는 가벼운 단일 작업 | 사용량 기반 과금 선택 | 사용량이 적어 아키텍처를 복잡하게 만들 가치가 없음 | 사용량 기반 과금 채널 |
| 고빈도·토큰 집약적인 자동화 작업 | 월정액 또는 높은 한도 요금제 검토 | 실행당 한계 비용이 청구서에 별도로 반영되지 않음 | 구체적인 구독 약관에 따라 다름 |
마지막 행의 참고 사례가 있어요. 같은 시기에 보도된 Claude Code Pass는 월 9.99달러로, Kimi K3.1 Pro, GLM 5.3, DeepSeek V4.1 Flash 같은 오픈 모델에 약 2~5배의 속도 제한을 제공하며 5시간·주간·월간 사용량 상한을 둡니다. 해당 보도에서는 라우팅 결정이나 캐시된 컨텍스트 확인 단계에서는 빠르고 저렴한 모델이 비용뿐 아니라 기술적으로도 더 적합하다고 설명해요. 다만 이런 요금제는 사용 가능한 모델이 패키지에 포함된 모델로 제한되므로, 워커가 그 밖의 모델에 의존한다면 별도의 접속 경로가 필요해요.
멀티 에이전트 모델 배분의 위험과 한계
모델 배분은 비용과 역할 분담 문제를 해결할 뿐, 아키텍처 자체에 남아 있는 난제까지 해결해 주지는 않아요. DeepSeek은 아직 해결하지 못한 두 가지 문제를 인정했어요. 첫째는 장기 기억이에요. 시스템을 몇 달 동안 운영하면서 컨텍스트 윈도우를 초과하지 않고 관련 기록을 유지하기는 여전히 어려워요. 둘째는 프롬프트 인젝션이에요. 그룹 채팅이나 PR 댓글처럼 외부 이벤트를 읽는 에이전트는 누구나 조작당할 수 있어요. router와 worker가 공유 클라우드 루프로 연결되어 있기 때문에, 이론적으로는 침해된 이벤트 소스 하나가 시스템이 접촉하는 모든 머신에 지시를 퍼뜨릴 수도 있어요.
이는 모델 배분에도 직접적인 영향을 줘요. router에 저렴한 모델을 쓴다고 해서 보안을 느슨하게 해도 되는 건 아니에요. 오히려 router는 외부 이벤트를 가장 먼저 접하는 역할이에요. DeepSeek은 내부 배포 시 에이전트의 자율 행동을 즉시 실행하지 않고, 먼저 “이렇게 행동했을 것”이라는 로그만 남기는 모드로 운영했어요. 예를 들어 “조용히 재현하고 수정하기” 전략에서는 누군가 버그를 보고하면 에이전트가 백그라운드에서 재현을 시도해요. 재현에 성공하고 수정까지 마치면 대화가 진행되는 동안 PR을 제출하고, 재현하지 못하면 아무것도 보내지 않아요. 새 시스템을 도입할 때는 먼저 로그를 관찰한 뒤 점진적으로 권한을 부여하는 편이 더 안전해요.
또한 프로토타입 코드인 DSH Super Agent는 GitHub에 정식 제품이 아닌 연구용 코드라고 명시되어 있어요. 설계 아이디어를 참고하는 것은 좋지만, 프로덕션 환경에 그대로 배포하는 것은 권장하지 않아요.
자주 묻는 질문 FAQ
Q1: 멀티 에이전트 시스템에서 ‘모델 선택의 역전’이란 무엇인가요?
router에는 가볍고 저렴한 모델을, worker에는 가장 강력한 모델을 쓰는 방식이에요. router는 대화, 작업 할당, 추적만 담당하고 코드는 작성하지 않아요. 실제 코딩을 맡는 worker에 고성능 모델 예산을 쓰는 거죠.
Q2: router-worker 아키텍처는 ‘메인 에이전트가 작업을 분해하는’ 방식과 어떻게 다른가요?
메인 에이전트 방식에서는 메인 에이전트가 작업을 단계별로 나눠야 하므로 높은 추론 능력이 필요해요. DeepSeek의 router는 작업을 분해하지 않고 할당과 추적만 하므로 더 가벼운 모델을 쓸 수 있어요. 대신 worker가 전체 작업을 독립적으로 완수할 수 있어야 해요.
Q3: 이 설계는 언제 공개됐나요? DSH Super Agent를 바로 사용할 수 있나요?
관련 보도는 2026년 11월 3일에 나왔어요. DSH Super Agent는 설계에 관한 글과 함께 GitHub에 공개된 연구용 프로토타입이에요. 공식적으로 지원되는 제품이 아니며, 아키텍처를 이해하는 용도로만 적합하다고 명시되어 있어요.
Q4: 프롬프트만으로 단일 에이전트가 작업을 위임하도록 할 수 있나요?
DeepSeek의 테스트에 따르면 신뢰하기 어려워요. 중립적인 프롬프트로 5번 실행했을 때 위임은 한 번도 없었고, 위임을 강조한 프롬프트에서도 한 번은 위임하지 않았어요. 안정적인 위임을 위해서는 더 긴 프롬프트보다 세션 분리나 실행 도구 제거 같은 구조적 격리가 필요해요.
Q5: 하나의 시스템에서 router와 worker에 서로 다른 공급업체의 모델을 편리하게 설정하려면 어떻게 하나요?
핵심은 모델 이름을 역할별 설정 항목으로 만들고 접속 방식을 통일하는 거예요.
1. APIYI apiyi.com에 가입하고 API 키를 발급받아요
2. 시스템 설정에서 router와 worker의 `model` 매개변수를 각각 지정해요
3. 요청 형식은 그대로 유지하고 모델 이름만 바꿔 비교 실험을 진행해요
이렇게 하면 공급업체마다 별도의 SDK 설정을 유지할 필요가 없어요. 사용 가능한 모델은 플랫폼의 현재 목록을 확인하세요.
Q6: 원문의 비용 데이터를 예산 산정에 바로 사용해도 되나요?
그대로 적용하는 것은 권장하지 않아요. 코딩 과정은 시뮬레이션됐고, 데이터는 참고용 결과일 뿐이에요. Sonnet급 모델과의 가격 비교 설명도 앞뒤가 일치하지 않아요. 직접 구성한 작업 세트로 캐시 읽기량을 측정한 뒤 현재 단가를 곱하는 편이 좋아요. APIYI apiyi.com에서 작업은 그대로 두고 모델을 바꿔 각각 실행하면 자신의 환경에 맞는 데이터를 얻을 수 있어요.
Q7: 이 아키텍처에는 어떤 알려진 한계가 있나요?
크게 세 가지예요. 장시간 실행 시 기억 능력이 저하되고, 외부 이벤트를 읽을 때 프롬프트 인젝션 위험이 있으며, 캐시 읽기 토큰 양이 많아 고가 모델을 쓰면 비용이 크게 늘어나요. 또한 router에 어떤 모델을 사용했을 때 효과적인지에 관한 데이터가 부족하므로 직접 테스트해야 해요.
멀티 에이전트 모델 배분 핵심 요점 Key Takeaways
- 모델 선택의 역전: router에는 가볍고 저렴한 모델을, 코드를 작성하는 worker에는 강력한 모델을 사용해요.
- 병목은 주의력: 사람은 보통 3~5개 세션만 동시에 살펴볼 수 있어요. router가 소통을 한데 모아 관리해요.
- 위임은 구조로 보장: 프롬프트를 수정하는 것보다 router에서 실행 도구를 제거하는 편이 훨씬 확실해요.
- 비용의 핵심은 캐시: 한 차례 테스트에서 캐시 읽기가 2,320만 토큰에 달했어요. 캐시 읽기 단가가 가장 중요해요.
- 아키텍처 최적화도 비용 절감에 도움: pass-through 직통 방식으로 캐시 읽기를 약 27% 줄였어요.
- 데이터 인용에 주의: 코딩은 시뮬레이션으로 진행됐으므로 결과는 참고용으로만 활용하고, 가격 비교는 별도로 확인해야 해요.
- 통합 인터페이스로 실험: APIYI apiyi.com에서는
model파라미터만 바꿔 다양한 모델 배분 방식을 비교할 수 있어요.
정리
router에는 저렴한 모델을, worker에는 강력한 모델을 사용하는 멀티 에이전트 모델 배분 방식의 핵심은 다음과 같아요.
- 역할에 따라 모델 선택: 코드를 작성하지 않고 작업 분배와 추적만 하는 역할에는 저렴하고 빠른 모델을, 코딩 역할에는 강력한 모델을 사용해요.
- 캐시 기준으로 비용 계산: 캐시 읽기 토큰이 이 아키텍처의 주요 비용이므로, 모델을 선택할 때 캐시 읽기 단가부터 비교해요.
- 직접 측정해 결정: 원문의 데이터는 방향을 참고하는 데만 쓰고, 최종 결정은 직접 구성한 작업 세트의 비용과 성능을 측정한 뒤 내려요.
먼저 작은 작업 세트로 router-worker 프로토타입을 만들고, 모델명을 역할별 설정 파라미터로 지정해 보세요. 그런 다음 router 모델을 하나씩 바꾸면서 작업 분배 정확도와 비용 변화를 살펴보세요. APIYI apiyi.com에서 하나의 키로 여러 모델에 접속해 비교하면, 직접 얻은 데이터를 바탕으로 모델을 선택할 수 있어요.
📚 참고 자료
- DeepSeek’s Super Agent Harness: Fixing the Attention Bottleneck in AI Coding: DeepSeek 슈퍼 에이전트 설계 해설
- 링크:
mindstudio.ai/blog/deepseek-super-agent-harness-design -
설명: 라우터-워커 아키텍처, 위임 실험, 캐시 토큰 데이터와 미해결 과제를 다뤄요.
-
Claude Code Pass Pricing: What’s in the $9.99/Month Plan: 높은 사용 한도를 제공하는 월정액 요금제 해설
- 링크:
mindstudio.ai/blog/claude-code-pass-pricing - 설명: 멀티 에이전트와 토큰 집약적인 워크플로에서 종량제와 월정액 요금제의 선택 기준을 살펴봐요.
작성자: APIYI 기술팀
기술 교류: 멀티 에이전트 모델 배분 방안을 논의하고 싶다면 APIYI apiyi.com 홈페이지에서 문의해 주세요. 더 많은 연동 자료는 docs.apiyi.com 문서 센터에서 확인할 수 있어요.
