회사 다니면서 창업 테스트하는 법: 주 7시간 90일 검증 루틴

먼저 결론부터. 회사 다니면서 창업을 테스트할 때 제일 먼저 정할 건 아이템이 아니다. “일주일에 몇 시간을, 언제 쓸 수 있는가”다. 그 시간 안에서 작은 문제 하나를 골라 90일 동안 돈을 낼 사람이 있는지만 확인한다. AI 도구는 만드는 속도를 올려주지만, 무엇을 만들지와 누가 돈을 낼지는 여전히 내가 사람을 만나서 알아내야 한다.

이 글을 다시 쓰게 된 이유

퇴근하고 노트북을 여는 건 처음 몇 주는 꽤 설렌다. 아이디어도 많고, Cursor나 Claude Code를 켜면 화면이 금방금방 나오니까 뭔가 굴러가는 느낌이 든다. 문제는 3주차쯤부터다. 회의가 길어진 날은 저녁 먹고 소파에 앉는 순간 그날은 끝이고, 주말에 몰아서 하겠다고 미뤄둔 일은 일요일 밤에 그대로 남아 있다. 나도 그랬다. 기능은 늘어나는데 써주는 사람은 없었고, 지금 내가 뭘 검증하고 있는지 스스로도 한 문장으로 설명을 못 했다.

그 시기를 지나고 나서 정리된 생각은 하나다. 직장인의 사이드 프로젝트가 멈추는 건 의지가 약해서라기보다 설계가 없어서다. 쓸 수 있는 시간, 만들 범위, 멈출 기준을 처음에 정해두지 않으면 성실한 사람일수록 더 오래, 더 지친 채로 끌고 간다. 예전에 써둔 90일 로드맵에 실제로 부딪히면서 추가하게 된 것들, 그러니까 시간표, 회사와 겹치는 부분 확인, 자주 망하는 지점, 체크리스트를 보태서 다시 정리했다.

관점은 처음과 같다. 퇴사하고 크게 시작하지 말고, 월급이라는 안전망이 있을 때 작게 만들어서 유료 반응부터 확인하자는 것.

이런 분께 맞는 글

퇴근 후 사이드 프로젝트를 만들고는 있는데 몇 달째 출시 직전에서 맴도는 직장인
AI 코딩 도구로 MVP까지는 만들 수 있는데, 정작 무엇을 검증해야 하는지 막히는 1인 개발자
퇴사 전에 월 30만 원, 100만 원, 300만 원처럼 단계별 목표를 세워두고 싶은 예비 창업자

시작하기 전에: 회사와 겹치는 부분부터 확인한다

재미없는 얘기라 다들 건너뛰는데, 순서상으로는 이게 제일 먼저다. 미리 말해두면 나는 법률 전문가가 아니고, 아래 내용은 법률 자문이 아니다. 다만 사이드 프로젝트 때문에 회사와 껄끄러워지는 경우는 대체로 비슷한 지점에서 시작되는 것 같아서, 내가 시작 전에 확인했던 항목을 그대로 옮긴다. 회사마다 규정이 다르기 때문에 결국은 내 회사 문서를 직접 읽어보는 게 출발점이다.

취업규칙과 근로계약서의 겸업 조항. “겸업 금지”, “영리 활동 시 사전 승인” 같은 문구가 있는지 본다. 조항이 있다고 퇴근 후의 모든 활동이 자동으로 막힌다고 단정하기는 어렵다는 이야기도 있지만, 해석은 사안마다 다르다. 애매하면 인사팀에 문의하거나 노무사, 변호사 상담을 받아보는 쪽이 마음이 편하다.
본업과 경쟁하는 구조인지. 회사 고객에게 비슷한 걸 파는 구조라면 위험도가 확 올라간다. 처음부터 본업과 시장이 겹치지 않는 문제를 고르는 게 가장 깔끔하다.
영업비밀과 회사 자료. 회사에서 알게 된 고객 명단, 내부 데이터, 코드, 문서는 사이드 프로젝트로 가져오지 않는다. 내가 원래 갖고 있던 일반적인 노하우와 회사 자산 사이의 경계는 생각보다 흐릿하다. 그래서 보수적으로 잡는다.
회사 장비와 근무 시간. 회사 노트북, 회사 계정, 회사 클라우드 크레딧, 근무 시간은 쓰지 않는다. 개인 노트북과 개인 이메일로 처음부터 계정을 분리해두면 나중에 “이건 누구 거냐”는 문제가 생길 여지가 줄어든다.
업무 결과물의 귀속 조항. 개발 직군이라면 계약서에 직무발명이나 업무상 저작물이 회사에 귀속된다는 조항이 들어 있는 경우가 있다. 만드는 게 본업 업무 범위와 가까울수록 꼼꼼히 확인한다.
매출이 생긴 뒤의 사업자 등록과 세금. 첫 결제가 들어오기 시작하면 사업자 등록, 종합소득세 신고 같은 문제가 따라온다. 이 부분은 국세청 안내나 세무사 상담을 기준으로 확인한다. 결제를 실제로 붙일 단계라면 국내 PG와 해외 MoR 중 무엇을 고를지 한국에서 Stripe 대안 찾기: 토스페이먼츠·Paddle·Polar·Lemon Squeezy 비교에 정리해 두었다.

