[AI Frontier] 웹은 하나인데, 사람과 AI는 다르게 읽기 시작했다

[AI Frontier]

웹은 이제 두 종류의 사용자를 상대한다. 사람은 화면을 읽고 클릭한다. AI 에이전트는 정보를 찾아 도구를 호출한다.

웹은 하나인데, 사람과 AI는 다르게 읽기 시작했다

8월 25일, 인공지능(Artificial Intelligence, AI) 에이전트용 웹 검색 인프라를 표방한 Keenable이 공개됐다. 회사 측은 1,000억 개가 넘는 웹 문서를 색인했으며 일부 AI 연구소와 추론 서비스 업체가 학습·실행 단계에서 자사 응용프로그램 인터페이스(Application Programming Interface, API)를 쓰고 있다고 TechCrunch에 밝혔다.

한 회사의 등장만으로 웹이 바뀌었다고 단정하기는 이르다. 최근 신호를 나란히 놓으면 흐름은 보인다. Cloudflare는 8월 초 AI 에이전트를 위한 브라우저 Kitesurf를 공개했고 웹사이트가 에이전트에게 사용 가능한 기능을 직접 알려주는 WebMCP 개발자 프리뷰도 내놨다. Reuters는 7월부터 구독 뉴스 콘텐츠를 AI 에이전트가 직접 검색하고 가져갈 수 있는 모델 컨텍스트 프로토콜(Model Context Protocol, MCP) 서버를 제공하고 있다.

인터넷이 사람용과 AI용으로 둘로 쪼개진다는 얘기는 아니다. 같은 웹 위에 사람을 위한 화면과 에이전트를 위한 인터페이스가 나란히 생기고 있다. 기업의 질문도 달라진다. 사이트가 보기 좋은가만 볼 게 아니라 에이전트가 정보를 찾고 정확히 읽고 필요한 기능을 안전하게 실행하는지도 따져봐야 한다.

SYSTEM SUMMARY

사람이 사용하는 웹 · 검색 → 결과 선택 → 페이지 읽기 → 클릭·입력 → 행동

에이전트가 사용하는 웹 · 발견 → 구조화된 읽기 → 기능 발견 → 권한 확인 → 도구 호출·행동

AI 에이전트용 웹은 무엇이 다른가

기존 웹은 사람을 기준으로 설계됐다. 검색 결과의 제목과 설명을 보고 링크를 고른다. 사이트에 들어가면 메뉴, 화면 구성, 버튼, 이미지, 표를 살펴보며 다음 행동을 결정한다.

AI 에이전트는 같은 목적을 꼭 같은 방식으로 처리할 필요가 없다. 메뉴를 눈으로 읽는 대신 사이트맵이나 구조화된 데이터를 먼저 본다. 긴 페이지 전체를 그리지 않은 채 필요한 본문만 가져오기도 한다. API나 MCP 도구가 열려 있다면 화면에서 버튼 위치를 추측하기보다 해당 기능을 직접 호출한다.

에이전트용 웹은 새로운 디자인 유행이 아니다. 사람을 위한 사용자 인터페이스 옆에 기계가 읽기 쉬운 정보 구조와 행동 인터페이스가 하나 더 붙는 변화다.

구분	사람 중심 웹	에이전트 중심 웹
발견	검색 결과와 링크 순위	검색 API, 색인, 메타데이터
읽기	화면, 글, 이미지, 메뉴	본문, 구조화 데이터, 기계 판독 정보
이동	메뉴와 링크 클릭	정보 탐색과 도구 발견
행동	버튼 클릭과 폼 입력	API·MCP 호출 또는 브라우저 자동화
성과	방문, 클릭, 전환	인용, 추천, 호출 성공, 에이전트 경유 전환

검색은 링크보다 근거 조립 쪽으로 움직인다

사람이 검색할 때는 몇 개의 키워드를 입력하고 결과 중 하나를 고르는 흐름이 익숙하다. 검색엔진은 어떤 문서를 위에 보여줄지 정하고 사용자는 제목과 설명을 읽은 뒤 클릭한다. 검색 결과 페이지 자체가 핵심 인터페이스였다.

에이전트가 맡는 일은 조금 다르다. 한 문서를 찾고 끝나는 대신 여러 자료를 비교해 필요한 내용을 골라 하나의 판단으로 묶는 작업이 많다. Keenable이 내세우는 것도 사람에게 열 개의 파란 링크를 보여주는 검색보다 AI가 대규모 웹 문서에서 필요한 근거를 빠르게 좁혀서 가져오는 검색 인프라다.

