훈련장이 현실을 못 따라가면, AI는 영원히 실습생이다

AI가 웹을 다룬다는 것의 진짜 어려움

AI가 웹 브라우저를 다루는 것은 생각보다 복잡한 일입니다. 단순히 버튼을 누르고 글자를 입력하는 게 아닙니다. 어느 페이지가 어떤 구조로 되어 있는지 파악하고, 어디에 로그인 버튼이 있는지, 입력창을 채우면 무슨 결과가 나오는지, 심지어 페이지가 느리게 로딩될 때 기다려야 하는지까지 판단해야 합니다. 이것을 잘 하는 AI를 '웹 에이전트(web agent)'라고 부릅니다. 쉽게 말해, 사람 대신 웹사이트를 돌아다니며 일을 처리하는 AI입니다.

문제는 이런 AI를 어떻게 훈련시키느냐입니다. 처음부터 진짜 인터넷에 풀어놓으면 안 됩니다. 실수로 누군가의 계좌에서 돈을 이체하거나, 삭제하지 말아야 할 글을 지울 수도 있습니다. 사람도 처음 일을 배울 때 고객 앞에 바로 세우지 않고 먼저 역할극이나 시뮬레이션으로 연습하게 하듯, AI에게도 안전하게 실수할 수 있는 연습 공간이 필요합니다.

arXiv(전 세계 연구자들이 동료 검토 이전에 논문을 먼저 공개하는 플랫폼)에 최근 올라온 'WebAnything' 논문은 이 연습 공간을 만드는 새로운 방법을 제안합니다. 실제 URL(웹 주소)에서 출발해 훈련에 쓸 수 있는 재현 가능한 웹 환경을 자동으로 구성하겠다는 것입니다.

다만 연구는 정확히 읽어야 합니다. 논문이 제시하는 것과 논문이 실제로 해결한 것은 다를 수 있습니다. 흥분하기 전에 작동 원리(메커니즘)와 앞으로 가능해질 것이라는 기대(예언)를 먼저 분리해 봅시다.

기존 방법의 세 가지 함정

웹 에이전트를 훈련하기 위해 연구자들이 지금까지 써온 방법은 크게 세 가지입니다. 각각 왜 문제가 되는지 살펴보겠습니다.

첫째, '수동 미러링'입니다. 연구자들이 특정 웹사이트를 손으로 직접 복제해 훈련용 가짜 환경을 만드는 방식입니다. 신뢰할 수 있는 환경이 만들어지긴 합니다만, 웹사이트 하나를 제대로 복제하려면 수십 시간이 걸립니다. 세상의 웹사이트는 수십억 개입니다. 모두 손으로 복제할 수는 없습니다. 이것은 마치 요리사를 키우는 학교에서 각 음식점의 주방을 하나하나 직접 지어놓고 훈련시키겠다는 발상입니다. 현실적으로 불가능합니다.

둘째, '생성 모델 기반 환경'입니다. AI, 특히 LLM(쉽게 말해 사람 말을 흉내 내 문장과 코드를 만들어 내는 AI)이 알아서 웹 페이지 비슷한 것을 생성해 훈련 환경으로 쓰는 방식입니다. 편리하긴 합니다. 하지만 이렇게 만들어진 환경은 실제 웹사이트와 미묘하게 다릅니다. 진짜 쇼핑몰과 AI가 만든 가짜 쇼핑몰에서 훈련한 에이전트는, 진짜 쇼핑몰에 투입됐을 때 막히는 경우가 자주 생깁니다. 수영장에서 평영을 아무리 잘 배워도 파도 치는 바다에서는 다르게 느끼는 것과 비슷합니다.

셋째, '캡처-재생 방식'입니다. 실제 웹 페이지의 스냅샷, 즉 특정 순간의 화면 기록을 찍어 두고, AI가 그 상태에서 상호작용하도록 하는 방법입니다. 재현성은 좋습니다. 하지만 찍어 놓은 그 상태 이외의 상황에는 대응이 안 됩니다. 예를 들어 '이 버튼을 누르면 다음 페이지로 넘어가야 한다'는 상황을 미리 캡처해두지 않았으면, AI가 버튼을 눌러도 아무 일도 일어나지 않습니다. 영화 세트장과 같습니다. 앞면은 그럴 듯해 보이지만 뒤로 돌아가면 벽이 없습니다.