이걸 확인하는 데는 한두 시간이면 된다. 반대로 이 단계를 건너뛰고 석 달을 달렸다가 회사와 문제가 생기면 그 석 달이 통째로 사라진다. 시간 대비 효율로 따지면 이만한 투자가 없다.

현실적인 주 7시간 시간표

직장인에게 제일 부족한 건 아이디어가 아니라 시간이다. 그래서 나는 “시간 날 때 한다”는 말을 버리고, 일주일에 쓸 시간을 먼저 박아두는 방식으로 바꿨다. 아래는 그렇게 버틸 수 있었던 형태에 가깝게 정리한 예시다. 출퇴근 거리나 가족 상황에 따라 숫자는 얼마든지 바꿔도 된다. 원칙은 하나다. 평일엔 짧고 가벼운 일, 주말엔 집중이 필요한 일.

요일	시간	하는 일
월	30분	지난주 기록을 보고 이번 주 목표를 딱 한 줄로 적는다.
화	60분	잠재 고객에게 메시지를 보내거나 통화 한 건을 한다.
수	0분	일부러 비운다. 야근이나 회식이 몰리는 날로 남겨둔다.
목	60분	작은 수정 하나, 또는 고객이 말한 불편 하나를 고친다.
금	30분	이번 주에 한 일과 배운 점을 공개 기록으로 남긴다.
토	3시간	집중이 필요한 개발, 랜딩페이지, 결제 붙이기.
일	60분	숫자를 확인하고 다음 주 계획을 세운다. 계속할지 판단하는 시간이기도 하다.

이 표에서 제일 중요한 칸은 의외로 수요일이다. 처음엔 매일 한 시간씩 하겠다고 계획했는데, 일주일 중 하루는 꼭 무너졌다. 그러면 그 하루 때문에 “이번 주는 망했다”는 기분이 들고, 그 기분이 주말까지 이어졌다. 처음부터 쉬는 날을 하나 정해두니까 계획이 깨지는 일이 확 줄었다.

일요일 한 시간도 빼먹지 않는 게 좋다. 개발을 안 하더라도 숫자를 보고 다음 주에 할 일을 정해두면, 월요일 저녁에 “오늘 뭐 하지”를 고민하느라 30분을 날리지 않는다. 그리고 주 7시간을 넘기는 주가 3주 이상 이어지면 그건 열정이 아니라 경고등이라고 생각한다. 본업이 흔들리기 시작하면 사이드 프로젝트도 같이 무너진다.

직장인 사이드 프로젝트가 자주 멈추는 이유

아이디어가 나빠서 망하는 경우는 생각보다 적다. 더 자주 보이는 건 순서가 거꾸로 된 경우다. 일단 만들고, 고객에게는 나중에 묻는다. 내가 겪었거나 주변에서 자주 본 패턴을 적어보면 이렇다.

