형태(Shape) — 공공웹이 자주 틀리는 지점

공공 사이트를 하나 열어 두고, 화면 안에 있는 "네모"를 한번 세어 보세요. 버튼, 입력창, 카드, 배너, 검색 박스, 탭, 알림 띠… 의외로 화면의 대부분이 크고 작은 사각형으로 채워져 있습니다. 그리고 그 사각형들의 모서리를 자세히 보면, 어떤 건 칼처럼 각졌고, 어떤 건 살짝 둥글고, 어떤 건 알약처럼 완전히 굴려져 있습니다. 같은 페이지 안에서요. 처음엔 잘 안 보입니다. 그런데 한번 눈에 들어오기 시작하면, 이상하게 거슬립니다. "왜 이 버튼은 둥근데 바로 옆 버튼은 각졌지?"

이게 바로 형태(Shape)의 문제입니다. 색이나 글자처럼 대놓고 드러나지는 않지만, 화면 전체의 "정돈된 느낌"을 결정하는 건 사실 이 형태의 일관성입니다. 잘 맞으면 아무도 칭찬하지 않고, 안 맞으면 누구나 "어딘가 어수선하다"고 느끼는 — 딱 그런 자리에 형태가 있습니다.

저는 공공 웹사이트를 수백 개 분석하면서, 형태에서 똑같은 실수가 끝없이 반복되는 걸 봤습니다. 모서리 반경(border-radius)이 페이지마다 제각각이고, 같은 종류의 버튼인데 페이지를 옮기면 모양이 달라지고, 디자인 시안에는 분명히 둥근 카드였는데 개발된 화면에선 각진 카드가 되어 있고. 색이 틀리면 바로 지적이 들어오는데, 형태가 틀리면 아무도 모른 채 그냥 배포됩니다. 그래서 형태는 "가장 조용히 무너지는" 디자인 요소입니다.

이 글은 "KRDS 완전해부" 시리즈 중 하나로, 공공웹이 형태에서 가장 자주 틀리는 지점을 익명 사례 중심으로 뜯어보는 글입니다. KRDS(대한민국 정부 디자인 시스템)가 형태를 어떻게 정의하고 무엇을 요구하는지 짚되, 무게 중심은 "현업에서 실제로 어디서 무너지는가"에 둡니다. 특정 기관을 지목하지 않고, 제가 분석하며 반복해서 만난 일반적인 패턴들을 일반화해서 보여 드리겠습니다. 다 읽고 나면, 앞으로 어떤 사이트를 보든 "여기 모서리들이 안 맞네"가 눈에 들어오실 겁니다. 그리고 우리 사이트는 괜찮은지, 5분 만에 확인하는 방법까지 함께 알려 드리겠습니다.

형태(Shape)가 대체 뭘 말하는 건가 — 정의부터

먼저 용어부터 맞추겠습니다. "형태"라고 하면 막연하니, 이 글에서 다루는 형태가 구체적으로 무엇인지부터 정리하겠습니다.

KRDS의 스타일 가이드에서 형태(Shape)는 UI 요소의 모서리 처리와 외곽 형태에 관한 약속입니다. 쉽게 말해 "네모의 모서리를 얼마나 둥글릴 것인가", "요소의 겉모양을 어떤 형태로 통일할 것인가"를 정해 두는 영역이죠. 색(Color)이 "무슨 색을 쓸 것인가", 타이포그래피(Typography)가 "어떤 글자를 쓸 것인가"를 정한다면, 형태(Shape)는 "겉모양을 어떻게 다듬을 것인가"를 정합니다.

형태가 다루는 대표적인 것들을 풀어 보면 이렇습니다.

• 모서리 반경(border-radius): 버튼·카드·입력창 같은 사각형 요소의 모서리를 얼마나 둥글릴지. 0(완전 각짐)부터 시작해서 살짝 둥근 것, 많이 둥근 것, 완전히 굴려 알약 모양이 되는 것까지.
• 형태의 위계: 작은 요소는 살짝 둥글게, 큰 요소는 좀 더 둥글게 — 식의 크기별 규칙. 무작정 다 똑같이 둥글리는 게 아니라, 요소의 크기와 역할에 맞는 형태가 있다는 개념입니다.
• 형태의 일관성: 같은 종류의 요소(예: 모든 기본 버튼)는 페이지가 바뀌어도 같은 형태를 유지해야 한다는 원칙.

여기서 핵심은 형태가 "감각적으로 예쁘게"의 문제가 아니라 "규칙으로 정해 두고 일관되게 지키는"의 문제라는 점입니다. KRDS가 형태를 스타일 가이드의 독립된 항목으로 둔 이유가 이겁니다. 모서리 반경을 디자이너 개개인의 그날그날 기분에 맡기지 말고, 정해진 값(토큰)을 쓰라는 거죠.

디자인 토큰으로서의 형태

조금 더 들어가 보겠습니다. KRDS는 색·타이포·간격과 마찬가지로, 형태도 디자인 토큰(design token)으로 관리하도록 설계되어 있습니다. 토큰이란 쉽게 말해 "이름이 붙은 디자인 값"입니다. 예를 들어 모서리 반경을 코드에 8px이라고 직접 쓰는 게 아니라, radius-medium 같은 이름으로 정의해 두고 그 이름을 가져다 쓰는 방식이죠.

이게 왜 중요하냐면, 토큰을 쓰면 형태가 한 곳에서 관리되고, 전 화면에 일관되게 적용되기 때문입니다. "기본 버튼의 모서리는 이 값"이라고 한 번 정해 두면, 그 토큰을 쓴 모든 버튼이 자동으로 같은 형태가 됩니다. 반대로 토큰 없이 페이지마다 개발자가 border-radius를 손으로 입력하면, 같은 버튼인데도 4px, 6px, 8px이 뒤섞이게 됩니다. 형태 일관성이 무너지는 가장 흔한 경로가 바로 이 "손으로 직접 입력"입니다.

이 글의 뒤에서 다룰 ViewCheck도 바로 이 지점을 봅니다. 우리 사이트가 정해진 형태 토큰을 쓰고 있는지, 아니면 페이지마다 제각각의 임의 값을 쓰고 있는지를 자동으로 판정하죠. 형태 위반의 대부분은 "토큰을 안 쓰고 임의 값을 박았다"에서 출발하니까요.

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

