아이콘(Icon) — 공공웹이 자주 틀리는 지점

공공 사이트를 분석하는 일을 하다 보면, 어느 순간 직업병이 생깁니다. 처음 보는 정부 사이트에 들어가도 본문보다 먼저 우측 상단의 작은 그림들부터 눈이 갑니다. 돋보기, 사람 얼굴, 톱니바퀴, 줄 세 개. 그리고 거의 무의식적으로 손가락이 키보드 Tab 키로 향하죠. "이 아이콘들, 키보드로 닿기는 하나? 스크린리더는 뭐라고 읽을까?" 그렇게 수백 개 사이트를 훑다 보면, 충격적인 사실 하나를 받아들이게 됩니다. 공공웹에서 가장 많이 틀리는 게 다름 아닌 이 작은 아이콘들이라는 것.

이상한 일입니다. 메인 비주얼은 디자인 회의를 몇 번씩 거쳐 정성껏 만들고, 글꼴 하나 바꾸는 데도 논쟁이 오가는데, 정작 사용자가 매일 손으로 누르는 아이콘 버튼은 라벨 한 줄이 빠진 채로 몇 년씩 방치됩니다. 화면에서 차지하는 면적이 작다는 이유로요. 그런데 사용자 입장에서 보면 이 작은 그림 하나가 "검색을 할 수 있느냐 없느냐", "메뉴를 열 수 있느냐 없느냐"를 가르는 결정적 스위치입니다. 작은 건 면적이지, 중요도가 아닙니다.

이 글은 "KRDS 완전해부" 시리즈 중 아이콘 편의 두 번째입니다. 앞선 글에서 KRDS 아이콘 시스템이 무엇을 요구하는지 기준을 해부했다면, 이번에는 시선을 정반대로 돌립니다. 현장에서 공공 사이트가 실제로 어디서, 어떻게, 왜 그렇게 자주 틀리는지 — 익명화한 실제 사례를 중심으로 낱낱이 들여다보겠습니다. 특정 기관을 지목하지는 않습니다. 왜냐하면 이 실수들은 어느 한 기관의 문제가 아니라, 공공웹 전반에 퍼진 공통 패턴이기 때문입니다. 거의 모든 사이트가 같은 함정에 같은 방식으로 빠집니다.

미리 말해 두자면, 이 글의 목적은 누구를 비난하는 게 아닙니다. 오히려 그 반대입니다. "아, 우리도 저거 하고 있었네" 하고 알아차리는 것, 그게 고침의 시작이니까요. 아이콘 위반은 대부분 악의가 아니라 무지에서, 정확히는 "그게 문제인 줄 몰라서" 생깁니다. 그래서 이 글을 다 읽고 나면, 앞으로 어떤 사이트에서든 아이콘을 볼 때 "아, 저건 위험한 패턴이다"가 자동으로 보이실 겁니다. 그 눈이 생기는 게 이 글의 목표입니다.

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

본격적으로 사례를 보기 전에, 용어를 맞춰 두겠습니다. "아이콘 위반"이라고 하면 보통 "아이콘을 못생기게 그렸다"는 뜻으로 오해하기 쉽습니다. 하지만 우리가 말하는 위반은 미적 문제가 거의 아닙니다. KRDS(대한민국 정부 디자인 시스템)와 한국형 웹 접근성 지침(KWCAG)이 요구하는 기준을 충족하지 못한 상태 — 그게 위반입니다.

아이콘 위반은 크게 세 갈래로 나뉩니다. 이 세 가지 축을 머리에 넣어 두면, 앞으로 나올 모든 사례가 어디에 속하는지 한눈에 정리됩니다.

전달 위반: 아이콘이 담은 의미가 일부 사용자에게 닿지 못하는 경우. 이름 없는 아이콘 버튼, 색으로만 표현한 상태, 의미 불명의 커스텀 픽토그램 등. 가장 흔하고 가장 치명적입니다.
지각 위반: 아이콘이 있긴 한데 보거나 누르기 어려운 경우. 너무 작은 아이콘, 흐린 대비, 좁은 터치 영역, 사라진 포커스 표시 등.
일관성 위반: 아이콘이 사이트 안에서, 또는 다른 정부 사이트와 따로 노는 경우. 같은 의미인데 페이지마다 다른 모양, 제각각인 선 두께와 스타일, 표준이 있는데도 새로 그린 아이콘 등.

KRDS 공식 스타일 가이드(아이콘 항목, krds.go.kr)는 시스템 아이콘을 SVG 형식의 표준 세트로 제공합니다. 저장소(GitHub KRDS-uiux/krds-uiux)의 아이콘 폴더에는 공공 서비스에서 반복적으로 쓰이는 기능들 — 검색·홈·메뉴·닫기·화살표·체크·경고 등 — 을 위한 표준 아이콘이 들어 있습니다. 핵심은 이겁니다. KRDS가 이렇게 표준 세트를 만들어 두고, 가이드라인으로 사용 원칙까지 명시해 둔 이유는, 바로 위에서 말한 세 가지 위반이 공공웹에 만연하기 때문입니다. 규칙이 만들어졌다는 건, 그만큼 자주 깨졌다는 뜻이기도 합니다.

자, 그럼 이제 진짜 현장으로 들어가 보겠습니다. 지금부터 보는 사례들은 제가 수백 개 공공 사이트를 분석하며 거의 모든 곳에서 반복적으로 마주친 위반들입니다. 어느 하나도 희귀하지 않습니다. 오히려 너무 흔해서, 안 틀린 사이트를 찾는 게 더 어려울 정도입니다.

가장 흔한 위반 — 이름 없는 아이콘 버튼

공공웹 아이콘 위반의 단연 1위. 100개 사이트를 분석하면 90개 이상에서 발견되는, 압도적인 단골입니다. 바로 텍스트 라벨이 전혀 없는 아이콘 전용 버튼입니다.

화면 우측 상단을 떠올려 보세요. 햄버거(줄 세 개) 하나만 있는 메뉴 버튼, 돋보기 하나만 있는 검색 버튼, 톱니바퀴 하나만 있는 설정 버튼, X 하나만 있는 닫기 버튼. 마우스를 쓰는 사람에게는 아무 문제가 없습니다. 모양을 보고 "아, 검색이구나" 하고 누르면 되니까요. 그런데 화면을 못 보는 사용자에게는 이게 전혀 다른 이야기가 됩니다.

