🤖 AI

HTMLCure: Turning Browser Experience into State Guided Repair for Interactive HTML

HTMLCure 는 결정적 상호작용 궤적을 통해 인터랙티브 HTML 을 평가하고 수정하는 상태 기반 브라우저 경험 프레임워크를 도입하여 시드 코퍼스를 고품질 데이터셋으로 크게 확장함으로써 27B 모델이 Kimi-K2.6 및 GPT-5.4 와 같은 선도적인 시스템과 인터랙티브 웹 벤치마크에서 동등한 성능을 달성할 수 있게 합니다.

원저자: Jiajun Wu, Jian Yang, Tuney Zheng, Wei Zhang, Haowen Wang, Yihang Lou, Xianglong Liu

게시일 2026-05-27

📖 3 분 읽기☕ 가벼운 읽기

CC BY 4.0

원저자: Jiajun Wu, Jian Yang, Tuney Zheng, Wei Zhang, Haowen Wang, Yihang Lou, Xianglong Liu

원본 논문은 CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) 라이선스로 제공됩니다. ✨ 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성하거나 승인한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기

HTMLCURE 논문 설명을 일상적인 비유와 함께 간단한 개념으로 나누어 정리합니다.

큰 문제: "잘 보이지만 고장 난 것"

아주 재능 있는 예술가 (AI) 에게 장난감 자동차를 만들어 달라고 요청한다고 상상해 보세요. 예술가는 완벽한 모델로 보이는 아름다운 장난감을 건네줍니다. 사진 속에서는 완벽해 보입니다. 하지만 밀어보면 바퀴가 떨어지고, 조향 핸들을 돌리면 핸들이 무용지물로 빙글빙글 돌아갑니다.

이것이 현재 AI 가 생성한 웹페이지 (HTML) 가 안고 있는 문제입니다. 단일 스냅샷 (스크린샷) 에서는 훌륭해 보이지만, 실제 사람이 버튼을 클릭하거나 스크롤을 내리거나 창 크기를 조절하거나 게임을 플레이하려고 하면 페이지가 깨집니다.

옛날 방식: 연구자들은 페이지의 사진을 찍어 예쁘게 보이는지 확인하고 "좋다"고 판단했습니다. 이는 깨진 바퀴들을 모두 놓친 것이었습니다.
결과: 실제로는 고칠 수 있었던 수천 개의 페이지를 폐기하거나, 잘 보이지만 작동하지 않는 페이지를 유지했습니다.

해결책: HTMLCURE (테스트 드라이브 정비사)

저자들은 HTMLCURE라는 시스템을 구축했습니다. 단순히 사진을 보는 대신, HTMLCURE 는 자동차를 테스트 드라이브하는 정비사처럼 작동합니다.

다음은 단계별 작동 방식입니다.

1. 테스트 드라이브 (브라우저 경험)

단순히 사진을 찍는 대신, HTMLCURE 는 웹페이지를 실제 브라우저에 로드합니다. 가만히 앉아 있는 것이 아니라 적극적으로 상호작용합니다.

위아래로 스크롤합니다.
창 크기를 조절합니다 (작은 차고에 차가 들어가는지 확인하는 것처럼).
버튼을 클릭하고, 링크 위에 마우스를 올리고, 게임을 플레이해 봅니다.
정확히 어떤 일이 일어났는지 기록합니다. "버튼이 작동하지 않음", "게임이 멈춤", "모바일에서 레이아웃이 깨짐" 등.

비유: 이는 자동차를 위한 운전 시험과 같습니다. 도장 상태만 보는 것이 아니라, 엔진이 시동되는지, 브레이크가 작동하는지, 변속기가 부드럽게 전환되는지 확인하기 위해 직접 운전해 봅니다.

2. 진단 (상태 신호)

테스트 드라이브 후, 시스템은 페이지에 "건강 점수"와 진단을 부여합니다. 의사가 환자를 분류하듯 페이지를 세 가지 그룹으로 나눕니다.

