이 제품은 거의 전부 혼자 만들었다. 주로 저녁, 주말, 그리고 인정하고 싶지 않을 만큼 많은 휴일을 썼다. 오랫동안 웹에 공개되어 있어도 여전히 개인 프로젝트처럼 느껴졌다.
그 감각은 결제를 켠 순간 바로 달라졌다. 코드가 갑자기 더 고급스러워진 것은 아니다. 바뀐 것은 제품에 대한 내 책임이었다. 누군가 돈을 낼 수 있게 되면 망가진 flow는 더 이상 “나중에 고칠 edge case”로만 볼 수 없다. 온보딩, 모더레이션, 리텐션, 신뢰, 안정성은 미래의 문제가 아니라 지금 제품이 약속하는 경험의 일부가 된다.
이번 launch에서 가장 크게 배운 점은 이것이다. 기능이 많은 solo project를 만드는 것과 실제 product를 운영하는 것은 서로 다른 일이다.
Solo development에서는 attention이 병목이 됐다
이 제품을 만드는 동안 나는 소셜 미디어에서 거의 사라졌다. launch strategy가 아니었다. 제품 결정, 구현, edge case, flow testing, release 준비가 모두 같은 제한된 시간을 놓고 경쟁했기 때문이다.
이제 solo development의 이 부분을 훨씬 잘 이해한다. 병목은 언제나 코드 작성 속도가 아니다. 제품 안에서 늘어나는 state, transition, failure mode에 얼마나 attention을 줄 수 있느냐가 더 큰 제약이 된다.
성공한 build만으로는 이 질문에 답할 수 없다. 성공한 결제 한 번도 마찬가지다.
결제는 버그의 의미를 바꿨다
결제 전에는 일부 거친 부분을 “나중에 고칠 것”으로 생각할 수 있었다. 결제가 live된 뒤에는 그 mental model이 더 이상 맞지 않았다. 유료 제품이라고 bug-free여야 한다는 뜻은 아니다. 그건 현실적이지 않다. 하지만 다른 사람이 이미 돈을 맡긴 제품에서 알려진 문제를 해결하지 않고 두는 비용은 달라진다.
온보딩과 모더레이션도 같다. 개발 중에는 “진짜” feature를 둘러싼 support system처럼 보일 수 있다. production에서는 사용자가 직접 경험하므로 feature 자체의 일부다. 리텐션도 비슷하다. 첫 session이 좋았다고 해서 다시 돌아올 이유까지 제공했다는 뜻은 아니다.
결제가 이 제품의 완성을 증명한 것은 아니다. 오히려 “완성”이라는 단어 뒤에 얼마나 많은 일이 숨어 있었는지를 드러냈다.
Launch는 다른 종류의 정보를 줬다
release 후에는 보기 좋은 스크린샷으로 보여주기 어려운 일이 시작됐다. 공개 후에야 보이는 버그, 깨진 flow, 사용자가 오면서 현실이 되는 모더레이션 문제, 그리고 좋은 첫인상을 만드는 것보다 훨씬 어려운 리텐션 문제다.
나는 이런 signal을 과도하게 해석하지 않으려고 한다. release 후 bug가 나왔다고 자동으로 architecture가 나쁘다는 뜻은 아니다. 리텐션 문제 하나만으로 product-market fit을 진단할 수도 없다. 모더레이션 이슈가 있다고 전체 system이 unsafe하다는 증거도 아니다. symptom은 어디를 조사할지 알려줄 뿐, 원인을 자동으로 설명해주지는 않는다.
달라지는 것은 evidence의 질이다. launch 전에는 사용자가 어떻게 행동할 것이라고 예상하는지를 테스트할 수 있다. launch 후에는 그들이 실제로 무엇을 하는지 다뤄야 한다. release는 uncertainty가 사라지는 순간이 아니다. 가장 중요한 uncertainty 일부가 처음으로 관찰 가능해지는 순간이다.
지금 사용하는 post-launch loop
지금은 launch story를 예쁘게 만드는 것보다 그 이후의 일에 더 관심이 있다. 결제에서 얻은 교훈, 깨진 flow, 모더레이션 과제, 사용자 행동, 리텐션의 예상 밖 결과, 그리고 제품을 조금씩 더 신뢰할 수 있게 만드는 작은 수정들이다.
- 실제 flow를 본다. 내가 설계한 path가 사용자가 실제로 가는 path와 같다고 가정하지 않는다.
- Symptom과 cause를 분리한다. 실패한 step은 문제가 어디서 생겼는지 보여주지만 왜 생겼는지까지 자동으로 알려주지는 않는다.
- Trust-sensitive failure를 우선한다. 결제, 접근, 온보딩, 모더레이션은 실패 비용이 더 크므로 cosmetic issue보다 우선순위가 높다.
- 가장 작은 verified problem부터 고친다. 추측을 바탕으로 전체 system을 redesign하기보다 확인된 friction 하나를 제거하는 편을 택한다.
- 수정 후 사용자 경험을 다시 확인한다. code change가 기술적으로 맞아도 user-facing problem을 해결하지 못할 수 있다.
이것은 보편적인 framework가 아니다. 이 제품을 만드는 단계에서 운영하는 단계로 넘어오면서 내게 가장 합리적으로 느껴진 작업 방식일 뿐이다.
Launch는 내 source of truth를 바꿨다
지금 가장 중요하게 보는 차이는 제품을 만들었다와 제품을 운영할 준비가 됐다 사이에 있다. building은 system이 내가 설계한 일을 할 수 있는지 묻는다. operating은 실제 사람이 사용하고, 오해하고, 떠나고, 돌아오고, 결제하고, 예상하지 못한 path에 들어갔을 때 무슨 일이 생기는지를 묻는다.
그래서 나는 launch를 더 이상 finish line으로 보지 않는다. launch 전 evidence 대부분은 내 가정과 test에서 나온다. launch 후에는 제품이 실제 행동, 실패, 반복 사용을 통해 답하기 시작한다.