내가 만든 프로그램을 다른 사람에게 배포하려면 왜 돈을 내야 할까

내 컴퓨터에서 멀쩡하게 실행되는 프로그램도 다른 사람의 컴퓨터에서는 위험한 프로그램으로 취급될 수 있습니다. 코드를 잘못 작성해서도, 악성 기능을 넣어서도 아닙니다. 단지 누가 만들었는지 확인할 수 없다는 이유만으로 실행이 차단되기도 합니다. 그렇다면 운영체제는 프로그램의 출처를 어떻게 확인하며, 사용자는 그 프로그램을 신뢰할 수 있는지 어떻게 판단할까요.

작년에 처음으로 제 이름으로 iOS 앱을 출시하면서 애플 개발자 프로그램에 무려 10만 원이 넘는 연회비를 지불했고, 이후 맥용 데스크톱 앱도 만들어 앱스토어에 올리려 했지만 심사를 받기도 전에 Xcode의 업로드 단계에서 막혔습니다. 두 번의 경험을 거치며 소프트웨어를 만드는 일과 그것을 사람들이 실제로 사용할 수 있는 상태로 만드는 일은 전혀 다른 문제라는 것을 실감했습니다.

돈을 내고서야 시작된 배포

회사에서 모바일 앱을 개발해왔기 때문에 앱을 배포하려면 인증서가 필요하다는 사실 자체는 알고 있었습니다. 다만 그때는 늘 회사의 개발자 계정으로 작업했던 터라, 제 이름으로 앱을 출시하려면 직접 개발자 프로그램에 가입하고 매년 10만 원이 넘는 비용을 내야 한다는 사실은 프리랜서가 된 뒤에야 알 수 있었습니다. 애플은 Xcode를 비롯한 개발 도구를 무료로 제공하고, 자신의 기기에서 앱을 개발하고 테스트하는 일도 무료 계정으로 어느 정도 가능합니다. 하지만 애플 앱스토어를 통해 앱을 배포하려면 유료 개발자 계정을 만들어야 합니다. 계정을 만들었다고 모든 문제가 해결되는 것도 아니었습니다. 인증서, 프로비저닝 프로파일(provisioning profile), 코드 서명(code signing) 같은 설정이 얽혀 있었고, 인증서 관련 오류를 해결하느라 적지 않은 시간을 보냈습니다.

웹 서비스는 서버에 코드를 배포하고 도메인을 연결하면 누구나 접속할 수 있습니다. 물론 웹에도 HTTPS 인증서가 필요하고 서버 비용도 들지만, 적어도 운영체제 제조사에 개발자로 등록하고 돈을 내야만 제가 만든 웹사이트를 공개할 수 있는 것은 아닙니다. 그런데 모바일 애플리케이션은 달랐습니다. 프로그램을 완성했다고 해서 곧바로 다른 사람의 기기에 배포할 수 있는 것은 아니었습니다.

내 맥북에서만 쓰이는 Tiskofy(?)

그 뒤에는 Tiskofy라는 맥용 데스크톱 애플리케이션을 만들었습니다. 이름은 별다른 의미 없이 알파벳을 조합해 지었고, 혼자서 ‘티스코피’라고 부르고 있습니다. 유튜브 URL을 입력하면 영상이나 음원을 추출해 로컬에 저장하는 프로그램입니다. Tauri 프레임워크를 사용해서 리액트로 사용자 인터페이스를 만들고, 러스트로 운영체제의 네이티브 기능을 활용할 수 있도록 개발했습니다. 러스트를 어느 정도 다룰 줄 알았기 때문에 선택해 본 프레임워크였고 당시 처음 써 보는 것이었는데, 화면은 익숙한 웹 기반 코드를 사용해 만들면서도 브라우저만으로는 다루기 어려운 파일 시스템과 운영체제 기능에 접근할 수 있다는 점이 흥미로웠습니다.

개발 자체는 비교적 순조로웠습니다. 제 맥북에서는 의도한 대로 실행되었고, 지금도 필요할 때마다 저는 이 프로그램을 사용하곤 합니다. 그런데 문제는 이게 영원히 오직 저 혼자만 쓸 수 있는 프로그램이라는 사실(?)입니다.

