LLM Wrapper 제작을 중단하세요: 도메인 지식만이 지속 가능한 유일한 AI 해자(Moat)입니다

SaaS를 구축하고 있다면, 고객들은 스스로 소프트웨어를 만드는 것에 점점 더 가까워지고 있습니다.

소규모 비즈니스 소유자는 자신의 워크플로우(Workflow)를 AI 도구에 설명함으로써 작동하는 무언가를 얻을 수 있습니다. 과거에 소규모 비즈니스가 귀사와 같은 소프트웨어 기업에 의존하게 만들었던 '직접 구축 vs 구매(build-vs-buy)' 사이의 격차가 좁혀지고 있습니다.

만약 당신의 유일한 강점이 "우리는 AI를 추가했다"라면, 당신은 이미 뒤처진 것입니다.

그것은 고객을 위해 구축된 전략이 아니라, 주주들을 위해 작성된 기능 발표일 뿐입니다.

Jobber에서 소프트웨어 엔지니어링 인턴으로 근무하면서 SaaS에서의 AI에 대한 제 생각은 바뀌었습니다. Jobber는 배관공, 전기 기술자, HVAC(냉난방 공조) 기술자, 조경사, 청소업체 등 블루칼라(Blue-collar) 기업을 위한 소프트웨어를 구축합니다.

당신이 이해하지 못하는 고객을 위한 AI는 구축할 수 없습니다.

Jobber가 누구를 위해 제품을 만드는지에 대해 제가 배운 점은 다음과 같습니다.

피치 덱(Pitch deck)을 가진 모든 소프트웨어 기업은 "AI 우선(AI-first)"이라고 말합니다. 대부분은 "ChatGPT API 호출을 추가하고 어딘가에 반짝이는 아이콘을 넣었다"는 뜻입니다. 그것은 해자(Moat)가 아닙니다. 해자란 경쟁자가 쉽게 복제할 수 없는 지속 가능한 우위를 의미합니다. 어떤 경쟁자라도 스프린트(Sprint) 기간 내에 얇은 모델 호출(Model call) 기능을 출시할 수 있습니다. 모델 접근성은 기본 요건(Table stakes)일 뿐입니다. 진정한 강점은 모델이 어떤 고객 문제를 해결해야 하는지, 어떤 컨텍스트(Context)가 필요한지, 그리고 언제 개입하지 않고 물러나 있어야 하는지를 아는 것입니다. 누구도 빠르게 복제할 수 없는 것은 바로 당신이 고객에 대해 알고 있는 지식입니다.

Blake를 만나보세요

Jobber에서 제품 팀은 소프트웨어를 사용하는 사람들에 대한 상세한 그림을 그립니다. 이는 제품 결정이 실제 고객이 필요로 하는 것에 기반하도록 유지해 줍니다. Blake는 그중 한 명입니다.

Blake는 두 개의 팀을 운영하는 전기 회사를 운영합니다. 그는 집에 걸음마 단계의 아이가 있고 스케줄이 항상 꽉 차 있습니다. 하지만 스케줄이 꽉 차 있다고 해서 비즈니스가 원활하게 돌아가는 것은 아닙니다.

견적서(Quotes)는 여전히 무시되곤 합니다. Blake가 견적서를 보내면 고객은 침묵하고, 그가 후속 조치를 취할 시간을 갖기도 전에 잠재 고객(Lead)의 관심은 식어버립니다. 그의 워크플로우 중 그 어떤 것도 일이 잘못되기 전에 이를 포착하지 못합니다.

업무 시간 외의 전화가 쌓여갑니다. 집주인들은 오후 7시에 콘센트에서 타는 냄새가 난다거나 집 절반의 전등이 꺼졌다는 내용으로 전화를 겁니다. Blake는 항상 전화를 받을 수 없기에, 전화는 음성 사서함으로 넘어갑니다. 어떤 전화는 다음 날 아침에 회신되지만, 어떤 전화는 그렇지 못합니다.

그다음은 고객 메시지입니다. Blake는 고객과 대화하는 법을 잘 알지만, 현장에서 긴 하루를 보낸 후 후속 조치를 작성하거나 견적서(Quote)를 마무리하는 데에는 그에게 없는 시간이 필요합니다.

