Sparkle 자동 업데이트는 어떻게 배포할까? 2026 macOS 출시 안내

이 안내는 웹사이트 등에서 직접 배포하는 macOS 앱을 대상으로 합니다. Sparkle 업데이트와 앱스토어의 앱 업데이트는 같은 배포 경로가 아닙니다. 먼저 현재 앱을 어디에서 내려받는지 확정하고, 해당 방식에 맞는 서명과 공증 절차를 확인하세요.

Apple은 macOS 앱 배포 방식에 따라 적용할 절차를 안내합니다. 웹에서 배포하는 앱의 Developer ID 서명과 공증 요건은 Apple의 macOS 앱 배포 안내와 Developer ID 서명 설명에서 확인하세요. 공증을 적용할 때는 Apple의 공증 안내를 기준으로 현재 요구 사항을 점검합니다.

기존 앱의 배포 기록도 먼저 살펴보세요. 현재 설치본이 읽을 수 있는 Sparkle 설정, 업데이트 묶음 형식, 버전 표기 방식을 확인하지 않고 새 흐름으로 바꾸면, 새 설치본에서는 동작해도 이전 설치본이 업데이트를 찾지 못할 수 있습니다. Sparkle의 업그레이드 안내와 현재 앱 구성을 대조하는 이유입니다.

Sparkle을 연결할 때는 사용자가 앱을 내려받는 페이지와 앱이 업데이트를 확인하는 피드 주소, 실제 업데이트 묶음의 주소를 구분합니다. 이름과 역할이 다르므로 한 주소를 세 용도로 돌려 쓰지 마세요.

앱의 Info.plist에는 Sparkle이 읽을 피드 주소를 설정합니다. SUFeedURL이 업데이트 확인 위치를 가리키는지 확인하세요. 공개 키를 이용하는 설정에서는 SUPublicEDKey가 서명 검증에 필요한 공개 키와 일치해야 합니다. 설정 이름과 사용 조건은 Sparkle 공식 문서 및 사용자 설정 안내를 기준으로 확인합니다.

빌드 식별자도 함께 점검해야 합니다. 사용자에게 보여 주는 버전 정보와 업데이트 비교에 쓰이는 빌드 버전은 역할이 다를 수 있습니다. 새 빌드가 이전 빌드보다 새롭다고 판단될 수 있도록 프로젝트 설정과 피드 항목을 일치시키세요. 기존 출시본의 규칙을 확인하지 않은 채 표기 방식만 바꾸면 업데이트가 건너뛰어지거나 예상과 다르게 판단될 수 있습니다.

주의: Apple Developer ID 코드 서명과 Sparkle 업데이트 묶음의 EdDSA 서명은 서로 다른 검증입니다. 코드 서명이나 공증이 끝났다고 Sparkle 묶음 서명까지 맞는 것은 아니며, 그 반대도 마찬가지입니다.

Sparkle의 업데이트 묶음 서명은 앱이 받은 파일이 기대한 업데이트인지 확인하는 데 쓰입니다. Sparkle 문서는 EdDSA 서명과 키 관리, 업데이트 보안 조건을 설명합니다. Sparkle 보안 및 신뢰성 안내에서 현재 적용 방식을 확인하고, 사용 중인 구성을 다른 방식으로 옮기는 경우에는 EdDSA 이전 안내를 확인하세요.

기본 흐름은 비밀 키로 배포할 업데이트 묶음에 서명하고, 앱에는 대응하는 공개 키를 설정하는 방식입니다. Sparkle 도구로 서명 정보를 만든 뒤, 생성된 값이 앱 설정과 피드 항목에 맞게 반영됐는지 검증합니다. 비밀 키나 실제 키 값을 저장소에 넣거나 문서 예시에 노출하지 마세요. 키를 어디에 보관할지는 팀의 접근 권한과 발행 절차에 맞춰 정하고, 여기서 확인되지 않은 저장 방식의 보안 수준을 미리 단정하지 않습니다.

앱캐스트 안의 업데이트 항목은 해당 묶음의 주소와 필요한 버전 정보, 서명 정보를 서로 연결합니다. 이 항목에 붙은 업데이트 묶음 서명은 피드 파일 전체의 서명과 같은 뜻이 아닙니다. 피드 자체를 어떤 방식으로 보호할지는 전송 경로와 Sparkle 설정을 별도로 살펴보세요.

