개방성 자동 진단의 속사정 — robots.txt·sitemap.xml, 공공사이트의 문은 얼마나 열려 있는가

검색엔진·크롤러에게 정보를 얼마나 여는가. 두 파일의 내용을 파싱해야 비로소 보이는 것들

---

들어가며 — '개방성'이라는 단어가 감추는 기술적 현실

행안부 「전자정부 웹사이트 품질관리 지침」(고시 제2025-46호, 2025년 6월 25일 시행)은 공공 웹사이트가 갖춰야 할 7대 품질 영역 중 하나로 개방성을 명시한다. 개방성이라는 단어는 직관적으로 들린다. "우리 사이트는 열려 있습니다"라고 말하면 뭔가 다 된 것처럼 느껴지기도 한다.

그런데 막상 기술적으로 들어가면 이야기가 달라진다. 검색엔진과 크롤러에게 "어디까지 와도 되고, 어디는 오지 마시오"를 알려주는 파일이 실제로 존재한다. robots.txt라는 평범한 텍스트 파일이다. 그리고 "우리 사이트에 이런 페이지들이 있으니 인덱스해 가세요"를 말해주는 sitemap.xml도 있다. 이 두 파일이 없거나, 있어도 잘못 작성되어 있거나, 형식만 갖추고 내용이 비어 있거나 — 이런 상황이 공공 사이트에서 얼마나 자주 벌어지는지를 우리는 분석 과정에서 꽤 많이 목격했다.

더 흥미로운 건 2025년 고시 개정 내용이다. 이번 개정에서 개방성 기준의 일부가 완화됐다. 이전에는 크롤링 완전 허용이 기본 전제였다면, 이제는 부분 차단(Disallow)도 허용하는 방향으로 바뀌었다. "완전히 열어야 한다"에서 "합리적 범위에서 통제할 수 있다"로의 변화다. 이 변화가 무엇을 의미하는지, 그리고 그 '합리적 범위'를 자동으로 판단하려면 무엇을 파싱해야 하는지 — 이것이 이 글의 핵심 주제다.

ViewCheck LLM 분석은 URL을 입력받으면 24가지 관점으로 분석 결과를 대화로 펼쳐준다. 그 24가지 중에 SEO(검색최적화) 항목이 있고, 그 안에 개방성 진단이 포함된다. 이 편에서는 그 개방성 진단이 어떻게 작동하는지, 어떤 기술적 배경이 깔려 있는지, 그리고 "파일이 있느냐 없느냐"만 보는 것과 "내용을 파싱하는 것" 사이에 어떤 차이가 있는지를 R&D 여정의 관점에서 풀어보려 한다.

---

robots.txt — 28년의 관습이 2022년에야 정식 표준이 된 사연

이야기를 시작하기 전에 한 가지 역사적 사실부터. robots.txt는 1994년 네덜란드 컴퓨터 과학자 마르테인 코스터(Martijn Koster)가 처음 제안한 파일이다. 웹이 아직 걸음마 단계이던 시절, 검색 엔진 크롤러들이 무작위로 사이트를 긁어가는 것을 막기 위해 "이 파일을 읽고 지시에 따라 달라"는 약속을 만든 것이다.

그로부터 약 28년이 지난 2022년 9월, IETF(Internet Engineering Task Force)는 이 오랜 관습을 RFC 9309 — Robots Exclusion Protocol이라는 공식 표준으로 등재했다. RFC Editor에 따르면 이 문서는 수십 년간 사실상(de facto) 표준으로 작동해 온 robots.txt 프로토콜을 처음으로 공식 인터넷 표준(Internet Standard)으로 끌어올린 것이다(RFC 9309, IETF/RFC Editor, 2022). 표준화 작업이 이렇게 오래 걸린 데는 이유가 있다. robots.txt는 워낙 단순하고, 각 검색엔진이 조금씩 다르게 해석해 왔으며, 강제력이 없는 '신사 협정'이었기 때문이다.

RFC 9309가 확정한 핵심 내용은 이렇다.

• User-agent: 규칙을 적용할 크롤러를 지정한다. *는 모든 크롤러에 해당.
• Disallow: 접근을 막을 경로를 지정한다. /admin/이라고 쓰면 /admin/으로 시작하는 모든 URL이 차단된다.
• Allow: 특정 경로를 명시적으로 허용한다. Disallow와 중복될 때는 더 구체적(긴) 경로가 우선한다.
• Sitemap: robots.txt 파일에 sitemap.xml의 위치를 명시한다.
• Crawl-delay: 크롤러가 요청 사이에 기다려야 하는 시간. 단, Google은 이 지시어를 지원하지 않는다.
• 캐싱: 크롤러는 robots.txt를 캐시해 두되, 24시간을 넘겨 사용하지 않아야 한다.

"파일이 있다"는 것과 "파일의 내용이 타당하다"는 것은 전혀 다른 이야기다. robots.txt를 단순히 HTTP 200 응답이 오는지만 확인하는 것은, "현관문이 있다"는 것만 확인하고 "그 문이 제대로 달려 있는지"는 보지 않는 것과 같다. ViewCheck가 내용 파싱 기능을 개발한 출발점이 바로 이 지점이다.

---

sitemap.xml — "우리 집에 뭐가 있는지 목록을 드릴게요"

robots.txt가 "어디는 들어오지 마세요"를 말한다면, sitemap.xml은 "들어와서 이걸 봐 주세요"를 말한다. 사이트에 있는 URL들을 XML 형식으로 나열한 파일로, 검색엔진이 놓칠 수 있는 페이지를 확실히 인덱싱하도록 돕는다.

sitemap.xml의 공식 프로토콜은 sitemaps.org에서 정의된다. 구글, 야후, 마이크로소프트(빙) 세 회사가 2006년에 공동으로 마련한 이 사양은 오늘날 사실상의 표준으로 자리 잡았다(sitemaps.org 공식). 주요 내용은 이렇다.

