공공웹은 검색에 잡히고 있나 — ViewCheck가 메타태그·Open Graph·구조화데이터를 진단하는 방법

검색창에 '기관명'을 치면 무엇이 보이는가, 우리가 SEO 진단을 시작한 이유

들어가며 — "검색하면 나오지 않나요?"라는 가장 쉬운 질문

"검색하면 나오지 않나요?"

공공 웹사이트를 운영하는 담당자들에게 SEO 얘기를 꺼내면 가장 먼저 돌아오는 반응이다. 맞는 말이기도 하다. 공공기관 이름을 구글이나 네이버에 치면 대부분 첫 페이지에 나온다. 그런데 '기관 이름'으로 검색하는 사람은 그 기관을 이미 아는 사람이다. 그 기관이 다루는 정보를 몰라서 검색하는 시민은, 기관 이름이 아니라 '민원 키워드'로 검색한다. "노인 돌봄 신청 방법", "어린이집 인가 서류", "주차위반 이의신청 기간" 같은 식으로.

이 지점에서 공공웹의 SEO 문제가 시작된다. 기관명으로 치면 나오는데, 시민이 실제로 필요한 정보를 검색하면 엉뚱한 블로그나 커뮤니티 글이 먼저 나오고 공식 사이트는 뒤페이지에 있는 경우를 우리는 ViewCheck 분석 과정에서 적잖이 마주쳤다. 공식 정보가 있는데, 검색엔진이 그 페이지를 제대로 이해하지 못해서 상위에 못 올라오는 것이다.

왜 그럴까. 이유는 여러 가지지만, 그 시작에는 거의 항상 몇 가지 공통 문제가 있다. 메타 태그가 없거나, 모든 페이지가 같은 title을 쓰거나, Open Graph 태그가 빠져 있어서 SNS에 링크를 퍼 나를 때 이미지와 설명이 공란으로 뜨거나, 구조화데이터(JSON-LD)가 전혀 없어서 검색 결과에 리치 결과(Rich Result)가 표시되지 않거나, 헤딩(H1~H6) 구조가 제멋대로거나.

이런 요소들은 기술적으로 복잡하지 않다. 마크업 몇 줄이면 달라지는 것들이다. 그런데 정작 많은 공공 사이트에서 이 기초가 빠져 있다. 왜일까. 담당자가 몰라서이기도 하지만, 더 근본적으로는 "내 사이트의 SEO 요소들이 지금 어떤 상태인지"를 체계적으로 파악하는 도구와 절차가 없기 때문이다. 눈에 잘 안 보이고, 직접적인 불편이 즉각 생기지 않는 영역이라 후순위로 밀린다.

ViewCheck가 SEO 진단 기능을 만든 이유가 여기에 있다. 공공 웹의 SEO는 민간 이커머스의 SEO와 다르다. 클릭률을 올려서 수익을 늘리는 게 목적이 아니라, 시민이 공식 정보를 더 쉽게 찾을 수 있게 하는 게 목적이다. 그 목적을 위해 기초가 갖춰져 있는지, 빠진 곳이 어디인지를 빠르게 파악하는 것 — 그것이 우리가 SEO 진단에서 하려는 일이다.

이 글에서는 ViewCheck가 공공 웹의 SEO 요소를 어떻게 진단하는지를 주제별로 풀어간다. 메타 태그, Open Graph 태그, 구조화데이터(JSON-LD), 헤딩 계층, canonical URL, 그리고 robots.txt와 sitemap.xml까지. 기술적인 내용이지만, 가능한 한 "왜 중요한가"와 "공공웹에서는 어떤 패턴이 자주 보이는가"를 중심으로 이야기하겠다. 아직 우리가 파악하지 못한 부분도 솔직하게 적을 것이다.

밝은 사무실에서 한국인 마케터가 노트북으로 SEO 체크리스트를 검토하고 있는 모습. — 공공 웹의 SEO 체크리스트 — 메타 태그부터 구조화 데이터까지, 기초 점검이 먼저다.

SEO가 공공웹에서 왜 중요한가 — 시민의 검색 여정 이야기

먼저 맥락부터 짚고 가자. 공공 웹에서 SEO를 이야기할 때, 우리는 '광고비를 아끼거나 쇼핑몰 전환율을 올리는' 식의 상업적 SEO와는 다른 이야기를 한다.

공공 서비스는 시민의 '필요'에서 시작된다. 어떤 시민이 특정 지원금을 신청하고 싶다. 그는 검색창을 연다. 기관 이름을 모를 수도 있다. 정확한 사업 이름도 모른다. 그냥 "청년 창업 지원금 신청"이라고 치거나, "어르신 틀니 지원 2025" 같은 키워드를 넣는다. 검색 결과 첫 페이지에 공식 기관 페이지가 나오면 시민은 공식 정보를 얻는다. 하지만 첫 페이지에 커뮤니티 게시글, 블로거의 요약 포스팅, 뉴스 기사만 잔뜩 뜨고 공식 페이지가 2~3페이지에 있다면, 시민은 그 비공식 정보를 통해 서비스를 이해하게 된다. 부정확하거나 오래된 정보일 가능성이 높다.

공식 정보가 있어도 검색엔진이 그 페이지를 제대로 인식하지 못하면, 결과적으로 공공 서비스 접근성이 떨어진다. 이건 단순한 트래픽 문제가 아니라, 시민의 공공 서비스 이용 경험 전반의 문제다.

행정안전부의 「전자정부 웹사이트 품질관리 지침」(행안부고시 제2025-46호, 2025.6.25 일부개정)은 공공 웹사이트가 갖춰야 할 7대 품질 영역을 정의한다. 그 중 개방성은 "정보의 공개와 공유를 위해 robots.txt, 메타데이터, 크롤링 허용 등 정보가 열려 있는가"를 다룬다. 검색엔진이 사이트의 정보를 수집하고 색인할 수 있어야 한다는 것이 공공 웹의 공식 품질 기준 중 하나인 것이다. SEO의 기초는 곧 개방성의 기초이기도 하다.

우리가 ViewCheck에서 여러 공공 사이트를 분석하면서 자주 보는 현상은 대략 이렇다. 메인 페이지는 어느 정도 관리가 되어 있다. title 태그도 있고, description도 있다. 그런데 신청 페이지, 상세 공지 페이지, 검색 결과 페이지로 들어가면 상황이 달라진다. title이 사이트 이름 하나로 전부 같거나, description이 비어 있거나, H1이 없는 페이지도 나온다. 개별 페이지의 SEO 요소가 제대로 관리되지 않는 것이다.

이게 왜 문제냐면, 구글과 네이버 같은 검색엔진은 사이트 전체가 아니라 개별 페이지를 색인한다. 메인은 좋아도, 실제 콘텐츠가 있는 하위 페이지들의 SEO가 안 되어 있으면 그 페이지들은 검색 결과에서 잘 보이지 않는다. 시민이 직접 찾아야 할 정보가 있는 페이지가 바로 그 하위 페이지들이다.

메타 태그의 기초 — title, description, viewport, lang

SEO 진단의 첫 번째 관문은 메타 태그다. HTML의 <head> 영역에 들어가는 이 짧은 코드들이, 검색엔진과 브라우저가 페이지를 이해하는 방식에 직접 영향을 준다.

가장 중요한 것은 title 태그다. 검색 결과 목록에서 파란색으로 보이는 제목이 바로 이 title 태그에서 온다. Google Search Central의 공식 문서는 이렇게 설명한다.

