제안서 대신, 진짜 사업으로

제안서 대신, 진짜 고객을 데려왔습니다

신사업 제안은 보통 문서에서 시작해요. 시장 규모를 추정하고, 기대 임팩트를 계산하고, 리소스를 요청하죠. 그런데 이번엔 순서를 뒤집었어요. 제안서 대신 실제로 돌아가는 사업을 먼저 만들어 시장에 물어봤거든요.

솔직하게 밝히면, "2주"는 달력의 2주가 아니에요. 약 3개월간 주말과 휴가를 갈아 넣었고, 그 시간을 워킹타임으로 환산하니 대략 2주 분량이었어요. 다시 말해 이 글은 "2주 만에 뚝딱"이라는 마법이 아니라, 3개월간 주말을 쓸 만큼의 몰입과 그걸 2주치로 압축해 낸 AI 활용 이야기예요.

사업자 등록, 제품, 제휴, 운영 구조까지 세우고 모두의렌탈이라는 이름으로 시장에 내놨어요. 그리고 손에 쥔 건 예측치가 아니라 실제 고객이 남긴 신청 데이터였습니다.

실제로 시장에 내놓은 모두의렌탈. "숨어있는 렌탈 지원금을 돌려받는다"는 가치를 전면에 걸었어요.

이 글은 "뚝딱 만들었다"는 무용담이 아니에요. 직무가 다른 3명이 각자의 문제의식으로 뭉쳐, 눈앞의 제품을 넘어 조직이 일하는 방식까지 바꾼 기록이에요.

왜 시작했나: "시도의 비용이 너무 높아지고 있지 않나?"

모요에는 Focus on Impact라는 중요한 원칙이 있었어요. 임팩트가 큰 일에 집중하자는 거였죠. 저는 이 원칙을 믿었어요. 다만 신사업/탐색 영역에서는 조금 다르게 작동해야 한다고 생각했어요.

임팩트가 큰 일을 고르려면 시작 전에 임팩트를 증명해야 해요. 그런데 아직 시장에 없는 신사업은 증명 자체가 가장 어려운 일이에요. 그러다 보면 "이게 정말 될까?"를 확인하는 문서·검토·합의의 비용이 계속 커지고, 정작 시장에 물어보는 일은 뒤로 밀리죠.

그래서 이번엔 "될지 안 될지"를 논쟁하는 대신, 가장 작은 규모로 실제로 만들어서 시장에 물어보기로 했어요.

불투명한 지원금을 투명하게, 라는 가설

출발점은 시장의 기회였어요. 렌탈 시장은 빠르게 커지고 있지만, 고객 입장에서는 지원금이 불투명하고 비교할 방법이 없는 구조였거든요. 얼마를 지원받는 건지, 왜 이 금액인지, 더 받을 수 있는 건 아닌지, 기준 자체가 없었어요.

이건 모요가 통신 시장에서 이미 풀어온 문제와 핏이 정확히 맞았어요. 흩어진 정보를 모아 투명하게 비교해 주는 것, 모요가 가장 잘하는 일이니까요.

흩어진 지원금을 한눈에 비교. 모요가 통신에서 풀던 문제를 렌탈에 그대로 옮겼어요.

문제는 검증 방법이었어요. 렌탈은 사업자 등록, 제휴, 정산, 배송·운영까지 실체가 있는 구조를 요구해요. 보통이라면 "팀을 꾸리고 몇 달"이 필요한 일이죠. 그런데 그렇게 하면 다시 "시도의 비용이 너무 높다"는 원래 문제로 돌아가요.

그래서 이 실체 있는 구조를 남는 시간만으로 세울 수 있는지가 진짜 챌린지였어요. 여기서 AI가 결정적인 역할을 했습니다.

AI를 팀원 삼아, 세 명이 사업을 세운 법

3명이 역할을 나눠 뛰었지만, 사업자·제품·제휴·운영을 모두 세우기엔 손이 부족했어요. 이 빈자리를 AI가 메웠어요. 단순 보조가 아니라, 문제 정의부터 기획, 개발, 운영까지 전 과정에서 팀원처럼 활용했죠. 실제로 어떻게 썼는지, 사례로 풀어볼게요.

페인 포인트를 데이터로 찾았어요

"렌탈 시장의 진짜 페인 포인트가 뭘까?" 보통이라면 설문이나 인터뷰로 몇 주가 걸리는 질문이에요. 대신 커뮤니티·후기 데이터를 AI로 대량 수집한 뒤, 자동으로 라벨링·분류했어요. 수작업이었다면 며칠이 걸렸을 작업을, AI로 몇 시간 만에 끝냈죠.

그 결과 "불투명한 지원금" 이 압도적인 1순위 불만으로 올라왔어요. 감이 아니라 데이터로 문제를 정의했기 때문에, 이후 가설과 제품 방향이 흔들리지 않았어요.

수집한 데이터를 가격 민감도 × 탐색 의지 축으로 분류했어요. "비교형", "최적화형" 같은 고객 유형이 데이터에서 드러났어요.

