LLM 코딩 도구의 역설, 생산성은 오르는데 개발자 실력은 왜 정체되나 (NDC 토론토 강연 정리)

핵심 메시지

• 설문 응답자의 약 4분의 3이 LLM에 긍정적이고 80%가 주 수회 이상 쓰지만, 사람 검토 없이 생성 코드를 배포하는 비율은 8%에 그친다.
• 구글 클라우드 DORA 2025 보고서에서도 채택률은 90%, 생산성 향상 응답은 80%인 반면 응답자의 3분의 1은 생성 코드를 전혀 신뢰하지 않는다고 답했다.
• 여러 연구가 LLM 사용이 낯선 코드베이스 이해·디버깅 능력과 학습 지속성을 떨어뜨린다고 보고했다.
• 개발자는 자신이 얼마나 빨라졌는지조차 정확히 못 맞힌다. 한 연구에서는 20% 빨라졌다고 답했지만 실제로는 19% 더 오래 걸렸다.
• 아마존, 리눅스 커널, LLVM은 AI 생성 코드에 사람의 검토·서명을 요구하기 시작했다.

쉽게 이해하기

이 강연은 소프트웨어 엔지니어링 관리자와 전문직 사회학 연구자가 함께 무대에 올라, 생성형 AI가 개발자 개인의 성장 경로에 무엇을 하고 있는지를 다룬다. 두 사람은 링크드인식 일화와 홍보성 주장 대신 지난 1년, 대부분은 최근 6개월 안에 나온 동료 심사 연구와 자체 설문 결과만 근거로 삼았다고 밝힌다.

자체 설문의 그림은 겉보기에 밝다. 응답자의 약 4분의 3이 LLM 기반 도구에 긍정적이거나 매우 긍정적이었고, 80%가 최소 주 수회 사용한다고 답했다. 절반 이상은 생성된 코드 품질이 평균적인 엔지니어와 같거나 그보다 낫다고 봤고, 더 나쁘다고 답한 사람은 한 명도 없었다. 그런데 사람이 검토하지 않고 그대로 프로덕션에 병합한다는 응답은 8%뿐이었다. 품질을 그렇게 높이 평가하면서도 도구를 믿지는 않는 모순이 남는다.

발표자들은 이 모순을 전문성 형성 이론으로 설명한다. 블룸의 분류법과 드레이퍼스 모델을 빌려, 규칙에 의존하는 것은 오히려 초심자이고 전문가는 판단이 몸에 배어 특정 사례의 미묘함을 감지한다고 정리한다. 문제는 그 체화가 직접 부딪히고 실수하는 과정에서만 생긴다는 점이다. 좋은 판단은 경험에서 오고 경험은 나쁜 판단에서 오는데, 도구가 그 경험 구간을 대신 처리해 버리면 무엇이 남느냐는 물음이다.

인용된 연구들은 그 우려를 수치로 보여준다. 오픈소스 프로젝트가 LLM 사용을 허용한 첫 달에 추가된 코드 라인은 3~5배로 늘었지만 정적 분석 경고와 복잡도 지표로 본 품질은 시간이 지날수록 나빠졌다. 앤스로픽 연구자들의 실험에서는 낯선 코드베이스를 다룰 때 LLM을 쓴 참가자의 이해도가 쓰지 않은 쪽보다 뚜렷하게 낮았고, 발표자는 이를 학점 두 단계 차이에 비유했다. 10분 남짓의 사용만으로도 도구가 없을 때 과제를 포기하는 경향이 커졌다는 연구도 소개된다.

더 곤란한 것은 메타인지다. 독일·핀란드 연구에서는 LLM을 잘 안다고 여기는 사람일수록 자기 속도를 더 크게 잘못 추정했고 그 오답에 더 확신했다. 와튼스쿨 연구에서는 일부러 틀린 답을 주입한 모델을 따라간 참가자들이, 도구를 쓰지 않은 사람보다 11% 더 확신에 차 있었다. 발표자들은 여기서 결론을 맺는다. 회계·법률·보험계리 같은 다른 전문직은 신입 훈련 단계에 제한을 두는 방식으로 대응하고 있는데, 소프트웨어 업계의 질문은 여전히 "왜 더 빨리 도입하지 않느냐"에 머물러 있다는 것이다.

주요 인사이트

• 채택률·만족도·생산성 체감은 도구가 조직에 안전하다는 증거가 되지 못한다. 같은 설문에서 신뢰도만 따로 낮게 나오는 것이 실제 판단을 드러낸다.
• "인턴 같다"는 비유는 검토자가 될 사람이 계속 자라난다는 전제 위에서만 성립한다. 그 전제가 흔들리면 비유 자체가 무너진다.
• 생산성 자기 보고는 신뢰하기 어렵다. 체감 속도와 측정된 속도가 반대 방향으로 나온 사례가 있는 만큼, 팀은 체감 대신 실제 소요 시간을 재야 한다.
• 다른 전문직처럼 훈련 초기 구간에 의도적인 제약을 두는 것이 조직 차원의 현실적 대응이 될 수 있다.
• 아마존이 장애 이후 시니어 서명을 의무화하고 리눅스 커널·LLVM이 사람의 소유권을 명시한 흐름은, 당분간 숙련 엔지니어가 필요하다는 업계의 실질적 판단을 보여준다.

자주 묻는 질문

관련 AI 소식