아이콘(Icon) 완전 해부 — KRDS 공식 기준

증명서 한 장을 떼려고 어느 공공 서비스에 들어갔다고 해봅시다. 화면 맨 위에 작은 그림 네댓 개가 줄지어 있습니다. 돋보기, 사람 얼굴, 톱니바퀴, 줄 세 개, 그리고 정체불명의 동그라미 하나. 앞의 네 개는 "검색, 로그인, 설정, 메뉴겠지" 하고 짐작이 갑니다. 그런데 그 동그라미 하나에서 손이 멈칫합니다. "이게 뭐지?" 마우스를 올려 보고, 한참 뒤에야 "아, 챗봇 상담이었구나" 합니다. 이 짧은 멈칫거림. 별것 아닌 것 같지만, 같은 사용자가 하루에도 여러 공공 사이트에서 이 멈칫거림을 반복한다면, 그리고 그 사용자가 화면을 눈으로 볼 수 없는 사람이라면, 이야기는 완전히 달라집니다.

아이콘은 화면에서 가장 작은 요소이지만 가장 자주 잘못 다뤄지는 요소이기도 합니다. 잘 쓰면 긴 설명 없이 기능을 한눈에 알리고, 잘못 쓰면 사용자를 끝없는 추측 게임에 빠뜨립니다. 그리고 시각장애인이나 인지적 도움이 필요한 사용자에게는, 정체불명의 아이콘 하나가 그냥 "넘을 수 없는 벽"이 됩니다. 그래서 정부 디자인 시스템인 KRDS는 아이콘을 "알아서 예쁘게 쓰세요"로 방치하지 않고, 별도의 스타일 가이드 항목으로 정리해 두었습니다.

이 글은 그 KRDS 아이콘 기준을 처음부터 끝까지 해부하는 글입니다. "이렇게 하면 예뻐 보인다"가 아니라, "정부 표준은 아이콘에 무엇을 요구하는가"를 사실 기준으로 하나하나 뜯어보겠습니다. KRDS 공식 스타일 가이드(아이콘 항목)와 컴포넌트 킷, 그리고 디지털 정부서비스 UI/UX 가이드라인(2025.08판)을 1차 원천으로 삼고, 거기에 한국형 웹 접근성 지침(KWCAG)과 확립된 UX 원칙을 더해 정리합니다. 다 읽고 나면 어떤 사이트의 아이콘을 봐도 "이건 표준을 지킨 아이콘, 저건 위험한 아이콘"이 눈에 들어오실 겁니다.

미리 한 가지만 일러두겠습니다. 여기서 말하는 "아이콘을 제대로 쓴다"는 건 "더 화려하게 그린다"가 절대 아닙니다. 오히려 반대입니다. 독창성보다 명료함을, 표현의 자유보다 일관성을, 시각적 효과보다 누구나 알아볼 수 있는 분명함을 택하는 일입니다. 디자이너에게는 다소 답답할 수도 있습니다. 하지만 공공 서비스를 쓰는 사람은 디자인을 감상하러 온 게 아니라 볼일을 보러 온 국민이라는 사실을 떠올리면, 답은 분명합니다. 아이콘은 그 볼일로 가는 길을 가리키는 이정표여야지, 그 자체로 감상의 대상이 될 필요는 없습니다.

아이콘이란 무엇인가 — 정의부터 정확히

먼저 용어부터 맞추겠습니다. 우리가 "아이콘"이라고 뭉뚱그려 부르는 것들은 사실 한 덩어리가 아닙니다. 크게 두 종류로 나뉩니다.

• 시스템 아이콘(기능 아이콘): 검색·메뉴·닫기·홈·다운로드처럼 기능이나 동작을 나타내는, 단순하고 일관된 픽토그램. 화면 어디서나 반복적으로 쓰이며, 사용자가 "이걸 누르면 무슨 일이 일어난다"를 직관적으로 알게 하는 게 목적입니다.
• 일러스트·브랜드 그래픽: 페이지를 꾸미거나 분위기를 전달하는 그림. 빈 상태 화면의 일러스트, 캠페인 배너의 그래픽 같은 것들입니다. 이건 아이콘 시스템의 영역이 아니라 별도의 비주얼 자산입니다.

KRDS의 아이콘 스타일 가이드가 다루는 핵심은 바로 첫 번째, 시스템 아이콘입니다. 왜 이걸 굳이 표준으로 묶어 두었을까요? 답은 단순합니다. 모든 공공 사이트가 "검색"을 제각각 다른 돋보기 모양으로 그리고, "닫기"를 어떤 곳은 X로 어떤 곳은 화살표로 그리면, 사용자는 사이트를 옮길 때마다 "이게 검색이 맞나?", "이게 닫기인가?"를 다시 판단해야 합니다. 같은 의미는 같은 모양으로 — 이 약속 하나가 수백 개 정부 사이트를 오가는 국민의 인지 부담을 크게 줄입니다.

여기서 중요한 인식의 전환이 하나 필요합니다. 아이콘 시스템은 디자이너의 표현을 제한하려는 게 아니라, 사용자가 "한 번 배우면 어디서나 통하는" 공용 언어를 만들려는 시도라는 점입니다. 영어를 처음 배울 때 알파벳을 외우듯, 사용자는 "이 모양은 검색", "이 모양은 메뉴"를 한 번 배웁니다. 그 배움이 모든 정부 사이트에서 통하게 만드는 것 — 그게 표준 아이콘의 존재 이유입니다.

KRDS 아이콘 시스템 — 표준 SVG 세트의 의미

KRDS는 공식 컴포넌트 킷(GitHub KRDS-uiux/krds-uiux)을 통해 시스템 아이콘을 SVG 형식으로 제공합니다. 검색·홈·메뉴·닫기·화살표·체크·경고처럼 공공 서비스에서 반복적으로 쓰이는 기능들을 위한 표준 아이콘 세트입니다. 이 세트를 그대로 가져다 쓰면, 디자이너가 매번 아이콘을 새로 그릴 필요도, 외부 무료 아이콘 사이트에서 라이선스를 신경 쓰며 긁어올 필요도 없습니다.

