Router + Worker 2계층 아키텍처 분석: DeepSeek이 AI 에이전트에 세션이 하나만 있어서는 안 된다고 보는 이유와 4가지 핵심 설계

작성자 주: DeepSeek Super-agent의 Router + Worker 이중 계층 아키텍처를 살펴보고, 전역 조율과 독립적인 실행을 어떻게 분리하는지, 개발자가 자신의 Agent 시스템에 비슷한 설계를 도입할 만한 시점은 언제인지 설명해요.

Coding Agent 창을 네다섯 개 동시에 띄워 놓으면 현실적인 문제가 생겨요. 한 창에서는 로그인 버그를 수정하고, 다른 창에서는 데이터베이스 마이그레이션을 검토하고, 또 다른 창에서는 CI 결과를 기다리고 있죠. 각 창에서 무엇을 하는지, 어느 쪽이 답변을 기다리는지, 서로 관련된 작업은 무엇인지 일일이 기억해야 해요. 모델은 점점 더 독립적으로 일할 수 있게 됐지만, 이 세션들을 관리하는 부담은 여전히 사람에게 남아 있어요.

2026년 10월 31일, DeepSeek Harness 팀은 기술 글 《Super-agent 설계 탐구: 더 자율적인 Agent 시스템을 향해》를 발표하고, 연구용 프로토타입 dsh-superagent-prototype을 MIT 라이선스로 오픈소스 공개했어요. 가장 핵심적인 설계는 Router + Worker 이중 계층 아키텍처예요. 상시 실행되는 Router 하나가 전역 조율을 맡고, 서로 격리된 여러 Worker가 구체적인 작업을 실행하죠.

이건 단순히 “AI 하나가 더 많은 일을 동시에 하게 만드는” 요령이 아니에요. Super-agent의 핵심은 시스템 아키텍처를 통해 전역 조율과 독립적인 실행을 분리함으로써, 사람이 여러 세션을 관리하는 부담을 줄이는 데 있어요. 이 글에서는 ‘문제—메커니즘—근거—엔지니어링 가치’ 순서로 설계 배경과 핵심 메커니즘, 공식 실험 데이터, 그리고 API 호출과 비용 관리에 주는 시사점을 살펴볼게요.

핵심 가치: 이 글을 읽고 나면 Router + Worker 이중 계층 아키텍처가 실제로 해결하는 문제가 무엇인지 이해하고, 자신의 Agent 시스템에 비슷한 설계를 언제 도입할 만한지 판단할 수 있어요.

Router + Worker 핵심 정보 한눈에 보기

아키텍처를 살펴보기 전에 이번 발표의 기본 정보부터 짚어볼게요. 중요한 점은 DeepSeek가 오픈소스로 공개한 것이 정식 상용 제품이나 새로운 기반 모델이 아니라 연구용 프로토타입이라는 거예요.

DeepSeek는 Super-agent의 목표로 네 가지 특성을 제시했어요. Continuous(채널을 넘나드는 컨텍스트 연속성), Productive(여러 작업의 병렬 처리), Proactive(허용된 범위에서 이벤트에 능동적으로 대응), Persistent(지속적으로 실행되고 일부 오류에서 복구)예요. 이는 설계 목표이며, 오픈소스 프로토타입에서 모두 구현됐다는 뜻은 아니에요.

AI Agent에 Session이 하나만 있어서는 안 되는 이유

DeepSeek 팀은 AI 코딩 도구의 병목이 ‘모델 능력’에서 ‘사람의 주의력’으로 옮겨가고 있다고 봐요. 팀의 일상적인 관찰에 따르면 한 사람이 효과적으로 관리할 수 있는 활성 Agent Session은 보통 3~5개 정도예요. 공개된 대규모 사용자 통계가 아닌 팀의 경험에 근거한 판단이지만, 많은 개발자가 실제로 느끼는 상황을 잘 보여줘요.

단일 Session과 다중 Session의 딜레마

흔히 쓰이는 두 가지 방식에는 각각 뚜렷한 한계가 있어요. Router + Worker는 ‘전체 컨텍스트의 연속성’과 ‘백그라운드 병렬 처리 능력’을 함께 확보하기 위해 제안됐어요.

