지금까지 이 시리즈는 배포 사고, 성능 조사, 아키텍처 결정 위주로 기록했다. 전부 “코드를 어떻게 고쳤나”의 이야기였다. 그런데 두 달 정도 이 서비스를 운영해보니, 코드보다 오래 남는 건 오히려 그 코드를 왜 그렇게 짰는지에 대한 판단들이었다. 이번 편은 기술이 아니라 기획/제품 관점에서 돌아본 회고다.

건수와 도달은 다른 숫자다

기능을 정리해야 할 시점이 왔을 때, 감으로 고르지 않고 DB를 직접 봤다. 그때 제일 크게 배운 게 하나 있다 — 건수(volume)와 도달(reach)은 완전히 다른 지표라는 것.

연승 베팅은 발생 건수로는 압도적 1위였다. 그런데 그 건수를 만든 사람은 26명뿐이었다. 반대로 평가 기능은 총 93건밖에 안 됐는데, 그마저도 작성자 7명이 대부분을 만든 거였다 — 소수가 헤비하게 쓰는 기능이었던 거다. 반면 구인(LFG) 글은 수 자체는 많지 않았지만, 실제로 가장 많은 사람이 거쳐가는 정문 역할을 하고 있었다.

건수만 봤으면 “연승 베팅이 제일 잘 되는 기능이다”라고 결론 내렸을 거다. 도달을 같이 보고 나서야 “포인트베팅은 연승베팅과 기능이 겹치고 0건이니 정리 1순위, 구인은 글 수가 적어 보여도 손대면 안 되는 핵심 도입부”라는 정반대에 가까운 우선순위가 나왔다. 지표 하나만 보고 기능 우선순위를 매기면 틀린 결론에 확신을 갖게 될 수 있다는 걸 이때 체감했다.


“재사용률이 떨어진다”는 신호를 외면하지 않기

수익화 방향을 이 앱을 다른 모임에도 구독제로 배포하는 쪽으로 잡아둔 상태였다. 그런데 어느 시점부터 재사용률 그래프가 눈에 띄게 떨어졌고, 초대했던 테스터 한 명이 “이것저것 설명하기 어렵다”며 실제로 사이트를 떠났다.

같이 운영하는 친구는 “한 번 보여주면 이해는 쉽다”는 입장이었다. 나는 생각이 달랐다 — 경매 하한가·상한가처럼 자유도를 위해 모임마다 직접 설정해야 하는 기능들이, 그 맥락을 모르는 신규 모임 입장에서는 “그들만의 리그”처럼 진입장벽으로 느껴질 수 있다고 봤다. 승인 절차 하나만 봐도, 우리끼리는 당연한 절차지만 처음 온 사람에겐 “왜 이렇게까지 복잡하지”로 읽힐 수 있다.

이 신호가 불편했던 이유는, 그게 “SaaS로 여러 모임에 팔자”는 방향과 정면으로 충돌하기 때문이었다. 우리끼리 쓰기 편하게 자유도를 늘릴수록, 남에게 팔기는 더 어려워지는 역설이다. 그래서 이후로는 새 기능을 만들 때 “이걸 설정 없이도 신규 모임이 합리적인 기본값으로 바로 쓸 수 있나”를 체크리스트에 넣기로 했다. 아직 완전히 검증된 원인은 아니다 — 다음엔 재사용률 하락 시점과 코호트를 실측해서, 진짜 원인이 설정 장벽인지 아니면 온보딩 자체의 문제인지부터 갈라내는 게 우선이다.


성과를 부풀리지 않는 연습 — 시즌패스

리텐션을 노리고 시즌패스(미션·레벨·보상 시스템)를 만들어 배포했다. 얼마 뒤 “이게 리텐션에 도움이 되냐”는 질문을 받았을 때, 바로 “네, 됩니다”라고 답하고 싶은 유혹이 있었다. 실제로 숫자만 보면 그렇게 보이기도 했다 — 시즌 초반에 참여한 유저들의 후속 잔존율이 93.5%, 미참여자는 77.1%로 꽤 차이가 났으니까.

그런데 이 차이를 그대로 인과로 발표하지 않았다. 이유는 세 가지였다.

  • 관측 기간이 11일뿐이었다.
  • 비교 표본이 31명 대 48명으로 작았다.
  • 하필 같은 기간에 시즌패스와 무관한 성능 개선(N+1 쿼리 배치화, DB 커넥션 풀 확장 등)이 몰려 있어서, DAU 상승분 중 얼마가 시즌패스 덕분인지 분리할 수가 없었다.

