형태(Shape) 완전 해부 — KRDS 공식 기준

공공 사이트의 어느 신청 페이지를 떠올려 봅니다. 카드 몇 개가 늘어서 있고, 입력창과 버튼이 줄지어 있고, 알림 박스 하나가 위에 떠 있습니다. 별생각 없이 보면 그냥 "평범한 화면"입니다. 그런데 가만히 들여다보면 묘하게 어수선합니다. 어떤 카드는 모서리가 둥글고 어떤 카드는 각졌습니다. 버튼은 거의 동그란데 그 안의 입력창은 칼같이 직각입니다. 같은 페이지 안에서 "둥글기"가 제각각이라, 눈은 그걸 의식적으로 인지하진 못해도 어딘가 정돈되지 않았다는 인상을 받습니다. 우리는 그걸 보통 "디자인이 좀 촌스럽다" 정도로 뭉뚱그리고 넘어가죠.

그런데 그 "촌스러움"의 정체가 바로 형태(Shape)입니다. 더 정확히는, 형태에 일관된 규칙이 없어서 생긴 어수선함입니다. KRDS(대한민국 정부 디자인 시스템)는 이 형태를 "알아서 예쁘게 하세요"로 두지 않고, 색이나 타이포그래피와 똑같은 비중의 스타일 기준으로 정리해 두었습니다. 모서리를 얼마나 둥글릴지, 어떤 요소에 어떤 둥글기를 줄지, 그 둥글기들이 어떻게 한 가족처럼 어울릴지 — 이걸 디자이너 개인의 감(感)에 맡기지 않고 토큰과 규칙으로 박아 둔 겁니다.

이 글은 "KRDS 완전해부" 시리즈에서 스타일 가이드를 다루는 한 편입니다. 색·타이포·그리드처럼 형태도 디자인의 기본 골격을 이루는 요소인데, 유독 형태는 "그냥 둥글게 했어요" 한마디로 넘어가는 경우가 많습니다. 그래서 더 자주 무너집니다. 이 글에서는 KRDS가 형태에 무엇을 요구하는지, 왜 그렇게까지 따지는지, 공공웹이 어디서 자주 틀리는지, 그리고 우리 사이트가 그 기준을 지키는지 어떻게 확인하는지까지 차근차근 보겠습니다.

미리 한 가지만 일러두면, 이 글에서 말하는 "형태를 제대로 한다"는 건 "더 둥글고 트렌디하게 만든다"가 아닙니다. 오히려 절제와 일관성에 가깝습니다. 화면 안의 모든 둥글기가 같은 규칙에서 나오고, 같은 종류의 요소는 같은 형태를 갖고, 형태가 의미를 거들되 의미를 흐리지 않는 것. 디자이너에게는 다소 답답하게 느껴질 수도 있습니다. 자유롭게 모서리를 굴리고 싶은데 토큰 안에서만 놀라니까요. 하지만 공공 서비스의 목적을 떠올리면 답은 분명합니다. 우리 화면을 쓰는 사람은 디자인을 감상하러 온 게 아니라 볼일을 보러 온 국민이고, 일관된 형태는 그 볼일을 더 쉽고 덜 헷갈리게 만들어 줍니다.

형태(Shape)란 무엇인가 — 정의부터 정확히

먼저 용어를 맞추겠습니다. 디자인에서 "형태(Shape)"라고 하면 막연히 "모양 전부"를 떠올리기 쉬운데, 디자인 시스템의 스타일 요소로서의 형태는 그보다 구체적입니다. KRDS가 스타일 가이드에서 다루는 형태는 주로 UI 요소의 외곽이 어떻게 생겼는가에 관한 규칙입니다.

• 모서리 반경(border-radius): 사각형 요소의 네 귀퉁이를 얼마나 둥글릴지. 0이면 각진 직사각형, 값이 커질수록 둥글어지고, 아주 커지면 알약(pill) 모양이나 원이 됩니다.
• 형태의 종류: 사각형, 둥근 사각형, 알약형, 원형 등. 같은 버튼이라도 직각 버튼이냐 둥근 버튼이냐 알약 버튼이냐에 따라 인상이 완전히 달라집니다.
• 테두리·외곽선(border/outline): 요소의 경계를 선으로 그릴지 말지, 그린다면 두께와 스타일은 어떻게 할지.
• 형태와 상태의 관계: 같은 요소라도 평상시·호버·포커스·선택됨 같은 상태에서 형태(특히 외곽선)가 어떻게 변하는지.

이 글에서 가장 핵심은 단연 모서리 반경입니다. 형태 일관성이 무너지는 사고의 8할이 여기서 나기 때문입니다. 그래서 모서리 반경을 중심에 놓고, 나머지 형태 요소를 함께 엮어 가며 설명하겠습니다.

여기서 한 가지 짚고 넘어갈 게 있습니다. 형태는 "장식"이 아니라 "언어"입니다. 둥근 모서리는 부드럽고 친근한 느낌을, 각진 모서리는 단정하고 격식 있는 느낌을, 알약 모양은 "누를 수 있는 것"이라는 신호를 줍니다. 사용자는 이걸 의식하지 않지만 무의식적으로 읽습니다. 그래서 형태가 제각각이면 그 무의식의 신호도 뒤죽박죽이 되고, 화면 전체가 신뢰감을 잃습니다. KRDS가 형태를 토큰으로 묶어 둔 건, 이 "무의식의 언어"를 일관되게 유지하기 위해서입니다.

모서리 반경이 만드는 4가지 인상

같은 버튼인데 모서리 반경만 바꿔도 인상이 이렇게 달라집니다.

• 반경 0 (직각): 단정하고 공식적입니다. 표·데이터·문서 같은 격식 있는 맥락에 어울립니다. 다만 너무 많이 쓰면 딱딱하고 차가워 보일 수 있습니다.
• 작은 반경 (살짝 둥글게): 가장 무난하고 범용적입니다. 부드러우면서도 정돈된 인상. 공공 서비스의 입력창·카드 대부분이 이 영역입니다.
• 큰 반경 (제법 둥글게): 친근하고 캐주얼합니다. 알림 박스나 강조 카드처럼 부드러운 인상이 필요한 곳에 어울립니다.
• 완전 둥글게 (알약/원형): 칩(chip), 토글, 아이콘 버튼 같은 작은 인터랙티브 요소에 자주 씁니다. "이건 누르는 것"이라는 신호가 강합니다.

문제는 이 네 가지가 한 화면에 규칙 없이 섞일 때 생깁니다. 카드는 직각인데 그 안의 버튼은 알약이고, 입력창은 살짝 둥근데 알림 박스는 각졌다면 — 사용자의 눈은 "이 화면을 만든 사람들 사이에 합의가 없구나"를 느낍니다. KRDS는 그래서 "어떤 종류의 요소에 어떤 반경을 쓸지"를 토큰으로 정해 두라고 요구합니다.