먼저 만들고 나중에 물어본다. 고객과 대화 없이 기능을 쌓으면 출시 후 “좋네요”라는 말만 듣고 결제는 일어나지 않는다. 칭찬은 공짜라서 신호가 약하다.
너무 큰 제품을 잡는다. 대시보드, 로그인, 결제, 관리자 페이지, 알림까지 한 번에 만들려다 보면 3개월이 그냥 지나간다. 직장인에게 3개월은 체력이 바닥나는 시간이기도 하다.
멈출 기준이 없다. 언제 계속하고 언제 접을지 정하지 않으면, 매주 조금씩 고치다가 어느 날 그냥 안 열게 된다. 접은 것도 아니고 계속하는 것도 아닌 상태가 제일 오래 사람을 붙잡는다.
AI 도구를 개발 속도에만 쓴다. Cursor, Claude Code, Lovable 같은 도구는 구현을 빠르게 해주지만, 고객의 지불 의사를 대신 확인해주지는 않는다. 오히려 만들기가 쉬워진 만큼 “일단 만들어보자”의 유혹이 커졌다.
회사에서 일하던 방식을 그대로 가져온다. 기획서를 길게 쓰고, 디자인을 다듬고, 완성도 높게 출시하려고 한다. 회사에서는 맞는 방식이지만, 혼자 주 7시간으로 하는 실험에서는 대부분 과하다.
혼자만 알고 있다. 부끄러워서, 혹은 아이디어를 뺏길까 봐 아무에게도 안 보여준다. 그러면 피드백도 없고, 마감도 없고, 그만둬도 아무도 모른다.

공개된 인디 제품 사례에서 반복되는 패턴

TypingMind, ProjectionLab, Lunch Money 같은 인디 제품이 만들어진 과정을 찾아 읽어보면 분야는 다 다른데 겹치는 부분이 있다. 셋 다 멋진 기술을 보여주려고 시작했다기보다는, 만든 사람이 실제로 겪던 불편에서 출발했다는 점이다. 그 공통점을 좋은 신호와 위험 신호로 나눠보면 이렇다.

관찰 포인트	좋은 신호	위험 신호
문제 출발점	본인이 반복해서 겪는 불편에서 시작한다.	유행하는 기술을 먼저 정하고 쓸 곳을 찾는다.
초기 제품 범위	한 가지 작업을 확실히 줄여준다.	처음부터 플랫폼, 커뮤니티, 마켓플레이스를 꿈꾼다.
성장 방식	만드는 과정, 실패, 숫자를 꾸준히 공개한다.	완성 전까지 아무에게도 보여주지 않는다.
수익 검증	무료 칭찬보다 유료 결제, 예약, 대기자 명단을 본다.	조회수와 좋아요만 보고 시장성을 판단한다.

여기서 읽어야 할 건 “대단한 사람이라 성공했다”가 아니다. 작은 문제를 좁게 잡았고, 빨리 보여줬고, 돈을 낼 사람을 일찍 만났다는 것. 직장인이 따라 할 수 있는 건 정확히 이 세 가지다.

90일 동안 무엇을, 어떤 순서로 검증할까

회사에 다니면서 하는 실험이라면 기간을 90일 이상 열어두지 않는 걸 권한다. 90일이면 작게 만들고, 고객을 만나고, 결제 반응을 한 번은 볼 수 있다. 동시에 안 되는 아이디어를 미련 없이 정리하기에도 적당하다. 기간이 끝없이 열려 있으면 “조금만 더”가 반년이 된다.

1~2주차: 문제 하나만 고른다

처음엔 아이디어 목록이 아니라 반복되는 고통을 적는다. 아래 질문에 솔직하게 답해본다.

이번 주에 세 번 이상 반복한 귀찮은 작업은 무엇이었나?
그 작업 때문에 시간, 돈, 신뢰, 매출 중 무엇을 잃고 있나?
나 말고 같은 문제를 겪는 사람을 열 명 이상 떠올릴 수 있나?
그 사람들이 이 문제를 해결하려고 이미 쓰는 대체재가 있나?

마지막 질문이 제일 중요하다. 대체재가 전혀 없다면 아무도 생각 못 한 기회일 수도 있지만, 경험상으로는 아무도 돈을 내지 않는 문제인 경우가 더 많았다. 엑셀로 버티고 있다, 알바를 쓰고 있다, 비싼 툴을 억지로 쓰고 있다. 이런 대답이 나오면 오히려 반가운 신호다.

이 시기에 하지 말 것: 도메인 사기, 로고 만들기, 기술 스택 비교. 전부 재미있지만 검증과는 상관이 없다. 어떤 문제를 고를지 감이 안 잡힌다면 개발자 1인 창업자가 검토해볼 만한 Micro SaaS·AI 제품 8선을 후보 목록 삼아 위 질문에 하나씩 대입해 봐도 된다.

3~4주차: 코드보다 먼저 대화한다

MVP를 만들기 전에 잠재 고객 열 명과 이야기해본다. 거창한 인터뷰일 필요는 없다. 메신저로 15분 통화를 부탁하거나, 커피 한 잔 사겠다고 해도 된다. 질문은 이 다섯 개면 충분했다.

