분별 있는 행동

프로그래머가 알아야 할 97가지 - 첫 번째 이야기

by - Seb Rose
에든버러의 Rational DOORS 팀에서 수석 소프트웨어 엔지니어로 일했다. 1980년 프로그래머로서 처음 일을 시작하여 Apple lie를 사용하여 BASIC으로 부동산 업자와 텔레마케터용 애플리케이션을 만들었다. 1987년 에든버러 대학교를 졸업한 후 REKURSIV 프로젝트에 참여하고 프리랜서가 되었다. 요즘은 애자일 프랙티스와 레거시 코드 개선에 관심을 두고 있다.

뭘 하든, 항상 분별을 잊지 말라. 자신의 행동이 어떤 결과를 낳을지 잘 생각하라.
- 작자 미상

여유가 넉넉히 있어 보이는 일정도 막상 작업을 해보면 꼭 어딘가 문제가 생겨서 지연이 발생하곤 합니다. 그 문제를 해결하기 위한 선택지로 바른 방법과 빠른 방법이 있다면 아무래도 후자가 매력적으로 보이는 것이 사실입니다. 나중에 다시 손봐야 한다는 걸 알면서도 일단 후자를 선택하곤 합니다. 반드시 나중에 고치겠다고 스스로 다짐하며 주위의 동료, 혹은 고객과 약속까지 합니다. 물론 약속한 시점에는 당연히 지킬 마음으로 약속합니다. 하지만 막상 그때가 되면 다른 문제가 발생해서 그쪽에 주력하게 되고 결국은 손도 못 대는 일이 일어나게 됩니다. 이처럼 해야 할 일을 뒤로 미루는 것을 기술 부채 (Technical debt)라고 부릅니다. 당연히 바람직하지 않은 것입니다. Martin Fowler는 이것을 고의적 기술 부채라 정의하고, 고의가 아닌 부주의에 의한 기술 부채와 혼동해서는 안 된다고 설명합니다.

기술 부채는 말 그대로 빚을 의미 합니다. 짧게 보면 도움이 될 수 있지만 다 갚을 때까지 이자를 내야 하는 부담이 있습니다. 빚을 망각하고 여유를 부리며 코드를 작성하다 보면 기능 추가나 코드의 리팩토링이 어려워지게 됩니다. 빚은 새로운 오류의 온상이 되어 테스트 케이스의 가치를 해치는 원인이 되기도 합니다. 내버려 두면 둘수록 그 해는 점점 더 커져갑니다. 하나의 문제를 해결하면 그것이 원인이 되어 또 다른 문제가 생기고 그러한 문제들이 쌓여 산처럼 불어나는 일이 발생합니다. 방치했던 문제 때문에 이상적인 설계를 버리고 어쩔 수 없이 차선책을 선택을 해야 하는 상황이 올 수도 있습니다. 이러지도 저러지도 못하고 수정이 어려운 코드를 줄줄이 적어나갈 수밖에 없는 상황이 되어 버리는 것입니다. 사태가 극단적으로 악화되어 더는 손 쓸 수 없는 상황이 되었을 때, 모든 걸 멈추고 가장 처음 발생한 부채로 눈을 돌려 해결해보려 합니다. 사실 그런 상황이라면 이미 수정은 극단적으로 어려워져 있을 겁니다. 고쳐보려 해도 막대한 시간이 걸리거나 위험부담이 너무 커서 돌이킬 수 없는 상황일 가능성이 높습니다.

마감에 맞춰야 하거나 작은 기능을 추가하기 위해 어쩔 수 없이 빚을 져야 하는 일도 있습니다. 빚을 만들지 않도록 노력해야 하지만 어쩔 수 없는 불가항력이란 것도 있습니다. 그럴 때는 일단 기술 부채를 안고 갈 수밖에 없습니다. 이런 상황에서 가장 중요한 건 기술 부채의 존재를 잊지 않도록 계속 추적하고, 갚을 수 있을 때 빨리 갚아야 합니다. 어쩔 수 없이 타협하기로 했다면 바로 작업 일정에 넣고 이슈 트래커 시스템에 등록해야 합니다. 기술 부채가 존재한다는 사실을 항상 상기할 수 있도록 합니다.

다음 이터레이션에서 변제하도록 미리 일정을 짜두면 비용을 최소한으로 줄일 수 있습니다. 빚을 방치하면 이자가 발생하는 건 당연한 이치입니다. 이 이자를 추적하고, 그 코스트를 명확히 정의해둬야 합니다. 이를 통해 기술 부채가 사업 가치에 얼마나 큰 영향을 미치는지를 파악할 수 있게 되고 그렇게 되면 자연스럽게 변제를 위한 작업의 우선순위도 올라가게 될 것입니다. 기술 부채를 계산하는 방법과 이자 추적을 어떻게 할지는 프로젝트마다 다르겠지만, 추적해야 한다는 사실 만큼은 어떤 프로젝트에서든 동일합니다.

기술 부채는 가능한 한 빨리 갚으세요. 분별 있는 사람이라면 당연히 그럴 겁니다.