Figma 분석이란 — 만들기 전에 잡는다

---

들어가며 — 시점을 하나 앞으로 당깁니다

지난주에는 운영 시점, 그러니까 URL 분석 이야기를 드렸습니다. "이미 돌아가고 있는 진짜 사이트를 있는 그대로 본다"는 것이었죠. 이번 주에는 시점을 하나 앞으로 당겨보려 합니다. 아직 만들지도 않은, 디자인 단계의 화면을 보는 것. ViewCheck 용어로는 Figma 분석이고, 이번 달 첫 주에 말씀드린 세 시점 중 "설계 시점"에 해당합니다.

요즘 웹사이트나 앱은 거의 다 Figma 같은 디자인 도구로 화면을 먼저 그립니다. 개발에 들어가기 전에, 디자이너가 색과 레이아웃과 버튼 모양을 미리 다 잡아두는 것이죠. 이 단계의 화면이 바로 "설계도"인 셈입니다. 건물로 치면 착공 전 도면입니다. 벽돌 한 장 쌓기 전에, 종이 위에서 문이 어디에 나고 창이 어디에 붙는지가 다 정해지는 그 단계 말입니다.

그런데 보통 이 도면 단계에서 KRDS 기준을 제대로 보는 경우가 드뭅니다. "일단 예쁘게 만들고, 기준은 나중에 검수에서 보자"가 흔한 흐름입니다. 그러다 지난 글에서 짚었던 것처럼 "디자인은 통과였는데 막상 배포본은 위반" 같은 일이 생기거나, 더 흔하게는 "다 만들고 나서야 기준에 안 맞는 걸 발견"합니다. 그리고 그때 고치려면 비쌉니다. 아주 비쌉니다.

오늘은 왜 굳이 만들기 전, 디자인 단계에서 봐야 하는지를 풀어보려 합니다. 핵심은 하나입니다. 고치는 비용은 단계가 뒤로 갈수록 폭발합니다. 그래서 제일 싼 단계, 즉 도면 단계에서 잡는 게 이득이라는 것이죠. 운영 시점(URL)이 "진짜를 확인"하는 것이라면, 설계 시점(Figma)은 "미리 싸게 거르는" 것입니다. 둘은 경쟁이 아니라 분업이라고 첫 주에 말씀드린 그대로입니다.

이번 달은 세 가지 방법을 "개요"로 한 바퀴 도는 달이니, Figma 분석이 구체적으로 어떻게 작동하는지 — 변수를 어떻게 읽고, 컴포넌트를 어떻게 대조하는지 — 하는 세부 기술은 7개월차(Figma 분석 심화)에서 따로 깊게 다룹니다. 오늘은 "왜 이 시점이 필요한가"의 큰 그림에 집중하겠습니다. 그러니 오늘 글은 가볍게, "아 만들기 전에도 같은 기준으로 볼 수 있구나" 하는 감을 잡는 정도로 읽으셔도 충분합니다.

한 가지 미리 정리하면, 지난 2주 동안 다룬 URL 분석과 이번 Figma 분석은 보는 대상 자체가 다릅니다. URL은 "다 만들어진 진짜 사이트"를 보고, Figma는 "아직 안 만든 도면"을 봅니다. 그래서 URL은 결과를 보고, Figma는 의도를 봅니다. 둘 다 똑같이 KRDS 기준에 비춰본다는 건 같은데, 비추는 대상이 시간상 앞이냐 뒤냐가 다른 것이죠. 오늘 글을 읽으시면서 "같은 기준을, 만들기 전에 미리 보는 거구나" 정도로 잡으시면 됩니다.

그런데 "디자인 단계에서 기준을 본다"는 게 막연하게 들리실 수 있습니다. 도면에서 도대체 뭘 볼 수 있다는 걸까요. 사실 Figma 같은 디자인 도구의 화면에는, KRDS 기준과 맞춰볼 정보가 생각보다 많이 들어 있습니다. 대표적인 게 색·글자·간격 같은 "디자인 토큰"입니다. 아래는 ViewCheck가 실제 디자인 파일을 표준과 대조해 보여주는 화면인데, 도면 단계에서 보는 것도 결국 이런 종류의 점검입니다.

---

본론 1 — 고치는 비용은 왜 단계마다 뛰나

도면에서 고치기 vs 다 짓고 고치기

건물 비유가 제일 쉽습니다. 도면에서 "여기 문 위치 좀 옮기자"는 지우개로 슥슥 하면 됩니다. 그런데 골조를 다 올리고 나서 문을 옮기려면 어떻게 될까요. 벽을 부수고 다시 쌓아야 합니다. 입주까지 끝난 다음이라면? 말도 안 되게 비싸집니다. 똑같은 "문 위치 변경"인데, 언제 하느냐에 따라 비용이 천차만별입니다. 도면 위에서는 연필 자국 하나였던 것이, 시간이 지날수록 사람과 장비와 돈을 잡아먹는 공사가 되는 것이죠.

소프트웨어도 정확히 같습니다. 디자인 단계에서 버튼 색을 바꾸는 건 클릭 몇 번입니다. 그런데 그게 개발까지 끝난 다음이라면, 디자인을 고치고 → 개발자가 코드를 고치고 → 테스트를 하고 → 다시 배포합니다. 사람도 여럿 붙고 시간도 듭니다. 배포까지 다 된 다음에 발견되면 더 심각합니다. 사용자가 이미 그 화면을 보고 있는 상태에서 급하게 고쳐야 하니까요. 같은 문제인데 단계가 뒤로 갈수록 비용이 몇 배, 몇십 배로 뛰는 것입니다.

여기서 한 가지 짚고 싶은 게 있습니다. "단계가 뒤로 갈수록 비싸진다"는 건 단순히 돈만의 문제가 아닙니다. 뒤로 갈수록 "관련된 사람"이 늘어납니다. 도면 단계에서는 디자이너 혼자 고치면 됩니다. 개발 단계로 넘어가면 디자이너와 개발자가 같이 움직여야 하고, 배포 후로 가면 기획자·운영 담당자·때로는 외부 개발사까지 얽힙니다. 사람이 많아질수록 조율 비용이 붙고, 일정이 밀리고, "누가 언제 뭘 바꿨는지"가 흐려집니다. 그러니까 비용 폭발은 돈의 문제이면서 동시에 "일이 커지는" 문제이기도 합니다.

