외주 개발의 함정과 인하우스 전환 타이밍 - 언제까지 외주로 버틸 수 있을까?

 

"일단 외주로 만들고 봅시다"

비개발 창업자들이 가장 먼저 하는 말입니다. 그리고 저는 이렇게 답합니다.

 

"좋은 선택입니다. 하지만 언제까지 외주로 갈 건지 지금부터 생각하셔야 합니다."

 

외주 개발은 나쁜 선택이 아닙니다. 오히려 많은 경우 현명한 선택입니다. 문제는 언제까지 외주로 가야 하는지 모르는 채로 시작한다는 것입니다. 그리고 전환 타이밍을 놓쳐서 더 큰 비용을 치르게 됩니다.

 

저희 팀도 초기에는 일부 기능을 외주로 개발했습니다. 당시에는 그게 맞는 선택이었습니다. 하지만 6개월 만에 인하우스로 전환했고, 그 과정에서 외주로 만든 코드의 70%를 다시 작성해야 했습니다.

 

왜 그랬을까요? 전환 타이밍을 제대로 이해하지 못했기 때문입니다.

외주 개발이 합리적인 경우

먼저 외주 개발이 좋은 선택인 경우를 정리해봅시다.

제품-시장 적합성(PMF)을 찾기 전

아직 어떤 제품을 만들어야 할지 확신이 없는 단계라면, 외주가 답입니다. 빠르게 프로토타입을 만들고, 고객 반응을 보고, 피벗할 수 있어야 합니다. 이 단계에서 정규직 개발자를 뽑는 건 배보다 배꼽이 큽니다.

 

랜딩 페이지, 간단한 MVP, 프로토타입 수준이라면 외주로 충분합니다. 어차피 고객 반응을 보고 다시 만들 가능성이 높으니까요.

일회성 프로젝트

이벤트 페이지, 마케팅 캠페인 사이트, 일회성 도구처럼 만들고 나면 거의 손댈 일이 없는 프로젝트는 외주가 합리적입니다. 지속적인 유지보수가 필요 없다면 굳이 인력을 상시 보유할 이유가 없습니다.

전문 기술이 필요한 특정 기능

블록체인, AI 모델, 복잡한 알고리즘처럼 전문성이 높은 특정 기능은 외주 전문가를 쓰는 게 나을 수 있습니다. 풀타임으로 고용하기에는 비용 부담이 크고, 프로젝트 기간도 한정적이라면 더욱 그렇습니다.

자금이 극도로 제한적일 때

솔직히 말해서, 개발자 한 명 연봉이 부담스러운 초기 단계라면 외주 외에 선택지가 없습니다. 다만 이 경우에도 "언제까지 외주로 갈 것인가"에 대한 계획은 있어야 합니다.

외주 개발의 숨겨진 함정들

문제는 외주로 시작했다가 빠져나오지 못하는 경우입니다. 제가 봐온 실제 사례들을 공유합니다.

함정 1: "수정하는데 2주 걸린대요"

가장 흔한 함정입니다. 고객 피드백을 받아서 간단한 수정을 요청했는데, 외주 업체가 2주가 걸린다고 합니다. 급한 마음에 추가 비용을 주고 빨리 해달라고 하지만, 결과물은 또 기대에 못 미칩니다.

 

인하우스 개발자가 있었다면 하루면 될 일이, 외주로는 2주가 걸립니다. 이게 반복되면 제품 개선 속도가 느려지고, 시장 대응이 늦어집니다.

 

한 지인 스타트업은 이 문제로 경쟁사에 시장을 빼앗겼습니다. 고객들이 원하는 기능을 경쟁사는 2주 만에 출시했는데, 그들은 외주 업체 일정 때문에 2개월이 걸렸으니까요.

함정 2: "원래 개발자가 퇴사했대요"

외주 업체의 인력은 유동적입니다. 여러분의 프로젝트를 담당하던 개발자가 퇴사하면, 새로운 개발자가 코드를 파악하는 데 시간이 걸립니다. 그리고 그 시간과 비용은 고스란히 여러분의 몫입니다.

 

더 심각한 건, 외주 업체가 여러분의 프로젝트만 하는 게 아니라는 점입니다. 더 큰 프로젝트가 들어오면 여러분의 일은 우선순위에서 밀립니다.

