KRDS 컴포넌트 킷 적용 — npm·CDN 5분 세팅 (개발자)

새 공공 사이트 프로젝트가 떨어지면, 개발자들이 제일 먼저 하는 일이 뭘까요? 의외로 "버튼 컴포넌트 만들기"입니다. 그다음은 입력창, 셀렉트, 모달, 탭, 페이지네이션… 그렇게 한 달쯤 지나면 어디서 많이 본 컴포넌트들이 슬슬 갖춰집니다. 문제는 그 한 달이 통째로 "이미 누가 만들어 놓은 걸 다시 만드는" 시간이라는 겁니다. 그것도 접근성 빠뜨려 가면서, 디자인 토큰 제각각으로, 기관마다 또다시.

저는 공공 사이트를 수백 개 분석하면서 한 가지 패턴을 거듭 봤습니다. "잘 만든 사이트"의 공통점은 화려한 기술이 아니라, 이미 검증된 표준 컴포넌트를 가져다 썼다는 것이었어요. 반대로 "문제 많은 사이트"는 대부분 직접 손으로 만든 컴포넌트가 곳곳에서 접근성을 흘리고 있었습니다. 키보드로 안 열리는 드롭다운, 스크린리더가 못 읽는 버튼, 라벨이 코드에 연결 안 된 입력창. 전부 "직접 만들다 빠뜨린" 것들이죠.

그래서 KRDS(대한민국 정부 디자인 시스템)는 컴포넌트를 "알아서 잘 만드세요"로 끝내지 않습니다. 디자인 토큰부터 HTML·CSS·JS 코드까지, 바로 가져다 쓸 수 있는 컴포넌트 킷을 통째로 공개해 둡니다. npm install 한 줄, 혹은 CDN <link>·<script> 두 줄이면 시작할 수 있어요. 이 글은 그 컴포넌트 킷을 실제 프로젝트에 5분 만에 붙이는 법을 개발자 관점에서 단계별로 풀고, 붙인 다음 "제대로 적용됐는지"를 ViewCheck로 자가진단하는 체크리스트까지 한 바퀴 돌립니다.

미리 한 가지만 말씀드리면, 이 글은 "킷을 쓰면 다 끝난다"는 얘기가 아닙니다. 킷을 설치해 놓고도 절반만 적용해서 점수가 안 오르는 사이트가 정말 많거든요. CDN만 걸어 놓고 정작 컴포넌트는 예전 방식 그대로 쓰거나, 토큰은 무시하고 색을 하드코딩하거나, 킷의 JS를 안 불러서 키보드 동작이 죽어 있거나. "설치했다"와 "적용됐다" 사이엔 생각보다 큰 강이 흐릅니다. 그 강을 건너는 방법까지 다루는 게 이 글의 목적입니다.

컴포넌트 킷이 대체 뭔가 — 정의부터

용어부터 맞추겠습니다. "KRDS 컴포넌트 킷"은 정부 디자인 시스템을 실제 코드로 구현해 놓은 개발용 자산 묶음입니다. 그냥 디자인 가이드(글과 그림으로 된 문서)가 아니라, 브라우저에서 바로 동작하는 실물 코드예요. 크게 세 덩어리로 나눌 수 있습니다.

• 디자인 토큰: 색·타이포·간격·모서리 반경 같은 값들을 변수로 정의해 둔 것. "브랜드 블루는 정확히 이 값", "기본 여백은 8의 배수" 같은 약속을 코드로 박아 둔 겁니다.
• 컴포넌트 코드(HTML/CSS/JS): 버튼·입력·셀렉트·체크박스·탭·모달·아코디언·페이지네이션 등, 공공 서비스에서 반복되는 UI를 표준 마크업과 스타일·동작으로 구현해 둔 것.
• 에셋: 시스템 아이콘 SVG, 서체(Pretendard GOV 계열) 등 시각 요소.

이 세 가지가 "한 세트"라는 게 핵심입니다. 디자이너는 같은 토큰으로 시안을 그리고, 개발자는 같은 토큰·같은 컴포넌트로 구현하니까, 시안과 실제 화면 사이의 간극이 줄어듭니다. "디자인은 둥근데 구현은 각졌다", "시안은 파란데 코드는 다른 파랑이다" 같은 흔한 사고가 애초에 안 생기는 구조죠.

디자인 가이드와 컴포넌트 킷은 다르다

여기서 자주 헷갈리는 지점을 짚고 가겠습니다. KRDS에는 "가이드라인 PDF/웹 문서"와 "컴포넌트 킷"이 따로 있습니다.

• 가이드라인(디지털 정부서비스 UI/UX 가이드라인, 2025.08판): 무엇을 왜 그렇게 해야 하는지를 설명하는 문서. 정의·원칙·예시. 이건 "정답지"입니다.
• 컴포넌트 킷(GitHub `KRDS-uiux/krds-uiux`): 그 정답을 실제로 구현해 둔 코드. 이건 "정답대로 만든 부품"입니다.

가이드라인만 읽고 직접 만들 수도 있습니다. 하지만 그건 "요리책을 읽고 매번 처음부터 요리하는" 격이에요. 컴포넌트 킷은 "이미 만들어진 반조리 식품"에 가깝습니다. 둘 다 같은 레시피를 따르지만, 후자가 압도적으로 빠르고 실수가 적습니다. 특히 접근성처럼 "빠뜨리면 티는 안 나는데 누군가는 못 쓰게 되는" 영역에서, 검증된 부품을 쓰는 것의 가치는 큽니다.

왜 직접 만들면 안 되나 — 숨은 비용

"우리 팀 실력이면 직접 만들어도 되는데?" 충분히 그럴 수 있습니다. 문제는 유지보수입니다. 직접 만든 컴포넌트는 그 순간 우리 팀의 영원한 짐이 됩니다. 접근성 표준이 바뀌면 우리가 고쳐야 하고, 브라우저가 업데이트되면 우리가 테스트해야 하고, 새 개발자가 들어오면 우리 컨벤션을 가르쳐야 합니다. 반면 표준 킷을 쓰면 그 부담의 상당 부분이 킷 쪽으로 넘어갑니다. 버전을 올리면 개선이 따라오죠.

