컨테이너 쿼리를 미디어 쿼리처럼 쓰지 마세요
스매싱 매거진이 CSS 컨테이너 쿼리와 미디어 쿼리를 같은 도구의 다른 문법 정도로 오해하는 경향을 짚었다. 브라우저 지원률이 94%에 달함에도 실제 사용률은 41.4%에 머무는 이유를 두 쿼리의 "관찰 대상"이 다르다는 데서 찾는다. 미디어 쿼리는 뷰포트라는 페이지 전체 단위를, 컨테이너 쿼리는 부모 컨테이너라는 컴포넌트 단위를 관찰한다는 것이다.
"미디어 쿼리는 사실 아는 게 별로 없다."Kevin Powell, Smashing Magazine
왜 중요한가
같은 문법처럼 보이는 두 기능을 혼용하면 재사용 가능한 컴포넌트를 만들겠다는 애초의 목표가 흔들린다. 컨테이너 쿼리는 래퍼 요소가 필요하고 블록 크기 기준 쿼리 시 레이아웃이 무너질 수 있으며 커스텀 속성을 쿼리 조건에 쓸 수 없다는 제약도 있다. 이런 트레이드오프를 모르고 도입하면 오히려 디버깅 비용이 늘어난다.
실무 적용
원칙은 명확하다. 페이지 전역 레이아웃은 미디어 쿼리로, 사이드바·카드처럼 여러 컨텍스트에 반복 배치되는 컴포넌트는 컨테이너 쿼리로 나눠 담당시킨다. cqi 같은 컨테이너 단위로 컴포넌트 내부 타이포그래피를 조정하거나 flex-wrap 여부를 감지하는 기능은 미디어 쿼리로는 흉내 낼 수 없는 영역이라 이 구분을 지켜야 실제 이점을 가져간다.
교차 참고
- Smashing Magazine: How Baseline Can Help You Ship Less JavaScript — Baseline 지표로 이제 라이브러리 없이 바로 써도 되는 브라우저 내장 기능을 가려내는 법.
Wemeet의 관점
Wemeet이 만드는 랜딩페이지와 대시보드는 같은 카드·배너 컴포넌트가 사이드바, 본문, 모달 등 폭이 제각각인 자리에 반복 배치되는 구조가 많다. 이런 프로젝트에서는 컨테이너 쿼리 도입 여부가 유지보수 비용을 좌우한다. 뷰포트 기준 브레이크포인트만 늘려온 기존 코드베이스라면, 컴포넌트 단위로 반응형을 다시 설계하는 리팩터링을 검토할 시점이다.
이 글은 아래 원문을 바탕으로 Wemeet이 한국어로 요약·정리한 큐레이션입니다.
원문 보기 — Smashing Magazine ↗