엘리베이션(Elevation) 완전 해부 — KRDS 공식 기준

어느 공공 사이트에서 신청서를 작성하다 화면 한가운데에 팝업이 떠오른 적 있으실 겁니다. 동의 여부를 묻는 창이거나, "정말 삭제하시겠습니까" 같은 확인 창. 그런데 어떤 사이트의 팝업은 분명히 "위에 떠 있는" 느낌이 들고, 어떤 사이트의 팝업은 뒤 배경과 뒤엉켜서 "이게 새 창인지 그냥 같은 화면의 일부인지" 헷갈립니다. 같은 팝업인데 왜 이런 차이가 날까요. 답은 의외로 단순합니다. 한쪽은 그림자를 제대로 줘서 화면에서 한 단계 떠올렸고, 다른 한쪽은 그러지 않았거든요.

우리는 평소에 그림자를 거의 의식하지 않습니다. 그런데 그림자가 사라지면 그제야 그 존재를 압니다. 카드가 배경에 납작하게 붙어 버리고, 떠 있어야 할 팝업이 본문에 파묻히고, 드롭다운이 그 아래 내용과 구분되지 않습니다. 그림자는 "있을 때는 모르다가 없을 때 비로소 느껴지는" 종류의 디자인 요소입니다. 그리고 바로 그래서, 가장 자주 대충 다뤄지는 영역이기도 합니다.

엘리베이션(Elevation)은 이 "그림자로 만드는 위계"를 다루는 디자인 시스템의 한 축입니다. 화면은 평평한 2차원이지만, 우리는 그 위에 그림자라는 장치를 얹어서 "이건 위에 떠 있는 것, 저건 바닥에 붙은 것"이라는 깊이의 질서를 만듭니다. KRDS(대한민국 정부 디자인 시스템)는 이 엘리베이션을 디자이너의 감각에만 맡기지 않고, 스타일 가이드의 한 항목으로 정리해 두었습니다. 오늘은 그 KRDS 엘리베이션 기준을 하나하나 뜯어보고, 공공웹이 어디서 자주 무너지는지, 그리고 우리 사이트가 그 기준을 지키고 있는지 어떻게 확인하는지까지 차근차근 보겠습니다.

미리 한 가지만 일러두면, 이 글에서 말하는 "엘리베이션을 제대로 쓴다"는 건 "그림자를 더 진하고 멋지게 넣는다"가 아닙니다. 오히려 반대입니다. 정해진 단계만큼만, 정해진 곳에만, 정해진 모양으로 그림자를 쓰는 절제의 기술에 가깝습니다. 그림자를 아무 데나 마구 뿌리면, 화면 전체가 둥둥 떠다니는 것처럼 보여서 오히려 위계가 사라집니다. 잘 쓴 엘리베이션은 "여기가 중요해" 하고 딱 필요한 곳만 한 단계 들어 올려 사용자의 시선을 안내합니다. 그게 핵심입니다.

엘리베이션이 대체 뭘까 — 정의부터 정확히

먼저 용어부터 맞추겠습니다. 엘리베이션(Elevation)은 단어 그대로 "고도", "높이"라는 뜻입니다. 디자인 시스템에서는 화면 위 요소들이 가지는 시각적 높이의 차이를 가리킵니다. 화면은 물리적으로는 평평하지만, 우리는 거기에 가상의 z축(깊이 축)을 상상합니다. 본문 텍스트는 바닥(z=0)에 붙어 있고, 카드는 그보다 약간 떠 있고, 드롭다운은 그보다 더 떠 있고, 팝업(모달)은 가장 높이 떠 있는 식이죠.

이 "떠 있음"을 시각적으로 표현하는 가장 흔한 수단이 바로 그림자(shadow)입니다. 물리 세계에서 물건이 바닥에서 떨어져 있으면 그 아래에 그림자가 생기듯, 화면에서도 그림자를 통해 "이 요소가 다른 것들보다 위에 있다"는 신호를 줍니다. 그림자가 옅고 작으면 살짝 떠 있는 느낌, 그림자가 넓고 부드럽게 퍼지면 높이 떠 있는 느낌. 그래서 엘리베이션은 종종 "그림자 스타일"과 거의 같은 말처럼 쓰입니다.

다만 그림자만이 엘리베이션의 전부는 아닙니다. 깊이를 표현하는 다른 방법도 있습니다.

• 그림자(Drop Shadow): 가장 직관적인 방법. 요소 아래·주변에 부드러운 음영을 줘서 떠 있는 느낌을 만듭니다.
• 레이어 순서(z-index / 겹침): 어떤 요소가 다른 요소를 가리는지로 위아래를 표현합니다. 팝업이 본문을 덮으면, 사용자는 자연스럽게 팝업이 더 위에 있다고 인지합니다.
• 배경 딤(dim/scrim): 모달이 떴을 때 뒤 배경을 어둡게 깔아, 앞의 요소를 더 도드라지게 합니다. 이것도 넓은 의미의 깊이 표현입니다.
• 테두리·면 분리: 그림자 대신(또는 함께) 옅은 테두리나 면 색 차이로 영역을 구분하기도 합니다.

KRDS의 엘리베이션 기준은 이 중 주로 "그림자를 단계별로 정의하고, 어떤 컴포넌트에 어느 단계를 쓸지 정해 두는 것"을 다룹니다. 핵심은 단계화(leveling)입니다. 그림자를 자유롭게 그리는 게 아니라, 미리 정의된 몇 개의 단계 중에서 골라 쓰는 거죠.

왜 "단계"로 나눠 두나

여기서 디자인 토큰(design token)이라는 개념이 등장합니다. 토큰은 색·간격·서체·그림자 같은 디자인 값을 "이름이 붙은 변수"로 정리해 둔 것입니다. 색에 primary, secondary 같은 이름을 붙이듯, 그림자에도 단계별로 이름을 붙입니다. 예를 들어 "낮은 단계 그림자", "중간 단계 그림자", "높은 단계 그림자"처럼요.

이렇게 토큰으로 정리해 두면 두 가지가 좋아집니다. 첫째, 개발자가 매번 box-shadow: 0 2px 4px rgba(0,0,0,0.1) 같은 값을 손으로 정하지 않고, 정해진 토큰을 가져다 쓰면 됩니다. 둘째, 사이트 전체에서 그림자가 일관됩니다. A 페이지의 카드와 B 페이지의 카드가 똑같은 깊이로 떠 있게 되죠. KRDS가 엘리베이션을 스타일 가이드의 한 항목으로 정리한 이유가 정확히 이겁니다 — 그림자를 감각이 아니라 시스템으로 다루기 위해서.

