제품 일몰

소프트웨어를 만드는 쪽에는 내놓는 일을 가리키는 말이 여럿 있습니다. 만든 것을 한 번 내보내는 릴리스가 있고, 전체에 한꺼번에 열지 않고 1퍼센트부터 범위를 넓히는 점진적 출시가 있고, 언제 누구에게 어떤 경로로 알리고 팔지까지 묶은 고 투 마켓이 있습니다. 반대 방향에는 오랫동안 이름이 없었습니다. 기능을 끄는 일은 회의록에 "그거 이번에 뺐어요" 한 줄로 남았고, 그 한 줄을 누가 언제 어떻게 하는지 정해 둔 곳은 없었습니다.

절차가 없으니 사고는 두 방향으로 났습니다. 하나는 너무 빨리 끄는 쪽입니다. 페이지덱에서 태오가 서버 비용을 줄이려고 오래된 PDF 변환 기능을 내린 적이 있습니다. 월 사용자가 40명이라 영향이 없다고 본 겁니다. 다음 날 아침 수아에게 전화가 왔습니다. 그 40명 안에 기업 고객 두 곳이 있었고, 그중 한 곳은 매주 월요일 임원 보고서를 그 기능으로 만들고 있었습니다. 숫자가 작다는 것과 아무도 쓰지 않는다는 것은 다른 말입니다. 남은 40명은 대체로 그 기능에 가장 깊이 기대던 사람들이라, 없어졌을 때 가장 크게 곤란해지는 쪽도 그들입니다.

다른 하나는 아예 끄지 못하는 쪽입니다. 기능 하나를 붙여 두는 값은 눈에 잘 띄지 않습니다. 화면에 메뉴 한 줄, 코드에 조건 분기 하나, 배포할 때마다 확인할 항목 하나입니다. 따로 놓고 보면 어느 것도 문제가 아니라서 아무도 없애자는 말을 먼저 꺼내지 않습니다. 그렇게 3년이 지나면 설정 화면에 항목이 스물두 개 늘어서고, 새로 들어온 개발자는 그중 무엇이 살아 있는 기능인지 물어봐야 알게 됩니다. 페이지덱에서는 아무도 켜지 않는 옛 알림 설정 하나 때문에 알림 코드를 고칠 때마다 두 벌을 고쳤고, 그 값을 아무도 계산해 본 적이 없었습니다. 값이 드러나는 곳은 엉뚱한 자리입니다. 새 기능을 만드는 데 3주가 걸릴 일이 옛 기능과 부딪히지 않는지 확인하느라 4주가 되고, 신규 사용자가 설정 화면에서 헤매다 문의를 남기고, 그 문의를 받은 사람이 이 항목이 아직 살아 있는지 개발팀에 물어봅니다.

제품 일몰은 이 두 실패를 한 절차로 묶은 말입니다. 거두는 일을 내보내는 일과 같은 무게로 다룹니다. 끝나는 날짜가 있고, 그 전에 나가는 알림이 있고, 대신 쓸 것이 있고, 사용자가 옮겨 갈 시간이 사이에 있습니다. 예고 없는 출시가 사고이듯 예고 없는 종료도 사고라는 전제가 이 말 안에 들어 있습니다. 제품 수명주기에서 도입·성장·성숙 다음에 오는 쇠퇴 구간이 저절로 흘러가는 대신 사람이 날짜를 정해 실행하는 일이 되는 지점이기도 합니다.

아래에는 용어 셋이 있고 성격이 둘로 갈립니다. 둘은 시간 축 위에 찍는 점이고, 하나는 그 점 사이에서 사용자에게 건네는 것입니다. 앞의 둘은 순서가 정해져 있어 뒤엣것이 앞엣것보다 먼저 올 수 없습니다.

단계는 종료로 가는 길에 박아 두는 표지 둘입니다.

