고숙련 작업에 대한 Gen AI의 영향: 소프트웨어 개발자와의 실험

요약

• 연구 개요
  • 이 연구는 Microsoft, Accenture, 그리고 익명의 Fortune 100 전자 제조 회사에서 실시된 세 가지 무작위 통제 실험을 통해 생성형 AI가 소프트웨어 개발자의 생산성에 미치는 영향을 평가함.
  • 실험은 각 회사의 일상 업무의 일환으로 진행되었으며, 무작위로 선택된 개발자들에게 GitHub Copilot이라는 AI 기반 코딩 도우미를 제공함.
  • 총 4,867명의 소프트웨어 개발자를 대상으로 한 이 연구는 AI 도구를 사용하는 개발자들의 완료된 작업 수가 26.08% 증가했음을 발견함 (표준 오차: 10.3%).
  • 특히, 경험이 적은 개발자들이 더 높은 채택률과 생산성 향상을 보였음.

GN⁺의 정리

• 이 연구는 생성형 AI가 소프트웨어 개발자의 생산성을 크게 향상시킬 수 있음을 보여줌.
• 경험이 적은 개발자들에게 특히 유용하며, 이는 AI 도구가 학습 곡선을 완화하는 데 도움이 될 수 있음을 시사함.
• GitHub Copilot과 같은 AI 도구는 소프트웨어 개발의 효율성을 높이는 데 중요한 역할을 할 수 있음.
• 비슷한 기능을 가진 다른 프로젝트로는 TabNine과 Kite 등이 있음.

[GN⁺]

Hacker News 의견들

