오랜만에 인사이트 깊은 글을 보게 되어 새삼 21년전 IT입문하던 나의 모습을 되돌아보게 한다. 소프트웨어 개발자의 마인드와 성장은 이러한 깊은 고민과 성찰을 통해서 이루어지는게 아닌가 싶다.

오랜만에 인사이트 깊은 글을 보게 되어 새삼 21년전 IT입문하던 나의 모습을 되돌아보게 한다. 소프트웨어 개발자의 마인드와 성장은 이러한 깊은 고민과 성찰을 통해서 이루어지는게 아닌가 싶다. 전체 내용 중 기술부채에 대해서만 옮기고, 나머지 부분은 특히, 소프트웨어 개발을 하거나 관심있는 사람이라면 링크를 참고하셔서 꼭 전체 다 읽어보시길 강추합니다. "기술부채(Technical debt)"란 말그대로 기술적인 빚 이다. 일반적으로 소프트웨어를 만들 때 일정을 앞당기고자 코드를 불완전하게 작성하는 경우 "기술부채"가 발생한다. 또한, "기술부채"는 좀 더 넓은 의미로 문서 부족, 낮은 수준의 아키텍처 설계, 리팩토링을 게을리 해서 쌓인 꼬여버린 구조, 낮은 테스트 커버리지, 적절하지 못한 객체 모델링 등 을 포함한다. "기술부채"가 많을수록 우리는 불가피하게 많은 "이자"를 감수해야 한다. 유지보수 비용이 증가하고, 신규 개발 속도가 저하된다. 즉, 생산성이 떨어진다. 이런 문제를 해결하기 위해서(즉,"이자"를 덜 갚기 위해서) "기술부채"를 "상환"해야 한다. "상환"을 하기 위해서는 "리팩토링","시스템개선","재설계" 등 다양한 방법이 있다. 하지만, "기술부채"를 갚는 일은 생각보다 쉽지가 않다. "기술부채"를 해결하는 일이 쉽지 않은 이유를 생각하기 전에 먼저 "기술부채"의 일반적인 특징에 대해서 생각해보자.