Xcode 업로드조차 통과하지 못했던 앱

야심차게 AI의 도움을 받아 앱 아이콘까지 만들어서 티스코피를 Mac App Store에 정식 등록하고 싶었지만, 저는 그 당시 앱스토어 심사에서 거절당한 것도 아니고 심사를 받기 위해 Xcode에서 빌드를 업로드하는 단계부터 통과하지 못했습니다. 정확한 오류 내용은 지금 기억나지 않습니다. 영상과 음원을 처리하려고 포함했던 FFmpeg 계열의 바이너리가 관련되어 있었던 것으로 기억합니다만, 당시 오류 로그가 남아 있지 않아 원인을 단정하기는 어렵습니다. 앱 내부에 포함된 실행 파일의 서명이 문제였는지, 다른 빌드 설정과 충돌했던 것인지도 확실하지 않습니다.

지금 다시 관련 문서를 읽어보니 앱스토어에 배포하는 앱에는 코드 서명과 앱 샌드박스(App Sandbox) 등 여러 요구사항이 적용된다고 합니다. 별도의 실행 파일이 포함된 앱이라면 그 파일의 서명과 번들 구조도 함께 확인해야 합니다. 당시에는 이런 내용을 충분히 이해하지 못한 채 오류를 해결하려고 했습니다. 무엇을 수정해도 인증 관련 오류가 반복되었던 것으로 기억합니다. 다만 벌써 1년 전의 일이라 정확히 어떤 문제였는지는 가물가물합니다.

아무튼 Tiskofy는 끝내 앱스토어에 올라가지 못했습니다. 제 컴퓨터에서는 아무런 문제 없이 실행되는 프로그램인데, 다른 사람에게 배포하려면 왜 이렇게 많은 검증을 거쳐야 하는 것일까요.

코드 서명은 무엇을 증명할까

이 질문에 답하려면 먼저 코드 서명이 무엇인지 이해해야 합니다. 코드 서명은 소프트웨어에 디지털 서명을 붙여 서명자의 신원과 프로그램의 무결성을 검증할 수 있게 하는 기술입니다. 여기에는 공개키 암호화 기술이 쓰입니다. 개발자는 서로 대응하는 개인키(private key)와 공개키(public key)를 사용하는데, 개인키는 서명을 만드는 데, 공개키는 그 서명이 올바른지 검증하는 데 사용합니다. 프로그램에 서명할 때는 먼저 프로그램의 데이터를 해시(hash)라는 함수로 처리합니다. 해시는 입력 데이터를 일정한 길이의 값으로 바꾸는 함수로, 입력이 조금만 달라져도 일반적으로 전혀 다른 결과가 나옵니다. 개발자는 이 해시값을 바탕으로 개인키로 디지털 서명을 만들고, 사용자의 컴퓨터는 공개키로 서명을 검증해 실제 프로그램의 내용이 서명된 데이터와 일치하는지 확인합니다. 그 덕분에 서명한 뒤에 누군가 실행 파일을 수정했는지를 알아낼 수 있습니다.

그런데 여기에는 한 가지 문제가 남습니다. 개인키와 공개키는 누구나 만들 수 있으니, 악성 프로그램을 만드는 사람도 자기 프로그램에 디지털 서명을 붙일 수 있습니다. 서명이 올바르다는 사실만으로는 그 서명자가 믿을 만한 사람인지 알 수 없다는 뜻입니다. 이 간극을 메우는 것이 인증 기관(Certificate Authority, CA)입니다. 인증 기관은 정해진 절차에 따라 신청자의 신원을 확인하고, 그 신청자의 공개키와 신원 정보를 연결한 디지털 인증서를 발급합니다. 운영체제는 자신이 신뢰하는 인증 기관으로 이어지는 인증서인지 검증해 서명자의 신원을 확인합니다. 결국 코드 서명은 프로그램에 이름표를 붙이는 일이 아니라, 누가 서명했는지 확인하고 서명 이후 내용이 바뀌지 않았는지 검증할 수 있도록 신뢰 관계를 구성하는 과정입니다.

