우리는 더 나은 개발자가 되는가, 아니면 단순히 코드를 생산하는 속도만 빨라지는가?

금요일 오후. 당신의 작업 목록에 티켓 하나가 도착합니다: 새로운 엔드포인트, 일부 유효성 검사(validation), 작은 마이그레이션. 예전에는 하루의 절반을 차지하던 종류의 작업입니다.

당신은 이 작업을 AI 어시스턴트에게 설명하고, diff를 훑어보고, 테스트를 실행한 다음, 배포합니다. 20분 만에 완료됩니다.

3개월 후, 그 엔드포인트가 아무도 예상하지 못한 부하 패턴(load pattern)에서 오류를 일으킵니다. 파일을 열어보지만, 그것이 무엇인지 완전히 알 수 없습니다. 기술적으로는 당신이 작성한 것이 맞습니다. 당신이 승인하고, 테스트하고, 병합했죠. 하지만 어떻게 작동하는지에 대한 실제 모델을 구축할 기회가 없었습니다. 왜냐하면 그 깊이 생각하도록 강제했을 부분은 이미 처리되었기 때문입니다.

이것은 질문을 던집니다: 만약 AI가 우리의 코드를 더 많이 작성한다면, 우리는 여전히 그 코드가 실제로 어떻게 작동하는지 배우고 있는 것일까요, 아니면 단지 우리가 완전히 이해하지 못하는 것을 배포하는 속도만 빨라지고 있는 걸까요?

생산성 연구들은 의견이 일치하지 않으며, 이 불일치가 유용한 부분입니다

2023년, Microsoft, GitHub, 그리고 MIT Sloan은 개발자들이 JavaScript로 표준화된 HTTP 서버를 작성하도록 무작위 대조 시험(randomized trial)을 진행했습니다. Copilot 그룹이 55.8% 더 빠르게 완료했으며, 아예 완성한 비율도 78% 대 70%로 더 높았지만, 이 완성률 격차 자체는 통계적으로 유의미하지 않았습니다. 이는 상당히 제한된 작업에 대한 속도를 측정한 것이지, 결과 코드가 시간이 지나도 유지되는지를 측정한 것은 아니었습니다.

2년 후에는 METR가 실제 엔지니어링 작업에 더 가까운 것을 테스트했습니다. 그들은 숙련된 오픈 소스 개발자 16명을 모집하여, AI 접근 권한이 있는 그룹과 없는 그룹으로 나누어 자신들의 크고 익숙한 저장소에서 246개의 작업을 완료하는 것을 지켜보았습니다. 결과는 반대 방향으로 나왔습니다: AI를 사용한 개발자들이 오히려 19% 더 오래 걸렸습니다. 시작하기 전에 그들은 AI가 속도를 높여줄 것이라고 예측했지만, 나중에 데이터가 뒷받침하지 않는 약 20%의 개선을 추정했을 뿐입니다.

언뜻 보기에는 모순적으로 보입니다. 하지만 연구들은 서로 다른 종류의 작업을 테스트했습니다. 생소한 도구를 사용하는 제한된 작업 환경에서 AI 지원이 잘 나타나는 경향이 있습니다. 수년에 걸쳐 구축되어 이미 개발자의 머릿속에 존재하는 코드베이스는 범용적인 도구가 가치를 더하기가 훨씬 어렵고, 검토 및 수정 오버헤드가 절약되는 시간을 모두 먹어치우기 쉬운 곳입니다. 이 연구들은 서로 다른 환경에서의 생산성에 대해 우리에게 다른 이야기를 해줍니다. METR의 결과가 가장 주목할 만합니다. 개발자들은 AI가 시간을 절약해 줄 것이라고 예상했지만, 측정된 결과는 정반대였습니다.

개발자들이 실제로 무엇을 배웠는지 테스트한 퀴즈

실제 질문에 대한 더 직접적인 테스트는 Anthropic이 진행한 연구에서 나왔습니다. 이 연구는 주로 주니어 레벨의 52명 개발자가 'Trio'라는 생소한 Python 라이브러리를 학습하는 과정을 다루었습니다. 한 그룹은 코딩 작업 중 AI 어시스턴트를 사용했고, 다른 그룹은 수동으로 코딩했습니다. 이후 모두가 AI를 허용하지 않은 동일한 퀴즈(디버깅, 코드 읽기, 개념적 이해 포함)를 풀었습니다. 이는 새로운 것을 배우는 사람들에 대한 소규모 연구이며, 프로덕션 시스템에서 작업하는 시니어 엔지니어들의 대표 샘플은 아니지만, 그 결과는 검토할 가치가 있습니다.

