마이그레이션 가이드

기능을 없애는 쪽에서는 결정이 어려운 일이고 알리는 것이 마지막 절차처럼 느껴집니다. 그래서 공지가 이렇게 나가곤 했습니다. "기존 문서 내보내기 기능은 3월 31일자로 종료됩니다. 새로운 내보내기 기능을 이용해 주세요."

읽는 쪽 사정은 다릅니다. 그 기능을 쓰던 사람은 3년 동안 매달 같은 순서로 같은 버튼을 눌러 왔고, 그 결과물을 회계팀에 넘기거나 사내 다른 시스템에 올리고 있었습니다. 공지 한 줄이 답해 주지 않는 질문이 그대로 남습니다. 새 기능은 어디에 있는가, 지금 설정해 둔 자동 발송은 그대로 살아 있는가, 파일 형식이 바뀌면 회계팀 쪽 서식도 고쳐야 하는가, 지난 3년치 기록은 새 쪽에서도 보이는가.

페이지덱에서 이 질문이 한꺼번에 돌아온 적이 있습니다. 공지가 나간 다음 주에 수아가 받은 전화 가운데 절반이 같은 말로 시작했습니다. "바꾸라고는 하는데 뭘 어떻게 하라는 건지 모르겠어요." 답할 문서가 없으니 수아가 한 건씩 화면을 공유하며 짚어 주었고, 같은 설명을 서른 번 반복한 뒤에야 그 내용을 문서로 만들자는 말이 나왔습니다.

마이그레이션 가이드는 그 서른 번을 한 번으로 줄이는 문서입니다. 공지가 무엇이 언제 끝나는지를 알린다면, 이 문서는 그래서 지금 무엇을 하면 되는지를 답합니다.

한 문서에 여섯 가지가 들어갑니다. 빠진 항목이 있으면 그 항목이 그대로 문의가 되어 돌아옵니다.

1. 무엇이 언제 끝나는지 — 기능 이름과 날짜를 맨 위에 둡니다. 더는 권하지 않는다고 알리는 디프리케이션 시점, 고장을 고쳐 주지 않는 지원 종료 시점, 실제로 사라지는 날을 따로 적습니다. 셋을 하나로 뭉뚱그리면 읽는 사람이 언제까지 여유가 있는지 계산하지 못합니다.
2. 대체 수단 대응표 — 옛 기능의 항목 하나하나가 새 기능의 무엇에 해당하는지 짝을 지어 보여 줍니다. 예약 발송이 새 쪽에서는 자동화 규칙이라는 다른 이름으로 있다면, 그 사실은 표에 있어야지 본문 설명에 섞여 있으면 안 됩니다.
3. 옮기는 절차 — 어떤 화면에서 어떤 버튼을 어느 순서로 누르는지를 번호로 적습니다. 설명이 아니라 절차입니다. 화면 이름이 실제 화면과 글자까지 같아야 하고, 중간에 관리자 권한이 필요한 단계가 있으면 그 사실을 앞머리가 아니라 그 단계에 적습니다. 앞에서 한 번 알려 준 조건은 여섯 단계를 내려오는 동안 잊힙니다.
4. 옮긴 뒤 확인 방법 — 무엇이 보이면 제대로 된 것인지 적습니다. 목록에 지난달 기록이 그대로 보이고 담당자 이름이 유지돼 있으면 성공이라는 식입니다. 이 항목이 없으면 사용자는 옮긴 뒤에도 확신하지 못해 옛 기능을 종료 직전까지 함께 씁니다.
5. 잃는 것 — 옮기면서 사라지거나 달라지는 것을 먼저 적습니다. 옛 댓글의 작성 시각이 새 형식에서는 분 단위까지만 남는다면 그대로 씁니다. 옮긴 뒤에 문의로 알게 되는 쪽보다 미리 알고 결정하는 쪽이 낫습니다.
6. 막혔을 때 연락처 — 어디로 물어보면 되는지와 언제까지 답을 받을 수 있는지를 적습니다. 고객과 계약으로 약속한 서비스 수준인 SLA가 걸린 고객이면 그쪽 창구를 따로 안내합니다.

