Figma에서 KRDS 보는 법 — 도면을 실무에서 점검하는 순서

---

들어가며 — 도면을 보는 "순서"

이번 주 1개월차 세 번째 주의 마지막 글입니다. 월요일에는 "왜 도면 단계에서 보나(고치는 비용은 단계가 뒤로 갈수록 뛴다)"를, 수요일에는 "도면을 안 보거나 도면만 봐서 문제가 새는 사례들"을 살펴봤습니다. 오늘은 이번 주에서 가장 실용적인 부분을 다룹니다. 그래서 Figma 같은 디자인 파일에서 KRDS 준수를 실제로 어떻게 점검하느냐 하는 것입니다.

미리 한 가지 말씀드리면, 오늘 글은 "Figma 사용법" 강좌가 아닙니다. 디자인 도구를 다루는 법은 디자이너분들이 저보다 훨씬 잘 아십니다. 오늘 다루려는 건 "디자인 파일을 KRDS 기준에 비춰볼 때 무엇을, 어떤 순서로 보면 되는지"라는 점검의 관점입니다. 디자인을 직접 만드는 분이든, 그 디자인을 검수하는 담당자든, "이 도면이 기준에 맞나"를 확인할 때 손에 쥘 수 있는 지도를 그려드리려는 것입니다.

그리고 이번 달은 개요 달이라, Figma 분석의 깊은 작동 방식(디자인 파일 안의 변수와 스타일을 어떻게 읽어들여 비교하는지 같은 기술적인 부분)은 나중에 따로 팝니다. 이 심화 내용은 7개월차에서 하나씩 자세히 다룰 예정입니다. 오늘은 "점검 순서"에 집중하겠습니다. 큰 것부터 작은 것까지, 어디서부터 보면 효율적인지 말이죠. 순서만 잘 잡아도 같은 시간에 훨씬 많은 위험을 거를 수 있으니, 사실 이 "순서"가 실무에서는 제일 쓸모 있는 부분입니다.

지난주 금요일 글에서 URL 분석 결과를 "요약 먼저, 약한 것부터" 읽는 순서를 정리해드렸는데, Figma도 비슷합니다. 무작정 화면을 하나하나 뜯어보는 게 아니라, 공통적인 것부터 잡고 개별로 내려가는 편이 훨씬 효율적입니다. 그 순서를 오늘 함께 그려보겠습니다.

핵심 원리를 먼저 말씀드리면 "퍼지는 것부터 잡는다"입니다. 디자인에는 한 번 정하면 여러 화면에 퍼지는 것(색·글자·간격 같은 토큰과 버튼·입력창 같은 컴포넌트)이 있고, 그 화면에만 있는 것(개별 레이아웃)이 있습니다. 퍼지는 것을 먼저 잡으면 적은 노력으로 큰 위험이 걸러지고, 그다음에 개별로 내려가면 됩니다. 거꾸로 개별 화면부터 하나하나 보면, 같은 문제(예를 들어 비표준 색 하나)를 화면마다 또 발견하느라 시간만 쓰고 지치게 됩니다. 그래서 순서가 중요합니다. 오늘 글은 결국 이 한 문장을 풀어쓰는 셈입니다. 퍼지는 것부터, 그다음 개별로, 그리고 결과는 우선순위로.

---

본론 1 — 먼저 '공통 자산'부터 본다

토큰과 컴포넌트가 출발점입니다

디자인 파일을 점검할 때 개별 화면부터 들어가면 길을 잃기 쉽습니다. 화면이 수십 개나 되니까요. 대신 그 화면들이 공통으로 쓰는 "자산"부터 보는 게 맞습니다. 크게 두 가지입니다. 하나는 디자인 토큰(색·글자·간격처럼 미리 정해둔 값)이고, 다른 하나는 컴포넌트(버튼·입력창처럼 재사용하는 부품)입니다.

왜 여기서부터 봐야 하느냐면, 수요일에 말씀드렸듯 이것들이 모든 화면에 퍼지기 때문입니다. 토큰과 컴포넌트가 표준에 맞으면, 그것을 쓰는 화면들도 대체로 맞습니다. 반대로 여기가 어긋나 있으면 모든 화면이 같이 어긋납니다. 그러니 공통 자산을 먼저 잡으면, 개별 화면을 전부 다 보지 않아도 큰 위험이 한꺼번에 걸러집니다. 효율이 제일 좋은 출발점인 셈입니다.

조금 더 풀어보겠습니다. 디자인이란 결국 "정해둔 규칙을 여러 화면에 반복 적용하는 일"입니다. 색 하나를 정하면 그 색이 헤더에도, 버튼에도, 링크에도 쓰입니다. 버튼 컴포넌트 하나를 만들면 그것이 수십 개 화면에 복제되어 들어갑니다. 그래서 규칙이 되는 값과 부품이 표준에 맞는지를 먼저 확인하면, 그 규칙을 따르는 나머지가 자동으로 검증되는 효과가 생깁니다. 반대로 개별 화면부터 보면, 같은 규칙에서 나온 같은 문제를 화면마다 거듭 마주치게 됩니다. 노동은 노동대로 들고, 정작 근본은 못 고치는 것이죠. 그래서 "출발점을 어디에 두느냐"가 점검의 효율을 절반쯤 결정합니다.

토큰 점검: 표준 팔레트와 대조합니다

먼저 토큰부터 보겠습니다. 디자인 파일에 정의된 색 팔레트, 글자 크기 단계, 간격 규칙을 KRDS 표준과 대조합니다. 확인할 것은 이런 것들입니다.

• 색: 쓰고 있는 색이 표준 색 팔레트 안에 있나요? 디자이너가 직접 찍은 비표준 색이 슬쩍 섞여 있지는 않나요?
• 글자: 글자 크기와 굵기가 정해진 단계를 따르나요? 어중간한 중간값이 끼어 있지는 않나요?
• 간격: 요소 사이 간격이 규칙(예를 들어 일정한 배수)을 따르나요? 제멋대로인 값이 있지는 않나요?

