Offcanvas

리더십|조직관리

기고 | 뛰어난 SW 팀은 지표 대신 사기로 일한다

2022.07.27 Jeremy Duvall  |  InfoWorld
소프트웨어 팀 리더는 지표와 수치에 집착하곤 한다. 그러나 지표를 맹신하면 설사 팀의 능력이 뛰어나더라도, 혁신적인 솔루션이 탄생할 가능성이 오히려 줄어들 수 있다. 지표는 유용한 수단일 뿐, 비범한 결과는 결국 팀원의 사기에서 나온다. 
 
ⓒShutterstock

필자의 회사 같은 소프트웨어 업체(맞춤형 데브옵스 및 클라우드 솔루션 업체 7Factor Software)를 찾아오는 리더를 만나보면, 그들이 수치, 즉 결과물을 정량화한 지표에 얽매여 있다는 느낌을 가끔 받는다. 코드를 아름다울 정도로 깔끔하게 정리하는 리팩토링 작업에 대한 개발자의 애착을 이해하지 못하더라도, 예컨대 리팩토링을 하면 코드 커버리지가 85%에서 90%로 개선된다는 지표를 보여준다면 그들의 마음은 쉽게 바뀐다. 수치로 증명했기 때문이다! 그러니 그 가치를 부정하기는 힘들지 않은가? 

하지만, 수치를 신봉하는 것도 바람직하지 않다. 많은 수치가 터무니없으며, 심지어 측정값이 유효하더라도 수치 자체가 관리 도구가 될 수는 없다. 물론 수치는 유용하다. 그러나, 팀이 최우선적으로 따르는 기준이 돼서는 안 된다. 팀원 개개인이 핵심 주체가 되어 수치를 수단으로서만 활용해야지, 지표가 최우선이 된다면 수치가 가리키는 방향성에 묵종할 수밖에 없다.

훌륭한 엔지니어링팀이 진정으로 가치있는 소프트웨어 솔루션을 개발하도록 이끌려면 리더는 팀원의 사기, 만족도 그리고 팀 전체의 방향성을 관리하는 역할에 충실해야 한다. 또한 이런 리더십 스타일의 효과를 철저히 믿어야만 효율성과 품질을 모두 챙기는 기업 문화를 조성할 수 있다. 

지표 중심 리더십의 함정
사소한 예를 하나 생각해보자. 개발 스트린트마다 20개의 작업 티켓을 해치우는 한 엔지니어링팀이 있다. 지표가 더할 나위 없이 훌륭하다.  따라서 제품 관리자는 신이나 사내 관계자에게 일이 아주 잘 진행되고 있다고 보고하리라.
 
하지만 조금 더 자세히 살펴보면, 관리자는 이 팀이 주당 60시간씩 근무하면서 이 수치를 달성했다는 사실을 발견하게 된다. 팀은 피곤하고 지쳤으며, 오랫동안 보지 못한 가족과 친구를 그리워한다. 심지어 결과물이 어떤 가치가 있는지도 잘 모른다. 이 가련한 소프트웨어 엔지니어들은 손목 터널 증후군에 고통받으며, 눈을 게슴츠레하게 뜬 채 기계같이 키보드를 두드린다. 마치 끝이 안 보이는 생산 라인에서 내리 작동하는 자동화 로봇처럼 말이다. 

즉, 지표가 훌륭해 보일지라도 직원의 사기는 끔찍할 것이다. 

이런 악조건 속에서 점점 코드의 품질이 떨어지고, 개발 중인 솔루션이 완성됐을 때 그 품질이 원래 목표했던 기준과 멀어지는 것은 시간문제다. 자동화된 코드 테스트가 없고, 리팩토링도 거의 없으며, 심지어 돌려막기식(주먹구구식의)의 코드가 많다는 사실을 발견할 것이다. 기술 부채, 확장 문제, 원하는 사용자 경험과 구현된 코드 사이의 불협화음이 순식간에 눈덩이처럼 불어난다.  

