최종 업데이트: 2026년 8월 13일. Apple Developer와 GitHub Docs를 기준으로 Xcode 26, macOS Tahoe 26, Runner 라벨, 요금 및 서명 조건을 확인했습니다.
공개 저장소의 표준 빌드와 짧은 자동 테스트는 GitHub Actions macOS Runner를 선택하고, GUI 디버깅·지속 환경·서명 문제 해결은 원격 Mac을 선택하면 됩니다. Xcode 26을 계속 사용하는 연구 프로젝트라면 대부분의 경우 CI와 원격 Mac을 함께 쓰는 이중 구성이 가장 관리하기 쉽습니다.
이 글은 iOS·macOS 연구 앱을 개발하는 대학원생, 공개 연구 도구를 관리하는 개발자, 실험실의 빌드 환경과 인증서를 관리하는 기술 담당자를 위한 글입니다. Linux나 Windows 장비는 있지만 안정적인 macOS 개발 환경이 없는 팀을 기준으로 설명합니다.
먼저 작업을 네 가지로 나누어 보세요
GitHub Actions의 macOS Runner가 Mac 한 대를 완전히 대신할 수 있는지는 작업 종류에 따라 달라집니다. 한 번 빌드가 성공하는 것과 전체 개발 환경을 맡길 수 있는 것은 다른 문제입니다.
| 작업 상황 | 우선 선택 | 이유 | 주의할 점 |
|---|---|---|---|
| 공개 저장소의 자동 빌드 | GitHub Actions macOS Runner | 코드와 의존성이 고정되어 있고 실행 결과를 자동으로 남길 수 있습니다 | Runner를 영구 작업 공간으로 사용하기 어렵습니다 |
| 짧은 단위 테스트와 배포 전 확인 | GitHub Actions macOS Runner | 커밋마다 같은 명령을 반복하기 좋습니다 | 실행 시간과 대기 시간을 기록해야 합니다 |
| 중단점·GUI·Xcode Preview 디버깅 | 원격 Mac | 화면을 보면서 파일과 설정을 계속 수정할 수 있습니다 | 접속 지연과 세션 관리 정책을 확인해야 합니다 |
| 인증서·프로비저닝·기기 테스트 | 원격 Mac 또는 이중 구성 | 키체인, 서명 설정, 기기 연결을 직접 점검할 수 있습니다 | 인증서와 개인 키를 저장소나 로그에 남기면 안 됩니다 |
| 장기적인 실험 환경 재현 | 원격 Mac | Homebrew 패키지, 캐시, 중간 결과를 유지할 수 있습니다 | 정기적인 스냅샷과 환경 문서가 필요합니다 |
GitHub Actions의 macOS Runner가 Mac을 대신할 수 있나요?
자동화된 빌드 장치로는 가능합니다. 그러나 대화형 개발 환경, 장기간 보존되는 의존성, GUI 기반 문제 분석까지 대신하지는 못합니다. Runner는 작업이 끝난 뒤 파일과 설정이 사라질 수 있는 임시 실행 공간으로 보는 편이 안전합니다.
공개 저장소라면 표준 GitHub 호스팅 Runner 사용이 무료로 제공되지만, 더 큰 Runner는 공개 저장소에서도 과금됩니다. 비공개 저장소에서는 요금제에 포함된 실행 시간과 초과 사용량을 따로 확인해야 합니다. GitHub는 macOS 표준 Runner의 기준 단가를 분당 0.062달러로 안내하고 있으며, 큰 macOS Runner의 기준 단가는 분당 0.102달러입니다. 작업 시간은 분 단위로 올림 처리됩니다. GitHub Actions 요금 문서와 GitHub Actions 과금 기준을 함께 확인해야 합니다.
주의: 연구팀의 비용은 단가만으로 계산하면 안 됩니다. 월별 실행 횟수, 각 작업의 대기 시간, 실패 후 재실행 횟수, 아티팩트와 캐시 저장량을 함께 기록해야 합니다.
공개 저장소는 자동 빌드부터 고정하세요
공개된 연구 도구나 수업 프로젝트라면 먼저 빌드 명령을 스크립트로 고정하는 것이 좋습니다. 사람이 Xcode 화면에서 누르는 순서가 아니라, 누구나 같은 명령으로 실행할 수 있어야 합니다.
권장 흐름은 다음과 같습니다.
- Xcode 프로젝트 또는 워크스페이스의 빌드 구성을 정리합니다.
- Swift Package Manager, CocoaPods 등 의존성의 버전을 고정합니다.
- 테스트 대상과 스킴을 명시합니다.
- Runner에서 사용할 Xcode 버전을 지정합니다.
- 빌드 로그와 결과 파일을 아티팩트로 저장합니다.
- 실패한 커밋과 실패 원인을 이슈에 연결합니다.
GitHub Actions의 macOS 이미지에는 여러 Xcode 버전이 함께 제공될 수 있습니다. 2026년 7월 기준 macOS 26 arm64 이미지에는 Xcode 26.0.1부터 26.6까지 여러 버전이 포함되어 있으며, 기본 버전은 이미지 변경에 따라 달라질 수 있습니다. 따라서 macos-latest만 고정해서 쓰기보다 필요한 운영체제와 Xcode 버전을 명시하고, 실제 실행 시 xcodebuild -version 결과를 로그에 남겨야 합니다. Runner 이미지 목록과 macOS 26 arm64 이미지의 설치 소프트웨어를 기준으로 검토하세요.
| 관리 항목 | GitHub Actions에서 해야 할 일 | 실패를 줄이는 방법 |
|---|---|---|
| 운영체제 | macos-15, macos-26 등 필요한 라벨을 확인합니다 |
latest 라벨만 의존하지 않습니다 |
| Xcode | 빌드 전에 선택한 버전을 출력합니다 | Xcode 버전과 SDK 버전을 로그에 기록합니다 |
| 의존성 | 잠금 파일을 저장소에 포함합니다 | 자동 최신화와 재현용 버전을 분리합니다 |
| 결과물 | 앱 아카이브, 테스트 결과, 로그를 저장합니다 | 실패한 실행도 일정 기간 보존합니다 |
| 캐시 | 캐시 키에 의존성 버전을 포함합니다 | 캐시가 원인인 실패를 구분합니다 |
Xcode 26은 iOS 26, iPadOS 26, tvOS 26, watchOS 26, macOS Tahoe 26 및 visionOS 26 SDK를 포함합니다. 또한 Xcode 26의 기본 요구 조건은 macOS Sequoia 15.6 이상입니다. Xcode 버전과 운영체제 조합을 임의로 섞지 말고 Apple의 Xcode 26 출시 정보에서 확인해야 합니다.
비공개 저장소는 실행 기록으로 비용을 판단하세요
비공개 연구 저장소에서는 “Runner가 싸다” 또는 “원격 Mac이 싸다”라고 먼저 결론 내리기 어렵습니다. 최소한 다음 네 가지 기록을 한 달 동안 모아야 합니다.
- 작업별 실제 실행 시간
- 대기열에서 시작까지 걸린 시간
- 실패 후 다시 실행한 횟수
- 동시에 실행해야 했던 작업 수
GitHub Actions는 비공개 저장소의 호스팅 Runner 사용량을 과금 대상으로 표시하며, 실행 시간은 다음 분으로 올림됩니다. 반대로 공개 저장소의 표준 호스팅 Runner와 자체 호스팅 Runner에는 일반적인 청구 실행 시간이 없다고 안내합니다. 작업 실행 시간 확인 방법을 기준으로 저장소별 사용량을 확인하세요.
Xcode 26 자동 빌드는 호스팅 Runner와 자체 환경 중 어디가 나을까요?
공개 저장소에서 의존성이 단순하고 작업이 짧으면 호스팅 Runner가 먼저입니다. 반대로 동일한 도구 버전, 내부 네트워크, 장기 캐시, 고정된 인증 환경이 필요하면 자체 환경이나 지속적으로 접근할 수 있는 원격 Mac을 검토해야 합니다.
다만 자체 호스팅 Runner를 구성한다고 해서 곧바로 좋은 개발 환경이 되는 것은 아닙니다. 보안 업데이트, 디스크 정리, Runner 프로세스 감시, 접근 권한, 장애 후 재연결을 직접 관리해야 합니다. GitHub는 macOS 자체 호스팅 Runner와 arm64를 지원하지만, arm64 기능은 문서상 공개 미리 보기로 표시되어 있으므로 운영 전 현재 상태를 다시 확인해야 합니다. 자체 호스팅 Runner 문서를 참고하세요.
디버깅과 환경 재현은 원격 Mac으로 분리하세요
연구 앱은 일반적인 웹 서비스보다 환경 문제가 오래 남습니다. 특정 Xcode 버전, Swift Package의 캐시, Homebrew 도구, 시뮬레이터 상태, 테스트 데이터가 서로 연결되기 때문입니다.
원격 Mac이 필요한 대표적인 상황은 다음과 같습니다.
- Xcode에서 중단점을 걸고 화면 상태를 확인해야 합니다.
- Xcode Preview 또는 GUI 도구에서만 재현되는 문제가 있습니다.
- Homebrew 기반의 분석 도구와 iOS 앱 빌드 환경을 함께 유지해야 합니다.
- 한 번의 실험 결과를 다음 날 그대로 이어서 확인해야 합니다.
- 인증서와 프로비저닝 설정을 직접 점검해야 합니다.
- 로그만으로는 원인을 구분할 수 없는 서명 오류가 발생합니다.
GitHub 호스팅 Runner는 작업 단위 자동화에는 적합하지만, 지속적인 개인 작업 공간으로 설계된 서비스가 아닙니다. 반면 원격 Mac은 VNC, SSH 또는 웹 콘솔로 접속해 파일과 도구를 유지하면서 직접 수정할 수 있습니다. 완전한 관리자 권한이 필요한 연구 환경이라면 권한 범위와 초기화 정책을 먼저 확인해야 합니다.
경험상 구분법: 같은 오류를 두 번 이상 재현해야 하고 매번 의존성을 다시 설치해야 한다면 CI 설정을 계속 늘리기보다 지속 환경을 따로 두는 편이 낫습니다.
원격 Mac을 선택할 때는 단순한 CPU 성능보다 다음 조건을 확인하세요.
| 확인 항목 | 확인할 내용 | 문제가 되는 경우 |
|---|---|---|
| 접속 방식 | VNC, SSH, 웹 콘솔 중 무엇을 제공하는지 | GUI와 터미널 작업을 함께 해야 하는데 한 방식만 지원할 때 |
| 권한 | 관리자 권한과 Homebrew 설치 권한 | 연구 도구 설치가 제한될 때 |
| 상태 유지 | 재부팅 후 파일과 설정이 유지되는지 | 매번 프로젝트를 다시 내려받아야 할 때 |
| 저장 공간 | Xcode, 시뮬레이터, 빌드 산출물의 보관 정책 | 오래된 결과가 예고 없이 삭제될 때 |
| 기기 연결 | 실제 iPhone 또는 iPad 연결 가능 여부 | 장치 식별자가 필요한 테스트를 해야 할 때 |
| 접근 통제 | 계정, 키체인, 인증서의 관리 방식 | 여러 연구원이 같은 비밀 정보를 공유할 때 |
Apple은 2026년 4월 28일부터 App Store Connect에 업로드하는 앱이 Xcode 26 이상과 해당 플랫폼의 26 SDK로 빌드되어야 한다고 안내하고 있습니다. 따라서 단순한 내부 빌드와 실제 제출 빌드는 분리해 검증해야 합니다. Apple의 제출 요구 사항을 확인하세요.
서명과 기기 테스트는 별도 통제선을 만드세요
자동 빌드가 통과해도 서명 단계에서 막힐 수 있습니다. 연구 프로젝트에서 자주 발생하는 차이는 다음과 같습니다.
- 일반 디버그 빌드와 배포용 아카이브의 서명 방식이 다릅니다.
- 인증서와 프로비저닝 프로파일의 만료일이 다릅니다.
- 팀 식별자와 번들 식별자가 일치하지 않을 수 있습니다.
- 실제 기기 테스트에는 시뮬레이터만으로 확인할 수 없는 조건이 있습니다.
- arm64 Runner에는 Apple 정책상 고정된 기기 식별자가 제공되지 않습니다.
GitHub 문서도 arm64 macOS 호스팅 Runner에는 고정 UUID 또는 UDID가 배정되지 않는다고 명시합니다. 고정 기기 식별자가 필요한 테스트를 자동화하려면 단순한 호스팅 Runner만으로 충분하지 않을 수 있습니다. GitHub 호스팅 Runner 참고 자료를 확인해야 합니다.
인증서와 개인 키는 저장소의 일반 변수나 빌드 로그에 직접 기록하지 마세요. 필요한 경우 암호화된 비밀 저장소를 사용하고, 서명 작업을 별도 작업으로 분리하며, 로그에 환경 변수와 키체인 내용을 출력하지 않는지 점검해야 합니다. 원격 Mac에서도 여러 사용자가 같은 계정을 공유하지 않도록 계정과 키체인의 책임 범위를 정해야 합니다.
두 환경을 연결하는 운영 절차를 만드세요
대부분의 대학 연구팀에는 다음과 같은 역할 분담이 현실적입니다.
- GitHub Actions: 커밋별 빌드, 단위 테스트, 정적 검사, 결과물 보관
- 원격 Mac: Xcode GUI 디버깅, 의존성 수정, 서명 오류 분석, 장기 재현
- 저장소: 소스 코드, 잠금 파일, 빌드 명령, 환경 문서
- 책임자: Xcode 버전과 인증서 변경 승인
도입 순서는 다음과 같이 진행하면 됩니다.
- 먼저 현재 Linux 또는 Windows 환경에서 자동화할 수 있는 명령을 분리합니다.
- 공개 저장소라면 GitHub Actions macOS Runner에서 깨끗한 빌드를 실행합니다.
- Xcode 버전, SDK 버전, 의존성 버전, 실행 시간을 로그로 남깁니다.
- Runner에서만 재현되는지, 개발 환경에서도 재현되는지 나눕니다.
- GUI 디버깅이나 지속적인 파일 보관이 필요한 문제를 원격 Mac으로 옮깁니다.
- 원격 Mac에서 수정한 설정을 문서와 스크립트로 저장소에 반영합니다.
- 서명과 실제 기기 테스트는 별도 승인 절차를 거칩니다.
- 최종 아카이브와 테스트 결과를 CI 아티팩트로 보관합니다.
- Runner 이미지나 Xcode가 바뀌면 같은 커밋을 다시 빌드합니다.
간단한 작업 정의도 환경 선택에 도움이 됩니다.
name: macos-build
on:
push:
pull_request:
jobs:
build:
runs-on: macos-26
steps:
- uses: actions/checkout@v4
- name: Xcode 버전 기록
run: xcodebuild -version
- name: 빌드 및 테스트
run: xcodebuild test -scheme 연구앱 -destination 'platform=iOS Simulator,name=iPhone 17'
이 예시는 자동화의 시작점일 뿐입니다. 실제 프로젝트에서는 시뮬레이터 이름, 스킴, 서명 방식, 의존성 설치 명령을 저장소 상황에 맞게 고정해야 합니다. Xcode 26과 macOS Tahoe 26의 세부 동작은 업데이트마다 바뀔 수 있으므로 Apple의 macOS Tahoe 26 출시 정보도 함께 확인하세요.
연구 프로젝트 유형별로 최종 선택을 고르세요
| 프로젝트 유형 | 기본 구성 | 원격 Mac이 필요한 시점 | 추천 판단 |
|---|---|---|---|
| 짧은 수업 과제 | GitHub Actions 중심 | 서명 오류를 직접 확인할 때 | 우선 CI로 시작합니다 |
| 공개 오픈소스 연구 도구 | GitHub Actions 중심 | 특정 macOS 환경의 재현 버그가 남을 때 | 자동 빌드와 임시 원격 환경을 연결합니다 |
| 장기 연구 앱 | GitHub Actions와 원격 Mac | 의존성, 인증서, 중간 결과를 계속 유지해야 할 때 | 처음부터 이중 구성을 준비합니다 |
| 여러 명이 참여하는 실험실 프로젝트 | CI와 원격 Mac 역할 분리 | 공동 디버깅과 배포 승인 때 | 계정·권한·비밀 관리 문서를 먼저 만듭니다 |
| 실제 기기와 배포가 중요한 앱 | CI와 고정 접근 환경 | 기기 식별자와 키체인 관리가 필요할 때 | 호스팅 Runner 단독 구성을 피합니다 |
공개 저장소와 비공개 저장소의 macOS CI 비용은 어떻게 비교해야 하나요?
공개 저장소의 표준 Runner 무료 여부만 보지 말고, 큰 Runner 사용 여부와 저장 공간을 따로 확인해야 합니다. 비공개 저장소는 포함된 실행 시간, 분 단위 올림, 실패 재실행, 캐시와 아티팩트 저장량을 합산해야 합니다. 원격 Mac은 사용 기간과 접속 권한을 기준으로 비교하되, 실제 요금은 선택한 환경과 기간을 확인한 뒤 계산해야 합니다.
실험실의 현재 방식이 Linux 또는 Windows 서버에만 의존하면 macOS 전용 빌드 확인이 늦어지고, GUI 디버깅을 위해 개인 장비를 돌려 써야 하며, 인증서와 Xcode 버전이 사람마다 달라지는 문제가 생깁니다. GitHub Actions만 사용하면 지속적인 의존성 보관과 수동 장애 분석이 부족할 수 있습니다. 이런 조건이라면 자동 작업은 그대로 GitHub Actions에 두고, 반복 디버깅과 장기 재현에 필요한 시간만 MACCOME의 원격 Mac으로 분리하는 구성이 더 합리적입니다.
필요한 기간이 짧은 수업 프로젝트라면 CI부터 시작하세요. 반대로 논문 제출이나 장기 연구처럼 같은 Xcode 환경을 여러 번 복원해야 한다면 MACCOME의 원격 Mac 환경과 Mac 임대 환경 선택 안내를 확인해 보세요. 실제 기기 연결이나 고정된 물리 장비가 반드시 필요한 경우에는 원격 Mac만으로 충분하지 않을 수 있으므로, 그 조건을 먼저 담당자와 확인해야 합니다.