이것은 체계적이지 못한 계약업사에 대한 이야기가 아닙니다. Blake는 자기 일을 잘합니다. 이러한 마찰 지점(Friction points)은 구조적인 문제이며, 두 개의 팀으로 운영되는 전기 사업이 돌아가는 방식 자체에 내재되어 있습니다. 놓친 전화, 늦은 밤의 행정 업무, 백지 상태에서 고민하는 순간들. 이러한 일들은 모든 계약업사에게 예측 가능한 패턴으로 발생합니다.

그것이 바로 Jobber의 제품 팀이 시간을 들여 배우는 내용입니다. 이상적인 형태의 업무 일과가 아니라, 마찰을 포함하여 실제 하루가 어떻게 흘러가는지를 배우는 것입니다.

범용 AI는 대체되지만, 도메인 지식은 대체되지 않습니다.

ChatGPT나 Claude와 같은 도구들이 발전함에 따라, 단순히 이들을 감싸는(Wrap) AI 기능들은 서로 대체 가능한 수준이 됩니다. 여기서 "감싼다(Wrap)"는 의미는, 근본적인 워크플로우(Workflow)는 변하지 않으면서 모델 호출(Model call) 주위에 얇은 UI(User Interface)만 씌운 것을 뜻합니다. 더 나은 툴링(Tooling)도, 더 날카로운 제품 로직(Product logic)도, 업무를 더 쉽게 만드는 경로도 없습니다. 서비스 사업 운영자는 종종 ChatGPT를 무료로 열어보는 것만으로도 동일한 결과를 얻을 수 있습니다.

그러한 도구들이 동일한 작업을 직접 수행할 수 있게 되면, 도메인 지식(Domain knowledge)이 없는 래퍼(Wrapper)는 시장에서 경쟁할 자리가 없습니다. 서비스 사업 운영자가 모델이 이미 스스로 할 수 있는 일을 수행하는 제품에 추가 비용을 지불할 이유는 없습니다. 오늘날 대부분의 AI 제품 작업은 타인의 인프라(Infrastructure) 위에 얹혀진 얇은 UI에 불과합니다.

첫 번째 문제는 경쟁 측면입니다. AI 도구를 사용하는 소규모 팀은 과거 대기업이 한 분기 내내 걸렸을 기능을 단 한 번의 스프린트(Sprint) 만에 출시할 수 있게 되었습니다. 다른 모든 이들에게는 진입 장벽이 낮아진 것입니다.

두 번째 문제는 바로 당신의 고객으로부터 발생합니다. 노코드(No-code) 도구는 기술적 지식이 없는 비즈니스 소유자가 설명만으로 작동하는 앱을 구축할 수 있게 해줍니다. 배관공이 노코드 에이전트(No-code agent)에게 프롬프트를 입력하여 Jobber를 다시 만들어낼 수는 없습니다. 적어도 오늘은 말이죠. 하지만 그 경계선은 계속해서 이동하고 있습니다. 매년 더 많은 워크플로우(Workflow)의 복잡성이 고객이 스스로 구축할 수 있는 영역으로 넘어가고 있습니다.

만약 당신의 소프트웨어가 고객이 이미 자신의 일상에 대해 이해하고 있는 것들만 수행한다면, 고객은 당신을 배제하고 스스로 구축할 것입니다.

살아남는 소프트웨어 기업은 더 나은 모델을 선택함으로써 승리하지 않습니다. 그들은 어떤 경쟁자보다 고객을 더 잘 이해함으로써 승리할 것입니다. 이는 고객이 실제로 어떻게 일하는지, 그리고 업무에 밀착했을 때만 나타나는 패턴들을 수년간 학습해야 함을 의미합니다. 기성(Off-the-shelf) 모델 중 그 어떤 것도 이를 가지고 있지 않습니다.

