기술 부채(Technical debt)

기술 부채(Technical debt)

기술 부채: 개발 과정에서 즉각적인 요구 사항을 충족하기 위해 눈앞의 프로젝트를 더 빨리 완료할 수 있는 지름길을 택함으로써 추후 치루어야 하는 대가

회계 상의 부채(debt)를 감수하고 돈을 빌리면 당장 필요한 곳에 빠르게 투자할 수 있지만 재무 압박을 받고 원금에 이자를 붙여 지불해야 하는 것처럼, 당장 직면한 요구사항을 해결하기 위해 약간 지저분하더라도 빠르게 개발을 진행하면 코드가 복잡해지고 중복되면서 추후 새로운 기능을 구현하거나 확장하는 데 어려움이 발생한다.

기업이 부채를 통해 더 많은 투자를 적시에 집행하여 신제품을 개발하고 시장점유율을 높이거나, 개인이 대출을 통해 집을 계약하는 것처럼 기술 부채를 감수하고 새로운 기능을 빠르게 구현하는 것이 무조건 나쁜 것만은 아니며, 다만 기술부채가 쌓이는 것을 줄이고 감당 가능한 수준에서 관리하는 것이 바람직하다.

기술 부채가 발생하는 이유

개발자의 역량이 충분하다 할지라도 소프트웨어를 제작하는 과정에서 기술 부채는 필연적으로 발생하며, 원천적으로 막는 것은 불가능하다. 서비스가 발전하는 과정에서 기존에 설계했던 코드로는 한계에 봉착하면, 원래는 가독성 좋고 잘 작동하던 코드라 해도 기존 설계를 수정해야 할 수 있다. 또한 기술 자체가 발전함에 따라 예전에는 대세였던 라이브러리/프레임워크를 잘 사용하지 않게 되면 기술 스택을 다른 라이브러리/프레임워크로 변경하기로 결심할 수 있고, 이 경우에도 기존에 작성했던 코드가 일종의 기술 부채가 된다.

이 외에도 다음과 같은 이유들로 기술 부채가 발생할 수 있다.

• 프로젝트를 진행하면서 설계한 것을 제때 문서화하지 않아, 다른 사람이나 혹은 시간이 지나 자기 자신이 다시 해당 코드를 보았을 때 해석에 어려움을 겪는 경우
• 더 이상 사용하지 않는 변수나 DB 항목을 제거하지 않는 경우
• 반복 작업(배포/빌드 등)을 자동화하지 않아 매번 추가적인 시간과 노력이 드는 경우
• 긴급한 스펙 변경

기술 부채를 최소화하는 방법

개발자 간의 규칙(Convention) 설정

• 혼자 개발하는 것이 아닌 경우, 원활한 협업을 위해 사용할 언어나 기술 스택, 프로젝트의 디렉터리 구조, 개발 스타일 등등에 있어 합의 필요
• 어디까지 방식을 통일하여 개발하고 어디부터 개인의 자율로 둘 것인지 결정해야 함
• 코드 리뷰를 통해 서로의 개발 스타일을 확인하고 의견을 나누는 것이 필요

클린 코드(Clean Code) 작성 & 리팩터링(Refactoring)

• 기존 코드가 지저분하여 개발에 방해가 된다면, 코드 구조를 깔끔하게 변경하는 리팩터링을 통해 기술 부채를 청산할 수 있음
• 당연히 기존 코드가 지저분한 스파게티 코드일수록 리팩터링 난이도는 높아짐
• 가급적이면 처음부터 가독성이 좋고 유지보수가 용이한 코드를 짜고자 노력해야 함