컨테이너 쿼리, 미디어 쿼리처럼 쓰지 마세요

Smashing Magazine에 Victor Ayomipo가 쓴 글은 컨테이너 쿼리를 "미디어 쿼리의 최신 버전"으로 오해하는 관행을 정면으로 지적합니다. 브라우저 지원율은 94%에 이르지만 실제 사용률은 41.4%에 머무는데, 그 이유 중 하나가 두 기능의 역할을 구분하지 못한 채 뷰포트 기준 사고방식을 그대로 옮겨 쓰기 때문이라는 것입니다. 미디어 쿼리는 바깥(뷰포트)을 보고, 컨테이너 쿼리는 안쪽(컴포넌트에 주어진 공간)을 봅니다.

"미디어 쿼리는 멍청합니다 — 개념이 아니라, 아는 것이 너무 적다는 점에서요."Smashing Magazine

왜 중요한가

미디어 쿼리는 화면 폭만 알 뿐, 그 안의 카드가 사이드바에 들어갔는지 전체 폭을 차지하는지는 모릅니다. 그래서 같은 컴포넌트를 위치마다 다르게 보이게 하려면 결국 브레이크포인트마다 예외 규칙이 쌓이고, 디자인 시스템의 컴포넌트는 "어디에 놓이는지"를 전제한 반쪽짜리 부품이 됩니다. 컨테이너 쿼리는 레이아웃 판단 기준을 뷰포트에서 컴포넌트가 실제로 할당받은 공간으로 옮겨, 부품이 스스로 상황에 적응하게 만듭니다.

실무 적용

역할을 나누는 것이 출발점입니다. 헤더·내비게이션·페이지 그리드 같은 거시 레이아웃은 미디어 쿼리로, 카드·위젯·폼처럼 여러 자리에 재사용되는 부품은 컨테이너 쿼리로 다루면 규칙이 훨씬 단순해집니다. 타이포그래피도 cqi 단위를 clamp()와 함께 쓰면 컴포넌트 폭에 맞춰 자연스럽게 조절되고, 플렉스 아이템의 줄바꿈 감지처럼 예전에 자바스크립트로 처리하던 일도 CSS만으로 해결됩니다. 다만 컨테이너는 자기 자신을 질의할 수 없으므로, 래퍼 요소에 container-type을 두는 구조를 먼저 잡아야 합니다.

교차 참고

• Smashing Magazine: How Baseline Can Help You Ship Less JavaScript — 널리 지원되는 최신 웹 표준을 Baseline 기준으로 확인해 자바스크립트 의존을 줄이는 방법을 정리합니다.

Wemeet의 관점

지원율 94%와 사용률 41%의 격차는 기술의 문제가 아니라 습관의 문제입니다. Wemeet은 새 프로젝트의 CSS 구조를 잡을 때 "이 규칙의 판단 근거가 화면인가, 아니면 이 부품이 놓인 자리인가"를 먼저 묻는 것만으로도 브레이크포인트 예외가 눈에 띄게 줄어든다고 봅니다. 컴포넌트가 자기 공간을 스스로 읽는 구조는, 나중에 레이아웃을 바꿔도 부품을 다시 손대지 않아도 되는 유지보수 이점으로 돌아옵니다.