본문 바로가기
개발2026년 7월 25일6분 읽기

컨테이너 쿼리(Container Queries) — 반응형의 기준이 화면에서 컴포넌트로

YS
김영삼
조회 3
컨테이너 쿼리(Container Queries) — 반응형의 기준이 화면에서 컴포넌트로

반응형 웹을 만든다고 하면 대부분 화면 너비를 기준으로 분기하는 미디어 쿼리를 떠올린다. 그런데 요즘 CSS 진영에서 조용히, 그러나 확실하게 무게중심이 옮겨가고 있다. 기준이 화면(viewport)에서 컴포넌트가 놓인 컨테이너로 바뀌는 중이다. 그 주역이 컨테이너 쿼리(Container Queries)다.

컨테이너 쿼리는 요소의 스타일을 화면 크기가 아니라 그 요소를 감싼 부모의 크기에 따라 바꾸는 CSS 기능이다. 같은 카드 컴포넌트라도 넓은 영역에 놓이면 가로형으로, 좁은 사이드바에 놓이면 세로형으로 스스로 판단해 배치를 바꾼다.

컴포넌트가 자기가 놓인 공간을 보고 스스로 모양을 정한다.
컨테이너 쿼리는 반응형의 단위를 페이지에서 부품으로 바꾼다.

화면 폭 하나로 모든 걸 분기하던 시대가 저물고, 재사용 가능한 컴포넌트가 문맥에 맞게 반응하는 설계가 표준이 되고 있다.

부모기준
화면이 아닌
컨테이너 크기
cqw
컨테이너 상대
단위 도입
재사용
한 컴포넌트
어디든 이식
표준
주요 브라우저
안정 지원

미디어 쿼리의 한계

미디어 쿼리는 훌륭했지만 근본 가정이 하나 있었다. "페이지 레이아웃은 위에서 아래로 한 덩어리로 흐른다"는 것. 그래서 화면 폭만 알면 모든 요소의 배치를 결정할 수 있었다. 그런데 요즘 UI는 그렇지 않다. 같은 상품 카드가 홈에서는 4열 그리드에, 상세 페이지에서는 넓은 본문에, 장바구니에서는 좁은 사이드바에 동시에 등장한다.

이때 미디어 쿼리로 대응하려면 카드가 자기가 어디에 놓였는지를 화면 폭으로 역추정해야 한다. "화면이 1200px 이상이면 사이드바에 있을 테니 좁게"… 이런 식의 추정은 금세 무너진다. 레이아웃이 조금만 바뀌어도 가정이 깨지기 때문이다. 컴포넌트를 진짜 독립적인 부품으로 만들려는데, 스타일만은 페이지 전체 문맥에 묶여 있었던 셈이다.

컨테이너 쿼리가 푸는 것

컨테이너 쿼리는 이 매듭을 정확히 끊는다. 부모 요소를 컨테이너로 지정하면, 그 안의 자식은 자기 컨테이너의 실제 크기를 보고 스타일을 결정한다. 화면이 얼마나 넓은지는 알 필요가 없다.

.card-wrap { container-type: inline-size; }
@container (min-width: 380px) {
  .card { display: grid; grid-template-columns: 120px 1fr; }
}

이제 이 카드는 어느 페이지에 갖다 놓아도, 자기에게 주어진 가로 폭이 380px을 넘으면 가로형으로 바뀐다. 컴포넌트 하나가 문맥을 스스로 읽고 적응하는 것이다. 나는 이걸 처음 제대로 써 봤을 때, 그동안 얼마나 많은 코드를 "이 컴포넌트가 어디에 쓰일지"를 예측하는 데 낭비했는지 실감했다.

컨테이너 단위

함께 들어온 컨테이너 상대 단위도 유용하다. cqw는 컨테이너 너비의 1%를 뜻한다. 제목 글자 크기를 컨테이너 폭에 비례시키면, 넓은 곳에서는 크게 좁은 곳에서는 작게 자동으로 조정된다. 화면 기준의 vw 단위로는 표현하기 어렵던 컴포넌트 단위 타이포그래피가 가능해진다.

설계가 어떻게 바뀌나

가장 큰 변화는 사고방식이다. 이전에는 "이 페이지의 브레이크포인트는 몇 개"라고 페이지 단위로 생각했다면, 이제는 "이 컴포넌트는 어떤 폭에서 형태가 바뀌어야 하나"를 부품 단위로 생각한다. 디자인 시스템을 운영하는 팀에게 이건 특히 반갑다. 컴포넌트 라이브러리의 각 부품이 문맥에 자족적으로 반응하니, 페이지를 조립하는 쪽에서 배치를 신경 쓸 부담이 줄어든다.

항목컨테이너 쿼리미디어 쿼리
기준부모 컨테이너 크기화면(뷰포트) 크기
재사용성문맥 독립위치 가정에 의존
사고 단위컴포넌트페이지
적합한 곳재사용 부품전체 레이아웃 골격

둘은 경쟁하지 않는다

오해하지 말아야 할 건, 컨테이너 쿼리가 미디어 쿼리를 대체하는 게 아니라는 점이다. 페이지 전체 골격, 예컨대 사이드바를 접을지 말지 같은 큰 판단은 여전히 화면 기준이 자연스럽다. 반면 그 골격 안에 들어가는 개별 부품의 적응은 컨테이너 기준이 맞다. 둘을 역할에 맞게 나눠 쓰는 것이 지금의 정석이다.

한동안은 컨테이너 지정에 따른 레이아웃 계산 비용이나 중첩 규칙을 두고 조심스러운 목소리도 있었지만, 지금은 주요 브라우저에서 안정적으로 돌아가고 실무 도입도 빠르게 늘고 있다. 새로 시작하는 디자인 시스템이라면 처음부터 컨테이너 기준으로 사고를 세팅하길 권한다.

자주 묻는 질문

컨테이너 쿼리가 미디어 쿼리를 완전히 대체하나요?

아니다. 페이지 전체 골격은 화면 기준이 여전히 자연스럽고, 개별 컴포넌트의 적응은 컨테이너 기준이 맞다. 둘을 역할에 따라 병행하는 것이 권장되는 방식이다.

container-type을 지정하면 성능에 문제가 없나요?

컨테이너로 지정된 요소는 크기 계산의 기준점이 되므로 레이아웃 격리가 일어난다. 남용하지 않고 실제로 반응이 필요한 래퍼에만 지정하면 실무에서 체감할 만한 부담은 크지 않다.

기존 프로젝트에 점진적으로 도입할 수 있나요?

가능하다. 새로 만드는 컴포넌트부터 컨테이너 기준으로 작성하고 기존 미디어 쿼리는 그대로 둬도 충돌하지 않는다. 부품 단위로 조금씩 옮겨가는 방식이 현실적이다.

컨테이너 단위 cqw는 언제 쓰나요?

컴포넌트 폭에 비례해 글자나 여백을 조절하고 싶을 때 유용하다. 화면 기준 vw로는 표현하기 어려운 부품 단위의 유동적 크기 조절을 깔끔하게 처리할 수 있다.

댓글 0

아직 댓글이 없습니다.
Ctrl+Enter로 등록