운영기관 식별자(Identifier) 자가진단 — ViewCheck 5분 점검

낯선 정부 사이트에 처음 들어갔을 때, 우리는 무의식적으로 화면 맨 위와 맨 아래를 한 번씩 훑습니다. "여기가 어디 사이트지?" "이거 진짜 공식 사이트 맞나?" 이 두 질문에 답해 주는 게 바로 운영기관 식별자(Identifier)입니다. 헤더 왼쪽 위의 기관 로고와 이름, 그리고 푸터의 기관명·주소·연락처·사업자 정보 같은 것들요. 평소엔 눈에 잘 안 들어오지만, 막상 "이 사이트 믿어도 되나" 싶을 때 우리 눈이 가장 먼저 찾는 게 이 영역입니다.

그런데 이 식별자라는 게, 만드는 입장에서는 "그냥 로고 하나 박고 푸터에 주소 적으면 되는 거 아냐?" 싶은, 가장 만만해 보이는 영역입니다. 그래서 가장 자주 대충 처리됩니다. 로고 이미지에 대체 텍스트가 없거나, 푸터 기관명이 페이지마다 다르거나, 로고를 눌러도 홈으로 안 가거나, 사칭 사이트와 구별할 단서가 부족하거나. 공공 사이트를 수백 개 분석하다 보면, 식별자에서 똑같은 실수가 끝없이 반복되는 걸 봅니다.

이 글은 "KRDS 완전해부" 시리즈 중에서도 조금 결이 다릅니다. 앞선 글들이 "KRDS는 이걸 이렇게 요구한다"는 기준 해부에 무게를 뒀다면, 이번 글은 "그래서 우리 사이트의 식별자는 지금 어떤 상태인가"를 직접 확인하는 자가진단에 초점을 맞춥니다. 5분이면 됩니다. 커피 한 잔 내리는 시간이면, 우리 사이트의 식별자가 KRDS 기준을 지키는지 — 적어도 어디가 문제인지 — 대략 파악할 수 있습니다. 그 진단 과정을 하나하나 따라가 보겠습니다.

미리 한마디 하자면, 식별자는 "잘 만들어도 칭찬받기 어려운" 영역입니다. 로고 alt를 제대로 넣고 푸터 정보를 일관되게 맞춰 둬도, 마우스 쓰는 사람 눈엔 그냥 평범한 헤더와 푸터일 뿐이거든요. 하지만 한 번 무너지면 — 사칭 사이트로 의심받거나, 시각장애인이 "여기가 어딘지" 알 수 없거나, 푸터 연락처가 틀려 민원 전화가 엉뚱한 데로 가거나 — 그 파장은 작지 않습니다. 조용히 제 일을 하는 영역일수록, 한 번 점검해 둘 가치가 있습니다.

운영기관 식별자가 대체 뭔가 — 정의부터 정확히

먼저 용어부터 맞추겠습니다. KRDS(대한민국 정부 디자인 시스템)에서 말하는 운영기관 식별자(Identifier)는, 한마디로 "이 서비스를 누가 운영하는지를 사용자에게 분명히 알려 주는 시각·정보 요소"입니다. 영문으로는 Identifier. 단순히 로고 하나를 가리키는 게 아니라, 사이트 곳곳에서 "이 사이트의 주인이 누구인가"를 일관되게 드러내는 장치 전체를 뜻합니다.

구체적으로 식별자가 담당하는 자리는 크게 두 곳입니다.

헤더(상단)의 기관 식별 영역: 보통 화면 왼쪽 위에 놓이는 기관 로고와 서비스명. 사용자가 페이지에 들어오자마자 "여기가 ○○부/○○시/○○공단의 서비스구나"를 인지하는 첫 지점입니다. 그리고 이 로고는 거의 항상 "홈으로 가는 링크" 역할도 겸합니다.
푸터(하단)의 기관 정보 영역: 기관명, 주소, 대표 전화번호, 사업자/기관 식별 정보, 저작권 표시, 관련 정책 링크 등. 사용자가 "이 사이트가 진짜 공식이 맞는지" "문의는 어디로 하는지"를 확인하는 신뢰의 마지막 보루입니다.

이 두 영역은 떨어져 있지만 하나의 목적을 공유합니다. "이 서비스는 신뢰할 수 있는 공식 기관이 운영한다"는 사실을, 보는 사람이든 듣는 사람이든 누구나 확인할 수 있게 만드는 것. KRDS가 이걸 별도 식별자로 다루는 이유가 여기 있습니다. 공공 서비스에서 "주인이 분명한가"는 디자인 취향의 문제가 아니라, 신뢰와 안전의 문제이기 때문입니다.

왜 식별자가 "신뢰"의 문제인가

상업 사이트라면 로고가 좀 흐릿해도, 푸터 정보가 부실해도 큰일은 안 납니다. 그런데 공공 서비스는 다릅니다. 사용자가 그 사이트에서 주민등록 등본을 떼고, 세금을 내고, 개인정보를 입력합니다. 그래서 "이게 진짜 공식 사이트인가"라는 확신이 무엇보다 중요합니다.

피싱·사칭 사이트는 바로 이 식별자를 흉내 냅니다. 진짜와 똑같은 로고를 가져다 붙이고, 비슷한 도메인을 씁니다. 그렇다면 진짜 공식 사이트는 더더욱, 자신의 정체를 분명하고 일관되게 드러내야 합니다. 헤더 로고, 푸터 기관 정보, 정책 링크가 모든 페이지에서 한결같이 정확하게 나타나는 것 — 이게 사용자가 "아, 여기는 믿을 수 있는 곳"이라고 판단하는 근거가 됩니다. 식별자가 들쭉날쭉하거나 빈약하면, 진짜 공식 사이트인데도 어쩐지 미덥지 않게 느껴집니다.

KRDS는 운영기관 식별자에 무엇을 요구하나 — 기준 해부

이제 본론입니다. KRDS 가이드라인(디지털 정부서비스 UI/UX 가이드라인, 2025.08판)과 컴포넌트 문서, 그리고 확립된 웹 접근성 기준(KWCAG)을 종합해, 운영기관 식별자가 충족해야 하는 요건을 영역별로 정리하겠습니다. 자가진단의 "정답지"에 해당하는 부분이니, 천천히 보시면 좋겠습니다.

