KRDS 공식 Figma 라이브러리 200% 활용법 (디자이너)

디자이너 한 명이 새 공공 프로젝트에 투입되는 첫날을 떠올려 봅니다. 보통 무슨 일부터 할까요. 십중팔구 빈 Figma 파일을 하나 열고, 사각형을 그리기 시작합니다. 버튼 하나를 그리고, 모서리를 둥글리고, 색을 입히고, "이 정도면 괜찮네" 하고 다음 화면으로 넘어갑니다. 이 장면이 너무 익숙해서 우리는 이게 정상이라고 생각합니다. 그런데 잠깐, 그 버튼 — 옆자리 동료가 다른 화면에서 그린 버튼과 모서리 반지름이 같을까요? 높이는요? 호버 색은요? 비활성 상태는 누가 그렸죠?

공공 사이트를 수백 개 분석하다 보면, 화면 안에서 "같은 버튼"이 서너 가지 버전으로 존재하는 경우를 정말 자주 봅니다. 메인의 버튼과 신청 페이지의 버튼이 미묘하게 다르고, 같은 페이지 안에서도 위쪽 버튼과 아래쪽 버튼의 높이가 2px씩 어긋나 있죠. 사용자는 의식적으로 알아채지 못하지만, 무의식은 "뭔가 정돈이 안 됐다"는 인상을 받습니다. 이 모든 어긋남의 뿌리를 거슬러 올라가면, 대개 한 가지 원인에 닿습니다 — 각자 알아서 그렸다는 것.

KRDS(대한민국 정부 디자인 시스템)는 바로 이 "각자 알아서"를 끝내기 위해 공식 Figma 라이브러리를 제공합니다. 디자이너가 버튼을, 입력창을, 셀렉트를, 카드를 처음부터 다시 그릴 필요 없이, 이미 표준에 맞춰 만들어진 컴포넌트를 가져다 놓기만 하면 되는 자산입니다. 그런데 현장에서 보면, 이 라이브러리의 존재 자체를 모르거나, 알아도 "그냥 참고용이지" 하고 넘기는 팀이 많습니다. 그 결과가 위에서 말한 어긋난 버튼들입니다.

이 글에서는 KRDS 공식 Figma 라이브러리가 정확히 무엇이고, 왜 디자이너가 이걸 "200% 활용"해야 하는지, 그리고 — 이 시리즈의 다른 글과 달리 이번 글의 핵심은 여기인데 — 내가 정말 이 라이브러리를 제대로 쓰고 있는지 5분 만에 자가진단하는 방법까지 다루겠습니다. 추상적인 "쓰면 좋아요"가 아니라, 손에 쥐고 따라 할 수 있는 체크리스트 중심으로요. 다 읽고 나면, 오늘 당장 자기 Figma 파일을 열어 "아, 나 여기서 새고 있었구나"를 발견하시게 될 겁니다.

공식 Figma 라이브러리가 대체 뭔가 — 정의부터

먼저 용어를 정확히 맞추겠습니다. "KRDS Figma"라고 하면 사람마다 떠올리는 게 조금씩 다릅니다. 어떤 사람은 "정부에서 만든 예시 디자인"으로, 어떤 사람은 "참고용 시안 모음"으로 오해합니다. 둘 다 정확하지 않습니다.

KRDS 공식 Figma 라이브러리는 재사용 가능한 디자인 컴포넌트의 라이브러리(library)입니다. Figma에서 "라이브러리"라는 단어는 특별한 의미를 갖습니다. 단순한 그림 파일이 아니라, 여러 프로젝트에서 공유해서 가져다 쓰고, 원본이 업데이트되면 가져다 쓴 곳도 함께 갱신되는 — 살아 있는 부품 창고에 가깝습니다.

KRDS Figma 라이브러리에는 크게 세 종류의 자산이 들어 있습니다.

• 컴포넌트(Components): 버튼, 입력창, 셀렉트, 체크박스, 라디오, 탭, 아코디언, 모달, 카드, 페이지네이션 같은 UI 부품. 각각 상태(기본/호버/포커스/비활성/오류)와 변형(크기·종류)을 갖춘 형태로 제공됩니다.
• 디자인 토큰/스타일(Styles): 색상, 타이포그래피, 간격, 그림자 같은 시각 속성의 표준값. Figma의 색상 스타일·텍스트 스타일·변수(variable)로 등록되어 있어, 컴포넌트들이 이 값들을 공유합니다.
• 파운데이션/가이드: 그리드, 레이아웃, 아이콘 같은 기초 요소와 사용 규칙.

여기서 핵심은, 이 세 가지가 서로 연결되어 있다는 점입니다. 라이브러리의 버튼 컴포넌트는 라이브러리의 색상 토큰을 참조하고, 그 색상 토큰은 가이드라인 문서의 정의를 따릅니다. 그래서 디자이너가 컴포넌트 하나를 가져다 쓰는 순간, 그 뒤에 묶여 있는 모든 표준이 자동으로 따라옵니다. 이게 "각자 그리기"와 결정적으로 다른 부분입니다.

"참고"가 아니라 "부품"이라는 발상의 전환

가장 자주 보는 오해가 이겁니다. "KRDS Figma를 열어서 어떻게 생겼나 보고, 내 파일엔 비슷하게 그린다." 이건 라이브러리를 참고 자료로만 쓰는 방식입니다. 문제는, 사람 눈으로 보고 따라 그리면 반드시 어긋난다는 것. 모서리 반지름을 8px로 봤는데 7px로 그리고, 높이를 48px로 봤는데 46px로 그리고, 색을 거의 같지만 미묘하게 다른 파랑으로 칠합니다. "거의 같으면 됐지" 싶지만, 그 "거의"들이 화면 전체에 쌓이면 결국 표준에서 멀어집니다.

올바른 방식은 라이브러리를 연결(enable)해서 컴포넌트 인스턴스를 직접 가져다 놓는 것입니다. 그러면 베끼는 게 아니라 진짜 부품을 쓰는 거라, 수치가 어긋날 여지가 없습니다. 더 중요한 건, 원본 라이브러리가 업데이트되면 — 예를 들어 표준 버튼의 디자인이 개정되면 — 내 파일의 버튼들도 갱신 알림을 받는다는 점입니다. "참고"는 한 번 보고 끝이지만, "연결"은 계속 이어집니다.

이 발상의 전환 하나가 이 글 전체의 출발점입니다. KRDS Figma는 보는 게 아니라 쓰는 것. 따라 그리는 게 아니라 가져다 놓는 것. 이걸 받아들이고 나면, 뒤에 나올 자가진단 항목들이 전부 "내가 보고만 있나, 진짜 쓰고 있나"를 가르는 질문이라는 게 보이실 겁니다.

