AI가 낸 문제로 AI를 시험한다: AutoSciBench

에이전트가 시험지를 너무 빨리 풀어 벤치마크가 금방 쓸모없어진다. AutoSciBench는 에이전트의 풀이 과정을 훔쳐보며 문제를 스스로 더 어렵게 키운다.
English  ·  日本語  ·  한국어
← 목록으로
온
온틀 리서치
2026년 10월 08일 수정 2026.10.16 읽기 13분 조회 2

똑똑한 학생이 문제집을 무력화할 때

AI 에이전트들이 시험지를 너무 빨리 푼다. 상위 모델 여럿이 나란히 90점대 후반을 받으면, 그 시험은 더 이상 등수를 못 매긴다. 누가 더 나은지, 어디서 넘어지는지 아무것도 안 보인다.

여기서 에이전트란 질문에 바로 답하는 챗봇이 아니라, 데이터를 뒤지고 도구를 직접 돌려가며 스스로 일을 해내는 AI를 말한다. 그리고 벤치마크는 그 실력을 재는 공통 시험지다. 문제는 시험지가 고정돼 있다는 것이다. 모델은 분기마다 좋아지는데, 사람이 손으로 문제를 찍어내는 속도는 그 발전을 못 따라간다. 그래서 시험지는 금세 천장을 친다. 논문은 이 상태를 포화(saturation)라고 부른다. 실제로 재료과학의 사람 제작 벤치마크에서는 문제를 푸는 에이전트(이하 솔버)들의 평균이 95.7점, 거의 만점에 붙어 있었다. 실력 차가 보일 자리가 없었다.

AutoSciBench의 발상은 단순하면서 과감하다. 더 어려운 문제를 사람이 짜내는 대신, 에이전트가 문제를 어떻게 푸는지 그 풀이 과정을 훔쳐보고, 그걸 단서로 문제를 스스로 더 어렵게 키운다. 시험지가 학생을 보고 저절로 진화하는 셈이다.

과학 문제는 왜 더 까다로운가

벤치마크 포화는 모든 분야의 골칫거리지만, 과학은 유독 고약하다. 이유는 두 가지 차이를 겹쳐 보면 드러난다.

첫째, LLM과 에이전트는 다르다. LLM(대형 언어모델) 문제는 답에 필요한 정보가 이미 질문 안에, 또는 모델이 외운 지식 안에 들어 있다. 반면 에이전트는 환경과 직접 부딪쳐 필요한 정보를 스스로 얻어내야 한다. 계획을 세우고, 도구를 돌리고, 나온 결과를 보고, 다시 분석한다.

둘째, 일반 에이전트와 과학 에이전트가 또 다르다. 코딩이나 웹 작업은 틀리면 에러가 바로 뜬다. 신호가 즉시 오니 고칠 수 있다. 과학 분석은 그런 친절한 정답 신호를 주지 않는다. 중간에 나온 숫자는 "이 해석이 맞다"고 말해주지 않는다. 간접 증거일 뿐이다. 예를 들어 에이전트가 유전자 발현 측정값 원본을 뒤져 어떤 조작이 평균 이상의 효과를 냈는지 확인하고, 그 결과를 또 다른 증거와 겹쳐야 비로소 결론에 다가선다.

두 차이를 합치면 결론은 하나다. 과학 에이전트를 제대로 평가하려면 질문만 잘 만들어선 안 된다. 에이전트가 뒤질 데이터와 도구, 그리고 간접 증거를 어떻게 엮어 결론에 이르는지까지 함께 설계해야 한다. 원본 데이터 재검토, 중간 결과 검증, 여러 단계의 증거 통합 — 이게 과학 과제가 진짜로 재야 할 능력이다. 그런데 이런 문제 하나를 제대로 만들려면 전문가의 시간이 많이 든다. 그래서 더더욱 모델 속도를 못 따라간다.

스테이크 굽듯 문제를 짓는다

AutoSciBench는 과제 하나를 두 층으로 나눠 만든다. 완벽한 스테이크 한 접시를 내는 과정에 빗대보자.

