공식 저장소는 DeepSeek Harness가 아직 개발자 미리 보기이며 호환성을 깨는 변경이 있을 수 있다고 안내합니다. 또한 Web UI를 띄우는 기본 명령과 작업 공간 선택은 별도 단계입니다. (github.com)

화면이 열린다 → 인수 완료로 처리하면 안 됩니다.
환경, 권한, 작업 공간, 모델, 도구, 복구, 인수 자료를 재현한 뒤 서명해야 합니다.

이 글은 클라우드 맥에서 DeepSeek Harness를 정식으로 넘겨받아야 하는 기술 구매 담당자, 개발자, 프로젝트 책임자, 운영팀을 위한 글입니다. 단순 시연이 아니라 실제 원격 실행을 계속할 수 있는지 판단하려는 경우에 맞습니다.

마지막 업데이트: 2026년 8월 18일. 공식 저장소와 사용자 안내 문서를 기준으로 확인했습니다. 클라우드 맥의 실제 구성, 지역, 재시작 결과는 제공 환경에서 별도 실측해야 합니다.

먼저 인수표를 만들고 환경 신원을 고정합니다

첫 화면을 보기 전에 인수 기록 파일을 만드십시오. 운영 체제나 장비 이름은 설정 화면의 상품명으로 추정하지 말고 실제 명령 결과를 저장해야 합니다.

sw_vers
uname -m
node --version
pnpm --version
git -C ~/deepseek-harness rev-parse HEAD

소스에서 설치했다면 저장소 경로와 커밋을 기록합니다. 패키지로 실행했다면 설치 명령과 실행 시각을 남깁니다. 공식 개발 문서는 Node.js 지원 범위, pnpm 버전 고정, Git 요구 조건을 별도로 설명합니다. 이 값은 배포 시점에 달라질 수 있으므로 현재 인수 환경의 결과를 우선해야 합니다. (github.com)

인수 항목 확인 동작 남길 증거 통과 조건
환경 신원 운영 체제와 런타임 명령 실행 명령 결과 파일 담당자가 다시 확인 가능
실행 방식 실행 명령과 경로 확인 셸 기록과 인수 화면 같은 방식으로 재실행
모델 연결 실제 최소 요청 전송 입력, 응답, 실패 기록 성공 신호가 재현됨
작업 공간 허용·차단 경로 테스트 파일 변화와 차단 로그 범위가 설명과 일치
재시작 세션과 설정을 저장한 뒤 재시작 전후 비교표 복구 여부가 구분됨

공식 Web UI 안내에 따르면 실행 디렉터리는 기본 파일 시스템 위치가 되지만, 새 Web UI에는 선택된 작업 공간이 없을 수 있습니다. 따라서 “실행 위치를 설정했다”는 설명만으로 작업 공간 인수를 끝내면 안 됩니다. (github.com)

접근 경로와 권한을 분리해서 확인합니다

클라우드 맥의 원격 로그인 권한과 DeepSeek Harness 내부의 승인 정책은 다른 층입니다. 원격 Mac 계정으로 접속할 수 있어도 모든 Agent 도구를 승인 없이 실행할 수 있다는 뜻은 아닙니다.

다음 순서로 확인하십시오.

  • 원격 접속 계정의 이름과 관리자 여부를 기록합니다.
  • 관리자 계정과 일반 계정을 나누어 로그인합니다.
  • Web UI가 어느 주소와 포트에서 열리는지 확인합니다.
  • 외부 네트워크에서 관리 화면이 노출되는지 점검합니다.
  • 다른 계정으로 작업 세션과 로그를 볼 수 있는지 확인합니다.
  • 인수 직후 비밀번호와 API 키를 누가 교체하는지 정합니다.
  • DeepSeek Harness의 승인 요청이 실제 명령 실행 전에 발생하는지 확인합니다.

공식 안내는 Web UI에서 모델 설정과 작업 실행을 분리하고, 권한 정책에 따라 승인이 필요한 작업을 묻는다고 설명합니다. 그러므로 로그인 성공, Web UI 접근, 명령 승인, 모델 키 사용을 각각 별도 증거로 남겨야 합니다. (github.com)

