AI에게 원하는 기능을 설명하고 오류 메시지를 보여주며 수정하다 보면 실제 스마트폰에서 작동하는 앱이 나온다. 처음 경험하면 꽤 놀랍다. 프로그래밍을 제대로 공부하지 않았어도 아이디어를 제품 형태로 만들어볼 수 있는 시대가 됐다.
나도 첫 안드로이드 앱 Visit Korea Helper를 출시할 때 기능을 만드는 속도에 먼저 놀랐다. 막상 Google Play에 올리려니 계정 등록, 테스터 모집, 개인정보처리방침, 스토어 자료, 심사가 차례로 기다리고 있었다. 앱 제작과 앱 출시는 서로 다른 일정으로 봐야 했다.
초보 바이브코더라면 코딩 도구를 고르기 전에 출시까지 필요한 돈과 시간, 사람을 먼저 계산하는 편이 낫다.
적은 돈으로 시작할 수 있지만 운영비는 기능이 결정한다
Google Play에 앱을 출시하려면 Play Console 개발자 계정이 필요하다. Google 공식 안내에 따르면 등록 수수료는 미화 25달러이며 한 번만 납부한다. 여기에 유료 AI 서비스 구독료, 도메인이나 호스팅 비용이 추가될 수 있다.
서버가 필요한 앱은 Firebase 같은 서비스를 이용할 수 있다. Firebase의 Spark 요금제는 결제 수단 없이 시작할 수 있고 Analytics, Crashlytics, Cloud Messaging 등 여러 기능을 무료로 제공한다. 초기 사용자가 적고 무료 할당량 안에서 움직이는 앱이라면 서버 비용 없이 운영할 수도 있다.
비용은 기능을 추가할 때 늘어난다. 지도 API 호출, AI API, 사진·동영상 저장, 문자 인증은 사용량이 늘수록 월 운영비가 생긴다. 두 번째 앱인 가계부 ‘돈기록장’을 만들 때 자연어 입력에 AI를 붙였다가 서버와 API 비용, 운영 부담을 고려해 첫날 제거했다. 간단한 파서로 충분한 문제에 유료 AI를 유지할 이유가 없었다.
개발을 시작하기 전에 AI에 다음 질문을 던져보면 비용 구조를 빠르게 확인할 수 있다.
이 앱을 운영할 때 발생할 수 있는 비용을 초기 비용과 월 운영비로 나누어 알려줘. 무료 구간이 끝나는 조건과 사용량이 늘 때 비용이 급증할 기능도 표시해줘.
AI의 계산은 출발점으로만 쓰고, 실제 가격과 무료 할당량은 서비스의 공식 요금표에서 다시 확인해야 한다.
개발 완료일과 Google Play 출시일은 같지 않다
바이브코딩의 장점은 개발 속도다. 간단한 앱은 며칠 안에 기본 기능이 나오고, 몇 주를 투자하면 제법 쓸 만한 형태가 된다. 출시 준비에는 별도의 시간이 들어간다.
| 단계 | 초보자 기준 예상 기간 |
|---|---|
| 아이디어와 핵심 기능 정리 | 1~3일 |
| 기본 앱 제작 | 며칠~2주 |
| 기능 보완과 오류 수정 | 1~2주 이상 |
| 실제 스마트폰 테스트 | 수일 이상 |
| 아이콘·스크린샷·스토어 설명 준비 | 1~3일 |
| 필수 비공개 테스트 | 최소 14일 |
| 프로덕션 액세스 신청과 검토 | 일반적으로 7일 이내, 더 길어질 수 있음 |
| 출시 후 오류 수정과 업데이트 | 계속 |
앱의 난이도에 따라 기간은 크게 달라진다. 핵심은 개발 완료일에 맞춰 출시일을 잡지 않는 것이다. 첫 계정과 첫 앱이라면 테스터 모집과 비공개 테스트만으로도 최소 2주가 필요하다.
기능 제작에 일주일을 예상했다면 테스트와 수정까지 포함해 두 배 정도의 여유를 두는 편이 현실적이다. 출시 일정을 먼저 정해야 한다면 스토어 자료 준비와 테스트 기간부터 역산해야 한다.
12명의 테스터는 AI가 대신 구해주지 못한다
2023년 11월 13일 이후 생성된 Google Play 개인 개발자 계정에는 프로덕션 출시 전 테스트 요구사항이 적용된다. 현재 Google 공식 기준은 최소 12명의 테스터가 비공개 테스트 참여를 선택한 상태를 14일 연속 유지하는 것이다. 기준을 채운 뒤 프로덕션 액세스를 신청할 수 있다.
앱은 AI와 함께 혼자 만들 수 있지만 테스터는 실제 사람이 필요하다. 가족이나 친구에게 설치 링크를 보내는 것으로 끝나지도 않는다. 참여 선택 방법, 설치 절차, 확인할 기능, 피드백 전달 방법을 함께 안내해야 한다. 누군가 중간에 참여를 취소해 12명 아래로 내려가면 일정이 밀릴 수 있다.
테스터 모집은 앱 완성 뒤가 아니라 개발을 시작할 때 준비하는 편이 낫다. 테스트 중에는 다음 내용을 남겨둔다.
- 어떤 기능을 확인해달라고 요청했는가
- 어떤 기기와 Android 버전에서 테스트했는가
- 어떤 오류와 불편이 제보됐는가
- 피드백을 반영해 무엇을 바꿨는가
- 아직 해결하지 못한 문제는 무엇인가
14일이 지나면 자동으로 출시되는 구조가 아니다. 프로덕션 액세스 신청 때 테스트 과정과 피드백, 앱 개선 내용을 설명해야 한다. 테스트 기록은 심사 답변을 만들 때 그대로 쓸 수 있다.
Play Console은 앱 파일보다 많은 것을 요구한다
앱 번들을 올리고 제목과 설명을 쓰면 끝날 것 같지만 Play Console에서 준비할 항목은 훨씬 많다.
- 앱 이름, 짧은 설명, 상세 설명
- 앱 아이콘과 휴대전화용 스크린샷
- 앱 카테고리와 연락처
- 광고 포함 여부
- 연령과 콘텐츠 등급
- 데이터 보안 항목
- 개인정보처리방침
- 테스트 안내와 프로덕션 액세스 신청 답변
데이터 보안 항목은 초보자가 자주 막히는 부분이다. 앱에서 회원정보를 직접 받지 않아도 Firebase Analytics, Crashlytics, 광고 SDK가 데이터를 처리할 수 있다. 앱 기능뿐 아니라 포함된 SDK의 데이터 수집·전송 방식까지 확인해야 한다.
AI에는 사용 중인 SDK 목록과 Play Console 질문을 함께 보여주고 선택 항목의 근거를 설명하게 할 수 있다. 최종 답변은 각 SDK의 공식 문서와 실제 앱 설정을 기준으로 결정해야 한다. 개인정보처리방침도 AI가 만든 초안을 그대로 공개하지 말고 앱의 실제 수집 항목, 보관 방식, 삭제 방법과 일치하는지 대조한다.
스토어 등록 자료는 개발 중에 미리 모으면 부담이 줄어든다. 기능이 안정될 때마다 스크린샷 후보를 저장하고, 아이콘과 짧은 소개문을 일찍 정해두면 앱 완성 후의 자잘한 작업이 줄어든다.
기능을 추가할수록 수정 시간이 길어진다
바이브코딩 초반에는 화면과 기능이 빠르게 생긴다. 어느 순간부터 새 기능보다 기존 기능을 고치는 시간이 더 길어진다.
A 기능을 고친 뒤 B 기능이 멈추고, UI를 수정했더니 작은 화면에서 버튼이 잘릴 수 있다. 테스트 빌드에서는 됐던 기능이 배포용 빌드에서 실패하기도 한다. 앱을 다시 설치했더니 로컬 데이터가 사라지고, 최신 스마트폰에서는 정상이지만 오래된 Android 기기에서 오류가 날 수도 있다.
수정할 때는 AI에 오류 메시지만 던지기보다 재현 순서와 기대 결과를 함께 전달하는 편이 낫다. 한 번에 여러 파일을 바꾸게 하기보다 변경 범위를 좁히고, 수정 전후에 핵심 기능을 다시 확인한다. 작동하는 버전은 별도 브랜치나 태그로 남겨두면 AI가 새로운 오류를 만들었을 때 되돌아가기 쉽다.
AI는 때때로 “문제를 완전히 해결했다”고 답하고 같은 오류를 남긴다. Google Play 정책과 Android 권한처럼 자주 바뀌는 내용에는 오래된 답을 내놓을 수도 있다. 비용, 정책, 출시 조건은 공식 문서를 다시 확인하고, 코드 수정은 실제 기기와 배포용 빌드로 검증해야 한다.
첫 앱의 목표는 수익보다 출시 경험이 낫다
앱을 Google Play에 등록해도 사용자가 저절로 생기지는 않는다. 발견되는 과정과 설치 후 계속 쓰게 만드는 과정은 개발과 또 다른 일이다. 사용자 수가 적으면 광고를 붙여도 수익은 작다.
첫 앱의 목표를 “내 아이디어를 실제 앱으로 만들어 Google Play에 출시하고 한 번 업데이트한다”로 잡으면 얻는 것이 분명해진다. 아이디어 선정, 개발, 테스트, 스토어 등록, 심사, 출시, 업데이트를 한 바퀴 경험하는 것이다.
두 번째 앱부터는 Play Console이 덜 낯설고 준비할 자료도 예상할 수 있다. 세 번째 앱 VibeTerms를 출시할 때는 1,000개 용어와 40개 시나리오를 정리하고 3개 언어를 적용하면서 여덟 차례 테스트를 거쳤다. 첫 앱에서 겪은 과정이 있었기에 개발과 검증을 더 구체적으로 나눌 수 있었다.
첫 앱을 시작하기 전에는 다음 항목만 확인해도 큰 시행착오를 줄일 수 있다.
- 핵심 기능을 한 문장으로 설명할 수 있는가
- 초기 비용과 월 운영비를 나눠 계산했는가
- 테스터 12명을 미리 구할 수 있는가
- 테스트와 수정에 개발 기간만큼의 여유를 뒀는가
- 사용 중인 SDK와 데이터 수집 항목을 알고 있는가
- 아이콘, 스크린샷, 소개문, 개인정보처리방침을 준비했는가
- 출시 뒤 첫 업데이트까지 할 시간을 확보했는가
처음부터 거창한 앱을 고를 필요는 없다. 기능을 줄여서라도 끝까지 출시할 수 있는 작은 앱이 낫다. 첫 목표는 작동하는 화면을 만드는 데서 끝나지 않는다. Google Play에 공개하고 첫 업데이트까지 마치는 경험이 다음 앱을 만드는 가장 실용적인 교재가 된다.
Google Play 계정·테스트 정책과 비용 관련 내용은 2026년 8월 28일 공식 도움말 확인 기준이다. 정책과 요금은 바뀔 수 있으므로 실제 출시 전 다시 확인해야 한다.