모든 도구가 호출 가능해질 때, 채팅은 결합 계층(Join Layer)이 된다

모든 소프트웨어 스택에는 어떤 벤더(Vendor)도 판매하지 않는 숨겨진 계층이 있습니다. 바로 결합(Join)입니다. 이곳은 서로를 알지 못하는 두 제품이 함께 작동하도록 만들어지는 곳이며, 한 도구의 수치가 다른 도구의 결과물과 대조되어 조정되는 곳입니다. 지난 20년 동안 이 계층은 모든 제품의 외부에 존재했습니다. 내보내기(Export) 데이터를 조정하는 사람이나, 누군가가 구축하고 유지 관리하는 파이프라인(Pipeline) 속에 존재했습니다. 그것은 어떤 벤더의 소유도 아니었으며, 누구의 화면도 아니었습니다.

그 계층이 이동하고 있습니다. 벤더가 거대한 통합(Integration) 기능을 구축했기 때문이 아니라, 도구들이 호출 가능(Callable)해지고 있기 때문입니다. 제품이 MCP를 통해 자신의 기능(Functions)을 노출하면, 그것은 더 이상 방문하는 화면이 아니라 클라이언트(Client)가 호출할 수 있는 무언가가 됩니다. 그리고 클라이언트가 한 번에 하나 이상의 제품을 호출할 수 있는 순간, 클라이언트는 결합 계층이 항상 해왔던 일, 즉 하나에서 데이터를 가져오고 다른 하나에서도 가져와 실시간으로 조정하는 일을 할 수 있게 됩니다. 통합 지점은 제품 내부에 구축되는 것이 아닙니다. 그것은 모든 제품과 대시보드(Dashboard)로부터 한 단계 위로 올라가, 사용자가 이미 머물고 있는 채팅 클라이언트(Chat Client)로 떠오릅니다.

이것은 새로운 기능이 아니라 위상(Topology)의 변화입니다. 통합이 존재하는 형태가 변하고 있으며, 그 결과는 벤더의 전략에 직접적인 영향을 미칩니다. 완벽하고 독립적인 섬—가장 세련된 화면, 가장 풍부한 대시보드—이 되도록 설계된 도구는, 그 밑바닥에서 해체되고 있는 위상을 위해 최적화하고 있는 셈입니다. 이 변화를 구체적으로 확인하려면 가장 친숙한 별도 벤더 도구 스택인 고객 획득(Acquisition) 과정을 살펴보십시오. 광고(Ads), 양식(Forms), 분석(Analytics)은 각각 별개의 제품이며, 별개의 로그인과 별개의 사고 모델을 가집니다. 그리고 가장 결정적인 작업인 '광고 비용과 양식이 생성한 결과물을 대조하는 일'은 그 사이의 간극에서 수동 작업으로 남겨져 있습니다. 각 도구가 동일한 대화 안에서 호출 가능해질 때, 그 수동 작업에 어떤 일이 일어나는지 지켜보십시오.

결합 계층이 과거에 존재했던 곳

대부분의 제품 담당자들이 겉으로 잘 묻지 않는 질문으로 시작해 보겠습니다. 두 도구가 함께 작동해야 할 때, 그 작업은 물리적으로 어디에서 일어날까요?

지난 20년 동안 그 답은 "사람 내부에서, 혹은 누군가가 작성한 접착제(glue) 코드 안에서"였습니다. 만약 광고 플랫폼과 양식(form) 도구가 모두 비교가 필요한 수치를 보유하고 있다면, 사람이 곧 통합(integration) 역할을 수행했습니다. 양쪽을 모두 열고, 양쪽을 모두 내보내고(exporting), 양쪽을 모두 대조(reconciling)하는 식이었죠. 더 정교한 팀은 파이프라인(pipeline)을 구축했습니다. ETL 작업, 데이터 웨어하우스(data warehouse), 그리고 각 API에서 데이터를 가져와 하류(downstream)에서 결합하는 대시보드(dashboard)를 만드는 방식이었습니다. 어떤 방식이든, 결합(join)은 구축하고 유지 관리해야 하는 구조물이었으며, 두 제품 모두의 외부, 즉 어느 쪽에도 속하지 않는 영역에 존재했습니다.

