PostgreSQL의 잠재력을 극대화하는 확장 기능

1. 서론: 관계형 데이터베이스를 넘어 데이터 플랫폼으로

PostgreSQL의 핵심 설계 철학은 ’확장성(Extensibility)’에 있다. 이 철학은 PostgreSQL을 단순한 데이터 저장소의 역할을 넘어, 특정 도메인의 복잡한 문제를 해결하는 다목적 데이터 플랫폼으로 변모시키는 원동력이 되었다.1 지리 공간 정보 분석, 시계열 데이터 처리, 비정형 데이터 관리, 고성능 검색 등 현대 애플리케이션이 요구하는 다양한 기능은 PostgreSQL의 확장(Extension) 아키텍처를 통해 구현된다. 확장은 단순한 부가 기능이 아니라, PostgreSQL을 현대적이고 복잡한 시스템 아키텍처의 중심으로 만드는 핵심 동력이다.

확장은 새로운 데이터 타입, 함수, 연산자, 인덱스 접근 방법 등을 포함하는 관련 SQL 객체들의 패키지로서, 데이터베이스의 핵심 기능을 수정하지 않고도 새로운 능력을 부여한다.1 예를 들어, CREATE EXTENSION postgis;라는 단 한 줄의 명령어로 PostgreSQL은 세계 최고 수준의 지리정보시스템(GIS) 데이터베이스로 탈바꿈한다.1 이는 PostgreSQL의 개방적인 구조가 얼마나 강력한지를 보여주는 대표적인 사례다.

본 보고서는 PostgreSQL 확장의 개념적 이해에서부터 시작하여, 주요 확장의 기능과 내부 동작 원리를 심층적으로 분석하고, 실무 환경에서의 전략적 활용 방안과 고려사항까지 포괄하는 종합적인 가이드를 제공하는 것을 목표로 한다. 이를 통해 데이터베이스 관리자, 백엔드 개발자, 데이터 엔지니어 및 솔루션 아키텍트가 PostgreSQL의 잠재력을 최대한 활용하여 견고하고 효율적인 시스템을 구축하는 데 필요한 깊이 있는 지식을 전달하고자 한다.

2. PostgreSQL 확장의 이해

2.1 확장의 개념과 구조

PostgreSQL 확장은 데이터베이스 시스템의 기능을 확장하는 강력한 도구로, 핵심 배포판에서 기본적으로 제공하지 않는 추가 기능을 제공하는 SQL 객체의 집합이다.2 이러한 객체에는 새로운 함수, 데이터 타입, 연산자, 인덱스 접근 방법 등이 포함될 수 있으며, 간단한 SQL 스크립트부터 C 언어로 작성된 복잡한 이진 라이브러리에 이르기까지 다양한 형태로 구현된다.1

모든 확장은 물리적으로 최소 두 가지 핵심 파일로 구성된다.2 첫 번째는 **컨트롤 파일(.control)**이다. 이 파일은 확장의 이름, 기본 버전, 설명, 의존성 등 확장을 식별하고 관리하는 데 필요한 메타데이터를 담고 있다. 두 번째는 하나 이상의 **SQL 스크립트 파일(.sql)**이다. 이 스크립트 파일에는 CREATE EXTENSION 명령이 실행될 때 데이터베이스 내에 실제 객체(함수, 타입 등)를 생성하는 데 필요한 SQL 명령어들이 포함되어 있다. 확장의 기능은 순수 SQL이나 PL/pgSQL로 작성될 수도 있지만, 높은 성능이 요구되는 복잡한 연산의 경우 C나 Rust와 같은 저수준 언어로 작성된 후 컴파일된 공유 라이브러리(.so 또는 .dll) 형태로 제공되기도 한다.2

이러한 전통적인 파일 기반 아키텍처는 확장을 설치하기 위해 서버의 파일 시스템에 직접 접근해야 한다는 것을 전제로 한다. 그러나 이는 보안과 안정성을 최우선으로 고려하여 파일 시스템 접근을 엄격하게 제한하는 관리형 클라우드 데이터베이스 환경(예: AWS RDS, Azure Database for PostgreSQL)에서는 상당한 제약으로 작용했다.4 클라우드 제공업체들이 자체적으로 선별하고 검증한 제한된 확장 목록만을 제공하는 근본적인 이유가 바로 여기에 있다.

이러한 제약을 극복하기 위한 새로운 패러다임으로 pg_tle(PostgreSQL용 신뢰할 수 있는 언어 확장)가 등장했다.5 pg_tle는 파일 시스템에 접근할 필요 없이, 데이터베이스 관리자가 JavaScript, Perl, Tcl과 같은 신뢰할 수 있는 언어를 사용하여 안전하게 확장을 개발하고 데이터베이스 내에서 직접 실행할 수 있도록 지원한다. 이는 확장 생태계가 클라우드 중심의 현대 IT 환경에 적응하며 진화하고 있음을 보여주는 중요한 증거다. 즉, ’파일 시스템 의존성’이라는 전통적인 제약이 데이터베이스 내부에서 관리되는 ’안전한 개발 환경’으로 전환되는 기술적 변곡점을 나타내는 것이다.

2.2 확장의 생명주기 관리

PostgreSQL 확장은 명확하게 정의된 생명주기를 가지며, 관리자는 일련의 표준 SQL 명령어를 통해 이를 제어할 수 있다.

설치 (CREATE EXTENSION)

데이터베이스에 새로운 확장을 로드하는 가장 기본적인 명령어는 CREATE EXTENSION이다.6 이 명령을 실행하면 PostgreSQL은 해당 확장의 컨트롤 파일과 SQL 스크립트 파일을 찾아 실행함으로써 관련된 모든 객체를 데이터베이스에 생성한다. 이 명령어는 여러 유용한 옵션을 제공한다. IF NOT EXISTS는 동일한 이름의 확장이 이미 존재할 경우 오류를 발생시키지 않고 경고만 표시한다. SCHEMA는 확장의 객체들이 설치될 스키마를 지정할 수 있게 해준다. VERSION은 특정 버전의 확장을 설치하도록 강제하며, CASCADE 옵션은 해당 확장이 의존하는 다른 확장들이 아직 설치되지 않았을 경우, 재귀적으로 함께 설치해주는 강력한 기능이다.6

업그레이드 (ALTER EXTENSION… UPDATE)

설치된 확장은 ALTER EXTENSION 명령어를 통해 사용 가능한 최신 버전으로 업그레이드할 수 있다.2 ALTER EXTENSION my_extension UPDATE TO ‘2.0’;과 같은 명령은 확장의 스크립트를 실행하여 새로운 버전의 객체를 생성하거나 기존 객체를 수정한다.7

