기술 부채 (technical debt)
역사
"기술 부채"라는 용어는 워드 커닝햄(Ward Cunningham)이 처음으로 사용했다. 기술 부채는 금융 부채와 비슷한 개념으로 우리의 결정이 계속해서 미래에 선택할 수 있는 옵션을 줄이고, 어떻게 시간이 지날수록 점점 더 해결하기 어려운 문제가 되는지를 설명한다. 아무리 신중하게 고려한다 하더라도 우리는 여전히 이자를 물게 된다.1
20% 리소스를 투입해 기술 부채를 갚아 나가기
[Inspired]의 저자인 마티 케이건(Marty Cagan)은 교훈을 다음과 같이 체계적으로 정리했다.
"엔지니어와 제품 관리자 사이의 협상은 다음과 같이 진행된다. 제품 경영진은 엔지니어가 팀 역량의 20%를 제품을 적합하게 튜닝하는 데 투자하도록 한다. 엔지니어는 해당 역량을 코드베이스의 문제 부분 재작성, 아키텍처 재구성, 리팩토링할 때 사용할 수 있다. 그들이 생각하는 것이 무엇이든 팀에 찾아와 '작업을 중단하고 전체 코드를 다시 작성해야 한다'라고 이야기하는 상황은 피할 필요가 있다. 엔지니어의 컨디션이 몹시 나쁘다면 30%, 아니라면 그 이상의 리소스를 사용해야 한다. 그러나 팀이 20% 미만의 역량 투입만으로 해낼 수 있다는 사실을 알게 되면 긴장하게 될 것이다."
케이건은 조직이 "20%의 세금"을 내지 않으면 필연적으로 모든 개발 및 운영 주기를 기술 부채를 해결하는 데 쏟아야 할 만큼 기술 부채가 증가할 것이라고 지적했다. 어느 시점에는 서비스가 매우 취약해져서 기능 제공이 서서히 중단된다. 모든 엔지니어가 안정성 문제와 문제 해결 작업에 매달려 있기 때문이다.
개발 및 운영 주기의 20%를 투자하면 개발과 운영이 일상 업무에서 직면하는 문제에 대한 대응책을 지속적으로 마련할 수 있으며, 서비스를 빠르고 안전하게 개발하고, 프로덕션 환경에서 운영하는 능력이 기술 부채에 방해받지 않음을 보장받는다. 작업자에게 기술 부채 추가에 대한 부담감을 높이므로 번아웃 수준도 낮출 수 있다. 2
사례
LinkedIn의 Operation InVersion
다음은 데브옵스 핸드북에서 발췌한 내용이다.
2011년 가을까지도 야근은 더 이상 통과 의례나 결속을 위한 활동이 아니었다. 링크드인의 엔지니어링 부사장인 케빈 스콧(Kevin Scott)을 포함한 최고 엔지니어 중 일부는 신규 기능의 개발 작업을 완전히 중단하고, 사이트의 핵심 인프라를 고치는 데 전체 부서를 투입하기로 결정했다. 그리고 이런 노력을 오퍼레이션 인버전(Operation InVersion)이라 불렀다.
그는 문화와 관련된 선언문의 시작 부분에 팀의 엔지니어링 문화를 주입하는 방식으로 오퍼레이션 인버전을 시작하면서 다음과 같이 말했다.
"링크드인의 컴퓨팅 아키텍처를 개조할 때까지 신규 기능 개발은 없을 것이다. 이것이 비즈니스 부서와 팀에게 필요한 사항이다."
스콧은 한 가지 단점을 설명했다.
"모두에게 공개하고, 모든 세상이 바라보게 한 후, 경영진에게 모든 엔지니어가 '인버전' 프로젝트에 투입되는 향후 두 달 동안 어떤 새로운 기능도 출시하지 않겠다고 얘기했다. 이것은 두려운 일이었다."
그러나 밴스는 오퍼레이션 인버전의 결과가 엄청나게 긍정적이었다고 설명했다.
"링크드인은 사이트 코드를 개발하는 데 도움이 되는 전체 소프트웨어 스위트(suite)와 도구를 만들었다. 엔지니어가 새로운 기능을 링크드인의 메인 사이트에 추가하기 위해 몇 주를 기다리는 대신, 새로운 서비스를 개발했다. 새로운 기능이 기존 기능과 상호작용하는 경우, 일련의 자동화된 시스템이 서비스에서 발생할 수 있는 버그나 이슈에 대한 코드를 검사하도록 함으로써 실제 환경의 링크드인 사이트에 바로 출시할 수 있었다. 링크드인의 엔지니어링 군단은 현재, 사이트의 주요 업그레이드를 1일 3회 진행한다."
더 안전한 업무 시스템을 만들어 엔지니어들이 생성해낸 가치는 벼락치기식 야근의 감소와 새롭고 혁신적인 기능 개발에 투자할 수 있는 시간의 증가를 포함한다.
(중략)
인버전 프로젝트는 링크드인이 10여 년간의 기술 부채를 모두 상환함으로써 안정성(stability)와 안전성(safety)을 확보하는 동시에 회사가 다음 단계로 성장할 수 있는 발판을 마련했다. 그러나 IPO 진행 중에는 시장에 약속한 모든 기능을 희생하며 두 달 동안 비기능적인 요구 사항에 완전히 집중해야 했다. 일상 업무 목적으로 문제점을 찾아내고 해결하는 것으로 기술 부채를 관리하면 이와 같은 "경영 위기"에 가까운 경험을 피할 수 있다. 2
함께 읽기
- [[/jargon/20-percent-project]]
참고문헌
- 데브옵스 핸드북 / 진 킴, 제즈 험블, 패트릭 드부아, 존 윌리스 저/김영기 역 외 1명 정보 더 보기/감추기 / 에이콘출판사 / 2018년 07월 06일 / 원제: The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations