Exploring Super-agent Design: Towards a More Autonomous Agent System

3줄 요약

1. 2026년 11월 1일, DeepSeek Harness 팀(주저자 Yujia Qiao)은 슈퍼에이전트(Super-agent) 시스템 아키텍처와 프로토타입(dsh-superagent-prototype)을 공개했다.¹ 단일 세션에 종속된 기존 에이전트의 한계를 해소하고 복잡한 과제 여러 건을 상시 처리하는 것이 목표다.
2. 연구진이 설계한 다섯 모듈의 중심은 두 계층 아키텍처다. Router 계층은 사람과의 상호작용과 전역 조율을 전담하고, Worker 계층은 개별 과제를 병렬로 실행한다. 나머지 네 모듈은 이벤트 처리(두 단계 필터링, 구독 패스스루, 참조 그래프 기반 맥락 회수 Chain of Recall), 전이중 비동기 ReAct 루프, 외부 Watchdog 세션, 그리고 컴퓨팅과 상태, 실행 환경을 두 단계로 분리하는 구조(BYOM 포함)다.
3. 약 300건의 메시지(작업 요청 약 20건 포함)를 주입한 종단 간 실험에서 슈퍼에이전트의 과제 완료 시간은 중앙값(p50) 12.4분, 95백분위수(p95) 15.7분이었다. 단일 세션이 서브에이전트 도구를 쓰는 구조(p95 29.0~29.5분)보다 빠르고 안정적이다.

1. 단일 세션의 한계와 슈퍼에이전트의 네 가지 조건

지난 1년 동안 코딩 에이전트를 비롯한 단일 과제 에이전트는 도구를 활용해 복잡한 문제를 해결하면서 사람의 지속적인 감시와 단계별 개입을 줄여 왔다. 에이전트 여러 개를 조율하는 모델 능력도 향상되어 여러 세션에 걸친 작업 편성과 스케줄링이 가능해졌다. 세부 실행에 직접 참여하는 비중이 줄어들면서 사람의 역할은 점차 상위 수준의 의사결정과 최종 승인으로 바뀌고 있다. 메신저, 캘린더, 이메일, 업무 플랫폼에 직접 연결해 피드를 감시하고 과제를 돕는 개인용 에이전트도 다수 등장했다.

하지만 현재 주류 에이전트 설계는 여전히 단일 세션을 기본 작업 단위로 삼고 있어 여러 과제나 팀 단위의 상시 협업을 지원하기 어렵다. 세션끼리 서로 격리되어 있기 때문에 여러 과제를 병렬로 실행하는 사용자는 세션을 수동으로 전환하며 각 세션에 어떤 맥락이 들어 있는지 직접 기억해야 한다. 연구진의 경험에 따르면 사람이 동시에 추적할 수 있는 활성 세션은 보통 3~5개에 그친다. 단일 과제를 얼마나 잘 푸는지는 모델 능력이 결정하지만, 여러 과제를 동시에 진행할 때는 사람이 맥락을 따라가는 주의력의 한계에서 먼저 막힌다. 기존 로컬 단일 세션 에이전트에 CLI나 MCP, 외부 커넥터를 추가해도 한계는 그대로 남는다. 긴 작업에서는 동기식으로 멈추고, 여러 과제의 맥락이 뒤섞이며, 로컬 장비가 오프라인이 되면 모든 작업이 중단된다.

연구진은 에이전트를 사람이 수동으로 구동하는 개별 세션과 분리된 존재로 재정의했다. 여러 세션에 걸쳐 맥락을 유지하면서 복잡한 과제 여러 건을 간섭 없이 동시에 처리하는 단일 연속 개체다. 연구진은 이를 슈퍼에이전트(Super-agent)라 명명했다. DeepSeek Harness에서 가동 중인 슈퍼에이전트 인스턴스는 사내 메신저(IM)와 GitHub를 연결해 같은 개발 과제를 이어서 수행한다.

