작년쯤부터 주변에서 창업 얘기가 부쩍 늘었다. 같이 부트캠프 나온 동기 한 명은 퇴사하고 뭔가를 만들고 있고, 전 직장 동료는 주말마다 사이드 프로젝트를 돌리다가 법인을 냈다고 한다. 개발자 커뮤니티에서도 "아이디어가 있는데 같이 할 사람 구합니다" 같은 글이 눈에 자주 띈다.

나도 창업에 관심이 있다. 솔직히 말하면 꽤 오래 전부터. 근데 관심이 있다는 것과 실제로 뛰어드는 것 사이에는 엄청난 간극이 있다. 그 간극 사이에서 이것저것 읽고, 주변 사람들 지켜보고, 내 나름대로 정리한 것들을 써본다.

개발자라서 빠지기 쉬운 함정#

개발자가 창업을 생각할 때 가장 먼저 하는 게 뭘까. 코드를 짠다. 아이디어가 떠오르면 바로 터미널을 열고 프로젝트를 세팅한다. npx create-next-app, DB 스키마 설계, API 라우팅. 이게 우리한테는 가장 자연스러운 행동이다. 문제를 보면 코드로 해결하는 게 몸에 배어 있으니까.

근데 여기서부터 꼬인다.

Paul Graham이 Y Combinator를 운영하면서 수천 개의 스타트업을 봤는데, 그가 반복적으로 강조하는 게 있다. "Make something people want." 사람들이 원하는 걸 만들라는 거다. 당연한 말 같지만, 여기서 핵심은 순서다. "사람들이 원하는 것"을 먼저 확인하고, 그다음에 만들어야 한다. 대부분의 개발자 창업자는 이 순서가 뒤집혀 있다. 먼저 만들고, 그다음에 원하는 사람을 찾으려 한다.

내 주변에서도 이 패턴을 봤다. 한 선배가 "개발자 전용 타임 트래킹 앱"을 만들겠다고 했다. 3개월 동안 혼자서 프론트, 백엔드, 인프라를 다 구축했다. GitHub 연동, 커밋 기반 자동 시간 측정, 대시보드까지. 기술적으로는 훌륭했다. 근데 베타를 열었을 때 가입자가 23명이었고, 일주일 뒤에 활성 사용자는 3명이었다. 그 선배가 한 말이 기억난다. "만드는 건 재밌었는데, 왜 아무도 안 쓰는지 모르겠어."

왜 안 쓰는지는 간단하다. 아무한테도 물어보지 않았으니까. 개발자들이 시간 추적에 불편을 느끼는지, 기존 도구의 어떤 점이 부족한지, 돈을 낼 만큼 절실한 문제인지를 확인하지 않았다.

사이드 프로젝트와 사업은 다르다#

이걸 구분하는 게 생각보다 중요하다. 사이드 프로젝트는 내가 만들고 싶은 걸 만드는 거다. 기술을 배우고 싶어서, 포트폴리오에 넣고 싶어서, 그냥 재밌어서. 동기가 나한테 있다.

사업은 다르다. 다른 사람이 돈을 내고 쓸 만큼의 가치를 만들어야 한다. 동기가 나한테 있는 게 아니라 시장에 있어야 한다. 이 차이가 사소해 보이는데, 모든 의사결정을 바꿔놓는다.

사이드 프로젝트를 할 때는 기술 스택이 중요하다. "이번에 Rust 배워볼까?" "Next.js 15 써볼까?" 이런 고민이 의미가 있다. 사업에서는 그런 고민이 의미 없다. 사용자한테 중요한 건 내 코드가 Rust로 짜여졌는지가 아니라, 자기 문제가 해결되는지다.

물론 사이드 프로젝트에서 출발한 사업이 많다. 근데 그 전환 지점이 어디인지를 인식해야 한다. "이거 사람들이 진짜 쓰네?"라는 신호가 오는 순간, 마인드셋을 바꿔야 한다. 더 이상 내 기술 호기심을 충족시키는 게 우선이 아니라, 사용자가 뭘 원하는지를 파악하는 게 우선이 된다.

Sam Altman이 한 말 중에 이런 게 있다. "Fast iteration can make up for a lot; it's usually ok to be wrong if you iterate quickly." 빠르게 반복하면 많은 걸 만회할 수 있다는 거다. 근데 이 반복의 기준이 "내가 원하는 기능을 추가하는 것"이 되면 안 된다. "사용자한테 보여주고, 피드백 받고, 고치는 것"이 되어야 한다.

퇴사 타이밍이라는 난제#

창업 관련 글을 읽으면 퇴사 타이밍에 대한 조언이 많다. "충분히 준비가 되면 뛰어들어라", "기회비용을 계산해봐라", "나이가 젊을수록 유리하다." 다 맞는 말인데, 구체성이 없다. 충분한 준비라는 게 대체 뭔데.

