브라우저에서는 페이지가 열리는데 DeepSeek Harness 작업이 API, Git, MCP 단계에서 멈춥니다.
가장 빠른 해결법은 웹페이지 접속을 중단하고, 실제 실행 계정으로 모델 API·코드 저장소·의존성 원본·외부 도구를 각각 검수하는 것입니다.
이 검수는 누구에게 필요한가
클라우드 맥을 구매하거나 임대하고, 네트워크 조건을 납품 기준에 넣어야 하는 기술 책임자에게 필요합니다.
DeepSeek Harness를 배포하는 운영자는 상위 API, Git, 패키지 관리자, MCP Server의 장애를 분리할 수 있습니다.
기업 프록시나 출구 허용 목록을 사용하는 개발자는 무인 작업에서도 같은 연결이 유지되는지 확인할 수 있습니다.
DeepSeek Harness 네트워크 출구 검수의 기준은 단순합니다. DNS, TLS, 프록시 실행 주체, 인증, 상위 응답을 증거로 남겨야 합니다. 핵심 연결이 임시 셸 변수나 수동 키 입력에 의존한다면 지속 운영 검수는 통과시키지 않는 편이 맞습니다.
먼저 검수 범위를 고정하고 허용 목록을 만들기
DeepSeek Harness는 모델을 호출하고, 작업 공간에 접근하며, 명령을 실행하고, 외부 도구와 연결될 수 있습니다. 그러나 모든 프로젝트가 같은 외부 주소를 필요로 하지는 않습니다. Provider, 사설 저장소, 패키지 관리자, MCP Server의 전송 방식에 따라 대상이 달라집니다.
따라서 처음부터 통합된 고정 도메인 목록을 만들지 말고 다음 항목을 프로젝트별로 작성합니다.
- 모델 호출: 사용하는 DeepSeek API 방식과 모델 식별자
- 코드 관리: SSH 또는 HTTPS 방식, 저장소 읽기와 제한된 쓰기 여부
- 의존성: Node.js 실행 파일, 프로젝트 패키지 관리자, 내부 또는 외부 패키지 저장소
- 외부 도구: MCP Server의 전송 방식과 실제로 접근하는 자료원
- 기업망: 프록시 적용 대상, 내부 DNS, 인증서 신뢰 정책, 프록시를 사용하지 않을 로컬 주소
- 복구 조건: 재시도, 중단, 대기, 중복 실행 방지 방식
DeepSeek API는 Bearer 인증을 사용하고, 모델 목록과 채팅 응답에는 모델 식별자와 사용량 정보가 포함될 수 있습니다. 검수 로그에는 키 자체를 남기지 말고 응답 상태, 오류 단계, 모델 식별자 정도만 남깁니다. 자세한 요청 형식은 DeepSeek API 인증 문서와 채팅 응답 문서를 기준으로 확인합니다.
인수 여부를 바로 결정하는 검수 목록
아래 목록은 결과를 단순한 “접속 가능”으로 묶지 않고, 실제 납품 승인 여부를 판단하기 위한 도구입니다. 각 항목을 체크한 뒤 하나라도 거부 조건에 해당하면 전체 인수가 아니라 해당 시나리오의 부분 보류로 처리합니다.
즉시 승인할 수 있는 조건
- [ ] 모델 API 요청이 실제 Harness 실행 계정에서 성공했습니다.
- [ ] API 요청의 DNS, TLS, 인증, 상위 응답 단계가 각각 기록됐습니다.
- [ ] Git 저장소의 발견, 참조 읽기, 필요한 경우 제한된 전송을 별도로 확인했습니다.
- [ ] 캐시를 비운 뒤 Node.js와 프로젝트 의존성을 다시 구성했습니다.
- [ ] MCP Server의 발견, 읽기 전용 호출, 반환, 취소 결과를 확인했습니다.
- [ ] 기업 프록시와 인증서 설정이 대화형 터미널이 아니라 지속 프로세스에도 전달됩니다.
- [ ] 원격 Mac을 재시작한 뒤 핵심 연결을 다시 재현했습니다.
- [ ] 로그에 실제 토큰, 개인 키, 고객 저장소 내용이 없습니다.
조건부 승인으로 낮춰야 하는 경우
- 웹페이지는 열리지만 명령행 Git 또는 DeepSeek API가 실패합니다.
- 대화형 셸에서는 연결되지만 백그라운드 작업에서는 프록시가 사라집니다.
- 기존 캐시가 있을 때만 의존성 설치가 성공합니다.
- MCP Server는 시작되지만 외부 자료원 호출 결과가 없습니다.
- 네트워크 단절 뒤 작업 상태와 재시도 방식이 확인되지 않았습니다.
- 테스트는 성공했지만 실행 계정, 시각, 대상, 회귀 절차가 기록되지 않았습니다.
즉시 거부해야 하는 경우
- TLS 검증을 끄거나 기업 인증서를 우회해야만 연결됩니다.
- 실제 키나 개인 키를 로그, 화면 캡처, 인수 문서에 넣어야 합니다.
- 사람이 매번 프록시 변수나 인증 정보를 수동으로 입력해야 합니다.
- 고객 저장소에 대한 쓰기 작업을 시험하면서 복구와 중복 실행을 통제하지 못합니다.
- 원격 Mac 재시작 뒤 같은 작업을 재현할 수 없습니다.
이 기준에서 핵심 연결이 모두 통과하고, 민감 정보가 보호되며, 재시작 후 재현까지 확인되면 정식 인수로 이동합니다. 그렇지 않으면 실패한 구간만 수정한 뒤 같은 증거 형식으로 재검수합니다.
모델 API는 화면이 아니라 최소 요청으로 검수하기
검수 대상
민감한 데이터가 없는 짧은 요청 한 건입니다. Harness가 실제로 실행되는 계정과 프로세스에서 요청해야 합니다. 브라우저의 로그인 상태나 개발자 노트북의 환경 변수를 복사하면 안 됩니다.
성공 증거
다음 순서가 모두 확인되어야 합니다.
- 대상 이름이 DNS로 해석됩니다.
- TLS 연결이 기업 인증서 정책에 맞게 성립합니다.
- Harness 프로세스가 자격 증명을 읽습니다.
- 상위 서비스가 인증 요청을 처리합니다.
- 모델 응답과 종료 상태가 기록됩니다.
- 요청이 사용한 실행 계정과 실행 시각이 남습니다.
DeepSeek API의 공식 문서에는 OpenAI 형식의 기본 API 주소와 채팅 응답 경로가 설명되어 있습니다. 다만 실제 검수에서는 문서의 예시 주소를 무조건 전체 허용 목록으로 확대하지 말고, 현재 프로젝트가 사용하는 Provider 설정과 버전을 기준으로 대상 범위를 확정해야 합니다. 공식 모델 및 API 주소 문서를 함께 대조합니다.
실패를 나누는 방법
- DNS 단계에서 실패하면 이름 해석, 내부 DNS, 출구 정책을 확인합니다.
- TLS 단계에서 실패하면 인증서 신뢰 체인과 프록시 중간 검사를 확인합니다.
- 인증 단계에서 실패하면 키의 유효성, 계정 권한, 사용 모델 권한을 확인합니다.
- 상위 응답이 오류를 반환하면 서비스 상태나 요청 형식을 별도로 확인합니다.
- Harness만 실패하면 환경 변수, 프로세스 권한, 설정 파일 상속을 확인합니다.
거부 기준
화면에 답변이 보였다는 이유만으로 통과시키지 않습니다. 실제 실행 계정에서 요청되지 않았거나, 실패 단계가 기록되지 않았거나, 키가 로그와 화면 캡처에 노출됐다면 거부합니다.
Git은 웹페이지와 백그라운드 인증을 따로 확인하기
사설 코드 저장소 페이지가 브라우저에서 열린다고 Git 연결이 성공한 것은 아닙니다. Harness는 별도의 SSH 키, HTTPS 자격 증명, 에이전트 소켓 또는 서비스 계정을 사용할 수 있습니다.
검수 대상
- 원격 저장소 주소 발견
- 제한된 범위의 복제 또는 가져오기
- 원격 참조 읽기
- 테스트용 변경 사항의 제한된 전송
- 백그라운드 프로세스에서 동일한 인증 사용
Git은 SSH와 HTTPS를 포함한 여러 전송 방식을 지원합니다. 저장소 복제 후 원격 참조가 만들어지고, 가져오기와 전송은 서로 다른 권한과 경로를 사용할 수 있습니다. Git 복제 공식 문서를 기준으로 복제와 참조 읽기를 분리해 기록합니다.
성공 증거와 거부 조건
성공 증거는 저장소 이름이 아니라 테스트 저장소의 식별자, 현재 참조, 실행 계정, 명령 결과 코드입니다. 고객 저장소 파일이나 실제 토큰은 증거에 포함하지 않습니다.
브라우저 인증만 성공하고 명령행 Git이 실패하면 거부합니다. SSH는 되지만 HTTPS 기반 자동화가 실패하거나, 읽기는 되지만 제한된 전송 권한이 없으면 그 범위만 부분 실패로 기록합니다. GIT_SSL_NO_VERIFY처럼 인증서 검증을 끄는 설정은 해결책으로 사용하지 않습니다. Git 공식 문서도 이 환경 변수가 HTTPS 인증서 검증을 끄는 동작임을 설명하므로, 발견 즉시 보안 검토 대상으로 분류해야 합니다. Git 환경 변수 문서를 참고합니다.
Node.js와 의존성은 캐시 삭제 후 다시 만들기
첫 설치가 성공했다는 결과만으로는 납품할 수 없습니다. 기존 캐시와 개인 터미널에서 임시로 설정한 프록시가 성공을 숨길 수 있기 때문입니다.
다섯 단계 재현 절차
- Harness와 프로젝트의 Node.js 실행 위치를 기록합니다.
- 현재 패키지 관리자와 저장소 설정을 확인합니다.
- 별도 작업 폴더에서 초기 설치 또는 갱신을 실행합니다.
- 의존성 캐시를 비운 상태에서 같은 작업을 반복합니다.
- 재시작 후 지속 프로세스에서 다시 설치 또는 필요한 패키지 조회를 실행합니다.
npm은 HTTP_PROXY, HTTPS_PROXY 계열 환경 변수와 설정 파일의 프록시 값을 사용할 수 있습니다. 따라서 대화형 터미널에서만 설정된 프록시 변수는 전달 방식이 확인되지 않는 한 납품 조건으로 인정하지 않습니다. npm 프록시와 저장소 설정 문서에서 프로젝트 설정과 서비스 설정을 구분해 확인합니다.
실패 분류
- 저장소 이름 해석 실패: DNS 또는 출구 정책
- TLS 검증 실패: 인증서 신뢰 또는 프록시 검사
- 패키지 조회 실패: 저장소 주소, 프록시, 인증
- 설치 후 실행 실패: Node.js 버전, 네이티브 의존성, 권한
- 캐시 삭제 후 실패: 초기 구축 경로가 재현되지 않음
개인 단말에서 한 번 내보낸 프록시 변수, 수동으로 복사한 인증 파일, 사람의 개입이 필요한 일회성 설치는 모두 “재현 불가”로 표시합니다.
MCP Server는 세 구간으로 나눠 호출하기
MCP는 애플리케이션과 외부 자료원 및 도구를 연결하는 표준 프로토콜입니다. MCP Server 프로세스가 로컬에서 시작됐다는 사실은 외부 데이터 원본까지 연결됐다는 뜻이 아닙니다.
검수 대상
읽기 전용 도구 하나를 선택합니다.
- Harness가 MCP Server를 발견하는지 확인합니다.
- 도구 이름과 입력 형식을 읽습니다.
- 민감하지 않은 입력으로 호출합니다.
- 반환값의 구조와 출처 구간을 기록합니다.
- 실행 중 취소했을 때 중단 또는 취소 응답을 확인합니다.
MCP 표준은 로컬 프로세스를 통한 표준 입출력 방식과 HTTP 기반 전송 방식을 정의합니다. 전송 방식에 따라 프록시, 세션, 인증서, 연결 유지 조건이 달라집니다. MCP 전송 방식 공식 문서를 기준으로 현재 서버의 방식을 먼저 확정합니다.
실패 구간별 판단
- Harness에서 MCP Server 발견 자체가 안 됨: 실행 경로, 권한, 설정 파일, 표준 입출력
- 도구 목록은 보이지만 호출이 실패함: 입력 형식, 서버 내부 오류, 세션
- MCP Server가 실행되지만 자료를 반환하지 못함: 서버에서 외부 자료원으로 나가는 연결
- 인증 오류가 발생함: MCP 자격 증명 또는 상위 서비스 권한
- 취소 후에도 부작용이 남음: 도구의 취소 처리와 중복 실행 방지
읽기 전용 도구가 아니라 쓰기 도구를 첫 검수 대상으로 선택하면 실패 원인을 확인하기 전에 실제 변경이 발생할 수 있습니다. 초기 인수에서는 데이터 조회와 취소를 먼저 통과시키고, 변경 작업은 별도의 승인 절차로 분리합니다. MCP 도구와 안전 원칙 문서를 확인합니다.
기업 프록시와 내부 DNS는 실행 계정 기준으로 검수하기
가장 흔한 실패는 대화형 터미널에서는 연결되지만 지속 프로세스에서는 연결되지 않는 경우입니다. 원인은 프록시 환경 변수, 인증서 저장소, DNS 설정, 서비스 계정의 권한이 서로 다르기 때문입니다.
다음 정보를 실행 시점에 기록합니다.
- 어떤 계정이 Harness를 실행했는지
- 어떤 방식으로 프로세스가 시작됐는지
- 프록시 설정이 어디에서 상속됐는지
- 내부 이름과 외부 이름이 각각 어떤 DNS 경로를 사용하는지
- 인증서 신뢰가 사용자 저장소인지 시스템 저장소인지
- 프록시를 통과하지 않아야 하는 로컬 주소가 무엇인지
기업 인증서를 우회하거나 TLS 검증을 끄는 방식은 승인 기준에 포함하지 않습니다. 인증서 체인이 맞지 않으면 올바른 신뢰 저장소와 중간 프록시 정책을 조정해야 합니다. 연결은 되지만 백그라운드 작업에서만 실패한다면 같은 계정으로 재시작 후 재검수합니다.
단절 복구는 짧은 중단과 재시작으로 확인하기
네트워크를 잠시 끊고 Harness 작업의 상태를 확인합니다. 작업이 중단되는지, 재시도하는지, 대기하는지, 같은 변경을 반복하는지를 기록합니다.
검수 순서는 다음과 같습니다.
- 모델 요청 중단 후 중복 응답 여부를 확인합니다.
- Git 가져오기 중단 후 저장소 상태를 확인합니다.
- 의존성 설치 중단 후 잠금 파일과 설치 폴더를 확인합니다.
- MCP 읽기 호출 중단 후 외부 자료원에 변경이 남았는지 확인합니다.
- 원격 Mac을 재시작하고 같은 작업을 다시 실행합니다.
MCP의 취소는 도구와 전송 방식에 따라 협력적으로 처리될 수 있습니다. 따라서 “취소 버튼을 눌렀다”가 아니라 서버가 취소를 받았는지, 작업이 종료됐는지, 외부 부작용이 없는지를 확인해야 합니다. MCP 취소 동작 공식 문서와 작업 취소 문서를 함께 참고합니다.
인수 서류는 결과보다 증거 구조를 본다
최종 전달 자료에는 다음 항목을 포함합니다.
- 테스트 시각
- 원격 Mac의 대상 유형과 운영 환경
- 실행 계정과 프로세스 시작 방식
- 각 시나리오의 성공 또는 실패 결과
- DNS, TLS, 인증, 상위 응답 단계
- 사용한 테스트 저장소와 읽기 또는 쓰기 범위
- 캐시 삭제 후 재구축 결과
- MCP 발견, 호출, 반환, 취소 결과
- 실패 시 회귀 또는 대체 절차
- 로그에서 민감 정보가 제거됐다는 확인
검수 도구를 선택할 때는 다음 대조 목록을 사용합니다.
- 웹페이지 접속만 가능한 경우: 브라우저 기반 확인에는 적합하지만 DeepSeek API, Git 자격 증명, 백그라운드 프록시를 증명하지 못하므로 인수에 부적합합니다.
- 대화형 터미널만 가능한 경우: 초기 장애 분석에는 쓸 수 있지만 무인 실행의 환경 상속을 증명하지 못하므로 조건부 승인만 가능합니다.
- 실제 Harness 프로세스에서 모든 핵심 연결을 재현한 경우: DNS, TLS, 인증, 상위 응답과 재시작 결과를 남겼다면 지속 운영 인수 대상으로 검토할 수 있습니다.
네 가지 핵심 연결이 모두 통과하고, 민감 정보가 로그에 들어가지 않으며, 재시작 뒤 같은 결과를 재현해야 최종 서명을 진행합니다.
자가 운영과 원격 Mac 임대 중 선택하기
직접 보유한 장비나 일반 서버에서 DeepSeek Harness를 운영하면 네트워크 정책과 장기 비용을 직접 통제할 수 있습니다. 반면 초기 출구 설정, 인증서 신뢰, 지속 프로세스, 단절 복구를 모두 직접 관리해야 합니다. 사내 장비는 물리 인터페이스나 장기 고정 부하가 필요할 때 더 적합할 수 있습니다.
반대로 임시 프로젝트, 이전 검증, 공급망 테스트처럼 빠르게 원격 Mac이 필요한 경우에는 MACCOME의 원격 Mac 제공 방식을 검토할 수 있습니다. 맥 미니 주문 페이지를 확인하더라도, 실제 계약 전에는 이 글의 네 가지 최소 연결을 먼저 실행해야 합니다.
특히 현재 환경이 브라우저 접속에만 의존하거나, 개인 노트북의 프록시 변수를 복사하거나, 매번 사람이 키를 입력해야 한다면 장기 운영에 불리합니다. 이런 조건에서는 원격 Mac 임대가 테스트 환경을 빠르게 분리하는 선택지가 될 수 있습니다. 단, 장기간의 고정 부하와 물리 장치 접근이 핵심이라면 직접 구매가 더 맞을 수 있습니다.
정식 저장소와 실사용 자격 증명을 옮기기 전에 빈 네트워크 증거 기록지를 만들어 모델 API, Git, 의존성, MCP의 최소 연결부터 검수하시기 바랍니다. 하나라도 임시 설정에 의존하면 승인 대신 실패 구간과 회귀 조치를 먼저 정리해야 합니다.