DeepSeek dsh-superagent: 저장소별 작업, 명시적 권한 경계

1. 저장소 하나에서 일하고 웹 패널로 사람을 부른다

dsh-superagent는 에이전트 실행 기반인 DeepSeek Harness용 묶음이다. GitHub의 요청을 받고 선택적으로 협업 도구 Feishu도 연결한다. 작업마다 독립된 대화 세션과 폴더를 마련해 진행하고, 코드 변경을 검토받는 풀 리퀘스트, 코드 변경 검토를 요청하는 방식 등으로 결과를 돌려준다. 웹 패널에는 사람이 답하거나 검토해야 할 항목이 모인다.

설치는 코딩 에이전트에게 저장소의 SETUP.md를 읽고 함께 설정해 달라고 요청하는 방식이다. 에이전트가 질문을 하나씩 하고 전체 계획을 보여 준 다음 설치와 구성을 진행한다. 팀은 요청을 받을 대상과 작업을 시작할 규칙을 정해 운영할 수 있다.

2. 허용 목록과 규칙이 작업의 시작을 통제한다

작업을 시작할 권한과 허용 범위는 에이전트를 실행하는 시스템이 관리하는 허용 목록, 규칙, 작업별 권한 기록으로 정해진다. 댓글은 업무 자료이고 허용 목록은 출입 명부인 셈이다. 허용된 사람이 에이전트를 지목하면 명시적 요청이 된다. 목록 밖 사람의 지목 요청도 대화 범위별 설정으로 명시적으로 허용할 수 있다. 그 밖의 사람이나 등록된 봇의 메시지는 설정에 따라 검토 후보가 되거나 무시된다.

이미 시작된 작업의 대화는 별도 경로로 작업자에게 전달될 수 있다. 이 전달은 문맥을 보태지만 권한을 늘리지 않는다. 작업자는 맡은 범위에서 처리하거나 범위를 벗어난 요청을 돌려보낸다. 봇과 자동 검사 결과는 기존 작업에 문맥으로 전달될 수 있지만 종료된 작업을 다시 깨우지는 않는다.

3. 자동 시작은 평가 모드와 팀 규칙으로 조절한다

규칙에 따른 자율 작업은 기본적으로 관찰부터 시작한다. 기본 모드에서는 검토 후보의 평가 결과를 기록하되 작업을 자동으로 시작하지 않는다. 팀은 기록을 살펴본 뒤 자동 모드로 전환할 수 있다. 명시적으로 허용된 요청은 어느 모드에서든 처리된다.

자동 모드에서 후보를 승인하려면 활성화된 규칙을 각각 평가하고 하나 이상이 맞아야 한다. 규칙은 시작 여부뿐 아니라 작업 방식도 정한다. 예를 들어 검토 규칙에는 코드를 병합하기 전 필요한 검토자와 승인을 담을 수 있다. 관련 없는 대화처럼 규칙에 걸리지 않는 것이 명백한 후보는 상세 평가 없이 무시할 수 있다.

정책 버전에는 규칙과 자동 시작 모드, 소스별 정책이 포함된다. 정책이 바뀌면 진행 중인 평가를 다시 대기시키며, 영향받는 작업에는 변경 알림을 보낸다. 이미 진행 중인 작업의 권한은 정책 변경만으로 바로 취소되지 않지만, 종료된 작업을 재개하기 전에는 현재 정책에 맞는지 다시 확인한다.

4. 작업은 분리된 세션에서 진행하고 조건에 따라 재개한다

작업마다 전용 세션과 폴더를 쓰며, 폴더가 아직 없으면 설정된 준비 명령을 한 번 실행한다. 준비 명령에는 10분 제한이 있고, 흔한 설정은 git worktree, 작업 폴더를 따로 만드는 Git 기능을 이용해 체크아웃을 만드는 방식이다. 준비 명령이 없으면 빈 폴더에서 시작한다.

내부 구조는 요청을 받아 정책과 평가를 거쳐 작업 실행에 연결하는 방식으로, 아래는 원문 구조도의 앞 10줄을 그대로 발췌한 것이다.

flowchart TB
  plugins[Source plugins] -->|SourceContext| engine
  tools[Session tools] --> engine
  http[Management routes] --> engine
  engine[Engine] -->|Repositories| store[Store]
  engine -->|Policy| policy[Policy]
  engine -->|SourceScope| registry[SourceRegistry]
  engine -->|Assessor| assessor[MasterAssessor]
  engine -->|Executor| executor[DshExecutor]
  assessor -->|decide| engine

사람이 해당 작업의 대화에 후속 메시지를 보내면 종료된 작업도 이어질 수 있다. 재개 전에는 원래 대화가 여전히 수신 대상인지 확인하고, 승인 근거에 따라 현재 허용 목록과 규칙 등을 다시 점검한다. 재검증에 실패하면 권한이 철회되고, 기다리던 메시지는 다른 작업이 맡고 있지 않은 경우 새 평가로 돌아간다.

중단 방식도 나뉜다. 대화에서 사람이 멈추라고 말하면 일반 메시지처럼 평가를 거치고, 패널의 멈춤 기능은 해당 작업을 직접 중단한다. 사람이 중단한 작업은 새 승인 없이 재개되지 않는다.

5. 주의 부담은 줄지만 정책 운영 책임이 생긴다

에이전트가 요청을 먼저 분류하고 작업별 공간에서 처리하면 사람이 매번 착수시키는 부담을 낮출 수 있다. 대신 팀의 역할은 개별 요청 처리에서 허용 대상과 규칙의 관리, 평가 기록의 검토로 옮겨간다. 관찰 모드, 자동 실행 없이 평가만 기록하는 방식은 어떤 요청을 자동으로 맡겨도 될지 팀이 판단할 기회를 준다.

다만 작업자는 운영자 계정으로 명령을 승인 없이 실행하며, 전용 폴더나 명령 연결 설정은 보안 격리 장치가 아니다. 저장소는 공식 제품이 아닌 연구용 프로토타입으로 공개됐으며, 버그 가능성과 내부 버전과의 차이를 알리고 도입 전 검토와 환경별 조정을 권한다.

이 프로토타입의 도입 가치는 자율 실행을 늘리는 것보다, 팀이 맡길 일의 범위와 시작 권한을 먼저 설계할 수 있다는 데 있다.