통합론은 너무 성급한 판단이다

모두가 AI 코딩 도구들이 통합될 것이라고 말하고 있습니다. 이번 주에만 이 분야가 통합되고 있으며, 승자들이 스스로를 선택하고 있으니 이제 한 편을 정해야 한다는 세 가지 의견을 보았습니다.

저는 이것이 사이클을 잘못 읽고 있다고 생각합니다.

우리는 통합 단계에 있는 것이 아닙니다. 우리는 폭발 단계에 있습니다. 실제적인 통합이 일어나기 전에 수백 개의 도구가 나타났다가 사라질 것입니다. 지금 통합을 요구하는 것은 캄브리아기 대폭발 (Cambrian explosion)의 한복판에 서서 모두에게 척추동물을 선택하라고 말하는 것과 같습니다.

자세히 관찰하면 지금 실제로 일어나고 있는 일은 통합이 아니라 복제입니다. 모든 도구가 모든 것을 하려고 시도하고 있습니다. IDE 플러그인은 에이전트 (agents)를 추가하고 있습니다. 에이전트는 IDE를 추가하고 있습니다. 채팅 도구는 터미널 (terminal)을 추가하고 있습니다. 터미널 도구는 채팅을 추가하고 있습니다. 아무도 누구와 통합하고 있지 않습니다. 그들은 모두 펀딩 덱 (funding decks)에서 만들라고 지시한 것과 같은 상상 속의 올인원 (all-in-one) 제품을 향해 전력 질주하고 있을 뿐입니다.

이것은 시장 재편 (shakeout) 직전의 소음처럼 보입니다. 통합 (consolidation) 직전의 모습이 아닙니다.

실제 통합에 필요한 조건

통합이 일어나려면 아직 충족되지 않은 몇 가지 조건이 성립되어야 합니다.

문제의 표면적 (surface area)이 안정적이어야 합니다. 현재는 매 분기마다 변하고 있습니다. 작년에 코딩 도구는 자동 완성 (autocomplete)과 채팅의 결합이었습니다. 올해는 PR을 제출하는 자율 에이전트 (autonomous agents)입니다. 내년에는 또 다른 무언가가 될 것입니다. 움직이는 목표를 중심으로 통합할 수는 없습니다.

직접 만드는 것보다 인수하는 것이 더 저렴할 정도로 승자가 명확해야 합니다. 현재 그 누구도 그런 위치에 있지 않습니다. Cursor가 Continue를 인수하고 있지 않습니다. Claude Code가 Aider를 인수하고 있지 않습니다. Windsurf는 누구도 인수하고 있지 않습니다. 그들은 모두 여전히 영토 확장 (land grab) 단계에 있습니다.

역량 (capability)보다 배포 (distribution)가 더 중요해져야 합니다. 우리는 여전히 역량이 더 중요한 단계에 있습니다. 왜냐하면 도구들이 실제로 할 수 있는 기능 면에서 서로 진정으로 다르기 때문입니다. 모든 도구가 동일한 역량의 천장에 수렴하게 되면, 그때부터 배포가 중요해지기 시작하며, 그때 비로소 인수 (acquisitions)가 일어나는 것을 보게 될 것입니다. 우리는 아직 그 단계에 도달하지 않았습니다.

실제로 일어나고 있는 일

실제로 일어나고 있는 일은 사이클의 단계 중 아무도 쓰고 싶어 하지 않는 부분입니다. 왜냐하면 혼란스럽고 깔끔한 내러티브(narrative)가 없기 때문입니다.

도구들은 서로를 복제하고 있습니다. 기능들은 몇 주 안에 클론(cloned)됩니다. 차별화 요소는 명확한 축들 — 자동 완성 품질, 채팅 품질, 에이전트 능력(agent capability) — 에서 무너지고 있으며, 비명확한 축들인 지연 시간(latency), 작업당 비용(cost per task), 긴 문맥 처리(long-context handling), 이미 사용 중인 도구와의 통합(integration)으로 이동하고 있습니다.

이 도구들 중 대부분은 사라질 것입니다. 도구들이 나빠서가 아니라, 이미 닫혀버린 시기에 맞춰 만들어졌기 때문입니다. 그들은 "AI 코딩"이 카테고리이며 자신들은 그 조각을 차지하기만 하면 된다는 가정하에 자금을 조달했습니다. 그들은 카테고리가 제품을 출시하는 속도보다 더 빠르게 파편화(fragmenting)되고 있다는 사실을 알아차리지 못했습니다.

생존자들은 플랫폼이 되려고 노력하는 대신, 실제 쐐기(wedge)를 선택하여 깊게 파고드는 이들이 될 것입니다. 승리하는 쐐기는 올인원(all-in-one) 도구가 굳이 신경 쓰지 않지만, 일단 사용하고 나면 그것 없이는 일할 수 없게 되는 것들입니다.

구축하거나 구매하는 입장에서 이것이 중요한 이유

구축하는 입장이라면: 아직 플랫폼이 되려고 하지 마세요. 플랫폼은 아직 구축되지 않았습니다. 곡괭이와 삽(picks-and-shovels) 계층도 아직 구축되지 않았습니다. 차세대 Cursor가 되는 것보다, 하나의 특정 작업을 다른 무엇보다 더 잘 수행하는 것에 훨씬 더 많은 기회가 있습니다.

구매하는 입장이라면: 18개월 후에도 당신의 스택(stack)이 될 것이라고 기대하며 특정 스택에 전념하지 마세요. 그렇지 않을 것입니다. 오늘 사용 중인 도구는 팀 온보딩(onboarding)을 마치기도 전에 인수되거나, 폐기되거나, 피벗(pivoted)될 가능성이 높습니다. 도구는 변하지만 API 계약(API contracts)은 변하지 않는다는 가정하에 워크플로우(workflow)를 구축하세요.

통합은 구조조정 이후에 찾아온다

통합(consolidation)은 일어날 것입니다. 하지만 그것은 구조조정(shakeout) 전이 아니라 후에 일어납니다. 이러한 도구들 대부분이 사라지고, 살아남은 서너 개의 도구가 기능적 동등성(feature parity)을 향한 질주를 멈추고, 차별화할 수 없는 능력에 더 많은 비용을 쓰지 않으면서 성장할 방법을 찾기 시작할 때 — 바로 그때 인수(acquisitions)를 보게 될 것입니다.

지금 당장 통합을 요구하는 것은 그저 소음(noise)에 새로운 이름을 붙이는 것에 불과합니다. 소음은 폭발적인 변화를 의미합니다. 통합은 시장 정리(shakeout)가 일어난 후에나 찾아올 것이며, 우리는 아직 그 정리 단계를 거치지 않았습니다.

저는 이러한 도구 중 하나를 만들고 있습니다. Prism은 라우팅(routing)과 세션 메모리(session memory) 기능만을 수행하는 API 프록시(API proxy)입니다. 이것이 저의 베팅입니다. 즉, 적어도 지금으로서는 플랫폼(platform)보다 쐐기(wedge) 전략이 더 유용할 것이라는 점에 걸고 있습니다. API 키를 받으시거나 문서를 읽어보세요.