엔지니어가 Dawn을 열고 다음과 같이 요청합니다. "https://topstartups.io/ 페이지를 스크래핑해서 처음 10개 스타트업의 이름, 설명, 본사 위치, 설립 연도, URL, 소셜 페이지를 표 형식으로 정리해 줘."
에이전트는 잠시 생각한 뒤 페이지를 가져와 목록을 파싱하고, 각 스타트업의 프로필을 추적하여 표를 반환합니다. 10개의 행. 모든 열이 채워져 있습니다. Pogo, Auctor, Scalify, Omnea, Rivan, Listen Labs, Doppel, Blossom, Avoca, Traba. 본사 위치는 Brooklyn, New York, London, San Francisco, Remote에 걸쳐 있습니다. 대부분 LinkedIn 링크가 포함되어 있습니다. 설립 연도는 2020년부터 2026년까지입니다.
이 표는 몇 번의 FourA 호출로 생성된 결과물입니다.
이번 주 Dawn은 자사 에이전트 플랫폼에 FourA를 퍼스트 파티 도구로 통합하여 출시했습니다. FourA는 Notion, GitHub, Google Drive와 함께 통합 그리드에 배치됩니다. FourA 접근 권한이 부여된 에이전트는 공개 웹 페이지나 HTTP 엔드포인트를 가져오고, 응답(JSON 포함)을 파싱하며, 폼을 제출하고, 연결성을 확인하며, 반환된 데이터에서 특정 텍스트나 링크를 추출할 수 있습니다. 각 에이전트는 명시적인 접근 권한을 갖거나 갖지 않습니다. "모든 에이전트에 인터넷 접근 허용"과 같은 위험 요소 없이 에이전트 단위의 거버넌스를 제공합니다.
흥미로운 점은 에이전트가 단순히 URL에 접근할 수 있다는 사실이 아닙니다. 웹 검색은 이미 1년 전부터 에이전트 플랫폼에 존재했습니다. 중요한 것은 새롭게 등장하는 도구의 형태입니다.
웹 검색과 URL 추출은 서로 다른 작업입니다. 검색은 "인터넷에서 X에 대해 어떻게 말하고 있는가?"를 다룹니다. 광범위하고 생성형이며 요약 수준의 정보에 적합합니다. 반면 추출은 "여기에 URL이나 endpoint가 있으니, 이를 가져와서 구조화된 답을 제공하라"는 작업입니다. 신뢰성 요구사항, 비용 프로필, 실패 모드가 모두 다릅니다. 이 둘을 하나의 도구에 섞어 쓰면 두 작업 모두에서 어중간한 결과가 나옵니다.
Dawn의 연동 방식은 이 둘을 분리하여 다룹니다. 광범위한 작업에는 /web-research 기능을 사용합니다. FourA는 타겟팅된 작업을 처리합니다. 에이전트는 실제로 필요한 대상에 따라 적절한 도구를 호출합니다. 이는 2026년 에이전트 플랫폼 전반에서 나타나기 시작한 성숙 패턴이기도 합니다. 데이터 추출이 단순한 "검색 부가 기능"을 넘어 독자적인 primitive로 진화하고 있는 것입니다.
플랫폼 엔지니어를 위한 세부 내용
Dawn은 FourA를 일반적인 추출 패턴에 각각 매핑되는 8개의 명명된 도구로 제공합니다.
- HTML 및 텍스트 페이지를 위한
foura_fetch_page - 가독성 높은 클린 콘텐츠를 위한
foura_extract_text - 내비게이션, 폼, 스크립트, 스타일을 위한
foura_extract_links - API endpoint를 위한
foura_fetch_json - header, status, redirect를 위한
foura_head_url - 빠른 연결성 확인을 위한
foura_probe_site - 로그인 불필요 폼 제출을 위한
foura_submit_form - 임의의 HTTP를 위한
foura_single_request
에이전트는 질문의 성격에 맞춰 도구를 선택합니다. 위의 topstartups 쿼리는 fetch, extract, 후속 작업 순으로 세 가지 도구를 순차적으로 사용했습니다.
연동 과정은 하루 만에 완료할 수 있을 만큼 간단합니다. 기본 구조는 두 가지 request 방식으로 구성됩니다. 차단 정책이 느슨한 사이트를 위한 브라우저급 request signature를 갖춘 direct 모드, 그리고 그 외 모든 대상을 위한 proxy-routed 모드입니다. 두 방식 모두 URL, 선택적 header 및 body, 선택적 response 파싱이라는 동일한 request 구조를 공유합니다. 에이전트는 대상 사이트의 요구사항에 맞춰 최적의 방식을 선택합니다.
플랫폼이 에이전트에 제공하는 계약 구조는 보통 다음과 같습니다.
- 에이전트가 호출할 수 있는 명확한 도구 정의를 갖춘 소규모 기능 셋(fetch / extract / probe / submit)
- proxy 모드를 기본으로 사용하고, 지연 시간이나 비용이 중요할 때 direct 모드로 fallback
- 플랫폼 고객이 거버넌스를 유지할 수 있도록 하는 에이전트별 권한 제어
- system prompt에 숨기지 않고 도구 파라미터로 노출되는 구조화된 response 파싱
하지만 대다수 플랫폼 엔지니어가 간과하는 지점은 바로 tail 구간에서 일어나는 일들입니다. 80%의 일반적인 케이스(200ms 내에 fetch가 성공하고 깨끗한 HTML을 반환하는 경우)는 해결하기 쉽습니다. 그러나 나머지 20%(request signature 기반 차단 사이트, JS 챌린지를 response에 끼워 넣는 사이트, 클라우드 IP 대역을 403으로 막는 사이트)가 에이전트가 정확한 답을 내놓을지 아니면 환각을 일으킬지를 결정합니다. 우리는 바로 이러한 tail 구간을 처리하기 위해 request 경로를 완전히 재구축했으며, "신뢰할 수 있어 보이는 것"과 "실제로 신뢰할 수 있는 것"의 차이를 메우는 작업이 엔지니어링의 대부분을 차지합니다.
에이전트 플랫폼을 운영 중이고 고객들이 에이전트가 "이 URL을 바로 확인할 수 있는 방법"을 계속 묻는다면, 바로 이 패턴을 적용하면 됩니다. 문서는 /docs에서 확인할 수 있습니다. 직접 안내해 드릴 수도 있습니다.
일반 사용자의 경우
사용자는 이 모든 내부 과정을 볼 수 없습니다. 단지 AI 어시스턴트에게 지금 실제 웹페이지를 확인해야 하는 질문을 했을 때, 어시스턴트가 추측하거나 사과하는 대신 정확하게 답한다는 점만 체감하게 됩니다.
이는 GitHub 및 Google Drive와 나란히 연동 그리드에 들어갈 만큼 안정적인 추출 기본 요소를 갖췄을 때 나타나는 사용자 측면의 결과입니다. 더 이상 연구 프로젝트에 머물지 않고, 기본 인프라로 자리 잡게 됩니다.
이것이 중요한 이유
6개월 전만 해도 웹페이지를 읽어야 하는 에이전트는 맞춤형으로 직접 구축해야 했습니다. 제각각인 프롬프트, 취약한 스크래퍼, 직접 구현한 재시도 로직으로 잘 나와야 성공률이 60% 수준이었습니다. 해당 레이어가 아직 존재하지 않았기 때문에 아키텍처 자체가 불안정했습니다. 게다가 에이전트가 접근하는 사이트들도 계속 변화했습니다. 봇 탐지가 정적 신호에서 행동 분석 기반으로 전환되면서, 임시방편으로 만든 스크래퍼는 팀이 패치하는 속도보다 더 빠르게 무너졌습니다.
이제 이 레이어가 자리를 잡아가고 있습니다. Dawn은 이를 도입하여 연동 기능을 배포했습니다. 올해 더 많은 에이전트 플랫폼이 뒤를 이을 것으로 예상하며, 검색 전용 도구, 추출 전용 도구, 에이전트별 거버넌스, 예측 가능한 비용이라는 표준 규격으로 수렴할 것으로 보고 있습니다.
아직 초기 단계입니다. 하지만 새로운 기술이 자리 잡는 과정은 늘 이런 형태였습니다. 어떤 역량이 연구 프로젝트 단계를 벗어나 플러그 형태로 정착되는 순간입니다.
동일한 구조의 에이전트 플랫폼을 구축하고 배포하고자 한다면, 문의해 주시기 바랍니다. Dawn에서 에이전트를 구축하고 있다면 FourA가 이미 준비되어 있습니다. 기능을 켜기만 하면 됩니다.