런치 체크리스트

출시일에 빠진 것이 드러나는 일은 늘 같은 모양으로 벌어집니다. 만드는 쪽은 코드가 올라간 시점을 출시로 보고, 파는 쪽과 응대하는 쪽은 고객에게서 처음 소식을 듣습니다. 기능은 나갔는데 그 기능을 설명할 수 있는 사람이 회사 안에 개발자 두 명뿐인 상태가 됩니다.

페이지덱도 권한 관리 기능을 내보내면서 같은 일을 겪었습니다. 공개 당일 오후부터 "관리자만 편집하게 어떻게 바꾸나요" 라는 문의가 들어왔는데, 받는 사람은 그런 기능이 나갔다는 것조차 몰랐습니다. 도움말 문서는 비어 있었고 가격표에는 이 기능이 어느 플랜부터인지 적혀 있지 않았습니다. 기능 자체는 잘 만들어졌는데 그날 남은 것은 사과 메일 40통이었습니다.

문제는 누가 게을러서가 아니라 해야 할 일이 여러 팀에 흩어져 있고 그 목록이 아무 데도 적혀 있지 않은 데서 옵니다. 각자 자기 몫은 했는데 아무도 전체를 본 사람이 없는 상태입니다. 체크리스트는 그 흩어진 항목을 한 장에 모아 두고, 출시 전에 빠진 것을 찾는 자리를 만듭니다.

항목은 보통 다섯 묶음으로 나뉩니다. 묶음마다 확인하는 질문이 다릅니다.

1. 되돌릴 방법. 문제가 생겼을 때 어떻게 끄는지를 먼저 적습니다. 피처 플래그로 기능만 꺼지는지, 안 되면 롤백으로 이전 버전까지 돌려야 하는지, 그 판단을 누가 내리는지까지 씁니다. 피처 플래그는 코드를 배포한 채 기능만 켜고 끄는 스위치입니다.
2. 사용자에게 보이는 글. 이번에 무엇이 바뀌었는지 알리는 릴리스 노트, 쓰는 법을 설명하는 도움말 문서, 화면 안의 안내 문구가 여기 들어갑니다. 문서는 공개 시점에 이미 올라가 있어야 합니다. 기능을 본 사람이 검색해서 아무것도 못 찾으면 그 길은 곧장 문의로 이어집니다.
3. 값과 권한. 어느 플랜부터 쓸 수 있는지, 가격표가 그렇게 바뀌었는지, 기존 계약 고객에게는 어떻게 적용되는지를 확인합니다. 무료 플랜에서 쓰던 것이 유료로 올라가는 경우는 사전 안내까지 이 묶음에 포함됩니다.
4. 내부 준비. 영업과 고객 응대 팀이 이 기능을 설명할 수 있는 상태인지를 봅니다. 내부 인에이블먼트가 이 항목을 맡고, 흔히 나올 질문과 답을 묶은 문답 한 장이 최소 기준입니다.
5. 대외 알림과 판정. 소개 페이지와 메일과 게시물을 언제 내보낼지는 런치 플랜이 날짜별로 정합니다. 여기에 더해 이번 출시가 잘된 것인지 어떻게 판정할지를 미리 적습니다. 2주 안에 전체 팀의 20퍼센트가 한 번이라도 켜 보면 성공, 처럼 숫자와 기한이 들어가야 나중에 다툼이 없습니다.

항목마다 담당자 이름과 언제까지인지를 붙입니다. 이름 없는 항목은 아무도 하지 않습니다. 목록의 길이는 런치 티어가 정합니다. 가장 높은 등급이면 다섯 묶음을 다 채우고, 문구 한 줄을 고치는 출시라면 1번과 2번만 남깁니다.

목록을 소유하는 사람은 그 출시를 책임지는 프로덕트 매니저나 제품 마케터 한 명입니다. 항목을 전부 그 사람이 하는 것은 아닙니다. 되돌릴 방법은 개발자가, 도움말은 테크니컬 라이터나 기획자가, 응대 문답은 고객 응대 팀이 채웁니다. 소유자가 하는 일은 채우는 것이 아니라 비어 있는 칸을 찾아 물어보는 것입니다.

