코드 없이 앱 구축하기 (Building Apps Without Code)의 파트 2입니다. 파트 1에서는 코딩 방법을 모른 채 첫 번째 앱인 Steamy Dumplings를 만든 과정을 다뤘습니다. 이 글은 Mac이 없는 사람, 또는 구매할 여력이 안 되는 사람이지만 그래도 iPhone 앱을 출시하고 싶은 분들을 위한 내용입니다.
저는 Mac을 소유한 적이 없습니다. 지금까지도요. 아래 내용은 모두 제 iPhone으로 작업했습니다.
하지만 저는 실제로 작동하는 iPhone 앱들, TestFlight에 올라가 있는 것들, 심지어 App Store에 제출된 것도 가지고 있습니다. 저는 코딩 없이 앱을 만드는 사람입니다. AI 파트너(Forge, 저의 Muse agent)와 함께 일하며 이 파트너가 코드를 작성합니다. 제 역할은 아이디어 구상, 결정, 그리고 휴대폰에서의 테스트입니다.
이 방식은 아주 잘 작동했습니다. 그러다가 우리가 빌드에 사용하던 자원을 거의 다 써버릴 위기에 처할 때까지는요.
문제점: 선(line)과 한도(cap)
iPhone 앱을 출시하려면 Apple의 요구사항으로 Mac이 필요합니다. '권장' 수준이 아니라, 필수입니다. iOS 앱을 컴파일하고 서명하며 업로드하는 도구인 Xcode는 macOS와 Apple 하드웨어에서만 실행됩니다.
저희는 GitHub Actions의 Mac runner를 사용하고 있었습니다. 작동은 했지만 다음과 같은 문제가 있었습니다:
- 10월 20일 아침까지 제공된 분 중 1,826분을 소모했습니다. macOS 분은 10배로 계산되기 때문에 남은 시간이 실제보다 더 많아 보이는 착시 현상이 발생합니다.
- 러너 대기열(Runners queue). 푸시하면 줄을 서서 기다리고 희망만 갖게 됩니다.
- 가장 당연한 해결책 — 중고 Mac mini를 약 433달러~500달러에 구매하는 것 — 은 저의 규칙 자체를 깨뜨렸습니다. 저는 이 프로젝트들이 '벌어들인' 돈으로만 장비를 구매하기로 했기 때문입니다. 먼저 돈을 벌어야 합니다.
그래서 제가 모든 것을 시작하게 만든 말을 했습니다:
"Mac 없이, 대기열도 없이 앱을 만들 것이다."
첫 번째 단계: 왜 Mac이 실제로 필요한지 조사하기
Forge가 우리가 추측하기 전에 저희의 빌드 워크플로우를 점검했습니다. 이것은 하나의 작업이 아니라 Xcode 안에 묶여 있는 다섯 가지 작업입니다:
- iPhone용 코드 컴파일(Compiling): Xcode 내에서만 제공되는 iOS SDK를 사용합니다.
- Mac 전용 도구로 아이콘, 에셋, 스토리보드 **패키징(Packaging)**하기
- Apple이 신뢰하도록 앱에 **코드 서명(Code signing)**하기
- Apple이 수락하는 실제
.ipa 파일로 **아카이빙(Archiving)**하기
- 업로드 검증(Upload validation) — 2026년 4월 28일부터 Apple은 Xcode 26 / iOS 26 SDK가 필요하며, 그렇지 않으면 업로드가 거부됩니다.
iPhone에서 그 다섯 가지를 할 수는 없습니다. iOS용 Xcode가 없기 때문입니다. 하지만 할 수 있는 것은 Mac을 다른 곳에 숨기고 — 휴대폰에 그것으로 연결되는 간단한 출입문을 만드는 것입니다.
이것이 전체 아이디어입니다: 당신의 iPhone이 마치 당신이 가지고 있지 않은 Mac처럼 작동하게 만드세요. 각 앱마다 간단한 카드와, 크고 명확한 'TestFlight용 빌드' 버튼, 그리고 쉬운 영어 상태 표시만 있으면 됩니다. 가짜 Mac 데스크톱은 없습니다 — 그 아이디어는 버렸습니다. 간단한 카드들입니다. 당신의 iPhone이 출입문이고, 클라우드의 실제 Mac이 그 뒤에서 다섯 가지 작업을 수행하는 것입니다.
우리가 찾은 두 개의 무료 통로
우리가 Mac을 발명한 것은 아닙니다. 이미 접근할 수 있는 두 개의 통로를 발견했을 뿐이며, 그것들은 무료였습니다:
- Codemagic — 버튼 통로. 개인 사용자를 대상으로 M2 Mac에서 매달 500분의 무료 macOS 시간을 제공합니다. API가 있어 앱의 버튼을 누르면 실제 빌드가 트리거될 수 있습니다.
- Xcode Cloud — Apple 자체 통로. 월 25 컴퓨팅 시간으로, 제가 이미 연간 $99를 지불하고 있는 Apple Developer Program에 포함되어 있습니다.
이 두 가지를 합치면 GitHub가 제공하던 것보다 훨씬 많은 여유 공간을 확보할 수 있었고 — 우리가 통제하지 못하는 라인은 전혀 없습니다.
그날 오후, 저는 제 iPhone에서 프로토타입을 테스트했습니다. 'Tap Dumplings'를 누르자 → 5단계 체크 표시가 나타나고 → 'TestFlight용'으로 연결되었습니다. 시뮬레이션이었고, 명확하게 레이블링 되어 있었습니다. 작동했습니다. 제가 진행하라고 지시했습니다: Codemagic에 연결하고, 그것을 현실로 만드세요.
그리고 우리는 세 번 연속 실패했다
이것은 대부분의 빌드 이야기가 건너뛰는 부분입니다.
빌드 #1 실패. 빌드 #2 실패. 빌드 #3도 실패했습니다 — 모두 정확히 같은 단계에서요: App Store Connect API 키를 작성하는 단계였습니다.
키 자체는 존재했습니다. Codemagic에 저장되어 있었습니다. 다른 모든 곳에서는 작동했습니다. 하지만 빌드 내부에서, 키 파일은 비어 나왔고, 서명(signing) 단계가 그것을 거부했습니다.
빌드 #3에는 진단 기능이 추가되었고 마침내 원인을 밝혀냈습니다: Codemagic의 포털 통합은 실제 키를 빌드 스크립트에 전달하지 않습니다. 대신 **72자 길이의 참조 토큰(reference token)**을 전달하며, 이 토큰이 키를 가리킵니다. 만약 당신의 스크립트가 그 토큰을 마치 실제 키인 것처럼 처리하면, 빈 파일과 혼란스러운 오류가 발생합니다.
수정된 부분은 포털 자체에 있는 문제가 아니었습니다. 핵심은 키를 암호화된 환경 변수 그룹으로 옮기고 빌드 스크립트가 이를 우선하도록 만든 것이었습니다. 커밋을 한 번 더 거치자:
빌드 #4는 3분 만에 처음부터 끝까지 성공했습니다. 키 유효, 아카이브 서명 완료, 업로드까지 마쳤습니다. 10월 20일 오후 4시 43분(ET)에 Steamy Dumplings build 16이 App Store Connect에 VALID하게 안착했습니다.
집에는 Mac이 없습니다. GitHub 라인도 없습니다. 버튼 하나, 제가 소유하지 않은 클라우드 Mac만 있으면 됩니다. 그리고 Apple이 승인하는 빌드를 만들 수 있습니다.
우리가 의도적으로 배포하지 않은 것들
우리는 또한 더 급진적인 아이디어—아예 Mac 없이 리눅스 환경에서 오픈소스 Xcode 대체재를 이용해 구축하는 방법—에 대해서도 연구했습니다. 해당 프로젝트들은 공개적이고 실제 존재하지만, Apple의 라이선스는 iOS SDK 사용을 Apple 브랜드 하드웨어로 제한하기 때문에, 그 경로는 개발자 계정에 위험 요소(terms risk)가 따릅니다.
저는 제 앱들이 존재하는 계정을 실험을 위해 위험에 빠뜨릴 생각이 없습니다. 이 글에서 다루는 방법—당신의 iPhone이 전면에 있고, 합법적인 클라우드 Mac이 뒤에 있으며, Apple의 자체 Developer Program을 통해 연결하는 방식—이 가장 안전하고 반복 가능한 방법입니다. 제가 여기서 가르치려는 것이 바로 그것입니다.
다음 단계
iPhone 전면부는 같은 저녁에 최종 배선 작업을 마쳤습니다. 이제 트리거 키를 본체 내부에 안전하게 보관하는 방식으로 재구축했고, 그 후 제가 직접 버튼을 눌렀습니다. 앱은 모든 과정을
Patrick Hawkins는 AI를 창의적인 파트너로 삼아 코딩 배경 지식 없이 앱, 책, 제품을 만듭니다. 그는 여기서 실제 제작 과정, 실패 사례까지 글을 씁니다.