2025년 4~6월에 수집된 데이터에 따르면, 85%의 개발자가 1개 이상의 AI 도구를 코딩 및 개발 활동에 사용합니다. 이러한 AI의 성장은 기술 리더와 개발자의 기대치를 바꾸고 있습니다.

생성형 AI 도구의 채택은 이미 중요한 변화로 간주되고 있습니다. 기술 관리자는 조직이 개발자 경험 및 생산성을 높이기 위해 우선적으로 취해야 할 3가지 조치 중 하나로 내부 교육 및 개발 프로세스 개선과 함께 이를 꼽았습니다.

개발자들은 AI가 업무에 가져올 변화에 대해 명확히 원하는 바가 있습니다. 향후 1~3년 동안 워크플로가 어떻게 변화할 것이라 생각하는지 물었을 때, 개발자들은 자신들의 업무가 전면 자동화되는 것이 아니라 업무 시간 투자가 재조정될 것이라고 답했습니다.

많은 개발자가 AI가 학습 속도를 높이고(47%), 반복 작업이나 상용구 작업을 맡고(44%), 코드의 초기 초안을 생성(42%)해 줄 것으로 기대합니다. 또한, AI가 문제 해결 및 고급 설계와 같은 의미 있는 작업에 더 많은 시간을 쏟게 해 줄 것이라고 생각합니다(39%).

개발자들은 이미 AI를 어디에 활용할지 알고 있습니다.

AI 시대에 개발자 경험과 생산성을 향상하고 싶다면 주목할 만한 신호입니다.

2025년에도 개발자 및 기술 관리자 모두에게 유사한 질문을 하였으며, 이번에는 기술적 및 비기술적 요인이 개발자 생산성에 미치는 영향의 정도를 질문했습니다. 두 그룹 모두 비기술적 요인이 개발자 생산성에 약간 더 영향을 미친다고 평가했습니다(관리자: 89% 대 85%, 개발자: 89% 대 84%).

개발자 생산성과 경험을 측정하는 데 가장 인정받는 두 가지 프레임워크는 DORA와 SPACE입니다. 이 프레임워크는 개발자 생산성과 경험에 대한 구조화된 접근 방식을 제공합니다.

2024년 설문조사에서는 개발자 경험과 생산성을 개선하는 일에 관여하는 기술 관리자에게 이 프레임워크의 특정 요소(즉, 메트릭)를 개발자 경험과 생산성 평가에 사용하는지 물었습니다.

생산성 측정과 관련하여 개발자는 자신의 회사에서 다양한 방법을 사용한다고 보고합니다.

2025년의 상위 항목은 다음과 같습니다.

그 뒤를 이어 개발자 중 23%는 활동 로그(코드 커밋 및 풀 리퀘스트 추적 등)가 회사에서 많이 사용된다고 말했습니다.

개발 도구에 대한 만족도 측정은 완벽함과 거리가 먼 것으로 나타납니다. 거의 절반(49%)의 개발자들이 만족도 측정에 문제가 있다고 말했습니다. 33%는 만족도가 전혀 측정되지 않는다고 말하며, 16%는 측정되고 있는지 모른다고 말했습니다.

개발자 경험을 측정하는 상위 세 가지 방법은(측정되는 경우) 다음과 같습니다.

대부분의 개발자는 일반적으로 이러한 평가 수행을 수용하고 있습니다. 2024년에 개발자들에게 자신의 생산성이 측정되는 것에 대해 어떻게 느끼는지 물었을 때, 42%가 편안함을 느낀다고 말했고, 40%는 중립적인 태도를 보였습니다. 그러나 18%는 이 아이디어가 불편하다고 밝혔습니다.

개발자들은 개발 도구에 대한 자신의 만족도가 평가되는 것에 대해 훨씬 더 편안하게 생각합니다. 응답자의 절반 이상(57%)은 자신의 만족도가 측정되는 것에 대해 편안함을 느낀다고 말했고, 39%는 중립적인 태도를 보였습니다.

데이터에서 분명히 알 수 있는 한 가지는 대부분의 개발자가 자신의 생산성과 경험이 평가되는 것에 대해 편안하게 생각합니다.

이러한 종류의 평가는 기술 산업에서 표준 관행이 되고 있는 것으로 보입니다. 개발자에게 불편함을 주거나 부정적 감정을 유발할 수 있다는 두려움 때문에 기업이 개발자 생산성과 경험을 측정하는 일을 멈춰서는 안 될 것입니다.

약 2/3의 개발자는 생산성을 측정하는 데 사용되는 메트릭이 자신의 생산성과 기여도를 정확하게 반영한다고 생각하지 않거나(36%) 확신하지 않는다고(30%) 보고했습니다.

이러한 불신은 이 데이터가 의사결정 과정에서 사용되는 방식에도 확장됩니다. 2024년 설문조사에서는 개발자들에게 자신의 생산성 평가를 기반으로 이루어지는 의사결정에 대해 인지하고 있는지 물었습니다.

