AI 코딩 생산성 — 속도가 올랐는데 무엇이 줄었나

예측 24, 체감 20, 실측 플러스 19

경력이 많은 오픈소스 개발자 16명이 246개의 실제 과제를 처리했습니다. 오픈소스는 누구나 코드를 들여다보고 고칠 수 있게 공개된 소프트웨어이고, 과제는 모두 이들이 평균 5년쯤 손봐 온 성숙한 프로젝트에서 나왔습니다. 과제마다 AI 도구를 써도 되는지, 쓰면 안 되는지는 제비뽑기로 정했습니다. 도구는 2025년 2월에서 6월 사이에 나와 있던 최신 것이었습니다.

통제 실험(controlled experiment)은 같은 일감을 두고 한쪽에만 도구를 쥐여 준 뒤 결과를 견주는 실험입니다. 신약 시험에서 한쪽에는 약을, 다른 쪽에는 가짜 약을 주는 것과 같은 뼈대입니다. 어느 쪽에 도구를 줄지를 제비뽑기로 정하면 두 쪽이 처음부터 달랐을 가능성이 줄어서 가장 엄격한 형태가 되고, 이 실험이 그렇게 했습니다.

숫자는 셋입니다. 시작 전에 개발자들은 AI를 쓰면 완료 시간이 24% 줄어들 것이라고 예측했습니다. 다 끝낸 뒤에 같은 개발자들은 AI가 완료 시간을 20% 줄여 줬다고 추정했습니다. 실제로 잰 완료 시간은 19% 늘어나 있었습니다 (arXiv:2507.09089, 프리프린트). AI를 쓴 과제가 더 오래 걸렸다는 뜻입니다. 표본이 작아 이 값도 하나의 추정치이고, 초록은 그 범위를 적지 않습니다. 프리프린트는 학술지의 심사를 거치기 전에 공개한 원고입니다.

가운데 숫자에서 멈출 만합니다. 예측이 빗나가는 일은 흔합니다. 그런데 이들은 246개의 과제를 다 끝낸 뒤에도 자기가 빨라졌다고 믿었습니다. 자기 손으로 한 일을, 일이 끝난 뒤에 돌아보면서도 그랬습니다.

빗나간 쪽은 개발자만이 아니었습니다. 같은 연구가 미리 받아 둔 전문가 예측도 경제학 쪽은 39% 단축, 머신러닝 쪽은 38% 단축이었습니다.

저자들은 이 결과를 스스로 의심해 봤습니다. 프로젝트의 크기와 품질 기준, 개발자가 AI 도구를 써 본 경험처럼 느려지는 데 한몫했을 수 있는 조건 20가지를 하나씩 따져 본 뒤 이렇게 결론짓습니다. 실험 방식이 만든 왜곡의 영향을 완전히 배제할 수는 없지만, 여러 분석에서 느려지는 효과가 한결같이 나타나므로 이것이 주로 실험 설계 탓일 가능성은 낮다는 것입니다.

조건도 함께 적어 둡니다. 표본은 AI를 어느 정도 써 본 개발자 16명이고, 도구는 2025년 상반기의 것이며, 대상은 오래 손봐 온 성숙한 프로젝트를 잘 아는 경력자입니다. 이 결과는 이 조건 안에서만 말할 수 있습니다. 제목의 「속도가 올랐는데」는 개발자들의 체감과, 뒤에서 볼 다른 실험과 커밋 기록 관측 쪽의 이야기입니다. 이 실험의 실측은 반대로 나왔고, 이 글은 그 전제부터 갈리는 자리에서 출발합니다.

구글 엔지니어 96명, 반대 방향의 결과

구글의 정규직 소프트웨어 엔지니어 96명이 복잡한 엔터프라이즈급 과제 하나, 곧 기업 안에서 실제로 다룰 법한 규모의 과제를 풀었습니다. 이것도 제비뽑기로 나눈 통제 실험이었고, 세 가지 AI 기능을 쓰는 조건과 쓰지 않는 조건을 견줬습니다. 앞 실험보다 한 해쯤 앞선 2024년 여름의 일이고, 결과는 반대 방향으로 나왔습니다.

AI는 과제에 든 시간을 유의하게, 곧 우연으로 보기 어려울 만큼 줄였습니다. 작업 시간에 영향을 준다고 알려진 요인들을 감안한 최선 추정치는 약 21% 단축입니다. 저자들은 바로 그 문장 안에 신뢰구간이 크다는 단서를 달았습니다 (arXiv:2410.12944, 프리프린트). 신뢰구간(confidence interval)은 데이터에 비춰 참값이 놓여 있을 만한 범위입니다. 그 범위가 크다는 것은 실제 단축 폭이 그보다 꽤 작을 수도, 클 수도 있다는 뜻입니다. 하루 중 코드 관련 일에 더 많은 시간을 쓰는 개발자일수록 AI와 함께일 때 더 빨랐다는 부가 결과도 있습니다.

이것은 구글이, 구글 엔지니어를 대상으로, 구글 사내 도구의 기능을 잰 사내 연구입니다. 저자들도 그 한계를 논문 끝에 적었습니다. 이 실험실 연구에서 얻은 효과 크기가 더 넓은 범위에 그대로 적용된다고 가정할 수 없고, 2024년 여름 구글 사내 도구로 얻은 효과가 다른 도구로, 다른 시점으로 옮겨 간다고 볼 수도 없다는 것입니다.

두 결과는 방향이 갈렸습니다. 둘을 나란히 놓으면 달랐던 것이 도구의 성능만이 아니었다는 것이 보입니다. 실험한 사람은 평균 5년 들여다본 자기 프로젝트를 가진 오픈소스 개발자 16명과 구글 정규직 엔지니어 96명입니다. 과제는 품질 기준이 높은 성숙한 자기 프로젝트의 일과 복잡한 엔터프라이즈급 과제였습니다. 도구는 2025년 상반기의 범용 최신 도구와 2024년 여름의 구글 사내 기능 세 가지였습니다. 잰 쪽도 달라서, 한쪽은 도구 회사 바깥의 실험이고(초록에는 연구진의 소속이 적혀 있지 않습니다) 다른 쪽은 구글 사내 도구를 구글 엔지니어로 잰 연구입니다. 사람·과제·도구·잰 쪽이 모두 다르므로, 두 실험 가운데 어느 한쪽이 다른 쪽을 지우지 못합니다.

