디프리케이션

기능을 없애는 가장 빠른 방법은 그냥 지우는 것입니다. 실제로 그렇게 하던 시절이 있었고, 그 방식의 비용은 만든 쪽이 아니라 쓰던 쪽이 냈습니다.

장면은 대개 이렇게 나타났습니다. 어느 화요일 아침에 고객사 개발자가 자기 시스템이 멈춰 있는 걸 발견합니다. 밤사이 바뀐 것은 자기 코드가 아니라 연동해 쓰던 API, 그러니까 프로그램끼리 데이터를 주고받기로 약속해 둔 창구였습니다. 없어진 항목 하나 때문에 주문 동기화가 열두 시간째 멈춰 있고, 담당자는 공지를 받은 기억이 없습니다. 이렇게 기존 사용자의 코드를 깨뜨리는 변경을 브레이킹 체인지라고 부릅니다.

문제는 만든 쪽에도 남습니다. 이런 일을 한 번 겪은 고객은 다음 공지를 믿지 않고, 그다음부터는 사소한 수정에도 문의가 붙습니다. 그렇다고 아무것도 없애지 않으면 쓰는 사람이 열 명뿐인 기능을 몇 년째 돌보게 됩니다.

디프리케이션은 그 사이에 구간을 하나 만든 것입니다. 없앨 것을 없애되 없애기 전에 알리고 옮길 시간을 주는 구간이고, 지우는 행위와 알리는 행위를 같은 날에 하지 않는다는 합의입니다.

이 구간에서 기능은 그대로 돌아갑니다. 달라지는 것은 안내와 새 사용자의 진입로 둘뿐입니다. 이미 쓰던 사람은 어제와 똑같이 쓰고, 오늘 처음 온 사람은 이 기능을 만나지 못합니다.

밖에서 보이는 표시는 네 자리에 붙습니다.

1. 도움말 문서 맨 위에 더는 권하지 않는다는 문구와 대체 수단이 붙습니다. 검색으로 이 문서에 처음 들어온 사람이 본문을 읽기 전에 알아야 해서 맨 위에 둡니다.
2. 제품 화면에 안내 띠가 뜹니다. 이 기능을 쓰고 있는 사용자에게만 보이게 하고, 언제까지 쓸 수 있는지와 무엇으로 옮기면 되는지를 한 줄로 적습니다.
3. API 라면 응답에 경고가 실립니다. 화면을 보지 않고 프로그램으로만 부르는 사용자에게는 이 경로밖에 없습니다. 응답 헤더에 경고와 종료 예정일을 실어 두면 고객사 개발자가 로그에서 봅니다.
4. 새로 켜지는 경로가 막힙니다. 설정 목록에서 빼고, 새로 만든 계정에는 아예 보이지 않게 합니다.

네 번째가 빠지면 이 구간은 끝나지 않습니다. 오늘도 이 기능을 새로 켜는 사람이 생긴다면 남은 사용자 수는 줄지 않고, 종료 날짜는 계속 밀립니다. 그래서 안내를 붙이는 일과 새 진입을 막는 일은 한 쌍으로 움직입니다.

구간의 목적도 여기서 나옵니다. 예의를 차리는 시간이 아니라 남은 사용자 수를 0에 가깝게 줄이는 작업 기간입니다. 공지 직후, 중간, 종료 2주 전에 남은 사용자 수를 세고 줄어드는 속도가 예상보다 느리면 그 자리에서 이유를 찾습니다. 대체 수단이 불편해서인지, 안내가 안 보여서인지, 옮기다 막혀서인지에 따라 할 일이 다릅니다.

다음 구간은 지원 종료입니다. 넘어가려면 네 가지가 갖춰져 있어야 합니다.