여기서 "비표준 값이 몇 개나 섞여 있나"가 핵심 지표입니다. 수요일 본론에서 말씀드린 그 "비슷비슷한 파랑 여러 개" 문제를, 토큰 단계에서 미리 잡는 것입니다. 사람 눈으로는 비슷한 색을 구분하기가 거의 불가능하니, 값으로 대조하는 편이 확실합니다. 화면에서 파랑 두 개가 나란히 있으면 우리 눈은 그냥 "파랑"으로 뭉뚱그려 보지만, 값으로 보면 하나는 표준 색이고 하나는 미묘하게 어긋난 비표준 색일 수 있습니다. 이 차이를 값으로 짚어주는 게 토큰 대조입니다.

조금 더 풀면, 토큰 점검은 "채택률"이라는 개념으로도 읽을 수 있습니다. 이 디자인이 쓴 값 가운데 표준 토큰을 쓴 것이 몇 %, 직접 찍은 비표준이 몇 %인지를 보는 것입니다. 채택률이 높을수록 표준을 잘 따른 것이고, 낮으면 제멋대로인 값이 많다는 뜻입니다. 이 숫자 하나로 "이 디자인이 얼마나 표준에 가까운가"를 가늠할 수 있습니다. 그리고 흥미로운 건, 이게 운영 시점(URL 분석)에서도 똑같은 방식으로 나온다는 점입니다. 그래서 "디자인 채택률"과 "구현 채택률"을 나란히 비교하면, 수요일에 말씀드린 "도면에서 실제 사이트로 옮기다가 샌 정도"가 눈에 보입니다. 디자인은 90%인데 구현이 70%라면, 옮기는 과정에서 20%만큼 샌 것이죠. 이 비교는 뒤(본론 5)에서 다시 짚겠습니다.

색만이 아니라 글자와 간격도 같은 방식입니다. 글자는 정해진 크기 단계(예를 들어 본문·소제목·제목)를 벗어난 어중간한 값이 있는지, 간격은 규칙을 벗어난 값이 있는지를 봅니다. 이 셋(색·글자·간격)이 디자인 토큰의 핵심이고, 화면 전체의 인상을 좌우합니다. 그래서 토큰부터 잡으면 "사이트가 정돈돼 보이느냐"의 팔 할이 정해집니다. 사람들이 어떤 사이트를 보고 "깔끔하다" 혹은 "어수선하다"고 느끼는 건, 대개 개별 화면의 문제가 아니라 이 토큰이 일관되느냐 아니냐에서 갈립니다. 색이 다섯 가지 파랑으로 흩어져 있고, 글자 크기가 제각각이고, 간격이 들쭉날쭉하면 아무리 개별 화면을 예쁘게 그려도 전체 인상은 어수선합니다. 반대로 토큰이 일관되면 화면 하나하나에 큰 공을 들이지 않아도 전체가 정돈돼 보입니다. 그만큼 토큰은 파급력이 큰 자산입니다.

한 가지 더 짚고 싶은 게 있습니다. 토큰 대조는 "디자이너의 취향을 검열하는 일"이 아닙니다. 어떤 파랑을 브랜드 색으로 정할지, 글자 위계를 어떻게 설계할지는 여전히 디자이너의 몫입니다. 토큰 대조가 하는 일은 "정해둔 표준에서 벗어난 값이 있다"는 사실만 짚어주는 것입니다. 정해진 표준 팔레트를 쓰기로 했는데 실수로 비슷한 다른 색이 섞여 들어갔다면, 그건 취향의 문제가 아니라 실수의 문제입니다. 그 실수를 값으로 잡아주는 게 토큰 점검이고, 무엇을 어떻게 디자인할지는 그 위에서 디자이너가 정하면 됩니다.

컴포넌트 점검: 표준 키트와 대조합니다

다음은 컴포넌트입니다. 버튼·입력창·표 같은 부품이 KRDS 규격에 맞는지 봅니다. KRDS는 표준 컴포넌트를 키트 형태로 제공하기도 하니까(월요일에 말씀드렸죠), 그것을 그대로 가져다 썼는지, 아니면 비슷하게 직접 만들었는지부터 확인합니다. 직접 만든 것이라면 더 꼼꼼히 봐야 합니다. 겉모습은 같아 보여도 크기·간격·상태 처리가 다를 수 있기 때문입니다.

확인할 것은 이런 것들입니다.

• 크기: 버튼과 터치 영역이 충분히 큰가요? (손가락으로 눌러야 하는 터치 타겟은 최소 44×44px 정도가 권장됩니다.)
• 구조: 입력창에 라벨 자리가 제대로 있나요? 도움말이나 오류 메시지가 들어갈 자리는요?
• 상태: 기본·마우스 올림·비활성·선택됨 같은 여러 상태가 다 디자인되어 있나요?

특히 "상태"가 자주 빠집니다. 기본 모양만 그려두고 비활성이나 오류 상태를 안 그려두면, 그 처리를 개발자가 알아서 만들면서 어긋나게 됩니다(수요일 본론에서 말씀드린 그 지점입니다). 그래서 도면 단계에서 상태까지 다 그려져 있는지 보는 것이 중요합니다.

상태가 왜 그렇게 중요한지 예를 들어보겠습니다. 입력 폼이 대표적입니다. 입력창의 기본 모양만 그려두고 "오류일 때(빨간 테두리와 안내 메시지)", "비활성일 때(회색 처리)", "입력하는 중일 때"의 모양을 안 그려두면, 그 처리를 개발자가 즉흥으로 하게 됩니다. 그러면 사용자가 필수 항목을 빠뜨리고 제출 버튼을 눌렀을 때 나오는 오류 안내가 엉성해집니다. 지난주 시리즈에서도 짚었던 "눌러봐야 뒤늦게 나오는" 불친절한 오류 메시지가 여기서 싹틉니다. 반대로 도면 단계에서 "필수 항목을 안 채우고 제출하면 이렇게 보인다"까지 그려져 있으면, 개발도 그대로 만들고 사용자도 헷갈리지 않습니다. 컴포넌트는 기본 모양이 전부가 아니라, 그것이 살아 움직이는 여러 상태까지가 한 세트라는 걸 기억하시면 좋겠습니다.

