개발사 교체 체크리스트: 소스코드·서버·계정·문서를 안전하게 인수인계하는 법

개발사 교체의 핵심은 기존 업체와의 관계를 정리하는 것이 아니라, 새 팀이 서비스 운영을 재현할 수 있는 상태를 만드는 것입니다. 계약 종료 전에 소스코드만 전달받아서는 충분하지 않습니다. 클라우드·도메인 계정, 데이터 백업, 배포 절차, 외부 서비스, 보안 권한, 장애 대응 문서까지 발주사 소유로 확인하고 실제로 작동하는지 검수해야 합니다.

가장 안전한 방법은 2~4주의 인수인계 기간을 두고 기존 개발사와 새 개발사가 일정 기간 함께 운영하도록 하는 것입니다. 아래 체크리스트는 웹·앱·SaaS 프로젝트를 다른 개발사로 이관할 때 발주 담당자가 확인해야 할 항목을 순서대로 정리한 실무 가이드입니다.

개발사를 교체해야 하는 신호

담당자와 의견이 맞지 않는다는 이유만으로 즉시 개발사를 교체하면 오히려 비용과 위험이 커질 수 있습니다. 먼저 요구사항, 의사결정권자, 검수 기준이 내부에서 명확한지 확인해야 합니다. 그럼에도 다음 문제가 반복된다면 교체를 검토할 시점입니다.

• 장애 원인과 복구 예상 시간을 설명하지 못한다.
• 발주사가 Git 저장소, 클라우드 또는 도메인 관리자 권한을 갖고 있지 않다.
• 특정 개발자의 개인 PC나 개인 계정이 없으면 배포할 수 없다.
• 요청한 기능이 자주 누락되지만 검수 기준과 변경 이력이 없다.
• 월 유지보수 비용을 지불해도 처리 내역과 투입 근거를 확인하기 어렵다.
• 보안 업데이트와 백업 복구 테스트가 장기간 수행되지 않았다.
• 담당자 교체 때마다 시스템 지식이 사라지고 같은 설명을 반복해야 한다.

서비스 장애나 보안 사고가 진행 중이라면 계약 협의보다 먼저 운영 안정화와 증거 보존을 우선해야 합니다. 로그와 데이터베이스를 임의로 수정하지 말고, 현재 상태의 백업과 접근 기록을 확보한 뒤 대응 범위를 정하십시오.

교체를 결정하기 전에 확인할 5가지 원칙

1. 책임 공방보다 운영 연속성을 먼저 확보합니다. 기존 업체와의 분쟁이 있더라도 서비스에 필요한 접근 권한과 백업을 먼저 확인합니다.
2. 핵심 계정의 최종 소유자는 발주사여야 합니다. 개발사는 필요한 범위의 권한을 위임받아 사용하도록 구성합니다.
3. 문서가 아니라 재현 결과를 검수합니다. 새 팀이 깨끗한 환경에서 빌드·배포·복구할 수 있어야 인수인계가 끝난 것입니다.
4. 교체 전 상태를 보존합니다. 코드, DB, 서버 설정, 로그의 기준 시점을 만들어 누락과 변경을 추적합니다.
5. 종료 조건을 서면으로 합의합니다. 산출물 목록, 질의응답 기간, 계정 회수일, 미해결 이슈의 담당자를 명확히 합니다.

개발사 교체 체크리스트 25개

아래 표에서 ‘보유’는 파일을 받았다는 뜻이 아니라, 발주사 계정으로 접근할 수 있고 새 팀이 사용할 수 있음을 확인했다는 의미입니다.

1. 계약·권리와 프로젝트 범위

소스코드 소유권은 대금을 지급했다는 사실만으로 모든 경우에 자동 정리된다고 가정해서는 안 됩니다. 계약서에서 맞춤 개발 결과물, 개발사가 기존에 보유한 모듈, 오픈소스, 디자인·폰트·콘텐츠의 권리를 나누어 확인해야 합니다. 정부의 소프트웨어사업 표준하도급계약서도 안정적인 유지보수를 위해 소스코드, 오브젝트 코드, 매뉴얼, 설계서와 유지보수 자료 등을 기술자료로 예치할 수 있도록 규정하고 있습니다.

2. 계정과 디지털 자산

개인 이메일로 만든 계정을 비밀번호만 넘겨받는 것은 안전한 이관이 아닙니다. 가능하면 발주사 도메인의 그룹 메일과 조직 계정으로 소유권을 이전하고, 담당자 개인 계정에는 역할 기반 권한만 부여하십시오.

3. 소스코드와 배포 재현

14번이 가장 중요한 합격 기준입니다. 저장소에 코드가 있어도 누락된 환경 변수, 비공개 패키지, 수동 서버 설정 때문에 배포하지 못하는 경우가 많습니다. 인수인계 완료 서명 전에 새 팀이 별도 환경에서 동일 버전을 재현하도록 하십시오.

4. 인프라와 데이터

백업 성공 알림만으로는 부족합니다. 실제 복원에 걸리는 시간과 복원된 데이터의 시점을 기록해야 합니다. 서비스별 허용 중단 시간과 데이터 손실 범위를 정하면 새 팀이 우선순위를 판단하기 쉬워집니다.

5. 보안과 운영

한국인터넷진흥원(KISA)의 외주개발 보안 기준도 분석·설계부터 구현과 이관까지의 보안 요구사항을 계약에 반영하고, 취약점 조치와 불필요한 개발자 계정·권한 삭제를 확인한 뒤 검수하도록 안내합니다. 따라서 계정 회수와 비밀정보 교체는 프로젝트 종료 후의 선택 작업이 아니라 인수 조건에 포함해야 합니다.