라이브러리 처음 연결하기 — 막막하지 않게

"연결해서 쓰라"는 말이 추상적으로 들릴 수 있어, 실제 흐름을 짚어 두겠습니다. Figma에서 외부 라이브러리를 쓰는 절차는 생각보다 단순합니다. 대략 이런 순서입니다.

첫째, KRDS 공식 Figma(@krds) 자산을 자기 작업 공간(또는 팀)에서 접근할 수 있게 합니다. 둘째, 디자인 파일에서 자산(Assets) 패널을 열고 라이브러리 관리(라이브러리 토글)에서 KRDS 라이브러리를 켭니다(enable). 셋째, 그러면 자산 패널에 KRDS 컴포넌트들이 목록으로 나타납니다. 넷째, 필요한 컴포넌트(예: 1차 버튼)를 캔버스로 드래그하면, 그게 바로 라이브러리에 연결된 인스턴스가 됩니다.

여기까지가 한 번만 하면 되는 초기 설정입니다. 그 뒤로는 새 화면을 만들 때마다 자산 패널에서 부품을 꺼내 쓰면 됩니다. 처음 한 번의 연결이 번거로워 보여도, 그 이후 매 화면에서 절약되는 시간을 생각하면 압도적인 이득입니다. "한 번 설정, 평생 활용"이라고 생각하시면 됩니다. 그리고 이 초기 설정을 안 했기 때문에 — 즉 라이브러리를 켜 본 적이 없어서 — 많은 디자이너가 여전히 빈 사각형부터 그리고 있습니다. 진입 장벽은 사실 5분짜리인데, 그 5분을 안 넘어서 평생 손해를 보는 셈이죠.

KRDS는 Figma 라이브러리로 무엇을 요구하나 — 기준 해부

KRDS가 공식 Figma 라이브러리를 제공하는 데에는 분명한 의도가 있습니다. "예쁜 시안을 보여 주려고"가 아니라, 디자인 단계에서부터 표준을 강제하려고입니다. 이걸 영역별로 뜯어보겠습니다. 기준이 무엇인지 알아야, 내가 그 기준을 지키는지 점검할 수 있으니까요.

1) 컴포넌트는 처음부터 끝까지 정의되어 있어야 한다

KRDS Figma의 컴포넌트는 "평상시 모습 하나"로 끝나지 않습니다. 각 컴포넌트가 가질 수 있는 상태와 변형이 모두 포함되어 있습니다. 버튼이라면 1차 버튼·2차 버튼·텍스트 버튼 같은 종류, 그리고 각각의 기본·호버·포커스·비활성·로딩 상태까지요. 셀렉트라면 기본·크기·정렬·상태 변형(앞선 셀렉트 편에서 본 그대로)이 들어 있습니다.

이게 왜 기준이냐면, 디자이너가 직접 그릴 때 가장 많이 빠뜨리는 게 바로 이 "평상시가 아닌 상태들"이기 때문입니다. 기본 버튼은 다들 그립니다. 그런데 호버하면 어떻게 변하는지, 비활성이면 어떻게 보이는지, 키보드 포커스가 오면 어떤 외곽선이 생기는지 — 이건 시안에서 자주 누락됩니다. 누락된 채로 개발에 넘어가면, 개발자가 "알아서" 만들고, 그 "알아서"가 표준에서 벗어납니다. KRDS Figma는 이 상태들을 미리 다 정의해 둠으로써, 디자이너가 빠뜨릴 수 없게 만듭니다.

2) 모든 시각 속성은 토큰/스타일을 참조해야 한다

KRDS Figma의 컴포넌트는 색을 직접 칠하지 않습니다. 대신 등록된 색상 스타일·변수(토큰)를 참조합니다. 버튼의 배경색은 "어떤 파랑"이 아니라 "기본 강조색 토큰"이고, 글자색은 "흰색"이 아니라 "강조 위 텍스트 토큰"입니다. 간격도, 모서리 반지름도, 그림자도 마찬가지로 정해진 값을 참조합니다.

이게 기준인 이유는 두 가지입니다. 첫째, 일관성. 모든 컴포넌트가 같은 토큰을 보면, 화면 전체의 색·간격이 저절로 통일됩니다. 둘째, 유지보수. 나중에 표준 강조색이 바뀌면 토큰 하나만 고쳐도 그 토큰을 참조하는 모든 컴포넌트가 한꺼번에 바뀝니다. 직접 칠한 색은 이게 안 됩니다 — 일일이 찾아 다 바꿔야 하죠. KRDS가 토큰 기반 라이브러리를 제공하는 건, 디자인의 일관성과 유지보수성을 디자인 도구 안에서부터 보장하려는 겁니다.

3) 디자인과 코드가 1:1로 대응해야 한다

KRDS의 진짜 강점은, Figma 라이브러리만 주는 게 아니라 같은 컴포넌트의 HTML/CSS 코드를 GitHub 킷으로 함께 제공한다는 점입니다(KRDS-uiux/krds-uiux 저장소). 즉 Figma의 버튼 컴포넌트와 코드의 버튼 컴포넌트가 같은 표준을 공유합니다. 디자이너가 Figma에서 표준 버튼을 배치하면, 개발자는 GitHub 킷의 버튼 코드를 가져다 구현하면 됩니다. 둘이 같은 부모(가이드라인)에서 나왔으니, 시안과 구현 사이의 간극이 자연히 줄어듭니다.

이건 기준이라기보다 라이브러리의 설계 철학에 가깝지만, 점검 관점에서는 매우 중요합니다. "디자인은 표준대로 했는데 개발에서 달라졌다"는 흔한 사고를, 디자인·코드 양쪽이 같은 SSOT(단일 진실 공급원)를 보게 함으로써 막는 구조거든요. 디자이너가 임의 컴포넌트를 그리면 이 1:1 대응이 깨지고, 개발자는 다시 "알아서" 구현하게 됩니다.

4) 접근성 요건이 컴포넌트에 내장되어 있어야 한다

KRDS Figma 컴포넌트는 단순히 모양만 표준인 게 아닙니다. 포커스 상태, 충분한 색 대비, 적절한 터치 크기 같은 접근성 요건이 시각적으로 반영되어 있습니다. 예를 들어 버튼의 포커스 상태에는 또렷한 외곽선이 들어 있고, 텍스트와 배경의 색 대비는 기준을 충족하도록 토큰이 설계되어 있습니다. 디자이너가 이 컴포넌트를 그대로 쓰면, 접근성을 따로 신경 쓰지 않아도 기본선은 지켜집니다.