코드 안에서 무슨 일이 벌어지나

문제의 핵심은 코드입니다. 흔히 이런 식으로 작성됩니다.

```html

</button>

```

이 버튼을 스크린리더가 만나면 뭐라고 읽을까요? "버튼." 그게 끝입니다. 무슨 버튼인지에 대한 정보가 코드 어디에도 없으니까요. 돋보기 그림은 시각적 정보일 뿐, 스크린리더에게는 의미 없는 벡터 경로 덩어리에 불과합니다. 시각장애인 사용자는 "버튼"이라는 말만 듣고, 이게 검색인지 신청인지 로그아웃인지 알 길이 없습니다. 그래서 대부분 그냥 지나칩니다. 검색 기능이 분명히 거기 있는데도, 그에게는 없는 것이나 마찬가지가 됩니다.

올바른 코드는 놀랄 만큼 간단합니다.

```html

</button>

```

aria-label="검색" 한 줄이면 스크린리더가 "검색, 버튼"이라고 읽어 줍니다. 그리고 안의 svg는 aria-hidden="true"로 숨겨서 중복 낭독을 막습니다. 위반을 고치는 데 드는 비용은 정확히 코드 한 줄. 그런데 이 한 줄이 없어서, 수많은 공공 사이트의 검색·메뉴·설정 버튼이 시각장애인에게 닫힌 문이 되어 있습니다.

왜 이 위반이 이토록 흔할까

이유는 구조적입니다. 첫째, 만든 사람에게는 너무 명백합니다. 디자이너가 직접 돋보기를 고른 거라 그에게는 "검색"이 자명하지만, 코드는 그 의도를 모릅니다. 둘째, 테스트가 늘 마우스로 이뤄집니다. 개발자도 기획자도 검수 담당자도 마우스로 클릭해 보고 "잘 되네" 하고 넘어갑니다. 스크린리더를 켜고 Tab으로 훑어 보는 사람이 없으면, 이 위반은 영원히 발견되지 않습니다. 셋째, 너무 흔합니다. 한 화면에 아이콘 버튼이 수십 개씩 들어가다 보니, 하나하나 라벨을 챙기는 게 번거롭게 느껴지고 "다음에 정리하자"가 쌓입니다.

그리고 한 가지 더. 햄버거 메뉴는 워낙 유명해서 "이건 다들 아니까 라벨 없어도 되지 않나?" 하는 착각이 있습니다. 아닙니다. 시각적으로 익숙한 것과 코드로 전달되는 것은 완전히 별개입니다. 줄 세 개가 "메뉴"라는 정보는 반드시 코드(aria-label="메뉴 열기")로 담겨야 스크린리더에 닿습니다. 유명세는 접근성을 면제해 주지 않습니다.

두 번째 위반 — 장식 아이콘이 시끄럽게 읽힌다

첫 번째 위반과 정확히 거울처럼 짝을 이루는 위반입니다. 이름 없는 버튼이 "읽혀야 하는데 안 읽히는" 문제라면, 이건 "안 읽혀도 되는데 시끄럽게 읽히는" 문제입니다.

상황은 이렇습니다. "검색"이라는 글자 옆에 돋보기 아이콘이 붙어 있습니다. 이 경우 돋보기는 그저 시각적 보조, 즉 장식입니다. 텍스트가 이미 "검색"이라고 말해 주고 있으니까요. 그런데 이 돋보기에 aria-hidden 처리를 하지 않으면, 스크린리더가 아이콘까지 읽으려 들면서 "이미지 검색" 혹은 "그래픽 검색"처럼 중복해서 낭독합니다. 같은 의미를 두 번 듣게 되는 거죠.

한두 번이면 거슬리는 수준이지만, 한 화면에 이런 장식 아이콘이 수십 개라면 음성 사용자에게는 고문에 가깝습니다. 의미 없는 "이미지", "그래픽" 소리가 끊임없이 끼어들어 정작 중요한 정보를 가립니다. 스크린리더 사용자가 공공 사이트를 답답해하는 큰 이유 중 하나가 바로 이 "잡음"입니다.

나쁜 예: <span>검색</span><svg>...</svg> — 텍스트와 아이콘이 같은 의미인데 둘 다 읽힘. "검색 이미지 검색"처럼 군더더기.
올바른 예: <span>검색</span><svg aria-hidden="true">...</svg> — 아이콘은 숨기고 텍스트만 한 번 읽히게.

판단 기준은 간단합니다. "이 아이콘을 통째로 지워도 옆 텍스트로 같은 정보를 얻을 수 있는가?" 그렇다면 그 아이콘은 장식이고, 숨겨야 합니다. 그런데 현장에서는 이 판단 자체를 안 합니다. svg를 화면에 얹는 것까지만 하고, "이게 의미인가 장식인가"를 따져 보는 단계가 통째로 빠져 있죠. 그래서 의미 있는 아이콘엔 이름이 없고(첫 번째 위반), 장식 아이콘은 시끄럽게 읽히는(두 번째 위반) 정반대 오류가 한 사이트 안에 공존합니다.

세 번째 위반 — 의미를 색으로만 전달한다

상태를 나타내는 아이콘에서 자주 터지는 위반입니다. 처리 완료는 초록 점, 오류는 빨간 점, 진행 중은 노란 점. 색만 다르고 모양은 똑같은 점 세 개로 상태를 구분하는 패턴입니다.

문제는 색각 이상(색맹·색약) 사용자입니다. 우리나라 남성의 상당 비율이 적록색약이라는 통계는 잘 알려져 있습니다. 이들에게 빨간 점과 초록 점은 거의 같은 색으로 보입니다. 즉 "오류"와 "정상"을 전혀 구분하지 못합니다. 저시력 사용자나 흑백 화면을 쓰는 사용자도 마찬가지입니다. 신청 상태가 "반려"인지 "승인"인지를 색 하나로만 구분해 둔 화면이라면, 이들은 자기 신청이 어떻게 됐는지조차 알 수 없습니다.

나쁜 예: 빨간 동그라미 / 초록 동그라미. 모양이 동일하고 색만 다름. 색 구분이 어려운 사용자는 동일하게 인식.
올바른 예: 색 + 모양(경고는 삼각형, 정상은 체크, 진행은 시계) + 텍스트("반려", "승인"). 세 가지가 함께 의미를 받쳐 줌.

