'기술적 부채(Technical debt)'는 소프트웨어 개발 과정에서 장기적으로 바람직한 접근법 대신 당장 편한 해법을 택해 발생하는 추가적 작업 비용을 가리킨다. '디자인 부채(design debt)', '코드 부채(code debt)'라고도 불린다. 예를 들어 어떤 코드를 수정하면 연관된 코드와 문서화 작업을 함께 해야 하는데, 여러 이유로 이 작업을 미뤄 두면 결국 언젠가는 해야 할 작업, 즉 '빚'이 된다.
이 개념은 '금융 부채'와 비교하면 더 쉽게 이해할 수 있다. 부채를 상환하지 않으면 이자를 내야 하고, 이 이자가 쌓이면 재정 상황이 나빠진다. 기술적 부채도 처음에는 큰 부담이 아니지만 방치하면 기존 시스템을 전면적으로 수정하기도, 그대로 운영하기도 힘든 난감한 상황이 된다. 오픈소스에서는 로컬에서 수정한 것을 업스트림 프로젝트로 보내지 않는 것을 기술적 부채로 보기도 한다.
기술적 부채가 발생하는 이유는 다양하다. 대표적인 것이 불충분한 선행 정의다. 요건 파악이나 설계를 제대로 하지 않고 개발을 진행하는 것이다. 개발 기간을 조금 줄일 수 있지만 결국 더 많은 재작업을 해야 할 수 있다. 이 밖에 더 빠른 릴리즈를 요구하는 현업의 압박, 모듈화되지 않은 컴포넌트, 테스트와 문서화의 부족, 빈약한 협업 등도 기술적 부채가 생기는 원인이다.
상당한 기술적 부채를 안은 채 릴리즈하면 훗날 이를 바로잡는 부담이 급격히 커진다. 이미 사용하고 있는 소프트웨어 코드를 수정해야 하므로 장애 위험도 감수해야 한다. 클라우드 업체라면 SLA(Service Level Agreement)에 따른 법적 책임을 져야 할 수도 있다. 이 때문에 많은 기업이 기술적 부채를 그대로 안고 시스템을 운영한다. 마치 더 많은 이자를 감당하며 해결을 미루는 것과 같다.
그렇다고 기술적 부채를 무조건 나쁜 것으로 볼 필요는 없다. 예를 들어 개념증명(PoC) 같은 프로젝트는 어느 정도 기술적 부채를 감수하는 것이 오히려 효율적이다. 장기적 대비보다는 당장 상용화 여부를 판단해야 하기 때문이다. 반면 '기술적 부채'라는 표현 자체부터 문제가 있다는 지적도 있다. 마땅히 해야 할 작업을 안 하는 것을 그럴듯하게 포장하는 데 악용되고 있다는 것이다.
출처
'DevOps.' 카테고리의 다른 글
| '플랫폼 엔지니어링'의 이해 | 데브옵스의 최종 진화 (0) | 2023.04.27 |
|---|---|
| 생성형 AI를 기업에 품는 방법 | 긴 호흡으로 차근차근 (1) | 2023.04.11 |
| 애플리케이션 개발 과정에 '네트워크 전문가'가 꼭 필요한 이유 (0) | 2023.04.10 |
| 클라우드 비용을 절감하고 IT 운영을 개선하는 지혜 (가트너) (2) | 2023.04.10 |
| 무작위 데이터 테스트 방법 '퍼징(fuzzing)' (0) | 2023.04.04 |
| 고속 개발 플랫폼(rapid development platforms) '로우코드(Low Code)' (0) | 2023.04.04 |
| 업무 효율을 높여주는 파워셸 툴 (0) | 2023.04.04 |
| 모바일 관리 솔루션 MDM, MAM, EMM, UEM의 차이 (0) | 2023.03.27 |
