개발자 성과 평가에는 개발자 경험을 고려해야 한다 (with DevEx Framework)

부제: 성과 측정 및 개선을 위한 개발자 중심 접근 방식

이 글은 DevEx: What Actually Drives Productivity 의 내용을 참고하여 작성되었습니다

네카라쿠배당토직야 … 몰두센

개발자의 연봉을 많이 주는 회사들을 나열하여 부르는 신조어입니다. 하지만 돈만 많이 준다고 이렇게까지 모아 부르지는 않을 것 같습니다.

네이버, 카카오, 쿠팡, 배달의민족, 당근마켓, 토스, 직방, 야놀자, 몰로코, 두나무, 센드버드

다들 공통점이 있습니다. 이 회사들에 다니는 개발자들의 근무경험이 좋다는 것입니다. 바로 이것이 DevEx Framework 에서 집중하고 있는 부분입니다.

이 글에서는 DevEx Framework 분석을 통해 개발자 경험이 왜 중요한지에 대해 알아보고, 이것을 활용하여 성과 지표가 오염되는 것을 방지할 방법을 찾아보도록 하겠습니다.

Dev (eloper) Ex (perience) Framework

2020년 맥킨지의 연구에 따르면 개발자를 위한 ‘더 나은 업무 환경’ 을 갖춘 기업은 경쟁사보다 4~5배 더 높은 매출 성장을 달성한 것으로 나타났습니다.

개발자 경험을 올리기 위해 좋은 기기, 좋은 의자와 책상만 사주면 된다고 오해하는 경우가 많습니다. 하지만 연구 결과에 따르면 프로젝트의 명확한 목표, 팀 내 심리적 안정감 등 인적 요소가 개발자의 성과에 상당한 영향을 미치는 것으로 나타났습니다. 개발자 경험을 개선하면 성과 뿐만 아니라 만족도, 참여도, 직원 유지율도 높아집니다.

‘더 나은 업무 환경’ 이란 개발자가 자신의 업무에 대해 어떻게 느끼고, 생각하고, 가치를 부여하는지를 포함합니다. 연구팀은 개발중단, 비현실적인 마감일, 개발 도구 부족 등은 부정적인 영향을 미치는 반면, 명확한 작업, 잘 정리된 코드, 원활한 릴리스 프로세스 등은 이를 개선한다는 것을 연구를 통해 증명해냈습니다.

과도한 빌드 시간이나 어려운 인프라와 같은 근본적인 문제는 리더나 전담 팀을 필요로 합니다. 반면에 업무 중단시간이나 명확한 업무 정의와 같은 보다 국지적인 문제는 팀이나 개인의 필요에 맞는 구체적인 개선 노력이 필요할 수 있습니다.

DevEx의 세 가지 차원

DevEx Framework 는 개발자 경험을 피드백 루프, 인지적 부하, 흐름 상태라는 세 가지 핵심 차원으로 개발자가 직면하게 되는 모든 종류의 방해 유형을 요약합니다.

피드백 루프(Feedback Loops)

개발조직은 보통 리드타임을 줄이거나 업무 허들을 제거하여 서비스 제공 사이클을 최적화하는 방법을 취합니다. 이를 통해 고객 피드백 사이클 및 학습이 빨라지고, 결과적으로 더 신속하게 비즈니스를 수행할 수 있습니다. 연구를 통하여 배포 빈도를 높이고 리드 타임을 짧게 유지하는 조직은 경쟁사보다 성과 목표를 초과 달성할 가능성이 두 배나 높다는 사실을 수치로 증명했습니다.

무언가를 실행하거나 빌드를 돌리고, 배포를 하는 등 수행한 작업에 대한 응답의 속도와 품질을 단축하는 것도 개발자 경험을 개선하는 데 있어 매우 중요합니다. 일반적인 개발자의 하루는 도구와 사람 모두의 피드백에 의존하는 수많은 작업으로 구성됩니다. 예를 들어 개발자는 코드가 다시 컴파일 되거나 테스트가 실행되기를 기다리는 데 상당한 시간을 소비할 수 있습니다. 2022년 GitHub에서 실시한 조사에 따르면 빌드 시간을 기다리는 동안의 개발자 인건비와 빌드 시간을 개선하기 위한 하드웨어 구매비용을 비교해보았을 때 명확하게 하드웨어 구매비용이 낮음을 알아냈습니다.