제거 (DROP EXTENSION)

DROP EXTENSION 명령어는 확장을 데이터베이스에서 제거한다.2 이 명령은 확장이 생성했던 모든 객체를 함께 삭제한다. 만약 다른 데이터베이스 객체가 확장이 제공하는 객체에 의존하고 있다면, 제거는 실패하게 되어 데이터 무결성을 보호한다.

확인

데이터베이스 관리자는 psql의 메타 명령어인 \dx를 사용하여 현재 데이터베이스에 설치된 확장의 목록, 버전, 스키마 정보를 쉽게 확인할 수 있다.7 또한, pg_available_extensions 뷰를 조회하면 현재 시스템에서 설치 가능한 모든 확장의 목록을 볼 수 있다.8

확장의 생명주기 관리는 단순한 기술적 절차 이상의 의미를 갖는다. 많은 관리자들이 PostgreSQL의 메이저 또는 마이너 버전 업그레이드를 실행하면 설치된 확장도 자동으로 호환되거나 업그레이드될 것이라고 가정하지만, 이는 매우 위험한 오해다. AWS Aurora PostgreSQL 관련 문서에서는 “DB 클러스터를 새로운 메이저 또는 마이너 버전으로 업그레이드해도 PostgreSQL 확장이 동시에 업그레이드되지 않는다“고 명확히 경고하고 있다.9

이는 단순한 불편함을 넘어 심각한 운영 리스크를 내포한다. 상황에 따라서는 특정 확장을 데이터베이스 엔진 업그레이드 이전에 먼저 업그레이드해야 할 수도 있다.9 이러한 숨겨진 종속성과 인과 관계는 데이터베이스 업그레이드 계획의 복잡성을 기하급수적으로 증가시킨다. 따라서 데이터베이스 관리자는 단순히 PostgreSQL의 릴리스 노트만 확인할 것이 아니라, 운영 환경에서 사용 중인 모든 확장의 릴리스 노트와 버전별 호환성 매트릭스를 교차 검증해야 하는 무거운 책임을 진다. 이는 새로운 확장을 선택할 때 단순히 ’기능’뿐만 아니라, ’커뮤니티의 유지보수 활성도’와 ’업그레이드 지원 주기’가 매우 중요한 평가 기준이 되어야 함을 시사한다. 활발하게 관리되지 않는 확장은 미래의 기술 부채가 되어, 데이터베이스 시스템의 현대화를 가로막는 족쇄가 될 수 있다.

2.3 확장 생태계: PGXN

PGXN(PostgreSQL Extension Network)은 오픈소스 PostgreSQL 확장을 위한 중앙 집중식 저장소 및 배포 시스템이다.10 PGXN의 목적은 흩어져 있는 유용한 확장들을 한곳에 모아 사용자가 쉽게 검색하고, 문서를 확인하며, 다운로드하여 설치할 수 있도록 체계적인 생태계를 제공하는 것이다.10

PGXN은 크게 네 가지 핵심 구성 요소로 이루어져 있다.10 첫째, 확장 개발자들이 자신의 확장을 업로드하고 관리할 수 있는 업로드 서버가 있다. 둘째, 업로드된 확장 패키지와 메타데이터를 담고 있는 미러링 가능한 배포 디렉토리가 있어 전 세계적으로 빠른 다운로드를 지원한다. 셋째, 사용자가 키워드나 기능으로 확장을 검색하고 온라인에서 문서를 바로 열람할 수 있는 **웹사이트(pgxn.org)**가 제공된다.11 마지막으로, pgxnclient와 같은 커맨드라인 클라이언트를 통해 터미널에서 pgxn install <extension_name>과 같은 간단한 명령으로 확장의 다운로드, 컴파일, 설치 과정을 자동화할 수 있다.13

PGXN의 설계는 수십 년간 안정적인 라이브러리 배포, 버전 관리, 자동화된 테스트의 표준을 정립한 Perl의 CPAN(Comprehensive Perl Archive Network)에서 깊은 영감을 받았다.10 PGXN이 CPAN을 모델로 삼았다는 사실은 PostgreSQL 커뮤니티가 단순히 새로운 기능을 추가하는 것을 넘어, 확장 생태계의 ‘품질’, ‘신뢰성’, ’지속 가능성’을 체계적으로 관리하려는 성숙한 단계에 접어들었음을 의미한다.

이는 확장의 메타데이터 표준을 정의하는 META.json 파일, PGXN 내에서 고유해야 하는 확장 이름 정책, 그리고 오픈소스 라이선스를 강제하는 정책 등에서 명확히 드러난다.10 즉, PGXN은 “어떤 확장이 존재하는가?“라는 기본적인 질문을 넘어, “이 확장을 프로덕션 환경에서 신뢰하고 사용할 수 있는가?“라는 더 중요한 질문에 답을 주기 위한 사회-기술적 인프라다. 이러한 체계는 기업 사용자들이 서드파티(third-party) 확장을 도입할 때 겪는 심리적, 기술적 장벽을 낮추는 데 결정적인 역할을 하며, PostgreSQL 생태계의 건전한 성장을 촉진한다.

3. 기능별 핵심 확장 심층 분석

PostgreSQL의 확장 생태계는 매우 방대하며 다양한 기능을 제공한다. 본 장에서는 가장 널리 사용되고 중요한 확장들을 기능별로 분류하여 그 원리와 활용법을 심층적으로 분석한다.

3.1 공간 정보 처리: PostGIS

PostGIS는 단순한 확장을 넘어, PostgreSQL을 완전한 기능을 갖춘 지리정보시스템(GIS) 데이터베이스로 변모시키는 ’플랫폼급 확장’으로 평가받는다.1 PostGIS를 설치하면 데이터베이스는 지형 데이터 저장, 공간 분석, 지도 서비스 구현 등 복잡한 공간 정보 처리 능력을 갖추게 된다.

PostGIS의 핵심은 OGC(Open Geospatial Consortium) 표준을 따르는 두 가지 핵심 데이터 타입, 즉 geometry와 geography에 있다.16 geometry 타입은 데카르트 좌표계를 사용하는 평면을 기반으로 하며, 두 지점 사이의 최단 거리는 직선으로 계산된다. 반면, geography 타입은 지구와 같은 구면(球面)을 기반으로 하며, 위도와 경도 좌표를 사용하여 대원 거리를 계산한다.16 이 타입들은 점(Point), 선(LineString), 다각형(Polygon)과 같은 기본적인 도형부터, 원호(circular arc)를 포함하는 곡선 다각형(CurvePolygon)과 같은 고급 기하 객체까지 표현할 수 있다.16

