OAuth 개발 뒷이야기

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

PostgreSQL 18은 새로운 OAuth 2.0 지원 프레임워크를 탑재했습니다. OAuth는 인터넷에서 오랫동안 널리 사용되어 온 오픈 인증 시스템입니다. 저는 2021년에 이 기능에 대한 첫 번째 개념 증명(proof-of-concept)을 게시했는데, 이제 이렇게 세상에 공개되니 설레면서도 긴장됩니다.

EDB의 Guang Yi Xu가 이미 이 기능에 대해 훌륭한 기술 글들을 작성했기 때문에, 여기서는 반복하지 않겠습니다. 대신, 이 코드를 개발한 동기와 과정에 대해 말씀드리고자 합니다.

왜 OAuth인가? 그리고 왜 지금인가?

Postgres의 기본 인증 방식인 SCRAM은 암호학적으로 매우 탄탄하며, 계속 개선이 이뤄지고 있고, 앞으로도 소수의 사용자나 머신 간 통신에는 훌륭한 선택지가 될 것입니다. 하지만 수백~수천 명의 사람을 관리해야 하는 대규모 시스템에서는 개별 (사용자, 클러스터) 쌍마다 비밀번호를 관리해야 하므로 확장성이 떨어집니다. 이럴 때는 “이 정보를 한 곳에만 관리할 수 있다면 좋겠다”라는 생각이 들 수밖에 없습니다.

Postgres가 현재 지원하는 서드파티 인증 방식들은 불만족스러운 점이 많습니다.

LDAP: 사실상 비밀번호를 평문으로 전달하는 수준
Kerberos: 보안성/감사성에 대한 불안, 플랫폼 간 상호운용성 문제, 시대에 뒤처진 아키텍처
TLS 클라이언트 인증서: 개인적으로 좋아하지만, 대부분의 사람들에게는 자체 CA 운영이 너무 번거롭다
(덤: RADIUS도 있긴 하지만, 실제 배포 사례를 본 적은 없습니다)

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

OAuth는 여러 면에서 이를 개선합니다.

사용자 인증 방식과 무관: Postgres는 패스워드, 키, MFA가 어떻게 구현됐는지 몰라도 됨
클라이언트와 사용자 분리: 프로그램에 데이터베이스 접근 권한을 줘도, 사용자의 다른 권한까지 위임되는 건 아님
OAuth 토큰의 특성: 유효기간이 있고 자체 기술(self-describing) 가능 → Postgres 내부의 validator가 중앙 서버에 매번 질의하지 않고 안전한 판단 가능

물론 “OAuth가 모든 문제를 해결했다”라고 말한다면 거짓말일 겁니다. OAuth 역시 규격과 구현 간의 미묘한 불일치가 많은 복잡한 시스템입니다. 하지만 수많은 사람들이 HTTPS와 공개키 암호 같은 개방형 기술 위에서 끊임없이 개선해 가고 있고, 이는 장기적으로 믿을 만한 투자라고 생각합니다.

함께한 사람들

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

특히:

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

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

4년 동안 어떻게 동기를 유지했는가?

사실 4년 내내 몰두한 건 아니었습니다. 6~9개월씩 쉬기도 하고, 다른 일을 하다가 다시 돌아오기도 했습니다. 이 과정에서 다른 사람들이 이 기능에 관심을 가지게 되었고, 그 관심이 다시 동기부여가 되었습니다.

마지막 단계(“무엇을 마무리하고, 무엇을 남길지” 결정)는 여전히 힘들었습니다. 하지만 커뮤니티 리뷰어들의 꾸준한 피드백이 저를 계속 앞으로 나아가게 했습니다.

왜 흥미로운가?

개발자: 사용자명을 기반으로 한 인증에서 벗어나, “무엇을 할 수 있는가”에 기반한 권한 시스템으로 전환할 수 있습니다. 더 확장성이 좋고, 익명 접근 같은 새로운 유즈케이스도 가능해집니다.
고객(DBA): LDAP 동기화 스크립트 같은 번거로운 인프라를 줄이고, 조직의 인증 체계를 Postgres와 쉽게 연동할 수 있습니다.
최종 사용자: 새로운 로그인 경험이 “흥미롭다”고 하긴 어렵지만, 기존 조직의 인증 도구를 그대로 사용하면서 더 편리하게 접근할 수 있습니다.