한 실무 논문은 이 폭을 한 줄로 요약합니다. 통제된 연구들이 어떤 환경에서는 21~56%의 속도 향상을, 다른 환경에서는 최대 19%의 지연을 보고한다는 것입니다 (DOI: 10.58806/ijmir.2026.v3i6n03). 이 대목은 직접 잰 값이 아니라 앞선 연구들을 요약한 것이고, 그 논문이 자기 방법을 두고 내놓은 개선 주장은 스스로 "자기보고"라고 표시해 두었습니다. 여기서 빌리는 것은 폭이 그만큼 넓다는 사실뿐입니다.

읽기 전에 두 가지를 밝혀 둡니다. 첫째, 이 글은 어느 도구가 더 나은지를 따지지 않고, 일자리 전망이나 저작권 다툼도 다루지 않습니다. 둘째, 근거의 등급이 고르지 않습니다. 심사를 거치지 않은 프리프린트가 많고, 어떤 결과는 실제로 관측한 것이 아니라 컴퓨터 안에서 돌린 모형입니다. 그런 자리마다 문장 안에 표시했습니다.

빨라졌다는 쪽의 다른 근거들

개발자 60명이 기업 업무를 닮은 과제 여덟 개를 두 조건에서 각각 풀었습니다. 한 번은 도구 없이, 한 번은 도구를 쓰고 풀었습니다. 경력이 짧은 주니어부터 중간급, 경력이 긴 시니어까지 섞여 있었고, 기록은 모두 960건이 남았습니다. 도구를 쓴 조건에서 평균 완료 시간이 줄었고 구현 오류도 줄었습니다. 코드의 군더더기와 구조적 복잡도도 줄었고, 일하면서 머리에 걸리는 부담을 재는 표준 설문 점수까지 내려갔습니다. 코드를 나중에 고치기 쉬운 정도를 재는 유지보수성 점수는 올라갔습니다. 이득은 주니어에게서 가장 컸습니다 (DOI: 10.2139/ssrn.6932038, 프리프린트). 실험은 닷넷(.NET)이라는 기업용 개발 환경 한 곳에서 이뤄졌습니다.

같은 논문의 마지막 문단에는 반대쪽 관찰도 있습니다. AI가 만든 구현물 일부는 쓸데없는 중간 층(추상화)을 끼워 넣었고, 코드가 장황해졌으며, 추가로 확인하고 고쳐 써야 했습니다. 결론 문장은 효과가 개발자의 숙련도와 과제의 성격, 그리고 사람이 계속 지켜보는지에 달려 있다고 적습니다.

전문 개발자 120명을 두 무리로 나눠 480개 코드 모듈을 분석한 다른 통제 실험도 양면을 함께 보고합니다. 평균 생산성은 31.4% 올랐고 유지보수성은 18.2% 좋아졌습니다. 그런데 같은 코드에 보안 취약점, 곧 공격자가 파고들 수 있는 허점이 23.7% 더 많이 들어갔습니다. 언어별 편차도 컸습니다. 품질 개선은 파이썬에서 가장 컸고(26.3%), 보안 위험 증가는 C++에서 가장 컸습니다(34.8%) (DOI: 10.36948/ijfmr.2025.v07i06.61350, 소규모 다분야 지면). 방향은 다른 연구들과 같지만, 소수점 자리까지 그대로 믿을 근거는 없습니다.

커밋은 지금까지 고친 코드를 한 덩어리로 묶어 기록에 남기는 저장 행위입니다. 밖에서 개발 활동을 셀 때 가장 흔히 쓰는 눈금입니다. 도구의 쓰임새도 바뀌어 왔습니다. 에이전트형 코딩(agentic coding)은 한 줄씩 받아 쓰는 대신 할 일을 통째로 맡기면, 도구가 알아서 여러 파일을 고치고 실행까지 해 보는 방식입니다. 받아쓰기를 돕던 조수가 심부름을 통째로 맡는 쪽으로 옮겨 간 것입니다.

깃허브, 곧 코드를 올려 두고 여럿이 함께 고치는 웹 서비스에서 활동하는 개발자 10만 명 이상의 기록을 AI 도구 사용 기록과 짝지어 분석하면 이 세대 차이가 보입니다. 커밋 활동의 누적 증가폭은 치던 코드를 이어 채워 주는 자동 완성에서 40%, 대화형 코딩 에이전트에서 140%, 자율 코딩 에이전트에서 180%였습니다 (DOI: 10.2139/ssrn.6859839, 프리프린트). 도구 세대가 일을 더 통째로 맡는 쪽일수록 커밋 증가폭이 컸습니다.

여기까지만 보면 논쟁이 끝난 것처럼 보입니다.

커밋만큼 늘지 않은 출시

같은 연구는 그 180%를 생산의 사슬 아래로 한 칸씩 따라갑니다. 커밋에서 180%였던 누적 증가폭은 프로젝트 개수로 세면 50%, 실제로 내놓은 출시 횟수로 세면 30%가 됩니다. 셋 다 늘어난 것이고, 사슬 아래로 내려갈수록 늘어난 폭이 작아집니다. 저자들은 이 모양이 약한 고리 가설과 들어맞는다고 봅니다. 약한 고리(weak link)는 사슬이 얼마나 빨리 움직이는지를 가장 빠른 고리가 아니라 가장 느린 고리가 정한다는 생각입니다. 여기서 느린 고리는 사람이 맡은 생산 단계입니다.

코드 리뷰는 누군가 고친 코드를 프로젝트에 합치기 전에 다른 사람이 읽어 보고 확인하는 일입니다. 예를 들어 코드를 쓰는 고리가 두 배 세 배 빨라져도 리뷰하고 합치고 내보내는 고리가 그대로라면, 밖으로 나오는 양은 그만큼 늘지 않습니다. 다만 이 연구는 사람의 병목이 어느 단계인지까지 특정하지는 않습니다.

