레딧이 이제 ‘그냥 HTML’도 위험하다고 말하기 시작함

• 레딧이 old.reddit.com의 비로그인 접근을 막으면서 내세운 명분은 ‘레딧을 안전하게 지키기 위해서’임

  • old.reddit.com은 레딧의 구형 UI인데, 핵심은 그냥 서버가 내려주는 평범한 HTML 페이지라는 점임
  • 글쓴이는 파이어폭스, 노스크립트 같은 조합을 쓰는 구형 웹 사용자라서 이 변화가 더 직접적으로 와닿는다고 말함

• 레딧의 공식 설명은 구형 레딧의 로그아웃 경험이 악성 스크래핑과 자동화 트래픽의 큰 원천이라는 것임

  • 그런데 신형 레딧은 여전히 로그인 없이 접근 가능하다는 점에서 설명이 깔끔하진 않음
  • 관리자 답변도 ‘구형 레딧에는 현대적인 보안 스택이 없다’는 식이라, 정확히 뭐가 위험한지는 흐릿함

• 글쓴이가 직접 비교해보니 구형 레딧은 정말로 ‘평범한 웹페이지’에 가까웠음

  • 발표 스레드를 열어보니 약 1MB를 내려받고 약 0.5MB를 전송하는 정도였고, 응답 대부분은 HTML 자체였음
  • 댓글 더 불러오기도 가볍고 빠르게 동작했고, 자바스크립트가 필수인 구조도 아니었음
  • 다만 첫 응답까지 2초 정도 걸려서, 글쓴이는 레이트 리밋 냄새가 난다고 봄

• 신형 레딧은 완전히 다른 세계임. 자바스크립트 없이는 글 본문 말고는 거의 제대로 안 뜸

  • 전체 로딩량은 구형 레딧의 약 5배 수준으로 보였고, 댓글은 별도 서비스 엔드포인트를 통해 받아오는 구조였음
  • 글쓴이가 요청을 최소한으로 열어둔 상태에서도 댓글 텍스트 응답은 받을 수 있었고, 결국 ‘자바스크립트 실행’이 스크래퍼를 귀찮게 만드는 장벽처럼 보였다고 함
  • 스크롤하거나 커서를 움직일 때마다 레딧으로 하트비트가 전송되는 것도 발견함. 안전해지는 기분이라니, 참 묘함

• 글쓴이의 결론은 꽤 날카로움. 이건 프론트엔드 보안 문제가 아니라 데이터 접근 통제 문제에 가깝다는 것임

  • 구형 레딧은 사람이 읽기에도 좋고 기계가 긁기에도 좋은 HTML이라서, 지금의 레딧 입장에선 너무 ‘열린’ 표면이 된 셈임
  • 대규모 언어 모델 시대에는 사람들의 진짜 댓글과 경험담이 금광처럼 취급되니, 레딧이 그걸 막으려는 동기는 충분히 있음
  • 다만 그걸 ‘안전’이라는 말로 포장하는 순간, 오랜 사용자 입장에선 빡칠 수밖에 없다는 얘기임

• 이 글이 개발자에게 찝찝하게 남는 이유는 단순함이 점점 벌을 받는 느낌 때문임

  • 텍스트를 HTML로 내려주면 빠르고 접근성도 좋고 검색도 잘 되지만, 플랫폼은 그게 너무 쉽게 수집된다고 봄
  • 반대로 무거운 자바스크립트 앱은 사용자에겐 느리고 불편해도, 플랫폼 입장에선 통제와 추적이 쉬움
  • 결국 ‘웹은 문서다’라는 오래된 감각과 ‘웹은 통제 가능한 앱 표면이다’라는 플랫폼 감각이 정면충돌하는 사례임

---

기술 맥락

• 여기서 선택된 기술적 갈림길은 서버 렌더링된 HTML과 자바스크립트 중심 앱이에요. old.reddit.com은 HTML만 받아도 내용을 읽을 수 있었기 때문에 사람에게도, 검색에도, 자동 수집에도 모두 열려 있었거든요.

• 레딧이 문제 삼은 건 HTML 자체의 보안 취약점이라기보다 접근 비용이에요. 자바스크립트 앱으로 가면 댓글을 더 가져오기 위해 특정 엔드포인트 호출, 실행 환경, 상태 관리가 필요해지고, 대량 수집자는 그만큼 구현 비용을 더 치르게 돼요.

• 하지만 이 방식은 사용자 비용도 같이 올려요. 글에서는 신형 레딧이 구형보다 약 5배 더 많이 로드되고, 기본 댓글도 200개가 아니라 약 25개만 보여준다고 짚어요. 스크래퍼를 귀찮게 하려다 일반 독자도 같이 불편해지는 구조인 셈이에요.

• 개발자 입장에서 이 사례가 재밌는 이유는 ‘보안 스택’이라는 말이 실제 제품 결정의 기술적 설명처럼 쓰였다는 점이에요. 막고 싶은 건 악성 트래픽이지만, 구현 결과는 공개 텍스트 웹의 접근성을 줄이는 방향으로 나타났거든요.