KRDS는 형태에 무엇을 요구하나 — 기준 완전 해부

이제 본론입니다. KRDS 가이드라인(디지털 정부서비스 UI/UX 가이드라인, 2025.08판)의 스타일 가이드와 컴포넌트 킷을 기준으로, 형태가 충족해야 하는 요건을 영역별로 정리하겠습니다.

1) 형태는 토큰(token)으로 관리되어야 한다

가장 근본적인 요건입니다. KRDS는 색·타이포·간격과 마찬가지로 형태(특히 모서리 반경)를 디자인 토큰으로 정의합니다. 토큰이란 "이 값을 여기저기서 직접 쓰지 말고, 이름 붙은 변수로 정해 두고 그걸 참조하라"는 약속입니다.

쉽게 말해, CSS에 border-radius: 8px를 화면 곳곳에 직접 박아 넣는 대신, --radius-small, --radius-medium 같은 토큰을 정해 두고 그걸 쓰는 겁니다. 그러면 나중에 "전체적으로 모서리를 조금 더 둥글게 하자"는 결정이 났을 때, 토큰 값 하나만 바꾸면 사이트 전체가 일관되게 바뀝니다. 직접 박아 둔 값들은 일일이 찾아 고쳐야 하고, 그 과정에서 반드시 몇 개를 놓칩니다. 그렇게 놓친 한두 개가 바로 "형태 일관성 붕괴"의 시작입니다.

토큰으로 관리한다는 건 단순히 편의의 문제가 아닙니다. 일관성을 시스템이 강제하느냐, 사람의 기억에 의존하느냐의 차이입니다. 사람의 기억은 반드시 틀립니다. 토큰은 안 틀립니다.

2) 같은 종류의 요소는 같은 형태를 가져야 한다

이게 형태 일관성의 핵심 원칙입니다. 버튼은 버튼끼리, 카드는 카드끼리, 입력창은 입력창끼리 같은 모서리 반경을 공유해야 합니다. "이 버튼은 둥글게, 저 버튼은 각지게"가 디자인적 의도 없이 그냥 생겨 버리면, 사용자는 "둥근 버튼과 각진 버튼이 다른 기능인가?" 하고 잠깐 헷갈립니다.

형태는 사용자에게 "이것들은 같은 종류"라는 그룹핑 신호를 줍니다. 같은 형태를 공유하는 요소들은 "같은 가족"으로 묶여 인식되고, 다른 형태는 "다른 종류"로 구분됩니다. 그래서 형태를 의도 없이 섞으면, 사용자가 무의식적으로 잘못된 그룹핑을 하게 됩니다. KRDS가 컴포넌트별로 형태를 표준화해 둔 이유가 이겁니다 — 같은 컴포넌트는 어느 페이지에서나 같은 형태로 보여야 한다는 것.

3) 형태에도 위계(scale)가 있다

모서리 반경은 "하나로 통일"하는 게 아니라 "정해진 단계 안에서 선택"하는 것입니다. KRDS는 형태에도 일종의 스케일을 둡니다. 작은 반경, 중간 반경, 큰 반경, 완전 둥근 형태처럼 몇 단계로 나눠 두고, 요소의 크기와 역할에 맞게 그중 하나를 고르게 합니다.

여기에는 시각적 원리가 하나 있습니다. 요소가 클수록 모서리 반경도 어느 정도 비례해서 커야 자연스럽다는 것입니다. 작은 칩에 큰 반경을 주면 거의 원이 되어 버리고, 큰 카드에 아주 작은 반경을 주면 둥글린 게 티도 안 납니다. 형태 스케일은 이 "요소 크기와 둥글기의 조화"를 단계로 정리해 둔 것이라고 보면 됩니다. 그래서 "그냥 다 8px"이 아니라 "작은 건 작은 반경, 큰 건 큰 반경"이라는 위계가 생깁니다.

4) 형태가 의미를 거들어야 한다

형태는 단순한 미관이 아니라 정보를 전달합니다. 대표적으로 두 가지입니다.

• 누를 수 있음(affordance): 둥근 모서리, 특히 알약 형태는 "이건 클릭/터치할 수 있는 것"이라는 신호를 줍니다. 반대로 본문 텍스트 블록처럼 누르지 않는 요소에 버튼 같은 둥근 형태를 주면 사용자가 헷갈립니다.
• 요소의 성격: 알림·경고 박스는 부드러운 둥근 형태로 "정보 안내"의 톤을, 데이터 표는 각진 형태로 "정확한 기록"의 톤을 전합니다.

형태가 의미와 따로 놀면, 즉 누를 수 없는 것이 누를 수 있는 것처럼 보이거나 그 반대면, 사용자는 시행착오를 겪습니다. KRDS가 컴포넌트별 형태를 정해 두는 데에는 이 "형태=신호"의 일관성을 지키려는 의도도 있습니다.

5) 형태는 접근성과 충돌하지 않아야 한다

여기서 가장 자주 간과되는 부분이 나옵니다. 형태를 둥글리는 것 자체는 접근성과 무관해 보이지만, 외곽선·테두리·포커스 표시와 엮이는 순간 접근성 문제가 됩니다.

• 포커스 표시(focus ring): 키보드로 요소에 초점이 왔을 때 나타나는 외곽선도 형태의 일부입니다. 둥근 요소에는 둥근 포커스 링이, 각진 요소에는 각진 포커스 링이 자연스럽게 맞아야 합니다. 그런데 디자인이 지저분해 보인다고 outline: none으로 포커스 표시를 아예 지워 버리는 경우가 많습니다. 그러면 키보드 사용자는 자기가 화면 어디에 있는지 알 수 없게 됩니다.
• 테두리 대비: 형태를 구분하는 테두리가 배경과 명도 대비가 충분해야 합니다. 연한 회색 테두리를 흰 배경에 두면 저시력 사용자에게는 경계가 거의 안 보입니다. 형태가 "있긴 한데 안 보이는" 상태가 되는 거죠.
• 상태 변화의 시각적 구분: 선택됨/비활성/오류 같은 상태를 형태(테두리 두께·색)로 표현할 때, 색에만 의존하면 색 구분이 어려운 사용자가 상태를 놓칩니다. 두께·아이콘·텍스트를 함께 써야 합니다.

즉 형태는 "예쁘게 둥글리기"에서 끝나는 게 아니라, "둥글린 형태가 모든 사용자에게 명확하게 보이는가"까지 챙겨야 한다는 뜻입니다.

6) 클리핑(clipping) 주의 — 둥글린 모서리가 콘텐츠를 자르지 않게

