Postgres의 30년 구조와 앞으로 바뀔 부분은 무엇인가

Postgres는 연결마다 운영체제 프로세스를 하나씩 만들고, 장애 복구에는 기록을 먼저 남기는 방식을 택했다. 핵심 개발자 톰 레인은 커미터로 25년을 보낸 시점에 이 구조와 프로젝트의 향후 과제를 설명했다.

Snowflake의 엘리자베스 개럿 크리스텐슨(Elizabeth Garrett Christensen)이 진행한 인터뷰다. Postgres의 설계 배경과 앞으로 논의할 변화를 살펴보려는 데이터베이스 운영자와 개발자에게 참고가 될 만하다.

Postgres의 구조는 어떻게 작동하나?

Postgres를 여러 작업자가 각자 맡은 공간에서 일하는 작업장에 빗대면 이해하기 쉽다. 각 연결은 별도 프로세스에서 처리되고, 데이터 변경은 먼저 기록에 남긴 뒤 데이터 페이지에 반영된다. 여러 버전의 행을 함께 보관해 읽기와 쓰기가 서로를 막지 않도록 한다.

연결마다 프로세스를 두는 이유는 무엇인가?

Postgres는 MySQL이나 SQL Server의 스레드 방식과 달리, 클라이언트 연결마다 격리된 운영체제 프로세스를 만든다. 코드가 단순해지고 한 세션의 장애가 다른 세션의 메모리를 훼손할 위험이 줄어든다. 세션이 충돌하면 postmaster 프로세스가 자식 프로세스를 종료하고 공유 메모리를 안전하게 다시 초기화한다.

1990년대에는 표준화되지 않은 스레드 구현을 피할 수 있어 새 기여자가 코드에 참여하기 쉬웠다. 다만 프로세스마다 시스템 카탈로그 캐시와 개인 메모리 맵이 필요하다. 연결이 많아지면 CPU가 프로세스 사이를 전환하는 부담이 커져, PgBouncer 같은 연결 풀러를 이용하는 생태계가 형성됐다.

장애 복구와 동시 읽기는 어떻게 처리하나?

Postgres는 버클리 캘리포니아대에서 처음 공개됐을 때 쓰기 전 로그(WAL)가 없었다. 장애가 나면 백업에서 복구해야 하는 경우가 많았다. WAL 도입은 Postgres 8.0에 이르러 정착했고, 학술 프로젝트를 실무용 데이터베이스로 전환하는 데 중요한 역할을 했다.

WAL은 데이터 페이지를 갱신하기 전에 변경 내용을 하나의 순차 기록에 쓴다. 기록이 디스크에 도달하면 트랜잭션이 커밋되고, 데이터 페이지의 무작위 동기화는 백그라운드 체크포인트로 미룬다. 장애 뒤 WAL을 재생하는 복구 과정은 단순성과 안전성을 위해 의도적으로 단일 프로세스에서 수행한다.

Postgres는 기존 행을 덮어쓰거나 실행 취소 로그를 이용하는 대신, 트랜잭션 정보를 담은 새 행 버전을 추가한다. 이 다중 버전 동시성 제어(MVCC) 덕분에 읽는 작업이 쓰는 작업을 막지 않고, 쓰는 작업도 읽는 작업을 막지 않는다. 더 이상 필요하지 않은 행 버전은 VACUUM과 자동 VACUUM이 백그라운드에서 정리한다. 트랜잭션의 중단이나 커밋을 기다리며 정리할 필요가 없다.

메모리와 확장 기능은 어떻게 다루나?

Postgres는 일반적인 C 메모리 할당·해제 함수인 malloc과 free 대신, 수명에 따라 이름 붙인 메모리 컨텍스트를 트리 형태로 관리한다. 컨텍스트는 세션·쿼리·행 수준에 맞춰 구성된다. 쿼리나 트랜잭션이 끝나면 해당 메모리 컨텍스트 트리를 한꺼번에 해제할 수 있어 개별 free() 호출을 줄이고 메모리 누수를 막는다. 원문은 이 방식이 150만 줄 규모의 C 코드에서 메모리 관리를 안정적으로 만든다고 설명한다.