사내 메신저 그룹 채팅에서 제기된 글꼴 설정 요청을 받아 PR을 생성하고, 메신저의 추가 요청과 GitHub 리뷰어의 UI 수정 요청을 같은 PR에서 연속으로 반영해 머지까지 마치는 과정.

이 인스턴스는 공개 그룹 채팅의 피드백도 상시 모니터링하며, 아무도 에이전트를 멘션하지 않아도 스스로 버그의 근본 원인을 찾아 수정 PR을 제출한다.

macOS 데스크톱 앱에서 비활성 창을 클릭할 때 더블클릭으로 오인되어 세션 이름 변경이 실행된다는 사용자의 불만을 보고, 멘션이나 지시 없이 Electron의 클릭 이벤트 처리를 백그라운드에서 조사해 원인을 규명하고 전후 스크린샷과 함께 수정 PR을 제출한 사례.

슈퍼에이전트가 갖춰야 할 네 가지 기본 특성은 다음과 같다.

• 연속성(Continuous): 사용자가 메신저 채팅이나 GitHub 코멘트 등 기존 업무 공간 어디에서 말을 걸어도 늘 하나의 에이전트와 대화하는 것처럼 작동한다. 특정 세션이 특정 정보를 알고 있는지 사용자가 신경 쓸 필요가 없다. 예를 들어 메신저에서 A안을 지시했다가 나중에 GitHub PR 코멘트에서 B안으로 변경해도 에이전트가 맥락을 파악해 작업을 수정한다.
• 생산성(Productive): 빠르게 응답하며 복잡한 과제 여러 건을 동시에 높은 품질로 완수한다. 이전 명령이나 과제가 끝나기 전에도 다음 지시를 받을 수 있다.
• 능동성(Proactive): 단계별 지시를 기다리지 않고 환경의 이벤트를 감시하다가 처리할 가치가 있는 사안에 스스로 대응하며, 그 외에는 조용히 대기한다.
• 영속성(Persistent): 항상 온라인 상태를 유지하며 사용자의 실제 작업 환경에 직접 연결되고, 장기 실행 중 이상 동작이 발생하면 스스로 복구한다.

하나의 ReAct 루프만 돌리는 구조에서는 이 네 가지 특성을 동시에 구현하기 어렵다. 연구진은 이를 해결하기 위해 다섯 가지 시스템 아키텍처 모듈을 조합했다.

슈퍼에이전트 전체 아키텍처(대괄호 숫자는 이 글의 절 번호).

2. 두 계층 아키텍처: 연속성과 처리량의 양립

여러 채널에 걸친 대화의 연속성과 다중 과제의 동시 처리량(throughput)은 세션 구성 방식을 정할 때 상충한다. 모든 이벤트를 단 하나의 세션으로 보내면 그 세션이 모든 정보를 보므로 맥락 연속성은 극대화된다. 그러나 ReAct 루프가 한 번에 한 단계씩만 실행되어 처리 속도가 느려지고, 서로 다른 과제의 중간 과정이 한 컨텍스트에 뒤섞여 결과 품질이 저하된다. 반대로 이벤트마다 새 세션을 생성하면 동시 처리량은 극대화된다. 대신 전역 맥락이 공유되지 않아 연관된 과제의 결과가 단절되고, 여러 세션이 사용자에게 제각각 응답해 혼란을 초래한다.

연구진은 이 문제를 해결하기 위해 역할을 두 계층으로 분리했다. 장기 실행되는 Router 계층(2.1절)은 모든 사용자 상호작용과 전역 조율을 전담해 연속성을 유지하고, 컨텍스트가 격리된 Worker 계층(2.2절)은 개별 과제를 높은 동시성으로 실행한다. 시스템이 컨텍스트 관리와 병렬 실행을 내부에서 처리하므로, 사용자는 개별 세션을 일일이 챙기지 않고도 늘 같은 슈퍼에이전트와 협업할 수 있다.

Router 계층과 격리된 Worker 세션으로 구성된 두 계층 아키텍처.

