형태(Shape) 자가진단 — ViewCheck 5분 점검

같은 사이트인데도 어떤 버튼은 모서리가 둥글고, 어떤 버튼은 각이 져 있고, 또 어떤 입력창은 어중간하게 살짝만 둥근 걸 본 적 있으실 겁니다. 처음 만들 땐 다 비슷하게 맞췄던 것 같은데, 페이지가 늘고 담당자가 바뀌고 외주가 한 번 들어왔다 나가면, 어느새 화면이 "둥근 것 반, 각진 것 반"이 됩니다. 우리는 그걸 보면서도 "뭔가 좀 안 맞는 것 같긴 한데…" 하고 정확히 뭐가 문제인지는 짚어내지 못합니다. 분명히 거슬리는데, 어디가 어떻게 거슬리는지 말로 설명하기가 애매하죠.

그 "애매하게 거슬리는 정체"의 상당 부분이 바로 형태(Shape)입니다. KRDS(대한민국 정부 디자인 시스템)는 컴포넌트의 모서리 반경(border-radius), 테두리, 그림자, 형태의 일관성을 디자인 스타일의 한 축으로 다룹니다. 색이나 타이포만큼 주목받지 못하지만, 사실 화면의 "정돈된 느낌"을 가장 직접적으로 좌우하는 게 형태입니다. 모서리 하나가 제각각이면, 아무리 색을 잘 맞춰도 화면 전체가 어딘가 허술해 보입니다.

이 글은 "KRDS 완전해부" 시리즈 중에서도 자가진단에 초점을 맞춘 글입니다. 형태가 무엇을 요구하는지를 짧게 정리한 다음, "그래서 우리 사이트의 형태는 지금 어떤 상태인가"를 직접 확인하는 방법에 대부분의 분량을 쓸 겁니다. 거창한 이론서가 아니라, 오늘 당장 우리 화면을 열어 놓고 한 줄씩 짚어 볼 수 있는 실무 체크리스트라고 생각하시면 됩니다. 다 읽고 나면, "우리 사이트 형태, 한번 봐야겠다"가 막연한 다짐이 아니라 구체적인 점검 순서가 되어 있을 겁니다.

미리 한 가지만 일러두면, 형태 점검의 목표는 "더 예쁘게 만들자"가 아니라 "어긋난 것을 찾아 맞추자"입니다. 형태는 독창성을 뽐내는 영역이 아니라, 일관성을 지키는 영역이거든요. 그래서 점검의 핵심 질문도 단순합니다. "같은 종류의 요소가 같은 형태를 갖고 있는가?" 이 한 문장을 가지고 화면을 훑는 것, 그게 형태 자가진단의 전부라고 해도 과언이 아닙니다.

형태(Shape)란 무엇인가 — 점검 전에 용어부터

자가진단을 하려면 먼저 "무엇을 보는지"가 명확해야 합니다. 형태라는 말이 막연하니, 점검 대상이 되는 구체적인 항목부터 정리하겠습니다. KRDS가 디자인 스타일의 형태 영역에서 다루는 것은 대략 이런 것들입니다.

• 모서리 반경(border-radius): 버튼·카드·입력창·모달의 모서리가 얼마나 둥근가. 0(완전 각짐)부터 완전한 원형까지.
• 테두리(border): 선의 두께, 색, 스타일. 있고 없고, 굵고 가늘고.
• 그림자(shadow / elevation): 요소가 떠 있는 느낌을 주는 그림자의 깊이와 방향.
• 형태의 일관성: 같은 역할을 하는 요소끼리 위의 속성들이 통일되어 있는가.

여기서 가장 중요한 건 마지막 항목, 일관성입니다. 모서리를 둥글게 하느냐 각지게 하느냐는 사실 디자인 콘셉트의 선택일 수 있습니다. 그런데 "어떤 버튼은 둥글고 어떤 버튼은 각진" 건 선택이 아니라 그냥 어긋난 겁니다. 점검의 80%는 이 어긋남을 찾는 일입니다.

KRDS는 이 형태 값들을 디자인 토큰으로 정리해 둡니다. 토큰이란 "둥근 정도 4px, 8px, 12px"처럼 디자인에 쓰이는 값을 이름 붙여 정해 둔 것입니다. 디자이너가 매번 "이번엔 7px, 저번엔 5px"로 즉흥적으로 정하는 게 아니라, 정해진 몇 개의 값만 골라 쓰게 하는 거죠. 형태 자가진단은 결국 "우리 사이트가 이 정해진 토큰 안에서 놀고 있는가, 아니면 제멋대로 값을 흩뿌리고 있는가"를 확인하는 일이기도 합니다.

왜 "값을 줄이는" 게 핵심인가

처음 이 개념을 접하면 "둥근 정도가 4px든 5px든 그게 그렇게 중요한가" 싶습니다. 1px 차이를 누가 알아보겠냐는 거죠. 맞습니다. 버튼 하나만 떼어 놓고 보면 4px과 5px은 구분이 안 됩니다. 문제는 그 버튼들이 한 화면에 여러 개 모여 있을 때 생깁니다.

같은 줄에 놓인 버튼 세 개가 각각 4px, 5px, 6px이면, 사람의 눈은 "정확히 뭐가 다른지는 모르겠지만 줄이 안 맞는 느낌"을 받습니다. 이 미묘한 불일치가 쌓이면 화면 전체가 "프로가 만든 것 같지 않은" 인상을 줍니다. 반대로 모든 버튼이 정확히 같은 8px이면, 특별히 멋지지 않아도 "정돈되어 보인다"는 느낌을 줍니다. 그래서 토큰은 값을 늘리는 도구가 아니라 값을 줄이는 도구입니다. 쓸 수 있는 모서리 값을 서너 개로 제한해서, 어긋날 여지 자체를 없애는 거죠.

자가진단의 첫걸음도 여기서 출발합니다. "우리 사이트에서 실제로 쓰이는 모서리 값이 몇 종류인가?" 이 숫자가 적을수록(서너 개) 형태가 잘 관리된 사이트이고, 많을수록(열 개 이상 제각각) 손볼 곳이 많은 사이트입니다.

