"지금 개발사 바꾸면 다 날아가는 거 아닌가요?"
이 질문을 받을 때마다 "꼭 그렇지는 않습니다"라고 대답하지만, 솔직히 말하면 상황에 따라 다릅니다. 준비 없이 교체하면 실제로 상당 부분 날아갑니다. 반면 제대로 준비한다면, 생각보다 훨씬 적은 손실로 새 출발이 가능합니다.
개발사 교체는 창업자가 겪는 가장 고통스러운 결정 중 하나입니다. 계약을 맺을 때는 몰랐던 문제들이 수개월 후에야 수면 위로 드러나고, 그때는 이미 상당한 자금과 시간이 들어간 이후입니다. "지금 바꾸는 게 맞는 건지", "인수인계에 몇 달이 걸린다는데", "차라리 처음부터 다시 만드는 게 나을까"—이런 고민이 겹치면서 판단이 흐려집니다.
이 글에서는 교체 타이밍 판단, 현 개발사에서 자산을 최대한 회수하는 방법, 새 개발사로 넘어가는 과정에서 맥락 손실을 최소화하는 방법을 다룹니다.
교체를 고민해야 하는 신호
모든 외주 프로젝트에는 마찰이 있습니다. 마찰 자체가 교체의 이유가 되기는 어렵습니다. 하지만 다음 신호들이 복수로 겹친다면 진지하게 검토할 시점입니다.
기술 부채가 통제 불능 수준으로 쌓이고 있을 때
"빠르게 개발하다 보니 코드가 복잡해졌어요"는 어느 정도 이해할 수 있습니다. 그런데 새 기능 하나를 추가할 때마다 기존 기능이 망가지거나, 버그 수정 하나에 몇 주가 걸린다면 이미 구조적 문제입니다. 이 시점에서 계속 같은 개발사에 맡기면 기술 부채가 서비스 수명을 잠식하기 시작합니다.
소스코드와 인프라를 직접 접근할 수 없을 때
GitHub 저장소에 클라이언트 계정으로 접근하거나 배포 환경에 대한 권한이 없다면, 이미 위험한 상태입니다. 개발사가 연락 두절이 되거나 계약 분쟁이 생겼을 때 속수무책이 됩니다. 이런 상황이라면 교체보다 먼저 자산 회수가 우선입니다.
납품 품질에 대한 신뢰가 무너졌을 때
버그가 많다, 화면이 느리다, 테스트가 없다—이런 개별 문제는 협의로 개선할 수 있습니다. 하지만 약속을 반복적으로 어기고, 책임을 클라이언트 쪽으로 전가하며, 결과물에 대한 설명을 회피한다면 관계의 신뢰 자체가 손상된 것입니다. 이 경우 계속 진행해도 결과가 바뀌기 어렵습니다.
핵심 인력이 교체되었는데 공지가 없었을 때
처음 계약할 때 대화하던 개발자가 프로젝트 중간에 교체되는 건 흔한 일입니다. 문제는 그 사실을 알리지 않거나, 새 인력이 맥락을 전혀 모른 채 투입되는 경우입니다. 이런 패턴은 내부 인력 운영에 구조적인 문제가 있다는 신호입니다.
어느 하나만으로 교체를 결정하기는 어렵습니다. 그러나 두세 가지가 겹쳐 있다면, "좀 더 기다려보자"보다 "지금 무엇을 할 수 있는지 파악하자"가 적절한 시점입니다. 외주 프로젝트가 흔들리기 시작했을 때의 대응 방법은 외주 진행 중 문제 대응 매뉴얼에서 상황별로 정리해뒀습니다.
"처음부터 다시 만드는 게 나을까" — 판단 기준
교체를 결심하면 가장 먼저 맞닥뜨리는 질문입니다. 현재 코드를 이어받는 게 나을까, 아니면 새로 시작하는 게 나을까.
답은 현재 코드베이스의 상태에 달려 있습니다.
재작성(리빌드)이 나은 경우
- 핵심 아키텍처 결정이 비즈니스 방향과 근본적으로 맞지 않을 때 (예: 모놀리식으로 만든 서비스를 마이크로서비스로 전환해야 하는 경우)
- 소스코드를 전혀 인수받지 못한 경우
- 기술 스택이 너무 구식이어서 새 개발사가 이어받길 꺼리는 경우
- 시장 방향 자체가 크게 바뀌어 기능의 절반 이상을 갈아야 하는 경우
인수인계가 나은 경우
- 핵심 데이터가 쌓여 있고, 이 데이터를 새 시스템으로 옮기는 비용이 재작성보다 크지 않은 경우
- 비즈니스 로직이 복잡하게 구현되어 있어서 재작성 시 놓칠 엣지 케이스가 많을 때
- 실사용자가 있고, 서비스 중단 없이 이어가야 하는 경우
- 코드 구조 자체는 나쁘지 않지만 특정 모듈만 문제일 때
현장에서 보면 많은 창업자가 "차라리 처음부터"를 선택하고 싶어하지만, 실제로는 인수인계 후 부분 리팩토링이 더 빠른 경우가 많습니다. 리빌드는 생각보다 오래 걸리고, 그 사이에도 비즈니스는 멈추지 않으니까요.
다만 인수인계 자체를 포기해야 하는 상황도 있습니다. 기존 개발사가 소스코드를 제공하지 않거나 협조를 거부하는 경우, 실질적으로 리빌드 외의 선택지가 없습니다.
현 개발사에서 회수해야 할 것들
교체를 결정했다면, 먼저 확보해야 할 자산 목록이 있습니다. 이 단계에서 철저히 하지 않으면 이후에 훨씬 큰 비용이 들거나 아예 회수가 불가능해집니다.
소스코드 전체
브랜치 이력 포함한 전체 저장소를 넘겨받아야 합니다. "최신 버전만 드릴게요"는 충분하지 않습니다. 커밋 히스토리가 있어야 코드 변경 맥락을 파악할 수 있습니다.
데이터베이스 스키마와 데이터
스키마 덤프와 실데이터 백업 파일을 확보하세요. 데이터가 전혀 없는 경우라도 테이블 구조와 인덱스 설계만으로도 후속 개발사가 분석할 수 있는 것이 많습니다.
배포 및 인프라 설정
클라우드 계정 접근 권한, 도메인 등록 정보, SSL 인증서, 환경변수 목록. AWS나 GCP, Azure 등 어느 서비스를 쓰든 동일합니다.
외부 서비스 연동 정보
결제 API 키, 알림 서비스, 지도 API, 소셜 로그인 설정 등 연동된 외부 서비스의 키와 설정값. 이 정보가 없으면 서비스가 돌아가더라도 연동 기능이 전부 죽습니다.
기획·설계 문서
화면 기획서, API 명세서, DB 설계서, 회의록. 이런 문서가 체계적으로 남아 있는 개발사는 드물지만, 있다면 모두 요청하세요. 메신저 채팅 로그나 이메일 스레드도 맥락을 복원하는 데 도움이 됩니다.
기존 개발사가 이 정보들을 순순히 넘겨주지 않는 경우도 있습니다. 계약서에 "납품물의 소유권은 클라이언트에게 있다"는 조항이 있다면 법적 근거가 있습니다. 없다면 교섭이 필요하고, 경우에 따라 법적 조언을 구해야 할 수도 있습니다. 개발 외주 계약에서 소유권 조항을 어떻게 확인해야 하는지는 외주 견적서 검토 가이드에서 다루고 있습니다.
새 개발사에게 맥락을 전달하는 방법
인수인계의 진짜 어려움은 서류 전달이 아닙니다. "이 코드가 왜 이렇게 되어 있는지"를 설명하는 맥락이 사람 머릿속에만 있는 경우가 대부분이기 때문입니다.
새 개발사에게 필요한 것은 크게 세 가지입니다.
첫째, 현재 코드의 구조 파악. 새 개발사가 코드를 처음 받았을 때 스스로 구조를 파악하는 데는 시간이 걸립니다. 기존 개발사의 개발자나 클라이언트 측 담당자가 아키텍처를 한 번 설명해주는 세션을 갖는 것만으로도 온보딩 비용이 크게 줄어듭니다.
둘째, 알려진 문제와 기술 부채 목록. 기존 코드에 어떤 버그가 있는지, 어떤 부분이 임시방편으로 처리되어 있는지를 미리 공유하면 새 개발사가 지뢰를 밟을 가능성이 낮아집니다. 이 목록이 없으면 새 개발사도 결국 직접 탐색하는 시간이 필요합니다.
셋째, 비즈니스 의사결정 배경. "왜 이 기능이 이렇게 구현되어 있는지"에 대한 배경이 없으면 새 개발사는 불필요하게 바꾸거나, 바꾸면 안 되는 것을 바꿉니다. 기능 하나하나에 대한 기획 의도와 주요 결정 사항이 정리되어 있으면 이 비용을 절약할 수 있습니다.
현실적으로, 이 세 가지 정보를 체계적으로 보유하고 있는 클라이언트는 많지 않습니다. 개발이 진행되는 동안 문서화와 기록이 부족했기 때문입니다. 이 경우 새 개발사와의 인수인계 기간이 길어지는 건 불가피합니다. 하지만 적어도 현 개발사와의 코드 리뷰 세션 한두 번, 주요 설계 결정에 대한 메모라도 확보해두면 상당히 달라집니다.
인수인계를 구조화하는 실용적 방법
맥락 전달이 어렵다면, 새 개발사와의 온보딩 단계를 별도 페이즈로 분리하는 것이 실용적입니다.
탐색 단계를 첫 2~4주로 잡고, 이 기간에 새 개발사가 코드베이스를 분석하고 질문 목록을 정리하는 것을 공식 작업으로 포함시킵니다. "바로 개발부터 시작하자"는 압박보다, 이 단계에 적절한 비용을 투자하는 것이 전체 프로젝트의 속도와 품질 모두에 이득입니다.
이 탐색 결과를 문서로 남기면 나중에 또 다른 변경이 생겼을 때도 참조할 수 있는 자산이 됩니다.
스택 오버뷰 문서를 요청하세요. 새 개발사가 코드를 분석한 후, 프레임워크·라이브러리·외부 서비스 의존성·배포 구조를 한 페이지로 정리한 문서를 만들게 하는 겁니다. 이 문서가 있으면 이후에 팀이 바뀌어도 기본 맥락은 유지됩니다.
위험 영역 표시도 이 단계에서 해야 합니다. 건드리면 예상치 못한 부분이 망가질 수 있는 코드 영역, 테스트가 없어서 검증이 어려운 부분, 성능 병목이 예상되는 지점 등을 미리 파악해두면 이후 개발 계획을 현실적으로 세울 수 있습니다.
인테그래빗이 이 문제를 다루는 방식
인수인계가 이렇게 어려운 이유 중 하나는 프로젝트의 맥락이 한 곳에 모이지 않기 때문입니다. 기획서는 드라이브 어딘가, 회의 기록은 메신저 스레드, 버그 리포트는 이메일, 소스코드는 저장소에 따로따로 흩어져 있습니다. 개발사가 바뀌면 이 조각들을 다시 모으는 데만 몇 주가 걸립니다.
인테그래빗은 프로젝트가 진행되는 동안 산출물, 이슈 로그, 의사결정 내역, 커뮤니케이션 기록을 포털에 아카이빙합니다. 개발사가 바뀌는 상황이 발생하더라도, 새 개발사는 포털에서 프로젝트 히스토리를 한 번에 파악할 수 있습니다. "다음 개발사가 포털만 보면 바로 이어서 할 수 있습니다"—이것이 인테그래빗이 설계 단계부터 염두에 둔 방향입니다.
문서화가 부족한 채로 프로젝트를 시작했거나, 현재 개발사 교체를 고민 중이라면 처음부터 이런 구조 위에서 진행하는 것이 장기적으로 훨씬 안전합니다.
새 개발사를 선정할 때 추가로 확인할 것
교체를 결정했다면, 새 개발사 선정 과정에서 기존과 다르게 확인할 항목이 있습니다.
레거시 코드 인수 경험
새 개발사가 처음부터 개발하는 것과 기존 코드를 이어받는 것은 전혀 다른 작업입니다. "기존 코드 인수인계 해본 적 있나요?"라는 질문에 구체적인 사례를 들어 답할 수 있는지 확인하세요. 막연한 "가능합니다"보다 실제 경험이 있는 개발사가 훨씬 현실적인 접근을 합니다.
코드 감사 절차
신뢰할 수 있는 개발사라면 인수 전에 현재 코드 상태를 분석하고 결과를 공유하는 절차를 밟습니다. "일단 시작해보면서 파악하죠"라는 태도는 나중에 문제가 생겼을 때 책임 소재가 불분명해지기 쉽습니다.
인수인계 단계를 계약에 포함시키는 방식
탐색 단계를 별도 계약 단계로 분리하고, 그 결과에 따라 이후 작업 범위를 협의하는 구조를 제안하는 개발사는 현실적인 판단을 하는 곳입니다. 코드도 보지 않고 전체 견적부터 제시하는 개발사는 주의가 필요합니다.
커뮤니케이션 체계
기존 개발사와의 문제 중 상당수가 소통 방식에서 비롯됩니다. 새 개발사가 어떤 주기로, 어떤 형식으로 진행 상황을 공유하는지 계약 전에 구체적으로 확인하세요.
개발사 교체는 한 번 결정했다고 끝나는 게 아닙니다. 자산 회수, 인수인계, 새 개발사 온보딩까지 각 단계에서 신경 써야 할 것들이 있습니다. 하지만 준비된 교체는 "처음부터 다시"가 아닙니다. 기존에 쌓아온 것 위에서, 더 나은 파트너와 다시 시작하는 과정입니다.
개발사 교체를 고민 중이라면 — 30분 무료 상담에서 현재 상황을 함께 점검해 드립니다.