첫 번째 사이드 프로젝트를 만들었을 때 이야기다. 개발자용 북마크 관리 서비스. 기능은 간단했다. 링크 저장, 태그 분류, 검색. 기본 기능은 2주 만에 다 만들었다.

그리고 3개월을 더 붙잡고 있었다.

"다크 모드가 없으면 안 되지." 다크 모드 추가. "공유 기능도 있어야 하지 않을까." 공유 기능 추가. "성능 최적화를 좀 해야..." Lighthouse 점수 올리기. "온보딩 튜토리얼이 있으면 좋겠다." 튜토리얼 추가. 3개월 동안 핵심 기능은 안 바뀌고 부가 기능만 늘어났다.

결국 출시했을 때 사용자 반응은? 조용. 3개월 동안 정성 들인 다크 모드, 공유 기능, 튜토리얼 중에 사용자가 실제로 쓴 건 거의 없었다. 피드백은 전혀 다른 곳에서 나왔다. "폴더 기능이 없어서 불편해요." 3개월 동안 생각도 안 한 기능이었다.

2주 만에 출시했으면 이 피드백을 3개월 전에 받았을 거다. 그리고 다크 모드 대신 폴더 기능을 만들었을 거다.

Paul Graham: "일찍 런칭하라"#

Paul Graham이 "Do Things That Don't Scale"에서 한 이야기가 계속 머릿속에 남는다. 성공한 스타트업들은 완벽한 제품으로 시작한 게 아니라, 창업자가 직접 손으로 밀어서 굴러가게 만든 것이라고. Stripe은 초기에 사용자를 일일이 수동으로 등록시켰고, Airbnb 창업자들은 뉴욕 아파트를 문 두드리며 다녔다.

핵심은 "완벽한 제품을 만들고 나서 사용자를 모은다"가 아니라 "일단 돌아가는 걸 만들고, 사용자 반응을 보면서 키운다"라는 거다. 초기에 중요한 건 제품의 완성도가 아니라 사용자 경험이다. 제품이 미숙해도 개인적인 관심과 빠른 대응으로 보상할 수 있다.

이걸 회사 업무에 적용하면 좀 다르긴 하다. 스타트업과 대기업의 맥락이 다르니까. 근데 핵심 원리는 같다. 사용자 앞에 빨리 갖다 놓을수록 방향을 빨리 잡을 수 있다.

Seth Godin: "출시하라"#

Seth Godin은 더 직설적이다. 줄타기에서 가만히 서 있는 것보다 걸어가는 게 더 쉽다고 했다. 앞으로 나아가는 움직임 자체가 안정성을 만든다.

출시도 마찬가지다. 내부적으로 완벽하게 만들려고 하면, 피드백 없이 혼자 균형을 잡으려고 서 있는 거다. 흔들릴 수밖에 없다. 출시하고 나서 사용자 반응을 보면서 조정하는 게 훨씬 안정적이다. 걸어가면서 균형을 잡는 거다.

Seth Godin이 강조하는 또 다른 포인트는, "시도해볼 만한 가치가 있는가?"가 "이게 성공할 것인가?"보다 중요한 질문이라는 거다. 확실한 성공을 보장할 수는 없지만, 빠르게 테스트해볼 가치가 있는지는 판단할 수 있다. 그리고 테스트하는 유일한 방법은 출시하는 거다.

"다 됐다"를 판단하는 프레임워크#

그래서 실용적으로, 언제 출시해야 하는 건지. 나는 세 가지 기준을 쓴다.

1. MVP 체크리스트#

기능을 설계할 때 처음부터 세 개의 목록을 만든다.

• Must Have: 이게 없으면 서비스가 성립하지 않는 것. 북마크 서비스에서 "링크 저장"은 Must Have다.
• Should Have: 없어도 되지만 사용자 경험에 큰 차이를 만드는 것. "태그로 분류"는 Should Have다.
• Nice to Have: 있으면 좋지만 없어도 아무도 모르는 것. "다크 모드"는 Nice to Have다.

Must Have가 다 되면 출시한다. Should Have는 출시 후에 추가한다. Nice to Have는 사용자가 요청할 때만 한다.

단순해 보이는데, 이걸 제대로 하려면 "이게 진짜 Must인가 Should인가"를 정직하게 구분해야 한다. 개발자는 본능적으로 "이것도 Must, 저것도 Must"로 올리고 싶어한다. 기술적 완성도에 대한 욕심 때문에. Must는 "이게 없으면 사용자가 핵심 목적을 달성할 수 없는가?"로 판단한다. 꽤 많은 것들이 Should로 내려간다.

