AI는 좋아졌는데 소프트웨어는 그대로다 (AI Got Better While I Was Away. Software Didn't.)
코드 생성 도구는 빠르게 좋아졌지만 과잉 설계와 불필요한 복잡도는 그대로입니다. 저자는 이제 개발자에게 필요한 능력이 코드 작성이 아니라 판단력과 '취향'이라고 말합니다.
AI Got Better While I Was Away. Software Didn't.
I haven't written here in a while. Not because I ran out of opinions. That would be concerning. I...
개요 #
Dev.to 필자 NorthernDev가 한동안 쉬었던 글쓰기를 다시 시작하면서 한 문장으로 요약한 소감이 있습니다. "AI는 좋아졌다. 소프트웨어는 아니다."
저자가 글을 멈춘 건 할 말이 없어서가 아니었습니다. "AI가 개발자를 대체한다", "절대 대체하지 못한다", "이 모델이 모든 걸 바꾼다", "소프트웨어 엔지니어링은 끝났다" 같은 말이 끝없이 반복되는 데 지쳤다고 합니다. 그 사이에도 AI는 계속 발전했습니다. 모델도, 코딩 에이전트도 좋아졌고, 오후 반나절에 만들어 낼 수 있는 코드 양은 1년 전과 비교도 안 될 만큼 늘었습니다.
그런데 현장은 별로 달라지지 않았다는 게 저자의 관찰입니다. 과하게 설계된 백엔드, 단순한 DB 호출 하나를 일곱 겹으로 감싼 추상화, 의존성 지옥, 아무도 요청하지 않은 기능, 있지도 않은 문제를 푸는 마이크로서비스가 여전히 남아 있습니다. 저자는 이렇게 묻습니다. 애초에 코드 생성이 병목이었던 적이 있었나, 우리가 그렇게 믿고 싶었던 것뿐 아닌가.
본문 #
어려운 건 늘 코드 작성이 아니었다 #
개발자들은 구현을 타이핑하는 일에 가치가 몰려 있는 것처럼 말하곤 합니다. 저자 생각은 다릅니다. 정말 어려운 건 늘 다음 질문에 답하는 일이었다는 거죠.
- 이게 정말 있어야 하는가?
- 이게 맞는 해법인가?
- 진짜 문제를 풀고 있는가?
- 레이어를 하나 더 얹어야 하는가?
- 차라리 지워도 되지 않는가?
AI는 커피 한 잔 마시는 동안 그럴듯해 보이는 코드 600줄을 내놓습니다. 그렇다고 그 600줄이 존재해야 한다는 뜻은 아닙니다. 저자가 위험하다고 보는 지점이 여기입니다. AI는 마찰을 없애 주는데, 그 마찰이 때로는 우리를 나쁜 아이디어에서 지켜 줬다는 겁니다. 예전엔 쓸데없이 복잡한 시스템을 만들려면 적어도 그만큼 고생을 해야 했습니다. 지금은 에이전트가 신이 나서 그 재앙을 통째로 같이 지어 줍니다.
과잉 설계를 너무 잘 도와주는 AI #
AI에게 뭔가를 해결해 달라고 하면 대개 도움이 되려고 애씁니다. 지나칠 정도로요. 작은 기능 하나를 요청했는데 어느새 서비스 레이어, 리포지토리 패턴, 의존성 주입, 검증 추상화, 재시도 로직, 설정 객체, 인터페이스 세 개, 팩토리까지 생겨 있습니다.
하나하나 보면 다 그럴듯합니다. 저자는 바로 그게 문제라고 짚습니다. 나쁜 소프트웨어는 처음부터 대놓고 이상해 보이는 결정에서 시작하지 않습니다. 각각은 합리적으로 보이는 결정이 쌓이면서 만들어집니다. 그리고 이제 AI는 그런 결정을 우리가 후회하는 속도보다 훨씬 빠르게 만들어 냅니다.
AI가 좋아질수록 지루한 소프트웨어가 좋다 #
저자는 예전 글에서 자신의 2026년 기술 스택이 "지루하기 짝이 없다"고 쓴 적이 있습니다. 지금은 그 생각이 더 확고해졌다고 합니다. 구현을 AI가 더 많이 맡게 된다면, 그 주변 시스템은 지겨울 만큼 예측 가능해야 한다는 이유에서입니다.
저자가 원하는 건 이런 것들입니다.
- 지루한 데이터베이스
- 지루한 API와 프레임워크
- 지루한 배포
- 한눈에 보이는 아키텍처
- 다이어그램을 설명하는 다이어그램 없이도 다른 사람이 읽을 수 있는 코드
스택이 흥미로울 필요는 없고, 흥미로워야 하는 건 제품이라는 게 저자의 말입니다. 그리고 우리가 이 차이를 조금 잊고 있다고 지적합니다.
코드는 싸지고 있다 #
저자는 일부 독자가 불편해할 이야기라고 미리 밝히면서, 코드 자체의 가치가 낮아지고 있다고 말합니다. 쓸모없어지는 게 아니라 덜 귀해지는 겁니다. 코드를 만들어 내는 능력은 무섭게 빠른 속도로 범용화되고 있습니다.
다만 개발자가 쓸모없어진다는 뜻은 아니라고 선을 긋습니다. 개발에서 가치 있는 부분이 다른 곳으로 옮겨 가고 있다는 겁니다. 저자가 꼽는 영역은 판단력, 아키텍처, 디버깅, 제품 관점의 사고, 그리고 무엇을 거절할지, AI가 자신 있게 틀린 순간이 언제인지, 아예 구현하지 않는 게 정답인 때가 언제인지 알아보는 능력입니다.
그중에서도 저자는 '취향(taste)'이 가장 중요한 엔지니어링 역량이 될 거라고 봅니다. 문제는 측정하기가 몹시 어렵다는 점입니다. 그래도 그런 사람과 일해 보면 바로 알 수 있다고 합니다. 그들은 뭔가를 지우고, 단순하게 만들고, 귀찮은 질문을 던지고, 내가 짠 14단계짜리 기발한 해법을 지루한 다섯 줄로 바꿔 놓습니다. 저자는 AI 비중이 커지는 세상에서 이런 사람들이 크게 빛을 볼 거라고 내다봅니다.
Photo by 모자란 건 코드가 아니라 좋은 결정 #
저자가 계속 되돌아오는 지점은 이것입니다. 우리는 코드가 부족했던 적이 없습니다. GitHub이 "제발 누가 자바스크립트 좀 더 써 주세요"라고 애원하고 있지는 않으니까요.
부족한 건 좋은 결정입니다. AI는 더 많은 결과물, 더 많은 구현, 더 많은 선택지와 프로토타입과 코드를 줍니다. 훌륭한 일이지만, 많다고 저절로 더 좋은 건 아닙니다. 때로는 그냥 많을 뿐입니다.
저자는 개발자가 생성된 결과물을 걸러 내는 능력을 키우지 못하면, 인류가 만든 가장 강력한 개발 도구로 역사상 가장 거대한 평범한 소프트웨어 더미를 쌓게 될 수 있다고 경고합니다. 그것도 아주 효율적으로요.
반(反) AI 글이 아니다 #
저자는 이 글이 AI를 반대하는 글이 아니라고 분명히 합니다. 오히려 코딩, 디버깅, 리서치, 글쓰기, 아이디어 탐색, 자기 해법 검증까지 AI를 늘 쓰고 있고, 예전으로 돌아가고 싶지도 않다고 말합니다.
다만 "AI가 기능 하나를 통째로 짰다"는 말에 예전만큼 감탄하지는 않는다고 합니다. 이제는 이런 질문이 더 중요해졌습니다.
- 그게 맞는 기능이었나?
- 유지보수할 수 있는 코드인가?
- 생성된 코드를 이해했나?
- 필요 없는 복잡도를 더하지는 않았나?
- 직접 설계했어도 그렇게 했을까?
개발자의 일은 원래 코드 작성이 아니었을지도 #
저자는 코드 작성이 그저 눈에 가장 잘 띄는 부분이었을 수 있다고 말합니다. 개발자의 진짜 일은 불확실한 상황에서 결정을 내리고, 시스템을 이해하고, 트레이드오프를 따지고, 동작하는 가장 단순한 방법을 찾는 것이었다는 겁니다. 그리고 가끔은 모두에게 이렇게 말하는 일이기도 합니다.
아뇨. 이건 절대로 Kubernetes가 필요 없습니다.
AI는 우리 누구도 손으로는 다 쓸 수 없을 만큼 많은 소프트웨어를 만들어 낼 수 있고, 그 부분은 이미 해결됐습니다. 저자가 보기에 남은 질문은 어떤 소프트웨어가 존재할 가치가 있는지를 우리가 더 잘 판단하게 됐느냐입니다. 여기엔 확신이 서지 않는다고 하면서, 그게 AI가 프로그래머를 대체하는 것보다 훨씬 큰 문제일 수 있다고 덧붙입니다.
글은 독자에게 던지는 질문으로 끝납니다. AI는 개발자를 더 나은 엔지니어로 만드는가, 아니면 원래 만들려던 것을 더 빨리 만들게 할 뿐인가?
이 글은 위 출처를 바탕으로 한국 독자를 위해 재작성한 기사입니다. 원문의 사실과 수치에 근거하며, 별도의 견해를 포함하지 않습니다.