그리고 컴포넌트도 토큰처럼 "표준을 그대로 썼나, 변형했나"를 기준으로 보면 빠릅니다. KRDS 표준 컴포넌트를 그대로 가져다 썼으면 대체로 안전하고, 직접 만들었거나 변형했으면 거기를 집중적으로 봅니다. 변형한 컴포넌트가 많을수록 어긋날 위험이 커지니, 사실상 "변형 컴포넌트 목록"이 그대로 위험 지도가 됩니다. 점검할 때 "어디를 특히 조심해서 봐야 하나"를 이 목록이 알려주는 셈이죠. 표준을 그대로 쓴 부분은 가볍게 넘기고, 손을 댄 부분에 시간을 집중하면 됩니다.

여기서 컴포넌트를 왜 KRDS가 표준으로 제공하는지도 잠깐 생각해볼 만합니다. 공공 사이트는 기관마다 제각각으로 만들면 국민 입장에서 매번 새로 배워야 합니다. A 기관의 신청 버튼과 B 기관의 신청 버튼이 생긴 것도 다르고 동작도 다르면, 사용자는 사이트를 옮길 때마다 사용법을 다시 익혀야 하죠. 표준 컴포넌트는 이 "매번 새로 배우는 비용"을 줄여줍니다. 어느 공공 사이트를 가도 버튼은 버튼답게, 입력창은 입력창답게 동작하면, 국민은 익숙한 방식으로 서비스를 쓸 수 있습니다. 그래서 컴포넌트가 표준을 따르는지 보는 건 단순한 형식 점검이 아니라, "이 사이트를 처음 오는 사람도 헤매지 않을까"를 보는 일입니다.

---

본론 2 — 그다음 '개별 화면'을 봅니다

공통 자산을 한 번 잡았으면, 이제 개별 화면으로 내려갑니다. 그런데 여기서도 모든 화면을 똑같이 볼 게 아니라 우선순위가 있습니다.

중요한 화면부터 봅니다

모든 화면이 똑같이 중요하지는 않습니다. 사용자가 제일 많이 거치는 화면, 핵심 기능 화면(신청·검색·로그인 같은)부터 봅니다. 잘 안 쓰는 안내 페이지보다, 매일 수천 명이 거치는 메인이나 신청 폼이 우선입니다. 지난주 금요일에 말씀드린 "심각도와 빈도" 개념이 여기서도 그대로 적용됩니다. 영향 범위가 큰 화면부터 보는 것이죠. 시간과 집중력은 한정돼 있으니, 그것을 가장 많은 사용자에게 닿는 화면에 먼저 쓰는 게 합리적입니다.

이 우선순위가 왜 중요한지, 반대 상황을 상상해보면 분명해집니다. 화면 마흔 개를 앞에서부터 순서대로 다 똑같이 정독한다고 해봅시다. 앞쪽 화면은 아직 힘이 있으니 깐깐하게 보지만, 뒤로 갈수록 지쳐서 대충 넘기게 됩니다. 그런데 하필 뒤쪽에 중요한 신청 폼이 있었다면, 정작 제일 중요한 화면을 제일 지친 상태로 본 셈이 됩니다. 중요도 순으로 보면 이 함정을 피할 수 있습니다. 가장 많은 사용자에게 닿는 화면을 가장 맑은 정신으로 보게 되니까요.

화면에서 무엇을 보나요

개별 화면에서는 이런 것들을 봅니다.

• 레이아웃과 위계: 제목이 제목답게, 본문이 본문답게 위계가 잡혀 있나요? 중요한 버튼이 눈에 잘 띄나요?
• 정렬과 간격: 요소들이 가지런히 정렬돼 있나요? 간격이 일정한가요?
• 반응형: 모바일 화면도 함께 그려져 있나요? 데스크톱만 있고 모바일이 없으면, 거기서 이번 달 앞선 글들에서 짚은 그 모바일 사고가 싹틉니다.
• 대비: 글자와 배경의 대비가 충분한가요? (이건 디자인 단계에서 색 값으로 미리 확인할 수 있습니다.)

레이아웃과 위계 이야기를 조금 더 하겠습니다. 위계란 "무엇이 더 중요한지가 눈에 보이느냐"입니다. 제목은 크고 진하게, 본문은 그보다 작게, 부가 설명은 더 작고 흐리게. 이 위계가 잡혀 있으면 사용자는 화면을 슥 훑기만 해도 "여기가 핵심이구나"를 압니다. 반대로 모든 글자가 비슷한 크기로 나열돼 있으면, 어디가 중요한지 몰라 처음부터 끝까지 다 읽어야 합니다. 특히 공공 사이트는 안내 정보가 많아서, 위계가 없으면 정보의 벽 앞에서 사용자가 지칩니다. 그래서 개별 화면을 볼 때 "이 화면에서 제일 중요한 게 한눈에 들어오나"를 꼭 확인하시면 좋습니다.

정렬과 간격은 사소해 보여도 인상을 크게 좌우합니다. 요소들이 왼쪽 선에 딱 맞춰 정렬돼 있으면 정돈된 느낌을 주지만, 조금씩 어긋나 있으면 무의식적으로 "허술하다"는 인상을 줍니다. 사용자가 그 어긋남을 콕 집어 설명하지는 못해도, 전체적으로 "뭔가 어수선하다"고 느낍니다. 간격도 마찬가지입니다. 관련 있는 것끼리는 가깝게, 관련 없는 것끼리는 멀게 배치돼 있어야 정보가 묶여 보입니다. 이런 것들은 도면 단계에서 값으로 확인할 수 있는 부분이라, 개발로 넘어가기 전에 정리해두면 좋습니다.

모바일 화면이 그려져 있는지 꼭 봅니다

특히 강조하고 싶은 게 모바일입니다. 디자인 단계에서 데스크톱만 그리고 모바일은 "개발자가 알아서"로 넘기는 경우가 의외로 많은데, 그러면 모바일 깨짐이 거의 보장되다시피 합니다. ViewCheck의 URL 분석이 데스크톱·태블릿·모바일 세 가지 화면 크기를 실제로 테스트하는 것도 바로 이 때문입니다. 도면 단계에서 모바일 화면이 함께 그려져 있는지, 거기서 요소가 겹치지 않는지를 보는 게 중요합니다. 모바일 화면이 아예 없다면, 그게 첫 번째 지적 사항이 됩니다.