PostGIS는 수백 가지에 달하는 강력한 공간 함수와 연산자를 제공한다. ST_GeomFromText나 ST_GeomFromEWKT는 텍스트 형식의 공간 데이터를 데이터베이스 객체로 변환하고, ST_Distance는 두 공간 객체 사이의 거리를 계산한다.16 특히 ST_DWithin 함수는 특정 지점으로부터 일정 반경 내에 있는 모든 객체를 효율적으로 찾는 데 사용된다. 실제 프로젝트 적용 사례에서, 복잡하고 가독성이 떨어지는 하버사인(Haversine) 공식을 사용하여 거리를 계산하는 SQL 쿼리가 ST_DWithin 함수 하나로 대체되어 코드의 가독성과 유지보수성을 극적으로 향상시킨 바 있다.17

PostGIS의 진정한 힘은 단순히 다양한 함수를 제공하는 데 그치지 않는다. 그 핵심은 PostgreSQL의 쿼리 최적화기(Query Planner)와의 깊은 통합에 있다. PostGIS는 R-Tree 자료구조에 기반한 GiST(Generalized Search Tree) 인덱스를 사용하여 공간 검색 쿼리의 성능을 획기적으로 개선한다.15 ST_DWithin(geom, point, 1000)과 같은 공간 조건이 포함된 쿼리가 주어지면, PostGIS는 PostgreSQL 최적화기가 이 조건을 이해하고 GiST 공간 인덱스를 활용하여 효율적인 실행 계획을 생성하도록 돕는다.

만약 PostGIS가 단순한 외부 함수 라이브러리에 불과했다면, 최적화기는 ST_DWithin 함수를 테이블의 모든 행에 대해 한 번씩 실행하는 ’블랙박스’로 취급하여 비효율적인 전체 테이블 스캔(Full Table Scan)을 수행했을 것이다. 그러나 PostGIS는 새로운 ’인덱스 접근 방식’을 최적화기에 등록함으로써, 최적화기가 공간 데이터의 특성(예: 경계 상자(Bounding Box) 비교)을 이해하고 인덱스를 통해 검색 범위를 기하급수적으로 줄일 수 있도록 ’교육’시킨다. 즉, PostGIS는 PostgreSQL의 ’두뇌’가 공간적으로 사고하도록 업그레이드하는 것이며, 이것이 다른 데이터베이스가 제공하는 제한적인 공간 기능과 PostGIS를 근본적으로 차별화하는 지점이다.

3.2 성능 모니터링 및 최적화

PostgreSQL은 다양한 확장을 통해 데이터베이스의 성능을 심층적으로 분석하고 최적화할 수 있는 강력한 도구를 제공한다. 이 확장들은 데이터베이스의 내부 동작을 투명하게 만들어 관리자가 병목 지점을 정확히 식별하고 해결할 수 있도록 돕는다.

3.2.1 pg_stat_statements

pg_stat_statements는 데이터베이스 관리자에게 필수적인 성능 분석 도구로, 서버에서 실행된 모든 SQL 문의 실행 통계를 추적하고 집계한다.3 이 확장을 활성화하면 각 쿼리별로 호출 횟수(calls), 총 실행 시간(total_time), 평균 실행 시간, 처리된 행의 수(rows), 디스크 I/O 관련 정보(읽고 쓴 블록 수) 등을 pg_stat_statements 뷰를 통해 확인할 수 있다.18

이 확장을 활용하는 일반적인 워크플로우는 다음과 같다. 먼저, total_time을 기준으로 뷰를 정렬하여 시스템 전체에서 가장 많은 시간을 소비하는 쿼리, 즉 성능 병목을 유발하는 ’슬로우 쿼리’를 식별한다.18 그 다음, 식별된 쿼리에 대해 EXPLAIN 또는 EXPLAIN ANALYZE 명령을 실행하여 PostgreSQL이 해당 쿼리를 어떻게 처리하는지, 즉 실행 계획(Execution Plan)을 분석한다. 실행 계획 분석을 통해 비효율적인 테이블 스캔이나 부적절한 조인 방식이 발견되면, 인덱스를 추가하거나 쿼리 구조를 변경하는 등의 최적화를 수행한다.18 이 확장을 사용하기 위해서는 postgresql.conf 파일의 shared_preload_libraries 설정에 pg_stat_statements를 추가하고 서버를 재시작한 뒤, CREATE EXTENSION 명령을 실행해야 한다.18

3.2.2 pg_buffercache

pg_buffercache는 PostgreSQL의 공유 버퍼 캐시(메모리)의 상태를 실시간으로 들여다볼 수 있게 해주는 저수준 분석 도구다.3 공유 버퍼 캐시는 디스크에서 읽어온 데이터 페이지를 메모리에 저장하여 디스크 I/O를 줄이는 핵심적인 성능 요소다. pg_buffercache 뷰를 조회하면 현재 캐시에 어떤 테이블이나 인덱스의 어떤 데이터 블록이 상주하고 있는지, 해당 블록이 ‘dirty’(디스크에 기록해야 할 변경 사항이 있음) 상태인지, 그리고 얼마나 자주 사용되었는지(usagecount) 등의 상세한 정보를 얻을 수 있다.20

관리자는 pg_buffercache 뷰를 pg_class 시스템 카탈로그 테이블과 조인하여 특정 테이블이나 인덱스가 캐시에 얼마나 효율적으로 상주하고 있는지(cache hit ratio)를 정량적으로 분석할 수 있다.20 예를 들어, 자주 액세스되는 테이블의 데이터가 캐시에 거의 없다면, 이는 shared_buffers 파라미터 값이 너무 작거나 다른 대규모 작업으로 인해 캐시에서 밀려났음을 시사한다. 이러한 분석은 메모리 관련 파라미터를 튜닝하는 데 중요한 근거 자료로 활용된다.

3.2.3 기타 성능 관련 확장