이제 KRDS 가이드라인(디지털 정부서비스 UI/UX 가이드라인, 2025.08판)과 컴포넌트 킷을 기준으로, 형태가 충족해야 하는 요건을 짚어 보겠습니다. 위반 사례를 제대로 이해하려면, 먼저 "지켜야 할 기준"이 무엇인지 알아야 하니까요.

1) 모서리 반경은 정해진 단계(스케일)를 쓴다

KRDS는 모서리 반경을 아무 값이나 쓰는 게 아니라, 몇 단계로 정해진 스케일 안에서 고르도록 합니다. 보통 "각짐(0) → 작게 둥글림 → 중간 → 크게 → 완전히 둥글림(알약/원형)" 같은 단계로 구성되죠. 이 단계 값들이 토큰으로 제공됩니다.

여기서 중요한 건 "정해진 단계 외의 임의 값을 쓰지 않는다"는 원칙입니다. 디자이너가 "이 정도면 적당하겠지"라며 5px, 7px, 9px을 그때그때 정하는 게 아니라, 시스템이 정한 단계 중에서 고르는 거죠. 구체적인 px 수치는 KRDS 공식 토큰을 따라야 하므로, 이 글에서 특정 숫자를 단정하지는 않겠습니다. 정확한 값은 항상 공식 자료에서 확인하시는 게 맞습니다. 핵심은 "단계가 정해져 있고, 그 안에서만 고른다"는 규율 그 자체입니다.

2) 요소의 크기·역할에 맞는 형태를 쓴다

모서리 반경은 "무조건 둥글수록 좋다"가 아닙니다. 작은 요소를 너무 많이 둥글리면 형태가 뭉개져 보이고, 큰 요소를 너무 적게 둥글리면 딱딱해 보입니다. KRDS는 요소의 크기와 역할에 맞는 형태 단계를 안내합니다. 예컨대 작은 태그·뱃지, 중간 크기의 버튼·입력창, 큰 카드·모달은 각각 어울리는 형태 단계가 다릅니다.

이 "위계"가 중요한 이유는, 형태가 무질서하게 섞이는 걸 막아 주기 때문입니다. 같은 크기·같은 역할의 요소는 같은 형태, 다른 역할이면 정해진 다른 형태 — 이 규칙이 있으면 화면이 "정돈된 느낌"을 갖습니다. 규칙 없이 그때그때 정하면, 화면은 "어딘가 산만한 느낌"을 줍니다. 사용자는 그 이유를 정확히 짚지 못해도 "뭔가 어수선하다"고 느끼죠.

3) 같은 종류의 요소는 어디서나 같은 형태

형태 일관성의 핵심 요건입니다. 기본 버튼이라면 메인 페이지에서도, 신청 페이지에서도, 검색 결과에서도 같은 모서리 반경이어야 합니다. 카드라면 어느 페이지의 카드든 같은 형태여야 하고요. 페이지마다 같은 컴포넌트의 형태가 달라지면, 사용자는 "이게 같은 버튼인가, 다른 버튼인가"를 매번 미세하게 다시 판단하게 됩니다. 그 미세한 인지 부담이 쌓이면 "이 사이트 어수선하다"는 인상으로 굳어집니다.

KRDS가 컴포넌트 킷(GitHub KRDS-uiux/krds-uiux)을 통해 버튼·카드·입력창 등의 표준 코드를 제공하는 이유가 여기 있습니다. 검증된 컴포넌트를 가져다 쓰면, 형태가 토큰으로 고정되어 있으니 페이지를 옮겨도 일관성이 자동으로 유지됩니다. 직접 만들다 보면 페이지마다 미묘하게 어긋나는데, 표준 컴포넌트는 그 어긋남 자체를 차단해 주죠.

4) 형태는 의미를 거들 수 있다 — 단, 형태에만 의존하지 않는다

형태는 때로 의미 구분에 쓰입니다. 예를 들어 알약 모양(완전히 둥근)은 "태그·필터 칩"처럼 가벼운 요소에, 각진 형태는 "구조적인 컨테이너"에 쓰는 식으로요. 형태가 일관된 규칙으로 쓰이면 사용자는 형태만 보고도 요소의 성격을 짐작합니다.

다만 주의할 점이 있습니다. 형태(또는 색)만으로 정보를 전달하면 안 됩니다. 예를 들어 "둥근 건 활성, 각진 건 비활성"처럼 형태에만 의존하면, 형태 차이를 인지하기 어려운 사용자는 그 정보를 놓칩니다. 형태는 의미를 거드는 보조 수단이지, 유일한 전달 수단이 되면 안 된다는 게 웹 접근성(KWCAG)의 원칙과도 맞닿습니다. 형태로 구분하되, 텍스트나 다른 표시로도 함께 알려야 합니다.

5) 일관성의 단위는 "사이트 전체"

형태 일관성을 한 페이지 안에서만 따지면 충분하지 않습니다. KRDS의 표준화 정신은 "한 페이지가 아니라 서비스 전체, 나아가 모든 공공 서비스가 일관된 경험을 준다"는 데 있습니다. 그래서 형태 점검도 단일 페이지가 아니라 사이트 전체(여러 페이지)를 함께 봐야 의미가 있습니다. 메인은 잘 맞는데 하위 페이지에서 어긋나는 경우가 워낙 많거든요. 이 부분은 뒤의 위반 사례와 ViewCheck 점검에서 다시 강조하겠습니다.

정리하면, KRDS의 형태 기준은 세 축입니다. ① 정해진 스케일(임의 값 금지, 토큰 사용), ② 크기·역할에 맞는 위계, ③ 사이트 전체의 일관성. 이 세 축을 기억하고 위반 사례를 보면, 왜 그게 문제인지가 또렷해집니다.

왜 형태가 이렇게 중요한가 — 원리와 배경

"모서리 좀 안 맞는 게 그렇게 큰일인가?" 싶으실 수 있습니다. 색이 틀리거나 글자가 안 읽히는 것에 비하면 사소해 보이니까요. 그런데 형태 일관성은 생각보다 깊은 곳에서 사용자 경험을 좌우합니다. 왜 이걸 이렇게까지 따지는지, 원리를 짚어 보겠습니다.

일관성은 "신뢰"로 번역된다

