아마존이 AI 에이전트를 막았어요 | 우리 서비스는 어떻게

📰 2026년 9월 22일 기준 최신 소식 | 이 글은 특정 시점의 뉴스를 다루고 있어요.

지난 일요일 밤부터 아마존 사이트에 팝업이 하나 뜨기 시작했어요. “승인되지 않은 AI 에이전트의 접근은 아마존 이용약관 위반입니다.” 메타가 내놓은 AI 비서 Muse가 사용자 대신 물건을 사려다 막힌 거예요.

남의 나라 플랫폼 싸움처럼 보이지만, 이 사건은 온라인 서비스를 운영하는 모든 회사에게 같은 질문을 던져요. 우리 서비스에 에이전트가 들어오면, 우리는 무엇을 할 건가요.

---

1. 무슨 일이 있었나요

아마존이 메타의 AI 에이전트 Muse의 아마존닷컴 접근을 차단했어요. Muse는 iOS·안드로이드·왓츠앱에서 쓰는 비서인데, 사용자를 대신해 상품을 찾고 결제까지 진행하는 기능이 있어요.

차단은 9월 21일 보도로 알려졌고, 이용자 화면에는 자동 결제가 막혔다는 안내가 떴어요. 아마존은 먼저 메타에 자발적으로 아마존을 대상에서 빼 달라고 요청했다고 밝혔어요.

우리가 볼 지점은 차단 자체가 아니라 그 이유예요. 기술적으로 막을 수 없어서가 아니라, 막을 근거를 어디에 뒀는지가 앞으로의 기준이 되거든요.

2. 아마존이 든 이유는 세 가지였어요

셋 다 성능이나 트래픽 이야기가 아니에요.

아마존이 든 이유	무엇을 문제 삼았나
사전 통보 없음	Muse가 아마존에 접근한다는 사실을 미리 알리지 않았어요
신원 미고지	에이전트가 접속할 때 자기가 누구인지 밝히지 않아요
자격증명 취급	고객의 로그인 정보를 수집·저장하는 것으로 보인다고 주장했어요

메타는 반박했어요. 가상머신을 따로 띄워 격리하고 감시용 에이전트를 붙여서, 비밀번호가 원문 그대로 노출되지 않게 저장한다는 설명이에요.

양쪽 주장 중 누가 맞는지는 아직 확인할 방법이 없어요. 다만 분쟁의 축이 어디에 놓였는지는 분명해요. 신원을 밝히는가, 남의 계정 정보를 어떻게 다루는가. 이 둘이에요. 사내 AI 에이전트를 만들거나 도입할 때도 같은 두 가지를 먼저 정해두면 나중에 설명이 쉬워져요.

3. 법정에서 갈린 지점은 “누가 접근했나”였어요

이번이 처음이 아니에요. 아마존은 올해 3월 퍼플렉시티를 상대로 예비적 금지명령을 받아냈는데, 8월 4일 제9연방항소법원이 이를 뒤집었어요.

법원 논리는 이랬어요. 연방 컴퓨터 부정접근 법률의 관점에서 아마존 시스템에 접근한 주체는 AI 회사가 아니라 그 에이전트를 시킨 사용자라는 거예요. 사용자는 이미 접근 권한이 있으니 부정접근이 아니라는 뜻이죠.

다만 판결은 한 갈래를 남겨 뒀어요. 계약과 이용약관을 근거로 한 청구예요. 이번에 아마존이 띄운 팝업 문구가 “이용약관 위반”인 이유가 여기 있어요.

용어 정리 — 에이전트는 사람이 지시한 목표를 받아 여러 단계를 스스로 수행하는 프로그램이에요. 검색만 하고 끝나는 크롤러와 달리 로그인하고 장바구니에 담고 결제까지 시도해요. 이용약관은 서비스와 이용자 사이의 계약이라, 법으로 못 막는 것도 약관으로는 막을 수 있는 경우가 있어요.

정리하면, 지금 이 영역에서 실제로 힘을 갖는 문서는 법이 아니라 우리 서비스의 약관이에요.

4. 우리 서비스에도 곧 같은 질문이 와요

