엘리베이션(Elevation) — 공공웹이 자주 틀리는 지점

공공 사이트를 열었는데 화면이 어쩐지 답답하게 느껴진 적 있으실 겁니다. 분명 정보는 다 있는데 어디가 카드고 어디가 그냥 배경인지 한눈에 안 들어오고, 팝업이 떴는데 뒤 화면이랑 구분이 안 돼서 "이게 떠 있는 건가, 아니면 그냥 화면이 바뀐 건가" 헷갈리는 순간. 반대로 어떤 사이트는 카드 하나하나에 그림자가 너무 진하게 들어가서 모든 게 둥둥 떠 있는 것처럼 보여 정신이 사납기도 합니다. 우리는 그걸 그냥 "디자인이 좀 별로네" 정도로 넘기지만, 사실 그 위화감의 정체는 대부분 한 가지로 좁혀집니다. 엘리베이션(Elevation), 그러니까 화면 요소의 "높이감"을 잘못 쓴 겁니다.

엘리베이션은 KRDS(대한민국 정부 디자인 시스템)의 스타일 가이드 중에서도 가장 자주, 그리고 가장 조용히 무너지는 영역입니다. 색이나 글꼴은 틀리면 바로 눈에 띄니까 누군가 잡아내지만, 그림자와 높이감은 "틀렸다"는 감각 자체가 모호합니다. 그래서 디자이너도 개발자도 "이 정도면 됐지" 하고 넘기고, 그 결과 사이트마다 그림자가 제각각이고, 어떤 화면에서는 위계가 너무 약하고 어떤 화면에서는 너무 과합니다. 공공 사이트를 수백 개 분석하다 보면 엘리베이션에서 똑같은 실수가 반복되는 걸 봅니다. 모든 카드에 똑같은 진한 그림자를 박아 두거나, 모달이 떠도 배경이 안 어두워져서 떠 있는 느낌이 없거나, 그림자 값을 매번 손으로 다르게 적어 넣어서 같은 사이트 안에서도 통일이 안 되거나.

이 글은 "엘리베이션을 어떻게 예쁘게 쓰느냐"가 아니라 "공공웹이 엘리베이션에서 무엇을 자주 틀리는가"에 초점을 맞춥니다. 익명화한 일반적 사례들을 통해, 실제 현업에서 반복되는 실수와 그 올바른 대안을 하나씩 짚어 보겠습니다. 다 읽고 나면, 앞으로 어떤 사이트를 보든 "이건 높이감을 제대로 쓴 화면, 저건 그림자를 잘못 쓴 화면"이 눈에 들어오실 겁니다. 그리고 더 중요한 건, 우리 사이트가 그 실수를 저지르고 있는지 어떻게 확인하느냐입니다.

엘리베이션이 대체 뭔가 — 개념부터 정확히

용어부터 맞추고 시작하겠습니다. "엘리베이션(Elevation)"은 글자 그대로 "높이"입니다. 종이를 책상 위에 여러 장 겹쳐 놓으면, 위에 있는 종이는 아래 종이보다 살짝 떠 있고 그 사이에 그림자가 생깁니다. 화면은 평평한 2D인데, 사용자가 "이건 위에 떠 있는 거구나", "저건 바닥에 깔린 거구나"를 직관적으로 느끼게 만드는 장치가 바로 엘리베이션입니다. 그 높이감을 시각적으로 표현하는 수단이 주로 그림자(shadow)이고, 경우에 따라 테두리·배경색 차이도 함께 씁니다.

여기서 핵심은 엘리베이션이 "장식"이 아니라 "위계를 알려 주는 신호"라는 점입니다. 그림자가 진하면 진할수록 그 요소는 화면에서 더 "위"에 있다는 뜻이고, 사용자는 무의식적으로 "더 위에 있는 것 = 지금 더 중요하거나 활성화된 것"으로 읽습니다. 예를 들어 모달(팝업)은 화면 맨 위에 떠야 하니 그림자가 깊고, 배경 카드들은 살짝만 떠 있으니 그림자가 옅고, 본문 텍스트가 깔린 페이지 바닥은 아예 그림자가 없습니다. 이 높이의 차이가 곧 "지금 무엇에 집중해야 하는지"의 지도가 됩니다.

그래서 엘리베이션을 잘못 쓰면 단순히 "안 예쁜" 문제가 아니라 "위계가 망가지는" 문제가 됩니다. 모든 요소가 같은 높이로 떠 있으면 사용자는 뭐가 중요한지 못 고르고, 떠 있어야 할 게 안 떠 있으면 "지금 이게 활성화된 건지" 알 수 없습니다. 평면 위에 깊이를 그리는 일이라, 작은 차이가 의외로 크게 작용합니다.

엘리베이션은 "단계(레벨)"로 관리한다

KRDS를 포함한 현대 디자인 시스템들이 엘리베이션을 다루는 공통된 방식이 있습니다. 그림자 값을 그때그때 손으로 적는 게 아니라, 몇 개의 정해진 단계(레벨)로 묶어서 토큰으로 관리하는 것입니다. 흔히 "레벨 0(바닥, 그림자 없음) → 레벨 1(살짝 떠 있는 카드) → 레벨 2(드롭다운·호버 상태) → 레벨 3(모달·다이얼로그)"처럼 단계가 올라갈수록 그림자가 깊어지는 식입니다. (구체적인 단계 수와 수치는 KRDS 공식 가이드라인과 토큰을 직접 확인하시기 바랍니다 — 이 글에서는 임의의 수치를 단정하지 않습니다.)

