PostgreSQL channel_binding 기준 정리

PostgreSQL channel_binding 기준 정리

channel_binding은 libpq 클라이언트가 SCRAM 인증 과정에서 채널 바인딩을 어떻게 사용할지 정하는 연결 옵션이다. 2026년 7월 19일 기준 PostgreSQL 18 공식 문서에 따르면 값은 disable, prefer, require 세 가지이며, SSL 지원으로 빌드된 PostgreSQL에서는 기본값이 prefer다. 다중 환경에서 이 옵션을 보는 이유는 단순히 로그인 성공 여부보다, SCRAM 인증이 서버 인증 정보와 함께 묶여야 하는지까지 연결 정책으로 정할 수 있기 때문이다.

핵심은 이 옵션이 모든 인증 방식에 적용되는 보안 스위치가 아니라는 점이다. PostgreSQL 공식 문서 기준 채널 바인딩은 SSL 연결 위에서 PostgreSQL 11 이상 서버가 SCRAM 인증을 사용할 때만 지원된다. 따라서 비밀번호 인증을 쓰더라도 MD5 인증이거나, SSL이 없거나, 서버가 SCRAM 채널 바인딩을 제공하지 않는 환경이면 기대한 동작이 나오지 않을 수 있다.

channel_binding은 무엇을 바꾸나?

PostgreSQL의 SASL 인증 문서는 채널 바인딩이 없는 SCRAM과, 채널 바인딩을 포함하는 SCRAM-SHA-256-PLUS를 구분한다. 채널 바인딩을 쓰면 클라이언트가 서버 인증서와 연결된 정보를 인증 교환에 섞기 때문에, 중간자가 서버의 난수만 전달해서 인증을 통과시키는 공격을 막는 데 도움이 된다.

값	의미	무난한 사용 상황
disable	채널 바인딩을 사용하지 않음	레거시 호환성 확인이 우선일 때
prefer	가능하면 사용하고, 불가능하면 없이 진행	혼합 환경에서 기본값으로 두기 무난할 때
require	채널 바인딩이 반드시 성립해야 연결 허용	SCRAM over SSL을 강제할 수 있는 환경

공식 문서 그대로 보면 prefer는 "되면 쓰고 안 되면 포기"이고, require는 "안 되면 연결 실패"다. 따라서 운영 환경이 모두 PostgreSQL 11 이상이고 SSL과 SCRAM 정책이 정리되어 있다면 require를 검토할 수 있지만, 구버전 서버나 프록시가 섞여 있다면 먼저 호환성 점검이 필요하다.

언제 require를 고려할까?

require는 보안 기준을 명확하게 강제하고 싶을 때 의미가 있다. PostgreSQL 공식 문서에는 클라이언트가 더 나은 보안을 위해 채널 바인딩 변형을 선택하는 편이 좋다고 설명되어 있다. 즉 이미 SSL 연결과 SCRAM 인증을 표준으로 쓰고 있고, 일부 연결이 채널 바인딩 없이 성공하는 것을 허용하고 싶지 않다면 require가 정책 표현에 더 가깝다.

host=db.example.com
dbname=app
sslmode=require
channel_binding=require

이 예시는 "SSL은 반드시 써야 하고, SCRAM이라면 채널 바인딩도 빠지면 안 된다"는 의도를 연결 문자열에 드러낸다. 다만 이 설정은 서버가 SCRAM 채널 바인딩을 제공하지 않으면 접속이 실패하므로, 장애 대응용 임시 클라이언트나 오래된 드라이버가 남아 있는 환경에서는 신중해야 한다.

prefer가 기본값인 이유는 무엇일까?

prefer는 보안 향상과 호환성 사이의 타협점이다. PostgreSQL 18 libpq 문서는 SSL 지원으로 빌드된 경우 기본값이 prefer라고 밝힌다. 즉 채널 바인딩이 가능한 서버에서는 더 안전한 경로를 자동으로 택하고, 불가능한 서버에서는 연결 자체를 막지 않는다.

여러 서버나 관리 주체가 섞인 환경에서는 이 기본값이 실용적이다. 예를 들어 일부 서버는 아직 SCRAM 채널 바인딩을 제공하지 않지만, 최신 서버들은 지원하는 상태라면 클라이언트가 별도 분기 없이 가능한 곳에서는 SCRAM-SHA-256-PLUS를 고를 수 있다.