그래서 결론은 “긍정적일 가능성은 있으나 지금 확정하기엔 이르다”로 정리했다. 원래 앱에 열심인 유저가 새 기능도 먼저 써보는 것뿐일 수 있다는, 역인과 가능성도 그대로 남겨뒀다. 성과를 그럴듯하게 포장하는 것보다, “아직 모른다”고 정직하게 말하는 게 다음에 더 나은 판단을 하는 데 도움이 된다고 믿는다. 이 검증 로직은 그 뒤로 관리자 페이지의 상시 지표로 옮겨서, 시간이 지나면 저절로 표본과 기간이 쌓이며 답이 더 분명해지게 만들어뒀다.


나중을 미리 깔아두는 설계

친구 둘이서 취미로 운영하던 서비스가 “다른 모임에도 팔 수 있지 않을까”로 방향이 넓어지면서, 몇 가지 구조를 미리 깔아뒀다.

  • 기능 on/off 플러그인 시스템 — 모임마다 필요한 기능만 켤 수 있게. 처음부터 “모든 모임이 우리와 똑같이 쓸 것”이라고 가정하지 않는 구조다.
  • 랭킹 전략 조립식 구조 — 평가 점수, 승률, Glicko-2 배치 레이팅 중 최대 3개를 모임마다 원하는 순서로 조합할 수 있게. 어떤 모임은 평가 없이 순수 배치 시스템만 쓰고 싶어할 수 있다는 가정을 코드가 아니라 설정으로 흡수한다. (자세한 건 12편에 남겨뒀다.)
  • 권한을 플랫폼/모임 2축으로 분리 — “이 사람이 뭘 할 수 있냐”를 하나의 전역 role이 아니라, 플랫폼 관리자 권한과 모임별 운영진 권한으로 나눴다. 모임이 여러 개가 되는 순간 이 구분이 없으면 권한 모델 자체가 무너진다.

다만 여기서 가장 중요했던 판단은 구조가 아니라 속도 조절이었다. 멀티테넌시 전환 견적이 6주 규모로 나왔을 때, “일단 6주 박고 완성형으로 만들자”가 아니라 외부 모임 2~3개를 수동으로 먼저 받아보고 수요부터 검증한 다음, 두 번째 모임이 실제로 확정되면 그때 착수한다는 순서로 정했다. 확신 없는 방향에 6주를 미리 태우는 것보다, 작게 검증하고 늘리는 쪽이 훨씬 덜 위험하다고 판단했다.


문서를 자산으로 만들기

각 기능의 동작 규칙(누가 뭘 할 수 있는지, 어떤 상태 전이가 허용되는지)을 Gherkin 스타일 정책 문서로 정리해뒀다. 처음엔 그냥 “나중에 잊어버리지 않으려고” 만든 문서였는데, 예상 못 한 곳에서 쓸모가 생겼다 — 코드를 고치고 나서 “이게 정책 문서에 맞게 동작하는지” 자체를 검증 기준으로 쓸 수 있게 된 거다. 코드 리뷰가 “문법적으로 맞나”를 넘어서 “기획 의도대로 동작하나”를 확인하는 절차가 된 셈이다.


정리

  • 건수와 도달을 구분하지 않으면, 확신을 갖고 틀린 우선순위를 매길 수 있다. 지표는 하나가 아니라 여러 각도로 봐야 한다.
  • 불편한 신호(재사용률 하락)를 외면하지 않고, 그게 다른 목표(SaaS화)와 충돌한다는 것까지 인정하는 게 다음 판단의 출발점이다.
  • 좋아 보이는 숫자를 성급하게 인과로 발표하지 않는 것도 실력이다. 표본·기간·다른 변수와의 겹침을 밝히는 게, 당장의 성과 보고보다 다음 결정에 더 도움이 된다.
  • 구조는 미리 깔아두되, 그 구조에 확신 없는 시간을 통째로 태우지는 않는다. 작게 검증하고 나서 늘리는 순서를 지켰다.
  • 결국 이 두 달 동안 가장 오래 남을 자산은 특정 기능이 아니라, 측정하고 → 정직하게 검증하고 → 그 결과로 다음 결정을 하는 사이클 그 자체였다.