Xcode Cloud sudo 사용 불가: 2026년 원격 Mac으로 옮겨야 할까?

승자는 작업에 따라 달라집니다. Homebrew 도구 설치, 환경 변수 읽기, 일반 사용자 스크립트만 필요하면 Xcode Cloud를 먼저 고치고, 관리자 권한·상시 서비스·빌드 사이의 지속 파일·깊은 시스템 설정이 필요하면 원격 Mac으로 옮기는 편이 맞습니다. 두 요구가 섞였다면 표준 테스트는 Xcode Cloud에 남기고 복잡한 배포만 원격 Mac으로 분리하는 방식이 가장 낮은 위험을 만듭니다.

이 글은 ci_post_clone.sh에서 sudo 또는 권한 오류가 발생한 독립 개발자를 위한 안내서입니다. 백그라운드 서비스와 사용자 지정 도구 체인이 필요한 작은 앱 팀, Xcode Cloud와 제어 가능한 원격 Mac을 비교하는 배포 담당자도 대상입니다.

Xcode Cloud sudo 사용 불가를 먼저 오류 유형으로 나누기

다음과 같은 로그가 있다고 가정하겠습니다. 실제 값은 저장소 이름, 사용자 이름, 토큰을 노출하지 않도록 바꿔야 합니다.

[ script ] $ sudo install-tool --project <PROJECT_PATH>
sudo: a terminal is required to read the password
sudo: a password is required

이 로그만 보고 sudo를 다시 시도하면 해결되지 않습니다. 오류는 대체로 세 갈래입니다.

Apple은 Xcode Cloud 사용자 지정 빌드 스크립트가 sudo를 통해 관리자 권한을 얻는 방식으로 동작하지 않는다고 안내합니다. 따라서 대화형 비밀번호 입력이나 반복 승인으로 제한을 넘을 수 없습니다. 사용자 지정 빌드 스크립트에 관한 Apple 공식 안내와 Xcode Cloud 작업 흐름 참고 문서를 기준으로 권한 경계를 확인해야 합니다.

#!/bin/sh
set -eu

printf '%s\n' "user=$(id -un)"
printf '%s\n' "home=${HOME}"
printf '%s\n' "path=${PATH}"
command -v <TOOL_NAME> || true

이 검사는 관리자 권한을 얻기 위한 것이 아닙니다. 현재 실행 사용자, 홈 폴더, 도구 경로를 확인하는 용도입니다. 경로가 잘못되었는데 권한 문제로 오해하는 사례를 먼저 제거할 수 있습니다.

의존성 설치는 원격 Mac 이전보다 스크립트 수정이 먼저입니다

Xcode Cloud에서 사용자 지정 빌드 스크립트를 쓴다고 해서 모든 도구를 시스템 전체에 설치해야 하는 것은 아닙니다. Apple의 의존성 설치 안내는 작업 흐름 안에서 필요한 의존성을 준비하는 방법과 설치 위치를 구분해 설명합니다.

판단은 도구 설치와 프로젝트 의존성 복원을 나누어야 합니다.

• CocoaPods, Carthage, Swift Package Manager의 복원 실패는 저장소 설정, 버전 고정, 네트워크 또는 잠금 파일 문제일 수 있습니다.
• 특정 실행 파일이 없다는 오류는 PATH나 설치 단계 누락일 수 있습니다.
• 시스템 폴더에 파일을 쓰려는 도구는 일반 사용자 설치가 불가능할 수 있습니다.
• 프로젝트 안에 넣을 수 있는 실행 파일이라면 저장소의 별도 폴더에서 호출하는 방식으로 바꿀 수 있습니다.

예를 들어 시스템 폴더 대신 사용자 폴더를 지정하는 형태입니다.

#!/bin/sh
set -eu

TOOL_HOME="${HOME}/tools/<TOOL_NAME>"
mkdir -p "${TOOL_HOME}"
curl -fsSL "<VERIFIED_DOWNLOAD_URL>" -o "${TOOL_HOME}/<TOOL_FILE>"
chmod u+x "${TOOL_HOME}/<TOOL_FILE>"

export PATH="${TOOL_HOME}:${PATH}"
<TOOL_FILE> --version

위 명령의 주소와 파일 이름은 실제 프로젝트 값으로 바꿔야 합니다. 비밀번호, 인증 토큰, 팀 식별자와 앱 식별자는 스크립트에 직접 적으면 안 됩니다.

다음 조건을 모두 만족하면 Xcode Cloud에 계속 남길 수 있습니다.