KRDS는 엘리베이션에 무엇을 요구하나 — 기준 완전 해부

이제 본론입니다. KRDS 가이드라인(디지털 정부서비스 UI/UX 가이드라인, 2025.08판)의 스타일 항목과 컴포넌트 문서를 기준으로, 엘리베이션이 충족해야 하는 요건을 영역별로 정리하겠습니다. 한 가지 미리 양해를 구하면, 그림자의 정확한 픽셀 값(흐림 반경, 오프셋, 투명도 등)은 KRDS 공식 자료에 정의된 값을 직접 확인하는 게 가장 정확합니다. 이 글에서는 그 구체 수치를 임의로 지어내지 않고, "어떤 원칙과 구조로 정의돼 있는가"를 중심으로 설명하겠습니다.

1) 그림자는 단계(level)로 정의된다

엘리베이션의 첫 번째 요건은, 그림자를 자유롭게 쓰는 게 아니라 정해진 몇 개의 단계 안에서 고르는 것입니다. 디자인 시스템마다 보통 3~5개 정도의 깊이 단계를 둡니다. 낮은 단계는 살짝 떠 있는 요소(예: 평상시 카드)에, 높은 단계는 화면 위로 확실히 떠올라야 하는 요소(예: 모달, 드롭다운)에 씁니다.

이 단계화가 왜 중요하냐면, 깊이에도 "질서"가 있어야 하기 때문입니다. 모든 요소가 제각각의 그림자를 갖고 있으면, 사용자는 무엇이 무엇보다 위에 있는지 직관적으로 알 수 없습니다. 반대로 단계가 정해져 있으면, "이 정도 그림자면 카드 수준, 저 정도면 팝업 수준"이라는 약속이 화면 전체에 일관되게 적용됩니다. 마치 건물의 층처럼, 1층·2층·3층이 명확하면 위아래 관계가 헷갈리지 않는 것과 같습니다.

2) 깊이 단계와 의미가 짝지어져야 한다

그냥 단계를 나누는 것에서 끝나지 않습니다. 어떤 컴포넌트가 어느 단계에 속하는지가 정해져 있어야 합니다. 일반적으로 깊이가 깊을수록(=높이 떠 있을수록) "임시적이고, 사용자의 주목을 강하게 요구하며, 다른 것을 덮는" 성격을 가집니다.

• 바닥(가장 낮음): 본문, 기본 배경. 그림자 없음. 화면의 토대입니다.
• 낮은 단계: 평상시의 카드, 정보 박스. 살짝 떠서 "묶인 영역"임을 알립니다.
• 중간 단계: 사용자가 상호작용할 때 떠오르는 것들. 호버된 카드, 드롭다운 메뉴, 툴팁.
• 높은 단계: 화면 전체의 흐름을 잠시 멈추고 주목을 요구하는 것. 모달(팝업), 다이얼로그.
• 가장 높음(필요 시): 알림 토스트, 시스템 메시지처럼 모든 것 위에 잠깐 나타나는 요소.

이 위계가 의미와 맞아떨어져야 사용자가 직관적으로 "아, 이건 잠깐 뜬 임시 창이구나" 하고 알 수 있습니다. 모달을 카드와 똑같은 낮은 그림자로 띄우면, 사용자는 그게 화면을 덮은 팝업인지 그냥 본문 중간의 한 영역인지 구분하지 못합니다.

3) 상태에 따라 깊이가 바뀐다

엘리베이션은 정적인 값이 아닙니다. 사용자의 행동에 따라 요소의 깊이가 변하는 게 자연스럽습니다. 가장 흔한 예가 호버(hover)입니다. 클릭 가능한 카드에 마우스를 올리면 살짝 더 떠오르는(그림자가 조금 깊어지는) 효과를 주면, 사용자는 "아, 이건 누를 수 있는 거구나" 하고 직감합니다.

마찬가지로 버튼을 누르는 순간(active/pressed)에는 오히려 살짝 가라앉는(그림자가 옅어지는) 표현을 쓰기도 합니다. 실제로 물리적 버튼을 누르면 들어가듯이요. 이런 상태별 깊이 변화는 사용자에게 "지금 내 행동이 시스템에 닿고 있다"는 피드백을 줍니다. 다만 여기서도 절제가 필요합니다. 너무 과한 깊이 변화는 화면이 들썩거리는 느낌을 줘서 오히려 어지럽습니다.

4) 그림자는 일관된 광원(光源)을 가정한다

물리 세계의 그림자는 빛의 방향에 따라 생깁니다. 빛이 위에서 비치면 그림자는 아래로 떨어지죠. 디자인 시스템의 그림자도 마찬가지로, 하나의 일관된 광원 방향을 가정하고 만들어집니다. 보통 "위에서 약간 비추는 빛"을 가정해서, 그림자가 요소의 아래쪽에 살짝 더 짙게 깔리도록 합니다.

이게 왜 중요하냐면, 한 화면 안에서 어떤 그림자는 아래로, 어떤 그림자는 위로, 어떤 건 오른쪽으로 떨어지면 화면이 어색해지기 때문입니다. 우리 뇌는 무의식적으로 "빛은 한 방향에서 온다"고 가정하는데, 그 가정이 깨지면 그림자가 "잘못됐다"고 느낍니다. 명확히 설명은 못 해도 "뭔가 이상하다"는 인상을 받죠. KRDS가 그림자 토큰을 정의할 때 일관된 광원을 전제하는 이유입니다.

5) 깊이는 색·대비와 충돌하지 않아야 한다

그림자도 결국 색입니다. 보통 검정에 투명도를 준 형태죠. 그런데 이 그림자가 너무 진하면, 그 위에 얹힌 텍스트나 주변 요소의 대비를 해칠 수 있습니다. 특히 어두운 배경에서는 검정 그림자가 거의 보이지 않거나, 반대로 밝은 요소 주변에 너무 강한 음영을 만들어 시각적 잡음이 됩니다.