• IT 인력의 질이 떨어지는 이유가 회사들이 인원 감축을 위해 한 사람에게 점점 더 많은 역할을 밀어 넣기 때문인지 가끔 궁금함
  예전에는 개발, 운영, 보안이 각각 전담 역할이었는데, DevOps를 만들자 일부 회사는 팀 통합이 아니라 인원을 2/3만 둬도 된다는 뜻으로 받아들였고, DevSecOps를 만들자 원래 역할의 1/3만 있어도 되며 개발자가 운영과 애플리케이션 보안까지 하면 된다고 여김
  shift-left나 통합 운영 모델 자체를 비판하는 건 아니고, 임원들이 인원 줄여 비용을 깎으면 보너스를 더 받을 수 있다고 생각할 때 이런 모델이 낳는 논리적 결과라는 뜻임
  이제 신입 개발자는 말도 안 되게 복잡한 n개 마이크로서비스 환경에 들어와 기존 코드베이스, 5개짜리 CI/CD 파이프라인, DBA 역할까지 배우면서 꾸준한 릴리스 주기도 맞춰야 함
  따라잡으려고 ChatGPT를 쓰는 게 정말 놀라운 일인가 싶고, IT 회사들이 좋은 사업 전략 대신 “선 올라가기”를 위해 인원을 줄이는 일을 멈추기 전까지 계속될 것임

  • 스타트업에서는 한 사람이 세 사람 몫을 할 수 있고 실제로도 자주 그렇게 함
    MBA들이 놓치는 건 과도한 제약 현상이라고 봄. “개발자”라는 일반 역할을 “개발, 운영, 보안”으로 쪼개면 각 역할을 어떻게 해야 하는지 온갖 세부사항이 생김. 다시 DevSecOps로 합치더라도 그 세부사항은 그대로 남아서, 한 사람이 3배 효율적으로 일하는 게 아니라 3배의 일을 떠안게 됨
    제대로 되돌리려면 제약을 완화하고, 그 한 사람이 일을 어떻게 할지 판단할 수 있게 해야 함
    이에 따른 결론은 조직 규모는 줄어들 수 없고 늘어나기만 한다는 것임. 직원이 늘수록 직무는 더 전문화되고, 그들을 없애면 그 기능이 그냥 수행되지 않게 됨. 그 수준의 전문화에서는 남은 직원들이 직무 기술서를 조금 바꿔 새 책임을 떠안기 어렵기 때문임
    결국 낡은 조직을 버리고 새롭고 작은 조직으로 다시 시작해야 하며, 사모펀드/벤처캐피털/스타트업 생태계가 존재하는 이유도 여기에 있음. Gall의 법칙도 같은 맥락임: https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law
  • IT 인력의 질 저하는 돈을 많이 벌 수 있어서 소프트웨어 업계에 들어온 세대와 전적으로 관련 있다고 봄. 이해는 되지만, 소프트웨어에 대한 열정보다 보상이 동기인 경우가 많고, 대체로 기술적으로 평범한 사람들이며 또 다른 평범한 기술자를 채용하는 경향이 있음
    반면 요즘 생겨나는 신생 스타트업을 보면 정말 재능 있는 사람들이 점점 더 많아짐. 자금이 더 빡빡한 환경에서는 회사를 시작하려면 진짜 실력자가 더 필요하고, 그런 사람들이 또 뛰어난 사람을 뽑기 때문이라고 봄
    지금의 기술 업계는 스타트업에 관심 있던 거의 모두가 기술 문제를 해킹하는 걸 좋아해서 뛰어들던 2004~2008년 무렵과 훨씬 더 비슷하게 느껴짐
    Cursor를 써 본 경험상, 평범한 엔지니어가 할 수 있는 일에는 훌륭하지만 그보다 고급 작업에는 형편없고, 남의 코드를 매우 빠르게 이해하는 능력도 필요함
    아마 프론트엔드나 웹 앱 개발에 집중하지 않는 고급 기술 엔지니어들이 주니어 웹 개발자를 예전만큼 많이 뽑지 않아도 되게 만들 것 같음. 웹페이지용 기본 HTML/CSS를 빠르게 만드는 프레임워크와 도구가 생기자 웹마스터가 사라진 것과 비슷함
  • 이 현상은 IT 노동자에게만 일어나는 게 아니라 전반적으로 벌어지고 있고, 기술이 약속했던 생산성 향상이 현실화되지 않은 주요 이유라고 봄
    “DevSecOps” 인력이 해야 할 일의 3배를 하고 있다고 해보면, 그들이 또 무엇을 하는지도 봐야 함. 출장 예약, 비용 정산과 보고, 업무 시간을 사업 분류별로 나눠 보고, 휴가 관리, 회의 관리, 직접 만든 그래픽으로 발표자료 작성, 외부 업체 구매 준비의 80%까지 할 수도 있음
    이런 일들은 직무 기술서에 없고, 실제 업무를 방해하며 본업 수행 능력을 불균형하게 갉아먹음. 예전에는 이런 일마다 전담 전문가가 있었고, 훨씬 싸게 10배 효율로 처리할 수 있었음
    비서, 내부 그래픽 부서, 재무 인력 같은 전문가들은 재무제표에 보였음. 그 역할을 없앤다고 일이 사라지는 건 아니고, 셀프서비스 사무 소프트웨어가 “생산성”을 개선한다는 명목 아래 모두에게 조각조각 분산될 뿐임
    그 결과 모두가 불균형하게 느려지지만, 숫자만 보는 사람들은 없앤 역할의 급여에서 절약된 돈만 봄. 느려짐은 흐릿하고 일반적인 생산성 저하감, 모두가 겪는 신비한 비용 질병처럼만 나타남
    신비한 게 아니라 생산성 증가는 없고 오히려 손실이 생긴다고 봄. 다만 명확하고 드러나는 비용을 분산되고 계산하기 어려운 비용으로 바꾸기 때문에, 돈을 아끼고 있다고 착각하기 쉬움
  • 회사들은 10배 개발자가 존재한다는 건 깨닫고 있지만, 그들을 1배 개발자 급여로 고용할 수 있다고 생각함
    빠뜨린 핵심 역량은 회사가 속한 사업을 이해하는 능력임. 적당한 개발 능력이라도 사업 목표에 대한 좋은 이해와 결합하면, 순수 개발자 일부가 AI로 대체되는 와중에도 계속 유효할 수 있음
  • 이건 멈추지 않을 것임. 실제 권력을 가진 전형적인 최고위 임원들은 IT 복잡성에 대해 전혀 모르고, 우리를 비싼 청소부 정도로 봄. 그들의 잘못이지만, 그 실수가 완전히 드러날 때쯤이면 대개 이미 떠난 뒤일 가능성이 큼
    은행권 회사에서 13년 동안 복잡성이 크게 늘고, 말도 안 되는 관료주의도 같이 증가하는 걸 봄. 아직도 필요한 작업을 할 수는 있지만 접근 권한이 없음. 가질 수도 없음
    단순 작업이 이제는 정체불명의 Pune 팀과 10단계 협상을 해야 하는 일이 됐고, 그들이 실제로 할 일이 있음을 인식할 때까지 10번 쫓아다니고 에스컬레이션해야 함
    프로세스는 터무니없어져서 뭔가 시작하면 2일 걸릴지 3개월 걸릴지 모름. 모든 앱은 새 네트워크 작업, 검증 안 된 Unix 업데이트, 혹은 발생할 수밖에 없는 수많은 일 중 하나 때문에 지속적으로 유지보수하지 않으면 꽤 빨리 망가짐
    결국 서류 처리자들과 본업도 평균 수준인 사람들이 프로세스에 깊숙이 자리 잡고 이겼고, 사업부는 수준 낮은 IT를 제공받으며 프로젝트는 지연되고 예산도 초과됨. 이게 “형편없지만 참아야 하는 악”인 IT 이미지를 더 굳힘
    이제 신경을 끊었고, 일은 삶을 위한 수단이면 충분함. 내 초점과 성취는 그 “삶” 쪽에 있음

