개요
오늘은 기술 부채란? (Technical Debt) [ 개발에 도움이 되는 영상 ] 영상을 보고 기술 부채에 대한 글을 작성해 보았습니다.
기술 부채란?
기술 부채란 현재 시점에서 더 오래 소요될 수 있지만 더 나은 접근 방법을 사용하는 대신 보다 쉬운 솔루션을 채택함으로 인해 발생하는 추가적인 재작업의 비용을 의미합니다. (위키백과)
간단하게 말하면 다음과 같습니다. 문제 해결을 위해 아래 두 가지의 접근 방식이 존재한다고 가정해봅시다.
- 시간이 오래 걸리나 좋은 접근 방법인 A
- 코드는 더럽지만 시간이 짧게 소요되고 개발하기 쉬운 B
우리는 언젠간 A를 맞이해야 되지만 B를 사용해놓고 '일단 B쓰고 나중에 A로 바꿔야겠다'라 생각하면 그게 바로 기술 부채인 것입니다.
기술 부채의 종류
기술 부채에는 크게 두 가지 종류가 존재합니다. 일반적으로 코드를 바꾸는 것은 가벼운 정도의 기술 부채로, 시스템의 구조를 바꿔야 되는 정도는 무거운 기술 부채로 인식하고 있습니다.
가벼운 기술 부채
- 리팩토링
- 라이브러리 업그레이드
- 유닛 테스트
- 문서 작성
- 불필요 코드 제거
무거운 기술 부채
- 모놀리식 애플리케이션의 리엔지니어링
- 인프라 현대화
- 서비스 UX 변경
- 서비스 구조 변경
기술 부채의 특징
- 기술 부채는 빌린 사람과 갚는 사람이 일치하지 않을 수 있음
- 기술 부채는 서비스의 수준과 직결되지 않음
- 정량적 측정이 어려우며, 보는 관점에 따라 기술 부채 정도가 다를 수 있음
=> 결과적으로 서비스 운영에 큰 영향을 미치지 않아 낮은 우선순위를 가지게 되는 경우가 많습니다.
기술 부채가 발생하는 이유
- 개발자의 역량
- 당시 개발하는 개발자의 역량이 부족하여 발생할 수 있음
- 서비스의 지속적인 개발
- 기능 개선 과정에서 처음 설계된 코드와 온전히 섞이지 않는 코드가 개발될 수 있음
- 최근 트렌드와 같은 애자일 방식에서 쉽게 발생할 수 있는 문제
- 발전하는 기술
- 그 당시 가장 최신 기술을 채택하여 개발했음에도 이후 새로운 기술의 등장으로 레거시화
- 바뀐 규정 조항이나 기술 표준
기술 부채가 지속되는 경우
- 기존 개발에 참여했던 개발자가 이탈하면서 레거시 코드에 대한 컨트롤이 어려워짐
- 리팩토링으로 문제를 해결하려다 서비스 품질에 영향을 줄 수 있음
- 간단한 기능을 추가하기 위해 비교적 많은 코드의 수정이 필요해짐
기술 부채 해결 과정
1. 기술 부채 관점에 대한 고려
가벼운 기술 부채부터 점진적으로 해결해 나가야 합니다.
기술 부채 관점 종류
- 코드 컨벤션을 정했는가?
- 설계 원칙을 세웠는가?
- 테스트가 잘 작성되었는가?
- 개발 문서가 잘 작성되었는가?
- 정적 분석을 통한 코드 품질을 유지하였는가?
- 일정 수준 이상의 테스트 커버리지를 유지하였는가?
- 불필요한 코드를 제거하였는가?
- etc
2. 단기적 리팩토링을 진행한다.
3. 테스트 코드 작성
기술 부채 해결 예시
당신의 기술부채는 안녕하십니까? 배민선물하기 다시 만들기 영상을 통해 우아한형제들에서는 어떻게 기술 부채를 해결했는지 알아봤습니다.
1. 팀원들의 기술 부채 인지
기존 서비스를 운영하면서 팀 내부적으로 서비스의 발전과 trade off된 기술 부채 내역을 내부적으로 정리하였습니다.
2. 기술 부채 상환 계획 수립
팀 내부적으로 중요한 과제가 있어 기술 부채 상황 계획을 수립하되, 조바심내지 않고 여유로울 때 개선하기 위해 일정을 조정했습니다.
또한, 해당 기간동안 기술 부채 상환 계획을 보다 더 상세하고 치밀하게 계획해 나갔습니다.
3. 일부 구성원만 기술 부채 상환 진행
기술 부채를 상환할 서비스를 잘 아는 일부 개발자만 상환 준비를 진행합니다. 어떤 영향이 있을지, 문제가 있는지, 무엇을 해야 되는지 검토합니다.
어느정도 개선 계획이 완료될 경우 기존 운영서비스를 유지하는 일부 팀원을 제외한 대부분의 팀원들이 서비스 개선에 참여합니다.
4. 기존 시스템에 꾸준한 의문을 가진다.
기존의 시스템이 왜 이런 사용자 시나리오를 가지는지 지속적인 의문을 가지고 더 나은 시나리오를 찾기 위해 노력합니다.
기술 부채는 0으로 만들 수 없으나, 다음과 같은 과정을 통해 많은 기술 부채를 상환하여 더 나은 서비스를 제공을 할 수 있게 되었습니다.
별첨. 기술 부채는 안좋은 것인가?
기술 부채를 통해 회사는 서비스로 시장 점유율을 높일 수 있으며 서비스의 빠른 성장의 촉진시키는 연료로도 이용할 수 있습니다. 기존 서비스의 개선 없이 추가적인 기능 개발만 존재하기 때문입니다.
또한 개발자라면 마주치는 기술 부채, 꼭 다 갚아야 하나요? 라는 글과 함께 위의 영상을 통해 기술 부채의 발생 이유를 확인해보면 결국 필연적으로 발생할 수 밖에 없는 것이라고 생각되어집니다.
결론적으로 일정 수준 이상의 기술 부채는 서비스의 성장을 위해 필요하지만 과도한 기술 부채는 결국 문제가 발생할 수 있으니 서비스의 기술 부채에 대한 정리가 필요하다고 생각되어집니다.
결론
오늘은 기술 부채에 대해 알아보았습니다. 현재 서비스를 운영하는 개발자분들은 필연적으로 발생하는 기술 부채에 대해 불만을 가지지 않았으면 좋겠습니다.
서비스 성장을 위해서 어느 정도의 합의된 기술 부채는 추후 팀원들과 공유하며 점진적으로 개선해 나가면 되는 것입니다.
오늘부터 서비스 개선사항을 하나하나 적어 나가면서 기술 부채 상환을 준비하는 것은 어떨까요?
감사합니다.