1) 기관 로고에는 의미 있는 대체 텍스트가 있어야 한다

헤더의 기관 로고는 거의 항상 이미지(SVG 또는 PNG)로 들어갑니다. 그리고 이 로고 이미지는 단순한 장식이 아니라 정보를 가진 이미지입니다. "이 사이트는 ○○기관이 운영한다"는 핵심 정보를 담고 있으니까요.

그래서 로고 이미지에는 반드시 대체 텍스트(alt)가 있어야 합니다. 스크린리더가 "○○부 누리집, 홈으로 이동"처럼 읽어 줄 수 있도록요. 만약 로고 이미지에 alt가 비어 있거나 "logo", "image", "img_01.png" 같은 무의미한 값이 들어 있으면, 시각장애인 사용자는 페이지에 들어오자마자 "여기가 어딘지"를 알 수 없습니다. 가장 먼저 만나는 요소가 가장 먼저 무너지는 셈입니다.

여기서 한 가지 더. 로고가 보통 홈 링크를 겸하기 때문에, 대체 텍스트는 "기관명 + 동작"을 함께 담는 게 좋습니다. 예를 들어 단순히 "○○부"가 아니라 "○○부 홈페이지, 메인으로 이동"처럼요. 그래야 스크린리더 사용자가 "이게 그냥 그림인지, 누르면 홈으로 가는 링크인지"까지 파악할 수 있습니다.

2) 로고는 홈으로 가는 링크여야 한다

이건 거의 모든 웹사이트의 관습이자, 공공 서비스에서는 사실상 요건에 가깝습니다. 사용자가 사이트 어디에 있든, 헤더 로고를 누르면 메인(홈)으로 돌아간다는 것. 이 약속은 워낙 보편적이라, 사용자는 길을 잃었을 때 무의식적으로 로고를 클릭합니다.

그런데 의외로 이게 깨진 사이트가 많습니다. 로고가 그냥 이미지로만 박혀 있어서 눌러도 아무 반응이 없거나, 링크는 걸려 있는데 엉뚱한 페이지로 가거나, 서브 페이지에서는 링크가 빠져 있거나. 로고 클릭으로 홈에 못 가면, 특히 키보드 사용자나 익숙하지 않은 사용자는 "어떻게 처음으로 돌아가지?"에서 한참 헤맵니다.

코드 수준으로 보면, 로고 이미지가 <a> 링크로 감싸여 있고, 그 링크가 사이트 루트(/ 또는 메인 URL)를 가리켜야 합니다. 그리고 그 링크는 키보드로도 접근·실행 가능해야 합니다(Tab으로 도달, Enter로 실행).

3) 헤더 식별 영역은 모든 페이지에서 일관되게 나타나야 한다

식별자의 핵심 가치는 일관성입니다. 메인 페이지에서는 로고가 또렷하게 보이는데, 신청 페이지나 검색 결과 페이지에 들어가니 로고가 작아지거나 사라지거나 위치가 바뀌면, 사용자는 "여기 같은 사이트 맞나?" 하고 불안해집니다.

KRDS가 식별 영역을 표준화해 두는 이유가 이겁니다. 어느 페이지에 있든 헤더 왼쪽 위에 같은 로고가, 같은 자리에, 같은 동작으로 있어야 한다는 것. 이 일관성이 곧 "이 사이트는 처음부터 끝까지 같은 기관이 책임지고 운영한다"는 신호입니다. 다중 페이지로 운영되는 공공 사이트일수록 이 항목이 중요합니다 — 페이지가 수십·수백 개인데 식별자가 페이지마다 제각각이면, 신뢰도 그만큼 새어 나갑니다.

4) 푸터에는 기관 정보가 정확하고 충분하게 들어가야 한다

푸터는 식별자의 또 다른 절반입니다. 사용자가 "이 사이트가 진짜 공식인가" "문의는 어디로 하나"를 확인하는 곳이죠. KRDS와 공공 웹 운영 관행을 종합하면, 푸터 기관 정보 영역에는 대체로 다음이 포함됩니다.

기관명(정식 명칭): 약칭이 아니라 정식 기관명. 사용자가 검색하거나 대조할 수 있는 형태로.
주소: 기관 소재지.
대표 연락처: 전화번호, 가능하면 운영 시간이나 콜센터 정보까지.
저작권 표시: "Copyright ○○기관. All rights reserved." 같은 권리 표시.
관련 정책 링크: 개인정보처리방침, 이용약관, 저작권 정책, 웹 접근성 안내 등.

여기서 중요한 건 "있다/없다"만이 아니라 "정확한가"입니다. 기관 통폐합·이전·연락처 변경이 있었는데 푸터는 옛날 정보 그대로인 경우가 적지 않습니다. 푸터 연락처가 틀리면, 그 사이트를 통해 문의하려던 사용자가 엉뚱한 곳에 전화를 걸게 됩니다. 작은 텍스트 하나가 행정 혼선으로 이어지는 거죠.

5) 개인정보처리방침은 특별 취급 — 강조와 접근성

푸터의 여러 정책 링크 중에서도 개인정보처리방침은 특별합니다. 법적으로도, 사용자 신뢰 측면에서도 가장 중요한 링크라, 흔히 다른 링크보다 강조(굵게 표시 등)해 둡니다. 공공 서비스는 개인정보를 다루는 경우가 많으니, "우리는 당신의 정보를 이렇게 다룬다"를 명시한 이 링크가 명확하게 보여야 합니다.

자가진단 관점에서 보면, 개인정보처리방침 링크가 ① 푸터에 존재하는가, ② 클릭하면 실제 방침 페이지로 가는가(깨진 링크 아닌가), ③ 키보드·스크린리더로 접근 가능한가 — 이 세 가지를 확인해야 합니다. 의외로 "링크는 있는데 클릭하면 404"인 경우가 종종 있습니다.

6) 정책 링크들은 키보드·스크린리더로 접근 가능해야 한다

