운영기관 식별자(Identifier) 완전 해부 — KRDS 공식 기준

공공 사이트에 처음 들어갔을 때, 우리는 무의식중에 화면 맨 위 왼쪽 구석을 봅니다. 거기 무엇이 있는지 정확히 의식하지는 않지만, 눈은 자동으로 그쪽을 훑죠. 거기에 기관의 이름과 마크가 있으면 "아, 여기가 ○○부 사이트구나" 하고 안심하고 본론으로 들어갑니다. 그런데 가끔, 그 자리에 아무것도 없거나, 마크는 있는데 무슨 기관인지 도무지 알 수 없거나, 클릭해도 아무 일도 일어나지 않는 경우를 만납니다. 그 순간 우리는 미세하게 불안해집니다. "여기 진짜 정부 사이트 맞아? 혹시 사칭 사이트 아니야?"

운영기관 식별자(Identifier)는 바로 그 자리에 있는 컴포넌트입니다. 화면 맨 위, 보통 왼쪽에 자리 잡은 "이 사이트를 누가 운영하는지"를 알리는 영역. 기관 마크(심볼·로고), 기관명, 그리고 대개 홈으로 돌아가는 링크가 한 덩어리로 묶인 것. 우리는 이걸 그냥 "로고 자리"라고 부르며 대수롭지 않게 여기지만, 사실 이 작은 영역은 공공 서비스의 신뢰가 시작되는 출발점입니다. 사용자가 화면에서 가장 먼저 보고, 가장 먼저 판단하는 곳이거든요.

현업에서 보면, 운영기관 식별자는 "디자인 다 끝나고 마지막에 로고 이미지 하나 얹는 자리" 취급을 받는 경우가 많습니다. 기획서에는 "헤더 좌측에 기관 로고"라고 한 줄 적히고, 디자인에서는 가져온 로고 이미지를 적당한 크기로 배치하고, 개발에서는 <img> 태그 하나로 끝냅니다. 이 과정 어디에서도 "이 마크가 스크린리더로 어떻게 읽히나", "키보드로 홈에 갈 수 있나", "어두운 배경에서도 보이나", "기관명이 텍스트로 존재하나"를 따지지 않습니다. 그 결과가 우리가 종종 마주치는, 정체불명의 헤더 로고들입니다.

이 글에서는 KRDS(대한민국 정부 디자인 시스템)가 운영기관 식별자를 어떻게 정의하고 무엇을 요구하는지를, 공식 가이드라인과 컴포넌트 킷을 기준으로 하나하나 뜯어보겠습니다. "이렇게 하면 멋지다"가 아니라 "정부 표준은 이걸 요구한다"는 사실 기준으로요. 그리고 그 기준을 우리 사이트가 실제로 지키고 있는지 어떻게 확인하는지까지 이어가겠습니다. 다 읽고 나면, 앞으로 어떤 공공 사이트에 들어가든 맨 위 왼쪽 구석을 보며 "이 기관은 자기를 제대로 밝히고 있군" 혹은 "여기는 위험하게 만들었네"가 눈에 들어오실 겁니다.

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

먼저 용어부터 맞추겠습니다. "식별자(Identifier)"라는 말이 개발자에게는 변수 이름이나 데이터베이스 키처럼 들릴 수 있지만, KRDS에서 말하는 식별자는 그게 아닙니다. 여기서의 식별자는 "이 디지털 서비스를 어느 기관이 운영하는지 사용자에게 분명히 알리는 시각적·구조적 영역"을 뜻합니다. 영어 원문도 그냥 Identifier이고, 미국·영국 등 다른 나라의 정부 디자인 시스템에도 비슷한 개념이 있습니다. 공공 서비스라면 "누가 책임지고 운영하는가"를 명확히 밝혀야 한다는 보편적 원칙에서 나온 컴포넌트입니다.

운영기관 식별자를 구성하는 요소를 풀어 보면 대략 이렇습니다.

• 기관 마크(심볼/로고): 기관을 시각적으로 대표하는 그래픽. 부처 상징, 지자체 엠블럼, 공공기관 로고 등.
• 기관명(텍스트): 마크 옆이나 아래에 따라붙는 기관의 정식 명칭. "○○부", "○○시", "○○공단" 같은 글자.
• 홈 링크: 식별자 전체(또는 마크)를 누르면 그 사이트의 메인 화면으로 돌아가는 링크. 사용자가 길을 잃었을 때 "원점으로" 돌아오는 가장 보편적인 출구입니다.

이 세 가지가 한 덩어리로 묶여, 보통 화면 최상단의 헤더 왼쪽에 자리합니다. 모양은 단순해 보이지만, 이 안에는 "신뢰", "탐색", "접근성"이라는 세 가지 무거운 책임이 동시에 담겨 있습니다.

여기서 흔히 헷갈리는 게 "그럼 푸터(맨 아래)에 있는 기관 정보랑 뭐가 다르지?"입니다. 다릅니다. 푸터의 기관 정보는 주소·전화번호·사업자등록번호·저작권 표시처럼 "법적·행정적 식별 정보"에 가깝습니다. 반면 헤더의 운영기관 식별자는 사용자가 화면에 들어서자마자 가장 먼저 마주하는 "시각적 정체성"입니다. 둘 다 "이 사이트는 누구 것인가"를 알리지만, 하나는 화면의 얼굴이고 하나는 화면의 명함입니다. 이 글에서 다루는 건 주로 헤더의 얼굴 쪽입니다. 다만 두 영역의 기관명이 서로 다르거나, 한쪽에만 있고 다른 쪽엔 없으면 사용자는 혼란스러워하니, 둘의 일관성도 함께 챙겨야 합니다.

왜 KRDS가 이걸 별도 컴포넌트로 떼어냈나

