연구로 짚어본 GenAI와 소프트웨어 엔지니어링의 8가지 오해 - 개발자는 하루의 14%만 코딩한다

출처: ACM Queue (Jenna Butler, Brian Houck, Margaret-Anne Storey, Travis Lowdermilk, Steven Clarke, Emerson Murphy-Hill)
원문: https://queue.acm.org/detail.cfm?id=3807963

작성자: 팔복소프트-김팔복

한눈에 보기

• Microsoft 연구에 따르면 개발자가 실제로 코드를 작성하는 시간은 업무 시간의 약 14%에 불과합니다. 코드 생성 AI가 아무리 뛰어나도 전체 업무에서 건드리는 영역은 생각보다 작습니다.
• AI가 생성한 코드 라인 수(LoC)는 통계적으로도, 실질적으로도 유효한 생산성 지표가 아닙니다. 오히려 지표를 "게임"하게 만들고 기술 부채를 키울 수 있습니다.
• AI 도구의 효과는 작업 유형, 개발자 경험, 코드베이스 친숙도, 프롬프트 작성 능력에 따라 크게 달라집니다. 숙련된 오픈소스 개발자 대상 연구에서는 오히려 구현 시간이 평균 18% 늘어난 결과도 있었습니다.
• 라이선스만 나눠준다고 생산성이 오르지 않습니다. 역사적으로 생산성 향상은 개인이 아니라 조직 차원의 시스템 재설계에서 나왔습니다.
• 도구 성능이 좋다고 자동으로 도입되지도 않습니다. 개발자의 80%가 AI 도구를 쓰지만 정확성을 신뢰하는 비율은 29%에 그칩니다.

주요 내용

Microsoft의 연구자들이 ACM Queue에 발표한 이 글은, GenAI가 소프트웨어 엔지니어링을 바꾸고 있는 것은 맞지만 "이야기(narrative)가 증거(evidence)를 앞서가고 있다"는 문제의식에서 출발합니다. 마케팅 문구, 일화적인 성공담, 잘못 해석된 연구들이 만들어낸 8가지 오해를 대규모 연구와 인터뷰, 현장 관찰을 근거로 하나씩 검증합니다.

오해 1: 개발자는 대부분의 시간을 코딩에 쓴다

2025년 Microsoft 엔지니어 450여 명을 대상으로 한 연구에서 개발자가 코드 작성에 쓰는 시간은 전체의 14%였습니다. 이전 연구들에서도 "좋은 날" 18%, "나쁜 날" 11% 수준으로 비슷한 결과가 반복해서 나왔습니다. 나머지 시간은 설계, 회의, 스탠드업, 계획, 코드 리뷰 같은 활동에 쓰입니다. 소프트웨어는 혼자 진공 상태에서 만들어지는 것이 아니기 때문입니다.

오해 2: 코드 작성이 병목이다

위의 시간 분포를 놓고 보면, 코딩 속도를 2배로 올려도 이론상 전체 생산성 향상은 15% 미만입니다. 나머지 85%의 시간은 그대로 남습니다.

게다가 코드 생성 속도만 높이면 리뷰·테스트·통합해야 할 코드가 늘어나 압박이 다운스트림으로 이동합니다. 개발 사이클 전체 속도는 가장 느린 단계에 의해 결정되는데, 코딩은 대개 가장 느린 단계가 아닙니다. AI를 코드 생성기로만 쓰는 것은 IDE 안의 "inner loop"에만 손을 대는 것이고, 실제 배포까지의 "outer loop"는 그대로 남습니다.

오해 3: AI가 작성한 코드 라인 수가 좋은 지표다

라인 수(LoC)가 생산성 지표로 부적합하다는 것은 이미 2014년 통계 연구에서 확인된 사실입니다. 그런데 AI 시대에 들어와 "AI가 작성한 코드 라인 수"라는 변형된 형태로 다시 유행하고 있고, 일부 기업은 이 수치를 공개적으로 발표하기도 합니다.

저자들은 이런 단일 지표가 통계적으로 유효하지 않을 뿐 아니라, 팀이 지표를 게임하도록 유도하고, 코딩 물량을 우선시하는 압박 속에서 설계 품질 저하·기술 부채 증가·보안 취약점 확대로 이어질 수 있다고 경고합니다. 소프트웨어 회사의 목표는 코드를 최대한 많이 쓰는 것이 아니라 안전하고 유지보수 가능한 고품질 소프트웨어를 전달하는 것이고, AI의 영향 측정도 그 목표를 반영해야 합니다.

오해 4: AI는 모든 작업과 개발자에게 똑같이 도움이 된다

관련 연구 결과는 상당히 엇갈립니다. 큰 생산성 향상을 보고한 연구도 있고, 효과가 중립적이거나 심지어 부정적인 연구도 있습니다. 2025년의 한 연구에서는 숙련된 오픈소스 개발자들이 AI 도구를 사용했을 때 구현 시간이 오히려 평균 18% 증가했습니다.

Microsoft의 2024년 AI·생산성 보고서에 따르면 익숙하고 잘 이해된 작업일수록 Copilot의 효율 향상이 컸고, 보일러플레이트 같은 반복적인 "코드 집약적" 작업에는 효과적이지만 창의적·협업적 작업에는 그렇지 않았습니다. 프롬프트를 의미는 같게 유지하면서 표현만 바꿔도 46%의 경우 다른 코드가 나오고 28%는 정답 여부까지 달라진다는 연구도 있습니다. 결국 작업 특성, 개발자 경험, 코드베이스 친숙도, 프롬프트 작성 능력이 모두 결과를 좌우하며, GenAI를 효과적으로 만드는 보편적인 공식은 없습니다.

