기술적 채무(technical dept)에 관해서

기술적 채무(Technical Dept)

기술적 채무(Technical Dept) 란 무엇인가

오늘은 기술적 채무(Technical Dept)에 대한 짧은 생각을 가볍게 적어볼까 한다. 많이들 쓰는 얘기인 것 같긴 하지만 나는 몇 년 전 아마존에서 근무했던 개발자가 집필한 책에서 처음 접했다. 기술적 채무는 본질적인, 혹은 더 좋은 방식의 해결책을 미루고 당장에 빠르게 쉽게 처리하는 것을 의미한다.

SI 에 만연한 기술적 채무의 원인

나도 현재 SI 업계에서 일하고 있으며 이러한 기술적 채무들을 수없이 보았다. 인지했던 경우도 있고 아닌 경우도 있겠지만 나 역시도 일조했으리라 생각한다.

개인적인 경험에서 보자면 원인은 크게 두 가지인 것 같다.

1. 일정의 빠듯함
   

사실 시작 단계부터 일정이 빠듯하게 잡히는 경우는 드문 것 같다. 그러나 중간에 끼어드는 추가 요구사항, 기반마저 흔들려 드는 요건의 변경들이 쌓이면서 후반부로 갔음에도 되려 일이 줄어들지 않고 늘어나는 경우가 다반사였다.

애자일 방법론을 제대로 경험해 본 적은 없어서 어떤 것이 좋은가를 평가해볼 수는 없지만, 워터폴 방식의 진행에서도 최소한 기획 혹은 디자인까지 완성된 시점에서 단위 테스트(Unit Test)와 통합 테스트(Integration) 수준의 무언가가 이루어져야 한다고 생각한다. 디자인까지를 중단점으로 본 것은 고객으로서도 시각적인 결과물 없이는 세세한 요건에 관한 판단이 어렵다고 생각했기 때문이다.

그리고 여기까지를 합의점으로 보고 보안적 이슈가 아닌 이상 요건의 추가 및 변경은 최대한 지양해야 한다고 생각한다.¹

본론으로 돌아와서 많은 개발자가 이런 일정 속에서 우선 눈에 보이도록 대충 빠르게 처리하려 하면서 기술적 채무가 쌓인다고 본다. 고객이 원하는 것 역시 결과물이고 과정은 서비스에 이슈가 없는 한 상관없기 때문이다. 유지보수, 운영도 어차피 맡기면 된다.

2. 개발자의 나태와 실력 부족, 혹은 회의감
   

팀원들의 코드를 전부는 아니더라도 어느 정도 일일이 들여다보고 피드백을 해주는 PL들도 있었다. 그러나 본인의 업무도 바쁘거나 드러나는 이슈만 없다면 상관없다고 생각하는 리더들도 많다.²

그리고 심지어는 버그일지라도 들키면 하겠다는 개발자들도 제법 많이 봤다. 실력이 많이 부족한 사람들도 있었고 실력은 있으나 귀찮아서, 아니면 1. 일정의 빠듯함에서 언급했던 이유에 상처받고 지쳐서 의미 없다고 말하는 이들도 있었다.

물론, 지금 얘기하는 것들은 모두 기술적 채무가 쌓이는 경우를 뜻하며 실력 있고 책임감 있는 개발자들, 실력은 아직 부족하지만 책임감 있고 자기 발전을 위해 노력하는 개발자들도 많이 봤다.

그리고 원인을 두 가지로 나누어 얘기했지만 꼭 단편적으로만 판단할 일도 아니라고 생각한다.

빚을 지는 것은 무조건 나쁜 것일까?

빚을 지지 않거나 바로 갚아나가는 것이 좋다는 것은 누구나 동의할 것이다.

기술적 채무가 아닌 현실적인 빚을 생각해보자. 과거 우리나라의 금리는 두 자릿수였다. 2000년대에도 4%대를 웃돌았고 불과 10년 전에도 3% 정도였다. 최근 금리의 급격한 상승으로 근접하고 있지만 아직은 약 0.5%P 이상 낮다.

이러한 금리의 차이는 대출에 대한 인식의 변화로도 이어지는데 대출을 끼고 집을 사거나 전세를 들어가는데 거부감이 사라졌다는 것이다. 기술적 채무도 같은 의미에서 생각해보면 영향이 크지 않다면 그렇게 나쁘지도, 꼭 문제 되지도 않는다고 생각한다. 우리가 유한한 시간 내에서 프로젝트를 수행해야 되기 때문이다.

그래서 내가 생각하기에 중요한 것은 기술적 채무의 영향도를 파악할 수 있는 실력이나, 그 수준을 감당할 수 있는 정도(감당 가능한 대출 이자)로 맞추는 노력이라고 본다.

채무 불이행의 과정과 결과

채무 불이행의 결과는 갈수록 복잡하게 얽혀있는 코드나 예기치 못한 잠재적 이슈가 되어 돌아온다. 특히나 다른 사람의 코드라면 사이드 이펙트를 최소화하기 위해서라던가 복잡한 구조의 파악이 어려워서라는 이유로 채무를 추가로 얹는 경우도 많다.

또한 프로젝트에서는 깨진 유리창의 법칙(broken windows theory)³이 쉽게 적용되는 것 같다. 소신을 지키던 사람들도 일정에 치이다가 다른 사람들 코드를 보며 타협하기도 하고, 주위에서 대충 마무리하라고 하거나 그럴 시간에 이거나 하라며 추가 업무를 던져준다면 회의감이 들어 그들과 같은 길을 가기도 한다.

하지만 감당할 수 없는 채무는 부메랑처럼 반드시 돌아와 뒤통수를 친다. 다행(?)인 것은 내가 날린 부메랑에 내가 맞지 않을 수 있다는 것이고, 불행인 것은 타인이 날린 부메랑에 내가 맞을 수 있다는 사실이다.

마무리

그때그때 체력이 허락하는 선에서 공부해서 채무를 남기지 않는다면 나에게 큰 자산이 된다고 본다. 급변하는 환경과 도구들 속에서 어느 정도의 선은 있겠지만 그 과정들이 나중에는 빨라질 것이고 선을 가늠하는 눈도 기를 수 있다.

그리고 당장 프로젝트가 조금 길어져도 대부분 본인의 코드가 낯설거나 유지보수의 불편함을 경험해 볼 수 있다는 점에서 좋은 코드를 남기려고 노력해야 한다고 생각한다. 이 또한 습관으로 자리 잡아 성장의 자양분이 된다고 믿는다.