반대로 말하면, 디자이너가 표준 컴포넌트를 무시하고 직접 그릴 때 가장 위험한 게 바로 이 접근성입니다. 보기에 예쁜 회색 글자가 사실은 대비 기준에 한참 못 미치거나, 멋들어진 버튼에 포커스 상태가 아예 없거나 하는 일이 생깁니다. "디자인이 접근성을 망치는" 전형적 경로죠. KRDS Figma는 이 위험을 컴포넌트 안에 접근성을 미리 녹여 둠으로써 줄입니다.

왜 이렇게까지 라이브러리를 챙겨야 하나 — 원리와 배경

여기까지 읽고 "그냥 잘 그리면 되는 거 아닌가" 싶으실 수 있습니다. 디자인 라이브러리를 왜 이렇게까지 강조하는지, 그 원리를 짚어 보겠습니다. 이 부분을 이해하면 뒤의 자가진단이 훨씬 절실하게 다가올 겁니다.

디자인 단계의 어긋남은 끝까지 따라간다

소프트웨어 품질에는 오래된 격언이 있습니다. "문제는 늦게 발견될수록 고치는 비용이 기하급수적으로 커진다." 디자인 단계에서 버튼 하나가 표준에서 어긋나면, 그건 디자인에서 끝나지 않습니다. 개발자가 그 어긋난 시안을 보고 그대로 구현하고, QA는 시안과 일치하니 통과시키고, 배포된 뒤에야 "어, 이 버튼만 모양이 다르네"가 발견됩니다. 그때 고치려면 디자인·개발·검수를 다시 한 바퀴 돌아야 합니다.

KRDS Figma 라이브러리를 제대로 쓴다는 건, 이 어긋남을 가장 싼 시점에 막는다는 뜻입니다. 디자인 단계에서 표준 컴포넌트를 가져다 놓으면, 애초에 어긋날 수가 없습니다. 어긋남을 나중에 잡는 게 아니라, 처음부터 발생시키지 않는 거죠. 이게 라이브러리의 경제학입니다. "그릴 시간 아끼려고"가 아니라 "나중에 고칠 비용을 없애려고" 쓰는 겁니다.

사람은 일관성을 못 지킨다 — 도구가 지켜야 한다

솔직해집시다. 아무리 꼼꼼한 디자이너도, 100개 화면에 걸쳐 버튼 높이를 정확히 48px로 유지하는 건 불가능에 가깝습니다. 어딘가에서 46px이 끼고, 어딘가에서 50px이 끼죠. 사람의 집중력과 기억력에는 한계가 있고, 마감에 쫓기면 더 그렇습니다. 여러 디자이너가 한 프로젝트를 나눠 작업하면 어긋남은 배가됩니다.

그래서 일관성은 사람의 의지가 아니라 도구의 구조로 보장해야 합니다. 라이브러리 컴포넌트를 가져다 쓰면, 내가 아무리 덜렁대도 버튼 높이는 항상 48px입니다. 인스턴스이기 때문에 임의로 안 바뀌니까요. KRDS Figma가 토큰과 컴포넌트를 묶어 제공하는 건, "디자이너를 믿지 말고 시스템을 믿어라"는 디자인 시스템의 기본 철학을 실천하는 겁니다. 이건 디자이너를 불신하는 게 아니라, 디자이너를 반복 노동에서 해방시키는 일입니다.

공공 서비스의 일관성은 곧 신뢰다

상업 브랜드는 개성으로 승부합니다. 남들과 달라 보이는 게 자산이죠. 그런데 공공 서비스는 정반대입니다. 국민이 정부 사이트에 기대하는 건 "신선함"이 아니라 "예측 가능함"입니다. A 부처 사이트에서 신청서를 낸 방식이 B 지자체 사이트에서도 똑같이 통하면, 사용자는 "여기도 정부구나, 믿을 만하구나" 하고 안심합니다. 사이트마다 버튼이 제각각이고 입력창이 제각각이면, 사용자는 매번 새로 적응해야 하고 "이게 진짜 공식 사이트 맞나" 하는 불안까지 느낍니다.

KRDS Figma 라이브러리는 이 "범정부 일관성"을 디자인 도구 차원에서 떠받치는 기둥입니다. 모든 기관의 디자이너가 같은 라이브러리에서 같은 컴포넌트를 가져다 쓰면, 결과물도 자연히 닮습니다. 이 닮음이 디지털 약자에게는 "한 번 배우면 어디서나 통하는" 큰 배려가 되고, 일반 국민에게는 "정부 서비스답다"는 신뢰가 됩니다. 일관성은 미적 취향의 문제가 아니라 공공성의 문제입니다.

"디자이너의 자유"라는 오해

라이브러리를 강조하면 꼭 나오는 반발이 있습니다. "그러면 디자이너는 그냥 부품 조립공이 되는 거 아니냐, 창의성은 어디 가냐." 이건 디자인 시스템에 대한 흔한 오해입니다. 라이브러리가 표준화하는 건 반복되는 기초 부품이지, 디자인 전체가 아닙니다. 버튼을 매번 새로 그리는 데 쓸 에너지를, 정작 중요한 정보 구조·흐름·콘텐츠 위계에 쏟으라는 겁니다.

비유하자면, 건축가는 못과 나사를 직접 깎지 않습니다. 표준 부품을 쓰고, 자신의 창의성은 공간의 구성과 동선에 발휘하죠. 디자이너도 마찬가지입니다. 버튼 모서리 반지름을 고민하는 건 창의성이 아니라 낭비입니다. 라이브러리는 디자이너에게서 자유를 뺏는 게 아니라, 낭비할 자유를 뺏고 진짜 창의성에 집중할 자유를 주는 겁니다. 잘 만든 디자인 시스템 위에서 일해 본 디자이너들은 이걸 금방 체감합니다 — "잡일이 사라지니 진짜 디자인을 할 시간이 생겼다"고요.

한 장면 — 같은 프로젝트, 두 디자이너

추상적인 원리를 길게 늘어놓는 것보다, 한 장면을 그려 보는 게 빠를 것 같습니다. 어느 공공 기관의 새 민원 포털 구축 프로젝트, 디자이너 두 명이 화면을 나눠 맡았다고 합시다.

