일주일 만에 만든 카톡 테마 메이커가 5주 동안 버린 것들

이 글의 간판은 "데이터 기반 의사결정"인데, 제가 읽은 건 뺄셈이에요. 프로덕트 디자이너 서란이 클로드와 일주일 만에 카카오톡 테마 메이커를 릴리즈하고 5주를 굴리면서 내린 결정을 세어 보면, 서비스를 살린 쪽은 추가가 아니라 철회였습니다. 인앱 브라우저 다운로드를 버렸고, 인스타그램과 유튜브 홍보를 접었고, 블로그 댓글창을 닫았어요. 반대로 서비스를 키운 추가 기능들은 GA 가 아니라 사용자 한 명의 요청에서 나왔고요. 지표와 요청이 각각 무슨 일을 했는지 갈라서 보면, 이 글은 개인 프로젝트 후기보다 훨씬 쓸모 있는 기록이 됩니다.

GA 가 고쳐준 건 사용자가 아니라 디자이너의 직업병이었다

릴리즈 첫날 약 200명이 들어왔고 그중 80% 가 모바일이었습니다. 카톡 테마 제작은 파일 압축과 정교한 편집이 필요하니 당연히 데스크탑에서 하겠거니 하고 사이트를 데스크탑용으로 만들었는데, 테마를 가볍게 만들고 싶은 사람은 애초에 컴퓨터를 켜지 않았던 거죠. 운영 한 달이 지난 지금도 모바일 비중은 80~90% 예요.

이 숫자에서 제가 보는 건 사용자에 대한 발견이 아닙니다. 카톡 테마를 쓰는 사람이 폰 사용자라는 건 데이터 없이도 짐작할 수 있는 사실이잖아요. 데이터가 뒤집은 건 사용자가 아니라 "정교한 편집은 큰 화면에서" 라는 디자이너의 직업적 전제였어요. 자기 취미를 자기가 쓰려고 만든 제품에서도 만드는 사람의 작업 환경이 사용자의 환경을 덮어쓴다는 게, 저는 이 글에서 가장 정직한 대목이라고 봐요.

두 번째 지표도 같은 결이에요. 세션 리플레이에서 사용자들이 비정형으로 테마를 고치며 화면을 한참 스크롤하는 게 보였고, 섹션으로 바로 가는 네비게이션 탭을 넣었더니 편집 사용자의 65% 가 그걸 썼고 편집 중 이탈률이 약 21.4%p 내려갔습니다.

측정 전후 모수가 200명이라 수치가 튄다는 건 서란도 인정합니다. 저는 그 인정이 옳은 태도라고 보는데, 이유가 조금 달라요. 21.4%p 라는 숫자가 정확해서가 아니라, 이 결정은 세션 리플레이를 본 순간 이미 내려졌기 때문이에요. 스크롤이 지나치게 긴 편집 화면에 탭을 다는 건 지표가 증명해 줄 일이 아니라 디자이너가 그냥 해야 하는 일이고, 지표는 그 뒤에 "맞았다"는 확인을 붙여 준 거죠. 개인 프로젝트에서 GA 의 역할은 결정을 내리는 게 아니라 결정을 되돌릴 근거를 남기는 것에 가깝습니다.

서란 스스로도 GA 는 유입과 이벤트 횟수를 보기엔 좋지만 사용자의 맥락은 안 보인다고 쓰고, 그 빈자리를 문의 댓글 관찰, 세션 리플레이, 그리고 직접 사용자가 되어 보는 것 세 가지로 채웠다고 합니다. 이 글의 결정들을 하나씩 짚어 보면 실제로 방향을 정한 건 이 세 가지였고, GA 는 그 결정이 맞았는지 뒤에서 확인하는 자리에 있었어요.

17% 를 버린 결정

인앱 브라우저 대목이 이 글의 핵심이라고 저는 봐요. 사용자들은 네이버 블로그, 카카오톡, X 안의 브라우저로 들어오는데, 인앱 브라우저 정책상 테마 파일 다운로드가 안정적으로 되지 않았습니다. 아이폰은 공유하기를 띄워 카톡으로 보내는 방식, 안드로이드는 완료 페이지에서 서버가 다운로드 링크를 만들어 주는 방식으로 제각각 대응했는데 로컬에서 되던 게 프로덕션에서 자꾸 어그러졌고요.

데이터를 열어 보니 편집 시도 사용자 중 인앱 브라우저 비율이 17% 였습니다. 사파리와 크롬은 40%대. 17% 는 무시할 수 없는 숫자예요. 그런데 서란은 그 17% 를 위한 다운로드 기능을 철회하고, 인앱으로 들어온 사용자에게는 첫 방문 때 기본 브라우저로 열라고 안내하는 쪽을 택했습니다.

이 결정이 왜 맞느냐면, 17% 를 지키는 비용이 나머지 83% 의 안정성이었기 때문이에요. 인앱마다 다른 정책을 쫓아다니는 동안 서비스 전체가 불안정해졌다고 서란이 직접 적고 있잖아요. 혼자 만드는 제품에서 "지원한다"는 말은 "고장 나면 내가 고친다"는 뜻이고, 그 약속을 17% 에게 하려다 83% 에게 한 약속이 깨지고 있었던 거죠. 지표는 여기서도 무엇을 만들지가 아니라 무엇을 놓을지를 알려줬습니다.