엘리베이션은 단독으로 존재하지 않고 색·대비 같은 다른 스타일 요소와 함께 작동합니다. 그래서 그림자를 정의할 때도 "이 그림자가 텍스트 가독성을 해치지 않는가", "배경색과 어울리는가"를 함께 봐야 합니다. KRDS의 스타일 가이드가 색·타이포·간격·엘리베이션을 한 묶음으로 다루는 건, 이들이 따로 노는 게 아니라 서로 맞물려 화면을 만들기 때문입니다.

6) 그림자는 정보를 "대체"하지 않는다 — 접근성 관점

여기가 의외로 자주 놓치는 지점입니다. 그림자는 시각적 신호입니다. 즉 눈으로 보는 사람에게만 작동하는 정보예요. 시각장애인이 스크린리더로 화면을 들을 때, 그림자는 아무 의미가 없습니다. 그림자는 "들리지" 않으니까요.

그래서 엘리베이션으로 어떤 중요한 의미를 전달할 때는, 반드시 그것이 코드 구조로도 표현돼 있어야 합니다. 예를 들어 "이건 떠 있는 팝업이다"라는 의미를 그림자로만 표현하면 안 되고, 코드 수준에서 그게 모달(role="dialog" 등)이라고 선언돼 있어야 스크린리더 사용자도 "지금 대화상자가 열렸다"는 걸 압니다. 즉, 그림자는 보조 신호이지 유일한 신호가 아니어야 합니다. 깊이로 전달하려는 정보가 있으면, 그 정보는 코드로도 한 번 더 전달돼야 한다는 게 핵심 원칙입니다.

이건 색에만 의존하지 않기 원칙(색 구분이 어려운 사용자를 위해 색 외의 신호도 주기)과 같은 맥락입니다. 그림자도 색처럼, "그것만으로 의미를 전달하면 누군가는 그 의미를 못 받는다"는 한계가 있습니다.

7) 절제 — 그림자 인플레이션을 경계하라

마지막 요건은 역설적이게도 "적게 쓰라"는 것입니다. 그림자가 위계를 만든다는 건, 바꿔 말하면 모든 게 떠 있으면 아무것도 안 떠 있는 것과 같다는 뜻입니다. 카드도 떠 있고, 버튼도 떠 있고, 입력창도 떠 있고, 본문 영역까지 그림자를 두르면, 화면 전체가 둥둥 떠다니는 잡탕이 됩니다. 이걸 흔히 "그림자 인플레이션"이라고 부릅니다.

좋은 엘리베이션은 꼭 필요한 곳에만 깊이를 줍니다. 사용자의 주목을 끌어야 하는 요소, 다른 것을 덮는 요소, 상호작용 가능한 요소에만요. 나머지는 바닥에 두는 게 맞습니다. 그래야 떠 있는 것이 진짜로 떠 보입니다. KRDS가 단계를 제한적으로 두고, 컴포넌트별로 적용 단계를 정해 둔 것 자체가 "마구 쓰지 말라"는 절제의 장치입니다.

정리하면, KRDS의 엘리베이션 기준은 크게 세 축입니다. ① 단계화(그림자를 정해진 몇 개 단계로 정의), ② 의미 연결(깊이 단계와 컴포넌트의 성격을 짝짓기), ③ 절제와 일관성(꼭 필요한 곳에만, 같은 광원·같은 토큰으로). 그리고 여기에 접근성 원칙 하나가 더 붙습니다 — 그림자는 보조 신호이지 유일한 신호가 아니다. 이 축들은 그대로 ViewCheck가 디자인 시스템을 판정하는 기준의 일부이기도 합니다.

왜 이렇게까지 따지나 — 원리와 배경

여기까지 읽고 "그림자 하나에 뭐 이리 까다롭나" 싶으실 수 있습니다. 그런데 엘리베이션 요건들은 누가 괜히 만들어 낸 규칙이 아니라, 실제 사용자가 화면을 "어떻게 읽는가"에서 역으로 도출된 것들입니다.

사람은 그림자로 "깊이"를 읽는다

우리 뇌는 2차원 화면을 볼 때도 자동으로 3차원으로 해석하려 합니다. 진화적으로 우리는 실제 입체 세계에서 살아왔기 때문에, 그림자를 보면 무의식적으로 "이건 떠 있다", "이건 붙어 있다"를 판단합니다. 이건 배워서 아는 게 아니라 거의 본능에 가깝습니다.

디자인은 이 본능을 활용합니다. 모달에 큰 그림자를 주면, 사용자는 "설명을 읽기도 전에" 그것이 화면 위에 떠오른 임시 창이라는 걸 직감합니다. 카드에 옅은 그림자를 주면 "이 영역은 하나로 묶인 단위구나" 하고 알아챕니다. 이 직감을 잘 활용하면, 긴 설명 없이도 화면 구조를 사용자에게 전달할 수 있습니다. 엘리베이션은 말하자면 "말없이 위계를 설명하는 시각 언어"입니다.

위계가 곧 사용성이다

화면에는 항상 위계가 있습니다. 더 중요한 것과 덜 중요한 것, 지금 해야 할 것과 나중에 봐도 되는 것. 사용자는 이 위계를 단서로 삼아 "어디를 먼저 봐야 하는지"를 정합니다. 엘리베이션은 이 위계를 만드는 강력한 도구입니다.

예를 들어 "정말 삭제하시겠습니까" 확인 창이 본문과 같은 평면에 납작하게 놓여 있으면, 사용자는 그게 지금 당장 답해야 하는 질문인지 인식하지 못하고 그냥 지나칠 수 있습니다. 반면 그 창이 화면 위로 확 떠오르고 뒤 배경이 어두워지면, "아, 이건 지금 답해야 하는 거구나" 하고 즉시 압니다. 위계가 분명하면 사용자는 헤매지 않습니다. 그리고 공공 서비스에서 사용자가 헤매지 않는다는 건, 민원을 끝까지 완결한다는 뜻입니다.

공공 서비스는 "헤맬 여유"가 없는 사람들이 쓴다

상업 사이트는 사용자가 헤매다 지치면 떠나면 그만입니다. 그런데 공공 서비스는 다릅니다. 주민등록 등본을 떼거나, 지원금을 신청하거나, 세금을 내는 일은 그 사이트가 아니면 할 수 없습니다. 그리고 그 사용자 중에는 디지털에 익숙하지 않은 고령층, 인지적 도움이 필요한 분들이 많습니다.