먼저 A 디자이너. 첫날 빈 파일을 열고 익숙하게 사각형부터 그립니다. 버튼을 그리고, "8px쯤이면 되겠지" 하며 모서리를 둥글리고, 평소 쓰던 파랑으로 칠합니다. 입력창도, 셀렉트도 그렇게 하나씩 손으로 만듭니다. 일주일 만에 시안이 그럴듯하게 나옵니다. 본인 눈엔 멀쩡합니다. 빠르고, 자유롭고, "내가 만들었다"는 만족감도 있죠.

B 디자이너는 첫날 30분을 KRDS 라이브러리를 연결하는 데 씁니다. 처음엔 좀 답답합니다. "그냥 그리면 빠를 텐데 뭐 이런 걸 설정하나" 싶죠. 그런데 둘째 날부터 속도가 붙습니다. 버튼이 필요하면 자산 패널에서 끌어다 놓고, 상태 변형은 이미 다 들어 있으니 따로 그릴 필요가 없습니다. 색은 토큰을 참조하니 고민할 게 없고요. 일주일 뒤, B의 시안도 완성됩니다.

겉보기엔 둘 다 멀쩡한 시안입니다. 그런데 두 시안을 합쳐 한 사이트로 개발하는 순간, 차이가 드러납니다. A의 화면과 B의 화면에서 버튼 높이가 다르고(A는 손으로 그려 46px, B는 표준 48px), 파랑의 채도가 미묘하게 다르고, A의 입력창엔 오류 상태가 아예 없어서 개발자가 "알아서" 만들어야 합니다. 그 "알아서"는 또 표준에서 벗어나죠. 결국 QA가 "두 화면이 따로 논다"고 지적하고, A의 화면을 표준에 맞춰 다시 손보는 추가 작업이 생깁니다.

여기서 핵심은, A가 게으르거나 실력이 없어서가 아니라는 점입니다. A는 오히려 더 부지런히, 더 많이 그렸습니다. 다만 각자 그렸기 때문에 어긋난 겁니다. B가 한 일은 더 적게 그린 것뿐인데, 결과는 더 일관되고 접근성도 챙겨졌습니다. 라이브러리의 가치가 바로 여기 있습니다 — 더 적게 일하고 더 표준에 가까워지는 것. 그리고 이 차이는, 사이트가 완성된 뒤 ViewCheck로 돌려 보면 컴포넌트 미통과 수로 정확히 드러납니다. A가 맡은 페이지의 미통과가 B의 페이지보다 훨씬 많을 거고, 그게 곧 "어디서 표준이 샜는지"의 지도가 됩니다.

공공 사이트가 자주 틀리는 지점 — 라이브러리 오용 사례

이제 현업에서 실제로 반복되는, "라이브러리를 안 쓰거나 잘못 쓰는" 사례들을 보겠습니다. 모두 익명화한 일반적 패턴입니다(특정 기관을 지목하지 않습니다). 이 사례들이 곧 뒤에 나올 자가진단 항목의 근거가 됩니다.

실수 1) 라이브러리를 "참고용"으로만 본다

가장 근본적이고 흔한 실수입니다. KRDS Figma를 열어 보긴 했는데, 내 파일엔 연결하지 않고 눈으로 보며 따라 그립니다.

• 나쁜 예: KRDS 버튼이 모서리 8px, 높이 48px인 걸 보고, 내 파일엔 "비슷하게" 그림. 실제론 7px, 46px. 색도 미묘하게 다른 파랑. 화면 100개에 이게 누적되며 표준에서 점점 멀어짐.
• 올바른 예: KRDS 라이브러리를 팀 라이브러리로 연결(enable)하고, 자산 패널에서 표준 버튼 컴포넌트를 직접 드래그해 배치. 수치가 어긋날 여지 자체가 없음.

실수 2) 가져다 놓고 멋대로 뜯어고친다(디태치/오버라이드 남용)

라이브러리 컴포넌트를 가져다 놓긴 했는데, 마음에 안 든다고 색을 바꾸고, 모서리를 바꾸고, 심하면 "분리(detach)"해서 인스턴스 연결을 끊어 버립니다.

• 나쁜 예: 표준 버튼을 가져왔지만 "이 화면엔 좀 더 진한 색이 어울려서" 토큰이 아닌 임의 색으로 덮어씀. 또는 detach해서 더 이상 라이브러리 업데이트를 못 받는 죽은 부품으로 만듦.
• 올바른 예: 컴포넌트가 제공하는 정식 변형·속성(variant/property) 안에서만 조정. 정 표준에 없는 모양이 필요하면, 그건 디자인 결정으로 별도 검토하지 임의로 덮어쓰지 않음. 인스턴스 연결은 유지해서 업데이트를 계속 받음.

실수 3) 토큰을 무시하고 색·간격을 직접 입력한다

컴포넌트는 표준을 써 놓고, 정작 색상과 간격은 등록된 스타일/변수가 아니라 손으로 직접 입력합니다.

• 나쁜 예: 텍스트 색을 색상 스타일이 아니라 #333333 같은 임의 값으로 직접 지정. 간격도 8의 배수 토큰이 아니라 "보기 좋은" 임의 px로 입력. 나중에 표준색이 바뀌어도 자동 갱신 안 됨.
• 올바른 예: 색은 반드시 등록된 색상 스타일/변수로, 간격은 표준 간격 토큰으로. 이렇게 해야 토큰 하나 고치면 전체가 따라 바뀌는 유지보수 이점을 누림.

실수 4) 상태·변형을 통째로 빠뜨린다

기본 모습만 그리고, 호버·포커스·비활성·오류 상태는 시안에 아예 없습니다.

• 나쁜 예: 신청 폼 시안에 입력창의 평상시 모습만 있음. 오류 상태(빨간 테두리 + 메시지)는 없어서, 개발자가 "알아서" 만들고 표준에서 벗어남. 포커스 상태도 누락돼 키보드 접근성이 시안 단계에서부터 빠짐.
• 올바른 예: KRDS 컴포넌트의 상태 변형을 시안에 함께 명시. 적어도 오류·포커스·비활성은 별도 화면이나 주석으로 개발에 전달. 라이브러리 컴포넌트를 쓰면 이 상태들이 이미 정의돼 있어 빠뜨리기 어려움.

실수 5) 오래된 버전을 계속 쓴다

한 번 가져다 쓴 뒤로 라이브러리 업데이트를 무시합니다. 갱신 알림이 떠도 "지금 바쁘니까" 하고 넘깁니다.

