급하게 이삿짐을 싸다 보면 일단 상자에 아무렇게나 넣고 나중에 정리하자고 마음먹을 때가 있습니다. 당장은 빨리 끝나지만, 새집에서 물건 하나를 찾으려면 상자를 몇 개씩 뒤져야 하고 정리를 미룰수록 수고는 점점 커집니다. 소프트웨어 개발에도 이와 똑같은 일이 벌어지는데, 이를 가리키는 말이 바로 ‘기술 부채(Technical Debt)’입니다.

기술 부채란 쉽게 말해 당장의 속도를 위해 더 나은 설계 대신 손쉬운 방법을 택했을 때, 나중에 고치고 다듬느라 치르게 되는 추가 비용을 의미합니다. 미국의 프로그래머 워드 커닝햄(Ward Cunningham)이 1992년 한 학회 발표에서 처음 쓴 비유로, 오늘날에는 개발자뿐 아니라 경영진과 기획자도 흔히 쓰는 말이 되었습니다.

본 자료에서는 기술 부채의 뜻과 탄생 배경부터 부채가 쌓이는 원리, 부채의 여러 종류, 그리고 부채를 관리하고 갚아 나가는 방법까지 쉽게 이해할 수 있도록 정리합니다.

기술 부채의 원리와 관리

기술 부채란 무엇인가?

커닝햄은 1992년 객체지향 프로그래밍 학회인 OOPSLA에서 자신이 만든 금융 소프트웨어 개발 경험을 발표하며 이 비유를 꺼냈습니다. 그는 처음 내놓는 코드는 빚을 지는 것과 같다고 말했습니다. 조금 빚을 지면 개발 속도가 빨라지지만, 그 빚은 코드를 다시 고쳐 쓰는 방식으로 제때 갚아야 한다는 것입니다.

이 비유가 널리 퍼진 까닭은 개발자가 아닌 사람도 바로 이해할 수 있기 때문입니다. 빚에는 이자가 붙듯, 대충 짠 코드를 그대로 두면 그 위에 기능을 하나 더할 때마다 시간과 노력이 조금씩 더 듭니다. 커닝햄은 갚지 않은 빚이 쌓이면 조직 전체가 이자에 짓눌려 멈춰 설 수 있다고 경고했습니다.

여기서 원금은 아직 고치지 않은 엉성한 코드 그 자체이고, 이자는 그 코드 때문에 매번 더 들어가는 시간과 노력입니다. 원금을 갚는다는 것은 코드를 제대로 다시 정리한다는 뜻이며, 원금이 남아 있는 한 이자는 개발이 계속되는 동안 꼬박꼬박 붙습니다.

부채는 어떻게 쌓이고 이자는 어떻게 붙을까?

기술 부채는 여러 경로로 쌓입니다. 출시 일정에 맞추려고 테스트를 건너뛰거나, 비슷한 코드를 고치지 않고 복사해 붙이거나, 설명서를 남기지 않는 경우가 대표적입니다. 처음에는 맞았던 설계가 서비스가 커지면서 맞지 않게 되는 것처럼, 아무도 잘못하지 않았는데 생기는 부채도 있습니다.

이자는 눈에 잘 보이지 않는 형태로 붙습니다. 작은 기능 하나를 고쳐도 예상하지 못한 곳에서 오류가 나고, 새로 온 개발자는 얽힌 코드를 이해하는 데 몇 주를 보냅니다. 같은 작업에 드는 시간도 해마다 조금씩 늘어나지만, 하루하루의 변화가 작아서 누구도 쉽게 알아차리지 못합니다.

이자가 무서운 까닭은 복리처럼 불어난다는 데 있습니다. 대충 짠 코드 위에 새 코드를 얹으면, 새 코드 역시 그 엉성한 구조에 맞춰 억지로 짜일 수밖에 없습니다. 결국 한 군데의 지름길이 여러 군데의 우회로를 낳고, 고쳐야 할 범위는 처음보다 몇 배로 넓어집니다.

이자가 원금보다 커지면 새 기능을 만드는 시간보다 기존 문제를 막는 시간이 더 많아지는 상황에 이르게 됩니다.

모든 부채가 나쁜 것은 아니다, 기술 부채의 종류

영국의 소프트웨어 개발자 마틴 파울러(Martin Fowler)는 2009년 기술 부채를 두 가지 기준으로 나눈 ‘기술 부채 사분면’을 제시했습니다. 하나는 알고 졌는지 모르고 졌는지이고, 다른 하나는 신중했는지 무모했는지입니다.

(1) 신중하고 의도적인 부채
‘지금은 출시가 먼저이니 이렇게 하고, 나중에 고치자’처럼 결과를 알고 택한 부채입니다. 사업에 꼭 필요한 시기를 잡게 해 주는 전략적 선택이 될 수 있습니다.

(2) 무모하고 의도적인 부채
‘설계할 시간이 없다’며 알면서도 대충 넘기는 경우로, 가장 위험한 형태입니다.

(3) 모르고 진 부채
경험이 부족해 생기거나, 일을 마친 뒤에야 ‘이렇게 했어야 했구나’ 하고 깨닫는 부채입니다. 배움의 과정에서 피하기 어려운 부채이기도 합니다.

주의할 점은 의도적인 부채라도 갚을 계획이 없으면 금세 무모한 부채로 바뀐다는 것입니다. ‘나중에 고치자’던 코드가 몇 년째 그대로 남아 있는 일은 개발 현장에서 아주 흔합니다.

이처럼 기술 부채는 무조건 피할 대상이 아니라, 은행 대출처럼 언제 얼마나 지고 어떻게 갚을지를 따져야 하는 관리 대상입니다.

기술 부채를 관리하고 갚는 법

부채를 갚는 가장 대표적인 방법은 리팩터링(Refactoring)입니다. 리팩터링은 프로그램이 하는 일은 그대로 두고 코드 구조만 더 읽기 쉽고 고치기 쉽게 다듬는 작업을 말합니다. 겉으로 달라지는 것이 없어 성과가 잘 보이지 않기 때문에, 개발자와 경영진이 부채의 비용을 함께 이해하는 것이 무엇보다 중요합니다.

(1) 부채를 기록하기
나중에 고칠 부분을 할 일 목록에 적어 두면 잊히지 않고, 얼마나 쌓였는지도 한눈에 볼 수 있습니다.

(2) 꾸준히 조금씩 갚기
개발 시간의 일부를 정해 두고 매번 조금씩 정리하면 이자가 불어나는 것을 막을 수 있습니다.

(3) 테스트로 안전망 만들기
자동 테스트를 갖춰 두면 코드를 고칠 때 다른 곳이 망가지지 않았는지 바로 확인할 수 있어 부채를 갚는 부담이 줄어듭니다.

(4) 너무 큰 부채는 새로 짓기
부채가 지나치게 쌓여 고치는 비용이 새로 만드는 비용보다 커졌다면, 낡은 시스템을 단계적으로 새 시스템으로 바꾸는 것도 방법입니다. 다만 비용과 위험이 큰 만큼 신중하게 결정해야 합니다.

기술 부채는 속도와 품질 사이에서 늘 균형을 찾아야 하는 개발 현장의 현실을 빚이라는 익숙한 말로 보여 줍니다. 빚을 지는 것 자체보다 빚을 졌다는 사실을 잊는 것이 더 큰 문제이며, 잘 관리한 부채는 오히려 빠른 성장의 발판이 됩니다.

오늘 아낀 시간이 내일 이자로 돌아온다는 사실을 기억하는 것, 그것이 건강한 소프트웨어의 첫걸음입니다.