단일 Session의 문제는 ‘막힘’이고, 다중 Session의 문제는 ‘분산’이에요. 전자는 하나의 컨텍스트 윈도우가 모든 작업의 중간 단계를 감당해야 하고, 후자는 조율 부담을 전부 사람에게 넘겨요. DeepSeek는 시스템 차원에서 ‘전체 상황을 기억하는’ 역할을 따로 두어, 실행 담당자가 작업에 집중할 수 있도록 했어요.

Router + Worker 이중 계층 아키텍처의 작동 방식

Router: 조율만 담당하는 전역 스케줄링 계층

Router는 장기 실행되는 논리 계층이에요. 현재 공식 아키텍처 탐색에서는 주로 상시 실행되는 LLM Session으로 구현하지만, 개념적으로 반드시 하나의 모델 세션과 일치할 필요는 없어요. Router는 직접 작업하기보다 관리에 집중해요.

• 사용자 메시지와 GitHub, IM, CI 등의 외부 이벤트를 통합해서 받아요.
• 전체 작업의 연관 관계를 관리하고 새 작업을 만들어야 하는지 판단해요.
• 권한을 확인하고 Worker에 작업을 할당하며, 작업 간 조율을 처리해요.
• 사람에게 전달할 정보를 취합하고, 필요하면 이전 작업의 컨텍스트를 불러와요.

중요한 점은 공식 설명에 따르면 Router에 Bash 도구가 없어도 된다는 거예요. Router가 복잡한 프로그래밍을 직접 수행하지 않으면, 오랜 시간이 걸리는 도구 호출에 막히는 상황을 피할 수 있어요. 또한 Router의 작업에는 가장 강력한 추론 모델이 필요하지 않은 경우가 많아요. 가벼운 모델로도 상호작용과 작업 분배를 처리할 수 있어, 역할마다 다른 모델을 구성할 기술적 근거가 돼요.

Worker: 격리된 환경에서 실행하는 작업 계층

Worker는 구체적인 작업을 담당해요. 공개 프로토타입에서는 Ticket 하나에 Executor Session 하나가 대응하며, 각 Ticket에는 독립적인 작업 디렉터리가 있어요. Worker는 허용된 범위 안에서 코드를 수정하고 테스트를 실행하며 후속 피드백을 처리한 뒤 Report를 작성해요. 사람의 결정이 필요하면 Attention 상태로 설정하고, 결과는 원래 채널(예: GitHub PR)을 통해 전달해요.

Worker마다 모델 컨텍스트가 독립되어 있어 여러 작업의 중간 단계가 하나의 윈도우에 뒤섞이는 문제를 해결할 수 있어요. 다만 독립된 Session과 디렉터리가 강력한 보안 격리를 뜻하는 것은 아니에요. 공식 배포 문서에 따르면 Worker는 기본적으로 운영자의 운영체제 사용자 권한으로 명령을 실행해요.

GitHub Issue가 Router + Worker 흐름을 거치는 과정

오픈소스 구현의 Domain Model에 따르면 작업 흐름은 Source → Trigger → Eval → Decision → Ticket → Assignment → Executor → Report로 정리할 수 있어요. “권한이 있는 사용자가 GitHub Issue에서 버그 수정을 요청하는 경우”를 예로 들어볼게요.

1. GitHub Source가 Issue 댓글을 받고 Trigger를 생성해요.
2. 시스템이 먼저 결정적 규칙으로 권한을 필터링한 다음, 모델이 작업 수락 규칙에 부합하는지 판단해요.
3. Router가 작업을 수락하고 Ticket을 생성해요. Ticket에는 작업 범위와 권한(Mandate)이 기록돼요.
4. 시스템이 Ticket에 대한 Assignment를 만들고 해당 Worker에 할당해요.
5. Executor가 독립된 디렉터리와 Session에서 수정을 수행해요.
6. Worker가 진행 상황을 보고하거나 결과를 제출하고 PR을 생성해요.
7. 시스템이 원래 Issue나 PR 스레드를 통해 결과를 사용자에게 전달해요.

