"요즘 Claude로 뚝딱 만들 수 있잖아요. 굳이 세일즈포스 쓸 필요가 없지 않나요?"
요즘 미팅에서 이 말을 자주 듣습니다. 틀린 말이 아니에요. AI를 잘 쓰면 예전에는 개발팀 없이 불가능했던 것들이 가능해진 건 맞아요. Claude로 2주 만에 간이 CRM 인터페이스를 만들었다는 이야기도 들었고, 저도 직접 겪었고요.
이 흐름에는 이름이 있어요. 사스포칼립스(SaaSpocalypse) — AI 에이전트 시대에 기존 SaaS가 무너진다는 담론이에요. 2024년 12월 마이크로소프트 CEO 사티아 나델라가 BG2 팟캐스트에서 "SaaS is dead"를 선언하면서 불이 붙었고, 2026년 초 Jefferies가 이 용어를 공식화하며 글로벌 SaaS 시장 전체를 흔들었어요.
그런데 이 판단에는 한 가지 빠진 게 있습니다.
AI가 낮춰준 비용은 사실 하나가 아니라 두 덩어리인데, 사람들이 첫 번째 덩어리만 보고 결론을 내린다는 겁니다.
소프트웨어 비용에는 2개의 덩어리가 있다
기업이 소프트웨어에 쓰는 돈을 찬찬히 들여다보면, 크게 2개의 레이어로 나뉩니다.
첫 번째 덩어리 — 솔루션 라이선스 비용
SaaS를 직접 구독해서 쓰는 비용이에요. Salesforce, HubSpot, Notion 같은 플랫폼에 매달 내는 구독료죠. 10석이면 얼마, 100석이면 얼마 — 티어가 올라갈수록 커지는 그 비용.
두 번째 덩어리 — 에코시스템 서비스 비용
솔루션 주변에서 발생하는 비용이에요. 구축사에게 주는 돈, SI 파트너에게 내는 돈, 데이터 마이그레이션 업체 비용, 유지보수 파트너 비용. 라이선스 계약서에는 안 잡히지만(구축사와 계약을 따로 한다는 의미), 실제로 소프트웨어를 쓰기 위해 들어가는 총비용에서 상당한 비중을 차지하는 돈이에요.
많은 기업이 Salesforce를 도입할 때 라이선스 비용만 계산하다가 구축비에서 당황하는 경험을 합니다. 라이선스가 연 5천만 원이어도, SI 파트너에게 구축비로 1억을 쓰는 경우가 흔합니다. 그 이후에도 커스터마이징, 데이터 이관, 유지보수로 계속 돈이 나가고요.
그러니까 "소프트웨어 비용"이라고 할 때, 실제로는 이 두 덩어리를 합한 금액이에요.
AI 등장 이후 두 덩어리에 어떤 일이 생겼나
여기서부터가 핵심입니다. AI가 등장하면서 두 덩어리 모두에 충격이 가고 있어요.
첫 번째 덩어리에 가해진 충격
기존 솔루션을 대체하는 제품을 직접 만드는 비용이 낮아졌어요. 이게 많은 사람들이 직관적으로 느끼는 변화입니다. "나도 이제 AI로 만들 수 있다. 저 비싼 SaaS 안 써도 된다."
실제로 맞아요. 예전에는 백엔드 개발자, 프론트엔드 개발자, DB 설계자가 팀으로 달라붙어야 했던 일이 이제 혼자서도 어느 정도 가능해졌어요. 비개발자도 할 수 있는 영역이 넓어진 건 사실이고요.
두 번째 덩어리에 가해진 충격
그런데 동시에, 두 번째 덩어리 — 에코시스템 서비스 비용도 낮아지고 있어요.
연동 작업이 쉬워졌고, 데이터 마이그레이션 도구가 성숙해졌고, API 연결의 허들이 낮아졌어요. 예전에는 "솔루션 A와 솔루션 B를 연결하려면 SI 파트너를 써야 하고 3개월은 걸린다"던 일이 이제 훨씬 빠르고 저렴하게 가능해졌거든요.
그 결과로 자연스럽게 이런 방향이 열렸어요.
"굳이 누군가한테 맡겨서 만들 게 아니라, 이미 있는 툴을 바로 연결해서 쓰는 게 제일 빠르다."
왜 사람들은 첫 번째 덩어리만 보는가
두 번째 덩어리가 눈에 안 들어오는 이유가 있어요.
소프트웨어를 직접 깊이 만들어본 경험이 없으면, 개발 비용이 낮아졌다는 신호를 "진입 장벽이 낮아졌다"로만 읽거든요.
막상 만들어보면 나타나는 것들 — DB 설계, 스케일 문제, 유지보수 부채, 보안, 장애 대응 — 이게 눈에 안 들어오는 거예요.
제가 최근에 대화를 나눈 분 중 한 분이 이런 말씀을 하시더라고요.
"소프트웨어를 안 만들어봐서 사람들이 잘 몰라요. 요즘 세상에 만들고 싶다니까 그냥 일단 다 만들어요. 그게 얼마나 큰 비용인지 몰라요. 그냥 돌아가는 수준을 넘어서서 돈 받고 유지보수가 되는 수준으로 만들려면 그 후에 시간이 엄청나게 들어가는데 말이죠"
"만들 수는 있다"와 "만든 이후를 감당할 수 있다"는 완전히 다른 이야기인데, AI 덕분에 허들이 낮아지다 보니 그 구분이 더 흐릿해지고 있어요.
두 덩어리를 같이 보면 나오는 전혀 다른 결론
두 덩어리를 동시에 놓고 보면, 나오는 결론이 달라져요.
첫 번째 덩어리만 볼 때 | 두 덩어리를 같이 볼 때 | |
|---|---|---|
판단 | 직접 만든다 | 이미 있는 툴을 연결한다 |
근거 | 개발 비용이 싸졌으니까 | 서비스 비용도 싸졌고, 기다릴 이유도 없으니까 |
결과 | 스케일 없는 솜사탕 구조 | 즉시 쓸 수 있고, DB만 쌓이면 껍데기는 교체 가능 |
3년 후 | 회사 커지면 전부 폐기 | 위에 무엇이든 올릴 수 있는 구조 |
가장 중요한 포인트는 "즉시성"이에요.
예전에는 이런 논리가 있었어요. "원하는 UI가 없으니까 차라리 직접 만들겠다." 세일즈포스가 원하는 화면을 개발해주길 기다려야만 했고, 자체 개발이 그 대안이었죠.
그런데 AI 시대에는 껍데기 — UI, 화면, 뷰 — 가 굉장히 유연해졌어요. DB만 제대로 쌓여 있으면, 원하는 화면은 나중에 얼마든지 만들 수 있는 환경이 된 거예요. "원하는 화면이 없다"는 이유로 전체를 새로 만들 필요가 줄어들었어요.
그러니까 전략의 우선순위가 바뀐 거예요.
예전: 원하는 UI를 얻기 위해 → 직접 만든다
지금: DB를 제대로 쌓아두면 → UI는 나중에 유연하게 교체 가능
"일주일이면 만들어드립니다"의 숨겨진 진짜 비용
"AI로 일주일이면 원하시는 기능 다 만들어드립니다."
빠르고 저렴하게 들리죠. 근데 그 뒷단을 생각해본 적 있으세요?
일주일 만에 나온 솔루션의 DB 구조는 스케일을 고려하지 않아요. 현재 문제 하나를 해결하기 위한 최소한의 구조만 있는 거예요. 초기에는 잘 돌아가는 것처럼 보이지만, 데이터가 쌓이고 사용자가 늘고 기능 요청이 생기면 기반부터 흔들리기 시작해요.
반면 Salesforce, HubSpot 같은 기존 플랫폼들은 수십 년간 수만 개의 기업 케이스를 소화하면서 만든 데이터 구조를 갖고 있어요. 그 뒷단의 두께가 다릅니다. 오늘 연결하면 내일 바로 쓸 수 있고, DB는 그냥 쌓이고, 나중에 껍데기를 바꾸고 싶으면 그때 바꾸면 돼요.
이게 CRM 선택에서 어떻게 작동하는가
한국 B2B 현장에서 이 두 덩어리 논리가 가장 선명하게 드러나는 게 CRM 도입 결정이에요.
시나리오 A: 두 번째 덩어리를 모르는 팀
세일즈포스 라이선스 비용이 비싸다고 느낀다
"우리가 필요한 기능만 AI로 만들면 되지 않나?"
개발하거나 외주를 맡긴다
처음엔 잘 된다
6개월 후 팀이 커지면서 권한 관리, 리포팅, 연동 문제가 터진다
처음부터 다시 만든다 (또는 결국 표준 솔루션으로 이사한다)
시나리오 B: 두 번째 덩어리까지 보는 팀
에코시스템 연결 비용이 낮아졌다는 걸 안다
이미 있는 툴을 빠르게 연결해서 쓰기로 한다
DB가 제대로 된 플랫폼 위에 데이터가 쌓이기 시작한다
원하는 뷰나 자동화는 필요할 때 위에 얹는다
회사가 커져도 기반은 흔들리지 않는다
더 빠르고, 더 안전하고, 더 확장 가능한 건 B입니다.
"처음에 비용 절감을 위해 직접 만들었다가 나중에 전부 폐기하고 Salesforce로 이사한 기업" 이야기는 B2B 현장에서 심심찮게 들려요. 직접 만드는 비용, 운영하는 비용, 그리고 나중에 이사하는 비용까지 다 더하면 처음부터 표준 솔루션을 쓰는 것보다 훨씬 많이 쓴 경우가 대부분이에요.
"그래도 우리는 특수한 케이스라 맞는 솔루션이 없다"는 말
이런 반론도 종종 나와요.
"우리 업종 특성상, 우리 프로세스가 특이해서 맞는 솔루션이 없어요."
틀린 말이 아닐 수 있어요. 진짜로 그런 경우도 있으니까요. 하지만 제 경험상, 이 말이 나올 때 두 가지 중 하나인 경우가 많아요.
하나는 프로세스 자체가 아직 정의되지 않은 경우예요. 뭘 원하는지 불분명한 상태에서 "우리한테 맞는 게 없다"고 느끼는 거죠. 이 경우엔 직접 만들어도 같은 문제가 반복됩니다. 뭘 만들어야 하는지 모르는데 어떻게 잘 만들겠어요. 우리 회사 전체의 완벽한 워크플로우부터 제대로 정의하고 만들어야 하는데 말이에요.
또 하나는 표준 솔루션을 제대로 써본 적이 없어서 무엇이 가능한지 모르는 경우예요. Salesforce를 "비싼 연락처 저장소"로 써본 경험만 있으면, 실제 기능의 5%도 안 쓴 거거든요.
세일즈포스를 도입해놓고 제대로 못 쓰는 이유 중 큰 부분이 구축과 운영을 담당할 세일즈 옵스의 부재예요. 솔루션이 안 맞는 게 아니라, 운영 체계가 없는 거예요.
AI 시대에 "만들 수 있다"와 "만들어야 한다"는 다른 질문이다
AI 덕분에 이제 많은 것을 직접 만들 수 있어요. 이건 분명한 사실이고, 좋은 변화예요.하지만 "만들 수 있다"는 능력의 문제이고, "만들어야 하는가"는 전략의 문제예요. 리소스를 투입하기 전에 반드시 두 가지를 물어보는 게 도움이 될 것 같아요.
첫째, 지금 만들려는 것의 DB 구조가 3년 후에도 버텨줄 것인가?
솜사탕은 만들기는 쉬워요. 하지만 회사가 커지면, 팀이 늘면, 요구사항이 복잡해지면 — DB 구조의 부채가 드러납니다. "만들 수 있다"는 오늘의 판단이, "3년 뒤에 전부 폐기해야 한다"는 비용을 만들 수 있어요.
둘째, 에코시스템 연결 비용이 낮아진 지금, 기다릴 이유가 있는가?
예전에는 Salesforce를 원하는 대로 쓰려면 SI 파트너를 기다려야 했고, 원하는 UI가 나오려면 로드맵을 기다려야 했어요. 하지만 AI 시대엔 에코시스템 연결이 훨씬 빨라졌고, UI는 필요할 때 유연하게 만들 수 있어요. "기다리기 싫어서 만든다"는 이유가 예전보다 약해진 거예요.
직접 만드는 게 맞는 경우도 분명히 있어요. 핵심 경쟁력이 그 소프트웨어 자체인 경우, 아무리 찾아봐도 기존 솔루션으로 해결이 안 되는 진짜 특수한 케이스. 하지만 그 판단 전에 두 번째 덩어리까지 보고 있는지 확인해보는 게 필요합니다.
정리: 두 덩어리를 같이 봤을 때 달라지는 결론
AI는 솔루션 비용과 에코시스템 서비스 비용, 두 덩어리를 동시에 낮추고 있다. 첫 번째 덩어리만 본 사람은 "직접 만들면 된다"고 결론짓는다. 두 번째 덩어리까지 본 사람은 "이미 있는 걸 연결하는 게 제일 빠르다"는 결론에 도달한다.
어느 쪽이 더 스마트한 판단인지는, 시간이 어느 정도 흐르고 데이터가 많이 쌓인 시점에서 알 수 있다고 생각합니다.