검증 점수를 보고 계속 고치는데, 왜 과적합이 안 될까?
요즘 머신러닝 쪽에서 ‘연구 에이전트’라는 게 꽤 뜨거운 주제거든요. 이게 뭐냐면, LLM한테 데이터셋과 목표를 던져주면 알아서 학습 코드를 짜고, 모델을 돌리고, 검증 점수를 확인한 다음, “음, 피처를 하나 더 추가해볼까?” 하면서 코드를 고쳐서 다시 돌리는 걸 수십, 수백 번 반복하는 시스템이에요. AIDE 같은 오픈소스 에이전트나 OpenAI의 MLE-bench 같은 벤치마크에서 보던 바로 그 방식이죠.
그런데 여기서 좀 이상한 점이 하나 있어요. 머신러닝 수업 첫 시간에 배우는 원칙 중 하나가 “검증 데이터를 보고 모델을 고르되, 너무 많이 들여다보면 검증 데이터에도 과적합된다”는 거잖아요. 에이전트는 검증 점수를 보고 코드를 고치는 행동을 사람보다 훨씬 많이, 훨씬 빠르게 반복해요. 상식대로라면 검증 점수만 화려하고 실제 테스트 점수는 형편없는 모델이 나와야 정상인데요. 아마존 사이언스 블로그에서 바로 이 질문을 정면으로 다뤘어요. “왜 연구 에이전트는 과적합하지 않는가?”
이게 뭐냐면: 적응적 데이터 분석의 함정
과적합이라는 말부터 풀어볼게요. 모델이 학습 데이터의 진짜 패턴이 아니라 우연한 잡음까지 외워버려서, 새로운 데이터에서는 성능이 떨어지는 현상이에요. 시험 문제집을 통째로 외웠더니 문제집 점수는 만점인데 실제 시험에서는 망하는 것과 비슷하죠.
그런데 검증 데이터에도 같은 일이 생길 수 있어요. 검증 점수를 보고 “이 설정이 좋네” 하고 고르는 행동 자체가 검증 데이터에서 나온 정보를 모델에 흘려 넣는 거거든요. 이걸 학계에서는 ‘적응적 데이터 분석(adaptive data analysis)’이라고 불러요. 캐글 해보신 분이라면 익숙할 텐데요, 퍼블릭 리더보드 점수에 맞춰서 제출을 수백 번 반복하다가 프라이빗 리더보드가 열리는 순간 순위가 뚝 떨어지는 경험, 바로 그거예요. 이론적으로는 검증 데이터를 들여다보는 횟수가 늘어날수록 이 위험이 커진다고 알려져 있어요.
그런데 실제로는 잘 안 일어난다
재미있는 건, 이런 현상이 사람 연구자 커뮤니티에서도 예상보다 훨씬 약하게 나타났다는 거예요. 몇 년 전 버클리의 연구팀이 CIFAR-10과 ImageNet의 새로운 테스트셋을 만들어서 기존 모델들을 다시 평가한 유명한 연구가 있는데요. 수년 동안 전 세계 연구자들이 같은 테스트셋을 보고 모델을 개선해 왔으니 과적합이 심할 거라 예상했는데, 실제로는 기존 테스트셋에서 잘하는 모델이 새 테스트셋에서도 순위를 거의 그대로 유지했어요. 점수는 전체적으로 좀 떨어졌지만 ‘순서’는 안 바뀌었다는 거죠.
에이전트에서도 비슷한 그림이 나오는 이유를 둘러싼 핵심 논점들을 정리하면 이래요.
첫째, 에이전트가 시도하는 변화의 ‘종류’가 다르다는 점이에요. 검증 데이터에 과적합하려면 검증 데이터의 잡음에 딱 맞는 미세한 조정이 필요한데, 에이전트가 하는 건 “그래디언트 부스팅으로 바꿔보자”, “날짜 피처를 요일로 분해해보자”, “학습률을 낮춰보자” 같은 구조적인 변경이에요. 이런 변경은 검증 데이터의 잡음에 맞추기보다는 데이터의 진짜 패턴을 더 잘 잡는 방향으로 작동할 가능성이 커요. 탐색 공간이 구조적으로 제한되어 있으면 이론상의 최악 시나리오와 실제 사이에 큰 간격이 생기는 거죠.
둘째, 시도 횟수가 생각보다 적다는 거예요. 이론에서 말하는 과적합은 검증 데이터 크기에 비해 시도 횟수가 엄청나게 많을 때 문제가 되는데, 에이전트가 실제로 돌리는 실험은 수십에서 수백 번 수준이고, 검증 데이터가 수천 개 이상이면 통계적으로 여유가 꽤 있어요.
셋째, LLM이 갖고 있는 ‘사전 지식(prior)’이 필터 역할을 한다는 점이에요. 사람 연구자가 검증 점수가 0.1% 올랐다고 이상한 설정을 채택하지 않듯이, 에이전트도 상식적으로 말이 되는 변경만 시도하는 경향이 있거든요. 이게 무작위 탐색과 결정적으로 다른 부분이에요. 무작위로 수천 가지 설정을 던져보는 방식이라면 잡음에 맞는 설정이 걸릴 확률이 높아지지만, “말이 되는” 변경만 골라 시도하면 그 확률이 크게 줄어들어요.
업계 맥락에서 보면
이 질문이 중요한 이유는, 자동화된 ML 실험이 이제 연구실 장난감이 아니라 실제 제품 파이프라인에 들어오고 있기 때문이에요. 아마존은 이미 AutoGluon 같은 AutoML 프레임워크를 오래 만들어왔고, 구글의 AlphaEvolve나 Sakana AI의 ‘AI Scientist’ 같은 프로젝트는 아예 알고리즘 발견 자체를 에이전트에게 맡기고 있어요. 이런 시스템의 결과를 믿을 수 있는지는 결국 “검증 점수가 진짜 일반화 성능을 반영하는가”에 달려 있죠. 그래서 이 질문에 대한 답이 “생각보다 괜찮다”라면, 에이전트 기반 실험 자동화에 대한 신뢰도가 한 단계 올라가는 셈이에요.
한국 개발자에게 주는 시사점
실무에서 바로 챙길 수 있는 건 세 가지예요. 하나, 에이전트든 사람이든 최종 판단용 홀드아웃 테스트셋은 절대 루프 안에 넣지 마세요. 과적합이 약하다는 것과 없다는 건 다른 얘기거든요. 둘, 에이전트가 시도한 변경 이력을 기록해서 “어떤 종류의 변경이 검증 점수를 올렸는지” 사람이 검토하는 절차를 두면, 잡음에 맞춘 변경인지 진짜 개선인지 구분하기 쉬워요. 셋, 검증 데이터 크기를 에이전트 실험 횟수에 맞춰 넉넉하게 잡으세요. 데이터가 적은 프로젝트일수록 이 문제가 실제로 튀어나올 수 있어요.
마무리
한 줄로 정리하면, “에이전트가 검증 점수를 아무리 많이 봐도, 시도하는 변경이 구조적이고 상식적이면 과적합은 이론이 겁주는 것만큼 심하지 않다”는 거예요. 여러분은 AutoML이나 에이전트가 찾아준 모델을 얼마나 신뢰하시나요? 검증 점수와 실제 배포 성능이 크게 달랐던 경험이 있다면 어떤 경우였는지 나눠주세요.
🔗 출처: Hacker News