DeepSeek Super Agent를 안전하게 설정하는 방법: 계정, 권한 및 격리

평소 사용하는 계정으로, 또는 중요한 프로덕션 저장소를 대상으로 dsh-superagent 실험을 시작하지 마세요. 배포 문서에 따르면 라우터와 워커 프리셋은 모두 운영 체제 사용자 계정으로 danger-full-access 권한을 사용하며 해당 사용자의 홈 디렉터리를 읽을 수도 있습니다. 예기치 않은 동작이 발생한 뒤가 아니라, 설치와 테스트를 시작하기 전에 전용 계정과 임시 저장소를 준비해야 합니다.

공개 저장소의 코드는 연구용 프로토타입이며, DeepSeek의 공식 프로덕션 준비 완료 제품이 아닙니다. 이 가이드에서는 문서에 명시된 기본 설정을 바탕으로 신중한 설정 계획을 제시합니다. 별도의 사용자 계정, 제한된 저장소 접근 권한, 검토된 작업 허용 규칙, 통제된 실행, 테스트를 거친 중지 절차가 이에 포함됩니다. 자격 증명은 승인된 본인 소유의 터미널이나 비밀 정보 관리 워크플로를 통해서만 입력하고, 채팅 대화에는 절대 입력하지 마세요.

dsh-superagent는 프로덕션에 사용할 준비가 되었나요?

README에는 이 코드가 연구용 코드이며, 공개된 구현은 내부 시스템 및 관련 설계 문서의 일부 아이디어와 다르다고 명시되어 있습니다. 배포 여부를 결정할 때 이 점을 중요하게 고려해야 합니다. 코드를 공개적으로 이용할 수 있다는 것은 설계를 살펴볼 기회이지, 민감한 작업에 사용할 준비가 되었다는 보장은 아닙니다.

이 가이드는 2026년 11월 5일에 리비전 8c32a9dc5d72c033816c6a8110b37f40cf94fba4를 기준으로 확인했습니다. 실제로 검토한 리비전을 고정하고 기록하세요. 이후 체크아웃을 업데이트한다면 다시 실행하기 전에 필수 조건, 권한, 프리셋, 설정 마이그레이션을 재확인하세요.

설정 문서에는 대화형 계획 수립 및 확인 워크플로가 설명되어 있습니다. 실행 전에 계획을 검토하세요. 코딩 에이전트에 설정을 도와달라고 요청하라는 지침을, 관련 없는 자격 증명에 접근하거나 일반 작업 프로필에 설치해도 된다는 허가로 받아들이지 마세요.

첫 번째 승인 기준은 소박해야 합니다. 무해한 요청 하나로 이해하기 쉬운 작업과 검토 가능한 결과물이 임시 저장소에 생성되는지 확인하세요. 거부 및 중지 동작도 테스트하세요. 정상 경로의 성공적인 시연만으로는 프로덕션 환경의 안정성이 입증되지 않으며, 즉시 접근 권한을 확대해도 된다는 근거도 되지 않습니다.

전용 운영 체제 계정을 사용해야 하는 이유

배포 가이드에는 호스트 접근에 관한 가정이 명시되어 있습니다. 세션 디렉터리와 자격 증명 래퍼를 분리해도 프로세스가 격리되지는 않습니다. 워커는 워커를 실행하는 계정에 허용된 프로그램을 실행하고 파일에 접근할 수 있으며, 해당 계정의 홈 디렉터리도 포함됩니다.

실험에 필요한 파일과 자격 증명만 포함된 전용 계정을 만드세요. 개인 SSH 키, 클라우드 관리자 자격 증명, 브라우저 프로필, 프로덕션 설정, 관련 없는 저장소는 해당 계정이 접근할 수 있는 환경 밖에 두세요. 계정의 홈 디렉터리뿐 아니라 그룹 구성원 자격과 마운트된 저장소도 검토하세요.

더 강력한 격리를 원한다면 전용 일회용 가상 머신이나 이와 유사하게 제어된 호스트 환경을 고려하세요. 파일 시스템 보기가 다르다는 이유만으로 컨테이너면 충분하다고 가정하지 마세요. 실제 경계는 마운트, 권한, 소켓, 네트워킹에 따라 달라집니다. 배포 방식은 호스트와 실행할 코드의 가치를 고려해 결정해야 합니다.

아키텍처 안내에서는 이러한 제어가 서로 다른 계층에 배치된 이유를 설명합니다. 계층을 분리하면 요청자 목록을 짧게 유지하는 것과 같은 제한적인 보호 조치를 완전한 격리로 오해하는 일을 막을 수 있습니다.