"Make sure every page on your site has a title specified in the element. Write descriptive and concise text for your <title> elements." — Google, SEO Starter Guide: The Basics, developers.google.com </blockquote> 좋은 title 태그는 해당 페이지의 내용을 정확하고 간결하게 요약해야 한다. 그리고 페이지마다 달라야 한다. 사이트 전체가 "○○시청 공식 홈페이지"라는 동일한 title을 쓴다면, 검색엔진은 각 페이지를 구분하기 어렵고, 사용자는 검색 결과에서 어떤 페이지가 자신에게 필요한지 판단하기 어렵다. Google은 약 60~70자 이내를 권장하며, 모바일과 데스크톱 화면 너비에 맞게 잘리지 않도록 하는 것이 좋다. meta description은 검색 결과에서 title 아래에 나오는 요약 설명이다. Google Search Central의 가이드는 이렇게 말한다. <blockquote> "A meta description tag generally informs and interests users with a short, relevant summary of what a particular page is about. They are like a pitch that convince the user that the page is exactly what they're looking for." — Google, How to Write Meta Descriptions, developers.google.com </blockquote> meta description은 직접적인 랭킹 요소는 아니다. 그러나 검색 결과 페이지(SERP)에서 사용자가 클릭할지 말지를 결정하는 '문구'로 작용한다. 잘 쓴 description은 클릭률(CTR)을 높인다. 공공 사이트의 경우 서비스 내용을 명확하게 담아야 하고, 가능하면 신청 기간, 대상, 핵심 키워드를 포함하는 것이 좋다. 권장 길이는 대략 150~155자 내외다. 주의할 점이 있다. Google은 실제로 meta description을 그대로 쓰지 않을 때가 많다. 페이지 본문에서 더 적절한 문구를 골라 검색 결과 스니펫으로 사용하기도 한다. 연구에 따르면 Google이 meta description을 재작성하는 비율이 62~70%에 달한다는 분석도 있다. 그렇다고 description을 안 써도 된다는 뜻이 아니다. 제대로 작성된 description은 Google이 '그대로 쓰기 가장 좋은 요약'으로 선택할 가능성이 높고, 소셜 미디어에서 공유될 때도 이 description이 표시된다. viewport 메타 태그는 반응형 웹의 기초다. <code><meta name="viewport" content="width=device-width, initial-scale=1"></code> 한 줄이 없으면, 모바일에서 PC 화면이 축소되어 표시된다. W3C(월드와이드웹 컨소시엄)와 WHATWG의 HTML 표준에서 viewport 메타 태그는 모바일 반응형 웹의 기본 요소로 명시된다. Google도 모바일 친화성을 랭킹 신호로 사용하기 때문에, viewport 설정 누락은 검색 노출에도 영향을 줄 수 있다. lang 속성은 HTML 태그에 붙는 언어 선언이다. <code><html lang="ko"></code>처럼. 접근성(스크린 리더가 올바른 언어로 읽을 수 있도록)과 SEO(검색엔진이 페이지 언어를 인식해 적절한 사용자에게 노출하도록) 모두에서 중요하다. KWCAG(한국형 웹 콘텐츠 접근성 지침) 2.2에서도 콘텐츠의 주 언어를 명시하도록 요구하는 지침이 있다. ViewCheck는 이 네 가지 기본 메타 태그를 모든 페이지에서 점검한다. 있는지 없는지가 아니라, 있더라도 제대로 작동하는지까지 확인한다. 예를 들어 title이 있어도 30자가 안 되는 지나치게 짧은 경우나, 모든 페이지가 같은 title을 공유하는 경우도 점검 대상에 포함한다. 이 판정 과정이 어떻게 이뤄지는지는 뒤에서 다시 다룰 것이다. <hr> <h2 id="h-4">Open Graph 태그 — SNS에서 공공 정보가 어떻게 보이는가</h2> 메타 태그가 검색엔진을 위한 것이라면, Open Graph 태그는 소셜 미디어를 위한 것이다. 카카오톡, 페이스북, 트위터(X), 슬랙, 텔레그램 등 대부분의 메신저와 소셜 플랫폼은 링크를 공유할 때 해당 페이지의 Open Graph 태그를 읽어서 '링크 미리보기(preview card)'를 생성한다. Open Graph 프로토콜은 2010년 페이스북이 만들었다. 공식 사양은 ogp.me에서 관리된다. 핵심 태그 네 가지는 다음과 같다. <pre><code class="language-html"><meta property="og:title" content="페이지 제목" /> <meta property="og:description" content="페이지 요약 설명" /> <meta property="og:image" content="https://example.go.kr/images/thumb.jpg" /> <meta property="og:url" content="https://example.go.kr/page/" /> </code></pre> 이 네 가지를 갖추면, 카카오톡에서 링크를 공유했을 때 이미지와 제목, 설명이 미리보기로 나타난다. 없으면 URL 텍스트만 노출되거나, 임의의 이미지가 잡히거나, 설명이 공란으로 뜬다. 공공 정보가 시민에게 전달되는 경로는 공식 홈페이지 방문만이 아니다. 담당자가 카카오 단체채팅방에 공지를 공유하거나, 인스타그램에 링크를 올리거나, 지역 온라인 커뮤니티에 글을 남기는 식으로 퍼진다. 이때 Open Graph 미리보기가 제대로 나타나야 시민이 클릭할 가능성이 높아지고, 공식 정보임을 신뢰하게 된다. Open Graph 태그가 없거나 부실한 경우, 어떤 일이 생기는지를 구체적으로 상상해 보자. 주민센터 담당자가 "2025년 긴급복지지원 신청 안내" 페이지 링크를 주민 단체채팅방에 올린다. og:image가 없으면 기관 로고도, 안내 배너도 보이지 않는다. og:title이 없으면 URL만 뜬다. 시민 입장에서는 이 링크가 신뢰할 수 있는 공식 정보인지, 아니면 누군가 요약한 블로그인지 구분이 안 된다. 클릭률도 떨어진다. <code>og:image</code>는 특히 중요하다. 대개 1200×630픽셀 이상의 비율을 권장하며, 정보를 담은 대표 이미지가 있어야 한다. 그리고 <code>og:url</code>은 페이지의 canonical URL과 동일해야 한다. 둘이 다르면 소셜 플랫폼이 링크를 잘못 인식할 수 있다. 우리가 ViewCheck로 공공 사이트들을 분석하면서 자주 마주치는 패턴이 있다. 메인 페이지에는 Open Graph 태그가 있는데, 개별 콘텐츠 페이지(보도자료, 공지사항, 사업 안내 페이지 등)에는 없는 경우다. 시민이 직접 공유하는 건 개별 페이지인데, 정작 그 페이지들에 OG 태그가 없다. 또는 og:image가 모든 페이지에서 동일한 기관 로고를 가리켜, 다양한 콘텐츠를 공유해도 항상 같은 이미지가 뜨는 경우도 많다. ViewCheck의 SEO 진단은 메인 페이지만 보지 않는다. 사이트를 크롤링하며 여러 페이지의 OG 태그 현황을 페이지별로 수집하고, 전체 사이트에서 OG 태그 커버리지가 어느 수준인지를 함께 본다. 물론 100%가 아니더라도 어떤 유형의 페이지에서 주로 누락되는지를 파악하는 것만으로도 개선 우선순위를 잡는 데 도움이 된다. <figure><img src="https://xbbhievqdmccsexxrdtn.supabase.co/storage/v1/object/sign/covers/content/qfeu2yqf-108088.jpg?token=eyJraWQiOiJzdG9yYWdlLXVybC1zaWduaW5nLWtleV8yOWQwYWZmNy1mOWJhLTRkNmUtYmZlZi0yMzg2NTc0ZWUzODQiLCJhbGciOiJIUzI1NiJ9.eyJ1cmwiOiJjb3ZlcnMvY29udGVudC9xZmV1MnlxZi0xMDgwODguanBnIiwic2NvcGUiOiJkb3dubG9hZCIsImlhdCI6MTc4NDUwNjIyNSwiZXhwIjoyMDk5ODY2MjI1fQ.OlJZUc7jdl_bWbb5B7zYw9f3mqW9N5qdzjmtcPKLfAQ" alt="소프트하게 블러 처리된 화면의 코드를 바라보며 검색 최적화 작업을 하는 한국인 개발자의 클로즈업." loading="lazy" /><figcaption>소셜 공유 시 미리보기를 결정하는 Open Graph 태그 — 몇 줄 코드의 차이가 클릭률을 바꾼다.</figcaption></figure><hr> <h2 id="h-5">구조화데이터(JSON-LD) — 검색엔진이 '이해하는' 정보</h2> SEO의 한 단계 위에 **구조화데이터(Structured Data)**가 있다. 단순히 "이 페이지가 존재한다"를 알리는 것에서 나아가, "이 페이지가 어떤 종류의 정보이고, 핵심 내용이 무엇인지"를 검색엔진에게 명시적으로 알려주는 기술이다. 구조화데이터의 형식은 여러 가지가 있지만, 지금 가장 널리 쓰이고 구글이 권장하는 방식은 **JSON-LD(JSON for Linked Data)**다. Google Search Central의 공식 문서는 이렇게 설명한다. <blockquote> "Google recommends using JSON-LD for structured data if your site's setup allows it, as it's the easiest solution for website owners to implement and maintain at scale (in other words, less prone to user errors)." — Google, Intro to How Structured Data Markup Works, developers.google.com </blockquote> JSON-LD는 <code><script type="application/ld+json"></code> 태그 안에 JSON 형식으로 데이터를 넣는 방식이다. HTML 본문 어느 위치에나 삽입할 수 있고, 기존 HTML 코드를 건드리지 않아도 된다. 이전 방식인 Microdata나 RDFa와 달리, 페이지 콘텐츠와 메타 정보를 분리해서 관리할 수 있어 유지보수가 쉽다. 구조화데이터에서 어떤 '타입'을 쓸지는 schema.org에서 정의한다. schema.org는 Google, Microsoft, Yahoo, Yandex가 공동으로 만든 어휘 표준이다. 현재 823개의 타입(Type)과 1,529개의 속성(Property)이 정의되어 있다(schema.org 공식). 공공 웹에서 자주 활용할 수 있는 타입들을 몇 가지만 꼽으면 이렇다. <ul> <li>Organization: 기관의 이름, 로고, 공식 URL, 소셜 미디어 계정, 연락처</li> <li>GovernmentOrganization: Organization의 하위 타입. 정부기관에 특화</li> <li>Event: 행사, 설명회, 공청회 정보</li> <li>Article / NewsArticle: 보도자료, 뉴스 공지</li> <li>FAQPage: 자주 묻는 질문과 답변</li> <li>Service: 공공 서비스, 신청 안내</li> <li>WebSite: 사이트 전체의 검색 기능(Sitelinks Searchbox) 등록</li> </ul> 이 구조화데이터를 제대로 삽입하면, 검색 결과에 **리치 결과(Rich Result)**가 뜰 수 있다. 일반적인 파란 제목+설명 텍스트 대신, 별점이 함께 뜨거나, FAQ가 펼쳐지거나, 이미지가 표시되는 등 시각적으로 더 풍부한 형태다. 이 리치 결과의 효과는 실측 데이터가 있다. Google Search Central의 공식 구조화데이터 문서에서는 Nestlé의 사례를 인용한다. <blockquote> "Nestlé has measured pages that show as rich results in search have an 82% higher click through rate than non-rich result pages." — Google, Intro to How Structured Data Markup Works, developers.google.com </blockquote> 82%는 꽤 큰 숫자다. 물론 이커머스나 레시피처럼 시각화가 강한 영역에서의 효과가 공공기관 정보 페이지와 동일하게 적용된다고 단정할 수는 없다. 다만 '페이지에 대한 더 많은 정보를 검색엔진에게 명확히 전달하면, 검색 결과의 노출 품질이 올라간다'는 원리 자체는 공공 웹에도 동일하게 적용된다. 공공 사이트에서 자주 만나는 패턴은, 구조화데이터가 아예 없거나, 있어도 기본적인 Organization 타입 하나뿐인 경우다. 보도자료는 Article 타입으로, FAQ는 FAQPage 타입으로, 공개 행사는 Event 타입으로 마크업하면 각각 더 풍부한 검색 결과를 만들 수 있는데, 대부분의 공공 사이트는 이 부분을 활용하지 않는다. ViewCheck의 SEO 진단에서는 구조화데이터의 존재 여부, 어떤 타입이 사용되었는지, Google의 검증 기준에 맞게 작성되었는지를 확인한다. JSON-LD 형식인지, Microdata나 RDFa 형식인지도 구분한다. 이 판정 역시 메인 페이지뿐 아니라 크롤링된 여러 페이지에 걸쳐 이뤄진다. <hr> <h2 id="h-6">헤딩 계층 — H1에서 H6까지, 구조가 내용을 안내한다</h2> 구조화데이터가 검색엔진을 위한 '명시적 선언'이라면, 헤딩(H1~H6) 계층은 페이지 콘텐츠 자체의 구조를 드러내는 방식이다. 접근성과 SEO 양쪽에 모두 영향을 미친다. 헤딩의 기본 원칙은 간단하다. H1은 페이지의 핵심 주제를 나타내는 가장 중요한 제목이고, H2~H6은 그 아래에 들어가는 소제목들이다. 책의 목차처럼, 페이지의 구조를 위계 있게 나타낸다. SEO 관점에서 헤딩은 검색엔진이 페이지 내용을 이해하는 데 사용하는 신호다. Google Search Central 커뮤니티에 올라온 공식 답변과 여러 SEO 연구에 따르면, H1은 title 다음으로 강한 on-page SEO 신호다. 그러나 Google은 최근 헤딩의 "위계적 순서 자체가 랭킹에 직접 영향을 주지는 않는다"고도 명확히 했다. 즉, H2 다음에 H4가 온다고 해서 랭킹이 직접 떨어지지는 않지만, 의미론적으로 바른 구조가 검색엔진의 이해를 돕고 접근성을 높인다는 점에서 중요하다. 접근성 관점에서 헤딩은 더 직접적인 영향을 미친다. 시각 장애인이 사용하는 스크린 리더는 헤딩을 '목차'처럼 활용한다. 사용자는 헤딩을 통해 페이지의 구조를 탐색하고, 원하는 섹션으로 빠르게 이동한다. 헤딩이 없거나 계층이 엉망이면, 스크린 리더 사용자는 페이지 전체를 처음부터 끝까지 읽어야 하는 상황이 된다. KWCAG 2.2와 WCAG 2.2 모두 논리적인 헤딩 구조를 접근성 요건으로 포함한다. 공공 사이트에서 자주 보이는 헤딩 관련 문제들은 크게 몇 가지다. H1 누락 또는 복수 H1: 페이지에 H1이 없거나, 시각적 디자인 때문에 CSS로 만든 '큰 제목'이 있는데 실제 HTML에는 H1이 없는 경우. 또는 로고, 메뉴, 본문 제목 등 여러 곳에 H1이 중복 사용된 경우. 헤딩 단계 건너뜀: H1 다음에 바로 H4가 오거나, H2 아래에 H6이 오는 식으로 위계를 건너뛰는 경우. 시각적으로는 폰트 크기만 맞추면 되지만, 구조적으로는 맞지 않는다. 스타일 목적의 헤딩 남용: "크게 보이고 싶어서" H1이나 H2를 쓰는 경우. 페이지의 실제 내용 구조와 무관하게 헤딩이 배치된다. 모든 페이지의 H1이 동일: 사이트 공통 헤더에 사이트명이 H1으로 박혀 있어서, 어느 페이지를 가도 H1은 "○○시청"뿐인 경우. ViewCheck의 SEO 진단은 각 페이지의 H1~H6 구조를 수집해서, H1 개수, 헤딩 계층의 논리성, 헤딩 없는 페이지 비율 등을 정리한다. 특히 다중 페이지 분석을 기본으로 하기 때문에, "메인 페이지의 헤딩 구조는 괜찮은데 하위 페이지들의 헤딩이 깨져 있다"는 패턴도 잡아낼 수 있다. <hr> <h2 id="h-7">canonical URL — 중복 페이지 문제와 정규화</h2> 공공 사이트에서 흔히 발생하는 또 다른 SEO 문제가 중복 콘텐츠다. 같은 내용이 여러 URL에서 접근 가능할 때 생기는 문제다. 예를 들어, 한 공공기관 사이트에서 동일한 공지 페이지가 <code>https://example.go.kr/notice/123</code>과 <code>https://www.example.go.kr/notice/123</code> (www 차이), 또는 <code>https://example.go.kr/notice/123?page=1</code> (파라미터 붙은 버전)으로 동시에 접근 가능한 경우가 있다. 또는 모바일 전용 주소(<code>m.example.go.kr</code>)와 PC 주소가 별도로 운영되는 경우도 있다. 검색엔진 입장에서는 같은 내용이 여러 URL에 있으면 '어느 URL을 기준으로 색인해야 하는가'를 판단해야 한다. 잘못하면 링크 점수가 분산되거나, 원본이 아닌 복사본이 더 높이 뜰 수도 있다. 이 문제를 해결하는 방법이 canonical 태그다. <code><link rel="canonical" href="https://example.go.kr/notice/123" /></code>를 HTML head에 넣어서, "이 URL이 이 콘텐츠의 정규(canonical) 주소다"라고 선언하는 것이다. Google Search Central의 공식 가이드는 이렇게 설명한다. <blockquote> "Google chooses a single URL (the canonical URL) to show users, per piece of content. To specify which URL you want Google to consider canonical, use the rel='canonical' link element." — Google, How to Specify a Canonical with rel="canonical", developers.google.com </blockquote> canonical 태그가 없으면 Google이 알아서 canonical을 결정하는데, 그 결과가 우리가 원하는 URL이 아닐 수 있다. 특히 파라미터가 붙은 URL이나 www/non-www가 혼재하는 경우에는 명시적 canonical 선언이 중요하다. 공공 사이트에서 자주 보이는 문제는 canonical 태그 자체가 없는 경우, 또는 canonical이 자기 자신을 가리키지 않고 엉뚱한 URL을 가리키는 경우(CMS나 템플릿 오류로 발생), 또는 og:url과 canonical이 서로 다른 URL을 가리키는 경우 등이다. ViewCheck는 각 페이지의 canonical 태그 존재 여부와, canonical이 가리키는 URL이 접근 가능한 유효한 URL인지를 점검한다. og:url과의 일치 여부도 확인 대상이다. <figure><img src="https://xbbhievqdmccsexxrdtn.supabase.co/storage/v1/object/sign/covers/content/yc1a7q5w-101587.jpg?token=eyJraWQiOiJzdG9yYWdlLXVybC1zaWduaW5nLWtleV8yOWQwYWZmNy1mOWJhLTRkNmUtYmZlZi0yMzg2NTc0ZWUzODQiLCJhbGciOiJIUzI1NiJ9.eyJ1cmwiOiJjb3ZlcnMvY29udGVudC95YzFhN3E1dy0xMDE1ODcuanBnIiwic2NvcGUiOiJkb3dubG9hZCIsImlhdCI6MTc4NDUwNjIyNSwiZXhwIjoyMDk5ODY2MjI1fQ.AzrP0O7QNCKTpe14v5xn8VF2zIOPpFClkM4dgNLsJZA" alt="책상에 앉아 공공 웹사이트의 검색 노출 최적화 작업에 집중하는 한국인의 모습." loading="lazy" /><figcaption>canonical 태그 하나로 중복 페이지 문제가 해결된다 — 기초지만 놓치기 쉬운 영역.</figcaption></figure><hr> <h2 id="h-8">robots.txt와 sitemap.xml — 개방성의 가장 기본 인프라</h2> SEO에서 '수집 가능성'을 결정하는 두 개의 파일이 있다. robots.txt와 sitemap.xml이다. robots.txt는 검색엔진 크롤러에게 "어떤 페이지를 수집해도 되고, 어떤 페이지는 수집하지 말아야 하는지"를 알려주는 파일이다. 사이트 루트에 <code>https://example.go.kr/robots.txt</code> 형태로 놓인다. 검색엔진의 Googlebot, Naverbot 같은 봇들은 사이트 방문 전에 이 파일을 먼저 읽는다. Google은 robots.txt 파일 생성과 제출에 관한 공식 가이드를 제공하고 있다. robots.txt의 <code>User-agent</code>, <code>Allow</code>, <code>Disallow</code> 지시어를 통해 특정 봇에 대해 접근 허용/차단을 세밀하게 설정할 수 있다. 잘못 설정된 robots.txt는 심각한 결과를 낳는다. 국내 SEO 전문가들이 공유하는 사례에 따르면, robots.txt 오설정으로 인해 사이트 전체 색인이 블락되어 하루 트래픽이 30만 명에서 2천 명대로 떨어진 사례도 있다. 의외로 많은 국내 금융권 기업, 국가 기관, 지자체, 대학 웹사이트에서 이런 실수를 찾아볼 수 있다고 SEO 전문가들은 지적한다(TBWA 데이터랩, robots.txt 총정리 가이드). 행안부 「전자정부 웹사이트 품질관리 지침」(고시 제2025-46호)은 최근 개정에서 흥미로운 변화를 담았다. 기존에는 크롤링을 '완전 허용'하도록 했던 개방성 기준이, '일부 차단'이 가능하도록 수정되었다. 즉 개인정보가 포함된 영역, 민감한 내부 관리 페이지 등은 합리적 근거로 차단할 수 있게 된 것이다. 이 변화는 robots.txt를 '있으면 무조건 Disallow 없게'가 아니라, 목적에 맞게 섬세하게 관리해야 한다는 방향을 시사한다. sitemap.xml은 사이트에 있는 모든(혹은 주요) URL의 목록을 XML 형식으로 제공하는 파일이다. 검색엔진이 새로운 페이지를 더 빠르게 발견하고 색인할 수 있도록 돕는다. lastmod(최종 수정일), changefreq(변경 주기) 등의 속성으로 콘텐츠 업데이트 정보도 제공할 수 있다. 공공 사이트에서 자주 보이는 sitemap 관련 문제는 크게 세 가지다. 첫째, sitemap.xml 자체가 없는 경우. 둘째, sitemap이 있는데 robots.txt에 sitemap 위치가 명시되어 있지 않은 경우. 셋째, sitemap에 포함된 URL들이 실제로는 404 오류를 반환하거나, 이미 삭제된 페이지를 가리키는 경우(sitemap 관리가 자동화되어 있지 않을 때 흔히 발생). ViewCheck는 robots.txt와 sitemap.xml을 각 사이트에 대해 수집하고 파싱한다. robots.txt에서 Disallow 규칙이 너무 광범위하게 설정되어 있진 않은지, 중요한 콘텐츠 페이지가 차단되어 있진 않은지를 체크한다. sitemap.xml에서는 URL 수, lastmod의 유효성, sitemapindex(sitemap 파일을 여러 개로 나눈 경우의 인덱스 파일) 구조 등을 확인한다. 이 수집과 파싱 작업은 사이트 분석 시 1회만 수행하며, 다중 페이지 분석이라도 robots.txt와 sitemap은 사이트당 한 번만 가져온다. <hr> <h2 id="h-9">ViewCheck SEO 진단의 실제 — 14종 점검 항목과 다중 페이지 접근</h2> 지금까지 개별 SEO 요소들을 설명했다. 그럼 ViewCheck의 SEO 진단이 실제로는 어떤 구조로 이뤄지는지를 정리해보자. ViewCheck는 SEO 분석을 크게 두 층위로 나눈다. 사이트 단위: robots.txt, sitemap.xml, canonical 패턴처럼 사이트 전체에 걸쳐 한 번만 수집·분석하면 되는 항목. 페이지 단위: title, description, OG 태그, 헤딩 구조, 구조화데이터처럼 각 페이지마다 별도로 수집·분석해야 하는 항목. SEO 진단에서 체크하는 주요 항목들은 다음과 같다. <table> <thead> <tr> <th>항목</th> <th>점검 내용</th> </tr> </thead> <tbody><tr> <td>title 태그</td> <td>존재 여부, 길이(50~60자 권장), 페이지별 중복 여부</td> </tr> <tr> <td>meta description</td> <td>존재 여부, 길이(150자 내외 권장), 페이지별 중복 여부</td> </tr> <tr> <td>viewport 메타</td> <td>반응형 뷰포트 선언 여부</td> </tr> <tr> <td>lang 속성</td> <td>HTML lang 속성 선언 및 적합한 언어 코드 여부</td> </tr> <tr> <td>H1 헤딩</td> <td>존재 여부, 페이지당 단일 H1 여부</td> </tr> <tr> <td>H2~H6 계층</td> <td>헤딩 단계 건너뜀 여부, 전반적 계층 논리성</td> </tr> <tr> <td>og:title</td> <td>Open Graph 제목 태그 존재 및 내용 유효성</td> </tr> <tr> <td>og:description</td> <td>Open Graph 설명 태그 존재 및 내용 유효성</td> </tr> <tr> <td>og:image</td> <td>Open Graph 이미지 태그 존재 및 접근 가능성</td> </tr> <tr> <td>og:url</td> <td>Open Graph URL과 canonical 일치 여부</td> </tr> <tr> <td>JSON-LD</td> <td>구조화데이터 존재 여부, 사용된 schema.org 타입</td> </tr> <tr> <td>canonical</td> <td>canonical 태그 존재 및 유효성</td> </tr> <tr> <td>robots.txt</td> <td>존재 여부, User-agent/Disallow 파싱, Sitemap 명시 여부</td> </tr> <tr> <td>sitemap.xml</td> <td>존재 여부, URL 수, lastmod 유효성</td> </tr> </tbody></table> 이 14개 항목 중 어떤 것은 '있다/없다'로 단순하게 판정되지만, 어떤 것은 내용의 품질까지 봐야 한다. 예를 들어 title이 있어도 30자 미만이면 너무 짧을 수 있고, og:image가 있어도 해당 URL이 404를 반환하면 아무 의미가 없다. ViewCheck의 다중 페이지 분석 원칙에 따라, 이 항목들은 사이트의 여러 페이지에 걸쳐 수집된다. 그리고 결과는 두 가지 방식으로 집계된다. 하나는 사이트 전체의 커버리지(예: "140개 크롤링 페이지 중 OG 태그가 있는 페이지 비율"), 다른 하나는 개별 페이지별 상세 현황이다. 전자는 사이트 전반의 SEO 건강도를 보는 데, 후자는 어떤 페이지부터 고쳐야 하는지를 잡는 데 쓴다. <figure><img src="https://xbbhievqdmccsexxrdtn.supabase.co/storage/v1/object/sign/covers/content/wrou1pxk-584424.jpg?token=eyJraWQiOiJzdG9yYWdlLXVybC1zaWduaW5nLWtleV8yOWQwYWZmNy1mOWJhLTRkNmUtYmZlZi0yMzg2NTc0ZWUzODQiLCJhbGciOiJIUzI1NiJ9.eyJ1cmwiOiJjb3ZlcnMvY29udGVudC93cm91MXB4ay01ODQ0MjQuanBnIiwic2NvcGUiOiJkb3dubG9hZCIsImlhdCI6MTc4NDUwNjIyNiwiZXhwIjoyMDk5ODY2MjI2fQ.uKI1-lHHhtePEEyzMeLui71IHb-54L4nLoOZD2IvRB4" alt="ViewCheck LLM 분석에서 공공 사이트의 SEO 상세 진단 결과가 항목별로 표시된 실제 프로덕션 화면 캡처." loading="lazy" /><figcaption>ViewCheck LLM 분석의 SEO 상세 화면. 메타태그·OG 태그·구조화데이터·헤딩 계층 등 14종 항목이 페이지별로 정리되어 보인다. — 실제 분석 화면</figcaption></figure><hr> <h2 id="h-10">다중 페이지 SEO의 의미 — 메인만 보면 보이지 않는 것들</h2> SEO 진단에서 '다중 페이지'를 기본으로 하는 게 왜 중요한지를 조금 더 구체적으로 이야기해보자. 단일 페이지(메인 페이지) SEO 진단의 한계는 명확하다. 메인 페이지는 대개 가장 공들여 만들어진 페이지다. title도 있고, description도 있고, OG 태그도 있을 가능성이 높다. 그런데 실제로 시민이 검색해서 찾아야 하는 정보는 하위 페이지에 있다. 보도자료, 사업 공지, FAQ, 신청 안내 페이지 같은 것들이다. 우리가 여러 공공 사이트를 분석하면서 반복적으로 확인한 패턴이 있다. 메인 페이지의 SEO 요소는 어느 정도 갖춰져 있는데, 하위 페이지로 들어갈수록 상황이 달라진다. 예를 들어 공지사항 목록 페이지(예: <code>/notice/list</code>)는 페이지마다 title이 바뀌어야 하지 않나 싶지만, 실제로는 "공지사항 — ○○기관"으로 고정된 경우가 많다. 1페이지든 10페이지든 같은 title이다. 검색엔진 입장에서는 같은 이름의 페이지가 수십 개 있는 것처럼 보인다. 개별 공지 상세 페이지(예: <code>/notice/view/12345</code>)는 각 공지의 제목이 title에 반영되면 좋은데, 그냥 "공지사항 상세 — ○○기관"이 고정으로 박혀 있는 경우도 흔하다. 그 공지의 내용이 아무리 중요해도, 검색엔진이 그 페이지를 '공지사항 상세'라는 이름의 수천 개 중 하나로만 인식한다. 사업 신청 안내 페이지는 내용이 중요한 만큼 SEO도 중요한데, 같은 내용이 여러 URL에서 접근 가능하거나(카테고리 경로가 달라지는 경우), canonical이 없거나, 구조화데이터가 없는 경우가 대부분이다. ViewCheck의 다중 페이지 분석은 이런 패턴을 사이트 전체 수준에서 볼 수 있게 해준다. "이 사이트에서 title이 중복된 페이지가 몇 %인가", "OG 태그가 없는 페이지 유형은 주로 어떤 유형인가", "구조화데이터가 한 페이지에도 없는가, 아니면 특정 유형 페이지에만 없는가" 같은 질문에 답할 수 있게 된다. 이게 '다음에 무엇을 고쳐야 하는가'의 우선순위를 잡는 데 핵심이다. <hr> <h2 id="h-11">공공웹 SEO의 특수성 — 민간 SEO와 다른 것들</h2> 여기서 한 번 멈추고 생각해야 할 것이 있다. 공공 웹의 SEO는 민간 웹사이트의 SEO와 목표가 다르다. 그 차이를 무시하고 민간 SEO 기법을 그대로 적용하면 미스핏이 생긴다. 민간 SEO의 핵심 목표는 대개 트래픽 증가와 전환율 향상이다. 더 많은 사람이 방문해서 물건을 사거나 서비스에 가입하게 만드는 것. 키워드 경쟁, 백링크 확보, 콘텐츠 마케팅 등이 주요 전술이다. 공공 웹의 SEO 목표는 다르다. 공식 정보에 대한 접근성 보장이 핵심이다. 시민이 필요한 정보를 검색했을 때 공식 출처 페이지를 쉽게 찾을 수 있어야 한다. 트래픽 수를 극대화하는 게 아니라, '이 정보가 필요한 사람이 이 페이지를 찾을 수 있는가'가 기준이다. 이 차이에서 오는 몇 가지 실용적 함의가 있다. 키워드 전략: 민간은 검색량이 많은 '경쟁 키워드'를 노리지만, 공공은 서비스와 직결된 '정확한 행정 키워드'를 사용해야 한다. "청년 전월세 지원금 신청" 같은 구체적 키워드가 메타 태그와 제목에 자연스럽게 담겨야 한다. 콘텐츠 중복: 민간에서는 중복 콘텐츠를 피하는 것이 SEO에 중요하다. 공공에서는 동일한 정보가 여러 부처, 여러 기관에서 각자의 웹사이트에 올라오는 경우가 많다. 이때 출처 명시와 canonical 관리가 더 중요해진다. 권위(Authority): 공공기관은 본래 높은 도메인 권위를 가질 수 있다. .go.kr 도메인은 정부기관임을 나타내는 신뢰 신호다. Google의 E-E-A-T(Experience, Expertise, Authoritativeness, Trustworthiness) 기준에서 공공기관은 특정 주제(행정, 복지, 법령 등)에서 권위 있는 출처다. 이 권위를 제대로 활용하려면, 구조화데이터와 메타 태그가 제대로 갖춰져야 한다. 대량의 정형화된 콘텐츠: 공공 사이트에는 공지사항, 보도자료, 법령, 고시 같은 정형화된 대량의 콘텐츠가 있다. 이런 경우에는 동적으로 생성되는 페이지들에 SEO 요소(title, description, 구조화데이터)를 CMS 차원에서 자동 생성하는 전략이 필요하다. 담당자가 수동으로 5천 개 공지의 meta description을 작성하는 건 현실적으로 불가능하다. ViewCheck의 SEO 진단은 이런 공공 웹의 특성을 고려해서 설계됐다. 단순히 "이 기술적 항목이 있는가 없는가"를 넘어서, "이 사이트의 콘텐츠 유형과 규모를 고려할 때 개선 방향이 무엇인가"까지 제시하려고 한다. 아직 완전히 만족스러운 수준은 아니고, 더 발전시켜야 할 부분이 많다. <hr> <h2 id="h-12">SEO 진단과 KRDS 846규칙의 관계</h2> ViewCheck의 SEO 진단은 KRDS 846규칙 판정과 어떻게 관계하는지도 짚을 필요가 있다. KRDS(KoRea Design System)는 기본적으로 UI/UX 디자인 시스템이다. 색상, 타이포그래피, 컴포넌트, 패턴 같은 시각적·구조적 설계 기준을 담고 있다. SEO 자체가 KRDS의 핵심 영역은 아니다. 그렇다면 ViewCheck가 SEO를 진단하는 근거는 무엇인가. 행안부 「전자정부 웹사이트 품질관리 지침」 7대 품질 영역 중 개방성이 그 근거다. 개방성은 "정보의 공개와 공유를 위한 기반"으로, robots.txt, 메타데이터, 크롤링 허용 등을 포함한다. SEO의 기초 요소들이 개방성 영역에 직접 포함되는 것이다. KRDS 846규칙 중에는 SEO와 직접 관련된 카테고리가 있다. 예를 들어 메타 태그 구조, 헤딩 구조, canonical URL 같은 요소들은 HTML 구조 차원에서 접근성(CP 규칙)과도 겹치는 부분이 있다. 접근성 기준에서 "페이지 제목이 명확해야 한다(WCAG 2.4.2)"는 요건은 SEO의 "title 태그가 각 페이지를 명확히 설명해야 한다"는 요건과 본질적으로 같은 방향을 가리킨다. 구조화데이터(JSON-LD)는 KRDS 846규칙의 직접 판정 항목은 아니다. 그러나 ViewCheck의 24기능 중 SEO 카드가 이 구조화데이터를 포함해서 SEO 관련 항목 전체를 다루고, 이 SEO 카드가 7대 품질 중 개방성 영역의 점수에 기여한다. 즉, KRDS 846규칙 판정이 KRDS 디자인 준수를 확인한다면, SEO 진단은 그와 상호보완적으로 공공 웹의 '정보 개방성'을 확인하는 역할을 한다. 두 축이 합쳐져서 공공 웹의 품질을 더 입체적으로 파악할 수 있게 된다. <figure><img src="https://xbbhievqdmccsexxrdtn.supabase.co/storage/v1/object/sign/covers/content/vlck1985-104257.jpg?token=eyJraWQiOiJzdG9yYWdlLXVybC1zaWduaW5nLWtleV8yOWQwYWZmNy1mOWJhLTRkNmUtYmZlZi0yMzg2NTc0ZWUzODQiLCJhbGciOiJIUzI1NiJ9.eyJ1cmwiOiJjb3ZlcnMvY29udGVudC92bGNrMTk4NS0xMDQyNTcuanBnIiwic2NvcGUiOiJkb3dubG9hZCIsImlhdCI6MTc4NDUwNjIyNSwiZXhwIjoyMDk5ODY2MjI1fQ.-UfO9YY3v3gNxO5LqNSwShbK7RuRQuhF05bw-WSM-8E" alt="노트북으로 메타 정보 체크리스트를 검토하는 한국인 콘텐츠 매니저의 모습." loading="lazy" /><figcaption>SEO 점검은 KRDS 준수 판정과 별개가 아니다 — 공공 웹 품질의 두 축이 함께 맞물린다.</figcaption></figure><hr> <h2 id="h-13">진단의 어려운 점 — 우리가 아직 풀지 못한 것들</h2> 지금까지 ViewCheck가 SEO를 어떻게 진단하는지를 설명했는데, 솔직하게 "이건 아직 어렵다"는 부분도 적어두고 싶다. 동적 생성 콘텐츠의 meta 판정: 많은 공공 사이트가 JavaScript로 콘텐츠를 동적으로 생성한다. 특히 React나 Vue 같은 프레임워크를 쓰는 경우, 서버에서 HTML을 내려주는 시점에는 meta 태그가 비어 있고, JavaScript가 실행된 후에야 채워진다. Playwright 기반 크롤링은 실제 브라우저를 띄우기 때문에 이 경우도 대응할 수 있지만, 자바스크립트 실행 타이밍이나 SSR/CSR 방식에 따라 수집 결과가 달라질 수 있다. meta description 품질 판정: description이 '있다'는 건 자동으로 확인할 수 있다. 그런데 "이 description이 페이지 내용을 잘 요약하고 있는가"라는 품질 판단은 다르다. 단순히 길이만 보거나, 특정 키워드 존재 여부만 보는 것은 한계가 있다. 내용의 적절성을 AI로 평가하는 방향도 연구하고 있지만, 이게 정확한 판정인지는 아직 불확실하다. 대형 사이트의 페이지 커버리지: 콘텐츠 수천~수만 개를 가진 대형 공공 포털을 분석할 때, 모든 페이지를 크롤링하는 건 시간과 자원 면에서 한계가 있다. 어떤 페이지를 샘플링해서 보느냐에 따라 결과가 달라질 수 있다. 다양한 페이지 유형을 골고루 수집하는 샘플링 전략이 필요하고, 이 부분은 계속 개선하고 있다. OG 이미지의 적절성: og:image가 있고 해당 URL이 접근 가능하다는 건 확인할 수 있다. 그런데 그 이미지가 "소셜 공유 시 눈에 띄고 클릭을 유도하는" 이미지인지, 아니면 300×200 픽셀짜리 흐릿한 로고인지는 다르다. 이미지의 품질과 적절성을 자동으로 판정하는 건 여전히 어려운 문제다. JSON-LD 내용의 정확성: 구조화데이터가 있는지, 어떤 타입인지는 파악할 수 있다. 그런데 그 안의 속성 값들이 실제 페이지 내용과 일치하는지는 더 깊이 들여다봐야 한다. name, url, logo 같은 필드들이 실제로 유효한지, 오래된 정보가 아닌지 같은 것들이다. 이 부분은 앞으로 더 정교화할 계획이다. 이 한계들을 솔직하게 적는 이유는, "ViewCheck가 SEO 진단을 완벽하게 한다"는 인상을 주고 싶지 않기 때문이다. 우리는 공공 웹의 SEO 기초 요소들을 체계적으로 수집하고 정리해서, 담당자가 어디부터 봐야 할지를 빠르게 파악하도록 돕는 것을 목표로 한다. 그 목표는 어느 정도 달성하고 있지만, 판정의 깊이와 정확도는 계속 더 나아가야 할 여정이다. <hr> <h2 id="h-14">실제 분석에서 자주 보이는 패턴 — 유형별 공통 문제</h2> ViewCheck로 여러 공공 사이트를 분석하면서 반복적으로 보이는 패턴들을 유형별로 정리해본다. 물론 이건 우리가 분석한 사례에서 관찰한 것이며, 모든 공공 사이트가 이렇다고 일반화할 수는 없다. 광역지자체 대형 포털 유형 보통 메인 페이지는 비교적 잘 관리되어 있다. title, description, OG 태그 다 있다. 그런데 포털 하위에 여러 부서별 미니 사이트가 붙어 있는 구조에서, 각 미니 사이트의 SEO 관리 수준이 들쭉날쭉하다. 어떤 부서 사이트는 잘 되어 있고, 어떤 부서 사이트는 title이 "○○시청 - 홈" 하나로 고정이다. 조직 구조가 사이트 SEO 편차로 그대로 드러나는 경우다. 중소 기초지자체 유형 외주 개발로 만들어진 사이트가 많고, 개발 당시의 기본 SEO 설정이 그대로 유지되거나 방치되어 있다. robots.txt가 없거나, 기본 템플릿의 robots.txt가 그대로인 경우가 많다. sitemap도 없거나 오래된 URL만 담겨 있다. 구조화데이터는 거의 없다. 공공기관 전문 포털 유형 특정 분야(교육, 의료, 복지 등)의 전문 포털은 콘텐츠 수가 방대하다. 이 경우 개별 콘텐츠 페이지의 SEO 요소가 CMS에서 자동 생성되는 구조이면 비교적 일관되게 관리되고 있지만, CMS가 오래되었거나 SEO를 고려하지 않고 만들어진 경우에는 수천 개 페이지 모두 같은 title, 같은 description이다. 정부 전문 사이트 유형 법령, 고시, 통계 같은 데이터가 주인 사이트들은 URL 구조가 복잡하고, 같은 콘텐츠가 여러 URL로 접근 가능한 경우가 많다. canonical 관리가 특히 중요하지만, 대부분 canonical 태그가 없거나 체계적으로 관리되지 않는다. 구조화데이터 측면에서는 Dataset 타입을 활용하면 Google Datasets 검색에 노출될 수 있는 잠재력이 있는데, 활용되는 경우가 거의 없다. 이 패턴들이 특별히 새롭거나 충격적인 발견은 아니다. SEO 전문가라면 "공공 사이트가 그 정도지"라고 할 수도 있다. 우리가 이 관찰에서 갖게 된 물음은 다른 것이다. "이 상태를 체계적으로 파악하고, 우선순위를 잡고, 개선 방향을 제시하는 과정을 어떻게 단순하게 만들 수 있는가." <hr> <h2 id="h-15">검색엔진과 소셜의 교차점 — 통합 시각의 중요성</h2> 메타 태그, OG 태그, JSON-LD, 헤딩 구조, canonical, robots.txt, sitemap. 이 요소들을 각각 따로 떼어 보면 기술적 체크리스트처럼 보인다. 그런데 이들이 실제로 어떻게 맞물려 작동하는지를 보면, 하나가 빠졌을 때 나머지에 미치는 영향을 알게 된다. 예를 들어 JSON-LD를 제대로 삽입했는데 robots.txt로 해당 페이지 크롤링이 차단되어 있다면, Googlebot이 그 JSON-LD를 읽지 못하고 구조화데이터 효과가 없다. sitemap에 올라간 URL이 canonical과 다르다면, sitemap이 있어도 색인이 분산된다. og:url과 canonical이 다르면, 소셜에서 공유된 페이지가 검색엔진의 canonical 페이지와 달라진다. 이 상호작용을 제대로 파악하려면 요소들을 개별로 보는 것이 아니라, 통합적으로 봐야 한다. ViewCheck의 SEO 진단이 단일 항목 체크리스트가 아니라, 여러 요소의 상태를 함께 수집해서 교차 확인하는 방향으로 설계된 이유가 여기에 있다. 예를 들어 robots.txt에서 Disallow된 경로가 sitemap에도 포함되어 있다면, 그건 설정 충돌이다. 검색엔진에게 "오지 마라"고 하면서 동시에 "이 URL 있다"고 알려주는 모순이다. 이런 충돌을 잡아내려면 robots.txt와 sitemap.xml을 함께 분석해야 한다. 또는 OG 태그가 잘 설정되어 있는데 og:image의 URL이 robots.txt에서 차단된 경로에 있다면, 소셜 미디어 봇이 그 이미지를 가져가지 못한다. 이미지 미리보기가 안 뜨는 것이다. 이런 교차 확인이 "기초는 다 있는데 왜 안 되지?"라는 상황의 원인을 찾는 데 도움이 된다. 우리가 ViewCheck의 SEO 진단에서 이 교차 확인을 얼마나 잘 구현하고 있는지는, 솔직히 아직 개선할 여지가 있다. 각 항목은 잘 잡히는데, 항목 간 상호관계를 자동으로 진단하는 부분은 더 발전시켜야 하는 영역이다. <hr> <h2 id="h-16">SEO 진단 결과를 어떻게 쓸 것인가 — 담당자 시각</h2> 기술적인 이야기를 많이 했는데, 마지막에는 "이 진단 결과를 받아 든 담당자가 실제로 무엇을 해야 하는가"로 돌아가고 싶다. SEO 진단 결과를 받았다고 해서 즉시 수천 개 페이지의 meta description을 다 고칠 수는 없다. 현실적인 접근이 필요하다. 첫 번째 우선순위: 기술적 차단 요소 제거 robots.txt 설정 오류, sitemap 부재, canonical 충돌처럼 검색엔진이 사이트를 제대로 인식하지 못하게 막는 요소를 먼저 제거해야 한다. 이건 CMS나 서버 설정을 바꾸는 일이라 개발팀 협조가 필요하지만, 한 번 고치면 사이트 전체에 영향을 미친다. 두 번째 우선순위: 핵심 페이지의 SEO 요소 확보 메인 페이지, 주요 서비스 안내 페이지, 검색량이 많을 것으로 예상되는 핵심 콘텐츠 페이지에 title, description, OG 태그를 제대로 갖추는 것이다. 전체 사이트를 한 번에 다 고치는 건 어렵지만, 핵심 페이지부터 챙기면 효과가 빠르다. 세 번째 우선순위: CMS 차원의 자동화 수백~수천 개 이상의 페이지가 있는 사이트라면, 개별 페이지마다 SEO 요소를 수동으로 관리하는 건 불가능하다. CMS나 템플릿 차원에서 "공지사항 상세 페이지의 title은 '공지 제목 — 사이트명' 형식으로 자동 생성"하는 방식을 개발 단계에서 설정해 두어야 한다. 이미 운영 중인 사이트라면 재개발 없이 적용하기 어려운 경우도 있는데, 이건 확인이 필요한 부분이다. 네 번째 우선순위: 구조화데이터 단계적 도입 JSON-LD는 기존 HTML을 건드리지 않고 <code><script></code> 블록을 추가하는 방식이라 비교적 도입이 쉬운 편이다. 사이트 전체를 한 번에 하기보다, Organization 타입부터 시작해서 주요 콘텐츠 유형(FAQPage, Event, NewsArticle)을 순서대로 추가하는 단계적 접근이 현실적이다. ViewCheck의 SEO 진단 결과는 이 우선순위 설정을 돕는 방식으로 제공된다. 어떤 항목이 빠져 있는지뿐 아니라, 어떤 유형의 페이지에서 어떤 문제가 얼마나 광범위하게 나타나는지를 함께 보여줘서, "어디부터 손댈 것인가"를 잡을 수 있게 한다. 물론 그 다음 실제 수정 작업은 담당자와 개발팀의 몫이다. 우리가 할 수 있는 건 "어디를 봐야 하는지"를 빠르고 체계적으로 짚어주는 것까지다. <figure><img src="https://xbbhievqdmccsexxrdtn.supabase.co/storage/v1/object/sign/covers/content/8gbl7iq8-113232.jpg?token=eyJraWQiOiJzdG9yYWdlLXVybC1zaWduaW5nLWtleV8yOWQwYWZmNy1mOWJhLTRkNmUtYmZlZi0yMzg2NTc0ZWUzODQiLCJhbGciOiJIUzI1NiJ9.eyJ1cmwiOiJjb3ZlcnMvY29udGVudC84Z2JsN2lxOC0xMTMyMzIuanBnIiwic2NvcGUiOiJkb3dubG9hZCIsImlhdCI6MTc4NDUwNjIyNiwiZXhwIjoyMDk5ODY2MjI2fQ.cm5ldDaAfIVDS1Gn-T9nSDeX9eVL2sUyzVGIcEneNoY" alt="책상에서 동료와 함께 검색 노출 전략에 대해 이야기하는 한국인 마케터의 모습." loading="lazy" /><figcaption>진단 결과를 받은 다음이 시작이다 — 우선순위를 잡고, 팀과 논의하고, 한 걸음씩.</figcaption></figure><hr> <h2 id="h-17">공공웹 SEO와 접근성의 겹치는 지점</h2> SEO와 접근성(Accessibility)은 겉으로는 다른 것처럼 보이지만, 기술적 기반에서 많이 겹친다. 이 겹침이 공공 웹에서 특히 중요하다. WCAG(Web Content Accessibility Guidelines) 2.4.2는 "웹 페이지는 주제나 목적을 설명하는 제목을 가져야 한다"고 요구한다. 이건 SEO에서 title 태그를 각 페이지 내용에 맞게 고유하게 작성해야 한다는 요건과 정확히 겹친다. 접근성을 위해 title을 잘 쓰면 SEO에도 좋고, SEO를 위해 title을 잘 쓰면 접근성에도 좋다. 헤딩 구조도 마찬가지다. WCAG 1.3.1은 "정보, 구조, 관계가 시각적 표현 이외에 프로그래밍 방식으로도 확인 가능하거나 텍스트로 제공되어야 한다"고 하는데, 올바른 헤딩 계층이 이 기준을 충족하는 핵심 방법이다. 스크린 리더 사용자를 위한 논리적 헤딩 구조는 검색엔진의 콘텐츠 이해도 돕는다. lang 속성도 그렇다. KWCAG 2.2에서 요구하는 언어 선언은 스크린 리더가 올바른 언어로 읽기 위해 필요한 것이고, 동시에 검색엔진이 페이지 언어를 인식해 적절한 국가·언어권 사용자에게 노출하는 데도 쓰인다. 이 겹침은 "SEO와 접근성을 따로 챙겨야 하는 두 가지 과제"가 아니라, "기초를 제대로 갖추면 두 가지가 동시에 개선되는" 효율적인 접근이 가능함을 의미한다. 실제로 ViewCheck의 KRDS 846규칙 판정(접근성 관련 CP 규칙 포함)과 SEO 진단은 서로 보완하며, 중복되는 기초 요소들을 함께 본다. 공공 웹의 품질 관리 담당자가 KRDS 준수와 SEO를 "두 개의 별개 프로젝트"로 접근하면 자원이 두 배로 든다. "기초 HTML 구조를 제대로 갖추면 KRDS 접근성과 SEO가 동시에 개선된다"는 시각으로 접근하면 더 효율적이다. ViewCheck가 846규칙 판정과 SEO 진단을 같은 분석 흐름 안에서 통합적으로 제공하는 이유가 이것이다. <hr> <h2 id="h-18">Twitter Card와 추가 메타데이터</h2> Open Graph 태그가 페이스북, 카카오 계열에서 주로 쓰인다면, Twitter Card 태그는 X(구 트위터)에서 링크 미리보기를 제어한다. 기본 형식은 이렇다. <pre><code class="language-html"><meta name="twitter:card" content="summary_large_image" /> <meta name="twitter:title" content="페이지 제목" /> <meta name="twitter:description" content="요약 설명" /> <meta name="twitter:image" content="https://example.go.kr/images/thumb.jpg" /> </code></pre> Twitter Card가 없으면 X에서 링크를 공유했을 때 미리보기가 제대로 뜨지 않는다. 대신 OG 태그가 있으면 X가 이를 fallback으로 활용하기도 하지만, 완전하지 않을 수 있다. 공공 사이트에서 Twitter Card 태그는 OG 태그보다도 누락 비율이 높다. 실제로 카카오나 네이버 중심인 국내 소통 채널을 생각하면 OG 태그의 우선순위가 높지만, X를 공식 채널로 운영하는 기관에서는 Twitter Card 태그도 필요하다. ViewCheck SEO 진단에서 Twitter Card 태그는 OG 태그와 함께 수집하고 점검한다. 두 태그가 모두 있는 경우, 없는 경우, OG만 있고 Twitter Card는 없는 경우를 구분해서 보여준다. 또 한 가지 언급할 만한 것이 hreflang 태그다. 이중 언어 사이트(예: 외국인 대상 서비스 안내를 영어로도 제공하는 경우)에서, 어떤 언어 버전이 어떤 언어 사용자에게 표시되어야 하는지를 알려주는 태그다. 국제화를 고려한 공공 사이트에서 필요한 요소인데, 이 부분은 ViewCheck가 현재 검토하고 있는 확장 영역 중 하나다. 아직 완전히 구현된 건 아니고, 다국어 공공 사이트가 늘어남에 따라 중요도가 높아질 것으로 보인다. <hr> <h2 id="h-19">검색엔진 색인 확인 — 분석 이후의 후속 단계</h2> SEO 진단을 해서 문제점을 파악하고 개선했다면, 그 다음은 "개선이 실제로 반영됐는가"를 확인하는 단계다. 가장 직접적인 방법은 Google Search Console이나 네이버 서치어드바이저를 활용하는 것이다. 이 도구들은 검색엔진이 실제로 사이트의 어떤 URL을 색인하고 있는지, 어떤 키워드로 노출되는지, 클릭률은 어떤지를 보여준다. sitemap.xml을 제출하면 더 빠르고 체계적인 색인이 이뤄진다. 특히 새로운 콘텐츠가 자주 올라오는 사이트에서는 sitemap을 최신 상태로 유지하고 주기적으로 재제출하는 것이 중요하다. ViewCheck는 현재 Google Search Console이나 네이버 서치어드바이저와 직접 연동하지는 않는다. 실제 색인 상태나 키워드 성과 데이터는 이 도구들에서 직접 확인해야 한다. ViewCheck의 SEO 진단은 "페이지에 SEO 요소가 제대로 갖춰져 있는가"를 확인하는 쪽이고, "그 결과로 검색 순위가 어떻게 되는가"는 서치 콘솔 같은 별도 도구가 담당하는 영역이다. 이건 의도적인 역할 분리다. ViewCheck는 페이지 자체의 기술적 기초를 확인하고, 서치 콘솔은 검색엔진과의 실제 상호작용 결과를 보여준다. 두 도구를 함께 쓰면 "문제가 어디에 있는가"와 "그게 검색 결과에 어떻게 영향 미쳤는가"를 모두 파악할 수 있다. <hr> <h2 id="h-20">앞으로의 방향 — SEO 진단 고도화 계획</h2> 솔직히 말하면, ViewCheck의 SEO 진단은 아직 계속 발전하는 중이다. 현재까지 구현된 것들과 앞으로 더 발전시키려는 방향을 간략히 정리해보자. 현재 구현된 것: <ul> <li>14종 SEO 항목 페이지별 수집 및 판정</li> <li>robots.txt 파싱(User-agent, Disallow, Sitemap 지시어)</li> <li>sitemap.xml 파싱(URL 수, lastmod 유효성)</li> <li>OG 태그 4종 + Twitter Card 수집</li> <li>JSON-LD 존재 여부 및 schema.org 타입 식별</li> <li>헤딩 H1~H6 구조 분석</li> <li>canonical 태그 수집 및 OG:url과의 일치 확인</li> <li>다중 페이지 전체 커버리지 집계</li> </ul> 개선 중인 것: <ul> <li>JSON-LD 내용 검증(필수 속성 누락 여부, Google Rich Result Test 기준)</li> <li>robots.txt와 sitemap의 교차 충돌 자동 탐지</li> <li>구조화데이터 타입별 권장 도입 순위 제안</li> <li>OG 이미지 크기·접근성 자동 확인</li> <li>다중 언어 사이트의 hreflang 분석</li> </ul> 장기적으로 탐색 중인 것: <ul> <li>meta description 내용 품질의 AI 평가</li> <li>경쟁 사이트(동급 공공기관) 대비 SEO 현황 벤치마킹</li> <li>Google Search Console API 연동을 통한 실제 색인·성과 데이터 통합</li> <li>키워드 수준의 노출 개선 시뮬레이션</li> </ul> 이 중 일부는 꽤 멀리 있는 목표다. 특히 외부 서치 콘솔 데이터와의 연동이나 키워드 벤치마킹은, 사용자 인증과 데이터 연동 설계가 복잡해서 단기간에 넣기 어렵다. 장기 로드맵으로 가지고 있을 뿐이다. 지금 집중하는 건 14종 항목 각각의 판정 정확도를 높이고, 판정 결과를 더 실용적인 방식으로 보여주는 것이다. "이 항목이 미통과"라고 말하는 것에서 나아가, "이 항목이 미통과인 이유가 이것이고, 이렇게 하면 개선된다"는 구체적 안내까지 줄 수 있는 방향으로. <hr> <h2 id="h-21">마무리 — 공공 정보의 발견 가능성을 높이는 작은 시작</h2> 공공 웹의 SEO는 화려하지 않다. 트래픽을 열 배 늘리거나, 키워드 1등을 찍거나, 바이럴 콘텐츠를 만드는 이야기가 아니다. 그보다 훨씬 기초적인 것들이다. title 태그를 각 페이지에 맞게 쓰기, description을 채우기, OG 태그를 달기, JSON-LD 하나 추가하기, robots.txt를 점검하기. 이 기초들이 갖춰지면 어떤 변화가 생기는지 확실하게 말하기는 어렵다. 검색 노출이 곧바로 드라마틱하게 좋아진다고 단언할 수 없다. 다만 우리가 확신하는 것은, 기초가 없으면 아무리 좋은 콘텐츠가 있어도 검색엔진이 그것을 제대로 이해하고 전달할 수 없다는 것이다. Google Search Central의 공식 문서에 실린 Nestlé 사례처럼, 구조화데이터 하나로 클릭률이 82% 오른 게 꼭 공공 사이트에서도 같은 수치로 재현된다고는 말 못한다. 하지만 "검색엔진에게 더 명확한 정보를 주면, 검색엔진이 더 잘 보여준다"는 원리는 공공이든 민간이든 다르지 않다. 공공 정보가 공식 채널을 통해 시민에게 잘 전달되는 것 — 이건 단순히 홈페이지 방문자 수의 문제가 아니라, 공공 서비스의 본질적인 책무와 연결된 문제라고 우리는 생각한다. 시민이 복지 서비스를 신청하고 싶은데 어디서 찾아야 할지 몰라 비공식 채널을 전전한다면, 그건 콘텐츠가 없어서가 아니라 '찾기 어렵게 만들어져 있어서'다. ViewCheck의 SEO 진단은 그 '찾기 어렵게 만드는' 기술적 원인을 파악하는 도구다. 아직 완성되지 않았고, 계속 발전 중이다. 하지만 방향은 분명하다 — 공공 정보가 더 잘 발견될 수 있게, 기초부터 체계적으로 점검하는 것. 다음 편에서는 이 시리즈의 또 다른 데이터 주제로 넘어간다. 함께 이어가자. <hr> <h2 id="h-22">참고문헌</h2> <blockquote> 본문에 인용한 출처는 작성 시점에 모두 실재 여부를 검증했다. 국내 공식 기준과 해외 공식 문서를 함께 실었다. </blockquote> 국내 — 공식 기준 / 정책자료 <ol> <li>행정안전부, 「전자정부 웹사이트 품질관리 지침」(행정안전부고시 제2025-46호, 2025.6.25. 일부개정). 국가법령정보센터. <a href="https://www.law.go.kr/%ED%96%89%EC%A0%95%EA%B7%9C%EC%B9%99/%EC%A0%84%EC%9E%90%EC%A0%95%EB%B6%80%EC%9B%B9%EC%82%AC%EC%9D%B4%ED%8A%B8%ED%92%88%EC%A7%88%EA%B4%80%EB%A6%AC%EC%A7%80%EC%B9%A8">https://www.law.go.kr/행정규칙/전자정부웹사이트품질관리지침</a> </li> <li>행정안전부, 「전자정부 웹사이트 품질관리 지침」 일부 개정 및 「전자정부 웹사이트 품질관리 가이드」 수정본 안내(고시 제2025-46호). 행정안전부 알립니다. <a href="https://www.mois.go.kr/frt/bbs/type013/commonSelectBoardArticle.do?bbsId=BBSMSTR_000000000006&nttId=118639">https://www.mois.go.kr/frt/bbs/type013/commonSelectBoardArticle.do?bbsId=BBSMSTR_000000000006&nttId=118639</a> </li> <li>KRDS(범정부 UI/UX 디자인시스템) 공식 사이트 — 디지털 정부서비스 UI/UX 가이드라인. 행정안전부·디지털플랫폼정부위원회. <a href="https://www.krds.go.kr/">https://www.krds.go.kr/</a> </li> <li>TBWA 데이터랩, "robots.txt 10분 안에 끝내는 총정리 가이드". robots.txt와 공공·기업 사이트의 실수 사례 포함. <a href="https://seo.tbwakorea.com/blog/robots-txt-complete-guide/">https://seo.tbwakorea.com/blog/robots-txt-complete-guide/</a> </li> <li>어센트 코리아, "Robots.txt와 Sitemap.xml 제대로 설정하기". <a href="https://www.ascentkorea.com/what-is-robots-txt-sitemap-xml/">https://www.ascentkorea.com/what-is-robots-txt-sitemap-xml/</a> </li> </ol> 해외 — 공식 표준 / 기술 문서 <ol start="6"> <li>Google Search Central, "SEO Starter Guide: The Basics". Google for Developers. <a href="https://developers.google.com/search/docs/fundamentals/seo-starter-guide">https://developers.google.com/search/docs/fundamentals/seo-starter-guide</a> </li> <li>Google Search Central, "Intro to How Structured Data Markup Works". Nestlé 82% CTR 사례 포함. Google for Developers. <a href="https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data">https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data</a> </li> <li>Google Search Central, "How to Write Meta Descriptions". Google for Developers. <a href="https://developers.google.com/search/docs/appearance/snippet">https://developers.google.com/search/docs/appearance/snippet</a> </li> <li>Google Search Central, "How to Specify a Canonical with rel='canonical' and Other Methods". Google for Developers. <a href="https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls">https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls</a> </li> <li>Google Search Central, "Create and Submit a robots.txt File". Google for Developers. <a href="https://developers.google.com/crawling/docs/robots-txt/create-robots-txt">https://developers.google.com/crawling/docs/robots-txt/create-robots-txt</a> </li> <li>The Open Graph protocol (ogp.me). Facebook 2010년 개발, 공식 사양. <a href="https://ogp.me/">https://ogp.me/</a> </li> <li>schema.org 공식. Google, Microsoft, Yahoo, Yandex 공동 운영 어휘 표준. 823개 타입·1,529개 속성. <a href="https://schema.org/">https://schema.org/</a> </li> <li>schema.org, Organization 타입 정의. <a href="https://schema.org/Organization">https://schema.org/Organization</a> </li> <li>W3C WAI, "Meta viewport allows for zoom" — viewport 메타 태그와 접근성 기준(WCAG 연계). <a href="https://www.w3.org/WAI/standards-guidelines/act/rules/b4f0c3/">https://www.w3.org/WAI/standards-guidelines/act/rules/b4f0c3/</a> </li> </ol> <hr> <figure><img src="https://xbbhievqdmccsexxrdtn.supabase.co/storage/v1/object/sign/covers/content/rhbo0glv-1187218.png?token=eyJraWQiOiJzdG9yYWdlLXVybC1zaWduaW5nLWtleV8yOWQwYWZmNy1mOWJhLTRkNmUtYmZlZi0yMzg2NTc0ZWUzODQiLCJhbGciOiJIUzI1NiJ9.eyJ1cmwiOiJjb3ZlcnMvY29udGVudC9yaGJvMGdsdi0xMTg3MjE4LnBuZyIsInNjb3BlIjoiZG93bmxvYWQiLCJpYXQiOjE3ODQ1MDYyMjcsImV4cCI6MjA5OTg2NjIyN30.Oi4npVfLaiKUEwS_w5f0kqqcSLpKNKhAJsdom4A8wmU" alt="" loading="lazy" /></figure></div><div class="mt-12 border-t border-border/60 pt-6 flex flex-wrap gap-2">#SEO#구조화데이터#OpenGraph#공공웹#KRDS#메타태그#JSONLD#헤딩구조</div></div><section class="mt-10"><h3 class="text-lg font-bold">관련 글</h3><div class="mt-4 grid gap-4 sm:grid-cols-2 lg:grid-cols-3"><a href="/posts/viewcheck-llm-%EB%B6%84%EC%84%9D-%EB%A6%AC%ED%8F%AC%ED%8A%B8-%EC%9D%BD%EB%8A%94-%EB%B2%95-%EC%A0%90%EC%88%98-%EB%93%B1%EA%B8%89-%EA%B7%BC%EA%B1%B0-%EC%9A%B0%EC%84%A0%EC%88%9C%EC%9C%84-%ED%95%B4%EC%84%9D%EC%97%90%EC%84%9C-%ED%96%89%EB%8F%99%EA%B9%8C%EC%A7%80" class="glass-card group block rounded-2xl p-5 transition hover:-translate-y-0.5 hover:shadow-[var(--shadow-glow)]">KRDS · 공공웹 AI 진단연구<h4 class="mt-3 text-sm font-bold leading-snug group-hover:text-gradient">ViewCheck LLM 분석 리포트 읽는 법 — 점수·등급·근거·우선순위 해석에서 행동까지</h4>분석이 끝나고 화면에 숫자가 떴다. 종합 74점. KRDS 846규칙 중 289개 통과, 228개 미통과, 329개 해당없음. 접근성 68점. 보안 91점. 위반 매트릭스에는 빨간 칸과 노란 칸이 뒤섞여 있다. 그런데 막상 이 결과를 받아 든 담당자의 표정이 묘하다. 뭔가 많이 나왔는데, 무엇을 먼저 봐야 할지 모르겠다.<div class="mt-3 flex items-center gap-2 text-[11px] text-muted-foreground">ViewCheck Insight·2026.07.20</div></a><a href="/posts/ai-%EC%A7%84%EB%8B%A8-%EC%96%B4%EB%94%94%EA%B9%8C%EC%A7%80-%EB%AF%BF%EC%96%B4%EC%95%BC-%ED%95%98%EB%82%98-viewcheck%EB%A5%BC-%ED%99%9C%EC%9A%A9%ED%95%98%EB%8A%94-%EC%82%AC%EB%9E%8C%EC%9D%84-%EC%9C%84%ED%95%9C-%EC%A0%95%EC%A7%81%ED%95%9C-%EA%B0%80%EC%9D%B4%EB%93%9C" class="glass-card group block rounded-2xl p-5 transition hover:-translate-y-0.5 hover:shadow-[var(--shadow-glow)]">KRDS · 공공웹 AI 진단연구<h4 class="mt-3 text-sm font-bold leading-snug group-hover:text-gradient">AI 진단, 어디까지 믿어야 하나 — ViewCheck를 활용하는 사람을 위한 정직한 가이드</h4>2026년 어느 날, 공공기관의 웹 담당자 한 명이 AI 분석 결과를 출력해 상사에게 내밀었다고 상상해 보자. "AI가 분석했더니 우리 사이트 KRDS 준수율이 68점입니다." 상사는 고개를 끄덕이며 "그럼 개선 계획 짜세요"라고 했다. 담당자는 돌아가 개발사에 수정 목록을 전달했다. 문제는, 그 68점이 무엇을 근거로 <div class="mt-3 flex items-center gap-2 text-[11px] text-muted-foreground">ViewCheck Insight·2026.07.20</div></a><a href="/posts/%EB%B6%84%EC%84%9D-%EA%B0%9C%EC%84%A0-%EC%9E%AC%EC%A7%84%EB%8B%A8-%EA%B3%B5%EA%B3%B5%EC%9B%B9-%ED%92%88%EC%A7%88%EC%9D%84-%EC%A0%90%EC%88%98%EB%A1%9C-%EA%B4%80%EB%A6%AC-%ED%95%9C%EB%8B%A4%EB%8A%94-%EA%B2%83-viewcheck-llm-%EB%B6%84%EC%84%9D-%ED%99%9C%EC%9A%A9" class="glass-card group block rounded-2xl p-5 transition hover:-translate-y-0.5 hover:shadow-[var(--shadow-glow)]">KRDS · 공공웹 AI 진단연구<h4 class="mt-3 text-sm font-bold leading-snug group-hover:text-gradient">분석 → 개선 → 재진단, 공공웹 품질을 '점수로 관리'한다는 것 — ViewCheck LLM 분석 활용</h4>공공 웹사이트 품질 진단을 맡은 실무 담당자들과 이야기하다 보면, 어느 지점에서 공통된 표정이 나온다. "진단은 했어요. 그런데 그다음은 어떻게 해야 하죠?" 도구를 돌리면 문제 목록이 나온다. 때로는 수백 개, 때로는 수십 페이지짜리 보고서가 나온다. 그리고 거기서 멈춘다. 문제를 고쳤는지 어떻게 확인하지? 개선 후에 <div class="mt-3 flex items-center gap-2 text-[11px] text-muted-foreground">ViewCheck Insight·2026.07.20</div></a></div></section></article><aside class="lg:order-last"><div class="lg:sticky lg:top-24"><div class="glass-card rounded-2xl p-5"><header class="mb-4 flex items-center gap-2"><svg xmlns="http://www.w3.org/2000/svg" width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" class="lucide lucide-list h-4 w-4" aria-hidden="true"><path d="M3 5h.01"></path><path d="M3 12h.01"></path><path d="M3 19h.01"></path><path d="M8 5h13"></path><path d="M8 12h13"></path><path d="M8 19h13"></path></svg><h3 class="text-sm font-bold">목차</h3></header><nav><ul class="space-y-2 text-[13px]"><li><a href="#h-0" class="group flex gap-2 text-muted-foreground hover:text-foreground">01검색창에 '기관명'을 치면 무엇이 보이는가, 우리가 SEO 진단을 시작한 이유</a></li><li><a href="#h-1" class="group flex gap-2 text-muted-foreground hover:text-foreground">02들어가며 — "검색하면 나오지 않나요?"라는 가장 쉬운 질문</a></li><li><a href="#h-2" class="group flex gap-2 text-muted-foreground hover:text-foreground">03SEO가 공공웹에서 왜 중요한가 — 시민의 검색 여정 이야기</a></li><li><a href="#h-3" class="group flex gap-2 text-muted-foreground hover:text-foreground">04메타 태그의 기초 — title, description, viewport, lang</a></li><li><a href="#h-4" class="group flex gap-2 text-muted-foreground hover:text-foreground">05Open Graph 태그 — SNS에서 공공 정보가 어떻게 보이는가</a></li><li><a href="#h-5" class="group flex gap-2 text-muted-foreground hover:text-foreground">06구조화데이터(JSON-LD) — 검색엔진이 '이해하는' 정보</a></li><li><a href="#h-6" class="group flex gap-2 text-muted-foreground hover:text-foreground">07헤딩 계층 — H1에서 H6까지, 구조가 내용을 안내한다</a></li><li><a href="#h-7" class="group flex gap-2 text-muted-foreground hover:text-foreground">08canonical URL — 중복 페이지 문제와 정규화</a></li><li><a href="#h-8" class="group flex gap-2 text-muted-foreground hover:text-foreground">09robots.txt와 sitemap.xml — 개방성의 가장 기본 인프라</a></li><li><a href="#h-9" class="group flex gap-2 text-muted-foreground hover:text-foreground">10ViewCheck SEO 진단의 실제 — 14종 점검 항목과 다중 페이지 접근</a></li><li><a href="#h-10" class="group flex gap-2 text-muted-foreground hover:text-foreground">11다중 페이지 SEO의 의미 — 메인만 보면 보이지 않는 것들</a></li><li><a href="#h-11" class="group flex gap-2 text-muted-foreground hover:text-foreground">12공공웹 SEO의 특수성 — 민간 SEO와 다른 것들</a></li><li><a href="#h-12" class="group flex gap-2 text-muted-foreground hover:text-foreground">13SEO 진단과 KRDS 846규칙의 관계</a></li><li><a href="#h-13" class="group flex gap-2 text-muted-foreground hover:text-foreground">14진단의 어려운 점 — 우리가 아직 풀지 못한 것들</a></li><li><a href="#h-14" class="group flex gap-2 text-muted-foreground hover:text-foreground">15실제 분석에서 자주 보이는 패턴 — 유형별 공통 문제</a></li><li><a href="#h-15" class="group flex gap-2 text-muted-foreground hover:text-foreground">16검색엔진과 소셜의 교차점 — 통합 시각의 중요성</a></li><li><a href="#h-16" class="group flex gap-2 text-muted-foreground hover:text-foreground">17SEO 진단 결과를 어떻게 쓸 것인가 — 담당자 시각</a></li><li><a href="#h-17" class="group flex gap-2 text-muted-foreground hover:text-foreground">18공공웹 SEO와 접근성의 겹치는 지점</a></li><li><a href="#h-18" class="group flex gap-2 text-muted-foreground hover:text-foreground">19Twitter Card와 추가 메타데이터</a></li><li><a href="#h-19" class="group flex gap-2 text-muted-foreground hover:text-foreground">20검색엔진 색인 확인 — 분석 이후의 후속 단계</a></li><li><a href="#h-20" class="group flex gap-2 text-muted-foreground hover:text-foreground">21앞으로의 방향 — SEO 진단 고도화 계획</a></li><li><a href="#h-21" class="group flex gap-2 text-muted-foreground hover:text-foreground">22마무리 — 공공 정보의 발견 가능성을 높이는 작은 시작</a></li><li><a href="#h-22" class="group flex gap-2 text-muted-foreground hover:text-foreground">23참고문헌</a></li></ul></nav></div></div></aside></div></div><footer class="mt-16 border-t border-border/60 bg-background/60"><div class="mx-auto max-w-[1400px] px-4 py-10 lg:px-8"><div class="flex flex-col items-start justify-between gap-6 md:flex-row md:items-center"><div><div class="flex items-center gap-2"><img src="/assets/neuroflow-logo-DNMszRUo.png" alt="뉴로플로우" class="h-6 w-auto shrink-0" width="309" height="242"/><div class="text-sm font-bold">ViewCheck Insight</div></div>© 2026 ViewCheck. Premium research on Korean digital government.</div><div class="flex flex-wrap gap-6 text-[12px] text-muted-foreground"><a href="/about" class="hover:text-foreground">소개</a><a href="/advertise" class="hover:text-foreground">광고 문의</a><a href="/contact" class="hover:text-foreground">기술제휴</a><a href="/privacy" class="hover:text-foreground">개인정보처리방침</a><a href="/manage" class="hover:text-foreground">관리</a></div></div></div></footer></div><script>(function(a,f){let l;try{l=JSON.parse(sessionStorage.getItem(a)||"{}")}catch{return}const n=l?.[f||history.state?.__TSR_key];let c=!1;for(const t in n){const e=n[t],o=e?.scrollX,s=e?.scrollY;if(Number.isFinite(o)&&Number.isFinite(s)){if(t==="window")scrollTo(o,s),c=!0;else if(t)try{const r=document.querySelector(t);r&&(r.scrollLeft=o,r.scrollTop=s)}catch{}}}if(c)return;const i=location.hash.slice(1);if(i){const t=history.state?.__hashScrollIntoViewOptions??!0;if(t){const e=document.getElementById(i);e&&e.scrollIntoView(t)}return}scrollTo(0,0)})("tsr-scroll-restoration-v1_3");document.currentScript.remove()</script></div><script class="$tsr" id="$tsr-stream-barrier">(self.$R=self.$R||{})["tsr"]=[];self.$_TSR={h(){this.hydrated=!0,this.c()},e(){this.streamEnded=!0,this.c()},c(){this.hydrated&&this.streamEnded&&(delete self.$_TSR,delete self.$R.tsr)},p(e){this.initialized?e():this.buffer.push(e)},buffer:[]};$_TSR.router=($R=>$R[0]={manifest:$R[1]={routes:$R[2]={__root__:$R[3]={preloads:$R[4]=["/assets/index-C1m3Lvel.js","/assets/jsx-runtime-DJLGwldU.js","/assets/useStore-PjCMavjJ.js","/assets/link-COsi0Rbg.js","/assets/matchContext-D0ckMBGh.js","/assets/useRouter-Dogm4UJo.js","/assets/redirect-Coy-z-9D.js","/assets/root-DLTE-HSj.js","/assets/createServerFn-CIeolcgg.js","/assets/tslib.es6-Tae09705.js"],scripts:$R[5]=[$R[6]={attrs:$R[7]={type:"module",async:!0,src:"/assets/index-C1m3Lvel.js"}}]},"/posts/$postId":$R[8]={preloads:$R[9]=["/assets/posts._postId-D2JH8AxV.js","/assets/arrow-left-BvtkRfy6.js","/assets/bookmark-uOXzh24g.js","/assets/list-COk-KOof.js","/assets/site-header-DQzYbrSG.js","/assets/site-footer-DGjpVJrl.js","/assets/post-content-BGlD59hJ.js","/assets/posts._postId-D90q64H0.js","/assets/posts._postId-yaCbZ3Bt.js"]}}},matches:$R[10]=[$R[11]={i:"__root__�",u:1784708409788,s:"success",ssr:!0},$R[12]={i:"�posts�$postId�posts�%EA%B3%B5%EA%B3%B5%EC%9B%B9%EC%9D%80-%EA%B2%80%EC%83%89%EC%97%90-%EC%9E%A1%ED%9E%88%EA%B3%A0-%EC%9E%88%EB%82%98-viewcheck%EA%B0%80-%EB%A9%94%ED%83%80%ED%83%9C%EA%B7%B8-open-graph-%EA%B5%AC%EC%A1%B0%ED%99%94%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%A5%BC-%EC%A7%84%EB%8B%A8%ED%95%98%EB%8A%94-%EB%B0%A9%EB%B2%95",u:1784708410564,s:"success",l:$R[13]={post:$R[14]={id:"공공웹은-검색에-잡히고-있나-viewcheck가-메타태그-open-graph-구조화데이터를-진단하는-방법",uuid:"828fa554-7e24-4550-ac7e-5dbc3d2fc4d9",slug:"공공웹은-검색에-잡히고-있나-viewcheck가-메타태그-open-graph-구조화데이터를-진단하는-방법",cat:"KRDS · 공공웹 AI 진단연구",category:"ai-diagnostics",title:"공공웹은 검색에 잡히고 있나 — ViewCheck가 메타태그·Open Graph·구조화데이터를 진단하는 방법",excerpt:"\"검색하면 나오지 않나요?\"\n공공 웹사이트를 운영하는 담당자들에게 SEO 얘기를 꺼내면 가장 먼저 돌아오는 반응이다. 맞는 말이기도 하다. 공공기관 이름을 구글이나 네이버에 치면 대부분 첫 페이지에 나온다. 그런데 '기관 이름'으로 검색하는 사람은 그 기관을 이미 아는 사람이다. 그 기관이 다루는 정보를 몰라서 검색하는 ",author:"ViewCheck Insight",date:"2026.07.20",read:"5분",views:"73",cover:"https://xbbhievqdmccsexxrdtn.supabase.co/storage/v1/object/sign/covers/content/4zf885zg-804879.png?token=eyJraWQiOiJzdG9yYWdlLXVybC1zaWduaW5nLWtleV8yOWQwYWZmNy1mOWJhLTRkNmUtYmZlZi0yMzg2NTc0ZWUzODQiLCJhbGciOiJIUzI1NiJ9.eyJ1cmwiOiJjb3ZlcnMvY29udGVudC80emY4ODV6Zy04MDQ4NzkucG5nIiwic2NvcGUiOiJkb3dubG9hZCIsImlhdCI6MTc4NDUwNjIyNCwiZXhwIjoyMDk5ODY2MjI0fQ.hlS6ryhnqnqY9UJQaPdpXyuHYFysLQP1qmpQorh1BPQ",tags:$R[15]=["SEO","구조화데이터","OpenGraph","공공웹","KRDS","메타태그","JSONLD","헤딩구조","ViewCheck","전자정부","검색최적화","공공기관SEO"],sections:$R[16]=[],content:"\x3Ch3>검색창에 '기관명'을 치면 무엇이 보이는가, 우리가 SEO 진단을 시작한 이유\x3C/h3>\n\x3Chr>\n\x3Ch2>들어가며 — "검색하면 나오지 않나요?"라는 가장 쉬운 질문\x3C/h2>\n\x3Cp>"검색하면 나오지 않나요?"\x3C/p>\n\x3Cp>공공 웹사이트를 운영하는 담당자들에게 SEO 얘기를 꺼내면 가장 먼저 돌아오는 반응이다. 맞는 말이기도 하다. 공공기관 이름을 구글이나 네이버에 치면 대부분 첫 페이지에 나온다. 그런데 '기관 이름'으로 검색하는 사람은 그 기관을 이미 아는 사람이다. 그 기관이 다루는 정보를 몰라서 검색하는 시민은, 기관 이름이 아니라 '민원 키워드'로 검색한다. "노인 돌봄 신청 방법", "어린이집 인가 서류", "주차위반 이의신청 기간" 같은 식으로.\x3C/p>\n\x3Cp>이 지점에서 공공웹의 SEO 문제가 시작된다. 기관명으로 치면 나오는데, 시민이 실제로 필요한 정보를 검색하면 엉뚱한 블로그나 커뮤니티 글이 먼저 나오고 공식 사이트는 뒤페이지에 있는 경우를 우리는 ViewCheck 분석 과정에서 적잖이 마주쳤다. 공식 정보가 있는데, 검색엔진이 그 페이지를 제대로 이해하지 못해서 상위에 못 올라오는 것이다.\x3C/p>\n\x3Cp>왜 그럴까. 이유는 여러 가지지만, 그 시작에는 거의 항상 몇 가지 공통 문제가 있다. 메타 태그가 없거나, 모든 페이지가 같은 title을 쓰거나, Open Graph 태그가 빠져 있어서 SNS에 링크를 퍼 나를 때 이미지와 설명이 공란으로 뜨거나, 구조화데이터(JSON-LD)가 전혀 없어서 검색 결과에 리치 결과(Rich Result)가 표시되지 않거나, 헤딩(H1~H6) 구조가 제멋대로거나.\x3C/p>\n\x3Cp>이런 요소들은 기술적으로 복잡하지 않다. 마크업 몇 줄이면 달라지는 것들이다. 그런데 정작 많은 공공 사이트에서 이 기초가 빠져 있다. 왜일까. 담당자가 몰라서이기도 하지만, 더 근본적으로는 "내 사이트의 SEO 요소들이 지금 어떤 상태인지"를 체계적으로 파악하는 도구와 절차가 없기 때문이다. 눈에 잘 안 보이고, 직접적인 불편이 즉각 생기지 않는 영역이라 후순위로 밀린다.\x3C/p>\n\x3Cp>ViewCheck가 SEO 진단 기능을 만든 이유가 여기에 있다. 공공 웹의 SEO는 민간 이커머스의 SEO와 다르다. 클릭률을 올려서 수익을 늘리는 게 목적이 아니라, 시민이 공식 정보를 더 쉽게 찾을 수 있게 하는 게 목적이다. 그 목적을 위해 기초가 갖춰져 있는지, 빠진 곳이 어디인지를 빠르게 파악하는 것 — 그것이 우리가 SEO 진단에서 하려는 일이다.\x3C/p>\n\x3Cp>이 글에서는 ViewCheck가 공공 웹의 SEO 요소를 어떻게 진단하는지를 주제별로 풀어간다. 메타 태그, Open Graph 태그, 구조화데이터(JSON-LD), 헤딩 계층, canonical URL, 그리고 robots.txt와 sitemap.xml까지. 기술적인 내용이지만, 가능한 한 "왜 중요한가"와 "공공웹에서는 어떤 패턴이 자주 보이는가"를 중심으로 이야기하겠다. 아직 우리가 파악하지 못한 부분도 솔직하게 적을 것이다.\x3C/p>\n\x3Cfigure>\x3Cimg src=\"https://xbbhievqdmccsexxrdtn.supabase.co/storage/v1/object/sign/covers/content/isbdz1jn-109117.jpg?token=eyJraWQiOiJzdG9yYWdlLXVybC1zaWduaW5nLWtleV8yOWQwYWZmNy1mOWJhLTRkNmUtYmZlZi0yMzg2NTc0ZWUzODQiLCJhbGciOiJIUzI1NiJ9.eyJ1cmwiOiJjb3ZlcnMvY29udGVudC9pc2JkejFqbi0xMDkxMTcuanBnIiwic2NvcGUiOiJkb3dubG9hZCIsImlhdCI6MTc4NDUwNjIyNCwiZXhwIjoyMDk5ODY2MjI0fQ.BHTr57N4_mwQWWxTS56iENr0ADl_deUz_oFiudYbNTQ\" alt=\"밝은 사무실에서 한국인 마케터가 노트북으로 SEO 체크리스트를 검토하고 있는 모습.\" loading=\"lazy\" />\x3Cfigcaption>공공 웹의 SEO 체크리스트 — 메타 태그부터 구조화 데이터까지, 기초 점검이 먼저다.\x3C/figcaption>\x3C/figure>\x3Chr>\n\x3Ch2>SEO가 공공웹에서 왜 중요한가 — 시민의 검색 여정 이야기\x3C/h2>\n\x3Cp>먼저 맥락부터 짚고 가자. 공공 웹에서 SEO를 이야기할 때, 우리는 '광고비를 아끼거나 쇼핑몰 전환율을 올리는' 식의 상업적 SEO와는 다른 이야기를 한다.\x3C/p>\n\x3Cp>공공 서비스는 시민의 '필요'에서 시작된다. 어떤 시민이 특정 지원금을 신청하고 싶다. 그는 검색창을 연다. 기관 이름을 모를 수도 있다. 정확한 사업 이름도 모른다. 그냥 "청년 창업 지원금 신청"이라고 치거나, "어르신 틀니 지원 2025" 같은 키워드를 넣는다. 검색 결과 첫 페이지에 공식 기관 페이지가 나오면 시민은 공식 정보를 얻는다. 하지만 첫 페이지에 커뮤니티 게시글, 블로거의 요약 포스팅, 뉴스 기사만 잔뜩 뜨고 공식 페이지가 2~3페이지에 있다면, 시민은 그 비공식 정보를 통해 서비스를 이해하게 된다. 부정확하거나 오래된 정보일 가능성이 높다.\x3C/p>\n\x3Cp>공식 정보가 있어도 검색엔진이 그 페이지를 제대로 인식하지 못하면, 결과적으로 공공 서비스 접근성이 떨어진다. 이건 단순한 트래픽 문제가 아니라, 시민의 공공 서비스 이용 경험 전반의 문제다.\x3C/p>\n\x3Cp>행정안전부의 「전자정부 웹사이트 품질관리 지침」(행안부고시 제2025-46호, 2025.6.25 일부개정)은 공공 웹사이트가 갖춰야 할 7대 품질 영역을 정의한다. 그 중 \x3Cstrong>개방성\x3C/strong>은 "정보의 공개와 공유를 위해 robots.txt, 메타데이터, 크롤링 허용 등 정보가 열려 있는가"를 다룬다. 검색엔진이 사이트의 정보를 수집하고 색인할 수 있어야 한다는 것이 공공 웹의 공식 품질 기준 중 하나인 것이다. SEO의 기초는 곧 개방성의 기초이기도 하다.\x3C/p>\n\x3Cp>우리가 ViewCheck에서 여러 공공 사이트를 분석하면서 자주 보는 현상은 대략 이렇다. 메인 페이지는 어느 정도 관리가 되어 있다. title 태그도 있고, description도 있다. 그런데 신청 페이지, 상세 공지 페이지, 검색 결과 페이지로 들어가면 상황이 달라진다. title이 사이트 이름 하나로 전부 같거나, description이 비어 있거나, H1이 없는 페이지도 나온다. 개별 페이지의 SEO 요소가 제대로 관리되지 않는 것이다.\x3C/p>\n\x3Cp>이게 왜 문제냐면, 구글과 네이버 같은 검색엔진은 사이트 전체가 아니라 \x3Cstrong>개별 페이지\x3C/strong>를 색인한다. 메인은 좋아도, 실제 콘텐츠가 있는 하위 페이지들의 SEO가 안 되어 있으면 그 페이지들은 검색 결과에서 잘 보이지 않는다. 시민이 직접 찾아야 할 정보가 있는 페이지가 바로 그 하위 페이지들이다.\x3C/p>\n\x3Chr>\n\x3Ch2>메타 태그의 기초 — title, description, viewport, lang\x3C/h2>\n\x3Cp>SEO 진단의 첫 번째 관문은 \x3Cstrong>메타 태그\x3C/strong>다. HTML의 \x3Ccode><head>\x3C/code> 영역에 들어가는 이 짧은 코드들이, 검색엔진과 브라우저가 페이지를 이해하는 방식에 직접 영향을 준다.\x3C/p>\n\x3Cp>가장 중요한 것은 \x3Cstrong>title 태그\x3C/strong>다. 검색 결과 목록에서 파란색으로 보이는 제목이 바로 이 title 태그에서 온다. Google Search Central의 공식 문서는 이렇게 설명한다.\x3C/p>\n\x3Cblockquote>\n\x3Cp>"Make sure every page on your site has a title specified in the \x3Ctitle> element. Write descriptive and concise text for your \x3Ctitle> elements."\n— Google, \x3Cem>SEO Starter Guide: The Basics\x3C/em>, developers.google.com\x3C/p>\n\x3C/blockquote>\n\x3Cp>좋은 title 태그는 해당 페이지의 내용을 정확하고 간결하게 요약해야 한다. 그리고 \x3Cstrong>페이지마다 달라야 한다\x3C/strong>. 사이트 전체가 "○○시청 공식 홈페이지"라는 동일한 title을 쓴다면, 검색엔진은 각 페이지를 구분하기 어렵고, 사용자는 검색 결과에서 어떤 페이지가 자신에게 필요한지 판단하기 어렵다. Google은 약 60~70자 이내를 권장하며, 모바일과 데스크톱 화면 너비에 맞게 잘리지 않도록 하는 것이 좋다.\x3C/p>\n\x3Cp>\x3Cstrong>meta description\x3C/strong>은 검색 결과에서 title 아래에 나오는 요약 설명이다. Google Search Central의 가이드는 이렇게 말한다.\x3C/p>\n\x3Cblockquote>\n\x3Cp>"A meta description tag generally informs and interests users with a short, relevant summary of what a particular page is about. They are like a pitch that convince the user that the page is exactly what they're looking for."\n— Google, \x3Cem>How to Write Meta Descriptions\x3C/em>, developers.google.com\x3C/p>\n\x3C/blockquote>\n\x3Cp>meta description은 직접적인 랭킹 요소는 아니다. 그러나 검색 결과 페이지(SERP)에서 사용자가 클릭할지 말지를 결정하는 '문구'로 작용한다. 잘 쓴 description은 클릭률(CTR)을 높인다. 공공 사이트의 경우 서비스 내용을 명확하게 담아야 하고, 가능하면 신청 기간, 대상, 핵심 키워드를 포함하는 것이 좋다. 권장 길이는 대략 150~155자 내외다.\x3C/p>\n\x3Cp>주의할 점이 있다. Google은 실제로 meta description을 그대로 쓰지 않을 때가 많다. 페이지 본문에서 더 적절한 문구를 골라 검색 결과 스니펫으로 사용하기도 한다. 연구에 따르면 Google이 meta description을 재작성하는 비율이 62~70%에 달한다는 분석도 있다. 그렇다고 description을 안 써도 된다는 뜻이 아니다. 제대로 작성된 description은 Google이 '그대로 쓰기 가장 좋은 요약'으로 선택할 가능성이 높고, 소셜 미디어에서 공유될 때도 이 description이 표시된다.\x3C/p>\n\x3Cp>\x3Cstrong>viewport 메타 태그\x3C/strong>는 반응형 웹의 기초다. \x3Ccode><meta name="viewport" content="width=device-width, initial-scale=1">\x3C/code> 한 줄이 없으면, 모바일에서 PC 화면이 축소되어 표시된다. W3C(월드와이드웹 컨소시엄)와 WHATWG의 HTML 표준에서 viewport 메타 태그는 모바일 반응형 웹의 기본 요소로 명시된다. Google도 모바일 친화성을 랭킹 신호로 사용하기 때문에, viewport 설정 누락은 검색 노출에도 영향을 줄 수 있다.\x3C/p>\n\x3Cp>\x3Cstrong>lang 속성\x3C/strong>은 HTML 태그에 붙는 언어 선언이다. \x3Ccode><html lang="ko">\x3C/code>처럼. 접근성(스크린 리더가 올바른 언어로 읽을 수 있도록)과 SEO(검색엔진이 페이지 언어를 인식해 적절한 사용자에게 노출하도록) 모두에서 중요하다. KWCAG(한국형 웹 콘텐츠 접근성 지침) 2.2에서도 콘텐츠의 주 언어를 명시하도록 요구하는 지침이 있다.\x3C/p>\n\x3Cp>ViewCheck는 이 네 가지 기본 메타 태그를 모든 페이지에서 점검한다. 있는지 없는지가 아니라, \x3Cstrong>있더라도 제대로 작동하는지\x3C/strong>까지 확인한다. 예를 들어 title이 있어도 30자가 안 되는 지나치게 짧은 경우나, 모든 페이지가 같은 title을 공유하는 경우도 점검 대상에 포함한다. 이 판정 과정이 어떻게 이뤄지는지는 뒤에서 다시 다룰 것이다.\x3C/p>\n\x3Chr>\n\x3Ch2>Open Graph 태그 — SNS에서 공공 정보가 어떻게 보이는가\x3C/h2>\n\x3Cp>메타 태그가 검색엔진을 위한 것이라면, \x3Cstrong>Open Graph 태그\x3C/strong>는 소셜 미디어를 위한 것이다. 카카오톡, 페이스북, 트위터(X), 슬랙, 텔레그램 등 대부분의 메신저와 소셜 플랫폼은 링크를 공유할 때 해당 페이지의 Open Graph 태그를 읽어서 '링크 미리보기(preview card)'를 생성한다.\x3C/p>\n\x3Cp>Open Graph 프로토콜은 2010년 페이스북이 만들었다. 공식 사양은 ogp.me에서 관리된다. 핵심 태그 네 가지는 다음과 같다.\x3C/p>\n\x3Cpre>\x3Ccode class=\"language-html\"><meta property="og:title" content="페이지 제목" />\n<meta property="og:description" content="페이지 요약 설명" />\n<meta property="og:image" content="https://example.go.kr/images/thumb.jpg" />\n<meta property="og:url" content="https://example.go.kr/page/" />\n\x3C/code>\x3C/pre>\n\x3Cp>이 네 가지를 갖추면, 카카오톡에서 링크를 공유했을 때 이미지와 제목, 설명이 미리보기로 나타난다. 없으면 URL 텍스트만 노출되거나, 임의의 이미지가 잡히거나, 설명이 공란으로 뜬다.\x3C/p>\n\x3Cp>공공 정보가 시민에게 전달되는 경로는 공식 홈페이지 방문만이 아니다. 담당자가 카카오 단체채팅방에 공지를 공유하거나, 인스타그램에 링크를 올리거나, 지역 온라인 커뮤니티에 글을 남기는 식으로 퍼진다. 이때 Open Graph 미리보기가 제대로 나타나야 시민이 클릭할 가능성이 높아지고, 공식 정보임을 신뢰하게 된다.\x3C/p>\n\x3Cp>Open Graph 태그가 없거나 부실한 경우, 어떤 일이 생기는지를 구체적으로 상상해 보자. 주민센터 담당자가 "2025년 긴급복지지원 신청 안내" 페이지 링크를 주민 단체채팅방에 올린다. og:image가 없으면 기관 로고도, 안내 배너도 보이지 않는다. og:title이 없으면 URL만 뜬다. 시민 입장에서는 이 링크가 신뢰할 수 있는 공식 정보인지, 아니면 누군가 요약한 블로그인지 구분이 안 된다. 클릭률도 떨어진다.\x3C/p>\n\x3Cp>\x3Ccode>og:image\x3C/code>는 특히 중요하다. 대개 1200×630픽셀 이상의 비율을 권장하며, 정보를 담은 대표 이미지가 있어야 한다. 그리고 \x3Ccode>og:url\x3C/code>은 페이지의 canonical URL과 동일해야 한다. 둘이 다르면 소셜 플랫폼이 링크를 잘못 인식할 수 있다.\x3C/p>\n\x3Cp>우리가 ViewCheck로 공공 사이트들을 분석하면서 자주 마주치는 패턴이 있다. 메인 페이지에는 Open Graph 태그가 있는데, 개별 콘텐츠 페이지(보도자료, 공지사항, 사업 안내 페이지 등)에는 없는 경우다. 시민이 직접 공유하는 건 개별 페이지인데, 정작 그 페이지들에 OG 태그가 없다. 또는 og:image가 모든 페이지에서 동일한 기관 로고를 가리켜, 다양한 콘텐츠를 공유해도 항상 같은 이미지가 뜨는 경우도 많다.\x3C/p>\n\x3Cp>ViewCheck의 SEO 진단은 메인 페이지만 보지 않는다. 사이트를 크롤링하며 여러 페이지의 OG 태그 현황을 페이지별로 수집하고, 전체 사이트에서 OG 태그 커버리지가 어느 수준인지를 함께 본다. 물론 100%가 아니더라도 어떤 유형의 페이지에서 주로 누락되는지를 파악하는 것만으로도 개선 우선순위를 잡는 데 도움이 된다.\x3C/p>\n\x3Cfigure>\x3Cimg src=\"https://xbbhievqdmccsexxrdtn.supabase.co/storage/v1/object/sign/covers/content/qfeu2yqf-108088.jpg?token=eyJraWQiOiJzdG9yYWdlLXVybC1zaWduaW5nLWtleV8yOWQwYWZmNy1mOWJhLTRkNmUtYmZlZi0yMzg2NTc0ZWUzODQiLCJhbGciOiJIUzI1NiJ9.eyJ1cmwiOiJjb3ZlcnMvY29udGVudC9xZmV1MnlxZi0xMDgwODguanBnIiwic2NvcGUiOiJkb3dubG9hZCIsImlhdCI6MTc4NDUwNjIyNSwiZXhwIjoyMDk5ODY2MjI1fQ.OlJZUc7jdl_bWbb5B7zYw9f3mqW9N5qdzjmtcPKLfAQ\" alt=\"소프트하게 블러 처리된 화면의 코드를 바라보며 검색 최적화 작업을 하는 한국인 개발자의 클로즈업.\" loading=\"lazy\" />\x3Cfigcaption>소셜 공유 시 미리보기를 결정하는 Open Graph 태그 — 몇 줄 코드의 차이가 클릭률을 바꾼다.\x3C/figcaption>\x3C/figure>\x3Chr>\n\x3Ch2>구조화데이터(JSON-LD) — 검색엔진이 '이해하는' 정보\x3C/h2>\n\x3Cp>SEO의 한 단계 위에 **구조화데이터(Structured Data)**가 있다. 단순히 "이 페이지가 존재한다"를 알리는 것에서 나아가, "이 페이지가 어떤 종류의 정보이고, 핵심 내용이 무엇인지"를 검색엔진에게 명시적으로 알려주는 기술이다.\x3C/p>\n\x3Cp>구조화데이터의 형식은 여러 가지가 있지만, 지금 가장 널리 쓰이고 구글이 권장하는 방식은 **JSON-LD(JSON for Linked Data)**다. Google Search Central의 공식 문서는 이렇게 설명한다.\x3C/p>\n\x3Cblockquote>\n\x3Cp>"Google recommends using JSON-LD for structured data if your site's setup allows it, as it's the easiest solution for website owners to implement and maintain at scale (in other words, less prone to user errors)."\n— Google, \x3Cem>Intro to How Structured Data Markup Works\x3C/em>, developers.google.com\x3C/p>\n\x3C/blockquote>\n\x3Cp>JSON-LD는 \x3Ccode><script type="application/ld+json">\x3C/code> 태그 안에 JSON 형식으로 데이터를 넣는 방식이다. HTML 본문 어느 위치에나 삽입할 수 있고, 기존 HTML 코드를 건드리지 않아도 된다. 이전 방식인 Microdata나 RDFa와 달리, 페이지 콘텐츠와 메타 정보를 분리해서 관리할 수 있어 유지보수가 쉽다.\x3C/p>\n\x3Cp>구조화데이터에서 어떤 '타입'을 쓸지는 schema.org에서 정의한다. schema.org는 Google, Microsoft, Yahoo, Yandex가 공동으로 만든 어휘 표준이다. 현재 823개의 타입(Type)과 1,529개의 속성(Property)이 정의되어 있다(schema.org 공식). 공공 웹에서 자주 활용할 수 있는 타입들을 몇 가지만 꼽으면 이렇다.\x3C/p>\n\x3Cul>\n\x3Cli>\x3Cstrong>Organization\x3C/strong>: 기관의 이름, 로고, 공식 URL, 소셜 미디어 계정, 연락처\x3C/li>\n\x3Cli>\x3Cstrong>GovernmentOrganization\x3C/strong>: Organization의 하위 타입. 정부기관에 특화\x3C/li>\n\x3Cli>\x3Cstrong>Event\x3C/strong>: 행사, 설명회, 공청회 정보\x3C/li>\n\x3Cli>\x3Cstrong>Article / NewsArticle\x3C/strong>: 보도자료, 뉴스 공지\x3C/li>\n\x3Cli>\x3Cstrong>FAQPage\x3C/strong>: 자주 묻는 질문과 답변\x3C/li>\n\x3Cli>\x3Cstrong>Service\x3C/strong>: 공공 서비스, 신청 안내\x3C/li>\n\x3Cli>\x3Cstrong>WebSite\x3C/strong>: 사이트 전체의 검색 기능(Sitelinks Searchbox) 등록\x3C/li>\n\x3C/ul>\n\x3Cp>이 구조화데이터를 제대로 삽입하면, 검색 결과에 **리치 결과(Rich Result)**가 뜰 수 있다. 일반적인 파란 제목+설명 텍스트 대신, 별점이 함께 뜨거나, FAQ가 펼쳐지거나, 이미지가 표시되는 등 시각적으로 더 풍부한 형태다.\x3C/p>\n\x3Cp>이 리치 결과의 효과는 실측 데이터가 있다. Google Search Central의 공식 구조화데이터 문서에서는 Nestlé의 사례를 인용한다.\x3C/p>\n\x3Cblockquote>\n\x3Cp>"Nestlé has measured pages that show as rich results in search have an 82% higher click through rate than non-rich result pages."\n— Google, \x3Cem>Intro to How Structured Data Markup Works\x3C/em>, developers.google.com\x3C/p>\n\x3C/blockquote>\n\x3Cp>82%는 꽤 큰 숫자다. 물론 이커머스나 레시피처럼 시각화가 강한 영역에서의 효과가 공공기관 정보 페이지와 동일하게 적용된다고 단정할 수는 없다. 다만 '페이지에 대한 더 많은 정보를 검색엔진에게 명확히 전달하면, 검색 결과의 노출 품질이 올라간다'는 원리 자체는 공공 웹에도 동일하게 적용된다.\x3C/p>\n\x3Cp>공공 사이트에서 자주 만나는 패턴은, 구조화데이터가 아예 없거나, 있어도 기본적인 Organization 타입 하나뿐인 경우다. 보도자료는 Article 타입으로, FAQ는 FAQPage 타입으로, 공개 행사는 Event 타입으로 마크업하면 각각 더 풍부한 검색 결과를 만들 수 있는데, 대부분의 공공 사이트는 이 부분을 활용하지 않는다.\x3C/p>\n\x3Cp>ViewCheck의 SEO 진단에서는 구조화데이터의 존재 여부, 어떤 타입이 사용되었는지, Google의 검증 기준에 맞게 작성되었는지를 확인한다. JSON-LD 형식인지, Microdata나 RDFa 형식인지도 구분한다. 이 판정 역시 메인 페이지뿐 아니라 크롤링된 여러 페이지에 걸쳐 이뤄진다.\x3C/p>\n\x3Chr>\n\x3Ch2>헤딩 계층 — H1에서 H6까지, 구조가 내용을 안내한다\x3C/h2>\n\x3Cp>구조화데이터가 검색엔진을 위한 '명시적 선언'이라면, \x3Cstrong>헤딩(H1~H6) 계층\x3C/strong>은 페이지 콘텐츠 자체의 구조를 드러내는 방식이다. 접근성과 SEO 양쪽에 모두 영향을 미친다.\x3C/p>\n\x3Cp>헤딩의 기본 원칙은 간단하다. H1은 페이지의 핵심 주제를 나타내는 가장 중요한 제목이고, H2~H6은 그 아래에 들어가는 소제목들이다. 책의 목차처럼, 페이지의 구조를 위계 있게 나타낸다.\x3C/p>\n\x3Cp>SEO 관점에서 헤딩은 검색엔진이 페이지 내용을 이해하는 데 사용하는 신호다. Google Search Central 커뮤니티에 올라온 공식 답변과 여러 SEO 연구에 따르면, H1은 title 다음으로 강한 on-page SEO 신호다. 그러나 Google은 최근 헤딩의 "위계적 순서 자체가 랭킹에 직접 영향을 주지는 않는다"고도 명확히 했다. 즉, H2 다음에 H4가 온다고 해서 랭킹이 직접 떨어지지는 않지만, \x3Cstrong>의미론적으로 바른 구조가 검색엔진의 이해를 돕고 접근성을 높인다\x3C/strong>는 점에서 중요하다.\x3C/p>\n\x3Cp>접근성 관점에서 헤딩은 더 직접적인 영향을 미친다. 시각 장애인이 사용하는 스크린 리더는 헤딩을 '목차'처럼 활용한다. 사용자는 헤딩을 통해 페이지의 구조를 탐색하고, 원하는 섹션으로 빠르게 이동한다. 헤딩이 없거나 계층이 엉망이면, 스크린 리더 사용자는 페이지 전체를 처음부터 끝까지 읽어야 하는 상황이 된다. KWCAG 2.2와 WCAG 2.2 모두 논리적인 헤딩 구조를 접근성 요건으로 포함한다.\x3C/p>\n\x3Cp>공공 사이트에서 자주 보이는 헤딩 관련 문제들은 크게 몇 가지다.\x3C/p>\n\x3Cp>\x3Cstrong>H1 누락 또는 복수 H1\x3C/strong>: 페이지에 H1이 없거나, 시각적 디자인 때문에 CSS로 만든 '큰 제목'이 있는데 실제 HTML에는 H1이 없는 경우. 또는 로고, 메뉴, 본문 제목 등 여러 곳에 H1이 중복 사용된 경우.\x3C/p>\n\x3Cp>\x3Cstrong>헤딩 단계 건너뜀\x3C/strong>: H1 다음에 바로 H4가 오거나, H2 아래에 H6이 오는 식으로 위계를 건너뛰는 경우. 시각적으로는 폰트 크기만 맞추면 되지만, 구조적으로는 맞지 않는다.\x3C/p>\n\x3Cp>\x3Cstrong>스타일 목적의 헤딩 남용\x3C/strong>: "크게 보이고 싶어서" H1이나 H2를 쓰는 경우. 페이지의 실제 내용 구조와 무관하게 헤딩이 배치된다.\x3C/p>\n\x3Cp>\x3Cstrong>모든 페이지의 H1이 동일\x3C/strong>: 사이트 공통 헤더에 사이트명이 H1으로 박혀 있어서, 어느 페이지를 가도 H1은 "○○시청"뿐인 경우.\x3C/p>\n\x3Cp>ViewCheck의 SEO 진단은 각 페이지의 H1~H6 구조를 수집해서, H1 개수, 헤딩 계층의 논리성, 헤딩 없는 페이지 비율 등을 정리한다. 특히 다중 페이지 분석을 기본으로 하기 때문에, "메인 페이지의 헤딩 구조는 괜찮은데 하위 페이지들의 헤딩이 깨져 있다"는 패턴도 잡아낼 수 있다.\x3C/p>\n\x3Chr>\n\x3Ch2>canonical URL — 중복 페이지 문제와 정규화\x3C/h2>\n\x3Cp>공공 사이트에서 흔히 발생하는 또 다른 SEO 문제가 \x3Cstrong>중복 콘텐츠\x3C/strong>다. 같은 내용이 여러 URL에서 접근 가능할 때 생기는 문제다.\x3C/p>\n\x3Cp>예를 들어, 한 공공기관 사이트에서 동일한 공지 페이지가 \x3Ccode>https://example.go.kr/notice/123\x3C/code>과 \x3Ccode>https://www.example.go.kr/notice/123\x3C/code> (www 차이), 또는 \x3Ccode>https://example.go.kr/notice/123?page=1\x3C/code> (파라미터 붙은 버전)으로 동시에 접근 가능한 경우가 있다. 또는 모바일 전용 주소(\x3Ccode>m.example.go.kr\x3C/code>)와 PC 주소가 별도로 운영되는 경우도 있다.\x3C/p>\n\x3Cp>검색엔진 입장에서는 같은 내용이 여러 URL에 있으면 '어느 URL을 기준으로 색인해야 하는가'를 판단해야 한다. 잘못하면 링크 점수가 분산되거나, 원본이 아닌 복사본이 더 높이 뜰 수도 있다.\x3C/p>\n\x3Cp>이 문제를 해결하는 방법이 \x3Cstrong>canonical 태그\x3C/strong>다. \x3Ccode><link rel="canonical" href="https://example.go.kr/notice/123" />\x3C/code>를 HTML head에 넣어서, "이 URL이 이 콘텐츠의 정규(canonical) 주소다"라고 선언하는 것이다.\x3C/p>\n\x3Cp>Google Search Central의 공식 가이드는 이렇게 설명한다.\x3C/p>\n\x3Cblockquote>\n\x3Cp>"Google chooses a single URL (the canonical URL) to show users, per piece of content. To specify which URL you want Google to consider canonical, use the rel='canonical' link element."\n— Google, \x3Cem>How to Specify a Canonical with rel="canonical"\x3C/em>, developers.google.com\x3C/p>\n\x3C/blockquote>\n\x3Cp>canonical 태그가 없으면 Google이 알아서 canonical을 결정하는데, 그 결과가 우리가 원하는 URL이 아닐 수 있다. 특히 파라미터가 붙은 URL이나 www/non-www가 혼재하는 경우에는 명시적 canonical 선언이 중요하다.\x3C/p>\n\x3Cp>공공 사이트에서 자주 보이는 문제는 canonical 태그 자체가 없는 경우, 또는 canonical이 자기 자신을 가리키지 않고 엉뚱한 URL을 가리키는 경우(CMS나 템플릿 오류로 발생), 또는 og:url과 canonical이 서로 다른 URL을 가리키는 경우 등이다.\x3C/p>\n\x3Cp>ViewCheck는 각 페이지의 canonical 태그 존재 여부와, canonical이 가리키는 URL이 접근 가능한 유효한 URL인지를 점검한다. og:url과의 일치 여부도 확인 대상이다.\x3C/p>\n\x3Cfigure>\x3Cimg src=\"https://xbbhievqdmccsexxrdtn.supabase.co/storage/v1/object/sign/covers/content/yc1a7q5w-101587.jpg?token=eyJraWQiOiJzdG9yYWdlLXVybC1zaWduaW5nLWtleV8yOWQwYWZmNy1mOWJhLTRkNmUtYmZlZi0yMzg2NTc0ZWUzODQiLCJhbGciOiJIUzI1NiJ9.eyJ1cmwiOiJjb3ZlcnMvY29udGVudC95YzFhN3E1dy0xMDE1ODcuanBnIiwic2NvcGUiOiJkb3dubG9hZCIsImlhdCI6MTc4NDUwNjIyNSwiZXhwIjoyMDk5ODY2MjI1fQ.AzrP0O7QNCKTpe14v5xn8VF2zIOPpFClkM4dgNLsJZA\" alt=\"책상에 앉아 공공 웹사이트의 검색 노출 최적화 작업에 집중하는 한국인의 모습.\" loading=\"lazy\" />\x3Cfigcaption>canonical 태그 하나로 중복 페이지 문제가 해결된다 — 기초지만 놓치기 쉬운 영역.\x3C/figcaption>\x3C/figure>\x3Chr>\n\x3Ch2>robots.txt와 sitemap.xml — 개방성의 가장 기본 인프라\x3C/h2>\n\x3Cp>SEO에서 '수집 가능성'을 결정하는 두 개의 파일이 있다. \x3Cstrong>robots.txt\x3C/strong>와 \x3Cstrong>sitemap.xml\x3C/strong>이다.\x3C/p>\n\x3Cp>\x3Cstrong>robots.txt\x3C/strong>는 검색엔진 크롤러에게 "어떤 페이지를 수집해도 되고, 어떤 페이지는 수집하지 말아야 하는지"를 알려주는 파일이다. 사이트 루트에 \x3Ccode>https://example.go.kr/robots.txt\x3C/code> 형태로 놓인다. 검색엔진의 Googlebot, Naverbot 같은 봇들은 사이트 방문 전에 이 파일을 먼저 읽는다.\x3C/p>\n\x3Cp>Google은 robots.txt 파일 생성과 제출에 관한 공식 가이드를 제공하고 있다. robots.txt의 \x3Ccode>User-agent\x3C/code>, \x3Ccode>Allow\x3C/code>, \x3Ccode>Disallow\x3C/code> 지시어를 통해 특정 봇에 대해 접근 허용/차단을 세밀하게 설정할 수 있다.\x3C/p>\n\x3Cp>잘못 설정된 robots.txt는 심각한 결과를 낳는다. 국내 SEO 전문가들이 공유하는 사례에 따르면, robots.txt 오설정으로 인해 사이트 전체 색인이 블락되어 하루 트래픽이 30만 명에서 2천 명대로 떨어진 사례도 있다. 의외로 많은 국내 금융권 기업, 국가 기관, 지자체, 대학 웹사이트에서 이런 실수를 찾아볼 수 있다고 SEO 전문가들은 지적한다(TBWA 데이터랩, robots.txt 총정리 가이드).\x3C/p>\n\x3Cp>행안부 「전자정부 웹사이트 품질관리 지침」(고시 제2025-46호)은 최근 개정에서 흥미로운 변화를 담았다. 기존에는 크롤링을 '완전 허용'하도록 했던 개방성 기준이, '일부 차단'이 가능하도록 수정되었다. 즉 개인정보가 포함된 영역, 민감한 내부 관리 페이지 등은 합리적 근거로 차단할 수 있게 된 것이다. 이 변화는 robots.txt를 '있으면 무조건 Disallow 없게'가 아니라, 목적에 맞게 섬세하게 관리해야 한다는 방향을 시사한다.\x3C/p>\n\x3Cp>\x3Cstrong>sitemap.xml\x3C/strong>은 사이트에 있는 모든(혹은 주요) URL의 목록을 XML 형식으로 제공하는 파일이다. 검색엔진이 새로운 페이지를 더 빠르게 발견하고 색인할 수 있도록 돕는다. lastmod(최종 수정일), changefreq(변경 주기) 등의 속성으로 콘텐츠 업데이트 정보도 제공할 수 있다.\x3C/p>\n\x3Cp>공공 사이트에서 자주 보이는 sitemap 관련 문제는 크게 세 가지다. 첫째, sitemap.xml 자체가 없는 경우. 둘째, sitemap이 있는데 robots.txt에 sitemap 위치가 명시되어 있지 않은 경우. 셋째, sitemap에 포함된 URL들이 실제로는 404 오류를 반환하거나, 이미 삭제된 페이지를 가리키는 경우(sitemap 관리가 자동화되어 있지 않을 때 흔히 발생).\x3C/p>\n\x3Cp>ViewCheck는 robots.txt와 sitemap.xml을 각 사이트에 대해 수집하고 파싱한다. robots.txt에서 Disallow 규칙이 너무 광범위하게 설정되어 있진 않은지, 중요한 콘텐츠 페이지가 차단되어 있진 않은지를 체크한다. sitemap.xml에서는 URL 수, lastmod의 유효성, sitemapindex(sitemap 파일을 여러 개로 나눈 경우의 인덱스 파일) 구조 등을 확인한다. 이 수집과 파싱 작업은 사이트 분석 시 1회만 수행하며, 다중 페이지 분석이라도 robots.txt와 sitemap은 사이트당 한 번만 가져온다.\x3C/p>\n\x3Chr>\n\x3Ch2>ViewCheck SEO 진단의 실제 — 14종 점검 항목과 다중 페이지 접근\x3C/h2>\n\x3Cp>지금까지 개별 SEO 요소들을 설명했다. 그럼 ViewCheck의 SEO 진단이 실제로는 어떤 구조로 이뤄지는지를 정리해보자.\x3C/p>\n\x3Cp>ViewCheck는 SEO 분석을 크게 두 층위로 나눈다.\x3C/p>\n\x3Cp>\x3Cstrong>사이트 단위\x3C/strong>: robots.txt, sitemap.xml, canonical 패턴처럼 사이트 전체에 걸쳐 한 번만 수집·분석하면 되는 항목.\x3C/p>\n\x3Cp>\x3Cstrong>페이지 단위\x3C/strong>: title, description, OG 태그, 헤딩 구조, 구조화데이터처럼 각 페이지마다 별도로 수집·분석해야 하는 항목.\x3C/p>\n\x3Cp>SEO 진단에서 체크하는 주요 항목들은 다음과 같다.\x3C/p>\n\x3Ctable>\n\x3Cthead>\n\x3Ctr>\n\x3Cth>항목\x3C/th>\n\x3Cth>점검 내용\x3C/th>\n\x3C/tr>\n\x3C/thead>\n\x3Ctbody>\x3Ctr>\n\x3Ctd>title 태그\x3C/td>\n\x3Ctd>존재 여부, 길이(50~60자 권장), 페이지별 중복 여부\x3C/td>\n\x3C/tr>\n\x3Ctr>\n\x3Ctd>meta description\x3C/td>\n\x3Ctd>존재 여부, 길이(150자 내외 권장), 페이지별 중복 여부\x3C/td>\n\x3C/tr>\n\x3Ctr>\n\x3Ctd>viewport 메타\x3C/td>\n\x3Ctd>반응형 뷰포트 선언 여부\x3C/td>\n\x3C/tr>\n\x3Ctr>\n\x3Ctd>lang 속성\x3C/td>\n\x3Ctd>HTML lang 속성 선언 및 적합한 언어 코드 여부\x3C/td>\n\x3C/tr>\n\x3Ctr>\n\x3Ctd>H1 헤딩\x3C/td>\n\x3Ctd>존재 여부, 페이지당 단일 H1 여부\x3C/td>\n\x3C/tr>\n\x3Ctr>\n\x3Ctd>H2~H6 계층\x3C/td>\n\x3Ctd>헤딩 단계 건너뜀 여부, 전반적 계층 논리성\x3C/td>\n\x3C/tr>\n\x3Ctr>\n\x3Ctd>og:title\x3C/td>\n\x3Ctd>Open Graph 제목 태그 존재 및 내용 유효성\x3C/td>\n\x3C/tr>\n\x3Ctr>\n\x3Ctd>og:description\x3C/td>\n\x3Ctd>Open Graph 설명 태그 존재 및 내용 유효성\x3C/td>\n\x3C/tr>\n\x3Ctr>\n\x3Ctd>og:image\x3C/td>\n\x3Ctd>Open Graph 이미지 태그 존재 및 접근 가능성\x3C/td>\n\x3C/tr>\n\x3Ctr>\n\x3Ctd>og:url\x3C/td>\n\x3Ctd>Open Graph URL과 canonical 일치 여부\x3C/td>\n\x3C/tr>\n\x3Ctr>\n\x3Ctd>JSON-LD\x3C/td>\n\x3Ctd>구조화데이터 존재 여부, 사용된 schema.org 타입\x3C/td>\n\x3C/tr>\n\x3Ctr>\n\x3Ctd>canonical\x3C/td>\n\x3Ctd>canonical 태그 존재 및 유효성\x3C/td>\n\x3C/tr>\n\x3Ctr>\n\x3Ctd>robots.txt\x3C/td>\n\x3Ctd>존재 여부, User-agent/Disallow 파싱, Sitemap 명시 여부\x3C/td>\n\x3C/tr>\n\x3Ctr>\n\x3Ctd>sitemap.xml\x3C/td>\n\x3Ctd>존재 여부, URL 수, lastmod 유효성\x3C/td>\n\x3C/tr>\n\x3C/tbody>\x3C/table>\n\x3Cp>이 14개 항목 중 어떤 것은 '있다/없다'로 단순하게 판정되지만, 어떤 것은 내용의 품질까지 봐야 한다. 예를 들어 title이 있어도 30자 미만이면 너무 짧을 수 있고, og:image가 있어도 해당 URL이 404를 반환하면 아무 의미가 없다.\x3C/p>\n\x3Cp>ViewCheck의 다중 페이지 분석 원칙에 따라, 이 항목들은 사이트의 여러 페이지에 걸쳐 수집된다. 그리고 결과는 두 가지 방식으로 집계된다. 하나는 사이트 전체의 커버리지(예: "140개 크롤링 페이지 중 OG 태그가 있는 페이지 비율"), 다른 하나는 개별 페이지별 상세 현황이다. 전자는 사이트 전반의 SEO 건강도를 보는 데, 후자는 어떤 페이지부터 고쳐야 하는지를 잡는 데 쓴다.\x3C/p>\n\x3Cfigure>\x3Cimg src=\"https://xbbhievqdmccsexxrdtn.supabase.co/storage/v1/object/sign/covers/content/wrou1pxk-584424.jpg?token=eyJraWQiOiJzdG9yYWdlLXVybC1zaWduaW5nLWtleV8yOWQwYWZmNy1mOWJhLTRkNmUtYmZlZi0yMzg2NTc0ZWUzODQiLCJhbGciOiJIUzI1NiJ9.eyJ1cmwiOiJjb3ZlcnMvY29udGVudC93cm91MXB4ay01ODQ0MjQuanBnIiwic2NvcGUiOiJkb3dubG9hZCIsImlhdCI6MTc4NDUwNjIyNiwiZXhwIjoyMDk5ODY2MjI2fQ.uKI1-lHHhtePEEyzMeLui71IHb-54L4nLoOZD2IvRB4\" alt=\"ViewCheck LLM 분석에서 공공 사이트의 SEO 상세 진단 결과가 항목별로 표시된 실제 프로덕션 화면 캡처.\" loading=\"lazy\" />\x3Cfigcaption>ViewCheck LLM 분석의 SEO 상세 화면. 메타태그·OG 태그·구조화데이터·헤딩 계층 등 14종 항목이 페이지별로 정리되어 보인다. — 실제 분석 화면\x3C/figcaption>\x3C/figure>\x3Chr>\n\x3Ch2>다중 페이지 SEO의 의미 — 메인만 보면 보이지 않는 것들\x3C/h2>\n\x3Cp>SEO 진단에서 '다중 페이지'를 기본으로 하는 게 왜 중요한지를 조금 더 구체적으로 이야기해보자.\x3C/p>\n\x3Cp>단일 페이지(메인 페이지) SEO 진단의 한계는 명확하다. 메인 페이지는 대개 가장 공들여 만들어진 페이지다. title도 있고, description도 있고, OG 태그도 있을 가능성이 높다. 그런데 실제로 시민이 검색해서 찾아야 하는 정보는 하위 페이지에 있다. 보도자료, 사업 공지, FAQ, 신청 안내 페이지 같은 것들이다.\x3C/p>\n\x3Cp>우리가 여러 공공 사이트를 분석하면서 반복적으로 확인한 패턴이 있다. 메인 페이지의 SEO 요소는 어느 정도 갖춰져 있는데, 하위 페이지로 들어갈수록 상황이 달라진다.\x3C/p>\n\x3Cp>예를 들어 공지사항 목록 페이지(예: \x3Ccode>/notice/list\x3C/code>)는 페이지마다 title이 바뀌어야 하지 않나 싶지만, 실제로는 "공지사항 — ○○기관"으로 고정된 경우가 많다. 1페이지든 10페이지든 같은 title이다. 검색엔진 입장에서는 같은 이름의 페이지가 수십 개 있는 것처럼 보인다.\x3C/p>\n\x3Cp>개별 공지 상세 페이지(예: \x3Ccode>/notice/view/12345\x3C/code>)는 각 공지의 제목이 title에 반영되면 좋은데, 그냥 "공지사항 상세 — ○○기관"이 고정으로 박혀 있는 경우도 흔하다. 그 공지의 내용이 아무리 중요해도, 검색엔진이 그 페이지를 '공지사항 상세'라는 이름의 수천 개 중 하나로만 인식한다.\x3C/p>\n\x3Cp>사업 신청 안내 페이지는 내용이 중요한 만큼 SEO도 중요한데, 같은 내용이 여러 URL에서 접근 가능하거나(카테고리 경로가 달라지는 경우), canonical이 없거나, 구조화데이터가 없는 경우가 대부분이다.\x3C/p>\n\x3Cp>ViewCheck의 다중 페이지 분석은 이런 패턴을 사이트 전체 수준에서 볼 수 있게 해준다. "이 사이트에서 title이 중복된 페이지가 몇 %인가", "OG 태그가 없는 페이지 유형은 주로 어떤 유형인가", "구조화데이터가 한 페이지에도 없는가, 아니면 특정 유형 페이지에만 없는가" 같은 질문에 답할 수 있게 된다. 이게 '다음에 무엇을 고쳐야 하는가'의 우선순위를 잡는 데 핵심이다.\x3C/p>\n\x3Chr>\n\x3Ch2>공공웹 SEO의 특수성 — 민간 SEO와 다른 것들\x3C/h2>\n\x3Cp>여기서 한 번 멈추고 생각해야 할 것이 있다. 공공 웹의 SEO는 민간 웹사이트의 SEO와 목표가 다르다. 그 차이를 무시하고 민간 SEO 기법을 그대로 적용하면 미스핏이 생긴다.\x3C/p>\n\x3Cp>민간 SEO의 핵심 목표는 대개 \x3Cstrong>트래픽 증가와 전환율 향상\x3C/strong>이다. 더 많은 사람이 방문해서 물건을 사거나 서비스에 가입하게 만드는 것. 키워드 경쟁, 백링크 확보, 콘텐츠 마케팅 등이 주요 전술이다.\x3C/p>\n\x3Cp>공공 웹의 SEO 목표는 다르다. \x3Cstrong>공식 정보에 대한 접근성 보장\x3C/strong>이 핵심이다. 시민이 필요한 정보를 검색했을 때 공식 출처 페이지를 쉽게 찾을 수 있어야 한다. 트래픽 수를 극대화하는 게 아니라, '이 정보가 필요한 사람이 이 페이지를 찾을 수 있는가'가 기준이다.\x3C/p>\n\x3Cp>이 차이에서 오는 몇 가지 실용적 함의가 있다.\x3C/p>\n\x3Cp>\x3Cstrong>키워드 전략\x3C/strong>: 민간은 검색량이 많은 '경쟁 키워드'를 노리지만, 공공은 서비스와 직결된 '정확한 행정 키워드'를 사용해야 한다. "청년 전월세 지원금 신청" 같은 구체적 키워드가 메타 태그와 제목에 자연스럽게 담겨야 한다.\x3C/p>\n\x3Cp>\x3Cstrong>콘텐츠 중복\x3C/strong>: 민간에서는 중복 콘텐츠를 피하는 것이 SEO에 중요하다. 공공에서는 동일한 정보가 여러 부처, 여러 기관에서 각자의 웹사이트에 올라오는 경우가 많다. 이때 출처 명시와 canonical 관리가 더 중요해진다.\x3C/p>\n\x3Cp>\x3Cstrong>권위(Authority)\x3C/strong>: 공공기관은 본래 높은 도메인 권위를 가질 수 있다. .go.kr 도메인은 정부기관임을 나타내는 신뢰 신호다. Google의 E-E-A-T(Experience, Expertise, Authoritativeness, Trustworthiness) 기준에서 공공기관은 특정 주제(행정, 복지, 법령 등)에서 권위 있는 출처다. 이 권위를 제대로 활용하려면, 구조화데이터와 메타 태그가 제대로 갖춰져야 한다.\x3C/p>\n\x3Cp>\x3Cstrong>대량의 정형화된 콘텐츠\x3C/strong>: 공공 사이트에는 공지사항, 보도자료, 법령, 고시 같은 정형화된 대량의 콘텐츠가 있다. 이런 경우에는 동적으로 생성되는 페이지들에 SEO 요소(title, description, 구조화데이터)를 CMS 차원에서 자동 생성하는 전략이 필요하다. 담당자가 수동으로 5천 개 공지의 meta description을 작성하는 건 현실적으로 불가능하다.\x3C/p>\n\x3Cp>ViewCheck의 SEO 진단은 이런 공공 웹의 특성을 고려해서 설계됐다. 단순히 "이 기술적 항목이 있는가 없는가"를 넘어서, "이 사이트의 콘텐츠 유형과 규모를 고려할 때 개선 방향이 무엇인가"까지 제시하려고 한다. 아직 완전히 만족스러운 수준은 아니고, 더 발전시켜야 할 부분이 많다.\x3C/p>\n\x3Chr>\n\x3Ch2>SEO 진단과 KRDS 846규칙의 관계\x3C/h2>\n\x3Cp>ViewCheck의 SEO 진단은 KRDS 846규칙 판정과 어떻게 관계하는지도 짚을 필요가 있다.\x3C/p>\n\x3Cp>KRDS(KoRea Design System)는 기본적으로 \x3Cstrong>UI/UX 디자인 시스템\x3C/strong>이다. 색상, 타이포그래피, 컴포넌트, 패턴 같은 시각적·구조적 설계 기준을 담고 있다. SEO 자체가 KRDS의 핵심 영역은 아니다.\x3C/p>\n\x3Cp>그렇다면 ViewCheck가 SEO를 진단하는 근거는 무엇인가. 행안부 「전자정부 웹사이트 품질관리 지침」 7대 품질 영역 중 \x3Cstrong>개방성\x3C/strong>이 그 근거다. 개방성은 "정보의 공개와 공유를 위한 기반"으로, robots.txt, 메타데이터, 크롤링 허용 등을 포함한다. SEO의 기초 요소들이 개방성 영역에 직접 포함되는 것이다.\x3C/p>\n\x3Cp>KRDS 846규칙 중에는 SEO와 직접 관련된 카테고리가 있다. 예를 들어 메타 태그 구조, 헤딩 구조, canonical URL 같은 요소들은 HTML 구조 차원에서 접근성(CP 규칙)과도 겹치는 부분이 있다. 접근성 기준에서 "페이지 제목이 명확해야 한다(WCAG 2.4.2)"는 요건은 SEO의 "title 태그가 각 페이지를 명확히 설명해야 한다"는 요건과 본질적으로 같은 방향을 가리킨다.\x3C/p>\n\x3Cp>구조화데이터(JSON-LD)는 KRDS 846규칙의 직접 판정 항목은 아니다. 그러나 ViewCheck의 24기능 중 \x3Cstrong>SEO 카드\x3C/strong>가 이 구조화데이터를 포함해서 SEO 관련 항목 전체를 다루고, 이 SEO 카드가 7대 품질 중 개방성 영역의 점수에 기여한다.\x3C/p>\n\x3Cp>즉, KRDS 846규칙 판정이 KRDS 디자인 준수를 확인한다면, SEO 진단은 그와 상호보완적으로 공공 웹의 '정보 개방성'을 확인하는 역할을 한다. 두 축이 합쳐져서 공공 웹의 품질을 더 입체적으로 파악할 수 있게 된다.\x3C/p>\n\x3Cfigure>\x3Cimg src=\"https://xbbhievqdmccsexxrdtn.supabase.co/storage/v1/object/sign/covers/content/vlck1985-104257.jpg?token=eyJraWQiOiJzdG9yYWdlLXVybC1zaWduaW5nLWtleV8yOWQwYWZmNy1mOWJhLTRkNmUtYmZlZi0yMzg2NTc0ZWUzODQiLCJhbGciOiJIUzI1NiJ9.eyJ1cmwiOiJjb3ZlcnMvY29udGVudC92bGNrMTk4NS0xMDQyNTcuanBnIiwic2NvcGUiOiJkb3dubG9hZCIsImlhdCI6MTc4NDUwNjIyNSwiZXhwIjoyMDk5ODY2MjI1fQ.-UfO9YY3v3gNxO5LqNSwShbK7RuRQuhF05bw-WSM-8E\" alt=\"노트북으로 메타 정보 체크리스트를 검토하는 한국인 콘텐츠 매니저의 모습.\" loading=\"lazy\" />\x3Cfigcaption>SEO 점검은 KRDS 준수 판정과 별개가 아니다 — 공공 웹 품질의 두 축이 함께 맞물린다.\x3C/figcaption>\x3C/figure>\x3Chr>\n\x3Ch2>진단의 어려운 점 — 우리가 아직 풀지 못한 것들\x3C/h2>\n\x3Cp>지금까지 ViewCheck가 SEO를 어떻게 진단하는지를 설명했는데, 솔직하게 "이건 아직 어렵다"는 부분도 적어두고 싶다.\x3C/p>\n\x3Cp>\x3Cstrong>동적 생성 콘텐츠의 meta 판정\x3C/strong>: 많은 공공 사이트가 JavaScript로 콘텐츠를 동적으로 생성한다. 특히 React나 Vue 같은 프레임워크를 쓰는 경우, 서버에서 HTML을 내려주는 시점에는 meta 태그가 비어 있고, JavaScript가 실행된 후에야 채워진다. Playwright 기반 크롤링은 실제 브라우저를 띄우기 때문에 이 경우도 대응할 수 있지만, 자바스크립트 실행 타이밍이나 SSR/CSR 방식에 따라 수집 결과가 달라질 수 있다.\x3C/p>\n\x3Cp>\x3Cstrong>meta description 품질 판정\x3C/strong>: description이 '있다'는 건 자동으로 확인할 수 있다. 그런데 "이 description이 페이지 내용을 잘 요약하고 있는가"라는 품질 판단은 다르다. 단순히 길이만 보거나, 특정 키워드 존재 여부만 보는 것은 한계가 있다. 내용의 적절성을 AI로 평가하는 방향도 연구하고 있지만, 이게 정확한 판정인지는 아직 불확실하다.\x3C/p>\n\x3Cp>\x3Cstrong>대형 사이트의 페이지 커버리지\x3C/strong>: 콘텐츠 수천~수만 개를 가진 대형 공공 포털을 분석할 때, 모든 페이지를 크롤링하는 건 시간과 자원 면에서 한계가 있다. 어떤 페이지를 샘플링해서 보느냐에 따라 결과가 달라질 수 있다. 다양한 페이지 유형을 골고루 수집하는 샘플링 전략이 필요하고, 이 부분은 계속 개선하고 있다.\x3C/p>\n\x3Cp>\x3Cstrong>OG 이미지의 적절성\x3C/strong>: og:image가 있고 해당 URL이 접근 가능하다는 건 확인할 수 있다. 그런데 그 이미지가 "소셜 공유 시 눈에 띄고 클릭을 유도하는" 이미지인지, 아니면 300×200 픽셀짜리 흐릿한 로고인지는 다르다. 이미지의 품질과 적절성을 자동으로 판정하는 건 여전히 어려운 문제다.\x3C/p>\n\x3Cp>\x3Cstrong>JSON-LD 내용의 정확성\x3C/strong>: 구조화데이터가 있는지, 어떤 타입인지는 파악할 수 있다. 그런데 그 안의 속성 값들이 실제 페이지 내용과 일치하는지는 더 깊이 들여다봐야 한다. name, url, logo 같은 필드들이 실제로 유효한지, 오래된 정보가 아닌지 같은 것들이다. 이 부분은 앞으로 더 정교화할 계획이다.\x3C/p>\n\x3Cp>이 한계들을 솔직하게 적는 이유는, "ViewCheck가 SEO 진단을 완벽하게 한다"는 인상을 주고 싶지 않기 때문이다. 우리는 공공 웹의 SEO 기초 요소들을 체계적으로 수집하고 정리해서, 담당자가 어디부터 봐야 할지를 빠르게 파악하도록 돕는 것을 목표로 한다. 그 목표는 어느 정도 달성하고 있지만, 판정의 깊이와 정확도는 계속 더 나아가야 할 여정이다.\x3C/p>\n\x3Chr>\n\x3Ch2>실제 분석에서 자주 보이는 패턴 — 유형별 공통 문제\x3C/h2>\n\x3Cp>ViewCheck로 여러 공공 사이트를 분석하면서 반복적으로 보이는 패턴들을 유형별로 정리해본다. 물론 이건 우리가 분석한 사례에서 관찰한 것이며, 모든 공공 사이트가 이렇다고 일반화할 수는 없다.\x3C/p>\n\x3Cp>\x3Cstrong>광역지자체 대형 포털 유형\x3C/strong>\x3C/p>\n\x3Cp>보통 메인 페이지는 비교적 잘 관리되어 있다. title, description, OG 태그 다 있다. 그런데 포털 하위에 여러 부서별 미니 사이트가 붙어 있는 구조에서, 각 미니 사이트의 SEO 관리 수준이 들쭉날쭉하다. 어떤 부서 사이트는 잘 되어 있고, 어떤 부서 사이트는 title이 "○○시청 - 홈" 하나로 고정이다. 조직 구조가 사이트 SEO 편차로 그대로 드러나는 경우다.\x3C/p>\n\x3Cp>\x3Cstrong>중소 기초지자체 유형\x3C/strong>\x3C/p>\n\x3Cp>외주 개발로 만들어진 사이트가 많고, 개발 당시의 기본 SEO 설정이 그대로 유지되거나 방치되어 있다. robots.txt가 없거나, 기본 템플릿의 robots.txt가 그대로인 경우가 많다. sitemap도 없거나 오래된 URL만 담겨 있다. 구조화데이터는 거의 없다.\x3C/p>\n\x3Cp>\x3Cstrong>공공기관 전문 포털 유형\x3C/strong>\x3C/p>\n\x3Cp>특정 분야(교육, 의료, 복지 등)의 전문 포털은 콘텐츠 수가 방대하다. 이 경우 개별 콘텐츠 페이지의 SEO 요소가 CMS에서 자동 생성되는 구조이면 비교적 일관되게 관리되고 있지만, CMS가 오래되었거나 SEO를 고려하지 않고 만들어진 경우에는 수천 개 페이지 모두 같은 title, 같은 description이다.\x3C/p>\n\x3Cp>\x3Cstrong>정부 전문 사이트 유형\x3C/strong>\x3C/p>\n\x3Cp>법령, 고시, 통계 같은 데이터가 주인 사이트들은 URL 구조가 복잡하고, 같은 콘텐츠가 여러 URL로 접근 가능한 경우가 많다. canonical 관리가 특히 중요하지만, 대부분 canonical 태그가 없거나 체계적으로 관리되지 않는다. 구조화데이터 측면에서는 Dataset 타입을 활용하면 Google Datasets 검색에 노출될 수 있는 잠재력이 있는데, 활용되는 경우가 거의 없다.\x3C/p>\n\x3Cp>이 패턴들이 특별히 새롭거나 충격적인 발견은 아니다. SEO 전문가라면 "공공 사이트가 그 정도지"라고 할 수도 있다. 우리가 이 관찰에서 갖게 된 물음은 다른 것이다. "이 상태를 체계적으로 파악하고, 우선순위를 잡고, 개선 방향을 제시하는 과정을 어떻게 단순하게 만들 수 있는가."\x3C/p>\n\x3Chr>\n\x3Ch2>검색엔진과 소셜의 교차점 — 통합 시각의 중요성\x3C/h2>\n\x3Cp>메타 태그, OG 태그, JSON-LD, 헤딩 구조, canonical, robots.txt, sitemap. 이 요소들을 각각 따로 떼어 보면 기술적 체크리스트처럼 보인다. 그런데 이들이 실제로 어떻게 맞물려 작동하는지를 보면, 하나가 빠졌을 때 나머지에 미치는 영향을 알게 된다.\x3C/p>\n\x3Cp>예를 들어 JSON-LD를 제대로 삽입했는데 robots.txt로 해당 페이지 크롤링이 차단되어 있다면, Googlebot이 그 JSON-LD를 읽지 못하고 구조화데이터 효과가 없다. sitemap에 올라간 URL이 canonical과 다르다면, sitemap이 있어도 색인이 분산된다. og:url과 canonical이 다르면, 소셜에서 공유된 페이지가 검색엔진의 canonical 페이지와 달라진다.\x3C/p>\n\x3Cp>이 상호작용을 제대로 파악하려면 요소들을 개별로 보는 것이 아니라, \x3Cstrong>통합적으로\x3C/strong> 봐야 한다. ViewCheck의 SEO 진단이 단일 항목 체크리스트가 아니라, 여러 요소의 상태를 함께 수집해서 교차 확인하는 방향으로 설계된 이유가 여기에 있다.\x3C/p>\n\x3Cp>예를 들어 robots.txt에서 Disallow된 경로가 sitemap에도 포함되어 있다면, 그건 설정 충돌이다. 검색엔진에게 "오지 마라"고 하면서 동시에 "이 URL 있다"고 알려주는 모순이다. 이런 충돌을 잡아내려면 robots.txt와 sitemap.xml을 함께 분석해야 한다.\x3C/p>\n\x3Cp>또는 OG 태그가 잘 설정되어 있는데 og:image의 URL이 robots.txt에서 차단된 경로에 있다면, 소셜 미디어 봇이 그 이미지를 가져가지 못한다. 이미지 미리보기가 안 뜨는 것이다.\x3C/p>\n\x3Cp>이런 교차 확인이 "기초는 다 있는데 왜 안 되지?"라는 상황의 원인을 찾는 데 도움이 된다. 우리가 ViewCheck의 SEO 진단에서 이 교차 확인을 얼마나 잘 구현하고 있는지는, 솔직히 아직 개선할 여지가 있다. 각 항목은 잘 잡히는데, 항목 간 상호관계를 자동으로 진단하는 부분은 더 발전시켜야 하는 영역이다.\x3C/p>\n\x3Chr>\n\x3Ch2>SEO 진단 결과를 어떻게 쓸 것인가 — 담당자 시각\x3C/h2>\n\x3Cp>기술적인 이야기를 많이 했는데, 마지막에는 "이 진단 결과를 받아 든 담당자가 실제로 무엇을 해야 하는가"로 돌아가고 싶다.\x3C/p>\n\x3Cp>SEO 진단 결과를 받았다고 해서 즉시 수천 개 페이지의 meta description을 다 고칠 수는 없다. 현실적인 접근이 필요하다.\x3C/p>\n\x3Cp>\x3Cstrong>첫 번째 우선순위: 기술적 차단 요소 제거\x3C/strong>\x3C/p>\n\x3Cp>robots.txt 설정 오류, sitemap 부재, canonical 충돌처럼 검색엔진이 사이트를 제대로 인식하지 못하게 막는 요소를 먼저 제거해야 한다. 이건 CMS나 서버 설정을 바꾸는 일이라 개발팀 협조가 필요하지만, 한 번 고치면 사이트 전체에 영향을 미친다.\x3C/p>\n\x3Cp>\x3Cstrong>두 번째 우선순위: 핵심 페이지의 SEO 요소 확보\x3C/strong>\x3C/p>\n\x3Cp>메인 페이지, 주요 서비스 안내 페이지, 검색량이 많을 것으로 예상되는 핵심 콘텐츠 페이지에 title, description, OG 태그를 제대로 갖추는 것이다. 전체 사이트를 한 번에 다 고치는 건 어렵지만, 핵심 페이지부터 챙기면 효과가 빠르다.\x3C/p>\n\x3Cp>\x3Cstrong>세 번째 우선순위: CMS 차원의 자동화\x3C/strong>\x3C/p>\n\x3Cp>수백~수천 개 이상의 페이지가 있는 사이트라면, 개별 페이지마다 SEO 요소를 수동으로 관리하는 건 불가능하다. CMS나 템플릿 차원에서 "공지사항 상세 페이지의 title은 '공지 제목 — 사이트명' 형식으로 자동 생성"하는 방식을 개발 단계에서 설정해 두어야 한다. 이미 운영 중인 사이트라면 재개발 없이 적용하기 어려운 경우도 있는데, 이건 확인이 필요한 부분이다.\x3C/p>\n\x3Cp>\x3Cstrong>네 번째 우선순위: 구조화데이터 단계적 도입\x3C/strong>\x3C/p>\n\x3Cp>JSON-LD는 기존 HTML을 건드리지 않고 \x3Ccode><script>\x3C/code> 블록을 추가하는 방식이라 비교적 도입이 쉬운 편이다. 사이트 전체를 한 번에 하기보다, Organization 타입부터 시작해서 주요 콘텐츠 유형(FAQPage, Event, NewsArticle)을 순서대로 추가하는 단계적 접근이 현실적이다.\x3C/p>\n\x3Cp>ViewCheck의 SEO 진단 결과는 이 우선순위 설정을 돕는 방식으로 제공된다. 어떤 항목이 빠져 있는지뿐 아니라, 어떤 유형의 페이지에서 어떤 문제가 얼마나 광범위하게 나타나는지를 함께 보여줘서, "어디부터 손댈 것인가"를 잡을 수 있게 한다. 물론 그 다음 실제 수정 작업은 담당자와 개발팀의 몫이다. 우리가 할 수 있는 건 "어디를 봐야 하는지"를 빠르고 체계적으로 짚어주는 것까지다.\x3C/p>\n\x3Cfigure>\x3Cimg src=\"https://xbbhievqdmccsexxrdtn.supabase.co/storage/v1/object/sign/covers/content/8gbl7iq8-113232.jpg?token=eyJraWQiOiJzdG9yYWdlLXVybC1zaWduaW5nLWtleV8yOWQwYWZmNy1mOWJhLTRkNmUtYmZlZi0yMzg2NTc0ZWUzODQiLCJhbGciOiJIUzI1NiJ9.eyJ1cmwiOiJjb3ZlcnMvY29udGVudC84Z2JsN2lxOC0xMTMyMzIuanBnIiwic2NvcGUiOiJkb3dubG9hZCIsImlhdCI6MTc4NDUwNjIyNiwiZXhwIjoyMDk5ODY2MjI2fQ.cm5ldDaAfIVDS1Gn-T9nSDeX9eVL2sUyzVGIcEneNoY\" alt=\"책상에서 동료와 함께 검색 노출 전략에 대해 이야기하는 한국인 마케터의 모습.\" loading=\"lazy\" />\x3Cfigcaption>진단 결과를 받은 다음이 시작이다 — 우선순위를 잡고, 팀과 논의하고, 한 걸음씩.\x3C/figcaption>\x3C/figure>\x3Chr>\n\x3Ch2>공공웹 SEO와 접근성의 겹치는 지점\x3C/h2>\n\x3Cp>SEO와 접근성(Accessibility)은 겉으로는 다른 것처럼 보이지만, 기술적 기반에서 많이 겹친다. 이 겹침이 공공 웹에서 특히 중요하다.\x3C/p>\n\x3Cp>WCAG(Web Content Accessibility Guidelines) 2.4.2는 "웹 페이지는 주제나 목적을 설명하는 제목을 가져야 한다"고 요구한다. 이건 SEO에서 title 태그를 각 페이지 내용에 맞게 고유하게 작성해야 한다는 요건과 정확히 겹친다. 접근성을 위해 title을 잘 쓰면 SEO에도 좋고, SEO를 위해 title을 잘 쓰면 접근성에도 좋다.\x3C/p>\n\x3Cp>헤딩 구조도 마찬가지다. WCAG 1.3.1은 "정보, 구조, 관계가 시각적 표현 이외에 프로그래밍 방식으로도 확인 가능하거나 텍스트로 제공되어야 한다"고 하는데, 올바른 헤딩 계층이 이 기준을 충족하는 핵심 방법이다. 스크린 리더 사용자를 위한 논리적 헤딩 구조는 검색엔진의 콘텐츠 이해도 돕는다.\x3C/p>\n\x3Cp>lang 속성도 그렇다. KWCAG 2.2에서 요구하는 언어 선언은 스크린 리더가 올바른 언어로 읽기 위해 필요한 것이고, 동시에 검색엔진이 페이지 언어를 인식해 적절한 국가·언어권 사용자에게 노출하는 데도 쓰인다.\x3C/p>\n\x3Cp>이 겹침은 "SEO와 접근성을 따로 챙겨야 하는 두 가지 과제"가 아니라, "기초를 제대로 갖추면 두 가지가 동시에 개선되는" 효율적인 접근이 가능함을 의미한다. 실제로 ViewCheck의 KRDS 846규칙 판정(접근성 관련 CP 규칙 포함)과 SEO 진단은 서로 보완하며, 중복되는 기초 요소들을 함께 본다.\x3C/p>\n\x3Cp>공공 웹의 품질 관리 담당자가 KRDS 준수와 SEO를 "두 개의 별개 프로젝트"로 접근하면 자원이 두 배로 든다. "기초 HTML 구조를 제대로 갖추면 KRDS 접근성과 SEO가 동시에 개선된다"는 시각으로 접근하면 더 효율적이다. ViewCheck가 846규칙 판정과 SEO 진단을 같은 분석 흐름 안에서 통합적으로 제공하는 이유가 이것이다.\x3C/p>\n\x3Chr>\n\x3Ch2>Twitter Card와 추가 메타데이터\x3C/h2>\n\x3Cp>Open Graph 태그가 페이스북, 카카오 계열에서 주로 쓰인다면, \x3Cstrong>Twitter Card 태그\x3C/strong>는 X(구 트위터)에서 링크 미리보기를 제어한다. 기본 형식은 이렇다.\x3C/p>\n\x3Cpre>\x3Ccode class=\"language-html\"><meta name="twitter:card" content="summary_large_image" />\n<meta name="twitter:title" content="페이지 제목" />\n<meta name="twitter:description" content="요약 설명" />\n<meta name="twitter:image" content="https://example.go.kr/images/thumb.jpg" />\n\x3C/code>\x3C/pre>\n\x3Cp>Twitter Card가 없으면 X에서 링크를 공유했을 때 미리보기가 제대로 뜨지 않는다. 대신 OG 태그가 있으면 X가 이를 fallback으로 활용하기도 하지만, 완전하지 않을 수 있다.\x3C/p>\n\x3Cp>공공 사이트에서 Twitter Card 태그는 OG 태그보다도 누락 비율이 높다. 실제로 카카오나 네이버 중심인 국내 소통 채널을 생각하면 OG 태그의 우선순위가 높지만, X를 공식 채널로 운영하는 기관에서는 Twitter Card 태그도 필요하다.\x3C/p>\n\x3Cp>ViewCheck SEO 진단에서 Twitter Card 태그는 OG 태그와 함께 수집하고 점검한다. 두 태그가 모두 있는 경우, 없는 경우, OG만 있고 Twitter Card는 없는 경우를 구분해서 보여준다.\x3C/p>\n\x3Cp>또 한 가지 언급할 만한 것이 \x3Cstrong>hreflang 태그\x3C/strong>다. 이중 언어 사이트(예: 외국인 대상 서비스 안내를 영어로도 제공하는 경우)에서, 어떤 언어 버전이 어떤 언어 사용자에게 표시되어야 하는지를 알려주는 태그다. 국제화를 고려한 공공 사이트에서 필요한 요소인데, 이 부분은 ViewCheck가 현재 검토하고 있는 확장 영역 중 하나다. 아직 완전히 구현된 건 아니고, 다국어 공공 사이트가 늘어남에 따라 중요도가 높아질 것으로 보인다.\x3C/p>\n\x3Chr>\n\x3Ch2>검색엔진 색인 확인 — 분석 이후의 후속 단계\x3C/h2>\n\x3Cp>SEO 진단을 해서 문제점을 파악하고 개선했다면, 그 다음은 "개선이 실제로 반영됐는가"를 확인하는 단계다.\x3C/p>\n\x3Cp>가장 직접적인 방법은 \x3Cstrong>Google Search Console\x3C/strong>이나 \x3Cstrong>네이버 서치어드바이저\x3C/strong>를 활용하는 것이다. 이 도구들은 검색엔진이 실제로 사이트의 어떤 URL을 색인하고 있는지, 어떤 키워드로 노출되는지, 클릭률은 어떤지를 보여준다.\x3C/p>\n\x3Cp>sitemap.xml을 제출하면 더 빠르고 체계적인 색인이 이뤄진다. 특히 새로운 콘텐츠가 자주 올라오는 사이트에서는 sitemap을 최신 상태로 유지하고 주기적으로 재제출하는 것이 중요하다.\x3C/p>\n\x3Cp>ViewCheck는 현재 Google Search Console이나 네이버 서치어드바이저와 직접 연동하지는 않는다. 실제 색인 상태나 키워드 성과 데이터는 이 도구들에서 직접 확인해야 한다. ViewCheck의 SEO 진단은 "페이지에 SEO 요소가 제대로 갖춰져 있는가"를 확인하는 쪽이고, "그 결과로 검색 순위가 어떻게 되는가"는 서치 콘솔 같은 별도 도구가 담당하는 영역이다.\x3C/p>\n\x3Cp>이건 의도적인 역할 분리다. ViewCheck는 페이지 자체의 기술적 기초를 확인하고, 서치 콘솔은 검색엔진과의 실제 상호작용 결과를 보여준다. 두 도구를 함께 쓰면 "문제가 어디에 있는가"와 "그게 검색 결과에 어떻게 영향 미쳤는가"를 모두 파악할 수 있다.\x3C/p>\n\x3Chr>\n\x3Ch2>앞으로의 방향 — SEO 진단 고도화 계획\x3C/h2>\n\x3Cp>솔직히 말하면, ViewCheck의 SEO 진단은 아직 계속 발전하는 중이다. 현재까지 구현된 것들과 앞으로 더 발전시키려는 방향을 간략히 정리해보자.\x3C/p>\n\x3Cp>\x3Cstrong>현재 구현된 것\x3C/strong>:\x3C/p>\n\x3Cul>\n\x3Cli>14종 SEO 항목 페이지별 수집 및 판정\x3C/li>\n\x3Cli>robots.txt 파싱(User-agent, Disallow, Sitemap 지시어)\x3C/li>\n\x3Cli>sitemap.xml 파싱(URL 수, lastmod 유효성)\x3C/li>\n\x3Cli>OG 태그 4종 + Twitter Card 수집\x3C/li>\n\x3Cli>JSON-LD 존재 여부 및 schema.org 타입 식별\x3C/li>\n\x3Cli>헤딩 H1~H6 구조 분석\x3C/li>\n\x3Cli>canonical 태그 수집 및 OG:url과의 일치 확인\x3C/li>\n\x3Cli>다중 페이지 전체 커버리지 집계\x3C/li>\n\x3C/ul>\n\x3Cp>\x3Cstrong>개선 중인 것\x3C/strong>:\x3C/p>\n\x3Cul>\n\x3Cli>JSON-LD 내용 검증(필수 속성 누락 여부, Google Rich Result Test 기준)\x3C/li>\n\x3Cli>robots.txt와 sitemap의 교차 충돌 자동 탐지\x3C/li>\n\x3Cli>구조화데이터 타입별 권장 도입 순위 제안\x3C/li>\n\x3Cli>OG 이미지 크기·접근성 자동 확인\x3C/li>\n\x3Cli>다중 언어 사이트의 hreflang 분석\x3C/li>\n\x3C/ul>\n\x3Cp>\x3Cstrong>장기적으로 탐색 중인 것\x3C/strong>:\x3C/p>\n\x3Cul>\n\x3Cli>meta description 내용 품질의 AI 평가\x3C/li>\n\x3Cli>경쟁 사이트(동급 공공기관) 대비 SEO 현황 벤치마킹\x3C/li>\n\x3Cli>Google Search Console API 연동을 통한 실제 색인·성과 데이터 통합\x3C/li>\n\x3Cli>키워드 수준의 노출 개선 시뮬레이션\x3C/li>\n\x3C/ul>\n\x3Cp>이 중 일부는 꽤 멀리 있는 목표다. 특히 외부 서치 콘솔 데이터와의 연동이나 키워드 벤치마킹은, 사용자 인증과 데이터 연동 설계가 복잡해서 단기간에 넣기 어렵다. 장기 로드맵으로 가지고 있을 뿐이다.\x3C/p>\n\x3Cp>지금 집중하는 건 14종 항목 각각의 판정 정확도를 높이고, 판정 결과를 더 실용적인 방식으로 보여주는 것이다. "이 항목이 미통과"라고 말하는 것에서 나아가, "이 항목이 미통과인 이유가 이것이고, 이렇게 하면 개선된다"는 구체적 안내까지 줄 수 있는 방향으로.\x3C/p>\n\x3Chr>\n\x3Ch2>마무리 — 공공 정보의 발견 가능성을 높이는 작은 시작\x3C/h2>\n\x3Cp>공공 웹의 SEO는 화려하지 않다. 트래픽을 열 배 늘리거나, 키워드 1등을 찍거나, 바이럴 콘텐츠를 만드는 이야기가 아니다. 그보다 훨씬 기초적인 것들이다. title 태그를 각 페이지에 맞게 쓰기, description을 채우기, OG 태그를 달기, JSON-LD 하나 추가하기, robots.txt를 점검하기.\x3C/p>\n\x3Cp>이 기초들이 갖춰지면 어떤 변화가 생기는지 확실하게 말하기는 어렵다. 검색 노출이 곧바로 드라마틱하게 좋아진다고 단언할 수 없다. 다만 우리가 확신하는 것은, 기초가 없으면 아무리 좋은 콘텐츠가 있어도 검색엔진이 그것을 제대로 이해하고 전달할 수 없다는 것이다.\x3C/p>\n\x3Cp>Google Search Central의 공식 문서에 실린 Nestlé 사례처럼, 구조화데이터 하나로 클릭률이 82% 오른 게 꼭 공공 사이트에서도 같은 수치로 재현된다고는 말 못한다. 하지만 "검색엔진에게 더 명확한 정보를 주면, 검색엔진이 더 잘 보여준다"는 원리는 공공이든 민간이든 다르지 않다.\x3C/p>\n\x3Cp>공공 정보가 공식 채널을 통해 시민에게 잘 전달되는 것 — 이건 단순히 홈페이지 방문자 수의 문제가 아니라, 공공 서비스의 본질적인 책무와 연결된 문제라고 우리는 생각한다. 시민이 복지 서비스를 신청하고 싶은데 어디서 찾아야 할지 몰라 비공식 채널을 전전한다면, 그건 콘텐츠가 없어서가 아니라 '찾기 어렵게 만들어져 있어서'다.\x3C/p>\n\x3Cp>ViewCheck의 SEO 진단은 그 '찾기 어렵게 만드는' 기술적 원인을 파악하는 도구다. 아직 완성되지 않았고, 계속 발전 중이다. 하지만 방향은 분명하다 — 공공 정보가 더 잘 발견될 수 있게, 기초부터 체계적으로 점검하는 것.\x3C/p>\n\x3Cp>다음 편에서는 이 시리즈의 또 다른 데이터 주제로 넘어간다. 함께 이어가자.\x3C/p>\n\x3Chr>\n\x3Ch2>참고문헌\x3C/h2>\n\x3Cblockquote>\n\x3Cp>본문에 인용한 출처는 작성 시점에 모두 실재 여부를 검증했다. 국내 공식 기준과 해외 공식 문서를 함께 실었다.\x3C/p>\n\x3C/blockquote>\n\x3Cp>\x3Cstrong>국내 — 공식 기준 / 정책자료\x3C/strong>\x3C/p>\n\x3Col>\n\x3Cli>\x3Cp>행정안전부, 「전자정부 웹사이트 품질관리 지침」(행정안전부고시 제2025-46호, 2025.6.25. 일부개정). 국가법령정보센터. \x3Ca href=\"https://www.law.go.kr/%ED%96%89%EC%A0%95%EA%B7%9C%EC%B9%99/%EC%A0%84%EC%9E%90%EC%A0%95%EB%B6%80%EC%9B%B9%EC%82%AC%EC%9D%B4%ED%8A%B8%ED%92%88%EC%A7%88%EA%B4%80%EB%A6%AC%EC%A7%80%EC%B9%A8\">https://www.law.go.kr/행정규칙/전자정부웹사이트품질관리지침\x3C/a>\x3C/p>\n\x3C/li>\n\x3Cli>\x3Cp>행정안전부, 「전자정부 웹사이트 품질관리 지침」 일부 개정 및 「전자정부 웹사이트 품질관리 가이드」 수정본 안내(고시 제2025-46호). 행정안전부 알립니다. \x3Ca href=\"https://www.mois.go.kr/frt/bbs/type013/commonSelectBoardArticle.do?bbsId=BBSMSTR_000000000006&nttId=118639\">https://www.mois.go.kr/frt/bbs/type013/commonSelectBoardArticle.do?bbsId=BBSMSTR_000000000006&nttId=118639\x3C/a>\x3C/p>\n\x3C/li>\n\x3Cli>\x3Cp>KRDS(범정부 UI/UX 디자인시스템) 공식 사이트 — 디지털 정부서비스 UI/UX 가이드라인. 행정안전부·디지털플랫폼정부위원회. \x3Ca href=\"https://www.krds.go.kr/\">https://www.krds.go.kr/\x3C/a>\x3C/p>\n\x3C/li>\n\x3Cli>\x3Cp>TBWA 데이터랩, "robots.txt 10분 안에 끝내는 총정리 가이드". robots.txt와 공공·기업 사이트의 실수 사례 포함. \x3Ca href=\"https://seo.tbwakorea.com/blog/robots-txt-complete-guide/\">https://seo.tbwakorea.com/blog/robots-txt-complete-guide/\x3C/a>\x3C/p>\n\x3C/li>\n\x3Cli>\x3Cp>어센트 코리아, "Robots.txt와 Sitemap.xml 제대로 설정하기". \x3Ca href=\"https://www.ascentkorea.com/what-is-robots-txt-sitemap-xml/\">https://www.ascentkorea.com/what-is-robots-txt-sitemap-xml/\x3C/a>\x3C/p>\n\x3C/li>\n\x3C/ol>\n\x3Cp>\x3Cstrong>해외 — 공식 표준 / 기술 문서\x3C/strong>\x3C/p>\n\x3Col start=\"6\">\n\x3Cli>\x3Cp>Google Search Central, "SEO Starter Guide: The Basics". Google for Developers. \x3Ca href=\"https://developers.google.com/search/docs/fundamentals/seo-starter-guide\">https://developers.google.com/search/docs/fundamentals/seo-starter-guide\x3C/a>\x3C/p>\n\x3C/li>\n\x3Cli>\x3Cp>Google Search Central, "Intro to How Structured Data Markup Works". Nestlé 82% CTR 사례 포함. Google for Developers. \x3Ca href=\"https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data\">https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data\x3C/a>\x3C/p>\n\x3C/li>\n\x3Cli>\x3Cp>Google Search Central, "How to Write Meta Descriptions". Google for Developers. \x3Ca href=\"https://developers.google.com/search/docs/appearance/snippet\">https://developers.google.com/search/docs/appearance/snippet\x3C/a>\x3C/p>\n\x3C/li>\n\x3Cli>\x3Cp>Google Search Central, "How to Specify a Canonical with rel='canonical' and Other Methods". Google for Developers. \x3Ca href=\"https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls\">https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls\x3C/a>\x3C/p>\n\x3C/li>\n\x3Cli>\x3Cp>Google Search Central, "Create and Submit a robots.txt File". Google for Developers. \x3Ca href=\"https://developers.google.com/crawling/docs/robots-txt/create-robots-txt\">https://developers.google.com/crawling/docs/robots-txt/create-robots-txt\x3C/a>\x3C/p>\n\x3C/li>\n\x3Cli>\x3Cp>The Open Graph protocol (ogp.me). Facebook 2010년 개발, 공식 사양. \x3Ca href=\"https://ogp.me/\">https://ogp.me/\x3C/a>\x3C/p>\n\x3C/li>\n\x3Cli>\x3Cp>schema.org 공식. Google, Microsoft, Yahoo, Yandex 공동 운영 어휘 표준. 823개 타입·1,529개 속성. \x3Ca href=\"https://schema.org/\">https://schema.org/\x3C/a>\x3C/p>\n\x3C/li>\n\x3Cli>\x3Cp>schema.org, Organization 타입 정의. \x3Ca href=\"https://schema.org/Organization\">https://schema.org/Organization\x3C/a>\x3C/p>\n\x3C/li>\n\x3Cli>\x3Cp>W3C WAI, "Meta viewport allows for zoom" — viewport 메타 태그와 접근성 기준(WCAG 연계). \x3Ca href=\"https://www.w3.org/WAI/standards-guidelines/act/rules/b4f0c3/\">https://www.w3.org/WAI/standards-guidelines/act/rules/b4f0c3/\x3C/a>\x3C/p>\n\x3C/li>\n\x3C/ol>\n\x3Chr>\n\x3Cfigure>\x3Cimg src=\"https://xbbhievqdmccsexxrdtn.supabase.co/storage/v1/object/sign/covers/content/rhbo0glv-1187218.png?token=eyJraWQiOiJzdG9yYWdlLXVybC1zaWduaW5nLWtleV8yOWQwYWZmNy1mOWJhLTRkNmUtYmZlZi0yMzg2NTc0ZWUzODQiLCJhbGciOiJIUzI1NiJ9.eyJ1cmwiOiJjb3ZlcnMvY29udGVudC9yaGJvMGdsdi0xMTg3MjE4LnBuZyIsInNjb3BlIjoiZG93bmxvYWQiLCJpYXQiOjE3ODQ1MDYyMjcsImV4cCI6MjA5OTg2NjIyN30.Oi4npVfLaiKUEwS_w5f0kqqcSLpKNKhAJsdom4A8wmU\" alt=\"\" loading=\"lazy\" />\x3C/figure>",isPrivate:!1},related:$R[17]=[$R[18]={id:"viewcheck-llm-분석-리포트-읽는-법-점수-등급-근거-우선순위-해석에서-행동까지",uuid:"6095a7aa-aa0a-4966-a07c-fbee811507da",slug:"viewcheck-llm-분석-리포트-읽는-법-점수-등급-근거-우선순위-해석에서-행동까지",cat:"KRDS · 공공웹 AI 진단연구",category:"ai-diagnostics",title:"ViewCheck LLM 분석 리포트 읽는 법 — 점수·등급·근거·우선순위 해석에서 행동까지",excerpt:"분석이 끝나고 화면에 숫자가 떴다. 종합 74점. KRDS 846규칙 중 289개 통과, 228개 미통과, 329개 해당없음. 접근성 68점. 보안 91점. 위반 매트릭스에는 빨간 칸과 노란 칸이 뒤섞여 있다.\n그런데 막상 이 결과를 받아 든 담당자의 표정이 묘하다. 뭔가 많이 나왔는데, 무엇을 먼저 봐야 할지 모르겠다.",author:"ViewCheck Insight",date:"2026.07.20",read:"5분",views:"47",cover:"https://xbbhievqdmccsexxrdtn.supabase.co/storage/v1/object/sign/covers/content/zrk6opob-816388.png?token=eyJraWQiOiJzdG9yYWdlLXVybC1zaWduaW5nLWtleV8yOWQwYWZmNy1mOWJhLTRkNmUtYmZlZi0yMzg2NTc0ZWUzODQiLCJhbGciOiJIUzI1NiJ9.eyJ1cmwiOiJjb3ZlcnMvY29udGVudC96cms2b3BvYi04MTYzODgucG5nIiwic2NvcGUiOiJkb3dubG9hZCIsImlhdCI6MTc4NDUwNjI4MywiZXhwIjoyMDk5ODY2MjgzfQ.xq4hqoT2raxqfS4v1cWSPhzX5d0LdDpEiUeiiPYx25Q",tags:$R[19]=["LLM분석","ViewCheck","공공웹","KRDS","리포트읽기","웹접근성","디지털정부","품질관리","우선순위","WCAG","심각도","개선로드맵"],sections:$R[20]=[],content:"",isPrivate:!1},$R[21]={id:"ai-진단-어디까지-믿어야-하나-viewcheck를-활용하는-사람을-위한-정직한-가이드",uuid:"986f6075-622e-4243-8b9f-e9877bea4de9",slug:"ai-진단-어디까지-믿어야-하나-viewcheck를-활용하는-사람을-위한-정직한-가이드",cat:"KRDS · 공공웹 AI 진단연구",category:"ai-diagnostics",title:"AI 진단, 어디까지 믿어야 하나 — ViewCheck를 활용하는 사람을 위한 정직한 가이드",excerpt:"2026년 어느 날, 공공기관의 웹 담당자 한 명이 AI 분석 결과를 출력해 상사에게 내밀었다고 상상해 보자. \"AI가 분석했더니 우리 사이트 KRDS 준수율이 68점입니다.\" 상사는 고개를 끄덕이며 \"그럼 개선 계획 짜세요\"라고 했다. 담당자는 돌아가 개발사에 수정 목록을 전달했다. 문제는, 그 68점이 무엇을 근거로 ",author:"ViewCheck Insight",date:"2026.07.20",read:"5분",views:"111",cover:"https://xbbhievqdmccsexxrdtn.supabase.co/storage/v1/object/sign/covers/content/d90vfxv9-793773.png?token=eyJraWQiOiJzdG9yYWdlLXVybC1zaWduaW5nLWtleV8yOWQwYWZmNy1mOWJhLTRkNmUtYmZlZi0yMzg2NTc0ZWUzODQiLCJhbGciOiJIUzI1NiJ9.eyJ1cmwiOiJjb3ZlcnMvY29udGVudC9kOTB2Znh2OS03OTM3NzMucG5nIiwic2NvcGUiOiJkb3dubG9hZCIsImlhdCI6MTc4NDUwNjI4MCwiZXhwIjoyMDk5ODY2MjgwfQ.hbkeVJVvrdl4jBGDteFoQqNHGxQEjLOm_Sur_CpuNPY",tags:$R[22]=["LLM분석","ViewCheck","공공웹","AI신뢰","자동화편향","KRDS","웹접근성","AutomationBias","AI진단","인간감독","디지털정부","웹품질"],sections:$R[23]=[],content:"",isPrivate:!1},$R[24]={id:"분석-개선-재진단-공공웹-품질을-점수로-관리-한다는-것-viewcheck-llm-분석-활용",uuid:"fd8e40ac-1030-40e9-800d-0792f65f2212",slug:"분석-개선-재진단-공공웹-품질을-점수로-관리-한다는-것-viewcheck-llm-분석-활용",cat:"KRDS · 공공웹 AI 진단연구",category:"ai-diagnostics",title:"분석 → 개선 → 재진단, 공공웹 품질을 '점수로 관리'한다는 것 — ViewCheck LLM 분석 활용",excerpt:"공공 웹사이트 품질 진단을 맡은 실무 담당자들과 이야기하다 보면, 어느 지점에서 공통된 표정이 나온다. \"진단은 했어요. 그런데 그다음은 어떻게 해야 하죠?\"\n도구를 돌리면 문제 목록이 나온다. 때로는 수백 개, 때로는 수십 페이지짜리 보고서가 나온다. 그리고 거기서 멈춘다. 문제를 고쳤는지 어떻게 확인하지? 개선 후에 ",author:"ViewCheck Insight",date:"2026.07.20",read:"5분",views:"116",cover:"https://xbbhievqdmccsexxrdtn.supabase.co/storage/v1/object/sign/covers/content/0zb4z4ti-810301.png?token=eyJraWQiOiJzdG9yYWdlLXVybC1zaWduaW5nLWtleV8yOWQwYWZmNy1mOWJhLTRkNmUtYmZlZi0yMzg2NTc0ZWUzODQiLCJhbGciOiJIUzI1NiJ9.eyJ1cmwiOiJjb3ZlcnMvY29udGVudC8wemI0ejR0aS04MTAzMDEucG5nIiwic2NvcGUiOiJkb3dubG9hZCIsImlhdCI6MTc4NDUwNjI3NiwiZXhwIjoyMDk5ODY2Mjc2fQ.HABSrPMbnC0qGzLzurWelDQroorfi6YihX8pcBcgWns",tags:$R[25]=["LLM분석","ViewCheck","공공웹","KRDS","재진단루프","품질관리","웹접근성","지속개선","PDCA","디지털정부","전자정부","웹품질관리"],sections:$R[26]=[],content:"",isPrivate:!1}]},ssr:!0}],lastMatchId:"�posts�$postId�posts�%EA%B3%B5%EA%B3%B5%EC%9B%B9%EC%9D%80-%EA%B2%80%EC%83%89%EC%97%90-%EC%9E%A1%ED%9E%88%EA%B3%A0-%EC%9E%88%EB%82%98-viewcheck%EA%B0%80-%EB%A9%94%ED%83%80%ED%83%9C%EA%B7%B8-open-graph-%EA%B5%AC%EC%A1%B0%ED%99%94%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%A5%BC-%EC%A7%84%EB%8B%A8%ED%95%98%EB%8A%94-%EB%B0%A9%EB%B2%95"})($R["tsr"]);$_TSR.e();document.currentScript.remove()</script><script type="module" async="" src="/assets/index-C1m3Lvel.js"></script></body></html>