Jobber의 제품 팀은 지붕 수리공이 일회성 고객에게 보내는 문자 메시지가, 2년 동안 서비스를 제공해 온 고객에게 청소업자가 보내는 메시지와는 다르다는 것을 알고 있습니다. 하나는 일회성 작업일 수 있지만, 다른 하나는 더 따뜻한 어조가 자연스러운 지속적인 고객 관계일 수 있습니다. 그들은 대화 도중에 채널을 전환하는 것이 고객을 당황하게 만든다는 것도 알고 있습니다. 어떤 작업이 밤사이에 예약되는지, 어떤 작업이 먼저 대화가 필요한지도 알고 있습니다. 따라서 Blake의 인용구 후속 조치는 적절한 시점에 적절한 채널로 발송됩니다.

그러한 지식은 인터넷을 스크래핑(Scraping)해서 얻은 것이 아닙니다. 제품 팀은 수년간 비즈니스 소유자들과 함께 시간을 보냈습니다. 그들은 배운 것을 이들 기업의 실제 워크플로우에 적합한 기능(Feature)으로 전환했습니다.

그러한 종류의 이해도를 구축한다면, 그 누구도 이를 복제할 수 없습니다.

이해하지 못하는 결과(Outcome)를 위해 설계할 수는 없습니다.

챗봇(Chatbot)은 질문에 답하고 멈춥니다. 에이전트(Agent)는 그 결과에 따라 행동하며 작업이 완료될 때까지 계속 진행합니다. 이 차이는 대부분의 팀이 깨닫는 것보다 훨씬 더 중요합니다. 하나는 정보를 제공하고, 다른 하나는 행동합니다.

Blake는 오후 일정을 채팅으로 논의하고 싶어 하지 않습니다. Blake는 다른 집에서 콘센트를 수리하는 동안 오후 4시 통화가 처리되고, 작업이 예약되며, 고객에게 문자가 발송되기를 원합니다. 후속 조치 템플릿을 생성해 주는 챗봇(Chatbot)은 결과(Outcome)가 아닙니다. 그것은 오히려 더 많은 일을 만들어낼 뿐입니다.

스케줄링(Scheduling)을 예로 들어보겠습니다. 배관공의 하루는 반응적(Reactive)입니다. 응급 상황이 연쇄적으로 발생하고, 작업은 근처 위치에 따라 이동하며, 부품 가용성에 따라 전체 계획이 바뀔 수 있습니다. 조경 팀은 매주 동일한 경로를 운행합니다. 상업용 청소 업체는 건물이 업무 시간 외 청소를 위해 개방되는 시간에 맞춰 몇 주 전부터 예약을 잡습니다.

배관공, 조경사, 상업용 청소 업체 모두 이를 "스케줄링"이라고 부릅니다. 유사점은 거기까지입니다.

일반적인 스케줄링 가정은 계약업체(Contractor)들이 직접 사용해 볼 때만 나타나는 방식으로 무너집니다. 잘못된 판단을 내리는 AI는 AI가 아예 없는 것보다 더 빠르게 소프트웨어에 대한 신뢰를 떨어뜨립니다. 계약업체들은 고객 앞에서 자신을 신뢰할 수 없는 사람처럼 보이게 만드는 도구에게 두 번의 기회를 주지 않습니다.

그 지점이 바로 Jobber의 AI Receptionist가 필요한 곳입니다. Blake는 두 개의 팀을 운영하는 전기 사업체를 운영하며, 집주인들이 업무 시간 이후에 전화할 때 항상 응답할 수는 없습니다. Receptionist가 해당 전화들을 처리합니다. 전화를 받고, Blake가 가능한 작업 유형을 기반으로 예약을 잡으며, 검토를 위한 작업 요청을 생성하고, 확인 메시지를 보냅니다. Blake는 밤사이 일어난 일에 대한 요약과 이미 캘린더에 등록된 예약 사항을 확인하며 잠에서 깹니다. 놓치는 비즈니스가 없습니다.

제품 팀은 이를 일반적인 자동화(Automation)가 아닌 Blake의 결과(Outcome)를 중심으로 구축했습니다. 이는 밤사이 놓친 전화가 전기 계약업체에게 어떤 비용을 초래하는지, 그리고 집주인이 예약을 신뢰하기 전에 무엇을 들어야 하는지를 이해할 때만 가능합니다. 그 답은 모델(Model)에서 나오는 것이 아닙니다. 고객을 아는 것에서 나옵니다.