이 세 가지 방법의 공통 문제는 '확장성 부족'입니다. 연구실 수준에서는 동작해도, 실제 인터넷의 다양성을 감당하기 어렵습니다. 그리고 팀마다 다른 환경에서 실험하기 때문에 서로의 연구 결과를 비교하기도 어렵습니다. 서로 다른 트랙에서 달린 기록을 갖고 '누가 더 빠르냐'고 따지는 셈입니다.

WebAnything의 작동 원리: 세 단계 자동 복원

WebAnything이 제시하는 방식은 단순하게 표현하면 이렇습니다. 실제 URL을 입력하면, 그 페이지의 구조와 기능을 자동으로 파악하고, 에이전트가 훈련할 수 있는 재현 가능하고 재설정 가능한 환경을 만들어 준다는 것입니다.

조금 더 구체적으로 설명하겠습니다. 일반적으로 웹사이트는 HTML(페이지의 뼈대), CSS(색깔·배치 같은 스타일), JavaScript(버튼 클릭 같은 동작을 처리하는 기능) 세 가지로 이루어져 있습니다. WebAnything은 이 세 가지를 자동으로 수집하고, 에이전트가 버튼을 누르거나 입력창에 글자를 쓸 때 어떤 반응이 일어나야 하는지를 파악해 '기능적으로 동등한' 로컬 환경, 즉 인터넷 없이 자체 서버에서 돌아가는 환경을 구축합니다.

논문에 따르면 WebAnything은 다음 세 단계로 환경을 구성합니다.

1. 수집 단계: 실제 URL에서 페이지 구조(DOM, 쉽게 말해 버튼·입력창·이미지 등이 계층적으로 어떻게 배치돼 있는지), 네트워크 요청(페이지가 외부 서버와 어떤 정보를 주고받는지), 동적 요소(클릭하면 바뀌는 부분)를 자동 추출합니다.
2. 정규화 단계: 외부 서버에 의존하는 부분(광고 서버 호출, 외부 API 연결 등)을 잘라내거나 모의 서버로 대체해 독립적으로 동작하도록 만듭니다.
3. 검증 단계: 재구성된 환경이 원본 페이지와 기능적으로 동등한지 자동으로 점검합니다.

핵심은 '재설정 가능성(resettability)'입니다. AI 에이전트가 실수로 폼(입력창)을 잘못 채웠거나 페이지 상태를 엉망으로 만들었다면, 버튼 하나로 처음 상태로 돌려놓을 수 있습니다. 이것이 훈련에서 얼마나 중요한지는 자동차 운전 연습 게임을 생각하면 됩니다. 게임에서 벽에 부딪혀도 '다시 시작' 버튼을 누르면 그만입니다. 실제 도로에서는 그럴 수 없습니다. 에이전트도 마찬가지입니다. 실수를 반복하며 배울 수 있는 환경이 있어야 실력이 늡니다.

역사적 평행선: 자율주행도 같은 벽에 부딪혔다

이 문제를 처음 겪은 분야는 웹 에이전트 연구가 아닙니다. 자율주행차 연구도 정확히 같은 벽에 부딪혔습니다.

2010년대 초반, 자율주행을 연구하던 팀들은 '시뮬레이션 대 실제 도로' 문제로 고전했습니다. CARLA, LGSVL 같은 시뮬레이터에서 수백만 킬로미터를 달린 AI가 실제 도로에 나가면 엉뚱한 실수를 했습니다. 시뮬레이션의 빛 반사 방식, 센서 노이즈 패턴이 실제와 달랐기 때문입니다. 이것을 'sim-to-real gap', 즉 시뮬레이션과 현실 사이의 간극이라고 부릅니다.

자율주행 연구자들은 이 문제를 두 방향으로 풀었습니다. 하나는 시뮬레이터를 더 정교하게 만드는 것입니다. NVIDIA의 DRIVE Sim처럼 물리 기반 렌더링을 도입해 빛과 그림자가 실제처럼 보이게 했습니다. 다른 하나는 실제 데이터로 시뮬레이터를 보정하는 것입니다. 웨이모(Waymo)가 실제 도로 주행 데이터를 지속적으로 시뮬레이터에 반영하는 방식입니다. 어느 쪽도 완전한 해결책은 아니었습니다. 하지만 이 두 방향 모두 '재현 가능하고 통제된 환경을 만들자'는 목표에서 출발했다는 점은 같습니다.