이런 사용자에게 화면의 위계가 모호하면, 그건 단순한 불편이 아니라 "어디를 눌러야 할지 모르겠는" 막막함이 됩니다. 떠 있어야 할 팝업이 본문에 파묻혀 있으면, 그 팝업의 "확인" 버튼을 못 찾아서 신청을 못 끝낼 수도 있습니다. 엘리베이션을 제대로 쓰는 건 "예쁜 화면"의 문제가 아니라, "헤매지 않는 화면"의 문제입니다. 가장 도움이 필요한 사용자일수록 명확한 위계의 혜택을 가장 크게 받습니다.

일관성이 곧 학습 비용 절감

KRDS가 엘리베이션을 토큰으로 표준화하는 또 다른 이유는 일관성입니다. 정부 사이트마다 그림자가 제각각이면, 사용자는 사이트를 옮길 때마다 "여기선 떠 있는 게 뭐지?"를 다시 익혀야 합니다. 모든 공공 서비스의 깊이 위계가 같은 방식으로 작동하면, 한 번 익힌 "이 정도 그림자면 누를 수 있는 거"라는 감각이 모든 사이트에서 통합니다. 디지털 약자에게 이 "다시 안 배워도 됨"은 생각보다 큰 배려입니다. 표준화는 디자이너의 자유를 뺏는 게 아니라, 사용자의 인지 부담을 덜어 주는 일입니다.

작은 스타일일수록 방치되기 쉽다

역설적이지만, 엘리베이션처럼 "작고 미묘한" 스타일일수록 품질 관리에서 밀려납니다. 색이나 글꼴은 그래도 눈에 확 띄니 다들 신경 쓰지만, 그림자는 "있는 듯 없는 듯"해서 아무도 깐깐하게 보지 않거든요. 그래서 개발 막판에 "대충 box-shadow 하나 넣자"로 처리되기 일쑤입니다. 그런데 바로 그 미묘함이 화면의 완성도를 가릅니다. 그림자가 일관되고 절제된 화면은 "정돈됐다"는 인상을 주고, 제각각인 화면은 설명하기 어렵게 "어수선하다"는 느낌을 줍니다. 가장 덜 주목받는 스타일이 사실은 화면 전체의 신뢰감을 좌우하는 셈입니다.

공공 사이트가 자주 틀리는 지점 — 그리고 올바른 예

이제 현업에서 실제로 반복되는 엘리베이션 실수들을 보겠습니다. 모두 익명화한 일반적 사례입니다(특정 기관을 지목하지 않습니다).

실수 1) 모달인데 안 떠 보인다 — 깊이 없는 팝업

가장 치명적인 실수입니다. 동의 창이나 확인 창 같은 모달을 띄우는데, 그림자도 없고 배경 딤도 없어서 본문과 같은 평면에 납작하게 놓입니다. 사용자는 그게 "지금 답해야 하는 팝업"인지, 그냥 화면 중간에 끼어든 한 영역인지 구분하지 못합니다.

• 나쁜 예: 흰 박스 하나가 본문 위에 그냥 얹혀 있음. 그림자 없음, 뒤 배경 그대로. 본문 글자와 팝업 글자가 뒤섞여 보임. 사용자는 "여기 뭐가 바뀐 거지?" 하고 멈칫.
• 올바른 예: 모달에 높은 단계의 그림자를 주고, 뒤 배경을 어둡게 딤 처리. 화면의 흐름이 잠시 멈추고 팝업에 시선이 집중됨. 코드 수준에서도 role="dialog"로 선언해 스크린리더에도 "대화상자 열림"이 전달됨.

실수 2) 그림자 인플레이션 — 다 떠 있어서 아무것도 안 떠 있다

모든 요소에 그림자를 둘러 버립니다. 카드도, 버튼도, 입력창도, 심지어 본문 박스까지. 디자이너가 "그림자 주면 고급스러워 보여"라는 생각으로 곳곳에 뿌린 경우죠.

• 나쁜 예: 화면 전체가 둥둥 떠다니는 느낌. 무엇이 더 중요한지, 무엇을 눌러야 하는지 위계가 사라짐. 시각적으로 어수선하고 피로함.
• 올바른 예: 떠야 할 것(모달·드롭다운·상호작용 카드)에만 그림자를 주고, 나머지는 바닥에 둠. 떠 있는 것이 진짜로 도드라져 보임. "절제가 곧 위계"라는 원칙 적용.

실수 3) 제각각인 그림자 — 일관성 붕괴

같은 종류의 카드인데 페이지마다, 심지어 같은 페이지 안에서도 그림자가 다릅니다. 어떤 카드는 옅고, 어떤 카드는 진하고, 어떤 건 오른쪽으로, 어떤 건 아래로 떨어집니다. 개발자가 그때그때 손으로 box-shadow 값을 정한 결과입니다.

• 나쁜 예: 같은 "공지 카드"가 메인에선 옅은 그림자, 목록 페이지에선 진한 그림자. 광원 방향도 제각각. 통일감이 없어 "급하게 만든 사이트" 같은 인상.
• 올바른 예: 엘리베이션 토큰을 정의해 두고, 같은 컴포넌트는 같은 토큰을 참조. 사이트 전체에서 카드의 깊이가 동일. KRDS 표준 토큰을 쓰면 다른 정부 사이트와도 일관.

실수 4) 광원 방향이 뒤죽박죽

한 화면 안에서 어떤 그림자는 아래로, 어떤 건 위로, 어떤 건 사방으로 균일하게 퍼집니다. 빛이 한 방향에서 온다는 자연스러운 가정이 깨져서, 보는 사람이 무의식적으로 "뭔가 어색하다"고 느낍니다.

• 나쁜 예: 카드 그림자는 아래로 떨어지는데, 바로 옆 버튼 그림자는 위로 솟음. 설명은 못 해도 어수선한 인상.
• 올바른 예: 일관된 광원(보통 위에서 약간 비추는 빛)을 가정해 모든 그림자가 같은 방향. 화면이 안정감 있게 정돈됨.

실수 5) 너무 진한 그림자 — 대비를 해친다

깊이를 강조한답시고 그림자를 새카맣고 진하게 줍니다. 그 결과 그림자가 주변 텍스트나 요소의 대비를 해치고, 화면에 무거운 그늘이 드리워집니다.

• 나쁜 예: 카드 주변에 짙은 검정 그림자가 두껍게 둘러져, 카드 안 텍스트보다 그림자가 더 눈에 띔. 화면이 답답하고 무거움.
• 올바른 예: 부드럽고 옅은 그림자로 "살짝 떠 있는" 느낌만 줌. 그림자는 어디까지나 보조이고, 주인공은 내용이라는 원칙 유지.