brew가 이미 제공되는 환경이라도 모든 패키지가 관리자 권한 없이 설치된다는 뜻은 아닙니다. 패키지의 설치 경로와 사후 실행 경로를 직접 확인해야 합니다. Xcode Cloud 첫 작업 흐름 설정 문서의 스크립트 단계에 맞춰 작은 샘플 프로젝트에서 의존성 복원과 보관 빌드를 따로 검증하는 편이 좋습니다.

임시 파일과 지속성은 서로 다른 선택 기준입니다

Xcode Cloud에서 스크립트가 만든 파일이 다음 빌드에 보이지 않는다면, 스크립트가 실패했다고 단정하기 어렵습니다. 빌드 환경을 지속형 서버의 작업 폴더처럼 사용했을 가능성이 큽니다. 빌드 사이에 남겨야 하는 자료는 다음 네 경로 중 하나로 설계해야 합니다.

• 저장소에 넣어야 하는 생성 자원
• 사용자 지정 스크립트와 함께 제공하는 고정 파일
• 다음 단계로 전달하는 빌드 산출물
• 별도로 관리하는 외부 저장소의 캐시 또는 메타데이터

예를 들어 생성된 설정 파일을 같은 실행 안에서만 쓴다면 작업 폴더에 두면 됩니다.

GENERATED_FILE="${CI_WORKING_DIRECTORY}/<GENERATED_FILE>"
<GENERATOR_COMMAND> > "${GENERATED_FILE}"
test -s "${GENERATED_FILE}"
<BUILD_COMMAND> --config "${GENERATED_FILE}"

반대로 다음 실행에서도 반드시 존재해야 하는 대형 캐시, 로컬 데이터베이스, 수동으로 고친 상태는 임시 작업 폴더에 두면 안 됩니다. 이때는 캐시 복원과 무효화 규칙을 외부 저장소에 설계하거나, 상태를 유지할 수 있는 원격 Mac으로 옮겨야 합니다.

핵심은 파일 크기보다 복원 방식입니다. 작은 파일도 저장 위치가 명확하지 않으면 사라집니다. 큰 캐시도 매번 안전하게 다시 만들 수 있다면 반드시 이전해야 하는 것은 아닙니다.

주의: 원격 Mac으로 옮겨도 캐시가 저절로 안전해지는 것은 아닙니다. 캐시 경로, 삭제 정책, 재부팅 뒤 복구 방법을 문서화하고 실제로 검증해야 합니다.

백그라운드 서비스는 단발성 프로세스와 분리해서 판단하기

데이터베이스, 모의 서버, 사용자 지정 데몬, 시스템 확장, macOS 전체 설정 변경은 같은 “빌드 스크립트”로 묶어도 요구 조건이 다릅니다.

한 번의 빌드 안에서 일반 사용자 프로세스로 시작해 테스트가 끝나면 종료되는 모의 서버라면 Xcode Cloud에 남길 여지가 있습니다.

#!/bin/sh
set -eu

<LOCAL_SERVICE_BINARY> --port <PORT_NUMBER> &
SERVICE_PID=$!

cleanup() {
  kill "${SERVICE_PID}" 2>/dev/null || true
}
trap cleanup EXIT

<TEST_COMMAND> --endpoint "http://127.0.0.1:<PORT_NUMBER>"

이 방식은 장기 서비스가 아닙니다. 포트 충돌, 종료 처리, 로그 수집, 준비 완료 확인을 작업 안에서 처리해야 합니다. 서비스가 빌드 사이에도 실행되어야 하거나, 재부팅 뒤 자동 시작되어야 하거나, 고정된 로컬 데이터가 필요하면 원격 Mac 쪽 요구입니다.

원격 그래픽 세션, 백그라운드 프로세스, 무인 빌드는 서로 대체 관계가 아닙니다. VNC로 화면을 보는 것과 SSH로 명령을 실행하는 것은 접속 방식입니다. 상시 서비스와 재부팅 복구는 호스트 운영 방식입니다. 이 둘을 혼동하면 원격 Mac을 선택하고도 같은 장애를 반복할 수 있습니다.

서명 실패는 sudo 대신 키체인과 비밀 설정부터 확인하기

Archive나 업로드가 실패할 때마다 관리자 권한 부족으로 연결하면 안 됩니다. 코드 서명에는 다음 요소가 따로 관여합니다.

• 인증서와 개인 키가 모두 존재하는지
• 키체인이 비대화형 실행을 허용하는지
• 비밀 환경 변수가 올바른 단계에 전달되는지
• 프로비저닝 프로파일과 앱 식별자가 일치하는지
• Archive 단계와 업로드 단계가 같은 서명 설정을 쓰는지