더 큰 문제는 "처음 한 명이 잘 만들어도, 나중에 다른 사람이 망친다"는 겁니다. 잘 만든 커스텀 셀렉트 옆에, 급한 일정에 쫓긴 다른 개발자가 <div>로 대충 만든 셀렉트를 하나 더 추가합니다. 그렇게 한 사이트 안에서도 컴포넌트가 제각각이 됩니다. 표준 킷은 이 "엔트로피 증가"를 막아 줍니다. 누가 만들든 같은 부품을 쓰니까요.

KRDS는 컴포넌트 킷에 무엇을 담아 두었나 — 자산 해부

컴포넌트 킷을 처음 열어 보면 폴더 구조에 좀 압도될 수 있습니다. 하지만 개발자가 실제로 챙겨야 할 핵심은 몇 개 안 됩니다. GitHub 저장소(KRDS-uiux/krds-uiux)를 기준으로, 실무에서 손대는 영역을 정리하겠습니다.

1) HTML 컴포넌트 코드 (`html/code`)

저장소의 html/code 폴더에는 컴포넌트별로 완성된 마크업이 들어 있습니다. 버튼, 입력, 셀렉트(여러 변형), 체크박스, 라디오, 탭, 아코디언, 모달, 페이지네이션, 브레드크럼, 테이블 등. 각 파일을 열어 보면 단순히 보기 좋은 HTML이 아니라, role·aria-* 속성과 적절한 시맨틱 태그가 이미 박혀 있습니다. 접근성이 마크업 단계에서부터 들어가 있다는 게 핵심입니다.

여기서 개발자가 얻는 가장 큰 이득은 "올바른 구조를 외우지 않아도 된다"는 점입니다. 예를 들어 아코디언을 직접 만들면 aria-expanded를 토글하고, aria-controls로 패널을 연결하고, 헤더를 버튼으로 감싸야 하는데, 이걸 매번 정확히 기억하기는 어렵습니다. 킷 코드를 복사해 오면 그 구조가 이미 정답대로 짜여 있습니다.

2) 스타일 (CSS / SCSS)

킷은 컴파일된 CSS(krds.min.css)와 원본 SCSS를 함께 제공합니다. 그냥 빠르게 쓰고 싶으면 컴파일된 CSS를 통째로 불러오면 되고, 디자인을 세밀하게 커스터마이즈하고 싶으면 SCSS 변수를 건드려 빌드할 수 있습니다. 어느 쪽이든 색·간격·타이포가 토큰으로 통제된다는 점이 중요합니다. 색을 #xxxxxx로 직접 박는 대신, 정의된 토큰(변수)을 참조하게 되어 있어요.

3) 자바스크립트 (`krds.min.js`)

여기가 많은 사람이 빠뜨리는 부분입니다. 모달 열고 닫기, 탭 전환, 아코디언 펼치기, 드롭다운 키보드 조작 같은 동작(behavior)은 JS가 담당합니다. CSS만 불러오고 JS를 안 불러오면, 화면은 KRDS처럼 보이는데 정작 키보드로 모달이 안 닫히거나 탭이 안 넘어가는 "껍데기만 KRDS"가 됩니다. 컴포넌트 킷을 쓸 거면 CSS와 JS를 둘 다 챙겨야 합니다.

4) 디자인 토큰

토큰은 색상 팔레트, 타이포 스케일, 간격 체계(8의 배수 그리드 계열), 모서리 반경, 그림자 등을 변수로 묶어 둔 것입니다. 컴포넌트들이 이 토큰을 참조하기 때문에, 토큰을 한 번 맞춰 두면 모든 컴포넌트가 일관되게 따라옵니다. 반대로 토큰을 무시하고 컴포넌트마다 색·여백을 임의로 덮어쓰기 시작하면, 킷을 쓰는 의미가 절반으로 줄어듭니다.

5) 아이콘과 서체

시스템 아이콘 SVG 세트와 정부 표준 서체(Pretendard GOV 계열)도 함께 제공됩니다. 아이콘은 같은 의미를 같은 모양으로 통일하기 위한 것이고, 서체는 가독성과 일관성을 위한 것입니다. 이것까지 킷으로 맞추면 "어느 정부 사이트에 와도 익숙한" 느낌이 완성됩니다.

정리하면, 컴포넌트 킷은 ① 접근성이 박힌 HTML, ② 토큰으로 통제된 CSS, ③ 동작을 살리는 JS, ④ 일관성을 만드는 토큰·아이콘·서체의 묶음입니다. 이 넷을 "다 함께" 적용해야 비로소 킷을 제대로 쓴 것입니다. 하나라도 빠지면 반쪽짜리가 됩니다. 그리고 이 "다 함께 적용됐는지"를 사람이 일일이 확인하기 어렵기 때문에, 뒤에서 다룰 자동 점검이 필요합니다.

5분 세팅 — 실제로 붙여 보기

이제 본론입니다. 컴포넌트 킷을 실제 프로젝트에 붙이는 길은 크게 두 갈래입니다. CDN 방식(가장 빠름)과 npm 방식(빌드 파이프라인에 통합). 상황에 맞게 고르면 됩니다.

방법 A) CDN — 가장 빠른 5분 세팅

빌드 도구가 없거나, 기존 사이트에 빠르게 얹어 보고 싶을 때 가장 간단합니다. HTML <head>에 CSS를, </body> 직전에 JS를 넣으면 끝입니다. 개념적으로는 이런 모양입니다.

• <head> 안: krds.min.css를 <link>로 연결
• 본문 끝: krds.min.js를 <script>로 연결

이 두 줄이 들어가는 순간, 킷의 토큰·스타일·동작이 페이지에 로드됩니다. 그다음 컴포넌트가 필요한 자리에 킷의 HTML 마크업을 그대로 붙이면 됩니다. 예를 들어 버튼이 필요하면, <button>을 임의 클래스로 만들지 말고 킷이 정의한 버튼 마크업·클래스를 복사해 옵니다.

CDN 방식의 장점은 "빌드 없이 즉시"입니다. 단점은 버전 고정·트리쉐이킹(안 쓰는 부분 제거) 같은 세밀한 관리가 어렵다는 점. 빠르게 시작하거나, 작은 페이지에 적용하거나, 일단 어떻게 생겼는지 보고 싶을 때 적합합니다.

방법 B) npm — 빌드 파이프라인에 통합

규모 있는 프로젝트라면 npm 방식이 정석입니다. 패키지를 설치한 뒤, 빌드 도구(Vite, webpack 등)에서 CSS·JS를 불러옵니다.

1. 설치: npm install krds-uiux