AI 지원 그룹이 퀴즈 평균 점수 50%를 기록한 반면, 수동 코딩 그룹은 67%를 기록하여 17퍼센트 포인트의 격차가 발생했습니다. 그룹 간 가장 큰 차이는 특히 디버깅 질문에서 나타났습니다. 하지만 또 다른 중요한 세부 사항이 있습니다. AI 그룹이 평균적으로 단지 약 2분 정도 더 빨리 끝냈을 뿐인데, 이 차이는 통계적으로 의미 있다고 부르기에는 너무 작았습니다. 그들은 이해도의 격차를 메우는 대가로 속도 자체에서도 큰 이득을 얻지 못했습니다.

화면 녹화를 되돌아보며, 연구진은 참가자들이 실제로 어시스턴트를 사용하는 방식에 따라 여섯 가지 관찰 패턴으로 분류했습니다. 작업을 맡기고 돌아온 결과물을 받아들이는 것을 중심으로 하는 세 가지 패턴은 퀴즈 평균 점수가 40% 미만이었습니다. 반면, 사람들이 무언가가 왜 작동하는지 질문하거나 코드와 함께 설명을 요청한 다른 세 가지 패턴은 65%에서 86% 사이의 점수를 받았습니다. 연구진은 이것이 특정 사용 패턴이 점수의 원인이라는 증거가 아니라 사후에 발견된 상관관계임을 분명히 했습니다. 그럼에도 불구하고 이 연관성은 무시하기 어렵습니다. 어시스턴트와 인지적으로 계속 관여한 사람들은 그렇지 않은 사람들보다 더 많은 것을 기억하는 경향을 보였습니다.

실제 코드베이스에서 나타나는 현상

GitClear는 2020년부터 2023년까지 변경된 약 1억 5,300만 줄의 코드를 분석하여, 코드 변화(코드 작성 후 2주 이내에 되돌리거나 다시 작성하는 줄 수)가 2021년 기준 대비 2024년에는 대략 두 배로 증가할 것으로 예측했습니다. 또한 복사-붙여넣기한 코드도 제대로 리팩토링된 코드에 비해 증가하고 있었습니다. GitClear는 AI 도구가 일반화되는 동안 변화(churn)가 증가했음을 보여주지만, 이것이 AI 때문이라고 증명하지 못하며 GitHub 역시 이 해석에 대해 공개적으로 반박했습니다. 한 가지 가능한 설명은 개발자들이 코드를 완전히 이해하기 전에 병합하고 있다는 것이지만, 데이터만으로는 이를 확립할 수 없습니다.

보안 측면에서 특히, Stanford 연구진은 AI 코딩 어시스턴트에 접근한 개발자들이 통제 그룹보다 측정 가능하게 덜 안전한 코드를 작성했으며, 자신의 코드가 안전하다고 더 자신감을 가졌다는 것을 발견했습니다. 이 도구들은 2022년부터 2023년까지의 실험 이후로 변경되었기 때문에 그 결과는 오늘날의 어시스턴트에 대한 판결로 간주되어서는 안 됩니다. 하지만 이는 고려할 가치가 있는 위험을 강조합니다. 즉, 개발자들이 완전히 평가하지 않은 코드에 대해 자신감을 가질 수 있다는 것입니다.

49,000명 이상의 응답을 기반으로 한 2025 Stack Overflow 설문조사에 따르면, 개발자의 84%가 이미 AI 도구를 사용하고 있거나 사용할 계획이라고 답했습니다. 이 수치는 현재 사용자들과 아직 시작하지 않은 사람들을 혼합한 것입니다. 응답자 전체를 대상으로 했을 때, 46%는 AI 출력의 정확성을 신뢰하지 않는다고 답했으며, 이는 전년도 31%에서 증가한 수치입니다. 또한 66%는 도구 사용 시 가장 큰 좌절감으로 '거의 맞지만 완벽하진 않은' 답변을 꼽았습니다. 이 좌절감을 질문에 답한 사람들 중 45%는 AI가 생성한 코드를 디버깅하는 것이 예상보다 시간이 많이 걸린다고 말했습니다. 이는 통제된 측정 방식이 아닌 자가 보고 경험이지만, 여기 제시된 다른 발견들과 일치합니다.

도구가 실제로 도움이 되는 부분

Copilot 연구에서 얻은 속도 향상은 실제였으며, Anthropic 연구에 참여한 일부 사람들은 동일한 도구를 동일한 작업을 수행하는 과정에서 대조군만큼 많이 배웠습니다. AI는 개발자가 이미 이해하고 있는 작업 중 기계적인 부분, 즉 반복되는 코드(boilerplate), 거의 잊어버린 구문(syntax), 이미 계획을 세운 것을 코드로 변환하는 것, 검색 엔진보다 빠르게 생소한 오류를 설명하는 부분 등에서 가장 도움을 주는 경향이 있습니다. 또한 이는 두 번째 의견으로 유용하며, 자신의 설계에 전념하기 전에 되돌아보고 검토할 수 있는 무언가를 제공합니다. 이 모든 것이 AI가 기본적으로 학습을 저해한다는 의미는 아닙니다. 이것은 학습이 도구가 열려 있는지 여부뿐만 아니라 개발자가 그 도구를 사용하는 동안 무엇을 하느냐에 달려 있다는 것을 의미합니다.

