Kafka 호환성, 이제 꼭 필요한 걸까

이번 주 Iceberg Summit에서 지인 한 명과 Kafka 얘기를 하다가 꽤 뜨거운 논쟁을 벌였습니다.
정확히는 이런 질문이었습니다. AI 에이전트 시대에도 Kafka 호환성이 우리가 생각하는 만큼 여전히 중요한가?

결론을 내리지는 못했습니다.
그래도 그 대화가 계속 머리에 남았습니다. 우리가 지난 몇 년 동안 너무 당연하게 받아들여 온 몇 가지 전제가 더 이상 성립하지 않을 수도 있겠다는 생각이 들었기 때문입니다.

Kafka의 생태계와 호환성

Kafka는 Fortune 500 기업의 90% 이상에서 돌아가고 있습니다.
이쯤 되면 더 이상 단순한 기술 선택이라고 보기는 어렵고, 사실상 표준에 가깝습니다.

Kafka가 실제로 하는 일은 꽤 단순합니다. 디커플링과 버퍼링입니다.
수십 개의 시스템이 데이터를 생산하고, 또 수십 개의 시스템이 그것을 소비합니다. Kafka는 그 사이에 있어서 어느 한쪽이 다른 한쪽을 신경 쓰지 않아도 되게 만들어 줍니다. 생산 속도와 소비 속도가 맞을 필요도 없습니다. 깔끔한 모델이고, 실제로 잘 동작합니다.

그래서 시장의 패턴도 거의 비슷합니다.
새로운 데이터 스트리밍 회사들은 거의 예외 없이 Kafka-compatible을 내세웁니다. Kafka-compatible하다는 것은 곧 drop-in replacement가 될 수 있다는 뜻이기 때문입니다. Kafka Connect, Kafka Streams, 그리고 엔지니어들이 이미 작성해 두었고 디버깅도 끝냈고 더는 신경 쓰지 않게 된 각종 consumer SDK까지, 전체 생태계를 그대로 가져올 수 있습니다.

호환성은 moat이고, 생태계는 사람들이 쉽게 떠나지 못하게 만드는 힘입니다.

이 논리는 지난 10년 동안 거의 반박하기 어려운 수준이었습니다.
그런데 지금은, 제 생각에 꽤 진지하게 봐야 할 변화가 두 가지 생기고 있습니다.

변화 1: Upstream과 Downstream이 점점 수렴하고 있다

Kafka의 가치 상당수는 연결 대상의 다양성에서 나옵니다.
Upstream에는 Oracle, MySQL, MongoDB, Salesforce, Stripe, HubSpot 같은 것들이 있을 수 있고, downstream에는 Elasticsearch, Redshift, Snowflake, 그리고 수십 개의 마이크로서비스가 있을 수 있습니다. 이렇게 다양한 것들을 붙여야 하니까, 중간에 표준 인터페이스를 제공하는 무언가가 필요한 겁니다.

그런데 그 다양성이 빠르게 줄어들고 있습니다.

Upstream 쪽부터 보면, 데이터베이스 시장은 사실상 Postgres 중심으로 수렴하고 있습니다. AI 시대에 새로 프로비저닝되는 데이터베이스 대부분이 Postgres입니다.
이 말은 결국 CDC의 upstream source가 점점 더 균일해지고 있다는 뜻입니다. 누가 공식적으로 결정한 적은 없더라도, Postgres logical replication이 사실상의 표준 입력이 되어 가고 있습니다.

SaaS 연동도 마찬가지입니다. 예전에는 이런 작업에 몇 달이 걸렸습니다. 커넥터를 만들고, rate limit을 처리하고, schema를 매핑하고, SaaS 벤더가 API를 또 한 번 깨먹을 때마다 따라가야 했습니다.
지금은 coding agent를 붙이면 며칠 안에 일단 돌아가는 수준까지는 만들 수 있습니다. 완벽하지는 않더라도, 동작은 합니다. 이런 연동 비용이 내려가면, 모든 것을 하나의 표준 프로토콜로 통일해야 할 절박함도 같이 줄어듭니다.