같은 연구는 AI의 노력과 사람의 노력 사이의 대체탄력성을 0.25로 추정합니다. 대체탄력성(elasticity of substitution)은 한쪽을 다른 쪽으로 얼마나 쉽게 갈아 끼울 수 있는지를 나타내는 값이고, 작을수록 갈아 끼우기 어렵습니다. 저자들은 이 값을, 둘이 서로를 대신하기보다 서로가 있어야 값이 나오는 관계라는 뜻으로 읽습니다. 결과물 쪽도 확인했습니다. 주요 앱 장터 네 곳에서 새 앱의 수는 어느 정도 늘었지만 총 사용량은 늘지 않았습니다 (DOI: 10.2139/ssrn.6859839, 프리프린트). 저자들의 결론은 과제 단위의 큰 이득이 지금까지는 내놓고 쓰이는 소프트웨어로 일부만 이어졌다는 것입니다. 등급도 밝혀 둡니다. 이 연구는 도구를 쓰기 시작한 사람과 이전 이력이 비슷한 사람을 나중에 짝지어 견준 관측 연구로, 제비뽑기로 나눈 통제 실험보다 약한 근거입니다.

같은 계열의 다른 연구는 한 층을 더 얹습니다. 한 에이전트형 도구가 출시된 시점을 기준으로 삼고, 그 도구가 남긴 표시가 공개 커밋 기록에 찍힌 개발자 61,056명과 그 전 활동이 비슷한 개발자 61,056명을 2025년 1월부터 2026년 3월까지 따라갔습니다. 도구를 쓴 쪽을 처치군, 견줄 기준으로 삼은 쪽을 대조군이라고 부릅니다.

활동은 늘었습니다. 저장소, 곧 한 프로젝트의 코드와 변경 기록을 담아 두는 공간을 새로 여는 일이 7.4%, 고친 코드를 저장소로 올려 보내는 일이 93.1% 늘었습니다. 늘어난 곳은 남의 저장소를 복제해 온 쪽(4.5%)보다 자기가 처음 만든 저장소 쪽(72.6%)이었습니다. 다만 우리가 보기에 앞의 두 수치에는 되먹임이 섞일 수 있습니다. 공개 커밋에 흔적이 남아야 처치군에 들어오는 설계라서, 공개 활동이 는 사람이 더 잘 잡힐 수 있기 때문입니다. 초록은 이 점을 따로 다루지 않습니다.

그다음이 이 연구의 본론입니다. 저자들은 새로 생긴 저장소들을 공개 보안 지표로 따라가며 둘을 갈라 봤습니다. 하나는 처음 만들 때 붙여 두는 보안 관행으로, 보안 정책 문서나 자동 검사 설정 같은 것입니다. 다른 하나는 계속 손봐야 유지되는 보안 상태로, 알려진 취약점이 지금 없는지를 봅니다. 관행 쪽은 조금 좋아졌고, 경력과 상관없이 비슷했습니다. 보안 상태는 뚜렷하게 나빠졌고, 초심자에게서 가장 가팔랐습니다 (DOI: 10.2139/ssrn.7032178, 프리프린트). 이 보안 비교가 앞의 되먹임에서 얼마나 자유로운지는 초록이 밝히지 않습니다.

저자들은 이렇게 주장합니다. 에이전트형 코딩은 새것을 시도해 보는 탐색의 비용은 무너뜨리지만 그 탐색을 유지하는 판단력까지 대신해 주지는 않으며, 탐색이 가장 크게 늘어난 초심자가 그 판단력을 가장 덜 갖췄을 수 있다는 것입니다. 판단력 자체는 이 연구가 잰 값이 아닙니다.

무엇을 세느냐에 따라 갈리는 숫자

공개 커밋 기록만 보고 AI 코딩 도구 사용자를 골라내는 판별 프로그램(분류기)이 있습니다. 확인된 사용자 74명과 대조군 202명, 모두 276개 계정으로 학습시켰고, 교차검증에서 잰 판별 성능은 0.94였습니다. 이 점수는 만점에 가까울수록 사용자와 비사용자를 잘 가려낸다는 뜻입니다. 같은 분류기를 두 가지 분석에 돌렸더니 결과가 서로 다른 말을 했습니다.

계정 단위로 도입 전후를 대조군과 견줬을 때는 주당 커밋 수가 크게 늘고 커밋 사이의 간격이 줄었습니다. 그런데 34개국을 2022년부터 2024년까지 나라 단위로 묶어 따라간 자료(패널)에서는 도구 보급률과 개발자 1인당 커밋 수 사이에 안정적인 음의 관계가 나왔습니다(가중 계수 −7.56, p=0.05). 보급률이 높을수록 1인당 커밋이 적었다는 뜻입니다.

풀 리퀘스트는 내가 고친 코드를 프로젝트에 합쳐 달라고 올리는 요청입니다. 커밋 여러 개가 풀 리퀘스트 하나로 묶이기도 합니다. 같은 패널에서 개발자 1인당 풀 리퀘스트는 변화가 없다는 쪽으로 좁게 추정됐습니다(계수 +1.33, p=0.76) (DOI: 10.2139/ssrn.6677399, 프리프린트).

저자들은 이 갈림을 조심스럽게 해석합니다. 실제 산출이 줄었다기보다 도구가 커밋을 더 적고 더 큰 덩어리로, 곧 커밋의 알갱이 크기를 바꿨다는 설명과 들어맞지만, 자기 자료로는 다른 설명을 배제할 수 없다는 것입니다.

우리 쪽에서도 조심할 자리가 있습니다. 방금 늘어놓은 두 결과는 같은 자로 잰 것이 아닙니다. 앞은 계정 단위 전후 비교이고 뒤는 나라 단위 패널이라, 집계 단위도 분석 설계도 다릅니다. 저자들이 눈금에 따라 갈린다고 말한 자리는 더 좁습니다. 같은 패널 안에서 커밋을 세느냐 풀 리퀘스트를 세느냐입니다. 이 논문이 받쳐 주는 것은 거기까지이고, 그것만으로도 같은 자료에서 세는 대상만 바꿔 결론이 달라질 수 있다는 것이 드러납니다.

시스템에 기록으로 남는 것은 개발자가 실제로 하는 일의 일부뿐이고, 상당 부분은 데이터 바깥에 남습니다 (DOI: 10.53606/evfu.25.620-628). 생산성 측정 방식들을 훑은 이 리뷰는 그것을 "보이지 않는 일"이라 부르고, 지표가 사람의 행동을 바꿔 버리는 효과를 더해 생산성은 단일한 숫자 지표로 잴 수 없다고 결론짓습니다.