• pg_repack: 시간이 지남에 따라 UPDATE와 DELETE가 반복되면 테이블과 인덱스 내부에 비어있는 공간, 즉 ’블로트(Bloat)’가 발생하여 저장 공간을 낭비하고 성능을 저하시킨다. pg_repack은 테이블이나 인덱스에 대한 배타적 잠금(exclusive lock)을 최소화하여 서비스 중단 없이(Online) 블로트를 제거하고 테이블을 재구성하는 강력한 도구다.7
• hypopg: 인덱스 추가는 쿼리 성능을 향상시킬 수 있지만, 잘못된 인덱스는 오히려 쓰기 성능을 저하시키고 공간을 낭비한다. hypopg는 실제로 인덱스를 생성하는 비용과 시간 없이, 가상의 ’가상 인덱스(hypothetical index)’를 만들어 해당 인덱스가 존재할 경우 쿼리 실행 계획이 어떻게 변하는지를 EXPLAIN을 통해 미리 시뮬레이션해볼 수 있게 해준다.22 이를 통해 DBA는 인덱스 생성 전략의 효과를 사전에 검증할 수 있다.

이러한 성능 관련 확장들은 단편적인 도구의 집합이 아니다. 이들은 현대 시스템 관리의 핵심 개념인 ’관찰 가능성(Observability)’을 데이터베이스 계층에 구현하는 통합된 시스템으로 기능한다. pg_stat_statements는 “애플리케이션이 데이터베이스에 무엇을 요청하는가?“라는 ’작업 부하(Workload)’의 관점을 제공하고, pg_buffercache는 “데이터베이스가 그 요청을 처리하기 위해 내부 리소스를 어떻게 사용하는가?“라는 ’시스템 상태(System State)’의 관점을 제공한다.

이 두 확장의 조합은 관리자가 ’증상’과 ’원인’을 논리적으로 연결하는 강력한 분석 체계를 구축하게 한다. 예를 들어, pg_stat_statements에서 특정 쿼리의 total_time이 급증하는 ’증상’이 관찰되었다고 가정하자. 이때 pg_buffercache를 조회하여 해당 쿼리가 접근하는 테이블의 데이터가 캐시에서 밀려나 디스크 I/O가 급증했음을 확인한다면, 이는 ’캐시 미스’라는 명확한 ’원인’을 진단한 것이다. 더 나아가 hypopg를 사용해 인덱스 추가라는 ’처방’을 시뮬레이션하고, pg_repack으로 테이블을 최적화하는 ’치료’를 수행할 수 있다. 이처럼 성능 확장들은 ’진단 → 분석 → 시뮬레이션 → 해결’로 이어지는 체계적인 성능 관리 방법론을 PostgreSQL 내에서 구현할 수 있게 한다.

3.3 데이터 모델링의 확장

PostgreSQL은 확장을 통해 전통적인 관계형 데이터 모델의 한계를 넘어, 다양한 형태의 데이터를 효율적으로 저장하고 처리할 수 있는 능력을 갖춘다. 이는 개발자가 특정 데이터 유형에 더 적합한 다른 데이터베이스 시스템을 도입하는 대신, PostgreSQL 내에서 여러 데이터 모델의 장점을 통합하여 사용할 수 있게 해준다.

3.3.1 hstore

hstore 확장은 단일 컬럼 내에 (키, 값) 쌍의 집합을 저장할 수 있는 데이터 타입을 제공한다.3 이는 제품의 속성처럼 항목마다 가질 수 있는 속성의 종류와 개수가 다른 경우, 즉 스키마가 고정되지 않은 동적 속성을 저장하는 데 매우 유용하다.22 예를 들어, attributes hstore 컬럼에 'cpu' => 'i7', 'ram' => '16GB', 'ssd' => '512GB'와 같은 데이터를 저장할 수 있다. hstore는 특정 키의 존재 여부(? 연산자)나 값에 대한 조건(-> 연산자)을 WHERE 절에 사용하여 효율적으로 검색할 수 있는 연산자도 함께 제공한다.24 hstore는 이후에 등장한 강력한 JSON/JSONB 타입의 전신으로서, PostgreSQL에서 반정형 데이터를 처리하는 가능성을 연 역사적 의미를 지닌다.

3.3.2 citext

citext 확장은 대소문자를 구분하지 않는(case-insensitive) 문자열 데이터 타입을 제공한다.3 내부적으로 citext 타입의 값을 비교할 때는 PostgreSQL의 lower() 함수를 호출하여 두 값을 모두 소문자로 변환한 뒤 비교하는 것과 동일하게 동작한다.25

이 타입의 가장 큰 장점은 개발의 편의성이다. 사용자 이메일 주소나 아이디를 저장하는 컬럼에 citext를 사용하면, 애플리케이션 코드나 SQL 쿼리에서 WHERE lower(email) = lower(...)와 같이 lower() 함수를 반복적으로 사용할 필요가 없어진다.25 WHERE email = 'User@Example.com'과 같은 간단한 쿼리만으로도 대소문자에 관계없이 정확한 결과를 얻을 수 있어 코드가 간결해지고 실수를 줄일 수 있다. 또한, PRIMARY KEY나 UNIQUE 제약 조건 역시 대소문자를 구분하지 않고 적용되므로, ’user@example.com’과 ’User@Example.com’이 동시에 저장되는 것을 데이터베이스 수준에서 방지할 수 있다.26

3.3.3 uuid-ossp

uuid-ossp 확장은 다양한 표준 알고리즘에 따라 범용 고유 식별자(UUID, Universally Unique Identifier)를 생성하는 함수들을 제공한다.3 전통적으로 데이터베이스의 기본 키(Primary Key)는 1, 2, 3,… 과 같이 순차적으로 증가하는 정수(SERIAL 또는 IDENTITY 타입)를 사용해왔다. 그러나 이러한 방식은 분산 시스템 환경에서는 여러 노드에서 동시에 키를 생성할 때 충돌이 발생할 수 있고, URL 등에 키 값이 노출될 경우 데이터의 총 개수나 생성 순서를 쉽게 추측할 수 있어 보안상 취약점을 가질 수 있다.

UUID는 이러한 문제들을 해결하기 위해 사용된다. 128비트의 매우 큰 수로, 전 세계적으로 고유함이 사실상 보장되는 식별자다. uuid-ossp 확장은 uuid_generate_v1()(타임스탬프와 MAC 주소 기반), uuid_generate_v4()(순수 난수 기반) 등 여러 버전의 UUID 생성 함수를 제공한다.28 가장 널리 사용되는 uuid_generate_v4() 함수를 테이블 컬럼의 기본값(default)으로 설정하면, 새로운 행이 삽입될 때마다 자동으로 고유한 UUID가 생성된다.28