Downstream 쪽에서도 비슷한 수렴이 일어나고 있습니다.
예전에는 데이터 웨어하우스를 고르는 것 자체가 큰 의사결정이었습니다. Redshift를 쓸지, Snowflake를 쓸지, BigQuery를 쓸지 따져야 했습니다. 지금은 Apache Iceberg가 점점 모두가 받아들이는 기본 테이블 포맷이 되어 가고 있습니다. 이제는 어떤 query engine을 쓰는지가 예전만큼 중요하지 않습니다. 데이터는 그냥 S3나 GCS 위에 Iceberg 테이블로 놓여 있으면 됩니다.

그렇다면 upstream이 대부분 Postgres CDC이고, downstream이 대부분 object storage 위의 Iceberg라면, 중간의 파이프가 정말로 무한한 다양성을 전제로 설계된 복잡한 프로토콜을 필요로 할까요?
연결해야 할 대상의 종류가 줄어들수록 통합의 복잡도도 줄어듭니다. 그리고 “이 모든 걸 처리하려면 표준 프로토콜이 필요하다”는 주장도 그만큼 힘이 약해집니다.

변화 2: Coding Agent가 프로토콜의 의미 자체를 바꾸고 있다

이건 저에게는 더 근본적인 변화처럼 느껴집니다.

사람들이 Kafka 호환성을 원하는 이유가 뭘까요? 큰 이유 중 하나는 개발자 경험입니다. Kafka-compatible하다는 것은 엔지니어가 새로운 SDK, 새로운 CLI, 새로운 mental model을 배울 필요가 없다는 뜻입니다. 이미 Kafka를 알고 있으니 그냥 가져다 쓰면 됩니다. 온보딩이 빠르고, 마찰이 적습니다. 이건 분명 실제 가치입니다.

그런데 이 논리는 결국, 프로토콜을 인간 엔지니어가 직접 배워야 한다는 전제 위에 서 있습니다.

지금은 거의 모든 엔지니어가 coding agent를 사용합니다.
요즘 엔지니어는 원하는 동작을 설명하고, 코드는 agent가 작성합니다. Coding agent는 당신이 어떤 프로토콜을 쓰는지 신경 쓰지 않습니다. Kafka Protocol도 몇 초면 파악하고, 직접 설계한 HTTP 기반 커스텀 프로토콜도 몇 초면 파악합니다. 예전에는 표준화의 근거가 되었던 프로토콜 학습 비용이, agent에게는 사실상 0에 가까워진 것입니다.

그렇다면 프로토콜 학습 비용이 더 이상 병목이 아니라면, 좋은 프로토콜의 기준은 무엇일까요?

어쩌면 답은 그냥 단순함일지도 모릅니다.
가장 좋은 프로토콜은 가장 큰 생태계를 가진 것이 아니라, agent가 이해하고 다루기 가장 쉬운 것일 수 있습니다. 파일 시스템은 그런 성질을 갖고 있습니다. 우리가 가진 가장 오래된 추상화 중 하나이기도 하고, 동시에 AI agent가 가장 자연스럽게 다루는 인터페이스이기도 합니다.

우리는 지난 몇 년 동안 인간을 위한 개발자 경험을 최적화해 왔습니다.
이제는 AI agent를 위한 개발자 경험이 무엇인지 생각해 봐야 할지도 모릅니다. 그리고 이 둘은 반드시 같은 방향을 가리키지는 않습니다.

원점에서 다시 생각해 보기: Agentic AI 시대의 메시지 큐는 어떻게 설계해야 할까

그럼 오늘 완전히 새로 시작한다고 가정해 봅시다.
Kafka도 잊고, 지금까지의 역사적 맥락도 잠시 내려놓고, agentic AI 시대의 메시지 큐를 처음부터 설계한다면 어떤 모습일까요?

Upstream: 세 가지 주요 소스

첫 번째는 SaaS Webhook입니다.
대부분의 SaaS 제품은 이벤트가 발생하면 HTTP request를 push하는 webhook을 지원합니다. 가장 가벼운 형태의 연동입니다. polling도 없고, persistent connection도 필요 없습니다.