이렇게 단계로 묶는 이유가 핵심입니다. 디자이너가 화면마다 "이 카드 그림자는 좀 더 진하게, 저 카드는 좀 더 연하게" 즉흥적으로 정하면, 같은 사이트 안에서도 카드 그림자가 수십 가지가 됩니다. 그러면 사용자는 "이 두 카드의 그림자가 다른데, 의미가 다른 건가?" 하고 쓸데없이 헷갈립니다. 반대로 정해진 레벨만 쓰면, 같은 레벨은 항상 같은 의미("이건 카드", "이건 떠 있는 메뉴")로 읽힙니다. 토큰화된 엘리베이션은 디자이너의 손맛을 빼앗는 게 아니라, 그림자에 "문법"을 부여하는 일입니다.

KRDS 공식 기준은 무엇을 말하나 — 짚어 두기

이 글은 위반 사례 중심이지만, 틀린 걸 알려면 먼저 "맞는 것"의 윤곽을 잡아 둬야 합니다. KRDS의 스타일 가이드(엘리베이션 항목)와 디지털 정부서비스 UI/UX 가이드라인(2025.08판)을 종합하면, 엘리베이션에 대한 기준은 대략 이런 축으로 정리됩니다.

① 정해진 단계를 쓴다. 엘리베이션은 임의의 그림자 값이 아니라 정해진 레벨 토큰으로 표현합니다. 카드는 카드 레벨, 모달은 모달 레벨처럼, 컴포넌트의 종류와 상태에 맞는 단계를 골라 씁니다.

② 높이는 의미와 일치해야 한다. 더 높은 엘리베이션은 "더 위에 떠 있는 것 = 지금 더 우선되는 것"을 뜻해야 합니다. 모달처럼 사용자의 모든 주의를 끌어야 하는 요소는 깊은 그림자로 확실히 떠 있어야 하고, 배경에 깔린 요소는 낮게 둬야 합니다. 높이와 중요도가 뒤집히면 위계가 거짓말을 합니다.

③ 상태 변화를 높이로 표현할 수 있다. 버튼이나 카드에 마우스를 올리거나(hover), 누르는(pressed) 순간 엘리베이션이 미묘하게 바뀌어 "지금 반응했다"는 피드백을 줄 수 있습니다. 이때도 그 변화는 정해진 단계 사이의 이동이어야지, 매번 다른 임의 값이면 안 됩니다.

④ 과하지 않게. 모든 요소가 떠 있으면 떠 있는 게 하나도 없는 것과 같습니다. 엘리베이션은 "강조하고 싶은 소수"에만 써서, 그것이 도드라지게 만드는 도구입니다. 페이지 전체에 그림자를 뿌리면 위계가 평평해집니다.

⑤ 그림자에만 의존하지 않는다. 엘리베이션을 표현하는 주된 수단은 그림자지만, 그림자는 배경색에 따라 잘 안 보일 수 있고(특히 어두운 배경이나 흰 위에 옅은 그림자), 명도 대비가 약하면 저시력 사용자에게는 거의 전달되지 않습니다. 그래서 위계가 정말 중요한 곳에서는 그림자만 믿지 말고 테두리·배경 차이·간격 같은 다른 단서도 함께 써서, 그림자가 안 보여도 구조가 무너지지 않게 해야 합니다.

이 다섯 가지가 엘리베이션의 "맞는 모습"입니다. 그리고 공공웹에서 가장 많이 틀리는 지점은, 정확히 이 다섯 가지를 거꾸로 한 것들입니다. 이제 그 위반 사례를 하나씩 보겠습니다.

공공웹이 엘리베이션에서 자주 틀리는 지점

지금부터는 현업에서 실제로 반복되는 엘리베이션 실수들입니다. 모두 익명화한 일반적 사례이며, 특정 기관을 지목하지 않습니다. ○○시, A 광역지자체, 한 중앙부처 같은 식으로만 표현하겠습니다. 읽다 보면 "어, 우리 사이트도 이런데" 싶은 게 한두 개는 분명히 나올 겁니다.

위반 1) 모든 카드에 똑같은 진한 그림자 — "다 떠 있으면 아무것도 안 떠 있다"

가장 흔한 실수입니다. 어느 A 광역지자체 포털의 메인 화면을 떠올려 보세요. 공지사항 카드, 민원 바로가기 카드, 행사 안내 카드, 통계 위젯 카드가 격자로 쭉 깔려 있는데, 모든 카드에 똑같이 진한 그림자가 박혀 있습니다. 화면 전체가 마치 책상 위에 던져 놓은 카드 더미처럼 둥둥 떠 보입니다.

겉보기엔 "입체감 있어 보이고 좋네" 싶지만, 사용성으로 보면 정반대입니다. 엘리베이션의 존재 이유는 "소수를 띄워서 강조하는 것"인데, 전부 똑같이 띄우면 강조가 사라집니다. 모든 게 위에 떠 있으면 사용자 입장에선 위계가 평평한 거나 마찬가지죠. 어디부터 봐야 할지 길잡이가 없어집니다.

• 나쁜 예: 메인의 카드 12개가 전부 똑같은 깊은 그림자. 시각적으로 다 같은 높이라 우선순위가 안 보임. 화면이 산만하고 무거움.
• 올바른 예: 기본 카드는 낮은(또는 거의 없는) 엘리베이션으로 차분하게 두고, "이번 주 핵심 공지"나 "긴급 민원"처럼 진짜 강조할 소수만 한 단계 높임. 나머지는 테두리나 배경 구분만으로 충분. 떠 있는 게 적을수록 떠 있는 게 도드라진다.

엘리베이션은 잉크 같은 자원이라고 생각하면 쉽습니다. 한 화면에 쓸 수 있는 "높이감의 총량"이 정해져 있어서, 아무 데나 다 쓰면 정작 강조해야 할 곳에서 쓸 게 남지 않습니다.

위반 2) 모달이 떴는데 배경이 안 어두워진다 — 떠 있는 느낌의 실종