KRDS는 헤더 안의 수많은 요소 중에서도 운영기관 식별자를 별도 컴포넌트로 분리해 정의합니다. 그냥 "헤더 디자인 알아서 하세요"가 아니라 "운영기관을 밝히는 이 부분만큼은 표준을 따르세요"라고 떼어 둔 거죠. 이게 메시지입니다. 헤더에는 검색창도 있고 메뉴도 있고 로그인 버튼도 있지만, 그중에서 "기관 정체성"은 별도로 관리할 만큼 중요하다는 뜻입니다.

생각해 보면 당연합니다. 정부 서비스를 사칭하는 피싱 사이트가 끊이지 않는 시대에, "이 사이트가 진짜 그 기관 것이 맞는가"를 사용자가 빠르고 확실하게 판단할 수 있어야 합니다. 운영기관 식별자가 일관된 위치에, 일관된 방식으로, 명확하게 표시되면 사용자는 "정부 사이트는 다 이렇게 생겼지"라는 학습된 기대를 갖게 됩니다. 그 기대에 맞으면 신뢰하고, 어긋나면 경계합니다. 표준화된 식별자는 그래서 단순한 디자인 통일이 아니라, 사회 전체의 보안 인프라이기도 합니다.

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

이제 본론입니다. KRDS 가이드라인(디지털 정부서비스 UI/UX 가이드라인, 2025.08판)과 컴포넌트 문서를 기준으로, 운영기관 식별자가 충족해야 하는 요건을 영역별로 정리하겠습니다. 작은 영역이지만 따져야 할 게 생각보다 많습니다.

1) 위치 — 정해진 자리에 있어야 한다

운영기관 식별자의 첫 번째 요건은 위치입니다. 사용자는 "기관 로고는 화면 맨 위 왼쪽에 있다"는 강한 학습된 기대를 가지고 있습니다. 이건 한국 사이트만의 관습이 아니라 전 세계 웹의 보편적 패턴입니다. 그래서 식별자를 헤더 좌측이라는 예측 가능한 자리에 두는 것 자체가 사용성의 일부입니다.

이 자리를 임의로 가운데나 오른쪽으로 옮기거나, 다른 요소(거대한 검색창, 배너 등)에 밀려 잘 보이지 않게 만들면 사용자는 "여기가 어디지?"부터 헤매게 됩니다. 위치는 사소해 보이지만, 첫 화면에서 사용자의 시선이 가장 먼저 닿는 곳이라 영향이 큽니다. KRDS가 헤더 구조를 표준화하는 이유 중 하나가 바로 이 "예측 가능성"입니다.

2) 기관 마크 — 이미지가 아니라 "의미"로 다뤄라

운영기관 식별자의 핵심은 기관 마크입니다. 그런데 여기서 가장 많이 실수하는 게, 이 마크를 그저 "이미지 파일 하나"로 다루는 것입니다.

웹 표준으로 말하면, 기관 마크가 이미지(<img>)일 때는 반드시 대체 텍스트(alt)가 있어야 합니다. 그것도 의미 있는 대체 텍스트여야 하죠. alt="logo"나 alt="이미지"처럼 무의미하게 적거나, 아예 비워 두면 안 됩니다. 스크린리더 사용자에게는 이 마크가 "어느 기관 사이트인지"를 알리는 유일한 단서이기 때문입니다. 올바른 대체 텍스트는 alt="○○부"처럼 기관명 그 자체입니다.

만약 마크가 SVG로 들어가 있다면, role="img"과 aria-label 또는 <title> 요소로 이름을 부여해야 합니다. 어떤 방식이든 핵심은 같습니다 — 눈으로 보면 알 수 있는 정보(어느 기관)가 코드로도 전달돼야 한다는 것. 마크가 아무리 멋지게 디자인돼 있어도, 코드가 그 의미를 담고 있지 않으면 화면을 못 보는 사용자에게는 존재하지 않는 것과 같습니다.

3) 기관명 텍스트 — 마크에만 의존하지 마라

마크에 대체 텍스트를 넣는 것과 별개로, 기관명이 실제 텍스트로 화면에 존재하는 것이 더 안전합니다. 마크 이미지 안에 기관명이 그림으로 박혀 있고 화면에 따로 텍스트가 없으면, 몇 가지 문제가 생깁니다.

첫째, 검색엔진이 기관명을 텍스트로 인식하기 어려워 검색 노출에 불리합니다. 둘째, 사용자가 화면을 확대했을 때 그림 속 글자는 흐려지지만 실제 텍스트는 또렷하게 커집니다. 셋째, 이미지 로딩이 실패하면 그림 속 기관명은 사라지지만, 텍스트는 남아 있습니다. 그래서 KRDS는 마크와 함께 기관명을 텍스트로 병기하는 구조를 권장합니다. 마크는 시각적 인상을, 텍스트는 명확한 정보를 담당하는 역할 분담인 셈입니다.

이때 마크와 기관명 텍스트가 둘 다 스크린리더에 읽히면 중복이 되니, 처리에 주의해야 합니다. 보통은 마크 이미지를 alt=""(빈 대체 텍스트)나 aria-hidden으로 장식 처리하고 옆의 텍스트로 이름을 전달하거나, 반대로 텍스트를 시각적으로만 두고 이미지에 대체 텍스트를 주는 식으로 한 번만 읽히게 정리합니다. 핵심은 "기관명이 코드로 한 번은 명확히 전달되되, 두 번 중복해서 읽히지는 않게"입니다.

4) 홈 링크 — 클릭하면 메인으로

운영기관 식별자는 거의 항상 홈으로 가는 링크 역할을 겸합니다. 이건 웹의 오래된 관습이라, 사용자는 "로고를 누르면 첫 화면으로 돌아간다"를 자연스럽게 기대합니다. 그래서 식별자를 누르면 그 사이트의 메인 페이지로 이동해야 합니다.