함정 3: "코드를 받았는데 아무도 못 읽어요"

외주 프로젝트가 끝나고 코드를 인수받았습니다. 나중을 위해 새로운 개발자를 고용했는데, 그 개발자가 코드를 보더니 고개를 젓습니다. "이거 처음부터 다시 짜는 게 나을 것 같은데요."

 

외주 업체는 빠르게 납품하는 게 목표입니다. 유지보수나 확장성은 그들의 관심사가 아닙니다. 주석도 없고, 문서도 없고, 구조도 엉망인 코드를 받게 되는 경우가 많습니다.

 

결국 인하우스 개발자를 뽑고 나서 코드를 다시 작성하는 데 외주 개발비만큼의 비용이 또 듭니다.

함정 4: "소스코드 저작권이 저희 거래요?"

계약서를 제대로 확인하지 않았다가 나중에 발견하는 함정입니다. 소스코드 저작권이 외주 업체에 있거나, 추가 비용을 내야 소스를 받을 수 있는 경우도 있습니다.

 

더 황당한 경우는, 같은 코드베이스를 여러 고객에게 재활용해서 판매하는 업체도 있습니다. 여러분이 막대한 비용을 들여 만든 기능이 경쟁사에도 똑같이 판매될 수 있다는 뜻입니다.

인하우스로 전환해야 하는 신호들

그렇다면 언제 인하우스로 전환해야 할까요? 다음 신호들이 보이면 진지하게 고민해야 합니다.

신호 1: 주 1회 이상 수정 요청을 한다

제품에 대한 수정과 개선이 잦아진다는 건, PMF를 찾아가고 있다는 신호입니다. 이 단계에서는 빠른 실행이 생명인데, 외주로는 그 속도를 맞출 수 없습니다.

 

개발 요청이 쌓이기 시작하고, 외주 업체의 대응이 느리게 느껴진다면 전환 타이밍입니다.

신호 2: 외주 비용이 월 500만원을 넘어간다

매달 외주에 500만원 이상을 쓰고 있다면, 시니어 개발자 한 명을 고용하는 게 더 경제적입니다. 외주는 프로젝트 단위로 비용이 책정되지만, 인하우스는 지속적으로 가치를 만들어냅니다.

 

단순 비용 계산만이 아닙니다. 인하우스 개발자는 제품을 누구보다 잘 이해하게 되고, 시간이 지날수록 생산성이 높아집니다.

신호 3: 투자 유치에 성공했다

시드 투자를 받았다면, 그 돈의 일부는 반드시 인하우스 개발팀을 구축하는 데 써야 합니다. 투자자들도 이를 기대합니다.

외주로만 개발하는 스타트업은 다음 라운드 투자 유치가 어렵습니다. 투자자 입장에서는 "기술 역량이 내재화되지 않은 회사"로 보이기 때문입니다.

신호 4: 기술이 핵심 경쟁력이다

만약 여러분의 비즈니스에서 기술이 차별화 포인트라면, 외주로는 경쟁력을 만들 수 없습니다.

 

AI 기반 추천 알고리즘, 독자적인 데이터 처리 기술, 실시간 매칭 시스템처럼 기술 자체가 핵심이라면, 하루빨리 인하우스로 전환해야 합니다. 이런 기술은 외부에 맡겨서는 경쟁사 대비 우위를 만들 수 없습니다.

신호 5: 고객 데이터를 다룬다

개인정보, 금융 정보, 의료 정보처럼 민감한 데이터를 다룬다면, 보안상 인하우스가 필수입니다. 외주 업체를 통한 데이터 유출 리스크는 회사의 존폐를 좌우할 수 있습니다.

 

GDPR, 개인정보보호법 같은 규제 준수도 인하우스가 훨씬 관리하기 쉽습니다.

전환, 어떻게 시작할까?

인하우스로 전환하기로 결정했다면, 다음 순서를 권장합니다.

1단계: 기술 공동창업자 또는 첫 개발자 영입

CTO급이 아니어도 됩니다. 시니어 레벨의 풀스택 개발자 한 명이면 충분합니다. 이 사람이 외주 업체와 소통하고, 코드를 인수받고, 점진적으로 내재화하는 역할을 합니다.

 