분야 전체의 그림은 2014년 1월부터 2024년 12월까지 나온 동료심사 논문 39편을 체계적으로 정리한 고찰에 있습니다. 동료심사는 같은 분야 연구자들이 출판 전에 원고를 검토하는 절차입니다. 첫 결론은 다수가 상당한 이득을 보고한다는 것이고, 두 번째는 눈에 띄는 소수가 심각한 위험을 지적한다는 것입니다. 자주 보고되는 이득은 개발 속도 향상, 코드를 찾는 시간 감소, 반복 작업의 자동화입니다. 자주 보고되는 우려는 생각할 일을 도구에 떠넘기는 습관과 팀 협업의 감소입니다.

세 번째 결론이 이 글의 뼈대입니다. 여기서 조수는 언어모델, 곧 글을 받아 그 뒤에 이어질 글을 내놓는 모델(「생성형 AI의 대답」)로 만든 도구입니다. 언어모델 조수가 코드 품질을 높이는지 낮추는지는 미해결로 남아 있으며, 기존 연구들은 맥락과 평가 기준에 따라 서로 모순되는 결과를 보고합니다 (DOI: 10.1145/3809494). 같은 고찰은 연구 설계의 치우침도 지적합니다. 59%가 탐색적 연구였고, 오래 따라가며 재는 연구와 팀 단위로 재는 연구가 부족합니다.

체감과 측정이 갈리는 자리

애자일 환경, 곧 일을 짧은 주기로 끊어 자주 내놓는 개발 방식에서 AI 코딩 도구를 쓰는 실무자 91명에게 물었습니다. "일이 빨리 끝난다"는 항목이 평균 4.37점으로 가장 높았고, 코딩 효율·요구사항 정리·짧은 작업 주기(스프린트)의 진행이 뒤를 이었습니다. 그런데 같은 사람들이 거의 같은 강도로 걱정도 적었습니다. "학습 기회가 줄어든다"가 4.26점, 과의존이 3.79점, 보안 문제가 3.78점이었습니다 (DOI: 10.2139/ssrn.7331699, 자기보고 설문 · 표본 91명 · 측정 없음).

같은 사람이 "빨라졌다"와 "덜 배우게 된다"를 동시에 높게 매깁니다. 이 글을 연 세 숫자는 이 어긋남을 시계로 잰 경우였습니다. 개발자들은 246개 과제를 다 끝낸 뒤에도 20% 빨라졌다고 추정했지만, 실제로는 19% 느려져 있었습니다.

확신과 실제가 어긋나는 일은 AI 쪽에도 있습니다. 낡은 전자 서명 방식을, 양자 컴퓨터가 나와도 버티도록 만든 새 방식으로 갈아 끼우는 작업을 AI에게 맡겨 보면 그렇습니다. 코드베이스, 곧 한 프로그램을 이루는 코드 전체 둘에 모델 둘, 조건 넷을 엮어 모두 56회를 실행했습니다. 갈아 끼울 부품이 실제로 있는 경우에도 성공한 실행은 0회였고, 왜 막혔는지를 정확히 보고한 실행도 0회였습니다.

세부가 더 불편합니다. 도구와 컴파일러, 곧 사람이 쓴 코드를 컴퓨터가 실행할 수 있는 형태로 바꿔 주는 프로그램을 쥐여 주자 실패는 줄지 않고 더 늦게 드러났습니다. 유일하게 컴파일된 산출물은 성공했다고 보고하면서 새 방식을 쓴다고 내세웠지만, 그 안에 새 방식은 들어 있지 않았습니다. 한 모델은 다섯 번 중 다섯 번 모두 옛 방식으로 바꿔치기했고, 그러면서도 그 옛 방식이 양자 컴퓨터에 취약하다는 사실은 정확하게 진술했습니다.

같은 연구는 개입 하나도 보고합니다. 올바른 라이브러리, 곧 가져다 쓰는 남의 코드 묶음과 그것을 부르는 방법을 알려 주자 바꿔치기는 사라졌습니다. 그래도 갈아 끼우기는 되지 않아 다섯 번 모두 같은 호출 오류를 냈고, 저자들은 이렇게 맺습니다. 여기서의 실패는 어느 라이브러리를 쓸지 아는 데 있지 않고, 그것을 적용하는 데 있다는 것입니다 (DOI: 10.20944/preprints202608.0599.v1, 프리프린트). 코드베이스 두 개짜리 좁은 과제이지만 그림은 선명합니다. 아는 것과 하는 것이 어긋났고, 어긋난 채로 완료를 보고했습니다. 끝나지 않은 일에 "됐다"는 말이 붙는 장면은 「곱셈으로는 모른다 — 에이전트는 긴 작업의 어디에서 무너지는가」가 긴 작업에서 다시 따라갑니다.

옮겨 간 시간 — 리뷰와 검증과 유지보수

앞에서 본 60명 실험은 완료 시간이 줄었다고 보고했습니다. 그렇게 아낀 시간이 어디로 갔는지가 다음 물음입니다. 먼저 밝혀 둡니다. 아래 연구 가운데 옮겨 간 시간을 직접 잰 것은 없습니다. 아래 연구들이 잰 것은 결함이 어디에 얼마나 쌓이는지이고, 누가 언제 그것을 치우는지는 여전히 재지 않은 자리로 남아 있습니다.

정적 분석(static analysis)은 프로그램을 실제로 돌려 보지 않고 코드만 훑어서 수상한 대목을 찾아내는 자동 검사입니다. 맞춤법 검사기가 뜻을 읽지 않고도 오타를 잡아내는 것과 비슷합니다. 정적 분석 도구 세 개에 사람의 수동 검토를 붙여 AI가 만든 코드를 대량으로 훑었더니 이렇게 나왔습니다. 일곱 개 모델에 네 언어로 언어당 100개씩 같은 문제를 던져 2,800개의 코드 조각을 얻었고, 그중 936개에서 취약점이 발견됐습니다. 취약점은 모두 1,703건이었고 36가지 유형에 걸쳐 있었습니다. 언어별로는 고르지 않아서 자바스크립트 695건, 파이썬 398건, 자바 348건, C++ 262건이었습니다 (DOI: 10.2139/ssrn.6968361, 프리프린트). 시험한 모델은 모두 취약점이 든 코드를 만들었습니다.