다만 코드 서명이 프로그램의 안전성을 보증하는 것은 아닙니다. 악성 프로그램도 유효한 인증서로 서명될 수 있기 때문입니다. 서명은 프로그램이 무해하다는 증명서가 아니라, 검증 가능한 서명자의 신원과 프로그램의 무결성을 확인하기 위한 수단입니다.

macOS의 공증과 Gatekeeper

macOS에는 코드 서명 외에도 공증(notarization)이라는 절차가 있습니다. 이 노터라이제이션, 애플의 공증이란 쉽게 말하면 개발자가 제출한 소프트웨어에 알려진 악성 콘텐츠나 코드 서명 관련 문제가 있는지 자동으로 검사하는 절차입니다. 검사를 통과하면 공증 티켓이 발급됩니다. macOS의 보안 기능인 Gatekeeper는 인터넷에서 내려받은 프로그램을 처음 실행할 때 코드 서명과 공증 여부 등을 확인합니다. 필요한 검증을 통과하지 못한 프로그램은 경고가 나타나거나 실행이 차단될 수 있습니다. 코드 서명이 누가 서명했고 그 뒤로 내용이 바뀌지 않았는지 확인하는 절차라면, 공증은 애플이 해당 프로그램에 자동화된 보안 검사를 수행했다는 사실을 확인하는 절차입니다.

여기서 구분해야 할 것이 있습니다. 애플 앱스토어를 통한 배포와 개발자 웹사이트에서 설치 파일을 직접 제공하는 방식은 요구사항이 다릅니다. 애플 앱스토어에 등록하는 앱은 스토어의 제출과 심사 절차를 거치고, 별도의 Developer ID 공증은 필요하지 않습니다. 반면 앱스토어 밖에서 직접 배포하는 앱은 일반적으로 Developer ID 인증서로 코드 서명을 하고 애플의 공증을 거쳐 Gatekeeper가 신뢰할 수 있도록 준비해야 합니다. 맥에서 직접 배포할 때 흔히 쓰는 파일 형식이 dmg인데, 사용자는 dmg 파일을 열고 그 안의 애플리케이션을 Applications 폴더로 옮겨 설치합니다. 다만 dmg 파일을 만드는 일과 그 안의 애플리케이션이 보안 검사를 통과하는 일은 별개입니다.

더 복잡한 문제는 애플리케이션 안에 별도의 실행 파일이 들어 있을 때 생깁니다. 이 티스코피처럼 FFmpeg 같은 외부 도구를 사용하는 프로그램이라면 앱 자체뿐 아니라 내부에 포함된 실행 파일에도 올바르게 코드 서명을 해야 할 수 있습니다. 또한 앱스토어를 거치지 않고 직접 배포하기 위해 공증을 받을 때는 하드닝 런타임(Hardened Runtime)이라는 보안 기능도 적용해야 합니다. 하드닝 런타임은 프로그램이 실행되는 동안 외부에서 코드를 주입하거나 메모리를 부당하게 변경하는 등의 공격을 어렵게 만드는 macOS의 보안 기능입니다. 즉, 프로그램을 누가 만들었는지 확인하는 것뿐 아니라 실행 중에도 안전하게 보호받을 수 있도록 여러 보안 조건을 충족해야 하는 것입니다. 앱스토어 빌드에도 외부 실행 코드의 서명, 앱 샌드박스, 번들 구성에 관한 별도의 요구사항이 있습니다. 다만 티스코피가 실제로 어느 단계에서 어떤 규칙을 충족하지 못했는지는 당시의 오류 기록이 없으므로 알 수 없습니다. 개발할 때는 하나의 프로그램으로 보였던 것이, 배포 단계에서는 각각 검증해야 하는 여러 실행 파일과 설정의 집합이 됩니다.

윈도우의 exe 파일도 크게 다르지 않습니다

윈도우용 애플리케이션도 비슷한 보안 체계를 사용합니다. 다만 이 부분은 제가 직접 배포를 경험한 것이 아니어서 마이크로소프트의 공식 문서를 참고했습니다. 윈도우에서 인터넷으로 내려받은 exe 파일을 실행하다 보면 “Windows의 PC 보호”라는 경고 화면이 나타나는 경우가 있는데, Microsoft Defender SmartScreen이라는 보안 기능이 보여주는 경고입니다. 이 경고가 나타난다고 해서 반드시 악성 프로그램이라는 뜻은 아니고, 서명되지 않았거나 아직 충분한 평판(?)이 쌓이지 않은 프로그램에도 나타날 수 있다고 합니다.