오해 5: AI가 개인을 10x 개발자로 만든다

"55% 생산성 향상" 같은 수치는 격리된 개별 작업 환경에서 측정된 것으로, 조율·협업·지식 공유가 필수인 실제 팀 기반 개발 환경에 그대로 이식되지 않습니다. 기존 연구 상당수가 실제 프로덕션 코드가 아닌 토이 예제를 대상으로 했다는 한계도 있습니다.

또한 개발자 간 성과 차이의 상당 부분은 개인 능력이 아니라 수행 중인 작업의 특성에서 나옵니다. 어떤 작업에서 앞선 개발자가 모든 작업에서 앞서는 것은 아니라는 뜻으로, 오해 4와 같은 결론으로 이어집니다. 성과를 결정하는 것은 개인의 재능보다 작업·맥락·적합성입니다.

오해 6: AI를 잘 쓰는 것은 각 개발자의 몫이다

현재 대부분의 연구는 "개인 엔지니어 + GenAI 도구" 구도를 보고 있고, 이는 생산성 향상의 부담을 엔지니어 개인에게 지우는 셈입니다. 하지만 역사적으로 생산성 도약은 개인이 아니라 조직 수준의 시스템 변화에서 나왔습니다. 글에서는 Cal Newport의 지적을 인용해, 포드의 조립 라인조차 수많은 시행착오와 대규모 투자 끝에 나왔는데 지금은 개별 지식 노동자에게 자기 업무를 스스로 최적화하라고, 그것도 본래 업무를 하면서 동시에 하라고 요구하고 있다고 꼬집습니다.

수백만 달러의 라이선스를 사놓고도 가치를 극대화하는 방법은 모르는 상태 — 저자들은 GenAI가 그런 첫 번째 기술일지 모른다고 말합니다. 기대했던 극적인 생산성 향상이 나타나지 않는 것은 접근 권한만으로는 부족하다는 신호이며, 조직 차원에서 개발 프로세스 자체를 다시 설계해야 한다는 것입니다.

오해 7: 성능 좋은 AI 도구는 알아서 도입된다

도입에는 사회적·조직적·인지적 장벽이 얽혀 있습니다. 특히 여성과 고연차 엔지니어는 AI를 사용했다는 이유만으로 동일한 결과물에 더 가혹한 평가를 받는 "역량 페널티(competence penalty)"에 직면한다는 연구가 있습니다. 신뢰 문제도 큽니다. 개발자의 80%가 AI 도구를 쓰지만 정확성을 신뢰하는 비율은 29%에 불과하고, 직접 짜는 것보다 AI 출력을 디버깅하는 데 더 많은 시간을 쓴다는 보고도 많습니다.

여기에 기존 워크플로와의 통합 문제, 새 도구를 배울 시간 부족, 학습 데이터 출처나 환경 영향 같은 윤리적 우려, 그리고 AI 의존이 문제 해결 능력을 퇴화시킬 수 있다는 탈숙련화(de-skilling) 불안까지 더해집니다. 결국 도입은 도구 품질만의 문제가 아니라 신뢰, 맥락, 일하는 경험의 문제입니다.

오해 8: GenAI만 있으면 대기업도 스타트업 속도로 혁신할 수 있다

스타트업은 LLM 학습 데이터에 풍부하게 포함된 오픈소스 컴포넌트와 잘 문서화된 프레임워크 위에서 개발합니다. 반면 엔터프라이즈는 AI 모델이 한 번도 본 적 없는 사내 도구와 레거시 코드베이스에 의존하고, 대규모 조직에만 적용되는 컴플라이언스·보안·규제 요건을 지켜야 합니다.

GenAI가 가장 잘하는 것은 그린필드(백지 상태) 개발인데, 엔터프라이즈 소프트웨어는 하위 호환성을 유지하면서 수천 개의 내부 시스템·서드파티 도구와 연동돼야 합니다. 고객 기대치도 다릅니다. 스타트업은 버그 있는 알파 버전을 내놔도 얼리어답터가 용인하지만, 엔터프라이즈 고객과 계약·규제는 완성된 프로덕션 품질을 요구합니다. 저자들의 표현을 빌리면, 속도는 눈에 보이지만 복잡성은 보이지 않습니다.

정리

이 글의 핵심은 "AI가 쓸모없다"가 아니라 "효과가 맥락에 따라 크게 달라진다"입니다. 코딩은 개발자 업무의 작은 부분이므로 코드 생성 가속만으로는 조직 전체의 배포 속도가 크게 바뀌지 않고, 라인 수 같은 단일 지표로 AI의 효과를 측정하면 오히려 잘못된 행동을 유도합니다. AI 도입을 검토하는 팀이라면 개인에게 라이선스를 나눠주는 데서 멈추지 말고, 어떤 작업에 어떻게 적용할지와 무엇으로 성공을 측정할지를 조직 차원에서 설계하는 것이 이 글에서 기억할 부분입니다.

• GenAI
• 개발자생산성
• GitHub Copilot
• 소프트웨어엔지니어링
• 개발문화