소프트웨어가 세상을 집어삼킨 뒤, 이제 AI 에이전트가 SaaS 수요와 경제성을 어떻게 바꾸고 있는지, 유지보수 반론과 방어 가능한 해자, 위험한 영역을 살펴본다.
URL: https://martinalderson.com/posts/ai-agents-are-starting-to-eat-saas/
우리는 15년 동안 소프트웨어가 세상을 먹는 것을 지켜봤다. 리테일, 미디어, 금융 등 온갖 산업이 소프트웨어에 의해 집어삼켜졌다. 지난 20여 년 동안 SaaS 도구가 폭발적으로 늘어나며 엄청난 수준의 파괴적 변화가 일어났다. 그 결과 수조 달러 가치로 평가되는 방대한 규모의 SaaS 기업군이 만들어졌다.
지난 글에서 AI 코딩 에이전트로 인해 소프트웨어 비용이 90% 떨어졌는가를 논할 때는 주로 시장의 공급 측면을 살폈다. 만약 이 가설이 현실이 된다면 SaaS 도구에 대한 수요는 어떻게 될까? 소프트웨어 엔지니어링의 변화가 낳는 2차, 3차 효과를 나는 계속 많이 생각해 왔다.
만들까(build) 살까(buy)라는 계산식이 바뀌기 시작했다. 소프트웨어가 세상을 먹었다. 에이전트가 SaaS를 먹을 것이다.
가장 분명한 시작점은, 특히 “단순한” SaaS 도구에서 수요가 그냥 증발하기 시작했다는 점이다. 많은 소프트웨어 엔지니어가 이미 체감하기 시작했을 거라고 본다. 예전 같으면 프리미엄이나 유료 서비스를 찾았을 법한 것들을, 이제는 에이전트가 몇 분 만에—그리고 내가 원하는 방식 그대로—해결해 주는 경우가 많다. 흥미로운 건, 나는 그 변화를 의식적으로 느끼지도 못했다는 점이다. 그냥 어느새 그렇게 되어 있었다.
내부 대시보드가 필요하다면, 이제 Retool 같은 것이 더 쉽다고 생각조차 하지 않는다. 그냥 대시보드를 만든다. 미디어 인제스트 과정에서 비디오를 다시 인코딩해야 한다면, Claude Code에게 ffmpeg를 감싸는 견고한 래퍼를 작성하게 하면 된다. 그러면 원본 파일을 별도 서비스로 전송하면서 발생하는 비용(과 속도 저하), 티어 제한에 걸리는 문제, 다른 API의 멘탈 모델을 내 머릿속에 억지로 끼워 맞추는 일을 피할 수 있다.
이 현상은 순수한 소프트웨어 개발이 아닌 작업에서는 더 두드러진다. 예를 들어 Gemini 3로 몇 분 만에 정말 높은 품질의 UI/UX 목업과 와이어프레임을 만들어 본 적이 있다. 별도 서비스를 쓰거나 시작할 템플릿을 찾을 필요가 없었다. 마찬가지로 프레젠테이션을 만들 때도, 슬라이드를 예쁘게 만들기 위해 플랫폼을 사용할 필요가 없다. Claude Code에게 내 마크다운을 보기 좋게 디자인된 PDF로 내보내라고 하면 된다.
또 하나(어쩌면 더 큰 영향이 있을) 변화로는, 사람들이 대형 “엔터프라이즈” SaaS 업체의 갱신(renewal) 견적을 진지하게 의심하기 시작했다는 점이다. 아직은 매우 초기 단계지만, 나는 이 행동 변화가 정말 중요하게 부상하고 있다고 믿는다. 이제까지 몇 번 봤는데, SaaS 벤더 X가 매년 관례적으로 두 자릿수(%) 가격 인상을 담은 견적서를 보내면, 팀들이 “우리가 진짜 이걸 꼭 내야 하나? 아니면 필요한 걸 직접 만들면 되지 않나?”라고 묻기 시작한다. 1년 전만 해도 이건 기껏해야 가정적 질문이었고 결론은 빠르게 ‘아니오’였을 것이다. 지금은 사람들이 실제로 시간을 들여 진지하게 검토하는 ‘현실적 선택지’가 됐다.
마지막으로, 대부분의 SaaS 제품은 많은 고객이 필요로 하지 않거나 사용하지 않는 기능을 다수 포함한다. SaaS 제품 엔지니어링의 복잡성 상당 부분은 바로 그걸 관리하는 데서 나오는데, 고객이 단 한 명(자기 조직)뿐이면 그 복잡성은 하룻밤 사이에 사라진다. 또한 그 고객이 곧 제품 로드맵을 결정하는 사람과 동일할 때는 로드맵에 대한 통제력이 완전해진다. 더 이상 SaaS 벤더가 다른 고객보다 내 요청을 우선해 주길 바라며 기다릴 필요가 없다.
이에 대한 핵심 반론은 “그 앱들은 누가 유지보수하나?”다. 이는 실제로 타당하고 정확한 반론이다. 소프트웨어에는 고칠 버그가 있고, 해결해야 할 확장성 문제가 있으며, 패치해야 할 보안 이슈가 있다. 그건 변하지 않는다.
먼저, 상당히 많은 SaaS가 유지보수가 형편없다는 점을 짚는 것이 중요하다(내 경험상 종종 비쌀수록 품질이 더 나쁘다). 보안 리스크는 외부 제3자가 내부 데이터에 연결하고 인터페이스해야 한다는 사실 그 자체에서 비롯되는 경우가 많다. 이를 기존 VPN이나 액세스 솔루션 뒤로 옮기기만 해도, 조직의 공격 표면(attack surface)을 갑자기 크게 줄일 수 있다.
게다가 에이전트 자체가 유지보수 비용을 극적으로 낮춘다. 내가 겪어온 가장 고통스러운 유지보수 작업 중 하나는—지원이 중단된 라이브러리에서 더 지원이 좋은 다른 라이브러리로 마이그레이션하는 일인데—에이전트를 쓰면 특히 정적 타입 언어 생태계에서 훨씬 쉬워진다. 또한 기업이 내부 도구를 만드는 데 가장 주저하는 이유 중 하나는 한 사람이 모든 것을 알고 있게 되는 상황인데, 그 사람이 떠나면 내부 지식이 함께 사라진다. 에이전트는 떠나지 않는다. 그리고 잘 설계된 AGENTS.md 파일이 있다면, 미래의 누구에게든 코드베이스를 설명할 수 있다.
마지막으로, SaaS도 유지보수 문제를 동반한다. 이번 달에 지인에게서 들은 최근 사례로는, 한 SaaS 회사가 기존 API 엔드포인트를 더 이상 지원하지 않기로 하고 새로운 API 세트로 옮겼는데, 그 새 API에는 동일한 메서드가 모두 존재하지 않았다. 이 시스템이 핵심 시스템이라면 이는 엄청난 문제이며, 영향받는 통합을 업데이트하고 테스트하고 롤아웃하는 데 막대한 자원이 든다.
나는 소프트웨어 지식이 거의 없는 중소기업이 갑자기 SaaS 전체를 단번에 대체할 거라고 말하는 게 아니다. 다만, 일정 수준의 기술 역량과 이해가 있는 조직이라면 SaaS 조달과 벤더 라이프사이클을 훨씬 더 비판적으로 바라보기 시작할 것이라고 생각한다.
SaaS 가치평가는 두 가지 핵심 가정 위에 세워진다. 빠른 고객 성장과 높은 NRR(순매출 유지율, 종종 100%를 초과).
특정 도구/앱 세그먼트에서 신규 고객 수요가 감소하기 시작하는 세계는 이미 충분히 보인다. 이는 문제이며, 해당 기업들의 영업 및 마케팅 지출 증가로 이어질 것이다.
하지만 더 교묘한 문제는 NRR 하락이다. NRR은 이탈(churn)을 반영해 기존 고객이 지속적으로 얼마나 지출하는지를 측정한다. NRR이 100%라면 기존 고객 코호트가 동일한 금액을 지출하고 있다는 뜻이다. 그보다 낮다면 고객이 당신에게 지출을 줄이고 있거나, 그리고/또는 전체적으로 고객이 떠나고 있다는 뜻이다.
많은 훌륭한 SaaS 기업의 NRR은 100%를 크게 웃돈다. 이것이 많은 SaaS 비즈니스 모델의 아름다움이다. 고객사는 성장하면서 플랜에 더 많은 사용자를 추가해야 한다. 또는 추가 기능을 얻기 위해 더 비싼 티어로 업그레이드해야 한다. 이런 증가는 대체로 매우 수익성이 높다. 이 상승분을 얻기 위해 영업·마케팅에 큰돈을 쓸 필요가 없다(이미 관계가 있으니까). 그리고 고객에게 SaaS 제품의 사용자 라이선스 100개를 더 추가하는 데 드는 한계 이익률은 사실상 무한대에 가깝다.
여기서 일부 SaaS 기업이 크게 타격을 받을 수 있다고 본다. 사람들은 더 높은 가격 티어로 올라가며 크게 더 지불하는 것을 피하기 위해, 솔루션의 일부를 자체 구축/수정한 내부 플랫폼으로 옮기기 시작할 것이다. 또는 당신의 API로 플랫폼 데이터를 가져와 내부 대시보드와 리포팅을 만들어, 사용자 라이선스의 80%를 없애 버릴 수도 있다.
가장 명확한 건 매우 높은 업타임과 SLA가 필요한 영역이다. 99.99%나 99.999%를 달성하는 건 정말 어렵고, 고가용성 시스템을 만드는 건 매우 복잡하다. 그리고 만들다가 스스로 발등을 찍기 쉽다. 그래서 결제 처리 같은 코어 인프라 영역은 내 눈에는 꽤 안전하다. 에이전트만으로 Stripe와 그들이 코어 결제를 위해 해온 모든 엔지니어링 작업을 (아직은) 쉽게 대체하긴 어렵다.
또한 초고트래픽 시스템과 데이터 레이크도 대체하기 어렵다. 거대한 데이터셋이나 거래량을 위해 클러스터를 띄우는 건 간단한 일이 아니다. 이 역시 조직 내에 존재하지 않을 수도 있는(있더라도 희소한) 전문 지식이 필요하다.
또 하나는 강한 네트워크 효과가 있는 소프트웨어—특히 조직 외부 사람들과 협업하는 경우다. Slack이 좋은 예다. 이걸 사내 도구로 대체하긴 어렵다. 마찬가지로, 풍부한 통합 생태계와 플러그인 마켓플레이스를 가진 제품도 여기서 실질적 이점을 갖는다.
그리고 독점 데이터셋을 가진 기업은 여전히 매우 가치가 있다. 금융 데이터, 세일즈 인텔리전스 같은 것들은 계속 가치가 있다. 오히려 나는 이런 기업들이 새로운 우위를 가진다고 본다. 에이전트가 이 데이터를 새로운 방식으로 활용할 수 있기 때문에, 락인이 더 강해진다.
마지막으로 규제와 컴플라이언스는 여전히 중요하다. 많은 산업은 규제 준수가 필수이며, 이건 하루아침에 바뀌지 않는다.
다만 이를 위해서는 조직이 새로 만들어진 앱들을 운영할 역량(내부 혹은 외부)을 갖추고 있어야 한다. SRE와 DevOps에 관련된 제품과 인력 수요는 크게 증가할 것이라고 본다. 기업 내에서 이러한 신규 애플리케이션을 전담으로 관리하는 완전히 새로운 기능과 팀이 등장할 가능성도 있다고 생각한다. 물론 비용이 들지만, 이 비용은 기존 SRE/DevOps 기능으로 흡수될 수도 있고, 신규 인력과 인프라가 필요하다면 훨씬 더 많은 앱에 걸쳐 분산(상각)될 수도 있다.
내가 보기엔 가장 위험한 회사들은, 본질적으로 CRUD 로직에 불과한 백오피스 도구이거나 고객의 자체 데이터 위에 간단한 대시보드와 분석을 얹는 제품들이다.
이런 도구들은 대개 많은 마찰을 만든다. 고객이 원하는 방식과 정확히 일치하지 않기 때문이다. 그리고 에이전트로 가장 쉽게 대체되는 종류의 도구이기도 하다. 기존 시스템을 문서화하고 에이전트에게 “이걸 만들어라”라고 지시하는 건 매우 쉽고, 그러면서도 기존의 고통 포인트를 제거할 수 있다.
SaaS가 죽었다고 말하는 건 아니다. 어떤 큰 기술 변화든 승자와 패자가 있다. 다만 명확한 해자나 독점적 지식이 없는 많은 SaaS 제품은 기준(허들)이 훨씬 높아질 것이라고 본다.
예측하기 어려운 건 에이전트가 얼마나 빠르게 밸류체인의 상단으로 이동하느냐이다. 나는 에이전트가 복잡한 데이터베이스 클러스터를 관리하지 못할 거라고 가정하고 있지만, 그게 오래 지속될지는 확신할 수 없다.
그리고 모든 회사가 갑자기 SaaS 지출을 전부 대체할 수 있을 거라는 경로도 보이지 않는다. 오히려 시장은 (또 한 번) 더 쪼개질 것 같다. 내부 기술력이 강한 회사와 그렇지 않은 회사로. 이는 전자에게 또 다른 경쟁우위가 된다. 반대로 후자는, SaaS 제공자가 첫 번째 그룹에서 잃는 매출을 전환이 어려운 두 번째 그룹에서 만회하려 할 때, 비용이 급격히 증가할 가능성이 크다.
하지만 내 핵심 결론은 이것이다. 당신의 제품이 청구 시스템 위에 얹힌 SQL 래퍼에 불과하다면, 이제 당신에게는 경쟁자가 수천 명이다. 고객사 엔지니어들이 에이전트와 함께 ‘금요일 오후의 여유 시간’에 만들어 버릴 수 있으니까.
