반응형 홈페이지 카드, 놓이는 자리가 좁아지면 깨지는 이유와 해결법

# 반응형 카드, 사이드바에 넣으면 왜 깨질까?
CSS 컨테이너 쿼리로 끝내는 카드 UI 설계 완벽 가이드

---

메인 목록에서는 완벽하게 보이던 카드 컴포넌트를 사이드바나 좁은 칸에 그대로 넣었더니 이미지와 텍스트가 겹치고 버튼이 잘려 나온 경험, 개발자라면 한 번쯤 겪어봤을 겁니다. 분명 미디어 쿼리로 반응형 처리를 다 해뒀는데 왜 이런 일이 생기는 걸까요?

결론부터 말하면 미디어 쿼리는 화면(뷰포트) 크기만 검사하지, 카드가 실제로 놓인 부모 요소의 폭은 전혀 신경 쓰지 않기 때문입니다. 화면이 1920px로 넓어도 카드가 300px짜리 사이드바 안에 들어가면 미디어 쿼리 입장에서는 "화면이 넓으니 가로형 레이아웃을 써도 된다"고 착각해버립니다. 그 결과가 바로 이미지 겹침, 텍스트 밀림, 버튼 잘림 같은 흔한 UI 사고입니다.

이 글에서는 이 문제를 근본적으로 해결하는 CSS 컨테이너 쿼리를 중심으로, 카드 목록의 외부 배치는 CSS Grid로 짜고 카드 내부 변화는 컨테이너 쿼리로 제어하는 설계 방식을 단계별로 정리합니다.
`container-type: inline-size` 선언부터 `@container` 조건 분기, `cqi` 단위를 이용한 글자 크기 조절, 그리고 미지원 환경을 위한 대체 구성까지 순서대로 따라오시면, 놓이는 자리가 어디든 깨지지 않는 카드 UI를 실제로 구현할 수 있습니다.

이 정도만 알면 바로 시작할 수 있어요

카드 UI를 컨테이너 쿼리로 재설계하는 데 필요한 준비물은 생각보다 단순합니다. HTML·CSS 기본 문법을 다룰 수 있고, CSS Grid와 Flexbox의 기초 개념(트랙, 자동 배치, 축)을 이해하고 있다면 바로 실습에 들어갈 수 있습니다. 별도의 프레임워크나 빌드 도구가 꼭 필요한 건 아니고, 순수 CSS만으로도 충분히 구현 가능합니다.

실습 환경 측면에서는 최신 버전의 크롬·엣지·파이어폭스·사파리 중 하나만 있어도 됩니다. caniuse.com이 2026년 9월 27일 기준으로 확인한 바에 따르면 크기 기반 컨테이너 쿼리는 크롬·엣지 106, 파이어폭스 110, 사파리 16.0(iOS 포함), 삼성 인터넷 20부터 지원되고 있고, 이를 지원하는 브라우저의 전 세계 사용 비율은 94.87%에 달합니다. 즉 대부분의 실무 환경에서 별다른 폴리필 없이 바로 적용해볼 수 있는 수준입니다.

컴포넌트 기반 웹제작 방식에 익숙하다면 이해가 훨씬 빠릅니다. 카드를 하나의 독립된 컴포넌트로 보고, "이 컴포넌트는 자기가 놓인 자리의 크기에 따라 스스로 레이아웃을 바꾼다"는 개념만 잡으면 나머지는 CSS 문법 문제일 뿐입니다.

준비할 것을 정리하면 다음과 같습니다.
① HTML·CSS 기본 문법 이해
② CSS Grid의 `repeat()`, `minmax()` 문법 지식
③ 컨테이너 쿼리를 지원하는 최신 브라우저(크롬 106+, 파이어폭스 110+, 사파리 16+ 등)
④ 텍스트 에디터와 로컬 서버 환경(라이브 서버 확장 등)

Step 1: 미디어 쿼리와 컨테이너 쿼리의 기준 차이부터 정확히 이해하기

