IT 관리 / 개발자

우리가 알던 '기술 부채' 통념은 모두 틀렸다

Scott Carey | InfoWorld 2022.06.03

“빚은 여느 덫과 다르지 않다. 들어가기는 쉽고, 빠져나오기는 어렵다.” (조시 빌링스, 미국의 유머 작가)


IT 분야에서도 마찬가지다. 삶에서와 똑같이 말 자체만으로도 스트레스를 받고 짐스러운 느낌이 든다. 소프트웨어 엔지니어링에서 '기술 부채(Technical Debt)'는 일반적으로 노화하면서 엔지니어의 귀중한 시간을 잡아먹는 시스템을 가리킨다. 기술 부채는 관리되고 바람직하게 유지되고 최소화돼야 한다. 이것은 남은 업무의 가장 아래에 위치하며, 궁극적으로 시스템을 실패로 이끌기도 한다.
 
ⓒ Getty Images Bank

그러나 꼭 이런 식일 필요가 있을까? 진보적인 엔지니어링 기업은 오히려 기술 부채가 모든 소프트웨어 개발자의 핵심 업무여야 하고 기술 부채를 선제적으로 관리해 실패를 피할 수 있을 뿐 아니라,실제로 경쟁에서 우위를 점할 수 있다고 말한다. 어떻게 해서 가능한 것일까? 지금부터 차근차근 살펴보자.
 

기술 부채의 정의

'기술 부채'라는 용어는 1992년 컴퓨터 과학자 와드 커닝험이 처음 만들었다. 단기적 솔루션을 기술 시스템에 구축하는 업무에는 일련의 취사선택이 필요한데 선택받지 못한 업무가 결국 미래 엔지니어링 작업 형태로 남아 마치 갚아야 할 부채처럼 된다는 생각이다.

2003년 소프트웨어 개발자인 마틴 파울러는 기술 부채를 다음과 같이 설명했다.
 

"일을 성급하고 지저분하게 처리하면 기술 부채가 쌓이는데, 이는 금융 부채와 비슷하다. 금융 부채처럼 이자를 지불해야 하고, 결국은 나중에 개발해야만 하는 추가적인 업무의 형태로 남는다.


2018년 스트라이프(Stripe)의 개발자 계수(Developer Coefficient) 보고서에 따르면, 평균적인 소프트웨어 개발자는 기술 부채를 처리하는 데 일주일에 13시간 이상을 쓴다. 애플리케이션이 갈수록 복잡해지면서 부채를 관리하는 일이 매우 중요해졌다. 스텝사이즈(Stepsize)의 CEO인 알렉산더 오메여는 “개발자가 처리하리라 결정한 코드는 무엇이든 기술 부채다”라고 말했다.

기술 부채의 형태는 매우 다양하다. InfoWorld 칼럼니스트인 아이작 새콜리크는 지난해 "가벼운 기술 부채라면 리팩토링이 필요한 코드, 업그레이드가 필요한 라이브러리, 수정을 필요로 하는 유닛 테스팅 등을 꼽을 수 있다. 반면 복잡한 일체형 애플리케이션의 리엔지니어링, 오래된 웹 서비스 프로토콜의 이식, 다수의 플랫폼을 하나의 표준으로 일원화, 데이터 부채 문제의 해소, 인프라 현대화, 관측성 관행 도입, 수동 테스트 사례 잔고의 자동화 등 같은 것은 매우 부담스러운 기술 부채다. 최악의 유형은 ‘불타는 플랫폼(Burning platform)’으로, 비즈니스에 영향을 주는 장애와 오류를 반복하는 플랫폼을 의미한다”라고 말했다.

불타는 플랫폼이라고 불리는 작업을 하는 것은 빛나는 신기능을 배포하는 것보다 덜 매력적이다. 하지만 개발자는 팀으로서 선제적이고 지속해서 기술 부채를 상환해야 장기적으로 더 큰 고통을 피할 수 있다. 새콜릭은 “흔히 기술 부채에 대처하는 일은 소홀히하기 쉽다. 긴급한 비즈니스 니즈를 다루는 경우가 드물기 때문이다. 특히 긴급을 요하지 않는 경우 ROI가 불분명하고 따라서 나중에 해결하도록 연기가 가능하다고 인식한다. 코드든 주택이든 유지 보수 업무가 있는 모든 일에서 으레 발생하는 일이다"라고 말했다.
 

회원 전용 콘텐츠입니다. 이 기사를 더 읽으시려면 로그인 이 필요합니다. 아직 회원이 아니신 분은 '회원가입' 을 해주십시오.

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록발행일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.