직장인 1인 개발, 앱 8개를 출시하며 배운 것들

첫 앱 출시까지의 여정을 쓴 지 1년 반이 지났습니다. 그때는 스토어에 앱 하나를 올리는 것조차 미지의 영역이었고, 목표는 “2주에 앱 하나”였습니다. 지금은 8개의 앱이 스토어에 올라가 있습니다. 목표한 속도에는 한참 못 미쳤지만, 대신 처음에는 상상하지 못했던 것들을 알게 됐습니다.

이 글은 성공기가 아닙니다. 수익은 아직 유지비를 겨우 따라가는 수준입니다. 대신 “앱을 만드는 일”과 “앱을 출시해서 유지하는 일”이 얼마나 다른 일인지에 대한 기록입니다.

만드는 시간보다 출시하는 시간이 길다

가장 크게 어긋난 예상이 이것이었습니다. 첫 앱 병 돌리기는 마음먹고 3시간 만에 동작하는 앱이 됐습니다. 그런데 그 앱이 실제로 스토어에 올라가기까지는 몇 주가 걸렸습니다. 사이에 있던 일들은 이렇습니다.

• 개발자 계정 등록과 사업자 정보 확인
• 앱 아이콘, 피처 그래픽, 스크린샷 여러 규격
• 개인정보처리방침 페이지(웹사이트가 필요합니다)
• 콘텐츠 등급 설문, 데이터 안전 섹션, 타깃 연령 선언
• 스토어 등록정보 문구, 그리고 심사 대기

코드가 아닌 작업이 대부분입니다. 그리고 이 목록은 앱 개수만큼 반복됩니다. 앱을 여덟 개 만들었다는 말은 이 절차를 여덟 번 밟았다는 뜻입니다. 두 번째부터는 빨라지지만 없어지지는 않습니다.

여기서 얻은 교훈은 단순합니다. 아이디어가 열 개 있을 때 열 개를 다 시작하면 출시는 하나도 못 합니다. 만드는 데 3시간이 걸리는 앱이라도 출시에는 며칠이 필요하다고 계산해야 계획이 맞습니다.

심사에서 막히는 건 대개 코드 문제가 아니다

가장 아팠던 반려는 반응속도 챌린지의 첫 심사였습니다. 사유는 “잘못된 개인정보처리방침”. 앱 코드에는 아무 문제가 없었습니다. 원인은 홈페이지 쪽이었습니다. GitHub Pages 설정이 어긋나 개인정보처리방침 페이지가 404를 내고 있었고, 심사자는 링크를 열어보고 반려한 것이었습니다.

앱 심사는 앱만 보지 않습니다. 개발자 계정 정보, 연결된 웹페이지, 스토어 문구까지 함께 봅니다. 앱 밖에 있는 것들이 앱을 막습니다. 출시 전에 스토어에 적어 넣은 모든 URL을 시크릿 창으로 직접 열어보는 습관이 생긴 계기였습니다.

두 번째로 많이 겪은 반려 사유는 로딩 속도와 외부 리소스였습니다. 웹 기반 앱을 배포할 때 폰트나 렌더링 엔진을 외부 CDN에서 받아오면, 심사 환경에서 그 요청이 막혀 첫 화면이 뜨지 않습니다. 내 컴퓨터에서 잘 되는 것과 심사 환경에서 잘 되는 것은 다른 문제입니다.

출시하고 나서야 진짜 일이 시작된다

출시는 끝이 아니라 유지보수의 시작점입니다. 스토어는 매년 대상 API 수준을 올리라고 요구합니다. 1년 전에 만든 앱을 그대로 두면 어느 날 “이 앱은 더 이상 새 사용자에게 노출되지 않습니다”라는 안내를 받습니다. 앱이 여덟 개라면 이 작업도 여덟 번입니다.

그래서 앱 개수를 늘리는 전략에는 숨은 비용이 있습니다. 앱 하나를 추가할 때 늘어나는 것은 개발 시간이 아니라 매년 반복되는 고정 작업량입니다. 저는 이 비용을 줄이기 위해 여러 앱이 같은 코드 베이스를 공유하도록 구조를 바꾸는 데 시간을 꽤 썼습니다. 게임 여러 개를 하나의 저장소에서 관리하고, 광고와 공유 기능처럼 모든 앱에 들어가는 부분은 공통 패키지로 묶었습니다. 앱 하나를 만드는 시간은 그대로지만, 여덟 개를 한 번에 업데이트할 수 있게 됐습니다.

플랫폼 하나에만 걸지 않기

올해 가장 잘한 선택은 앱인토스에 앱을 올린 것이었습니다. 토스 앱 안에서 설치 없이 실행되는 미니앱 플랫폼인데, 같은 웹 기반 코드를 거의 그대로 올릴 수 있었습니다. 스토어 검색으로 사람을 만나는 것과, 이미 사람이 모여 있는 앱 안에서 노출되는 것은 유입 성격이 완전히 다릅니다.

물론 플랫폼마다 심사 기준과 정책이 다르고, 그만큼 관리 대상도 늘어납니다. 다만 스토어 알고리즘 하나에 전부를 걸어두면 그 알고리즘이 바뀌는 날 할 수 있는 게 없습니다. 채널을 하나 더 두는 것은 노출을 두 배로 늘리는 일이라기보다, 없어지지 않을 최소한의 유입을 확보하는 일에 가깝습니다.

아이가 써주는 앱이 오래 남는다

만들 때 가장 재미있었고 지금도 계속 손이 가는 앱은 아이를 위해 만든 것들입니다. 한글 몬스터는 아이가 한글을 떼는 과정을 보다가, 수학 몬스터는 첫째가 연산을 지겨워하는 걸 보다가 만들었습니다. 실제 사용자가 옆에 있으니 피드백이 즉각적입니다. “이 버튼 안 눌려”라는 말을 듣고 고친 버그가 여러 개입니다.

반대로 아이디어만으로 만든 앱은 출시하고 나면 손이 잘 가지 않았습니다. 쓸 사람의 얼굴이 떠오르지 않으니 무엇을 고쳐야 할지도 떠오르지 않는 것이죠. 간호조무사 모의고사를 만들 때도 실제로 시험을 준비하는 사람을 떠올리며 문제 수와 오답 노트 구조를 정했는데, 그렇게 만든 기능은 나중에 봐도 이유가 분명했습니다.

다음 목표

“2주에 하나”라는 처음 목표는 폐기했습니다. 대신 기준을 두 개로 바꿨습니다. 하나는 내가 계속 손볼 마음이 생기는 앱만 만드는 것, 다른 하나는 앱 하나가 늘어날 때 고정 작업량이 늘지 않는 구조를 유지하는 것입니다.

다음 글에서는 앱인토스에 앱을 올리는 과정을 등록부터 심사까지 순서대로 정리해 보겠습니다. 국내 자료가 아직 많지 않아, 저처럼 처음 시도하는 분께 도움이 될 만한 부분이 꽤 있을 것 같습니다.

---

지금까지 출시한 앱은 Play 미니게임 3종, 사주로또, 주스 스피너 등 각 소개 글에 정리해 두었습니다. 소식은 인스타그램(@fadongkwon.soft)에서 전해드립니다.