칼럼 | 생산성 10배 ‘10x 개발자’는 허구다

'10x 개발자(10x developer)', 다른 개발자에 비해 10배 더 생산적이라는 의미의 이 수수께끼 같은 용어는 빅풋(Bigfoot)과 공통점이 많다. 실제로 본 사람이 거의 없고 존재가 확인되지도 않았다. 그러나 빅풋의 생김새는 많은 사람이 희미하게나마 아는 것과 달리 '10x 개발자'에 대해서는 알려진 바가 거의 없다. 
 

그 이유는 10x 개발자가 명확하지 않은 전제를 기반으로 한 개념이기 때문이다. 즉, 보편적으로 합의된 개인 생산성에 대한 지표를 통해 팀원의 상대적 생산성을 평가할 수 있다고 전제한다. 그러나 이런 지표는 존재하지 않을 뿐더러, 설사 개인 생산성에 대한 신뢰할 수 있는 지표가 있다고 해도 이 지표를 비즈니스 성과와 연결하는 것은 또다른 이야기다. 많은 IT 리더가 '10x 개발자' 같은 개념을 좇느니, 성과가 확실히 떨어지는 개발자 관련 문제를 해결하는 데 초점을 두는 것도 이 때문이다.

'10x 개발자' 개념은 1987년경 피플웨어(Peopleware)에 게재된 연구에 처음 등장했는데, 이미 그 당시부터 개발자 사이에서 조롱과 무시의 대상이 됐다. 그런데도 IT 리더십 사이에서는 여전히 회자되는 이유는 무엇일까? 생산성은 주로 사람에 관한 문제이며, 채용 방법, 기술 간극 분석, 교육, 활동 모니터링, 설문조사, 보상 전략과 같은 관리 모범 사례와 툴을 통해 생산성을 관리할 수 있다는 '일반적인 가정'과 일맥상통하기 때문이다. 

이론적으로는 이런 툴을 사용해 최고 성과자, 즉 '10x 개발자'를 찾아 육성하고 유지하면 탁월한 수준의 생산성을 얻을 수 있다. 이렇게 팀원 모두가 (도무지 정체를 알 수 없는) 10x 개발자가 될 수 있다는 희망을 품은 채 일하면 전체 팀의 생산성 기준점을 높일 수 있다는 것이다.
 

개발자 생산성 엔지니어링의 등장 

그러나 노련한 개발팀은 기존의 많은 생산성 관리 접근 방법이 효과가 있는 것은 분명하지만, 충분하지는 않다는 것을 안다. 또한, 개인의 생산성을 1에서 10x 개발자로 확장하는 데 집중하는 접근 방법의 한계도 알고 있다. 그래서 노련한 기업은 '10x 개발자' 같은 모호한 개념이 아니라 개발자 생산성에 대한 더 현대적인 접근 방법인 '개발자 생산성 엔지니어링(DPE)"을 채택한다.

실제로 DPE는 에어비앤비, 아메리칸 익스프레스, 애플, JP모건 체이스, 구글, 넷플릭스와 같은 기업에서 개발자 생산성과 개발자 경험을 개선하기 위해 사용하는 새로운 방법이다. 

DPE는 핵심은 '10x 개발자' 육성에서 '10x 팀' 구축으로 초점을 전환하는 것이다. 10x 개발자 개념에 비판적이라면 '10x 개발팀' 개념에 대해서는 아마도 10배 더 회의적일 텐데, 실제로 DPE 자체만으로 10x 팀을 만들 수는 없다. 가장 중요한 것은 '10x 개발팀'의 개념을 DPE를 통해 실현 가능하고 지속적으로 개선하는 비전과 전략으로 설정하는 것이다. 이는 10x 개발팀을 만드는 여정 자체를 성공적으로 끌어 나가는 것이 매우 중요하다는 것을 의미한다. 이를 위해 자동화, 실행가능한 데이터, 가속화 기술 등 3가지를 활용한다.
 

사람의 문제에서 기술적 과제로 

구체적으로 10x 팀은 개발 생산성을 보는 시각을 관리 모범 사례로 해결 가능한 사람의 문제에서 엔지니어링된 솔루션으로 해결할 수 있는 기술적 과제로 전환한다. 엔지니어링된 솔루션은 자동화와 데이터를 활용하는 가속 기술과 분석을 통해 생산성 병목 현상과 프로세스 마찰을 해결한다. 

즉, 기존 개발자 생산성 관리가 “빌드 및 테스트 사이클이 완료될 때까지 기다리는 동안 어떻게 개발자의 생산성을 더 높일 수 있을까?”와 같은 질문의 답을 찾는 데 집중했다면 DPE는 “애초에 빌드 및 테스트 사이클이 완료되는 데 왜 이렇게 많은 시간이 걸릴까? 데이터와 기술로 이 문제를 해결하려면 어떻게 해야 할까?”를 묻는다. 