내가 관찰한 바로는, 잘 된 케이스에서 공통적으로 보이는 패턴이 있다. 퇴사 전에 이미 "신호"가 있었다. 사이드 프로젝트로 만든 걸 누군가 쓰고 있었다거나, 특정 문제에 대해 업계 사람들이 반복적으로 불만을 토로하는 걸 직접 목격했다거나, 함께할 공동창업자가 이미 있었다거나. 아무 신호도 없이 "이번 달에 퇴사하고 뭔가 해야지"로 시작한 경우는 대부분 몇 달 안에 다시 취업 준비를 하게 됐다.

Derek Sivers가 "Don't start a business until people are asking you to"라고 했는데, 이게 극단적으로 들릴 수 있지만 핵심은 맞다. 시장에서 어떤 형태로든 수요의 신호가 있어야 한다. 그 신호 없이 만드는 건 도박에 가깝다.

한 가지 현실적인 접근법은, 재직 중에 할 수 있는 데까지 해보는 거다. 퇴근 후와 주말에 프로토타입을 만들고, 잠재 사용자한테 보여주고, 반응을 확인한다. 이 단계에서 "돈 낼 의향이 있냐"까지 물어본다. 여기서 긍정적인 반응이 나오면, 그때 퇴사를 구체적으로 고민한다.

회사를 다니면서 이걸 하는 게 쉽지 않다는 건 안다. 퇴근하면 지쳐서 넷플릭스 틀고 싶은 날이 더 많다. 근데 이 과정을 견딜 수 없으면, 퇴사하고 풀타임으로 해도 비슷한 상황이 온다. 창업은 지칠 때 멈출 수 있는 게 아니니까. 어떤 의미에서는, 재직 중에 사이드로 얼마나 하느냐가 본인의 의지를 테스트하는 과정이기도 하다.

YC가 실제로 보는 것#

YC(Y Combinator) 합격/불합격 이야기는 온라인에 많다. 근데 대부분 합격 후기 위주라서 편향이 있다. 내가 여러 글이랑 영상을 보면서 정리한 바로는, YC가 보는 건 크게 세 가지다.

첫째, 창업자. 이게 압도적으로 중요하다. Paul Graham이 "Relentlessly Resourceful"이라는 글에서 좋은 창업자의 특성을 한마디로 요약했다. 끈질기게 자원을 찾아내는 사람. 문제가 생기면 멈추지 않고 어떻게든 돌파하는 사람. 기술적 능력도 중요하지만, 그보다 "이 사람이 벽에 부딪혔을 때 어떻게 할까"가 더 큰 판단 기준이다.

둘째, 시장. "이 문제를 겪는 사람이 얼마나 많은가?"와 "이 문제가 얼마나 절실한가?"를 본다. 대단한 기술을 가지고 있어도, 그걸 원하는 사람이 없으면 의미가 없다.

셋째, 진행 상황. 아이디어만 가지고 오는 팀보다, 뭔가를 이미 만들었고 사용자가 있는 팀이 유리하다. 완성도보다 속도를 본다. "6개월 동안 이걸 만들었습니다"보다 "3주 만에 이걸 만들고 사용자 50명을 모았습니다"가 더 좋은 신호다.

이건 YC에 지원하지 않더라도 유효한 프레임워크다. 자기 자신에게 물어보면 된다. "나는 끈질긴가?", "이 문제를 겪는 사람이 충분한가?", "나는 빠르게 움직이고 있는가?"

기술로 해결할 수 있는 문제와 없는 문제#

개발자가 창업에서 가지는 가장 큰 장점은 명확하다. 직접 만들 수 있다는 거다. 비개발자 창업자는 MVP 하나 만드는 데 외주를 쓰거나 기술 공동창업자를 찾아야 한다. 우리는 바로 만들 수 있다. 이건 진짜 큰 장점이다.

근데 이 장점이 함정이 되기도 한다. 모든 문제를 기술로 풀려고 하니까. "마케팅이 안 돼? SEO를 최적화하자." "사용자가 안 늘어? 새 기능을 추가하자." "이탈률이 높아? UI를 리디자인하자." 기술적 해결책에만 손이 간다.

근데 초기 스타트업에서 가장 중요한 문제들은 기술로 풀 수 없는 경우가 많다. "이 사람이 진짜 돈을 낼까?"는 대화를 해봐야 안다. "우리 제품이 어떤 가치를 제공하는가?"는 포지셔닝 문제다. "왜 사람들이 기존 솔루션에서 넘어와야 하는가?"는 시장 이해의 문제다.

Paul Graham이 "Do Things That Don't Scale"에서 강조한 게 이거다. Airbnb 창업자들이 초기에 뉴욕의 호스트를 한 명 한 명 방문했다. Stripe 창업자들이 잠재 고객한테 직접 가서 결제 시스템을 대신 세팅해줬다. 이건 코드 한 줄로 해결되는 게 아니다. 사람을 만나고, 대화하고, 불편한 일을 손으로 하는 거다.

내가 아는 한 CTO가 창업 초기에 고객 지원을 직접 했다고 한다. Zendesk 설정하는 것보다 카카오톡으로 일일이 답장하는 게 더 빠르기도 했고, 사용자가 뭘 불편해하는지를 직접 체감할 수 있었다고. 처음에는 "이런 건 내 일이 아닌데"라고 느꼈지만, 나중에 돌이켜보니 그때 고객 대화에서 얻은 인사이트가 이후 제품 방향을 결정했다고 한다.