같은 결정이 홍보와 CS 에서 반복돼요. 인스타그램과 유튜브는 반응이 없어 접었고, 블로그 댓글창은 닫고 사이트 안 '의견 보내기'로 모았고, 자주 묻는 질문은 UI 안에 박아 넣었습니다. 틱톡만 남긴 이유도 데이터보다 관찰이에요. 틱톡의 어린 사용자층은 사이트를 찾아오는 것조차 버거워해서, 그들이 있는 곳을 창구로 남겨둔 거죠.

한 명의 요청이 충분한 근거가 되는 조건

추가 쪽은 정반대로 움직였습니다. 저장 기능은 사용자 한 명의 요청에서 시작해 지금 계정 연동자 588명 중 256명이 쓰고, 공유 기능도 한 명의 요청에서 시작해 하루 최대 400개 넘는 링크가 생성됐고 현재도 약 200개가 만들어지며 공유 링크 유입이 18% 예요. 안드로이드 테마는 두세 명의 요청으로 APK 빌드용 서버 작업까지 갔고요.

"적은 사용자의 요청을 다 들어야 하나"에 서란은 성장 기회가 보이면 그렇다고 답하는데, 저는 그 답의 근거를 뒤에 붙은 한 문장에서 찾아요. AI 덕분에 기능 검증 비용이 싸졌다는 문장이요. 요청을 몇 명이 해야 만드느냐는 사실 요청의 수가 아니라 만드는 비용이 정하는 문제거든요. 검증에 2주가 들면 열 명은 모여야 하고, 클로드와 이틀이면 한 명이면 됩니다. DAU 100~150명일 때 받은 요청이 DAU 1,000명일 때 43.54% 사용률과 18% 유입으로 돌아온 건, 요청자가 특별히 안목이 있어서가 아니라 싸게 만들어 보고 아니면 걷어낼 수 있었기 때문이에요.

조건이 하나 붙습니다. 싸게 만든 기능이 서버와 DB 를 쓰기 시작하면 유지 비용이 생기고, 그건 AI 가 줄여 주지 않아요. 서란이 저장을 3개로 제한하고 1년 뒤 소멸시키고 공유 링크를 24시간 뒤 만료시킨 건 그 비용을 정책으로 막은 거고, 저는 이 정책이 기능 자체만큼 중요하다고 봅니다. 한 명의 요청을 듣는 대신 그 기능의 수명을 미리 정해 두는 것. 이게 검증이 싸진 시대에 요청 문턱을 낮추는 대가예요.

디자인 시스템은 지금 숙제가 아니다

마지막 대목에서 한 군데 갈라집니다. 전체 커밋의 30% 가 일관성과 UI 폴리싱이었다는 걸 디자인 기준의 부재로 읽고 다음 숙제를 본격적인 디자인 시스템으로 잡았는데, 저는 순서가 반대라고 봐요. 테마 하나를 완성하는 데 37가지 항목을 거치고 그 흐름이 5주 사이에 반응형 전환, 탭 추가, 인앱 철회, 저장과 공유와 안드로이드 추가를 겪었잖아요. 화면이 이만큼 움직이는 동안 커밋의 30% 가 폴리싱이었다는 건 기준이 없어서라기보다 기준을 세울 표면이 아직 굳지 않았다는 뜻에 가깝습니다. 디자인 시스템을 도입해 본 팀은 알아요. 흐름이 바뀌는 중에 세운 시스템은 다음 달에 시스템 자체를 고치는 일이 됩니다.

오히려 이 글에서 일관성을 실제로 붙들어 준 장치는 다른 데 있어요. 커밋 규칙, 정책 문서, 디자인 시스템 문서, UX 라이팅, 장애 보고서를 써 두고 어떤 상황에 어느 문서를 참조할지 인덱스를 만든 것, 기능을 추가할 때마다 PRD 를 스냅샷처럼 자동 기록하게 한 것. 그게 새 세션에서도 결과물을 안정시켰다고 적혀 있잖아요. 혼자 클로드와 만드는 제품에서 디자인 시스템의 첫 형태는 컴포넌트 라이브러리가 아니라 이 참조 문서예요. 토큰 몇 개와 컴포넌트 목록 한 장을 그 인덱스에 넣는 것으로 시작하고, 37가지 항목의 편집 흐름이 한 달쯤 안 바뀌면 그때 본격적으로 가는 게 맞다고 봅니다.

5주 동안 사용자들이 40~60분씩 테마를 만들고 로컬 스토리지에 저장해 뒀다가 돌아와 완성하는 걸 보며 감회가 새롭다고 했는데, 그 40분이 디자이너가 만든 화면 덕분인지 덕질하는 사람의 집념 덕분인지는 아직 갈라 보지 않은 것 같아요. 그만둘 것을 먼저 고르는 습관은 이미 생겼으니, 다음 5주의 GA 는 그 둘을 가를 수 있을까요?