Z-index가 내 마음대로 움직이지 않는 이유: 쌓임 맥락(Stacking Context)의 마법

 

웹 프론트엔드 개발을 하다 보면 누구나 한 번쯤은 z-index: 9999를 부여했는데도 특정 요소가 화면 뒤로 숨어버리는 당혹스러운 경험을 합니다. "숫자가 더 큰데 왜 안 올라오지?"라는 의문이 든다면, 여러분은 CSS의 가장 오해받기 쉬운 개념 중 하나인 **쌓임 맥락(Stacking Context)**의 늪에 빠진 것입니다.

오늘은 단순히 숫자 싸움이 아닌, 브라우저가 요소를 렌더링하는 3차원적인 원리를 심도 있게 파헤쳐 보겠습니다.

---

1. 서론: 왜 단순한 숫자만으로는 부족할까?

HTML은 기본적으로 2차원 평면 구조를 가지지만, 사용자에게 보여질 때는 z축이라는 깊이 개념이 추가됩니다. 브라우저는 어떤 요소가 더 앞에 보일지 결정하기 위해 **화가 알고리즘(Painter's Algorithm)**을 사용합니다. 먼저 그려진 것이 뒤에 깔리고, 나중에 그려진 것이 위에 덮어씌워지는 방식이죠.

하지만 현대의 복잡한 UI에서는 단순히 코드 순서만으로 층위를 결정할 수 없습니다. 이때 등장하는 것이 바로 **쌓임 맥락(Stacking Context)**입니다. 이는 요소를 묶는 '가상의 레이어 그룹'이라고 이해하면 쉽습니다. 특정 그룹 안에 속한 요소는 아무리 z-index가 높아도, 그룹 자체가 뒤에 있다면 절대로 앞으로 나올 수 없습니다.

---

2. 핵심 개념: 쌓임 맥락(Stacking Context) Deep Dive

계급 체계로 이해하는 비유

쌓임 맥락을 **'아파트 단지'**에 비유해 봅시다.

• A 아파트 10층에 사는 사람과 B 아파트 1층에 사는 사람이 있습니다.
• 만약 B 아파트 자체가 A 아파트보다 앞 동에 위치한다면, B 아파트 1층 사람이 A 아파트 10층 사람보다 우리 눈에 더 가깝게 보입니다.
• 여기서 각 '아파트 동'이 쌓임 맥락이고, '층수'가 z-index입니다. 옆 동의 층수가 아무리 높아도 우리 동 자체가 뒤에 있으면 소용없는 것과 같습니다.

쌓임 맥락이 생성되는 조건

브라우저가 "아, 여기서부터는 새로운 레이어 그룹을 만들어야겠군!"이라고 판단하는 기준은 다음과 같습니다:

1. position이 absolute나 relative이면서 z-index가 auto가 아닐 때.
2. position: fixed 또는 sticky일 때.
3. opacity 값이 1보다 작을 때.
4. transform, filter, perspective 속성이 적용되었을 때.
5. flex나 grid 컨테이너의 자식 요소에 z-index가 설정되었을 때.

---

3. 실전 예제: 쇼핑몰 장바구니 레이어 문제

이커머스 사이트에서 상품 상세 페이지의 '상단 네비게이션'과 '우측 퀵 메뉴'가 겹치는 상황을 가정해 코드를 짜보겠습니다.

HTML

 

<div class="header-wrapper">
  <header class="navbar">
    <h1>My Shop</h1>
    <div class="dropdown">장바구니 미리보기 (z-index: 100)</div>
  </header>
</div>

<div class="main-content">
  <aside class="quick-menu">퀵 메뉴 (z-index: 10)</aside>
</div>

CSS

 

/* CSS 비즈니스 로직 */
.header-wrapper {
  position: relative;
  z-index: 1; /* 새로운 쌓임 맥락 생성! */
  opacity: 0.99; /* 의도치 않게 맥락을 형성하는 흔한 실수 */
}

.navbar .dropdown {
  position: absolute;
  top: 50px;
  right: 0;
  z-index: 100; /* 엄청 높은 숫자 부여 */
  background: yellow;
}

.main-content {
  position: relative;
  z-index: 2; /* header-wrapper보다 높음 */
}

.quick-menu {
  position: sticky;
  top: 20px;
  z-index: 10; /* 드롭다운(100)보다 낮은 숫자 */
  background: cyan;
}

💡 왜 드롭다운이 퀵 메뉴 뒤로 숨을까?

위 코드에서 .dropdown의 z-index는 100이고, .quick-menu는 10입니다. 하지만 실제 화면에서는 퀵 메뉴가 드롭다운을 가립니다. 그 이유는 부모인 .header-wrapper가 형성한 쌓임 맥락의 z-index가 1인 반면, .main-content의 z-index가 2이기 때문입니다. 드롭다운은 자기가 속한 '1번 아파트'를 벗어날 수 없습니다.

---

4. 트러블슈팅: z-index가 먹히지 않을 때 체크리스트

만약 z-index가 의도대로 작동하지 않는다면 다음 3단계를 점검하세요.

1. 부모 요소의 쌓임 맥락 확인: 부모 중 opacity, transform, filter 등이 적용된 요소가 있는지 확인하세요. 만약 있다면 그 부모가 새로운 기준점이 됩니다.
2. Position 속성 확인: z-index는 static이 아닌 position(relative, absolute, fixed, sticky)에서만 동작합니다.
3. 형제 요소 간의 우선순위: 문제가 되는 두 요소의 공통 조상을 찾아 올라가서, 어느 시점에서 쌓임 맥락이 갈라지는지 파악하세요.

Tip: Chrome 개발자 도구의 'Layers' 패널을 활용하면 현재 페이지의 3D 레이어 구조를 시각적으로 확인하며 디버깅할 수 있습니다.

---

5. 장단점 및 고려사항 (Trade-offs)

쌓임 맥락을 강제로 만드는 것은 해결책인 동시에 잠재적 위험 요소입니다.

• 장점: 특정 컴포넌트 내부의 z-index를 격리시켜, 외부 요소와의 번호 경쟁을 방지할 수 있습니다(캡슐화).
• 단점: 무분별하게 생성된 쌓임 맥락은 나중에 모달(Modal)이나 툴팁(Tooltip)을 띄울 때 "전역 최상단"으로 올리는 것을 불가능하게 만듭니다.

대안: 전역 모달처럼 항상 최상단에 위치해야 하는 요소는 DOM 구조상 가장 하단(body 바로 위)에 배치하거나, React의 Portal 같은 기술을 사용하여 쌓임 맥락의 간섭을 피하는 것이 현명합니다.

---

6. 결론 및 요약

z-index는 절대적인 숫자가 아니라 상대적인 서열입니다.

1. 쌓임 맥락은 요소를 묶는 독립적인 층위다.
2. 하위 맥락의 요소는 상위 맥락의 z-index를 추월할 수 없다.
3. 숫자를 높이기 전에, 내가 지금 어느 '맥락' 안에서 싸우고 있는지 먼저 파악하라.

복잡한 레이아웃을 설계할 때 여러분만의 z-index 관리 전략은 무엇인가요? 단순히 9999를 남발하는 대신, 프로젝트 전체의 레이어 시스템을 정의해 보는 것은 어떨까요?

더 궁금한 점이 있다면 브라우저 렌더링 엔진의 합성(Compositing) 과정을 살펴보는 것도 큰 도움이 될 것입니다.