미디어 쿼리와 컨테이너 쿼리는 검사하는 기준 자체가 다릅니다. 이 차이를 정확히 이해하지 못하면 아무리 문법을 따라 해도 왜 문제가 해결되는지 알 수 없습니다.

MDN은 2026년 9월 16일 기준으로 미디어 쿼리가 뷰포트·기기 환경 특성을 검사하고, 컨테이너 쿼리는 지정된 컨테이너의 크기·상태를 기준으로 자식 요소의 스타일을 적용한다고 명확히 구분해 설명하고 있습니다. 쉽게 말해 미디어 쿼리는 "지금 화면이 몇 픽셀이야?"를 묻고, 컨테이너 쿼리는 "지금 이 카드가 들어있는 상자가 몇 픽셀이야?"를 묻는 겁니다.

이 차이가 왜 중요한지, 실제 상황으로 풀어보겠습니다.

카드를 메인 목록에 넣을 때는 카드가 화면 폭의 대부분을 차지하니 미디어 쿼리로 "화면이 768px 이상이면 가로형 레이아웃"이라고 지정해도 문제가 없어 보입니다. 하지만 같은 카드 컴포넌트를 사이드바나 대시보드의 좁은 패널, Grid 레이아웃 안의 작은 칸에 재사용하는 순간 문제가 터집니다. 화면 자체는 여전히 1920px든 1440px든 넓은데, 카드가 실제로 차지하는 공간은 200~300px 수준으로 좁아지기 때문입니다.

web.dev는 2026년 9월 16일 기준으로 카드가 사이드바·히어로 영역·Grid 내부에 배치될 때 컨테이너 쿼리를 사용하면 뷰포트가 아니라 카드가 속한 컨테이너 너비에 따라 내부 레이아웃을 바꿀 수 있다고 설명합니다. 즉 컨테이너 쿼리는 컴포넌트 기반 웹제작에서 필연적으로 발생하는 "같은 컴포넌트, 다른 배치 위치" 문제를 정면으로 해결하기 위해 만들어진 기능입니다.

주의할 점은 미디어 쿼리를 완전히 버려야 한다는 뜻이 아니라는 겁니다. 페이지 전체의 큰 틀(사이드바를 보여줄지 말지, 헤더 높이를 얼마로 할지)은 여전히 미디어 쿼리로 처리하는 게 자연스럽습니다. 다만 재사용되는 개별 컴포넌트, 특히 카드처럼 여러 위치에 반복 배치되는 요소의 내부 레이아웃은 컨테이너 쿼리로 넘기는 것이 반응형 웹디자인의 다음 단계라고 볼 수 있습니다.

Step 2: container-type 선언으로 카드의 부모를 컨테이너로 만들기

컨테이너 쿼리를 쓰려면 먼저 카드를 감싸는 부모 요소에 `container-type`을 선언해서 그 요소를 "쿼리 가능한 컨테이너"로 등록해야 합니다. 이 선언 없이는 아무리 `@container` 문법을 써도 아무 일도 일어나지 않습니다.

MDN에 따르면 크기 기반 컨테이너 쿼리를 사용하려면 부모 요소에 `container-type: inline-size` 또는 `container-type: size`를 선언해야 합니다. 여기서 실무자들이 자주 헷갈리는 부분이 바로 이 두 값의 차이입니다.

`container-type`의 기본값은 `normal`이며, `normal`인 요소는 애초에 크기 쿼리의 컨테이너가 되지 않습니다. 크기를 기준으로 쓰려면 반드시 `size` 또는 `inline-size` 중 하나를 명시해야 합니다.

그런데 `size`는 너비와 높이를 모두 기준으로 삼는 대신, 높이 억제(containment)가 걸려서 카드가 내용의 높이만큼 자연스럽게 늘어나지 않을 수 있다는 부작용이 있습니다. 이미지, 제목, 본문 텍스트로 구성된 일반적인 카드에서 이런 높이 고정은 오히려 콘텐츠가 잘리는 새로운 문제를 만들 수 있습니다. 그래서 일반적인 카드 UI에는 높이를 자유롭게 놔두는 `container-type: inline-size`를 쓰는 것이 안전한 선택입니다.

