DeepSeek가 라우터 하나에 워커 세션을 여럿 붙여 사람 개입을 줄인 Super-agent 설계를 공개했습니다 | DAKER 커뮤니티

DeepSeek의 에이전트 개발 조직 DeepSeek Harness가 사람의 개입을 최소로 줄인 코딩 에이전트 설계 'Super-agent'를 공개했습니다. 한국 시각 2026년 11월 1일 오후 8시 37분, 공식 X 계정에 설계 글 「Exploring Super-agent Design: Towards a More Autonomous Agent System」을 올렸고, 같은 시기에 MIT 라이선스 연구용 프로토타입 dsh-superagent-prototype을 GitHub에 공개했습니다. 제품이 아니라 연구 프로토타입이라는 점을 분명히 했습니다. 이 글은 2026년 11월 3일 오전에 DeepSeek 공식 X 글과 GitHub 저장소를 확인하고 정리했습니다.

해질녘 사무실에서 여러 작업 창이 띄워진 모니터를 바라보는 개발자 실사풍 장면 모션 미리보기
설명을 돕기 위해 만든 생성 이미지입니다.
해질녘 사무실에서 여러 작업 창이 띄워진 모니터를 바라보는 개발자 실사풍 장면
설명을 돕기 위해 만든 생성 이미지입니다.

무엇을 풀려고 했나

DeepSeek 팀은 지금의 주류 에이전트가 '세션 하나'를 기본 단위로 삼는다고 지적합니다. 사람이 동시에 지켜볼 수 있는 세션은 3~5개 정도라서, 모델 성능이 아니라 사람의 주의력이 여러 작업을 동시에 돌리는 데 병목이 된다는 것입니다. 그래서 "사람의 주의는 최대한 적게 쓰고, 가치는 최대한 많이 준다"는 원칙을 세웠습니다. 에이전트는 요청을 받으면 한 번 확인하고, 일하는 동안에는 조용히 있다가 결과나 질문, 실패가 있을 때만 다시 말을 겁니다.

라우터와 워커로 나눈 구조

설계는 두 층으로 나뉩니다. 오래 살아 있는 라우터(Router)가 대화와 작업 배분을 맡고, 서로 격리된 워커(Worker) 세션이 실제 작업을 합니다. 프로토타입에서는 흐름이 다음처럼 구체화돼 있습니다.

  1. GitHub나 선택적으로 Feishu에서 이벤트가 들어옵니다.
  2. 평가 단계에서 이 이벤트 묶음이 새 작업 요청인지 판단합니다.
  3. 허가된 작업은 '티켓'이 되고, 진행해도 되는 이유를 바꿀 수 없는 형태로 기록합니다.
  4. 티켓마다 별도 세션과 디렉터리에서 워커가 일하고, 결과는 주로 풀 리퀘스트로 원래 대화에 돌아갑니다.

요청하지 않은 일을 먼저 하는 기능은 기본적으로 '관찰' 모드로 꺼져 있습니다. 이 모드에서는 받아들였을 작업을 기록만 하고, 팀이 직접 켜야 자동으로 움직입니다. 설계 글은 프로토타입 밖의 아이디어로 외부 감시 장치(Watchdog), 저장과 연산 분리, 비동기 ReAct 루프도 제시했습니다.

이 설계가 기존 방식과 다른 점

지금 많이 쓰는 방식은 사람이 세션을 하나 열고, 그 안에서 에이전트가 하위 에이전트를 불러 일을 나누는 구조입니다. 이 경우 세션이 늘어날수록 사람이 화면을 오가며 진행 상황을 확인해야 합니다. Super-agent는 반대로 사람과 대화하는 창구를 라우터 하나로 모으고, 실제 작업은 보이지 않는 곳에서 워커가 나눠 맡게 했습니다. 사람은 여러 세션을 지켜보는 대신 라우터가 돌려주는 결과와 질문에만 답하면 됩니다.

또 하나의 차이는 작업을 받아들인 근거를 남긴다는 점입니다. 티켓에는 왜 이 일을 시작해도 되는지가 바꿀 수 없는 형태로 기록되므로, 나중에 에이전트가 왜 이런 풀 리퀘스트를 만들었는지 거슬러 올라가 확인할 수 있습니다. 자동으로 움직이는 에이전트를 팀에 들일 때 가장 먼저 나오는 걱정인 책임 소재 문제를 설계 단계에서 다룬 셈입니다. DeepSeek는 성능 수치를 내세우기보다 연구용 프로토타입이라는 점을 앞세웠고, 실제 효과는 각 팀이 자기 환경에서 확인해야 합니다.

써 보려는 팀이 알아둘 점

프로토타입은 TypeScript로 만든 v0.1.0 번들이며, DeepSeek Harness 프로필 위에서 내 컴퓨터에 직접 돌립니다. Node.js, git, Python, tmux, GitHub CLI가 필요하고, 저장소 하나를 대상으로 동작합니다. 운영체제 사용자 권한을 그대로 쓰기 때문에 시험하려면 별도 계정이나 격리된 환경에서 돌리는 편이 안전합니다.

국내에서 Claude Code나 Codex로 여러 작업을 동시에 맡기다가 세션 관리에 지친 팀이라면, 이 설계가 던지는 질문이 유용합니다. 에이전트 수를 늘리는 것보다 사람이 언제 개입해야 하는지를 먼저 정하는 것이 생산성을 좌우한다는 점입니다. 사내 메신저 요청을 티켓으로 바꾸고 결과만 알려 주는 구조는 국내 협업 도구에도 옮겨 볼 수 있습니다.

원문은 아래에서 확인할 수 있습니다.