딥시크 하네스 다중 프로젝트 배포

공식 구조에서 확인되는 분리 지점

딥시크 하네스는 기능을 플러그인으로 구성하는 구조입니다. 공식 아키텍처 문서는 모델 연결, 도구 목록, 세션 기록, 에이전트 실행 흐름까지 플러그인으로 조합되며, 프로필이 여러 구성을 쌓아 실행 환경을 만든다고 설명합니다. 공식 아키텍처 문서

이 구조는 프로젝트별 구성을 만들기에는 유리하지만, 한 대의 맥 안에서 모든 경계가 자동으로 분리된다는 뜻은 아닙니다. 실제 운영에서는 다음 요소가 자주 섞입니다.

1. 파일 시스템 경계: 잘못된 작업 공간을 선택하면 에이전트가 다른 저장소의 파일을 읽거나 수정할 수 있습니다.
2. 세션 경계: 세션 기록과 로그가 섞이면 고객 요청, 내부 메모, 테스트 결과가 같은 흐름에서 재생될 수 있습니다.
3. 구성 경계: 공용 프로필이나 플러그인을 바꾸면 해당 환경에서 실행 중인 여러 작업의 동작이 동시에 달라질 수 있습니다.
4. 인증 경계: 모델 인증 정보와 외부 도구 권한을 공유하면 잘못된 계정으로 요청을 전송할 가능성이 커집니다.
5. 복구 경계: 한 환경의 업데이트나 재시작이 다른 프로젝트의 장기 작업까지 중단시킬 수 있습니다.

공식 문서는 일반적인 단일 맥의 프로젝트 수용 상한을 제시하지 않습니다. 따라서 “한 대에서 몇 개까지 안정적”이라는 숫자를 보편적인 기준처럼 사용하면 안 됩니다.

낮은 동시성 개인 프로젝트는 공유로 시작할 수 있습니다

개인 프로젝트라면 한 대의 맥을 공유하는 편이 비용과 관리 복잡도를 줄일 수 있습니다. 특히 다음 조건을 모두 만족하면 공유 시작이 가능합니다.

• 사용하는 언어와 패키지 관리 방식이 비슷합니다.
• 여러 에이전트가 같은 시간에 파일을 수정하지 않습니다.
• 인증 정보와 외부 도구 권한이 동일한 보안 영역에 있습니다.
• 플러그인 업데이트를 자주 하지 않습니다.
• 한 프로젝트가 멈춰도 다른 프로젝트의 납기나 서비스가 중단되지 않습니다.

다만 공유의 핵심은 폴더만 나누는 것이 아닙니다. 공식 웹 화면 안내도 작업을 시작하기 전에 작업 공간을 선택해야 하며, 선택한 공간의 파일을 읽고 수정하고 명령을 실행할 수 있다고 설명합니다. 공식 웹 화면 안내

프로젝트별로 최소한 다음을 분리해야 합니다.

mkdir -p ~/dsh-workspaces/project-a
mkdir -p ~/dsh-workspaces/project-b

dsh --profile project-a --dump-config
dsh --profile project-b --dump-config

예상 출력은 다음처럼 프로필별 구성이 달라야 합니다.

profile: project-a
workspace: ~/dsh-workspaces/project-a

profile: project-b
workspace: ~/dsh-workspaces/project-b

실제 명령과 옵션은 설치한 버전에 따라 달라질 수 있으므로 실행 전 공식 문서의 현재 사용법을 확인해야 합니다. 특히 작업 공간을 잘못 선택했을 때는 에이전트 실행을 계속하지 말고, 세션을 중지한 뒤 경로와 프로필을 다시 확인하는 규칙을 팀 문서에 적어야 합니다.

여러 저장소를 동시에 개발하면 공유의 이점이 빠르게 줄어듭니다

저장소가 많다는 사실만으로 맥을 늘릴 필요는 없습니다. 판단 기준은 다음 세 가지입니다.

• 같은 시간에 몇 개의 세션이 실행되는가
• 각 세션이 얼마나 오래 프로세스와 도구를 점유하는가
• 오류 뒤 재시도가 다른 작업과 겹치는가