모서리를 둥글리면, 그 안에 든 콘텐츠(특히 이미지)가 모서리 곡선을 따라 잘립니다. 이걸 의도하지 않으면 카드 안 이미지의 귀퉁이가 어색하게 잘리거나, 텍스트가 둥근 모서리에 너무 바짝 붙어 읽기 불편해집니다. 형태를 줄 때는 안쪽 여백(padding)과 콘텐츠 배치까지 함께 고려해야 합니다. 둥글기만 신경 쓰고 안쪽을 안 챙기면, 둥근 건 둥근데 내용이 답답해 보이는 결과가 나옵니다.

7) 일관성은 "사이트 안"과 "사이트 간" 둘 다

형태 일관성에는 두 층위가 있습니다.

• 사이트 내부 일관성: 같은 사이트 안에서 모든 카드가 같은 반경, 모든 버튼이 같은 반경을 갖는 것. 페이지가 달라도 일관돼야 합니다. 메인은 둥근데 신청 페이지는 각진 식의 편차는 사용자에게 "다른 사이트에 온 듯한" 혼란을 줍니다.
• 사이트 간 일관성: KRDS 표준 형태를 따르면, 다른 정부 사이트와도 형태 언어가 통일됩니다. 사용자가 A 부처 사이트에서 익힌 "이 둥근 버튼은 누르는 것"이라는 감각이 B 지자체 사이트에서도 그대로 통하는 거죠.

KRDS가 형태를 표준화하는 궁극적 목표는 이 두 번째, 사이트 간 일관성입니다. 수백 개 정부 사이트가 같은 형태 언어를 쓰면, 국민은 한 번 익힌 감각으로 모든 공공 서비스를 더 쉽게 쓸 수 있습니다.

정리하면, KRDS의 형태 기준은 크게 세 축입니다. ① 체계성(형태를 토큰으로 관리, 위계를 둘 것), ② 일관성(같은 종류는 같은 형태, 사이트 내·외부 모두), ③ 명확성(형태가 의미를 거들고, 모든 사용자에게 보이며, 접근성과 충돌하지 않을 것). 이 세 축은 그대로 ViewCheck가 형태를 판정하는 기준이기도 합니다.

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

여기까지 읽고 "모서리 둥글기 하나에 뭐 이리 까다롭나" 싶으실 수 있습니다. 그런데 형태의 일관성은 단순한 미관 취향이 아니라, 사용자가 화면을 인지하는 방식과 직결된 문제입니다.

형태는 무의식의 그룹핑 언어다

사람의 시각 인지는 비슷하게 생긴 것들을 자동으로 묶습니다(게슈탈트의 유사성 원리). 같은 형태를 가진 요소들은 "한 무리"로, 다른 형태는 "다른 무리"로 무의식적으로 분류됩니다. 그래서 형태가 일관되면 사용자는 화면 구조를 빠르게 파악합니다. "둥근 것들은 누르는 버튼, 각진 것들은 정보 카드"처럼 형태만으로 종류를 직감하는 거죠.

반대로 형태가 제각각이면 이 자동 분류가 작동하지 않습니다. 사용자는 매 요소를 일일이 따로 해석해야 하고, 그만큼 인지 부담이 늘어납니다. 본인은 "왜 피곤한지" 의식하지 못한 채, 그냥 "이 사이트는 좀 쓰기 어렵다"고 느끼게 됩니다. 형태 일관성은 이 보이지 않는 피로를 줄이는 일입니다.

형태는 신뢰의 신호다

특히 공공 서비스에서 형태의 일관성은 신뢰감과 직결됩니다. 모서리 반경이 들쭉날쭉하고 요소마다 둥글기가 다른 화면은, 내용이 아무리 정확해도 "대충 만든 사이트", "관리 안 되는 사이트"라는 인상을 줍니다. 그리고 한번 "허술하다"는 인상이 박히면, 사용자는 그 사이트가 제공하는 정보의 정확성까지 의심하기 시작합니다.

세금을 내고, 증명서를 떼고, 복지를 신청하는 곳입니다. 사용자가 "이 사이트를 믿어도 되나"를 무의식적으로 판단하는 단서 중 하나가 바로 시각적 정돈됨이고, 그 정돈됨의 큰 부분이 형태 일관성입니다. 잘 정돈된 형태는 "이 서비스는 신경 써서 만들어졌다"는 조용한 메시지를 전합니다.

형태는 누를 수 있음을 알려준다

앞서도 말했듯 형태는 affordance(행동 유도성)를 전달합니다. 둥근 알약 형태는 "누를 수 있다"는 신호이고, 각진 정보 블록은 "읽는 것"이라는 신호입니다. 이 신호가 일관되면 사용자는 설명 없이도 "어디를 누르면 되는지"를 직감합니다.

그런데 이 신호가 깨지면 어떻게 될까요. 누를 수 없는 장식 박스가 버튼처럼 둥글면 사용자는 헛클릭을 합니다. 반대로 진짜 버튼이 본문 텍스트처럼 각지고 밋밋하면 사용자는 그게 누를 수 있는 줄 모르고 지나칩니다. 디지털에 익숙하지 않은 고령 사용자일수록 이 형태 신호에 더 많이 의존하기 때문에, 형태가 의미와 어긋나면 가장 도움이 필요한 사용자가 가장 먼저 길을 잃습니다.

작은 차이라서 더 방치된다

역설적이지만, 형태처럼 "미세한" 요소일수록 품질 관리에서 밀립니다. 색이 틀리면 한눈에 보이고, 글자가 깨지면 바로 항의가 들어오지만, 모서리 반경이 2px 다른 건 아무도 버그 리포트를 올리지 않습니다. 그래서 형태 불일치는 조용히 쌓입니다. 컴포넌트를 만든 사람마다 자기 감으로 둥글기를 정하고, 외주로 만든 페이지는 또 다른 값을 쓰고, 나중에 급하게 추가한 박스는 아무 값이나 들어가고 — 그렇게 사이트 전체의 형태 언어가 서서히 무너집니다.

KRDS가 형태를 굳이 토큰으로 묶어 표준화한 건, 바로 이렇게 "작아서 방치되기 쉬운" 곳에 시스템 차원의 규칙을 박아 두기 위해서입니다. 사람이 매번 신경 쓰지 않아도 일관성이 유지되도록요.

형태는 "유행"이 아니라 "체계"여야 한다

