안녕하세요. 인포그랩 프로덕트 팀에서 백엔드 엔지니어로 근무하는 Andy입니다. 프로젝트를 진행하다 보면 여러 가지 이유로 기술 부채가 쌓이는데요. 기술 부채를 어감상 부정적으로 생각하기 쉽지만 모든 기술 부채가 나쁜 건 아닙니다. 이를 잘 관리하면 개발을 진전시키는 데 도움이 되죠. 그러나 기술 부채를 잘 관리하지 못하면 개발 생산성과 비즈니스에 부정적 영향을 미칠 수 있는데요. 따라서 평소 기술 부채 특징과 관련 모범 관행을 학습하는 건 매우 중요합니다. 이 글에서는 기술 부채 개념과 유형, 해결 방법을 살펴보고, 인포그랩 프로덕트 팀의 기술 부채 관리 방식을 소개하겠습니다.
기술 부채 개념과 유형
‘기술 부채(Technical Debt)’ 용어 정의는 1992년 컴퓨터 프로그래머 워드 커닝햄이 고안했습니다. 이 는 ‘시간이 더 걸릴 수 있는 더 나은 접근 방식을 취하는 대신 쉽지만 제한된 솔루션을 선택할 때 필요한, 향후 재작업의 암묵적 비용’입니다. 또는 ‘가장 효과적인 솔루션이 아닌 가장 빠른 솔루션을 선택하면서 발생한 추가 작업 비용’을 뜻하기도 하죠.
소프트웨어 엔지니어인 크리스 리코미니, 드미트리 리아보이는 『필독! 개발자 온보딩 가이드: 지속 가능한 소프트웨어와 원활한 협업 문화를 이해하는 프로페셔널 개발자의 탄생』에서 기술 부채를 이렇게도 설명합니다.
금융 부채와 마찬가지로 기술 부채에도 원금과 이자가 있다. 원금은 수정해야 할 원래의 단점을 의미한다. 이자는 본질적인 단점을 수정하지 않고 코드를 개선할 때 발생하는 비용을 뜻하며, 차선책을 택해 구현하면서 점차 복잡도가 올라가는 것을 의미한다. 이와 같은 차선책이 계속 복제되고 자리를 잡다 보면 이자도 더 늘어난다. 점점 더 많은 코드가 복잡해지고 결함도 생겨난다.
기술 부채 개념은 시간이 지나면서 더 구체화됐는데요. 2009년 소프트웨어 엔지니어 마틴 파울러는 기술 부채를 2차원 매트릭스로 설명하며, 아래 그림과 같이 유형을 구분했습니다.
위 그림을 보면 다음과 같은 기준이 있죠.
- 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?(계층화가 뭐야?)”에 해당합니다.
기술 부채 해결 방법
기술 부채가 항상 나쁜 건 아닙니다. 크리스 리코미니, 드미트리 리아보이는 『필독! 개발자 온보딩 가이드: 지속 가능한 소프트웨어와 원활한 협업 문화를 이해하는 프로페셔널 개발자의 탄생』에서 “나중에라도 팀이 해결 가능하도록 훈련된 부채라면 이는 ‘좋은 부채’라 할 수 있다”고 설명하죠. 아울러 기술 부채를 적절히 관리하면 개발을 진전시키는 데 도움이 됩니다.
그러나 기술 부채는 비즈니스에 부정적 영향을 미칠 수 있으므로 해결해야 하는데요. 이는 버그로 나타나 사용자 경험을 저하할 수 있습니다. 아울러 기술 부채가 악화하면, 개발자가 기존 코드베이스 안에서 작업하기 더 힘들어지고요. 새로운 기능을 개발하고, 기존 기능을 수정하는 데 시간을 쪼개어 쓰느라 소프트웨어 개발 라이프사이클이 느려지고, 시장 출시 시기가 미뤄질 수 있죠. 그렇 다면 기술 부채를 어떻게 관리, 해결하면 좋을까요?
(아래 내용은 미국 소프트웨어 기업 Asana, 크리스 리코미니와 드미트리 리아보이 저서 『필독! 개발자 온보딩 가이드: 지속 가능한 소프트웨어와 원활한 협업 문화를 이해하는 프로페셔널 개발자의 탄생』, 웹 개발자 출신이자 캐나다 웹 디자인 기업 Norlink 대표 리앤 민튼의 Splunk 기고 글, 래티스 주식회사 공동 창업자이자 CPO 이재하 님(필명 ‘호박너구리’)의 요즘 IT 기고 글에서 제언한 방법을 모아 정리했습니다.)
1. 기술 부채 목록 관리
프로젝트를 회고해 기술 부채를 목록으로 정리, 공유합니다. 아울러 기술 부채가 발생할 때마다, 이 부채를 해결하는 데 필요한 작업을 예상되는 노력, 일정과 함께 기록하고요. 또 팀에서 기술 부채 해결 여부와 해결 시점을 논의하고, 해결 방안을 수립합니다. 이는 기술 부채를 계획적으로 해결하는 데 도움이 됩니다. 한편, 90일 이상 해결되지 않은 기술 부채는 ‘중요한 부채’로 취급해야 하고요.
2. 좋은 기술 부채와 나쁜 기술 부채 구분
좋은 기술 부채와 나쁜 기술 부채를 구분합니다. 이렇게 기술 부채를 구분하면 가장 큰 문제 의 우선순위를 정하는 데 도움이 되죠. 참고로 기술 부채 때문에 애플리케이션이 장애를 일으키거나 보안 결함이 노출되면, 이러한 문제를 먼저 해결해야 합니다.
3. 리팩토링
업무를 수행하면서 필요한 부분을 정리하고 조금씩 리팩토링합니다. 간혹 대규모로 리팩토링해야 할 때도 있는데요. 이때 팀에 상황을 공유하고 기술 부채 위험과 비용을 알립니다. 또 해결책을 제안하고, 함께 대안을 논의하며 트레이드오프를 따져보고요.
4. 테스트 코드 작성
코드가 복잡할수록, 리팩토링 규모가 클수록 버그 없이 코드를 한 번에 수정하기란 어렵습니다. 부작용을 방지하려면 테스트 코드를 작성해야 하는데요. 리팩토링하고 테스트 코드를 실행했을 때 문제가 있으면 그 부분만 수정하면 됩니다. 이로써 리팩토링을 안전하게 진행할 수 있죠.
5. 품질 표준 설정, 준수
품질 표준을 설정해 코더가 엉성한 코드를 배포하지 못하도록 합니다. 그러면 우발적인 기술 부채를 더 쉽게 피할 수 있고요. 기술 부채를 더 용이하게 관리할 수 있습니다.
6. 갑작스러운 규정·일정 변경 X
개발자 관련 규정을 지속적으로 변경하거나, 마감일을 바꾸면 기술 부채를 피하기 어렵습니다. 현실적인 일정, 방법론, 작업량을 제공해 기술 부채를 관리할 수 있도록 합니다.
인포그랩 프로덕트 팀의 기술 부채 관리 방식
인포그랩 프로덕트 팀은 코드 리뷰, 리팩토링 기간 운영, 백로그 정리, 회고를 주기적으로 진행하며 기술 부채를 관리하는데요. 구체적인 내용을 각각 살펴보겠습니다.
1. 코드 리뷰
프로덕트 팀은 코드 리뷰를 두 가지 방식으로 진행합니다. 첫째, 개발이 완료되면 GitLab에서 해당 개발 건의 Merge Request(MR)를 활용해 리뷰를 받는데요. 이 과정에서 잘못된 도메인 선정을 지적하고, 코드를 더 깔끔하게 작성하도록 피드백하죠. 프로덕트 팀 소프트웨어 엔지니어들은 리뷰 내용을 반영해 문제를 개선하며 기술 부채를 해소합니다.
둘째, 팀 회의에서 코드를 공유하며 리뷰를 받습니다. 프로덕트 팀은 매주 두 차례 팀 회의를 진행하는데요. 이 자리에서 엔지니어들은 각자 발견한 새로운 기술이나 에러 사항 또는 코드 리팩토링 내용을 공유합니다. 이로써 자기가 작성한 코드를 논리적으로 설명하고요. 동료들의 피드백을 받아 문제를 바로 잡으며 기술 부채를 줄이죠.
2. 리팩토링 기간 운영
프로덕트 팀은 리팩토링 기간을 운영하며, 이 기간에 코드를 전체적으로 가다듬습니다. 이는 주기적이지 않고, 팀에 여유가 있을 때 진행하는데요. GitLab에 리팩토링 이슈를 생성하고, 구체적인 리팩토링 내용과 할 일 목록을 작성하며 리팩토링을 진행하죠. 이 과정에서 기존에 작성한 코드를 세분화해 코드를 더 깔끔하게 개선합니다.
3. 백로그 정리와 회고
프로덕트 팀은 우선순위에 밀려 진행하지 못한 개발 건을 Figma로 관리합니다. 이를 토대로 다음 버전을 준비할 때 신규 개발 건과 우선순위를 비교하고 개발 여부를 결정하는데요. 이로써 기술 부채를 지속적으로 상기하고, 조금씩 없애나가죠.
이 밖에 팀에서 회고를 진행, 부족한 점과 개선할 점을 논의하고요. 이 또한 백로그로 정리해 지속적으로 기술 부채를 의식하며 관리합니다.
맺음말
어느 개발팀이든 기술 부채는 필연적으로 마주치기 마련입니다. 기술 부채를 무조건 나쁘게 생각하고 스트레스를 받으며 이를 한 번에 다 해결하는 건 무리가 있고요. 이러한 접근 방식은 시간이 지나 기술 부채가 더 쌓였을 때 더 괴로울 수 있죠. 물론 ‘기술 부채가 어쩔 수 없는 것’이란 생각에 이를 안이하게 대처해서도 안 됩니다. 개발 생산성과 비즈니스에 부정적 영향을 미칠 수 있으니까요. 기술 부채의 불가피성을 인정하되, 지혜롭게 이를 관리하고 피해를 최소화하도록 모범 관행을 학습하고요. 우리 조직에 맞는 기술 부채 관리 방식을 확립해 개발 생산성과 품질, 비즈니스 성과 를 향상하는 데 기여해야 합니다.
참고 자료
- 크리스 리코미니, 드미트리 리아보이 저, 장현희 역. 『필독! 개발자 온보딩 가이드: 지속 가능한 소프트웨어와 원활한 협업 문화를 이해하는 프로페셔널 개발자의 탄생』
- Martin Fowler. "Technical Debt Quadrant." Martin Fowler’s Bliki
- 이재하. "개발자들이 꼭 알아야 할 기술 부채 관리법." 요즘IT
- Asana. "What is technical debt? How to pay it off (with examples)"
- Leanne Mitton. "Technical Debt & How To Manage It". Splunk
- Wikipedia. "Technical debt"
인포그랩은 GitLab과 DevOps를 맞춤형으로 기술 지원합니다. GitLab(Omnibus/Cloud Native Hybrid) 구축 지원이 필요하시면 문의하기로 연락해 주십시오.