macOS 27 맥 앱 공증 전 어떻게 검수할까? 2026 체크리스트

macOS 27은 Apple silicon 맥만 지원한다고 Apple이 안내합니다. macOS 27 출시 정보를 기준으로 보면, 직접 배포 앱은 Developer ID 서명과 공증뿐 아니라 최종 전달물의 일치 여부, 대상 환경에서의 실행까지 확인해야 합니다. Mac App Store 배포에는 같은 직접 배포 공증 절차를 적용하지 않습니다. 격리된 빌드에서 검수를 끝낸 뒤, 통과한 절차만 정식 출시 과정에 반영하세요.

이 글은 맥 앱을 직접 배포하며 서명과 공증을 점검하려는 독립 개발자, DMG나 PKG를 배포하는 소규모 팀을 위한 안내입니다.
개발 환경을 고정할 원격 맥을 검토하는 개발자도 배포 경로별 차이를 확인할 수 있습니다.

마지막 업데이트: 2026년 11월 6일. Apple의 공증 안내, notarytool 작업 흐름 문서, macOS 27 출시 정보를 기준으로 확인했습니다.

먼저 구분할 배포 경로와 검수 대상

Apple은 Mac App Store 외부로 배포하는 macOS 앱에 공증 절차를 안내합니다. 직접 배포에서는 서명과 Hardened Runtime 설정, 실제 제출물의 공증 상태를 확인해야 합니다. 반면 Mac App Store 배포는 스토어 제출과 심사 경로를 따릅니다. Apple의 macOS 소프트웨어 공증 안내와 앱 배포 경로 설명을 기준으로 두 흐름을 나누세요.

이 표는 Apple의 요구사항을 대신하는 규정표가 아니라, 검수 대상을 빠뜨리지 않기 위한 프로젝트용 구분입니다. 공증 결과가 승인됐다는 사실과 사용자가 앱을 문제없이 실행할 수 있다는 사실은 별도로 기록해야 합니다.

직접 배포라면 어떤 증거를 남겨야 하나요?

Apple은 직접 배포용 앱에서 코드 서명과 Hardened Runtime 등 공증에 필요한 조건을 안내합니다. Hardened Runtime 설명과 코드 서명 서비스 문서를 보고 앱의 서명 설정을 확인하세요. 특정 권한을 예외로 허용했다면 해당 권한이 필요한 이유와 설정값도 남겨야 합니다.

공증 검수의 핵심은 상태 문구 하나가 아니라, 제출한 빌드와 배포 파일 사이의 연결을 증명하는 것입니다. 다음 증거를 한 묶음으로 보관하면 출시 뒤 같은 결과를 재현하기 쉽습니다.

• 빌드 식별 정보와 사용한 Xcode 및 도구 환경
• 서명 주체와 앱의 서명 상태
• notarytool 제출 결과와 해당 제출의 로그
• DMG 또는 PKG를 사용했다면 최종 파일의 검증 결과
• 대상 macOS 환경에서 설치·마운트한 뒤 실행한 결과

Apple은 공증 작업 흐름을 구성하는 방법도 설명합니다. 명령의 사용 조건은 해당 문서와 현재 도구 설명에 맞춰 확인하세요. 다른 빌드로 다시 패키징했거나 전달 파일을 바꿨다면 이전 검수 기록을 새 파일의 증거로 간주하지 않는 편이 안전합니다.

DMG와 PKG에서는 무엇이 달라지나요?

DMG: 내려받는 이미지와 이미지 안의 앱을 함께 확인합니다

DMG로 전달한다면 공증을 요청한 대상이 사용자가 내려받을 이미지와 일치하는지 확인하세요. 이미지 안의 앱만 검수하고 DMG 자체의 검증을 생략하면, 실제 배포 파일을 승인된 결과와 연결하기 어렵습니다. Apple의 Mac 소프트웨어 패키징 지침에 따라 선택한 제출 대상과 티켓 처리 결과를 확인합니다.

검수 기록에는 파일 식별 정보, 공증 상태, 티켓 검증 결과를 남기세요. 이어서 별도 검수 환경에서 DMG를 마운트하고 앱을 실행합니다. 마운트 후 앱이 열리지 않거나 예상한 앱과 다르면 출시를 보류하고, 최종 이미지에 들어간 앱이 검수한 빌드인지 먼저 대조해야 합니다.

PKG: 설치 패키지와 설치 결과를 나눠 기록합니다

PKG는 설치 파일 자체와 설치 후 앱을 각각 확인해야 합니다. 패키지에 대한 서명·공증 상태가 정상이어도 설치 경로나 설치된 앱의 상태까지 자동으로 입증되는 것은 아닙니다. Apple의 공증 지침과 패키징 설명을 따라 실제 제출 대상을 확인하고, 설치를 마친 뒤 앱 서명과 실행 결과를 별도 항목으로 남기세요.

프로젝트 기록에는 제출한 PKG, 설치 결과, 설치 위치, 설치된 앱의 검증 상태를 연결해 보관합니다. DMG용 검수 절차를 PKG에 그대로 적용하면 설치 단계가 누락될 수 있습니다.