1. 디프리케이션 — 곧 없앨 예정이라고 공개적으로 알리고 새로 쓰는 것을 말리는 상태입니다. 기능은 그대로 돌아갑니다. 달라지는 것은 안내입니다. 도움말 맨 위에 더는 권하지 않는다는 문구가 붙고, 설정 화면에 띠 형태의 안내가 뜨고, 개발자가 프로그램으로 불러 쓰는 창구라면 부를 때마다 응답에 경고가 실립니다. 이 단계의 목적은 숫자를 줄이는 것입니다. 오늘도 이 기능을 새로 켜는 사람이 생긴다면 종료 날짜는 영원히 오지 않습니다. 그래서 안내를 붙이는 일과 새로 켜지는 경로를 막는 일이 한 쌍으로 움직입니다. 이미 쓰던 사람에게는 그대로 두되 새 사용자에게는 목록에서 아예 보이지 않게 하는 식입니다.
2. 지원 종료 — 더는 지원하지 않는다고 못 박은 시점입니다. 여기서 두 가지가 한꺼번에 끝납니다. 고장이 나도 고치지 않고, 문의가 와도 되살려 주지 않습니다. 기능이 실제로 사라지는 날짜와 같을 수도 있고 뒤에 올 수도 있습니다. 기업 고객과 고쳐 주는 시간까지 계약서에 적어 둔 경우, 그 계약이 끝나는 날보다 앞에 이 시점을 두면 약속을 어기는 것이 됩니다. 고객과 계약으로 약속한 서비스 수준을 SLA라고 부르는데, 지원 종료 날짜는 이 문서를 먼저 확인하고 잡습니다. 이 시점을 따로 이름 붙여 두는 이유는 안과 밖의 기준을 맞추기 위해서입니다. 날짜가 적혀 있지 않으면 고객은 고장 신고를 계속 넣고, 받는 쪽은 매번 어디까지 봐 줄지를 그 자리에서 판단합니다. 담당자에 따라 답이 달라지고, 한 번 고쳐 준 사례가 생기면 그 기능은 사실상 지원이 살아 있는 상태로 돌아갑니다.

두 표지 뒤에 하나가 더 있습니다. 코드와 데이터를 실제로 지우는 날입니다. 여기에는 따로 이름이 붙어 있지 않지만 날짜는 따로 잡습니다. 지원을 끊은 뒤에도 몇 주는 켜 둔 채로 두는 편이 안전하기 때문입니다. 미처 옮기지 못한 고객이 그 사이에 자료를 꺼내 갈 수 있고, 무언가 잘못됐을 때 되돌릴 여지가 남습니다.

지원은 이 길을 건너는 사람에게 건네는 다리입니다. 마이그레이션 가이드는 지금 쓰던 것을 무엇으로 바꾸고 어떤 순서로 옮기는지 적은 문서입니다. 대체 수단이 없으면 이 문서를 쓸 수 없고, 쓸 수 없으면 일몰을 시작할 수 없습니다. 실무에서 순서가 뒤집히는 일이 잦은 자리이기도 합니다. 종료 공지부터 내보내 놓고 대체 수단은 두 달 뒤에 나오는 식으로 진행하면, 그 두 달 동안 들어오는 문의에 답할 말이 없습니다. 좋은 가이드는 설명이 아니라 절차입니다. 지금 상태를 어떻게 확인하는지, 어떤 버튼을 어느 순서로 누르는지, 옮긴 뒤에 무엇을 보면 제대로 됐는지가 화면 단위로 적혀 있어야 합니다. 옮기는 동안 잃는 것이 있다면 그것도 적습니다. 옛 댓글의 작성 시각이 새 형식에서는 분 단위까지만 남는다는 사실을 미리 적어 두는 쪽이, 옮긴 뒤에 문의로 알게 되는 쪽보다 낫습니다.

셋을 시간 위에 늘어놓으면 하나의 일정표가 됩니다. 페이지덱이 쓰는 기본 간격은 이렇습니다. 공지와 디프리케이션을 같은 날 시작하고, 60일 뒤에 지원 종료일을 두고, 다시 30일 뒤에 코드를 지웁니다. 기업 고객이 걸린 기능이면 90일과 60일로 늘립니다. 간격을 길게 잡는 이유는 사용자가 천천히 옮기라는 뜻이 아니라, 옮기다 막힌 사람이 문의할 시간을 확보하려는 것입니다. 일정표에는 확인 시점도 함께 박습니다. 공지 직후, 중간, 종료 2주 전에 남은 사용자 수를 세고, 줄어드는 속도가 예상보다 느리면 그 자리에서 이유를 찾습니다.

들어오는 사람과 시점도 정해져 있습니다. 시작은 지현이 사용량과 유지 비용을 놓고 일몰 여부를 정하는 자리입니다. 결정이 나면 태오가 남은 사용자 목록을 뽑고 대체 경로를 만듭니다. 공지가 나가기 일주일 전에 수아가 기업 고객에게 따로 연락합니다. 같은 문구를 단체 메일로 받는 것과 담당자에게 먼저 듣는 것은 다른 일이기 때문입니다. 공지 당일에는 현우가 릴리스 노트와 도움말을 함께 고칩니다. 계약에 걸린 기능이면 규원이 마지막으로 날짜를 승인합니다.