형태에는 유독 유행을 타는 속성이 있습니다. 한때는 모든 게 각졌다가, 한때는 모든 게 둥글어졌다가, 또 한때는 알약 버튼이 대세가 됩니다. 디자이너라면 이 흐름을 모를 수 없고, 새 프로젝트를 시작할 때 자연스럽게 "요즘 스타일"을 입히고 싶어집니다. 문제는 공공 서비스가 상업 서비스처럼 1~2년마다 전면 리뉴얼을 하지 않는다는 데 있습니다. 한 번 만든 화면은 길게는 5년, 10년을 갑니다.

그래서 공공웹의 형태는 "지금 멋진 것"보다 "오래 봐도 무난한 것", "유행이 지나도 어색하지 않은 것"이 더 중요합니다. KRDS가 형태를 절제된 스케일로 정리해 둔 데에는 이 시간의 문제도 있습니다. 과도하게 둥근 트렌드를 사이트 전체에 박아 두면, 몇 년 뒤 그 사이트는 "딱 그 시절에 만든 티가 나는" 화면이 됩니다. 반면 절제된 형태 체계를 따르면, 시간이 지나도 정돈됨이 유지됩니다. 유행은 개별 요소에 살짝 반영하되, 골격이 되는 형태 토큰은 보수적으로 — 이게 오래 가는 공공 디자인의 지혜입니다.

형태 불일치는 "조직의 문제"이기도 하다

형태가 제각각인 사이트를 들여다보면, 그 뒤에 거의 항상 조직 구조가 보입니다. 메인 페이지는 본청 디자인팀이, 하위 게시판은 다른 부서가, 특정 서비스 페이지는 외주 업체가, 급하게 추가된 공지 영역은 담당 주무관이 직접 — 이렇게 여러 주체가 여러 시기에 손을 대면서 형태 언어가 갈라집니다. 각자는 자기 영역에서 최선을 다했는데, 합쳐 놓으면 어수선해지는 거죠.

이건 누구 한 사람의 잘못이 아니라 "공통 기준이 없어서" 생긴 구조적 문제입니다. 그리고 바로 그래서 형태 토큰과 디자인 시스템이 필요합니다. 모든 주체가 같은 토큰을 참조하면, 누가 언제 만들든 형태가 한 가족으로 묶입니다. 형태 일관성은 결국 "디자인 실력"의 문제라기보다 "공통 약속을 시스템으로 강제하느냐"의 문제입니다.

한 장면 — 같은 페이지, 두 가지 형태

추상적인 원리보다 한 장면이 빠를 것 같습니다. 어느 공공 서비스의 "민원 신청" 페이지가 있다고 합시다. 카드 3개, 입력창 5개, 버튼 4개, 알림 박스 1개가 들어 있는 평범한 폼 페이지입니다.

버전 A: 이 페이지를 세 명이 나눠 만들었습니다. 카드 영역을 만든 사람은 모서리를 12px로 둥글렸고, 입력창을 만든 사람은 4px로 살짝만 둥글렸고, 버튼을 만든 사람은 "요즘은 알약이 트렌드지" 하며 완전 둥근 형태로 했습니다. 알림 박스는 급하게 추가하느라 0px 직각으로 들어갔습니다. 각자 보면 다 그럴듯합니다. 그런데 합쳐 놓으니 화면이 어수선합니다. 둥근 버튼, 살짝 둥근 입력창, 더 둥근 카드, 각진 알림이 한 화면에 뒤섞여, 사용자는 의식하지 못한 채 "정돈 안 됐다"는 인상을 받습니다. 게다가 각진 알림 박스가 둥근 카드 위에 떠 있으니, 알림이 이 페이지에 원래 속한 게 아니라 어디서 붙여 온 것처럼 보입니다.

버전 B: 같은 페이지를 KRDS 형태 토큰을 기준으로 다시 만들었습니다. 카드·입력창·알림 박스는 같은 "중간 반경" 토큰을 공유하고, 작은 칩과 토글만 "완전 둥근" 토큰을 씁니다. 버튼은 컴포넌트 표준 형태를 따릅니다. 결과적으로 화면 안의 모든 둥글기가 두세 개의 정해진 값에서만 나오니, 전체가 한 가족처럼 정돈돼 보입니다. 사용자는 "잘 만든 사이트"라고 느끼지만 왜 그런지는 설명하지 못합니다. 형태 일관성은 원래 그렇게, 잘 됐을 때는 티가 안 나고 안 됐을 때만 어수선함으로 드러납니다.

같은 페이지, 같은 콘텐츠. 차이를 만든 건 거창한 기술이 아니라 "각자 감으로 둥글렸느냐, 정해진 토큰을 따랐느냐"라는 작은 선택입니다. 그리고 버전 A의 어수선함은 사람이 매번 눈으로 잡아내기 어렵기 때문에, 자동 점검이 필요한 겁니다.

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

이제 현업에서 실제로 반복되는 형태 실수들을 보겠습니다. 모두 익명화한 일반적 사례입니다(특정 기관을 지목하지 않습니다).

실수 1) 모서리 반경이 페이지마다 제각각

가장 흔한 실수입니다. 토큰 없이 그때그때 직접 값을 박아 넣어서, 같은 종류 요소인데 페이지마다 둥글기가 다릅니다.

• 나쁜 예: 메인의 카드는 16px, 소개 페이지의 카드는 8px, 신청 페이지의 카드는 4px. 같은 "카드"인데 사이트를 옮길 때마다 형태가 바뀜. 사용자는 "다른 사이트인가?" 하는 미세한 혼란.
• 올바른 예: --radius-card 같은 토큰을 하나 정해 모든 카드가 그걸 참조. 페이지가 달라도 카드는 항상 같은 형태.

실수 2) 한 화면에 둥글기가 너무 많은 종류

스케일(위계) 개념 없이, 요소마다 그때 기분대로 둥글기를 정합니다.

• 나쁜 예: 한 화면에 0px, 3px, 5px, 8px, 12px, 20px이 다 등장. 규칙이 없으니 눈이 어디에 기준을 둬야 할지 모름.
• 올바른 예: 형태 스케일을 2~4단계로 제한(예: 작은 반경 / 중간 반경 / 완전 둥근). 모든 요소가 이 단계 중 하나만 사용. 선택지가 적을수록 일관성은 강해짐.

실수 3) 요소 크기와 반경의 부조화

큰 요소에 너무 작은 반경, 작은 요소에 너무 큰 반경을 줍니다.

• 나쁜 예: 화면 가득한 큰 배너에 2px 반경 — 둥글린 티가 안 나 그냥 각져 보임. 반대로 작은 칩에 16px 반경 — 거의 원이 되어 텍스트가 잘림.
• 올바른 예: 요소 크기에 비례해 반경 선택. 큰 요소엔 큰 반경, 작은 요소엔 작은 반경. 형태 스케일이 이 비례를 가이드함.

실수 4) 누를 수 없는 것이 버튼처럼 둥글다