2. CSS 불러오기: 엔트리 파일이나 글로벌 스타일에서 킷의 CSS를 import

3. JS 불러오기: 필요한 컴포넌트의 스크립트(또는 번들)를 import 후 초기화

4. 토큰 연동: SCSS를 쓴다면 킷의 변수·믹스인을 import해서 우리 스타일에서도 같은 토큰을 참조

npm 방식의 장점은 버전 관리입니다. package.json에 버전이 박히니, 누가 받아도 같은 킷을 쓰고, 업그레이드도 명시적으로 통제됩니다. 또 빌드 단계에서 안 쓰는 스타일을 정리하거나, SCSS 변수를 조정해 커스터마이즈하기도 좋습니다. 협업 규모가 크고 오래 유지보수할 사이트라면 거의 항상 npm을 권합니다.

프레임워크(React/Vue 등)에 얹을 때

킷은 기본적으로 HTML/CSS/JS로 제공됩니다. React·Vue 같은 프레임워크를 쓴다면, 킷의 마크업을 컴포넌트로 감싸고 클래스·속성을 그대로 옮기는 식으로 적용합니다. 이때 주의할 점은 킷의 JS 동작과 프레임워크의 상태 관리가 충돌하지 않게 하는 것입니다. 예를 들어 모달의 열림/닫힘을 킷 JS에도 맡기고 프레임워크 state에도 맡기면, 둘이 따로 놀 수 있어요. 보통은 시각·구조·접근성 속성은 킷에서 가져오되, 열고 닫는 제어는 프레임워크 한쪽으로 통일하는 게 깔끔합니다. 어느 쪽으로 통일하든, aria-* 속성이 상태에 맞게 갱신되는지만 잊지 않으면 됩니다.

마이그레이션이라면 — 한꺼번에 vs 점진적

신규 프로젝트라면 처음부터 킷으로 시작하면 그만이지만, 현실에는 이미 운영 중인 사이트가 훨씬 많습니다. 기존 커스텀 컴포넌트로 굴러가는 사이트에 킷을 도입할 때, "한 번에 다 갈아엎을지, 점진적으로 옮길지"를 두고 늘 고민합니다.

결론부터 말하면, 규모 있는 공공 사이트는 거의 항상 점진적 전환이 답입니다. 한꺼번에 다 바꾸면 회귀 위험이 통제 불가능해지고, 검수도 한 번에 몰려 일정이 터집니다. 점진적 전환의 정석은 이렇습니다. 먼저 컴포넌트 종류별로 "사용 빈도 × 접근성 위험도"를 매겨 우선순위를 만듭니다. 신청 폼의 셀렉트·입력처럼 자주 쓰이고 접근성이 중요한 것이 맨 위, 푸터의 장식성 요소가 맨 아래죠. 그다음 한 종류씩 킷으로 교체하면서, 교체할 때마다 ViewCheck로 회귀가 없는지 확인합니다. 이렇게 하면 리뉴얼 예산을 한 번에 들이지 않고도 점수를 단계적으로 끌어올릴 수 있습니다.

한 가지 주의할 점은, 점진적 전환 도중에는 킷 컴포넌트와 레거시 컴포넌트가 한동안 공존한다는 겁니다. 이때 토큰만이라도 먼저 통일해 두면 시각적 이질감이 줄어듭니다. 색·간격 토큰을 킷 기준으로 맞춰 두면, 레거시 컴포넌트도 같은 색을 쓰게 되어 "옮기는 중"이라는 게 덜 티가 나죠.

"설치했다"와 "적용됐다"의 차이

여기까지 하면 "설치"는 끝났습니다. 하지만 앞서 강조했듯, 설치가 곧 적용은 아닙니다. 실무에서 가장 흔한 실패가 이겁니다.

• CSS만 불러오고 JS는 안 불러서 동작이 죽어 있음
• 킷을 설치해 놓고 정작 컴포넌트는 예전 커스텀 코드를 그대로 씀
• 토큰을 무시하고 색·여백을 곳곳에서 하드코딩으로 덮어씀
• 킷의 버튼은 쓰는데 셀렉트·모달은 직접 만든 채로 둠(부분 적용)

이 상태로는 "KRDS 킷을 적용했다"고 말하기 어렵습니다. 그래서 설치 다음에 반드시 검증 단계가 필요합니다. 그 검증을 자동화하는 게 바로 이 글 후반부의 핵심입니다.

한 장면 — 같은 컴포넌트, 두 개발팀

추상적인 얘기를 길게 늘어놓는 것보다, 한 장면을 그려 보는 게 빠를 것 같습니다. 비슷한 규모의 두 공공 서비스 프로젝트가 거의 같은 시기에 시작했다고 합시다. 둘 다 신청·조회·검색 기능이 있는, 전형적인 민원 사이트요.

먼저 A팀. 일정이 빠듯하니 "일단 빨리 만들자"는 분위기입니다. 버튼·입력·셀렉트·모달을 직접 손으로 만듭니다. 디자인 시안을 보면서 색을 하나하나 #값으로 박고, 드롭다운은 <div>로 모양만 잡고 클릭 이벤트를 붙입니다. 처음 한 달은 빨라 보입니다. 화면이 척척 나오니까요. 그런데 두 달째부터 균열이 보입니다. 새로 합류한 개발자가 만든 셀렉트는 먼저 사람이 만든 것과 미묘하게 색이 다릅니다. 키보드로 모달이 안 닫힌다는 제보가 들어옵니다. 접근성 점검에서 무더기로 미통과가 뜹니다. 그제야 "접근성을 붙이자"고 하는데, 이미 만든 컴포넌트를 다 뜯어고쳐야 합니다. 결국 두 번 만든 셈이 됐습니다.

이번엔 B팀. 시작할 때 반나절을 들여 KRDS 컴포넌트 킷을 붙였습니다. npm install krds-uiux 한 줄, CSS·JS 연동, 토큰 글로벌 설정. 그다음부터는 컴포넌트가 필요하면 킷의 마크업을 가져와 콘텐츠만 채웠습니다. 버튼·셀렉트·모달이 누가 만들든 똑같이 보이고 똑같이 동작합니다. 키보드로도 다 됩니다. 접근성 속성이 이미 박혀 있으니, 점검을 돌려도 컴포넌트 영역은 대부분 통과입니다. B팀은 "컴포넌트를 만드는 시간"을 "콘텐츠와 비즈니스 로직"에 썼습니다. 같은 기간에 A팀보다 더 많은 기능을 더 안정적으로 냈죠.

