더 이상 기술 부채를 변명이나 구실로 사용해서는 안 된다.

‘기술 부채’라는 용어는 미국 프로그래머 워드 커닝햄이 만든 의미가 명확한 말이다. 커닝햄이 말한 기술 부채란, 더 바르고 올바른 방법이 존재함을 알면서도, 일단 속도를 내기 위해 덜 바람직한 방법을 선택하는 의도적인 결정이었다. 이 결정은 단기적으로는 빠른 개발을 장려하지만, 장기적으로는 버그와 유지보수의 어려움이라는 비용을 낳는다. 이러한 선택은 애초에 나중에 ‘빚을 갚겠다’는 전제 하에 이루어진다. 다시 말해, 의도적으로 만든 열악한 코드에는 반드시 열악함을 개선하려는 티켓 같은 구체적인 계획이 백로그에 있어야만 ‘기술 부채’라고 부를 수 있다.

그러나 솔직해지자. 이제 이 용어는 너무 왜곡돼서 본래의 의미를 잃었다. 지금 코드 저장소에 들어 있는 온갖 엉망진창의 코드가 정말로 기술 부채일까? 말은 그렇게 하지만, 그중 의도적으로 만들어진 것은 과연 얼마나 되고, 실제로 고칠 계획이 있는 것은 몇 퍼센트일까? 아마 거의 없을 것이다.

기술 부채 아닌 기술 부채

기술 부채라는 단어는 이제 “우리 회사 시스템에 있는 형편없는 코드 중, 너무 비용이 많이 들고 위험해서 다시는 고치지 않겠지만 그냥 내버려 둔 코드”를 의미하게 됐다. 이처럼 문제 많은 코드의 원인은 다음 3가지로 요약된다.

1. 진짜 기술 부채
   개발팀이 코드가 수준 이하임을 인지하고도 타당한 이유로 빠른 길을 택한 경우다. 다만 이는 어디까지나 이를 수정하기 위한 계획이 있는 경우에만 해당된다. 하지만 현실에서 이런 유형의 코드는 드물다. 실제로 기술 부채를 갚기 위한 구체적인 계획을 갖고 있는 개발팀이 얼마나 될까? 많지 않다.
2. 우연히 생긴 복잡성(Accidental Complexity)
   튜링상을 수상한 컴퓨터 과학자 프레드 브룩스가 만든 용어로, 실력이 부족하거나 부주의해서가 아니라 단지 시스템에 대한 이해가 부족해 잘못된 판단을 내린 결과다. 예를 들어, 과도하게 무거운 프레임워크를 선택했거나, 시스템 전체의 방향과 어긋나는 방식으로 기능을 추가한 경우다. 대체로 한참 시간이 흐른 뒤에야 문제가 드러난다.
3. 그냥 나쁜 코드
   기술 부채로 불리는 코드 상당수는 사실 대충 급히 짜놓은 코드다. 리뷰조차 제대로 이뤄지지 않았거나, 고객의 불만을 급하게 처리해야 했다는 이유로 ‘일단 작동만 하면 된다’는 식으로 넘어간 경우다. 주말에 체크인된 긴급 버그 픽스, 시간과 명확한 지시, 지원 없이 작성된 코드 등도 여기에 포함된다.

그럴듯한 포장일 뿐

문제는 이런 모든 문제 코드를 ‘기술 부채’라는 그럴듯한 용어로 포장하면서, 피할 수 있었던 문제들을 정당화하기 쉽다는 점이다. 잘못된 선택을 하면서도 이름만 멋지게 바꿔서 ‘나중에 고치겠다’고 둘러댄다. 하지만 모두 절대 문제를 고치지 않을 것을 알고 있지 않은가? 개발팀이 기술 부채라는 용어를 써서 잘못된 작업 방식을 정당화하게끔 허용하는 순간, 기업의 개발 문화는 쇠퇴하기 시작한다.

또한, 기술 부채라는 말로 모든 문제를 뭉뚱그리면 엔지니어링에 대한 투자 부족이나 지속적인 과도한 일정 압박 등 더욱 근본적인 문제를 볼 수 없게 된다. 단지 잘못된 코드가 아니라, 조직 문화와 리더십의 실패일 수도 있다는 점이 가려지는 것이다.

정확히 부르자

이제 그만하자. 수정 계획 없이 코드가 형편없다는 이유로 ‘기술 부채’라고 부르는 일을 멈추자. 진짜 기술 부채는 반드시 작업 티켓, 수정 계획, 기한이 명확해야 한다. 그 외의 모든 것은 사실 기술 부채가 아니다. 그냥 부패한 코드(code rot) 이상도 이하도 아니다.

모두가 진짜 기술 부채와 그렇지 않은 문제를 구분할 수 있는 문화를 만들어야 한다. 의식적인 절충과 수정할 계획이 명확한 코드만을 기술 부채라 부르자. 그 외의 코드에 더는 면죄부를 주지 말자. 나쁜 코드는 그냥 나쁜 코드일 뿐이다.
dl-itworldkorea@foundryco.com