왜 "개발자가 알아서"가 위험할까요? 디자이너의 의도가 담기지 않기 때문입니다. 데스크톱에서 가로로 나란히 있던 버튼 세 개를, 모바일에서는 세로로 쌓을지, 둘과 하나로 나눌지, 메뉴 안으로 접을지는 명백히 디자인 결정입니다. 그런데 모바일 도면이 없으면 개발자가 그것을 즉흥으로 정하게 됩니다. 디자이너가 원한 모양이 아닐 가능성이 크고, 그러다 요소가 겹치거나 잘리거나 화면 밖으로 삐져나갑니다. 모바일 도면을 그린다는 건 "작은 화면에서 이 정보를 어떻게 배치할까"라는 결정을 디자인 단계에서 미리 내린다는 뜻이고, 그게 있어야 개발도 헤매지 않습니다.

조금 더 현실적으로 말씀드리면, 요즘 공공 사이트 방문자의 상당수가 모바일로 들어옵니다. 어떤 서비스는 모바일 접속이 데스크톱보다 많기도 합니다. 그런데 정작 디자인은 데스크톱 기준으로만 그려지는 경우가 많죠. 실제로 대부분의 사용자가 보는 건 모바일 화면인데, 그 화면의 도면이 없다면 순서가 거꾸로 된 셈입니다. 그래서 모바일 도면 유무는 단순한 체크 항목이 아니라, "우리가 실제 사용자를 기준으로 설계했는가"를 묻는 질문이기도 합니다.

터치 타겟 이야기도 여기서 짚고 가겠습니다. 손가락으로 눌러야 하는 버튼이나 링크는 마우스 커서로 누를 때보다 정밀도가 떨어집니다. 그래서 충분히 큰 터치 영역(권장 최소 44×44px)이 필요합니다. 이게 너무 작으면 원하는 버튼 대신 옆 버튼이 눌리거나, 여러 번 시도해야 겨우 눌립니다. 특히 손이 떨리는 어르신이나 화면을 정확히 못 보는 저시력 사용자에게는 작은 터치 타겟이 큰 장벽이 됩니다. 이 크기 역시 도면 단계에서 값으로 확인할 수 있으니, 컴포넌트 점검(본론 1)과 이어서 봐두면 좋습니다.

대비도 디자인 단계에서 챙기면 좋습니다. 글자와 배경의 색이 정해져 있으니, 그 둘의 대비가 기준 이상인지는 도면에서 이미 계산할 수 있습니다. 지난주 시리즈에서 나온 "회색 글씨가 안 보인다"는 류의 민원을, 디자인 단계에서 색을 정할 때 미리 거르는 것입니다. 운영에서 뒤늦게 발견해서 색을 다시 바꾸는 것보다, 처음 색을 정할 때 대비를 맞추는 편이 훨씬 쌉니다. 대비는 감으로 "괜찮아 보인다"가 아니라 값으로 판정되는 항목이라, 사람 눈보다 자동 대조가 정확합니다. 디자이너 눈에는 충분해 보이는 회색도, 값으로 재보면 기준에 못 미치는 경우가 흔합니다.

---

본론 3 — 점검 결과를 어떻게 다루나요

"비표준" 목록을 만듭니다

점검을 하고 나면 결국 "표준에서 벗어난 것들"의 목록이 나옵니다. 비표준 색 몇 개, 규격을 벗어난 글자 크기 몇 개, 상태가 빠진 컴포넌트 몇 개. 이 목록을 정리하는 게 점검의 산출물입니다. 점검은 "봤다"로 끝나는 게 아니라, "무엇이 어긋났는지"를 손에 잡히는 목록으로 남기는 데까지 가야 의미가 있습니다.

여기서도 지난주 금요일의 원칙이 그대로 통합니다. 우선순위를 매기는 것입니다. 모든 화면에 쓰이는 공통 컴포넌트의 문제가, 한 화면에만 있는 문제보다 급합니다. 영향 범위 순으로 정리하면, "이 버튼 컴포넌트 하나만 고치면 화면 절반이 해결"처럼 효율 좋은 것부터 손대게 됩니다. 이 우선순위 등급은 보통 P0부터 P3까지로 나뉘는데(이 위험도 등급화의 자세한 원리는 4개월차에서 다룹니다), 오늘은 "비표준 항목마다 무게가 다르고, 그 무게 순으로 처리한다" 정도만 잡으시면 됩니다.

우선순위를 매기는 기준을 조금 더 풀어보겠습니다. 두 축으로 봅니다. 하나는 "얼마나 아픈가(심각도)"이고, 다른 하나는 "얼마나 퍼져 있나(영향 범위)"입니다. 신청 버튼을 아예 못 누르게 만드는 문제는 심각도가 최상위이고, 잘 안 쓰는 페이지의 간격이 조금 어긋난 건 한참 아래입니다. 동시에, 모든 화면에 들어가는 공통 헤더의 문제는 영향 범위가 넓고, 한 화면에만 있는 문제는 좁습니다. 이 두 축을 겹쳐서, 심각하면서도 넓게 퍼진 것부터 처리하면 적은 노력으로 가장 큰 개선을 냅니다. 도면 단계에서는 특히 공통 자산의 문제가 이 "심각하고 넓은" 자리에 자주 옵니다. 공통 컴포넌트 하나가 어긋나면 그것을 쓰는 모든 화면이 같이 어긋나니까요.

"의도된 예외"를 가려냅니다

그리고 "의도된 예외"를 가려내는 것도 이 단계입니다. 비표준 목록에 올라온 것 중에는, 사실 일부러 그렇게 한 것도 있습니다. 특정 캠페인 페이지라 의도적으로 다른 색을 썼다든가 하는 경우죠. 이런 건 무작정 "고쳐라"가 아니라 "예외로 둔다"고 표시하면 됩니다. 기계가 "이건 표준이 아니다"라고 잡아주면, 사람이 "이건 의도된 예외다"라고 판단하는 것입니다. 단순 대조는 기계가, 맥락 판단은 사람이. 그래야 멀쩡한 의도까지 다 고치라고 하는 과잉이 생기지 않습니다.