KRDS가 아이콘을 SVG로 제공한다는 사실 자체에 메시지가 담겨 있습니다. SVG는 벡터 형식이라 크기를 아무리 키워도 깨지지 않습니다. 16px로 쓰든 48px로 쓰든 선이 또렷합니다. 또 SVG는 코드로 직접 접근성 속성을 붙이기 좋습니다. aria-hidden을 달거나, <title> 요소로 이름을 줄 수 있죠. 반면 아이콘 폰트 방식은 폰트 로딩에 실패하면 깨진 글자(□)가 보이거나, 스크린리더가 엉뚱한 글자로 읽는 문제가 있습니다. KRDS가 굳이 SVG를 택한 데에는, "선명함"과 "접근성"이라는 두 가지 이유가 동시에 깔려 있는 셈입니다.

그리고 한 가지 더. 표준 세트를 제공한다는 건 "이 안에 있는 걸 먼저 쓰라"는 권고이기도 합니다. 새 아이콘을 만들기 전에 "이미 표준 세트 안에 있는가"를 먼저 확인하는 습관. 이게 일관성의 출발점입니다. 표준에 있는 검색 아이콘을 두고 굳이 새 돋보기를 그리는 건, 공용 언어를 깨뜨리는 일이니까요.

KRDS는 아이콘에 무엇을 요구하나 — 기준 해부

아이콘을 화면에 얹는 건 쉽습니다. 어려운 건 "제대로" 얹는 것입니다. KRDS 가이드라인과 웹 접근성 기준을 종합하면, 아이콘이 충족해야 할 요건은 다음과 같이 정리됩니다. 하나씩 보겠습니다.

1) 의미 있는 아이콘과 장식 아이콘을 구분하라

가장 먼저 던져야 할 질문은 "이 아이콘이 의미를 가지는가, 아니면 장식인가"입니다. 둘은 코드에서 완전히 다르게 다뤄야 합니다.

• 의미 있는 아이콘: 그 자체가 정보나 기능을 전달합니다. 예를 들어 텍스트 없이 돋보기만 있는 검색 버튼. 이 경우 아이콘에 접근 가능한 이름(대체 텍스트)이 반드시 있어야 합니다. 스크린리더가 "검색, 버튼"이라고 읽을 수 있도록요.
• 장식 아이콘: 옆에 이미 텍스트 라벨이 있어서, 아이콘은 그저 시각적 보조일 뿐인 경우. "검색"이라는 글자 옆에 돋보기가 붙어 있다면, 이 돋보기는 장식입니다. 이때는 오히려 스크린리더가 아이콘을 무시하도록(aria-hidden="true") 해야 합니다. 안 그러면 "이미지 검색"처럼 중복으로 읽혀 거슬립니다.

이 구분을 안 하면 정반대 오류가 동시에 납니다. 의미 있는 아이콘엔 이름이 없어서 못 읽히고, 장식 아이콘은 쓸데없이 읽혀서 시끄러워집니다. 둘 다 사용자 경험을 망가뜨립니다.

판단이 헷갈릴 때 쓰는 간단한 질문이 있습니다. "이 아이콘을 통째로 지워도, 사용자가 같은 정보를 얻을 수 있나?" 지워도 옆 텍스트로 충분히 알 수 있으면 그 아이콘은 장식입니다(숨기세요). 지웠더니 무슨 기능인지 알 수 없게 되면 그건 의미 있는 아이콘입니다(이름을 주세요). 예를 들어 "다운로드"라는 글자 옆 화살표 아이콘은 지워도 "다운로드"가 남으니 장식입니다. 반면 텍스트 없이 화살표 아이콘만 있는 다운로드 버튼은 지우면 빈 버튼이 되니 의미 있는 아이콘입니다. 이 한 가지 질문이 대부분의 경우를 가려 줍니다.

한 가지 더 주의할 점. 같은 아이콘이라도 맥락에 따라 의미와 장식이 바뀝니다. 똑같은 돋보기라도 "검색" 텍스트 옆에 있으면 장식, 툴바에 혼자 있으면 의미 있는 아이콘입니다. 그래서 "이 아이콘은 항상 장식"이라고 일괄 처리하면 안 되고, 쓰이는 자리마다 판단해야 합니다. 컴포넌트를 만들 때 이 점을 옵션으로 열어 두면(라벨을 받으면 의미, 안 받으면 장식), 재사용이 깔끔해집니다.

2) 아이콘 전용 버튼에는 반드시 이름을 붙여라

공공웹에서 가장 흔한 아이콘 사고가 여기서 납니다. 햄버거(줄 세 개) 하나만 있는 메뉴 버튼, 돋보기 하나만 있는 검색 버튼, 톱니바퀴 하나만 있는 설정 버튼 — 텍스트 라벨이 전혀 없는 "아이콘 전용 버튼"입니다.

마우스 쓰는 사람은 모양으로 짐작하지만, 스크린리더 사용자에게는 이름이 없으면 그냥 "버튼"으로만 읽힙니다. 무엇을 하는 버튼인지 알 수 없죠. 그래서 아이콘 전용 버튼에는 aria-label이나 화면에는 안 보이지만 코드엔 있는 텍스트(visually hidden)로 "메뉴 열기", "검색", "설정" 같은 이름을 반드시 부여해야 합니다. 이건 선택적 권장이 아니라 접근성의 기본 요건입니다.

3) 충분한 크기와 터치 영역

아이콘은 작게 그려지기 쉽지만, 그게 곧 "작게 눌러도 된다"는 뜻은 아닙니다. 특히 아이콘이 버튼 역할을 할 때, 손가락이나 마우스로 누를 수 있는 영역은 충분해야 합니다. 한국형 웹 접근성 지침(KWCAG)과 국제 표준 모두 터치 대상의 최소 크기를 권장하는데, 보통 한 변 44px 이상을 기준으로 봅니다. 아이콘 그림 자체는 작아도, 그것을 감싸는 클릭/터치 영역은 이 기준을 채워야 합니다. 그림 픽셀에만 클릭이 걸려 있으면, 손이 살짝만 빗나가도 안 눌리니까요.

4) 색에만 의존하지 않기 + 충분한 대비

아이콘이 상태를 나타낼 때(예: 빨간 경고 아이콘, 초록 완료 아이콘) 색만으로 의미를 전달하면, 색 구분이 어려운 사용자는 그 의미를 놓칩니다. 모양이나 텍스트가 함께 의미를 받쳐 줘야 합니다. "오류는 빨간 점, 정상은 초록 점"이 아니라 "오류는 빨간 경고 삼각형 + 텍스트, 정상은 초록 체크 + 텍스트"처럼요. 또 아이콘과 배경의 명도 대비가 충분해야 흐릿하게 보이지 않습니다. 연한 회색 아이콘을 흰 배경에 얹어 두면, 저시력 사용자에게는 거의 보이지 않습니다.

