DeepSeek 자율 코딩 에이전트, 모델보다 권한표를 먼저 공개했다

딥시크가 저장소 하나를 맡아 스스로 일하는 코딩 에이전트를 공개했습니다. 저장소 이름은 dsh-superagent-prototype, 라이선스는 MIT, 공개일은 2026년 10월 31일입니다.

허용된 사람이 일을 시키면 작업 항목을 열고, 자기 세션과 자기 디렉터리에서 처리한 뒤 원래 대화에 풀 리퀘스트로 답합니다. 사람이 판단해야 할 일만 웹 패널에 남깁니다.

이 글에서 볼 것은 모델 성능이 아닙니다. 누가 언제 에이전트에게 일을 시킬 수 있는지를 표와 상태로 못 박아 둔 부분입니다. 팀에 코딩 에이전트를 붙이려는 쪽이 바로 참고할 수 있는 설계입니다.

모델이 아니라 운영 규칙을 공개했다

저장소 설명은 첫 줄에서 선을 긋습니다. 참고용 연구 프로토타입이고 공식 제품이 아니며, 상당 부분을 코딩 에이전트가 직접 작성했기 때문에 버그와 일관성 문제가 남아 있다고 밝힙니다.

논문 제목은 Exploring Super-agent Design입니다. 저장소는 그 논문의 구현 전체가 아니라, 팀이 실제로 쓰는 형태에 맞춰 각색한 판본이라고 밝힙니다. 논문에 있는 설계 가운데 일부는 앞으로의 방향으로만 남아 있습니다.

구조는 딥시크 하네스(DeepSeek Harness)용 번들입니다. 깃허브를 듣고, 선택적으로 페이수(Feishu) 메시지도 받습니다. 설정은 에이전트가 함께 합니다. 저장소의 SETUP.md를 읽고 사용자와 같이 설치하라는 안내가 README에 있습니다.

문서는 000 철학부터 008 요리책까지 번호 순서로 읽게 되어 있습니다. 각 문서가 앞 문서만 전제로 쓰였습니다. 읽는 사람이 아직 소개되지 않은 개념을 먼저 만나지 않게 하려는 구성입니다.

설치 난이도는 저장소도 인정합니다. 단계가 많아서 사람 대신 에이전트가 같이 하게 만들었고, 한 번에 질문 하나씩 받은 뒤 계획 전체를 보여주고 설치합니다. 검사는 pnpm check 하나로 타입 검사와 테스트, 빌드를 함께 돌립니다.

핵심은 권한표다

가장 눈에 띄는 문서는 권한(002 Authorization)입니다. 요청은 에이전트를 직접 부르고, 팀이 허용한 사람이 보낸 것만 요청으로 인정합니다. 허용 목록에 없는 사람의 말은 요청이 아니라 후보로 분류됩니다.

그 아래에 수락 표가 있습니다. 행은 메시지가 들어오는 범위(새 이슈, 새 풀 리퀘스트, 댓글, 기본 브랜치의 CI 결과, 페이수 대화방)이고, 칸은 그 메시지를 명시적 요청으로 볼지, 후보로만 볼지, 무시할지를 정합니다.

수락 모드는 세 단계입니다. 꺼짐, 관찰, 자동입니다. 기본값은 관찰이고, 이 모드에서는 후보를 평가만 해서 "받았을 것"으로 기록하고 실제로는 아무것도 수락하지 않습니다. 기록을 보고 나서 자동으로 넘기는 순서를 전제로 만든 장치입니다. 도입 첫 주의 실제 작업은 이 기록을 읽는 일입니다.

수락되면 위임(Mandate)이 생깁니다. 어떤 규칙에 걸려 수락됐는지, 어느 정책 버전에서 수락됐는지가 함께 기록됩니다. 정책이 바뀌면 진행 중이던 평가는 버려지고 대기 중인 요청이 다시 큐에 들어갑니다.

봇은 별도 취급입니다. dependabot[bot] 같은 봇은 후보만 만들 수 있고 명시적 요청이나 중단은 못 합니다. 자동 리뷰어가 평범한 계정을 쓰면 시스템은 그를 사람으로 봅니다. 그래서 팀 프롬프트에 그 계정이 자동이라는 사실을 적어 두어야 합니다.