웹 에이전트 연구도 같은 궤적을 밟고 있습니다. WebAnything은 자율주행에서 '더 정교한 시뮬레이터' 방향에 해당합니다. 없는 것을 새로 만드는 것이 아니라 실제 웹 구조에서 출발해 기능적으로 충실한 환경을 재구성하겠다는 것입니다. 이것이 생성 모델 기반 방법과 근본적으로 다른 지점입니다.

자율주행의 교훈 하나를 덧붙이겠습니다. 시뮬레이터에서 높은 성능을 달성하더라도 실제 환경에서 그 격차가 생각보다 크게 벌어진 사례들은 자율주행 분야에서 반복적으로 나왔습니다. 웹 에이전트도 WebAnything으로 훈련한 성능이 실제 인터넷에서 그대로 유지될지는 독립적인 검증이 필요합니다. 논문이 주장하는 성능과 실제 배포 환경에서의 성능은 다를 수 있습니다.

재현 가능성이라는 열쇠: 표준 경기장의 의미

WebAnything이 연구 커뮤니티에 제공하는 가장 중요한 것은 '재현 가능성'입니다. 이것이 왜 그렇게 중요한지 설명하겠습니다.

AI 연구에서 A라는 팀과 B라는 팀이 각각 새로운 웹 에이전트를 개발했다고 가정합시다. A팀은 자신들이 직접 만든 웹 환경에서 테스트했고, B팀은 다른 환경에서 테스트했습니다. 두 팀의 결과를 비교하려면 동일한 환경에서 동일한 조건으로 실험해야 합니다. 하지만 지금까지는 팀마다 훈련 환경이 달랐기 때문에, '우리 에이전트가 더 낫다'는 주장을 검증하기 어려웠습니다. 시험지가 달랐는데 점수를 비교하는 것이나 마찬가지입니다.

WebAnything이 공통 표준 환경을 제공한다면 이 문제가 개선될 수 있습니다. 같은 URL, 같은 과제, 같은 조건에서 여러 에이전트를 비교할 수 있게 됩니다. 이것은 단순한 편의성의 문제가 아닙니다. 연구 결과의 신뢰도, 나아가 연구 속도 전체에 영향을 미칩니다.

비슷한 변화를 이미 겪은 분야가 있습니다. 강화학습(Reinforcement Learning, 줄여서 RL — AI가 시행착오를 통해 스스로 배우는 방법) 연구에서 OpenAI가 2016년에 공개한 'Gym'이라는 표준 환경 라이브러리가 있습니다. Gym 이전에는 연구자마다 자신만의 실험 환경을 만들었기 때문에 결과 비교가 어려웠습니다. Gym이 표준 환경을 제공하자 연구 속도가 눈에 띄게 빨라졌다는 평가가 많습니다. WebAnything이 웹 에이전트 연구에서 비슷한 역할을 목표로 한다는 점은 분명합니다.

다만 논문 수치에 대해 신중해야 합니다. arXiv에 올라온 논문은 동료 검토(피어 리뷰, 다른 전문가들이 논문 내용을 독립적으로 검증하는 과정)를 거치기 전 단계의 공개본인 경우가 많습니다. 이 글에서 논문의 구체적인 성능 수치를 직접 인용하지 않는 것은 그 이유 때문입니다. 공식 학회에 게재될 때 주요 수치나 실험 조건이 조정될 수 있습니다. 재현성을 높이겠다는 연구가 정작 자신의 주장을 충분히 재현 가능한 형태로 공개했는지도 확인이 필요합니다.

두 가지 흔한 오해: 재구성 환경과 진짜 웹은 다르다

이 연구를 접한 사람들이 쉽게 빠지는 오해가 두 가지 있습니다. 짚고 넘어가겠습니다.

첫째 오해: WebAnything이 만든 환경은 실제 웹과 동일하다.

사실은 그렇지 않습니다. WebAnything의 목표는 '기능적 동등성'이지 '완전한 동일성'이 아닙니다. 실제 쇼핑몰에서 결제 버튼을 누르면 실제로 카드가 청구됩니다. 재구성된 환경에서는 결제 기능이 모의(mock)로 대체됩니다. 실제 서버 응답 속도, 네트워크 지연, 로그인 인증 체계도 다르게 처리됩니다. 이것은 단점이 아닙니다. 훈련 목적에서는 오히려 의도된 설계입니다. 실수해도 실제 피해가 없어야 하니까요. 하지만 이 환경에서 훈련한 에이전트가 실제 웹에서도 똑같이 잘 작동하리라고 보장할 수는 없습니다. 이 간극을 무시하면 안 됩니다.