순서대로 실행하면 한 환경을 공유하기 쉽습니다. 반면 장시간 실행되는 에이전트와 짧은 수정 작업이 겹치면 문제가 달라집니다. 장기 작업이 세션과 터미널을 계속 점유하고, 다른 프로젝트의 명령 실행이나 승인 요청이 뒤섞일 수 있습니다.

공유 환경을 유지하려면 작업을 정해진 순서로 실행하고, 세션 이름과 작업 공간을 명시해야 합니다.

[고객-알파] 작업 공간 확인
[내부-웹] 작업 공간 확인
[고객-알파] 테스트 실행
[내부-웹] 문서 수정

다음 상황에서는 저장소 수와 관계없이 분리를 검토해야 합니다.

• 두 프로젝트가 동시에 파일 수정과 명령 실행을 수행합니다.
• 실패한 작업의 재시도가 다른 작업의 승인 요청과 겹칩니다.
• 한 프로젝트의 장기 에이전트가 계속 실행되어 종료 시점을 예측하기 어렵습니다.
• 한 환경의 재시작이 고객 작업의 납기를 직접 막습니다.

클라우드 맥을 선택할 때도 같은 원칙이 적용됩니다. 맥을 단순히 저장소별로 추가하기보다, 동시에 실행될 작업과 독립적인 권한 영역을 먼저 계산해야 합니다. NodeMini의 클라우드 맥 주문 안내는 환경을 준비할 때 고려할 접속과 운영 조건을 확인하는 출발점으로 사용할 수 있습니다.

고객 프로젝트는 폴더 이름만으로 보호되지 않습니다

고객 저장소와 내부 저장소를 같은 환경에 두는 경우 가장 큰 위험은 파일 경로가 아니라 권한의 혼합입니다. 폴더 이름을 명확히 붙여도 에이전트가 올바른 작업 공간을 선택한다는 보장은 없습니다.

맥의 파일 권한은 사용자 또는 그룹이 파일을 읽고 변경할 수 있는 범위를 정하는 기능입니다. 따라서 공유 환경에서는 작업 공간 폴더의 소유자와 접근 권한도 함께 확인해야 합니다. 맥 파일과 폴더 권한 안내

특히 다음 조합은 별도 배포에 가깝게 판단해야 합니다.

• 고객별 인증 정보가 다릅니다.
• 외부 도구의 접근 범위가 고객마다 다릅니다.
• 로그에 저장되는 정보의 보안 등급이 다릅니다.
• 고객 계약상 접근 기록과 담당자가 구분되어야 합니다.
• 한 고객의 플러그인 또는 설정 변경이 다른 고객에게 영향을 줄 수 있습니다.

독립 환경은 잘못된 작업 공간 선택, 로그 혼합, 인증 정보 오용의 영향 범위를 줄이는 데 도움이 됩니다. 그러나 클라우드 맥이나 물리적으로 다른 맥을 사용한다고 해서 자동으로 규정 준수가 완성되는 것은 아닙니다. 계정 관리, 로그 보관, 접근 승인, 삭제 절차까지 별도로 정의해야 합니다.

모델 인증 정보와 외부 서비스 비밀값은 프로젝트별 환경 변수에 무분별하게 복사하기보다 맥의 키체인과 같은 접근 통제 수단을 검토해야 합니다. 애플 개발자 문서는 키체인이 작은 비밀 데이터를 암호화된 데이터베이스에 저장하고, 어떤 앱이 항목에 접근할지 제어할 수 있다고 설명합니다. 키체인 서비스 공식 문서

플러그인 실험 환경과 안정 작업을 분리합니다

딥시크 하네스 공식 저장소는 현재 개발자 미리 보기 단계이며 호환성을 깨는 변경이 있을 수 있다고 안내합니다. 공식 개발자 미리 보기 안내

플러그인을 설치하거나 업데이트하는 환경에서는 다음 변화가 발생할 수 있습니다.