이것이 워크플로 토폴로지(workflow topology, 작업 흐름 위상)의 핵심입니다. 즉, 통합이 어디에 거주하는가에 대한 형태를 의미합니다. 오랫동안 그 형태는 고정되어 있었습니다. 각 제품은 자신만의 화면과 데이터를 소유했으며, 제품 간의 모든 연결은 외부 비계(scaffolding) — 즉 사람, 스크립트(script), 웨어하우스(warehouse) — 가 그 간극 사이에 볼트로 고정된 형태였습니다. 벤더(vendor)들은 각자의 표면 위에서 경쟁했습니다. 그들 사이의 이음새(seams)는 고객의 문제였습니다.

변하고 있는 것은 바로 그 토폴로지입니다. 제품이 아니라, 이음새가 위치하는 곳이 변하고 있습니다.

모든 도구가 호출 가능해질 때, 클라이언트가 결합 계층이 된다

그 메커니즘을 명확하게 설명하겠습니다.

도구가 MCP(Model Context Protocol) — AI 클라이언트가 외부 서비스에 안전하게 접근할 수 있게 해주는 개방형 프로토콜 — 를 통해 자신의 함수(functions)를 노출하면, 해당 도구는 당신이 찾아가는 화면이 아니라 호출될 수 있는 대상이 됩니다. 이것만으로도 이제는 널리 이해되고 있습니다. 하지만 논의가 덜 된 부분은, 동일한 채팅 클라이언트 내에서 "여러" 도구가 동시에 호출 가능해질 때 어떤 일이 벌어지는가 하는 점입니다.

클라이언트는 그 모든 도구를 호출할 수 있는 능력을 얻게 됩니다. 그리고 클라이언트가 하나 이상의 도구를 호출할 수 있게 되는 순간, 과거에 당신의 번거로운 작업이었던 일을 수행할 수 있게 됩니다. 즉, 하나에서 데이터를 가져오고, 다른 하나에서 데이터를 가져와, 그것들을 결합(join)할 수 있게 됩니다. 과거에 사람이나 파이프라인에 존재했던 오케스트레이션(orchestration, 조정)이 대화 속으로 재배치됩니다. 채팅 클라이언트는 벤더를 가로지르는 결합 계층(cross-vendor join layer)이 됩니다. 즉, 어느 벤더도 상대방을 향한 다리를 구축하지 않고도 광고 플랫폼의 수치와 양식 도구의 결과값이 마침내 만나는 장소가 되는 것입니다.

이 지점이 사람들을 놀라게 하는 부분입니다. 어떤 벤더도 다른 벤더와 통합되지 않았습니다. 광고 도구는 양식(form) 도구가 존재하는지조차 모릅니다. 양식 도구 또한 광고 도구에 대해 알지 못합니다. 어느 쪽도 커넥터(connector)를 구축하지 않았습니다. 그럼에도 불구하고 이들은 결합됩니다. 왜냐하면 그들 위의 계층인 클라이언트(client)가 양쪽 모두에 도달하여 즉석에서 이를 조정(reconcile)할 수 있기 때문입니다. 통합은 제품 내부에 구축된 것이 아닙니다. 통합은 제품에서 완전히 벗어나, 사용자가 이미 머물고 있는 대화(conversation) 속으로 이동했습니다.

이것은 기능(feature)이 아니라 위상(topology)의 변화입니다. 제품 사이의 틈새에 있던 이음새들이 하나의 표면으로 모였습니다. 그리고 그 표면은 바로 채팅창입니다.

결합이 채팅으로 이동한 8일간의 기록

위상에 대한 주장은 말하기는 쉽지만 증명하기는 어렵습니다. 따라서 결합이 재배치된 구체적인 사례를 소개하겠습니다.

