Chapter 1. 개발은 의외로 제일 마지막에 해야 할 일이다

개발자는 보통 스타트업에 ‘마지막으로’ 합류하는 사람이다.
하지만 실제로는 ‘가장 먼저’ 찾는 사람이기도 하다.

“이 아이디어, 괜찮지 않나요?”
“저희도 이제 개발 들어가야 할 것 같아서요.”
“개발자 한 분만 붙으면 금방 나올 것 같은데…”

나는 외주 개발, 협업 개발, 공동 프로젝트 개발까지 다양하게 겪어왔다.
그 과정에서 내가 반복적으로 마주친 건 이거다.
창업자들은 개발이 시작점이라고 믿는다.
그렇기 때문에 준비가 안 된 채로 시작하고, 결국 개발 단계를 지나면서 대부분 망가진다.

그리고 나는 점점 확신하게 됐다.
개발은 제일 마지막에 해야 한다. 그게 제일 싸고, 빠르고, 안정적인 방법이다.

 

창업자 입장에서 보면 당연히 빨리 뭔가를 만들고 싶다.
생각해둔 아이디어가 있고, 대략적인 화면 구성도 있다.
어디선가 비슷한 서비스를 봤고, 그것보다 조금 더 나은 기능이면 이길 수 있을 것 같다는 믿음도 있다.

그런데 개발자 입장에서 보면, 그건 아직 ‘실행’의 단계가 아니다.
그건 ‘가설’이다.
내가 본 대부분의 초창기 창업 아이템은 검증되지 않은 가정으로 가득 차 있다.

“이 기능만 있으면 사람들이 쓸 것 같아요.”
“이게 불편하다는 사람이 많던데요.”
“지금 당장은 없지만, 나중에 이 시장이 열릴 거예요.”

이런 말들을 수없이 들었고, 그럴 때마다 나는 묻는다.

“그 ‘사람들’이 실제로 누구고, 어떻게 불편하다고 했나요?”
“그 시장이 열린다는 건 어떤 근거로 말씀하시는 건가요?”
“지금 이 기능을 먼저 써보겠다고 연락한 사람, 몇 명이나 있나요?”

보통 대답은 없다.
이건 비난이 아니다. 당연하다.
아이디어는 늘 먼저 떠오르고, 실체는 그 뒤에 따라온다.
문제는 많은 창업자들이 실체가 오기도 전에 개발을 시작한다는 데에 있다.

 

한 번은 이런 일이 있었다.
A 대표는 창업 컨설팅도 받아봤고, 시장 분석 리포트도 가지고 있었고, 화면 구성도 이미 피그마로 어느 정도 만들어놨다.
그리고 개발자만 붙으면 완성이라고 생각했다.
우리 팀은 “정말 잘 정리된 기획”이라고 느꼈고, 계약을 진행했다.

하지만 개발이 시작되고 나서 2주 차부터 일이 꼬이기 시작했다.
디자인이 바뀌었다.
구현 범위가 애매하던 기능이 갑자기 “이건 당연히 들어가는 거 아닌가요?”라는 말과 함께 다시 올라왔다.
3주 차에는 “결제 쪽은 일단 보류하고요, 마이페이지 먼저 구현해볼게요”라고 말했다.
그때 우리는 알았다.
아직 이 프로젝트는 개발을 시작할 준비가 안 돼 있었다.

 

왜 이런 일이 벌어질까?
그건 스타트업이 개발의 위치를 잘못 생각하기 때문이다.

개발에 대한 창업자의 오해실제 개발자의 관점기획이 끝났으면 개발이 시작이다기획이 검증되었을 때만 개발이 시작이다앱이 있어야 홍보할 수 있다기능보다 고객 반응과 진입 구조가 먼저다개발자는 바로 움직일 수 있다개발자는 명확한 설계와 결정이 있어야 움직인다피그마면 충분하지 않나?피그마는 보여주는 것, 명세서는 설명하는 것

 

개발은 기획서를 받아서 뚝딱 만드는 작업이 아니다.
기획 → 검증 → 설계 → 구조화 → 이후에야 개발이 들어간다.

그 순서를 무시하면 어떻게 되느냐?
바로 이런 흐름이 된다.

빠른 개발 시작의 흔한 전개결과‘대충’ 기획한 기능으로 개발 시작실제 요구사항과 괴리 발생중간에 방향이 바뀜재개발, 일정 지연, 예산 초과사용자 테스트 미진만든 후 아무도 안 씀유지보수 범위 불명확마찰, 분쟁, 신뢰 붕괴

그리고 스타트업은 종종 이렇게 말한다.
“개발사(혹은 개발자)가 너무 별로였어요.”

그런 말을 들을 때 개발자들은 입을 닫는다.
왜냐하면 그 원인을 설명하는 것조차 ‘변명’처럼 들리기 때문이다.
그 대신 나는 글로 정리해서 말한다.
“문제는 개발자가 아니라, 개발이 너무 빨리 시작됐기 때문입니다.”

 

나는 이런 비유를 자주 든다.
기획이 시장 테스트를 거치지 않은 상태에서 개발을 시작하는 건,
설계도 없이 건물을 올리는 것과 같다.
당연히 중간에 삐걱대고, 잘못 올라가고, 다 부수고 다시 해야 한다.

그런데 스타트업은 시간이 없다.
예산도 없다.
투자자한테 보여줘야 하고, 다음 달엔 베타 테스트를 해야 하고, 벌써 마케팅 채널은 예약되어 있다.
그러니까 무리하게 개발부터 시작한다.

이건 마치 숨 안 쉬고 마라톤을 시작하는 거랑 비슷하다.
망할 걸 알면서도 달리는 것.

 

그래서 나는 조언한다.
개발을 맨 마지막에 하라고.
그게 ‘개발자를 늦게 찾으라’는 뜻이 아니다.
개발자가 제대로 일할 수 있을 만큼 정리된 뒤에 움직이라는 뜻이다.

그걸 판단할 기준은 간단하다.

개발 시작 체크리스트점검핵심 기능이 3개 이하로 요약되어 있는가✅/❌

화면 흐름이 피그마 외에도 텍스트로 설명되어 있는가✅/❌

사용자 대상 테스트 경험이 있는가✅/❌

개발자 없이 이 서비스를 1주일이라도 흉내내 본 적 있는가✅/❌

MVP가 무엇이고, 무엇이 MVP가 아닌지 구분이 되는가✅/❌

이 중에서 4개 이상이 체크되면 개발을 시작해도 된다.
그게 아니라면 지금 필요한 건 개발자가 아니라, 문제를 명확히 정의할 사람, 혹은 진짜 고객이다.

 

개발은 정리를 위한 수단이지, 혼란 속에서 구원해줄 마법사가 아니다.
정리된 문제, 구조화된 기획, 반복 테스트된 피드백이 있을 때
개발자는 놀라울 정도로 빠르고 정확하게 움직일 수 있다.

개발은 가장 비싼 리소스다.
그만큼 가장 아껴야 한다.
그러니 제일 마지막에 써야 한다.