5) 일관성 — 같은 의미는 같은 아이콘

한 사이트 안에서 "닫기"를 어떤 곳은 X로, 어떤 곳은 화살표로 표현하면 사용자가 헷갈립니다. KRDS 아이콘 시스템을 쓰는 핵심 이유가 이 일관성입니다. 같은 동작에는 같은 아이콘을, 그리고 가능하면 KRDS 표준 아이콘을 써서 다른 정부 사이트와도 일관되게 맞추는 것. 임의로 새 아이콘을 만들기 전에 "표준 세트 안에 이미 있는가"를 먼저 확인하는 습관이 필요합니다.

6) 크기·정렬·여백의 규칙

아이콘은 텍스트와 나란히 놓일 때가 많습니다. 이때 아이콘과 글자의 세로 중심이 맞아야 하고, 아이콘 크기가 텍스트 크기와 조화로워야 합니다. 제각각인 크기의 아이콘이 한 줄에 섞여 있으면 화면이 들쭉날쭉 어수선해 보입니다. KRDS가 아이콘을 SVG로 제공하는 것도, 어느 크기에서나 선명하게 정렬되도록 하기 위함입니다.

7) 누를 수 있는 아이콘에는 초점 표시를

아이콘이 버튼·링크 역할을 한다면, 키보드로 그 위에 초점이 왔을 때 시각적으로 또렷하게 표시돼야 합니다. 텍스트 버튼과 마찬가지로, 아이콘 버튼도 Tab으로 도달 가능해야 하고 포커스 링이 보여야 합니다. 아이콘이 작다는 이유로 포커스 표시를 생략하면, 키보드 사용자는 지금 어느 아이콘에 가 있는지 알 수 없습니다. 디자인이 깔끔해 보인다고 outline: none으로 지우는 실수가 여기서도 똑같이 반복됩니다.

8) 움직이는 아이콘 — 로딩·진행의 의미 전달

스피너(빙글빙글 도는 로딩 아이콘)나 진행 표시 같은 "움직이는 아이콘"은 시각적으로 "기다리세요"를 전합니다. 그런데 화면을 못 보는 사용자에게는 이 회전이 전달되지 않습니다. 로딩 중이라는 사실, 그리고 끝났다는 사실이 코드로도(예: 상태 영역 텍스트 갱신, aria-live) 전달돼야 합니다. 아이콘의 "움직임"에만 의미를 싣지 말고, 그 의미가 텍스트로도 닿게 해야 합니다. 또 과도하게 빠르거나 번쩍이는 애니메이션은 일부 사용자에게 불편이나 발작 위험이 될 수 있으니 절제해야 합니다.

9) 다국어·문화권에서도 통하는가

공공 서비스는 외국인 사용자도 적지 않습니다. 텍스트는 번역되지만 아이콘은 그대로 남습니다. 그래서 문화권에 따라 다르게 읽힐 수 있는 아이콘(특정 손동작, 특정 기물 등)은 주의해야 합니다. 보편적으로 통용되는 기능 아이콘을 쓰고, 의미가 갈릴 수 있으면 역시 텍스트로 받쳐 주는 게 안전합니다.

정리하면 아이콘의 요건은 세 갈래입니다. ① 의미 전달(의미/장식 구분, 이름 부여), ② 지각 가능성(충분한 크기·대비·초점, 색 비의존, 움직임의 텍스트화), ③ 일관성(같은 의미=같은 아이콘, 표준 우선, 다국어 고려). 작은 그림 하나에도 이 세 가지가 다 걸려 있습니다.

왜 이렇게까지 — 아이콘은 보편 언어가 아니다

"아이콘은 그림이니까 누구나 알아보지 않나?"라는 생각은 절반만 맞습니다. 일부 아이콘(집=홈, 돋보기=검색)은 거의 보편적이지만, 상당수는 그렇지 않습니다.

같은 그림이 사람·문화·세대에 따라 다르게 읽힙니다. 플로피 디스크 모양이 "저장"을 뜻한다는 걸, 플로피 디스크를 본 적 없는 젊은 세대는 직관적으로 알기 어렵습니다. 종 모양이 "알림"인지 "소리"인지, 하트가 "좋아요"인지 "찜"인지는 맥락에 따라 다릅니다. 즉 아이콘은 "설명이 필요 없는 만국 공통어"가 아니라, "학습된 약속"에 가깝습니다.

그래서 아이콘의 의미가 조금이라도 모호할 수 있으면, 텍스트 라벨을 함께 두는 게 안전합니다. 특히 공공 서비스는 디지털에 익숙하지 않은 분, 고령층, 외국인 등 사용자 폭이 넓습니다. "아이콘만 봐도 알겠지"라는 가정은 가장 도움이 필요한 사용자를 가장 먼저 배제합니다. KRDS가 아이콘 전용 버튼에 이름을 강제하고, 아이콘과 텍스트 병기를 권장하는 배경이 여기 있습니다.

그리고 잊지 말아야 할 사실 하나. 스크린리더 사용자에게 아이콘은 "그림"이 아니라 "코드가 말해 주는 것"입니다. 아무리 직관적인 아이콘이라도, 코드가 그 의미를 담고 있지 않으면 그들에게는 존재하지 않는 것이나 같습니다. 보이는 그림과 코드가 담은 의미가 일치해야 한다는 원리는, 아이콘에서도 똑같이 적용됩니다.

작아서 방치되고, 흔해서 무뎌진다

아이콘이 유독 자주 잘못 쓰이는 데에는 구조적인 이유가 있습니다. 첫째, 작습니다. 화면에서 차지하는 면적이 작으니 검수 우선순위에서 밀립니다. 메인 비주얼은 모두가 들여다보지만, 우측 상단의 16px짜리 아이콘이 스크린리더에 어떻게 읽히는지는 아무도 확인하지 않습니다. 둘째, 너무 흔합니다. 한 화면에 수십 개씩 들어가다 보니 하나하나에 이름을 붙이는 일이 번거롭게 느껴지고, "다음에 정리하자"가 쌓입니다. 셋째, 만든 사람에게는 너무 명백합니다. 디자이너가 직접 고른 아이콘이라 그에게는 의미가 자명하지만, 처음 보는 사용자에게는 전혀 그렇지 않습니다. 이 세 가지가 겹쳐서, 아이콘은 "별생각 없이 얹고 끝나는" 요소가 되기 쉽습니다. KRDS가 아이콘을 굳이 스타일 가이드로 떼어내 표준화한 것은, 이렇게 방치되기 쉬운 곳에 최소한의 규칙을 박아 두기 위해서입니다.

