기술 부채라는 단어를 많이 들어보셨을것 같은데요,

인포그랩에서 기술 부채에 대한 개념, 유형 및 해결 방법에 대해 잘 정리한 글이 있어 공유드립니다.

기술 부채는 시간이 더 걸릴 수 있는 더 나은 접근 방식을 취하는 대신 쉽지만 제한된 솔루션을 선택할 때 필요한, 향후 재작업의 암묵적 비용을 뜻하는 말입니다.

(1992년 워드 커닝햄이라는 컴퓨터 프로그래머가 이 용어를 정의했다고 합니다.)

쉽지만 제한된 솔루션을 사용할 경우 빠르게 적용할 수 있는 장점이 있지만

시스템 장애 상황이나 추가 개선 작업이 생겼을 때 이로 인해 더 큰 개발 공수가 들어갈 수 있는 기술 부채가 발생하게 되는데요,

어감상 기술 부채가 부정적인 표현으로 들릴 수 있지만 이를 잘 알고 관리하면 개발을 진전시키는데 도움이 됩니다.

소프트웨어 엔지니어 마틴 파울러가 구분한 기술 부채 유형은 다음과 같습니다.

📌 신중하고 의도적인 기술 부채(Prudent & Deliberate)

팀이 부채를 지고 있다는 걸 알지만 ‘더 빠른 출시 보상이 부채 상환 비용보다 더 큰지’ 여부 고려

📌 신중하지 못하고, 의도적인 기술 부채(Reckless & Deliberate)

좋은 설계 관행 알고, 실천할 수 있지만 깔끔한 코드를 작성할 시간이 없어 ‘빠르고 지저분하게’ 진행하기로 한 결과

📌 신중하되, 의도하지 않은 기술 부채(Prudent & Inadvertent)

좋은 소프트웨어를 개발했고, 코드도 깔끔했지만 시간이 지나서야 ‘설계가 어땠어야 한다’는 걸 깨달은 결과

📌 신중하지 못하되, 의도하지 않은 기술 부채(Reckless & Inadvertent)

잘 몰라서 발생한 결과

글에서 정리한 기술 부채 해결 방법으로 다음과 같습니다.

📌 기술 부채 목록 관리

• 프로젝트 회고해 기술 부채를 목록으로 정리, 공유

• 기술 부채 발생할 때마다, 이 부채 해결에 필요한 작업을 예상되는 노력, 일정과 함께 기록

• 팀에서 기술 부채 해결 여부와 해결 시점 논의, 해결 방안 수립

📌 좋은 기술 부채와 나쁜 기술 부채 구분

• 이렇게 기술 부채를 구분하면 가장 큰 문제와 우선순위를 정하는 데 도움이 된다

📌 리팩토링

• 업무 수행하면서 필요한 부분 정리, 조금씩 리팩토링

• 대규모 리팩토링할 때 팀에 상황 공유, 기술 부채 위험과 비용 알림

📌 테스트 코드 작성

• 코드가 복잡할수록, 리팩토링 규모가 클수록 버그 없이 코드를 한 번에 수정하기 어렵다

• 부작용 방지하려면 테스트 코드 작성

📌 품질 표준 설정, 준수

• 품질 표준을 설정하여 코더가 엉성한 코드를 배포 못하도록 한다

📌 갑작스러운 규정·일정 변경 X

• 개발자 관련 규정 지속 변경, 마감일 바꾸면 기술 부채를 피하기가 어렵다

• 현실적인 일정, 방법론, 작업량을 제공해 기술 부채를 관리하도록 한다

좀 더 자세한 내용은 공유드린 원문 링크를 참고해주세요.

📚 원문

• https://insight.infograb.net/blog/2024/06/05/technical-debt-return/