무슨 일이 있었나요?
혹시 12ft.io라는 서비스 기억하시나요? 유료 구독 장벽, 그러니까 페이월(paywall)이 걸린 기사 주소 앞에 12ft.io/만 붙이면 본문을 보여주던 서비스예요. “10피트짜리 벽을 세우면 12피트짜리 사다리를 가져오겠다”는 재치 있는 컨셉 덕분에 개발자들 사이에서도 꽤 유명했죠.
그런데 2025년 여름, 미국 언론사 연합 단체인 News/Media Alliance가 12ft.io를 내리게 했다고 발표하면서 서비스가 사라졌어요. 그 빈자리를 채우겠다며 한 개발자가 직접 만든 게 바로 WallHop이에요. 이름 그대로 벽(wall)을 깡충 넘는다(hop)는 뜻이고, 읽고 싶은 기사 링크를 넣으면 페이월 없이 본문을 보여주겠다는 기본 컨셉은 12ft.io와 같아요.
오늘은 이 서비스를 홍보하려는 게 아니에요. 페이월 우회가 기술적으로 왜 가능한지, 그리고 이런 서비스가 왜 생겼다 사라지기를 반복하는지를 개발자 시선에서 풀어볼게요. 언젠가 유료 콘텐츠 서비스를 만드는 쪽에 서게 될 우리한테 꽤 실용적인 이야기거든요.
페이월에도 종류가 있어요
페이월은 크게 두 가지로 나눠 볼 수 있어요.
소프트 페이월은 본문 전체를 일단 브라우저로 보내놓고, 자바스크립트나 CSS로 그 위에 “구독하세요” 창을 덮어서 가리는 방식이에요. 비유하자면 책은 이미 손에 쥐여줬는데 표지에 스티커만 붙여둔 셈이죠. 그래서 자바스크립트를 끄거나 개발자 도구로 가림막 요소를 지우면 본문이 그대로 보이는 경우가 많아요. “한 달에 기사 3개까지 무료” 같은 미터형 페이월도 읽은 횟수를 쿠키나 로컬 스토리지에만 저장하는 경우가 많아서 비슷한 약점이 있고요.
하드 페이월은 서버가 결제 여부를 먼저 확인하고, 통과한 사람에게만 본문을 내려주는 방식이에요. 브라우저에 데이터 자체가 없으니 클라이언트 쪽에서 무슨 짓을 해도 볼 수가 없죠.
그런데 하드 페이월도 뚫리는 이유: 검색엔진의 딜레마
여기서 재밌는 지점이 나와요. 언론사 입장에서는 기사가 구글 검색에 잘 걸려야 독자가 들어오잖아요. 그런데 검색엔진이 본문을 못 읽으면 색인을 제대로 못 하겠죠. 그래서 많은 언론사가 검색엔진 크롤러에게는 전체 본문을 보여주는 선택을 해요. 크롤러는 검색엔진이 웹페이지를 모으려고 돌리는 자동 방문 프로그램이에요.
12ft.io가 처음 유명해진 것도 이 틈 덕분이었어요. 구글 크롤러가 수집해 둔 페이월 없는 사본, 즉 구글 캐시를 대신 보여준다는 게 초기 설명이었거든요. 다른 우회 도구들도 비슷하게 크롤러인 척 요청을 보내거나, 웹 아카이브에 저장된 사본을 가져오는 식으로 동작했고요.
하지만 이 길은 점점 좁아지고 있어요. 구글은 2024년에 검색 결과의 캐시 링크 기능을 없앴고, 크롤러인 척하는 요청은 역방향 DNS 조회로 걸러낼 수 있거든요. 이게 뭐냐면, 요청을 보낸 IP 주소가 정말 구글 소유 도메인으로 연결되는지 거꾸로 확인하는 거예요. 이름표를 바꿔 단다고 신분증까지 바뀌진 않는 거죠.
왜 이런 서비스는 오래가지 못할까
기술보다 더 높은 벽은 법이에요. 12ft.io뿐 아니라 유명한 페이월 우회용 브라우저 확장 프로그램도 저작권 침해 신고 때문에 코드 저장소에서 여러 차례 내려간 적이 있어요. 미국에서는 저작권 보호 장치를 무력화하지 못하게 막는 DMCA 조항이 자주 근거로 쓰이고, 한국 저작권법에도 기술적 보호조치 무력화 금지 규정이 있어요. 페이월이 법적으로 여기에 해당하는지는 사안마다 따져봐야겠지만, 남의 유료 콘텐츠를 대신 가져다 보여주는 서비스를 공개적으로 운영하는 건 상당한 법적 리스크를 안고 가는 일이에요.
WallHop 같은 후속 서비스가 계속 나온다는 건 그만큼 수요가 있다는 뜻이에요. 하지만 같은 이유로 오래 버티기 어렵다는 것도 반복해서 확인된 패턴이고요. 좋은 기사를 만드는 데는 돈이 들고 그 비용은 누군가 내야 하니까, 쓰는 쪽이든 만드는 쪽이든 신중하게 판단해야 하는 영역이라고 생각해요.
한국 개발자가 가져갈 포인트: 페이월을 만드는 쪽의 시선
이 이야기를 뒤집어서 페이월을 만드는 쪽에서 보면 배울 게 많아요. 국내에서도 언론사 프리미엄 구독, 유료 뉴스레터, 온라인 강의, 웹소설처럼 유료 콘텐츠 서비스가 꾸준히 늘고 있잖아요.
- 중요한 콘텐츠는 서버에서 막으세요. 클라이언트에서 CSS로 가리는 건 보호라기보다 연출에 가까워요. 유료 본문은 권한 확인을 통과한 요청에만 내려주는 게 기본이에요.
- 크롤러 예외를 둔다면 진짜 크롤러인지 검증하세요. User-Agent 헤더는 누구나 바꿀 수 있어요. 역방향 DNS 확인이나 검색엔진이 공개한 IP 대역으로 검증하는 게 안전해요.
- 검색엔진 가이드도 챙기세요. 구글은 페이월 콘텐츠의 유료 영역을 구조화 데이터로 표시하라고 안내하고 있어요. 이걸 빼먹으면 크롤러와 사용자에게 다른 내용을 보여주는 ‘클로킹’으로 오해받을 수 있거든요.
- 무료 열람 횟수는 서버에서 세세요. 로컬 스토리지에만 저장한 카운트는 시크릿 모드 한 번이면 초기화돼요.
마무리
한 줄로 정리하면, 페이월 우회는 대부분 콘텐츠를 이미 보내놓고 가리는 설계의 빈틈에서 시작되고, 그런 서비스가 얼마나 버티는지는 기술보다 법이 결정해요.
여러분이 유료 콘텐츠 서비스를 만든다면 검색 노출과 콘텐츠 보호 사이에서 어떤 균형을 잡으시겠어요? 그리고 이런 우회 서비스가 계속 등장하는 현상이 지금의 구독 모델에 대해 무엇을 말해준다고 보시나요?
🔗 출처: Hacker News