이미 잘 작동하는 것을 수정하는 일이 왜 위험하게 느껴질까요? 대부분의 도구는 현재 위치에서 편집하도록 만들어져 있기 때문입니다 — 기존 버전 위에 저장하고, 변경 사항이 문제를 일으켜도 돌아갈 버전이 없습니다. 되돌리기가 없다면 그런 두려움은 지극히 합리적입니다. 그래서 여기에는 "현재 위치"라는 개념이 없습니다. 모든 편집은 기존에 있던 것 옆에 새로운 것을 만듭니다.
변경을 요청하면 실제로 무슨 일이 일어나나요?
빌드 채팅에 원하는 것을 말하면 됩니다 — 문구 수정, 새 섹션, 완전히 새로운 기능 등. 그러면 플랫폼은 기존 버전과 나란히 새로운 버전을 만듭니다. 기존 버전을 대체하는 게 아닙니다. 두 버전 모두 미리보기와 다운로드가 가능하며, 이전 버전은 뒤져야 하는 보관함으로 밀려나지 않습니다. 클릭 한 번이면 다시 라이브가 될 수 있는 작동하는 제품으로 남아 있습니다. 변경을 되돌리는 비용이 이렇게 저렴해지면, 더 이상 모든 편집을 도박처럼 다루지 않게 됩니다.
모든 버전마다 전체 검증을 다시 실행하면 속도가 느려지지 않나요?
오히려 검증이 해결하는 문제와 정반대입니다. 반복적인 AI 편집에서 흔한 실패 방식은 변경 그 자체가 아니라, 그 변경이 다른 곳에서 조용히 망가뜨리는 것입니다. 가격 페이지를 고쳤더니 그 페이지로 연결되던 내비게이션 링크가 조용히 404가 되는 식이죠. 그래서 9번째 버전도 1번째 버전과 정확히 같은 검증 체인을 거칩니다: 코드 리뷰, 보안, 링크 확인, 접근성, 표준 준수. 변경이 무언가를 망가뜨리면, 그것이 도입된 라운드에서 바로 발견됩니다. 사용자가 3주 후에 고장 난 버튼에 대해 이메일을 보낼 때가 아니라요. (자세한 내용은 빌드는 어떻게 스스로를 검증하는가에서 확인하세요.)
자체 서버에 배포하면 어떻게 되나요?
자체 호스트로의 SFTP 배포도 한 단계 아래에서 동일한 처리를 받습니다. 무엇이든 기록되기 전에, 플랫폼은 현재 웹루트를 캡처합니다. 그 이후 배포한 모든 버전은 호스트에 남아 복원 가능한 상태를 유지합니다. 그래서 미리보기에서는 완벽해 보였던 배포가 캐시 헤더나 이상한 CDN 규칙 같은 프로덕션 스택의 문제로 인해 실제 라이브에서 이상해 보이면, 옛 익스포트를 다시 배포하며 제대로 된 파일을 가져왔길 바라는 대신 클릭 한 번으로 되돌릴 수 있습니다.
무료 서브도메인은 어떤가요?
같은 개념이지만 더 가볍습니다. 그곳에 게시하면 게시된 모든 버전이 보관되며, 이전 버전을 다시 게시하는 일은 새 버전을 게시하는 것만큼 쉽습니다.
| 지역 | 무엇이 보관되는가 | 실행 취소 |
|---|---|---|
| 빌더 안에서 | 모든 버전, 미리보기와 다운로드 가능 | 모든 버전 복원 |
| 내 서브도메인 | 언제든 교체 가능한 게시 버전 | 이전 버전 다시 게시 |
| 내 서버 | 배포 전 캡처 + 배포된 각 버전 | 호스트에서 클릭 한 번으로 되돌리기 |
이건 그냥 고급 백업 시스템 아닌가요?
아니요 — 백업 시스템은 재난으로부터 지켜주는 것입니다. 이것은 여러분의 일상적인 행동을 바꾸기 위한 것입니다. 잘못된 추측의 비용이 클릭 한 번으로 떨어지면, "일단 한번 해보자"는 위험한 제안이 아니라 거의 모든 아이디어에 대한 기본 답이 됩니다.
