CSS 컨테이너 쿼리를 전통적인 미디어 쿼리처럼 다루지 마세요

솔직히 말씀드리자면, CSS Container Queries가 처음 출시되었을 때 저는 그 소식을 놓쳤습니다. 그리고 마침내 이 소식을 듣고 가장 먼저 생각한 것은 '미디어 쿼리가 이미 존재하는데, 대체 내가 이걸 왜 필요로 하는 거지?'였습니다.

지금 제가 아는 것을 알기에 제 반응이 자랑스럽지는 않지만, 저 혼자만 그런 생각을 하는 게 아니라는 사실에 안도했습니다. 실제로 저희 같은 사람들이 엄청나게 많습니다.

저를 당황하게 만드는 것은 컨테이너 쿼리가 새로운 기능이 아니라는 점입니다. 현재 94%의 브라우저 지원 수준에 도달해 있습니다. 그런데도 실제로 사용하는 사람이 매우 적습니다. State of CSS 설문조사에 따르면, 개발자의 86%가 컨테이너 쿼리를 인지하고 있지만, 실제로 사용하는 비율은 41.4%에 불과합니다. 설문조사는 편향될 수 있고 우리의 전체 분야를 완전히 대표하지는 못하지만, 이 자료가 우리가 가진 최고의 지표임에는 틀림없습니다.

[Kevin Powell]도 SmashingConf Amsterdam 2026에서 이 주제로 이야기했습니다: 컨테이너 쿼리 채택률이 형편없다고요. 그리고 이는 매우 이상하게 느껴집니다. 컴포넌트가 외부 컨테이너의 크기에 맞춰 적응할 수 있는 기능이 지난 몇 년 동안 수많은 CSS 위시리스트에서 최상위에 있었음을 아는 입장에서 말입니다.

저는 사람들이 컨테이너 쿼리를 얼마나 많이 사용하는지에 크게 관심이 있는 것이 아니라, 어떻게 사용하고 있느냐에 더 관심이 있습니다. 모든 사람을 설명할 수는 없지만, 제가 목격한 것—저 자신의 초기 시도들을 포함하여—많은 사람이 그것들을 잘못 사용하고 있습니다.

결론은 잘못된 사용법이 제가 이 기능에 대해 배울 때 가졌던 인상과 같은 맥락으로 귀결됩니다. 첫눈에 보기에는 미디어 쿼리와 완전히 똑같아 보이기 때문입니다. 그리고 비슷하게 생겼기 때문에, 비슷한 목적을 가지고 있고 같은 방식으로 작동한다고 가정하기 쉽습니다.

하지만 그렇지 않습니다.

참고: 본 기사에서 제가 초점을 맞추는 것은 container_size 쿼리를 사용하는 것입니다. 즉, 특정 컨테이너의 크기에 반응하는 반응형 디자인 기술입니다. 또한 컨테이너의 계산된 스타일(computed styles)에 반응하는 container_style 쿼리도 있습니다 (본문 작성 시점에서는 실험적입니다). 이 기능들의 가능한 사용 사례를 검토한 Smashing Magazine의 Juan Diego 글에서 더 자세히 알아볼 수 있습니다.

미디어 쿼리(Media Queries)는 바깥을 바라봅니다 (Look Outward)

뷰포트(viewport)는 대리 지표(proxy)입니다. 항상 그래왔습니다. 미디어 쿼리는 화면 너비만으로도 반응형 앱이 환경에 어떻게 적응하는지라는 착각을 우리에게 주었습니다.

스스로에게 물어보세요: @media를 작성할 때, 브라우저에게 무엇을 요청하고 있나요?

