Metr은 최근 AI 도구가 오픈 소스 개발자의 생산성 (Productivity)에 미치는 영향에 관한 논문을 발표했습니다1. 연구 결과에 따르면, 자신이 매우 익숙한 코드베이스 (Codebase)에서 작업하는 오픈 소스 개발자들이 작업을 완료하기 위해 AI 도구를 사용할 경우, AI 도구 사용이 금지된 다른 작업들과 비교했을 때 해당 작업을 완료하는 데 더 오랜 시간이 걸리는 것으로 나타났습니다. 흥미롭게도 개발자들은 AI가 자신들을 더 빠르게 만들어 줄 것이라고 예측했으며, 원래보다 작업 완료 시간이 더 오래 걸린 후에도 AI가 자신들을 더 빠르게 만들었다고 계속 믿었습니다!

개발자들이 AI 도구를 사용할 수 있게 되면, 이슈 (Issue)를 완료하는 데 19% 더 많은 시간이 소요됩니다. 이는 개발자들의 믿음 및 전문가들의 예측과 상반되는 상당한 속도 저하입니다. 인지와 현실 사이의 이러한 격차는 매우 놀랍습니다. 개발자들은 AI가 자신들의 속도를 24% 높여줄 것으로 기대했으며, 속도 저하를 경험한 후에도 AI가 자신들의 속도를 20% 높여주었다고 여전히 믿었습니다. 2025년 초 AI가 숙련된 오픈 소스 개발자의 생산성에 미치는 영향 측정

이 결과를 모든 소프트웨어 개발자에게 일반화할 수는 없습니다. 이 연구의 개발자들은 매우 특정한 유형의 개발자이며, 매우 특정한 프로젝트에서 작업하고 있습니다. 이들은 자신의 프로젝트에서 작업하는 숙련된 오픈 소스 개발자들입니다. 이 연구는 현재의 AI 도구 세트가 이러한 개발자들의 속도를 늦추는 것처럼 보인다는 점을 알려주지만, 이것이 다른 개발자들에게도 동일하게 적용된다고 가정할 수 있다는 의미는 아닙니다. 예를 들어, 이미 회사를 떠난 사람들이 대부분 구축한 next.js 앱을 작업하는 기업의 드론 (Corporate drones)들에게는 엄청난 생산성 향상이 나타날 것으로 기대할 수도 있습니다! (저 포함)

우리가 할 수 있는 또 다른 한 가지는, 왜 이 특정한 오픈 소스 개발자들이 속도를 높여주겠다고 약속하는 도구들에 의해 오히려 속도가 늦춰졌는지에 대해 이론을 세워보는 것입니다.

저는 인지된 성능과 실제 성능 사이의 격차보다는, 왜 그들이 속도가 늦춰졌는지에 특히 집중하고자 합니다. 도구가 자신을 빠르게 만들었는지 아니면 느리게 만들었는지 개발자가 판단할 수 없다는 사실 그 자체는 매우 흥미로우며, 아마도 다른 많은 형태의 인간 활동에도 적용될 것입니다. 이는 왜 그렇게 많은 사람이 AI가 자신을 10배 더 생산적으로 만들었다고 생각하는지, 왜 제가 계속해서 Vim을 사용하는지, 왜 사람들이 런던에서 운전을 하는지 등과 같이 다양한 현상들을 설명해 줍니다. 저는 이 격차가 왜 발생하는지에 대해서는 그 이상의 특별한 생각을 가지고 있지 않습니다. 다만, 왜 그들의 속도가 늦춰졌는지에 대해서는 의견이 있습니다.

two

얼마 전 저는 Peter Naur의 '이론 구축으로서의 프로그래밍 (programming as theory building)'이라는 오래된 논문에 대해 다소 우회적으로 글을 쓴 적이 있습니다. 그 논문은 다음과 같이 기술합니다.

"적절한 프로그래밍은 프로그래머가 당면한 문제에 대해 특정한 종류의 통찰, 즉 이론을 형성하거나 달성하는 활동으로 간주되어야 한다."