게다가 엔지니어가 품질에 진심으로 신경 쓴다면(그렇지 않다면 애초에 고용해서는 안 된다), 결과물이 기대에 못 미친다는 사실을 알고 사기가 더욱더 곤두박질칠 공산이 크다.
 
이런 상황이 지속되면, 악재가 연달아 발생한다. 인재가 떠나고, 프로젝트 진행 중 신입 엔지니어의 온보딩이 지연되기도 한다. 

기업이 이렇게 사기 대신 지표에 치중한다면, 이런 문제를 조기에 발견하기란 매우 어렵다. 

직원 사기 관리의 세 기둥: 미션, 주체성, 성장 
여기서 필자가 말하는 ‘사기’라는 단어를 너무 거창하게 해석할 필요는 없다. 마치 국운이 달린 전쟁에 나가는 군대 사령관처럼 강력한 카리마스로 팀을 이끌어 그들이 모든 의지를 불태우도록 만들어야 한다는 말이 아니다.

필자가 강조하고자 하는 사기란 팀이 각 프로젝트의 성공에 지속 가능한 노력을 하도록 동기부여 하는 것을 말한다. 

다니엘 핑크가 자신의 2009년 베스트셀러 ‘주도하라: 우리에게 동기를 부여하는 것에 관한 놀라운 진실(Drive: The Surprising Truth About What Motivates Us)’에서 밝혔듯이, 인간의 가장 강력하고 진실된 동기는 자율성, 숙달 그리고 확고한 목표에서 비롯된다. 

물론 인위적인 지표와 이에 따른 보상은 몇몇 프로젝트의 품질을 보장해줄 것이다. 하지만 소프트웨어 엔지니어링 팀의 잠재력을 극대화하여 혁신적인 방식으로 유의미한 문제를 해결하며 새로운 가치를 창출하기는 어렵다. 

1.    직원 사기는 지표 대신 공통의 미션에서 우러나온다 
자기 자리에서 주어진 일만 고분고분 처리하는 “비버가 알아서 하겠지(Leave It to Beaver)”식의 업무 방식은 끝 난지 오래다. 특히 IT 분야는 밀레니엄 및 Z세대의 비율이 높고, 이 세대는 의미를 중시한다. 단순히 노동의 대가를 받는 거래적 고용 방식을 거부한다. 대신 나름의 철학과 목표가 있는 회사를 선호한다. 

게다가, 세대에 상관없이 뛰어난 개발자는 모두 자신만의 철학이 있는 경우가 많다. 흥미로운 문제를 해결하고 기술 부채 없이 양질의 코드를 개발하여 사용자에게 진정으로 가치 있는 솔루션을 만들고 싶어한다. (그리고 다시 한번 말하지만, 애초에 이렇게 생각하지 않는 개발자는 고용하지 말자)

따라서 이런 개발자를 동기부여 하는 데 무의미한 지표는 필요 없다. 팀이 각 프로젝트의 미션을 추구하도록 돕고, 성공의 길을 가로막는 장애물을 치워 최고의 성과를 내는 환경을 가꾸는 것에만 전념해야 한다.
 
ⓒShutterstock

리더가 프로젝트의 목적을 세세히 설명해주고 같이 논의해야 엔지니어들은 존중받는다고 느낀다. 리더는 ‘우리는 무엇을 하려 하는가?’, ‘우리가 이렇게 하는 이유는 무엇인가?’, ‘무엇이 핵심인가?’, ‘철학은 무엇인가?’ 같은 질문을 그들이 하지 않아도 먼저 대답해줘야 한다. 

여기서 중요한 것은, 꼭 거대한 목표를 세워야 한다는 의무감에 짓눌리지 않아도 된다는 점이다. 물론, 기후 위기에 맞서거나, 공공 보건 분야에서 생명을 구하는 등의 큰 목표를 이루려는 프로젝트를 할 수 있다면 얼마든지 해도 좋다. 이렇게 정의와 인류애로 가득 찬 미션은 팀에게 엄청난 동기부여가 될 것이다. 