• 시작 시 불러오는 구성 순서가 달라집니다.
• 도구 목록과 승인 정책이 바뀔 수 있습니다.
• 세션 기록 방식이나 출력 형식이 달라질 수 있습니다.
• 특정 플러그인의 오류가 전체 시작 흐름에 영향을 줄 수 있습니다.

따라서 최소한 하나의 안정 프로필은 실험 대상에서 제외해야 합니다. 실험 프로필에서 먼저 플러그인을 검증하고, 재현 절차와 되돌리기 방법을 기록한 뒤 안정 프로필에 반영하는 순서가 적절합니다.

장기 에이전트는 임시 작업과 다른 운영 책임을 가집니다

짧은 코드 수정이나 문서 생성은 공유 환경의 빈 시간에 실행하기 쉽습니다. 반면 장기 에이전트는 세션, 프로세스, 로그, 재시작 책임을 계속 점유합니다.

맥에서 백그라운드 작업을 장기 실행할 때는 단순히 터미널을 열어 두는 방식보다 시작, 중지, 재시작 조건을 명확히 해야 합니다. 애플의 실행 서비스 문서는 launchd가 백그라운드 서비스를 시작하고 필요할 때 다시 실행하는 구조를 설명합니다. 애플의 백그라운드 서비스 수명 주기 안내

다음 조건에 해당하면 장기 에이전트를 독립 환경으로 옮기는 편이 안전합니다.

• 에이전트가 일정하지 않은 시간 동안 계속 실행됩니다.
• 재시작 시 다른 프로젝트의 세션도 함께 끊깁니다.
• 오류 로그를 확인할 담당자가 별도로 필요합니다.
• 한 프로젝트의 장애가 다른 프로젝트의 배포나 고객 대응을 막습니다.

중간 판단을 위한 공유·분리 비교

팀 공유는 계정과 인수인계를 먼저 정해야 합니다

팀이 한 대의 맥을 함께 사용한다면 다음 네 가지를 문서로 고정해야 합니다.

1. 누가 로그인할 수 있는지 정합니다.
2. 누가 프로필과 플러그인을 바꿀 수 있는지 정합니다.
3. 누가 업데이트와 재시작을 담당하는지 정합니다.
4. 누가 세션 로그와 오류 기록을 볼 수 있는지 정합니다.

이 중 하나라도 답하기 어렵다면 공유 계정을 늘리는 방식으로 해결하지 않는 편이 좋습니다. 팀 단위 또는 권한 영역 단위로 환경을 나누고, 각 환경에 담당자를 지정해야 합니다.

이번 주에 실행할 5단계 점검 절차

첫 단계: 프로젝트를 네 가지 축으로 분류합니다

각 프로젝트에 대해 동시 실행 여부, 데이터 등급, 플러그인 변경 빈도, 장애 시 영향 범위를 기록합니다. 프로젝트 이름이나 저장소 개수만 기록하면 실제 분리 필요성을 놓치기 쉽습니다.

둘째 단계: 공유 후보를 두 개로 제한합니다

처음부터 모든 프로젝트를 한 환경에 넣지 않습니다. 의존성이 비슷하고 데이터 권한이 같은 프로젝트 두 개만 선택해 순서 실행부터 확인합니다.

셋째 단계: 작업 공간과 프로필을 검증합니다

pwd
git rev-parse --show-toplevel
dsh --profile project-a --dump-config

출력된 최상위 경로와 프로필 이름이 작업 대상과 일치하지 않으면 명령 실행을 중지합니다. 경로 확인을 생략한 상태에서 에이전트에게 수정 권한을 주지 않는 것이 안전합니다.

넷째 단계: 인증 정보와 플러그인 변경을 따로 시험합니다

공유 인증 정보를 그대로 사용하지 말고, 프로젝트별 또는 권한 영역별 이름을 붙입니다. 플러그인 업데이트는 안정 프로필이 아닌 실험 프로필에서 먼저 수행합니다.

다섯째 단계: 장애 전파를 확인합니다

