2026년 딥시크 하네스 시트벨트 샌드박스 의미

공식 실행 예시는 웹 화면을 127.0.0.1:3080에서 시작합니다. 딥시크 하네스는 아직 개발자 미리보기이며 호환성이 바뀔 수 있습니다. 따라서 딥시크 하네스 시트벨트 샌드박스는 격리의 출발점이지 안전성의 완성본이 아닙니다. 먼저 위험이 낮은 저장소에서 실제 허용·거부 동작을 확인해야 합니다. 그 뒤 권한 확대나 독립된 원격 맥 이전을 결정하는 편이 안전합니다. 공식 저장소의 실행 방식과 현재 상태에서 확인할 수 있습니다.

이 글은 다음 독자를 위한 내용입니다.

• 맥에서 딥시크 하네스에 명령 실행을 맡기려는 개발자
• 에이전트의 운영체제 격리 경계를 평가하는 보안 엔지니어
• 원격 맥 시험 범위와 구매 계획을 정하는 기술 책임자

마지막 업데이트: 2026년 8월 18일. 공식 저장소와 애플 보안 문서를 기준으로 확인했습니다. 실제 기본 활성화 여부와 제한 범위는 설치한 버전과 설정에서 다시 검증해야 합니다.

시트벨트는 작업 공간 선택과 다른 통제 계층입니다

딥시크 하네스의 작업 공간 설정은 에이전트가 어느 저장소를 대상으로 작업할지 정하는 애플리케이션 계층입니다. 반면 시트벨트는 실행된 프로세스가 파일, 네트워크, 시스템 자원에 접근할 수 있는 범위를 운영체제 수준에서 제한하는 계층입니다.

두 설정을 같은 것으로 보면 안 됩니다.

애플은 샌드박스를 파일, 네트워크, 하드웨어 접근을 제한하는 운영체제 기능으로 설명합니다. 그러나 샌드박스는 취약한 코드 자체를 없애지 않습니다. 허용된 권한 안에서 실행되는 행위까지 자동으로 업무 위험으로 판별하지도 않습니다. 애플의 맥 샌드박스 설명을 함께 확인해야 합니다.

현재 공식 공개 자료에서 샌드박스는 프로세스 제한 능력과 여러 백엔드를 위한 구조로 다뤄집니다. 다만 저장소의 디렉터리 이름이나 설계 문서에 시트벨트가 언급된다는 이유만으로 특정 배포판, 설정, 실행 모드에서 기본 활성화된다고 단정할 수는 없습니다. 설치한 버전의 설정 파일과 실제 프로세스를 기준으로 판단해야 합니다.

주의: “시트벨트가 있다”와 “현재 실행 중인 명령에 시트벨트 정책이 적용됐다”는 서로 다른 주장입니다.

딥시크 하네스는 macOS에서 시트벨트를 자동으로 켭니까?

현재 답은 설치 버전과 실행 모드를 직접 확인하기 전에는 그렇다고 말할 수 없다입니다.

첫 시험에서는 다음 네 가지 증거를 남겨야 합니다.

1. 딥시크 하네스 버전과 설치 경로
2. 선택된 샌드박스 모드와 작업 공간 경로
3. 허용되어야 하는 파일 접근 결과
4. 거부되어야 하는 파일 접근 결과와 오류 기록

애플 문서도 샌드박스 적용 여부를 실행 중인 프로세스와 시스템 진단 정보로 확인하도록 안내합니다. 설정 화면에 샌드박스라는 단어가 보이는 것만으로는 충분하지 않습니다. 애플의 샌드박스 위반 진단 문서도 같은 원칙을 제시합니다.

검증 저장소에는 민감하지 않은 더미 파일을 둡니다.

검증 저장소/
├── 허용읽기.txt
├── 허용쓰기.txt
├── 거부대상/
│   └── 외부파일.txt
└── 기록/
    └── 결과.txt

그 뒤 에이전트에게 저장소 안의 파일 읽기와 기록/결과.txt 쓰기를 요청합니다. 이어서 홈 디렉터리의 비밀키 경로, 다른 프로젝트 경로, 시스템 설정 경로를 읽도록 요청합니다. 허용과 거부 결과를 모두 저장해야 합니다.

Seatbelt 샌드박스가 다른 디렉터리 접근을 막을 수 있습니까?

가능성은 있지만, 항상 같은 범위로 막는다고 볼 수는 없습니다.

애플의 샌드박스는 앱이 요청한 권한과 파일 접근 방식에 따라 허용 범위를 정합니다. 사용자 선택 파일, 보안 범위 북마크, 앱 컨테이너처럼 예외가 생기는 경로도 있습니다. 파일 권한, 접근 제어 목록, 시스템 무결성 보호가 별도로 영향을 줄 수도 있습니다. 파일 접근 경계에 대한 애플 문서를 기준으로 보면, “다른 폴더는 무조건 차단”이라는 표현은 지나치게 단순합니다.

