"Kafka보다 Postgres가 더 나을 때" 실전 벤치마크와 선택 기준

데이터 처리 시스템을 선택하는 순간, 우리는 두 가지 길 앞에 놓입니다. 하나는 최신 기술과 화려한 키워드에 끌려가 복잡성을 더하는 길, 다른 하나는 단순함과 실용적 선택을 중시하는 길이죠. 최근 들어 Postgres가 "만능 데이터베이스"로 각광받으면서, Kafka나 Redis, MongoDB, ElasticSearch 같은 전문 시스템 대신 Postgres만으로도 웬만한 처리가 가능하다는 주장이 힘을 얻고 있습니다. 실제로 성능 테스트를 통해, Postgres의 확장성과 실용성을 검증한 이야기를 공유하려 합니다. 이 글을 읽으시면 "내 서비스에 Kafka가 필요한가?" 혹은 "Postgres로 충분한가?"라는 고민에 명쾌한 답을 얻으실 수 있습니다.

데이터 인프라 선택, 두 가지 사고방식

기술을 선택할 때, 사람들은 종종 최신 CLI, 클라우드, AI, 서버리스 등 유행하는 키워드만 좇다가 필요 이상으로 복잡한 시스템을 만듭니다. 이른바 "이력서가 빛나는 아키텍처"죠. 반면, 최근에는 단순함과 상식에 기반한 선택이 다시 인기를 끌고 있습니다. "작은 데이터(Small Data)" 흐름과 "Just Use Postgres" 움직임이 그 대표 사례입니다. 실제로 대부분의 조직은 데이터 규모가 크지 않고, 최신 하드웨어 덕분에 Postgres 한 대로도 충분히 서비스를 운영할 수 있습니다.

Postgres, 다재다능한 만능 데이터베이스

Postgres는 단지 SQL 서버가 아닙니다. 텍스트 검색(Elasticsearch), JSON 저장(MongoDB), 캐시(Redis), AI 벡터 데이터베이스, 심지어는 Kafka처럼 메시지 큐(Queue)와 Pub/Sub 시스템 역할까지 겸할 수 있습니다. 물론 완벽히 대등하진 않지만, 실무에서 요구되는 기능의 80%를 20% 노력만으로 처리하는 경우가 대부분입니다. 최신 하드웨어와 결합하면, Postgres만으로도 상당한 규모의 트래픽과 메시징을 소화할 수 있습니다.

Postgres로 Pub/Sub 시스템 구현 및 성능 테스트

Kafka는 실시간 Pub/Sub(발행/구독) 메시징의 표준이죠. 하지만 Postgres 역시 고성능을 보여줄 수 있을까요? 직접 벤치마크를 통해 실측 값을 확인했습니다.

• Pub/Sub 메시지 처리:

  • 4 vCPU 싱글 노드에서 평균 5,000 msg/s 기록

  • 3노드 복제 환경에서도 유사한 성능 유지

  • 대형 96 vCPU 노드에선 24만 msg/s 이상, 1.16 GiB/s 출력

  • End-to-end 지연시간은 보통 60~850ms 사이(서버 상태에 따라 다름)

• 구현 방식:

  • 각 메시지는 고유 오프셋을 갖고, 별도 "로그 테이블"에 저장

  • Writer/Reader 각각 여러 개 동시 운용, Reader는 Consumer Group 단위로 읽기 진행

  • 성능 향상을 위해 배치 처리 및 오프셋 관리 사용

• 실서비스에서 얻을 수 있는 시사점:

  1. Kafka를 꼭 써야 할 수준의 트래픽(수백 MB/s 이상)이 아니라면 Postgres로도 충분히 운영

  2. 높은 내구성과 동시성, 간편한 관리가 큰 장점

  3. Pub/Sub용 인기 라이브러리는 많지 않지만 직접 구현도 어렵지 않음

Postgres 기반 Queue 성능과 실무 활용법

Queue(큐)는 비동기 작업 처리, 예를 들면 이메일 발송이나 푸시 알림에 주로 쓰입니다. Postgres에서는 SELECT FOR UPDATE SKIP LOCKED로 Lock 경쟁 이슈를 해결할 수 있습니다.

• Queue 처리량 벤치마크:

  • 4 vCPU 노드에서 초당 약 2,800 msg 처리(최대 쓰기 성능 12,000 msg/s)

  • 3노드 복제에서도 안정적으로 2,000~2,400 msg/s

  • 96 vCPU 대형 노드에서는 2만 msg/s 처리 가능, 단일 테이블 한계 존재

• 실용적 장점:

  1. 대다수 비즈니스 서비스(즉, 대부분 스타트업)는 Postgres Queue만으로 충분히 운영

  2. 인기 라이브러리(pgmq 등)와 간단한 커스텀 구현 모두 가능

  3. 높은 안정성과 관리의 용이성, 별도 Queue 전용 솔루션 도입 없이 문제 해결

