내가 쉬는 동안 AI는 나아졌지만, 소프트웨어는 그대로입니다

AI 요약

글쓴이는 한동안 글쓰기를 멈췄다가 돌아와 보니 AI 모델과 코딩 에이전트는 발전했지만 소프트웨어 개발의 문제는 그대로라고 말합니다. 오후 한나절에 만들 수 있는 코드의 양은 1년 전과 비교하기 어려울 만큼 늘었습니다. 그런데도 과하게 복잡한 백엔드, 단순한 데이터베이스 호출을 둘러싼 여러 추상화, 의존성 문제, 요청받지 않은 기능, 존재하지 않던 문제를 푸는 마이크로서비스는 여전히 생깁니다. 팀이 복잡성을 더 빠르게 배포할 뿐이라면 코드 생성 속도가 병목은 아니었다는 주장입니다.

코드보다 결정이 어렵습니다

글쓴이가 꼽는 어려운 일은 코드 타이핑이 아닙니다. 기능이 정말 필요한지, 문제를 제대로 해결하는지, 계층을 하나 더 만들 이유가 있는지, 오히려 삭제해야 하는지를 판단하는 일입니다. AI는 커피가 식기도 전에 그럴듯한 코드 600줄을 만들어낼 수 있지만, 그 코드가 존재해야 한다는 뜻은 아닙니다.

코드를 직접 만드는 데 드는 마찰은 때로 나쁜 아이디어를 실행하기 전에 멈춰 세웠습니다. 지금은 AI 에이전트가 작은 기능 요청에도 서비스 계층, 저장소 패턴, 의존성 주입, 검증 추상화, 재시도 로직, 설정 객체, 여러 인터페이스와 팩토리를 덧붙일 수 있습니다. 각각은 그럴듯한 선택처럼 보입니다. 문제는 나쁜 소프트웨어가 대개 명백히 어리석은 결정 하나가 아니라, 따로 보면 합리적인 결정들이 쌓여 만들어진다는 점입니다. AI는 그 결정을 사람이 후회하기도 전에 빠르게 구현합니다.

지루하고 예측 가능한 시스템

AI가 구현을 더 많이 맡을수록 주변 시스템은 단순하고 예측 가능해야 한다고 글쓴이는 말합니다. 데이터베이스, API, 프레임워크, 배포 방식은 굳이 흥미로울 필요가 없습니다. 아키텍처는 명확하고, 다이어그램을 위한 다이어그램 없이도 다른 개발자가 코드를 이해할 수 있어야 합니다. 스택이 흥미로운 것보다 제품이 흥미로운 편이 낫다는 주장입니다.

글쓴이는 코드 자체의 가치가 사라지는 게 아니라, 코드 생산 능력이 빠르게 값싼 자원이 되고 있다고 봅니다. 이에 따라 가치가 이동하는 곳은 판단력, 아키텍처, 디버깅, 제품 감각, 취향, 잘못된 결과를 거부하는 능력입니다. 특히 구현을 아예 하지 않는 편이 낫다는 점을 알아채는 능력을 강조합니다. 좋은 엔지니어는 복잡한 14단계 해결책을 다섯 줄로 줄이고, 불필요한 부분을 제거합니다.

더 많은 코드가 더 나은 소프트웨어는 아닙니다

글쓴이는 AI를 코딩, 디버깅, 조사, 글쓰기, 아이디어 탐색에 사용하며 AI를 반대하는 것은 아니라고 밝힙니다. 다만 AI가 기능 전체를 작성했다는 말만으로는 감탄하지 않습니다. 올바른 기능인지, 유지보수할 수 있는지, 생성된 코드를 이해했는지, 불필요한 복잡성을 더하지 않았는지 확인해야 합니다.

AI는 구현과 선택지를 늘리지만, 더 많은 결과물이 자동으로 더 좋은 결과를 뜻하지는 않습니다. 생성된 결과를 걸러내지 못하면 강력한 개발 도구로 역사상 가장 큰 평범한 소프트웨어 더미를 효율적으로 만들 수 있다고 경고합니다. AI가 개발자를 대체하는가보다, 개발자가 어떤 소프트웨어를 만들어야 하는지 더 잘 판단하는가가 더 큰 질문이라고 글을 맺습니다.

dev.to 반응

