에이전틱 AI의 빠진 계층

URL: https://www.youtube.com/watch?v=XsvUhpnHepE 날짜: 2026-08-26 채널: aiDotEngineer 영상 ID: XsvUhpnHepE 발표자: Giedrius Šteimantas, Oxylabs Director of Scraping Engineering 원제: The Missing Layer in Agentic AI — Giedrius Šteimantas, Oxylabs 자막 상태: YouTube 최초 공개 전 상태로 자동 자막이 아직 제공되지 않아, 영상 공개 설명과 챕터에 포함된 발표 내용으로 선공개 심층 원고를 구성함

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==추론(reasoning)이 충분히 좋아진 지금, 에이전트가 샌드박스 밖의 실제 웹에서 신뢰성 있게 행동하도록 만드는 빠진 계층은 무엇인가?== 브라우저 하나로 모든 단계를 처리하면 느리고 비싸며 CAPTCHA와 차단 페이지를 정상 콘텐츠로 오인하기 쉽다. 따라서 탐색(discovery)은 빠른 검색 API, 정보 수집(decision)은 범용 스크래퍼, 실제 거래·상호작용(checkout)은 브라우저로 분리해야 한다.

• 에이전트의 실패 원인은 모델의 추론 품질보다 웹 접근 계층의 불안정성인 경우가 많다.
• HTTP 200과 정상처럼 보이는 응답 크기는 실제 콘텐츠를 받았다는 보장이 아니다. CAPTCHA와 “사람인지 확인” 페이지도 200으로 반환될 수 있다.
• 모든 작업을 브라우저로 수행하면 토큰·시간·비용을 낭비한다. 필요한 순간에만 브라우저를 사용하고, 나머지는 더 가벼운 인터페이스로 처리해야 한다.

친구가 만든 개인 쇼핑 에이전트는 사용자의 스타일을 대화로 파악한 뒤 다른 에이전트에게 구매 지시를 넘겼지만, 브라우저 자동화 프레임워크를 처음부터 끝까지 사용해 느리고 비싸며 불안정했다. 이 사례는 에이전틱 AI의 실전 병목이 “무엇을 추론할 수 있는가”가 아니라 “웹에서 무엇을 안정적으로 읽고 실행할 수 있는가”라는 점을 보여준다.

1. 브라우저 자동화만으로는 실제 에이전트를 만들 수 없다

1.1. 개인 쇼핑 에이전트가 실패한 이유

1. 아이디어 자체는 에이전틱 워크플로에 적합하다

   1. 대화형 취향 파악: 개인 쇼핑 챗봇이 사용자의 스타일과 요구를 대화로 정리한다.
   2. 두 번째 에이전트로 구매 위임: 정리된 취향과 요구사항을 구매를 담당하는 다른 에이전트에게 프롬프트로 넘긴다.
   3. 목표는 명확하다: 여러 상품을 찾고 비교한 뒤 실제 구매 단계까지 이어지는, 웹을 떠도는 자율 에이전트다.

2. 브라우저를 모든 구간에 적용한 것이 문제였다

   1. 브라우저 자동화 프레임워크의 전면 사용: 상품 탐색, 페이지 읽기, 비교, 결제까지 매 단계에서 브라우저를 띄웠다.
   2. 느린 실행: 페이지 렌더링과 네트워크·자바스크립트 실행을 반복하므로 단순 검색보다 훨씬 오래 걸렸다.
   3. 높은 비용: 브라우저가 반환하는 화면과 페이지 내용이 모델 컨텍스트로 흘러가면서 불필요한 토큰 사용량이 커졌다.
   4. 낮은 신뢰성: 차단·레이트 리밋(rate limit)·CAPTCHA가 발생하면 에이전트가 실제 상품 페이지 대신 방어 페이지를 읽게 됐다.

1.2. 문제의 본질은 모델이 아니라 웹 접근 계층이다

