개발자들, AI 없이 '노동 거부'? 미래 소프트웨어 재앙의 서곡인가
Published May 30, 2026
2026년, 개발자들의 손에서 AI 코딩 도구를 떼어놓는 것은 거의 불가능하다는 충격적인 연구 결과가 나왔습니다. 마치 자신의 신체 일부인 양, AI 없이는 작업 자체를 거부하고 있다는 것이죠. 믿기시나요? 불과 몇 년 만에 AI가 소프트웨어 개발 현장을 이렇게까지 장악해버린 겁니다. 하지만 이 놀라운 생산성 향상 이면에는 우리가 미처 보지 못했던 어둡고 거대한 그림자가 드리워지고 있다는 경고음이 들려오고 있습니다. AI가 코드를 훨씬 빠르게 생성하는 것은 분명하지만, 이것이 과연 ‘더 나은’ 코드를 의미할까요? 불행히도, 많은 연구자들이 “아니다”라고 답하며, 이는 미래에 개발자와 기업 모두에게 거대한 재앙으로 돌아올 수 있다고 경고하고 있습니다.
AI: 생산성 향상의 만능 열쇠일까, 아니면 독배일까?
우리는 한때 AI 코딩 도구가 개발자들의 생산성을 혁명적으로 끌어올릴 것이라고 기대했습니다. 실제로 2025년 발표된 한 획기적인 연구는 AI 코딩 생산성에 대한 기대를 한껏 부풀렸죠. 당시 개발자들은 AI가 자신들을 더욱 생산적으로 만든다고 보고했습니다. 하지만 연구 결과는 의외였습니다. AI는 코드를 더 빠르게 생성했지만, 개발자들은 오류를 찾고 수정하며 AI를 조종하고 작업이 완료되기를 기다리는 데 추가 시간을 소비했고, 결과적으로 실제 작업 속도는 오히려 느려졌다는 겁니다. 솔직히 말해서, 이쯤 되면 우리가 AI를 제대로 활용하고 있는 것인지 의문이 들지 않을 수 없습니다.
그리고 2026년 2월, 존경받는 AI 연구소 METR은 또 다른 충격적인 사실을 발표했습니다. AI 및 코더 역량 향상을 측정하기 위해 2025년 실험을 반복하려 했지만, 개발자들이 연구 참여를 거부한 겁니다. 그들의 이유는 명확했습니다. “AI 없이는 일하고 싶지 않기 때문”이라는 겁니다. 단지 연구를 위한 잠시 동안의 제한적인 작업조차도 AI 없이 하려 하지 않았다는 점은 매우 놀랍습니다. 이는 단순한 도구 의존도를 넘어선, 거의 **‘디지털 의존증’**에 가까운 현상으로 보입니다.
METR은 결국 5월에 기술 직원을 대상으로 한 설문조사를 발표했고, 예상대로 직원들은 AI가 자신들의 가치를 조직에 두 배로 높여준다고 인식했습니다. 스스로 느끼는 생산성 향상은 엄청났던 것이죠. 하지만 과연 이러한 자기 인식은 현실을 정확히 반영하고 있을까요? 저는 이 부분에서 주목할 점은, 개발자들이 AI의 도움으로 얻는 즉각적인 ‘생산성의 감각’에 너무 깊이 빠져들어, AI가 가져올 수 있는 잠재적인 장기적 문제점들을 간과하고 있을 가능성이 높다는 점입니다.
‘토큰맥싱’의 환상과 숨겨진 비용
최근 ‘토큰맥싱(tokenmaxxing)‘이라는 현상이 2026년의 주요 트렌드로 떠올랐습니다. 이는 AI 사용량을 생산성 척도로 삼는 방식으로, AI 에이전트가 생성하는 ‘토큰’의 양을 통해 직원의 기여도를 측정하려는 시도였죠. 하지만 이 트렌드는 이미 막을 내리고 있을지도 모릅니다. 아마존은 직원들이 AI 에이전트를 과도하게 사용해 비용을 증가시키며 시스템을 조작하자, 내부 토큰 추적 리더보드인 ‘키로랭크(Kirorank)‘를 폐쇄했습니다. 이는 AI 사용이 자동으로 생산성 증가로 이어지지 않는다는 명백한 증거입니다.
우버 또한 올해 첫 4개월 만에 2026년 AI 예산을 모두 소진했습니다. COO 앤드류 맥도널드는 팟캐스트에서 이러한 지출이 프로젝트나 생산성의 측정 가능한 증가로 이어지지 않았다고 인정했습니다. 대규모 AI 투자가 곧바로 가시적인 성과로 이어지지 않는다는 이 사례들은, AI 도입의 비즈니스적 가치에 대해 신중한 재평가가 필요함을 시사합니다.