형태와 의미가 어긋난 경우입니다.

• 나쁜 예: 단순 정보 박스를 버튼처럼 둥글고 강조된 형태로 만들어, 사용자가 누를 수 있는 줄 알고 헛클릭. 또는 진짜 버튼이 본문처럼 밋밋해 누를 수 있는 줄 모르고 지나침.
• 올바른 예: 누를 수 있는 요소(버튼·링크·칩)와 누를 수 없는 요소(정보 박스·본문)의 형태 언어를 명확히 구분. 형태가 affordance를 정직하게 전달.

실수 5) 포커스 표시를 형태와 함께 지움

outline: none으로 포커스 링을 없애 버립니다.

• 나쁜 예: 둥근 버튼을 깔끔하게 보이려고 outline 제거. 키보드 사용자는 지금 어느 버튼에 있는지 안 보임.
• 올바른 예: 요소 형태에 맞춘 포커스 표시 유지(둥근 요소엔 둥근 포커스 링). 지우는 게 아니라 디자인과 어울리게 다듬는 것.

실수 6) 테두리 대비가 약해 형태가 안 보임

형태를 구분하는 테두리가 배경에 거의 묻힙니다.

• 나쁜 예: 흰 배경에 아주 연한 회색 테두리의 입력창. 저시력 사용자에겐 입력창 경계가 안 보여 어디에 입력하는지 모름.
• 올바른 예: 테두리와 배경의 명도 대비를 충분히 확보. 형태가 "있고, 보이는" 상태.

실수 7) 상태를 형태(색)로만 표시

선택됨/오류 상태를 테두리 색만 바꿔 표현합니다.

• 나쁜 예: 선택된 카드를 파란 테두리로만 구분. 색 구분이 어려운 사용자는 어느 게 선택됐는지 모름.
• 올바른 예: 테두리 색 + 두께 변화 + 체크 아이콘/텍스트를 함께. 형태 변화를 색 외 신호로도 보강.

실수 8) 둥근 모서리가 콘텐츠를 어색하게 자름

클리핑을 고려하지 않습니다.

• 나쁜 예: 둥근 카드 안에 꽉 찬 이미지를 넣었는데 안쪽 여백 없이 텍스트가 둥근 모서리에 바짝 붙어 읽기 불편. 또는 이미지 귀퉁이가 어색하게 잘림.
• 올바른 예: 형태에 맞춰 안쪽 여백을 확보하고, 이미지·콘텐츠가 둥근 모서리와 조화롭게 배치되도록 설계.

실수 9) 외주·레거시 페이지의 형태 따로 놀기

여러 시기에 여러 업체가 만들어 형태 규칙이 섞입니다.

• 나쁜 예: 메인은 최신 둥근 스타일, 하위 게시판은 옛날 각진 스타일. 같은 사이트인데 영역마다 시대가 다름.
• 올바른 예: 전사 형태 토큰을 한 번 정하고, 레거시 영역도 우선순위에 따라 점진적으로 토큰 기준에 맞춰 통일.

실수 10) 형태를 강조라고 착각해 과하게 둥글림

"이 카드가 중요하니 더 눈에 띄게" 하려고 모서리를 과하게 둥글립니다.

• 나쁜 예: 강조하고 싶은 카드만 모서리를 20px 이상으로 크게 둥글려, 옆 카드들과 따로 노는 "튀는 형태"가 됨. 강조는 됐지만 일관성이 깨짐.
• 올바른 예: 강조는 형태가 아니라 색·그림자·크기·위치로. 형태는 같은 종류끼리 통일하고, 강조가 필요하면 다른 시각 수단을 씀. 형태를 강조 도구로 남용하면 형태 언어 전체가 흔들림.

실수 11) 중첩된 요소의 안팎 반경이 안 맞음

카드 안에 또 다른 박스(이미지·버튼)가 들어갈 때 안팎 둥글기가 어긋납니다.

• 나쁜 예: 둥근 카드 안에 꽉 차는 이미지를 직각으로 넣어, 카드 모서리와 이미지 모서리 사이에 어색한 직각 틈이 생김.
• 올바른 예: 바깥 요소가 둥글면 안쪽 요소의 모서리도 그에 맞게(보통 바깥보다 약간 작은 반경) 조정. 안팎이 동심원처럼 자연스럽게 겹치도록 설계.

실수 12) 호버·포커스에서 형태가 갑자기 변함

상호작용 시 모서리 반경이 튀게 바뀝니다.

• 나쁜 예: 평상시엔 각진 버튼이 마우스를 올리면 갑자기 알약으로 변함. 형태가 출렁여 산만하고, 클릭 위치 예측이 어려워짐.
• 올바른 예: 상태가 바뀌어도 기본 형태(반경)는 유지하고, 변화는 색·테두리 두께·그림자로 표현. 형태는 안정적으로 두는 게 원칙.

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

KRDS의 좋은 점은, 위 요건들을 "알아서 잘하세요"로 끝내지 않고 바로 쓸 수 있는 자산으로 제공한다는 것입니다.

개발자라면 — KRDS 컴포넌트 킷을 npm install krds-uiux로 설치하거나 CDN(krds.min.css / krds.min.js)으로 불러오면, 형태 토큰이 이미 정의된 상태로 시작할 수 있습니다. 핵심 습관은 단 하나입니다. 모서리 반경을 코드에 직접 박지 말고, 정의된 토큰(CSS 변수)을 참조하라. border-radius: 8px 대신 border-radius: var(--krds-radius-medium) 같은 식으로요. 이 한 가지 습관만 지켜도 형태 일관성 문제의 대부분이 애초에 생기지 않습니다. 그리고 포커스 표시는 지우지 말고(outline을 없앴다면 형태에 맞는 대체 스타일 제공), 테두리는 배경과 대비를 충분히 확보하세요. 이 항목들은 공통 컴포넌트로 한 번 잡아 두면 이후엔 자동으로 따라옵니다.

디자이너라면 — KRDS 공식 Figma(@krds) 라이브러리에서 형태 스타일이 적용된 컴포넌트를 그대로 가져다 쓸 수 있습니다. 직접 사각형을 그려 매번 모서리를 굴리지 말고, 표준 컴포넌트를 배치하면 디자인 단계에서부터 형태 토큰이 지켜집니다. 새 요소를 만들 때도 "이 둥글기가 기존 스케일 안에 있는가"를 먼저 확인하세요. 임의의 값을 새로 만드는 순간 일관성에 균열이 갑니다. 형태는 "내가 정하는 것"이 아니라 "정해진 단계에서 고르는 것"이라는 감각이 중요합니다.