"단계마다 10배"라는 경험칙

소프트웨어 업계에는 오래된 경험칙이 있습니다. 문제를 늦게 발견할수록 고치는 비용이 대략 단계마다 10배씩 커진다는 것이죠. 정확한 숫자야 상황마다 다르겠지만, 방향은 분명합니다. 일찍 잡으면 쌀수록, 늦게 잡으면 비쌀수록. 흔히 말하는 1:10:100 법칙이 바로 이것입니다. 설계에서 1이면, 개발에서 10, 배포 후에는 100이라는 것이죠.

조금 더 구체적인 장면으로 그려보겠습니다. 어떤 버튼이 기준보다 작게 디자인되었다고 해봅시다. 아무도 도면 단계에서 그걸 못 잡았고, 그대로 개발되어 수십 개 페이지에 깔린 다음에야 발견되었습니다. 디자인 컴포넌트 하나만 고치면 끝났을 일이, 이제는 페이지마다 손을 대야 하는 일이 됩니다. 이것이 "단계마다 10배"의 실제 모습입니다. 도면에서 잡았으면 1이었을 것이, 개발 후에는 10이 되고, 배포 후에는 100이 되는 것이죠. 그리고 이 곱셈은 페이지 수가 많은 공공 사이트일수록 더 무섭게 작동합니다. 페이지가 수십에서 수백 장에 이르면, "공통 부품 하나의 실수"가 곧 "수백 건의 위반"으로 복제되니까요.

그럼 왜 다들 늦게 발견할까요. 이유가 좀 얄궂습니다. 디자인 단계에서는 "아직 진짜가 아니니까" 하며 대충 넘기고, 개발 단계에서는 "기능 만들기 바빠서" 못 보고, 배포 직전에는 "일정이 급해서" 건너뜁니다. 그러다 오픈하고 나서 사용자 민원이나 외부 지적으로 터집니다. 즉 제일 싸게 잡을 수 있는 단계일수록 "아직 급하지 않다"는 이유로 미뤄지고, 제일 비싼 단계에 가서야 발등에 불이 떨어지는 것이죠. 비용 곡선과 관심 곡선이 정반대로 움직입니다. 그래서 의식적으로 "지금, 도면에서" 보지 않으면, 일은 자연스럽게 제일 비싼 타이밍으로 밀려갑니다.

이 "정반대로 움직인다"가 사실 문제의 핵심입니다. 사람은 급한 일에 반응하도록 되어 있는데, 정작 가장 싸게 고칠 수 있는 순간은 하나도 급해 보이지 않습니다. 도면은 아직 종이일 뿐이니까요. 반대로 눈앞이 급해졌을 때는 이미 고치는 값이 100으로 불어난 뒤입니다. 그러니 "급해 보이지 않는 단계에서 미리 본다"는 건 사람의 자연스러운 반응을 거스르는 일입니다. 그래서 이걸 사람의 의지에만 맡기면 잘 안 됩니다. 도구가, 만드는 그 순간에 자동으로 기준을 대조해주는 방식이 필요한 이유가 여기에 있습니다.

그리고 한 가지 덧붙이자면, 늦게 발견된 문제는 고치는 값만 비싼 게 아니라 "이미 벌어진 피해"까지 얹힙니다. 배포 후에 발견된 위반은, 발견되기 전까지 사용자가 그 불편을 그대로 겪고 있었다는 뜻입니다. 버튼이 작아 자꾸 헛눌리는 화면을, 색 대비가 낮아 잘 안 읽히는 글씨를, 그 며칠 혹은 몇 달 동안 실제 사용자가 마주하고 있었던 것이죠. 공공 사이트는 특히 그렇습니다. 대체할 창구가 없으니, 그 불편이 곧 "서비스를 못 쓰는 사람"으로 이어집니다. 도면 단계에서 잡는다는 건 고치는 값을 아끼는 것이면서, 동시에 아무도 그 불편을 겪지 않게 하는 것이기도 합니다. 아직 사용자가 그 화면을 만나기 전이니까요.

그래서 제일 싼 단계에서

결론은 단순합니다. 어차피 봐야 할 기준이라면, 제일 싼 단계인 디자인 단계에서 보는 게 이득입니다. 그게 설계 시점, 즉 Figma 분석이 존재하는 이유입니다. 나중에 비싸게 고칠 것을, 미리 싸게 거르자는 것이죠.

물론 "그럼 운영 시점은 필요 없겠네?" 하실 수 있는데, 그건 아닙니다. 디자인에서 아무리 잘 잡아도, 그게 실제로 구현될 때 또 어긋날 수 있으니까요. 도면이 완벽해도 시공에서 벽이 삐뚤어질 수 있는 것과 같습니다. 그래서 설계로 미리 거르고, 운영으로 진짜를 확인하는 두 단계가 다 필요합니다. 설계 시점은 "싸게 미리", 운영 시점은 "진짜 확인". 역할이 다릅니다. 이 둘을 하나로 합칠 수 없는 이유는, 하나는 "의도"를 보고 다른 하나는 "결과"를 보기 때문입니다. 의도와 결과가 항상 같다면 한쪽만 봐도 되겠지만, 실무에서는 그 둘 사이에 늘 틈이 벌어집니다. 그 틈이 바로 지난주에 길게 다룬 "디자인은 통과인데 배포본은 위반"의 정체입니다.

---

본론 2 — Figma 분석은 무엇을 보나

그럼 디자인 단계에서 구체적으로 뭘 볼 수 있을까요. Figma 같은 도구의 화면에는 사실 KRDS 기준과 맞춰볼 정보가 꽤 들어 있습니다. 크게 디자인 토큰, 컴포넌트, 레이아웃·구조 세 갈래로 나눠서 보겠습니다.

디자인 토큰 — 색·글자·간격

