BuildMidas 핸드북: 플랫폼 지도

사이드바 항목을 하나씩 설명하는 대신, 실제 계정 하나를 처음부터 끝까지 안내해드리겠습니다. 플랫폼 첫 주를 맞은 프리랜서가 소규모 클라이언트를 위한 습관 추적 앱을 만든다고 가정해봅시다. 그 빌드가 대시보드를 거쳐가는 동안 실제로 일어나는 순서대로 이 문서도 진행되며, 각 단계에서 도움이 됐는지 5분을 낭비했는지도 함께 다룹니다.

프롬프트

그들은 AI 빌더를 열고 "습관 추적기 만들어줘" 비슷한 문장을 입력합니다. 첫 문장으로는 나쁘지 않지만 최종 프롬프트로는 부족하죠. 결과로 나오는 건 코드가 아니라 평문으로 쓰인 계획이며, "괜찮아 보이네"에서 읽기를 멈추고 승인 버튼을 누르면 "습관 추적기"라는 단어에는 기술적으로 부합하지만 중요한 모든 면에서는 그저 평범한 결과물을 얻게 됩니다. 이 프리랜서의 클라이언트는 소셜 기능 없음, 로컬 저장소만 사용, 기본값은 다크 모드를 원했습니다. 이 중 어느 것도 첫 프롬프트에는 없었죠. 대신 그 내용은 승인 전 세 가지 수정 사항으로 계획에 반영됩니다. 계획이 멋대로 만들어낸 "스트릭 공유하기" 기능 삭제, 저장소 항목 교체, 기본 테마 전환. 30초의 수정 작업. 그 과정을 거쳐 나온 빌드는 "습관 추적기"라는 단어가 아니라 실제 요구사항에 맞아떨어집니다.

사람들이 건너뛰는 계획 단계

다른 사용자들에게서 이런 순간이 정확히 잘못 흘러가는 걸 지켜본 적이 있습니다. 첫 번째 계획을 읽지도 않고 승인한 뒤, 세 번의 반복 작업을 거치고 나서야 애초에 계획 단계에서 정했어야 할 제약 조건을 다시 설명하기 시작하는 겁니다. 계획 단계가 존재하는 이유는 정확히 그런 상황을 막기 위해서죠. 비용은 거의 들지 않고, 이 루프 전체에서 코드 결과물을 디버깅하는 대신 여러분의 언어로 에이전트와 협상할 수 있는 유일한 지점입니다.

빌드가 실제로 도착하는 곳

빌드가 생성되면 습관 추적기는 내 빌드에 카드 형태로 나타납니다. 유형별로 필터링할 수 있는 라이브러리 페이지이며, 3주 차쯤 빌드 5~6개가 쌓이면 이 프리랜서가 다른 어떤 페이지보다 더 자주 열게 될 페이지죠. 쇼케이스에는 표시되지 않습니다. 그 페이지는 자동이 아니라 큐레이션되는 곳이며, 클라이언트 빌드가 홍보 없이 거기 놓이는 게 올바른 기본값입니다. 템플릿에도 프리랜서가 직접 템플릿으로 저장하지 않는 한 표시되지 않습니다. 사실 여기서는 저장해두는 게 좋습니다. 습관 추적기 골격은 브랜딩만 다르게 해서 다음 클라이언트를 위해 다시 만들기 딱 좋은 종류의 자산이니까요. 대부분의 사람들은 여섯 번째 빌드에서야 "템플릿으로 저장" 기능을 발견하고, 첫 번째 빌드 때 해뒀으면 좋았을 걸 하고 아쉬워합니다.

게시, 혹은 더 무거운 선택지

이제 배포 방식에 대한 질문입니다. 이름만 세 개인 하나의 옵션이 아니라, 진짜 세 가지 옵션입니다. 게시됨은 무료 서브도메인을 제공하며 몇 초 만에 라이브로 전환되고 설정이 전혀 필요 없습니다. 클라이언트가 아직 검토 중이고 리디자인을 요청할 수도 있는 단계라면 옳은 선택이죠. 도메인 관리는 클라이언트 소유 도메인을 연결할 준비가 됐을 때 쓰는 곳이며, 이 단계는 두 가지 역할을 합니다. 여기서 도메인을 연결하는 건 단순한 URL 변경이 아니라, 사이드바 아래쪽에 있는 분석 페이지들이 붙일 데이터를 갖게 되는 계기이기도 하죠. 설정 아래에 있는 배포는 클라이언트가 자신들이 통제하는 인프라에서 빌드를 운영하라고 고집할 때 쓰는 SFTP 경로입니다. 설정이 더 많이 필요하고, 프리랜서는 더 이상 가동 시간에 대한 책임을 지지 않게 되는데, 이는 우연히 알게 되기보다는 명시적으로 논의해볼 가치가 있는 실질적인 트레이드오프입니다.

이 빌드는 먼저 게시부터 합니다. 서브도메인에서 커스텀 도메인으로 나중에 옮기는 건 별일 아닙니다. 반면 취소된 클라이언트 프로젝트에서 커스텀 도메인 배포를 되돌리는 건 그럴 가치보다 정리할 게 더 많습니다. 실제로 이 프리랜서는 이전 프로젝트에서 정확히 그 문제로 곤욕을 치른 적이 있고, 그게 바로 "기본값은 게시"라는 습관을 들이게 된 이유입니다.

