브라우저 에이전트는 사용자 대신 예약하고, 표를 사고, 양식을 채우겠다고 약속합니다. 그런데 지난 몇 주 사이 주요 사이트들이 이들에게 문을 닫기 시작했습니다. Yelp는 데이터 라이선스에 돈을 내는 에이전트만 받는다고 밝혔고, Delta는 대리 발권을 막고 있습니다. JPMorgan Chase와 Charles Schwab은 보안을 이유로 계좌 접근 자체를 차단했습니다. 에이전트의 가치는 "접근할 수 있는 곳의 수"에 비례하는데, 그 수가 줄어들고 있습니다.

무엇이 확인됐나

The Verge가 10월 17일 보도한 내용을 중심으로, 확인된 사실과 사용자 제보를 구분해 정리하면 이렇습니다.

[접근 차단 현황 (2026년 10월)]

기관 차원에서 확인된 차단
- Yelp            : 데이터 라이선스 프로그램에 참여하는 에이전트만 허용
- Delta Air Lines : 사용자를 대신한 항공권 발권 차단
- JPMorgan Chase : 보안을 이유로 에이전트의 계좌 접근 차단
- Charles Schwab : 동일 (계좌 접근 차단)
- Amazon          : Perplexity의 에이전트 쇼핑 금지, 이후 소송

사용자 제보 (기관 확인은 아님)
- Cars.com, Amtrak 등에서 "이전엔 되던 에이전트가 막힘"
- Meta Muse 사용 계정이 Google에서 "의심스러운 활동"으로 차단된 사례
- Meta 파트너십이 있는 Walmart에서도 결제 단계 문제 보고

증상은 Meta의 Muse, xAI의 Grok, OpenAI의 Dots, 그리고 Instinct 같은 서비스 사용자들에게서 두루 나타납니다. 흥미로운 건 Amazon의 경우입니다. Amazon은 이미 2025년에 Perplexity의 에이전트 쇼핑 기능을 금지하고 소송을 냈습니다. 법원이 Perplexity에 중단을 명했지만, 2026년 8월 항소법원이 그 결정을 뒤집었고, Amazon은 다시 수정 소장을 냈습니다. 그 사이 Amazon은 Meta의 Muse에도 접근을 막았습니다.

두 가지 실패 모드

여기서 구분이 중요합니다. 에이전트가 막히는 방식은 두 가지이고, 대응도 다릅니다.

[실패 모드 1: 의도적 정책 차단]

사이트가 "일부러" 막는 경우
- 데이터 라이선스 (Yelp)
- 법적 책임·사기 위험 (금융 계좌)
- 광고 수익 (사람의 시선이 줄어듦)
→ 협상·라이선스·공식 API로 풀리는 문제


[실패 모드 2: 봇 방어 시스템의 오작동]

사이트가 에이전트를 겨냥하지 않았는데도 막히는 경우
- 스크래퍼·사기 봇을 막는 안전장치가 에이전트를 같은 부류로 인식
- Google의 "의심스러운 활동" 계정 차단, 결제 단계 실패 등
→ 기술·프로토콜 문제로, 사용자 계정이 다칠 수 있는 위험

AI 안전 평가 업체 EquiStamp의 Chris Canal은 이 두 번째 모드를 이렇게 설명합니다. 이런 장치들은 애초에 에이전트를 막으려고 만든 게 아니라 스크래핑이나 해킹을 막으려고 만든 것이고, 에이전트는 바로 그 안전장치를 건드린다는 것입니다. 그 결과 예약이나 결제를 시도하는 정당한 에이전트가 봇으로 분류됩니다.

왜 사이트는 막는가

가장 직접적인 이해관계는 광고입니다. Perplexity는 Amazon이 에이전트를 막는 이유가 "사람의 눈이 광고 앞에 덜 머무르기 때문"이라고 주장했습니다. 실제로 전자상거래에서 이는 중대한 문제입니다. 에이전트가 사람 대신 결제하면, 광고 노출과 상품 탐색 시간이 줄어듭니다.

그래서 흐름이 둘로 갈립니다. 하나는 차단이고, 다른 하나는 조건부 개방입니다.

[차단 vs 조건부 개방]

차단 쪽
- Amazon: Perplexity 에이전트 금지 → 소송
- Delta, JPMorgan, Charles Schwab: 접근 차단

조건부 개방 쪽
- Yelp: 라이선스 프로그램 참여 에이전트에 개방
- Meta: Walmart, Gap, Sephora, Best Buy 등과 제휴해 Muse 쇼핑 허용
- Shopify: 스토어프론트 카탈로그를 더 많은 AI 에이전트에 개방

정리하면 "에이전트를 받을 것인가"가 아니라 "어떤 조건과 어떤 통로로 받을 것인가"의 문제로 옮겨가고 있습니다. 인프라 업체도 이 흐름에 가담했습니다. Cloudflare는 2025년 AI 크롤러를 클릭 한 번으로 막는 기능을 내놨고, 이후 검색 인덱싱과 AI 학습을 동시에 하는 다목적 크롤러까지 차단했습니다. 크롤러 증가가 인터넷 인프라에 부담을 준다는 문제의식(EFF가 지적한 "AI 크롤러의 무게")과 맞물립니다.

대가: 사람도 함께 번거로워진다