이건 KRDS만의 까다로운 요구가 아니라 웹 접근성의 가장 기본적인 원칙 중 하나입니다 — "색만으로 정보를 전달하지 말 것." 그런데도 공공웹에서 끊임없이 반복됩니다. 디자이너가 색으로 깔끔하게 구분하는 데 익숙하다 보니, 색이 정보를 "보조"하는 게 아니라 "전담"하게 되는 거죠. 색은 정보를 강조하는 데 쓰되, 정보 그 자체는 모양과 텍스트로도 전달돼야 합니다.

네 번째 위반 — 너무 작고, 너무 흐리고, 누르기 힘들다

지각 위반의 대표 묶음입니다. 세 가지가 보통 함께 나타납니다.

너무 작은 아이콘. 디자인의 미니멀함을 추구하다 아이콘을 12px, 심하면 그보다 작게 그립니다. 고령 사용자나 저시력 사용자에게는 이게 거의 보이지 않습니다. 공공 서비스의 핵심 사용자층이 바로 이분들인데, 정작 화면은 젊고 시력 좋은 디자이너의 모니터 기준으로 만들어집니다.

너무 흐린 아이콘. 연한 회색 아이콘을 흰 배경에 얹는 경우. "은은하고 세련돼 보인다"는 이유로요. 그런데 명도 대비가 부족하면 저시력 사용자에게는 아이콘이 거의 사라집니다. 브랜드 색을 쓰겠다고 연한 파스텔 톤을 고집하다 대비를 놓치는 경우도 많습니다.

너무 좁은 터치 영역. 이게 특히 교묘합니다. 아이콘 그림 자체는 16px인데, 클릭/터치 영역도 딱 그 16px에만 걸려 있는 경우입니다. 마우스를 쓰는 젊은 사용자는 정확히 조준해서 누르니 문제를 못 느낍니다. 그런데 손이 떨리는 고령 사용자나, 화면을 손가락으로 누르는 모바일 사용자에게는 매번 빗나가는 고역이 됩니다. 옆 버튼이 눌리기도 하고요.

나쁜 예: 12px 연회색 아이콘, 클릭 영역이 그림에만 한정. 보이지도 않고 누르기도 어려움.
올바른 예: 충분한 크기와 명도 대비, 그리고 아이콘을 감싸는 버튼 영역을 약 44px 이상으로 넓게. 그림은 작아도 누를 수 있는 영역은 넉넉하게.

한국형 웹 접근성 지침(KWCAG)과 국제 표준 모두 터치 대상의 최소 크기를 권장하며, 보통 한 변 44px 이상을 기준으로 봅니다. 핵심은 "아이콘 그림 크기"와 "누를 수 있는 영역 크기"를 분리해서 생각하는 것입니다. 그림은 작게 그리되, 그것을 감싸는 버튼에 패딩을 충분히 줘서 누르기 쉽게 만들면 됩니다. 이 한 가지 발상만으로 터치 영역 위반의 대부분이 해결됩니다.

다섯 번째 위반 — 사라진 포커스 표시

키보드로 화면을 쓰는 사용자에게 치명적인 위반입니다. 그런데 마우스 사용자에게는 전혀 보이지 않아서, 거의 발견되지 않은 채 방치됩니다.

상황은 이렇습니다. 디자인 통일성을 위해, 혹은 "테두리가 지저분해 보인다"는 이유로 CSS에서 outline: none을 선언해 포커스 링(초점 표시)을 지워 버립니다. 그 순간 키보드 사용자는 자기가 지금 화면 어디에 있는지 알 수 없게 됩니다. Tab을 눌러 아이콘 버튼들 사이를 이동하는데, 어느 아이콘에 초점이 가 있는지 시각적으로 전혀 표시가 안 되는 거죠. 불 꺼진 방에서 손전등 없이 물건을 찾는 것과 같습니다.

이 위반이 무서운 건, 한 번 outline: none을 전역 CSS에 박아 두면 사이트 전체의 모든 버튼·링크·아이콘에서 포커스가 사라진다는 점입니다. 한 줄로 사이트 전체의 키보드 접근성이 무너집니다.

나쁜 예: *:focus { outline: none; } 같은 전역 선언. 모든 인터랙티브 요소의 초점 표시 소멸.
올바른 예: 포커스 시 또렷한 테두리·외곽선을 유지하거나, 디자인과 어울리는 대체 포커스 스타일을 제공. :focus-visible을 활용하면 마우스 클릭 시엔 안 보이고 키보드 이동 시에만 또렷하게 표시할 수도 있음.

포커스 표시는 "지우는 것"이 아니라 "디자인과 어울리게 다듬는 것"이 정답입니다. 깔끔함을 위해 지워야 할 대상이 아니라, 키보드 사용자에게는 화면을 항해하는 유일한 나침반이니까요.

여섯 번째 위반 — 의미 불명의 커스텀 아이콘

표준에 없는 독창적인 아이콘을, 그것도 텍스트 라벨 없이 사용하는 경우입니다. 디자이너의 창의성이 오히려 사용자를 추측 게임에 빠뜨리는 역설적 위반입니다.

KRDS가 표준 아이콘 세트를 제공하는 이유는 "같은 의미는 같은 모양으로"라는 약속을 만들기 위해서입니다. 검색은 돋보기, 메뉴는 줄 세 개처럼 보편적으로 학습된 아이콘을 쓰면 사용자가 처음 봐도 짐작할 수 있습니다. 그런데 디자이너가 "우리만의 개성"을 위해 검색을 추상적인 도형으로, 신청을 알 수 없는 픽토그램으로 새로 그리면, 그 사이트를 처음 방문한 사용자는 아이콘 하나하나가 다 수수께끼가 됩니다.

나쁜 예: 디자이너만 아는 추상 픽토그램을 라벨 없이 배치. 사용자는 "이게 뭐지?" 하며 일일이 눌러 봐야 정체를 알 수 있음.
올바른 예: KRDS 표준 아이콘 세트를 우선 사용. 표준에 없는 기능이라 부득이 새로 만들어야 한다면, 반드시 텍스트 라벨을 병기하고, KRDS 아이콘의 시각 스타일(선 두께·모서리·그리드)에 맞춰 같은 톤으로 제작.