주의: 원격 데스크톱 화면이 보인다는 이유로 관리 권한까지 넘기지 마십시오. 인수 자료에는 계정별 권한과 교체 책임을 따로 적어야 합니다.

작업 공간 경계는 테스트 저장소로 증명합니다

작업 공간은 DeepSeek Harness가 읽고 수정할 수 있는 파일 범위를 결정합니다. 실제 프로젝트를 처음부터 넣지 말고 빈 테스트 저장소를 사용하십시오.

다음 파일을 준비합니다.

  • 읽어도 되는 파일
  • 수정해도 되는 파일
  • 읽기 전용으로 표시한 파일
  • 작업 공간 밖에 둔 파일
  • 접근 시 차단되어야 하는 민감한 경로

그 뒤 Agent에 같은 기준의 작업을 시킵니다. 파일 목록을 읽게 하고, 허용 파일만 수정하게 하며, 읽기 전용 파일과 상위 경로 접근을 시도하게 합니다. 각각의 결과를 저장합니다.

통과 기준은 “작업 디렉터리가 맞다”가 아닙니다. Agent가 실제로 볼 수 있는 범위, 바꿀 수 있는 범위, 차단되는 범위가 인수 설명과 일치해야 합니다. 파일 변화가 없었다면 성공으로 기록하지 말고, 명령이 실행되지 않았는지 권한 정책이 막았는지 구분하십시오.

모델과 도구 체인을 고정된 작업으로 시험합니다

모델 목록이 화면에 보이는 것만으로는 모델 연결이 끝난 것이 아닙니다. 공식 안내는 모델 키를 저장한 뒤 모델 경로를 사용할 수 있다고 설명하지만, 실제 작업에서는 응답과 도구 호출이 이어져야 합니다. (github.com)

고정 기준 작업을 하나 만드십시오.

  1. 짧은 응답을 요청합니다.
  2. 테스트 저장소의 특정 파일을 읽게 합니다.
  3. 허용된 파일에 한 줄의 변경을 요청합니다.
  4. 셸 명령 실행 전 승인 요청을 확인합니다.
  5. 명령 결과가 세션에 기록되는지 확인합니다.
  6. 변경 결과를 파일과 로그에서 대조합니다.
  7. 실패할 때 오류 신호가 남는지 확인합니다.

모델 키는 인수 문서에 평문으로 넣지 않습니다. 저장 위치, 교체 주체, 만료 또는 폐기 절차만 기록합니다. 공식 개발 문서도 키를 환경 변수나 무시 처리된 설정 파일에서 읽을 수 있지만 실제 자격 증명을 저장소에 커밋하지 말라고 안내합니다. (github.com)

모델 설정은 특히 다시 확인해야 합니다. 같은 DeepSeek Harness라도 모델 경로, 사용자 지정 API 주소, 사고 모드, 도구 호출 정책이 달라지면 결과가 달라질 수 있습니다. DeepSeek의 API 문서도 사고 모드와 요청 방식에 별도 설정이 필요하다고 설명합니다. (api-docs.deepseek.com)

재시작 뒤 남는 상태와 사라지는 상태를 나눕니다

지속 실행 목적이라면 재시작 시험을 인수 과정에 포함하십시오. 테스트 세션을 만들고 민감하지 않은 설정을 저장한 뒤 운영 담당자가 통제된 재시작을 수행합니다.

재접속 후 다음을 각각 확인합니다.

  • 이전 세션이 목록에 남아 있는지
  • 마지막 대화와 실행 결과를 다시 열 수 있는지
  • 작업 공간 선택이 유지되는지
  • 모델 설정이 남아 있는지
  • 플러그인 구성이 동일한지
  • 진행 중이던 작업이 재개되는지
  • 로그가 끊기거나 중복되지 않는지

공식 저장소는 Web UI, 모델, 세션과 같은 구성 요소가 플러그인 구조로 연결되고 개발자 미리 보기 상태라고 밝힙니다. 따라서 “항상 자동 복구된다”는 전제를 공식 문서만으로 만들 수 없습니다. 현재 버전의 실제 환경에서 전후 상태를 비교해야 합니다. (github.com)

