이슈

할 일이 말로 오가던 시절에는 요청이 도착한 자리마다 따로 쌓였습니다. 어떤 것은 회의에서 나왔고, 어떤 것은 메신저 대화 중간에 끼어 있었고, 어떤 것은 복도에서 지나가며 들은 한마디였습니다. 각자 자기 수첩에 적어 뒀으니 팀 전체가 지금 몇 건을 안고 있는지 아무도 답하지 못했습니다.

빠뜨리는 일이 생기는 건 당연했습니다. 더 성가신 건 같은 일을 두 사람이 따로 하고 있는 걸 배포 직전에 알게 되는 경우였습니다. 누가 맡았는지 적힌 자리가 없으니 둘 다 자기 일이라고 여겼습니다.

이 불편은 늘 같은 대화로 나타났습니다. "지난주에 말씀드린 그거 어떻게 됐어요?" 하고 물으면 "어떤 거였죠?" 라는 답이 돌아옵니다. 다시 설명하고 나면 "아, 그건 다른 분이 하기로 한 줄 알았어요" 가 이어집니다. 요청한 사람은 말했다고 기억하고 받은 사람은 그게 요청인 줄 몰랐던 겁니다.

이슈는 이 말들을 전부 한 군데로 모으려고 만든 기록 단위입니다. 종류를 가리지 않는다는 점이 핵심입니다. 새 기능을 만드는 일, 고장 난 것을 고치는 일, 고객이 보낸 요청을 모두 같은 형식으로 등록해 두면 흩어진 요청 대신 목록 하나가 남습니다. 그 목록은 훑을 수 있고 셀 수 있고 나눠 맡길 수 있습니다.

이슈 하나에 적는 것은 도구마다 이름이 달라도 대체로 다섯 가지입니다.

1. 제목 — 목록에서 한 줄로 보이는 부분입니다. "로그인 오류" 보다 "비밀번호 재설정 메일이 도착하지 않음" 처럼 무엇이 어떻게 안 되는지까지 적어야 목록을 훑는 사람이 열어 보지 않고 구분합니다.
2. 설명 — 왜 필요한지와 어떤 상황에서 생기는지를 적습니다. 버그라면 재현 순서와 기대한 동작과 실제 동작을 나란히 적습니다.
3. 완료 조건 — 무엇이 되면 이 건을 닫아도 되는지입니다. 이 줄이 없으면 만든 사람과 맡은 사람이 서로 다른 끝을 생각한 채 진행합니다.
4. 크기 추정 — 이 일이 얼마나 큰지입니다. 계획을 세울 때 이 값을 더해 다음 주기에 담을 양을 가늠합니다.
5. 연결 — 상위 항목이나 관련 항목과의 관계입니다. 에픽처럼 여러 건으로 쪼개지는 큰 덩어리 아래에 매달아 두면 그 덩어리가 몇 퍼센트 진행됐는지가 자동으로 나옵니다.

다섯 중 실제로 가장 자주 빠지는 것은 3번입니다. 제목과 설명은 등록하면서 자연히 적히지만, 완료 조건은 적는 사람이 상대도 당연히 알 것이라 여겨 건너뜁니다.

여기에 네 가지 값이 더 붙습니다. 워크플로 상태는 지금 어느 단계에 있는지, 담당자는 누가 맡았는지, 기한은 언제까지 끝내기로 했는지, 라벨은 나중에 모아 보려고 붙이는 꼬리표입니다. 이 값을 채우는 이유는 기록을 단정하게 만들려는 것이 아니라 나중에 물어볼 수 있게 하려는 것입니다. 담당자가 채워져 있어야 한 사람에게 몇 건이 몰렸는지 보이고, 라벨을 같은 기준으로 붙여야 기술 부채를 갚는 데 이번 분기에 며칠을 썼는지 셀 수 있습니다.