이 "예외 처리"가 왜 중요하냐면, 그게 없으면 자동 점검이 오히려 신뢰를 잃기 때문입니다. 기계가 잡은 비표준 목록을 그대로 "전부 잘못"이라고 들이밀면, 담당자는 "아니 이건 일부러 이렇게 한 건데"라며 목록 전체를 불신하게 됩니다. 하나가 틀리면 나머지도 못 믿는 것이죠. 그래서 좋은 점검은 "기계가 잡되, 사람이 예외를 판정할 수 있게" 설계돼 있어야 합니다. 그러면 목록은 "무조건 고칠 것"이 아니라 "검토가 필요한 것"이 되고, 사람의 판단이 그 위에 얹히면서 목록이 실제로 신뢰받고 쓰이게 됩니다.

디자이너에게 넘길 때는 "표준은 이거다"로

점검 결과를 디자이너에게 넘길 때는, "틀렸다"가 아니라 "표준은 이거다"로 전달하는 게 낫습니다. "이 색은 비표준입니다" 대신 "이 색 대신 표준 브랜드 블루를 쓰시면 됩니다"처럼요. 어떻게 고치는지가 함께 있어야 바로 행동으로 이어집니다. 이건 수요일에 말씀드린 "값이 아니라 이름(토큰)으로 소통"과도 통합니다. "#1F4E79로 바꿔주세요"보다 "브랜드 블루로 바꿔주세요"가 사람 사이 소통에서는 훨씬 명확하니까요.

이 소통 방식의 차이는 실무에서 생각보다 큽니다. 지적만 있고 방법이 없으면, 받는 사람은 "그래서 어떻게 하라는 거지?" 하고 한 번 더 알아봐야 합니다. 그 사이에 시간이 흐르고, 소통이 오갑니다. 반대로 "이렇게 바꾸면 됩니다"라는 방향이 함께 있으면, 받는 즉시 손을 댈 수 있습니다. 발견과 개선 사이의 거리가 짧아지는 것이죠. 그래서 점검 결과를 넘길 때는 늘 "무엇이 어긋났나"와 "무엇으로 바꾸면 되나"를 한 쌍으로 주는 게 좋습니다.

개발에 넘기기 전 마지막 관문으로 둡니다

가장 좋은 건, 이 점검을 "개발에 넘기기 직전"의 마지막 관문으로 두는 것입니다(수요일 본론에서 말씀드린 지점입니다). 디자인이 끝났다 싶을 때 한 번 자동으로 훑어서 비표준 목록을 정리하고, 그걸 다 처리한 뒤에 개발에 넘깁니다. 그러면 개발자는 깨끗한 도면을 받게 되고, 수요일에 예로 든 그 "개발 후에 문제가 우수수 발견되는" 팀 같은 상황이 생기지 않습니다.

이걸 아예 절차로 못 박아두면 더 좋습니다. "디자인 완료 = 자동 점검 통과 + 비표준 목록 0(또는 의도된 예외만 남김)"으로 정의하는 것입니다. 그러면 "예쁘면 완료"가 아니라 "기준에 맞으면 완료"가 됩니다. 디자인 완료의 기준 자체를 바꾸는 셈이죠. 처음에는 번거로워 보여도, 이게 자리를 잡으면 개발과 운영 단계에서 잡을 일이 확 줄어서 전체적으로는 훨씬 편해집니다. 앞에서 막을수록 뒤가 편하다는 것(수요일 본론)이 여기서도 그대로입니다.

외주 디자인을 받을 때도 이 점검이 검수 기준이 됩니다. "KRDS에 맞게 해주세요"라는 모호한 말 대신, "자동 점검에서 비표준 0으로 납품해주세요"라는 객관적 기준으로 받는 것입니다. 그러면 "맞게 했다 vs 안 맞다"는 소모적인 논쟁 없이, 결과로 확인됩니다. 검수 기준이 사람 감이 아니라 자동 대조면 양쪽 다 깔끔합니다. 발주하는 쪽은 명확한 기준을 제시할 수 있고, 받는 쪽은 그 기준만 맞추면 되니 오히려 일이 단순해집니다. 모호한 요구는 늘 나중에 분쟁을 낳지만, 값으로 확인되는 기준은 그럴 여지가 적습니다.

---

본론 4 — 사람이 다 하기 어려운 이유 (다시)

오늘 순서를 쭉 보시면, "이걸 사람이 일일이 하면?"이라는 생각이 드실 겁니다. 이번 달 초에 짚었던 그 한계가 여기서도 똑같이 나타납니다. 점검의 순서 자체는 사람이 이해하고 판단할 수 있지만, 그 순서를 실제로 돌리는 데는 사람 손으로 감당하기 어려운 부분이 섞여 있습니다.

토큰 대조는 눈으로 되지 않습니다

색이 표준과 정확히 같은지, 글자 크기가 정확히 그 단계인지, 간격이 규칙에 맞는지 — 이건 사람 눈으로 확인하기가 거의 불가능합니다(월요일 본론에서 말씀드렸죠). 색 값을 일일이 찍어서 비교하고, 크기를 재고, 간격을 재고… 화면 수십 개에 요소 수백 개를 그렇게 하는 건 현실적으로 무리입니다. 특히 비슷한 색끼리는 사람 눈이 아예 구분을 못 하니, 값으로 대조하지 않으면 놓칩니다. 그래서 토큰 대조는 자동으로 하는 게 사실상 필수입니다.

이 부분을 조금 더 강조하고 싶습니다. 사람 눈은 "다르다/같다"를 판단하는 데는 뛰어나지만, "얼마나 다른가"를 정밀하게 재는 데는 약합니다. 색 두 개가 미묘하게 다르면 "비슷하네" 하고 넘어가지, 그 차이가 표준 허용 범위 안인지 밖인지는 알 수 없습니다. 간격이 몇 픽셀 어긋난 것도 눈으로는 "괜찮아 보인다"로 넘어갑니다. 그런데 이런 미세한 어긋남들이 화면 전체에 쌓이면 앞서 말한 "어수선함"이 됩니다. 자동 대조는 이 "얼마나 다른가"를 값으로 재주기 때문에, 사람 눈이 놓치는 미세한 어긋남을 잡아냅니다. 사람이 못 하는 일을 기계가 대신하는 전형적인 자리입니다.