• @sylwia-lask — 돌아오신 것을 환영합니다!!! “존재하지도 않던 문제를 해결하는 마이크로서비스”라는 문장이 정말 와닿았습니다 🤣
  • @the_nortern_dev — 감사합니다! 😂 지금 이 순간에도 어딘가에서는 연락처 양식 하나 처리하려고 마이크로서비스 11개를 배포하는 팀이 있겠네요.
• @leob — “가치는 코드에 있지 않다”는 말도 좋지만, 문서 같은 다른 결과물에도 코드만큼, 아니 그보다 더 많은 정성을 쏟지 않는다면 코드는 여전히 제품입니다. 제 생각에는 그렇게 하지 않으니까요. “어쩌면 직업은 코드를 작성하는 일이 아니었을지도 모릅니다”라고 하지만, 결국 평가받는 건 코드입니다. AI가 쓴 코드는 항상 그런 건 아니지만 사람이 쓴 코드보다 과하게 설계된 경우가 많았습니다. 대부분의 코드를 AI가 작성하게 되는 일이 불가피하다면, AI에게 “이 과하게 설계된 코드를 단순하게 만들어 주세요”라고 요청하는 사람이 가장 중요한 일을 하게 될 것 같습니다. 추상적인 기술이 코드 타이핑보다 중요하다는 점에는 동의합니다. 하지만 처음부터 코드를 배운 적이 없다면 AI가 만든 코드가 말이 되는지 어떻게 검토하겠습니까? 직접 코드를 써보지 않으면 제대로 읽는 법도 모릅니다. 또 그런 추상적인 기술은 허공에서 생기지 않습니다. 직접 코드를 쓰고 실행하고 디버깅하는 일이 그 기술을 기르는 가장 좋은 방법 가운데 하나입니다. 생각과 구현을 전부 AI에 맡기면 기술의 기본과 기초를 잊거나 익히지 못할 수 있습니다. “코드 작성은 이제 중요하지 않다”는 생각에 대한 반론으로, 저는 여전히 일부 코드는 직접 쓰자고 말하고 싶습니다.
  • @the_nortern_dev — 중요한 뉘앙스라고 생각합니다. 코드를 배우는 일이 더는 중요하지 않다고 말하려는 뜻은 아닙니다. 오히려 코드를 직접 읽고 디버깅하고 추론할 수 없다면 AI가 준 결과를 판단하기 어렵습니다. 코드 생산 비용은 낮아지지만, 그 코드가 필요한지, 지나치게 복잡하지는 않은지, 실제 문제를 해결하는지 이해하는 능력의 가치는 커진다는 뜻입니다. 과잉 설계에 관한 말씀에도 전적으로 동의합니다. “단순하게 해주세요”가 지금 소프트웨어 개발에서 가장 유용한 프롬프트 가운데 하나일지도 모릅니다. 다만 초보 개발자가 손으로 해보는 고된 작업을 너무 건너뛰면 어떻게 될지는 아직 모르겠습니다. 많은 엔지니어링 판단력은 나쁜 코드를 쓰고, 디버깅하고, 후회하면서 왜 나쁜지 배운 데서 나왔습니다.
  • @leob — 마지막 말씀을 특히 포함해 전부 동의합니다. 주니어는 기본기와 실무 기술을 배워야 합니다. 여기에는 전통적인 방식으로 코드를 쓰는 일뿐 아니라 데이터베이스, 웹 프로토콜(HTTP), HTML/CSS/JS 같은 기초도 들어갑니다. 그래야 AI가 만든 결과를 검토하고 판단할 수 있습니다. 우리는 지식이 줄어드는 게 아니라 더 많이 알아야 할 겁니다. 기준도 낮아지는 게 아니라 높아진다고 생각합니다.
  • @the_nortern_dev — 정확합니다. 많은 사람이 과소평가하는 부분이라고 생각합니다. AI는 코드를 만드는 문턱을 낮추지만, 좋은 엔지니어가 되기 위한 기준은 오히려 높일 수 있습니다. 구현을 더 많이 자동 생성할수록 잘못된 가정, 취약한 추상화, 미묘한 실수를 찾아낼 만큼 시스템을 깊이 이해해야 합니다. 아이러니하게도 AI 시대에는 탄탄한 기본기가 더 큰 보상을 받을 수 있습니다. 무서운 점은 실제로 이해하지 못하면서도 생산적으로 보이기가 훨씬 쉬워진다는 것입니다.
  • @leob — “무서운 점은 실제로 무엇을 만드는지 이해하지 못하면서도 생산적으로 보이기가 훨씬 쉬워진다는 것입니다.” 바로 이 말입니다.
  • @the_nortern_dev — 어쩌면 이 문장을 중심으로 글 전체를 썼어야 했겠네요.
  • @leob — 네, 코딩 AI의 가장 큰 위험이나 단점은 이 부분이라고 생각합니다. 속도와 코드는 늘지만 이해는 줄어듭니다. AI가 만든 결과를 검토해야 하지만, 전부 직접 검토하다 보면 감당하기 어려워질 수 있습니다. 언젠가는 검토에도 AI를 써야 할 것 같습니다. AI가 처음 만든 문제를 AI가 해결하도록 하는 셈일지도 모르겠네요 ;-)
  • @the_nortern_dev — 맞습니다 😂 AI가 검토 부채를 만들고 나서 자기가 치우겠다고 나서는 모습은 아주 AI답네요. 위험은 “AI가 AI를 검토했다”는 말만으로 안심하고, 아무도 시스템을 실제로 이해하지 않게 되는 데 있다고 생각합니다. 결국 “이게 왜 작동하는지 압니다”라고 말할 사람은 필요합니다.
  • @leob — 맞습니다. AI 도구는 “승인합니다” 또는 “거부합니다”만 말해서는 안 됩니다. 무엇을 어떻게 검토했고 어떤 문제가 있는지 자세히 설명해야 합니다. 개발자는 그 설명을 검토해야 하며, 그러려면 말씀하신 맥락을 깊이 알아야 합니다. 마지막 승인이나 거부는 AI가 아니라 사람이 해야 합니다. 건초 더미에서 바늘을 찾는 일과 같으니 AI가 코드 검토의 고된 작업을 돕는 형태는 불가피해 보입니다.
  • @the_nortern_dev — 네, 정확합니다. 아마 그런 방향으로 갈 것 같습니다. AI가 1차 검토를 하고 의심스러운 부분을 찾아 문제일 수 있는 이유를 설명한 뒤, 사람이 최종 판단을 내리는 방식입니다. 그렇지 않으면 AI가 코드를 쓰고 AI가 검토하고, 사람은 아무도 실제로 이해하지 못하는 시스템에 “승인”만 누르게 됩니다 😅 바늘 찾기 문제가 현실적이기는 합니다. 규모가 커지면 모든 코드를 사람이 직접 검토하는 일은 더 이상 현실적이지 않습니다.