위층은 콘셉트(concept)다. 무엇을 평가할지 정하는 단계, 말하자면 "오늘은 스테이크를 굽는다"고 메뉴를 정하는 자리다. 어떤 과학 분야인지, 어떤 데이터를 다루는지, 어떤 작업을 시킬지 — 재료와 목표만 적고 구체적인 조리법은 비워둔다.

아래층은 레시피(recipe)다. 그 요리를 어떤 순서로 만들지 적는 단계다. 여기서 핵심 결정은 하나다. 무엇을 미리 손에 쥐여주고, 무엇은 직접 알아내게 할 것인가.

논문의 실제 예가 깔끔하다. 결정 구조를 분류하는 과제인데, 필요한 재료 데이터(이온 반지름 표, 분류 규칙)는 파일로 넣어주되 정작 계산 공식과 답은 주지 않는다. 질문은 딱 한 줄, "이 물질의 구조를 분류하라." 에이전트는 데이터를 꺼내 스스로 지표를 계산하고 규칙을 적용해야 답에 닿는다. 정답은 출제 쪽이 같은 계산을 미리 돌려 검증해둔다. 이렇게 두 층을 나누면, 같은 분석 능력을 겨냥하면서도 질문과 데이터는 얼마든지 다르게 찍어낼 수 있다.

여기까지는 기존 자동 생성 연구와 크게 다르지 않다. AutoBencher나 BenchMaker 같은 앞선 방법들도 정해둔 목표나 품질 기준에서 문제를 뽑아낸다. 다만 그들은 주로 "질문만 잘 만들면 되는" LLM 평가에 초점을 둔다. 과학 에이전트는 질문뿐 아니라 환경과 데이터, 간접 증거의 해석까지 설계해야 한다는 게 앞서 본 차이고, 두 층 구조는 바로 그 요구에서 나왔다.

진짜 차별점은 그다음이다. 레시피를 잘 짰다고 의도한 요리가 나온다는 보장은 없다. 에이전트가 도구 하나의 출력만 슬쩍 보고 답을 찍을 수 있기 때문이다. 요리로 치면 속은 덜 익혔는데 소스만 끼얹어 그럴듯하게 낸 접시다. 논문은 이 얕은수를 지름길(shortcut)이라 부른다.

그래서 맛을 보며 레시피를 고치는 과정을 넣는다. 만든 과제를 솔버가 여러 번 독립적으로 풀어본다. 그 풀이 과정과 최종 답을 심판(채점을 맡는 또 다른 모델)이 두 눈으로 본다. 하나는 "질문과 데이터가 채점 가능한 명확한 답을 떠받치는가"(검증 가능성), 다른 하나는 "솔버가 여러 번 풀어 얼마나 자주 맞히는가"(풀이율)다. 풀이 과정을 뜯어보면 에이전트가 어느 대목에서 지름길로 샜는지도 드러난다.

채점은 되는데 너무 쉬우면, 심판의 지적을 근거로 레시피를 손본다. 중간 출력 하나로는 안 되고 추가 검증과 해석이 필요하도록 데이터와 질문을 다시 짠다. 그래도 애초 노린 추론이 안 나오면 콘셉트, 즉 메뉴 자체를 갈아끼운다. 이 고치고-다시 풀리고-채점되는 사이클을 과제 하나당 최대 열 번 돈다.

마지막 조각은 요리 노트다. 과제 하나를 고치며 배운 걸 그 과제에만 쓰고 버리면 아깝다. 그냥 두면 생성기는 비슷한 약점을 가진 메뉴를 또 내놓는다. 그래서 정제하며 얻은 교훈을 경험 카드로 요약해 쌓아둔다. 어떤 설계가 직답을 허용했는지, 어떤 수정이 솔버 행동을 바꿨는지, 아직 못 푼 숙제는 무엇인지. 눈에 띄는 건 실패한 레시피도 노트에 남긴다는 점이다. 실패에서도 배우는 구조다.

숫자가 말하는 것

가장 극적인 장면은 재료과학이다. 사람이 만든 벤치마크에서 95.7점으로 천장에 붙어 있던 솔버 평균이, Claude Opus 4.8이 생성한 벤치마크에서는 70.2점으로 떨어졌다. 전산생물학도 79.8점에서 57.4점으로 내려앉았다. 초록이 내세운 22.4·25.5포인트 하락이 바로 이 Opus 4.8 기준 수치다. 생성기에 따라 하락폭은 달랐지만, 방향은 같았다.

