개발사 교체, 언제 결정해야 하나 — 중단된 프로젝트를 넘기기 전에 확인할 6가지

개발사 교체를 검색해서 이 글을 보고 계신다면, 아마 지난 몇 주 동안 거의 같은 내용의 주간 보고를 반복해서 받고 계실 겁니다. 진행률은 지난달에도 80%였고 이번 달에도 80%입니다. 데모는 매번 “거의 다 됐다”는 설명과 함께 열리지만, 화면 두세 개를 넘기면 멈춥니다. 수정 요청에 답이 오는 데 이틀이 걸리고, 그 답은 대개 “확인 후 회신드리겠습니다”입니다.

이 상태에서 가장 먼저 드는 생각은 교체가 아니라 계산입니다. 이미 지급한 기성금이 얼마인지, 여기서 손을 떼면 그 돈이 어떻게 되는지, 새로 시작하면 처음부터 다시 해야 하는 것은 아닌지를 먼저 따지게 됩니다. 그래서 대부분의 발주사는 필요한 시점보다 훨씬 오래 버팁니다. 한 달만 더 기다려 보자는 판단이 세 번 반복되면 분기가 지나가 있습니다.

이 글은 개발사 교체를 언제 결정해야 하는지, 결정 전에 무엇을 확보해야 하는지, 교체할 곳을 어떤 기준으로 골라야 하는지를 순서대로 정리했습니다. 미리 말씀드리면 결론은 “더 좋은 개발사를 찾으십시오”가 아닙니다. 첫 번째 개발사가 실패한 이유는 대개 그 회사의 성의 문제가 아니라 발주 구조의 문제이고, 같은 구조를 가진 다른 회사로 옮기면 같은 일이 다시 일어납니다.

디비컨설팅은 100개 이상의 프로젝트를 수행했고, 50개 이상의 글로벌 파트너사와 협업하며, 고객 만족도 98%를 유지하고 있습니다. 삼성물산, GS건설, LS일렉트릭, 하나투어, 가천대학교의 서비스를 구축했습니다. 아래 내용은 그 과정에서 반복적으로 확인한 패턴입니다.

개발사 교체가 논의되는 프로젝트의 공통 구조

멈춘 프로젝트를 들여다보면, 원인이 담당 개발자의 역량보다 앞선 단계에 있는 경우가 많습니다. 계약 시점에 이미 정해진 세 가지 구조 때문에 프로젝트는 대체로 같은 방식으로 멈춥니다. 저희가 IT 외주 프로젝트가 납기 후 분쟁으로 끝나는 구조를 따로 정리한 이유도 여기에 있습니다.

요구사항이 문서로 존재하지 않습니다

착수 시점에 발주사가 받은 문서가 제안서와 견적서뿐인 경우가 많습니다. 화면 정의서, 기능 명세, 예외 처리 규칙이 없는 상태로 개발이 시작되면 이후의 모든 논의가 기억에 의존하게 됩니다. 회의에서 이야기한 기능이 빠져 있을 때 발주사는 “분명히 말씀드렸다”고 하고, 개발사는 “그 범위는 계약에 없었다”고 합니다. 양쪽 다 거짓말을 하는 것이 아니라 판단할 근거가 없는 것입니다.

이 구조에서는 분쟁이 사실 확인이 아니라 협상으로 흐릅니다. 그리고 협상은 대개 발주사에게 불리합니다. 개발사는 남은 일정과 투입 인력을 알고 있고 발주사는 모르기 때문입니다. 요구사항 문서는 개발을 잘하기 위한 부속물이 아니라, 분쟁이 생겼을 때 사실관계를 확정하는 장치입니다.

진행률 보고를 검증할 방법이 없습니다

“80%”라는 숫자는 검증 가능한 형태가 아닙니다. 무엇을 기준으로 80%인지, 남은 20%에 어떤 작업이 포함되는지가 정의되어 있지 않기 때문입니다. 진행률이 몇 달째 같은 자리에 머무는 프로젝트는 일이 아예 진행되지 않아서가 아니라, 처음부터 진행률을 셀 수 있는 단위로 쪼개지 않았기 때문에 그렇게 보입니다.

검증 가능한 보고는 숫자가 아니라 상태로 옵니다. 어떤 기능이 테스트 서버에 올라가 있고, 어떤 기능이 검수 대기이고, 어떤 항목이 아직 착수되지 않았는지가 목록으로 나와야 합니다. 발주사가 직접 눌러 볼 수 있는 테스트 환경이 없다면, 지금 받고 있는 진행률은 근거를 확인할 수 없는 숫자입니다.