한 장면 — 같은 버튼, 두 사람

추상적인 요건보다 한 장면이 빠를 것 같습니다. 어느 공공 서비스의 모바일 화면, 우측 상단에 돋보기 아이콘 하나가 있습니다. 텍스트는 없고 그림만 있습니다.

먼저 스마트폰을 눈으로 보며 쓰는 어느 주무관. 돋보기를 보고 "아, 검색이구나" 하고 누릅니다. 0.5초도 안 걸립니다. 그에게 이 아이콘은 완벽합니다. 그래서 이 화면을 만든 팀도 "직관적이다"라고 자평합니다.

이번엔 시각장애가 있는 한 선생님. 스크린리더로 화면을 훑어 내려가다 그 자리에서 "버튼"이라는 말만 듣습니다. 무슨 버튼인지 알 수 없습니다. 돋보기 그림은 코드상 이름이 없어서, 스크린리더가 "검색"이라고 말해 줄 수가 없거든요. 한 선생님은 그 버튼을 그냥 지나칩니다. 검색 기능이 분명히 있는데도, 그에게는 없는 것이나 마찬가지입니다.

같은 돋보기, 같은 버튼. 한 사람에겐 0.5초짜리 직관이고, 다른 한 사람에겐 보이지 않는 기능입니다. 이 차이를 메우는 비용은 놀랄 만큼 작습니다. 버튼에 aria-label="검색" 한 줄. 그거면 한 선생님의 스크린리더도 "검색, 버튼"이라고 읽어 줍니다. 아이콘 접근성은 거창한 기술이 아니라, 이 작은 한 줄을 빠뜨리지 않는 습관의 문제입니다.

아이콘, 공공성과 만나다

상업 서비스라면 아이콘이 좀 불친절해도 사용자가 다른 앱으로 갈아타면 그만입니다. 그런데 공공 서비스는 대체재가 없습니다. 세금을 내고, 증명서를 떼고, 복지를 신청하는 일은 그 사이트에서만 가능합니다. 그래서 공공웹의 아이콘은 "예쁘게 잘 뽑았는가"보다 "가장 도움이 필요한 사용자도 알아볼 수 있는가"가 먼저입니다.

생각해 보면, 디지털에 가장 서툰 분들이야말로 공공 서비스를 가장 절실히 필요로 합니다. 복지 신청, 의료 예약, 민원 처리는 고령층·장애인·저소득층에게 특히 중요한데, 이분들은 동시에 화려한 아이콘 앞에서 가장 쉽게 길을 잃습니다. 모르는 그림 하나가, 누군가에게는 "이 서비스는 나를 위한 게 아니구나" 하는 좌절이 됩니다. 아이콘을 보수적으로(보편적인 것으로, 텍스트와 함께) 쓰자는 원칙은 멋이 없어서가 아니라, 한 명이라도 더 포용하기 위한 선택입니다.

KRDS가 추구하는 일관성도 같은 맥락입니다. 어떤 정부 사이트에서 "이 모양은 신청이구나"를 한 번 배우면, 다른 정부 사이트에서도 그대로 통해야 합니다. 사이트마다 아이콘 언어가 다르면, 사용자는 갈 때마다 새 언어를 배워야 합니다. 표준 아이콘은 그 학습 비용을 0으로 만드는, 보이지 않는 사회적 인프라인 셈입니다.

좋은 아이콘의 기본기 — 선·면·크기의 일관성

접근성과는 별개로, 아이콘이 "잘 만들어졌다"는 느낌은 디테일에서 옵니다. KRDS 아이콘 세트가 통일감을 주는 이유를 뜯어보면 몇 가지 규칙이 보입니다.

• 선 두께(stroke)의 통일: 한 세트 안의 아이콘은 같은 굵기의 선으로 그려집니다. 어떤 건 가늘고 어떤 건 두꺼우면, 나란히 놓였을 때 들쭉날쭉해 보입니다.
• 외곽 박스(그리드)의 통일: 아이콘마다 차지하는 가상의 정사각형 영역이 같아야, 크기를 맞춰 배치했을 때 시각적 무게가 비슷해집니다. 어떤 아이콘은 꽉 차고 어떤 건 작게 떠 있으면 정렬이 흐트러집니다.
• 모서리·끝 처리의 통일: 선의 끝을 둥글게 할지 각지게 할지, 모서리 반경을 얼마로 할지가 일관돼야 한 가족처럼 보입니다.
• 시각적 정렬(optical alignment): 수학적으로 가운데 둔다고 가운데로 보이지 않습니다. 삼각형 재생 아이콘은 약간 오른쪽으로 밀어야 "가운데"로 느껴집니다. 좋은 아이콘 세트는 이런 미세 보정이 되어 있습니다.

이 디테일을 매번 직접 맞추는 건 전문 영역입니다. 그래서 KRDS가 정리해 둔 표준 세트를 쓰는 게 품질과 효율 양쪽에서 이득입니다. 새로 그릴 때도 이 규칙(선 두께·그리드·끝 처리)을 기존 세트에 맞추면, 추가 아이콘이 어색하게 튀지 않습니다.

공공 사이트가 자주 틀리는 지점

이제 현장에서 반복되는 아이콘 실수들을 보겠습니다. 모두 익명화한 일반적 사례입니다.

실수 1) 이름 없는 아이콘 버튼

햄버거 메뉴, 돋보기 검색, X 닫기 — 라벨 없이 아이콘만 덩그러니.

• 나쁜 예: <button><svg>...</svg></button> 끝. 스크린리더는 "버튼"으로만 읽음. 무슨 버튼인지 알 수 없음.
• 올바른 예: <button aria-label="메뉴 열기"><svg aria-hidden="true">...</svg></button>. 버튼엔 이름을, 안의 장식 svg는 숨김 처리.

실수 2) 장식 아이콘이 스크린리더에 읽힘

"검색" 글자 옆 돋보기가 aria-hidden 없이 그대로 노출.

• 나쁜 예: "이미지 검색"처럼 중복 낭독. 텍스트와 아이콘이 같은 의미인데 두 번 읽힘.
• 올바른 예: 텍스트 라벨이 있으면 아이콘은 aria-hidden="true"로 숨겨 한 번만 읽히게.