에이전트가 남의 사이트에 들어가 행동하는 흐름은 이제 특정 회사 기능이 아니에요. 예약·주문·조회처럼 절차가 정해져 있는 일부터 넘어오고 있어요.

그래서 서비스를 운영하는 쪽에서는 세 가지가 한꺼번에 애매해져요.

• 통계가 흔들려요. 에이전트 방문이 사람 방문으로 잡히면 전환율·체류시간이 전부 틀어져요.
• 부하가 달라져요. 사람은 화면을 읽느라 쉬는데, 에이전트는 쉬지 않아요.
• 책임이 애매해져요. 에이전트가 잘못 주문했을 때 취소와 환불은 누구와 이야기하나요.

기업 ai 도입 사례를 들여다보면 대부분 “우리가 AI를 어떻게 쓸까”에 집중돼 있어요. 그런데 이 사건이 보여주는 건 반대 방향이에요. 남의 AI가 우리 서비스를 쓰러 오는 상황이고, 이쪽은 준비된 회사가 거의 없어요.

5. 선택지는 세 갈래예요

전부 막거나 전부 여는 게 아니라, 구간을 나누는 선택이에요.

선택	어떻게 하나	맞는 경우	치르는 값
차단	약관에 금지를 명시하고 탐지되면 접근을 끊어요	계정·결제·개인정보가 걸린 서비스	에이전트를 통한 유입을 잃어요
방치	따로 손대지 않아요	정보 제공 위주, 로그인 없는 서비스	통계 오염과 부하를 그대로 받아요
전용 통로	에이전트용 API를 따로 열고 신원 확인을 요구해요	주문·예약처럼 절차가 정해진 서비스	개발과 운영 비용이 들어요

대부분은 세 번째로 가되, 한 번에 가지는 않아요. 둘러보기는 열고 되돌리기 어려운 동작만 닫는 것부터 시작하면 돼요. 결제, 개인정보 조회, 취소처럼요.

에이전트 트래픽을 어디까지 허용할지는 기술 결정이 아니라 사업 결정이에요. 우리 서비스에서 어느 동작이 되돌리기 어려운지부터 같이 짚어 보고 싶으시면 편하게 물어봐 주세요 →

6. 지금 발주서에 넣을 수 있는 것은 무엇일까요

새 시스템을 만들거나 리뉴얼을 준비 중이라면, 다음 다섯 줄은 지금 넣어도 비용이 크게 늘지 않아요. 나중에 붙이면 훨씬 비싸지고요.

1. 접속 기록에 신원 정보를 남겨요 — 어떤 클라이언트가 어떤 경로로 들어왔는지 기록해요.
2. 속도 제한을 둬요 — 같은 계정이 짧은 시간에 반복 호출하면 제한해요.
3. 되돌리기 어려운 동작에 확인 단계를 둬요 — 결제·삭제·취소는 사람 확인을 거치게 해요.
4. 약관에 자동화 접근 조항을 넣어요 — 허용 범위와 금지 범위를 문장으로 적어 둬요.
5. 에이전트용 통로를 나중에 열 수 있게 설계해요 — 화면과 기능을 분리해 두면 나중이 쉬워요.

5번이 제일 중요해요. 화면 안에만 기능이 박혀 있으면 에이전트용 통로를 여는 순간 기능을 다시 짜야 해요. 처음부터 기능을 API로 빼 두면 그때 가서 문을 하나 더 다는 정도로 끝나요.

직접 운영해보니 — 저희가 롯데백화점 수원 푸드홀 실시간 혼잡도 시스템을 만들 때, 여러 센서가 동시에 데이터를 보내면서 취합이 지연되는 일을 겪었어요. 사람이 쓰는 속도를 전제로 만든 구조는 기계가 들어오는 순간 무너져요. 에이전트 트래픽도 성질이 같아요. 지금은 양이 적어서 안 보일 뿐이에요.

7. 사내에서 에이전트를 쓰는 쪽이라면 무엇을 확인해야 할까요

반대편, 그러니까 에이전트를 쓰는 입장에서도 이번 사건은 경고예요. 아마존이 문제 삼은 항목이 그대로 우리 회사 내부에 적용될 수 있거든요.