산출물과 소스코드가 개발사 안에만 있습니다

세 번째 구조가 교체를 가장 어렵게 만듭니다. 소스코드가 개발사 계정의 저장소에만 있고, 서버와 도메인과 각종 API 키가 개발사 명의로 발급되어 있고, 데이터베이스 구조를 아는 사람이 그쪽 개발자 한 명뿐인 상태입니다. 이때 교체는 계약 해지의 문제가 아니라 이관의 문제가 됩니다.

이 구조는 시간이 지날수록 나빠집니다. 코드는 늘어나지만 문서는 늘지 않기 때문입니다. 출시 이후에도 같은 문제가 이어지는 이유는 인수인계되지 않은 코드가 유지보수 비용을 만드는 구조와 동일합니다.

교체를 망설이게 만드는 것은 이미 쓴 돈입니다. 하지만 실제로 비용을 키우는 것은 결정을 미루는 시간입니다. 이미 지급한 금액은 교체를 하든 하지 않든 회수되지 않는 반면, 지연되는 동안 발생하는 비용 — 시장 진입 시점을 놓치는 손실, 담당자가 조율에 쓰는 시간, 그리고 매달 늘어나는 이관 범위 — 은 계속 새로 발생합니다. 판단 기준은 “지금까지 얼마를 썼는가”가 아니라 “이 개발사와 계속 갔을 때 남은 일정 안에 완료될 근거가 있는가”입니다.

교체 전에 확인할 6가지

교체를 결정했다면, 통보 전에 확보해야 할 것이 있습니다. 순서가 중요합니다. 해지 의사를 먼저 전달하면 협조를 받기 어려워지는 경우가 많기 때문에, 아래 항목은 가능한 한 통보 이전에 확인하시는 편이 안전합니다.

1. 소스코드와 형상관리 접근 권한이 우리에게 있는지

Git 저장소에 발주사 계정으로 접근할 수 있는지 확인하십시오. 볼 것은 세 가지입니다. 저장소의 소유 계정이 누구인지, 전체 커밋 이력을 내려받을 수 있는지, 현재 운영 중인 버전이 어느 브랜치인지입니다. 개발사가 완성된 파일만 압축해서 전달하는 방식이라면 이력이 없는 코드를 받게 되고, 다음 개발사는 왜 그렇게 구현했는지를 알 수 없습니다. 서버, 도메인, 클라우드, 외부 API 계정의 명의도 같은 기준으로 확인하십시오.

2. 산출물 범위가 문서로 존재하는지

계약서에 적힌 산출물 목록과 실제로 받은 문서를 나란히 놓고 비교하십시오. 최소한 기획서(화면 정의서), API 명세, 데이터베이스 스키마, 배포 절차서 네 가지는 있어야 다음 개발사가 이어받을 수 있습니다. 특히 배포 절차서가 없으면 코드를 받아도 서비스를 다시 띄우지 못하는 상황이 생깁니다. 없다면 지금 요청하십시오. 계약 관계가 유지되는 동안이 이 요청이 통하는 마지막 시점입니다.

3. 중도 해지 조항과 기성 정산 기준

계약서에서 해지 통보 기간, 귀책사유 판단 방식, 기성 정산 기준, 지연배상금 조항을 먼저 확인하십시오. 기성 정산이 투입 공수 기준인지 완료 산출물 기준인지에 따라 정산 금액이 크게 달라집니다. 완료 산출물 기준이라면, 2번에서 확인한 문서 상태가 그대로 협상 근거가 됩니다. 다음 계약에서 같은 상황을 피하려면 개발 외주 계약서에서 서명 전에 확인할 조항을 함께 보시는 것이 좋습니다. 이 단계에서 오간 메일과 회의록을 시간순으로 정리해 두시는 것도 실무적으로 도움이 됩니다.

4. 이어받을 수 있는 상태인지, 재개발이 빠른지

감정이 아니라 기준으로 판단해야 하는 항목입니다. 다음 중 해당하는 것이 많다면, 재개발이 이어받기보다 빠른 경우도 있습니다.

• 코드에 주석과 문서가 거의 없고, 함수·변수 이름만으로 의도를 알 수 없다
• 데이터베이스 구조가 정리되지 않아 화면 하나를 고치면 다른 화면이 깨진다
• 테스트 코드가 전혀 없어 수정 후 정상 동작을 수동으로만 확인할 수 있다
• 사용된 프레임워크나 라이브러리 버전이 이미 지원 종료 상태다
• 완료로 보고된 기능 중 실제로 동작하는 비율이 절반 이하다