두 번째는 Postgres CDC입니다.
Postgres logical replication으로 WAL을 읽어 row-level change event를 캡처하는 방식입니다. Postgres의 지배력이 더 강해질수록, 이 파이프라인이 커버하는 범위도 함께 넓어집니다.

세 번째는 agent입니다.
이게 새로 등장한 producer입니다. Agent도 다른 시스템처럼 이벤트를 만들어낼 텐데, 그 이벤트는 “database row updated”라기보다는 tool calling trace나 chat log 같은 형태에 더 가까울 겁니다. 데이터의 모양 자체가 근본적으로 다르기 때문에, 나중에 억지로 덧붙이는 대신 처음부터 이걸 전제로 설계할 가치가 있습니다.

Downstream: SaaS, Iceberg, 그리고 Agent

SaaS는 좋든 싫든 계속 남아 있을 겁니다. 특히 비개발자 영역에서는 더 그렇습니다.
Iceberg는 OLAP query가 돌 수 있는 형태로 과거 데이터를 축적하는 분석용 endpoint가 될 겁니다.

하지만 더 흥미로운 downstream은 agent입니다.
제 생각에 agent는 다음 세대의 애플리케이션이고, 다음 세대의 마이크로서비스입니다. 예전에는 RPC를 통해 여러 마이크로서비스가 협업하던 비즈니스 프로세스가, 앞으로는 메시지를 통해 협업하는 여러 agent로 점점 대체될 수 있습니다. 이 모델에서는 메시지 큐의 downstream이 더 이상 “작업을 가져가기 위해 polling하는 consumer program”이 아닙니다. 메시지를 듣고, 그 메시지를 바탕으로 다음 행동을 자율적으로 결정하는 agent가 됩니다.

통신: Kafka Protocol이 아니라 Webhook과 Polling

Agent 간 통신에서 가장 자연스러운 패턴은 webhook입니다.
이벤트가 발생하면 target agent의 endpoint로 POST하면 됩니다. 단순하고, stateless하고, HTTP-native한 방식입니다.

과거 메시지를 가져오거나 batch processing이 필요한 경우에는 polling이면 충분합니다.
Downstream이 새로운 메시지를 조회하고, 가져가서 처리하고, ack하면 됩니다.

대부분의 use case는 이 두 가지 패턴으로 커버할 수 있습니다. 그리고 둘 다 HTTP 기반이라는 점이 중요합니다. Coding agent는 HTTP client를 생성하는 작업에 특히 강합니다.

Storage: Object Store 우선

다음 세대 메시지 큐의 storage layer는 object storage 위에 올라갈 가능성이 높다고 생각합니다.
S3, GCS, R2 같은 것들입니다.

물론 object storage는 local disk보다 latency가 높습니다.
하지만 훨씬 저렴하고, 운영 부담이 거의 없습니다. Kafka cluster를 운영한다는 것은 ZooKeeper나 KRaft를 유지하고, 디스크와 네트워크를 관리하고, replication factor와 retention policy를 조정해야 한다는 뜻입니다. Object storage는 PUT과 GET이면 됩니다.

이건 전형적으로 latency를 비용과 바꾸는 trade-off입니다.
그리고 이 아이디어 자체가 새로운 것도 아닙니다. WarpStream 같은 Kafka의 diskless architecture나, Confluent의 Tiered Storage도 비용 절감을 위해 데이터를 object storage로 내리고 있습니다. Kafka 생태계 내부에서도 이미 방향은 그쪽을 향하고 있습니다.

더 공격적인 아이디어: 파일 시스템 자체를 프로토콜로 쓰기

조금 더 과감하게 가보면, 메시지의 read/write interface로 파일 시스템 자체를 쓰는 방법도 진지하게 생각해볼 만합니다.

Upstream은 특정 경로에 파일을 쓰는 것으로 메시지를 기록합니다.
Downstream은 그 파일을 읽는 것으로 메시지를 소비합니다.
경로는 topic이고, 파일명은 offset이며, append는 produce이고, read는 consume이 됩니다.

