dsh-superagent 공개 내용 정리: 시키지 않은 일은 기록만 하는 코딩 에이전트

DeepSeek 의 GitHub 계정에 dsh-superagent-prototype 이라는 저장소가 2026년 10월 31일 만들어졌습니다. 팀의 요청을 받아 PR(코드 변경 제안)로 답하는 코딩 에이전트의 연구용 시제품입니다. 공식 문서가 가장 앞에 둔 기준은 사람의 주의를 가장 적게 쓰고 가치는 가장 많이 주는 것입니다.

저희는 이 도구를 아직 직접 써 보지는 않았습니다. 이 글은 2026년 11월 4일 기준 공식 README·docs·SETUP 문서를 읽고 정리한 것입니다. 성능 평가와 측정값은 없습니다. 마지막의 '우리 일에 붙인다면' 절은 공식 문서의 주장이 아니라 저희의 판단입니다.

코딩 에이전트 도입을 검토하는 팀이라면 이 문서에서 볼 곳은 권한과 알림 설계라고 봅니다. 납품 현장에 바로 넣을 제품은 아닙니다. 그 이유는 공식 문서가 먼저 적어 두었습니다.

연구용 시제품이라고 먼저 밝힌 저장소

README 맨 앞의 안내부터 옮깁니다.

참고용 연구 시제품이며 DeepSeek 공식 제품이 아닙니다

운영 수준 소프트웨어로 보지 말고, 검토하고 수정해서 쓰라고 적혀 있습니다

내부 버전과 같지 않습니다

글 'Exploring Super-agent Design' 에 나온 설계 중 일부는 구현되어 있지 않습니다

정체는 GitHub 저장소 하나를 맡는 능동형 코딩 에이전트입니다. 라이선스는 MIT 이고, DeepSeek Harness 묶음으로 배포됩니다. GitHub 에서 오는 요청을 받아 움직이고, 팀 채팅 서비스 Feishu 연동은 선택입니다.

공개 직후의 시제품이라 동작이 금방 바뀔 수 있습니다. 이 글의 내용도 11월 4일 기준으로 읽어 주시기 바랍니다.

요청 하나가 PR 로 답하기까지

공식 문서의 흐름을 순서대로 적으면 다음과 같습니다.

허용된 사람이 요청합니다. 목록에 없는 사람이 불러도 기본값은 무시입니다

에이전트가 작업 항목을 엽니다

작업마다 'worker-<ticket id>' 세션과 전용 디렉터리가 생기고, 그 안에서 일합니다

요청이 들어온 원래 대화에 PR 같은 결과로 답합니다

사람이 보는 화면은 웹 패널입니다. 패널은 사람이 필요한 것을 먼저 보여 줍니다. 사람이 답해야 하는 일이 생겼을 때만 패널 맨 앞으로 올라오는 구조입니다.

메시지 하나도 사람의 주의를 쓴다고 봅니다

철학 문서(docs/000)의 원칙은 사람의 주의는 최소로, 가치는 최대로입니다. 메시지·알림·질문·설정 하나하나가 주의를 쓰므로, 각각이 그보다 값어치가 있어야 한다고 적습니다. 여기서 나오는 규칙은 네 가지입니다.

움직이는 조건: 요청받았거나 팀이 쓴 규칙이 허용할 때만 움직입니다

시키지 않은 일: 팀이 쓴 규칙이 필요하고, 하려던 일을 기록만 하는 모드로 시작합니다

말하는 조건: 사람이 움직여야 하거나 결과를 쓸 수 있을 때만 말합니다. 질문은 한 번에 하나, 구체적으로 합니다

멈추는 기준: 일의 양이 아니라 영향입니다. 설계 판단이 필요한 변경은 질문과 함께 멈춥니다

네 번째 규칙은 변경 규모만으로 멈출지를 정하지 않는다는 뜻으로 읽힙니다. 변경이 작아도 설계 판단이 필요하면 사람에게 묻는다는 것입니다.

두 번째 규칙의 기록만 하는 모드는 에이전트가 무엇을 하려 했는지를 사람이 기록으로 먼저 볼 수 있게 합니다. 자동으로 움직이는 범위는 그 기록을 본 뒤에 정할 수 있습니다.

자동화를 넓히면서 사람이 보는 단계를 어디에 남길지는 저희도 고민한 문제입니다. SNS 게시 자동화를 AI 에이전트에서 프로그램으로 옮기면서도 검토 단계는 남겨 두었습니다.

메시지는 권한을 바꾸지 못합니다