화면이 많으면 또 지칩니다

디자인도 화면이 많으면 이번 달 초에 짚은 피로·편차·누락이 똑같이 찾아옵니다. 앞 화면은 깐깐하게, 뒤 화면은 대충. 사람이니 어쩔 수 없습니다. 그래서 "공통 자산은 자동으로 대조하고, 사람은 개별 화면의 맥락(이 위계가 적절한가 같은)에 집중"하는 분업이 낫습니다. 기계가 잴 수 있는 건 기계가 재고, 사람이 판단할 건 사람이 판단하는 것이죠. 이 분업은 사람을 대체하려는 게 아니라, 사람이 잘하는 일에 집중하게 해주려는 것입니다.

게다가 디자인은 자주 바뀝니다

그리고 디자인은 운영보다 더 자주, 더 빠르게 바뀝니다. 시안은 피드백을 받을 때마다 수정되니까, 어제 본 도면이 오늘 또 바뀝니다. 사람이 매번 처음부터 전부 다 보는 건 비현실적입니다. 어제 통과했던 화면을 오늘 또 처음부터 다 재검토할 여력은 없으니까요. 반면 자동 대조는 바뀔 때마다 다시 돌려도 부담이 없습니다. 시안이 바뀔 때마다 빠르게 "이번 수정에서 비표준이 새로 생겼나"를 확인할 수 있습니다. 디자인이 활발하게 도는 단계일수록 자동 점검의 가치가 커집니다.

이 "자주 바뀐다"는 특성은 도면 점검이 운영 점검과 다른 결정적인 지점이기도 합니다. 운영 사이트는 배포된 뒤에는 비교적 안정적이지만, 디자인 시안은 완성되기 전까지 계속 흔들립니다. 그래서 도면 점검은 "한 번 하고 끝"이 아니라 "수정될 때마다 가볍게 다시 돌리는" 방식이 어울립니다. 매번 사람이 전부 다시 보는 대신, 자동으로 훑어서 "지난번 대비 새로 생긴 비표준"만 확인하면 됩니다. 그러면 디자인이 아무리 자주 바뀌어도 점검이 발목을 잡지 않습니다.

그래서 자동 대조 + 사람 판단입니다

결국 Figma 분석도 운영 시점(URL 분석)과 같은 구조입니다. 기계가 토큰·컴포넌트를 표준과 자동으로 대조해서 "비표준 목록"을 뽑고, 사람은 그 위에서 "이건 의도된 예외다", "이 위계는 좀 어색하다" 같은 판단을 얹습니다. 단순 대조는 기계, 맥락 판단은 사람. 이번 달 내내 반복해서 말씀드린 그 원칙이, 설계 시점에서도 똑같이 적용됩니다. 어느 도구를 쓰든 이 구조는 변하지 않습니다. 재는 일은 기계에 맡기고, 판단하는 일은 사람이 쥐고 있는 것. 그게 자동 점검을 제대로 쓰는 방식입니다.

---

본론 5 — 도면 점검이 운영 점검과 이어지는 이유

오늘 글이 도면(설계) 이야기라, 지난 두 주 동안 다룬 운영(URL) 이야기와 따로 노는 것처럼 느껴질 수 있습니다. 그런데 둘은 사실 한 몸입니다. 같은 KRDS 기준을 쓰되, 하나는 "의도"를 보고 하나는 "결과"를 봅니다. 이 연결을 짚어두면 오늘 이야기가 더 또렷해집니다.

디자인 채택률과 구현 채택률을 비교합니다

본론 1에서 잠깐 말씀드린 "채택률" 비교를 여기서 마저 풀겠습니다. 도면 단계에서 디자인 토큰 채택률이 나오고, 운영 단계(URL 분석)에서 구현 토큰 채택률이 나옵니다. 둘은 같은 방식으로 계산되니까 나란히 비교할 수 있습니다. 만약 디자인 채택률은 90%인데 구현 채택률이 70%라면, 도면에서 실제 사이트로 옮기는 과정에서 20%만큼 샌 것입니다. 디자이너는 표준을 잘 지켜 그렸는데, 개발로 넘어가면서 비표준 값이 끼어든 것이죠.

이 비교가 왜 값진지 생각해보겠습니다. 수요일에 짚은 "디자인은 통과인데 사이트는 위반"인 상황을, 이 두 숫자의 차이가 그대로 보여줍니다. 도면만 봐도, 사이트만 봐도 이 "새는 지점"은 안 보입니다. 둘을 나란히 놓고 비교해야 "어디서, 얼마나 샜는지"가 드러납니다. 그래서 도면 점검과 운영 점검은 어느 하나만 하면 반쪽입니다. 도면 점검으로 "의도는 맞았나"를 확인하고, 운영 점검으로 "그 의도가 결과에 담겼나"를 확인해야 온전합니다. ViewCheck가 Figma 분석과 URL 분석을 둘 다 갖고 있는 것도 이 때문입니다.

이 두 숫자의 차이를 어떻게 활용하느냐도 실무에서 중요합니다. 만약 디자인 채택률과 구현 채택률이 거의 같다면, 도면에서 사이트로 옮기는 과정이 깨끗하다는 뜻이니 그 팀의 개발 프로세스는 믿을 만합니다. 반대로 둘의 차이가 크게 벌어진다면, 그 간극 자체가 개선 과제가 됩니다. "디자인은 잘 그렸는데 개발에서 새고 있다"는 사실이 숫자로 드러나면, 어느 단계를 손봐야 할지가 명확해지니까요. 막연히 "품질이 안 좋다"가 아니라 "설계는 괜찮은데 구현 단계에서 표준이 유실된다"는 구체적인 진단이 나오는 것입니다. 그리고 이 진단은 감이 아니라 같은 방식으로 계산된 두 숫자의 비교에서 나오므로, 그대로 보고 근거가 됩니다.

도면 점검은 7대 영역 중 일부까지만 봅니다

