??? ??? ?? ?? ?? ??? ???? ??? ?? ?? ? ??. ????? ???? ???? ???? ?? ?? ????. ?? ??? ?? ???? ??? ???? ???? ??? ??? ????? ????? ? ? ??? ?? ?? ? ?? ??? ? ??. 개발자 생산성 측정 방법 대한 의견은 조직이나 직급에 따라 다를 수 있다. 기본적으로 생산성을 정의하고 추적하는 것이 쉽지 때문이다. 그런 면에서 현재 기업에서 개발자 생산성을 논의하고 있다면 개발자 워크플로를 간소화하는 데 더 중점을 두는 것이 더 나은 선택일 수 있다. 대부분의 기업은 디지털 전략에 투자하며 직원의 생산성을 향상시킬 방법을 찾는다. 하지만 기술인력을 찾는 것은 쉽지 않다. 개발자는 부족하고 써야 할 소프트웨어는 많아지고 있다. 가트너 애널리스트인 키스 만(Keith Mann)는 “개발자를 찾기 어려워지면서 개발자 생산성을 이해하고 측정하는 것에 대한 관심이 높아졌다”라며 “조직은 제한된 수의 개발자를 최대한 활용해야 하는 상황이다. 가트너의 설문조사를 비롯해 최근 고객 문의를 보면 소프트웨어 엔지니어링 분야 리더에게 개발자 생산성이 최우선 과제임을 확인할 수 있다”라고 설명했다. 치과 치료 중개 서비스를 제공하는 캘리포니아 델타 덴탈(Delta Dental of California)의 CIO인 도미닉 팃콤(Dominic Titcombe)은 최근 생성형 AI의 발전이 새로운 업무 방식에 영감을 주었으며, 소프트웨어 제작을 가속화하기 위해 AI를 적용하는 것에 대해 많은 논의가 이루어졌다고 설명했다. 팃콤은 “개발 영역에서 깃허브 코파일럿 같은 훌륭한 도구를 이용하면 개발자의 생산성을 높일 수 있다”라고 설명했다. 금융 자동화 소프트웨어 및 결제 솔루션 제공업체인 아비드엑스창(AvidXchange)의 CIO인 엔젤릭 깁슨(Angelic Gibson)은 개발자 워크플로에서 업무 중단을 야기하는 요소를 제거하면 애자일 혁신을 강화할 수 있다라고 설명했다. 깁슨은 “혁신과 기술 배포에 집중하면 기술 팀을 방해하는 장애물을 정확히 찾아내고 제거할 수 있다”고 덧붙였다. 또한 깁슨은 소프트웨어 개발 생산량을 측정하는 것이 IT 디지털화에 필수적이지만, 건강한 팀 역학을 유지하기 위해서는 신중한 측정 방식이 필요하다고 강조했다. 깁슨은 “더 높은 주인의식을 갖고 업무에 더 전념하면서 결과적으로 관련 팀의 생산성이 높아질 수 있다”라고 밝혔다. 생산성 최적화를 위한 간소화가트너의 만에 따르면, 애자일 소프트웨어 개발은 혁신과 경쟁력 유지를 위해 필수적이다. 엔지니어링 분야 리더라면 소프트웨어 개발자의 생산성을 측정해야 해야 한다. 그리고 이를 효과적으로 측정하는 방법도 이해하고 위험 요소를 주의해야 한다. 만은 “생산성을 제대로 측정해야 한다. 그래야 개발팀이 사용자와 고객에게 더 많은 가치를 제공할 수 있는 인사이트를 얻을 수 있다. 이런 과정은 비즈니스에 긍정적인 영향을 미친다”라고 밝혔다. 팃콤은 마찬가지로 소프트웨어 개발자의 효율성을 평가하는 것이 가치가 있다고 생각한다. 팃콤은 “모든 비즈니스 부서는 생산성 향상을 모색하고 적은 자원으로 더 많은 일을 할 수 있는 방법을 찾아야 한다”라며 “고객 경험을 높이려고 할 때 훌륭한 제품을 제공하면서 이를 빠르고 비용 효율적으로 수행하는 방법을 잘 생각해야 한다”라고 밝혔다. 하지만 소프트웨어 개발팀이 준비가 되어 있지 않다면 훌륭한 디지털 제품을 제공하는 것은 어려울 수 있다. 깁슨은 IT 부서가 우선순위가 낮은 밀린 업무 영역과 씨름하면서 신규 개발을 위한 시간 확보를 못하는 경우가 너무 많다고 지적했다. 깁슨은 “IT 부서가 우선순위가 낮은 밀려 있는 업무를 처리하고 있는 상황이라면, 이를 얼마나 빨리 프로덕션 제품에 적용할 수 있는지를 확인하는 게 중요하다”라고 말했다. 깁슨은 개발팀은 또한 복잡한 코드, 복잡한 아키텍처, 불충분한 자동화 및 테스트 때문에 원활한 워크플로를 막는 병목 현상을 자주 마주한다고 설명헀다. 소프트웨어 개발 프로세스 내의 이런 병목 현상은 생산성을 떨어뜨린다. 당연히 이러한 장애물이 왜 어떻게 발생하는지에 대한 정보를 미리 알곡 있어야 한다. 개발 과정 내 병목현상은 혁신의 속도를 늦춰 회사의 전반적인 매출과 수익에 영향을 미칠 수 있다. 깁슨은 “넷플릭스가 원활한 기술 개발로 블록버스터에 맞서 혁신을 이룬 것처럼, 이 프로세스를 간소화하는 기업은 시장 혁신을 가속화하여 매출과 수익성을 높인다”라고 밝혔다. 하지만 모든 경영진이 개발자 생산성 측정이 실행 가능한 결과를 가져올 수 있다고 확신하는 것은 아니다. 그보다는 프로세스 간소화에 중점을 두는 것이 더 중요하다고 보는 입장이 있다. 코드 테스트 플랫폼 CTO.AI의 CEO이자 설립자인 카일 캠벨(Kyle Campbell)은 “개발자 생산성에 초점을 맞추는 것은 어리석은 일이다”라며 “경험이 풍부하고 실무적인 리더는 팀의 성과가 최고의 업무 수행에 집중할 수 있는 지원 수준과 직결된다고 보고 있다”라고 밝혔다. 따라서 캠벨은 CI/CD와 같은 개발자 워크플로를 최적화할 수 있는 방법을 비판적으로 생각하고 이러한 영역에서 개발자 경험을 실증적으로 측정하여 개발 팀의 역량을 강화할 것을 권장했다. 코드 줄이 아닌 비즈니스 성과 측정깁슨에 따르면, 아이디어 생성부터 생산 단계에 이르기까지 소프트웨어 개발 수명주기(Software Development LifeCycle, SDLC) 전반에 걸쳐 원활한 흐름을 보장하려면 여러 지점을 모니터링해야 한다. 깁슨은 “기업이 이러한 단계의 효율성이나 상용 기술 배포를 개선하지 않으면 경쟁업체에 뒤처질 위험이 있다”라고 말했다. 하지만 소프트웨어 개발자의 생산성을 측정하려는 시도 자체가 너무 어려운 작업일 수 있다. 무엇이 정확한 측정 방법이냐에 대해서도 의견이 분분하다. 거기다 많은 기술 리더가 개발자별 코드 분량 등을 파악하시는 식으로 생산성을 측정하는 것을 피하고 싶어한다. 팃콤은 “개발자 한 명당 하루에 생성되는 코드 줄 수를 세는 것은 잘못된 생산성 측정 방식이다”라며 “대신 새로운 기능 제공 속도를 조사하는 것이 좋다. 고객에게 더 나은 경험을 빨리 제공했는지를 중심으로 평가하면 여러 이점을 누릴 수 있다”라고 표현했다. 잘못된 생산성 측정 방식은 오탐을 유발하거나 엔지니어가 시스템을 조작하는 상황까지 유도한다. 팃콤은 “개발자가 특정 지표로 측정되고 있다는 사실을 알게 되면 인위적으로 해당 지표를 부풀리려고 할 것”이라며 “더 나은 지표는 고객에게 제공되는 결과에 초점을 맞춘 엔터프라이즈 생산성 지표다”라고 밝혔다. 가트너의 만은 특정 개발자 생산성 프레임워크를 구현하는 데 최근 고객들이 관심을 보이고 있다고 설명했다. 대표적으로 SPACE라는 프레임워크가 있다. 깃허브가 개발한 SPACE는 DORA(DevOps Research and Assessment)와 유사하지만 만족도와 복지, 성과, 활동, 커뮤니케이션 및 협업, 효율성과 워크플로우를 기반으로 정성적인 부분의 측정을 강화한 게 특징이다. 만이 제시한 또 다른 프레임워크에는 데브엑스(DevEx)가 있다. 만에 따르면, 이러한 프레임워크의 속성은 개발자의 생산성을 측정하는 데 도움이 될 수 있다. 경우에 따라 다른 프레임워크보다 더 객관적이다. 하지만 만은 경영진이 이러한 프레임워크를 구현할 때 의도에 맞게 목적의식을 갖고 실행할 것을 권장했다. 이상적인 측정 활동은 긍정적인 비즈니스 성과를 방해하는 장애물을 밝혀내는 것이어야 하며, 특정 기여자를 높은 자리에 올려놓는 데 사용되어서는 안 된다. 만은 “측정의 목적은 메트릭을 비교하여 한 개발자가 다른 개발자보다 더 나은지 나쁜지를 판단하는 것이 아니다”라며 “대신 어떤 요인이 해당 개발자의 생산성을 높이거나 낮출 수 있는지 진단하는 것이 목적이다”라고 강조했다. 실제로 만은 SPACE 프레임워크를 사용하는 한 고객이 커뮤니케이션 장애를 발견하고 이를 성공적으로 수정하여 품질 문제와 재작업을 줄였다고 전했다. 지능형 생산성 모니터링을 통해 이러한 종류의 사소한 문제를 발견하면 처리 시간을 단축하여 수익을 창출할 수 있다. 깁슨은 “생산성은 아이디어의 개념화 및 세부 사항 정의부터 아키텍처 계획까지 얼마나 빠르게 진행할 수 있는지에 달려 있다”라며 “생산성은 시장 진입과 혁신의 속도로 직결되며, 궁극적으로 수익에 영향을 미친다”라고 밝혔다. 팀워크를 통한 생산성 향상소프트웨어 개발 생산성 향상은 지표만으로 장려할 수 있는 것이 아니다. 전반적인 생산성에 기여하는 또 다른 중요한 요소는 개발자가 팀에 대해 갖는 주인의식과 헌신이다. 깁슨은 “팀의 연대감은 생산성의 초석이다”라며 “생산성이 높은 팀을 구성하려면 사람들이 서로 연결되어 있다고 느끼고 함께 일하는 팀에 대한 소속감과 응집력을 가져야 한다”라고 말했다. ‘생산성’에 대한 일반적인 산업적 정의는 유동적인 소프트웨어 설계 및 개발 프로세스에 잘 적용되지 않기 때문에 생산성을 더 잘 이해하려면 개념을 완전히 재구성해야 할 수도 있다. 만은 소프트웨어는 제조 공정이 각 장치마다 동일하게 유지되는 기계식 위젯을 생산하는 것과는 다르다고 말했다. 소프트웨어는 미묘한 차이가 있고 끊임없이 변화하며, 구성 요소마다 최종 가치가 다르기 때문에 기존의 생산성 측정 기법을 복잡하게 만들기 때문이다. 만은 “모든 소프트웨어는 고유하고 고유한 가치를 지니고 있다”라며 “이번 주 소프트웨어의 가치가 절반일 수도 있기 때문에 ‘지난주보다 두 배의 소프트웨어를 생산했으니 생산성이 두 배로 높아졌다’고 말하는 것은 의미가 없다”라고 말했다. 따라서 생산성 측정은 실질적인 이점이 없는 환상에 불과할 수 있다. 만은 “우리가 해야 할 일은 생산성을 단위 시간 또는 비용당 제공하는 가치의 양으로 이해하는 것이다”라고 말했다. 또 다른 의미는 소프트웨어는 고립된 상태로 만들어지는 것이 아니라 각 스프린트마다 많은 이해관계자가 참여하는 협업 프로세스라는 사실을 깨달아야 한다는 것이다. 만은 “대부분의 소프트웨어는 개별 개발자가 아닌 개발자 팀에 의해 만들어진다”라고 말했다. 따라서 리더는 생산성 향상의 효과를 제대로 측정하기 위해 장기간에 걸쳐 팀의 생산성(만은 생산성을 ‘단위 시간당 가치’라고 설명했다)을 평가해야 한다. 만은 “여러 팀에서 일관되게 가치를 평가할 수 있다면 팀별 생산성을 비교할 수도 있다”라며 “하지만 이는 ‘가정’에 불과하며, 가치는 해당 비즈니스 영역에 따라 크게 달라지고 이해관계자에 따라 크게 달라지기 때문이다”라고 밝혔다. 물론 가치를 측정하기가 항상 쉬운 것은 아니다. 특히 팀 역학 관계를 비교할 때는 유연한 접근 방식이 필요하다. 따라서 어떤 보편적인 지표에 의존하는 대신 해당 팀과 관련된 추세를 밝히는 것이 더 유리할 수 있다. 만은 “추세를 비교하고 이해한 다음 이를 바탕으로 더 심도 있는 질문을 하는 것이 더 의미 있는 일이다”라며 “예를 들어, 한 팀의 생산성이 상승 추세를 보이는데 비슷한 팀의 생산성은 그렇지 않다면 첫 번째 팀이 무엇을 다르게 하고 있는지 물어볼 수 있다”라고 밝혔다. 또한 이러한 질문을 통해 회사 전체에서 공유할 수 있는 지식이 노출되어 다른 팀의 개선에 도움이 될 수 있다. 개발자 경험의 맥락에서 집중해야 할 핵심 영역은 다를 수 있다. 캠벨은 “개발 결과물에 대해 일화적으로 이야기할 때는 팀의 피드백을 통해 개발자 경험의 주요 구성 요소를 평가하는 것이 중요하다”라고 설명했다. 캠벨은 이러한 구성 요소를 명확성(어떻게 배포할 것인가), 사용 편의성(배포를 위한 최소한의 단계는 무엇인가), 기능성(확장할 수 있는 기존 워크플로, API 또는 SDK가 있는가), 안정성(지금 배포해도 한밤중에 깨지지 않는다고 확신할 수 있는가)으로 구분할 수 있다고 표현했다. 캠벨은 “이러한 영역에서 엔지니어의 피드백을 들으면서 경영진은 최고의 업무를 수행하기 위해 어떤 영역에서 지원이 필요한지 빠르게 공감할 수 있다”라고 “이를 통해 IT 부서는 생산성을 높이고 비즈니스에 긍정적인 영향을 미치는 개선 사항에 가장 효과적으로 투자할 수 있다”라고 밝혔다. 개발자와 고객 경험기술 리더는 개발자 생산성 측정에 신중을 기해야 하며, 측정을 시도할 경우 최종 소비자에게 실질적인 가치를 제공할 수 있는 결과를 도출해야 한다. 팃콤은 “경영진은 생산성 측정이 고객 경험과 결과에 초점을 맞추고 팀이 민첩성을 유지하면서 새로운 기회가 발생할 때 이를 지원할 수 있도록 해야 한다”라며 “우리는 기술이 현재와 미래에 환자를 돌보는 데 도움이 될 수 있는 방법에 우선순위를 두어야 한다”라고 밝혔다. 또한 리더는 정신적 에너지에는 한계가 있으며 직원이 번아웃을 느낄 수 있다는 점을 기억해야 한다. 따라서 깁슨은 성과를 측정할 때 두려움을 심어주지 않기 위해 개인보다는 프로세스에 초점을 맞추는 것이 중요하다고 말한다. 깁슨은 “전체 프로세스의 효율성을 강조하고 측정 프로세스 자체의 효율성을 평가함으로써 개인이 그 틀 안에서 얼마나 잘 운영되고 있는지에 초점을 맞출 수 있다”라고 밝혔다. 마지막으로 캠벨은 지속적인 개선 문화를 조성하고 개발자 워크플로를 더 잘 계측할 수 있는 전략을 발견한 다음, 이 툴체인을 측정하여 실행 가능한 개발 인사이트를 얻을 것을 권장했다. 캠벨은 “소프트웨어가 목표를 달성하려는 최종 사용자에게 미치는 영향을 측정하는 것처럼 내부 도구가 목표를 달성하는 데 미치는 영향도 측정할 수 있다”라고 밝혔다.dl-ciokorea@foundryco.com ???? ???? ??? ??? IT ??? ???? ??? ????! ??? ??? ??? ?????. ????