Sparkle의 게시 도구를 사용하면 업데이트 묶음과 앱캐스트 항목을 생성하는 과정을 줄일 수 있습니다. 그러나 도구가 파일을 만들었다는 사실만으로 공개 피드와 파일 배포가 맞게 끝난 것은 아닙니다. Sparkle 업데이트 발행 안내에서 도구의 적용 조건을 확인한 뒤, 팀의 배포 방식에 맞춰 자동 생성 또는 수동 관리를 선택하세요.

자동 생성은 반복 입력을 줄이는 데 유리합니다. 수동 편집은 변경 내용을 세밀하게 검토하기 좋지만, 주소와 버전 정보를 잘못 옮기기 쉽습니다. 어느 방법을 택하든 발행 전에 다음 항목을 확인합니다.

• [ ] 앱에서 사용하는 피드 주소가 실제 공개 위치와 일치합니다.
• [ ] 피드 항목의 버전 정보가 새 빌드 설정과 대응합니다.
• [ ] 업데이트 묶음 주소로 이동했을 때 해당 파일을 받을 수 있습니다.
• [ ] 피드의 업데이트 설명과 실제 변경 내용이 일치합니다.
• [ ] 서명 정보가 방금 발행할 묶음에 대해 생성됐습니다.
• [ ] 공개 키 설정과 발행에 사용한 서명 키가 한 쌍으로 맞습니다.

게시 작업 뒤에는 공개된 피드와 실제 다운로드 파일을 각각 확인하세요. 로컬 빌드 폴더에 파일이 있다는 점만 확인하면 서버에 잘못된 경로를 올렸거나, 피드가 이전 파일을 계속 가리키는 문제를 놓칠 수 있습니다.

새 버전을 새로 설치하는 검사는 설치 과정을 확인할 뿐입니다. 자동 업데이트가 기존 사용자에게 도달하는지는 실제 이전 설치본으로 확인해야 합니다. 사용 중인 배포본을 설치하고, 앱 안에서 업데이트를 확인한 다음 새 묶음을 내려받아 설치하고, 업데이트 뒤 앱이 실행되는지 검증합니다.

실패 지점을 나눠 기록합니다

업데이트가 끝나지 않으면 한 번에 전체 배포를 다시 만들기보다 다음 순서로 원인을 나눕니다.

• 피드에 접근하지 못한다면 앱 설정의 주소와 공개된 피드 위치를 비교합니다.
• 업데이트가 표시되지 않는다면 기존 설치본과 피드의 버전 정보를 확인합니다.
• 다운로드 뒤 검증이 실패한다면 공개 키, 서명 정보, 대상 묶음을 대조합니다.
• 설치는 됐지만 앱이 실행되지 않는다면 설치 뒤 실행 결과와 코드 서명 상태를 확인합니다.

검증 기록에는 앱 화면에 표시되는 버전, 빌드 식별자, 피드 항목, 내려받은 파일을 각각 적으세요. 이 정보가 서로 대응하면 업데이트가 어느 단계에서 어긋났는지 구분하기 쉬워집니다. Sparkle의 업그레이드 관련 문서도 대상 앱의 기존 구성과 함께 확인합니다.

macOS 앱의 빌드와 서명 작업에는 macOS 환경이 필요합니다. 원격 맥은 로컬 장비를 새로 마련하지 않고 빌드, 서명, Sparkle 발행 검증을 수행하려는 팀의 선택지가 될 수 있습니다. 다만 원격 화면에 접속할 수 있는 것과 무인 발행 흐름이 정상 작동하는 것은 별개의 확인 항목입니다.

원격 맥을 검토한다면 빌드 권한과 발행 권한을 분리할 수 있는지, 서명 키에 접근할 담당자를 통제할 수 있는지, 공개된 피드와 업데이트 파일을 검증할 수 있는지 점검하세요. 발행이 실패했을 때 이전 피드와 파일 상태로 되돌리는 절차도 필요합니다. 현재 운영 방식과 비교할 때는 맥 미니 대여 가격 안내에서 비용 조건을 확인하되, 실제로 필요한 작업 시간과 관리 부담을 함께 따져야 합니다.

