업무 자동화 SaaS를 만드는 쪽이 요즘 영업 자리에서 가장 자주 듣는 반문이 하나 있다. "그거, 우리가 직접 만들면 안 되나요?"
예전 같으면 이 질문은 금방 가라앉았다. 개발자를 몇 명 붙여야 하고, 몇 달이 걸리고, 그 사이 다른 일을 못 한다. 셈을 해 보면 대부분 "그냥 사자"로 끝났다. 그런데 지금은 분위기가 다르다. 코딩을 도와주는 AI 에이전트(사람이 지시하면 스스로 코드를 짜고 고치는 AI)에게 "매일 아침 주문 데이터를 모아 요약 메일을 보내줘" 같은 걸 시키면, 반나절 만에 돌아가는 무언가가 나온다. 비개발자도 흉내는 낼 수 있다.
그래서 이 질문이 다시 무거워졌다. 누구나 자동화의 '첫 버전'을 만들 수 있게 된 시대에, 업무 자동화 SaaS(월정액으로 쓰는 클라우드 소프트웨어)는 대체 무엇을 팔아 '직접 구축'과 경쟁하는가. 결론부터 말하면, 싸움은 '만들 수 있냐 없냐'가 아니라 '실패를 먼저 발견하고, 피해를 줄이고, 되돌릴 책임을 누가 지느냐'에서 갈린다. 이 글은 그 구도를 SaaS 사업자의 눈으로 짚는다. 고객이 왜 직접 구축 쪽으로 기우는지, 그리고 그 앞에서 제품과 영업이 무엇을 입증해야 하는지.
자동화의 진입 장벽이 진짜로 낮아진 건 맞다. 이걸 외면하면 경쟁 분석 자체가 틀어진다.
작은 가게를 하는 사람이 AI에게 "네이버 예약이 들어오면 나한테 문자로 알려줘"를 부탁한다고 하자. 몇 번 주고받으면 작동하는 스크립트(특정 작업을 자동으로 실행하는 짧은 프로그램)가 손에 쥐어진다. 첫날 테스트도 통과한다. 이 순간 그는 확신한다. "봐, 되잖아. 굳이 돈 내고 쓸 필요 없네."
여기서 미끄러진다. 그가 본 것은 '맑은 날의 시운전'이다. 예약이 정상적인 형식으로 하나씩 들어오고, 인터넷이 끊기지 않고, 네이버가 화면을 안 바꾼 상태. 그 조건에서만 돌아가는 물건이다. 자동화의 난이도는 이 맑은 날에 있지 않다. 비바람에 있다. 그리고 고객이 직접 구축 쪽으로 기우는 출발점이 바로 이 맑은 날의 성공 체험이다.
자동화에서 가장 많은 일이 남는 구간은 데모가 아니라 그 뒤다. 정상 입력을 처리하는 첫 버전을 만드는 것보다, 실패를 발견하고 되돌리는 장치를 갖추는 데 더 많은 일이 남는다. 이 마지막 구간을 흔히 '라스트 마일(last mile)'이라고 부른다. 앞의 예약 알림으로 이어가 보면, 비바람은 세 방향에서 분다.
첫째, 입력이 지저분하다. 한 달쯤 잘 돌던 알림이 어느 날 안 온다. 손님이 예약 메모에 이모지를 잔뜩 넣었고, 그걸 처리하다 스크립트가 멈춘 것이다. 이렇게 드물게 튀어나오는 예외 상황을 엣지케이스(edge case)라고 한다. 세상의 데이터는 깨끗하지 않다. 전화번호 칸에 "곧 연락드릴게요"가 들어오고, 날짜 칸에 "다음 주 아무 때나"가 적힌다. 데모는 이런 걸 가정하지 않지만, 운영은 매일 이런 걸 만난다.
둘째, 바깥 세상이 멋대로 변한다. 네이버가 예약 화면 구조를 바꾸면 어제까지 멀쩡하던 자동화가 오늘 멈춘다. 문제는 멈췄다는 사실을 알려주는 장치가 없다는 것이다. 그래서 가게 주인은 "요새 예약이 뜸하네" 하다가, 한참 뒤에야 밀려 있던 알림 뭉치를 발견한다. 멈춘 것보다 멈춘 줄 몰랐던 시간이 더 비싸다.
셋째, 고친 게 다시 깨진다. 이모지 문제를 막으려고 코드를 손봤더니, 이번엔 멀쩡하던 영문 이름 처리가 틀어진다. 한 군데를 누르면 다른 데가 튀어나오는 이 현상을 리그레션(regression)이라고 한다. 테스트를 제대로 갖춰두지 않으면, 고칠 때마다 새 구멍이 뚫리는지조차 모른다.
이 셋을 떠안는 사람이 직접 만든 사람이다. 직접 만들기는 한 번 짜고 끝나는 공작이 아니라 끝나지 않는 돌봄이다. 고객이 "직접 만들면 되는데"라고 말할 때 셈에 넣지 않는 비용이 바로 여기 있다. 그리고 SaaS 사업자가 제품과 영업에서 보여줘야 할 가치도 여기서 시작된다.
경쟁 분석의 핵심은 여기다. SaaS가 파는 상품을 '기능'으로 적으면 자꾸 헷갈린다. 기능은 복제하기 쉽다. "요약 메일 보내기"는 누구나 만든다. SaaS가 실제로 파는 건, 그 기능이 비바람 속에서 깨질 때 실패를 먼저 발견하고(탐지), 피해를 제한하고(멈춤·승인), 되돌리는(복구) 책임이다. 이건 주말에 복제할 수 없다.
무엇이 복제하기 어려운지 보자. 먼저, 쌓인 예외 경험이다. 수천 명의 고객을 겪은 서비스는 그만큼 이상한 입력을 이미 만나봤고, 그 경험이 코드 안에 녹아 있다. 직접 만드는 사람은 이 수천 번의 사고를 혼자 처음부터 다시 겪어야 한다. 다음으로, 바깥 변화의 흡수다. 외부 서비스가 화면을 바꾸거나 모델이 교체될 때 SaaS 쪽이 미리 감지하고 고쳐 놓으면, 고객은 그런 일이 있었는지도 모른 채 계속 쓴다. 마지막으로, 멈췄을 때 알아채는 감시 장치다. 이걸 제대로 만드는 일은 자동화 본체를 만드는 것만큼 손이 가고, 직접 구축한 사람 대부분이 여기까지는 손대지 못한다.
정리하면, 복제하기 쉬운 것은 기능이고 어려운 것은 실패를 통제하는 능력이다. 그래서 제품과 영업이 입증해야 할 것은 데모 화면의 번듯함이 아니라 "깨졌을 때 어떻게 되는가"다.
경쟁 분석이 자사에 유리한 쪽으로만 기울면 분석이 아니라 영업이다. 직접 만드는 게 더 나은 경우는 분명히 있다. 다만 그 경계는 조직 규모가 아니라 세 가지로 그어진다. 자동화를 얼마나 오래 유지할 것인가, 깨졌을 때 손실이 얼마나 큰가, 고칠 사람이 상시 있는가.
실패해도 손실이 작거나 한두 번 쓰고 버릴 자동화라면, 라스트 마일에 들일 품이 애초에 적으니 직접 만들어 쓰는 게 낫다. 업무가 회사의 비밀 레시피 그 자체여서 바깥 도구에 맡기는 순간 차별점을 내주는 경우도 안에서 만드는 게 맞다. 깨졌을 때 바로 달려들 개발 인력이 상시 대기하고 있다면 라스트 마일의 비용을 자기 힘으로 감당할 수 있다. (규모가 아주 커서 단가가 뒤집히는 지점도 여기에 겹친다.)
반대로 그 업무가 본업이 아니고 고칠 사람을 따로 둘 여유가 없다면, 직접 구축은 대개 이렇게 끝난다. 처음엔 신나서 만들고, 두어 달 돌아가다, 어느 날 멈추고, 멈춘 줄 모른 채 방치되고, 결국 그 일을 다시 사람이 수동으로 한다. 돌아온 자리다. 그 사이 날린 시간이 진짜 비용이다. 사업자는 이 경계를 솔직히 그려야 한다. 경계 밖의 고객을 억지로 끌어오면 곧 이탈로 돌아온다.
경쟁 상대를 '비슷한 다른 SaaS'로만 보면 그림의 절반을 놓친다. 실제 기준선은 셋이다. '직접 만들기', '사람을 더 뽑기', 그리고 가장 강력한 '아무것도 안 하고 지금처럼 버티기'.
마지막 게 왜 가장 센가. 사람은 불편을 꽤 오래 참는다. 매일 30분씩 손으로 데이터를 긁는 일을 '원래 그런 것'으로 받아들이고 몇 년을 버틴다. 새 도구를 들이면 배워야 하고, 기존 방식을 바꿔야 하고, 잘못되면 책임을 져야 한다. 그 번거로움이 눈앞의 30분보다 크게 느껴지는 한 사람들은 그냥 버틴다.
그래서 "우리 제품이 경쟁 제품보다 기능이 많다"는 이 관성을 이기지 못한다. 이겨야 하는 건 관성 쪽이다. 도입이 덜 번거롭고, 기존 방식을 덜 바꿔도 되고, 잘못됐을 때 알려준다는 믿음. 이 관점은 가격을 보는 눈도 바꾼다. '직접 만들기'와 비교하면 월정액은 비싸 보이지만, 비교 대상이 '그 일을 하던 사람의 시간'이나 '방치돼 다시 수동으로 돌아간 시간'이라면 전혀 다른 크기로 보인다. 승부처는 "우리가 더 싸다"가 아니라 "당신이 지금 치르는 보이지 않는 비용을 보이게 만든다"에 있다.
온틀(ONTLE)은 이 라스트 마일을 대신 맡는 서비스다. 들어온 메일을 읽고, 사내에 공유하고, 고객에게 보낼 답장 초안을 만들고, 변경을 기록하는 과정을 대신 돌린다. 단, 고객에게 나가는 답장과 일정 확정처럼 되돌리기 어려운 지점은 사람 승인을 거친다. 가상의 작은 제조 회사를 두고, 흔한 사건 하나를 쫓아가 보자. 고객이 "납기를 일주일 당겨 달라"고 메일을 보낸 상황이다.
여기서 짚을 게 하나 있다. AI가 섞이는 방식은 두 가지이고, 둘은 다르다. 하나는 코딩 에이전트가 코드를 한 번 짜두면 그대로 도는 것, 다른 하나는 실행 중에 AI 모델이 매번 메일을 읽고 판단하는 것이다. 납기 메일을 해석하는 쪽은 후자다. 그런데 이 판단하는 모델은 몇 달 단위로 새 버전이 나오고 옛 버전은 서서히 닫힌다. 새 모델은 같은 지시에도 조금 다르게 반응해서, 지난달까지 멀쩡하던 프롬프트(AI에게 주는 지시문)가 오늘 엉뚱한 답을 내기도 한다.
무엇이 실패하는가. 현실의 메일은 데모처럼 생기지 않았다. "저번에 말한 그 건, 가능하면 조금 당겨주실 수 있을까요?"라고 온다. '그 건'이 어느 주문인지 메일에 없고, 날짜도 숫자로 안 적혀 있다. 하필 생산 일정 시스템이 점검 중이라 조회가 실패한다. 당겨 달라는 게 물리적으로 불가능한데, 자동화가 그걸 모르고 "네, 가능합니다" 초안을 만들어 버린다. 이 초안이 검토 없이 나가면 사고다.
어떻게 대응하는가. 여기서 직접 만든 스크립트와 운영을 책임지는 서비스가 갈린다. '그 건'이 뭔지 모를 때 멋대로 찍지 않고 "이 주문을 말씀하시는 게 맞을까요?"라고 되묻거나 사람에게 넘긴다(탐지·승인). 틀린 주문에 답장이 나가 생기는 신뢰 손실을 막는 장치다. 당기는 게 불가능하면 거짓 약속 대신 "여기까지는 가능하다"를 제시한다(정직). 지키지 못할 납기를 약속해 터지는 사고를 막는다. 일정 조회가 실패하면 넘어가지 않고 "지금 확인이 안 되니 잠시 뒤 다시"라고 멈춘다(탐지). 잘못된 정보로 답하는 걸 막는다. 외부로 나가는 답장은 사람 승인을 거치고(승인), 이 변경이 다른 주문에 미치는 영향까지 함께 살핀다.
누가 그 비용을 맡는가. 이 회사가 직접 만든다면 이 다섯 가지를 전부 스스로 설계하고, 모델이 바뀔 때마다 다시 점검하고, 생산 시스템이 화면을 바꾸면 그때마다 고쳐야 한다. 그 일을 할 사람이 없으면 자동화는 '맑은 날만 되는 물건'으로 남고, 비 오는 날엔 사람이 또 뛴다.
다섯 가지가 전부 온틀의 고유 기능은 아니라는 점은 분명히 해 둔다. '모호하면 사람에게 넘김'과 '외부 발신 전 사람 승인'은 온틀이 실제로 그렇게 동작하도록 만들어 둔 지점이다. 나머지 셋(불가능 판정, 조회 실패 시 멈춤, 영향 분석)은 운영 자동화라면 어디든 갖춰야 할 설계 원칙이고, 온틀도 그 원칙 위에서 움직인다. 누구나 첫 번째 답장은 만든다. 천 번째 이상한 메일 앞에서 사고를 안 치는 건 다른 이야기다.
구매자를 위한 점검 질문 직접 만든 자동화든, 사려는 SaaS든, 다음을 물어보면 라스트 마일에 얼마나 대비돼 있는지 가늠된다. - 자동화가 지금 멈췄다면 나는 몇 시간 안에 알 수 있나. 모른다면 멈춘 줄도 모르는 상태에 노출돼 있다. - 이상한 입력이 들어왔을 때 어떻게 되는지 실제로 테스트해 봤나. 안 해봤다면 맑은 날만 검증한 것이다. - 만든 사람이 자리를 비우면 누가 고치나. 답이 없다면 그 자동화의 수명은 그 사람의 재직 기간과 같다. - (SaaS를 고를 때) 기능 목록의 길이보다 깨졌을 때의 행동을 보라. 실패를 어떻게 알리는지, 불확실할 때 멋대로 진행하는지 사람에게 넘기는지, 외부로 나가는 행동에 승인 단계가 있는지.
그 순서 자체는 합리적이고 실제로 많이들 그렇게 합니다. 다만 갈아타는 시점의 비용을 미리 염두에 둘 필요가 있습니다. 직접 만든 자동화에는 그동안 쌓인 예외 처리와 사내 사람들의 사용 습관이 얽혀 있어서, 옮길 때 그걸 풀어내는 일이 생각보다 큽니다. 그래서 '언제 갈아탈까'보다 '어느 선을 넘으면 갈아탄다'를 처음에 정해두는 편이 낫습니다. 예컨대 고칠 사람이 없어 일주일 이상 방치된 적이 한 번이라도 생기면, 그게 신호입니다.