아직 Keenable이 에이전트 검색의 표준이라고 볼 근거는 없다. 1,000억 개 이상의 문서를 색인했다는 수치와 고객 사용 현황도 회사 측 설명에 기댄다. 다만 검색 인프라에 새로운 사용자가 들어오고 있다는 신호는 분명하다. 새로 들어온 사용자는 사람만이 아니다. 검색 결과를 다음 작업의 입력값으로 쓰는 소프트웨어도 있다.

브라우저가 화면 대신 작업비용을 보기 시작했다

브라우저도 사람을 기준으로 만들어졌다. 탭, 테마, 확장 프로그램, 화면 전환, 렌더링 품질은 사람에게 중요하다. 에이전트에서는 우선순위가 달라진다. 긴 화면을 보는 대신 필요한 HTML을 뽑는다. 일부 화면만 확인해 다음 행동에 필요한 정보만 컨텍스트에 담는 쪽이 효율적이다.

Cloudflare가 공개한 Kitesurf는 이 차이를 앞세운 브라우저다. 회사는 스크린샷과 HTML 추출 같은 일반적인 에이전트 작업에서 Kitesurf가 Chromium보다 중앙처리장치(Central Processing Unit, CPU)와 메모리를 3~7배 적게 사용했다고 자체 테스트 결과를 공개했다.

3배냐 7배냐보다 눈여겨볼 부분은 최적화 대상이다. 사람용 브라우저가 화면 경험을 다듬는다면 에이전트용 브라우저는 컨텍스트 크기, 연산비용, 동시 실행 수, 지연시간을 먼저 본다. 프롬프트 주입처럼 기존 브라우저 보안과 다른 공격 경로도 함께 관리해야 한다.

NOTE

에이전트용 웹이 항상 API만 쓴다는 뜻은 아니다. API가 없는 기존 웹에서는 브라우저가 여전히 필요하다. 브라우저 자체의 최적화 기준도 사람의 시각 경험에서 에이전트의 작업비용으로 옮겨갈 수 있다는 뜻이다.

웹페이지가 문서에서 도구로 바뀌는 지점

더 큰 변화는 웹이 정보를 읽는 공간을 넘어 일을 요청하는 인터페이스가 되는 순간에 나타난다. MCP는 AI 애플리케이션이 외부 데이터와 도구를 일정한 방식으로 발견하고 사용할 수 있게 연결하는 공개 표준이다. 서버는 자료를 제공하기도 하고 데이터베이스 조회나 외부 시스템 작업 같은 도구를 열어두기도 한다.

Reuters 사례는 이 변화를 이해하기 쉽다. Reuters는 구독 고객이 AI 에이전트로 자사 뉴스 콘텐츠를 검색하고 가져와 업무 흐름에 사용할 수 있는 MCP 서버를 7월 공개했다. 사람이 뉴스 사이트에서 기사를 하나씩 찾는 경로와 별도로 승인된 AI 시스템이 필요한 콘텐츠를 직접 가져가는 길을 만든 셈이다.

Cloudflare가 개발자 프리뷰로 공개한 WebMCP는 웹사이트 자체를 에이전트가 사용할 수 있는 도구 인터페이스로 바꾸려는 접근이다. 에이전트가 화면의 버튼 위치를 추측하며 클릭하는 대신 사이트가 허용한 작업을 명시적으로 알려준다. 아직 실험 단계라 웹의 보편적 표준이라고 보기는 어렵다.

그래도 기업이 던질 질문은 달라진다. 웹사이트 경쟁력을 화면 디자인만으로 설명하기 어려워진다. 정보가 기계가 읽을 수 있는 형태인지, 필요한 기능을 호출할 수 있는지, 그 호출 권한은 누구에게 있는지가 제품 설계의 일부가 된다.

에이전트 트래픽은 페이지뷰만으로 설명하기 어렵다

기존 검색엔진과 웹사이트 사이에는 비교적 익숙한 교환관계가 있었다. 검색엔진이 콘텐츠를 수집해 결과에 노출하면 일부 사용자가 원래 사이트를 방문한다. 그 방문은 광고 노출, 구독, 상품 구매 같은 수익 기회로 이어졌다.