• @gramli — 돌아오신 것을 환영합니다! NorthernDev가 어디로 사라졌는지 궁금했습니다 😂 AI 생성 코드와 바이브 코딩의 실제 영향은 앞으로 몇 년 안에, 아니면 변화 속도를 보면 더 빨리 드러날 것 같습니다. 기존 프로젝트는 이미 AI로 유지보수하고 있지만, 코드 대부분은 사람이 처음 작성했습니다. 한편 기업들은 AI 생성 코드로 완전히 새로운 제품을 만들고 출시하고 있습니다. 그런 프로젝트가 얼마나 유지보수하기 쉬울지, 얼마나 큰 난장판이 될지는 몇 년 뒤에야 알 수 있겠지요.
  • @the_nortern_dev — 감사합니다 😂 인터넷에서 잠시 겨울잠을 자야 했나 봅니다. 저도 바로 그 점이 가장 궁금합니다. 지금 “AI가 실무에서 잘 작동한다”는 증거 상당수는 사람이 아키텍처 대부분을 만들고 AI가 구현과 유지보수를 돕는 프로젝트에서 나옵니다. 진짜 시험대는 처음부터 AI 비중이 높았던 프로젝트일 겁니다. 빠르게 출시하는지가 아니라, 18~36개월 동안 변경과 예외 상황, 직원 교체, 쌓여가는 “합리적인” 결정들을 겪은 뒤 어떻게 되는지가 관건입니다. 그때 AI가 소프트웨어 개발 비용을 낮췄는지, 아니면 비용을 미래로 미뤘는지 알게 될 겁니다.
