EOS

EOS란 무엇인가

EOS(End of Service, 서비스 종료)는 제품·솔루션·플랫폼에 대한 공급자의 공식 지원이 끝나는 시점을 가리킨다. 이 시점 이후에는 기능 개선은 물론 보안 패치와 결함 수정, 기술 문의 대응이 모두 중단되거나 제한된다.

비슷한 용어인 EOL(End of Life, 수명 종료)이 판매·생산 자체의 종료를 뜻한다면, EOS는 이미 사용 중인 고객에 대한 지원의 종료라는 점에서 운영 단계와 더 직접적으로 맞닿아 있다. 공급자는 통상 EOS 전에 지원 축소 단계를 예고하므로, 운영 조직은 그 일정을 미리 파악해 대비해야 한다.

지원 종료가 운영에 남기는 위험

EOS가 위험한 이유는 종료된 그 순간이 아니라 그 이후의 시간에 있다. 보안 취약점이 새로 발견되어도 패치가 제공되지 않으므로 시스템은 시간이 지날수록 노출 위험이 누적된다.

결함이 생겨도 공급자의 수정 의무가 사라져 운영 조직이 우회책을 스스로 떠안아야 한다. 또한 EOS 제품에 의존하는 다른 구성요소까지 함께 낡아 가면서 호환성 문제가 연쇄적으로 번질 수 있다.

표면적으로는 잘 돌아가는 시스템이라도 지원이 끊긴 순간부터 그 안정성은 빌려 쓰는 시간일 뿐이다.

전환 계획과 마이그레이션

EOS에 대응하는 정석은 막연한 연장이 아니라 후속 버전·대체 제품으로의 전환 계획을 미리 세우는 것이다. 현재 시스템이 종료 대상 솔루션에 어디까지 의존하는지 의존성 지도를 그리고, 데이터·설정·연동 인터페이스를 어떻게 이관할지 단계별로 정의해야 한다.

전환에는 검증과 병행 운영 기간이 필요하므로, EOS 시점 직전에 시작하면 거의 항상 늦는다. 마이그레이션 일정은 단순 교체 작업이 아니라 하나의 작은 프로젝트로 다루어 범위·일정·공수를 산정하는 편이 안전하다.

전환을 미루는 결정 자체가 곧 위험을 쌓는 결정임을 의사결정자에게 명확히 전달해야 한다.

운영 문서와 책임의 인계

EOS는 운영 단계에서 다루어지는 사건이므로 운영자 매뉴얼과 긴밀하게 연결된다. 종료 대상 구성요소가 무엇이고, 그 종료가 어떤 장애 시나리오를 새로 만들며, 비상 시 누구에게 에스컬레이션하는지가 운영 문서에 반영되어야 한다.

외부 솔루션의 지원이 끊긴 뒤에는 내부 운영 조직이 사실상 1차 대응을 떠안게 되므로, 그동안 공급자에게 의존하던 절차를 자체 절차로 다시 써야 한다. 계약상 하자담보책임기간과 EOS 시점이 어긋나 있는지도 점검 대상이다.

책임 경계가 흐릿한 상태로 종료를 맞으면 장애가 발생했을 때 대응 주체를 두고 혼선이 생긴다.

생애주기 관점에서 본 종료

EOS를 사고가 아니라 예정된 생애주기 단계로 바라보는 관점이 중요하다. ITIL 4 같은 서비스 관리 체계가 서비스를 기획·전환·운영·개선의 흐름으로 다루듯, 모든 서비스에는 시작과 마찬가지로 정해진 끝이 있다.

종료를 미리 설계에 포함해 두면 데이터 보존 기간·고객 통지 절차·라이선스 정리·자산 회수까지 질서 있게 진행할 수 있다. 반대로 종료를 외면하면 어느 날 갑자기 지원 중단 통보를 받고 황급히 대응하는 상황으로 내몰린다.

잘 관리되는 조직은 도입 시점에 이미 그 서비스의 퇴역 시나리오를 함께 그려 둔다.

고객 통지와 데이터 정리

공급자 입장에서 EOS를 선언할 때는 고객에게 충분한 사전 통지와 이행 경로를 함께 제공해야 한다. 종료 일정, 종료 이후 제공되지 않는 항목, 권장 대체안, 데이터 추출·이전 방법을 명확히 안내해야 고객이 자신의 운영을 준비할 수 있다.

동시에 종료되는 서비스가 보관하던 데이터는 법적 보존 의무와 개인정보 처리 기준에 따라 이관·파기 절차를 밟아야 한다. 단순히 시스템을 끄는 것으로 끝나는 것이 아니라, 데이터의 사후 처리까지 마쳐야 종료가 완결된다.

깔끔한 종료 절차는 그 자체로 공급자의 신뢰를 좌우하는 마지막 인상이 된다.