표지: dsh-superagent 프로토타입 저장소, GitHub에서 생성한 저장소 카드. 저장소 메타데이터는 특정 날짜의 예시일 뿐, 도입이나 성능에 관한 주장이 아닙니다.

GitHub 에이전트 신원은 어떻게 만드나요?

개인 계정 대신 현재 프로토타입에서 요구하는 전용 GitHub 사용자 계정 방식을 사용하세요. 배포 가이드에 따르면 이 구현은 해당 계정의 알림을 읽으며, GitHub App을 에이전트 신원으로 대체하는 기능을 지원하지 않습니다. 이는 구현상의 제약일 뿐, 다른 시스템에서 GitHub Apps를 사용하지 말라는 일반적인 권고가 아닙니다.

처음에는 일회용 테스트 저장소에만 접근을 허용하세요. 에이전트의 로그인 설정은 본인의 설정과 분리하세요. 문서화된 래퍼 방식을 사용하거나 승인된 동등한 설정을 적용하고, 프로세스가 작업을 수행하도록 허용하기 전에 CLI가 어떤 계정을 사용 중인지 확인하세요. 채팅에 표시된 이름만으로 신원을 추정하지 마세요.

GitHub 토큰 가이드에서는 권한 및 만료 옵션을 설명합니다. 문서화된 프로토타입 작업에 필요한 최소한의 지원 접근 권한을 선택하고, 호환성 요구 사항을 검토한 뒤, 권한을 취소할 방법을 마련하세요. 편의를 위해 계정에 조직 관리 권한이나 프로덕션 배포 권한을 부여하지 마세요.

초기 실험에서는 병합을 사람이 직접 하도록 두세요. 브랜치를 푸시하고 풀 리퀘스트를 열 수 있는 에이전트에 저장소 보호 설정을 바꾸거나 자신의 작업을 승인할 권한까지 줄 필요는 없습니다. 작성자가 누구인지 분명히 드러나게 하면서 독립적인 승인 결정을 유지해야 합니다.

허용 사용자 목록과 허용 정책은 어떻게 작동하나요?

권한 부여 문서는 명시적 요청, 추론된 후보, 허용되지 않는 입력을 구분합니다. 허용된 신원과 범위별 허용 설정은 모두 중요합니다. 짧은 허용 목록은 유용하지만, 유일한 제어 수단으로 취급하지 말고 수신 범위 및 규칙과 함께 검토해야 합니다.

이미 알고 있는 요청자 한 명과 저장소 하나로 시작하세요. 테스트에 Feishu가 필요하지 않다면 설정하지 마세요. 소스를 추가할 때마다 신원, 수신 범위, 봇 동작, 작업을 시작할 권한을 확인해야 할 지점도 늘어납니다. 첫 번째 워크플로를 이해한 뒤에만 소스를 추가하세요.

무해한 예시로 정책 동작을 테스트하세요. 허용된 사용자가 에이전트를 지목할 때, 누군가 관련 없는 대화를 올릴 때, 후속 요청이 기존 작업 범위를 벗어날 때 각각 어떤 일이 발생하는지 확인하세요. 눈에 보이는 답변이 없다고 아무 동작도 일어나지 않았을 것이라 가정하지 말고, 결정 기록을 살펴보세요.

저장소 콘텐츠와 인용된 메시지는 정책 업데이트가 아니라 근거로 남아야 합니다. 이슈나 문서에 포함된 지시가 접근 권한을 조용히 부여하거나 누가 작업을 요청할 수 있는지를 바꾸어서는 안 됩니다. proactive-agent 비교에서는 이벤트에 연결된 워크플로가 단일 감독형 채팅 세션보다 이런 구분을 더 중요하게 만드는 이유를 설명합니다.

왜 Observe 모드로 시작해야 하나요?

문서에 명시된 기본 observe 모드에서는 시스템이 추론한 후보를 평가하고, 자동으로 수락하지 않은 채 수락될 후보를 기록합니다. 이를 통해 설정된 규칙이 어떻게 작동하는지 파악할 수 있습니다. 허가된 명시적 요청의 실행은 막지 않으므로, 전체 읽기 전용 모드나 무동작 모드는 아닙니다.

관찰하는 동안에도 실험의 기술적 권한 범위를 좁게 유지하세요. 목표가 중요한 변경을 허용하지 않고 라우팅을 점검하는 것이라면, 폐기 가능한 리소스를 사용하고 호스트와 저장소 설정을 통해 그 경계를 강제하세요. 프로세스가 이미 접근할 수 있는 자산을 모드 이름만으로 보호하려 하지 마세요.