두 번째로 잦은 실수입니다. ○○시의 한 신청 페이지에서, "정말 제출하시겠습니까?"라는 확인 팝업(모달)이 뜹니다. 그런데 모달 뒤의 본문 화면이 그대로 밝게 보이고, 모달과 배경 사이에 높이 차이가 거의 없습니다. 그림자도 옅어서 모달이 "떠 있다"는 느낌이 약합니다. 사용자는 순간 "이게 새 화면으로 바뀐 건가, 아니면 위에 뜬 건가"를 헷갈립니다.

모달은 엘리베이션의 가장 높은 단계를 써야 하는 대표적 컴포넌트입니다. 사용자의 모든 주의를 끌어와서 "지금은 이것만 하세요"라고 말해야 하니까요. 이를 위해 ① 모달 자체에 깊은 그림자를 줘서 확실히 띄우고, ② 뒤 배경을 반투명 어두운 막(딤·오버레이)으로 덮어서 "지금 배경은 비활성"임을 시각적으로 알립니다. 이 둘이 함께 작동해야 모달이 모달답게 보입니다.

• 나쁜 예: 모달에 옅은 그림자만, 배경 딤 없음. 배경 본문이 그대로 또렷해서 어디가 활성 영역인지 모호함. 키보드/스크린리더 사용자에게는 배경 요소가 여전히 잡혀서 더 혼란.
• 올바른 예: 모달은 가장 높은 엘리베이션 단계로 깊게 띄우고, 뒤 배경은 반투명 어두운 오버레이로 덮어 비활성임을 분명히. 동시에 초점(focus)도 모달 안으로 가두어, 시각·코드 양쪽에서 "지금은 모달이 위에 있다"가 일치하게.

여기서 중요한 건, "떠 있다"는 게 눈에 보이는 그림자만의 문제가 아니라는 점입니다. 모달이 시각적으로 위에 떠 있으면, 코드 수준에서도 초점이 모달 안에 머물러야 합니다. 그림자로는 위에 떠 있는데 키보드로는 여전히 배경 버튼이 눌리면, 보이는 것과 작동하는 것이 어긋나서 더 큰 혼란이 됩니다.

위반 3) 그림자 값을 매번 손으로 적는다 — 같은 사이트 안에서 제각각

이건 화면에서 바로 안 보이지만, 코드를 열면 금방 드러나는 실수입니다. 한 중앙부처 사이트의 CSS를 들여다보면, 카드마다 그림자 값이 조금씩 다릅니다. 어떤 카드는 box-shadow: 0 2px 4px rgba(0,0,0,0.1), 옆 카드는 0 3px 6px rgba(0,0,0,0.15), 또 다른 곳은 0 1px 3px rgba(0,0,0,0.2). 디자이너가 시안마다 감으로 정하고, 개발자가 그걸 그대로 받아 적다 보니, 의도하지 않은 미세한 차이가 사이트 전체에 흩어진 겁니다.

사용자가 이 미세한 차이를 의식적으로 알아채진 못합니다. 하지만 무의식적으로는 "왜 이 카드들은 미묘하게 다르게 느껴지지?" 하는 위화감을 받습니다. 더 큰 문제는 유지보수입니다. 나중에 "전체 그림자를 좀 부드럽게 바꾸자"는 결정이 나면, 흩어진 수십 군데를 일일이 찾아 고쳐야 합니다. 하나라도 빠뜨리면 또 제각각이 됩니다.

• 나쁜 예: box-shadow를 컴포넌트마다 인라인으로 직접 적음. 같은 "카드"인데 그림자가 다 다름. 변경 시 전수 수정 필요.
• 올바른 예: 엘리베이션을 디자인 토큰(예: --elevation-1, --elevation-2 같은 CSS 변수)으로 정의해 두고, 모든 컴포넌트가 그 토큰을 참조. 같은 레벨은 항상 같은 값. 바꿀 때는 토큰 한 곳만 고치면 전체에 반영.

KRDS가 컴포넌트 킷(npm install krds-uiux 또는 CDN)으로 토큰화된 스타일을 제공하는 이유가 정확히 이겁니다 — 그림자를 손으로 적다 제각각 되지 말고, 정해진 토큰을 쓰라는 것.

위반 4) 높이와 중요도가 뒤집힌다 — 위계가 거짓말을 한다

미묘하지만 치명적인 실수입니다. B 기관의 한 화면에서, 페이지 한구석의 사소한 보조 위젯(예: "오늘의 날씨" 같은 부가 정보)에 깊은 그림자가 들어가 화면에서 가장 도드라지고, 정작 핵심 행동인 "민원 신청하기" 영역은 평평하게 깔려 있습니다. 시각적 위계가 실제 중요도와 거꾸로 된 거죠.

엘리베이션은 "더 위 = 더 중요/우선"이라는 약속 위에서 작동합니다. 이 약속을 어기면, 사용자의 눈은 그림자가 깊은 쪽으로 끌려가는데 거기엔 정작 별로 안 중요한 게 있습니다. 사용자는 "왜 이게 강조돼 있지?" 하며 핵심을 놓치고 헤맵니다. 그림자가 일종의 거짓 신호를 보내는 셈입니다.

• 나쁜 예: 장식성 위젯이 가장 높은 엘리베이션, 핵심 CTA(신청·검색 등)는 평면. 시선이 엉뚱한 데로 감.
• 올바른 예: 엘리베이션 단계를 정할 때 "이게 사용자에게 얼마나 우선인가"를 기준으로. 핵심 행동·강조 콘텐츠가 높고, 보조 정보는 낮게. 높이의 순서 = 중요도의 순서.

위반 5) 다크 모드/어두운 배경에서 그림자가 사라진다

