# 소프트웨어 개발 비용이 90%나 감소했는가? > Clean Markdown view of GeekNews topic #24946. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=24946](https://news.hada.io/topic?id=24946) - GeekNews Markdown: [https://news.hada.io/topic/24946.md](https://news.hada.io/topic/24946.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-12-09T23:33:44+09:00 - Updated: 2025-12-09T23:33:44+09:00 - Original source: [martinalderson.com](https://martinalderson.com/posts/has-the-cost-of-software-just-dropped-90-percent/) - Points: 3 - Comments: 1 ## Topic Body - **에이전틱 코딩(Agentic Coding)** 도구의 등장으로 소프트웨어 개발의 **노동 비용이 급격히 감소**하고 있음 - 과거 한 달 걸리던 내부용 웹앱 프로젝트가 **일주일 내 완성**될 정도로 구현 속도가 단축됨 - **Claude Code** 등 도구가 수백 개의 테스트를 몇 시간 만에 생성하며, **소규모 팀이 대규모 성과**를 내는 구조로 변화 - 비용 하락은 **잠재 수요 폭발(Jevons Paradox)** 을 유발해 더 많은 조직이 맞춤형 소프트웨어를 제작하게 될 가능성 - 개발자의 **도메인 지식과 인간-에이전트 협업 능력**이 새로운 경쟁력으로 부상하며, 2026년 산업 전반의 급격한 전환 예상 --- ### 소프트웨어 개발 비용 구조의 변화 - 오픈소스 확산은 초기 소프트웨어 개발 비용을 낮춘 첫 번째 전환점이었음 - 과거 SQL Server, Oracle 등은 연간 수만 달러의 라이선스 비용이 필요했으나, **MySQL**은 무료로 네트워크 애플리케이션 구축 가능 - 이후 **클라우드 도입**은 초기 자본 지출을 줄였으나, 전체 비용 절감 효과는 제한적이었음 - 최근 수년간 **TDD, 마이크로서비스, 복잡한 React 프런트엔드, Kubernetes** 등으로 오히려 복잡성이 증가하며 비용 절감이 정체됨 - 반면 **AI 에이전트**는 개발 과정의 노동 비용을 대폭 축소함 ### 90% 절감의 근거 - 2025년 초까지는 AI 코딩 도구에 회의적이었으나, 최근 **에이전틱 코딩 CLI**가 실제로 대규모 효율을 입증 - 예시로, 한 내부 툴의 **300개 이상 테스트 코드**를 Claude Code가 몇 시간 만에 생성함 - 과거 한 달 걸리던 프로젝트가 **일주일 내 완료** 가능 - 구현 시간은 급감했으나 사고(설계) 시간은 동일 - 팀 규모 축소로 **커뮤니케이션 오버헤드가 사라짐** - 결과적으로 **소수 인원이 10배 이상의 생산성**을 달성 ### 잠재 수요의 폭발 - 비용 하락은 산업 전반의 수요를 줄이지 않고 오히려 확대시키는 **Jevons Paradox**로 설명됨 - 많은 조직이 여전히 **엑셀 기반 업무 프로세스**를 운영 중이며, 이를 SaaS 앱으로 전환할 잠재 수요 존재 - 기존 5만 달러 견적이 5천 달러 수준으로 낮아지면, **비필수 프로젝트도 개발 대상**이 됨 - 따라서 개발 산업 전반의 **총 생산량이 증가**할 가능성 ### 도메인 지식이 새로운 경쟁력 - 현재는 여전히 **인간의 감독과 판단**이 필수 - 에이전트의 접근 방식을 점검하고 잘못된 경로를 교정해야 함 - 이 기술을 숙달한 개발자는 **비즈니스 문제 해결 능력**이 크게 향상됨 - **도메인 지식 + 기술 숙련도**의 결합이 핵심 경쟁력으로 부상 - 비즈니스 전문가와 개발자가 **소규모 협업 단위**로 빠르게 반복 개발 가능 - 소프트웨어는 **‘버릴 수 있는 자산’** 으로 변하며, 잘못된 방향이면 즉시 폐기 후 재개발 가능 ### 변화에 대비해야 함 - **LLM과 에이전트 모델**은 빠르게 개선 중이며, 기존 벤치마크가 이를 반영하지 못함 - 예: **Opus 4.5**는 10~20분 세션을 안정적으로 유지 - 대규모 GPU 인프라 투자로 향후 모델 성능이 급격히 향상될 전망 - 일부 개발자들은 여전히 “LLM은 오류가 많다”거나 “시간 절약이 안 된다”고 주장하지만, 이는 **점점 사실이 아님** - 2007년 아이폰을 무시한 데스크톱 엔지니어 사례처럼, **변화를 거부하면 뒤처질 위험** 존재 - 대기업은 관료적 구조로 도입이 느리지만, **소규모 팀은 즉시 활용 가능** - LLM은 신규 프로젝트뿐 아니라 **기존 코드베이스 분석과 유지보수**에도 효과적 - 오래된 코드의 구조 이해, 버그 탐지, 수정 제안 등에서 높은 효율 - 결과적으로, **2026년은 개발 방식의 대전환 시점**이 될 가능성 큼 ## Comments ### Comment 47468 - Author: neo - Created: 2025-12-09T23:33:44+09:00 - Points: 1 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=46196228) - Claude Code가 몇 시간 만에 300개 이상의 테스트를 생성했다는 이야기를 들었음 하지만 그 테스트들이 정말 **의도한 동작을 검증**하고, 다음 개발자에게 시스템의 작동 방식을 명확히 전달할 수 있을지는 의문임 AI가 빠르게 코드를 만들어도, 그만큼 **세심한 검토 시간**을 들이지 않으면 품질이 떨어질 위험이 큼 - 나도 AI 코딩에 “적극적으로 적응해보라”는 조언을 따라봤음 하지만 로보틱스와 임베디드 쪽이라 그런지 웹앱이나 게임을 AI로 만드는 건 너무 **지루하고 답답한 경험**이었음 Cursor에게 문제를 고쳐달라 하면 오히려 더 엉망이 되었고, 결국 Flask와 JS를 직접 배우는 게 훨씬 효율적이었음 AI는 문서나 에러 메시지를 찾는 데는 훌륭했지만, **“운전대를 맡기는 것”** 은 전혀 도움이 안 되었음 - 나도 비슷한 경험을 했음 AI가 “10배 생산성”을 준다는 말이 맞는지 의심스러움 실제로는 **슈퍼차지된 Google/Stack Overflow**처럼 쓰는 게 현실적임 대부분의 코드는 내가 직접 짜고, AI는 단순 반복 작업이나 스크립트 작성 정도에만 도움을 줌 - AI에게 코드를 맡기는 건 **배워야 하는 기술**임 성공하려면 ‘멘토’처럼 명확히 지시하고 설명하는 능력이 필요함 직접 손대지 않고 프롬프트로 수정 요청을 하는 습관이 중요하며, 이 과정이 결국 **커뮤니케이션 능력**을 키워줌 - 이런 기사들을 보면, **현장 개발팀과 경영진의 인식 차이**가 명확히 드러남 위층 사람들은 몇 줄의 요구사항으로 전체 시스템을 이해했다고 착각하지만, 실제로는 의존성과 맥락을 거의 모름 좋은 개발팀이 그 모호한 요구를 실제 제품으로 바꾸는 게 진짜 예술인데, 그걸 자동화할 수 있는 기술은 아직 없음 - **단순한 코드 작성 비용**은 90% 줄었음 하지만 문제를 단순한 코드로 환원하는 데는 여전히 많은 **경험과 시간**이 필요함 - 대부분의 개발은 **레거시 코드 유지보수**임 Claude Code는 오래된 코드베이스를 이해하고 수정하는 데 탁월했음 테스트와 디버깅까지 도와줘서 생산성이 10배는 오른 느낌임 단순히 코드를 빨리 쓰는 게 아니라, **빠른 두 번째 두뇌**처럼 작동함 - 나도 AI 덕분에 예전엔 귀찮아서 안 하던 **작은 자동화 작업**들을 빠르게 처리하게 되었음 1시간 안에 스크립트나 미니 웹서비스를 만들어 문제를 해결할 수 있었음 - CRUD 앱 만드는 비용이 90% 줄었다는 말엔 동의하지만, 사실 이런 단순 작업은 **AI 이전에도 자동화**됐어야 했다고 생각함 - 복잡한 시스템도 결국 단순한 코드의 **층층이 쌓인 구조**임 LLM은 삽 하나에서 **굴착기 10대**로 업그레이드된 느낌이지만, 프로젝트가 실패할 거라면 단지 **더 빨리 실패**할 뿐임 - 코드가 단순하다는 건 결국 **온라인 예제 패턴**과 얼마나 유사한가의 문제임 Claude Code는 학습된 패턴 안에서는 복잡한 코드도 잘 작성함 - 만약 진짜로 **맞춤형 소프트웨어 개발 비용이 90% 줄었다면**, 시장에는 저가의 SaaS가 넘쳐야 하는데 현실은 그렇지 않음 결국 코드를 쓰는 게 가장 큰 문제는 아닌 듯함 - 맞음, **개발 이후의 운영 비용**이 훨씬 큼 유지보수, 보안, 업그레이드, 호스팅, 고객 지원, 새 기능 추가 등 이런 것들이 SaaS 구독료에 포함된 진짜 가치임 AI가 이 부분까지 해결하려면 아직 3~5년은 걸릴 것 같음 - 개발자의 실제 코딩 시간은 전체 업무의 절반 정도임 나머지는 회의, 조율, 대기 등으로 채워짐 설령 코딩 비용이 90% 줄어도 전체 비용은 절반 이상 남음 게다가 AI가 **자연어 요약조차 정확히 못하는데**, 코드의 의미를 완전히 이해하고 작성할 수 있을지 의문임 관련 영상: [YouTube 링크](https://www.youtube.com/watch?v=MrwJgDHJJoE) - 단순히 코드가 싸졌다고 **좋은 비즈니스**가 되는 건 아님 지금도 SaaS는 넘쳐나지만, 기능이 좋아도 사업은 어렵다는 게 현실임 - SaaS는 단순한 앱보다 **두세 배의 노력이 필요한 영역**임 많은 엔지니어링이 사실상 **벤더 락인**을 위한 작업임 - 시장이 완벽히 작동한다는 가정 자체가 틀림 **플랫폼 노출, 신뢰, 알고리즘 통제** 때문에 신생 SaaS는 성장하기 어려움 대기업이 금세 복제해버리고, 소비자들은 점점 돈이 없음 결국 시장은 공정하지 않으며, 그래서 많은 이들이 **정치적 영역**으로 눈을 돌리는 중임 - 대기업에서 일해본 사람이라면 이런 기사에 공감하지 못할 것임 예를 들어 Shutterstock 같은 곳은 단순한 요청도 **5개 시스템을 건드려야** 함 AI가 코드를 이해하고 수정하는 데 도움은 되지만, 전체 개발 비용이 90% 줄었다는 건 **전혀 사실이 아님** - 게다가 글쓴이는 “AI 개발 워크숍 강사”라서, 이 글은 사실상 **기업 대상 홍보용 글**에 가까움 - “모든 조직에는 수백 개의 Excel 시트가 있고, SaaS로 바꾸면 더 낫다”는 주장에 대해 정말로 **누구에게 더 나은가**를 묻고 싶음 스프레드시트는 도메인 지식을 가진 사람들이 직접 다룰 수 있고, 접근성도 높아서 여전히 강력한 도구임 - 나도 스프레드시트를 사랑하지만, **복잡도가 조금만 올라가도 오류**가 많아짐 수식과 UI가 밀접히 연결돼 있어서 내부 로직을 파악하기 어려움 - 스프레드시트는 강력하지만 **남용되기 쉬움** 특히 Excel은 유지보수가 어렵고, 복잡해질수록 **코드로 옮기는 게 낫다**고 생각함 - 글쓴이로서 말하자면, 모든 시트를 웹앱으로 만들자는 게 아니라 협업, 접근 제어, 테스트 같은 **구조적 보완**이 필요하다는 뜻이었음 - 문제는 언제 스프레드시트가 **한계를 넘었는지 인식하는 시점**임 데이터베이스처럼 쓰기 시작하거나, 여러 사용자가 동시에 다루기 시작하면 그때가 전환 시점임 - 대부분의 스프레드시트는 **원 제작자와 함께 사라짐** 공통 문제는 SAP 같은 솔루션이 해결하지만, 대부분의 시트는 **단 하나의 고객만 존재하는 맞춤형 문제**임 - **90/90 법칙**이 여전히 유효하다고 느낌 AI가 첫 90%를 빠르게 처리해주지만, 나머지 10%가 진짜 어려움 LLM은 **삽질 단계**에서는 유용하지만, 세밀한 마무리 단계에서는 오히려 방해가 됨 단순한 웹사이트 제작에는 마법처럼 느껴지겠지만, 그런 일은 앞으로 **생계가 되기 어려운 영역**일 것 같음 - 특히 **새로운 시나리오에서의 정확성**이 중요한 일일수록 AI의 한계가 드러남 생성된 결과를 멈추고 자세히 보면, 정말로 올바른지 의심스러움 - 많은 사람들이 여전히 AI를 **복붙용 챗봇**으로만 쓰는 게 놀라움 하지만 제대로 지시하면, Claude Code는 **몇 주 걸릴 실험을 몇 분 만에 재현**할 수 있음 실제 업무에서는 완벽한 코드보다 **결과를 빠르게 내는 것**이 중요함 물론 보안 버그나 비즈니스 로직 오류는 여전히 위험 요소임 도메인 전문가가 함께라면 이런 문제는 점점 줄어들 거라 생각함 - 하지만 빠른 결과만 추구하면 코드 품질이 급격히 떨어짐 **기능 개발과 코드베이스 관리의 균형**이 중요함 Cursor 같은 에이전트가 이 균형을 잘 잡는지는 아직 의문임 - LLM 붐 이후, Excel을 대체하려는 프로젝트에 참여한 적 있음 하지만 실제로는 **비전문가들이 AI로 앱을 만들려다 망한 사례**였음 데이터 분석가들이 Python 앱을 ‘바이브 코딩’으로 만들었지만, 상태 관리도 없고 구조도 엉망이었음 결국 고객 데이터가 엉뚱하게 처리되는 **재앙 수준의 결과**가 나왔음 이런 조직은 기술 인력이 없기 때문에, AI가 오히려 **위험을 가속화**함 - “포스트 LLM 시대의 Excel 현대화 프로젝트”라는 말 자체가 **섬뜩한 발상**처럼 들림