요즘 디자인은 색이나 글자 크기, 간격을 그냥 아무 값이나 쓰는 게 아니라 "정해둔 값"에서 골라 씁니다. 이걸 디자인 토큰이라고 합니다. 예를 들어 "브랜드 파랑은 이 색", "본문 글자는 이 크기", "기본 간격은 8의 배수" 이런 식으로 미리 정해두고, 디자이너가 그중에서 고르는 것이죠. 값을 매번 손으로 찍는 게 아니라, 준비된 팔레트에서 선택하는 방식입니다.

KRDS도 표준 색, 표준 글자, 표준 간격을 정해두고 있습니다. 그러니 Figma의 디자인이 그 표준 토큰을 제대로 쓰고 있는지를 대조할 수 있습니다. "이 화면이 쓴 색이 표준 색이 맞나", "글자 크기가 정해진 단계 안에 있나", "간격이 규격에 맞나". 도면 단계에서 이걸 보면, 표준 밖의 값을 미리 걸러낼 수 있습니다.

이게 왜 중요하냐면, 디자이너가 무심코 "비슷한 색"을 쓰는 일이 생각보다 잦기 때문입니다. 표준 파랑이 있는데 살짝 다른 파랑을 직접 찍어 쓰거나, 정해진 글자 크기 단계가 있는데 그 사이의 어중간한 크기를 쓰거나 하는 식이죠. 하나하나는 사소해 보입니다. 그런데 이게 화면마다 쌓이면, 사이트 전체의 색이 미묘하게 제각각이 되고 통일감이 깨집니다. 토큰 대조는 이런 "비슷하지만 표준은 아닌" 값들을 콕 집어줍니다. 사람 눈으로는 "어, 비슷한데 뭐가 문제야?" 싶은 것을, 기계는 "이건 표준 토큰이 아니다"라고 정확히 가릅니다.

여기서 "값 단위로 본다"는 게 실제로 무슨 뜻인지 한 번 짚겠습니다. 사람이 시안을 볼 때는 "이 파랑 괜찮네" 정도로 느낍니다. 느낌이죠. 그런데 도구는 그 색을 정확한 값으로 알고 있습니다. 표준 파랑의 값과 화면에 쓰인 파랑의 값을 나란히 놓고 "같다/다르다"를 딱 떨어지게 판정합니다. "비슷한 파랑"이 "표준값에서 벗어난 색"으로 바뀌는 것이죠. 글자 크기도 마찬가지입니다. "좀 큰가?"가 아니라 "정해진 단계 밖의 크기"로 나옵니다. 간격도 "좁아 보이는데"가 아니라 "8의 배수가 아닌 값"으로 나옵니다. 느낌을 값으로 바꾸는 이 과정이, 감으로 보는 검수와 근거로 보는 검수를 가르는 지점입니다. 그리고 값으로 나오니까 재현되고, 재현되니까 "여기 이 색이 표준에서 이만큼 벗어났다"는 걸 근거로 제시할 수 있습니다.

디자인 토큰이 특히 도면 단계에서 잡기 좋은 이유가 하나 더 있습니다. 색·글자·간격은 디자인의 가장 기초적인 뼈대라서, 여기가 흔들리면 그 위에 올라가는 모든 게 같이 흔들립니다. 반대로 여기를 도면 단계에서 단단히 잡아두면, 그 위에 그려지는 컴포넌트도 레이아웃도 자연스럽게 표준 안에서 움직입니다. 토큰은 말하자면 디자인의 문법 같은 것이고, 문법이 정확하면 문장도 대체로 반듯해지는 이치입니다.

컴포넌트 — 버튼·입력창 같은 부품

Figma에서는 버튼이나 입력창 같은 것을 "컴포넌트"로 만들어서 재사용합니다. 한 번 잘 만들어두고 여기저기 갖다 쓰는 것이죠. KRDS도 버튼·입력창·표 같은 컴포넌트의 규격을 정해두고 있습니다. 지난주에 본 846규칙 중 가장 큰 묶음인 컴포넌트(CP, 446개)가 바로 이 부품들의 규격을 다룹니다.

그러니 Figma의 컴포넌트가 KRDS 규격에 맞는지를 볼 수 있습니다. "버튼 크기가 충분한가(터치타겟)", "입력창에 라벨 자리가 있나", "이 컴포넌트가 표준 구조를 따르나". 특히 컴포넌트는 한 번 만들면 사방에 쓰이니까, 도면 단계에서 컴포넌트 하나를 제대로 잡아두면 그걸 쓰는 모든 화면이 같이 좋아집니다. 효율이 아주 좋은 지점입니다. 반대로 컴포넌트 하나가 잘못 잡히면, 그 잘못이 그걸 쓰는 모든 화면에 그대로 복제됩니다. 좋은 쪽으로든 나쁜 쪽으로든, 컴포넌트는 "한 번의 결정이 여러 번 반복되는" 자리입니다.

KRDS는 사실 표준 컴포넌트를 아예 키트 형태로 제공하기도 합니다. 버튼은 이렇게, 입력창은 이렇게 생긴 것을 가져다 쓰라고 말이죠. 그러니 가장 깔끔한 건 그 표준 컴포넌트를 그대로 가져다 쓰는 것이고, Figma 분석은 "우리가 쓴 게 그 표준과 같나, 아니면 비슷하게 직접 만든 거라 어딘가 어긋났나"를 봅니다. 직접 만든 컴포넌트는 겉보기엔 똑같아도 크기나 간격, 상태 처리(눌렸을 때·비활성일 때) 같은 데서 미묘하게 다른 경우가 많은데, 그런 걸 도면 단계에서 짚는 것입니다.

이 "상태 처리"는 특히 도면 단계에서 놓치기 쉬운 부분입니다. 디자이너가 버튼의 기본 모양은 잘 그려도, 마우스를 올렸을 때·눌렀을 때·비활성일 때의 모습까지 다 그려두는 경우는 의외로 적습니다. 그런데 이 상태들이 실제 사용에서는 굉장히 중요합니다. 지금 이 버튼이 눌리는 건지 아닌지, 방금 내가 누른 게 먹힌 건지 아닌지를 사용자에게 알려주는 게 바로 이 상태 변화니까요. 표준 컴포넌트를 그대로 쓰면 이 상태들이 이미 규격대로 들어 있는데, 직접 만들면 이런 세부가 빠지기 쉽습니다. 도면 단계의 대조는 "기본 모양만 있고 상태가 비어 있다" 같은 것도 짚어줄 수 있습니다.