둘째 오해: URL만 넣으면 어떤 웹사이트든 완벽하게 재구성된다.

논문이 설명하는 '자동화'는 부분적입니다. 로그인이 필요한 페이지, 복잡한 JavaScript로 구동되는 앱(구글 독스, 슬랙처럼 실시간으로 많은 것이 바뀌는 서비스), 실시간 외부 데이터를 필수적으로 다루는 페이지는 단순한 자동 추출로 완전히 재현하기 어렵습니다. 모든 웹사이트가 동일한 난이도를 가지지 않습니다. 오픈 웹(로그인 없이 누구나 볼 수 있는 페이지)과 인증이 필요한 서비스는 기술적 난이도가 크게 다릅니다. 논문이 다루는 범위와 실제 인터넷의 복잡도 사이에는 여전히 거리가 있습니다.

추가로 지적해야 할 한계들도 있습니다.

• 저작권과 이용약관 문제: 실제 웹사이트를 복제해 AI 훈련 환경으로 쓰는 행위가 법적으로 문제없는지는 명확하지 않습니다. 웹사이트 운영자의 이용약관에 저촉될 수 있고, 학술 연구 목적과 상업적 활용 사이의 경계가 모호해질수록 이 문제는 커집니다.
• 유지 관리 부담: 웹사이트는 계속 바뀝니다. 오늘 재구성한 환경이 3개월 뒤에도 의미 있는 훈련 환경인지는 별개의 문제입니다. 정기적 갱신 파이프라인(자동화된 일련의 과정)이 필요합니다.
• 개인 데이터 문제: 사용자 맞춤형 콘텐츠를 포함하는 페이지를 재구성하려면 실제 사용자 데이터가 관여될 수 있습니다. 이것은 기술 문제이기 이전에 개인정보 보호 문제입니다.

추적 신호와 시사점: 무엇을 지켜봐야 하는가

WebAnything 자체보다 이 연구가 가리키는 방향이 더 중요합니다. 지금 주목해야 할 것을 정리합니다.

첫째, 표준 벤치마크(기준 측정 환경)의 등장입니다. WebAnything처럼 재현 가능한 환경 구축 도구들이 자리를 잡으면, 웹 에이전트 연구의 공통 측정 기준이 만들어집니다. OpenAI Gym이 강화학습 분야에서 했던 역할처럼요. 이런 표준이 생기면 연구 속도가 빨라진다는 것을 경험적으로 알고 있습니다. 어느 팀이 이 분야의 표준 환경을 설계하느냐는 장기적으로 중요한 경쟁 요소가 됩니다.

둘째, 웹 에이전트의 현실 배포 시점 문제입니다. 훈련 환경 문제가 어느 정도 해결된다면, 웹 에이전트의 실제 서비스 배포가 더 빨리 이뤄질 수 있습니다. 이것은 단순히 기술 발전 이야기가 아닙니다. 웹 에이전트가 대규모로 배포되면 웹사이트 트래픽 구조가 바뀝니다. 지금은 사람이 직접 검색하고 클릭하지만, 에이전트가 대신 탐색하게 되면 웹사이트들은 에이전트에게 최적화된 구조를 만들어야 할지도 모릅니다. SEO(검색 엔진 최적화, 구글 같은 검색 엔진에서 잘 보이게 하는 작업)가 AEO(에이전트 엔진 최적화, AI 에이전트가 잘 읽도록 최적화하는 개념)로 확장되는 흐름이 이미 시작되고 있습니다.

셋째, 데이터 주권 문제입니다. 이것이 가장 묵직한 시사점입니다. 실제 웹사이트의 구조와 콘텐츠를 수집해 AI 훈련 환경으로 쓰는 행위는, 더 크게 보면 '누가 인터넷의 데이터를 AI 훈련에 활용할 수 있는가'라는 질문으로 이어집니다. 구글이 크롤링으로 전 세계 웹을 인덱싱해 검색 독점을 구축했듯, AI 에이전트 훈련 환경을 대규모로 구축하는 주체가 비슷한 방식으로 유리한 위치를 점할 수 있습니다. 웹사이트를 만든 사람들이 자신의 콘텐츠가 AI 훈련에 쓰이는 것에 동의했는지, 어떤 범위까지 허용되는지에 대한 사회적 합의가 아직 없습니다. WebAnything이 기술적 혁신인 동시에 이 논쟁의 한복판에 있다는 점을 잊으면 안 됩니다.