AI 에이전트는 이 관계를 흔든다. 사용자는 에이전트의 답변만 받고 원래 페이지를 방문하지 않을 수 있다. 에이전트가 정보를 읽은 뒤 구매나 예약까지 처리하는 경우도 생긴다. 사이트 운영자 입장에서는 기존 페이지뷰와 클릭으로 설명하기 어려운 트래픽이 생긴다.

Cloudflare의 정책 변화는 이 간극을 보여주는 사례다. 회사는 2026년 9월 15일부터 신규 도메인의 광고가 있는 페이지에서 학습용·에이전트용 봇은 기본 차단하고 검색용 봇은 기본 허용하는 정책을 적용하겠다고 밝혔다. Cloudflare의 정책일 뿐 웹 전체의 규칙은 아니다. 다만 검색 크롤러와 에이전트 크롤러를 경제적으로 다른 방문자로 보기 시작했다는 신호다.

측정도 달라지고 있다. Cloudflare는 최근 답변 엔진 최적화(Answer Engine Optimization, AEO) 도구에서 사이트가 AI 답변에 얼마나 인용되고 언급되는지를 별도 지표로 보기 시작했다. 아직 업계 표준은 아니다. 다만 페이지뷰와 검색 순위만으로는 새 경로를 충분히 설명하기 어렵다는 문제는 이미 드러났다.

기업이 준비할 것은 새 홈페이지가 아니라 두 번째 인터페이스다

모든 기업이 지금 MCP 서버를 만들거나 에이전트 전용 사이트를 구축할 이유는 없다. 사람은 여전히 웹페이지를 읽고 검색엔진도 중요한 고객 발견 경로다. 기존 웹을 갈아엎기보다 에이전트가 접근할 표면을 어디까지 추가할지 정하는 편이 현실적이다.

플랫폼 운영 관점에서 새 채널이 등장했을 때 먼저 볼 것은 기능보다 데이터 흐름, 권한, 성과 측정이다. 에이전트도 다르지 않다. 정보를 읽게 했다면 어디까지 허용할지, 행동까지 맡긴다면 누가 승인하고 어떤 로그를 남길지까지 함께 정해야 한다.

AGENCYTIMES DECISION FRAMEWORK

1. 발견될 수 있는가

검색 색인, 사이트맵, 크롤러 정책, 메타데이터가 에이전트의 접근을 막고 있지 않은지 확인한다.

2. 정확하게 읽을 수 있는가

핵심 정보가 화면 장식이나 이미지 안에만 갇혀 있지 않은지 살핀다. 최신 가격·정책·재고·제품 정보의 기준 출처도 정해둬야 한다.

3. 필요한 기능을 호출할 수 있는가

반복적으로 쓰이는 조회·예약·주문·업무 기능이 있다면 API, MCP 또는 다른 구조화된 인터페이스가 필요한지 판단한다.

4. 권한과 책임을 통제할 수 있는가

읽기, 변경, 결제, 외부 전송 권한을 나눈다. 사람이 승인할 지점과 감사 로그를 어디에 남길지도 정한다.

5. 성과를 측정할 수 있는가

에이전트 호출량에서 멈추지 말고 추천, 성공한 작업, 고객 전환, 지원비용, 거래 마진까지 연결해 본다.

마지막 질문이 빠지면 에이전트 트래픽도 또 하나의 허수 지표가 되기 쉽다. 기존 검색에서 방문자 수보다 전환과 고객 가치가 중요했듯 에이전트 환경에서도 호출 횟수보다 어떤 고객 행동과 비용으로 이어졌는지를 봐야 한다.

CHECKLIST

고객이 우리 사이트에 직접 오지 않고 AI에게 먼저 질문할 가능성이 높은가?
가격, 제품, 재고, 정책처럼 에이전트가 읽어야 할 기준 데이터가 명확한가?
에이전트에게 허용할 읽기·변경·거래 권한을 구분할 수 있는가?
외부 AI가 어떤 데이터를 사용했는지 추적할 수 있는가?
에이전트 경유 고객이 실제 구매·문의·업무 완료로 이어졌는지 측정할 수 있는가?
콘텐츠를 무료로 읽게 할지, 차단할지, 별도 계약이나 과금 대상으로 볼지 기준이 있는가?

웹은 사라지지 않는다. 대신 한 사이트가 두 종류의 사용자를 상대하기 시작했다. 사람은 읽기 쉽고 믿을 수 있는 화면을 원한다. 에이전트에는 발견하기 쉽고 구조가 명확하며 안전하게 호출할 수 있는 인터페이스가 맞다.