Canal은 이 차단이 웹을 더 번거롭게 만들 수 있다고 봅니다. 더 많은 사이트가 "당신이 로봇이 아님을 증명하라"는 화면을 띄우면, 결국 사람이 장바구니 하나 쓰려고도 관문을 통과해야 한다는 것입니다.

[늘어나는 로봇 확인 관문]

- "로봇이 아닙니다" 체크와 이미지 퀴즈
- 로그인·본인 확인 단계 추가
- 계정 단위의 활동 이상 탐지

→ 정당한 사람과 정당한 에이전트가 같은 관문에서 함께 멈춘다

에이전트를 만드는 개발자에게

이 흐름은 "브라우저 에이전트를 만들었는데 사이트가 막는다"를 예외가 아니라 정상 상태로 다루게 만듭니다. 설계 원칙을 정리하면 이렇습니다.

[웹 접근을 다루는 에이전트 설계 원칙]

접근 경로 선택
- [ ] 공식 API를 우선 검토한다 (있으면 브라우저 자동화보다 안정적)
- [ ] 없으면 라이선스·제휴(예: 카탈로그 피드)로 정식 통로를 찾는다
- [ ] 브라우저 자동화는 마지막 수단으로 두고, 이용약관·robots.txt를 확인한다

차단을 정상 상태로 다루기
- [ ] 401/403/429, 로그인 벽, 캡차를 예상 상태로 모델링한다
- [ ] 차단 시 재시도 폭주 대신 안전하게 멈추고 사람에게 넘긴다
- [ ] 반복 재시도로 상대 서버에 부담을 주거나 계정을 위험에 빠뜨리지 않는다

사용자 보호
- [ ] 결제·예약 같은 비가역 행동은 사람 승인 뒤에 실행
- [ ] 사용자 계정이 정지될 수 있는 패턴(대량 로그인 등)을 피한다
- [ ] 개인정보·결제정보 취급 범위를 최소화하고 로그를 남긴다

운영
- [ ] 어떤 사이트가 언제 어떤 이유로 막았는지 기록한다
- [ ] 정책 변화를 감지하면 경로를 바꾸거나 기능을 끈다

핵심은 "막히면 어떻게 할 것인가"를 기능 설계의 첫 단계에 넣는 것입니다. 브라우저 자동화의 성공률은 상대 사이트의 정책에 달려 있고, 그 정책은 예고 없이 바뀝니다.

무엇을 선택할 것인가

같은 작업도 목적에 따라 정답이 다릅니다.

작업 권장 경로 이유
공개 데이터 조회 공식 API 또는 라이선스 피드 정책·과금이 명확, 안정적
항공·숙박 예약 공식 예약 API 우선, 브라우저 자동화는 보조 발권·결제는 차단 위험이 큼
금융 계좌 접근 원칙적으로 사람이 직접 보안·법적 책임이 큼
결제가 필요한 쇼핑 제휴·라이선스 채널 차단·소송 위험 회피
단순 정보 입력·정리 브라우저 자동화 가능 실패해도 되돌릴 수 있음

한계와 아직 정리되지 않은 것

이 주제는 사실관계가 계속 움직입니다. 짚어 둘 점은 이렇습니다.

[주의할 점]

- "모든 AI 에이전트를 일괄 차단"이 아니다. 사이트마다 정책이 다르다
- 차단 보도 상당수는 사용자 제보이고, 기관이 공식 확인한 것은 일부다
- 차단의 상당 부분은 에이전트를 겨냥한 게 아니라 일반 봇 방어의 부작용이다
- Amazon 대 Perplexity 소송은 항소로 결론이 뒤집혔고, 아직 진행 중이다
- "공식 API를 쓰면 안전하다"도 조건부다. API 약관과 접근 권한은 따로 확인해야 한다

결론: 접근 권한은 기능이 아니라 전제다

브라우저 에이전트의 성공 여부는 모델 성능이 아니라 "상대가 열어 주는가"에 달려 있습니다. 그래서 제품을 만들 때 물어야 할 질문도 바뀝니다. 이 작업을 공식 API로 할 수 있는가, 라이선스로 정식 통로를 열 수 있는가, 막혔을 때 사용자에게 무엇을 돌려줄 것인가. 차단은 예외가 아니라 기본 상태로 설계해야 합니다.

그래서 브라우저에서 도는 작은 자동화를 직접 만들어 보면 감이 빨리 옵니다. 어떤 화면이 로그인 벽을 세우는지, 어떤 요청이 차단을 부르는지, 실패했을 때 어떻게 안전하게 멈추는지를 몸으로 익히게 됩니다. 웹 자동화의 기초는 AI 바이브코딩 웹 개발에서, 크롤러 통제의 배경은 Cloudflare 웹 검색 API 게이트웨이에서, 그리고 검색·가져오기 API를 쓰는 방식은 DeepSeek Search·Fetch API로 에이전트 검색 붙이기에서 이어집니다.

함께 읽으면 좋은 글

참고 자료

이 주제를 직접 따라가며 배우고 싶다면

브라우저에서 도는 자동화는 결국 작은 도구를 직접 만들어 보면서 감이 옵니다. 로그인 벽과 차단 응답을 만나고, 실패했을 때 안전하게 멈추게 설계하는 경험을 해보면 왜 "접근 권한"이 기능의 전제인지 이해하게 됩니다.