지원 종료

없애기로 정한 기능도 한동안은 화면에 그대로 남아 있습니다. 옮겨 갈 시간을 주어야 하니 당연한 일인데, 그 사이에 고장이 나면 곤란해집니다. 고쳐 줘야 할까요. 어차피 두 달 뒤에 지울 기능인데요.

날짜가 정해져 있지 않으면 이 질문의 답이 매번 달라집니다. 접수된 문의 한 건을 지원 티켓이라고 부르는데, 없앨 예정인 기능의 티켓이 올라올 때마다 받는 사람이 그 자리에서 판단하게 됩니다. 한가한 날에는 고쳐 주고 바쁜 날에는 안내만 하고 넘어갑니다. 한 번 고쳐 준 사례가 생기면 그 기능은 사실상 지원이 살아 있는 상태로 돌아가고, 고객은 계속 신고를 넣습니다.

페이지덱에서도 같은 장면이 있었습니다. 수아가 옛 댓글 기능의 오류를 들고 오자 태오가 "그거 없앤다고 공지했는데요" 하고 답했고, 수아가 "그럼 지금은 고쳐 주는 거예요 마는 거예요" 하고 되물었습니다. 공지에는 언젠가 없앤다는 말만 있었지 언제부터 손을 떼는지가 적혀 있지 않았습니다. 지원 종료는 이 빈칸을 날짜 하나로 메우려고 따로 이름 붙인 시점입니다.

이 구간에 들어서면 기능은 그대로 돌아가는데 고치는 손만 빠집니다. 화면에서 사라지지 않고 버튼도 눌립니다. 달라지는 것은 그 뒤에 아무도 없다는 사실입니다.

한꺼번에 멈추는 것은 셋입니다.

1. 버그 수정. 새로 발견된 오류를 고치지 않습니다. 이미 예약해 둔 수정 작업이 있어도 이 날짜를 넘기면 취소하고, 취소했다는 사실을 신고한 사람에게 알립니다. 조용히 닫으면 고쳐 주기를 기다리는 사람이 생깁니다.
2. 보안 패치. 외부에서 알려 온 취약점도 막지 않습니다. 셋 중에 가장 조용히 문제가 되는 항목입니다. 버그는 사용자가 신고해 주지만 취약점은 아무도 신고하지 않은 채 몇 달을 흐르고, 기업 고객은 계약을 갱신할 때 보안 점검표를 들고 와 패치가 끊긴 기능이 있는지부터 봅니다.
3. 문의 응대. 티켓이 올라오면 고쳐 주는 대신 마이그레이션 가이드 링크로 안내합니다. 어디로 옮기고 어떤 순서로 하는지 적힌 문서입니다.

이 날짜가 기능이 실제로 사라지는 날과 같을 필요는 없습니다. 페이지덱은 둘 사이를 30일 벌려 둡니다. 공지와 함께 곧 없앤다는 안내를 붙이는 날이 1일이라면 지원 종료일은 61일, 코드를 지우는 날은 91일입니다. 지원을 끊은 뒤에도 한 달은 켜 둔다는 뜻입니다. 미처 옮기지 못한 고객이 그 사이에 자료를 꺼내 갈 수 있고, 무언가 잘못됐을 때 되돌릴 여지가 남습니다.

안내는 이 시점에 한 번 더 나갑니다. 도움말 문구와 릴리스 노트에 지원이 끝났다는 사실을 적고, 설정 화면의 안내 띠 문구도 "곧 종료됩니다" 에서 "종료되었습니다" 로 바꿉니다. 같은 자리에 같은 띠가 걸려 있으면 사용자는 어제와 오늘이 다른 줄 모릅니다.

다음 구간은 코드와 데이터를 실제로 지우는 날이고, 그리로 넘어가려면 세 가지를 확인합니다.

