불확실한 문제를 구조로 정리해 실제 서비스로 만들어요

미스고는 출시 이후 2년 동안 앱으로만 서비스되어 왔어요. 그러는 사이 유료 구독 전환율은 1%대에서 멈춰 있었고, 신규 가입은 늘지 않으면서 이탈하는 분들은 점점 많아졌어요. "경·공매 매물은 화면이 커야 비교가 된다"는 의견이 VOC로 계속 들어왔는데, 경쟁사들은 이미 PC 환경을 잘 갖춰가고 있어서 더 미루기 어려운 상황이었어요.

앱 전용 서비스를 4개월 안에 PC 웹으로 새로 만들어야 했어요. 와이어프레임 설계부터 앱·웹 정책 정리, 유관팀 협업, 일정 관리까지 거의 혼자 맡아 진행했고, 결과적으로 전환율·매출·가입자 모두 의미 있게 끌어올렸어요.

• PC 웹을 처음부터 만들기 — 앱 화면을 그대로 옮기지 않고, PC에서 더 잘 쓰이는 기능(매물 여러 개를 동시에 비교, 지도 넓게 보기, 어드민 대시보드 등)을 골라 와이어프레임을 새로 그렸어요. 모바일에서만 의미 있던 기능은 과감히 빼고, PC에서 필요한 기능을 추가했고요.
• 앱·웹이 같은 그림을 보게 만들기 — 한쪽에서 본 매물·찜·결제 정보가 다른 쪽에서 어긋나지 않도록 데이터 흐름과 정책을 정리했어요. 중복 로그인 처리 기준, 디바이스별 응대 규칙, 반응형이 깨지지 않을 화면 폭 단위, 지도 줌 단계와 마커 노출 규칙까지 문서로 남겨뒀어요.
• 대표·디자인·개발·데이터팀 사이 다리 역할 — 각 팀이 처한 상황과 우선순위가 달라서, 그 사이를 오가며 결정을 모아주는 일을 했어요. 의견이 부딪히는 지점은 추측 대신 데이터로 근거를 만들어 차근차근 풀어갔고, 그렇게 매주 한 단계씩 결과물이 쌓이는 흐름이 자리잡았어요.
• 일정 빈틈없이 굴리기 — 4개월이 짧다 보니 작업 순서를 먼저 그려보고, 동시에 진행할 수 있는 일은 디자인·개발·QA가 같이 움직이도록 나눴어요. 일정이 꼬이면 막힐 수 있는 핵심 단계는 매주 따로 챙겨봤고, 덕분에 처음 세웠던 일정 안에서 무리 없이 마무리할 수 있었어요.
• 전환율·매출·가입자 함께 끌어올리기 — 결제로 가는 동선을 짧게 만들고 구독 혜택을 더 잘 보이는 자리에 배치했더니 전환율이 1%대에서 3%대로 올라왔어요. 매물이 노출되는 방식과 판매자 어드민도 손봐서 월 매출이 95.6% 늘었고, PC 검색으로 들어오는 분들에 맞춰 랜딩과 가입 절차를 다듬으면서 가입자도 두 배가 됐어요.
• 출시 후에도 손 놓지 않기 — QA 케이스를 미리 정리해두고, 런칭 직후엔 VOC를 바로바로 확인하면서 이슈를 빠르게 잡았어요. 초기에 들어온 피드백으로 결제 흐름에서 살짝 걸리던 부분까지 한 번 더 다듬었고요.

신규 구독자·매출처럼 표면 지표만 간단히 잡혀 있어서, 그 안쪽에서 무슨 일이 벌어지고 있는지는 알 길이 없었어요. 결제 단계마다 어디서 막히는지, 마케팅·영업 활동이 매출로 얼마나 이어졌는지, 사용자가 어디로 들어와서 어디서 빠져나가는지 — 이런 흐름을 볼 수 없으니 운영팀의 결정이 거의 감으로 이뤄지고 있는 상태였어요.

마케팅·영업·CS 팀과 먼저 이야기 나누면서 진짜 필요한 지표를 정리했고, 영향이 큰 항목부터 차례대로 다섯 번에 걸쳐 풀었어요. 단순히 숫자를 늘어놓는 게 아니라 운영팀이 한눈에 흐름을 볼 수 있도록 화면을 짜는 게 핵심이었어요.

