Supabase가 연결 로그를 껐다: 조용해진 Postgres에서 관측성을 잃지 않는 법

개발

7월 9일 이후 Supabase의 Postgres 로그가 갑자기 조용해졌다면 장애가 아니라 기본값 변경일 수 있다. Supabase는 새 프로젝트와 기존 Free·Pro 프로젝트의 log_connections를 기본 off로 전환했다. 연결 한 번마다 쌓이던 이벤트를 줄이는 결정은 합리적이지만, 팀이 그 로그를 비공식 모니터링으로 쓰고 있었다면 ‘노이즈 제거’가 곧 ‘관측 공백’이 된다.

Supabase Postgres 연결 신호를 기본 지표, 선택적 연결 로그, 쿼리 통계와 감사 로그의 세 계층으로 분리한 관측성 다이어그램
연결 로그 하나로 모든 문제를 보려 하지 말고, 항상 켜둘 저비용 지표와 사건 때 켤 진단 로그, 규정용 감사 로그를 분리해야 한다.

무슨 일이 바뀌었나

Supabase는 2026년 6월 22일 변경을 공지했고 7월 9일부터 적용한다고 밝혔다. 7월 9일 이후 생성된 모든 신규 프로젝트는 log_connections=off가 기본이며, 기존 Free·Pro 프로젝트도 같은 값으로 이동한다. Teams·Enterprise와 HIPAA add-on 프로젝트는 기존 설정이 유지된다.

log_connections는 클라이언트가 접속하거나 인증을 마칠 때 연결 생명주기 메시지를 기록한다. PostgreSQL 문서는 일부 클라이언트가 암호 필요 여부를 확인하려고 두 번 연결할 수 있으므로 중복된 ‘connection received’가 반드시 장애를 뜻하지는 않는다고 경고한다. Supabase가 밝힌 변경 이유도 로그 볼륨과 노이즈 감소다.

필요하면 Dashboard의 Database Settings 또는 Management API로 다시 켤 수 있다. Supabase 문서상 log_connections와 log_disconnections는 Management API 전용 설정이며 일반 CLI 설정 목록과 구분된다. 설정을 자동화할 때는 UI 클릭 절차를 문서화하는 데서 끝내지 말고, 원하는 값과 실제 pg_settings 값을 함께 검증해야 한다.

왜 실무 팀에게 중요한가

연결 로그는 값이 싸고 눈에 잘 띄어서 여러 목적에 잘못 재사용되기 쉽다. 배포 직후 연결 폭주, 잘못된 비밀번호를 가진 오래된 worker, 지역별 pooler 오설정, 서버리스 함수의 connection churn을 대략 찾는 데 유용하다. 하지만 이벤트 수 자체는 사용자 영향, 쿼리 지연, pool 포화, 인증 실패율을 직접 설명하지 않는다.

기본값 변경은 관측성 계약을 다시 쓰라는 신호다. 서비스 수준 경보는 연결 이벤트 줄 수가 아니라 API 오류율, 데이터베이스 연결 사용량, 대기 시간, lock wait, slow query와 pool 상태를 기준으로 삼아야 한다. 연결 로그는 원인 분석용 보조 증거로 내려놓는 편이 낫다.

반대로 감사나 사고 대응에서 누가 언제 접속했는지가 필수라면 단순히 기본값을 따를 수 없다. 규정·위협 모델·보존 기간을 근거로 연결과 종료 로그를 켜고, 쿼리 행위가 필요하면 별도의 pgAudit 범위를 설계해야 한다. 연결 기록과 데이터 변경 감사는 같은 문제가 아니다.

관측성 스택을 세 층으로 나눠라

첫 번째 층은 항상 켜둘 저비용 신호다. API의 latency와 error rate, Postgres connection utilization, pool saturation, lock과 transaction 상태, pg_stat_statements의 호출 수·총 시간·평균 시간을 수집한다. 이 층은 ‘사용자가 영향을 받는가’를 빠르게 알려야 한다.

두 번째 층은 사건 때 좁게 켜는 진단 신호다. 연결 누수나 인증 루프가 의심되면 log_connections와 필요시 log_disconnections를 일정 시간 활성화하고, 시작 시각·담당자·종료 조건을 기록한다. 고정적으로 켜두는 대신 시간 제한이 있는 debug mode로 운영하면 노이즈와 비용을 제어할 수 있다.

세 번째 층은 목적이 명확한 감사 신호다. Supabase는 query logging에 pgAudit를 안내하며, 너무 넓은 범위는 Postgres 로그에 많은 노이즈를 만든다고 설명한다. DDL·write·function 등 필요한 class만 role 단위로 설정하고, 민감한 쿼리 본문과 개인정보가 로그 저장소로 복제되는 위험도 검토해야 한다.

커뮤니티 신호: 노이즈와 공백은 동시에 문제다