실제 코드는 다음과 같은 형태가 됩니다.

```css
.card-wrapper {
container-type: inline-size;
}
```

여기서 `.card-wrapper`는 카드를 직접 감싸는 부모 요소입니다. 카드 자체가 아니라 카드의 부모에 선언한다는 점이 중요합니다. 컨테이너 쿼리는 "자기 자신"의 크기를 기준으로 자기 스타일을 바꾸는 게 아니라, "부모 컨테이너"의 크기를 기준으로 "자식"의 스타일을 바꾸는 구조이기 때문입니다.

이름을 붙여서 더 명확하게 관리하고 싶다면 `container-name`과 `container-type`을 함께 쓰거나, 축약형인 `container: card / inline-size` 형태로 한 줄에 선언할 수도 있습니다. 이름 있는 컨테이너를 쓰면 뒤에서 다룰 "가장 가까운 컨테이너 조회" 문제를 더 정교하게 제어할 수 있습니다.

주의 사항으로는, `container-type`을 선언한 요소는 컨테인먼트(containment) 특성이 적용되기 때문에 레이아웃 계산 방식이 미묘하게 달라질 수 있다는 점입니다. 기존에 이 부모 요소에 다른 레이아웃 의존 스타일이 걸려 있었다면 적용 후 반드시 실제 화면에서 확인하는 습관이 필요합니다.

Step 3: @container 조건으로 카드 내부를 가로형↔세로형으로 전환하기

`@container` 규칙을 이용하면 카드가 놓인 컨테이너의 폭에 따라 카드 내부 레이아웃을 가로형과 세로형으로 자동 전환할 수 있습니다. 이게 바로 이 글의 핵심 해결책입니다.

기본 원리는 이렇습니다. 컨테이너 폭이 넉넉할 때(예: 400px 이상)는 이미지를 왼쪽, 텍스트를 오른쪽에 두는 가로형 레이아웃을 쓰고, 컨테이너 폭이 좁아지면(예: 300px 미만) 이미지를 위, 텍스트를 아래에 두는 세로형 레이아웃으로 자동 전환하는 방식입니다.

```css
.card {
display: flex;
flex-direction: column;
}

@container (min-width: 400px) {
.card {
flex-direction: row;
}
}
```

이 코드에서 눈여겨볼 부분은 컨테이너 이름을 따로 지정하지 않았다는 점입니다. MDN은 컨테이너 이름을 생략한 쿼리는 조건에 맞는 가장 가까운 컨테이너를 조회한다고 설명합니다. 즉 `.card`의 부모 트리를 따라 올라가면서 `container-type`이 선언된 가장 가까운 요소를 찾아 그 폭을 기준으로 삼습니다.

이 방식은 간단한 페이지에서는 편리하지만, 컴포넌트 기반 웹제작 환경처럼 카드가 여러 겹의 부모 컨테이너 안에 중첩되는 구조라면 문제가 생길 수 있습니다. 예를 들어 카드 바깥에 사이드바 컨테이너가 있고, 그 사이드바 바깥에 전체 레이아웃 컨테이너가 또 있다면, "가장 가까운 컨테이너"가 개발자가 의도한 컨테이너가 아닐 수도 있습니다.

이럴 때는 이름 있는 컨테이너를 쓰는 것이 안전합니다.

```css
.card-wrapper {
container: card-container / inline-size;
}

@container card-container (min-width: 400px) {
.card {
flex-direction: row;
}
}
```

이렇게 하면 아무리 중첩 구조가 복잡해도 `card-container`라는 이름을 가진 컨테이너만 정확히 지목해서 쿼리할 수 있습니다. 카드 UI 설계에서 배치 위치가 사이드바, 메인 목록, 모달, 대시보드 위젯 등 다양하게 확장될 가능성이 있다면 처음부터 이름 있는 컨테이너 방식을 습관화하는 걸 권해드립니다.