"좋음"은 도메인(Domain) 내부에서만 의미를 갖습니다.

계약업체(Contractor)와 대화해 본 적 없는 개발자에게 견적 후속 조치를 위한 "전문적인 어조 (Professional tone)"를 정의해 보라고 해보세요. 그다음 15년 동안 사업을 해온 전기 기술자에게 물어보세요. 두 가지 답변이 나올 것입니다. 그리고 그중 오직 하나만이 고객에게 제대로 전달됩니다.

정의되지 않은 모든 표준은 여러분의 도메인 지식 (Domain knowledge)의 공백입니다. "전문적인 (Professional)", "친절한 (Friendly)", "도움이 되는 (Helpful)" 같은 단어들 말입니다. 전기 기술자와 조경사는 이 단어들을 서로 다르게 사용합니다. 모델은 그 사실을 모릅니다. 여러분이 이를 정의하지 않으면, 모델은 자신의 추측으로 그 공백을 채워버립니다. 여러분은 고객이 메시지를 읽고 난 후에야 실수를 발견하게 될 뿐입니다. 신뢰할 수 있는 시스템을 구축할 수 있을 만큼 이 단어들을 정밀하게 정의하는 것이 바로 실제 제품 작업 (Product work)입니다.

Blake의 고객 메시지는 작성하는 데 너무 오래 걸리곤 했습니다. 쉬운 해결책은 "메시지를 더 좋게 만들어주는 AI"를 출시하는 것이었을 겁니다. 하지만 제품 팀 (Product teams)은 대신 구체적인 어조를 정의했습니다: 전문적인 (Professional), 캐주얼한 (Casual), 쾌활한 (Cheerful), 더 짧은 (Shorter). 각 옵션은 계약업체들이 고객에게 메시지를 쓰는 시점에 대한 연구를 통해 도출되었습니다.

상황에 따라 다른 어조가 필요하다는 것은 당연합니다. 하지만 4,000달러짜리 견적서를 들고 있는 주택 소유주에게 "전문적인 (Professional)" 어조가 어떻게 들릴지는 그리 명확하지 않습니다. 고객이 단 한 번 만난 기술자에게 "캐주얼한 (Casual)" 어조가 무엇을 의미하는지도 마찬가지입니다. 그러한 정의들이 곧 제품입니다. 어조 레이블 (Tone labels)은 그 위에 달린 손잡이에 불과합니다.

모든 어조 선택은 신호 (Signal)입니다. 모든 편집은 신호입니다. 수정 없이 전송되는 모든 메시지 또한 신호입니다. 수백만 개의 메시지를 거치며, 이는 그 어떤 파운데이션 모델 (Foundation model)도 가질 수 없는 플라이휠 (Flywheel)이 됩니다. 팀들은 수년에 걸쳐 이 플라이휠을 구축합니다. 그들은 창문 청소업체가 고객에게 어떻게 문자를 보내는지 배웁니다. 전기 기술자가 상업용 작업에 대해 어떻게 견적을 내는지 배웁니다.

그것이 바로 도메인 지식 해자 (Domain knowledge moat)입니다. 단순히 더 나은 모델도 아니고, 단순히 영리한 프롬프트 (Prompt)도 아닙니다. 프롬프트는 팀이 이미 도메인 내부에서 무엇이 '좋은 것'인지 정의했을 때에만 작동합니다. 블루칼라 서비스 업무에서 무엇이 좋은 것인지 수년간 파악하고, 그 지식을 고객이 제품에서 느낄 수 있는 방식으로 적용하는 것입니다.

서비스 사업 소유주들은 자신의 세계를 이해하는 AI만을 신뢰합니다.

서비스 사업 소유주들은 낭비할 시간이 없습니다. 그들이 시도해 본 대부분의 AI 기능은 도움이 되지 않았습니다. 오히려 많은 경우 더 많은 업무를 만들어냈습니다. 그들이 사용하는 소프트웨어에 새로운 "AI 기반 (AI-powered)" 기능이 나타나면, 가장 먼저 드는 생각은 "이것은 내 시간을 낭비하게 만들 것이다"입니다.

