AI가 정말 코딩 속도를 높여줄까요?

지난 몇 년 동안 AI의 프론티어 모델은 코딩 어시스턴트를 사용하면 코드가 더 빨라지고 버그가 줄어들며 개발자의 고된 작업이 줄어든다는 대담한 약속을 해왔습니다. Claude 또는 GPT와 같은 대규모 언어 모델(LLM)로 구동되는 GitHub Copilot 및 Cursor와 같은 도구는 프로그래밍의 지루한 부분을 자동화하여 인간 프로그래머가 코드베이스에서 더 어렵고 창의적인 문제에 집중할 수 있도록 설계되었습니다.

적어도 지금까지는 그랬습니다. 그러나 프론티어 모델의 기능을 평가하는 버클리의 비영리 단체인 METR(모델 평가 및 위협 연구의 줄임말로 '미터'로 발음)은 이러한 주장을 뒷받침할 실제 증거가 있는지 알아보고자 했습니다. 그들이 발견한 결과는 상황을 뒤집었습니다. 코딩 어시스턴트가 오히려 개발자의 속도를 늦출 수 있다는 것입니다.

METR 연구원들은 수년간 대규모 오픈소스 리포지토리에 기여해 온 16명의 숙련된 개발자들의 작업을 관찰했습니다. 각 개발자는 버그 수정부터 새로운 기능까지, 일반적으로 처리하는 실제 작업 목록을 제공했습니다. 그런 다음 연구진은 개발자가 AI 도구를 사용할 수 있는 그룹과 사용할 수 없는 그룹으로 무작위로 작업을 나눴습니다.

AI가 허용되었을 때 개발자는 원하는 도구를 선택할 수 있었는데, 대부분은 Claude 3.5 또는 3.7 Sonnet과 결합된 Cursor Pro를 선택했습니다. 그들은 각 작업을 완료할 때마다 화면을 기록한 다음, 전체 구현 시간이 얼마나 되었을지 보고했습니다. 연구 결과는 놀라웠습니다. "개발자가 AI 도구를 사용할 수 있게 되면 문제를 완료하는 데 19% 더 오래 걸리며, 이는 개발자의 믿음과 전문가의 예측에 어긋나는 상당한 속도 저하입니다."라고 이 논문의 저자들은 썼습니다.

저희는 IBM의 수석 AI 옹호자 PJ Hagerty와 수석 엔지니어 Chris Hay에게 METR의 연구를 살펴보고 공유해 달라고 요청했습니다.

Hagerty는 AI 어시스턴트에 대한 과대 광고가 실제 유틸리티를 앞질러 갈 수 있다고 경고했습니다. "AI가 사람들의 생산성을 높여줄 것이라는 약속은 AI의 과대광고를 활용하려는 기술 리더십과 생성형 AI 기업에서 비롯된 것입니다."라고 그는 IBM Think에 말했습니다. "실제로 AI는 주니어 개발자가 사용하는 것과 동일한 리소스(스택 오버플로, Github, 일반 검색 등)를 사용하지만 맥락은 전혀 고려하지 않은 채 학습하고 있습니다."

Hay는 "적절한 결과라고 생각합니다."라고 덧붙였습니다. "하지만 '와, AI는 쓸모없어, 내가 하는게 더 빨라.'라고 생각해서는 안 된다고 생각합니다. 하지만 특정 작업의 경우 AI를 설득하는 것보다 직접 하는 것이 더 빠를 수도 있다고 생각합니다."

연구 결과의 나머지 절반도 마찬가지로 흥미롭습니다. 개발자들은 시작하기 전에 AI가 작업 속도를 24% 높일 것으로 예상했습니다. 그러나 19%의 속도 저하를 경험한 후에도 AI가 20%나 속도를 높였다고 믿었습니다.

그렇다면 이러한 인식 격차의 원인은 무엇일까요? 이 연구의 저자 중 한 명인 METR의 Nate Rush를 만나 이야기를 들어보았습니다. Rush는 IBM Think에 "이는 훌륭한 질문이지만 우리의 연구에서는 완전히 이야기하지 못하는 질문입니다."라고 말합니다. "이상적으로는 향후 연구를 통해 개발자의 AI 유용성에 대한 기대가 도구 사용 방식에 어떤 영향을 미치는지, 그리고 이러한 인식 격차가 존재하는 이유를 더 탐구할 것입니다."

이 연구는 인식 문제 외에도 여러 가지 중요한 질문을 제기합니다. 과연 시간 절약만이 개발자의 생산성을 측정하는 유일한 방법일까요? 코드 품질 및 팀 영향력과 같은 지표가 전체 그림에 어떻게 들어맞을까요?

"저희 연구는 생산성의 한 측면인 시간 절약에 대해서만 이야기하고 있습니다."라고 Rush는 말합니다. "'하나의 올바른 지표'는 없지만, AI 도구의 영향력에 대한 정보를 제공하는 지표의 모음일 가능성이 높습니다." 그는 이번 연구는 시간에 초점을 맞췄지만, 그의 팀은 개발자 생산성의 SPACE 프레임워크(SPACE는 만족, 성능, 활동, 커뮤니케이션, 효율성의 줄임말)가 향후 방향을 생각하는 데 유용하다는 것을 알게 되었다고 덧붙였습니다.

또 다른 질문입니다. 모델 버전(이 경우 Claude 3.5 및 3.7 Sonnet)이 성능 시간에 영향을 미칠 수 있을까요? "이것이 현실입니다."라고 Hay는 말했습니다. "버전이 중요하다고 생각합니다. Claude 4 Sonnet이 훨씬 낫습니다. Claude 4 Opus가 훨씬 더 좋습니다. 조금 더 나아졌다고 말하는 것이 아닙니다. 우리는 훨씬 더 나은 방법에 대해 이야기하고 있습니다."

이 연구에 참여한 16명 중 한 명인 Quentin Anthony에 따르면 인적 요소도 또 다른 중요한 고려 사항입니다. "우리는 LLM을 도구라고 말하고 싶지만, 마법의 총알처럼 취급합니다."라고 그는 X에 썼습니다. "LLM은 문제를 한 번에 해결할 수 있는 큰 도파민 지름길 버튼입니다. 1% 확률로 모든 것을 고칠 수 있는 버튼을 계속 누르시나요? 적어도 저에게는 힘든 대안보다 훨씬 더 즐겁습니다."(Anthony는 소셜 미디어로 인한 주의 산만함이 지연을 유발하는 또 다른 쉬운 방법이라고 덧붙였습니다.)

그렇다면 AI 코딩 어시스턴트가 진화하고 개선됨에 따라 소프트웨어 개발에 장기적으로 가장 지속 가능한 영향을 미칠 수 있는 분야는 어디일까요? "안정적이고 신뢰할 수 있으며 유용해지면 테스트, 품질 보증, 접근성 등 QA 계층에 코드 어시스턴트가 가장 적합할 것 같습니다."라고 Hagerty는 말합니다. "제약이 있고 규칙에 기반한 것이 이러한 도구를 가장 잘 활용할 수 있습니다."

그 이유는 코드를 작성하는 것과 검사하는 것이 근본적으로 다르기 때문이라고 했습니다. "코딩은 그 자체로 창의적인 활동입니다. 독특한 에코시스템에서 무에서 유를 창조하고 있습니다. AI 어시스턴트는 이러한 뉘앙스를 놓치고 있습니다. 하지만 더 일반적이고 보편적인 규칙 시스템을 사용하여 테스트할 수 있습니다."