핵심 교훈은 이겁니다. 공공 서비스에서 아이콘은 감상의 대상이 아니라 이정표입니다. 사용자는 디자인을 감상하러 온 게 아니라 볼일을 보러 온 국민입니다. 화려한 독창성보다 보편적 명료함이 먼저여야 합니다. 새 아이콘을 그리기 전에 항상 "이미 표준에 있는가"를 먼저 확인하는 습관이 위반을 막는 첫걸음입니다.

일곱 번째 위반 — 같은 의미, 다른 아이콘

일관성 위반의 대표 사례입니다. 한 사이트 안에서 "닫기"를 어떤 페이지는 X로, 어떤 페이지는 ← 화살표로, 또 어떤 곳은 "닫기" 텍스트 버튼으로 제각각 표현하는 경우입니다.

사용자 입장에서 보면, 사이트를 옮겨 다닐 때마다 "여기선 닫기가 어떤 모양이지?"를 다시 학습해야 합니다. 한 번 익힌 사용법이 다음 페이지에서 안 통하니, 학습 비용이 페이지 수만큼 늘어납니다. 특히 디지털에 서툰 사용자에게 이 "매번 다시 배우기"는 생각보다 큰 장벽입니다.

이 위반은 보통 조직 구조에서 옵니다. 페이지를 여러 팀이 나눠 만들거나, 시기를 달리해 개발하다 보면 각자 다른 아이콘을 쓰게 됩니다. 이걸 막으려면 디자인 시스템 차원에서 "닫기는 X, 메뉴는 줄 세 개"처럼 동작별 아이콘을 한 번 정해 전사에 적용해야 합니다. KRDS 표준을 채택하면 이 결정을 처음부터 내려 둔 셈이 되어, 팀이 달라도 자연스럽게 통일됩니다.

나쁜 예: 모달은 X로 닫고, 알림은 화살표로 닫고, 팝업은 "닫기" 텍스트로 닫음. 같은 동작인데 모양이 셋.
올바른 예: "닫기"는 사이트 전체에서 동일한 아이콘(과 라벨). 동작별로 한 번 정해 일관되게 적용.

여덟 번째 위반 — 외부에서 긁어온 제각각 아이콘

일관성 위반의 또 다른 형태이자, 시각적 품질을 가장 직접적으로 해치는 위반입니다. 여러 무료 아이콘 사이트에서 그때그때 필요한 걸 가져와 쓰다 보니, 선 두께도 스타일도 제각각인 아이콘이 한 화면에 섞이는 경우입니다.

어떤 아이콘은 가는 선(thin), 어떤 건 두꺼운 선(bold), 어떤 건 속이 채워진 면(filled), 어떤 건 모서리가 둥글고 어떤 건 각졌습니다. 이런 아이콘들이 한 줄에 나란히 놓이면 화면이 들쭉날쭉 어수선해 보입니다. 사용자가 "왜 이 사이트는 정돈이 안 된 느낌이지?" 하고 느끼는 막연한 불편의 정체가, 사실은 이 아이콘 스타일 불일치인 경우가 많습니다.

여기에 더해 라이선스 문제도 따라옵니다. 출처가 제각각인 아이콘은 상업적/공공 사용 라이선스가 명확하지 않은 경우가 있어, 나중에 법적 위험으로 번질 수도 있습니다.

나쁜 예: A 사이트에서 검색, B 사이트에서 메뉴, C 사이트에서 설정 아이콘을 가져와 섞음. 선 두께·채움·모서리가 전부 다름. 라이선스도 불명확.
올바른 예: KRDS 표준 세트처럼 한 가족으로 디자인된 통일된 아이콘 세트를 일괄 사용. 스타일도 라이선스도 한 번에 해결.

KRDS가 아이콘을 SVG로, 통일된 스타일로 묶어 제공하는 이유가 정확히 이겁니다. 선 두께, 외곽 그리드, 모서리 처리, 시각적 정렬까지 한 톤으로 맞춰져 있어서, 가져다 쓰기만 하면 화면이 자동으로 정돈됩니다.

아홉 번째 위반 — 이모지를 아이콘 대신 쓰기

비교적 최근에 늘어난 위반입니다. 개발이 간편하다는 이유로, 정식 아이콘 대신 이모지(😀 🔍 ⚙️)를 아이콘처럼 박아 넣는 경우입니다.

문제는 여러 겹입니다. 첫째, 이모지는 기기·운영체제·폰트마다 모양이 다르게 보입니다. 디자이너 맥에서는 깔끔한데, 사용자의 구형 안드로이드에서는 전혀 다른 모양이거나 네모 박스(□)로 깨져 보일 수 있습니다. 둘째, 스크린리더가 이모지를 의도와 다르게 읽습니다. 예를 들어 특정 이모지를 장황한 공식 이름으로 낭독하거나, 엉뚱한 의미로 읽어 버립니다. 셋째, 색과 크기를 디자인 의도대로 통제하기 어렵습니다.

나쁜 예: 검색 버튼에 🔍 이모지. 기기마다 모양 제각각, 스크린리더는 "돋보기 기울어진" 같은 의도치 않은 이름으로 낭독.
올바른 예: 기능 아이콘은 KRDS 표준 SVG를 사용. 모양이 일관되고, 접근성 속성을 붙이기 좋으며, 크기를 키워도 선명함.

공공 서비스처럼 사용자 기기 환경이 천차만별인 곳에서는 특히 이모지 사용을 피해야 합니다. "어디서나 똑같이 보이고, 똑같이 읽히는" 것이 공공웹의 기본인데, 이모지는 그 기본을 충족하지 못합니다.

열 번째 위반 — 움직이는 아이콘의 의미가 안 닿는다

스피너(빙글빙글 도는 로딩 아이콘)나 진행 표시 같은 "움직이는 아이콘"에서 나는 위반입니다. 시각적으로는 "기다리세요"를 전하지만, 화면을 못 보는 사용자에게는 이 회전이 전혀 전달되지 않습니다.

흔한 상황을 그려 보겠습니다. 사용자가 신청서 제출 버튼을 누르자 화면에 로딩 스피너가 돕니다. 마우스 사용자는 "아, 처리 중이구나" 하고 기다립니다. 그런데 스크린리더 사용자는 아무 소리도 듣지 못합니다. 화면이 멈춘 건지, 처리가 되고 있는 건지, 끝난 건지 알 수 없습니다. 무작정 기다리거나, 다 됐는 줄 알고 다른 행동을 해서 오류를 일으키기도 합니다.