이러한 데이터 모델링 관련 확장들은 PostgreSQL이 다른 데이터베이스 패러다임과의 경쟁에서 단순히 방어하는 것이 아니라, 그들의 핵심적인 장점을 관계형 모델 안으로 적극적으로 ’흡수’하고 통합하는 전략을 취하고 있음을 보여준다. hstore와 JSONB는 문서 지향 데이터베이스의 ’스키마 유연성’을, uuid-ossp는 분산 데이터베이스의 ’충돌 없는 ID 생성’을, citext는 사용자 입력 데이터 처리 시 빈번하게 발생하는 ‘정규화’ 문제를 데이터베이스 계층에서 직접 해결한다.

이로 인해 개발자는 더 이상 “유연한 스키마를 위해 MongoDB를 추가로 도입해야 할까?” 또는 “분산 ID 생성을 위해 별도의 서비스를 구축해야 할까?“와 같은 복잡한 아키텍처적 고민을 할 필요가 없어진다. PostgreSQL은 확장을 통해 이러한 요구사항들을 ‘하나의 데이터베이스’ 내에서 해결할 수 있는 ‘다중 모델(Multi-model)’ 데이터베이스로 진화한다. 이는 개발자가 데이터 일관성, ACID 트랜잭션 지원 등 관계형 모델의 강력한 보장을 그대로 유지하면서도, 필요에 따라 NoSQL의 유연성을 선택적으로 취할 수 있게 함으로써, 전체 시스템 아키텍처의 복잡성을 줄이고 데이터 관리의 일관성을 높이는 강력한 이점으로 작용한다.

3.4 데이터 통합 및 연동

현대의 분산 시스템 환경에서는 데이터가 여러 데이터베이스나 서비스에 분산되어 저장되는 경우가 많다. PostgreSQL은 외부 데이터 래퍼(Foreign Data Wrapper, FDW)라는 강력한 기능을 통해 이러한 분산된 데이터를 효과적으로 통합하고 연동할 수 있는 방법을 제공한다.

3.4.1 postgres_fdw

FDW는 PostgreSQL이 원격 데이터 소스에 접근하여 마치 로컬 테이블처럼 데이터를 읽고 쓸 수 있게 해주는 확장 메커니즘이다.29 이는 2003년에 발표된 SQL 표준인 SQL/MED(SQL Management of External Data)에 기반한 기능이다.29 다양한 FDW가 존재하지만(예: MySQL, Oracle, MongoDB 용 FDW), 그 중 postgres_fdw는 원격에 있는 다른 PostgreSQL 데이터베이스의 테이블에 투명하게 접근할 수 있게 해주는 가장 기본적이고 널리 사용되는 확장이다.30

postgres_fdw를 사용하는 절차는 명확한 단계로 구성된다.

1. CREATE EXTENSION postgres_fdw;: 현재 데이터베이스에 FDW 기능을 설치한다.29
2. CREATE SERVER: 원격 데이터베이스의 접속 정보(호스트, 포트, 데이터베이스 이름 등)를 담은 ‘서버’ 객체를 생성한다.29
3. CREATE USER MAPPING: 로컬 데이터베이스의 사용자와 원격 서버에 접속할 때 사용할 사용자 및 비밀번호를 매핑한다.29
4. CREATE FOREIGN TABLE: 원격 테이블의 구조와 동일한 ’외부 테이블(Foreign Table)’을 로컬에 정의한다. 또는 IMPORT FOREIGN SCHEMA 명령을 사용하여 원격 스키마의 모든 테이블 정의를 한 번에 가져올 수도 있다.29

이 설정이 완료되면, 사용자는 외부 테이블에 대해 일반 로컬 테이블과 거의 동일하게 SELECT, INSERT, UPDATE, DELETE 쿼리를 실행할 수 있다.30

가장 주의해야 할 점은 로컬 테이블과 외부 테이블을 조인할 때 발생할 수 있는 심각한 성능 저하 문제다.30 초기 버전의 FDW는 외부 테이블의 모든 데이터를 네트워크를 통해 로컬 서버로 가져온 뒤, 메모리에서 조인 작업을 수행했다. 이는 외부 테이블의 크기가 클 경우 엄청난 네트워크 트래픽과 부하를 유발했다.

이 문제를 해결하기 위해 최신 버전의 PostgreSQL에서는 ‘푸시다운(Pushdown)’ 최적화 기능이 대폭 강화되었다.29 이는 WHERE 조건절, ORDER BY, 집계 함수(SUM, COUNT 등), 심지어 테이블 간의 JOIN 연산까지 원격 서버에서 직접 실행하도록 쿼리를 ‘밀어넣는’ 기술이다. 이렇게 하면 원격 서버에서 데이터가 필터링되고 집계된 후, 최소한의 결과 집합만이 네트워크를 통해 전송되므로 성능이 크게 향상된다. EXPLAIN VERBOSE 명령을 사용하면 어떤 작업이 원격 서버로 푸시다운되었는지 확인할 수 있으며, 이는 FDW 성능 튜닝의 핵심적인 과정이다.

트랜잭션 처리와 관련하여, 로컬 트랜잭션이 커밋되거나 롤백될 때 원격 서버에서 실행된 작업도 함께 커밋되거나 롤백된다. 그러나 이는 원자성을 보장하는 2단계 커밋(two-phase commit)과 같은 분산 트랜잭션 관리를 지원하지는 않으므로, 여러 원격 서버에 걸친 복잡한 쓰기 작업 시에는 데이터 일관성에 대한 추가적인 고려가 필요하다.30

postgres_fdw는 데이터베이스의 역할을 근본적으로 변화시킨다. 전통적으로 데이터베이스는 데이터가 격리되어 저장되는 ’데이터 사일로(Data Silo)’였다. 그러나 postgres_fdw를 사용하면 하나의 PostgreSQL 인턴스가 여러 다른 PostgreSQL 데이터베이스에 대한 단일 진입점(Single Point of Access) 역할을 하는 ’데이터 허브(Data Hub)’로 변모할 수 있다.

이는 특히 각 서비스가 자체 데이터베이스를 가지는 마이크로서비스 아키텍처(Database-per-service) 패턴에서 강력한 힘을 발휘한다. 예를 들어, 여러 마이크로서비스에 분산된 데이터를 통합하여 분석 리포트를 생성해야 할 경우, 각 서비스의 API를 개별적으로 호출하여 데이터를 취합하는 복잡한 과정을 거치는 대신, 하나의 중앙 PostgreSQL ‘허브’ 데이터베이스에 각 서비스 데이터베이스를 외부 테이블로 연결할 수 있다. 분석가는 이 허브 데이터베이스에 접속하여 표준 SQL을 사용해 여러 서비스에 분산된 데이터를 마치 하나의 거대한 데이터베이스인 것처럼 자유롭게 조인하고 집계할 수 있다. 이는 사실상 데이터 가상화(Data Virtualization) 계층을 PostgreSQL 자체적으로 구축하는 것과 같다. 이 접근 방식은 불필요한 데이터 이동(ETL) 파이프라인의 복잡성을 줄이고, ’실시간 데이터 접근’을 가능하게 함으로써 데이터 아키텍처를 근본적으로 단순화하고 데이터의 최신성을 보장하는 중요한 역할을 한다.