조건에 맞춰 다음 검수 경로를 선택합니다

아래 조건에서 하나를 골라 진행하세요. 조건에 맞지 않는 경로의 검수 결과를 대신 사용하지 않는 것이 기준입니다.

• Mac App Store로 배포한다면 직접 배포용 Developer ID 공증 흐름 대신 스토어 제출물, 심사 상태, 공개 버전의 일치 여부를 확인합니다.
• 사용자가 DMG를 받는다면 최종 DMG의 공증 결과와 티켓을 확인한 뒤 마운트해 앱을 실행합니다. 이미지 안의 앱만 확인한 상태라면 이미지 검수를 추가합니다.
• 사용자가 PKG를 받는다면 패키지 서명과 공증을 확인한 후 실제 설치 경로의 앱 서명과 실행을 검수합니다.
• 직접 배포 앱을 단독 전달한다면 최종 앱 번들의 서명과 공증 상태를 확인하고, 공증에 사용한 빌드와 배포 빌드가 같은지 대조합니다.
• macOS 27 지원을 표방한다면 Apple silicon 기반 대상 환경에서 실행을 확인하고 결과를 기록합니다. 공증 승인만으로 운영체제 호환성을 판정하지 않습니다.

자주 묻는 배포 전 확인 사항

이 지점에서 검수 범위가 자주 혼동됩니다. 특히 공증 성공, 파일 형식, 스토어 제출, 원격 실행은 서로 다른 판단 항목입니다. 아래 답변은 각 경우에 필요한 확인 자료를 구분합니다.

원격 맥에서 반복 검수할 때는 어떻게 이어가나요?

원격 맥은 고정된 빌드·서명 환경을 유지해야 하는 팀에 유용할 수 있습니다. 반복 작업에서는 절차를 고정하는 것만큼 인증 정보의 권한 관리와 결과 기록도 중요합니다. Apple의 Xcode 아카이브 작업 흐름 설명을 참고해 빌드 산출물과 이후 검수 단계를 연결하세요.

단계별 출시 전 진행

1. 격리된 빌드 환경을 준비합니다. 대상 운영체제와 기기 구조를 정하고, 사용한 Xcode 및 서명 자산을 기록합니다.
2. 배포 경로를 먼저 고릅니다. 직접 배포, DMG, PKG, Mac App Store 중 하나로 분류하고 그 경로에 필요한 검수 대상을 정합니다.
3. 서명과 Hardened Runtime을 확인합니다. 서명 주체, 앱 설정, 필요한 권한을 기록합니다. 직접 배포가 아니라면 Developer ID 절차를 무조건 덧붙이지 않습니다.
4. 최종 전달물을 기준으로 공증을 확인합니다. notarytool 결과와 로그를 보관하고 제출물과 출시 파일이 같은 빌드인지 대조합니다.
5. 파일 형식에 맞게 티켓과 설치를 검증합니다. DMG는 마운트 후 실행하고, PKG는 설치 후 앱을 확인합니다.
6. 대상 macOS 27 환경에서 앱을 실행합니다. 지원 환경, 대상 구조, 실행 여부를 공증 결과와 분리해 기록합니다.
7. 정식 출시 절차를 갱신합니다. 검수가 통과한 빌드와 절차를 기준으로 출시하고, 파일이 바뀌면 해당 전달물을 다시 검수합니다.

원격 맥을 쓸 때도 사용자 환경 검수는 생략할 수 없습니다. 반복 빌드와 제출을 같은 환경에서 수행할 수 있어도, 그 환경에서의 성공만으로 실제 사용자의 설치·실행 결과가 보장되지는 않습니다. 출시 담당자는 빌드 기록과 제출 결과를 함께 보관하고, 문제가 생겼을 때 어느 단계에서 결과가 달라졌는지 추적할 수 있어야 합니다.

고정된 macOS 환경이 필요하지만 실물 맥을 따로 마련하기 어렵다면 OrbVPS의 한국 원격 맥 환경을 검토할 수 있습니다. 다만 장기간 안정적으로 무거운 작업을 계속하거나 물리 포트와 주변 장치가 필요한 경우에는 직접 보유한 맥이 더 적합할 수 있습니다. 사용 기간과 인증 정보 관리 방식은 서비스 이용 안내에서 먼저 확인하세요.

검수 기록이 분산된 로컬 환경은 빌드마다 도구 상태가 달라질 수 있고, 개발용 맥에 배포 키를 함께 보관하면 접근 권한 관리가 복잡해지며, 공용 빌드 환경은 결과 재현과 책임 추적이 어려울 수 있습니다. 이런 조건에서 정기적인 서명·공증 검수를 반복한다면, OrbVPS의 원격 맥을 고정된 작업 환경으로 쓰는 방안이 대안이 됩니다. 우선 프로젝트가 요구하는 운영체제, 키 접근 정책, 실제 사용자 환경 검수 범위를 정한 뒤 선택하세요.

자주 묻는 질문