이번 주에는 먼저 배포 단계를 나누세요. 공증 제출과 상태 조회만 Windows나 Linux에서 처리하려면 Notary API를 검토할 수 있지만, 전체 macOS 앱 배포를 Mac 없이 끝내려는 목적이라면 부족합니다. 이미 Xcode와 Mac을 쓰고 있다면 notarytool을 우선 유지하고, 실제로 교차 플랫폼 제출이 필요한 경우에만 API 통합을 평가하세요.
이 글은 macOS 앱을 사이트 외부에서 배포하며 공증을 관리하는 독립 개발자, 비Mac 환경에서 공증 제출을 맡길 수 있는지 확인하는 개발자, 서명 자격 증명과 배포 검수를 책임지는 소규모 팀을 위한 내용입니다.
SECTION 01 Xcode 공증에서 Mac이 필요한 구간
핵심은 공증 서비스와 통신하는 일과 앱을 배포 가능한 상태로 만드는 일을 구분하는 것입니다. Apple은 공증 서비스와 상호작용하는 방법으로 notarytool과 Notary API를 안내하며, API를 사용하면 공증 상호작용 자체는 macOS에 의존하지 않을 수 있습니다. 하지만 이 경계는 빌드, 서명, 티켓 첨부까지 자동으로 비Mac 환경으로 옮겨 준다는 뜻이 아닙니다. Notary API 개요
| 배포 책임 | notarytool 중심 | Notary API 중심 |
|---|---|---|
| 공증 제출과 결과 확인 | Mac의 명령줄 흐름에서 실행 | HTTP 요청으로 서비스와 상호작용 |
| 빌드와 코드 서명 | 별도 Xcode 및 macOS 작업 | API가 제공하지 않으므로 별도 처리 |
| 제출 상태와 로그 확인 | 도구를 통해 확인 | API 요청으로 조회 |
| 티켓 첨부와 전달 파일 검수 | 적절한 macOS 도구로 별도 확인 | API가 자동으로 처리하지 않으므로 별도 확인 |
| 인증 관리 | 기존 도구와 파이프라인의 자격 증명 관리 | JWT 서명 키와 업로드 자격 증명을 안전하게 관리 |
Apple의 Notary API 제출 절차는 제출 요청, 파일 업로드, 상태 확인이 별도 상호작용임을 설명합니다. 따라서 API를 선택하는 기준은 “Mac을 없앨 수 있는가”가 아니라 “공증 서비스와 대화하는 구간을 현재 파이프라인으로 옮길 필요가 있는가”입니다.
SECTION 02 기존 Mac과 Xcode를 쓰는 개발자
이미 Xcode에서 빌드와 서명을 수행하고 있다면, notarytool을 현재 배포 흐름에 연결하는 편이 관리 지점이 적습니다. Apple은 Xcode 명령줄 도구와 공증을 위한 사용자 지정 작업 흐름을 안내합니다. 외부 API 호출과 토큰 발급, 재시도 처리를 새로 구현하기 전에 현재 Mac 기반 절차가 필요한 요구를 충족하는지 먼저 확인하세요. Xcode 명령줄 도구 설치 안내와 사용자 지정 공증 작업 흐름 안내를 참고할 수 있습니다.
notarytool을 고수하는 것이 항상 정답은 아닙니다. 여러 운영체제에 걸친 배포 서버에서 제출과 결과 조회를 통합해야 하거나, 공증 상태를 기존 배포 대시보드에 모아야 한다면 Notary API의 이점을 따져볼 만합니다. 다만 API를 도입해도 Xcode 빌드와 서명 단계까지 그 서버가 대신할 것으로 기대해서는 안 됩니다.
판단은 아래 조건으로 나누면 명확합니다.
- 빌드, 서명, 공증 제출이 모두 Mac에 있고 현재 흐름이 안정적이라면 notarytool을 우선 사용하세요.
- 제출과 상태 조회를 Windows 또는 Linux 파이프라인에서 해야 하는 요구가 분명하다면 Notary API를 평가하세요.
- 앱 빌드와 서명까지 비Mac 환경에서 끝내려는 계획이라면 API 선택만으로 해결된다고 보지 말고 해당 작업을 수행할 환경부터 검증하세요.
- API 인증 키를 안전하게 보관하고 업로드 요청을 관리할 운영 책임자가 없다면 기존 Mac 기반 흐름을 유지하거나 책임 체계를 먼저 정하세요.
SECTION 03 Windows와 Linux 배포 파이프라인 담당자
Notary API는 공증 서비스의 제출과 결과 확인을 비Mac 파이프라인에 포함하는 데 적합할 수 있습니다. 그러나 API는 Mac 빌드 서버가 아닙니다. Apple의 macOS 앱 배포 준비 안내는 배포 준비와 서명 작업을 다룹니다. API를 붙였다는 사실만으로 앱을 빌드하고 서명하는 작업까지 비Mac에서 가능하다고 결론 내릴 수는 없습니다.
책임을 나누면 운영 구조가 더 분명해집니다. 빌드와 서명은 현재 사용할 수 있는 개발 환경에서 수행하고, 서명된 결과물을 공증 서비스에 보내는 구간만 기존 Windows 또는 Linux 파이프라인에 맡길 수 있습니다. 승인 여부를 확인한 뒤에는 배포용 산출물에 필요한 후속 처리를 별도로 수행해야 합니다.
API 흐름에는 인증 책임도 따라옵니다. Apple의 Notary API 안내에 따르면 요청은 JWT 기반 인증을 사용하며, 제출 과정에서는 업로드를 위한 자격 증명도 다뤄야 합니다. 서명 키를 파이프라인 설정이나 저장소에 평문으로 남기지 말고, 로그에 재사용 가능한 토큰이나 업로드 정보를 기록하지 않도록 점검하세요. 자격 증명의 생성, 저장, 접근 권한, 폐기 절차를 운영 문서에 포함해야 합니다. Notary API 인증 및 작업 안내
SECTION 04 외부 빌드 시스템을 쓰는 팀
외부 빌드 시스템에서 macOS 소프트웨어를 만들고, 릴리스 담당자가 공증 제출을 현재 배포 파이프라인에 포함하려는 경우에는 교체 범위를 좁혀 비교하세요. notarytool은 Mac에서 명령줄 작업으로 연결하기 쉽고, Notary API는 HTTP 요청을 처리할 수 있는 파이프라인에 공증 상호작용을 통합할 여지를 줍니다. 두 방식 모두 제출 파일의 유효성이나 빌드 시스템의 품질을 대신 보증하는 것은 아닙니다.
notarytool에서 API로 옮기기 전에는 다음을 실제 산출물로 확인하세요.
- 파이프라인이 공증 대상으로 보낼 파일을 일관되게 생성하는지 확인합니다.
- 서명 결과와 공증 제출 파일이 같은 릴리스 산출물인지 식별할 수 있게 합니다.
- API 요청의 인증 정보가 제한된 실행 환경에서만 접근되는지 검토합니다.
- 제출 뒤 상태와 로그를 릴리스 기록에 연결할 수 있는지 시험합니다.
- 승인된 산출물에 필요한 티켓 첨부와 최종 검수를 별도 작업으로 남깁니다.
이 검토에서 가장 중요한 것은 “제출이 성공했는가”와 “사용자에게 전달할 파일이 준비됐는가”를 다른 완료 조건으로 두는 것입니다.
SECTION 05 티켓 첨부와 최종 전달 검수
공증 상태가 승인으로 바뀌어도 배포 검수가 자동 완료되지는 않습니다. 앱을 어떻게 전달하는지에 따라 티켓 첨부가 필요한지 확인하고, 해당되는 경우 macOS 도구로 처리한 뒤 실제 배포 파일을 대상으로 검증하세요. Apple의 공증 문제 해결 안내는 제출 결과와 공증 문제를 확인할 때 로그를 살펴보도록 안내합니다. 상태만 저장하지 말고 실패 원인을 추적할 수 있도록 로그와 산출물 식별 정보를 함께 관리하세요.
검수 대상은 파이프라인에서 공증 서비스로 보낸 임시 파일이 아니라 사용자에게 전달할 최종 파일이어야 합니다. 릴리스 작업의 완료 조건에 서명 확인, 공증 결과 확인, 필요한 티켓 첨부, 전달 파일 검증을 각각 기록하면 제출 성공을 최종 승인으로 오해할 가능성이 줄어듭니다.
SECTION 06 자주 묻는 질문
notarytool을 Windows나 Linux에서 바로 실행할 수 있나요?
notarytool은 Xcode와 macOS 명령줄 도구를 사용하는 공증 흐름에 맞춰진 도구입니다. 따라서 Windows나 Linux에서 같은 명령을 그대로 실행하는 방식으로 계획하지 않는 편이 안전합니다. 비Mac 시스템에서 제출과 상태 확인만 맡기려면 Notary API를 검토하고, 빌드나 서명까지 필요하다면 그 작업에 맞는 Mac 환경을 별도로 고려하세요.
Notary API가 macOS 앱 공증 전체를 대신하나요?
아닙니다. API가 맡는 것은 공증 서비스와의 상호작용입니다. 빌드와 코드 서명, 승인 뒤 필요한 티켓 첨부와 최종 배포 검수까지 자동으로 대신하지 않습니다. 공증 제출을 비Mac 서버로 옮기더라도 릴리스 책임을 단계별로 나눠 관리해야 합니다.
Mac이 아닌 곳에서 공증을 제출해도 stapler 작업이 남나요?
티켓 첨부가 필요한 배포 흐름이라면 제출한 환경이 Mac이 아닌지와 무관하게 후속 첨부와 검수를 확인해야 합니다. Notary API의 제출 응답만으로 이 과정이 완료됐다고 판단하면 안 됩니다. 적절한 macOS 도구로 실제 전달 파일에 필요한 작업을 수행하고 결과를 검증하세요.
Xcode 배포 흐름에서 언제 Notary API를 검토해야 하나요?
현재 Mac 기반 Xcode 흐름이 빌드, 서명, 공증을 충분히 처리한다면 notarytool을 유지하는 편이 단순할 수 있습니다. 제출과 상태 조회를 비Mac 파이프라인에 통합해야 하는 구체적인 요구가 있을 때 API를 비교하세요. 이때 인증 키 보호와 업로드 자격 증명 관리까지 운영 가능한지도 함께 판단해야 합니다.
Windows나 Linux 중심의 현재 구성은 공증 제출을 다른 파이프라인에 붙일 수 있어도, Mac 전용 빌드·서명 도구나 티켓 첨부 단계가 필요할 때 별도 환경과 전달 절차를 추가해야 할 수 있습니다. 반대로 모든 일을 비Mac에서 처리하려고 API를 확대 해석하면 배포 마지막 단계에서 누락이 생길 수 있습니다. 빌드, 서명 또는 티켓 첨부처럼 macOS 도구가 필요한 구간을 원격 Mac에서 처리하는 방안을 함께 비교해 보세요. VPSNIX의 원격 Mac 이용 안내와 요금 및 이용 옵션를 살펴보면, 직접 Mac을 준비하는 방식과 필요한 기간에 원격 환경을 이용하는 방식 중 현재 릴리스 절차에 맞는 선택지를 평가할 수 있습니다.