여기서 챙길 점이 몇 가지 있습니다. 우선 링크가 진짜 링크(<a>)여야 합니다. <div>에 클릭 이벤트만 붙여 만들면 키보드로 도달할 수 없고 스크린리더가 링크로 인식하지 못합니다. 그리고 이 링크에는 "○○부 홈" 또는 "메인으로"처럼 어디로 가는지 알 수 있는 접근 가능한 이름이 있어야 합니다. 단순히 마크 이미지의 대체 텍스트가 기관명이면, 스크린리더는 "○○부, 링크"라고 읽어 주고 사용자는 "아 누르면 홈에 가겠구나" 하고 짐작할 수 있습니다.

또 하나, 메인 페이지에서는 이 홈 링크가 "현재 페이지를 가리키는 링크"가 됩니다. 이미 홈에 있는데 홈 링크가 평범하게 활성화돼 있으면 약간 어색하죠. 그래서 현재 위치를 알리는 처리(aria-current="page" 등)를 더하면 더 친절합니다. 다만 이건 권장 사항이고, 최소한 "로고 누르면 홈으로 간다"는 동작은 반드시 작동해야 합니다.

5) 키보드 접근 — 마우스 없이도 홈으로

홈 링크가 진짜 링크라면 키보드 접근은 대체로 따라옵니다. Tab으로 식별자에 초점이 가고, Enter로 홈으로 이동할 수 있어야 합니다. 그리고 초점이 왔을 때 시각적으로 또렷하게 표시(포커스 링)돼야 합니다. 헤더 맨 앞의 로고는 보통 Tab 순서상 가장 먼저 만나는 요소 중 하나라, 키보드 사용자가 페이지를 탐색하기 시작하는 출발점이기도 합니다. 그런데 디자인이 깔끔해 보인다고 outline: none으로 포커스 표시를 지워 버리면, 키보드 사용자는 자기가 로고에 와 있는지 알 수 없습니다. 작은 영역이라고 포커스 표시를 생략하는 실수가 여기서도 반복됩니다.

6) 색상과 대비 — 어떤 배경에서도 보여야

기관 마크와 기관명은 배경과 충분한 명도 대비를 가져야 합니다. 특히 헤더 배경색을 진하게(예: 짙은 남색, 검정) 쓰는 경우, 어두운 색의 로고를 그대로 얹으면 거의 안 보입니다. 그래서 어두운 배경용 흰색(반전) 버전 로고를 별도로 준비하는 게 보통입니다. 저시력·고령 사용자에게는 이 대비가 "기관을 인지할 수 있느냐"를 가르는 문제입니다.

또 스크롤에 따라 헤더 배경이 투명→불투명으로 바뀌는 디자인이라면, 모든 상태에서 로고가 명확히 보이는지 확인해야 합니다. 배너 이미지 위에 헤더가 겹쳐지는 경우, 배경 이미지에 따라 로고가 묻히지 않도록 그림자나 반투명 박스를 받쳐 주는 처리가 필요할 때도 있습니다.

7) 크기와 터치 영역 — 작아도 누를 수 있어야

로고가 작게 디자인되더라도, 그것이 누를 수 있는 링크라면 터치/클릭 영역은 충분해야 합니다. 한국형 웹 접근성 지침(KWCAG)과 국제 표준 모두 터치 대상의 최소 크기를 권장하는데, 일반적으로 한 변 44px 이상을 기준으로 봅니다. 작은 마크 그림 자체는 작아도, 그것을 감싸는 링크 영역은 손가락으로 정확히 누를 수 있을 만큼 여유가 있어야 합니다. 특히 모바일에서 로고가 너무 작으면 홈으로 돌아가려다 옆의 메뉴 버튼을 잘못 누르기 쉽습니다.

8) 반응형 — 화면 크기에 따라 적절히

데스크톱에서는 마크+기관명을 나란히 다 보여 주다가, 좁은 모바일 화면에서는 공간이 부족해 마크만 남기거나 기관명을 줄이는 경우가 많습니다. 이 자체는 자연스러운 반응형 처리입니다. 다만 모바일에서 기관명 텍스트를 숨기더라도, 접근 가능한 이름(대체 텍스트나 aria-label)은 그대로 남아 있어야 합니다. 시각적으로 글자를 안 보이게 한 것과, 코드에서 정보를 지워 버린 것은 전혀 다릅니다. 화면에서 기관명이 사라졌다고 스크린리더에서도 "어느 기관인지 모름" 상태가 되면 안 됩니다.

9) 일관성 — 사이트 전체에서 같은 모습

운영기관 식별자는 사이트의 모든 페이지에서 같은 위치, 같은 모습, 같은 동작을 유지해야 합니다. 메인 페이지의 로고와 하위 신청 페이지의 로고가 다르게 생겼거나, 어떤 페이지는 홈 링크가 되는데 어떤 페이지는 안 되거나 하면 사용자는 혼란스럽습니다. 이 일관성이 깨지는 대표적인 경우가, 별도 시스템으로 만든 하위 서비스(예: 외부 위탁 개발한 민원 신청 시스템)가 본 사이트와 헤더를 다르게 쓰는 상황입니다. 사용자 입장에서는 같은 기관 서비스인데 갑자기 다른 곳에 온 듯한 단절을 느끼게 됩니다.

정리하면, KRDS의 운영기관 식별자 기준은 크게 세 축으로 모입니다. ① 신뢰성(정해진 위치에 명확한 기관 마크와 이름), ② 접근성(마크의 대체 텍스트, 진짜 링크, 키보드 접근, 충분한 대비·크기), ③ 일관성(사이트 전체에서 같은 모습·동작, 헤더-푸터 정보 일치). 이 세 축은 그대로 ViewCheck가 식별자를 점검하는 기준이기도 합니다.

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

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

신뢰는 첫 화면의 왼쪽 위에서 시작된다

사용자가 어떤 사이트를 신뢰할지 말지는 놀랄 만큼 빠르게 결정됩니다. 화면이 뜨고 몇 초 안에, 무의식적으로요. 그 짧은 순간에 가장 강력하게 작동하는 신호 중 하나가 "이 사이트가 누구 것인지 명확히 밝히고 있는가"입니다. 맨 위 왼쪽에 또렷한 기관 마크와 이름이 있으면 사용자는 "공식 사이트구나" 하고 마음을 놓습니다. 반대로 그 자리가 비어 있거나 모호하면, 사용자는 의식하지 못한 채 경계 태세에 들어갑니다.