푸터의 정책 링크들이 마우스로만 눌리고 키보드로는 접근 안 되는 경우가 있습니다. 푸터를 화려하게 만들겠다고 <div>에 클릭 이벤트만 붙인 "가짜 링크"로 구현하면 이런 일이 생깁니다. 정책 링크는 진짜 <a> 요소로 만들어, Tab으로 도달하고 Enter로 열 수 있어야 합니다. 그리고 링크 텍스트가 "여기", "바로가기"처럼 모호하지 않고, "개인정보처리방침"처럼 목적지를 분명히 알려 주는 게 좋습니다. 스크린리더 사용자는 링크 목록만 따로 듣는 경우가 많은데, "여기 여기 여기"만 줄줄이 읽히면 어디로 가는 링크인지 알 수 없습니다.

7) 식별 영역의 색 대비와 가독성

로고와 기관명, 푸터 정보 텍스트는 배경과 충분한 명도 대비를 가져야 합니다. 푸터를 짙은 색 배경으로 만들고 글씨를 어두운 회색으로 두면, 저시력 사용자에게는 거의 안 보입니다. 연한 회색 글씨로 푸터 정보를 깨알같이 적어 두는 것도 흔한 실수입니다. 식별자는 "신뢰를 주는 정보"인데, 그 정보가 안 보이면 신뢰를 줄 수 없습니다.

8) 텍스트 로고 vs 이미지 로고

기관 로고를 이미지로 넣을 수도 있고, CSS로 디자인한 텍스트로 넣을 수도 있습니다. 이미지 로고는 위에서 본 대로 alt가 필수이고, 텍스트 로고라면 그 자체가 읽히므로 alt 문제는 없지만 대신 색 대비·확대 시 깨짐 여부를 봐야 합니다. 어느 쪽이든 핵심은 동일합니다 — "보는 사람도, 듣는 사람도, 확대하는 사람도 기관명을 분명히 알 수 있는가."

정리하면, KRDS의 식별자 기준은 세 축으로 요약됩니다. ① 명료성(로고에 의미 있는 대체 텍스트, 푸터에 정확한 기관 정보), ② 일관성(모든 페이지에서 같은 식별 영역), ③ 접근성(로고·정책 링크가 키보드·스크린리더로 접근 가능, 충분한 색 대비). 이 세 축이 그대로 우리가 자가진단할 항목이 됩니다.

왜 이렇게까지 따지나 — 식별자의 원리와 배경

여기까지 읽고 "로고랑 푸터 가지고 뭐 이리 까다롭나" 싶으실 수 있습니다. 그런데 이 요건들은 누가 괜히 만들어 낸 규칙이 아니라, 실제로 사용자가 막히거나 속는 지점에서 역으로 도출된 것들입니다.

첫인상은 식별자에서 결정된다

사용자가 사이트에 들어와 가장 먼저 보는 게 헤더입니다. 그리고 "여기 어디지?"라는 질문에 0.5초 안에 답을 못 주면, 사용자는 불안해집니다. 비장애인은 로고를 "보고" 순간적으로 기관을 인지합니다. 그런데 스크린리더 사용자는 이 "보는" 과정이 없습니다. 코드가 알려 주는 정보가 전부입니다. 로고 alt가 비어 있으면, 그들에게 이 사이트는 "정체불명의 어딘가"로 시작합니다. 첫 단추부터 어긋나는 거죠.

식별자는 사칭 방어의 최전선이다

앞서 말했듯 피싱 사이트는 식별자를 흉내 냅니다. 그렇다면 진짜 공식 사이트가 할 수 있는 가장 강력한 방어는, 자신의 정체를 누구도 의심할 수 없을 만큼 분명하고 일관되게 드러내는 것입니다. 모든 페이지의 헤더 로고, 푸터 기관명·주소·연락처, 정책 링크가 정확하게 일치하면, 사용자는 자연스럽게 "여기는 진짜"라고 신뢰합니다. 반대로 식별자가 빈약하거나 페이지마다 다르면, 진짜인데도 가짜처럼 느껴집니다. 식별자 점검은 단순한 디자인 검수가 아니라 신뢰 관리이자 보안의 일부인 셈입니다.

"안 쓸 자유"가 없는 사용자를 위하여

공공 서비스의 특수성을 다시 짚어야 합니다. 상업 사이트는 불편하면 떠나면 그만이지만, 주민등록 등본을 떼거나 건강보험을 신청하는 일은 그 사이트가 아니면 할 수 없습니다. 사용자에게 "안 쓸 자유"가 없어요. 그래서 식별자가 누군가에게 작동하지 않으면 — 시각장애인이 기관을 인지하지 못하거나, 키보드 사용자가 로고로 홈에 못 가거나, 푸터 연락처가 틀려 문의를 못 하거나 — 그건 단순한 불편이 아니라 행정 서비스 접근권의 손상입니다.

가장 덜 주목받는 곳에서 신뢰가 샌다

역설적이지만, 헤더와 푸터처럼 "늘 있는, 그래서 당연한" 영역일수록 품질 관리에서 밀려납니다. 메인 비주얼이나 핵심 기능에는 모두가 눈을 부릅뜨지만, 헤더 로고 alt나 푸터 텍스트에는 아무도 깐깐하게 굴지 않습니다. 그런데 사용자가 "이 사이트 믿어도 되나"를 판단하는 건 바로 이 영역입니다. 가장 덜 주목받는 곳이 사실은 신뢰의 길목인 셈입니다. KRDS가 식별자를 표준 항목으로 다루는 건, 바로 이 "방치되기 쉬운 곳"에서 신뢰가 새는 걸 막기 위해서입니다.

일관성이 곧 학습 비용 절감

KRDS가 식별자의 위치와 구성을 표준화하는 또 다른 이유는 일관성입니다. 정부 사이트마다 로고 위치가 제각각이고 푸터 구성이 천차만별이면, 사용자는 사이트를 옮길 때마다 "여기선 기관 정보가 어디 있지?"를 다시 찾아야 합니다. 모든 공공 서비스의 식별 영역이 비슷한 자리에, 비슷한 방식으로 있으면, 한 번 익힌 패턴이 모든 사이트에서 통합니다. 디지털 약자에게 이 "다시 안 찾아도 됨"은 생각보다 큰 배려입니다.

한 장면 — 같은 사이트, 세 사람