두 팀의 실력 차이일까요? 아닙니다. A팀이 B팀보다 못한 개발자들이어서가 아니라, "검증된 부품을 쓰느냐"라는 작은 선택 하나가 갈랐습니다. 직접 만든 컴포넌트는 그 순간엔 빨라 보여도, 접근성·일관성·유지보수라는 청구서가 나중에 한꺼번에 날아옵니다. 컴포넌트 킷은 그 청구서를 처음부터 안 만드는 선택입니다. 그리고 어느 팀이 어느 쪽인지는, ViewCheck로 사이트를 한 번 돌려 보면 컴포넌트 탭에 고스란히 드러납니다.

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

"컴포넌트 킷 좀 붙이는 게 뭐 대수라고 이렇게 길게 쓰나" 싶으실 수 있습니다. 그런데 이 작은 선택이 사이트 전체의 품질을 가르는 길목이라, 배경을 짚고 가겠습니다.

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

상업 사이트는 불편하면 사용자가 경쟁사로 떠나면 그만입니다. 공공 서비스는 다릅니다. 주민등록 등본을 떼거나, 보조금을 신청하거나, 세금을 내는 일은 그 사이트가 아니면 할 수 없어요. 사용자에게 "안 쓸 자유"가 없습니다. 그래서 컴포넌트 하나가 누군가에게 작동하지 않으면, 그건 단순한 불편이 아니라 행정 서비스 접근권의 박탈이 됩니다.

키보드로 안 열리는 셀렉트는 마우스를 못 쓰는 사람에게 닫힌 문입니다. 라벨이 연결 안 된 입력창은 시각장애인에게 정체불명의 빈칸입니다. 이런 결함은 대개 "직접 만들다 빠뜨려서" 생깁니다. 검증된 컴포넌트 킷을 쓰면, 이 "빠뜨림"의 상당수가 애초에 발생하지 않습니다. 킷이 접근성을 기본값으로 깔고 시작하니까요.

일관성이 곧 학습 비용 절감

정부 사이트마다 버튼·셀렉트·모달이 제각각이면, 사용자는 사이트를 옮길 때마다 "여기선 어떻게 하지?"를 다시 배워야 합니다. 모든 공공 서비스의 컴포넌트가 같은 모습·같은 동작이면, 한 번 익힌 사용법이 어디서나 통합니다. 디지털 약자에게 이 "다시 안 배워도 됨"은 생각보다 큰 배려예요. 컴포넌트 킷은 디자이너·개발자의 자유를 뺏는 게 아니라, 국민의 인지 부담을 덜어 주는 장치입니다.

접근성은 "나중에 붙이는 것"이 아니다

가장 비싼 실수가 이겁니다. "일단 기능부터 만들고 접근성은 나중에 붙이자." 접근성을 나중에 붙이려면 이미 만든 컴포넌트를 다 뜯어고쳐야 하는데, 그게 처음부터 넣는 것보다 몇 배 비쌉니다. 컴포넌트 킷은 접근성을 시작점에 둡니다. 마크업 단계에서 이미 role·aria-*가 들어가 있으니, "나중에 붙이는" 부채가 처음부터 없는 셈입니다. 이게 킷을 쓰는 가장 실용적인 이유 중 하나입니다.

개발 속도와 품질을 동시에

보통 "빠르게"와 "제대로"는 충돌합니다. 빨리 만들면 대충 되고, 제대로 만들면 느리죠. 컴포넌트 킷은 이 둘을 동시에 잡는 드문 수단입니다. 이미 만들어진 검증된 부품을 가져다 쓰니 빠르고, 그 부품이 표준을 지키니 품질도 확보됩니다. "직접 만들어서 어렵다"던 접근성의 절반이, 검증된 코드를 쓰는 순간 사라집니다. 남는 절반(우리 비즈니스 로직, 콘텐츠)에만 집중하면 되죠.

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

컴포넌트 킷을 둘러싼 실수들을 정리하겠습니다. 모두 익명화한 일반적 사례입니다(특정 기관을 지목하지 않습니다).

실수 1) CSS만 불러오고 JS는 안 챙김

가장 흔합니다. 디자인 담당이 "KRDS 스타일 적용해 주세요" 하면, 개발자가 krds.min.css만 <link>로 걸고 끝냅니다. 화면은 KRDS처럼 보입니다. 그런데 모달이 키보드로 안 닫히고, 탭이 방향키로 안 넘어가고, 아코디언이 스크린리더에서 펼침 상태를 안 알립니다. 동작이 죽은 껍데기가 된 거죠.

• 나쁜 예: krds.min.css만 로드. JS 미로드. 시각은 표준인데 키보드·스크린리더 동작은 전무.
• 올바른 예: krds.min.css와 krds.min.js를 함께 로드하고, 컴포넌트가 초기화되는지 확인. 동적으로 추가되는 컴포넌트는 추가 시점에 다시 초기화.

실수 2) 설치만 하고 컴포넌트는 옛날 코드 그대로

npm install krds-uiux까지는 했는데, 정작 화면의 버튼·셀렉트는 예전 프로젝트의 커스텀 컴포넌트를 그대로 씁니다. 킷은 node_modules에서 잠만 자고 있죠. 패키지 목록엔 KRDS가 있는데 실제 적용은 0%인 상황입니다.

• 나쁜 예: 킷 설치 후, 화면은 기존 커스텀 컴포넌트로 그대로 운영. "도입은 했다"는 착각.
• 올바른 예: 핵심 경로(신청·로그인·검색)의 컴포넌트부터 킷 마크업으로 교체. 점진적으로 커버리지를 넓힘.

실수 3) 토큰 무시하고 색·여백 하드코딩

킷의 컴포넌트를 가져다 쓰면서도, "이 버튼만 색이 좀 달랐으면" 하며 인라인 스타일이나 별도 CSS로 색·여백을 덮어씁니다. 한두 곳이면 모르겠는데, 이게 쌓이면 토큰 체계가 무너지고 컴포넌트마다 색이 미묘하게 달라집니다. 킷을 쓰는 의미가 사라지죠.