이건 단순한 심리가 아니라 보안과 직결됩니다. 정부·공공기관을 사칭한 피싱 사이트는 대체로 디테일에서 어설픕니다. 로고가 흐릿하거나, 기관명이 어색하거나, 홈 링크가 작동하지 않거나 합니다. 진짜 공공 사이트가 운영기관 식별자를 표준에 맞게 또렷하고 일관되게 표시할수록, 사용자는 "진짜와 가짜의 차이"를 직관적으로 느끼게 됩니다. 그래서 식별자를 제대로 만드는 일은 그 기관 하나의 문제가 아니라, 공공 서비스 전체의 신뢰 자산을 지키는 일이기도 합니다.

공공 서비스는 "안 쓸 자유"가 없다

상업 사이트는 신뢰가 안 가면 사용자가 떠나면 그만입니다. 경쟁사로 가면 되니까요. 그런데 공공 서비스는 다릅니다. 주민등록 등본을 떼거나, 건강보험을 신청하거나, 세금을 내는 일은 그 사이트가 아니면 할 수 없습니다. 사용자가 "안 쓸 자유"가 없어요. 그래서 공공 웹의 식별자가 누군가에게 작동하지 않거나 모호하면, 그건 단순한 불편이 아니라 행정 서비스 접근권의 문제가 됩니다.

기관 마크에 대체 텍스트가 없으면, 시각장애인은 자기가 어느 기관 사이트에 들어왔는지조차 알 수 없습니다. 여러 탭을 열어 두고 작업하는 상황이라면, 지금 어느 사이트에 있는지 확인할 길이 막막해지죠. 홈 링크가 키보드로 작동하지 않으면, 마우스를 못 쓰는 사용자는 길을 잃었을 때 원점으로 돌아오는 가장 기본적인 출구를 잃습니다. 이게 KRDS가 식별자의 접근성을 "있으면 좋은 것"이 아니라 "기본 요건"으로 두는 이유입니다.

보이는 것과 읽히는 것의 분리

비장애인은 화면을 "본다"고 생각하지만, 사실 우리는 화면을 보고 머릿속에서 의미로 번역합니다. 헤더 왼쪽의 그래픽을 보고 "아, ○○부 로고구나" 하고 알아채죠. 스크린리더 사용자에게는 이 짐작 과정이 없습니다. 코드가 알려 주는 정보가 곧 전부입니다.

그래서 기관 마크는 "보기에 로고 같은 것"으로는 부족하고, "코드 수준에서 어느 기관인지 선언된 것"이어야 합니다. 멋진 로고 이미지를 얹어도, 코드가 그걸 "○○부"라고 말해 주지 않으면 스크린리더에겐 그냥 의미 없는 그림 파일입니다. 이 "보이는 것 ≠ 읽히는 것" 문제가 식별자 위반의 근본 원인 대부분을 차지합니다. KRDS의 모든 컴포넌트 요건이 결국 "시각과 코드의 일치"라는 한 가지 원리로 수렴하는 셈입니다.

일관성이 곧 신뢰와 학습 비용 절감

KRDS가 식별자의 위치와 모습을 표준화하는 또 다른 이유는 일관성입니다. 정부 사이트마다 로고 위치와 동작이 제각각이면, 사용자는 사이트를 옮길 때마다 "여기선 어디가 홈이지?"를 다시 찾아야 합니다. 모든 공공 서비스의 식별자가 같은 자리에서 같은 방식으로 작동하면, 한 번 익힌 사용법이 모든 사이트에서 통합니다. 그리고 그 일관성 자체가 "이건 진짜 정부 사이트"라는 신뢰의 근거가 됩니다. 표준화는 디자이너의 자유를 뺏는 게 아니라, 사용자의 인지 부담을 덜고 신뢰를 쌓아 주는 일입니다.

한 장면 — 같은 헤더, 두 사람

추상적인 요건을 길게 늘어놓는 것보다, 한 장면을 그려 보는 게 빠를 것 같습니다. 어느 공공 서비스의 화면, 헤더 왼쪽에 기관 로고가 하나 있다고 합시다. 디자인이 깔끔하고, 마크도 세련됐습니다.

먼저 마우스를 쓰는 김 주무관. 화면에 들어서자마자 왼쪽 위 로고를 보고 "아, ○○공단이구나" 하고 안심합니다. 한참 하위 페이지를 헤매다 길을 잃자, 자연스럽게 로고를 클릭해 메인으로 돌아옵니다. 10초도 안 걸렸습니다. 김 주무관에게 이 식별자는 아무 문제가 없습니다. 그래서 이 화면을 만든 팀도 "잘 작동한다"고 믿습니다. 자기들이 테스트할 때 늘 마우스를 썼으니까요.

이번엔 시각장애가 있는 박 선생님. 여러 민원을 처리하느라 탭을 대여섯 개 열어 둔 상태입니다. 스크린리더로 한 탭에 들어가 헤더부터 훑는데, 로고 자리에서 "이미지"라고만 들립니다. 어느 기관 사이트인지 알 수 없습니다(대체 텍스트 누락). 일단 홈으로 돌아가 처음부터 보려고 그 자리에서 Enter를 눌렀는데, 아무 반응이 없습니다. 이 로고는 <div>에 클릭 이벤트만 붙인 가짜 링크라, 마우스 클릭에만 반응하거든요(키보드 미지원). 박 선생님은 지금 자기가 어느 사이트의 어디에 있는지조차 가늠하지 못한 채, 결국 브라우저 뒤로 가기로 헤매다 작업을 포기합니다.