• 그 도구가 우리 계정 정보를 어디에 저장하나요? 원문 그대로인가요, 아닌가요.
• 외부 서비스에 접속할 때 자기 신원을 밝히나요?
• 무슨 일을 했는지 기록이 남나요? 나중에 확인할 수 있나요.
• 상대 서비스의 약관을 위반할 가능성은 검토했나요?

특히 마지막 항목이 잘 안 다뤄져요. AI 에이전트 도입 검토는 보통 성능과 비용으로 시작하는데, 이번처럼 상대 쪽에서 막아 버리면 성능과 상관없이 그 업무가 멈춰요. 신원 보안용 에이전트 ai처럼 확인 절차가 붙은 형태가 논의되는 것도 이 때문이에요.

AI 에이전트 도입을 준비하고 있다면, 도구를 고르기 전에 AI 에이전트 권한을 어디까지 열어야 할까요를 함께 보셔도 좋아요.

8. 자주 묻는 질문

우리 서비스에 AI 에이전트가 들어오는지 어떻게 알 수 있나요?

접속 기록(로그)에서 먼저 보여요. 사람이라면 나올 수 없는 패턴이 있거든요. 화면을 거의 안 보고 특정 API만 반복해서 부르거나, 새벽에 초 단위로 같은 흐름을 도는 접속이 그래요. 자기 신원을 밝히는 에이전트는 접속 정보에 이름을 적어 두기도 하고요. 문제는 그런 항목을 기록으로 남기고 있느냐예요. 에이전트 이야기는 나중에 하더라도, 누가 어떤 경로로 들어오는지 남기는 설정은 지금 해두는 편이 좋아요.

에이전트를 막으면 매출이 줄지 않을까요?

지금 시점에서는 양쪽 다 근거가 얇아요. 에이전트를 통한 구매가 얼마나 되는지 공개된 국내 데이터가 거의 없거든요. 그래서 전면 차단이나 전면 허용보다, 구간을 나누는 쪽을 권해요. 둘러보기는 열어 두고 결제·개인정보 조회처럼 되돌리기 어려운 동작만 사람 확인을 요구하는 식이에요. 이러면 노출은 지키면서 위험한 자리만 닫을 수 있어요.

ai 자체 도입과 외주 개발 중 어떤 선택이 맞나요?

이 주제만 놓고 보면 기준이 비교적 분명해요. 접근 통제·로그·속도 제한처럼 서비스 전반에 걸리는 일은 우리 시스템 구조를 아는 쪽이 해야 빨라요. 반면 에이전트 전용 통로를 새로 만드는 일처럼 범위가 떨어져 나오는 작업은 외부에 맡기기 좋고요. 판단이 어렵다면 한 가지만 보세요. 이 일을 하려면 기존 코드를 얼마나 건드려야 하는지. 많이 건드려야 하면 안에서, 붙이는 수준이면 밖에서 하는 편이 대체로 맞아요.

9. 마무리

아마존과 메타의 다툼은 결국 세 문장으로 줄어요. 미리 알렸는가, 신원을 밝혔는가, 남의 계정 정보를 어떻게 다뤘는가.

세 질문 모두 기술 질문처럼 보이지만 답은 문서에 있어요. 약관과 요구사항 정의서죠. 작년까지는 크롤러가 우리 글을 읽어가는 게 문제였고, 올해는 에이전트가 우리 서비스를 사용하는 것이 문제가 됐어요. 자료를 누가 읽어갈지 정하는 문제는 검색은 열고 학습만 닫는 설정에서 한 번 다뤘는데, 이번 건은 그다음 단계예요.

지금 당장 무언가를 막을 필요는 없어요. 다만 우리 서비스에서 되돌리기 어려운 동작이 무엇인지 목록으로 적어 두는 일은, 오늘 해도 늦지 않아요.

저희는 10년 넘게 50개 이상의 프로젝트를 진행하고 자체 SaaS 4종을 직접 운영해온 개발사예요. 롯데·캐논 같은 곳과도 함께해 왔고요. 새 기술이 들어올 때 먼저 보는 건 기능보다 운영에서 무엇이 흔들릴지예요.