에이전트는 왜 403 한 번에 멈추는가
에이전트에게 웹 리서치를 시키면 멀쩡한 공개 페이지인데도 403이나 WAF, 캡차 한 번에 접근할 수 없다며 작업이 끊기는 일이 잦습니다. 콘텐츠가 없는 게 아니라, 기본 fetch가 차단 신호를 만나는 순간 더 시도하지 않고 포기하기 때문입니다.
자동화를 실제로 굴려 보면 모델 성능보다 이 접근 단계의 마찰이 더 자주 발목을 잡습니다. 사람이라면 모바일 주소나 피드, 캐시를 손으로 뒤졌을 상황에서 에이전트는 그냥 멈춥니다.
되는 경로가 나올 때까지 올라가는 에스컬레이션
insane-search는 차단을 단정하지 않고 단계적으로 경로를 올립니다. 먼저 공개 API와 피드를 두드리고, 막히면 모바일이나 .json, /rss 같은 가벼운 변형을 시도하고, 그다음 TLS 핑거프린트를 흉내 내며, 끝내 안 되면 실제 헤드리스 브라우저까지 동원해 하나가 뚫릴 때까지 시도합니다.
API 키도 프록시 설정도 필요 없고, curl_cffi나 yt-dlp 같은 도구는 처음 쓸 때 알아서 설치됩니다. X와 레딧, 유튜브 자막, 네이버, 쿠팡, arXiv, 깃허브처럼 공개 페이지나 피드가 있는 곳이면 대체로 읽어 옵니다.
왜 '안 하는 것'을 그어둔 설계가 중요한가
더 눈에 들어오는 부분은 하지 않는 일을 분명히 정해 둔 점입니다. 로그인 창과 페이월 앞에서는 넘지 않고 인증이 필요하다고 그대로 보고하며, 자격증명을 저장하거나 전송하지도 않습니다. 인증을 깨는 도구가 아니라 공개 콘텐츠를 읽는 도구라는 선을 코드로 지킵니다.
AX를 현장에 붙일 때 실제 마찰은 모델 성능보다 데이터에 닿느냐에서 더 자주 생깁니다. 첫 차단에서 멈추지 않고 공개 경로를 끝까지 시도하되 넘지 말아야 할 선은 분명히 박아 둔 접근이라 소개해 둡니다. 직접 만든 도구는 아니고, 써 보고 권하는 쪽입니다.