기획자라면 — 화면 정의서에 "카드", "버튼"이라고만 적지 말고, 그 요소가 "누를 수 있는지(인터랙티브인지)"를 함께 명시하세요. 형태는 affordance를 전달하므로, 누를 수 있는 요소와 없는 요소가 명확히 구분돼야 디자인·개발 단계에서 형태를 올바르게 매길 수 있습니다. 이 한 줄이 "정보 박스가 버튼처럼 보이는" 혼란을 막습니다.

5분 셀프 점검 — 지금 바로 해보기

거창한 도구 없이도, 지금 우리 사이트에서 형태를 직접 점검해 볼 수 있습니다. 순서대로 해보세요.

1. 카드를 모아 보세요. 메인·목록·신청·게시판 페이지의 카드들을 나란히 캡처해 비교합니다. 모서리 둥글기가 같나요? 페이지마다 다르면 1번 문제(사이트 내부 불일치)입니다.

2. 한 화면의 둥글기 종류를 세어 보세요. 한 페이지 안에서 서로 다른 모서리 반경이 몇 종류나 쓰였는지 눈으로 세어 봅니다. 네 종류를 넘어가면 스케일이 없다는 신호입니다.

3. 마우스를 치우고 Tab만으로 화면을 훑어 보세요. 버튼·링크·입력창에 초점이 갈 때 포커스 표시가 또렷이 보이나요? 안 보이면 outline을 지운 것입니다(치명적).

4. 화면을 흑백으로 보세요(운영체제의 색 필터). 선택된 카드나 오류 입력창이 색 없이도 구분되나요? 안 되면 형태 상태를 색으로만 표시한 것입니다.

5. 누를 수 있는 것과 없는 것을 형태만 보고 구분해 보세요. 정보 박스가 버튼처럼 보이거나, 진짜 버튼이 밋밋해 안 눌릴 것 같으면 형태가 의미와 어긋난 겁니다.

이 다섯 가지만 해봐도 대부분의 형태 문제가 드러납니다. 다만 페이지가 많아지면 사람이 다 보기 어렵습니다 — 그때 ViewCheck로 전 페이지를 한 번에 점검하면 됩니다.

그래서 우리 사이트는? — ViewCheck로 5분 점검

여기까지가 KRDS의 형태 기준입니다. 그런데 정작 어려운 건 "그래서 우리 사이트의 형태는 이걸 지키고 있나?"를 확인하는 일입니다. 페이지마다 카드·버튼·입력창의 모서리 반경이 일관된지, 둥글기 종류가 너무 많지 않은지, 포커스 표시가 살아 있는지를 사람이 일일이 눈으로 비교하려면 끝이 없습니다. 페이지가 수십·수백 개인 공공 사이트라면 더더욱요.

ViewCheck(krds.viewcheck.co.kr)는 이 점검을 자동화합니다. URL만 넣으면 페이지를 실제로 크롤링해서, 형태를 포함한 디자인 스타일이 KRDS 기준을 지키는지 판정합니다. 형태(Shape)는 KRDS 846규칙 중 디자인 스타일(DS) 규칙군 120개에 속하고, 분석 결과의 디자인 시스템(Design System) 탭에서 확인할 수 있습니다.

ViewCheck가 형태에 대해 자동으로 보는 것들:

• 모서리 반경의 일관성: 같은 종류 요소(카드·버튼·입력창 등)가 일관된 반경을 쓰는지, 한 화면에 둥글기 종류가 과도하게 많지 않은지
• 디자인 토큰 채택률: 형태 값이 KRDS 토큰 체계에 맞게 쓰였는지, 임의의 값이 직접 박혀 있는지(KRDS HTML Kit의 토큰과 대조)
• 테두리·외곽선 대비: 형태를 구분하는 테두리가 배경과 충분한 명도 대비를 갖는지(대비 분석과 연계)
• 포커스 표시 유지: 인터랙티브 요소의 포커스 표시가 형태에 맞게 살아 있는지(접근성 항목과 연계)

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

리포트를 어떻게 읽나

분석이 끝나면 디자인 시스템 탭에서 형태 관련 규칙의 통과/미통과 수와, 미통과한 항목의 위치(어느 페이지)·이유·개선 방법(howToFix)이 함께 나옵니다. 예를 들어 "신청 페이지의 카드 모서리 반경이 다른 페이지와 다름"이나 "버튼 형태가 토큰을 따르지 않고 임의 값 사용"처럼 구체적으로요. 여러 페이지를 한꺼번에 분석하면, "메인의 카드는 토큰을 따르는데 게시판 페이지만 제각각" 같은 페이지별 편차도 한눈에 드러납니다.

특히 ViewCheck의 디자인 토큰 채택률 리포트는 형태 점검의 핵심 도구입니다. 우리 사이트가 형태 값을 얼마나 토큰 기반으로 쓰는지를 수치로 보여 주기 때문에, "토큰을 도입했다고 생각했는데 실제로는 절반만 적용됐다" 같은 현실을 직시하게 됩니다. 그리고 어디부터 고쳐야 하는지 우선순위(P0~P3)도 함께 매겨지니, 한정된 시간에 가장 중요한 것부터 손볼 수 있습니다.

무료 진단으로 우리 사이트 메인부터 한 번 돌려 보면, 손으로는 몇 시간 걸릴 형태 점검이 몇 분 만에 끝납니다. 그리고 그 결과는 막연한 "정돈하자"가 아니라, "이 페이지의 이 요소 반경을 토큰에 맞추자"는 구체적인 작업 목록이 됩니다.

자주 묻는 질문

현장에서 형태를 다룰 때 반복해서 나오는 질문들을 모았습니다.

Q. 모서리를 둥글게 하는 게 무조건 좋은 건가요?

아닙니다. "둥글면 트렌디하다"는 건 절반만 맞는 얘기입니다. 형태는 맥락에 맞아야 합니다. 정확한 데이터를 보여 주는 표나 격식 있는 공문 영역은 오히려 각진 형태가 더 어울립니다. 핵심은 "둥글기/각짐"의 선택이 아니라 "그 선택이 일관되고 의미에 맞는가"입니다. 모든 걸 다 둥글린다고 좋은 디자인이 되는 게 아니라, 같은 종류는 같은 형태로, 형태가 의미를 거들도록 하는 게 좋은 디자인입니다.

Q. 디자인 토큰이라는 게 꼭 필요한가요? 그냥 다 8px로 통일하면 안 되나요?

"다 8px로 통일"하는 것도 토큰 정신의 일부입니다. 다만 현실에서는 모든 요소에 같은 반경이 어울리지 않습니다. 큰 카드와 작은 칩에 같은 8px을 주면 칩은 너무 각져 보이거든요. 그래서 보통 2~4단계의 토큰(작은/중간/큰/완전 둥근)을 두고 요소에 맞게 고릅니다. 그리고 토큰의 진짜 가치는 "나중에 한 번에 바꿀 수 있다"는 데 있습니다. 직접 박아 둔 값은 사이트가 커질수록 손댈 수 없게 됩니다.