반대로 기능이 화면 단위로 분리되어 있고, 데이터 구조가 정리되어 있고, 배포가 재현 가능하다면 이어받는 편이 유리합니다. 판단 방식 자체는 고칠 것과 다시 만들 것을 가르는 기준과 같습니다. 다만 이 판단은 코드를 열어 보지 않고는 할 수 없습니다. 교체 후보 업체에 기존 코드 진단을 먼저 요청하시고, 진단 없이 견적부터 제시하는 곳은 한 번 더 확인해 보시는 것이 좋습니다.

5. 지식재산권과 소스코드 소유권이 누구에게 귀속되는지

계약서에 소유권 귀속 조항이 있는지, 있다면 누구에게 귀속되는지 확인하십시오. 이 조항이 아예 빠져 있거나, 개발사가 저작권을 보유하고 발주사에 사용권만 부여하는 형태로 되어 있는 경우가 적지 않습니다. 후자라면 코드를 받아도 다음 개발사가 자유롭게 수정하고 배포할 수 있는지가 불확실해집니다. 제3자 라이브러리나 상용 솔루션이 포함된 경우, 그 라이선스가 발주사 명의로 이전 가능한지도 함께 확인하십시오.

6. 다음 개발사에게 넘길 인수 패키지를 어떻게 확보할 것인지

교체는 해지로 끝나지 않고 인수로 끝납니다. 통보 전에 인수 패키지 목록을 문서로 만들어 두시고, 해지 합의서에 그 목록과 인계 기한을 명시하십시오. 최소 구성은 다음과 같습니다.

• 전체 소스코드와 커밋 이력
• 데이터베이스 스키마와 운영 데이터 백업
• 서버·도메인·클라우드·외부 API 계정의 명의 이전
• 기획서, API 명세, 배포 절차서
• 미완료 기능 목록과 알려진 결함 목록
• 인계 후 일정 기간의 질의 응답 창구

마지막 항목이 실무에서 가장 자주 빠집니다. 인계 직후에는 반드시 질문이 생기는데, 그 시점에 연락이 닿지 않으면 문서가 있어도 시간이 걸립니다.

교체할 곳을 고르는 기준

여기까지가 실무 준비입니다. 그런데 준비를 다 하고 새 업체와 계약해도 6개월 뒤에 같은 자리에 서 있는 경우가 있습니다. 회사 이름만 바뀌고 구조가 그대로였기 때문입니다.

앞에서 정리한 세 가지 — 문서화되지 않은 요구사항, 검증 불가능한 진행률, 개발사 안에만 있는 산출물 — 는 특정 회사의 문제가 아니라 발주 방식의 문제입니다. 그래서 후보를 볼 때 확인해야 하는 것은 포트폴리오의 화려함이 아니라, 이 세 가지가 누구의 책임으로 정의되어 있는지입니다. 현실적으로 선택지는 세 가지입니다.

	국내 개발사	해외 직접 발주	한국 PM + 글로벌 개발팀
개발 단가	높음	낮음	낮음
요구사항 정의 책임	개발사	발주사 본인	한국 PM
커뮤니케이션 언어	한국어	영어	한국어
발주사 담당자 투입 시간	보통	매우 많음	적음
재작업 리스크	낮음	높음	낮음
총비용 관점	비쌈	기대만큼 안 싸다	실질 절감

국내 개발사는 한국어로 소통하고 요구사항 정의도 맡아 주지만 단가가 높습니다. 예산이 맞지 않으면 인력 등급이나 투입 기간을 줄이게 되고, 그 지점에서 앞의 구조가 다시 생깁니다. 방금 겪은 프로젝트가 국내 개발사였다면, 비슷한 조건으로 다시 계약하는 것은 같은 구조를 한 번 더 시도하는 선택입니다.

해외 팀에 직접 발주하는 방식은 단가가 분명히 낮습니다. 문제는 표에서 굵게 표시한 두 칸입니다. 요구사항을 정의하는 책임과 매일의 조율 부담이 발주사 본인에게 넘어옵니다. 사내에 개발 조직과 PM이 있는 회사라면 이 방식이 가장 저렴합니다. 그런데 지금 개발사 교체를 검토하는 회사는 대부분 사내에 그 역할을 할 사람이 없습니다. 없는 상태에서 영어와 시차를 끼고 팀을 관리하면, 낮은 단가로 시작해도 재작업이 쌓여 총비용은 기대만큼 내려가지 않습니다. 견적의 1.5배가 되는 일은 드물지 않습니다. 항목별로 어떻게 벌어지는지는 IT 외주개발 비용 비교에 정리해 두었습니다.

