기술 부채
Technical Debt
기술 부채란?
- 급히 대충 짠 코드가 '빚'처럼 쌓임
- 방치하면 이자(속도 저하)
- 리팩터링으로 상환
기술 부채라는 말이 팀에 들어오면 가장 먼저 바뀌는 것은 대화의 언어입니다. 그전까지 '코드가 지저분하다', '그 파일은 손대기 무섭다'는 개발자 개인의 감상이었던 것이, 원금과 이자가 붙는 재무 항목으로 번역되어 경영 회의 테이블에 올라옵니다. 그래야 '이번 분기에 기능 12개를 내보내려면 상환에 스프린트 용량을 몇 퍼센트 떼야 하는가' 같은 협상이 가능해집니다. 감정 대신 견적으로 말하게 되는 것, 그것이 이 개념의 실질적인 쓸모입니다.
부채는 성격에 따라 갚는 방법이 다릅니다. 흔히 의도적인가 무의식적인가, 신중한가 무모한가로 네 갈래를 나누는데, 현장에서 가장 위험한 쪽은 '무모하고 무의식적인' 부채입니다. 빚을 졌다는 사실조차 모르기 때문입니다. 영역으로 보면 코드 부채, 아키텍처 부채, 테스트 부채, 데이터·스키마 부채, 인프라·문서 부채로 갈리는데, 코드 부채는 몇 주 리팩터링으로 잡히지만 아키텍처 부채는 분기 단위 계획이 필요합니다. 경계도 분명히 해야 합니다. 지금 잘못 동작하면 버그이고, 잘 동작하지만 바꾸기 비싼 상태가 부채입니다. 오래된 시스템이 전부 부채인 것도 아닙니다 — 손댈 일이 없는 안정된 레거시에는 이자가 붙지 않습니다.
가장 흔한 사고는 '한 번에 다 갚자'며 전면 재작성에 들어가는 것입니다. 6개월 기능 동결을 선언했다가 새 시스템이 완성되지 않아 구시스템과 병행 운영에 들어가면, 갚기는커녕 부채가 두 벌로 늘어납니다. 반대쪽 오해도 있습니다. 부채 목록을 위키 문서에만 적어두고 백로그에 티켓으로 올리지 않으면 그 목록은 영원히 읽히지 않습니다. 경영진이 '그건 개발팀 내부 사정'으로 선을 그으면 상환 예산은 배정되지 않고, 결국 대형 장애가 터진 다음에야 몇 배 비싼 값으로 갚게 됩니다. 부채는 사건이 아니라 잔고이므로, 매 스프린트에 고정 비율로 갚는 방식이 현실적입니다.
1992년 워드 커닝햄(Ward Cunningham)이 '빚'에 비유해 제안한 개념으로, 소프트웨어 유지보수 논의의 핵심어가 됐습니다.
가상의 사례로 살펴보겠습니다. 임직원 140명 규모의 물류 SaaS 기업 A사입니다. 개발 인력 18명으로 3년간 기능을 밀어붙인 끝에, 2주 주기 릴리스가 평균 12일씩 밀리고 운영 장애가 월 11건까지 늘었습니다. 신규 입사한 개발자가 결제 모듈의 금액 표기 하나 고치는 데 3주가 걸렸습니다.
- CTO가 스프린트 회고에서 "기능이 많아서 늦는 게 아니라 손댈 때마다 비싼 겁니다"라고 말하며, 최근 6개월 지연 티켓 87건의 원인을 분류하게 했습니다. 절반 이상이 결제·정산 모듈 한 곳에 몰려 있었습니다.
- 개발팀장이 부채를 위키에서 꺼내 지라 백로그에 티켓 47건으로 등록했습니다. 각 건마다 '상환 예상 공수'와 '방치할 경우 월 낭비 시간'을 적어 넣자, 어느 것부터 갚을지가 숫자로 정렬됐습니다.
- PO가 경영진 회의에서 스프린트 용량의 20%를 상환에 고정 배정하자고 제안했습니다. 영업이사가 "그러면 기능이 늦어지지 않겠냐"고 묻자 CTO는 "지금도 12일씩 늦고 있습니다"라고 답했습니다.
- 전면 재작성은 접고 결제 모듈만 떼어 6주간 집중했습니다. 테스트 커버리지를 18%에서 62%로 올린 뒤 내부 구조를 바꿨고, 나머지 영역은 기능 작업으로 파일을 열 때마다 함께 정리하는 방식으로 처리했습니다.
- 7개월 뒤 릴리스 지연은 평균 12일에서 3일로, 월 장애는 11건에서 4건으로 줄었습니다. 신규 입사자가 첫 배포를 하기까지 걸린 기간도 3주에서 5일로 짧아졌습니다.