딥시크, 코딩 작업 병렬 처리하는 슈퍼 에이전트 프로토타입 공개

여러 작업을 동시에 관리하도록 설계된 코딩 에이전트

딥시크의 하네스 팀은 2026년 10월 31일 슈퍼 에이전트 설계를 공개하고, 깃허브 저장소의 작업 요청을 별도의 코딩 세션으로 전환하는 MIT 라이선스 연구용 프로토타입도 함께 선보였다. 개발자가 대화 사이를 오가고 진행 상황을 확인하는 데 쓰는 시간을 줄이면서 여러 작업을 동시에 진행하는 것이 목표다.

팀의 예비 실험에는 약 20건의 작업 요청이 담긴 시뮬레이션 메시지 약 300개가 사용됐다. 슈퍼 에이전트는 12.4분 안에 작업의 절반을, 15.7분 안에 95%를 완료했다. 중립적인 지시를 받은 상태에서 하나의 메인 세션이 보조 에이전트를 사용할 수 있도록 한 비교 시스템은 95% 완료 시점까지 29.5분이 걸렸다.

딥시크의 공개 프로토타입 저장소인 dsh-superagent-prototype은 범위를 좁힌 실용적인 버전을 제시한다. 딥시크 하네스용 번들 형태로 제공되는 이 프로액티브 코딩 에이전트는 깃허브 저장소 하나를 대상으로 한다. 깃허브와 선택적으로 페이슈를 감시하다 권한이 있는 사용자가 작업을 요청하면 작업 항목을 만들고, 원래 대화에서 답한다. 코드 변경을 제안하는 풀 리퀘스트를 올릴 수도 있다.

README는 분명한 경고도 담고 있다. 공개된 코드는 내부 시스템 및 설계 에세이의 일부 내용과 다르다. 제안된 기능 중 일부는 향후 과제로 남아 있으며, 딥시크는 이 공개물을 완성된 제품이 아닌 연구용 코드라고 설명한다.

프로토타입을 관리하는 딥시크 하네스 팀은 README에서 현재 상태를 다음과 같이 밝혔다.

참고용 연구 프로토타입이며, 딥시크 공식 제품이 아닙니다.

개발자는 공개된 코드를 살펴보고 수정해 활용할 수 있다. 핵심 실험은 에이전트가 작업을 어떻게 구성하고, 관련 대화를 어떻게 기억하며, 언제 사람의 개입이 필요한지 어떻게 판단하는지에 관한 것이다.

딥시크가 세션 관리를 보이지 않게 하려는 이유

딥시크의 설계는 자체 작업 과정에서 얻은 관찰에서 출발한다. 한 사람이 동시에 따라갈 수 있는 에이전트 세션은 보통 3~5개에 불과하다. 세션마다 대화 기록이 따로 쌓이기 때문에 개발자는 어떤 작업이 어느 세션에 속하는지, 각 에이전트에 어떤 지시를 내렸는지 기억해야 한다.

하네스는 AI 모델 주변에서 도구, 파일, 대화와 실행을 관리하는 소프트웨어다. 모델은 작업을 추론하고, 하네스는 작업을 모델에 전달하는 방식과 동작 실행 방식을 결정한다. 슈퍼 에이전트는 여러 작업을 조율하는 책임을 주변 소프트웨어에 더 많이 맡긴다.

팀은 대화 간 연속성, 효율적인 병렬 실행, 이벤트에 대한 선제적 대응, 장애 복구를 포함한 지속적 운영이라는 네 가지 목표를 제시한다. 한 사례에서는 개발자가 채팅에서 계획을 선택한 뒤 깃허브 댓글로 이를 변경한다. 시스템은 두 대화를 연결해 같은 작업에 변경 사항을 반영해야 한다.

이번 공개는 딥시크가 10월 3일 하네스 v0.2.1-alpha.1에서 진행한 클로드 코드 확장 기능 호환성 실험에 이은 것이다. 당시 업데이트는 확장 기능을 연결하는 방법을 시험했고, 슈퍼 에이전트는 하네스 자체가 진행 중인 작업을 조율하는 방식을 탐구한다. 위자 치아오는 시스템 구현과 설계 에세이 작성을 담당한 것으로 명시됐으며, 검토 및 논의 참여자로는 15명이 추가로 기재됐다.

라우터 하나가 조율하고 여러 워커가 실행

슈퍼 에이전트는 상주형 라우터와 별도의 워커들에 역할을 나눈다. 라우터는 사람과의 상호작용을 처리하고, 작업 간 공유 정보를 유지하며, 작업을 배정한다. 직접 코딩은 하지 않아 다른 세션이 바쁜 동안에도 조율 역할을 수행할 수 있다.

