이율이 높아지는 요즘 같은 시대에 빚이란 걸 생각하기도 싫습니다.
어려운 길과 쉬운 길이 있다면 누구나 쉬운 길을 선택할 것입니다.
하지만 지금 쉬운 길을 선택했을 경우 간과했던 것들이 결국 나에게 빚으로 다가와 그것을 수정할 때 더 많은 노력과 시간이 필요한 경우가 많습니다.
이런 것을 기술 부채(Technical Debt) 라고 합니다.
Technical Debt 란 무엇인가?
Technical Debt(=Design Debt, Code Debt)는 직역하자면 "기술적인 빚"이란 뜻으로, 소프트웨어 개발 시 최상의 방법(The Best Overall Solution) 대신에 단기적으로 구현이 쉬운 방법을 선택하여 구현함으로써 발생한 나중으로 미뤄 둔 작업을 나타내는 용어입니다.
즉, 소프트웨어 개발 시 처음부터 제대로 구현을 하지 않으면 그게 빚이 되고, 결국 더 큰 빚으로 돌아오기 때문에 나중에 유지/보수 비용이 많이 발생하게 된다는 뜻입니다.
Technical Debt 는 왜 생기나요?
일반적으로 Technical Debt는 아래와 같은 원인으로 발생합니다.
1. Business Pressures
상사 또는 조직으로부터 압박에 의해 발생합니다.
제품 출시 일정을 맞추기 위해 촉박하게 업무를 진행하다보면 문서작업이라든지, warning 이라든지 사소하다고 생각하는 것들을 간과하기 쉽죠.
이 것들이 결국 품질 문제를 야기하기도 하기 이를 보완하기 위해 다시 시간과 비용이 필요합니다.
일정을 상사에게 말씀 드릴 때 항상 외부 인터럽트 발생할 것을 생각해서 내 생각보다 20% 길게 잡는 것이 필요합니다.
2. Lack of Process or Understanding
일정이나 요구사항이 변경되는 경우 또는 업무에 대한 이해가 부족할 경우 발생하게 됩니다.
사실 일정이나 요구사항이 변경되는 경우는 허다합니다. 하지만 업무를 진행함에 있어 빈번히 발생되는 경우이므로 시작 전에 항상 명확히 하고 요구사항 변경 시 이에 따른 일정 변경을 꼭 챙길 필요가 있습니다.
Risk Management 를 해야 오래 삽니다~!
3. Lack of Test Suite
테스트가 부족할 경우 발생하는 SW 품질 저하의 경우입니다.
나중에 SW 개발 방법론을 간략하게 설명하겠지만, 요구사항이 입력되면, 설계 단계에서부터 테스트가 들어가야 합니다.
4. Lack of Collaboration
프로젝트에 따라 다르겠지만, 일반적으로 제품 개발을 위해서는 여러 부서, 팀원들이 함께 개발을 합니다.
이 경우 부서 간 협업 이나 정보 공유가 부족하여 정보가 왜곡되는 경우를 말합니다.
서로 신뢰가 쌓이기 위해서는 부서간, 팀원간 Tea Time을 갖는 것도 중요하다고 생각합니다.
5. Parallel Development
동시에 여러 인원이 한 제품을 Target 하여 개발할 경우 발생하는 경우입니다.
이것도 또한 4번과 마찬가지로 구성원간 정보 공유가 제대로 이루어지지 않을 경우 발생하는 경우입니다.
6. Delayed Refactoring
코드를 개발하는 도중에 Refactoring을 제때 하지 않아 코드가 길어지고 복잡해지면서 발생하는 경우입니다.
SW 개발 시 Modular Design 을 잘 생각하면서 소프트웨어를 개발하는 버릇을 가져야 합니다. 특히 품질 평가를 염두해두면서 개발을 하시면 좋을 것 같습니다.
https://blog.naver.com/dorergiverny/223040815505
[소프트웨어] 소프트웨어(SW) 품질 평가 지표/기준
SW 품질 평가 지표/기준에 대해 고민해보는 시간을 가져볼까 합니다. 우리가 SW를 많이 개발하고 있지...
blog.naver.com
7. Lack of Alignment to Standards
팀원 간 표준에 대한 동의와 이해 없이 서로 각자 개발하는 경우에 발생합니다.
팀원간 소통과 미팅이 중요한 이유이죠.
8. Lack of Ownership
개발자 각자가 오너쉽이 없이 개발하는 경우입니다. 월급을 받고 일을 하는 입장에서는 오너쉽이 생기기 쉽지 않죠. 저도 마찬가지이니까요. 하지만 열정과 몰입을 할 수 있는 환경을 만들어보는 것도 중요합니다.
9. Poor Architecture
설계와 개발 시 아키텍쳐 설계가 유연하지 않아서 발생하는 경우입니다.
이럴 경우 요구사항 변경을 반영하기 어렵게 됩니다.
그럼 Technical Debt가 없는 프로젝트가 좋은가?
개발자들 사이에서 Technical Debt에 대한 오해가 많습니다.
1. Technical Debt가 없는 프로젝트가 좋은 프로젝트이다.
2. 실제 사업에서도 그렇듯이 적정 비율의 부채를 유지하면서 그 비용을 다른 곳에
투자하는 것이 오히려 더 많은 이익을 낼 수 있다.
3. 소프트웨어 개발에서도 Technical Debt를 발생시키면서 남는 잉여 리소스를
다른 곳에 투자함으로써 좋은 효과를 낼 수 있다.
4. 중요한 것은 "이 Technical Debt" 비율을 어느정도로 유지할 것이냐" 하는 것입니다.
이에 대한 답변은 개인이 고민해보고 도출하기 바랍니다.