낮은 점수 (폐차): 페이지는 엉망입니다. 구조의 큰 부분이 누락되었습니다.
- 해결책: 완전 재작성. 패치하지 말고 처음부터 새로운 차를 만드세요.
중간 점수 (고장 난 차): 페이지는 대부분 작동하지만 특정 부품이 고장 났습니다 (예: 라디오가 작동하지 않거나 문 손잡이가 걸려 있음).
- 해결책: 표적 수리. 고장 난 특정 부품을 진단하고 그 부분만 고치세요.
높은 점수 (스포츠카): 페이지는 이미 훌륭합니다.
- 해결책: 연마만. 엔진에 손을 대지 마세요. 아마도 페인트를 왁스칠하는 정도면 됩니다. 고장 나지 않은 것을 "수리"하려고 하면 오히려 고장 날 수 있습니다.

핵심 통찰: 이 논문은 모든 페이지에 동일한 수리 방법을 사용하는 것은 실수라고 주장합니다. 페이지가 실제로 얼마나 고장 났는지에 따라 다른 전략이 필요합니다.

3. 수리 루프 (피드백 사이클)

시스템이 전략 (재작성, 패치, 또는 연마) 을 결정하면 AI 에게 페이지를 수정하도록 요청합니다.

중요 단계: 시스템은 AI 의 말만 믿지 않습니다. 페이지의 새로운 버전을 가져와 테스트 드라이브를 다시 실행합니다.
게이트키퍼: 새로운 버전이 더 좋으면 유지합니다. 새로운 버전이 더 나빠지면 (후퇴), 버리고 다시 시도합니다.
목표: 페이지가 고품질 기준 (100 점 만점에 97 점) 을 통과할 때까지 이 과정을 반복합니다.

비유: 요리사가 수프를 맛보는 상황을 상상해 보세요. 너무 짜면 물을 넣습니다. 그리고 다시 맛을 봅니다. 물이 문제를 해결했다고 단순히 가정하지 않고 확인합니다. 물을 너무 많이 넣어 너무 밍밍해지면 멈추고 다른 레시피를 시도합니다.

결과: 더 나은 라이브러리 구축

저자들은 이 시스템을 97,000 개의 AI 생성 페이지로 구성된 거대한 컬렉션에 적용했습니다.

그들은 "완벽한" 페이지들의 작은 더미로 시작했습니다.
HTMLCURE 를 사용하여 "고장 난" 것들을 수정했습니다.
그 결과 원래 작은 세트에서 63,000 개의 고품질 검증된 페이지를 확보했습니다.

그들은 이렇게 정제된 새로운 라이브러리를 사용하여 새로운 AI 모델 (HTMLCure-27B) 을 훈련시켰습니다.

결과:

새로운 모델은 작동하는 웹페이지를 만드는 데 훨씬 더 뛰어납니다.
엄격한 테스트인 HTMLBENCH에서 50.6점을 기록했으며, 이는 Kimi-K2.6 및 GPT-5.4 와 같은 최상급 상용 모델과 견줄만 합니다.
다른 테스트 (MiniAppBench) 에서는 훈련되지 않은 버전 대비 15 점 향상되었습니다.

한 문장으로 요약한 내용

HTMLCURE는 AI 가 웹페이지가 작동하는지 단순히 "추측"하는 것을 막는 시스템입니다. 대신 AI 에게 모든 페이지를 테스트 드라이브하게 하고, 정확히 무엇이 고장 났는지 진단하며, 올바른 전략으로 수리하고, 수정이 실제로 작동했는지 확인하기 위해 재테스트하게 함으로써 고품질의 작동하는 코드로 구성된 거대한 라이브러리를 만들어냅니다.

기술 요약: HTMLCure

문제 정의