제품 팀은 소유주에게 제어권 (control)을 부여함으로써 서비스 사업 소유주의 신뢰를 얻습니다. 당신의 AI가 고객 앞에서 계약업자 (contractor)를 신뢰할 수 없는 사람처럼 보이게 만드는 순간, 신뢰는 깨집니다.

Jobber Copilot은 제품 내에 구축된 AI 어시스턴트 (AI assistant)입니다. 이 기능은 서비스 사업 소유주의 데이터를 알고 있습니다. 질문을 던지면 소유주 자신의 수치를 바탕으로 답변합니다. 어느 목요일, Blake는 Copilot에게 물었습니다: "오늘 어떤 미결 견적서 (open quotes)를 후속 조치해야 할까요?" Copilot은 미결 견적서 목록을 짧게 반환했으며, 각 항목에는 왜 후속 조치를 취할 가치가 있는지에 대한 맥락 (context)이 포함되어 있었습니다. Copilot은 Blake 자신의 영업 파이프라인 (sales pipeline)에서 정보를 가져왔고, 전기 계약업자 (electrical contractor)에게 중요한 신호들을 순위 매겼으며, Blake가 즉시 실행할 수 있는 것을 제공했습니다. Copilot은 Blake의 비즈니스에서 후속 조치가 어떤 모습이어야 하는지를 알고 있습니다. 그것이 실제로 업무를 수행합니다. Blake가 이를 신뢰한 이유는 제품이 자신의 비즈니스를 명확히 알고 있었기 때문입니다.

AI 리셉셔니스트 (AI Receptionist)도 같은 방식으로 작동합니다. 서비스 제공자들은 이 기능이 예약할 수 있는 작업 유형을 선택합니다. 전화 문의를 도와줄 수 없을 때 AI가 할 말을 설정합니다. 서비스 사업 소유주가 AI가 맡을 업무를 결정합니다. 이것이 계약업자들이 AI에 의존하는 이유입니다.

프롬프트 (prompt)는 복사할 수 있습니다. UI는 복제할 수 있습니다. 하지만 이러한 답변을 구축하기 위해 Jobber가 블루칼라 (blue-collar) 서비스 비즈니스가 어떻게 작동하는지 배우며 보낸 세월은? 그것은 복사할 수 없습니다. 그리고 소프트웨어가 비즈니스를 이해하고 있다는 것을 증명할 때, 서비스 사업 소유주들은 그 안의 AI를 더 기꺼이 신뢰하게 됩니다.

유일하게 지속되는 해자 (moat)

이러한 도구들을 실무에 투입한 후, Blake의 경험은 달라졌습니다. 견적 후속 조치는 원래 견적과 동일한 채널을 통해 제때 발송되었습니다. 업무 시간 외의 전화는 아침에 대기 중인 예약된 일정으로 바뀌었습니다. 고객 메시지 처리는 20분이 아닌 2분이 걸렸습니다. Copilot은 어떤 미결 견적서가 전화할 가치가 있는지, 그리고 그 이유는 무엇인지를 제시해 주었습니다.

이러한 결과 중 그 어느 것도 더 나은 모델 덕분에 얻어진 것이 아닙니다.

도메인 지식 (Domain knowledge)은 지속 가능한 유일한 AI 해자 (Moat)입니다. 범용 AI (Generic AI)는 대체 가능한 존재가 됩니다. 경쟁자들은 기능을 복제합니다. 이러한 블루칼라 (blue-collar) 비즈니스가 실제로 어떻게 운영되는지 아는 것은 어떤 경쟁자도 빠르게 따라잡을 수 없는 우위입니다. 그리고 그것은 그 어떤 모델의 학습 데이터 (training data)에도 들어있지 않습니다.

다음 AI 기능을 만들기 전에, Blake와 같은 서비스 비즈니스 소유주로부터 시작하세요. 실제 워크플로우 (workflow)를 따르십시오. 혼란스러운 지점, 임시방편 (workarounds), 그리고 귀하의 소프트웨어 외부에서 발생하는 작업들을 찾아내십시오. 당신이 발견한 것들을 중심으로 구축하십시오. 경쟁자가 다음 분기에 출시할 모델은 당신의 모델과 일치할 것입니다. 하지만 경쟁자에게는 Blake가 없을 것입니다.