요즘 일부 공공 사이트가 다크 모드나 어두운 헤더·섹션을 도입합니다. 그런데 밝은 배경 기준으로 만든 옅은 그림자를 어두운 배경에 그대로 얹으면, 그림자가 배경에 묻혀 거의 안 보입니다. 밝은 화면에선 멀쩡하던 카드 구분이 어두운 섹션에선 통째로 사라지는 거죠.

엘리베이션을 그림자 "하나"에만 의존했을 때 생기는 전형적인 사고입니다. 그림자는 밝은 배경 위에서 가장 잘 보이고, 배경이 어두워지면 효과가 급격히 약해집니다. 그래서 어두운 맥락에서는 그림자 대신(또는 함께) 배경 명도를 살짝 올리거나 미세한 테두리를 더해 "떠 있음"을 표현해야 합니다.

• 나쁜 예: 다크 섹션에 밝은 배경용 옅은 그림자 그대로. 카드 경계가 안 보여 콘텐츠가 한 덩어리로 뭉침.
• 올바른 예: 어두운 맥락에서는 표면(surface) 색을 배경보다 살짝 밝게 해서 높이감을 주거나, 옅은 테두리를 보조 단서로 추가. 그림자만 믿지 않기.

위반 6) 호버/포커스 상태에 엘리베이션 피드백이 없거나, 반대로 과하다

클릭 가능한 카드나 버튼에 마우스를 올렸을 때(hover), 미묘한 높이 변화로 "여기 누를 수 있어요"를 알려 주면 좋습니다. 그런데 두 방향으로 다 틀립니다. 한쪽은 아무 변화가 없어서 클릭 가능한지 모호하고, 다른 한쪽은 호버할 때마다 카드가 너무 확 튀어 올라 화면이 출렁입니다.

• 나쁜 예 (부족): 카드가 링크인데 호버해도 아무 반응 없음. 마우스 사용자는 클릭 가능 여부를 확신 못 함.
• 나쁜 예 (과함): 호버 시 그림자가 과도하게 깊어지고 카드가 크게 솟구쳐 레이아웃이 출렁이고 어지러움. 모션에 민감한 사용자에게 불편.
• 올바른 예: 호버 시 정해진 한 단계만 부드럽게 올림(예: 레벨 1 → 레벨 2). 변화는 분명하되 과하지 않게. 그리고 호버에만 의존하지 말고 포커스(focus) 상태에도 같은/유사한 피드백을 줘서 키보드 사용자도 동일하게 인지하게.

마우스에만 호버 효과를 주고 키보드 포커스를 빠뜨리는 경우가 특히 많습니다. 호버는 마우스 전용이라, 키보드로 탐색하는 사용자에게는 그 피드백이 전혀 닿지 않거든요. 엘리베이션 피드백을 줄 거면 포커스에도 함께 줘야 공평합니다.

위반 7) 그림자로 위계를 흉내 내려다 정작 구조(간격·정렬)를 방치

엘리베이션은 위계의 한 도구일 뿐, 전부가 아닙니다. 그런데 가끔 "그림자만 잘 넣으면 정리돼 보이겠지" 하며, 정작 더 기본적인 간격·정렬·여백을 소홀히 한 화면을 봅니다. 카드마다 그림자는 화려한데 카드 사이 간격이 들쭉날쭉하고 정렬이 안 맞으면, 그림자가 아무리 좋아도 산만함은 그대로입니다.

• 나쁜 예: 그림자는 신경 썼는데 카드 간격·정렬이 제각각. 입체감만 있고 질서는 없음.
• 올바른 예: 위계의 1차 도구는 간격·정렬·크기·색이고, 엘리베이션은 그 위에 얹는 보조 신호. 기본 구조를 먼저 잡고, 그 위에 높이감으로 강조를 더하기.

위반 8) 그림자 남용으로 성능과 가독성을 깎아먹기

이건 좀 더 기술적인 실수입니다. 그림자(특히 흐림 반경이 큰 부드러운 그림자)를 화면 수십 개 요소에 동시에, 게다가 애니메이션으로 계속 변하게 하면, 저사양 기기나 모바일에서 스크롤이 버벅일 수 있습니다. 또 그림자가 너무 진하면 그림자가 옆 텍스트 위로 번져 가독성을 떨어뜨리기도 합니다.

• 나쁜 예: 페이지 전체에 크고 진한 그림자를 남발. 저사양 기기에서 스크롤 끊김, 텍스트 주변이 지저분해짐.
• 올바른 예: 그림자는 꼭 필요한 곳에만, 정해진 단계 안에서. 큰 흐림·진한 그림자의 남용을 피하고, 애니메이션은 절제. 성능과 가독성도 디자인의 일부.

위반 9) 드롭다운·툴팁·토스트의 높이를 빼먹는다

엘리베이션을 "카드와 모달"에만 신경 쓰고, 그 사이에 있는 자잘한 떠 있는 요소들을 잊어버리는 경우입니다. 셀렉트를 눌렀을 때 펼쳐지는 목록, 도움말 툴팁, 잠깐 떴다 사라지는 알림 토스트 같은 것들이죠. 이 요소들은 본문 위에 "잠깐 떠 있는" 성격이라 적절한 엘리베이션 단계가 필요한데, ○○시의 한 페이지에서는 셀렉트 펼침 목록이 배경과 같은 높이로 평평하게 깔려서, 펼쳐진 목록이 아래 본문 텍스트와 시각적으로 뒤섞입니다. 사용자는 "이게 펼쳐진 메뉴인지 그냥 본문인지" 한순간 헷갈립니다.

• 나쁜 예: 드롭다운 펼침 목록·툴팁이 그림자 없이 본문과 같은 평면. 떠 있는지 안 떠 있는지 모호하고 아래 내용과 겹쳐 보임.
• 올바른 예: 이런 "임시로 떠 있는" 요소들에 카드보다 한 단계 높은(모달보다는 낮은) 엘리베이션을 줘서, 본문 위에 분명히 얹혀 있음을 표시. KRDS 킷의 해당 컴포넌트를 쓰면 이 단계가 이미 지정돼 있다.

