업체 교체 후 몇 달간 장애가 늘어나는 이유
유지보수(SM) 업체를 바꾸고 나서 3~6개월 동안 장애가 오히려 늘었다는 이야기는 흔합니다. 원인은 대개 기술력보다 인수인계 공백에 있습니다.
소스는 받았는데 빌드가 안 되는 경우: 저장소에 올라간 코드와 운영 서버에서 돌아가는 코드가 다르거나, 사내 라이브러리와 빌드 스크립트가 빠져 있습니다.운영 서버 접속 정보가 없는 경우: 클라우드 루트 계정, 도메인 관리 계정, SSL 인증서 발급 계정이 전 담당자 개인 이메일로 묶여 있는 일이 잦습니다.담당자 머릿속에만 있던 업무: 매월 말 수작업으로 돌리던 정산 보정 쿼리, 특정 거래처만 예외 처리하는 로직처럼 문서 어디에도 없는 작업이 이관 첫 달에 장애로 드러납니다.이관 전에 확보해야 할 자산 목록
코드와 배포
최신 소스 전체와 브랜치 전략(운영 배포 브랜치가 무엇인지)빌드·배포 절차서, CI/CD 설정 파일환경 변수, 서비스 계정, API 키, 인증서와 각각의 만료일데이터와 운영
DB 스키마와 최근 변경 이력, 백업 주기와 복구 절차배치 스케줄 목록(실행 시각, 실패 시 조치)외부 연동 목록: PG, 문자 발송, 공공 API 등과 계약 담당자·갱신일실무에서는 이 항목을 50~80개 체크리스트로 만들어 "받음/확인함/직접 실행해 봄" 3단계로 관리하는 것을 권장합니다. 받기만 한 자료는 실제로 쓸 수 있는지 아직 모르는 상태이기 때문입니다.
문서가 없을 때 역으로 파악하는 방법
문서가 부실하다면 시스템이 남긴 흔적에서 출발합니다.
운영 로그와 트래픽: 최근 90일 접근 로그를 URL별로 집계하면 실제로 쓰이는 기능과 방치된 기능이 구분됩니다. 전체 화면의 20~30%에 트래픽 대부분이 몰리는 경우가 많습니다.배치 이력: crontab과 스케줄러 실행 기록을 확인해 "누가 만들었는지 모르는 작업"을 찾아냅니다.코드 분석: 모듈 간 호출 관계와 외부 호출 지점을 정리해 의존성 지도를 만들고, 테스트가 없으면서 변경이 잦은 파일을 위험 구간으로 표시합니다.병행 운영 기간 설계
겹침 기간과 책임 구분
기존 업체와 최소 4~8주를 겹치게 두는 것이 안전합니다. 기간 중 장애 대응의 1차 책임자와 에스컬레이션 경로를 주차별로 명시해야 "서로 상대가 하는 줄 알았다"는 상황을 막을 수 있습니다.
인수 측 검증 시나리오
인수 측이 직접 빌드하고 스테이징·운영에 배포하기백업에서 DB를 복구해 보기모의 장애(배치 실패, 인증서 만료)를 인수 측이 단독으로 처리하기이 세 가지를 통과하기 전에는 기존 업체의 계약을 종료하지 않는 것이 원칙입니다.
계약으로 막아야 할 것들
종료 시 자료 인도 의무: 인도 대상 목록, 형식, 기한을 계약서 부속서로 명시합니다.협조 조항: 종료 후 일정 기간(예: 30일) 질의 응답 협조와 그 비용 기준을 정해 둡니다.소스 소유권: 산출물 저작권이 발주사에 귀속되는지 확인합니다.접근 권한 회수 절차: 계정 목록을 기준으로 권한 회수와 비밀번호·키 교체 완료 확인서를 받습니다.이관 이후 90일 로드맵
1~30일, 모니터링 구축: 가용성·에러율·배치 성공 여부 알림을 먼저 갖춰 "모르는 장애"를 없앱니다.31~60일, 긴급 기술부채 정리: 만료 임박 인증서, 지원 종료된 런타임, 백업 누락처럼 사고로 직결되는 항목부터 처리합니다.61~90일, 개선 백로그 운영: 요청과 개선 과제를 우선순위 백로그로 관리하고 월간 리포트로 공유합니다.POLYGLOTSOFT와 함께하는 SM 전환
POLYGLOTSOFT의 SM 구독은 기존 업체에서 넘어오는 시스템도 인수합니다. 자산 체크리스트 점검, 로그·코드 기반 역분석, 직접 배포·복구 검증까지 거친 뒤 운영을 시작하며, 월 9만원 Basic SM부터 전담 PM이 배정되는 Pro SM까지 규모에 맞게 선택하실 수 있습니다. 업체 교체를 검토 중이시라면 문의하기나 카카오톡 채널로 현재 시스템 상황을 알려 주십시오. 인수인계 위험 요소부터 함께 짚어 드리겠습니다.