추상적인 요건을 길게 늘어놓는 것보다, 한 장면을 그려 보는 게 빠를 것 같습니다. 어느 A 광역지자체의 "복지 지원금 안내" 사이트가 있다고 합시다. 헤더에 기관 로고, 푸터에 기관 정보가 있는, 평범해 보이는 사이트입니다.

먼저 마우스를 쓰는 김 주무관. 검색을 타고 서브 페이지로 바로 들어왔습니다. "어, 여기가 어디 사이트지?" 하고 왼쪽 위 로고를 봅니다. A 광역지자체 로고가 또렷하게 보이네요. 안심하고 로고를 클릭하니 메인으로 돌아갑니다. 푸터를 내려 보니 기관명·주소·대표번호·개인정보처리방침까지 다 있습니다. "제대로 된 공식 사이트구나." 김 주무관에게 이 식별자는 아무 문제가 없습니다. 그래서 이 사이트를 만든 팀도 "잘 만들었다"고 믿습니다. 자기들이 테스트할 때 늘 마우스를 썼으니까요.

이번엔 시각장애가 있는 박 선생님. 스크린리더를 켜고 같은 서브 페이지에 들어옵니다. 페이지 맨 위에서 스크린리더가 "이미지"라고만 말하고 지나갑니다. 로고에 대체 텍스트가 없거든요. "여기가 어디 사이트지?" — 비장애인이라면 0.5초에 끝낼 질문에, 박 선생님은 답을 얻지 못합니다. 푸터까지 내려가 기관명을 듣고 나서야 겨우 기관을 짐작합니다. 그마저도 푸터 정책 링크는 <div>로 만든 가짜라, 개인정보처리방침을 열려고 Enter를 눌러도 아무 반응이 없습니다. 박 선생님은 "내 정보가 어떻게 쓰이는지" 확인하지 못한 채 신청을 망설입니다.

마지막으로, 비슷한 도메인의 사칭 사이트에 잘못 들어간 이 사장님. 화면은 진짜와 거의 똑같습니다. 그런데 푸터 기관 정보가 어딘가 엉성하고, 로고를 눌러도 홈으로 안 갑니다. "진짜 공식이면 이게 이렇게 허술할 리가 없는데?" 미심쩍어 창을 닫습니다. 만약 진짜 A 광역지자체 사이트가 식별자를 빈틈없이 갖췄다면, 이 사장님은 그 대비로 사칭을 더 쉽게 알아챘을 겁니다.

같은 유형의 사이트, 같은 식별 영역. 한 사람에겐 안심의 근거이고, 다른 한 사람에겐 정체불명의 벽이며, 또 다른 사람에겐 진짜와 가짜를 가르는 잣대입니다. 그리고 이 차이는 "예산이 부족해서"나 "기술이 어려워서" 생긴 게 아닙니다. 그냥 만들 때 마우스 쓰는 비장애인만 떠올렸기 때문에 생긴 차이입니다. KRDS의 식별자 요건은, 이 세 사람의 경험을 모두 챙기기 위한 최소한의 약속입니다. 그리고 그 약속을 지켰는지는 사람이 매번 스크린리더로 확인하기 어렵기 때문에, 자동 점검이 필요한 겁니다.

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

이제 현업에서 실제로 반복되는 식별자 실수들을 보겠습니다. 모두 익명화한 일반적 사례입니다(특정 기관을 지목하지 않습니다). 자가진단할 때 "혹시 우리도 이거 아닌가?" 하고 대조해 보시면 좋습니다.

실수 1) 로고 이미지에 대체 텍스트가 없다

가장 흔하고 가장 치명적인 실수입니다. 헤더 로고를 이미지로 넣으면서 alt를 비워 두거나, "logo" "img" 같은 무의미한 값을 넣습니다.

나쁜 예: <img src="logo.png"> (alt 없음) 또는 <img src="logo.png" alt="logo">. 스크린리더는 파일명을 읽거나 그냥 "이미지"라고만 말함. 사용자는 어느 기관 사이트인지 알 수 없음.
올바른 예: <img src="logo.png" alt="○○부 누리집, 홈으로 이동">처럼 기관명과 동작을 함께 담은 대체 텍스트. 스크린리더가 "○○부 누리집, 홈으로 이동, 링크"라고 읽어 줌.

실수 2) 로고를 눌러도 홈으로 안 간다

로고가 그냥 이미지로만 박혀 있거나, 링크가 엉뚱한 곳을 가리킵니다.

나쁜 예: 로고가 <img> 단독으로 있어 클릭해도 반응 없음. 또는 서브 페이지에서만 로고 링크가 빠져 있음.
올바른 예: 로고를 <a href="/">로 감싸 사이트 루트로 연결. 모든 페이지에서 동일하게 동작. 키보드 Tab→Enter로도 홈 이동 가능.

실수 3) 페이지마다 식별 영역이 다르다

메인은 로고가 큼직한데 서브는 작아지거나 위치가 바뀌거나 사라집니다.

나쁜 예: 메인 헤더와 서브 헤더의 로고 위치·크기·동작이 제각각. 사용자가 "같은 사이트 맞나" 불안.
올바른 예: 모든 페이지에서 동일한 헤더 식별 영역(위치·크기·로고·동작) 유지. 공통 헤더 컴포넌트로 관리.

실수 4) 푸터 기관 정보가 부실하거나 틀렸다

푸터에 저작권 한 줄만 덜렁 있고 기관명·주소·연락처가 없거나, 옛날 정보 그대로입니다.

나쁜 예: "Copyright ○○. All rights reserved." 한 줄만. 또는 통폐합 전 옛 기관명·옛 전화번호가 그대로 남아 있음.
올바른 예: 정식 기관명, 주소, 대표 연락처, 저작권, 정책 링크를 정확하게. 기관 정보 변경 시 푸터도 함께 갱신하는 프로세스 마련.

실수 5) 개인정보처리방침 링크가 없거나 깨졌다

푸터에 개인정보처리방침 링크가 아예 없거나, 클릭하면 404로 갑니다.

나쁜 예: 정책 링크가 없음. 또는 링크는 있는데 페이지 이전·구조 변경으로 깨진 링크가 됨.
올바른 예: 개인정보처리방침을 푸터에 명확히(흔히 강조 표시) 두고, 링크가 실제 유효 페이지로 연결되는지 정기 점검.

