DeepSeek Harness 데스크톱 앱: 설치 프로그램이 실제로 컴퓨터에 설치하는 것

DeepSeek Harness 데스크톱 앱은 npx @deepseek-ai/dsh web에서 얻는 것과 동일한 웹 인터페이스를 감싼 Electron 셸이며, 현재 버전 0.2.1-rc.2인 하네스용 플랫폼별 설치 프로그램 세 가지로 제공됩니다. 그 설명은 무시하는 것처럼 들리지만 그럴 의도는 아닙니다. 작동하는 인터페이스를 데스크톱 컨테이너로 감싸는 것은 주말이면 충분한 작업입니다. 자체 런타임 디렉터리를 소유하고, 창을 닫아도 작업이 계속 살아 있게 하며, 안정 릴리스가 없는 채널에서 스스로 업데이트하고, 그 모든 작업 전반에 걸쳐 세션을 보존하는 컨테이너로 그것을 감싸는 것이 바로 몇 달이 걸리는 부분이며, 읽을 가치가 있는 부분입니다. 터미널이 아니라 창 안에 존재하는 하네스를 통해 DeepSeek-V4.1-Flash를 실행하고 싶다면, 이것이 바로 그 빌드이며, 흥미로운 질문은 모두 창 주변에서 일어나는 일에 관한 것입니다.

세부 사항에 앞서 두 가지를 말해야 합니다. 첫째, 이 글은 데스크톱 앱이 없다는 우리의 이전 안내를 대체합니다. 그 안내는 2026년 8월 작성 당시에는 맞았지만 지금은 틀렸습니다. 둘째, 이것은 공개 미리보기이며 DeepSeek 자체 사이트에서도 여전히 그렇게 표시되어 있고, 패키징에는 그 명칭이 함의하는 거친 부분이 있습니다. 설치 프로그램은 작동합니다. 그 주변의 배포는 짐작보다 빈약합니다.

데스크톱 빌드가 실제로 무엇인지

데스크톱 애플리케이션은 얇은 Electron 계층으로, 그 역할은 Host 프로세스를 시작하고 창을 해당 프로세스로 연결하는 것입니다. 이 창은 자체 채팅 인터페이스를 구성하지 않습니다. 대신 앱 내부에 번들된 패키징된 Web 엔트리를 다음 위치에서 로드합니다: dsh-app://app/, 그리고 보게 될 업데이트 대화 상자는 두 번째로 번들된 origin인 dsh-app://shell/에서 제공됩니다. 하위 Node 프로세스는 Electron의 RunAsNode 모드로 실행되어 공유 프로필 러너를 시작하며, 셸은 인증된 Web Host로 HTTP를 전달하면서 전달 과정에서 다음 transfer-encoding, connection 및 keep-alive 헤더를 제거합니다. 플러그인 번들 응답은 no-store로 표시됩니다. 이는 눈에 보이는 결과가 있는 작은 세부 사항입니다. 플러그인을 변경하면 다음 새로고침에서 변경 사항이 표시됩니다.

URL이 dsh-app://이고 localhost가 아니기 때문에 기억해야 할 고정 포트도, 피해야 할 포트 충돌도 없습니다. 데스크톱 Host는 기본적으로 OS가 할당한 포트에서 수신 대기합니다. 특정 포트가 필요하면 webserver.config.port 재정의를 통해 설정할 수 있지만, 기본값은 의도적으로 상수가 아니며 Host는 127.0.0.1에 바인딩합니다. 이는 이전 지침을 따라오신 경우 중요합니다. 8월 설치 가이드에 유포되었던 숫자 19387은 데스크톱 포트가 아니며, 이를 포트로 취급하면 존재하지 않는 서비스를 찾게 됩니다.