같은 헤더, 같은 로고. 한 사람에겐 10초짜리 안심이고, 다른 한 사람에겐 정체불명의 미로 입구입니다. 그리고 이 차이는 "예산이 부족해서"나 "기술이 어려워서" 생긴 게 아닙니다. 그냥 만들 때 마우스로 보는 사용자만 떠올렸기 때문에 생긴 차이입니다. KRDS의 운영기관 식별자 요건은, 이 두 사람의 경험을 같게 만들기 위한 최소한의 약속입니다.

만약 이 팀이 KRDS 킷의 식별자 구조를 가져다 썼다면 어땠을까요. 박 선생님의 스크린리더는 "○○공단 홈, 링크"라고 읽었을 거고, Enter를 누르면 메인으로 돌아갔을 겁니다. 어느 사이트에 있는지 한 번에 알고, 길을 잃어도 원점으로 돌아오는 출구가 분명히 있었겠죠. 김 주무관과 똑같이 10초면 됐을 겁니다. 차이를 만드는 건 거창한 기술이 아니라, "검증된 구조를 쓰느냐"라는 작은 선택입니다.

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

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

실수 1) 대체 텍스트 없는(또는 무의미한) 기관 마크

가장 흔하고 가장 치명적인 실수입니다. 기관 로고 이미지에 alt가 비어 있거나, alt="logo", alt="이미지"처럼 무의미하게 적혀 있습니다.

• 나쁜 예: <img src="logo.png"> 또는 <img src="logo.png" alt="logo">. 스크린리더는 "이미지" 또는 "로고"라고만 읽음. 어느 기관인지 알 수 없음.
• 올바른 예: <img src="logo.png" alt="○○부">처럼 기관명을 대체 텍스트로. SVG라면 role="img" + aria-label="○○부" 또는 <title>○○부</title>.

실수 2) 가짜 홈 링크

로고를 누르면 홈으로 가긴 하는데, 그게 진짜 링크가 아니라 <div>에 자바스크립트 클릭 이벤트를 붙인 것입니다.

• 나쁜 예: <div>. 키보드 Tab으로 도달 불가, 스크린리더가 링크로 인식 못 함. 마우스로만 작동.
• 올바른 예: <a href="/" aria-label="○○부 홈">...</a>. 진짜 링크라 키보드·스크린리더 모두 지원되고, 어디로 가는지 이름도 명확.

실수 3) 기관명이 그림 속에만 있고 텍스트가 없음

마크 이미지 안에 기관명이 그림으로 박혀 있고, 화면에 실제 텍스트 기관명이 따로 없습니다.

• 나쁜 예: 기관명이 통째로 PNG 이미지. 확대하면 흐려지고, 검색엔진은 기관명을 텍스트로 못 읽고, 이미지 로딩 실패 시 기관명이 사라짐.
• 올바른 예: 마크는 마크대로 두고, 기관명을 실제 텍스트로 병기. 중복 낭독은 한쪽을 장식 처리해 막음.

실수 4) 어두운 배경에서 안 보이는 로고

헤더 배경을 진하게 깔아 두고, 어두운 색 로고를 그대로 얹습니다.

• 나쁜 예: 짙은 남색 헤더에 검정 계열 로고. 저시력 사용자는 거의 인지 못 하고, 일반 사용자도 흐릿하게 봄.
• 올바른 예: 배경에 맞는 반전(흰색) 로고를 준비하거나, 배경 대비를 충분히 확보. 스크롤·배너 위 겹침 상태에서도 보이는지 확인.

실수 5) 포커스 표시 제거

디자인 통일성을 위해 헤더 로고 링크의 포커스 링을 outline: none으로 지웁니다.

• 나쁜 예: 키보드로 페이지를 탐색하기 시작할 때 로고에 초점이 와도 표시가 안 보임. 어디서 시작했는지 알 수 없음.
• 올바른 예: 포커스 시 또렷한 테두리·외곽선 유지. 작은 영역이라도 텍스트 링크와 동일한 기준 적용.

실수 6) 모바일에서 너무 작은 터치 영역

데스크톱 기준으로 만들고 모바일을 확인하지 않아, 로고 링크가 손가락에 비해 작습니다.

• 나쁜 예: 모바일에서 로고가 너무 작아, 홈으로 가려다 옆 메뉴 버튼을 잘못 누름.
• 올바른 예: 로고를 감싸는 링크 영역을 충분히(약 44px 이상) 확보하고, 옆 요소와 간격도 여유 있게.

실수 7) 모바일에서 접근 가능한 이름까지 사라짐

좁은 화면에서 기관명 텍스트를 시각적으로 숨기는 것까지는 좋은데, 코드에서도 정보를 통째로 지워 버립니다.

• 나쁜 예: 모바일에서 기관명 텍스트를 DOM에서 제거하고 마크만 남겼는데, 그 마크엔 대체 텍스트도 없음. 스크린리더에 "어느 기관인지" 정보가 완전히 사라짐.
• 올바른 예: 화면에서는 기관명을 숨기더라도, 마크의 대체 텍스트나 링크의 aria-label로 기관명을 코드에 남겨 둠.

실수 8) 하위 시스템에서 식별자 단절

본 사이트와 외부 위탁 개발한 하위 시스템(민원 신청, 예약 등)의 헤더가 달라, 사용자가 같은 기관인데 다른 곳에 온 듯 느낍니다.

• 나쁜 예: 메인은 ○○시 식별자, 신청 시스템은 정체불명의 다른 헤더. 사용자가 "여기 맞나?" 불안.
• 올바른 예: 하위 시스템에도 동일한 운영기관 식별자를 일관되게 적용. 사용자가 끊김 없이 같은 기관 서비스임을 인지.

실수 9) 헤더와 푸터의 기관 정보 불일치

헤더의 기관명과 푸터의 기관명·운영주체가 서로 다릅니다(리뉴얼·조직 개편 후 한쪽만 갱신된 경우).

