백로그를 비우는 가장 빠른 방법

결제·정산 팀의 백로그는 일반 백로그보다 위험하다

결제·정산·자동화를 운영하는 팀의 백로그는 일반 피처 개발팀 것과 성격이 다르다. 한 목록 안에 이질적인 항목이 뒤섞인다. PG사 정책 변경 대응, 정산 오차 수정 로직, 재처리 예외 케이스, 자동화 파이프라인 개선, 규정 준수 작업—이것들이 "사용자 온보딩 개선"이나 "대시보드 색상 조정"과 같은 목록에 공존한다. 처리하지 않으면 실제 금전적 손실이 생기는 항목과, 6개월 후에 해도 무방한 항목이 같은 줄에 나란히 있다는 뜻이다.

이 혼재 자체가 비용이다. 목록이 길어질수록 실제로 중요한 것이 묻힌다. HEDVION 팀이 이 문제를 직감한 건 정산 오차 관련 항목 하나가 2주 넘게 스프린트에 올라오지 못한 시점이었다. 목록이 70개를 넘어선 상황이었고, 매 스프린트 초반 우선순위 논의만 30분 넘게 걸렸다. 논의 시간이 길어지는 건 목록이 현실을 반영하지 못한다는 신호였다.

처리가 아니라 검토 — 90분으로 목록의 절반을 날린 방법

어느 시점에 접근을 바꿨다. 처리가 아니라 전체 검토를 먼저 했다. 한 세션, 약 90분. 70개 항목을 전부 빠르게 훑으면서 질문 하나만 던졌다. "이게 지금도 중요한가?" 삭제가 아니라 별도 아카이브로 이동하는 방식을 선택했기 때문에 팀의 심리적 저항이 낮았다. 지운 게 아니니 "나중에 꺼내올 수 있다"는 안전장치가 있었다.

결과는 예상보다 극적이었다. 70개 중 39개가 "지금은 아니다" 판정을 받았다. 패턴은 세 가지였다. 첫째, 환경이 바뀐 항목. 특정 PG사의 정산 API 변경 대응으로 적어뒀는데, 그 PG사를 연동에서 이미 제외한 것들. 둘째, 이미 다른 경로로 해결된 항목. "정산 합산 오차 수정"이라고 적어뒀는데, 업스트림 데이터 정합성을 고치면서 자동으로 없어진 케이스. 셋째, 처음부터 불분명했던 항목. "결제 플로우 개선"처럼 뭘 어떻게 해야 하는지 기준이 없어서 시작조차 못 했던 것들. 이 세 유형이 아카이브된 39개의 대부분을 차지했다. 실제로 처리해야 할 작업이었던 게 아니라, 목록에 있어서 있던 것들이었다.

버리는 기준: 결제 현장에서 실제로 작동하는 두 가지 필터

기준 없이 버리면 이후에 "그거 없앴어?" 소리가 반드시 나온다. 우리가 실제로 쓰는 기준은 두 가지다. 단순하지만, 결제·정산 컨텍스트에서 검증됐다.

첫 번째 필터: 마지막으로 누군가 이 항목을 입에 올린 게 언제인가. 2주 이상 아무도 언급하지 않은 항목은 아카이브 후보다. 이게 결제 현장에서 강력한 이유는 명확하다. 정말 긴급한 정산 문제는 발생 당일 누군가가 말을 꺼낸다. 특정 PG사에서 정산 금액이 맞지 않으면 하루도 버티지 못하고 슬랙에 올라온다. 반면 "언젠가 하면 좋을 것 같은" 자동화 개선 항목은 아무도 찾지 않는다. 침묵은 중요도의 신호다.

두 번째 필터: 이 항목이 없어졌을 때 누가, 얼마나 불편함을 느끼는가. 결제·정산 팀에서 이 질문이 중요한 이유는 두 종류의 항목이 항상 섞이기 때문이다. 실제 사용자(가맹점, 정산 수신자)가 기다리는 것과, 팀 내부에서 "있으면 좋겠다"고 생각하는 자동화 욕망. 경험상 후자가 전체 백로그의 30~40%를 차지한다. 이 구분이 없으면 내부 욕망이 실제 우선순위를 조용히 밀어낸다. "누가 기다리는가"라는 질문이 없으면 그 차이를 알아차리기 어렵다.

30개 상한선이 만들어낸 예상 밖의 변화