사람은 화면을 볼 때 의식하지 못한 채 수많은 단서를 종합해 "이 사이트가 믿을 만한가"를 판단합니다. 형태의 일관성은 그 단서 중 하나입니다. 모든 버튼이 같은 모양, 모든 카드가 같은 형태로 정돈되어 있으면, 사용자는 무의식적으로 "여기 잘 관리되고 있구나"라고 느낍니다. 반대로 모서리가 제각각이면 "대충 만들었나?", "여기 믿어도 되나?" 하는 미세한 불신이 깔립니다.

특히 공공 서비스는 신뢰가 생명입니다. 세금을 내고, 민원을 신청하고, 개인정보를 입력하는 곳이니까요. 그 화면이 "어딘가 어수선하다"는 인상을 주면, 사용자는 자기도 모르게 입력 정보가 제대로 처리될지 의심하게 됩니다. 형태 일관성은 단순한 미관이 아니라, 서비스에 대한 신뢰의 토대입니다.

형태는 "같은 것/다른 것"을 구분하는 언어다

사용자는 형태가 같으면 "같은 종류"라고, 다르면 "다른 종류"라고 직관적으로 받아들입니다. 이건 학습된 게 아니라 거의 본능에 가깝습니다. 그래서 형태가 무질서하면 이 직관이 어긋납니다. 같은 기능의 버튼인데 모양이 다르면 "이건 다른 기능인가?"라고 헷갈리고, 다른 기능인데 모양이 같으면 "이게 그거랑 같은 건가?"라고 오해합니다.

예를 들어 어떤 페이지에선 "신청" 버튼이 둥근데, 다른 페이지에선 각졌다고 합시다. 사용자는 "이 각진 버튼도 신청 버튼이 맞나?" 하고 한 박자 멈칫합니다. 그 멈칫거림 하나하나는 사소하지만, 서비스 전체에 쌓이면 "이 사이트 쓰기 피곤하다"는 인상이 됩니다. 형태 일관성은 사용자가 멈칫거리지 않고 매끄럽게 작업을 끝내게 해 주는, 보이지 않는 윤활유입니다.

작은 요소일수록 방치되기 쉽다

역설적이지만, 형태처럼 "작고 당연해 보이는" 요소일수록 품질 관리에서 밀려납니다. 메인 비주얼이나 핵심 기능에는 모두가 눈을 부릅뜨지만, 버튼 모서리가 몇 px인지에는 아무도 깐깐하게 굴지 않습니다. "그거 좀 다른 게 무슨 대수냐"는 거죠.

그런데 사용자가 실제로 손을 대는 건 바로 그 작은 요소들입니다. 버튼을 누르고, 입력창에 글자를 넣고, 카드를 클릭하죠. 이 작은 요소들의 형태가 정돈되어 있느냐가, 사이트 전체의 완성도 인상을 결정합니다. 가장 덜 주목받는 곳이 사실은 사용자 경험의 최전선인 셈입니다. KRDS가 형태 같은 기초 요소까지 토큰으로 표준화해 둔 건, 바로 이 "방치되기 쉬운 곳"에서 품질이 무너지는 걸 막기 위해서입니다.

한 가지 솔직히 덧붙이면, 형태는 "잘 맞춰도 티가 안 나는" 영역입니다. 모서리 반경을 전 화면에서 완벽하게 통일해도, 사용자가 "와, 모서리 일관성 좋네"라고 칭찬하는 일은 없습니다. 잘 됐을 때는 그냥 "깔끔하다"는 막연한 인상만 남고, 안 됐을 때만 "어수선하다"는 불만이 생기죠. 칭찬받기는 어렵고 욕먹기는 쉬운, 좀 억울한 자리입니다. 그래서 더 방치됩니다. "어차피 티도 안 나는데 대충 하자"는 유혹이 늘 따라붙거든요. 하지만 티가 안 난다는 건 잘 됐을 때 얘기고, 한 번 무너지면 그 어수선함은 사이트 전체로 번집니다. 이 글이 "형태쯤이야"라는 유혹을 한 번쯤 멈춰 세우는 계기가 되면 좋겠습니다.

형태 일관성은 유지보수 비용도 줄인다

토큰으로 형태를 관리하면, 나중에 디자인을 바꿀 때도 편합니다. "전체 버튼 모서리를 조금 더 둥글게 바꾸자"는 결정이 나면, 토큰 값 하나만 바꾸면 전 화면이 한 번에 바뀝니다. 반면 페이지마다 손으로 박아 둔 값들은, 일일이 찾아서 고쳐야 합니다. 빠뜨리면 또 어긋나고요. 형태 일관성은 사용자 경험뿐 아니라, 개발·운영 효율까지 함께 끌어올리는 일입니다. 한 번 잘 정해 두면 두고두고 이득을 보는 구조죠.

공공웹이 형태에서 자주 틀리는 지점 — 익명 사례 모음

이제 이 글의 핵심입니다. 제가 공공 사이트를 분석하며 반복해서 만난 형태 위반들을, 익명화한 일반 사례로 정리하겠습니다. 특정 기관을 지목하지 않고, "이런 패턴이 흔하다"는 일반화된 형태로 보여 드립니다. 읽으면서 "어, 우리 사이트도 이런데?" 싶은 게 분명 있으실 겁니다.

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

가장 흔하고 가장 알아차리기 어려운 위반입니다. ○○시의 한 서비스를 분석했을 때, 메인 페이지의 카드는 살짝 둥근데 공지사항 페이지의 카드는 더 많이 둥글고, 신청 페이지의 카드는 거의 각져 있었습니다. 같은 "카드"라는 컴포넌트인데 페이지마다 모서리가 다른 거죠.

원인은 대부분 같습니다. 토큰을 안 쓰고 개발자가 페이지를 만들 때마다 border-radius를 손으로 입력한 겁니다. 어떤 개발자는 4px, 어떤 개발자는 8px, 어떤 페이지는 외주 시기가 달라서 또 다른 값. 각 페이지만 따로 보면 멀쩡해 보이는데, 사이트 전체를 펼쳐 놓고 보면 모서리가 들쭉날쭉입니다.

• 나쁜 예: 페이지마다, 컴포넌트마다 border-radius를 임의 px으로 직접 입력. 토큰 없음. 같은 카드인데 페이지별로 값이 다름.
• 올바른 예: 모서리 반경을 토큰(radius-*)으로 정의하고, 모든 요소가 그 토큰을 참조. 같은 컴포넌트는 어느 페이지에서나 같은 형태.