피드백 루프를 빠르게 하면 개발자는 컨텍스트 스위칭을 최소화하면서 신속하게 작업을 완료할 수 있습니다. 반면 피드백 루프가 느릴 때에는 개발 프로세스가 중단되어 개발자가 기다리거나 컨텍스트 스위칭을 해야만 하게 만들어 개발자의 근무 만족도를 낮추게 됩니다. 개발자의 경험 뿐만 아니라 느린 피드백 루프는 시스템 또는 사람의 피드백이 반환되어 치명적인 버그가 발생하여 빠르게 배포가 필요한 상황에 추가적인 문제들을 유발합니다. 개발자 경험을 개선하기 위해 조직은 개발 도구를 가속화할 수 있는 영역(예: 빌드 및 테스트 프로세스, 개발 환경 설정)을 파악하거나 사람 간의 핸드오프 프로세스(예: 코드리뷰)를 개선하여 피드백 루프를 단축해야 합니다. 또한 팀 간의 핸드오프 프로세스 개선을 위해 조직 구조를 최적화해야 합니다.

인지 부하(Cognitive Load)

개발은 본질적으로 복잡하며, 점점 더 많은 도구와 기술로 인해 개발자가 부담해야 하는 인지적 부하가 더욱 가중되고 있습니다. 인지 부하는 개발자가 작업을 수행하는 데 필요한 정신 에너지의 양을 뜻합니다. 예를 들어, 개발자가 본질적으로 어렵거나 복잡한 작업을 수행하거나 익숙하지 않은 개발 프레임워크를 이해하고 학습해야 하는 경우 일반적으로 인지 부하가 증가하게 됩니다.

이런 인지 부하는 개발자의 가장 중요한 역할인 고객에게 가치를 제공하는 것에 방해가 됩니다. 제대로 문서화되지 않은 코드나 시스템과 같은 문제로 인해 인지 부하가 높은 경우 개발자는 작업을 완료하고 실수를 방지하기 위해 더 많은 시간과 노력을 투자해야 합니다.

개발자 경험을 개선하기 위해 팀과 조직은 개발 프로세스에서 굳이 개발자가 고려하지 않아도 되는 불필요한 장애물을 제거하여 인지적 부하를 줄이는 것을 목표로 삼아야 합니다. 개발자가 작업하는 시스템에 대한 이해를 돕고 프로젝트를 완료하는 데 필요한 컨텍스트 또는 작업 전환의 양을 줄이기 위해 잘 정리된 코드와 문서를 작성하는 데 중점을 두어야 합니다. 전담 팀은 개발자가 개발 및 릴리스 단계를 간소화할 수 있도록 사용하기 쉬운 DevOps 도구를 제공해야 합니다.

흐름 상태(Flow State)

개발자들은 종종 ‘흐름 탔다’ 또는 ‘몰입하고 있다’ 고 말합니다. 이러한 표현은 개발자들이 개발을 하는 동안 활기찬 집중력, 완전한 몰입감, 즐거움에 완전히 몰입한 정신 상태의 개념을 말합니다.

직장에서 ‘몰입하는’ 경험을 자주하면 생산성, 혁신, 직원 개발 및 만족도가 높아집니다. 즐겁게 일하는 개발자가 더 나은 성과를 내고 더 높은 품질의 제품을 생산한다는 연구 결과도 있습니다.

피드백 루프 차원과 관련된 중단과 지연은 개발자가 몰입하는 데 방해가 되는 중요한 요소입니다. 그 외에도 몰입하기 위해 전제되어야 할 것들로는 업무 구조에 대한 자율성, 명확한 팀 및 프로젝트 목표, 자극적이고 도전적인 작업에 참여하는 것 등이 있습니다.

‘몰입하는’ 경험을 활용하여 개발자 경험을 개선하기 위해 팀과 조직은 최적의 조건을 만드는 데 집중해야 합니다. 회의를 클러스터링하고, 계획에 없던 작업을 피하고, 지원 요청을 일괄 처리하여 중단을 최소화해야 합니다. 또한 리더는 개발자에게 자율성과 도전 과제를 해결할 수 있는 기회를 제공하는 긍정적인 팀 문화를 조성하는 것이 중요함을 인식해야 합니다.

