AI 코딩 주장의 허상, 왜 '삽질웨어' 폭증은 나타나지 않는가

• 최근 AI 코딩 도구의 생산성 증대 주장에 대해 데이터로 확인한 결과, 실제로는 속도나 결과물이 눈에 띄게 증가하지 않음
• METR 연구 결과, 개발자들이 AI 코딩 도구로 생산성이 20% 향상된다고 믿었지만 실제로는 19% 저하됨
• 수많은 홍보 문구와 기업, 개발자들의 과장된 10배 생산성 주장이 시장 현실 또는 소프트웨어 신규 출시에 반영되고 있지 않음
• Shovelware(대량 양산 앱, 저품질 소프트웨어) 급증과 같은 현상은 관측되지 않아, 가시적인 변화가 없음
• GitHub, Copilot, Cursor, Google, OpenAI 등 기업과 일부 개발자의 생산성 과장이 투자, 구조조정, 연봉 책정에 악용되고 있음
• 핵심 결론: “실제로 더 많은 소프트웨어가 나오지 않는 이상, AI 코딩이 개발자를 10배로 만든다는 주장은 허구”, 따라서 개발자는 압박에 흔들리지 말고 데이터로 대응해야 함

---

서론: 소프트웨어 개발자, AI 코딩에 분노

• 오랜 기간 소프트웨어 개발자로 살아오며 프로그래밍에 자부심과 정체성을 가짐
• AI 기반 코딩 툴 도입 초기에는 기대감을 가졌으나, 최근 연구(METR)에 회의감을 느끼게 됨
  • 본인은 AI 코딩이 자신을 약 25% 빠르게 만든다고 생각했으나, METR 연구에서는 오히려 19% 느려진다는 결과
• 해당 연구에서 개발자가 직접 느끼는 AI 도구 효율성 인식과 실측 데이터가 정반대임을 확인함
• 직접 실험해본 결과도, AI 활용이 실제 프로그래밍 시간에 긍정적 영향을 주지 않음을 체감함

직접 검증: AI와 무작위 비교 실험

• 작업 단위별로 AI를 사용했을 때와 그렇지 않을 때의 시간 차이(Delta) 를 측정하는 실험 방법 적용
• 6주간 실험으로 얻은 데이터는 통계적으로 유의미한 차이를 발견하지 못함
• 소규모 표본에도 불구하고 AI 사용이 실제로는 오히려 21% 느려지는 경향을 확인(METR 연구와 동일한 수치)
• 만약 진짜 2배, 10배 향상 효과가 있었다면 데이터에서 뚜렷이 드러났을 것임
• 현재의 AI 코딩 꿈은 실현되지 않고 실제로는 변화가 없음

기대와 현실: Shovelware 폭증이 없는 이유

• AI 코딩의 생산성 혁신이 현실이라면, 온갖 앱과 서비스, 게임 등이 폭증해야 함
• 수많은 AI 코딩 툴의 마케팅 메시지(“Built to make you extraordinarily productive” 등)가 난무함
• 구글, OpenAI, GitHub Copilot 등도 개발자 25% 속도증가나 10배 생산성을 주장함
• 하지만 실제 신규 소프트웨어 출시 데이터(GH Archive, BigQuery 등)에서는 가파른 성장이나 폭증 현상이 일어나지 않음
• 2022년 이후 대중적 AI 코딩 보급에도 불구하고, 전 세계 신규 릴리스 및 프로젝트 수치에는 큰 변화가 없음

시장 영향과 개발자 현실

• AI-First 전략, FOMO, 대량 해고 및 개발자 연봉 인하 같은 산업 내 사회적 파장까지 나타남
• 실제 개발 현장에서는 AI 도구가 생산성 혁신을 제공하지 못함
• 학습 곡선이나 툴 숙련도로도 절대적인 생산성 차이를 설명하지 못함

결론: 냉정한 데이터 기반 판단의 필요성