버전 고정은 언뜻 보이는 것보다 더 엄격합니다. Electron과 @deepseek-ai/dsh는 항상 정확히 동일한 버전을 사용합니다. 범위도 아니고, 호환되는 메이저 버전도 아닙니다. 따라서 하네스를 업그레이드하는 것은 곧 데스크톱 릴리스이며, 새로운 dsh와 이전 창을 조합하는 것은 지원되지 않습니다. Electron 프로세스는 프로세스 수명 동안 유지되는 단일 인스턴스 잠금을 획득하며 $DSH_HOME/profiles/desktop을 독점적으로 소유합니다. 이 독점성은 실제입니다. CLI는 해당 프로필을 부팅할 수 없고, npm(으)로 설치된 dsh도 이를 변경할 수 없습니다. 두 설치가 공유하는 것은 사용자에게 중요한 상태입니다. 즉 세션, 설정, 자격 증명, 워크스페이스 및 스토리지가 모두 $DSH_HOME 아래에 있습니다. 공유하지 않는 것은 실행 패키지, 플러그인 활성화, 잠금 파일 또는 node_modules이며, 이것이 데스크톱 프로필에 플러그인을 설치하는 것이 CLI 프로필에 설치하는 것과 같은 작업이 아닌 이유입니다.

설치 프로그램 세 가지, 업데이트 채널 하나, 안정판 없음

설치 프로그램이 세 개 존재하며 셋 모두 응답합니다. Windows 64비트 실행 파일은 289,385,456바이트이고 HTTP 200으로 제공됩니다. Apple 실리콘 디스크 이미지는 264,990,950바이트이며 역시 200입니다. Intel Mac 디스크 이미지는 289,480,824바이트이며 역시 200입니다. 세 파일 모두 2026년 10월 17일에 마지막으로 수정되었습니다. 다운로드 페이지에는 그중 두 개만 링크되어 있습니다. Intel 빌드는 활성 상태이며 접근 가능하고, 다음 주소 어디에도 이를 가리키는 링크가 없습니다: deepseek.com/en/harness/ — Intel Mac을 사용 중이고 해당 페이지를 따라갔다면, 자신을 위한 빌드가 없다고 합리적으로 결론 내리게 될 것입니다.

Intel 빌드도 한 버전 뒤처져 있습니다. 업데이트 피드에는 0.2.1-rc.1이 표시되지만, Windows와 Apple 실리콘 피드에는 둘 다 0.2.1-rc.2가 표시됩니다. 릴리스 후보 하나 차이는 기능 면에서 큰 격차는 아니지만, 어떤 대상이 먼저 빌드되고 어떤 대상이 마지막에 검증되는지에 대한 실질적인 신호이며, 작업 세션을 특정 플랫폼에 맡기기 전에 알아두고 싶은 바로 그런 정보입니다.

업데이트 채널은 배포 이야기가 빈약해지는 지점입니다. 피드는 대상별로 /dsh-desk/feeds/<target>/ 경로 아래에, 같은 호스트에서 제공됩니다. Windows x64는 nightly.yml을 확인하고, 두 macOS 대상은 모두 nightly-mac.yml을 확인합니다. 세 가지 중 아무거나에 latest.yml 또는 latest-mac.yml을 요청하면 404가 돌아옵니다. 안정 채널도, 베타 채널도 없으며, 존재하는 채널에서 빠져나갈 방법도 없습니다. DeepSeek 자체의 게시 노트는 이 배열을 뒤집기는커녕 확인해 줍니다. 모든 릴리스는 nightly 피드를 게시하고, 안정 릴리스만 동일한 아티팩트를 가리키는 latest 피드를 게시합니다. 이 맥락에서 "Nightly"는 빌드 주기가 아니라 채널 이름입니다. Windows와 Apple 실리콘 피드 모두 10월 17일자 동일한 0.2.1-rc.2 빌드를 제공하며, Windows 패키지는 09:22 UTC, Apple 실리콘 패키지는 09:57 UTC 타임스탬프가 찍혀 있습니다. 즉 자동 업데이터 장치, 지터가 적용된 폴링, 1시간 상한까지의 백오프를 갖추고 있지만, 미리보기 채널이 현재 담고 있는 것 외에 다른 것을 요청할 방법은 없습니다.