KRDS는 형태에 무엇을 요구하나 — 점검 기준 압축

본격적인 자가진단에 들어가기 전에, "무엇을 기준으로 합격/불합격을 판단할지"를 정리하겠습니다. KRDS 가이드라인(디지털 정부서비스 UI/UX 가이드라인, 2025.08판)과 컴포넌트 킷을 종합하면, 형태에서 점검해야 할 기준은 다음과 같습니다.

1) 모서리 반경은 정해진 토큰을 쓰는가

가장 기본입니다. 버튼·입력·카드·모달 등 각 컴포넌트는 KRDS가 정한 모서리 값을 따라야 합니다. 임의의 픽셀 값(3px, 7px, 11px처럼 토큰에 없는 숫자)을 즉흥적으로 쓰면 안 됩니다. 점검 시 질문: "이 요소의 모서리 값이 KRDS 토큰 중 하나인가?"

2) 같은 컴포넌트는 같은 형태를 갖는가

사이트 안의 모든 1차 버튼(primary button)은 같은 모서리, 같은 테두리, 같은 그림자를 가져야 합니다. 카드도 마찬가지고, 입력창도 마찬가지입니다. 점검 시 질문: "같은 종류의 요소를 두세 개 골라 비교했을 때 형태가 똑같은가?"

3) 형태가 의미를 흐리지 않는가

형태는 단순히 미관의 문제가 아닙니다. 둥근 정도나 그림자가 요소의 "역할"을 암시하기도 합니다. 예를 들어 완전히 둥근(pill 형태) 버튼은 "태그"나 "필터 칩"처럼 읽히기 쉽고, 각진 큰 버튼은 "주요 동작"으로 읽힙니다. 형태가 역할과 어긋나면 사용자가 헷갈립니다. 점검 시 질문: "이 형태가 이 요소의 역할과 어울리는가?"

4) 그림자(elevation)가 일관된 규칙을 따르는가

그림자는 "이 요소가 화면에서 얼마나 떠 있는가"를 표현합니다. 모달은 페이지 위에 떠 있으니 그림자가 깊고, 카드는 살짝 떠 있으니 얕게. 이 깊이가 들쭉날쭉하면 화면의 층위가 무너집니다. 점검 시 질문: "그림자의 깊이가 요소의 층위(떠 있는 정도)와 맞고, 같은 층위끼리는 같은 그림자인가?"

5) 테두리가 일관되고 대비가 충분한가

입력창의 테두리, 카드의 외곽선 등은 두께·색이 통일되어야 하고, 배경과 충분히 구분돼야 합니다. 너무 연한 테두리는 저시력 사용자에게 "여기가 입력칸인지" 안 보입니다. 점검 시 질문: "테두리 두께·색이 통일돼 있고, 배경과 충분히 대비되는가?"

6) 모바일에서도 형태가 깨지지 않는가

데스크톱에서 맞춰 둔 형태가 모바일에서 무너지는 경우가 많습니다. 반응형으로 크기가 줄면서 모서리 비율이 어색해지거나, 그림자가 잘리거나, 터치 영역이 좁아지면서 형태가 찌그러지죠. 점검 시 질문: "모바일 화면에서도 형태가 데스크톱과 같은 인상을 유지하는가?"

정리하면 형태 점검의 기준은 세 갈래입니다. ① 토큰 준수(정해진 값 안에서 쓰는가), ② 일관성(같은 것은 같게), ③ 명료성(형태가 역할과 가시성을 해치지 않는가). 이 세 가지를 가지고 화면을 훑는 게 형태 자가진단입니다.

손으로 하는 5분 자가진단 — 도구 없이 지금 바로

거창한 도구 없이도, 지금 우리 사이트를 열어 놓고 형태를 직접 점검해 볼 수 있습니다. 순서대로 따라 해보세요. 커피 한 잔 마실 시간이면 충분합니다.

1단계 — 버튼을 한 줄에 모아 비교한다

가장 빠른 방법입니다. 화면에서 버튼들을 찾아, 같은 종류끼리 눈으로 나란히 비교해 보세요. 메인 페이지의 주요 버튼, 신청 페이지의 제출 버튼, 검색 버튼… 이것들의 모서리가 똑같이 둥근가요? 하나는 둥글고 하나는 각지면 바로 1번 문제입니다.

요령이 하나 있습니다. 화면을 캡처해서 버튼 부분만 잘라 한 이미지에 모아 보세요. 따로 보면 비슷해 보이던 것들도, 나란히 놓으면 차이가 확 드러납니다. 사람의 눈은 "절대값"엔 둔하지만 "나란히 놓인 것의 차이"엔 예민하거든요.

2단계 — 입력창의 테두리와 모서리를 본다

폼이 있는 페이지(신청·로그인·문의)로 가서, 입력창들을 보세요. 테두리 두께가 다 같은가요? 모서리가 같은가요? 그리고 한 가지 더 — 테두리가 배경과 충분히 구분되나요? 연한 회색 테두리를 흰 배경에 얹어 두면, 어디까지가 입력칸인지 흐릿합니다. 눈을 살짝 찡그리고 봤을 때 입력칸 경계가 분명히 보이면 합격, 흐물흐물 사라지면 문제입니다.

3단계 — 카드들을 비교한다

목록 페이지나 메인의 카드(게시물 카드, 서비스 바로가기 카드 등)를 보세요. 카드들의 모서리·그림자가 통일돼 있나요? 특히 그림자를 보세요. 어떤 카드는 그림자가 진하고 어떤 건 없으면, 같은 층위인데 떠 있는 정도가 다르게 보입니다. 같은 종류의 카드는 같은 깊이로 떠 있어야 합니다.

4단계 — 모달(팝업)을 띄워 본다

알림·확인 같은 팝업을 하나 띄워 보세요. 모달의 모서리·그림자가 페이지 위에 잘 떠 보이나요? 모달은 페이지 맨 위 층이라, 카드보다 깊은 그림자로 "확실히 위에 있다"를 표현해야 합니다. 모달인데 그림자가 없어 배경과 붙어 보이면, 사용자가 "이게 떠 있는 창인지" 헷갈립니다.