이 일을 지금은 어떻게 처리하고 있나요?
가장 짜증 나는 순간은 언제인가요?
이 문제 때문에 실제로 손해 본 시간이나 돈이 있나요?
이미 돈을 내고 쓰는 도구가 있나요?
제가 일주일 안에 아주 단순한 해결책을 만들면 써보실 건가요?

대화하면서 내 아이디어를 설명하는 시간은 최대한 줄인다. 설명을 길게 하는 순간 상대는 예의상 맞장구를 쳐주기 시작한다. “좋은 아이디어네요”보다 귀 기울여야 할 말은 “나오면 알려주세요”, “지금 쓰는 것보다 낫다면 돈 낼 수 있어요”, “우리 팀에서도 한번 써볼게요” 같은 쪽이다. 구체적인 행동이 따라붙는 말일수록 믿을 만하다.

열 명을 못 채우는 경우도 많다. 그럴 땐 그 자체를 데이터로 본다. 같은 문제를 겪는 사람을 열 명도 못 찾는다면, 나중에 고객 100명을 찾는 건 더 어렵다.

B2B 쪽이라면 인터뷰 메모를 정리하고 내 가설을 반박하는 질문을 뽑는 데 AI를 붙여 볼 만하다. 어디까지 믿고 어디서 사람이 판단해야 하는지는 B2B SaaS 검증, 코딩 전에 해야 할 일에 따로 적어 두었다.

5~8주차: 기능 하나짜리 MVP를 만든다

이제야 AI 도구를 본격적으로 쓴다. 다만 MVP는 작아야 한다. 로그인, 결제, 관리자 기능을 한 번에 넣기보다 아래 같은 일 하나만 확실히 해결한다.

CSV를 올리면 보고서 초안을 만들어준다.
URL을 넣으면 링크 미리보기와 요약을 만들어준다.
반복되는 이메일 답장을 템플릿으로 생성해준다.
Notion, Slack, Google Sheets 사이를 오가는 반복 복사를 자동화한다.

이 단계의 목표는 완성도가 아니라 사용자가 자기 실제 데이터를 넣어보게 만드는 것이다. 샘플 데이터로 데모를 보는 것과 자기 엑셀 파일을 직접 올려보는 건 완전히 다른 반응을 만든다. 초기 사용자 몇 명은 내가 옆에서 같이 써보면서 막히는 곳을 직접 보는 게 좋았다. 화면 공유 30분이 설문 50개보다 많은 걸 알려줬다.

이 시기에 하지 말 것: 회원가입 플로우 다듬기, 다크 모드, 팀 기능. 열 명이 쓰기 전까지는 대부분 필요 없다. 이 단계를 Lovable로 시작할지 Bolt.new로 시작할지 고민된다면 두 플랫폼을 1인 창업 관점에서 비교한 글을 먼저 보고 하나만 고르는 편이 크레딧을 아낀다.

9~12주차: 유료 신호를 확인한다

무료 사용자는 생각보다 쉽게 모인다. 하지만 SaaS든 콘텐츠든 결국 중요한 건 가치 교환이다. 그래서 이 시기엔 일부러 가격을 붙여본다. 정식 결제 시스템이 없어도 된다. 계좌 이체나 간단한 결제 링크로 선결제를 받아보거나, “유료 버전 대기자”로 따로 신청을 받아봐도 된다. 가격을 말하는 게 어색하면, 그 어색함 자체가 아직 제품에 확신이 없다는 신호일 수 있다.

90일째에는 아래 숫자를 냉정하게 본다.

지표	계속할 만한 기준	멈추거나 바꿀 기준
잠재 고객 대화	10명 이상과 직접 대화	대화 없이 혼자 개발만 함
실사용자	반복 사용자가 5명 이상	가입 후 재방문이 거의 없음
유료 신호	선결제, 유료 대기자, 컨설팅 문의 중 하나 발생	칭찬은 많지만 결제 의사가 없음
운영 피로도	주 6~8시간 안에 유지 가능	매주 15시간 이상 쓰고도 개선이 없음

이 기준은 내가 정한 출발점일 뿐이고 정답은 아니다. 중요한 건 숫자를 미리 정해두는 것이다. 90일째에 기준을 정하면 사람은 어떻게든 계속할 이유를 찾아낸다. 첫날 정해두면 90일째의 나는 그 기준을 따르기만 하면 된다.