• 나쁜 예: 헤더는 새 기관명, 푸터는 옛 기관명. 사용자가 어느 게 맞는지 혼란.
• 올바른 예: 헤더·푸터의 운영기관 정보를 일치시키고, 변경 시 양쪽을 함께 갱신.

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

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

개발자라면 — KRDS 컴포넌트 킷을 npm install krds-uiux로 설치하거나 CDN(krds.min.css / krds.min.js)으로 불러올 수 있습니다. 저장소의 html/code 폴더에 헤더·운영기관 식별자 관련 마크업 구조가 들어 있어, 표준 구조로 시작할 수 있습니다. 핵심 습관은 단순합니다. 식별자를 진짜 링크(`<a href="/">`)로 감싸고, 그 링크나 마크 이미지에 기관명을 접근 가능한 이름으로 부여하고(alt="○○부" 또는 aria-label="○○부 홈"), 포커스 표시를 지우지 않는 것. 이 세 가지만 지켜도 식별자 접근성의 대부분이 해결됩니다. 한 번 공통 헤더 컴포넌트로 잡아 두면 모든 페이지에 자동으로 따라옵니다.

디자이너라면 — KRDS 공식 Figma(@krds) 라이브러리에서 헤더와 운영기관 식별자 영역을 컴포넌트로 가져다 쓸 수 있습니다. 직접 그리기보다 표준 컴포넌트를 배치하면, 위치·크기·여백·상태가 기준에 맞춰집니다. 그리고 어두운 배경용 반전 로고를 함께 준비하고, 로고의 최소 크기와 보호 여백(로고 주변에 다른 요소가 침범하지 않는 빈 공간)을 규정해 두세요. 시안과 실제 구현 사이의 간극도 줄어듭니다.

기획자라면 — 화면 정의서에 "헤더 좌측 로고"라고만 적지 말고, "운영기관 식별자(기관 마크 + 기관명 텍스트 + 홈 링크, 대체 텍스트=기관명, 모바일 시 마크만 노출하되 접근 가능한 이름 유지)"처럼 구성 요소와 동작·접근성 요건을 함께 명시하세요. 이 한 줄이 디자인·개발 단계의 누락을 막습니다. 그리고 헤더와 푸터의 운영기관 정보가 일치하는지, 하위 시스템에도 동일하게 적용되는지를 검수 항목에 넣어 두세요.

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

여기까지가 KRDS의 운영기관 식별자 기준입니다. 그런데 정작 어려운 건 "그래서 우리 사이트 식별자는 이걸 지키고 있나?"를 확인하는 일입니다. 로고에 제대로 된 대체 텍스트가 있는지, 홈 링크가 진짜 링크인지, 키보드로 작동하는지, 모바일에서 접근 가능한 이름이 유지되는지를 사람이 일일이 손으로 점검하려면 끝이 없습니다. 페이지가 수십·수백 개인 공공 사이트라면 더더욱요.

ViewCheck(krds.viewcheck.co.kr)는 이 점검을 자동화합니다. URL만 넣으면 페이지를 실제로 크롤링해서, 운영기관 식별자를 포함한 컴포넌트들이 KRDS 기준을 지키는지 판정합니다. 운영기관 식별자는 KRDS 846규칙 중 컴포넌트(CP) 규칙군 446개에 속하고, 분석 결과의 컴포넌트(Components) 탭에서 확인할 수 있습니다.

ViewCheck가 운영기관 식별자에 대해 자동으로 보는 것들:

• 기관 마크의 대체 텍스트: 로고 이미지에 의미 있는 대체 텍스트(기관명)가 있는지, logo·이미지 같은 무의미한 값이 아닌지
• 홈 링크 여부: 식별자가 진짜 링크(<a>)로 감싸여 홈으로 연결되는지, <div> 클릭 같은 가짜 링크는 아닌지
• 접근 가능한 이름: 마크/링크에 어디로 가는지 알 수 있는 이름이 부여돼 있는지
• 위치·구조: 식별자가 헤더 영역에 표준 구조로 배치돼 있는지
• 터치 영역·대비: 모바일 뷰포트에서 로고 링크가 최소 권장 크기를 충족하는지, 색 대비가 기준에 맞는지(반응형·대비 분석과 연계)

DOM만으로 판단하기 어려운 시각적 부분(예: 기관명이 그림 속에만 있는 경우, 어두운 배경에서 로고가 묻히는 경우)은 KRDScan Vision AI가 스크린샷을 보고 보강 판정합니다. 그래서 "코드엔 텍스트 기관명이 없는데 화면엔 분명히 로고가 보이는" 비표준 구현도 놓치지 않습니다. 이 점이 단순 코드 검사 도구와 다른 부분입니다 — 사람이 눈으로 보듯 화면을 함께 보기 때문에, 표준을 우회해 만든 UI도 잡아냅니다.

리포트를 어떻게 읽나

분석이 끝나면 컴포넌트 탭에서 운영기관 식별자 관련 규칙의 통과/미통과 수와, 미통과한 항목의 위치(어느 페이지)·이유·개선 방법(howToFix)이 함께 나옵니다. 예를 들어 "메인 페이지 헤더 로고의 대체 텍스트가 비어 있음"처럼 구체적으로요. 여러 페이지를 한꺼번에 분석하면, "메인은 멀쩡한데 신청 시스템 페이지의 로고만 가짜 링크" 같은 페이지별 편차도 한눈에 드러납니다. 앞서 말한 "하위 시스템 식별자 단절"을 잡아내기 좋은 대목입니다. 어디부터 고쳐야 하는지 우선순위(P0~P3)도 함께 매겨지니, 한정된 시간에 가장 중요한 것부터 손볼 수 있습니다.

무료 진단으로 우리 사이트 메인부터 한 번 돌려 보면, 손으로는 몇 시간 걸릴 점검이 몇 분 만에 끝납니다. 그리고 그 결과는 막연한 "신뢰감 있게 만들자"가 아니라, "이 페이지의 로고에 이 대체 텍스트를 넣자"는 구체적인 작업 목록이 됩니다.