1. 추론 능력과 실행 환경을 분리해야 한다

   1. 모델 품질만 올리는 접근의 한계: 더 똑똑한 모델도 존재하지 않는 상품 정보나 CAPTCHA 텍스트를 진짜 콘텐츠로 받으면 올바른 결정을 내릴 수 없다.
   2. 샌드박스의 착시: 통제된 데모 환경에서는 도구 호출이 잘 되지만, 공개 웹으로 나가면 봇 방어와 사이트별 동작 차이가 즉시 나타난다.
   3. 빠진 계층: 모델과 외부 웹 사이에 신뢰할 수 있는 검색·수집·브라우저 인프라가 있어야 한다.

2. 에이전트는 정상 응답처럼 보이는 실패를 구별해야 한다

   1. 200의 함정: 웹사이트가 HTTP 200을 반환해도 그것이 요청한 상품·본문·재고 데이터라는 뜻은 아니다.
   2. 응답 크기의 함정: 상태 코드와 응답 크기가 정상 범위처럼 보여도, 내용이 CAPTCHA 또는 “사람인지 확인하라”는 차단 페이지일 수 있다.
   3. 조용한 오염(silent contamination): 모델이 차단 페이지를 정상 문서로 요약하면 오류가 명시적으로 실패하지 않고 구매 판단까지 전파된다.

2. Oxylabs의 설계 원칙: 비용이 중요하며 브라우저는 필요할 때만 쓴다

2.1. 10년간 스크래핑에서 얻은 첫 번째 원칙

1. 웹 데이터 수집을 비용 문제로 보라

   1. Giedrius의 배경: 발표자는 Oxylabs에서 스크래핑 엔지니어링을 이끌며 약 10년 동안 웹 데이터 수집 시스템을 다뤘다.
   2. 에이전트의 규모 문제: 단일 페이지를 사람이 한 번 읽는 방식과 수백·수천 페이지를 에이전트가 병렬로 읽는 방식은 비용 구조가 다르다.
   3. 모든 페이지를 모델에 보내지 말라: 웹 접근 단계에서 불필요한 데이터와 실패 응답을 걸러야 모델 토큰 비용이 줄어든다.

2. 브라우저를 기본값이 아닌 고가 도구로 취급하라

   1. 브라우저의 장점: 자바스크립트 실행, 쿠키·세션 유지, 클릭·입력·스크롤, 최종 결제처럼 실제 사용자 상호작용이 필요한 작업을 수행한다.
   2. 브라우저의 부담: 렌더링 비용, 긴 응답, 느린 지연시간, 사이트별 자동화 실패, 봇 탐지 대응 비용이 따라온다.
   3. 핵심 규칙: “브라우저를 사용하지 말라”가 아니라 “브라우저가 정말 필요한 단계에서만 사용하라”는 원칙이다.

2.2. 세 가지 웹 접근 프리미티브

1. 빠른 검색 API(Fast Search API)

   1. 역할: 후보 상품과 관련 URL을 발견하는 discovery 단계의 인터페이스다.
   2. 장점: 검색 결과를 브라우저 화면이 아니라 모델이 읽기 쉬운 압축 JSON으로 반환한다.
   3. 효과: 에이전트가 미리 정한 소매점 목록을 순회하는 대신, 검색 질의를 확장하고 스스로 적합한 URL을 고를 수 있다.

2. 범용 스크래퍼(Universal Scraper / Scraping API)

   1. 역할: 후보 URL에서 상품명·가격·설명·재고 같은 실제 정보를 수집하는 decision 단계의 인터페이스다.
   2. 반환 형식: 모델이 처리하기 쉬운 Markdown을 반환해 브라우저의 화면·DOM·불필요한 자바스크립트 산출물을 줄인다.
   3. 실패 방식: 차단되면 CAPTCHA 내용을 정상 Markdown으로 포장하지 않고, 명시적인 오류로 실패한다.
   4. 확장성: 수백 건의 요청을 병렬로 실행할 수 있고, 성공한 결과에 대해서만 비용이 청구되도록 설계한다.