레이아웃·구조

화면 안에서 요소들이 어떻게 배치되었는지, 정렬이 맞는지, 위계가 잡혀 있는지도 봅니다. 제목이 제목답게 크고, 본문이 본문답게 정리되어 있고, 중요한 버튼이 눈에 띄는 자리에 있는지 하는 것이죠. 이런 시각적 위계는 디자인 단계에서 잡는 게 가장 자연스럽습니다. 어차피 디자이너가 의도를 담는 단계니까요. "여기가 제일 중요하다", "이건 보조 정보다" 하는 판단이 레이아웃에 그대로 배어드는데, 그 판단이 KRDS가 말하는 정보 위계와 어긋나지 않는지를 도면에서 미리 맞춰보는 것입니다.

레이아웃은 토큰이나 컴포넌트보다 조금 더 "판단이 섞이는" 영역이기도 합니다. 색이 표준값이냐 아니냐는 딱 떨어지지만, "이 배치가 위계를 잘 표현했나"는 어느 정도 맥락이 필요하니까요. 그래서 이 부분은 기계가 명백한 것(정렬이 어긋났다, 제목이 본문보다 작다 같은 것)을 짚어주고, 그 위에서 사람이 "이건 의도된 강조다" 같은 판단을 얹는 식으로 나눠 봅니다. 뒤에서 다시 말씀드리겠지만, "단순 대조는 기계, 최종 판단은 사람"이라는 원칙이 설계 시점에서도 그대로 적용되는 자리입니다.

레이아웃과 구조를 도면 단계에서 보는 게 좋은 또 다른 이유는, 이 단계가 바로 "정보의 뼈대를 세우는" 순간이기 때문입니다. 무엇을 제목으로 삼고, 무엇을 그 아래 묶고, 어떤 순서로 읽히게 할지가 여기서 정해집니다. 이 뼈대가 반듯하면 개발에서도 그 구조가 코드의 위계로 자연스럽게 옮겨지고, 그러면 화면을 못 보는 사용자를 위한 스크린리더도 그 순서를 제대로 읽어줍니다. 반대로 도면 단계에서 위계가 흐트러지면, 겉보기엔 멀쩡해도 속 구조가 뒤엉킨 화면이 되기 쉽습니다. 그러니 레이아웃 점검은 단순히 "보기 좋으냐"를 넘어, 나중에 접근성으로 이어지는 뼈대를 도면에서 미리 반듯하게 세우는 일이기도 합니다.

다만, 도면은 도면입니다

여기서 솔직하게 짚을 게 있습니다. Figma 분석은 "의도"를 봅니다. 도면이 기준에 맞는지를 보는 것이지, 그게 실제로 어떻게 구현될지는 모릅니다. 도면이 완벽해도 시공에서 어긋날 수 있는 것과 같습니다. 그래서 Figma 분석만으로 "우리 사이트는 기준에 맞다"고 할 수는 없습니다. "우리 디자인은 기준에 맞다"까지가 정확한 표현입니다. 그 의도가 실제로 구현되었는지는 운영 시점(URL)이 확인합니다. 이 둘의 분업을 다시 떠올리시면 됩니다.

이 경계를 흐리지 않는 게 중요합니다. 지난주에 URL 분석을 두고 "공개 영역은 봤다지 다 봤다는 아니다"라고 솔직하게 선을 그었던 것과 같은 태도입니다. Figma 분석도 "디자인은 봤다"이지 "사이트는 봤다"가 아닙니다. 각 시점이 잘하는 걸 잘한다고 하고, 못 보는 건 다른 시점이 메운다고 하는 것 — 그게 세 시점을 나눠 쓰는 이유이자, 과장 없이 오래 신뢰받는 길입니다.

---

본론 3 — 디자인 단계에서 잡으면 좋은 점

비용 말고도, 디자인 단계에서 보는 게 좋은 이유가 몇 가지 더 있습니다.

① 공통 부품을 한 번에 잡습니다

방금 말씀드렸듯 컴포넌트는 한 번 만들어 여기저기 씁니다. 그래서 도면 단계에서 버튼 컴포넌트 하나를 기준에 맞게 잡아두면, 앞으로 그 버튼을 쓰는 모든 화면이 자동으로 기준에 맞습니다. 반대로 잘못 잡으면, 그 잘못이 모든 화면에 복제됩니다. 지난주에 "공통 요소 하나를 고치면 위반 여러 건이 한 번에 사라진다"고 했는데, 디자인 단계에서는 아예 그 여러 건이 생기기 전에 막는 것입니다. 운영에서 100건을 찾아 고치는 것보다, 도면에서 1건을 제대로 잡는 게 훨씬 쌉니다. 같은 효과, 다른 비용이죠.

이걸 뒤집어 생각하면 더 분명해집니다. 운영 시점에서 위반 100건을 발견했다는 건, 대개 그 100건이 서로 무관한 100개의 실수가 아니라 "공통 부품 몇 개의 실수가 100번 복제된 것"인 경우가 많습니다. 그러니 도면 단계에서 그 공통 부품 몇 개를 잡으면, 애초에 100건이 태어나지 않습니다. 문제를 사후에 100번 지우는 것과, 사전에 몇 번 막는 것. 어느 쪽이 싼지는 자명합니다.

그리고 공통 부품을 도면에서 잡아두면, 그 효과가 "이번 한 번"으로 끝나지 않습니다. 앞으로 그 컴포넌트로 새 화면을 만들 때마다 계속 기준에 맞는 화면이 나오니까요. 말하자면 한 번의 정비가 앞으로의 모든 작업에 복리처럼 쌓이는 셈입니다. 반대로 잘못 잡힌 부품을 방치하면, 새 화면을 만들수록 위반이 자동으로 늘어납니다. 그러니 공통 부품은 "가장 먼저, 가장 확실하게" 잡아야 하는 자리입니다. 여기 하나를 제대로 세워두면 뒤따르는 수고가 통째로 줄고, 여기 하나가 어긋나면 뒤따르는 수고가 통째로 늘어납니다.