DevEx Framework 로 측정하기

무언가를 개선하고자 한다면 개선이 잘 되고 있음을 개선 과정 전반에서 측정하여 지속적으로 추적해나가야 합니다. 측정하는 것은 개선 기회를 파악하고, 추세를 감지하고, ROI를 알아내는 데에 매우 중요합니다.

개발자 성과와 마찬가지로 개발자 경험도 하나의 지표나 차원으로 요약할 수 없습니다. 팀과 조직은 개발자 경험을 이루는 요소들이 복잡하다는 것을 인지하고 본격적으로 측정함으로써 직원과 팀의 업무 방식을 더 잘 이해하고 더 나은 의사 결정을 내릴 수 있습니다.

개발자 경험 측정의 핵심은 개발자와 소프트웨어 제공에 대한 개발자의 실제 경험에 초점을 맞추는 것입니다. 여기에는 엔지니어링 시스템의 지표 뿐만 아니라 해당 시스템을 사용하고 상호 작용하는 개발자 경험에 대한 인식과 협업 및 문화와 같은 사회적 요소도 파악하는 것이 중요합니다.

측정 대상

DevEx의 세 가지 차원은 개발자 경험의 전체 범위를 정확하게 측정하려면 설문조사로 얻는 개발자의 개발자 경험에 대한 인식과 워크플로우를 파악하는 것뿐만 아니라 더 큰 그림을 파악할 수 있는 전반적인 KPI(핵심 성과 지표) 또는 “북극성 지표” 도 필요합니다.

측정은 총 세가지 영역에서 이루어집니다.

1.Perceptions: 개발자 경험에 대한 설문

피드백 루프(Feedback Loops)

• 자동화된 테스트 속도 및 결과에 대한 만족도
• 변경 사항을 검증하는 데 걸리는 시간에 대한 만족도
• 변경 사항을 배포하는 데 걸리는 시간에 대한 만족도

인지 부하(Cognitive Load)

• 코드 복잡도에 대한 인식
• 개발환경의 디버깅 용이성에 대한 만족도
• 문서 접근 및 품질에 대한 만족도

흐름 상태(Flow State)

• 집중할 수 있는 정도와 업무 허들에 대한 인식
• 작업 또는 프로젝트 목표 명확성에 대한 만족도
• 컨퍼런스콜 품질에 대한 만족도

2.Workflows: 시스템과 업무 프로세스에서 측정되는 데이터

피드백 루프(Feedback Loops)

• CI(Continuous Integration) 에 걸리는 시간
• 코드리뷰 처리시간
• 배포 리드 타임(변경 사항을 배포하는 데까지 걸리는 시간)

인지 부하(Cognitive Load)

• 기술적인 질문에 대한 답변을 얻는 데 걸리는 시간
• 변경 사항을 배포하는 데 필요한 수동 작업의 양
• 문서가 최신화 되는 빈도

흐름 상태(Flow State)

• 회의나 업무 허들이 없는 시간
• 계획되지 않은 태스크나 요청을 처리하는 빈도
• 개인이 아닌 팀 차원에서의 처리가 필요한 빈도

3.KPIs: KPI 또는 북극성 지표

• 전반적으로 인식되는 소프트웨어 제공 프로세스가 원활한 정도
• 개발자 참여도 또는 만족도
• 생산성에 대한 인식 정도

개발자 경험에 대한 인식과 워크플로 비교분석의 필요성

개발자 경험을 측정하려면 엔지니어링 시스템과 프로세스에 대한 객관적인 데이터뿐만 아니라 개발자의 태도, 감정, 의견 등의 개발자가 느끼는 개발자 경험에 대한 인식도 파악해야 합니다. 개발자는 스스로 말하는 인식 정도와 경험을 통해 DevEx의 세 가지 차원에 걸쳐 직접적인 신호를 제공합니다. 또한 시스템과 프로세스에 대한 객관적인 데이터는 업무 허들에 대한 인사이트와 개선 방법을 제공합니다.