• 나쁜 예: style="background:#2b5cff"처럼 토큰 대신 직접 값을 박음. 사이트 곳곳에서 브랜드 색이 조금씩 다름.
• 올바른 예: 색·간격은 토큰(변수)으로만 참조. 정말 변형이 필요하면 토큰 자체를 조정하거나 정의된 변형(variant)을 사용.

실수 4) 부분 적용 — 버튼만 KRDS, 나머지는 제각각

버튼은 킷을 썼는데 셀렉트·모달·탭은 직접 만든 채로 둡니다. 사용자 입장에선 한 화면 안에서 어떤 건 표준이고 어떤 건 아닌, 일관성 없는 경험을 하게 됩니다. 그리고 직접 만든 컴포넌트들이 접근성을 흘리는 지점이 됩니다.

• 나쁜 예: 일부 컴포넌트만 킷 적용. 나머지는 레거시 커스텀. 사이트 내부에서 패턴이 충돌.
• 올바른 예: 컴포넌트 단위로 마이그레이션 로드맵을 세우고, 사용 빈도·위험도 순으로 전부 킷으로 수렴.

실수 5) 킷 마크업을 가져오면서 접근성 속성을 지움

킷의 HTML을 복사해 오긴 했는데, "안 쓰는 속성 같아서" 혹은 "코드가 지저분해서" aria-*·role을 임의로 떼어 냅니다. 그 속성들이 바로 접근성의 핵심인데, 모르고 지워 버리면 시각만 표준이고 의미는 사라진 컴포넌트가 됩니다.

• 나쁜 예: 킷 마크업에서 aria-expanded·aria-controls·role을 "정리"한다며 삭제.
• 올바른 예: 킷 마크업의 속성은 손대지 않음. 의미를 모르겠는 속성일수록 더 남겨 둘 것(대부분 접근성 장치).

실수 6) 버전 안 고정하고 최신만 무작정 당겨 씀

CDN에서 버전 지정 없이 "latest"를 물어다 쓰거나, npm 버전을 느슨하게 잡아 둡니다. 어느 날 킷이 업데이트되면서 클래스명이나 동작이 바뀌면, 우리 사이트가 예고 없이 깨집니다.

• 나쁜 예: 버전 미고정. 외부 업데이트가 우리 배포에 무단으로 끼어듦.
• 올바른 예: 명시적 버전 고정. 업그레이드는 변경 로그를 확인하고 테스트 후 의도적으로 진행.

실수 7) 동적 콘텐츠에 컴포넌트 재초기화 누락

목록을 비동기로 불러와 화면에 끼워 넣을 때, 거기 들어간 킷 컴포넌트(예: 새로 그려진 탭·아코디언)에 JS 초기화를 다시 안 해 줍니다. 처음 로드된 컴포넌트는 멀쩡한데, 나중에 추가된 건 동작이 안 되죠. 디버깅하기 까다로운 유형입니다.

• 나쁜 예: 초기 1회만 초기화. 이후 추가된 컴포넌트는 클릭·키보드 동작 무반응.
• 올바른 예: 동적 추가 시점에 해당 영역을 다시 초기화하거나, 이벤트 위임으로 새 요소도 동작하도록 설계.

실수 8) "보기엔 KRDS인데" 표준을 우회한 가짜 컴포넌트

가장 교묘한 실수입니다. 킷은 안 쓰면서, 킷처럼 보이게 색·모양만 흉내 낸 커스텀 컴포넌트를 만듭니다. 겉보기엔 KRDS인데 속은 비표준이라, 코드 검사로도 잘 안 잡히고 시각 검사로도 통과해 버립니다.

• 나쁜 예: 킷 미사용. 시각만 KRDS 흉내. 키보드·스크린리더에선 비표준 컴포넌트의 모든 문제를 그대로 안음.
• 올바른 예: 흉내 내지 말고 실물 킷을 사용. 굳이 커스텀이 필요하면 접근성 요건을 전부 직접 충족하고, 그게 됐는지 자동 검사로 확인.

직접 적용하기 — 역할별 가이드

컴포넌트 킷은 한 사람의 일이 아니라 팀 전체의 합작입니다. 역할별로 챙길 포인트를 정리합니다.

개발자라면 — 가장 먼저 할 일은 "어떤 방식으로 붙일지" 정하는 겁니다. 빠른 검증·소규모면 CDN, 본 프로젝트·장기 유지보수면 npm. 그다음 CSS와 JS를 둘 다 챙기고, 토큰을 글로벌에 연동합니다. 컴포넌트는 직접 만들지 말고 html/code의 마크업을 그대로 가져오되, aria-*·role 속성은 절대 손대지 않습니다. 동적으로 추가되는 컴포넌트는 재초기화를 잊지 마세요. 마지막으로 버전을 고정하고, 업그레이드는 변경 로그를 보고 의도적으로 진행합니다. "직접 만들고 싶은" 유혹이 들 때마다, 그 컴포넌트의 키보드·스크린리더 동작을 전부 직접 구현하고 테스트할 자신이 있는지 자문하세요. 대부분의 경우 답은 "킷을 쓰자"입니다.

디자이너라면 — KRDS 공식 Figma(@krds) 라이브러리에서 컴포넌트와 토큰을 가져다 시안을 그립니다. 직접 그리지 말고 표준 컴포넌트를 배치하면, 디자인 단계에서부터 색·간격·상태가 기준에 맞춰집니다. 무엇보다 개발자가 쓸 컴포넌트와 같은 부품으로 시안을 만드는 것이 핵심입니다. 그래야 시안과 구현 사이의 간극이 사라집니다. 변형이 필요하면 임의로 색을 바꾸지 말고, 정의된 토큰·variant 안에서 해결하세요.

기획자라면 — 화면 정의서에 "버튼", "드롭다운"이라고만 적지 말고, "KRDS 컴포넌트 킷 적용(버튼 primary, 셀렉트 단일·필수)"처럼 표준 사용을 전제로 명시하세요. 신규 컴포넌트가 정말 필요한 경우에만 별도 표기하고, 그 경우 접근성 요건을 함께 적습니다. 이 한 줄이 "직접 만들어 빠뜨리는" 사고를 막습니다. 또 마이그레이션 프로젝트라면, 핵심 경로(신청·로그인·검색)부터 킷으로 전환하는 우선순위를 일정에 반영하세요.

