DeepSeek Harness는 어떻게 사용하나요? dsh 설치 및 배포, Agent Harness 플러그인 아키텍처, AI 코딩 워크플로와 Claude Code/Codex 비교 실전

DeepSeek Harness는 지금 바로 전면 이전하기보다, 플러그인 기반 Agent Runtime과 자체 도구 체인을 연구하려는 개발자가 작은 범위에서 시험하는 편이 맞습니다. 공식 저장소가 developer preview로 안내하는 단계이므로, 안정적인 일상 코딩이 우선인 팀은 기존 Agent를 유지하고 dsh를 병행 검증해야 합니다.

이 글은 원격 클라우드 개발 환경을 계획하는 기술 책임자를 위한 내용입니다. 특히 원격 접속, 권한 분리, 플러그인 관리, 로그 보존을 확인해야 하는 경우에 적합합니다.

마지막 업데이트: 2026년 9월 21일. 공식 저장소, 공식 안내 문서, npm 및 SSH 문서를 기준으로 내용을 확인했습니다.

먼저 결정하기: 지금 DeepSeek Harness를 선택할 조건

DeepSeek Harness를 선택할 이유는 단순히 코드를 더 빠르게 작성하기 위해서가 아닙니다. 모델, 도구, 스킬, 세션, 샌드박스, 저장소, 실행 루프, 사용자 화면을 플러그인으로 조합하면서 자신에게 맞는 Agent Runtime을 만들 수 있다는 점이 핵심입니다. 공식 저장소도 현재 프로젝트를 developer preview로 설명하므로, 장기 호환성과 운영 안정성을 정식 제품처럼 가정해서는 안 됩니다.

다음 조건에 해당하면 즉시 전체 이전보다 제한적인 시험이 적합합니다.

• 개인 연구자이고 Agent Harness 구조 자체를 분석하려는 경우
• 조직 내부 도구나 사내 명령을 플러그인으로 연결해야 하는 경우
• 코드 작성뿐 아니라 계획 수립, 검사, 하위 Agent 실행을 하나의 흐름으로 묶으려는 경우
• 실패해도 기존 환경으로 돌아갈 수 있는 별도 저장소와 테스트 프로젝트가 있는 경우

반대로 매일 같은 저장소에서 안정적으로 수정, 테스트, 검토를 반복해야 한다면 Claude Code나 Codex를 먼저 유지하는 편이 안전합니다. 이때 dsh는 주력 도구가 아니라 비교 대상이 됩니다.

첫 단계: dsh 설치와 웹 화면 실행 경로 확인하기

DeepSeek Harness dsh는 어떻게 설치하고 웹 화면을 시작하나요?

공식 안내에서 확인할 수 있는 시작 경로는 npx 실행과 소스 코드 빌드입니다. npx는 패키지를 실행하는 방식이므로, 먼저 npm 공식 npx 명령 문서와 Node.js 공식 설치 안내에서 현재 프로젝트가 요구하는 실행 환경을 확인해야 합니다. 문서에 없는 Node.js 버전을 임의로 고정하면 나중에 플러그인 호환성 문제가 생길 수 있습니다.

권장 순서는 다음과 같습니다.

1. 격리된 작업 디렉터리를 만들고 Node.js와 npm이 정상 실행되는지 확인합니다.
2. 공식 저장소의 현재 설치 지침과 패키지 이름을 대조합니다.
3. npx 실행 경로를 먼저 시험하고, 재현 가능한 팀 환경이 필요할 때 소스 코드 빌드 경로를 검토합니다.
4. 웹 화면을 시작하기 전에 사용 포트, 작업 디렉터리, 저장 위치를 기록합니다.
5. 모델 제공자 설정을 등록하고, 필요한 도구와 샌드박스 권한만 허용합니다.
6. 로컬 브라우저에서 세션 생성, 파일 읽기, 테스트 실행을 순서대로 확인합니다.
7. 마지막으로 원격 SSH 접속에서 같은 세션과 파일 상태가 유지되는지 확인합니다.

로컬 실행과 원격 SSH 실행은 같은 문제가 아닙니다. 로컬에서는 브라우저와 프로세스가 한 컴퓨터에 있지만, 원격 환경에서는 포트 노출, SSH 터널, 사용자 권한, 세션 종료 후 프로세스 유지 여부를 별도로 관리해야 합니다. OpenSSH 공식 매뉴얼을 기준으로 공개 포트를 무작정 열기보다 인증된 계정과 제한된 터널을 사용하는 편이 낫습니다.

두 번째 단계: Agent Harness 플러그인 구조를 작업 단위로 나누기

DeepSeek Harness의 플러그인 아키텍처는 어떻게 이해해야 하나요?

핵심 원칙은 “모든 것이 플러그인”이라는 구성입니다. 모델은 추론 제공자이고, 도구는 파일·셸·검색 같은 작업 인터페이스이며, 스킬은 반복 지침을 묶은 실행 단위입니다. 세션은 대화와 실행 상태를 담고, 샌드박스는 허용된 자원 범위를 제한하며, 저장소는 대화와 결과를 보존합니다. 실행 루프와 사용자 화면은 이 요소들을 연결합니다.

공식 핵심 하위 시스템 문서와 도구 하위 시스템 문서를 읽을 때는 이름보다 경계를 확인해야 합니다. 모델 설정을 바꾼다고 파일 권한이 자동으로 안전해지는 것은 아니며, 도구를 추가한다고 그 도구가 현재 세션에서 자동으로 허용되는 것도 아닙니다.

하나의 최소 흐름은 다음과 같습니다.

• 사용자가 버그 수정 요청을 보냅니다.
• 모델 플러그인이 작업 계획을 만듭니다.
• 파일 읽기와 검색 도구가 관련 코드를 찾습니다.
• 편집 도구가 변경을 적용합니다.
• 샌드박스 안에서 테스트 명령을 실행합니다.
• 세션 저장소에 변경 설명과 실행 로그를 남깁니다.
• 화면에서 사람이 diff와 테스트 결과를 확인합니다.

모드 선택도 작업 목적에 따라 달라집니다. Standard는 일반적인 기능 묶음을 확인할 때, Code는 코딩 도구를 중심으로 시험할 때, Minimal은 권한과 의존성을 최소화할 때, Creator는 플러그인 자체를 개발할 때 검토할 수 있습니다. 다만 각 모드가 조직의 보안 경계를 대신 정해 주는 것은 아니므로, 실제 권한은 별도로 검증해야 합니다.

주의: 모델 제공자를 설정하는 것과 모델 호출 권한을 관리하는 것은 다른 작업입니다. 제공자 설정은 공식 제공자 구성 문서를 기준으로 확인하고, 비밀 키는 저장소나 작업 로그에 남지 않는지 별도로 점검해야 합니다.

세 번째 단계: AI 코딩 워크플로에 맞춰 맡길 일과 남길 일 구분하기

dsh에서 모델, 도구와 샌드박스는 어떻게 함께 설정하나요?

먼저 모델 제공자를 정하고, 그 모델이 사용할 도구 목록을 좁힌 다음, 샌드박스에서 허용할 경로와 명령을 정하는 순서가 안전합니다. 반대로 모든 도구를 먼저 열어 둔 뒤 모델에게 판단을 맡기면, 잘못된 경로 수정이나 예상하지 못한 셸 명령이 발생했을 때 원인을 분리하기 어렵습니다.

버그 수정 작업은 다음처럼 나누면 검증하기 쉽습니다.

• 코드 읽기와 검색: 에이전트에 맡겨도 되는 초기 조사
• 계획 작성: 사람이 범위와 완료 조건을 확인해야 하는 단계
• 파일 편집: 변경 파일 목록과 diff를 제한해야 하는 단계
• 테스트 실행: 샌드박스와 허용 명령을 먼저 정해야 하는 단계
• 변경 설명 작성: 실제 diff와 테스트 결과를 바탕으로 생성할 수 있는 단계
• 병합과 배포: 승인과 권한을 사람 또는 기존 자동화에 남겨야 하는 단계

이 방식은 AI Coding 워크플로를 “한 번에 자동화”하지 않습니다. 대신 읽기, 수정, 검증, 보고를 나눠 실패 지점을 찾게 해 줍니다. 커뮤니티에서 특정 환경이 잘 작동했다는 경험은 참고할 수 있지만, 이를 DeepSeek Harness의 공식 성능이나 안정성 결론으로 바꿔서는 안 됩니다.

네 번째 단계: 원격 클라우드 개발 환경에서 격리와 유지 상태 확인하기

DeepSeek Harness를 원격 환경에 배포할 때 가장 먼저 확인할 것은 CPU나 화면 속도가 아니라 프로세스와 데이터의 경계입니다. 다음 항목을 별도로 기록해야 합니다.

• 실행 계정과 파일 소유자
• 웹 화면에 접근하는 방식과 SSH 터널 여부
• 세션 데이터와 프로젝트 파일의 저장 위치
• 재시작 뒤에도 남아야 하는 설정과 로그
• 모델 비밀 키의 주입 방식
• 샌드박스에서 허용한 경로와 명령
• 세션 종료, 오류, 플러그인 업데이트를 추적하는 로그

클라우드 맥이나 원격 개발 서버에서 실행한다면, 연결이 끊겼을 때 작업이 중단되는지 확인해야 합니다. 브라우저 화면이 닫혔다는 이유만으로 실행 프로세스와 세션이 안전하게 보존된다고 가정하면 안 됩니다. 반대로 세션을 지나치게 오래 보존하면 민감한 코드와 명령 기록이 남는 범위가 커집니다.