5단계 — 모바일로 같은 화면을 본다

스마트폰으로(또는 브라우저 개발자도구의 모바일 모드로) 위에서 본 화면들을 다시 보세요. 모서리·그림자·테두리가 데스크톱과 같은 인상인가요? 작아지면서 모서리가 어색하게 커 보이거나, 그림자가 화면 밖으로 잘리거나, 버튼이 찌그러지진 않았나요? 데스크톱만 보고 "다 맞췄다"고 안심하는 게 가장 흔한 함정입니다.

6단계 — "어긋난 값" 세어 보기 (개발자라면)

개발자라면 브라우저 개발자도구로 요소를 찍어 border-radius 값을 직접 확인해 보세요. 버튼·카드·입력 몇 개를 찍어 보면, 실제로 몇 종류의 값이 쓰이는지 금방 드러납니다. 서너 개면 양호, 열 개 이상 제각각이면 토큰화가 안 된 사이트입니다. CSS 파일에서 border-radius를 검색해 등장하는 서로 다른 값의 개수를 세 보는 것도 같은 효과입니다.

이 여섯 단계만 해봐도 형태 문제의 대부분이 드러납니다. 다만 한계가 분명합니다 — 페이지가 수십·수백 개인 공공 사이트에서, 이걸 모든 페이지에 대해 손으로 하긴 불가능합니다. 메인 한 장 보는 데 5분이면, 100페이지는 8시간이 넘습니다. 그래서 자동 점검이 필요한 겁니다.

컴포넌트별 형태 점검 — 무엇을 어떻게 보나

위의 5분 점검이 "전체를 빠르게 훑는" 방식이라면, 이번엔 컴포넌트별로 좀 더 꼼꼼히 보는 법을 정리하겠습니다. 형태는 컴포넌트마다 봐야 할 포인트가 조금씩 다르거든요. 자가진단을 "감"이 아니라 "체크 항목"으로 하고 싶을 때 쓰면 됩니다.

버튼 — 형태 점검의 출발점

버튼은 사용자가 가장 많이 누르는 요소라, 형태가 어긋나면 가장 먼저 눈에 띕니다. 버튼을 볼 때는 세 가지를 봅니다. 첫째, 모서리 반경. 1차 버튼(primary)과 2차 버튼(secondary)이 같은 모서리를 갖는지, 페이지마다 같은지. 둘째, 테두리. 외곽선이 있는 버튼(outline)이라면 그 두께·색이 통일됐는지. 셋째, 크기에 따른 형태 변화. 큰 버튼과 작은 버튼이 같은 모서리 값을 쓰면, 작은 버튼이 상대적으로 더 둥글어 보일 수 있습니다. KRDS는 크기별로 적절한 형태 값을 정해 두니, 이를 따르면 됩니다.

흔한 함정 하나. "1차 버튼은 둥글게, 2차 버튼은 각지게" 같은 식으로 형태로 위계를 표현하려는 경우가 있는데, 위계는 색·크기로 표현하고 형태는 통일하는 게 더 안전합니다. 형태가 제각각이면 "둥근 게 더 중요한 건가? 각진 게 더 중요한 건가?"라는 불필요한 해석을 유발하거든요.

입력 필드 — 형태가 곧 가시성

입력창은 형태가 미관을 넘어 접근성에 직결되는 컴포넌트입니다. 테두리가 곧 "여기가 입력칸"이라는 신호이기 때문이죠. 볼 포인트는 두 가지. 첫째, 테두리의 대비. 배경과 충분히 구분되는지. 둘째, 상태별 형태 변화. 포커스됐을 때(테두리 강조), 오류일 때(보통 빨간 테두리), 비활성일 때 — 이 상태들이 형태로 명확히 구분되는지. 특히 오류 상태에서 테두리 색만 바꾸고 끝내면 색각 이상 사용자가 놓치니, 형태(테두리 굵기)나 아이콘·텍스트를 함께 써야 합니다. 모든 입력창의 기본 형태가 같은지, 그리고 같은 상태일 때 같은 형태로 반응하는지를 봅니다.

카드 — 그림자와 모서리의 조화

카드는 보통 여러 개가 격자로 배열되니, 형태 불일치가 가장 잘 드러나는 컴포넌트입니다. 볼 포인트. 첫째, 모서리 통일. 카드 격자 안에서 한 장이라도 모서리가 다르면 줄이 안 맞아 보입니다. 둘째, 그림자 통일. 같은 종류의 카드는 같은 그림자 깊이를 가져야 합니다. 셋째, 내부 요소와의 조화. 카드 안에 들어가는 이미지·버튼의 모서리가 카드 자체의 모서리와 어울리는지. 카드는 8px인데 안의 이미지는 각지면 어색하고, 카드보다 안의 요소가 더 둥글어도 이상합니다.

모달·드롭다운 — 층위를 형태로 표현

모달과 드롭다운은 "페이지 위에 떠 있는" 요소라, 그 떠 있음을 그림자로 표현해야 합니다. 볼 포인트. 첫째, 충분한 그림자 깊이. 배경과 확실히 분리돼 보이는지. 둘째, 모서리 통일. 모든 모달이 같은 모서리를 갖는지. 셋째, 배경 처리. 모달 뒤의 어두운 오버레이가 "이 창이 떠 있다"를 받쳐 주는지. 모달인데 그림자도 없고 오버레이도 흐릿하면, 사용자가 "이게 새 창인지 페이지의 일부인지" 헷갈립니다.

태그·칩·뱃지 — 작지만 자주 어긋나는 곳

태그나 필터 칩, 상태 뱃지처럼 작은 요소들도 형태가 있습니다. 이것들은 보통 둥근(pill) 형태로 "이건 라벨이지 버튼이 아니다"를 암시하는데, 사이트마다 제각각 처리되기 쉽습니다. 어떤 태그는 둥글고 어떤 건 각지면 "왜 다르지?"라는 의문이 생깁니다. 작은 요소라고 빼먹지 말고, 같은 종류끼리 형태를 통일하세요.

왜 형태가 이렇게 자주 어긋나는가 — 점검 전에 알아둘 배경

