라벨

일을 한 건씩 등록해 두는 도구를 쓰기 시작하면 목록은 금방 수백 줄이 됩니다. 등록은 쉬운데 찾는 일이 어려워집니다. 대표가 이번 분기에 결제 쪽에서 문제가 몇 건이나 있었느냐고 물으면, 답하려는 사람은 목록을 처음부터 끝까지 훑는 수밖에 없었습니다.

제목으로 검색하는 방법을 먼저 시도하게 되지만 오래가지 않습니다. 같은 결제 관련 건을 누구는 결제, 누구는 구독, 누구는 카드라고 적어 두기 때문입니다. 세 낱말을 다 검색해도 빌링이라고 적은 한 건이 빠집니다. 찾는 사람이 등록한 사람의 낱말 선택을 맞혀야 하는 구조라 정확히 셀 수가 없습니다.

폴더로 나누는 방법도 한계가 뚜렷합니다. 한 건은 폴더 하나에만 들어가는데, 모바일에서 생긴 결제 오류는 모바일 폴더에도 결제 폴더에도 들어가야 맞기 때문입니다. 어느 한쪽을 고르고 나면 다른 쪽에서 셀 때 그 건이 사라집니다.

라벨은 이 두 문제를 한꺼번에 풉니다. 팀이 쓸 낱말을 미리 정해 두고 그중에서만 고르게 해서 표기 흔들림을 없애고, 한 건에 여러 개를 붙일 수 있게 해서 한 건이 여러 기준에 동시에 속하는 상황을 그대로 담습니다.

붙이고, 걸러 보고, 세는 세 동작이 전부입니다.

1. 붙입니다. 한 건에 여러 개를 붙일 수 있습니다. 모바일에서 생긴 결제 오류에는 결제와 모바일을 같이 붙입니다. 워크플로 상태나 담당자처럼 하나만 고를 수 있는 값과 다른 점이 여기입니다. 상태는 진행 중이면서 동시에 완료일 수 없지만, 라벨은 겹쳐도 됩니다.
2. 걸러 봅니다. 결제 라벨만 켜면 목록이 그 건들로 줄고, 결제와 모바일을 함께 켜면 둘 다 붙은 건만 남습니다. 칸반 보드처럼 작업을 상태별 열에 늘어놓는 화면에서도 라벨로 걸러 두면 그 주제의 일이 어느 열에 몰려 있는지가 보입니다.
3. 셉니다. 지난 분기에 결제 라벨이 붙은 건이 몇 개였는지, 그중 몇 건이 아직 안 닫혔는지가 바로 나옵니다. 처음에 답하지 못했던 질문이 이 단계에서 답을 얻습니다.

세 동작이 굴러가려면 목록을 관리해야 합니다. 라벨은 아무나 아무 때나 새로 만들 수 있어서 방치하면 금세 불어납니다. 결제와 결제기능과 payment가 따로 생기면 셋 중 어느 것으로 세도 값이 틀립니다.

• 이름을 지을 때 앞에 갈래를 붙여 둡니다. area/결제, area/모바일, type/버그처럼 적으면 목록이 정렬되고 무엇이 같은 갈래인지 보입니다.
• 새로 만드는 사람을 정해 둡니다. 누구나 만들 수 있게 열어 두더라도, 분기에 한 번은 한 사람이 훑어 비슷한 것끼리 합칩니다.
• 총 개수를 서른 개 안쪽으로 둡니다. 그보다 많아지면 붙이는 사람이 목록에서 고르기를 포기하고 아무것도 붙이지 않습니다.

같은 장치가 여러 도구에서 이름만 조금씩 다르게 쓰입니다.