2.1 Router 계층과 자동 배칭(Batching)

Router 계층은 모든 채널의 대화를 수신해 이벤트의 전역 순서를 정하고 과제를 배분한다. 기존 에이전트 팀(Agent Team)의 리더처럼 단일 과제를 세부 단계로 분해해 조율하지 않고, 고수준 배분과 과제 간 관계 추적만 맡으며 직접 실행 도구(Bash 등)도 쓰지 않는다. 역할이 단순해 가벼운 모델로도 응답 속도와 배분 품질을 확보할 수 있다.

연구진은 Router 계층을 장기 실행되는 단일 LLM 세션으로 구현했다. 한 추론 턴이 진행되는 동안 도착한 환경 이벤트(Trigger)를 대기열에 모았다가 다음 턴에 한꺼번에 주입하는 방식이다. 연구진은 이 자동 배칭(batching) 덕분에 처리량 병목이 쉽게 발생하지 않는다는 점을 확인했다.

• 외부 이벤트가 느린 속도로 도착할 때는 Trigger가 한 건씩 Router 세션에 전달되어 즉시 응답이 반환된다.
• 이벤트가 일시에 몰려 대기열이 생기면, 이전 턴 동안 쌓인 Trigger가 자동으로 병합되어 다음 LLM 호출 한 번에 함께 주입된다. Router 세션은 가벼운 응답과 배분만 수행하므로 입력은 길고 출력은 짧다. 병합된 Trigger는 프리필(Prefill) 단계에서 병렬로 계산되므로 요청당 소요 시간은 배치 크기보다 훨씬 느리게 증가하며, 의사결정 1건에 드는 분할 상환(amortized) 추론 시간은 도리어 줄어든다.

시스템 규모가 더 커져 단일 세션으로 감당하기 어려워지면 내부에 다단계 필터링 구조를 두거나 수평 샤딩(horizontal sharding)으로 여러 세션에 분산할 수 있다.

2.2 Worker 계층

각 Worker 세션은 격리된 컨텍스트와 전체 실행 도구를 갖추고 고성능 모델로 단일 과제를 수행한다. 사람과 직접 대화하거나 추론 과정, 도구 로그를 외부에 노출하지 않고 Router 계층에만 상태를 보고한다.

Worker끼리 직접 통신할 일은 드물다. 하나의 PR처럼 공유하는 작업 환경에서 충돌이 생기면, 해당 스레드(Thread)를 함께 구독한 Worker들이 같은 이벤트 알림을 받아 스스로 충돌을 감지하고 해결한다. 각 Worker는 내부에서 서브에이전트나 자체 에이전트 팀을 꾸릴 수 있으며, 이 내부 구성은 Router 계층에 드러나지 않는다.

3. 이벤트 기반 트리거와 맥락 조직화

슈퍼에이전트가 지시를 기다리지 않고 능동적으로 행동할 수 있는 이유는 시스템을 구동하는 입력 자체가 다르기 때문이다. 사람이 세션에 한 줄씩 입력하는 프롬프트 대신, 작업 환경에서 발생하는 반정형 이벤트가 에이전트를 깨운다. 그룹 채팅 메시지, 이메일, 캘린더 알림, 코드 리뷰 코멘트, CI 결과 같은 환경 이벤트를 Trigger라 부른다.

3.1 두 단계 이벤트 필터링 (Fast Path / Slow Path)

실제 그룹 채팅과 코드 플랫폼에 연결되면 에이전트가 개입할 필요가 없는 일상 메시지가 대부분을 차지한다. 모든 이벤트를 대형 모델로 판단하면 지연 시간과 연산 비용이 과도해진다. 따라서 컴퓨터 시스템의 Fast Path / Slow Path 개념을 차용해 결정론적 코드와 대형 모델을 결합한 두 단계 필터링을 적용한다.

