애플은 macOS 공증 흐름을 제출, 결과 확인, 티켓 부착과 검증으로 나눠 안내합니다. 공증 절차의 공식 설명을 기준으로 보면, 성공 메시지 하나만으로 게시를 승인해서는 안 됩니다.
문제: Claude Code가 작업 완료라고 답해도 서명이나 공증의 증거가 되지는 않습니다.
빠른 해결: 클라우드 맥에서 실제 명령 출력과 산출물을 확인하고, 담당자가 최종 게시를 승인하세요.
이 글은 macOS 앱 릴리스를 준비하는 독립 개발자, Claude Code가 포함된 파이프라인을 감사하려는 릴리스 담당자, 원격 서명 환경의 접근 권한을 관리하는 플랫폼 관리자에게 적합합니다.
배포 채널부터 나눠 승인 기준을 정합니다
먼저 앱 스토어 배포인지, Apple Developer ID를 사용한 웹 등 외부 배포인지 결정하세요. 두 배포 유형은 서명과 전달 과정이 다르므로 같은 릴리스 절차로 취급하면 안 됩니다. 앱 스토어용 빌드는 애플의 빌드 업로드 안내를 따르고, 외부 배포는 맥 배포용 코드 서명 문서와 공증 요구 사항을 확인하세요.
Claude Code는 명령 실행을 도울 수 있지만 다음 판단을 대신하지 않습니다.
- 어떤 서명 신원을 쓸지 결정하고 승인합니다.
- 자격 증명을 제공할 환경과 접근 범위를 정합니다.
- 최종 산출물이 승인된 버전인지 확인한 뒤 게시합니다.
이 경계를 먼저 정해 두면 에이전트의 실행 권한과 릴리스 승인 권한을 분리할 수 있습니다. Claude Code의 명령 실행 및 권한 옵션을 살펴보고, 실제 권한 설정이 조직의 배포 정책과 맞는지 검토하세요.
개발 빌드에서는 재현 가능한 산출물을 남깁니다
서명 작업에 앞서 프로젝트의 빌드 방식을 문서화하세요. Xcode 프로젝트인지 외부 빌드 시스템인지, 의존성은 어떻게 고정하는지, 목표 아키텍처와 배포용 산출물 경로는 무엇인지 확인해야 합니다. 이 정보가 모호하면 에이전트가 성공했다고 보고해도 다른 설정으로 만든 결과일 수 있습니다.
- 배포 채널과 버전 식별자를 확정합니다.
- 빌드 도구와 의존성 버전을 확인하고 승인된 설정으로 빌드합니다.
- 생성된 앱 또는 보관 파일이 예상 경로에 있는지 확인합니다.
- 명령 출력과 산출물의 이름, 버전을 기록합니다.
- 서명 단계에 넘길 파일이 승인한 빌드 결과와 같은지 대조합니다.
빌드 로그에는 실행한 명령과 종료 결과를 남기세요. Claude Code의 자연어 설명은 참고 자료일 뿐, 빌드 성공의 증거가 아닙니다. 맥 앱 패키징에 관한 애플 문서를 함께 확인해 배포 대상에 맞는 패키지 형태인지 검토하세요.
중간 점검표로 실행 환경을 선택합니다
서명 자격 증명이 필요한 작업은 접근 권한을 제한하고 작업 뒤 정리할 수 있는 macOS 환경에서 수행하세요. 자격 증명을 코드 저장소나 프롬프트에 직접 넣거나 오래 남는 작업 디렉터리에 보관하면, 로그나 후속 작업을 통해 값이 노출될 위험이 커집니다. 애플의 사용자화된 공증 흐름 안내를 참고해 사용하는 도구와 인증 방식을 정하고, 최소 권한 원칙을 적용하세요.
| 방식 | 적합한 상황 | 주요 확인 사항 | 게시 판단 |
|---|---|---|---|
| 개발자 개인 맥 | 담당자가 장비와 키체인을 직접 관리할 수 있는 경우 | 개인 장비의 접근 권한, 작업 기록, 자격 증명 잔류 여부 | 산출물과 로그를 별도로 보관하고 승인 |
| 권한이 제한된 클라우드 맥 | 원격 릴리스 실행과 작업별 격리가 필요한 경우 | 누가 환경에 접근하는지, 비밀 정보가 로그나 디스크에 남는지, 종료 후 정리되는지 | 격리와 정리 결과까지 확인한 뒤 승인 |
| 앱 스토어 제출 흐름 | 앱 스토어를 통해 배포하는 경우 | 업로드 대상, 서명된 빌드, 스토어의 처리 상태 | Developer ID 공증 흐름과 혼용하지 않음 |
어떤 방식을 택하든 실제 빌드와 서명 작업을 같은 환경에서 재현할 수 있는지 확인하세요. 원격 환경 준비가 필요하다면 Kvmkit의 맥 지원 안내에서 사용 전에 확인할 항목을 살펴보고, 필요한 대여 방식은 한국 맥 미니 대여 안내에서 검토할 수 있습니다. 구체적인 제공 구성이나 비용은 실제 안내 페이지를 기준으로 판단하세요.
서명 검증은 앱과 안쪽 실행 파일까지 확인합니다
공증을 요청하기 전에 서명 대상이 맞는지, 앱 안에 포함된 실행 파일이나 구성 요소의 서명이 유효한지 확인하세요. 배포용 서명과 Hardened Runtime 요구 사항은 대상과 빌드 설정에 따라 검토해야 합니다. 관련 기준은 애플의 Hardened Runtime 안내에서 확인하세요.
대표적으로 다음과 같은 검사를 수행하고, 실제 출력과 실행 코드를 릴리스 기록에 남길 수 있습니다.
codesign --verify --deep --strict --verbose=2 "/경로/앱.app"
codesign -dv --verbose=4 "/경로/앱.app"
검증 오류가 나오면 경고를 무시하고 공증으로 넘어가지 마세요. 앱 번들 내부의 어떤 파일에서 실패했는지 확인한 다음, 빌드 설정이나 서명 대상을 바로잡아 다시 검사해야 합니다. 서명 신원이 예상한 배포 유형과 일치하는지도 담당자가 확인합니다.
서명에 성공한 앱과 공증이 끝난 앱은 같은 상태가 아닙니다. 서명 검증 결과, 공증 요청의 최종 상태, 티켓 검증 결과를 각각 보관하세요.
공증 완료 뒤 배포 파일에 티켓을 확인합니다
공증 요청을 제출한 뒤에는 결과를 조회하고, 실패했다면 공증 로그에서 문제 항목을 찾으세요. 승인 결과를 받으면 대상 산출물에 티켓을 부착하고 검증해야 합니다. Apple의 공증 사용자화 문서는 이 흐름에서 사용하는 도구와 처리 방식을 확인하는 기준입니다.
예를 들어 notarytool로 제출한 뒤 결과를 기다리는 명령 형태는 다음과 같습니다. 실제 입력 파일과 인증 정보 전달 방식은 사용 중인 애플 도구의 현재 문서를 기준으로 확인하세요.
xcrun notarytool submit "/경로/배포파일.zip" --keychain-profile "프로필이름" --wait
승인 후에는 대상 파일에 티켓을 부착하고 결과를 검사합니다.
xcrun stapler staple "/경로/앱.app"
xcrun stapler validate "/경로/앱.app"
공증 제출이 접수됐다는 응답, 공증이 승인된 결과, 최종 산출물에서 티켓이 검증되는 상태는 각각 별도로 확인해야 합니다. 실패 시 요청 식별 정보와 로그를 보관하고, 승인되지 않은 파일을 배포 경로에 올리지 마세요. 압축 파일 등으로 최종 전달물을 만들었다면, 실제로 배포할 파일과 공증을 확인한 파일이 같은지 다시 대조하세요.
게시 전 권한과 산출물의 흔적을 정리합니다
게시 직전에는 산출물의 출처와 버전, 서명 신원, 공증 상태, 담당자의 승인 기록을 한 묶음으로 확인하세요. 실행이 끝난 뒤에는 임시 키체인, 프로필, 환경 변수, 작업 파일에 비밀 정보가 남지 않았는지 점검합니다. 필요하면 해당 자격 증명을 회수하거나 교체하세요.
다음 중 하나라도 확인되지 않으면 게시를 보류하세요.
- 산출물이 승인된 빌드와 버전에 해당합니다.
- 앱과 포함된 실행 파일의 서명 검사가 통과했습니다.
- 공증 결과와 최종 배포 파일의 티켓 검증을 확인했습니다.
- 자격 증명의 접근 기록과 작업 후 정리 상태를 확인했습니다.
- 책임자가 결과를 검토하고 게시를 승인했습니다.
개인 맥에서 직접 처리하면 장비 관리와 반복 작업이 부담이 될 수 있고, 여러 작업자가 공유하는 빌드 환경은 권한 분리와 정리 상태를 놓치기 쉽습니다. 서명 키가 오래 남는 구조라면 노출 위험도 커집니다. 반면 클라우드 맥은 원격 실행 환경을 작업 단위로 관리하는 선택지가 될 수 있지만, 격리와 정리 여부를 확인하지 않으면 위험을 없애 주지는 않습니다. 테스트 프로젝트로 실제 명령과 로그를 먼저 검증한 뒤, 임시 릴리스 환경이 필요하다면 Kvmkit의 맥 대여를 검토하세요. 상시로 반복되는 무거운 작업이나 물리 장비 연결이 필요한 경우에는 직접 보유한 맥이 더 적합할 수 있습니다.
자주 묻는 질문
Claude Code에 앱 서명을 맡겨도 되나요?
명령 실행을 보조하게 할 수는 있지만, 서명 신원 선택과 자격 증명 사용 권한은 책임자가 확인해야 합니다. 서명 검증 명령의 실제 출력과 서명 대상을 점검하고, 자연어로 완료했다고 알리는 것만으로는 통과 처리하지 마세요. 게시 여부도 승인된 담당자가 결정해야 합니다.
클라우드 맥의 서명 자격 증명은 어떻게 보호하나요?
저장소와 프롬프트, 장기간 보존되는 작업 폴더에 비밀 정보를 남기지 마세요. 접근 권한을 제한해 필요한 작업에서만 사용하고, 명령 출력과 로그에 값이 노출되는지 확인하세요. 작업이 끝나면 임시 인증 정보와 파일이 남았는지 점검하고, 정책에 따라 폐기하거나 교체하세요.
macOS 공증 성공 후 무엇을 확인하나요?
요청이 승인됐는지 확인하고 공증 로그를 살펴본 뒤, 배포할 산출물에 티켓을 부착해 검증하세요. 앱 서명 상태와 최종 패키지가 검증한 빌드와 일치하는지도 대조해야 합니다. 명령 출력, 요청 결과, 버전 정보를 함께 보관하면 승인 근거를 다시 확인하기 쉽습니다.
서명과 공증, 최종 패키징은 어떤 순서로 진행하나요?
배포 유형을 먼저 결정하고 앱을 빌드한 다음 서명을 검증하세요. 그 후 공증을 제출해 승인 결과를 확인하고, 대상에 티켓을 부착해 검증한 뒤 실제 배포 패키지를 점검합니다. 앱 스토어 배포는 Developer ID 기반 외부 배포와 절차가 다르므로 한 흐름으로 섞지 마세요.
자주 묻는 질문
Claude Code가 앱 서명과 공증까지 알아서 처리하게 해도 되나요?
명령 실행을 보조하도록 맡길 수는 있지만, 자동으로 자격 증명을 승인하거나 게시 성공을 보장한다고 간주해서는 안 됩니다. 사용할 서명 신원, 비밀 정보 접근 권한, 배포 대상은 담당자가 먼저 확인해야 합니다. 작업 뒤에는 실제 서명 검사와 공증 결과, 배포 파일 검증을 수행하고 그 근거를 확인한 후에만 게시를 승인하세요.
클라우드 맥에서 서명 키와 비밀번호는 어디에 보관해야 하나요?
저장소, 프롬프트, 장기간 남는 작업 폴더에 비밀 정보를 기록하지 마세요. 접근 권한을 제한한 비밀 정보 관리 방식으로 필요한 작업에만 제공하고, 실행 환경과 로그에 값이 노출되지 않는지 확인해야 합니다. 임시 키체인을 쓰는 경우에도 작업 뒤 인증 정보와 임시 파일이 남았는지 점검하고, 필요하면 자격 증명을 폐기하거나 교체하세요.
공증이 완료됐다는 메시지 뒤에 무엇을 더 확인해야 하나요?
제출이 완료됐다는 응답만으로 배포 준비가 끝난 것은 아닙니다. 공증 요청의 최종 상태와 실패 로그를 확인하고, 배포할 파일에 티켓을 부착한 뒤 검증해야 합니다. 앱 서명 상태와 최종 배포 패키지도 다시 검사하세요. 확인한 명령 출력과 산출물 버전을 함께 보관하면 게시 승인 과정에서 어떤 파일을 검토했는지 추적할 수 있습니다.
앱 서명, 공증, 최종 패키징은 어떤 순서로 해야 하나요?
배포용 앱을 먼저 빌드하고 서명 상태를 확인한 다음 공증을 제출하세요. 공증 결과가 승인되면 해당 산출물에 티켓을 부착하고 검증한 뒤, 실제로 배포할 패키지를 검사합니다. 앱 스토어 제출은 Developer ID 공증 배포와 다른 흐름이므로 먼저 배포 채널을 정해야 합니다. 어떤 흐름이든 최종 파일과 승인 기록을 대조한 후 게시하세요.
M4 Mac mini에서 CI/CD를 돌리면 진짜 편합니다
Xcode, Fastlane, CocoaPods, and SPM are first-class on macOS. Mac mini M4 unified memory keeps signing and archiving smooth; ~4W standby power suits 24/7 build nodes.