주 애플리케이션은 Universal Binary인데 CI의 코드 생성기만 x86_64로 실행됩니다. 가장 빠른 해법은 Rosetta 지원 종료를 기다리지 말고, 격리된 Apple Silicon 노드에서 전체 의존성 체인을 원시 arm64로 다시 빌드하고 검수하는 것입니다.
macOS 27 Rosetta 마이그레이션을 담당하는 앱 개발자, 빌드 엔지니어, DevOps 엔지니어를 위한 글입니다. 특히 원격 맥 CI를 운영하거나 Intel Mac 사용자용 산출물을 계속 제공하는 팀이 대상입니다.
마지막 업데이트: 2026년 9월 20일. 날짜와 지원 상태는 [Apple Developer News의 macOS 27 출시 기록](https://www.apple.com/newsroom/2026/09/major-updates-for-apples-software-platforms-are-now-available/?utm_source=openai), [macOS 출시 기록](https://developer.apple.com/documentation/macos-release-notes/macos-27-release-notes?changes=latest_minor) 및 Rosetta 문서를 대조했습니다.**주의:** Apple은 macOS 27을 일반적인 Intel 앱에 Rosetta를 제공하는 마지막 큰 버전으로 확인했습니다. macOS 27이 현재 모든 Intel 전용 앱을 즉시 실행하지 못한다는 뜻은 아닙니다. [Apple의 소프트웨어 플랫폼 출시 기록](https://www.apple.com/newsroom/2026/09/major-updates-for-apples-software-platforms-are-now-available/?utm_source=openai)과 실제 프로세스 정보를 기준으로 판단해야 합니다.
먼저 원시 arm64 검수 노드를 분리합니다
Apple은 2026년 9월 14일 macOS 27을 정식 출시했습니다. 또한 macOS 27은 일반적인 Intel 앱에 대한 Rosetta 지원을 제공하는 마지막 큰 버전으로 확인됐습니다. 이후 버전의 세부 동작이나 특정 게임을 제외한 지원 범위는 이 글에서 확정하지 않습니다.
따라서 지금 필요한 조치는 “Rosetta가 아직 실행되는가”를 확인하는 것이 아닙니다. 주어진 커밋이 다음 조건을 만족하는지 증명하는 것입니다.
- 빌드와 테스트가 Apple Silicon 노드에서 원시 arm64로 실행됩니다.
- 필요한 Intel 산출물은 별도의 호환 작업에서 의도적으로 생성됩니다.
- 코드 생성기, 플러그인, 셸 도구와 서명 도구도 실행 구조가 확인됩니다.
- 캐시나 이미 설치된 Rosetta에 의존하지 않고 새 계정과 깨끗한 노드에서 재현됩니다.
첫 단계는 주 앱이 아니라 의존성 지도를 만드는 일입니다
앱 번들만 확인하면 가장 흔한 오류를 놓칩니다. 다음 항목을 같은 목록에 넣어야 합니다.
- 앱과 확장
- 플러그인과 프레임워크
- 동적 라이브러리와 정적 라이브러리
- 명령줄 도구와 데몬
- 코드 생성기와 빌드 보조 프로그램
- 사용자 정의 빌드 단계와 패키지 관리자 도구
- 테스트 실행 파일과 테스트용 외부 프로세스
file은 실행 파일의 구조를 빠르게 확인하는 데 사용하고, 여러 슬라이스의 존재는 lipo 결과로 다시 확인합니다. 경로는 실제 저장소 이름 대신 다음과 같은 자리 표시자를 사용하면 문서와 로그를 공유하기 쉽습니다.
file /PATH/TO/APP
lipo -info /PATH/TO/FRAMEWORK
file /PATH/TO/TOOLS/code-generator| 점검 대상 | 확인할 증거 | 처리 분류 | 통과 조건 |
|---|---|---|---|
| 앱, 확장, 프레임워크 | file, lipo 결과 | 소스 재빌드 또는 교체 | 필요한 arm64 슬라이스 확인 |
| 플러그인, 동적 라이브러리 | 로드 로그와 구조 정보 | 업그레이드, 교체, 차단 | 실제 앱 프로세스에서 로드 성공 |
| 명령줄 도구, 코드 생성기 | 실행 프로세스 구조 | 재설치 또는 소스 빌드 | CI 계정에서도 arm64 실행 |
| 정적 라이브러리, SDK | 링크 로그와 제공 구조 | 공급자 수정 요청 | 링크 단계에서 x86_64 경고 없음 |
| 데몬, 테스트 보조 도구 | 시작 로그와 자식 프로세스 | 별도 작업 또는 교체 | 통합 테스트에서 원시 실행 |
arm64가 주 앱에 표시된다는 이유로 전체 목록을 닫지 마십시오.
CI 계정과 도구 체인의 실제 실행 구조를 비교합니다
로컬 터미널에서 성공한 빌드가 원격 맥 CI에서 실패하는 이유는 PATH, 계정, 셸 초기화 파일이 다르기 때문입니다. 대화형 터미널, SSH 세션, Runner 서비스 계정에서 같은 명령을 실행하고 다음 결과를 보관합니다.
uname -m
arch
which xcodebuild
which swift
which /PATH/TO/TOOL
ps -axo pid,communame이나 arch 값을 기준으로 분기하는 스크립트, x86_64 경로를 직접 지정한 설치 코드, Intel 전용 다운로드 주소, 사용자 정의 빌드 단계를 검색합니다. Rosetta를 통하면 명령이 성공할 수 있으므로 성공 코드만 보지 말고 실제 프로세스 구조와 자식 프로세스를 확인해야 합니다.
CI 도구가 Rosetta에 의존하는지 어떻게 확인합니까? Runner 계정으로 도구를 직접 실행하고 프로세스 정보, 실행 경로, 빌드 로그를 함께 저장합니다. 대화형 셸에서만 arm64 도구가 선택되고 서비스 계정에서는 오래된 Intel 도구가 선택되는 경우가 있으므로, 새 계정 또는 깨끗한 노드에서 같은 커밋을 다시 실행해야 합니다.
이 단계에서 다음 중 하나라도 해당하면 “조건부 통과”가 아니라 수정 대상으로 분류합니다.
- Runner가 설치된 Rosetta에 의존합니다.
- 도구 경로에
x86_64가 하드코딩되어 있습니다. - 패키지 관리자가 계정별로 서로 다른 바이너리를 선택합니다.
- 사용자 정의 빌드 단계가 로컬 셸 설정을 전제로 합니다.
- 코드 생성기만 Intel 구조이고 그 사실이 빌드 로그에 남지 않습니다.
서드파티 바이너리는 네 가지 결과로 나눕니다
Universal Binary는 arm64와 x86_64 슬라이스를 함께 제공하는 형식입니다. 하지만 그것만으로 Rosetta가 필요 없다는 뜻은 아닙니다. 앱이 올바른 슬라이스를 로드하는지, 플러그인이 별도 프로세스로 실행되는지, 코드 생성기와 설치 도구가 어떤 구조인지까지 확인해야 합니다.
Apple의 Universal Binary 및 Apple Silicon 이식 안내와 Rosetta 번역 환경 문서를 기준으로 구조를 구분하되, 프로젝트의 통과 판정은 자체 로그로 남겨야 합니다.
각 의존성은 다음 네 가지 중 하나로만 표시합니다.
- 업그레이드 가능: arm64를 제공하는 버전으로 올리고 재검수합니다.
- 소스 재빌드 가능: 빌드 옵션과 패치 책임자를 정하고 내부 산출물로 교체합니다.
- 교체 가능: 동일 기능의 다른 도구나 라이브러리로 바꿉니다.
- 아직 이동 불가: Intel 호환 작업으로 격리하고 생산 주 경로를 차단하지 않습니다.
테스트는 원시 경로와 호환 경로를 분리합니다
테스트 통과만으로는 부족합니다. Apple Silicon에서 앱이 시작되는지, 단위 테스트와 통합 테스트가 원시 arm64로 실행되는지, 플러그인 로드와 핵심 작업이 같은 조건에서 끝나는지 각각 기록합니다.
JIT, 저수준 명령어, 프로세스 안에서 로드되는 플러그인이 있는 프로젝트는 별도 테스트를 둡니다. 충돌 로그, 프로세스 구조, 테스트 산출물과 실행 명령을 하나의 검수 증거로 묶어야 합니다.
| 실행 트랙 | 목적 | 반드시 남길 증거 | 판정 |
|---|---|---|---|
| Apple Silicon 원시 트랙 | 새 생산 주 경로 검증 | 구조 정보, 빌드 로그, 테스트 결과 | 주 경로 후보 |
| Intel 호환 트랙 | Intel Mac 사용자 지원 | x86_64 또는 Universal 산출물 | 별도 호환 경로 |
| 깨끗한 노드 트랙 | 환경 우연성 제거 | 새 복제본, 빈 재생성 캐시 | 재현성 확인 |
| 재시작 트랙 | 서비스와 키체인 복구 확인 | 재부팅 뒤 로그와 서명 상태 | 운영 준비도 확인 |
캐시, 서명과 배포 단계까지 깨끗하게 다시 검수합니다
캐시는 마이그레이션 실패를 숨기는 대표적인 원인입니다. 재생성 가능한 캐시를 비우고, 새로 복제한 저장소에서 의존성을 다시 받으며, 독립된 Apple Silicon 노드에서 같은 커밋을 실행합니다. 캐시 키에 uname, arch, SDK, 도구 버전이 빠져 있으면 서로 다른 구조의 산출물이 섞일 수 있습니다.
그다음 서명과 공증 단계에서 다음을 확인합니다.
- 서명 명령을 실행하는 계정이 예상한 계정인지 확인합니다.
- 키체인 접근 권한과 잠금 상태를 확인합니다.
- 최종 앱과 포함된 라이브러리의 구조를 다시 검사합니다.
- 공증 제출물과 실제 배포 산출물이 같은 파일인지 비교합니다.
- 재부팅 뒤 동일한 서명 체인과 실행 결과가 유지되는지 확인합니다.
체크리스트 점수로 생산 전환 여부를 결정합니다
아래 목록은 이 글의 검수 도구입니다. 각 항목을 실행한 뒤 증거 링크나 로그 위치를 내부 이슈에 기록하십시오.
- [ ] Apple Silicon 격리 노드에서 저장소를 새로 복제했습니다.
- [ ] 앱, 확장, 프레임워크, 라이브러리, 플러그인 목록에 담당자와 종료 조건을 붙였습니다.
- [ ]
file과lipo결과로 arm64, x86_64, Universal Binary를 구분했습니다. - [ ] SSH 세션과 Runner 계정의 PATH 및 실행 결과를 비교했습니다.
- [ ] 코드 생성기, 패키지 도구, 사용자 정의 빌드 단계의 프로세스 구조를 확인했습니다.
- [ ] 재생성 가능한 캐시를 비우고 같은 커밋을 다시 빌드했습니다.
- [ ] 원시 arm64 시작, 단위 테스트, 통합 테스트와 플러그인 로드를 각각 실행했습니다.
- [ ] Intel 호환 산출물이 필요한 범위와 담당 작업을 별도로 정했습니다.
- [ ] 서명, 공증, 키체인과 배포 산출물의 구조를 확인했습니다.
- [ ] 재부팅 뒤 빌드와 핵심 작업을 다시 실행했습니다.
- [ ] Rosetta가 없거나 사용되지 않는 깨끗한 조건에서 생산 경로를 재현했습니다.
| 점수 | 상태 | 운영 결정 |
|---|---|---|
| 통과 항목만 남고 차단 항목이 없음 | 통과 | Apple Silicon 원시 파이프라인을 주 경로로 전환 |
| 호환 작업만 남아 있고 담당자와 종료 조건이 있음 | 제한 통과 | 기한을 정해 Intel 작업을 별도 유지 |
| 원시 빌드 실패, 서명 실패 또는 숨은 Intel 도구 존재 | 차단 | 생산 전환 중지, 문제 의존성부터 수정 |
Intel 호환선은 남기되 Rosetta 기본값은 제거합니다
Intel Mac 사용자에게 계속 배포해야 한다면 호환 파이프라인을 없앨 필요는 없습니다. 다만 같은 커밋을 기준으로 Apple Silicon 원시 파이프라인을 주 경로로 두고, Intel 산출물 생성은 책임이 분명한 별도 작업으로 제한해야 합니다.
기존 Intel Mac 또는 오래된 도구 체인은 다음과 같은 단점이 있습니다.
- 원시 arm64 경로와 실제 사용자 호환 경로를 한 노드에서 분리하기 어렵습니다.
- Rosetta를 통한 성공이 숨은 Intel 의존성을 가릴 수 있습니다.
- 오래된 캐시와 계정별 환경 차이가 재현성을 떨어뜨립니다.
- 서명과 공증 단계에서 생산 도구와 호환 도구의 책임 경계가 흐려집니다.