대규모 언어 모델 (LLM) 은 전체 HTML 페이지를 생성할 수 있는 능력을 입증해 왔으나, 이러한 출력물은 종종 "피상적 정확성" 문제를 겪습니다. 생성된 페이지가 단일 정적 스크린샷에서는 올바르게 렌더링될지라도, 스크롤, 호버, 클릭, 크기 조정 또는 게임 플레이와 같은 동적 조건 하에서는 자주 실패합니다. 정적 스크린샷이나 희소한 시각적 흔적에 의존하는 전통적인 평가 방법은 이러한 상호작용 특이적 실패를 놓칩니다. 더 나아가, 표준 데이터 필터링 접근법은 이러한 페이지 중 많은 부분을 사용 불가능한 것으로 폐기하며, 실제로는 수리가 가능한 경우가 많다는 점을 간과합니다. 식별된 핵심 과제는 대화형 HTML 을 위한 데이터 구축이 단순한 채점 문제가 아니라 상태 추정 문제라는 점입니다. 정적 관찰은 특정 사용자 상호작용 이후에야 나타나는 실패를 드러내지 못합니다.

방법론

본 논문은 브라우저 실행 흔적에 의해 주도되는 폐루프 과정을 통해 대화형 HTML 을 평가, 진단 및 수리하도록 설계된 브라우저 경험 프레임워크인 HTMLCURE를 소개합니다.

1. 다차원 경험 평가 파이프라인

정적 스크린샷에 의존하는 대신, HTMLCURE 는 보기 및 상호작용 행동 시퀀스 ( $\pi$ ) 를 실행하여 HTML 아티팩트 ( $h$ ) 를 평가합니다.

4 계층 경험 프로토콜:
- L1 (시각적 관찰): 로딩 동작 및 초기 렌더링을 확인합니다.
- L2 (능동적 상호작용): 컨트롤, 호버 상태, 키보드 바인딩 및 스크롤 동작을 테스트합니다.
- L3 (심층 게임 플레이): 게임이나 복잡한 UI 에 대한 작업 주도 롤아웃을 실행하여 상태 전환, 카운터 및 캔버스 변경을 검증합니다.
- L4 (반응형): 이벤트 맥락과 함께 실행 궤적에서 대표적인 키프레임을 선택합니다.
구조화된 증거: 평가자는 시각적 증거 ( $v_t$ , 예: 렌더링된 프레임) 와 행동적 증거 ( $b_t$ , 예: DOM 상태, 콘솔 오류, 프로브 결과) 를 포함하는 정렬된 흔적 $E(h, \pi)$ 를 생성합니다.
5 구성 요소 채점: 점수 $S(h)$ 는 렌더링, 시각적 디자인, 기능성, 상호작용성, 코드 품질이라는 다섯 가지 차원에서 도출됩니다. 중요한 점은 시각적 디자인이 큐레이션된 키프레임을 기반으로 비전 - 언어 모델 (VLM) 에 의해 평가되는 유일한 구성 요소이며, 나머지 모든 차원은 결정론적 브라우저 실행 및 정적 분석에 의존한다는 것입니다.

2. 상태 인식 대화형 수리 엔진

수리 과정은 일반적인 재생성이 아니라 페이지의 현재 상태에 기반한 통제된 개입입니다.

상태 라우팅: 시스템은 점수 $s$ $s$ 를 기반으로 페이지를 세 가지 상태로 분류합니다.
- 낮음 (< 40): 안정적인 로컬 목표가 없는 페이지. 전략: 전체적 재작성.
- 중간 (40–79): 사용 가능한 구조는 있으나 동작이 손상된 페이지. 전략: 진단 기반 로컬 수리(예: 특정 상호작용 버그 수정).
- 높음 (≥ 80): 강력한 페이지. 전략: 보존 또는 회귀를 피하기 위한 표적 정제.
폐루프 실행: 컨트롤러는 수리 계열을 선택하고 LLM 에 후보를 요청한 후, 모든 후보를 브라우저에서 다시 실행합니다.
회귀 인식 승인: 후보는 기능성과 상호작용성의 회귀를 패널티로 부과하는 복합 점수 $S_{comp}$ 를 사용하여 선택되며, 시각적 디자인의 개선이 손상된 논리의 대가로 이루어지지 않도록 보장합니다.
종료: 페이지가 높은 목표 점수 (≥ 97) 에 도달하거나, 개선이 정체되거나, 라운드 예산이 소진되면 루프가 중단됩니다.

3. 데이터 구축