1. 대체 수단이 이미 돌아가고 있어야 합니다. 순서가 뒤집히는 일이 잦은 자리입니다. 종료를 먼저 공지하고 대체 수단은 두 달 뒤에 내놓으면, 그 두 달 동안 들어오는 문의에 답할 말이 없습니다.
2. 마이그레이션 가이드가 나와 있어야 합니다. 어떤 버튼을 어느 순서로 누르는지, 옮긴 뒤 무엇을 보면 제대로 됐는지가 화면 단위로 적힌 문서입니다. 옮기는 동안 잃는 것이 있으면 그것도 적습니다.
3. 계약을 먼저 확인해야 합니다. 기업 고객과 고쳐 주는 시간까지 약속해 둔 SLA가 걸려 있으면, 계약 만료일보다 앞에 종료일을 두는 순간 약속을 어기는 것이 됩니다.
4. 남은 사용자에게 개별 연락이 끝나 있어야 합니다. 같은 문구를 단체 메일로 받는 것과 담당자에게 먼저 듣는 것은 다른 일입니다.

날짜 간격은 미리 정해 두는 편이 낫습니다. 페이지덱은 공지와 디프리케이션을 같은 날 시작하고, 60일 뒤에 지원 종료일을 두고, 다시 30일 뒤에 코드를 지웁니다. 기업 고객이 걸린 기능이면 90일과 60일로 늘립니다. 간격을 길게 잡는 이유는 천천히 옮기라는 뜻이 아니라, 옮기다 막힌 사람이 문의하고 답을 받을 시간을 확보하려는 것입니다.

"이번 판부터 이 항목은 디프리케이션입니다. 아직 동작하지만 새 연동에는 쓰지 마세요."

지금은 돌아가되 여기에 새로 기대지 말라는 안내입니다.

"디프리케이션 공지는 나갔는데 아직 신규 생성이 열려 있어요. 그것부터 막아야 합니다."

안내만으로는 사용자 수가 줄지 않는다는 지적입니다.

"남은 사용자가 여섯 곳인데 그중 두 곳이 기업 고객이라 종료일을 90일로 잡았습니다."

계약과 남은 사용자 구성을 보고 일정을 정했다는 뜻입니다.

페이지덱에서 오래된 문서 내보내기 기능을 접기로 한 자리가 전형적이었습니다. 지현이 사용량과 유지 비용을 놓고 일몰을 결정했고, 태오가 지난 90일간 이 기능을 쓴 워크스페이스 목록을 뽑았습니다. 마흔한 곳이었고 그중 셋이 기업 고객이었습니다.

공지 일주일 전에 수아가 기업 고객 세 곳에 먼저 연락했습니다. 공지 당일에 현우가 릴리스 노트와 도움말을 고쳤고, 태오는 같은 날 새 워크스페이스에서 이 기능이 보이지 않게 막았습니다. 30일 뒤에 세어 보니 남은 곳이 열아홉이었고, 절반은 대체 기능에 표 형식 내보내기가 없어 옮기지 못한 상태였습니다. 그 기능을 먼저 만들고 종료일을 2주 미뤘습니다.

디프리케이션을 이미 못 쓰게 된 상태로 읽는 경우가 가장 흔합니다. 공지 문구가 종료를 말하니 오늘부터 막힌 것처럼 들립니다. 실제로는 이 구간의 정의 자체가 기능이 그대로 돌아가는 상태입니다. 오해를 그대로 두면 양쪽에서 사고가 납니다. 쓰던 쪽은 급한 일정을 미루고 이전 작업부터 하느라 다른 일을 밀어내고, 만든 쪽은 공지를 냈으니 끝났다고 여겨 실제로 지우는 날 마흔 곳의 연동이 한꺼번에 멈춥니다.

공지를 내는 일이 이 구간의 전부라고 보는 것도 자주 보입니다. 알려야 한다는 원칙만 기억하면 공지가 목표처럼 보입니다. 하지만 공지는 시작 신호이고 구간의 내용은 남은 사용자를 옮기는 작업입니다. 공지만 내고 새 진입을 막지 않으면 사용자 수는 오히려 늘고, 6개월 뒤에 종료일을 다시 미루는 회의를 하게 됩니다. 한 번 미룬 날짜는 다음에도 믿기지 않아서, 그다음 공지에는 아무도 움직이지 않습니다.