개발자 경험에 대한 인식을 측정하는 것과 워크플로우의 비교 분석이 모두 필요한 이유는 둘 중 어느 하나만으로는 전체 상황을 파악할 수 없기 때문입니다. 예를 들어 코드 리뷰 처리 시간이 겉으로 보기에는 빨라 보여도 코드 리뷰가 정기적으로 작업 진행을 방해한다면 개발자들은 여전히 코드리뷰가 방해가 된다고 느낄 수 있습니다. 반대로 개발자가 빌드 프로세스에 만족한다고 느끼더라도 빌드 시간과 같은 객관적인 지표를 사용해서 측정했을 때 피드백 루프가 느리고 개발 워크플로가 간소화되지 않은 것을 확인해볼 수 있습니다.

대부분의 개발자들은 리더가 성과지표를 오용하거나 잘못 해석하는 것에 대해 우려합니다. 개발자 경험에 대한 인식을 측정하면 리더가 개발자의 업무에 대해 관리자의 관점으로 설계한 지표 간의 균형을 맞추는 데 도움이 될 수 있습니다.

KPI의 중요성

개별 요소에만 집중하면 조직은 더 큰 그림을 놓치고 국지적인 영역에만 투자하게 될 위험이 있습니다. 따라서 조직은 이니셔티브의 ‘북극성 지표’ 역할을 하게 될 개발자 경험에 대한 상위 수준의 KPI도 측정하는 것이 중요합니다. 잘 설계된 KPI는 생산성, 만족도, 참여도, 리텐션 등 개발자 경험의 개선과 연관되어 있고 이를 통해 달성하고자 하는 결과를 측정할 수 있습니다.

이런 KPI는 조직이 개발자 경험에만 치중하지 않고 전략적 우선순위를 설정하고 노력의 전체 영향을 파악하는 데 도움이 됩니다. 예를 들어, 팀 회의를 줄이면 심층 작업과 관련된 개발자 경험의 개별 요소를 개선할 수 있습니다. 그러나 회의를 줄이면 동료 간의 협업이 더 어려워져 전반적인 만족도에 대한 KPI가 저하될 수 있습니다. KPI에 주의를 기울이면 만족도를 동시에 떨어뜨리지 않으면서도 작업 시간을 개선할 수 있는 전략으로 팀을 이끌 수 있습니다.

실제 사례

대기업 뿐만 아니라 중소기업과 스타트업에서도 조직이 발전함에 따라 엔지니어링 효율성, 제품 품질 및 직원 유지율의 개선을 통해 비즈니스 성과를 촉진시킬 수 있습니다. 개발자 성과를 종합적으로 파악하기는 여전히 어렵지만, 개발자 경험을 측정하고 평가하여 개선하는 것은 비즈니스 가치를 창출할 수 있는 것이 여러 실제사례를 통해 입증되었습니다.

eBay: 개발자 속도 가속화

글로벌 이커머스 리더인 eBay는 소프트웨어 제공을 비즈니스의 경쟁 우위로 만들기 위한 새로운 방법을 지속적으로 모색하고 있었습니다.

이베이는 개발자의 생산성과 경험을 개선하는 데 초점을 맞춘 다년간의 ‘속도 이니셔티브’ 를 가지고 있습니다. 피드백 루프와 인지 부하를 개선하는 것은 eBay의 주요 중점 분야이며, 내부 플랫폼 및 DevEx 조직은 경험 개선을 추진하기 위해 문제 영역에 대한 인사이트를 수집하는 일을 담당하고 있습니다.

DevEx 팀은 분기별 설문조사를 통해 전반적인 개발자 만족도 및 개발 용이성 등의 KPI를 파악하여 개발자 경험을 측정합니다. 또한 설문조사를 통해 일상 업무의 다양한 영역에 대한 개발자의 인식과 워크플로우를 파악합니다. 이 데이터는 엔지니어링 시스템과 포커스 그룹 토론에서 얻은 실시간 인사이트로 보강되어 구체적인 개선 사항을 결정하고 구현합니다.