• 무엇을 측정하느냐가 중요함. 이 연구는 Copilot 사용량만 봤음
  나는 경험 많은 엔지니어인데, Copilot은 내겐 쓸모없다 못해 방해됨. 대부분의 시간은 문제 영역을 이해하고, 내가 있는 환경의 제약과 가능성을 파악하고, 작성할 코드를 생각하는 데 씀
  실제로 코드를 치기 시작할 때는 무엇을 쓸지 이미 알고 있어서, “도와주는” Copilot 자동완성은 그냥 산만하게 만들 뿐임. 내 작업 흐름을 훨씬 더 나쁘게 함
  반대로 실제 코딩 전 단계들에는 AI가 엄청나게 유용함. 때로는 미리 해둔 사고를 바탕으로 잘 만든 프롬프트만으로 초안을 얻을 수 있고, 이후에는 생기는 작은 예상 밖 문제들에 빠르게 답을 얻기 위해 LLM과 짝을 이루는 게 매우 도움이 됨
  그래서 이 보고서와 달리, 숙련 개발자가 AI를 잘 쓰면 미숙한 개발자보다 더 큰 이득을 볼 수도 있다고 생각함

  • Copilot은 특별히 유용하지 않음. 잘해야 맞을 수도 틀릴 수도 있는 작은 코드 조각을 내놓고, 더 큰 코드 덩어리가 처음부터 동작하는 경우는 드묾
    하지만 Claude Sonnet 3.5를 Cursor나 Continue.dev와 함께 쓰면 극적으로 좋아짐. 맥락을 명시적으로 제어할 수 있고, 예를 들어 6~7개 파일을 선택해 주입할 수 있으며, Claude의 우수한 능력까지 더해지면 완전히 판이 바뀜
    작업에 따라 쉽게 2~5배 빨라짐. 원래 반나절 걸릴 수 있는 일을 한 시간 안에 테스트까지 갖춘 100줄짜리 프로덕션 준비 코드로 만들 수 있음
    26년 경력이고 2012년부터 principal/staff/lead 역할을 해온 입장에서 하는 말임. 다만 시니어 미만 경험에서는 같은 향상을 기대하지 않음. 실제로 원하는 바를 꽤 상세히 설명해야 하고, 보통 동작하는 초기 해법을 받아서 여섯 번쯤 다듬어 이상적이고 잘 분해된 형태로 만들어야 하기 때문임
  • 내게 AI는 문서와 검색 능력을 가속하는 도구 같음. 무엇을 하고 싶은지는 정확히 아는데 문법이나 사용법이 기억나지 않는 작은 일이 많음
    예를 들어 AWS용 IaC를 작성할 때는 찾아볼 게 많음. AI에 물으면 답과 예제를 매우 빠르게 얻음. 새 서비스의 IaC를 배우는 중이면 AWS 문서를 보겠지만, 빠른 답이나 복습만 필요할 때는 AI가 훨씬 빠름
  • 반대 관점으로는, Copilot은 나중에 메서드 시그니처만 보고 함수 전체를 작성할 수 있게 해주는 패턴 작성을 보상한다고 느낌
    함수형 패턴에 더 기댈수록, 모나드를 설계하고 입출력은 경계에서만 하고 fluent programming을 쓰면 효과가 매우 큼
    참고로 이건 Java에서의 경험임. Java를 쓴 지 3.5년 됐고 Java 8+ 기능에 크게 의존함. 라이브러리 코드에서 제네릭을 많이 쓰면 LLM이 일관되게 올바른 선택을 할 여지가 커짐
    더 빠르고 대충 만든 설계에서는 이런 이득을 그만큼 못 봄. Haskell, OCaml, F#, Scala 같은 진짜 함수형 프로그래밍 사용자들의 이야기를 더 듣고 싶음
  • Copilot 체험판을 써봤는데, 무슨 결과를 내놓을지 기다리고 분석한 뒤 대부분 버리고 내 구현으로 다시 만들게 됨. 금방 시간 낭비라는 걸 깨달음
    단위 테스트, 특히 테이블 기반 테스트의 상용구 작성에는 쓸모가 있었지만, 유료 구독을 유지할 만큼은 아니었음
  • 내 경험도 비슷함. 직장에서 접근 권한은 있지만, 집중에 너무 시끄러워져서 최근에는 꺼뒀음
    익숙하지 않은 언어로 작업하거나, 생성된 코드가 괜찮은지 쉽게 판단할 수 있는 반복 작업에서는 매우 가치 있었음
    반대로 내가 하고 싶은 것이 아주 명확하고 표준 구현과 비슷하지만 조금 더 새로운 작업일 때 약해짐. “reduce”나 더 모호한 절차에서 이런 일이 자주 일어남
    플랫폼 엔지니어라 Bash, Python, 브라우저, 순수 JS, TS, Node, GitHub Actions, Jenkins Java 워크플로, Docker 등 여러 공간을 오가는데, 영역을 전환할 때 뇌를 쉬게 해주고 몸을 푸는 데는 도움이 됨