3. 브라우저·헤드리스 브라우저(Headless Browser)

   1. 역할: 로그인, 장바구니, 배송지 입력, 구매 버튼 클릭처럼 실제 상호작용이 필요한 checkout 단계다.
   2. 연동 방식: Playwright MCP를 에이전트의 브라우저 도구로 유지하되, 뒤쪽에 강화된(hardened) 헤드리스 브라우저를 배치한다.
   3. 보완 기능: stealth, residential proxy, geolocation 같은 기능으로 자동화 탐지와 지역별 상품·재고 차이를 처리한다.

3. 브라우저에서 검색 API로: 탐색 단계의 재설계

3.1. 브라우저 기반 discovery의 낭비

1. 고정된 소매점 목록을 순회하는 방식

   1. 초기 접근: 에이전트가 브라우저를 열고 미리 정해 둔 여러 리테일러 사이트에 접속한다.
   2. 확장성 한계: 사이트마다 렌더링 방식과 방어 정책이 달라 동일한 자동화가 반복해서 깨진다.
   3. 탐색과 실행의 혼동: 아직 후보를 고르는 단계인데도 실행 단계와 같은 무거운 브라우저를 사용한다.

2. 10개 중 3개만 실제 콘텐츠를 주는 상황

   1. 실패 비율: 상품 페이지 10개를 요청해도 실제 콘텐츠가 돌아오는 것은 3개뿐이고, 나머지는 CAPTCHA나 차단 응답일 수 있다.
   2. 토큰 낭비: 에이전트가 10개 응답을 모두 모델에 보내면 그중 약 70%가 상품 정보가 아니라 CAPTCHA를 읽는 데 사용된다.
   3. 판단 오염: 모델이 방어 페이지를 상품 정보로 착각하면 “상품이 없다”거나 잘못된 가격·재고를 근거로 결론을 낼 수 있다.

3.2. 검색 API의 구조와 숫자

1. 압축 JSON으로 후보를 찾는다

   1. 검색 질의 생성: 에이전트가 사용자의 스타일·상품 조건을 검색 질의로 바꾼다.
   2. 자율적 URL 선택: 검색 API가 반환한 결과 중 에이전트가 다음 수집 대상으로 삼을 URL을 고른다.
   3. 고정 목록 제거: 개발자가 모든 리테일러와 상품 페이지를 미리 하드코딩할 필요가 줄어든다.

2. 탐색 비용을 작게 만든다

   1. 컨텍스트 크기: 호출 1회 결과가 2,000토큰 미만의 compact JSON으로 들어온다.
   2. 지연시간: 검색 API 호출은 약 700밀리초 수준이다.
   3. 팬아웃(fan-out): 에이전트가 여러 검색 질의를 병렬로 날리고 후보 URL을 빠르게 모을 수 있다.
   4. 모델의 역할 유지: 모델은 “어디를 읽을지”와 “무엇이 조건에 맞는지”를 결정하고, 브라우저 렌더링 자체에는 토큰을 쓰지 않는다.

4. 브라우저에서 범용 스크래퍼로: 결정 단계의 재설계

4.1. 차단 응답을 정상 콘텐츠로 전달하지 않는다

1. 스크래퍼는 실패를 크게(fail loudly) 만든다

   1. 잘못된 흐름: 차단 페이지를 HTML 또는 텍스트로 그대로 모델에 전달하면 모델은 그 내용을 사실로 해석할 수 있다.
   2. 새로운 흐름: 범용 스크래퍼가 차단을 감지하고 명시적인 오류를 반환하면 에이전트가 해당 URL을 버리거나 다른 경로를 선택할 수 있다.
   3. 오류의 의미: 빈 결과와 차단 결과를 구분해야 “상품이 없다”와 “읽지 못했다”를 혼동하지 않는다.