중단과 재개도 규칙으로 정해져 있다

스레드에 “그만”이라고 쓴 것은 명령이 아니라 보통 요청으로 들어가서 판정을 거칩니다. 패널에서 누르는 정지는 명령으로 처리되고 수동 중단으로 기록됩니다. 같은 뜻의 말이 경로에 따라 다르게 다뤄지는 셈입니다.

끝난 작업은 위임을 잃지 않습니다. 그 스레드에 사람이 다시 말을 걸면 새 판정 없이 같은 작업이 재개됩니다. 다만 재개 전에 조건을 다시 확인합니다. 보낸 사람이 아직 허용 목록에 있는지, 그 규칙이 아직 켜져 있는지, 소스가 그 스레드를 계속 듣고 있는지를 봅니다. 하나라도 어긋나면 작업은 끝난 채로 남습니다.

구독은 권한을 주지 않습니다. 구독한 스레드의 모든 메시지는 맥락으로 전달되지만, 봇 메시지와 CI 결과까지 포함해 새 권한을 만들지 않습니다. 이 구분이 없으면 알림이 쌓이는 만큼 에이전트 권한도 함께 불어납니다. 권한이 조용히 넓어지는 경로를 미리 막아 둔 셈입니다.

조용한 에이전트를 만드는 다섯 규칙

철학 문서의 원칙은 한 줄입니다. 사람의 주의를 최소로 쓰고 가치를 최대로 내라는 것입니다. 여기서 다섯 가지 행동 규칙이 나옵니다.

첫째, 시킨 일만 합니다. 아무도 시키지 않은 일은 팀이 쓴 규칙이 있어야 하고, 그마저도 무엇을 했을지 기록만 하는 모드에서 시작합니다. 둘째, 사람이 판단해야 하거나 결과를 쓸 수 있을 때만 말합니다. 요청을 한 번 확인하고, 작업 중에는 조용히 있고, 결과가 나왔을 때 다시 씁니다.

셋째, 한 번에 질문 하나를 구조화된 형식으로 던집니다. 긴 보고서 안에 질문을 묻어 두면 담당자에게 도달하지 않기 때문입니다. 넷째, 노력이 아니라 영향으로 멈춥니다. 국소적인 변경은 리뷰 가능한 결과까지 가고, 설계 판단이 필요한 변경은 질문을 남기고 멈춥니다.

다섯째, 정직하게 보고합니다. 초안은 미완성으로 표시하고, 실패는 실패로 적고, 질문을 피하려고 한계를 우회하지 않습니다.

도입 전에 정할 것

문서는 운영자 책임을 따로 적습니다. 에이전트가 다는 댓글과 풀 리퀘스트는 팀이 매일 보는 계정으로 나가고, 그 메시지의 값은 동료의 주의입니다.

그래서 짧은 허용 목록으로 시작하고, 선제 작업은 기록만 하게 두라고 권합니다. 에이전트가 했을 일이 맞아 보이면 그때 목록과 범위를 넓힙니다.

시끄러울 때의 처방도 적혀 있습니다. 설명 메시지를 더 붙이지 말고 프롬프트를 짧고 엄격하게 바꾸거나 잠시 멈추라고 합니다. 부피를 만드는 용도로 쓰지 말라는 항목도 있습니다. 대량 풀 리퀘스트와 방송형 메시지는 팀에 주는 것보다 빼앗는 것이 큽니다.

이 저장소를 오늘 바로 운영에 넣을 수는 없습니다. 연구 코드이고, 논문에서 다룬 설계 중 일부는 프로토타입에 구현되지 않았습니다. 대신 팀에 에이전트를 붙일 때 무엇을 먼저 정해야 하는지 순서를 보여주는 참고서로 값이 있습니다.

사내 저장소에 붙일 때 가장 먼저 정할 것도 이 순서입니다. 누가 시킬 수 있는지, 어떤 범위의 메시지를 요청으로 볼지, 처음 몇 주를 기록만 하는 모드로 둘지입니다. 모델을 고르는 일은 그다음입니다.

에이전트 도입의 성패는 모델 성능보다 권한과 침묵의 설계에서 갈립니다.

원문 보기 - dsh-superagent-prototype

이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.