• 연구에, 경험 적은 개발자들이 AI로 기여한 뒤 더 경험 많은 개발자들이 처리해야 했던 기술 부채가 포함됐는지 궁금함. 연구에 나온 회사 중 하나에서 개인적으로 그런 일을 많이 겪었기 때문임
  또 기술 자체에는 관심이 적지만 전달에는 큰 관심이 있는 개발자들이 AI에 더 큰 흥미를 보이는 걸 직접 봤음. PM들은 그런 사람들을 좋아하지만

  • 나도 궁금함. 이제 여러 PR에서, 메서드가 명백히 AI에 의해 아무 좋은 이유 없이 완전히 수정된 걸 리뷰해야 했음. 왜 바꿨냐고 물으면 말 그대로 침묵하고, 질문을 무시한 채 우리가 처음 요청했던 일만 설명하려 함. PR 안에 실제로 무엇이 들어 있는지 모르는 게 분명했음
    우리가 요청한 건 5줄 정도의 작은 변경과 테스트였음. 그런데 이제 새 부채뿐 아니라 왜 완전히 바뀌었는지 아무도 설명할 수 없는 코드, 그중 일부는 바꾸기 위한 변경에 불과한 코드, 그리고 이 코드를 관리하는 사람들이 보기에 완전히 낯선 코드까지 떠안게 됨
    이런 도구를 쓰는 사람들 중 고급 엔지니어가 아닌 경우에 계속 봄. 결국 그런 PR은 거절하고 다시 하라고 말하게 됐고, 처음에 얻었다고 여긴 시간 이득은 사라짐
    이런 도구가 쓸모없다는 뜻은 아니지만, 사람들은 출력물이 무엇인지 이해하지 못한 채 쓰고 있고, 코드베이스에 미칠 장기적 영향도 이해하지 못함
  • “기술에는 별 관심이 없지만 전달에는 관심이 큰 개발자들이 AI에 더 관심을 보인다”는 표현이 내가 설명하려고 애쓰던 걸 정확히 말해줌
    내 영혼 일부를 잃은 날은 어떤 개발자에게 DB 스키마 피드백을 줘도 되냐고 물었고, 그가 된다고 한 뒤 몇 분 지나 “네, 저는 X에는 별로 관심 없어요”라며 끊었을 때였음
    관심이 없다고? 해당 분야 전문가로서 무엇을 개선할 수 있고 어떻게 해야 하며 왜 해야 하는지 말해주고 있는데 관심이 없다니
    클라우드는 실수였음. 언제든 scale up/out 할 수 있으니 효율성과 최적화를 추구할 필요가 없다는 생각을 사람들에게 심었음. 마이크로벤치마크를 말하는 것도 아니고, “이 자료구조 대신 저 자료구조를 쓰는 게 낫지 않을까” 같은 아주 단순한 얘기임
  • 코딩 AI를 파는 회사에서 일한다는 전제를 밝힘
    내부에서도 쓰고 있는데, 기술 부채는 제대로 가늠되지 않은 거대한 위협이라고 봄
    익숙하지 않은 API와 패턴을 코드에 융단폭격하듯 적용하는 데는 매우 유용하지만, 조심하지 않으면 엄청난 코드 중복과 다루기 힘든 상용구를 낳음
    이유는 두 가지 큰 편향 때문임. 첫째, 모델의 학습 데이터가 StackOverflow식 예제 데이터라 맥락과 제약을 고려하지 않음. 둘째, 기존 코드베이스를 보고 리팩터링을 제안하기보다 복사하고 반복하는 경향이 있음
    첫 번째는 결국 자기 일을 해서 LLM이 뱉은 것을 리뷰하고 편집하면 완화됨
    두 번째는 diff와 커밋 이력이 학습 데이터에 들어가야 완화될 수 있는데, 이 데이터셋은 다루고 태깅하기가 훨씬 어려움. 어떤 변경은 리팩터링처럼 좋지만, 어떤 변경은 이후 커밋에서 고쳐지는 버그일 수 있고, 커밋 메시지는 사실상 거짓말이라 명확한 구분도 없음. 아무도 “버그 도입”이라고 쓰지 않음
    게다가 merge, rebase, squash가 이력의 의미를 바꾸거나 제거하거나 잡음을 더해 모든 것을 더 흐릿하게 만듦
  • AI를 좋아하는 개발자들 중 내가 아는 거의 모두는 AI 이전에도 기술적으로 별로 존중하지 않던 개발자들이었음. 일을 어느 정도 끝내긴 했지만 장인정신이나 품질이 없었음
  • 나도 그렇게 느꼈지만 반대도 봤음. 여기 HN에서도 기술에 관심 있는 사람들이 AI 사용에 거의 거부감을 보이는 경우가 있음
    나는 기술을 좋아하고 재미로 소프트웨어도 쓰지만, AI와 함께하는 쪽이 객관적으로 더 재미있음. 생산성이 훨씬 더 올라가고, 무엇보다 미루기가 사라짐
    막히거나 일을 시작하기 싫을 때 Aider와 대화하기 시작하면 어느새 그날 AI 없이는 하지 않았을 작업 하나가 끝나 있음
    덕분에 예전에는 몇 달에서 몇 년 걸리던 공개/비공개 프로젝트를 이제는 2주마다 내놓음. 빠르고 경험 많은 개발자 팀이 옆에 앉아 있는 비용이 하루 최대 몇 달러임

