스타트업의 성장 과정에서 자연스럽게 찾아오는 전환점이 있습니다. 초기에는 외주 개발로 빠르게 제품을 만들었지만, 서비스가 궤도에 오르면서 내부 개발팀을 꾸려야 할 시점이 오는 것입니다.

중요한 건, 이 전환은 프로젝트가 성공했을 때 반드시 오는 단계라는 점입니다. 외주로 시작하더라도 서비스가 성장하면 결국 내부 팀을 꾸려야 합니다. 처음부터 이걸 염두에 두고 외주를 맡기면, 기술 스택 선택부터 인수인계 구조까지 자연스럽게 전환을 준비하는 방향으로 진행할 수 있습니다. 반대로 "일단 만들고 나중에 생각하자"는 접근은 전환 시점에 큰 비용으로 돌아옵니다.

전환이 실패하는 이유

기술 부채. 외주 업체가 자체적으로 만든 독자적인 프레임워크나 커스텀 라이브러리를 사용한 경우, 새로 합류한 내부 개발자가 코드를 이해하는 데만 수개월이 걸립니다. Thoughtworks는 대규모 프레임워크 마이그레이션이 "사실상 앱 재작성"이라고 명시한 바 있으며, 업계 데이터에 따르면 외주 코드의 기술 부채가 유지보수 예산의 60~80%를 흡수하는 경우도 있습니다.

문서 부재. API 명세서, DB 스키마 문서, 배포 가이드 없이 코드만 넘겨받으면 마치 설명서 없는 가구를 조립하는 것과 같습니다. 코드를 읽어도 왜 그렇게 설계했는지, 어떤 비즈니스 규칙이 적용되어 있는지 전혀 알 수가 없습니다.

소스 코드 소유권 문제. 계약서에 소스 코드 귀속 조항이 명확하지 않아 법적 분쟁으로 이어지는 사례도 있습니다. Git 히스토리 없이 최종 버전만 압축 파일로 받는 경우도 있는데, 이러면 변경 이력을 추적할 수 없어 유지보수가 어려워집니다.

배포 환경의 블랙박스화. 서버 설정, 환경 변수, 배포 스크립트가 외주 업체의 인프라에 묶여 있으면 독립적으로 서비스를 운영하는 것 자체가 불가능해집니다.

기존 개발사와의 관계 정리 실패. 의외로 많이 놓치는 부분입니다. 내부 개발팀을 꾸리거나 다른 개발사에게 맡기기로 했지만, 기존 개발사에게는 말하지 않습니다.

말하지 못하는 이유는 크게 두 가지입니다. 첫째, 새로운 시도가 실패하면 다시 기존 개발사에게 맡겨야 하니까 Plan B로 관계를 유지해두려는 것. 둘째, 더 솔직히 말하면, 전환 사실을 알렸을 때 기존 개발사가 서버를 삭제하거나 DB를 날려버리지 않을까 하는 막연한 두려움입니다. 이건 막연한 두려움이 아닐 수 있습니다. 협업하면서 그 개발사의 태도나 소통 방식을 경험했기 때문에, 이 사람들이라면 진짜 그럴 수도 있겠다는 합리적 의심이 드는 경우도 있습니다. 내 서비스의 모든 데이터가 상대방 손에 있는 상황에서, 관계가 좋지 않았다면 그 불안은 당연합니다.

하지만 이렇게 하면 인수인계가 제대로 이루어질 수 없습니다. 기존 개발사가 모르는 상태에서는 소스코드, 서버 접속 정보, 배포 절차 같은 것들을 체계적으로 넘겨받을 수 없고, 결국 새 팀이 코드를 처음부터 분석해야 합니다. 전환을 결정했다면, 기존 개발사에게 명확하게 이야기하고 인수인계를 정식으로 요청하는 게 결과적으로 비용이 적게 듭니다.

그래서 처음 외주를 맡길 때부터 서버, DB, 도메인, 외부 서비스 계정을 클라이언트 명의로 설정하는 것이 중요합니다. 이렇게 해놓으면 전환 시점에 상대방에 의존할 필요가 없습니다.

처음부터 전환을 염두에 둔 외주

외주를 맡기면서 "나중에 내부 팀을 꾸릴 수도 있다"는 생각을 갖고 있으면, 자연스럽게 확인하게 되는 것들이 있습니다.

• 이 기술 스택으로 개발자를 쉽게 구할 수 있는가?
• 코드를 다른 개발자가 이해할 수 있는 구조인가?
• 서버와 인프라가 우리 명의로 되어 있는가?
• 인수인계 문서가 자동으로 생성되는 구조인가?

이 질문들을 처음부터 하면서 외주를 진행하면, 전환 시점이 왔을 때 자연스럽게 넘어갈 수 있습니다. "일단 만들고 나중에 생각하자"와 "전환을 염두에 두고 만들자"의 차이가 나중에 수천만원의 재개발 비용 차이로 나타납니다.

성공적인 전환을 위한 조건

주류 기술 스택 사용. React, Next.js, Django 같은 범용적인 기술을 사용하면 채용 시장에서 해당 기술을 다룰 수 있는 개발자를 쉽게 찾을 수 있습니다. 마이너 기술일수록 구인이 어렵고, 인건비도 올라갑니다.

체계적인 문서화. API 명세서, DB 스키마 문서, 배포 가이드, 아키텍처 다이어그램이 최소한의 문서입니다. 이 문서들이 있으면 새 개발자가 프로젝트에 적응하는 시간이 크게 줄어듭니다.

단계적 인수인계. 처음 1개월은 외주팀과 함께 유지보수 업무를 내부 팀이 담당하고, 2개월차에는 소규모 기능 개선을, 3개월차부터 신규 기능 개발로 점진적으로 확대하는 방식이 가장 안전합니다.

저희의 방식

프로덕트 메이커는 프로젝트 첫날부터 인수인계를 염두에 두고 개발합니다. 소스 코드와 Git 저장소는 잔금 정산 후 클라이언트에게 귀속시키고, 커밋 히스토리를 포함한 전체 개발 이력을 함께 전달합니다. API 문서는 Swagger를 통해 자동 생성하고, 배포 환경은 Docker 컨테이너로 구성하여 어떤 클라우드에서든 동일하게 실행할 수 있도록 합니다.

외부 서비스의 계정과 API 키도 클라이언트 명의로 설정하여, 전환 후에도 독립적으로 운영할 수 있도록 합니다. 인수인계 이후에도 클라이언트가 연락 주시거나 방문 주시면 저희 사무실에서 직접 또는 원격, 화상으로 안내해드립니다.

참고로 저희는 인수인계 요청을 받아도 서운한 감정이 전혀 없습니다. 오히려 응원합니다. 서비스가 성장하려면 더 나은 방법을 지속적으로 모색하고 선택해야 하고, 외주 개발사의 한계가 명확한 부분도 있습니다. 내부 팀을 꾸리는 것은 서비스가 그만큼 성장했다는 뜻이니까요.

외주에서 내부로의 전환은 끝이 아니라 서비스 성장의 자연스러운 다음 단계입니다. 처음부터 이걸 염두에 두고 시작하는 것이 가장 확실한 준비입니다.