개발사와 연락이 끊긴 시스템, 첫 주에 무엇부터 해야 합니까?

첫 주의 원칙 — 고치지 말고 지킵니다

개발사와 연락이 끊기면 그동안 미뤄 둔 개선 요청부터 처리하고 싶어지기 쉽습니다. 그러나 구조를 모르는 상태에서 코드를 고치면 원래 멀쩡하던 부분까지 멈출 수 있습니다. 첫 주의 목표는 지금 돌아가는 상태를 그대로 지키는 것이고, 개선은 이어받을 수 있는지 판단한 뒤의 일입니다.

1. 만료 일정 확인도메인·인증서·결제 수단·외부 구독의 만료일을 모읍니다
2. 열쇠 확보클라우드·도메인·저장소의 관리자 계정과 복구 경로를 회사 쪽으로 옮깁니다
3. 백업 복원 확인백업이 실제로 되살아나는지 별도 환경에서 시험합니다
4. 변경 동결과 기록배포를 멈추고 지금의 구성과 설정을 기록해 둡니다
5. 이어받기 판단 준비손에 있는 것과 없는 것의 목록을 만듭니다

날짜가 정해진 위험부터

운영 중인 시스템이 예고 없이 멈추는 원인 가운데 미리 알 수 있는 것이 날짜가 정해진 일입니다. 도메인 갱신, 인증서 갱신, 결제 카드 만료처럼 개발사 담당자가 챙기던 일이 아무에게도 넘어오지 않으면, 정해진 날 시스템이 멈춥니다.

도메인의 만료일과 등록기관은 ICANN의 등록 정보 조회 도구 같은 공개 서비스로 확인할 수 있고, .kr 같은 국가 도메인은 해당 국가 도메인 관리 기관의 조회 서비스를 이용합니다.

만료일을 모았다면 각 항목의 갱신 담당자와 결제 수단을 회사 쪽으로 바꿉니다. 자동 갱신이 켜져 있어도 등록된 카드가 개발사 법인 카드이거나 이미 만료된 카드라면 갱신은 실패합니다. 갱신 알림 메일이 개발사 직원 주소로 가고 있다면 회사 공용 주소로 바꾸는 것도 같은 날 처리할 일입니다.

인증서는 특히 급합니다. 브라우저 제조사와 인증기관이 모인 CA/Browser Forum은 2025년 4월 공개 TLS 인증서의 최대 유효기간을 단계적으로 줄이는 안을 통과시켰고, 2026년 3월 15일부터 발급되는 인증서에는 이미 200일 한도가 적용되고 있습니다.

유효기간이 짧아질수록 사람이 손으로 갱신하던 시스템은 더 자주 멈출 위험이 있습니다. 갱신이 자동으로 이뤄지도록 설정돼 있는지, 그 자동 갱신이 개발사 서버나 계정에 의존하고 있지는 않은지를 먼저 확인하십시오. 외부에서 확인할 수 있는 인증서 상태는 웹사이트 기술 · 보안 상태 확인으로도 볼 수 있습니다.

열쇠 확보 — 관리자 권한이 누구 손에 있는가

다음으로 확인할 것은 관리자 계정이 회사 손에 있는가입니다. 클라우드 계정, 도메인 등록기관 계정, DNS 관리 계정, 코드 저장소, 배포 도구, 앱스토어 계정을 차례로 확인합니다.

가장 무거운 것은 클라우드의 최상위 계정입니다. AWS는 루트 사용자의 이메일로 개인이 아니라 회사가 관리하는 그룹 메일 주소를 쓰도록 권고하는데, 담당자가 회사를 떠나도 계정 연락이 끊기지 않게 하기 위해서입니다. 또한 모든 MFA 장치를 잃었을 때는 계정에 등록된 이메일과 전화번호가 모두 살아 있어야 복구할 수 있다고 안내합니다. 루트 계정의 이메일, 전화번호, MFA 장치가 개발사 직원 개인에게 묶여 있다면 이것을 회사 쪽으로 옮기는 일이 첫 주의 최우선 과제입니다.

명의가 개발사로 되어 있는 계정은 각 서비스의 소유권 확인 절차를 거쳐야 옮길 수 있습니다. 계약서, 세금계산서, 결제 내역처럼 회사가 실제 사용자이자 비용 부담자임을 보여 주는 자료를 미리 모아 두면 절차가 빨라집니다.

백업은 「있는지」가 아니라 「복원되는지」

백업이 설정돼 있다는 화면만으로는 충분하지 않습니다. 백업이 어느 계정에 저장되는지, 얼마나 자주 만들어지는지, 그리고 실제로 별도 환경에 되살려 쓸 수 있는지를 확인해야 합니다. 백업이 개발사 계정에 저장되고 있다면 연락이 끊긴 순간 백업도 함께 손에서 떠난 것입니다. 이 경우에는 회사 명의의 저장소에 새 백업을 즉시 한 벌 더 만들어 두는 것이 우선입니다. 백업이 있어도 복구가 안 되는 원인은 백업은 있는데 왜 복구가 안 되는가에서 더 자세히 다룹니다.

변경 동결과 기록, 그리고 다음 단계

첫 주에는 누구도 배포하지 않도록 정하고, 지금의 구성을 기록해 둡니다. 서버와 데이터베이스 목록, 주요 설정 화면, 매달 청구되는 서비스 항목을 모아 두면, 청구서가 곧 어떤 자원이 돌고 있는지 보여 주는 지도 역할을 합니다.

이때 개발사 직원의 계정을 서둘러 삭제하지 않도록 주의하십시오. 그 계정으로 예약 작업이나 외부 연동이 돌고 있을 수 있어, 삭제하는 순간 아무도 원인을 모르는 장애가 생길 수 있습니다. 비밀번호와 MFA를 회사가 통제하도록 바꾸고, 계정이 어디에 쓰이는지 확인한 뒤에 정리하는 순서가 안전합니다.

이렇게 모은 목록이 다음 단계의 출발점입니다. 첫 주가 끝날 때 손에 남아야 하는 것은 고친 기능이 아니라 정리된 목록입니다. 소스코드, 실행 환경, 데이터, 배포 경로, 계정 명의, 문서 가운데 무엇이 손에 있고 무엇이 비어 있는지 정리되면, 지금 시스템을 이어받아 유지할지 다시 만들지를 근거를 가지고 판단할 수 있습니다. 그 목록을 들고 새 업체와 이야기를 시작하면 견적과 일정도 추측이 아니라 확인된 사실 위에서 논의할 수 있습니다. 빌드업웍스가 이어받기를 검토할 때도 코드와 함께 계정 명의와 만료 일정을 먼저 확인합니다.

참고 자료

• CA/Browser Forum — Ballot SC-081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods
• CA/Browser Forum — TLS Baseline Requirements
• ICANN — Registration Data Lookup Tool
• AWS IAM User Guide — Root user best practices for your AWS account