QA·운영 담당이라면 — "킷을 설치했다"로 끝내지 말고 "실제로 적용됐는지"를 검수 항목에 넣으세요. CSS만 로드되고 JS가 빠지지 않았는지, 부분 적용으로 비표준 컴포넌트가 남아 있지 않은지, 동적 콘텐츠의 컴포넌트가 동작하는지. 이걸 사람이 매번 손으로 보기는 어려우니, 자동 점검 도구를 정기 검수에 끼워 넣는 게 현실적입니다.

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

여기까지가 컴포넌트 킷을 붙이는 법이었습니다. 그런데 정작 어려운 건 "그래서 우리 사이트, 킷이 제대로 적용된 거 맞나?"를 확인하는 일입니다. 페이지마다 어떤 컴포넌트가 쓰였는지, 그게 표준 마크업인지 흉내만 낸 커스텀인지, 접근성 속성이 살아 있는지, JS 동작이 붙어 있는지를 사람이 일일이 손으로 점검하려면 끝이 없습니다. 페이지가 수십·수백 개인 공공 사이트라면 더더욱요.

ViewCheck(krds.viewcheck.co.kr)는 이 점검을 자동화합니다. URL만 넣으면 페이지를 실제로 크롤링해서, 컴포넌트들이 KRDS 기준을 지키는지 판정합니다. 컴포넌트는 KRDS 846규칙 중 컴포넌트(CP) 규칙군 446개에 속하고, 분석 결과의 컴포넌트(Components) 탭에서 확인할 수 있습니다. 446개라는 숫자가 말해 주듯, 컴포넌트 영역은 KRDS에서 가장 비중이 큰 부분입니다. 그만큼 자동 점검의 가치가 크죠.

ViewCheck가 컴포넌트에 대해 자동으로 보는 것들:

• 컴포넌트 존재·식별: 페이지에 어떤 컴포넌트(버튼·입력·셀렉트·체크박스·탭·모달·아코디언·페이지네이션 등)가 있는지 감지하고, 그게 표준 마크업인지 비표준 커스텀인지 판별
• 접근성 속성 충족: 각 컴포넌트가 요구되는 role·aria-*·라벨 연결 등을 갖췄는지(킷을 제대로 가져왔다면 충족, 속성을 지웠다면 미통과)
• 상태·동작 표현: 펼침/접힘, 오류, 비활성 같은 상태가 코드로 표현돼 있는지
• 일관성·부분 적용: 같은 종류의 컴포넌트가 페이지마다 표준/비표준이 섞여 있지 않은지(부분 적용 탐지)

여기서 ViewCheck의 강점이 하나 있습니다. DOM(코드)만으로 판단하기 어려운 시각적 부분은 KRDScan Vision AI가 스크린샷을 보고 보강 판정합니다. 그래서 "코드엔 표준 컴포넌트가 안 보이는데 화면엔 분명히 버튼·드롭다운이 있는" 비표준 구현, 즉 앞서 말한 "킷처럼 보이게 흉내만 낸 가짜 컴포넌트"도 놓치지 않습니다. 사람이 눈으로 보듯 화면을 함께 보기 때문에, 표준을 우회해 만든 UI까지 잡아내는 거죠. 단순 코드 검사 도구와 결정적으로 다른 부분입니다.

리포트를 어떻게 읽나

분석이 끝나면 컴포넌트 탭에서 CP 규칙의 통과/미통과 수와, 미통과한 항목의 위치(어느 페이지)·이유·개선 방법(howToFix)이 함께 나옵니다. 예를 들어 "신청 페이지의 셀렉트 2개가 접근성 속성 누락(킷 미적용 의심)"처럼 구체적으로요. 여러 페이지를 한꺼번에 분석하면, "메인은 킷이 잘 적용됐는데 신청 페이지는 레거시 커스텀이 남아 있다" 같은 부분 적용도 한눈에 드러납니다. 컴포넌트 킷 도입의 가장 흔한 실패가 부분 적용인데, 그걸 페이지별로 짚어 주니 "어디부터 마저 적용해야 하는지"가 명확해집니다.

또 디자인 시스템(Design System) 탭의 디자인 토큰 채택률 리포트를 함께 보면, 토큰을 무시하고 색·여백을 하드코딩한 곳이 얼마나 되는지도 파악됩니다. "컴포넌트는 킷인데 색은 제각각"인 실수 3번을 잡아내는 데 유용합니다.

무료 진단으로 우리 사이트 메인부터 한 번 돌려 보면, 손으로는 몇 시간 걸릴 "킷 적용 현황 점검"이 몇 분 만에 끝납니다. 그리고 그 결과는 막연한 "킷 잘 쓰자"가 아니라, "이 페이지의 이 컴포넌트를 킷으로 교체하자"는 구체적인 작업 목록이 됩니다.

자주 묻는 질문

현장에서 컴포넌트 킷을 도입할 때 반복해서 나오는 질문들을 모았습니다.

Q. CDN과 npm 중 뭘 써야 하나요?

간단한 기준은 "빌드 도구가 있느냐"와 "얼마나 오래 유지보수하느냐"입니다. 빌드 파이프라인이 없거나, 기존 사이트에 빠르게 얹어 보고 싶거나, 일단 어떻게 생겼는지 확인하려면 CDN이 빠릅니다. 반대로 Vite·webpack 같은 번들러를 쓰고, 협업 규모가 크고, 장기 유지보수할 사이트라면 npm이 정석입니다. npm은 버전을 package.json에 고정하니 누가 받아도 같은 킷을 쓰고, 안 쓰는 스타일 정리나 SCSS 커스터마이즈도 수월합니다. 본 프로젝트라면 거의 항상 npm을 권합니다.

Q. 기존에 우리 디자인 시스템이 있는데, KRDS 킷으로 다 바꿔야 하나요?

한 번에 다 갈아엎을 필요는 없습니다. 현실적인 전략은 "핵심 경로부터 점진적 전환"입니다. 신청·로그인·검색처럼 사용 빈도가 높고 접근성이 중요한 화면의 컴포넌트부터 킷으로 교체하고, 나머지는 일정에 맞춰 차례로 옮기세요. 먼저 ViewCheck로 현황을 찍어 "지금 어떤 컴포넌트가, 어느 페이지에서, 무슨 문제를 일으키는지"를 목록화한 다음, 위험도·사용 빈도 순으로 마이그레이션하는 게 효율적입니다.

Q. CSS만 불러오면 안 되나요? JS까지 꼭 챙겨야 하나요?