이후 사용자가 해당 PR에 수정 의견을 남기면 새 메시지가 원래 작업에 자동으로 연결될 수 있어요. 사용자가 “이 작업을 처리하던 Agent 세션이 무엇이었지?” 하고 다시 찾아볼 필요가 없어요. 이중 계층 아키텍처가 사람의 관리 부담을 줄여주는 구체적인 사례예요.

Router + Worker의 4가지 핵심 설계

2계층 아키텍처는 뼈대에 불과해요. 실제로 작동하게 만드는 건 구체적인 문제를 해결하기 위한 엔지니어링 설계예요.

Thread 구독 직접 전달: Router의 반복 분배 줄이기

Worker A가 특정 PR을 담당한다고 가정해 볼게요. 해당 PR의 후속 댓글과 CI 결과는 Thread 담당 관계에 따라 Worker A에게 직접 전달할 수 있어요. Router가 관련 메시지마다 다시 판단할 필요가 없죠. 빈도가 높지만 가치가 낮은 결정을 중앙 노드에서 덜어내는 대표적인 설계예요.

다만 구독 메시지의 직접 전달에는 명확한 권한 경계가 있어요. 공식 권한 부여 문서에 따르면 구독 메시지는 컨텍스트를 제공할 수 있지만, 기존 Ticket의 Mandate를 확대할 수는 없어요. 후속 댓글이 권한 범위 밖의 새 작업을 요청하면 Worker는 이를 시스템에 다시 넘겨 평가받아야 해요. 외부 댓글에 담긴 권한 밖의 지시를 막는 데 중요한 원칙이에요.

Router 배치 처리: 갑작스러운 이벤트에 대응하기

Router가 한 차례 추론을 진행하는 동안 새로 도착한 Trigger는 일단 쌓아 두었다가, 다음 추론에서 하나의 배치로 분석해요. 즉, ‘메시지마다 한 번씩 모델 호출’하는 대신 ‘추론 한 번으로 여러 메시지 처리’로 바꾸는 거예요. 이벤트가 몰릴 때 결정 하나당 추론 비용을 크게 줄일 수 있어요.

Inline & Spill과 연쇄 회수: 컨텍스트를 캐시처럼 활용하기

DeepSeek는 컨텍스트 윈도우를 일종의 캐시로 봐요. Inline은 현재 작업의 최신 댓글, 관련 코드 행과 필요한 주변 코드처럼 곧 사용할 가능성이 높은 정보를 윈도우에 직접 넣는 방식이에요. Spill은 긴 과거 논의처럼 자주 쓰지 않거나 너무 긴 내용을 윈도우 밖에 두고, 요약과 연결 ID, 읽기 경로만 남기는 방식이에요. 관련 없는 과거 메시지는 매번 주입하지 않아도 돼요.

여기서 더 나아간 방식이 Chain of Recall(연쇄 회수)이에요. 모델이 Trigger → Thread → Ticket → Worker의 객체 연결 관계를 따라 필요할 때 과거 정보를 단계적으로 찾아요. ‘매번 전체 기록을 넣는’ 방식보다 컨텍스트를 절약할 수 있고, 데이터베이스에서 인덱스로 조회하는 방식과도 비슷해요. 다만 공식 자료에서도 몇 달 이상에 걸친 장기 기억은 여전히 해결되지 않은 문제라고 인정해요.

Router + Worker 실험 데이터 해석

DeepSeek은 합성 워크로드로 초기 실험을 진행했어요. 시뮬레이션 한 번에 약 300개의 메시지가 발생했는데, 이 중 약 20개는 작업 요청이고 나머지는 잡담, 후속 피드백, 취소 요청, CI 메시지였어요. 각 방식은 5회씩 실행했어요. 프로그래밍 작업은 시간이 걸리는 모의 도구로 대체했기 때문에, 이 데이터는 코드 생성 품질이 아니라 스케줄링 시스템의 성능을 측정한 결과예요.

엔드투엔드 스케줄링 비교

