실수 하나: 문장 대신 명세서를 작성하는 것
예전에 형편없는 소프트웨어에 데였던 사람들은 빌더를 열고 문단 하나를 통째로 쓰는 경향이 있습니다. 등급 시스템, 단위 설정, 오프라인 모드, 색상 테마까지 첫 응답이 오기도 전에 미리 다 적어둡니다. 신중해 보이지만 사실은 그렇지 않습니다. 빌더는 한 문장만 읽고도 여러분이 아마 의도했을 바를 추론해서 약 15초 만에 계획을 들고 옵니다 — "클라이머를 위한 훈련 기록"이라는 문장은 세션 기록, 등급 추적 화면, 대시보드로 바뀌고, 대부분의 클라이머가 실제로 사용하는 방식이라는 이유로 V등급 볼더링과 YDS 루트가 기본값으로 선택됩니다. 무엇을 선택했는지는 그 계획 안에 바로 표시되므로, 예외적인 경우라도 한 줄이면 수정할 수 있습니다. 미리 문단을 써두어도 이 단계를 건너뛸 수는 없습니다. 어차피 계획은 나오고, 그걸 읽어야 하며, 결국 계획이 어차피 알려줬을 제약 조건들을 타이핑하느라 3분을 쓴 셈이 됩니다. 그것도 빌드에 실제로 중요한 순서와 상관없이 말이죠.
계획은 빈칸을 채우는 양식이 아닙니다. 산문이고, 여러분도 산문으로 답합니다. "실제로는 폰트 등급으로 해줘, 나는 유럽에 있어"는 그 자체로 완결된 수정 요청입니다. "파트너/빌레이 기록 필드 추가해줘, 사람마다 같이 클라이밍하는 대상이 달라서"도 마찬가지입니다. 각 수정은 계획을 다시 생성할 뿐, 빌드를 다시 만드는 게 아닙니다 — 비용이 많이 드는 단계가 시작되기 전에 방향을 조정하는 것이지, 다시 시작하는 게 아닙니다. 그 계획을 승인하는 것이 여러분이 내려야 할 마지막 결정입니다. 이후는 모두 생성과 검증입니다.
실수 두 번째: 멈춘 터미널처럼 피드를 지켜보기
빌드는 서버 측에서 실행되며, 여기서 벌어지는 '난리'는 거의 항상 오해입니다. 누군가 조용한 활동 피드를 2분간 바라보다가 멈췄다고 단정합니다. 그렇지 않습니다 — 매초 눈에 보이는 출력을 내지 않는 단계에 있을 뿐이며, 바로 이런 이유로 피드는 현재 어떤 단계인지 표시해줍니다. 탭을 아예 닫아도 됩니다. 실행은 브라우저에 상주하지 않습니다.
실제로 기대해야 할 시간은 형태에 따라 크게 달라집니다. 클라이밍 기록 앱 — 몇 개의 페이지, 로컬 데이터 모델, 외부 API 호출 없음 — 은 3분 이내에 완성되며, "이걸 기록하고, 저걸 차트로 보여주고, 목록으로 표시해줘" 정도의 요청이라면 일반적인 시간입니다. 빌드에 실제 백엔드, 인증, 관계형 데이터베이스, 백그라운드 작업이 필요해지는 순간부터는 8~12분을 예상해야 합니다. 이제 스키마 생성과 마이그레이션이 필요하고, 검증 과정도 마크업이 아닌 서버 코드를 대상으로 한 번 더 돌기 때문입니다. 게임은 에셋 생성이 필요하기 때문에 더 느립니다: 스프라이트, 사운드 큐, 첫 시도가 실제 표시 크기에서 제대로 보이지 않으면 두 번째 비주얼 패스까지 필요할 수 있습니다. 그리고 네이티브 패키징 — 웹뷰를 껍데기로 감싼 것이 아니라 실제로 설치 가능한 APK — 은 실제 툴체인으로 넘어갑니다. Gradle, 서명 등 전부요. 이 단계 하나만으로도 다른 모든 과정 위에 5~10분이 추가될 수 있으며, 조용한 피드가 무언가 고장 났다는 뜻이 아니라 툴체인이 제 할 일을 하고 있다는 뜻인 유일한 단계입니다.
이 방식의 솔직한 대가는, 코드가 에디터에 한 글자씩 스트리밍되는 것을 지켜보는 즉각적인 피드백을 잃는다는 점입니다. 대신 얻는 것은 노트북이 잠자기 모드에 들어가거나 와이파이가 끊겨도 살아남고, 휴대폰으로 확인할 수 있으며, 여러분이 지켜보든 말든 계속 진행되는 시스템입니다. 90초짜리 빌드에는 이 트레이드오프가 거의 체감되지 않습니다. 12분짜리 백엔드 빌드에서는 터미널을 지키고 앉아 있는 것과 커피를 사러 다녀오는 것의 차이입니다.
실수 세 번째: '생성됨'과 '완료됨'을 혼동하기
이것이 가장 비싼 대가를 치르는 실수입니다. 빠르게 끝났지만 검토되지 않은 빌드는 완성된 빌드가 아니라, 우연히 작동하는 초안일 뿐입니다 — 그리고 이 둘 사이의 간극이 바로 빠른 사이트 빌더들이 나쁜 평판을 얻는 지점입니다. 이스케이프 처리 없는 폼, 키보드로 접근할 수 없는 버튼을 그대로 배포하기 때문이죠. 이 플랫폼이 무언가를 '완료'라고 부르기 전에, 별도의 검증 에이전트들이 코드, 보안, 링크, SEO, 접근성, 그리고 여러분이 승인한 계획과의 일치 여부를 검토합니다. 이는 진짜 별개의 검토 과정이지, 같은 에이전트가 자기 결과물을 다시 읽고 고개를 끄덕이는 것이 아닙니다.
보안 검사는 실제 프로덕션에서 문제를 일으키는 진부하지만 치명적인 문제들을 찾습니다: 클라이언트 측 코드에 커밋된 API 키, 이스케이프 처리 없이 입력을 받는 폼, 세션에서 유도하지 않고 클라이언트가 제공한 사용자 ID를 그대로 신뢰하는 엔드포인트. 접근성 검사는 주석으로 무시할 수 있는 린터가 아닙니다 — 실제 명암비와 인터랙티브 요소들이 키보드로 접근 가능한지를 확인합니다.
정합성(Conformance)은 사람들이 가장 과소평가하는 요소입니다. 생성 단계에서 요청한 내용이 슬그머니 빠지는 일은 흔합니다 — 예를 들어 플랜 수정 때 요청했던 파트너/빌레이 로그 필드 같은 것이, 빌드가 세 개 파일쯤 진행된 시점에서 누군가 결정하지 않았는데도 우선순위에서 밀려 사라지는 식입니다. 정합성 검사는 승인된 플랜을 실제 출력물과 다시 대조해 이런 차이를 찾아냅니다. 문제를 발견하면 수정이 자동으로 적용되고 다시 검증됩니다. 사용자에게 할 일 목록이 전달되는 게 아니라, 결과적으로 눈에 띄지 않게 고쳐지거나 애초에 문제가 없는 상태가 됩니다. 각 검증기가 정확히 무엇을 확인하는지, 같은 항목이 두 번 연속 실패하면 어떻게 되는지는 빌드는 어떻게 스스로 검증하는가에서 다룹니다. 이 섹션에서 꼭 기억해야 할 한 가지: 완료란 생성됨이 아니라 검증을 통과함을 의미합니다. 이 둘을 같은 것으로 취급하면 결국 노출된 키나 작동하지 않는 버튼을 그대로 배포하게 됩니다.
세 가지 실수를 모두 피하면 얻게 되는 것
- 클릭해서 실제로 둘러볼 수 있는 진짜 미리보기 — 여러분의 데이터가 연결된 실제 실행 인스턴스이지, 완성될 모습을 담은 스크린샷이 아닙니다.
- 여기에 연결된 채팅 스레드에서 "헤더를 더 어둡게 하고 통계 페이지를 추가해줘"라고 하면 버전 1 옆에 버전 2가 생성됩니다. 이전 버전은 사라지지 않고, 새 버전이 실제 미리보기 자리를 차지하는 동안 폴백으로 그대로 남아 있습니다.
- 실제로 동작하는 버튼들: 라이브 배포, 코드 다운로드, 네이티브 설치 파일 빌드, 스토어 출시. 버튼처럼 꾸며진 업셀 모달이 아닙니다.
그 코드 다운로드 버튼은 한 번 더 살펴볼 가치가 있습니다. 이것이 바로 진짜 작업물에 신뢰할 수 있는 도구인지, 아니면 일회성 프로토타입에만 쓸 도구인지를 가르는 지점이기 때문입니다. 코드가 정말로 여러분 소유이고, 읽기 쉬운 파일 구조에, 실제로 요청한 것 이상의 이상한 종속(lock-in)이 없다면, 플랫폼은 여러분이 이미 갇혀 있다는 사실에 안주하지 않고 다음 세션에서도 계속 신뢰를 얻어야 합니다.
