외주 인수인계 전 기술 부채 체크리스트 20

외주 프로젝트가 “오픈 완료”로 끝나는 순간, 담당자는 안도하기 쉽습니다.

그런데 실제 비용은 그 다음 주부터인 경우가 많습니다. 소스 위치가 불명확하고, 서버 접속 정보가 개인 메일에 흩어져 있으며, “이 부분만 아시는 분”이 퇴사하면 작은 수정도 견적이 커집니다.

흔히 기술 부채라고 부르지만, 발주자 언어로 바꾸면 나중에 청구될 미정산 작업 목록입니다.

이 글은 개발자가 아니어도 인수인계 미팅에서 확인할 수 있는 점검 항목 20가지를 정리합니다. 모든 항목을 완벽히 통과해야 하는 것은 아닙니다. 다만 미완료 항목이 문서에 남고, 잔여 비용·일정과 연결되어 있어야 합니다.

외주 인수인계 전 기술 부채 체크리스트 20 — 핵심 개념 시각 자료

이렇게 쓰면 좋아요

부분 통과를 통과로 바꿔 쓰지 않는 것이 핵심입니다.

점수보다 중요한 것은 미흡 항목에 가격을 붙이는 것입니다.

표의 “전형 비용”은 업계에서 반복되는 패턴 설명이며, 특정 수치 보장이 아닙니다.

인수인계 미팅에서는 시연만 보지 말고, 가능하면 저장소 받기 → 빌드 → 테스트 서버 배포 중 하나 이상을 함께 수행합니다.

“문서 나중에 드리겠습니다”는 잔금 조건에 날짜를 겁니다. 개인 메신저 산출물은 공식 산출물로 인정하지 않고, 이슈·위키·저장소로 모읍니다. 디자인 원본, 콘텐츠 원고, 외부 서비스 계약서도 기술 산출물과 같이 목록화합니다.

20항을 한 번에 못 채울 때는 중단 위험 순으로 닫습니다.

소유권(1~5)

계정·저장소·도메인이 없으면 서비스 자체가 남의 손에 있습니다.
운영 최소(11, 13, 14)

백업·로그·정기 작업을 모르면 장애 시 복구가 어렵습니다.
알려진 이슈(19)와 유지보수 합의(20)

미완을 숨긴 채 잔금을 치르면 분쟁만 남습니다.
코드 구조(6~10)

중요하지만, 소유권과 백업이 확보된 뒤에도 개선할 여지가 있습니다.
성능 전제(18)

트래픽 계획이 있으면 앞당기고, 없으면 가정만이라도 문서화합니다.

부분 통과 항목은 “기술 부채 대장”에 남겨 유지보수 백로그 1호로 삼습니다. 대장이 없으면 부채는 사라지지 않고 기억에서만 사라집니다.

체크리스트는 감사 도구이기도 하지만, 제안 요청 단계에 미리 첨부하면 저가·고위험 제안을 걸러내는 필터가 됩니다. “인수 시 이 20항을 통과 기준으로 합니다” 한 문장이 견적 품질을 바꿉니다.

체크리스트 없이 잔금을 치르면, 기술 부채는 제작사 책임이 아니라 발주자 자산의 결함으로 남습니다.

이후 다른 업체에 유지보수를 맡길 때 가장 먼저 나오는 말이 “현황 파악 비용”입니다. 현황 파악만으로 수 주가 걸리면, 기능 개선 예산이 조사비로 소진됩니다.

인수인계 부실은 보안 사고로 이어질 수 있습니다. 퇴사한 외주 인력의 개인 클라우드에 운영 키가 남아 있는 상태는, 계약이 끝났다고 자동으로 해소되지 않습니다.

LB Contents는 앱·홈페이지·쇼핑몰 제작과 운영 구조를 함께 설계합니다. 인수인계·유지보수 전환 전 점검이 필요하면, 요구사항이 완전히 정리되기 전에도 상담할 수 있습니다.