[논문 리뷰] K-BrowseComp — 한국어 웹 브라우징 에이전트는 왜 어려운가

한 줄 요약

K-BrowseComp는 OpenAI의 BrowseComp 계열 문제를 한국어와 한국 웹 맥락으로 옮긴 벤치마크다. 단순히 질문을 한국어로 번역한 것이 아니라, 한국 웹사이트, 한국식 검색어, 로컬 엔티티, 반정형 페이지, 문화적 단서까지 포함해 웹 브라우징 에이전트가 실제 한국 사용자 질문을 얼마나 잘 풀 수 있는지를 본다.

논문이 보여주는 숫자는 꽤 세다.

• 전체 문제 수: 400개
• 수작업 검증 subset: 300개
• synthetic diagnostic split: 100개
• K-BrowseComp-Verified에서 frontier model 정확도: 30.00-45.67%
• 한국 proprietary foundation model 계열 정확도: 0.00-10.33%
• synthetic split에서 가장 강한 모델 정확도: 26.00%

내가 보기엔 이 벤치마크의 핵심 메시지는 “한국어 모델이 약하다”보다 조금 더 넓다.

에이전트 평가는 이제 지식 암기나 단일 추론 문제가 아니라, 로컬 웹을 탐색하고 증거를 연결하고 중간 상태를 보존하는 실행 시스템 평가가 되어야 한다.

왜 BrowseComp의 한국 버전이 필요한가

LLM 평가가 빠르게 바뀌고 있다. 예전에는 instruction following, MMLU류 지식, 수학/코딩 reasoning처럼 모델 내부 능력을 주로 봤다. 그런데 에이전트가 실제 제품에 들어가면서 질문이 달라졌다.

모델이 정답을 알고 있는가?
  ↓
모델이 필요한 정보를 찾아올 수 있는가?
  ↓
여러 출처를 비교하고, 제약조건을 유지하고, 최종 답을 안정적으로 만들 수 있는가?

BrowseComp는 이 흐름에서 나온 대표적인 웹 브라우징 에이전트 벤치마크다. 문제는 한국어/한국 웹 맥락에서는 그대로 쓰기 어렵다는 점이다.

한국 사용자 질문에는 영어권 benchmark와 다른 마찰이 있다.

• 기관명, 학교명, 방송/연예/스포츠/지역 정보처럼 로컬 엔티티가 많다.
• 검색어가 한국식 약칭, 별칭, 역사적 명칭, 띄어쓰기 변형에 크게 의존한다.
• 정보가 블로그, 공공기관, 대학, 커뮤니티, 반정형 표, PDF, 랭킹 페이지에 흩어져 있다.
• 질문 자체가 “정답 하나”보다 조건 조합과 후보 소거를 요구하는 경우가 많다.

그래서 K-BrowseComp는 “한국어 번역 benchmark”가 아니라 한국 웹에서 작동하는 browsing agent benchmark에 가깝다.

벤치마크 구성

K-BrowseComp는 크게 두 부분으로 나뉜다.

K-BrowseComp
├─ Verified: 300개
│  ├─ native Korean speaker가 직접 제작/검증
│  ├─ multi-hop: 160개
│  └─ parallel-branching: 140개
└─ Synthetic: 100개
   ├─ browsing agent가 생성
   ├─ hard human-written exemplar 기반
   └─ failure-mode-targeted prompting + adversarial filtering

Verified subset은 사람이 직접 만든 핵심 benchmark다. 논문에 따르면 300개 중 multi-hop 문제는 160개, parallel-branching 문제는 140개다. 가장 큰 카테고리는 엔터테인먼트/미디어 109개, 그 다음은 교통/장소/지역 48개다. 그 외 교육, 스포츠, 과학, 문학, 제품, 역사, 공공정책 등이 포함된다.

Synthetic split은 조금 다르게 봐야 한다. 저자들은 이것을 main benchmark와 섞지 않고 별도 diagnostic stress split으로 보고한다. synthetic 문제는 verified 문제와 reasoning format은 비슷하게 맞추지만, 도메인 분포와 표면 형태가 다르다. 예를 들어 논문은 synthetic에서 과학/IT/학술 비중이 더 높고 질문 길이도 평균적으로 길다고 설명한다.

이 구분은 중요하다. synthetic 문제를 만들 수 있다고 해서 바로 “사람이 만든 benchmark를 대체한다”는 뜻은 아니다. 대신 모델이 어떤 실패 모드에 취약한지 강하게 찌르는 진단용 압력 테스트로 쓰는 게 맞다.

결과: frontier model도 절반을 못 넘는다

K-BrowseComp-Verified에서 가장 눈에 띄는 결과는 frontier model도 50%를 넘기지 못한다는 점이다.

