AI 에이전트 차단 설계의 역설 — 주문 확인 메일이 비어버린 이유와 설계 원칙 3가지

주문한 이어폰이 언제 도착하는지 보려고 아마존 확인 메일을 열었어요. 본문에는 감사 인사 한 줄과 버튼 하나뿐이었습니다. 상품명도, 금액도 없더군요. 결국 앱을 켜고 로그인해서 주문 내역까지 들어가야 했습니다. 몇 년 치 영수증을 메일함에 쌓아둔 사람에겐 꽤 성가신 변화죠. 저는 이 변화를 단순한 디자인 정리로 보지 않습니다. AI 에이전트의 메일함 접근을 막으려는 자동화 설계가, 정작 그 메일을 읽는 사람의 정보까지 함께 걷어낸 결과라고 생각하거든요.

주문 확인 메일에서 상세 정보가 왜 사라졌나요?

The Verge 는 아마존 주문 확인 메일에서 상품명과 가격 같은 상세가 빠진 현상을 다뤘습니다. 배경으로 지목된 건 서드파티 AI 에이전트였어요. 메일함을 긁어 쇼핑 데이터를 모으는 도구가 늘자, 발신자 쪽에서 본문에 담기는 정보를 줄였다는 해석이죠. 구글 지메일이 메일 데이터를 AI 기능에 쓰는 흐름도 함께 거론됐고요. 출처: The Verge 보도(2026).

이 기사는 해커뉴스에서 8월 19일 기준 62포인트와 댓글 27개를 받았어요. 제 메일함도 뒤져봤습니다. 3년 전 주문 메일에는 품목과 결제액이 그대로 박혀 있는데, 올해 것들은 껍데기만 남아 있더라고요. 검색창에 물건 이름을 넣어도 안 걸립니다. 자동화가 읽지 못하게 만든 텍스트는 사람도 검색하지 못하니까요.

봇을 막으려던 설계가 사람까지 밀어내는 이유

차단 설계는 대체로 행위가 아니라 환경을 봅니다. 어느 IP에서 왔는지, 브라우저 지문이 어떤지를 먼저 따지죠. 저는 이 방식에 두 번 크게 당했어요.

지난 7월, 우리 자동화 파이프라인이 레딧 공개 데이터를 받으려는데 JSON 엔드포인트가 데이터센터 IP에서 403을 뱉었습니다. 결국 RSS 피드로 경로를 바꿔 해결했는데, 대규모 수집 업체라면 프록시 한 줄로 끝냈을 문제예요. 8월 12일에는 교차발행 기계를 통째로 걷어냈습니다. 티스토리를 그만 쓰면서 글이 실제로 나가던 유일한 통로가 사라졌고, 남은 velog·Medium 은 클라우드플레어 터너스타일이 지문 단계에서 막아 발행 이력이 0건이었거든요.

환경 기반 차단은 악의를 걸러내지 못하고 능력을 걸러냅니다. 우회할 자원이 있는 쪽은 통과하고, 없는 쪽만 벽 앞에 남죠. 주문 확인 메일도 같은 구조라고 봅니다. 상세를 지우면 메일함을 긁던 AI 에이전트는 앱 화면을 읽는 쪽으로 옮겨가고, 벽에 부딪히는 건 메일 한 통으로 금액을 확인하려던 사람이에요.

정보를 감춘 쪽은 정말 이득을 볼까요?

플랫폼 입장에서 자동화 방어의 계산은 단순해 보입니다. 데이터를 앱 안에 가두면 방문이 늘고, 외부 도구가 가져가는 몫은 줄어드니까요. 저는 이 계산에서 빠진 항목이 있다고 봐요.

