개발자 / 클라우드

애자일 부서 설득하기 "기술 부채 인식이 최우선"

Isaac Sacolick  | InfoWorld 2021.10.18
지난 몇 년 동안 클라우드 네이티브 마이크로서비스 아키텍처를 다룬 전도유망한 신생업체가 아니라면, 나머지 애자일 개발 부서는 아마 기술 부채 해결에 끙끙 앓고 있을 것이다. 기술 부채는 애플리케이션 및 서비스, 데이터베이스, 인프라 등에 골고루 엮여 있고 규모와 위험, 복잡성, 그리고 비즈니스에 미치는 영향도 다양하다.

기술 부채는 신기능 개발, 고객 경험 향상, 보안 문제 해결, 신뢰성 개선, 성과 증진, 워크플로 자동화, 기타 비즈니스 우선순위 해결 등 다양한 부서의 과업을 가로막는 과제로 작용하고 있다.
 
ⓒ Getty Images Bank
 

기술 부채란 무엇인가?

기술 부채의 정의와 의미는 다양하다. 간단하게 보면 리팩터링이 필요한 코드의 일부분이나 업그레이드가 필요한 라이브러리, 수정이 필요한 유닛 테스트 등이다. 더욱 고차원적인 기술 부채에는 복잡한 일체형 애플리케이션 재설계, 구식 웹 서비스 프로토콜 복사, 단일 표준에 통합된 복수의 플랫폼, 데이터 부채 문제 정리, 인프라 현대화, 관찰 가능성 방식 도입, 밀려 있는 수동 테스트 사례 자동화 등이 속한다. 이중 최악의 유형은 회사에 영향을 미치는 사건과 가동 중단이 반복되는 플랫폼이다.

필자가 간단히 정의하는 기술 부채란 전략적 비즈니스 요건을 구현하기 전이나 구현 단계 중에 프로덕션 단계에서 실행되는 기술에 수정, 리팩터링, 현대화, 업그레이드, 재설계, 또는 교체가 필요한 것을 말한다.
 

기술 부채가 애자일 개발 부서에 영향을 미치는 방식

기술 부채를 해결해야 하는 애자일 부서와 스크럼 부서가 직면한 난제는 다음과 같다. 조직마다 애자일 채택 방식이 많지만, 대부분의 애자일 방법론에서는 고객과 이해관계자의 필요에 따라 밀린 일의 우선순위를 설정할 책임을 제품 소유자에게 부여한다.

최상의 경우라면 제품 소유자가 경청하고 학습하고 질문하면서 기술 부서와 협력하여 기술 부채를 해결할 것이다. 기술 부채를 우선시하려면 제품 관리 그룹(제품 관리자 및 소유자 포함)은 밀린 일의 우선순위를 확립할 때 기술 전문가를 배포 협력업체와 이해관계자로 바라보아야 한다.

제품 관리자 및 소유자가 고객과 비즈니스 리더, 그리고 까다로운 이해관계자로부터 기능과 비즈니스 능력을 우선적으로 처리해 달라는 엄청난 압력을 받으면서도, 기술 개선에 지속적으로 집중하는 것을 꺼릴 수도 있다. 왜냐하면 비즈니스 결과 실행, 고객 만족 개선, 엄격한 비즈니스 이해관계자의 요구 충족 등을 더 빨리 해낼 방법을 추구하기 때문이다. 필자의 경험에 비추어 볼 때 또 다른 어려움은 제품 소유자가 기술 부서와 충분히 협력하지 않는다는 점이다. 이것이 기술 부채 해결에 대한 투자를 부족하게 만드는 주범인 경우가 많다.

애자일 부서와 데브옵스 조직이 어떻게 해야 기술 부채와 관련하여 애자일 제품 관리자 및 소유자와 협력적인 동반자 관계를 구축할 수 있을까? 경험이 풍부한 3인의 제품 관리자에게 통찰과 권장사항을 물어보았다.
 

비즈니스 결과에 대한 애자일 기술 개선

VM웨어 제품 관리 리더 수메야 벤하넴은 클럽하우스에서 ‘더 위크 인 프로덕트(The Week in Product)’를 진행하면서 제품 관리자가 우선순위 정의, 고객의 수요 부응, 기술 능력 개선 등과 관련하여 내려야 하는 어려운 결정에 대해 논의했다.

벤하넴은 “비즈니스 영향에 대해 생각할 때 내가 우선시한 결과와 중요한 모든 요소를 살펴보는 방식으로 한다. 그러한 결과와 일치하는 기술 부채가 있는 경우가 많다. 제품 관리자에게 더 나은 방식은 기술 부서와 긴밀히 협력하고, 기술 설계의 결과를 이해하고, 기술 부채 해결 노력을 우선시하는 것이다. 기술 부채를 해결하면 비즈니스 결과 향상, 속도 증대, 부서 사기 개선, 부서 근속 증가, 가치와의 일치 등의 결과로 이어질 수 있다”라고 말했다.