다음에 볼 신호도 모델 성능만이 아니다. WebMCP 같은 인터페이스가 실제 사이트에서 얼마나 채택되는지, MCP가 기업의 인증·권한 체계를 어떻게 받아들이는지, 콘텐츠 사업자가 에이전트 접근에 어떤 가격을 붙이는지, 에이전트 경유 고객을 기업이 어떤 지표로 측정하는지를 봐야 한다.

웹의 다음 경쟁은 사람과 AI 중 누구를 택하느냐에 있지 않다. 같은 제품과 데이터를 두 종류의 사용자가 서로 다른 방식으로 쓸 때, 기업이 그 둘을 위한 인터페이스와 권한, 측정을 얼마나 일관되게 설계하느냐가 관건이다.

Summary

AI 에이전트용 웹은 별도의 인터넷을 뜻하지 않는다. 검색 색인, 에이전트용 브라우저, MCP, WebMCP 같은 기술이 같은 웹 위에 기계가 읽고 행동하는 두 번째 인터페이스를 만들고 있다. 기업이 준비할 것은 에이전트 전용 홈페이지가 아니라 발견, 읽기, 호출, 권한, 측정을 잇는 운영 구조다.

FAQ

자주 묻는 질문

Q. AI 에이전트가 늘어나면 SEO는 필요 없어지나요?

아니다. 에이전트도 먼저 정보를 발견해야 하므로 검색엔진 최적화(Search Engine Optimization, SEO)의 기본 구조는 여전히 유효하다. 다만 검색 순위와 클릭뿐 아니라 AI가 내용을 읽고 인용·추천하는지도 관리 범위에 들어올 가능성이 있다.

Q. MCP와 WebMCP는 같은 것인가요?

같은 개념은 아니다. MCP는 AI 애플리케이션과 외부 데이터·도구를 연결하는 공개 프로토콜이다. WebMCP는 웹페이지가 브라우저 에이전트에 사용할 기능을 알려주려는 웹 인터페이스 접근이다. 현재 WebMCP는 실험 단계라 향후 사양과 채택 범위를 확인해야 한다.

Q. 모든 기업이 MCP 서버를 만들어야 하나요?

그럴 필요는 없다. 공개 정보 제공이 중심인 사이트라면 구조화된 콘텐츠와 데이터의 최신성을 먼저 정리하는 편이 낫다. 반복 조회나 실제 업무 실행 비중이 높아질수록 API나 MCP 같은 호출 인터페이스의 가치가 커진다.

Q. AI 에이전트 시대에는 무엇을 측정해야 하나요?

에이전트 방문량만 보는 것으로는 부족하다. 인용·추천 여부, 도구 호출 성공률, 사람 승인 비율, 에이전트 경유 문의·구매, 거래당 비용과 마진을 함께 봐야 한다. 아직 표준 지표가 정해지지 않은 만큼 자사 고객 여정과 연결된 측정 기준부터 만드는 편이 현실적이다.

TERMINOLOGY

본문에 나오는 주요 용어

용어	뜻	실무자가 볼 지점
AI 에이전트	목표를 받아 정보를 찾고 도구를 사용해 여러 단계의 작업을 수행하는 AI 시스템	답변 정확도와 함께 데이터 접근권과 행동 권한을 관리해야 한다.
MCP	AI 애플리케이션이 데이터와 외부 도구를 발견하고 사용할 수 있게 연결하는 공개 프로토콜	연결 자체보다 인증, 도구 권한, 감사 기록을 함께 본다.
WebMCP	웹사이트가 브라우저 에이전트에 사용할 수 있는 기능을 직접 노출하려는 실험적 웹 인터페이스	아직 초기 단계이므로 표준 채택과 브라우저 지원 범위를 추적해야 한다.
AEO	AI 답변 시스템이 콘텐츠를 이해하고 답변에 활용하기 쉽게 만드는 최적화 접근	검색 순위뿐 아니라 인용, 언급, 추천 여부도 관찰 대상이 된다.
에이전트 브라우저	사람의 화면 경험보다 자동 탐색과 정보 추출·행동 수행에 초점을 맞춘 브라우저 환경	연산비용, 지연시간, 컨텍스트 사용량, 프롬프트 주입 같은 운영 조건을 함께 본다.

이 블로그 검색