@media (min-width: 1024px) {
  .card {
    display: flex;
...

대부분의 개발자와 마찬가지로 저는 브라우저에게 이렇게 질문합니다: 지금 화면 너비가 얼마나 되나요? 그게 전부입니다.

미디어 쿼리는 이 질문에 완벽하게 답하지만, 만약 이 .card 컴포넌트가 1920px의 데스크톱 화면에서 300px 너비의 그리드 셀 안에 배치된다면 어떻게 될까요?

미디어 쿼리는 신경 쓰지 않습니다. 제 역할을 할 뿐입니다. 뷰포트는 여전히 1920px이므로, min-width: 1024px가 발동하고 일치하는 쿼리 스타일이 적용됩니다. 하지만 카드가 작업할 공간은 겨우 300px에 불과합니다. 결국 카드 안의 모든 것이 변형되거나(deforms), 오버플로우하거나, 혹은 비좁게 압축됩니다.

“미디어 쿼리는 어리석습니다. 개념적인 측면에서 어리석다는 뜻이 아니라, 아는 것이 별로 없어서 어리석하다는 의미입니다. 사실 대부분의 사람들은 자신이 아는 것보다 더 많이 안다고 가정합니다.”

— Kevin Powell

반응형 디자인을 단순히 큰 화면에서는 두 개의 열(column)에서 작은 화면에서는 하나의 열로 레이아웃 전체를 업데이트하는 시스템으로 생각하는 것이 흔합니다.

컨테이너 쿼리(Container Queries)는 안쪽을 바라봅니다 (Look Inward)

컨테이너 쿼리(Container Queries)는 그보다 더 똑똑합니다. 이들은 반응형 레이아웃을 컴포넌트의 외부 컨텍스트에 의존하기보다는, 컴포넌트 내부에서 발생하는 일에 더 많이 의존하게 만듭니다. 이는 다음과 같습니다: “지금, 바로 이 특정 위치에 나에게 얼마나 많은 공간이 확보되어 있는가?”

지난 섹션에서 살펴본 것과 동일한 카드 코드 예시를 컨테이너 쿼리를 사용하여 보여드리겠습니다:

.card-wrapper {
  container-name: card;
  container-type: inline-size;
...

이것은 모든 것을 바꿉니다. 카드는 뷰포트(viewport)의 영향을 받지 않습니다. 오직 .card 컴포넌트의 부모 래퍼가 최소 450px의 인라인(inline, 즉 왼쪽에서 오른쪽으로 쓰는 모드에서는 가로 방향) 공간을 가지고 있는지 여부만을 신경 씁니다. 이 조건이 참이면, 컴포넌트는 가로 방향으로 배치되고; 그렇지 않으면 기본값인 block 디스플레이를 따릅니다.

논리는 다음과 같이 작동합니다:

1. 충분한 공간이 있을 때, 두 항목(.flex-item)은 나란히 위치하며, 각각 부모 컨테이너 너비의 정확히 절반을 차지합니다.
2. 공간이 제한적일 때는, 두 번째 항목이 다음 줄로 감싸집니다(wraps).
3. 각 항목에 flex-grow가 활성화되어 있기 때문에, 감싸진 항목들은 부모 너비의 대부분을 채우도록 늘어납니다.
4. 만약 해당 항목 자체가 컨테이너라면, 갑작스러운 너비 확장을 감지하고 스타일이 발동됩니다.

/* flex 부모 */
.flex-layout {
  display: flex;
...

이것이 작동합니다. 부모 크기가 줄어들고 카드가 두 줄로 감싸질 때, 카드 항목이 확장되고, 컨테이너 쿼리가 발동되어 필요한 스타일을 적용합니다.

결론

궁극적으로, 컨테이너 쿼리가 미디어 쿼리(media queries)와 놀라울 정도로 비슷해 보이는 핵심적인 이유는 단지 친숙함 때문입니다. 이것들이 정확히

우리가 가진 것은 특정 컴포넌트의 컨텍스트가 언제 바뀌는지 감지하는 더 효과적인 기능이며, 해당 컴포넌트가 여러 컨텍스트에 존재할 수 있을 때 마땅히 그래야 하는 방식대로 그 내용(콘텐츠)을 기반으로 스타일을 조정하는 수단입니다.