중립 프롬프트를 사용한 단일 세션 방식과 비교하면 Super-agent의 P50 완료 시간은 약 39%, P95는 약 47% 줄었어요. 우선 위임을 적용한 단일 세션 방식과 비교하면 P50의 차이는 크지 않지만, P95로 본 지연의 롱테일은 훨씬 짧아요. 즉, 2계층 아키텍처의 가장 큰 이점은 가장 느린 작업들이 지나치게 오래 걸리지 않도록 하는 것이에요.

대가도 분명해요. Super-agent의 캐시 읽기량은 중립 프롬프트를 사용한 단일 세션 방식의 약 3.8배예요. 더 많은 병렬 세션과 추론 리소스를 사용해 완료 시간을 단축하고 안정성을 높인 셈이죠. 하지만 총비용도 3.8배로 늘어난다는 뜻은 아니에요. 실제 비용은 모델 단가, 캐시 적중, 일반 입력 및 출력 토큰, Router와 Worker의 모델 선택, 도구 호출에도 영향을 받아요. 실제 작업 요청의 평균 API 비용은 아직 공식적으로 공개되지 않았어요.

구독 이벤트 직접 전달을 제거한 소거 실험도 살펴볼 만해요. 이 기능을 제거하자 Router가 처리해야 하는 의사결정 수는 약 30%, 캐시 읽기 토큰은 약 37% 늘었지만 완료 시간은 거의 변하지 않았어요. 이 테스트에서 구독 이벤트 직접 전달은 속도를 직접 높이기보다 주로 Router의 모델 호출과 컨텍스트 오버헤드를 줄이는 역할을 했다는 뜻이에요.

Router 배치 처리 부하 테스트

이 테스트에서는 Router에 실제 모델을, Worker에는 모의 모델을 사용했어요.

이벤트 밀도가 높아지자 요청 한 건에 걸리는 시간은 늘었지만, 의사결정 하나에 할당되는 추론 시간은 오히려 줄었어요. 배치 처리로 유효 처리량이 높아졌다는 뜻이에요. 공식 결론은 신중해요. 현재 팀 규모에서는 Router 하나로 당분간 충분하지만, Router 하나가 메시지를 무한정 처리할 수 있다는 의미는 아니에요.

Router + Worker가 개발자에게 미치는 영향

모델 계층화: Router는 경량 모델, Worker는 작업에 맞는 모델 선택

2계층 아키텍처가 주는 가장 직접적인 교훈은 모든 역할에 같은 모델을 쓸 필요가 없다는 점이에요. Router는 주로 분류, 분배, 요약을 담당하므로 빠르고 저렴한 모델이 적합해요. Worker는 작업의 복잡도에 따라 추론 능력이 더 뛰어난 모델을 선택하면 돼요. 프로토타입에서도 Router와 Worker의 모델 제공업체와 모델을 각각 지정할 수 있어요.

아래는 하나의 OpenAI 호환 인터페이스를 통해 Router가 작업 분배 여부를 판단하는 간단한 예시예요.

import openai

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"  # APIYI 통합 인터페이스, 하나의 키로 여러 모델 전환
)

ROUTER_MODEL = "your-fast-cheap-model"   # 콘솔에서 사용할 수 있는 경량 모델 이름으로 변경

resp = client.chat.completions.create(
    model=ROUTER_MODEL,
    messages=[{"role": "user", "content": "判断这条 Issue 评论是否需要新建 Ticket:修复登录页 500 错误"}]
)
print(resp.choices[0].message.content)

import json
import openai
from typing import Dict

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"
)

# 역할별 모델 계층화: 모델 이름을 실제 사용할 수 있는 모델로 변경하세요
ROLE_MODELS: Dict[str, str] = {
    "router": "your-fast-cheap-model",
    "worker_simple": "your-mid-tier-model",
    "worker_complex": "your-strong-reasoning-model",
}

usage_log = []  # Ticket별 토큰 사용량 기록

def call(role: str, ticket_id: str, prompt: str) -> str:
    resp = client.chat.completions.create(
        model=ROLE_MODELS[role],
        messages=[{"role": "user", "content": prompt}],
    )
    u = resp.usage
    usage_log.append({
        "ticket": ticket_id, "role": role,
        "input": u.prompt_tokens, "output": u.completion_tokens,
    })
    return resp.choices[0].message.content