이 설계 변경 뒤에 제가 직접 재봤습니다. 메일 본문에서 바로 보이던 결제액을 앱에서 확인하는 데 로그인 포함 2분 40초가 걸리더군요. 제 주문 빈도가 연 40건쯤이니 1년이면 100분 넘게 쓰는 셈이죠. 더 아픈 쪽은 기록입니다. 예전에 배송 사고로 환불을 다툴 때 제가 내민 증거가 바로 그 확인 메일이었거든요. 거기서 품목과 금액이 빠지면 소비자는 분쟁에서 쓸 카드를 하나 잃습니다.

자동화 설계가 방어 하나로 좁혀지면 사용자 가치는 남는 자리에만 놓여요. 이건 취향 차이가 아니라 우선순위 문제입니다.

"개인정보를 지키려면 어쩔 수 없다"는 반론

첫 반론은 정당합니다. 메일함을 통째로 읽는 서드파티 도구는 실제 위험이에요. 다만 수단이 과녁을 빗나갔습니다. 정보를 지운다고 에이전트가 사라지지 않고, 계정 연동이나 화면 읽기로 경로만 바뀌거든요. 위험은 그대로 남고 불편만 사람 몫이 되는 셈이죠.

두 번째 반론은 비용입니다. 누가 무엇까지 읽을지 나누는 권한 설계에는 돈과 시간이 들죠. 맞는 말인데, 아마존은 이미 정교한 권한 관리를 굴리는 회사예요. 못 하는 게 아니라 안 하기로 한 선택에 가깝다고 봅니다.

세 번째는 운영자들의 경험담이에요. 크롤러 때문에 서버가 죽어본 사람은 그런 말 못 한다는 지적이죠. 그래서 우리는 막을 때도 사람이 쓰는 통로 하나는 열어둡니다. 공개 문서와 피드는 인증 없이 두고, 무거운 조회에만 제한을 걸어요. 차단에도 출구 설계가 필요하다고 믿거든요.

자동화 설계에서 지키려는 선 세 가지

저희 파이프라인의 검증자 다섯에겐 차단권만 있고, 통과를 단독으로 승인할 권한은 없습니다. 막는 쪽에도 한계를 두려고 만든 규칙이에요. 같은 태도를 서비스 설계로 옮기면 세 가지가 남습니다.

• 무언가를 가릴 땐 가린 만큼 같은 내용을 다른 채널에 내놓는다
• 차단 판정은 요청자의 정체가 아니라 요청의 행위량을 기준으로 삼는다
• 사람이 쓰는 통로는 로그인 없이 하나 남긴다

우리가 만드는 자동화도 매번 같은 질문 앞에 섭니다. 이번 주에 무언가를 감추기로 했다면, 그 결정은 누구를 보호했나요? 답에 회사 이름밖에 없다면 설계를 다시 열어볼 때죠.

자주 묻는 질문

Q. 국내 쇼핑몰 주문 메일도 같은 방향으로 가고 있나요?

A. 제가 8월에 확인한 국내 몰 세 곳은 상품명과 결제액이 그대로 있었고, 자동화 방어의 흔적은 안 보였습니다. 판단 기준은 하나예요. 본문만 보고 얼마 냈는지 알 수 있으면 기록용으로 쓸 만합니다.

Q. AI 에이전트에 메일 접근을 허용할 때 뭘 봐야 하나요?

A. 권한 범위입니다. 대부분 전체 읽기로 열리니까 발신자나 라벨로 범위를 좁힐 수 있는지부터 확인하세요.

Q. 소비자가 지금 당장 할 수 있는 대비가 있을까요?

A. 고가 주문만 상세 화면을 PDF로 저장해 두세요. 저는 건당 20초쯤 씁니다. 스크린샷과 달리 파일 생성 시각이 남아서 나중에 근거로 쓰기 좋더라고요.

Q. 차단과 개방을 가르는 실무 기준이 있나요?

A. 저는 시간을 잽니다. 그 경로를 막았을 때 사람이 대체 경로로 30초 안에 닿으면 막아도 됩니다. 로그인이나 앱 설치가 끼어들면 다시 검토해요.