실수 6) 정책 링크가 키보드로 접근 안 된다

푸터 링크를 <div> + 클릭 이벤트로 만든 "가짜 링크"라 키보드로 도달·실행이 안 됩니다.

나쁜 예: <div>개인정보처리방침</div>. 마우스로만 작동. Tab으로 도달 불가.
올바른 예: 진짜 <a href="..."> 요소로 구현. Tab 도달, Enter 실행, 스크린리더가 링크로 인식.

실수 7) 식별 영역의 색 대비가 부족하다

푸터 배경과 글씨의 명도 대비가 약하거나, 로고가 흐릿합니다.

나쁜 예: 짙은 회색 배경에 어두운 회색 글씨로 푸터 정보. 저시력 사용자에게 거의 안 보임.
올바른 예: 배경과 텍스트의 명도 대비를 충분히 확보(WCAG/KWCAG 대비 기준 준수). 로고도 또렷하게.

실수 8) 링크 텍스트가 모호하다

정책 링크 텍스트가 "여기", "바로가기", "더보기"처럼 목적지를 알 수 없습니다.

나쁜 예: "자세히 보려면 여기 클릭". 스크린리더 링크 목록에서 "여기 여기 여기"로만 읽힘.
올바른 예: "개인정보처리방침", "이용약관"처럼 목적지를 분명히 밝히는 링크 텍스트.

실수 9) 외부 시스템 연계 페이지에서 식별자가 통째로 사라진다

공공 사이트는 자체 페이지 말고도 별도 시스템(예약·결제·인증 등)으로 넘어가는 경우가 많습니다. 그런데 그 연계 페이지로 가는 순간 헤더 로고도, 푸터 기관 정보도 통째로 사라지거나 전혀 다른 모습이 되는 일이 흔합니다.

나쁜 예: 메인은 식별자가 완벽한데, 신청·결제 단계로 넘어가니 정체불명의 회색 화면. 사용자는 "내가 지금 진짜 그 기관 시스템에 있는 게 맞나?" 하고 불안. 가장 민감한 순간(개인정보·결제 입력)에 신뢰가 흔들림.
올바른 예: 연계 페이지에도 최소한의 식별 영역(기관 로고·서비스명·돌아가기 링크)을 유지. 외부 시스템이라 완전한 통제가 어렵더라도, "여기는 어느 기관의 어떤 절차"인지 알리는 표시를 둠.

실수 10) 다국어/모바일 버전에서 식별자가 깨진다

데스크톱 한국어 버전만 점검하고, 모바일 화면이나 영문 페이지의 식별자는 확인하지 않습니다.

나쁜 예: 모바일에서 로고가 잘리거나 푸터 정보가 접혀 안 보임. 영문 페이지 로고 alt는 여전히 한글이거나 "logo"인 채. 모바일·외국인 사용자에게 식별자가 작동 안 함.
올바른 예: 모바일 뷰포트에서도 로고와 핵심 푸터 정보가 보이고, 다국어 페이지는 해당 언어에 맞는 대체 텍스트·기관명 표기를 갖춤.

자, 이제 직접 진단해 봅시다 — 5분 자가진단 절차

기준을 다 봤으니, 이제 우리 사이트의 식별자를 실제로 점검해 볼 차례입니다. 도구 없이 손으로 할 수 있는 빠른 진단부터, ViewCheck로 자동화하는 방법까지 단계적으로 안내하겠습니다. 먼저 "맨손 진단" 3분, 그다음 "자동 진단" 2분, 합쳐서 5분입니다.

1단계: 눈으로 보기 (30초)

우리 사이트 메인 페이지를 띄우고, 헤더 왼쪽 위와 푸터를 봅니다.

헤더에 기관 로고/이름이 분명히 보이는가?
푸터에 기관명·주소·연락처·저작권·정책 링크가 있는가?
푸터 글씨가 배경에 묻히지 않고 읽히는가?

여기서 이미 빈 곳이 보이면, 그게 1차 점검 대상입니다.

2단계: 로고 클릭 테스트 (20초)

서브 페이지 아무 곳에나 들어간 뒤, 헤더 로고를 클릭합니다.

메인(홈)으로 돌아가는가?
안 돌아가거나 엉뚱한 데로 가면 → 실수 2번 해당.

3단계: 키보드만으로 훑기 (40초)

마우스에서 손을 떼고 Tab 키만 눌러 봅니다.

헤더 로고에 초점이 가고, Enter로 홈에 갈 수 있는가?
푸터의 정책 링크들에 Tab으로 도달하고 Enter로 열리는가?
초점이 지금 어디 있는지 시각적으로 보이는가(포커스 표시)?

이 테스트만으로도 "가짜 링크"나 "포커스 표시 제거" 문제를 상당 부분 잡아낼 수 있습니다.

4단계: 로고 alt 확인 (30초)

로고 이미지 위에서 마우스 오른쪽 버튼 → 검사(또는 개발자 도구)로 <img> 태그를 봅니다.

alt 속성이 있는가? 그 값이 기관명을 담고 있는가?
비어 있거나 "logo" "img" 같으면 → 실수 1번 해당.

(개발자 도구가 익숙지 않다면 이 단계는 건너뛰고, 곧이어 ViewCheck로 자동 확인하면 됩니다.)

5단계: 정책 링크 클릭 (30초)

푸터의 개인정보처리방침·이용약관 링크를 차례로 클릭합니다.

실제 해당 페이지로 가는가? 404가 뜨지 않는가?
깨진 링크가 있으면 → 실수 5번 해당.

여기까지가 맨손 진단입니다. 3분이면 됩니다. 다만 맨손 진단에는 한계가 있습니다. 페이지가 수십·수백 개인 공공 사이트에서 "모든 페이지의 식별자가 일관된가"를 손으로 다 확인하기는 불가능에 가깝고, alt 값이나 색 대비를 페이지마다 일일이 들여다보기도 어렵습니다. 여기서부터는 자동 진단이 필요합니다.

자동 진단 — ViewCheck로 식별자 한 번에 점검하기