한 프로젝트의 에이전트를 중지하거나 환경을 재시작한 뒤 다른 프로젝트의 세션, 로그, 작업 공간 선택이 영향을 받지 않는지 확인합니다. 다른 작업이 중단되거나 담당자가 복구 방법을 모르면 독립 배포 조건으로 기록합니다.

FAQ

한 대의 맥에서 여러 딥시크 하네스 프로젝트를 동시에 실행해도 되나요?

가능합니다. 다만 저장소 수가 아니라 동시에 점유하는 세션과 도구 실행 수를 먼저 봐야 합니다. 의존성이 비슷하고 데이터 권한이 같다면 프로젝트별 작업 공간, 세션, 프로필을 나누어 공유할 수 있습니다. 고객 코드나 장기 실행 작업이 포함되면 별도 환경이 더 안전합니다.

서로 다른 프로젝트가 플러그인과 모델 인증 정보를 함께 쓰면 어떤 문제가 생기나요?

공유 플러그인은 업데이트 뒤 설정 조합이나 시작 순서를 바꿀 수 있습니다. 인증 정보도 잘못된 프로필을 선택하면 다른 프로젝트의 모델 계정이나 도구 권한으로 요청할 수 있습니다. 따라서 공통 플러그인은 안정 환경에 고정하고, 인증 정보는 프로젝트 또는 권한 영역별로 분리해야 합니다.

고객 코드 저장소는 에이전트 환경을 따로 배포해야 하나요?

고객별 보안 등급, 저장소 접근 권한, 로그 보관 규칙이 다르면 따로 배포하는 편이 합리적입니다. 별도 환경이 곧바로 규정 준수를 보장하는 것은 아니지만, 잘못된 작업 공간 선택과 로그 혼합이 다른 프로젝트로 번지는 범위를 줄일 수 있습니다.

다중 프로젝트 환경은 저장소별로 나눠야 하나요, 권한 영역별로 나눠야 하나요?

기본 기준은 저장소 수가 아니라 권한 영역입니다. 같은 담당자가 비슷한 인증 정보와 플러그인을 사용하고 작업이 겹치지 않으면 여러 저장소를 한 환경에서 관리할 수 있습니다. 반대로 고객, 내부 운영, 보안 등급이 다르면 저장소 수가 적어도 권한 영역별 분리가 우선입니다.

NodeMini 클라우드 맥을 검토할 때의 기준

현재 방식이 개인 맥 한 대 공유라면 초기 비용과 관리 대상은 줄지만, 작업 공간을 잘못 선택했을 때 영향 범위가 넓고, 플러그인 변경과 재시작 책임이 여러 프로젝트에 동시에 걸리며, 팀원이 늘어날수록 계정과 로그 관리가 복잡해집니다. 반대로 프로젝트마다 무조건 맥을 추가하면 사용하지 않는 시간까지 비용으로 남고, 저장소 수를 기준으로 과도하게 배포할 수 있습니다.

따라서 임시 테스트, 고객별 권한 영역, 장기 에이전트처럼 독립성이 필요한 작업만 NodeMini의 클라우드 맥으로 분리하고, 낮은 위험의 개인 프로젝트는 명확한 작업 공간과 프로필을 갖춘 공유 환경에 남기는 이중 구성이 현실적입니다. 서울 지역 접속이 필요한 경우에는 서울 맥 미니 주문 안내를, 미국 서부권 지연 시간을 비교해야 하는 경우에는 실리콘밸리 맥 미니 주문 안내를 함께 확인하면 됩니다.

이번 주에는 프로젝트마다 데이터 경계, 동시 실행 여부, 플러그인 변경 여부, 장애 책임자를 표시해 보시기 바랍니다. 그 결과에서 격리 조건에 해당하는 프로젝트만 별도 클라우드 맥 조합으로 상담하면, 저장소 개수만 보고 불필요하게 여러 환경을 임대하는 일을 피할 수 있습니다.

마지막 업데이트: 2026년 8월 18일. 데이터와 구조는 딥시크 하네스 공식 저장소, 공식 아키텍처 문서, 공식 웹 화면 안내, 애플의 맥 권한·키체인·백그라운드 서비스 문서를 기준으로 확인했습니다.