기술 부채(Tech Debt), 제대로 알고 계신가요?

안녕하세요, Devloo입니다. 🙂 오늘은 기술 부채에 대해 이야기해보려고 합니다.

제가 함께 일했던 모든 팀은 기술 부채에 대해 고민해왔습니다. 어떤 팀은 이를 잘 관리했지만, 몇몇 팀은 기술 부채로 인해 큰 어려움을 겪었고 이를 해결하기 위해 많은 리소스를 쏟아부었습니다.

이번 시간에는 이러한 기술 부채가 무엇인지, 어떻게 발생하는지, 그리고 이에 대한 일반적인 오해들에 대해 알아보겠습니다.

기술 부채란 무엇인가요?

“기술 부채는 제품 개발 작업 환경이 얼마나 혼란스럽거나 낡아 있는지를 나타내는 지표입니다.”

— 데이브 스미스

‘부채’라는 비유는 매우 적절한 표현입니다. 이 비유를 처음 사용한 엔지니어는 이렇게 설명했습니다:

“돈을 빌리면 평소보다 더 빨리 어떤 일을 할 수 있지만, 그 돈을 갚기 전까지는 이자를 지불해야 합니다. 저는 돈을 빌리는 것이 좋은 생각이라고 생각했습니다. 소프트웨어를 서둘러 출시해서 경험을 쌓는 것이 좋은 생각이라고 생각했지만, 나중에 그 소프트웨어에 대해 알게 된 것들을 반영하여 프로그램을 리팩토링함으로써 그 부채를 갚을 것이라고 생각했습니다.”

— 워드 커닝햄

기술 부채가 어떻게 발생하는지 알아보겠습니다. 하지만 먼저 기술 부채의 원인과 성격에 대한 몇 가지 일반적인 오해를 이해하는 것이 중요합니다.

오해 1: “기술 부채” == 나쁜 코드

도대체 “나쁜 코드”란 무엇일까요? 좋은 코드는 아마도 깨끗한 코드일 것입니다. 이는 미래에 특정 결정을 강요하지 않고, 선택의 여지를 남겨두는 코드로 요약할 수 있습니다. 반면 나쁜 코드는 선택의 여지를 주지 않고, 그렇지 않았으면 필요 없었을 구현 제약을 강요합니다.

저는 거의 “나쁜 코드”가 “나쁜 개발자”에게서 나오는 것을 본 적이 없습니다. 적어도 실제 프로젝트에서는 그렇습니다. (그것이 코드 리뷰의 목적이니까요.) 제가 마주치는 대부분의 “나쁜 코드”는 제약 속에서 일하는 좋은 개발자에게서 나옵니다.

오해 2: 기술 부채는 잘못된 것이다

기술 부채는 재정적 부채처럼 “잘못된 것”이 아닙니다. 이상적이지는 않지만, 제품을 만들 때 사용할 수 있는 유효한 도구입니다.

오해 3: 한 번 개발하면 끝이다

이 오해는 소프트웨어가 건축과 비슷하다는 생각에서 비롯된 것 같습니다. 건축에서 (그리고 이 비유에서) 작업은 순차적으로 진행됩니다:

1. 건축가가 건물을 설계하고, 설계도를 전달합니다.
2. 작업자들이 기초를 다지고, 벽을 세우고, 전기와 배관을 설치하며, 가구를 놓습니다.
3. 세입자들이 이사해 행복하게 생활합니다. 문제가 생기면 유지 보수팀을 부를 것입니다.

이 비유는 이해하기 쉽습니다. 그러나 소프트웨어에는 적용되지 않습니다.

소프트웨어는 건축보다는 정원 가꾸기에 더 가깝습니다. 정원은 고정된 것이 아니라 살아 숨쉬는 존재입니다. 초기 계획과 조건에 맞춰 여러 식물을 심지만, 어떤 식물은 잘 자라고, 어떤 것은 결국 퇴비가 됩니다. 햇빛과 그늘, 바람과 비의 조화를 고려해 식물들의 위치를 옮기기도 합니다. 너무 자란 식물은 나눠 심거나 가지치기를 하고, 어울리지 않는 색의 식물은 더 보기 좋은 위치로 옮깁니다. 잡초를 뽑고, 도움이 필요한 식물에는 비료를 줍니다. 끊임없이 정원의 상태를 살피고, 필요에 따라 토양, 식물, 배치를 조정합니다.

— 실용주의 프로그래머

건설에 대한 비유에서는 대부분의 비용이 초기에 발생합니다. 유지 보수 비용은 거의 명목상에 불과하거나, 우연한 단발성 비용으로 무시되곤 합니다.

하지만 정원 가꾸기 비유에서는 어떤 기능을 만드는 것이 단순한 첫 걸음에 불과합니다. 작물을 심는 것처럼 긴 작업의 일환입니다. 정원이 커질수록 더 많은 유지 보수가 필요합니다. 이는 레이아웃을 변경하기 위해 다시 심는 작업(리팩토링)이나 정원을 확장하고 새로운 작물을 심는 작업(새로운 기능 추가 – 이것도 유지 보수가 필요함) 외에도 많은 일이 포함됩니다.

