AI 업무 자동화 서비스를 고르는 기준은 무엇일까. 후보 세 곳을 놓고 비교한다고 하자. 셋 다 비슷한 수준의 최신 모델을 쓰고, 데모를 돌려보면 결과물도 엇비슷하다. 그렇다면 무엇을 보고 골라야 하나.
파는 쪽도 이 질문에 잘 답하지 못한다. 많은 에이전트 서비스가 여전히 "우리는 최신 모델을 씁니다"를 앞세운다. 몇 년 전이라면 차별점이었겠지만 지금은 아니다. 이 글의 주장은 하나다. 모델이 비슷해진 시장에서 승부를 가르는 것은 모델 성능이 아니라, 그 모델이 고객의 일을 처리하는 동안 쌓이는 맥락이다.
먼저 용어 하나. 에이전트 SaaS는 설치 없이 매달 구독해 쓰는(SaaS, 서비스형 소프트웨어), 사람이 시킨 목표를 받아 스스로 여러 단계를 밟아 일을 처리하는 소프트웨어를 말한다. 메일을 읽고, 일정을 잡고, 문서를 만들고, 다음 할 일을 판단하는 식이다.
에이전트가 하는 일의 품질은 대부분 바닥에 깔린 거대언어모델(사람 말을 알아듣고 글을 생성하는 AI)의 능력에서 나온다. 문제는 그 모델을 이제 거의 모두가 쓸 수 있다는 것이다. 몇몇 회사가 만든 최상위 모델 — 그 시점 가장 앞선 성능이라 흔히 프런티어 모델이라 부른다 — 을 API(프로그램이 외부 기능을 불러다 쓰는 연결 통로)로 호출해 쓰면 된다. 값은 계속 내리고, 1등과 2등 모델의 간격도 좁아졌다. 웬만한 업무에서는 둘 다 충분히 잘한다.
재료가 흔해졌다는 뜻이다. 흔한 재료로는 해자를 못 판다. 해자(垓字)는 원래 성 둘레를 파 적이 못 넘어오게 한 물길이고, 사업에서는 경쟁자가 쉽게 못 따라오게 만드는 구조적 장벽을 가리킨다. 남들과 똑같은 모델을 불러 쓰는 것만으로는 이 장벽이 서지 않는다. 오늘 내가 더 좋은 모델로 갈아타면, 내일 경쟁자도 같은 모델로 갈아탄다.
그래서 승부처는 모델 자체가 아니라, 그 모델이 일하는 동안 무엇이 남고 쌓이느냐로 내려간다.
핵심 단어는 맥락이다. 맥락이란 그 고객의 일을 처리하는 데 필요한 배경 지식 전부를 말한다. 누가 어떤 거래처와 일하는지, 지난달 납기를 왜 미뤘는지, 이 고객은 보고서를 어떤 톤으로 받길 원하는지, 어떤 실수를 한번 겪고 나서 무엇을 조심하게 됐는지.
이런 건 모델 안에 들어 있지 않다. 모델은 세상 일반을 알 뿐, 당신 회사의 지난 반년을 모른다. 서비스가 당신과 일하면서 하나씩 모아 쌓아야 생긴다. 그리고 한번 쌓이기 시작하면 선순환이 돈다. 맥락이 많을수록 판단이 정확해지고, 판단이 정확하니 더 많은 일을 맡기게 되고, 더 많이 맡기니 맥락이 또 쌓인다.
데이터가 한곳에 모이면 중력이 생긴다. 그 데이터를 쓰는 일들이 주변으로 끌려오고, 그렇게 끌려온 일들이 다시 데이터를 낳는다. 작게 시작한 맥락 덩어리는 이렇게 스스로 몸집을 불리며, 누구도 쉽게 떼어낼 수 없는 인력장을 형성한다.
결정적 차이가 여기 있다. 모델 성능은 파는 쪽이 통제하지 못한다. 모델 회사가 올려주면 경쟁자도 똑같이 올라간다. 하지만 쌓인 맥락은 고객과 서비스가 함께 일하며 자란 것이다. 경쟁자가 돈을 더 쓴다고 하루아침에 사다 쓸 수 있는 게 아니다. 진짜 장벽과 가짜 장벽은 여기서 갈린다.
작은 가구 공방이 있다. 사장 혼자 영업하고, 외주 목공 두세 곳에 일을 나눠 준다. 어느 날 큰 거래처에서 연락이 온다. "이번 주문, 납기를 열흘 당겨줄 수 있나요."
맥락이 없는 일반 자동화 도구에 이 요청을 넣으면, 정중한 답장 초안이 나온다. 문장은 매끄럽다. 하지만 거기까지다. 열흘을 당기는 게 가능한지는 사장이 직접 머릿속으로 계산해야 한다. 어느 외주가 지금 여유가 있는지, 이 거래처가 예전에도 급하다고 해놓고 결제를 늦춘 적이 있는지, 납기를 당기면 다른 주문이 밀리는지. 도구는 이걸 모른다. 결국 사장이 다 한다. 도구는 받아쓰기만 했다.
맥락이 쌓인 AI 프로젝트 매니저는 다르게 움직인다. 이 공방과 몇 달을 일했다면, 저 요청 한 줄에 여러 개가 걸려 있다는 걸 안다. 지난 분기 이 거래처가 비슷한 요청을 두 번 했고 결제는 평균보다 늦었다는 기록이 있다. 외주 A는 다른 건으로 꽉 찼고 B는 이번 주 여유가 있다는 것도 최근 일정에서 안다. 그래서 초안만 던지지 않는다. "이 거래처는 결제가 늦은 편이니 선입금 조건을 붙이는 게 어떻겠냐", "B에 맡기면 열흘 당기는 게 가능해 보인다, 다만 다음 주 다른 주문이 이틀 밀린다" 같은 판단까지 얹어 올린다.
두 경우의 모델은 같을 수 있다. 격차는 그 사이에 쌓인 몇 달치 맥락에서 나왔다.
여기서 한 겹 더 들어가 보자. 이 공방이 쌓은 것은 두 종류다. 하나는 거래처 목록, 과거 주문 내역, 결제가 며칠씩 늦었다는 기록 같은 원자료다. 표로 뽑아 다른 서비스에 넘기기 쉽다. 다른 하나는 그 위에서 깎아낸 판단 방식이다. "이 거래처엔 선입금을 거는 게 낫다", "이런 급한 요청은 B에 돌린다" 같은 결론은, 수많은 사례에서 무엇이 어긋났고 무엇이 통했는지를 겪으며 서비스가 다듬은 것이다. 이 판단 규칙도 문서나 메모리로 적어 두면 내보낼 수 있다. 실제로 Claude 같은 서비스는 쌓인 메모리를 내보내고 다른 환경으로 가져오는 기능을 제공한다(공식 안내). 다만 규칙을 옮긴다고 성능까지 그대로 재현되는 건 아니다. 새 서비스가 같은 판단에 안정적으로 도달하려면 대개 다시 적잖은 적응과 시행착오가 필요하다.
그래서 전환 비용이 생긴다. 전환 비용이란 다른 서비스로 옮길 때 치러야 하는 대가다. 돈만이 아니라, 처음부터 다시 다 가르치는 시간과 번거로움, 그사이 품질이 떨어지는 위험까지 전부 비용이다. 공방이 갈아타는 순간, 원자료도 판단 규칙도 내보낼 수는 있지만, 새 서비스가 예전만큼 손발이 맞기까지는 다시 길들이는 시간이 든다. 사장이 이걸 한번 겪고 나면, 어지간해서는 갈아타지 않는다.
여기서 경쟁 분석의 요령이 하나 나온다. 어떤 서비스의 힘을 가늠하려면 "얼마나 똑똑한가"보다 "떠날 때 무엇을 잃는가"를 물어야 한다. 떠나도 잃을 게 없으면 해자가 없는 것이다. 모델만 좋은 서비스가 그렇다. 반대로 떠날 때 몇 달치 적응을 처음부터 다시 쌓아야 하는 서비스는, 모델이 평범해도 쉽게 뺏기지 않는다.
단, 전환 비용은 가입 첫날엔 0이다. 쌓인 게 없으니까. 이 해자는 시간이 만든다. 바꿔 말하면, 초반에 고객을 붙잡아 맥락이 쌓이기 시작할 때까지 버티게 하는 설계가 반년 뒤 해자의 크기를 정한다.
그럼 맥락만 많이 쌓으면 이기는가. 그렇게 단순하지 않다. 세 가지 함정이 있다.
첫째, 전환 비용은 고객을 묶지만 지나치면 가둔다. 나가려는데 내 데이터를 못 빼 간다고 느끼는 순간, 그건 해자가 아니라 족쇄다. 족쇄를 채운 서비스는 평판으로 대가를 치른다. 오래 가는 해자는 "못 나가게 막아서"가 아니라 "나갈 수 있는데도 안 나가서" 생긴다. 원자료든 판단 규칙이든 언제든 내보낼 수 있게 열어두는 쪽이 길게 이긴다.
둘째, 맥락은 신선할 때만 자산이다. 반년 전 거래처 사정이 지금과 다르면, 오래된 맥락은 오히려 틀린 판단을 부른다. 쌓는 것만큼 버리고 갱신하는 설계가 중요하다. 쌓인 양을 자랑하는 서비스보다, 그걸 어떻게 최신으로 유지하는지 설명하는 서비스를 더 믿을 만하다.
셋째, 맥락이 깊어질수록 책임도 커진다. 그 회사의 결제 이력, 거래처 관계, 내부 사정을 안다는 건 그만큼 민감한 걸 쥐고 있다는 뜻이다. 이걸 어떻게 지키고, 어디까지 쓰고, 누구에게 안 보여주는지가 흐릿한 서비스는, 맥락이 깊어질수록 위험도 같이 깊어진다. 깊은 맥락과 그 맥락을 다루는 신뢰는 한 몸으로 가야 한다.
정리하면 경쟁자를 볼 때 봐야 할 곳이 바뀐다. 데모 화면의 매끄러움은 맥락이 0인 상태의 성능이고, 그건 어차피 다들 비슷하다. 질문은 하나로 모인다. 이 서비스는 고객의 맥락을 어떻게 자산으로 바꾸고 있는가.
이 맥락 해자를 파려는 시도는 서비스 형태마다 다르게 나타난다. 어떤 서비스는 고객의 흩어진 문서 더미를 한곳에 모아 검색 가능한 기억으로 바꾸고, 어떤 서비스는 업무 흐름 자체에 끼어들어 결정의 근거를 적립한다.
온틀(ONTLE)이 택한 형태는 파견형이다. 사람을 대신 세우는 게 아니라, 사람을 더 뽑기 어려운 소기업이나 1인 창업가가 매일 반복하는 판단 업무를 곁에서 떠안아 손을 더는 쪽이다. 앞의 가구 공방을 다시 떠올리면, 파견형이 쌓는 맥락은 이런 것이다. 어느 거래처가 결제가 늦는지, 급한 주문을 어느 외주에 돌려왔는지, 사장이 어떤 조건에서 거절해 왔는지. 손을 덜어주려면 그 회사 사정을 알아야 하고, 알려면 곁에서 겪으며 쌓여야 한다. 그렇게 쌓인 것이 곧 쉽게 떼어낼 수 없는 자리가 된다.
시장의 다음 단계도 여기서 갈린다. 지금은 "어느 모델을 쓰느냐"로 서비스를 광고하는 시기지만, 모델이 완전히 평준화되고 나면 그 문구는 힘을 잃는다. 그때 남는 질문은 결국 하나다. 당신과 반년을 일한 서비스는, 그 반년을 당신의 자산으로 바꿔 두었는가, 아니면 그냥 로그로 흘려보냈는가. 경쟁 분석의 무게중심을 모델에서 맥락으로 옮기는 것, 이게 이 시장을 읽는 가장 실용적인 각도다.
일의 절대량이 적어도 반복의 결은 분명히 있습니다. 거래처 성향, 선호하는 보고 방식, 과거에 어긋났던 지점 같은 건 규모와 무관하게 쌓입니다. 오히려 작은 회사일수록 사장 한 사람 머릿속에만 있던 암묵적 판단이 많아서, 그게 밖으로 쌓이기 시작하면 체감 효과가 더 큽니다. 중요한 건 양이 아니라 그 맥락이 다음 판단에 실제로 반영되느냐입니다.
건강한 서비스라면 가져갈 수 있어야 합니다. 서비스를 고를 때 "내 데이터를 내보낼 수 있는가"를 계약 전에 확인하는 걸 권합니다. 내보내기를 떳떳하게 열어두는 쪽이, 역설적으로 더 믿을 만하고 더 오래 선택받습니다.
반대입니다. 모델이 좋아질수록 맥락의 값이 올라갑니다. 똑똑한 사람에게 회사 사정을 잘 설명할수록 더 좋은 판단이 나오는 것과 같습니다. 모델이 좋아진다고 당신 회사의 사정을 알 필요가 없어지지는 않습니다. 오히려 같은 모델을 쓰는 경쟁자 사이에서 맥락 격차가 더 또렷하게 드러납니다.
오픈소스로 평준화되는 건 모델과 도구 쪽입니다. 그건 원래 해자가 아니었습니다. 특정 고객과 쌓은 맥락은 오픈소스로 풀 수 있는 성질의 것이 아닙니다. 공짜 도구가 많아질수록, 차별점은 그 도구로 무엇을 쌓았느냐 쪽으로 더 쏠립니다.