• 프로그래밍 정책(Fast Path): 이벤트 출처, 그룹, 사용자와 봇 허용 목록 등 결정론적 조건을 코드로 빠르게 검사한다. 예를 들어 출처별로 “명시적 요청에만 응답”, “후보 이벤트로 취급”, “무시”를 설정해 무관한 대다수 메시지를 모델 호출 전에 걸러낸다.
• 시맨틱 정책(Slow Path): 첫 단계를 통과한 후보 이벤트만 LLM에 전달해 맥락과 프롬프트 기반 정책에 따라 행동 여부를 판단한다. 사용자는 자연어 프롬프트로 언제든 시맨틱 정책을 켜고 끄거나 추가할 수 있다.

프로그래밍 정책(Fast Path)과 시맨틱 정책(Slow Path)으로 이어지는 두 단계 이벤트 필터링.

3.2 구독과 패스스루(Subscription and Pass-through) 라우팅

이미 배정된 과제의 후속 이벤트까지 매번 Router 계층을 거치면 전역 노드의 부하가 커지고 응답이 느려진다. 실제 업무에서 같은 GitHub PR이나 메신저 주제, 이메일 체인에 연달아 발생하는 이벤트 흐름은 하나의 Thread를 이룬다.

Thread 예시. 사내 메신저의 같은 대화 주제에서 이어지는 메시지나 같은 GitHub PR에 달리는 리뷰 코멘트와 커밋이 각각 하나의 Thread를 구성한다.

Router 계층이 어떤 Thread의 첫 이벤트를 처리해 Worker 세션을 생성하면, 그 Worker는 해당 Thread를 직접 구독한다. 이후 라우팅은 두 경로로 구분된다.

• 구독 경로(Fast Path): 그 Thread에서 발생하는 후속 이벤트는 Router의 추가 도구 호출 없이, 구독 중인 Worker에 코드가 직통으로 전달(pass-through)한다. 만약 새 이벤트가 현재 과제에 해당하지 않으면 Worker가 구독을 해제하거나 이벤트를 다시 Router 계층에 전달해 재배분하게 한다.
• 미구독 경로(Slow Path): Router 계층은 전역 상태 추적을 위해 모든 이벤트를 열람할 수 있지만, 직접 평가하고 배분하는 대상은 아직 구독자가 없는 신규 이벤트로 한정한다.

구독과 패스스루(Subscription and Pass-through) 라우팅 흐름.

Thread와 Worker의 구독 관계는 다대다(many-to-many) 구조다. 하나의 Worker가 연관된 여러 Thread를 구독할 수 있고, 하나의 공유 Thread를 여러 Worker가 함께 구독해 점대점 통신 없이도 서로의 작업을 파악하고 충돌을 조율할 수 있다.

3.3 컨텍스트 조직화: Inline & Spill과 Chain of Recall

제한된 컨텍스트 창을 효율적으로 쓰기 위해 연구진은 컴파일러 최적화와 시스템 설계의 캐시와 지역성(locality) 개념을 빌려 Inline & Spill을 도입했다. 당장 필요할 가능성이 높은 정보는 현재 컨텍스트 창에 바로 넣어 도구 호출 왕복을 줄인다(Inline). 컨텍스트 예산을 초과하거나 드물게 쓰이는 전체 정보는 창에 넣지 않고 요약과 참조 포인터만 남겨, 모델이 필요할 때 도구로 읽게 한다(Spill).

1. 최소 정보로 시작: 처음에는 현재 객체의 ID와 내용 요약만 제공한다.
2. 지역성에 따른 점진적 Inline: 밀접하게 연관된 객체의 ID를 먼저 넣고, 시공간적으로 인접한 내용을 덧붙인다. 본문 앞 50자, 그 메시지 전후의 채팅 메시지와 답장 대상 메시지, 같은 코드 리뷰 토론의 인접 코멘트 등이 여기에 해당한다.
3. 한도 초과분 Spill: 길이 상한을 초과하는 긴 본문은 잘라내고 이어지는 내용을 읽을 수 있는 포인터를 남긴다.

