AI 연구 에이전트 평가: 열린 연구를 결과물만으로 채점하면 안 되는 이유

AI 연구 에이전트의 실력을 보려면 “코드를 끝까지 만들었는가”나 “그럴듯한 논문 초안을 냈는가”만 물으면 부족하다. 열린 연구는 정답이 미리 정해진 티켓이 아니기 때문이다. 최근 공개된 두 사례의 shadow evaluation은 최전선 에이전트에게 각각 6일과 수천 달러 규모의 컴퓨트를 줬을 때, 엔지니어링 작업은 사람 도움 없이 끝냈지만 핵심 연구 질문에는 실질적인 진전을 만들지 못했다고 보고했다. 나는 이 결과를 에이전트가 연구에 쓸모없다는 판정으로 읽지 않는다. 오히려 연구 자동화의 병목이 실행량이 아니라 연구 기준을 세우고, 막힌 설계를 되돌리고, 실패를 전문가가 재검증할 수 있게 남기는 능력이라는 신호로 본다. 에이전트를 연구팀에 넣으려면 모델 데모 대신 질문·증거·판정이 분리된 평가 루프부터 만들어야 한다.

왜 기존 벤치마크만으로 열린 연구를 판단하기 어려운가

코딩 벤치마크나 수학 문제는 대개 채점 가능한 정답, 제한된 입력, 명확한 완료 조건을 가진다. 그래서 같은 환경에서 여러 모델을 비교하기 좋다. 반면 실제 연구는 출발점부터 다르다. 좋은 질문은 아직 답이 없고, 실험 설계가 틀릴 수 있으며, 중간 결과가 가설을 바꾸기도 한다. 실패한 실험을 계속 돌릴지, 측정 방식을 바꿀지, 질문의 범위를 줄일지는 단순한 실행 계획 문제가 아니라 연구 판단이다.

arXiv에 2026년 7월 29일 제출된 *Can AI agents conduct open-ended AI research?*는 이 간극을 직접 다뤘다. 저자들은 이미 고품질이지만 아직 공개되지 않은 NeurIPS 2026 제출 논문의 중심 질문을 에이전트에게 맡기고, 원 논문의 저자가 산출물을 채점하는 방식을 shadow evaluation이라 부른다. 두 사례에서 에이전트는 구현과 실행을 수행했지만, 저자들은 결과를 모두 명확히 거절했다. 논문이 제시한 반복 실패는 다섯 가지다. 출판 가능한 연구의 기준을 잘못 판단했고, 설계의 결함에 창의적으로 대응하지 못했으며, 막힌 길에서 효과적으로 되돌아가지 못했고, 자원 상태를 제대로 읽지 못했으며, 지시에서 이탈했다.

이 관찰은 “에이전트는 연구를 못 한다”는 보편 결론이 아니다. 사례 수가 둘이고, 연구 과제·하네스·모델 선택에 따라 결과는 달라질 수 있다. 다만 데모의 완성도와 연구의 진전을 같은 지표로 취급하면 위험하다는 점은 분명하다. 실행 가능한 코드가 있다는 사실은 연구 질문에 답했다는 증거가 아니다.

shadow evaluation은 결과가 아니라 연구 과정의 증거를 묻는다

shadow evaluation의 핵심은 에이전트에게 공개된 답을 재현하게 하는 데 있지 않다. 원 저자가 답을 알고 있지만 아직 발표하지 않은 연구 질문을 주고, 그 과정과 결과를 해당 분야 전문가가 판정하도록 만드는 데 있다. 자동 채점과 블라인드 논문 심사 사이의 빈틈을 메우려는 시도다. 자동 채점은 열린 질문을 너무 좁히고, 블라인드 심사는 리뷰 품질과 확률성의 영향을 크게 받는다.

이 구조가 실무에 주는 힌트는 단순하다. AI 연구 에이전트의 평가는 하나의 점수보다 네 묶음의 증거를 남겨야 한다.

1. 질문 증거: 에이전트가 해결하려 한 질문과 성공 기준을 시작 전에 고정한다. “성능 개선” 같은 표현 대신 어떤 기준선, 어떤 데이터, 어떤 반증 조건을 넘을지 적는다.
2. 설계 증거: 왜 이 실험을 골랐는지, 어떤 대안을 버렸는지, 실패가 발생하면 무엇을 바꿀지 기록한다. 가설을 바꾼 시점도 빠지면 안 된다.
3. 실행 증거: 코드·환경·시드·로그·비용을 재현 가능하게 남긴다. 이것은 구현이 실제로 돌아갔는지 확인하는 레인이다.
4. 판정 증거: 결과를 만든 에이전트가 아닌 도메인 검토자가 질문에 실제로 답했는지, 부정 결과도 의미 있게 해석됐는지 판정한다.

