안녕하세요. 인포그랩 프로덕트 팀에서 백엔드 엔지니어로 근무하는 Andy입니다. 프로젝트를 진행하다 보면 여러 가지 이유로 기술 부채가 쌓이는데요. 기술 부채를 어감상 부정적으로 생각하기 쉽지만 모든 기술 부채가 나쁜 건 아닙니다. 이를 잘 관리하면 개발을 진전시키는 데 도움이 되죠. 그러나 기술 부채를 잘 관리하지 못하면 개발 생산성과 비즈니스에 부정적 영향을 미칠 수 있는데요. 따라서 평소 기술 부채 특징과 관련 모범 관행을 학습하는 건 매우 중요합니다. 이 글에서는 기술 부채 개념과 유형, 해결 방법을 살펴보고, 인포그랩 프로덕트 팀의 기술 부채 관리 방식을 소개하겠습니다.
기술 부채 개념과 유형
‘기술 부채(Technical Debt)’ 용어 정의는 1992년 컴퓨터 프로그래머 워드 커닝햄이 고안했습니다. 이는 ‘시간이 더 걸릴 수 있는 더 나은 접근 방식을 취하는 대신 쉽지만 제한된 솔루션을 선택할 때 필요한, 향후 재작업 의 암묵적 비용’입니다. 또는 ‘가장 효과적인 솔루션이 아닌 가장 빠른 솔루션을 선택하면서 발생한 추가 작업 비용’을 뜻하기도 하죠.
소프트웨어 엔지니어인 크리스 리코미니, 드미트리 리아보이는 『필독! 개발자 온보딩 가이드: 지속 가능한 소프트웨어와 원활한 협업 문화를 이해하는 프로페셔널 개발자의 탄생』에서 기술 부채를 이렇게도 설명합니다.
금융 부채와 마찬가지로 기술 부채에도 원금과 이자가 있다. 원금은 수정해야 할 원래의 단점을 의미한다. 이자는 본질적인 단점을 수정하지 않고 코드를 개선할 때 발생하는 비용을 뜻하며, 차선책을 택해 구현하면서 점차 복잡도가 올라가는 것을 의미한다. 이와 같은 차선책이 계속 복제되고 자리를 잡다 보면 이자도 더 늘어난다. 점점 더 많은 코드가 복잡해지고 결함도 생겨난다.
기술 부채 개념은 시간이 지나면서 더 구체화됐는데요. 2009년 소프트웨어 엔지니어 마틴 파울러는 기술 부채를 2차원 매트릭스로 설명하며, 아래 그림과 같이 유형을 구분했습니다.
![마틴 파울러의 기술 부채 2차원 매트릭스. 출처=마틴 파울러 홈페이지 | 인포그랩 GitLab](https://cdn.infograb.io/insight_prod/image/blog/2024-06/2024-06-05-technical-debt-return-0.png)
위 그림을 보면 다음과 같은 기준이 있죠.
- Reckless(신중하지 못한), Prudent(신중한)
- Inadvertent(의도하지 않은), Deliberate(의도적인)
위 기준을 중심으로 4가지 기술 부채 유형 을 자세히 알아보겠습니다.
1. 신중하고 의도적인 기술 부채(Prudent & Deliberate)
이는 팀이 부채를 지고 있다는 걸 알지만 ‘더 빠른 출시 보상이 부채 상환 비용보다 더 큰지’ 여부를 고려한 건데요. 이러한 기술 부채는 개발 속도와 출시일의 트레이드오프를 신중히 고려한, 실용적인 결과입니다. 보편적으로 발생하는 기술 부채 유형이기도 하고요. 신중하고 의도적인 기술 부채는 위 그림에서 “We must ship now and deal with consequences(지금 출시하고, 결과를 처리해야 한다)”에 해당합니다.
2. 신중하지 못하고, 의도적인 기술 부채(Reckless & Deliberate)
이는 좋은 설계 관행을 알고, 실천할 수 있지만 깔끔한 코드를 작성할 시간이 없어 ‘빠르고 지저분하게’ 진행하기로 한 결과인데요. 이러한 기술 부채는 팀이 출시일 압박을 받을 때 생기고요. 고객의 긴급한 요구사항을 맞춰야 할 때, 예기치 못한 장애로 기능을 급히 수정해야 할 때 충분한 설계 없이 개발하다 이 부채가 발생할 수도 있습니다. 신중하지 못하고, 의도적인 기술 부채는 위 그림에서 “We don’t have time for design(설계할 시간이 없다)”에 해당합니다.
3. 신중하되, 의도하지 않은 기술 부채(Prudent & Inadvertent)
이는 좋은 소프트웨어를 개발했고, 코드도 깔끔했지만 시간이 지나서야 ‘설계가 어땠어야 한다’는 걸 깨달은 결과입니다. 이러한 기술 부채는 성장 과정에서 자연스럽게 나타나죠. 예를 들어, 웹 애플리케이션을 개발할 때, 초기 설계 단계에서 모든 데이터를 단일 데이터베이스(DB)에 저장하도록 구현했는데요. 당시에 최적의 선택이었더라도 나중에 DB 부하가 커져 분산 DB로 전환해야 하면 이 부채가 생긴 걸로 볼 수 있습니다. 신중하되, 의도하지 않은 기술 부채는 위 그림에서 “Now we know how we should have done it(‘우리가 어떻게 해야 했는지’ 이제 알겠다)”에 해당합니다.
4. 신중하지 못하되, 의도하지 않은 기술 부채(Reckless & Inadvertent)
이는 잘 몰라서 발생한 결과인데요. 위 그림에서 “What’s layering?(계층화가 뭐야?)”에 해당합니다.
기술 부채 해결 방법
![출처=픽사베이 | 인포그랩 GitLab](https://cdn.infograb.io/insight_prod/image/blog/2024-06/2024-06-05-technical-debt-return-1.png)
기술 부채가 항상 나쁜 건 아닙니다. 크리스 리코미니, 드미트리 리아보이는 『필독! 개발자 온보딩 가이드: 지속 가능한 소프트웨어와 원활한 협업 문화를 이해하는 프로페셔널 개발자의 탄생』에서 “나중에라도 팀이 해결 가능하도록 훈련된 부채라면 이는 ‘좋은 부채’라 할 수 있다”고 설명하죠. 아울러 기술 부채를 적절히 관리하면 개발을 진전시키는 데 도움이 됩니다.
그러나 기술 부채는 비즈니스에 부정적 영향을 미칠 수 있으므로 해결해야 하는데요. 이는 버그로 나타나 사용자 경험을 저하할 수 있습니다. 아울러 기술 부채가 악화하면, 개발자가 기존 코드베이스 안에서 작업하기 더 힘들어지고요. 새로운 기능을 개발하고, 기존 기능을 수정하는 데 시간을 쪼개어 쓰느라 소프트웨어 개발 라이프사이클이 느려지고, 시장 출시 시기가 미뤄질 수 있죠. 그렇다면 기술 부채를 어떻게 관리, 해결하면 좋을까요?
(아래 내용은 미국 소프트웨어 기업 Asana, 크리스 리코미니와 드미트 리 리아보이 저서 『필독! 개발자 온보딩 가이드: 지속 가능한 소프트웨어와 원활한 협업 문화를 이해하는 프로페셔널 개발자의 탄생』, 웹 개발자 출신이자 캐나다 웹 디자인 기업 Norlink 대표 리앤 민튼의 Splunk 기고 글, 래티스 주식회사 공동 창업자이자 CPO 이재하 님(필명 ‘호박너구리’)의 요즘 IT 기고 글에서 제언한 방법을 모아 정리했습니다.)
1. 기술 부채 목록 관리
프로젝트를 회고해 기술 부채를 목록으로 정리, 공유합니다. 아울러 기술 부채가 발생할 때마다, 이 부채를 해결하는 데 필요한 작업을 예상되는 노력, 일정과 함께 기록하고요. 또 팀에서 기술 부채 해결 여부와 해결 시점을 논의하고, 해결 방안을 수립합니다. 이는 기술 부채를 계획적으로 해결하는 데 도움이 됩니다. 한편, 90일 이상 해결되지 않은 기술 부채는 ‘중요한 부채’로 취급해야 하고요.
2. 좋은 기술 부채와 나쁜 기술 부채 구분
좋은 기술 부채와 나쁜 기술 부채를 구분합니다. 이렇게 기술 부채를 구분하면 가장 큰 문제의 우선순위를 정하는 데 도움이 되죠. 참고로 기술 부채 때문에 애플리케이션이 장애를 일으키거나 보안 결함이 노출되면, 이러한 문제를 먼저 해결해야 합니다.
3. 리팩토링
업무를 수행하면서 필요한 부분을 정리하고 조금씩 리팩토링합니다. 간혹 대규모로 리팩토링해야 할 때도 있는데요. 이때 팀에 상황을 공유하고 기술 부채 위험과 비용을 알립니다. 또 해결책을 제안하고, 함께 대안을 논의하며 트레이드오프를 따져보고요.
4. 테스트 코드 작성
코드가 복잡할수록, 리팩토링 규모가 클수록 버그 없이 코드를 한 번에 수정하기란 어렵습니다. 부작용을 방지하려면 테스트 코드를 작성해야 하는데요. 리팩토링하고 테스트 코드를 실행했을 때 문제가 있으면 그 부분만 수정하면 됩니다. 이로써 리팩토링을 안전하게 진행할 수 있죠.
5. 품질 표준 설정, 준수
품질 표준을 설정해 코더가 엉성한 코드를 배포하지 못하도록 합니다. 그러면 우발적인 기술 부채를 더 쉽게 피할 수 있고요. 기술 부채를 더 용이하게 관리할 수 있습니다.