기술 부채 티켓

정리해야 할 것이 개발자들 사이의 말로만 돌던 시절이 있었습니다. 이 파일은 손대기 무섭다거나 배포 절차가 너무 오래 걸린다는 이야기는 점심시간에 나왔고, 앞으로 만들 후보를 모아 둔 목록에는 올라가지 않았습니다.

목록에 없는 일은 순서 회의에 등장하지 않습니다. 그래서 같은 분기에 기능 열두 개가 정해지고 정리는 한 건도 정해지지 않는 일이 반복됐습니다. 빨리 가려고 미뤄 둔 정리가 쌓여 나중에 시간을 빼앗는 상태를 기술 부채라고 하는데, 이 상태는 조용히 누적되다가 추정치로 드러납니다. 반년 전에 1주면 됐던 크기의 작업이 이제 3주로 불리는데, 그 차이를 설명할 자리가 어디에도 없었습니다.

기술 부채 티켓은 그 일을 목록 위로 끌어올린 것입니다. 적어 두면 순서를 정하는 자리에 함께 올라가고, 미루기로 했다면 미뤘다는 기록이 남습니다. 빌린 돈에 이자가 붙는 것과 같아서, 원금인 정리를 미루는 동안 이자는 매번 작업에 붙는 여분의 시간으로 빠져나갑니다. 티켓은 그 이자를 눈에 보이게 적는 자리입니다.

한 장에 적는 것이 정해져 있습니다. 기능 티켓과 다른 점은 무엇을 만들지가 아니라 지금 무엇이 비용을 만들고 있는지를 적는다는 데 있습니다.

1. 지금 상태를 적습니다. 어떤 부분이 어떻게 되어 있는지를 사실로 씁니다. 결제 관련 코드가 한 파일에 3,000줄로 모여 있고 테스트가 없다는 식입니다.
2. 그 상태가 만드는 비용을 숫자로 적습니다. 이 자리가 티켓의 성패를 정합니다. 배포마다 손으로 확인하는 데 20분이 들고 주 세 번 배포하니 한 달에 네 시간이 빠진다거나, 이 파일을 건드리는 작업은 매번 반나절이 더 걸린다고 적습니다. 숫자가 없으면 기능과 순서를 다툴 수 없습니다.
3. 그대로 뒀을 때 생길 일을 적습니다. 다음 분기에 예정된 기능이 같은 파일을 건드린다면, 그때 드는 시간이 지금보다 늘어난다는 사실이 여기 들어갑니다.
4. 범위를 한 주기 안으로 쪼갭니다. 동작은 그대로 두고 구조만 고치는 작업을 리팩터링이라고 하는데, 결제 모듈 전체를 리팩터링하겠다는 티켓은 아무 주기에도 담기지 않습니다. 테스트를 먼저 붙이는 조각, 함수 하나를 떼어내는 조각으로 나눕니다.
5. 기능과 같은 자리에서 순서를 정합니다. 따로 관리하는 목록을 두면 그 목록은 열리지 않습니다. 우선순위 결정 회의에 기능 티켓과 섞어 올려놓고 함께 견줍니다.

배정에는 규칙을 두는 팀이 많습니다. 한 주기 용량의 15에서 20퍼센트를 이 몫으로 미리 떼어 두는 방식입니다. 미리 떼지 않으면 급한 기능이 매번 그 자리를 가져가고, 라벨만 붙은 티켓이 목록 아래쪽에 묘지처럼 쌓입니다.

이 티켓이 필요해지는 자리는 대개 숫자로 먼저 나타납니다.

첫째는 추정치가 커질 때입니다. 비슷한 크기의 작업에 붙는 견적이 반년 전보다 두 배가 됐다면, 원인을 찾아 티켓으로 적을 시점입니다.

둘째는 같은 자리에서 사고가 반복될 때입니다. 서비스에 영향을 준 사고를 인시던트라고 하는데, 한 분기에 같은 모듈에서 세 번 났다면 그 모듈의 구조가 원인일 가능성이 큽니다. 사고 대응이 끝난 뒤 남기는 티켓이 여기 속합니다.

셋째는 새 기능이 그 부분을 건드릴 때입니다. 어차피 열어야 하는 파일이라면 정리를 같은 작업에 묶는 편이 싸게 끝납니다. 이때 티켓은 기능 티켓 옆에 붙어 함께 계획됩니다.

넷째는 외부에서 규격이 바뀔 때입니다. 쓰고 있는 외부 서비스가 곧 없앨 예정이라고 미리 알리는 디프리케이션 공지를 내면, 기한이 정해진 부채가 생깁니다. 이 종류는 미룰 수 있는 상한이 있어 순서 다툼에서 대개 이깁니다.

반대로 이 티켓이 아닌 것도 분명합니다. 의도와 다르게 동작하는 결함은 버그이고, 지금 고치는 일입니다. 부채는 지금 제대로 동작하지만 앞으로 비싸지는 구조를 가리킵니다. 둘을 같은 라벨로 묶으면 급한 결함이 정리 항목에 섞여 묻힙니다.

"이건 기능 티켓이 아니라 부채 티켓으로 올릴게요. 근거는 배포 시간입니다."

정리 작업을 목록에 올려 순서 경쟁에 참여시키겠다는 뜻입니다.

"이번 주기에는 부채 티켓 두 장을 포함했습니다."

미리 떼어 둔 몫을 무엇으로 채웠는지 알리는 보고입니다.

"그건 부채가 아니라 버그예요. 다음 주기로 넘기면 안 됩니다."

분류가 잘못돼 급한 일이 미뤄질 상황이라는 지적입니다.

페이지덱에서 이 티켓이 실제로 순서를 이긴 것은 숫자가 붙은 다음이었습니다. 태오가 문서 저장 부분에 테스트가 없어 배포 전 손 확인에 매번 25분이 든다고 적고, 주 세 번 배포 기준으로 분기당 열여섯 시간이라는 값을 붙였습니다.

지현은 그 값을 기능 하나의 개발 기간과 나란히 놓았습니다. 이번 분기에 문서 저장 쪽을 건드리는 기능이 두 건 예정돼 있었고, 정리를 먼저 하면 그 두 건의 견적이 각각 이틀씩 줄어든다는 계산이 나왔습니다. 그래서 이 티켓은 기능보다 앞 순서에 놓였습니다.

개발팀 안의 사정이라 제품 쪽은 볼 필요가 없다고 보는 경우가 가장 많습니다. 코드 이야기이니 판단할 수 없는 영역처럼 느껴집니다. 하지만 제품 쪽이 판단할 것은 코드가 아니라 시간입니다. 지금 사흘을 쓰면 다음 분기 견적 열흘이 줄어드는지, 그 열흘이 이번에 미룰 기능보다 값어치가 큰지가 질문입니다. 이 판단을 개발팀에만 남기면 정리는 늘 급한 기능에 밀리고, 반대로 제품 쪽이 아예 손을 놓으면 정리만 쌓여 몇 분기 동안 사용자가 볼 변화가 나오지 않습니다.

코드가 마음에 안 들어 고치고 싶은 취향의 문제로 보는 것도 흔합니다. 개발자마다 좋아하는 구조가 다르니 그렇게 읽힐 여지가 있습니다. 그런데 티켓으로 적히는 순간 기준은 취향이 아니라 비용이 됩니다. 2번 항목에 숫자를 못 채우는 티켓은 실제로 순서 다툼에서 지고, 그것이 이 방식의 걸러내는 장치입니다. 더 좋은 구조라는 말만 적힌 티켓과 한 달에 네 시간이 빠진다고 적힌 티켓은 같은 회의에서 다르게 다뤄집니다.