읽는 쪽은 출시에 관여하는 모두입니다. 실제로 펼쳐지는 자리는 공개 하루나 이틀 전에 잡는 짧은 점검 회의입니다. 여기서 소유자가 항목을 위에서 아래로 읽고, 담당자가 됐다 안 됐다를 답합니다. 안 된 항목이 나오면 그 자리에서 두 가지 중 하나를 정합니다. 날짜를 미루거나, 그 항목 없이 나가되 누가 어떻게 메울지를 적습니다.

전부 채워야만 나갈 수 있는 문서로 만들면 목록은 금방 형식이 됩니다. 판정하는 사람은 목록이 아니라 소유자입니다. 다만 되돌릴 방법 한 칸만은 예외로 두는 팀이 많습니다. 나머지 항목이 비면 나간 뒤에 메울 수 있지만, 끄는 방법이 없는 채로 나간 기능은 문제가 생겼을 때 메울 방법 자체가 없기 때문입니다.

"런치 체크리스트에서 도움말 문서랑 응대 문답이 아직 비어 있어요."

공개 전에 두 항목의 담당자가 답해야 한다는 알림입니다.

"이번 건은 티어 3이니까 릴리스 노트만 쓰고 나머지는 건너뜁니다."

출시 규모가 작으니 목록을 줄여서 쓰겠다는 선언입니다.

"되돌리는 방법이 안 적혀 있으면 오늘은 못 나갑니다."

다른 항목과 달리 이 칸은 비운 채 내보낼 수 없다는 뜻입니다.

페이지덱은 권한 관리 건 이후로 이 목록을 만들었습니다. 지현이 소유자를 맡고, 공개 전날 15분짜리 점검 회의를 잡습니다. 다음 분기의 어느 출시에서는 태오가 피처 플래그는 걸었지만 끄는 권한이 개발자에게만 있다고 답했고, 밤에 문제가 생기면 대기 중인 사람이 못 끈다는 점이 그 자리에서 드러나 공개를 하루 미뤘습니다.

같은 회의에서 수아가 이번 기능은 상위 플랜 전용인데 영업 자료에는 모든 플랜에서 쓸 수 있다고 적혀 있다는 점을 짚었습니다. 그대로 나갔으면 무료 플랜 고객이 안내를 보고 기능을 찾다가 문의를 넣었을 것이고, 응대하는 쪽은 잘못 쓴 자료와 실제 동작 사이에서 매번 사과를 했을 겁니다. 코드로는 드러나지 않고 테스트로도 안 걸리는 종류의 구멍입니다. 목록이 잡아 내는 것은 대체로 이런 것들입니다.

목록이 길수록 안전하다고 읽는 경우가 가장 많습니다. 빠뜨린 것이 사고를 냈으니 항목을 더 넣자는 반응이 자연스럽게 나옵니다. 그런데 문구 한 줄 고치는 출시에도 20개짜리 목록을 채우게 하면 사람들은 두 달 만에 목록을 열고 전부 체크만 하고 닫습니다. 그렇게 되면 진짜 큰 출시에서도 같은 손놀림이 나오고, 목록은 사고를 막는 대신 사고가 났을 때 누가 체크했는지를 따지는 자료가 됩니다.

품질 보증과 같은 것으로 보는 오해도 흔합니다. 둘 다 내보내기 전에 하는 확인이라 겹쳐 보입니다. 품질 보증은 만든 것이 의도대로 동작하는지를 봅니다. 체크리스트는 그 바깥을 봅니다. 기능이 완벽하게 동작해도 가격표가 그대로면, 문서가 없으면, 응대할 사람이 모르면 출시는 실패합니다. 하나로 뭉치면 테스트가 끝났다는 이유로 나머지 네 묶음이 통째로 생략됩니다.