• 나쁜 예: 1년 전 버전의 컴포넌트를 그대로 사용. 그사이 표준이 개정됐는데 반영 안 함. 신규 화면은 새 표준, 기존 화면은 옛 표준이 섞여 한 사이트 안에서 일관성이 깨짐.
• 올바른 예: 라이브러리 업데이트 알림을 주기적으로 확인하고, 변경 사항을 검토 후 일괄 반영. 컴포넌트 인스턴스를 유지했다면 업데이트 적용이 클릭 몇 번으로 끝남.

실수 6) 디자인과 코드를 따로 논다

디자이너는 KRDS Figma를 쓰는데, 개발자는 GitHub 킷을 모르고 직접 구현합니다(또는 그 반대).

• 나쁜 예: 디자인은 표준 컴포넌트인데, 개발은 부트스트랩 같은 다른 프레임워크로 비슷하게 흉내. 시안과 구현이 미묘하게 어긋나고, 접근성 속성이 빠짐.
• 올바른 예: Figma는 KRDS 라이브러리, 코드는 KRDS GitHub 킷(npm install krds-uiux 또는 CDN)을 함께 사용. 디자인·코드가 같은 표준을 공유해 간극이 최소화됨.

실수 7) 임의 컴포넌트를 만들어 "우리 표준"이라 부른다

KRDS에 이미 있는 컴포넌트를, 팀이 따로 만들어 자체 라이브러리라고 부릅니다.

• 나쁜 예: 표준 셀렉트가 있는데 "우리 프로젝트용 셀렉트"를 새로 디자인. 결국 표준과 다른 동작·접근성을 가진 또 하나의 비표준 부품이 탄생. 유지보수 책임도 팀이 떠안음.
• 올바른 예: KRDS에 있는 컴포넌트는 KRDS 것을 쓰고, 정말 KRDS에 없는 프로젝트 고유 컴포넌트만 자체 제작하되 KRDS 토큰을 기반으로 만듦. 표준을 재발명하지 않음.

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

KRDS의 좋은 점은, 라이브러리를 "쓰세요"로 끝내지 않고 바로 연결해서 쓸 수 있는 형태로 제공한다는 것입니다. 역할별로 어떻게 적용하는지 정리합니다.

디자이너라면 — 가장 먼저 할 일은 KRDS 공식 Figma(@krds) 라이브러리를 자기 작업 공간/팀에 연결(enable)하는 것입니다. 그러면 자산(Assets) 패널에 표준 컴포넌트들이 나타나고, 드래그 한 번으로 배치할 수 있습니다. 새 화면을 만들 때 사각형부터 그리지 말고, 자산 패널을 먼저 여세요. "이 부품이 라이브러리에 있나?"를 먼저 묻는 습관이 핵심입니다. 색과 간격은 반드시 등록된 스타일/변수로 지정하고, 컴포넌트는 정식 변형 안에서만 조정하세요. detach는 최후의 수단입니다.

개발자라면 — 디자이너가 KRDS Figma를 쓴다면, 개발도 짝을 맞춰 KRDS GitHub 킷(KRDS-uiux/krds-uiux)을 써야 1:1 대응이 완성됩니다. npm install krds-uiux로 설치하거나 CDN(krds.min.css / krds.min.js)으로 불러오면, Figma 컴포넌트와 같은 표준을 따르는 HTML/CSS/JS를 그대로 쓸 수 있습니다. 시안의 버튼 변형(1차/2차/텍스트)과 코드의 버튼 클래스가 대응되는지 확인하세요. 디자인은 표준인데 개발이 다른 프레임워크로 흉내 내면, 그 순간 간극이 벌어집니다.

기획자라면 — 화면 정의서에 "버튼", "드롭다운"이라고만 적지 말고, "KRDS 표준 컴포넌트 사용(1차 버튼, 오류 상태 포함)"처럼 표준 사용을 명시하세요. 그리고 디자인 리뷰 체크리스트에 "표준 컴포넌트를 인스턴스로 사용했는가, 임의로 그리지 않았는가"를 넣으면, 라이브러리 누락이 검수 단계에서 걸러집니다. 기획이 "표준을 쓰라"고 명시하는 한 줄이, 디자인·개발의 이탈을 막는 가장 싼 보험입니다.

그래서 우리 디자인은 표준일까? — ViewCheck로 5분 자가진단

여기까지가 KRDS 공식 Figma 라이브러리의 기준과 활용법입니다. 그런데 이 글의 진짜 핵심은 지금부터입니다. "내가(우리 팀이) 정말 표준을 지키고 있는지"를 어떻게 확인하느냐.

디자이너 입장에서 곤란한 건, Figma 안에서 "나 표준 잘 쓰고 있나"를 객관적으로 확인하기가 의외로 어렵다는 점입니다. 자산 패널에서 컴포넌트를 가져다 썼다고 믿지만, 어느 화면에선 detach해 놨을 수도 있고, 어느 버튼은 색을 임의로 덮어썼을 수도 있습니다. 그리고 무엇보다 — Figma에서 표준대로 그렸어도, 실제로 배포된 사이트에서 그 표준이 지켜졌는지는 별개의 문제입니다. 디자인은 표준인데 개발에서 어긋났다면? 그건 Figma만 봐서는 절대 알 수 없습니다.

그래서 가장 확실한 자가진단은 완성된(또는 운영 중인) 사이트를 표준 잣대로 직접 채점해 보는 것입니다. ViewCheck(krds.viewcheck.co.kr)가 바로 이 채점을 자동화합니다. URL만 넣으면 페이지를 실제로 크롤링해서, 화면 위의 컴포넌트들이 KRDS 기준을 지키는지 판정합니다.

공식 Figma 라이브러리가 제공하는 컴포넌트들은 KRDS 846규칙 중 컴포넌트(CP) 규칙군 446개에 대응하고, 분석 결과의 컴포넌트(Components) 탭에서 확인할 수 있습니다. 즉 ViewCheck는 "이 사이트가 라이브러리의 표준 컴포넌트대로 만들어졌는가"를 446개 규칙으로 자동 점검하는 셈입니다.

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

• 표준 컴포넌트 존재·구현 여부: 버튼·입력창·셀렉트·탭·아코디언 등 KRDS 컴포넌트가 표준 구조(올바른 태그·역할·속성)로 구현됐는지, 아니면 비표준으로 흉내 냈는지
• 접근성 요건 충족: 컴포넌트에 접근 가능한 이름(label/aria), 포커스 처리, 적절한 역할(role)이 있는지 — Figma 컴포넌트에 내장된 접근성이 실제 코드에서도 살아 있는지
• 상태 표현: 오류·비활성 같은 상태가 코드로 표현되고 메시지가 연결돼 있는지
• 시각 표준(토큰) 준수: 색·간격·크기가 표준 토큰 범위 안에 있는지(디자인 토큰 채택률과 연계)