주의할 점은 `min-width` 기준값을 카드 디자인에 맞춰 신중히 정해야 한다는 겁니다. 무작정 400px, 300px 같은 값을 복사해 쓰기보다, 실제 카드 안의 이미지 최소 크기와 텍스트 줄 바꿈 지점을 고려해서 기준값을 잡아야 어색한 전환 구간이 생기지 않습니다.

Step 4: cqi 단위로 제목 글자 크기까지 컨테이너 폭에 맞춰 조절하기

레이아웃만 바꾸는 걸로는 부족합니다. 카드 안 제목 글자 크기도 컨테이너 폭에 비례해서 조절해야 진짜 자연스러운 카드 UI가 완성됩니다. 이때 쓰는 것이 컨테이너 기준 길이 단위입니다.

MDN은 컨테이너 기준 길이 단위로 `cqw`·`cqh`(컨테이너 너비·높이의 1%), `cqi`·`cqb`(인라인·블록 크기의 1%), `cqmin`·`cqmax`를 제공한다고 설명합니다. 이 중 카드 UI에서 가장 실용적으로 쓰이는 건 `cqi`(컨테이너 인라인 크기의 1%)입니다. 가로쓰기 환경에서는 `cqi`가 사실상 컨테이너 너비의 1%와 같은 개념으로 동작하기 때문에, `container-type: inline-size`와 궁합이 잘 맞습니다.

```css
.card__title {
font-size: clamp(1rem, 4cqi, 1.5rem);
}
```

이 코드는 제목 글자 크기를 컨테이너 폭의 4%로 설정하되, 최소 1rem 아래로는 작아지지 않고 최대 1.5rem 위로는 커지지 않도록 `clamp()`로 상하한선을 잡아둔 형태입니다. 이렇게 하면 카드가 넓은 메인 목록에 있을 때는 제목이 시원하게 커 보이고, 좁은 사이드바에 있을 때는 자동으로 작아져서 줄 바꿈이나 텍스트 넘침이 발생하지 않습니다.

여기서 반드시 짚어야 할 주의 사항이 있습니다. MDN은 조건에 맞는 컨테이너가 없으면 이 단위들이 작은 뷰포트 단위(`sv*`)로 계산된다고 설명합니다. 즉 `container-type`을 제대로 선언하지 않은 채로 `cqi`를 써버리면, 개발자가 의도한 컨테이너 기준이 아니라 엉뚱하게 뷰포트 기준으로 크기가 계산되어버릴 수 있습니다. 반드시 Step 2에서 다룬 `container-type: inline-size` 선언이 선행되어야 `cqi`가 제대로 동작한다는 점을 기억해두세요.

이미지 영역에도 손을 봐야 합니다. MDN은 이미지에 CSS `aspect-ratio`나 HTML `width`·`height` 속성을 지정하면 로딩 전에 공간과 비율을 예약해 레이아웃 이동을 줄일 수 있다고 안내합니다. 카드가 가로형↔세로형으로 전환될 때 이미지 영역이 갑자기 커지거나 줄어들면서 텍스트가 덜컹거리는 것을 막으려면, 이미지에도 반드시 `aspect-ratio: 16 / 9` 같은 비율 값을 지정해두는 것이 좋습니다.

```css
.card__image {
aspect-ratio: 16 / 9;
object-fit: cover;
}
```

이렇게 레이아웃 전환, 글자 크기, 이미지 비율 예약까지 세 가지를 함께 처리하면 카드가 어떤 폭에 놓이든 콘텐츠가 자연스럽게 재구성되는 진짜 반응형 카드 UI 설계가 완성됩니다.

컨테이너 쿼리가 안 먹힐 때 확인할 것들

컨테이너 쿼리를 적용했는데도 카드 레이아웃이 전혀 바뀌지 않는다면, 가장 먼저 부모 요소에 `container-type` 선언이 빠지지 않았는지부터 확인해야 합니다. 실무에서 발생하는 오류의 대부분은 문법 오류가 아니라 선언 위치 실수입니다.

가장 흔한 오류 패턴을 정리하면 다음과 같습니다.

