Offcanvas

CIO / How To / HR / 데브옵스 / 리더십|조직관리 / 소프트스킬 / 훈련|교육

‘마이크로 매니징은 해법 아니다’ 개발자 관리 방안 7가지

2022.02.16 Isaac Sacolick  |  InfoWorld
우수한 개발자들은 조직의 미세 관리(Micro management)를 못 견뎌 하는 경향을 가진다. 여기 개발자의 반발을 사지 않고도 개발팀의 성과와 비즈니스 목표를 정렬할 수 있도록 해주는 7가지 방안을 정리했다. 
 
Image Credit : Getty Images Bank


올해 들어 유독 자주 받은 질문이 있다. 하이브리드 근무 모델을 도입할 때 소프트웨어 개발자의 생산성, 품질, 성과를 어떻게 측정할 지와 관련된 것들이었다.

경영진이라면 해야 할 고민이기는 하다. 그러나 유능한 소프트웨어 개발자를 고용해 유지하기가 쉽지 않은 현실을 직시할 필요가 있다. 유능한 소프트웨어 개발자는 미시적 관리를 달가워하지 않을 것이며, 마이크로 매니지먼트 문화가 없는 곳으로 떠날 가능성이 크다.

개발 경험이 전무한 관리자에게 보고하도록 개발자에게 주문한다면 업무 관료주의에 대한 공포가 촉발된다. 자율성 원리를 옹호하는 소프트웨어 개발자는 전적인 자율을 원하고 경영진이 생산성, 품질, 여타 성과 고려사항을 측정하려 드는 어떤 징후에든 반발할 것이다.

소프트웨어 개발자들은 으레 마이크로 매니지먼트를 혐오한다. 또 다수의 소프트웨어 개발자가 연간 성과 리뷰를 경멸한다. 개발자 대부분은 실시간 성과 목표를 추구하고, 속도, 코드 개발 빈도, 순환 시간, 여타 핵심 성과 지표를 개선하려고 노력한다. 스크럼 팀은 스프린트가 종결될 때마다 성과를 논의하기 때문에 연간 및 분기 성과 리뷰 작업이 불필요하거나 무의미해 보이기 쉽다.

그러나 조직으로서는 가만히 맡겨둘 수 없다. 애자일 팀 및 소프트웨어 개발자가 성과, 개발, 사업 목표를 충족했거나 초과했는지를 인식할 방법이 있어야 한다는 실체적 현실 역시 존재한다. 매니저는 어떻게 하면 개발자를 괴롭히지 않으면서 자신이 필요한 것을 얻어낼 수 있을까? 

아래에서는 애자일, 스크럼, 데브옵스 원리, 그리고 소프트웨어 개발 수명주기에 합치하고, 아울러 소프트웨어 개발자를 평가할 때 적용할 수 있는 7가지 권장 관행을 살펴본다. 필자가 이를 SMART 목표로서 (Specific, Measurable, Achievable, Relevant, Time-bound) 제시하는 것은 아니다. 그러나 리더는 조직의 기민한 업무 방식 및 사업 목표를 바탕으로 이같이 합당한 관행을 검토해야 한다. 이들 가운데 일부는 팀 수준에서만 유의미할 수 있음을 알린다.

사업 및 기술 목표에 합치하는 목표 및 핵심 성과를 정의 
제품 소유자, 개발 매니저, 아키텍트는 자신의 팀과의 논의를 통해 측정 가능한 성공 기준에 부합하는 OKR(Objectives and Key Results)를 정의해야 한다. 이상적으로 이는 리더와 팀 사이의 협력이다. 리더가 목표를 정의하면 전체 팀이 핵심 성과를 토론하고 논쟁하고 결정한다. 
 
바람직한 관행은 유효한 빈도로 OKR을 정의하는 것이다. 너무 빈번하면 OKR을 정의하고 측정하는 데 따른 간접 비용이 값비쌀 수 있다. 횟수가 지나치게 적다면 팀이 목표에 대한 시야를 잃을 수 있다. 아래에서는 두 실례를 제시한다.