초안은 기능을 없애기로 정한 사람이 씁니다. 페이지덱에서는 지현이 1번과 2번을 먼저 채웁니다. 무엇이 언제 끝나고 무엇으로 대체되는지는 결정한 사람만 정확히 알기 때문입니다. 3번과 4번은 태오가 실제 화면을 눌러 보며 채우고, 문장을 다듬고 도움말과 릴리스 노트에 연결하는 일은 현우가 맡습니다. 기업 고객이 걸려 있으면 공지 전에 수아가 한 번 읽고, 자기 고객이 막힐 지점을 짚어 3번에 단계를 더합니다.

읽는 쪽은 셋으로 갈립니다.

1. 기능을 직접 쓰던 사람 — 절차만 필요합니다. 배경 설명이 위에 길게 붙어 있으면 3번까지 내려오지 못하고 문의를 넣습니다.
2. 계정을 관리하는 사람 — 팀 전체의 설정을 옮겨야 해서 잃는 것과 날짜를 먼저 봅니다. 사내에 다시 공지할 사람이기도 해서, 이 문서의 문장을 그대로 복사해 쓸 수 있게 써 두면 일이 한 번에 끝납니다.
3. 고객 지원 담당자 — 문의가 들어왔을 때 열어 보는 대본으로 씁니다. 접수된 문의 한 건인 지원 티켓에 링크를 붙여 보내는 일이 많아서, 문단마다 따로 가리킬 수 있는 주소가 있으면 답변 시간이 줄어듭니다.

"가이드 없이 공지부터 나가면 안 됩니다. 문의 받을 말이 없어요."

대체 경로와 절차가 정리되기 전에는 일몰을 시작하지 말자는 제동입니다.

"가이드 3번에 관리자 권한 얘기가 빠졌어요. 여기서 다들 막혀요."

절차가 실제 화면과 어긋나 사용자가 같은 지점에서 멈춘다는 지적입니다.

"기업 고객에게는 가이드 링크만 보내지 말고 담당자가 먼저 연락합시다."

같은 문서라도 전달 방식에 따라 받아들이는 쪽 반응이 달라진다는 뜻입니다.

페이지덱이 옛 내보내기 기능을 닫기로 한 분기에 이 문서가 먼저 만들어졌습니다. 지현이 초안을 올리고 태오가 절차를 따라 해 보다가 두 단계를 더했고, 수아가 읽고 회계팀에 넘기는 서식이 달라진다는 사실이 빠져 있다고 짚었습니다. 그 한 줄이 5번 항목에 들어가면서, 실제 공지가 나갔을 때 들어온 문의는 지난번의 3분의 1이었습니다.

공지와 가이드를 같은 문서로 보는 오해가 가장 많습니다. 둘 다 종료를 알리는 글이니 하나로 합치고 싶어집니다. 하지만 둘은 읽는 시점이 다릅니다. 공지는 한 번 읽히고 지나가는 글이라 짧아야 하고, 가이드는 실제로 옮기는 날 다시 열어 옆에 띄워 두는 글이라 길어도 됩니다. 둘을 합치면 공지가 길어져 끝까지 안 읽히고, 정작 옮기는 날 다시 찾을 주소가 메일함 어딘가로 사라집니다. 공지에는 날짜와 링크만 남기고 나머지를 전부 가이드로 넘기는 편이 양쪽 다 제 일을 합니다.

이름 때문에 데이터베이스의 마이그레이션과 같은 일로 오해하기도 합니다. 그쪽은 저장 구조를 새 형태로 옮기는 기술 작업이고, 이 문서는 사람이 다른 기능으로 옮겨 가도록 돕는 안내입니다. 같은 낱말을 쓰지만 옮기는 주체가 데이터냐 사용자냐가 다릅니다.