엘리베이션(Elevation) 자가진단 — ViewCheck 5분 점검

화면을 한참 보다 보면, 어떤 카드는 종이처럼 살짝 떠 있는 것 같고 어떤 영역은 바닥에 딱 붙어 있는 것처럼 느껴질 때가 있습니다. 분명 모니터는 완전히 평평한 유리판인데, 우리 눈은 거기서 "위"와 "아래", "앞"과 "뒤"를 읽어 냅니다. 어떻게 그게 가능할까요. 답은 그림자입니다. 정확히는 빛과 그림자가 만들어 내는 깊이감, 그러니까 엘리베이션(Elevation)입니다.

엘리베이션은 디자인 시스템에서 가장 "조용한" 항목 중 하나입니다. 색이나 타이포그래피는 바꾸면 누구나 단번에 알아챕니다. 그런데 그림자는 조금 진해지거나 흐려져도 대부분은 알아채지 못합니다. 그냥 "어딘가 정돈돼 보인다" 혹은 "왠지 어수선하다" 정도의 막연한 느낌으로만 남죠. 그래서 엘리베이션은 잘 만들어도 칭찬받기 어렵고, 망쳐도 콕 집어 욕먹기 어려운, 좀 억울한 자리에 있습니다. 그리고 바로 그 이유로 가장 자주 방치됩니다.

이 글은 "이래야 한다"는 기준 설명에서 끝내지 않으려 합니다. 그보다는 손에 잡히는 자가진단에 초점을 맞추겠습니다. 우리 사이트의 그림자가 지금 어떤 상태인지, 어디부터 들여다봐야 하는지, 그리고 그걸 5분 만에 확인하는 방법까지요. KRDS(대한민국 정부 디자인 시스템)가 엘리베이션을 어떻게 정의하는지 먼저 짚고, 공공 웹에서 그림자가 흔히 어떻게 어그러지는지 살펴본 다음, ViewCheck로 우리 사이트의 깊이감을 직접 점검하는 절차로 이어가겠습니다. 다 읽고 나면, 앞으로 어떤 화면을 보든 "이 그림자는 정돈된 것, 저 그림자는 막 쓴 것"이 눈에 들어오실 겁니다.

엘리베이션이 대체 뭐길래 — 정의부터 정확히

먼저 용어를 맞추겠습니다. 엘리베이션(Elevation)을 우리말로 옮기면 "고도" 혹은 "높이"입니다. 디자인 시스템에서 말하는 엘리베이션은 화면 위 요소들이 z축(앞뒤 방향, 사용자를 향한 깊이) 상에서 어느 높이에 떠 있는지를 가리킵니다. 모니터는 2차원 평면이지만, 우리는 거기에 가상의 3차원 공간을 부여합니다. 바닥(배경)이 있고, 그 위에 카드가 살짝 떠 있고, 그보다 더 위에 드롭다운 메뉴가, 더 위에 모달(팝업)이 떠 있는 식이죠.

이 "떠 있음"을 시각적으로 표현하는 도구가 바로 그림자(shadow)입니다. 현실에서 책상 위에 놓인 책이 그림자를 드리우듯, 화면에서도 떠 있는 요소는 그 아래로 그림자를 드리웁니다. 높이 떠 있을수록 그림자는 더 넓게 퍼지고 더 부드러워집니다. 책상에 딱 붙은 종이의 그림자는 가늘고 진하지만, 높이 든 종이의 그림자는 흐릿하게 넓게 번지는 것과 같은 원리입니다.

여기서 중요한 건, 엘리베이션이 단순한 장식이 아니라 정보라는 점입니다. 그림자는 예뻐 보이라고 있는 게 아닙니다. "이 요소가 다른 것들보다 앞에 있다", "이건 지금 클릭 가능한 상태다", "이 팝업은 뒤의 내용을 가린 채 떠 있다" 같은 위계와 상태를 눈에 전달하는 시각 언어입니다. 그래서 그림자를 아무렇게나 쓰면, 사용자는 "무엇이 먼저고 무엇이 나중인지"를 헷갈리게 됩니다.

엘리베이션은 위계 시스템이다

엘리베이션의 본질은 "레이어(layer)의 위계"입니다. 화면 요소들을 여러 층으로 나누고, 각 층마다 정해진 높이와 그에 맞는 그림자를 부여하는 것이죠. KRDS를 비롯한 대부분의 디자인 시스템은 엘리베이션을 연속적인 값이 아니라 단계(level)로 정의합니다. 예를 들면 이런 식의 위계입니다.

• 바닥(레벨 0): 페이지 배경, 본문 영역. 그림자 없음. 모든 것의 기준면.
• 살짝 떠 있음(낮은 레벨): 콘텐츠 카드, 패널처럼 배경에서 한 단계 분리된 요소. 가볍고 은은한 그림자.
• 중간 레벨: 드롭다운, 호버 시 떠오르는 요소처럼 일시적으로 위로 올라오는 것들. 좀 더 또렷한 그림자.
• 높은 레벨: 모달(팝업), 알림 토스트처럼 화면 전체보다 위에 떠서 주목을 끄는 것들. 넓고 부드러운, 그러나 분명한 그림자.

이 단계들이 정해진 토큰(token)으로 관리된다는 게 핵심입니다. 디자인 토큰이란 색·간격·그림자 같은 디자인 속성을 이름 붙여 재사용 가능한 값으로 만들어 둔 것입니다. "shadow-1", "shadow-2"처럼 정해진 그림자 토큰을 정의해 두고, 카드에는 항상 같은 토큰을, 모달에는 또 다른 정해진 토큰을 쓰는 것이죠. 이렇게 하면 사이트 전체에서 같은 위계의 요소는 항상 같은 그림자를 갖게 되어, 사용자가 깊이감을 일관되게 읽을 수 있습니다.

왜 "단계"로 나누나 — 연속이 아니라 계단

그림자 값을 자유롭게 아무 숫자나 쓰면 안 되느냐고요? 기술적으로는 가능합니다. 하지만 그렇게 하면 화면마다 그림자가 조금씩 달라져서, 어떤 카드는 그림자가 4px, 어떤 카드는 5px, 또 어떤 건 7px이 되는 혼돈이 벌어집니다. 사용자 눈에는 "비슷한데 미묘하게 다른" 그림자들이 어수선하게 널려 있는 것으로 보이죠. 정돈된 느낌은 사라지고, "왜인지 모르게 산만한" 화면이 됩니다.