•     ‘애플리케이션 신뢰성을 제고한다’는 목표는 페이지 반응 시간 단축, 앱 가용성 향상, 오류 비율의 유의미한 감소 등의 성과를 포함할 수 있다. 
•    ‘배포 안정성을 제고한다’라는 목표는 테스트 자동화 증가, 제작 시간의 유의미한 단축 등의 성과를 포함할 수 있다. 

스프린트 및 배포 약속을 지속적으로 충족 
스크럼 방법론은 개발 주기 및 약속 준수라는 기반 위에서 작용한다. 따라서 마감시한 달성은 팀의 기강과 기준에의 합치를 측정하는 한 방법이다. 매 스프린트마다 완벽하게 약속을 달성하지는 못할 것이다. 그러나 리더는 여러 스프린트에 걸쳐 합계한 기대치의 상한 및 하한을 정할 수는 있다.

정해진 주기에 따라 배포를 수행하는 경우 (예를 들어 일일, 주간, 4회 스프린트마다) 필자는 팀이 일정에 따라 배포하고 품질 수준을 충족하는 지 평가하도록 권고한다. 배포일은 준수했지만, 정전, 보안 사건, 심각한 생산 문제를 유발했다면 명백한 문제이다.

제품 소유자 및 이해관계자의 만족을 달성 
애자일 소프트웨어 개발 선언문은 ‘계약 협상과 관련해 고객과의 협업’(customer collaboration over contract negotiation)을 핵심 가치로 규정한다. 애자일 개발자가 완벽하게 전달하도록 압박해서는 안 된다 (시간, 범위, 비용을 가리키는 이른바 철 삼각형의 준수). 그러나 개별적인 고객 만족 지표를 달성하도록 추구할 수는 있다.

만족도 조사는 대형 개발 조직이 애자일 개발자 및 팀에 대한 피드백을 수집하는 데 사용할 수 있는 도구이다. 몇몇 질문은 아래와 같은 내용을 다룰 수 있다.

•    문제에 관해 브레인스토밍을 하고 해법을 문서로 기록할 때의 협업 
•    범위 및 만족도에 준하는 성과를 전달 
•    특장점을 계획하고 평가할 때 피드백의 질 

핵심은 개발자와 애자일 팀에게 고객 피드백을 제공하는 것이고, 이에 의해 이들은 고객의 시각에서 성과를 판단하며 성능을 개선할 수 있다. 

설계, 설명서, 사용성에 대한 동료 리뷰를 수량화 
다른 팀의 API를 사용하거나, 다른 개발자의 코드를 업그레이드하거나, 신규 애플리케이션 아키텍처를 설명서를 통해 학습하기가 얼마나 쉬운 지를 개발자에게 질문하라. 유감스럽지만, 긍정적인 응답이나 만족스러운 개발자를 만나기 쉽지 않을 것이다. 구식 코드 상에서나 획일적 아키텍처 내에서 작업하는 경우라면 특히 그렇다. 

그렇다면 개발자가 유지보수 가능한 코드, 유용한 설명서, 소비하기 쉬운 마이크로서비스를 개발하는 일에서 나아지고 있는지를 어떻게 판단하는가? 발전이나 퇴보를 어떻게 측정할 수 있을까? 

이들 지표를 측정할 도구나 분석법이 없지는 않겠지만, 필자는 가장 간단한 방법이 동료 리뷰 프로세스를 생성하는 것이라고 믿는다. 동료는 풀 리퀘스트 리뷰 시 코드 가독성에 대해 의견을 말할 수 있고, 설명서에 대해 평점을 제공할 수 있고, 마이크로서비스나 API를 통합할 때 설문에 응할 수 있다. 