특히 에이전트는 직접 파일을 읽는 것만 하지 않습니다. git, 패키지 관리자, 빌드 도구, 셸 스크립트, 플러그인, MCP 서버를 통해 간접적으로 경로를 확장할 수 있습니다.

따라서 확인 항목은 다음과 같습니다.

• 작업 공간 밖의 일반 파일 읽기
• 작업 공간 밖의 파일 쓰기
• 심볼릭 링크를 통한 우회
• 자식 프로세스가 만든 임시 파일
• 빌드 캐시와 패키지 저장소 접근
• 로그에 외부 경로와 파일 내용이 남는지 여부

명령 실행에서는 프로세스 격리만으로 충분하지 않습니다

빌드 명령 하나가 하나의 프로세스로 끝난다고 가정하면 안 됩니다. 셸은 다시 스크립트를 실행할 수 있습니다. 스크립트는 패키지 관리자나 컴파일러를 호출할 수 있습니다. 컴파일러는 보조 도구와 캐시를 사용할 수 있습니다.

결국 위험 범위는 최초 명령보다 커질 수 있습니다.

시트벨트는 실제로 작성된 정책을 적용할 뿐입니다. 명령의 업무상 위험을 이해하고 “이 명령은 실행해도 되는가”를 판단하지는 않습니다. 그러므로 승인 정책은 유지해야 합니다.

샌드박스 뒤에도 명령 승인이 필요합니까?

필요합니다.

샌드박스는 권한의 상한선을 낮추는 장치입니다. 명령 승인은 해당 작업을 지금 실행할지 결정하는 운영 통제입니다. 둘은 대체 관계가 아닙니다.

다음 명령은 낮은 위험으로 분류할 수 있습니다.

• 저장소 상태 조회
• 특정 파일의 읽기
• 격리된 테스트 실행
• 임시 결과 파일 생성

다음 명령은 승인 없이는 실행하지 않는 편이 좋습니다.

• 권한 상승을 시도하는 명령
• 대량 삭제와 이동
• 외부 스크립트 내려받기
• 비밀 저장소와 인증 도우미 호출
• 네트워크를 통한 배포와 원격 변경

네트워크와 외부 도구는 별도 경계로 평가해야 합니다

시트벨트가 적용됐다고 해서 모든 외부 연결이 자동으로 차단된다고 말할 수 없습니다. macOS의 네트워크 권한은 연결을 시작하는 방식과 앱의 권한 설정에 따라 달라집니다. 애플은 샌드박스 앱의 네트워크 접근 권한을 별도 항목으로 다룹니다. 애플의 앱 샌드박스 공식 설명을 확인해야 합니다.

또한 로컬 프로세스 제한과 애플리케이션 수준의 네트워크 정책은 다른 문제입니다.

• 시트벨트: 프로세스가 어떤 시스템 자원에 접근할 수 있는지 제한
• 네트워크 정책: 어느 주소와 포트로 연결할지 결정
• MCP 또는 플러그인: 어떤 데이터를 만들고 보내는지 결정
• 명령 승인: 실제 실행을 허용할지 결정

첫 테스트에서는 민감하지 않은 주소를 사용합니다. 허용 대상과 거부 대상을 나누고, 도메인 조회, 일반 요청, 리디렉션, 자식 프로세스의 연결을 각각 기록합니다. 실제 저장소 주소나 사내 주소를 바로 넣지 않는 편이 좋습니다.

경험상 네트워크 테스트는 “연결된다”보다 “어떤 프로세스가 어떤 주소로 연결했는가”를 남기는 것이 더 중요합니다.

비밀키는 샌드박스 밖에서 다시 설계해야 합니다

샌드박스는 환경 변수, 설정 파일, 셸 기록, 빌드 로그에 비밀키가 노출되는 문제를 자동으로 해결하지 않습니다.

위험 지점은 세 가지입니다.

1. 에이전트가 환경 변수를 읽는 경우
2. 설정 파일과 셸 기록에 키가 남는 경우
3. 오류 로그와 모델 입력에 키 일부가 포함되는 경우

시험용 키는 실제 서비스 권한이 없는 별도 키로 준비합니다. 권한 범위도 최소화합니다. 로그에는 키를 출력하지 않습니다. 테스트가 끝나면 즉시 폐기하거나 교체합니다.

비밀키가 macOS 키체인에 있다고 해서 자동으로 안전한 것은 아닙니다. 키체인 접근 자체가 추가 권한과 별도 검증 대상이 됩니다. 애플은 샌드박스 환경에서 제한된 리소스 접근이 권한과 사용자 승인에 좌우될 수 있다고 설명합니다. 애플의 사용자 데이터 보호 문서를 참고할 수 있습니다.

원격 맥에서는 책임 경계를 나누어야 합니다

