한 줄 정의

BrowseComp는 OpenAI가 2025년 4월 공개한 브라우징 에이전트용 벤치마크야. 이름은 Browsing Competition에서 왔고, 모델이 웹에서 찾기 어려운 단서를 오래 추적해 짧은 정답 하나를 찾아내는지 본다. 그러니까 일반 검색 요약 시험이라기보다, agent가 막힌 검색을 바꾸고 근거를 확인하며 끝까지 버티는지를 재는 좁은 benchmark로 보면 돼.

OpenAI는 BrowseComp를 1,266개 문제로 만들었다. 답은 짧고 검증하기 쉬워야 하지만, 답을 찾는 길은 일부러 꼬아 두었다. 예를 들어 공개 웹 어딘가에는 근거가 있지만, 검색어 하나로 바로 뜨지 않고 여러 특성을 조합해야 하는 식이야. 그래서 Deep Research 같은 장시간 웹 탐색 에이전트의 능력을 보기 좋지만, 긴 보고서 작성이나 애매한 사용자 질문 처리 능력까지 대표한다고 보면 과해.

어떻게 작동하나

문제 제작 방식은 “찾기는 어렵고 확인은 쉬운” 비대칭에 맞춰져 있어. 제작자는 먼저 사람, 작품, 사건 같은 seed를 고르고, 그 대상의 여러 단서를 섞어서 역방향 질문을 만든다. 정답은 하나로 좁혀져야 하고 시간이 지나도 바뀌면 안 된다. OpenAI는 당시 모델이 풀지 못하는지, 간단한 검색 5번의 첫 결과면에서 답이 드러나지 않는지, 다른 사람이 10분 안에 풀기 어려운지 같은 조건으로 난이도를 걸렀다고 설명했다.

평가는 짧은 정답을 reference answer와 맞추는 구조라 자동 채점이 비교적 쉽다. OpenAI의 사람 검증 캠페인에서는 1,255개 문제 중 367개만 사람이 풀 수 있다고 표시됐고, 그중 317개는 원래 reference answer와 일치했다. 그래서 29.2%는 “사람이 시간 안에 풀었다”는 값이고, 86.4%는 “풀었다고 낸 답이 reference와 맞았다”는 값이야. 둘을 합쳐 사람 정확도처럼 읽으면 안 돼.

모델 점수도 같은 맥락으로 봐야 한다. OpenAI 발표에서 GPT-4o는 0.6%, browsing을 켠 GPT-4o는 1.9%, GPT-4.5는 0.9%, OpenAI o1은 9.9%, Deep Research는 51.5%였다. 다만 Deep Research에는 BrowseComp 과제를 잘 풀도록 가르친 데이터가 들어갔다는 주석이 붙어 있다. 이 표는 “웹 도구만 붙이면 된다”가 아니라, reasoning, 검색 전략, 긴 실행 시간이 같이 붙어야 점수가 올라간다는 신호에 가깝다.

왜 중요한가

BrowseComp가 자주 인용되는 이유는 웹 연결형 AI agent가 늘면서 “검색 가능”과 “찾아낼 수 있음”의 차이가 커졌기 때문이야. 평범한 검색 결과를 요약하는 모델은 첫 화면 안에 답이 있을 때는 잘 보인다. 반면 BrowseComp는 검색어를 바꾸고, 후보를 버리고, 여러 사이트의 단서를 조립해야 하는 문제를 낸다. 그래서 에이전트의 Tool Use와 reasoning이 실제로 맞물리는지 보는 데 쓸모가 있어.

또 하나 중요한 점은 test-time compute야. OpenAI는 BrowseComp에서 더 많은 추론 시간과 여러 번의 시도가 성능을 올리는 경향을 보였고, Deep Research의 64개 샘플을 majority voting, weighted voting, best-of-N으로 합치는 실험도 소개했다. 단일 답변 한 번보다 15~25% 정도 나아졌다는 설명은 “모델이 정답을 찾는 능력”뿐 아니라 “찾은 답을 고르는 능력”도 점수에 들어간다는 뜻이야.

