메시지 큐와 스트리밍 시스템을 다뤄 본 실무자라면 카프카(Kafka)나 유사 시스템을 운영하며 겪는 고민이 익숙할 것이다. 브로커의 로컬 디스크 용량을 계산하고, 파티션 수를 미리 정하고, 보존 기간을 넘긴 데이터를 어디에 어떻게 내려둘지 결정하는 일이 끊이지 않는다. 최근 해커뉴스에 공개된 PicoMQ는 이런 구조에 대한 하나의 대안적 관점을 보여 준다. 핵심 주장은 간단하다. 스트림을 HTTP로 다루되, 그 저장소를 S3 호환 오브젝트 스토리지 위에 올린다는 것이다.
왜 오브젝트 스토리지인가
PicoMQ가 스스로를 규정하는 문장은 "S3 호환 오브젝트 스토리지 위에 구축된 내구성 있는 실시간 스트림"이다. 여기서 오브젝트 스토리지를 백엔드로 삼는다는 점이 이 프로젝트의 성격을 사실상 결정한다. 전통적인 브로커는 데이터를 자신이 소유한 디스크에 기록하고, 그 디스크의 크기와 성능이 곧 시스템의 한계가 된다. 반면 S3 같은 오브젝트 스토리지는 사실상 용량 상한이 없고, 저장 비용이 저렴하며, 내구성 보장을 스토리지 계층에 위임할 수 있다. PicoMQ가 각 스트림을 "바닥이 없는(bottomless)" 것으로 표현하는 배경이 여기에 있다. 저장 한계를 브로커가 아니라 오브젝트 스토리지가 흡수하기 때문이다.
이 접근은 완전히 새로운 발상은 아니다. 최근 몇 년간 스트리밍 인프라 진영에서는 연산 계층과 저장 계층을 분리하고, 저장을 오브젝트 스토리지로 밀어내려는 흐름이 뚜렷했다. 로컬 디스크에 묶여 있던 상태를 걷어내면 브로커는 상대적으로 가벼워지고, 유휴 상태에서 비용이 거의 들지 않으며, 부하가 몰릴 때만 자원을 늘리는 운영이 수월해진다. PicoMQ가 "유휴에서 고처리량까지 확장된다"고 말하는 지점도 이런 아키텍처적 이점과 맞닿아 있다.
토픽 대신 유스케이스별 스트림
PicoMQ가 제시하는 또 다른 설계 원칙은 사용 방식에 대한 것이다. 한 종류의 레코드를 전부 하나의 토픽에 몰아넣는 대신, 유스케이스마다 스트림을 따로 만들라는 권고다. 각 스트림은 독립적으로 주소를 가지며(independently addressable), 개별적으로 확장된다. 이는 카프카에서 하나의 큰 토픽을 파티션으로 쪼개 관리하던 관행과는 결이 다르다. 스트림 생성 비용이 충분히 낮다는 것을 전제로 할 때에만 성립하는 모델이기 때문이다. 오브젝트 스토리지 기반이라 스트림 하나하나가 물리적 디스크 파티션을 선점하지 않는다면, 수많은 스트림을 세밀하게 나누는 방식이 실제로 부담이 되지 않을 수 있다.
실무 관점에서 이 모델은 매력적인 구석이 있다. 예컨대 고객사별, 기능별, 이벤트 종류별로 스트림을 잘게 나누면 접근 제어와 보존 정책을 스트림 단위로 다르게 걸 수 있고, 특정 스트림만 리플레이하거나 폐기하는 일도 단순해진다. 하나의 거대한 토픽 안에서 소비자들이 필요 없는 레코드까지 훑고 지나가야 하는 낭비도 줄어든다. 다만 이런 이점이 실제로 얼마나 발현되는지는 스트림 생성과 조회의 실제 비용, 그리고 수천 개 스트림을 다룰 때의 관리 도구 성숙도에 달려 있다.
HTTP라는 선택과 그 한계
PicoMQ가 프로토콜로 HTTP를 택한 것도 눈여겨볼 만하다. 별도의 브로커 프로토콜이나 전용 클라이언트 라이브러리 없이 HTTP만으로 스트림을 읽고 쓸 수 있다면, 진입 장벽은 상당히 낮아진다. 방화벽과 프록시를 넘기 쉽고, 어떤 언어에서든 표준 HTTP 클라이언트로 접근할 수 있으며, 서버리스나 엣지 환경과의 궁합도 좋다. 카프카 클라이언트의 복잡한 설정과 커넥션 관리를 걷어낼 수 있다는 점은 소규모 팀에게 특히 실질적인 이점이다.
동시에 오브젝트 스토리지를 저장 계층으로 쓰는 구조에는 본질적인 트레이드오프가 따른다는 점을 짚어야 한다. 일반적으로 오브젝트 스토리지는 개별 쓰기의 지연 시간이 로컬 디스크보다 크고, 진정한 밀리초 단위 지연을 요구하는 워크로드에는 부담이 될 수 있다. "실시간"이라는 표현이 어느 수준의 지연을 의미하는지, 정확히 한 번 처리(exactly-once)나 순서 보장 같은 세부 시맨틱을 어떻게 다루는지는 공개된 소개 문구만으로는 판단하기 어렵다. 이런 부분은 프로젝트의 실제 문서와 벤치마크로 확인해야 할 몫으로 남는다.
결국 PicoMQ는 완성된 정답이라기보다, 스트리밍 인프라의 저장 계층을 오브젝트 스토리지로 옮겼을 때 무엇이 달라지는지를 보여 주는 사례에 가깝다. 유휴 시 저렴하고 사실상 무한한 용량, HTTP만으로 접근 가능한 단순함, 유스케이스별로 잘게 나눈 스트림이라는 방향성은 분명 검토할 가치가 있다. 다만 도입을 고려하는 팀이라면 지연 특성, 처리 보장 수준, 대량 스트림 운영 도구의 완성도를 자신의 요구사항과 대조해 본 뒤 판단하는 것이 순서일 것이다.