Rosetta 2는 언제 지원이 중단될까? 2026년 기업 Mac CI 마이그레이션 체크리스트

Apple은 Intel 전용 macOS 앱에 일반적인 Rosetta 지원을 제공하는 마지막 주요 버전이 macOS 27이라고 안내했습니다. macOS 26.4 이후에는 이전 방식의 실행을 계속 사용하는 사용자에게 마이그레이션 알림이 표시될 수 있습니다. macOS 27.0 RC는 2026년 9월 9일 공개됐지만, 이 글을 확인하는 시점에 공개 정식 버전이 아직 나오지 않았다면 정식 Release Notes를 다시 확인해야 합니다. 자세한 경계는 Apple의 Rosetta 지원 공지와 macOS 27 Release Notes를 함께 대조하십시오.

여기서 세 가지를 분리해야 합니다.

• Intel Mac 하드웨어: Apple Silicon이 아닌 물리 장비입니다.
• Apple Silicon에서 실행되는 Intel 전용 macOS 앱: Rosetta가 x86_64 코드를 변환해 실행하는 경우입니다.
• Linux 가상 머신의 Intel 바이너리: macOS 앱 호환성과 같은 문제로 단정할 수 없습니다. Apple은 Linux 가상 머신에서 Intel 바이너리를 실행하는 별도 경로를 설명합니다. Linux 가상 머신의 Intel 바이너리 문서를 별도로 확인해야 합니다.

따라서 macOS 27에서 특정 명령이 계속 실행된다는 사실은 마이그레이션 완료를 뜻하지 않습니다. 신규 x86_64 의존성을 동결하고, 각 운영 작업에 담당자와 종료 조건을 붙이는 것이 첫 승인 조건입니다. macOS 28의 최종 동작이나 출시 시점은 Apple의 공식 확인 전까지 추정하지 마십시오.

macOS 27에서도 Intel 앱을 실행할 수 있습니까?

공식 지원 경계 안에서는 macOS 27에서 Intel 전용 macOS 앱을 실행할 수 있습니다. 그러나 이것은 영구 보장이나 CI 파이프라인의 미래 호환성을 뜻하지 않습니다. 설치 성공이 아니라 네이티브 arm64 실행, 서명, 플러그인, 재시작 복구까지 확인해야 업그레이드 승인을 내릴 수 있습니다.

CI 노드 목록만 보면 위험을 놓칩니다. 주 애플리케이션이 arm64여도 호출되는 설치 스크립트, 플러그인, 동적 라이브러리 또는 후처리 도구가 x86_64일 수 있습니다.

다음 항목을 하나의 자산 표로 관리하십시오.

• 실행 파일과 내부에서 호출하는 하위 프로세스
• 패키지 관리기와 설치 경로
• CI Agent, LaunchAgent, 데몬
• 셸 스크립트와 설치 전후 처리 스크립트
• Xcode 플러그인, 빌드 확장 기능, 코드 생성기
• 사내에서 만든 바이너리와 외부 공급업체의 폐쇄형 도구
• 동적 라이브러리, 테스트 런처, 배포 보조 도구
• 작업 이름, 담당자, 대체 버전, 실제 검증 로그

Apple의 Rosetta 기술 문서는 변환 실행 환경의 경계를 설명합니다. 실제 판정은 문서 설명과 현장 프로세스 기록을 함께 남겨야 합니다.

최소 확인 명령

각 CI 노드에서 전체 파일 시스템을 무작정 훑기보다, 실제 작업이 사용하는 경로와 프로세스를 먼저 확인하십시오.

file /path/to/tool
lipo -info /path/to/tool
ps -axo pid,comm | grep -E 'x86_64|tool-name'
uname -m
system_profiler SPHardwareDataType

판정 결과는 다음처럼 기록합니다.

Mac CI가 Rosetta 2에 의존하는지 어떻게 확인합니까?

주 애플리케이션 하나만 검사하지 말고, 실제 빌드에서 생성되는 하위 프로세스와 플러그인 로더를 기록해야 합니다. file과 lipo로 바이너리 형식을 확인하고, 실행 중인 프로세스 목록과 CI 로그를 대조하십시오. 프로세스가 셸 스크립트를 거쳐 실행된다면 스크립트가 호출하는 모든 경로도 자산 표에 추가해야 합니다.

마이그레이션 방식은 세 가지로 나뉩니다.

첫째, 공식 arm64 버전이 있고 기능이 같다면 직접 교체합니다. 이때 설치가 끝났다는 메시지만으로 완료 처리하지 말고 실제 프로젝트의 빌드, 테스트, 아카이브, 배포를 실행해야 합니다.

둘째, 사내 도구라면 arm64 재빌드 또는 Universal Binary 생성을 검토합니다. Apple은 Universal Binary 빌드 지침을 제공합니다. 두 절편을 만들었다면 각 절편의 실행뿐 아니라 코드 서명, 공증, 패키징 결과까지 확인하십시오.

