관찰할 수 있는 순간이 출시 시점이다

주변에 사이드 프로젝트를 하는 개발자가 많습니다. 이들이 서비스를 시작할 때 고려하는 범위를 보면 상당히 넓습니다. 아직 아무도 써보지 않은 서비스인데 회원 탈퇴 흐름을 어떻게 처리할지 설계하고, 처음부터 멀티테넌트를 감당할 수 있는 SaaS 구조를 그립니다.

이 습관 자체가 잘못된 것은 아닙니다. 실무에서 몸에 익은 엔지니어링 규율이고, 나중에 반드시 필요해지는 것들입니다. 다만 그 규율이 지금 답해야 할 질문에 적용되고 있지 않습니다. 지금의 질문은 "이 제품이 완성되었는가"가 아니라 "여기서 무언가를 배울 수 있는가"입니다.

완성도는 출시 기준이 아니다

제가 쓰는 기준은 하나입니다. 실제 사용자가 이 서비스를 통과하는 과정을 지켜보면서 무언가 알아낼 수 있는가. 그 정도까지 정의되어 있다면 처음에 구상했던 기능이 다 들어 있지 않아도 내보낼 시점입니다.

구체적으로는 이 정도면 충분합니다.

• 사용자가 무엇을 하는 곳인지 첫 화면에서 이해할 수 있다
• 핵심 흐름을 처음부터 끝까지 한 번 완주할 수 있다
• 어디서 멈추고 무엇을 눌렀는지 남는다
• 결과가 틀렸을 때 그것이 틀렸다고 말할 통로가 있다

회원 탈퇴나 결제 예외 처리가 중요하지 않다는 뜻이 아닙니다. 그것들은 사용자가 생겼을 때 지게 되는 의무이지, 사용자가 생기기 전에 갖춰야 할 조건이 아닙니다. 순서를 뒤집으면 아직 존재하지 않는 문제를 푸는 데 가장 좋은 시간을 씁니다.

지인의 피드백은 타깃 사용자의 피드백이 아니다

주변 사람들에게 클로즈드 베타처럼 써보게 하는 방식으로는 이 격차가 메워지지 않습니다. 문제는 인원수가 아니라 종류입니다.

지인은 제가 설명해 준 맥락을 가지고 들어옵니다. 무엇을 하는 서비스인지 이미 알고, 어디를 눌러야 하는지 짐작하며, 막히면 저에게 물어봅니다. 호의도 섞여 있습니다. 그래서 이들이 주는 신호는 대체로 "잘 만들었다"에 가깝고, 그 문장으로는 다음에 무엇을 고쳐야 할지 알 수 없습니다.

실제 타깃 사용자는 바깥에 있고, 검색 결과나 링크를 통해 아무 맥락 없이 도착합니다. 제가 당연하다고 생각한 문장에서 멈추고, 예상하지 못한 순서로 누르고, 만들지 않은 기능을 찾습니다. 이 정보는 제 주변에서는 절대 나오지 않습니다.

같은 것을 만드는 사람이 이미 여럿이다

간과하기 쉬운 사실이 하나 더 있습니다. 비슷한 서비스는 지금 이 순간에도 여러 사람이 만들고 있습니다. 제가 머릿속에 그린 기능을 전부 넣어 한 번에 내놓는다고 해서 그 사이에서 만족스러운 결과가 나오지는 않습니다.

완성될 때까지 쥐고 있는 것이 차별화를 사주지도 않습니다. 사주는 것은 침묵입니다. 그동안 그 자리에 아무것도 없었다는 사실만 남습니다.

검색과 AI 답변 노출 관점에서는 이 손실이 더 분명합니다. 색인은 시간에 비례해 쌓이는 자산입니다. 존재하는 페이지는 크롤링되고 색인되고 인용되기 시작하지만, 존재하지 않는 페이지는 아무것도 축적하지 않습니다. 나중에 훨씬 좋은 버전을 내놓아도 그 사이에 흐른 시간을 소급해서 살 수는 없습니다. 그래서 선별된 일부라도 먼저 노출시키는 편이 나을 때가 많습니다.

기술적 해자가 없을 때 남는 것

엔지니어의 마음가짐으로만 접근할 때의 결말은 대체로 비슷합니다. 기술적으로는 흠잡을 데 없지만 아무도 쓰지 않는 것, 저 혼자만 아는 작고 예쁜 쓰레기가 됩니다.

지금은 기술적 해자가 거의 없는 시대입니다. 예전 같으면 몇 달이 걸렸을 구현이 며칠로 줄었고, 그 말은 제가 오래 붙잡고 다듬은 구조가 방어선이 되어주지 않는다는 뜻이기도 합니다. 남는 차이는 누가 먼저 실제 사용자 앞에 서서 무엇을 배웠는가 쪽으로 옮겨갑니다.

더 큰 비용은 따로 있습니다. 속도와 동기입니다. 사용자도 피드백도 근거도 없는 상태로 몇 달을 보내면, 무엇을 위해 만들고 있는지가 흐려집니다. 그 상태에서 프로젝트는 실패하지 않고 그냥 멈춥니다. 빠진 기능 하나보다 이쪽이 훨씬 위험합니다.

일찍 내보내는 것은 기준을 낮추는 일이 아닙니다. 기준을 결과를 실제로 좌우하는 쪽으로 옮기는 일입니다. 완성되었는지가 아니라, 배울 수 있는지로.