• XML 형식, UTF-8 인코딩 필수
• 단일 파일에 최대 50,000개 URL, 50MB(비압축) 제한
• <loc>: URL (필수)
• <lastmod>: 콘텐츠 마지막 수정일 (선택, 그러나 Google이 실제로 활용하는 유일한 메타데이터)
• <changefreq>: 변경 빈도 (선택, Google은 무시함)
• <priority>: 중요도 (선택, Google은 무시함)

여기서 실무적으로 중요한 포인트가 하나 있다. Google은 <priority>와 <changefreq> 값을 무시한다(Google Search Central 공식). 이 두 값을 설정하는 데 시간을 쓰는 것은, 구글 기준으로는 아무 효과가 없는 작업이다. 대신 <lastmod> 값을 정확하게 관리하는 것이 실질적으로 의미 있다. Google은 이 값이 신뢰할 수 있을 때만 실제 크롤링 신호로 활용한다.

50,000개를 초과하는 대형 사이트라면 sitemap index 파일을 사용한다. 여러 개의 sitemap.xml을 묶는 상위 파일이다. 대형 공공기관 포털이라면 이 구조를 써야 할 수도 있다.

---

"있느냐 없느냐"에서 "뭐라고 적혀 있느냐"로 — 내용 파싱의 의미

ViewCheck 이전에도 개방성을 체크하는 도구들이 있었다. 그러나 많은 경우 "robots.txt가 HTTP 200을 반환하는가", "sitemap.xml이 존재하는가"만 확인했다. 파일이 존재하면 '개방성 통과', 없으면 '미통과'. 이 정도로 처리했다.

그런데 현장에서 보면, 파일은 있는데 내용이 문제인 경우가 훨씬 많다. 우리가 실제 분석 과정에서 마주친 사례들을 유형별로 정리하면 이렇다.

유형 1: 전체 차단 (사고)

User-agent: *
Disallow: /

위 두 줄은 모든 크롤러에게 사이트 전체를 차단한다. 사이트가 검색엔진에 아예 잡히지 않는다. 개발 단계에서 설정해 두고 배포 때 수정하지 않은 채 그대로 올라가는 경우가 대표적이다. 파일은 분명히 있지만, 그 내용이 사이트의 가시성을 완전히 막아버린다. 이를 "개방성 통과"로 판정하면 오진이다.

유형 2: 텅 빈 파일

파일은 존재하고 200 응답을 반환하지만 내용이 없거나, User-agent: *만 있고 Disallow/Allow가 없는 경우. 기술적으로는 "모든 크롤러에게 모두 허용"이지만, 의도인지 실수인지 알 수 없다. 이 경우 최소한 sitemap.xml 위치라도 적어두면 크롤러가 훨씬 효율적으로 동작하는데, 그 기회를 날리고 있는 것이다.

유형 3: sitemap.xml 경로 오입력

robots.txt에 Sitemap: https://example.go.kr/sitemap.xml이라고 적혀 있지만, 실제 sitemap.xml은 /sitemap/sitemap.xml에 있거나 존재 자체가 없는 경우. 크롤러가 robots.txt에 명시된 경로로 요청을 보내면 404가 떨어진다.

유형 4: sitemap.xml의 URL 불일치

sitemap.xml 안에 나열된 URL이 실제로 200 응답을 반환하지 않는 경우. 리다이렉트가 걸려 있거나, 이전에 삭제된 페이지가 목록에 남아 있거나. 검색엔진은 이런 URL을 크롤링하다가 쓸데없이 크롤 버짓(crawl budget)을 소진한다.

유형 5: lastmod 미갱신

sitemap.xml에 모든 URL의 <lastmod>가 2019-01-01로 고정되어 있거나, 아예 날짜 표기가 없는 경우. 구글은 정확한 lastmod만 크롤링 신호로 활용하므로, 이 값이 엉터리면 "최신 콘텐츠인데도 재크롤링이 느린" 문제가 생긴다.

이 다섯 가지 유형 모두, 파일의 존재 여부만 확인해서는 포착할 수 없다. 내용을 파싱해야 비로소 보인다. 이것이 ViewCheck가 "파일 있음/없음" 체크를 넘어서 robots.txt 내용 파싱과 sitemap.xml 구조 분석으로 나아간 이유다.

---

2025년 고시 개정 — "완전 개방"에서 "합리적 통제"로

앞서 간략히 언급했지만, 이 부분은 좀 더 자세히 살펴볼 필요가 있다.

행안부고시 제2025-46호(2025년 6월 25일 시행) 개정 내용 중 개방성 관련 변화가 있다. 이전 지침에서는 공공 웹사이트의 크롤링 허용이 원칙적으로 전면 개방을 전제로 했다면, 이번 개정에서는 "크롤링의 부분 차단"을 허용하는 방향으로 완화됐다. 서울시 정보소통광장에 공개된 결재 문서에서도 이 변화를 확인할 수 있다(서울특별시 정보소통광장, 전자정부 웹사이트 품질관리 지침 일부 개정 관련 결재문서).

이 변화를 어떻게 읽어야 할까. 우리가 보기엔, 이건 "개방성을 포기하자"가 아니라 "현실을 인정하자"에 가깝다.

공공 사이트에는 민감한 정보가 있다. 개인정보가 담긴 행정 처리 화면, 보안이 필요한 관리자 경로, 시스템 내부 API 엔드포인트. 이런 경로까지 전면 개방하면 오히려 보안 문제가 생긴다. robots.txt의 Disallow는 이런 경로를 합리적으로 제외할 수 있는 표준 수단이다.

더 나아가, 2025~2026년 현재는 GPTBot(OpenAI), ClaudeBot(Anthropic), Google-Extended, PerplexityBot, Bytespider(TikTok) 같은 AI 학습 목적의 크롤러가 급증했다. 기존의 검색 인덱싱 목적과는 다른 맥락이다. Cloudflare의 분석에 따르면, 2024년 이후 주요 웹사이트의 robots.txt에 AI 봇 차단 지시어가 폭발적으로 늘어났다(technologychecker.io, 2024). 검색 크롤러는 허용하되 AI 학습 크롤러는 차단하는 세분화된 정책이 현실적으로 필요해진 것이다.