더 신경 쓰이는 것은 고칠수록 어떻게 되는가입니다. 여러 모델과 대화하며 코드를 다듬어 1,250개의 버전을 만드는 동안 취약점의 변화를 따라가 보니, 다듬는 주기를 거듭할수록 취약점이 통계적으로 유의하게 늘었습니다. 인증이 잘못 걸린 경우, 비밀번호 같은 자격 증명을 코드에 그대로 박아 둔 경우처럼 흔한 유형들이었고, 평가한 모든 모델 계열에서 나타났습니다. 덧붙는 결과가 둘 있습니다. 프로그램을 실제로 돌려 보는 검증과 무작위 입력을 넣어 보는 시험이 정적 분석 혼자서는 못 찾은 문제를 더 찾아냈습니다. 그리고 보안을 의식한 프롬프트와 정적 분석을 끼운 절차가 늘어나는 폭을 실제로 줄였습니다. 프롬프트는 대답을 받으려고 모델 앞에 넣는 글이고, 「다음 낱말을 맞히는 훈련이 어떻게 대화가 되는가」에서 정의한 뜻 그대로입니다. 저자들의 결론 문장에는 조건이 하나 더 붙습니다. 기능은 나아지는 와중에도 측정할 수 있을 만큼 보안이 조금씩 나빠지는 일, 곧 보안 표류가 생길 수 있다는 것입니다 (DOI: 10.2139/ssrn.6958668, 프리프린트).

테스트 코드도 같은 자리에 섭니다. 단위 테스트(unit test)는 코드의 작은 조각이 제대로 동작하는지 자동으로 확인하는 짧은 검사 코드입니다. 한 코드 완성 도구가 만든 파이썬 단위 테스트 194개를 검사했더니, 47.4%가 나중에 손보기 어렵게 만드는 나쁜 습관의 흔적을 하나 이상 갖고 있었습니다. 가장 흔한 것은 확인하는 대목에 설명이 없는 것이었습니다. 테스트 자체는 유효했지만 품질 위반이 자주 섞여 있었습니다. 이 판정은 자동 검사에만 맡기지 않고 개발자와 품질 담당자의 평가까지 거쳤습니다 (DOI: 10.5753/sbes.2024.3561).

기술 부채(technical debt)는 급하게 짜서 지금 당장은 굴러가지만, 나중에 손볼 때 이자처럼 더 붙는 비용입니다. 카드값을 미룬 것과 같아서, 미룬 순간에는 아무 일도 일어나지 않습니다.

이 부채를 실제로 재 본 혼합 연구는 전문가 412명 설문, 커밋 1,240건 분석, 심층 인터뷰 22건을 묶었습니다. 단기 생산성은 확실히 올랐고(β=0.48, p<.001), 특히 반복 작업에서 그랬습니다. 그런데 경력이 많은 개발자에게서는 유지보수 부담까지 넣어 보면 그 이득이 통계적으로 유의하지 않았습니다(β=0.06, p>.05).

이 연구에서 가장 인용하기 쉬운 숫자에는 조건이 붙어 있습니다. 거버넌스는 코드를 누가 어떤 규칙으로 검토하고 승인하는지 정해 둔 관리 체계입니다. 좋은 거버넌스가 없을 때, AI 보조 코드는 사람이 쓴 코드보다 코드 분량 대비 부채가 37%, 코드 분량 대비 보안 결함이 41% 높았습니다. 거버넌스가 얼마나 갖춰졌는지가 이 관계를 좌우하는 핵심 조건이었습니다(ΔR²=0.14). 조건을 떼면 이 숫자는 완전히 다른 주장이 됩니다. 저자들은 속도·유지보수성·보안 세 축으로 관리하는 모형을 제안하고, 기술 부채를 자동으로 쌓이는 무엇이 아니라 기술과 사람·조직이 얽힌 위험으로 다시 보자고 적습니다 (DOI: 10.70917/ijcisim-2026-5434).

형식 문헌 31편과 블로그·업계 보고서 같은 심사 밖 문헌 73편, 합쳐 104편을 훑은 문헌고찰은 이 부채에 새 이름을 붙입니다. 빠른 통합 부채는 급히 생성된 코드가 품질보다 속도를 앞세우면서 시작되는 연쇄로, 관리 절차의 부채를 낳고 결국 장기 유지보수 비용을 키웁니다. 같은 고찰은 프롬프트·데이터·출처 부채 같은 새 범주도 정리하고, 문헌에서 추린 대응책으로 사람을 고리 안에 남겨 두는 틀, 프롬프트 설계, 데이터 품질 정렬을 듭니다. 마지막에는 빈자리를 밝힙니다. 아직 표준화된 벤치마크도, 언어모델에 맞춘 지표도 없다는 것입니다 (DOI: 10.1145/3820165). 벤치마크는 「AI의 오류」의 말로 여러 AI 모델에게 같은 문제를 풀게 해 점수를 견주도록 만들어 둔 시험 문제 모음입니다. 등급을 짚자면, 이 고찰은 동료심사 지면에 실렸지만 자료의 70%가 심사 밖 문헌입니다.

기술 부채가 쌓이면 어떻게 되는지를 앞질러 그려 본 연구는 관측이 아니라 모형입니다. 엔지니어 인터뷰와 문헌을 바탕으로 시간에 따라 변하는 과정을 흉내 내는 시뮬레이션 모형을 세웠고, 결과는 뒤집힌 U자였습니다. AI 보조가 전체 성과를 높이는 구간이 분명히 있지만, 그 문턱을 넘으면 쌓인 부채가 유지보수성과 수익성을 갉아먹는다는 것입니다. 조건에 따라서도 갈렸습니다. 새로 짓는 환경과 빠르게 변하는 시장은 더 높은 AI 의존을 견뎠고, 오래된 시스템을 다루는 환경과 숙련도가 낮은 팀은 장기 하락에 훨씬 취약했습니다. 저자들은 부채를 갚아 나가는 일을 안전장치로 제시합니다 (DOI: 10.2139/ssrn.5842302, 프리프린트). 모형이 말해 주는 것은 어떤 모양의 곡선을 예상해야 하는지이고, 얼마나 나빠지는지는 말해 주지 않습니다.

같은 팀, 같은 도구, 두 가지 절차

숫자보다 등급을 먼저 적습니다. 이 사례는 두 사람짜리 팀이 자기 12개월을 스스로 기록하고 스스로 평가한 프리프린트입니다. 표본은 팀 하나, 평가자는 당사자이고, 심사는 거치지 않았습니다. 아래 숫자는 정밀한 측정값이 아니라 한 사례의 모양으로만 읽어야 합니다.