맨손 진단의 한계를 메우는 게 자동 진단입니다. ViewCheck(krds.viewcheck.co.kr)는 URL만 넣으면 페이지를 실제로 크롤링해서, 운영기관 식별자를 포함한 컴포넌트들이 KRDS 기준을 지키는지 자동으로 판정합니다.

운영기관 식별자는 KRDS 846규칙 중 컴포넌트(CP) 규칙군 446개에 속하고, 분석 결과의 컴포넌트(Components) 탭에서 확인할 수 있습니다. ViewCheck가 식별자에 대해 자동으로 보는 것들은 대략 이렇습니다.

로고 대체 텍스트: 헤더 로고 이미지에 의미 있는 alt가 있는지, 비어 있거나 무의미한 값(logo/img 등)은 아닌지
로고 홈 링크: 로고가 링크로 감싸여 홈(사이트 루트)을 가리키는지, 키보드로 접근 가능한지
헤더 식별 영역 일관성: 여러 페이지에 걸쳐 식별 영역이 일관되게 존재하는지(다중 페이지 분석 시)
푸터 기관 정보: 기관명·연락처·저작권·정책 링크 등 기관 정보 요소가 존재하는지
정책 링크 접근성: 개인정보처리방침 등 정책 링크가 실제 링크 요소로 구현되고 접근 가능한지
색 대비: 식별 영역 텍스트와 배경의 명도 대비가 기준을 충족하는지(접근성 분석과 연계)

DOM만으로 판단하기 어려운 시각적 부분 — 예를 들어 "로고가 이미지인데 코드상으로는 식별이 안 되는" 비표준 구현이나, 실제 화면에서 로고가 어떻게 보이는지 — 는 KRDScan Vision AI가 스크린샷을 보고 보강 판정합니다. 그래서 "코드엔 로고 같은 게 없는데 화면엔 분명히 기관 로고가 있는" 비표준 구현도 놓치지 않습니다. 이 점이 단순 코드 검사 도구와 다른 부분입니다 — 사람이 눈으로 보듯 화면을 함께 보기 때문에, 표준을 우회해 만든 식별 영역도 잡아냅니다.

리포트를 어떻게 읽나

분석이 끝나면 컴포넌트 탭에서 식별자 관련 규칙의 통과/미통과 수와, 미통과한 항목의 위치(어느 페이지)·이유·개선 방법(howToFix)이 함께 나옵니다. 예를 들어 "신청 페이지의 헤더 로고에 대체 텍스트 없음"처럼 구체적으로요.

특히 식별자는 다중 페이지 분석의 가치가 큰 영역입니다. 메인 한 장만 보면 "로고 잘 있네" 하고 끝나지만, 여러 페이지를 한꺼번에 돌려 보면 "메인 로고는 alt가 있는데 검색 결과 페이지 로고는 alt가 비어 있다", "서브 페이지에서는 푸터 정책 링크가 빠져 있다" 같은 페이지별 편차가 드러납니다. 식별자의 핵심 가치가 "일관성"인 만큼, 이 편차를 잡아내는 게 자동 진단의 진짜 효용입니다.

그리고 어디부터 고쳐야 하는지 우선순위(P0~P3)도 함께 매겨지니, 한정된 시간에 가장 중요한 것부터 손볼 수 있습니다. 무료 진단으로 우리 사이트 메인부터 한 번 돌려 보면, 손으로는 몇 시간 걸릴 점검이 몇 분 만에 끝납니다.

직접 고치기 — 개발자·디자이너·기획자 가이드

진단으로 문제를 찾았다면, 이제 고칠 차례입니다. KRDS의 좋은 점은, 식별자 요건을 "알아서 잘 만드세요"로 끝내지 않고 바로 쓸 수 있는 자산으로 제공한다는 것입니다.

개발자라면 — KRDS 컴포넌트 킷을 npm install krds-uiux로 설치하거나 CDN(krds.min.css / krds.min.js)으로 불러올 수 있습니다. 저장소(KRDS-uiux/krds-uiux)의 html/code 폴더에 헤더·푸터를 포함한 표준 마크업이 들어 있어, 로고 링크 구조와 푸터 정보 영역을 기준에 맞게 시작할 수 있습니다. 식별 영역을 공통 컴포넌트(공통 헤더/푸터)로 분리해 모든 페이지가 같은 코드를 쓰게 하면, "페이지마다 다른 식별자" 문제가 구조적으로 사라집니다. 로고 alt는 이미지 교체 시 함께 점검하는 체크 항목으로 넣어 두세요. 정책 링크는 반드시 진짜 <a> 요소로, 목적지가 분명한 텍스트로 작성합니다.

디자이너라면 — KRDS 공식 Figma(@krds) 라이브러리에서 헤더·푸터 식별 영역을 컴포넌트로 가져다 쓸 수 있습니다. 직접 그리지 말고 표준 컴포넌트를 배치하면, 로고 위치·크기·푸터 구성이 기준에 맞춰집니다. 시안 단계에서 로고 대체 텍스트(어떻게 읽혀야 하는지)와 색 대비를 명시해 두면, 개발 단계의 누락을 막을 수 있습니다.

기획자라면 — 화면 정의서에 "헤더/푸터"라고만 적지 말고, "헤더: 기관 로고(홈 링크, alt='○○기관 누리집, 홈으로 이동'), 푸터: 기관명·주소·대표전화·개인정보처리방침(강조)·이용약관"처럼 식별 요소를 구체적으로 명시하세요. 그리고 기관 정보 변경(통폐합·이전·연락처 변경) 시 푸터를 갱신하는 책임 주체와 절차를 정해 두면, "옛 정보가 남는" 사고를 예방할 수 있습니다.

자주 묻는 질문

현장에서 운영기관 식별자를 다룰 때 반복해서 나오는 질문들을 모았습니다.

Q. 로고에 alt를 넣으라는데, 뭐라고 써야 하나요? "로고"라고 쓰면 되나요?

"로고"는 안 좋습니다. 스크린리더가 "로고, 이미지"라고만 읽어서 어느 기관인지 알 수 없으니까요. 기관명을 담아야 합니다. 그리고 로고가 보통 홈 링크를 겸하니, "○○부 누리집, 홈으로 이동"처럼 기관명 + 동작을 함께 쓰는 게 좋습니다. 핵심은 "이 alt만 듣고도 어느 기관 사이트인지, 누르면 어디로 가는지 알 수 있는가"입니다.