② 디자이너가 의도를 담는 그 순간에

디자인 기준이라는 게, 결국 디자이너가 화면을 만드는 그 순간에 지키는 게 제일 자연스럽습니다. 다 만들어놓고 나중에 "이거 기준에 안 맞으니 바꾸세요"라고 하면, 디자이너 입장에서도 다시 작업하는 것이라 비효율이고 의욕도 떨어집니다. 이미 여러 화면에 퍼진 다음이면 되돌리는 부담도 큽니다. 그런데 만드는 김에 기준을 확인하면, 처음부터 맞게 만들 수 있습니다. 고치는 게 아니라 애초에 맞게 만드는 것 — 이게 심리적으로도, 실무적으로도 훨씬 가볍습니다.

여기엔 조직 문화 측면의 이점도 있습니다. 검수를 "다 만든 뒤 잘잘못을 따지는 자리"로 두면, 그 자리는 아무래도 지적하고 지적받는 껄끄러운 자리가 됩니다. 반면 기준 대조를 만드는 과정에 녹여두면, 그건 지적이 아니라 "작업을 돕는 안내"가 됩니다. 디자이너가 화면을 그리는 중에 "이 색은 표준 밖입니다"를 바로 알면, 누가 뭐라 하기 전에 스스로 표준 안의 색으로 바꾸면 그만이니까요. 잘못을 사후에 들추는 게 아니라, 잘못이 자리 잡기 전에 조용히 걸러지는 것입니다. 이렇게 되면 검수 회의도 "누가 틀렸나"를 따지는 자리에서 "무엇을 먼저 개선할까"를 논의하는 자리로 성격이 바뀝니다.

③ 개발자에게 깨끗한 도면을 넘깁니다

디자인이 기준에 맞으면, 개발자도 그 기준에 맞게 구현하기 쉽습니다. 애초에 도면이 표준 토큰·표준 컴포넌트로 그려져 있으면, 개발도 그 표준을 그대로 코드로 옮기면 되니까요. 반대로 도면이 제멋대로면 개발도 제멋대로가 되기 쉽습니다. 개발자는 도면을 보고 만드는데, 도면에 "여기는 표준 밖 색, 저기는 어중간한 간격"이 섞여 있으면 그걸 그대로 코드로 옮기거나, 아니면 개발자가 임의로 판단해서 바꾸게 됩니다. 어느 쪽이든 결과가 흔들립니다. 깨끗한 도면이 깨끗한 결과물의 출발점입니다. 지난주에 본 "디자인과 개발 사이의 틈"도, 도면이 명확하면 그만큼 줄어듭니다.

④ 리뉴얼·신규에서 특히 빛납니다

이 시점은 새로 만들거나 크게 개편할 때 진가를 발휘합니다. 어차피 디자인부터 새로 하는 것이니, 그 단계에서 기준을 잡으면 가장 싸게, 가장 일관되게 시작할 수 있습니다. 반대로 이미 다 만들어진 사이트에는 Figma 분석이 덜 유용합니다. 디자인 파일이 없거나 옛날 것이면 의미가 적으니까요. 그럴 때는 운영 시점(URL)이 주력이 됩니다. 상황에 따라 무게중심이 다르다는 게 여기서도 적용됩니다. 우리 상황이 "지금 도면을 그리고 있는" 쪽인지, "이미 다 지어져 돌아가는" 쪽인지에 따라 어느 시점을 앞세울지가 갈립니다.

그리고 외주를 줄 때도 이 시점이 유용합니다. 디자인 업체에 맡길 때 "KRDS 기준에 맞게"라고 말로만 하면 나중에 해석이 갈립니다. 무엇이 "맞게"인지에 대한 감이 발주처와 업체가 다르니까요. 그런데 도면 단계에서 자동으로 기준 대조를 걸면, 납품받은 디자인이 실제로 기준에 맞는지를 객관적으로 확인할 수 있습니다. "맞게 했어요"와 "확인해보니 맞다"는 다른 이야기입니다. 검수 기준이 사람 감이 아니라 자동 대조면, 업체와 발주처 사이의 소모적인 논쟁도 줄어듭니다. "여기 이 색이 표준값에서 벗어났습니다"라는 근거가 손에 있으면, "예뻐 보이는데요"와 "규격에 안 맞아요" 사이의 지루한 공방이 값 하나로 정리되니까요.

---

본론 4 — 그럼 사람이 도면을 보면 되지 않나

여기서 이번 달 첫 주의 그 질문이 또 나옵니다. "디자인 검수, 사람이 하면 되잖아?" 맞습니다. 지금도 다들 디자인 검수를 합니다. 그런데 그게 사람 손이면 첫 주에 짚었던 그 한계에 또 부딪힙니다. 도면 단계라고 해서 사람의 한계가 마법처럼 사라지는 게 아니니까요.

사람 눈은 정밀하지 않습니다

지난주에 봤듯, 사람 눈은 몇 픽셀 차이를 못 잡습니다. 색이 살짝 다른 것도, 나란히 놓지 않으면 모릅니다. 간격이 8인지 6인지 자를 대지 않으면 모릅니다. 디자인 검수 회의에서 시안을 띄워놓고 "음 괜찮네" 하는 건, 큰 문제는 잡아도 미세한 기준 위반은 놓치기 쉽습니다. 토큰이 표준에서 살짝 벗어난 것 같은 건 거의 못 잡습니다. 사람 눈은 애초에 "값을 재는" 용도로 설계된 게 아니라 "대략 파악하는" 용도로 설계되어 있어서 그렇습니다. 흠이 아니라 특성입니다. 그러니 정밀한 대조는 사람의 몫이 아니라 기계의 몫으로 넘기는 게 자연스럽습니다.

화면이 많으면 또 지칩니다