소프트웨어의 전체 비용 중 90%가 유지 보수와 관련되어 있습니다. 이 지표를 오랫동안 알고 있었지만, 여전히 생각할 때마다 놀라움을 금할 수 없습니다.

어떻게 이런 상황에 빠지게 되었을까?

기술 부채는 도대체 어디에서 오는 것일까? 그리고 그것을 피할 수 있을까?

기술 부채를 이렇게 정의할 수도 있습니다: 프로젝트가 현재 위치한 상태와 우리가 그동안 쌓아온 지식을 바탕으로 처음부터 다시 시작했을 때 도달할 수 있는 이상적인 상태 사이의 차이.

기술 부채는 두 가지 원인에서 발생합니다:

1. 트레이드오프에 대한 결정. 기술 부채의 성격을 잘 이해하고 신중하게 결정하는 것이, 이를 고려하지 않은 채 성급하게 결정하는 것보다 더 바람직합니다.
2. 설계와 구현에 대한 결정을 내릴 때의 지식(또는 지식의 부족).

결정을 내릴 때 모든 정보를 완벽하게 알고 제약 조건을 맞추기 위해 타협하지 않는 것이 이상적입니다. 그러나 현실에서는 전체 프로그램의 구현 방법을 완전히 알지 못한 채 프로젝트를 시작하게 됩니다. 또한 이해관계자의 마감 기한이나 비용 제한 등의 제약 조건에 따라 타협을 해야 할 때도 있습니다.

이 과정에서 기술 부채를 피하는 방법에 대해 배울 수 있는 교훈이 있습니다. 이에 대한 자세한 내용은 후속 글에서 다루겠습니다. “기술 부채를 피할 수 있는가?”라는 질문에 대한 간단한 답변은 “네, 하지만 부채는 도구일 뿐, 적이 아닙니다.”입니다.

기술 부채를 정량화하기

“기술 부채가 얼마나 있나요?” 모든 기술 부채. 이렇게 추상적인 개념을 정말로 수치화할 수 있을까요?

좋은 기술 백로그는 결국 갚아야 할 일부 기술 부채를 추적할 것입니다. (백로그에서 해결되지 않고 사라진 기술 부채 티켓을 실제로 많이 봤습니다.) 이것은 갚아야 할 특정 부채를 식별하는 데 도움이 될 수 있지만, 팀에 미치는 기술 부채의 전체적인 영향을 정확하게 수량화하는 방법은 아닙니다.

(가) 정량화할 수 있고 (나) 기술 부채와 높은 상관관계를 갖는 다른 지표가 있습니다: 유지 보수 부하(Maintenance Load) 입니다.

유지 보수 부하(Maintenance Load)는 개발 팀이 기존 기능을 이전과 동일하게 유지하기 위해 얼마나 많은 노력을 기울이는지를 나타냅니다. 이는 코드의 품질보다 기술 부채를 측정하는 데 더 유용한 지표입니다. 유지 보수 부하는 프로젝트의 연령과 구축된 방식에 따라 달라집니다. 단위는 지속적인 개발자 노력입니다.

— 첼시 트로이

여기서 분명히 하고 싶은 것은, 유지 보수 부하가 기술 부채와 동일하지 않다는 것입니다. 그러나 유지 보수 부하는 시스템 내 기술 부채의 양과 그것이 팀에 미치는 영향을 대략적으로 파악할 수 있는 좋은 지표입니다. 시스템이 무너지지 않도록 하기 위해 더 많은 엔지니어가 필요하다면, 아마도 많은 기술 부채를 가지고 있을 가능성이 큽니다. 반면에, 소수의 인원으로 1000억원 매출의 회사를 구축할 수 있다면, 기술 부채를 잘 관리하고 있는 것입니다.

결론

기술 부채는 피할 수 없는 현실이지만, 제대로 관리하면 프로젝트 성공의 중요한 도구가 될 수 있습니다. 기술 부채를 완전히 없앨 수는 없지만, 이를 인식하고 체계적으로 관리하는 것이 중요합니다.

기술 부채를 효과적으로 관리하기 위해 다음과 같은 방법을 추천드립니다:

1. 정기적인 코드 리뷰: 팀 내에서 정기적으로 코드 리뷰를 통해 기술 부채를 미리 방지하고, 발생한 부채를 빠르게 해결합니다.
2. 리팩토링 시간 확보: 주기적으로 리팩토링 시간을 마련하여 기술 부채를 갚아 나갑니다.
3. 우선순위 설정: 중요한 기능과 기술 부채를 균형 있게 처리하기 위해 우선순위를 설정합니다.
4. 지속적인 학습: 팀원들이 최신 기술과 방법론을 꾸준히 학습하여 기술 부채를 줄여나갑니다.

기술 부채를 잘 관리하여 프로젝트를 성공으로 이끄는 여러분이 되시길 바랍니다. 더 자세한 내용은 다음 글에서 다루겠습니다.

끝까지 읽어주셔서 감사합니다 ~!! 궁금하신 사항은 댓글로 편하게 남겨주세요 🙂