즉, 우리가 소프트웨어를 작성할 때 만들어내는 진정한 결과물은 우리가 생성한 프로그램에 대한 우리의 정신 모델 (mental model)이라는 뜻입니다. 이 모델은 우리가 소프트웨어를 구축할 수 있게 해준 것이며, 향후에는 시스템을 이해하고, 내부의 문제를 진단하며, 효과적으로 작업할 수 있게 해주는 토대가 됩니다. 만약 여러분이 저와 마찬가지로 이 이론에 동의한다면, 이는 왜 모든 사람이 레거시 코드 (legacy code)를 싫어하는지, 왜 소규모 팀이 대규모 팀보다 더 나은 성과를 낼 수 있는지, 왜 아웃소싱은 일반적으로 잘 풀리지 않는지 등을 설명해 줍니다.

우리는 Metr의 연구에 참여한 프로그래머들이 모두 자신이 작업하는 프로젝트에 대해 매우 잘 발달된 정신 모델 (mental model)을 가진 사람들이라는 점을 알고 있습니다. 또한 그들이 사용한 LLM (대규모 언어 모델)은 이러한 정신 모델에 실제로 접근할 수 없었다는 점도 알고 있습니다. 개발자들은 그 정신 모델의 일부를 AI 도구에 제공할 수는 있었지만, 그렇게 하는 과정은 느리고 정보 손실이 발생하는 (lossy) 과정이며, 그들의 머릿속에 존재하는 프로그램의 이론을 결코 진정으로 포착할 수 없습니다. 소프트웨어 개발 작업을 LLM에 떠넘김으로써, 그들은 코드베이스 (codebase)를 효과적으로 다룰 수 있는 그들만의 고유한 능력을 저해했습니다.

다른 누군가에게 간단한 업무를 위임하려 했던 때를 떠올려 보십시오. 예를 들어 아기를 재우는 일 말입니다. 당신은 모호하지 않다고 생각하는 지침들을 적어 내려갈 수 있습니다. "아기에게 우유를 주고, 침대에 눕히세요. 만약 아기가 울더라도 절대로 반응하지 마세요"라고 말이죠. 하지만 열 번 중 아홉 번은, 당신이 집에 돌아왔을 때 그 지침을 따랐던 사람이 당신이 의도했던 것과 정반대로 행동하고 있다는 사실을 발견하게 될 것입니다. 어쩌면 그들은 울고 있는 아기를 침대에서 데리고 나와 개구리를 구경하러 산책을 나갔을지도 모릅니다.

우리가 세상을 이해하는 방식인 멘탈 모델 (mental models)은 믿을 수 없을 정도로 풍부하며, 그중 가장 단순한 모델조차 타인에게 전달하려면 엄청난 노력이 필요할 정도입니다. 게다가 그 전달은 결코 완전히 성공할 수 없으며, 공유된 이해 (shared understanding)의 부족으로 인해 문제가 발생하기 전까지는 그 전달이 얼마나 성공적이었는지 판단하기가 매우 어렵습니다. 이러한 문제들은 우리가 불일치를 인지하게 하고, 향후 더 나은 수행을 위해 서로의 멘탈 모델을 상호 적응시킬 수 있게 해줍니다. 하지만 텍스트를 통해서만 멘탈 모델을 전달해야 하고, 그 대상이 결코 이의를 제기하거나 명확한 질문을 던지지 않으며, 진정으로 학습할 수 없고, 하나의 문장을 다른 문장보다 더 중요하게 취급할 수도 없는 존재라면—글쎄요, 그 작업은 본질적으로 불가능해집니다.

이것이 바로 현재 존재하는 AI 코딩 도구들이, 만약 사용자가 자신이 무엇을 하고 있는지 알고 있으며 자신이 이해하고 있는 프로젝트에서 작업하고 있다면, 일반적으로 그들의 속도를 늦추게 되는 이유입니다.

음, 어쩌면 아닐지도 모릅니다. 앞선 문단에서 저는 AI 도구가 "자신이 무엇을 하고 있는지 알고, 자신이 이해하고 있는 프로젝트에서 작업하는" 사람의 속도를 늦출 것이라고 썼습니다. 이것이 업계의 평균적인 소프트웨어 개발자를 설명할까요? 저는 의구심이 듭니다. 그렇다면 당신의 직장에 있는 소프트웨어 개발자들은 어떠합니까?