목록을 줄이는 것보다 더 효과적인 변화는 총 항목 수에 상한을 두는 것이었다. 우리는 30개로 정했다. 새 항목을 추가하려면 기존 항목을 아카이브로 보내거나 두 항목을 합쳐야 한다. 규칙은 단순하다. 효과는 단순하지 않았다.

첫 번째 변화는 추가 자체의 속도가 줄었다. 상한 도입 전 월 평균 12개 내외의 항목이 추가됐다. 도입 이후 5~6개로 떨어졌다. 처리 속도는 비슷한데 투입이 줄었으니 전체 부채가 줄어드는 건 당연한 결과였다. 두 번째 변화는 미팅 문화가 달라진 것이다. 이전에는 미팅에서 아이디어가 나오면 일단 적었다. 지금은 그 자리에서 "이게 현재 30개 안에 들어갈 만큼 중요한가"를 바로 논의한다. 적기 위한 논의가 아니라, 적을지 말지를 판단하는 논의다. 이 하나의 질문이 "일단 기록하고 나중에 판단하는" 관성을 끊었다.

트레이드오프: 우리가 잃은 것과 실제로 얻은 것

이 방식이 완벽하지 않다는 건 솔직히 말해야 한다. 30개 상한에 밀려 아카이브로 내려갔다가 한 달 후에 다시 꺼내야 했던 항목이 3~4개 있었다. 결제 연동 예외 처리 케이스였는데, 당시엔 트래픽이 낮아서 엣지 케이스처럼 보였다. 실사용이 늘면서 실제 장애로 이어졌다. 판단 실수였다. 아카이브에서 꺼내는 비용만의 문제가 아니라, 늦게 처리한 대가가 컸다.

그러나 반대 방향의 손실과 비교하면 셈은 달라진다. 70개짜리 목록에서 스프린트마다 우선순위를 정하는 데 쓰인 시간, 이미 죽은 항목에 논의 에너지를 쏟는 낭비, 신규 팀원이 맥락을 파악하는 데 걸리는 온보딩 비용 — 이것들의 합산이 아카이브에서 항목 3~4개를 꺼내오는 비용보다 크다. 그리고 판단이 잘못된 항목은 결국 잦은 언급을 통해 드러난다. 아카이브에서 꺼내는 일이 반복되는 항목은 처음부터 상한 안에 있었어야 했다는 사후 신호이고, 그 신호가 다음 판단을 개선한다.

지금 바로 써먹을 수 있는 실행 시사점

일반론이 아니라 결제·정산·자동화 운영 맥락에서 실제로 작동하는 것들만 적는다.

1. 오늘 백로그를 열고 "마지막 언급 날짜"를 확인하라. 항목마다 누군가 마지막으로 입에 올린 날짜를 태그로 달아라. 2주 이상 된 항목을 빨간색으로 표시하는 것만으로도 목록의 실제 상태가 보인다. Jira나 Linear에 Custom Field 하나면 된다.

2. "사용자가 기다리는 것" vs "우리가 하고 싶은 것" 두 열로 분류하라. 결제·정산 팀은 자동화 욕망이 강하다. 분류 기준이 없으면 내부 욕망이 사용자 니즈를 조용히 밀어낸다. 이 구분이 우선순위 논의의 출발점이 돼야 한다.

3. 상한을 정해라. 34인 팀이면 2025개, 57인 팀이면 3035개가 실용적이다. 숫자 자체보다 "추가하려면 하나를 빼야 한다"는 규칙이 핵심이다. 이 규칙 하나가 투입 속도를 통제한다.

4. 아카이브는 삭제가 아니다. 검색 가능한 별도 목록에 날짜와 이동 사유를 함께 보관하라. 아카이브에서 꺼내야 하는 일이 생기면, 왜 잘못 판단했는지 한 줄만 기록하라. 이것이 다음 검토 세션의 판단 기준을 실질적으로 개선한다.

5. 분기 1회, 90분 검토 세션을 캘린더에 반복 일정으로 넣어라. 처리가 아니라 검토다. 목적은 현재 목록이 현재 상황을 반영하고 있는지 확인하는 것이다. 이 세션 하나가 스프린트 몇 번치 논의 낭비를 막는다. PG 정책이 바뀌고, 연동 파트너가 교체되고, 자동화 범위가 달라지는 팀일수록 목록의 유통기한은 짧다. 6개월 전에 쓴 항목이 지금도 유효하다고 가정하는 것 자체가 리스크다.

— by mings