엘리베이션 단계는 "카드·모달" 두 개가 아니라, 바닥부터 모달까지 여러 층으로 이뤄진 사다리입니다. 그 중간 층들(드롭다운·툴팁·토스트)을 빼먹으면 사다리에 구멍이 생기고, 그 구멍에서 사용자가 헷갈립니다.

위반 10) 그림자를 테두리 대용으로만 쓰다 위계가 사라진다

반대 방향의 실수도 있습니다. 카드를 구분하려고 그림자를 넣긴 했는데, 그게 너무 옅어서 "테두리 한 줄"만도 못한 경우입니다. A 광역지자체의 한 목록 화면에서, 카드들이 흰 배경 위에 거의 안 보이는 그림자만 두르고 있어, 화면을 빠르게 훑으면 카드 경계가 안 잡히고 정보가 한 덩어리로 뭉쳐 보입니다. "그림자를 넣었으니 됐지"라고 생각했지만, 사실상 위계 표현이 작동하지 않는 거죠.

• 나쁜 예: 흰 배경에 거의 안 보이는 옅은 그림자만. 카드 구분이 안 돼 정보가 뭉쳐 보임. 저시력 사용자에게는 아예 경계가 없는 것과 같음.
• 올바른 예: 위계가 중요한 곳은 그림자만 믿지 말고 배경색 차이·여백·(필요하면) 옅은 테두리를 함께 써서 구분을 분명히. 그림자는 "더하는 강조"이지 "유일한 구분선"이 아니다.

한 장면 — 같은 모달, 두 가지 결과

추상적인 설명보다 한 장면이 빠를 것 같습니다. 어느 공공 서비스의 "신청 취소" 확인 모달을 떠올려 봅시다.

잘못된 버전. 사용자가 "취소" 버튼을 누르자 확인 팝업이 뜹니다. 그런데 뒤 배경이 그대로 환하고, 모달도 옅은 그림자만 살짝 있어 떠 있는 느낌이 약합니다. 사용자는 순간 멈칫합니다. "어, 화면이 바뀐 건가? 아니면 위에 뜬 건가?" 게다가 키보드로 Tab을 눌러 보니 초점이 모달을 벗어나 뒤 배경의 메뉴로 가 버립니다. 시각적으로도 코드로도 "지금 무엇이 위에 있는지"가 흐릿합니다. 결국 사용자는 모달 바깥의 엉뚱한 버튼을 눌러 의도치 않은 행동을 하고, 다시 처음으로 돌아가야 합니다.

올바른 버전. 같은 상황. "취소" 버튼을 누르자 모달이 깊은 그림자와 함께 또렷하게 떠오르고, 뒤 배경이 반투명 어두운 막으로 덮여 "지금 배경은 비활성"임을 분명히 합니다. 키보드 초점은 모달 안에 갇혀, Tab을 눌러도 "예/아니오" 버튼 사이만 오갑니다. 사용자는 한눈에 "지금은 이 팝업만 다루면 되는구나"를 알고, 망설임 없이 "예"를 누릅니다. 5초도 안 걸립니다.

같은 모달, 같은 기능. 차이를 만든 건 거창한 기술이 아니라, 엘리베이션을 제대로 썼느냐 하나입니다. 깊은 그림자 + 배경 딤 + 초점 가두기. 이 세 가지가 함께 작동하면 모달은 모달답게 보이고, 하나라도 빠지면 "이게 뭐지" 하는 멈칫거림이 생깁니다. 그리고 그 멈칫거림은 곧 잘못된 클릭, 중도 포기, 민원 콜로 이어집니다.

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

여기까지 읽고 "그림자 하나에 뭘 이리 깐깐하나" 싶으실 수 있습니다. 그런데 엘리베이션의 요건들은 누가 멋 부리려고 만든 게 아니라, 실제 사용자가 막히는 지점에서 역으로 도출된 것들입니다.

깊이는 인간이 세상을 읽는 기본 방식이다

사람은 평생 3차원 세계에서 살아왔기 때문에, "위에 있는 것 = 가깝고 중요한 것"이라는 감각이 본능에 가깝게 박혀 있습니다. 책상 위에 서류를 쌓아 두면, 맨 위 서류가 지금 다루는 것이라고 누가 말 안 해도 압니다. 화면의 엘리베이션은 이 본능을 빌려 옵니다. 그래서 높이감을 제대로 쓰면 사용자는 설명 없이도 위계를 직관적으로 읽습니다. 반대로 높이감이 엉터리면, 그 본능이 거짓 정보를 받아 혼란스러워집니다. 엘리베이션 위반이 "왠지 모르게 불편한" 느낌을 주는 이유가 여기 있습니다 — 본능 수준의 신호가 어긋나니까요.

공공 서비스는 "안 쓸 자유"가 없다

상업 사이트는 디자인이 산만하면 사용자가 떠나면 그만입니다. 그런데 공공 서비스는 다릅니다. 등본을 떼거나 세금을 내거나 지원금을 신청하는 일은 그 사이트가 아니면 할 수 없습니다. 사용자가 "안 쓸 자유"가 없어요. 그래서 모달이 떠 있는지 안 떠 있는지 헷갈려서 엉뚱한 버튼을 누르거나, 위계가 평평해서 핵심 기능을 못 찾는 일이, 단순 불편을 넘어 "민원을 못 끝내는" 문제로 직결됩니다. 위계의 혼란은 그대로 행정 서비스 접근의 장벽이 됩니다.

그림자는 "전달이 약한" 신호라 더 조심해야 한다