엔지니어들이 자신이 정확한 멘탈 모델 (Mental Model)을 가지고 있지 않은 프로젝트를 맡게 되는 일은 흔합니다. 더 나은 미래를 찾아 회사를 떠난 지 오래된 사람들이 만든 프로젝트 말입니다. 개발자들이 시스템을 이해하는 것에는 거의 가치를 두지 않으면서, 대부분은 제대로 작동하는 변경 사항을 빠르게 전달하는 것에는 큰 가치를 두는 환경에서 일하는 것 또한 매우 흔한 일입니다. 이러한 맥락에서, 저는 AI 도구들이 더 많은 이점을 가진다고 생각합니다. AI는 어떤 인간보다도 낯선 코드베이스 (Codebase)를 더 빠르게 흡수할 수 있으며, 본질적으로 작동할 변경 사항을 생성해낼 수 있는 경우가 많기 때문입니다.

따라서 우리가 생산성에 대해 이처럼 좁고 단기적인 관점을 취하여, 생산성이란 단순히 비즈니스 가치를 창출하는 시간이라고 정의한다면 — 그렇다면 네, 저는 LLM (Large Language Model)이 개발자의 생산성을 높일 수 있다고 생각합니다. 데이터를 가지고 있지 않기에 이를 증명할 수는 없지만, 누군가 이 연구를 수행해 준다면 정말 좋을 것 같습니다. 만약 선뜻 나서는 사람이 없다면 제가 직접 실험해 볼 수도 있습니다.

하지만 이러한 맥락에서 AI 도구를 사용하는 데에는 문제가 있습니다.

좋습니다, 만약 당신이 프로그램에 대한 멘탈 모델 (Mental Model)을 가지고 있지 않다면, 아마도 LLM이 당신의 생산성을 향상시킬 수 있을 것입니다. 하지만 우리는 앞서 소프트웨어를 작성하는 주요 목적이 멘탈 모델을 구축하는 것이라는 점에 동의했습니다. 만약 우리의 업무를 LLM에 외주 준다면, 우리는 여전히 효과적으로 멘탈 모델을 구축할 수 있을까요? 저는 회의적입니다2.

그렇다면 이러한 도구들의 사용을 피해야 할까요? 그럴 수도 있습니다. 만약 당신이 프로젝트를 장기적으로 수행할 것으로 예상하고, 프로젝트를 진정으로 이해하고 싶으며, 효과적으로 변경 사항을 만들 수 있는 역량을 갖추기를 원한다면, 그냥 직접 코드를 작성해야 한다고 생각합니다3. 반면에 당신이 그저 '슬롭 공장 (Slop factory)'에서 '슬롭 (Slop)'을 마구 찍어내고 있는 중이라면, Cursor4를 설치하고 그냥 밀어붙이세요 — YOLO.

1
정말 멋진 연구이며, 적어도 요약본만큼은 꼭 읽어보시기를 강력히 권장합니다.

2
Claude Code 등을 흔히 제안되는 용도 중 하나는, 해당 프로젝트에 대해 질문함으로써 새로운 프로젝트에 빠르게 온보딩 (onboarding) 할 수 있다는 것입니다. 이것이 우리가 멘탈 모델 (mental model)을 구축하는 데 도움이 될까요? 아마도 그럴 수도 있습니다! 하지만 일반적인 개발자보다 10배 빠르게 코드를 생성하는 것이, 생성되고 있는 시스템에 대한 강력한 멘탈 모델로 이어질까요? 거의 확실히 그렇지 않습니다.

3
이것이 프로젝트에 대한 멘탈 모델을 가진 개발자의 속도를 의미 있게 높여주거나, 혹은 그러한 멘탈 모델을 구축하도록 돕는 AI 도구가 존재할 수 없다는 뜻은 아닙니다. 하지만 현재 존재하는 도구 세트들은 그 방향으로 나아가고 있는 것처럼 보이지 않습니다. 만약 모델들이 개선된다면, 인간이 소프트웨어 산출물 (software artifact)에 대한 멘탈 모델을 가질 필요가 전혀 없는 지점에 도달할 수도 있을 것입니다. 하지만 우리는 분명 아직 그 단계에 도달하지 못했습니다.

4
Cursor를 설치하지 마세요, 형편없습니다. 성인답게 Claude Code를 사용하세요.