METR이 2026년 7월 28일 공개한 독립 연구자용 사후 조사 안내도 비슷한 방향을 가리킨다. AI 시스템이 사람 의도와 어긋난 행동을 보였을 때, 외부 조사가 어떤 질문에 답해야 하는지와 필요한 접근 권한, 결과 공개 방식을 별도로 다룬다. 실행 로그를 갖고 있다는 것만으로 충분하지 않고, 독립적인 조사자가 무엇을 재구성하고 어떤 결론을 공유할 수 있는지가 중요하다는 뜻이다.

작은 팀은 연구 에이전트를 어떻게 안전하게 시험할까

거대한 평가 인프라가 없어도 시작은 가능하다. 먼저 실제 연구 주제를 통째로 맡기지 말고, 이미 팀이 이해하는 작은 공개 질문 하나를 고른다. 예를 들어 “이 데이터 분할에서 특정 전처리가 기준선보다 개선되는가”처럼 결과를 확인할 수 있으면서도, 실험 설계와 해석이 필요한 과제가 적당하다. 그 다음 산출물과 판단을 같은 문서에 섞지 않는다.

아래 명령은 연구 후보 브랜치를 검토하기 전 변경 범위와 재현 단서를 확인하는 최소 preflight다. macOS 또는 Git 환경에서 실제로 실행할 수 있고, 통과 결과는 연구의 타당성 보장이 아니라 전문가가 무엇을 다시 봐야 할지 좁히는 출발점이다.

# 연구 후보 브랜치에서: 변경 범위와 재현 단서를 빠르게 확인한다.
git status --short
git diff --check HEAD~1..HEAD
git log -1 --format='%h %s'
find . -maxdepth 3 -type f \( -name 'README*' -o -name 'requirements*.txt' -o -name 'pyproject.toml' \) -print

그 뒤 검토자는 다음 세 질문을 따로 답해야 한다. 첫째, 에이전트가 측정한 값이 시작할 때 정의한 질문에 실제로 연결되는가. 둘째, 부정적인 결과가 나오자 원인을 좁혔는가, 아니면 다른 설정을 무작정 더 돌렸는가. 셋째, 사람이 같은 환경에서 핵심 주장을 다시 확인할 수 있는가. 이 세 질문은 모델의 말재주가 아니라 연구의 복구 가능성을 본다.

내 의견: 연구 자동화의 다음 지표는 속도가 아니라 되돌림의 질이다

내 의견은 분명하다. AI 연구 에이전트의 평가를 논문 수, 실행 횟수, 만들어 낸 코드 줄 수로만 하면 가장 중요한 실패를 보지 못한다. 열린 연구에서 좋은 작업은 빠른 정답이 아니라, 잘못된 가설을 일찍 버리고 그 이유를 남기는 과정까지 포함한다. 가벼운 반론도 있다. 전문가 검토를 넣으면 자동화의 속도와 규모가 줄어든다. 맞다. 하지만 아직 연구 질문의 타당성을 독립적으로 판정하기 어려운 단계에서 검토를 빼면, 우리는 값비싼 계산을 “진전”으로 오인할 가능성이 더 크다. 초기에는 사람을 완전히 대체하는 대신, 사람이 검토할 연구 공간을 더 잘 좁히는 도구로 쓰는 편이 정직하다.

김덕환 운영자 관점

김덕환 운영자 관점에서 연구·리서치 에이전트는 “좋은 결론을 빨리 쓰는 도구”보다 “다음 판단을 위해 무엇을 다시 확인해야 하는지 남기는 도구”여야 한다. 콘텐츠 조사나 제품 실험도 마찬가지다. 답을 하나 낸 뒤에는 출처, 반론, 제외한 가설, 재현 가능한 실행 단서를 함께 남기자. 그래야 다음 작업이 이전의 문장만 이어받지 않고, 이전의 증거 위에서 실제로 앞으로 간다.

참고 자료

• Can AI agents conduct open-ended AI research? Early evidence from two case studies — arXiv:2607.27191, 2026-07-29
• METR: How independent researchers could investigate AI propensities after misalignment incidents — 2026-07-28