반응형 웹사이트를 만들어본 사람이라면 한 번쯤 겪어봤을 겁니다. 똑같은 카드 컴포넌트인데 사이드바에 들어가면 답답하고, 본문 영역에 놓이면 여백이 과하고, 푸터의 2단 그리드에서는 또 다르게 보이는 상황 말입니다. 미디어 쿼리만으로는 이걸 해결할 수가 없었습니다. 컴포넌트는 자신이 어디에 놓였는지 모르고, 오직 '브라우저 창이 얼마나 넓은가'만 알 수 있었으니까요. 2023년 이후 모든 주요 브라우저가 Container Queries를 지원하기 시작했고, 이제 웹은 다른 방식으로 반응하는 시대에 들어섰습니다.
미디어 쿼리가 해결하지 못한 문제
전통적인 반응형 디자인은 뷰포트(화면) 크기를 기준으로 동작합니다. 가로 768px 이하에서는 모바일 레이아웃, 1024px 이상에서는 데스크톱 레이아웃 같은 식이죠. 하나의 페이지 전체가 같은 기준으로 움직이는 구조입니다. 문제는 요즘 웹사이트가 더 이상 '페이지 단위'로만 구성되지 않는다는 점입니다.
디자인 시스템, 컴포넌트 기반 개발, 헤드리스 CMS가 일반화되면서 같은 카드가 홈에서는 3단 그리드로, 상세 페이지 사이드바에서는 세로 목록으로, 모달 안에서는 작은 썸네일로 재사용됩니다. 이 경우 뷰포트는 1440px로 넓은데 컴포넌트가 놓인 공간은 280px짜리 사이드바인 상황이 흔히 발생합니다. 미디어 쿼리는 이 차이를 감지하지 못합니다.
Container Queries가 바꾸는 것
Container Queries는 '화면'이 아니라 '부모 컨테이너'의 크기에 반응합니다. 컴포넌트가 자기 자리의 너비를 스스로 확인하고 레이아웃을 조정하는 겁니다. 문법은 두 단계로 나뉩니다.
컨테이너 지정
먼저 크기를 감지할 부모 요소에 container-type을 지정합니다. inline-size는 가로 크기만, size는 가로와 세로 모두를 기준으로 삼습니다. 이름(container-name)을 붙여두면 여러 컨테이너를 구분해서 쿼리할 수 있습니다.
조건에 따른 스타일
자식 요소에서는 @container 규칙으로 조건을 걸고 스타일을 바꿉니다. @media 대신 @container가 들어간다고 생각하면 됩니다. 이 작은 차이가 컴포넌트의 자립성을 완전히 바꿔 놓습니다. 이제 카드는 자신이 320px 폭 안에 들어갔는지, 800px 폭 안에 들어갔는지를 알고 스스로 판단합니다.
실무에서 달라지는 것들
재사용 컴포넌트가 진짜 재사용된다
가장 큰 변화는 컴포넌트의 맥락 독립성입니다. 지금까지는 같은 카드 컴포넌트를 여러 자리에 쓰려면 CardOnSidebar, CardOnHero, CardCompact 같은 변형을 여러 개 만들거나, 부모에서 클래스를 주입해 스타일을 덮어씌워야 했습니다. Container Queries가 있으면 카드 하나만 만들어 두면 됩니다. 어디에 놓이든 스스로 적응하니까요.
디자인 시스템의 일관성이 강해진다
디자인 시스템을 운영할 때 가장 흔한 문제는 '같은 컴포넌트가 페이지마다 다르게 보인다'는 것입니다. 대부분 맥락에 따라 덧붙인 예외 스타일이 쌓여서 생기는 부작용입니다. Container Queries는 이 예외를 컴포넌트 내부로 흡수시킵니다. 덕분에 새로운 페이지에 컴포넌트를 꽂아도 예상된 모습으로 동작하고, 리팩터링 비용이 줄어듭니다.
CMS와 대시보드에서 빛을 발한다
노션, 커스텀 대시보드, 관리자 페이지처럼 사용자가 레이아웃을 자유롭게 바꿀 수 있는 환경에서는 Container Queries의 위력이 특히 큽니다. 사용자가 위젯을 좁은 칸에 넣든 넓은 칸에 넣든, 위젯이 알아서 보기 좋은 형태로 변합니다. 쇼핑몰에서도 카테고리 페이지의 카드 개수를 사용자가 조절할 수 있는 기능 같은 것이 훨씬 쉬워집니다.
도입 전에 알아두어야 할 것
브라우저 지원
Chrome과 Edge는 105, Safari는 16, Firefox는 110부터 지원합니다. 대부분의 사용자가 이미 지원 브라우저를 쓰고 있지만, 구형 환경이 섞여 있다면 단계적 접근이 필요합니다. @supports 규칙으로 지원 여부를 감지해 폴백(fallback) 스타일을 함께 제공하면 안전합니다.
성능 고려
container-type을 설정하면 브라우저는 해당 요소에 대해 추가적인 레이아웃 계산을 수행합니다. 페이지 전체에 남발하면 오히려 렌더링 성능이 떨어질 수 있습니다. 꼭 필요한 컨테이너에만 지정하는 것이 원칙입니다. 특히 size(가로+세로)보다는 inline-size(가로만) 쪽이 계산 비용이 훨씬 적습니다.
미디어 쿼리를 완전히 대체하지는 않는다
Container Queries는 미디어 쿼리를 대체하는 것이 아니라 보완하는 도구입니다. 내비게이션 바, 전체 페이지의 그리드 전환, 타이포그래피 스케일처럼 '페이지 수준'의 반응은 여전히 미디어 쿼리가 맡습니다. 반대로 컴포넌트 내부의 레이아웃, 카드, 위젯, 폼 요소는 Container Queries가 맞습니다. 역할을 나눠서 쓰는 것이 핵심입니다.
지금 시작해야 하는 이유
Container Queries는 이미 실무에 적용할 수 있을 만큼 안정화되었습니다. 무엇보다 중요한 점은 이 기능이 단순한 기술적 진보가 아니라 컴포넌트 단위로 사고하는 프런트엔드 개발 패러다임과 정확히 맞물려 있다는 것입니다. 디자인 시스템을 도입하거나 리뉴얼을 준비하는 팀이라면 지금이 Container Queries를 레이어에 포함시킬 최적의 시점입니다.
CYAN 에이전시는 최신 웹 표준을 반영한 디자인 시스템 기반의 웹사이트 제작을 지향합니다. 뷰포트가 아닌 컴포넌트가 스스로 반응하는 웹사이트, 어떤 레이아웃에 놓여도 흔들리지 않는 디자인을 고민하고 계시다면 언제든 문의 주세요.