장기 실행 과정에서 수많은 후속 이벤트가 Worker로 직통 전달되고 과거 과제가 누적되면, Router 계층은 모든 과제의 전체 이력을 컨텍스트 창에 보관할 수 없다. 이를 해결하는 메커니즘이 Chain of Recall이다. 시스템의 모든 객체(Trigger, Thread, Worker 세션)에 고유 ID를 부여하고, 연관 객체의 ID를 함께 Inline해 참조 그래프를 구성한다.

Chain of Recall. Trigger, Thread, Worker 세션이 서로의 ID를 포함한 참조 그래프를 이루며, 모델이 현재 이벤트에서 출발해 필요한 만큼 다음 홉(hop) 객체를 단계적으로 조회한다.

3.4 추측 실행(Speculative Execution)을 활용한 선제 행동

컴퓨터 아키텍처의 추측 실행 개념을 적용하면, 에이전트는 환경 신호를 포착했을 때 작업 결과가 채택될지 확정되기 전에 백그라운드 연산 자원으로 작업을 미리 시작한다. 유용한 것으로 판명된 결과만 사용자에게 전달하고 나머지는 폐기한다. 개인 비서 시나리오에서는 회의 초대 메일이 오면 일정 충돌 확인과 배경 자료 조사, 답장 초안 작성을 미리 마쳐 둔다. 연구개발 협업에서는 사내 그룹에 버그 제보가 올라오면 “조용히 재현 및 수정(silently reproduce and fix)” 정책을 가동하고, 이슈 재현과 간단한 수정이 실제로 성공했을 때만 PR을 생성해 공유한다.

추측 실행 사례. 모델 출력의 물결표(틸드)가 취소선으로 잘못 렌더링되는 문제를 두고 사용자들이 학습 수정과 렌더러 수정 중 무엇이 나을지 논의하는 사이, 슈퍼에이전트는 백그라운드에서 단일 물결표는 유지하고 이중 물결표만 취소선으로 처리하는 PR을 이미 생성했다. 근거로 Pandoc과 markdown-it 규격 비교까지 제시하는 장면이다.

4. 전이중(Full-Duplex) 다중 채널 상호작용

4.1 비동기 ReAct 루프와 전이중 대화

기존의 반이중(half-duplex) ReAct 루프에서는 모델이 동기식 run() 도구를 호출하면 실행이 끝날 때까지 루프가 차단되어 사용자의 새 메시지에 응답할 수 없다. 연구진은 시간이 오래 걸리는 명령과 도구 호출을 비동기 start()와 stop() 호출로 대체해 비동기 ReAct 루프로 전환했다.

동기식 ReAct 루프와 비동기 ReAct 루프 비교. start() 호출은 즉시 Started를 반환하고 백그라운드 실행이 끝나면 결과가 새 이벤트 메시지로 주입되므로, 도구가 실행되는 동안에도 사용자와 대화를 이어갈 수 있다.

4.2 채널별 상호작용 규범

사람들이 그룹 채팅, 이메일, GitHub 토론에서 소통하는 방식이 다르므로 에이전트도 채널에 맞춰 응답의 상세도와 형식을 조절해야 한다. Worker 세션의 장황한 추론 과정과 도구 호출 로그는 외부로 내보내지 않고, Router 계층이 프롬프트 규범에 따라 채널별로 응답을 조율한다.

5. 컴퓨팅, 상태, 실행 환경의 두 단계 분리

로컬 에이전트는 에이전트 루프를 실행하는 컴퓨팅(compute), 영속화되어야 할 세션 상태(state), 코드 저장소와 로컬 툴체인 같은 실행 환경(environment) 세 가지 모두 한 장비에 의존한다. 장비가 절전 모드로 전환되거나 오프라인이 되면 에이전트도 멈추고 다른 장비의 환경에 접근할 수도 없다. 슈퍼에이전트는 컴퓨팅과 스토리지를 분리하는 컴퓨터 시스템의 원칙을 세 요소에 두 단계로 적용한다.