실수 6) 그림자만으로 의미를 전달 — 접근성 사각지대

"이건 떠 있는 알림이다", "이건 새로 뜬 영역이다"라는 의미를 오직 그림자로만 표현합니다. 코드 구조로는 본문의 평범한 <div>와 다를 게 없습니다.

• 나쁜 예: 시각적으로는 분명히 떠 있는 팝업인데, 코드상으로는 그냥 일반 영역. 스크린리더 사용자는 "팝업이 떴다"는 걸 전혀 모름. 그림자는 들리지 않으니까.
• 올바른 예: 깊이로 표현한 의미를 코드로도 한 번 더 전달. 모달이면 role="dialog"와 초점 이동·닫기 처리까지. 그림자는 시각적 보조 신호로, 코드 구조가 진짜 의미의 전달자.

실수 7) 호버 효과 과잉 — 화면이 들썩인다

상호작용 피드백을 준답시고, 마우스를 올릴 때마다 카드가 크게 솟구치거나 그림자가 확 깊어집니다. 카드가 여러 개 모인 화면에서는 마우스를 움직일 때마다 화면이 출렁거립니다.

• 나쁜 예: 카드 목록 위로 마우스를 지나가면 카드들이 차례로 펄쩍펄쩍 떠오름. 어지럽고 산만함. 모션에 민감한 사용자에겐 불편을 넘어 불쾌.
• 올바른 예: 호버 시 그림자를 한 단계만 살짝 깊게. "누를 수 있다"는 신호는 주되, 화면이 들썩이지 않을 정도로 절제. 모션 최소화 설정을 존중.

실수 8) 깊이와 의미의 불일치

낮은 단계 그림자를 모달에, 높은 단계 그림자를 평범한 카드에 주는 식으로, 깊이 위계와 컴포넌트의 성격이 거꾸로 됩니다.

• 나쁜 예: 중요한 확인 팝업은 옅게 떠 있고, 단순 정보 카드는 화면에서 가장 높이 떠 있음. 사용자의 직관과 어긋나 혼란.
• 올바른 예: 임시적이고 주목이 필요한 것일수록 더 높이, 평상시 콘텐츠일수록 더 낮게. 깊이 위계가 의미 위계와 일치.

한 장면 — 같은 신청서, 두 화면

추상적인 요건을 길게 늘어놓는 것보다, 한 장면을 그려 보는 게 빠를 것 같습니다. 어느 공공 서비스의 "지원금 신청" 마지막 단계. 사용자가 "신청하기" 버튼을 누르면 "제출하시겠습니까?"를 묻는 확인 창이 떠야 합니다.

먼저 깊이를 제대로 준 A 화면. 사용자가 버튼을 누르는 순간 뒤 배경이 부드럽게 어두워지고, 화면 한가운데에 흰 박스가 또렷한 그림자를 두르고 떠오릅니다. 사용자는 설명을 읽기도 전에 "아, 이건 지금 답해야 하는 거구나" 하고 직감합니다. 시선이 자연스럽게 그 창의 "예/아니오" 버튼으로 모입니다. 망설임 없이 "예"를 누르고 신청을 끝냅니다. 30초도 안 걸렸습니다.

이번엔 깊이를 빠뜨린 B 화면. 같은 버튼을 눌렀는데, 뒤 배경은 그대로고 확인 창은 본문 글자들 사이에 납작하게 끼어듭니다. 그림자도 없습니다. 사용자는 "어? 뭐가 바뀐 거지?" 하고 화면을 한참 훑습니다. 본문 텍스트와 확인 창의 텍스트가 시각적으로 구분되지 않아, 어디가 새로 뜬 창인지 헷갈립니다. 결국 확인 창의 "예" 버튼을 못 찾고, 페이지를 다시 새로고침하거나 "신청이 안 되는 것 같다"며 전화 문의를 합니다.

같은 신청서, 같은 확인 창. 한 화면에선 30초짜리 사소한 단계이고, 다른 화면에선 막힌 길입니다. 그리고 이 차이는 "예산이 부족해서"나 "기술이 어려워서" 생긴 게 아닙니다. 그냥 만들 때 "이 창이 떠 보여야 한다"는 생각을 안 했기 때문에 생긴 차이입니다. 더 안타까운 건, 깊이를 제대로 준 A 화면은 KRDS 킷의 모달 컴포넌트를 그대로 가져다 쓰기만 해도 자동으로 만들어진다는 점입니다. 차이를 만드는 건 거창한 기술이 아니라, "검증된 컴포넌트를 쓰느냐"라는 작은 선택입니다.

직접 적용하기 — 개발자·디자이너·기획자 가이드

KRDS의 좋은 점은, 위 요건들을 "알아서 잘 하세요"로 끝내지 않고 바로 쓸 수 있는 자산으로 제공한다는 것입니다.

개발자라면 — KRDS 컴포넌트 킷을 npm install krds-uiux로 설치하거나 CDN(krds.min.css / krds.min.js)으로 불러올 수 있습니다. 엘리베이션 토큰이 CSS 변수 형태로 정의돼 있어, 카드·모달·드롭다운을 만들 때 손으로 box-shadow 값을 적는 대신 정해진 그림자 토큰을 참조하면 됩니다. 이렇게 하면 사이트 전체에서 깊이가 자동으로 일관됩니다. "그림자 값을 외우거나 매번 정하는" 수고가 사라지고, 나중에 그림자 톤을 한 번에 조정하기도 쉬워집니다(토큰 한 곳만 고치면 전부 반영). 저장소의 html/code 폴더에서 컴포넌트별로 어떤 엘리베이션을 쓰는지 실제 코드로 확인할 수 있습니다.

디자이너라면 — KRDS 공식 Figma(@krds) 라이브러리에서 엘리베이션이 적용된 컴포넌트(카드·모달·드롭다운 등)를 그대로 가져다 쓸 수 있습니다. 그림자를 직접 그리지 말고 표준 스타일을 적용하면, 디자인 단계에서부터 깊이 단계가 기준에 맞춰집니다. 시안과 실제 구현 사이의 간극도 줄어들죠. 무엇보다, 시안 안에서 "이 그림자는 몇 단계인가"를 토큰 이름으로 개발자에게 명확히 전달할 수 있습니다.