disable는 언제 필요할까?

disable는 보통 권장 기본값이라기보다 호환성 진단용에 가깝다. 공식 문서상 이 값은 채널 바인딩 사용을 막는다. 따라서 특정 프록시, TLS 종료 장비, 오래된 클라이언트 조합에서 채널 바인딩 협상 문제를 분리해서 보고 싶을 때 선택할 수 있다.

다만 장기 운영 설정으로 계속 두면, 채널 바인딩이 가능한 환경에서도 그 이점을 스스로 포기하게 된다. 그래서 문제 재현이나 전환 기간이 아니라면 disable를 상시 기본값으로 두는 판단은 보수적으로 해야 한다.

이 옵션만 보면 충분할까?

그렇지는 않다. 채널 바인딩은 PostgreSQL 문서 기준 SSL 연결과 SCRAM 인증이라는 전제가 맞아야 의미가 생긴다. 따라서 연결 정책을 점검할 때는 최소한 다음 세 가지를 함께 확인하는 편이 안전하다.

확인 항목	왜 필요한가	함께 볼 옵션
SSL 사용 여부	채널 바인딩은 SSL 연결에서만 지원됨	sslmode
인증 방식	문서상 SCRAM 인증일 때만 채널 바인딩 사용 가능	서버의 SCRAM 설정
서버/클라이언트 버전 및 빌드	서버는 PostgreSQL 11 이상이어야 하고, libpq는 SSL 지원 빌드여야 기본 동작이 달라짐	서버 버전, libpq 빌드 옵션

즉 channel_binding=require만 추가한다고 전체 연결 보안 정책이 완성되는 것은 아니다. 이 옵션은 "SCRAM over SSL 경로에서 채널 바인딩을 강제할지"를 정하는 세부 정책으로 보는 편이 정확하다.

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

상황	무난한 선택	이유
최신 PostgreSQL과 SCRAM, SSL을 표준으로 운영	require	보안 기준을 연결 실패로까지 명확히 강제할 수 있기 때문
지원 여부가 섞인 과도기 환경	prefer	가능한 곳에서는 채널 바인딩을 쓰고, 불가능한 곳도 우선 연결할 수 있기 때문
원인 분리나 레거시 호환성 진단이 우선	disable	채널 바인딩 협상 자체를 제외하고 문제를 좁힐 수 있기 때문

FAQ

Q. channel_binding=require면 모든 PostgreSQL 인증이 더 안전해지나?

그렇게 볼 수는 없다. PostgreSQL 공식 문서 기준 이 옵션은 SSL 연결에서 SCRAM 인증을 사용할 때의 채널 바인딩 정책이다. 다른 인증 방식에는 같은 방식으로 적용되지 않는다.

Q. 서버가 PostgreSQL 11 미만이면 어떻게 되나?

libpq 문서에는 채널 바인딩이 PostgreSQL 11 이상 서버에서 지원된다고 적혀 있다. 따라서 require를 쓰면 이런 서버와는 기대한 정책이 성립하지 않아 연결 실패 가능성을 먼저 봐야 한다.

Q. 기본값을 굳이 바꿔야 하나?

혼합 환경에서는 기본값 prefer도 충분히 실용적이다. 다만 조직 정책이 이미 "SCRAM over SSL을 강제한다" 쪽으로 정리되어 있다면 require가 의도를 더 분명하게 드러낸다.

정리

channel_binding은 PostgreSQL 연결에서 SCRAM 인증을 SSL 채널 정보와 묶어 쓸지 정하는 libpq 옵션이다. 2026년 7월 19일 기준 PostgreSQL 18 공식 문서만 놓고 보면, 최신 표준 환경에는 require, 지원 여부가 섞인 환경에는 prefer, 호환성 점검에는 disable가 가장 이해하기 쉽다.

선택 기준은 단순하다. 첫째, 서버와 클라이언트가 PostgreSQL 11 이상 SCRAM over SSL 구성을 만족하는지 본다. 둘째, 채널 바인딩이 빠진 연결을 허용할지 정책으로 정한다. 셋째, 전환 중이라면 기본값 prefer로 시작하고, 환경이 정리된 뒤 require로 올리는 방식이 현실적이다.

참고 자료

• PostgreSQL 18 공식 문서: libpq connection parameters
• PostgreSQL 18 공식 문서: SASL Authentication