1. 남은 사용자 수. 지난 30일 안에 그 기능을 한 번이라도 쓴 계정을 셉니다. 45명 규모의 팀이 만든 기능이라도 남은 계정이 200개면 지우지 않습니다. 0에 가깝거나, 남은 계정이 전부 연락이 닿아 옮길 날짜를 잡아 둔 상태여야 합니다.
2. 계약상 약속. 고객과 계약으로 약속한 서비스 수준을 SLA라고 하는데, 거기에 고쳐 주는 시간까지 적어 둔 기업 고객이 있으면 그 계약이 끝나는 날보다 앞에 지원 종료일을 둘 수 없습니다. 계약이 내년 3월까지면 지우는 날은 그 뒤입니다.
3. 자료를 꺼낼 길. 사용자가 자기 데이터를 내려받는 기능이 살아 있고, 실제로 내려받아 열어 본 사람이 있어야 합니다. 내보내기 버튼이 있다는 것과 그 파일이 열린다는 것은 다른 이야기입니다. 태오가 직접 한 계정을 내려받아 열어 보는 것으로 이 항목을 확인합니다. 옛 댓글 100건이 그대로 들어 있고 작성 시각이 붙어 있으면 통과입니다.

셋 중 하나라도 걸리면 지우는 날을 미룹니다. 지원 종료일 자체를 미루지는 않습니다. 둘은 따로 움직이는 날짜이고, 앞의 날짜를 함께 미루면 지난 두 달 동안 옮긴 고객만 손해를 봅니다. 남은 사람을 기다리느라 이미 따라와 준 사람에게 약속을 바꾸는 셈이기 때문입니다.

"이 기능 지원 종료일이 11월 30일이라 그 뒤 문의는 고쳐 드리지 못하고 안내만 드립니다."

오늘부터는 고치는 작업을 잡지 않는다는 뜻입니다.

"EOL 날짜부터 잡고 공지 일정을 거꾸로 짜죠."

가장 늦은 날짜를 먼저 박고 60일을 빼서 공지일을 정하자는 제안입니다.

"엔터프라이즈 계약이 내년 3월까지라 EOL을 그 앞에 둘 수 없어요."

계약서가 날짜를 정하지 우리 일정이 정하는 게 아니라는 지적입니다.

페이지덱에서는 지현이 사용량과 유지 비용을 놓고 일몰을 결정하면 그 자리에서 지원 종료일부터 잡습니다. 그다음 태오가 남은 사용자 목록을 뽑고, 공지 일주일 전에 수아가 기업 고객에게 따로 연락합니다. 같은 문구를 단체 메일로 받는 것과 담당자에게 먼저 듣는 것은 다른 일이기 때문입니다. 계약이 걸린 기능이면 규원이 마지막으로 날짜를 승인합니다. 이 순서가 뒤집혀 공지가 먼저 나가면 수아의 연락은 해명이 되고, 고객은 통보를 받았다고 느낍니다.

지원 종료일을 기능이 사라지는 날로 읽는 경우가 가장 많습니다. 끝났다는 말이 붙어 있으니 그날 버튼이 없어질 것 같습니다. 하지만 이 날짜가 끊는 것은 사람의 손이지 기능이 아닙니다. 둘을 같은 날로 붙여 두면 옮기다 막힌 고객이 도움을 청할 곳도 자료를 꺼낼 곳도 한꺼번에 사라집니다. 종료 다음 날 환불 요구가 몰리는 사고는 대개 여기서 생깁니다.

공지를 냈으니 할 일이 끝났다고 보는 것도 흔합니다. 안내는 읽힐 때만 안내입니다. 공지 직후와 중간, 종료 2주 전에 남은 사용자 수를 세어 보면 줄어드는 속도가 눈에 보입니다. 예상보다 느리면 그 자리에서 이유를 찾습니다. 그대로 두면 종료일 당일에 쓰던 사람 수백 명이 한꺼번에 막히고, 그 문의는 하필 고쳐 주지 않기로 한 창구로 들어옵니다. 수아는 답할 말이 없고 태오는 이미 다른 일을 하고 있으니, 결국 지우기로 한 코드를 다시 열어 급히 고치는 자리로 되돌아갑니다.