한 가지 정직하게 짚어둘 게 있습니다. 도면 점검으로 볼 수 있는 건, 사이트 품질의 전부가 아닙니다. 색·글자·간격·컴포넌트 규격처럼 도면에 담긴 값은 설계 단계에서 확인할 수 있지만, 실제로 사이트에 접속해봐야 알 수 있는 것들은 도면에 없습니다. 예를 들어 페이지가 얼마나 빨리 뜨는지(성능), 보안 설정이 제대로 됐는지(신뢰성), 검색엔진이 잘 읽는지(개방성) 같은 것은 도면에는 아예 존재하지 않는 정보입니다. 이런 것들은 운영 시점(URL 분석)에서만 판정됩니다.

행정안전부의 전자정부 웹사이트 품질관리 지침은 호환성·접근성·개방성·접속성·편의성·효율성·신뢰성이라는 7대 영역을 봅니다. 도면 점검은 이 가운데 디자인·컴포넌트·일부 접근성 항목(대비·터치 타겟처럼 값으로 판정되는 것)까지를 미리 거를 수 있습니다. 나머지, 특히 실제 접속해봐야 아는 영역들은 운영 점검의 몫입니다. 그래서 "Figma 분석으로 다 끝난다"고 하면 과장입니다. 정확히는 "설계 단계에서 미리 거를 수 있는 부분을 거른다"이고, 나머지는 만든 뒤에 URL 분석으로 확인해야 합니다. 이 두 시점이 각자의 자리에서 일하고, 그 위에 다음 주에 다룰 세 번째 시점(LLM 분석)이 판단을 얹습니다.

이렇게 시점을 나눠 보는 게 왜 중요한지도 짚고 싶습니다. 하나의 점검으로 모든 걸 잡으려 하면, 각 시점의 강점을 살리지 못합니다. 도면은 "만들기 전에, 값으로 정밀하게" 볼 수 있는 자리이고, 운영은 "만든 뒤에, 실제 응답까지" 볼 수 있는 자리입니다. 도면에서 잡을 수 있는 걸 굳이 운영까지 미루면 그만큼 비싸지고, 운영에서만 볼 수 있는 걸 도면에서 억지로 판정하려 하면 틀린 결론이 나옵니다. 각 시점을 제자리에 두고, 그 사이를 채택률 비교 같은 방식으로 이어주는 것. 그게 설계와 운영을 한 몸으로 쓰는 방법입니다.

---

본론 6 — Figma 점검 자가 체크리스트

오늘 순서를 한 장으로 정리해보겠습니다. 디자인을 개발에 넘기기 전, 이 정도만 확인해도 큰 사고는 거릅니다. 자동 대조로 잡는 것과 사람이 봐야 하는 것을 나눠 적겠습니다. 거창한 도구가 없어도, 이 순서만 지키면 대부분의 위험은 걸러집니다.

공통 자산 (자동 대조가 유리)

확인	통과
색이 표준 팔레트 안에 있나 (비표준 색 없나)	☐
글자 크기·굵기가 정해진 단계를 따르나	☐
간격이 규칙(일정한 배수)을 따르나	☐
버튼·터치 영역이 충분히 큰가 (최소 44×44px 권장)	☐
컴포넌트가 표준 키트를 따르나 (변형 최소)	☐
컴포넌트 상태(기본·마우스 올림·비활성·오류)가 다 있나	☐

개별 화면 (사람 판단이 필요)

확인	통과
제목·본문 위계가 분명한가	☐
중요한 버튼이 눈에 띄는 자리에 있나	☐
모바일 화면이 그려져 있나 (데스크톱만 아님)	☐
모바일에서 요소가 안 겹치나	☐
글자·배경 대비가 충분한가	☐
핵심 흐름(신청·검색·로그인)이 자연스러운가	☐

넘기기 전 마지막

확인	통과
비표준 목록을 우선순위로 정리했나	☐
색·간격을 값이 아니라 토큰 이름으로 표기했나	☐
의도된 예외를 따로 표시해 두었나	☐
배포 후 운영 점검(URL) 일정이 잡혀 있나	☐

위쪽(공통 자산)은 사람 눈으로 하기 힘드니 자동 대조에 맡기고, 가운데(개별 화면)는 사람이 맥락을 보고, 아래(넘기기 전)는 절차로 챙깁니다. 이 세 묶음만 돌면, 수요일에 본 두 팀의 사고가 둘 다 예방됩니다. 공통 자산 점검이 첫째 팀의 "안 봐서 비싸짐"을, 마지막 줄의 "운영 점검 일정"이 둘째 팀의 "통과인데 위반"을 막습니다.

이 체크리스트를 처음 쓰실 때는 항목이 많아 보일 수 있습니다. 그런데 실제로 몇 번 돌려보면, 자동 대조가 맡는 위쪽 묶음은 사람이 신경 쓸 일이 거의 없다는 걸 아시게 됩니다. 사람이 실제로 판단할 건 가운데 묶음뿐이고, 아래 묶음은 습관이 되면 한 번 훑는 것으로 끝납니다. 그래서 체감상 부담은 항목 수보다 훨씬 가볍습니다. 처음 한두 번만 낯설지, 자리를 잡으면 검수가 오히려 빨라집니다.

체크리스트를 하나 더 얹어 소개하자면, "이번에 새로 생긴 비표준이 있나"라는 질문입니다. 디자인은 자주 바뀌니까, 지난번 점검 이후 수정된 부분에서 새 비표준이 생겼을 수 있습니다. 전부 다시 볼 필요 없이, "이번 수정에서 새로 생긴 것"만 확인하면 됩니다. 자동 대조는 이 비교를 대신 해주니, 담당자는 "달라진 부분"에만 집중하면 됩니다. 정기적으로 도는 프로젝트일수록 이 "변화분만 보기"가 시간을 크게 아껴줍니다.

---

그래서 ViewCheck는

ViewCheck의 Figma 분석이 오늘 말씀드린 순서대로 돌아갑니다. 디자인 파일을 읽어들여서, 먼저 공통 자산(토큰·컴포넌트)을 KRDS 표준과 대조하고, 비표준 항목을 뽑아줍니다. 사람 눈으로는 못 잡는 미세한 색·간격 차이를 값으로 짚어서요. 그러면 디자이너나 검수 담당은 그 목록을 보고 "개발에 넘기기 전에" 정리하면 됩니다. ViewCheck가 하는 일은 "디자인 도구에서 파일을 읽어 KRDS 기준과 자동으로 대조"하는 것이고, 그 위의 판단(무엇이 의도된 예외인지, 어떤 위계가 어색한지)은 사람 몫으로 남깁니다.