자가진단을 하다 보면 "왜 이렇게 제각각이 됐지?" 하는 의문이 듭니다. 형태가 유독 잘 어긋나는 데에는 구조적인 이유가 있습니다. 원인을 알면 어디를 집중적으로 봐야 할지도 보입니다.

형태는 "기본값에 묻혀" 방치된다

색이나 글꼴은 디자이너가 의식적으로 고릅니다. 그런데 모서리 반경은? "버튼 만들 때 적당히 둥글게" 정도로 넘어가는 경우가 많습니다. 명시적인 결정이 아니라 그때그때의 감각으로 정해지니, 사람과 시점이 바뀌면 값도 바뀝니다. 한 디자이너는 4px을 좋아하고, 다른 디자이너는 8px을 좋아하면, 두 사람의 작업물이 섞이는 순간 사이트의 모서리가 둘로 갈립니다.

외주·리뉴얼이 한 번 들어올 때마다 갈라진다

공공 사이트는 영역별로 다른 업체가 만드는 경우가 흔합니다. 메인은 A업체, 게시판은 B업체, 민원 시스템은 C업체. 각 업체가 자기 기준으로 형태를 정하면, 한 도메인 안에서 모서리·그림자가 세 갈래로 나뉩니다. 사용자는 같은 사이트를 쓰는데 페이지를 옮길 때마다 다른 디자인을 만나는 셈입니다. 자가진단에서 "페이지마다 형태가 다르다"가 나오면, 십중팔구 이 구조적 원인이 배경에 있습니다.

컴포넌트 라이브러리와 직접 만든 것이 섞인다

UI 라이브러리(부트스트랩 등)를 일부 쓰고, 일부는 직접 만들면 형태가 섞입니다. 라이브러리 기본 버튼은 4px인데 직접 만든 버튼은 8px이면, 같은 화면에 두 종류의 둥근 정도가 공존하죠. 외부에서 가져온 위젯(달력, 차트, 지도)도 자기만의 형태를 들고 오니, 신경 쓰지 않으면 화면이 짜깁기처럼 됩니다.

"1px쯤이야"가 쌓인다

가장 무서운 건 이겁니다. 개별 작업자는 "이번 한 번만 5px로" 하고 넘어갑니다. 큰 문제가 아니라고 느끼니까요. 그런데 그런 "이번 한 번"이 수백 번 쌓이면, 사이트 전체가 일관성을 잃습니다. 형태 부채(debt)는 이렇게 조용히, 한 픽셀씩 쌓입니다. 그래서 정기적인 점검이 필요한 겁니다 — 부채가 눈덩이가 되기 전에 발견해서요.

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

추상적인 설명보다 한 장면을 그려 보는 게 빠를 것 같습니다. 어느 ○○시의 통합 포털이 있다고 합시다. 메인 페이지는 몇 해 전 전면 리뉴얼을 했고, 게시판 영역은 그보다 앞서 다른 업체가 만든 시스템을 그대로 붙여 쓰고 있습니다. 그리고 민원 신청 시스템은 또 다른 외주가 별도로 구축했습니다.

사용자인 정 선생님이 메인에서 "민원 신청"을 누릅니다. 메인의 버튼들은 모서리가 부드럽게 둥글고(8px), 카드에는 은은한 그림자가 깔려 있어 깔끔합니다. 그런데 신청 페이지로 넘어가는 순간, 분위기가 묘하게 바뀝니다. 입력창의 모서리가 거의 각져 있고(2px), 버튼은 또 다른 정도로 둥급니다(4px). 정 선생님은 정확히 뭐가 달라졌는지는 모릅니다. 다만 "어, 다른 사이트로 넘어왔나?" 하는 막연한 위화감을 느낍니다. URL을 확인해 보니 같은 도메인입니다. 다시 게시판으로 가 보면 거기는 또 모서리가 완전히 각져 있습니다(0px). 한 사이트 안에서 모서리가 0px, 2px, 4px, 8px 네 종류로 갈려 있는 겁니다.

이 화면을 만든 각 팀에게는 아무 문제가 없습니다. 메인 팀은 메인만 보고 "잘 맞췄다"고 하고, 신청 시스템 팀은 자기 영역만 보고 "통일됐다"고 합니다. 각자는 맞습니다. 문제는 아무도 사이트 전체를 한 번에 보지 않았다는 데 있습니다. 사용자는 영역을 가로질러 다니는데, 만드는 사람은 영역 안에만 있었던 거죠.

이게 형태 자가진단을, 그것도 전 페이지를 한 번에 봐야 하는 이유입니다. 한 페이지씩 보면 "이 페이지는 통일됐다"가 다 맞아 떨어집니다. 하지만 페이지를 가로질러 비교해야 비로소 "사이트 전체로는 네 갈래로 갈렸다"가 드러납니다. 사람이 100페이지를 머릿속에 펼쳐 놓고 모서리를 비교하긴 불가능합니다. 그래서 도구가 필요한 겁니다 — 전 페이지의 형태 값을 동시에 펼쳐 놓고, "이 도메인 안에서 모서리 값이 몇 종류 쓰였는지"를 한 표로 보여 주는.

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

자가진단을 돌리면 거의 매번 나오는, 형태의 단골 위반들을 정리합니다. 모두 익명화한 일반적 사례입니다(특정 기관을 지목하지 않습니다). "우리 사이트도 이거다" 싶은 게 하나쯤은 있을 겁니다.

위반 1) 한 화면에 둥근 정도가 제각각

같은 줄, 같은 종류의 버튼인데 모서리가 미묘하게 다릅니다.

• 나쁜 예: 검색 버튼 4px, 그 옆 필터 버튼 6px, 제출 버튼 8px. 따로 보면 모르지만 나란히 놓으면 줄이 안 맞아 보임.
• 올바른 예: 같은 종류의 버튼은 같은 토큰 값으로 통일. CSS 변수 하나(--radius-button)로 모두가 같은 값을 참조.

위반 2) 입력창 테두리가 너무 연함

깔끔해 보이려고 테두리를 아주 연한 회색으로.