확장성은 버클리 시절부터 Postgres의 설계 조건이었다. 사용자 정의 자료형이나 새 인덱스 접근 방식을 지원하지 못하는 핵심 기능 제안은 일반화될 때까지 공동체가 받아들이지 않는다는 원칙이 있다. 이를 통해 핵심 엔진을 비대하게 만들지 않으면서 확장 기능을 지원해 왔다. 핵심 구문 분석기는 Flex와 Bison으로 만들었으며, 문법의 정확성을 지키기 위해 의도적으로 정적인 구조를 유지한다.

확장 기능으로는 구체화된 뷰를 기초 테이블 변경 직후 갱신하는 PostgreSQL 14용 pg_ivm, SQLite 데이터베이스를 Postgres로 가져오는 파이썬 모듈·명령줄 도구 pgsqlite, 비동기 쿼리를 실행하는 pg_later, 열 기반 테이블을 추가하는 Hydra, 벡터 저장소 기능을 제공하는 pg_vector가 소개됐다. 관련 사례는 PostgreSQL에 내장된 Elasticsearch 검색 기능, pg_ivm 소개, pgsqlite 소개, pg_later 소개, Hydra 소개, PostgreSQL을 벡터 저장소로 바꾸는 확장 기능에서 볼 수 있다.

앞으로 무엇이 달라질 수 있나?

Postgres는 관대한 BSD·MIT 계열 라이선스를 사용한다. 상용 업체와 클라우드 제공업체는 이를 바탕으로 독점 파생 제품을 만들 수 있고, 공동체 코드베이스와의 관계도 유지할 수 있다. 프로젝트에는 공식 법인이나 기업 주도 운영위원회가 없다. 변경은 이메일 토론과 합의를 거치며, 데이터 신뢰성과 안정성을 우선해 신중하게 진행된다.

레인은 공식 로드맵이나 운영위원회가 없고 개발이 분산돼 있어 빠른 출시나 유행 추종보다 안정성을 중시한다고 설명했다. 현재 논의되거나 진행 중인 변화는 다음과 같다.

• 스레드 방식 전환: 고성능 코어가 많은 하드웨어에서 프로세스 전환 부담을 줄이기 위한 연구가 진행 중이다. 스레드와 세션이 시스템 카탈로그 캐시를 공유하면서 데이터 손상을 막는 방법을 해결해야 한다.
• 열 기반 테이블: 기존 행 기반 테이블과 함께 열 기반 저장 방식을 지원하자는 관심이 이어지고 있다. 이를 위해 확장 기능이나 핵심 기능이 열 지향 형식을 지원하도록 테이블 접근 방식(TAM) API를 확장해야 한다.
• 병렬 장애 복구: 현재 단일 프로세스가 수행하는 WAL 재생을 향후 병렬화할 가능성이 있다.
• 확장 가능한 SQL 구문 분석기: 현재 정적인 Flex·Bison 테이블 때문에 확장 기능은 새 SQL 문법을 추가할 수 없다. Bison의 정확성과 모호성 보장에 맞먹는 도구가 나온다면 구문 분석기를 확장 가능하게 만드는 데 열려 있다는 것이 레인의 입장이다.
• VACUUM 개선: 자동 VACUUM의 휴리스틱을 개선하고 유지보수 작업을 병렬화하는 개발이 이어지고 있다. 원문은 Postgres 19의 병렬 VACUUM을 사례로 든다.

레인은 핵심 엔진을 가볍게 유지하고, 확장 기능으로 잘 구현할 수 있는 기능은 핵심에 넣지 않는 편을 선호한다. AI 보조 코드에 관한 공식 정책도 공동체가 마련하고 있다. 현재 합의는 모든 패치에 인간 커미터가 책임을 지고 각 설계 결정을 설명할 수 있어야 한다는 것이다. AI가 생성한 버그·보안 신고도 급증했으며, 그중 일부는 유효하지만 다수는 구조에 대한 이해가 부족해 공동체가 걸러내는 방법을 논의하고 있다. 레인은 계속 관심과 기여 역량을 유지하는 한 가까운 미래에도 핵심 개발을 이어갈 계획이다.

인터뷰 전문은 Snowflake의 ‘Postgres 30년을 만든 아키텍처 결정’과 톰 레인과 나눈 Postgres 30주년 대화에서 확인할 수 있다. 관련 역사 소개는 Postgres가 남긴 지속적인 영향에 있다. 다만 인터뷰와 원문은 스레드 전환이나 병렬 복구 등의 구체적인 도입 시점과 확정된 일정을 밝히지 않는다.