엘리베이션이 까다로운 이유 중 하나는, 그림자가 본질적으로 "약한" 신호라는 점입니다. 색은 누구에게나 비교적 분명히 전달되지만, 옅은 그림자는 배경·조명·화면 밝기·시력에 따라 보일 수도 안 보일 수도 있습니다. 저시력 사용자에게는 옅은 그림자가 아예 없는 것과 같고, 야외에서 밝은 햇빛 아래 스마트폰을 보는 사람에게도 그림자는 거의 안 보입니다. 그래서 KRDS를 비롯한 좋은 디자인 시스템은 "그림자만으로 결정적 위계를 표현하지 말라"고 합니다. 정말 중요한 구분은 간격·테두리·배경색 같은, 더 튼튼하게 전달되는 단서로 받쳐 둬야 한다는 거죠. 엘리베이션은 "더하면 좋은 강조"이지, "이것만 믿어도 되는 유일한 위계 수단"이 아닙니다.

일관성이 곧 학습 비용 절감

정부 사이트마다 그림자와 높이감이 제각각이면, 사용자는 사이트를 옮길 때마다 "여기선 뭐가 떠 있는 거지?"를 다시 익혀야 합니다. 모든 공공 서비스가 같은 엘리베이션 문법(카드는 이 정도 높이, 모달은 이 정도 높이)을 쓰면, 한 번 익힌 감각이 모든 사이트에서 통합니다. 디지털 약자에게 이 "다시 안 배워도 됨"은 생각보다 큰 배려입니다. 엘리베이션 토큰을 표준화하는 건 디자이너의 자유를 뺏는 게 아니라, 국민의 인지 부담을 더는 일입니다.

작아 보이는 스타일일수록 방치되기 쉽다

역설적이지만, 엘리베이션처럼 "은근한" 스타일일수록 품질 관리에서 밀려납니다. 색이 틀리면 누구나 잡지만, 그림자가 한 단계 깊거나 얕은 건 아무도 깐깐하게 굴지 않거든요. 그런데 사용자가 화면을 "읽는" 그 무의식의 과정에서, 엘리베이션은 생각보다 큰 역할을 합니다. 가장 덜 주목받는 스타일이 사실은 화면의 질서를 좌우하는 셈입니다. KRDS가 엘리베이션을 별도 스타일 항목으로 정리해 둔 건, 바로 이 "방치되기 쉬운 곳"에서 품질이 무너지는 걸 막기 위해서입니다.

직접 고치기 — 개발자·디자이너·기획자 가이드

위반을 알았으니 이제 고치는 법입니다. KRDS의 좋은 점은, 엘리베이션을 "알아서 잘 쓰세요"로 끝내지 않고 바로 쓸 수 있는 자산으로 제공한다는 것입니다.

개발자라면 — 가장 먼저 할 일은 흩어진 box-shadow를 토큰으로 모으는 것입니다. CSS 변수(--elevation-0 ~ --elevation-N)로 단계를 정의하고, 모든 컴포넌트가 인라인 값 대신 그 변수를 참조하게 바꾸세요. KRDS 컴포넌트 킷을 npm install krds-uiux로 설치하거나 CDN(krds.min.css / krds.min.js)으로 불러오면, 토큰화된 스타일과 컴포넌트(카드·모달·드롭다운 등)가 이미 정의된 상태로 시작할 수 있습니다. 저장소(github.com/KRDS-uiux/krds-uiux)의 코드를 참고하면, 모달의 그림자·오버레이·초점 처리가 어떻게 한 세트로 묶여 있는지 볼 수 있습니다. 직접 만들다 빠뜨리지 말고 검증된 걸 가져다 쓰는 게 핵심입니다.

디자이너라면 — KRDS 공식 Figma(@krds) 라이브러리에서 엘리베이션 토큰과 그것이 적용된 컴포넌트를 그대로 가져다 쓸 수 있습니다. 시안을 그릴 때 그림자 값을 매번 손으로 정하지 말고, 정해진 레벨 스타일을 적용하세요. 그리고 시안 단계에서부터 "이 화면에서 엘리베이션을 쓸 곳은 어디, 안 쓸 곳은 어디"를 명시해 두면, 개발 단계에서 "모든 카드에 그림자 박기" 같은 사고를 미리 막을 수 있습니다.

기획자라면 — 화면 정의서에 "카드 영역"이라고만 적지 말고, "이 영역에서 강조할 요소(높은 엘리베이션)는 무엇, 배경으로 둘 요소는 무엇"처럼 위계를 함께 명시하세요. 특히 모달·팝업을 정의할 때는 "배경 비활성 처리(딤) 필요"를 한 줄 적어 두면, 디자인·개발 단계의 누락을 막습니다. 위계는 디자인의 영역만이 아니라 기획의 영역이기도 합니다.

세 팀이 같은 토큰을 보고 일하면 "이건 너희 일"이라는 논쟁이 줄어듭니다. KRDS가 디자인(Figma)·코드(GitHub 킷)·문서(가이드라인)를 한 세트로 제공하는 이유가 그겁니다.

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

여기까지가 엘리베이션에서 흔한 위반과 고치는 법입니다. 그런데 정작 어려운 건 "그래서 우리 사이트는 이걸 틀리고 있나, 아닌가?"를 확인하는 일입니다. 페이지마다 카드 그림자가 일관된지, 모달에 배경 딤이 들어가는지, 그림자 값이 토큰으로 관리되는지 사람이 일일이 눈과 손으로 점검하려면 끝이 없습니다. 페이지가 수십·수백 개인 공공 사이트라면 더더욱요.