DevEx 팀은 이러한 인사이트를 바탕으로 조직 전반의 툴링 및 문서 격차 해소, 개발 및 릴리스를 위한 수동 단계 및 프로세스 제거, 도메인 간 팀 상호 작용 간소화 등의 이니셔티브를 주도해 왔습니다. DevEx 팀은 출시 지원을 위해 기능 팀과 긴밀히 협력하고 정기적인 회고, 데모 및 교육 세션을 진행합니다.

개발자의 속도를 높이고 소프트웨어 배포를 경쟁 우위로 구축하기 위한 eBay의 투자는 계속되고 있으며, 그 진전을 더욱 가속화하고 있습니다. 지난 한 해 동안 개발자들은 개선된 기능을 통해 출시 빈도를 두 배로 늘리고 배포 리드 타임을 6배나 단축할 수 있었습니다.

무엇보다도 eBay는 개발자가 매일 신나게 출근하고 훌륭한 고객 성과를 창출하는 데 필요한 도구를 갖출 수 있도록 하는 것을 목표로 합니다.

Pfizer: 빛의 속도로 실현한 혁신

9개월 만에 코로나19 백신 개발에 성공한 이후, Pfizer는 개발자들이 “빠른 속도로 혁신을 이룰 수 있도록” DevEx를 개선하기 위한 작업에 착수했습니다.

Pfizer의 엔지니어링 조직은 2018년부터 2022년까지 10배 가까이 성장하는 동시에 오픈 소스 및 클라우드 네이티브 기술을 통해 소프트웨어 제공 역량을 현대화했습니다. 현재 Pfizer의 DevEx 팀은 개발자 환경 개선을 통해 팀이 더 빠르게 제공할 수 있도록 지원하는 추가적인 방법을 찾는 데 집중하고 있습니다.

규제가 심한 환경에서 운영되고 있지만 Pfizer의 리더들은 소규모 팀의 이점과 개발자가 창의적인 조직이 될 수 있도록 역량을 강화하는 것이 중요하다고 믿습니다. 이러한 목표를 지원하기 위해 DevEx 팀은 주로 피드백 루프와 흐름 상태라는 두 가지 차원의 개발자 경험에 중점을 두고 있습니다. 분기별 설문조사를 통해 전반적인 만족도 및 참여도와 같은 KPI는 물론 코드베이스 품질 및 팀 자율성과 같은 보다 구체적인 요소도 파악합니다. DevEx 팀은 집계된 결과를 분석하여 자체 이니셔티브를 계획할 뿐만 아니라 개별 팀에 맞춤형 인사이트를 제공합니다.

Pfizer는 각 팀에 전담 시간과 리소스를 제공하여 각 팀이 자체적으로 현지에서 개선할 수 있도록 지원합니다. 각 팀이 자신의 영향력 범위 내에서 개선 사항을 해결할 수 있는 기회를 제공함으로써 Pfizer는 탑다운 노력만으로 달성할 수 있는 것보다 훨씬 빠른 속도로 혁신할 수 있었습니다. 이 혁신적인 접근 방식 덕분에 DevEx 팀은 통합 개발자 포털을 만들고, 팀 간 코드 중복을 줄이고, 소스 제어 관리를 위한 도구를 개선하는 등 전사적인 이니셔티브를 관리할 수 있는 여유를 갖게 되었습니다.

우리 회사에 적용해보기

개발자 경험에 대한 인식과 더불어 업무와 관련된 다양한 시스템 및 프로세스에서 개발자의 워크플로우를 파악하여 측정해야 합니다. 이를 위해 조직은 소프트웨어 제공 프로세스에 대한 완전한 가시성을 확보하기 위해 사람과 시스템 모두에서 데이터를 수집해야 합니다 (관련 아티클: Measuring Developer Productivity via Humans)

특히 ‘설문조사’는 개발자 경험을 측정하고 소프트웨어 배포 프로세스에서 마찰이 발생하는 지점에 대한 개발자의 피드백을 수집하는 데 유용한 도구입니다. 설문조사 데이터는 신속하게 수집할 수 있으며(대개 몇 주 이내에), 올바르게 설계하면 빠르고 정확하게 측정하여 평가하고 개선까지 이끌어낼 수 있습니다.