GitHub은 다른 각도에서 같은 점을 지적한다. deepseek-ai/deepseek-harness 저장소는 — 2026년 10월 21일에 확인했을 당시 256,559개의 스타와 30,921개의 포크를 기록했고 — 같은 날짜에 31개의 릴리스가 있었으며, 모든 릴리스가 사전 릴리스로 표시되어 있었고 모두 첨부된 바이너리 자산이 0개였습니다. Releases 페이지에서는 어떤 것도 다운로드할 수 없습니다. 빌드를 원한다면 download.deepseek.com 또는 npm에서 받을 수 있으며, 여기서 @deepseek-ai/dsh가 현재 latest를 0.2.1-rc.2로 해석합니다. 이 저장소는 변경 로그의 진실 공급원이자 아티팩트에는 막다른 길인데, 이는 31개의 릴리스를 보면 그중 하나에 설치 프로그램이 있을 것이라고 기대하는 것이 당연한 반응이기에 분명히 짚고 넘어갈 만큼 이례적입니다.

설치 프로그램이 기록하는 것, 그리고 손대기를 거부하는 것

Windows 설치 프로그램은 MSI를 감싼 래퍼가 아니라 네이티브 NSIS 패키지이며, 그에 걸맞게 동작합니다. 밝게, 어둡게, 자동 팔레트를 제공하며 설치 시점에 /THEME=light, /THEME=dark 또는 /THEME=auto로 선택할 수 있고, 대상 디렉터리를 편집할 수 있으며, 설치 범위는 현재 사용자로 제한됩니다. 드라이브 루트는 대상으로 거부되며, 비어 있지 않은 대상은 이미 등록된 설치인 경우에만 허용되는데, 이는 관련 없는 폴더를 덮어쓰지 않겠다는 설치 프로그램의 거부입니다. 업데이트 시 무음 경로는 실행 중인 애플리케이션이 종료되기를 최대 10초 동안 기다린 뒤, 여전히 실행 중이면 종료 코드 2로 중단됩니다. 이는 손상된 설치가 아니라 정직한 실패이며, 앱을 먼저 종료하지 않는 모든 스크립트 기반 배포에서 드러나게 됩니다.

이 제거 프로그램은 대부분의 제거 프로그램이 잘못 짚는 경계를 제대로 긋습니다. Electron userData 디렉터리와 %APPDATA% 아래의 제품 디렉터리, %LOCALAPPDATA% 아래의 업데이터 캐시를 삭제합니다. 반면 하네스 홈인 ~/.dsh, 또는 DSH_HOME이 가리키는 위치는 건드리지 않습니다. 이곳에는 세션, 설정, 자격 증명, 플러그인이 들어 있습니다. --updated 또는 /KEEP_APP_DATA를 전달하면 Electron 데이터도 그대로 유지됩니다. 따라서 제거 후 재설치하는 것은 작업을 잃지 않고 망가진 창을 고칠 수 있는 지원되는 방법이며, 이는 사고가 아니라 의도된 설계 결정입니다.

번들 런타임은 용량이 크고 앱 디렉터리 밖에 있기 때문에 알아 둘 만합니다. numpy, pandas, python-docx, python-pptx, openpyxl, Pillow, lxml, XlsxWriter가 포함된 Python과 Node, pnpm은 $DSH_HOME/dsh-runtimes/dsh-primary-runtime — 보통 ~/.dsh/... 양 플랫폼에서 — 워크스페이스가 처음으로 해당 런타임이 필요하다고 선언할 때 설치됩니다. 그래서 일주일 사용 후의 디스크 점유량은 설치 직후의 디스크 점유량과 다르고, $DSH_HOME을 보존하는 제거 작업이 수백 메가바이트의 런타임도 보존하는 이유입니다.