기획자가 직접 만들고, 개발자가 풀스택으로 뛰었다

기획과 개발 사이의 핸드오프를 없앤 게 속도를 낸 가장 큰 비결이었어요. PO도 개발자도 자기 직함 안에만 머물지 않았거든요.

기획자(PO)는 기획서를 넘기는 대신, 바이브코딩으로 직접 화면을 구현했어요. 머릿속 아이디어를 AI에게 던지면 초안이 나오고, 피드백하고, 수정하고, 이 사이클이 몇 시간 단위로 돌았죠. 기획한 사람이 바로 만드니까 "이거 기획 의도랑 다른데요" 같은 핸드오프 손실이 아예 없었어요.

개발자(Problem Solver)는 코드에만 머물지 않았어요. AI로 인프라·백엔드·프론트를 풀스택으로 구축한 건 기본이고, 사업자 등록에 필요한 제도·약관 리서치, 경쟁사 분석, 가격 구조 설계까지 파고들었죠. 낯선 도메인의 벽도 AI에게 먼저 정리시키고 사람은 판단과 검증에 집중하는 방식으로 빠르게 넘었어요.

AI를 '일관된 팀원'으로 만든 건 context와 agents였어요

바이브코딩이 이렇게 빨랐는데도 결과가 매번 흔들리지 않은 데는 이유가 있어요. AI에게 뭘 시키기 전에, "우리가 어떤 제품을 어떤 원칙으로 만드는가"를 먼저 코드 저장소 안에 적어뒀거든요. 매번 긴 프롬프트를 새로 쓰는 대신 AI가 읽을 세계를 repo 안에 만들어 둔 거예요.

중심은 context였어요. 우린 이걸 프롬프트가 아니라 제품 운영 메모리로 봤고, 세 층으로 나눴어요.

• Canonical context: 제품 목적, 아키텍처 원칙, 품질 기준, 읽는 순서. AI가 매번 같은 세계관 위에서 판단하게 잡아주는 기준이에요.
• Task-local context: 이번 작업의 목표·범위·완료 기준. PRD나 기획 스펙처럼 이 작업에서만 유효한 결정을 적어둬요.
• Adapter context: Codex·Claude·Cursor 같은 도구가 각자 읽는 파생 지시문. 도구마다 형식은 달라도 진짜 기준은 항상 repo 안에 뒀어요.

그 위에 agents를 얹었어요. 여기서 오해하기 쉬운 게, agent를 사람처럼 여러 명 띄운 걸로 상상하는 거예요. 실제론 혼자 돌아다니는 봇이 아니라 AI가 한 문제를 여러 관점으로 나눠 보게 만드는 역할의 경계에 가까웠어요. 사업 판단 흐름에 이렇게 붙여뒀고요.

• PO: 이 요청, 지금 만들 만한가? 목표는 충분히 잡혀 있나?
• PM: 성공 지표와 완료 기준이 실제로 테스트 가능한가?
• PD: CTA·신뢰 요소·정보 구조가 전환 목표에 맞나?
• FE: 라우트·모듈·컴포넌트 경계가 유지되나?
• BE: 검증·저장·이벤트 규약이 깨지지 않나?
• Evaluator: 낼지·고칠지·멈출지를 독립적으로 판정하고 남기는가?

역할을 나눈 건 병렬로 빨리 돌리려는 목적만은 아니었어요. 그보다 AI가 답 하나를 너무 빨리 확정해버리지 못하게 막고 싶었어요. 0→1에선 "그럴듯한 구현"보다 "지금 이 문제를 푸는 게 맞나"가 훨씬 중요하니까요. 그래서 구현하는 관점과 평가하는 관점을 떼어놓고 제품 판단과 코드 판단을 한 답변에 섞지 않으려 했어요.

이렇게 해두니 AI가 잘하는 구간과 사람이 꼭 잡아야 하는 구간이 또렷하게 갈렸어요. 규칙 안에서 초안을 빠르게 뽑고 여러 관점으로 자기 답을 되짚는 건 AI가 잘했어요. 반대로 "이 금액이 진짜 맞나", "이걸 지금 푸는 게 맞나" 같은 최종 판단은 여전히 사람 몫이었고요.

AI를 매번 새로 지시하는 단발성 도구로 쓰면 속도는 나도 방향이 샜어요. 맥락과 역할을 저장소 안에 고정해두면 AI가 프로젝트를 아는 동료처럼 같은 방향으로 움직였고요. 세 명이 사업 하나를 통째로 세운 진짜 비결은 화려한 프롬프트가 아니라 여기, 이 거버넌스에 있었어요.

제휴 제안서도, 눈에 안 보이는 운영까지도

실제 신청과 거래가 일어나려면 제휴 파트너와 정산·배송·CS 운영 구조가 필요해요. 문서로 흉내 낼 수 없는, 실체가 필요한 부분이었죠. 제휴 제안서, 커뮤니케이션 문서, 운영 예외 케이스 정리를 AI로 빠르게 초안화하고 사람은 파트너 설득과 의사결정에 집중했어요.

