▲

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

 (lesswrong.com)
26P by GN⁺ 6달전 | ★ favorite | 댓글 6개
  • 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의 관련 발언 링크
  • "장기적인 성과를 내려면 AGI가 필요하다"는 주장에 대해서는
    • 현재 AI의 발전 경로에는 일반적인 능력(Generality)이 예상보다 적음
    • AI의 성능이 특정 작업에서 급격히 향상되거나, 특정 영역에서 약점이 나타나는 경우가 많음
    • 이러한 성능의 불균형 때문에 AGI(인공 일반 지능)라는 개념이 예상보다 덜 유용할 수 있음

[yo-cuddles의 댓글]

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

저의 체험과 비슷한 느낌이네요.

  • 간단하지만 외우기는 힘든 코드들(파일 입출력 처리, 컨테이너 다루기 등)을 작성할 때
  • 컴파일, 런타임 오류가 생겼을 때 이게 어떤 에러고 어느 코드가 원인인지
  • 이미 작성해둔 함수와 비슷하지만 조금 다른 기능을 넣은 함수를 재작성 하고 싶을 때
  • 어떤 라이브러리에 의존하고 있는 코드를 다른 라이브러리로 교체하거나 자체 함수로 대체하고 싶을때
  • 특정 기능을 구현하거나, 특정 환경에서 작업해야 할때 어떤 식으로 개발하면 될 지 가이드가 필요할 때

위와 같은 케이스에선 꽤 많은 시간이 단축되었습니다. 구글+스택오버플로우 조합으로는 잘 안 찾아지는 경우도 많고, 특히 스택오버플로우에선 어떤 답변이 있으면 댓글로 이의도 항상 많이 제기되고 옛날 버전의 구현방식이라 쓰면 안된다던지 그런 문제들이 있어서 짜증나는 경우가 참 많았는데...

답변달기
▲
superego 6달전  [-]

10x 생산성은 프로토타이핑할때 나오는거 같습니다

답변달기
▲
hilft 6달전  [-]

저는 달달하네요.

답변달기
▲
GN⁺ 6달전  [-]
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배 더 많은 일을 할 수 있는 것은 아님
답변달기
▲
ignos 6달전  [-]

Hacker News 의견 요약 번역 마지막 항목인 '소프트웨어의 생산성이 5-10배 향상되지 않았다는 가정은 잘못된 것일 수 있음'은 오역인 듯 합니다. 원문을 보면 '소프트웨어의 생산성이 5-10배 향상되었다고 하는 건 생산성 향상에 대한 잘못된 가정에 기반한 것임' 정도가 더 무난한 요약일 듯 싶네요.

답변달기
▲
halfenif 6달전  [-]

대부분의 프로그래머는 LLM 도구를 효과적으로 사용하는 방법을 모르거나 관심이 없음

주변의 많은 개발자들이 의외로 기술에 관심이 없음. 그들은 새로운 혹은 반복되는 유튜브 쇼츠를 기계적으로 탐미하는데 대부분의 시간을 할애하고 있음.

답변달기