그 고집불통 PostgreSQL이 드디어 '쿼리 힌트'를 받아들인다고?

20년 묵은 논쟁이 움직이기 시작했다

PostgreSQL 커뮤니티에서 오랫동안 '절대 안 돼'라고 못 박아온 기능이 하나 있어요. 바로 '쿼리 힌트(query hint)'예요. 그런데 다가오는 Postgres 19를 두고 이 힌트 기능을 다시 진지하게 논의하는 분위기가 만들어지고 있어요. 오라클이나 MySQL 쓰다가 Postgres로 넘어온 분들이 "어? 왜 힌트가 없지?" 하고 당황했던 그 부분이거든요. 오늘은 쿼리 힌트가 뭔지, Postgres가 왜 그렇게 싫어했는지, 그리고 이제 와서 왜 마음을 바꾸려는지 풀어볼게요.

쿼리 힌트가 뭐냐면

데이터베이스에는 '쿼리 플래너(query planner)' 또는 '옵티마이저(optimizer)'라는 똑똑한 녀석이 있어요. 우리가 SQL을 던지면, 이 녀석이 "이 데이터는 인덱스로 찾는 게 빠를까, 아니면 테이블을 통째로 훑는 게 빠를까", "두 테이블을 합칠 때 어떤 조인 방식을 쓸까"를 통계 정보를 보고 스스로 결정해요. 우리는 '무엇을' 원하는지만 적고, '어떻게' 가져올지는 DB가 알아서 정하는 거죠.

그런데 가끔 이 옵티마이저가 헛다리를 짚어요. 통계가 오래됐거나 데이터 분포가 특이하면 엉뚱하게 느린 실행 계획을 골라버리거든요. 이럴 때 "야, 그러지 말고 이 인덱스 써"라고 개발자가 직접 명령을 끼워넣는 게 바로 쿼리 힌트예요. 오라클에서 SELECT /+ INDEX(...) / ... 이런 식으로 주석처럼 넣는 그거예요.

Postgres는 왜 그렇게 거부했나

Postgres 코어 팀의 논리는 일관됐어요. "힌트는 근본 문제를 가린다"는 거예요. 옵티마이저가 잘못된 계획을 골랐다면 그건 통계가 부정확하거나 옵티마이저에 개선할 점이 있다는 신호인데, 힌트로 강제로 덮어버리면 진짜 원인을 안 고치고 임시방편으로 때운다는 거죠. 게다가 한번 힌트를 박아두면, 나중에 데이터가 백만 건에서 일억 건으로 늘어 상황이 완전히 바뀌어도 그 옛날 힌트가 그대로 강제돼서 오히려 더 느려질 수 있어요. 그래서 "개발자가 힌트로 옵티마이저보다 똑똑한 척하는 건 위험하다"는 게 철학이었어요.

실제로 그동안은 pg_hint_plan 같은 외부 확장(extension)을 깔아서 우회하거나, enable_seqscan = off 같은 세션 설정을 임시로 만져서 옵티마이저의 선택지를 막는 식으로 버텨왔어요. 하지만 이건 너무 거칠어요. 특정 한 쿼리만 고치고 싶은데 세션 전체 동작을 바꿔버리니까요.

그래서 무엇이 달라지나

핵심 변화는 '현실론'의 승리예요. 운영 환경에선 새벽 3시에 갑자기 느려진 쿼리를 당장 막아야 할 때가 있거든요. "옵티마이저를 근본적으로 개선하자"는 옳은 말이지만, 그건 몇 달이 걸릴 수도 있는 일이에요. 그동안 서비스 장애를 그냥 두고 볼 순 없잖아요. 그래서 '응급 처치 수단'으로서 힌트의 가치를 인정하는 쪽으로 무게가 기울고 있어요. 논의되는 방향은 무분별한 강제가 아니라, 통제되고 명시적인 형태로 옵티마이저에 개입할 수 있는 길을 열어주는 거예요.

업계 맥락

사실 오라클, SQL Server, MySQL은 진작부터 힌트를 지원해왔어요. 그래서 다른 DB에서 넘어온 사람들에게 Postgres의 '힌트 없음'은 진입 장벽이자 마이그레이션의 걸림돌이었어요. 클라우드 매니지드 DB(예: 아마존 RDS, Aurora)가 보편화되면서 "옵티마이저 코드를 직접 못 고치는 환경"이 늘어난 것도 영향이 커요. 코어를 못 건드리는 사용자에겐 힌트가 사실상 유일한 튜닝 무기니까요. 이런 흐름 속에서 Postgres만 끝까지 버티기 어려워진 거죠.

한국 개발자에게 주는 시사점

국내에서도 Postgres 채택이 빠르게 늘고 있잖아요. 그동안 "운영 중에 특정 쿼리가 갑자기 느려지는데 손쓸 방법이 마땅찮다"는 게 Postgres 운영자들의 은근한 고충이었어요. 힌트가 정식으로 들어오면 이 응급 대응이 한결 수월해져요. 다만 주의할 게 있어요. 힌트는 어디까지나 '진통제'예요. 근본 원인(오래된 통계, 잘못된 인덱스 설계, 비정상적인 데이터 분포)을 고치는 대신 힌트만 덕지덕지 붙이면, 나중에 데이터가 커졌을 때 그 힌트들이 시한폭탄이 돼요. ANALYZE로 통계를 갱신하고 실행 계획(EXPLAIN ANALYZE)을 읽는 기본기는 여전히 필수예요.

마무리

한 줄 요약하면, Postgres가 오랜 철학적 고집을 한발 양보해 현실의 운영 필요를 받아들이려는 신호예요. 여러분은 어떻게 생각하세요? 옵티마이저를 믿고 맡기는 게 맞을까요, 아니면 개발자가 직접 통제할 수 있어야 진짜 프로덕션용 DB일까요? 힌트 때문에 데여본 경험이 있다면 같이 나눠봐요.