개발사를 바꿔야 하는 상황은 생각보다 자주 일어납니다. 비용이 맞지 않거나, 소통이 안 되거나, 기술적으로 한계에 부딪히거나. 이유는 다양하지만, 이전 과정은 쉽지 않습니다. 준비 없이 진행하면 비용과 시간을 크게 잃습니다.

개발사를 바꾸게 되는 이유

• 비용 문제: 유지보수 비용이 지속적으로 올라가거나, 작은 수정에도 높은 비용을 청구. "이건 구조를 바꿔야 해서 비용이 많이 듭니다"가 매번 반복
• 소통 문제: 요청에 대한 응답이 느리거나, 결과물이 요청과 다르거나, 비즈니스 맥락을 이해하지 못함
• 기술 불일치: 서비스가 성장하면서 필요한 기술이 바뀌었는데, 기존 개발사가 대응을 못 하는 경우

개발사가 역갑질 하는 경우

외주 관계에서 클라이언트가 갑이라고 생각하지만, 현실에서는 개발사가 갑이 되는 경우가 있습니다. 소스코드, 서버 접근 권한, 배포 방법 — 이 모든 게 개발사에만 있으면, 클라이언트는 개발사 없이 아무것도 할 수 없습니다.

이 구조를 악용하는 케이스:

• 유지보수 비용을 과도하게 올림: "이 서비스 저희 아니면 관리 못 합니다" — 대안이 없으니 울며 겨자 먹기로 수락
• 소스코드 인도를 거부하거나 지연: "소스코드는 저희 자산입니다" 또는 "정리해서 드릴게요"라고 하면서 몇 달째 안 줌
• 서버를 인질로 잡음: 서버가 개발사 명의라 이전하려면 개발사 협조가 필요한데, 협조를 안 함
• 추가 개발을 부풀림: "이 기능을 추가하려면 기존 구조를 다 바꿔야 합니다" — 실제로는 작은 수정인데 큰 작업으로 부풀림
• 이전 결정을 알리면 태도 변화: 갑자기 대응이 느려지거나, 하자보수 기간인데도 "우리 범위가 아닙니다" 시작

저희가 인수받은 사이트들의 상태

실제로 저희가 다른 개발사로부터 인수받은 프로젝트들의 상태를 보면, "더 이상 이 개발사와 하면 안 된다"고 판단할 수밖에 없는 경우가 많았습니다.

• HTTPS 인증서 미적용: 2026년인데 아직 HTTP로 운영 중. 브라우저에 "안전하지 않음" 경고가 뜨는 상태로 고객을 맞이하고 있었음
• 서버 접속 정보를 클라이언트가 모름: 서버가 어디에 있는지, 어떻게 접속하는지 클라이언트가 전혀 모르는 상태. 개발사에 완전 종속
• 백업이 없음: DB 백업이 한 번도 안 되어 있어서, 서버에 문제가 생기면 데이터가 통째로 날아가는 상태
• 비밀번호 평문 저장: 회원 비밀번호가 암호화 없이 DB에 그대로 저장. 개인정보 유출 시 법적 책임이 클라이언트에게
• 테스트 데이터가 실서비스에 남아있음: "test", "ㅁㄴㅇㄹ" 같은 데이터가 실 DB에 그대로
• 에러 페이지가 서버 정보를 노출: 에러 발생 시 서버 경로, DB 정보가 화면에 그대로 출력

이런 상태로 운영되고 있었다는 건, 이전 개발사가 기본적인 것조차 안 했다는 뜻입니다. 이 정도면 이전이 아니라 탈출입니다.

이전 전에 반드시 확보해야 할 것

이전을 결정했다면, 새로운 개발사를 찾기 전에 먼저 확보해야 할 것들이 있습니다.

• 소스코드: 전체 소스코드(프론트엔드, 백엔드, 모바일), Git 저장소 접근 권한, 환경 설정 파일(.env)
• 서버 정보: 서버 접속 정보(SSH), DB 접속 정보, 도메인 관리 계정, SSL 인증서, 클라우드 서비스 계정(AWS, GCP 등)
• 문서: API 문서, DB 구조(ERD), 배포 절차 문서, 관리자 매뉴얼

현실적으로 문서가 없는 경우가 많습니다. 그래도 있는 만큼 확보하세요. 문서가 없으면 새 개발사가 코드를 분석하는 데 더 많은 시간(비용)이 듭니다.