그래서 엘리베이션은 일부러 계단처럼 띄엄띄엄 단계를 둡니다. 연속적인 그라데이션이 아니라 정해진 몇 개의 높이만 허용하는 것이죠. 이렇게 하면 같은 위계의 요소는 항상 똑같은 그림자를, 다른 위계의 요소는 명확히 구별되는 그림자를 갖게 됩니다. "정해진 칸 안에서만 고른다"는 제약이 오히려 화면 전체에 질서를 부여하는 셈입니다. 디자인 토큰의 철학이 그대로 적용되는 영역이 바로 엘리베이션입니다.

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

이제 본론입니다. KRDS 공식 스타일 가이드(스타일 > 엘리베이션 항목)와 가이드라인 문서(디지털 정부서비스 UI/UX 가이드라인, 2025.08판)를 기준으로, 엘리베이션이 충족해야 하는 요건을 정리하겠습니다. 미리 밝혀 두면, 이 글은 KRDS가 정한 구체적인 그림자 수치(픽셀 단위 blur 값 등)를 임의로 지어내지 않습니다. 정확한 수치는 KRDS 공식 페이지와 컴포넌트 킷에서 직접 확인하시길 권합니다. 여기서는 "어떤 원칙을 지켜야 하는가"라는 기준의 뼈대를 다룹니다.

1) 엘리베이션은 토큰으로 관리한다

KRDS는 엘리베이션을 임의 값이 아니라 정의된 그림자 토큰으로 제공합니다. 즉 디자이너나 개발자가 매번 그림자 값을 손으로 정하는 게 아니라, KRDS가 미리 정해 둔 단계별 그림자를 가져다 쓰는 것이 원칙입니다. 컴포넌트 킷(GitHub KRDS-uiux/krds-uiux)과 디자인 토큰 정의에 이 그림자 단계들이 포함돼 있습니다. 이렇게 토큰으로 관리하면, 어느 페이지를 만들든 같은 위계의 요소는 같은 그림자를 갖게 됩니다.

이 "토큰 채택"이라는 개념이 KRDS 디자인 시스템 준수의 핵심입니다. 색을 KRDS 색 토큰으로 쓰고, 간격을 KRDS 간격 토큰으로 쓰듯, 그림자도 KRDS 엘리베이션 토큰으로 써야 한다는 것이죠. 임의의 그림자 값을 직접 박아 넣는 순간, 그 요소는 디자인 시스템 바깥으로 벗어납니다.

2) 위계는 명확해야 한다 — 같은 층은 같게, 다른 층은 다르게

엘리베이션의 존재 이유 자체가 위계 전달입니다. 따라서 KRDS 기준에서 가장 중요한 건 "위계가 시각적으로 명확하게 구분되는가"입니다. 카드와 모달은 사용자 입장에서 분명히 다른 층입니다. 카드는 페이지 안의 콘텐츠고, 모달은 페이지 전체를 가린 채 떠 있는 것이죠. 이 둘이 같은 그림자를 갖고 있으면 사용자는 "지금 떠 있는 게 페이지의 일부인지, 아니면 별도의 팝업인지"를 직관적으로 알 수 없습니다.

반대로 같은 위계의 요소들은 같은 그림자를 가져야 합니다. 한 페이지에 카드가 여섯 개 있는데 그중 둘만 그림자가 더 진하다면, 사용자는 "이 둘이 뭔가 특별한 건가?" 하고 잘못된 신호를 읽습니다. 엘리베이션은 일관성이 곧 의미입니다. 같은 모양은 같은 뜻이어야 사용자가 화면을 신뢰할 수 있습니다.

3) 그림자는 한 방향의 빛을 가정한다

현실 세계에서 그림자는 빛의 방향에 따라 한쪽으로 드리웁니다. 화면에서도 마찬가지로, 디자인 시스템은 보통 "빛이 위에서(또는 위 약간 앞에서) 비친다"는 일관된 가정을 둡니다. 그래서 그림자는 요소의 아래쪽으로 떨어지는 게 자연스럽습니다. 어떤 요소는 아래로, 어떤 요소는 위로, 또 어떤 건 옆으로 그림자가 가면, 마치 화면에 빛이 여러 방향에서 동시에 비치는 것처럼 보여 어색해집니다. KRDS의 엘리베이션 토큰을 일관되게 쓰면 이 빛 방향이 자동으로 통일됩니다.

4) 깊이는 다른 단서와 함께 작동한다

엘리베이션은 그림자만으로 깊이를 표현하지 않습니다. 그림자는 가장 흔한 도구이지만, 배경색의 미묘한 차이, 테두리(border), 요소 간 겹침(overlap) 같은 다른 단서들과 함께 작동합니다. 예를 들어 그림자가 거의 안 보이는 환경(고대비 모드 등)에서도 위계가 무너지지 않으려면, 그림자 외의 단서가 보완 역할을 할 수 있어야 합니다. KRDS가 컴포넌트 단위로 디자인을 제공하는 이유 중 하나가 이것입니다 — 그림자만 떼어 쓰는 게 아니라, 그 컴포넌트에 맞는 깊이 표현 전체를 함께 가져가라는 것.

5) 접근성과 충돌하지 않아야 한다

여기서 한 가지 꼭 짚어야 할 게 있습니다. 그림자는 시각적 효과이기 때문에, 그것 하나에만 의존해 정보를 전달하면 안 됩니다. 예를 들어 "이 버튼은 지금 누를 수 있다"는 상태를 오직 그림자로만 표현하면, 시각장애인이나 저시력 사용자는 그 정보를 받지 못합니다. 한국형 웹 접근성 지침(KWCAG)의 핵심 원칙 중 하나가 "색이나 시각 효과에만 의존하지 말 것"인데, 그림자도 이 원칙의 적용 대상입니다. 깊이감은 시각적 위계를 거드는 보조 단서로 쓰되, 핵심 정보는 텍스트와 구조(올바른 마크업)로도 전달돼야 합니다.