Supabase 커뮤니티에는 내부 health check나 로컬 서비스가 만든 반복 메시지를 실제 장애로 오해하거나, 반대로 필요한 호출이 보이지 않아 원인을 찾기 어렵다는 질문이 반복된다. 최근 논의에서도 내부 프로세스 메시지가 로그를 채우지만 서비스 영향은 없는 상황이 공유됐다.

이런 게시물은 제품 동작을 증명하는 출처가 아니다. 다만 운영자가 원하는 것은 ‘더 많은 로그’가 아니라 어떤 메시지가 사용자 영향과 연결되는지 알려주는 분류 체계라는 점을 보여준다. 실제 기본값·설정 방식·제한은 Supabase와 PostgreSQL 공식 문서를 기준으로 판단해야 한다.

오늘 적용할 운영 체크리스트

1. 모든 production·staging 프로젝트에서 show log_connections;와 show log_disconnections;를 기록하고 기대값과 비교한다.

2. 기존 대시보드와 경보가 connection log event 문자열이나 건수에 의존하는지 검색한다. 의존한다면 metric 또는 pooler 신호로 교체한다.

3. API latency·error, connection utilization, pool saturation, lock wait, slow query를 최소 golden signal로 정하고 소유자와 경보 임계값을 둔다.

4. 연결 진단 로그를 켜는 runbook에 시작 조건, Management API 권한, 예상 로그량, 종료 시각, 원복 검증을 포함한다.

5. 감사 요구가 있다면 연결·종료 로그와 pgAudit을 분리해서 설계하고 보존 기간, 접근 권한, 민감정보 노출을 검토한다.

6. 서버리스·Edge Function·background worker가 매 요청 새 연결을 만드는지 pooler와 application name 기준으로 확인한다.

7. 변경 전후 같은 트래픽 창을 비교하되 로그 건수 감소를 성능 개선으로 오해하지 않는다. 사용자 지표와 데이터베이스 지표를 함께 본다.

8. 설정을 다시 켰다면 Dashboard 표시만 믿지 말고 실제 값, 로그 도착, 경보 동작, 종료 후 원복까지 게임데이로 검증한다.

리스크와 반론

‘로그가 적으면 장애 분석이 어려워진다’는 반론은 맞다. 그래서 무조건 끄기가 아니라 계층화가 필요하다. 다만 연결 이벤트를 영구 보관해도 쿼리 지연의 원인이나 pool wait을 자동으로 설명해 주지는 않는다. 목적별 지표를 먼저 갖춘 뒤 사건 범위를 좁히는 로그를 더해야 한다.

‘비용 때문에 관측성을 줄이는 것 아니냐’는 우려도 가능하다. Supabase는 변경 이유로 볼륨과 노이즈 감소를 들었지만, 팀의 감사·보안 요구까지 대신 판단하지 않는다. Free·Pro라는 요금제 분류보다 실제 데이터 민감도와 위협 모델이 재활성화 여부를 결정해야 한다.

마지막 위험은 설정 드리프트다. 콘솔에서 한 번 켠 값은 코드 리뷰와 변경 기록에서 빠질 수 있다. Management API를 사용하는 조직이라면 desired state, 승인, 사후 검증을 남기고, API token에는 필요한 database_config_write 권한만 부여해야 한다.

Supabase 연결 관측성 전환 체크포인트

✓모든 production·staging 프로젝트에서 show log_connections;와 show log_disconnections;를 기록하고 기대값과 비교한다.

✓기존 대시보드와 경보가 connection log event 문자열이나 건수에 의존하는지 검색한다. 의존한다면 metric 또는 pooler 신호로 교체한다.

✓API latency·error, connection utilization, pool saturation, lock wait, slow query를 최소 golden signal로 정하고 소유자와 경보 임계값을 둔다.

✓연결 진단 로그를 켜는 runbook에 시작 조건, Management API 권한, 예상 로그량, 종료 시각, 원복 검증을 포함한다.

✓감사 요구가 있다면 연결·종료 로그와 pgAudit을 분리해서 설계하고 보존 기간, 접근 권한, 민감정보 노출을 검토한다.

✓서버리스·Edge Function·background worker가 매 요청 새 연결을 만드는지 pooler와 application name 기준으로 확인한다.

✓변경 전후 같은 트래픽 창을 비교하되 로그 건수 감소를 성능 개선으로 오해하지 않는다. 사용자 지표와 데이터베이스 지표를 함께 본다.

✓설정을 다시 켰다면 Dashboard 표시만 믿지 말고 실제 값, 로그 도착, 경보 동작, 종료 후 원복까지 게임데이로 검증한다.

정리

이번 변경의 핵심은 로그 한 줄이 사라진 것이 아니라, 관측성의 책임이 기본값에서 팀의 명시적 운영 계약으로 이동했다는 점이다. 평상시에는 지표로 사용자 영향을 보고, 사건 때 연결 로그를 좁게 켜고, 감사는 별도 정책으로 다뤄야 조용한 로그와 빠른 진단을 함께 얻을 수 있다.

출처

다른 글