남는 것은 세 번째 열입니다. 개발 단가는 해외 직접 발주와 같은 수준이고, 요구사항 정의와 일정 관리와 검수는 한국인 PM이 책임집니다. 발주사는 한국어로 한 사람과만 이야기합니다. 특별히 새로운 방식은 아닙니다. 국내 개발사가 담당했던 관리 역할과 해외 팀의 단가를 분리해 결합한 것이고, 프로젝트를 멈추게 한 세 가지 항목의 책임 소재를 계약 단계에서 확정해 두는 방식입니다. 디비컨설팅의 IT 아웃소싱이 이 구조로 운영됩니다.

디비컨설팅이 이관을 진행하는 방식

1. 상담 및 요구 분석

비즈니스 목표와 기술 요구사항을 한국어로 문서화하는 단계입니다. 이관 프로젝트에서는 여기에 하나가 더 붙습니다. 기존 산출물의 상태를 진단합니다. 소스코드와 데이터베이스 구조를 열어 보고, 이어받을 범위와 다시 만들어야 하는 범위를 나눠 문서로 정리합니다. 이 단계에서 확정된 문서가 이후의 재작업을 대부분 없앱니다. 견적이 이 단계 이후에 확정되는 이유도 같습니다.

2. 개발팀 구성

진단 결과에 맞춰 전담팀을 2~4주 내에 구성합니다. 필요한 역할과 인력 등급을 확정하고 한국인 PM이 팀에 배정됩니다. 발주사는 이 PM을 통해서만 커뮤니케이션합니다. 글로벌 개발팀을 어떻게 검증하고 운영하는지는 인도 IT 아웃소싱의 진화에서 더 자세히 다뤘습니다.

3. 프로젝트 개발

애자일 방식으로 진행하며 진행 상황을 투명하게 공유합니다. 스프린트 단위로 동작하는 결과물이 테스트 환경에 올라가고, 발주사는 진행률 숫자가 아니라 실제 화면으로 확인합니다. 개발팀과의 일정 조율, 우선순위 정리, 이슈 처리는 PM이 맡습니다. 발주사 담당자가 조율에 하루를 쓰지 않습니다.

4. 테스트 및 배포

QA 프로세스를 거친 뒤 배포합니다. 이관 프로젝트에서는 신규 기능 테스트와 함께, 기존에 동작하던 기능이 그대로 동작하는지 확인하는 회귀 테스트가 특히 중요합니다. 배포 절차는 다른 사람이 그대로 따라 할 수 있는 형태로 문서화합니다.

5. 운영 및 유지보수

문서와 함께 인계하고 장기 지원을 이어갑니다. 소스코드, API 명세, 데이터베이스 스키마, 배포 절차서가 발주사에 남습니다. 분명히 말씀드리면, 지금의 문제는 이 단계가 없었기 때문에 생겼습니다. 첫 번째 개발사가 문서 없이 코드만 들고 있었기 때문에 교체가 어려워졌고, 그 상태가 협상에서 그대로 불리하게 작용했습니다. 인계 문서는 다음 개발사를 위한 것이 아니라, 발주사가 언제든 선택할 수 있는 상태를 유지하기 위한 것입니다.

실제 구축 사례

• 삼성물산 — 홈닉, 주거 플랫폼 앱
• GS건설 — 엘리시안 리조트, 리조트 웹·앱 통합 구축
• 하나투어 — 하나오픈챗, 여행 상담 채팅 서비스
• LS일렉트릭 — 테크스퀘어, 산업 B2B 거래 플랫폼
• 직방 — 호갱노노, 부동산 데이터 서비스
• 가천대학교 — 학사관리 시스템

산업군은 교육, 금융·핀테크, 헬스케어, 제조·물류, 이커머스, 스마트빌딩·IoT에 걸쳐 있습니다. 도메인이 달라도 요구사항을 한국어로 확정하고 검수 기준을 먼저 정한 뒤 진행하는 방식은 동일하게 적용됩니다. 전체 목록은 포트폴리오에서 확인하실 수 있습니다.

이런 기업에 적합합니다