1. 컴퓨팅과 상태의 분리: 에이전트 루프 연산은 무상태(stateless) 클라우드 컨테이너에서 실행하고 세션과 영속 상태는 데이터베이스에 저장한다. 컨테이너가 확장되거나 재시작되거나 교체되어도 작업 연속성이 유지된다.
2. 컴퓨팅과 실행 환경의 분리 및 BYOM: 실제 작업 환경에는 커밋되지 않은 로컬 변경사항, 비공개 자격증명, 사내망 서비스 의존성, 특수 하드웨어나 툴체인이 포함되어 있어 클라우드 샌드박스로 복제하고 동기화하기 어렵다. 따라서 에이전트 루프는 클라우드에서 실행하고, 상태를 많이 지닌 실행 환경은 원래 장비에 그대로 둔다. 각 엔드포인트에는 경량 데몬(lightweight daemon)만 설치한다. 이 데몬은 세션 상태를 일절 보관하지 않고 명령 실행과 결과 반환만 수행한다.

이 구조는 앤스로픽의 “Decoupling the brain from the hands”와 같은 접근법이다. 그러나 관리형 서비스가 주로 온디맨드 샌드박스와 고객 VPC 자원을 다루는 것과 달리, 슈퍼에이전트는 개인이 매일 쓰는 개발 장비와 PC를 클라우드 에이전트에 직접 연결하는 BYOM(Bring Your Own Machine) 시나리오를 우선 지원한다. 에이전트는 과제에 따라 여러 실행 장비를 전환하며 명령을 실행하고, 간헐적으로만 온라인이 되는 개인 노트북이 다시 연결되면 대기 중이던 과제를 자동으로 재개해 완수한다.

컴퓨팅, 상태, 실행 환경의 두 단계 분리 구조(온디맨드 샌드박스, 클라우드 워크스테이션, 개인 노트북 BYOM 연결).

6. 외부 Watchdog 세션과 이상 동작 복구

장기 실행 분산 시스템이 내부 로직만으로 신뢰성을 유지하기는 어렵다. 더욱이 에이전트 시스템의 이상 동작은 단순한 프로세스 크래시에 그치지 않는다. 프로세스는 살아 있는데 모델이 비생산적인 루프를 반복하거나 원래 목표에서 이탈하는 현상이 자주 발생한다.

슈퍼에이전트는 이 문제에 대응해 Watchdog 세션을 외부 제어 루프(Control Loop)로 둔다. 주 시스템과 독립적으로 정기 스케줄 메시지에 따라 구동되는 에이전트 세션이다. Watchdog은 API 오류나 상태 복구 실패 같은 인프라 장애를 처리한다. 모델을 사용해 각 Worker가 실질적인 진전을 내고 있는지, 전체 목표에서 이탈하지 않았는지도 판정하고, 일시적인 외부 장애가 해소될 때까지 재점검한다. Watchdog 자체가 전체 도구를 갖춘 에이전트 세션이므로, 운영자는 자연어로 Watchdog에게 장애 원인을 묻거나 실행 중인 주 시스템의 프롬프트와 트리거 규칙을 실시간으로 교정하게 할 수 있다.

7. 예비 실험: 절제 연구와 Router 배칭

예비 실험은 두 가지다. 합성 워크로드와 단순화된 환경에서 전체 시스템의 스케줄링 성능(7.1절)과 Router 계층의 배칭 처리량(7.2절)을 측정했다.²

7.1 종단 간 절제 연구(Ablation Study)

실험에 쓴 이벤트 스트림은 그룹 채팅과 GitHub CI 메시지 약 300건이다. 작업 요청이 약 20건이고 나머지는 일상 대화와 후속 질문, 작업 취소, CI 알림이다. 이 스트림을 네 가지 설계에 똑같이 주입하고 각 설계를 5회씩 반복 실행했다.

