Electron 44 macOS 패키징에 Mac이 필요할까? 2026 CI 방안

Electron 앱을 Windows에서 개발하고 macOS 대상 파일을 생성하는 것 자체는 프로젝트 구성에 따라 가능합니다. 그러나 생성된 파일이 곧 macOS 사용자가 설치할 수 있는 생산용 제품이라는 뜻은 아닙니다.

Electron 공식 배포 흐름은 다음처럼 나뉩니다.

• 패키징: 앱과 Electron 런타임, 리소스를 macOS용 번들로 묶습니다.
• 코드 서명: 개발자 인증서와 권한 설정으로 앱의 출처와 무결성을 증명합니다.
• 공증: Apple 공증 서비스에 제출하고 검사 결과를 받습니다.
• 티켓 장착: 승인된 공증 티켓을 설치 파일에 연결합니다.
• 설치 검증: 깨끗한 사용자 계정에서 Gatekeeper와 실행 권한을 확인합니다.
• 업데이트 검증: 서명된 이전 버전에서 새 버전으로 정상 업데이트되는지 확인합니다.

따라서 “Electron 앱을 Windows에서 macOS 설치 파일로 만들 수 있는가”라는 질문의 답은 파일 생성만 보면 조건부로 그렇습니다. 공개 배포와 자동 업데이트까지 포함하면 최종 단계에 실제 Mac이 필요하다고 판단해야 합니다.

Electron 44는 2026년 8월 25일 공개됐습니다. 버전 자체의 출시 사실은 Electron 44 출시 기록에서 확인할 수 있지만, 특정 프로젝트의 패키징 성공이나 공증 통과를 보장하는 자료는 아닙니다.

주의: CI 작업이 초록색이라는 이유만으로 배포물을 승인하지 않습니다. 서명 검증, 공증 결과, 티켓 상태, 깨끗한 계정 설치까지 별도 증거로 남겨야 합니다.

순수 JavaScript와 웹 리소스 중심의 앱은 다른 운영 체제에서 macOS용 패키지를 준비하기가 비교적 쉽습니다. 반면 Node 네이티브 모듈, 보조 실행 파일, 시스템 확장, 플랫폼별 리소스를 포함하면 대상 아키텍처와 빌드 환경이 달라집니다.

먼저 다음 항목을 확인합니다.

• 의존성이 darwin-arm64를 제공하는지 확인합니다.
• Intel 기반 darwin-x64 파일이 필요한지 확인합니다.
• 두 아키텍처를 포함한 범용 바이너리를 제공하는지 확인합니다.
• 설치 후 네이티브 모듈이 실제로 로드되는지 확인합니다.
• 패키지 매니저의 재빌드가 목표 아키텍처에서 실행됐는지 기록합니다.

Electron의 설치 문서도 운영 체제와 CPU 아키텍처를 구분합니다. Electron 플랫폼 및 아키텍처 안내를 기준으로 의존성의 지원 범위를 확인해야 합니다.

Windows에서 생성한 node_modules를 Mac 작업 공간에 그대로 복사하는 방식은 피해야 합니다. 네이티브 모듈이 포함된 경우 운영 체제와 아키텍처가 다른 바이너리를 전달할 수 있기 때문입니다. 원격 Mac의 첫 번째 역할은 다른 노드의 결과물을 단순히 복사하는 것이 아닙니다. 실제 목표 아키텍처에서 의존성을 새로 설치하고 다시 빌드하는 것입니다.

Electron Forge를 CI에 넣을 때 확인할 경계

Electron Forge는 패키징과 배포 과정을 연결하는 선택지입니다. 다만 Forge 설정이 macOS의 인증서, 키체인, 권한 파일, 공증 자격 증명을 대신 만들어 주는 것은 아닙니다.

Forge 빌드 생명 주기 문서를 기준으로 다음을 분리해 기록합니다.

1. 소스 커밋과 의존성 잠금 파일을 고정합니다.
2. 목표 아키텍처에 맞춰 의존성을 설치합니다.
3. Forge 패키징 작업을 실행합니다.
4. 서명 설정과 권한 파일을 적용합니다.
5. 공증 제출과 결과 대기를 실행합니다.
6. 티켓 장착 후 최종 파일을 검증합니다.

Electron Forge에서 notarization을 구성할 때도 공증 제출이 곧 완료를 의미하지 않습니다. 제출 식별자와 결과 상태를 확인한 뒤, 최종 산출물에 티켓이 연결됐는지 별도로 검사해야 합니다.