3.5 보안 강화

데이터베이스 보안은 현대 애플리케이션에서 가장 중요한 요소 중 하나다. PostgreSQL은 pgcrypto 확장을 통해 데이터베이스 계층에서 강력한 암호화 기능을 제공하여 데이터의 기밀성과 무결성을 보장한다.

3.5.1 pgcrypto

pgcrypto는 데이터베이스 내에 저장되는 데이터를 암호화하고, 비밀번호와 같은 민감한 정보를 안전하게 해싱하기 위한 포괄적인 암호화 함수 모음을 제공하는 확장이다.3

주요 기능은 크게 해싱과 암호화로 나뉜다.

• 해싱(Hashing): crypt()와 gen_salt() 함수를 사용하여 비밀번호를 안전하게 해싱할 수 있다.32 해싱은 입력값을 고정된 길이의 무작위 문자열로 변환하는 단방향 암호화 과정으로, 원본 값을 복호화하는 것은 불가능하다. gen_salt() 함수는 해싱 과정에 임의의 ‘솔트(salt)’ 값을 추가하여, 동일한 비밀번호를 가진 여러 사용자가 서로 다른 해시 값을 갖도록 만들어 레인보우 테이블 공격과 같은 보안 위협을 방지한다.32 사용자 인증 시에는 입력된 비밀번호를 저장된 해시 값에 포함된 솔트를 사용하여 다시 해싱한 후, 그 결과를 저장된 해시 값과 비교하는 방식으로 이루어진다.32
• 대칭키 암호화: encrypt()와 decrypt() 함수는 동일한 키를 사용하여 데이터를 암호화하고 복호화하는 대칭키 암호화 기능을 제공한다.32 주민등록번호나 신용카드 번호와 같이 나중에 원본 값을 확인해야 하는 민감한 정보를 저장할 때 사용된다. AES, Blowfish 등 다양한 암호화 알고리즘을 지원하며, 암호화된 결과는 바이너리(bytea) 타입이므로, 텍스트 형식으로 저장하기 위해 encode(..., 'hex') 함수와 함께 사용하는 것이 일반적인 패턴이다. 복호화는 이 과정의 역순으로, decode(..., 'hex')를 먼저 수행한 후 decrypt() 함수를 호출한다.34
• 공개키 암호화(PGP): pgcrypto는 더 높은 수준의 보안을 위해 PGP(Pretty Good Privacy) 표준에 기반한 공개키 암호화 기능도 제공한다.32 이는 공개키로 암호화하고 해당 공개키와 쌍을 이루는 비밀키로만 복호화할 수 있는 방식으로, 키 관리를 더욱 안전하게 할 수 있다.

pgcrypto를 사용하기 위해서는 다른 확장과 마찬가지로 CREATE EXTENSION pgcrypto; 명령을 실행하여 데이터베이스에 설치해야 한다.35

전통적으로 데이터 암호화는 애플리케이션 코드 내에서 처리되는 경우가 많았다. 이 접근 방식은 여러 애플리케이션(웹 서버, 모바일 백엔드, 배치 작업 등)이 동일한 암호화 로직과 키 관리 정책을 일관되게 구현하고 유지해야 하는 상당한 부담을 안겨준다. 하나의 애플리케이션에서라도 로직에 오류가 있거나 키가 유출되면 전체 시스템의 보안이 무너질 수 있다.

pgcrypto는 이러한 보안의 책임을 애플리케이션 계층에서 데이터 계층으로 이동시키는 패러다임의 전환을 가져온다. 암호화 로직이 데이터베이스 자체에 내장됨으로써, ’보안 정책의 중앙화’가 이루어진다. 이제 데이터는 데이터베이스에 저장되는 시점에 자동으로 암호화되고, 조회 시에는 특정 권한을 가진 데이터베이스 사용자에 의해서만 복호화될 수 있다.

이러한 접근 방식은 여러 가지 중요한 파급 효과를 낳는다. 첫째, 애플리케이션 개발자는 복잡하고 오류가 발생하기 쉬운 암호화 로직 구현에서 벗어나 핵심 비즈니스 로직에 더 집중할 수 있다. 둘째, 데이터베이스 백업 파일이나 물리적 디스크가 외부에 유출되더라도 민감한 정보는 암호화된 상태로 남아있어, 데이터 유출 사고 발생 시 피해를 최소화하는 심층 방어(Defense-in-Depth) 전략을 구현할 수 있다. 셋째, 데이터베이스의 뷰(View)나 함수를 이용하여 특정 사용자 역할(Role)에 따라서만 복호화된 데이터를 보여주도록 접근 제어를 더욱 세밀하게 구현하는 것이 가능해진다. 즉, pgcrypto는 PostgreSQL을 단순한 데이터 저장소가 아닌, 데이터의 생명주기 전반에 걸쳐 보안 정책을 능동적으로 강제하는 ’보안의 주체’로 격상시키는 역할을 한다.

4. 확장의 전략적 활용과 고려사항

4.1 확장 선택 및 도입 전략

PostgreSQL의 강력한 확장 생태계는 양날의 검이 될 수 있다. 올바르게 선택하고 사용하면 개발 생산성과 시스템 성능을 크게 향상시킬 수 있지만, 무분별한 도입은 오히려 시스템의 복잡성을 증가시키고 장기적인 유지보수 비용을 높이는 원인이 될 수 있다. 따라서 프로젝트에 필요한 확장을 도입할 때는 체계적인 평가 프레임워크를 통해 신중하게 접근해야 한다.

가장 먼저 수행해야 할 일은 요구사항을 명확히 분석하는 것이다. 해결하려는 문제가 무엇인지 구체적으로 정의하고, 해당 문제를 해결할 수 있는 여러 확장 후보를 식별해야 한다. 예를 들어, ’대소문자 구분 없는 이메일 중복 체크’가 요구사항이라면 citext 확장과 lower() 함수 기반의 표현식 인덱스 방식이 후보가 될 수 있다.

후보 확장을 식별한 후에는 다음과 같은 다각적인 평가 기준을 적용하여 최적의 선택을 해야 한다.

