홈 · 가이드 · 앱 출시 완주

바이브코딩으로 만든 앱, 실제로 출시하기까지

주식회사 톡톡랩스 · 2026-08-04

AI에게 시켜서 앱을 만드는 일은 확실히 쉬워졌습니다. 그런데 실제로 스토어에 올라가 있고, 결제가 되고, 사람이 돈을 낼 수 있는 상태까지 간 앱은 그중 극히 일부입니다.

만드는 게 어려운 게 아니라, 통과하는 게 어렵기 때문입니다. 저희는 서로 다른 스택으로 두 개의 앱을 출시하면서 네 개의 관문을 지났습니다. 각 관문에서 실제로 무엇에 막혔는지 적었습니다.

관문 1 — 스토어 심사

심사 반려 메일은 무엇이 문제인지 정확히 알려주지 않습니다. 어느 조항인지, 어느 화면인지, 무엇을 고쳐야 재제출이 통과되는지를 찾아내는 게 작업의 대부분입니다.

의외로 코드 문제가 아닌 경우가 많습니다. 개인정보처리방침 문구, 데이터 안전 섹션에 신고한 내용과 실제 수집 항목의 불일치, 권한을 왜 쓰는지에 대한 설명 — 개발자 시야에서는 잘 안 보이는 곳에서 막힙니다.

관문 2 — 결제 연동과 PG 심사

결제는 코드를 붙인다고 끝나지 않습니다. PG 계약과 심사가 별도로 있고, 정기결제(빌링키)는 일반 결제와 또 다른 계약입니다.

또 하나. “본인인증 미계약” 오류는 코드 문제가 아니라 정기결제 미계약 증상입니다. 여기서 코드를 뜯어보면 며칠이 날아갑니다. 정기결제 전용 채널키를 받아 환경변수만 교체하면 끝납니다.

구조에서 반드시 지켜야 할 것도 있습니다.

• 멱등키 — 같은 주기에 두 번 청구되지 않도록 결제 요청에 고유 키를 붙입니다.
• 서버에서 사용자 검증 — 요청 본문에 담겨 온 사용자 식별자를 믿으면 안 됩니다. 남의 구독을 조회하거나 해지할 수 있게 됩니다.
• fail-closed — 웹훅 시크릿이 설정되지 않았으면 운영 환경에서 요청을 거부해야 합니다. 조용히 열리는 쪽이 훨씬 위험합니다.

관문 3 — 법적 요건

돈을 받으려면 통신판매업 신고가 필요합니다. 자동결제라면 약관에 갱신 조건과 해지 방법을 고지해야 하고, 취소·환불정책 페이지가 있어야 하며, 푸터에 통신판매업 번호가 노출돼야 합니다.

도메인에 따라 더 무거운 규제가 붙습니다. 저희가 아동 보상 기능을 설계할 때는 전자금융거래법이 문제였습니다. 앱 안에 지갑을 만들고 충전하거나 포인트를 사용자끼리 주고받게 하면 선불업·자금이동업에 해당하고, 등록 없이 운영하면 형사처벌 대상입니다. 그래서 앱이 자금을 보관하거나 중개하지 않는 구조로 다시 설계했습니다.

의료 정보를 다룰 때도 마찬가지입니다. AI가 의사처럼 보이면 안 되므로, 가상 캐릭터이며 실제 면허 의사가 아니라는 사실을 구조화 데이터와 이용약관 양쪽에 명시했습니다.

관문 4 — 실기기 호환성

내 폰에서 되는 것과 사용자 폰에서 되는 것은 다릅니다. 저희는 아이폰에서 앱 전체가 헤더만 뜨고 멈추는 문제를 겪었고, 원인이 두 개였습니다.

1. browserslist 미설정 — 빌드 도구가 최신 문법으로 번들을 출력하면서 구형 iOS Safari가 파싱에 실패했고, 자바스크립트 전체가 중단됐습니다.
2. 무거운 SDK가 클라이언트 번들에 유입 — SDK 내부의 lookbehind 정규식이 구형 Safari에서 문법 오류를 냈습니다. lookbehind는 트랜스파일로 낮출 수 없습니다. 런타임 문법이라 라이브러리 자체를 피하는 것 외에 방법이 없습니다.

여기서 나온 규칙은 하나입니다. 무거운 SDK를 클라이언트에서 직접 부르지 말고 서버 API를 경유하세요. 번들도 가벼워지고 키도 노출되지 않습니다.

디버깅에는 window.onerror를 잡아 화면에 그대로 띄우는 임시 코드가 결정적이었습니다. 아이폰은 콘솔을 보기 어렵기 때문입니다.

정리

네 관문 중 코드 실력이 필요한 건 사실 마지막 하나뿐입니다. 나머지 셋은 몰라서 막히는 것이고, 한 번 지나가 본 사람에게는 며칠이면 끝나는 일입니다.

직접 하실 거라면 이 글의 순서대로 점검해 보세요. 시간을 사고 싶으시면 저희가 대신 지나가 드립니다.