자주 묻는 질문

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

Q. 로고 이미지의 대체 텍스트(alt)에 정확히 뭐라고 적어야 하나요?

가장 단순하고 안전한 답은 "기관의 정식 명칭"입니다. alt="○○부"처럼요. 만약 그 로고가 홈으로 가는 링크를 겸한다면, 링크의 목적까지 담아 alt="○○부 홈"이나 aria-label="○○부 홈"으로 해도 좋습니다. 반대로 alt="logo", alt="심볼마크", alt="이미지" 같은 건 정보 가치가 없으니 피하세요. 핵심은 "눈으로 보면 알 수 있는 정보(어느 기관)를 글자로 옮기는 것"입니다.

Q. 기관 마크가 SVG인데, 대체 텍스트는 어떻게 넣나요?

SVG는 <img>처럼 alt를 쓸 수 없으니 방식이 조금 다릅니다. 가장 무난한 건 SVG를 감싼 링크나 요소에 aria-label="○○부"를 주는 것, 또는 SVG 안에 <title>○○부</title>를 넣고 SVG에 role="img"을 부여하는 것입니다. 어떤 방식이든 "이 그래픽이 어느 기관을 뜻하는지"가 코드로 전달되기만 하면 됩니다. 반대로 그 SVG가 옆에 기관명 텍스트가 이미 있는 순수 장식이라면 aria-hidden="true"로 숨겨 중복 낭독을 막는 게 맞습니다.

Q. 로고를 누르면 홈으로 가는 건 너무 당연한데, 굳이 신경 써야 하나요?

"당연히 그렇게 동작할 것"이라는 기대 때문에 오히려 더 중요합니다. 사용자는 길을 잃으면 무의식적으로 로고를 누릅니다. 그게 작동하지 않으면 "어? 왜 안 가지?" 하고 당황하죠. 그리고 이 동작이 진짜 링크(<a>)로 구현돼 있어야 키보드·스크린리더 사용자도 같은 출구를 쓸 수 있습니다. 자바스크립트로 흉내 낸 가짜 링크는 마우스 사용자에게만 작동하니, "당연한 동작"이 누군가에겐 막힌 문이 됩니다.

Q. 메인 페이지에서도 로고가 홈 링크인 게 맞나요? 이미 홈인데요.

대체로 그대로 두어도 괜찮습니다(눌러도 같은 페이지를 다시 불러올 뿐이니까요). 다만 더 친절하게 하려면, 메인 페이지에서는 이 링크에 aria-current="page"를 부여해 "지금 보고 있는 페이지가 바로 여기"임을 알려 줄 수 있습니다. 필수는 아니지만, 스크린리더 사용자에게 현재 위치를 분명히 해 주는 작은 배려입니다.

Q. 모바일에서 공간이 좁아 기관명 텍스트를 숨기고 마크만 남기고 싶은데, 괜찮나요?

시각적으로 기관명을 숨기는 것 자체는 문제없습니다. 다만 "코드에서까지 정보를 지우지 말 것"이 핵심입니다. 기관명 텍스트를 화면에서만 안 보이게 처리(visually hidden)하거나, 마크 이미지의 대체 텍스트·링크의 aria-label로 기관명을 코드에 남겨 두세요. 화면에서 글자가 사라졌다고 스크린리더에서도 "어느 기관인지 모름"이 되면, 가장 도움이 필요한 사용자를 배제하는 셈입니다.

Q. 헤더에 기관 로고가 있으면, 푸터에는 또 안 넣어도 되나요?

헤더와 푸터는 역할이 다릅니다. 헤더의 식별자는 "화면의 얼굴"(첫인상·신뢰), 푸터의 기관 정보는 "법적·행정적 명함"(주소·연락처·운영주체 등)에 가깝습니다. 둘 다 두는 게 일반적이고, 중요한 건 두 곳의 기관명·운영주체가 서로 일치하는 것입니다. 리뉴얼이나 조직 개편 후 한쪽만 갱신돼 어긋나는 경우가 흔하니, 변경 시 양쪽을 함께 확인하세요.

Q. 우리 기관은 브랜드 로고가 화려한데, 그대로 써도 되나요?

브랜드 정체성을 살리는 건 좋습니다. 다만 어떤 배경에서도 명확히 보이도록 반전(밝은/어두운) 버전을 준비하고, 너무 복잡한 디테일이 작은 크기·모바일에서 뭉개지지 않는지 확인하세요. 그리고 아무리 화려해도 접근성 요건(대체 텍스트, 진짜 링크, 포커스 표시)은 동일하게 적용됩니다. "예쁘게"와 "누구나 알아볼 수 있게"는 충돌하는 목표가 아닙니다.

Q. 외부 업체가 만든 하위 신청 시스템은 헤더가 다른데, 꼭 통일해야 하나요?

사용자 입장에서는 본 사이트든 하위 시스템이든 "같은 기관 서비스"입니다. 그런데 헤더가 갑자기 달라지면 "여기 맞나?" 하는 불안과 단절을 느낍니다. 피싱을 의심하게 되는 지점이기도 하죠. 그래서 하위 시스템에도 동일한 운영기관 식별자를 적용해, 사용자가 끊김 없이 같은 기관임을 인지하게 하는 게 맞습니다. 위탁 개발 발주 단계에서 "KRDS 식별자 적용"을 요건으로 명시하면 나중의 단절을 막을 수 있습니다.

Q. 이미 운영 중인 사이트인데, 헤더를 전부 다시 만들어야 하나요?

전부 갈아엎을 필요는 없습니다. 먼저 ViewCheck로 현황을 확인해 "지금 로고에 대체 텍스트가 있는지, 홈 링크가 진짜 링크인지, 어느 페이지의 식별자가 문제인지"를 목록으로 만든 다음, 치명적인 것(대체 텍스트 누락, 가짜 링크)부터 차례로 고치면 됩니다. 식별자는 보통 공통 헤더 하나로 관리되므로, 그 한 곳만 제대로 고치면 전 페이지가 동시에 개선되는 경우가 많습니다. 적은 작업으로 가장 큰 효과를 보는 대표적인 영역입니다.

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