넷째, 진입 장벽과 악용 가능성입니다. 지금까지 웹 에이전트 훈련 환경을 구축할 자원은 대형 연구소나 빅테크에만 있었습니다. WebAnything 같은 자동화 도구가 성숙해지면 중소 규모의 팀도 자체 웹 에이전트를 훈련시킬 수 있게 됩니다. 이것이 기술 민주화라는 측면에서 긍정적이기도 하지만, 반드시 그렇지만은 않습니다. 스팸, 계정 자동 생성, 조작적 자동화 봇처럼 악의적인 목적의 에이전트도 더 쉽게 만들 수 있게 된다는 뜻이기도 합니다.

마무리: 재현되는가, 조건은 무엇인가

WebAnything이 풀려는 문제는 진짜 문제입니다. 훈련 환경이 빈약하면 아무리 좋은 알고리즘(AI의 판단 규칙)도 제대로 검증하기 어렵고, 연구 결과의 신뢰성도 낮아집니다. 공정한 경기장이 없는 상태에서 각자 다른 트랙에서 달린 기록을 비교해 봐야 의미가 없습니다. 그 점에서 WebAnything의 방향은 올바릅니다.

실제 URL에서 출발해 자동으로 재현 가능한 환경을 만들려는 시도는 '시뮬레이션의 현실성'과 '자동화의 편의성'을 동시에 잡으려는 균형 잡힌 접근입니다. 지금까지의 세 가지 방법이 각각 한 가지씩만 잘했다면, WebAnything은 그 교집합을 넓히겠다는 것입니다.

다만 연구는 정확히 읽어야 합니다. 재구성된 환경과 라이브 웹의 간극, 저작권 문제, 로그인 필요 서비스의 처리 방식, 동료 검토 전 논문의 수치 신뢰도, 그리고 학술 목적 연구가 대규모 상업적 활용으로 이어질 때 발생하는 데이터 주권 문제 — 이것들은 흥분을 가라앉히고 따져봐야 할 질문들입니다.

기술 뉴스는 종종 '혁신적인 기술이 등장했다'는 방향으로 기울어지기 쉽습니다. 그러나 진짜 중요한 것은 항상 같은 질문입니다. 이 기술이 실제 배포 환경에서 재현되는가, 그 조건은 무엇인가. WebAnything이 이 질문들에 명확히 답할 때, 그때 비로소 '게임 체인저'라는 표현을 쓸 수 있습니다.

독자가 던질 법한 질문 세 가지

Q. WebAnything으로 훈련한 에이전트가 실제 웹에서도 잘 작동하나요? A. 아직 독립적인 검증이 충분하지 않습니다. 논문이 내부 실험 결과를 제시하지만, 외부 팀의 재현 실험이 이루어져야 신뢰할 수 있습니다. 자율주행 시뮬레이터와 실제 도로 사이에 항상 간극이 있었듯, 이 문제는 앞으로도 계속 추적해야 할 열린 질문입니다.

Q. 이 기술이 상용화되면 일반인에게 어떤 영향이 있나요? A. 직접 영향보다 간접 영향이 먼저 나타날 것입니다. 웹 에이전트 연구가 빨라지면 고객 지원 자동화, 온라인 쇼핑 에이전트, 웹 기반 업무 자동화 도구 등이 더 빨리 더 많이 나올 수 있습니다. 웹사이트 입장에서는 사람이 아닌 에이전트를 대상으로 하는 설계 고민이 시작됩니다. 편리함과 함께 자동화 봇의 악용 문제도 함께 커집니다.

Q. 웹사이트 운영자라면 지금 당장 무언가를 해야 하나요? A. 지금 당장 행동보다는 관찰이 적절합니다. 웹 에이전트가 대규모로 배포되면 트래픽 패턴이 바뀔 수 있습니다. 에이전트가 쉽게 읽고 탐색할 수 있는 구조(명확한 메타데이터, 기계가 읽기 쉬운 페이지 구조)가 장기적으로 유리해질 가능성이 있습니다. 하지만 이것이 일반화되려면 아직 시간이 필요하고, 그 사이 기술 환경도 계속 바뀝니다.