ViewCheck(krds.viewcheck.co.kr)는 이 점검을 자동화합니다. URL만 넣으면 페이지를 실제로 크롤링해서, 디자인 스타일이 KRDS 기준을 지키는지 판정합니다. 엘리베이션은 KRDS 846규칙 중 디자인 시스템(DS) 규칙군 120개에 속하는 영역이고, 분석 결과의 디자인 시스템(Design System) 탭에서 확인할 수 있습니다. ViewCheck는 페이지의 실제 computed style(브라우저가 최종 계산한 스타일)을 읽어서, 그림자·색·간격 같은 수치를 KRDS 토큰 기준과 비교합니다.

ViewCheck가 엘리베이션과 관련해 자동으로 보는 것들(앵글에 맞춰 요약):

• 디자인 토큰 채택률: 그림자(box-shadow)를 비롯한 스타일 값이 KRDS 토큰을 따르는지, 아니면 임의의 인라인 값으로 흩어져 있는지. "토큰 채택률" 리포트로 한눈에.
• 일관성 점검: 같은 종류의 요소(카드 등)가 사이트 안에서 일관된 스타일을 쓰는지, 페이지마다 제각각인지.
• 시각적 보강 판정: DOM의 수치만으로 판단하기 애매한 시각적 부분(예: 모달이 실제로 떠 보이는지, 배경 딤이 들어갔는지)은 KRDScan Vision AI가 스크린샷을 함께 보고 보강 판정합니다. 그래서 "코드상으로는 애매한데 화면엔 분명히 문제가 있는" 경우도 놓치지 않습니다.

이 점이 단순 코드 검사 도구와 다른 부분입니다 — 사람이 눈으로 보듯 화면을 함께 보기 때문에, 코드만으로는 안 드러나는 시각적 위계 문제까지 잡아냅니다.

리포트를 어떻게 읽나

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

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

자주 묻는 질문

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

Q. 엘리베이션, 그냥 그림자(box-shadow) 얘기 아닌가요? 굳이 어려운 용어를 써야 하나요?

그림자가 엘리베이션을 표현하는 주된 수단인 건 맞습니다. 하지만 엘리베이션은 "그림자 값"이 아니라 "높이라는 개념"입니다. 같은 높이(레벨)를 어떤 화면에선 그림자로, 어떤 화면(어두운 배경)에선 배경색 차이나 테두리로 표현할 수 있어요. "그림자"라고만 생각하면 다크 모드에서 그림자가 사라질 때 대안을 못 찾습니다. "이 요소는 레벨 2의 높이를 가져야 한다"고 개념으로 생각하면, 맥락에 맞는 표현 방법을 고를 수 있습니다. 용어가 거창해 보여도, 그 차이가 실무에서 꽤 큽니다.

Q. 우리 디자이너가 카드마다 그림자를 다르게 주는 게 더 풍부해 보인다고 합니다.

"풍부함"과 "산만함"은 종이 한 장 차이입니다. 그림자를 다양하게 주면 처음엔 입체감 있어 보이지만, 사용자가 무의식적으로 "이 차이에 의미가 있나?"를 계속 해석하게 만들어 인지 부담을 늘립니다. 엘리베이션은 의미를 전달하는 신호이지 장식이 아니라는 점을 짚어 주세요. 정말 풍부함을 원한다면 색·이미지·여백으로 표현하고, 높이감만큼은 정해진 단계로 통일하는 게 좋습니다. 특히 "안 쓸 자유가 없는" 공공 서비스라면 더더욱 명료함이 우선입니다.

Q. 모달에 배경 딤(어두운 막)이 꼭 필요한가요? 디자인상 너무 무거워 보여서요.

필요합니다. 배경 딤은 단순히 어두워 보이게 하는 장식이 아니라, "지금 배경은 비활성이고 이 모달만 다루세요"라는 기능적 신호입니다. 딤이 없으면 사용자가 모달 바깥을 클릭해도 되는지, 배경 내용이 여전히 유효한지 헷갈립니다. 무거워 보이는 게 걱정이면 딤의 투명도를 조절하면 됩니다(완전 검정이 아니라 적당히 비치는 정도로). 딤 자체를 빼는 건 권하지 않습니다.

Q. 그림자 값을 토큰으로 바꾸려니 이미 만든 페이지가 너무 많습니다. 전부 다시 해야 하나요?

전부 한 번에 갈아엎을 필요는 없습니다. 먼저 ViewCheck로 현황을 확인해 "어느 페이지의 어떤 요소가 토큰을 벗어나 있는지"를 목록으로 만든 다음, 사용 빈도가 높은 핵심 페이지(메인·신청·로그인 등)부터 토큰으로 교체하세요. 새 CSS 변수를 정의해 두고, 기존 인라인 그림자를 점진적으로 변수 참조로 바꿔 나가면 됩니다. 한 번에 토큰 체계만 잡아 두면, 그다음부터는 새로 만드는 화면은 자동으로 일관성을 갖춥니다.

Q. 다크 모드를 도입할 계획인데, 엘리베이션을 어떻게 처리해야 하나요?

어두운 배경에서는 그림자가 거의 안 보이므로, "표면(surface) 밝기"로 높이감을 표현하는 방식을 권합니다. 즉 더 높이 떠 있는 요소일수록 배경보다 살짝 더 밝은 색을 줘서 떠 있는 느낌을 내는 거죠(많은 디자인 시스템이 다크 모드에서 이 방식을 씁니다). 그림자를 함께 쓰더라도, 그림자만으로 위계를 결정하지 말고 표면 밝기와 테두리를 보조 단서로 두세요. 밝은 모드와 어두운 모드 각각에 맞는 엘리베이션 토큰을 따로 정의해 두면 깔끔합니다.

Q. 호버 효과로 카드가 떠오르게 했는데, 키보드 사용자는 이걸 못 본다고요?