DOM만으로 판단하기 어려운 시각적 부분 — 예를 들어 "코드엔 표준 컴포넌트 같은 게 없는데 화면엔 분명히 버튼/드롭다운이 있는" 비표준 구현 — 은 KRDScan Vision AI가 스크린샷을 보고 보강 판정합니다. 이게 중요한 이유는, 표준을 우회해 직접 그린(또는 코딩한) 컴포넌트일수록 일반 코드 검사 도구에 안 잡히기 때문입니다. ViewCheck는 사람이 눈으로 보듯 화면을 함께 보기 때문에, "라이브러리를 안 쓰고 흉내 낸 부품"도 놓치지 않습니다.

리포트를 어떻게 읽나 — 디자이너를 위한 해석법

분석이 끝나면 컴포넌트(Components) 탭에서, 컴포넌트별 규칙의 통과/미통과 수와, 미통과 항목의 위치(어느 페이지)·이유·개선 방법(howToFix)이 함께 나옵니다.

디자이너 관점에서 이 리포트는 이렇게 읽으면 됩니다. 미통과가 많이 뜨는 컴포넌트가 있다면, 그건 십중팔구 "라이브러리를 안 썼거나 잘못 쓴 컴포넌트"입니다. 예를 들어 버튼에서 접근성·상태 관련 규칙이 줄줄이 미통과라면, 표준 버튼 컴포넌트를 안 쓰고 직접 그려서 구현한 것일 가능성이 큽니다. 셀렉트에서 라벨·역할 규칙이 미통과라면, "가짜 셀렉트"(div로 만든)를 쓴 거죠. 즉 ViewCheck의 컴포넌트 미통과 목록은, 사실상 "라이브러리를 쓰지 않은 곳의 지도"입니다.

여러 페이지를 한꺼번에 분석하면 더 유용합니다. "메인의 버튼은 표준인데 신청 페이지의 버튼은 비표준"처럼 페이지별 편차가 드러나거든요. 이건 보통 "메인은 외주가 표준대로 만들었는데, 신청 페이지는 나중에 내부에서 급하게 추가하며 표준을 빠뜨린" 경우입니다. 우선순위(P0~P3)도 함께 매겨지니, 한정된 시간에 사용자를 가장 많이 막는 것부터 손볼 수 있습니다.

무료 진단으로 우리 사이트 메인부터 한 번 돌려 보면, 손으로는 며칠 걸릴 "표준 준수 여부 전수 점검"이 몇 분 만에 끝납니다. 그리고 그 결과는 막연한 "표준 잘 지키자"가 아니라, "이 페이지의 이 버튼을 표준 컴포넌트로 교체하자"는 구체적인 작업 목록이 됩니다. 디자이너에게 이건 곧, "내 시안이 어디서 새고 있는지"를 데이터로 확인하는 일입니다.

자주 묻는 질문

현장에서 KRDS Figma 라이브러리를 다룰 때 반복해서 나오는 질문들을 모았습니다.

Q. KRDS Figma 라이브러리는 어디서 구하나요? 유료인가요?

KRDS 공식 Figma 계정(@krds)에서 공개적으로 제공됩니다. 정부 디자인 시스템 자산이라 공공·민간을 막론하고 공공 서비스 구축에 활용할 수 있도록 열려 있습니다. 정확한 최신 위치와 사용 범위는 KRDS 공식 채널(가이드라인 페이지, 공식 Figma)에서 확인하시는 게 안전합니다. 핵심은 "구하기 어려운 비밀 자산"이 아니라 "이미 공개된 표준 자산"이라는 점입니다 — 안 쓰는 게 손해죠.

Q. 라이브러리를 "연결"하는 것과 "복사해서 쓰는 것"의 차이가 뭔가요?

큰 차이가 있습니다. 복사해서 쓰면, 그 순간의 모습이 내 파일에 박제됩니다. 나중에 원본 라이브러리가 개정돼도 내 복사본은 옛날 그대로죠. 반면 라이브러리를 연결(enable)하고 컴포넌트를 인스턴스로 가져다 쓰면, 원본이 바뀔 때 갱신 알림을 받고 클릭 몇 번으로 반영할 수 있습니다. "복사"는 한 번 찍은 사진이고, "연결"은 실시간 중계라고 생각하시면 됩니다. 가능하면 연결을 쓰세요.

Q. 우리 기관 고유의 색·로고가 있는데, 표준 라이브러리를 쓰면 개성이 사라지지 않나요?

표준 컴포넌트를 쓴다고 기관 정체성이 사라지지 않습니다. 라이브러리가 표준화하는 건 버튼·입력창 같은 기능 부품의 동작과 접근성이지, 기관의 브랜드 색이나 로고, 콘텐츠 톤이 아닙니다. 토큰 체계 안에서 브랜드 색을 적용하고, 헤더·푸터·메인 비주얼 같은 영역에서 정체성을 표현하면 됩니다. 기초 부품은 표준으로 통일하되 정체성은 상위 레이아웃에서 — 이게 디자인 시스템과 브랜드가 공존하는 방식입니다.

Q. 이미 디자인이 끝난(또는 운영 중인) 사이트인데, 지금 와서 라이브러리로 바꿔야 하나요?

전부 갈아엎을 필요는 없습니다. 먼저 ViewCheck로 현황을 확인해 "지금 어떤 컴포넌트가, 어느 페이지에서, 표준을 안 지키는지"를 목록으로 만드세요. 그다음 우선순위가 높은 것(접근성을 막는 비표준 컴포넌트)부터 표준으로 교체하면 됩니다. 신청·로그인·검색처럼 사용 빈도가 높은 핵심 경로부터 손보면, 적은 작업으로 가장 많은 사용자를 구제할 수 있습니다. 리뉴얼 예산을 한 번에 들이지 않고도 점진적으로 표준에 가까워지는 게 현실적인 전략입니다.

Q. Figma에서 표준대로 그렸는데 ViewCheck는 왜 미통과를 띄우나요?

바로 그 지점이 ViewCheck가 필요한 이유입니다. Figma 시안이 표준이어도, 개발 과정에서 어긋났을 수 있거든요. 디자이너가 표준 셀렉트를 그렸는데 개발자가 div로 흉내 냈다면, 시안은 완벽해도 실제 사이트는 비표준입니다. ViewCheck는 시안이 아니라 실제 배포된 코드와 화면을 점검하기 때문에, "디자인·개발 사이에서 표준이 새는 지점"을 잡아냅니다. 미통과가 떴다면, 그건 디자인 탓이 아니라 "디자인은 됐는데 구현에서 빠졌다"는 신호일 가능성이 큽니다. 그 리포트를 들고 개발팀과 대화하면 됩니다.