• 기능성 및 성숙도: 확장이 정의된 요구사항을 완벽하게 충족하는가? 전 세계적으로 널리 사용되어 충분히 검증되었는가? 알려진 버그나 한계점은 없는가?
• 커뮤니티 및 유지보수: 확장이 활발하게 유지보수되고 있는가? GitHub 저장소의 최근 커밋 기록, 이슈 트래커의 활동, 메일링 리스트의 논의 등을 통해 개발 커뮤니티의 건강 상태를 확인해야 한다. 새로운 PostgreSQL 버전에 대한 지원이 신속하게 이루어지는지는 장기적인 관점에서 매우 중요한 요소다 (1.2절에서 논의된 업그레이드 리스크와 직접적으로 연결된다).
• 성능 영향: 확장을 사용했을 때 발생할 수 있는 성능 오버헤드는 어느 정도인가? 특정 함수 호출이나 데이터 타입 사용이 CPU나 메모리 사용량에 미치는 영향을 벤치마킹을 통해 정량적으로 평가해야 한다.
• 보안: 확장에 알려진 보안 취약점(CVE)은 없는가? 코드가 공개되어 있고 신뢰할 수 있는 출처(예: PGXN, PostgreSQL 공식 배포판)에서 제공되었는가?
• 문서화: 학습과 문제 해결을 용이하게 할 만큼 문서가 상세하고 명확하게 작성되어 있는가? 예제 코드나 모범 사례가 충분히 제공되는지도 중요한 평가 항목이다.

이러한 평가 과정을 거쳐 확장을 선택하는 것은 단순히 기술적인 결정을 넘어, 프로젝트의 장기적인 안정성과 유지보수성을 담보하는 전략적인 선택이다.

4.2 확장 사용 시 주의점 및 모범 사례

확장을 성공적으로 도입하고 운영하기 위해서는 몇 가지 주의사항을 인지하고 모범 사례를 따르는 것이 중요하다.

버전 충돌 및 의존성 문제

여러 확장을 동시에 사용하거나, 특정 버전의 라이브러리에 의존하는 확장을 사용할 때 버전 충돌 문제가 발생할 수 있다. 예를 들어, 두 개의 다른 확장이 동일한 이름의 함수를 정의하려고 하거나, 서로 다른 버전의 공유 라이브러리를 요구하는 경우가 그렇다. 이러한 문제를 피하기 위해 확장을 도입하기 전에 의존성 관계를 명확히 파악하고, 테스트 환경에서 다른 확장들과의 호환성을 충분히 검증해야 한다.

업그레이드 복잡성

앞서 여러 차례 강조했듯이, 데이터베이스의 메이저 버전 업그레이드 시 확장 호환성 문제는 가장 큰 걸림돌 중 하나가 될 수 있다.9 PostgreSQL의 새로운 메이저 버전이 출시되더라도, 내가 사용하는 확장이 해당 버전을 즉시 지원하지 않을 수 있다. 이 경우, 데이터베이스 업그레이드가 지연되거나, 해당 확장을 대체할 다른 방법을 찾아야 하는 상황에 직면할 수 있다. 따라서 프로덕션 환경을 업그레이드하기 전에는 반드시 별도의 테스트 환경에서 모든 확장이 새로운 버전의 데이터베이스와 완벽하게 호환되는지 철저하게 검증하는 절차가 필수적이다.

성능 모니터링

새로운 확장을 도입한 후에는 시스템의 성능 변화를 지속적으로 모니터링해야 한다. pg_stat_statements와 같은 도구를 사용하여 특정 쿼리의 응답 시간이 느려지지는 않았는지, 전체적인 CPU 및 I/O 사용량이 비정상적으로 증가하지는 않았는지 등을 면밀히 관찰해야 한다. 예상치 못한 성능 저하가 발견될 경우, 해당 확장의 설정값을 조정하거나 사용 방식을 변경하는 등의 조치가 필요할 수 있다.

“적을수록 좋다 (Less is More)” 원칙

PostgreSQL의 풍부한 확장 생태계는 매력적이지만, 모든 유용한 확장을 무조건 도입하려는 유혹을 경계해야 한다. 모든 확장은 시스템의 복잡성을 증가시키고, 잠재적인 장애 지점을 추가하며, 관리해야 할 대상을 늘리는 비용을 수반한다. 따라서 “이 기능이 있으면 좋겠다“는 막연한 생각보다는, “이 확장이 없으면 해결할 수 없는 명확한 문제가 있는가?“라는 질문을 통해 도입의 필요성을 엄격하게 판단해야 한다. 꼭 필요한 핵심적인 확장에 집중하는 것이 장기적으로 더 안정적이고 관리하기 쉬운 시스템을 만드는 비결이다.

5. 결론: 지속적으로 진화하는 데이터베이스

PostgreSQL의 확장 아키텍처는 이 데이터베이스 시스템이 가진 가장 강력하고 독창적인 특징이다. 이는 PostgreSQL이 특정 기술 트렌드나 시대적 요구사항에 뒤처지지 않고, 전 세계 커뮤니티의 집단 지성을 통해 지속적으로 진화하고 적응할 수 있게 하는 핵심적인 메커니즘이다. 본 보고서에서 심층적으로 분석한 PostGIS, postgres_fdw, pg_stat_statements, pgcrypto 등의 사례는 확장이 어떻게 PostgreSQL의 본질적인 한계를 극복하고, 관계형 데이터베이스라는 전통적인 틀을 넘어 새로운 가치를 창출하는지를 명확하게 보여준다.

PostGIS는 PostgreSQL을 지리 공간 데이터 분석의 표준 플랫폼으로 만들었고, postgres_fdw는 데이터 사일로의 경계를 허물어 데이터 가상화 허브로서의 가능성을 열었다. pg_stat_statements는 데이터베이스에 대한 깊이 있는 관찰 가능성을 제공하여 과학적인 성능 관리를 가능하게 했으며, pgcrypto는 보안의 책임을 데이터 계층으로 가져와 더욱 견고한 데이터 보호 체계를 구축하게 했다.

결론적으로, 현대 PostgreSQL 환경에서 성공적인 시스템을 구축하고 운영하는 것은 단순히 코어 기능에 대한 깊이 있는 이해를 넘어, 강력하고 방대한 확장 생태계를 얼마나 현명하고 전략적으로 활용하는지에 달려있다. 확장은 PostgreSQL의 잠재력을 무한히 확장시키는 열쇠다. 그러나 그 열쇠를 올바르게 사용하기 위해서는 해결하려는 문제에 대한 명확한 정의, 후보 확장에 대한 체계적인 평가, 도입 후의 철저한 테스트와 지속적인 관리가 반드시 동반되어야 한다. 이러한 원칙이 지켜질 때, PostgreSQL과 그 확장 생태계는 어떤 복잡한 요구사항에도 대응할 수 있는 강력하고 유연한 데이터 플랫폼이 될 것이다.