셋째, 대체 버전이 없고 소스도 없는 폐쇄형 도구는 예외로 격리합니다. 예외는 “계속 사용” 승인이 아닙니다. 담당자, 사업 영향, 대체 조사일, 종료 예정일, 보안 조건을 붙인 제한적 운영입니다.

x86_64 빌드 도구를 arm64로 옮길 때 가장 먼저 볼 부분은 무엇입니까?

패키지 관리자 경로와 셸 인터프리터부터 확인하십시오. 도구 자체가 arm64여도 설치 스크립트가 x86_64 하위 프로세스를 실행할 수 있습니다. 이후 플러그인 로더, 동적 라이브러리, 테스트 런처, 서명 도구 순서로 확인하고, 같은 프로젝트에서 산출물과 오류 처리가 기존 결과와 일치하는지 검증하십시오.

Apple의 Apple Silicon 포팅 문서는 애플리케이션 이전 시 검토할 방향을 제공합니다. 문서에 없는 사내 플러그인과 설치 스크립트는 조직의 실행 로그가 유일한 증거가 될 수 있습니다.

다음 체크리스트를 담당자별 승인 문서에 붙이십시오.

• [ ] 실행 파일의 아키텍처가 기록됐습니다.
• [ ] 호출되는 하위 프로세스까지 조사했습니다.
• [ ] 패키지 관리자와 설치 경로를 고정했습니다.
• [ ] 플러그인과 동적 라이브러리의 로딩 결과를 남겼습니다.
• [ ] 실제 프로젝트에서 테스트와 아카이브를 실행했습니다.
• [ ] 산출물 해시와 서명 검증 결과를 보관했습니다.
• [ ] 실패 시 이전 노드로 되돌리는 절차가 있습니다.

네이티브 arm64 작업과 Rosetta 호환 작업을 같은 큐에 두면 결과 해석이 어려워집니다. 환경 변수, 패키지 캐시, 빌드 캐시가 섞이고, 어떤 노드에서 성공했는지 추적하기도 어렵습니다.

노드 태그나 큐 이름으로 최소한 다음을 분리하십시오.

• arm64-native: 신규 작업과 마이그레이션 검증 작업
• rosetta-compat: 승인된 기존 예외 작업
• release-verified: 서명과 배포까지 확인된 출시 작업

대표적인 Pull Request, 전체 테스트, 아카이브, 배포 작업을 두 풀에서 각각 실행하십시오. 비교할 항목은 단순한 성공 여부가 아닙니다.

• 산출물 해시와 서명 결과
• 테스트 실패 유형
• 캐시 재사용 여부
• 큐 대기와 작업 재시도
• 노드 재부팅 뒤 Agent 자동 복귀
• Keychain 접근과 인증서 사용
• 대화형 로그인 없이 실행되는지 여부

구체적인 소요 시간과 처리량은 조직의 CI 기록 또는 현장 실측만 사용해야 합니다. 근거가 없는 평균 시간으로 노드 수를 산정하지 마십시오.

주의: 터미널에서 수동 실행한 작업이 성공해도 무인 CI가 정상이라는 뜻은 아닙니다. 재부팅, Keychain 잠금, 로그인 세션 부재, 데몬 재시작을 포함한 서비스 계정 검증이 빠지면 호환성 판단은 완료되지 않습니다.

기업은 macOS 27 호환 노드를 계속 보유해야 합니까?

마이그레이션이 끝나지 않은 승인 예외가 있으면 한시적으로 보유할 수 있습니다. 다만 호환 풀에는 각 작업의 담당자와 종료 조건이 있어야 하며, 신규 작업을 배정해서는 안 됩니다. 모든 생산 작업이 arm64 네이티브 실행과 서명·복구 검증을 통과한 뒤에만 축소 여부를 판단하십시오.

Rosetta 의존성이 남은 도구가 결과를 만들어도, 출시 과정의 보안 경계를 통과하지 못하면 운영에 넣을 수 없습니다.

다음 항목은 별도 승인으로 분리하십시오.

• Keychain에서 인증서와 프로파일을 읽는지
• 코드 서명과 공증이 두 아키텍처 절편에서 통과하는지
• 내부 플러그인이 올바른 절편을 로드하는지
• 데몬이 로그인 세션 없이 시작되는지
• 노드 재부팅 후 CI Agent와 비밀 저장소 연결이 복구되는지
• 산출물 해시, 로그, 승인 기록을 재현할 수 있는지
• 보안 설정을 낮춰야만 실행되는 구성인지

보안 설정을 완화해야 하는 구성은 정상 마이그레이션으로 분류하지 마십시오. 차단하거나 명시적인 만료일이 있는 예외 목록으로 이동해야 합니다. Universal Binary를 사용하더라도 두 절편 모두 검증해야 합니다. 한쪽 절편만 테스트한 결과는 배포 증거가 아닙니다.