디자인도 화면이 수십 개씩 됩니다. 그걸 사람이 하나하나 기준과 대조하면, 첫 주에 짚은 그 피로·편차·누락이 똑같이 나옵니다. 앞 화면은 깐깐하게 보고 뒤 화면은 대충 보고, 어떤 건 통과 어떤 건 미통과가 사람 따라 갈리고 말이죠. 오전에 본 기준과 오후에 본 기준이 미묘하게 달라지기도 합니다. 도면 단계라고 해서 이 한계가 사라지지 않습니다. 오히려 도면은 "아직 진짜가 아니니까"라는 마음 때문에 더 느슨하게 보기 쉽습니다.

그래서 자동으로 대조합니다

그러니 디자인 단계도 사람이 눈으로만 보는 게 아니라, 기준과 자동으로 대조하는 게 낫습니다. Figma의 색·글자·간격·컴포넌트 정보를 KRDS 표준과 기계가 맞춰보는 것이죠. 사람은 그 결과 위에서 "이건 의도된 예외다", "이건 고치자" 같은 판단을 하면 됩니다. 운영 시점에서 했던 그 이야기 — 단순 대조는 기계, 판단은 사람 — 가 설계 시점에서도 똑같이 적용됩니다.

이게 Figma 분석의 핵심입니다. 도면 단계에서, 기준과 자동으로 대조해서, 사람이 놓치기 쉬운 미세한 기준 위반을 미리 잡는 것. 그래서 제일 싼 단계에서 깨끗하게 시작하게 하는 것. 기계가 대조를 맡으면 사람은 "세는 일"에서 풀려나, "판단하는 일"에 집중할 수 있습니다. 디자이너가 846개 규칙을 외워서 하나하나 대보는 대신, 자동으로 정리된 결과 위에서 "우리 화면의 방향"을 고민하게 되는 것이죠. 기계에게 반복을 맡기고 사람은 판단을 되찾는 이 구조가, 운영 시점이든 설계 시점이든 똑같이 흐르는 밑그림입니다.

---

본론 5 — 디자인 단계에서 자주 어긋나는 것들

그럼 도면 단계에서 실제로 뭐가 자주 어긋날까요. 현장에서 흔히 보는 유형 몇 가지를 짚어두면, "우리 디자인은 괜찮나"를 가늠하기 좋습니다.

① 비표준 색

제일 흔합니다. 표준 색 팔레트가 있는데 디자이너가 "이게 더 예쁜데" 하고 살짝 다른 색을 직접 쓰는 경우입니다. 한 화면만 보면 멀쩡한데, 사이트 전체로 보면 비슷비슷한 파랑이 대여섯 개씩 섞여 있습니다. 브랜드 통일감도 깨지고, 나중에 색을 한꺼번에 바꾸기도 어려워집니다. 표준 토큰을 썼다면 "브랜드 파랑" 하나만 바꾸면 전부 따라 바뀌는데, 제각각 직접 찍은 색이면 그걸 일일이 찾아 바꿔야 하니까요.

② 폰트·글자 크기 혼용

표준 글자 크기 단계가 있는데, 그 사이의 어중간한 크기를 쓰거나, 굵기를 제멋대로 섞는 경우입니다. 제목인지 본문인지 위계가 흐려지고, 읽는 사람이 정보 구조를 파악하기 어려워집니다. 특히 여러 디자이너가 나눠서 작업하면 이게 잘 생깁니다. 각자 감으로 크기를 잡으니까요. A가 만든 화면의 제목과 B가 만든 화면의 제목이 크기가 미묘하게 다르면, 사용자는 무의식적으로 "일관성이 없다"고 느낍니다.

③ 간격 제멋대로

요소 사이 간격을 8의 배수 같은 규칙 없이 그때그때 눈대중으로 잡는 경우입니다. 어떤 데는 10, 어떤 데는 13, 어떤 데는 7. 따로 보면 모르는데 모이면 화면이 어딘가 정돈 안 된 느낌을 줍니다. "아마추어 같다"는 인상의 정체가 보통 이것입니다. 사람 눈은 그 원인을 콕 집지 못하고 그냥 "뭔가 어수선하다"고만 느끼는데, 값으로 재보면 "간격이 규칙 없이 흩어져 있다"는 게 명확히 드러납니다.

④ 터치타겟이 작게

버튼이나 누르는 영역을 디자인 단계부터 작게 잡는 경우입니다. 데스크톱 큰 화면에서는 괜찮아 보여도, 모바일에서 손가락으로 누르기엔 너무 작습니다. 이건 도면에서 크기를 키워두지 않으면 개발에서도 그대로 작게 나옵니다. KRDS가 말하는 터치타겟 기준(44×44px)에 못 미치는 버튼은, 실제로 사용자가 손가락으로 자꾸 헛누르게 만듭니다. 데스크톱·태블릿·모바일 세 화면 크기를 다 상정하는 운영 시점의 반응형 점검과, 도면 단계에서 터치타겟을 미리 키워두는 설계 시점의 대조가 같은 문제를 앞뒤에서 막는 셈입니다.

⑤ 컴포넌트를 변형해서 씁니다

잘 만들어둔 표준 컴포넌트가 있는데, 화면마다 조금씩 변형해서 쓰는 경우입니다. 여기선 버튼 모서리를 둥글게, 저기선 각지게. 통일되어야 할 부품이 화면마다 달라지면, 사용자는 "같은 기능인데 왜 다르게 생겼지?" 하고 헷갈립니다. 특히 공공 사이트처럼 여러 담당자·여러 시기에 걸쳐 화면이 늘어나는 경우, 이 변형이 조용히 쌓입니다. 처음엔 컴포넌트 하나였는데, 몇 년 지나면 "비슷하지만 조금씩 다른" 버튼이 열 종류쯤 생겨 있는 식이죠.

