PostgreSQL 18 OAuth 2.0 지원: 개발 배경과 인증의 미래

작성자: Jacob Champion | 2025년 9월 25일

PostgreSQL 18에는 중앙화된 인증 체계와 PostgreSQL을 연동할 수 있는 새로운 OAuth 2.0 지원 프레임워크가 도입됐습니다. OAuth는 인터넷에서 오랫동안 활용되어 온 개방형 인증 표준입니다. 이 글에서는 PostgreSQL 18 OAuth 기능의 사용법보다, 2021년 첫 개념 증명(Proof of Concept, PoC)에서 정식 공개까지 이어진 개발 동기와 과정을 중심으로 살펴봅니다.

EDB의 Guang Yi Xu가 이미 이 기능의 기술적인 내용을 자세히 소개했으므로, 여기서는 PostgreSQL에 OAuth가 필요했던 이유와 커뮤니티의 협업 과정, 개발자와 DBA에게 주는 의미, 앞으로의 개선 과제를 설명합니다.

PostgreSQL 18에 OAuth 인증이 필요한 이유

PostgreSQL의 기본 인증 방식인 SCRAM은 암호학적으로 매우 견고합니다. 지속적으로 개선되고 있으며, 앞으로도 소수의 사용자나 머신 간 통신에는 훌륭한 선택지가 될 것입니다. 하지만 수백~수천 명의 사용자를 관리해야 하는 대규모 시스템에서는 개별 (사용자, 클러스터) 쌍마다 비밀번호를 관리해야 하므로 확장성이 떨어집니다. 이 경우 인증 정보를 한곳에서 관리할 필요성이 커집니다.

PostgreSQL이 현재 지원하는 서드파티 인증 방식에는 다음과 같은 한계가 있습니다.

• LDAP: 사실상 비밀번호를 평문으로 전달하는 수준
• Kerberos: 보안성과 감사 가능성에 대한 우려, 플랫폼 간 상호운용성 문제, 오래된 아키텍처
• TLS 클라이언트 인증서: 유용하지만, 대부분의 사용자에게 자체 인증 기관(Certificate Authority, CA) 운영은 부담이 큼
• RADIUS: 지원되지만, 저자가 실제 배포 사례를 접한 적은 없음

제가 OAuth 패치 작업을 시작했을 당시에는 LDAP 기반 배포의 지원 문제에 지쳐 있었습니다. PostgreSQL 역할과 디렉터리를 동기화하는 스크립트가 지나치게 자주 실행되면서 LDAP 서버 자체가 중단되는 상황까지 발생했습니다. 저는 이런 아키텍처를 없애고 싶었습니다.

OAuth가 기존 인증 운영을 개선하는 방식

OAuth는 여러 측면에서 기존 방식의 한계를 개선합니다.

• 사용자 인증 방식과 분리: PostgreSQL은 비밀번호, 키, 다중 인증(MFA)이 어떻게 구현됐는지 알 필요가 없습니다.
• 클라이언트와 사용자 분리: 프로그램에 데이터베이스 접근 권한을 부여하더라도 사용자의 다른 권한까지 함께 위임할 필요가 없습니다.
• OAuth 토큰의 특성: 토큰에는 유효기간이 있으며 자체 기술(self-describing)이 가능하므로, PostgreSQL 내부의 검증기(validator)가 매번 중앙 서버에 질의하지 않고 안전하게 판단할 수 있습니다.

물론 OAuth가 모든 문제를 해결하는 것은 아닙니다. OAuth 역시 규격과 구현 사이에 미묘한 불일치가 많은 복잡한 시스템입니다. 하지만 많은 사람이 HTTPS와 공개키 암호 같은 개방형 기술을 기반으로 계속 개선하고 있어, 장기적으로 투자할 가치가 있다고 생각합니다.

PostgreSQL OAuth 개발에 참여한 사람들

이 기능은 제가 혼자 만든 것이 아닙니다. 4년 넘게 작업하는 동안 수십 명의 PostgreSQL 커뮤니티 리뷰어가 코드, 아키텍처, 보안, 사용성 측면에서 도움을 주었습니다.

주요 기여자는 다음과 같습니다.

• Peter Eisentraut: 전체 전략과 패치 구조에 큰 도움 제공
• Daniel Gustafsson, Thomas Munro(Microsoft): 서버 API, BSD 지원, 문서 등 구현에 기여
• Daniel Gustafsson: 최종 커밋 담당
• EDB의 Kashif Zeeshan: 대규모 사용자 테스트를 수행해 아키텍처의 심각한 사용성 결함을 사전에 발견

모든 분께 진심으로 감사드립니다.

4년간 PostgreSQL OAuth 개발을 이어온 동력

사실 4년 내내 이 작업에만 몰두한 것은 아닙니다. 6~9개월씩 쉬거나 다른 일을 하다가 다시 돌아오기도 했습니다. 그 과정에서 다른 사람들이 이 기능에 관심을 보였고, 그 관심이 다시 동기부여가 됐습니다.

마지막 단계에서 무엇을 마무리하고 무엇을 향후 과제로 남길지 결정하는 일은 여전히 어려웠습니다. 하지만 커뮤니티 리뷰어들의 꾸준한 피드백 덕분에 계속 앞으로 나아갈 수 있었습니다.

PostgreSQL 18 OAuth가 개발자와 DBA에게 주는 의미

• 개발자: 사용자명을 기반으로 한 인증에서 벗어나 ‘무엇을 할 수 있는가’에 기반한 권한 시스템으로 전환할 수 있습니다. 확장성을 높이고 익명 접근과 같은 새로운 사용 사례도 구현할 수 있습니다.
• 고객(DBA): LDAP 동기화 스크립트와 같은 번거로운 인프라를 줄이고, 조직의 인증 체계를 PostgreSQL과 더 쉽게 연동할 수 있습니다.
• 최종 사용자: 기존 조직의 인증 도구를 그대로 사용하면서 데이터베이스에 더 편리하게 접근할 수 있습니다.

PostgreSQL OAuth의 향후 개선 과제

PostgreSQL 18의 OAuth는 시작일 뿐입니다. 앞으로 필요한 기능은 다음과 같습니다.

1. 플로우 전환 지원: 현재는 커스텀 코드 없이는 다른 유틸리티에 새로운 플로우를 적용할 수 없음
2. 안전한 토큰 캐싱: 연결할 때마다 인증을 반복하지 않도록 기본 캐싱 메커니즘 필요
3. 머신 간 플로우: 현재는 인간 사용자를 중심으로 하므로 자동화 스크립트와 서비스용 내장 플로우 필요
4. 클라이언트 바인딩 토큰: 토큰 유출 시 악용을 방지하기 위한 규격 반영 필요
5. 내장 검증기(validator) 제공: 널리 사용되는 OAuth 제공자 사이의 토큰 규칙 합의가 선행돼야 구현 가능

이 기능은 사용자 피드백을 바탕으로 계속 발전할 것입니다. 실제 환경에서 얻은 경험과 제안은 PostgreSQL 19 이후의 개선에 큰 도움이 될 것입니다.

메일: salesinquiry@enterprisedb.com