웹 에이전트의 가장 흔한 실패 모드는 “조용한 이탈(off-track drift)“이다. 에이전트는 여전히 의미론적으로 관련된 페이지를 돌아다니고, 각 클릭은 국소적으로는 그럴듯해 보이지만, 실제로는 이미 사용자의 요청을 충족할 수 없는 경로에 들어섰다. FCPAgent는 이 문제를 “반증 가능한 계획(falsifiable commitment)“이라는 개념으로 풀었다. 각 계획 단계에 “이 단계가 여전히 유효한지 확인하는 증거”와 “이 단계를 의심해야 하는 증거”를 명시적으로 붙여서, 에이전트가 궤적 이탈을 최종 실패 이전에 감지하고 수정하게 만든다.

핵심 문제: “계획이 틀렸는지”를 계획 자체가 알려주지 않는다
기존 웹 에이전트의 계획은 “무엇을 할 것인가”만 서술한다. “초대장 보내기 버튼을 찾아라”, “검색어를 입력하라”, “결과를 정렬하라” — 각 단계는 실행 가능한 지시문이지만, 이 단계가 지금도 유효한지를 판단하는 근거는 어디에도 없다.
FCPAgent 논문은 이를 “Test–Operate–Test–Exit(TOTE)” 모델에서 착안한다. 1960년대 인지과학에서 제안된 이 모델은 목표 지향적 행동이 단순한 실행이 아니라 지속적인 테스트와 수정의 루프라고 본다. FCPAgent는 이를 LLM 웹 에이전트에 적용한다:
- 각 계획 단계를 “반증 가능한 헌약(Falsifiable Commitment Unit, FCU)“으로 표현
- 실행 전과 후에 커밋먼트가 여전히 유효한지 테스트
- 반증(falsification)이 발견되면 가장 작은 단위부터 수정
반증 가능한 헌약(FCU)의 구조
FCU는 다음 5가지 요소로 구성된다:
- : 현재 서브골
- : 연결된 재사용 가능한 스킬 (선택적)
- : 확인 증거 (confirming evidence) — 전제조건, 진행, 완료 단계로 구성
- : 반증 증거 (falsifying evidence) — 실행/스킬/계획 3단계 계층
- : 신뢰도 점수
핵심 통찰은 반증 증거의 계층 구조다. 에이전트가 이탈했을 때, 그것이 “실행 레벨의 실수”인지(잘못된 버튼 클릭), “스킬 레벨의 부적합”인지(현재 레이아웃에 맞지 않는 재사용 스킬), 아니면 “계획 레벨의 근본적 오류”인지(서브골 자체가 잘못됨)를 구분한다. 이 구분이 없으면 모든 실패를 같은 방식으로 처리하게 되어 비효율적이거나 파괴적인 수정을 하게 된다.

계획-테스트-수정 루프의 세 단계
1. 반증 가능한 계획 생성
Planner는 과거 성공 궤적에서 추출한 스킬 라이브러리 와 과거 실패-수정 궤적에서 추출한 장애 기억 라이브러리 를 검색한다. 스킬은 “무엇이 작동했는지”를 알려주고, 장애 기억은 “무엇이 의심스러운지”를 알려준다.
이 이중 경험이 중요하다. 스킬만 쓰면 작업 특화 제약을 놓치고, 장애 기억만 쓰면 절차적 지식이 부족해진다. 두 가지를 결합해야 “이 서브골이 일반적으로 이렇게 수행되며, 이 특정 작업에서는 이런 실패 패턴을 조심해야 한다”는 계획이 나온다.
2. 하이브리드 커밋먼트 테스팅
실행 중인 커밋먼트를 테스트하는 데 두 가지 계층을 사용한다:
경량 테스터 (Lightweight Tester): NLI 모델(nli-deberta-v3-base)과 이미지-텍스트 매칭(SigLIP2)을 결합해 액션 제안과 브라우저 상태를 빠르게 검사.
LLM 진단 검증자 (Slow Verifier): 완료 임박, 강한 반증, 또는 경량 테스터 결과가 모호할 때만 개입. 모든 스텝에서 LLM을 부르는 비용을 피하면서도 중요한 순간에는 정확한 판단을 수행.
하이브리드 설계의 효과는 Table 5에서 명확하다:

3. 스코프 인식 수리 (Scope-Aware Repair)
반증이 감지되면, 어느 수준에서 수정할지를 반증 증거의 계층이 결정한다:
- 실행 수준 반증 → 로컬 액션 교정 (예: 잘못된 탭 클릭 수정)
- 스킬 수준 반증 → 다른 스킬로 교체
- 계획 수준 반증 → 남은 커밋먼트 시퀀스 재계획
이것이 FCPAgent가 기존 반성 기반 에이전트(Reflexion, WebDART 등)와 다른 점이다. 기존 방법들은 “문제가 있다”는 것은 알아채지만, 문제가 어디서 비롯되었는지를 구분하지 못해 전체 계획을 버리고 새로 시작하거나 반대로 너무 작은 수정만 한다.
WebArena 결과: 긴 호라이즌에서의 차별화
WebArena 벤치마크에서 FCPAgent는 가장 강한 기준선 대비 평균 성공률 13.8% 상대적 향상을 달성했다. 더 중요한 것은 태스크 길이에 따른 성능 분포다:

짧은 태스크(1-5 스텝)에서는 기준선과 차이가 작다. 하지만 태스크가 길어질수록 격차가 벌어진다. 이는 FCPAgent의 설계 목표와 일치한다: 국소적 합리성이 전역적 유효성을 보장하지 않는 긴 호라이즌 시나리오에서 커밋먼트 테스팅의 가치가 커진다.
제로샷 일반화에서도 확인된다. WebChoreArena에서 9.6% 상대적 향상을 기록했으며, 이는 훈련 데이터에 없는 새로운 환경에서도 반증 가능한 계획 구조가 이전된다는 것을 시사한다.
컴포넌트별 기여도

제거 실험(Ablation)은 세 컴포넌트—계획, 테스팅, 수리—의 역할을 분리한다:
| 제거 컴포넌트 | 3도메인 평균 성공률 | 하락 |
|---|---|---|
| 전체 모델 | 70.6% | — |
| 반증 가능한 계획 제거 | 64.4% | -6.2%p |
| 하이브리드 테스팅 제거 | 67.4% | -3.2%p |
| 커밋먼트 수리 제거 | 68.6% | -2.0%p |
반증 가능한 계획의 제거가 가장 큰 하락을 가져온다. 이는 **“테스트할 대상이 없으면 테스팅과 수리도 의미가 없다”**는 당연하지만 중요한 통찰이다. FCU의 증거 인터페이스가 테스팅과 수리의 전제 조건이다.
경험 스케일링: 실패 기억의 독립적 기여

Figure 4는 훈련 경험이 늘어날수록 FCPAgent가 어떻게 개선되는지를 보여준다. 흥미로운 점은 스킬 라이브러리만 있는 것보다 장애-수정 라이브러리를 함께 쓸 때 일관되게 높은 성능을 보인다는 것이다.
이는 “성공에서 배우는 것”과 “실패에서 배우는 것”이 상호 보완적이라는 증거다. 성공은 절차적 지식(어떻게 하는가)을 제공하고, 실패는 위험 지식(무엇을 의심해야 하는가)을 제공한다. 반증 증거의 품질이 경험과 함께 개선되면, 더 날카로운 패턴 매칭과 더 정확한 수리가 가능해진다.
사례 연구: Amazon Basics 가격 범위 검색
논문의 WebArena-Shopping 사례는 FCPAgent의 작동 방식을 잘 보여준다:
- 사용자가 “Amazon Basics 제품의 가격 범위를 찾아달라”고 요청
- 에이전트가 일반 검색바에 “Amazon Basics”를 입력
- 결과 페이지가 나오지만 다른 브랜드 제품이 섞여 있음
- 페이지는 의미론적으로 관련되어 있으므로 일반 에이전트는 정렬을 시도했을 것
- FCPAgent의 반증 증거가 “계획 수준 드리프트”를 감지 — 광범위 검색 전략이 브랜드 제약을 만족할 수 없음
- 스코프 인식 수리가 계획을 재구성: Advanced Search로 전환, 더 엄격한 제품명 쿼리 발행
- 결과적으로 순수 Amazon Basics 제품만 포함된 리스트에서 정확한 가격 범위 추출
이 사례가 보여주는 핵심은 에이전트가 “실행 경로가 틀렸다”가 아니라 “계획 자체가 부적절하다”는 것을 인지했다는 점이다. 실행 수준의 수정(다른 정렬 버튼 클릭 등)으로는 해결할 수 없는 문제를 계획 수준에서 재구성한 것이다.
FCPAgent가 기존 방법과 다른 점
Table 6(부록)은 FCPAgent를 10개 관련 방법과 네 가지 기준으로 비교한다:
| 요구사항 | Reflexion | AR | WebDART | ColorBrowser | SkillTracer | ContractSkill | FCPAgent |
|---|---|---|---|---|---|---|---|
| 명시적 진행 기준 | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✓ |
| 명시적 이탈 감지 | ✗ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| 다중 수준 귀인 | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✓ |
| 귀인 기반 수리 | ✗ | ✗ | ✗ | ✗ | ✓ | ✓ | ✓ |
FCPAgent만이 네 가지 요구사항을 모두 만족한다. 기존 방법들은 이탈을 감지하거나 국소적 수리를 할 수 있지만, **“문제가 실행인지, 스킬인지, 계획인지”를 구분하는 다중 수준 귀인(multi-scope attribution)**이 부족하다.
더 실습해보고 싶은 분들께
에이전트가 자기 계획의 유효성을 스스로 테스트하고 수정한다는 개념은, 하네스 설계와 루프 엔지니어링의 핵심 주제와 직결됩니다. 실제 에이전트 하네스에서 반증 가능한 계획을 어떻게 구현할 수 있는지, 그리고 루프 설계가 에이전트 신뢰성에 미치는 영향에 대해 더 알고 싶다면 다음 자료를 추천합니다:
한계 및 향후 방향
논문이 인정하는 한계: 반증 증거의 품질이 계획 생성 모델에 의존한다. 너무 넓은 반증자(falsifier)는 불필요한 수리를 유발하고, 너무 좁으면 이탈을 놓친다. 학습 기반 반증자 생성과 “최종 성공 여부”가 아니라 “얼마나 빨리 회복 가능한 이탈을 감지했는가”를 측정하는 새로운 벤치마크가 향후 필요하다.
📄 논문: FCPAgent: Falsifiable Commitment Planning for Self-Correcting Web Agents (arXiv:2607.24167)