딥시크 하니스 계획 모드 선택 기준

직접 실행과 계획 모드는 기능 이름으로 고르는 것이 아니라 변경의 되돌림 비용과 책임 구조로 골라야 합니다. 공식 저장소는 현재 개발자 미리보기 상태이며 호환성이 깨지는 변경이 있을 수 있다고 안내합니다. 따라서 특정 화면, 기본 동작, 자동 전환 규칙을 고정된 사실로 취급해서는 안 됩니다. 공식 저장소의 개발자 미리보기 안내와 공식 실행 안내를 작업 전 확인하는 것이 우선입니다. (github.com)

직접 실행은 빠르지만, 작은 수정이라는 판단이 틀렸을 때 손상이 즉시 작업 공간에 남습니다. 계획 모드는 검토 시간을 추가하지만, 누가 무엇을 승인했는지 남길 수 있습니다. 다만 계획 모드 자체가 민감한 파일과 자격 증명을 격리해 주는 것은 아닙니다.

독립 개발자는 모든 작업을 계획 모드로 보내면 오히려 흐름이 느려집니다. 다음 조건을 모두 만족할 때만 직접 실행을 기본값으로 삼는 편이 합리적입니다.

• [ ] 수정 대상이 한 파일 또는 명확히 연결된 소수 파일입니다.
• [ ] 공개된 인터페이스, 데이터베이스 구조, 배포 설정을 바꾸지 않습니다.
• [ ] 변경 전후를 비교할 수 있는 테스트나 검사 명령이 있습니다.
• [ ] 실패하면 한 번의 되돌리기 또는 짧은 복구 작업으로 원상 복구할 수 있습니다.
• [ ] 작업 공간에 승인받지 않은 변경이 이미 남아 있지 않습니다.

하나라도 충족하지 못하면 먼저 계획 모드로 전환합니다. 특히 코드 리팩터링은 파일 수보다 호출 관계와 외부 계약이 더 중요합니다. 이름을 바꾸는 작업처럼 보여도 여러 패키지의 가져오기 경로, 테스트 픽스처, 문서 예제가 함께 깨질 수 있습니다.

계획 결과는 실행 명령이 아니라 검토 가능한 가설입니다. 계획 문서에 적힌 파일 경로가 실제 저장소의 현재 상태와 일치하는지, 제안된 검증 명령이 현재 프로젝트에서 실행되는지 확인해야 합니다.

처음 보는 저장소에서는 곧바로 수정하지 않는 것이 좋습니다. 계획 모드에서 다음 다섯 단계를 순서대로 진행합니다.

1. 진입점 확인: 실행 파일, 기본 패키지, 서버 시작점, 주요 작업 흐름을 찾습니다.
2. 의존 관계 확인: 수정 후보가 어떤 모듈과 설정을 읽고 쓰는지 추적합니다.
3. 검증 명령 확인: 읽기 전용 검사, 단위 테스트, 통합 테스트, 빌드 명령을 구분합니다.
4. 변경 경계 기록: 이번 작업에서 건드리지 않을 디렉터리와 파일을 명시합니다.
5. 실행 전 증거 수집: 현재 브랜치, 최근 커밋, 작업 공간 변경 내역, 의존성 설치 상태를 저장합니다.

공식 저장소의 최신 릴리스와 기본 브랜치가 서로 다른 동작을 가질 수 있으므로, 사용 중인 버전과 확인한 소스 버전을 함께 기록해야 합니다. 공식 릴리스 목록과 공식 개발 문서를 함께 확인하면 버전 착오를 줄일 수 있습니다. (github.com)

주의: 계획 모드에서 읽기 권한이 넓게 열려 있다면 민감한 저장소를 안전하다고 볼 수 없습니다. 계획 단계에도 필요한 경로만 제공하고, 자격 증명 파일과 운영 설정은 별도 환경에 두어야 합니다.

개발팀에서는 “계획이 끝났으니 실행한다”라는 문장만으로는 부족합니다. 계획을 검토하는 사람, 파일 쓰기를 승인하는 사람, 테스트를 실행하는 사람, 실패 시 되돌리는 사람이 다를 수 있기 때문입니다.

팀 작업에서는 계획 문서에 다음 항목을 포함합니다.

• 변경 목적과 제외 범위
• 예상되는 파일 및 모듈 목록
• 외부 인터페이스에 미치는 영향
• 실행할 검증 명령과 통과 조건
• 승인자와 실행자
• 실패 시 되돌릴 커밋 또는 브랜치 기준