설정은 시작 시 다음에서 한 번 읽습니다: desktop/settings.json. 이 파일은 Electron userData 디렉터리 내부에 있으며, Windows에서 이 경로는 %APPDATA%\@deepseek-ai\dsh-desktop\desktop\settings.json이고, macOS에서 이 경로는 ~/Library/Application Support/@deepseek-ai/dsh-desktop/desktop/settings.json입니다. DSH_HOME은 이 파일의 위치를 바꾸지 않습니다 — 이는 짚고 넘어갈 만한 점인데, 다른 모든 것이 따르는 변수를 따르지 않는 유일한 구성 항목이기 때문입니다. 해당 파일의 업데이트 설정은 밀리초 단위입니다: intervalMs의 기본값은 600,000이고, maxBackoffMs의 기본값은 3,600,000이며 최소 intervalMs 이상이어야 합니다. 지터의 기본값은 0.2이고 0에서 1 사이의 범위로 제한되며, 1초로 하한이 적용되지만 백오프 상한을 초과하지는 않습니다. 연결별 비활성 기한 60,000밀리초가 업데이트 HTTP 트래픽에 적용되지만, 진행 중인 다운로드에는 총 지속 시간 기한이 없습니다 — 느린 링크라도 다운로드 중간에 끊기지 않습니다.

창을 닫아도 애플리케이션은 종료되지 않습니다.

두 플랫폼 모두에서 창을 닫으면 창이 숨겨집니다. macOS에서는 Command-W이고, Windows에서는 닫기 버튼, Alt-F4 또는 작업 표시줄의 닫기입니다. Windows는 처음 숨기기 전에 확인을 요청하고 Electron userData 디렉터리 아래에 background-close-confirmed 플래그를 기록하므로 매번이 아니라 한 번만 묻습니다. Windows는 또한 실행되는 동안 내내 트레이 아이콘을 유지합니다. macOS는 메뉴 막대 아이콘을 전혀 제공하지 않으므로 숨겨진 상태가 그곳에서는 정말로 보이지 않습니다 — 앱이 실행 중이고 작업도 실행 중인데, 플랫폼에 따라 dsh://open 또는 트레이로 다시 열기 전까지 화면에는 아무것도 이를 알려주지 않습니다.

숨기기에서 살아남는 것이 유용한 부분입니다. 실행 중인 작업은 계속 실행되며, 다음에 창이 표시될 때 동일한 문서를 동일한 세션, 동일한 초안, 동일한 스크롤 위치로 보여 줍니다. 이는 닫았다가 다시 여는 브라우저 탭과는 다른 동작이며, 작업이 장시간 실행되는 에이전트 작업을 포함한다면 데스크톱 빌드를 갖는 가치가 있는 이유입니다. 창을 닫고 작업이 완료되게 할 수 있습니다.

종료는 고유한 로직을 가진 별도의 동작입니다. 종료하기 전에 셸은 호스트를 검사하여 하위 에이전트와 승인을 기다리는 에이전트를 포함하여 실행 중인 에이전트, 대기열에 있는 메시지, 실행 중이거나 중지 중인 작업, 그리고 활성화된 예약 알림이 있는지 확인합니다. 이런 항목이 하나도 없으면 조용히 종료됩니다. 하나라도 있으면 제목이 DeepSeek Harness를 종료할까요?인 네이티브 확인 대화상자가 표시되며, 찾은 내용에 따라 작업이 중단된다는 것, 예약된 작업이 실행되지 않는다는 것, 또는 둘 다라는 세 가지 설명 중 하나가 함께 표시됩니다. 준비 상태에 도달한 적이 없는 호스트는 어떤 작업도 시작할 수 없었으므로, 그 상태에서 종료하면 묻지 않고 진행됩니다. "닫기"와 "종료"의 구분이 이 설계의 핵심이며, 두 플랫폼 중 하나만 사용자에게 지속적인 아이콘을 표시하더라도 두 플랫폼 모두에서 유지됩니다.

dsh 명령, 그리고 중요한 순서

설치 프로그램은 dsh를 PATH에 추가할 수 있으며, 이를 통해 데스크톱 앱이 사용하는 동일한 하네스 홈에 대해 CLI를 실행할 수 있습니다. 해당 제어 항목은 dsh 명령 관리…이며, 메뉴에서 업데이트 확인… 바로 아래에 있고 설치, 복구, 제거의 세 가지 작업이 있습니다. macOS에서는 /usr/local/bin/dsh에 런처를 작성하고 필요할 때 관리자 권한 부여를 요청합니다. Windows에서는 현재 사용자의 PATH에 명령을 등록합니다.

