코딩은 자동화됐는데 소프트웨어는 왜 계속 나빠지는가

AI 코딩 도구가 실무의 표준으로 자리 잡은 지금, 역설적인 질문 하나가 떠오른다. 모델은 계속 좋아지고 개발팀의 평균적인 생산성도 올라갔다는데, 왜 우리가 매일 쓰는 소프트웨어의 체감 품질은 오히려 떨어지는 것처럼 느껴질까. 개발자 ptrchm는 이 질문을 정면으로 던진다. 그는 지금을 'AI가 유발한 집단적 열광' 상태로 묘사하며, 연말이면 코드의 100%를 AI가 작성할 것이라는 반복된 예언 속에서 많은 사람이 시장 가치를 선점하려 과도하게 몰두하고 있다고 말한다. 도구가 준 힘 자체는 부정하지 않는다. 다만 그 힘을 '더 나은 소프트웨어를 만드는 데' 쓰고 있지 않다는 것이 그의 핵심 문제 제기다.

버그는 도구의 문제가 아니다

흥미로운 지점은, 요즘 눈에 띄는 버그들을 만든 팀 대부분이 최신 모델과 넉넉한 토큰 예산에 접근할 수 있다는 저자의 추정이다. LLM은 기회만 주어지면 버그를 꽤 잘 잡는다. 그렇다면 문제는 도구의 성능이 아니라 그 도구를 어디에 겨누느냐에 있다. 즉 품질 저하는 기술의 한계라기보다 우선순위의 문제라는 것이다. 이는 한국의 실무자에게도 익숙한 상황이다. 코파일럿이나 에이전트형 도구를 도입하면 기능 개발 속도는 눈에 띄게 빨라지지만, 그 여력이 안정화나 회귀 버그 정리로 흘러가는 경우는 드물다.

저자는 과거 소프트웨어가 정말로 더 좋았는지에 대해서도 냉정하다. macOS 스노우 레퍼드 시절이 안정적이었다는 향수는 상당 부분 '선택적 기억'의 산물이라는 것이다. 옛날 소프트웨어가 나았다면 그것은 주로 훨씬 단순했기 때문이다. 그 이후 우리는 새로운 추상화 계층, 새로운 프런트엔드 프레임워크, 더 복잡한 인프라를 끊임없이 쌓아 올렸다. '사용자 경험'의 기준선은 계속 높아졌지만, 그만큼 시스템 전체는 점점 더 부서지기 쉬운 상태가 됐다. 저자가 이제 macOS나 자신이 의존하는 앱의 업데이트를 기대가 아니라 두려움의 대상으로 받아들이고, 새 버전이 더 나빠질 것이라 미리 예상하게 됐다는 대목은 이 취약함을 압축적으로 보여준다.

KPI가 안정성을 밀어낸다

저자가 지목하는 구조적 원인은 KPI 중심의 벤더 문화다. 무언가를 더 안정적으로 만드는 일은 숫자에 직접적인 영향을 주지 않을 때가 많고, 발표 자료에서도 매력적으로 보이지 않는다. '이번 분기에는 새 기능도, 리디자인도 없이 오직 버그 수정에만 집중하겠다'는 계획은 경영진 앞에서 좀처럼 통과되기 어렵다. 이 태도가 바뀌지 않는 한 소프트웨어 품질의 완만한 붕괴는 계속될 것이라는 게 그의 진단이다. 이 지점은 기술 도입의 성패가 결국 조직의 인센티브 설계에 달려 있음을 다시 확인시킨다. 아무리 강력한 도구가 주어져도, 안정성에 보상하지 않는 조직에서는 그 역량이 또 다른 기능 더미를 쌓는 데 쓰일 뿐이다.

다만 이 글의 성격을 오해하지 않는 것이 중요하다. 저자는 이것을 'AI 비판'이 아니라고 분명히 선을 긋는다. 돌아가는 GPU 팜이 우리에게 초능력을 줬다는 사실 자체는 인정한다. 그의 불만은 도구가 아니라 그 도구를 쓰는 방식과 우선순위를 향한다. 이 구분은 실무 논의에서도 의미가 있다. AI 도입 효과를 '기능 산출량'으로만 측정하는 지표 체계 아래에서는, 도구가 좋아질수록 오히려 복잡성과 부채가 더 빠르게 축적될 수 있다.

개인 개발자에게 열리는 틈

결론이 비관적으로만 들릴 수 있지만 저자의 전망은 오히려 반대다. 기업들이 집단적으로 'AI 부채' 속으로 빠져드는 사이, 개인 개발자에게는 예전이라면 손닿지 않았을 소프트웨어를 직접 만들 수 있는 독특한 기회가 열린다는 것이다. 그는 자기 차의 안드로이드 오토나 특정 벤더의 웹사이트에는 별 기대가 없다고 말하면서도, 바로 그 축적된 불만이 동력이 되어 일상적인 소프트웨어가 개선될 것이라 믿기로 선택한다. 이미 macOS와 윈도우의 현재 상태에 대한 일종의 '반란'이 나타나고 있고, 이 흐름이 스택 전반으로 번지기를 그는 기대한다.

이 글은 데이터나 벤치마크가 아니라 한 개발자의 관찰과 추정에 기댄 에세이라는 한계를 분명히 안고 있다. 품질 저하가 실제로 업계 전반의 추세인지, 아니면 개인의 체감인지는 이 글만으로 단정하기 어렵다. 그럼에도 한국의 개발 조직에 남기는 함의는 선명하다. 코딩 도구의 성능 경쟁에만 시선을 두는 대신, 확보한 여력을 어디에 배분할지, 안정성에 어떤 보상을 설계할지를 함께 묻지 않으면, 더 좋은 도구는 더 좋은 제품으로 이어지지 않는다. 도구는 이미 충분히 강력하다. 남은 문제는 그것을 겨누는 방향이다.