계획이 너무 세밀하면 승인 대기가 길어지고, 너무 거칠면 인수인계가 되지 않습니다. 좋은 전환점은 작업 단계의 개수가 아니라 다른 사람이 계획만 읽고 같은 범위로 실행할 수 있는가입니다.

계획을 승인한 뒤에도 모델이 새로운 파일이나 새로운 위험을 발견하면 계속 실행해서는 안 됩니다. 변경 범위가 늘어나거나 검증 명령이 바뀌면 계획을 중단하고 다시 승인을 받습니다.

보안 민감 프로젝트에서는 계획 모드와 실행 환경을 분리해야 합니다. 계획 단계에는 저장소 탐색에 필요한 읽기 범위만 제공하고, 실행 단계에서만 특정 경로에 임시 쓰기 권한을 부여합니다.

특히 다음 항목은 계획 모드가 켜졌다는 이유로 접근을 허용해서는 안 됩니다.

• 배포용 비밀값과 개인 키
• 운영 데이터베이스 접속 정보
• 프로덕션 설정 파일
• 자동 배포 토큰
• 다른 프로젝트의 공유 작업 공간

공식 저장소의 구성과 패키지 구조를 기준으로 권한을 나눌 때도, 실제 사용 중인 플러그인과 도구가 어떤 경로를 읽고 쓰는지 별도로 확인해야 합니다. 공식 구조가 곧 조직의 권한 정책을 대신하지는 않습니다. (github.com)

원격 맥에서 딥시크 하니스를 실행하면 계획과 작업 공간이 서로 다른 시간에 저장될 수 있습니다. 세션이 끊겼거나 맥이 재시동됐거나 다른 개발자가 작업을 이어받았다면, 이전 대화가 복원됐다는 사실만으로 실행을 계속해서는 안 됩니다.

재접속 후에는 다음 순서를 지킵니다.

1. 현재 작업 공간의 경로를 확인합니다.
2. 활성 브랜치와 마지막 커밋을 확인합니다.
3. 미커밋 변경과 충돌 상태를 확인합니다.
4. 패키지 잠금 파일과 의존성 설치 상태를 확인합니다.
5. 계획 문서의 대상 파일과 현재 파일을 대조합니다.
6. 검증 명령을 쓰기 없이 실행합니다.
7. 모든 조건이 일치할 때만 실행 권한을 다시 부여합니다.

원격 맥의 접속과 작업 공간 준비가 필요하다면 NUKCLOUD 원격 맥 안내를 먼저 확인할 수 있습니다. 장시간 작업의 비용과 환경 조건은 NUKCLOUD 요금 안내에서 별도로 확인해야 합니다.

다음 조건 분기를 팀의 기본 정책으로 사용할 수 있습니다.

• 모든 조건이 충족되면 직접 실행합니다. 한 파일 중심이고, 변경이 빠르게 되돌려지며, 검증 명령과 책임자가 이미 정해져 있을 때입니다.
• 하나라도 불명확하면 계획 모드로 돌아갑니다. 저장소가 낯설거나 호출 관계를 확인하지 못했거나, 작업 공간 권한이 과도하게 열려 있을 때입니다.
• 계획 승인 후 범위가 늘어나면 실행을 중지합니다. 새 모듈, 새 의존성, 새 권한, 새 배포 대상이 생기면 기존 승인은 더 이상 같은 작업을 승인한 것이 아닙니다.
• 원격 세션이 끊겼다면 계획을 다시 대조합니다. 세션 복구는 대화 복구일 뿐이며, 브랜치와 커밋이 같은 상태라는 증거가 아닙니다.
• 검증 산출물이 없으면 실행을 완료로 처리하지 않습니다. 변경 내역, 테스트 결과, 남은 위험, 되돌림 방법을 함께 남겨야 합니다.

현재 방식이 개인 맥에서 직접 실행하는 흐름이라면, 복잡한 작업을 계속 같은 환경에서 처리할 때 작업 공간 충돌, 세션 중단, 권한 관리 누락이 반복될 수 있습니다. 반대로 모든 작업을 원격 환경으로 옮기면 단순 수정에는 접속 준비와 대기 절차가 과해질 수 있습니다. 그래서 임시 조사나 팀 검토가 필요한 작업은 NUKCLOUD의 원격 맥에서 계획 단계와 실행 단계를 나누고, NUKCLOUD의 맥 환경 안내를 확인한 뒤 지속 실행 여부를 결정하는 방식이 더 현실적입니다.