나쁜 예: 회전하는 svg 스피너만 표시. 코드상으로는 로딩 상태에 대한 어떤 텍스트 정보도 없음.
올바른 예: 스피너와 함께 aria-live 영역에 "처리 중입니다", 완료 시 "처리가 완료되었습니다" 같은 텍스트를 갱신해 스크린리더가 진행/완료를 듣게 함.

여기에 더해, 과도하게 빠르거나 번쩍이는 애니메이션은 일부 사용자에게 불편이나 발작 위험이 될 수 있으니 절제해야 합니다. 핵심 원칙은 한결같습니다 — 아이콘의 "움직임"에만 의미를 싣지 말고, 그 의미가 텍스트로도 닿게 하라.

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

추상적인 위반 목록보다 한 장면이 더 와닿을 것 같습니다. 어느 공공 서비스의 모바일 화면, 우측 상단에 돋보기 아이콘 하나가 있다고 합시다. 텍스트는 없고 그림만 있는, 앞서 본 첫 번째 위반의 전형입니다.

먼저 스마트폰을 눈으로 보며 쓰는 이 주무관. 돋보기를 보고 "아, 검색이구나" 하고 누릅니다. 0.5초도 안 걸립니다. 그에게 이 아이콘은 완벽합니다. 그래서 이 화면을 만든 팀도 자기들끼리 써 보고 "직관적이다, 깔끔하다"라고 자평했습니다. 실제로 보기엔 아무 문제가 없으니까요.

이번엔 시각장애가 있는 한 선생님. 스크린리더를 켜고 화면을 위에서부터 훑어 내려갑니다. 우측 상단 그 자리에서 스크린리더가 "버튼"이라고만 말하고 멈춥니다. 무슨 버튼인지 알 수 없습니다. 돋보기 그림은 코드상 이름이 없어서, 스크린리더가 "검색"이라고 말해 줄 수가 없거든요. 한 선생님은 잠시 망설이다 그 버튼을 그냥 지나칩니다. 검색 기능이 분명히 있는데도, 그에게는 처음부터 없었던 기능입니다. 결국 원하는 정보를 못 찾고 사이트를 떠나거나, 가족에게 대신 찾아 달라고 부탁합니다.

같은 돋보기, 같은 버튼. 한 사람에겐 0.5초짜리 직관이고, 다른 한 사람에겐 보이지 않는 기능입니다. 그리고 이 차이는 "예산이 부족해서"나 "기술이 어려워서" 생긴 게 아닙니다. 그저 만들 때 마우스 쓰는 사람만 떠올렸기 때문에 생긴 차이입니다. 이 위반을 메우는 비용은 놀랄 만큼 작습니다. 버튼에 aria-label="검색" 한 줄. 그거면 한 선생님의 스크린리더도 "검색, 버튼"이라고 읽어 줍니다. 아이콘 위반의 해결은 거창한 기술이 아니라, 이 작은 한 줄을 빠뜨리지 않는 습관의 문제입니다.

그런데 여기서 진짜 문제가 드러납니다. 이 위반을 "사람이" 발견하려면 누군가 스크린리더를 켜고 모든 페이지의 모든 아이콘 버튼을 일일이 훑어야 합니다. 페이지가 수백 개인 공공 사이트에서 이걸 손으로 하는 건 사실상 불가능합니다. 그래서 자동 점검이 필요한 겁니다.

왜 공공웹은 유독 아이콘을 자주 틀릴까 — 배경과 원리

여기까지 보면 "왜 이렇게 똑같은 실수가 끝없이 반복되나" 싶으실 겁니다. 여기엔 공공웹 특유의 구조적 배경이 있습니다.

작아서 검수 우선순위에서 밀린다

아이콘은 화면에서 차지하는 면적이 작습니다. 그래서 검수할 때 자연스럽게 후순위로 밀립니다. 메인 비주얼이나 핵심 배너는 모두가 눈을 부릅뜨고 보지만, 우측 상단의 16px짜리 아이콘이 스크린리더에 어떻게 읽히는지는 아무도 확인하지 않습니다. 면적은 작아도, 그 작은 아이콘이 검색·메뉴·로그인 같은 핵심 동작의 입구라는 사실을 간과하는 거죠.

만든 사람에겐 너무 명백하다

디자이너가 직접 고른 아이콘이라, 그에게는 의미가 자명합니다. 돋보기는 당연히 검색이고, 톱니바퀴는 당연히 설정이죠. 이 "자명함"이 함정입니다. 만든 사람의 머릿속에서는 의미가 완벽하게 연결돼 있으니, 코드에 그 의미를 명시할 필요를 못 느낍니다. 하지만 처음 방문한 사용자에게도, 스크린리더에게도 그 자명함은 존재하지 않습니다. 보이는 그림과 코드가 담은 의미는 별개라는 사실 — 이걸 놓치면 모든 아이콘 위반이 시작됩니다.

테스트가 항상 마우스로 이뤄진다

가장 근본적인 이유일지도 모릅니다. 화면을 만들고 검수하는 거의 모든 사람이 마우스(또는 트랙패드)와 정상 시력으로 테스트합니다. 키보드만으로, 혹은 스크린리더로, 혹은 흑백 화면으로 써 보는 사람이 없으면, 앞서 본 위반들은 단 하나도 드러나지 않습니다. 마우스로는 전부 멀쩡하게 작동하니까요. "우리가 써 보니 잘 되더라"는 말이 위험한 이유가 여기 있습니다 — 그 "우리"가 대부분 비장애·마우스 사용자거든요.

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

이 모든 위반이 상업 사이트보다 공공웹에서 훨씬 심각한 이유가 있습니다. 상업 사이트는 불편하면 사용자가 경쟁사로 떠나면 그만입니다. 그런데 공공 서비스는 대체재가 없습니다. 주민등록 등본을 떼거나, 복지를 신청하거나, 세금을 내는 일은 그 사이트가 아니면 할 수 없습니다. 사용자에게 "안 쓸 자유"가 없어요. 그래서 공공웹의 아이콘이 누군가에게 작동하지 않으면, 그건 단순한 불편이 아니라 행정 서비스 접근권의 박탈이 됩니다.