• 나쁜 예: #eee 같은 연한 테두리. 흰 배경에서 입력칸 경계가 거의 안 보임. 저시력 사용자는 어디가 입력칸인지 모름.
• 올바른 예: 배경과 충분히 대비되는 테두리. 미관보다 가시성이 먼저. 형태의 "옅음"이 접근성을 해치지 않게.

위반 3) 페이지마다 형태가 다름

영역별로 다른 업체가 만들어, 한 사이트 안에서 모서리가 갈림.

• 나쁜 예: 메인은 8px, 게시판은 0px, 신청은 4px. 사용자가 영역을 넘을 때마다 "다른 사이트인가?" 위화감.
• 올바른 예: 전사 토큰을 정해 모든 영역이 공유. 외주 발주 시 "형태는 KRDS 토큰을 따른다"를 계약·검수 항목에 명시.

위반 4) 그림자 남발로 층위가 무너짐

"떠 있는 느낌"을 강조하려고 모든 요소에 진한 그림자.

• 나쁜 예: 카드도 버튼도 입력도 다 진한 그림자. 뭐가 위에 있는지 알 수 없음. 화면이 어수선.
• 올바른 예: 그림자는 절제. 정말 떠 있어야 하는 모달·드롭다운에만 깊게, 나머지는 얕거나 없게. 그림자도 단계를 토큰화.

위반 5) 모달인데 떠 있어 보이지 않음

팝업에 그림자도 오버레이도 없어 배경과 붙어 보임.

• 나쁜 예: 모달이 페이지 위에 평평하게 얹혀, 새 창인지 페이지 일부인지 헷갈림.
• 올바른 예: 충분한 그림자 + 뒤 배경 어둡게(오버레이)로 "확실히 위에 떠 있음"을 표현.

위반 6) 외부 위젯만 형태가 튐

달력·지도·차트 같은 외부 위젯이 자기 형태를 그대로 들고 옴.

• 나쁜 예: 사이트는 둥근데 박아 넣은 달력 위젯만 각지고 그림자도 다름. 화면 속 이물질처럼 보임.
• 올바른 예: 위젯 스타일 옵션으로 우리 토큰에 맞추거나, 최소한 감싸는 컨테이너 형태라도 통일.

위반 7) 모바일에서 형태가 깨짐

데스크톱만 보고 배포해, 모바일에서 형태가 찌그러짐.

• 나쁜 예: 작아진 버튼에 고정 px 모서리가 그대로라 과하게 둥글어 보이고, 그림자가 화면 밖으로 잘림.
• 올바른 예: 반응형에서도 형태가 같은 인상을 유지하는지 모바일로 확인. 크기별 적절한 토큰 적용.

자동 자가진단 — ViewCheck로 전 페이지를 한 번에

손으로 하는 점검은 메인 한 장에선 유효하지만, 사이트 전체를 보려면 한계가 분명합니다. 여기서부터가 ViewCheck가 필요한 지점입니다.

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

손으로 하는 점검과 비교하면 차이가 명확합니다. 사람은 메인 한 장 보는 데 5분, 100페이지면 하루가 꼬박 걸리고 그마저도 눈으로 1px 차이를 다 잡아내긴 어렵습니다. ViewCheck는 각 요소의 border-radius, 테두리, 그림자 값을 computed style(브라우저가 실제로 계산한 최종 값)로 정확히 읽어, KRDS 토큰과 수치로 비교합니다. 사람의 눈이 "뭔가 안 맞는 느낌"으로 감지하는 것을, 도구는 "이 버튼은 7px, 토큰은 8px"처럼 수치로 짚어 주는 거죠.

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

• 모서리 반경 토큰 채택률: 사이트에서 쓰인 border-radius 값들이 KRDS 토큰에 얼마나 들어맞는지. 토큰 밖의 임의 값이 얼마나 섞여 있는지.
• 컴포넌트별 형태 일관성: 같은 종류의 컴포넌트(버튼·카드·입력)가 같은 형태를 갖는지, 페이지마다 다른지.
• 테두리·그림자 일관성: 테두리 두께·색, 그림자 깊이가 규칙을 따르는지.
• 대비: 테두리·경계가 배경과 충분히 구분되는지(대비 분석과 연계).

여기서 ViewCheck의 핵심 자산이 디자인 토큰 채택률 리포트입니다. 단순히 "위반이다/아니다"를 넘어, "우리 사이트가 KRDS가 정한 형태 값을 몇 %나 따르고 있는가"를 비율로 보여 줍니다. 이 숫자가 낮으면 형태가 제멋대로라는 뜻이고, 높으면 잘 관리되고 있다는 뜻입니다. 점검 전후의 이 숫자를 비교하면, "고친 게 실제로 효과가 있었는지"도 객관적으로 확인됩니다.

Vision AI가 보강하는 부분

DOM(코드)만으로 판단하기 어려운 시각적 부분 — 예를 들어 이미지로 박아 넣은 버튼이나, CSS가 아니라 배경 이미지로 그림자를 표현한 경우 — 은 KRDScan Vision AI가 스크린샷을 함께 보고 보강 판정합니다. 그래서 "코드엔 모서리 속성이 없는데 화면엔 분명히 둥근 버튼이 있는" 비표준 구현도 놓치지 않습니다. 사람이 눈으로 보듯 화면을 함께 보기 때문에, 표준을 우회해 만든 UI까지 잡아내는 게 단순 코드 검사 도구와 다른 점입니다.

리포트를 어떻게 읽나 — 형태 결과 해석법

분석이 끝나면 디자인 시스템 탭에서 형태 관련 규칙의 통과/미통과 수와, 토큰 채택률, 그리고 미통과한 항목의 위치(어느 페이지)·이유·개선 방법(howToFix)이 함께 나옵니다.

리포트를 읽는 순서를 권하자면 이렇습니다. 첫째, 토큰 채택률 숫자를 먼저 보세요. 이게 전체 형태 건강도의 요약입니다. 둘째, 미통과 항목의 위치를 보세요. 특정 페이지에 몰려 있다면(예: 게시판 영역만 형태가 어긋남), 그 영역을 통째로 손보는 게 효율적입니다. 셋째, 이유를 보세요. "토큰 밖 값 사용"인지 "컴포넌트 간 불일치"인지에 따라 고치는 방법이 다릅니다.