윈도우에서 실행 파일에 코드 서명을 하려면 전통적으로 인증 기관에서 코드 서명 인증서를 발급받아 써왔습니다. 대표적으로 조직의 신원을 검증하는 OV(Organization Validation) 인증서와 더 엄격한 신원 확인 절차를 거치는 EV(Extended Validation) 인증서가 있습니다. 이 인증서는 웹사이트의 HTTPS 인증서처럼 공개키 기반의 신뢰 체계를 이용하지만 용도는 다릅니다. HTTPS 인증서는 서버의 신원을 확인하고 브라우저와 서버 사이의 통신을 보호하는 데 쓰이고, 코드 서명 인증서는 실행 파일의 서명자와 무결성을 검증하는 데 쓰입니다. 물론 윈도우용 프로그램을 배포할 때 반드시 별도의 상용 인증서를 구입해야 하는 것은 아닙니다. 예를 들어 Microsoft Store에 MSIX 형식으로 애플리케이션을 제출하면 스토어에서 검증을 거친 패키지에 마이크로소프트가 서명을 적용하므로 개발자가 상용 코드 서명 인증서를 구입할 필요가 없습니다. Microsoft Store에 MSI나 exe 설치 파일을 제출할 때는 개발자가 신뢰할 수 있는 인증서로 직접 서명해야 합니다. 자신의 웹사이트에서 exe 파일을 배포할 때는 서명이 법적·기술적으로 항상 필수인 것은 아니지만, 서명되지 않은 프로그램은 스마트스크린 경고가 나타날 가능성이 높아 일반 사용자를 대상으로 배포하기에는 불리합니다.

유효한 인증서로 서명했다고 해서 스마트스크린 경고가 반드시 사라지는 것도 아닙니다. 스마트스크린은 해당 프로그램이 얼마나 널리 사용되었는지, 이전에 보안 문제가 발견된 적은 없는지 등 여러 정보를 종합해 위험성을 판단합니다. 따라서 처음 배포하는 프로그램은 안전하게 만들어졌더라도 신뢰성을 판단할 만한 정보가 충분히 쌓이지 않아 경고가 나타날 수 있습니다. 과거에는 더 비싼 EV 인증서를 구입하면 경고를 즉시 피할 수 있다는 점이 장점으로 소개되기도 했지만, 지금은 EV 인증서도 그런 효과를 보장하지 않는다고 합니다. 결국 윈도우와 macOS 모두 프로그램을 만드는 일과 신뢰할 수 있는 형태로 배포하는 일 사이에 별도의 절차를 두고 있습니다.

그런데 왜 돈을 내야 할까

애플 개발자 프로그램에 처음 가입했을 때 가장 의아했던 것도 이 부분이었습니다. 프로그램을 만드는 개발 도구는 무료로 제공하면서, 왜 다른 사람에게 배포하려면 별도의 비용을 내야 할까요. 인증서를 발급하고 신뢰 체계를 유지하는 데에는 실제로 비용이 들 것입니다. 인증 기관은 신청자의 신원을 확인해야 하고, 인증서가 유효한지 검증할 수 있는 시스템을 운영해야 하며, 개인키가 유출되거나 인증서가 악용되면 이를 폐기하고 더 이상 신뢰하지 않도록 하는 체계도 갖춰야 합니다. 다만 소프트웨어를 배포하기 위해 지불하는 비용이 모두 같은 성격을 갖는 것은 아닙니다. 애플 개발자 프로그램의 연회비는 인증서 한 장의 가격이라기보다는 앱스토어 배포와 여러 개발자 서비스를 이용하기 위한 비용에 가깝습니다. 반면 윈도우에서 사용하는 상용 코드 서명 인증서는 인증 기관이 개발자의 신원을 확인하고 인증서를 발급·관리하는 데 드는 비용이라는 성격이 더 강합니다.