논문은 GPT-5.5가 45.67%, DeepSeek-V4-Pro가 30.00%를 기록했다고 보고한다. 같은 모델들이 원래 BrowseComp에서 각각 84.4%, 83.4% 수준으로 보고된 것과 비교하면 큰 하락이다. 한국 proprietary foundation model 계열은 0.00-10.33% 범위에 머문다.

여기서 더 흥미로운 부분은 trajectory analysis다. 저자들은 실패가 하나의 병목으로 환원되지 않는다고 말한다.

모델은 서로 다른 지점에서 실패한다.

1. 유용한 초기 검색 전략을 못 잡는다.
2. 어려운 페이지 구조 뒤에 숨은 증거에 접근하지 못한다.
3. 약하게 연결된 출처나 엔티티 문맥을 이어 붙이지 못한다.
4. 표, 목록, 랭킹, DB, 기관 페이지를 잘못 읽는다.
5. 관련 증거를 찾고도 후보나 출처 선택을 틀린다.
6. 희귀 이름, 별칭, 철자 변형, 역사적 명칭을 해소하지 못한다.
7. 일부 후보는 찾지만 모든 제약조건을 만족시키지 못한다.
8. 날짜 계산, 순서, 개수, 비교, 필터링에서 실패한다.

이 목록이 중요한 이유는, 에이전트 성능 개선이 단순히 “더 좋은 LLM으로 바꾸기”가 아닐 수 있음을 보여주기 때문이다.

에이전트 시스템 관점에서 보는 실패 지점

내가 이 논문을 실무적으로 읽을 때 가장 유용했던 포인트는 “실패를 모델 점수로만 보지 말자”는 것이다.

웹 브라우징 에이전트는 대략 이런 루프를 돈다.

질문 이해
  → 검색 쿼리 생성
  → 후보 페이지 탐색
  → 증거 추출
  → 후보 집합 유지
  → 제약조건 검증
  → 최종 답 생성

여기서 하나라도 약하면 최종 정확도는 떨어진다. 특히 K-BrowseComp 같은 문제에서는 중간 상태 관리가 중요하다.

예를 들어 “어떤 방송에 나온 장소 중 조건 A와 B를 만족하고, 날짜 C 이후에 변경된 이름을 가진 곳” 같은 질문을 생각해보자. 모델이 검색을 잘해도 중간 후보를 잃어버리면 틀린다. 표를 잘 읽어도 별칭을 못 맞추면 틀린다. 관련 페이지를 찾고도 최종 답 format을 안정적으로 유지하지 못하면 틀린다.

그래서 이 벤치마크는 모델 평가이면서 동시에 agent harness 평가다.

• 검색 쿼리 planner가 좋은가?
• 브라우징 trace가 안정적인가?
• evidence를 구조화해서 저장하는가?
• 후보 집합과 제약조건을 별도 state로 유지하는가?
• final answer 전에 검증 pass를 수행하는가?
• 실패 시 같은 검색을 반복하지 않고 전략을 바꾸는가?

이런 질문 없이 accuracy만 보면 개선 방향이 잘 안 보인다.

Synthetic split이 흥미로운 이유

논문의 또 다른 포인트는 100개 synthetic split 생성 방법이다. 저자들은 browsing task에 정보 비대칭성이 있다고 본다.

문제를 푸는 것은 어렵지만, 정답과 증거 경로를 알고 있으면 후보 답을 검증하는 것은 상대적으로 쉽다.

이 관찰을 문제 생성에도 적용한다. browsing agent에게 그냥 문제를 만들라고 하면 너무 쉽거나 애매한 문제가 나온다. 하지만 어려운 사람이 만든 예시를 few-shot으로 주거나, 실제 실패 모드를 목표로 삼게 하면 더 어려운 문제가 만들어진다.

이건 벤치마크 구축 자동화 관점에서 꽤 실용적이다. 사람이 모든 문제를 만드는 것은 비용이 크다. 반대로 LLM이 만든 문제를 그대로 믿으면 benchmark 품질이 무너질 수 있다. K-BrowseComp의 접근은 중간 지점에 있다.

사람이 만든 hard exemplar
  + 실패 모드 taxonomy
  + agent 기반 draft/test/revise
  + searchability / well-formedness / difficulty filter
  → diagnostic synthetic split

이 패턴은 다른 도메인에도 적용할 만하다. 예를 들어 사내 문서 검색 에이전트, 세무/법무 리서치 에이전트, 코드베이스 탐색 에이전트의 benchmark를 만들 때도 “실제 실패 taxonomy를 먼저 만들고, 그 실패를 겨냥한 synthetic problem을 생성”하는 방식이 유용할 수 있다.