또 하나, 과한 그림자는 오히려 가독성을 해칩니다. 그림자가 너무 진하거나 넓으면 요소 주변이 탁해 보이고, 텍스트와 배경의 대비를 떨어뜨릴 수 있습니다. 엘리베이션은 "은은하게 떠 있는 느낌"을 주는 게 목적이지, "두껍게 칠한 액자"를 만드는 게 아닙니다.

정리하면, KRDS의 엘리베이션 기준은 크게 네 축입니다. ① 토큰화(임의 값이 아니라 정의된 그림자 단계를 쓸 것), ② 위계 명확성(같은 층은 같게, 다른 층은 다르게), ③ 일관성(빛 방향과 단계가 사이트 전체에서 통일될 것), ④ 접근성 양립(그림자에만 의존하지 말고, 과하지 않게). 이 네 축이 곧 우리가 자가진단에서 확인할 항목들입니다.

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

여기까지 읽고 "그림자 하나에 뭐 이리 까다롭나" 싶으실 수 있습니다. 그런데 엘리베이션을 제대로 다루는 게 왜 중요한지는, 우리 뇌가 화면을 어떻게 읽는지를 생각하면 분명해집니다.

인간의 눈은 깊이를 먼저 읽는다

우리는 진화적으로 평면을 보고도 깊이를 추론하도록 만들어졌습니다. 멀리 있는 것과 가까이 있는 것을 순식간에 판단하는 능력은 생존에 필수였으니까요. 화면을 볼 때도 마찬가지입니다. 우리는 글자를 읽기도 전에, 무엇이 앞에 있고 무엇이 뒤에 있는지를 먼저 느낍니다. 떠 있는 카드는 "여기 중요한 게 있다"는 신호로, 진하게 떠오른 버튼은 "이걸 누르라"는 신호로 무의식중에 받아들이죠.

엘리베이션은 이 무의식의 언어를 다룹니다. 그래서 그림자가 어긋나면, 사용자는 "뭔가 이상한데 정확히 뭐가 이상한지는 모르겠는" 불편을 느낍니다. 카드가 다 똑같이 떠 있어서 무엇이 중요한지 모르겠거나, 모달이 배경과 충분히 분리되지 않아 "이 팝업이 정말 떠 있는 건가" 하고 헷갈리거나. 이런 미세한 혼란이 쌓이면 사이트 전체가 "왠지 모르게 신뢰가 안 가는" 인상을 줍니다.

공공 서비스는 신뢰가 생명이다

상업 사이트는 디자인이 좀 어수선해도 사용자가 "원래 좀 그런가 보다" 하고 넘어갑니다. 그런데 공공 서비스는 다릅니다. 주민등록 등본을 떼고, 세금을 내고, 민원을 넣는 곳입니다. 사용자는 이 화면이 "공식적이고 믿을 만한가"를 무의식적으로 평가합니다. 그리고 그 평가의 상당 부분이 시각적 완성도에서 옵니다. 그림자가 제각각이고 위계가 무너진 화면은, 내용이 아무리 정확해도 "어딘가 엉성한 사이트"라는 인상을 줍니다.

반대로 엘리베이션이 정돈된 화면은, 사용자가 별로 의식하지 못한 채로 "이 사이트는 잘 만들어졌다"고 느낍니다. 깊이감의 질서가 곧 신뢰의 토대인 셈입니다. KRDS가 엘리베이션을 스타일 가이드의 한 항목으로 따로 정의해 둔 건, 바로 이 "보이지 않는 신뢰"를 표준화하기 위해서입니다.

작은 디테일일수록 일관성이 어렵다

엘리베이션이 어려운 진짜 이유는, 그것이 "작고 흔한" 디테일이라는 점입니다. 색이나 폰트는 디자인 가이드에 큼직하게 정의돼 있어서 모두가 신경 씁니다. 그런데 그림자는 컴포넌트마다 살짝살짝 들어가는 부속품 같은 거라, 여러 사람이 여러 화면을 만들다 보면 어느새 제각각이 됩니다. A 화면을 만든 사람은 카드에 그림자 4px를, B 화면을 만든 사람은 6px를 썼는데, 둘 다 "이 정도면 괜찮겠지" 하고 넘어갑니다. 그렇게 쌓인 미세한 불일치가 사이트 전체의 깊이감을 흐트러뜨립니다.

이 "여러 사람이 만들어서 생기는 불일치"는 사람이 눈으로 일일이 잡아내기가 정말 어렵습니다. 한 화면만 보면 멀쩡해 보이거든요. 여러 페이지를 나란히 놓고 비교해야 비로소 "여기 그림자가 저기랑 다르네"가 보입니다. 페이지가 수십·수백 개인 공공 사이트라면 사람 손으로는 사실상 불가능에 가깝습니다. 그래서 토큰 기반 관리와 자동 점검이 필요한 겁니다.

일관성이 곧 학습 비용 절감

KRDS가 엘리베이션을 표준화하는 또 다른 이유는, 정부 사이트 전체의 일관성입니다. 모든 공공 서비스의 카드가 같은 깊이로 떠 있고, 모든 모달이 같은 방식으로 화면을 가리면, 사용자는 한 사이트에서 익힌 "이건 떠 있는 거구나, 이건 팝업이구나"라는 감각을 다른 사이트에서도 그대로 씁니다. 디지털에 익숙하지 않은 사용자에게 이 "다시 안 배워도 됨"은 큰 배려입니다. 표준화는 디자이너의 자유를 뺏는 게 아니라, 사용자의 인지 부담을 덜어 주는 일입니다.

한 장면 — 같은 사이트, 세 번의 리뉴얼

추상적인 원리를 길게 늘어놓는 것보다, 한 장면을 그려 보는 게 빠를 것 같습니다. 어느 A 광역지자체의 민원 포털을 떠올려 봅시다. 처음 만들어질 때는 한 디자인 회사가 전체를 통째로 설계해서, 카드든 모달이든 그림자가 깔끔하게 통일돼 있었습니다. 사용자는 의식하지 못했지만, 화면 어디를 봐도 "떠 있는 것"과 "바닥에 있는 것"이 일관되게 구분됐죠.