이런 맥락에서 2025년 고시 개정은, "크롤링 차단 = 나쁜 것"이라는 이진법적 판단에서 벗어나 "어떤 크롤러에게, 어떤 경로를, 왜 차단하거나 허용했는가"를 다층적으로 보도록 기준을 진화시킨 것으로 이해할 수 있다.

ViewCheck의 개방성 진단도 이 방향을 따른다. 단순히 "Disallow가 있는가"를 체크하는 게 아니라, 어떤 경로가 차단되었고, 그것이 사이트의 주요 콘텐츠 노출에 영향을 미치는가를 살핀다. 관리자 경로를 막은 것과 검색 결과 페이지를 막은 것은 전혀 다른 판정을 받아야 한다.

---

ViewCheck가 파싱하는 것들 — robots.txt 편

ViewCheck가 robots.txt에서 실제로 뽑아내는 정보를 정리하면 이렇다.

1. 파일 존재 + HTTP 상태

가장 기본이다. https://{domain}/robots.txt에 GET 요청을 보내 HTTP 응답 코드를 확인한다. 200이면 존재, 404면 없음, 403은 있지만 접근 거부(이 경우도 따로 표기).

2. User-agent 그룹 수집

파일 내에 몇 개의 User-agent 그룹이 정의되어 있는지, 특정 크롤러(Googlebot, Bingbot, Yandexbot, GPTBot 등)가 별도로 명시되어 있는지를 파악한다. 특정 크롤러에 대한 개별 정책이 있다는 것 자체가 해당 사이트가 크롤링 정책을 얼마나 세심하게 관리하는지를 보여준다.

3. Disallow 경로 수와 패턴