실수 3) 의미를 색으로만 전달

상태 아이콘을 빨강/초록으로만 구분.

• 나쁜 예: 빨간 점과 초록 점만으로 "오류/정상" 구분. 색각 이상 사용자는 둘을 구별 못 함.
• 올바른 예: 색 + 모양(경고 삼각형 / 체크) + 텍스트를 함께. 어느 하나에만 의존하지 않음.

실수 4) 너무 작거나 흐린 아이콘

장식성에 치중해 아이콘을 작고 연하게.

• 나쁜 예: 12px 연회색 아이콘. 저시력·고령 사용자에겐 거의 안 보이고, 터치 영역도 부족.
• 올바른 예: 충분한 크기와 대비, 터치 영역(약 44px 이상) 확보.

실수 5) 의미 불명의 커스텀 아이콘 남발

표준에 없는 독창적 아이콘을 라벨 없이 사용.

• 나쁜 예: 디자이너만 아는 추상 픽토그램. 사용자는 "이게 뭐지?" 추측 게임.
• 올바른 예: KRDS 표준을 우선 사용하고, 부득이 새 아이콘이면 반드시 텍스트 라벨 병기.

실수 6) 같은 의미, 다른 아이콘

같은 "닫기"를 페이지마다 다른 모양으로.

• 나쁜 예: 한 곳은 X, 한 곳은 ←, 한 곳은 "닫기" 텍스트. 일관성 붕괴.
• 올바른 예: 동작별 아이콘을 통일하고, 디자인 시스템 차원에서 한 번 정해 전사에 적용.

실수 7) 포커스 표시 없는 아이콘 버튼

아이콘 버튼이 작다는 이유로 포커스 링을 생략.

• 나쁜 예: 키보드로 툴바를 훑어도 지금 어느 아이콘에 있는지 안 보임. 결국 마우스 없이는 쓰기 어려움.
• 올바른 예: 아이콘 버튼에도 또렷한 포커스 표시. 텍스트 버튼과 동일한 기준 적용.

실수 8) 클릭 영역이 아이콘 그림에만 한정

16px 그림 픽셀에만 클릭이 걸려 있어, 살짝만 빗나가도 안 눌림.

• 나쁜 예: 작은 아이콘 외곽을 정확히 눌러야만 작동. 손 떨림이 있거나 모바일에서 특히 고역.
• 올바른 예: 아이콘을 감싸는 버튼 영역 자체를 충분히(약 44px) 넓혀 여유 있게 누르게.

실수 9) 외부에서 긁어온 제각각 아이콘

여러 무료 아이콘 사이트에서 그때그때 가져와 선 두께·스타일이 뒤죽박죽.

• 나쁜 예: 어떤 건 두꺼운 선, 어떤 건 채워진 면, 어떤 건 둥글고 어떤 건 각진. 화면이 어수선.
• 올바른 예: KRDS 표준 세트처럼 한 세트의 통일된 스타일을 쓰고, 라이선스도 명확히.

아이콘과 텍스트의 관계 — 언제 병기하고, 언제 숨기나

아이콘을 둘러싼 혼란의 대부분은 "텍스트와 어떻게 짝지을 것인가"에서 옵니다. 경우를 나눠 정리하면 명확해집니다.

• 아이콘 + 텍스트 (가장 안전): "검색" 글자 옆 돋보기. 누구에게나 의미가 분명합니다. 이때 아이콘은 장식이므로 aria-hidden="true"로 숨겨 중복 낭독을 막습니다. 공공 서비스의 주요 동작 버튼은 가급적 이 형태를 권합니다. 공간이 조금 더 들더라도, 가장 많은 사용자를 포용합니다.
• 아이콘만 (공간 절약, 단 이름 필수): 툴바처럼 공간이 빠듯해 아이콘만 둘 때. 반드시 aria-label로 이름을 부여해야 합니다. 그리고 이 경우에도 보편적으로 통용되는 아이콘(검색·닫기·메뉴)에 한정하는 게 안전합니다. 의미가 모호한 아이콘을 라벨만 믿고 텍스트 없이 두면, 마우스 사용자에게는 여전히 추측 게임입니다.
• 텍스트만 (아이콘 없음): 아이콘으로 표현하기 애매한 동작은 무리하게 그림을 만들지 말고 텍스트로 두는 게 낫습니다. 억지 아이콘은 없느니만 못합니다.

핵심 판단 기준은 하나입니다. "이 아이콘을 처음 보는 사람이, 옆에 글자 없이도 100% 같은 의미로 이해할까?" 자신이 없으면 텍스트를 병기하세요. 디자이너에게는 자명한 아이콘이 사용자에게는 수수께끼인 경우가, 생각보다 훨씬 많습니다.

한 화면에 아이콘이 너무 많을 때

아이콘을 많이 쓴다고 화면이 깔끔해지는 건 아닙니다. 오히려 의미를 모르는 그림이 늘어나면 인지 부담이 커집니다. 정말 자주 쓰는 핵심 동작에만 아이콘을 쓰고, 나머지는 텍스트로 두는 절제가 필요합니다. 아이콘은 "많이 쓰면 좋은 것"이 아니라 "정확히 필요한 곳에 쓰는 것"입니다.

헷갈리기 쉬운 아이콘들 — 의미가 갈리는 경우

같은 그림이 다른 뜻으로 쓰이는 대표 사례를 정리해 둡니다. 이런 아이콘일수록 텍스트 병기나 명확한 라벨이 중요합니다.

• 종(bell): "알림"으로 흔히 쓰이지만, 맥락에 따라 "소리/음량"으로 오해될 수 있습니다. 알림이면 "알림" 라벨을 분명히.
• 하트(heart): "좋아요"인지 "찜/즐겨찾기"인지 서비스마다 다릅니다. 별(star)과도 혼용되니, 무엇을 하는지 라벨로 못박는 게 좋습니다.
• 세 점(⋯ / ⋮): "더보기/추가 메뉴"를 뜻하지만 초보 사용자에겐 모호합니다. 라벨 "더보기" 권장.
• 공유(share): 운영체제마다 모양이 달라(네모+화살표 vs 점 세 개 연결) 헷갈립니다.
• 새로고침/되돌리기: 둥근 화살표가 "새로고침"인지 "실행 취소"인지 방향과 맥락으로 갈립니다.
• 플로피 디스크: "저장"의 관습적 상징이지만, 실물을 본 적 없는 세대에겐 의미가 전달되지 않습니다.
• 햄버거(≡) vs 케밥(⋮) vs 미트볼(⋯): 모두 "메뉴/더보기" 계열이라 자주 혼동됩니다.