기획자라면 — 화면 정의서에 "팝업"이라고만 적지 말고, "모달(높은 엘리베이션, 배경 딤, 대화상자 역할)"처럼 깊이와 동작을 함께 명시하세요. 특히 "이 요소가 다른 것을 덮는가", "주목을 강하게 요구하는가"를 적어 두면, 디자인·개발 단계에서 적절한 깊이 단계가 자연스럽게 선택됩니다. 이 한 줄이 "떠 있어야 할 게 안 뜨는" 사고를 막습니다.

그래서 우리 사이트는? — ViewCheck로 점검하기

여기까지가 KRDS의 엘리베이션 기준입니다. 그런데 정작 어려운 건 "그래서 우리 사이트는 이걸 지키고 있나?"를 확인하는 일입니다. 페이지마다 카드·모달·드롭다운이 몇 개인지, 각각 적절한 깊이를 쓰는지, 그림자가 일관된 토큰을 참조하는지, 모달이 코드로도 제대로 선언돼 있는지를 사람이 일일이 손으로 점검하려면 끝이 없습니다. 페이지가 수십·수백 개인 공공 사이트라면 더더욱요.

ViewCheck(krds.viewcheck.co.kr)는 이 점검을 자동화합니다. URL만 넣으면 페이지를 실제로 크롤링해서, 디자인 시스템 요소들이 KRDS 기준을 지키는지 판정합니다. 엘리베이션은 KRDS 846규칙 중 디자인 시스템(DS) 규칙군 120개에 속하고, 분석 결과의 디자인 시스템(Design System) 탭에서 확인할 수 있습니다.

ViewCheck가 디자인 시스템 영역에서 자동으로 보는 것들(엘리베이션 관련):

• 디자인 토큰 채택률: 그림자·색·간격·서체 같은 디자인 값이 KRDS 토큰을 따르는지, 아니면 임의 값으로 흩어져 있는지를 계산해 "토큰 채택률"로 보여 줍니다. 그림자를 손으로 일일이 다르게 준 사이트는 이 채택률이 낮게 나옵니다.
• 그림자 일관성: 같은 종류의 요소가 일관된 깊이를 쓰는지, 아니면 페이지마다 제각각인지.
• 모달·드롭다운의 코드 표현: 시각적으로 떠 있는 요소가 코드 수준에서도 제대로 선언돼 있는지(예: 모달의 대화상자 역할, 초점 처리).
• 대비·색과의 충돌: 그림자나 깊이 표현이 텍스트 가독성·대비를 해치지 않는지(색·대비 분석과 연계).

DOM(코드)만으로 판단하기 어려운 시각적 부분 — 예를 들어 "이 그림자가 실제로 화면에서 떠 보이는가", "모달이 시각적으로 본문과 충분히 구분되는가" — 은 KRDScan Vision AI가 스크린샷을 보고 보강 판정합니다. 그래서 코드만 보는 단순 검사 도구와 달리, 사람이 눈으로 보듯 화면을 함께 봅니다. 비표준 방식으로 만든 깊이 표현(예: 그림자 대신 이미지로 처리한 경우)도 놓치지 않습니다.

리포트를 어떻게 읽나

분석이 끝나면 디자인 시스템 탭에서 토큰 채택률과 함께, 엘리베이션을 포함한 디자인 값들이 KRDS 기준을 얼마나 따르는지 통과/미통과로 나옵니다. 미통과한 항목은 위치(어느 페이지)·이유·개선 방법(howToFix)이 함께 표시됩니다. 예를 들어 "이 페이지의 카드들이 KRDS 그림자 토큰 대신 임의 box-shadow를 사용"처럼 구체적으로요.

여러 페이지를 한꺼번에 분석하면, "메인의 카드는 토큰을 쓰는데 목록 페이지의 카드는 임의 값을 쓴다" 같은 페이지별 편차도 한눈에 드러납니다. 어디부터 고쳐야 하는지 우선순위(P0~P3)도 함께 매겨지니, 한정된 시간에 가장 중요한 것부터 손볼 수 있습니다. 디자인 시스템은 한두 페이지만 봐서는 일관성을 알 수 없기 때문에, 이렇게 사이트 전체를 한 번에 보는 게 특히 유용합니다.

무료 진단으로 우리 사이트 메인부터 한 번 돌려 보면, 손으로는 몇 시간 걸릴 점검이 몇 분 만에 끝납니다. 그리고 그 결과는 막연한 "그림자 좀 정리하자"가 아니라, "이 페이지의 이 카드를 이 토큰으로 바꾸자"는 구체적인 작업 목록이 됩니다.

자주 묻는 질문

현장에서 엘리베이션을 다룰 때 반복해서 나오는 질문들을 모았습니다.

Q. 그림자 없이 테두리(border)만으로 영역을 구분해도 되나요?

됩니다. 사실 그림자보다 옅은 테두리나 면 색 차이로 영역을 구분하는 게 더 깔끔할 때도 많습니다. 특히 정보 밀도가 높은 화면(표, 목록)에서는 그림자를 남발하면 어수선해지므로, 테두리·구분선이 더 적합합니다. 핵심은 "그림자냐 테두리냐"가 아니라 "위계가 분명하게 전달되느냐"입니다. 다만 진짜로 떠 있어야 하는 요소(모달·드롭다운)는 테두리만으로는 "떠 있음"을 표현하기 어려우니, 이때는 그림자가 제 역할을 합니다. 둘을 적절히 섞되, 한 사이트 안에서는 같은 역할엔 같은 방식을 쓰는 일관성이 중요합니다.

Q. 다크 모드(어두운 배경)에서는 그림자가 안 보이는데 어떻게 하나요?

좋은 질문입니다. 검정 그림자는 어두운 배경에서 거의 보이지 않습니다. 그래서 다크 모드에서는 깊이를 그림자 대신 면 밝기로 표현하는 게 일반적입니다. 즉, 떠 있는 요소일수록 배경보다 살짝 더 밝은 면 색을 줘서 "위에 있음"을 나타냅니다. 빛이 위에서 오면 높은 면이 더 밝게 보인다는 물리 원리를 그대로 쓰는 거죠. 디자인 시스템이 라이트/다크 양쪽을 지원한다면, 엘리베이션 토큰도 모드별로 다르게 정의돼 있어야 합니다. 그림자 값 하나를 두 모드에 똑같이 쓰면 다크 모드에서 깊이가 사라집니다.