• 현재까지 신규 소프트웨어 출하량에 변화가 없음을 데이터로 확인하는 것이 핵심임
• AI로 10배 코더가 되었다는 주장에 증거가 없음
• 개발자는 압박에 굴복하지 말고, 자신이 직접 확인한 데이터에 의거해 도구 선택을 해야 함

자주 나오는 반론에 대한 반박

1. "프롬프트 기술을 제대로 익히면 10배 개발자가 된다"

   • 실제로 10배 생산성을 달성한 이들이 있었다면, 전 세계 신규 소프트웨어 생산량이 두 배가 넘었을 것임
   • 주장보다 객관적 결과물(앱, 프로젝트 등) 이 중요한 증거임

2. "아직 초기 단계라 시간이 필요함"

   • 수십억 달러가 투자되고 실제 현업에서 이미 도입 중임
   • 오늘날 결정이 실제 사람들의 삶에 직접적 영향을 미침

3. "지금 도입 안 하면 뒤처짐"

   • Github Copilot 데이터 등에서도 숙련도 상승에 따른 실질적 생산성 증가가 극히 미미함(29% → 34% 승락률)

4. "품질이 좋아졌을 뿐 양은 그대로"

   • 업계 품질 전체가 오히려 퇴보하고 테스트도 줄어듦
   • 진짜 10배 코더 도구이였다면 Shovelware 범람이 현실이어야 함

5. "모든게 웹 사이트 중심이고, 요즘엔 도메인 이름은 관심없음. Vercel 같은 곳의 하위도메인이 전부임"

   • 여전히 개별 도메인을 선호하는 사용자가 많음

6. ".ai 도메인 폭증(올해 47%) = 실질적 증가"

   • 신규 도메인 증가는 AI 스타트업의 피벗 때문일 뿐, 전반적 신규 도메인 수 폭증은 아님
   • 도메인 전체수는 그렇지 않음

7. "개발의 본질은 코드 이외 업무임"

   • 대기업이 아닌 개인/소규모 개발자 환경에서는 실제로 코드가 중심임
   • 여전히 자잘한 코딩 욕구를 해소하는 신규 프로젝트가 눈에 띌 만큼 늘어나지 않음

마무리

• 개발자는 실제로 더 많이 출시하지 않고 있음
• AI 코딩이 10배 생산성을 제공한다는 주장은 데이터로 반박 가능
• 업계의 FOMO·마케팅 내러티브에 휘둘리지 말고, 실제 결과물 중심으로 평가해야 함
• 저자의 메시지: “압박을 느낀다면 데이터와 차트를 보여주라. 10배 생산성 주장에는 영수증을 요구하라.”

[ahwjdekf]

10x 개발자에겐 ai 도움으로 12x 정도로 점프 할 순있겠죠.

[overthetop]

AI는 허상. 신뢰할 수 없고 수준도 낮음. AI로 개발할 수 있다는건 과장된 거짓말. 불가능함. 그리고 AI사용하는건 개발자의 윤리를 버리는 무책임한 행동.

[nemorize]

단순 반복 작업은 AI에게 온전히 맡기고, 더 중요한 작업에 완전히 몰두할 수 있는 수준이 된다면 그 때 AI가 코드 작성 생산성에 향상에 큰 도움이 된다고 말할 수 있지 않을까 싶습니다.

명령을 한번 내려놓으면 수십초 가량의 기다림 끝에 아웃풋이 나오는데, 그 수십초 사이를 활용할 수 있는것도 아니고, 수십초만 끝나면 항상 완벽한 아웃풋을 기대할 수 있는 것도 아니구요.

결국 내가 계속 그 간단한 작업이 완벽히 끝나기 전까지는 계속 신경쓰고 있어야 하고, 다른 작업으로 전환하지도 못하기 때문에... 유의미한 향상을 기대하긴 힘들더라구요.

[nemorize]

차라리 당근에서 시급 만원 주고 몇시간동안 단순 작업만 해줄 알바 하나 구하는게 생산성 향상에는 더 도움이 되었던 것 같습니다.
일주일에 10만원 내외의 비용 지출만으로도 개인적으론 꽤 만족스러웠습니다.