하지만 이런 웅장한 목표가 있어야만 팀을 동기부여할 수 있는 것은 아니다.  가령 “윤리 기준을 준수하며. 흥미로운 문제를 매끄럽게 해결하는 좋은 소프트웨어를 만들자”라는 미션도 충분하다. 해결하려는 문제가 ‘장거리 트럭 운전자가 은행 시스템의 문제로 가족에게 집세를 송금하는 데 어려움을 겪고 있다’라거나 ‘구식 인프라가 다가구 주택의 중앙 제어 시스템 혁신을 가로막고 있다’ 같은, 작지만 구체적인 목표도 충분히 의미 있다. (실제로 필자의 회사가 고객들이 이런 문제를 해결하도록 도운 적이 있다.)

2. 직원 사기는 지표 대신 주체성으로 발휘된다 
자, 이제 팀원 모두가 공통의 문제의식과 목표를 공유한다. 하지만 팀원이 각자의 방식으로 미션에 기여하는 방식까지 간섭한다면, 오히려 역효과를 불러일으킬 위험이 있다.

어떤 팀은 산업을 변혁하거나, 생명을 구하거나 심지어 인류 역사에 남을 만한 무엇을 만들려는 미션을 가지고 있을지도 모른다. 그럼에도 리더가 최종 결정권을 가지고 있다면, 엔지니어의 체감 업무 방식은 다시 지표에 매달려 티켓 쿼터를 마무리하는 수준으로 회귀할 뿐이다. 미션에서 점점 멀어지기 시작할 것이다. 처음에 불타올랐던 동기부여가 수그러들면서 비판적 사고와 창의성이 상실된다. 
 
ⓒShutterstock

뛰어난 소프트웨어 엔지니어는 대부분 주체적이다. 리더가 할 일은 단순하다. 초반에 팀이 미션에 진심으로 동참하도록 논의하고, 이해관계자와 고객의 요구를 이해하도록 돕고, 최종 결과물이 지켜야 하는 필수 규칙과 지침을 안내하기만 하면 된다. 그다음에는 팀이 마음껏 일할 수 있도록 자리를 비키도록 하자. 그래야 최고의 품질을 달성하기 위해 팀원 개개인이 자신만의 방식으로 최고의 능률을 발휘하게 된다. 

물론, 주체적인 팀도 여전히 현명한 리더가 필요하다. ‘무정부 상태’는 자유 대신 혼란을 일으킬 잠재성을 지닌다. 

결국 리더에게는 자신이 맡은 팀이 문제를 스스로 해결할 수 있다고 믿는 마음가짐이 필요하다. 리더는 자기 팀이 잠재적인 문제점을 포착하고, 혁신적인 솔루션을 만들어낼 만한 훌륭한 집단이라고 굳게 믿어야 한다. 이러한 믿음이야말로 팀이 궁극적인 미션을 향해 정진하게 만드는 가장 큰 버팀목이 될 수 있다. 

그리고 만약 팀을 그만큼 신뢰할 수 없다면, 처음부터 다시 생각해봐야 한다. 정말 신뢰하기 어려울 정도로 능력이 부족한 사람을 고용한 건지, 아니면 충분히 뛰어난 인재인데도 이들을 잘 이끌 리더십이 부족한 건지 성찰해봐야 한다. 

아니면 혹시 아무도 몰랐던 임의의 프로세스가 엔지니어링을 방해하고 있을 수도 있다. 지표는 이런 문제를 포착해내지 못한다. 팀원 모두가 최고의 결과물을 만들려는 공통의 목표를 이루기 위해 주체적으로 일할 때만 이런 문제를 알아챌 수 있다. 

3. 직원 사기는 지표 대신 성장으로 지속된다 
‘성장’은 보통 엔지니어 각자의 능력과 그들이 이런 능력을 발전시킬 만한 기회와 연관된다. 하지면 조직 구조도 개인의 성장에 큰 역할을 한다. 반대로 바람직하지 않은 기업 구조, 예컨대 특정한 의사결정 방식이나 업무 방식은 엔지니어가 자랑스러워할 만한 결과물을 만드는 데 원동력이 될 때도 있지만, 반대로 걸림돌이 되기도 한다.
 