이 위반이 무서운 건, 각 페이지를 따로 점검하면 절대 안 잡힌다는 점입니다. 사이트 전체를 동시에 봐야만 "어, 이 페이지 카드가 다르네"가 드러나거든요. 그래서 형태 점검은 반드시 여러 페이지를 함께 봐야 합니다.

위반 2) 같은 버튼인데 위치마다 모양이 다르다

A 광역지자체의 사례입니다. 헤더 우측의 "로그인" 버튼은 알약처럼 완전히 둥글었는데, 본문 안의 "신청하기" 버튼은 살짝만 둥글고, 푸터의 "맨 위로" 버튼은 또 각졌습니다. 셋 다 같은 위계의 버튼인데 형태가 전부 달랐죠.

이런 일은 보통 컴포넌트를 표준화하지 않고, 화면을 만드는 사람마다 그 자리에서 버튼을 새로 그릴 때 생깁니다. 헤더는 한 사람이, 본문은 다른 사람이, 푸터는 또 다른 시점에 만들어졌고, 각자 자기 감각으로 모서리를 정한 거죠.

• 나쁜 예: 버튼을 위치마다 따로 스타일링. 공통 버튼 컴포넌트 없음. 형태가 자리마다 제각각.
• 올바른 예: 버튼을 하나의 표준 컴포넌트로 정의(KRDS 킷 활용)하고, 변형(크기·강조)만 두되 기본 형태 토큰은 공유. 같은 위계의 버튼은 어디서나 같은 모양.

위반 3) 시안은 둥근데 개발본은 각졌다 (디자인-구현 간극)

한 중앙부처의 신규 서비스를 분석했을 때, 흥미로운 패턴을 봤습니다. 디자인 시안(Figma)에서는 카드와 버튼이 분명히 둥글게 설계됐는데, 실제 개발된 화면에선 각져 있었습니다. 개발 과정에서 모서리 반경이 누락되거나, 기본 브라우저 스타일이 그대로 남은 거죠.

이건 디자이너와 개발자가 같은 기준을 공유하지 않아서 생기는 전형적인 간극입니다. 디자이너는 "당연히 둥글게 그렸으니 둥글게 나오겠지" 생각하고, 개발자는 시안의 모서리 값을 정확히 확인하지 않은 채 구현하죠. 그 사이에서 형태가 증발합니다.

• 나쁜 예: 시안의 형태 값이 코드로 정확히 전달되지 않음. 개발자가 임의로 추정하거나 누락. 시안 ≠ 결과물.
• 올바른 예: 형태를 토큰으로 정의해 디자인(Figma)과 코드(CSS)가 같은 값을 공유. KRDS 공식 Figma(@krds)와 컴포넌트 킷을 함께 쓰면 이 간극이 크게 줄어듦.

위반 4) 형태를 의미 전달의 유일한 수단으로 씀

○○구의 한 화면에서, 둥근 칩은 "선택됨", 각진 칩은 "선택 안 됨"을 형태만으로 구분하고 있었습니다. 색도 거의 비슷하고, 텍스트로는 상태를 알려 주지 않았죠. 형태 차이를 인지하기 어려운 사용자에게는 어느 칩이 선택된 건지 알 길이 없었습니다.

형태로 의미를 거드는 건 좋습니다. 하지만 형태 하나에만 의존하면, 그 차이를 못 보는 사용자는 정보를 통째로 놓칩니다. 이건 웹 접근성(KWCAG)에서 말하는 "정보를 한 가지 감각 특성에만 의존하지 말라"는 원칙과 정확히 충돌합니다.

• 나쁜 예: 형태(또는 색)만으로 상태·종류를 구분. 텍스트·아이콘 등 보조 표시 없음.
• 올바른 예: 형태로 거들되, 텍스트 라벨이나 명확한 상태 표시(예: "선택됨" 텍스트, 체크 아이콘)를 함께 제공.

위반 5) 한 요소 안에서 모서리가 따로 논다

이건 좀 더 미세한 위반인데, 의외로 자주 보입니다. 카드 하나에서 위쪽 두 모서리는 둥글고 아래쪽 두 모서리는 각진 경우. 의도한 디자인이면 괜찮지만, 대부분은 그냥 CSS를 잘못 적용한 실수입니다. 카드 안에 이미지가 들어가면서 이미지 모서리는 각지고 카드 배경 모서리만 둥글어, 둥근 테두리 안에 각진 이미지가 비죽 튀어나오는 경우도 흔합니다.

• 나쁜 예: 컨테이너는 둥근데 내부 요소(이미지·배경)는 각져서, 모서리에서 형태가 어긋남. overflow 처리 누락.
• 올바른 예: 둥근 컨테이너 안의 요소도 같은 형태로 맞추거나, overflow: hidden 등으로 내부 요소를 컨테이너 형태에 맞춰 잘라냄.

위반 6) 입력창과 버튼의 형태가 안 맞는다

검색 박스를 예로 들면, 입력창은 각졌는데 바로 붙어 있는 검색 버튼은 둥근 경우가 많습니다. 나란히 붙어 한 덩어리처럼 보여야 할 두 요소의 형태가 어긋나, 어색하게 들떠 보이죠. B 공공기관의 검색창이 딱 이랬습니다. 입력창과 버튼이 붙어 있는데 모서리가 안 맞아서, 마치 두 개의 다른 부품을 억지로 붙여 놓은 것 같았습니다.

• 나쁜 예: 한 덩어리로 보여야 할 입력창+버튼의 형태가 서로 다름. 붙는 면의 모서리 처리 불일치.
• 올바른 예: 함께 쓰이는 요소는 형태 토큰을 공유하고, 붙는 면의 모서리는 평평하게(또는 맞물리게) 처리해 한 덩어리로 보이게.

위반 7) 과한 둥글림 / 과한 각짐

형태에도 "맥락에 맞는 정도"가 있습니다. 본문의 정보 카드를 알약처럼 완전히 굴려 버리면 정보 컨테이너로서의 무게감이 사라지고, 반대로 친근해야 할 작은 알림 띠를 칼처럼 각지게 하면 딱딱해 보입니다. C 기관의 어떤 페이지는 모든 요소를 과하게 둥글려서 화면이 장난감처럼 보였고, 다른 페이지는 전부 각져서 1990년대 화면 같았습니다. 둘 다 "정해진 위계 없이 한쪽으로 쏠린" 경우죠.

