2025년이 지났습니다. 실리콘밸리에서 또 한 해를 버텨낸 여러분에게 경의를 표합니다. 연말이 되면 기술 블로그들은 "올해의 혁신"을 터들썩하게 포장하지만, 운영팀의 시선에서 본 2025년 데이터베이스 시장은 'PostgreSQL에 의한 천하통일'과 그에 따른 '거대 자본의 영토 전쟁'으로 요약됩니다.
CMU의 앤디 파블로(Andy Pavlo) 교수가 정리한 2025년 리뷰를 기반으로, 화려한 마케팅 용어 뒤에 숨겨진 인프라의 현실과 우리 같은 엔지니어들이 새벽 3시 PagerDuty 호출을 피하기 위해 알아야 할 생존 전략을 정리했습니다.
1. PostgreSQL v18: 마침내 OS의 그늘에서 벗어나다
2025년 11월 출시된 PostgreSQL v18은 단순한 버전업이 아닙니다. 가장 중요한 변화는 비동기 I/O(Asynchronous I/O) 저장 서브시스템의 도입입니다.
이게 왜 중요하냐고요? 지금까지 PostgreSQL은 파일 시스템의 OS Page Cache에 과도하게 의존했습니다. 이는 트래픽이 폭주할 때 커널 레벨의 컨텍스트 스위칭 오버헤드와 예측 불가능한 레이턴시를 유발하는 주범이었습니다.
Staff SRE의 관점:
v18의 비동기 I/O 도입은 '드디어 올 것이 왔다'는 느낌입니다. 이제 데이터베이스가 디스크 I/O 스케줄링의 주도권을 OS로부터 가져오기 시작했습니다. 이는 고부하 상황에서 Tail Latency(P99)를 잡는 데 결정적인 역할을 할 것입니다. 튜닝 포인트가 OS 파라미터에서 DB 설정으로 넘어왔음을 의미하니, 만 만지작거리지 말고 실행 계획과 스토리지 엔진 파라미터를 다시 공부하십시오.
Skip Scan 지원(Prefix가 없는 인덱스 스캔)도 추가되었지만, 솔직히 말해 오라클은 20년 전(9i)부터 지원하던 기능입니다. 혁신이라기보다는 늦은 정상화에 가깝습니다.
2. 거대 자본의 습격: '순정'은 사라지고 '서비스'만 남았다
2025년은 빅테크 기업들이 PostgreSQL 전문 기업들을 쇼핑하듯 사들인 해입니다.
- Databricks는 Neon을 10억 달러에 인수했습니다.
- Snowflake는 Crunchy Data를 2억 5천만 달러에 인수했습니다.
- Microsoft는 HorizonDB라는 이름의 새로운 Azure 서비스를 내놓았습니다.
이들의 공통점은 '컴퓨팅과 스토리지의 분리(Separation of Compute and Storage)'입니다. 과거 Amazon Aurora가 개척했던 아키텍처가 이제 업계 표준이 되었습니다. Neon과 HorizonDB 모두 단일 Primary 노드 구조에서 스토리지만 분리하여 유연성을 확보하는 방식을 택하고 있습니다.
경고 (Warning):
빅테크가 이 회사들을 인수한 이유는 자선사업이 아닙니다. 이제 '값싸고 성능 좋은 매니지드 Postgres'의 시대는 저물고 있습니다. 그들은 자신들의 통합 데이터 플랫폼(Lakehouse 등) 안으로 DB를 끌어들여 락인(Lock-in)을 걸 것입니다.
Action Item:
회사에서 특정 벤더의 독점 기능(예: Snowflake의 proprietary extension)을 도입하자고 할 때 신중하십시오. 편의성은 달콤하지만, 나중에 클라우드를 옮겨야 할 때 그 코드는 기술 부채가 되어 여러분의 발목을 잡을 것입니다. 표준 SQL과 오픈소스 호환성을 유지하는 것이 탈출구를 열어두는 유일한 길입니다.
3. 분산 DB의 악몽: 샤딩 미들웨어의 귀환
PostgreSQL의 수평 확장(Scale-out)을 위한 시도들이 2025년에 다시 불붙었습니다.
- Supabase (Multigres): Vitess의 공동 창시자인 Sugu를 영입하여 개발 중입니다. MySQL의 샤딩 미들웨어인 Vitess의 개념을 Postgres에 이식하려는 시도입니다.
- PlanetScale (Neki): 역시 Vitess 철학을 계승한 Postgres 프로젝트를 발표했습니다.
이것은 2010년대 중반, NoSQL과 NewSQL이 난립하던 시절의 데자뷔입니다. 애플리케이션 레벨에서 처리하던 샤딩 로직을 미들웨어로 내리는 것입니다.
현실적인 조언:
"우리도 구글처럼 스케일 아웃해야 하지 않을까요?"라고 묻는 주니어 개발자가 있다면 말리십시오. 샤딩은 복잡도(Complexity)를 기하급수적으로 높입니다. 데이터 정합성 문제, 분산 트랜잭션의 성능 저하, 그리고 장애 발생 시 RCA(원인 분석)의 난이도 상승은 고스란히 운영팀의 몫입니다.
여러분의 서비스가 수십 TB 단위의 데이터를 다루지 않는다면, 단일 노드(Single Node) + 고성능 하드웨어(Scale-up) 조합이 가용성 99.99%를 지키는 훨씬 현명한 방법입니다. Sugu 같은 천재가 만든 도구라도, 운영하는 사람이 천재가 아니라면 장애는 반드시 터집니다.
4. 정리된 시장, 살아남은 자와 사라진 자
클라우드 3사(AWS, Google, MS)와 Oracle, IBM까지 모든 메이저 플레이어가 PostgreSQL을 1군 라인업으로 올렸습니다. 반면, Hydra나 PostgresML 같은 틈새시장을 노렸던 스타트업들은 파산했습니다. 시장은 냉정하게 '범용성'과 '자본력'을 선택했습니다.
SurrealDB처럼 벤치마크 수치를 위해 디스크 플러시(fsync)를 끄는 꼼수를 부리다 데이터 유실 사고를 낸 사례도 있었습니다. 엔지니어로서 절대 타협하지 말아야 할 것은 데이터의 내구성(Durability)입니다. 속도를 위해 안정성을 팔아먹는 기술은 언젠가 반드시 대가를 치릅니다.
결론: 엔지니어의 생존은 '기본기'에 있다
2025년의 데이터베이스 트렌드는 화려해 보이지만, 본질은 'PostgreSQL의 표준화'입니다.
이제 데이터베이스 엔지니어링의 핵심은 "어떤 DB를 쓸까?"를 고민하는 것이 아닙니다. "표준이 된 PostgreSQL을 어떻게 극한까지 튜닝하고, 클라우드 벤더의 종속성 없이 아키텍처를 설계할 것인가"가 핵심 역량이 되었습니다.
- OS가 아닌 DB 내부(Internals)를 파십시오. v18의 비동기 I/O처럼 DB 엔진이 하드웨어를 직접 제어하는 영역이 늘어나고 있습니다.
- 샤딩 환상에서 깨어나십시오. 수평 확장은 최후의 수단입니다. 수직 확장과 쿼리 최적화로 버틸 수 있을 때까지 버티는 것이 정신 건강에 이롭습니다.
- 벤더의 달콤한 제안을 의심하십시오. 편한 기능 뒤에는 항상 청구서와 락인이 기다리고 있습니다.
시스템은 거짓말을 하지 않습니다. 거짓말은 항상 마케팅 부서와 우리의 욕망이 합니다. 오늘도 장애 없는 밤을 기원합니다.