2. "부끄러운가?" 테스트#

출시 전에 스스로한테 물어본다. "이걸 출시하면 부끄러운가?"

부끄럽지 않으면 출시가 너무 늦은 거다. 살짝 부끄러우면 적당한 타이밍이다. 너무 부끄러우면 조금 더 다듬어야 한다.

이 판단 기준이 주관적이긴 한데, 나름 유용하다. "부끄러움"의 실체는 보통 두 가지 중 하나다.

첫째, 기술적 부끄러움. "코드가 지저분한데." "테스트가 부족한데." "이 부분 하드코딩인데." 이건 무시해도 된다. 사용자는 코드를 안 본다. 동작만 하면 된다.

둘째, 사용자 경험 부끄러움. "이 흐름이 불편한데." "에러 처리가 엉성한데." "로딩이 느린데." 이건 좀 더 신경 써야 한다. 근데 이것도 정도의 문제다. "좀 불편하다"와 "못 쓰겠다"는 다르다. 좀 불편한 정도면 출시하고 개선하면 된다.

3. 다듬기 vs 미루기 구분#

가장 어려운 건 "진짜 다듬고 있는 건가, 출시를 미루는 핑계인가"를 구분하는 거다.

다듬기(polish)는 구체적인 목표가 있다. "에러 메시지를 사용자 친화적으로 바꾸겠다." "로딩 스피너를 추가하겠다." "이 버튼의 위치를 조정하겠다." 각각 30분에서 2시간이면 끝나는 작업.

미루기(procrastination)는 목표가 애매하다. "좀 더 다듬어야 할 것 같다." "어딘가 부족한 느낌이다." "좀 더 테스트해봐야 한다." 끝이 없는 작업.

내 규칙: "이 다듬기 작업이 뭔지 한 문장으로 설명할 수 있으면 다듬기, 못 하면 미루기." 한 문장으로 설명할 수 없다는 건 진짜 문제가 있는 게 아니라 출시에 대한 불안감 때문이라는 신호다.

너무 일찍 출시해서 실패한 이야기#

다 빨리 출시하라는 이야기만 하면 안 된다. 너무 일찍 출시해서 문제가 된 적도 있다.

내부 관리자 도구를 만들 때였다. 기본 CRUD만 되는 상태에서 "빨리 피드백 받자"고 출시했다. 근데 데이터 validation이 안 되어 있어서, 운영팀에서 잘못된 데이터를 입력하는 일이 생겼다. 잘못된 데이터가 실서비스에 반영되면서 장애가 났다.

이건 Must Have를 제대로 파악 못 한 거였다. "데이터 validation"은 내부 도구라 해도 Must Have였다. 사용자가 개발자가 아니라 운영팀이었기 때문에, 입력 실수에 대한 방어가 필수였다.

이 경험에서 배운 건, "빨리 출시하라"가 "아무렇게나 출시하라"는 뜻이 아니라는 거다. Must Have를 정확히 파악하는 게 핵심이고, Must Have에는 사용자의 실수로부터 보호하는 것도 포함된다. 특히 데이터를 다루는 도구라면.

너무 늦게 출시해서 실패한 이야기#

반대 사례도 있다. 소셜 기능이 있는 사이드 프로젝트를 만들었다. 개발자들이 코드 스니펫을 공유하고 코멘트를 달 수 있는 서비스. 6개월 동안 만들었다. 문법 하이라이팅, 마크다운 에디터, 알림 시스템, 팔로우 기능까지 전부 만들었다.

출시했을 때 비슷한 서비스가 이미 3개나 나와 있었다. 6개월 전에는 하나도 없었는데. 시장이 이미 채워진 거다. 3개월 전에 핵심 기능만으로 출시했으면 차별화할 수 있었을 텐데, 완벽하게 만들겠다고 붙잡고 있는 동안 기회가 사라졌다.

Paul Graham이 "Ramen Profitable"에서 강조하는 것처럼, 빠르게 기본적인 생존 가능성을 확보하는 게 중요하다. 사이드 프로젝트에서의 "생존"은 돈이 아니라 사용자다. 사용자가 단 10명이라도 있으면 방향을 잡을 수 있다. 0명인 상태에서 6개월을 혼자 만들면 전부 나의 추측일 뿐이다.

출시 후가 진짜 시작이다#

많은 개발자가 출시를 끝이라고 생각한다. 그래서 출시 전에 모든 걸 완벽하게 만들려고 한다. 근데 현실은 반대다. 출시가 시작이다.