• 나쁜 예: 요소의 크기·역할을 무시하고 일괄적으로 과하게 둥글리거나 각지게 함.
• 올바른 예: 크기·역할에 맞는 형태 단계를 적용(작은 요소는 작은 반경, 큰 컨테이너는 적절한 반경). KRDS의 형태 위계를 따름.

위반 8) 모바일에서 형태가 깨진다

데스크톱에서만 확인하고 모바일을 점검하지 않아, 좁은 화면에서 형태가 무너지는 경우입니다. 카드가 화면 폭에 맞춰 늘어나면서 모서리 비율이 어색해지거나, 둥근 버튼이 작아지면서 형태가 뭉개지거나. 반응형 환경에서 형태가 의도대로 유지되는지는 별도로 확인해야 합니다.

• 나쁜 예: 데스크톱 기준으로만 형태를 맞추고 모바일은 미확인. 좁은 화면에서 형태 깨짐.
• 올바른 예: 주요 뷰포트(데스크톱·태블릿·모바일)에서 형태가 일관되게 유지되는지 확인. 토큰 기반이면 대부분 자동으로 유지됨.

위반 9) 외주·시기별로 만든 페이지의 형태가 따로 논다

공공 사이트는 한 번에 다 만들어지는 경우가 드뭅니다. 메인은 A 업체가, 통합검색은 B 업체가, 민원 신청은 또 몇 년 뒤 C 업체가 추가하는 식이죠. 문제는 각 업체·각 시기마다 형태 기준이 달랐다는 점입니다. 제가 분석한 어느 광역지자체 통합 포털은, 한 도메인 안인데도 페이지마다 "다른 사이트에 온 듯한" 느낌을 줬습니다. 카드 모서리, 버튼 형태, 박스 처리가 영역별로 전부 달랐거든요. 사용자는 같은 기관 안에서 움직이는데도 매번 다른 디자인을 만나, "여기가 거기 맞나?" 하고 헷갈렸습니다.

이건 단일 업체의 실력 문제가 아니라, 공통 형태 토큰이라는 기준선이 없었기 때문에 생기는 구조적 위반입니다. 기준이 없으니 각자 자기 감각대로 만들 수밖에 없었던 거죠. KRDS 토큰을 발주 시방서에 명시해 두면, 어느 업체가 언제 만들든 같은 형태로 수렴하게 됩니다.

• 나쁜 예: 영역·시기별로 형태 기준이 제각각. 공통 토큰 없이 업체마다 임의 적용. 한 도메인인데 형태가 분열.
• 올바른 예: 발주 단계에서 "KRDS 형태 토큰 준수"를 시방서에 명시. 어느 업체가 추가하든 같은 토큰을 참조해 일관성 유지.

위반 10) 호버·포커스 상태에서만 형태가 바뀐다

평소엔 둥근 버튼이 마우스를 올리면(hover) 갑자기 각져 보이거나, 키보드 포커스가 왔을 때 모서리 모양이 미묘하게 달라지는 경우입니다. 상태 변화에서 색이나 그림자만 바꾸면 되는데, 실수로 형태까지 건드린 거죠. 사용자는 "버튼이 움찔한다"는 어색한 느낌을 받습니다. 특히 포커스 상태의 외곽선이 버튼 형태와 안 맞게 각진 사각형으로 떠서, 둥근 버튼 위에 각진 테두리가 겹쳐 보이는 경우도 흔합니다.

• 나쁜 예: 기본/호버/포커스 상태마다 형태가 달라짐. 포커스 외곽선이 요소 형태와 불일치(둥근 버튼에 각진 외곽선).
• 올바른 예: 상태 변화는 색·그림자·강조로만 표현하고 형태는 유지. 포커스 외곽선도 요소의 모서리 형태를 따라가게.

한 장면 — 같은 사이트, 두 페이지

추상적인 설명보다 한 장면을 그려 보는 게 빠를 것 같습니다. 어느 공공 서비스의 두 페이지를 나란히 놓고 봤다고 합시다.

먼저 메인 페이지. 카드들이 살짝 둥근 모서리로 가지런히 정렬되어 있고, 버튼도 같은 정도로 둥급니다. 화면이 깔끔하고, "잘 만들었네" 싶습니다. 이 페이지만 보면 형태에 아무 문제가 없습니다. 그래서 이 사이트를 만든 팀도 "우리 디자인 일관성 좋다"고 믿습니다. 데모할 때 늘 메인만 보여 주니까요.

이번엔 신청 페이지로 넘어갑니다. 그런데 여기 카드는 거의 각져 있고, 버튼도 메인보다 덜 둥급니다. 입력창은 또 다른 모서리고요. 메인을 보다 넘어온 사용자는 미묘한 위화감을 느낍니다. "어? 아까랑 좀 다른데?" 정확히 뭐가 다른지는 짚지 못하지만, "사이트가 좀 어수선하다", "딴 데로 넘어온 것 같다"는 인상이 남습니다. 그 인상은 "이 신청 정보가 제대로 처리될까?"라는 미세한 불안으로 이어지기도 합니다.

같은 사이트, 같은 컴포넌트. 한 페이지에서는 정돈된 인상을, 다른 페이지에서는 어수선한 인상을 줍니다. 그리고 이 차이는 "예산이 부족해서"나 "기술이 어려워서" 생긴 게 아닙니다. 그냥 형태를 토큰으로 묶어 두지 않고 페이지마다 따로 만들었기 때문에 생긴 차이입니다. 그리고 이 차이는 메인 한 페이지만 봐서는 절대 발견할 수 없습니다. 사이트 전체를 함께 펼쳐 봐야만 드러나죠. 형태 점검이 "여러 페이지를 동시에 보는 자동 분석"을 필요로 하는 이유가 바로 여기 있습니다.

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

위반 사례를 봤으니, 이제 "그럼 어떻게 안 틀리게 만드나"를 역할별로 정리하겠습니다. KRDS의 좋은 점은 형태 기준을 "알아서 잘 하세요"로 끝내지 않고, 바로 쓸 수 있는 자산으로 제공한다는 것입니다.