• 결론을 집기 전에 논문을 조금 더 깊게 볼 필요가 있음. 연구 자체도 결과 요약을 더 잘할 수 있었을 것 같음
  초록과 결론은 결과로 생산성 26.08% 증가라는 하나의 비율만 제시하는데, 소수점이 너무 많은 듯함. 조금 더 들어가면 주니어는 27~39%, 시니어는 8~13%라는 수치가 나옴
  더 깊이 보면 경력뿐 아니라 회사별 편차도 큼. Microsoft에서는 풀 리퀘스트 외에 커밋, 빌드, 빌드 성공률 같은 다른 결과 지표가 통계적으로 유의미하지 않은 것으로 보임. PR 증가도 Microsoft에서는 유의미해 보이지만 Accenture에서는 아닌 듯하고, 그마저도 주니어에게만 그럴 수 있음
  초록과 결론은 요약해야 하지만, 변수에 따라 결과가 너무 달라서 단일 전체 숫자를 요약으로 주는 게 말이 되는지 모르겠음. 특히 통계적 유의성이 들쭉날쭉해 보이기 때문임

  • 이 결과가 어떻게 나왔는지 더 잘 보려면 이렇게 봐야 함. Microsoft는 자사 내부 제품 사용 연구를 했고 효능을 보여주고 싶었음. 결과는 기대만큼 폭넓게 성공적이지 않았음
    Accenture는 Microsoft 같은 대형 조직과 협력하고 공동 마케팅하는 회사임. 약 300명 개발자 풀은 전체 표본을 거의 움직이지 못하고, AI 워크플로를 둘러싼 마케팅/컨설팅 부서를 만들고 있으니 객관적이라고 가정하기도 어려움
    세 번째 익명 회사는 실제로 무작위 대조 실험이 아니었으므로, 그 결과를 RCT들과 어떻게 합쳐야 할지 말하기 어려움. 또한 대형 기술 회사들 중 비슷한 실험을 하고 효능을 알고 싶어 한 곳이 더 있었을 것이므로, 결과에 포함된 것 말고도 다른 데이터가 있다고 가정할 수 있음
    왜 더 큰 표본 집합 중 이 회사들을 골랐을까? 아마 Microsoft와 Accenture는 도입에 인센티브가 있고, 세 번째 회사는 p-hacking으로 골랐기 때문일 것임
    특히 초록의 “각 개별 실험은 잡음이 있지만, 세 실험을 합치면”이라는 문장은 매우 나쁜 신호임. 각 회사만 보면 통계적으로 유의미한 결과가 없지만, 이 세 집단을 합치면 유의미해진다는 사실상의 인정임. 이건 과학이 아님
  • 26.08%라는 수치에 대해, 물리학 같은 분야가 아닌 연구에서 소수점 둘째 자리까지 제시하면 바로 의심하게 됨
  • 개인적으로는 차이의 일부가 시니어 개발자들이 생성된 코드에 대해 코드 리뷰와 테스트 경험을 적용하기 때문이라고 느낌. 그래서 변경을 요구하고, 나쁜 생성을 거부하고, 새 코드나 리팩터링이 기대대로 동작하는지 테스트를 구현하느라 더 많은 시간을 씀
    주니어 개발자는 LLM이 맞히기 쉬운 작업을 하거나, 첫 초안이 LGTM처럼 보인다는 이유로 받아들이는 실수를 해서 처리량이 더 높게 보일 수 있음
    생성 코드 모델을 쓰는 데도 기술이 필요하고, 그 기술은 다른 사람에게 일을 위임하고 여러 작성자의 해법을 하나의 응집된 시스템으로 통합할 때 필요한 기술과 같음