게다가 디지털에 가장 서툰 분들 — 고령층, 장애인, 저소득층 — 이야말로 공공 서비스를 가장 절실히 필요로 합니다. 복지 신청, 의료 예약, 민원 처리가 이분들에게는 더없이 중요한데, 동시에 이분들이 정체불명의 아이콘 앞에서 가장 쉽게 길을 잃습니다. 모르는 그림 하나가, 누군가에게는 "이 서비스는 나를 위한 게 아니구나" 하는 좌절이 됩니다. 아이콘 위반을 고치는 일이 단순한 기술 작업이 아니라 포용의 문제인 이유입니다.

직접 적용하기 — 위반을 만들지 않는 개발·디자인 습관

위반 사례를 잔뜩 봤으니, 이제 처음부터 위반을 만들지 않는 방법으로 넘어가겠습니다. KRDS의 좋은 점은, 위반을 막을 도구를 바로 쓸 수 있는 자산으로 제공한다는 것입니다.

개발자라면 — 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을 지웠다면 :focus-visible 등으로 대체 스타일 제공), 상태 아이콘에는 색 외에 모양·텍스트 동반, 로딩 아이콘에는 aria-live 영역으로 진행/완료 안내. 이 항목들은 한 번 공통 아이콘 버튼 컴포넌트로 만들어 두면 이후엔 자동으로 따라옵니다. 그래서 처음에 KRDS 킷 기반으로 공통 컴포넌트를 잡아 두는 게 장기적으로 가장 위반을 적게 내는 길입니다.

디자이너라면 — KRDS 공식 Figma(@krds) 라이브러리에서 표준 아이콘을 컴포넌트로 가져다 배치할 수 있습니다. 새 아이콘을 만들기 전에 반드시 "이미 표준에 있는가"를 확인하세요. 표준에 있는 걸 새로 그리는 건 일관성 위반의 시작입니다. 그리고 시안 단계에서부터 아이콘 버튼 옆에 "이 아이콘의 동작 이름"(예: 메뉴 열기)을 주석으로 달아 두면, 개발 단계의 라벨 누락을 막을 수 있습니다.

기획자라면 — 화면 정의서에 "아이콘 버튼"이라고만 쓰지 말고, 그 아이콘이 의미하는 동작 이름을 함께 적으세요. "우측 상단 검색 아이콘 버튼(라벨: 검색)"처럼요. 이 한 줄이 디자인·개발 단계의 누락을 막는 가장 싼 보험입니다. 그리고 검수 단계에 "키보드만으로 모든 아이콘 버튼에 닿는가", "스크린리더로 모든 아이콘 버튼의 이름이 읽히는가"를 체크 항목으로 넣어 두세요.

위반을 부르는 라벨 vs 좋은 라벨

라벨을 붙이기로 했어도, 문구를 잘못 쓰면 또 다른 위반이 됩니다.

군더더기 빼기: "검색 버튼 아이콘"처럼 "버튼/아이콘"을 라벨에 넣지 마세요. 스크린리더가 이미 역할을 "버튼"이라고 읽어 주므로 "검색 버튼 버튼"처럼 중복됩니다. 라벨은 "검색"이면 충분합니다.
동작 중심으로: 메뉴 버튼이면 "메뉴 열기", 닫기 버튼이면 "닫기"처럼 결과를 짐작할 수 있게.
토글은 상태도 함께: 펼침/접힘이 바뀌는 버튼은 aria-expanded로 현재 상태를 전달해 "메뉴, 접힘 → 메뉴, 펼침"처럼 변화가 읽히게.
같은 동작엔 같은 문구: "닫기"를 어떤 곳은 "닫기", 어떤 곳은 "창 닫기", 어떤 곳은 "취소"로 쓰면 일관성이 깨집니다. 동작별 표준 문구를 한 번 정하세요.

그래서 우리 사이트는? — ViewCheck로 위반 잡아내기

여기까지 위반 사례를 봤으니, 이제 진짜 중요한 질문이 남습니다. "그래서 우리 사이트는 이 중 몇 개나 틀리고 있을까?" 솔직히 이 질문에 손으로 답하긴 어렵습니다. 아이콘 버튼이 몇 개인지, 각각 이름이 붙어 있는지, 장식 아이콘이 잘못 노출되는지, 색으로만 상태를 표시하는지, 포커스가 살아 있는지를 페이지마다 일일이 확인하려면 끝이 없으니까요. 페이지가 수십·수백 개인 공공 사이트라면 더더욱요.

ViewCheck(krds.viewcheck.co.kr)는 이 점검을 자동화합니다. URL만 넣으면 페이지를 실제로 크롤링해서, 아이콘과 관련된 KRDS 기준을 자동으로 판정합니다. 아이콘은 KRDS 846규칙 중 디자인 스타일(DS) 규칙군 120개와 컴포넌트 접근성 항목에 걸쳐 있고, 분석 결과의 디자인 시스템(Design System) 탭에서 확인할 수 있습니다.

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

이름 없는 아이콘 버튼 탐지: 라벨(aria-label / 연결된 텍스트) 없이 아이콘만 있는 버튼을 찾아냄. 앞서 본 1번 위반.
장식/의미 아이콘 처리: 텍스트와 중복되는 아이콘이 적절히 aria-hidden 처리됐는지. 2번 위반.
크기·대비·터치 영역: 아이콘 버튼의 터치 영역과 색 대비가 기준을 충족하는지(반응형·대비 분석과 연계). 4번 위반.
일관성·표준 채택: 디자인 토큰 채택률 리포트를 통해, 아이콘을 포함한 시각 요소가 KRDS 표준을 얼마나 따르는지. 7·8번 위반과 연결.

DOM(코드)만으로 판단하기 어려운 시각적 부분 — 예를 들어 이미지로 박아 넣은 아이콘, 비표준으로 구현한 커스텀 드롭다운의 아이콘 — 은 KRDScan Vision AI가 스크린샷을 함께 보고 보강 판정합니다. 그래서 "코드엔 아이콘 같은 게 없는데 화면엔 분명히 그림 버튼이 있는" 비표준 구현도 놓치지 않습니다. 이 점이 단순 코드 검사 도구와 다른 부분입니다 — 사람이 눈으로 보듯 화면을 함께 보기 때문에, 표준을 우회해 만든 UI도 잡아냅니다.

리포트를 어떻게 읽나

