소프트웨어 개발 비용이 90%나 감소했는가?
(martinalderson.com)- 에이전틱 코딩(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년은 개발 방식의 대전환 시점이 될 가능성 큼
Hacker News 의견
-
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 링크 - 단순히 코드가 싸졌다고 좋은 비즈니스가 되는 건 아님
지금도 SaaS는 넘쳐나지만, 기능이 좋아도 사업은 어렵다는 게 현실임 - SaaS는 단순한 앱보다 두세 배의 노력이 필요한 영역임
많은 엔지니어링이 사실상 벤더 락인을 위한 작업임 - 시장이 완벽히 작동한다는 가정 자체가 틀림
플랫폼 노출, 신뢰, 알고리즘 통제 때문에 신생 SaaS는 성장하기 어려움
대기업이 금세 복제해버리고, 소비자들은 점점 돈이 없음
결국 시장은 공정하지 않으며, 그래서 많은 이들이 정치적 영역으로 눈을 돌리는 중임
- 맞음, 개발 이후의 운영 비용이 훨씬 큼
-
대기업에서 일해본 사람이라면 이런 기사에 공감하지 못할 것임
예를 들어 Shutterstock 같은 곳은 단순한 요청도 5개 시스템을 건드려야 함
AI가 코드를 이해하고 수정하는 데 도움은 되지만,
전체 개발 비용이 90% 줄었다는 건 전혀 사실이 아님- 게다가 글쓴이는 “AI 개발 워크숍 강사”라서,
이 글은 사실상 기업 대상 홍보용 글에 가까움
- 게다가 글쓴이는 “AI 개발 워크숍 강사”라서,
-
“모든 조직에는 수백 개의 Excel 시트가 있고, SaaS로 바꾸면 더 낫다”는 주장에 대해
정말로 누구에게 더 나은가를 묻고 싶음
스프레드시트는 도메인 지식을 가진 사람들이 직접 다룰 수 있고,
접근성도 높아서 여전히 강력한 도구임- 나도 스프레드시트를 사랑하지만, 복잡도가 조금만 올라가도 오류가 많아짐
수식과 UI가 밀접히 연결돼 있어서 내부 로직을 파악하기 어려움 - 스프레드시트는 강력하지만 남용되기 쉬움
특히 Excel은 유지보수가 어렵고, 복잡해질수록 코드로 옮기는 게 낫다고 생각함 - 글쓴이로서 말하자면, 모든 시트를 웹앱으로 만들자는 게 아니라
협업, 접근 제어, 테스트 같은 구조적 보완이 필요하다는 뜻이었음 - 문제는 언제 스프레드시트가 한계를 넘었는지 인식하는 시점임
데이터베이스처럼 쓰기 시작하거나, 여러 사용자가 동시에 다루기 시작하면 그때가 전환 시점임 - 대부분의 스프레드시트는 원 제작자와 함께 사라짐
공통 문제는 SAP 같은 솔루션이 해결하지만,
대부분의 시트는 단 하나의 고객만 존재하는 맞춤형 문제임
- 나도 스프레드시트를 사랑하지만, 복잡도가 조금만 올라가도 오류가 많아짐
-
90/90 법칙이 여전히 유효하다고 느낌
AI가 첫 90%를 빠르게 처리해주지만, 나머지 10%가 진짜 어려움
LLM은 삽질 단계에서는 유용하지만, 세밀한 마무리 단계에서는 오히려 방해가 됨
단순한 웹사이트 제작에는 마법처럼 느껴지겠지만,
그런 일은 앞으로 생계가 되기 어려운 영역일 것 같음- 특히 새로운 시나리오에서의 정확성이 중요한 일일수록 AI의 한계가 드러남
생성된 결과를 멈추고 자세히 보면, 정말로 올바른지 의심스러움
- 특히 새로운 시나리오에서의 정확성이 중요한 일일수록 AI의 한계가 드러남
-
많은 사람들이 여전히 AI를 복붙용 챗봇으로만 쓰는 게 놀라움
하지만 제대로 지시하면, Claude Code는 몇 주 걸릴 실험을 몇 분 만에 재현할 수 있음
실제 업무에서는 완벽한 코드보다 결과를 빠르게 내는 것이 중요함
물론 보안 버그나 비즈니스 로직 오류는 여전히 위험 요소임
도메인 전문가가 함께라면 이런 문제는 점점 줄어들 거라 생각함- 하지만 빠른 결과만 추구하면 코드 품질이 급격히 떨어짐
기능 개발과 코드베이스 관리의 균형이 중요함
Cursor 같은 에이전트가 이 균형을 잘 잡는지는 아직 의문임
- 하지만 빠른 결과만 추구하면 코드 품질이 급격히 떨어짐
-
LLM 붐 이후, Excel을 대체하려는 프로젝트에 참여한 적 있음
하지만 실제로는 비전문가들이 AI로 앱을 만들려다 망한 사례였음
데이터 분석가들이 Python 앱을 ‘바이브 코딩’으로 만들었지만,
상태 관리도 없고 구조도 엉망이었음
결국 고객 데이터가 엉뚱하게 처리되는 재앙 수준의 결과가 나왔음
이런 조직은 기술 인력이 없기 때문에, AI가 오히려 위험을 가속화함- “포스트 LLM 시대의 Excel 현대화 프로젝트”라는 말 자체가 섬뜩한 발상처럼 들림