이런 상황을 방지하려면 처음부터, 또는 최소한 완료 시점부터 소스코드, 서버, 도메인을 클라이언트 명의로 관리하고, 계약서에 소유권과 인수인계 조항을 명확히 넣어야 합니다.

왜 다른 개발사가 인수를 꺼려하는가

솔직히 대부분의 개발사는 다른 회사가 만든 프로젝트를 이어받는 걸 꺼립니다.

• 첫 개발사에게 대부분의 프로젝트 자금이 이미 흡수된 상태라, 남은 유지보수 예산이 좋게 책정되지 않습니다
• 기존 소스코드를 신뢰할 수 없습니다. 어디에 지뢰가 묻혀 있을지 모릅니다
• 기존 버그까지 뒤집어쓸 리스크가 있습니다
• 그리고 더 큰 문제는, 다른 개발사로 갈아타는 경우는 이전 개발사와 이미 사이가 파탄 난 경우가 대부분입니다. 관계가 틀어진 상태에서 이전 개발사 담당자에게 친절한 인수인계를 기대하기 어렵습니다. 문서도 없고, 물어볼 사람도 없는 상태에서 코드만 보고 분석해야 합니다

이전 비용: 새 개발사의 분석 시간

새 개발사가 기존 코드를 인수받으면, 바로 작업을 시작하지 못합니다. 코드 구조 파악, 비즈니스 로직 이해, 기술 부채 식별 — 보통 1~4주의 분석 기간이 필요하고, 이 기간에도 비용이 발생합니다. 분석이 끝나면 기존 코드를 유지보수할지, 부분 또는 전체 재개발할지를 판단합니다.

그래도 해드린 경험

프로덕트 메이커는 9개의 소스코드 프로젝트가 서로 연동되는 서비스를 인수인계 없이 유지보수한 경험이 있습니다. Android, iOS 앱, 미디어 서버, 공지 서버, 콘텐츠 서버, 관리자 페이지 등 여러 서비스가 복잡하게 엮여 있었고, 인프라에도 특정 플랫폼에 강하게 락인된 상태였습니다.

인수인계 가이드는 하나도 없었습니다. 코드를 열어보면서 직접 구조를 파악해야 했습니다. 클라이언트가 "다음 프로젝트를 약속할 테니 이번 한 번만 부탁합니다"라고 해서 진행했는데, 그 약속은 지켜지지 않았습니다.

결과적으로 이 프로젝트에서 마이너스가 났습니다. 하지만 맡은 건 다 해결해드렸습니다. 굉장히 어려운 프로젝트였지만, 클라이언트의 서비스는 정상적으로 돌아가게 됐습니다.

반대로, 저희가 만든 프로젝트를 넘겨드릴 때

프로덕트 메이커에서 개발한 프로젝트의 인수인계를 요청하시는 경우, 이미 프로세스가 있습니다. 배포 방법, 간단한 업데이트 방법, 서비스 구조 설명 — 문서로 정리해서 전달합니다. 필요하면 동영상을 녹화해서 보내드리기도 하고, 클라이언트 쪽 담당자를 저희 회사에 불러서 직접 인수인계를 진행하기도 합니다.

실제로 어떤 클라이언트는 내부 개발팀이 3번 공중분해된 적이 있었습니다. 팀이 바뀔 때마다 저희가 다시 들어가서 새 담당자에게 인수인계를 해드렸습니다. 공중분해된 이전 담당자들은 회사와 관계가 파탄 나서 인수인계를 할 의지가 없었습니다. 전화를 피했습니다. 결국 저희가 그 역할을 대신한 겁니다.

그리고 솔직히 말씀드리면, 저희 회사에서 다른 곳으로 넘어가실 때 저희가 가지는 감정적 소모는 제로입니다. 더 가까운 곳을 찾았거나, 더 저렴한 곳을 찾았거나, 더 믿음직해 보이는 곳을 찾았거나, 내부적으로 처리하기로 했거나 — 사유는 다양하겠지만 그건 클라이언트의 판단이고, 저희는 그런 사정이 있겠거니 합니다. 다만 저희가 만든 것을 베이스로 그 서비스가 성공하길 바랄 뿐입니다. 그래서 인수인계를 꼼꼼하게 해드리는 겁니다.

인수인계를 "해주는" 개발사와 "안 해주는" 개발사의 차이는, 프로젝트가 끝난 뒤에 비로소 체감됩니다.

*개발사 이전이 필요하시거나, 기존 프로젝트를 인수해서 이어 개발이 필요하시다면, 프로젝트 상담을 통해 문의해 주세요.*