각 부서가 기능 출시와 개선만 생각한다면 기술 부채에 신경 쓰기 어렵다. 애자일 부서가 비즈니스 결과를 목표로 할 때는 새로운 기능, 신뢰성 업그레이드, 보안 강화 기능, 새로운 자동화, 추가 테스트, 기타 개선 사항이 전략과 일치하는지 여부에 대한 토론으로 이어진다. 
 

개선 촉진을 위한 애자일 원칙 및 지표

중요한 것은 비즈니스 결과뿐만이 아니다. 애자일 부서는 토론을 거쳐 각자의 원칙을 공개하기도 해야 한다. 벤하넴은 부서 사기 개선과 속도 증대 같은 원칙을 제안했다.

지원이 부실한 코드 모듈, 수동 배치 프로세스, 오류가 잘 생기는 데이터 서비스 등이 있다고 가정해 보자. 이 경우 해당 기술 분야에 추가되는 고생과 스트레스는 합의된 원칙에 따라 해결책의 우선순위 설정을 정당화하는 데 도움이 될 것이다.

벤하넴은 기능 구축이나 경험 개선에 방해가 되는 거대한 기술 부채 바위만을 목표로 하는 것도 경고했다. “특히 기술 솔루션 도입 초기에는 오직 ‘방해물’ 수준의 기술 부채만이 해결할 가치가 있다는 인식이 있는데 개인적으로는 매우 건전하지 않은 태도라고 본다”라고 말했다.

각 부서는 유지관리와 개선이 필요한 분야를 정당화하고 우선시하는 데 도움이 될 애자일 원칙과 관련 지표를 규정해야 한다. 그렇게 하지 않으면, 기술 토대에서 썩어가는 작은 부분이 장기적인 구조적 문제로 이어질 수 있다. 테스트 범위 확대, 데이터 품질 해결, 아키텍처 기록, 관찰 가능성 증대는 계속적인 강화가 필요한 비차단 개선의 예시다.

맥킨지 앤 컴퍼니의 뉴욕 기반 제품 책임자 겸 부파트너 마크 앨버트는 각 개발부서에 계속적인 강화를 비즈니스 용어로 설명할 것을 상기시켰다. 구체적으로는 “기술적 장점과 이유를 지나치게 자세하게 설명하다 보면 중요성은 축소해서 말할 때도 있다. 따라서 그 대신 기술 부채를 해결하지 않을 때의 비즈니스 결과에 초점을 맞춰야 한다. 사용자 경험과 고객 서비스 이행, 제품 경제학은 물론 심지어는 대단히 중요한 가치 제안까지도 어떻게 나중이 아니라 지금 투자할 때 이득을 누릴 수 있을지를 중심으로 논의의 틀을 구성하는 것이 더 효율적으로 우선순위 설정에 영향을 미치는 방법이 될 수 있다”라고 말했다.
 

신뢰 구축과 절충점 토론

아쉽게도, 비즈니스 결과와 애자일 원칙을 일치시키는 것은 기술 부채 우선순위를 정하는 데까지만 해당한다. 가끔은 비즈니스 결과를 성취하기 위해 장기간에 걸쳐 여러 가지를 해결해야 할 때가 있다. 제품 관리자가 점진적인 기술 강화에 투자하다가 인내심을 잃는 경우도 있다.

박스(Box)의 그룹 제품 관리자 스티브 츄는 제품 관리자와 담당 부서는 반드시 신뢰를 쌓고 절충점을 논의해야 한다고 강조했다. 요점은 “제품 관리자로서 해당 기술 책임자가 이 기술 부채가 필요하다고 하면 신뢰하는가? 그렇지 않다면 부서 내에 근본적인 문제가 있는 것이다. 훌륭한 제품 부서에는 제품 관리자, 엔지니어링, 설계자 간의 신뢰가 수반된다. 그런 신뢰가 없다면 이유를 알아내서 해결하는 것은 각자의 몫이다. 모든 상황에 쌍방 타협이 있는 협력 관계여야 한다.”

신뢰는 기술 책임자 및 개발 부서가 지는 책임을 제품 관리자가 잘 이해하는 상황을 의미한다. 기술 부서는 각자의 기술 부채를 해결해야 한다. 엄청나게 밀려 있는 기술 부채를 가지고 제품 관리자에게 가는 것은 필수 기능 우선 순위가 수십 개 있는 까다로운 이해관계자와 일하는 것만큼 나쁘다.

각 기술 부서가 우선 순위를 정하고 각자의 문제를 비즈니스 용어로 설명하고 의미 있는 애자일 원칙을 만드는 것이 먼저다. 이러한 조직의 제품 관리자라면 자연히 기술 부채를 해결하는 다양한 개선을 지원하게 될 것이다. editor@itworld.co.kr 

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

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

Copyright © 2024 International Data Group. All rights reserved.