두 가지 순서 규칙은 놓치기 쉽고 나중에 알게 되면 골치 아픕니다. 첫 번째: 데스크톱 애플리케이션을 제거하기 전에 Remove를 실행하세요. 제거 프로그램이 dsh 등록을 제거하지 않기 때문입니다. 먼저 제거하면 더 이상 존재하지 않는 바이너리를 가리키는 PATH 항목이 남습니다. 두 번째: 애플리케이션을 다른 위치로 옮기는 경우, 등록이 앱을 따라간다고 가정하지 말고 macOS에서는 Repair를, Windows에서는 새 위치에서 Install을 사용하세요.

데스크톱 프로필의 플러그인 관리에는 고유한 주의점이 있습니다. Electron이 실행 중에 $DSH_HOME/profiles/desktop을(를) 독점적으로 소유하기 때문에, 해당 프로필에 설치하는 것은 앱을 열어 둔 상태에서 하는 작업이 아닙니다. 지원되는 순서는 데스크톱 앱을 한 번 실행했다가 종료한 다음 명령줄에서 dsh plugin --profile desktop add <package>를 실행하는 것입니다. 패키지는 데스크톱 프로필에 들어가며 다음에 창을 열 때 활성화됩니다.

패키징이 이미 말해 주는 것은 미완성이다

README의 '알려진 제한 사항' 섹션은 유난히 솔직한데, 그중 두 항목은 여러분이 가장 먼저 겪게 될 것들입니다.

• 계정 로그인이 연결되어 있지 않습니다. 로그인 버튼이 비활성화되어 있습니다. 대신 첫 실행 시 API 키 입력 양식이 있는 600x700 크기의 환영 창이 열립니다. 저장 후 계속을 누르면 키가 개발용 자격 증명 저장소에 기록되고, 나중에 설정을 누르면 키를 저장하지 않고 실제 작업 공간이 열립니다. 표시되는 위치에서 로그인을 누르면 구성된 플랫폼 페이지가 시스템 브라우저에서 열리며, Host가 PKCE 교환과 임시 루프백 콜백을 담당합니다. 기반 구조는 존재하지만 계정 바인딩은 없습니다. 실제로는 키를 준비해 두는 것으로 계획하세요.

• 릴리스 서명 및 공증은 프로덕션 릴리스 환경이 필요한 항목으로 나열되어 있습니다. 이는 README가 신중을 기한 것이며, 문장보다 측정값이 더 유용한 지점이기도 합니다. 공개된 Windows 실행 파일에는 확장 검증(EV) 체인이 포함된 유효한 Authenticode 서명이 있습니다: GlobalSign Root CA–R3에서 GlobalSign Code Signing Root R45 및 GlobalSign GCC R45 EV CodeSigning CA 2020을 거쳐, 관할이 CN / Zhejiang / Hangzhou로 표시되고 비즈니스 범주가 민간 조직인 Hangzhou DeepSeek Artificial Intelligence Co., Ltd.에 발급된 리프 인증서까지 이어집니다. 해당 서명의 RFC-3161 타임스탬프는 2026-10-17T09:22:04Z이며, 이는 Windows 업데이트 피드의 릴리스 날짜와 1분 이내로 일치하고, 다운로드한 파일의 SHA-512 다이제스트는 해당 피드에 게시된 해시와 바이트 단위까지 일치합니다. 따라서 Windows에서는 해당 프로세스가 완전히 프로덕션화되지 않았다고 README가 말하더라도, 오늘 기준으로 바이너리는 서명되고 타임스탬프가 찍혔으며 해시도 일치합니다. macOS 쪽은 별개의 문제이며 우리는 그곳의 공증을 검증하지 않았습니다. Windows 결과를 그대로 확대 해석하지 마십시오.

충돌 보고서, 그리고 알아 둘 만한 한 가지 세부 사항