6. Works cited

1. 제14장: 확장 기능과 고급 기능 활용(PostGIS 등) - TILNOTE, accessed October 30, 2025, https://tilnote.io/pages/68116b263c3f2fc7099cadb1
2. 확장 및 모듈 | Microsoft Learn, accessed October 30, 2025, https://learn.microsoft.com/ko-kr/azure/postgresql/extensions/concepts-extensions
3. DB 인사이드 | PostgreSQL Extension - Introduction - NOW엑셈, accessed October 30, 2025, https://blog.ex-em.com/1910
4. postgres_fdw 사용 - 사용 가이드, accessed October 30, 2025, https://guide.ncloud-docs.com/docs/clouddbforpostgresql-postgresqlfdw
5. PostgreSQL용 신뢰할 수 있는 언어 확장 작업 - Amazon Aurora, accessed October 30, 2025, https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/PostgreSQL_trusted_language_extension.html
6. Documentation: 18: CREATE EXTENSION - PostgreSQL, accessed October 30, 2025, https://www.postgresql.org/docs/current/sql-createextension.html
7. PostgreSQL 확장 관리 - IBM Cloud Docs, accessed October 30, 2025, https://cloud.ibm.com/docs/databases-for-postgresql?topic=databases-for-postgresql-extensions&locale=ko
8. [PostgreSQL] UUID 생성 실패, accessed October 30, 2025, https://bonarbo.tistory.com/26
9. PostgreSQL 확장 버전 업그레이드 - Amazon Aurora, accessed October 30, 2025, https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Upgrading.ExtensionUpgrades.html
10. PGXN - PostgreSQL wiki, accessed October 30, 2025, https://wiki.postgresql.org/wiki/PGXN
11. PGXN: PostgreSQL Extension Network, accessed October 30, 2025, https://pgxn.org/
12. pgxn/pgxn: PostgreSQL Extension Network - GitHub, accessed October 30, 2025, https://github.com/pgxn/pgxn
13. PGXN Client - VA.gov, accessed October 30, 2025, https://www.oit.va.gov/Services/TRM/ToolPage.aspx?tid=13790
14. pgxnclient - PyPI, accessed October 30, 2025, https://pypi.org/project/pgxnclient/
15. PostGIS 3.0.0 사용자 지침서, accessed October 30, 2025, https://postgis.net/docs/manual-3.0/postgis-ko_KR.html
16. Chapter 4. Data Management - PostGIS, accessed October 30, 2025, https://postgis.net/docs/manual-3.7/ko_KR/using_postgis_dbmanagement.html
17. [이길어때] 위치 정보 관리를 위한 PostGIS 적용기 - 코딩 석세스, accessed October 30, 2025, https://stonehee99.tistory.com/19
18. pg_stat_statements로 쿼리 성능 모니터링하기 Plain. Simple. Clear …, accessed October 30, 2025, https://seungho-jeong.github.io/technology/pg_stat_statements/
19. Amazon Aurora PostgreSQL의 쿼리 플랜 모니터링 | AWS 기술 블로그, accessed October 30, 2025, https://aws.amazon.com/ko/blogs/tech/monitor-query-plans-for-amazon-aurora-postgresql/
20. pg_buffercache - postgresql.kr, accessed October 30, 2025, https://postgresql.kr/docs/9.6/pgbuffercache.html
21. 캐시 사이즈 확인 방법 - velog, accessed October 30, 2025, https://velog.io/@tarzandb/%EC%BA%90%EC%8B%9C-%EC%82%AC%EC%9D%B4%EC%A6%88-%ED%99%95%EC%9D%B8-%EB%B0%A9%EB%B2%95
22. 확장 기능 - PostgreSQL - 카카오클라우드, accessed October 30, 2025, https://docs.kakaocloud.com/service/data-store/postgresql/how-to-guides/postgresql-extension
23. PostgreSQL 공식 확장 모듈 | ServBay 지원 센터, accessed October 30, 2025, https://support.servbay.com/ko/database-management/postgresql-extensions/official-extensions
24. PostgreSQL의 확장 기능 HStore - GIS Developer, accessed October 30, 2025, http://www.gisdeveloper.co.kr/?p=2082
25. The citext Extension - Neon Docs, accessed October 30, 2025, https://neon.com/docs/extensions/citext
26. Documentation: 18: F.9. citext — a case-insensitive character string type - PostgreSQL, accessed October 30, 2025, https://www.postgresql.org/docs/current/citext.html
27. Citext - Nile Documentation, accessed October 30, 2025, https://www.thenile.dev/docs/extensions/citext
28. [PostgreSQL]UUID - 모나드 - 티스토리, accessed October 30, 2025, https://starseeds.tistory.com/17
29. [OpenSQL] PostgreSQL의 Foreign Data Wrapper - 티맥스티베로 …, accessed October 30, 2025, https://tmaxtibero.blog/4280-2/
30. postgres_fdw로 마이그레이션 생산성 높이기 | 우아한형제들 기술블로그, accessed October 30, 2025, https://techblog.woowahan.com/20371/
31. postgres_fdw 및 dblink 확장을 사용하여 PostgreSQL를 통해 OCI 데이터베이스에서 데이터베이스 간 액세스 사용, accessed October 30, 2025, https://docs.oracle.com/ko/learn/ocipgfdw-dblink-extn/index.html
32. pgcrypto - PostgreSQL KR, accessed October 30, 2025, https://postgresql.kr/docs/9.6/pgcrypto.html
33. PostgreSQL - pgcrypto 모듈을 사용한 패스워드 및 문자열 암호화, accessed October 30, 2025, https://guiyomi.tistory.com/98
34. 가볍고 가장 빠른 암호화 알고리즘을 위한 BaroCRYPT 솔루션의 API 가이드(PostgreSQL), accessed October 30, 2025, https://mc529.tistory.com/1622
35. [Postgresql] 데이터 해시화, 암호화, 복호화 :: 불곰, accessed October 30, 2025, https://brownbears.tistory.com/545
36. pgcrypto 확장 모듈을 이용한 oracle DBMS_CRYPTO 패키지 이용하는 함수들 마이그레이션, accessed October 30, 2025, https://ktdsoss.tistory.com/476