def router_dispatch(ticket_id: str, event: str) -> str:
    prompt = (
        "你是任务调度器,只做分类,不执行任务。"
        "输出 JSON:{\"accept\": bool, \"complexity\": \"simple\"|\"complex\"}\n"
        f"事件:{event}"
    )
    decision = json.loads(call("router", ticket_id, prompt))
    if not decision["accept"]:
        return "ignored"
    role = "worker_complex" if decision["complexity"] == "complex" else "worker_simple"
    return call(role, ticket_id, f"在授权范围内处理任务:{event}")

print(router_dispatch("T-001", "CI 失败:单元测试 test_login 超时"))
print(usage_log)

🎯 기술 팁: 계층형 에이전트를 구축할 때는 APIYI apiyi.com의 API 키 하나로 경량 모델과 고성능 추론 모델을 Router와 Worker에 각각 적용해 성능을 먼저 비교해 보세요. 그 결과를 바탕으로 최종 구성을 결정하면 모든 역할에 가장 비싼 모델을 사용하는 일을 피할 수 있어요.

비용 관리: 전체 청구서가 아닌 Ticket별로 추적하기

공식 실험에 따르면 이중 계층 아키텍처는 추론 리소스를 더 많이 소비하므로 비용을 세밀하게 관리해야 해요. 실용적인 방법은 다음과 같아요.

• Ticket별 Token 기록: Router의 의사결정 비용과 Worker의 실행 비용을 구분해 어떤 유형의 작업이 가장 비싼지 파악해요.
• 비용 유형 구분: 모델 비용, 도구 비용(검색, 웹페이지 가져오기 등), 실행 환경 비용을 따로 집계해요.
• 캐시 적중률 확인: Super-agent의 Token 사용량은 대부분 캐시 읽기에서 발생해요. 캐시 적중과 미적중의 단가 차이가 클 수 있는데, DeepSeek 공식 가격을 기준으로 수십 배 차이가 나요.
• 불필요한 의사결정 줄이기: 구독 이벤트를 담당 Worker에 직접 전달해 Router의 반복적인 작업 할당을 줄여요.

💰 비용 최적화: 여러 Worker를 병렬로 실행하면 호출량이 몇 배로 늘어날 수 있어요. APIYI apiyi.com에서 여러 모델을 사용량 기반으로 호출하면 하나의 청구서에서 역할과 모델별 실제 비용을 비교할 수 있어 계층별 비용 최적화가 편리해요.

Router + Worker는 언제 도입할 만할까요?

이중 계층 아키텍처는 복잡할수록 좋은 것이 아니에요. 다음 기준을 참고해 보세요.

• 도입이 적합한 경우: 서로 독립적인 작업이 여러 개 있고(예: Ticket A는 버그 수정, Ticket B는 마이그레이션 검토, Ticket C는 CI 처리), 이벤트가 여러 채널에서 발생해 지속적인 대응이 필요한 경우예요.
• 도입을 미뤄도 되는 경우: 작업 수가 적거나 작업 간 의존성이 높을 때, 또는 하나의 복잡한 작업을 나눠 처리할 때는 단일 Agent나 기존 Agent Team이 리소스를 덜 사용해요.
• 인프라를 먼저 갖춰야 하는 경우: 권한 격리, 파일 수정 충돌 처리, 작업별 비용 기록이 준비되지 않았다면 무턱대고 병렬 처리할 때 오히려 위험이 커져요.

Router + Worker와 일반적인 Agent Team은 중점을 두는 부분도 달라요. 일반적인 Agent Team은 복잡한 작업 하나를 조사, 코딩, 테스트 등의 역할로 나누는 경우가 많아요. 반면 Super-agent의 Router는 각 작업의 기술적 세부사항보다 여러 독립적인 작업 간의 조율에 집중해요. 공식 설명에 따르면 일반 Agent Team에서도 메인 세션이 통합 인터페이스와 작업 간 할당만 담당하면 비슷한 구조를 만들 수 있어요. 이중 계층 아키텍처는 DeepSeek만의 개념이 아니에요.