특히 경리일 하시다가 일 그만두고 전업주부로 계신 아주머님들 몇 분과도 일해봤는데, 코딩 전혀 모르시는 분들도 몇 번 피드백 드리고 나면 아주 깔끔하게 만들어주십니다ㅋㅋ
보일러플레이트 코드들은 엑셀 사용해서 자동채우기, 수식 등등으로 순식간에 만들어 주시기도 하고...

[zxcv123]

음 .. 솔직하게 드는 생각은 AI도 역시 도구기 떄문에 잘활용해야하는데요..
어떤 도구든간에 잘쓰는 사람에비해서 그냥 대충, 혹은 제대로 활용 못하는 사람이 더 많습니다.
AI가 양질의 결과를 내게끔 세팅하면 충분히 압도적인 퍼포먼스를 보여줍니다.
AI로 양질의 결과를 내게끔 할줄 모르는사람들이 그저 멍청한 프롬프트나 싸재끼면서, 생산성이 낮아졌다고 하는게 아닐까 합니다. AI의 생산성을 부정하는건 도저히 이해가 안되네요

[kirrie]

그런데 그렇게 말씀하시는건 “진짜 CS를 깊게 이해하고 충분한 숙련을 쌓은 사람은 어떤 AI보다 더 생산성이 뛰어나다.“는 말처럼 아무 것도 증명하지 못하는 것 같아요.

[ndrgrd]

언급된 METR 연구를 얼마 전 봤는데 제가 느끼고 의문을 갖던 것을 잘 설명해주는 결과더라고요.

Hacker News 댓글에 있는 "반복 업무"를 시켜도 사실 대부분 수동 확인과 수정이 필요합니다.
AI가 작성한 '간단한' 결과의 중구난방식 논리를 보고 그냥 내가 할 걸 그랬나 라는 생각이 든 것이 한두번이 아닙니다.

정말 간단한 복붙 수준의 작업은 잘 하겠죠.
근데 그런 건 그냥 복붙과 스니펫이 더 효율적입니다. 인터넷에 접속해서 남의 서버에 내 데이터를 올리고 수십 초씩 기다리지 않아도 되고요.

[GN⁺]

Hacker News 의견