• 사내에 개발 조직이나 PM이 없어, 요구사항 정의부터 맡길 곳이 필요한 경우
• 진행 중인 프로젝트가 멈춰 있고, 기존 산출물 진단부터 시작해야 하는 경우
• 국내 개발사 견적이 예산을 넘지만 품질 기준은 낮추고 싶지 않은 경우
• 해외 팀 수준의 단가는 필요하지만 영어 커뮤니케이션과 시차 조율은 감당할 수 없는 경우
• 소스코드와 문서를 반드시 자사에 남겨야 하는 경우

이어받는 대상이 모바일 서비스라면 앱 개발 외주, 웹 서비스나 플랫폼이라면 웹 개발 외주 쪽 진행 방식을 함께 참고하시면 됩니다.

반대로, 권하지 않습니다

• 사내에 개발 조직과 PM이 이미 있고 단가만 낮추려는 경우 — 해외 팀에 직접 발주하시는 편이 더 저렴합니다.
• 남은 작업이 며칠 수준의 소규모 수정인 경우 — 팀을 구성하는 시간이 작업 시간보다 길어집니다.
• 요구사항을 끝까지 확정하지 않고 일단 시작하려는 경우 — 이 방식은 첫 번째 실패의 원인과 동일합니다. 저희와 하셔도 같은 결과가 나옵니다.
• 업체 선정 기준이 최저 단가 하나인 경우 — 그 기준에는 항상 더 낮은 곳이 있고, 지금 상황이 그 결과일 수 있습니다.

자주 묻는 질문

해외 개발팀인데 의사소통은 어떻게 됩니까?

발주사는 한국인 PM하고만 한국어로 소통합니다. 해외 개발팀과 직접 이야기하는 일은 없습니다. 요구사항 정의, 일정 관리, 검수는 PM의 책임이며 회의도 한국 시간 기준으로 진행됩니다. 영어로 스펙을 다시 쓰거나 시차에 맞춰 새벽에 회의를 잡는 일은 발주사 쪽에서 발생하지 않습니다.

이관 비용은 어떻게 산정됩니까?

인력 등급별 단가와 투입 기간을 기준으로 산정하고, 기획·디자인·개발·QA·배포·유지보수를 항목별로 구분해 제시합니다. 이관 프로젝트는 기존 산출물 진단 결과에 따라 이어받는 범위가 달라지므로, 진단 이후에 범위와 금액이 확정됩니다. 진단 전 금액은 개략 견적이며, 확정 시 차이가 어디에서 발생했는지도 함께 설명드립니다.

기획서가 없는데 견적이 가능합니까?

가능합니다. 해결하려는 문제, 주요 사용자, 반드시 필요한 기능 3~5개, 일정과 예산의 범위만 있으면 개략 견적을 드릴 수 있습니다. 멈춰 있는 프로젝트라면 기존 화면과 코드가 기획서 역할을 일부 대신하기도 합니다. 기획서를 만들어 오시는 것이 아니라, 기획서를 만드는 일부터 함께하는 것이 1단계입니다.

팀 규모를 조정할 수 있습니까?

가능합니다. 전담팀, 장기 협업, 인력 단위, 프로젝트 단위 중에서 선택할 수 있고 진행 중에도 조정할 수 있습니다. 이관 초기에는 진단과 정리에 인력을 집중하고 이후 개발 인력을 늘리는 형태로 구성할 수 있습니다.

소스코드 소유권은 누구에게 있습니까?

발주사에 귀속됩니다. 소스코드만이 아니라 API 명세, 데이터베이스 스키마, 배포 절차 문서까지 인계 대상에 포함합니다. 이 항목을 강조하는 이유는, 지금 개발사 교체가 어려워진 원인이 대부분 여기에 있기 때문입니다. 코드와 지식이 개발사 한쪽에만 있으면 발주사는 협상에서 선택권을 잃고, 남는 선택지는 계속 끌려가는 것뿐입니다. 소유권과 인계 문서를 계약 단계에서 확정해 두면, 다음에는 교체를 검토할 일이 생겨도 그것이 위기가 아니라 그냥 선택이 됩니다.

정리

개발사 교체는 회사를 바꾸는 일이 아니라 구조를 바꾸는 일이어야 합니다. 요구사항이 문서로 남는지, 진행률을 발주사가 직접 확인할 수 있는지, 소스코드와 문서가 발주사에 귀속되는지 — 이 세 가지가 계약서에 정해져 있지 않으면 다음 개발사에서도 같은 주간 보고를 받게 됩니다. 지금 비교해야 할 것은 후보들의 포트폴리오보다 이 세 가지의 책임 소재이고, 사내에 개발 조직이 없다면 그 책임을 한국어로 대신 지는 PM 층이 구조 안에 반드시 있어야 합니다.