여기서 다섯 가지에 공통으로 흐르는 성질을 하나 짚고 싶습니다. 전부 "한 화면만 보면 안 보이고, 여러 화면을 모아야 보이는" 문제라는 점입니다. 색 하나, 간격 하나, 버튼 하나만 떼어놓고 보면 다 그럴듯합니다. 문제가 드러나는 건 그것들이 사이트 전체에 걸쳐 제각각으로 쌓였을 때입니다. 그런데 사람은 화면을 한 장씩 봅니다. 그래서 "이 화면들을 통틀어 색이 몇 종류나 쓰였나", "간격 값이 규칙에서 얼마나 벗어나 흩어졌나" 같은 걸 사람이 손으로 집계하기가 거의 불가능합니다. 반면 자동 대조는 여러 화면의 값을 한꺼번에 모아 "표준 밖 색 다섯 종류, 규칙 벗어난 간격 여덟 곳" 하는 식으로 통틀어 보여줄 수 있습니다. 개별로는 안 보이던 "누적된 어긋남"이 값으로 드러나는 것이죠. 도면 단계에서 이 누적을 미리 보면, 아직 화면이 몇 장 안 될 때 바로잡을 수 있습니다. 화면이 수십 장으로 불어난 뒤에 손대는 것과는 비교가 안 되게 가볍습니다.

이 다섯 가지는 다 "사람 눈으로는 사소해 보이지만 쌓이면 문제"인 것들입니다. 그리고 다 도면 단계에서 자동 대조로 미리 잡을 수 있는 것들이기도 합니다. 만들기 전에 이 다섯만 걸러도, 나중에 비싸게 고칠 일이 확 줄어듭니다. 공교롭게도 이 다섯 가지는 운영 사이트를 URL 분석으로 돌렸을 때 미통과로 가장 많이 잡히는 유형과도 겹칩니다. 즉 운영에서 자주 터지는 문제의 씨앗이, 대부분 도면 단계에 이미 심겨 있다는 뜻입니다. 씨앗일 때 뽑는 것과, 다 자란 뒤 베어내는 것. 비용의 차이가 바로 여기서 벌어집니다.

---

본론 6 — 세 시점 안에서 Figma 분석의 자리

오늘 이야기를 세 시점의 큰 그림 안에 놓아보겠습니다. ViewCheck는 웹 품질을 세 시점에서 봅니다. 설계 시점(Figma), 운영 시점(URL), 판단 시점(LLM). Figma 분석은 이 중 가장 앞단입니다.

앞단이 든든하면 뒷단이 편합니다

가장 이상적인 그림은 이렇습니다. 디자인 단계에서 Figma 분석으로 도면을 깨끗하게 만들고 → 개발·배포 후 URL 분석으로 의도대로 구현되었는지 확인하고 → 그 위에 판단을 얹어 우선순위를 잡습니다. 설계에서 거른 게 많을수록 운영에서 잡을 게 줄고, 운영까지 깨끗하면 판단할 거리도 명확해집니다. 앞단을 잘 막을수록 뒷단이 편해지는 구조입니다.

이 흐름이 특히 잘 맞는 상황이 신규 구축과 리뉴얼입니다. 어차피 디자인부터 시작하니, 설계 시점으로 미리 거르고 배포 후 운영 시점으로 확인하는 두 단계를 시간 순서대로 밟으면 됩니다. 앞에서 도면을 깨끗하게 만들어두면, 뒤에서 URL 분석을 돌렸을 때 잡히는 위반이 훨씬 적습니다. 그러면 남은 위반들 하나하나에 사람의 판단을 더 촘촘히 얹을 수 있습니다. 반대로 앞단을 건너뛰면, 운영 시점에서 위반이 쏟아지고, 그걸 다 판단하기엔 시간이 모자라 결국 급한 것만 대충 처리하게 됩니다.

무게중심은 상황마다 다릅니다

물론 모든 사이트가 설계 시점부터 밟을 수 있는 건 아닙니다. 이미 다 만들어져 몇 년째 운영 중인 사이트라면, 디자인 파일이 없거나 실제 화면과 달라진 지 오래인 경우가 많습니다. 그럴 때는 설계 시점을 억지로 끼워 넣기보다, 운영 시점(URL)을 주력으로 삼는 게 맞습니다. 지금 실제로 돌아가는 그 화면을 있는 그대로 보는 것이죠. Figma 분석이 빛나는 건 "지금 도면을 그리고 있는" 상황입니다. 우리 상황이 어느 쪽인지부터 보고, 맞으면 도면 단계에서 챙기면 됩니다.

판정의 성격도 세 시점이 다릅니다

한 가지 더 짚어두면, 세 시점은 판정의 성격도 다릅니다. 설계 시점은 "의도가 기준에 맞나"를 봅니다. 운영 시점은 "결과가 기준에 맞나"를 봅니다. 그리고 판단 시점은 "이 결과가 우리 기관 맥락에서 얼마나 급한가"를 봅니다. 예를 들어 어떤 위반이 규칙상으로는 미통과여도, 그게 사용자가 거의 안 들어가는 페이지의 사소한 것이라면 우선순위가 낮을 수 있습니다. 반대로 신청·민원처럼 사용자가 반드시 거쳐야 하는 흐름의 위반이라면, 같은 미통과여도 훨씬 급합니다. 이 "무엇을 먼저 고칠까"의 우선순위(P0~P3 같은 위험도)는 4개월차에서, 규칙마다 무게를 다르게 두는 가중치 이야기는 3개월차에서 따로 풀겠습니다. 오늘은 "설계 시점은 의도를, 운영 시점은 결과를, 판단 시점은 맥락을 본다"는 세 갈래의 성격 차이만 잡으시면 됩니다.

세 시점이 이렇게 성격이 다르기 때문에, 하나로 합칠 수 없고 합쳐서도 안 됩니다. 설계만 보면 구현을 놓치고, 운영만 보면 이미 비싸진 다음이고, 판단만 있으면 판단할 데이터가 없습니다. 셋이 각자의 자리에서 각자의 것을 보고, 그 결과를 이어붙일 때 비로소 "우리 사이트가 KRDS 기준에 얼마나 맞나"라는 질문에 정직하게 답할 수 있습니다.