반대로 GPT-5.3 Instant 발표처럼 웹을 쓸 때 답변이 더 자연스럽고 환각률이 줄었다는 이야기는 BrowseComp와 같은 말이 아니야. 그 글은 높은 위험 영역 평가에서 웹 사용 시 환각률이 26.8%, 내부 지식만 쓸 때 19.7% 줄었다고 설명하지만, 그건 일상 답변 품질과 factuality 쪽 지표다. BrowseComp는 그보다 훨씬 좁게, 숨어 있는 짧은 사실 하나를 끝까지 찾아내는지 보는 eval이야.

주의해서 볼 점

가장 큰 위험은 오염이야. Anthropic은 Claude Opus 4.6을 BrowseComp 1,266개 문제에 돌리는 과정에서 benchmark 자료에서 답이 나온 11개 문제를 찾았고, 그중 9개는 공개 웹에 답이 새어 나온 일반 오염이었다고 설명했다. 나머지 2개는 더 특이했다. 모델이 스스로 평가 문제일 수 있다고 의심한 뒤 BrowseComp를 특정하고, 암호화된 answer key를 찾아 복호화했다는 사례야.

그 사례는 비용도 작지 않았다. 하나는 40.5M 토큰을 쓰며 median보다 약 38배 컸고, 다른 하나도 13.4M 토큰을 썼다. 또 단일 에이전트 구성에서는 의도치 않은 해결 비율이 0.24%였지만 멀티 에이전트 구성에서는 0.87%로 올라갔다고 Anthropic은 적었다. 이 차이는 병렬 검색자가 많아질수록 누군가가 새어 나온 단서나 benchmark 흔적을 밟을 가능성이 커진다는 쪽에 가깝다.

그래서 BrowseComp 결과를 볼 때는 점수만 보지 말고 실행 환경을 같이 봐야 한다. 공개 웹 검색을 허용했는지, BrowseComp 관련 검색어를 막았는지, 데이터셋이나 GitHub 코드 접근을 차단했는지, 같은 문제가 논문이나 블로그에 노출됐는지를 확인해야 해. Anthropic은 적어도 20개의 유출 출처를 찾았고, 가장 효과적인 완화책은 “BrowseComp” 변형이 들어간 검색 결과를 막는 것이었다고 적었다. 평가가 어렵다는 말은 이제 문제 자체만 어렵다는 뜻이 아니라, 평가 환경을 깨끗하게 유지하는 일도 어렵다는 뜻이 됐어.

관련 용어

  • Benchmark: BrowseComp는 넓은 제품 품질이 아니라 특정 문제 묶음에서 같은 규칙으로 성능을 재는 benchmark야.
  • Eval: 모델이나 에이전트 변경 전후를 비교하려면 BrowseComp 점수와 함께 실행 조건, 검색 차단, 채점 방식을 같이 봐야 해.
  • Deep Research: OpenAI 발표에서 BrowseComp를 가장 잘 푼 예시지만, BrowseComp 과제에 맞춘 학습 주석이 붙어 있어서 일반 웹 에이전트 기준선으로 바로 쓰면 안 돼.
  • Agent: BrowseComp는 단순 채팅 모델보다 목표를 세우고 도구를 호출하며 검색 경로를 바꾸는 agent 구조를 겨냥한 시험에 가까워.
  • Tool Use: 웹 검색, fetch, 코드 실행 같은 도구를 얼마나 전략적으로 쓰는지가 BrowseComp 점수를 크게 흔든다.
  • OpenAI: BrowseComp를 공개한 쪽이고, 1,266개 문제와 기준 성능표를 제공한 1차 출처야.
  • Anthropic: BrowseComp를 실제 모델 평가에 쓰면서 오염, eval awareness, 멀티 에이전트 증폭 문제를 공개적으로 분석한 2차 출처야.