Q. 이미 운영 중인 사이트인데, 형태를 전부 다시 맞춰야 하나요?

전부 갈아엎을 필요는 없습니다. 먼저 ViewCheck로 "지금 형태가 어디서 어떻게 어긋나 있는지"를 목록으로 만든 다음, 사용 빈도가 높은 핵심 경로(메인·신청·로그인·검색)의 형태부터 토큰 기준으로 맞추세요. 형태 불일치는 대개 한 번에 다 고치기보다, 토큰을 먼저 정의해 두고 새로 만드는 것부터 토큰을 쓰고 레거시는 점진적으로 교체하는 게 현실적입니다.

Q. 모서리 반경이 2~3px 다른 것까지 정말 신경 써야 하나요?

하나만 보면 티가 안 납니다. 그런데 그런 미세한 차이가 화면 곳곳에 쌓이면, 사용자는 "왜인지 모르게 정돈 안 됐다"는 인상을 받습니다. 형태 일관성은 개별 요소가 아니라 화면 전체의 누적 효과로 작동하거든요. 다만 우선순위는 분명히 있습니다. 2~3px 차이보다, 같은 종류 요소가 완전히 다른 형태(직각 vs 알약)인 게 훨씬 큰 문제입니다. 작은 것부터 다 잡으려 하지 말고 큰 불일치부터 잡으세요.

Q. 형태는 디자이너 일 아닌가요? 개발자가 왜 신경 써야 하죠?

형태는 디자인에서 정의하지만 코드에서 무너집니다. 디자이너가 시안에서 깔끔하게 토큰을 정해도, 개발 단계에서 border-radius를 직접 박아 버리면 그 순간 토큰 체계가 깨집니다. 그래서 형태 일관성은 디자인과 개발의 합작입니다. 디자이너는 토큰을 정의하고, 개발자는 그 토큰을 코드에서 참조하고, 기획자는 어떤 요소가 인터랙티브인지 명시해야 합니다. 셋 중 하나만 어긋나도 형태는 무너집니다.

Q. 포커스 표시(outline)가 디자인을 망치는데, 정말 못 지우나요?

지우는 게 아니라 다듬는 겁니다. 기본 브라우저 포커스 링이 투박해 보일 수는 있지만, 그렇다고 outline: none만 하고 대체 스타일을 안 주면 키보드 사용자는 화면 어디에 있는지 알 수 없게 됩니다. 요소의 형태에 맞춰(둥근 요소엔 둥근 포커스 링) 디자인과 어울리는 포커스 스타일을 직접 만들어 주면, 깔끔함과 접근성을 둘 다 잡을 수 있습니다.

Q. KRDS 형태 토큰을 안 쓰고 우리만의 토큰을 만들면 안 되나요?

사이트 내부 일관성만 보면 자체 토큰도 일관되기만 하면 됩니다. 다만 KRDS가 형태를 표준화하는 더 큰 목적은 "사이트 간 일관성"입니다. 국민이 여러 정부 사이트를 오갈 때 같은 형태 언어를 만나면 학습 비용이 줄어듭니다. 가능하면 KRDS 표준 형태를 따르는 게, 우리 사이트뿐 아니라 공공 서비스 전체의 사용성에 기여하는 길입니다.

Q. 형태와 그림자(shadow)는 다른 건가요?

다릅니다. 형태는 요소의 외곽(반경·테두리)에 관한 것이고, 그림자(elevation)는 요소가 떠 있는 정도를 표현하는 별개의 스타일 요소입니다. 다만 둘은 함께 작동해 요소의 성격을 전합니다. 둥근 형태 + 적절한 그림자는 "떠 있는 누를 수 있는 카드"라는 신호를 함께 만들죠. 이 글은 형태에 집중했지만, 실제로는 형태·그림자·색·간격이 함께 어우러져야 완성된 컴포넌트가 됩니다.

Q. 디자이너와 개발자가 보는 모서리 값이 자꾸 어긋납니다. 왜 그럴까요?

가장 흔한 원인은 "중간 매개가 토큰이 아니라 픽셀 숫자"이기 때문입니다. 디자이너가 시안에서 "여기 8px"이라고 말로 전달하면, 개발자는 그 숫자를 코드에 직접 박습니다. 그러면 디자인이 바뀔 때마다 숫자가 어긋나고, 어느 게 최신인지 아무도 모르게 됩니다. 해법은 양쪽이 같은 토큰 이름을 보는 것입니다. 디자이너의 Figma 변수와 개발자의 CSS 변수가 같은 이름(예: radius-medium)을 가리키면, "8px이냐 12px이냐"를 매번 확인할 필요 없이 토큰 이름만 맞추면 됩니다. KRDS가 Figma와 코드 킷을 한 세트로 제공하는 이유가 이겁니다.

Q. 모바일과 데스크톱에서 형태를 다르게 줘도 되나요?

요소 크기가 달라지면 반경도 비례해 조정하는 게 자연스럽습니다. 다만 "달라도 된다"가 "마음대로 해도 된다"는 뜻은 아닙니다. 모바일에서도 형태 스케일과 토큰 체계는 그대로 유지하되, 그 안에서 크기에 맞는 단계를 고르는 식이어야 합니다. 예를 들어 데스크톱에서 중간 반경을 쓰던 카드가 모바일에서 작아지면 작은 반경 토큰으로 내려가는 식으로요. 체계 안에서의 조정은 괜찮지만, 체계를 벗어난 임의 값은 모바일에서도 일관성을 깹니다.

Q. 모든 모서리를 다 둥글려야 하나요, 일부만 둥글려도 되나요?

일부 모서리만 둥글리는 디자인(예: 위쪽 두 모서리만 둥근 탭)도 있고, 그 자체가 잘못은 아닙니다. 다만 그것도 "의도와 일관성"이 있어야 합니다. 탭처럼 특정 패턴에서 일부만 둥글리는 건 그 패턴 전체에 일관되게 적용해야지, 어떤 탭은 위만 둥글고 어떤 탭은 다 둥근 식이면 또 불일치가 됩니다. 부분 둥글림도 결국 "같은 종류는 같은 형태" 원칙 안에서 다뤄야 합니다.

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

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

가장 먼저(치명적) — 형태가 접근성을 막는 경우. 포커스 표시가 지워져 키보드 사용자가 위치를 알 수 없거나, 테두리 대비가 약해 입력창 경계가 안 보이는 문제입니다. 이건 특정 사용자에게 기능을 실질적으로 차단하므로 1순위입니다. 신청·로그인처럼 핵심 경로에 있다면 더더욱 먼저 손봐야 합니다.