2. Markdown은 모델 입력에 맞는 경계다

   1. 필요한 정보만 전달: 상품명·가격·설명·재고·조건을 읽기 쉬운 Markdown으로 정리한다.
   2. 렌더링 산출물 제거: 브라우저 화면의 메뉴·스크립트·스타일·반복 UI가 모델 컨텍스트를 차지하지 않는다.
   3. 검증 가능성: 스크래퍼가 성공·실패를 분명히 보고하므로 모델은 입력 신뢰도를 판단할 수 있다.

4.2. 병렬성과 성공 기준을 비용 모델에 반영한다

1. 수백 건을 병렬 처리한다

   1. 직렬 브라우징의 병목 제거: 후보 URL마다 브라우저를 순서대로 열지 않고 스크래핑 요청을 병렬화한다.
   2. 에이전트의 강점 활용: 모델은 결과가 모이는 동안 조건·정렬·비교 논리를 준비할 수 있다.
   3. 실전 규모: 수십 개 상품 비교를 넘어 수백 개 요청을 처리할 때도 브라우저 세션 수를 불필요하게 늘리지 않는다.

2. 성공한 결과에만 비용을 연결한다

   1. 실패에 대한 과금 억제: 차단되어 쓸 수 없는 결과까지 정상 데이터처럼 비용을 내지 않도록 한다.
   2. 품질과 비용의 결합: “요청이 끝났다”가 아니라 “실제 콘텐츠를 얻었다”를 성공으로 본다.
   3. 운영 지표 변화: 단순 HTTP 성공률보다 실제 추출 성공률과 유효 결과 수를 봐야 한다.

5. 결제 단계에서만 브라우저를 사용한다

5.1. checkout은 브라우저가 필요한 예외다

1. 탐색·판단과 결제를 분리한다

   1. 탐색: 검색 API가 후보 URL을 찾는다.
   2. 판단: 범용 스크래퍼가 상품 데이터를 가져와 조건을 비교한다.
   3. 실행: 최종 선택 뒤 장바구니·로그인·배송지·결제를 브라우저가 수행한다.
   4. 원칙: 브라우저를 제거하는 것이 아니라, 비용이 정당화되는 마지막 단계에 집중한다.

2. Playwright MCP를 실제 실행 도구로 남긴다

   1. 에이전트 인터페이스: Playwright MCP는 클릭·입력·탐색을 에이전트가 호출할 수 있게 한다.
   2. 인프라 뒤편의 강화: 에이전트가 직접 취약한 브라우저를 운영하지 않고 hardened headless browser가 연결을 담당한다.
   3. 세션의 현실성: 로그인 세션과 상호작용 상태를 유지하면서도 자동화 차단에 대응한다.

5.2. 재고가 결제 순간 사라지는 문제

1. 상품 페이지와 checkout의 지역·세션 차이

   1. 겉보기 재고: 상품 페이지에서는 “in stock”으로 보이던 항목이 결제 단계에서 사라질 수 있다.
   2. 원인: 지역, IP, 세션, 배송 가능 범위가 달라 페이지 단계와 결제 단계의 재고 판단이 일치하지 않을 수 있다.
   3. 사용자 피해: 에이전트가 오래된 탐색 결과를 신뢰하면 결제 실패나 잘못된 상품 선택으로 이어진다.

2. stealth·residential proxy·geolocation의 역할

   1. stealth: 브라우저 자동화의 식별 가능성을 낮춰 일반적인 사용자 브라우징에 가까운 실행 환경을 만든다.
   2. residential proxy: 데이터센터 IP만으로 접근할 때 발생하는 차단을 줄이고 현실적인 접속 경로를 제공한다.
   3. geolocation: 사용자의 지역에 맞는 가격·재고·배송 정보를 확인한다.
   4. 마지막 검증: 구매 직전 브라우저에서 상품·가격·재고·배송 조건을 다시 확인한다.

6. 토큰을 쓰기 전에 검증하는 에이전트 파이프라인

6.1. 최종 재구축 흐름