첫째, `container-type`을 카드 자기 자신에게 선언한 경우입니다.
컨테이너 쿼리는 부모의 크기를 기준으로 자식의 스타일을 바꾸는 구조이기 때문에, 스타일이 바뀌어야 할 요소(카드) 자체에 `container-type`을 걸면 자기 자신을 기준으로 자기 스타일을 바꾸려는 순환 구조가 되어 정상 동작하지 않습니다. 반드시 카드를 감싸는 별도의 부모 요소(`.card-wrapper` 등)에 선언해야 합니다.

둘째, `container-type: size`를 써서 카드 높이가 이상하게 고정되는 경우입니다.
앞서 설명했듯 `size`는 높이 억제가 걸려 콘텐츠 높이만큼 자연스럽게 늘어나지 않을 수 있습니다. 카드 안 텍스트 길이가 가변적이라면 `inline-size`로 바꿔야 합니다.

셋째, 부모 요소에 명시적인 폭이 없어서 컨테이너 크기 자체가 애매한 경우입니다.
`container-type: inline-size`를 선언해도 그 부모가 `width: auto` 상태로 내용에 따라 크기가 정해지는 구조라면, 컨테이너 쿼리가 참조할 안정적인 기준값이 없어 예상과 다르게 동작할 수 있습니다. Grid나 Flex의 트랙·아이템 크기로 폭이 확정되는 구조인지 점검해보세요.

넷째, 이름 없는 쿼리를 썼는데 중첩 컨테이너 구조 때문에 엉뚱한 컨테이너를 참조하는 경우입니다.
Step 3에서 다룬 것처럼, 카드가 여러 겹의 컨테이너 안에 있다면 이름을 붙여서 명시적으로 지목하는 방식으로 바꿔야 합니다.

다섯째, 오래된 브라우저 환경에서 아예 컨테이너 쿼리 자체를 인식하지 못하는 경우입니다.
이 경우는 오류라기보다 지원 범위 밖의 환경이므로, 바로 다음 섹션에서 다룰 `@supports` 기반 대체 구성이 필요합니다.

활용 팁 & 베스트 프랙티스: 카드 외부는 Grid, 내부는 컨테이너 쿼리로 역할 분리하기

카드 UI 설계에서 가장 실전적인 원칙은 "카드 목록의 배치(외부)는 CSS Grid가 맡고, 카드 내부의 반응형 변화는 컨테이너 쿼리가 맡는다"는 역할 분리입니다. 이 둘을 헷갈려서 한쪽에 모든 책임을 몰아넣으면 코드가 금방 복잡해집니다.

카드 목록을 배치할 때 자주 쓰는 패턴이 `repeat(auto-fill, minmax(100px, 1fr))` 형태의 Grid 선언입니다. MDN은 이 문법에서 `auto-fill`이 오버플로가 발생하지 않는 최대 반복 수를 계산하고, `minmax()`의 최소값은 트랙의 최소 크기를 지정한다고 설명합니다.

여기서 실무자들이 자주 혼동하는 게 `auto-fill`과 `auto-fit`의 차이입니다. MDN에 따르면 `auto-fill`은 컨테이너에 들어갈 수 있는 트랙 수를 유지하는 반면, `auto-fit`은 항목 배치 후 비어 있는 트랙을 접는 방식으로 동작합니다. 카드 개수가 적을 때 이 차이가 확실히 드러납니다. `auto-fill`을 쓰면 카드가 몇 개 없어도 빈 트랙 공간이 그대로 남아 카드가 왼쪽에 쏠려 보일 수 있고, `auto-fit`을 쓰면 빈 트랙이 접혀서 남은 카드들이 균등하게 늘어나 채워집니다. 카드가 항상 왼쪽 정렬을 유지해야 하는 갤러리형 레이아웃이라면 `auto-fill`을, 카드 개수와 무관하게 화면을 꽉 채우고 싶다면 `auto-fit`을 선택하는 식으로 상황에 맞게 판단하면 됩니다.