Q. 텍스트로 만든 로고(이미지가 아닌)는 alt가 필요 없나요?

네, CSS로 디자인한 텍스트 로고는 그 텍스트 자체가 읽히므로 alt 문제는 없습니다. 다만 텍스트 로고는 색 대비(배경과 충분히 구분되는지)와 확대 시 깨짐 여부를 봐야 합니다. 그리고 그 텍스트 로고도 홈 링크로 감싸 키보드로 접근 가능하게 만드는 건 동일하게 적용됩니다.

Q. 푸터에 기관 정보가 얼마나 자세해야 하나요? 어디까지 넣어야 하죠?

Q. 개인정보처리방침 링크를 왜 굳이 강조하라고 하나요?

공공 서비스는 개인정보를 다루는 경우가 많고, 개인정보처리방침은 법적으로도 사용자 신뢰 측면에서도 가장 중요한 문서이기 때문입니다. 사용자가 "내 정보가 어떻게 쓰이는지"를 쉽게 찾을 수 있어야 하므로, 다른 정책 링크보다 눈에 띄게(흔히 굵게) 두는 관행이 있습니다. 강조하면서도 키보드·스크린리더 접근성은 동일하게 챙겨야 합니다.

Q. 우리는 페이지가 200개가 넘는데, 식별자가 다 일관된지 어떻게 다 확인하나요?

손으로는 사실상 불가능합니다. 이게 바로 자동 진단(ViewCheck)이 필요한 이유입니다. URL을 넣고 다중 페이지 분석을 돌리면, 페이지별로 로고 alt·홈 링크·푸터 정보·정책 링크가 어떻게 다른지를 한눈에 비교해 줍니다. "메인은 괜찮은데 특정 서브 페이지군에서 식별자가 무너진다"는 식의 패턴을 잡아내는 게 자동 진단의 강점입니다.

Q. 로고 클릭으로 홈에 가는 건 너무 당연한 거 아닌가요? 정말 자주 깨지나요?

의외로 자주 깨집니다. 특히 서브 페이지를 별도 템플릿으로 만들었거나, 로고를 이미지로만 박아 두고 링크를 빼먹은 경우, 외부 시스템으로 연결되는 일부 페이지에서 헤더가 통째로 다른 경우 등에서요. "메인에서는 되니까 다 되겠지" 하고 넘기면 놓치기 쉬운 게 바로 이 항목입니다. 그래서 서브 페이지에서 직접 클릭 테스트를 해 보라는 겁니다.

Q. 이미 운영 중인 사이트인데, 식별자 때문에 전체를 다시 만들어야 하나요?

전혀 그럴 필요 없습니다. 식별자 문제는 대부분 국소적이고 고치기 쉬운 편입니다. 로고 alt 추가, 로고 링크 연결, 푸터 정보 갱신, 깨진 정책 링크 수정 — 대부분 적은 작업으로 해결됩니다. 먼저 ViewCheck로 현황을 목록화한 뒤, 우선순위(아래 참고)대로 치명적인 것부터 차례로 고치면 됩니다. 특히 공통 헤더/푸터로 구조를 정리해 두면, 한 번 고치는 게 모든 페이지에 반영되어 효율이 높습니다.

Q. 디자인팀은 "로고는 우리 일이지만 alt는 개발 일"이라고 합니다.

식별자 품질은 합작입니다. 디자이너는 로고가 어떻게 읽혀야 하는지(대체 텍스트 내용)와 색 대비를 시안에 명시하고, 개발자는 그걸 표준 코드로 구현하고, 기획자는 푸터 정보의 정확성과 정책 링크 구성을 책임집니다. KRDS가 디자인(Figma)·코드(GitHub 킷)·문서(가이드라인)를 한 세트로 제공하는 이유가 이겁니다. 세 팀이 같은 기준을 보면 "네 일/내 일" 논쟁이 줄어듭니다.

Q. 사칭 사이트 방어에 식별자가 정말 도움이 되나요?

직접적인 차단 수단은 아니지만, 사용자가 진짜와 가짜를 구별하는 근거가 됩니다. 진짜 공식 사이트가 일관되고 정확한 식별자(모든 페이지의 로고·푸터 기관 정보·정책 링크)를 갖추면, 사용자는 "이게 진짜"라고 학습합니다. 반대로 진짜인데 식별자가 빈약하면, 사용자가 진짜를 의심하고 가짜에 속을 여지가 커집니다. 그래서 식별자 점검은 신뢰·보안 관리의 일부이기도 합니다.

Q. 로고 alt에 "홈으로 이동" 같은 동작까지 넣으면 너무 길지 않나요?

길어 보여도 괜찮습니다. 스크린리더 사용자에게는 그 한 줄이 "어느 기관인지 + 누르면 어디로 가는지"를 동시에 알려 주는 유일한 정보거든요. 다만 "○○부 누리집 메인 페이지로 이동하는 링크 이미지입니다" 식으로 불필요하게 장황하게 쓸 필요는 없습니다. "○○부 누리집, 홈으로 이동" 정도면 충분합니다. 핵심 정보를 담되 군더더기는 빼는 게 요령입니다.

Q. 푸터가 너무 길어지는데, 식별 정보를 접어 둬도 되나요?

기관명·연락처·개인정보처리방침 같은 핵심 식별 정보는 접지 말고 항상 보이게 두는 게 좋습니다. 보조적인 정보(관련 사이트 링크 모음 등)는 접어 둘 수 있지만, "이 사이트가 누구 것인지"와 "어떻게 문의하고 어떤 정책이 적용되는지"는 사용자가 한 번에 확인할 수 있어야 신뢰가 유지됩니다. 접는다면 접힌 상태에서도 키보드·스크린리더로 펼칠 수 있어야 합니다.

Q. ViewCheck로 식별자만 따로 볼 수 있나요?

전체 분석을 돌리면 결과의 컴포넌트(Components) 탭에서 식별자 관련 규칙(헤더 로고·푸터 기관 정보·정책 링크 등)을 모아 볼 수 있습니다. 식별자는 CP 446개 규칙군의 일부라, 별도 도구를 따로 돌릴 필요 없이 한 번의 분석으로 다른 컴포넌트와 함께 점검됩니다. 미통과 항목은 위치·이유·개선 방법까지 같이 나오니, 그 목록만 따라 고쳐도 됩니다.

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

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