개발자라면 — 모서리 반경을 코드에 직접 px으로 박지 마세요. KRDS 컴포넌트 킷(npm install krds-uiux 또는 CDN krds.min.css / krds.min.js)을 쓰면 형태가 토큰으로 정의된 상태로 시작합니다. 저장소(KRDS-uiux/krds-uiux)의 html/code 폴더에 버튼·카드·입력창 등의 표준 코드가 들어 있어, 형태 일관성이 기본으로 보장됩니다. 직접 만들더라도 border-radius는 반드시 토큰(CSS 변수)으로 정의하고, 모든 요소가 그 변수를 참조하게 하세요. 그래야 나중에 한 번에 바꿀 수 있고, 페이지별 어긋남도 막힙니다. 둥근 컨테이너 안의 이미지가 튀어나오는 위반(위반 5)은 overflow: hidden을 잊지 않으면 대부분 막힙니다.

디자이너라면 — 형태를 매 화면에서 그날의 감각으로 정하지 말고, KRDS 공식 Figma(@krds) 라이브러리의 표준 컴포넌트를 가져다 쓰세요. 그러면 시안 단계에서부터 형태 토큰이 적용되어, 페이지 간 일관성이 자동으로 유지됩니다. 시안을 개발에 넘길 때는 "이 카드의 모서리는 어떤 형태 단계인지"를 토큰 이름으로 명시하세요. "그냥 둥글게"가 아니라 "radius-medium"처럼요. 이 한 줄이 위반 3(시안-구현 간극)을 막습니다.

기획자라면 — 화면 정의서에 형태 관련 메모를 한 줄 넣어 두세요. "카드·버튼은 KRDS 형태 토큰을 따른다", "신규 컴포넌트는 표준 킷 우선" 같은 원칙을요. 그리고 검수 단계에서 "메인만 보지 말고 신청·검색·상세 등 주요 페이지를 함께 보고 형태가 일관된지 확인"을 체크 항목으로 넣으면, 위반 1·2가 배포 전에 걸러집니다.

세 역할이 같은 기준(토큰)을 공유하는 게 핵심입니다. 그래서 KRDS가 디자인(Figma)·코드(GitHub 킷)·문서(가이드라인)를 한 세트로 제공하는 거죠. 같은 토큰을 보고 일하면 "이건 누구 책임" 논쟁도 줄어듭니다.

그래서 우리 사이트는? — ViewCheck로 형태 점검

여기까지가 KRDS의 형태 기준과 흔한 위반입니다. 그런데 정작 어려운 건 "그래서 우리 사이트 형태는 일관된가?"를 확인하는 일입니다. 앞서 계속 강조했듯, 형태 위반의 상당수는 여러 페이지를 동시에 펼쳐 봐야 드러납니다. 페이지마다 카드 모서리가 몇 px인지, 같은 버튼이 페이지별로 같은 형태인지를 사람이 일일이 눈으로 비교하려면 끝이 없습니다. 페이지가 수십·수백 개인 공공 사이트라면 사실상 불가능하죠.

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

ViewCheck가 형태에 대해 자동으로 보는 것들을 정리하면 이렇습니다.

• 형태 토큰 채택 여부: 모서리 반경 등 형태 값이 정해진 토큰을 쓰는지, 아니면 페이지마다 임의 값을 박았는지. ViewCheck는 분석한 화면의 실제 computed style(브라우저가 최종 계산한 스타일)을 읽어, 형태 값이 일관된 단계 안에 있는지 봅니다.
• 페이지 간 형태 일관성: 여러 페이지를 한꺼번에 분석하면, 같은 종류의 요소가 페이지별로 같은 형태인지 비교합니다. "메인 카드는 둥근데 신청 페이지 카드는 각졌다" 같은 위반이 바로 드러납니다.
• 디자인 토큰 채택률 리포트: 형태를 포함한 디자인 토큰을 전체적으로 얼마나 잘 채택하고 있는지 비율로 보여 줍니다. 토큰 채택률이 낮다는 건 곧 "임의 값이 많다 = 일관성 위험"이라는 신호입니다.

DOM(코드)만으로 판단하기 어려운 시각적 부분 — 예를 들어 "실제로 화면에서 모서리가 어떻게 보이는지", "둥근 컨테이너 안에 각진 이미지가 튀어나오는지" 같은 건 KRDScan Vision AI가 스크린샷을 보고 보강 판정합니다. 그래서 코드만 검사하는 단순 도구가 놓치는 "눈으로 봐야 보이는 형태 어긋남"도 잡아냅니다. 사람이 눈으로 비교하듯 화면을 함께 보기 때문이죠.

리포트를 어떻게 읽나

분석이 끝나면 디자인 시스템 탭에서 형태 관련 규칙의 통과/미통과 수와, 미통과한 항목의 위치(어느 페이지)·이유·개선 방법(howToFix)이 함께 나옵니다. 예를 들어 "신청 페이지의 카드 모서리 반경이 사이트 기준값과 다름"처럼 구체적으로요. 여러 페이지를 한꺼번에 분석하면, "메인은 토큰을 잘 쓰는데 하위 페이지는 임의 값이 많다" 같은 페이지별 편차도 한눈에 드러납니다. 어디부터 고쳐야 하는지 우선순위(P0~P3)도 함께 매겨지니, 한정된 시간에 가장 효과 큰 것부터 손볼 수 있습니다.

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

자주 묻는 질문

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

Q. 모서리 반경, 솔직히 몇 px이든 사용자가 알아챌까요?

한 페이지만 보면 거의 못 알아챕니다. 문제는 페이지를 옮겨 다닐 때 생깁니다. 사람은 미세한 형태 차이를 "정확히 몇 px 다르다"고 인지하진 못해도, "뭔가 달라졌다", "어수선하다"는 느낌으로는 분명히 감지합니다. 특히 같은 버튼·카드가 페이지마다 다르면 그 위화감이 누적됩니다. 그래서 형태는 "한 값이 얼마냐"보다 "전 화면에서 같으냐"가 훨씬 중요합니다. 일관성이 핵심이지, 특정 px이 정답인 게 아닙니다.

Q. 디자인 자유를 너무 제한하는 거 아닌가요? 둥근 정도 정도는 자유롭게 하고 싶은데.

