트렐로로 버그를 관리하다 막히는 네 지점

트렐로로 버그를 받기 시작하면 처음엔 잘 굴러갑니다

칸반 보드에 할 일 / 진행중 / 완료 리스트를 만들고, 버그가 나오면 카드를 하나 만들어 올립니다. 스크린샷은 첨부하고, 담당자는 멤버 아바타를 붙이고, 급한 건 라벨을 빨갛게 답니다. 세팅에 5분도 안 걸리고, 팀원 누구나 설명 없이 씁니다.

버그가 하루에 몇 건이고 검수하는 사람이 만든 사람과 같다면, 사실 이걸로 충분합니다. 도구를 바꿀 이유가 없습니다.

문제는 프로젝트가 조금 커질 때입니다. 화면이 열 개를 넘고, 기획·개발·디자인이 한 버그를 나눠 처리하고, 고객사가 검수에 참여하기 시작하면, 같은 보드가 갑자기 답답해집니다. 어디서 막히는지 순서대로 짚어보겠습니다.

막히는 지점 1 · "완료"가 누구의 완료인지 모릅니다

카드 하나가 완료 리스트로 넘어갔습니다. 이게 무슨 뜻일까요?

• 개발자가 코드를 고쳤다는 뜻일 수도 있고
• 그 수정이 스테이징에 올라갔다는 뜻일 수도 있고
• 기획자가 확인까지 마쳤다는 뜻일 수도 있습니다

칸반의 리스트는 본질적으로 한 줄짜리 축입니다. 카드는 한 번에 한 리스트에만 있을 수 있으니까요. 그런데 실제 버그 수정은 최소 두 축으로 굴러갑니다. 작업이 끝났는가와 검수가 끝났는가는 다른 질문이고, 앞의 질문은 담당 파트마다 답이 다릅니다.

그래서 팀들이 리스트를 늘리기 시작합니다. 개발완료, 배포대기, 검수중, 반려… 리스트가 여덟 개가 되면 보드는 가로로 스크롤되고, 카드를 옮기는 일 자체가 업무가 됩니다.

buggle이 상태를 두 겹으로 나눠 둔 게 이 지점 때문입니다. 파트별 작업 상태(미수정 → 진행중 → 작업완료 → 배포/반영, 작업이 필요 없으면 사유를 적고 작업없음)가 먼저 굴러가고, 모든 파트가 끝나면 이슈 전체가 검수요청으로 올라가 확인완료 또는 재수정요청으로 갈립니다. 리스트를 늘리는 대신 축을 하나 더 준 셈입니다.

막히는 지점 2 · 한 카드에 담당자가 여럿이면 아무도 담당이 아닙니다

버그 하나에 기획 확인이 필요하고, 개발 수정이 필요하고, 디자인 시안 교체가 필요한 경우는 드물지 않습니다. 트렐로에서는 카드에 멤버 셋을 다 붙입니다.

그러면 이런 대화가 반복됩니다.

"이거 지금 누구 차례예요?" "저는 기획 확인만 하면 돼서 끝냈는데요" "저는 디자인 나와야 시작해요"

카드에는 세 사람이 붙어 있지만 지금 공이 누구에게 있는지는 카드 어디에도 적혀 있지 않습니다. 코멘트를 위에서 아래로 읽어야 알 수 있고, 코멘트가 스무 개면 아무도 안 읽습니다.

이슈를 파트로 쪼개면 각 파트가 자기 상태와 자기 담당자를 따로 갖습니다. 기획이 작업없음으로 빠지고 디자인이 배포/반영이면, 남은 건 개발 하나라는 게 목록에서 바로 보입니다. buggle에는 파트 사이 순서를 지정하는 핸드오프도 있는데, 이건 앞 파트가 안 끝나면 뒤 파트를 막는 방식이 아니라 순서를 표시하고 알림을 보내는 방식입니다. 실무에서 순서를 어겨야 하는 일이 자주 생기기 때문입니다.

막히는 지점 3 · "이 화면에서 몇 건 터졌나"를 못 셉니다

QA를 조금이라도 오래 하면 관심사가 개별 버그에서 화면으로 옮겨갑니다.

• 결제 화면에서만 이번 달에 일곱 건이 나왔다
• 로그인은 두 달째 조용하다
• 주문 목록은 고칠 때마다 다른 게 터진다

이건 "어느 화면이 불안정한가"라는 질문이고, 다음 회차에 어디를 더 볼지 정하는 근거가 됩니다. 트렐로에서 이걸 하려면 화면 이름을 라벨로 만들어야 하는데, 라벨은 개수와 색이 제한적이고 화면이 서른 개인 프로젝트에서는 금방 무너집니다. 카드 제목 앞에 [결제]처럼 접두어를 붙이는 팀도 많은데, 오타 한 번이면 집계에서 빠집니다.

buggle은 화면을 라벨이 아니라 별도 목록으로 관리합니다. 화면 코드와 메뉴 경로를 등록해 두고 이슈를 거기에 연결하면, 화면별 수정이력 보고서에서 화면 단위로 집계가 나옵니다.

막히는 지점 4 · 고객사를 부르려면 보드를 통째로 열어야 합니다

외주 프로젝트라면 언젠가 고객사가 "우리도 직접 보면 안 되나요"라고 합니다. 트렐로 보드에 초대하면 그 보드의 카드를 전부 봅니다. 내부용으로 적어둔 카드, 다른 고객사 이야기가 섞인 카드, "이건 우선순위 낮게 미루자" 같은 코멘트까지요.

그래서 보통 고객사용 보드를 따로 만들고, 사람이 손으로 옮겨 적습니다. 그 순간부터 같은 버그가 두 곳에 있고, 한쪽만 업데이트되는 일이 시작됩니다.

buggle의 게스트 초대는 범위를 프로젝트 또는 이슈 단위로 좁혀서 주고, 게스트는 회원가입 없이 들어옵니다. 옮겨 적을 필요가 없다는 게 핵심입니다.

그래서 트렐로를 버려야 하나요

아닙니다. 위 네 가지 중 어느 것도 겪지 않고 있다면 그대로 쓰는 게 맞습니다. 도구를 옮기는 비용은 늘 생각보다 크고, 트렐로는 "설명 없이 누구나 쓴다"는 아주 큰 장점을 갖고 있습니다.

옮길지 판단하는 기준은 단순합니다. 보드를 보는 것 말고, 보드를 관리하는 데 시간을 쓰고 있다면, 리스트를 계속 늘리고, 카드를 두 보드에 옮겨 적고, 지금 누구 차례인지 물어보고 있다면, 도구가 일을 만들고 있는 겁니다.

buggle은 무료로 시작할 수 있고, 얼리버드 기간에는 플랜과 무관하게 상위 플랜 한도로 쓸 수 있습니다. 트렐로에서 옮겨온다면 카드를 CSV로 내보내 업로드 마법사로 이관하는 방법부터 보시면 됩니다. 도구를 고르는 기준 전체를 보고 싶다면 소규모 외주팀의 버그 트래커 선택 기준도 같이 읽어보세요.