시각만 맞추는 게 목적이면 CSS만으로도 "보이긴" 합니다. 하지만 모달 닫기, 탭 전환, 아코디언 펼치기, 드롭다운 키보드 조작 같은 동작은 JS가 담당합니다. CSS만 불러오면 화면은 KRDS인데 키보드로는 못 쓰는 "껍데기"가 됩니다. 컴포넌트 킷을 쓰는 이유의 절반이 접근성인데, JS를 빼면 그 절반이 날아갑니다. CSS와 JS는 한 세트로 챙기세요.

Q. 프레임워크(React/Vue)에서 킷을 쓰면 충돌하지 않나요?

킷의 JS 동작과 프레임워크의 상태 관리가 같은 것을 두 번 제어하면 충돌할 수 있습니다. 예를 들어 모달의 열림/닫힘을 킷 JS와 프레임워크 state 양쪽이 관리하면 따로 놀죠. 해결책은 "제어는 한쪽으로 통일"입니다. 보통 시각·구조·접근성 속성(role·aria-*)은 킷 마크업에서 가져오고, 열고 닫는 제어는 프레임워크 한쪽에 맡깁니다. 어느 쪽으로 통일하든 aria-* 속성이 상태 변화에 맞춰 갱신되는지만 확인하면 됩니다.

Q. 킷 마크업이 너무 복잡한데, 안 쓰는 속성은 지워도 되나요?

지우지 마세요. 킷 마크업의 role·aria-expanded·aria-controls·aria-describedby 같은 속성은 "지저분한 코드"가 아니라 접근성의 핵심 장치입니다. 눈에 안 보인다고 없어도 되는 게 아니라, 눈에 안 보이는 사용자(스크린리더)에게 꼭 필요한 정보예요. 의미를 모르겠는 속성일수록 더 남겨 두는 게 안전합니다. 정 정리하고 싶으면, 그 속성이 무슨 역할인지 확인한 다음에 판단하세요. 대부분은 "남겨야 한다"가 답입니다.

Q. 킷을 적용했는데 ViewCheck 점수가 안 오릅니다. 왜죠?

대개 "설치는 했는데 적용이 안 된" 경우입니다. 흔한 원인 네 가지를 확인해 보세요. ① CSS만 불러오고 JS를 안 불렀다(동작 미작동), ② 킷을 설치만 하고 컴포넌트는 예전 커스텀 코드를 그대로 쓴다, ③ 토큰을 무시하고 색·여백을 하드코딩했다, ④ 일부 컴포넌트만 킷이고 나머지는 비표준이다(부분 적용). ViewCheck의 컴포넌트 탭은 어느 페이지의 어떤 컴포넌트가 미통과인지 짚어 주니, 그걸 보면 "설치와 적용 사이의 강"이 어디서 막혔는지 정확히 알 수 있습니다.

Q. 버전을 올렸더니 화면이 깨졌어요.

버전을 고정하지 않았거나, 변경 로그 확인 없이 업그레이드했을 가능성이 큽니다. 컴포넌트 킷도 소프트웨어라 버전 간 클래스명·동작이 바뀔 수 있습니다. 업그레이드는 "무작정 최신"이 아니라, 변경 로그를 읽고 테스트 환경에서 먼저 확인한 뒤 의도적으로 진행하세요. CDN을 쓴다면 버전을 명시적으로 박아 두는 것도 방법입니다. 그리고 업그레이드 후엔 ViewCheck로 회귀가 없는지 한 번 돌려 보면 안전합니다.

Q. 외주로 사이트를 발주하는데, 킷 적용을 어떻게 요구하면 되나요?

발주처(기관) 입장에서 가장 확실한 방법은 제안요청서(RFP)와 검수 기준에 "KRDS 컴포넌트 킷 적용"을 명시하는 것입니다. "KRDS 디자인을 따른다" 같은 모호한 표현이 아니라, "KRDS 컴포넌트 킷(krds-uiux)을 실제로 적용하고, 컴포넌트 영역(CP) 준수율을 일정 수준 이상 충족한다"처럼 구체적이고 검증 가능한 조건으로요. 그리고 검수 단계에서 ViewCheck 같은 자동 진단으로 객관적으로 확인하면, "킷처럼 보이게만 만든" 흉내 구현을 걸러낼 수 있습니다. 말로만 "KRDS 적용했습니다"를 받지 말고, 숫자로 받는 게 핵심입니다.

Q. 킷에 없는 컴포넌트가 필요하면 어떻게 하나요?

공공 서비스의 대부분 화면은 킷이 제공하는 표준 컴포넌트로 충분히 구성됩니다. 그래도 킷에 없는 특수 컴포넌트가 정말 필요하다면, "직접 만들되 킷의 원칙을 따르는" 게 정답입니다. 즉 킷의 토큰을 그대로 참조하고, 키보드 조작·aria-*·포커스 표시 같은 접근성 요건을 빠짐없이 충족하고, 가능하면 킷의 기존 컴포넌트 구조를 본떠 만드세요. 그리고 새로 만든 만큼 자동 점검으로 접근성을 반드시 검증해야 합니다. "킷에 없으니 대충 만들어도 된다"가 아니라, "킷에 없을수록 더 꼼꼼히 표준을 지킨다"가 맞습니다.

Q. 디자인팀과 개발팀이 서로 "그건 너희 일"이라고 합니다.

컴포넌트 킷 적용은 어느 한 팀의 책임이 아니라 합작입니다. 디자이너는 같은 토큰·컴포넌트로 시안을 만들고, 개발자는 그 컴포넌트를 표준 코드로 구현하고, 기획자는 표준 사용을 화면 정의서에 전제로 깔아야 합니다. 그래서 KRDS가 디자인(Figma)·코드(GitHub 킷)·문서(가이드라인)를 한 세트로 제공하는 겁니다. 세 팀이 같은 부품을 보고 일하면 "네 일/내 일" 논쟁 자체가 줄어듭니다.

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

ViewCheck로 돌려 보면 보통 컴포넌트 관련 문제가 한두 개로 끝나지 않습니다. 특히 컴포넌트 영역(CP 446규칙)은 비중이 커서 "고칠 게 많다"는 압박감이 들기 쉽습니다. 그래서 우선순위가 중요합니다. 컴포넌트 킷 적용 문제를 심각도 순으로 정리하면 대략 이렇습니다.

