통합 계층(Consolidation Layer) — 위 회사가 옆 회사를 인수할 때

이 시리즈 에세이를 열한 편 쓰면서 한 문장은 예외 없이 지켜져 왔습니다. 바로 '당신이 소유하지 않은 계층이야말로 당신을 소유하는 계층'이라는 것입니다. 지금까지 저는 여러분이 _임대_하는 계층들, 즉 배포(distribution) (#45), 모델(#46), 아이덴티티(#47), 접근(access) (#48), 하네스(harness) (#49), 미터(meter) (#50), 런타임(runtime) (#51), 데이터(#52), 책임성(accountability) (#53), 레일(#54), 라우터(#55) 등의 계층들을 언급했습니다.

오늘의 계층은 여러분이 구매하는 제품으로 나타나지 않습니다. 그것은 _헤드라인_으로 나타납니다.

제가 이 글을 쓰게 만든 헤드라인

Cloudflare가 Deno를 인수한다고 발표했습니다 (HN에서 1,053점 — 오늘의 최고 기사). 이것만 놓고 보면, 인프라 회사 두 곳이 인프라 회사다운 일을 하는 것입니다. 하지만 잠시 생각해 보면 새로운 계층의 형태, 즉 통합자(consolidator)의 모습을 볼 수 있습니다.

지난 10년간의 주장은 모듈성(modularity)이었습니다. 여러분의 엣지(edge)를 고르고, 런타임(runtime)을 고르고, 데이터베이스를 고르고, 인증(auth)을 고른 다음, 최고의 조합으로 조립하는 것이었습니다. 그 전제는 이것들이 언제든지 다시 만들 수 있는 독립적인 선택지라는 것이었습니다. 통합은 이 전제를 조용히 삭제합니다. 여러분의 엣지를 운영하는 회사가 여러분의 런타임을 운영하는 회사를 인수할 때, 여러분의 '독립적인 공급업체 선택'은 _같은 공급업체_가 되며, 여러분의 탈출구는 API 마이그레이션이 아니라 협상(negotiation)이 됩니다.

통합이 그 자체로 하나의 계층인 이유

이름을 붙일 수 있는 계층은 완화할 수 있는 계층입니다. 즉, 그것을 래핑하거나, 고정시키거나, 대체할 수 있습니다. 통합은 여러분이 이미 완화했던 계층들 안에 숨어 있기 때문에 더욱 위험합니다.

• 선택권을 없애지 않으면서 출구(exit)를 제거합니다. 여전히 확보한 제품에 대한 대안을 기술적으로는 가지고 있습니다. 단, 그 대안이 인수 주체에 의해 소유되지 않는 한에서 말입니다. 통합은 N개의 독립적인 대체 경로(fallback)를 1개로 만듭니다.
• 계약을 소급하여 변경합니다. 당신은 당신에게 서비스를 제공하는 것이 전부였던 작은 공급업체와 거래했습니다. 하지만 인수 주체의 사업 전체는 당신을 묶어두는 데 초점을 맞춥니다. 당신의 통합(integration)에 문제가 생기는 것은 아무것도 없지만, 당신의 협상력(leverage)에는 모든 것이 문제가 됩니다.
• 추상화(abstraction)의 가격을 재설정합니다. 당신이 의존했던 "저렴한 런타임(cheap runtime)"과 "프리미엄 에지(premium edge)" 사이의 격차는 시장적 사실이었을 뿐, 법은 아니었습니다. 단일 소유자는 그 격차가 더 이상 존재하지 않는다고 결정할 수 있으며, 이에 반대하는 경쟁자가 남아있지 않습니다.
• 실패를 집중시킵니다. 이제 한 운영 주체가 여러 계층(layer)에 동시에 자리합니다. 이들의 서비스 중단은 당신의 스택 전반에 걸친 서비스 중단이며, 그들의 로드맵이 곧 당신의 로드맵이 됩니다.

핵심 신호: 통합은 결코 스스로를 '통합'이라고 광고하지 않는다

합병은 당신에게 '역량(capability)'으로 판매됩니다. "더 깊은 통합," "하나의 플랫폼," "더 나은 경험"과 같은 방식으로 말입니다. 의존성은 발표 자체에 있는 것이 아니라, 그 발표가 6분기 후 무엇을 불가능하게 만드는가에 있습니다. 통합 주체를 알아차릴 수 있는 가장 좋은 시기는 당신이 그들의 최전선 기술(frontier)에 의존하기 전이며, 아직 연락할 두 번째 선택지가 남아있을 때입니다.

그리고 같은 날 뉴스에서 반대 신호를 주목하십시오: Oxide Computer가 4억 4,500만 달러 규모의 시리즈 D(Series D) 자금 조달(585 포인트)을 발표하며, 통합 주체로부터 임대하는 것보다 직접 소유하는 하드웨어와 스택에 더 많은 비용을 지불할 고객이 있을 것이라고 베팅했습니다. 이것이야말로 시장이 이 계층이 설명하는 정확한 위험을 가격으로 매기고 있는 것입니다. "직접 소유"가 벤처 규모의 사업(venture-scale business)이 될 때, "임대"는 실질적인 부채(liability)가 됩니다.

실제로 무엇을 해야 하는가

• 벤더가 아닌 소유권을 파악하세요. 의존성(dependencies)을 상위 회사까지 연결하여 선을 그려보세요. 한 지붕 아래에 있는 두 개의 벤더는 하나의 벤더입니다.
• 핵심 계층별로 진정으로 독립적인 대체재를 하나 유지하세요. 서브 브랜드가 아니라, 다른 소유자가 있어야 합니다. 이름을 대지 못한다면, 그런 것은 없는 것입니다.
• 인수 관련 계약서를 다시 읽어보세요. '통제권 변경(Change-of-control)' 조항과 '편의에 의한 해지(termination-for-convenience)' 조건이 바로 당신의 실질적인 선택권(real options)이 있는 곳입니다. 발표가 난 후에가 아니라, 그 전에 행사하세요.
• 가격 집중도를 위험 모델에 반영하세요. 당장은 싸지만 나중에는 그렇지 않은 것은 할인이 아닙니다. 그것은 지연된 의존성(deferred dependency)입니다.
• 전환 비용이 높은 지루하고 독립적인 옵션을 선호하세요. 통합되는 시장에서는, 독립성이 약간의 추가 비용과 적은 완성도로 구매할 수 있는 기능(feature)입니다.

한 줄 요약 버전

통합화(Consolidation)는 당신의 대안들을 지우고 그것을 시너지라고 부르는 계층입니다. 이는 당신의 통합 자체를 깨뜨리는 것이 아니라, 협상 위치를 조용히, 인수 건마다 하나씩 무너뜨립니다. 스택의 모든 계층을 임대할 수는 있지만 괜찮을 수 있습니다. 단, 어느 한 명의 소유자가 그중 하나 이상을 보유하고 있지 않다는 전제 하에 말입니다. 당신이 소유하지 않은 계층은 당신을 소유하는 계층이며, 통합화 주체는 나머지 이사회 전체를 사들이는 사람입니다.

배포(Distribution), 모델(Model), 신원(Identity), 접근(Access), 하네스(Harness), 측정기(Meter), 런타임(Runtime), 데이터(Data), 책임성(Accountability), 레일(Rail), 라우터(Router) — 그리고 다른 것들을 하나의 건물주로 조용히 만드는 통합화 주체.

시리즈: 배포 → 모델 → 신원 → 접근 → 하네스 → 측정기 → 런타임 → 데이터 → 책임성 → 결제 레일 → 라우터 → *통합화(Consolidator). 당신이 소유하지 않은 각 계층은 당신이 책임을 져야 하는 계층이 됩니다.