Linux 중심 CI에서 macOS 앱을 빌드하고 서명한 뒤 공증하는 팀을 위한 배포 판단 가이드입니다. 제출과 조회만 필요한 경우와 실제 Mac이 필요한 단계를 시간순으로 나누고, 혼합 CI를 검증하는 조건을 설명합니다.
Linux 중심 CI에서 macOS 앱을 빌드하고 서명한 뒤 공증하는 팀을 위한 배포 판단 가이드입니다. 제출과 조회만 필요한 경우와 실제 Mac이 필요한 단계를 시간순으로 나누고, 혼합 CI를 검증하는 조건을 설명합니다.
macOS 앱 공증에 맥이 필요한가요? 파일 제출과 결과 조회만 맡는다면 Mac 없이도 검토할 수 있지만, 빌드·Developer ID 서명·티켓 부착·로컬 검증까지 포함한 배포라면 실제 Mac을 유지해야 합니다. 대부분의 팀에는 범용 CI가 지휘하고 원격 Mac CI가 macOS 전용 단계를 처리하는 혼합 구성이 가장 안전합니다.
이 글은 Linux CI에 macOS 앱 배포 기능을 추가하려는 플랫폼 엔지니어, 서명과 공증을 자동화하려는 macOS 개발자, 장기 임대와 필요할 때만 쓰는 Mac 노드 사이에서 결정하는 기술 책임자를 위한 내용입니다.
공증은 하나의 명령이 아니라 여러 작업의 연결입니다. 소스 빌드, 앱 서명, 배포용 패키징, 공증 제출, 상태 조회, 티켓 부착, 최종 검증을 분리해야 합니다. Apple의 공식 공증 흐름도 공증 전에 배포 가능한 형식과 서명 상태를 준비하도록 안내합니다.
macOS 앱을 Linux CI에서 공증할 수 있나요?
이미 서명된 제출 파일이 있고, Linux 노드에서 Apple Notary API를 호출하는 범위라면 가능합니다. 그러나 Linux에서 Xcode 프로젝트를 빌드하거나 Developer ID 서명을 수행하고, 배포 파일에 티켓을 부착한 뒤 macOS 도구로 검증하는 전체 흐름까지 끝내는 것으로 해석하면 안 됩니다.
따라서 첫 판단은 “공증 서비스에 접속할 수 있는가”가 아니라 “최종 사용자가 받는 파일을 어느 노드에서 만들고 검증하는가”여야 합니다.
소스에서 시작하는 파이프라인은 Xcode 빌드, 앱 번들 생성, 서명 대상 정리, 설치 패키지나 디스크 이미지 생성 순서로 진행합니다. Apple의 Mac 소프트웨어 패키징 안내는 배포 형식에 따라 준비 과정이 달라질 수 있음을 설명합니다.
이미 배포 파일이 있다면 Linux에서 해시와 파일 보관을 관리할 수 있습니다. 반대로 Xcode 프로젝트, macOS 전용 스크립트, 앱 번들 내부의 중첩 코드를 처음부터 처리해야 한다면 실제 Mac을 빌드 노드로 배치하는 편이 낫습니다.
이 단계의 통과 조건은 “빌드가 성공했다”가 아닙니다. 같은 소스와 잠금 파일로 반복 생성할 수 있는 서명 전 산출물을 저장하고, 파일 목록과 해시를 다음 단계의 입력으로 고정해야 합니다. 재생성한 파일이 다르면 공증 실패 원인을 제출 문제로 오인하기 쉽습니다.
공증은 서명을 대신하지 않습니다. 먼저 앱과 중첩 코드의 서명, 권한 설정, 서명 식별자, 키체인 접근 상태를 확인해야 합니다. Apple의 배포용 코드 서명 문서를 기준으로 서명 결과를 검증하고, 실제 인증서 이름이나 비밀값은 로그에 남기지 않는 구조를 사용해야 합니다.
전용 원격 Mac은 실행 계정과 키체인을 분리하기 쉽습니다. 공유 Mac은 다른 작업의 프로세스와 캐시, 로그인 세션이 섞일 위험이 있습니다. 외부 서명 단계를 쓰면 비밀값이 이동하는 구간과 실패 시 재시도 권한을 별도로 검토해야 합니다.
서명 단계에서 보관할 증거는 다음과 같습니다.
주의: 공증 제출 성공 로그만 남기면 서명 실패와 제출 실패를 구분할 수 없습니다. 단계별 입력 파일, 작업 계정, 실패 로그, 제출 식별자를 서로 연결해 보관해야 합니다.
notarytool과 Apple Notary API 중 무엇을 선택해야 하나요?
Mac 노드에서 제출과 상태 대기를 빠르게 묶고 싶다면 notarytool을 먼저 검토할 수 있습니다. 반대로 Linux 같은 범용 CI가 작업을 조율하고 제출 상태와 로그만 서비스 방식으로 관리하려면 Apple Notary API가 더 자연스러울 수 있습니다. Apple은 Notary API 개요와 소프트웨어 제출 인터페이스를 별도로 제공합니다.
두 방식의 차이는 공증 품질보다 운영 경계에 있습니다.
Apple의 공증 로그 조회 문서를 참고해 실패 원문을 저장해야 합니다. 성공이나 실패만 기록하면 서명된 파일과 실제 제출 파일이 달랐는지 추적하기 어렵습니다.
공증 상태가 성공으로 바뀌었다고 최종 배포가 끝난 것은 아닙니다. 배포 형식에 따라 티켓 부착이 필요할 수 있고, 사용자가 내려받을 최종 파일을 대상으로 오프라인 검증도 수행해야 합니다. 이 과정은 Apple 명령줄 도구와 macOS 실행 환경을 함께 요구할 수 있으므로, 제출을 Linux에서 했더라도 마무리 작업은 원격 Mac에 남겨 두는 설계가 안전합니다.
검증 대상은 중간 아카이브가 아니라 실제로 배포할 앱, 설치 패키지 또는 디스크 이미지여야 합니다. 서명 전 파일, 서명 후 파일, 제출 파일, 티켓 처리 후 파일을 같은 이름으로 덮어쓰지 않는 것도 중요합니다.
macOS 공증 과정에서 Mac에서 실행해야 하는 단계는 무엇인가요?
소스 기반 빌드, Xcode 도구 체인 사용, Developer ID 서명, macOS 명령줄 도구를 이용한 티켓 처리와 로컬 검증은 Mac 노드에 두는 편이 적합합니다. 제출과 상태 조회는 Apple Notary API로 분리할 수 있지만, 그 사실만으로 전체 배포 과정이 Linux에서 완성되는 것은 아닙니다.
원격 Mac은 자동 서명과 공증 파이프라인에 어떻게 연결하나요?
범용 CI가 작업을 시작하고, 서명 전 산출물을 원격 Mac에 전달한 뒤, Mac에서 서명·패키징·검증을 수행하도록 역할을 나눕니다. 공증 제출은 Mac에서 notarytool로 처리하거나, 범용 CI가 Apple Notary API를 호출하도록 선택합니다. 어느 쪽이든 비밀값을 일반 로그와 작업 파일에 남기지 않고, 작업이 끝난 뒤 임시 파일을 삭제해야 합니다.
실행 전에는 다음 순서로 시험합니다.
아래 점수는 제품 성능 점수가 아니라 운영 적합성 판단을 위한 내부 평가 기준입니다. 실제 선택은 저장소 구조, 인증 정책, 빌드 빈도, 물리 장치 필요 여부를 함께 확인해야 합니다.
| 조건 | 권장 구조 | 강점 | 주의점 | 운영 적합성 |
|---|---|---|---|---|
| 제출 파일이 이미 준비되고 조회만 필요함 | 범용 CI + Apple Notary API | Linux 중심 운영과 잘 맞음 | 티켓 처리와 최종 검증을 별도로 확보해야 함 | 4 / 5 |
| Xcode 빌드와 Developer ID 서명이 필요함 | 범용 CI + 전용 원격 Mac | macOS 전용 도구와 키체인을 격리하기 쉬움 | Mac 재시작과 비밀값 복구 시험이 필요함 | 5 / 5 |
| 패키징과 티켓 처리를 자주 수행함 | 원격 Mac 중심 CI | 전체 전달 경로를 한 환경에서 검증 가능 | Mac 노드 장애가 배포를 막을 수 있음 | 4 / 5 |
| 가끔 릴리스하고 Mac 전용 작업이 적음 | 필요할 때 연결하는 Mac 노드 | 상시 노드 운영을 줄일 수 있음 | 릴리스 직전 환경 준비 시간이 필요함 | 3 / 5 |
| 장시간 안정적인 빌드와 물리 장치가 필요함 | 자체 Mac 또는 전용 장비 | 장치 접근과 장기 튜닝에 유리함 | 구매, 유지 보수, 장애 대응을 직접 맡아야 함 | 4 / 5 |
결정 조건은 다음처럼 단순화할 수 있습니다.
Linux CI가 이미 중심이라면 원격 Mac 개발 환경을 임시 릴리스 노드로 연결해 실제 산출물로 시험할 수 있습니다. 한국에서 접근하는 팀은 한국 원격 Mac 구성도 함께 비교하되, 위치보다 인증 격리와 복구 시험 결과를 우선해야 합니다.
macOS 앱 공증에 맥이 필요한가라는 질문의 답은 작업 범위에 달려 있습니다. 제출과 조회만 분리하면 Linux CI와 Apple Notary API를 사용할 수 있지만, 빌드·서명·티켓 처리·최종 검증까지 포함한 배포라면 실제 Mac이 필요합니다. Linux 전용 서버는 Mac 전용 도구 체인과 키체인을 제공하지 못하고, 가상 환경은 그래픽 세션이나 서명 자격 증명 관리에서 별도 검증 부담을 만들 수 있습니다. 반면 VNCMac의 원격 Mac을 먼저 격리된 릴리스 노드로 임대하면 장비 구매 없이 실제 산출물의 서명부터 복구 시험까지 확인할 수 있습니다. 장기 고정 부하나 물리 장치가 필요하지 않다면, 먼저 짧은 검증 주기로 전체 흐름을 닫아 본 뒤 장기 임대 여부를 결정하는 편이 기술적으로 안전합니다.