• 내게 AI는 종 모양 곡선과 같음, 많은 사람들에게도 비슷할 거라고 봄. 아웃풋을 평가하는 기준이 중요하다고 생각함. “코드 라인 수”가 아니라 “좋은 품질의 유지 관리 가능하고, 확장 가능하며, 업그레이드가 쉬운 코드 라인 수”여야 함. 이 기준으로 보면 “전체 레포 생성” 같은 요청의 결과는 의미가 없는 쓰레기이지만, AI가 “getUser(…” 같은 코드를 자동 완성해주는 것은 생산성 향상임. 이게 0.1% 증가인지 1%인지 10%인지는 확실하게 말할 수 없음

• 내 입장에서 가장 심각한 문제는 지금 회사에서 내가 다루는 문제들이 신중한 계획과 실행을 요구하는데, AI가 전혀 도움이 되지 않는다는 점임. 그런데 우리 매니저는 “우리는 AI-first 회사”라는 이유로 프로젝트 납기 시간을 기존 견적의 20%로 줄였다고 함. SVP들과 PM들 사이에서 이런 집단적 광기가 엄청나게 번지고 있고, 이런 건 전에도 본 적 없음

  • 매니저가 프로젝트 납기를 원래 견적의 20%로 줄였다고 말했는데, 이건 정말 말도 안 되는 일이라고 생각함. 이런 비현실적인 수치를 누군가가 그냥 정해서 현실로 만들어버림. 결국 안 되면 그 책임을 나에게 돌릴 것이고, 위에서는 그 매니저에게 책임을 물을 거임. AI로 정말 생산성이 올라간다면 불필요한 개발자를 정리하면 되지만, 그건 LLM이 개발 프로세스에 성공적으로 자리 잡은 후에 할 일임. 투자금도 AI 버블에 대비해서 S&P 500에서 빼야 하나 고민이 생김
  • 만약 인시던트 대응까지 LLM에게 맡길 수 있다면, CEO가 원하는 대로 하게 두고 그에 따른 평판적인 손해도 감수하면 됨. 만약 실패하면, LLM이 작성한 코드 이전 시점으로 git을 되돌리면 된다고 생각함. 농담 반 진심 반임
  • 현재 AI 수준은 개발자를 대체할 정도는 아니지만, 이전에는 자동화하기 어려웠던 많은 오피스 업무나 매니저 역할은 충분히 자동화할 수 있을 만큼 좋아졌다고 생각함. Google은 실제로 AI 때문에 미들 매니지먼트를 많이 줄였고 개발자는 그만큼 줄이지 않은 듯함
  • AI가 기술 리더십이 부족한 매니저들이 개발자에게 압박을 가할 핑계로 쓰이고 있음

• 여러 가지가 동시에 사실일 수 있음. LLM이 무작위로 선정된 일반적인 작업에 대해 개발자 생산성을 10배로 올려주는 건 아님. 반면 LLM이 특정 범위의 작업에서는 생산성을 극적으로 높여줌. 바쁜 반복 업무를 자동화하는 데도 쓸 수 있는데, 인간보다 실제 시간은 오래 걸려도 백그라운드로 작업이 돌아가니 문제되지 않음. 새로운 API나 라이브러리를 익히는 데 LLM이 훨씬 속도를 올려주고, 모르는 언어로 작은 glue 코드를 짤 때 시간도 아끼고 불필요한 학습까지 안 해도 되어 엄청난 도움임. 큰 기존 코드베이스 보수 작업엔 별 생산성 차이를 못 느낌. 새로운 웹사이트 스캐폴딩 세팅은 LLM이 놀랄 정도로 잘함. mock 클래스 작성도, mock 라이브러리 사용법을 잘 파악해서 내가 두어 번 해보다 까먹는 복잡한 작업도 순식간에 처리함. 새로운 코드베이스 구조 파악도 70% 정도는 만족스럽게 해줌. 복잡하게 설계된 프로젝트에서 HTTP 라우트 위치나 의존성 주입 함수 위치 찾기 등에도 “야 Claude, auth 관련 함수들 어디 있냐?” 이렇게 물어보면 편함. 올바른 도구를 올바른 작업에 써야 한다고 생각함

  • 새로운 API나 라이브러리 익히기가 LLM 덕에 훨씬 빨라졌다는 느낌을 동의하면서도, 막상 LLM의 답변을 살펴보고 문서도 직접 읽어보면 관례를 안 따르거나 단순한 예제만 쥐어짜고, 잘못된 특징을 써서 돌아가는 방식이 엉뚱하거나 복잡한 길을 택할 때가 있다는 점이 걱정임. 마치 마법처럼 느끼다가도 너무 믿다 보면 실제론 제대로 이해하지 못하는 착각에 빠지기 쉬움
  • “바쁜 반복 업무를 백그라운드에서 LLM이 자동화한다"는 게 구체적으로 뭔지 궁금함. 실제로 어떤 업무에 성공하고 있는지 AI 옹호자들이 구체적인 예시를 명확하게 밝혀야 된다고 생각함. 두루뭉술함에 점점 피곤해짐
  • “LLM이 새로운 API와 라이브러리를 빠르게 익히게 해준다”라는 표현이 더 정확하려면 “이미 오래된 라이브러리나 API를 처음 접할 때”로 바꿔야 할 것 같음. 정말 새로운 라이브러리나 툴에는 LLM이 별 도움이 안 되는 경우가 많음

• 영상 속에서 스크린에 코드가 쏟아지고, “주니어 개발자들은 끝났다”는 주장 이상의 실체가 없는 게 대부분임. 그 이유는 경제가 불안정하고, AI가 구원자가 되어줄 거라는 기대에 과장과 불안이 가득한 분위기라 생각함. 실제로 AI로 인상적인 결과를 얻을 때도 있긴 하지만, 기본적으로 어느 정도 실력 있는 사람이 아니면 무의미함. 초보~중급 수준의 사람들은 소셜미디어에서 과장된 성공담만 쏟아냄. 사람마다 “AI 슈퍼파워”를 지키려고 심리적·현실적으로 애쓰는 분위기가 형성됨. 결국 하이프 사이클에서 어느 순간 균형점을 찾고, 몇십억 달러가 다시 소각될 날을 기다릴 뿐임

  • 내 경험상, AI 툴들은 완전히 빈 프로젝트(블랭크 캔버스)에선 정말 능력을 발휘함. 예를 들면 새로 React 프로젝트를 만드는 데는 툴이 나보다 빠르게 세팅해줌. 그런데 실제 업무 레포지토리에서는 거의 쓸모가 없음. 이렇기 때문에 AI 툴들이 데모와 홍보에선 엄청난 인상을 주지만, 현실에선 실망만 남기는 결과가 나옴
  • “충분히 직접 수동으로 해볼 만큼 경험이 있는 사람”이어야 잘 다루는지, AI 툴과 그 한계에 익숙한 사람이어야 하는지, 아니면 그 둘 다가 필요한 건지 궁금함
  • AI에 관한 과장된 이야기는 대부분 깊이 없는 논문 추상만 읽고, 곧 현실화될 거라 떠드는 대중 과학 미디어 기사랑 비슷하게 들림

• 내 경험상, AI는 일부 사소한 작업(예: 소규모 리팩토링, 타입 정의 자동화 등)에 쓸모 있었지만, 그 이상의 복잡한 작업에는 여러 가지를 놓치고 재작업이 필요했음. 미래에는 내 말을 다시 생각하게 될 수도 있겠지만, 최근 더 경험이 적은 엔지니어들이 큰 기능을 구현하려고 AI가 내놓는 결과물을 “좋은 코드”라고 무비판적으로 받아들이는 경우가 늘었음. 그런데 이 코드들은 우리 스타일 가이드와 패턴을 따르지 않거나, 이미 나와 있는 라이브러리 대신 굳이 로직을 처음부터 구현해서 결국 우리가 직접 관리해야 할 코드가 늘어남. 나중에는 모든 걸 한 번에 하려는 거대한 PR이 나오기도 함

  • 순수하게 새로 만든 코드라면, 종종 50줄 정도 코드를 위해 큰 라이브러리를 끌어오는 것보다 그냥 짓는 게 이롭다고 생각함. 이 점은 긍정적임
  • 이런 코드들과 라이브러리의 존재 자체를 파악하는 ‘발견’이 숙제로 남아 있고, 팀원들이 내부 코드를 독립적으로 알아서 쓰려면 문서 또는 검색 자체를 LLM에 기대하는 방식도 연구 중임. 내부 라이브러리 지식이 편중되는 현상이 고민거리임
  • 진입 단계 개발에선 상황이 달라짐. 프로젝트 초기에 코딩 스타일이나 기준이 없는 상태라 LLM이 내는 결과가 팀원들이 내는 의견과 큰 차이가 없음. 데모 상태까지만 코드를 만들어도 가치 있음. 여러 프로젝트를 빠르게 데모 단계까지 만들어보는 게 큰 부스트임

• 여기 주장에 동의함. AI를 써도 생산성 획기적 상승은 못 봄. 소프트웨어 엔지니어가 꾸준히 문제 해결, 분별, 코드화 연습을 안 하면 신경 지식이 약화될 수 있다고 봄. AI가 미래의 2배, 10배 생산성을 가져다 줄 기술이라는 약속은 실체가 없고, 개인 코드베이스에서 약간의 생산성 증가가 있었더라도, 시장에서 실제로 더 나은 제품 출시가 늘진 않았음. 컨설팅을 하면서 종종 파운더나 CTO들이 AI를 밀어붙이다가 오히려 코드를 제대로 관리하지 못하고 더 많은 혼란을 초래하는 걸 자주 봄. 요즘은 엔지니어링 베스트 프랙티스 확립을 위해 어드바이저 역할을 맡는 경우도 많음

  • 대부분의 기술이 그렇듯, 실습과 연습이 끊기면 감각이 둔해짐. 자전거 타기도 오랜만에 하면 몸의 감각이 녹슬듯, 코딩 능력도 실질적으로 약해짐. IT 엔지니어링에도 해당한다고 믿음. 실제로 경계해야 할 신호임

• CEO들이 AI로 기존 개발자 생산성이 10배 오른다고 말하지만, 그게 진짜라면 오히려 개발자를 훨씬 더 많이 뽑아야 하는 거 아닌가 싶은 의문이 듦. 만약 같은 투자로 생산성이 10배 오르면 당연히 그 “엔진”에 돈을 퍼붓는 게 합리적임. 그런데 현장에선 생산성은 그대로인데 인건비만 줄이는 데 그친 게 아닌가 싶음

  • 이익률이 떨어지면, 결국 인건비에서 가치를 짜내야 한다고 생각함. AI의 99% 매력은 인건비 절감이고, 채용은 그에 역행함. 나 또한 AI의 생산성 향상 주장에 동의하지는 않지만, 이런 동기 요소가 있다는 점을 지적하고 싶음
  • 많은 C레벨들이 남아있는 인력도 AI로 대체할 거라 기대하는 듯 보임. “곧 AGI가 실현된다"는 내러티브를 따름. 난 그렇게 믿지 않지만, 그런 입장이라면 개발자 더 채용하지 않을 논리도 이해됨
  • 오늘 “수익체감의 법칙”이 뭔지 배울 수 있을 것 같음. 한 조직에 투입할 수 있는 인간·자원의 한계가 존재함. 필요 이상 투입은 무의미함. 해고가 늘어난 이유는 AI가 효율을 올려줬기 때문인데, 인간 한 명이 하던 업무량을 AI가 커버하게 되면 그만큼 고용이 줄어듦. 한 인간 = 한 AI가 아니라, 업무량이 AI에게 넘어가 인간이 줄어드는 구조임. 사람 대체가 완전히 끝난 건 아니지만, 얼마나 인간이 필요한지가 새로운 수요·공급의 기준이 될 것임. 창의적 인재는 항상 더 필요할 텐데, 그런 인재가 부족함. 연봉 10만~20만불 원하는 소프트웨어 엔지니어 중에는, 기업에 얼마를 절약시킬 수 있는지도 모르는 경우가 많음. 학교 교육이 창의력을 죽였다는 생각도 듦. 문제는 역량 부족이 아니라, 스스로 방향을 컨트롤하거나 아이디어를 만들어내는 힘이 부족한 데 있다고 봄

• 신선한 각도로 신제품 출시량을 바라보는 분석이 인상적임. 빠른 성장 대신 예상보다 큰 변화가 없다고 느꼈음. 대안론으로, 실은 코드 작성이 제품 출시의 병목이 아니었고, 무엇을 만들지 탐험하며 실제 플랫폼에 올리는 것 자체에 많은 시간과 노력이 소요된다는 해석도 가능함. 한편 AI 툴을 잘못 쓰기가 너무 쉽다는 점도 동의함. 때론 “드디어 깨달았다!” 하다가도 다음 날 “또 다른 방법으로 잘못 쓰고 있었구나” 깨닫게 됨. 소프트웨어 개발이 왜 이렇게 어렵고 생산성 가속이 어려운지, 20년 이상 개발을 해도 여전히 명확하지 않음

  • “코드 작성이 병목이 아니었다”는 통찰이 정말 와 닿음. 소프트웨어에서 진짜 가치는 “어려운 문제”를 푸는 데서 나오고, 쉬운 문제는 이미 템플릿처럼 어디에나 있음을 깨달음. LLM이 쉬운 문제는 빨리 끝내지만, 진짜 병목은 여전히 “하드”한 문제에 있음. 기술, 비즈니스, 고객 등이 이유가 되어 어려운 문제들은 LLM으로 제대로 풀리지도 않고, 진짜 이득은 이 지점에 있음. 반면 템플릿화 가능한 쉬운 문제들은 LLM이 진짜 생산성을 높임
  • 소프트웨어 제공에서 코딩 자체가 병목이 된 적은 없었음. AI는 회사 인력 감축의 명분이나 투자 유치용 구실로 활용될 뿐임
  • 제품 개발에서는 반복적인 사용자 피드백, 예외 케이스 고치기 등 시간이 필요한 과정은 아무리 AI가 있어도 단축시키기 어려움. 이런 점이 소프트웨어가 10년은 걸린다는 joelonsoftware.com의 글과도 연결됨

• 우리가 그 미래를 지금 만들고 있음. 실제로 내가 속도가 붙기 시작한 건 agentic AI가 충분히 좋아진 4~5월 부터였음. 오늘만 해도 iMessage 아카이브를 웹사이트로 익스포트하는 CLI 도구를 만들었고, 예전 같으면 몇 주 걸릴 일이 이제 하루 이틀 만에 homebrew formula로도 만들 수 있을 듯함. iOS 앱도 진행 상황이 손코딩보다 훨씬 빠르게 나가지만, 일부러 천천히 진행 중임. 참고로 해당 게시글 데이터가 3~4월에 끝나는데, 이 시점부터 generative AI가 코딩에 실질적 도움이 되기 시작했다고 생각함. (난 Copilot을 2022년 11월부터 썼음)

  • 이런 논란이 나올 때마다 “너 아직 최신 AI 안 써봤구나, 이번엔 진짜 잘 됐다”라는 반응이 반복됨이 놀라움
  • 내 경험도 거의 비슷함. 나는 AI 하이프에 늦게 탑승했지만, 최근에 나온 새로운 모델과 툴 조합을 써보고 생각이 바뀌었음. 내 주변에선 대기업들이 이제야 이런 툴 사용을 허락하기 시작했기 때문에 실제 생산성 향상 데이터에는 꽤 시차가 있어서 그 영향이 나중에 드러날 거라 예상함. METR 연구에 대한 아쉬움도 있고, 이런 생산성에 대한 메타 연구가 더 많이 나오길 바람
  • 동의함. agentic AI는 “전통적인” AI와 완전히 다른 툴임. 앞으로 1년 후라면 저자의 데이터와 실험이 어떻게 나올지 기대가 큼
  • “AI가 드디어 빨라졌다”고 말하는 순간, 불과 5개월 전이라니. AI 속도에서는 5개월이 6년에 해당하는 변화처럼 느껴짐

• 한때 풀타임 개발자였고, 이후 매니저·CTO로 일하면서 점점 개발 실무와는 멀어져 감. 다시 코딩을 하려고 해보니 프레임워크, API, 언어, 세세한 트릭들을 새로 익혀야 하는 게 예전엔 흥미로웠지만 지금은 짜증나는 일이 됨. 그런데 Claude Code 같은 툴과 소프트웨어 설계 경험 덕분에, 예전처럼 큰 시스템을 다시 개발하는 게 가능해졌음. 내 생산성이 20% 느는 것도, 10배 빨라지는 것도 아님. 애초에 안 하려고 했던 일을 다시 하게 만들어줬으니 무한대의 생산성 증가라고 표현하고 싶음. 만약 내가 개발을 사랑하는 실력자라면 이 툴들이 귀찮기만 하겠지만, 평소 개발하지 않을 사람에겐 정반대임

  • 와, 큰 시스템을 한 번도 아니고 여러 번이나 다시 개발했다니, 자세한 사례를 공유해줬으면 좋겠음
  • 내 AI 코딩 툴에 대한 대이론은, 실제 시간을 크게 단축시키는 게 아니라 짜증을 대폭 줄여준다는 것임. 문법, 컴파일러, 반복 작업에 대한 불필요한 짜증을 아껴 진짜 중요한 데 정신을 쓸 수 있게 만들어줌. 덕분에 예전 같으면 너무 짜증나서 안 할 일도 이제는 하게 되고, 퇴근 전에 산책 대신 그냥 책상에 몇 시간 더 머무를 수 있게 됨