Xcode와 운영체제 조합을 바꾸는 작업은 Xcode 27 Release Notes와 macOS 문서를 함께 확인하십시오. Release Notes의 변경 사항을 읽지 않고 CI 이미지만 교체하면 도구 버전과 서명 환경의 차이를 놓칠 수 있습니다.

마이그레이션 기간의 용량은 개발자 수로 바로 환산하면 안 됩니다. 다음 변수를 기록하십시오.

• 아직 호환 풀에 남은 작업 수
• arm64 네이티브 노드가 처리할 수 있는 검증 완료 작업량
• 출시 집중 시간대의 대기량
• 장애 시 필요한 여유 노드
• 호환 풀을 폐기할 예정일
• 이중 실행에 필요한 임시 용량
• 노드 교체와 운영 자동화에 드는 내부 인력

기존 Apple Silicon 노드가 이중 실행을 감당하면 추가 구매 없이 진행할 수 있습니다. 그렇지 않으면 신규 장비 구매, 단기 원격 Mac 임대, 혼합 노드 풀을 같은 기준으로 비교하십시오. 장기 고정 부하와 물리 장비 접근이 핵심이면 직접 구매가 적합할 수 있습니다. 반대로 마이그레이션 기간에만 추가 노드가 필요하거나 출시 일정 전에 빠르게 격리 환경을 만들어야 한다면 임시 원격 Mac이 더 단순할 수 있습니다.

이때 비용은 월 이용료만 보지 말고 설치, 교체, 장애 대응, 유휴 용량, 보안 검토, 종료 후 처분 비용까지 포함해야 합니다. CALMVPS의 한국어 서비스 안내와 요금 정보를 확인할 때도, 공개된 조건을 실제 필요한 기간과 노드 수에 대입해 계산하십시오.

다음 승인 순서를 사용하면 구매 결정을 늦추지 않으면서도 과잉 확장을 피할 수 있습니다.

1. x86_64 의존 작업과 담당자를 확정합니다.
2. arm64 네이티브 노드에서 대표 작업을 이중 실행합니다.
3. 서명, 공증, Keychain, 재부팅 복구 증거를 수집합니다.
4. 남은 예외 작업에 종료일과 호환 풀 용량을 부여합니다.
5. 출시 집중 시간대의 대기와 장애 여유를 기준으로 부족분을 계산합니다.
6. 부족분만 구매, 원격 임대 또는 혼합 풀로 보충합니다.
7. 예외 작업이 종료되면 호환 노드를 회수하고 신규 유입을 차단합니다.

기술 책임자는 다음 조건을 모두 확인한 뒤 macOS 27 업그레이드와 호환 풀 축소를 승인하는 편이 안전합니다.

• IT 책임자: 모든 노드의 운영체제, 칩 구조, 관리 계정, 복구 경로가 기록됐습니다.
• 도구 체인 담당자: x86_64 실행 파일과 플러그인의 교체·재빌드·예외 분류가 끝났습니다.
• CI 플랫폼 팀: 네이티브 풀과 호환 풀이 큐와 캐시에서 분리됐습니다.
• 보안 담당자: 서명, 공증, Keychain, 무인 재시작 결과가 남아 있습니다.
• 출시 담당자: 실제 산출물과 배포 승인 로그를 재현할 수 있습니다.
• 구매 담당자: 이중 실행 기간과 호환 풀 종료 뒤의 장기 용량을 따로 산정했습니다.

Apple이 macOS 27 정식 버전의 지원 문구를 수정하거나, macOS 28 테스트 버전을 공식 공개하거나, 주요 빌드 도구가 x86_64 지원을 중단하면 이 승인 문서를 다시 검토해야 합니다. 현재 확인되지 않은 미래 동작을 전제로 호환 풀을 영구 운영해서는 안 됩니다.

Apple Silicon 장비를 이미 보유하고도 CI가 Rosetta에 기대는 현재 방식은 숨은 의존성, 캐시 오염, 재부팅 후 복구 실패, 예외 노드의 지속 운영 비용을 남깁니다. 반대로 무조건 장비를 추가 구매하면 마이그레이션이 끝난 뒤 유휴 용량과 관리 부담이 남을 수 있습니다. 먼저 격리된 원격 Mac 시험 노드에서 실제 파이프라인을 검증하고, 증거가 통과한 뒤 장기 구매와 임대 규모를 결정하는 편이 리스크가 작습니다.

단기 이중 검증이나 출시 전 PoC에 추가 Apple Silicon 노드가 필요하다면 CALMVPS의 원격 Mac 신청 안내에서 조건을 확인할 수 있습니다. 핵심은 임대를 먼저 정하는 것이 아니라, 네이티브 실행·서명·복구 증거를 확보한 뒤 그 결과에 맞춰 장기 인프라를 선택하는 것입니다.