권한 문서(docs/002)는 에이전트가 받는 입력을 두 종류로 나눕니다.

코딩 에이전트는 이슈 댓글과 문서를 읽으면서 일합니다. 문서의 규칙대로라면 댓글에 '이 작업은 승인됐다'고 적혀 있어도 권한은 그대로입니다. 그 문장은 판단에 참고하는 재료일 뿐입니다. 위 예시 문장은 저희가 든 것이고, 공식 문서의 문구는 아닙니다.

목록에 없는 사람이 불렀을 때의 기본값도 무시입니다. 요청하는 사람을 확인하는 일과 요청 내용을 읽는 일을 처음부터 나눠 둔 설계로 읽힙니다.

권한을 어느 층에서 정할지는 저희도 한 번에 정하지 못한 문제입니다. 같은 날 설계를 바꾼 기록을 남겨 두었습니다.

승인 없이 실행한다는 문장

실행 문서(docs/003)에서 도입 검토자가 가장 먼저 볼 문장은 이것입니다. 실행 세션은 운영자 OS 계정으로 승인 없이 명령을 실행합니다. 누구의 요청을 받을지는 엄격하게 정하지만, 받은 뒤의 명령에는 사람의 승인 단계가 없습니다.

실행 문서의 나머지 수치는 작업 중에도 사람의 메시지를 받을 수 있게 하는 설정으로 읽힙니다.

포그라운드 셸 명령은 5초 뒤 백그라운드로 옮겨 새 메시지를 받을 수 있게 합니다

턴이 끝난 뒤 백그라운드 작업은 최대 30분까지입니다

동시 실행 상한에는 사람 메시지를 위한 여분 칸이 하나 더 있습니다

5초와 30분은 문서에 적힌 값입니다. 저희가 측정한 값이 아닙니다.

설치 전에 확인할 조건

SETUP.md 는 단계가 많아서 코딩 에이전트에게 이 문서를 읽혀 함께 설치하는 방식을 안내합니다. 필요한 것은 다음과 같습니다.

실행 환경: Node.js 22.19+ 또는 24+, pnpm, git 2.32+, tmux, Python 3.8+, GitHub CLI 2.48+, DSH

모델 제공자

에이전트용 GitHub 계정: 운영자 본인 계정이 아닌 전용 계정을 권장합니다

팀 채팅 연동은 기본이 Feishu 입니다. 다른 메신저를 쓰는 팀은 docs/008 Cookbook 의 'adding a Source' 항목을 보고 직접 붙여야 합니다.

우리 일에 붙인다면: 여기부터는 저희의 판단입니다

이 절은 공식 문서의 주장이 아닙니다. 공식 자료를 읽고 저희가 판단한 내용입니다. 직접 실행해 확인한 결과도 아닙니다.

시스템 개발·SI 납품에서는 유지보수 요청을 이슈로 받아 PR 초안을 내는 자리에 어울린다고 봅니다. 다만 승인 없이 실행하는 구조라 고객 저장소에 바로 붙이는 것은 권하지 않습니다. 운영자 OS 계정으로 실행되므로 격리 환경 없이 실행하면 위험하다고 판단합니다. 자체 저장소에서 기록만 하는 모드로 먼저 보는 순서가 맞습니다.

도구를 쓰지 않더라도 그대로 가져올 만한 문장은 둘입니다.

메시지 내용은 권한을 바꾸지 못한다

시키지 않은 일은 기록만 하며 시작한다

AI 도입을 맡은 분이라면 어떤 코딩 에이전트를 고르든 아래 항목을 먼저 정해 둘 수 있습니다.

에이전트를 부를 수 있는 사람의 허용 목록을 시스템 설정으로 관리할 수 있습니까

시키지 않은 일의 규칙을 팀이 글로 적어 두었습니까

기록만 하는 모드로 먼저 시작할 수 있습니까

어떤 경우에만 사람에게 알릴지 기준을 정했습니까

운영자 계정과 분리된 전용 계정과 격리 환경을 준비했습니까

지금 읽을 수 있는 것은 설계 문서입니다

dsh-superagent 는 공식 문서가 스스로 연구용 시제품이라고 밝힌 도구이고, 저희는 아직 써 보지 않았습니다. 그래서 이 글에는 성능 평가가 없습니다. 지금 쓸모 있는 것은 권한과 알림을 어떻게 나눴는지 적은 문서입니다. 허용 목록, 기록만 하는 모드, 알림 기준 세 가지는 도구를 설치하기 전에 문서로 먼저 적어 볼 수 있습니다.