11월 1일, DeepSeek Harness 팀이 X에 장문 글 《슈퍼 에이전트 설계 탐구》를 올리고 슈퍼 에이전트(Super-agent) 아키텍처를 논의했어요. 게시 약 15시간 만에 조회수 약 130만 회, 좋아요 9.4K를 기록했어요. 이 글은 아키텍처 설계 철학을 다루며, 제품 기능을 소개하는 글이 아니에요.
한 줄 결론: 시스템이 세션 관리를 맡고, 사용자는 하나의 창구만 이용하는 설계예요. Router가 요청을 접수해 작업을 배분하고, Worker가 백그라운드 세션에서 작업을 병렬로 처리해요. 사람은 상위 의사결정과 최종 승인에 집중하면 돼요.
DeepSeek 슈퍼 에이전트가 단일 세션을 넘어서는 이유
현재 주류 Agent는 여전히 단일 세션을 작업 단위로 사용해요. 여러 작업을 동시에 실행하면 사용자가 직접 세션을 전환하고 맥락을 기억해야 해요. DeepSeek Harness 팀의 경험에 따르면, 한 사람이 동시에 처리할 수 있는 활성 세션은 보통 3~5개예요. 이 수치는 보편적인 통계가 아닌 팀의 경험이지만, 하나의 병목을 보여줘요. 단일 작업은 모델의 능력에, 여러 작업은 사람의 주의력에 제약을 받는다는 거예요.
로컬 Agent에 명령줄 도구와 외부 커넥터를 추가해도 외부 메시지를 받을 수 있을 뿐, 다음 세 가지 제약은 그대로 남아요.
- 동기식 대기: 기존 ReAct 방식은 생각과 도구 호출을 반복하다가 오래 걸리는 작업을 만나면 기다려야 해요. 그동안 새 메시지에 응답할 수 없어요.
- 컨텍스트 혼선: 서로 다른 작업의 중간 세부 사항이 하나의 윈도우에 섞여 서로 간섭해요.
- 기기 종속: 로컬 기기가 절전 모드에 들어가거나 오프라인 상태가 되면 Agent도 작동을 멈춰요.
그래서 이 글은 Agent를 사람이 직접 조작하는 개별 세션과 분리해, 끊김 없이 작동하는 하나의 주체로 만들자고 제안해요. 이 주체는 다음 네 가지 특성을 모두 갖춰야 해요. 단일 ReAct 루프만으로는 불가능하므로 주변 시스템 아키텍처가 뒷받침해야 해요.
| 슈퍼 에이전트의 특성 | 쉽게 말하면 | 핵심 모듈 |
|---|---|---|
| 연속성 | IM이나 GitHub 어디서 대화해도 같은 Agent처럼 느껴짐 | 2계층 아키텍처, 멀티채널 상호작용 |
| 효율성 | 이전 명령이 끝나지 않아도 새 지시를 받고 여러 작업을 병렬 처리 | 2계층 아키텍처, 전이중 상호작용 |
| 능동성 | 환경의 이벤트를 감시하고 처리할 가치가 있을 때 행동 | 이벤트 기반 |
| 지속성 | 항상 온라인 상태를 유지하고 이상 발생 시 자동 복구 | 연산 자원과 상태 분리, Watchdog |
DeepSeek 슈퍼 에이전트의 5가지 모듈 살펴보기
먼저 전체 표를 볼게요. 특히 “지금 사용할 수 있나요?” 열에 주목하세요. 이 글에서 다루는 내용은 설계 방향이므로, 이미 제공되는 기능과는 달라요.
| 모듈 | 해결하려는 문제 | 핵심 방식 | 지금 사용할 수 있나요? |
|---|---|---|---|
| 이중 계층 아키텍처 | 연속성과 동시성을 함께 확보하기 어려움 | Router는 상호작용과 작업 배분만 담당하고, Worker는 격리된 환경에서 실행 | 프로토타입에 유사한 흐름이 있지만, 전체 설계는 직접 구축해야 함 |
| 이벤트 기반 처리 | 에이전트가 지시를 기다려야 하고, 이벤트 노이즈가 많음 | 코드로 빠르게 선별하고 모델로 정밀 판단, Thread 구독은 바로 전달 | 프로토타입에서 GitHub를 감시할 수 있으며, Feishu도 선택 가능 |
| 전이중 멀티채널 | 오래 걸리는 작업이 대화를 막고 로그가 사용자에게 방해가 됨 | 도구를 비동기로 호출하고 채널별 응답 규칙을 지정 | DeepSeek Harness에 비동기 작업이 구현되어 있지만 기본적으로 비활성화됨 |
| 컴퓨팅·상태·환경 분리 | 기기가 오프라인이 되면 작업이 중단되고, 다른 환경에 접근할 수 없음 | 클라우드에서 루프를 실행하고, 상태는 데이터베이스에 저장하며, 엔드포인트는 원래 위치에 유지 | 원문에 외부 제공 여부가 명시되지 않아 직접 구축해야 함 |
| Watchdog | 프로세스는 살아 있지만 작업이 멈추거나 엉뚱한 방향으로 진행됨 | 메인 시스템 외부의 독립 세션이 주기적으로 점검 | 원문에 외부 제공 여부가 명시되지 않아 직접 구축해야 함 |
모듈 1: DeepSeek 슈퍼 에이전트의 Router/Worker 2계층 아키텍처
비유: Router는 손님을 맞고 주문을 전달하는 식당 프런트와 같아요. Worker는 주방처럼 각 조리대에서 한 가지 요리만 담당해요.
모든 이벤트를 하나의 세션으로 처리하면 컨텍스트가 끊기지 않지만 처리량이 낮아요. 반대로 이벤트마다 새 세션을 열면 동시 처리량은 높아지지만 전체 컨텍스트가 부족하고, 여러 세션이 사용자에게 각각 답변하는 혼란도 생겨요.
2계층 아키텍처는 이 두 역할을 분리해요. 계속 실행되는 Router가 사용자와의 상호작용과 전체 조율을 담당하며, Bash 도구가 전혀 없어도 돼요. Worker는 각각 독립된 컨텍스트에서 하나의 작업만 처리하고, 사용자에게 직접 답하지 않고 상태를 Router에 보고해요. 원문의 핵심은 세션을 사용자가 신경 써야 할 대상이 아니라 시스템 내부의 구현 세부 사항으로 만들어야 한다는 거예요.
Router가 병목이 될 것처럼 보이지만, 한 추론 라운드 동안 도착한 Trigger(환경에서 발생하는 이벤트)는 대기열에 쌓였다가 다음 라운드에서 묶어서 처리돼요. Router의 요청은 보통 입력이 길고 출력이 짧아요. 묶인 이벤트는 Prefill(모델이 입력을 처리하는 전반부) 단계에서 병렬 계산되므로, 단일 요청의 처리 시간은 묶인 이벤트 수보다 느리게 증가해요. 팀의 경험에 따르면 Router의 작업은 생각보다 단순해서 경량 모델로도 충분한 경우가 많아요. 실제로 도입할 때는 APIYI · apiyi.com을 통해 deepseek-v4.1-flash를 Router로 시험 운영하고 작업 배정 정확도를 살펴볼 수 있어요.
Worker는 작업 결과와 코드 품질을 직접 좌우하므로, 원문에서는 보통 가장 강력한 모델을 사용해야 한다고 봐요. APIYI · apiyi.com에서 동일한 작업으로 deepseek-v4-pro와 claude-opus-5-5를 비교한 뒤 기본 모델을 결정할 수 있어요.
모듈 2: DeepSeek 슈퍼 에이전트의 Trigger 이벤트 기반 동작
비유: 경비원이 먼저 명단을 보고 출입을 거른 뒤, 판단하기 어려운 경우에는 관리자에게 물어봐요. 기존 고객의 후속 요청은 원래 담당자에게 바로 전달하고요.
Agent가 능동적으로 일하려면 주요 입력이 사람의 프롬프트에서 단체 채팅 메시지, CI 결과, 코드 리뷰 댓글 같은 환경 이벤트로 바뀌어야 해요. 실제 이벤트 스트림에는 노이즈가 많아서 모든 이벤트를 대규모 언어 모델에 판단하도록 맡기면 지연 시간과 연산 비용이 감당하기 어려워져요. 그래서 이 글에서는 두 단계의 필터링을 설계했어요.
- Fast Path（코드 빠른 필터링）： 출처, 그룹, 사용자 또는 봇 화이트리스트를 기준으로 정해진 규칙에 따라 검사해요. 출처마다 “명시적인 요청에만 응답”, “후보 이벤트로 취급” 또는 “무시”를 설정할 수 있어요.
- Slow Path（모델을 통한 신중한 판단）： 빠른 필터링을 통과한 후보 이벤트만 LLM에 전달해요. LLM은 컨텍스트와 프롬프트로 작성한 정책을 함께 고려해 행동 여부를 결정해요.
라우팅도 빠른 경로와 느린 경로로 나뉘어요. 같은 PR, IM 대화 주제 또는 이메일 체인에서 이어지는 이벤트는 하나의 Thread를 구성해요. Worker가 Thread를 구독하면 이후 이벤트는 Router의 판단을 다시 거치지 않고 코드가 직접 전달해요. 여러 Worker가 같은 Thread를 구독하면 동일한 알림을 받아 충돌을 스스로 발견하고 해결할 기회가 생겨요.
컨텍스트는 캐시처럼 관리해요. 곧 사용할 정보는 윈도우에 직접 넣고（Inline）, 자주 쓰지 않는 전체 정보는 윈도우 밖에 두고 참조나 요약만 남겨요（Spill）. 이 글에서는 선제적 행동도 소개해요. 백그라운드에서 미리 캘린더를 확인하거나 이슈를 재현한 뒤 유용한 결과만 전달하고 나머지는 버리는 방식이에요. 추가 연산을 활용해 사람의 대기 시간과 개입을 줄이는 거죠.
모듈 3: DeepSeek 슈퍼 에이전트의 전이중 멀티채널 상호작용
비유: 물을 끓일 때 주전자 옆에 서 있을 필요는 없어요. 물이 끓으면 알림이 오고, 그동안 다른 사람과 대화할 수 있죠.
비동기 ReAct는 시간이 오래 걸리는 호출을 start()와 stop()으로 처리해요. start()는 즉시 반환되고 도구는 백그라운드에서 실행돼요. 작업이 끝나면 결과가 새 이벤트로 대화에 전달되죠. 모델은 stop()을 사용해 너무 오래 걸리는 명령을 종료할 수도 있어요. 덕분에 현재 추론 단계가 끝나면 사용자의 새 입력을 처리할 수 있어요. 원문에 따르면 DeepSeek Harness에는 이미 이 비동기 작업 방식이 구현돼 있지만, 기본 설정으로 활성화되어 있지는 않아요.
멀티채널은 ‘어떻게 소통할 것인가’를 다뤄요. IM에서는 가볍고 방해가 적은 방식으로 소통하며, 의사결정이나 승인이 필요할 때만 알림을 보내요. 팀이 검증한 엄격한 규칙 중 하나는 답변당 100단어를 넘기지 않는 거예요. 반면 GitHub, 이메일, 문서에는 구조적이고 정보 밀도가 높은 결과물이 필요해요. 예를 들어 PR에는 문제 배경, 변경 사항, 검증 결과를 명확히 작성해야 해요.
모듈 4: DeepSeek 슈퍼 에이전트의 연산 자원, 상태, 환경 분리
비유: 자료를 회사 기록 보관실에 보관하면 직원이 자리를 옮겨도 계속 일할 수 있어요. 특정 컴퓨터의 도구가 필요하면 그 컴퓨터에 사람을 보내 작업하면 되죠.
이 글에서는 두 단계로 구성 요소를 분리해요. 먼저 에이전트 루프는 상태를 저장하지 않는 클라우드 컨테이너에서 실행하고, 세션 상태는 데이터베이스에 저장해요. 따라서 컨테이너를 재시작하거나 교체해도 작업을 이어갈 수 있어요. 다음으로 실행 환경은 기존 위치에 그대로 두고, 각 엔드포인트에는 가벼운 데몬(백그라운드에서 상시 실행되는 작은 프로그램)만 설치해요. 데몬은 세션 상태를 저장하지 않고 명령 실행과 결과 반환만 담당해요.
이 설계는 BYOM(Bring Your Own Machine, 자신의 컴퓨터를 클라우드 에이전트에 연결하는 방식)도 지원해요. 커밋하지 않은 변경 사항과 로컬 인증 정보를 모두 클라우드에 동기화할 필요가 없죠. 기기가 다시 온라인 상태가 되면 클라우드 에이전트가 해당 기기에서 실행해야 하는 작업을 이어서 완료할 수 있어요. Anthropic의 “Decoupling the brain from the hands”도 비슷한 분리 방식을 채택하고 있어 함께 읽어보면 좋아요.
모듈 5: DeepSeek 슈퍼 에이전트의 Watchdog 외부 점검
비유: 당직 관리자가 직접 업무에 참여하지 않고, 누가 일을 멈췄는지 또는 방향을 벗어났는지 주기적으로 살펴보는 것과 같아요.
많은 Agent 이상 상황은 프로세스가 멈추는 게 아니라, 프로세스는 살아 있지만 모델이 성과 없는 반복에 빠지는 형태로 나타나요. 기존 생존 확인 프로브로는 이런 문제를 발견할 수 없어요. Watchdog은 주 시스템 밖에서 실행되는 독립 세션으로, 정기적으로 전달되는 메시지에 따라 동작해요. API 오류나 상태 복구 실패 같은 인프라 장애를 처리할 뿐 아니라, 모델을 활용해 각 Worker가 실질적으로 작업을 진전시키고 있는지도 판단해요. 관리자는 자연어로 “왜 실패했어?”라고 물어보거나, 시스템이 실행 중일 때 프롬프트와 트리거 규칙을 조정하도록 요청할 수도 있어요.
DeepSeek 슈퍼 에이전트 프로토타입은 지금 어디까지 써볼 수 있을까요?
관련 저장소는 github.com/deepseek-ai/dsh-superagent-prototype이며 MIT 라이선스를 사용해요. 2026-11-02 수집 기준으로 stars는 8,636개, forks는 863개였어요. 이 저장소는 연구용 프로토타입으로, DeepSeek의 공식 제품이 아니며 팀 내부 버전이나 글에서 설명하는 전체 구현과도 달라요. 글에 소개된 일부 설계는 향후 방향에 해당하며, 프로토타입에는 구현되지 않았어요.
이 프로토타입은 단일 GitHub 저장소를 대상으로 하는 능동형 프로그래밍 Agent이며, DeepSeek Harness의 번들로 패키징되어 있어요. GitHub를 모니터링하고 선택적으로 Feishu에도 연결할 수 있어요. 누군가 작업을 맡기면 작업 항목을 만들고 별도의 세션과 디렉터리에서 작업한 뒤, PR을 제출하는 등의 결과를 원래 대화에 답변해요. 사람이 처리해야 할 사항을 보여주는 웹 대시보드도 별도로 제공해요.
DeepSeek 슈퍼 에이전트의 두 실험 데이터가 말해주는 것
아래 데이터는 모두 공식 글에서 자체 보고한 결과예요. 실험에는 합성 부하와 단순화된 환경을 사용했으며, 저자는 결과를 참고용으로만 보라고 밝혔어요. 첫 번째 실험은 한 번 실행할 때마다 약 300개의 메시지가 오갔고, 그중 작업 요청은 약 20개였어요. 각 설계는 5회씩 반복했어요. 코딩 작업은 시간만 소모하는 도구로 시뮬레이션했기 때문에, 측정 대상은 작업 수행 품질이 아니라 스케줄링과 조율이에요.
표에서 p50은 작업의 절반이 완료되는 시간, p95는 작업의 95%가 완료되는 시간을 뜻해요. cache-read tokens는 캐시 읽기(이미 캐시된 컨텍스트를 재처리하지 않고 바로 재사용)에 사용한 토큰 수로, 여기서는 모든 세션의 합계예요.
| 설계 | p50(분) | p95(분) | 실행당 cache-read tokens |
|---|---|---|---|
| Super-agent | 12.4 | 15.7 | 23.2M |
| Pass-through(구독 직통) 제거 | 12.6 | 15.5 | 31.8M |
| 단일 세션 + 하위 에이전트(중립적 프롬프트) | 20.4 | 29.5 | 6.1M |
| 단일 세션 + 하위 에이전트(위임 우선 프롬프트) | 13.8 | 29.0 | 10.8M |
중립적 프롬프트에서는 모델이 5번의 실행 모두에서 하위 에이전트를 호출하지 않았어요. 위임 우선 프롬프트에서는 5번 중 4번을 위임했고, 나머지 한 번은 모델이 작업이 작다고 판단해 직접 처리했어요. 이 부하에서 단일 세션의 성능은 프롬프트와 모델의 상황별 판단에 크게 좌우되는 반면, 2계층 아키텍처는 위임을 시스템 차원에서 고정해 둔 셈이에요. 대가도 분명해요. Super-agent는 캐시 읽기 토큰을 훨씬 많이 사용해 더 짧고 안정적인 완료 시간을 얻었어요.
직통을 제거해도 완료 시간은 거의 달라지지 않았지만, Router의 결정 횟수는 약 30%, cache-read tokens는 약 37% 늘었어요. 따라서 이 부하에서 직통의 주된 역할은 속도 향상이 아니라 Router의 오버헤드를 줄이는 것이었어요.
두 번째 실험에서는 Router 계층만 따로 부하 테스트했어요. Router는 실제 모델을 호출하고 Worker는 시뮬레이션 모델을 사용하면서, Router의 판단이 필요한 Trigger의 도착률을 점차 높였어요.
| 도착률(회/분) | 평균 배치 크기 | 단일 요청 시간 | 결정당 분담 추론 시간 |
|---|---|---|---|
| 약 1 | 1.0 | 2.5초 | 6.4초 |
| 약 40 | 2.8 | 3.9초 | 1.6초 |
하나의 결정에는 여러 번의 LLM 요청이 포함될 수 있으므로, 분담 시간이 단일 요청 시간보다 길 수 있어요. 이 데이터는 이벤트가 갑자기 몰릴 때 자동 병합으로 Router의 유효 처리량을 높일 수 있다는 점을 뒷받침해요. 다만 실제 프로덕션 환경에서도 같은 결과가 나온다는 증거는 아니며, 작업 품질이나 코드베이스에 따른 성능 차이도 보여주지 못해요.
DeepSeek 슈퍼 에이전트의 네 가지 미해결 문제
원문은 다음 문제가 아직 해결되지 않았음을 명시해요. 실제 도입 방안을 평가할 때도 이를 고려해야 해요.
- 아키텍처 확장 방법: 작업 규모가 커지고 구성 요소 간 결합이 강해질 때 Router를 샤딩해야 하는지, 얼마나 세분화해야 하는지, Worker가 언제 직접 통신해야 하는지는 아직 정해지지 않았어요. 샤딩을 세분화할수록 동시 처리량은 늘지만, 공유하는 메모리와 컨텍스트는 줄어들어요. 장기 메모리도 주요 병목이에요.
- 세션 없이 사용하는 방법: 작업을 어떻게 보여줄지, 백그라운드 작업을 중단하지 않으면서 사람이 핵심 세부 사항에 어떻게 개입할지에 관한 새로운 상호작용 방식이 필요해요.
- 컨텍스트 경계와 A2A: A2A(agent-to-agent)는 서로 다른 에이전트 간의 소통과 협업을 뜻해요. 조직이 커지면 Super-agent를 구성하는 일은 사실상 어떤 컨텍스트를 공유하고 격리할지 결정하는 일이에요. 권한 경계를 넘어 안전하게 협업하는 방법은 아직 정해지지 않았어요.
- 보안과 개인정보 보호: 가장 우선적으로 평가해야 할 문제예요. 클라우드의 실행 루프는 외부 이벤트를 지속적으로 받아들이고, 엔드포인트에는 비공개 코드와 로컬 자격 증명이 저장돼 있어요. 서버가 침해되거나 프롬프트 인젝션(입력에 숨겨진 악성 지시)으로 실행 루프가 공격당하면 연결된 엔드포인트도 장악될 수 있어요. 원문은 에이전트에 “자격 증명을 볼 수는 없지만 사용할 수 있는” 방식이 필요하다고 봐요.
DeepSeek 슈퍼 에이전트, 소규모 팀을 위한 최소 도입 체크리스트
아래 순서는 원문의 아이디어를 바탕으로 제안한 것이며, 공식 로드맵은 아니에요. 먼저 신뢰할 수 있는 범위의 단일 저장소에서 시범 운영하고, Router 샤딩은 당분간 적용하지 않아요.
1단계: Router와 Worker부터 분리하기
- 코드: 상시 실행되는 Router 진입점을 만들고 Bash 도구는 제공하지 않아요. 작업마다 독립적인 컨텍스트와 작업 디렉터리를 갖춘 Worker를 생성하고, Worker는 결과를 Router에만 보고해요.
- 모델: Router에는 경량 모델을, Worker에는 더 성능이 좋은 모델을 사용해요. 각각 별도로 설정해 개별 교체가 가능하도록 해요.
- 사람: Router하고만 대화하며 작업 범위 정의, 의사결정 요청 처리, 최종 승인을 담당해요.
2단계: Trigger 필터링 추가하기
- 코드: 소스 허용 목록과 3단계 정책을 설정하고, PR과 IM 대화 주제를 Thread에 매핑해요. 이미 구독한 후속 이벤트는 Worker에 바로 전달해요.
- 모델: 후보 이벤트만 의미를 분석해 대응할지, 새 Worker를 생성할지 판단해요.
- 사람: 프롬프트에 행동 조건을 명확히 작성하고, 오작동과 누락을 정기적으로 점검한 뒤 허용 목록과 정책을 조정해요.
3단계: 마지막으로 Watchdog 추가하기
- 코드: Watchdog을 메인 시스템 외부에 배포하고 주기적인 메시지로 실행해요. API 오류나 상태 복구 실패 같은 인프라 문제를 점검해요.
- 모델: Worker의 진행 기록을 읽고 실제로 진전이 있는지, 막혀 있는지, 목표에서 벗어났는지 판단해요.
- 사람: Watchdog의 복구 권한을 설정하고, 프롬프트와 트리거 규칙 변경을 승인하며, 실패 원인을 돌아봐요.
첫날부터 프로덕션 자격 증명을 모델 컨텍스트에 직접 넣지 말고, 권한도 필요한 최소 범위로 설정해야 해요. 비동기 도구 호출과 연산 자원 분리는 앞의 세 단계가 안정적으로 작동한 뒤, 실제로 작업 차단이나 장비 오프라인 문제가 발생할 때 도입해도 돼요.
DeepSeek 슈퍼 에이전트의 모델 조합과 비용 추정
아래 표는 2026-11-02에 조회한 APIYI · apiyi.com의 모델 가격표예요. 단위는 $/1M tokens입니다. 모델과 가격은 플랫폼의 모델 목록을 확인하고, 실제 청구액은 콘솔에서 확인하세요.
| 모델 | 입력 | 출력 | 캐시 읽기 |
|---|---|---|---|
| deepseek-v4.1-flash | 0.3 | 1.2 | 0.006 |
| deepseek-v4-flash | 0.44 | 1.32 | 0.01408 |
| deepseek-v4-pro | 1.32 | 3.96 | 0.043996 |
| claude-opus-5-5 | 4 | 20 | 0.2 |
아래 금액은 모두 공개 가격을 기준으로 계산한 추정치이며, 실측값이 아니에요. 호출 한 번에 입력 2만 tokens, 출력 2천 tokens를 사용하고 캐시는 고려하지 않았다고 가정했어요.
deepseek-v4.1-flash는 약 $0.0084,deepseek-v4-pro는 약 $0.0343,claude-opus-5-5는 약 $0.12예요.- Router에
deepseek-v4.1-flash, Worker에deepseek-v4-pro를 사용해 각각 한 번씩 호출하면 총 약 $0.0427이에요. 양쪽 모두claude-opus-5-5를 사용하면 약 $0.24로, 앞선 조합의 약 5.6배예요. - 이 사용량으로 하루에 20세트를 실행하면 혼합 조합은 약 $0.85, 모두
claude-opus-5-5를 사용하면 약 $4.8이에요. 실제 Worker는 여러 차례 호출하는 경우가 많으니, 직접 기록한 로그의 token 수로 다시 계산하세요.
장시간 실행하는 시스템은 캐시 읽기 비용도 따로 계산해야 해요. 실험의 캐시 읽기 23.2M tokens를 기준으로 추정하면, 전부 deepseek-v4.1-flash로 계산할 때 약 $0.14, deepseek-v4-pro는 약 $1.02, claude-opus-5-5는 약 $4.64예요. 대략적인 규모를 가늠하기 위한 수치일 뿐이에요. 실험에서 각 계층의 token 분포를 공개하지 않았고, 입력과 출력 비용도 포함하지 않았어요.
Router와 Worker의 모델은 설정 항목으로 분리하는 게 좋아요. APIYI · apiyi.com에서는 하나의 API 키로 이 모델들을 전환할 수 있어요. OpenAI 호환 인터페이스의 base_url은 https://api.apiyi.com/v1이며, 전환할 때 주로 모델명만 바꾸면 돼요. 같은 작업으로 품질과 비용을 비교하기 편리해요. 다만 가격은 선택 기준의 절반일 뿐이에요. Worker의 기본 모델은 작업 성공률과 재작업량도 살펴보고 정하세요.
위 그래프는 APIYI · apiyi.com 모델 가격표의 기본 가격으로 추정했어요. 예산을 세울 때는 직접 사용한 token 수를 대입해 계산하세요.
DeepSeek 슈퍼 에이전트 자주 묻는 질문 FAQ
Q1: 새로운 모델인가요?
아니요. 이 글은 Agent 시스템 아키텍처를 다루며, 주변 시스템이 세션, 이벤트, 상태, 모니터링을 어떻게 구성하는지에 초점을 맞춰요. 새로운 모델을 출시한 것은 아니에요.
Q2: 일반 개발자도 바로 사용할 수 있나요?
다섯 가지 모듈을 바로 사용할 수 있는 기능으로 생각하면 안 돼요. 현재는 연구용 프로토타입을 시험하거나, 글의 아이디어를 바탕으로 직접 구축할 수 있어요. 원문에서 기존 구현으로 명확히 언급한 것은 DeepSeek Harness의 비동기 작업 메커니즘뿐이며, 이 기능도 기본적으로 꺼져 있어요.
Q3: dsh-superagent-prototype은 공식 제품인가요?
아니요. README에 연구 참고용이라고 명시되어 있어요. DeepSeek 공식 제품이 아니며, 내부 버전이나 글에서 설명한 전체 구현과도 같지 않아요.
Q4: 멀티 Agent를 사용하면 비용이 더 많이 드나요?
이 실험에서는 캐시 읽기 토큰이 확실히 더 많았어요. Super-agent는 23.2M, 단일 세션 방식은 6.1M~10.8M이었어요. 그 대신 작업 완료 시간이 더 짧고 안정적이었죠. 실제 총비용은 모델 조합과 작업 규모에도 영향을 받아요. Router에 경량 모델을 사용하고 Thread 직통을 활성화하면 비용을 줄이는 데 도움이 돼요.
Q5: 중국에서는 이 모델들을 어떻게 연동하나요?
APIYI · apiyi.com에서 가입하고 API 키를 발급받을 수 있어요. 신규 사용자에게는 무료 테스트 한도가 제공돼요. 그런 다음 클라이언트의 base_url을 위에서 안내한 주소로 변경하고, 모델 파라미터에 표에 나온 모델명을 입력하세요. 이 DeepSeek 및 Claude 모델은 모두 chat, messages 엔드포인트를 지원해요. 서비스에 적용하기 전에 적은 트래픽으로 먼저 검증하는 것이 좋아요.
요약
DeepSeek 슈퍼 에이전트에 관한 이 글의 가치는 고전적인 시스템 엔지니어링 사고를 Agent에 적용했다는 데 있어요. 핵심은 다음과 같아요.
- 문제 정의: 단일 작업에 필요한 인력은 점점 줄고 있지만, 다중 작업의 병목은 사람의 주의력으로 옮겨가고 있어요.
- 다섯 가지 모듈: 이중 계층 아키텍처, 이벤트 기반 처리, 전이중 다중 채널, 연산·상태·환경 분리, Watchdog은 지속성, 효율성, 능동성, 영속성이라는 네 가지 특성에 대응해요.
- 근거의 범위: 두 실험 모두 저자가 직접 보고한 합성 워크로드 결과이므로 설계 참고 자료로만 활용해야 해요.
- 구현 순서: 먼저 Router와 Worker를 분리하고, Trigger 필터링을 추가한 뒤, 마지막으로 Watchdog을 도입하세요. 모든 단계에서 보안 경계를 우선해야 해요.
모델 조합을 처음부터 확정할 필요는 없어요. APIYI · apiyi.com에서 동일한 작업을 소규모로 비교해 본 뒤, 성공률과 비용을 기준으로 구성을 결정할 수 있어요.
Agent를 더 추가하기 전에, 먼저 스스로 ‘인간 Router’ 역할에서 벗어나세요.
작성자: APIYI 기술팀
기술 교류: APIYI 웹사이트 홈페이지에서 문의해 주세요. 더 많은 자료는 docs.apiyi.com 문서 센터에서 확인할 수 있어요.