공동창업자에 대해#

혼자 창업할까, 같이 할까. 이것도 많이 고민되는 부분이다.

통계적으로 보면 공동창업이 유리하다고 한다. YC에서도 공동창업 팀을 선호한다고 알려져 있다. 이유는 여러 가지인데, 서로 보완이 되고, 힘들 때 의지할 수 있고, 판단을 견제할 수 있고.

근데 내가 주변에서 본 현실은, 공동창업자 관계가 깨지는 게 스타트업 실패의 가장 흔한 원인 중 하나라는 거다. 원래 친한 친구였는데 지분 문제로 사이가 틀어진 경우, 비전이 달라지면서 방향 갈등이 생긴 경우, 한 명은 풀타임이고 한 명은 사이드로 하면서 기여도 갈등이 생긴 경우.

그래서 결론이 "그래도 공동창업이 좋다"는 아니고, "잘 맞는 공동창업자를 찾는 게 쉽지 않다"는 거다. 오히려 혼자 빠르게 검증하고, 확신이 생겼을 때 팀을 꾸리는 것도 방법이다. 특히 개발자는 혼자서 MVP를 만들 수 있으니까, 초기 검증 단계에서는 혼자 해도 불리하지 않다.

다만 혼자 하면 빠지기 쉬운 게, 사업 전체를 기술의 관점으로만 보게 된다는 거다. 개발 말고도 해야 할 일이 산더미인데, 코딩하는 시간이 가장 편하니까 계속 코드만 짜게 된다. 이건 의식적으로 경계해야 한다.

창업이 맞는 사람, 아닌 사람#

불편한 진실을 쓰자면, 창업은 모든 사람에게 맞는 선택이 아니다. "도전하면 뭐든 할 수 있다"는 말은 동기부여에는 좋지만 현실적이지 않다.

내가 관찰한 바로는, 창업에 적합한 사람에게는 몇 가지 공통점이 있다. 불확실성을 견디는 능력. 매달 같은 날에 월급이 들어오지 않는 상황이 스트레스인 사람도 있고, 그게 오히려 동기부여가 되는 사람도 있다. 거절을 일상적으로 받아들이는 자세. 영업, 투자 유치, 채용, 거의 모든 과정에서 거절당한다. 이게 축적되면 꽤 힘들다.

그리고 무엇보다, 특정 문제에 대한 집착. "이건 이렇게 되어야 하는데 왜 아무도 안 만들지?"라는 생각이 몇 달째 안 떠나는 상태. 이런 집착이 없으면 어려운 시기에 포기하기 쉽다.

반대로, "좀 더 자유롭게 일하고 싶어서", "연봉 천장을 깨고 싶어서", "남의 밑에서 일하기 싫어서"라는 이유만으로 창업을 생각하고 있다면, 프리랜서나 1인 개발 같은 선택지가 더 맞을 수도 있다. 창업은 자유로운 게 아니라 다른 종류의 구속이다. 상사 대신 고객, 투자자, 팀원한테 책임이 생긴다.

그래서 지금 뭘 하면 좋을까#

당장 퇴사할 생각이 없더라도 할 수 있는 게 있다.

하나, 문제를 모으기 시작한다. 일상에서, 업무에서, 주변 사람들한테서 반복적으로 불편해하는 것들을 메모한다. 아이디어를 모으는 게 아니라 문제를 모으는 거다. 해결책은 나중에 생각해도 된다.

둘, 사용자랑 대화하는 연습을 한다. 우리한테 가장 어색한 일이다. 근데 창업의 절반 이상이 사람과의 대화다. 지금 다니는 회사의 고객 지원 내용을 읽어보는 것만으로도 시작이 된다. 사용자가 뭘 불편해하는지, 어떤 말로 표현하는지를 관찰하는 거다.

셋, 작게 만들어서 공개한다. 완벽하지 않아도 된다. 주말에 만든 작은 도구를 트위터에 올리고, 사람들 반응을 본다. 이게 습관이 되면 "만들고 공개하고 피드백 받는" 사이클이 자연스러워진다. 이 사이클이 창업의 기본 단위다.

넷, 돈 관련 준비를 한다. 비상금이 얼마 있는지, 최소한의 생활비가 얼마인지, 몇 개월을 버틸 수 있는지를 숫자로 파악한다. 막연하게 "좀 모아야지"가 아니라 구체적인 숫자가 필요하다. 이 숫자가 퇴사 타이밍의 현실적인 기준이 된다.

나도 아직 창업을 하지 않았다. 관심만 가지고 몇 년째다. 근데 그 기간 동안 읽고 관찰하면서 알게 된 게 있다면, 창업은 어느 날 갑자기 결심하고 뛰어드는 게 아니라 서서히 준비되는 거라는 것. 지금 하고 있는 사이드 프로젝트가, 매일 마주치는 문제들이, 나누는 대화들이 언젠가 연결될 수도 있다.

그 연결이 올 때 움직일 수 있도록, 지금은 안테나를 세워두는 시기라고 생각한다.