바이브코딩으로 앱부터 만들기 전에 고객 한 명의 일을 직접 해결하고 돈부터 받아봐야 하는 이유를, 사주·이력서 분석 사례와 실제 창업 사례로 짚었습니다.
요즘은 아이디어가 생기면 바로 만들 수 있습니다. 클로드코드나 코덱스를 켜고 “이런 서비스 만들어줘”라고 말하면 화면부터 로그인, 결제까지 며칠 안에 나옵니다. 코드를 몰라도 됩니다. 바이브코딩이 구현에 드는 시간과 돈을 많이 줄였습니다.
그런데 제품을 만들었다고 사업을 시작한 건 아닙니다.
바이브코딩으로 앱부터 만들기 전에 고객 한 명의 일을 직접 해결하고 돈부터 받아봐야 하는 이유를, 사주·이력서 분석 사례와 실제 창업 사례로 짚었습니다.
요즘은 아이디어가 생기면 바로 만들 수 있습니다. 클로드코드나 코덱스를 켜고 “이런 서비스 만들어줘”라고 말하면 화면부터 로그인, 결제까지 며칠 안에 나옵니다. 코드를 몰라도 됩니다. 바이브코딩이 구현에 드는 시간과 돈을 많이 줄였습니다.
그런데 제품을 만들었다고 사업을 시작한 건 아닙니다.
사용할 사람을 구했는지, 그 사람이 무엇 때문에 돈을 내는지, 내가 그 문제를 실제로 해결할 수 있는지는 그대로 남아 있습니다. AI가 코드는 써주지만 이 세 가지까지 확인해주진 않습니다.
그래서 요즘 앱을 만들겠다는 사람에게는 이 말을 먼저 하고 싶습니다.
제발 IT 창업부터 하지 마세요. 먼저 서비스를 해보세요.
사주 앱을 만들고 싶다고 해보겠습니다. 생년월일을 넣으면 AI가 사주를 분석하고, 매달 구독료를 받는 서비스입니다. 바이브코딩으로 충분히 만들 수 있습니다.
그 전에 사주 상담으로 돈을 받아본 적이 있나요?
사람들은 어떤 고민을 들고 오는지, 첫 상담에서 무엇을 묻는지, 어떤 답을 듣고 만족하는지, 한 번 보고 끝나는지 다시 찾아오는지 알아야 합니다. 상담 한 번에 얼마를 받았을 때 실제로 결제하는지도 봐야 하고요.
이 일을 한 번도 해보지 않았다면 AI가 내놓은 사주 분석이 좋은지부터 판단하기 어렵습니다. 고객이 결과를 마음에 들어 하지 않을 때 사주가 틀린 건지, 설명이 부족한 건지, 애초에 고객이 원한 답과 다른 건지도 알 수 없습니다.
이력서 분석 AI도 같습니다. 이력서를 직접 받아서 고쳐주고, 왜 그렇게 고쳤는지 설명하고, 그 대가로 돈을 받아봐야 합니다. 어느 경력은 앞으로 빼야 하는지, 지원하는 직무마다 무엇을 바꿔야 하는지, 고객은 첨삭과 상담 중 어디에 더 돈을 내는지 직접 봐야 합니다.
직접 좋은 이력서를 골라내지 못하는데 AI가 쓴 분석은 어떻게 검토할까요. 고객 한 명에게 결과를 설명하지 못하는데 앱 안에서는 무슨 문장을 보여줘야 할까요.
소개팅 앱을 만들고 싶다면 몇 쌍이라도 직접 연결해보면 됩니다. 마케팅 자동화 서비스를 만들고 싶다면 작은 가게 한 곳의 마케팅을 맡아볼 수 있고요. 예약 관리 서비스를 만들고 싶다면 예약을 직접 받아 정리해보면 됩니다.
왜 직접 해본 적도 없는 일을 IT로 만들면 잘할 수 있다고 생각할까요.
지인에게 아이디어를 말하면 대개 좋다고 해줍니다. 무료 앱을 열어보겠다는 사람도 쉽게 구할 수 있습니다. 그 반응만으로는 사업인지 알기 어렵습니다.
직접 서비스를 팔면 네 가지를 한꺼번에 확인합니다.
앱을 먼저 만들면 이 질문에 답하지 않은 채 화면과 기능만 늘어납니다. 직접 팔면 오늘 답을 듣습니다. 필요 없다고 하거나, 지금 쓰는 방법으로 충분하다고 하거나, 좋지만 돈을 낼 정도는 아니라고 말합니다.
듣기 좋은 답은 아닙니다. 그래도 제품을 몇 달 만든 뒤에 듣는 것보다는 낫습니다.
고객 한 명을 구하지 못하고, 결과 하나를 만들어주지 못하고, 그 대가로 1만 원도 받지 못했다면 결제 화면부터 만들 이유가 없습니다. 결제 기능은 이미 돈을 내려는 사람에게 받을 수단만 줍니다.
폴 그레이엄은 스타트업에 관한 글 〈Do Things That Don't Scale〉에서 초기 고객을 직접 구하고, 나중에 자동화할 일도 처음에는 손으로 처리해보라고 썼습니다. 일부 스타트업은 초기에 거의 모든 일을 수작업으로 해도 된다고 말합니다.
Y Combinator도 초기 스타트업을 위한 조언에서 첫 고객을 얻기 위해서라면 고객 열 명을 넘기기 어려운 수작업도 해보라고 권합니다. 고객이 생기기 전에 확장을 위한 기술부터 만들면 시간만 쓸 수 있다는 얘기입니다.
실제로 용역을 하다가 제품을 만든 회사도 있습니다.
Basecamp는 원래 웹 디자인 회사였습니다. 고객 프로젝트가 늘자 일정과 대화를 관리하기 어려웠고, 자기들이 실제로 쓰려고 Basecamp를 만들었습니다. 나중에는 디자인 일을 그만두고 제품에 집중했습니다.
Basecamp는 공식 창업 이야기에서 웹 디자인 회사로 일하며 프로젝트가 늘었고, 그 일을 감당하려고 제품을 만들었다고 설명합니다. 화면: Basecamp, Where we came from, © 37signals LLC.
Mailchimp도 웹 디자인 에이전시의 사이드 프로젝트로 시작했습니다. 창업자들은 고객 일을 하면서 작은 사업자가 쓸 이메일 마케팅 도구를 만들었고, 그 제품이 커지자 에이전시 일을 접었습니다.
Mailchimp 창업자 Ben Chestnut은 공식 글에서 Mailchimp를 웹 디자인 사업의 사이드 프로젝트로 시작했다고 적었습니다. 화면: Mailchimp 창업자 글, © Intuit Mailchimp.
두 회사는 회의실에서 고객의 업무를 상상하지 않았습니다. 돈을 받고 고객 일을 하면서 불편을 겪었고, 반복해서 만난 문제를 제품으로 만들었습니다.
여기서 하나는 나눠서 봐야 합니다.
사람이 직접 처리하니 시간이 너무 많이 들어서 돈이 남지 않는 사업이 있습니다. 고객은 10만 원을 냈는데 네 시간이 걸리고, 그중 세 시간을 반복 업무에 썼다면 IT가 할 일이 분명합니다. 세 시간을 십 분으로 줄이면 같은 사람이 더 많은 고객을 받을 수 있습니다.
이건 좋은 신호입니다. 고객은 이미 돈을 냈고, 기술로 줄일 일도 찾았습니다. 용역으로 매출을 만들고, 사람이 모자라기 시작할 때 IT로 상방을 열 수 있습니다.
반대로 사람이 직접 좋은 결과를 줬는데도 아무도 돈을 내지 않는다면 얘기가 다릅니다. 처리 속도를 줄이거나 화면을 예쁘게 만들어도 지불할 이유가 생기진 않습니다. 고객이나 문제, 가격부터 다시 봐야 합니다.
정리하면 이렇습니다.
게임이나 검색엔진, 개발 도구처럼 기술 자체가 상품인 사업도 있습니다. 모든 IT 창업을 용역으로 시험할 수 있다는 뜻은 아닙니다. 다만 사람의 상담·분석·중개·관리 업무를 대신하겠다는 앱이라면, 그 일을 직접 해보지 않을 이유를 찾기 어렵습니다.
앱을 만들기 전에 고객 한 명을 정합니다. 그 사람에게 어떤 결과를 줄지 한 문장으로 말하고, 가격을 붙여봅니다. 직접 서비스를 제공하면서 고객이 묻는 말과 내가 반복한 일을 적어둡니다.
고객이 계속 찾아오는데 내 시간이 모자라기 시작하면 그때 바이브코딩을 켜면 됩니다. 가장 자주 반복한 일부터 AI에게 맡깁니다. 이미 내가 해본 일이라 요구사항을 설명할 수 있고, 결과가 맞는지도 확인할 수 있습니다.
바이브코딩은 이 순서에서 아주 좋은 도구입니다. 예전에는 용역으로 확인한 업무를 제품으로 만들려면 개발자를 구하거나 큰돈을 써야 했습니다. 지금은 직접 작은 제품을 만들 수 있습니다. 용역의 매출 한계를 IT로 넘기 쉬워졌습니다.
다만 용역을 건너뛰게 해주는 도구는 아닙니다.
사주 앱을 만들기 전에 사주 상담 한 번, 이력서 분석 AI를 만들기 전에 유료 첨삭 한 번, 중개 플랫폼을 만들기 전에 실제 연결 한 번. 직접 팔아보면 무엇을 만들어야 할지 알게 됩니다. 아무도 사지 않으면 제품을 만들기 전에 멈출 수 있고요.
바이브코딩으로 앱부터 만들기 전에, 내가 직접 이 일을 해서 돈을 받을 수 있는지부터 확인해보면 어떨까요.
첫 댓글을 남겨보세요.
사용할 사람을 구했는지, 그 사람이 무엇 때문에 돈을 내는지, 내가 그 문제를 실제로 해결할 수 있는지는 그대로 남아 있습니다. AI가 코드는 써주지만 이 세 가지까지 확인해주진 않습니다.
그래서 요즘 앱을 만들겠다는 사람에게는 이 말을 먼저 하고 싶습니다.
제발 IT 창업부터 하지 마세요. 먼저 서비스를 해보세요.
사주 앱을 만들고 싶다고 해보겠습니다. 생년월일을 넣으면 AI가 사주를 분석하고, 매달 구독료를 받는 서비스입니다. 바이브코딩으로 충분히 만들 수 있습니다.
그 전에 사주 상담으로 돈을 받아본 적이 있나요?
사람들은 어떤 고민을 들고 오는지, 첫 상담에서 무엇을 묻는지, 어떤 답을 듣고 만족하는지, 한 번 보고 끝나는지 다시 찾아오는지 알아야 합니다. 상담 한 번에 얼마를 받았을 때 실제로 결제하는지도 봐야 하고요.
이 일을 한 번도 해보지 않았다면 AI가 내놓은 사주 분석이 좋은지부터 판단하기 어렵습니다. 고객이 결과를 마음에 들어 하지 않을 때 사주가 틀린 건지, 설명이 부족한 건지, 애초에 고객이 원한 답과 다른 건지도 알 수 없습니다.
이력서 분석 AI도 같습니다. 이력서를 직접 받아서 고쳐주고, 왜 그렇게 고쳤는지 설명하고, 그 대가로 돈을 받아봐야 합니다. 어느 경력은 앞으로 빼야 하는지, 지원하는 직무마다 무엇을 바꿔야 하는지, 고객은 첨삭과 상담 중 어디에 더 돈을 내는지 직접 봐야 합니다.
직접 좋은 이력서를 골라내지 못하는데 AI가 쓴 분석은 어떻게 검토할까요. 고객 한 명에게 결과를 설명하지 못하는데 앱 안에서는 무슨 문장을 보여줘야 할까요.
소개팅 앱을 만들고 싶다면 몇 쌍이라도 직접 연결해보면 됩니다. 마케팅 자동화 서비스를 만들고 싶다면 작은 가게 한 곳의 마케팅을 맡아볼 수 있고요. 예약 관리 서비스를 만들고 싶다면 예약을 직접 받아 정리해보면 됩니다.
왜 직접 해본 적도 없는 일을 IT로 만들면 잘할 수 있다고 생각할까요.
지인에게 아이디어를 말하면 대개 좋다고 해줍니다. 무료 앱을 열어보겠다는 사람도 쉽게 구할 수 있습니다. 그 반응만으로는 사업인지 알기 어렵습니다.
직접 서비스를 팔면 네 가지를 한꺼번에 확인합니다.
앱을 먼저 만들면 이 질문에 답하지 않은 채 화면과 기능만 늘어납니다. 직접 팔면 오늘 답을 듣습니다. 필요 없다고 하거나, 지금 쓰는 방법으로 충분하다고 하거나, 좋지만 돈을 낼 정도는 아니라고 말합니다.
듣기 좋은 답은 아닙니다. 그래도 제품을 몇 달 만든 뒤에 듣는 것보다는 낫습니다.
고객 한 명을 구하지 못하고, 결과 하나를 만들어주지 못하고, 그 대가로 1만 원도 받지 못했다면 결제 화면부터 만들 이유가 없습니다. 결제 기능은 이미 돈을 내려는 사람에게 받을 수단만 줍니다.
폴 그레이엄은 스타트업에 관한 글 〈Do Things That Don't Scale〉에서 초기 고객을 직접 구하고, 나중에 자동화할 일도 처음에는 손으로 처리해보라고 썼습니다. 일부 스타트업은 초기에 거의 모든 일을 수작업으로 해도 된다고 말합니다.
Y Combinator도 초기 스타트업을 위한 조언에서 첫 고객을 얻기 위해서라면 고객 열 명을 넘기기 어려운 수작업도 해보라고 권합니다. 고객이 생기기 전에 확장을 위한 기술부터 만들면 시간만 쓸 수 있다는 얘기입니다.
실제로 용역을 하다가 제품을 만든 회사도 있습니다.
Basecamp는 원래 웹 디자인 회사였습니다. 고객 프로젝트가 늘자 일정과 대화를 관리하기 어려웠고, 자기들이 실제로 쓰려고 Basecamp를 만들었습니다. 나중에는 디자인 일을 그만두고 제품에 집중했습니다.
Basecamp는 공식 창업 이야기에서 웹 디자인 회사로 일하며 프로젝트가 늘었고, 그 일을 감당하려고 제품을 만들었다고 설명합니다. 화면: Basecamp, Where we came from, © 37signals LLC.
Mailchimp도 웹 디자인 에이전시의 사이드 프로젝트로 시작했습니다. 창업자들은 고객 일을 하면서 작은 사업자가 쓸 이메일 마케팅 도구를 만들었고, 그 제품이 커지자 에이전시 일을 접었습니다.
Mailchimp 창업자 Ben Chestnut은 공식 글에서 Mailchimp를 웹 디자인 사업의 사이드 프로젝트로 시작했다고 적었습니다. 화면: Mailchimp 창업자 글, © Intuit Mailchimp.
두 회사는 회의실에서 고객의 업무를 상상하지 않았습니다. 돈을 받고 고객 일을 하면서 불편을 겪었고, 반복해서 만난 문제를 제품으로 만들었습니다.
여기서 하나는 나눠서 봐야 합니다.
사람이 직접 처리하니 시간이 너무 많이 들어서 돈이 남지 않는 사업이 있습니다. 고객은 10만 원을 냈는데 네 시간이 걸리고, 그중 세 시간을 반복 업무에 썼다면 IT가 할 일이 분명합니다. 세 시간을 십 분으로 줄이면 같은 사람이 더 많은 고객을 받을 수 있습니다.
이건 좋은 신호입니다. 고객은 이미 돈을 냈고, 기술로 줄일 일도 찾았습니다. 용역으로 매출을 만들고, 사람이 모자라기 시작할 때 IT로 상방을 열 수 있습니다.
반대로 사람이 직접 좋은 결과를 줬는데도 아무도 돈을 내지 않는다면 얘기가 다릅니다. 처리 속도를 줄이거나 화면을 예쁘게 만들어도 지불할 이유가 생기진 않습니다. 고객이나 문제, 가격부터 다시 봐야 합니다.
정리하면 이렇습니다.
게임이나 검색엔진, 개발 도구처럼 기술 자체가 상품인 사업도 있습니다. 모든 IT 창업을 용역으로 시험할 수 있다는 뜻은 아닙니다. 다만 사람의 상담·분석·중개·관리 업무를 대신하겠다는 앱이라면, 그 일을 직접 해보지 않을 이유를 찾기 어렵습니다.
앱을 만들기 전에 고객 한 명을 정합니다. 그 사람에게 어떤 결과를 줄지 한 문장으로 말하고, 가격을 붙여봅니다. 직접 서비스를 제공하면서 고객이 묻는 말과 내가 반복한 일을 적어둡니다.
고객이 계속 찾아오는데 내 시간이 모자라기 시작하면 그때 바이브코딩을 켜면 됩니다. 가장 자주 반복한 일부터 AI에게 맡깁니다. 이미 내가 해본 일이라 요구사항을 설명할 수 있고, 결과가 맞는지도 확인할 수 있습니다.
바이브코딩은 이 순서에서 아주 좋은 도구입니다. 예전에는 용역으로 확인한 업무를 제품으로 만들려면 개발자를 구하거나 큰돈을 써야 했습니다. 지금은 직접 작은 제품을 만들 수 있습니다. 용역의 매출 한계를 IT로 넘기 쉬워졌습니다.
다만 용역을 건너뛰게 해주는 도구는 아닙니다.
사주 앱을 만들기 전에 사주 상담 한 번, 이력서 분석 AI를 만들기 전에 유료 첨삭 한 번, 중개 플랫폼을 만들기 전에 실제 연결 한 번. 직접 팔아보면 무엇을 만들어야 할지 알게 됩니다. 아무도 사지 않으면 제품을 만들기 전에 멈출 수 있고요.
바이브코딩으로 앱부터 만들기 전에, 내가 직접 이 일을 해서 돈을 받을 수 있는지부터 확인해보면 어떨까요.
첫 댓글을 남겨보세요.