오늘 이야기한 게 특별한 비법은 아닙니다. "공통 자산 먼저, 개별 화면은 중요한 것부터, 비표준 목록은 우선순위로, 개발 전에 정리." 이 순서입니다. 다만 토큰 대조처럼 사람 눈으로 안 되는 부분이 있어서, 거기를 자동으로 메워주는 것뿐입니다. ViewCheck는 그 자동 대조를 해주고, 그 위의 판단은 사람에게 남깁니다. 이 시리즈 내내 말씀드린 "단순 대조는 기계, 맥락 판단은 사람"이라는 구조가 여기서도 그대로입니다.

그리고 잊지 마실 것 하나. 수요일에 강조했듯, 도면을 잘 봤어도 그게 실제로 구현됐는지는 운영 시점(URL 분석)으로 따로 확인해야 합니다. Figma 분석은 "도면이 맞나"까지입니다. 그래서 ViewCheck가 URL 분석과 함께 있는 것이고요. 설계에서 거르고, 운영에서 확인하는 그 흐름입니다. 본론 5에서 말씀드린 "디자인 채택률과 구현 채택률의 비교"가 그 두 시점을 잇는 다리입니다.

오늘로 이번 달의 두 시점(운영·설계)이 다 나왔습니다. 정리하면 이렇습니다. 만들기 전에는 Figma 분석으로 도면을 깨끗하게(이번 주), 만든 후에는 URL 분석으로 진짜를 확인(지난 두 주). 둘 다 같은 KRDS 기준으로 보되, 하나는 의도를 하나는 결과를 봅니다. 그리고 다음 주에 나올 세 번째 시점(LLM 분석)이 그 위에서 판단을 더합니다. 세 개가 모이면 이번 달 첫 주에 그린 그 큰 그림이 완성됩니다.

🔐 특허로 지키는 부분

오늘 본 "디자인 파일에서 공통 자산(토큰·컴포넌트)을 먼저 표준과 자동 대조해 비표준 목록을 뽑고, 영향 범위 순으로 우선순위를 매겨 개발 전에 처리하게 하는 점검 절차"는 ViewCheck가 출원한 5건의 특허 가운데 설계 단계 디자인 토큰·컴포넌트 표준 대조, 그리고 위반 위험도 등급화 및 개선 우선순위 산정 주제와 맞닿아 있습니다. 비표준 항목을 단순히 나열하는 건 누구나 합니다. 차별점은, 퍼지는 것(공통 자산)부터 먼저 잡아 적은 노력으로 큰 위험을 거르고, 그 결과를 영향 범위와 의도된 예외까지 가려 행동 가능한 우선순위로 정리하는 순서를 권리로 정리해 둔 데 있습니다.

다만 솔직히 짚어둘 게 있습니다. 특허는 "방법을 지키는 장치"이지 "품질 보증서"가 아닙니다. 점검이 실제로 효율적이냐는 오늘 본 순서가 제대로 작동하느냐로 결정되는 것이고, 특허는 그 방법을 보호하는 것입니다. 그래서 "특허가 있으니 믿으세요"가 아니라 "이 방법을 직접 만들고 지켜두었다" 정도로 받아들여 주시면 됩니다. 그리고 현재는 출원 단계입니다. "등록특허"가 아니라 "출원 기술"로 정확히 표기합니다. 과장하면 오히려 신뢰가 깨지니까요. (특허 출원 기술 / 자체 개발)

마무리

오늘로 1개월차 세 번째 주가 끝났습니다. Figma 분석을 왜 하나(월), 도면과 결과물 사이에서 어떻게 새나(수), 도면을 실제로 어떤 순서로 보나(금)를 한 바퀴 돌았습니다. 점검 순서를 한 줄로 줄이면 이렇습니다. 공통 자산(토큰·컴포넌트) 먼저, 그다음 중요한 화면부터, 비표준은 우선순위로 정리해 개발 전에 처리. 그리고 토큰 대조처럼 눈으로 안 되는 건 자동으로.

다음 주(W4)는 세 번째 시점, LLM 분석으로 넘어갑니다. 규칙으로 딱 떨어지지 않는 부분을 AI가 어떻게 채우는지, 두 엔진이 어떻게 나눠 일하는지를 풀겠습니다. 이번 달의 마지막 시점입니다. 그리고 다음 달부터는 오늘 개요만 그린 것들을 영역별로 깊게 팝니다. 예를 들어 위험도 등급화는 4개월차, 네 카테고리(DS·CP·BP·SP)의 깊은 내용은 5개월차, 다중 페이지 집계는 6개월차, Figma 분석의 깊은 작동 방식은 7개월차, N/A를 채우고 개선안을 만드는 원리는 8개월차, 정기 진단과 성과 증명은 11개월차에서 각각 자세히 다룹니다.

오늘 체크리스트를 캡처해두시거나 메모장에 옮겨두시면, 다음 디자인 검수 때 그대로 꺼내 쓰실 수 있습니다. 거창한 도구 없이도 이 순서만 지키면 큰 사고는 거릅니다. 그게 핵심이고, 자동 대조는 사람 눈으로 안 되는 부분(토큰 값 비교)을 거들 뿐입니다.

디자인은 만드는 사람의 작품이라, "기준에 맞나"를 따지는 게 자칫 간섭처럼 느껴질 수 있습니다. 그런데 토큰과 컴포넌트를 자동으로 대조하는 건 디자이너의 창의를 건드리는 게 아니라, "표준에서 벗어난 값"이라는 사실만 짚어주는 것입니다. 무엇을 어떻게 디자인할지는 여전히 디자이너의 몫이고, 다만 "이 색은 표준 밖입니다"라는 정보를 하나 더 드리는 것뿐입니다. 그 정보가 있으면 개발로 넘어가 비싸지기 전에 정리할 수 있습니다. 이번 주도 끝까지 함께해 주셔서 고맙습니다. 다음 주, LLM 분석으로 만나뵙겠습니다.

krds.viewcheck.co.kr

---