Postgres extension 을 도입할 때 우리가 검토하는 5가지

PostgreSQL은 extension 생태계가 풍부하다. 전문 검색, 벡터 유사도, 시계열, 통계 함수 등 순수 SQL로 구현하기 번거로운 기능을 extension 하나로 해결할 수 있다. 작은 팀에게는 매력적인 선택지다. 그런데 우리는 extension을 도입한 뒤 예상치 못한 운영 비용을 치른 적이 있다. 그 경험을 바탕으로 지금은 다섯 가지를 먼저 확인한다.

1. 호스팅 환경에서 사용 가능한가

관리형 DB 서비스를 쓴다면 지원하는 extension 목록이 정해져 있다. 직접 컴파일이 필요한 extension은 서버에 루트 접근이 가능할 때만 설치된다. 도입 전에 현재 환경에서 CREATE EXTENSION 이 실제로 되는지 먼저 확인한다.

2. Postgres 버전 업그레이드 시 호환성이 유지되는가

extension에는 각자의 릴리스 사이클이 있다. Postgres 메이저 버전이 올라갈 때 extension이 따라오지 않는 경우가 있다. 유지보수가 활발한지, 최근 커밋이 언제인지를 저장소에서 확인한다. 마지막 커밋이 2년 전인 extension은 신중하게 본다.

3. pg_dump 와 복원이 정상 동작하는가

백업·복원 흐름에서 extension이 개입하면 예상치 못한 오류가 나올 수 있다. 특히 C로 작성된 extension은 덤프 파일을 다른 서버에 복원할 때 바이너리가 없으면 실패한다. 도입 전 개발 환경에서 dump→restore 전 과정을 한 번 돌려본다.

4. 쿼리 플래너에 영향을 주는가

일부 extension은 커스텀 스캔 노드나 플래너 훅을 등록한다. 이런 경우 기존 쿼리의 실행 계획이 바뀌어 성능이 달라질 수 있다. EXPLAIN ANALYZE로 주요 쿼리를 extension 설치 전후로 비교한다.

5. 해당 기능을 정말 extension으로 풀어야 하는가

가장 단순한 질문이면서 가장 자주 건너뛰는 질문이다. 전문 검색이 필요할 때 pg_trgm 이 정답인지, 아니면 애플리케이션 레이어에서 처리하거나 별도 검색 엔진을 붙이는 게 장기적으로 나은지를 따진다. extension 수는 적을수록 유지보수가 쉽다.

정리

extension은 강력하지만 도입 비용이 없는 게 아니다. 위 다섯 가지를 체크리스트처럼 쓰면서부터 “편리해서 추가했다가 나중에 후회”하는 케이스가 줄었다. 작은 팀일수록 운영 복잡도를 낮게 유지하는 게 중요하다.

— by slecs