Xcode Cloud의 환경 변수는 Apple 공식 환경 변수 참고 문서에 따라 작업 흐름에 전달해야 합니다. 팀 인증서 공유 방식은 Apple의 서명 인증서 공유 안내에서 확인할 수 있으며, 클라우드 관리 인증서를 쓰는 경우에는 클라우드 관리 인증서 문서의 적용 범위를 먼저 확인해야 합니다.

비밀 값은 다음처럼 이름만 참조합니다.

#!/bin/sh
set -eu

: "${SIGNING_SECRET:?missing signing secret}"
: "${APP_IDENTIFIER:?missing app identifier}"

<ARCHIVE_COMMAND> \
  --bundle-id "${APP_IDENTIFIER}" \
  --signing-input "${SIGNING_SECRET}"

실제 비밀 값은 출력하지 않아야 합니다. 키체인 접근 제어를 바꾸거나 인증서와 개인 키를 교체하는 작업은 영향 범위가 큽니다. 먼저 별도 작업 흐름에서 Archive만 검증하고, 기존 서명 자산으로 되돌릴 수 있는 조건을 기록해야 합니다. 일반적인 서명 설정 오류라면 원격 Mac으로 옮겨도 해결되지 않습니다.

다섯 가지 조건으로 수정·두 환경·이전을 결정하기

다음 조건 분기를 사용하면 sudo 오류 하나만으로 결론을 내리는 일을 피할 수 있습니다.

• 일반 사용자 폴더에 도구를 설치할 수 있으면 스크립트를 수정하고 Xcode Cloud를 선택합니다. 설치 위치, PATH, 버전 고정을 검증합니다.
• 의존성을 매번 새로 복원할 수 있고 작업 사이의 상태가 필요하지 않으면 Xcode Cloud를 유지합니다. 저장소와 산출물 전달을 기준으로 재실행합니다.
• 테스트 안에서만 실행되는 모의 서비스라면 일반 사용자 프로세스로 시작하고 종료하는 방식을 시도합니다. 준비 상태와 종료 처리가 실패하면 원격 서비스로 분리합니다.
• 관리자 권한, 시스템 설정, 상시 데몬 중 하나가 필수라면 우회 시도를 중단하고 원격 Mac을 검토합니다.
• 표준 테스트는 재현되지만 Archive와 무인 업로드만 제어가 필요하면 두 환경을 함께 씁니다. Xcode Cloud는 검증용으로, 원격 Mac은 복잡한 배포용으로 고정합니다.
• 실패가 한 번만 재현되거나 로그가 부족하면 이전하지 않습니다. 의존성 복원, Archive, 서명, 업로드, 재시작 후 복구를 같은 프로젝트에서 차례로 재현한 뒤 결정합니다.

이 선택에서 가장 중요한 정지 조건은 “한 번 성공했는가”가 아닙니다. 새 작업이 빈 환경에서 의존성을 복원하는지, 서명이 비대화형으로 동작하는지, 호스트 재시작 뒤에도 필요한 서비스와 파일이 돌아오는지를 확인해야 합니다.

Xcode Cloud에서 해결할 수 없는 시스템 제어가 명확해졌다면 SFTPMAC의 원격 Mac 대여 방식을 확인할 수 있습니다. 특정 지역의 접속 지연이나 운영 요구가 있다면 서울 원격 Mac 선택지처럼 실제 사용 위치에 맞는 항목을 먼저 비교하는 편이 낫습니다.

현재 환경을 그대로 유지하는 선택에도 약점이 있습니다. 임시 실행 환경은 빌드 사이의 상태를 보장하지 않고, 관리자 권한이 필요한 도구는 계속 막히며, 상시 서비스와 재부팅 복구를 한 작업 안에 억지로 넣기 어렵습니다. 반면 원격 Mac은 호스트 상태를 직접 관리해야 하므로 업데이트, 키체인 보호, 장애 복구 절차를 맡아야 합니다. 그래도 완전한 시스템 제어와 무인 Archive가 핵심이라면, 제한된 클라우드 스크립트를 반복 수정하는 것보다 SFTPMAC의 원격 Mac을 짧은 기간 먼저 대여해 실제 Archive와 재시작 복구를 검증하는 방식이 더 현실적입니다.

자주 묻는 내용

FAQ는 위의 권한, 설치, 지속성, 이전 조건을 실제 검색 의도에 맞춰 다시 정리한 것입니다. 단순히 sudo를 다른 명령으로 바꾸는 것보다, 작업이 요구하는 환경 경계를 먼저 확인해야 합니다.