언제 Postgres만으로 충분할까?

많은 개발자들이 "Kafka가 더 빠르니 무조건 써야 한다"는 인식에 빠지는데, 사실 대부분의 서비스엔 지나친 오버엔지니어링일 가능성이 높습니다. 중요한 것은 실제 요구사항, 그리고 조직이 운영에 들일 수 있는 시간·비용·복잡성입니다.

Postgres를 먼저 사용해야 하는 이유:

• 높은 확장성: OpenAI도 2025년 기준 "단일 Postgres 인스턴스+리드 복제"로 8억 유저의 서비스를 운영

• 조직 내 학습 비용 및 운영비 절감: 이미 익숙한 기술 스택에 새로운 복잡한 시스템을 도입하는 비용 대비 효용이 낮음

• 간단한 관리, SQL을 통한 자유로운 조회 및 수정

• 대부분의 서비스는 수십~수천 MB/s 이하의 데이터·메시지 처리면 충분(대형 인터넷 기업 제외)

Kafka(혹은 RabbitMQ, Redis 등)로 가는 기준

• 초대형 트래픽(수백 MB/s 이상의 메시징)

• 엄격한 확장성과 지역 간 내구성 보장 필요

• Pub/Sub, Queue 기능의 극한 최적화 수준 요구

"최소한의 인프라(MVI)" 전략이 더 현명하다

신생 기업이나 대부분의 실무에서, "최고의 인프라"를 찾기보다 "충분히 괜찮은 인프라"에 집중해야 합니다. 즉, 이미 운영 중인 Postgres에 기능만 추가하여 필요한 서비스 론칭 → 나중에 정말 한계에 다다를 때 새롭고 전문화된 시스템으로 옮기는 전략이 비용·효율·확장성 모두에 유리하죠. 실제로 Postgres는 글로벌 커뮤니티, 엔지니어 구인·구직의 용이성, 성장하는 생태계 모두 강력하므로 "최소한의 인프라 선택"에 매우 적합합니다.

조직 운영 관점에서 "불필요한 시스템 도입"의 위험

분산 시스템은 언제나 운영 복잡성과 장애 처리, 학습 및 유지 보수 부담이 큽니다. 새로운 기술을 도입하는 순간, 설정·모니터링·전담 인력·배포 및 업그레이드·런북 작성 등 수많은 추가 작업이 필요해집니다. 아직 수십만 req/s 수준의 "웹 스케일" 문제가 아니라면, 이미 안정적으로 사용 중인 Postgres로도 충분히 비즈니스 가치를 제공할 수 있습니다.

"걱정하는 만큼 폭발적 성장에 곧장 대비해야 할까?"

많은 분들이 "서비스가 갑자기 대박난다면?"이라며 무리하게 대형 아키텍처를 도입합니다. 하지만 실제로

• 대부분의 스타트업은 10~50% 정도의 연 성장률에서 수년간 충분한 준비 및 이전 시간을 확보

• 문제를 겪을 때까지는 작은 규모의 인프라로도 오랜 시간 버틸 수 있음

• 만약 Postgres의 한계에 도달했다면, 이동의 시간은 이미 충분히 갖게 된 셈 "필요하지 않은 단계에 최고의 툴을 도입하는 것"은 오히려 팀과 조직에 독이 될 수 있습니다.

결론: 필요할 때까지 Postgres로 운영하세요!

데이터와 메시징 인프라는 늘 진화 중입니다. Kafka, Redis, RabbitMQ, Snowflake 등등 화려한 기술 스택 유행은 끊임없이 변합니다. 하지만 현업에서 더 중요한 것은 현실적인 요구, 운영 난이도, 비용, 관리의 편의성, 그리고 빠른 대응력입니다. Postgres는 폭발적으로 성장하는 서비스도 꽤 오랫동안 충분히 버티며, 스타트업부터 대기업까지 폭넓게 쓰입니다. 새로운 기술을 도입하기 전 "지금 내가 가진 문제를, 이미 익숙한 도구로 충분히 풀 수 있는가?"를 먼저 질문하세요. 진짜 한계가 올 때, 그때서야 Kafka든, 특화된 솔루션이든 선택하면 됩니다.

실전 팁:

• 처음엔 Postgres로 시작, 문제가 생길 때까지 기다리세요.

• 성능 한계가 보이면 그때 고민해도 늦지 않습니다.

• 복잡한 시스템 도입이 꼭 "혁신"은 아닙니다. 관리가 쉽고 충분히 빠른 시스템이 곧 현명한 선택입니다.

데이터 인프라 고민에 이 글이 실질적인 길잡이가 되길 바랍니다!

출처 및 참고 : Kafka is fast -- I'll use Postgres