기술 부채

기술 부채란

기술 부채(technical debt)는 더 나은 방법 대신 빠른 방법을 택해서 나중에 치러야 하는 추가 작업이다. 워드 커닝햄(Ward Cunningham)이 1992년에 금융 부채에 빗대어 처음 쓴 말이다.

금융	소프트웨어
원금	지름길을 제대로 된 구조로 고치는 데 드는 비용
이자	고치지 않은 채로 그 코드를 건드릴 때마다 더 드는 시간과 버그
복리	부채 위에 새 코드가 쌓여 고치기가 점점 더 비싸진다
파산	작은 변경도 못 할 만큼 느려져 전면 재작성 이야기가 나온다

이 비유의 쓸모는 비개발자와 대화할 수 있게 해 준다는 것이다. "코드가 지저분하다" 대신 "이 영역은 이자율이 높아서 기능 하나에 이틀이 더 든다"고 말할 수 있다.

부채는 나쁜가

빚 자체는 나쁘지 않다. 출시 시점을 맞추는 것이 더 큰 가치라면 의식적으로 빌리는 것은 합리적인 결정이다. 문제는 빌린 줄 모르거나, 빌린 것을 기록하지 않거나, 갚지 않는 것이다. 이자는 그 코드를 자주 건드릴 때만 붙는다. 다시 볼 일 없는 코드의 부채는 갚지 않아도 된다.

원인: 파울러의 사분면

마틴 파울러는 부채를 신중한가 · 무모한가와 의도했나 · 모르고 했나 두 축으로 나눈다.

	의도적(Deliberate)	비의도적(Inadvertent)
무모함(Reckless)	"설계할 시간 없어": 알면서 대충 한다	"레이어링이 뭐지?": 몰라서 엉망이 된다
신중함(Prudent)	"지금 출시하고 결과는 나중에 처리하자": 비용을 알고 빌린다	"이제야 어떻게 했어야 했는지 알겠다": 만들면서 배운 결과

신중하고 의도적인 부채만 전략적 선택이다. 이때는 무엇을 빌렸는지 적고 갚을 시점을 정해 둔다.
신중하지만 비의도적인 부채는 피할 수 없다. 좋은 팀도 만들어 봐야 더 나은 설계를 안다. 그래서 리팩터링은 일회성 행사가 아니라 일상이다.
무모한 부채는 코드 리뷰, 페어 프로그래밍, 학습으로 줄인다.

스티브 매코널(Steve McConnell)은 같은 현상을 의도적 부채(단기·장기)와 의도하지 않은 부채(이해 부족, 실수)의 두 갈래로 설명한다. 단기 부채 가운데 하나하나 식별되는 큰 지름길보다, 수많은 작은 지름길이 흩어진 부채가 더 위험하다. 눈에 띄지 않은 채 전체 속도를 떨어뜨리기 때문이다.

부채가 사는 곳

영역	예
코드	중복, 거대한 함수, 하드코딩된 값
설계·아키텍처	잘못 나눈 모듈 경계, 확장하기 어려운 데이터 모델
테스트	테스트 없는 핵심 로직, 불안정한(flaky) 테스트
의존성·인프라	지원이 끝난 라이브러리·런타임, 수동 배포
문서·지식	한 사람만 아는 시스템, 낡은 README

측정

방법	보는 것
정적 분석 (SonarQube 등)	복잡도, 중복, 코드 스멜, 테스트 커버리지, 유지보수성 지수
핫스팟 분석	자주 바뀌는 파일 × 복잡한 파일. 이자가 실제로 붙는 곳이다
흐름 지표	특정 영역의 변경 리드 타임, 버그 재발률, 재작업 비율
팀의 감각	"여기 건드리기 무섭다"는 말이 나오는 곳

도구 점수는 출발점일 뿐이다. 복잡해도 아무도 건드리지 않는 코드보다, 덜 복잡해도 매주 바뀌는 코드의 부채가 더 비싸다.

갚는 법

1. 보이게 만든다

부채를 머릿속이나 코드 주석(// TODO)에만 두면 우선순위 경쟁에 끼지 못한다. 제품 백로그에 항목으로 올리고, 사용자 스토리처럼 크기를 추정하고, 무엇이 나빠지는지(이자)를 적는다. 그래야 PO가 기능과 같은 저울에 올려 순서를 정할 수 있다. 백로그 다루는 법은 백로그와 추정에 있다.

2. 이자가 큰 것부터

우선순위 높음	우선순위 낮음
곧 기능을 추가할 영역	당분간 안 건드릴 영역
버그가 반복되는 곳	보기엔 지저분하지만 안정적인 곳
보안·지원 종료 의존성	취향의 문제

3. 일상에 섞는다

보이스카우트 규칙: 지나간 코드를 조금 더 낫게 남긴다. 기능을 고치러 들어간 김에 그 주변을 정리한다.
매 스프린트 용량의 일정 비율을 부채 상환에 고정해 두는 팀이 많다. "기능 다 끝나면 정리하자"는 대개 오지 않는다.
큰 재작성보다 작은 리팩터링을 쌓는다. 원칙(두 개의 모자, 테스트 먼저)은 리팩터링 원칙에 있다.

4. 새로 쌓이는 것을 막는다

코딩 컨벤션, 완료의 정의에 테스트·문서 포함, 코드 리뷰, CI의 정적 분석 게이트가 무모한 부채를 줄인다. 의도적으로 빌릴 때는 결정 이유와 갚을 조건을 남긴다. 나쁜 코드가 비싼 이유(깨진 유리창, 생산성 저하)는 클린 코드: 함수와 이름에서 다룬다.

예시

상황	부채	처리
출시일에 맞추려고 결제 설정을 하드코딩	신중·의도적	출시 직후 스프린트에 "설정 분리" 항목을 올려 둔다
기능을 다 만들고 나서 더 단순한 구조가 보임	신중·비의도적	다음에 그 영역을 건드릴 때 리팩터링한다. 안 건드리면 미룬다
테스트 없이 계속 기능을 덧붙임	무모·의도적	완료의 정의에 테스트를 넣고, 핫스팟부터 특성 테스트를 붙인다

정리

기술 부채는 빠른 길의 대가다. 원금과 이자로 나눠 생각하면 비개발자와도 우선순위를 논의할 수 있다.
신중하고 의도적인 빚은 전략이고, 무모한 빚은 습관 문제다. 만들며 배운 결과로 생기는 빚은 피할 수 없다.
이자는 자주 건드리는 곳에서만 붙는다. 핫스팟부터 갚는다.
백로그에 올려 보이게 하고, 매 스프린트 일상적으로 조금씩 갚는다.

버그 제보