이 목록의 교훈은 단순합니다. "유명한 아이콘"과 "누구에게나 명확한 아이콘"은 다릅니다. 조금이라도 갈릴 여지가 있으면 텍스트를 함께 두세요. 특히 공공 서비스에서는, 디자인 트렌드보다 "처음 온 사람도 헤매지 않는가"가 우선입니다.

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

개발자라면 — KRDS 컴포넌트 킷(npm install krds-uiux 또는 CDN krds.min.css / krds.min.js)에 표준 아이콘 SVG가 포함돼 있습니다. 직접 아이콘을 그리거나 외부에서 긁어오지 말고, 이 표준 세트를 가져다 쓰면 일관성과 라이선스 문제를 한 번에 해결할 수 있습니다. 핵심 습관은 단 두 가지입니다. 아이콘이 버튼·링크로 동작하면 그 요소에 이름을 주고(aria-label="검색"), 안의 그림 SVG는 aria-hidden="true"로 숨깁니다. 아이콘이 순수 장식(옆에 텍스트가 이미 있음)이면 역시 aria-hidden="true"로 숨깁니다. 즉 "장식 SVG는 무조건 숨기고, 기능 요소에는 이름을 준다" — 이 한 문장만 지켜도 아이콘 접근성의 대부분이 해결됩니다.

추가로 챙기면 좋은 것들: 아이콘 버튼의 클릭 영역을 그림보다 넓게(패딩으로 약 44px 확보), 포커스 표시 유지(outline을 지웠다면 대체 스타일 제공), 상태 아이콘에는 색 외에 텍스트/모양 동반, 로딩 아이콘에는 aria-live 영역으로 진행/완료 안내. 이 항목들은 한 번 공통 컴포넌트로 만들어 두면 이후엔 자동으로 따라옵니다. 그래서 처음에 KRDS 킷 기반으로 공통 아이콘 버튼 컴포넌트를 잡아 두는 게 장기적으로 가장 효율적입니다.

디자이너라면 — KRDS 공식 Figma(@krds) 라이브러리에서 표준 아이콘을 컴포넌트로 가져다 배치할 수 있습니다. 새 아이콘을 만들기 전에 "이미 표준 세트 안에 있는가"를 먼저 확인하세요. 표준에 있는 걸 새로 그리는 건 일관성을 깨뜨리는 일입니다. 부득이 새 아이콘이 필요하면, 기존 세트의 선 두께·그리드·끝 처리 규칙에 맞춰 같은 톤으로 제작하세요.

기획자라면 — 화면 정의서에 "아이콘 버튼"이라고만 쓰지 말고, 그 아이콘이 의미하는 동작 이름(예: "메뉴 열기")을 함께 적어 두세요. 그 한 줄이 개발 단계에서 라벨 누락을 막습니다. 또 "이 아이콘은 단독으로 둘지, 텍스트와 병기할지"를 기획 단계에서 정해 두면, 디자인·개발에서 우왕좌왕할 일이 줄어듭니다.

아이콘 라벨 문구, 이렇게 쓰세요

라벨을 붙이기로 했다면, 그 문구도 신경 써야 합니다. 좋은 라벨은 짧고, 동작 중심이며, 사용자가 듣고 바로 이해할 수 있어야 합니다.

• 동작 + 대상으로: 단순히 "검색"보다 맥락이 필요하면 "게시물 검색"처럼. 단, 너무 길면 오히려 거추장스러우니 균형이 중요합니다.
• 무엇이 일어날지 알려주기: 메뉴 버튼이면 "메뉴 열기", 닫기 버튼이면 "닫기"처럼 결과를 짐작할 수 있게.
• 상태가 바뀌는 토글은 상태도: 펼침/접힘이 바뀌는 버튼은 aria-expanded로 현재 상태를 함께 전달. "메뉴, 접힘 → 메뉴, 펼침"처럼 변화가 읽히게.
• 중복·군더더기 빼기: "검색 버튼 아이콘"처럼 "버튼/아이콘"이라는 말을 라벨에 넣지 마세요. 스크린리더가 이미 "버튼"이라고 역할을 읽어 주므로 "검색 버튼 버튼"처럼 중복됩니다. 라벨은 "검색"이면 충분합니다.
• 같은 동작엔 같은 문구: 사이트 전체에서 "닫기"를 어떤 곳은 "닫기", 어떤 곳은 "창 닫기", 어떤 곳은 "취소"로 쓰면 일관성이 깨집니다. 동작별 표준 문구를 한 번 정해 두세요.

이 라벨 문구는 사실 UX 라이팅의 영역과 맞닿아 있습니다. 화면에 보이는 글자뿐 아니라, "보이지 않지만 읽히는 글자"도 똑같이 공들여 다듬어야 한다는 뜻입니다. 음성으로만 서비스를 쓰는 사용자에게는, 이 라벨이 곧 화면 전체이기 때문입니다.

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

아이콘 요건은 "알면 쉽지만, 페이지마다 일일이 확인하긴 어려운" 종류입니다. 아이콘 버튼이 몇 개인지, 각각 이름이 붙어 있는지, 장식 아이콘이 잘못 노출되는지를 손으로 다 보려면 끝이 없죠.

ViewCheck(krds.viewcheck.co.kr)는 URL만 넣으면 페이지를 크롤링해, 아이콘과 관련된 KRDS 기준을 자동으로 점검합니다. 아이콘은 KRDS 846규칙 중 디자인 스타일(DS) 규칙군 120개와 컴포넌트 접근성 항목에 걸쳐 있고, 분석 결과의 디자인 시스템(Design System) 탭과 접근성 항목에서 확인할 수 있습니다. DS 탭에는 디자인 토큰 채택률 리포트가 함께 나와, 아이콘을 포함한 시각 요소가 표준 토큰을 얼마나 따르고 있는지 한눈에 보여 줍니다.

ViewCheck가 아이콘과 관련해 자동으로 보는 것들:

• 아이콘 전용 버튼의 이름 유무: 라벨 없이 아이콘만 있는 버튼을 찾아냄
• 장식/의미 아이콘 처리: 텍스트와 중복되는 아이콘이 적절히 숨김 처리됐는지
• 크기·대비: 아이콘 버튼의 터치 영역과 색 대비가 기준을 충족하는지(반응형·대비 분석과 연계)

화면으로만 보이는 시각적 부분은 KRDScan Vision AI가 스크린샷을 함께 보고 보강 판정하기 때문에, 이미지로 박아 넣은 아이콘처럼 코드만으로는 놓치기 쉬운 경우도 잡아냅니다. 단순 코드 검사 도구와 다른 점이 여기입니다 — 사람이 눈으로 보듯 화면을 함께 보기 때문에, 표준을 우회해 만든 UI도 놓치지 않습니다.

리포트를 어떻게 읽나

분석이 끝나면 "이름 없는 아이콘 버튼이 몇 개, 어느 페이지에 있는지"가 목록으로 나옵니다. 예를 들어 "검색 페이지 헤더의 아이콘 버튼 2개가 라벨 미연결"처럼 구체적으로요. 여러 페이지를 한꺼번에 분석하면, "메인은 멀쩡한데 신청 페이지의 아이콘 버튼들만 라벨이 빠졌다" 같은 페이지별 편차도 한눈에 드러납니다. 그리고 어디부터 고쳐야 하는지 우선순위(P0~P3)가 함께 매겨지니, 한정된 시간에 가장 중요한 것부터 손볼 수 있습니다. 막연한 "아이콘 잘 쓰자"가 아니라 "이 페이지의 이 아이콘 버튼에 이 라벨을 붙이자"는 구체적인 작업 목록이 나오는 셈입니다.

무료 진단으로 메인 페이지부터 한 번 돌려 보면, 우리 사이트의 아이콘이 추측 게임을 만들고 있는지 5분 만에 확인됩니다. 그리고 그 결과는 다음 개선 작업의 출발점이 됩니다.

자주 묻는 질문

Q. 아이콘 옆에 텍스트가 있으면 접근성은 신경 안 써도 되나요?

텍스트 라벨이 함께 있으면 그 아이콘은 장식으로 봐도 됩니다. 다만 이때는 아이콘을 aria-hidden="true"로 숨겨 스크린리더가 중복해서 읽지 않게 해 주세요. "있으니 괜찮다"가 아니라 "숨겨서 깔끔하게"가 정답입니다.

Q. 이모지를 아이콘 대신 써도 되나요?

권장하지 않습니다. 이모지는 기기·폰트마다 모양이 다르게 보이고, 스크린리더가 의도와 다른 이름으로 읽는 경우가 많습니다(예: 특정 이모지를 장황하게 낭독). 기능 아이콘은 KRDS 표준 SVG를 쓰는 게 안전합니다.

Q. 우리 브랜드만의 아이콘을 쓰고 싶은데요?

브랜드 일러스트나 특수 아이콘이 필요할 수 있습니다. 다만 검색·메뉴·닫기 같은 보편 기능까지 독창적으로 만들면 사용자가 혼란스럽습니다. 보편 기능은 표준을, 브랜드 표현이 필요한 곳은 신중하게 — 그리고 어느 쪽이든 의미 있는 아이콘에는 이름을 붙이세요.

Q. SVG와 아이콘 폰트 중 뭐가 낫나요?

KRDS는 SVG로 제공합니다. SVG는 크기를 키워도 선명하고, 접근성 속성을 붙이기 좋습니다. 아이콘 폰트는 폰트 로딩 실패 시 깨진 글자가 보이거나 스크린리더가 엉뚱하게 읽는 문제가 있어, 일반적으로 SVG가 더 권장됩니다.

Q. 햄버거 메뉴(줄 세 개)는 워낙 유명한데도 라벨이 필요한가요?

네. 시각적으로는 익숙해도, 스크린리더 사용자에게는 그 줄 세 개가 "메뉴"라는 정보가 코드로 전달돼야 합니다. aria-label="메뉴 열기" 같은 이름은 유명세와 무관하게 필요합니다. 또 메뉴가 열렸는지 닫혔는지 상태(aria-expanded)까지 알려 주면 더 좋습니다.

Q. 아이콘 색을 브랜드 색으로 통일하고 싶은데, 대비가 좀 약해도 될까요?

브랜드 일관성은 중요하지만, 대비가 부족하면 저시력·고령 사용자가 아이콘을 못 봅니다. 특히 기능 아이콘(누를 수 있는 것)은 배경과의 명도 대비를 충분히 확보해야 합니다. 브랜드 색을 쓰더라도 명도를 조정해 대비 기준을 맞추는 게 맞습니다.

Q. 표준 세트에 우리가 필요한 아이콘이 없으면요?

표준에 없는 기능 아이콘이 필요할 수 있습니다. 그럴 때는 KRDS 아이콘의 시각적 스타일(선 두께·모서리·크기 규칙)에 맞춰 같은 톤으로 제작하고, 의미가 모호하면 텍스트를 병기하세요. 톤이 제각각인 아이콘이 섞이면 화면이 어수선해 보입니다.

Q. 아이콘에 툴팁(마우스 올리면 뜨는 설명)을 달면 라벨은 생략해도 되나요?

안 됩니다. 툴팁은 마우스를 올려야 보이므로, 키보드·터치·스크린리더 사용자에게는 닿지 않는 경우가 많습니다. 툴팁은 보조 설명일 뿐, 접근 가능한 이름(aria-label 등)을 대신하지 못합니다. 라벨은 라벨대로 두고, 툴팁은 추가 도움으로 쓰세요.

Q. 접근성까지 챙기면 개발이 너무 오래 걸리지 않나요?

처음 한 번 공통 아이콘 버튼 컴포넌트를 제대로 만들어 두면, 그 뒤로는 거의 비용이 들지 않습니다. 라벨을 받는 자리 하나만 열어 두면, 쓸 때마다 이름만 넘기면 끝이거든요. "매번 따로 챙기느라 느리다"는 건 컴포넌트화가 안 됐다는 신호입니다. KRDS 킷을 기반으로 한 번 잡아 두는 초기 투자가, 장기적으로는 가장 빠른 길입니다.

Q. 이미 아이콘이 수백 개 박힌 운영 사이트인데, 다 고쳐야 하나요?

