Building AI Agents with Real-Time Web Data — Yohan Raju, Bright Data

한 줄 핵심

실시간 웹 데이터를 AI 에이전트에 붙이면 고정된 RAG보다 최신성이 필요한 판단과 분석을 더 정확하게 만들 수 있으며, Bright Data의 MCP와 데이터 수집 인프라로 이를 대규모로 안정화할 수 있다.

시간별 요약

1. 0:00
   소개와 제품 인텔리전스 실습 Bright Data의 웹 데이터 수집 배경과 현재 위치를 소개하고, 실시간 웹 데이터를 활용한 AI 에이전트의 가능성을 설명한다. 마지막에는 Amazon 제품과 Reddit 반응을 결합해 구매 여부를 판단하는 실습 흐름을 예고한다.
2. 1:37
   스크래핑은 커버리지가 늘수록 더 어려워진다 처음에는 Amazon, Walmart 같은 소수의 대상을 낮은 볼륨으로 수집하지만, 대상 사이트가 수십·수백 개로 늘면 개발과 유지보수 비용이 급격히 커진다. 사이트가 추가될수록 새 스크래퍼 개발뿐 아니라 기존 스크래퍼의 변경 대응까지 동시에 관리해야 한다.
3. 4:36
   셀렉터 변경과 파이프라인 실패 가격이나 제목을 가리키는 셀렉터가 바뀌면 데이터가 끊기고, 그 영향이 분석·전달 파이프라인 전체로 번진다. 이런 장애는 수동 수정과 누락분 백필을 요구하며, 자동화되지 않으면 다운타임이 곧 SLA와 품질 문제로 이어진다.
4. 5:18
   서로 다른 레이아웃과 접근 장벽 같은 e-commerce 사이트라도 Amazon과 Walmart는 구조가 다르기 때문에 각 사이트마다 별도의 스크래퍼가 필요하다. 여기에 Cloudflare, Okami 같은 봇 방어와 캡차가 더해져, 데이터센터 IP만으로는 접근이 안 되고 실제 사용자처럼 보이는 브라우저·주거용 IP가 필요해진다.
5. 7:07
   전통적인 스크래핑 아키텍처 전통적인 구조는 스케줄러나 URL 설정이 작업을 시작하고, 프록시 계층이 탐지를 피하며, 이후 수집 요청이 사이트로 전달되는 방식이다. Web Unlocker나 Browser API 같은 도구는 차단 여부와 재시도, IP 선택을 포함한 방어 로직을 계층 안에 담는다.
6. 8:32
   데이터 검증과 하위 전달 수집 후에는 가격, 리뷰, 평점 같은 필수 필드가 안정적으로 들어오는지 검증해야 하며, 단순 수집보다 품질 검사가 더 중요해진다. 이후 중복 제거, 보강, 배치 처리, 저장소 전달까지 이어지며, 어느 단계에서든 실패하면 전체 과정을 다시 돌려야 할 수 있다.
7. 9:56
   에이전트가 최신 웹 데이터를 필요로 하는 순간 일부 질문은 사전 학습 데이터나 캐시만으로 답할 수 있지만, 특정 시점의 정보가 필요한 질문은 웹에 직접 나가서 확인해야 한다. 따라서 AI는 동기적 웹 탐색과 비동기적 사전 지식 활용 사이를 구분해 상황에 맞는 경로를 선택해야 한다.
8. 13:27
   Bright Data의 MCP 도구 MCP는 Claude Code, LangChain 같은 시스템이 Bright Data의 60+ API와 연결되도록 해 주는 웹 접근 계층이다. 검색, Markdown/HTML 수집, Amazon·Reddit·LinkedIn·Instagram 같은 특정 사이트 접근, 그리고 브라우저 자동화까지 하나의 엔드포인트로 제공한다.
9. 15:27
   MCP가 있을 때와 없을 때의 Glassdoor 접근 데모 같은 프롬프트라도 MCP가 연결된 Claude는 Glassdoor 내용을 가져오지만, 연결되지 않은 상태에서는 차단된다. 보호가 강한 사이트에서 MCP가 접근 가능성을 크게 높이며, AI 브레인과 실제 웹 수집을 안정적으로 연결해 준다는 점이 드러난다.
10. 17:03
    연속적인 채용 데이터와 이력서 매칭 채용 데이터는 한 번 긁어 끝나는 정보가 아니라, 공고 수·급여·지역·기업별 변화가 계속 바뀌는 연속 데이터다. 이력서 매칭이나 채용 시장 분석처럼 시간 흐름이 중요한 문제일수록 구조화된 실시간 데이터와 과거 이력까지 함께 확보해야 한다.
11. 19:06
    노트북 설정과 분석 파이프라인 실습은 Bright Data API 토큰과 Gemini API key를 사용해 Google Notebook에서 진행되며, Amazon과 Reddit 데이터를 순서대로 수집한 뒤 AI 분석을 수행한다. Amazon에서는 제품 정보를, Reddit에서는 제품명 기반 검색 결과를 가져와 구매 판단에 필요한 입력을 만든다.
12. 21:32
    실시간 Amazon 제품 데이터 Amazon API 응답에서 가격, 평점, 다른 판매자 정보, 기능 설명 등 제품 수준의 상세 데이터가 정상적으로 수집된다. 이 데이터는 이후 Reddit 반응과 결합해 단순 상품 조회를 넘어 구매 의사결정 자료로 활용된다.
13. 22:00
    Reddit에서 제품 감성 검색 Stanley Quencher Tumblr에 대한 Reddit 검색을 실행해 실제 사용자 반응을 모은다. 동시에 MCP 서버의 다른 도메인 도구들, 예를 들어 e-commerce·소셜 미디어·재무·리서치·비즈니스 인텔리전스용 도구가 한 엔드포인트에 묶여 있다는 점을 보여 준다.
14. 24:05
    대규모에서 신뢰할 수 있는 접근에 대한 질문 대규모 차단 우회가 가능한 이유는 단순 봇이 아니라 거대한 프록시 인프라와 사이트별 대응 전략을 함께 운영하기 때문이다. 사이트가 방어를 강화할수록 고정된 접근 방식은 깨지기 쉬우며, 지속적으로 방식을 바꾸고 관리할 역량이 필요하다.
15. 25:23
    결과와 구매 추천 수집된 Amazon 데이터와 Reddit 의견을 함께 분석한 결과, 제품은 할인 중이고 평가는 대체로 긍정적이며 수요는 높고 재고는 낮은 것으로 정리된다. 최종적으로는 구매해도 좋다는 판단과 함께, 이런 방식이 e-commerce를 넘어 다양한 실시간 의사결정에 확장될 수 있음을 보여 준다.

실무 인사이트

• 실시간 웹 데이터가 필요한 작업은 RAG보다 직접 수집 경로를 분리해 설계해야 하며, 최신성 요구가 있는 질문만 동적으로 웹으로 보내는 라우팅이 효율적이다.
• 수집 안정성은 스크래퍼 코드보다 프록시·봇 방어·검증·백필까지 포함한 운영 설계에서 결정되므로, 데이터 파이프라인을 하나의 제품처럼 관리해야 한다.
• MCP 같은 표준 인터페이스를 쓰면 에이전트가 검색·수집·브라우저 조작을 선택적으로 조합할 수 있어, 특정 사이트 접근이 필요한 실제 업무 자동화에 바로 연결하기 쉽다.