이렇게 Grid로 배치된 각 트랙(칸) 안에 카드 컴포넌트가 들어가고, 그 칸의 실제 폭이 컨테이너 쿼리의 기준이 되는 구조입니다. 즉 Grid가 "이 칸은 지금 180px짜리야"라고 정해주면, 컨테이너 쿼리는 그 180px을 기준으로 카드 내부를 세로형으로 바꿀지 결정하는 식으로 두 기술이 자연스럽게 이어집니다.

컴포넌트 기반 웹제작 환경에서 일하고 있다면, 카드 컴포넌트 자체에는 배치 관련 스타일(`grid-column`, `margin` 등)을 최소화하고 컴포넌트 내부 반응형은 전적으로 컨테이너 쿼리에 맡기는 방식을 권해드립니다. 이렇게 하면 같은 카드 컴포넌트를 메인 목록, 사이드바, 모달, 대시보드 위젯 어디에 재사용해도 코드 수정 없이 각 위치에 맞게 알아서 재구성됩니다.

응용·확장: 미지원 환경 대비 @supports 기반 대체 구성 만들기

컨테이너 쿼리 지원 비율이 94.87%(2026년 9월 27일 caniuse.com 확인 기준)로 높다고 해도, 나머지 환경까지 챙기려면 대체 구성을 함께 준비해두는 것이 안전합니다. 이때 쓰는 것이 `@supports`입니다.

MDN에 따르면 `@supports`는 CSS 기능 지원 여부를 검사하고, `@media`는 실행 환경이나 뷰포트·기기 특성을 검사합니다. 이 차이를 활용하면 컨테이너 쿼리 미지원 환경에는 Grid·Flex 기본 레이아웃과 미디어 쿼리 등의 대체 구성을 둘 수 있습니다.

기본 전략은 이렇습니다. 먼저 컨테이너 쿼리 없이도 무너지지 않는 기본 카드 레이아웃(Flex 기반 세로형 정도)을 깔아두고, `@supports (container-type: inline-size)` 조건이 참일 때만 컨테이너 쿼리 기반의 정교한 전환 로직을 덧씌우는 방식입니다.

```css
.card {
display: flex;
flex-direction: column;
}

@supports (container-type: inline-size) {
.card-wrapper {
container-type: inline-size;
}

@container (min-width: 400px) {
.card {
flex-direction: row;
}
}
}
```

이 구조의 장점은 컨테이너 쿼리를 지원하지 않는 극소수 환경에서도 카드가 아예 깨지지 않고, 최소한 세로형으로라도 안정적으로 보인다는 점입니다. `container-type`이 대부분의 주요 브라우저에서 2023년 2월부터 널리 지원되는 기능으로 분류된다는 점을 감안하면, 실무에서는 이 대체 구성이 정말 예외적인 상황을 위한 안전망 역할에 가깝습니다.

미디어 쿼리를 완전히 배제하지 않고 이렇게 이중 안전망으로 남겨두는 것은 반응형 웹디자인의 견고성을 높이는 방법이기도 합니다. 페이지 레벨의 큰 레이아웃 전환(예: 특정 화면 폭 이하에서 사이드바 자체를 숨기는 결정)은 여전히 미디어 쿼리가 담당하고, 그 안의 개별 카드 컴포넌트 재구성은 컨테이너 쿼리가 담당하는 계층 구조로 이해하면 헷갈리지 않습니다.

또한 MDN이 언급한 스타일 쿼리·스크롤 상태 쿼리 같은 다른 컨테이너 쿼리 유형도 존재하지만, 카드 반응형 설계에 실질적으로 필요한 것은 이 글에서 다룬 크기 쿼리 하나면 충분합니다. 확장이 필요할 때 참고 정도로만 알아두면 됩니다.

점검 체크리스트: 배포 전 마지막으로 확인할 6가지

카드 UI를 실제로 배포하기 전에 아래 항목들을 순서대로 점검해보세요.