형태 토큰은 자유를 뺏는 게 아니라, "고민할 필요 없는 것을 정해 주는" 장치에 가깝습니다. 모서리 반경을 매번 새로 정하느라 쓰는 에너지를, 정말 중요한 디자인 결정에 쓰자는 거죠. 그리고 토큰은 보통 여러 단계를 제공하므로, 그 안에서 충분히 선택할 수 있습니다. "정해진 단계 안에서 고른다"와 "아무 값이나 쓴다"는 다릅니다. 전자는 일관성을 지키면서 표현하는 거고, 후자는 무질서입니다. 공공 서비스에서 추구할 건 단연 전자입니다.

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

전부 갈아엎을 필요는 없습니다. 먼저 ViewCheck로 현황을 확인해 "지금 어떤 페이지의 어떤 요소가 기준과 다른지"를 목록으로 만든 다음, 우선순위대로 고치면 됩니다. 특히 신청·로그인·검색처럼 사용 빈도가 높은 핵심 경로부터 형태를 맞추면, 적은 작업으로 가장 많은 사용자가 느끼는 위화감을 줄일 수 있습니다. 그리고 토큰을 도입해 두면, 이후로는 어긋남이 다시 생기는 걸 구조적으로 막을 수 있습니다.

Q. 형태가 색이나 접근성보다 덜 중요한 거 아닌가요? 우선순위가 낮을 것 같은데.

형태가 "기능을 차단하는" 문제는 아니라는 점에서, 키보드 미지원이나 라벨 누락 같은 치명적 접근성 위반보다 급박하진 않습니다. 다만 형태가 의미 전달의 유일한 수단으로 쓰이는 경우(위반 4)는 접근성 문제로 직결되니 우선순위가 올라갑니다. 그 외의 형태 일관성은 "사용자 신뢰와 완성도 인상"의 문제로, 중요하지만 치명적이진 않은 영역입니다. ViewCheck가 우선순위(P0~P3)를 매겨 주니, 형태 항목이 어느 급간인지 보고 다른 항목과 비교해 처리 순서를 정하면 됩니다.

Q. KRDS 형태 토큰의 정확한 px 값은 어디서 보나요?

이 글에서는 일부러 특정 숫자를 단정하지 않았습니다. 형태 토큰의 정확한 값은 KRDS 공식 자료에서 직접 확인하시는 게 맞습니다. KRDS 가이드라인 PDF와 컴포넌트 킷(GitHub KRDS-uiux/krds-uiux), 공식 Figma(@krds)에서 형태 토큰의 단계와 값을 확인할 수 있습니다. 가장 확실한 방법은 컴포넌트 킷을 직접 가져다 쓰는 것입니다 — 그러면 정확한 값을 외울 필요 없이 토큰이 알아서 적용되니까요.

Q. 우리는 자체 디자인 시스템이 있는데, 그래도 KRDS 형태를 따라야 하나요?

자체 디자인 시스템이 있다면, 그 시스템 안에서 형태가 토큰으로 잘 관리되고 페이지 간 일관성이 지켜진다면 그것 자체로 의미가 있습니다. 다만 공공 서비스라면 "모든 정부 사이트가 일관된 경험을 준다"는 KRDS의 표준화 정신을 고려할 필요가 있습니다. 자체 시스템을 KRDS 토큰 체계와 맞춰 두면, 사용자가 다른 공공 서비스로 옮겨 가도 형태 언어가 통합니다. 핵심은 "토큰으로 관리하느냐"이지, 어떤 시스템이냐가 아닙니다. 자체 시스템이든 KRDS든, 임의 값을 손으로 박지 않는 게 출발점입니다.

Q. 형태가 어긋난 걸 발견해도, 디자이너가 "의도한 디자인"이라고 하면요?

실제로 의도한 경우도 있습니다. 예를 들어 특정 강조 요소만 형태를 다르게 해 시선을 끄는 디자인은 정당합니다. 구분 기준은 "규칙이 있느냐"입니다. "강조 카드는 이 형태, 일반 카드는 저 형태"처럼 규칙이 명확하고 일관되면 그건 의도된 위계입니다. 반면 "이 페이지만 어쩌다 다른" 건 의도가 아니라 실수일 가능성이 높습니다. ViewCheck 리포트로 "같은 종류 요소가 페이지별로 다른지"를 보면, 의도와 실수를 구분하는 데 도움이 됩니다. 규칙적인 차이는 위반이 아니지만, 무작위적인 차이는 위반입니다.

Q. 둥근 모서리가 성능에 영향을 주나요?

모서리 반경 자체가 성능에 의미 있는 부담을 주는 일은 거의 없습니다. 다만 형태를 그림자·필터 같은 무거운 효과와 함께 과하게 쓰면 렌더링에 영향이 있을 수 있죠. 형태는 성능보다는 "일관성"과 "접근성(형태에만 의존하지 않기)" 관점에서 보는 게 맞습니다. 토큰을 쓰면 CSS가 단순해져 오히려 유지보수와 로딩 양쪽에 도움이 됩니다.

Q. 둥근 컨테이너 안에 이미지가 자꾸 모서리에서 튀어나옵니다.

아주 흔한 위반(위반 5)입니다. 컨테이너의 border-radius만 둥글리고 그 안의 이미지는 각진 채로 두면, 둥근 테두리 밖으로 이미지 모서리가 비죽 나옵니다. 컨테이너에 overflow: hidden을 주면 내부 요소가 컨테이너 형태에 맞춰 잘려서 깔끔해집니다. 또는 이미지에도 같은 형태 토큰을 적용하는 방법도 있습니다. KRDS 표준 카드 컴포넌트를 쓰면 이 처리가 이미 되어 있습니다.

Q. 디자인팀과 개발팀이 서로 형태가 다르게 나오는 걸로 다툽니다.

형태 일관성은 어느 한 팀의 책임이 아니라 합작입니다. 디자이너는 형태를 토큰 이름으로 명시하고, 개발자는 그 토큰을 코드의 CSS 변수로 구현하면, 시안과 결과물이 같아집니다. 분쟁의 원인은 대개 "둥글게"라는 모호한 말을 서로 다르게 해석하는 데 있습니다. 토큰이라는 공통 언어를 쓰면 해석의 여지가 사라집니다. 그래서 KRDS가 디자인·코드·문서를 한 세트로 제공하는 겁니다 — 같은 토큰을 보고 일하라는 거죠.

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

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

