한 엔지니어가 Dawn을 열고 다음과 같이 요청합니다. "https://topstartups.io/를 스크랩해서 이름, 설명, 본사 위치, 설립 연도, URL, 소셜 페이지를 포함한 상위 10개 스타트업을 표 형식으로 정리해 줘."
에이전트는 잠시 생각한 뒤, 페이지를 가져오고, 목록을 파싱하고, 각 스타트업의 프로필을 추적하여 표를 반환합니다. 10개의 행. 모든 열이 채워져 있습니다. Pogo, Auctor, Scalify, Omnea, Rivan, Listen Labs, Doppel, Blossom, Avoca, Traba. 본사는 브루클린, 뉴욕, 런던, 샌프란시스코, 원격 근무지 등에 위치해 있습니다. 대부분 LinkedIn 링크가 포함되어 있습니다. 설립 연도는 2020년부터 2026년까지입니다.
이 표는 단 몇 번의 FourA 호출로 만들어진 결과물입니다.
이번 주 Dawn은 자사 에이전트 플랫폼에 FourA를 기본 도구(first-class tool)로 탑재했습니다. 이는 Notion, GitHub, Google Drive와 함께 연동 그리드에 나란히 자리 잡고 있습니다. FourA 접근 권한을 부여받은 에이전트는 공개 웹 페이지나 HTTP endpoint를 가져오고, response(JSON 포함)를 파싱하고, 폼을 제출하고, 연결 상태를 확인하며, 반환된 결과에서 특정 텍스트나 링크를 추출할 수 있습니다. 각 에이전트는 명시적인 접근 권한을 갖거나 갖지 못합니다. 에이전트별 거버넌스가 적용되어, "모든 에이전트가 인터넷에 무제한 접근하는" 위험(footgun)을 방지합니다.
에이전트가 URL에 접근할 수 있다는 사실 자체가 흥미로운 것은 아닙니다. 에이전트 플랫폼에서 웹 검색 기능은 이미 1년 전부터 존재했습니다. 흥미로운 점은 새롭게 등장하고 있는 도구의 형태입니다.
웹 검색과 URL extraction은 서로 다른 작업입니다. 검색은 "인터넷에서 X에 대해 뭐라고 하나요?"를 위한 것입니다. 광범위하고 생성적이며 요약 수준의 정보입니다. 반면 extraction은 "여기 URL이나 endpoint가 있으니, 이를 가져와서 구조화된 답변을 제공해 달라"는 요구를 처리합니다. 신뢰성 요구사항도 다르고, 비용 프로필도 다르며, 실패 모드도 다릅니다. 이 두 가지를 하나의 도구에 섞으면 둘 다 어중간한 결과가 나옵니다.
Dawn의 연동 기능은 이 둘을 분리하여 처리합니다. 광범위한 작업에는 /web-research 기능을 사용합니다. FourA는 특정 대상을 타겟팅하는 작업에 사용됩니다. 에이전트는 실제로 필요한 기능에 따라 적절한 도구를 선택합니다. 그리고 이것이 바로 2026년 에이전트 플랫폼 전반에서 나타나기 시작한 성숙화 패턴입니다. 즉, extraction이 "검색에 덧붙여진 기능"에서 벗어나 독자적인 primitive로 자리 잡아가고 있습니다.
이 글을 읽는 플랫폼 엔지니어를 위하여
Dawn은 FourA를 일반적인 extraction 패턴에 각각 매핑되는 8개의 명명된 도구로 제공합니다:
foura_fetch_page(HTML 및 텍스트 페이지용)foura_extract_text(정돈되고 읽기 쉬운 콘텐츠용)foura_extract_links(내비게이션, 폼, 스크립트, 스타일용)foura_fetch_json(API endpoint용)foura_head_url(header, 상태 코드, 리다이렉트용)foura_probe_site(빠른 연결 상태 확인용)foura_submit_form(로그인 없는 폼 제출용)foura_single_request(임의의 HTTP용)
에이전트는 질문의 요구사항에 따라 도구를 선택합니다. 위의 topstartups 쿼리는 fetch, extract, follow-up의 세 가지 도구를 순서대로 사용했습니다.
연동 작업은 하루 만에 완료할 수 있을 정도로 간단합니다. 내부적으로는 두 가지 방식의 request가 작동합니다. 강력한 차단 정책이 없는 사이트를 위한 브라우저 수준의 핑거프린팅을 지원하는 direct 모드와, 그 외 모든 사이트를 위한 proxy-routed 모드입니다. 두 방식 모두 동일한 request 구조(URL, 선택적 header 및 body, 선택적 response 파싱)를 공유합니다. 에이전트는 대상 사이트의 요구사항에 따라 적절한 방식을 선택합니다.
플랫폼이 에이전트에 제공하는 계약(contract)은 대개 다음과 같은 형태를 띱니다:
- 에이전트가 바로 사용할 수 있는 명확한 도구 정의를 가진 소수의 기능 세트 (fetch / extract / probe / submit)
- 기본적으로 proxy 모드를 사용하고, 지연 시간이나 비용이 중요할 때는 direct 모드로 전환
- 플랫폼 고객이 거버넌스를 유지할 수 있도록 에이전트별 권한 설정 제공
- 시스템 프롬프트에 묻어두는 대신 도구 파라미터로 노출된 구조화된 response 파싱 기능
하지만 대부분의 플랫폼 엔지니어가 간과하는 부분은 예외적인 케이스(tail)에서 발생합니다. 80%의 케이스(200ms 만에 fetch에 성공하고 깔끔한 HTML을 반환하는 경우)는 쉬운 영역입니다. 나머지 20%의 케이스(TLS 핑거프린트로 차단하는 사이트, response에 JS 챌린지를 끼워 넣는 사이트, 클라우드 IP 대역을 403 에러로 막는 사이트 등)가 에이전트가 정확한 답변을 내놓을지 아니면 환각(hallucination) 답변을 내놓을지를 결정합니다. 저희는 바로 이러한 예외적인 케이스를 해결하기 위해 request 경로를 완전히 재구축했으며, "신뢰할 수 있을 것 같은 느낌"과 "실제로 신뢰할 수 있음"의 차이를 만드는 것이 작업의 대부분을 차지합니다.
So if you run an agent platform and your customers keep asking how their agents could "just check this URL," that's the pattern. Docs are at /docs. We're happy to walk you through it.
그 외 모든 분들을 위하여
여러분은 이러한 내부 과정을 전혀 보지 못할 것입니다. 그저 AI 비서에게 지금 당장 실제 웹 페이지를 확인해야 하는 질문을 던졌을 때, 비서가 짐작하거나 사과하는 대신 정확하게 답변하는 것을 보게 될 뿐입니다.
이것이 바로 연동 그리드에서 GitHub 및 Google Drive 옆에 나란히 자리 잡을 만큼 신뢰할 수 있는 extraction primitive가 사용자에게 제공하는 결과물입니다. 이제 이것은 연구 프로젝트가 아니라, 당연히 작동해야 하는 인프라(plumbing)가 되었습니다.
이것이 중요한 이유
6개월 전만 해도 웹페이지를 읽어야 하는 에이전트는 맞춤형으로 제작해야 했습니다. 맞춤형 프롬프트, 취약한 스크레이퍼, 직접 구현한 재시도 로직을 사용해 운이 좋은 날에도 성공률은 60%에 불과했습니다. 레이어가 아직 존재하지 않았기 때문에 구조 자체가 잘못되어 있었습니다. 게다가 에이전트가 접근하려는 사이트들은 계속 변화했습니다. 안티봇 기술이 정적 시그널에서 행동 분석 기반 검사로 전환되면서, 임시방편으로 때운 스크레이퍼들은 개발팀이 패치를 적용하는 속도보다 더 빠르게 망가졌습니다.
이제 그 레이어가 형성되고 있습니다. Dawn이 이를 채택하여 연동 기능을 출시했습니다. 올해 더 많은 에이전트 플랫폼이 그 뒤를 따를 것으로 예상하며, 계약(contract)은 검색을 위한 전용 도구, extraction을 위한 전용 도구, 에이전트별 거버넌스, 예측 가능한 비용이라는 형태로 수렴될 것입니다.
아직 초기 단계입니다. 하지만 이것이 바로 새로운 흐름이 시작되는 모습입니다. 하나의 기능이 프로젝트 단계를 넘어 플러그처럼 끼워 쓰는 도구가 되는 순간입니다.
에이전트 플랫폼을 개발 중이며 이와 동일한 구조를 도입하고 싶다면, 저희에게 연락해 주세요. Dawn에서 에이전트를 개발하고 있다면 FourA는 이미 준비되어 있습니다. 기능을 켜기만 하면 됩니다.