가장 먼저(치명적) — 키보드로 아예 작동하지 않거나 스크린리더가 인식하지 못하는 컴포넌트. 직접 만든 가짜 셀렉트·모달·드롭다운이 여기 해당합니다. 특정 사용자에게 기능을 완전히 차단하는 문제라 1순위입니다. 신청·로그인·검색처럼 핵심 경로에 있다면 더더욱 먼저 손봐야 합니다. 이런 건 대개 킷의 표준 컴포넌트로 교체하는 것이 가장 빠른 해결책입니다.

그다음(높음) — CSS만 로드되고 JS가 빠져 동작이 죽은 컴포넌트, 그리고 킷 마크업에서 접근성 속성이 지워진 컴포넌트. 시각은 표준인데 실제로는 못 쓰는 상태라, 작동하는 척하는 만큼 더 위험합니다. JS를 마저 불러오거나 속성을 복원하면 비교적 적은 노력으로 큰 개선이 됩니다.

그 후(보통) — 부분 적용(일부만 킷, 나머지는 비표준)과 토큰 하드코딩. 사용은 가능하지만 일관성이 깨지고 유지보수 부담이 쌓입니다. 컴포넌트 단위로 마이그레이션 로드맵을 세워 차례로 수렴시키세요.

여력이 되면(낮음) — 버전 고정·업그레이드 체계 정비, 동적 콘텐츠 재초기화 정리 같은 운영 안정성 개선. 당장 사용자를 막는 건 아니지만, 장기적으로 사이트를 튼튼하게 만드는 항목입니다.

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

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

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

• KRDS 컴포넌트 킷(GitHub `KRDS-uiux/krds-uiux`) — 컴포넌트 HTML 코드(html/code), CSS/SCSS, JS, 토큰, 아이콘, 서체. npm install krds-uiux 또는 CDN(krds.min.css / krds.min.js)으로 사용. 실제 도입의 1차 자산입니다.
• KRDS 가이드라인 PDF(디지털 정부서비스 UI/UX 가이드라인, 2025.08판) — 컴포넌트별 정의와 사용 원칙의 1차 원천. "왜 그렇게 만드는가"를 이해하는 데 필수.
• KRDS 공식 Figma(@krds) — 디자이너용 컴포넌트와 토큰 라이브러리. 시안을 표준 부품으로 그릴 때 사용.
• KRDS 컴포넌트 문서(웹) — 각 컴포넌트의 변형·예시를 화면으로 확인.

공식 자료는 "정답지이자 부품 창고"이고, ViewCheck는 "내가 그 부품을 제대로 끼웠는지 채점해 주는 도구"라고 생각하시면 됩니다. 둘을 함께 쓰면, 기준을 이해하고(가이드라인) → 검증된 부품을 가져와 붙이고(컴포넌트 킷) → 제대로 붙었는지 확인하는(ViewCheck) 한 바퀴가 완성됩니다.

오늘의 체크리스트 — 컴포넌트 킷, 이것만은

마지막으로, 개발자·디자이너·기획자가 컴포넌트 킷을 도입하거나 검수할 때 바로 쓸 수 있는 체크리스트로 정리합니다.

• ☐ 설치 방식을 상황에 맞게 골랐다(빠른 검증·소규모면 CDN, 본 프로젝트·장기 유지보수면 npm).
• ☐ krds.min.css와 krds.min.js를 둘 다 불러왔다(CSS만 불러 동작을 죽이지 않았다).
• ☐ 컴포넌트는 직접 만들지 않고 킷의 표준 마크업(html/code)을 그대로 가져왔다.
• ☐ 킷 마크업의 role·aria-* 속성을 임의로 지우지 않았다.
• ☐ 색·간격은 토큰(변수)으로 참조했다(하드코딩으로 덮어쓰지 않았다).
• ☐ 일부만이 아니라 모든 동종 컴포넌트를 킷으로 통일했다(부분 적용을 남기지 않았다).
• ☐ 동적으로 추가되는 컴포넌트에 JS 초기화를 다시 적용했다.
• ☐ 프레임워크를 쓴다면 킷 JS와 상태 관리의 제어를 한쪽으로 통일했다(aria-* 갱신 확인).
• ☐ 킷 버전을 고정하고, 업그레이드는 변경 로그 확인 후 의도적으로 진행한다.
• ☐ "설치"가 아니라 "적용"이 됐는지 ViewCheck 컴포넌트 탭으로 확인했다.

KRDS 컴포넌트 킷(npm install krds-uiux 또는 CDN)을 제대로 쓰면 위 항목 대부분이 자연스럽게 충족됩니다. 직접 만들다 빠뜨릴 위험을 줄이는 가장 확실한 방법이죠. 공식 Figma 라이브러리(@krds)에서는 디자이너가 같은 컴포넌트·토큰을 그대로 가져다 시안을 그릴 수 있어, 디자인과 구현의 간극도 좁힙니다.

컴포넌트 킷은 거창한 기술이 아닙니다. "이미 잘 만들어진 부품을 가져다 쓰자"는, 어찌 보면 당연한 선택이에요. 그런데 이 당연한 선택 하나가 한 달의 중복 개발을 없애고, 접근성 부채를 시작점에서 차단하고, 사이트 전체의 일관성을 만듭니다. 그리고 그게 잘 됐는지는 ViewCheck로 몇 분이면 확인할 수 있습니다. 완벽하게 한 번에 갈아엎을 필요는 없습니다. 가장 많이 쓰이는 컴포넌트 하나부터 킷으로 바꿔 나가면, 우리 사이트는 분명히 조금씩 더 많은 사람에게 열립니다. 다음 글에서는 이 킷을 구성하는 또 다른 핵심 자산을 같은 방식으로 뜯어보겠습니다.

우리 사이트는 KRDS 컴포넌트 킷이 "설치"만 됐을까요, "적용"까지 됐을까요? krds.viewcheck.co.kr에서 URL만 넣으면 무료로 확인할 수 있습니다. 메인 페이지 하나만 돌려 봐도, 위 체크리스트가 실제로 지켜지고 있는지 컴포넌트 탭에서 바로 보입니다.

#KRDS #공공웹 #디자인시스템 #컴포넌트킷개발적용 #웹접근성 #ViewCheck #정부웹사이트 #UIUX #프론트엔드 #npm #디자인토큰 #퍼블리싱 #자가진단 #체크리스트 #점검항목 #UI컴포넌트 #컴포넌트설계 #전자정부 #디지털정부 #행정안전부