앱스토어로 잠깐 우회하기

이번 클라이언트는 앱스토어 등록도 원했기 때문에, 게시에서 멈추지 않고 배송됨 단계를 거칩니다. 이 페이지가 존재하는 이유는 스토어 심사가 웹 배포와는 다른 방식으로 비동기적이기 때문입니다. 한 스토어에 제출하면 이틀 동안 대기하고, 다른 스토어에 제출하면 20분 만에 통과하죠. 배송됨은 각기 다른 로그인과 상태 표현 방식을 가진 다섯 개의 스토어 콘솔을 다섯 개의 브라우저 탭으로 열어두지 않고도 이를 추적할 수 있는 곳입니다.

아무도 경고해주지 않은 빈 페이지

도메인 연결 일주일 후, 프리랜서는 확인차 검색 성능을 엽니다. 비어 있습니다. 사실 다소 쓸쓸해 보이죠. 차트도 숫자도 없이 계정 연결 안내만 있을 뿐입니다. 고장 난 게 아니라 정직한 상태입니다. 아직 데이터가 없는 이유는 검색 성능, 구글 애널리틱스, 스토어 분석이 모두 설정 아래의 구글 계정 연결에 의존하며, 그중 어느 것도 소급 반영되지 않기 때문입니다. 동기화는 연결한 순간부터 시작되며 이후로만 진행됩니다. 첫날에 도메인을 연결하면 둘째 주에는 일주일치 이력이 쌓이지만, 깜박해서 열흘째 되서야 연결하면 그날부터 다시 시작하는 겁니다. 이 프리랜서는 도메인은 연결했지만 구글 계정은 연결하지 않았습니다. 하나처럼 보이지만 실제로는 별개인 두 단계였던 거죠.

여기서 실제로 비용이 드는 부분은 비어 있는 차트가 아닙니다. 최적화 에이전트들도 이 동일한 데이터를 참조하기 때문에, 검색 성능 이력이 전혀 없는 상태에서 페이지 순위 개선을 요청받은 에이전트는 이 사이트의 실제 수치가 아니라 일반적인 모범 사례를 기반으로 작업하게 됩니다. 연결을 건너뛰는 건 단순히 대시보드 페이지 하나를 비워두는 게 아니라, 에이전트가 할 수 있는 일 자체를 제한하는 것입니다.

묻지도 않았는데 나타나는 브리핑

2주 차에 디스커버리에 카드가 하나 나타납니다. 클라이언트 사이트의 콘텐츠 공백을 짚어주는 기회 브리핑이며, 바로 실행할 수 있는 '빌드하기' 버튼이 붙어 있습니다. 어차피 실행에 옮길 만한 내용일 때는 정말 유용하죠. 하지만 디스커버리는 설계상 정밀도보다 물량 쪽에 치우쳐 있습니다. 누구도 다 실행하지 못할 만큼 많은 브리핑이 쏟아지죠. 그러니 올바른 태도는 처리해야 할 대기열이 아니라 제안함으로 대하는 것입니다. 이 프리랜서는 며칠에 한 번씩 훑어보고 대부분을 무시하는데, 이는 뒤처지는 게 아니라 의도된 사용 방식입니다.

첫날에 해뒀어야 할 설정들

이 시점까지 프리랜서는 설정 메뉴를 일부러 연 적이 한 번도 없이 설정 페이지 네 곳을 건드리게 됐습니다. 각각 다른 무언가가 비어 있는 걸 발견하고서야 알게 된 것들이죠.

구글 계정 연결은 미리 해두는 게 좋은 항목입니다. 대시보드 화면 세 곳이 이 단일 연결 지점 뒤에 물려 있으며, 이걸 어렵게 알아가는 방식 — 서로 다른 빈 페이지 세 개, 그때마다 "아, 뭔가 연결해야 하는구나" 하고 깨닫는 세 번의 순간 — 은 바로 첫날에 5분만 투자해 설정하면 피할 수 있는 마찰입니다.

처음부터 계속 거기 있었던 두 가지

떠다니는 AI에게 묻기 버튼은 이 모든 페이지에 처음부터 계속 자리해 있었고, 이건 범위가 제한된 FAQ 봇이 아니라 여러분을 대신해 계정을 연결하거나, 빌드를 시작하거나, 페이지가 왜 비어 있는지 설명해줄 수 있습니다. 이 프리랜서의 클라이언트는 영어를 쓰지 않았고 검토 통화를 위해 인터페이스 전체를 다른 언어로 바꿔야 했습니다. 내비게이션의 지구본 아이콘은 진행 중인 빌드를 잃지 않고 세션 도중에도 20개 언어를 전환해줍니다. 이 두 가지는 이 안내서의 다른 모든 것처럼 시행착오를 거쳐 발견할 필요가 없었습니다. 그저 원래 거기 있었던 겁니다.

그것이 이 계정의 첫 2주를 정직하게 요약한 내용입니다. "문서를 읽고 나서 만들라"가 아니라 그 반대죠. 내 빌드는 카드가 하나 생기기 전까지는 추상적인 개념일 뿐이었습니다. 검색 성능은 도메인이 데이터를 공급하기 전까지는 빈 상태였고요. 첫 빌드 전에 전체 구조를 읽어보는 것도 배경지식으로는 괜찮지만, 그 구조는 실제 습관 추적기 하나가 어딘가에 자리 잡고 나서야 비로소 이해가 됩니다.