"SaaS is dead"라는 말이 최근 유행하고 있습니다. AI가 코드를 작성할 수 있는 시대이니 SaaS에 매달 비용을 내지 말고 필요한 것은 사내에서 직접 만들자는 논리입니다.
저희 회사 Emooove는 지난 몇 달간 사내 시스템을 직접 구축하는 일에 전념해 왔습니다. 실제로 해보면서 저는 성공과 쓰라린 교훈을 모두 경험했습니다. 오늘은 그 실제 경험을 바탕으로 "SaaS is dead"라는 주장에 대한 제 관점을 공유하고자 합니다.
분명히 말하면, 저는 SaaS 제공자가 아닌 시스템 사용자/구축자의 관점에서 이 글을 씁니다.
누구나 시스템을 만들 수 있는 놀라운 시대
먼저, 전제로서 Claude Code의 등장은 정말로 "누구나 시스템을 만들 수 있는" 시대를 열었습니다. 이는 과장이 아닙니다.
Emooove에서 입사한 지 두 달밖에 안 된 채용 리드가 사내 ATS(Applicant Tracking System, 지원자 추적 시스템)를 구축했습니다. 그녀는 개발 경험이 전혀 없는 비개발자입니다. 그럼에도 불구하고 지원자 불러오기부터 선발 관리, 대시보드까지 처리하는 제대로 동작하는 시스템을 만들어 냈습니다.
또한 현재 저희는 핵심 사업인 영업 대행 서비스의 운영 효율성과 품질을 개선하기 위한 사내 시스템을 개발 중입니다. 저도 매일 이 작업에 직접 참여하고 있는데, 시작한 지 2주도 안 되어 꽤 괜찮은 무언가를 만들 직전까지 온 것 같습니다.
매달 수만 엔에서 수십만 엔에 달하는 SaaS 비용을 내야 할 것을 사내에서 직접 만들 수 있다면, 사람들이 "SaaS is dead"라고 말하고 싶어 하는 이유를 이해할 수 있습니다.
하지만 순탄하기만 한 것은 아닙니다
이것이 핵심입니다. 실제로 시도해 보니 장밋빛만은 아니었습니다.
1. 유지보수가 엄청나게 어렵다
좋든 나쁘든 "즉흥적으로" 만들 수 있기 때문에 빠르게 형태를 갖추게 됩니다. 하지만 요구사항이 완전히 정리되지 않은 상태이기 때문에 거친 부분이 많습니다.
저희 ATS의 경우 이런 문제들이 있었습니다:
- 가져와야 할 지원자 데이터가 누락되었다.
- 대시보드 숫자에 어딘가 버그가 있었다.
- 중요한 버튼이 없어서 업무가 마비된 적도 있었다.
사용을 시작한 후에야 발견하게 되는 "누락"을 많이 겪었습니다. 사내 영업 지원 시스템은 어느 날 갑자기 접속이 안 되고 화면이 열리지 않는 아침이 있기도 했습니다.
물론 요구사항을 더 꼼꼼히 정의하거나 사용하면서 개선해 나가면 어느 정도 해결할 수 있습니다. 하지만 그동안 정상적인 업무 운영이 중단됩니다. "쉽고 빠르게" 만들 수 있을 거란 기대를 가지고 시작하면 곤란한 상황에 빠지게 됩니다. 저는 "만들고 끝내는" 마음가짐이 아니라 "만들고 계속 고쳐 나가는" 마음가짐으로 시작해야 한다는 것을 깨달았습니다.
저희는 채용 규모가 작아서 ATS가 잠시 멈춰도 어떻게든 버틸 수 있습니다. 하지만 이해관계자가 많은 시스템이었다면 생각만 해도 아찔합니다. 사용자 수와 영향 범위가 커질수록 한 번의 실패로 인한 손실이 커지고 난이도는 급격히 올라갑니다.
내부 시스템에서는 이런 부분을 감수할 수 있겠지만, 외부 판매용이거나 문의 양식처럼 외부와 맞닿은 것을 만들 때는 극도로 신중해야 합니다.
2. UI/UX는 결코 다듬어지지 않는다
시스템을 직접 만들면서 깨달은 것인데, 완성도가 다소 어중간합니다.
AI가 처음 생성해 주는 화면은 "그럴듯해" 보이지만, 실제로 사용해 보면 디테일이 매끄럽지 않습니다. 지시를 반복해서 주다 보면 결국 괜찮은 모습으로 만들 수는 있지만, 그 과정에는 강한 집착과 시간이 필요합니다. 대부분의 사람들은 중간쯤에서 타협하게 될 것입니다.
SaaS 인터페이스가 정교한 것은 전문 디자이너들이 수년간 사용자 피드백을 반영해 왔기 때문입니다. 이것은 공짜로 얻을 수 있는 것이 아닙니다.
3. 보안 문제
이것이 가장 무서운 부분입니다.
비개발자라도 "일단 만들어 보자"는 태도로 Claude Code를 사용해 기능과 UI/UX를 구축할 수 있습니다. 하지만 보안도 같은 방식으로 따라잡을 수 있을까요? 적어도 저에게는 불가능합니다. 인증, 권한 관리, 취약점 대응 — "동작하는 것"과 "안전한 것"은 완전히 다른 문제입니다.
저희는 다행히 보안 엔지니어 경험을 가진 분이 있어서 이 부분을 반드시 그분이 담당하도록 하고 있습니다. 그럼에도 불구하고 약간의 불안감은 남습니다. 전문가도 없는 조직이 즉흥적으로 만든 시스템에 고객 정보를 올리고 외부에 공개하는 모습을 상상하면 식은땀이 납니다.
"살아남느냐 죽느냐"라는 이분법적 논리는 틀렸다
사내 개발의 부정적인 점들을 나열했지만, 솔직히 좋은 점도 많이 있습니다.
- 비즈니스에 완벽하게 맞는 것을 만들 수 있다.
- 고치고 싶은 것이 있으면 바로 다음 날 고칠 수 있다.
- 월 비용이 거의 들지 않는다.
- "우리가 직접 시스템을 만들 수 있다"는 노하우와 자신감을 회사가 얻게 된다.
문제는 이것을 "SaaS가 살아남을까, 죽을까"로 단순화하려는 것입니다. SaaS를 도입할지 사내에서 구축할지는 회사의 상황에 달려 있습니다. 제 경험을 바탕으로 고려해야 할 다섯 가지 포인트를 정리했습니다:
포인트 1: 사내에 엔지니어가 있는가?
없다면 비개발자가 즉흥적으로 감당할 수 없는 보안 같은 영역에서 실패하게 됩니다. 가장 무서운 점은 위험을 인지하지 못한 채 기능을 만들어 버릴 수 있다는 것입니다. 핵심 영역을 검토해 줄 경험 많은 인력을 확보할 수 있는지가 분기점입니다.
포인트 2: 이해관계자의 수
이해관계자가 너무 많으면 실패했을 때의 손실이 크고 난이도가 급격히 올라갑니다. 반대로 작은 조직은 시스템이 멈추면 사과하면 되기 때문에 더 쉽게 실험할 수 있습니다. 영향 범위가 작은 업무부터 시작하는 것이 현실적입니다.
포인트 3: 외부 시스템 vs 내부 시스템
내부 시스템은 문제가 생겨도 위험이 제한적입니다. 하지만 외부로 향하는 것은 단 한 번의 정보 유출로도 되돌릴 수 없는 결과를 초래할 수 있습니다. SaaS는 책임의 일부를 공급업체에 넘길 수 있지만, 사내 개발은 모든 것이 당신의 책임입니다. 외부를 상대하는 것일수록 SaaS가 주는 "검증된 안심"의 가치는 더 커집니다.
포인트 4: 유지보수에 인력을 투입할 수 있는가?
유지보수는 상상보다 더 자주 필요합니다. 사내 개발은 "만들고 끝내는" 것이 아니라 "계속 고쳐 나가는" 것입니다. 그런 예측을 가지고 시작할 수 있습니까? 어중간한 마음가짐으로 시작하면 결함 수정에 파묻혀서 핵심 사업에 부담이 갑니다.
포인트 5: AI 개발을 좋아하고 하고 싶은가?
결국 이것이 가장 중요합니다. 생각보다 더 지루하고 어려우며, AI가 말을 안 들을 때는 답답하기도 합니다(웃음). 그래도 끝까지 해낼 수 있습니까? 좋아하는 사람에게는 정말 좋은 시대이지만, 의무감만으로는 지속할 수 있는 것이 아니라고 생각합니다.
요약: SaaS는 죽지 않았다. 선택지가 늘어났을 뿐이다.
제목에 "실패"라는 단어를 사용했지만, 더 정확히 말하면 "거의 실패할 뻔한 적이 여러 번"이었습니다. 저희가 사내 개발을 계속하는 이유는 경험 많은 엔지니어가 있고, 조직이 아직 작으며, 주로 내부용이고, 유지보수에 전념할 준비가 되어 있고, 무엇보다 제가 그것을 하고 싶기 때문입니다. 다섯 가지 포인트가 모두 충족되는 유리한 환경에 있기 때문에 하고 있다고 할 수 있습니다.
반대로 이런 조건을 갖추지 못한 회사가 "SaaS is dead"라는 말을 문자 그대로 받아들여 핵심 업무를 사내에서 구축하려 한다면 정말로 실패하게 될 것입니다.
SaaS는 죽지 않았습니다. 단지 "직접 만든다"는 선택지가 이제 모든 사람에게 열렸을 뿐입니다. 냉정하게 회사의 상황을 평가해서 SaaS와 사내 개발을 병용하세요. 편리하면서도 불안정한 이 시대에 대처하는 올바른 방법이 그것 아닐까요?