여러 페이지를 한꺼번에 분석하면, "메인의 버튼은 8px로 통일됐는데 신청 페이지의 버튼만 4px이다" 같은 페이지별 편차가 한눈에 드러납니다. 손으로는 두 페이지를 번갈아 봐야 알 수 있는 걸, 리포트는 한 표에 정리해 줍니다. 이게 다중 페이지 분석의 진짜 가치입니다 — 사람의 기억력으로는 페이지 간 비교가 어렵지만, 도구는 전 페이지를 동시에 펼쳐 놓고 비교하니까요.

그리고 어디부터 고쳐야 하는지 우선순위(P0~P3)도 함께 매겨집니다. 형태는 접근성을 완전히 막는 종류는 아니지만(예외: 대비 부족), 일관성·신뢰감에 직결되므로 적절한 우선순위로 다루면 됩니다. 막연한 "형태 정리하자"가 아니라 "이 페이지의 이 버튼을 8px로 맞추자"는 구체적인 작업 목록이 나오는 셈입니다.

직접 적용하기 — 점검 결과를 고치는 법

자가진단으로 어긋난 곳을 찾았다면, 다음은 고치기입니다. 역할별로 정리하겠습니다.

개발자라면 — 가장 확실한 해법은 형태 값을 CSS 변수(토큰)로 중앙화하는 것입니다. --radius-button: 8px 같은 변수를 한 곳에 정의하고, 모든 버튼이 이 변수를 쓰게 하면, 값이 어긋날 여지가 사라집니다. 더 좋은 건 KRDS 컴포넌트 킷을 가져다 쓰는 겁니다. npm install krds-uiux로 설치하거나 CDN(krds.min.css / krds.min.js)으로 불러오면, 형태 토큰이 이미 정의된 상태로 시작할 수 있습니다. 저장소의 html/code 폴더에 표준 컴포넌트 코드가 그대로 들어 있어, 모서리·테두리·그림자가 기준에 맞춰진 채로 가져다 쓸 수 있죠. "이미 박힌 임의 값들을 일일이 찾아 고치는" 수작업 대신, 토큰 기반으로 한 번 정리해 두면 이후엔 자동으로 일관성이 유지됩니다.

디자이너라면 — KRDS 공식 Figma(@krds) 라이브러리에서 형태가 정의된 표준 컴포넌트를 가져다 쓰세요. 직접 사각형을 그리고 모서리를 즉흥적으로 둥글게 하지 말고, 표준 컴포넌트를 배치하면 시안 단계에서부터 형태가 토큰에 맞춰집니다. 시안과 실제 구현 사이의 간극도 줄어들고요. 그리고 팀 내에 "우리가 쓰는 모서리 값은 이 서너 개뿐"이라는 규칙을 명문화해 두면, 새 화면을 그릴 때마다 어긋나는 일을 막을 수 있습니다.

기획자라면 — 화면 정의서나 디자인 가이드에 "버튼/카드/입력의 형태는 KRDS 토큰을 따른다"는 한 줄을 박아 두세요. 외주를 줄 때도 이 한 줄이 있으면 "각 업체가 자기 기준으로 형태를 정하는" 갈라짐을 사전에 막을 수 있습니다. 검수 단계에서 "형태가 토큰을 따르는가"를 체크 항목으로 넣는 것도 좋습니다.

형태를 고칠 때 흔히 하는 실수 — 그리고 올바른 방향

점검 후 고치는 과정에서도 함정이 있습니다. 자가진단만큼이나 "제대로 고치기"도 중요하니, 자주 빠지는 실수를 짚어 두겠습니다.

실수 1) 눈에 띄는 것만 고치고 토큰은 안 만든다

메인의 버튼 몇 개만 8px로 맞추고 끝냅니다. 그러면 다음에 새 페이지를 만들 때 또 어긋납니다. 올바른 방향: 개별 요소를 고치기 전에 먼저 토큰(CSS 변수)을 정의하고, 모든 요소가 그 토큰을 참조하게 구조를 바꾸세요. 근본을 안 고치면 형태 부채는 계속 다시 쌓입니다.

실수 2) 일관성을 위해 모든 걸 똑같이 만든다

"통일이 중요하다니까 모서리를 전부 같게" 하면, 버튼도 카드도 모달도 다 같은 모서리가 됩니다. 그런데 컴포넌트마다 적절한 형태는 다를 수 있습니다. 올바른 방향: "같은 종류끼리 같게"가 원칙이지, "모든 종류를 같게"가 아닙니다. 버튼은 버튼끼리, 카드는 카드끼리 통일하되, 컴포넌트 종류별로는 KRDS가 정한 적절한 값을 따르세요.

실수 3) 그림자를 과하게 쓴다

"떠 있는 느낌"을 강조하려고 모든 요소에 진한 그림자를 답니다. 그러면 화면의 층위가 무너져 뭐가 위에 있는지 알 수 없게 됩니다. 올바른 방향: 그림자는 절제해서, 정말 떠 있어야 하는 것(모달·드롭다운)에만 깊게, 나머지는 얕거나 없게. 그림자도 토큰화해서 "얕음/보통/깊음" 같은 정해진 단계만 쓰는 게 좋습니다.

실수 4) 테두리를 너무 연하게 한다

깔끔해 보이려고 입력창 테두리를 아주 연한 회색으로 합니다. 그러면 저시력 사용자에게 입력칸 경계가 안 보입니다. 올바른 방향: 테두리는 배경과 충분히 대비되게. 형태의 "예쁨"이 가시성을 해치면 안 됩니다. 대비가 부족한 테두리는 미관이 아니라 접근성 문제로 다뤄야 합니다.

실수 5) 모바일을 안 보고 끝낸다

데스크톱에서 형태를 다 맞추고 배포한 뒤, 모바일은 확인 안 합니다. 올바른 방향: 반응형으로 크기가 변할 때 형태가 어떻게 보이는지 반드시 모바일에서 확인하세요. 모서리는 보통 비율이 아니라 고정 px이라, 요소가 작아지면 상대적으로 더 둥글어 보일 수 있습니다.

