며칠 전 저희는 자사 홈페이지에 자동 차단 계층을 하나 추가했습니다. 악성 스캔 IP를 자동으로 문 밖에서 막아내는 기능입니다. 배포 전에 한 단계를 남겨 두었습니다. 우선 관찰만 하고 실제로 차단하지는 않으며, ‘활성화하면 차단될 IP’를 기록해 며칠간 지켜보는 것이었습니다.
그런데 이 한 단계가 저희를 구했습니다. 관찰 기간에 ‘차단 대상’으로 잡힌 30여 개 IP 가운데 4개가 실제 Googlebot이었습니다.
만약 당시 번거로움을 피하려고 곧바로 활성화했다면, 저희는 Google의 크롤러를 문 밖에서 막아 세웠을 것입니다. 그리고 이를 알려 주는 것은 아무것도 없습니다. 웹사이트는 평소처럼 열리고, 관리자 페이지도 모두 정상입니다. 다만 순위와 색인만이 앞으로 몇 주에 걸쳐 서서히 떨어지고, 그때 가서는 원인을 찾을 수 없게 됩니다.
이 일은 별도의 글로 다룰 가치가 있습니다. 왜냐하면 많은 기업이 지금 저지르고 있으면서도 전혀 알지 못하는 실수이기 때문입니다. 보안 플러그인을 설치하고, CDN을 도입하고, 방화벽 규칙을 설정했습니다. 보호는 갖췄지만, 그 과정에서 검색엔진과 AI의 크롤러까지 함께 막아 버렸을 가능성이 큽니다.
결론부터 말씀드리면, 보안과 SEO는 태생적으로 충돌합니다. 좋은 쪽과 나쁜 쪽이 너무 닮았기 때문입니다
차단하려는 공격자와 반갑게 맞이하려는 검색엔진 크롤러는 행동 특성이 상당 부분 겹칩니다. 둘 다 프로그램이 자동으로 접속하고, 광고도 보지 않고 버튼도 누르지 않으며, 짧은 시간에 대량의 페이지를 수집하고, 낯선 IP에서 들어옵니다.
따라서 ‘접속 빈도에 따라 차단하는’ 어떤 규칙이든 크롤러를 함께 오탐할 수밖에 없습니다. 이것은 설정을 잘못 조정한 문제가 아니라, 판단 기준 자체를 잘못 고른 문제입니다. 저희 관찰 기간에 잡힌 Googlebot 4개 중 하나는 단일 연결로 647개 페이지를 연속 수집했습니다. 이 숫자만 보면 스캐너와 전혀 구분되지 않습니다.
회색 지대가 거의 없는 판별 특성: ‘찾을 수 없음’의 비율을 보라
빈도를 쓸 수 없다면 무엇을 써야 할까요? 저희가 시험 삼아 찾아낸 판단 기준은 구분도가 워낙 높아 망설일 필요가 거의 없습니다. 이 방문자가 요청한 페이지 가운데 ‘애초에 존재하지 않는’ 페이지가 얼마나 되는지 보는 것입니다.
이유는 아주 명확합니다. 정상적인 크롤러는 당신이 제공한 단서를 따라 수집합니다. 사이트맵에 어떤 주소가 나열되어 있고 페이지에 어떤 링크가 있는지, 그것을 그대로 수집하므로 적중률이 매우 높습니다. 반면 스캐너는 추측합니다. 설정 파일 유출이 있는지, 데이터베이스 백업이 있는지, 관리자 페이지가 어디인지 하나씩 시험해 보며, 대부분은 당연히 ‘찾을 수 없음’이 나옵니다.
실측 결과 이 두 부류의 격차는 중간 지대가 없을 정도입니다. 크롤러의 ‘찾을 수 없음’ 비율은 기본적으로 0이고, 스캐너는 대개 87% 이상이며 100%인 경우도 많습니다. 따라서 ‘찾을 수 없음의 비율’을 차단의 전제 조건으로 삼는 편이 단순히 빈도만 보는 것보다 훨씬 신뢰할 수 있습니다.
직관에 반하는 함정: 도메인에 google이 들어 있다고 해서 Google은 아닙니다
저희는 관찰 기간에 흥미로운 것도 하나 잡았습니다. 어떤 IP를 역조회해 나온 도메인이 google이라는 글자를 포함하고 있었고(Google 클라우드의 하위 도메인에 속함), 그런데 그 IP는 당시 저희 /.git/config를 탐색하고 있었습니다. 전형적인 공격 행위입니다.
이유는 그런 도메인이 클라우드 서버 임차인에게 속하기 때문입니다. 누구든 돈을 내고 한 대를 빌릴 수 있으며, Google 자체의 크롤러와는 전혀 다른 것입니다. 그래서 ‘도메인에 google이 들어 있으면 통과시킨다’는 식의 손쉬운 처리는 진짜 스캐너를 문 안으로 직접 들여보내게 됩니다. 마찬가지로 방문자가 스스로 밝히는 신원(UA)만 보는 것은 더욱 신뢰할 수 없습니다. 그것은 누구나 마음대로 적을 수 있고, 바이두 크롤러로 위장하는 것은 가장 기초적인 수법입니다.
올바른 검증 방법: 양방향 조회가 일치해야 인정
업계의 표준 방식은 정·역방향 조회 검증이라고 하며, 검색엔진 공식 문서에도 나와 있습니다. 세 단계로 이루어집니다.
- ① 역조회: 방문자 IP로 도메인을 역방향 조회합니다.
- ② 대조: 이 도메인이 검색엔진의 공식 도메인인지 확인합니다(예: 바이두, Google이 각각 공개한 크롤러 도메인). ‘포함’이 아니라 ‘점’ 단위로 접미사를 정확히 일치시켜야 합니다. 그렇지 않으면
xxx-google.com같은 도메인도 통과할 수 있습니다. - ③ 정조회: 이 도메인을 다시 IP로 정방향 조회해 방문자 IP와 일치해야 진짜로 확인됩니다.
세 단계를 모두 통과해야 통과시킵니다. 첫 단계만으로는 부족하고, UA만 보는 것은 하지 않은 것과 같습니다.
저희가 겪은 또 하나의 세부 사항은 DNS 자체에 장애가 생기면 역조회가 실패한다는 점입니다. 이때 절대 ‘의심스러움’으로 처리해서는 안 됩니다. 그렇지 않으면 검색엔진이 통째로 오차단됩니다. ‘역조회 기록이 실제로 없는 경우’와 ‘저희 쪽에서 조회할 수 없는 경우’를 구분해야 하며, 후자는 차단이 아니라 판단을 건너뛰어야 합니다.
중소기업이 스스로 점검하는 방법: 기술이 필요 없는 세 가지
위의 내용은 기술적 세부 사항이며, 대부분의 기업이 직접 구현할 필요는 없습니다. 그러나 다음 세 가지는 반드시 확인 방법을 알아 두셔야 합니다. 문제는 대개 문제가 생기지 않을 것이라 여기는 곳에서 발생하기 때문입니다.
- 웹마스터 도구에서 ‘크롤링 이상’을 확인하세요. 가장 직접적인 증거입니다. 바이두, Bing의 웹마스터 콘솔에는 모두 크롤링 실패율과 오류 상세가 있습니다. 갑자기 대량의 크롤링 실패, 연결 시간 초과, 접근 거부가 나타난다면 기본적으로 자사 보호 기능에 막힌 것입니다. 정상 상태는 0에 가까워야 합니다.
- ‘사람을 막는’ 모든 요소를 한 번 나열하세요. 많은 기업의 보호는 여러 겹으로 겹쳐 있습니다. CDN에 한 겹, 서버 방화벽에 한 겹, 웹사이트 보안 플러그인에 또 한 겹, 심지어 홈페이지 제작사가 예전에 설정해 지금은 아무도 모르는 한 겹까지 있을 수 있습니다. 목록화해서 각 계층이 무엇을 막고 있는지 파악하세요.
- 차단에는 반드시 만료 시간이 있어야 함을 확인하세요. 저희 자체의 철칙입니다. 영구 차단은 절대 하지 않습니다. 규칙에는 언젠가 오판이 생기기 마련인데, 만료 시간이 있는 차단은 최대 몇 시간만 영향을 주지만, 영구 차단은 계속 피해를 주며 게다가 누가 언제 차단되었는지 아무도 기억하지 못합니다.
어떤 차단 규칙이든 배포 전에 ‘보기만 하고 막지 않기’
이 글에서 가장 하고 싶은 말이며, 유일하게 저희를 구한 항목입니다. 새로운 차단 규칙은 먼저 관찰 모드로 실행합니다. ‘원래라면 누구를 막게 되는지’만 기록하고 실제로 막지 않습니다. 며칠간 실행한 뒤 명단을 한 번 훑어보고, 그 안에 실제로 맞이하고 싶은 손님이 없는지 확인한 다음 정식으로 활성화하세요.
이 단계에 며칠이 더 들지만, ‘순위가 이유 없이 세 달간 하락했는데도 원인을 찾지 못하는 상황’을 없애 줍니다. 저희의 그 Googlebot 4개도 이렇게 건져냈습니다. 보안과 SEO의 절충은 추측이 아니라 실제 데이터를 먼저 보는 데서 나와야 합니다.
매달 10분 자체 점검표
| 무엇을 확인하나 | 어디서 확인하나 | 정상 상태 |
|---|---|---|
| 크롤링 오류율 | 바이두 / Bing 웹마스터 도구 → 크롤링 진단, 크롤링 오류 | 실패율이 0에 가깝고, “접근 거부”류 오류가 없음 |
| 차단 계층 목록 | CDN 관리 콘솔 + 서버 방화벽 + 웹사이트 보안 플러그인 | 각 계층이 무엇을 차단하는지 명확하고, 출처가 불분명한 규칙이 없음 |
| 차단 목록 | 보안 콘솔의 블랙리스트 / 차단된 IP 목록 | 모두 만료 시간이 있고, 검색엔진 IP가 포함되어 있지 않음 |
| robots 파일 | 도메인/robots.txt 열기 |
정식 페이지를 잘못 차단하지 않았고, Disallow: /가 없음 |
| 색인 추이 | site:도메인으로 총수 기록 / 웹마스터 도구 그래프 |
글을 올릴수록 완만하게 증가하며, 특정 월부터 하락세로 돌아서지 않음 |
지난 글에서 “조용한 실패”를 다뤘을 때와 마찬가지로, 핵심은 점검이 아니라 기록입니다. 매달 한 번씩 기록해야 추이가 보입니다. 크롤러가 잘못 차단될 때의 피해는 점진적이어서, 하루만 봐서는 절대 문제를 알아챌 수 없습니다.
자주 나오는 몇 가지 질문
Q: 그럼 아예 보안을 하지 않고 전부 허용하면 안 되나요?
A: 안 됩니다. 스캐너는 실제로 여러분의 취약점을 찾고 있고, 그대로 두면 서버가 느려지며 심한 경우 데이터 유출이나 침해로 이어집니다. 올바른 방향은 “막을지 말지”가 아니라 “올바른 판단 기준으로 막는 것”입니다. 단순히 빈도만으로 일괄 차단하지 말고, 행동 특성(예를 들어 위에서 말한 ‘찾지 못한 비율’)을 기준으로 판단해야 합니다.
Q: 잘못 차단된 크롤러는 차단을 풀면 회복되나요?
A: 회복됩니다. 다만 시간이 걸립니다. 검색엔진은 여러분 사이트에 대한 접근이 반복적으로 실패하는 것을 감지하면 자동으로 크롤링 빈도를 낮추며, 원래 속도로 돌아오기까지 보통 몇 주가 걸립니다. 그래서 사후 복구보다 조기 발견이 훨씬 중요합니다. 매달 크롤링 오류율을 확인해야 하는 이유도 여기에 있습니다.
Q: AI 크롤러도 고려해야 하나요?
A: 그렇습니다. 그리고 지금 점점 더 중요해지고 있습니다. AI가 여러분의 콘텐츠를 인용하려면, 전제 조건은 크롤링이 가능해야 한다는 것입니다. 이를 차단하면 AI의 답변에서 아예 존재하지 않게 됩니다. 검색 순위가 낮은 것보다 훨씬 심각한데, AI에는 “두 번째 페이지”가 없기 때문입니다.
Q: 우리 사이트에 몇 겹의 보호가 걸려 있는지 어떻게 알 수 있나요?
A: “우리 웹사이트 앞에 무엇이 걸려 있나요?”라고 물어봐도 보통 명확한 답을 얻기 어렵습니다. 더 신뢰할 수 있는 방법은 도메인 해석 경로와 서버 설정을 함께 훑어보면서 트래픽이 실제로 어떤 구간을 거치는지 확인하는 것입니다. 이 작업을 한 번 제대로 정리해 두고 도표로 저장해 두면, 앞으로 어떤 접속 문제를 진단할 때도 유용하게 쓸 수 있습니다.
검색엔진과 AI를 문 밖에 막아세우고 있지는 않은지 걱정되시나요?
Siwenlide는 베이징 및 인근 지역 중소기업을 위해 네트워크 보안과 홈페이지 SEO/GEO 운영을 함께 수행합니다. 두 가지를 동시에 하기 때문에 어디서 충돌하는지 잘 알고 있습니다. 몇 겹의 차단이 걸려 있는지 정리해 드리고, 계층별로 규칙을 하나씩 검증하며, 잘못 차단된 크롤러를 풀어주고 정·역방향 조회 검증이 포함된 화이트리스트를 적용합니다. 또한 매달 크롤링 오류와 색인 추이를 모니터링합니다. 본문에 나온, 차단될 뻔한 Googlebot 4개는 바로 저희 사이트에서 “먼저 관찰한 후 활성화”하는 방식으로 찾아낸 것입니다. siwenlide.com을 방문하시거나(또는 먼저 저희 회사 소개를 확인해 보시거나) 400-686-2011로 전화해 이야기 나눠 보세요.