이슈 관리 도구가 가장 흔한 자리입니다. 이슈는 작업과 버그와 요청을 통칭하는 기록 단위인데, 여기에 어느 영역의 일인지와 어떤 종류의 일인지를 라벨로 적어 둡니다. 기술 부채, 그러니까 빨리 가려고 미뤄 둔 정리 작업에 라벨을 붙여 두면 이번 분기에 그 일에 며칠을 썼는지를 셀 수 있습니다. 이 숫자가 있어야 정리할 시간을 달라는 요청이 느낌이 아니라 근거가 됩니다.

고객 문의를 받는 창구도 같습니다. 접수된 티켓마다 문의 유형을 라벨로 남기면, 한 달 뒤에 어떤 문의가 가장 많았는지가 나옵니다. 그 목록의 위쪽 서너 개가 다음에 고칠 것의 순서가 됩니다.

코드 저장소에도 있습니다. 코드 변경 요청 하나하나에 붙여 어떤 변경인지 표시하고, 릴리스 노트를 만들 때 라벨별로 묶어 정리합니다.

자동화의 방아쇠로 쓰이기도 합니다. 긴급 라벨이 붙으면 담당 채널에 알림이 가고, 문서 라벨이 붙으면 에픽 아래로 자동 연결되는 식입니다. 이때부터 라벨은 분류를 넘어 동작을 일으키는 값이 되므로 아무나 붙이지 못하게 막아 두는 팀도 있습니다.

"이거 결제 라벨 좀 붙여 주세요. 분기말에 한 번에 모아 봐야 해서요."

지금 당장 필요한 게 아니라 나중에 세기 위해 붙여 달라는 요청입니다.

"라벨이 마흔 개가 넘는데 이번에 한 번 정리하죠."

종류가 너무 많아 아무도 일관되게 붙이지 않는 상태라는 뜻입니다.

"그건 라벨이 아니라 상태로 두는 게 맞아요."

한 건에 하나만 있어야 하는 값이라 겹쳐 붙는 자리에 두면 안 된다는 지적입니다.

페이지덱은 라벨을 세 갈래로만 씁니다. 어느 영역인지(area/), 어떤 종류인지(type/), 어디서 들어왔는지(from/)입니다. 태오가 버그를 등록하면서 area/결제와 type/버그를 붙이고, 수아가 고객에게 들은 요청을 옮겨 적으면 from/고객을 붙입니다.

분기가 끝나면 지현이 from/고객이 붙은 건을 모아 그중 몇 건이 실제로 반영됐는지 셉니다. 지난 분기에는 스물세 건 중 여섯 건이었습니다. 이 숫자 하나로 다음 분기 계획 회의의 대화가 달라졌습니다. 고객 요청을 더 받자가 아니라 받아 둔 것 중 무엇을 버릴지 먼저 정하자는 쪽으로 옮겨 갔습니다.

라벨을 많이 붙일수록 정리가 잘된 것이라고 생각하기 쉽습니다. 붙이는 데 드는 품이 거의 없으니 일단 달아 두자는 판단이 자연스럽습니다. 하지만 라벨의 쓸모는 걸러 봤을 때 남는 목록이 의미를 갖는 데서 나옵니다. 모든 건에 긴급이 붙어 있으면 긴급으로 거른 목록이 전체 목록과 같아지고, 그 라벨은 있으나 없으나 같은 값이 됩니다. 라벨 하나를 만들 때 이걸로 걸렀을 때 몇 건쯤 남기를 기대하는지 먼저 답해 보면 대부분 걸러집니다.

라벨로 우선순위나 기한을 대신하려는 것도 흔한 실수입니다. 중요, 매우중요, 진짜급함 같은 라벨이 늘어나는 팀이 있는데, 이런 값은 서로 순서가 있고 한 건에 하나만 있어야 하므로 라벨의 성질과 맞지 않습니다. 한 건에 중요와 매우중요가 같이 붙어도 도구는 막지 않고, 그 순간 어느 쪽이 맞는지 아무도 모르게 됩니다. 순서가 있는 값은 우선순위 항목에, 날짜는 기한에 적고 라벨은 순서가 없는 갈래에만 씁니다.