Router + Worker 아키텍처의 한계와 프로토타입 범위

이런 아키텍처를 분석할 때 가장 흔한 실수는 설계 문서의 전체 청사진을 오픈소스 프로토타입에 이미 구현된 기능으로 받아들이는 거예요. 자료를 기준으로 엄격히 구분하면 다음과 같아요.

• 프로토타입에서 지원하는 기능: 단일 GitHub 저장소 모니터링, 선택적인 Feishu 연동, 티켓 관리, 독립적인 Worker 세션과 디렉터리, PR 생성, 관리 대시보드를 통한 수동 처리 대기 작업 표시, 후속 메시지에 따른 작업 재개
• 설계에는 있지만 완전한 구현이 확인되지 않은 기능: 여러 저장소 자동 관리, 프로덕션 수준의 클라우드 상시 운영과 기기 간 환경 지원, 완전히 독립적인 Watchdog의 자율 복구. 비동기 ReAct Loop는 Harness에 구현되어 있지만 기본적으로 활성화되어 있지는 않아요.
• 능동적 작업의 한계: 추론한 작업은 기본적으로 observe 모드를 사용해 기록만 하고 실행하지 않아요. PR 자동 병합도 기본적으로 꺼져 있어요.

아키텍처 차원에서도 공식적으로 인정한 난제가 몇 가지 있어요. 첫째는 단일 Router의 확장성이에요. 현재 팀 규모에서는 충분하다고만 밝혔을 뿐, 더 큰 규모에서 어떻게 샤딩할지는 아직 답이 없어요. 둘째는 장기 기억이에요. Inline & Spill과 연쇄적 기억 검색으로 중단기 컨텍스트는 처리하지만, 몇 달에 걸친 기억은 여전히 해결되지 않았어요. 셋째는 권한 경계예요. Router와 Worker의 기본 설정은 danger-full-access 모드로 실행되며, 기본적으로 운영자의 시스템 사용자 권한을 사용해요. 공식적으로는 별도의 시스템 사용자를 쓰도록 권장해요. 외부 댓글을 통한 프롬프트 인젝션과 자격 증명 관리도 해결해야 할 문제로 꼽혀 있어요. 커뮤니티에서는 특정 commit을 대상으로 한 제3자의 소스 코드 감사 보고서도 나왔지만, 전체 공격 과정이 독립적으로 재현되지는 않아 잠재적 위험으로만 봐야 해요.

커뮤니티의 실제 사용 결과도 아직은 프로토타입이라는 점을 보여줘요. SETUP.md를 따라 저장소를 새로 복제한 뒤 Issue에서 PR까지 전체 과정을 성공적으로 실행한 사용자가 있었어요. 동시에 Node.js 24 프로세스 인식 문제, GitHub 알림 지연으로 인한 메시지 누락, 중국어 시스템 언어 설정으로 인한 테스트 단언 실패 등도 보고됐어요.

자주 묻는 질문 FAQ

Router + Worker 핵심 요점 Key Takeaways

• 핵심 개념: Super-agent는 모델을 둘러싼 시스템 아키텍처이며, 공개된 것은 상용 제품이 아닌 연구용 프로토타입이에요.
• 문제의 본질: 병목이 모델 성능에서 사람의 주의력으로 옮겨가고 있어요. 세션이 하나면 작업이 밀리고, 여러 개면 관리가 분산돼요.
• 역할 분리: Router는 전체 작업 조율만 담당하며 Bash조차 제공받지 않을 수 있어요. Worker는 격리된 세션에서 독립적으로 작업해요.
• 핵심 메커니즘: 구독을 통한 직접 전달로 Router의 의사결정 부담을 줄이고, 배치 처리로 추론 비용을 분산하며, Inline & Spill로 컨텍스트를 캐시처럼 활용해요.
• 실험 데이터의 범위: 스케줄링 실험에서는 오래 걸리는 작업의 완료 시간이 줄었지만, 토큰 소비는 늘었어요. 이 결과가 코딩 능력을 보여주는 것은 아니에요.
• 시작하는 방법: APIYI apiyi.com의 통합 인터페이스로 역할별 모델을 설정하고, Ticket 단위로 비용을 관리할 수 있어요.

