Codex CLI를 공유 고권한 계정에서 바로 실행하면 안 됩니다. 이번 주에는 독립 시스템 계정, 저장소별 작업 공간, 최소 권한 샌드박스와 승인 정책을 먼저 만든 뒤 파일·네트워크·인증 정보·Xcode·복구 경계를 검수해야 합니다. 격리를 증명하지 못하면 단일 저장소 임시 노드나 이중 운영으로 되돌리십시오.
이 글은 원격 Mac에서 Codex CLI로 여러 저장소를 수정·빌드·테스트하는 전문 개발자, 장기 실행 노드를 관리하는 DevOps 엔지니어, 소스와 서명 자산의 접근 범위를 승인하는 보안·플랫폼 담당자를 위한 내용입니다.
이번 주 검수 일정은 권한보다 증거를 먼저 봅니다
첫 번째 작업일에는 테스트용 저장소와 별도 시스템 계정을 준비합니다. 실제 토큰, 운영용 인증서, 배포용 SSH 키는 사용하지 않습니다. 다음 작업일에는 파일과 네트워크 경계를 확인하고, 그 다음에는 Keychain, SSH Agent, Xcode 서명 흐름을 분리해 시험합니다. 마지막에는 작업 중단, SSH 연결 종료, Codex CLI 종료, Mac 재부팅 뒤의 복구 결과를 확인합니다.
Codex CLI의 샌드박스, 승인 정책, 작업 공간 쓰기 범위, 네트워크 설정은 서로 다른 통제 수단입니다. 샌드박스가 켜져 있어도 시스템 계정이 볼 수 있는 파일이나 SSH Agent가 자동으로 안전해지는 것은 아닙니다. 공식 Codex 샌드박스와 승인 정책 설명은 명령 실행 범위와 승인 흐름을 구분해 설명합니다.
이번 주의 운영 판단은 다음 조건으로 나누십시오.
- 독립 계정과 저장소별 작업 공간을 만들고, 파일·네트워크·인증 정보·Xcode·복구 시험에서 모두 증거가 남으면 다중 저장소 운영을 선택합니다.
- 파일 격리는 통과했지만 인증 정보나 네트워크 경계가 불명확하면 단일 저장소 임시 노드로 제한합니다.
- 여러 저장소의 작업 폴더, 캐시, 포트가 서로 섞이면 독립 노드 풀이나 이중 운영으로 되돌립니다.
- 운영용 서명 키가 기본 Agent 세션에서 보이면 즉시 중지하고 노드를 재구축합니다.
- 재부팅 뒤 프로세스와 임시 파일을 회수하지 못하면 장기 실행을 보류합니다.
파일 경계: 같은 Mac에서도 저장소를 섞지 않는지 확인합니다
Codex CLI가 실제로 읽고 수정할 수 있는 범위는 프롬프트가 아니라 실행 환경과 시스템 권한이 결정합니다. 현재 저장소의 작업 폴더, 상위 경로, 다른 저장소의 Git 메타데이터, 프로젝트 설정 파일, 임시 디렉터리를 각각 확인해야 합니다.
Codex CLI가 원격 Mac에서 여러 저장소를 처리해도 안전한 조건은 무엇입니까?
각 작업이 독립 시스템 계정 또는 독립 작업 공간에서 실행되고, 테스트 저장소 밖의 파일을 읽거나 쓰지 않는다는 기록이 있어야 합니다. 다른 저장소의 파일명만 알려 주는 시험, 다른 저장소 파일을 읽는 시험, 상위 경로에 임시 파일을 만드는 시험을 나누어 실행하십시오.
| 검수 대상 | 시험 방법 | 통과 증거 | 즉시 중지 조건 |
|---|---|---|---|
| 작업 폴더 | 저장소 밖 경로 읽기와 쓰기를 각각 요청 | 거부 결과와 실행 로그 보관 | 다른 저장소 파일을 읽거나 수정 |
| Git 메타데이터 | 다른 저장소의 브랜치·설정·후크 경로를 분리 시험 | 현재 저장소 정보만 노출 | 다른 저장소의 Git 정보 노출 |
| 임시 파일 | 작업 전후 임시 경로와 상위 경로 비교 | 허용된 작업 공간 안에만 잔류 | 상위 경로에 비공개 파일 생성 |
| 프로젝트 설정 | 저장소 설정 파일의 변경 목록 확인 | 승인된 파일만 변경 | 숨은 설정이나 자동 생성 파일 변경 |
시험용 경로, 저장소 이름, 계정 이름은 모두 <WORKSPACE_PATH>, <REPOSITORY_NAME>, <AGENT_USER> 같은 자리표시자를 사용하십시오. 실제 운영 경로를 문서에 남기지 않는 편이 좋습니다.
샌드박스 설정의 필드와 권한 이름은 사용 중인 공식 문서와 현재 설정 원본을 대조해야 합니다. Codex 설정 원본은 설정 구조를 확인하는 자료이며, 설정 원본만 보고 현재 노드의 실제 권한이 통과했다고 판단해서는 안 됩니다.
현재 저장소만 수정하도록 제한하려면 어떻게 해야 합니까?
작업 공간을 저장소 내부로 좁히고, 시스템 계정의 상위 경로 쓰기 권한을 제거한 뒤, 다른 저장소를 별도 계정이나 별도 노드로 분리해야 합니다. “이 저장소만 수정하라”는 지시문은 보조 규칙일 뿐 시스템 보안 경계가 아닙니다. 승인 정책과 샌드박스 설정은 Codex 권한 설정 문서를 기준으로 다시 확인하십시오.
네트워크 경계: 모델 통신과 외부 실행을 따로 검수합니다
네트워크는 한 덩어리의 권한으로 기록하면 안 됩니다. 모델 통신, 의존성 다운로드, Git 원격 저장소, 내부 API, 외부 도구, MCP 실행기를 각각 분리해야 합니다. 승인을 끈 상태가 네트워크를 자동으로 허용한다는 뜻도 아닙니다.
| 네트워크 경로 | 확인할 내용 | 통과 조건 | 중지 조건 |
|---|---|---|---|
| 모델 통신 | Codex CLI가 사용하는 통신 경로와 기록 | 승인된 경로만 로그에 표시 | 예상하지 않은 외부 주소 접속 |
| 의존성 다운로드 | 패키지 관리자와 저장소 주소 | 허용 목록 안에서만 다운로드 | 임의 미러나 추적 주소 사용 |
| Git 작업 | 원격 저장소의 읽기·쓰기 범위 | 필요한 저장소만 접근 | 다른 저장소로 인증 요청 |
| MCP·외부 실행기 | 도구가 별도 프로세스와 네트워크를 여는지 | 실행기와 요청을 모두 기록 | 로컬 제한을 우회하는 실행 경로 |
Codex 공식 저장소의 네트워크 설정 설명을 바탕으로 기본 거부, 작업별 허용, 요청 기록을 확인하십시오. 도메인 허용 목록을 만들 때는 <ALLOWED_DOMAIN>처럼 자리표시자를 사용하고, 실제 내부 주소나 토큰을 문서에 넣지 마십시오.
커뮤니티 Issue는 일반적인 취약점의 증거가 아닙니다. MCP나 권한 전달과 관련한 커뮤니티 보고는 재현 여부와 적용 범위를 별도로 확인해야 하는 대기 위험으로만 기록하십시오.
인증 정보와 서명 자산: 읽을 수 있음과 사용할 수 있음을 분리합니다
원격 Mac의 Codex CLI 프로세스가 어떤 시스템 계정으로 실행되는지부터 확인하십시오. 환경 변수, SSH Agent 소켓, 로그인 Keychain, Xcode 서명 신원, 배포용 인증서와 업로드 토큰을 각각 나누어 시험해야 합니다.
| 자산 | 무자격 시험 | 읽기 전용 시험 | 임시 자격 시험 |
|---|---|---|---|
| SSH 키 | 키와 Agent가 보이지 않아야 함 | 저장소 읽기만 허용 | 테스트 저장소에서만 제한된 쓰기 |
| Keychain | 항목 목록과 비밀 값 모두 차단 | 비밀 값 없이 필요한 항목만 확인 | 만료 가능한 시험 항목만 사용 |
| Xcode 서명 | 서명 신원 없이 빌드 시도 | 테스트 서명으로 검증 | 폐기 가능한 테스트 자산으로 업로드 모의 |
| 환경 변수 | 비밀 변수 이름과 값 확인 | 필요한 비밀만 주입 | 작업 종료 후 즉시 폐기 |
원격 Mac의 Codex CLI가 SSH 키와 macOS Keychain을 볼 수 있습니까?
시스템 계정, SSH Agent 전달, Keychain 접근 권한에 따라 달라집니다. 따라서 “원격 Mac이므로 볼 수 없다”거나 “샌드박스이므로 모두 차단된다”고 단정하면 안 됩니다. Apple의 Keychain 접근 권한 안내를 기준으로 테스트 항목과 승인 기록을 확인하십시오.
운영 서명 개인 키는 기본 Agent 세션에 직접 노출하지 마십시오. 빌드와 서명을 분리하고, 서명이 꼭 필요하면 폐기 가능한 테스트 자격과 별도 실행 계정을 사용하십시오. 코드 수정은 성공했지만 서명과 업로드가 실패하는 상태가 오히려 안전한 기본값일 수 있습니다.
Xcode 실행과 병렬성: 명령 성공보다 재현성을 측정합니다
Codex CLI가 xcodebuild를 실행할 수 있다는 사실만으로 CI 노드가 운영 가능한 것은 아닙니다. 테스트 프로젝트에서 파생 데이터, 캐시, 시뮬레이터 상태, 스크립트, 포트, 로그 경로를 각각 기록하십시오. 명령, 프로젝트, 계정, Team ID는 <BUILD_COMMAND>, <PROJECT_PATH>, <TEAM_IDENTIFIER> 같은 자리표시자로 표시합니다.
병렬 작업을 흉내 낼 때는 같은 저장소를 단순히 두 번 실행하지 마십시오. 서로 다른 저장소가 같은 캐시 경로와 포트를 사용하는 상황, 한 작업이 중단된 뒤 다른 작업이 시작되는 상황, 한 작업의 로그가 다른 작업에 보이는 상황을 나누어 시험해야 합니다.
| 병렬성 지표 | 수집할 증거 | 통과 판단 | 회귀 시 선택 |
|---|---|---|---|
| 작업 공간 | 시작·종료 시 파일 차이 | 저장소별 변경만 존재 | 단일 저장소 순환 |
| 캐시 | 캐시 경로와 소유 계정 | 공유가 필요하면 읽기 범위만 허용 | 독립 노드 풀 |
| 포트 | 작업별 사용 포트와 종료 상태 | 종료 뒤 점유가 없음 | 병렬 실행 금지 |
| 로그 | 작업 ID와 계정별 로그 | 다른 작업의 비밀이 없음 | Agent는 검토만 수행 |
캐시 재사용으로 빌드가 빨라졌다는 평가는 이 글의 안전 통과 조건이 아닙니다. 같은 결과를 다시 만들 수 있는지, 다른 저장소의 산출물이 섞이지 않는지가 우선입니다.
정리와 재부팅 복구: 장기 실행 전 마지막 관문입니다
작업 중단은 정상 흐름으로 취급해야 합니다. SSH 연결을 끊고, Codex CLI 프로세스를 종료하고, 작업 중간에 Mac을 재부팅한 뒤 다음 항목을 수집하십시오.
- 남아 있는 Agent와 하위 프로세스 목록을 확인합니다.
- 임시 파일, 파생 데이터, 소켓, 포트 점유를 확인합니다.
- 환경 변수, SSH Agent 연결, 임시 Keychain 항목을 폐기합니다.
- Git 변경 목록과 새로 생성된 파일을 보관합니다.
- 재부팅 뒤 자동으로 다시 시작된 작업과 로그를 확인합니다.
- 같은 저장소를 다시 선택했을 때 이전 작업의 상태가 섞이지 않는지 확인합니다.
각 실행에는 작업 ID를 붙이고, 시작 시점 권한 스냅샷과 종료 시점 차이 목록을 함께 저장하십시오. 인증 정보의 실제 값은 기록하지 말고 존재 여부와 접근 결과만 보관합니다.
Codex CLI 다중 저장소 작업의 잔류 파일과 프로세스는 어떻게 정리합니까?
정리 스크립트 하나에 의존하지 말고, 프로세스 회수·임시 경로 삭제·포트 해제·자격 폐기·Git 차이 보존을 각각 검증해야 합니다. 하나라도 자동 회수되지 않으면 해당 노드는 장기 실행에 부적합합니다. 복구 결과가 불명확한 경우에는 저장소를 바꾸기 전에 노드를 재구축하는 편이 안전합니다.
검수 결과에 따른 운영 선택
검수 결과를 “안전” 또는 “위험”으로만 기록하면 다음 조치가 모호해집니다. 아래 네 가지 상태로 결정하십시오.
- 운영 가능: 독립 계정, 저장소 경계, 네트워크 기록, 인증 정보 제한, Xcode 재현성, 재부팅 복구가 모두 증명된 경우입니다.
- 제한 운영: 파일 경계는 확인했지만 네트워크나 서명 자산이 제한된 경우입니다. 단일 저장소와 비생산 자격만 허용합니다.
- 노드 재구축: 다른 저장소의 파일·캐시·로그·포트가 섞이거나 권한 회수가 실패한 경우입니다.
- 보류: MCP 실행 경로, Keychain 접근, 재부팅 후 자동 실행처럼 책임 범위를 설명하지 못하는 항목이 남은 경우입니다.
공유 원격 Mac은 구매 비용 없이 개발 환경을 마련할 수 있지만, 공유 계정과 장기 작업을 한곳에 몰아넣으면 격리 증거를 관리하기 어려워집니다. 직접 관리하는 현재 방식은 물리 장비 비용, 유지보수, 전원과 재부팅 대응, 고정된 용량이라는 부담이 있고, 임시 클라우드 환경은 macOS 도구 체인과 실제 Xcode 동작을 별도로 검증해야 합니다. 반면 VMSPIN의 원격 Mac은 단기 격리 시험이나 비생산 저장소 검수에 필요한 실제 Mac 환경을 준비하는 선택지가 될 수 있습니다. 다만 장기 고정 부하, 물리 장치 연결, 운영용 서명 키의 직접 보관이 필요하다면 자체 장비나 독립 CI 노드가 더 적합할 수 있습니다.
격리 시험용 Mac이 필요하다면 먼저 VMSPIN 원격 Mac 요금과 이용 방식을 확인하고, 비생산 저장소로 위의 검수표를 재현하십시오. 장기 다중 저장소 운영을 결정하기 전에는 VMSPIN Mac 환경 신청 페이지에서 필요한 접근 방식과 운영 조건을 확인하는 순서가 안전합니다. 핵심 키워드인 Codex CLI 원격 Mac 다중 저장소 보안은 서비스 이름보다 실제 권한 스냅샷, 파일 차이, 네트워크 기록, 정리 결과로 판단해야 합니다.