1. Discovery — Search API

   1. 입력: 사용자의 취향, 상품 종류, 가격·스타일·지역 조건을 검색 질의로 변환한다.
   2. 출력: 2,000토큰 미만의 compact JSON과 약 700밀리초 지연시간으로 후보 URL을 받는다.
   3. 다음 행동: 여러 질의를 팬아웃하고, 에이전트가 수집 우선순위를 정한다.

2. Decision — Universal Scraper

   1. 입력: 검색 결과에서 선택한 후보 URL을 병렬로 전달한다.
   2. 출력: 상품 내용을 Markdown으로 받고, 차단이면 CAPTCHA가 아니라 명시적인 오류를 받는다.
   3. 다음 행동: 에이전트가 실제 콘텐츠만 비교해 최종 상품을 결정한다.

3. Checkout — Browser

   1. 입력: 최종 선택 상품과 구매 조건을 브라우저 세션에 전달한다.
   2. 출력: 로그인·장바구니·배송·결제 과정의 실제 페이지 상태를 확인한다.
   3. 다음 행동: 결제 직전 가격·재고·지역 조건을 검증한 뒤 사용자가 허용한 범위에서 실행한다.

6.2. “검증 후 토큰 사용”이라는 운영 원칙

1. 모델 입력 전 단계에서 품질을 판정한다

   1. 정상 콘텐츠 여부: 상태 코드만 보지 말고 응답 본문이 기대한 상품 페이지인지 확인한다.
   2. 차단 여부: CAPTCHA, “verify you are human”, access denied 같은 패턴을 오류로 분류한다.
   3. 내용 충실도: 제목·가격·상품 설명처럼 필요한 필드가 있는지 확인한다.

2. 비용과 정확도를 동시에 관리한다

   1. 불필요한 토큰 제거: 10개 응답 중 7개가 CAPTCHA라면 70%의 입력 비용과 모델 집중력을 낭비하지 않는다.
   2. 재시도 전략: 차단 결과를 정상 결과로 누적하지 말고 다른 URL·다른 접근 방법으로 전환한다.
   3. 결과의 책임성: 에이전트가 “읽었다”고 보고하는 것과 실제로 구매에 쓸 수 있는 정보를 확보하는 것을 구분한다.

주요 발언 모음

“Reasoning is solved. Web access isn’t.”

“Cost matters, and use a browser only when you have to.”

“A 200 does not mean the page is real.”

“Validate before you spend tokens.”

“Most agents break the moment they leave the sandbox — blocked, rate-limited, or staring at a CAPTCHA.”

핵심 데이터 & 수치

• 약 10년: Giedrius Šteimantas가 Oxylabs에서 스크래핑 엔지니어링을 다뤄 온 경험의 시간 규모다.
• 10개 중 3개: 브라우저로 상품 페이지 10개를 요청해도 실제 콘텐츠가 돌아오는 예시로, 나머지 7개는 CAPTCHA·차단 응답일 수 있다.
• 약 70%: 위 상황에서 모델에 모든 응답을 보내면 CAPTCHA를 읽는 데 낭비되는 토큰 비중이다.
• 2,000토큰 미만: Search API가 discovery 단계에서 반환하는 compact JSON의 목표 크기다.
• 약 700밀리초: Search API 호출 1회의 예시 지연시간이다.
• 수백 건 병렬 요청: Universal Scraper가 후보 URL을 동시에 처리해 브라우저 직렬 실행의 병목을 줄이는 규모다.
• HTTP 200: 요청이 성공적으로 끝났다는 신호일 뿐, 실제 상품 콘텐츠가 반환됐다는 증거가 아니다.
• 3개 프리미티브: production agent에 필요한 브라우저, 빠른 검색 API, 범용 스크래퍼다.

결론 및 시사점