예를 들어 개발자 생산성을 저해하는 가장 큰 문제 중 하나는 유휴 시간과 불필요한 맥락 전환을 유발하는 느린 빌드 및 테스트다. 빌드 캐싱, 머신러닝 기반 테스트 선택, 테스트 배포와 같은 엔지니어링된 성능 가속 기술을 이용해 빌드 시간을 최대 90% 줄일 수 있다. 그 결과 개발자는 기다리면서 낭비하는 시간을 줄이고, 창의적 흐름을 유지하면서 빌드와 테스트를 더 자주 수행할 수 있다. 

빌드 및 테스트의 이 같은 리엔지니어링에는 개발자 생산성과 품질에 대한 '시프트 레프트(shift left)' 효과가 있다. 문제를 탐지하고 수정하는 데 더 많은 비용이 드는 CI 과정에서 문제가 드러날 가능성이 줄어든다. 또한 장애가 발생하는 경우 망가진 빌드 문제를 해결하는 과정에 많은 노동과 피로가 발생할 수 있다. 그래들 빌드 스캔(Gradle Build Scan)과 같은 DPE 기술을 사용하면 빌드 실패의 근본 원인을 더 효율적으로 찾아 해결할 수 있다. 
 

개인별 산출량에서 팀 성과로 

기존 개발자 생산성 관리는 개인별 산출량에 초점을 두는 반면 DPE는 팀 성과를 우선한다. 경험 많은 개발팀은 생산성 산출량을 인적 지표로 산출할 수 없다는 것을 안다. 인적 지표는 조작이 가능하고 전체적인 맥락을 반영하지 않으며, 경우에 따라 완전히 현실과 동떨어지기도 한다. 게다가 오히려 비생산적인 행동을 장려할 수도 있다. 기능 점수 또는 해결된 버그 측면에서 산출량이 측정되기 때문에 귀중한 멘토링 기술을 쌓는 데는 시간을 덜 쓸 수밖에 없고, 많은 산출량 지표가 장황한 코드를 높게 보상하므로 간결한 코드를 작성하는 기술에 정면으로 반한다. 

또한 DPE는 소프트웨어 개발 수명 주기와 툴체인에 존재하는 병목 지점을 목표로 삼아 이 부분의 속도를 높이는 데 사용할 수 있는 데이터를 제공한다. 주요 지표로는 빌드 및 테스트 시간, 비용 절감, 실패율, 평균 장애 복구 시간 등이다. DPE 솔루션은 개인을 대상으로 하지 않고 모든 개발자에게 동등하게 혜택을 제공함으로써 마치 밀물이 모든 배를 들어 올리듯 전체 팀의 기본 생산성 기준을 높인다. 특히 중요한 것은 이러한 지표가 소프트웨어 개발 시간, 개발 비용, 품질, 브랜드와 같은 비즈니스 성과에 신뢰성 있게 연결된다는 점이다.
 

소프트 ROI에서 하드 ROI 투자로의 의사 결정 

기존 생산성 관리 정책에서는 투자 수익을 확인할 수 없다. 반면 DPE 지표는 측정 가능한 비즈니스 성과를 제공한다. 이 비즈니스 성과는 돈으로 환산해 하드 ROI를 판단하고 초기 비즈니스 사례와 DPE의 성숙화를 위한 지속적인 투자의 근거를 제시하는 데 사용할 수 있다. 

예를 들어 DPE 성능 기술을 활용한 빌드 및 테스트 피드백 사이클 속도 개선에서 얻은 절감 효과는 간단한 공식을 사용해 계산할 수 있다. 절감된 빌드 완료 대기 시간과 연간 빌드 수를 곱해서 엔지니어링 연도에서 절감된 총 시간을 구한 다음 여기에 최대 부하 상태 엔지니어링 연도의 비용을 곱하면 된다. 중간 규모의 개발 팀이라면 두 자릿수 절감을 실현해 많게는 수백만 달러까지 비용을 절감할 수 있을 것이다.

DPE는 최신 기술을 사용해 팀 성과의 기준을 높인다는 점에서 궁극적으로 개발자 생산성에 대한 혁신적인 접근 방법이다. DPE를 실천한다고 해서 모두 10x 팀이 만들어지는 것은 아니지만, DPE는 지속적인 개선을 위한 전략을 제공한다. 비즈니스 가치는 목적지가 아닌 여정에 있으며, 이 여정을 헤쳐 나가는 것은 모든 기업의 경쟁력에서 매우 중요하다. 기업은 소프트웨어 개발자 사이에서 존재 여부조차 불확실한 빅풋, 10x 개발자를 찾는 데 집중하는 대신 DPE를 채택해 10x 팀을 추구해야 한다.
editor@itworld.co.kr