전부 한 번에 갈아엎을 필요는 없습니다. 먼저 ViewCheck로 "이름 없는 아이콘 버튼이 어디에 몇 개인지" 목록을 뽑고, 사용 빈도가 높은 핵심 경로(메인·검색·신청·로그인)의 아이콘부터 차례로 라벨을 채우세요. 적은 작업으로 가장 많은 사용자를 먼저 구제하는 순서입니다.

5분 셀프 점검 — 지금 바로 해보기

거창한 도구 없이도, 지금 우리 사이트에서 아이콘을 직접 점검해 볼 수 있습니다. 순서대로 해보세요.

1. 마우스를 치우고 Tab만으로 화면을 훑어 보세요. 우측 상단 아이콘들(검색·메뉴·설정 등)에 초점이 가나요? 가서 또렷이 보이나요? 안 가거나 안 보이면 1번 문제입니다.

2. 브라우저에서 이미지를 끄거나 개발자도구로 아이콘을 잠시 숨겨 보세요. 그래도 무슨 버튼인지 알 수 있나요? 텍스트 라벨이 없다면, 시각장애인에게 그 버튼은 사라진 셈입니다.

3. 화면을 흑백으로 보세요(운영체제의 색 필터 기능). 상태를 색으로만 표시한 아이콘이 구분되나요? 안 되면 색 의존 문제입니다.

4. 모바일에서 아이콘 버튼을 빠르게 눌러 보세요. 옆 버튼이 눌리거나 자꾸 빗나가면 터치 영역이 부족한 겁니다.

5. 같은 동작(예: 닫기)을 여러 페이지에서 비교해 보세요. 모양이 다르면 일관성 문제입니다.

이 다섯 가지만 해봐도 대부분의 아이콘 문제가 드러납니다. 다만 페이지가 많아지면 사람이 다 보기 어렵습니다 — 그때 ViewCheck로 전 페이지를 한 번에 점검하면 됩니다.

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

• 가장 먼저(치명적): 이름 없는 아이콘 전용 버튼. 특히 메뉴·검색·닫기처럼 핵심 동작 버튼. 스크린리더 사용자에게 기능을 완전히 차단하므로 1순위.
• 그다음(높음): 색으로만 의미를 전달하는 상태 아이콘. 색각 이상·저시력 사용자가 정보를 놓침.
• 그 후(보통): 장식 아이콘 중복 낭독, 작은 터치 영역, 낮은 대비.
• 여력이 되면(낮음): 같은 의미인데 제각각인 아이콘 통일, 비표준 아이콘을 KRDS 표준으로 교체.

ViewCheck 리포트는 이 우선순위(P0~P3)를 자동으로 매겨 주므로, "사용자를 가장 많이 막는 것부터" 순서대로 처리하면 됩니다. 한정된 인력과 시간 안에서, 가장 효과가 큰 수정부터 손대는 게 현명한 운영입니다.

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

• KRDS 가이드라인 PDF(디지털 정부서비스 UI/UX 가이드라인, 2025.08판) — 아이콘 사용 원칙의 1차 원천.
• KRDS 스타일 가이드(웹) — 아이콘 항목 — 아이콘 규격과 예시.
• KRDS 컴포넌트 킷(GitHub `KRDS-uiux/krds-uiux`) — 표준 아이콘 SVG를 그대로 사용(npm install krds-uiux 또는 CDN).
• KRDS 공식 Figma(@krds) — 디자이너용 아이콘 컴포넌트.

공식 자료는 "정답지", ViewCheck는 "내 답안 채점"입니다. 기준을 익히고(가이드라인) → 내 사이트를 확인하고(ViewCheck) → 표준 자산으로 고치는(킷·Figma) 한 바퀴를 돌리면 됩니다.

오늘의 체크리스트 — 아이콘, 이것만은

• ☐ 아이콘 전용 버튼(메뉴·검색·닫기 등)에 이름(aria-label 등)이 있다.
• ☐ 텍스트와 함께 있는 장식 아이콘은 aria-hidden="true"로 숨겼다.
• ☐ 상태를 색으로만 전달하지 않는다(모양·텍스트 병행).
• ☐ 아이콘 버튼의 터치 영역이 충분하다(약 44px 이상).
• ☐ 아이콘과 배경의 명도 대비가 충분하다.
• ☐ 누를 수 있는 아이콘에 포커스 표시가 또렷하다.
• ☐ 같은 의미에는 같은 아이콘을 쓴다(전사 통일).
• ☐ 보편 기능은 KRDS 표준 SVG 세트를 우선 사용한다.
• ☐ 의미가 모호할 수 있으면 텍스트 라벨을 병기한다.
• ☐ 움직이는 아이콘(로딩 등)의 의미가 텍스트로도 전달된다.

아이콘은 "작아서 사소한" 게 아니라, "작아서 방치되기 쉬운" 요소입니다. 그런데 사용자는 바로 그 작은 그림을 보고 어디를 누를지 결정합니다. 잘 정리된 아이콘 하나는 긴 설명을 대신하고, 잘못된 아이콘 하나는 누군가의 길을 막습니다.

오늘 이야기를 한 문장으로 줄이면 이렇습니다. "아이콘은 보여 주기 위한 게 아니라, 알아보게 하기 위한 것이다." 그래서 의미 있는 아이콘에는 이름을 주고, 장식 아이콘은 숨기고, 색만으로 말하지 않고, 같은 의미는 같은 모양으로, 그리고 헷갈릴 것 같으면 텍스트를 함께 둡니다. 어느 것도 어려운 기술이 아닙니다. 다만 "작아서 그냥 넘기던" 습관을 한 번 멈춰 세우면 됩니다. KRDS가 아이콘을 표준으로 정리해 둔 것도 바로 그 멈춤을 도와주기 위해서입니다. 표준 세트를 가져다 쓰고, 두 가지 습관(장식은 숨기고, 기능엔 이름 주기)만 지키면, 우리 사이트의 아이콘은 더 많은 사람에게 분명해집니다.

우리 사이트의 아이콘은 추측 게임을 만들고 있지 않을까요? krds.viewcheck.co.kr에서 URL만 넣으면, 이름 없는 아이콘 버튼이 어디에 있는지, KRDS 기준에 맞는지 무료로 확인할 수 있습니다.

#KRDS #공공웹 #디자인시스템 #아이콘Icon #웹접근성 #ViewCheck #정부웹사이트 #UIUX #픽토그램 #aria라벨 #디자인토큰 #아이콘 #Icon #KRDS기준 #디자인원칙 #표준가이드 #디자인스타일 #전자정부 #디지털정부 #행정안전부