설정은 약 6,597엔의 비용을 지출한 8일간의 소규모 광고 테스트였으며, 대시보드를 열지 않고 AI 클라이언트 내의 단일 대화에서 전체 획득 루프(acquisition loop)를 실행하려는 시도였습니다. 해당 채팅에는 두 개의 커넥터가 동시에 활성화되어 있었습니다. 하나는 광고를 위한 것이었고, 다른 하나는 양식 측을 위한 FORMLOVA의 것이었습니다. 어떤 벤더도 서로를 향한 가교를 구축하지 않았습니다.

먼저 광고 측입니다. 지출액, 클릭 수, 클릭률(CTR)과 같은 지표들이 단순한 요청을 통해 채팅창으로 돌아왔습니다. 이 8일 동안 704회의 클릭이 발생했으며, 클릭률(CTR)은 12.62%였습니다. 광고 화면에서 이는 깔끔한 결과로 읽힙니다. 높은 클릭률, 저렴한 클릭 비용, 그리고 분명히 돈을 잘 쓴 것으로 보입니다.

그다음, 기존의 토폴로지(Topology)에서는 한 곳에서 결코 할 수 없었던 움직임을 실행했습니다. 동일한 대화 내에서, 저는 폼(Form) 측면으로 시선을 돌려 응답을 어떤 광고에서 유입되었는지에 따라 분류해 달라고 요청했습니다. 한쪽에는 광고 지출액(Ad spend)이, 다른 한쪽에는 폼 결과(Form outcomes)가 있었고, 클라이언트가 그 사이에서 결합(Join)을 수행했습니다. 별도의 내보내기(Export)도, 스프레드시트도, 두 번째 화면도 필요 없이 바로 그 자리에서 이루어졌습니다. 그 결합으로부터, 획득 비용(Acquisition cost)은 단순히 지출액을 폼 측 전환(Conversions)으로 나눈 값으로, 채팅 내부에서 도출되었습니다. 이 에세이의 핵심은 그 수치가 아니라, 계산이 이루어진 '위치(Location)'에 있습니다. 그것은 내 머릿속이 아니라, 대화 속에서 일어났습니다.

그리고 이 결합은 광고 화면이 숨기고 있었던 진실을 드러냈습니다. 게재 위치(Placement)별로 전달(Delivery)을 나누어 보니 편향(Skew)이 즉각적으로 나타났습니다. 노출(Impressions)의 약 96%, 지출액의 약 83%가 제가 도달하고자 했던 피드(Feeds)가 아닌 오디언스 네트워크(Audience Network)에 집중되어 있었습니다. 저렴하고 클릭률(CTR)이 높은 클릭들은 대부분 신기루였습니다. 겉보기에는 효율적으로 보였지만

결합(Join)이 클라이언트(Client) 내부로 이동할 때, 스택 내 모든 도구에 대한 경쟁 구도는 그 형태가 바뀝니다. 사용자가 더 이상 단일 화면에서 그림을 완성하지 않기 때문에, 제품은 더 이상 가장 완전한 화면을 소유함으로써 승리할 수 없습니다. 그림은 그 모든 화면의 상위 계층에서 조립됩니다. 대신 제품이 제공할 수 있는 것은 깔끔하게 호출(Callable) 가능해야 하며, 대화 내의 다른 모든 것과 잘 결합되는 데이터—정확하고, 구조화되어 있으며, 추적 가능한(Attributable) 데이터—를 반환하는 것입니다. 도구의 가치는 스스로가 얼마나 완전한 '전체(Whole)'인가보다는, 자신이 제어하지 않는 결합 내에서 얼마나 좋은 '부분(Part)'인가에 따라 결정되기 시작합니다.

이는 에이전트(Agent) 세계에서 통제권이 어디에 위치하는가라는 문제와 맞닿아 있습니다. 이는 그 자체로 논쟁의 여지가 있는 주제이므로, 여기서 다시 논의하기보다는 하나의 지나가는 메모로 남겨두겠습니다. 위상(Topology)에 관한 관점은 그 자체로 성립합니다. 고객 획득(Acquisition) 스택의 통합 계층(Integration layer)은 과거에 여러분이 유지 관리하던 외부 비계(Scaffolding)였으나, 이제는 여러분이 이미 사용 중인 채팅 클라이언트의 속성이 되어가고 있습니다. 벤더(Vendor)들이 수렴한 것이 아닙니다. 결합(Join)이 이동한 것입니다.