그런데 몇 년이 지나면서 부서별로 새 기능이 붙기 시작합니다. 복지 부서가 새 신청 페이지를 추가하면서, 담당 외주 개발자가 그 페이지의 카드에 자기 취향대로 진한 그림자를 넣습니다. 다음 해엔 교통 부서가 또 다른 업체를 통해 알림 페이지를 추가하는데, 이번엔 그림자를 거의 안 씁니다. 각자 자기 페이지만 보면 다 괜찮아 보입니다. 아무도 "전체를 나란히 놓고 비교"하지 않으니까요.

그렇게 3년쯤 지나면, 이 포털의 그림자는 페이지마다 제각각이 됩니다. 메인의 카드는 옅게, 복지 페이지의 카드는 진하게, 교통 페이지의 카드는 평평하게. 사용자는 "왜인지 모르게 이 사이트는 좀 어수선하다"고 느끼지만, 정확히 무엇 때문인지는 짚지 못합니다. 화면을 만든 사람들도 자기 페이지만 봤으니 문제를 못 느낍니다. 이게 엘리베이션 불일치가 쌓이는 전형적인 과정입니다 — 누구도 잘못한 적 없는데, 전체로 보면 어그러져 있는.

만약 이 지자체가 처음부터 KRDS 엘리베이션 토큰을 정의해 두고 모든 부서·모든 업체가 그것만 쓰도록 했다면, 외주가 몇 번 바뀌든 카드는 늘 같은 그림자를 가졌을 겁니다. 그리고 만약 매 리뉴얼마다 ViewCheck로 한 번씩 돌려 봤다면, "이번에 추가된 복지 페이지의 카드 그림자가 기준에서 벗어났다"는 걸 즉시 알았을 거고요. 차이를 만드는 건 거창한 기술이 아니라, "토큰으로 관리하느냐"와 "정기적으로 점검하느냐"라는 두 가지 작은 습관입니다.

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

이제 현업에서 실제로 반복되는 엘리베이션 실수들을 보겠습니다. 모두 익명화한 일반적 사례입니다(특정 기관을 지목하지 않습니다). 이 사례들이 곧 우리가 자가진단에서 찾아낼 "증상"들입니다.

실수 1) 토큰 없이 임의의 그림자 값 남발

가장 흔하고 가장 뿌리 깊은 실수입니다. 그림자를 KRDS 토큰으로 쓰지 않고, 화면마다 개발자가 손으로 값을 정합니다. 한 카드는 box-shadow: 0 2px 4px rgba(0,0,0,0.1), 다른 카드는 0 4px 8px rgba(0,0,0,0.15), 또 다른 건 0 1px 3px rgba(0,0,0,0.2). 따로 보면 다 그럴듯하지만, 모아 놓으면 위계가 뒤죽박죽입니다.

• 나쁜 예: 페이지마다, 컴포넌트마다 제각각인 임의 그림자 값. 같은 카드인데도 화면이 다르면 그림자가 다름. "비슷한데 미묘하게 다른" 그림자들이 사이트 전체에 흩어져 있음.
• 올바른 예: KRDS 엘리베이션 토큰을 정의하고, 카드에는 항상 카드용 토큰을, 모달에는 항상 모달용 토큰을 사용. 어느 화면을 만들든 같은 위계는 같은 그림자를 갖도록 통일.

실수 2) 위계가 뒤집힌 그림자

깊이의 의미를 거꾸로 쓰는 경우입니다. 페이지 안의 평범한 카드에 모달급 진한 그림자를 줘서 마치 떠 있는 팝업처럼 보이게 하거나, 반대로 정작 화면 전체를 가린 모달에는 그림자가 거의 없어서 배경과 분리가 안 됩니다.

• 나쁜 예: 본문 카드가 모달보다 더 진하게 떠 있어, 사용자가 "이게 팝업인가?" 하고 멈칫함. 모달은 배경과 안 떨어져 보여 "이 창이 정말 떠 있는 건가" 헷갈림.
• 올바른 예: 위계 순서대로 그림자 강도를 부여. 바닥 < 카드 < 드롭다운 < 모달 순으로 깊이가 올라가게. 사용자가 그림자만 봐도 "무엇이 더 앞에 있는지"를 직관적으로 읽음.

실수 3) 과한 그림자로 가독성 저하

"입체감을 더 주자"는 의욕이 과해서, 그림자를 너무 진하고 넓게 줍니다. 결과적으로 요소 주변이 탁해지고, 화면 전체가 무거워 보이며, 텍스트 대비가 떨어집니다.

• 나쁜 예: 모든 카드에 두껍고 어두운 그림자. 화면이 답답하고 무겁게 느껴짐. 그림자가 옆 요소까지 침범해 경계가 지저분함.
• 올바른 예: 은은하고 부드러운 그림자로 "살짝 떠 있는" 느낌만. 깊이는 전달하되 화면은 가볍게 유지. KRDS 토큰의 절제된 그림자 값을 그대로 사용.

실수 4) 그림자에만 의존한 상태 표현

버튼이 클릭 가능한지, 카드가 선택됐는지 같은 상태를 오직 그림자로만 표현합니다. 그림자가 잘 안 보이는 환경(고대비 모드, 저시력)에서는 그 상태를 전혀 알 수 없게 됩니다.

• 나쁜 예: 선택된 카드를 그림자 강도로만 구분. 그림자가 안 보이는 사용자는 무엇이 선택됐는지 모름.
• 올바른 예: 그림자에 더해 테두리·배경색·텍스트 표시 등 다른 단서를 함께 제공. 색·형태·깊이가 같은 정보를 중복해서 전달하도록 설계(KWCAG의 "색·시각 효과에만 의존 금지" 원칙 준수).

실수 5) 빛 방향이 제각각

요소마다 그림자가 가는 방향이 다릅니다. 어떤 건 아래로, 어떤 건 위로, 어떤 건 오른쪽으로. 화면에 빛이 사방에서 비치는 것처럼 보여 비현실적이고 어수선합니다.

