룸톤 Roomtone TIL 11
정리해 보자고 했는데 올라가 있는 게 없었다
앱스토어에 내기까지 뭐가 남았는지 마일스톤으로 정리해 보자고 했다. 목록을 만들려면 지금 어디까지 왔는지부터 알아야 하니 상태를 훑었는데, 클라우드에 데이터베이스도 파일 저장소도 서버도 하나 없었다.
두 달 넘게 만들었고 그동안 앱은 잘 돌았다. 노트북에서 서버를 띄우면 로그인이 되고 곡이 흘렀으니 다 된 줄 알았다. 그런데 그건 wrangler(Cloudflare를 다루는 명령줄 도구)의 로컬 개발 모드가 클라우드 서비스를 노트북 안에서 흉내 내고 있었던 것이다. 곡 7GB도 그 안에만 있었다.
로컬에서 돌아가는 것과 남이 접속할 수 있는 것 사이에는 통째로 한 단계가 있다. 그 단계는 기능이 아니라서 만드는 동안 한 번도 부딪히지 않고, 그래서 다 됐다고 착각하기 쉽다. 첫 고객을 받기까지의 일정을 짤 때 이 단계를 항목으로 세워 두지 않으면 없는 셈이 된다.
정리를 시켜 보길 잘했다. 물어보지 않았으면 스토어 제출 직전에 알았을 것이다.
검수 방식을 바꿨더니 병목이 저절로 빠졌다
지난주에 제일 큰 걸림돌은 곡이었다. 검수를 기다리는 곡이 442개였고 하나에 1분씩 걸렸다. 곡 수는 줄일 수 없는 숫자라 답이 없어 보였다.
줄일 수 있는 건 곡당 걸리는 시간이었다. 1초 듣고 2초 건너뛰기를 곡 끝까지 반복하는 훑어듣기를 붙였다. 4분짜리가 80초에 끝나고, 판정을 숫자키로 눌러 바로 다음 곡으로 넘어간다.
일주일 뒤 결과가 나왔다. 442곡이 15곡이 됐다. 오늘 마일스톤을 정리하려고 세어 보기 전까지는 그렇게 줄어든 줄도 몰랐다.
여기서 두 가지를 가져간다. 하나는 막힌 일을 볼 때 「일이 몇 개인가」와 「하나에 얼마나 걸리는가」를 나눠 봐야 한다는 것이다. 앞엣것이 못 줄이는 숫자여도 뒤엣것은 대개 줄일 수 있고, 곱해지는 값이라 효과가 크다. 다른 하나는 병목이 옮겨 다닌다는 것이다. 지난주 1순위가 오늘은 목록 끝에 있었다. 순서를 정하기 전에 다시 세지 않으면 이미 끝난 일을 계속 1순위로 붙들게 된다.
쓰려던 주소를 남이 이미 갖고 있었다
Cloudflare Pages(정적 사이트와 서버 코드를 함께 올리는 호스팅)에 배포하면 프로젝트 이름을 그대로 쓴 기본 주소가 따라온다. 그런데 우리가 쓰려던 이름을 열어 보니 동명의 한국어 일기 앱이 이미 서비스 중이었다.
이 기본 주소는 내 계정 안에서 고유한 게 아니라 그 서비스를 쓰는 전 세계에서 이름이 하나뿐이다. 먼저 만든 쪽이 가진다. 우리 계정에 그 이름이 없다는 것만 확인하고 비어 있다고 판단하면 틀린다.
다행히 큰 문제는 아니었다. 실제 서비스 주소는 우리가 산 도메인의 하위 주소로 붙일 거라서, 기본 주소는 내부용 이름표에 지나지 않는다. 프로젝트 이름만 바꾸면 끝난다.
여기서 배운 건 남의 이름 공간에 서비스 주소를 두면 언제든 선점당할 수 있다는 것이다. 내 도메인이 있으면 그 위에 얼마든지 하위 주소를 만들 수 있고 누가 가져갈 수도 없다. 도메인 하나 사 두는 값이 이런 데서 돌아온다.
이름이 겹치는 서비스가 있다는 사실 자체는 따로 적어 뒀다. 성격이 전혀 달라 지금 부딪힐 일은 없지만, 제품명으로 상표를 낼 생각이 서면 그때는 먼저 조회해야 한다.
옛 화면을 지우지 않고 배포에서만 뺐다
배포하면 주소의 첫 화면에 7월에 만든 웹 관리 콘솔이 뜨게 돼 있었다. 그 콘솔은 7월 22일 이후로 손대지 않았고, 아직 역할이 관리자와 매장 둘뿐인 줄 안다. 매장 역할은 9월에 없앴다.
선택지를 받았다. 그대로 배포하거나, 첫 화면을 비우고 앱만 접속하게 하거나.
처음엔 보안 문제로 보였는데 아니었다. 콘솔을 빼든 안 빼든 서버는 똑같이 열려 있고, 관리자로 들어가려면 어차피 비밀번호가 필요하다. 실제로 달라지는 건 첫 화면에 뭐가 뜨느냐뿐이다.
진짜 이유는 다른 데 있었다. 앱 밖에서 팔기로 했으니 웹 가입·결제 페이지를 만들어야 하는데, 들어갈 자리가 바로 그 첫 화면이다. 지금 옛 콘솔을 올려두면 어차피 몇 주 뒤에 걷어낸다. 그래서 비우기로 했다.
이유를 바로 잡는 게 왜 중요하냐면, 보안 문제로 알았으면 「위험이 낮으니 그냥 두자」가 답이 됐을 것이다. 실제로 위험은 낮았다. 자리를 비워 두는 판단은 위험이 아니라 다음 일정에서 나온다.
콘솔 코드 자체는 지우지 않고 저장소에 남겼다. 급할 때 노트북에서 띄워 쓰는 예비 수단이라고 적어 뒀으니, 배포에서만 빼면 목적이 둘 다 지켜진다. 안 쓰는 것을 지울지 말지 물으면 「배포에서 뺀다」가 「삭제한다」보다 대개 낫다.
출시일이 앱이 아니라 계정 종류로 갈린다
플레이스토어 제출 준비를 항목으로 적다가 알게 된 것이다. 개인 개발자 계정으로 앱을 내려면 테스터 열몇 명을 모아 14일 동안 연속으로 테스트를 돌려야 한다. 사업자로 등록된 계정에는 이 의무가 없다.
앱이 다 만들어져 있어도 계정 종류에 따라 출시가 2주 늦어진다는 뜻이다. 코드와 아무 상관이 없고, 마지막에 알면 되돌릴 수도 없다.
플랫폼에 물건을 올릴 때는 기능 목록만 볼 게 아니라 그 플랫폼이 요구하는 절차와 자격을 먼저 확인해야 한다. 심사 기간, 필요한 계정 종류, 미리 준비해야 하는 문서 같은 것들이다. 이것들은 개발 일정과 나란히 흐르지 않고 일정 끝에 통째로 붙는다.
같은 자리에서 되돌릴 수 없는 게 하나 더 나왔다. 앱 식별자는 한 번 올리면 영원히 못 바꾼다. 지금 임시로 지어 둔 이름이 그대로 굳는 셈이라, 제출 전이 유일하게 고칠 기회다.
용량은 지금이 아니라 몇 달 뒤로 센다
음원 저장소는 무료로 10GB를 쓸 수 있다. 지금 곡이 7GB니까 들어간다. 여기서 멈추면 안 된다.
새 곡이 한 달에 60곡쯤 들어오고 그게 0.5GB쯤 된다. 남은 3GB를 나누면 6개월이다. 즉 지금 결정은 「들어간다」가 아니라 「반년 뒤에 유료로 넘어간다」이다.
용량이나 한도를 볼 때는 현재 값과 한계선만 비교하지 말고 늘어나는 속도를 같이 넣어야 한다. 그래야 언제 돈이 들기 시작하는지가 나오고, 그 시점을 알면 미리 정리할지 그냥 낼지 고를 수 있다. 모르면 어느 날 갑자기 막힌다.
요약
- 로컬에서 다 돌아가도 클라우드에 올리는 단계는 통째로 남아 있다. 기능이 아니라서 만드는 동안 안 부딪히고, 일정에 항목으로 없으면 없는 셈이 된다.
- 막힌 일은 「몇 개인가」와 「하나에 얼마 걸리는가」로 나눠 본다. 개수를 못 줄여도 단위 시간은 대개 줄일 수 있다.
- 병목은 옮겨 다닌다. 순서를 정하기 전에 다시 센다.
- 남의 이름 공간에 둔 주소는 선점당한다. 내 도메인 위에 두면 흔들리지 않는다.
- 안 쓰는 것을 정리할 때는 「삭제」보다 「배포에서 빼기」가 대개 낫다. 예비 수단은 남기고 자리만 비운다.
- 자리를 비워 두는 판단은 위험이 아니라 다음 일정에서 나온다. 이유를 바로 잡아야 답이 안 뒤집힌다.
- 플랫폼 출시는 절차와 자격을 먼저 본다. 개발과 나란히 가지 않고 끝에 통째로 붙는다.
- 되돌릴 수 없는 것은 제출 전에 확정한다. 앱 식별자가 그렇다.
- 용량은 현재 값이 아니라 늘어나는 속도로 센다. 언제 돈이 드는지가 나온다.