① 카드를 감싸는 부모 요소에 `container-type: inline-size`를 정확히 선언했는지 확인
② 카드 자체가 아니라 부모에 선언했는지 재확인 (자기 자신 선언은 동작하지 않음)
③ 중첩 컨테이너 구조라면 이름 있는 컨테이너(`container-name` 또는 축약형)로 명시했는지 확인
④ `@container` 조건의 `min-width` 기준값이 실제 카드 디자인과 맞는지 확인
⑤ 제목에 `cqi` 단위와 `clamp()`를 적용해 극단적으로 작거나 크게 깨지지 않는지 확인
⑥ 이미지에 `aspect-ratio` 또는 `width`·`height`를 지정해 레이아웃 이동을 예방했는지 확인

여기에 더해 `@supports` 기반 대체 구성을 넣어뒀다면, 개발자 도구에서 컨테이너 쿼리를 강제로 비활성화한 상태로도 한 번 확인해보는 것을 권해드립니다. 대체 레이아웃이 실제로 카드 형태를 유지하는지 눈으로 직접 보는 것이 가장 확실합니다.

자주 묻는 질문 FAQ

Q1. 컨테이너 쿼리를 도입하면 기존 미디어 쿼리 코드를 다 지워야 하나요?
아니요. 페이지 전체의 큰 레이아웃 전환(사이드바 표시 여부, 헤더 높이 조정 등)은 여전히 미디어 쿼리가 적합합니다. 재사용되는 개별 컴포넌트, 특히 카드처럼 여러 위치에 배치되는 요소의 내부 반응형만 컨테이너 쿼리로 옮기는 것이 합리적인 접근입니다.

Q2. container-type: size와 inline-size 중 뭘 써야 할지 모르겠어요.
텍스트 길이가 가변적이고 콘텐츠에 따라 카드 높이가 자연스럽게 늘어나야 하는 일반적인 카드라면 `inline-size`를 권해드립니다. `size`는 높이 억제가 걸려 내용 높이로 늘어나지 않을 수 있어, 높이가 고정된 특수한 레이아웃에만 제한적으로 고려해볼 만합니다.

Q3. 컨테이너 쿼리를 지원하지 않는 브라우저 사용자는 얼마나 되나요?
2026년 9월 27일 caniuse.com 확인 기준 지원 브라우저의 전 세계 사용 비율은 94.87%입니다. 나머지 소수 환경을 위해서는 `@supports`로 검사해 Grid·Flex 기본 레이아웃과 미디어 쿼리 조합의 대체 구성을 마련해두는 것이 안전합니다.

Q4. auto-fill과 auto-fit 중 카드 목록에는 뭐가 더 나은가요?
카드 개수가 적어도 항상 왼쪽 정렬을 유지하고 싶다면 `auto-fill`, 카드 개수와 무관하게 남은 공간을 카드들이 균등하게 채우길 원한다면 `auto-fit`이 적합합니다. 정답이 정해진 게 아니라 디자인 의도에 따라 선택하는 문제입니다.

Q5. 이름 없는 컨테이너 쿼리는 언제 써도 괜찮나요?
카드 구조가 단순하고 부모 컨테이너가 하나뿐인 환경이라면 이름 없는 쿼리로도 충분합니다. 다만 여러 겹의 컨테이너가 중첩되는 복잡한 컴포넌트 기반 웹제작 환경이라면 처음부터 이름 있는 컨테이너로 명시하는 것이 나중에 겪을 디버깅 부담을 줄여줍니다.

---

지금까지 카드 UI가 배치 위치에 따라 깨지는 근본 원인과, `container-type` 선언부터 `@container` 조건 분기, `cqi` 단위 활용, 미지원 환경 대체 구성까지 전체 흐름을 정리했습니다. 카드 목록의 외부 배치는 CSS Grid에, 카드 내부의 반응형 변화는 컨테이너 쿼리에 역할을 나눠 맡기는 설계 원칙만 기억해두면, 앞으로 어떤 위치에 카드를 재배치하더라도 흔들림 없는 결과를 얻으실 수 있을 겁니다.

더 깊은 내용은 MDN의 컨테이너 쿼리 공식 문서(developer.mozilla.org)와 web.dev의 반응형 디자인 아티클을 참고하시면 도움이 됩니다.