Q. 디자인 토큰(색·간격)까지 ViewCheck가 점검하나요?

네, 시각 표준의 채택 여부를 봅니다. 색·간격·크기 같은 값이 KRDS 표준 토큰 범위 안에 있는지를 디자인 토큰 채택률로 확인할 수 있습니다(디자인 시스템 관련 분석과 연계). 다만 "디자이너가 Figma에서 토큰 변수를 썼는지"는 Figma 내부 정보라 외부에서 직접 보긴 어렵고, ViewCheck는 그 결과물인 사이트의 실제 색·간격이 표준값인지를 점검합니다. 즉 "토큰을 썼나"가 아니라 "토큰을 쓴 결과와 같은가"를 봅니다 — 사용자에게 중요한 건 결국 결과물이니까요.

Q. 디자인팀과 개발팀이 라이브러리를 두고 자꾸 엇갈립니다. 어떻게 맞추죠?

KRDS가 디자인(Figma)·코드(GitHub 킷)·문서(가이드라인)를 한 세트로 제공하는 이유가 정확히 이 문제를 풀기 위해서입니다. 디자이너는 KRDS Figma를, 개발자는 KRDS GitHub 킷을 쓰면 둘이 같은 표준을 공유하게 됩니다. 그리고 분기마다(또는 릴리스마다) ViewCheck로 사이트를 점검해, 컴포넌트 미통과 목록을 공동의 "할 일 목록"으로 삼으세요. 누구 탓을 가리는 대신 "이 리포트의 P0부터 같이 고치자"로 대화하면, 책임 떠넘기기가 협업으로 바뀝니다.

Q. 작은 프로젝트라 라이브러리까지 챙길 여유가 없는데요?

오히려 작은 프로젝트일수록 라이브러리가 시간을 아껴 줍니다. 버튼·입력창·셀렉트를 처음부터 그리고 상태까지 일일이 만드는 시간보다, 라이브러리에서 가져다 놓는 게 압도적으로 빠르거든요. "여유가 없어서 못 쓴다"는 보통 "한 번도 안 써봐서 진입 장벽이 커 보인다"의 다른 말입니다. 라이브러리 연결은 처음 한 번만 하면 되고, 그 뒤로는 계속 시간을 벌어 줍니다. 작은 팀일수록 표준 자산에 기대는 게 이득입니다.

Q. 컴포넌트를 가져왔는데 우리 화면에 딱 맞는 변형이 없으면요?

먼저 라이브러리가 제공하는 변형(variant)·속성(property)을 끝까지 확인하세요. 의외로 크기·종류·상태 조합이 많아, "없다"고 생각한 게 사실은 있는 경우가 많습니다. 그래도 정말 표준에 없는 형태가 필요하다면, 그건 임의로 덮어쓸 게 아니라 의식적인 디자인 결정으로 다뤄야 합니다. 가능하면 표준 토큰을 기반으로 새 컴포넌트를 만들어 자체 라이브러리에 등록하고, 팀 안에서 공유하세요. 핵심은 "표준에 없으니 막 그린다"가 아니라 "표준의 토큰 위에서 일관되게 확장한다"는 태도입니다. 그리고 그렇게 만든 커스텀 컴포넌트도 ViewCheck로 점검하면 접근성·상태 처리에서 빠진 게 있는지 확인할 수 있습니다.

Q. 라이브러리를 썼는데도 사이트가 느려지거나 무거워지지 않나요?

디자인 라이브러리(Figma)와 실제 사이트 성능은 별개입니다. Figma 라이브러리를 쓴다고 코드가 무거워지지 않습니다. 오히려 KRDS GitHub 킷의 컴포넌트 코드는 표준에 맞춰 정돈돼 있어, 제각각 구현한 것보다 유지보수와 성능 면에서 유리한 경우가 많습니다. CDN으로 불러올지 번들에 포함할지는 프로젝트 사정에 맞게 선택하면 됩니다. 성능이 걱정된다면 그건 라이브러리 사용 여부의 문제가 아니라 별도의 최적화 영역이고, ViewCheck의 Web Vitals 분석으로 따로 점검할 수 있습니다.

Q. ViewCheck로 점검한 결과를 디자인팀 보고서에 어떻게 활용하나요?

컴포넌트(Components) 탭의 통과/미통과 수치와 우선순위(P0~P3)는 그대로 보고 자료가 됩니다. "현재 컴포넌트 표준 준수율 X%, P0 미통과 N건, 주요 원인은 비표준 셀렉트·라벨 누락"처럼 정량적으로 정리할 수 있거든요. 분기마다 같은 사이트를 점검하면 추세(개선되고 있는가)도 보입니다. 막연히 "디자인 잘하고 있어요"가 아니라, "지난 분기 대비 미통과 N건 감소"처럼 숫자로 성과를 보고할 수 있다는 게 디자이너에게 큰 무기가 됩니다.

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

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

가장 먼저(치명적, P0) — 접근성을 완전히 막는 비표준 컴포넌트. 키보드로 안 열리는 가짜 셀렉트, 스크린리더가 인식 못 하는 커스텀 드롭다운, 접근 가능한 이름이 없는 아이콘 버튼 같은 것들. 이건 특정 사용자에게 기능을 완전히 차단하므로 1순위입니다. 라이브러리를 안 쓰고 직접 만든 컴포넌트가 대개 여기 해당합니다. 신청·로그인 같은 핵심 경로에 있다면 더더욱 먼저 손봐야 합니다.

그다음(높음, P1) — 표준 컴포넌트인데 상태 처리가 빠진 경우. 오류 상태가 코드로 표현 안 되거나, 포커스 표시가 없거나, 필수 입력의 미선택을 못 잡는 것들. 작동은 하지만 특정 상황(오류 제출, 키보드 사용)에서 사용자가 막힙니다.

그 후(보통, P2) — 시각 표준 이탈. 색·간격·크기가 토큰을 벗어나거나, 같은 컴포넌트가 페이지마다 미묘하게 다른 것들. 사용은 가능하지만 일관성이 떨어져 "정돈 안 된" 인상을 줍니다.

여력이 되면(낮음, P3) — 오래된 버전 컴포넌트 갱신, 그룹화·정렬 같은 사용성 개선. 표준을 크게 벗어나진 않지만 경험을 한 단계 끌어올리는 항목입니다.