• 표면 너머 깊은 데이터 시각화 — 결제·환불·구독 변경처럼 한 단계씩 들여다봐야 보이는 데이터를 한 화면에 모아 보여줬어요. 어디서 매출이 새는지, 어디서 사용자가 멈추는지 운영팀이 직접 확인할 수 있게 됐어요.
• 결제·매출 전략 분석 — 단순 매출 합계가 아니라 결제 수단별, 구독 플랜별, 환불 사유별로 쪼개 본 데이터를 묶어 매출 흐름을 검증할 수 있는 화면을 만들었어요.
• 마케팅·영업 성과 트래킹 — 캠페인 유입과 영업 활동이 실제 매출로 얼마나 이어지는지 매주 확인할 수 있도록 지표를 묶었어요. 마케팅·영업이 자기 활동의 결과를 스스로 들여다볼 수 있게 됐고요.
• 진입·트래픽·이탈 플로우 시각화 — 사용자가 어디로 들어와서 어떤 화면을 거쳤다가 어디서 떠나는지 깔때기로 그려, 단계별 이탈 지점을 한눈에 볼 수 있게 했어요.
• 데이터 기반 UI/UX 개선으로 연결 — 통계에서 잡힌 이탈 지점을 토대로 가입·결제 화면을 다시 손봤어요. 통계 시스템 구축이 숫자 보기로 끝나지 않고 실제 사용자 경험 개선까지 이어지도록 만들었어요.
• 다섯 번 나눠 배포로 안정화 — 한 번에 끝내지 않고 확인할 수 있는 단위로 쪼개서 배포했어요. 각 단계에서 운영팀 피드백을 반영하면서 안정성을 챙겼고, 마케팅·영업의 주간 업무 효율이 40% 개선됐어요.

서비스 콘셉트의 큰 방향을 바꾼 결정.

디자이너가 없는 환경이라 화면·정책·기능 정의까지 모두 PO가 직접 끌고 갔어요. 빈 자리를 메우는 게 아니라, 일관성 있는 결과물이 나오도록 처음부터 시스템을 잡았어요.

• 서비스 비전·정책서 — 인증 사용자 중심 메신저라는 큰 그림부터 채팅·게임·AI 캐릭터·트렌드 피드 각 영역의 운영 정책까지 한 권으로 묶어 팀이 같이 볼 기준점을 만들었어요.
• 와이어프레임 단독 작성 — 메신저 흐름, 게임방 UI, 캐릭터 화면, 트렌드 피드, 어드민까지 모든 화면을 직접 그렸어요. 일관된 정보 구조와 인터랙션 패턴으로 정리.
• 디자인 토큰·컴포넌트 정의 — 색상·타이포·간격을 토큰으로 묶고 자주 쓰이는 패턴(채팅 버블, 카드, 모달, 바텀시트, 게임 입력 UI)을 컴포넌트 단위로 표준화했어요. 디자이너가 합류해도 그대로 이어받을 수 있는 형태로요.
• 기능 정의서 — 사용자 플로우·예외 케이스·관리자 운영 시나리오까지 분리해 적었어요. 개발이 의사결정을 다시 묻지 않아도 진행할 수 있는 수준으로 디테일을 채웠고요.

채팅방 안에서 친구들과 함께 즐길 수 있는 미니게임을 11종 기획했어요. 게임을 단순히 추가한 게 아니라, 채팅 흐름을 끊지 않고 자연스럽게 녹아드는 형태로 풀었어요.

• 세 가지 결로 분류 — 빠르게 답하는 퀴즈형(자음·모음·이모지·노래제목·아재개그·눈코입·행맨), 함께 그리는 협력형(재미 스케치), 머리 쓰는 추리형(라이어·양세찬·묵찌빠) — 채팅 텐션을 다르게 가져갈 수 있도록 결을 나눴어요.
• 실시간 동기화 정책 — Firebase Realtime DB를 기반으로 모든 참가자가 같은 게임 상태를 보도록 정의. 정답·문제·턴 정보가 사용자 화면에서 어긋나지 않도록 동기화 우선순위를 정리했어요.
• 정답 보안 처리 — 정답을 클라이언트에 그대로 내려주면 보이는 문제가 있어서, 암호화해서 전달하고 클라이언트에서는 검증만 가능한 구조로 설계했어요.
• 자동 정답 판정 — 사용자가 채팅으로 답을 적으면 서버가 자동으로 정답 여부를 판정하고 힌트·결과 메시지를 흘려보냈어요. 게임 진행이 끊기지 않도록.
• 캐릭터와 연동 — 게임 승리 시 AI 캐릭터 '재미'의 친밀도·경험치 보상으로 이어지도록 묶어, 게임이 주는 재미와 캐릭터가 자라는 재미를 한 줄로 엮었어요.

채팅 중심 진입 → 랜딩 중심 진입으로 화면 흐름을 뒤집은 경험.

• 처음 가정 — 사용자 입장에서는 들어오자마자 채팅이 보이는 게 자연스러울 거라 봤어요
• 다시 보니 — 채팅은 결국 둘 사이의 사적인 공간이라, 처음 들어온 분 입장에서는 "여기에 뭐가 있는지"를 살펴볼 자리가 없다는 걸 발견했어요
• 결정 — 그래서 로그인하지 않아도 볼 수 있는 랜딩을 메인 진입점으로 다시 짰어요
• 덧붙여서 — 기다리는 시간이 지루하지 않도록 콘텐츠와 인터랙션을 채팅에 들어가기 전 단계에 먼저 배치했어요