• 나쁜 예: 카드는 아래로, 버튼은 위로, 패널은 옆으로 그림자가 감. 통일된 광원이 없어 입체감이 깨짐.
• 올바른 예: 모든 그림자가 같은 빛 방향(보통 위에서 아래)을 가정. KRDS 토큰을 일관되게 쓰면 빛 방향이 자동으로 통일됨.

실수 6) 다크 모드·고대비에서 무너지는 그림자

밝은 배경 기준으로만 그림자를 만들고, 어두운 배경이나 고대비 모드를 확인하지 않습니다. 검은 배경에 검은 그림자는 보이지 않아, 위계가 통째로 사라집니다.

• 나쁜 예: 다크 모드에서 그림자가 안 보여 모든 요소가 바닥에 붙은 것처럼 평평해짐.
• 올바른 예: 어두운 환경에서는 그림자 대신(또는 함께) 미묘한 밝기 차나 테두리로 위계를 보완. KRDS가 컴포넌트 단위로 깊이 표현을 제공하는 이유.

실수 7) 컴포넌트마다 다른 카드 그림자

같은 "카드"인데 메인 페이지의 카드, 목록 페이지의 카드, 상세 페이지의 카드 그림자가 다 다릅니다. 여러 사람이 각 페이지를 만들면서 생기는 전형적인 불일치입니다.

• 나쁜 예: 메인 카드는 옅고, 목록 카드는 진하고, 상세 카드는 또 다름. 같은 컴포넌트가 페이지마다 다르게 떠 있음.
• 올바른 예: "카드"라는 컴포넌트를 한 번 정의하고 모든 페이지에서 재사용. 그림자는 컴포넌트에 귀속되어 어디서든 동일.

실수 8) 그림자 대신 두꺼운 테두리로 입체 흉내

그림자를 쓸 줄 몰라서, 혹은 귀찮아서 두꺼운 테두리로 입체감을 대신합니다. 결과적으로 화면이 "선으로 나뉜 칸"처럼 보여 답답하고 구식 느낌을 줍니다.

• 나쁜 예: 모든 카드에 두꺼운 회색 테두리. 깊이감이 아니라 격자 느낌. 떠 있는 위계가 전혀 안 보임.
• 올바른 예: 위계가 필요한 요소는 그림자(엘리베이션)로, 단순 구분만 필요한 요소는 가벼운 테두리로. 두 도구를 목적에 맞게 구분해 사용.

그래서 우리 사이트는? — ViewCheck로 5분 자가진단

여기까지가 KRDS의 엘리베이션 기준과 흔한 실수들입니다. 그런데 정작 어려운 건 "그래서 우리 사이트 그림자는 이걸 지키고 있나?"를 확인하는 일입니다. 앞서 봤듯 엘리베이션 문제는 한 화면만 봐서는 거의 드러나지 않습니다. 여러 페이지를 나란히 놓고 비교해야 "여기 그림자가 저기랑 다르네"가 보이죠. 그걸 사람이 페이지마다 손으로, 컴포넌트마다 눈으로 비교하려면 끝이 없습니다. 페이지가 수십·수백 개인 공공 사이트라면 사실상 불가능합니다.

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

ViewCheck가 엘리베이션에 대해 보는 것들

ViewCheck는 페이지의 실제 CSS와 computed style을 추출해서, 그림자가 어떻게 쓰였는지를 분석합니다. 구체적으로는 이런 것들을 봅니다.

• 그림자 토큰 채택 여부: 화면에 쓰인 box-shadow 값들이 KRDS 엘리베이션 토큰과 일치하는지, 아니면 임의의 손으로 박은 값인지. 토큰을 안 쓰고 제각각 값을 쓰면 채택률이 떨어집니다.
• 그림자 값의 일관성: 같은 종류의 요소(예: 카드)가 페이지 안에서, 그리고 여러 페이지에 걸쳐 같은 그림자를 쓰는지, 아니면 제각각인지.
• 위계의 구분: 카드급 요소와 모달급 요소가 시각적으로 충분히 다른 깊이를 갖는지.
• 과한 그림자 여부: 그림자가 지나치게 진하거나 넓어 가독성을 해치는 수준은 아닌지.

이 모든 게 디자인 토큰 채택률 리포트로 요약됩니다. KRDS가 제공하는 색·타이포·간격·그림자 토큰을 우리 사이트가 얼마나 충실히 따르고 있는지를 수치로 보여 주는 것이죠. 엘리베이션 토큰의 채택률이 낮다면, 그건 곧 "그림자를 토큰으로 관리하지 않고 손으로 제각각 쓰고 있다"는 신호입니다.

DOM으로 못 보는 부분은 Vision AI가 본다

그림자 중에는 CSS box-shadow가 아니라 이미지나 그라데이션, 의사 요소(pseudo-element)로 흉내 낸 것들도 있습니다. 이런 비표준 구현은 코드만 봐서는 "여기 그림자가 있다"는 걸 알기 어렵습니다. ViewCheck는 이 한계를 보완하기 위해, DOM만으로 판단하기 어려운 시각적 부분을 KRDScan Vision AI가 스크린샷을 보고 보강 판정합니다. 사람이 눈으로 화면을 보듯 깊이감을 함께 보기 때문에, 표준을 우회해 만든 그림자도 놓치지 않습니다. 이 점이 단순 CSS 검사 도구와 다른 부분입니다.

리포트를 어떻게 읽나

분석이 끝나면 디자인 시스템 탭에서 엘리베이션 관련 규칙의 통과/미통과 수와, 미통과한 항목의 위치(어느 페이지)·이유·개선 방법(howToFix)이 함께 나옵니다. 예를 들어 "목록 페이지의 카드 그림자가 KRDS 토큰과 불일치"처럼 구체적으로요. 여러 페이지를 한꺼번에 분석하면, "메인의 카드는 토큰을 쓰는데 상세 페이지의 카드는 임의 값을 쓴다" 같은 페이지별 편차도 한눈에 드러납니다. 어디부터 고쳐야 하는지 우선순위(P0~P3)도 함께 매겨지니, 한정된 시간에 가장 중요한 것부터 손볼 수 있습니다.

5분 자가진단 절차

실제로 5분 안에 우리 사이트의 엘리베이션을 점검하는 순서는 이렇습니다.

