[Software Development] 기술 부채를 다루는 방법

기술 부채는 개발 팀에 큰 불만과 소진을 초래할 수 있으며, 소프트웨어 엔지니어들은 이의 부정적인 영향을 인지하고 있지만, 개발 과정에서 빠르고 쉬운 솔루션을 선택하는 것의 위험성을 제품 팀에 설명할 필요가 있다.
워드 커닝햄이 1992년에 기술 부채라는 용어를 처음 사용했으며, 마틴 파울러는 기술 부채 생성의 네 가지 경로를 설명했지만, 특히 스타트업 회사에서 품질보다 속도를 우선시하면서 더 많은 기술 부채가 발생한다.
개발자 생산성에 대한 연구에서는 회사가 단기 목표를 위해 품질을 희생하면서 새로운 기술 부채를 도입해야 하는 상황이 자주 발생한다고 한다. 기술 부채는 조직 전체뿐만 아니라 개발자의 행복, 직업 만족도, 그리고 사기에도 영향을 미친다.
기술 부채의 주요 문제는 코드가 추상적인 개념이어서 비즈니스와 경영진에게 무슨 일이 발생하는지 설명하기 어렵다는 것이다.
기술 부채로 인해 새로운 기능 개발 능력이 감소하고, 시스템의 복잡성이 쌓이면서 개발 사이클당 새 기능에 대한 가능성이 감소한다.

나쁜 코드, 테스팅 부족, 모듈 간의 결합, 구식 라이브러리나 도구 사용, 수동 프로세스, 부적절한 아키텍처, 문서화 부족, 지식 공유 부족 등 다양한 유형의 기술 부채가 있다.

기술 부채를 우선시하고, 개발 프로세스와 코드베이스를 분석하여 병목 현상을 찾아내고, 기술 부채 맵을 생성한 후, 해당 부분을 식별하여 우선 순위를 정한다.
개발, 병목 현상, 속도 향상 필요성에 대해 투명하게 하고, 모든 이해 관계자가 동일한 이해를 공유할 수 있는 언어로 요약한다.
시스템에 대한 명확한 소유권과 책임을 설정하고, 기술 부채 해결을 제품 개발의 자연스러운 흐름에 포함시켜 팀이 문제를 해결할 수 있도록 한다.

기술 부채는 개발 과정에서 불가피하게 발생하지만, 새로운 부채의 생성을 줄이고 기존 부채를 줄이는 전략이 필요하다.
다양한 유형의 기술 부채를 인식하고, 이를 관리 및 감소하기 위한 프로세스와 전략이 많은 조직에서 부족하다.
기술 부채를 우선 순위에 따라 해결하고, 투명성을 유지하며, 시스템에 대한 명확한 소유권을 확립하고, 팀이 기술 부채를 해결할 수 있도록 하는 것이 중요하다.

기술 부채(Technical Debt): 소프트웨어 개발 과정에서 품질을 희생하여 단기 목표를 달성하기 위해 선택한 설계나 코드상의 불완전함으로, 장기적으로 추가 작업이 필요한 상태.
코드 품질(Code Quality): 코드가 이해하기 쉽고, 유지보수가 용이하며, 오류가 적은 정도를 나타내는 지표.
아키텍처(Architecture): 소프트웨어 시스템의 전체적인 구조와 구성요소, 그 구성요소간의 관계 등을 설계하는 과정 또는 그 결과물.