가장 먼저(치명적에 준함) — 형태(또는 색)에만 의존해 정보를 전달하는 경우(위반 4). 이건 형태 차이를 인지하기 어려운 사용자에게 정보를 차단하는 접근성 문제라, 형태 항목 중에서는 1순위입니다. 상태·종류 구분에 텍스트·아이콘 같은 보조 표시를 함께 넣어 주세요.

그다음(높음) — 핵심 경로(신청·로그인·검색)에서의 형태 불일치. 작동은 하지만 사용 빈도가 높은 곳이라 위화감이 가장 많은 사용자에게 노출됩니다. 같은 컴포넌트가 핵심 페이지들에서 같은 형태인지부터 맞추세요.

그 후(보통) — 그 외 페이지의 모서리 반경 불일치, 입력창-버튼 형태 어긋남, 한 요소 안의 모서리 깨짐(이미지 튀어나옴 등). 사용은 가능하지만 완성도 인상을 떨어뜨리는 문제들입니다.

여력이 되면(낮음) — 과한 둥글림/각짐을 위계에 맞게 조정, 모바일 형태 미세 보정 같은 사용성·심미 개선. 경험을 한 단계 끌어올리는 항목입니다.

ViewCheck 리포트는 이 우선순위(P0~P3)를 자동으로 매겨 주기 때문에, "일단 눈에 띄는 것부터"가 아니라 "사용자에게 영향이 큰 것부터" 순서대로 처리할 수 있습니다. 그리고 무엇보다, 형태를 토큰으로 묶는 작업을 한 번 해 두면 위 문제들의 상당수가 한꺼번에 해결되고, 앞으로 다시 어긋나는 것도 막힙니다. 개별 픽스보다 구조를 바꾸는 게 결국 더 빠릅니다.

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

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

• KRDS 가이드라인 PDF(디지털 정부서비스 UI/UX 가이드라인, 2025.08판) — 스타일별 정의와 사용 원칙의 1차 원천. 형태 토큰의 정확한 단계와 값을 여기서 확인.
• KRDS 스타일 가이드(웹) — 형태(Shape) — 형태의 정의와 예시를 화면으로 확인.
• KRDS 컴포넌트 킷(GitHub `KRDS-uiux/krds-uiux`) — 버튼·카드·입력창 등의 표준 코드를 그대로 가져다 사용(npm install krds-uiux 또는 CDN). 형태 토큰이 이미 적용된 상태로 시작.
• KRDS 공식 Figma(@krds) — 디자이너용 표준 컴포넌트와 형태 단계.

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

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

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

• ☐ 모서리 반경(border-radius)을 코드에 임의 px으로 직접 박지 않고, 토큰(CSS 변수)으로 정의했다.
• ☐ 같은 종류의 요소(예: 모든 기본 버튼, 모든 카드)는 페이지가 바뀌어도 같은 형태다.
• ☐ 메인만 보지 않고 신청·로그인·검색·상세 등 주요 페이지를 함께 보고 형태 일관성을 확인했다.
• ☐ 디자인 시안의 형태 값이 코드에 정확히 반영됐다(시안 ≠ 결과물이 아니다).
• ☐ 형태(또는 색)만으로 정보를 전달하지 않고, 텍스트·아이콘 등 보조 표시를 함께 뒀다.
• ☐ 둥근 컨테이너 안의 이미지·배경이 모서리에서 튀어나오지 않는다(overflow 처리 확인).
• ☐ 함께 붙는 요소(입력창+버튼 등)의 형태가 어긋나지 않고 한 덩어리로 보인다.
• ☐ 요소의 크기·역할에 맞는 형태 단계를 썼다(작은 건 작게, 큰 컨테이너는 적절히).
• ☐ 모바일 등 주요 뷰포트에서도 형태가 깨지지 않고 유지된다.
• ☐ 가능하면 KRDS 컴포넌트 킷(npm install krds-uiux 또는 CDN)이나 공식 Figma(@krds)의 표준 컴포넌트를 썼다.

KRDS 컴포넌트 킷을 쓰면 위 항목 대부분이 이미 충족된 상태로 시작할 수 있습니다. 형태를 직접 박다 어긋나는 위험을 줄이는 가장 확실한 방법이죠. 공식 Figma 라이브러리(@krds)에서는 디자이너가 표준 형태 단계를 그대로 가져다 쓸 수 있습니다.

형태는 작아 보이지만, 화면의 거의 모든 요소가 형태를 갖습니다. 그래서 형태가 어긋나면 그 어긋남도 화면 전체에 퍼집니다. 우리가 무심코 넘긴 모서리 하나하나가 모여, 사용자에게 "잘 정돈된 사이트"라는 인상을 주기도 하고 "어딘가 어수선한 사이트"라는 인상을 주기도 합니다. 그리고 공공 서비스에서 그 인상은 곧 신뢰의 문제로 이어집니다.

오늘 정리한 위반들이 거창해 보일 수 있지만, 핵심은 결국 단순합니다. 형태를 토큰으로 묶고, 같은 요소는 어디서나 같은 모양으로 두고, 형태에만 의존해 정보를 전하지 않고, 메인만이 아니라 사이트 전체를 함께 보는 것. 이 네 가지만 챙겨도 형태 위반의 대부분은 사라집니다. 그리고 그게 잘 됐는지는 ViewCheck로 몇 분이면 확인할 수 있습니다. 완벽을 한 번에 만들 필요는 없습니다. 가장 눈에 띄는 형태 불일치 하나부터 토큰으로 정리해 나가면, 우리 사이트는 분명히 조금씩 더 정돈되고, 더 믿음직해집니다. 다음 글에서는 형태와 짝을 이루는 또 다른 스타일 요소를 같은 방식으로 뜯어보겠습니다.

우리 사이트의 형태는 지금 얼마나 일관될까요? krds.viewcheck.co.kr에서 URL만 넣으면 무료로 확인할 수 있습니다. 메인 페이지 하나만 돌려 봐도 토큰 채택률이 보이고, 여러 페이지를 함께 돌리면 페이지별 형태 편차까지 한눈에 드러납니다.

#KRDS #공공웹 #디자인시스템 #형태Shape #모서리반경 #디자인토큰 #웹접근성 #UIUX #ViewCheck #정부웹사이트 #일관성 #형태 #Shape #흔한실수 #개선사례 #안티패턴 #디자인스타일 #전자정부 #디지털정부 #행정안전부