분석이 끝나면 디자인 시스템 탭에서 아이콘 관련 규칙의 통과/미통과 수와, 미통과한 항목의 위치(어느 페이지)·이유·개선 방법(howToFix)이 함께 나옵니다. 예를 들어 "검색 페이지 헤더의 아이콘 버튼 2개가 라벨 미연결"처럼 구체적으로요. 막연한 "아이콘 잘 쓰자"가 아니라 "이 페이지의 이 아이콘 버튼에 이 라벨을 붙이자"는 작업 목록이 나오는 셈입니다.

특히 ViewCheck의 강점은 다중 페이지 분석입니다. 여러 페이지를 한꺼번에 돌리면, "메인은 멀쩡한데 신청 페이지의 아이콘 버튼들만 라벨이 빠졌다" 같은 페이지별 편차가 한눈에 드러납니다. 위반이 특정 팀이 만든 특정 페이지군에 몰려 있는 경우가 많은데, 이 패턴을 보면 어느 코드를 손봐야 가장 효율적인지 바로 보입니다. 그리고 어디부터 고쳐야 하는지 우선순위(P0~P3)가 함께 매겨지니, 한정된 시간에 가장 중요한 것부터 손볼 수 있습니다.

무료 진단으로 메인 페이지부터 한 번 돌려 보면, 우리 사이트의 아이콘이 지금 몇 개의 위반을 안고 있는지 5분 만에 확인됩니다. 손으로는 몇 시간 걸릴 점검이 몇 분이면 끝나고, 그 결과는 막연한 다짐이 아니라 구체적인 개선 작업의 출발점이 됩니다.

자주 묻는 질문

현장에서 아이콘 위반을 다룰 때 반복해서 나오는 질문들을 모았습니다.

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

네, 필요합니다. 이게 가장 흔한 오해입니다. 시각적으로 익숙한 것과 코드로 전달되는 것은 완전히 별개입니다. 마우스 사용자에게는 줄 세 개가 "메뉴"로 보이지만, 스크린리더 사용자에게는 그 정보가 코드(aria-label="메뉴 열기")로 담겨야만 전달됩니다. 유명세는 접근성을 면제해 주지 않습니다. 게다가 메뉴가 열렸는지 닫혔는지 상태(aria-expanded)까지 알려 주면 더 좋습니다.

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

텍스트 라벨이 함께 있으면 그 아이콘은 장식으로 봐도 됩니다. 다만 "괜찮다"가 아니라 "숨겨야 한다"가 정답입니다. 아이콘을 aria-hidden="true"로 처리하지 않으면 스크린리더가 텍스트와 아이콘을 둘 다 읽어 "검색 이미지 검색"처럼 중복 낭독합니다. 한 화면에 이런 아이콘이 많으면 음성 사용자에게는 상당한 잡음이 됩니다. "있으니 괜찮다"가 아니라 "숨겨서 깔끔하게"입니다.

Q. 디자인이 마음에 안 들어서 커스텀 아이콘을 쓰고 싶은데요?

브랜드 표현이 필요한 곳에는 특수 아이콘을 쓸 수 있습니다. 다만 검색·메뉴·닫기 같은 보편 기능까지 독창적으로 새로 만들면 사용자가 혼란스럽습니다. 보편 기능은 표준을, 브랜드 표현이 꼭 필요한 곳은 신중하게 — 그리고 어느 쪽이든 의미 있는 아이콘에는 반드시 이름을 붙이세요. 새 아이콘은 KRDS 아이콘의 시각 스타일(선 두께·모서리·그리드)에 맞춰 같은 톤으로 만들어야 화면이 어수선해지지 않습니다.

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

권장하지 않습니다. 이모지는 기기·폰트마다 모양이 다르게 보이고(구형 기기에서는 네모 박스로 깨지기도 합니다), 스크린리더가 의도와 다른 이름으로 읽는 경우가 많습니다. 공공 서비스처럼 사용자 기기 환경이 천차만별인 곳에서는 특히 피해야 합니다. 기능 아이콘은 KRDS 표준 SVG를 쓰는 게 안전합니다 — 어디서나 똑같이 보이고, 접근성 속성을 붙이기 좋으며, 크기를 키워도 선명합니다.

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

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

Q. 상태를 색으로 구분하는 게 가장 직관적인데, 꼭 모양·텍스트까지 넣어야 하나요?

색은 정보를 강조하는 데 쓰되, 정보 그 자체를 색에만 싣지는 마세요. 우리나라 남성 중 적지 않은 비율이 적록색약이라, 빨강과 초록을 거의 같은 색으로 봅니다. 이들에게 색으로만 구분한 "오류/정상"은 무용지물입니다. 색 + 모양(경고는 삼각형, 정상은 체크) + 텍스트("반려", "승인")를 함께 쓰면 모든 사용자가 같은 정보를 얻습니다. 색은 빼라는 게 아니라, 색"만"으로는 안 된다는 뜻입니다.

Q. 포커스 표시가 디자인을 해치는데 꼭 둬야 하나요?

꼭 둬야 합니다. 포커스 표시는 키보드 사용자가 화면 어디에 있는지 알 수 있는 유일한 단서입니다. outline: none으로 지우면 그들은 길을 잃습니다. 다만 기본 외곽선이 투박하다면 디자인과 어울리게 다듬으면 됩니다. :focus-visible을 쓰면 마우스 클릭 시에는 안 보이고 키보드 이동 시에만 또렷하게 표시할 수 있어서, 미관과 접근성을 둘 다 챙길 수 있습니다. 포커스 표시는 "지우는 것"이 아니라 "다듬는 것"입니다.

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

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

Q. 우리 팀은 마우스로 다 테스트해서 문제없다고 봤는데, 왜 위반이 나오나요?

바로 그 "마우스로 테스트했다"는 점이 위반을 숨긴 원인입니다. 앞서 본 위반들 — 이름 없는 버튼, 사라진 포커스, 색 의존 — 은 전부 마우스와 정상 시력으로는 멀쩡하게 작동합니다. 키보드만으로, 스크린리더로, 흑백 화면으로 써 봐야 비로소 드러납니다. "우리가 써 보니 잘 되더라"가 위험한 이유가 이겁니다. 그 "우리"가 대부분 비장애·마우스 사용자거든요. 그래서 자동 점검 도구나 다양한 환경 테스트가 필요합니다.

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

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