선택은 다음 조건으로 정리할 수 있습니다.

• 빌드와 발행을 한 환경에서 반복하고, 원격 접속과 키 접근 절차를 운영할 수 있다면 원격 맥을 검토합니다.
• 실제 기기 연결이나 로컬 전용 작업이 필수라면 로컬 맥을 유지하거나 해당 작업만 별도 환경에서 처리합니다.
• 출시가 드물고 기존 맥을 사용할 수 있다면 새 환경을 마련하기 전에 현재 장비로 검증을 진행합니다.
• 장시간의 지속 작업과 독립적인 장비 관리가 필요하다면 임대보다 직접 보유하는 편이 적합한지 비교합니다.

매번 앱만 올리지 마세요. 업데이트 묶음, 앱캐스트, 변경 설명, 서명 검증 결과를 한 발행 기록으로 관리하면 어떤 피드가 어떤 파일을 배포했는지 되짚을 수 있습니다. 잘못된 파일이나 피드를 게시했을 때 어느 지점으로 되돌릴지도 기록에 포함합니다.

서명 키를 바꾸는 경우에는 새 키를 앱에 넣는 작업만으로 끝나지 않습니다. 이미 배포된 설치본이 새 서명을 검증할 수 있는지, 키 전환 단계가 기존 업데이트 흐름과 호환되는지 먼저 확인하세요. 전환 전에 실제 이전 버전에서 새 버전으로 이어지는 검증을 수행하고, 문제가 있으면 기존 방식으로 되돌릴 계획을 준비합니다. 모든 과거 설치본이 새 설정과 호환된다고 가정하지 마세요.

Sparkle 자동 업데이트를 배포할 때 웹 호스팅만으로 운영하면 업데이트 파일과 피드를 함께 관리해야 하고, 발행 권한이나 되돌리기 절차가 빠질 수 있습니다. Mac을 따로 구매하면 초기 장비 비용과 직접 관리 부담이 생깁니다. 빌드와 서명, 검증을 맡길 macOS 환경이 일시적으로 필요하다면 MESHLAUNCH의 원격 맥을 검토할 수 있습니다. 반면 지속적인 고부하 작업이나 물리 장비 연결이 필수라면 직접 보유한 맥이 더 적합할 수 있습니다. 팀의 빌드 주기와 키 관리 절차를 기준으로 MESHLAUNCH 원격 맥 환경을 확인하세요.

Sparkle 자동 업데이트에 무엇을 먼저 설정하나요?

앱이 확인할 피드 주소와 버전 비교에 쓰이는 빌드 식별자를 먼저 맞춥니다. 이어서 공개 키 설정, 서명된 업데이트 묶음, 피드 항목이 같은 발행본을 가리키는지 확인합니다. 앱을 어디에서 배포하는지도 먼저 확정해야 Developer ID 서명과 공증 절차를 잘못 적용하지 않습니다.

업데이트 묶음 서명과 앱캐스트는 어떻게 연결되나요?

앱캐스트의 업데이트 항목은 버전 정보와 묶음 위치, 검증 정보를 연결합니다. 묶음 서명은 내려받은 파일을 확인하는 용도이며, 앱캐스트 파일 전체의 서명과 동일하지 않습니다. 생성 도구를 사용했더라도 공개된 피드가 올바른 파일을 가리키는지 직접 확인해야 합니다.

이전 버전에서 새 버전으로 이어지는 흐름은 어떻게 시험하나요?

이미 배포된 이전 버전을 설치한 상태에서 앱의 업데이트 확인을 실행합니다. 새 묶음 다운로드, 서명 확인, 설치, 설치 뒤 실행을 차례대로 확인하세요. 피드 주소와 버전 판단, 서명 검증, 설치 후 실행을 따로 기록하면 실패 지점을 분리할 수 있습니다.

로컬 맥 없이 원격 맥에서 업데이트 배포를 운영할 수 있나요?

원격 맥은 빌드와 코드 서명, 업데이트 발행 검증에 사용할 수 있습니다. 다만 접속 가능 여부만으로 자동 작업이나 키 관리가 검증되지는 않습니다. 접근 권한, 피드 공개 상태, 업데이트 파일 확인, 실패 시 되돌리기까지 실제 배포 흐름으로 점검해야 합니다.