1. krds.viewcheck.co.kr 접속, 우리 사이트 메인 URL 입력 (1분) — 회원 가입 없이 무료 진단으로 메인 페이지부터 돌려 봅니다.

2. 디자인 시스템(Design System) 탭으로 이동 (30초) — 분석이 끝나면 상단 탭에서 디자인 시스템을 엽니다.

3. 디자인 토큰 채택률에서 그림자(엘리베이션) 항목 확인 (1분) — 채택률 수치가 낮으면 토큰을 안 쓰고 있다는 뜻입니다.

4. 미통과 규칙의 위치와 이유 확인 (1분) — 어느 영역의 그림자가 어떻게 기준을 벗어났는지 봅니다.

5. 개선 방법(howToFix)과 우선순위 메모 (1분 30초) — 가장 시급한 한두 개를 골라 다음 작업 목록에 적습니다.

이렇게 한 바퀴 돌면, 막연한 "그림자 좀 정리해야지"가 "이 페이지의 이 카드 그림자를 KRDS 토큰으로 바꾸자"는 구체적 작업으로 바뀝니다. 손으로는 몇 시간 걸릴 비교 점검이 몇 분 만에 끝나는 거죠.

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

KRDS의 좋은 점은, 엘리베이션 요건을 "알아서 잘 만드세요"로 끝내지 않고 바로 쓸 수 있는 자산으로 제공한다는 것입니다. 자가진단으로 문제를 찾았다면, 다음은 고치는 단계입니다. 역할별로 정리하겠습니다.

개발자라면 — KRDS 컴포넌트 킷을 npm install krds-uiux로 설치하거나 CDN(krds.min.css / krds.min.js)으로 불러올 수 있습니다. 킷에는 엘리베이션을 포함한 디자인 토큰이 정의돼 있어서, box-shadow 값을 손으로 박는 대신 정해진 그림자 토큰을 가져다 쓰면 됩니다. 핵심 습관은 단순합니다 — 그림자 값을 코드에 직접 쓰지 말 것. 그림자가 필요하면 먼저 "이게 어느 위계의 요소인가"를 정하고, 그 위계에 맞는 KRDS 토큰을 적용하세요. 카드면 카드용 토큰, 모달이면 모달용 토큰. 이렇게만 해도 사이트 전체의 깊이감이 자동으로 통일됩니다.

또 하나, 이미 임의 값으로 박힌 그림자를 정리할 때는 CSS 변수(커스텀 프로퍼티)로 한 번 추상화해 두면 편합니다. --shadow-card, --shadow-modal 같은 변수를 KRDS 토큰 값으로 정의하고, 컴포넌트에서는 변수만 참조하게 하면, 나중에 토큰이 바뀌어도 한 곳만 고치면 됩니다.

디자이너라면 — KRDS 공식 Figma(@krds) 라이브러리에서 엘리베이션이 적용된 컴포넌트를 그대로 가져다 쓸 수 있습니다. 직접 그림자를 그리지 말고 표준 컴포넌트를 배치하면, 디자인 단계에서부터 깊이 단계가 기준에 맞춰집니다. 시안 작업을 할 때 "이 카드는 레벨 1, 이 모달은 레벨 3" 식으로 위계를 명시해 두면, 개발자가 어느 토큰을 써야 할지 한눈에 알 수 있어 시안과 구현 사이의 간극이 줄어듭니다. 그림자 효과를 임의로 미세 조정하고 싶은 유혹이 들 때는, 그게 "이 화면만 특별하게" 만드는 일은 아닌지 한 번 멈춰 보세요. 엘리베이션은 절제가 미덕입니다.

기획자라면 — 화면 정의서에 "카드", "팝업"이라고만 적지 말고, 그 요소가 어느 위계인지(콘텐츠 레벨인지, 떠 있는 오버레이인지)를 함께 적어 두면 좋습니다. "이 알림은 화면 위에 떠야 함(모달급)" 같은 한 줄이 디자인·개발 단계에서 그림자 위계를 잘못 잡는 실수를 막습니다. 또 다크 모드나 고대비 모드를 지원하는 서비스라면, "그림자가 안 보이는 환경에서도 위계가 유지돼야 함"을 요구사항에 명시해 두세요.

자주 묻는 질문

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

Q. 그림자가 너무 사소해 보이는데, 정말 점검할 가치가 있나요?

사소해 보이는 게 함정입니다. 엘리베이션은 개별 화면에서는 거의 티가 안 나지만, 사이트 전체로 보면 "정돈된 인상"과 "어수선한 인상"을 가르는 핵심 요소입니다. 특히 공공 서비스는 시각적 신뢰가 중요한데, 그림자가 제각각인 사이트는 내용이 아무리 정확해도 "엉성하다"는 인상을 줍니다. 그리고 그림자 불일치는 한번 방치하면 페이지가 늘수록 기하급수적으로 번지기 때문에, 일찍 잡을수록 비용이 적게 듭니다. ViewCheck로 5분만 돌려 보면 지금 상태를 바로 알 수 있으니, 비용 대비 효과가 아주 큰 점검입니다.

Q. 토큰을 안 쓰고 그냥 일관된 값만 쓰면 안 되나요?

값만 일관되게 써도 화면상으로는 비슷하게 보일 수 있습니다. 하지만 토큰을 쓰는 진짜 이유는 "변경 가능성"과 "검증 가능성"입니다. 나중에 KRDS 기준이 바뀌거나 디자인을 손볼 때, 토큰을 쓰면 한 곳만 고치면 전체가 바뀝니다. 손으로 박은 값은 페이지마다 찾아다니며 고쳐야 하죠. 또 ViewCheck 같은 도구가 "이게 KRDS 토큰과 일치하는가"를 검증할 수 있는 것도 토큰을 썼을 때입니다. 일관된 임의 값은 "어쩌다 맞은 것"이고, 토큰은 "구조적으로 보장된 것"입니다. 둘은 겉모습이 같아도 유지보수 비용이 완전히 다릅니다.

Q. 우리 사이트는 그림자를 거의 안 씁니다. 그래도 문제인가요?

