Agentforce, Copilot Studio 너머: 왜 어떤 기업은 개방형, 셀프 호스팅 런타임을 택하는가

결론부터 말하면: 닫힌 스위트는 자기 생태계 안에서 이긴다 — 당신의 세계 전체가 한 벤더의 담장 안에 있다면 그렇다. 데이터가 여러 시스템에 흩어져 있고, 직접 보유해야 하며, 모델 선택권을 원한다면, 개방형 셀프 호스팅 런타임(또는 둘 다 쓰기)이 정답이다.

한 회사가 AI agent 선정을 하는데, 후보 명단은 자연스러웠다. Agentforce, Copilot Studio, ServiceNow AI Agents. 셋 다 강하고, 셋 다 추천하는 사람이 있었다.

그들은 하마터면 Agentforce를 계약할 뻔했다 — CRM 시나리오 시연이 가장 화려했다. 막판 직전, 한 아키텍트가 질문을 던졌다. “우리가 agent에게 처리시키려는 고객 문제 중, 절반은 Salesforce의 상담을 조회해야 하고, 절반은 우리 자체 구축 시스템의 납품과 작업 지시를 조회해야 합니다. Agentforce는 담장 밖의 그 절반을 어떻게 가져옵니까?”

영업의 답은 “통합하면 됩니다”였다. 그래서 그들은 6주를 들여 통합 PoC를 만들었다. 결론은 분명했다. 연결은 되지만, 담장 밖 시스템을 하나 더 붙일 때마다 동기화를 한 벌 다시 쓰고, 기준을 한 번 정렬하고, 끊길 파이프라인 하나를 유지보수해야 했다 — 그리고 그들의 담장 밖 시스템은 일고여덟 개였다. 그제야 팀은 깨달았다. 문제는 Agentforce가 충분히 좋지 않은 데 있지 않고, 그것이 다른 두 회사와 마찬가지로 이 회사에 성립하지 않는 전제 하나를 가정한 데 있다.

6주와 PoC 하나의 비용으로, 사실 처음부터 생각해 낼 수 있었던 교훈 하나를 샀다.

입 밖에 내지 않은 그 전제: 당신의 세계가 한 담장 안에 다 있다

이런 제품군의 강함은 본질적으로 ‘생태계 내 최적’이다. Agentforce는 당신의 고객, 프로세스, 객체가 이미 Salesforce 안에 있다고 가정한다. Copilot Studio는 당신의 협업, 문서, 신원이 365 안에 있다고 가정한다. ServiceNow는 당신의 프로세스가 그 위에 있다고 가정한다. 전제가 성립할 때 그것들은 확실히 손이 덜 간다 — 데이터가 기성품, 권한이 기성품, 통합이 기성품이라, agent가 거의 손쉽게 연결된다.

하지만 이 전제는 대부분 기업에 성립하지 않는다. 진짜 기업은 이렇게 생겼다. CRM은 한 회사, ERP는 다른 회사, 작업 지시는 세 번째 회사, 게다가 한 무더기의 자체 구축 시스템과 스프레드시트. 그들은 모델 선택권을 유지하고 싶어 한다. 모델이 1년에 한 번씩 바뀌기 때문이다. 그들은 규제 제약을 받아 데이터를 함부로 역외로 내보낼 수 없다. 이런 기업에게 ‘생태계 내 최적’은 오히려 제약이 된다 — 당신의 세계가 애초에 어느 한 회사의 담장 안에 있지 않기 때문이다. 담장 밖 시스템을 하나 붙일 때마다 파이프라인 하나를 다시 써야 하는 것, 그것이 바로 그 회사가 PoC에서 부딪힌 담장이다.

펼쳐서 비교: 누가 더 좋은가가 아니라, 각자 누구에게 맞는가

차원	닫힌 제품군(Agentforce / Copilot / ServiceNow)	개방형 셀프 호스팅 런타임(ObjectStack / ObjectOS)
가장 적합한 곳	비즈니스가 이미 그 생태계에 심하게 집중됨	데이터가 여러 시스템에 흩어짐, 스택 횡단, 직접 보유 필요
데이터 위치	벤더 클라우드	당신 자신의 인프라
모델 선택	자사 또는 묶인 모델 편향	자유롭게 교체, 모델은 밖에 런타임은 안에
비즈니스 정의 귀속	플랫폼에 자라남	당신 저장소 안의 오픈 프로토콜 메타데이터(Apache 2.0)
과금	동작당 / 좌석당	런타임과 인프라에 따름, 사용량과 탈동조
출발 자세	먼저 비즈니스를 생태계로 옮김	기존 시스템을 확장, 먼저 이전할 것을 요구하지 않음

이 표에는 ‘전부 옳은’ 열이 없다.

먼저 찬물 두 바가지: 많은 경우, 당신은 제품군을 택해야 한다