출시 전에 만든 기능 중 사용자가 실제로 쓰는 비율은 체감상 40% 정도다. 나머지 60%는 내가 필요하다고 추측한 것들이다. 출시 후에 사용자가 진짜 필요한 기능은 내가 생각도 못 한 것인 경우가 많다.

그래서 "출시 전에 완벽하게"는 60%의 노력을 낭비하는 거다. 40%만 맞추고 출시한 다음, 나머지 60%를 실제 피드백으로 채우는 게 훨씬 효율적이다.

팀에서 일할 때도 마찬가지다. 기획자가 상세 기획서를 만들어줘도, 실제로 사용자 앞에 가면 예상과 다른 반응이 나온다. 그래서 우리 팀은 "기획 80%, 구현 80%, 출시, 피드백으로 나머지 20% 채우기" 방식으로 일한다. 처음엔 불안했는데, 이 방식이 "기획 100%, 구현 100%, 출시" 보다 결과물이 더 좋다는 걸 여러 번 확인했다.

나의 출시 루틴#

지금은 이런 루틴으로 출시를 결정한다.

1. 프로젝트 시작할 때 Must/Should/Nice 분류. Must가 3개를 넘으면 다시 생각한다. 진짜 3개가 넘을 수도 있지만, 대부분 욕심이다.

2. Must 기능이 돌아가면 내부 테스트. 나 혼자 또는 팀 내부에서 하루 정도 써본다. 크리티컬한 문제가 없으면 다음 단계로.

3. "부끄러움 테스트" 통과하면 출시. 살짝 부끄럽지만 핵심 기능은 잘 돌아가는 상태. 이 상태에서 출시.

4. 출시 후 1주일 집중 모니터링. 사용자 피드백, 에러 로그, 사용 패턴을 집중적으로 본다. 이 1주일에서 얻는 인사이트가 출시 전 3개월 고민보다 더 가치 있다.

5. 피드백 기반 우선순위 재조정. 내가 만든 Should/Nice 리스트를 사용자 피드백과 비교한다. 대부분 순서가 바뀐다. 사용자가 원하는 게 내 예상과 다르니까.

완벽주의와의 싸움#

솔직히 출시를 빨리 하는 게 이론적으로는 맞다는 걸 알면서도, 매번 미루게 된다. "이것만 더 하면" "저것만 더 다듬으면" 하는 생각이 끝없이 이어진다. 이건 완벽주의의 문제이기도 하지만, 더 정확하게는 거부에 대한 두려움이다.

출시하면 평가받는다. "이게 뭐야"라는 반응이 올 수 있다. 출시하지 않으면 평가받지 않는다. 내 머릿속에서는 이 프로젝트가 영원히 잠재적으로 훌륭한 상태로 남아 있을 수 있다. 현실의 평가를 받지 않으니까.

이 두려움을 이기는 방법? 많이 출시해보는 수밖에 없다. 첫 출시는 떨리지만, 세 번째부터는 덜 떨린다. 열 번째에는 "이번엔 어떤 피드백이 올까" 하는 기대감이 두려움보다 커진다. 출시에 익숙해지는 것 자체가 기술이다.

사이드 프로젝트에서 이 근육을 키우면, 회사 업무에서도 "좀 더 다듬고 싶은데 일단 내보내자"는 판단을 할 수 있게 된다. 그리고 그 판단이 대부분의 경우 옳다.

완벽은 없다, 완성은 있다#

마무리하자면, 이건 "대충 만들어라"는 이야기가 아니다. Must Have는 확실히 해야 하고, 치명적인 결함이 있는 상태로 출시하면 안 된다.

핵심은, 완벽과 완성을 구분하는 거다. 완벽은 도달할 수 없는 지점이다. 완성은 "핵심 기능이 동작하고, 사용자가 목적을 달성할 수 있는 상태"다. 완성을 목표로 하면 출시할 수 있고, 완벽을 목표로 하면 영원히 출시 못 한다.

출시는 끝이 아니라 시작이다. 출시해야 사용자를 만나고, 사용자를 만나야 뭘 고쳐야 하는지 알고, 뭘 고쳐야 하는지 알아야 진짜 좋은 제품이 된다. 혼자 방 안에서 완벽하게 만들 수 있다는 건 착각이다.

그러니까 지금 만들고 있는 그거, 조금 부끄럽더라도 내보내자. 피드백이 올 거다. 그 피드백이 다음 버전을 만든다. 그 다음 버전이 또 피드백을 만든다. 이 순환이 결국 좋은 제품을 만드는 유일한 방법이다.