결과가 애매할 때는 세 갈래로 나눈다. 문제는 맞는데 해결 방식이 틀렸으면 MVP를 바꾼다. 해결 방식은 좋은데 고객이 틀렸으면 대상을 바꾼다. 둘 다 아니면 접는다. 접는 것도 실패가 아니라 다음 90일을 아낀 결과다.

AI 도구는 어디에 써야 효과가 있나

AI를 “글 빨리 쓰기”나 “코드 많이 만들기”에만 쓰면 콘텐츠도 제품도 같이 얇아진다. 시간이 없는 직장인일수록 아래 같은 일에 쓰는 편이 체감이 컸다.

인터뷰 정리: 고객 대화 메모나 녹취를 문제, 대체재, 지불 의사로 나눠 정리한다. 다만 AI 요약은 내가 듣고 싶은 쪽으로 기울기 쉬워서, 원문 메모는 꼭 따로 남겨둔다.
MVP 범위 줄이기: 만들고 싶은 기능 스무 개를 적어 주고 “주말 하루에 만들 수 있는 한 가지만 남겨줘”라고 요청한다. 혼자 고르면 다 아까워서 못 버린다.
랜딩페이지 초안: 기능 나열이 아니라 고객 문제, 쓰기 전과 후, 가격 가설을 정리하는 데 쓴다. 문구는 결국 내 말투로 다시 고친다.
사용 기록 읽기: 어디서 이탈하는지, 어떤 기능을 반복해서 쓰는지 로그를 요약하게 한다.
운영 자동화: 문의 답변 초안, 온보딩 메일, 피드백 분류처럼 매주 반복되는 일을 넘긴다. 주 7시간에서 30분만 아껴도 체감이 크다.

자주 망하는 지점과 피하는 방법

90일을 돌려보면 거의 매번 비슷한 곳에서 걸린다. 미리 알고 있으면 덜 다친다.

본업 마감과 겹치는 주

분기 말, 큰 릴리스, 인사 평가 시즌에는 사이드 프로젝트가 가장 먼저 밀린다. 이걸 의지로 이기려고 하면 둘 다 망가진다. 90일 계획 안에 처음부터 “쉬는 주” 한 주를 넣어두고, 그 주에는 일요일 30분 점검만 한다.

기능 추가로 도망치기

고객에게 연락하는 게 불편하면 사람은 코드 속으로 숨는다. 이번 주에 기능을 두 개 이상 추가했는데 고객과는 한 번도 이야기하지 않았다면 도망치는 중일 가능성이 높다. 내 규칙은 간단하다. 고객 대화 한 건 전에는 새 기능을 시작하지 않는다.

지인 칭찬 착시

친구, 동료, 가족은 대부분 좋게 말해준다. 고마운 일이지만 검증 데이터로는 약하다. 지인 반응은 따로 적어두고, 모르는 사람의 반응과 섞지 않는다.

도구 쇼핑

새 AI 도구가 나올 때마다 갈아타면서 세팅하는 데 주말을 쓴다. 90일 동안은 쓰던 도구를 그대로 쓴다고 정해두면 마음이 편하다. 도구를 바꾸는 건 문제가 생겼을 때만.

가격 미루기

“조금 더 좋아지면 돈 받아야지”라는 생각은 거의 항상 늦다. 가격을 붙였을 때 사람들이 떠나는지 남는지를 보는 것 자체가 검증이다.

90일이 지나도 질질 끌기

기준을 못 넘었는데 아까워서 계속하는 경우. 이럴 땐 완전히 접기 어렵다면 “다음 30일 동안 딱 하나만 바꿔서 다시 본다”처럼 범위를 좁게 연장한다. 그래도 안 되면 정리한다.

체크리스트

시작 전

취업규칙과 근로계약서의 겸업, 영업비밀, 결과물 귀속 조항을 읽어봤다.
개인 노트북, 개인 이메일, 개인 결제 수단으로 계정을 분리했다.
본업과 고객이 겹치지 않는 문제를 골랐다.
일주일에 쓸 시간과 요일을 정했다.
90일째 계속할지 판단할 숫자를 미리 적어뒀다.

매주 일요일

이번 주에 고객과 몇 번 대화했나?
내가 만든 것을 누가 실제로 써봤나?
쓴 시간이 계획보다 많았나, 적었나?
다음 주에 할 일을 한 줄로 쓸 수 있나?

90일째