동료 리뷰는 코드 리뷰 및 품질 분석 툴에서 나오는 피드백을 보완해야 한다. 툴은 코드 품질, 보안, 여타 연관 문제에 대해 미시적 피드백을 실시간으로 제공할 수 있다. 

데브옵스에 관한 비타협적 KPI를 선택 
제품 소유자와 동료는 중요한 피드백을 제공하지만, 이외에도 매니저는 개발자 및 개발 팀이 운영에 관한 피드백을 리뷰하고 대응하도록 해야 한다. 피드백은 사이트 신뢰성 엔지니어링, 보안 실무, 그리고 ITSM, 요청 및 여타 티켓에 대한 반응성에 관한 구체적 사실을 포함해야 한다. 

데브옵스, ITSM, 정보보안은 매우 고도화된 KPI를 가지고 있고, 리더는 소프트웨어 개발 팀을 위해 유의미하고 관리 가능한 수의 전담 인원을 선발해야 한다. 클라우드 네이티브 애플리케이션 개발 팀의 경우 서비스 수준 목표를 정의하고, 오류 예산을 관리하는 데 이를 사용하는 것이 좋다. 다른 개발 집단의 경우 변경 실패 비율과 평균 사건 복구 시간의 감소를 측정하는 것이 이 연구에서 최상위 KPI였다.

학습, 실험, 멘토링의 영향을 입증 
오늘날, 지속 학습을 지원하고, 안전한 실험 환경을 촉진하고, 멘토링 프로그램 참여를 유도하는 일의 중요성을 인식하는 기업이 많다. 이들은 모두 중요한 목표이고 매니저는 개발자가 이들을 어떻게 실천하는지, 그리고 이들이 어느 곳에 영향을 주는 지를 평가해야 한다. 매니저는 개발자가 경력 발전 계획을 만드는 일을 지원해야 하고, 이들의 학습, 멘토링, 그리고 실험 및 개념 증명에의 참여가 직원의 경력 목표에 합치하는 지에 관해 피드백을 제공해야 한다.

일-삶 목표 및 목적을 제시하도록 개발자에게 요청 
다이스 2021 기술 전문가 정서 보고서(Dice 2021 Technologist Sentiment Report)에서는 36%의 응답자가 자신의 번아웃 수준을 5점 척도 상에서 4 또는 5로 평가했고, 48%가 직장을 옮길 생각이라고 응답했다.

필자는 CIO, CTO, 관리 책임자, 소프트웨어 개발 매니저가 소프트웨어 개발자의 번아웃 및 ‘대량 퇴직’ 동참을 보고 싶어한다고는 생각하지 않는다. 따라서 여기서 소프트웨어 개발자를 관리하는 방법을 소개하고 있기는 하지만 리더는 오늘날의 근무 환경과 개발자의 개인적 상황을 공감해야 한다. 

한가지 균형을 맞추는 방법은 HR과 함께 일-삶 목표 및 목적을 정의하는 것이다. 개발자는 이들 목표를 개별화해야 하고, 조직과 매니저는 이들 목표에 단서를 달아야 한다. 오늘날 일-삶 목표는 여러 개발자가 지원받는다고 느끼기 위해 필요한 균형을 생성할 수 있다. 

궁극적으로, 성과를 관리하고 측정하는 일은 매니저와 직원 사이의 빈번한 논의를 요구한다. 예를 들어 목표와 성공 기준에 합치하는지, 기준과 제약을 이해하고 있는지를 논의하는 것이다. 지표가 무언가를 가리킬 수는 있겠지만 성과 개선은 흔히 논의 및 후속 행동에 의해 이루어진다. 그냥 사람들이 일하는 방식이 그렇다.   

* Isaac Sacolick는 애자일, 데브옵스, 데이터 과학을 다룬 ‘Driving Digital: The Leader’s Guide to Business Transformation through Technology’의 저자다. ciokr@idg.co.kr
 
Sponsored
추천 테크라이브러리

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

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

Copyright © 2022 International Data Group. All rights reserved.