이슈는 개발팀만 쓰는 기록이 아닙니다. 고객 문의를 받은 세일즈, 화면에서 어긋난 부분을 발견한 디자이너, 회의에서 결정된 일을 정리하는 기획자가 모두 등록합니다. 등록 권한을 개발팀에만 열어 두면 나머지 사람들은 다시 메신저로 부탁하게 되고, 목록을 한 군데로 모으려던 목적이 무너집니다.

읽는 사람은 셋입니다. 맡은 사람은 무엇을 어디까지 해야 하는지 보려고 읽습니다. 계획을 세우는 사람은 남은 건수와 크기를 보려고 읽습니다. 그리고 반년 뒤의 누군가가 "이 기능 왜 이렇게 만들었지" 를 찾으려고 읽습니다. 세 번째 독자가 이슈를 기록으로 만듭니다.

쓰는 사람과 읽는 사람이 다르다는 점에서 요령이 나옵니다. 등록하는 순간에는 머릿속에 배경이 다 들어 있어 제목 한 줄이면 충분해 보이지만, 사흘 뒤에 그 줄만 보는 사람에게는 아무것도 남지 않습니다. "그거 수정" 이라고 적힌 이슈는 등록한 본인도 한 달 뒤에는 무엇인지 모릅니다. 어떤 화면에서 무엇을 눌렀을 때 무엇이 나왔고 대신 무엇이 나와야 하는지까지 적어 두면 세 줄이 되는데, 그 세 줄이 나중에 오가는 대화 대여섯 번을 없앱니다.

"이슈로 올려 주시면 이번 주 안에 볼게요."

말로 받은 요청을 기록으로 바꿔 달라는 뜻입니다. 거절이 아니라 순서를 매길 수 있게 해 달라는 요청입니다.

"이 이슈 완료 조건이 없어서 어디까지가 끝인지 모르겠어요."

등록한 사람에게 무엇이 되면 닫아도 되는지 적어 달라는 말입니다.

"그건 이미 올라와 있는 이슈랑 같은 건 같은데요."

같은 일이 두 건으로 등록됐으니 하나로 합치자는 제안입니다.

페이지덱에서는 수아가 고객 문의를 받아 이슈를 등록하는 일이 많습니다. 문의 내용을 그대로 옮기지 않고 재현 순서를 확인해 적는데, 이 한 단계가 있고 없고에 따라 태오가 원인을 찾는 시간이 반나절씩 갈립니다.

지현은 이 목록을 주 단위로 훑어 스프린트에 담을 것을 고릅니다. 이때 완료 조건이 비어 있는 이슈는 담지 않고 등록한 사람에게 되돌립니다. 냉정해 보이지만, 조건이 없는 채로 들어간 이슈가 주기 끝에 "이게 끝난 건가요" 로 되돌아오는 일을 몇 번 겪은 뒤에 생긴 규칙입니다.

이슈를 개발 작업 목록으로만 읽는 경우가 가장 많습니다. 도구를 개발팀이 먼저 쓰기 시작했고 화면도 코드 저장소 옆에 붙어 있으니 그렇게 보입니다. 하지만 이슈는 종류를 가리지 않는 기록 단위입니다. 문구 수정, 자료 정리, 외부 업체 문의 같은 것도 같은 목록에 들어가야 팀이 실제로 안고 있는 일의 양이 드러납니다. 개발 건만 올려 두면 목록은 깔끔한데 사람들은 늘 바쁜 상태가 됩니다.

잘게 쪼갤수록 좋다고 여기는 것도 흔합니다. 진행 상황이 자주 갱신되니 관리가 잘 되는 느낌을 줍니다. 그런데 30분짜리 일까지 전부 등록하면 등록하고 상태를 옮기는 데 드는 시간이 일하는 시간과 비슷해지고, 목록이 수백 건으로 불어나 정작 중요한 건이 묻힙니다. 기준은 대체로 한 사람이 며칠 안에 끝낼 크기입니다. 더 잘게 나눠야 하면 서브태스크로 이슈 안에 넣습니다.