ZavCloud의 원격 개발 환경과 맥 대여 선택지를 검토할 때도 같은 기준을 적용하십시오. 환경을 빌리는 것보다 중요한 것은 어떤 계정으로 실행하고, 어떤 데이터를 얼마 동안 유지하며, 누가 로그를 확인할 수 있는지입니다. 운영 전에는 ZavCloud 도움말 센터의 연결 및 관리 안내와 실제 배포 절차를 대조하는 편이 좋습니다.

다섯 번째 단계: Claude Code와 Codex를 대체하기 전에 병행 검증하기

DeepSeek Harness는 Claude Code나 Codex를 바로 대체할 수 있나요?

현재 확인 가능한 범위만 보면 “대체 가능”이라고 단정하기 어렵습니다. DeepSeek Harness의 강점은 플러그인 조합과 자체 실행 흐름을 연구하기 좋다는 점입니다. 반면 팀의 기존 Agent는 이미 저장소 규칙, 권한 절차, 스킬, 검토 습관에 맞춰져 있을 수 있습니다. 따라서 비교는 추상적인 성능 순위가 아니라 실제 작업의 호환성으로 해야 합니다.

다음 검증표를 사용하면 전면 이전 여부를 결정하기 쉽습니다.

• [ ] 같은 버그 설명으로 세 도구가 읽어야 할 파일 범위를 동일하게 확인합니다.
• [ ] 파일 편집 전에 계획과 변경 대상 목록을 출력하게 합니다.
• [ ] 동일한 테스트 명령을 실행하되, 실패 시 원인과 로그가 남는지 확인합니다.
• [ ] 기존 스킬이나 지침을 dsh 플러그인으로 옮길 수 있는지 하나만 시험합니다.
• [ ] 비밀 키, 셸 명령, 프로젝트 외부 경로에 대한 권한 차이를 기록합니다.
• [ ] 세션 재연결 뒤 대화, 변경 사항, 실행 로그가 유지되는지 확인합니다.
• [ ] 개발자 미리보기 업데이트 뒤 같은 플러그인이 다시 작동하는지 확인합니다.
• [ ] 실패했을 때 기존 Agent로 되돌리는 절차를 문서화합니다.

이 표는 성능 순위가 아닙니다. 실제 성능과 비용은 모델 제공자, 저장소 크기, 도구 권한, 테스트 방식에 따라 달라지므로, 공식 문서에 없는 수치로 우열을 정하면 안 됩니다. 특히 developer preview에서는 플러그인 인터페이스나 시작 절차가 바뀔 수 있다는 위험을 일정에 포함해야 합니다.

최종 점검: 연구용 실행과 생산용 운영을 분리하기

다음 조건을 모두 충족하지 못했다면 전면 이전을 미루십시오.

• [ ] 공식 저장소의 현재 설치 경로와 로컬 실행 결과를 대조했습니다.
• [ ] 웹 화면의 접근 포트와 SSH 접속 방식을 문서화했습니다.
• [ ] 모델 제공자, 비밀 키, 도구 권한을 서로 분리했습니다.
• [ ] 샌드박스에서 프로젝트 경로와 명령 범위를 제한했습니다.
• [ ] 세션과 로그의 저장 위치, 보존 기간, 삭제 절차를 정했습니다.
• [ ] 하나의 버그 수정과 테스트 작업을 기존 Agent와 병행했습니다.
• [ ] 플러그인 업데이트 실패 시 이전 환경으로 돌아갈 수 있습니다.
• [ ] 팀원이 설치, 권한 승인, 로그 확인 절차를 재현할 수 있습니다.

DeepSeek Harness는 연구용으로는 매력적이지만, 안정적인 팀 납품 환경과 같은 기준으로 평가하면 안 됩니다. 개인 연구자라면 지금 작은 저장소에서 시작할 수 있고, 소규모 팀이라면 읽기·검색 중심의 제한된 작업부터 병행해야 합니다. 장기 운영이 목적이라면 플러그인 유지 담당자와 장애 대응 절차가 생긴 뒤에야 주력 전환을 검토하는 편이 합리적입니다.

현재 환경을 그대로 유지하는 방법은 빠르고 익숙하지만, 도구 확장 경계가 제한되고 원격 세션과 권한을 팀 방식에 맞게 다시 설계하기 어렵다는 단점이 있습니다. 반대로 자체 장비나 복잡한 서버를 직접 유지하면 초기 설정, 접근 제어, 저장소 보존, 장애 대응을 모두 떠안게 됩니다. 이런 부담 없이 일시적인 원격 AI 코딩 환경을 검증하려면 ZavCloud의 맥 미니 대여 환경에서 먼저 병행 시험을 진행하고, 실제 유지 비용과 권한 요구를 확인한 뒤 장기 배포 여부를 결정하는 편이 더 안전합니다.