고객 프로젝트에서 Privacy Mode를 켰는데도 생산 키와 데이터베이스 구조가 클라우드 에이전트로 넘어갔습니다.
가장 빠른 해법은 프로젝트를 공개·일반 비공개·고민감으로 나눈 뒤, 고민감 프로젝트에서는 클라우드 에이전트를 차단하고 승인된 격리형 로컬 또는 원격 맥으로 전환하는 것입니다.
이 글은 개인 개발자, 외주 팀 책임자, 기술 책임자를 위한 점검 문서입니다. 보안 심사 담당자는 개발자의 구두 설명 대신 설정 화면, 모델 정보, 계정 유형, 확인 날짜를 증거로 수집할 수 있습니다.
마지막 업데이트: 2026년 8월 22일. Cursor 공식 데이터 사용 문서, 보안 문서, Cloud Agents 문서와 SpaceXAI의 Grok 4.6 발표를 기준으로 확인했습니다. 고객 계약에 대한 판단은 법률 자문이 아니라 내부 검토 기준입니다.
커서 스페이스엑스 합류 후 고객 코드 개인정보 판단 기준
Cursor는 2026년 8월 14일 SpaceX에 합류한다고 공식 발표했습니다. 같은 시기 Grok 4.6이 Cursor에 들어왔다는 내용도 공식 발표에 포함되어 있습니다. 다만 이 사실만으로 고객 코드의 처리 가능 여부를 결정할 수는 없습니다. Cursor의 합류 발표와 Grok 4.6 공식 발표는 기업 변화와 모델 제공 사실을 보여줄 뿐, 모든 고객 프로젝트에 대한 자동 승인을 의미하지 않습니다.
검토할 대상은 편집기 전체가 아닙니다. 다음 네 가지를 따로 확인해야 합니다.
- 학습에 사용되지 않는가
- 요청이 저장되지 않는가
- 요청이 Cursor 백엔드를 거치는가
- 에이전트가 저장소와 실행 환경의 복사본을 보관하는가
Cursor 공식 설명은 Privacy Mode를 켠 경우 고객 데이터가 학습에 사용되지 않는다고 안내합니다. 그러나 모델별 예외, 위험 분류기 처리, 요청 라우팅, Cloud Agents의 저장과 삭제 흐름은 별도 항목입니다. Cursor 데이터 사용 안내와 공식 보안 설명을 현재 설정 화면과 함께 대조해야 합니다.
커뮤니티 글에서 표준 Privacy Mode 세션이 Grok 학습으로 이어질 수 있다는 주장이 보이더라도 이는 제3자 주장입니다. 공식 설정과 당시 약관이 우선입니다. 확인되지 않은 특정 날짜의 데이터 파이프라인 개통설을 승인 근거로 사용해서도 안 됩니다.
프로젝트 위험도별 승인 범위
| 프로젝트 유형 | 사용 가능한 범위 | 금지하거나 보류할 항목 | 반드시 남길 증거 | 승인 결론 |
|---|---|---|---|---|
| 공개 저장소·공개 문서 | 공개 코드 설명, 테스트 작성, 일반적인 리팩터링 | 대화에 포함된 미공개 고객 자료 | Privacy Mode 화면, 클라이언트 버전, 모델명, 확인 날짜 | 조건부 계속 |
| 일반 고객 비공개 저장소 | 탈민감화한 코드 조각, 최소 범위의 검색과 수정 | 계약상 금지된 외부 처리, 원본 고객 자료의 광범위한 색인 | 고객 계약 검토, 데이터 경로, 계정과 모델 정보 | 제한 사용 |
| 상업 비밀·핵심 알고리즘 | 고객이 승인한 격리 환경의 로컬 추론 | 일반 클라우드 요청, 전체 저장소 색인 | 격리 환경 승인, 접근 제어, 삭제와 접속 기록 | 격리 전환 |
| 생산 키·개인정보·규제 데이터 | 실제 자료를 넣지 않은 별도 개발 환경 | 프롬프트, 인덱스, 환경 스냅샷에 실제 값 입력 | 비밀값 분리와 환경 접근 기록 | 기본 차단 |
| Cursor Cloud Agents | 고객이 명시적으로 승인한 저장소와 실행 환경 | 정책상 클라우드 보관이 금지된 모든 코드 | 저장소 연결, 환경, 네트워크, Secrets, 삭제 절차 | 별도 재승인 |
공개 저장소라고 해서 무조건 안전한 것은 아닙니다. 대화 중 아직 발표하지 않은 기능, 고객 이름, 내부 주소가 섞이면 공개 코드의 낮은 위험성이 사라집니다. 반대로 비공개 저장소라도 최소 코드 조각과 탈민감화된 맥락만 사용하면 제한적인 검토가 가능할 수 있습니다.
공개 프로젝트와 일반 비공개 프로젝트
공개 코드와 데모 프로젝트는 상대적으로 낮은 위험으로 계속 사용할 수 있습니다. 단, 다음 조건을 모두 만족해야 합니다.
- 현재 Privacy Mode 상태를 화면으로 확인합니다.
- 선택한 모델의 저장 표시와 예외 안내를 확인합니다.
- 대화 기록에 고객명, 내부 주소, 미공개 설계가 없는지 검토합니다.
- 승인 대상이 저장소 전체가 아니라 허용된 기능 조합임을 기록합니다.
여기서 모델 이름은 반드시 기록해야 합니다. Grok 4.6을 선택했다는 사실 자체가 학습이나 저장 조건을 자동으로 설명해 주지는 않습니다. 모델의 제공 경로와 데이터 처리 조건은 Grok 4.6 개발자 문서와 Cursor의 당시 안내를 함께 확인해야 합니다.
일반 고객 비공개 저장소는 계약 검토가 먼저입니다. 고객 계약에 제3자 처리, 국외 전송, 외부 모델 제공자 전송 금지 조항이 있으면 Privacy Mode만으로 허용 범위를 만들 수 없습니다. 고객이 명확히 승인하지 않았다면 공개 가능한 최소 코드 조각, 탈민감화한 변수명, 격리된 브랜치만 사용합니다.
계속 사용 조건
- 고객 계약이 외부 개발 도구 처리를 허용합니다.
- 실제 비밀값과 개인 데이터가 입력 범위에서 제외됩니다.
- Privacy Mode와 모델 표시를 확인할 수 있습니다.
- Cloud Agents를 사용하지 않거나 별도 승인을 받았습니다.
- 검토 날짜와 담당자를 기록할 수 있습니다.
제한 사용의 단점
- 코드 맥락이 잘려 답변 품질이 떨어질 수 있습니다.
- 탈민감화 누락으로 고객 정보가 다시 섞일 수 있습니다.
- API key를 직접 입력해도 요청이 Cursor 경로를 거치지 않는다고 증명할 수 없습니다.
- 팀원이 다른 모델이나 기능으로 바꾸면 기존 승인이 무효가 될 수 있습니다.
API key mode는 인증 방식의 선택입니다. 개인정보 보호를 위한 직접 연결 증명서가 아닙니다. 따라서 API key를 넣었다는 이유만으로 Cursor의 백엔드, 로그, 모델 제공자의 처리 범위를 모두 우회했다고 기록하면 안 됩니다. Cursor API key 안내에서 제공되는 현재 문서와 제품 화면을 기준으로 실제 경로를 재확인해야 합니다.
커서 프라이버시 모드와 고위험 자료의 분리
다음 자료는 기본적으로 클라우드 AI 작업 흐름에 넣지 않는 편이 안전합니다.
- 고객의 핵심 알고리즘과 영업 비밀
- 공개되지 않은 취약점과 보안 대응 자료
- 생산 환경의 비밀번호, 토큰, 인증서
- 개인 식별 정보와 규제 대상 데이터
- 고객이 외부 모델 제공자 전송을 금지한 저장소
.cursorignore나 저장소 제외 설정은 실수로 파일을 보내는 가능성을 낮추는 보조 수단입니다. 접근 제어와 격리 환경을 대신하지는 못합니다. 실제 키를 프롬프트에 넣지 않는 것만으로도 부족합니다. 인덱스 범위, 터미널 환경, 환경 변수 스냅샷, 에이전트가 생성한 패치까지 함께 확인해야 합니다.
주의: Cursor Privacy Mode가 학습 방지 약속을 제공하더라도 학습, 저장, 백엔드 라우팅, 에이전트 환경 보관은 서로 다른 통제 항목입니다. 하나를 확인했다고 나머지가 승인되는 것은 아닙니다.
Cursor Cloud Agents 재승인 항목
Cursor Cloud Agents는 일반적인 전면 편집기 요청과 같은 방식으로 승인하면 안 됩니다. 공식 문서에 따르면 에이전트는 저장소를 복제하고 격리된 가상 머신에서 작업합니다. 따라서 코드뿐 아니라 실행 환경과 네트워크 흐름까지 심사 대상이 됩니다. Cloud Agents 공식 문서와 보안·네트워크 문서를 함께 확인하십시오.
재승인 기록에는 다음 내용을 포함합니다.
- 어떤 저장소 연결을 허용했는가
- 복제된 작업 공간의 수명과 삭제 방식을 확인했는가
- 환경 변수와 Secrets를 어떤 방식으로 주입했는가
- 외부 네트워크 출구를 허용했는가
- 대화 기록과 실행 로그에 고객 코드가 남는가
- 에이전트가 만든 변경을 누가 검토하고 반영하는가
고객 정책이 클라우드 코드 저장을 금지한다면 Privacy Mode를 켜도 Cloud Agents는 승인하지 않아야 합니다. 에이전트가 격리 가상 머신에서 실행된다는 설명은 고객 환경과 완전히 분리된다는 뜻이 아닙니다. 저장소 복제, 환경 구성, 네트워크, 삭제 절차를 확인하지 못하면 데이터 경로를 입증할 수 없습니다.
승인 기록을 만드는 여섯 단계
- 프로젝트 자료를 분류합니다. 공개 코드, 일반 비공개 코드, 영업 비밀, 생산 키, 개인 정보로 나눕니다.
- 계약을 확인합니다. 제3자 처리, 국외 전송, 외부 모델, 클라우드 저장 금지 조항을 표시합니다.
- 기능 범위를 정합니다. 채팅, 코드 완성, 저장소 검색, 터미널 실행, Cloud Agents를 한 묶음으로 승인하지 않습니다.
- 현재 설정을 캡처합니다. Privacy Mode, 계정 유형, 모델 이름, API key 사용 여부, Cloud Agents 상태를 기록합니다.
- 작은 검증 요청을 실행합니다. 실제 고객 자료 대신 공개 테스트 파일을 사용하고 요청·응답·실행 환경의 경로를 확인합니다.
- 결론과 만료 조건을 남깁니다. 계속 사용, 제한 사용, 격리 전환 중 하나를 선택하고 모델·약관·설정이 바뀌면 재검토합니다.
개발자가 “학습에 쓰이지 않는다”고 말하는 것만으로는 승인 증거가 되지 않습니다. 스크린샷만으로도 충분하지 않습니다. 계정, 모델, 기능, 고객 계약, 검토 날짜가 함께 있어야 재현 가능한 판단이 됩니다. 팀에서 반복 사용할 MacHTML 콘솔과 내부 승인 양식에 이 항목을 묶어 두면 프로젝트가 바뀔 때 누락을 줄일 수 있습니다.
조건별 최종 결정
다음 조건 분기로 결론을 고정하십시오.
- 공개 코드이고 미공개 자료가 없으며 설정과 모델을 확인했다면 제한된 기능으로 계속 사용합니다.
- 일반 비공개 코드이고 계약이 외부 처리를 허용하지만 데이터 경로가 완전히 확인되지 않았다면 최소 코드와 탈민감화된 맥락만 사용합니다.
- 고객 계약에 외부 모델 또는 클라우드 저장 금지 조항이 있다면 Cloud Agents를 끄고 격리 환경으로 되돌립니다.
- 생산 키, 규제 데이터, 핵심 알고리즘이 포함된다면 Cursor의 일반 클라우드 흐름에 넣지 않습니다.
- 로컬 모델이 필요하지만 고객 장비에서 실행할 수 없다면 Cursor가 임의의 로컬 모델 교체를 공식 지원한다고 가정하지 말고, 고객이 승인한 독립형 원격 맥 환경에서 모델과 저장소를 분리해 운영합니다.
- 데이터 경로 또는 고객 승인을 증명하지 못한다면 개발 속도를 예외 사유로 삼지 말고 격리 환경을 검토합니다.
기존 환경과 격리형 원격 맥의 선택
현재 노트북이나 일반 클라우드 환경을 계속 쓰면 초기 설정은 간단합니다. 그러나 팀원이 같은 계정으로 다른 모델을 선택할 수 있고, 에이전트의 저장소 복제와 네트워크 출구를 통제하기 어렵습니다. 생산 키가 환경 변수나 셸 기록에 남는 문제도 있습니다. 고객별 장비와 정책을 분리하기도 어렵습니다.
반면 승인된 독립 원격 맥은 프로젝트별 접근 계정, 연결 방식, 비밀값 보관 위치, 작업 종료 후 회수 절차를 문서화하기 쉽습니다. 단, 장기간 안정적인 고부하 작업이나 물리 장비 연결이 필요한 경우에는 직접 구매나 고객 전용 장비가 더 적합할 수 있습니다. 임시 개발, 고객 검수, 격리된 테스트 환경이 목적이라면 맥 원격 환경 안내와 운영 도움말을 먼저 대조하십시오.
고객 코드가 Cloud Agents에 들어갈 수 없는 프로젝트라면, 기존 환경의 편의성보다 데이터 경로를 설명할 수 있는지가 우선입니다. 프로젝트를 분류한 뒤 격리형 원격 맥으로 옮기면 개발 도구를 전부 포기하지 않고도 저장소와 실행 환경의 경계를 별도로 관리할 수 있습니다. MacHTML의 원격 맥 환경이 필요한 경우에는 프로젝트 자료의 민감도, 고객 승인 범위, 필요한 접근 통제를 함께 전달해 적합한 운영 방식을 확인하십시오.
고객 코드를 다루는 프로젝트에 안전한 원격 맥 환경을 준비하세요
MacHTML의 원격 맥에서 프로젝트별 개발 환경을 분리해 코드 접근 범위를 체계적으로 관리할 수 있습니다. 개인 장비에 고객 코드를 내려받지 않고 필요한 개발 작업을 원격 환경에서 진행할 수 있습니다. 프로젝트의 보안 기준과 팀의 작업 방식에 맞춰 적합한 맥 환경을 선택할 수 있습니다. 고객 코드 처리 전 승인 기준을 정리하고 MacHTML로 통제 가능한 개발 환경을 시작해 보세요.