정리

DeepSeek은 Router + Worker로 “AI Agent에 세션 하나만으로는 부족한 이유”에 답했어요.

1. 아키텍처의 가치: 전체 조율과 독립 실행을 분리해 사람이 아닌 시스템이 작업 간 관계를 기억하도록 해요.
2. 엔지니어링 설계: 구독을 통한 직접 전달, 배치 처리, Inline & Spill, 체인형 검색은 각각 중앙 부하, 급증하는 작업 처리량, 컨텍스트 용량, 과거 정보 검색 문제에 대응해요.
3. 균형 잡힌 시각: 실험이 보여준 것은 스케줄링 효율과 리소스 비용 사이의 트레이드오프예요. 단일 Router의 확장성, 장기 기억, 권한 격리는 여전히 해결해야 할 과제예요.

시스템이 여러 독립적인 작업을 동시에 처리해야 한다면 이중 계층 아키텍처를 참고할 만해요. 작업이 적고 한곳에 집중돼 있다면 단일 Agent가 여전히 더 경제적인 선택이에요. 어떤 구조를 쓰든 모델을 역할별로 나누고 작업별 비용을 집계하는 것이 비용 관리의 핵심이에요.

APIYI apiyi.com을 통해 Router와 Worker 역할에서 다양한 모델의 성능을 빠르게 검증해 보세요. OpenAI 호환 인터페이스와 사용량 기반 요금제, 신규 사용자 무료 테스트 크레딧을 제공해요.

📚 참고 자료

1. DeepSeek 공식 아키텍처 글: Super-agent 설계 탐구: 더 자율적인 Agent 시스템을 향해
2. 링크: x.com/DeepSeekHarness/article/2116857257245987236

3. 설명: 2계층 아키텍처, 5대 모듈, 실험 데이터와 미해결 문제에 관한 원문 자료

4. DeepSeek 공식 GitHub 저장소: dsh-superagent-prototype

5. 링크: github.com/deepseek-ai/dsh-superagent-prototype

6. 설명: 프로젝트 현황, 소스 코드, 프로토콜과 현재 적용 범위

7. 오픈소스 Domain Model 문서: 작업 객체와 처리 흐름 모델

8. 링크: github.com/deepseek-ai/dsh-superagent-prototype/blob/main/docs/001-domain.md

9. 설명: Source, Trigger, Ticket, Assignment 등 핵심 개념의 정의

10. 권한 및 구독 문서: Mandate와 Thread 구독 규칙

11. 링크: github.com/deepseek-ai/dsh-superagent-prototype/blob/main/docs/002-authorization.md

12. 설명: 구독 메시지가 권한 범위를 확장할 수 없다는 공식 설명

13. 배포 문서: 의존성, 계정과 보안 주의사항

14. 링크: github.com/deepseek-ai/dsh-superagent-prototype/blob/main/docs/006-deployment.md

15. 설명: 높은 권한으로 실행하는 방식과 별도 시스템 사용자 사용 권장 사항

16. DeepSeek API 공식 요금: 모델과 도구 가격

17. 링크: api-docs.deepseek.com/quick_start/pricing
18. 설명: 캐시 히트와 미스의 가격 차이와 비용 추정 참고 자료

작성자: APIYI 기술팀
기술 교류: APIYI apiyi.com 홈페이지에서 문의해 Agent 아키텍처와 다중 모델 호출 사례를 함께 논의해 보세요. 더 많은 자료는 docs.apiyi.com 문서 센터에서 확인할 수 있어요.

관련 글

• 한 사람이 최대 5개의 대화만 모니터링할 수 있다? DeepSeek 슈퍼 에이전트의 5대 모듈 분석: DeepSeek Harness 팀의 슈퍼 에이전트(Super-agent) 아키텍처 글을 분석해 5대 모듈, 실험 조건과 데이터, 네 가지 미해결 문제, 소규모 팀을 위한 도입 체크리스트, Router와 Worker의 모델 조합 및 비용을 살펴봅니다.