개발자 중 22%만이 자신의 생산성 데이터가 어떻게 사용되고 있는지에 대해 완전히 알고 있으며, 정기적으로 그리고 명확하게 정보를 제공받는다고 말했습니다.

추가로 32%는 대충 알고 있다고 답했으며, 이는 대개의 내용은 알고 있으나 완전히 파악하고 있지는 않다는 뜻입니다. 나머지 46%는 해당 데이터가 어떻게 사용되고 있는지 잘 모르거나 전혀 알지 못하여 낮은 인지도를 보여줍니다.

개발자들에게 생산성 측정 방식에 대해 더 편안하게 느끼려면 무엇이 필요한지 물었을 때, 이들이 원하는 바는 다음과 같았습니다.

그밖에는 프로세스의 공정성, 결과가 의사결정에서 사용되는 방식, 측정 담당자에 대해 우려가 있었습니다. 개발자는 이러한 프로세스가 사려 깊고, 목적에 충실하며, 자신들에게 도움이 되기를 바랍니다.

개발자 경험을 측정하는 데 사용되는 메트릭과 방법에 대한 논의를 기반으로, 조직이 개발자의 도구 만족도를 실제로 측정하고 있는지에 대한 질문으로 돌아가 보았습니다. 이 메트릭은 개발자 경험에서 중요한 요소지만, 전체 개발자 중 약 절반이 이 메트릭이 회사에서 사용되지 않거나 모른다고 보고합니다. 구체적으로, 33%가 도구 만족도가 전혀 측정되지 않는다고 말하며, 16%는 확신하지 못합니다. 이처럼 정보가 없으면 팀은 문제를 파악하거나 체계적인 조치를 취하기 어렵습니다.

앞서 언급한 바와 같이, 개발자 만족도를 정량화하는 것은 일반적으로 긍정적인 반응을 얻으며, 드물게 불편함을 초래하는 것 같습니다.

회사 규모는 측정 관행의 채택에 영향을 미치는 것으로 보이며, 대기업은 중소기업보다 개발자 경험과 생산성을 측정할 가능성이 더 높습니다.

1,000명 이상의 직원이 있는 대기업에서는 조사 대상 기술 관리자 중 30%만이 회사가 개발자 경험 또는 생산성을 측정하지 않는다고 말했습니다. 중간 규모 기업(직원 수 50~1,000명)의 경우 이 수치는 34%로 증가하고, 50명 미만의 소규모 기업에서는 41%로 증가합니다.

2024년, 개발자를 대상으로 수행된 생산성 평가의 빈도는 기업마다 크게 차이를 보입니다. 가장 많이 시행되는 주기는 분기별(25%), 월별(18%), 주별(17%)입니다.

개발자 경험의 핵심 요소인 도구 만족도는 조금 상황이 다르며 변화하고 있습니다. 2024년에는 절반이 넘는 개발자(53%)가 개발 도구에 대한 만족도가 불규칙적으로 측정된다고 말했습니다. 하지만 2025년에는 이 수치가 29%로 크게 하락했고, 더 많은 팀이 체계적인 측정 관행(월별, 분기별, 연간)을 채택하고 있으며 분기별(28%), 월별(18%), 주별(9%) 평가가 늘어났습니다.

실제로 개발자 경험과 생산성을 추적하는 담당자는 누구일까요? 데이터에서는 답이 분명합니다. 규모와 관계없이 대부분의 회사에서 팀 리드가 이 업무를 담당하고 있거나 담당할 것으로 기대됩니다(차트에서 다른 직책 참조).

2025년 데이터에 따르면, 조사된 개별 기여자(IC)의 56%와 다양한 직책의 기술 관리자(생산성 엔지니어, 개발자 경험 전문가, 팀 리드 등 포함) 중 절반은 팀 리드가 개발자 경험과 생산성 측정을 기본적으로 담당한다는 데 동의합니다. 흥미롭게도, 이는 모든 규모의 회사에서 사실입니다. 이러한 선택은 논리적으로 보입니다. 팀 리드는 개발자와 긴밀하게 작업하며 팀의 워크플로, 도전 과제 및 문제점을 잘 알고 있습니다.

대기업에 다니는 개발자와 기술 관리자 중에서, 플랫폼 엔지니어링 팀이 개발자 경험 측정을 담당한다고 밝힌 응답자는 각각 22%와 23%였고, 전담 전문가가 있다고 밝힌 응답자는 각각 25%와 22%였습니다.

개발자 중 30%는 생산성과 경험을 측정하는 일은 개인 각자가 알아서 해야 한다고 느낍니다. 이 수치는 소규모 기업에서는 38%로 증가하여, 이는 조직 규모가 작을수록 개발자 스스로가 해결하도록 방치하는 경향이 있음을 시사합니다.