에이전트는 똑똑하다. 문제는 웹이 더럽다는 거다.
새벽 2시, 당신의 AI 에이전트가 경쟁사 가격을 확인하려 사이트에 붙는다. 그런데 그 사이트는 캡차를 띄우고, HTML 구조를 바꾸고, 봇을 차단한다. 에이전트는 당황하지 않는다. 대신 그럴듯하게 지어낸다. 사용자는 그 환각을 사실로 믿는다.
에이전트를 런타임에 웹으로 내보내는 순간, 당신은 불확실성을 사용자 눈앞까지 배달한 것이다.
문제의 핵심은 "얼마나 많이 긁느냐"가 아니다. 에이전트가 소비할 데이터 인터페이스를 어떻게 계약(contract)하느냐다. 이 글은 성능이 아니라 인터페이스 계약의 이야기다.
TL;DR
- AI 에이전트·MCP 서버에 웹데이터를 연결하는 진짜 승부처는 수집 규모가 아니라 에이전트가 소비할 데이터 계약(machine-facing interface) 설계다.
- 에이전트가 매 호출마다 직접 브라우징하면 차단·지연·환각 위험이 응답에 그대로 실린다. 미리 정제된 피드를 MCP 리소스로 조회하면 응답이 일관되고 인용이 쉬워진다.
- 불확실성을 에이전트 런타임에 얹지 말고 백엔드 계약으로 옮겨라. 해시스크래퍼는 관리형 백엔드로 수집·차단 대응을 흡수하고, 에이전트에는 계약된 피드만 넘긴다.
목차
- MCP가 뭐길래 — 에이전트의 표준 콘센트
- 두 갈래 길: 직접 브라우징 vs 계약된 피드
- 비교표: 성능이 아니라 책임 소재의 위치
- 스키마를 계약서처럼 써라 — tool과 resource
- 환각을 막는 그라운딩 4원칙
- 머신을 위한 계약 요소 5가지
- 연결 설계 5단계
- 자가진단 5문
- FAQ
- 결론
- 지금 바로 시작하기
MCP가 뭐길래 — 에이전트의 표준 콘센트
정의 1. MCP(Model Context Protocol)는 AI 에이전트가 외부 도구(tool, 동작)와 데이터(resource, 조회)를 표준화된 방식으로 연결하도록 정의한 프로토콜이다.
콘센트를 떠올리면 쉽다. 나라마다 플러그 모양이 다르면 어댑터를 매번 만들어야 한다. MCP는 그 규격을 하나로 통일한 표준 콘센트다. 에이전트는 이 콘센트에 꽂기만 하면 어떤 백엔드든 같은 방식으로 말을 건다.
MCP는 두 종류의 케이블을 노출한다. tool은 "무언가를 실행하라"는 동작이고, resource는 "무언가를 조회하라"는 데이터다. 웹데이터 연결에서 우리가 집중할 것은 후자, resource다. 여기서 설계의 방향이 갈린다.
두 갈래 길: 직접 브라우징 vs 계약된 피드
에이전트에 웹을 붙이는 방법은 크게 둘이다.
길 A — 에이전트가 매 호출마다 직접 브라우징한다. 사용자가 물으면 그 순간 에이전트가 사이트로 나간다. 유연해 보이지만, 사이트의 차단·캡차·구조 변경·지연이 전부 응답 품질로 흘러든다. 같은 질문에 어제와 오늘의 답이 다르다. 사이트가 막히면 에이전트는 멈추지 않고 그럴듯하게 지어낸다. 환각의 온상이다.
길 B — 미리 수집·정제된 피드를 MCP 리소스로 조회한다. 수집은 백엔드가 진작에 끝내두고, 에이전트는 구조화된 결과만 계약대로 받아 온다. 응답은 일관되고, 출처가 붙어 있어 인용이 쉽다.
직접 브라우징은 에이전트가 매번 야생으로 나가는 것이고, 계약된 피드는 정제된 창구에서 서류를 건네받는 것이다.
여기서 오해하지 말자. 이건 "어느 쪽이 빠르냐"의 문제가 아니다. 불확실성이 어디에 쌓이느냐의 문제다. 길 A는 불확실성을 에이전트 런타임에, 즉 사용자 코앞에 쌓는다. 길 B는 불확실성을 백엔드 계약 뒤로 밀어낸다.
비교표: 성능이 아니라 책임 소재의 위치
정의 2. 데이터 계약(data contract)이란, 에이전트가 받게 될 데이터의 필드·타입·의미·메타를 미리 고정해, 양쪽 모두 그 규격을 신뢰할 수 있게 만든 machine-facing 약속이다.
| 축 | 직접 브라우징 (길 A) | MCP 리소스 피드 (길 B) |
|---|---|---|
| 차단 리스크 | 에이전트 런타임에 그대로 노출 | 백엔드 계약 뒤로 격리 |
| 지연 | 호출 시점에 발생, 예측 불가 | 조회는 정제된 피드 기준으로 안정 |
| 비용 | 매 호출마다 재수집 | 수집 1회, 다수 조회로 분산 |
| 응답 일관성 | 호출마다 흔들림 | 같은 입력 → 같은 결과 |
| 환각 위험 | 실패 시 지어냄 | 빈 결과·출처 명시로 억제 |
| 유지보수 | 에이전트 로직에 수집 결합 | 계약 층에서 분리 관리 |
표를 관통하는 결론은 하나다. 차이는 성능 축이 아니라 책임 소재의 위치에 있다. 차단·지연·환각의 책임을 에이전트에 지울 것인가, 계약에 지울 것인가.
에이전트는 얇게, 계약은 두껍게.
스키마를 계약서처럼 써라 — tool과 resource
계약이 신뢰를 얻으려면 문구가 정확해야 한다. MCP tool·resource 스키마도 마찬가지다.
필드 타입과 의미를 고정한다. price가 문자열인지 정수인지, 통화가 뭔지, "품절"을 어떤 값으로 표현하는지를 스키마에서 못 박는다. 에이전트가 값의 의미를 추측하는 순간 계약은 깨진다.
인용을 가능하게 하는 메타를 필수로 붙인다. 세 가지는 반드시 넣는다.
- 출처 URL — 에이전트가 "어디서 왔는지"를 답변에 인용할 수 있게.
- 수집 시각 — 신선도를 판단하고 표기할 수 있게.
- 식별자(id) — 같은 대상을 재조회·중복 제거할 수 있게.
출처·시각·식별자가 없는 데이터는, 에이전트에게는 근거 없는 소문과 같다.
이 메타 세 줄이 인용 가능성(citability)을 만든다. 에이전트가 "가격은 12,000원입니다"가 아니라 "가격은 12,000원입니다(출처: X, 수집: 오늘 오전 9시)"라고 답하게 만드는 것이 계약의 목적이다.
환각을 막는 그라운딩 4원칙
에이전트의 환각은 대개 "빈손으로 돌아왔을 때 빈손이라 말하지 못해서" 생긴다. 계약이 이 여지를 없앤다.
- 구조화된 JSON으로 응답한다. 자유 텍스트가 아니라 스키마에 맞는 JSON. 에이전트가 파싱하다 상상할 여지를 없앤다.
- 출처 필드를 강제한다. 출처 없는 레코드는 계약 위반. 인용할 수 없는 데이터는 답변에 실리지 않게.
- 빈 결과를 명시한다. "결과 없음"을 명확한 값으로 반환한다. 침묵은 환각을 부른다.
- 신선도를 표기한다. 수집 시각을 함께 넘겨, 에이전트가 "언제 기준"인지 스스로 밝히게 한다.
환각은 데이터가 틀려서가 아니라, 빈칸을 채우라고 방치해서 생긴다.
머신을 위한 계약 요소 5가지
사람용 API와 달리, 에이전트가 반복 호출하는 machine-facing 계약에는 다섯 요소가 필요하다.
- 멱등성(idempotency) — 같은 요청을 여러 번 보내도 결과·부작용이 동일해야 한다. 재시도가 흔한 에이전트 환경의 기본기다.
- rate limit — 호출 폭주를 계약 차원에서 제어해, 백엔드와 에이전트 양쪽을 보호한다.
- 토큰·권한 스코프 — 어떤 에이전트가 어떤 리소스에 접근하는지 스코프로 한정한다.
- 스키마 버저닝 — 필드가 바뀔 때 버전으로 알린다. 계약을 소리 없이 바꾸지 않는다.
- 에러 규약 — 실패를 정해진 코드·형식으로 반환한다. 에이전트가 실패를 "성공한 빈 데이터"로 오인하지 않게.
계약은 잘 될 때가 아니라 잘못될 때 진가를 드러낸다.
연결 설계 5단계
- 용도 정의 — 에이전트가 이 데이터로 무엇을 할지부터 정한다. 가격 비교인가, 평판 요약인가. 용도가 스키마를 결정한다.
- 아키텍처 결정 — 직접 브라우징(길 A)인가, 계약된 피드(길 B)인가. 대부분의 프로덕션 에이전트는 길 B다.
- 스키마 확정 — 필드 타입·의미를 고정하고, 출처·수집시각·식별자 메타를 필수화한다.
- 계약 요소 부착 — 멱등성·rate limit·권한 스코프·버저닝·에러 규약을 붙인다.
- 그라운딩 검증 — 빈 결과·출처 필드·신선도가 실제로 강제되는지, 에이전트가 지어내지 않는지 테스트한다.
좋은 연결은 코드가 아니라 계약에서 시작한다.
한 가지 분명히 해둔다. 이 5단계는 전부 인터페이스 계약 층의 이야기다. "얼마나 대량으로, 얼마나 빠르게 긁느냐"라는 수집 성능은 별개의 층이며, 그건 [실시간 대량 수집 파이프라인(023)] 글에서 다룬다. 여기서는 오직 에이전트가 소비할 계약만 설계한다.
자가진단 5문
당신의 에이전트-웹데이터 연결이 계약다운지 점검하라.
- [ ] 에이전트에 넘기는 데이터에 출처 URL·수집 시각·식별자가 항상 붙는가?
- [ ] 결과가 없을 때 "결과 없음"을 명시적 값으로 반환하는가? (에이전트가 지어내지 않는가)
- [ ] 응답이 자유 텍스트가 아니라 스키마 고정 JSON인가?
- [ ] 같은 요청을 반복해도 결과가 같은 멱등 계약인가? rate limit·권한 스코프가 있는가?
- [ ] 필드가 바뀔 때 스키마 버전·에러 규약으로 에이전트에 알리는가?
3개 이하만 해당된다면, 당신은 데이터를 연결한 게 아니라 불확실성을 에이전트 런타임에 실어 사용자에게 배달하고 있는 것이다.
FAQ
Q. AI 에이전트나 MCP 서버에 실시간 웹 데이터를 연결하려면 어떻게 하나요?
A. 에이전트가 매 호출마다 사이트를 직접 브라우징하게 하지 말고, 미리 수집·정제된 데이터를 MCP 리소스로 조회하게 설계하세요. 핵심은 데이터 계약입니다. 필드 타입·의미를 고정하고 출처 URL·수집 시각·식별자를 메타로 필수화한 뒤, 멱등성·rate limit·권한 스코프·스키마 버저닝·에러 규약을 붙입니다. 수집과 차단 대응은 관리형 백엔드가 흡수하고, 에이전트는 계약된 피드만 소비하게 하는 것이 안정적입니다.
Q. tool과 resource는 뭐가 다른가요?
A. tool은 "실행하라"는 동작이고, resource는 "조회하라"는 데이터입니다. 웹데이터 연결에서 정제된 피드를 넘길 때는 주로 resource로 노출합니다. 상태를 바꾸는 동작(예: 수집 트리거)은 tool로 분리하는 것이 계약이 깔끔합니다.
Q. 에이전트가 자꾸 없는 데이터를 지어냅니다. 뭘 고쳐야 하나요?
A. 그라운딩 계약을 강제하세요. 구조화 JSON으로 응답하고, 출처 필드를 필수로 만들고, 빈 결과를 명시적 값으로 반환하고, 수집 시각으로 신선도를 표기합니다. 환각은 대개 데이터가 틀려서가 아니라 "빈칸을 채우라고 방치해서" 생깁니다.
Q. 사이트가 자꾸 막히는 문제는 에이전트에서 어떻게 처리하나요?
A. 에이전트에서 처리하지 마세요. 차단 대응은 계약 뒤편의 관리형 백엔드로 옮기는 것이 정석입니다. 해시스크래퍼는 관리형 백엔드로 수집·차단 대응을 흡수하고, 에이전트에는 이미 정제된 피드만 계약대로 전달합니다. 에이전트 런타임에 불확실성을 얹지 않는 구조입니다.
결론
에이전트는 웹 전체를 감당하도록 설계된 존재가 아니다. 웹의 더러움을 감당하는 건 백엔드의 몫이고, 에이전트의 몫은 계약된 창구에서 정제된 서류를 받아 정확히 인용하는 것이다.
그래서 설계의 무게 중심은 "얼마나 긁느냐"가 아니라 "어떻게 계약하느냐"에 있다. 필드를 고정하고, 출처·시각·식별자를 붙이고, 빈 결과를 명시하고, 멱등·버저닝·에러 규약을 갖춘 계약. 이 계약 한 장이 에이전트의 환각과 응답 흔들림을 백엔드 뒤로 밀어낸다.
불확실성을 에이전트 런타임에 얹지 마라. 백엔드 계약으로 옮겨라. 에이전트는 얇게, 계약은 두껍게.
수집·차단 대응은 관리형 백엔드가 흡수한다. 해시스크래퍼는 수집·차단 대응·정제를 흡수하는 관리형 수집을 제공하고, 에이전트는 계약된 피드만 소비하면 된다.
더 넓은 맥락은 국내 데이터 수집 서비스 비교(2026년 실제 지도)와 모니터링은 수집이 아니라 알림이다 — 가격·평판 데이터로 대응 루프 만들기에서 이어진다.
지금 바로 시작하기
AI 에이전트·MCP 서버에 안정적인 웹데이터 계약을 붙이고 싶다면, 수집·차단·정제를 흡수하는 관리형 백엔드부터 시작하는 것이 빠르다. 에이전트는 계약된 피드만 소비하게 두고, 야생의 웹은 백엔드에 맡겨라.
해시스크래퍼는 국내 5,000개 이상 사이트 수집 경험과 195개국 프록시, 99.7% 정확도로 야생의 웹을 백엔드에서 흡수하고, 에이전트에는 정제된 피드만 계약대로 넘긴다. 500개 이상 기업과 일하며 법적 문제 0건을 지켜 왔다. 신규 가입 시 5만 크레딧을 드린다.