조건에 따라 인수 결론을 나눕니다

  • 환경 명령 결과와 실행 커밋이 일치하면 정식 테스트로 진행합니다. 하나라도 없으면 환경 자료 보완으로 되돌립니다.
  • 허용 파일 수정과 차단 경로 테스트가 모두 재현되면 작업 공간을 통과시킵니다. 차단 근거가 없으면 제한 작업만 허용합니다.
  • 모델 응답, 도구 승인, 결과 쓰기가 모두 남으면 실제 업무 시험으로 넘어갑니다. 모델 목록만 보이면 통과시키지 않습니다.
  • 재시작 전후 상태가 같고 차이가 설명되면 지속 실행을 검토합니다. 복구 항목이 불명확하면 단기 세션으로 제한합니다.
  • 로그, 백업 범위, 회귀 방법이 문서화되면 서명 후보로 올립니다. 복구 책임자가 없으면 인수를 보류합니다.

FAQ: 클라우드 맥 인수에서 자주 놓치는 부분

위 조건을 적용하면 클라우드 맥에서 원격 실행하는 업무와 단순 접속 시연을 구분할 수 있습니다. 특히 개발자 미리 보기 소프트웨어는 업데이트 때 동작이 달라질 수 있으므로, 인수일의 커밋과 테스트 결과를 함께 보관해야 합니다. 공식 저장소도 호환성을 깨는 변경 가능성을 명시하고 있습니다. (github.com)

운영 자료와 인수 서명을 하나의 묶음으로 정리합니다

최종 인수 묶음에는 다음 자료가 들어가야 합니다.

  • 운영 체제와 런타임 버전 결과
  • DeepSeek Harness 설치 경로와 커밋 또는 태그
  • 실행 명령과 접속 방식
  • 원격 계정별 권한
  • 모델 연결 확인 결과
  • 작업 공간 경계 테스트 기록
  • 명령 승인과 도구 호출 기록
  • 재시작 전후 상태 비교
  • 로그를 받는 방법
  • 백업 대상과 제외 대상
  • 업데이트 책임과 변경 승인 절차
  • 문제 발생 시 이전 상태로 돌아가는 방법

복구 시간을 실제로 측정하지 않았다면 “몇 분 안에 복구”처럼 보장 문구를 쓰지 마십시오. 대신 “재설치 필요”, “설정 재주입 필요”, “백업에서 복원 가능”처럼 확인된 상태를 적습니다. 민감한 키와 토큰은 인수 문서에서 제거하고, 인수 직후 교체 여부만 체크합니다.

결론은 세 가지로 나누면 됩니다.

  • 통과: 핵심 시험을 다른 담당자가 다시 실행해 같은 결과를 얻음
  • 기한부 수정: 업무 시작 전 해결할 결함과 책임자, 기한이 명확함
  • 서명 거절: 환경 신원, 권한 경계, 모델 호출, 복구 중 하나라도 증거가 없음

DeepSeek Harness의 클라우드 맥 배포 흐름을 검토할 때도 같은 기준을 적용하십시오. 지역별 접속 조건이 중요하다면 서울 원격 맥 주문 안내나 버지니아 원격 맥 주문 안내를 확인하되, 페이지에 적힌 이용 가능성만으로 실제 복구 능력까지 추정해서는 안 됩니다.

현재 환경을 직접 구성하는 방식은 버전 고정, 권한 설계, 백업 구축을 모두 직접 맡아야 하고, 일반적인 가상 서버는 Mac 전용 도구와 원격 화면 운영에서 별도 조정이 필요합니다. 반대로 MACCOME의 클라우드 맥을 검토할 때는 먼저 동시 작업 수, 격리 범위, 필요한 원격 접속 방식, 예상 임대 기간을 제출하고 이 글의 인수표로 실제 전달 환경을 확인하는 편이 안전합니다. 검증되지 않은 구성이나 복구 능력을 먼저 약속하기보다, 같은 항목을 통과한 환경만 지속 Agent 업무에 투입해야 합니다.