비로소 사업의 방향이 잡히는 것 같았습니다. 아이디어도 구체화됐고, 누구의 문제를 풀 건지도 어렴풋이 잡혀가던 참이었습니다.
그런데,
"이제 만들어야 하는데, 나는 개발을 모르잖아."
그 한 문장이 떠오른 순간 자신감이 갑자기 위축됐습니다. 바로 검색창에 매달리기 시작했고, 노코드부터 외주 개발, AI 코딩에 에이전트까지 닥치는 대로 파고들었는데 파고들수록 오히려 길을 잃는 것 같았습니다.
어떤 글은 쉽다고 했고, 바로 다음 글은 절대 혼자 하지 말라고 했습니다. 읽으면 읽을수록 확신은 줄어들고, 선택지만 흐릿하게 늘어갔습니다.
그래도 폭풍 검색 끝에 하나는 알게 됐습니다. 갈래가 아무리 많아 보여도 결국 크게 세 가지로 좁혀진다는 겁니다.
선택지 하나, 직접 만들어본다
새벽 두 시, 버블이라는 도구를 처음 열어봤더니 클릭 몇 번만으로 화면이 만들어지기 시작했습니다. 머릿속에만 있던 서비스가 눈앞에 나타나니까 뭔가 끓어오를 것만 같던 것들이 움트기 시작했습니다.
그 기세로 플러터플로우도 써봤고, AI 바이브코딩까지 더해봤습니다. 그러다 보니 시장 반응을 빠르게 확인할 MVP 정도라면 이것만으로도 되겠다는 확신까지 차올랐습니다.
그런데 여기서부터 이야기가 달라졌습니다.
결제를 붙이려는데 막혔습니다. 그건 괜찮았습니다, 넘어가면 되니까요. 그런데 사용자 권한을 나누려고 하니까 구조 자체가 안 받쳐줬고, 억지로 우회해봤더니 이번에는 앞에서 만들어 놓은 것들까지 줄줄이 깨지기 시작했습니다.
"어느 수준까지는 금방인데, 거기서 한 발짝만 더 나가려면 급격히 어려워진다."
실제로 해 본 분들이 공통으로 하는 말이었습니다. 빠르게 왔으니까 조금만 더 하면 될 것 같거든요. 그런데 그 "조금"에 매달리다 보면 시간과 비용이 오히려 배로 들어가기 시작하고, 결국 빠르게 시작했다는 그 장점이 어느새 발목을 잡고 있었습니다.
선택지 둘, 개발사에 맡겨본다
견적서를 받아봤습니다. 두세 곳에 연락하니까 금액이 나왔고 기간도 잡혔는데, 숫자가 딱 정해져 있다는 것만으로도 마음이 한결 가벼워졌습니다.
"기획서 보내주시면 검토 후 착수할게요."
그런데 그 기획서라는 게, 화면 구조부터 데이터 흐름까지 개발사가 바로 손댈 수 있을 만큼 구체적인 문서여야 했습니다. 어디서부터 써야 하는지 감이 없었고, 기준 없이 채워 넣다 보니 시간만 흘러갔습니다.
그래도 어떻게든 정리해서 넘겼습니다.
한 달 뒤 중간 결과물이 왔는데, 직접 눌러보니까 머릿속에 그렸던 것과 달랐습니다. 바꿔달라고 했더니 돌아온 답은 짧았습니다. 계약 범위 밖이라고요. 그 사이에 추가 비용이 붙고 일정이 밀리면서, 서로가 바라보는 방향이 조금씩 어긋나기 시작했습니다.
"우리가 원한 건 이게 아닌데."
그 말을 몇 번이나 반복하다 보니 결국 한 가지가 선명해졌습니다. 외주 개발은 뭘 만들어야 하는지 이미 확실할 때 힘을 발휘하는 구조였고, 아직 방향을 잡아가는 중이라면 그 깔끔한 계약 구조가 오히려 발을 묶을 수 있다는 것이었습니다.
선택지 셋, IT 파트너를 구해본다
이번에는 전화를 걸었습니다. 기획서를 보내는 게 아니라, 내가 풀고 싶은 문제를 먼저 말하는 것부터 시작했습니다.
"이런 서비스를 만들고 싶은데, 어떻게 접근하면 될까요."
돌아온 건 견적서가 아니었습니다. 질문이었습니다.
사용자가 누구인지, 핵심 흐름이 어떤 건지 파트너 쪽에서 먼저 물어왔습니다. 검증까지 고려한 거냐고 부가적인 질문도 이어졌습니다. 그렇게 주고받다 보니 흩어져 있던 내 사업 아이디어가 뭔가 체계를 갖기 시작한 것처럼, 하나씩 자리를 잡아가기 시작했습니다.
그동안 외주는 일을 맡기고 관리하는 느낌이었습니다. 반면 이번에 파트너와 일을 하는 건, 내 옆에 동료를 앉혀놓고 처음부터 끝까지 함께 가는 느낌이었습니다.
실제로 그랬습니다. 초기에는 전략을 같이 짜는 것부터 시작했고, 그게 정리가 되니까 자연스럽게 PRD를 함께 쓰게 됐습니다. 개발이 시작된 뒤에도 출시 후 초기 반응까지 나란히 들여다보는 구조여서, 결국 처음부터 끝까지 한 팀이 관통하는 흐름이 만들어졌습니다.
외주에서 가장 지쳤던 순간이 떠올랐습니다. 기획은 한 사람이, 설계는 다른 사람이, 개발은 또 다른 사람이 맡았고 단계가 넘어갈 때마다 맥락을 처음부터 다시 설명해야 했습니다. 같은 이야기를 반복하는데 일정은 계속 줄어들고 있었습니다.
파트너 구조에서는 그게 사라졌습니다. 같은 팀이 쭉 함께 왔으니까, "왜 이렇게 만들었는지"를 굳이 말하지 않아도 이미 알고 있거든요.
그리고 방향을 틀어야 할 때도 분위기가 달랐습니다. 외주에서는 추가 계약이 됐던 그 일이, 파트너 구조에서는 프로젝트의 자연스러운 일부였습니다. 처음부터 "바뀔 수 있다"는 전제 위에 함께 설계했으니까요. 그래서 방향을 바꿨을 때 그게 비용이 아니라 학습이 되는 구조였습니다.
물론 모든 상황에 맞지는 않습니다. 내부에 기획자와 디자이너가 이미 있고 순수하게 개발 손만 빌리면 되는 상황이라면, 오히려 외주가 더 깔끔합니다.
다만 기술 의사결정을 함께할 사람이 옆에 아무도 없는 상황이라면, 이야기가 완전히 달라집니다. 혼자 검색하고 혼자 판단하던 밤이 계속됐다면, 이 선택지가 가장 가까운 답이 될 수 있습니다.
결국 중요한 건 하나입니다
검색하는 내내 "어떤 방법이 최고인가"를 묻고 있었습니다.
그런데 돌아보니 질문 자체가 틀렸습니다.
"지금 내 상황에서 가장 낭비가 적은 방법이 뭔가." 진짜 물어야 할 건 이쪽이었습니다.
기획서가 있는가 — 이게 있느냐 없느냐에 따라 출발선 자체가 달라졌습니다. 기술 판단을 함께할 사람이 옆에 있는가 — 없으면 중간에 부딪히는 벽의 높이가 완전히 달라졌습니다. 그리고 출시 후 운영까지 이어갈 여력이 있는가 — 이 마지막 질문이 결국 세 갈래 중 어디로 갈지를 결정적으로 갈랐습니다.
이 세 가지를 솔직하게 꺼내놓으면, 선택지는 생각보다 빠르게 좁혀집니다.
검색창 앞에서 막막했던 그 밤으로 다시 돌아가 봅니다. 돌이켜보면 방법이 없었던 게 아니라, 내 상황을 비춰볼 거울이 없었을 뿐이었습니다.
이제 그 거울이 생겼습니다. 다음 한 발은, 그 밤보다 훨씬 가벼울 겁니다.