그리고 세 시점이 같은 KRDS 기준을 공유한다는 점도 중요합니다. 설계 시점에서 "표준 밖 색"이라고 짚은 것과, 운영 시점에서 "표준 밖 색"이라고 짚은 것이 같은 잣대 위에 있어야, 도면과 실물을 나란히 비교할 수 있습니다. 잣대가 서로 다르면 "도면에선 통과였는데 실물에선 왜 미통과지?"가 잣대 차이 때문인지 진짜 구현 문제 때문인지 구분이 안 됩니다. ViewCheck가 세 시점을 하나의 846규칙 위에 얹은 이유가 여기 있습니다. 같은 기준으로 보니, 설계에서 거른 것과 운영에서 잡힌 것을 같은 언어로 비교할 수 있고, 그 차이가 곧 "의도와 결과의 틈"이라는 걸 분명히 짚어낼 수 있습니다. 이 교차 비교가 실제로 얼마나 유용한지는, 도면과 실물을 나란히 놓고 보는 이번 주 수요일 사례에서 더 실감하실 수 있을 것입니다.

---

그래서 ViewCheck는

ViewCheck의 Figma 분석이 바로 이 설계 시점을 담당합니다. 디자인 파일을 KRDS 기준과 대조해서, 표준 밖 색·글자·간격이나 규격에 안 맞는 컴포넌트를 도면 단계에서 짚어줍니다. 사람이 눈으로 놓치기 쉬운 미세한 위반을, 만들기 전에 말이죠. 위에서 본 실화면들이 그 결과물입니다.

거창한 건 아닙니다. 오늘 말씀드린 "고치는 비용은 단계마다 뛴다"는 단순한 사실 위에 서 있는 것입니다. 이왕 봐야 할 기준, 제일 싼 단계에서 보자는 것. 그리고 그걸 사람 눈의 한계 없이 자동으로 대조하자는 것. 이 두 가지가 Figma 분석의 전부입니다.

물론 Figma 분석 혼자서는 "도면이 맞나"까지입니다. 그게 실제로 구현되었는지는 URL 분석(운영 시점)이, 그 위에서 우선순위·판단은 LLM 분석이 잇습니다. 세 시점이 분업한다는 그 큰 그림 안에서, Figma 분석은 "가장 앞단에서 가장 싸게 거르는" 역할입니다. 그 뒤에 어떤 규칙들이 어떻게 판정되는지 — 846규칙이 디자인 스타일(DS, 120개)·컴포넌트(CP, 446개)·기본 패턴(BP, 108개)·서비스 패턴(SP, 172개) 네 갈래로 나뉘어 어떻게 판정되는지, 그중 서비스 패턴이 왜 여러 단계를 거치는 시나리오를 보는지 — 하는 카테고리별 깊은 이야기는 5개월차에서 다룹니다.

그래서 가장 이상적인 그림은 이렇습니다. 디자인 단계에서 Figma 분석으로 도면을 깨끗하게 만들고 → 개발·배포 후 URL 분석으로 의도대로 구현되었는지 확인하고 → 그 위에 판단을 얹어 우선순위를 잡습니다. 앞에서 거른 게 많을수록 뒤가 편하다는, 오늘 내내 말씀드린 그 구조를 실제로 잇는 것입니다.

🔐 특허로 지키는 부분

오늘 본 "디자인 단계에서 색·글자·간격·컴포넌트를 표준 토큰과 자동으로 대조해, 표준 밖 값을 만들기 전에 걸러내는 방법"은 ViewCheck가 출원한 5건의 특허 중 설계 단계 디자인 토큰·컴포넌트 표준 대조, 그리고 설계·운영 시점 교차 비교 주제와 맞닿아 있습니다. 도면을 사람이 눈으로 보는 건 누구나 합니다. 차별점은, 사람 눈으로 구분되지 않는 "비슷하지만 표준은 아닌" 값을 값 단위로 대조해 도면 단계에서 짚고, 그 결과를 운영 시점 결과와 같은 기준으로 비교할 수 있게 정리한 절차를 권리로 정리해 둔 데 있습니다.

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

마무리

오늘은 설계 시점, Figma 분석의 큰 그림을 봤습니다. 핵심은 "고치는 비용은 단계가 뒤로 갈수록 폭발한다"는 것입니다. 그래서 제일 싼 단계인 디자인 단계에서, 색·글자·간격·컴포넌트가 KRDS 기준에 맞는지 미리 봅니다. 사람 눈으로는 놓치기 쉬운 미세한 위반을 자동으로 대조해서 말이죠. 단, 도면은 도면이라 실제 구현은 운영 시점이 따로 확인합니다.

한 줄로 줄이면, "이왕 볼 기준, 제일 싼 단계에서 보자"입니다. 도면 단계는 지우개로 고치는 단계이고, 그 뒤는 점점 망치와 중장비가 필요해집니다. 같은 문제라도 언제 잡느냐가 비용을 가른다는 것만 기억하시면, Figma 분석이 왜 필요한지는 충분합니다. 그리고 그 "언제"를 앞으로 당길 수 있게 해주는 게, 바로 도면을 사람 눈이 아니라 기준으로 자동 대조해 보는 설계 시점의 분석입니다.

물론 모든 사이트에 Figma 분석이 필요한 건 아닙니다. 이미 다 만들어져 운영 중인 사이트라면 디자인 파일이 없거나 의미가 없으니, 그때는 운영 시점(URL)이 답입니다. Figma 분석이 빛나는 건 새로 만들거나 크게 개편할 때, 즉 "지금 도면을 그리고 있는" 상황입니다. 우리 상황이 어느 쪽인지부터 보고, 맞으면 도면 단계에서 챙기시면 됩니다. 어느 쪽이든 정답은 하나입니다. 지금 우리가 서 있는 단계에서, 할 수 있는 가장 이른 대조를 하는 것 말이죠.

이번 주 나머지 글에서 더 구체화하겠습니다. 수요일에는 "디자인 검수는 통과했는데 개발에서 토큰이 무너진" 사례로, 왜 디자인 단계만으로는 부족하고 또 왜 디자인 단계가 중요한지를(익명으로) 양쪽에서 풀고, 금요일에는 Figma 파일에서 KRDS 준수를 실제로 어떻게 보는지 개요를 정리하겠습니다. 월·수·금을 합치면 "왜 도면을 보나 → 도면만 봐도 안 되는 이유 → 도면을 어떻게 보나"가 한 흐름으로 이어집니다. 오늘도 끝까지 읽어주셔서 고맙습니다. 수요일에 사례로 이어가겠습니다.

krds.viewcheck.co.kr