Q. z-index만 잘 주면 엘리베이션은 신경 안 써도 되지 않나요?

z-index(겹침 순서)와 엘리베이션(그림자로 보이는 깊이)은 다릅니다. z-index는 "어떤 요소가 다른 요소를 가리는가"라는 기술적 순서이고, 엘리베이션은 "사용자 눈에 얼마나 떠 보이는가"라는 시각적 표현입니다. 둘은 보통 함께 맞물려야 합니다. z-index만 높이고 그림자는 안 주면, 코드상으로는 위에 있지만 사용자 눈에는 평면처럼 보여서 "떠 있다는 느낌"이 안 듭니다. 반대로 그림자만 주고 z-index를 안 맞추면, 떠 보이는데 실제로는 다른 요소에 가려지는 모순이 생깁니다. 둘을 함께 관리하는 게 맞습니다.

Q. 그림자를 CSS로 직접 주는 것과 KRDS 토큰을 쓰는 것, 결과가 같으면 상관없지 않나요?

당장 한 화면만 보면 결과가 같아 보일 수 있습니다. 차이는 "나중에"와 "전체에서" 드러납니다. 토큰을 쓰면 사이트 전체의 그림자가 한 곳에서 관리돼, 톤을 바꾸고 싶을 때 토큰 한 곳만 고치면 전부 반영됩니다. 손으로 값을 박아 두면 수백 군데를 일일이 찾아 고쳐야 하죠. 또 사람이 매번 값을 정하면 미묘하게 달라지기 마련이라, 결국 "제각각인 그림자" 문제로 이어집니다. ViewCheck가 토큰 채택률을 보는 이유가 이겁니다 — 지금 똑같아 보여도, 토큰을 안 쓰면 일관성이 무너질 위험이 높다는 신호거든요.

Q. 모션에 민감한 사용자를 위해 호버 그림자 효과를 빼야 하나요?

전부 뺄 필요는 없지만, 사용자의 "모션 줄이기" 설정(prefers-reduced-motion)을 존중하는 게 맞습니다. 이 설정을 켠 사용자에게는 그림자가 부드럽게 깊어지는 전환(transition) 같은 움직임을 최소화하거나 제거하면 됩니다. 깊이 자체(정적인 그림자)는 정보 전달이니 유지하되, 움직이는 전환만 줄이는 식으로요. 모션에 민감한 사용자는 과한 움직임에 어지러움이나 불편을 느낄 수 있으므로, 이 배려는 접근성의 한 부분입니다.

Q. 우리는 그림자를 거의 안 쓰는 플랫(flat) 디자인인데, 그래도 엘리베이션 기준이 적용되나요?

플랫 디자인이라고 엘리베이션 개념이 사라지는 건 아닙니다. 그림자를 안 쓰더라도 위계는 여전히 필요하니까요. 플랫 디자인에서는 깊이를 테두리·면 색·간격·z축 겹침으로 표현합니다. 핵심 요건 — "위계가 분명한가", "모달이 본문과 구분되는가", "깊이 정보가 코드로도 전달되는가" — 은 그대로 적용됩니다. 즉 "그림자를 쓰느냐"가 아니라 "위계를 명확히 전달하느냐"가 본질입니다. 플랫 디자인이라면 오히려 모달·드롭다운을 본문과 구분하는 장치(딤 배경 등)에 더 신경 써야 합니다.

Q. 이미 운영 중인 사이트인데, 그림자를 전부 다시 정리해야 하나요?

전부 갈아엎을 필요는 없습니다. 먼저 ViewCheck로 현황을 확인해 "지금 어떤 요소가, 어느 페이지에서, 토큰을 안 쓰거나 깊이가 어긋나는지"를 목록으로 만든 다음, 우선순위대로 치명적인 것부터 고치면 됩니다. 특히 "안 떠 보이는 모달"처럼 사용성에 직접 영향을 주는 것부터 손보면, 적은 작업으로 가장 큰 개선을 얻습니다. 그림자 톤 통일 같은 미세 조정은 토큰을 도입한 뒤 점진적으로 진행해도 됩니다. 리뉴얼 예산을 한 번에 들이지 않고도 점수를 끌어올리는 게 현실적인 전략입니다.

Q. 그림자 단계는 몇 개가 적당한가요?

정답이 정해진 건 아니지만, 보통 3~5개 정도가 다루기 좋습니다. 너무 적으면 위계를 충분히 표현하지 못하고, 너무 많으면 단계 간 차이가 미세해져서 사용자도 구분 못 하고 개발자도 어느 걸 써야 할지 헷갈립니다. "바닥 / 카드 / 떠 있는 메뉴 / 모달" 정도의 단계만 명확해도 대부분의 화면을 커버할 수 있습니다. 중요한 건 단계 개수가 아니라, 각 단계가 어떤 컴포넌트에 쓰이는지 약속이 분명한가입니다. KRDS가 정의한 단계 구조를 기준으로 삼고, 거기서 벗어나는 임의 단계를 늘리지 않는 게 안전합니다.

점검했다면, 무엇부터 고칠까 — 우선순위

ViewCheck로 돌려 보면 보통 엘리베이션 관련 문제가 한두 개로 끝나지 않습니다. 페이지가 많을수록 "고칠 게 많다"는 압박감이 듭니다. 그래서 우선순위가 중요합니다. 엘리베이션 문제를 심각도 순으로 정리하면 대략 이렇습니다.

가장 먼저(치명적) — 떠 있어야 할 모달·다이얼로그가 깊이 표현도 코드 선언도 없어 본문과 구분되지 않는 경우, 그리고 깊이로만 전달되어 스크린리더 사용자가 인지하지 못하는 중요 정보. 이건 사용자가 "지금 답해야 할 것"을 놓치거나, 특정 사용자에게 정보를 완전히 차단하는 문제라 1순위입니다. 신청·동의·확인처럼 핵심 경로의 모달이라면 더더욱 먼저 손봐야 합니다.

그다음(높음) — 깊이 위계와 의미가 거꾸로 된 경우(중요한 게 안 뜨고 사소한 게 떠 있음), 그리고 광원 방향이 뒤죽박죽이거나 그림자가 너무 진해 대비를 해치는 경우. 작동은 하지만 사용자의 직관과 어긋나 혼란을 주는 문제입니다.

