내 SEO 프로젝트 중 하나는 Yandex에 12,500페이지가 색인돼 있었다. 이 숫자만 보면 사이트는 정상처럼 보였다. 그런데 실제 러시아 트래픽은 거의 0이었다.
이 대규모 SEO 프로젝트는 프론트엔드 개발자로서 내 실력을 더 끌어올리기 위해 만들고 있던 프로젝트이기도 했다.
처음에는 당연히 SEO 문제라고 생각했다. 하지만 문제를 추적하면서 더 기초적인 원인을 발견했다. 네트워크 경로였다. 사이트는 Cloudflare 뒤에 있었고 러시아에서 안정적으로 접근할 수 없었다. 나는 러시아 밖에 살고 있었기 때문에 내가 일하는 환경에서는 이 장애가 거의 보이지 않았다.
이 사건을 겪으면서 나는 쉽게 같은 신호로 취급했던 세 가지를 분리하게 됐다. 색인, 접근성, 트래픽이다. 셋은 같은 것이 아니다. 페이지가 색인에 남아 있어도 특정 네트워크의 실제 사용자는 페이지를 제대로 불러오지 못할 수 있다.
내가 실제로 확인할 수 있는 것
내 경험에서 확인된 사실은 단순하다. 나는 Cloudflare 뒤에서 대규모 SEO 프로젝트를 운영하고 있었다. Yandex에는 12,500페이지가 색인돼 있었지만 러시아 트래픽은 거의 없었다. 조사 끝에 문제를 네트워크 레이어로 좁혔다. 이후 Cloudflare 프록시를 완전히 끄고 내 VDS의 Nginx에 필요한 기능인 캐싱, 압축, 기본 보안을 직접 구성했다.
그 변경 뒤 러시아에서의 접근은 즉시 복구됐다. 이 사례에서 내가 가장 강하게 말할 수 있는 결과는 이것이다. 전달 경로를 바꾸자 접근성이 돌아왔다.
반대로 이 사례가 증명하지 않는 것도 중요하다. 정확히 몇 번의 방문을 잃었는지, 러시아의 어떤 네트워크가 모두 영향을 받았는지, 이후 자연 검색 트래픽이 정확히 얼마나 회복됐는지는 이 사례만으로 말할 수 없다. 내가 관찰한 것은 접근성 문제와 거의 0에 가까운 트래픽이었지, 통제된 SEO 실험이 아니었다.
공개 자료는 내 초기 설명보다 더 정확했다
처음에는 Roskomnadzor가 Cloudflare의 특정 IP 대역을 차단했다고 설명했다. 지금 보면 내가 뒷받침할 수 있는 증거보다 너무 구체적인 표현이었다.
Cloudflare는 2025년 6월 26일 자체 보고서를 공개하면서 2025년 6월 9일부터 러시아에서 Cloudflare로 보호된 서비스에 접속하는 사용자들이 러시아 ISP의 throttling을 겪고 있다고 밝혔다. Cloudflare의 내부 분석에 따르면 영향을 받은 연결에서는 웹 자원의 처음 16 KB만 로드되는 경우가 있었고, 이 정도면 많은 페이지에서 정상적인 탐색이 불가능하다. 자세한 내용은 Cloudflare의 러시아 연결 제한 보고서에서 볼 수 있다.
이 설명은 내가 본 장애 유형과 잘 맞는다. 하지만 모든 ISP에서 정확히 어떤 방식으로 적용됐는지까지 증명하지는 않으며, 내 전체 트래픽 감소를 Roskomnadzor에 직접 귀속할 수도 없다. 더 정확한 표현은 이렇다. 내 사이트의 Cloudflare 프록시 경로는 러시아에서 안정적으로 사용할 수 없었고, 그 프록시를 우회하자 내 경우에는 접근이 복구됐다.
12,500페이지가 색인돼 있어도 사이트가 정상이라는 뜻은 아니었다
내가 과소평가했던 핵심은 이 개념적 차이였다. 12,500페이지가 색인돼 있다는 사실을 사이트 전체의 접근성 신호처럼 봤다. 하지만 검색엔진 크롤링과 최종 사용자의 네트워크 연결은 서로 다른 시스템이다.
검색엔진은 URL을 과거에 크롤링했을 수 있고, 사용자와 다른 네트워크 경로로 접근할 수 있으며, 일부 사용자가 완전한 응답을 받지 못해도 페이지를 계속 색인에 유지할 수 있다. 따라서 색인된 URL이라는 사실만으로 특정 러시아 ISP의 사용자가 오늘 그 페이지를 열 수 있다고 증명할 수는 없다. 내 경우에는 두 사실이 동시에 존재했다. Yandex에는 12,500페이지가 색인돼 있었고 실제 러시아 트래픽은 거의 0이었다.
색인은 접근성이 아니다. 접근성은 트래픽이 아니다.
내가 바꾼 것
- Cloudflare 프록시를 완전히 껐다. HTTP/HTTPS 트래픽이 내 인프라에 도달하기 전에 더 이상 Cloudflare를 거치지 않게 했다.
- 필요한 기능을 Nginx로 옮겼다. 내 VDS에서 캐싱, 압축, 기본 보안 제어를 직접 구성했다.
핵심은 Nginx가 Cloudflare보다 “더 좋다”는 것이 아니었다. 나에게 중요한 시장에서 문제가 된 네트워크 의존성을 제거한 것이다.
접근은 돌아왔지만 운영 책임도 돌아왔다
reverse proxy를 우회하는 것은 공짜 업그레이드가 아니다. Cloudflare의 최신 문서에 따르면 DNS-only에서는 사용자가 origin으로 직접 연결되고 HTTP/HTTPS 트래픽이 Cloudflare 프록시를 거치지 않는다. 그 결과 캐시와 여러 보호 기능 같은 프록시 기반 이점이 사라지고 origin IP가 노출될 수 있다. 자세한 내용은 공식 Proxy status 문서에 있다.
Nginx는 내가 필요로 했던 기능의 일부, 예를 들어 로컬 캐시, 압축, 요청 처리, 기본 필터링은 담당할 수 있다. 하지만 Cloudflare의 글로벌 네트워크, 관리형 DDoS 대응 역량, 모든 보안 기능을 자동으로 재현하지는 않는다. 결국 이 마이그레이션은 교환이었다. 전달 경로를 더 직접 통제하는 대신 운영 책임이 더 커졌다.
이 프로젝트에서는 러시아 접근성이 당장의 문제였기 때문에 그 교환이 가치 있었다. 그렇다고 VDS + Nginx가 모두에게 가장 안전한 아키텍처라는 뜻은 아니다.
비슷한 문제를 지금 다시 진단한다면
특정 국가나 네트워크 지역에서 트래픽이 급감하면 나는 제목이나 콘텐츠부터 고치지 않을 것이다. 먼저 레이어를 나눠 확인한다.
- 대상 국가에서, 가능하면 둘 이상의 ISP를 통해 페이지를 가져올 수 있는가?
- 클라이언트가 HTTP 200만 받는 것이 아니라 응답 본문 전체를 받는가?
- 통제된 테스트에서 CDN 또는 reverse proxy를 우회하면 동작이 바뀌는가?
- URL은 크롤링되고 색인돼 있는가?
- 접근성이 확인된 뒤에야 노출, 클릭, 세션이 실제로 변하는지 본다.
실무적인 교훈은 중요한 시장에서 직접 측정하라는 것이다. 다른 나라에서 origin이 살아 있다는 사실을 확인해도 지역 한정 연결 장애는 완전히 놓칠 수 있다.
이 사건에서 내가 얻은 결론
처음에는 SEO 미스터리처럼 보였다. 12,500페이지가 색인돼 있는데 러시아 트래픽은 거의 없다. 실제로 도움이 된 답은 스택의 더 아래에 있었다.
Cloudflare 프록시를 제거하고 VDS의 Nginx로 필요한 기능을 다시 구성하자 러시아에서의 접근이 즉시 복구됐다. 이 결과는 사실로 말할 수 있다. 하지만 이 사례를 Google이나 Yandex 순위 변화의 증거, 정확한 규제기관 차단 메커니즘의 증거, 또는 모두가 Cloudflare를 떠나야 한다는 보편적 규칙으로 확대할 수는 없다.
이후 내 기준은 더 단순해졌다. 어떤 시장이 중요하다면 그 시장에서 접근성을 측정해야 한다. 색인된 페이지 수만으로 실제 사용자가 페이지 전체를 받을 수 있는지는 알 수 없다.