PostgreSQL 하나로 어디까지? Kafka·Redis·Elastic을 대체하는 단순함의 전략

새로운 요구사항이 생길 때마다 전용 시스템을 하나씩 추가하는 것은 현대 백엔드 아키텍처의 익숙한 풍경이다. 검색이 필요하면 Elasticsearch, 큐가 필요하면 Kafka나 RabbitMQ, 캐시가 필요하면 Redis, 시계열 분석이 필요하면 Clickhouse를 붙인다. 그러나 이렇게 늘어난 시스템은 각각 운영·모니터링·장애 대응의 부담을 만들고, 데이터를 시스템 간에 동기화하는 별도의 복잡성까지 낳는다. 원문의 저자는 2003년부터 PostgreSQL을 써 온 경험을 바탕으로, 상당수의 경우 이 모든 것을 PostgreSQL 하나로 대신할 수 있으며 실제로 그렇게 하는 성공적인 회사들이 있다고 주장한다. 핵심 메시지는 기술의 화려함이 아니라 '빠르게 움직이려면 단순함이 필요하다'는 실무 원칙이다.

왜 하필 오래된 PostgreSQL인가

저자가 꼽는 PostgreSQL의 힘은 세 가지에서 나온다. 첫째는 역설적이게도 '지루하게 오래된 기술'이라는 점이다. 첫 릴리스가 1996년으로 거슬러 올라갈 만큼 오랫동안 널리 쓰였고, 데이터베이스처럼 버그를 잡아내는 데 시간이 필요한 소프트웨어에서 그 세월은 곧 안정성을 의미한다. 둘째는 오래됐지만 기능은 현대적이라는 점이다. 활발한 커뮤니티가 기존 동작을 깨뜨리지 않으면서 JSON 문서 저장, 파티셔닝, 공통 테이블 표현식(CTE) 같은 기능을 릴리스마다 꾸준히 추가해 왔다. 셋째는 어디서나 쉽게 돌아간다는 점이다. 리눅스 배포판에 기본 포함되고 Mac의 brew, PostgresApp으로도 설치되며, 테스트 단계에서는 Testcontainers로 운영 환경과 100% 동일한 실제 DB를 띄워 검증할 수 있다. 여기에 모든 주요 클라우드가 클릭 한 번으로 배포와 확장을 지원하니, 운영 부담은 줄고 기능 개발에 쓸 시간은 늘어난다.

검색·문서·큐를 한 시스템 안에서

구체적인 대체 사례는 광범위하다. 전문검색(full-text search)의 경우, 별도의 검색 클러스터 없이 PostgreSQL 안에서 텍스트를 사용자 검색 가능한 데이터로 바꿀 수 있고 데이터와 검색 인덱스 사이의 동기화 문제도 사라진다. 원문은 Contentful과 Instacart가 별도 검색 인프라 대신 PostgreSQL 위에 검색 기능을 구축한 사례를 든다. 문서 저장에서는 JSON을 저장할 뿐 아니라 질의까지 지원하고 GIN 인덱스로 속도를 확보하는데, 실제로 Guardian이 MongoDB에서 PostgreSQL로 전환한 사례가 소개된다. 이벤트·큐·영속 로그 역시 마찬가지다. 저자의 조언은 명확하다. 처음부터 Kafka를 도입하지 말고 PostgreSQL 테이블을 큐로 써 보라는 것이다. 성능이 더는 감당되지 않을 때 비로소 전용 시스템으로 옮기면 되며, 그전까지 PostgreSQL이 얼마나 잘 버티는지에 놀랄 것이라고 말한다.

시계열과 캐시 영역도 사정권이다. 고빈도로 쏟아지는 시계열 데이터는 Clickhouse 같은 전용 시스템의 영역이지만, TimescaleDB 확장을 쓰면 익숙한 PostgreSQL을 유지한 채 대용량 데이터를 다룰 수 있다. 저자는 프라이버시를 존중하는 웹 분석 서비스에서 이를 직접 활용했다고 밝힌다. 나아가 Timescale은 pgvector로 벡터 데이터베이스 기능을, pgai로 데이터 색인부터 LLM 호출과 유사도 기반 검색까지 묶어 제공해 AI 워크플로우까지 끌어안는다. 캐시의 경우, UNLOGGED 테이블을 활용하면 대부분의 용도에서 Redis만큼 빠르게 튜닝할 수 있고 트리거로 자동 만료(expire)까지 흉내 낼 수 있다는 것이다.

실무자가 기억해야 할 지점과 한계

이 글은 벤치마크 수치를 앞세운 성능 비교가 아니라, 한 사람의 경험과 여러 회사 사례를 엮은 아키텍처 관점의 주장이라는 점을 분명히 이해하고 읽을 필요가 있다. 저자 스스로도 큐로 쓰다가 성능이 안 나오면 Kafka·SQS로 옮기라고 명시하듯, 'PostgreSQL로 모든 것을'이 곧 '어떤 규모에서도 전용 시스템이 불필요하다'는 뜻은 아니다. 극단적 처리량이나 매우 특수한 접근 패턴에서는 전용 시스템이 여전히 유리할 수 있고, LTREE로 계층 데이터를 다루거나 쿼리를 곧장 JSON으로 반환해 미들웨어를 대체하는 접근에는 저자도 인정하듯 장단점이 공존한다. SQL만으로 테트리스를 구현한 사례처럼 일부는 진지하게 받아들일 것이 아니다.

그럼에도 한국의 실무자에게 남는 메시지는 유효하다. 새 요구사항을 마주할 때 곧바로 반짝이는 신기술 X를 도입하기 전에 'PostgreSQL로는 안 되나?'를 먼저 묻는 습관이다. 시스템 개수를 하나라도 줄이면 운영 인력, 동기화 로직, 장애 지점이 함께 줄어든다. PostgreSQL이 문자 그대로 모든 문제의 답은 아닐지 몰라도, 많은 팀이 생각하는 것보다 훨씬 넓은 범위의 답이 될 수 있다는 것이 이 글의 실용적 결론이다.