워커는 개별 작업을 처리한다. 각 워커는 자체 대화 맥락과 실행 도구를 갖춰 버그 조사, 코드 리뷰 대응, 기능 변경을 동시에 진행할 수 있다. 워커는 결과를 라우터에 보고하고, 여러 세션이 각자 사람에게 답하는 대신 라우터가 사람과 소통한다.

딥시크는 라우팅에는 경량 모델로 충분한 경우가 많고, 코드 품질을 좌우하는 작업은 더 강력한 모델에 맡길 수 있다고 설명한다. 워커는 복잡한 작업을 위해 보조 에이전트를 만들 수도 있다. 라우터는 작업 내부의 모든 단계를 계획하는 대신 작업 간 관계를 관리한다.

프로토타입은 작업 항목마다 세션과 디렉터리를 별도로 부여하고, 설정된 한도까지 작업을 동시에 시작한다. 따라서 운영자는 한 번에 시작할 작업량을 제어할 수 있다. 대화 기록을 분리하면 한 작업의 세부 내용이 다른 작업을 밀어낼 가능성이 줄고, 라우터는 전체 상황을 공유된 관점에서 파악한다.

끊임없이 끼어들지 않고 메시지를 작업으로 전환하는 방법

채팅 메시지, 코드 리뷰 댓글, 자동 테스트 결과는 동작을 유발하는 이벤트가 된다. 더 폭넓은 설계에는 이메일과 캘린더 알림도 고려 대상에 포함된다. 지속적 통합(CI)은 변경 후 코드를 빌드하거나 테스트하는 자동 점검을 뜻하며, 에이전트는 그 결과에 대응할 수 있다.

딥시크는 두 단계로 이벤트를 걸러낸다. 먼저 일반 프로그램 규칙으로 출처, 그룹, 권한이 있는 사용자 등을 확인한다. 이어 모델이 맥락과 서면 정책을 바탕으로 남은 후보를 평가한다. 조치가 필요 없는 일상적인 메시지에 모델을 호출하지 않아도 된다.

관련 이벤트는 하나의 풀 리퀘스트 댓글이나 채팅 주제처럼 스레드로 묶인다. 워커가 작업을 맡으면 해당 스레드를 구독한다. 이후 댓글이나 테스트 결과는 라우터가 다시 배정하지 않아도 워커에 직접 전달될 수 있다.

여러 워커가 같은 스레드를 구독할 수도 있다. 같은 풀 리퀘스트를 다루는 워커들이 동일한 업데이트를 받으면 작업에 영향을 주는 변화를 알아챌 수 있다. 워커 하나가 관련 스레드 여러 개를 구독할 수도 있고, 맡은 범위를 벗어난 이벤트를 라우터에 돌려보낼 수도 있다.

먼저 움직이되, 필요할 때만 알린다

딥시크는 내부 슈퍼 에이전트가 이미 상시 실행되며 문제를 재현하고 수정하고, 코드 리뷰에 대응하며, 하네스 자체 개발도 지원한다고 밝혔다. 서면 규칙에 따라 그룹 채팅에서 언급된 버그는 에이전트를 직접 호출하지 않아도 조사할 수 있다.

규칙은 먼저 조용히 조사하도록 한다. 에이전트는 보고된 문제를 재현하고 간단한 해결책을 찾은 뒤 유용한 결과를 제시한다. 한 사례에서는 개발자들이 물결표가 취소선 서식으로 표시되는 문제를 논의하는 동안 에이전트가 이미 수정안을 담은 풀 리퀘스트를 열어둔 상태였다.

하네스 팀은 README에서 운영 원칙을 다음과 같이 설명한다.

사람의 주의는 최대한 적게 쓰고, 가치는 최대한 많이 제공한다.

프로토타입은 권한이 있는 사용자가 요청하거나 팀이 작성한 규칙에서 허용하는 경우에 동작한다. 웹 패널에는 사람의 주의가 필요한 작업 항목이 표시된다. 모든 도구 호출이나 중간 추론이 아니라 결정과 활용 가능한 결과에 인터페이스를 집중시킨다.

이전 맥락과 새 지시를 함께 활용하기

딥시크의 설계는 한 번에 처리할 수 있는 정보량이 제한된 모델의 컨텍스트 창을 캐시처럼 다룬다. 자주 필요한 내용은 가까이에 두고, 길거나 관련성이 낮은 기록은 요청이 있을 때까지 창 바깥에 둔다.

