😓 기술부채(technical debt)에 관하여

최근 프로젝트를 진행하면서, 순간의 편의를 위해 소홀히 다룬 일이 기술 부채(technical debt)로 환원되는 경험을 했습니다. 😓 오늘은 이 기술부채에 대하여 여러분과 얘기를 해보려 합니다. ✅ 기술부채(technical debt)의 정의 '기술 부채'라는 용어는 1992년 컴퓨터 과학자인 워드 커닝햄(Ward Cunningham)이 처음 사용했습니다. 이 용어는 금융부채와 비슷한 개념으로 기술부채가 시간이 지날수록 점점 해결하기 어려운 난제가 되고, 미래에 선택할수 있는 옵션을 줄인다는 것입니다. 어느새 이자가 제3금융권, 고리대금 이자만큼 붙어서 갚으려면 종전의 리소스를 압도하는 상황을 맞이 할수 있게 되는거죠. 2009년, 소프트웨어 개발의 구루 마틴 파울러(Martin Fowler)는 기술 부채에 대해 이렇게 언급했습니다. "일을 성급하게 지저분하게 처리하면 기술 부채가 쌓이는데, 이는 금융 부채와 비슷하다. 금융 부채처럼 이자를 지불해야 하고, 결국 나중에 개발해야만 하는 추가적 업무의 형태로 남는다" 2018년 스트라이프(Stripe)의 개발자 계수(Developer Coefficient) 보고서에 따르면, 소프트웨어 개발자가 기술 부채를 해결하는데 일주일에 평균 13시간 이상을 소비한다고 합니다. 정말 어마어마하죠.😲 기술 부채는 여러 가지 유형으로 나타납니다. 📊 일반적으로 다음 6가지로 분류될 수 있으며, 이들은 서로 복합적으로 발생할 수 있습니다. ▶️ 기술부채 유형들 ------------------------------- 1. Developer efficiency debt(개발자 효율성 부채) 2. Stability debt (안정성 부채) 3. Security debt(보안 부채) 4. Technical product debt(기술 제품 부채) 5. Decision debt(의사 결정 부채) 6. Maintenance debt(유지 관리 부채) (*참고: https://www.reforge.com/blog/managing-tech-debt) 그렇다면 기술 부채를 어떻게 줄일 수 있을까요? 💡우리가 이미 알고 있는 방법들이 답입니다. 1️⃣ 복리 이자가 붙기 전에 조금씩 상환하기 : 코드 리팩토링, 아키텍쳐 개선을 진행하면서, 복리 이자가 붙지 않도록 지속적으로 개선해 나갑니다. 지속해서 기술 부채를 상환한다면 큰 고통에 시달리지 않겠죠. 2️⃣. 기술 부채의 중요도와 우선 순위를 설정하여 상환하기 : 중대한 문제가 될수 있는 가능성이 있는지, 비즈니스에 미칠수 있는 영향, 사용자 경험에 미칠수 있는 영향 등을 고려하여 우선순위를 정리하여 하나씩 갚아나갑니다. 3️⃣ 기술 부채를 줄일 수 있는 도구와 절차 도입하기 : 테스트 자동화, 코드 리뷰 등을 통해 기술 부채가 쌓이는 것을 최소화합니다. 🤔 🤔 🤔 사실, 기술 부채는 소프트웨어 개발의 불가피한 측면입니다. 시간이 지나면서 사업의 요구사항이 변하고, 기술은 지속적으로 발전하고 개선되기 때문입니다. 이러한 변화에 따라 기존의 코드나 아키텍처가 더 이상 적합하지 않게 될 수 있습니다. 그러나 이는 결코 소홀히 해도 좋은 이유가 아닙니다. 오히려 이런 변화가 빈번하게 일어나는 환경에서 더욱 체계적이고 신중한 관리가 필요합니다. 지속적으로 누적되는 기술 부채를 관리하고 감소시키는 것은 기술 팀의 중요한 역할이며, 이를 통해 더욱 효율적인 프로젝트 관리와 제품 품질 향상을 이루어낼 수 있습니다. 💪🏻🚀 📚 References: https://www.itworld.co.kr/insider/238829 https://stripe.com/files/reports/the-developer-coefficient.pdf https://johngrib.github.io/wiki/technical-debt/ https://brunch.co.kr/@jowlee/168