PostgreSQL sslnegotiation 기준 정리

본문 중간의 쿠팡 추천 상품 구매시 쿠팡 파트너스에서 일정액의 수수료를 제공받습니다.

PostgreSQL sslnegotiation 기준 정리

sslnegotiation은 libpq 클라이언트가 PostgreSQL 서버와 SSL을 어떤 방식으로 협상할지 정하는 연결 옵션이다. 2026년 7월 22일 기준 PostgreSQL 18 공식 문서에 따르면 값은 postgres와 direct 두 가지이며, 기본값은 postgres다. 이 옵션은 TLS 사용 여부를 결정하는 sslmode와는 역할이 다르고, SSL을 시작하는 절차를 어디서 시작할지 정하는 데 가깝다.

실무에서 이 값을 보는 이유는 두 가지다. 첫째, 서버가 direct SSL 연결을 확실히 지원하는 환경에서는 direct가 왕복 1회를 줄일 수 있다. 둘째, SSL 프록시나 네트워크 도구가 PostgreSQL 초기 핸드셰이크 대신 일반 TLS 시작을 기대하는지에 따라 연결 가능 여부가 달라질 수 있다.

sslnegotiation은 무엇을 바꾸나?

PostgreSQL 공식 문서 기준 postgres 모드는 먼저 서버에 SSL 지원 여부를 묻고, 그 다음 SSL 핸드셰이크를 시작한다. 반면 direct 모드는 TCP 연결이 성립하자마자 표준 SSL 핸드셰이크를 바로 시작한다. 즉 둘의 차이는 "TLS를 쓸지 말지"보다 "TLS 시작 절차를 PostgreSQL 프로토콜 앞에 둘지"에 있다.

값	동작	무난한 사용 상황
postgres	기존 PostgreSQL 방식으로 SSL 지원 여부를 먼저 협상	서버 구성 다양성이 있고 기본 호환성이 중요할 때
direct	TCP 연결 직후 바로 TLS 핸드셰이크 시작	서버가 direct SSL을 지원함이 확실하고 지연을 줄이고 싶을 때

기본값 postgres를 그대로 두는 편이 안전한 이유는 무엇일까?

공식 문서는 postgres 방식을 더 유연한 기본값으로 설명한다. 이유는 단순하다. 서버 구성이 제각각이거나, PostgreSQL 17 이전 서버가 섞여 있거나, 연결 중간에 PostgreSQL 특화 핸드셰이크를 전제로 하는 장비가 있으면 기존 방식이 더 넓게 동작할 가능성이 높다.

따라서 클라이언트와 서버를 모두 통제하지 못하는 환경에서는 성능상의 작은 이점보다 연결 호환성이 더 중요할 수 있다. 특히 라이브러리 기본값을 유지해야 하는 공용 애플리케이션, 다양한 고객 환경을 상대하는 제품, 서버 버전 혼재 기간에는 postgres가 무난하다.

언제 direct를 고려할까?

direct는 서버가 direct SSL 연결을 지원한다는 전제가 명확할 때 의미가 있다. PostgreSQL 공식 문서는 이 모드가 SSL 협상에 필요한 왕복을 하나 줄여 지연을 낮출 수 있고, 프로토콜 비의존형 SSL 네트워크 도구 사용에도 도움이 된다고 설명한다. 즉 프록시, 로드밸런서, 패킷 캡처 도구가 초기 연결부터 TLS로 보이길 기대하는 환경에서 검토할 수 있다.

host=db.example.com
dbname=app
sslmode=verify-full
sslnegotiation=direct

이 예시는 서버가 direct SSL 연결을 지원하고, 클라이언트도 평문 폴백 없이 TLS를 강제하겠다는 의도가 분명할 때 어울린다. 반대로 지원 여부가 불확실한 서버에 넓게 배포하는 기본 설정으로 두기에는 보수적인 검토가 필요하다.

 

 

왜 sslmode=require 이상이 함께 필요할까?

PostgreSQL 공식 문서는 direct가 sslmode=require 이상에서만 허용된다고 밝힌다. 이유는 더 약한 모드와 결합하면 서버가 direct SSL을 지원하지 않을 때 평문 인증으로 의도치 않게 내려갈 위험이 있기 때문이다. 그래서 sslnegotiation=direct는 사실상 "SSL을 반드시 써야 한다"는 정책과 함께 다니는 옵션으로 보는 편이 맞다.

