유저수!=0인 서비스 만들기 (PSF 방법론)

About this offer

서론 개발자를 꿈꾸는 컴공 학생이라면 포트폴리오에 넣을 멋진 프로젝트 하나 만들기를 꿈꾼다. 나도 늘 그래왔다. 기술 스택 정하고, ERD 설계하고, API 명세 쓰고, 배포까지 하면 끝이라고 생각했다. 그런데 배포하고 나서 대시보드를 열어보면... DAU : 0 가입자 : 나, 팀원, 지인 서버는 잘 돌아가는데 쓰는 사람은 없는, 예쁜 쓰레기가 되었다. 돌아보면 지금까지 했던 프로젝트는 전부 이런 순서였다. 아이디어 떠올림 → 기능 정리 → 개발 → 배포 → (아무도 안 씀) → 포트폴리오에 적음 기술적으로는 배운 게 많았다. 그런데 면접에서 "그래서 왜 이 기술을 쓰게 되었나요?"라는 질문을 받으면 할 말이 없었다. 트래픽이 없으니 성능 개선도, 장애 대응도, 사용자 피드백 반영도 전부 가정 일 뿐이었다. SW마에스트로 과정에서 아이디어를 선정할 때도 처음에는 창의적인 솔루션만 생각했다. "이런 거 있으면 좋지 않을까?"로 시작해서 바로 멘토님들께 피드백을 요청했다. 그때 제일 많이 들은 말이 이거였다. "유저 만나봤나요? 그 문제, 진짜 있어요?" 머리로는 당연한 말인데, 막상 하라면 이보다 어려울 수가 없다. 누구를 만나야 하는지, 뭘 물어봐야 하는지, 어디까지 확인해야 "문제가 있다"고 말할 수 있는지 전혀 갈피를 잡을 수 없다. 물론 정답은 없다. 데이터를 분석하더라도 기준은 주관적일 수밖에 없고, 특히 데이터가 적은 초기 서비스일수록 스스로의 판단이 더 중요해진다. 아래에서는 마에스트로에서 프로젝트를 선정하며 문제 가설을 검증했던 과정을 회고해보려고 한다. 1. PSF 방법론이란? PSF(Problem-Solution Fit) : 내가 정의한 문제가 실제로 존재하고, 내 해결책이 그 문제를 푸는지 확인하는 단계 Problem-Solution Fit → Product-Market Fit → Scale (문제가 진짜 있나?) (계속 쓰고 돈 내나?) (키우기) 대부분의 프로젝트는 문제 가설을 건너뛰고 바로 Solution 부터 만든다. 머릿속으로 대충 문제를 정의하고, 그걸 해결하는 독창적인 아이디어에만 집중하게 된다. 가장 큰 함정은 그 문제가 내 머릿속에만 있을 수 있다 는 것이다. 피땀 흘려 만든 서비스를 설명해도 뜨뜻미지근한 반응이 돌아오는 건, 문제가 실존하는지, 그 문제에 반응하는 "페르소나"가 누구인지 검증하지 않았기 때문이다. PSF에서 확인하는 핵심은 두 가지다. 1. 문제가 실존하는가? → 이 불편을 실제로 겪는 사람이 있나 2. 해결책에 반응하는가? → 해결책을 줬을 때 실제로 행동하나 린 스타트업과 맘 테스트(The Mom Test) 같은 고객 개발(Customer Development) 방법론에서 공통으로 강조하는 원칙은 하나다. "의견이 아니라 행동을 본다." "이런 앱 있으면 쓰실 거예요?"라고 물으면 대부분 "네, 좋을 것 같아요"라고 답한다. 엄마한테 물어봐도 좋다고 한다. 그런데 그 사람이 실제로 쓸지는 전혀 다른 문제다. 2. 문제가 실존하는지 확인하는 방법 그 당시 세웠던 여러 문제 가설 중, 서로 다른 방법으로 검증한 3가지를 소개하려고 한다. 시각장애인 안마원 → 만들기 전에 인터뷰 헬스장 환불 → 프로토타입 만들고 반응 측정 셋로그 소개팅 → 직접 주최하기 2-1. 원장님, 이 부분이 힘드신 거 맞을까요? 첫 번째는 아무것도 만들기 전에 사용자를 만나러 가는 방식이었다. 이때 가지고 있던 것은 문제 가설 과 시장조사 데이터뿐이었다. 가설: 시각장애인 원장은 예약 관리, 바우처 행정 같은 전산 업무가 어려워서 어쩔 수 없이 인건비와 불편을 감수하고 있을 것이다. 맘 테스트 원칙대로 아이디어는 숨기고, 최근에 실제로 어떻게 하고 있는지를 묻는 질문지를 만들었다. - 손님은 주로 어떤 경로로 오시나요? - 도와주시는 분이 대신 해주는 업무는 어떤 게 있나요? - 그 업무를 직접 해보신 적 있으세요? 그때 어떠셨어요? - 핸드폰은 어떻게 쓰시나요? - 마법의 지팡이가 있다면 뭘 바꾸고 싶으세요? 첫 관문은 늘 이런 인터뷰에 응해줄 사람을 찾는 것 이다. 집 근처 시각장애인 안마원 정보를 찾아보고, 번호로 문자를 보내거나 전화를 걸었다. 모르는 사람의 인터뷰 요청에 시간을 내줄 이유는 없고, 거절은 당연한 반응이다. 여러 번 거절당한 끝에, 흔쾌히 인터뷰에 응해주신 원장님을 만날 수 있었다. 인터뷰에서 들은 것 업무는 이미 잘 돌아가고 있었다. 예약은 전화와 문자로 원활했고, 청소나 안내는 활동지원사 한 분이 돕고 있었다. 오히려 예상 못 한 답이 나왔다. 문자 입력 방식을 묻자 이렇게 답했다. 음성으로 하면 기계가 발음을 못 알아들어서 오타가 날 수 있잖아요. 눈이 안 보이니까 철자도 모른다는 인식을 손님들한테 남기면 안 되니까, 긴 문장은 블루투스 키보드나 컴퓨터로 작성해서 보내요. 접근성 문제를 이미 스스로 해결하고 있었고 , 그 이유는 편의가 아니라 전문가로서의 자존심 이었다. 마법의 지팡이 질문에는 이렇게 답했다. 보행을 좀 자유롭게 할 수 있으면 좋겠죠. 모르는 길 갈 때가 불편하긴 해요. 가장 큰 불편은 업무가 아니라 일상생활 속에 있었다. 일은 실내에서 하니 큰 어려움이 없었던 것이다. 마지막으로 온라인 홍보를 편하게 해주면 쓰시겠냐고 물었다. 한 번 잘 만든다고 되는 게 아니라 계속 관리를 해야 되잖아요. 손님 후기나 경험담을 남기고 싶은 마음은 있는데, 아직 시행은 안 하고 있어요. PSF 회고 문제가 실존하는가? - 전산 업무 불편 ✗ 이미 활동지원사, 키보드로 해결 중 - 온라인 홍보 관리 △ "마음은 있다"는 의견. 지금 쓰는 시간이나 돈은 없음 해결책에 반응하는가? - 확인 불가 홍보 질문은 사실 내가 해결책을 먼저 꺼낸 거였다. "마음은 있는데 아직 안 하고 있다"는 맘 테스트 기준으로 가장 약한 신호 다. 정말 아픈 문제라면 이미 뭐라도 하고 있었을 것이다. 팀원이 인터뷰한 다른 안마원도 비슷했다. 예약은 전화와 기억으로, 전산 업무는 가족이 대신 하고 있었다. 결론은 우리가 풀 만큼 아픈 문제는 없다 는 것이었다. 코드 한 줄 쓰기 전에 알게 된 게 인터뷰의 가장 큰 수확이었다. 2-2. 헬스장 환불, 안해주면 어떡하죠..? 두 번째는 방식을 바꿨다. 헬스장 환불로 고생하는 사람은 한곳에 모여 있지 않아서 직접 찾아가기 어렵다. 그래서 핵심 기능만 있는 프로토타입 을 먼저 만들고, 행동 데이터로 확인하기로 했다. 아이디어 정리는 대략 아래와 같다. 헬스장 환불은 법적 기준이 명확하다. 위약금은 10%까지만, "환불 불가" 약관은 무효다. 그런데도 사람들은 법을 모르고, 절차가 귀찮아서 적당히 합의하거나 포기할 거라고 봤다. 이 내용을 바탕으로 최소 기능의 프로토타입을 구현했다. 바이브 코딩이 쉬워지면서, 고객 의견을 모으는 것보다 최소 기능을 만드는 게 더 빠를 때도 있는 것 같다. 링크 - claimauto 지금 상황을 입력하면 법적 기준에 맞는 환급액을 보여주고, 헬스장에 보낼 문서까지 만들어주는 서비스다. 결제 금액, 이용 기간 입력 ↓ 법적 기준으로 환급액 자동 계산 ↓ 헬스장에 보낼 PDF 청구서 발급 만든 링크는 헬스장 환불로 고민하는 사람이 있을 만한 커뮤니티에 직접 올렸다. 왼쪽부터 에브리타임, 지역 커뮤니티, 지식인 답변 그리고 Mixpanel을 붙여서 사람들이 핵심 기능까지 오는지 확인했다. 일별 지표 (4/27 ~ 5/4) 날짜 방문자 폼 제출 PDF 저장 4/27 67명 5명 2명 4/28 73명 5명 0명 4/29 19명 1명 0명 4/30 16명 2명 1명 5/1 7명 0명 0명 5/2 3명 1명 1명 5/3 17명 2명 0명 5/4 6명 0명 0명 합계 208명 16명 4명 방문 208명 → 폼 제출 16명 (7.7%) → PDF 저장 4명 (폼 제출자의 25%) PSF 회고 문제가 실존하는가? - △ 8일 동안 208명이 들어왔고 16명은 자기 계약 정보를 직접 입력했다 환불로 고민하는 사람은 분명히 있다 해결책에 반응하는가? - ✗ 환급액 확인까지는 왔지만 PDF 청구서를 받은 건 4명 "얼마 받을 수 있나"는 궁금해도, 그걸 들고 헬스장과 싸울 생각까지는 없었다 문제 자체는 있었다. 하지만 헬스장 환불은 1년에 한 번 겪을까 말까 한 문제고, 이 해결책은 그 순간의 궁금증 은 풀어줬지만 행동 까지 이어지진 못했다. 그래도 이번엔 "잘 안 됐다"가 아니라 어느 단계에서 멈췄는지 를 숫자로 말할 수 있었다. 측정을 붙인 덕분이다. 2-3. 셋로그로 소개팅 한 번 주선해볼까.. ᄒᄒ 세 번째는 인스타 릴스 하나에서 시작했다. 셋로그 앱으로 단체 소개팅을 하는 게 유행이다. 셋로그는 친구끼리 하루 일상을 짧은 영상으로 공유하는 앱이다. 정해진 규칙은 없다. 원하는 사람을 초대해서 원할 때 올리면 된다. 이걸 소개팅에 쓰는 걸 보면서 이런 생각이 들었다. "사람에게 호감을 느끼게 하는 건 결국 프로필이 아니라 일상 속에서 나오는 매력 아닐까?" 그래서 자유로운 셋로그 앱 위에 우리만의 형식 을 얹었다. 남녀 3:3으로 방을 만들고, 딱 3일 동안 서로의 일상을 공유하고, 마지막 날 마음에 드는 사람을 고른다. 이번엔 앱을 먼저 만들지 않았다. 이미 있는 셋로그 앱으로 소개팅을 직접 주최했다. 코드 한 줄 없이 사람이 손으로 서비스를 돌린 셈이다. 에브리타임, 인스타 모집 ↓ 신청 폼 ↓ 3:3 방 편성 → 셋로그에서 3일간 일상 공유 ↓ 최종 선택 → 서로 고르면 연락처 전달 소개팅 자체는 사실 이미 존재하는 시장이기 때문에, 이번 검증의 질문은 "사람들이 이걸 할까?"가 아니었다. 문제: 외모와 스펙으로 빠르게 판단하고, 매칭 뒤엔 억지로 대화를 이어가야 하는 기존 소개팅 방식에 지친 사람이 있는가? 해결책: 3일 동안 서로의 일상을 보고 고르는 방식에 실제로 돈과 시간을 쓰는가? 처음엔 방이 3일 동안 제대로 굴러가는지만 확인했고, 이후 기수마다 더 세분화된 지표를 트래킹하게 되었다. 신청 → 참가비 입금 → 3일간 영상 업로드 수 → 최종 선택 비율 → 서로 매칭률 → 재참가 수 → 신청 ... 기수가 끝날 때마다 최종 선택과 함께 설문도 받았다. 지표와 설문을 정리하면 이렇다. PSF 회고 문제가 실존하는가? - ✓ 참가비를 내고 신청했다. 누적 120명 최근 1년 데이팅 앱 사용 경험은 7% (7~8기 설문) → 앱 대신 소개팅, 과팅을 받던 사람들이 이 방식을 선택했다 해결책에 반응하는가? - ✓ 3일 동안 영상을 올리고 최종 선택까지 왔다. 누적 27쌍 매칭 - ✓ 상대를 고른 이유 1위는 외모(44%)가 아니라 영상 속 댓글과 반응(52%) (7~8기 설문) → "일상을 보고 고른다"는 가설이 행동으로 확인됐다 - △ 업로드를 안 한 이유 1위는 "올릴 게 없어서" → 방식은 맞는데, 올리게 만드는 장치가 필요했다 세 번의 검증 중 처음으로 문제와 해결책 둘 다 행동 으로 확인됐다. 다음 기수에 다시 신청하는 사람도 생기기 시작했다. 우리 방식을 좋아해 주는 첫 팬이었다. 그런데 여기서 한계가 보였다. 셋로그는 남의 앱이라 기능을 바꿀 수도, 로그를 볼 수도 없었다. 업로드 수 같은 지표도 전부 손으로 셌다. PSF는 확인했지만, 해결책을 더 좋게 만들려면 우리가 직접 바꿔가며 검증할 수 있는 판 이 필요했다. 운영하며 막힌 곳이 그대로 우리 앱의 출발점이 됐다. 셋로그로 운영하며 막힌 곳 → 우리 앱에서 바꾸는 것 기능도 못 바꾸고 로그도 못 봄 → 미션, 질문, 선택 방식을 직접 바꿔가며 데이터로 검증 한 사람 영상만 모아 볼 수 없음 → 참가자별로 모아 보기 궁금한 걸 물어볼 방법이 없음 (못 친해짐) → 방 안 채팅, 질문 미션 운영자가 방에 들어가 미션을 올림 → 앱이 미션을 던지고, 최종 선택도 앱 안에서 머릿속에서 정한 기능이 아니라, 몇 기수를 손으로 돌리면서 부딪힌 문제에서 나온 기능이다. 지금은 셋로그로 하던 소개팅을 우리 앱 하루하루 에서 운영하고 있다. 기존에 쌓아 올린 데이터와 참가자 덕분에 앱으로도 1~2기를 원활하게 진행할 수 있었고, 우리의 가장 큰 고민은 이제 "사용자가 0명이면 어떡하지?"가 아니라 "더 많은 사용자를 유지하려면 무엇을 해야 하지?"로 바뀌었다. 세 아이디어 모두, 앱을 만들기 전에 유저를 먼저 만나보며 판단할 수 있었다. 3. 회고 안마원 인터뷰 → 문제 가설이 틀렸음을 확인했다 헬스장 프로토타입+측정 → 문제에는 중간 정도 반응했으나, 행동으로 이어지지 않았다 셋로그 직접 주최 → 사람이 돈과 시간을 쓰는 걸 봤고, 팬이 생겼다 뒤로 갈수록 사용자가 내놓는 게 커졌다. 말 < 클릭 < 시간과 돈 그리고 PSF를 확인하고 나서야 "무엇을 만들지"가 정해졌다. 셋로그 사례에서 앱의 기능은 아이디어 회의가 아니라, 운영하며 막힌 곳에서 나왔다. 개발은 검증의 끝이 아니라, 검증을 계속하기 위한 도구였다. 물론 다른 의견도 있을 수 있다. 안마원 인터뷰에서 가장 큰 불편이 일상생활 속 불편함이었다면 그 문제를 더 파고들면 좋겠다고 생각하는 사람도 있을 것이고, 헬스장 문제도 다른 솔루션을 만들어 인터뷰해가며 발전시키면 좋은 서비스가 될 수도 있을 것이다. 이 과정의 핵심은 "문제가 존재하는가? → 해결책이 이 문제에 적합한가?"를 끊임없이 자문해야 한다는 것이다. 개발자는 주어진 문제 를 어떻게 해결할지에 집중하는 경향이 있다. 하지만 정작 "그 문제가 실존하는가?"라는 질문에 답해본 컴공 학생은 많지 않다고 생각한다. 실사용자가 있는 서비스를 만들고 싶거나, 대 바이브 코딩 시대에 토이 프로젝트 가 아닌 돈을 버는 서비스를 혼자서 기획해보고 싶다면, 코딩보다 언제나 먼저 답해야 하는 질문이 있다. "이 문제 때문에 지금 이미 시간이나 돈을 쓰고 있는 사람이 있는가?" 개발은 언제나 그다음이다.