무슨 일이 있었나요?
Cloudflare가 K2라는 서버리스 이벤트 스트림 서비스를 공개했어요. 한 줄로 말하면 “서버를 직접 띄우지 않고 쓰는 이벤트 스트림”이에요. 이게 왜 반가운지 알려면 두 가지를 먼저 봐야 해요. 이벤트 스트림이 뭔지, 그리고 지금까지 이걸 쓰는 데 얼마나 손이 많이 갔는지요.
이벤트 스트림, 이게 뭐냐면
서비스에서는 '사건(이벤트)'이 쉬지 않고 생겨요. 회원 가입, 결제 완료, 상품 클릭, 서버 로그 한 줄까지 전부 이벤트예요. 이벤트 스트림은 이런 사건을 일어난 순서대로 쌓아두는 기록장이라고 생각하면 쉬워요.
메시지 큐와 많이 헷갈리는데 둘은 꽤 달라요. 큐는 우체통 같아서 누가 편지를 꺼내 가면 그 편지는 없어지거든요. 스트림은 CCTV 녹화본에 더 가까워요. 기록이 보관 기간 동안 그대로 남아 있어서 여러 사람이 각자 원하는 시점부터 돌려볼 수 있어요. 기록을 읽어가는 쪽을 소비자(consumer)라고 하는데요. 소비자마다 오프셋(offset)을 따로 가지고 있어요. “나는 몇 번째 기록까지 읽었다”를 표시하는 책갈피 같은 거예요.
그래서 '결제 완료' 이벤트 하나를 정산 시스템, 알림 서비스, 데이터 분석 파이프라인이 서로 신경 쓰지 않고 각자 읽어갈 수 있어요. 나중에 새 서비스를 붙여도 과거 기록을 처음부터 다시 읽게 할 수 있고요. 이 분야에서 사실상 표준으로 쓰이는 게 Apache Kafka예요.
문제는 '운영'이었어요
Kafka를 직접 운영해 본 분들은 이게 얼마나 손이 가는지 잘 아실 거예요. 브로커 서버를 몇 대 둘지, 토픽을 파티션 몇 개로 나눌지 미리 정해야 해요. 디스크가 차면 늘려야 하고, 브로커가 죽으면 리밸런싱도 챙겨야 하죠. Kafka 4.0에서 ZooKeeper가 빠져서 한결 가벼워지긴 했어요. 그래도 아직 “Kafka 전담 인력이 필요하다”는 말이 나와요.
클라우드에서는 비용도 문제예요. Kafka는 데이터를 여러 브로커에 복제하는데, 브로커가 서로 다른 가용 영역(AZ)에 있으면 그 사이에 오가는 트래픽에 요금이 붙거든요. 트래픽이 많은 서비스에서는 이 복제 비용이 서버 비용보다 커지기도 해요. 서버리스는 이런 고민을 통째로 플랫폼에 넘기는 방식이에요. 클러스터 크기를 미리 정하지 않아도 되고, 쓴 만큼만 내고, 트래픽이 몰리면 알아서 늘어나요.
Cloudflare의 퍼즐 조각으로 보면
Cloudflare에는 이미 개발자용 서비스가 꽤 많아요.
- Workers: 엣지에서 코드를 돌려요.
- Queues: 작업을 비동기로 넘겨요.
- Durable Objects: 상태를 가진 서버리스 객체예요.
- R2: 이그레스(데이터를 밖으로 가져갈 때 내는) 요금이 없는 오브젝트 스토리지예요.
- Pipelines: 이벤트를 받아서 R2에 쌓아줘요.
업계 흐름: 스트리밍도 오브젝트 스토리지로
요즘 스트리밍 업계의 가장 큰 흐름은 “브로커 디스크 대신 오브젝트 스토리지에 저장하자”예요. 대표적인 게 S3 위에서 Kafka 프로토콜을 구현한 WarpStream인데요. 2024년에 Confluent가 WarpStream을 인수하면서 이 방향이 주류가 됐다는 게 분명해졌어요. AutoMQ와 Bufstream도 같은 방향이고, Kafka 커뮤니티에서도 디스크 없는 토픽(KIP-1150)을 논의해 왔어요. AWS에는 MSK Serverless와 Kinesis Data Streams가 있고요.
이 방식은 싸고 운영이 단순한 대신 느려질 수 있어요. 오브젝트 스토리지를 거치다 보니 지연 시간이 수 밀리초에서 수십~수백 밀리초로 늘어날 수 있거든요. 결국 “얼마나 빨라야 하나”와 “얼마나 싸야 하나” 중에서 골라야 해요. Cloudflare는 이 시장에 이그레스 요금이 없는 R2와 전 세계 엣지 네트워크를 무기로 들어온 셈이에요.
한국 개발자에게 주는 시사점
Kafka는 필요한데 운영할 사람이 없는 작은 팀이라면 눈여겨볼 만해요. 클러스터 운영 부담 때문에 이벤트 기반 구조를 미뤄왔던 스타트업이라면 시작하기가 훨씬 쉬워질 수 있거든요. 이미 Workers를 쓰고 있다면 더 자연스럽게 붙일 수 있고요.
조심해서 볼 부분도 있어요. 금융이나 공공처럼 데이터 저장 위치를 까다롭게 따지는 분야라면 데이터가 어느 지역에 저장되는지부터 확인해야 해요. Debezium 같은 CDC 도구(DB에서 바뀐 내용을 스트림으로 흘려보내는 도구)나 Kafka Connect를 쓰고 있다면 호환되는지부터 따져봐야 하고요. 특정 클라우드 전용 API에 너무 깊이 묶이면 나중에 옮기기 어려워진다는 점도 생각해 두세요.
어떤 서비스를 고르든 통하는 개념들도 있어요. 오프셋, 파티션과 순서 보장, 최소 한 번 전달(at-least-once), 그리고 멱등성(같은 메시지를 두 번 처리해도 결과가 같게 만드는 것) 같은 것들이에요. 이번 기회에 정리해 두면 Kafka를 쓰든 K2를 쓰든 계속 써먹을 수 있어요.
마무리
한 줄 정리: 이벤트 스트림이 '직접 운영하는 인프라'에서 '그냥 가져다 쓰는 서비스'로 바뀌고 있고, Cloudflare도 본격적으로 뛰어들었어요.
여러분 팀은 이벤트 스트리밍을 어떻게 하고 계신가요? 지금 Kafka를 직접 운영하고 있다면 서버리스로 옮길 생각이 있는지, 없다면 뭐가 가장 걸리는지 이야기 나눠봐요.
🔗 출처: Hacker News