떨어졌다는 것보다 중요한 건 흩어졌다는 것이다. 만점 근처에 뭉쳐 분간이 안 되던 점수들이, 생성 벤치마크에서는 아래로 넓게 퍼졌다. 포화됐던 시험지가 다시 모델 간 실력 차를 가려내기 시작한 것이다. "벤치마크 포화를 푼다"는 주장의 핵심 증거가 여기 있다.

이 어려움이 특정 짝에만 통한 우연이 아니라는 신호도 있다. 문제를 만드는 데 쓰이지 않은 다른 모델들도 생성 벤치마크에서 낮은 점수를 받았다. 난도가 출제자-응시자 쌍을 넘어 다른 모델에게도 전이된 것이다.

품질은 또 다른 축이다. 생성된 과제는 세 분야 모두에서 사람 제작 과제보다 평균 품질 점수를 높게 받았다. 어렵기만 한 게 아니라 평가로서 유효했다는 뜻이다. 단, 그 품질 점수를 매긴 것도 난도를 매긴 그 LLM 심판이다. 사람 전문가가 아니다 — 해석할 때 감안할 대목이다.

논문은 두 장치가 정말 효과가 있는지 하나씩 떼어내 보는 실험(절제 실험)도 돌렸다. 반복 정제는 라운드가 돌수록 난도를 올렸는데, 그 상승이 "데이터 재검토와 해석을 더 요구하는" 방식으로 일어났다. 요구되는 추론의 성격 자체가 바뀐 것이다. 요리 노트에 해당하는 경험 기반 생성은, 앞서 효과가 확인된 풀이 요구를 다음 과제에 재사용하며 더 어려운 문제를 만들어냈다.

이 틀이 아직 못 넘은 선

저자들도 인정한다. 이 틀은 한 번에 좋은 과제를 뽑지 못한다. 반복 정제를 둔 것 자체가 그 증거다. 그 위에 세 가지를 더 짚어둘 만하다.

첫째, 자기참조 위험이다. 문제를 만드는 생성기와 그걸 푸는 솔버가 같은 모델이다. "자기가 못 푸는 걸 어렵다고 판정"하는 함정이 여기 숨어 있다. 난도가 다른 모델로 전이됐다는 점이 어느 정도 방어막이 되지만, 생성기 자신의 맹점은 과제에 그대로 상속된다. 생성기가 애초에 놓치는 종류의 과학적 오류는 문제로 만들어지지도 않는다.

둘째, 풀이율의 함정이다. 수능으로 치면 이렇다. 복잡한 사고력을 요구해 정답률이 낮은 킬러 문항과, 지문이 모호하거나 오탈자가 있어 정답률이 낮은 불량 문항은 전혀 다른 이야기다. 둘 다 풀이율은 낮게 나온다. AutoSciBench는 검증 가능성을 함께 봄으로써 둘을 가르려 하지만, 그 심판 역시 LLM이라는 데 한계가 있다.

셋째, 정답의 신뢰성이다. 과제의 정답을 에이전트가 직접 계산해 만든다. 규칙이 또렷한 계산형이라면 몰라도, 더 열린 과학 분석에서 자동으로 뽑은 "정답"이 전문가 눈에도 정답인지는 따로 확인이 필요하다.

참고로 실험은 전산생물학·재료과학·임상영상 세 분야에서 돌렸고, 각각 CompBioBench·MatTools·MedCTA를 씨앗 벤치마크로 썼다. 다만 임상영상의 사람 제작 벤치마크 점수는 비교 표에서 빠졌다. 정답을 글자까지 맞추는 방식이 아니라 LLM이 채점하는 방식이라 다른 두 분야와 같은 잣대에 올릴 수 없어서다. 그래서 정확도 하락은 전산생물학·재료과학 두 분야 이야기다. 세 분야가 똑같이 어려워졌다고 뭉뚱그리면 안 된다.

우리 현장에서는 어떻게 쓰나