이 기준은 운영 판단을 단순하게 만든다. TLS를 강제할 생각이 없다면 direct를 굳이 쓸 이유가 줄어든다. 반대로 TLS를 이미 필수로 두고 있고 인증서 검증까지 마친 환경이라면 direct의 전제 조건을 만족시키기 쉽다.

gssencmode와 함께 봐야 하는 이유는 무엇일까?

libpq 연결 문서는 GSSAPI 암호화가 가능하면 sslmode 값과 무관하게 SSL보다 GSS 암호화를 우선한다고 설명한다. 따라서 Kerberos 기반 GSSAPI 인프라가 있는 환경에서 "반드시 direct SSL 경로를 타야 한다"는 요구가 있다면 gssencmode=disable까지 함께 검토해야 한다. 그렇지 않으면 애초에 SSL 협상 단계로 가지 않을 수 있다.

함께 볼 항목	이유	관련 옵션
SSL 강제 여부	direct는 약한 SSL 정책과 함께 쓸 수 없음	sslmode
GSSAPI 사용 가능성	가능하면 SSL보다 GSS 암호화가 우선될 수 있음	gssencmode
SNI 기반 프록시 사용 여부	문서상 SSL 인지 프록시는 direct와 함께 볼 수 있음	sslsni, sslnegotiation

PGSSLNEGOTIATION 환경 변수는 언제 쓸까?

PostgreSQL 18 환경 변수 문서에는 PGSSLNEGOTIATION이 sslnegotiation 연결 옵션과 같은 의미라고 적혀 있다. 즉 애플리케이션 코드에서 연결 문자열을 바꾸지 못하더라도, 실행 환경에서 기본 협상 방식을 정할 수 있다.

export PGSSLMODE=verify-full
export PGSSLNEGOTIATION=direct

다만 환경 변수는 프로세스 단위 기본값일 뿐이다. 서로 다른 서버에 같은 프로세스가 접속하는 구조라면, direct SSL을 지원하지 않는 대상까지 한 번에 영향받을 수 있다. 이런 경우에는 전역 환경 변수보다 연결 문자열별 명시가 더 안전하다.

실무에서는 어떻게 고르는 편이 무난할까?

상황	무난한 선택	이유
서버 버전과 프록시 구성이 제각각인 환경	postgres	기본 호환성이 가장 넓기 때문
PostgreSQL 17 이상 direct SSL 지원 서버만 운영	direct	왕복 1회를 줄이고 TLS 시작을 단순화할 수 있기 때문
SNI 기반 SSL 프록시와 함께 사용	direct 검토	문서상 PostgreSQL 핸드셰이크를 이해하지 않는 프록시와의 조합에서 의미가 있기 때문

FAQ

Q. sslnegotiation=direct를 쓰면 항상 더 빠를까?

공식 문서 기준 direct SSL은 왕복 1회를 줄일 수 있다. 다만 체감 차이는 네트워크 지연, 연결 재사용 여부, 프록시 구조에 따라 달라지므로 모든 환경에서 큰 차이가 난다고 일반화할 수는 없다.

Q. PostgreSQL 17 이전 서버에도 direct를 써도 되나?

문서에는 direct SSL 옵션이 PostgreSQL 17에서 도입됐다고 적혀 있다. 따라서 이전 서버가 섞인 환경에서는 지원 여부를 먼저 확인하지 않으면 연결 실패나 정책 불일치가 생길 수 있다.

Q. sslnegotiation만 바꾸면 인증서 검증도 강화되나?

아니다. 이 옵션은 SSL 시작 절차를 정하는 값이다. 서버 인증서 검증 강도는 sslmode, sslrootcert 같은 옵션으로 따로 결정된다.

정리

sslnegotiation은 PostgreSQL libpq 연결에서 SSL을 어떤 순서로 시작할지 정하는 옵션이다. 2026년 7월 22일 기준 PostgreSQL 18 공식 문서만 놓고 보면, 대부분의 혼합 환경에서는 기본값 postgres가 무난하고, PostgreSQL 17 이상 direct SSL 지원 서버만 다루며 TLS 강제 정책이 명확한 환경에서는 direct를 검토할 수 있다.

선택 기준은 세 가지다. 첫째, 서버가 direct SSL을 지원하는지 확인한다. 둘째, sslmode=require 이상으로 TLS를 강제할지 본다. 셋째, GSSAPI 암호화가 SSL보다 우선될 수 있는 환경인지 점검한다. 이 세 조건이 맞으면 direct, 아니면 기본값 유지가 안전하다.

참고 자료

• PostgreSQL 18 공식 문서: libpq connection parameters
• PostgreSQL 18 공식 문서: libpq environment variables