먼저 말해 두자. 이 글이 일방적인 홍보가 되지 않도록. 개방형 셀프 호스팅은 더 고결한 선택이 아니라 특정한 처지를 위해 준비된 선택이다 — 그리고 많은 회사의 처지는 하필 제품군에 맞다.

첫째, 당신의 세계가 정말 기본적으로 한 담장 안에 있다면. 비즈니스의 90%가 Salesforce 안에 있고, 데이터 역외 반출에도 개의치 않고, 모델을 바꿀 생각도 없다면 — Agentforce가 십중팔구 최적해다. 아직 일어나지 않은 ‘락인되지 않기’ 리스크를 위해, 눈앞의 실질적인 이전과 운영 부담을 떠안는 것은 수지가 안 맞는다.

둘째, 당신에게 플랫폼 팀이 없다면. 이것은 고전적인 ‘자체 구축 vs 구매’다. 개방형, 셀프 호스팅은 당신이 직접 그것을 운영해야 한다는 뜻이다 — 패치 적용, 가용성 보장, 업그레이드 관리. 제품군의 그 ‘바로 쓸 수 있고, 사고가 나면 전화 받아 줄 사람이 있고, SLA가 받쳐 주는’ 매니지드 경험은, 전담 플랫폼 팀이 없는 회사에게는 종종 ‘완전한 통제권’보다 더 값나가고 더 손이 덜 간다. 통제권에는 운영 비용이 있고, 아무도 받쳐 줄 수 없는 통제권은 짐이다.

그런데 ‘제품군 구매’로 아끼는 일은 당신 생각만큼 많지 않다

다만 ‘구매’라는 쪽에는, 자주 빠뜨리고 계산하는 비용 하나가 있다. 통합세다.

제품군 견적서에 적힌 것은 좌석 또는 동작의 돈이고, 적히지 않은 것은 — 당신의 그 일고여덟 개 담장 밖 시스템, 그 하나하나에 통합 파이프라인 하나씩이 필요하다는 것이다. 만들 때는 기준을 정렬해야 하고, 만든 다음에는 양쪽의 업그레이드를 따라 지속 유지보수해야 하며, 어느 한쪽이 필드를 바꾸면 파이프라인이 소리 없이 끊길 수 있다. 서두의 그 회사의 6주 PoC가 잰 것이 바로 이 세금의 계약금이다. 그래서 ‘제품군 구매 + 한 무더기의 깨지기 쉬운 통합’은 표면적으로는 buy이지만, 속을 보면 당신은 여전히 build를 하고 있다 — 게다가 build하는 것이 가장 가치 없고 가장 깨지기 쉬운 부분이다.

이 통합세를 TCO에 넣어 계산하면, ‘구매가 더 손이 덜 간다’는 결론은 당신의 담장 밖 시스템이 매우 적거나, 그것들이 애초에 agent에 닿을 필요가 없을 때만 안정적이다. 시스템이 흩어질수록 이 세금이 무거워지고, 제품군의 ‘손이 덜 간다’는 우위는 더 많이 갉아먹힌다.

사실 둘 다 쓸 수 있다: 하이브리드는 양다리가 아니다

이것이 선정 논의에서 오랫동안 간과된 선택지 하나를 끌어낸다. 이것은 꼭 단일 선택 문제가 아니다.

가장 실용적인 아키텍처는 종종 하이브리드다. 당신이 실제로 심하게 쓰는 그 생태계 안에서는 계속 그 제품군을 쓴다 — Salesforce 안의 영업 agent는 Agentforce가 가장 잘하는 일을 하게 둔다. 하지만 시스템을 횡단하고, 기준을 통일하고, 데이터를 직접 보유해야 하는 그 계층에서는, 개방형, 셀프 호스팅 런타임으로 연결 조직을 한다. 후자는 제품군을 대체하지 않는다. 그것이 하는 일은 제품군이 구조적으로 잘 못하는 그 일이다. 여러 담장에 흩어진 비즈니스를, 당신 자신이 소유하고 권한과 감사가 붙은 한 벌의 통일된 정의로 거둬들이는 것.

다른 말로 하면, 개방형 런타임은 당신의 여러 시스템(그 제품군들 포함) 위의 연결 조직이 될 수 있지, 당신더러 이사 들어오라는 또 하나의 담장이 아니다. 이 점을 인정하면, 선정은 ‘어느 한 회사에 걸까’에서 ‘어느 부분은 제품군으로, 어느 부분은 개방으로’로 바뀐다 — 이것이 바로 대부분 진짜 기업이 결국 도입하는 모습이다.

개방형 셀프 호스팅은 도대체 무엇을 가져다주나

당신이 오른쪽 열에 속하거나, 하려는 것이 바로 그 시스템 횡단 연결 계층이라면, ‘개방 + 셀프 호스팅’이 가져다주는 것은 정서가 아니라 구체적인 능력이다. 가장 잘 설명하는 것은 그것이 기존 시스템을 대하는 자세다 — 그리고 그것이 바로 서두의 그 회사가 막힌 지점이다.

