티켓 1건은 1건이 아니다 — 개발팀 지표에 무게를 붙인 이야기

개발팀 지표를 손봤다. 몇 달 돌려보고 나니 정리해둘 만해서 남긴다.

문제는 단위였다

기존에는 티켓을 전부 “1건"으로 셌다. 그런데 실제로 열어보면 이렇다.

• 어떤 티켓: 화면 파일 하나, 11줄
• 어떤 티켓: 14개 파일, 430줄, 4개 레이어

제목만 보면 둘 다 “문구 하나 고치는 일"처럼 보인다. 실제 작업량은 스무 배쯤 차이가 난다.

티켓 개수나 버그 개수로 재면 이 차이가 통째로 사라진다. 그러면 한 달 결산이 실제로 우리가 한 일과 어긋나기 시작한다. 무거운 작업을 한 사람이 저평가되는 것도 문제지만, 그보다 회사가 어디에 힘을 쓰고 있는지를 잘못 읽게 되는 게 더 큰 문제였다.

무게를 매기기로 했다

계산식은 단순하게 잡았다.

무게 = 변경 규모 × 레이어 수 × 위험도 × 협업 폭

레이어는 화면 / 서버 / 쿼리 / 테스트 / 인프라 다섯 개로 나눴다. 여기서 가장 중요한 건 레이어 항목이다. “버튼 하나 고치는 줄 알았는데 쿼리까지 건드린” 작업을 잡아내는 게 핵심이기 때문이다. 규모만 보면 줄 수가 비슷해 보이는 두 작업이, 레이어를 세면 확연히 갈린다.

실제로 붙은 무게는 이런 분포였다.

가장 가벼운 것과 무거운 것 사이가 마흔 배가 넘는다. 이게 전부 “1건"이었다.

세는 방식을 바꾸니 그림이 달라졌다

지난 2주치 PR 34건을 두 방식으로 세어봤다.

개수로 세면 쿼터 관련 UX 작업이 압도적 1등이다. 무게로 세면 보안 작업 한 건이 가벼운 UX 티켓 열일곱 건보다 무겁다.

어느 쪽이 그 2주 동안 실제로 벌어진 일에 가까운지는 팀 모두에게 명확했다. 개수로 세는 동안에는 운영·보안 작업이 계속 저평가되고 있었고, 그건 그 일을 하는 사람에게도 그 일을 계획하는 사람에게도 좋지 않았다.

이 지표를 평가에 쓰지 않기로 했다

여기가 제일 중요한 부분이라고 생각한다.

무게는 “이 목표에 우리 역량이 몇 % 갔나"를 계산하는 재료로만 쓴다. 정한 규칙은 세 가지다.

• 개인별로 합산하지 않는다
• 순위표를 만들지 않는다
• 부풀려도 이득이 없게 만든다

세 번째가 구조적인 장치다. 무게는 비율로만 쓰이기 때문에 내 티켓 무게가 두 배가 되면 분모도 같이 커진다. 부풀리기의 보상이 0이 되도록 설계를 잡았다.

측정 가능한 지표를 만들면 그 지표가 목표가 되어버린다는 건 오래된 이야기다. 무게를 개인 점수로 쓰는 순간 사람들은 무거운 티켓을 고르기 시작하고, 무겁게 보이도록 작업을 쪼개거나 합치기 시작한다. 그러면 지표는 정확해지는데 팀은 나빠진다. 그래서 처음부터 개인 단위로 내려가지 않게 못을 박았다.

배점에서 뺀 것들

무엇을 넣을지보다 무엇을 뺄지가 논의의 대부분이었다.

릴리즈 케이던스를 뺐다. 배포가 밀리는 이유는 기획 확정 지연이나 타 팀 대기인 경우가 많다. 그걸 개발팀 점수로 매기면 통제할 수 없는 걸로 평가받는 셈이다. 대신 밀린 주에는 사유를 한 줄 기록하는 것으로 바꿨다.

버그 개수를 뺐다. 다섯 명 규모에서는 한두 건 차이로 등급이 뒤집힌다. 그 정도 표본으로 등급을 나누는 건 측정이 아니라 그냥 운이다.

코드량·커밋 수·토큰 사용량은 배점 0%다. 특히 마지막 항목은 AI 도구를 도입하면서 한 번 짚고 넘어가야 했다. 많이 쓴 게 잘한 게 아니다.

대신 남긴 항목들은 대체로 “우리가 통제할 수 있고, 나빠지면 사용자가 아파하는 것"들이다. 데이터 파이프라인이 안 깨졌는지, 약속한 목표에 약속한 만큼 힘을 썼는지, 되돌리고 다시 한 일의 비중이 얼마인지, 결제·인증·스키마를 건드린 변경을 다른 사람이 한 번은 봤는지.

아직 어려운 것

“진짜 버그"를 가려내는 게 제일 어렵다.

우리는 revert나 hotfix 브랜치를 따로 쓰지 않아서, 코드 신호만으로는 버그 수정과 개선 작업이 구분되지 않는다. 지금은 주 1회 자동으로 분류를 돌리고 근거를 한 줄씩 남기게 해두었다. 원래 없던 걸 만든 것인지, 우리 코드가 원인이라 되돌린 것인지, 외부 데이터나 기획 변경 때문인지, 아니면 근거가 부족해 판정할 수 없는지.

판정불가로 분류된 건 그냥 제외하고 회고에서 같이 본다. 애매한 걸 억지로 분류하는 것보다 애매하다고 두는 편이 낫다는 판단이다. 이 부분은 아직 다듬는 중이다.

남은 생각

지표를 바꾸면서 배운 건, 지표의 정확도보다 지표가 팀에 주는 신호가 먼저라는 것이었다.

개수로 세던 시절에도 우리는 우리가 무슨 일을 하는지 알고 있었다. 다만 그게 숫자로 표현되지 않으니 계획을 세울 때 자꾸 어긋났고, 운영·보안처럼 티가 안 나는 일이 계속 뒤로 밀렸다. 무게를 붙인 뒤로 그 대화가 훨씬 쉬워졌다.

반대로, 이걸 개인 평가로 끌고 갔다면 아마 지금쯤 완전히 망가졌을 거라고 생각한다. 측정은 팀이 스스로를 보기 위한 거울이지 사람을 줄 세우는 자가 아니라는 걸, 만들면서 계속 되뇌었다.