그림자를 절제해서 쓰는 건 전혀 문제가 아닙니다. 오히려 과한 그림자보다 낫습니다. 다만 "위계가 필요한 곳에 위계가 보이는가"는 확인해야 합니다. 예를 들어 모달이 떴는데 배경과 전혀 구분되지 않으면, 사용자가 "이 창이 떠 있는 건가"를 헷갈립니다. 그림자를 적게 쓰되, 떠 있어야 할 것은 떠 있는 것처럼 보이게 하는 최소한의 단서(그림자든 배경 차이든 테두리든)는 있어야 합니다. ViewCheck로 점검하면 "위계가 필요한데 구분이 안 되는" 지점을 짚어 줍니다.

Q. 다크 모드를 지원하는데, 그림자가 안 보여요. 어떻게 하나요?

어두운 배경에서는 검은 그림자가 거의 보이지 않는 게 당연합니다. 이때는 그림자에만 의존하지 말고 보완 단서를 써야 합니다. 흔한 방법은 ① 떠 있는 요소의 배경을 주변보다 약간 밝게 해서 "떠오른 느낌"을 주거나, ② 미묘한 테두리(밝은 선)를 추가하거나, ③ 두 가지를 함께 쓰는 것입니다. KRDS가 컴포넌트 단위로 디자인을 제공하는 이유 중 하나가 이런 환경별 깊이 표현을 함께 다루기 위해서입니다. 직접 만들기 어렵다면 KRDS 킷의 컴포넌트를 가져다 쓰는 게 안전합니다.

Q. 그림자와 테두리, 언제 무엇을 써야 하나요?

간단한 기준은 "위계냐 구분이냐"입니다. 요소가 다른 것들보다 앞으로 떠 있어야 한다면(카드, 드롭다운, 모달) 그림자(엘리베이션)를 씁니다. 단지 영역을 나누기만 하면 된다면(입력 칸의 경계, 표의 셀 구분) 가벼운 테두리를 씁니다. 둘을 혼동해서 떠 있어야 할 모달을 테두리로만 표현하면 깊이감이 안 나고, 단순 구분만 필요한 곳에 진한 그림자를 주면 화면이 무거워집니다. 목적에 맞게 도구를 고르는 게 핵심입니다.

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

전부 갈아엎을 필요는 없습니다. 먼저 ViewCheck로 현황을 확인해 "지금 어떤 그림자가, 어느 페이지에서, 어떻게 기준을 벗어났는지"를 목록으로 만든 다음, 우선순위대로 치명적인 것부터 고치면 됩니다. 보통은 ① 위계가 뒤집힌 곳(모달이 안 떠 보이는 등)을 먼저, ② 그다음 토큰 불일치를 정리하는 순서가 효율적입니다. 특히 자주 쓰이는 핵심 컴포넌트(카드, 모달)부터 토큰화하면, 적은 작업으로 가장 많은 화면을 한꺼번에 정돈할 수 있습니다. 점진적으로 채택률을 끌어올리는 게 현실적인 전략입니다.

Q. 디자인팀과 개발팀의 그림자 값이 자꾸 어긋납니다.

이건 토큰이 없어서 생기는 전형적인 문제입니다. 디자이너는 Figma에서 그림자를 미세 조정하고, 개발자는 시안을 눈으로 보고 비슷하게 구현하다 보니 값이 어긋나죠. 해결책은 양쪽이 같은 토큰을 보는 것입니다. KRDS가 Figma(@krds)·코드(GitHub 킷)·문서(가이드라인)를 한 세트로 제공하는 이유가 이겁니다. 디자이너는 Figma의 엘리베이션 컴포넌트를, 개발자는 킷의 그림자 토큰을 쓰면, 둘 다 같은 출처를 참조하니 어긋날 일이 없습니다. "감으로 맞추기"를 "같은 토큰 쓰기"로 바꾸는 게 핵심입니다.

Q. ViewCheck 무료 진단으로 그림자까지 정말 다 보나요?

네, 무료 진단으로 메인 페이지를 돌리면 디자인 시스템 탭에서 그림자(엘리베이션) 토큰 채택 현황을 바로 확인할 수 있습니다. 여러 페이지를 한꺼번에 분석해 페이지별 편차까지 보려면 더 많은 페이지를 분석하면 되고요. 일단 메인 한 페이지만 돌려 봐도 "우리가 그림자를 토큰으로 쓰고 있는지, 손으로 박고 있는지"는 명확히 드러납니다. 가장 먼저 그 한 가지만 확인해 봐도 충분히 가치가 있습니다.

Q. 그림자를 "그라데이션"이나 "이미지"로 만들었는데, 그것도 엘리베이션인가요?

보기에 깊이감을 주는 효과라면 모두 엘리베이션의 영역으로 봐야 합니다. 다만 구현 방식에 따라 점검 난도가 달라집니다. 표준 box-shadow로 만든 그림자는 코드만 봐도 값을 정확히 비교할 수 있지만, 이미지나 그라데이션, 의사 요소(::before, ::after)로 흉내 낸 깊이감은 코드만으로는 "여기 그림자가 있다"는 걸 알기 어렵습니다. 이런 비표준 구현이 많을수록 시각 기반 점검이 더 중요해집니다. ViewCheck가 DOM 분석에 더해 KRDScan Vision AI로 스크린샷을 함께 보는 이유가 이것입니다. 가능하면 비표준 방식보다 표준 그림자 토큰을 쓰는 게, 유지보수와 검증 양쪽에서 유리합니다.

Q. 그림자가 성능에 영향을 주나요? 너무 많이 쓰면 느려진다던데요.

부분적으로 맞습니다. 그림자, 특히 blur가 큰 부드러운 그림자는 브라우저가 매번 다시 그려야 하므로, 화면에 수십·수백 개가 깔리면 스크롤이 버벅일 수 있습니다. 다만 이건 "그림자를 쓰지 말라"는 뜻이 아니라 "절제해서, 필요한 곳에만 쓰라"는 또 하나의 근거입니다. 모든 요소에 진한 그림자를 덕지덕지 바르면 성능과 가독성을 동시에 해칩니다. KRDS 토큰의 절제된 그림자를 위계가 필요한 요소에만 적용하면, 성능 부담도 자연스럽게 줄어듭니다. 깊이는 "강조가 필요한 소수"에만 주는 게 시각적으로도 기술적으로도 옳습니다.

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

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

