AI 코딩 도구가 하루가 다르게 좋아진다는 이야기는 넘쳐나지만, 정작 눈에 띄는 결과물은 보이지 않는다는 반론도 꾸준하다. 개발자 네이트 메이비스는 바로 이 지점을 파고든다. "AI 코딩이 그렇게 대단하다면, 지금쯤 쓸 만한 새 소프트웨어가 훨씬 많이 쏟아져 나와야 하는 것 아닌가?" 특히 AI 회의론자들이 즐겨 던지는 이 질문에서 글은 출발한다. 다만 그는 명쾌한 정답을 내놓기보다, 가능한 후보 답들을 추측 수준에서 늘어놓고 그중 상당수는 자신조차 신뢰도를 낮게 본다고 분명히 선을 긋는다. 결론을 단정하지 않는 이 태도 자체가, 요즘처럼 과장된 단언이 범람하는 환경에서 오히려 눈여겨볼 만하다.
질문보다 전제가 흔들린다
이 물음이 흥미로운 이유는 답보다 전제에 있다. '좋은 새 소프트웨어'라는 표현부터가 모호하다. 무엇을 '새것'으로 셀 것이며, '좋다'는 기준은 누가 정하는가. 앱스토어에 등록된 신규 앱 수인가, 깃허브 저장소 증가분인가, 아니면 실제로 사람들의 일을 바꿔 놓은 제품인가. 측정 기준을 정하지 않은 채 '더 많이 보여야 한다'고 말하면, 그 기대는 반증도 입증도 어려운 막연한 느낌에 머문다. AI의 효과를 논할 때 생산성 지표가 늘 논쟁거리가 되는 것도 같은 이유다. 생산성이 올랐다는 주장과 체감이 없다는 반박이 평행선을 달리는 배경에는, 서로 다른 것을 재고 있다는 사정이 깔려 있다.
변화는 보이지 않는 곳에서 먼저 일어난다
설령 AI가 코드 작성 속도를 끌어올렸다 해도, 그 효과가 곧장 '새 제품의 홍수'로 나타나리라는 보장은 없다. 소프트웨어 개발에서 코드를 짜는 일은 전체 과정의 일부일 뿐이다. 기획, 설계, 테스트, 배포, 유지보수, 그리고 사용자를 확보하는 유통 단계가 모두 병목으로 남아 있다. 코딩이 빨라져도 이 뒷단이 그대로라면 전체 산출물은 크게 달라지지 않는다. 더구나 AI가 만드는 상당수의 변화는 바깥에서 보이지 않는 곳에서 일어난다. 기존 코드베이스의 리팩터링, 밀려 있던 버그 수정, 사내 자동화 스크립트, 테스트 커버리지 보강 같은 작업은 '새 소프트웨어'로 집계되지 않지만 분명히 가치를 만든다. 겉으로 드러나는 신제품만 세면 이런 내부 개선은 통째로 누락된다.
여기에 시차 문제가 겹친다. 도구가 널리 퍼지고, 조직이 업무 방식을 바꾸고, 그 결과가 시장에 출시되기까지는 시간이 걸린다. 과거 클라우드나 오픈소스가 그랬듯, 기반 기술의 효과는 몇 년에 걸쳐 서서히 드러나는 경우가 많다. '지금 당장 보이지 않는다'는 관찰과 '효과가 없다'는 결론 사이에는 상당한 간극이 있는 셈이다.
실무자가 가져갈 지점
한국의 개발 조직과 실무자에게 이 논의가 주는 함의는 분명하다. 첫째, AI 도입 효과를 '신규 출시 건수' 같은 단일 지표로 성급히 판단하지 말아야 한다. 유지보수 부담 감소, 레거시 코드 정리 속도, 신입 개발자의 온보딩 시간처럼 눈에 덜 띄는 영역에서 먼저 변화가 나타날 가능성이 크다. 둘째, 코딩 생산성을 높였다면 그다음 병목이 어디로 옮겨 갔는지를 봐야 한다. 코드가 빨리 나올수록 리뷰, 품질 관리, 유통의 부담은 오히려 커질 수 있다. 셋째, 회의론과 과신 모두 경계하되, 메이비스처럼 '이건 추측이며 신뢰도가 낮다'고 명시하는 태도를 참고할 만하다.
다만 원문 자체의 한계도 짚어 둘 필요가 있다. 이 글은 엄밀한 데이터나 사례 연구가 아니라, 가능한 설명들을 느슨하게 모아 둔 짧은 사색에 가깝다. 저자 스스로 여러 답에 낮은 가중치를 둔다고 밝힌 만큼, 특정 주장을 근거로 받아들이기보다는 질문을 다시 세우는 출발점으로 읽는 편이 적절하다. 'AI 코딩의 성과가 왜 체감되지 않는가'라는 물음은, 답을 서둘러 구하기 전에 우리가 무엇을 어떻게 재고 있는지부터 점검하라는 요구에 가깝다.