예컨대 기업은 이런 질문으로 엔지니어를 성장시키는 조직 문화를 가지고 있는지 확인해야 한다. 

엔지니어가 회사의 방향성을 명확히 이해하고 있는가? 필요한 개발 도구를 제공받으며, 이를 활용할 만한 시간을 갖는가? 프로젝트 마감일을 같이 논의하고, 중요한 결정을 내릴 권한이 있는가?

여기에 더해, 완성도가 높은 결과물을 내기 위한 시간이 충분한가? 새로운 개발 도구를 모색하고 이를 활용하는 방법을 탐구할 만한 여유가 있는가? 원한다면 잠시 쉬며 성찰의 시간을 가진 뒤 업무에 복귀할 수 있는가? 부여된 문제를 정말 제대로 해결하는 솔루션을 만들기 위해서 말이다.  

아니면, 혹시 지표의 독재(tyranny of metrics) 속에서 엉성한 코드라는 것을 알면서도 문제를 해결했다고 치부하고, 빨리 다음 업무 티켓으로 넘어가는 데만 분주한 것은 아닌가? 불필요한 회의와 절차로 많은 시간을 낭비하며 과로와 번아웃에 시달리고 있지는 않은가? 
 
ⓒShutterstock

깃허브 출신 엔지니어 아비 노다는 현재 DX(Developer Experience)라는 회사의 CEO다. 그는 위와 같은 질문이 개발자의 생산성과 비즈니스 성공에 영향을 이 주제에 대해 노다는 마이클라 그레일라 박사마가렛 앤 스토리와 함께 ‘개발자 경험 파악 및 개선: 실행 가능한 프레임워크(An Actionable Framework for Understanding and Improving Developer Experience)’(PDF)라는 글을 JTSE(Journal of Transaction on Software Engineering)에 기고했다. 그리고 그 또한 DX 백서에서 결과 또는 프로세스에 치중된 지표로는 개발자 경험을 정확히 측정할 수 없다고 밝혔다.

신뢰와 존중의 문화가 자리 잡혀 있는 기업의 리더는 팀원 모두가 양질의 소프트웨어를 개발하려는 의지로 무장했다고 가정한 채 프로젝트를 시작한다. 이런 문화에서는 지표를 무기 삼아 생산도를 측정하거나 성과를 내라고 압박하지 않는다. 대신에 팀원과 허심탄회하게 대화를 나눈다. 

이런 대화의 단초는 곧 ‘여기에서 무엇을 하려 하는가?’ (미션), ‘무엇이 방해되는가?’ (주체성), ‘최고의 성과를 위해 우리가 어떻게 지원할 수 있는가?’ (성장)라는 세 가지 질문으로 연결된다.  

높은 직원 사기, 모든 혁신 기업의 원천
직원 사기 증진의 핵심은 단순히 쾌적한 근무 환경과 높은 직원 만족도 점수가 아니다. 소프트웨어 엔지니어가 프로젝트를 수행할 때 자신이 최선이라 생각하는 방식으로 문제를 해결할 주체성을 보장받으며, 최고의 성과를 내기 위해 필요한 모든 지원을 받는다고 느껴야 정말 가치 있는 솔루션이 나온다. 

또한 이런 환경에서 직원이 오래 남아 있을 가능성도 커진다. 인재 추가 채용도 더 쉬워질 것이다.

궁극적으로, 직원의 사기에 정말 신경 쓴다면, 더 나은 기업 문화와 더 나은 커뮤니티로 이어지기도 한다. 모든 팀원이 즐겁게 참여하며, 최고의 인재가 진정으로 혁신적인 소프트웨어 솔루션을 내놓게 되리라. 

*Jeremy Duvall은 커스텀, 클라우드 네이티브 소프트웨어 솔루션 기업 7factor Software의 설립자다. 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.