자주 묻는 질문

형태를 점검·정리할 때 현장에서 반복되는 질문들을 모았습니다.

Q. 모서리를 둥글게 하는 게 좋나요, 각지게 하는 게 좋나요?

정답은 없습니다. 둘 다 디자인 콘셉트의 선택입니다. 중요한 건 "골랐으면 일관되게 지키는 것"입니다. KRDS는 정해진 토큰 값을 제공하니, 그 안에서 컴포넌트 종류별로 적절한 값을 쓰면 됩니다. 자가진단의 관심사는 "둥근가 각진가"가 아니라 "같은 것끼리 같은가"입니다.

Q. border-radius 값이 1px 정도 차이 나는 건 정말 문제인가요?

하나만 보면 문제가 아닙니다. 하지만 같은 화면에 여러 요소가 1px씩 어긋나 있으면, 사람 눈은 "정렬이 안 맞는 느낌"을 받습니다. 그리고 1px 차이를 허용하기 시작하면 곧 2px, 5px로 번집니다. 그래서 "토큰 값만 쓴다"는 규칙을 1px 단위까지 지키는 게 장기적으로 편합니다. 점검에서 토큰 밖 값이 보이면, 작아 보여도 토큰으로 맞춰 두세요.

Q. 우리 브랜드만의 독특한 형태를 쓰고 싶은데, KRDS를 따라야 하나요?

브랜드 표현이 필요한 영역(메인 비주얼, 캠페인 페이지)에서는 어느 정도 자유가 있습니다. 다만 버튼·입력·카드 같은 기능 컴포넌트의 형태까지 독창적으로 만들면, 사용자가 "이게 버튼인지 태그인지" 헷갈립니다. 기능 컴포넌트는 표준을, 브랜드 표현은 별도 영역에서 — 그리고 어느 쪽이든 사이트 안에서는 일관되게 쓰는 게 원칙입니다.

Q. 외부 위젯(달력, 지도, 차트)은 형태가 우리와 다른데 어쩌죠?

외부 위젯이 자기 형태를 들고 오는 건 흔한 일입니다. 가능하면 위젯의 스타일 옵션으로 모서리·테두리를 우리 토큰에 맞추고, 그게 안 되면 위젯을 감싸는 컨테이너의 형태라도 통일하세요. 완벽히 맞추기 어렵더라도, 최소한 "우리 화면 안에서 위젯만 튀어 보이지 않게" 하는 게 목표입니다.

Q. 그림자(elevation)는 꼭 써야 하나요? 플랫 디자인이 더 깔끔하던데요?

꼭 써야 하는 건 아닙니다. 그림자를 거의 안 쓰는 플랫한 스타일도 유효합니다. 다만 모달이나 드롭다운처럼 "확실히 위에 떠 있어야 하는" 요소는, 그림자가 없으면 배경과 붙어 보여 혼란을 줄 수 있습니다. 그림자를 쓰든 안 쓰든, "층위가 구분되는가"가 판단 기준입니다. 그림자 대신 테두리나 배경 대비로 층위를 표현하는 것도 방법입니다.

Q. 점검했더니 형태 위반이 수백 개 나옵니다. 다 고쳐야 하나요?

전부 한 번에 갈아엎을 필요는 없습니다. 먼저 토큰을 정의하고, 사용 빈도가 높은 핵심 컴포넌트(버튼·입력·카드)부터 토큰을 적용하세요. 이 셋만 정리해도 화면의 "정돈된 느낌"이 크게 좋아집니다. 그다음 페이지별 편차가 심한 영역(보통 외주로 만든 게시판 등)을 차례로 손보면 됩니다. ViewCheck 리포트의 우선순위와 위치 정보를 따라가면, 적은 작업으로 가장 눈에 띄는 개선을 얻을 수 있습니다.

Q. 디자인팀은 "형태는 자유"라 하고, 개발팀은 "토큰을 달라"고 합니다.

둘 다 일리가 있습니다. 디자인의 자유는 메인·캠페인 같은 표현 영역에서, 토큰의 엄격함은 기능 컴포넌트에서. 이 경계를 명확히 나눠 두면 충돌이 줄어듭니다. KRDS가 디자인(Figma)·코드(GitHub 킷)·문서(가이드라인)를 한 세트로 제공하는 이유가 이겁니다 — 같은 토큰을 디자인과 개발이 공유하면, "자유냐 통일이냐"의 소모적 논쟁 대신 "어느 영역이냐"의 합의로 바뀝니다.

Q. 자가진단은 얼마나 자주 해야 하나요?

형태 부채는 새 페이지가 추가될 때, 외주가 들어왔다 나갈 때, 리뉴얼이 있을 때 쌓입니다. 그래서 "큰 변경이 있을 때마다" 한 번씩 돌려 보는 게 좋습니다. ViewCheck로 정기적으로(예: 분기마다, 또는 배포 전마다) 토큰 채택률을 찍어 두면, 형태가 다시 어긋나기 시작하는 시점을 조기에 잡을 수 있습니다. 점수가 떨어지기 시작하면 부채가 쌓이고 있다는 신호입니다.

Q. 형태 위반은 접근성 문제인가요, 아니면 단순 미관 문제인가요?

대부분은 미관·일관성 문제지만, 일부는 명백한 접근성 문제입니다. 테두리 대비가 부족해 입력칸 경계가 안 보이는 경우, 색으로만 오류 상태를 표시하는 경우가 그렇습니다. 그래서 형태를 "사소한 디테일"로만 보면 안 됩니다. 자가진단에서 대비 관련 항목은 미관이 아니라 접근성 우선순위로 다루고, 나머지 일관성 항목은 신뢰감·완성도 차원에서 다루면 균형이 맞습니다. ViewCheck 리포트도 이 둘을 구분해 우선순위를 매겨 줍니다.

Q. 토큰을 새로 도입하면 기존 화면이 다 바뀌지 않나요?