굉장히 원시적으로 들릴 수 있습니다.
하지만 중요한 특성이 하나 있습니다. 파일 시스템은 AI agent가 가장 자연스럽게 다루는 인터페이스라는 점입니다. 대부분의 agent framework는 persistence, context storage, tool call을 다룰 때 파일 시스템 추상화를 기본으로 사용합니다. 메시지 큐의 인터페이스까지 파일 시스템이라면, agent는 거의 마찰 없이 메시지를 다룰 수 있습니다. 전용 SDK도 필요 없고, 별도의 프로토콜 지식도 필요 없습니다.

S3 파일이 다음 세대 메시지 큐의 핵심 building block 중 하나가 될 수도 있습니다.

Backward Compatibility라는 질문

물론 이 모든 얘기가 내일부터 Kafka 호환성이 무의미하다는 뜻은 아닙니다.

AI 이전 시대에 만들어진 시스템과 연결해야 한다면, 기존 Kafka cluster를 대체해야 한다면, 혹은 팀이 Kafka 생태계에 이미 깊게 투자한 상태라면, 여전히 Kafka 호환성은 필요합니다. Migration 비용은 실제 문제이고, 그걸 가볍게 넘기자는 얘기는 아닙니다.

그럼에도 저는 계속 Postgres와 MySQL의 관계를 떠올리게 됩니다.

MySQL은 Web 2.0 시대의 절대 강자였습니다.
그런데 Postgres는 한 번도 MySQL-compatible해지려고 하지 않았습니다. 그럼에도 지난 5년 동안 MySQL의 시장을 상당 부분 가져갔습니다. 호환성 때문이 아니라, 실제로 중요한 지점들에서 더 나았기 때문입니다. JSON 지원, PostGIS, logical replication, 더 활발한 extension 생태계. 새로운 프로젝트들은 점점 Postgres를 기본값으로 선택하기 시작했고, migration도 일어나기 시작했습니다. 그러면서 MySQL 호환성은 사람들이 생각했던 만큼 필수 조건이 아니게 되었습니다.

제가 말하고 싶은 동학은 이것입니다.
호환성은 강한 moat이지만, 영구적인 것은 아닙니다. 그 가치는 원래의 생태계 주위로 계속 새로운 프로젝트가 몰릴 때 유지됩니다. 신규 프로젝트들이 더 이상 MySQL로 시작하지 않고 Postgres로 시작하게 되면, MySQL 호환성의 가치는 시간이 갈수록 거의 자동으로 줄어듭니다.

다음 세대 인프라 프로젝트들이 Kafka 대신 object storage, HTTP, 파일 기반 인터페이스를 기본값으로 삼기 시작하면, Kafka 호환성에도 같은 일이 벌어질 수 있습니다.
천천히, 그러다 갑자기.

생각보다 그 변곡점이 가까울 수도 있다고 봅니다.

Anyway

이 얘기 대부분이 지금 대다수 엔지니어링 팀이 서 있는 지점보다 조금 더 앞선 얘기라는 건 저도 압니다.
Kafka를 대규모로 운영하고 있다면 당분간 그게 사라질 일은 없을 것이고, 사라져야 한다고 주장하는 것도 아닙니다.

다만 변화가 실제로 닥친 뒤가 아니라, 닥치기 전에 지금 이 전제들을 한 번쯤 의심해볼 가치는 있다고 생각합니다.
시스템의 주요 행위자가 인간이 운영하는 서비스가 아니라 AI agent가 되고, 코드를 작성하는 일이 구현 자체보다 의도를 설명하는 일에 가까워지고, 프로토콜 학습 비용이 사실상 사라지게 되면, 우리가 인프라를 선택할 때의 논리도 달라질 수밖에 없습니다.

다음 세대의 메시지 큐는 Kafka-compatible할 필요가 없을지도 모릅니다.
대신 더 단순하고, 더 저렴하고, agent가 다루기 더 쉬운 형태일 수 있습니다.

이미 이 방향으로 뭔가를 만들고 있는 분이 있다면, 혹은 제가 완전히 틀렸다고 생각하신다면, 정말 의견을 들어보고 싶습니다.