• 내 직감일 뿐이지만, LLM 보조 코딩은 개발자로 성장하는 데 해롭다고 봄. 생산성을 일정 수준까지만 끌어올릴 수 있을 것 같은데, 그 수준은 시니어에게는 지루한 반복일 수 있지만 주니어에게는 형성 과정임
  내 경험상 LLM은 단순한 상용구 코드에만 쓰이는 게 아니라, 주니어 개발자가 아직 충분히 이해하지 못한 꽤 흔한 작업을 마주했을 때 호출됨. 실험하고 배우고 이해하는 과정이 대체로 LLM으로 대체되고, 진짜 기술은 작동하는 것처럼 보일 때까지 프롬프트를 조정하는 일이 됨

  • 나에게는 믿기 어려울 정도로 좋은 학습 도구임. 채팅 도구를 쓰면 더 넓고 깊게 배움. 주제를 탐색하고 추가 자료를 찾는 데 훌륭한 대화 상대가 됨
    어젯밤 처음으로 Linux RAID를 설정했음. 아주 어려운 일은 아니지만, mount, umount, fstab, blkid, mdadm, fdisk, lsblk, mkfs 등 여러 도구가 필요하고 도중에 가이드의 정확한 단계와 다르게 흘러갈 수 있어서 튜토리얼이나 문서만 보는 게 특히 도움이 되진 않음
    각 도구와 단계에 대해 수십 가지 질문을 했고, 예전 같으면 그냥 복사해서 붙여넣고 기도했을 것임
    이틀 전에는 고장 난 SSD에서 모든 데이터를 복구하는 것도 ChatGPT를 통해 배우며 해냈음. 20%는 틀릴 수 있어도, 열린 인터넷 평균보다 훨씬 나은 “가이드”가 있는 상태로 완전히 새로운 기술을 다루는 게 정말 좋았음
    배우는 걸 좋아하는 사람에게는 인터넷 쓰레기를 끝없이 뒤지는 것에 비해 천 리 장화 같은 느낌임. 물론 인터넷의 다른 모든 것처럼 AI가 말하는 것도 의심해야 하지만, 번거로움을 엄청나게 줄여줌
  • 이 연구가 그런 부분을 다뤄주길 정말 바랐음. 실제로는 단기 생산성 향상만 보고, 장기 기술 부채는 무시하며, 소프트웨어 개발자 성장에 미치는 영향은 완전히 무시함
    나도 같은 직감을 갖고 있고, 더 나아가 근거 있는 강한 의견이라고 부르고 싶음. 몇 년 뒤 업계가 대가를 치를 것이라고 봄
    “감이 있는 주니어 소프트웨어 개발자” 공급 파이프라인이 크게 말라붙고, “AI 의존 주니어 소프트웨어 개발자”의 홍수로 대체될 것임. 두 범주 사이에는 깊은 협곡이 있음
    당연히 이는 감이 있는 중급 개발자, 감이 있는 시니어 개발자 수에도 연쇄 영향을 줌
  • 사용자에 따라 정말 다르다고 봄. 예전에도 StackOverflow 코드를 작동하는 것처럼 보일 때까지 붙여넣고 끝내던 사람들은 LLM도 남용할 것임
    반면 자기가 쓰는 코드를 전부 이해하고 싶어 하는 사람은 LLM이 뱉은 것 중 모르는 부분을 조사할 가능성이 큼
    적어도 나는 그렇게 씀. 그리고 가설에 반례를 들자면, LLM이 내가 몰랐던 함수나 라이브러리 구성요소를 쓰는 경우가 있어서 새 언어나 도구키트를 배울 때 시간을 많이 절약해줌. 내게는 학습을 늦추기보다 가속함
  • 다른 것들과 마찬가지로 남용될 수 있음. StackOverflow에서 복사해 붙여넣다 작동하면 끝내는 식과 같음
    하지만 어차피 성공할 사람들에게는 StackOverflow 질문을 던지고 즉각적이고 비난 없는 답을 받는 것과 같아서 정말 큰 선물임
    항상 맞지는 않겠지만 StackOverflow도 그랬음. 결국 늘 그렇듯 개인에게 달려 있음
  • 지난 2년간 LLM이 보여준 발전을 보면, 정말 깊이 파고들고 싶지 않다는 선택이 나쁜 베팅일까 싶음
    50년 전에는 뭔가를 만들려면 사실상 필수였던 기계어를 지금의 개발자 중 얼마나 쓸 줄 알까
    LLM이 또 하나의 추상화 목발에서 견고한 추상화 기둥으로 바뀌는 것일 수도 있음