토큰을 도입한다고 해서 반드시 화면이 크게 바뀌는 건 아닙니다. 현재 가장 많이 쓰이는 형태 값을 토큰의 기준값으로 삼으면, 다수 화면은 그대로 두고 소수의 어긋난 값만 맞추는 식으로 부드럽게 전환할 수 있습니다. 즉 "지금 사이트가 대체로 8px이면 8px을 표준 토큰으로 정하고, 4px·6px로 튄 것만 8px로 맞춘다"는 접근입니다. 처음부터 완전히 새 값으로 갈아엎기보다, 현황을 토큰으로 추인하고 예외만 정리하는 게 현실적이고 안전합니다.

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

자가진단을 돌리면 형태 문제가 한두 개로 끝나지 않는 경우가 많습니다. 그래서 우선순위가 중요합니다. 형태 문제를 영향도 순으로 정리하면 대략 이렇습니다.

가장 먼저(치명적) — 테두리·경계의 대비 부족으로 입력칸이 안 보이는 경우. 이건 미관이 아니라 접근성 문제라 1순위입니다. 저시력 사용자가 "어디가 입력칸인지" 모르면 폼을 채울 수 없으니까요. 특히 신청·로그인처럼 핵심 경로의 입력창부터 확인하세요.

그다음(높음) — 핵심 컴포넌트(버튼·입력·카드)의 형태 불일치. 사용자가 가장 자주 마주치고, 신뢰감에 가장 크게 영향을 주는 요소들입니다. 메인과 주요 서비스 페이지의 버튼·입력 형태를 토큰으로 통일하는 게 가장 효과가 큽니다.

그 후(보통) — 페이지별 형태 편차, 그림자 층위 혼란, 모바일에서의 형태 깨짐. 사용은 가능하지만 "어딘가 허술해 보이는" 인상을 주는 문제들입니다. 외주로 만든 영역의 형태를 본체에 맞추는 작업이 여기 들어갑니다.

여력이 되면(낮음) — 토큰 밖 값을 토큰으로 정밀하게 맞추기, 외부 위젯 형태 통일 같은 마무리 작업. 큰 인상 차이는 아니지만, 토큰 채택률을 끌어올려 형태를 "완성"하는 항목입니다.

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

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

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

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

공식 자료는 "정답지"이고, ViewCheck는 "내 답안을 채점해 주는 도구"라고 생각하시면 됩니다. 기준을 이해하고(가이드라인) → 내 사이트가 그 기준에 맞는지 확인하고(ViewCheck) → 표준 토큰·컴포넌트로 고치는(킷·Figma) 한 바퀴를 돌리면, 형태가 점점 정돈됩니다.

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

마지막으로, 디자이너·개발자·기획자가 형태를 점검할 때 바로 쓸 수 있는 체크리스트로 정리합니다. 우리 사이트를 열어 놓고 한 줄씩 확인해 보세요.

• ☐ 같은 종류의 버튼들이 같은 모서리 반경을 갖는다(둥근 것/각진 것이 섞이지 않았다).
• ☐ 입력창들의 테두리 두께·색·모서리가 통일돼 있다.
• ☐ 입력창·카드의 테두리가 배경과 충분히 대비된다(연해서 안 보이지 않는다).
• ☐ 같은 종류의 카드들이 같은 모서리·그림자를 갖는다.
• ☐ 그림자 깊이가 층위와 맞는다(모달은 깊게, 카드는 얕게, 같은 층위끼리 같게).
• ☐ 모서리·그림자·테두리 값이 정해진 토큰 안에 있다(임의 값이 흩어져 있지 않다).
• ☐ 모바일에서도 형태가 데스크톱과 같은 인상을 유지한다(찌그러짐·잘림 없음).
• ☐ 형태가 요소의 역할과 어울린다(주요 버튼이 태그처럼 보이지 않는다).
• ☐ 외부 위젯·외주 영역의 형태가 본체와 튀지 않게 맞춰져 있다.
• ☐ (개발자) 형태 값이 CSS 변수(토큰)로 중앙화돼 있어, 어긋날 여지가 없다.

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

형태는 색이나 글꼴처럼 한눈에 "예쁘다/안 예쁘다"로 평가받지 않습니다. 대신 조용히, 화면 전체의 "정돈된 느낌"과 "신뢰감"을 좌우합니다. 모서리 하나가 어긋나도 사용자는 정확히 뭐가 문제인지 모른 채 "어딘가 허술하다"고 느낄 뿐이죠. 그 막연한 인상이 공공 서비스에 대한 신뢰로 이어진다는 걸 생각하면, 형태는 결코 사소한 디테일이 아닙니다.

오늘 정리한 자가진단은 거창해 보이지만, 핵심은 단순합니다. 같은 것은 같게, 정해진 값 안에서, 모바일까지. 이 세 가지를 가지고 우리 화면을 한 번 훑어보세요. 손으로 메인 한 장만 봐도 어긋난 곳이 보일 겁니다. 그리고 전 페이지를 정확한 수치로 확인하고 싶다면, ViewCheck로 5분이면 됩니다. 완벽을 한 번에 만들 필요는 없습니다. 가장 자주 보이는 버튼 하나의 모서리부터 토큰으로 맞춰 나가면, 우리 사이트는 분명히 조금씩 더 정돈되어 보입니다. 다음 글에서는 형태와 짝을 이루는 또 다른 디자인 스타일 요소를 같은 방식으로 — 무엇이 기준이고, 어디서 어긋나고, 어떻게 확인하는지 — 뜯어보겠습니다.

우리 사이트의 형태는 지금 몇 점일까요? krds.viewcheck.co.kr에서 URL만 넣으면, 모서리·테두리·그림자가 KRDS 토큰을 얼마나 따르는지 무료로 확인할 수 있습니다. 메인 페이지 하나만 돌려 봐도, 위 체크리스트가 실제로 지켜지고 있는지 수치로 바로 보입니다.

#KRDS #형태Shape #모서리반경 #디자인토큰 #디자인시스템 #공공웹 #웹접근성 #UIUX #ViewCheck #정부웹사이트 #형태 #Shape #자가진단 #체크리스트 #점검항목 #디자인스타일 #전자정부 #디지털정부 #행정안전부 #공공기관