1. 에이전트 스택의 병목을 모델에서 웹 접근으로 재정의해야 한다: 더 나은 reasoning만으로는 CAPTCHA, rate limit, 지역별 재고, 렌더링 차이를 해결할 수 없다.
2. 브라우저를 전 구간에 쓰지 말아야 한다: 검색에는 Search API, 읽기·비교에는 Universal Scraper, 로그인·결제에는 Browser를 배치해 각 도구의 비용과 능력을 맞춘다.
3. 실패를 숨기지 않는 인프라가 필요하다: 차단 페이지를 정상 텍스트로 전달하지 말고 명시적인 오류로 반환해야 에이전트가 재시도·대체 경로를 선택할 수 있다.
4. HTTP 성공률보다 데이터 성공률을 측정해야 한다: 200 응답 수가 아니라 실제 필드 추출 성공률, 유효 결과 수, 차단률을 운영 지표로 삼는다.
5. 토큰을 쓰기 전에 입력을 검증해야 한다: 모델에 보내기 전 응답이 진짜 콘텐츠인지, 필요한 필드를 갖췄는지, CAPTCHA가 아닌지 검사한다.
6. checkout은 별도의 신뢰 경계다: 상품 페이지의 재고와 결제 시점의 재고가 다를 수 있으므로 geolocation·residential proxy·세션 기반 브라우저로 마지막 상태를 재확인한다.
7. production agent는 세 가지 프리미티브의 조합으로 설계해야 한다: 에이전트가 실제 웹에서 작동하려면 검색·수집·상호작용을 하나의 만능 도구로 뭉치지 말고 분리된 계층으로 제공해야 한다.

핵심 요약 (20줄)

1. 에이전틱 AI의 병목은 추론보다 샌드박스 밖 웹 접근의 신뢰성이다.
2. Giedrius Šteimantas는 Oxylabs에서 스크래핑 엔지니어링을 이끈다.
3. 친구가 만든 개인 쇼핑 에이전트는 취향 대화 뒤 구매 에이전트에 지시를 넘겼다.
4. 브라우저 자동화를 모든 단계에 적용하자 쇼핑 에이전트가 느리고 비싸며 불안정해졌다.
5. 브라우저는 렌더링과 상호작용 때문에 단순 검색보다 무거운 도구다.
6. 실제 웹에서는 차단과 레이트 리밋 때문에 모델 품질만으로 문제를 해결할 수 없다.
7. HTTP 200과 정상적인 응답 크기는 진짜 상품 페이지를 보장하지 않는다.
8. 상품 페이지 10개 중 실제 콘텐츠가 3개뿐이면 약 70%의 모델 토큰이 CAPTCHA에 낭비된다.
9. Search API는 고정된 소매점 목록 대신 에이전트가 선택할 후보 URL을 찾게 한다.
10. Search API는 2,000토큰 미만의 compact JSON을 약 700밀리초에 반환한다.
11. 여러 검색 질의를 팬아웃하면 후보 상품을 빠르게 넓힐 수 있다.
12. Universal Scraper는 결정 단계에서 후보 페이지를 Markdown으로 변환한다.
13. 범용 스크래퍼는 차단을 CAPTCHA 본문이 아니라 명시적인 오류로 보고한다.
14. 수백 건의 스크래핑 요청을 병렬화하면 브라우저 직렬 실행의 병목이 줄어든다.
15. 성공한 결과에만 비용을 연결하면 실패 응답에 토큰과 비용을 낭비하지 않는다.
16. Browser는 로그인·장바구니·배송·결제처럼 실제 상호작용이 필요한 단계에 남긴다.
17. Playwright MCP 뒤에 hardened headless browser를 배치하면 자동화 실행을 강화할 수 있다.
18. stealth·residential proxy·geolocation은 지역별 재고와 결제 단계 차이를 다룬다.
19. 에이전트는 모델에 토큰을 보내기 전에 응답이 실제 콘텐츠인지 검증해야 한다.
20. production agent에는 빠른 검색 API, 범용 스크래퍼, 브라우저라는 세 가지 프리미티브가 필요하다.