에세이는 이 작업을 인라인과 스필이라고 부른다. 인라인은 가까운 채팅 메시지, 식별자, 짧은 미리보기처럼 유용한 세부 정보를 현재 컨텍스트에 직접 넣는다. 스필은 긴 내용을 다른 곳에 두고 모델이 더 읽을 수 있도록 참조를 남긴다.

리콜 체인은 이런 참조를 연결한다. 이벤트, 스레드, 워커 세션에 고유 식별자를 부여해 에이전트가 현재 메시지에서 논의 내용으로, 다시 관련 워커와 다른 코드 리뷰로 이동할 수 있게 한다. 전체 기록을 반복해서 불러오지 않고도 채널을 넘나들며 이전 작업을 찾아내는 것이 목표다.

딥시크는 더 즉각적인 중단 문제도 다룬다. 긴 명령은 기존 방식의 에이전트가 응답하지 못하게 막을 수 있다. 비동기 메커니즘은 작업을 백그라운드에서 시작하고 결과를 새 이벤트로 돌려보낸다. 사용자는 에이전트에 방향을 바꾸거나 중단하라고 요청하는 등 지시를 계속 내릴 수 있다.

팀은 이 메커니즘이 딥시크 하네스에 구현돼 있지만 기본적으로 활성화되지는 않는다고 밝혔다. 소통 규칙도 채널마다 다르다. 설계상 인스턴트 메시지 답변 하나는 100단어로 제한하고, 풀 리퀘스트와 문서에는 변경 사항과 검증 내용을 더 체계적으로 설명한다.

클라우드 조율과 로컬 컴퓨터 작업의 결합

딥시크는 에이전트를 실행하는 컴퓨팅 환경, 저장된 세션 기록, 명령을 실행하는 장치를 분리한다. 제안된 에이전트 루프는 클라우드 컨테이너에서 실행되고, 세션 상태는 데이터베이스에 저장되며, 경량 로컬 서비스가 명령을 실행하고 결과를 돌려준다.

이 구성은 BYOM(Bring Your Own Machine)을 지원한다. 개발자는 저장소와 도구, 미완성 변경 사항이 있는 기존 컴퓨터를 연결해 모든 것을 새로운 원격 환경으로 옮기지 않을 수 있다. 해당 컴퓨터의 연결이 끊겨도 클라우드 조율 기능은 계속 사용할 수 있으며, 컴퓨터가 필요한 작업은 기기가 다시 연결될 때까지 대기한다.

독립적인 워치독 세션은 장애와 작업 정체를 확인한다. 오류 메시지를 감지하는 데 그치지 않고 모델의 판단을 활용해 워커가 실제로 진척을 내는지, 목표에서 벗어나는지 평가한 다음 필요할 때 복구를 시도한다.

딥시크는 이런 요소들을 더 큰 아키텍처 탐구의 일부로 제시한다. README는 공개 번들과 내부 구현이 다르다고 경고하므로, 개발자는 특정 설계 기능을 전제로 삼기 전에 공개된 코드를 확인해야 한다.

실험에서 측정한 내용

딥시크는 각 실험 구성을 다섯 차례 반복해 슈퍼 에이전트를 이벤트 직접 전달 기능이 없는 버전 및 보조 에이전트를 갖춘 단일 세션 구성 두 가지와 비교했다. 작업 부하에는 합성 메시지와 시간이 오래 걸리는 코딩 작업을 모사하는 도구가 사용됐다. 메시지 간격과 작업 시간은 4분의 1로 축소됐다.

중앙값 12.4분은 작업의 절반이 그 시점까지 완료됐다는 의미다. 95백분위수 15.7분은 작업의 95%가 해당 시간 안에 끝났다는 뜻이다. 중립 지시를 받은 단일 세션의 95백분위수 29.5분과 비교하면 슈퍼 에이전트는 이 측정치를 13.8분, 약 47% 줄였다.

작업 위임 방식이 결과를 설명하는 데 도움이 된다. 중립 지시를 받은 단일 세션은 다섯 차례 실행 모두에서 보조 에이전트를 호출하지 않았다. 위임을 우선하라는 지시를 받았을 때는 네 차례 위임했고, 나머지 한 차례에는 직접 작업을 수행했다. 슈퍼 에이전트는 조율과 실행을 구조적으로 분리한다.

실험은 시뮬레이션된 실행 환경에서 일정 관리와 조율을 평가했다. 실제 코딩 품질, 독립적인 성능 측정치, 활성 사용자 수는 공개되지 않았으며, 팀은 측정 결과를 예비 자료라고 밝혔다. 딥시크는 정식 출시 일정을 제시하지 않았다.

조율 속도가 빨라지는 대신 캐시 토큰 사용량 증가