AI로 초안을 잡은 제휴 제안서. 사람은 파트너 설득과 의사결정에 집중했어요.

"못 한다"의 기준선이 내려갔어요

여기서 얻은 감각은 분명했어요. "리소스가 부족해서 못 한다"의 기준선이 AI로 크게 내려갔다는 것. 3명만으로도 문제 정의, 기획, 개발, 제휴, 운영까지 실체 있는 사업을 세울 수 있었어요. 이게 이번 프로젝트의 가장 큰 발견이에요.

AI-native하게 일한다는 건 개발자를 대체하는 방식이 아니었어요. 오히려 제품 판단·설계 판단·구현 판단·출시 판단을 더 또렷하게 나누는 방식이었죠. AI는 그 사이를 빠르게 왕복하게 해줬고 repo 안의 context와 agents는 그 왕복이 매번 다른 방향으로 새지 않게 잡아줬어요.

눈에 보이는 고객 화면만 만든 게 아니에요. 상품·정책·제휴·접수를 관리하는 운영 백오피스(어드민)까지 직접 붙여, 서비스가 매일 안정적으로 굴러가게 만들었어요. 구글시트와 수기 쿼리로 버티는 운영이 아니라, 어드민으로 관리되는 실제 서비스를 세운 거죠.

고객 화면 뒤에서 서비스를 굴리는 운영 백오피스까지 직접 구축했어요. 상품·정책·제휴·접수를 한 곳에서 관리해요.

3명이 직무 경계를 넘어 붙었다

이 프로젝트는 처음부터 3명이 함께 시작했어요. 역할도 직무도 달랐지만, "렌탈 × 통신, 직접 해보자"는 문제의식은 같았거든요.

BD는 파트너를 뚫는 자기 축에 집중했지만, PO와 개발자는 직함을 넘어 둘 다 'Problem Solver'처럼 일했어요. 기획자는 바이브코딩으로 화면을 직접 찍어냈고 개발자는 제도 리서치부터 인프라·운영까지 스스로 파고들었거든요. AI가 그 경계를 넘는 비용을 확 낮춰준 것도 컸고요.

누구도 "그건 제 일이 아니에요"라고 하지 않았어요. 문제가 있으면 각자의 자리에서 풀 방법을 찾아 붙는 것, 이게 모요에서 일이 굴러가는 방식이에요.

시장의 답: 신청 100건

준비가 끝난 뒤 모두의렌탈을 실제로 오픈했어요. 이제부터는 제 예측이 아니라 시장이 답할 차례였죠. 결과는 데이터로 돌아왔어요.

문서상의 기대치가 아니라, 실제로 쌓인 신청 데이터.

작은 규모였지만 의미는 컸어요. "될 것 같다"가 아니라 "됐다"를 손에 쥐었으니까요. 어떤 정교한 제안서보다 강한 증거였습니다.

제품을 넘어, 일하는 방식으로

이 결과를 개인 경험으로 남길 수도 있었어요. 하지만 더 중요한 건 "이 방식이 조직에 유효한가"였어요.

그래서 검증 데이터를 근거로 회사에 제안했어요. 신사업 탐색은 ① 빠르게 만들고 ② 시장에서 검증하고 ③ 결과물로 증명하는 방식으로 접근하자고요. 완벽한 사전 증명 대신, 작은 실행으로 실제 신호를 먼저 확인하자는 제안이었죠.

직접 0 to 1을 해보며 확인한 것들을 팀에 공유했어요. 작은 실험이 조직 차원의 대화로 이어진 순간.

이 제안이 받아들여진 건 데이터가 뒷받침했기 때문이에요. 문제의식과 실행이 실제 결과로 증명될 때, 조직은 움직여요. 작은 시도 하나가 제품 검증을 넘어, 조직이 신사업을 다루는 방식을 두고 나눈 대화로 이어졌어요.

이런 동료들과, 이런 조직에서

돌아보면 이번 프로젝트가 가능했던 건 두 가지 덕분이에요.

하나, 문제 앞에서 직무 경계를 따지지 않는 동료들. 제휴·운영·조직 제안 어디든, 필요하면 자기 문제처럼 붙는 사람들이 있었어요. 그리고 AI를 새로운 팀원처럼 쓰는 게 자연스러운 문화가 있었고요.

둘, 개인의 문제의식이 실제 변화로 이어질 수 있는 조직. 주말에 시작한 작은 실험이 회사의 일하는 방식에 대한 제안까지 갈 수 있었던 건, 결과로 이야기하면 조직이 귀 기울인다는 걸 알았기 때문이에요.

신사업은 완벽한 증명에서 시작하지 않아요. 빠르게 만들고, 시장에서 검증하고, 결과물로 증명하는 것. 그리고 그 작은 시도가 제품·사업·조직의 변화로 이어질 수 있다는 것. 이번 모두의렌탈이 남긴 가장 큰 배움이에요.

문제를 발견하면 직접 만들고, AI를 팀원처럼 쓰고, 데이터로 증명하는 일. 이런 방식으로 일하는 조직이 궁금하다면, 지금 모요에 합류해주세요.

Product Owner 지원하기