가장 먼저(치명적) — 위계가 뒤집혀 사용자가 화면 구조를 오해하는 경우. 모달이 배경과 안 떨어져 "이게 팝업인지 모르는" 상황, 혹은 본문 요소가 떠 있는 것처럼 보여 혼란을 주는 경우입니다. 이건 사용자가 화면을 잘못 읽게 만드는 문제라 1순위입니다. 특히 알림·확인 팝업처럼 사용자의 결정을 요구하는 모달의 위계가 망가져 있으면 가장 먼저 손봐야 합니다.

그다음(높음) — 그림자에만 의존해 상태를 표현하는 경우, 그리고 다크 모드·고대비에서 위계가 통째로 사라지는 경우. 작동은 하지만 특정 사용자·특정 환경에서 정보가 전달되지 않는 접근성 문제이므로 우선순위가 높습니다.

그 후(보통) — 토큰 불일치(임의 값 남발), 빛 방향 제각각, 같은 컴포넌트의 페이지별 그림자 차이. 사용은 가능하지만 사이트의 정돈된 인상을 해치는 일관성 문제입니다. 핵심 컴포넌트(카드, 모달)부터 토큰화하면 효율적으로 정리됩니다.

여력이 되면(낮음) — 과한 그림자 다듬기, 두꺼운 테두리를 가벼운 그림자로 교체하기 같은 미세 개선. 큰 문제는 아니지만 화면의 완성도를 한 단계 끌어올리는 항목입니다.

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

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

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

• KRDS 스타일 가이드(웹) — 엘리베이션 항목 — 깊이 단계와 그림자 정의를 화면으로 확인. 그림자 단계별 예시가 정리돼 있습니다.
• KRDS 가이드라인 PDF(디지털 정부서비스 UI/UX 가이드라인, 2025.08판) — 스타일·컴포넌트의 정의와 사용 원칙의 1차 원천.
• KRDS 컴포넌트 킷(GitHub `KRDS-uiux/krds-uiux`) — 엘리베이션을 포함한 디자인 토큰과 컴포넌트 코드를 그대로 가져다 사용(npm install krds-uiux 또는 CDN).
• KRDS 공식 Figma(@krds) — 디자이너용 엘리베이션 컴포넌트와 깊이 단계.

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

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

마지막으로, 디자이너·개발자·기획자가 엘리베이션을 만들거나 검수할 때 바로 쓸 수 있는 자가진단 체크리스트로 정리합니다. ViewCheck를 돌리기 전후로 이 목록을 손에 들고 점검해 보세요.

• ☐ 그림자를 임의 값이 아니라 KRDS 엘리베이션 토큰으로 쓰고 있다(box-shadow를 손으로 박지 않았다).
• ☐ 같은 위계의 요소(예: 모든 카드)는 같은 그림자를 갖는다(페이지마다 제각각이 아니다).
• ☐ 다른 위계의 요소(카드 vs 모달)는 명확히 다른 깊이로 구분된다(위계가 뒤집히지 않았다).
• ☐ 모달·팝업이 배경과 충분히 분리돼 보여, 사용자가 "떠 있다"는 걸 직관적으로 안다.
• ☐ 그림자가 과하지 않다(가독성을 해치거나 화면을 무겁게 만들지 않는다).
• ☐ 모든 그림자가 같은 빛 방향(보통 위에서 아래)을 가정한다(방향이 제각각이 아니다).
• ☐ 상태를 그림자에만 의존해 표현하지 않는다(색·테두리·텍스트 등 보완 단서 병행).
• ☐ 다크 모드·고대비에서도 위계가 유지된다(그림자가 안 보여도 떠 있음이 전달된다).
• ☐ 같은 컴포넌트(카드, 모달 등)는 모든 페이지에서 동일한 그림자를 쓴다.
• ☐ 단순 구분이 필요한 곳에는 그림자 대신 가벼운 테두리를 쓴다(도구를 목적에 맞게 구분).
• ☐ ViewCheck 디자인 시스템 탭에서 그림자(엘리베이션) 토큰 채택률을 확인했다.

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

엘리베이션은 작아 보이지만, 공공 서비스 화면의 "정돈된 인상" 전체를 떠받치는 보이지 않는 기둥입니다. 그림자 하나하나는 사소해도, 그것들이 모여 만드는 깊이의 질서가 곧 사용자가 느끼는 신뢰입니다. 우리가 무심코 박은 그림자 값 하나가, 누군가에게는 "잘 만든 공식 사이트"라는 인상으로, 또 누군가에게는 "왠지 엉성한 사이트"라는 인상으로 남습니다.

오늘 정리한 기준이 거창해 보일 수 있지만, 핵심은 결국 단순합니다. 그림자를 토큰으로 쓰고, 같은 층은 같게 다른 층은 다르게 하고, 과하지 않게 하고, 그림자에만 의존하지 않는 것. 이 네 가지만 챙겨도 엘리베이션 위반 대부분은 사라집니다. 그리고 그게 잘 됐는지는 ViewCheck로 5분이면 확인할 수 있습니다. 완벽을 한 번에 만들 필요는 없습니다. 가장 위계가 어긋난 화면 하나부터 정돈해 나가면, 우리 사이트는 분명히 조금씩 더 단단하고 믿음직한 인상을 갖게 됩니다. 다음 글에서는 엘리베이션과 함께 화면의 질서를 만드는 또 다른 스타일 항목을 같은 방식으로 뜯어보겠습니다.

우리 사이트의 그림자는 지금 얼마나 정돈돼 있을까요? krds.viewcheck.co.kr에서 URL만 넣으면 무료로 확인할 수 있습니다. 메인 페이지 하나만 돌려 봐도, 위 체크리스트가 실제로 지켜지고 있는지 디자인 시스템 탭에서 바로 보입니다.

#KRDS #공공웹 #디자인시스템 #엘리베이션Elevation #웹접근성 #ViewCheck #정부웹사이트 #UIUX #디자인토큰 #그림자 #자가진단 #DS규칙 #엘리베이션 #Elevation #체크리스트 #점검항목 #디자인스타일 #전자정부 #디지털정부 #행정안전부