HTMLCURE 는 수리를 데이터 구축 메커니즘으로 간주합니다. 초기 97K 프롬프트 코퍼스에서 승인된 수리들은 정제된 감독 미세 조정 (SFT) 풀로 내보내집니다. 이 과정은 "높음" 페이지의 작은 하위 집합에서 63,703 개의 품질이 확인된 페이지로 구성된 더 큰 풀까지 사용 가능한 데이터셋을 확장하며, 여기서 최종 40K 학습 세트가 구축됩니다.

주요 기여

수리 상태 신호로서의 브라우저 경험: 브라우저 실행 흔적을 구조화된 페이지 상태로 변환함으로써 VLM 의 시각적 판단을 정밀하게 경계하고 구체적인 수리 결정을 주도할 수 있음을 논문은 입증합니다.
상태 인식 대화형 수리: 이 프레임워크는 페이지의 관찰된 상태에 따라 수리 전략 (재작성 vs 진단 vs 보존) 을 동적으로 선택하는 정책을 도입합니다. 이는 고품질 페이지에서 작동하는 구성 요소를 파괴하는 것을 방지하고 저품질 페이지에 대한 구조적 재구성을 보장합니다.
데이터 구축으로서의 수리: 재실행을 통해 수리를 검증함으로써 시스템은 고품질이고 검증된 SFT 코퍼스를 생성합니다. 이 접근법은 "필터링" 패러다임 (나쁜 페이지 폐기) 을 "회복" 패러다임 (페이지 수리 및 검증) 으로 전환합니다.

결과

저자들은 HTMLBENCH-400(결정론적 브라우저 실행 벤치마크) 과 MiniAppBench 검증 분할을 사용하여 방법론을 평가했습니다.

성능: 동일한 백본 (Qwen3.5) 과 학습 레시피 하에서 HTMLCure-27B-Refined모델은 다음과 같은 결과를 달성했습니다.
- HTMLBENCH-400 에서 50.6(총점).
- 45.2% 결정론적 테스트 케이스 통과율.
- MiniAppBench 검증 분할에서 평균 81.2.
비교: 이러한 결과는 모델을 Kimi-K2.6 및 GPT-5.4 와 같은 강력한 참조 시스템과 동일한 성능 대역에 위치시킵니다.
절대 실험: 동일한 데이터 크기 (12,392 개 예제) 를 사용한 통제 실험은 "정제" 경로 (수리되고 검증된 데이터 사용) 가 "원본" (원래 생성물) 및 "필터링" (원래 고품질 페이지만) 경로보다 우월함을 확인시켜 주었습니다. 이는 데이터 양뿐만 아니라 브라우저 경험에서 도출된 감독의 품질이 개선의 주요 동인임을 입증합니다.

중요성 및 주장

본 논문은 HTMLCURE 가 대화형 HTML 생성의 패러다임을 "생성 및 필터링"에서 "경험, 수리 및 검증"으로 전환한다고 주장합니다.

제어로서의 실행: 핵심 주장은 브라우저 실행을 단순한 최종 합격/불합격 판정 도구로만 사용해서는 안 되며, 누락된 구조와 손상된 상호작용을 분리하는 지속적인 제어 신호로 사용해야 한다는 것입니다.
데이터 품질: 이 연구는 상태별 제어 하에서 약하고 부분적인 페이지를 수리하는 것이 단순히 기존 고품질 페이지를 선택하는 것보다 SFT 를 위한 더 강력한 감독을 산출함을 보여줍니다.
재현성: 저자들은 표준화된 실패 기록이 부족한 에이전트 기반 평가를 넘어설 수 있는 결정론적 테스트 케이스를 포함한 고정된 벤치마크 (HTMLBENCH) 와 재현 가능한 비교를 위한 전체 파이프라인을 제공합니다.

논문은 한계에 대해 겸손하게 서술하며, 시각적 디자인 채점을 위해 여전히 VLM 이 필요하다는 점, 브라우저 프로브가 모든 가능한 상호작용을 커버할 수 없다는 점, 복잡한 게임은 결합된 타이밍 실패를 노출시킬 수 있음을 인정합니다. 또한 향후 작업은 수리 흔적에서 직접 라우팅 및 중지 정책을 학습하는 것을 포함할 수 있다고 제안합니다.