고객 획득 흐름 내에서 어떤 도구든 구축하는 창업자들에게, 이 전략적 해석은 구체적입니다. 통합 작업이 여러분의 제품이나 고객의 파이프라인 내에서 일어난다고 가정하는 것을 멈추십시오. 통합은 점점 더 한 단계 위인 대화(Conversation) 속에서, 여러분과 여러분의 이웃 도구들을 호출하는 클라이언트에 의해 수행됩니다. 뒤따르는 질문들은 단순한 외형의 문제가 아닙니다. 여러분의 도구는 의도(Intent)가 올바르게 읽혔을 때 호출 가능한가? 여러분의 데이터는 여러분이 들어본 적도 없는 도구와, 여러분이 결코 볼 수 없는 스레드(Thread) 내에서 깔끔하게 결합되는가? 호출자가 에이전트이고 결합이 여러분의 상위 어딘가에서 일어나고 있을 때, 여러분의 운영은 안전하게 실행될 수 있는가? 자체 화면에서 완벽하게 완성된 아름다운 섬과 같은 도구는, 해체되고 있는 위상(Topology)을 위해 최적화되고 있는 것입니다. 자신이 소유하지 않은 결합의 좋은 시민이 되는 도구는, 다가오고 있는 새로운 위상을 위해 구축되는 것입니다.

이것은 제가 다른 곳에서도 기술했던 더 큰 흐름, 즉 소프트웨어가 '선택되는 것'에서 '호출되는 것'으로 변화하는 흐름의 일부입니다. 획득 스택 (Acquisition Stack)이 하나의 대화로 붕괴되는 모습은, 실제 워크플로우 (Workflow)의 한복판에 서서 도구들 사이의 이음새가 실시간으로 사라지는 것을 지켜볼 때 나타나는 현상입니다.

하나의 스레드 안에 담긴 전체 루프 (Loop)

8일간의 소액 지출을 통해 제가 명확히 깨달은 것은 광고에 관한 것이 아니었습니다. 그것은 형태 (Shape)에 관한 것이었습니다.

획득 스택 — 양식 구축, 광고 구축, 양식 관리, 광고 관리, 결과 분석 — 은 항상 별개의 화면에 있는 별개의 제품들로 나뉘어 있었으며, 가장 가치 있는 작업인 비용과 결과 사이의 결합 (Join)은 그 간극 사이에서 번거로운 일로 남겨져 있었습니다. 그 번거로운 일이 하나의 대화로 붕괴되고 있습니다. 광고 수치를 가져오고, 양식 결과를 가져오고, 이를 결합하고, 환상을 찾아내고, 광고를 다시 구축하는 것 — 이 모든 것이 어떤 벤더도 다리를 놓아주지 않았고 어떤 대시보드도 다시 열지 않은 채, 단 하나의 스레드 (Thread) 안에서 이루어집니다.

도구들이 합쳐진 것이 아닙니다. 도구들이 만나는 지점이 합쳐진 것입니다. 그리고 일단 결합 (Join)이 대화 속에 존재하게 되면, 기존 스택을 정의하던 이음새들은 단순히 보이지 않게 됩니다. 이것이 주목할 만한 조용하고 구조적인 변화입니다. 작업이 쉬워졌다는 것이 아니라, 획득의 통합 계층 (Integration Layer)이 당신의 스크립트와 화면을 벗어나 당신이 이미 작업하고 있는 채팅 속으로 이동했다는 사실입니다.

더 읽어보기

• 이 에세이의 근거가 된 8일간의 현장 보고서: Reconciling ad spend with real form outcomes in one chat
• MCP 준비가 된 양식 서비스로서의 FORMLOVA에 대한 광범위한 가이드: The FORMLOVA MCP form service, in brief