크래시 보고서는 crash-<UTC time>-<source>.log 파일로 작성되어 ~/Library/Logs/DeepSeek Harness에 저장됩니다(macOS). Windows에서는 Electron userData 경로 아래 logs 디렉터리에 저장되며, 가장 최근 10개가 보관됩니다. 이 보관 개수는 문제가 될 만큼 적습니다. 문제가 반복적으로 발생하는데 며칠 동안 확인하지 않으면 첫 번째 실패를 설명해 줄 로그는 이미 사라진 뒤입니다. 간헐적으로 발생하는 문제를 디버깅하는 경우에는 디렉터리를 복사하세요.

손상된 구성의 복구 경로도 마찬가지로 구체적입니다. 셸은 cordis.patch.yml의 이름을 cordis.patch.yml.bak-<timestamp>로 변경하는데, 이때 파일을 파싱하지 않으므로 파일은 복구되지 않고 그대로 보존되며, 앱은 기본값으로 시작합니다. 해당 파일을 직접 편집했다면 편집한 내용은 .bak 파일에 들어 있으며 여전히 읽을 수 있습니다.

이 상황에서 앞서 나온 “데스크톱 앱 없음” 조언은 어떻게 되는가

2026년 8월에 하네스에는 데스크톱 애플리케이션이 없으며 Windows 사용자는 터미널 빌드를 실행해야 한다고 안내한 바 있습니다. 이는 당시에는 정확했지만 이제는 오래된 정보입니다. 터미널 빌드는 여전히 작동하며 서버, 컨테이너 또는 스크립트로 실행되는 모든 환경에 여전히 적합한 선택입니다. 달라진 점은 데스크톱 빌드가 단순한 껍데기가 아니라는 것입니다. 별도 프로필을 사용하고, 창을 닫아도 작업을 계속 유지하며, 자체 업데이트되고, 사용자에게 도움이 되는 방향으로 CLI와 상태를 공유합니다. 이전 글에서 데스크톱 빌드가 존재하지 않는다고 해서 미뤄 왔다면, 이제 그 이유는 사라졌습니다.

설치 단계 자체는 설치 안내에서 다루며, 여기서는 의도적으로 반복하지 않습니다. 다만 그 안내로는 알 수 없는 사실들이 있습니다. 세 가지 설치 프로그램 중 어느 것에 다운로드 페이지 링크가 없는지, 어느 대상이 한 릴리스 뒤처져 있는지, 선택해 들어갈 수 있는 안정적인 업데이트 채널이 없다는 점, 그리고 README에는 서명이 향후 릴리스에 속한다고 되어 있는데도 Windows 바이너리에 서명이 되어 있다는 점입니다. 이러한 사실들이 데스크톱 빌드를 설치하는 것이 옳은지 결정하며, 이 페이지가 별도로 존재하는 이유이기도 합니다.

아무것도 설치하고 싶지 않으시다면

모델 하나에 접근하려고 하네스를 설치하는 것은 작은 작업에 비해 너무 많은 설치·관리 요소를 만드는 일이며, 데스크톱 앱은 단일 업데이트 채널과 아무도 링크하지 않는 Intel 빌드를 갖춘 프리뷰입니다. 정말로 원하는 것이 DeepSeek-V4.1-Flash — 하네스가 기본으로 사용하는 모델이자 0.2.1-rc.2 릴리스 노트에서 지원이 추가된 바로 그 모델 — 라면, API 엔드포인트가 설치 프로그램도, 프로필 디렉터리도, 실행 중이라는 걸 기억해야 하는 트레이 아이콘도 없이 그 일을 해냅니다.

해야 할 비교는 추상적인 데스크톱 앱 대 API가 아닙니다. 그것은 작업이 창을 닫아도 워크스페이스를 열린 상태로 유지하고, 사용자 머신에서 스크립트를 실행하며, 세션을 몇 시간 동안 살아 있게 할 수 있는 에이전트를 원하는지 — 그렇다면 위의 패키징 문제는 감수할 가치가 있고 데스크톱 빌드가 그런 동작을 얻는 유일한 방법입니다 — 아니면 작업이 이미 다른 곳에서 서비스되는 모델에 대한 요청의 연속인지입니다. 두 번째 경우에는 모델 디렉터리가 더 짧은 경로이며, 이 글에서 그것을 바꾸는 내용은 없습니다.