라이브까지 클릭 네 번. 시작부터 완료까지 30초. 무료 요금제에서는 계정당 서버 기반 앱 하나만 라이브로 운영 가능. 새로운 서브도메인이 처음 요청을 처리할 때만 0.5초의 추가 지연이 있고, 그 이후로는 없습니다. 이 중 세 가지 숫자는 잡학 상식에 불과합니다. 고개를 끄덕이고는 다음 장으로 넘어가면 잊어버리는 종류죠. 하지만 "하나"라는 숫자는 실제로 작업 방식을 바꿔야 하는 숫자이므로, 이번 장의 대부분을 여기에 할애하려 합니다.
왜 제한이 0도 무제한도 아닌 하나인가
프론트엔드를 무료로 게시할 수 있게 해주는 대부분의 노코드 도구들은 서버 기반 앱을 아예 다루지 않거나, 매우 공격적으로 사용량을 제한해서 "무료"가 사실상 형식에 불과합니다. 여기서는 계정, 데이터베이스, 멀티플레이어 상태를 가진 빌드도 정적 페이지와 정확히 같은 게시 버튼을 통해 배포되며, 서버 측은 그 단일 동작의 일부로 호스팅되고 관리됩니다. 별도의 데이터베이스 프로비저닝도, 연결해야 할 환경 변수도 없고, 로그인이 미리보기에서는 되는데 프로덕션에서는 백엔드가 실제로 배포되지 않아 500 에러가 나는 걸 사흘 뒤에 발견하는 일도 없습니다. 이는 실제로 그렇고, 사람들이 상한선에 부딪혔을 때 놀라는 이유이기도 합니다. 그 지점까지는 모든 게 무제한처럼 느껴지니까요.
그렇지 않습니다. 무료 요금제에서는 정확히 한 번에 하나의 서버 기반 앱만 라이브로 운영할 수 있습니다. 정적 빌드는 여기에 포함되지 않으니, 마케팅 페이지나 포트폴리오 사이트는 원하는 만큼 게시해도 제한이 없습니다. 하지만 자체 데이터베이스나 지속적인 프로세스가 필요한 두 번째 빌드는 자기 차례를 기다려야 하며, 완전히 빌드되고 미리보기는 가능하지만 URL에서 라이브 상태는 아닙니다. 같은 주에 SaaS 아이디어 세 가지를 프로토타이핑하고 있다면, 실제 컴퓨팅 자원을 차지하는 건 그중 하나뿐이고 나머지 둘은 완성된 결과물이지만 주소가 없는 상태입니다. 이 선을 그은 위치는 합리적이라고 생각합니다. 정적 번들은 엣지에서 서빙하는 데 플랫폼에 거의 비용이 들지 않지만, 워밍업된 서버 프로세스는 그렇지 않으니까요. 다만 이는 어떤 아이디어가 그 자리를 차지할 자격이 있는지를 게시 버튼을 누르기 전에 결정해야지, 이미 두 개를 동시에 라이브로 운영하는 데 애착이 생긴 후에 결정할 문제가 아니라는 뜻입니다.
참고로, 그 네 번의 클릭
- 빌드 카드에서 게시를 선택하세요.
- 슬러그를 선택하세요 — 사용자 이름 안에서
yourname.buildmidas.com. 이미 사용 중인 슬러그는 대안을 제시합니다. - 확인합니다.
- 카드에서 URL을 복사하거나, 나중에 게시됨 페이지에서 찾으세요.
DNS도 없고, 외부 계정도 없고, 전파를 기다릴 필요도 없습니다. 그리고 그 0.5초에 대해 말하자면, 그건 대기열도 "24시간 후 다시 확인하세요" 같은 지연도 아니라 그저 일반적인 CDN 캐시 워밍입니다. 새 서브도메인의 첫 방문자는 가장 가까운 엣지 노드가 자산 번들을 가져오는 동안 약간의 추가 지연을 경험할 수 있지만, 두 번째 방문자부터는 캐시에서 받아옵니다. 실제로는 눈치채지 못할 겁니다. 게시하고 링크를 탭하면 이미 즉각적으로 느껴질 테니까요. 언급하는 이유는, 로딩 시간을 캡처하는 게 업인 누군가가 언젠가 첫 번째 요청과 열 번째 요청이 왜 똑같지 않은지 물어볼 것이기 때문이고, 이제 여러분은 그 이유를 알고 있습니다.
슬러그는 신중히 결정할 가치가 있는 유일한 선택
이 흐름의 나머지는 다 기계적인 작업이지만, 슬러그만큼은 사람이 직접 말로 하거나 기억해서 입력해야 하는 부분이라 한 번쯤 생각해 볼 가치가 있습니다. "demo-v2-final-final"은 내부 테스트용으로는 괜찮지만 클라이언트에게 문자로 보내기엔 좋지 않습니다. 확정하기 전에 URL을 스스로 소리 내어 읽어보세요 — riverside-cafe.buildmidas.com 깔끔하게 읽히는 것과 riverside-cafe-mvp2.buildmidas.com 그렇지 않은 것의 차이를요. 오래된 플랫폼에서는 짧고 흔한 단어일수록 빨리 선점되기 때문에, 이미 사용 중인 슬러그를 입력하면 오류 대신 추천 목록이 표시됩니다. 그중 하나를 선택하든 거부하든, 의도를 갖고 결정하세요 — 저는 사람들이 데모 도중 급하게 링크가 필요해서 상자가 제안한 아무거나 골랐다가, 나중에 고칠 자연스러운 계기가 없어서 몇 달 동안 어색한 이름을 그대로 쓰는 걸 봐왔습니다.
재게시는 여러분이 결정하기 전까지 라이브 상태를 건드리지 않습니다
일찍 체득해둘 만한 사실이 하나 있습니다. 게시된 빌드를 편집한다고 해서 라이브 사이트가 바뀌지는 않는다는 것입니다. 뭔가를 망가뜨릴 수도, 과감한 레이아웃 변경을 시도할 수도, 일주일 내내 반복 작업을 할 수도 있습니다. 클라이언트가 이미 북마크해둔 URL은 여러분이 의도적으로 다시 게시하기 전까지는 마지막으로 게시한 그대로를 계속 제공합니다.
그게 롤백 절차의 전부이며, 정확히 지루하기 때문에 좋은 겁니다. 버전 6에서 버그가 발생합니다. 폼이 조용히 제출을 멈추는 식으로요. 그러면 되돌리기 명령이나 지원 티켓을 찾을 필요가 없습니다. 버전 기록을 열어 버전 5를 찾아 재게시하면 됩니다. 같은 버튼, 이전 결과물, 라이브 URL이 즉시 되돌아갑니다. 그런 다음 프로덕션이 멈춰 있지 않은 상태에서 아무 압박 없이 버전 6을 수정하면 됩니다. 여기서 치러야 할 대가는 릴리스당 클릭 한 번 더뿐입니다. 편집한 게 자동으로 나간다고 가정하지 말고 직접 게시해야 함을 기억해야 하니까요. 모든 저장이 곧바로 라이브로 반영되는 도구들과 비교하면 — 데모에서는 멋지지만 실제로 3주 쓰다 보면 곤혹스러운데 — 이 추가 클릭은 언제나 감수할 가치가 있는 트레이드오프입니다.
게시 취소는 URL이 더 이상 연결되지 않는다는 뜻이지, "목록에서 빠진다"는 뜻이 아닙니다
많은 플랫폼에서 "게시 취소"는 갤러리 페이지에서만 숨기고 URL은 계속 조용히 서빙하는 걸 의미합니다. 여기서는 주소 자체가 완전히 꺼진다는 뜻입니다. 캐시된 페이지도, 플레이스홀더도, 어떤 것도 연결되지 않습니다. 빌드 자체는 모든 버전이 그대로 남아 있으며, 나중에 다시 게시하면 같은 슬러그가 정확히 이전 상태로 돌아옵니다. 저는 이 기능을 평범한 이유(클라이언트 계약이 끝나서 아무도 옛 로고가 공개 링크에 떠 있길 원하지 않을 때)와 그보다 덜 평범한 이유(빌드가 유출되어서는 안 될 정보를 노출했고, 호스팅 업체에 티켓을 접수하는 시간이 아니라 버튼 한 번 클릭하는 시간 안에 오프라인으로 만들어야 했을 때) 둘 다에 써봤습니다. 두 상황 모두 같은 보장을 원하고, 둘 다 그걸 얻습니다.
혼동하지 말아야 할 한 가지 더: 게시는 링크를 가진 누구에게나 URL을 라이브로 만드는 것이고, 그것이 발견 가능한지 — 공개적으로 목록에 오르고 때로는 쇼케이스에 노출되는지 — 는 완전히 별개의 토글입니다. 정당하게 게시된 사이트 중 상당수는 영원히 링크로만 접근 가능한 상태로 남아야 하며, 공개 목록에 등록하기로 선택한 빌드도 내부적으로는 동일한 이력과 동일한 게시 취소 버튼을 가진 평범한 게시된 사이트일 뿐입니다.