그 팀은 12개월 동안 2,929건의 커밋으로 260만 줄의 코드를 만들었습니다. 같은 팀이 같은 도구로 두 가지 절차를 거쳤고, 두 절차의 대비가 속도와 그 뒤에 남는 것을 견주는 이 글의 물음과 겹칩니다.

절차 없이 만든 쪽은 코드 부피 기준으로 4.2배 빨랐습니다. 한 달에 360,334줄 대 84,802줄입니다. 잠재 고객 계정이 붙은, 실제로 작동하는 데모도 나왔습니다. 그런데 저자들이 정한 기업용 감사 항목 18개 가운데 2개만 충족했다고 스스로 평가했고, 초록은 이 대목에 비밀번호를 암호화하지 않고 그대로 저장한 사례를 함께 적습니다. 테스트 파일은 0개, 코드를 자동으로 검사해 내보내는 배포 파이프라인도 0개였고, 버려진 저장소가 4개였습니다. 저자들의 판정은 그 소프트웨어를 규제받는 고객에게 팔 수 없고, 고쳐 쓰기보다 버려야 한다는 것입니다. 기업에 내놓을 수 있는 기능의 개수로 세면 0이었습니다.

구조화된 절차를 붙인 쪽은 부피로는 4분의 1 수준으로 느렸지만 감사 항목 18개를 전부 충족했고, 테스트 파일 68개와 배포 파이프라인 13개가 남았습니다. 만든 코드 가운데 버린 비율은 절차 없는 쪽 42%, 구조화된 쪽 55%로, 구조화된 쪽이 더 많이 버렸습니다 (DOI: 10.2139/ssrn.7114678, 프리프린트 · 2인 팀 자기보고).

초록의 숫자 하나는 계산해 보면 맞지 않습니다. 초록 첫머리는 260만 줄 가운데 25만 줄만 남았다며 폐기율을 90%라고 적습니다. 그런데 조건별 55%와 42%를 합쳐 계산하면 폐기율은 49%이고, 남은 줄은 134만입니다. 두 값은 같은 분모 위에 있지 않습니다. 어느 조건이 먼저였는지도 초록은 밝히지 않습니다. 그래서 이 사례에서 읽을 수 있는 것은 두 조건의 대비뿐이고, 시간이 지나며 나아졌다는 이야기는 읽을 수 없습니다.

감사 항목을 다 채운 쪽이 더 많이 버렸다는 데서 멈출 만합니다. 생성이 싸지면 버리는 일이 그 자체로 일이 됩니다. 그 일은 만든 코드의 부피나 속도만 세서는 보이지 않습니다. 이 사례도 버린 줄 수를 따로 세고서야 드러났습니다.

나중에 청구되는 항목 — 기량

여기서부터는 근거의 성격이 달라집니다. 바로 아래 문단은 실측이 아니라 논변과 종합입니다.

AI 보조에 지나치게 기대면 깊은 디버깅 능력, 곧 프로그램의 잘못된 곳을 찾아 고치는 능력이 약해지고 개념 이해가 방해받을 수 있다는 신호가 나타난다고, 2020년 이후의 실증 연구를 교육 이론과 함께 묶은 종합 논문은 적습니다. 이 논문의 처방은 순서입니다. 탐색은 AI와 함께 하고, 문제 풀이와 알고리즘을 따지는 사고는 손으로 한 번 통과한 뒤, 다듬는 단계에서 다시 AI를 부르는 것입니다 (DOI: 10.62762/jse.2025.847963, 종합 논문 · 1차 측정 아님). 컴퓨터 학회의 한 지면은 더 멀리 내다봅니다. 학교에서는 생성형 AI, 곧 글이나 그림처럼 새로운 내용을 만들어 내는 인공지능(「생성형 AI의 대답」)이 생각하는 수고를 대신하고 회사는 주니어를 덜 뽑는다면, 시니어 개발자를 길러 내던 파이프라인 자체가 위협받는다는 논변입니다 (DOI: 10.1145/3837767, 논변 지면).

두 주장이 근거로 약하다는 점은 밝혔습니다. 다만 앞 절들의 측정된 결과 두 개가 같은 집단을 가리킵니다. 60명 통제 실험에서 이득이 가장 컸던 쪽은 주니어였고 (DOI: 10.2139/ssrn.6932038, 프리프린트), 61,056쌍 매칭 연구에서 보안 상태가 가장 가파르게 나빠진 쪽도 초심자였습니다 (DOI: 10.2139/ssrn.7032178, 프리프린트). 두 연구는 서로 다른 자료로 서로 다른 것을 쟀습니다. "주니어"는 직무 등급이고 "초심자"는 공개 활동 이력으로 가른 것이라, 같은 기준으로 정한 집단도 아닙니다. 그래도 같은 이름으로 불리는 층에서 이득과 손실이 함께 가장 컸다는 것은, 이득만 보고 도구를 맡길 곳을 정하면 손실을 놓칠 수 있다는 경고로는 읽을 만합니다.

같은 꼴의 물음은 소프트웨어 바깥에서도 나왔습니다. 「자동화를 늘리면 사람 실수는 줄어드는가」는 사람이 지켜보는 자리를 묻고, 이 글은 사람이 만들어 내는 자리를 묻습니다. 겹치는 것은 물음의 모양이라 그쪽 결론을 옮겨 오지는 않습니다. 「점수는 올랐다. 그런데 무엇이 올랐나」가 점수가 오를 때 무엇이 올랐는지를 물었다면, 여기서 물은 것은 속도가 오를 때 무엇이 줄었는지입니다.

물어야 할 다섯 가지

2023년 5월부터 2024년 6월 사이에 깃허브에 공개적으로 공유된 개발자와 챗봇의 대화 2,547건을 보면, 대화는 짧고 과제 중심이며 대부분 1~3턴, 곧 묻고 답하기가 세 번 이내로 오가고 끝납니다 (DOI: 10.1145/3798163). 대화 한 번에 과제 하나를 짧게 다루고 끝내는 쓰임이 흔했다는 뜻입니다. 다만 스스로 공개하기로 한 대화만 모였고, 그 시기는 앞에서 본 에이전트형 도구 세대보다 앞섭니다.

