AI로 만든 macOS 앱의 기능 검수를 마치고 DMG를 고객에게 보내려는 저녁이라고 해보죠. 개발자 컴퓨터에서는 화면이 잘 열리고 핵심 기능도 정상입니다. 이제 파일 하나만 전달하면 납품이 끝날 것처럼 보입니다.

사용 이력이 없는 Mac에서 그 DMG를 열자 앱이 실행되지 않습니다. 원인을 따라가 보니 네이티브 모듈이 빠져 있습니다. 모듈을 넣어 다시 빌드해도 끝이 아닙니다. 서명 방식을 맞추고 Gatekeeper 검사를 통과시키는 일이 남아 있습니다. 기능이 끝난 자리에서 배포 작업이 시작됩니다.

이 사례가 보여주는 것은 AI의 한계보다 완성의 기준입니다. AI는 실행본에 도달하는 시간을 크게 줄였습니다. 운영체제와 고객사는 여전히 누가 배포했는지, 파일이 바뀌지 않았는지, 다음 버전도 같은 주체가 책임지는지 확인합니다.

고객 PC가 먼저 확인하는 것은 기능이 아니라 배포 신원입니다

Windows에서 내려받은 새 파일은 유효한 인증서로 서명해도 처음에는 SmartScreen 경고를 볼 수 있습니다. 같은 게시자 신원으로 릴리스를 이어가면 평판은 시간이 지나며 쌓입니다. 과거에는 EV 인증서가 첫 다운로드부터 경고를 피하는 방법으로 알려졌지만, 이 효과는 2024년에 사라졌습니다.[1]

따라서 Windows 배포에서는 인증서 등급부터 고르는 접근이 맞지 않습니다. Microsoft Store에 MSIX로 배포할지, 공개 웹에서 직접 설치 파일을 받을지, 회사가 관리하는 PC에 사내 신뢰 정책으로 배포할지를 먼저 정해야 합니다. 배포 채널마다 필요한 계정과 서명 방식이 달라집니다.

한국 사업자라면 지역 조건도 확인해야 합니다. Microsoft Artifact Signing의 Public Trust 인증서는 2026년 8월 25일 현재 한국 조직에도 제공됩니다. 다만 개인 개발자는 미국과 캐나다로 제한되므로 발급 주체에 따라 지원 지역을 확인한 뒤 견적에 넣어야 합니다.[2]

macOS도 코드가 어떤 도구로 작성됐는지는 묻지 않습니다. Mac App Store 밖에서 일반 고객에게 배포하는 기준 경로는 Developer ID 서명과 Apple 공증입니다. Gatekeeper는 이 신원과 공증 티켓으로 알려진 악성 코드인지, 배포 뒤 변조됐는지를 확인합니다.[3]

시험 단계에서는 우클릭으로 열거나 보안 속성을 지워 실행할 수 있습니다. 저는 이 방법을 고객용 설치 안내서에 넣은 상태를 납품 완료로 보지 않습니다. 고객이 보안 경고를 우회해야만 쓸 수 있는 앱이라면 배포 주체가 아직 제품 뒤에 서지 않은 셈입니다.

개발사 명의로만 서명하면 계약이 끝난 뒤 문제가 시작됩니다

외주 개발사가 자기 계정과 인증서로 첫 버전을 배포하면 당장은 빠를 수 있습니다. 이후 업체가 바뀌거나 인증서가 만료되면 고객은 같은 게시자 신원으로 다음 버전을 내기 어려워집니다. 서명 키를 넘겨받는 방식도 복사본과 접근 권한이 남을 수 있어 안전한 인수인계라고 보기 어렵습니다.

배포 신원은 처음부터 고객 조직이 통제하는 계정에 두는 편이 좋습니다. 개발사는 필요한 권한을 받아 빌드하고, 고객은 계정 소유권과 키 보관 정책을 유지합니다. 이 구조가 어려우면 계약서에 인증서 갱신 주체, 키 보관 장소, 접근자, 계약 종료 시 회수와 교체 절차를 적어야 합니다.

중요한 것은 인증서 구매비보다 연속성입니다. 오늘 설치되는 1.0보다, 개발사가 바뀐 뒤에도 같은 제품으로 1.0.1을 보낼 수 있는지가 더 오래 남습니다.

자동 업데이트를 켰다고 다음 버전이 전달되지는 않습니다

데스크톱 앱의 업데이터는 버튼 하나가 아니라 작은 릴리스 시스템입니다. 운영체제와 CPU 구조별 설치 파일, 버전 메타데이터, 다운로드 경로를 함께 게시해야 합니다. macOS 자동 업데이트에는 서명된 앱이 필요하고, 비공개 제품이라면 정적 저장소나 자체 업데이트 피드도 운영해야 합니다.

업데이트 주소와 버전, 배포 파일의 서명값도 필요합니다. 앱에는 검증용 공개 키가 들어가고 릴리스 쪽에는 개인키가 남습니다. 업데이터 개인키를 잃으면 이미 설치된 앱에 새 버전을 보낼 수 없습니다.

운영체제의 코드 서명과 업데이터의 파일 서명은 목적도 다릅니다. 하나를 설정했다고 다른 하나가 따라오지 않습니다. 릴리스 파일을 어디에 둘지, 누가 서명할지, 배포를 누가 승인할지, 키를 어떻게 교체할지까지 연결돼야 다음 버전이 도착합니다.

복구도 별도 설계가 필요합니다. 이전 설치 파일이 남아 있어도 데이터 구조가 이미 바뀌었다면 프로그램만 낮춰서는 정상 동작하지 않을 수 있습니다. 실패를 감지하는 기준, 이전 버전을 다시 설치하는 경로, 데이터 마이그레이션의 하위 호환 범위를 정해야 합니다. 자동 업데이트 지원이라는 한 줄에는 이 책임이 담기지 않습니다.

납품 검수는 깨끗한 PC에서 1.0.1까지 이어져야 합니다

저라면 데스크톱 앱 계약서에 다음 네 가지를 기능 목록과 분리해 남깁니다.

  • 배포 대상: 지원할 운영체제와 CPU, 관리자 권한, 인터넷 연결, 사내 보안 정책, 설치 채널
  • 배포 신원: 고객과 개발사 중 계정 소유자, 인증서와 키 보관 위치, 갱신·회수·교체 책임
  • 릴리스 경로: 빌드 환경, 업데이트 저장소와 메타데이터, 배포 승인자, 장애 로그를 확인할 곳
  • 검수와 복구: 사용 이력이 없는 PC의 첫 설치, 실제 고객 정책이 적용된 PC의 실행, 1.0에서 1.0.1로의 업데이트, 실패 뒤 복구

고객도 실제 환경을 검수에 제공해야 합니다. 사내 프록시, 백신, 애플리케이션 허용 정책이 있는 조직이라면 개발사 장비만으로 납품 여부를 판단할 수 없습니다. 개발사는 이 환경에서 필요한 시험과 운영 구성을 기능 개발비 뒤에 숨기지 않고 별도 범위와 책임으로 제시해야 합니다.

설치 파일은 한 시점의 결과물입니다. 개발사를 바꾸고도 고객 명의로 1.0.1을 배포할 수 있을 때, 비로소 실행본이 고객의 제품이 됩니다.

출처