독립된 클라우드 맥은 개인 맥의 문서, 개발 키, 브라우저 세션과 작업을 분리하는 데 도움이 됩니다. 하지만 원격 환경을 임대했다고 보안 설정이 끝나는 것은 아닙니다.

다음 경계를 각각 확인해야 합니다.

• 원격 접속 계정과 다중 인증
• 운영체제 사용자 권한
• 딥시크 하네스 작업 공간
• 시트벨트와 프로세스 정책
• MCP 서버와 플러그인 목록
• 로그와 결과물 저장 위치
• 중지, 초기화, 회수 절차

프로젝트 민감도에 따른 선택은 다음과 같이 나눌 수 있습니다.

• 공개 저장소와 더미 데이터: 공유 환경에서 짧게 시험
• 내부 코드와 제한된 키: 독립 사용자와 제한된 네트워크 사용
• 고객 자료와 장기 실행: 별도 환경을 만들기 전까지 보류

원격 맥의 접근 방식과 운영 조건을 비교하려면 SFTPMAC의 맥 환경 안내를 먼저 확인하는 편이 좋습니다. 서울 지역의 독립 환경을 검토하는 경우에는 지역, 계정, 초기화, 원격 접속 정책을 별도로 확인해야 합니다. 운영 자료를 검토할 때도 SFTPMAC의 운영 안내를 기준으로 접근 권한과 회수 절차를 함께 기록하면 시험 결과를 비교하기 쉽습니다.

첫 공개 후에는 이 순서로 검증합니다

1. 공식 상태 확인
   공식 저장소의 현재 브랜치, 샌드박스 문서, 설정 예시를 확인합니다. 개발자 미리보기와 호환성 변경 가능성도 기록합니다.

2. 검증 환경 분리
   민감한 저장소를 복제하지 않습니다. 더미 파일과 폐기 가능한 시험용 키만 사용합니다.

3. 파일 경계 확인
   작업 공간 안의 읽기·쓰기를 시험합니다. 다른 프로젝트, 홈 디렉터리, 키 저장 경로는 거부되는지 확인합니다.

4. 프로세스 경계 확인
   셸, 빌드 도구, 패키지 관리자, 자식 프로세스를 차례로 실행합니다. 생성된 프로세스와 파일을 기록합니다.

5. 네트워크 경계 확인
   허용 주소와 거부 주소를 나누어 연결 결과를 저장합니다. MCP와 플러그인 연결은 별도 시험으로 분리합니다.

6. 비밀키 경계 확인
   환경 변수, 설정 파일, 셸 기록, 로그에서 키가 보이지 않는지 확인합니다. 시험이 끝나면 키를 폐기합니다.

7. 실패 대응 준비
   위험한 도구를 끄는 방법, 세션을 중지하는 방법, 환경을 초기화하는 방법을 문서화합니다. 한 번의 실패를 “일시 오류”로 넘기지 않습니다.

완전한 운영 점검이 필요하다면 파일, 프로세스, 네트워크, 비밀키를 하나의 통제로 묶지 말고 각각 승인하는 방식으로 문서화해야 합니다.

개인 맥과 독립된 맥 환경의 선택 기준

개인 맥에서 바로 실행하는 방식은 시작이 빠릅니다. 대신 개인 문서, 브라우저 인증, 개발 키, 다른 프로젝트와 섞일 가능성이 큽니다. 자체 서버나 일반 클라우드 환경은 접근 통제와 초기화 절차를 직접 설계해야 합니다.

독립된 맥 환경은 비용과 관리 절차가 생기지만, 작업 범위를 분리하고 실패 후 회수하기가 쉽습니다.

딥시크 하네스 시트벨트 샌드박스는 개인 맥을 곧바로 안전한 실행실로 바꾸지 않습니다. 현재 환경의 약점은 개인 파일 혼용, 원격 접근 관리 부담, 장기 실행 중 승인 누락입니다. 특히 장시간 실행과 외부 도구 사용이 겹치면 작업 공간과 자격 증명을 분리한 독립 맥이 더 현실적인 선택이 될 수 있습니다.

현재 방식의 단점은 분명합니다. 개인 맥은 자료와 키가 섞이기 쉽습니다. 자체 운영 환경은 초기화와 원격 접근을 직접 관리해야 합니다. 일반 클라우드 환경은 맥 전용 도구와 권한 흐름을 별도로 맞춰야 합니다. 반면 SFTPMAC의 독립 맥 환경은 임시 검증과 분리 운영을 시작하기 쉬운 선택지가 될 수 있습니다. 다만 장기 고정 부하, 물리 장치 연결, 전용 하드웨어가 필수라면 직접 구매나 자체 운영이 더 적합합니다. 임대 여부를 검토하더라도, 파일·프로세스·네트워크·비밀키 경계를 먼저 검수해야 합니다.