LLM이 실제로 프로그래머의 생산성을 얼마나 향상시키고 있을까?

• 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의 전체적인 산업적 영향은 아직 제한적임
• Ajeya Cotra의 관련 발언 링크
  • 트윗 링크 1
  • 트윗 링크 2
• "장기적인 성과를 내려면 AGI가 필요하다"는 주장에 대해서는
  • 현재 AI의 발전 경로에는 일반적인 능력(Generality)이 예상보다 적음
  • AI의 성능이 특정 작업에서 급격히 향상되거나, 특정 영역에서 약점이 나타나는 경우가 많음
  • 이러한 성능의 불균형 때문에 AGI(인공 일반 지능)라는 개념이 예상보다 덜 유용할 수 있음

[yo-cuddles의 댓글]

• 내 사무실에서 로봇 프로세스 자동화(RPA) 를 하는 사람의 예
  • 그는 자신이 훨씬 더 생산적이라고 강하게 주장함
  • 그러나 실제로는 비효율적이고 신뢰성이 떨어져 다른 사람들이 그의 작업을 수정하느라 시간 낭비 발생
  • 동료들은 그를 워크플로에서 배제하려고 함
• 사람들은 자신의 생산성을 제대로 측정하지 못하고, 특정한 성과나 손실만 잘 인식함:
  • 눈에 띄는 성과에 집중
    • 자동화된 방법으로 작업을 빠르게 완료하면 즉각적인 성취감이 큼
    • 빠른 성과는 즉각적으로 눈에 보이기 때문에 긍정적인 효과로 인식됨
  • 장기적인 비용은 인식하기 어려움
    • 작업 이후 발생한 시간 비용은 쉽게 추적되지 않음
    • 특히 문제가 다른 사람이 수정한 경우, 그 비용은 잘 보이지 않음
    • 자동화된 작업에서 발생한 오류가 수정되더라도 그로 인한 시간 낭비는 느끼기 어려움
• LLM 코드가 발생시키는 문제는 다음과 같은 이유로 인식하기 어려움:
  • 버그 발생 시 원인이 LLM 코드임을 정확히 추적하기 어려움
  • 문제를 수정하는 과정에서 다른 사람이 추가로 시간을 낭비할 수 있음
  • 문제 발생의 근본 원인을 인지하지 못하고, 자신이 자동화 도구를 사용한 탓임을 깨닫지 못함
  • "자동화 덕분에 빨리 끝냈다"는 성취감은 크지만, "자동화 때문에 낭비된 시간"은 체감하기 어려움
• LLM 사용이 보편화되었음에도 불구하고 산업 전반의 생산성 증가가 명확하게 보이지 않음
  • 사람들이 "2배 더 생산적"이라고 주장하지만, 실제로는 숨겨진 문제로 인해 오히려 생산성이 저하되었을 가능성 높음
  • 즉, 문제 해결에 소모된 시간과 자원이 눈에 보이지 않아 과장된 성과 인식 발생