2026년 8월 4일, 미국 제9 순회 항소법원은 3월부터 Perplexity Comet 에이전트가 Amazon 사용자 계정에 접근하는 것을 막고 있던 임시 금지 명령을 취소했습니다. 공식적으로 이는 인공지능을 통한 구매에 관한 두 기업 간의 분쟁입니다. 사실상 이는 에이전트 상업을 넘어서는 중요한 질문에 대한 첫 번째 항소 판결입니다: 자동화가 요청을 보낼 때, 누가 정확히 다른 서버에 "접근"하는가. 그리고 법원의 답변은 의외로 법이 아니라 네트워크 아키텍처에 기반했습니다.
무슨 일이 있었나: 소송에서 금지 해제까지
분쟁의 연대기는 다음과 같습니다:
- 2025년 11월 — Amazon은 Perplexity AI를 상대로 소송을 제기하며 연방 컴퓨터 사기 및 남용법(CFAA)과 그 캘리포니아 주 유사 법률을 인용했습니다. 주장: Comet 에이전트가 사용자 계정에 로그인하여 상품을 조회하고 구매를 시작하며, 즉 사이트의 승인 없이 비밀번호로 보호된 영역에서 작동하고 있다는 것입니다.
- 배경 — Amazon에 따르면, 회사는 2024년 11월부터 최소 다섯 차례 Perplexity에 경고했으며, 2025년 8월에는 기술적 장벽을 설치했지만 Perplexity는 하루 만에 이를 우회하는 업데이트를 출시했습니다. 별도의 비난: 에이전트가 일반 Google Chrome 세션으로 위장했습니다.
- 2026년 3월 9일 — 맥신 체스니 판사(캘리포니아 북부 지방법원)는 임시 금지 명령을 내리고 Amazon으로부터 받은 데이터를 파기하라고 명령했습니다. 그녀의 공식 입장은: 접근은 Amazon 사용자의 허가로 이루어졌지만 Amazon의 승인 없이 이루어졌다는 것입니다.
- 2026년 8월 4일 — 제9 순회 항소법원(사건 번호 26-1444)은 금지 명령을 취소했습니다: Amazon이 CFAA 주장에 대해 본질적으로 승소할 가능성이 낮다고 판단했습니다.
Amazon은 이 결정에 동의하지 않으며 분쟁을 계속할 것이라고 밝혔습니다. Perplexity는 사용자가 원하는 어떤 인공지능도 선택할 권리를 옹호할 것이라고 응답했습니다. 이 사건은 여전히 진행 중이며, Amazon은 재심을 요청하거나 상급 법원으로 갈 수 있습니다.
핵심 포인트: 에이전트는 도구일 뿐, 인물이 아니다
CFAA는 승인 없이 "보호된 컴퓨터"에 접근하는 것을 처벌합니다. 모든 분쟁은 한 동사로 귀결되었습니다: 누가 접근 행위를 했는가. Amazon은 Perplexity가 그들의 에이전트가 플랫폼에서 활동했기 때문에 접근했다고 주장했습니다. Perplexity는 사용자가 에이전트에게 명령을 내렸다고 반박했습니다.
항소법원은 두 번째 입장을 취하며 이를 명확히 표현했습니다: 에이전트가 아무리 진보하더라도 법의 목적상 "it is a tool, not a person" — 도구일 뿐, 인물이 아닙니다. 사용자가 Amazon.com에서 에이전트에게 어떤 작업을 지시할 때, Amazon의 컴퓨터에 대한 접근은 바로 사용자가 수행하는 것입니다.
이는 Van Buren v. United States (2021) 사건에서의 대법원의 논리적 연속으로, CFAA를 좁혔습니다: 법은 접근이 전혀 없는 곳으로의 침입을 처벌하며, 합법적인 접근을 "용도에 맞지 않게" 사용하는 것을 처벌하지 않습니다. Amazon 사용자는 계정이 있으며, 그 계정에 접근할 권리가 있습니다. 그가 이를 수행하는 도구는 스스로 해킹의 주체가 되지 않습니다.
왜 모든 것이 트래픽 아키텍처로 결정되었는가
실무자들에게 가장 흥미로운 판결의 부분은 기술적입니다. 법원은 Comet Assistant가 물리적으로 어떻게 구성되어 있는지를 분석하였고, 이것이 판결의 결과를 결정했습니다.
작동 방식은 다음과 같습니다: 에이전트는 사용자의 기기에서 브라우저 창의 스크린샷을 찍어, 이를 Perplexity 서버로 전송하고, 그곳에서 사용자 컴퓨터로 돌아오는 내비게이션 지침을 받습니다. Perplexity 서버는 Amazon 서버와 직접 통신하지 않습니다. Amazon이 자신의 시스템에서 보는 모든 트래픽은 사용자 자신의 장치와 IP 주소에서 발생합니다.
여기서 법원의 결론이 나옵니다. 요청이 물리적으로 사용자로부터 발생한다면, CFAA의 의미에서 "접근"은 그 사용자가 수행한 것입니다.
이것이 Power Ventures와 어떻게 다른가
지금까지 제3자의 접근에 대한 사용자 동의의 전형적인 사례는 Facebook v. Power Ventures (2016) 사건이었습니다. 그 사건에서 법원은 플랫폼이 제3자 서비스의 접근을 철회할 수 있다고 판단했습니다. 사용자가 자발적으로 자신의 로그인 정보를 제공했더라도 말입니다. 바로 이 선례를 1심 판사가 인공지능 에이전트에 적용했습니다.
제9 순회 항소법원은 이 사건을 하나의 기준으로 분리했습니다 — 그리고 다시 아키텍처적 이유로. Power Ventures 사건에서 피고의 시스템은 사용자의 기기를 우회하여 Facebook 플랫폼에 직접 메시지를 보냈습니다. Perplexity는 그런 경로가 없습니다. 트래픽의 서로 다른 토폴로지는 "누가 접근했는가"라는 질문에 대한 서로 다른 답변을 제공합니다.
이 구분의 실질적인 의미는 과대 평가하기 어렵습니다. 이는 시스템의 설계 — 사용자 기기에서의 클라이언트 에이전트 또는 자신의 인프라에서 플랫폼으로 접근하는 서버 서비스 — 가 순전히 엔지니어링 선택이 아니라 법적 논거가 되었다는 것을 의미합니다.
결정이 하지 않은 것들
법원은 스스로 최대한 영향력을 제한하려고 노력했으며, 에이전트 인공지능을 위한 새로운 법적 체계를 만들지 않는다고 명확히 밝혔습니다. 다음은 제외된 사항들입니다:
- 사용자 계약 위반. 계약, 불법 행위 및 플랫폼 규칙에 대한 주장들은 이 결정으로 종료되지 않으며, 별도로 제기할 수 있습니다.
- 사용자에 대한 소송. 접근이 사용자가 수행한 것이라면, 플랫폼은 그 사용자에게 주장할 수 있습니다.
- 서버 아키텍처. 이 결론은 특정 구조에 대해 내려졌습니다. 클라우드 스크래퍼나 자신의 인프라에서 플랫폼에 접근하는 SaaS 에이전트는 이 논리에 자동으로 포함되지 않습니다.
- 기술적 차단. 이 결정에서 Amazon이 자동화를 탐지하고 차단하는 것을 금지하는 단어는 없습니다. 차단할 권리는 여전히 존재하며, 형사법으로 차단을 뒷받침할 수 있는 가능성이 사라졌습니다.
이는 사실, 기존의 그림을 뒤집는 것입니다: 이전에는 자동화하는 쪽이 법적 위험을 안고 있었고, 기술적 보호는 두 번째 방어선으로 여겨졌습니다. 이제 플랫폼에게 기술적 보호는 첫 번째 방어선이 되었습니다.
이것이 실제로 무엇을 변화시키는가
데이터를 수집하거나 계정을 자동화하거나 에이전트를 구축하는 모든 이들에게 이 결정은 세 가지 실질적인 결론을 제공합니다.
1. 트래픽 출구 지점이 법적 중요성을 얻었다
이전에는 "모든 것을 자신의 데이터 센터를 통해 전송한다"와 "사용자와 구별할 수 없는 주소에서 작업한다"는 선택이 통과 가능성과 비용에 관한 문제였습니다. 이제 이는 요청이 누구의 행동으로 간주되는가에 대한 문제이기도 합니다. 플랫폼에 대한 접근이 사용자 측에서 발생하는 아키텍처는 법원에서 더 잘 보호될 수 있으며, 역사적으로도 자동화 방지 필터를 더 잘 통과합니다. 이는 법적 및 기술적 유인이 일치하여 주거용 프록시와 사용자 출구 지점을 서버 서브넷 대신 사용하는 방향으로 나아가는 드문 사례입니다. 공개 가격 모니터링이나 지역별 검색 결과 검증과 같은 중립적인 작업에는 여전히 데이터 센터 프록시가 충분합니다 — 로그인 영역이나 계정에 대한 분쟁이 없습니다.
2. CFAA가 약화되고 계약 및 탐지가 강화되었다
이 결정을 "이제 할 수 있다"고 읽어서는 안 됩니다. 가장 무거운 무기가 제거되었습니다 — 형사적 잠재력을 가진 연방 조항입니다. 남은 것은 사용자 계약, 계정 차단, 민사 소송, 그리고 가장 중요한 자동화 방지 스택입니다. 플랫폼은 법적 지렛대를 일부 잃었지만, 탐지로 이를 보완할 것입니다: 핑거프린팅, 행동 분석 및 서명된 에이전트들. 산업이 "좋은" 봇을 기술적으로 합법화하려고 시도하는 방법에 대해서는 Web Bot Auth 및 서명된 에이전트에 대한 자료에서 다뤘습니다.
3. 위험이 최종 사용자에게 이동했다
Perplexity의 승리의 반대편: 사용자가 행동한다면, 사용자도 책임을 집니다. 고객에게 자동화를 제품으로 제공하는 서비스들은 문서에서 누가 어떤 IP로 행동을 수행하는지, 그리고 어떤 플랫폼 규칙이 관련되는지를 솔직하게 설명할 필요가 있습니다.
지금 당장 해야 할 일
- 접근 토폴로지를 설명하십시오. 한 가지 질문에 답하십시오: 목표 플랫폼이 로그에서 보는 IP는 서버의 것인가, 사용자 것인가. 이것이 법적 입장과 탐지 프로필에 영향을 미칩니다.
- 공개와 로그인된 것을 분리하십시오. 공개 페이지 수집과 다른 계정 내에서의 행동은 위험 측면에서 본질적으로 다른 이야기입니다. 이를 하나의 파이프라인에서 혼합하지 않는 것이 좋습니다.
- 직접적인 금지 이후 공격적으로 위장하지 마십시오. 이 사건에서 바로 설정된 장벽을 우회하고 Chrome으로 클라이언트를 위장한 것이 Amazon에게 가장 강력한 사실을 제공했습니다. CFAA 주장은 무너졌지만, 다른 근거들은 여전히 살아 있습니다.
- 작업에 맞는 출구 유형을 선택하십시오. 에이전트를 Playwright 또는 MCP에서 실행하고 트래픽을 올바르게 포장하는 방법에 대해서는 AI 에이전트를 위한 프록시 가이드에서 자세히 다뤘습니다.
결론
제9 순회 항소법원은 자동화를 합법화하지 않았고 에이전트들에게 어디든지 갈 수 있는 통행증을 발급하지 않았습니다. 그들은 "접근"이라는 개념을 요청이 물리적으로 어디에서 발생하는지에 연결하는 더 좁지만 더 중요한 일을 했습니다. 사용자의 기기에서 작동하는 도구는 접근을 수행하지 않습니다 — 그것은 사람이 수행합니다. 자신의 인프라에서 플랫폼으로 접근하는 인프라는 여전히 기존의 위험 영역에 남아 있습니다.
시장은 중심이 이동하고 있음을 의미합니다. "할 수 있는가"에 대한 법적 분쟁은 점점 더 "로그에서 누구의 주소인가"라는 엔지니어링 질문으로 귀결될 것입니다. 그리고 접근을 위한 싸움은 결국 그동안 진행되어 온 곳으로 완전히 이동하게 됩니다 — 자동화 방지 탐지, 핑거프린팅 및 출구 지점의 품질로.