Offcanvas

How To / 개발자 / 데브옵스 / 리더십|조직관리 / 소프트스킬 / 애플리케이션 / 자기계발

기고 | 근절이 능사가 아니다··· '기술 부채' 측정 및 관리법

2015.12.28 Nick Dvas  |  Network World
‘기술 부채’(Technical Debt)는 개발자들 사이에서는 꽤나 대중적인 개념이다. 비록 경영 관점에서는 깊이 있게 검토된 바 없지만 말이다. 이에 대한 아이디어는 소프트웨어 개발 부서가 있는 기업 관리에 유용할 수 있다.

간단히 설명하면 기술 부채는 수정되어야 하지만 미처 수정되지 못한 코드들을 의미한다. 발생 이유는 다양하다. 소프트웨어 아키텍처의 변화, 새로운 요구 조건의 발생, 마감 기간에의 준수 등이 그것이다.

개발자들은 기술 부채를 마감 압박의 결과물로 설명하곤 한다. 제 때 제품을 납품하기 위해 여기 저기를 잘라내고 타협하며 차후 작업분을 남기는 경우를 의미한다.

엔지니어링 관점에서는 기술 부채에 대해 장기적으로는 코드 개체를 손상시킬 수 있지만 단기적인 필요를 충족시키는 소프트웨어 디자인 선택이라고 기술할 수 있을 것이다.

경영진의 관점에서 기술 부채는 현재의 개발 과정과 결과로 인한 개발 비용 또는 일정의 위험 증가로 해석될 수 있다.

정성적인 수준에서 기술 부채의 개념을 이해되는 경우도 있지만 다른 위험과 마찬가지로 때로는 정량화되기도 한다. 오늘날 기술 부채의 양에 대한 여러 지표가 존재한다.

* 정확도 예측. 기술 부채가 존재하지 않는 이상적인 상황에서 개발자들이 특정 기능을 개발하기 위해 필요한 시간을 좀더 잘 예측할 수 있다. 또 프로젝트 영역에 대한 전문 지식 증가, 사용하는 툴과 프레임워크(Framework)에 대한 지신 향상, 다른 팀 구성원의 성과 예측 능력 등을 통해 이론적으로 개발자와 개발 부서의 예측이 더욱 정확해진다.

반대의 경우에는 시스템이 통제를 벗어나게 된다. 예측 정확도 손실은 측정될 수 있으며 이 측정을 통해 누적된 기술 부채의 양에 관해 구체적으로 알 수 있다.

* 최초 기능 제공까지의 시간. 또 다른 유용한 지표는 최초의 기능을 제공할 때까지의 시간이다. 새로운 개발자를 기용하면 항상 적응 기간이 필요하다. 이 기간은 코드의 성향 이해 시간(학습 곡선의 형상)과 개발자가 이 학습 곡선을 따라 이동하는 속도(그의 학습 능력) 등 2가지 요소로 결정된다.

둘 다 중요하다. 하지만 평균적으로 새로운 고용으로 인해 생산 환경에 새로운 기능을 적용하기 위해 더 많은 시간이 필요한 경우 코드 학습이 너무 평평할 가능성이 꽤 높으며, 기술 부채가 원인일 수 있다.

* 내부적인 지표 실패. 개발자와 데브옵스(DevOps) 방침은 툴과 지표를 사랑한다. 그들은 끊임 없이 참고하고 측정한다. 개발팀이 현재의 소프트웨어 상태를 자동으로 추적하기 위해 일부 툴링(Tooling)을 이미 구성해 놓았을 가능성이 높다. 예를 들어, 빌드 "건전성", 즉 현재의 소프트웨어 버전이 시험을 통과하는지 여부를 확인하는 시스템을 가지고 있을 수도 있다.

이런 시스템은 대부분의 경우에 부실한 상태를 나타내는 경우가 많다. 이와 동시에 이 지표가 장기간 부실한 상태를 나타내게 내버려 두어서는 안 된다. 빌드가 1개월 동안 빨간 상태로 유지되는 경우 소프트웨어가 과거에는 충족했던 품질 기준을 지난 30일 동안 충족하지 못했다는 뜻이다. 여기에서 중요한 지표는 모두가 빨간색인 최대 지속 기간이다. 기간이 길수록 기술 부채에 더 깊이 빠지게 된다.