슈퍼 에이전트는 병렬 처리 과정에서 캐시 입력을 더 많이 사용했다. 캐시된 토큰을 2,323만 개 읽었는데, 단일 세션 구성 두 가지의 605만 개와 1,082만 개보다 많았다. 토큰은 모델이 처리하는 작은 텍스트 단위이며, 캐시 읽기는 이전 요청에서 보관한 입력을 재사용하는 것을 뜻한다.

이벤트 직접 전달을 제거하자 캐시 읽기는 2,323만 개에서 3,177만 개로 약 37% 늘었고, 라우터의 판단 횟수도 약 30% 증가했다. 후속 메시지를 작업을 맡은 워커에 직접 보내면 병렬 설계 내 조율 작업을 줄일 수 있었다.

배치 처리는 라우터가 더 많은 이벤트를 다루는 데 도움이 됐다. 분당 이벤트가 약 1건에서 40건으로 늘면서 평균 배치 크기는 1.0에서 2.8로, 요청 시간은 2.5초에서 3.9초로 증가했다. 라우터의 판단 한 건에 배정되는 추론 시간은 6.4초에서 1.6초로 줄었다.

실무상 절충점은 사람의 대기 시간을 줄이는 대신 여러 세션에서 모델 처리가 늘어난다는 것이다. 토큰 수치만으로 비용을 알 수는 없다. 도입을 검토하는 팀은 모델 가격, 동시 실행 설정, 실제 작업량을 고려해야 한다.

로컬 권한 때문에 보안이 핵심 쟁점

프로토타입 실행 문서에 따르면 워커 명령은 운영체제 계정의 권한으로 승인 없이 실행된다. 포그라운드 셸 명령은 5초가 지나면 백그라운드 실행으로 전환되며, 백그라운드 작업은 한 번의 실행 주기에서 최대 30분 동안 진행된다. 이 설정 때문에 운영자 계정의 권한은 배포 시 구체적으로 따져봐야 할 문제다.

연결된 컴퓨터에는 인증 정보, 비공개 코드, 민감한 파일이 있을 수 있다. 프롬프트 인젝션은 에이전트가 읽는 자료를 통해 악의적인 콘텐츠가 에이전트의 동작을 바꾸려는 공격이다. 수신 메시지나 저장소 콘텐츠가 해당 컴퓨터의 명령 실행에 영향을 줄 수 있다면 특히 심각한 문제가 된다.

딥시크는 보안과 개인정보 보호, 라우터 확장성, 장기간의 메모리 관리, 에이전트 인스턴스 간 통신을 아직 해결되지 않은 과제로 꼽는다. README는 사용자에게 코드를 검토하고 수정해 사용할 것을 당부하며, 버그와 일관되지 않은 엔지니어링 관행이 남아 있을 수 있다고 경고한다. 개발 과정 자체도 상당 부분 코딩 에이전트가 담당했다.

공개 직후 빠르게 관심이 확산됐으며, 허깅페이스 연구 책임자 레안드로 폰 베라의 게시물도 주목을 받았다. 다음 기록은 프로토타입이 얼마나 빠르게 확산됐는지 보여준다.

• 2026년 10월 31일 09:32 UTC: 깃허브 저장소가 생성됐다.
• 10월 31일: 하네스 팀이 설계 에세이를 공개했다. 같은 날 22:10 UTC 기준 저장소는 스타 2,046개와 포크 172개를 기록했다.
• 11월 1일 04:20 UTC: 저장소 스타 수가 3,433개에 도달했다.

엔지니어링 팀이 당장 판단할 사항은 실험 단계의 조율 시스템을 검토해 적용할지 여부다. 장점은 중단을 줄이면서 더 많은 작업을 처리할 가능성이고, 운영 과정에서는 코드 검토와 권한 설정, 사람의 확인이 필요한 조치의 범위를 정해야 한다.

핵심 요점

• 딥시크는 깃허브 저장소 하나의 코딩 작업을 위한 MIT 라이선스 연구용 프로토타입을 공개했으며, 페이슈 연동은 선택 사항이다.
• 라우터가 조율하고 별도의 워커들이 작업을 병렬로 실행한다.
• 내부 시스템은 서면 규칙에 따라 직접 호출되지 않아도 보고된 버그를 조사할 수 있다.
• 합성 테스트에서 작업 완료 시간은 중앙값 12.4분, 95백분위수 15.7분이었다. 캐시 토큰 사용량은 단일 세션 대안보다 많았다.
• 워커는 승인 없이 운영자 계정으로 명령을 실행하므로 권한과 인증 정보 관리가 중요하다.
• 공개 코드는 내부 시스템과 다르며, 딥시크 공식 제품이 아닌 연구용 프로토타입으로 남아 있다.