라이브로 가는 세 가지 길

이번 주에는 세 가지 경로를 단순히 설명만 하는 대신 실제로 빌드를 실서비스에 올려봤습니다. 그래서 무엇을 실행했고, 무엇이 문제였고, 다시 한다면 무엇을 건너뛸지 기록을 남깁니다.

1일차 오전 — 원클릭 서브도메인

가장 빠른 방법부터 시작했습니다: 게시 버튼을 누르니 DNS 설정도, 계정 생성도, 비용도 없이 yourname.buildmidas.com이 생겼습니다. 4초 정도밖에 안 걸렸습니다. 아이디어에 관심을 가지는 사람이 있는지 그냥 알아보고 싶을 때 딱 맞는 방법입니다 — 링크를 공유하고, 반응을 지켜보고, 개선하는 거죠. 계정, 데이터베이스, WebSocket 멀티플레이어 레이어처럼 앱이 진짜 백엔드가 필요해지는 순간 벽에 부딪힐 줄 알았는데, 그것도 이미 호스팅되고 관리되고 있었습니다. 제가 따로 설정할 게 전혀 없었어요. 첫날치고는 훌륭했습니다.

1일차 오후 — SFTP 배포를 망가뜨려보려는 시도

이 부분이 제일 긴장됐던 단계입니다. 제품이 서브도메인을 벗어나 자체 도메인이 필요해지면, 빌드 페이지에서 바로 SFTP로 배포합니다. 저는 이미 이전 파일이 남아 있는 웹루트가 있는 서버를 대상으로 지정해서, 절반쯤은 파일이 덮어써질 거라 예상했습니다. 하지만 배포 에이전트는 서버를 먼저 검사하고 전략을 선택했으며 — 이 부분이 중요했는데 — 무언가를 건드리기 전에 기존 웹루트를 먼저 백업했습니다. 그 이후 배포된 모든 버전도 계속 보관되며, 되돌리기는 클릭 한 번이면 됩니다. 그래서 20분 뒤 일부러 망가진 빌드를 배포해서 테스트했을 때, 롤백에 걸린 시간은 빌드가 망가졌다는 걸 알아차리는 시간과 거의 같았습니다. 이게 왜 중요한지는 두려움 없이 반복하기에서 더 자세히 다뤘습니다 — 요약하자면, 버전 기록 덕분에 배포가 숨죽이고 지켜보는 순간에서 별일 아닌 일로 바뀐다는 것입니다.

다음에는 건너뛸 것: 이상하게 중첩된 서브디렉토리 구조로 속여보려고 20분을 썼는데, 결국 핵심은 당신의 서버, 당신의 도메인, 당신의 파일이라는 점이었습니다 — 이 도구는 문지기가 아니라 신중한 이동자일 뿐입니다. 애초에 위험 요소가 아니었던 것을 테스트하느라 시간만 낭비한 셈이었습니다.

2일차 — 끝내지 못한 스토어 경로

사실 이건 완료하지 못했는데, 그게 오히려 더 유용한 교훈이다. 스토어 배포 — Android는 Google Play로, 확장 프로그램은 Chrome 웹 스토어와 Firefox Add-ons로 — 는 본인 소유의 개발자 계정을 통해 진행되며, 목록과 개인정보 보호 선언은 에이전트가 준비한다. 이건 실제로 가능하지만, 검토 대기열이 그 누구의 통제 밖에 있는 별도의 며칠짜리 프로세스이기도 해서, 목록 준비 단계 이후로는 멈췄다. 스토어 배포를 노린다면 그 부분은 따로 시간을 잡아두어야 한다. 전체 과정은 프롬프트에서 앱 스토어까지에 정리했다.

그 순간 어떤 경로를 선택할지 결정한 요인

2일차가 되자 선택은 거의 저절로 정해졌다:

주말 무렵

금요일이 되자 내 도메인에 마케팅 사이트가 있었고, 제품 자체는 서브도메인에서 라이브 상태였으며, 스토어 목록도 절반쯤 준비되어 있었다 — 세 경로 모두 같은 프로젝트를 위해 동시에 진행되었고, 처음부터 끝까지 같은 채팅에서 빌드되고 반복되었다. 이게 진지한 프로젝트라면 예외가 아니라 일반적인 최종 상태인 듯하다. 세 경로를 각각 별개의 결정으로 취급하는 대신, 첫날부터 이걸 예상했더라면 좋았을 것이다.