가장 먼저(치명적) — 이름 없는 아이콘 전용 버튼, 특히 메뉴·검색·닫기·로그인처럼 핵심 동작 버튼. 그리고 사라진 포커스 표시. 이건 특정 사용자에게 기능을 완전히 차단하는 문제라 1순위입니다. "예쁘게 만든 아이콘 버튼"이 사실 여기 해당하는 경우가 정말 많습니다. 서비스의 핵심 경로(신청·로그인)에 있다면 더더욱 먼저 손봐야 합니다.

그다음(높음) — 색으로만 의미를 전달하는 상태 아이콘, 그리고 의미 불명의 커스텀 아이콘. 작동은 하지만 특정 사용자(색각 이상자, 처음 방문자)가 정보를 얻지 못하니 실질적 장벽입니다.

그 후(보통) — 장식 아이콘의 중복 낭독, 작은 터치 영역, 낮은 명도 대비. 사용은 가능하지만 특정 상황·특정 사용자에게 불편을 주는 문제입니다.

여력이 되면(낮음) — 같은 의미인데 제각각인 아이콘 통일, 외부에서 긁어온 아이콘을 KRDS 표준으로 교체. 접근성을 막는 건 아니지만 일관성과 시각 품질을 한 단계 끌어올리는 항목입니다.

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

5분 셀프 점검 — 지금 바로 위반 찾기

거창한 도구 없이도, 지금 우리 사이트에서 아이콘 위반을 직접 찾아볼 수 있습니다. 순서대로 해보세요. 다섯 가지가 각각 앞서 본 위반에 대응합니다.

1. 마우스를 치우고 Tab만으로 화면을 훑어 보세요. 우측 상단 아이콘들(검색·메뉴·설정 등)에 초점이 가나요? 가서 또렷이 보이나요? 안 가면 키보드 접근 불가, 안 보이면 포커스 표시 위반입니다.

2. 개발자도구로 아이콘 svg를 잠시 숨기거나 이미지를 꺼 보세요. 그래도 무슨 버튼인지 알 수 있나요? 텍스트 라벨이 없다면, 시각장애인에게 그 버튼은 사라진 셈입니다. 이름 없는 버튼 위반.

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

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

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

이 다섯 가지만 해봐도 대부분의 아이콘 위반이 드러납니다. 다만 페이지가 많아지면 사람이 다 보기 어렵습니다 — 그때 ViewCheck로 전 페이지를 한 번에 점검하면 됩니다. 사람이 5분에 한 페이지를 본다면, 도구는 5분에 사이트 전체를 봅니다.

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

이 글은 KRDS 아이콘 기준을 어겼을 때 생기는 위반을 실무 관점에서 풀어 쓴 것입니다. 정확한 원문 기준과 코드·디자인 자산은 아래 공식 자료에서 직접 확인하실 수 있습니다.

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 등)이 있다(없으면 1번 위반).
☐ 텍스트와 함께 있는 장식 아이콘은 aria-hidden="true"로 숨겼다(안 숨기면 2번 위반).
☐ 상태를 색으로만 전달하지 않는다(모양·텍스트 병행. 색만 쓰면 3번 위반).
☐ 아이콘과 배경의 명도 대비가 충분하다(흐리면 4번 위반).
☐ 아이콘 버튼의 터치 영역이 충분하다(약 44px 이상. 좁으면 4번 위반).
☐ 키보드로 이동할 때 포커스 표시가 또렷하다(outline: none으로 지웠으면 5번 위반).
☐ 보편 기능은 KRDS 표준 아이콘을 우선 쓰고, 새 아이콘이면 텍스트를 병기한다(어기면 6번 위반).
☐ 같은 의미에는 같은 아이콘을 쓴다(전사 통일. 제각각이면 7번 위반).
☐ 아이콘을 한 통일된 세트에서 가져온다(외부에서 제각각 긁어오면 8번 위반).
☐ 기능 아이콘으로 이모지를 쓰지 않는다(쓰면 9번 위반).
☐ 움직이는 아이콘(로딩 등)은 텍스트로도 진행/완료를 알린다(aria-live. 안 하면 10번 위반).

KRDS 컴포넌트 킷(npm install krds-uiux 또는 CDN)을 쓰면 위 항목 대부분이 이미 해결된 상태로 시작할 수 있습니다. 직접 만들다 위반을 낼 위험을 줄이는 가장 확실한 방법이죠. 공식 Figma 라이브러리(@krds)에서는 디자이너가 표준 아이콘을 그대로 가져다 쓸 수 있습니다.

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

오늘 이야기를 한 문장으로 줄이면 이렇습니다. "아이콘은 보여 주기 위한 게 아니라, 알아보게 하기 위한 것이다." 그래서 의미 있는 아이콘에는 이름을 주고, 장식 아이콘은 숨기고, 색만으로 말하지 않고, 키보드로 닿게 하고, 같은 의미는 같은 모양으로, 표준을 우선 쓰고, 헷갈릴 것 같으면 텍스트를 함께 둡니다. 어느 것도 어려운 기술이 아닙니다. 다만 "작아서 그냥 넘기던" 습관을 한 번 멈춰 세우면 됩니다. 그 작은 멈춤이, 위반을 막는 시작입니다.

완벽을 한 번에 만들 필요는 없습니다. 가장 많은 사용자를 막고 있는 위반 하나부터 고쳐 나가면, 우리 사이트는 분명히 조금씩 더 많은 사람에게 열립니다. 그리고 그 위반이 지금 어디에 몇 개나 있는지는, ViewCheck로 5분이면 확인할 수 있습니다.

우리 사이트의 아이콘은 지금 몇 개의 위반을 안고 있을까요? krds.viewcheck.co.kr에서 URL만 넣으면, 이름 없는 아이콘 버튼이 어디에 있는지 무료로 확인할 수 있습니다. 메인 페이지 하나만 돌려 봐도, 위 체크리스트가 실제로 지켜지고 있는지 바로 보입니다.

#KRDS #공공웹 #디자인시스템 #아이콘Icon #웹접근성 #ViewCheck #정부웹사이트 #UIUX #픽토그램 #aria라벨 #KWCAG #포용성 #아이콘 #Icon #흔한실수 #개선사례 #안티패턴 #디자인토큰 #디자인스타일 #전자정부