이 첫 번째 개발자 선택이 정말 중요합니다. 이 사람이 향후 개발팀의 문화와 기준을 만들기 때문입니다.

2단계: 외주와 병행하며 지식 이전

갑자기 외주를 끊지 마세요. 인하우스 개발자가 온보딩하는 동안 외주 업체와 협력하며 점진적으로 전환합니다.

 

이 시기에 인하우스 개발자는 외주 업체가 만든 코드를 분석하고, 어떤 부분을 살리고 어떤 부분을 다시 작성할지 판단합니다. 보통 3~6개월 정도의 전환 기간이 필요합니다.

3단계: 핵심 기능부터 재작성

모든 코드를 한 번에 다시 쓰려고 하지 마세요. 가장 자주 변경되는 핵심 기능부터 인하우스 개발자가 재작성하고, 덜 중요한 부분은 외주 코드를 그대로 사용합니다.

 

시간이 지나면서 자연스럽게 외주 코드의 비중이 줄어들고, 결국 모든 코드가 인하우스로 전환됩니다.

4단계: 두 번째 개발자 채용

첫 번째 개발자가 안정적으로 자리잡으면, 그 사람과 함께 두 번째 개발자를 뽑습니다. 문화를 만들고 팀을 키우는 건 CTO만의 일이 아닙니다. 첫 번째 개발자와 함께 만들어가는 것입니다.

완전히 외주를 끊어야 할까?

아닙니다. 인하우스 팀이 생긴 후에도 외주는 여전히 유용합니다.

 

디자인, 일시적인 인력 증원, 전문 기술이 필요한 특정 기능 개발 등은 계속 외주를 활용할 수 있습니다. 다만 이때의 외주는 "우리

가 못해서 맡기는 것"이 아니라 "전략적으로 선택하는 것"이어야 합니다.

 

핵심 기능과 비핵심 기능을 구분하고, 비핵심은 외주로, 핵심은 인하우스로 하는 하이브리드 전략이 가장 효율적입니다.

가장 큰 오답노트: 전환을 미루는 것

7년간 수많은 스타트업을 보면서 가장 안타까운 경우는, 전환 타이밍을 알면서도 미루는 경우입니다.

 

"투자 받으면 개발자 뽑을게요."

"매출 나오면 인하우스로 전환할게요."
"지금은 바빠서 나중에 할게요."

 

이렇게 미루다가 결국 다음과 같은 상황에 빠집니다.

 

외주 비용이 눈덩이처럼 불어나고, 제품 개선 속도는 느려지고, 경쟁사에게 시장을 빼앗기고, 투자 유치도 어려워집니다. 결국 뒤늦게 인하우스로 전환하려고 하면, 쌓인 기술 부채 때문에 엄청난 비용을 치러야 합니다.

 

전환 타이밍을 놓치는 것이 외주 개발의 가장 큰 함정입니다.

대표님께 드리는 조언

외주냐 인하우스냐는 이분법적 질문이 아닙니다. 상황과 단계에 따라 달라집니다.

 

하지만 한 가지는 확실합니다. 여러분이 진짜로 성장하고 싶은 스타트업을 만들고 싶다면, 언젠가는 기술을 내재화해야 합니다. 그 "언젠가"가 언제인지 지금부터 생각해야 합니다.

 

외주로 시작하는 건 잘못이 아닙니다. 하지만 외주로만 가려는 건 위험합니다.

시장의 신호를 읽고, 올바른 타이밍에 전환하세요. 그리고 그 전환을 위한 예산과 계획을 미리 준비하세요.

 

제가 만약 다시 창업한다면? 물론 저는 개발자이기 때문에 제가 직접 제작하고 빠르게 검증했을 겁니다.

 

하지만 쉽디 쉬운 노코드 툴조차 어려워서 사용하지 못하는 비개발자라고 하면 초기에는 외주로 빠르게 검증하고, PMF가 보이는 순간 바로 인하우스로 전환할 겁니다. 그게 가장 빠르고 경제적인 길이니까요.

 

여러분의 스타트업은 지금 어느 단계인가요? 전환 타이밍을 놓치고 있는 건 아닌가요?

---

이 글은 '모두의 CTO' 시리즈의 일곱 번째 글입니다. 다음 글에서는 "5명 개발팀 vs 1명 풀스택"에 대해 다루겠습니다.