"이거 일몰 태우죠. 월 사용자 마흔 명인데 스프린트마다 손이 들어가요."

쓰는 사람 수보다 유지하는 값이 커졌으니 끝내자는 제안입니다.

"디프리케이션 공지는 나갔는데 신규 사용이 계속 붙어요. 가입 화면에서 이 항목부터 빼야 합니다."

알리는 것만으로는 유입이 멈추지 않으니 켜지는 경로를 막자는 말입니다. 공지를 읽지 않은 사람에게 안내문은 없는 것과 같습니다.

"지원 종료일을 계약 만료 뒤로 잡아 주세요. 그 전에 끊으면 우리가 약속을 어기는 겁니다."

기술 일정보다 계약 조건이 날짜를 먼저 정한다는 지적입니다. 계약이 걸린 기능은 개발팀이 날짜를 혼자 정할 수 없습니다.

페이지덱이 지난 분기에 거둔 것은 옛 댓글 기능이었습니다. 새 댓글 기능이 나온 뒤로 2년 동안 두 벌이 함께 돌아가고 있었고, 옛 쪽을 쓰는 문서는 전체의 3퍼센트였습니다. 지현이 일몰을 걸면서 잡은 날짜는 90일이었고, 태오가 뽑은 목록에는 계정 210개가 있었습니다. 그중 열한 곳이 기업 고객이라 수아가 한 곳씩 통화했습니다.

공지 60일이 지난 시점에 남은 계정은 여전히 130개였습니다. 마이그레이션 가이드가 있고 공지 메일도 세 번 나갔는데도 움직이지 않은 겁니다. 태오가 확인해 보니 옛 댓글을 새 형식으로 옮기는 버튼이 문서 편집 권한이 있는 사람에게만 보였고, 그 130개 계정의 담당자 대부분은 읽기 권한만 갖고 있었습니다. 버튼 위치를 고치자 2주 만에 남은 계정이 스물두 개로 줄었습니다. 마지막까지 남은 계정에는 규원의 승인을 받아 개별 연락을 돌렸고, 종료일은 그대로 지켰습니다. 이 일에서 팀이 챙긴 것은 종료 자체가 아니라 중간 점검이었습니다. 60일 시점에 남은 숫자를 세어 보지 않았다면 권한 문제는 종료 전날에야 드러났을 것이고, 그때는 날짜를 미루는 것 말고 선택지가 없었습니다.

일몰을 실패한 기능에만 하는 일로 읽는 경우가 가장 많습니다. 없앤다는 말이 잘 안 됐다는 뜻으로 들리니 그렇게 읽힙니다. 실제로는 잘 쓰이던 기능도 거둡니다. 같은 일을 더 잘하는 것이 새로 나와 둘을 함께 둘 이유가 없어졌을 때, 세 제품에 흩어져 있던 기능을 하나로 합칠 때, 그 기능이 딛고 선 바깥 서비스가 문을 닫을 때가 그렇습니다. 이 오해를 그대로 두면 일몰 논의가 책임 추궁이 됩니다. 누가 만들었는지부터 이야기가 시작되고, 만든 사람은 방어하는 쪽에 서게 되며, 그러면 아무도 자기 기능을 후보로 올리지 않습니다. 그 조직에서는 죽은 기능이 계속 쌓입니다. 거두는 결정을 만든 사람의 성적표와 떼어 놓아야 후보가 올라옵니다.

두 번째는 기간만 길게 잡으면 안전하다고 보는 것입니다. 90일을 주면 90일에 걸쳐 나눠 옮길 것 같지만 사람은 마감이 가까워야 움직입니다. 페이지덱의 옛 댓글 기능도 60일이 지난 시점에 남은 계정이 절반을 넘었습니다. 기간의 쓸모는 옮길 시간을 주는 데 있지 않고, 옮기다 막힌 사람이 물어보고 답을 받을 시간을 확보하는 데 있습니다. 그래서 기간보다 중요한 것은 중간에 남은 숫자를 확인하는 일입니다. 확인하지 않으면 종료 전날에야 130개가 남아 있다는 사실을 알게 되고, 그 자리에서는 날짜를 미루는 것 말고 할 수 있는 일이 없습니다. 한 번 미룬 종료일은 다음에도 미룰 수 있다고 읽히기 때문에 그다음 일몰부터는 공지가 힘을 잃습니다. 사용자 쪽에서 보면 합리적인 판단입니다. 지난번에도 미뤘으니 이번에도 미루겠거니 하고 옮기지 않는 쪽이 손해가 적기 때문입니다. 날짜를 지키는 조직에서만 공지가 실제로 사람을 움직입니다.