ViewCheck 리포트는 이 우선순위(P0~P3)를 자동으로 매겨 주기 때문에, "눈에 띄는 것부터"가 아니라 "사용자를 가장 많이 막는 것부터" 순서대로 처리할 수 있습니다. 디자이너 입장에서는, P0·P1에 자주 걸리는 컴포넌트를 표준 라이브러리 컴포넌트로 교체하는 것만으로도 점수가 크게 오릅니다. 한정된 인력과 일정 안에서 가장 효과 큰 개선에 집중하는 게 핵심입니다.

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

이 글은 KRDS 공식 Figma 라이브러리의 활용과 자가진단을 실무 관점에서 풀어 쓴 것입니다. 정확한 원문 기준과 자산은 아래 공식 자료에서 직접 확인하실 수 있습니다.

• KRDS 공식 Figma(@krds) — 디자이너용 컴포넌트·상태·토큰의 원본 라이브러리. 연결해서 인스턴스로 가져다 쓰는 게 핵심.
• KRDS 가이드라인 PDF(디지털 정부서비스 UI/UX 가이드라인, 2025.08판) — 컴포넌트별 정의와 사용 원칙의 1차 원천.
• KRDS 컴포넌트 킷(GitHub `KRDS-uiux/krds-uiux`) — Figma 컴포넌트와 1:1 대응하는 HTML/CSS/JS 코드. npm install krds-uiux 또는 CDN(krds.min.css / krds.min.js)으로 사용.
• KRDS 컴포넌트 문서(웹) — 각 컴포넌트의 변형·예시를 화면으로 확인.

공식 자료는 "정답지"이고, ViewCheck는 "내 답안을 채점해 주는 도구"라고 생각하시면 됩니다. 둘을 함께 쓰면, 표준을 이해하고(가이드라인·Figma) → 표준대로 디자인·구현하고(Figma 라이브러리·GitHub 킷) → 내 사이트가 그 표준에 맞는지 확인하는(ViewCheck) 한 바퀴가 완성됩니다. 디자이너에게 이 한 바퀴는, "잘 그렸겠지" 하는 막연한 믿음을 "데이터로 확인된 사실"로 바꾸는 과정입니다.

오늘의 체크리스트 — Figma 라이브러리, 이것만은

마지막으로, 디자이너·개발자·기획자가 바로 쓸 수 있는 자가진단 체크리스트로 정리합니다. 절반은 Figma 안에서, 절반은 ViewCheck로 확인하는 항목입니다.

• ☐ KRDS 공식 Figma(@krds) 라이브러리를 작업 공간/팀에 연결(enable)했다(눈으로 보고 따라 그리지 않았다).
• ☐ 새 화면을 만들 때 사각형부터 그리지 않고, 자산 패널에서 표준 컴포넌트를 먼저 찾았다.
• ☐ 컴포넌트를 인스턴스로 배치했고, 함부로 detach(분리)하지 않았다.
• ☐ 색·간격·크기를 직접 입력하지 않고 등록된 스타일/변수(토큰)로 지정했다.
• ☐ 기본 모습뿐 아니라 호버·포커스·비활성·오류 상태를 시안에 함께 정의했다.
• ☐ 컴포넌트는 정식 변형(variant) 안에서만 조정했다(임의로 색·모양을 덮어쓰지 않았다).
• ☐ 라이브러리 업데이트 알림을 확인하고, 최신 버전을 반영했다.
• ☐ 개발은 KRDS GitHub 킷(npm install krds-uiux 또는 CDN)을 써서 디자인·코드가 같은 표준을 공유한다.
• ☐ KRDS에 이미 있는 컴포넌트를 재발명하지 않았다(자체 표준을 따로 만들지 않았다).
• ☐ 완성/운영 사이트를 ViewCheck로 점검해, 컴포넌트(Components) 탭에서 미통과 목록을 확인했다.
• ☐ 컴포넌트 미통과가 많은 곳 = "라이브러리를 안 쓴 곳"으로 보고, P0·P1부터 표준 컴포넌트로 교체했다.

KRDS 공식 Figma 라이브러리(@krds)를 연결해서 인스턴스로 쓰면, 위 디자인 항목 대부분이 저절로 지켜집니다. 직접 그리다 어긋날 위험을 줄이는 가장 확실한 방법이죠. 그리고 그게 실제 사이트에서도 지켜졌는지는 ViewCheck로 몇 분이면 확인할 수 있습니다 — 디자인 단계의 점검(Figma)과 결과물의 점검(ViewCheck), 이 둘을 함께 돌리는 게 자가진단의 완성입니다.

공식 Figma 라이브러리는 작은 도구처럼 보이지만, 사실 공공 서비스 디자인의 일관성과 접근성이 출발하는 지점입니다. 디자이너가 사각형을 그릴지, 표준 컴포넌트를 가져다 놓을지 — 그 작은 선택 하나가 100개 화면의 정돈됨을, 그리고 그 화면을 쓰는 수많은 국민의 경험을 가릅니다.

오늘 정리한 것이 많아 보일 수 있지만, 핵심은 단순합니다. 따라 그리지 말고 가져다 쓰고, 토큰을 참조하고, 상태까지 챙기고, 결과물을 데이터로 확인하는 것. 이 네 가지만 챙겨도 라이브러리 미준수 문제의 대부분은 사라집니다. 그리고 그게 잘 됐는지는 ViewCheck로 5분이면 확인할 수 있습니다. 완벽을 한 번에 만들 필요는 없습니다. 오늘 자기 Figma 파일을 열어 "내가 진짜 라이브러리를 쓰고 있나"를 한 번 점검하고, 운영 사이트를 ViewCheck로 한 번 돌려 보는 것 — 거기서부터 시작하면 됩니다. 다음 글에서는 이 라이브러리가 참조하는 또 다른 공식 자산을 같은 방식으로 뜯어보겠습니다.

우리 사이트의 컴포넌트는 정말 KRDS 표준일까요? krds.viewcheck.co.kr에서 URL만 넣으면 무료로 확인할 수 있습니다. 메인 페이지 하나만 돌려 봐도, 컴포넌트(Components) 탭에서 "라이브러리를 안 쓴 곳"이 그대로 드러납니다.

#KRDS #공식Figma라이브러리 #디자인시스템 #공공웹 #웹접근성 #ViewCheck #정부웹사이트 #UIUX #디자인토큰 #컴포넌트 #피그마 #공식라이브러리 #자가진단 #체크리스트 #점검항목 #UI컴포넌트 #컴포넌트설계 #전자정부 #디지털정부 #행정안전부