소프트웨어를 만드는 진입장벽은 무너졌지만, 의미 있는 무언가를 만드는 장벽은 그대로다. LLM 시대에 개인용·일회용 소프트웨어가 늘어나는 이유와 여전히 비싼 ‘소프트웨어’의 본질을 살펴본다.
#19·Jan 10, 2026·10 min read
소프트웨어를 만드는 진입장벽은 무너졌다. 하지만 의미 있는 무언가를 만드는 장벽은 단 1인치도 움직이지 않았다.
Claude Code와 Claude Opus 4.5가 이 열풍에 기름을 부었다. LLM 도구는 이전에도 있었지만, 지금은 그 어느 때보다 좋아졌고 그래서 훨씬 더 많은 사람이 주목하고 있다. 하지만 우리는 SaaS의 황금기에 들어서는 게 아니다. 우리는 개인적이고, 소모품 같은 소프트웨어의 시대로 들어서고 있다. 이때 엔지니어링은 코드를 쓰는 일에서 시스템을 빚어내는 일로 옮겨가며, 바로 그 이유 때문에 엔지니어는 여전히 필요하다.
Claude Code가 요즘 내 피드를 점령하고 있는데, 그럴 만한 이유가 있다. 흥미로운 점은 개발자들이 뛰어드는 것뿐만 아니라, 이전에는 Lovable이나 Replit 같은 플랫폼에 의존하던 “빌더(builder)”와 메이커들이 그쪽으로 이동하고 있다는 사실이다.
오해는 말자. 그런 도구들도 빠르게 출시하기에 여전히 완전히 유효하다. 하지만 사람들은 CLI 퍼스트 워크플로가 가진 고유한 아름다움을 다시 발견하면서, 분명한 전환이 일어나고 있다. 상호작용을 터미널로 옮기면 추상화 계층이 얇아진다. 관리형 UI가 정해준 해피 패스를 따라가는 게 아니라, 내가 직접 통제권을 가진다.
사람들은 실제로 이런 도구로 무엇을 만들고 있을까? 주변을 보면 답은 이렇다: 거의 모든 것. 사실 우리는 이미 포화 상태에 도달했다. 한편으로 우리는 소프트웨어 창작의 진정한 민주화를 목격하고 있다. 진입장벽은 사실상 붕괴했다. 처음으로 비개발자들이 소프트웨어의 소비자에 그치지 않고, 자신만의 도구를 설계하는 아키텍트가 되고 있다.
과거에는 특정 문제가 있으면 그걸 80%쯤 해결해주는 SaaS를 찾느라 몇 시간을 썼다. 오늘날 워크플로는 바뀌었다. 사람들은 CLI나 음성 인터페이스를 열고 필요한 걸 그냥 설명한다. 우리는 **“개인 소프트웨어(personal software)”**의 급증을 보고 있다:
이건 엄청난 변화다. 소프트웨어는 구매하는 상품이 아니라, 생성해 쓰는 개인 유틸리티가 되고 있다.
우리는 소프트웨어 개발의 새로운 시대로 들어서고 있는데, 목표가 항상 장기 존속인 것은 아니다. 수년간 업계는 “플랫폼”과 “생태계”를 만드는 데 집착해 왔지만, 흐름은 더 덧없고 일시적인 방향으로 옮겨가고 있다. 우리는 SaaS에서 스크래치패드로 이동 중이다.
이 새로운 소프트웨어의 상당수는 영원히 살기 위해 만들어지지 않는다. 오히려 그 반대다. 사람들은 점점 더, 특정하고 단일한 문제를 딱 한 번 정확히 해결하고는 그 도구를 버린다. 즉 소프트웨어는 장기적인 “나중”이 아니라 당장의 “지금”을 위한 일회용 유틸리티가 된다.
오늘날 이게 가능해진 배경에는 특정한 기술 철학이 있다: CLI 퍼스트 인터페이스, 로컬 데이터, 그리고 온보딩 제로. 가입하고, 데이터베이스를 설정하고, 복잡한 UI를 헤매는 마찰을 제거하면 도구를 만드는 비용은 너무 낮아져서, “임시”가 버그가 아니라 기능이 된다. 일회성 작업을 위해 5분 만에 맞춤 솔루션을 띄울 수 있다면, 굳이 지속될 필요가 없다.
전통적인 SaaS 모델과의 대비는 극명하다. SaaS는 본질적으로 유지율, 락인, 확장을 최적화하도록 설계된다. 사용자를 생태계 안에 묶어두고 점점 더 많은 영역을 쓰게 만드는 비즈니스 모델이다. 반면 맞춤형 도구는 즉시성과 통제권을 최적화한다. 이들은 고객 생애가치(LTV)에 관심이 없다. 오직 눈앞의 작업을 해결하는 데만 관심이 있다.
여러 면에서 이것은 스프레드시트가 원래 사용되던 방식으로의 회귀다. 스프레드시트를 열어 영구적인 수년짜리 데이터베이스를 만들지 않는다. 문제를 생각해보고, 계산하고, 결론을 낸 다음, 넘어가기 위한 스크래치패드로 쓴다.
이 새로운 지형에서 Claude Code는 개발자에게 엑셀이다. 즉 당장의 문제를 풀기 위한 강력하고 유연한 유틸리티다. 반면 창업자에게 영구적인 사업 기반을 제공하도록 만들어진 Shopify와는 다르다. 중요한 건 일을 끝내고, 그 다음엔 도구를 놓아주는 것이다.
그리고 이것이 다음 부분이 중요한 이유이기도 하다. 소프트웨어를 빠르게 생성하는 것과, 현실 세계와 맞닿았을 때 살아남게 만드는 것은 완전히 다른 문제다.
현재의 “AI 네이티브” 시대의 현실은 이렇다: 코드는 싸졌지만, 소프트웨어는 여전히 엄청나게 비싸다.
LLM은 코드 라인을 생성하는 비용을 사실상 죽여버렸지만, 문제를 진짜로 이해하는 비용은 건드리지 못했다. 우리는 “주말에 만든 앱”의 홍수를 보고 있지만, 그 대부분은 기본적인 CRUD와 서드파티 API 위에 얇게 감싼 래퍼에 불과하다. 트위터 데모에서는 멋져 보이지만, 현실의 마찰을 만나는 순간 자주 무너진다.
소프트웨어의 진짜 비용은 초기에 쓰는 비용이 아니다. 유지보수, 엣지 케이스, 쌓여가는 UX 부채, 데이터 소유권의 복잡성이 진짜 비용이다. 이런 “빠른” 솔루션은 취약하다.
구독 추적기는 은행이 CSV 내보내기 형식을 바꾸는 순간 망가진다. Chrome 확장 프로그램은 대상 웹사이트의 DOM이 조금만 바뀌어도 죽는다. 피트니스 앱은 사용자가 견고한 오프라인 지원이나 신뢰할 수 있는 데이터 동기화를 필요로 하는 순간 쓸 수 없게 된다.
최근 Hacker News, Reddit, Twitter에서 “소프트웨어 엔지니어링의 끝”에 대한 종말론을 많이 봤다. 하지만 그건 핵심을 완전히 놓친다. 우리는 직업의 끝을 목격하는 게 아니다. 우리는 그 직업의 새로운 시대로 들어서고 있다.
엔지니어의 가치는 문법의 “어떻게(how)”에서 시스템의 “무엇(what)”과 “왜(why)”로 이동하고 있다. 진짜 엔지니어링은 추상화와 아키텍처에 있다. 오래가는 시스템을 어떻게 구조화할지 아는 것, 왜 특정 레이트 리미팅 전략이 필요한지 이해하는 것, 분산 캐시를 어떻게 운영할지 아는 것, 그리고 환경 변수를 어디에 저장하면 안 되는지 정확히 아는 것.
AI가 강력하게 느껴지는 이유는 복잡성을 숨기기 때문이다. 하지만 엔지니어의 일은 그 복잡성을 무시하는 게 아니라 관리하는 것이다. 도구는 바뀌었지만, 엔지니어링의 엄격함에 대한 근본적인 요구는 그 어느 때보다 높다.
하지만 반대편도 있다. 진입장벽이 사라지면서 노이즈 수준은 사상 최고가 됐다. 내 피드는 지금 “AI 창업가”들이 오후 한나절에 만든 앱으로 **월 5자리 MRR(월 반복 매출)**을 올린다고 주장하는 글로 가득하다.
많은 경우 이런 주장은 상당히 의심스럽다. 기존 유통 채널도 없고 뚜렷한 **해자(moat)**도 없는 창작자가 주말 프로젝트로 MRR 1만 달러를 만들었다고 하면, 대개 비즈니스 현실을 반영했다기보다 참여(engagement)를 노린 경우가 많다.
이런 이야기들 중 일부는 거의 확실히 사실이겠지만, 대부분은 기술 혁신의 청사진이라기보다는 마케팅 사례 연구다. 이들이 성공하는 이유는 AI 코파일럿이 있어서가 아니라, 혼잡한 환경에서 주목을 끌어내는 기술을 마스터했기 때문이다.
우리는 코드 생성 능력이 더 이상 병목이 아닌 시대로 들어섰다. 진짜 도전은 유통으로 옮겨갔고, 더 중요한 것은 업계에 만연해진 “한탕주의”식 포즈와 진짜 유틸리티를 구분하는 일이다.
이 사람들은 비밀 지름길을 우연히 발견한 게 아니다. 단지 기존에 갖고 있던 이점을 더 빠르게 실행하는 방법을 찾았을 뿐이다(그리고 사이드 프로젝트 아이디어를 위해 코딩을 배우는 일이 너무 큰 부담이었기에, 애초에 그 이점을 AI로 ‘해금’했을 가능성도 있다).
이 전환을 이해하는 데 유용한 프레임이 있다: AI는 사실상 주요 차별점으로서의 ‘엔지니어링 레버리지’를 제거했다. 어떤 개발자든 LLM을 사용해 과거보다 훨씬 짧은 시간에 복잡한 기능을 만들고 배포할 수 있게 되면서, 코드를 쓰는 능력은 예전 같은 경쟁우위가 아니다. 이제 단지 “빌더”인 것만으로는 충분하지 않다.
대신 성공은 자동화하기 훨씬 어려운 요소에 달려 있다. 취향, 타이밍, 그리고 청중에 대한 깊고 직관적인 이해가 그 어느 때보다 중요하다. 주말에 제품을 만들 수는 있지만, 잘못된 것을 만들었거나 아무도 듣지 않는 방에 출시한다면 그건 무가치하다.
이 새로운 환경에서 코드는 쉬운 부분이 됐다. 어려운 부분은 예전과 똑같다: 사람들이 관심을 갖게 만드는 방법을 찾는 것.
먼저 지루하고 반복적인 문제에 묶여 있는 도메인 전문가들이 있다. 다음으로는 완성도가 아니라 즉시 동작이 중요한, 일회성 도구를 만드는 내부 팀들—스크립트나 내부 앱 같은 것들—이 있다. 파워 유저들도 큰 이득을 본다. 특히 취약하고 수동적인 워크플로를 더 견고한 무언가로 바꾸고 싶을 때 그렇다. 마지막으로, 번쩍이는 폴리시보다 솔루션의 소유권을 우선하는 엔지니어들에게도 승리다.
그리고 맞다 — Claude Opus 4.5, Claude Code, Cursor 같은 도구는 엔지니어에게 정말 유용하다. 보일러플레이트를 줄이고, 기능을 구현하고, 유닛 테스트를 쓰는 데 놀랄 만큼 좋다. 특히 최근 새 직장을 시작한 이후 내가 가장 좋아하는 사용 사례 중 하나는, 제품 코드베이스와 그 미묘한 동작 방식을 빠르게 따라잡기 위해 기능에 대한 개인화된 문서와 워크스루를 생성하는 것이다. 적응 속도를 올리는 데 정말 도움이 됐다.
하지만 현실은 이렇다: LLM은 코드를 완벽하게 쓰지 못한다 — 설령 처음에 컴파일이 된다 하더라도. 프롬프트 품질이 높고 규칙이 명확해도, 이 모델들은 여전히 실수를 한다. 매일 이런 도구를 쓰는 사람으로서 말하자면, 출력을 그대로 믿을 수는 없다. 동료가 올린 PR을 리뷰하듯 코드를 봐야 한다. 로직을 읽고, 가정을 점검하고, 종종 수동으로 수정해야 제대로 된다.
결국 이건 팀원에게 리뷰를 보낼 가능성이 크다(그리고 Code Rabbit도, 아마?). 내가 쓰지도 않았고 제대로 확인조차 하지 않은 걸 동료에게 리뷰시키는 게 공정한가?
이 도구들은 더 빠르게 움직이게 해주지만, 비판적인 시선이나 수년간 쌓은 경험을 대체하지 못한다. 그리고 당신보다 문제 공간 전체를 더 잘 이해하지도 못한다.
열풍은 우리가 SaaS의 황금기로 들어서는 것처럼 보이게 만든다. 하지만 아니다. 우리는 개인 소프트웨어의 시대로 들어서고 있다: 문제를 해결하기 위해 생성해 쓰고, 그리고 넘어가는 도구들.
20달러, 몇 시간의 여유 시간, 약간의 인내만 있으면 거의 누구나 기능하는 애플리케이션을 출시할 수 있다. 아이디어에서 작동하는 제품까지의 간극은 그 어느 때보다 좁아졌다.
이 새로운 현실에서 엔지니어링 전문성은 여전히 엄청난 가치를 가지지만, 역할의 성격은 바뀌고 있다. 중요성이 사라지는 게 아니다. 오히려 이 도구들을 활용해 이전에는 불가능했던 더 높은 레벨에서 구축하는 것이다. 진정한 전문성은 이제 이런 시스템을 조향하고, LLM이 현재 부족한 기술적 감독을 제공하는 데 필요하다.
AI는 코드 작성에는 분명 뛰어나지만, 유지보수 가능하고, 배포 가능하며, 확장 가능한 시스템을 아키텍처링하는 데는 여전히 약하다. 바로 여기서, 개발팀을 해고할 수 있다고 생각하는 비기술 리더들이 큰 실수를 한다. 이 논의를 무의미하게 만들어버릴 수준의 인공지능이 등장하기 전까지는, 기술 전문성이 프롬프트로 대체될 수 있다고 믿는 것은 전략적 오류다. 견고한 소프트웨어를 만드는 데는 이 기술의 기저 원리를 이해하는 인간이 여전히 필요하다.
결론은 하나다. 도구는 바뀌었지만, 좋은 엔지니어링의 기본은 바뀌지 않았다.
진입장벽은 사라졌을지 몰라도 — 판단, 취향, 책임은 여전히 일이다.
이 글이 도움이 되었길 바란다. 프로그래밍과 Elixir에 대한 더 과감한 견해와 의견을 보고 싶다면 Twitter와 Bluesky에서 팔로우해달라.
defer.to도 확인해 보자 — 요즘 내가 푹 빠진 것!
Share
© 2026 Chris Gregori
