[한글화 프로젝트] 3. 기술부채

번역가 : 박성철 월간 라디오와 모형의 마이컴 강좌를 시작으로 컴퓨터 프로그래밍에 빠져서 지금까지 시간 가는 줄 모르고 살았다. 현 SK 플래닛 개발팀 팀장으로 멋진 팀원의 덕을 보며 잘 지내는 중이며 한국 SW 개발 문화를 개선하는 데 관심이 많다. 원문링크

 

 

기술 부채

Technical Debt

 

우리에게 시스템에 추가해야 하는 기능이 있다고 치자. 이 일을 하는 데에는 두 가지 방법이 있다. 하나는 (물론 나중에 잘 가다듬을 생각을 하며) 좀 지저분하지만 빠르게 처리하는 방법이다. 다른 하나는 설계가 더 깔끔하지만, 준비 시간이 더 걸리는 방법이다.

기술 부채(Technical Debt)는 이 문제를 잘 이해하도록 워드 커닝햄(Ward Cunningham)에 의해 고안된 멋진 은유다. 이 은유에 의하면, 빠르지만 지저분한 방식으로 일하면, 회계에서 말하는 부채와 유사한 기술 부채로 압박받게 된다. 회계 부채와 같이, 기술 부채는 지저분하면서 빠른 방법을 사용했기 때문에 추가 개발 노력을 기울임으로써 이자를 내야 한다. 우리는 이 이자를 계속 내기로 선택할 수도 있고, 지저분하고 빠른 방식의 설계를 리팩토링으로 개선하여 원금을 갚을 수도 있다. 원금을 갚으려면 비용이 들지만, 앞으로 치를 이자가 줄어드는 이점이 있다.

이 은유는 빠르지만 지저분한 방식이 실용적일 가능성이 있는 이유도 설명한다. 사업에서 시장 기회를 노리면서 일정 부채를 지듯이 개발자는 중요한 마감을 지키려고 기술 부채를 지게 된다. 다만, 개발 조직들이 감당하지도 못할 부채를 쌓아 두고 과도한 이자를 내면서 가용한 대부분의 개발력을 허비하며 지내는 모습이 너무나 일반적이라는 게 문제다.

기술 부채는 (당연히) 돈과 달리 효과적으로 측정하기 불가능해서 애매한 면이 있다. 기술 부채의 이자를 갚느라 팀의 생산성은 상처를 입지만, 우리가 생산성을 측정할 수 없는 한, 기술 부채의 진정한 효과를 가시적으로 확인할 수는 없다.

자주 간과하는 한 가지는, 제품을 출시하지 않고는 대출을 이윤으로 전환할 수 없다는 점이다. <설계 지구력 가설>에 따르면, 부채에서 이윤을 조금이라도 얻으려면 설계 상환선에 이르기 전에 제품을 출시해야 한다. 상환선 밑이라고 해도 내야 할 이자와 원금을 조기 출시에서 얻게 되는 가치와 맞교환해야 한다.

기술 부채는 다양한 형태로 발생하며, 좋기도 하지만 나쁘기도 하다. 이에 대해서는 <기술 부채 사분면>에서 설명했다.

(이 개념은 워드 커닝햄이 OOPSLA 1992에서의 경험을 정리하면서 소개했으며 위키에서도 토론이 진행되었다.)

추가

워드 커닝햄은 자신이 창안한 이 은유에 대해 논하는 비디오를 찍었다.

몇몇 독자는 (기술 부채와) 비슷한 멋진 이름을 보내왔다. 데이비드 패너리티는 엉터리 프로그래밍을 적자 프로그래밍이라고 칭했다. 분명 그는 원래 이 표현이 정부 정책과 일치했던 수년 전에 쓰기 시작한 것 같은데, 지금 다시 자연스러운 상황이 되었다고 생각된다.

스코트 우드는 “기술 인플레이션이란 현재의 산업 기술 수준이 제품 코드 기반의 수준을 넘어서는 바람에 제품이 호환성을 잃게 되는 상황이라 할 수 있다. 언어의 버전이 뒤처져서 코드가 더는 주류 컴파일러와 호환되지 않는 시점이 예라고 할 수 있다”고 제안했다.

스티브 맥코넬은 이 은유의 훌륭한 점 몇 가지, 특히 특히 의도하지 않은 부채를 줄이면 나중에 필요에 따라 부채를 질 수 있는 여지를 확보할 수 있다는 점을 지적했다. 난 그의 (이슈를 수정할 때 웹 사이트보다 임베디드 시스템이 훨씬 높은) 최소 지급의 개념도 좋아한다.

에어론 에릭슨은 엔론 회계에 대해서 말했다.