• 이 연구에서 가장 흥미로운 점은 경력 수준으로 나눴을 때, 재직 기간이 중앙값보다 높은 개발자는 “생산성”이라는 좋지 않은 대리지표에서 통계적으로 유의미한 증가가 없다는 것임. 95% 신뢰구간은 모든 지표에서 음수 쪽으로 깊게 내려가기도 하고, 다만 약간 양수 쪽으로 기울 뿐임
  내 경험과도 맞음. Copilot은 일부 지루한 일을 줄여주고 뇌를 더 깊은 질문에 쓰게 해주는 면에서는 좋지만, 주니어 개발자들이 말하는 것처럼 세상을 바꾸는 수준은 아님
  또 자주 미묘하게 틀리는데, 경험 적은 개발자는 놓칠 만한 방식임. 나는 생성한 대부분을 멈춰서 조정해야 하고, 덜 숙련된 개발자는 그런 조정을 어떻게 해야 할지 모를 가능성이 큼
  몇 년 써보니 이제는 Copilot을 언제 쓰고 언제 쓰지 말아야 할지 꽤 감이 생겼고, 그래서 순효과는 플러스일 것 같지만 항상 그랬던 건 아님
  또한 시니어 개발자의 “생산성”이 줄어든 것처럼 보이는 이유 중 일부가 회사 내 주니어들의 생산성 증가 때문인지도 궁금함. 주니어가 더 많은 PR을 만들고 거기에 실수가 더 많아 리뷰 시간이 늘면, 시니어의 생산성 향상은 비례해서 줄어들 수 있음

• 26% 생산성 증가는 내 경험과도 대체로 맞음. 더 살펴볼 차원은 새 기술을 다루는지, 이미 익숙한 기술을 다루는지라고 봄. AI는 내가 배우려는 언어나 프레임워크에서 훨씬 더 도움이 됨

  • “제대로 배울 생각이 없는 언어/프레임워크”까지 확장하고 싶음
    Bash에서 조건문을 쓰려면 정확히 어떤 따옴표 주문이 필요한지 같은 보조 언어의 특이점과 함정을 잘 기억하지 못함. 그래서 과거에는 자동화를 위한 Bash 스크립트를 거의 쓰지 않았고, 충분히 자주 하는 작업일 때만 노력했음. jq로 JSON 처리하거나 AWK로 파싱하는 것도 마찬가지였음
    이제 LLM 덕분에 Bash 스크립트를 훨씬 많이 만들고, 너무 쉬워져서 프로세스 문서화에도 더 자주 씀. 예전에는 정적인 단계별 README였던 것이 이제는 사용자 입력을 받는 대화형 Bash 스크립트와 함께 제공됨
  • Copilot은 지루함을 줄이는 데 꽤 괜찮음. 예를 들어 docstring은 대체로 잘 써줌. 하지만 소프트웨어 엔지니어링의 실제 정신적 노동을 덜어주지는 못함
  • 그럴 수도 있음. 커리어 단계별로 사람이 얼마나 유연한지의 결과일 수도 있음
    대체로 시니어 프로그래머들이 왜 AI 도구가 작동하지 않는지 논하는 걸 많이 봄. 주니어는 편견 없이 그냥 씀
  • 주력 제품 개발에서는 그다지 유용하지 않았음. Python 기반이긴 하지만 자체 프레임워크를 쓰기 때문에 CoPilot이 참고할 코드가 별로 없고, 존재하지 않는 메서드와 인자를 제안해 오히려 일이 늘어남
    유용한 곳은 네 가지였음. 첫째, Qt나 CSS처럼 내가 자주 쓰지 않지만 예제 콘텐츠가 많은 프레임워크/언어에 대한 질문
    둘째, 원래 Google Search나 StackOverflow에서 찾았을 매우 구체적인 질문. 예를 들어 “Python으로 Windows의 CPU와 RAM 사용량을 가장 효율적으로 얻는 방법” 같은 질문에서는 복붙할 코드를 바로 만들기보다 라이브러리나 예제를 가리켜줌
    셋째, 이미 쓸 줄 알지만 시간이 조금 절약되고 타이핑 오류를 줄이는 상용구 코드. PyCharm용 CoPilot 플러그인을 쓰면서 파일에 주석으로 의도를 쓰면 다음 몇 줄을 완성해줌. 역시 매우 짧고 구체적일 때 결과가 가장 좋음. 길어지면 CoPilot과 너무 많이 반복해야 해서 더는 가치가 없어짐
    넷째, 문서를 빠르게 검색하는 방법
    단위 테스트 작성에 좋다는 사람도 있지만 나는 그렇지 않았음. 적어도 내가 원하는 종류의 단위 테스트는 아니었음
    수치화하자면 생산성이 5~10% 오르는 정도라고 봄. Notepad 대신 PyCharm 같은 완전한 IDE를 쓰거나, CLI에서 git 명령을 직접 치는 대신 좋은 git 클라이언트를 쓰는 것보다 훨씬 작음. 즉 여러 생산성 도구 중 하나일 뿐, “혁명적”이라고는 말하지 않겠음
  • 나도 비슷한 인상임
    거대한 Ruby on Rails 프로젝트에서 약 10일 동안 Cursor를 써봤고, 이 스택은 13년 넘게 써왔음
    GitHub Copilot이 이미 주던 생산성 향상 이상은 얻지 못했음. Copilot의 향상은 대략 25% 정도로 추정함
    하지만 빈 폴더에서 Node.js 같은 새 프로젝트를 처음 만드는 경우는 기이할 정도로 강력함. 프롬프트만으로 OpenAPI 스키마에서 요청을 처리하고 swagger로 OpenAPI 스키마를 제공하는 API를 약 5분 만에 만들 수 있음
    다만 새 프로젝트를 처음부터 시작하는 일은 나에게는 드물기 때문에, 아마 Copilot과 기본 VSCode로 돌아갈 듯함

