이 글은 「AI 공부 지도 20부작」의 16편 (M6) 입니다.
앞 편: M4 — Tool Use, M5 — Evaluation이 agent의 방향감각을 만든다
다음 편: M7 — Meta-Harness가 loop 위의 땅을 바꾼다
0. 들어가기 전에
M5에서 “eval이 있어야 agent가 방향감각을 가진다” 는 얘기를 길게 했었죠. 신호가 없으면 loop는 그냥 바퀴만 빠르게 도는 것이고, 신호가 있어야 다음 시도가 이전 시도를 넘어서게 된다는 내용이었어요.
이번 편은 거기서 한 칸만 더 나갑니다. “Autoresearch” 라는 용어가 요새 AI 뉴스에 자주 등장해요. 논문 제목에도 박히고, 스타트업 피칭덱에도 들어가고, 트위터에서도 “AI가 이제 스스로 연구까지 한다” 식의 문장이 돌아다닙니다. 이 단어를 처음 들으면 꽤 무섭게 들리죠. “AI가 혼자 연구하는 기계” 라니, 내 일자리가 어떻게 되는 건가 싶기도 하고요.
그런데 이 글의 목적은 그 무서운 느낌을 풀어내는 겁니다. Autoresearch를 분해해서 들여다보면, 그건 혼자 연구하는 마법 상자 가 아니라 “실험을 계속 돌리는 구조” 에 가깝거든요. 오래 돌리는 기계가 아니라 실험이 반복되는 기계. 이 차이가 핵심이에요. 이 차이를 놓치면 제품 비교를 할 때도 논문을 읽을 때도 엉뚱한 곳에 기대를 걸게 됩니다.
이번 편은 M1 ~ M5를 다 읽으신 분을 기준으로 써요. retrieval, agent, tool use, evaluation 의 감각이 이미 있으신 독자를 상정합니다. 그 감각 위에 autoresearch 라는 한 칸을 더 얹는 거예요. 다음 편 M7에서 “Meta-Harness” 라는 더 바깥의 개념으로 넘어가는 다리 역할도 이 글이 합니다.
1. “AI가 알아서 연구한다” 라는 말이 위험한 이유
먼저 이 말의 문제점부터 짚고 갈게요. 헤드라인에 자주 등장하는 표현이 “AI가 스스로 실험하고 논문까지 쓴다” 입니다. 제목만 보면 그림이 이렇게 그려져요. 한 버튼을 누르면 AI가 밤새 혼자 뭔가를 굴리고, 아침에 와 보니 새로운 발견이 종이 한 장으로 튀어나와 있다. 마치 과학소설의 한 장면 같죠.
이 그림이 왜 위험하냐면, 실제 autoresearch 시스템을 쓸 때 판단을 어디에 둬야 하는지 를 흐려 놓기 때문입니다.
비유로 한 번 바꿔 볼게요. 요리 실험실을 상상해 보세요. 새로운 레시피를 만든다고 치면, 과정이 이렇습니다. “이 조합이 괜찮을 것 같다” 는 가설을 세우고, 실제로 그 조합으로 요리해 보고, 맛을 보고, 어디가 부족한지 적고, 다음엔 소금을 줄여서 다시 해 봅니다. 이걸 스무 번쯤 반복하면 쓸만한 레시피가 나와요.
이 요리사가 혼자 한 것 같지만 자세히 보면 손에 쥐고 있는 게 여러 개예요. 맛을 판단하는 기준 (짠지 싱거운지 알아채는 혀), 예산 (재료비), 시간 (한 번 끓이는 데 40분), 멈출 줄 아는 판단 (스무 번 해도 안 되면 방향을 바꿔야 한다) 같은 거죠. 이 모든 걸 사람이 쥐고 있었어요. 주방장이 혼자 움직인 게 아니라 여러 제약 안에서 일한 것 입니다.
Autoresearch도 똑같아요. “AI가 혼자 한다” 는 말은 이 맥락을 전부 날려버립니다. 실제로는 가설을 어떻게 세울지, 어떤 실험을 허용할지, 언제 멈출지, 결과를 어떻게 해석할지 전부 사람이 설계해 놓은 틀 안에서 돌아가요. 그 틀이 잘 만들어져 있으면 시스템이 좋은 결과를 뱉고, 허술하면 비싸게 아무것도 못 얻습니다.
이 글이 끝날 때까지 반복할 한 문장이 있어요. “Autoresearch 는 AI가 혼자 연구하는 기계가 아니라, 실험이 반복되는 구조 그 자체다.” 이 문장을 손에 쥐고 다음 섹션으로 넘어가 주세요.
2. One-shot agent vs Persistent loop agent
이 둘을 먼저 확실히 갈라야 합니다. M3, M4 에서 “agent 는 tool 을 쓸 수 있는 LLM 이다” 라는 얘기를 했었는데, 그 agent 안에서도 두 갈래가 있어요.
One-shot agent
한 번 질문을 받고, 한 번 계획을 짜고, 도구 몇 번 쓰고, 답을 뱉고 끝나는 agent. 거의 모든 초기형 LLM 제품이 이 구조였어요. ChatGPT 초창기에 “파이썬으로 이 데이터 분석해 줘” 라고 넣으면 한 번 계산해서 답이 나왔죠. 중간에 틀려도 그대로 끝이었고요. 사용자가 “아, 그게 아니잖아” 라고 다시 입력해야 새 턴이 돌기 시작했습니다.
One-shot 의 특징은 “시도가 한 번” 이라는 거예요. 실패해도 그 실패를 반영해서 다시 시도하는 구조가 없어요. 사람이 다시 말 걸어 주면 새 세션이 열리지만, 그건 agent 내부의 loop 가 아니라 사람이 만드는 loop 예요.
Persistent loop agent
반면 persistent loop agent 는 한 번에 답이 안 나오면 스스로 다시 시도 합니다. 시도 → 결과 확인 → 가설 수정 → 다시 시도. 이걸 여러 턴 반복하고, 어느 시점에 “됐다” 판단하면 멈추는 구조예요.
Claude Code 를 써 보신 분들은 감이 잡히실 거예요. “이 테스트 통과시켜 줘” 라고 던지면, Claude Code 가 코드를 쓰고, 테스트를 돌리고, 빨간 줄 나오면 다시 코드를 고치고, 또 돌리고, 또 고쳐요. 사람이 개입하지 않아도 실패 신호를 받아서 다음 턴이 굴러갑니다. 이게 persistent loop 의 뼈대예요.
Autoresearch 는 이 persistent loop 를 “연구 과제” 라는 문제 도메인에 적용한 것 입니다. 버그 고치기가 아니라 가설 탐색. 테스트 통과가 아니라 “이 조건에서 성능이 올라가는가” 같은 실험적 질문.
두 구조의 가장 큰 차이
One-shot 은 “단발 계산” 이에요. 들어온 문제를 가공해서 한 번 뱉는 것.
Persistent loop 는 “실험실” 이에요. 문제를 여러 번 치고, 매번 조금씩 다르게 쳐 보면서 점수가 올라가는 쪽으로 움직이는 것.
많은 사람이 autoresearch 를 “오래 돌리는 One-shot” 으로 오해합니다. 그건 틀렸어요. 오래 도는 게 아니라 여러 번 다르게 도는 겁니다. 같은 시도를 오래 하는 건 시간 낭비이고, 다른 시도를 반복하는 게 탐색 이에요. 이 한 끗 차이를 잡고 가는 게 이번 편의 핵심입니다.
3. Autoresearch 의 5가지 구성 요소
자, 그럼 autoresearch 가 실제로 어떤 부품으로 이루어져 있는지 뜯어봅시다. 이 부품들은 과학철학에서 말하는 “과학적 방법” 의 재배열에 가깝습니다. 연구라는 활동을 작동 가능한 단위로 쪼갠 결과예요.
(a) 명시적 가설
시작점은 가설 입니다. “만약 이걸 이렇게 바꾸면 점수가 오를까?”, “이 조합이 더 빠를까?” 같은 질문이에요. 중요한 건 이 가설이 명시적 이어야 한다는 점입니다. 머릿속에만 있는 게 아니라 시스템이 읽을 수 있는 형태로 적혀 있어야 해요. 보통은 configuration 파일이나 프롬프트 안에 구조화된 형태로 들어가요. “learning rate 0.001 이 0.01 보다 validation loss 가 낮을 것이다” 같은 문장이 그 예시죠.
왜 명시적이어야 하냐면, 뒤에서 결과 해석할 때 “무엇을 기대했는가” 와 비교해야 하기 때문이에요. 기대가 애매하면 결과가 와도 해석이 안 됩니다.
(b) 행동 (실험)
가설을 확인하려면 실제로 뭔가를 해야 해요. 코드를 실행하거나, 모델을 학습시키거나, 벤치마크를 돌리거나, API 를 호출하거나. 이게 행동 혹은 실험 이에요.
행동은 반드시 도구 (tool) 호출을 통해 일어납니다. 여기서 M4 에서 했던 tool use 얘기가 이어져요. agent 가 직접 계산하는 게 아니라, 환경에 대고 뭔가를 실행해서 결과를 받아 오는 거예요. 코드 실행기, 파일 시스템, HTTP 요청, GPU 클러스터 — 어떤 것이든 됩니다.
(c) 결과 관찰
실험이 끝나면 결과 가 나옵니다. 점수, 로그, 출력, 에러 메시지. 이걸 시스템이 읽을 수 있는 형태로 받아야 해요.
여기가 은근히 어려운 지점이에요. 결과라는 게 단순히 “숫자 하나” 인 경우도 있지만, 긴 로그 문자열이거나 여러 지표의 조합인 경우가 많습니다. Agent 가 이걸 어떻게 요약해서 다음 판단에 쓸지가 시스템 설계의 숨은 난제예요.
(d) 결과 해석 (eval 기반)
결과가 들어왔으면 해석 해야 합니다. “이 결과는 이전보다 나은 것인가?”, “기대한 방향으로 움직였나?”, “실패인가 부분 성공인가?”
이 해석이 바로 M5 에서 얘기한 evaluation 이에요. Eval 이 있어야 결과를 숫자로 비교할 수 있고, 숫자로 비교할 수 있어야 방향감각이 생깁니다. Eval 없이 결과를 보면 “뭔가 돌긴 했는데 좋은 건지 나쁜 건지 모르겠다” 상태가 돼요. 이 상태에서 다음 가설로 넘어가면 그냥 랜덤 탐색이 됩니다.
(e) 다음 가설로 업데이트 → 반복
해석이 끝나면 이제 다음 가설 을 만들어야 해요. “learning rate 를 더 낮춰 볼까?”, “데이터 전처리를 바꿔 볼까?”, “이 방향은 꽝인 것 같으니 아예 다른 축으로 바꿀까?”
여기가 autoresearch 의 가장 미묘한 부품 입니다. 가설 업데이트가 얼마나 똑똑하냐가 전체 시스템의 효율을 결정하거든요. 단순히 “랜덤하게 다른 값 시도” 면 그냥 grid search 나 마찬가지고, “이전 결과를 반영해서 다음 방향 잡기” 가 제대로 들어가야 탐색이 정보를 쌓으면서 나아가는 형태가 됩니다.
다섯 부품이 하나의 고리로 묶인다
가설 → 행동 → 관찰 → 해석 → 가설 갱신. 이 다섯 단계가 닫힌 고리 를 이룹니다. 한 바퀴가 끝나면 다음 바퀴가 시작돼요. 이 고리가 autoresearch 의 뼈대입니다. 겉에 LLM 이 올라가든 강화학습 에이전트가 올라가든, 이 다섯 부품의 순환 구조가 있으면 autoresearch 시스템이라고 부를 수 있어요.
반대로, 이 중 한 단계라도 빠지면 autoresearch 라고 부르기 어려워요. 가설이 없으면 그냥 trial and error 고, 해석이 없으면 그냥 무한 재시도고, 가설 갱신이 없으면 그냥 retry loop 예요. 이 구별은 다음 섹션에서 더 자세히 합니다.
4. eval 이 없으면 autoresearch 는 그냥 오래 도는 시스템
M5 에서 길게 했던 얘기를 한 문장으로 압축하면 이래요. “loop 는 신호가 있어야 방향이 생긴다.”
Autoresearch 도 예외가 아니에요. 아니, 더 심해요. Autoresearch 는 loop 가 전부 인 시스템이니까요. Loop 안의 신호가 부실하면 전체가 부실해집니다.
eval 이 부실할 때 어떤 일이 일어나는가
구체적으로 봅시다. 예를 들어 “요약 품질을 올리는 프롬프트를 탐색한다” 는 autoresearch 시스템을 돌린다고 해 보죠. Eval 함수가 “요약 글자 수가 200자 이하면 좋은 요약” 이라고만 정의돼 있다면 어떤 일이 벌어질까요.
시스템은 점수가 올라가는 방향으로 갑니다. 그래서 요약을 짧게 만드는 쪽으로 프롬프트가 수렴해요. 결국 “이 논문의 핵심은 AI 다.” 같은 무의미한 요약이 만점을 받는 상황이 만들어집니다. Autoresearch 는 eval 을 정말로 최적화하기 때문에, eval 이 잘못 짜여 있으면 시스템이 그 잘못된 방향으로 확고하게 갑니다.
이걸 보통 Goodhart 의 법칙 이라고 불러요. “측정이 목표가 되면 측정은 좋은 측정이 아니게 된다.” 원래 경제학에서 나온 말인데 AI 에서도 똑같이 작동합니다. 오래 돌리는 autoresearch 일수록 이 함정이 깊어져요.
신호의 질이 시스템의 천장이다
다시 한 번. M5 의 핵심 메시지가 여기서 되돌아옵니다. eval 의 품질이 시스템의 천장 이에요. 아무리 똑똑한 LLM 을 넣어도, 아무리 오래 돌려도, eval 이 0~1 만 뱉는 noisy 한 함수면 시스템은 그 이상을 못 가요.
이 얘기를 길게 하는 이유가 있어요. Autoresearch 제품·논문을 평가할 때 가장 먼저 봐야 할 것이 “이 시스템의 eval 은 뭐로 이뤄져 있나” 이기 때문입니다. 모델이 뭐냐, 몇 턴 도냐, 파라미터가 뭐냐보다 먼저 물어야 할 질문이에요.
5. 종료 조건의 중요성
Loop 는 돌아가는 것만큼 멈추는 것 도 중요합니다. 이게 의외로 무시되는 부분이에요.
autoresearch 가 무한히 돌면 어떻게 될까
이론적으로는 가설을 무한히 만들고, 무한히 실험하고, 무한히 해석할 수 있어요. 현실에서는 세 가지가 터집니다.
비용이 폭주한다. Autoresearch 는 매 턴마다 LLM 호출 + 도구 실행이 일어납니다. 토큰 비용 + API 비용 + 인프라 비용이 턴 수에 비례해요. 100턴 돌리면 100배 비용이 들어요. 1000턴이면 1000배고요. 종료 조건 없이 “좋은 답 나올 때까지” 돌리라고 하면 수백 달러, 수천 달러가 순식간에 없어집니다.
품질이 정체되거나 나빠진다. 처음 몇 십 턴은 점수가 올라가지만, 어느 순간부터 수렴해요. 그 이후는 랜덤한 변동만 남죠. 심한 경우 과적합 이 일어나서 점수가 오히려 떨어지는 현상도 보고됩니다. Eval 의 편향을 파고드는 방향으로 시스템이 가 버리거든요.
길 잃은 탐색. 이건 좀 덜 정량적인 문제인데, agent 가 한참 돌다가 원래 목표를 놓치는 경우가 있어요. “새로운 요약 프롬프트 찾기” 에서 시작했는데, 10시간 뒤에 보니 요약이 아니라 번역 실험을 하고 있더라 같은 식이에요. Goal drift 라고도 불러요.
어떤 종료 조건이 쓰이는가
실무에서는 보통 여러 가지를 겹쳐 놓습니다.
Budget 소진. 가장 단순하고 확실해요. “이 실험에 토큰 100만 개까지” 또는 “API 비용 50달러까지” 같은 상한을 둡니다. 도달하면 멈춥니다.
Iteration 상한. “최대 50턴” 같은 식으로 loop 횟수에 상한을 둬요. 토큰 양이 덜 예측 가능한 도메인에서 유용합니다.
성능 수렴 감지. 지난 N턴 동안 점수 개선이 임계치 이하면 멈춰요. “5턴 연속으로 1% 이상 안 올랐으면 수렴한 것으로 본다” 같은 규칙이에요.
실패 누적 임계치. 실패가 연속 K번 나오면 멈춥니다. “같은 에러가 3번 연속 나오면 시스템이 막혔다고 보고 중단” 이라는 패턴이에요.
사람 확인 체크포인트. 특정 조건에서 사람에게 결재를 요청해요. 위험 조작, 고비용 단계, 이상 징후 감지 시 등.
실제 production autoresearch 시스템은 이 다섯 가지를 거의 다 겹쳐서 씁니다. 하나라도 빠지면 어느 방향에서 사고가 날지 몰라요. 이게 harness 설계의 지루한 부분이지만, 사고를 막는 게 다 여기서 이뤄집니다.
종료 조건의 설계 = autoresearch 의 안전 장치
자율 주행차에도 엑셀만 있고 브레이크가 없으면 차가 아니잖아요. Autoresearch 도 마찬가지입니다. Loop 를 도는 능력만 있고 멈추는 능력이 없으면, 그건 그냥 비싼 무한 루프 예요. 뉴스에 “AI 가 연구한다” 는 화려한 얘기가 나올 때, 실제 엔지니어들은 이 종료 조건 설계에 대부분의 시간을 씁니다.
6. 구체 사례 — 과학 실험 자동화 연구들
용어만 설명하면 손에 안 잡힐 수 있으니까 실제로 돌아간 시스템 몇 개를 가볍게 짚고 갈게요. 이 사례들이 현재 “autoresearch” 라는 용어의 구체적인 참조점입니다.
Sakana AI — The AI Scientist (2024)
일본의 AI 스타트업 Sakana AI 가 2024년에 발표한 “The AI Scientist” 는 상징적인 사례예요. 이 시스템은 머신러닝 연구 과정을 자동화하려고 시도합니다. 논문 아이디어 생성 → 실험 코드 작성 → 실험 실행 → 결과 분석 → 논문 초안 작성 → 자체 리뷰 까지가 하나의 파이프라인에 묶여 있어요.
이 글에서 중요한 건 파이프라인 내부에 loop 가 들어가 있다 는 점이에요. 아이디어가 나오면 한 번에 논문이 되는 게 아니라, 실험을 돌려 보고 결과를 해석하고 수정하고 다시 실험하는 단계들이 자동으로 돌아갑니다. 이게 autoresearch 의 전형이에요.
발표 당시 화제가 됐던 건 실제로 논문 초안 여러 편이 나왔다는 점이에요. 물론 질적으로는 아직 사람 연구자의 수준에 못 미치고, 새로운 과학적 발견이라고 부를 만한 것은 없었어요. 그래도 “파이프라인 전체를 도는 시스템이 가능은 하다” 는 점은 증명했습니다. 한계와 과대평가에 관한 논의는 섹션 9에서 다시 다뤄요.
DeepMind — FunSearch (2023)
DeepMind 가 2023년 Nature 에 발표한 FunSearch 는 조금 다른 축이에요. 이 시스템은 수학적 난제에 대한 프로그램 을 LLM 이 반복 생성하면서, 그 중 좋은 것을 evaluator 가 걸러서 다음 세대의 seed 로 쓰는 구조입니다.
구체적으로는 “cap set problem” 이라는 조합론 난제에서 사람이 이전에 알던 것보다 나은 해를 찾아냈어요. 중요한 건 FunSearch 가 한 번에 답을 낸 게 아니라 수만 번의 프로그램 생성 → 평가 → 선별 → 재생성 을 돌았다는 점이에요. 정확히 autoresearch 의 고리 구조입니다.
가설은 “이 프로그램이 더 좋은 해를 낼 것이다”, 행동은 프로그램 실행, 관찰은 해의 품질, 해석은 evaluator 의 점수, 갱신은 LLM 이 상위 프로그램을 seed 로 새 프로그램을 생성. 다섯 부품이 그대로 들어가 있어요.
Autonomous chemistry labs
이건 특정 제품이라기보다 연구 흐름이에요. Carnegie Mellon, Liverpool, ETH Zurich 같은 곳에서 로봇 실험실 + LLM 을 묶어서 가설 세우고 실제 화학 실험을 자동으로 돌리는 시스템들이 나왔습니다. 2023년 Nature 에 발표된 “Autonomous chemical research with large language models” 같은 논문이 대표적이에요.
여기서는 LLM 이 “이 반응을 이 조건에서 돌리면 수율이 올라갈 것” 같은 가설을 세우고, 로봇 팔이 실제로 비커에 재료를 붓고, 스펙트럼으로 결과를 측정하고, LLM 이 그걸 읽어서 다음 조건을 제안해요. 물리적 행동이 loop 안에 들어간 드문 사례입니다. 현재는 특정 반응 클래스에 한정된 수준이지만, “autoresearch 가 digital 을 넘어서 physical 도메인으로 확장되는 방향” 을 보여주는 사례예요.
세 사례의 공통점
세 사례 모두 한 번에 답이 나오지 않아요. 전부 수십~수만 회의 반복을 합니다. 그리고 전부 평가 기준 이 명시적이에요. Sakana 는 자체 peer review, FunSearch 는 프로그램 실행 결과 점수, 자율 실험실은 실제 측정값. 이 평가 기준이 loop 의 나침반 역할을 해요.
이게 바로 섹션 4에서 얘기한 “eval 이 시스템의 천장” 이라는 말의 현장입니다. 성공한 autoresearch 시스템들은 예외 없이 평가 함수를 공들여 설계 했어요.
7. Autoresearch vs 그냥 loop — 뭐가 다른가
여기까지 오면 의문이 하나 생깁니다. “그냥 retry loop 랑 뭐가 달라?” 라는 질문이에요. 실패하면 다시 해 보는 건 Claude Code 에서도, ChatGPT 에서도 일어나잖아요. 그럼 그것도 autoresearch 인가요?
retry loop 의 구조
일반 retry loop 는 보통 이런 식이에요.
- 시도
- 실패 감지
- 같은 방식 (또는 아주 약간만 바꿔서) 재시도
- 성공하면 종료, 실패 누적되면 포기
이 구조의 특징은 가설이 없다 는 거예요. “왜 실패했는지” 에 대한 모델이 없거든요. 그냥 “한 번 더 해 본다” 예요. 실패 이유가 일시적 네트워크 문제면 먹힐 수 있고, 근본 문제면 계속 실패만 해요. Retry 는 탐색이 아니라 인내 입니다.
autoresearch 의 구조
Autoresearch 는 실패가 나면 “왜 실패했는가” 를 해석합니다. 그 해석을 바탕으로 다음 시도는 이전과 의도적으로 다르게 설계돼요. “learning rate 가 너무 커서 발산한 것 같다 → 다음엔 절반으로 줄여 보자.” 이게 가설 업데이트예요.
이 업데이트가 있으면 실패도 정보가 됩니다. “이 방향은 아니다” 라는 걸 알아낸 것만으로도 탐색 공간을 줄였으니까요. Retry 는 실패에서 아무것도 배우지 않지만, autoresearch 는 실패에서 배웁니다.
경계가 애매한 경우
실무에서는 두 구조가 섞이는 경우가 많아요. “실패하면 에러 메시지를 읽고 다르게 시도” 라는 패턴은 중간쯤에 있어요. 가설 업데이트가 있긴 한데 얕죠. 이걸 miniature autoresearch 라고 부를 수 있어요. 다음 섹션에서 자세히 봅니다.
구별의 한 줄: 가설 업데이트가 없는 반복은 retry 고, 가설 업데이트가 있는 반복은 autoresearch 다. 이 경계를 잡고 있으면 제품 비교할 때 헷갈림이 확 줄어요.
8. 실무에서 마주치는 autoresearch 요소들
사실 여러분은 이미 autoresearch 의 작은 조각들을 매일 쓰고 있어요. 제가 주로 쓰는 Claude Code 안에 여러 개가 숨어 있습니다.
Verification loop
Claude Code 의 verification loop 는 “작업 완료 → 테스트 실행 → 실패면 수정 → 다시 실행” 을 돕니다. 이건 retry 에 가깝지만, 실패 메시지를 읽고 수정 방향을 다르게 잡는 부분에서 얕은 autoresearch 요소가 있어요.
가설: 이 코드는 이 테스트를 통과할 것이다.
행동: 코드 저장 + 테스트 실행.
관찰: 테스트 결과.
해석: 빨간 줄이 나오면 어디서 나왔는지, 어떤 assertion 이 깨졌는지.
갱신: 그 부분을 수정한 다음 버전 작성.
다섯 부품이 얕지만 존재해요. 보통은 이 loop 를 몇 턴 안에 종결시키도록 설계돼 있습니다. 10턴 넘어가면 “사람이 봐야 한다” 쪽으로 경고가 떠요.
TODO.md 기반 재진입
더 큰 규모의 autoresearch 요소가 TODO 파일 기반 재진입 이에요. 여러 세션에 걸쳐서 TODO.md 나 비슷한 파일에 진행 상황을 적어 두고, 새 세션에서 그 파일을 읽으면서 “여기까지 됐고 다음은 이걸 해야지” 를 이어가는 구조입니다.
이건 한 세션 내 loop 가 아니라 여러 세션에 걸친 meta-loop 예요. 한 세션에서 얻은 실패와 부분 성공을 다음 세션이 읽고 출발점으로 씁니다. 단, 이때 TODO 파일에 “왜 그렇게 결정했는지” 맥락이 남아 있어야 다음 세션이 같은 실수를 안 해요. 그냥 할 일만 적혀 있으면 가설 업데이트가 안 된 retry 가 돼요.
prompt iteration
프롬프트 엔지니어링도 작은 autoresearch 입니다. “이 프롬프트가 원하는 출력을 낼까” 라는 가설로 시작해서, 실제 LLM 에 던져서 출력을 받고, 기대와 비교해서, 다음 프롬프트로 수정하는 과정. 이걸 수십 번 하면서 프롬프트를 다듬는 게 바로 autoresearch 의 수동 버전이에요.
자동화된 도구들이 이걸 점점 사람 대신 돌려 주려고 해요. 예를 들어 DSPy, PromptBreeder 같은 프레임워크들이 “프롬프트를 자동으로 탐색하는” 방향으로 나와 있습니다. 이건 섹션 6의 사례들과 같은 계보예요.
현재 수준
지금 우리가 쓰는 제품들 안에 들어간 autoresearch 요소는 miniature 입니다. Loop 가 얕고, 가설 업데이트가 단순하고, 종료 조건이 짧아요. 그래도 “loop 가 있다” 는 것만으로도 one-shot 에 비해 할 수 있는 게 훨씬 많아요. 다음 세대 제품들은 이 loop 를 더 깊게, 더 길게 돌리는 방향으로 가고 있습니다. 그게 M7 에서 얘기할 meta-harness 하고도 연결돼요.
9. Autoresearch 의 한계와 과장
Autoresearch 가 화제가 되면서 과장된 주장도 많이 돌아다녀요. 실무자로서 걸러야 할 지점을 정리합니다.
(a) 계산 비용 폭증
Autoresearch 의 가장 직접적인 한계는 비용 이에요. 수십 ~ 수천 번의 LLM 호출 + 실험 실행이 쌓이면 한 연구 세션이 수백 ~ 수만 달러에 이릅니다. Sakana AI 의 The AI Scientist 공식 문서에서도 한 논문 초안 생성에 상당한 비용이 든다고 언급돼 있어요.
이게 왜 문제냐면, 비용이 올라가면 실험을 자주 못 돌린다 는 거예요. 원래 연구는 싼 실험을 많이 돌려 보면서 가설을 세워야 하는데, 각 실험이 비싸지면 자기검증 빈도가 떨어져요. 아이러니하게도 “자동화로 더 많이 돌릴 수 있다” 는 약속과 반대 방향이에요.
(b) 창의적 가설은 여전히 사람이 씨앗 제공
현재의 autoresearch 시스템은 주어진 가설 공간 안에서 탐색을 잘 합니다. “이 파라미터 범위에서 최적을 찾아” 라든지 “이 함수 형태 중에서 좋은 것을 찾아” 같은 과제에서는 강해요. 하지만 완전히 새로운 가설 프레임 을 만드는 건 아직 어려워요.
FunSearch 도 “cap set 문제” 라는 정해진 문제 틀 안에서 움직였어요. The AI Scientist 도 주어진 ML 연구 템플릿 위에서 변형을 시도했습니다. 전혀 새로운 연구 분야를 여는 식의 창의성은 관찰되지 않았어요. 씨앗이 되는 문제 프레임은 여전히 사람이 심어 줘야 합니다.
이게 바뀔지 아닐지는 아직 모르는 일이에요. 하지만 현재 “AI 가 과학 전체를 자동화한다” 같은 주장은 과장이라고 보는 게 안전합니다.
(c) 종료 조건 없으면 발진
섹션 5 에서 얘기한 그대로예요. 종료 조건이 허술하면 autoresearch 는 비싸게 아무것도 못 얻고 끝납니다. 이건 한계라기보다 설계 책임 이에요. 자동화의 약속을 덜 깨려면 종료 조건을 처음부터 잘 박아야 해요.
(d) eval 품질이 천장
반복해서 말하지만 eval 이 천장입니다. Eval 이 noisy 하거나 편향돼 있으면 autoresearch 는 그 편향을 더 빠르게 파고듭니다. 사람이 손으로 실험할 때는 도중에 “아, 이건 측정이 이상하네” 라고 알아차릴 여지가 있지만, 자동화된 loop 는 그 자각이 없어요. 설계해 둔 eval 을 곧이곧대로 최적화합니다.
Eval 을 제대로 설계하지 못한 autoresearch 는 사람이 했을 때보다 더 나쁜 결과 를 낳을 수 있어요. 이 점은 Sakana AI 의 The AI Scientist 후속 논의에서도 인정된 부분이에요. “자체 peer review 가 충분히 엄격한가” 라는 질문이 계속 제기됩니다.
(e) 재현성과 검증 부담
Autoresearch 가 뱉은 결과를 사람이 검증해야 하는데, 그 검증 비용이 여전히 큽니다. 시스템이 10편의 논문 초안을 뽑으면 사람이 그걸 읽고 검증하는 시간이 필요해요. 검증까지 자동화하면 “누가 검증을 검증하나” 라는 무한 후퇴가 생겨요. 현재는 사람 검증이 병목이고, 이 병목이 autoresearch 의 실질적 처리량을 결정합니다.
과장을 걸러 내려면
뉴스에서 “AI 가 혼자 연구한다” 라는 헤드라인을 보면 다음 질문을 속으로 해 보세요.
- 가설 공간은 누가 정의했나?
- eval 함수는 뭔가? 검증 가능한가?
- 종료 조건은 뭔가? 비용 상한이 있나?
- 결과는 사람이 몇 명 검증했나?
이 네 질문에 대한 답이 명료하면 진지한 시스템이고, 답이 흐릿하면 과장이 섞여 있어요. 이 네 질문은 다음 편 M7 에서 meta-harness 의 설계 포인트로 다시 등장합니다.
10. Autoresearch 가 Meta-Harness 와 어떻게 다른가
M7 의 예고 차원에서 이 둘의 차이를 미리 짚어 둘게요.
Autoresearch = 탐색 loop 개선. 가설을 더 잘 만들고, 실험을 더 잘 돌리고, 결과를 더 잘 해석하고, 다음 가설로 더 똑똑하게 넘어가는 방향을 다룹니다. loop 자체 가 주인공이에요.
Meta-Harness = 그 loop 가 올라타는 땅을 바꾼다. Harness 는 agent 가 도구를 쓰고, 자원을 할당 받고, 안전하게 돌아갈 수 있게 해 주는 환경 이에요. Meta-harness 는 그 harness 자체를 개선하는 harness 예요. “자동차를 더 빨리 달리게 하는 엔진 튜닝” 이 autoresearch 라면, meta-harness 는 “그 자동차가 달릴 도로를 새로 까는 것” 에 가까워요.
구체적으로는 이런 것들이에요. 도구 API 를 자동으로 최적화하기, 권한 모델을 자동으로 조정하기, 비용 모델을 보고 자원 할당을 바꾸기, 다른 agent 를 자동으로 소환하고 관리하기. 이런 것들이 meta-harness 의 영역이에요.
Autoresearch 와 meta-harness 는 층위가 다릅니다. Autoresearch 는 실험실 안에서 연구원의 일을 개선하고, meta-harness 는 실험실 건물과 설비를 개선해요. 다음 편에서 이 비유를 길게 풀 거예요. 지금은 “층위가 다르다” 는 것만 기억해 두세요.
11. 실무자 체크리스트 — autoresearch 제품·논문을 볼 때
Autoresearch 라고 주장하는 제품이나 논문을 만나면 다음 6개 질문을 물어 보세요. 이 질문들에 얼마나 또렷하게 답할 수 있느냐가 그 시스템의 견고함을 꽤 정확하게 말해 줍니다.
1. 가설 표현 방식이 명시적인가? 시스템이 어떤 형태로 가설을 적고, 어떻게 읽는지. 자연어 프롬프트인지 structured config 인지. 로그를 봤을 때 “이 시도가 어떤 가설을 확인하려 했는지” 가 명료하게 추적 가능한가.
2. Eval 함수는 어떻게 생겼나? 뭘 측정하고, 노이즈는 얼마나 되고, 검증 가능한가. Eval 이 한 줄짜리 단순한 거라면 신뢰도를 내려 잡아야 해요. 여러 지표의 조합이면 더 믿을 만해요.
3. 종료 조건은 명문화돼 있나? Budget, iteration, convergence, failure cap, human checkpoint — 이 중 몇 가지가 결합돼 있나. 하나만 있으면 취약해요.
4. 실패가 어떻게 다음 턴에 반영되나? 그냥 retry 인지, 가설 업데이트가 있는지. 로그를 봤을 때 “이전 실패가 이 시도에 이렇게 영향을 줬다” 가 보이는가.
5. 계산 비용은 얼마고, 누가 감당하나? 한 실험 세션당 비용이 얼마인지, 그 비용이 사용자에게 전가되는 구조인지, 아니면 제품 공급자가 먹는지. 이게 제품의 지속 가능성을 결정해요.
6. 결과는 누가 검증하나? 시스템 자체인가, 사람인가, 둘의 조합인가. 자체 검증만 한다면 그 검증의 독립성을 어떻게 보장하는가.
이 6 개가 autoresearch 시스템의 “뼈대 점검표” 예요. 논문이든 제품이든 세일즈 피칭덱이든, 이 6 개에 답을 얻으려고 시도해 보시면 맥락이 확 잡힙니다.
닫는 한 문장
Autoresearch 는 AI 가 혼자 연구하는 마법 상자가 아니라, 가설·행동·관찰·해석·갱신 이 반복되는 구조가 시스템에 들어간 것이다. 이 구조가 잘 설계되면 사람보다 빠르게 탐색할 수 있고, 허술하면 비싸게 아무것도 못 얻는다. 오래 돌리는 기계가 아니라 실험이 반복되는 기계. 이 감각을 쥐고 뉴스를 보면 과장과 실체가 훨씬 또렷이 갈라져요.
다음 읽기
- M7 — Meta-Harness 가 loop 위의 땅을 바꾼다 [준비 중]
- M5 — Evaluation 이 agent 의 방향감각을 만든다 [완료]
- 시리즈 처음부터: P1 — LLM 이란 무엇인가 · P4 — Attention Is All You Need 해설 · M1 — Retrieval Layer 가 왜 필요한가
자주 묻는 질문 (FAQ)
Q1. Autoresearch 와 AutoML 은 같은 건가요?
다릅니다. AutoML 은 주어진 데이터셋에서 하이퍼파라미터와 모델 구조를 자동으로 탐색 하는 시스템이에요. 역사가 길고 (2013년 전후부터 본격화), 탐색 공간이 명확히 정의돼 있어요. Autoresearch 는 그보다 한 층 위예요. “무엇을 실험할지” 자체를 가설 형태로 세우는 단계가 포함돼요. AutoML 은 정해진 문제를 잘 푸는 거고, autoresearch 는 문제를 새로 꺼내는 것까지 일부 포함하는 개념입니다. 물론 현재 수준에서 autoresearch 의 “새 문제 꺼내기” 는 제한적이에요 (섹션 9 참조).
Q2. 우리 팀에서 autoresearch 시스템을 바로 도입할 수 있을까요?
먼저 eval 함수가 있는지부터 확인하시면 돼요. “우리 업무에서 좋은 결과와 나쁜 결과를 자동으로 구별할 함수가 있나” 가 질문이에요. 있으면 miniature autoresearch 부터 시작할 수 있어요. 예를 들어 “이 프롬프트가 다른 프롬프트보다 나은가” 를 자동으로 평가할 수 있으면 prompt iteration 형태로 autoresearch 를 붙일 수 있습니다. Eval 이 없으면 autoresearch 는 무조건 실패해요. Eval 을 먼저 만드는 게 순서입니다.
Q3. Autoresearch 가 사람 연구자를 대체하나요?
현재 수준에서는 대체가 아니라 확장 에 가까워요. 사람이 가설을 던지고, 시스템이 그 가설 주변을 빠르게 탐색하고, 사람이 결과를 해석해서 다음 가설을 던지는 식으로 섞여서 일하는 패턴이 가장 잘 돼요. Sakana AI 의 The AI Scientist 같은 풀 자동 시스템도 나오고 있지만, 결과물 품질이 아직 상위 저널 수준에 못 미칩니다. 10년 후는 다를 수 있겠지만, 2026년 기준에서는 “사람 + autoresearch” 가 “사람만” 보다 빠르고, “autoresearch 만” 은 “사람만” 에 못 미치는 영역이 많아요.
뉴스레터 구독 안내
매주 월요일, AI·LLM·에이전트 관련 실무 정리를 한 통씩 보내드립니다. 이런 기술 해설을 차분히 쌓아가고 싶으시면 구독해 주세요.
시리즈 안내 (20부작)
– P1 ~ P5: LLM 기본기
– M1: Retrieval Layer
– M2: Context Window
– M3: AI Agent 기본
– M4: Tool Use
– M5: Evaluation
– M6: Autoresearch (현재 글)
– M7: Meta-Harness [준비 중]
– M8 ~ M15: 응용 · 생태계
📚 전체 지도 보기
Autoresearch는 “오래 돌리는 기계”가 아니다. 가설·행동·관찰·해석·업데이트 5요소가 반복 구조로 들어간 설계 방향.
소스 리스트
- 태일러 지식백과사전 — AI 공부 지도 카테고리 (본 시리즈 20편 전체)
- AI 공부 지도 엔트리맵 — 전체 구조 + 3가지 독법
- “Attention Is All You Need” (Vaswani et al., 2017)
- Anthropic · OpenAI · Google 공식 docs
- mathbullet (YouTube) / Jay Alammar “Illustrated Transformer” / 3Blue1Brown 영상 — 쉬운 설명 레퍼런스
著者: 바이브코딩 태일러 (VibeCoding Tailor) — Lovable公式アンバサダー. AI·バイブコーディング専門メディアshuntailor.net運営.
本シリーズ “AI 공부 지도” 22편은 위키 자료와 공식 논문·공식 문서를 근거로 정리한 체계적 학습 커리큘럼입니다.