차단된 경로가 몇 개인지, 어떤 패턴인지를 본다. /admin/, /private/처럼 명백히 관리 목적인 경로는 합리적 차단으로 분류한다. 반면 /, /*, /board/, /notice/ 같은 핵심 콘텐츠 경로가 막혀 있다면 다른 판정을 한다.

4. Sitemap 지시어 유무

robots.txt 파일 내에 Sitemap: 지시어가 있는지, 있다면 어떤 URL을 가리키는지를 추출한다. 이 URL이 실제로 접근 가능한지도 확인한다.

5. 파일 크기(처음 2KB 범위 내 원문 보존)

지나치게 큰 robots.txt(수십 KB 이상)는 그 자체로 이상 신호일 수 있다. 수천 개의 Disallow 규칙이 한 파일에 쌓여 있는 경우, 관리 없이 계속 덧붙인 흔적인 경우가 많다.

이 정보들을 종합해 ViewCheck는 robots.txt 상태를 크게 세 범주로 분류한다.

• 정상적 개방: 파일 있음, 핵심 콘텐츠 경로 접근 가능, Sitemap 지시어 있음
• 부분 차단 (합리적 범위): 관리자/내부 경로만 차단, 주요 콘텐츠는 열려 있음
• 문제적 차단: 주요 콘텐츠 경로 차단, 또는 전체 차단 (Disallow: /)

---

ViewCheck가 파싱하는 것들 — sitemap.xml 편

sitemap.xml 분석은 robots.txt보다 더 복잡하다. 파일이 있어도 내용의 품질이 천차만별이기 때문이다.

1. 파일 위치 탐색

먼저 robots.txt에 명시된 Sitemap 경로를 확인한다. 없다면 관례적인 경로들(/sitemap.xml, /sitemap_index.xml, /sitemap/sitemap.xml)을 순서대로 시도한다.

2. sitemap index vs 단일 sitemap 구분

최상위 태그가 <sitemapindex>인지 <urlset>인지를 확인해 구조를 파악한다. sitemap index라면 하위 sitemap 파일들의 URL을 수집한다.

3. URL 수 집계

<loc> 태그로 묶인 URL이 몇 개인지 센다. URL 수가 너무 적으면 (사이트 규모에 비해) 중요 페이지가 누락되어 있을 가능성이 있다. 반대로 50,000개에 근접하면 sitemap index 분리가 필요한 상태일 수 있다.

4. lastmod 유효성 검증

<lastmod> 값이 ISO 8601 형식(YYYY-MM-DD 또는 YYYY-MM-DDTHH:MM:SS+09:00)에 맞는지, 미래 날짜가 아닌지, 너무 오래된 날짜(5년 이상)가 아닌지를 확인한다. Google Search Central이 명시하듯, lastmod가 일관성 있게 정확할 때만 크롤링 신호로 활용된다(Google Search Central 공식 문서). 이 값이 엉터리인 파일은 있어도 없는 것이나 마찬가지다.

5. sourceUrl (실제 출처 URL) 기록

어떤 경로에서 sitemap.xml을 찾았는지를 기록한다. robots.txt에 명시된 경로와 실제 파일 위치가 다를 경우 이를 지적한다.

---

기술적 구현의 어려움 — "간단해 보이는 것"의 함정

robots.txt와 sitemap.xml 파싱이 "간단한 작업"처럼 보일 수 있다. 텍스트 파일을 다운로드해서 읽으면 되는 것 아닌가. 실제로 해보면 그렇지 않다.

문제 1: 인코딩 문제

RFC 9309는 robots.txt 파일이 UTF-8을 기본으로 할 것을 명시한다. 그러나 오래된 공공 사이트 중에는 EUC-KR 또는 CP949로 인코딩된 robots.txt가 존재한다. 한국어 주석(# 관리자 경로 차단)이 들어간 경우 특히 그렇다. 인코딩을 잘못 해석하면 내용 전체가 깨진다.

문제 2: 대소문자 혼용

RFC 9309는 필드 이름(User-agent, Disallow 등)이 대소문자를 구분하지 않는다고 규정한다. 하지만 경로 매칭은 대소문자를 구분한다. Disallow: /Admin/과 Disallow: /admin/은 다른 경로다. 그런데 실제 파일에서는 user-agent, DISALLOW, User-Agent 등 다양한 표기가 섞여 있다. 이를 정규화하지 않으면 파싱 오류가 발생한다.

문제 3: 주석과 빈 줄 처리

# 이후는 주석이다. 그런데 인라인 주석(Disallow: /private/ # 개인정보 경로)과 독립 주석(# 모든 봇 차단)을 구분하는 로직이 필요하다. 또 User-agent 그룹은 빈 줄로 구분되는데, 파일 끝에 줄바꿈이 없거나 연속 빈 줄이 있으면 파싱이 엉킬 수 있다.

문제 4: sitemap.xml의 크기와 타임아웃

대형 포털 사이트의 sitemap.xml은 수 MB에 달하기도 한다. 전체를 내려받아 파싱하면 메모리와 시간이 많이 든다. 스트리밍 파싱(SAX 방식)과 최대 URL 수 제한(예: 처음 1,000개만 파싱)이 필요하다.

문제 5: 타임아웃과 리다이렉트

공공 사이트 중 robots.txt에 5초 이상 응답하는 경우가 있다. 또는 /robots.txt가 사이트 메인 페이지로 리다이렉트되는 경우도 있다(보통 파일이 없을 때). 이런 케이스를 구분해 타임아웃과 리다이렉트 횟수에 제한을 두고 처리해야 한다.

ViewCheck는 이런 엣지 케이스들을 하나씩 처리하는 코드를 openness-checker.js라는 모듈에 모아서 관리한다. 페이지 분석마다 반복 호출하는 게 아니라, 사이트 분석 시작 시 1회만 호출하고 결과를 재사용한다. robots.txt와 sitemap.xml은 사이트 전체에 하나씩 있는 파일이기 때문이다.

---

"크롤링 예산"이라는 개념과 공공 사이트

Google은 모든 사이트에 '크롤링 예산(crawl budget)'을 할당한다. 특정 시간 내에 Googlebot이 한 사이트에서 크롤링할 수 있는 URL 수의 상한이다. 이 예산은 무한하지 않다.

sitemap.xml이 없거나 불량하면, 크롤러는 내부 링크를 따라가면서 페이지를 발견해야 한다. 이 과정에서 정작 중요한 페이지가 발견되기 전에 예산이 소진될 수 있다. 특히 공공 사이트는 민원 처리 시스템, 검색 결과 페이지, 게시판 필터 조합 등 인덱싱이 필요 없는 동적 URL이 많다. 이런 URL들이 robots.txt에서 차단되지 않고 sitemap.xml에서도 걸러지지 않으면, 크롤러는 쓸모없는 URL에 예산을 낭비하게 된다.

Straightnorth의 분석에 따르면 "XML 사이트맵은 중요 URL의 목록을 명확하게 제공함으로써 검색엔진이 주요 콘텐츠를 발견하고 색인하도록 안내하며, robots.txt는 크롤러가 접근해서는 안 될 영역을 지정함으로써 크롤링 예산을 보호한다"고 정리한다(Straightnorth, "XML Sitemaps & Robots.txt: How to Guide Search Engines Effectively"). 두 파일이 서로 보완 관계를 이루는 것이다.

공공 사이트의 경우, 이 두 파일의 관계가 어긋나는 경우가 많다. sitemap.xml에는 URL이 올라가 있지만 robots.txt에서 그 경로가 막혀 있거나, 반대로 robots.txt에서 허용했지만 sitemap.xml에 해당 URL이 없는 경우. Google Search Central도 이런 불일치를 명시적으로 경고한다. "sitemap.xml에 있는 URL이 robots.txt에서 차단되어서는 안 된다"는 것이다(Google Search Central, "Build and Submit a Sitemap").

ViewCheck의 개방성 분석은 이 교차 검증을 자동으로 수행한다. robots.txt의 Disallow 경로와 sitemap.xml의 URL 목록을 대조해, "사이트맵에 올라가 있지만 차단된 URL"이 있는지를 발견한다. 이런 불일치를 손으로 찾는 건 수십~수백 개의 URL을 눈으로 대조해야 하는 작업이다. 자동화가 빛을 발하는 지점이다.

---

여러 크롤러, 다른 규칙 — AI 봇 시대의 복잡성

robots.txt가 단순했던 시절은 지났다. 2010년대 초만 해도 User-agent: *에 전체 규칙을 적어두면 대부분의 검색엔진이 따랐다. 지금은 상황이 전혀 다르다.

Google Crawling Infrastructure 공식 문서에 따르면, Googlebot은 RFC 9309를 따르되 crawl-delay는 지원하지 않는다(Google Crawling Infrastructure, "How Google Interprets the robots.txt Specification"). Bing과 Yandex는 crawl-delay를 지원한다. Yandex는 crawl-delay를 "해당 시간 안에 1회만 접속"으로 해석하는데, 이 해석이 다른 엔진과 다르다(Yandex Webmaster 공식).

그리고 20232025년 사이에 급부상한 AI 학습 봇들. GPTBot(OpenAI), ClaudeBot(Anthropic), Google-Extended, PerplexityBot, Bytespider(TikTok) 등이 각자의 User-agent 이름으로 크롤링을 시작했다. 현재 major 뉴스 사이트와 대형 웹사이트의 3554%가 이런 AI 봇들을 robots.txt에서 차단하고 있다는 조사 결과도 있다(technologychecker.io, Cloudflare Network 분석, 2024; BuzzStream, 2025).

공공 사이트 입장에서 이 상황은 새로운 판단이 필요함을 의미한다. 검색 인덱싱 목적의 크롤링(Googlebot, Bingbot)은 허용하되, AI 학습 목적의 크롤링(GPTBot 등)에 대해서는 기관 정책에 따라 결정할 수 있다. 2025년 고시 개정에서 "합리적 범위의 부분 차단"을 허용한 것은, 이런 복잡한 현실을 반영한 것이기도 하다.

ViewCheck는 현재 주요 크롤러별 정책을 파악하는 수준까지 분석을 시도한다. Googlebot, Bingbot, GPTBot, Yandexbot, CCBot, Google-Extended 등 주요 User-agent를 인식하고, 각 크롤러에 대해 어떤 규칙이 적용되는지를 요약한다. 이 기능은 아직 개선 중이다. User-agent 이름의 변형(예: gpt-bot, GPTBot, OpenAI)을 모두 잡아내는 것, 새로 등장하는 봇들을 빠르게 목록에 추가하는 것이 계속되는 과제다.

---

분석 결과가 대화로 펼쳐질 때 — SEO 카드 안의 개방성

ViewCheck LLM 분석에서 개방성 관련 결과는 주로 SEO 분석 카드에 담긴다. URL을 입력하면 24개의 분석 카드가 대화로 펼쳐지는데, 그중 SEO 카드는 다음 항목들을 포함한다.

• 메타 태그 (title, description, viewport, lang, canonical, robots meta)
• Open Graph 태그 (og:title, og:description, og:image 등)
• 구조화 데이터 (JSON-LD, microdata)
• 헤딩 계층 (H1~H6)
• 이미지 alt 커버리지
• robots.txt 분석 (개방성)
• sitemap.xml 분석 (개방성)

robots.txt와 sitemap.xml 항목은 단순히 "있음/없음"이 아니라, 위에서 설명한 파싱 결과를 요약해 보여준다. 어떤 경로가 차단되어 있는지, sitemap.xml에 URL이 몇 개 있는지, lastmod 값의 신뢰도가 어떤지 같은 정보다.

채팅에서 이 항목에 대해 추가 질문을 할 수도 있다. "왜 개방성이 부분 차단으로 분류됐어?", "차단된 경로가 문제가 되는 건가?"라고 물으면, 분석 근거와 함께 KRDS 공식 문서나 Google Search Central 가이드를 참조패널에 띄워 답한다. 단순한 Yes/No 판정이 아니라, 판정 근거를 대화로 설명할 수 있는 구조다.

이 '근거 있는 대화'라는 방향성은, 우리가 이 시리즈에서 계속 강조해 온 원칙과 이어진다. AI가 판단한다고 해서, 그 판단을 맹신하면 안 된다. 판단 옆에 근거가 있어야 사용자가 직접 확인하고 판단할 수 있다.

---

실제 공공 사이트에서 발견한 패턴들

우리가 실제로 분석한 공공 사이트들에서 공통적으로 발견한 패턴을 몇 가지 정리한다. (구체적 기관명은 생략한다. 특정 기관을 지적하려는 게 아니라, 일반적 경향을 공유하려는 것이다.)

패턴 A: sitemap.xml이 아예 없는 경우

소규모 지방 기관 사이트에서 자주 보인다. 외주 개발사가 기본 구성을 하고 나서 sitemap.xml 생성을 별도로 다루지 않은 경우다. 없어도 사이트는 작동하지만, 검색엔진이 페이지를 발견하는 데 더 많은 시간이 걸린다. 특히 링크 구조가 복잡한 사이트나, 신규 개설 사이트에서 영향이 크다.

패턴 B: sitemap.xml은 있지만 lastmod가 무의미한 경우

sitemap.xml의 모든 URL에 동일한 <lastmod> 날짜가 박혀 있거나, CMS에서 자동 생성되었지만 lastmod가 "사이트맵 파일이 생성된 날짜"로 고정된 경우. 이 경우 Google은 lastmod 신호를 무시하고 직접 크롤링으로 판단한다. 사실상 lastmod가 없는 것과 같다.

패턴 C: robots.txt에 과도한 Disallow

리뉴얼 이전 경로(/old/, /2019/)와 현재 경로가 혼재해 있고, 리뉴얼 이전 차단 정책이 그대로 남아 있는 경우. 불필요하게 많은 경로가 차단되어 있지만, 실제로 그 경로로 접근을 시도하면 404가 뜬다. 즉, 없는 경로를 막고 있는 것이다. 관리가 안 된 흔적이다.

패턴 D: Sitemap 지시어 경로와 실제 파일 위치 불일치

robots.txt에는 /sitemap.xml이라고 적혀 있지만, 실제 파일은 /sitemap/index.xml에 있거나 존재하지 않는다. 이런 경우 크롤러가 robots.txt를 참조해 sitemap을 찾으려 했다가 실패한다. 수동으로 발견한다면 시간이 걸린다. ViewCheck는 몇 가지 관례적 경로를 순차 탐색해 파일을 찾고, robots.txt에 명시된 경로와 다를 경우 이를 표시한다.

패턴 E: AI 봇 정책이 없는 경우

2024년 이후 GPTBot 등 AI 봇에 대한 정책을 명시적으로 robots.txt에 적어두는 것이 현실적으로 의미 있는 시점이 됐다. 그러나 많은 공공 사이트의 robots.txt는 2020년 이전에 작성된 그대로고, AI 봇에 대한 언급이 없다. 허용인지 차단인지 의도가 불명확한 상태다. 고시 개정이 "합리적 부분 차단"을 허용하는 방향으로 간 만큼, 기관별로 AI 봇 정책을 의식적으로 수립하고 robots.txt에 반영하는 것이 앞으로 필요해질 것으로 보인다.

이런 패턴들은 모두 자동화된 파싱 없이는 일일이 손으로 확인해야 하는 것들이다. 사이트 하나에 담당자가 15~30분을 쓸 수 있다. 수십 개 사이트라면? 그 부담이 쌓이면 점검 자체가 형식적으로 흐른다. ViewCheck가 이 작업을 수 초 안에 처리하고 결과를 카드로 보여주는 것이, 실무에서의 실질적 가치라고 생각한다.

---

멀티 페이지 맥락에서의 개방성 진단

ViewCheck의 기본 철학은 "단일 페이지가 아니라 사이트 전체를 본다"는 것이다. robots.txt와 sitemap.xml은 사이트 전체에 하나씩 존재하는 파일이므로, 이 항목은 멀티 페이지 분석에서 사이트 단위로 1회만 진단하고 그 결과를 전체 분석에 반영한다.

중요한 건 이 결과가 다른 분석 결과와 교차 검증된다는 점이다. 예를 들어, 접근성 분석에서 특정 페이지 유형(신청 페이지, 검색 결과 페이지)의 규칙 위반이 많이 발견됐는데, 동시에 그 페이지 유형의 URL 패턴이 robots.txt에서 차단되어 있다면 — 이 두 정보는 함께 볼 때 더 의미 있다. 크롤러가 그 페이지를 못 보는 것이 의도된 것인지, 아니면 관리 소홀인지를 판단하는 데 도움이 된다.

또한 sitemap.xml에 등재된 URL과 실제 크롤링에서 발견된 URL을 비교하면, 사이트맵에 누락된 중요 페이지를 찾아낼 수 있다. 특히 동적으로 생성되는 신청 페이지나 게시물 상세 페이지는 sitemap.xml에 빠져 있는 경우가 많다. 이런 누락이 검색 노출에 영향을 준다.

이 교차 분석은 현재 ViewCheck에서 부분적으로 구현되어 있고, 더 정밀하게 다듬는 작업이 계속 진행 중이다. "개방성은 robots.txt와 sitemap.xml 파일 두 개만 보면 된다"는 단순한 접근에서, "개방성은 사이트의 전체 크롤링 가능성을 보는 것"이라는 더 넓은 시각으로 가는 여정이다.

---

행안부 지침의 개방성 기준 — 무엇을 보는가

행안부 「전자정부 웹사이트 품질관리 지침」에서 개방성 영역이 다루는 항목들을 정리해 두면 유용하다. 고시 본문과 함께 배포된 「전자정부 웹사이트 품질관리 가이드」에서 개방성은 크게 다음 항목들로 구성된다.

• robots.txt 파일 제공 여부 — 파일의 존재와 접근 가능성
• 크롤링 정책의 타당성 — 차단 범위가 합리적 범위 내인지 (2025년 개정으로 부분 차단 허용)
• sitemap.xml 파일 제공 여부 — 사이트맵의 존재와 접근 가능성
• 메타데이터 개방 — Open Graph, 구조화 데이터, 메타 description 등
• RSS/Atom 피드 — 콘텐츠 개방성의 또 다른 측면

이 중 robots.txt와 sitemap.xml은 기술적 구현이 명확하고, 자동화된 확인이 가능한 항목이다. 나머지 메타데이터 항목도 ViewCheck SEO 카드에서 같이 다룬다. 이 글에서는 robots.txt와 sitemap.xml에 집중했지만, 실제 개방성 진단은 더 넓은 SEO 분석의 일부로 이루어진다.

2025년 고시 개정이 가져온 실질적 변화 중 하나는, 개방성 진단이 단순한 "있다/없다"의 이진법에서 "어떻게 열어놨는가"의 맥락 분석으로 진화해야 한다는 방향을 제시했다는 점이다. ViewCheck는 그 방향을 따라 개방성 진단 로직을 설계하고 있다.

---

개방성과 보안의 긴장 — "열려야 한다"와 "막아야 한다" 사이

개방성 영역에서 빠지지 않는 딜레마가 있다. "공공 사이트는 열려야 한다"는 원칙과, "공공 사이트는 보안이 중요하다"는 원칙이 충돌하는 지점이다.

robots.txt는 보안 수단이 아니다. 이 점을 Google도, RFC 9309도 명확히 한다. robots.txt는 "크롤러에게 요청하는 것"이지, "기술적으로 접근을 차단하는 것"이 아니다. 악의적인 봇은 robots.txt를 무시한다. 민감한 경로를 robots.txt로 차단했다고 해서 그 경로가 안전해지는 것은 아니다. 오히려 robots.txt에 민감 경로를 명시적으로 Disallow하면, 그 경로 자체를 공개하는 셈이 된다.

반면, sitemap.xml은 "크롤러에게 인덱싱을 요청하는 것"이다. 공개되어 있어야 할 페이지만 담아야 한다. 회원 전용 페이지, 임시 페이지, 개인정보가 포함된 결과 페이지 같은 것이 sitemap.xml에 들어가 있으면 곤란하다.

이 두 파일의 역할을 정확히 이해하고, 각각의 적절한 사용 방법을 따르는 것이 개방성과 보안을 동시에 챙기는 길이다. ViewCheck의 진단은 이 원칙을 기준으로 "개방성 차원에서 문제인 것"과 "보안 차원에서 문제인 것"을 구분하려 한다. 예를 들어, /admin/ 경로가 차단된 것을 개방성 위반으로 보지 않는다. 그러나 /board/notice/ 같은 공지사항 경로가 차단된 것은 다른 판정을 내린다.

이 구분이 항상 명확하지 않다는 것이 솔직한 고백이다. 경계선이 모호한 경로들이 있고, 기관마다 사정이 다르다. 완벽한 자동 판정보다는, "이 경로가 차단되어 있습니다, 의도된 것인지 확인하세요"라는 플래그를 세우고 판단을 담당자에게 넘기는 것이 현재 우리의 접근이다.

---

"개방성이 좋은 사이트"는 어떻게 생겼나 — 이상적인 설정의 예

말만 하면 와닿지 않으니, 이상적인 설정의 형태를 예시로 보여주겠다. 물론 모든 사이트에 똑같이 적용되는 "정답"은 없다. 하나의 참고 예시다.

이상적인 robots.txt (공공 사이트 예시)

# 검색엔진 크롤러 — 허용
User-agent: Googlebot
Allow: /

User-agent: Bingbot
Allow: /

# AI 학습 크롤러 — 기관 정책에 따라 결정
User-agent: GPTBot
Disallow: /

User-agent: CCBot
Disallow: /

# 모든 크롤러 — 관리 경로 차단
User-agent: *
Disallow: /admin/
Disallow: /wp-admin/
Disallow: /private/
Disallow: /temp/
Allow: /

# 사이트맵 위치 안내
Sitemap: https://www.example.go.kr/sitemap.xml

이 예시가 보여주는 것들:

1. 주요 검색엔진을 개별 지정해 명시적으로 허용
2. AI 봇에 대해 기관 정책을 명확히 표현
3. 모든 봇에 대해 관리 경로만 차단하고 나머지는 허용
4. Sitemap 지시어로 사이트맵 위치 안내

이상적인 sitemap.xml (간략한 구조)

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://www.example.go.kr/</loc>
    <lastmod>2025-06-01</lastmod>
  </url>
  <url>
    <loc>https://www.example.go.kr/board/notice/</loc>
    <lastmod>2025-06-15</lastmod>
  </url>
  <!-- 중요 페이지들... -->
</urlset>

실제로는 수십~수천 개의 URL이 담기고, 대형 사이트는 sitemap index 구조를 쓴다. 그러나 원칙은 단순하다. 중요하고 공개되어야 할 URL만 담고, lastmod는 실제 수정일을 정확하게 반영한다.

---

진단 결과를 보는 방법 — 어떤 항목에 주목할 것인가

ViewCheck의 SEO/개방성 카드를 처음 받아보는 담당자라면, 어디에 먼저 눈을 돌려야 할지 정리해 본다.

우선 확인 항목

1. robots.txt HTTP 상태: 200이 아닌 경우(404, 403, 타임아웃) 먼저 파악.
2. 전체 차단 여부: Disallow: / 또는 이에 준하는 설정이 있는지.
3. sitemap.xml 존재 여부: 파일이 있고 접근 가능한지.
4. sitemap.xml URL 수: 사이트 규모에 비해 현저히 적으면 누락 의심.

다음 확인 항목

5. Sitemap 지시어: robots.txt에 Sitemap 경로가 명시되어 있는지, 그 경로가 실제와 일치하는지.
6. lastmod 유효성: 날짜 형식과 신뢰도.
7. robots.txt와 sitemap.xml의 URL 교차 불일치: 사이트맵에 있는데 차단된 URL.

선택적 확인 항목

8. AI 봇 정책: GPTBot 등에 대한 명시적 정책 유무. 기관 정책이 수립되어 있는 경우.
9. Crawl-delay 설정: 서버 부하 이슈가 있을 때만 설정, Google에는 효과 없음을 감안.

모든 항목이 완벽한 사이트는 거의 없다. 중요한 건 어떤 항목이 실제 영향을 미치는지를 파악하고 우선순위를 잡는 것이다. 전체 차단 설정은 즉시 수정해야 하고, lastmod 날짜 형식 문제는 여유 있게 다뤄도 된다.

---

자동 진단의 한계와 우리가 아직 못 하는 것

솔직하게 이야기하자. 지금 ViewCheck의 개방성 진단이 완벽하지 않다.

아직 잘 못 하는 것들:

• robots.txt가 서버사이드에서 동적 생성되는 경우: 어떤 사이트는 사용자 에이전트에 따라 다른 robots.txt를 반환한다. ViewCheck가 보내는 요청과 Googlebot이 보내는 요청에 다른 내용이 올 수 있다. 이런 차이를 탐지하기가 쉽지 않다.
• sitemap.xml URL의 실제 상태 확인: sitemap.xml에 담긴 URL들이 실제로 200을 반환하는지 전수 확인하는 것은 URL이 수천 개일 때 시간과 비용이 많이 든다. 현재는 샘플링 방식으로 일부만 확인한다.
• 다국어 sitemap: hreflang 태그를 사용한 다국어 사이트의 sitemap.xml 구조는 더 복잡하다. 아직 이 부분의 파싱이 완전하지 않다.
• 동적 sitemap 생성 확인: CMS가 sitemap을 실시간 생성하는 경우, 요청 시마다 다른 내용이 올 수 있다. 캐시된 결과를 보는 것인지, 실시간 결과인지 구분이 어렵다.
• sitemap.xml과 실제 사이트 구조의 완전한 비교: ViewCheck가 크롤링하면서 발견한 URL과 sitemap.xml의 URL을 1:1로 매핑해 누락을 찾는 것은, 크롤링 깊이와 범위가 항상 달라서 완전한 비교가 어렵다.

이런 한계를 솔직하게 적는 이유는, 진단 결과를 읽을 때 "이걸로 다 알 수 있다"가 아니라 "이 결과를 출발점으로 삼아 담당자가 추가로 확인한다"는 태도가 맞기 때문이다. 도구가 모든 것을 해결해 주는 게 아니라, 도구가 빠르게 훑어보고 주목할 곳을 짚어주면 사람이 거기서부터 깊이 파고드는 것이 건강한 사용법이다.

---

다른 크롤러와 AI 봇의 공존 — 2025~2026년의 새로운 과제

마지막으로 조금 더 큰 맥락 이야기를 해보자.

robots.txt는 "신사 협정"이다. 따르는 것은 각 크롤러의 선택이다. 제대로 된 크롤러들(Googlebot, Bingbot 등 주요 검색엔진)은 이 파일을 잘 따른다. 하지만 RFC 9309는 명확히 말한다 — "Crawlers SHOULD follow the instructions, but are not legally required to." (크롤러는 지시를 따르는 것이 좋지만, 법적 의무는 아니다.)

이 말이 의미하는 바는, robots.txt가 악의적 스크래퍼나 규정을 무시하는 AI 학습 봇을 막는 기술적 수단은 아니라는 것이다. 그럼에도 robots.txt에 명시적 의사를 표현해 두는 것은 의미 있다. 법적 근거를 마련하는 데 도움이 되고(명시적 거부 의사가 있었음을 증명), 선의의 크롤러들이 그 의사를 존중하도록 안내할 수 있다.

공공 사이트 운영자들이 앞으로 robots.txt에서 신경 써야 할 것들이 늘었다. 검색 인덱싱, AI 학습, 공공 데이터 활용 크롤링 등 목적이 다양해졌고, 이에 따라 크롤러 종류도 급증했다. 이 복잡성을 손으로 관리하기 어려워진 만큼, 현황을 빠르게 파악하고 정책 검토가 필요한 항목을 짚어주는 자동 진단의 가치가 더 커졌다.

ViewCheck가 이 분야에서 완성된 솔루션을 갖고 있다고 말하기는 어렵다. 솔직히 말하면, 크롤러 생태계는 지금도 빠르게 변화하고 있고 우리도 따라가는 중이다. 다만 방향은 분명하다 — 단순한 "있음/없음" 체크에서 "내용과 맥락을 파악하는 진단"으로, 그리고 "새로운 크롤러 환경 변화를 반영하는 지속적 업데이트"로.

---

마무리 — "열려 있다"는 말의 기술적 무게

'개방성'이라는 단어는 쉽게 쓰인다. "우리 사이트는 열려 있습니다"라고 말하는 기관은 많다. 그러나 검색엔진과 크롤러에게 실제로 열려 있는지는, robots.txt 몇 줄과 sitemap.xml 하나가 결정한다.

그 파일들이 없거나, 있어도 잘못 작성되어 있거나, 형식만 갖추고 내용이 엉터리라면 — 아무리 훌륭한 콘텐츠도 검색엔진의 눈에 보이지 않는다. 시민이 검색으로 서비스를 찾지 못한다. '열려 있다'는 말이 기술적으로는 닫혀 있는 상태를 감추는 것이다.

2025년 고시 개정은 그 "열려야 한다"는 원칙을 더 현실적으로 다듬었다. 합리적 범위에서의 부분 차단을 허용하고, AI 봇이라는 새로운 변수를 반영할 공간을 만들었다. 이제 문제는 "얼마나 열어야 하는가"가 아니라 "무엇을, 누구에게, 왜 열고 막는지를 명확하게 표현하는가"다.

ViewCheck의 개방성 진단은 그 "명확한 표현"이 현재 어떤 상태인지를 빠르게 읽어주려는 시도다. 여기서 다룬 것들 — robots.txt 내용 파싱, sitemap.xml 구조 분석, 두 파일의 교차 검증 — 은 그 시도의 현재 모습이다. 아직 부족한 점이 있고, 계속 다듬는 중이다. 이 글이 그 여정을 조금 더 구체적으로 보여줬기를 바란다.

다음 편에서는 접속성 — 응답 시간, TTFB, SSL 인증서 상태, 네트워크 지연 분해 — 을 다룰 예정이다. 개방성이 "크롤러에게 열려 있는가"였다면, 접속성은 "사용자와 시스템에게 안정적으로 연결되는가"다. 또 다른 측정의 세계로 들어가 보자.

---

참고문헌

본문에 인용한 출처는 작성 시점에 모두 실재 여부를 직접 검색·검증했다. 국내 공식 기준과 해외 기술 표준 및 연구를 함께 실었다.

국내 — 공식 기준 / 정책자료

1. 행정안전부, 「전자정부 웹사이트 품질관리 지침」(행정안전부고시 제2025-46호, 2025년 6월 25일 일부개정 시행). 국가법령정보센터. https://www.law.go.kr/행정규칙/전자정부웹사이트품질관리지침

2. 행정안전부, 「전자정부 웹사이트 품질관리 지침」 일부 개정 및 「전자정부 웹사이트 품질관리 가이드」 수정본 안내 (고시 제2025-46호). 행정안전부 법령정보. https://www.mois.go.kr/frt/bbs/type001/commonSelectBoardArticle.do?bbsId=BBSMSTR_000000000016&nttId=118636

3. 서울특별시 정보소통광장, 「전자정부 웹사이트 품질관리 지침」 일부 개정 관련 결재문서 (개방성 기준 완화 확인). https://opengov.seoul.go.kr/sanction/33892320

4. 어센트 코리아, "Robots.txt와 Sitemap.xml 제대로 설정하기". https://www.ascentkorea.com/what-is-robots-txt-sitemap-xml/

해외 — 기술 표준 / 공식 문서

5. IETF (Internet Engineering Task Force), RFC 9309 — Robots Exclusion Protocol, September 2022. RFC Editor. https://www.rfc-editor.org/info/rfc9309/

6. sitemaps.org, Sitemap Protocol Specification (공식 사양, Google·Yahoo·Microsoft 공동). https://www.sitemaps.org/PROTOCOL.HTML

7. Google Search Central, "Robots.txt Introduction and Guide". Google for Developers. https://developers.google.com/search/docs/crawling-indexing/robots/intro

8. Google Search Central, "Build and Submit a Sitemap". Google for Developers. https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap

9. Google Crawling Infrastructure, "How Google Interprets the robots.txt Specification". Google for Developers. https://developers.google.com/crawling/docs/robots-txt/robots-txt-spec

10. Yandex Webmaster, "Using robots.txt". https://yandex.com/support/webmaster/en/controlling-robot/robots-txt

11. technologychecker.io, "We Analyzed robots.txt Across Cloudflare's Network" (AI 봇 차단 현황 분석, 2024). https://technologychecker.io/blog/robots-txt-ai-crawlers-blocking-report

12. BuzzStream, "Which News Sites Block AI Crawlers in 2025?" (뉴스 사이트 AI 봇 차단 현황, 2025). https://www.buzzstream.com/blog/publishers-block-ai-study/

13. Straightnorth, "XML Sitemaps & Robots.txt: How to Guide Search Engines Effectively". https://www.straightnorth.com/blog/xml-sitemaps-and-robots-txt-how-to-guide-search-engines-effectively/

14. Yoast, "The ultimate guide to robots.txt". https://yoast.com/ultimate-guide-robots-txt/

---