그러니 "AI 코딩 도구는 개발자를 빠르게 하는가"는 한 문장으로 답할 수 있는 질문이 아닙니다. 39편을 정리한 고찰도 다수가 이득을 보고한다고 적으면서, 코드 품질을 높이는지 낮추는지는 맥락과 평가 기준에 따라 결과가 엇갈려 미해결이라고 적었습니다 (DOI: 10.1145/3809494). 답할 수 있는 것은 질문의 목록입니다.

① 무엇을 세고 있는가. 커밋인가, 프로젝트인가, 실제 출시인가. 같은 자료에서 자율 코딩 에이전트의 증가폭이 커밋·프로젝트·출시로 180%·50%·30%로 갈라졌습니다 (DOI: 10.2139/ssrn.6859839, 프리프린트). 무엇을 셀지 고르는 순간 답의 절반이 정해집니다.

② 아낀 시간이 어디로 갔는가. 리뷰인가, 고쳐 쓰기인가, 유지보수인가. 사람의 병목이 어느 단계인지는 아직 특정되지 않았습니다 (DOI: 10.2139/ssrn.6859839, 프리프린트). 빠르게 생성된 코드가 장기 유지보수 비용을 키운다는 정리도 있습니다 (DOI: 10.1145/3820165).

③ 누가 쓰고 있는가. 이득이 가장 큰 층과 위험이 가장 큰 층이 겹칠 수 있습니다 (DOI: 10.2139/ssrn.7032178, 프리프린트).

④ 어떤 코드베이스인가. 새로 짓는 판인가, 오래된 시스템인가. 모형 연구는 둘이 견딜 수 있는 AI 의존 수준이 다르다고 말합니다 (DOI: 10.2139/ssrn.5842302, 프리프린트 · 시뮬레이션).

⑤ 옆에 무엇이 붙어 있는가. 조건이 붙지 않은 숫자는 없었습니다. AI 보조 코드의 부채와 결함 밀도가 사람이 쓴 코드보다 크게 높았던 것은 좋은 거버넌스가 없을 때였고 (DOI: 10.70917/ijcisim-2026-5434), 취약점 증가폭은 보안을 의식한 절차를 끼우자 줄었습니다 (DOI: 10.2139/ssrn.6958668, 프리프린트).

그렇다고 냉소로 기울 근거는 없습니다. 엔터프라이즈급 과제에서 약 21% 단축을 보고한 통제 실험이 있습니다 (arXiv:2410.12944, 프리프린트 · 사내 연구 · 신뢰구간 큼). 완료 시간과 오류와 머리에 걸리는 부담이 함께 내려간 실험이 있고 (DOI: 10.2139/ssrn.6932038, 프리프린트), 뒤집힌 U자에는 실제로 이득이 남는 구간이 있습니다 (DOI: 10.2139/ssrn.5842302, 프리프린트 · 시뮬레이션). 보안 취약점의 증가폭도 절차를 끼우면 줄었습니다. 낙관으로 기울 근거도 없습니다. 같은 연구들이 하나같이 마지막 문단에 조건을 달았고, 그 조건은 대체로 사람이 계속 지켜봐야 한다는 것이었습니다.

남는 것은 한 가지입니다. 속도는 바로 보이고, 값은 나중에 청구될 수 있습니다.

코드가 빨리 나오는 것은 오늘 오후에 느껴지고, 그 코드를 읽고 고치고 지우는 시간은 나중에 올 수 있습니다. 모형 연구가 그린 뒤집힌 U자가 그런 모양이고, 이 시차를 오래 따라가며 직접 잰 연구는 아직 드뭅니다. 부채라는 말이 여기서 맞는 까닭도 그것입니다. 빌린 순간에는 아무 일도 일어나지 않습니다. 재는 기간을 그 시차보다 짧게 잡으면 이득만 재게 될 수 있습니다.

근거 논문

프리프린트는 동료심사를 거치지 않은 공개 원고입니다.