• @rahul_r15 — 흥미로운 관점입니다! AI가 어느 때보다 많은 코드를 만들고 있는데, 생성된 해결책을 언제 신뢰하고 언제 멈춰서 설계를 직접 단순하게 해야 하는지 어떻게 판단하시나요?
  • @the_nortern_dev — 좋은 질문입니다. 저는 설계 결정에 비해 구현 세부 사항을 AI에게 더 맡기는 편입니다. 문제가 이미 분명하고 아키텍처가 단순하다면 AI가 빠르게 작업하도록 둡니다. 하지만 요청하지 않은 새로운 추상화나 계층, 의존성, 복잡성이 생기기 시작하면 멈춰 봅니다. 대략적인 기준은 생성된 설계를 몇 문장으로 설명할 수 없다면 지나치게 복잡할 가능성이 높다는 것입니다. “실제 문제를 해결하면서도 가능한 가장 단순한 형태는 무엇인가?”라는 평범한 질문도 자주 합니다. AI는 해결책을 잘 제시하지만, 적절한 규모의 해결책인지 판단하는 일은 여전히 사람이 해야 합니다.
• @alkaznodemaven — AI가 만들면 불필요한 복잡성도 얼마나 그럴듯해 보이는지가 무섭습니다. 이름도 깔끔하고 인터페이스와 구조도 제대로 갖췄는데, 알고 보면 함수 하나로 끝날 일이기도 합니다. AI를 많이 쓰지만, AI가 쓴 것의 절반을 삭제하는 일도 점점 기술이 되고 있습니다 😅
• @koda2026 — 현재 AI 개발 환경을 가장 정확하게 평가한 글 가운데 하나입니다. AI가 과잉 설계를 아주 잘 돕는다는 말이 딱 맞습니다. RAM 4GB에 3G 연결도 불안정한 150달러짜리 안드로이드폰 같은 제약된 하드웨어에서는 과잉 설계가 나쁜 아키텍처 선택에 그치지 않고 치명적인 문제가 됩니다. 하드웨어가 그런 “지나치게 친절한” 추상화와 14단계 마이크로서비스 구조를 물리적으로 거부합니다. 그래서 “지루한 스택”이 돌아오는 것입니다. 제약은 올바른 질문을 하게 합니다. “계층을 하나 더 만들어야 하나?”, “그냥 삭제할 수는 없나?” 같은 질문입니다. 개발자가 기본기를 배워야 한다는 대화에도 전적으로 동의합니다. 내부 작동 원리를 이해하지 못하면 AI 생성 코드를 제대로 검토하고, 디버깅하고, 단순화할 수 없습니다. 그래서 저는 에이전트에게 “작동하게 해줘”라고만 요청하는 대신 보안 JS 샌드박스와 실행 경계를 직접 만드는 데 시간을 씁니다. 지금 가장 가치 있는 기술은 프롬프트 작성이 아니라 편집입니다. 600줄의 그럴듯한 코드 가운데 문제를 해결하지 않는 500줄을 자신 있게 지울 줄 아는 능력입니다.
• @danielchinasz — 이 글은 많은 사람이 생각하지만 말하기 꺼리는 점을 솔직하게 말합니다. “코드 생성은 처음부터 병목이 아니었다”는 말이 글의 핵심입니다. 소프트웨어 개발을 늦추는 진짜 요인은 “이걸 해야 하는가”와 “어떻게 해야 하는가”입니다. AI는 가장 쉬운 일을 거의 무료로 만들었지만, 가장 어려운 일의 비용은 더 커졌습니다. “마찰이 우리를 보호했다”는 관점도 흥미롭습니다. 예전에는 과도하게 설계하려면 적어도 직접 노력해야 했지만, 이제 에이전트는 인터페이스 세 개와 팩토리까지 더하며 기꺼이 난장판을 완성합니다. 위험은 AI가 아니라 AI가 우리의 나쁜 판단을 증폭한다는 데 있습니다. “취향이 핵심 경쟁력이 될 것”이라는 말도 맞습니다. 이력서에 적기 어렵지만, 언제 코드를 작성하지 말아야 하는지 아는 능력은 점점 드물어집니다. 다만 “소프트웨어는 나아지지 않았다”는 주장은 조금 비관적일 수 있습니다. AI는 프로토타입 제작 비용을 낮춰 더 많은 아이디어를 빠르게 시험하고 폐기하게 합니다. 그것도 취향을 다듬는 방법일 수 있습니다. 문제는 도구가 아니라 새 도구를 쓰면서도 “많을수록 좋다”는 오래된 관념을 유지하는 사람들입니다. AI가 자동으로 사람을 더 나은 엔지니어로 만들지는 않겠지만 격차를 벌릴 것입니다. 판단력이 좋은 사람은 더 강해지고, 그렇지 않은 사람은 기술 부채만 더 빠르게 쌓을 겁니다. 도구는 사람을 증폭할 뿐 바꾸지는 않습니다.

원문: dev.to / 번역·요약: Trawling