맞습니다. 호버(hover)는 마우스 포인터를 올렸을 때만 발생하는 이벤트라, 키보드로 Tab을 눌러 탐색하는 사용자에게는 전혀 닿지 않습니다. 그래서 호버에 엘리베이션 피드백을 줄 거면, 포커스(focus, 키보드로 그 요소에 도달했을 때) 상태에도 같거나 유사한 피드백을 줘야 공평합니다. CSS로 말하면 :hover만 쓰지 말고 :focus나 :focus-visible에도 같은 스타일을 적용하는 거죠. 그래야 마우스 사용자와 키보드 사용자가 같은 정보를 받습니다.

Q. 그림자가 성능에 영향을 준다는 게 사실인가요?

부드럽고 큰 그림자(흐림 반경이 큰)를 화면의 많은 요소에 동시에 쓰거나, 그걸 스크롤·애니메이션과 함께 계속 다시 그리게 하면, 저사양 기기나 모바일에서 렌더링 부담이 커져 스크롤이 버벅일 수 있습니다. 일반적인 카드 몇 개에 적당한 그림자를 주는 정도는 문제없지만, "페이지 전체에 진하고 큰 그림자를 남발"하는 건 피하는 게 좋습니다. 엘리베이션을 꼭 필요한 곳에만 절제해서 쓰면, 위계도 살고 성능도 지킬 수 있습니다.

Q. ViewCheck는 그림자가 "예쁜지"까지 봐주나요?

"예쁨"은 주관의 영역이라 ViewCheck가 미감을 평가하진 않습니다. 대신 객관적으로 검증 가능한 것들을 봅니다 — 그림자 값이 KRDS 토큰을 따르는지, 사이트 안에서 일관되는지, 임의의 인라인 값으로 흩어져 있지 않은지 같은 것들이요. 그리고 모달의 배경 딤처럼 시각적으로 확인이 필요한 부분은 Vision AI가 화면을 보고 보강합니다. "예쁜가"가 아니라 "기준을 지켰는가"를 채점하는 도구라고 생각하시면 됩니다. 미감은 디자이너의 몫, 기준 준수 점검은 ViewCheck의 몫입니다.

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

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) → 검증된 코드로 고치는(킷) 한 바퀴가 완성됩니다.

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

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

• ☐ 그림자 값을 컴포넌트마다 인라인으로 적지 않고, 정해진 토큰(레벨)으로 관리한다.
• ☐ 같은 종류의 요소(카드 등)는 사이트 안에서 일관된 엘리베이션을 쓴다(같은 카드인데 그림자가 제각각이지 않다).
• ☐ 모든 요소에 그림자를 박지 않았다 — 강조할 소수에만 높이감을 줬다.
• ☐ 엘리베이션의 높이 순서 = 중요도 순서다(사소한 게 도드라지고 핵심이 평평하지 않다).
• ☐ 모달·다이얼로그는 가장 높은 단계로 확실히 띄우고, 뒤 배경에 반투명 딤(오버레이)을 넣었다.
• ☐ 모달이 떠 있을 때 키보드 초점이 모달 안에 갇힌다(보이는 위계와 코드의 동작이 일치한다).
• ☐ 어두운 배경/다크 모드에서는 그림자에만 의존하지 않고 표면 밝기·테두리로 높이감을 보강했다.
• ☐ 호버 피드백을 줄 때 포커스(focus) 상태에도 같은 피드백을 줘서 키보드 사용자도 인지한다.
• ☐ 호버 시 높이 변화가 과하지 않다(레이아웃이 출렁이거나 어지럽지 않다).
• ☐ 위계의 1차 도구(간격·정렬·크기·색)를 먼저 챙기고, 엘리베이션은 그 위의 보조 신호로 썼다.
• ☐ 크고 진한 그림자를 남발하지 않아 성능·가독성을 해치지 않는다.

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

엘리베이션은 작아 보이지만, 화면의 "질서"를 좌우합니다. 그림자 한 단계의 차이가 사용자에게는 "지금 뭘 봐야 하는지"의 차이로 다가오고, 모달의 배경 딤 하나가 "이게 떠 있는 건지 아닌지"의 혼란을 가르며, 토큰화 하나가 사이트 전체의 일관성과 유지보수성을 결정합니다. 우리가 무심코 박아 둔 그림자 하나가, 누군가에게는 화면을 매끄럽게 읽게 하고 또 누군가에게는 멈칫거리게 만듭니다.

오늘 정리한 위반들이 많아 보여도, 핵심은 결국 단순합니다. 그림자를 토큰으로 통일하고, 떠 있어야 할 것만 띄우고, 높이와 중요도를 일치시키고, 그림자만 믿지 않는 것. 이 네 가지만 챙겨도 엘리베이션 위반 대부분은 사라집니다. 그리고 그게 잘 됐는지는 ViewCheck로 몇 분이면 확인할 수 있습니다. 완벽을 한 번에 만들 필요는 없습니다. 가장 헷갈리는 모달 하나, 가장 산만한 메인 하나부터 고쳐 나가면, 우리 사이트는 분명히 조금씩 더 또렷하고 읽기 편해집니다. 다음 글에서는 엘리베이션과 짝을 이루는 또 다른 스타일 요소를 같은 방식으로 뜯어보겠습니다.

우리 사이트의 그림자와 높이감은 지금 일관될까요? krds.viewcheck.co.kr에서 URL만 넣으면 무료로 확인할 수 있습니다. 메인 페이지 하나만 돌려 봐도, 디자인 토큰 채택률과 위 체크리스트가 실제로 지켜지고 있는지 바로 보입니다.

#KRDS #공공웹 #디자인시스템 #엘리베이션Elevation #웹접근성 #ViewCheck #정부웹사이트 #UIUX #그림자 #디자인토큰 #UI위계 #모달디자인 #엘리베이션 #Elevation #흔한실수 #개선사례 #안티패턴 #디자인스타일 #전자정부 #디지털정부