가장 먼저(치명적) — 헤더 로고에 대체 텍스트가 없어 스크린리더가 기관을 인지하지 못하는 경우, 그리고 개인정보처리방침 링크가 없거나 깨진 경우. 전자는 시각장애인에게 사이트의 정체를 처음부터 차단하는 문제이고, 후자는 법적·신뢰 측면에서 가장 민감한 문서로의 통로가 막힌 문제라 1순위입니다.

그다음(높음) — 로고가 홈 링크로 작동하지 않는 경우, 정책 링크가 키보드로 접근 안 되는 경우, 푸터 기관 정보가 빠지거나 틀린 경우. 작동은 하지만 핵심 사용자 경로와 신뢰에 직접 영향을 주므로 빠르게 손봐야 합니다. 특히 푸터 연락처 오류는 행정 혼선으로 이어지니 우선 처리 대상입니다.

그 후(보통) — 페이지별 식별 영역 불일치, 식별 영역 색 대비 부족, 모호한 링크 텍스트. 사용은 가능하지만 특정 상황·특정 사용자에게 불편과 불안을 주는 문제입니다. 공통 헤더/푸터 정리로 한꺼번에 해결되는 경우가 많습니다.

여력이 되면(낮음) — 푸터 정보 보강(콜센터 운영 시간, 담당 부서), 정책 링크 텍스트 다듬기 같은 개선. 접근성을 막는 건 아니지만 신뢰와 사용성을 한 단계 끌어올리는 항목입니다.

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

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

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

KRDS 가이드라인 PDF(디지털 정부서비스 UI/UX 가이드라인, 2025.08판) — 컴포넌트별 정의와 사용 원칙의 1차 원천.
KRDS 컴포넌트 문서(웹) — 운영기관 식별자의 구성과 예시를 화면으로 확인.
KRDS 컴포넌트 킷(GitHub `KRDS-uiux/krds-uiux`) — 헤더·푸터 표준 마크업을 그대로 가져다 사용(npm install krds-uiux 또는 CDN).
KRDS 공식 Figma(@krds) — 디자이너용 헤더·푸터 식별 영역 컴포넌트.

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

오늘의 체크리스트 — 운영기관 식별자, 이것만은

마지막으로, 디자이너·개발자·기획자가 식별자를 만들거나 검수할 때 바로 쓸 수 있는 체크리스트로 정리합니다. 5분 자가진단 때 이 목록을 그대로 들고 확인하시면 됩니다.

☐ 헤더 기관 로고가 모든 페이지에서 같은 자리에 분명히 보인다.
☐ 로고 이미지에 의미 있는 대체 텍스트가 있다(기관명 포함, "logo"/"img" 아님).
☐ 로고를 누르면 메인(홈)으로 이동한다(모든 페이지에서, 키보드로도).
☐ 헤더 식별 영역이 모든 페이지에서 일관된다(위치·크기·동작).
☐ 푸터 기관 정보가 최신이다(통폐합·이전·연락처 변경 반영).
☐ 개인정보처리방침 링크가 푸터에 있고(흔히 강조), 클릭하면 유효한 페이지로 간다.
☐ 정책 링크가 진짜 링크 요소로 구현되어 키보드·스크린리더로 접근된다.
☐ 정책 링크 텍스트가 목적지를 분명히 밝힌다("여기"/"바로가기" 아님).
☐ 식별 영역(로고·푸터 텍스트)의 색 대비가 충분하다(흐릿하지 않다).

KRDS 컴포넌트 킷(npm install krds-uiux 또는 CDN)을 쓰면 위 항목 대부분이 이미 구현된 상태로 시작할 수 있습니다. 헤더·푸터를 공통 컴포넌트로 분리해 두면, 한 번 맞춰 놓은 식별자가 모든 페이지에 일관되게 적용됩니다. 공식 Figma 라이브러리(@krds)에서는 디자이너가 표준 헤더·푸터 식별 영역을 그대로 가져다 쓸 수 있습니다.

운영기관 식별자는 작아 보이지만, 사용자가 "여기가 어디인지" "믿어도 되는지"를 판단하는 첫 번째이자 마지막 단서입니다. 헤더 로고 하나, 푸터 한 줄이 누군가에겐 "아, 공식 사이트구나" 하는 안심이고, 또 누군가에겐 사이트의 정체를 알려 주는 유일한 통로입니다. 우리가 무심코 넘긴 그 작은 영역이, 사실은 신뢰의 출발점인 셈입니다.

오늘 정리한 기준이 많아 보일 수 있지만, 핵심은 결국 단순합니다. 로고에 기관명을 담은 대체 텍스트를 넣고, 로고를 홈 링크로 만들고, 푸터에 정확한 기관 정보와 정책 링크를 두고, 그게 모든 페이지에서 일관되게 작동하는지 확인하는 것. 이 네 가지만 챙겨도 식별자 위반의 대부분은 사라집니다. 그리고 그게 잘 됐는지는 ViewCheck로 5분이면 확인할 수 있습니다. 완벽을 한 번에 만들 필요는 없습니다. 가장 치명적인 항목 하나부터 고쳐 나가면, 우리 사이트는 분명히 조금씩 더 믿음직해집니다. 다음 글에서는 식별자와 함께 헤더·푸터를 구성하는 또 다른 요소를 같은 방식으로 뜯어보겠습니다.

우리 사이트의 운영기관 식별자는 지금 KRDS 기준을 지키고 있을까요? krds.viewcheck.co.kr에서 URL만 넣으면 무료로 확인할 수 있습니다. 메인 페이지 하나만 돌려 봐도, 위 체크리스트가 실제로 지켜지고 있는지 5분 안에 보입니다.

#KRDS #공공웹 #디자인시스템 #운영기관식별자Identifier #웹접근성 #ViewCheck #정부웹사이트 #UIUX #푸터 #헤더 #개인정보처리방침 #자가진단 #운영기관식별자 #Identifier #체크리스트 #점검항목 #UI컴포넌트 #컴포넌트설계 #전자정부 #디지털정부