권장 인수인계 일정: 2~4주

단순 기업 홈페이지는 더 짧게 끝날 수 있지만, 결제·개인정보·모바일 앱·배치 작업·다수 외부 연동이 있는 서비스는 충분한 병행 운영 기간이 필요합니다. 일정은 화면 수보다 시스템 의존성과 장애 시 손실을 기준으로 정하는 편이 안전합니다.

인수인계가 실패하는 대표적인 패턴

• ZIP 파일 하나로 종료: 어떤 커밋이 운영 중인지, 어떻게 빌드하는지 알 수 없습니다.
• 문서 전달을 검수로 착각: 오래된 구성도와 실제 서버가 다를 수 있습니다.
• 운영 계정부터 즉시 차단: 새 팀이 아직 장애 대응 방법을 모르는 상태에서 서비스 위험이 커집니다.
• 비밀번호를 메신저로 전달: 전달 이력이 남고 이후 회수 여부를 확인하기 어렵습니다.
• 미완료 기능과 결함을 섞음: 누가 비용을 부담해야 하는지 분쟁이 발생합니다.
• 기존 팀 없이 새 팀만 분석: 코드에 기록되지 않은 운영 규칙과 예외 처리를 놓치기 쉽습니다.

새 개발사에 요청할 첫 번째 산출물

새 개발사에 바로 기능 견적부터 요청하기보다, 먼저 1~2주간의 유상 진단을 맡기는 방법이 안전합니다. 진단 결과에는 다음 항목이 포함되어야 합니다.

• 현재 시스템 구성도와 실제 운영 환경의 차이
• 배포·복구 재현 결과
• 치명도별 보안 및 운영 위험
• 즉시 수정, 30일 내 개선, 장기 개선으로 나눈 우선순위
• 기존 기능 유지 비용과 개선 개발 비용의 구분
• 90일 운영 안정화 계획

이 과정을 거치면 새 업체도 불완전한 정보로 고정가 견적을 내는 위험을 줄일 수 있습니다. 발주사는 낮은 초기 견적 뒤에 숨어 있는 추가 비용을 더 일찍 확인할 수 있습니다.

개발사 교체 전 최종 판정표

자주 묻는 질문

개발사 교체에는 보통 얼마나 걸리나요?

구성이 단순하고 문서가 잘 정리된 서비스는 1~2주에도 가능하지만, 운영 중인 웹·앱 서비스는 일반적으로 2~4주의 병행 인수인계가 안전합니다. 레거시 시스템이나 결제·개인정보·다수 외부 연동이 있으면 진단과 안정화 기간을 별도로 잡아야 합니다.

기존 개발사가 소스코드를 주지 않으면 어떻게 해야 하나요?

먼저 계약서의 결과물 범위, 지식재산권, 대금 지급 조건과 계약 종료 조항을 확인해야 합니다. 권리 관계는 계약 유형과 기존 보유 기술 포함 여부에 따라 달라질 수 있으므로, 분쟁 가능성이 있다면 임의로 접근하거나 복제하지 말고 변호사 등 법률 전문가의 검토를 받는 것이 안전합니다.

Git 저장소만 받으면 인수인계가 끝난 것 아닌가요?

아닙니다. 환경 변수, 비공개 패키지, 데이터베이스 마이그레이션, 인프라 설정과 배포 권한이 없으면 코드를 실행하지 못할 수 있습니다. 새 팀이 깨끗한 환경에서 빌드하고 테스트 환경에 배포하는 것까지 검수해야 합니다.

기존 개발사의 계정은 언제 삭제해야 하나요?

새 팀이 운영과 복구를 재현하고 최종 검수가 끝난 직후가 적절합니다. 종료일에는 기존 계정을 비활성화하고 API 키, SSH 키, DB 비밀번호와 웹훅 서명키를 교체한 뒤 접근 로그를 확인하십시오.

서비스를 중단하지 않고 개발사를 바꿀 수 있나요?

대부분 가능합니다. 기존 팀이 운영을 유지하는 동안 새 팀이 읽기 권한으로 분석하고, 테스트 환경에서 배포와 복구를 재현한 뒤 소규모 변경부터 맡는 병행 운영 방식을 사용합니다. DNS, 인증서, 결제나 앱 서명 키처럼 되돌리기 어려운 변경에는 별도 롤백 계획이 필요합니다.

새 개발사는 어떤 기준으로 선택해야 하나요?

새 기능 개발 능력뿐 아니라 기존 코드 진단, 문서화, 클라우드 운영, 보안과 장애 대응 경험을 확인해야 합니다. 실제 인수인계 계획, 첫 30일 산출물, 담당자의 투입 범위와 커뮤니케이션 주기를 제안서에 명시하도록 요청하십시오.

기존 시스템을 안전하게 이관하려면

Nextchain은 코드만 넘겨받아 바로 기능 개발을 시작하기보다, 현재 시스템과 계정·배포·데이터 복구 상태를 먼저 진단하고 위험도에 따라 이관 순서를 설계합니다. 기존 업체에서 새 개발팀으로의 전환이 필요하다면 IT 컨설팅 서비스와 개발 프로세스를 확인하거나, 기존 시스템 이관 진단을 문의해 주세요.

이 글은 일반적인 프로젝트 운영 정보를 제공하며 개별 계약에 대한 법률 자문이 아닙니다. 계약 해지, 지식재산권 또는 손해배상 분쟁은 관련 전문가의 검토를 받으십시오.

참고 자료

• 한국인터넷진흥원, 소프트웨어 개발 보안 가이드
• 국가법령정보센터, 소프트웨어 진흥법
• 소프트웨어사업 표준하도급계약서