제품군은 당신의 세계가 자기 담장 안으로 이사 오기를 바란다. 개방형 런타임은 당신의 세계가 본래 흩어져 있다고 가정하며, 그것의 일은 기존 시스템이 AI를 네이티브로 지원하게 하는 것이지 먼저 이전하는 것이 아니다. 그 회사의 고객 데이터는 절반이 Salesforce에, 절반이 자체 구축 시스템에 있었다. ObjectOS 위에서는 양쪽을 각각 데이터소스로 연결해 객체로 모델링하고, 공유 키(사업자번호)를 기준으로 하나의 거버넌스가 적용된 ‘고객’으로 정렬할 수 있다.

export const Customer = ObjectSchema.create({
  name: 'crm_customer',
  label: '고객',
  fields: {
    name: Field.text({ label: '고객명', required: true }),
    tax_id: Field.text({ label: '사업자번호' }), // 시스템 간 "같은 고객"을 맞추는 공유 키
  },
});

차이는 한 번의 질문으로 구체화할 수 있다. “이 고객은 자원을 들여 지킬 가치가 있나?” —

이전: agent가 Salesforce에 연결되어, 상담이 활발한 것을 보고 “가치 있다”고 답한다. 그것은 자체 구축 시스템에서 이 고객의 납품이 계속 지연되고 작업 지시가 적체되고 있다는 것을 전혀 모른다.
이후: agent가 마주하는 것은 하나의 통일된 고객이다. 상담, 납품, 작업 지시를 함께 보고 “상담은 좋지만 납품 리스크가 높다, 먼저 이행을 해결한 다음 확대 영업을 논하라”고 답한다.

같은 모델, 같은 질문인데, 단지 발밑의 ‘고객’이 더 이상 담장에 잘리지 않았다는 이유만으로 결론은 단편에서 전체로 바뀐다. 그리고 이 모든 것이 담장 밖 시스템마다 동기화 파이프라인을 다시 쓸 필요가 없다 — 비즈니스 정의는 당신 저장소 안의 diff 가능하고 이전 가능한 메타데이터다. 런타임은 당신 자신의 인프라 위에서 돌아가며 권한을 강제하고 감사를 기록한다. 모델은 외부 어느 회사 것이든 올 수 있다. 당신은 ‘자기 비즈니스의 정의’를 어느 한 회사에 보관시키지 않았다.

정직한 선택 문제

그러니 이것은 ‘누가 도태되어야 하나’가 아니라 ‘어느 부분을 누구에게 맡기나’다. 자신에게 세 가지를 물어라.

내 비즈니스는 기본적으로 어느 한 생태계에 있나, 아니면 여러 시스템에 흩어져 있나?
데이터가 지속적으로 벤더 클라우드로 흘러가는 것을 받아들일 수 있나? 컴플라이언스상 서명할 수 있나?
나에게 셀프 호스팅 런타임을 운영할 팀이 있나?

앞의 두 답이 ‘흩어졌다, 안 된다’에 가깝고 세 번째가 ‘있다’에 가깝다면 — 당신이 찾는 것은 애초에 또 하나의 더 강한 닫힌 제품군이 아니다, 적어도 그 시스템 횡단 계층에서는 아니다. 세 답이 모두 반대편에 가깝다면, 그냥 시원하게 제품군을 써라. 그것들은 확실히 쓸 만하다. 정직하게 자리를 찾아 앉고, 심지어 시원하게 섞어 쓰는 것이, 어느 한 회사의 기능이 더 새롭냐를 좇는 것보다 훨씬 중요하다 — 그리고 6주를 들여 PoC를 만든 다음에야 깨닫는 것보다 훨씬 싸다.

맺으며

닫힌 제품군이 이기는 것은 ‘생태계 내 최적’이고, 이 우위는 그 전제가 성립할 때 매우 진짜이며 부정되어서는 안 된다. 개방형 셀프 호스팅 런타임이 이기는 것은 ‘전제가 성립하지 않을 때도 여전히 성립한다’다 — 당신의 세계가 흩어져 있고, 데이터를 직접 보유해야 하고, 모델이 자유로워야 하고, 정의를 자기 손에 쥐어야 하며, 게다가 그것을 직접 운영하는 책임을 감당할 수 있을 때.

어느 부분은 제품군을 써야 하고, 어느 부분은 개방을 써야 하며, 그를 위해 각각 어떤 대가를 내는지를 아는 것 — 이것이 어느 한 회사의 기능 목록보다 중요하다. 서두의 그 회사가 그 세 질문을 좀 더 일찍 물었다면, 6주와 PoC 하나를 아낄 수 있었을 것이다.

npm i -g @objectstack/cli && os start

이전할 필요 없이, 누구의 담장에 들어갈 필요 없이, 5분 만에 자신의 환경에서 두 시스템을 가로지르는 통일된 객체 하나를 띄워 보고, 이 길이 당신이 원하던 모습에 더 가까운지 판단하라.