분기 계획 회의에서 개발 리더가 말합니다. “이번 분기에는 결제 모듈을 정리해야 합니다.” PdM은 답합니다. “고객이 기다리는 기능이 세 개나 밀려 있는데요.” 두 사람 다 맞는 말을 하고 있지만 대화는 나아가지 않습니다. 한쪽은 코드의 말로, 다른 쪽은 고객의 말로 이야기하기 때문입니다.
기술 부채는 개발팀만의 문제가 아닙니다. 무엇을 먼저 만들지 정하는 사람이 PdM이라면, 무엇을 먼저 갚을지도 제품 결정입니다. 이 글에서는 기술 부채를 제품의 말로 옮겨 적고, 로드맵에서 새 기능과 균형을 맞추는 방법을 정리합니다.
기술 부채를 쉬운 말로
기술 부채는 소프트웨어를 만들며 미뤄 둔 일이 나중에 추가 비용으로 돌아오는 것을 빚에 빗댄 말입니다. 비유는 1992년 Ward Cunningham의 경험 보고에서 나왔습니다. 그는 처음 짠 코드를 일단 내놓는 일을 빚을 내는 것에 빗댔습니다. 그 뒤 이 말은 빨리 내놓으려고 고른 지름길 전반을 가리키는 말로 넓게 쓰이게 됐습니다. 빚을 내면 지금 당장 더 빨리 움직일 수 있지만, 갚지 않고 두면 이자가 붙습니다. 소프트웨어에서 이자는 같은 일을 하는 데 점점 더 많이 드는 시간과 수고입니다.
빚은 생긴 까닭에 따라 둘로 나눠 볼 수 있습니다. 아래 보기와 풀이는 이 글에서 새로 쓴 것입니다.
- 알고 진 빚: 출시 날짜를 맞추려고 “지금은 이렇게 하고 나중에 고치자”고 정한 것입니다. 결정한 사람이 있고 이유가 있습니다. 적어 두면 관리하기 쉽습니다.
- 모르고 생긴 빚: 만들 때는 최선이었지만 제품이 자라면서 맞지 않게 된 구조, 사용자가 열 배로 늘어 버거워진 설계, 지원이 끝난 라이브러리 같은 것입니다. 누구의 잘못이 아니라 시간이 만든 빚입니다.
이 구분은 PdM에게 쓸모가 있습니다. 알고 진 빚은 PdM 자신이 일정 때문에 요청한 것일 때가 많습니다. 빚을 낼 때 함께 정했다면 갚을 때도 함께 정해야 합니다. 그리고 빚이 있다는 것 자체는 나쁜 일이 아닙니다. 빠른 출시로 얻은 것이 이자보다 크다면 잘 낸 빚입니다. 문제는 얼마나 있는지 모르는 빚입니다.
부채가 제품에 드러나는 신호
PdM은 코드를 읽지 않아도 부채의 이자를 볼 수 있습니다. 이자는 제품과 일정에 드러납니다.
- 개발 속도가 느려집니다. 비슷한 크기의 기능인데 예전보다 오래 걸리거나, 특정 영역만 건드리면 추정이 번번이 빗나갑니다. “거기는 손대기 어렵습니다”라는 말이 같은 영역에서 되풀이됩니다.
- 장애와 되돌리기가 늘어납니다. 한 곳을 고쳤는데 상관없어 보이는 곳이 깨지고, 배포한 뒤 되돌리는 일이 잦아집니다.
- 고객 문의가 같은 자리에 몰립니다. 느린 화면, 가끔 사라지는 데이터, 같은 오류에 대한 문의가 줄지 않습니다.
- 사람에게 기댑니다. 특정 영역을 고칠 수 있는 사람이 한 명뿐이고, 새로 온 사람이 그 영역에서 일을 시작하기까지 오래 걸립니다.
이런 신호가 모두 부채 때문인 것은 아닙니다. 요구사항이 자주 바뀌거나 사람이 모자라도 같은 일이 생깁니다. 그래서 신호가 보이면 단정하지 않고 묻습니다. “왜 이렇게 오래 걸리나요”가 아니라 “이 영역에서 우리가 치르고 있는 비용이 무엇인가요”라고 묻습니다.
부채 항목을 제품의 말로 쓰기
“결제 모듈 정리”는 로드맵에서 “쿠폰 기능”을 이기기 어렵습니다. 얻는 것이 보이지 않기 때문입니다. 부채 항목을 다음 네 칸으로 적으면 같은 저울에 올릴 수 있습니다. 아래는 지어낸 예입니다.
표는 가로로 밀어서 볼 수 있습니다.
| 무엇 | 지금 드는 비용 | 갚으면 얻는 것 | 미루면 커지는 것 |
|---|---|---|---|
| 결제 모듈이 주문 화면과 얽혀 있음 | 결제 관련 기능은 추정의 두 배쯤 걸림(어림), 지난 분기 배포 되돌리기 3건이 이 영역 | 새 결제 수단을 붙이는 기간이 줄어듦, 결제 오류 문의 감소 | 계획된 정기 결제 기능이 이 구조 위에 올라가면 고칠 범위가 더 넓어짐 |
| 지원이 끝나는 라이브러리 사용 | 지금은 거의 없음 | 보안 수정을 계속 받을 수 있음 | 지원 종료 뒤 보안 문제가 생기면 급하게 옮겨야 함, 날짜가 정해져 있음 |
| 환불 기능을 급히 내느라 자동 처리를 만들지 않고 손으로 처리하게 둠 | 운영 담당이 건마다 직접 처리, 지난달 40건쯤(어림) | 운영 시간 절약, 처리 실수 감소 | 주문이 늘어나는 만큼 그대로 늘어남 |
적을 때 지킬 것이 있습니다.
- 지금 드는 비용은 관찰한 것으로 적습니다. “코드가 지저분함”이 아니라 걸린 시간, 장애 건수, 문의 건수처럼 누가 봐도 확인할 수 있는 것으로 씁니다. 숫자가 없으면 어림이라고 밝히고 적습니다.
- 미루면 커지는 것이 우선순위를 가릅니다. 이자가 일정한 빚과 이자가 불어나는 빚은 다릅니다. 곧 그 위에 새 기능을 올릴 영역, 날짜가 정해진 지원 종료, 사용량에 따라 커지는 비용은 미룰수록 비싸집니다.
- 지금 비용이 거의 없고 커지지도 않는 빚은 갚지 않아도 됩니다. 아무도 건드리지 않는 오래된 화면이 그런 예입니다. 목록에 적어 두고 그대로 둡니다.
로드맵에 올리는 방식
네 칸으로 적었다면 로드맵에 올리는 방식을 정합니다. 여기서는 세 가지 방식을 견줘 봅니다. 각각 장단점이 있습니다.
표는 가로로 밀어서 볼 수 있습니다.
| 방식 | 어떻게 | 좋은 점 | 조심할 점 |
|---|---|---|---|
| 비율 정하기 | 주기마다 개발 시간의 일정 몫을 부채에 씀. 몫은 팀이 정함 | 매번 다투지 않아도 꾸준히 갚음 | 몫 안에서 무엇을 갚는지 보지 않으면 급하지 않은 것부터 갚게 됨 |
| 기능과 묶기 | 새 기능이 지나가는 영역의 부채를 그 기능 일정에 넣어 함께 갚음 | 갚은 효과가 바로 그 기능에서 드러남 | 기능 일정이 늘어남. 새 기능이 지나가지 않는 영역은 계속 남음 |
| 따로 올리기 | 큰 부채를 기능과 같은 줄에 한 항목으로 올림 | 큰 구조 변경을 한 번에 할 수 있음 | 그동안 눈에 보이는 출시가 줄어듦. 범위와 끝을 정하지 않으면 길어짐 |
어떤 식으로 올리든 계획하는 자리에는 부채 목록을 기능 목록과 함께 펴 놓습니다. 그 자리에서 보이지 않는 항목은 차례가 오지 않습니다.
셋은 서로 배타적이지 않습니다. 작은 빚은 비율로, 새 기능이 지나가는 자리의 빚은 묶어서, 날짜가 정해졌거나 여러 기능을 막고 있는 큰 빚은 따로 올리는 식으로 섞어 씁니다. 어느 방식이든 PdM이 할 일은 같습니다. 이해관계자에게 “이번 분기에 기능이 하나 줄어드는 대신 무엇을 얻는가”를 제품의 말로 설명하는 것입니다.
개발팀과 대화하는 질문
부채의 크기와 리스크를 아는 사람은 개발자입니다. PdM은 부채의 크기를 판정하는 사람이 아니라, 물어서 제품 결정에 쓸 재료를 모으는 사람입니다.
- 지금 가장 자주 발목을 잡는 영역은 어디인가요?
- 그 영역 때문에 최근에 더 걸린 시간이나 생긴 장애가 있었나요?
- 앞으로 두 분기 로드맵 가운데 그 영역을 지나가는 기능은 무엇인가요?
- 지금 갚는 것과 반년 뒤 갚는 것은 드는 품이 얼마나 다른가요?
- 한 번에 다 갚아야 하나요, 나눠서 갚을 수 있나요?
- 갚은 뒤 무엇이 달라졌는지 어떻게 확인할 수 있나요?
- 이번에 일정을 맞추려고 새로 내는 빚이 있나요? 있다면 어디에 적어 둘까요?
마지막 질문은 출시 때마다 묻습니다. 알고 진 빚을 낸 날 적어 두는 것이 가장 싼 관리입니다.
바로 쓰는 부채 목록 한 장
- 개발 리더와 함께 부채 항목을 다섯 개에서 열 개 정도 적었습니다
- 항목마다 무엇, 지금 드는 비용, 갚으면 얻는 것, 미루면 커지는 것을 채웠습니다
- 지금 드는 비용을 관찰한 것으로 적었고, 어림은 어림이라고 밝혔습니다
- 미루면 커지는 항목과 그대로 둬도 되는 항목을 나눴습니다
- 항목마다 비율, 묶기, 따로 올리기 가운데 어느 방식으로 갚을지 정했습니다
- 로드맵을 설명할 때 부채 항목을 제품의 말로 함께 설명했습니다
- 출시 때 새로 낸 빚을 목록에 더했습니다
- 분기마다 목록을 다시 보고 갚은 것과 달라진 것을 적었습니다
기술 부채를 다루는 일은 개발팀의 요청을 들어주느냐 마느냐가 아닙니다. 지금의 속도와 앞으로의 속도 사이에서 제품이 무엇을 고를지 정하는 일입니다. 빚을 제품의 말로 적어 같은 저울에 올리면, 새 기능과 갚기는 다투는 사이가 아니라 함께 견주는 항목이 됩니다.
참고
- Ward Cunningham, “The WyCash Portfolio Management System”, OOPSLA ’92 Experience Report, 1992년 3월 26일(기술 부채 비유의 출처, 개념만 가져오고 문장은 인용하지 않음).
- Martin Fowler, “Technical Debt Quadrant”, martinfowler.com, 2009년 10월 14일(의도했는지에 따라 빚을 나누는 생각을 참고함. 보기와 풀이는 직접 썼고 문장은 인용하지 않음).
- 그 밖에는 참고 자료 없이 직접 썼습니다. 본문의 표에 나오는 항목과 숫자는 설명을 위해 지어낸 예입니다.
- 우선순위를 정하는 틀은 이 블로그의 「우선순위 결정 프레임워크」, 로드맵을 만드는 방법은 「프로덕트 로드맵 만들기」 글을 함께 보세요.