• 사람들이 PR을 더 많이 만들 수 있게 해줌. 와, 대단하네. 누가 신경 쓰나
  QA를 통과하는 항목 수가 늘어나는가? AI 보조로 만든 것들은 QA 이후에 발견되는 버그가 더 적은가? 나중에 확장하거나 수정하기 쉬운가, 아니면 경직되고 유연하지 않은 설계인가?
  개발자를 품질을 알 수 없는 코드 원숭이로 바꾸는 도구는 내가 찾는 게 아님. 개발자가 자신이 하는 일의 버그나 설계 결함을 찾도록 돕는 도구, 혹은 잘 설계된 테스트를 작성하게 해주는 도구를 원함
  PR 수만 세는 건 아무 유용한 것도 말해주지 않음. 오히려 단위 시간당 코드가 많아지면 평균 품질이 낮아진다는 내 직감을 건드림

  • 개발자: “Copilot, 이 커밋을 5개의 커밋으로 나눠줘”
    Copilot: “좋아요, 해드릴게요! 새 커밋들입니다!”
    시니어 개발자: “왜요? 변경은 원자적이에요. 경영진이 월간 변경 건수 같은 멍청한 지표를 다시 꺼내면, 예의 있게 꺼지라고 말해줄게요”

• 이건 아마 GPT-3.5 기반 Copilot이었을 가능성이 큼
  Microsoft: 2022년 9월~2023년 5월 3일
  Accenture: 2023년 7월~2023년 12월
  익명 회사: 2023년 10월~?
  Copilot Chat의 GPT-4 업데이트는 2023년 11월 30일이었음: https://github.blog/changelog/label/copilot/

  • 좋은 포인트임. Cursor 같은 것들이나 Claude를 그냥 바로 썼을 때 결과가 어땠을지 매우 궁금함. 이제 Claude로 간단한 작은 스크립트를 정말 쉽게 시작할 수 있다는 점에 놀라고 있음

• 내게 AI는 문서화를 되살려줬음. 새 프레임워크들은 문서가 너무 부족함. 내게 마지막으로 좋았던 문서는 DOS 책이었음. 요즘 개발자들은 좋은 문서가 어떤 것인지 감도 없을 것 같음
  그래도 AI는 매번 다른 제안을 할 수 있으니 판단은 여전히 경험 많은 개발자가 해야 함. 결국 AI는 문서와 타이핑을 대체함

  • AI는 문서의 가치를 더 높였다고 봄
    공개 프로젝트라면 문서가 LLM의 학습 데이터 일부가 되었으므로, 문서가 철저하고 정확한 것이 훨씬 더 중요해졌음. 많은 개발자가 그 시스템에서 답을 얻을 것이기 때문임
    비공개 프로젝트라면 문서를 fine-tuning 데이터셋이나 RAG 시스템에 넣어 같은 효과를 얻을 수 있음
  • 가끔 HN에 “내부 문서를 어떻게 관리하나” 같은 토론이 올라오면, 대부분 “문서는 금방 낡으니 쓸 의미가 없다”는 식으로 씀. 최근 며칠 사이에도 그런 스레드가 두 개 있었음
    아무것도 문서화되지 않는 이유를 설명해줄 수도 있음
  • 맞음. AI는 문서 작성을 도울 수도 있고, 문서부터 시작하면 더 좋아짐. 예를 들어 함수가 무엇을 하는지 설명하는 주석을 먼저 쓰면, AI가 함수를 작성하는 데 몇 자릿수 더 잘 도와줌
    그래서 실제로 개발자에게 코드를 더 잘 문서화하도록 강제하는 효과도 있음
  • 좋은 문서를 쓰는 걸 정말 좋아함. 물론 항상 그럴 기회가 있는 건 아니지만, 훌륭하다고 보는 문서를 하나 알려줄 수 있을까
    꼭 현대적인 라이브 문서일 필요는 없고 무엇이든 괜찮음. 과거에 무엇이 그렇게 훌륭했는데 우리가 잃어버렸는지 보고, 일부를 내 문서에 반영해보고 싶음