출시 후에도 누군가는 애플리케이션과 데이터, 사용 중인 서비스를 돌봐야 합니다. 어떤 일이 필요한지는 사람들이 무엇에 의존하는지에 따라 달라집니다. 콘텐츠 중심의 웹사이트와 고객 주문을 받는 애플리케이션은 필요한 점검과 복구 계획이 다릅니다.
유지보수를 맡기기 전에 무엇을 살펴야 하는지, 각각 누가 책임지는지, 어떤 근거 자료를 받게 되는지 정해 두세요. 제가 함께 짚어 볼 질문들을 소개합니다.
호스팅, 유지보수, 신규 개발 구분하기
호스팅은 소프트웨어가 실행되는 인프라를 제공합니다. 서비스에 따라 보안, 인증서, 백업의 일부를 관리해 주기도 합니다. 하지만 그렇다고 누군가가 결제, 로그인, 알림이 여전히 잘 작동하는지 확인하고 있다는 뜻은 아닙니다.
유지보수는 현재 제품이 계속 운영되도록 하기 위해 합의한 작업입니다. 신규 개발은 제품이 하는 일을 바꿉니다. 관리 계약에 둘 다를 위한 시간을 포함할 수는 있지만, 리디자인, 새로운 결제 흐름, 큰 규모의 연동은 별도의 범위가 필요합니다. 작업을 시작하기 전에 그 경계를 문서로 정해 두세요.
첫 인계 이후에 어떤 지원이 포함되는지, 기간은 얼마인지, 무엇을 다루는지도 확인하세요. 지원이 어디서 끝나는지 알면 이후의 작업을 계획하기가 쉬워집니다.
의존성은 지원 기간 안에 두고 업데이트는 확인하기
애플리케이션은 시간이 지나며 바뀌는 라이브러리, 프레임워크, 외부 서비스에 의존합니다. 보안 패치와 지원 종료 시점에는 주의를 기울여야 합니다. 업데이트는 우리 애플리케이션에 미칠 영향을 평가하고, 중요한 사용 흐름에서 확인한 뒤에 운영 환경에 반영해야 합니다.
주기는 위험도와 제품에 따라 정해집니다. 우리 제품에 해당하는 긴급한 보안 문제라면 매달 정해진 업데이트 일정까지 기다려서는 안 됩니다. 이런 문제를 어떻게 보고하고 처리할지, 계약 범위를 벗어나는 작업까지 포함해 합의해 두세요.
무엇이 백업되고 어떻게 복원하는지 알아 두기
저장소에 있는 코드는 복구에 필요한 것의 일부일 뿐입니다. 제품은 고객 기록, 업로드된 파일, 서비스 설정에도 의존합니다. 무엇을 백업하는지, 얼마나 자주 하는지, 사본을 얼마나 보관하는지, 누가 복원할 수 있는지 물어보세요.
백업 주기는 어느 정도의 데이터 손실까지 감당할 수 있는지에 맞춰 정하세요. 예를 들어 마지막으로 성공한 백업이 자정이고 오후 5시에 데이터베이스가 고장 났다면, 그 백업만 복원해서는 그날의 변경 사항이 빠지게 됩니다. 주문을 받는 제품과 콘텐츠가 매주 바뀌는 사이트는 적합한 복구 방식이 다를 수 있습니다.
이와 별도로, 복원하는 동안 제품이 얼마나 멈춰 있어도 되는지도 합의하세요. 데이터를 얼마나 되살릴 수 있는지와, 되살리는 데 시간이 얼마나 걸리는지는 서로 다른 질문입니다.
백업 성공 알림만으로는 애플리케이션을 복원할 수 있다는 증거가 되지 않습니다. 적절한 별도 환경에서 복구를 시험하고 그 절차를 기록해 두세요.NCSC의 백업 가이드도 백업에 중요한 데이터가 들어 있는지, 복원 방법을 알고 있는지 확인하라고 권합니다.
고객에게 필요한 것을 모니터링하기
가동 상태 점검은 페이지가 응답한다는 것만 알려 줍니다. 이메일이 발송되지 않거나, 백그라운드 작업이 멈췄거나, 고객이 구매를 마치지 못하는 문제는 드러나지 않을 수 있습니다. 제품에 어떤 점검이 중요한지, 장애 알림을 어디로 보낼지 정하세요.
애플리케이션과 주요 서비스의 가용성.
로그인, 결제, 예약처럼 핵심적인 흐름에서 발생하는 오류.
실패한 백그라운드 작업, 알림, 외부 서비스 연동.
도메인 갱신, 인증서 상태, 저장 공간 한도, 서비스 사용량.
모든 알림에는 받는 사람과 합의된 대응 방식이 있어야 합니다. 누가 어느 시간대에 대응하는지, 긴급한 문제는 어떻게 알리는지, 그 사람이 대응할 수 없을 때는 누구에게 연락하는지 정하세요. 월 단위 계약에 24시간 장애 대응이 포함되는 것은 아니므로, 필요하다면 명시적으로 합의해야 합니다.
대응 약속이 무엇을 뜻하는지도 확인하세요. 문제를 접수하는 것, 조사를 시작하는 것, 서비스를 복구하는 것은 서로 다른 단계입니다. 어느 단계까지 약속하는지, 그다음에는 어떻게 되는지 문구에서 분명히 알 수 있어야 합니다.
제품이 바뀌는 데 맞춰 성능과 접근 권한 점검하기
데이터는 늘어나고, 새 기능이 추가되며, 실제 사용자는 테스트 계정과 다르게 행동합니다. 문제의 징후가 보이면 느린 페이지와 비용이 큰 작업을 살펴보세요. 먼저 사용자에게 미치는 영향을 보고 원인을 조사해야 하며, 습관적으로 인프라를 늘리는 것은 피해야 합니다.
사람이 합류하거나 떠날 때마다 계정 접근 권한을 점검하세요. 소유자와 갱신 정보를 최신으로 유지하고, 중요한 서비스가 어디에 있는지 문서로 남겨 두세요. 팀의 누구도 복구할 수 없는, 잊힌 계정 하나에 제품이 의존해서는 안 됩니다.
이해할 수 있는 유지보수 계획 요청하기
지속적인 작업을 맡기기 전에 다음을 물어보세요.
어떤 애플리케이션, 서비스, 환경이 포함되나요?
실제로 어떤 점검과 정기 작업이 이루어지나요?
백업, 복원 테스트, 각종 갱신, 서비스 요금은 누가 담당하나요?
대응 시간은 언제이고, 긴급한 문제는 어떻게 알리면 되나요?
수정이나 개선을 위한 시간은 어떻게 쓰이며, 별도 견적이 필요한 일은 무엇인가요?
완료한 작업과 남은 위험에 대해 어떤 기록을 받게 되나요?
협업을 끝내면 접근 권한과 문서는 어떻게 되나요?
완료한 작업과 남은 과제를 문서로 받아 보세요. 예를 들어 유지보수 보고는 다음과 같을 수 있습니다.
완료: 애플리케이션의 의존성을 업데이트했고, 릴리스 전에 스테이징 환경에서 로그인, 비밀번호 재설정, 주요 예약 흐름을 확인했습니다.
복구 점검: 최신 데이터베이스 백업을 별도 환경에 복원하고 일부 레코드를 표본으로 확인했습니다. 업로드된 파일은 이번 복원 테스트에 아직 포함하지 않았습니다.
결정 필요: 저장 공간 사용량이 늘고 있습니다. 변경하기 전에 검토하실 수 있도록 선택지와 예상 영향을 정리해 두었습니다.
이는 요청해야 할 상세 수준의 예시일 뿐, 특정한 월간 일정을 약속하는 것은 아닙니다. 유지보수 계획에는 제품에 어떤 점검을 얼마나 자주 하는지가 적혀 있어야 합니다.
지금 가진 제품에서 시작하기
공개된 웹사이트를 먼저 살펴보고 싶다면 제가 만든웹사이트 건강 검진이나사이트 전체 점검을 사용해 보세요. 조사해 볼 만한 문제를 찾아 줄 수 있습니다. 다만 비공개 애플리케이션 코드를 살펴보거나, 백업과 고객 업무 흐름이 제대로 작동한다는 것을 증명할 수는 없습니다.
지속적인 도움이 필요하시다면제품에 대해 알려 주세요. 사용하는 서비스와 맡기고 싶은 범위도 함께 적어 주시면, 그에 맞춰 관리 계획을 정하거나 특정 개선 작업부터 범위를 잡을 수 있습니다.