GN⁺: LLM이 실제로 프로그래머의 생산성을 얼마나 향상시키고 있을까?
(lesswrong.com)- LLM 기반 코딩 보조 도구가 출시된 지 약 2년이 되었음
- 일부 개발자는 생산성이 최대 5배에서 10배까지 증가했다고 보고함
- 그러나 소프트웨어 업계 전체의 생산성이 5~10배 증가했다는 명확한 증거는 없음
- 실제로 코드베이스에 단순한 보일러플레이트 기능을 추가하는 것 이상의 작업에서는 LLM 도구가 까다롭게 작동함
- 대부분의 프로그래머는 LLM 도구를 효과적으로 사용하는 방법을 모르거나 관심이 없음
생산성 향상이 특정 사용자에게만 집중되는 이유
- 만약 생산성이 5배에서 10배 증가했다면, 이는 LLM을 잘 다루는 소수의 고급 사용자나 숙련된 개발자에게 국한될 가능성이 높음
- 전체 소프트웨어 업계가 급격히 더 많은 유용한 기능을 제공하거나 품질이 눈에 띄게 향상되었다는 징후는 없음
- 필자는 지난 1~2년 동안 LLM의 영향력을 거의 체감하지 못했음
실제로 LLM이 어떤 프로젝트를 가능하게 했는가?
- LLM의 성능 덕분에 활성화된 프로젝트가 무엇인지 명확히 확인되지 않음
- 연구 결과에서도 구체적인 사례는 거의 발견되지 않음 (COBOL 리팩터링 정도가 유일한 예)
- AGI 연구소의 LLM 기반 제품도 특별히 인상적인 성과를 보이지 않음
- 대화 상자에서 PDF 업로드와 같은 기본적인 기능 제공 수준
- LLM이 다양한 소프트웨어 및 데이터 유형에 원활히 인터페이스하도록 하는 기능은 부족함
질문: 실제로 생산성이 증가한 분야가 있는가?
- 어떤 프로젝트가 LLM 덕분에 빠르게 출시되었는지에 대한 명확한 증거가 없음
- 소프트웨어 생태계에서 특정 분야가 10배 성장한 흔적이 보이지 않음
원하는 것은 명확한 실질적 증거
- 아래와 같은 유형의 정보는 불필요함
- 생산성 10배 향상에 대한 모호한 주장
- 추상적인 경제 지표나 코드 생산량 증가에 대한 언급
- 단순한 LLM 기반 도구나 기능 생성 사례
- "ChatGPT로 Snake 클론 만들기" 같은 사소한 예제
음모론: LLM이 실제 생산성을 증가시키지 못하고 있을 가능성
- LLM이 생성한 코드 수정 및 문제 해결에 오히려 시간이 소모됨
- LLM이 생성한 대규모 코드베이스가 일정 복잡성을 넘어서면 수정이 불가능해져 결국 처음부터 다시 작성해야 하는 경우 발생
- LLM이 새로운 소프트웨어를 만들더라도 대부분 일회성 도구나 사용되지 않는 증명용 코드에 그칠 가능성 높음
- 실제 유용한 소프트웨어에서 코드 양이 늘어나더라도 불필요한 기능이나 블로트웨어(bloatware)가 증가할 위험 있음
- 프로그래머들이 LLM을 통해 즉각적인 결과를 얻는 '마법' 같은 경험에 속고 있을 가능성 존재
현실적인 생산성 향상 범위
- 필자가 경험한 바에 따르면 LLM은 다음과 같은 특정 경우에만 유용함
- 사소한 기능 작성
- 특정 라이브러리나 코드베이스 학습 보조
- 간단한 리팩터링 작업 수행
- 생산성 향상 폭은 대략 10~30% 수준일 가능성이 높음
- 생산성 극대화는 AGI(인공 일반 지능)가 등장하기 전까지는 어려울 것으로 보임
[Richard Horvath의 댓글]
특정 상황에서 LLM이 10배 속도 향상을 제공할 수 있는 경우
-
작은 독립형 스크립트 작성
- 간단한 작업(예: 파일 조작을 위한 bash 스크립트, Excel VBA 코드) 작성 시 큰 성과를 보임
- 짧은 설명만으로 쉽게 작성 가능하며 검증도 용이함
- 언어에 대한 깊은 지식이 없어도 작성 가능함
- 유지보수, 모듈화, 유닛 테스트 등을 고려할 필요가 없음
- 특히 정규식(regex)과 관련된 작업에서 매우 효과적임
-
낯선 스택에서 작업할 때 학습 속도 향상
- 새로운 라이브러리의 클래스 및 메서드를 빠르게 파악 가능
- 코드가 완전히 작동하지 않더라도 문제 해결 접근법을 제공함
- 기존에 문서나 강의를 찾아보는 데 걸리던 시간을 대폭 단축시킴
- 그러나 생성된 코드는 직접 수정 및 리팩토링이 필요함
10배 생산성 증가를 보고하는 사람들의 유형은 다음과 같은 경우에 해당할 가능성이 높음
-
개발 지식이 낮은 경우
- 기초적인 코딩 능력이 부족한 경우, LLM의 도움으로 작성된 코드가 이전보다 월등히 나아 보일 수 있음
- 그러나 이런 경우 LLM 코드가 장기적으로 부정적인 영향을 미칠 가능성이 높음
-
작고 독립적인 솔루션을 많이 작성해야 하는 경우
- 엑셀 자동화 작업이나 DevOps에서의 쉘 스크립트 작성 등은 LLM이 특히 유용함
-
다양한 스택과 라이브러리를 자주 실험해야 하는 경우
- 장기적으로 특정 스택에서 작업하는 경우보다 실험 위주의 작업이 주를 이루는 경우에 해당
-
앵커링 효과(Anchoring Effect) 발생
- LLM이 특정 작업에서 즉각적인 성과를 내자 이를 장기적인 생산성 향상으로 과대평가할 가능성이 높음
[Davidmanheim의 댓글]
- 일반적인 회사에서 코딩하는 사람들과 경영진의 관점에서 LLM의 생산성 향상이 실제로는 제한적일 수밖에 없음
- 이는 제약 이론(Theory of Constraints) 의 관점에서 설명됨:
- 이전에는 다음과 같은 작업 프로세스를 통해 작업이 완료되었다고 가정:
- 비즈니스 애널리스트(Business Analyst) → 하루 소요
- QA 테스터 → 하루 소요
- 프로그래머 → 하루 소요
- 프로그래머의 생산성이 2배 또는 5배로 증가하더라도 전체 작업 시간이 단축되지 않음
- 다른 단계(비즈니스 분석 및 QA)가 병목이 되기 때문에 전체 프로세스의 속도는 그대로 유지됨
- 이전에는 다음과 같은 작업 프로세스를 통해 작업이 완료되었다고 가정:
-
기업 프로세스 재구성이 필요함
- LLM의 생산성 향상을 최대한 활용하려면 기업의 전체 프로세스를 재구성해야 함
- 그러나 현재 일부 기업에서만 이와 같은 프로세스 재구성이 시작되고 있는 상황임
[faul_sname의 댓글]
- LLM으로 특히 UI 목업 생성에서 다음과 같은 성과를 경험했음:
- 이전에는 UI 목업 생성이 전체 작업 시간의 약 10%를 차지했음
- LLM 덕분에 UI 목업 생성 속도가 약 5배 빨라짐
- 그러나 작업 시간 자체가 줄어든 것은 아님
- 대신 UI 목업의 디테일과 상호작용성이 크게 향상됨
- 더 많은 반복 작업이 가능해져 결과적으로 제품의 품질이 개선됨
- "버려질 코드"가 반드시 쓸모없다는 의미는 아님
- 프로토타입이나 증명용 코드라도 더 나은 최종 제품 개발에 기여할 수 있음
- 또한 LLM은 검색 엔진으로 찾기 어려운 특정 오류에 대한 답변을 제공함
- 예시: "xyz 스택에서 실행 중인 작업에서 발생한 오류 해결 방법"
- 구체적인 스택 및 Kubernetes 설정 상황에서 디버깅을 도와줌
- 전체 생산성 증가율은 약 10~30% 수준으로 평가함
- 그러나 모든 작업에서 고르게 생산성이 향상된 것은 아님
- 특정 작업에서 획기적인 속도 향상 (예: UI 목업, 디버깅 등)
- 복잡하거나 레거시 코드 작업에서는 별다른 성과 없음
- 프로젝트 초기에 생산성 향상이 두드러지며, 복잡한 유지보수 단계에서는 효과 감소
- 따라서 여기서의 한계는 에이전시(Agency) 부족이 아니라 문맥 관리(Context Management) 문제라고 봄
[Noosphere89의 댓글]
-
Ajeya Cotra의 견해를 인용하며 LLM의 프로그래머 생산성 향상 효과에 대해 다음과 같은 요점을 언급함:
-
코딩 작업에서 AI의 생산성은 예상보다 높음
- AI는 코딩 작업에서 상당한 성과를 내고 있음
- 그러나 코딩 외 작업에서는 성능이 크게 떨어짐
- 따라서 AI의 전체적인 산업적 영향은 아직 제한적임
-
코딩 작업에서 AI의 생산성은 예상보다 높음
- Ajeya Cotra의 관련 발언 링크
- "장기적인 성과를 내려면 AGI가 필요하다"는 주장에 대해서는
- 현재 AI의 발전 경로에는 일반적인 능력(Generality)이 예상보다 적음
- AI의 성능이 특정 작업에서 급격히 향상되거나, 특정 영역에서 약점이 나타나는 경우가 많음
- 이러한 성능의 불균형 때문에 AGI(인공 일반 지능)라는 개념이 예상보다 덜 유용할 수 있음
[yo-cuddles의 댓글]
- 내 사무실에서 로봇 프로세스 자동화(RPA) 를 하는 사람의 예
- 그는 자신이 훨씬 더 생산적이라고 강하게 주장함
- 그러나 실제로는 비효율적이고 신뢰성이 떨어져 다른 사람들이 그의 작업을 수정하느라 시간 낭비 발생
- 동료들은 그를 워크플로에서 배제하려고 함
- 사람들은 자신의 생산성을 제대로 측정하지 못하고, 특정한 성과나 손실만 잘 인식함:
-
눈에 띄는 성과에 집중
- 자동화된 방법으로 작업을 빠르게 완료하면 즉각적인 성취감이 큼
- 빠른 성과는 즉각적으로 눈에 보이기 때문에 긍정적인 효과로 인식됨
-
장기적인 비용은 인식하기 어려움
- 작업 이후 발생한 시간 비용은 쉽게 추적되지 않음
- 특히 문제가 다른 사람이 수정한 경우, 그 비용은 잘 보이지 않음
- 자동화된 작업에서 발생한 오류가 수정되더라도 그로 인한 시간 낭비는 느끼기 어려움
-
눈에 띄는 성과에 집중
- LLM 코드가 발생시키는 문제는 다음과 같은 이유로 인식하기 어려움:
- 버그 발생 시 원인이 LLM 코드임을 정확히 추적하기 어려움
- 문제를 수정하는 과정에서 다른 사람이 추가로 시간을 낭비할 수 있음
- 문제 발생의 근본 원인을 인지하지 못하고, 자신이 자동화 도구를 사용한 탓임을 깨닫지 못함
- "자동화 덕분에 빨리 끝냈다"는 성취감은 크지만, "자동화 때문에 낭비된 시간"은 체감하기 어려움
- LLM 사용이 보편화되었음에도 불구하고 산업 전반의 생산성 증가가 명확하게 보이지 않음
- 사람들이 "2배 더 생산적"이라고 주장하지만, 실제로는 숨겨진 문제로 인해 오히려 생산성이 저하되었을 가능성 높음
- 즉, 문제 해결에 소모된 시간과 자원이 눈에 보이지 않아 과장된 성과 인식 발생
저의 체험과 비슷한 느낌이네요.
- 간단하지만 외우기는 힘든 코드들(파일 입출력 처리, 컨테이너 다루기 등)을 작성할 때
- 컴파일, 런타임 오류가 생겼을 때 이게 어떤 에러고 어느 코드가 원인인지
- 이미 작성해둔 함수와 비슷하지만 조금 다른 기능을 넣은 함수를 재작성 하고 싶을 때
- 어떤 라이브러리에 의존하고 있는 코드를 다른 라이브러리로 교체하거나 자체 함수로 대체하고 싶을때
- 특정 기능을 구현하거나, 특정 환경에서 작업해야 할때 어떤 식으로 개발하면 될 지 가이드가 필요할 때
위와 같은 케이스에선 꽤 많은 시간이 단축되었습니다. 구글+스택오버플로우 조합으로는 잘 안 찾아지는 경우도 많고, 특히 스택오버플로우에선 어떤 답변이 있으면 댓글로 이의도 항상 많이 제기되고 옛날 버전의 구현방식이라 쓰면 안된다던지 그런 문제들이 있어서 짜증나는 경우가 참 많았는데...
대부분의 프로그래머는 LLM 도구를 효과적으로 사용하는 방법을 모르거나 관심이 없음
주변의 많은 개발자들이 의외로 기술에 관심이 없음. 그들은 새로운 혹은 반복되는 유튜브 쇼츠를 기계적으로 탐미하는데 대부분의 시간을 할애하고 있음.
Hacker News 의견
-
시애틀의 인기 있는 기술 회사에서 일하고 있으며, AI 사용이 강요되고 있음. 리더십이 개발자들이 AI를 얼마나 사용하는지 추적하고 있으며, 개인적으로 AI를 더 많이 사용하지 않는 이유를 묻기도 했음. 적절한 도구를 적절한 작업에 사용하는 것이 중요하다고 믿고 있으며, AI가 항상 적합한 것은 아님
- 많은 수석 이사와 SVP들이 10년 이상 전에 코드를 작성했으며, 간단한 프로젝트를 시작하는 방법을 모름. AI가 그들에게 잃어버린 무언가를 되찾아 주었지만, 전문가에게는 도움이 되지 않음
- AI는 취미로 정원을 가꾸는 사람에게는 도움이 되지만, 농부에게는 수확량을 늘리는 데 도움이 되지 않음
-
소프트웨어 프로젝트의 마지막 10%가 90%의 시간을 차지한다는 오래된 격언이 있음. AI는 처음 90%에서는 유용하지만, 마지막 10%에서는 도움이 되지 않음
- AI 사용이 신중하지 않으면 복잡한 코드로 인해 AI가 도움이 되지 않는 상황에 빠지기 쉬움
- 소프트웨어 생산성의 폭발적인 증가가 보이지 않는 이유 중 하나일 수 있음
-
FAANG에서 LLM을 IDE에 통합하여 사용하고 있으며, 약간의 긍정적인 효과가 있음
- IDE 내 생산성이 약간 향상되었으며, 반복적인 작업을 자동완성할 수 있음
- 그러나 LLM이 그럴듯한 결과를 생성하여 생산성 향상을 저해하기도 함
- 직접적으로 기능을 생성하도록 요청하면 더 나은 결과를 얻을 수 있을 것 같음
-
실제로 10배의 개선을 경험한 개발자의 예로 Pieter Levels가 3D 멀티플레이어 비행 시뮬레이터를 며칠 만에 코딩한 사례가 있음
- 간단한 작업에서 시간을 절약할 수 있지만, 복잡한 작업에서는 도움이 되지 않음
-
LLM을 사용하여 코드 생성을 시도했으나, 처음에는 생산성이 떨어졌음
- 최근에는 Claude Code를 사용하여 생산성이 크게 향상되었으며, 페어 프로그래밍 스타일로 작업하고 있음
- 비개발자가 고품질의 출력을 생성할 가능성은 낮다고 생각함
-
GitHub에서 Copilot Autofix를 개발하는 팀의 일원으로, CodeQL 경고를 기반으로 수정 제안을 제공함
- 실제 개발자와의 상호작용 데이터를 기반으로 평균 3배, 최대 12배의 속도 향상을 보임
-
LLM 코딩 도우미의 답변 품질은 프로그래머의 의사소통 능력에 크게 영향을 받음
- 주니어 개발자들이 질문을 명확하게 하지 못해 잘못된 답변을 받는 경우가 많음
- 시니어 프로그래머의 능력이 크게 향상되는 경우를 보았으며, 주니어나 중급 개발자가 LLM 코딩 도우미가 쓸모없다고 불평할 때는 그들의 의사소통 능력에 문제가 있을 가능성이 높음
-
소프트웨어의 생산성이 5-10배 향상되지 않았다는 가정은 잘못된 것일 수 있음
- 대안으로는 회사가 더 적은 엔지니어를 필요로 하여 해고를 하거나, 비용을 줄여 소프트웨어 제품이 더 저렴해지는 경우가 있음
- 개인적으로는 간단한 스크립트를 작성하여 하루에 조금 더 많은 일을 할 수 있게 되었지만, 5배 더 많은 일을 할 수 있는 것은 아님