앱 스토어가 승인했습니다
두 주 전에 "여전히 만들고 있습니다. 여전히 끝나지 않았습니다"라고 썼습니다. 오늘 DIALØGUE(다이얼로그)가 App Store에 출시되었습니다. 마지막 40%가 실제로 어떤 모습이었는지 이야기해드릴게요.
두 주 전, 저는 블로그 포스트를 이렇게 마무리했습니다: "여전히 만들고 있습니다. 여전히 끝나지 않았습니다. 여전히 딸에게 무엇을 말해야 할지 고민하고 있습니다."
앱이 App Store에 올라가면 — 아니면 거부당하면 — 후속 글을 쓰겠다고 했습니다. 거부 이야기가 더 흥미로울 수도 있다고도 했죠.
DIALØGUE(다이얼로그) - AI Podcast Studio가 App Store에 출시되었습니다 — Swift를 한 번도 써본 적 없는 사람이 Claude Code로 만든, 어떤 주제나 PDF를 완전히 제작된 팟캐스트 에피소드로 바꿔주는 네이티브 SwiftUI iOS 앱입니다. 지금 바로 다운로드할 수 있어요.
단, 처음 시도에서 통과된 건 아닙니다. 솔직히 말하면 — 거부 이야기가 승인 이야기보다 더 흥미로울 것 같다고 예측했는데, 맞았습니다.
Apple이 첫 제출을 거부했을 때 무슨 일이 있었나?
첫 번째 제출이 거부당했습니다. 가이드라인 2.1 — 성능: 앱 완성도. 인앱 구매가 작동하지 않았거든요.
Apple의 리뷰 메시지는 정중했습니다 — 첫 제출이라는 걸 알아차리고, 개발자 프로그램 가입을 축하하며, 문제를 명확하게 설명해줬습니다. IAP 상품이 리뷰어가 구매를 시도할 때 오류를 던졌다는 거였죠.
사실 구매 플로우는 제 테스트에서는 완벽하게 작동했습니다. 문제는 Apple의 샌드박스 환경에 있었는데, 이게 개발 환경과 프로덕션 환경 모두와 다르게 동작합니다. StoreKit 설정이 App Store Connect와 정확히 동기화되어야 하는데, 제 건 그렇지 않았어요. 저는 로컬 StoreKit 설정 파일로 테스트하고 있었는데, 리뷰어는 실제 샌드박스를 사용하고 있었던 거죠.
같은 날 바로 수정해서 재제출했고, 통과됐습니다. 그 후 v1.0.1 버그 수정 업데이트도 잘 통과됐고요.
총 세 번의 제출. 한 번의 거부. 거부 경험이 두 번의 승인보다 App Store 프로세스에 대해 더 많은 것을 가르쳐줬습니다. 이게 패턴이죠, 그렇지 않나요? 실패가 항상 성공보다 더 많은 걸 가르쳐줍니다.
"마지막 40%"는 실제로 어떤 모습이었나?
이전 포스트에서 AI가 60%까지 데려다주고, 나머지 40%는 전적으로 인간의 작업이라고 했습니다. 이제 git 로그로 증명할 수 있으니 좀 더 구체적으로 이야기하고 싶어요.
16개의 커밋. 57개의 파일 변경. 4,886줄 추가. 앱은 Swift 파일 69개에서 88개로, 7,568줄에서 11,459줄로 늘었습니다. 거의 4,000줄의 "다듬기"죠.
이 16개의 커밋에 실제로 무엇이 담겼는지 — 대략 일어난 순서대로 — 이야기해드릴게요.
처음부터 있었어야 할 테스트 코드
원래 스캐폴드에는 테스트가 하나도 없었습니다. 하나도요. Claude가 프로덕션 코드 69개 파일을 만들었지만 테스트는 단 하나도 없었어요. 이전 포스트 이후 첫 번째 실질적인 커밋에서 유닛 테스트 176개와 로컬 Supabase 인스턴스에 대한 통합 테스트 19개를 추가했습니다.
테스트를 작성하자마자 실제 버그들이 잡혔습니다: 존재하지 않는 데이터베이스 컬럼 때문에 생기는 Show 모델 디코딩 실패, 트랙 끝에서 재설정되지 않는 AudioPlayer, 라이브러리 리로드 경쟁 조건, 생성 위자드에서 nil UUID 가드 누락. 이것들 하나하나가 프로덕션에서 크래시로 이어졌을 것입니다.
이건 이름 붙일 만한 패턴이라고 생각합니다: AI는 테스트 인프라 없이 코드를 생성합니다. 테스트를 못 쓰기 때문이 아니라 — Claude는 요청하면 테스트를 잘 작성합니다 — 초기 스캐폴드 프롬프트는 항상 "앱을 만들어줘"지, "포괄적인 테스트를 갖춘 앱을 만들어줘"가 아니기 때문입니다. 테스트를 추가한 건 테스트 없이는 출시하기 불편하다는 제 판단에서 나온 것이었습니다.
겨우 스텁만 있던 Studio 기능
원래 "Studio" 기능(반복 쇼를 위한)은 플레이스홀더에 불과했습니다. 두 번의 커밋 후에야 진짜 제품이 됐습니다: 템플릿 그리드가 있는 쇼 생성, 상태 배지와 액션 버튼이 있는 에피소드 관리, 편집/삭제 워크플로우, 타임존 피커가 있는 스케줄 설정, 음성 커스터마이징 시트.
그다음 Studio Phase 2가 왔습니다: 쇼 상세 화면 재설계, 에피소드별 재시도/삭제, 크레딧 확인이 있는 수동 에피소드 생성. 거기다 전체 플로우를 검증하는 새 XCUITest 8개도 추가했어요.
이게 제가 "AI가 제품이 아닌 코드베이스를 만들었다"고 했을 때 의미했던 것입니다. Studio 기능은 컴파일됐습니다. 화면을 렌더링했습니다. 하지만 실제로 반복 팟캐스트 쇼를 관리할 수는 없었어요.
오디오 플레이어 재구상
이전 포스트에서 미니 플레이어를 삭제했다고 했었는데, 사실 틀렸습니다 — 결국 더 나은 미니 플레이어를 만들게 됐거든요. 최종 디자인은 탭 바 위에 진행 상황, 건너뛰기 컨트롤, 재생/일시정지가 있는 영구 미니 플레이어 바를 배치했습니다. 탭하면 탐색 가능한 슬라이더, 속도 선택기(0.5x~2x), 이동 컨트롤, 사운드링 아트워크 애니메이션이 있는 확장된 "Now Playing" 시트가 펼쳐집니다.
까다로운 부분은 isSeeking 상태였습니다 — 이게 없으면 슬라이더 위치와 오디오 옵저버가 서로 싸워서 버벅거리는 난장판이 됩니다. 진단하는 데 한 시간이 걸린 한 줄짜리 상태였습니다.
오프라인 다운로드도 주변 UX와 함께 추가했습니다: 라이브러리에서 다운로드된 에피소드에 초록 아이콘, 완료 토스트 알림, Now Playing의 "Downloaded" 레이블, 스와이프로 다운로드 삭제. DownloadManager에는 URLSession 델리게이트에서 임시 파일 경쟁 조건이 있어 조용한 실패를 일으켰습니다 — 콜백 내부에서 동기적으로 파일을 이동하는 것이 수정 방법이었어요. 코드 리뷰에서 잡히는 종류의 버그가 아닙니다.
모든 레이어에 걸친 보안 강화
이건 좀 충격적이었습니다. 전체 스택 — iOS 앱만이 아니라 — 에 대한 보안 감사에서 여러 레이어에 걸쳐 취약점이 드러났습니다: 과도한 권한이 부여된 데이터베이스 함수, 인증 엣지 케이스, 토큰 검증 허점, 여러 백엔드 서비스의 입력 유효성 검사 문제.
이것들은 iOS Swift 코드에 있는 게 아니었습니다. iOS 앱이 통신하는 백엔드에 있었어요. 하지만 iOS 앱을 출시한다는 건 전체 스택이 이제 사용자의 주머니 속에 들어간다는 뜻입니다. 그게 모든 것의 판돈을 높였습니다. 웹 앱에서는 "잘 작동"하던 코드가 Apple의 리뷰 프로세스를 거치고 사람들이 들고 다니는 네이티브 앱에 들어가는 순간 용납할 수 없게 느껴졌습니다.
StoreKit: 제출을 막아버린 문제
StoreKit 샌드박스 테스팅은 그 자체로 완전히 다른 세계이고, 바로 그게 첫 제출을 거부당하게 만든 원인이었습니다. 샌드박스 환경은 프로덕션과 다르게 동작합니다. 트랜잭션이 영원히 "pending" 상태에 머무르기도 합니다. Xcode StoreKit 설정 파일은 수동으로 동기화해야 합니다. 코드에서는 완벽하게 작동하는데 샌드박스에서는 조용히 실패하는 구매 플로우를 디버깅하는 데 저녁 한 나절을 썼습니다 — 알고 보니 App Store Connect의 상품 ID에 후행 공백이 하나 있었던 거예요. 공백 하나.
Apple 리뷰어는 제 StoreKit 설정이 App Store Connect와 동기화되지 않아서 샌드박스 오류를 만났습니다. 제 로컬 테스트에서는 구매 플로우가 잘 됐는데 — 리뷰어는 제 로컬 StoreKit 설정 파일이 아닌 실제 샌드박스를 사용하고 있었으니까요. 같은 날 수정했지만, 이게 "내 컴퓨터에서는 작동"과 "Apple 환경에서는 작동"의 간극이 얼마나 크게 벌어질 수 있는지를 완벽하게 보여주는 사례입니다.
구매 검증 체인은 그 자체가 하나의 프로젝트였습니다: iOS 앱이 트랜잭션의 JWS(JSON Web Signature) 표현을 서버 측 함수로 보내면, 이 함수가 Apple의 서명된 영수증에 대해 완전한 암호화 체인 검증을 수행합니다. 단순 디코딩이 아닙니다 — 실제 서명 유효성 검사입니다. 이걸 제대로 잡는 데 전용 커밋 두 개가 필요했습니다.
개인정보 보호와 App Store 컴플라이언스
개인정보 보호와 컴플라이언스는 법적 의미가 있는 양식, 결정, 체크박스들입니다 — AI가 대신 채워줄 수 없어요. 앱 추적 투명성 선언, 개인정보 보호 영양 레이블, 암호화에 대한 수출 컴플라이언스(맞습니다, HTTPS도 해당됩니다), 콘텐츠 저작권, Turnstile 캡챠 통합. Claude Code는 Swift를 쓸 수 있지만, 제 데이터 수집 관행이 "사용자를 추적하는 데 사용된 데이터" 레이블을 필요로 하는지는 알려줄 수 없습니다.
완전한 MFA와 현지화
원래 MFA 구현은 깨진 스텁이었습니다 — 빈 팩터 ID, 검증만 하는 플로우. 완전한 TOTP 생명주기로 다시 작성했습니다: 등록, QR 코드 스캔(네이티브 CoreImage 생성), 검증, 상태 확인, 비활성화. 그 전에는 존재하지 않았던 394줄짜리 MFAView.swift입니다.
7개 언어 현지화는 영어, 스페인어, 프랑스어, 일본어, 한국어, 베트남어, 중국어로 번역된 253개의 UI 문자열을 의미합니다. Claude가 번역했고, 대부분은 괜찮았습니다. 하지만 일본어에서 "대부분 괜찮다"는 건 문법적으로는 맞지만 로봇이 쓴 것처럼 들리는 버튼 레이블이 있을 수 있다는 뜻입니다. 전화기 언어를 바꿔서 실제로 앱을 사용해보다가 그런 것들을 여럿 발견했습니다. 이런 종류의 테스트는 AI가 아직 해줄 수 없는 것입니다.
DIALØGUE iOS 앱으로 무엇을 할 수 있나?
원래 빌드 스토리를 읽지 않으신 분들을 위해 DIALØGUE(다이얼로그)가 뭘 하는지 간단히 설명하면:
주제를 입력하거나 PDF를 업로드하면, 완전히 리서치되고 스크립트화되고 음성이 입혀진 팟캐스트 에피소드를 만들어냅니다. 두 명의 AI 호스트가 실제 리서치를 바탕으로 주제에 대해 자연스러운 대화를 나눕니다. 마이크가 필요 없어요.
iOS 앱에는 이런 기능이 있습니다:
- 5단계 생성 위자드 — 주제, 포맷, 커스터마이징, 아웃라인 검토, 스크립트 검토
- 7개 언어 30개의 AI 음성 — 영어, 스페인어, 프랑스어, 일본어, 한국어, 베트남어, 중국어
- 9가지 팟캐스트 포맷 — 테크 뉴스 분석부터 탐사 코미디까지
- 잠금 화면 컨트롤이 있는 오디오 재생 — 백그라운드 재생이 그냥 작동합니다
- Apple Sign-In, Google OAuth, 이메일 인증
- 인앱 구매 — 구독 없는 크레딧 방식: 크레딧 4개 $4.99, 9개 $9.99, 18개 $19.99
- Studio — 자동으로 새 에피소드를 생성하는 반복 쇼 설정
- PDF 업로드 — 논문, 보고서, 책을 소스 자료로 활용
진짜 네이티브 SwiftUI 앱입니다. 웹 래퍼가 아닙니다. React Native가 아닙니다. Swift 파일 69개로 시작해서 이제 88개 파일에 11,459줄, 테스트 195개를 갖추고 있습니다. 출시하게 되어 진심으로 뿌듯합니다.
원래 "다듬기 단계" 예상이 얼마나 틀렸나?
앱이 "아직 개발 중이고, 마지막 다듬기 단계에 있다"고 썼었습니다. 기술적으로는 맞았지만, "다듬기 단계"의 많은 부분이 실제로는 새로운 작업이었다는 걸 과소평가했습니다.
지금 git 로그를 보니, 16개의 커밋은 "다듬기"처럼 들리지 않습니다. 두 번째 개발 단계처럼 들립니다. 테스트 코드만 해도 — 유닛 테스트 176개와 통합 테스트 19개 — 하나의 완전한 프로젝트였습니다. Studio는 스텁에서 완전한 기능으로 성장했습니다. 오디오 플레이어는 두 번 재구상됐습니다. 보안 강화는 백엔드 함수 40개 이상을 건드렸습니다. MFA는 처음부터 다시 작성됐습니다.
미니 플레이어를 삭제했다고도 했는데, 그것도 틀렸습니다 — 결국 더 나은 것을 만들었어요, Now Playing 시트, 속도 컨트롤, 다운로드 인디케이터까지 갖춘. "삭제하자"는 원래의 직감은 맞았습니다 — 첫 번째 미니 플레이어는 나빴으니까요. 하지만 개념 자체는 맞았습니다. 제대로 만들기만 하면 되는 것이었습니다.
전체 그림을 볼 수 있는 지금, 솔직한 비율을 이야기하자면: AI가 기반을 만들고(60%), 사람이 제품을 만들고(30%), App Store 제출 과정이 나머지 10%를 가르쳐준다는 것입니다.
DIALØGUE는 EU에서 이용 가능한가?
DIALØGUE(다이얼로그)는 전 세계적으로 이용 가능하지만, EU 가용성은 아직 Apple이 처리 중입니다. EU의 디지털 시장법(Digital Markets Act)은 추가 컴플라이언스 단계를 요구합니다 — 대체 결제 공개, 특정 개인정보 보호 문서, 사업자 등록 세부 사항. 모든 서류를 제출했고, Apple이 지금 검토 중입니다. 곧 EU 국가에서도 이용 가능해질 것입니다.
EU에 계시고 기다리기 어려우시면, 웹 앱이 어디서나 작동하며 동일한 기능을 제공합니다.
AI 지원 iOS 개발은 얼마나 빠른가?
DIALØGUE iOS 앱은 첫 번째 커밋부터 App Store 승인까지 약 두 주가 걸렸습니다 — AI 스캐폴딩은 저녁 한 나절, 그 후 두 주의 인간 제품 작업. 계속 이 표를 유지하고 있는데, 배우는 게 계속 생기기 때문입니다:
| 프로젝트 | 복잡도 | 개발 기간 |
|---|---|---|
| DIALØGUE v1 | MVP 팟캐스트 생성기 | ~6개월 |
| STRAŦUM | 10개 AI 에이전트, 11개 프레임워크, 멀티테넌트 | 75일 |
| 사이트 리디자인 | WordPress 프론트엔드 전면 개편 | 3일 |
| DIALØGUE v2 | 웹 앱 완전 재구축 | 14일 |
| 블로그 마이그레이션 | WordPress → Next.js, 490개 포스트, Sydney RAG | 4일 |
| DIALØGUE iOS | 네이티브 iOS 앱, Swift 첫 사용 | ~2주 (스캐폴드: 저녁 한 나절) |
DIALØGUE iOS의 스캐폴드에서 출시까지의 간격은 약 두 주였습니다. 스캐폴드 자체는 저녁 한 나절. 그 비율 — AI 작업 저녁 한 나절, 인간 작업 두 주 — 이 지금 AI 지원 개발이 어디에 있는지를 말해줍니다.
AI 부분은 계속 빨라지고 있습니다. 인간 부분은 대략 그대로입니다. 두 주 전에 썼고, 여전히 사실입니다.
AI가 코드를 만들 때 어떤 기술이 중요한가?
이전 포스트에서 저는 아직 딱 맞는 조언을 찾고 있었습니다. "시뮬레이터를 여는 사람이 되어라"가 제가 내놓을 수 있는 최선이었습니다.
이제 실제로 출시해봤으니, 좀 더 구체적으로 말할 수 있을 것 같습니다.
이 앱이 존재할 수 있었던 것은 AI가 할 수 없었던 세 가지 덕분입니다:
-
제품을 사용했습니다. 테스트가 아니라 사용했습니다. 팟캐스트를 만들었습니다. 출퇴근길에 들었습니다. 아웃라인 검토 화면에 리서치 출처가 표시되어야 한다는 걸 깨달았습니다 — 사실이 어디서 왔는지 알고 싶었으니까요.
-
정답이 없는 판단을 내렸습니다. 미니 플레이어를 삭제할까, 유지할까? 생성 위자드에서 커스터마이징이 너무 많은 건 어느 선일까? Studio 기능이 탭이어야 할까, 섹션이어야 할까? 이건 엔지니어링 결정이 아닙니다. 취향의 결정입니다. 그리고 취향은 많은 제품을 사용하면서 — 훌륭한 것과 끔찍한 것 모두 — 무엇이 맞게 느껴지는지에 대한 감각을 발달시킴으로써 생깁니다.
-
인간을 위해 설계된 시스템을 헤쳐나갔습니다. App Store Connect, 개인정보 보호 선언, 수출 컴플라이언스, 스크린샷 요구사항 — 이것들은 자동화할 수 없습니다. 읽고, 맥락을 이해하고, 법적·비즈니스적 의미에 대한 판단을 내려야 합니다. 복잡한 인간 시스템을 헤쳐나가는 그 기술은 사라지지 않을 것입니다.
그러니 업데이트된 조언은 이렇습니다: 제품을 깊이 사용하는 법을 배우고, 품질에 신경 씀으로써 취향을 기르고, 단순하게 설계되지 않은 시스템을 헤쳐나가는 것을 편안하게 느끼도록 하세요.
"비판적으로 생각하는 법을 배워라"보다 더 구체적입니다. 진실에 더 가깝다고 생각합니다. 그게 충분한지는 여전히 확신하지 못하겠습니다.
DIALØGUE는 어떻게 다운로드하나?
앱은 무료이고 인앱 크레딧 구매 방식입니다. 구독은 없습니다.
전 세계에서 이용 가능합니다 — EU 가용성은 Apple이 처리 중이며 곧 출시될 예정입니다. 웹 앱은 어디서나 이용 가능합니다.
자주 묻는 질문
DIALØGUE(다이얼로그)는 App Store에서 이용 가능한가?
네! DIALØGUE - AI Podcast Studio가 2026년 3월부터 App Store에 출시됐습니다. 무료 다운로드이고 인앱 크레딧 구매 방식입니다(크레딧 4개 $4.99, 9개 $9.99, 18개 $19.99). 전 세계에서 이용 가능합니다 — EU 가용성은 제출됐고 Apple이 처리 중입니다.
EU에서도 이용 가능한가?
제출됐고 Apple이 처리 중입니다. EU의 디지털 시장법이 추가 컴플라이언스 단계를 요구해서 서류 작업을 완료했고, Apple 검토를 기다리고 있습니다. 곧 이용 가능해질 것입니다. 그동안 웹 앱은 EU를 포함해 어디서나 작동합니다.
Apple이 거부했나?
네 — 첫 번째 제출은 인앱 구매 오류로 거부됐습니다(가이드라인 2.1: 앱 완성도). StoreKit 샌드박스 설정이 App Store Connect와 동기화되지 않아서 검토 중에 구매에서 오류가 발생했습니다. 같은 날 수정해서 재제출했고 통과됐습니다. v1.0.1도 통과됐고요. 총 세 번의 제출, 한 번의 거부. 거부가 두 번의 승인보다 더 많은 것을 가르쳐줬습니다.
전체 과정이 얼마나 걸렸나?
원래 블로그 포스트부터 App Store 승인까지 약 두 주. Claude Code가 저녁 한 나절에 Swift 파일 69개를 스캐폴딩했습니다. 나머지 16개의 커밋이 57개 파일에 걸쳐 4,886줄을 추가했습니다 — 테스트, Studio 기능, 오디오 플레이어 재설계, MFA 재작성, 보안 강화, StoreKit 검증, 현지화, App Store 제출 과정이 포함됩니다. 최종적으로 파일 88개, 11,459줄, 테스트 195개를 갖추고 출시됐습니다.
마지막 40%에서 가장 어려운 부분은 무엇이었나?
StoreKit 샌드박스 테스팅이었습니다. "코드에서 작동"과 "Apple의 트랜잭션 시스템에서 작동" 사이의 간극은 어마어마합니다. 샌드박스 트랜잭션은 프로덕션과 다르게 동작하고, 상품 ID는 정확히 일치해야 하며(후행 공백까지), 피드백 루프가 느립니다 — 유닛 테스트만 돌릴 수 없습니다.
웹 앱은 여전히 사용 가능한가?
물론입니다. podcast.chandlernguyen.com은 동일한 기능을 갖추고 있고 모든 기기에서 작동합니다. iOS 앱에는 Apple Sign-In, 잠금 화면 컨트롤, 오프라인 다운로드 같은 네이티브 편의 기능이 있지만, 핵심 팟캐스트 생성 경험은 동일합니다.
여전히 딸에게 무엇을 말해야 할지 고민하고 있습니다. 하지만 적어도 이제 "인간의 작업이 어려운 부분"이라고 말할 때 가리킬 수 있는 출시된 앱이 생겼습니다.
감사합니다, Chandler