네 가지 설계의 누적 작업 요청 도착 및 완료 곡선(5회 실행 평균, 메시지 간격과 작업 시간은 1/4로 축소, 모델 호출 시간은 축소하지 않음).

슈퍼에이전트의 과제 완료 시간은 p50 12.4분, p95 15.7분으로, 단일 세션 기반 설계보다 빠르고 편차가 작았다. 중립 프롬프트(“적절할 때 서브에이전트를 사용하라”)를 쓴 단일 세션은 5회 실행 모두 서브에이전트를 한 번도 호출하지 않았다. 메인 세션이 작업을 직접 수행하는 동안 새 메시지로 작업이 계속 중단되어 p95가 29.5분에 달했다.

위임 우선 프롬프트(“채팅의 모든 메시지가 메인 세션에 도착하므로 직접 실행하면 계속 멈춘다. 각 작업을 전용 서브에이전트에 맡기고 작은 일만 직접 하라”)를 쓴 경우에는 5회 중 4회에서 위임이 이루어졌다. 나머지 1회는 모델이 과제를 “작은 일”로 자체 판단해 직접 실행했고, 이 실행이 그래프의 보라색 긴 꼬리(p95 29.0분)를 만들었다. 프롬프트 엔지니어링과 모델의 즉석 판단에 위임 여부를 맡기는 대신, Router가 직접 과제를 실행하지 못하도록 시스템 구조로 차단하자 완료 시간의 긴 꼬리가 사라졌다.

한편 패스스루를 뺀 슈퍼에이전트의 완료 시간은 p50 12.6분, p95 15.5분으로 비슷했다. 그러나 Router의 의사결정 횟수가 실행당 약 30% 늘면서 전체 캐시 읽기 토큰이 2,320만 개에서 3,180만 개로 약 37% 증가했다. 구독과 패스스루 메커니즘이 Router 세션의 토큰 소모와 추론 부하를 크게 줄인다는 점이 확인된다.

7.2 Router 계층 배칭 스트레스 테스트

두 번째 실험은 장기 실행되는 단일 Router 세션이 자동 배칭으로 어느 정도의 부하를 견디는지 측정했다. Router에는 실제 모델을 연결하고 Worker에는 모의(mock) 모델을 둔 뒤, 의사결정이 필요한 Trigger의 도착률을 분당 약 1건에서 40건까지 단계적으로 높였다.

Trigger 도착률(분당 1~40건)에 따른 평균 배치 크기 B, 요청당 시간 T(초), 의사결정 1건당 분할 상환 추론 시간(초).

Trigger 도착률이 분당 1건에서 40건으로 높아질 때 평균 배치 크기는 1.0에서 2.8로 증가했지만, 요청당 소요 시간은 2.5초에서 3.9초로 늘어나는 데 그쳤다. 그 결과 의사결정 1건에 드는 분할 상환 추론 시간은 6.4초에서 1.6초로 감소했다. 이벤트가 폭주해도 대기열의 이벤트를 자동으로 병합해 처리하므로, 현재 팀 규모의 부하는 샤딩 없이 Router 세션 하나로 충분히 감당한다는 결과다.

8. 미해결 과제 네 가지와 결론

현재의 단순한 설계로도 일상 업무 대부분을 처리할 수 있으나, 시스템을 더 큰 규모와 조직으로 확장하려면 네 가지 과제를 풀어야 한다.