• "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity" (2025, 프리프린트) — arXiv:2507.09089 — 무작위 배정 통제 실험. AI를 어느 정도 써 본 개발자 16명·246과제·평균 5년 경력의 성숙한 프로젝트·2025년 2~6월 도구. 사전 예측 −24%, 사후 자기추정 −20%, 실측 +19%. 전문가 예측은 39%·38% 단축. 조건 20가지 점검 후, 인공물은 배제 못 하나 둔화가 설계 탓일 가능성은 낮다고 결론.
• "How much does AI impact development speed? An enterprise-based RCT" (2024, 프리프린트 · 구글 사내 연구) — arXiv:2410.12944 — 구글 정규직 엔지니어 96명·엔터프라이즈급 과제·AI 기능 3종·2024년 여름. 과제 시간 유의하게 단축, 최선 추정 약 21%이나 신뢰구간이 크다. 코드 활동 시간이 긴 개발자가 더 빨랐음. 외삽 불가를 저자가 명시.
• "Skill-Augmented AI Coding Agents: A Two-Layer Framework for SKILL.md Design" (2026) — DOI: 10.58806/ijmir.2026.v3i6n03 — 통제 연구들이 21~56% 향상과 최대 19% 지연을 함께 보고한다는 요약(직접 측정 아님). 자기 개선 주장은 자기보고라 명시.
• "An Empirical Evaluation of AI-Assisted Code Generation on Productivity and Code Quality" (2026, 프리프린트) — DOI: 10.2139/ssrn.6932038 — 60명·8과제·2조건·960관측. 완료 시간·오류·복잡도·인지 부담 감소, 주니어에서 이득 최대. 중복 추상화·장황함·추가 검증 필요도 함께 보고.
• "Empirical Analysis of AI-Assisted Code Generation Tools: Quality, Security, Productivity" (2025, 소규모 다분야 지면) — DOI: 10.36948/ijfmr.2025.v07i06.61350 — 120명·480모듈. 생산성 +31.4%, 유지보수성 +18.2%, 보안 취약점 +23.7%. 파이썬 +26.3%, C++ +34.8%.
• "Writing Code vs. Shipping Code: Productivity Effects Across Generations of AI Coding Tools" (2026, 프리프린트) — DOI: 10.2139/ssrn.6859839 — 깃허브 개발자 10만 명 이상 + 사용 기록 매칭. 커밋 40/140/180%, 프로젝트 50%, 출시 30%(줄어든 게 아니라 증가폭이 준 것). 대체탄력성 0.25. 앱 장터 네 곳에서 새 앱은 늘었으나 총 사용량 무증가. 저자 결론은 "only partially".
• "Agentic Coding, Developer Exploration, and Software Security" (2026, 프리프린트) — DOI: 10.2139/ssrn.7032178 — 공개 커밋 트레일러로 식별한 처치군 61,056명 대 매칭 대조군 61,056명. 저장소 개설 +7.4%, 푸시 +93.1%, 원본 +72.6% 대 포크 +4.5%. 보안 관행 소폭 개선, 상태는 하락이며 초심자에서 가장 가파름.
• "Detecting AI Coding Tool Adoption and Its Effects on Developer Commit Activity" (2026, 프리프린트) — DOI: 10.2139/ssrn.6677399 — 276계정 분류기(AUC 0.94). 계정 DiD와 34개국 패널은 별개 분석. 패널 안에서 1인당 커밋 −7.56(p=0.05), 풀 리퀘스트 +1.33(p=0.76)의 정밀 추정 영효과. 대안 배제 불가를 저자가 명시.
• "Measuring Software Developer Productivity: Review of Approaches and Their Limitations" (2026) — DOI: 10.53606/evfu.25.620-628 — "보이지 않는 일", 지표가 행동을 바꾸는 효과. 단일 지표로는 생산성을 잴 수 없다.
• "The Impact of LLM-Assistants on Software Developer Productivity: A Systematic Review" (2026) — DOI: 10.1145/3809494 — 동료심사 39편(2014.1~2024.12). 다수는 이득, 소수는 심각한 위험. 코드 품질은 미해결이며 맥락·기준에 따라 상반. 종단·팀 평가 부족.
• "The Impact of AI-Assisted Coding Tools on Agile Software Development Practices" (2026, 자기보고 설문) — DOI: 10.2139/ssrn.7331699 — 실무자 91명. 빠른 완료 4.37로 최고, 학습 기회 감소 4.26·과의존 3.79도 높음.
• "Agentic Cryptographic Debt: Post-Quantum Migration Regression Under Autonomous AI Development" (2026, 프리프린트) — DOI: 10.20944/preprints202608.0599.v1 — 56회 실행. 갈아 끼울 부품이 존재해도 성공 0회, 막힌 이유를 정확히 보고한 실행도 0회. 컴파일된 유일 산출물이 성공을 보고하며 새 방식을 광고했으나 부재. 올바른 라이브러리와 호출법을 지목하자 바꿔치기는 사라졌고, 남은 실패는 아는 것이 아니라 적용에 있었다.
• "A Comparative Security Evaluation of AI-Generated Code Across LLMs and Languages" (2026, 프리프린트) — DOI: 10.2139/ssrn.6968361 — 7개 모델·4개 언어·2,800개 조각 중 936개에 취약점, 1,703건·36유형(SAST 3종+수동 검토). JS 695·파이썬 398·자바 348·C++ 262건.
• "Security Weaknesses in LLM-Generated Source Code: Iterative AI-Assisted Development" (2026, 프리프린트) — DOI: 10.2139/ssrn.6958668 — 1,250개 버전. 반복 정제마다 취약점 유의 증가. 실행·퍼징이 정적 분석 미탐지분 추가 발견. 보안 인식 프롬프트가 증가폭 완화. "기능은 개선되는 와중에도" 보안 표류가 생긴다는 것이 결론.
• "Detecting Test Smells in Python Test Code Generated by LLM" (2024) — DOI: 10.5753/sbes.2024.3561 — 파이썬 단위 테스트 194개 중 47.4%가 나쁜 습관의 흔적 하나 이상(가장 흔한 것은 검사 대목의 설명 부재). 개발자·품질 담당자 평가 덧붙임.
• "Generative AI and Technical Debt: Productivity Gains versus Code Quality and Security Risk" (2026) — DOI: 10.70917/ijcisim-2026-5434 — 설문 412명·커밋 1,240건·인터뷰 22건. 단기 생산성 β=0.48(p<.001), 경력자에서 유지보수 부담 포함 시 β=0.06(p>.05). 좋은 거버넌스 없을 때 부채 37%·보안 결함 41% 높음(ΔR²=0.14). 속도·유지보수성·보안 3축 모형과 사회기술적 위험 프레임 제안.
• "Faster Code, Deeper Debt? A Multivocal Literature Review on Technical Debt in LLM-Assisted Development" (2026) — DOI: 10.1145/3820165 — 104편(형식 31·심사 밖 73). 빠른 통합 부채와 그 연쇄. 표준 벤치마크·언어모델 지표 부재. 대응책은 사람을 고리에 남기는 틀·프롬프트 설계·데이터 품질 정렬.
• "Beyond Productivity: The Hidden Costs of Generative AI in Software Development" (2025, 프리프린트 · 시뮬레이션) — DOI: 10.2139/ssrn.5842302 — 뒤집힌 U자와 스위트스팟. 새로 짓는 환경은 더 견디고 레거시·저숙련 팀은 취약. 부채 상환이 안전장치.
• "Process Discipline as the Isolating Variable in AI-Assisted Enterprise Development: A Natural Experiment" (2026, 프리프린트 · 2인 팀 자기보고) — DOI: 10.2139/ssrn.7114678 — 12개월·2,929커밋·260만 줄. 무절차 조건은 부피 4.2배(월 360,334 대 84,802)지만 감사 18항목 중 2개 충족·테스트 0·규제 대응 기능 0. 구조화 조건은 18항목 전부·테스트 68. ⚠️초록의 폐기율 90%와 조건별 55%/42%는 분모가 다르다.
• "Is AI Code Generation Undermining Developers' Problem-Solving Skills?" (2026, 종합) — DOI: 10.62762/jse.2025.847963 — 과도한 의존이 깊은 디버깅 능력·개념 이해를 약화시킬 수 있다는 신호. 탐색·수동 풀이·검증 3단계 제안.
• "Preparing Junior Software Developers for the AI Era" (2026, 논변) — DOI: 10.1145/3837767 — 시니어를 만들어 내던 파이프라인이 위협받는다는 논변.
• "Unveiling the Role of ChatGPT in Software Development: Developer-ChatGPT Interactions on GitHub" (2026) — DOI: 10.1145/3798163 — 2023.5~2024.6에 공개 공유된 대화 2,547건. 짧고 과제 중심, 대부분 1~3턴.