AI 에이전트 도입을 검토하는 팀이 가장 많이 의존하는 자료는 벤더가 만든 데모 영상이나 케이스 스터디다. 문제는 그 자료들이 에이전트에게 유리한 조건에서 촬영된다는 점이다. 로그인 없이 접근 가능한 페이지, JavaScript 렌더링이 필요 없는 콘텐츠, 사전 협의된 사이트를 대상으로 구성한 시나리오가 대부분이다. 실제 업무 환경은 다르다.
에이전트가 맡을 작업이 외부 웹 정보를 읽고, 정리하고, 행동으로 연결하는 흐름을 포함한다면, 웹 환경 자체의 에이전트 친화도가 도입 성패를 좌우하는 변수가 된다. 이 글은 그 변수를 어떻게 사전에 파악하고, 벤더 선정 기준으로 연결하는지에 대해 다룬다.
에이전트가 막히는 구조적 이유
에이전트가 웹에서 실패하는 원인은 대부분 AI 모델의 능력 문제가 아니다. 에이전트가 접근하려는 사이트가 에이전트를 수용하지 않는 구조로 되어 있어서 발생한다.
구체적으로 보면 세 가지 상황이 반복된다. 첫째, 페이지 콘텐츠가 JavaScript를 실행해야만 렌더링되는 경우다. 에이전트가 HTTP 요청만으로 페이지를 읽으면 실제 정보 대신 빈 구조만 받는다. 둘째, 봇 차단 정책이 에이전트의 요청을 사람이 아닌 트래픽으로 분류해 차단한다. 셋째, 사이트 자체가 AI 크롤러를 명시적으로 배제하는 정책을 적용한 경우다.
113개 사이트를 대상으로 매주 AI 에이전트 접근성을 감사하는 agentability.org의 공개 데이터를 보면, 이 문제가 얼마나 현실적인지 확인할 수 있다. 평균 준비도 점수는 100점 만점에 74점이고, llms.txt(에이전트에게 사이트 구조를 설명하는 규약 파일)를 게시한 곳은 절반 남짓이다. AI 크롤러를 하나라도 막는 사이트는 7%, 정책으로 완전히 닫은 곳은 3%다. 숫자만 보면 양호해 보이지만, 에이전트가 실제로 작업을 완료한 비율은 매 에피소드마다 달라지고, 실패의 절반 이상은 사이트 구조 문제에서 비롯된다.
벤더 데모가 보여주지 않는 것
벤더가 제공하는 데모에는 공통적인 공백이 있다. 작업이 실패했을 때 에이전트가 어떻게 반응하는지, 막힌 상황에서 포기하는지 우회를 시도하는지, 실패를 어떻게 보고하는지를 보여주지 않는다.
에이전트 평가에서 이 부분이 중요한 이유는, 실제 운영 환경에서 100% 성공률을 기대할 수 없기 때문이다. 중요한 것은 실패 자체가 아니라 실패의 성격이다. 접근 불가 상황에서 에이전트가 "확인할 수 없었다"고 솔직하게 보고하는 것과, 임의로 추론한 내용을 결과처럼 반환하는 것은 완전히 다른 위험을 만든다. 전자는 운영자가 판단을 보완할 수 있지만, 후자는 오류가 눈에 보이지 않은 채 다음 단계로 넘어간다.
agentability.org가 모든 트랜스크립트를 원문 그대로 공개하는 이유가 여기 있다. 에이전트가 어떤 페이지를 읽었는지, 어디서 멈췄는지, 무엇을 근거로 답을 냈는지를 투명하게 볼 수 있어야 의사결정자가 제대로 평가할 수 있다. 벤더를 평가할 때도 같은 기준을 적용해야 한다.
상황별로 다른 판단 기준
에이전트를 어떤 작업에 쓰느냐에 따라 평가 기준의 무게가 달라진다.
대상 사이트가 고정된 경우: 에이전트가 특정 파트너사 사이트, 내부 포털, 정해진 플랫폼에서만 정보를 수집한다면, 벤더의 범용 성능보다 해당 사이트들과의 호환성이 더 중요하다. 도입 전에 대상 사이트를 직접 감사하거나, agentability.org의 AI Index에 해당 도메인이 포함되어 있는지 확인하는 것이 먼저다. 점수가 낮은 사이트가 포함되어 있다면, 에이전트 벤더를 교체해도 해결되지 않는 문제가 있다는 신호다.
대상 사이트가 유동적인 경우: 에이전트가 일반 웹을 자율적으로 탐색하는 방식이라면, 봇 차단 우회 능력이나 JavaScript 없이 콘텐츠를 파악하는 방법보다 실패 처리 방식이 더 중요한 평가 항목이 된다. 모든 사이트에 접근할 수 있는 에이전트는 없다. 접근 실패를 어떻게 감지하고, 어떻게 처리하고, 어떻게 보고하는지를 기준으로 삼아야 한다.
업무 결과의 정확도가 핵심인 경우: 에이전트가 수집한 정보가 이후 의사결정이나 고객 커뮤니케이션에 활용된다면, 성공률보다 오류의 탐지 가능성이 더 중요하다. 에이전트가 틀렸을 때 그 사실을 알 수 있는 구조가 있는지를 먼저 확인해야 한다.
벤더 검증에서 실제로 물어봐야 할 것들
제품 데모 자리에서 확인하기 어렵지만, 도입 이후 가장 자주 문제가 되는 질문들이 있다.
에이전트가 접근에 실패했을 때 로그나 트랜스크립트를 어느 수준까지 제공하는가. 단순히 "실패"라고 표시하는 것과, 어떤 요청에서 어떤 이유로 실패했는지를 확인할 수 있는 것은 운영 투명성에서 큰 차이가 난다.
실제 환경에서 수행한 작업 기록을 공개하거나 제공할 수 있는가. 벤더가 성공 사례만 공개한다면, 실패 패턴을 사전에 파악할 방법이 없다.
에이전트가 정보를 찾지 못했을 때 어떻게 처리하는가. "찾을 수 없었습니다"와 "다음 정보를 바탕으로 추정했습니다"를 구분해서 보고하는지, 아니면 두 경우를 같은 형식으로 반환하는지 확인해야 한다.
특정 사이트 유형에서 성공률이 낮다는 사실을 인지하고 있는가. 이 질문에 제대로 답하는 벤더라면, 자사 제품의 한계를 파악하고 있다는 의미다. 답하지 못하거나 회피한다면, 그 자체가 판단 근거가 된다.
사전 검증을 직접 설계하는 방법
벤더 주도의 POC(파일럿)는 대부분 벤더가 유리한 조건을 선택한다. 팀이 직접 검증 환경을 설계하는 것이 더 실질적인 정보를 준다.
도입 대상 업무에서 에이전트가 실제로 접근해야 할 사이트 10곳을 먼저 목록으로 만든다. 각 사이트가 JavaScript 없이 주요 콘텐츠를 제공하는지, 로봇 차단 정책이 있는지, 구조화된 데이터를 포함하는지를 확인한다. 이 과정은 별도의 도구 없이도 브라우저 개발자 도구와 robots.txt 확인만으로 일부 가능하다.
그 다음 벤더에게 해당 사이트들을 대상으로 파일럿 작업을 실행하되, 트랜스크립트 전체를 제공하는 조건을 요청한다. 성공한 작업만이 아니라 실패한 작업의 로그까지 포함해야 한다. 여기서 벤더가 거부하거나 결과 요약만 제공한다면, 그것만으로도 중요한 신호다.
마지막으로, 시간 간격을 두고 같은 작업을 반복해서 실행해본다. 웹 환경은 동일한 사이트도 시점에 따라 접근 조건이 달라진다. 단일 시점의 성공률은 안정성 지표가 되지 못한다.