허용과 거부 결정을 모두 검토하세요. 너무 많은 작업을 허용하는 규칙은 원치 않는 작업을 유발할 수 있고, 너무 적게 허용하는 규칙은 예상된 작업을 놓칠 수 있습니다. 정책을 수정하기 전에 예상한 결과와 실제 결과가 다른 이유를 기록하세요. 시연이 성공할 때까지 규칙의 적용 범위를 반복해서 넓히는 것은 안전한 기본값을 정하는 좋은 방법이 아닙니다.

일상적인 설치 단계로 auto 모드로 전환하지 마세요. 이 모드를 사용하면 일치하는 규칙에 따라 추론된 작업을 시스템이 시작할 가능성이 커집니다. 나중에 범위를 확장하려면 명확한 책임자, 검토된 규칙 집합, 통제된 평가 기록, 액세스를 중지하거나 취소할 수 있는 검증된 방법을 마련해야 합니다.

토큰, 비밀 정보, 로컬 파일은 어떻게 보호해야 하나요?

자격 증명을 프롬프트, 저장소 파일, 스크린샷, 일반 로그에 포함하지 마세요. 전용 환경에서 승인된 CLI 로그인이나 비밀 정보 저장소를 사용하세요. OWASP 비밀 정보 관리 지침에서는 액세스 제어와 수명 주기에 대한 배경 정보를 제공하지만, 당장 지켜야 할 원칙은 간단합니다. 에이전트 환경에는 작업과 무관한 자격 증명이 없어야 합니다.

GitHub 계정뿐 아니라 모델 제공업체 연결 경로도 검토하세요. 코드와 프롬프트는 구성된 제공업체에서 처리될 수 있고, 도구를 사용하면 추가 전송 대상이 생길 수도 있습니다. 로컬에서 체크아웃했다고 해서 추론이나 처리가 로컬에서만 이루어지는 것은 아닙니다. 선택한 제공업체와 로깅 구성이 테스트 자료에 사용하도록 승인되었는지 확인하세요.

설정을 간편하게 하려고 개인 홈 디렉터리나 셸 구성을 전용 계정에 복사하지 마세요. 여기에는 자격 증명 도우미, 환경 변수, 클라우드 구성, 비공개 기록이 포함될 수 있습니다. 필요한 의존성만 신중하게 다시 구성하고, 추가한 항목은 비밀 정보가 없는 목록으로 기록하세요.

개인 에이전트 액세스 체크리스트는 관련 준비 절차를 안내합니다. 처음 실행하기 전에 에이전트의 실제 환경에서 어떤 디렉터리, 자격 증명, 서비스, 네트워크 대상에 접근할 수 있는지 확인하세요. 테스트에 필요한 범위를 넘어선다면 진행하기 전에 경계를 바로잡으세요.

저장소를 분리하고 변경 사항을 검토하려면 어떻게 해야 하나요?

합성 예제만 포함하고 운영 환경의 비밀 정보는 없는 일회용 저장소를 사용하세요. 설정 문서에는 호환되는 Node.js 버전, pnpm, Git, tmux, Python, GitHub CLI, DeepSeek Harness 등의 사전 요구 사항이 나와 있습니다. 오래된 명령어 목록을 보고 임의의 버전을 설치하는 대신, 현재 package.json과 설정 가이드에서 정확한 호환성을 확인하세요.

설치 계획을 실행하기 전에 다음 준비 순서를 따르세요:

1. 전용 계정이나 일회용 호스트를 준비하고 접근 권한의 범위를 확인하세요.
2. 적절히 제한된 권한으로 전용 GitHub 계정과 테스트 저장소를 만드세요.
3. 프로토타입을 가져와 리비전을 기록하고 설정 및 배포 문서를 검토하세요.
4. 제안된 설치 계획, 모델 제공업체, 프로필, 상태 저장 위치, 자격 증명 방식을 검토하세요.
5. 첫 시험에서는 GitHub를 통해서만 작업을 접수하고, 요청자 목록은 짧게 유지하며, observe를 사용하고, 자동 병합은 하지 않도록 설정하세요.
6. 검토한 구성을 시작하고 상태와 설정 요구 사항을 점검하세요.
7. 문제가 없는 승인된 작업 하나를 제출하고, 그 결과 상태와 제안된 변경 사항을 검토하세요.
8. 더 광범위한 접근 권한을 고려하기 전에 관련 없는 입력, 범위 확장, 종료 절차를 시험하세요.

설정 후에는 문서화된 상태 확인 명령을 사용하면 유용합니다:

scripts/dsh-superagent status

검토를 마친 체크아웃에서 전용 환경을 통해 실행하세요. 현재 배포 가이드를 참고해 출력을 해석하세요. 프로세스가 실행 중이라는 사실만으로 소스와 정책이 정상이며 올바르게 구성되었다고 볼 수는 없습니다.