• 8.1 두 계층 아키텍처의 확장: 단일 Router 세션의 처리 한계를 초과하는 대규모 강결합 과제에서 Router 샤딩 시점과 세분화 수준, 동료 Worker 간 직접 통신 토폴로지가 아직 정립되지 않았다. 이벤트 판정과 배치 단위 배분, 맥락 회수에 특화해 모델을 학습시키는 시스템과 모델 공동 설계, 수개월 이상 가동 시의 장기 메모리 병목 해결도 필요하다.
• 8.2 세션 없는 상호작용 설계: 실행 세션이 인터페이스 대화창과 1대1로 대응하지 않게 되면서 과제를 사용자에게 어떻게 보여줄지, 자율 백그라운드 실행 도중 사람이 핵심 세부사항에 실시간으로 개입하거나 인수하는 UX를 어떻게 설계할지가 새로운 제품 과제가 된다.
• 8.3 컨텍스트 경계와 A2A 협업: 개인과 소규모 팀에서 조직 단위로 적용 대상을 확장할 때 어느 맥락을 공유하고 격리할지 경계를 정해야 한다. 기반 맥락을 공유하지 않고 권한 경계가 서로 다른 에이전트 인스턴스(개인 에이전트와 팀 공유 슈퍼에이전트 등) 사이의 안전하고 신뢰성 있는 통신 방식(A2A)이 필요하다.
• 8.4 보안과 프라이버시: 클라우드 Agent Loop는 외부의 비신뢰 입력을 계속 받아들이는 반면 엔드포인트 장비(BYOM)는 비공개 코드와 자격증명을 보유한다. 서버 침해나 프롬프트 인젝션이 연결된 모든 장비의 장악으로 이어지지 않게 막는 방어가 필요하고, 모델 컨텍스트에 자격증명 원문을 노출하지 않은 채 자격증명을 사용하는 메커니즘도 필수적이다.

이번 슈퍼에이전트 설계는 새로운 이론을 내세우지 않는다. 두 계층 라우팅, Fast/Slow Path, 캐시 지역성과 Inline & Spill, 추측 실행, 전이중 비동기 루프, 컴퓨팅과 스토리지의 분리, 외부 Watchdog처럼 컴퓨터 시스템 분야에서 오랫동안 검증된 엔지니어링 기법들을 에이전트 아키텍처에 그대로 이식했다. 개별 과제마다 사람이 일일이 개입할 일이 줄어든 뒤에는, 여러 과제의 맥락을 사람이 직접 챙기는 부담이 전체 생산성을 제약한다. 세션 관리와 맥락 동기화라는 번거로운 작업을 시스템 아키텍처가 대신 처리할 때, 에이전트는 지시를 기다리는 대화창에 머물지 않고 디지털 작업 환경에 상주하는 자율 협업자로 작동한다.

가장 흥미로운 지점

7.1절의 절제 연구에서 단일 세션 에이전트에 위임 우선 프롬프트를 줬는데도, 5회 중 1회는 모델이 과제를 “작은 일”이라고 스스로 판단해 직접 실행했고 과제 완료 시간의 p95가 29.0분까지 늘었다. 에이전트 시스템을 운영해 보면, 모델의 즉석 판단에 아키텍처 규율을 맡긴 설계가 긴 꼬리 지연과 맥락 오염으로 이어지는 장면을 반복해서 목격한다.

연구진은 Router 세션에서 실행 도구(Bash 등)를 아예 빼 버리고, 후속 스레드 이벤트는 코드로 Worker에 직통 전달(pass-through)했다. 패스스루를 뺀 구성은 토큰을 37% 더 썼다. 이 수치들은 에이전트가 자율적으로 일하게 만들 때 모델의 즉석 판단부터 믿기보다, 모델이 직접 판단하지 못하도록 시스템 구조로 고정할 경계를 먼저 정해야 한다는 점을 보여준다.

출처

• 저자: DeepSeek Harness 팀 (구현 및 집필: Yujia Qiao / 리뷰 및 기여: Huanqi Cao, Zui Chen, Xieting Chu, Tianyi Cui, Shiyuan Feng, Yudong Han, Kexin Liu, Shichun Liu, Gesi Luo, Yifan Shi, Tongrui Xiong, Hanxiang Xu, C.C. Yu, Ziya Zhang, F. Zhou 외)
• 발표일: 2026년 11월 1일
• 원문: Exploring Super-agent Design: Towards a More Autonomous Agent System
• 프로토타입 저장소: deepseek-ai/dsh-superagent-prototype