많은 조직이 시간이 지나도 높은 설문조사 참여율을 유지하는 데 어려움을 겪고 있습니다. 피드백이 부족하다면 개발자는 설문조사에 반복적으로 응답하는 것이 가치 있는 일이 아니라고 생각하는 경우가 많습니다. 따라서 리더와 팀은 설문조사의 데이터를 빠르게 수집하고 분석하여 정기적으로 피드백 해야 합니다.

이것을 보완하는 방법으로 트랜잭션 설문조사가 존재합니다. 트랜잭션 설문조사는 개발자 워크플로우의 특정 접점이나 상호작용 중에 자연스럽게 피드백을 수집합니다. 예를 들어 플랫폼 팀은 트랜잭션 설문조사를 사용하여 CLI(명령줄 인터페이스) 도구를 설치하는 동안 특정 오류가 발생했을 때 개발자에게 피드백을 요청할 수 있습니다. 또한 트랜잭션 설문조사는 더 높은 빈도의 피드백과 더 세분화된 인사이트를 생성하여 정기 설문조사의 데이터를 보강할 수 있습니다.

조직 리더들이 흔히 저지르는 실수는 팀과 페르소나(예: 역할, 근속 기간, 연차)별로 세분화된 데이터 대신 회사 전체의 성과에 초점을 맞추는 것입니다. 앞서 설명했듯이 개발자 경험은 상황에 따라 크게 달라지며 팀이나 역할에 따라 크게 다를 수 있습니다. 범용적인 지표에만 초점을 맞추면 회사 내에서 작지만 중요한 집단에 영향을 미치는 개발자에 대한 객관적인 데이터를 얻어낼 수 없게 될 수 있습니다.

또한 위에서 언급한 것과 같이 한가지 영역에서만 수집된 데이터로는 객관적인 인사이트를 얻을 수 없습니다. 개발자 경험에 대한 설문조사를 보강하려면 조직은 시스템에서도 데이터를 수집해야 합니다. 그러나 E2E 시스템 데이터를 확보하는 것은 어려우며, 무수히 많은 서로 다른 도구와 팀에서 데이터를 추출하고 수집하여 가공해야 합니다. 기술 부채에 대한 개발자의 정서는 일반적으로 부정적이기 때문에 문제를 파악하거나 그 규모를 측정하기가 어렵습니다. 그러나 동료 팀보다 감정 점수가 낮은 팀과 업계 경쟁사보다 점수가 낮은 조직은 주목할 만한 개선의 기회를 포착할 수 있습니다.

따라서 설문조사와 시스템 데이터를 모두 얻으려면 조직 내에 이 과정을 위해 통합된 시스템이 반드시 필요하다고 볼 수 있습니다.

마무리

측정은 성장하는 조직이 트렌드를 파악하고 이해하며, 투자를 시작할 적절한 시기를 결정하고, 원격 근무 및 AI 기반 프로그래밍과 같은 거시적 변화를 탐색하는 데 도움이 될 수 있습니다.

DevEx 프레임워크는 리더에게 개발자 생산성 향상을 위해 무엇을 측정하고 집중해야 하는지에 대한 시각을 제공합니다. 피드백 루프, 인지적 부하, 흐름 상태라는 세 가지 차원을 종합하면 개발자 경험을 이해하기 위한 실용적인 프레임워크를 제공하며, 함께 제공되는 측정 접근 방식은 체계적으로 개선을 유도합니다.

조직에서 진행하는 개발자 성과 측정 및 평가를 위한 활동에 개발자 경험이 고려되어야만 개발자와 매니저 간 입장 차이를 제거하여 현실적이고 정확한 성과 측정이 가능 합니다. 그렇게 된다면 실제 평가를 받게 되는 개발자들도 역량이 입증 받거나 성장의 가능성을 얻는 방향으로 상호간 만족하는 결과를 얻을 수 있을 것입니다.

다음 주제로는 이 글에서 언급된 사람을 통한 평가에 대한 중요성(Measuring Developer Productivity via Humans)을 다뤄보도록 하겠습니다.

개발자 성과 평가에는 개발자 경험을 고려해야 한다 (with DevEx Framework) was originally published in 프루퍼 블로그 on Medium, where people are continuing the conversation by highlighting and responding to this story.