한국어 에이전트 개발에 주는 시사점

K-BrowseComp가 주는 실무적 시사점은 세 가지다.

1. 한국어 성능은 생성 품질만으로 평가하면 안 된다

한국어 답변을 자연스럽게 생성하는 것과 한국 웹에서 정확한 증거를 찾아 답하는 것은 다른 문제다. 후자는 검색, 브라우저 조작, HTML/표/PDF parsing, entity resolution, state tracking이 모두 들어간다.

한국어 에이전트를 만든다면 최소한 다음 평가를 분리해야 한다.

Korean language fluency
Korean local knowledge
Korean web retrieval
evidence extraction
multi-source reasoning
final-answer verification

2. agent trace를 저장해야 개선이 가능하다

이 논문이 failure taxonomy를 만들 수 있었던 이유는 모델의 trajectory를 봤기 때문이다. 최종 정답만 있으면 “틀렸다”밖에 모른다. 하지만 trace가 있으면 검색어가 문제였는지, 페이지 접근이 문제였는지, 증거 해석이 문제였는지 나눌 수 있다.

에이전트 플랫폼을 만들 때 trace 저장은 비용이 아니라 개선 루프의 재료다. 특히 한국 웹처럼 페이지 구조가 다양하고 정답 경로가 지저분한 환경에서는 더 그렇다.

3. RAG와 browsing agent는 다르게 봐야 한다

일반적인 RAG는 주어진 corpus 안에서 retrieve를 잘하면 된다. browsing agent는 corpus 자체가 열려 있고, 어떤 검색어를 던질지, 어떤 사이트를 믿을지, 몇 단계까지 파고들지 결정해야 한다.

K-BrowseComp의 실패 모드는 이 차이를 잘 보여준다. “검색 결과를 못 찾음”만 있는 게 아니라, 후보를 유지하지 못하거나, 약하게 연결된 문맥을 이어 붙이지 못하거나, 표/랭킹/기관 페이지를 잘못 읽는 문제가 많다.

즉 한국어 browsing agent를 만들 때는 vector DB 튜닝보다 먼저 다음이 필요할 수 있다.

• query reformulation loop
• page structure-aware parser
• evidence table / candidate set memory
• constraint checker
• answer verification step
• source attribution policy

내 생각: 벤치마크보다 중요한 것은 진단 가능성이다

K-BrowseComp의 가장 큰 가치는 “몇 점이 나왔는가”보다 “어디서 실패했는가를 볼 수 있게 만든다”는 점에 있다.

프론티어 모델도 한국 웹 맥락에서는 많이 흔들린다. 그런데 이것을 단순히 모델 크기나 언어 데이터 문제로만 보면 해결책이 좁아진다. 실제 실패는 검색 전략, 페이지 구조, 후보 상태, 제약조건 관리, final answer 검증에 흩어져 있다.

그래서 이 벤치마크는 한국어 LLM 리더보드라기보다, 한국어 에이전트 시스템을 만드는 팀이 자기 harness를 점검할 때 쓸 수 있는 체크리스트에 가깝다.

내가 에이전트 제품을 만든다면 K-BrowseComp류 benchmark를 다음처럼 활용할 것 같다.

1. 모델별 accuracy만 보지 않고, trace를 실패 유형별로 태깅한다.
2. retrieval, parsing, state tracking, answer verification을 분리해서 ablation한다.
3. synthetic split은 regression test와 stress test로 쓴다.
4. 실제 사용자 로그에서 나온 실패를 taxonomy에 추가한다.
5. 모델 교체보다 harness 개선으로 풀 수 있는 실패를 먼저 찾는다.

마무리

K-BrowseComp는 한국어 에이전트 평가에서 꽤 중요한 기준점이 될 수 있다. 특히 “한국어를 잘한다”와 “한국 웹에서 정보를 찾아 정확히 답한다”를 분리해서 보게 만든다는 점이 좋다.

앞으로 한국어 agent benchmark가 더 많아진다면, 단순 정답률보다 다음 축이 더 중요해질 것이다.

• 얼마나 좋은 검색 전략을 세우는가
• 증거를 얼마나 안정적으로 구조화하는가
• 후보와 제약조건을 잃지 않는가
• 한국 웹의 반정형/로컬 정보를 잘 다루는가
• 실패했을 때 어디서 실패했는지 설명 가능한가

에이전트의 시대에는 benchmark도 에이전트답게 바뀌어야 한다. K-BrowseComp는 그 방향으로 가는 꽤 좋은 첫 사례다.

참고 자료

• LinkedIn 소개 글
• K-BrowseComp 논문
• K-BrowseComp 데이터셋
• K-BrowseComp GitHub