미리 정한 기준과 실제 숫자를 나란히 놓고 봤다.
계속, 방향 전환, 정리 중 하나를 골랐다.
배운 점을 짧게라도 글로 남겼다.

당장 이번 주말에 해볼 수 있는 4시간

시간이 정말 없다면 아래 순서대로 4시간만 써본다.

30분: 내가 반복해서 겪는 업무나 생활 속 문제를 열 개 적는다.
30분: 그중 돈이나 시간을 가장 많이 잡아먹는 문제 하나를 고른다.
60분: 같은 문제를 겪을 만한 사람 열 명에게 보낼 짧은 메시지를 쓴다.
90분: AI 도구로 랜딩페이지 초안과 기능 하나짜리 MVP의 화면 구성을 잡는다.
30분: X, LinkedIn, 디스콰이엇, GeekNews 중 한 곳에 “이 문제 검증 중”이라고 공개 기록을 남긴다.

자주 받는 질문

회사에 미리 말해야 하나요?

회사 규정에 따라 다르다. 사전 승인이나 신고를 요구하는 조항이 있다면 그 절차를 따르는 게 맞다. 조항이 애매하면 인사팀에 일반적인 기준을 먼저 물어보거나 전문가 상담을 받아보는 걸 권한다. 숨기는 게 습관이 되면 나중에 더 큰 부담으로 돌아온다.

평일에 한 시간도 안 나는데 가능할까요?

가능하긴 하지만 기간을 늘려야 한다. 주말 3~4시간만 쓸 수 있다면 90일 대신 120일로 잡고, 대신 범위를 더 줄인다. 평일엔 출퇴근길에 고객 메시지 답장이나 메모 정리처럼 휴대폰으로 할 수 있는 일만 한다.

개발을 못하는데 AI 도구만으로 MVP를 만들 수 있나요?

Lovable이나 Bolt 같은 도구로 간단한 화면과 흐름은 꽤 만들 수 있다. 다만 결제, 개인정보, 보안이 걸리는 부분은 쉽게 보면 안 된다. 처음엔 노코드 폼이나 스프레드시트, 사람이 직접 처리하는 수동 서비스로 시작해서 수요를 먼저 확인하는 방법도 충분히 괜찮다.

얼마를 벌면 퇴사해도 될까요?

정해진 숫자는 없다고 생각한다. 나는 금액보다 몇 가지 조건을 같이 본다. 매출이 몇 달 연속으로 유지되거나 늘고 있는지, 생활비를 몇 개월 버틸 저축이 있는지, 지금 막혀 있는 게 정말 시간 부족 때문인지. 마지막 질문에 “아니다”라는 답이 나오면 퇴사해도 상황이 크게 달라지지 않을 가능성이 높다.

아이디어를 공개하면 누가 베끼지 않을까요?

그럴 수도 있다. 그런데 초기 단계에서 더 흔한 문제는 베끼는 사람이 아니라 아무도 관심을 주지 않는 것이었다. 실행 과정과 고객 관계는 쉽게 복사되지 않는다. 그래도 걱정된다면 핵심 노하우는 빼고 “어떤 문제를 검증하고 있는지” 정도만 공개해도 충분하다.

90일이 끝났는데 결과가 애매하면요?

위에서 말한 세 갈래로 나눠본다. 문제가 맞는지, 해결 방식이 맞는지, 고객이 맞는지. 하나만 바꿔서 30일 더 해보는 건 괜찮지만, 아무것도 바꾸지 않고 연장하는 건 대체로 시간만 쓴다.

퇴사는 목표가 아니라 결과다

회사 다니면서 창업을 테스트하는 사람에게 첫 목표는 퇴사가 아니다. 작은 고객 문제를 찾고, 그 문제에 누군가 돈을 낼지 확인하는 것. 월 30만 원의 첫 매출, 다섯 명의 반복 사용자, 세 명의 유료 대기자 같은 작은 숫자가 먼저다. 그 숫자가 쌓이면 퇴사는 결심이 아니라 자연스러운 다음 단계가 된다.

DP42에서는 앞으로도 이런 작은 실험을 계속 기록하려고 한다. 성공담보다 검증 과정, 도구보다 의사결정, 조회수보다 실제 수익 구조 쪽으로. 지금 사이드 프로젝트를 하고 있다면, 이번 주에는 기능을 하나 더 만들기 전에 고객 한 명과 먼저 이야기해보자. 그 15분짜리 대화가 다음 90일을 아껴줄 수 있다.