macOS 코드 서명은 인증서만 환경 변수에 넣는 작업이 아닙니다. Developer ID 인증서의 개인 키가 키체인에 있어야 하고, CI 실행 계정이 해당 키에 접근할 수 있어야 하며, 앱의 권한 설정도 서명 대상과 맞아야 합니다.

Electron 공식 코드 서명 안내와 Electron Forge macOS 서명 가이드를 함께 확인하면서 다음 요소를 분리합니다.

• Developer ID Application 인증서와 개인 키
• Hardened Runtime 설정
• entitlements 파일
• Bundle ID와 서명 대상
• 키체인 잠금 해제 상태
• CI 실행 계정의 접근 권한
• 서명 뒤 검증 명령과 원본 로그

@electron/osx-sign의 설정 타입 정의도 확인해야 합니다. 설정 이름만 보고 인증서가 자동으로 준비된다고 가정하면 안 됩니다.

원격 Mac에서 사용하는 계정은 일반 개발 계정과 분리하는 편이 좋습니다. 공용 로그인 계정에 개인 키를 넣거나, 모든 CI 작업이 같은 키체인을 공유하면 다른 작업이 서명 자격 증명에 접근할 수 있습니다. 키체인은 필요한 작업 시점에만 잠금 해제하고, 작업 종료 뒤 다시 잠그는 흐름을 설계합니다.

여기서 원격 Mac CI 키체인과 자격 증명 격리 안내를 함께 확인하면 계정 분리, 접근 범위, 재시작 뒤 복구 항목을 별도로 설계할 수 있습니다.

코드 서명이 끝난 앱도 공증이 끝난 것은 아닙니다. Apple 문서에 따르면 공증은 제출, 처리 결과 확인, 최종 배포물 검증으로 나누어야 합니다.

일반적인 흐름은 다음과 같습니다.

1. 서명된 앱 또는 설치 파일을 준비합니다.
2. 인증 정보, Team ID, Bundle ID를 자리 표시자로 관리합니다.
3. notarytool 또는 Apple의 공증 API에 제출합니다.
4. 제출 식별자를 저장합니다.
5. 처리 상태가 승인인지 실패인지 확인합니다.
6. 실패하면 원본 로그와 제출 결과를 보존합니다.
7. 승인된 파일에 티켓을 장착합니다.
8. 인터넷이 차단된 환경에서도 티켓과 서명이 검증되는지 확인합니다.

Apple의 macOS 소프트웨어 공증 안내와 공증 작업 흐름 문서는 제출 성공과 승인 결과를 구분합니다.

예시의 계정, 저장소, 호스트 이름, 경로, 인증서 이름은 실제 값을 넣지 않습니다. 다음처럼 자리 표시자를 유지합니다.

• 계정: <CI_ACCOUNT>
• Team ID: <TEAM_ID>
• Bundle ID: <BUNDLE_ID>
• 인증서: <DEVELOPER_ID_CERTIFICATE>
• 제출 식별자: <SUBMISSION_ID>
• 비밀 키 파일: <API_KEY_FILE>

실패한 공증 작업을 다시 실행하기 전에 이전 로그를 삭제하지 않습니다. 같은 소스와 같은 서명 대상에서 실패했는지 비교해야 원인이 자격 증명인지, 번들 구조인지, 권한 설정인지 구분할 수 있습니다.

경험상 가장 위험한 오해는 “업로드 성공 = 배포 가능”이라는 판단입니다. 공증 승인, 티켓 장착, 깨끗한 계정의 실행은 각각 별도의 승인 단계입니다.

Electron 44 macOS 패키징에서는 모든 작업을 Mac으로 옮기기보다 운영 체제별 책임을 나누는 방식이 적합합니다.

이 구조에서는 Windows 또는 Linux 노드가 lint와 단위 테스트를 빠르게 처리합니다. 원격 Mac은 고위험 자격 증명을 사용하는 짧은 릴리스 작업만 맡습니다. macOS 릴리스 노드가 모든 개발 작업에 사용되지 않으므로 대기열과 자격 증명 노출 범위도 줄어듭니다.

파이프라인 사이에는 소스 커밋, 잠금 파일, 입력 파일의 해시, 이전 작업의 산출물 해시를 전달합니다. Mac 노드에서 저장소를 다시 가져오면 다른 커밋이 들어올 수 있습니다. 릴리스 노드는 전달받은 고정 소스와 검증된 해시만 사용해야 합니다.

Electron macOS 릴리스 노드는 계속 켜져 있어야 합니까?