더 심각한 문제는 AI 생성 코드가 반드시 지속적인 코드 유지보수 요구 사항을 줄여주지 않으며, 오히려 증가시킬 수도 있다는 점입니다. 프로그래머이자 작가인 제임스 쇼어(James Shore)는 해커 뉴스에서 큰 화제가 된 블로그 게시물에서 이 점을 명확하게 지적했습니다. “코드를 두 배 빠르게 작성한다고요? 유지보수 비용도 절반으로 줄었다고 확신해야 할 겁니다. 그렇지 않으면 망하는 겁니다. 일시적인 속도 향상을 영구적인 노예 계약과 맞바꾸는 셈이죠.” 그의 말은 솔직히 섬뜩하기까지 합니다.
이러한 주장을 뒷받침하는 다른 증거들도 있습니다. 신뢰성 엔지니어링 에이전트 스타트업 Entelligence AI의 창립자 겸 CEO인 아이스와리아 산카르(Aiswarya Sankar)의 바이럴 트윗에 따르면, 기업들은 AI가 생성한 버그를 수정하는 데 **전체 토큰의 44%**를 사용하고 있다고 합니다. 코드 검토 도구 회사인 CodeRabbit 역시 오픈소스 풀 리퀘스트를 분석한 결과, AI가 인간이 작성한 코드보다 1.7배 더 많은 문제를 발생시켰다고 보고했습니다. 물론, 이 수치들은 AI 코드 검토 도구를 판매하려는 회사들의 주장이라는 점에서 어느 정도 자기 홍보적인 면이 있음을 인정해야 합니다.
하지만 독립적인 연구자들도 비슷한 문제들을 발견했습니다. 싱가포르 경영대학교(Singapore Management University, SMU)의 연구원들은 4월에 발표한 보고서에서 “AI 생성 코드가 실제 소프트웨어 프로젝트에 장기적인 유지보수 비용을 초래할 수 있다”고 경고했습니다. 개인적으로는 이 경고가 매우 중요하다고 생각합니다. 당장의 개발 속도에만 집중하다가 미래의 유지보수 부채를 엄청나게 쌓아 올리는 것은, 지속 가능한 소프트웨어 개발과는 거리가 멀기 때문입니다.
AI 코드, 어떻게 다뤄야 할까: 해결책은?
프로그래머들이 AI 조수를 사랑하는 것은 분명한데, 그렇다면 이 딜레마를 어떻게 해결해야 할까요? AI 코딩 에이전트를 판매하려는 사람들은 AI가 코드를 뱉어내는 속도만큼이나 빠르게 AI 코딩 에이전트를 사용해서 골치 아픈 코드 수정 작업을 처리할 수 있다고 말합니다. AI 코딩 에이전트 ‘데빈(Devin)‘의 개발사 Cognition의 창립자 겸 CEO인 스콧 우(Scott Wu)가 바로 그런 주장을 합니다. 하지만 그조차도 데빈이 독립적으로 작업할 수 있지만, 현재 데빈의 실력은 작업에 따라 주니어와 미들 레벨 프로그래머 사이라고 인정합니다. 이것은 단순히 맡겨놓고 잊어버릴 수 있는 해결책이 아니라는 말이죠.
SMU 연구자들은 좀 더 인간적인 접근 방식을 제안합니다. 프로그래머들은 AI가 잘하는 작업과 잘하지 못하는 작업을 자신이 가장 좋아하는 코딩 언어를 아는 것만큼이나 깊이 이해해야 합니다. AI를 위한 강력한 품질 보증 시스템이 필요하며, AI의 작업을 마치 주니어 개발자의 것처럼 신중하게 검토해야 한다는 겁니다. 사실 이건 너무나 당연한 이야기 아닐까요? 주니어 개발자의 코드를 리뷰하듯 AI 코드를 검토하는 것은, AI가 아직 완벽하지 않다는 현실을 인정하고 그 한계를 보완하려는 노력의 일환입니다.
한편, 연구자들은 (스콧 우 역시 동의하듯이) 인간은 여전히 소프트웨어 아키텍처 및 보안 설계와 같은 큰 그림을 그리는 작업을 수행해야 한다고 말합니다. AI는 도구일 뿐, 전체 시스템의 설계와 안전에 대한 최종 책임과 통찰은 인간의 영역이라는 것이죠. 업계 흐름을 보면, AI는 개발 프로세스의 특정 반복적이고 단순한 부분에 최적화될 가능성이 높으며, 창의적이고 비판적 사고가 요구되는 상위 레벨의 설계와 전략은 여전히 인간 전문가의 역량에 달려 있을 것입니다.
결론적으로, AI는 개발의 속도를 높일 수 있지만, 그 이면에는 보이지 않는 비용과 잠재적인 위험이 도사리고 있습니다. 무분별한 AI 의존은 오히려 장기적으로 더 큰 문제를 야기할 수 있다는 냉정한 현실을 직시해야 합니다. AI를 현명하게 활용하기 위해서는 그 한계를 정확히 이해하고, 엄격한 품질 관리 시스템을 도입하며, 인간 개발자가 최종적인 책임과 통찰력을 발휘하는 ‘인간 중심의 AI 통합’ 전략이 필수적입니다. 단순히 “AI 없이는 일 못 한다”는 말로 현상 유지만을 고집한다면, 우리는 머지않아 거대한 소프트웨어 부채의 늪에 빠지게 될지도 모릅니다.
출처
- 원문 제목: Coders are refusing to work without AI — and that could come back to bite them
- 출처: AI News & Artificial Intelligence | TechCrunch
- 원문 기사 보러가기