마이크로소프트는 인증서를 직접 구매하는 방식 외에도 클라우드 기반 코드 서명 서비스인 Azure Artifact Signing을 제공합니다. 과거 Trusted Signing이라고 불렸던 서비스로, 공식 문서에 안내된 기본 요금은 월 9.99달러부터입니다. 하지만 가격이 저렴하다고 누구나 이용할 수 있는 것은 아닙니다. 2026년 10월 기준으로 개인 개발자가 이용할 수 있는 지역은 미국과 캐나다로 제한되어 있습니다. 한국의 개인 개발자라면 이 서비스를 바로 쓰기 어렵고, 직접 배포하기 위한 서명에는 다른 인증 기관의 인증서를 고려해야 할 수 있습니다. 이처럼 모든 운영체제와 배포 방식에서 비싼 인증서가 필수인 것은 아니지만, 개인 개발자가 자신의 웹사이트에서 설치 파일을 직접 제공하려 하면 신원 확인과 코드 서명, 운영체제별 보안 정책이라는 장벽을 만나게 됩니다.

사용자를 악성 프로그램으로부터 보호해야 한다는 필요성은 충분히 이해합니다. 출처를 알 수 없는 프로그램이 사용자 컴퓨터의 파일을 읽거나 수정하고 다른 프로그램을 실행할 수 있다면 위험하기 때문입니다. 그렇지만 이제 막 프로그램 하나를 만들어본 개인 개발자와 오랫동안 소프트웨어를 배포해온 기업이 이런 절차를 감당하는 데에는 분명한 차이가 있습니다. 더구나 인증서를 사서 프로그램에 서명한다고 소프트웨어가 자동으로 신뢰를 얻는 것도 아닙니다. 개발자가 신원을 증명하는 일과 실제로 믿을 수 있는 프로그램을 만드는 일은 또 다른 문제이기 때문입니다.

AI가 낮춘 문턱, 낮추지 못한 문턱

AI의 발전으로 요즘은 바이브코딩을 통해 프로그램을 만드는 사람이 많아졌습니다. 개발 경험이 그리 많지 않은 사람이라도 원하는 기능을 자연어로 설명하고 AI가 작성한 코드를 고쳐가며 실제로 동작하는 프로그램을 만들 수 있게 된 것입니다. 저는 특히 데스크톱 애플리케이션이 일상에서 마주하는 크고 작은 문제를 해결하기에 좋은 도구라고 생각합니다. 별도의 서버 없이도 실행할 수 있고, 데이터를 외부로 전송하지 않고 사용자의 컴퓨터에서 직접 처리할 수도 있습니다. 파일 시스템이나 운영체제의 기능을 활용할 수 있다는 점도 장점입니다. 파일을 일괄 변환하거나 반복적인 업무를 자동화하고, 특정 형식의 데이터를 정리하는 프로그램이 대표적인 예입니다. 과거에는 이런 프로그램을 직접 만들려면 상당한 개발 지식이 필요했지만, 이제는 AI의 도움으로 훨씬 적은 시간과 노력만으로도 구현할 수 있게 되었습니다.

그런데 이렇게 만든 프로그램을 다른 사람에게 배포하거나 판매하려고 하면 전혀 다른 문제가 시작됩니다. 프로그램을 exe나 dmg 파일로 패키징하는 작업은 AI가 상당 부분 도와줄 수 있습니다. 코드 서명에 필요한 명령어를 작성하거나 빌드 설정을 수정하는 일도 마찬가지입니다. 하지만 개발자 계정을 등록하고 신원을 확인받거나, 필요한 인증서와 서명 서비스를 이용할 자격을 갖추는 일은 코드를 잘 작성한다고 해결되지 않습니다. AI가 대신 작성해줄 수 있는 코드와 실제 사람이나 조직이 자신의 신원을 증명해야 하는 절차는 별개의 문제이기 때문입니다. 여기에 운영체제별 빌드 환경, CPU 아키텍처, 외부 바이너리, 자동 업데이트, 라이선스 관리, 결제 시스템까지 고려하기 시작하면 개인적인 도구 하나를 만드는 일과 소프트웨어 제품을 배포하고 판매하는 일 사이에 얼마나 많은 단계가 있는지 알게 됩니다.