그 후(보통) — 그림자 인플레이션(다 떠 있어서 위계가 흐려짐), 호버 효과 과잉, 모션 설정 미존중. 사용은 가능하지만 화면을 어수선하게 만들거나 특정 사용자에게 불편을 주는 문제입니다.

여력이 되면(낮음) — 임의 box-shadow를 KRDS 토큰으로 교체해 일관성·유지보수성을 높이기. 당장 사용을 막는 건 아니지만, 장기적으로 사이트의 완성도와 관리 효율을 끌어올리는 항목입니다.

ViewCheck 리포트는 이 우선순위(P0~P3)를 자동으로 매겨 주기 때문에, "일단 눈에 띄는 것부터"가 아니라 "사용자에게 가장 큰 영향을 주는 것부터" 순서대로 처리할 수 있습니다. 한정된 인력과 일정 안에서 가장 효과 큰 개선에 집중하는 게 핵심입니다.

더 깊이 확인하려면 — 공식 자료 안내

이 글은 KRDS의 엘리베이션 기준을 실무 관점에서 풀어 쓴 것입니다. 정확한 원문 기준과 코드·디자인 자산은 아래 공식 자료에서 직접 확인하실 수 있습니다.

• KRDS 가이드라인 PDF(디지털 정부서비스 UI/UX 가이드라인, 2025.08판) — 스타일·컴포넌트의 정의와 사용 원칙의 1차 원천. 엘리베이션의 정확한 단계 정의와 적용 원칙을 여기서 확인하세요.
• KRDS 스타일 가이드(웹) — 엘리베이션 설명과 예시를 화면으로 확인.
• KRDS 컴포넌트 킷(GitHub) — 카드·모달·드롭다운 등 엘리베이션이 적용된 컴포넌트 코드를 그대로 가져다 사용(npm install krds-uiux 또는 CDN).
• KRDS 공식 Figma(@krds) — 디자이너용 엘리베이션 스타일과 컴포넌트.

공식 자료는 "정답지"이고, ViewCheck는 "내 답안을 채점해 주는 도구"라고 생각하시면 됩니다. 둘을 함께 쓰면, 기준을 이해하고(가이드라인) → 내 사이트가 그 기준에 맞는지 확인하고(ViewCheck) → 검증된 코드·토큰으로 고치는(킷) 한 바퀴가 완성됩니다.

오늘의 체크리스트 — 엘리베이션, 이것만은

마지막으로, 디자이너·개발자·기획자가 엘리베이션을 만들거나 검수할 때 바로 쓸 수 있는 체크리스트로 정리합니다.

• ☐ 그림자를 임의 값으로 그때그때 정하지 않고, 정의된 단계(토큰) 안에서 골라 쓴다.
• ☐ 모달·다이얼로그는 충분한 깊이(높은 단계 그림자 + 배경 딤)로 본문과 확실히 구분된다.
• ☐ 깊이 위계가 의미 위계와 일치한다(임시적·주목 필요 요소일수록 높이, 평상시 콘텐츠는 낮게).
• ☐ 같은 종류의 요소는 사이트 전체에서 같은 깊이를 쓴다(페이지마다 제각각이 아니다).
• ☐ 모든 그림자가 일관된 광원 방향을 가정한다(어떤 건 아래, 어떤 건 위로 떨어지지 않는다).
• ☐ 그림자가 너무 진하지 않아 텍스트 가독성·대비를 해치지 않는다.
• ☐ 깊이로 전달하려는 의미는 코드로도 전달된다(모달은 대화상자 역할 선언 등). 그림자만으로 끝내지 않는다.
• ☐ 꼭 필요한 곳에만 그림자를 준다(그림자 인플레이션을 피한다).
• ☐ 호버·클릭 시 깊이 변화는 절제돼 있고, 모션 줄이기 설정을 존중한다.
• ☐ 다크 모드를 지원한다면 모드별 엘리베이션이 따로 정의돼 있다(그림자 대신 면 밝기 등).

KRDS 컴포넌트 킷(npm install krds-uiux 또는 CDN)을 쓰면 위 항목 대부분이 이미 구현된 상태로 시작할 수 있습니다. 직접 그림자 값을 정하다 일관성을 잃을 위험을 줄이는 가장 확실한 방법이죠. 공식 Figma 라이브러리(@krds)에서는 디자이너가 엘리베이션이 적용된 컴포넌트를 그대로 가져다 쓸 수 있습니다.

엘리베이션은 작아 보이고 미묘하지만, 화면의 위계를 만드는 결정적인 장치입니다. 그림자 하나가 "지금 답해야 할 팝업"을 도드라지게 하고, 또 다른 그림자 하나가 "누를 수 있는 카드"임을 말없이 알려 줍니다. 우리가 무심코 넘긴 그림자 한 장이, 누군가에게는 "어디를 눌러야 할지 헤매지 않게" 해 주는 이정표입니다.

오늘 정리한 기준이 거창해 보일 수 있지만, 핵심은 결국 단순합니다. 정해진 단계만큼만 쓰고, 떠야 할 것만 띄우고, 사이트 전체에서 일관되게 하고, 깊이 정보를 코드로도 전달하는 것. 이 네 가지만 챙겨도 엘리베이션 위반 대부분은 사라집니다. 그리고 그게 잘 됐는지는 ViewCheck로 몇 분이면 확인할 수 있습니다. 완벽을 한 번에 만들 필요는 없습니다. 가장 눈에 띄는 "안 떠 보이는 모달" 하나부터 고쳐 나가면, 우리 사이트는 분명히 조금씩 더 정돈되고, 더 많은 사람이 헤매지 않게 됩니다. 다음 글에서는 엘리베이션과 함께 화면의 인상을 좌우하는 또 다른 스타일 요소를 같은 방식으로 뜯어보겠습니다.

우리 사이트의 디자인 시스템은 지금 몇 점일까요? krds.viewcheck.co.kr에서 URL만 넣으면 무료로 확인할 수 있습니다. 메인 페이지 하나만 돌려 봐도, 그림자와 디자인 토큰이 얼마나 일관되게 쓰이고 있는지 바로 보입니다.

#KRDS #공공웹 #디자인시스템 #엘리베이션Elevation #웹접근성 #ViewCheck #정부웹사이트 #UIUX #디자인토큰 #그림자 #shadow #depth #엘리베이션 #Elevation #KRDS기준 #디자인원칙 #표준가이드 #디자인스타일 #전자정부 #디지털정부