기술 부채 대응 방법
개발자들은 기술 부채를 싫어한다. 이로 인해 불필요한 복잡성이 생겨나고 시스템의 우아함과 능력이 떨어지며, 이런 식으로 처리하는 것은 적합하지 않다. 하지만 정말로 그럴까?

개발자 출신의 많은 팀 책임자 및 관리자들의 경우 기술 부채의 조짐이 나타나자 마자 비현실적인 싸움에 빠지게 되는 경향이 있다. 반면 일부 결과 지향적인 리더들은 기술 부채를 거의 개의치 않기도 한다. 그들은 처음에 성과를 내지만 이후 기술 부채를 누적시키는 경향이 있다. 결국 후임자에게 감당하기 어려운 수준의 해결되지 않은 문제들을 떠넘기게 된다.

당연히 두 접근방식 모두 위험하다. 위험의 종류에 상관 없이 기술 부채를 적절히 관리할 때 도움이 된다. 베스트 프랙티스는 다음과 같다.

* 부채 파악. 자신의 신용 카드 청구서를 관리할 줄 아는 사람이라면 비용이 누적되는 순간을 알 수 있다. 부채를 문서화하는 것도 좋은 생각이다. 실제로 발생하는 부채를 문서로 기록하거나 부채가 실제적인 장애물로 느껴질 때 문서로 기록하는 등의 2가지 접근 방식이 가능하다.

필자는 개인적으로 두 번째 방법을 권장한다. 이를 통해 부채가 자동적으로 우선순위화되기 때문이다. 부채를 파악하는 핵심은 부채 문서화 절차를 따를 때 절대적인 자세를 취하는 것이다.

* 검토와 상환. 부채를 파악한 후 상황에 따라 이를 검토하고 상환해야 한다. 때로는 하나의 부채를 상환하면서 다른 부채를 발생시키는 것도 좋을 수 있다. 금융 용어로 말하자면 지급 계정 회전율이 높아야 한다. 기술 부채가 지속되는 기간이 길어지면 지식이 분산되기 때문에 상환이 더 어려워진다.

* 수확 체감. 수확 체감의 법칙은 기술 부채 상환에 거의 무조건적으로 적용된다. 가장 큰 문제를 해결함으로써 위험이 극적으로 낮아질 수도 있다. 이후 해결하는 모든 문제의 효율성이 점차 낮아지게 된다.

* 예비 계획. 기술 부채는 위험이기 때문에 대비하는 것이 좋다. 기업에서 필요할 때는 청구서가 쌓이도록 하는 것이 좋다. 하지만 다음 기간, 즉 다음 개발을 준비할 때는 실제적인 위험 수준을 고려하는 것이 좋다.

* 분할 지배. 거칠게 찢을 때가 있고 꿰맬 때가 있다. 이는 기업 전체뿐만이 아니라 개발자들에게도 해당하는 이야기이다. 더욱 빠르면서 덜 엄격한 개발자들에게 개발을 맡기고 "열심히 일하는 사람들"이 이를 정리하며 해결하도록 하고 싶은 유혹이 존재하며 이로 인해 기술 부채가 발생한다. 하지만 이것은 좋은 생각이 아니다. 동기 부여 및 팀 구축을 위해 단기 생산성에 영향을 끼칠 수는 있지만 그 어떤 개발자도 부채 상환의 의무로부터 자유로울 수는 없다.

기술 부채는 불가원불가근이라는 표현과 어울린다. 기술 부채를 너무 회피하려 하면 가시적인 성과를 도출하기 어렵다. 기술 부채를 적절히 관리하면 안전하면서도 비즈니스 성장에 중요한 결과물을 제공할 수 있다.

* Nick Dvas는 Servers.com 최고 운영 책임자(COO)다. ciokr@idg.co.kr 
CIO Korea 뉴스레터 및 IT 트랜드 보고서 무료 구독하기
추천 테크라이브러리

회사명:한국IDG 제호: CIO Korea 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아01641 등록발행일자 : 2011년 05월 27일

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

Copyright © 2024 International Data Group. All rights reserved.