ViewCheck로 돌려 보면 운영기관 식별자 문제가 한두 개로 끝나지 않을 수 있습니다. 특히 하위 시스템이 여럿인 큰 사이트라면요. 그래서 우선순위가 중요합니다. 식별자 문제를 심각도 순으로 정리하면 대략 이렇습니다.

가장 먼저(치명적) — 기관 마크에 대체 텍스트가 없거나 무의미한 경우, 그리고 홈 링크가 키보드로 작동하지 않는 가짜 링크인 경우. 이건 시각장애인이 "어느 기관에 있는지"조차 알 수 없게 만들거나, 키보드 사용자에게서 가장 기본적인 출구를 빼앗는 문제라 1순위입니다. 신뢰와 직결되는 첫 화면 요소라 더더욱 먼저 손봐야 합니다.

그다음(높음) — 어두운 배경에서 로고가 거의 안 보이는 대비 문제, 모바일에서 접근 가능한 이름까지 사라지는 문제, 그리고 하위 시스템에서 식별자가 단절되는 문제. 작동은 하지만 특정 사용자·특정 환경에서 정보가 닿지 않거나 신뢰가 흔들리는 경우입니다.

그 후(보통) — 기관명이 그림 속에만 있고 텍스트가 없는 문제, 포커스 표시 제거, 모바일 터치 영역 부족, 헤더-푸터 정보 불일치. 사용은 가능하지만 검색·확대·일관성 측면에서 손해를 보는 항목입니다.

여력이 되면(낮음) — 메인 페이지에서 현재 위치 표시(aria-current) 추가, 로고 보호 여백 규정화, 반전 로고 정비 같은 다듬기. 접근성을 막는 건 아니지만 완성도를 한 단계 끌어올리는 항목입니다.

ViewCheck 리포트는 이 우선순위(P0~P3)를 자동으로 매겨 주기 때문에, "일단 눈에 띄는 것부터"가 아니라 "사용자 신뢰와 접근을 가장 많이 좌우하는 것부터" 순서대로 처리할 수 있습니다.

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

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

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

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

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

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

• ☐ 식별자가 화면 헤더 좌측의 예측 가능한 자리에 있다.
• ☐ 기관 마크 이미지에 의미 있는 대체 텍스트(기관명)가 있다(logo·이미지 같은 무의미한 값이 아니다).
• ☐ 기관 마크가 SVG라면 role="img" + aria-label/<title>로 기관명이 코드에 담겨 있다.
• ☐ 기관명이 실제 텍스트로 존재한다(그림 속 글자에만 의존하지 않는다).
• ☐ 식별자가 진짜 링크(`<a href="/">`)로 홈에 연결된다(<div> 클릭 같은 가짜 링크가 아니다).
• ☐ 홈 링크에 어디로 가는지 알 수 있는 접근 가능한 이름이 있다.
• ☐ 키보드만으로 식별자에 초점이 가고 Enter로 홈에 갈 수 있다.
• ☐ 초점이 왔을 때 포커스 표시가 또렷하다(outline: none으로 지우지 않았다).
• ☐ 헤더 배경(밝음/어두움/스크롤 변화)과 로고의 명도 대비가 충분하다.
• ☐ 모바일에서 로고 링크의 터치 영역이 충분하다(약 44px 이상).
• ☐ 모바일에서 기관명을 숨겨도 접근 가능한 이름은 코드에 남아 있다.
• ☐ 사이트 전체(하위 시스템 포함)에서 식별자가 일관되고, 헤더-푸터 기관 정보가 일치한다.

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

운영기관 식별자는 작아 보이지만, 사용자가 공공 서비스에 들어서서 가장 먼저 보고, 가장 먼저 신뢰 여부를 판단하는 첫 관문입니다. 그 작은 로고 자리 하나가 누군가에겐 "여기는 믿을 수 있는 곳"이라는 안심이고, 또 누군가에겐 "여기가 어딘지 모르겠다"는 미로의 입구입니다. 우리가 무심코 얹은 로고 이미지 하나가, 누군가에게는 그 민원을 안심하고 끝낼 수 있느냐 없느냐를 가릅니다.

오늘 정리한 기준이 거창해 보일 수 있지만, 핵심은 결국 단순합니다. 기관명을 코드에도 담고, 로고를 진짜 홈 링크로 만들고, 키보드로 쓸 수 있게 하고, 어떤 배경에서도 보이게 하는 것. 이 네 가지만 챙겨도 식별자 위반의 대부분은 사라집니다. 그리고 그게 잘 됐는지는 ViewCheck로 몇 분이면 확인할 수 있습니다. 완벽을 한 번에 만들 필요는 없습니다. 공통 헤더의 식별자 하나부터 제대로 고치면, 우리 사이트의 모든 페이지가 동시에 더 믿음직하고 더 많은 사람에게 열립니다. 다음 글에서는 이 식별자가 자리 잡은 헤더 영역의 또 다른 핵심 요소를 같은 방식으로 뜯어보겠습니다.

우리 사이트의 운영기관 식별자는 지금 제 역할을 하고 있을까요? krds.viewcheck.co.kr에서 URL만 넣으면 무료로 확인할 수 있습니다. 메인 페이지 하나만 돌려 봐도, 로고에 대체 텍스트가 있는지, 홈 링크가 제대로 작동하는지 바로 보입니다.

#KRDS #공공웹 #디자인시스템 #운영기관식별자Identifier #웹접근성 #ViewCheck #정부웹사이트 #UIUX #헤더 #브랜드아이덴티티 #공공서비스신뢰 #운영기관식별자 #Identifier #KRDS기준 #디자인원칙 #표준가이드 #UI컴포넌트 #컴포넌트설계 #전자정부 #디지털정부