2026년 8월 18일 기준 공개 저장소는 딥시크 하니스를 아직 개발자 미리보기로 설명하며 호환성 변경 가능성을 명시합니다. 따라서 이번 주에는 시험 작업 1개를 실행하는 데서 멈추지 말고, 소유권 격리·상태 확인·취소·완료 알림·연결 단절·재시작 복구까지 증거로 확인한 뒤에만 운영 작업을 올리십시오. (github.com)
이 글은 딥시크 하니스에 긴 빌드와 테스트를 맡기려는 개발자, 지속적인 인공지능 에이전트 환경을 관리하는 운영자, 작업을 여러 환경으로 나눌지 결정해야 하는 프로젝트 책임자를 위한 글입니다.
최종 갱신: 2026년 8월 18일. 공개 저장소, 사용자 안내서, 구조 문서와 현재 배포 상태를 기준으로 내용을 확인했습니다. 작업 처리 방식이나 저장 의미가 바뀌면 같은 검수표로 다시 시험해야 합니다.
SECTION 01 검수 일정과 합격선
검수는 다음 순서로 진행하는 것이 좋습니다.
- 1단계: 작업 생성과 소유권 확인
- 2단계: 실행 중 상태와 산출물 연결 확인
- 3단계: 취소, 시간 초과, 하위 프로세스 정리 확인
- 4단계: 성공·실패·취소 알림 확인
- 5단계: 브라우저 종료, 원격 연결 중단, 하니스 종료, 운영 체제 재시작 시험
- 6단계: 동시 실행에 따른 자원 변화와 최종 운영 판정
가장 중요한 전제는 간단합니다. 백그라운드로 시작된다는 사실은 다른 프로세스나 재시작 이후에도 자동으로 이어진다는 뜻이 아닙니다. 공개 저장소의 개발자 미리보기 상태도 고정된 운영 계약으로 해석해서는 안 됩니다. (github.com)
합격 기준은 “작업이 한 번 끝났다”가 아닙니다. 작업을 누가 볼 수 있는지, 현재 무엇을 하는지, 어떻게 멈추는지, 완료가 무엇으로 증명되는지, 장애 뒤에 어디까지 복구되는지를 모두 설명할 수 있어야 합니다.
SECTION 02 소유권과 작업 공간 격리
작업 번호를 발급한다고 해서 권한 격리가 끝난 것은 아닙니다. 다음 두 개의 통제된 세션을 준비하십시오.
- 세션 가에서 작업을 생성합니다.
- 세션 나에서 작업 목록과 상태를 조회합니다.
- 세션 나가 세션 가의 작업을 기다리거나 취소할 수 있는지 확인합니다.
- 두 세션의 작업 공간에 서로 다른 표시 파일을 만듭니다.
- 로그, 산출물, 잠금 파일이 섞이지 않는지 기록합니다.
판정은 세 가지로 나누면 됩니다.
- 세션 나가 작업의 존재조차 볼 수 없음: 소유권 경계가 확인됨
- 작업은 보이지만 조회만 가능함: 관찰 권한과 제어 권한이 분리됨
- 다른 세션이 기다리기, 취소하기, 파일 수정까지 가능함: 장기 작업 투입 보류
공개 사용자 안내서는 하니스가 작업 공간을 선택한 뒤 파일을 읽고 수정하며 명령을 실행한다고 설명합니다. 그러므로 작업 격리는 작업 번호뿐 아니라 작업 공간 경로, 운영 계정, 파일 권한까지 함께 검수해야 합니다. (github.com)
검수 자료에는 세션 식별자, 작업 식별자, 조회 결과, 취소 결과, 파일 목록을 남기십시오. 화면 사진만 남기지 말고 원문 출력도 보관해야 버전 변경 뒤 비교할 수 있습니다.
SECTION 03 상태 관찰과 완료 증거
장시간 작업에서 가장 비싼 장애는 실패 자체가 아니라 “지금 어디까지 진행됐는지 모르는 상태”입니다. 작업마다 다음 정보를 연결할 수 있어야 합니다.
- 작업 입력 또는 실행 목적
- 실행한 작업 공간
- 현재 상태와 마지막 갱신 시점
- 최근 로그 또는 단계 정보
- 생성된 산출물의 경로
- 성공·실패·취소를 입증하는 최종 기록
공개 문서에는 웹 화면에서 작업 공간을 선택하고 에이전트가 파일과 명령을 다룬다고 적혀 있습니다. 그러나 화면에 작업이 보인다는 것만으로 실제 하위 프로세스가 살아 있다는 뜻은 아닙니다. 상태 화면, 운영 체제 프로세스 목록, 로그 파일, 산출물의 수정 시점을 서로 대조하십시오. (github.com)
다음 조건이면 납품 합격으로 처리하지 마십시오.
- 작업 상태는 끝났지만 산출물이 없음
- 산출물은 있지만 어느 작업이 만들었는지 연결되지 않음
- 마지막 로그가 오래되었지만 실행 중으로 표시됨
- 재접속 뒤 작업은 보이지만 입력과 작업 공간을 확인할 수 없음
모델 설정이나 세션 저장 위치가 바뀌면 같은 작업이라도 결과가 달라질 수 있습니다. 공개 개발 문서가 환경 변수, 작업 공간, 실제 API 시험 조건을 별도로 다루는 이유도 여기에 있습니다. (github.com)
SECTION 04 취소와 시간 초과 제어
취소 시험은 한 번만 하지 말고 세 가지 상황으로 나누십시오.
정상 취소
작업이 로그를 계속 남기는 동안 취소를 요청합니다. 합격하려면 상태만 바뀌는 것이 아니라 관련 하위 프로세스, 파일 쓰기, 네트워크 요청이 실제로 멈춰야 합니다.
무응답 작업
로그 갱신을 멈춘 작업을 준비합니다. 상태 조회가 계속 가능한지, 취소 요청이 반환되는지, 운영자가 별도 조치를 취해야 하는지 기록합니다. 시간 초과 값은 제품 설명이나 실제 시험 환경과 날짜가 함께 있을 때만 운영 기준으로 사용하십시오.
하위 프로세스 잔류
하니스가 취소 상태를 표시한 뒤에도 빌드 도구, 테스트 실행기, 파일 변환기가 남아 있는지 확인합니다. 잔류 프로세스가 있으면 다음 작업의 성능과 저장 공간을 잠식할 수 있습니다.
공개 개발 문서는 현재 설치와 실행에 필요한 런타임 조건, 검사 명령, 실제 API 시험 조건을 버전별로 관리합니다. 따라서 취소와 시간 초과 결과에는 하니스 버전, 실행 환경, 시험 입력, 확인한 프로세스 목록을 함께 붙이십시오. (github.com)
SECTION 05 완료 알림과 복구 절차
완료 알림은 세 종류로 나누어 확인하십시오.
- 성공 알림: 산출물이 완전히 기록된 뒤 발생하는가
- 실패 알림: 실패 원인과 마지막 로그 위치를 포함하는가
- 취소 알림: 실제 프로세스 종료 뒤 발생하는가
알림이 먼저 오고 산출물이 나중에 기록된다면 무인 운영에는 위험합니다. 알림을 받은 즉시 파일 크기, 수정 시점, 검증 결과를 확인하는 후속 절차를 두십시오.
알림이 누락되었을 때의 수동 순회 경로도 필요합니다.
- 작업 목록을 조회합니다.
- 마지막 상태 갱신 시점을 확인합니다.
- 로그의 마지막 줄과 프로세스 상태를 비교합니다.
- 산출물의 완전성을 검사합니다.
- 일정 시간이 지나도 변화가 없으면 정상 취소 절차로 이동합니다.
이 과정은 VPSNIX 도움말 센터의 접속·운영 안내와 함께 내부 인수 문서에 넣어 두는 편이 좋습니다.
SECTION 06 연결 단절과 재시작 시험
브라우저 종료, 원격 연결 중단, 하니스 프로세스 종료, 운영 체제 재시작은 각각 따로 시험해야 합니다. 하나의 성공 결과를 다른 장애 유형에 확대하면 안 됩니다.
| 시험 항목 | 확인할 행동 | 남겨야 할 증거 | 운영 판정 |
|---|---|---|---|
| 브라우저 종료 | 화면을 닫고 다시 접속 | 작업 상태, 로그, 산출물 | 다시 관찰 가능해야 함 |
| 원격 연결 중단 | 원격 접속을 끊고 재연결 | 작업 지속 여부와 파일 변화 | 연결 없이 실행되는지 확인 |
| 하니스 종료 | 관련 프로세스를 종료 | 재실행 뒤 작업 식별과 로그 | 자동 복구를 가정하지 않음 |
| 운영 체제 재시작 | 재시작 전후 비교 | 중간 산출물, 잠금, 재개 결과 | 실제 재개 증거가 있어야 함 |
| 저장 공간 압박 | 대표 작업을 동시 실행 | 용량, 오류, 반응성 | 환경 분리 또는 작업 축소 |
특히 원격 맥은 접속 경로가 안정적이어도 운영 체제 재시작과 프로세스 종료를 스스로 막아 주지 않습니다. 재시작 이후 자동으로 이어진다는 공식 계약이나 실제 시험 증거가 없다면, 미완료 작업은 새 작업으로 다시 시작해야 하는 것으로 설계하십시오.
원격 맥 환경을 고르는 기준을 검토할 때도 “연결 가능”과 “장기 작업 복구 가능”을 분리해 확인해야 합니다.
SECTION 07 용량과 최종 운영 판정
대표 작업 하나만으로는 용량을 판단할 수 없습니다. 빌드, 테스트, 코드 분석, 파일 일괄 처리처럼 성격이 다른 작업을 준비하고, 동시에 실행하면서 다음 변화를 기록하십시오.
- CPU 사용량의 지속 변화
- 메모리 압박과 스왑 사용
- 저장 공간 증가와 임시 파일
- 작업 공간 잠금 충돌
- 상태 조회와 웹 화면의 반응성
- 취소 요청이 실제로 반환되는지 여부
특정 숫자 임계값을 미리 정하지 말고, 현재 환경에서 대표 작업이 안정적으로 끝나는지 기준을 먼저 정하십시오. 운영 결론은 다음 세 가지면 충분합니다.
- 운영 가능: 각 작업의 소유권, 상태, 취소, 알림, 복구 증거가 있고 동시 실행에서도 산출물이 온전함
- 환경 분리 필요: 작업끼리 파일이나 자원을 공유할 때만 문제가 생김
- 지속 실행 부적합: 재시작·취소·알림 중 하나라도 확인할 수 없거나 복구가 수동 재구성에 의존함
서명 자료에는 기준 작업, 하니스 버전, 운영 체제 버전, 작업 공간 경로, 동시 실행 조건, 재시험 날짜, 담당자를 넣으십시오. 공개 저장소가 개발자 미리보기이며 호환성 변경을 예고한 상태에서는 이 기록이 다음 배포를 비교하는 기준점이 됩니다. (github.com)
SECTION 08 이번 주 실행 순서
이번 주에는 작은 작업으로 다음 순서를 그대로 실행하십시오.
- 격리된 두 세션과 두 작업 공간을 준비합니다.
- 같은 종류의 기준 작업을 각각 생성합니다.
- 작업 목록, 상태, 로그, 산출물을 서로 대조합니다.
- 정상 취소와 무응답 취소를 각각 실행합니다.
- 브라우저 종료와 원격 연결 중단을 차례로 시험합니다.
- 하니스 종료와 운영 체제 재시작 뒤 상태를 비교합니다.
- 동시 실행 결과를 서명 자료로 묶고 운영·분리·보류 중 하나를 선택합니다.
현재 방식이 개인 맥이나 공유 원격 환경이라면 파일 충돌, 접속 단절, 프로세스 잔류, 재시작 뒤 복구 불확실성이 장기 작업의 실제 비용이 됩니다. 반대로 독립된 원격 맥을 쓰면 작업 공간과 사용 시간을 분리해 같은 기준 작업으로 먼저 시험할 수 있습니다. 다만 장기 고정 부하가 계속되거나 물리 장치 접근이 필요한 경우에는 임대보다 직접 보유 환경이 맞을 수 있습니다.
단기 빌드, 테스트, 코드 분석처럼 점검 가능한 시간 창만 필요하다면 VPSNIX의 맥 환경 및 이용 안내를 확인한 뒤, 기존 환경과 같은 기준 작업으로 먼저 시운전하십시오. 검수표에서 복구와 격리가 통과된 뒤에만 실제 무인 작업을 옮기는 방식이 가장 안전합니다.