속도 제한(Rate limiting): AI를 활용하는 두 가지 방법

두 개발자에게 동일한 작업을 부여했다고 상상해 보세요. 두 사람 모두 AI 어시스턴트를 사용하여 API에 속도 제한(rate limiting)을 추가하는 작업입니다. 이는 포인트를 구체적으로 전달하기 위한 가상의 시나리오일 뿐, 기록된 사건은 아닙니다.

첫 번째 개발자는 구현을 요청하고, Redis를 백업으로 사용하는 슬라이딩 윈도우 카운터로 작동하는 솔루션을 얻고, 테스트가 통과하는 것을 확인한 후 배포합니다. 몇 주 후, 트래픽이 폭증하면서 Redis 연결 풀에서 타임아웃이 발생하기 시작합니다. 그들은 서비스가 저하된 상태에서 재시도 로직(retry logic)과 연결 풀 동작(connection-pool behavior)을 이해하려고 노력하지만, 문제가 자신들의 구현에 있는지, Redis 설정에 있는지, 아니면 둘 다에 있는지 알지 못합니다.

두 번째 개발자는 같은 초기 질문을 던진 후 추가 질문을 합니다. 왜 이 접근 방식이 다른 대안보다 나은가? Redis가 잠시 끊기면 어떻게 되는가? 그들은 먼저 작은 부분을 직접 구현해 보고, 어시스턴트가 생성한 결과물과 비교하며, 재시도 로직이 구조화된 이유를 설명할 수 있을 때만 병합합니다. 이 작업에는 시간이 더 오래 걸립니다. 나중에 같은 Redis 문제가 발생했을 때, 그들은 이미 실패에 대한 작동하는 모델을 가지고 있습니다. 왜냐하면 아직 가능했을 때 일부러 그것을 구축했기 때문입니다.

두 개발자 모두 영구적으로 이런 상태에 갇히는 것은 아닙니다. 첫 번째 개발자도 무언가 고장나기 전에 재시도 로직을 제대로 배울 수 있고, 실제로 많은 개발자들이 정확히 그렇게 합니다. 그들을 구분하는 것은 추상적인 의미에서의 재능이나 근면함이 아닙니다. 한 명은 사전에 작은 비용을 지불했지만, 다른 한 명은 나중에, 아마도 더 안 좋은 시기에 더 큰 비용을 지불할 가능성이 높다는 것입니다.

시도해 볼 만한 것들의 짧은 목록

스스로 접근 방식을 먼저 스케치한 후 어시스턴트에게 요청하세요. 대략적으로라도 말입니다. 코드뿐만 아니라 제안의 근거에 대해 물어보세요. 나중에 혼자 디버깅하는 것처럼 생성된 코드를 검토하세요. 아마도 그렇게 할 것이기 때문입니다. 데모가 한 번 실행되는 것을 확인하는 대신 실제 동작을 테스트하는 테스트를 작성하세요. 무언가가 고장 났을 때, AI에게 수정해 달라고 요청하기 전에 몇 분 동안 스스로 추측하는 시간을 가지세요. 작업을 완료했다고 생각하기 전에 병합된 코드 조각을 소리 내어 설명해 보세요. Anthropic의 연구 결과는 이러한 습관들을 진지하게 받아들일 이유를 제공합니다. 질문하고 코드를 이해하려고 노력한 사람들이 단순히 AI가 작업을 수행하도록 맡긴 사람들보다 일반적으로 더 높은 점수를 받았기 때문입니다.

실제 변수(The real variable)

AI가 시간을 한 시간 절약해 준다면, 그 시간을 그것이 무엇을 생성했는지 실제로 이해하는 데 사용하세요. 만약 그냥 다음 티켓으로 넘어가 버린다면, 내일 디버깅할 준비가 더 잘 된 상태가 되지 않은 채 오늘 더 많은 작업을 끝낼 수도 있습니다.

이번 달에 배포한 AI 지원 코드 조각 하나를 골라보세요. 채팅을 다시 열지 않고도 팀원에게 왜 그것이 이런 방식으로 구축되었는지 설명해 줄 수 있나요?

thebitforge image

(/thebitforge)## TheBitForge팔로우

Founder @thebitforge.dev • Software & AI Product Agency • 172K+ 독자 및 5.8K+ 팔로워 • 우리는 아이디어를 사람들이 사용할 수 있는 디지털 제품으로 만듭니다 | insta에서도 방문하세요 @thebitforge.dev