저 역시 티스코피를 만들면서 그 차이를 경험했습니다. 프로그램을 구현하는 데에는 AI의 도움을 많이 받았지만, 배포 과정에서 생긴 문제는 끝내 풀지 못했습니다. 지금 생각하면 제가 완성한 것은 “동작하는 프로그램”이었지, 아직 “배포할 준비가 된 제품”은 아니었던 것 같습니다. AI 덕분에 프로그램을 만드는 사람이 늘어난 만큼, 이런 문제를 처음 마주하는 사람도 많아지지 않을까 생각합니다.

프로그램을 만드는 자유와 배포하는 책임

물론 티스코피가 Xcode 업로드 문제를 해결했다고 해서 반드시 앱스토어에 등록되었을 것이라고 장담할 수는 없습니다. 유튜브에서 영상이나 음원을 추출하는 기능은 사용 방식에 따라 저작권이나 플랫폼 이용약관과 관련된 문제가 생길 수 있고, 앱스토어 심사 지침도 검토해야 하기 때문입니다. 당시 제가 부딪힌 벽은 단지 배포 과정에 있는 여러 관문 중 하나였습니다.

코드 서명과 공증은 꼭 필요한 기술입니다. 사용자의 컴퓨터에서 실행되는 프로그램은 웹사이트보다 운영체제의 기능에 폭넓게 접근할 수 있어서, 출처를 확인할 수 없는 실행 파일을 아무런 검증 없이 실행하도록 두는 것은 상당한 위험을 동반합니다. 다만 그 신뢰 체계를 누가 관리하고, 어떤 기준으로 프로그램을 신뢰하며, 그 비용을 누가 부담해야 하는지는 따로 생각해볼 문제입니다. 웹 역시 브라우저의 보안 정책과 인증 기관의 신뢰 체계에 의존하므로 완전히 자유로운 공간은 아니지만, 웹사이트를 공개하는 일과 사용자의 컴퓨터에서 실행될 바이너리를 배포하는 일에는 요구되는 검증 방식과 책임에 차이가 있습니다. AI가 소프트웨어 개발의 진입 장벽을 낮추고 있는 지금, 전문 개발자가 아니더라도 자신의 문제를 풀려고 만든 프로그램을 다른 사람에게 판매하려는 시도는 더 많아질 것이라고 생각합니다. 그 과정에서 코드를 쓰는 능력만큼이나 배포와 보안, 신뢰 체계를 이해하는 일이 중요해질 것입니다. 프로그램을 만드는 일이 쉬워졌다고 해서 그것을 다른 사람에게 건네는 일까지 쉬워진 것은 아닙니다.

제 맥북에는 여전히 티스코피가 설치되어 있습니다. 앱스토어에 등록하지도, 다른 사람에게 판매하지도 못했지만 제게 필요한 기능은 잘 수행하는 프로그램입니다. 처음에는 프로그램만 완성하면 누구에게나 배포할 수 있을 것이라고 생각했습니다. 하지만 소프트웨어를 배포한다는 것은 단순히 완성된 파일을 전달하는 일이 아니었습니다. 그 파일이 어디에서 왔고, 누가 책임지며, 사용자는 무엇을 근거로 그것을 신뢰할 수 있는지까지 생각해야 하는 일이었습니다.

AI는 프로그램을 만드는 데 필요한 시간과 기술의 장벽을 낮췄습니다. 하지만 자신이 만든 프로그램에 대한 책임까지 대신 져주지는 않습니다. 프로그램을 완성하는 일과 그것을 다른 사람이 신뢰하고 사용할 수 있는 제품으로 만드는 일은 여전히 서로 다른 문제입니다.

참고 링크

• Apple Developer, 「Become a member」
• Apple Developer Documentation, 「Notarizing macOS software before distribution」
• Apple Developer, 「Distributing software on macOS」
• Microsoft Learn, 「Code signing options for Windows app developers」
• Microsoft Learn, 「SmartScreen reputation for Windows app developers」
• Tauri, 「macOS Code Signing」