그다음(높음) — 형태가 의미와 어긋난 경우. 누를 수 없는 것이 버튼처럼 보이거나, 진짜 버튼이 누를 수 없는 것처럼 밋밋한 경우. 사용자를 시행착오에 빠뜨리고, 특히 디지털 약자에게 장벽이 됩니다. 상태(선택됨·오류)를 형태 색으로만 표시하는 것도 여기 포함됩니다.

그 후(보통) — 같은 종류 요소의 형태 불일치. 카드·버튼이 페이지마다 다른 반경을 쓰거나, 한 화면에 둥글기 종류가 과도하게 많은 경우. 작동에는 문제없지만 정돈됨과 신뢰감을 떨어뜨립니다.

여력이 되면(낮음) — 토큰 채택률을 높여 형태 체계를 정비하기, 레거시 영역의 형태를 표준으로 통일하기, 요소 크기와 반경의 비례 다듬기 같은 작업. 당장 막는 건 아니지만 디자인 완성도를 한 단계 끌어올리는 항목입니다.

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

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

이 글은 KRDS의 형태(Shape) 기준을 실무 관점에서 풀어 쓴 것입니다. 정확한 원문 기준과 코드·디자인 자산은 아래 공식 자료에서 직접 확인하실 수 있습니다.

• KRDS 가이드라인 PDF(디지털 정부서비스 UI/UX 가이드라인, 2025.08판) — 스타일과 컴포넌트 정의·사용 원칙의 1차 원천.
• KRDS 스타일 가이드(웹) — 형태(Shape)의 정의와 예시를 화면으로 확인.
• KRDS 컴포넌트 킷(GitHub) — 형태 토큰이 적용된 컴포넌트 코드를 그대로 사용(npm install krds-uiux 또는 CDN).
• KRDS 공식 Figma(@krds) — 디자이너용 형태 스타일과 컴포넌트.

공식 자료는 "정답지"이고, ViewCheck는 "내 답안을 채점해 주는 도구"라고 생각하시면 됩니다. 둘을 함께 쓰면, 기준을 이해하고(가이드라인) → 내 사이트가 그 기준에 맞는지 확인하고(ViewCheck) → 검증된 토큰·컴포넌트로 고치는(킷·Figma) 한 바퀴가 완성됩니다.

오늘의 체크리스트 — 형태(Shape), 이것만은

마지막으로, 디자이너·개발자·기획자가 형태를 만들거나 검수할 때 바로 쓸 수 있는 체크리스트로 정리합니다.

• ☐ 모서리 반경을 코드에 직접 박지 않고 토큰(CSS 변수)으로 관리한다.
• ☐ 같은 종류 요소(카드·버튼·입력창)는 같은 반경을 공유한다(페이지가 달라도).
• ☐ 한 화면의 둥글기 종류를 2~4단계로 제한한다(스케일/위계가 있다).
• ☐ 요소 크기와 반경이 비례한다(큰 요소엔 큰 반경, 작은 요소엔 작은 반경).
• ☐ 형태가 의미를 정직하게 전한다(누를 수 있는 것만 버튼처럼 둥글다).
• ☐ 포커스 표시가 형태에 맞게 살아 있다(outline: none으로 지우지 않았다).
• ☐ 형태를 구분하는 테두리가 배경과 충분한 대비를 갖는다.
• ☐ 상태(선택됨·오류)를 색으로만 표시하지 않는다(두께·아이콘·텍스트 병행).
• ☐ 둥근 모서리가 콘텐츠를 어색하게 자르지 않는다(안쪽 여백 확보).
• ☐ 가능하면 KRDS 표준 형태 토큰을 따른다(사이트 간 일관성).

KRDS 컴포넌트 킷(npm install krds-uiux 또는 CDN)을 쓰면 위 항목 대부분이 이미 토큰으로 구현된 상태로 시작할 수 있습니다. 직접 만들다 형태를 흩뜨릴 위험을 줄이는 가장 확실한 방법이죠. 공식 Figma 라이브러리(@krds)에서는 디자이너가 형태 스타일이 적용된 컴포넌트를 그대로 가져다 쓸 수 있습니다.

형태는 색이나 글자처럼 한눈에 도드라지지 않습니다. 그래서 "사소하다"고 넘기기 쉽지만, 사실은 화면 전체의 인상과 신뢰감을 조용히 좌우합니다. 모서리 하나의 둥글기는 미세하지만, 그 미세함이 화면 곳곳에 일관되게 쌓이면 "잘 만든 사이트"의 정돈됨이 되고, 제각각으로 쌓이면 "관리 안 되는 사이트"의 어수선함이 됩니다.

오늘 정리한 기준이 거창해 보일 수 있지만, 핵심은 결국 단순합니다. 둥글기를 토큰으로 관리하고, 같은 종류는 같은 형태로 묶고, 형태가 의미를 거들게 하고, 그 형태가 모든 사용자에게 보이도록 챙기는 것. 이 네 가지만 지켜도 형태 위반의 대부분은 사라집니다. 그리고 그게 잘 됐는지는 ViewCheck로 몇 분이면 확인할 수 있습니다. 완벽을 한 번에 만들 필요는 없습니다. 토큰 하나를 정의하고, 가장 어긋난 형태 하나부터 맞춰 나가면, 우리 사이트는 분명히 조금씩 더 정돈되고 더 믿음직해집니다.

이번 시리즈는 KRDS를 항목 하나하나 이렇게 뜯어보는 긴 여정입니다. 형태처럼 "작아서 넘기기 쉬운" 요소까지 굳이 한 편을 들인 건, 바로 그런 곳에서 디자인 시스템의 진가가 드러나기 때문입니다. 다음 글에서는 형태와 짝을 이루는 또 다른 스타일 요소를 같은 방식으로 — 공식 기준이 무엇이고, 어디서 틀리고, 어떻게 확인하는지 — 차근차근 살펴보겠습니다.

우리 사이트의 형태는 지금 얼마나 정돈돼 있을까요? krds.viewcheck.co.kr에서 URL만 넣으면 무료로 확인할 수 있습니다. 메인 페이지 하나만 돌려 봐도, 모서리 반경이 토큰을 따르는지, 형태가 페이지마다 제각각은 아닌지 디자인 시스템 탭에서 바로 보입니다.

#KRDS #공공웹 #디자인시스템 #형태Shape #모서리반경 #웹접근성 #디자인토큰 #ViewCheck #정부웹사이트 #UIUX #형태 #Shape #KRDS기준 #디자인원칙 #표준가이드 #디자인스타일 #전자정부 #디지털정부 #행정안전부 #공공기관