보호된 브랜치 요구 사항과 사람의 검토 절차를 유지하세요. diff, 시작 리비전과 최종 리비전, 테스트, 해결되지 않은 가정을 점검하세요. 중요한 데이터는 별도 사본으로 보관하세요. 쓰기 권한을 부여하기 전에 복구 계획을 세워야 하는 이유는 복구 가능한 파일 가이드에서 설명합니다.

에이전트를 중지하고 접근 권한을 회수하려면 어떻게 해야 하나요?

첫 작업을 시작하기 전에 종료 절차를 문서화하세요. 현재 배포 가이드에는 정상 종료 명령이 나와 있습니다:

scripts/dsh-superagent stop
scripts/dsh-superagent status

정상 종료는 실행이 마무리될 때까지 기다릴 수 있지만, 모든 외부 영향이 취소되었다는 증거는 아닙니다. 대기 중인 작업과 관련 저장소 활동을 점검하세요. 프로세스가 무엇을 하는지 파악하지 않은 채 관련 없는 세션을 강제 종료하는 것으로 대신하지 마세요.

접근 사고가 발생했거나 실험이 중단된 경우, 적절한 제공업체 제어 기능을 통해 전용 자격 증명과 저장소 접근 권한을 회수하세요. 새 작업 접수를 중단하고 남아 있는 백그라운드 프로세스나 서비스를 점검하세요. 팀이 상황을 재구성할 수 있도록 영향을 받은 작업, 리비전, 관련 활동을 비밀 정보가 아닌 기록으로 남기세요.

정리와 복구는 서로 다른 작업입니다. 로컬 디렉터리를 삭제해도 토큰은 폐기되지 않고, 원격 풀 리퀘스트는 닫히지 않으며, 푸시한 변경 사항도 되돌아가지 않습니다. 각 결과물에 어떻게 조치할지 따로 정하고, 삭제 전에 필요한 증거를 보존하세요. 실험 범위는 시작만큼 중지, 권한 폐기, 복구 절차도 명확해진 뒤에만 넓히세요.

결과 자체를 검토하려면 agentic-autofix 검토 절차를 따르세요. 프로세스가 정상 작동하고 작업이 접수되었다는 것은 운영상 신호일 뿐, 제안된 패치를 병합해야 한다는 근거는 아닙니다.

자주 묻는 질문

일반 개발자 계정으로 프로토타입을 실행해도 되나요?

그러면 프로세스가 계정에서 접근할 수 있는 파일과 자격 증명에 노출됩니다. 특히 전체 접근을 허용하는 사전 설정이 문서화되어 있으므로, 첫 실험에는 전용 제한 환경을 사용하세요.

관찰 모드에서는 프로토타입이 읽기 전용이 되나요?

아니요. 추론으로 찾아낸 후보의 승인은 제한하지만, 명시적으로 승인된 요청은 여전히 실행할 수 있습니다. 테스트 목표가 쓰기 금지라면 권한으로 이를 강제하세요.

전용 사용자 계정 대신 GitHub App을 사용할 수 있나요?

검토한 프로토타입의 배포 가이드에서는 알림 워크플로 때문에 사용자 계정을 요구합니다. 이 호환성 제약이 그대로라고 가정하기 전에 이후 버전을 다시 확인하세요.

설정 토큰을 보조 에이전트의 채팅에 붙여 넣어야 하나요?

아니요. 직접 관리하는 환경에서 승인된 CLI 인증이나 비밀 정보 저장소를 사용하세요. 설정 과정에서 대화창에 비밀 값을 공개할 필요는 없습니다.

초기 시험 범위를 넓혀도 안전하다는 것을 어떻게 입증하나요?

단 하나의 테스트로 전반적인 안전성을 입증할 수는 없습니다. 접수 결정, 권한 경계, 제안된 변경 사항, 중지 동작, 복구 증거를 검토한 다음, 구체적인 추가 범위만 승인하세요.

결론

dsh-superagent를 안전하게 설정하려면 먼저 실제 작동 전제를 알아야 합니다. 연구 단계이며, 호스트 사용자 권한으로 전체 접근을 실행하고, 관찰 모드에서도 명시적인 작업은 허용합니다. 프로토타입의 동작을 파악하려면 전용 계정, 폐기 가능한 리소스, 독립적인 검토가 선행되어야 합니다.

첫 작업의 범위를 좁게 유지하고, 성공뿐 아니라 거부와 중지도 의도적으로 테스트하며, 승인된 모든 변경의 근거를 보존하세요. 자격 증명과 권한을 새로운 검토 없이 점차 늘려 가며 유용한 연구 실험을 프로덕션 배포로 바꾸지 마세요.