항상 켜져 있을 필요는 없습니다. 릴리스가 드물고 자격 증명 위험을 낮추는 것이 우선이면 작업이 있을 때만 사용하는 임시 Mac 노드가 적합합니다. 매일 여러 번 릴리스하거나 긴 테스트를 반복한다면 전용 노드가 대기 시간을 줄일 수 있습니다. 다만 전용 노드도 키체인 복구와 재부팅 검증을 자동화해야 합니다.

공유 Mac Runner는 비용과 관리 부담이 낮을 수 있지만, 다른 팀의 프로세스와 키체인이 섞이지 않는지 확인해야 합니다. 반대로 장기 전용 노드는 접근 통제와 패치 관리 책임이 커집니다. 개발 빈도보다 먼저 서명 자격 증명의 격리 수준과 실패 시 대체 경로를 결정해야 합니다.

결정 기준을 작업 방식에 맞추면 다음과 같습니다.

• 단기 원격 Mac: 처음 macOS 배포를 검증하거나 릴리스 빈도가 낮은 팀에 적합합니다.
• 장기 전용 Mac 노드: 반복 릴리스와 예약 작업이 많고, 팀이 키체인과 운영 체제 관리를 직접 맡을 수 있을 때 적합합니다.
• 로컬 Mac 구매: 물리 장치, 장시간 대화형 디버깅, 오프라인 개발이 중요할 때 적합합니다.
• 혼합 운영: 공통 테스트는 기존 노드에서 처리하고 macOS 릴리스만 Mac으로 보낼 때 적합합니다.

최종 선택 전에는 다음 체크리스트를 통과시킵니다.

• [ ] 깨끗한 작업 공간에서 전체 의존성을 새로 설치했습니다.
• [ ] darwin-arm64 또는 darwin-x64 목표를 확인했습니다.
• [ ] 네이티브 모듈을 실제 앱에서 로드했습니다.
• [ ] 서명 대상과 entitlements를 검증했습니다.
• [ ] 공증 제출 식별자와 원본 로그를 보관했습니다.
• [ ] 공증 승인 뒤 티켓 장착 상태를 확인했습니다.
• [ ] 깨끗한 사용자 계정에서 설치했습니다.
• [ ] Gatekeeper 경고와 첫 실행 결과를 기록했습니다.
• [ ] 이전 버전에서 새 버전으로 자동 업데이트했습니다.
• [ ] 재부팅 뒤 키체인, 빌드 계정, 상주 작업이 복구되는지 확인했습니다.
• [ ] 직전의 정상 배포물을 롤백용으로 보관했습니다.

이 검증에서 실패하면 Mac의 사양을 먼저 높이기보다 실패 단계부터 분류합니다. 패키징 실패는 의존성과 아키텍처 문제일 수 있습니다. 서명 실패는 키체인과 권한 문제일 수 있습니다. 공증 실패는 제출 자격 증명과 번들 구성 문제일 수 있습니다. 설치 실패는 티켓 장착과 사용자 환경 문제일 수 있습니다.

MESHLAUNCH의 Mac mini 임대 조건을 검토할 때도 가격만 비교하지 말고, 원격 접속 방식과 계정 분리, 재시작 뒤 복구 절차를 먼저 확인하는 편이 좋습니다. 실제 배포 노드를 구성하려면 원격 Mac CI용 재시작 복구 항목도 함께 점검해야 합니다.

현재 Windows 또는 Linux만 사용하는 팀이 직접 Mac을 구매하면 초기 장비 비용, 상시 전원 관리, 키체인 보안, 고장 시 대체 노드 운영을 모두 떠안게 됩니다. 반대로 기존 클라우드 Linux 노드만 유지하면 macOS 서명과 공증을 처리할 수 없고, 비공식 가상 환경은 목표 하드웨어와 설치 검증이 달라질 수 있습니다. 이런 경우 MESHLAUNCH의 원격 Mac을 짧은 기간 사용해 실제 Electron 44 릴리스를 끝까지 검증하는 편이 더 현실적입니다. 릴리스 빈도가 충분히 높아진 뒤에 전용 장비로 전환하면 구매 시점을 데이터로 판단할 수 있습니다.

이번 주에는 새 Mac 구매부터 시작하지 말고, 고정 커밋으로 임시 원격 Mac 릴리스 작업을 한 번 실행하는 것이 좋습니다. 깨끗한 작업 공간에서 설치, 패키징, 서명, 공증, 티켓 검증, 업데이트까지 통과한 뒤에 단기 임대 유지와 장기 전용 노드 중 하나를 선택하면 됩니다.