이 논문의 고민은 온틀의 일상과 그대로 겹친다. 온틀은 고객 프로젝트마다 AI PM을 붙인다. 사람 프로젝트 매니저가 하던 일 — 요청을 받아 데이터를 분석하고 결과를 정리해 보고하는 일 — 을 AI 에이전트가 맡아 수행하는 방식이다. 그 PM을 고객에게 내보내기 전, 우리는 매번 묻는다. "이 PM이 이 고객의 데이터로 진짜 분석을 해내는가, 아니면 그럴듯한 답으로 넘어가는가."

문제는 지금 이 검증이 고정된 테스트 몇 개에 기대고 있다는 것이다. 모델을 한 단계 올리면 그 테스트는 금세 전부 통과된다. 통과율 100%는 "완벽하다"가 아니라 "이제 구분을 못 한다"는 신호인데, 우리는 종종 그걸 합격으로 읽는다.

한 장면을 끝까지 따라가 보자. 고객이 매출 원본 데이터를 엑셀로 올린다. 온틀 워크스페이스는 이미 이 파일을 표로 미리보기한다. PM에게 "이상 구간을 찾아라"라고 시킨다. PM이 도구를 한 번 돌려 나온 요약 숫자 하나만 보고 "3월에 급감"이라고 결론 내면, 그건 속 덜 익은 스테이크에 소스만 끼얹은 답이다. AutoSciBench의 발상을 빌리면, 바로 그 지점에서 검증 과제를 다시 쓴다. 요약 숫자 하나로는 결론이 안 나오도록, 여러 시트의 증거를 교차해야만 답이 서도록 데이터와 질문을 고쳐 짜는 것이다. 그리고 우리 PM이 반복해서 빠지는 지름길을 경험 카드처럼 쌓아두면, 다음 고객의 검증을 짤 때 그 약점을 처음부터 겨눌 수 있다. 파견 전 QA가 "통과/불통과" 도장에서 "이 PM의 실패 지도"로 바뀌는 셈이다.

다만 한 가지 전문가로서의 제언을 덧붙이고 싶다. 앞서 본 자기참조 위험을 우리 쪽에도 그대로 들이지 않으려면, 검증 과제를 만드는 쪽과 검증받는 PM을 서로 다른 모델로 분리하는 교차검증 구조를 고민해볼 지점이다.

씨앗 벤치마크 없이 완전히 무에서도 문제를 만드나요?

아닙니다. 정제 루프는 에이전트가 자동으로 돌리지만, 출발점은 기존 사람 제작 벤치마크입니다. 어떤 분야를 평가할지도 사람이 정합니다. 무에서 창조한다기보다, 기존 자산과 문헌을 사전 지식 삼아 키워 나가는 구조에 가깝습니다.

생성기마다 난도가 다르면, 어떤 벤치마크를 믿어야 하나요?

하나의 절대 난도를 찍어주는 도구가 아니라고 보는 게 맞습니다. 믿음의 근거는 난도가 생성에 쓰지 않은 다른 모델로도 전이됐다는 점입니다. 실무에서는 무엇을 변별하고 싶은지에 맞춰 생성기를 고르고, 반드시 바깥 모델로 난도가 유지되는지 교차 확인하는 편이 안전합니다.

과학이 아닌 다른 분야에도 통할까요?

이 논문이 검증한 범위는 전산생물학·재료과학·임상영상 세 과학 분야뿐입니다. 풀이 과정을 보고 지름길을 닫는다는 핵심 발상은 분야를 가리지 않을 법하지만, 그 바깥에서의 효과는 이 논문이 보여준 결과가 아닙니다. 가져다 쓰려면 각자 도메인에서 다시 검증해야 합니다.

참고자료

  • 논문: AutoSciBench: Autonomous Benchmark Generation for Evaluating Scientific Agents
  • 저자: Dongki Kim, Namkyeong Lee, Surag Nair, Carl Edwards, Xiner Li, Edward De Brouwer, Jenna Lynn Collier, Sung Ju Hwang, Gabriele Scalia, Ehsan Hajiramezanali (KAIST, Genentech)
  • arXiv: https://arxiv.org/abs/2610.05140
  • HuggingFace: https://huggingface.co/papers/2610.05140