autoresearch가 정말 보여주는 것: 생성이 아니라 평가의 미래

글을 읽기 전에 Gemini 나 GPT 를 통해 한번 autoresearch 에 대해 간략하게 설명을 들으면 더 쉽게 이해가 잘 됩니다.

최근 Karpathy 가 공개한 autoresearch 가 꽤 큰 주목을 끌고 있다. 이유는 단순하다. AI 에이전트가 코드를 직접 고치고, 짧은 실험을 반복하고, 결과가 좋아지면 그 변경을 남기고 아니면 버리는 저장소이기 때문이다.

이 설명만 들으면 많은 사람들은 곧바로 생성의 미래를 떠올린다. 드디어 AI 가 코드를 직접 고치고, 실험도 돌리고, 연구까지 대신하는 시대가 왔다는 식이다. 실제로 autoresearch 는 그런 인상을 주기에 충분하다. 에이전트가 모델 학습 코드를 수정하고, 정해진 시간 동안 실험을 돌리고, 결과가 나아졌는지 확인한 뒤, 더 나아지면 남기고 아니면 버린다.

하지만 이 프로젝트의 더 중요한 의미는 생성이 아닌 평가 쪽에 있다. 핵심은 AI 가 파이썬 코드를 쓴다는 사실 자체가 아니다. 더 중요한 것은 이 저장소가 연구라는 활동을 아주 작은 폐쇄 루프로 바꿔놓았다는 점이다. 무엇을 바꿀 수 있는지, 무엇으로 실패를 판단하는지, 어떤 결과만 살아남는지를 먼저 고정해두면 연구와 개발은 하나의 자동화 가능한 탐색 문제로 다시 보이기 시작한다. autoresearch 는 바로 그 점을 보여주는 작은 원형이다.

autoresearch 는 실제로 무엇을 하는가

이 점은 저장소의 구조를 보면 더 분명해진다. 이 프로젝트에서 사실상 중요한 파일은 셋이다.

• prepare.py — 바뀌지 않는 환경이다. 데이터 다운로드, 토크나이저 준비, 데이터 로드, 평가 로직이 포함되어 있다. 특히 학습 시간은 5분으로 고정되어 있고, 평가는 val_bpb 라는 단일 지표로 이루어진다. 여기서는 무엇을 어떻게 실험하든 평가 환경 자체는 흔들리지 않는다.
• train.py — 반대로 에이전트가 실제로 손댈 수 있는 탐색 공간이다. 모델 구조, optimizer, 학습 루프가 모두 여기에 있다.
• program.md — 가장 흥미로운 파일이다. 이 문서는 단순한 설명문이 아니다. 에이전트에게 어떻게 브랜치를 만들고, 기준 성능을 잡고, 실험을 반복하고, 결과를 읽고, keep/discard 를 결정할지까지 알려주는 일종의 메타프로그램이다.

이 구조를 보고 나면, 이 리포지토리의 중심이 어디에 있는지 조금 다르게 보인다. 많은 사람들은 train.py 를 중심으로 보겠지만 사실 이 저장소의 무게중심은 program.md 쪽에 더 가깝다. 인간은 더 이상 직접 모델 코드를 고치는 존재가 아니라, 어떤 탐색이 허용되는지, 어떤 결과를 성공으로 인정할지, 어떤 파일을 건드리면 안 되는지, 실패를 어떻게 처리할지 정하는 존재로 올라간다. 다시 말해 구현의 중심이 코드에서 규칙으로, 함수에서 절차로 이동한다.

이때 LLM 이 실제로 하는 일도 조금 더 정확하게 이해할 수 있다. 이 프로젝트에서 LLM 은 마법처럼 연구를 “이해” 해서 혁신을 만들어내는 존재로 등장하지 않는다. LLM 은 가설을 하나 제안하고, train.py 를 수정하고, 실험을 한 번 돌리고, val_bpb 와 메모리 사용량을 확인한 뒤, 좋아지면 채택하고 아니면 버리는 반복 루프 안에서 일한다. 여기에 git 브랜치와 커밋, 그리고 result.tsv 같은 기록 장치가 붙으면서, 이 루프는 인간 연구자의 머릿속에서만 굴러가던 비공식적인 습관이 아니라 기계가 실행할 수 있는 절차가 된다.

그래서 이 프로젝트에서 자동화된 것은 흔히 상상하는 종류의 “지능” 이라기보다는 연구의 작업 흐름 자체다. 더 정확히 말하면, 가설 생성 → 코드 수정 → 짧은 실험 → 단일 지표 평가 → keep/discard 라는 연구자의 암묵적 루틴이 외부화되고 기계화된 것이다. 이게 중요한 이유는, 우리가 원래부터 하고 있던 개발과 연구가 사실 비슷한 구조를 갖고 있었기 때문이다.

생성이 아니라 평가가 중요한 이유

기존의 소프트웨어 개발도 본질적으로는 늘 이런 식이었다. 목표가 있었고, 후보 해법이 있었고, 테스트나 지표가 있었고, 더 나아진 쪽을 채택했다. 차이가 있다면 인간은 이 탐색을 아주 저대역폭으로 수행했다는 점이다. 우리는 머릿속에서 동시에 몇 개 안 되는 가설만 붙들 수 있고, 코드의 변화들이 서로 어떤 상호작용을 일으킬지 고차원적으로 계속 추적하기 어렵다.

조금 과장해서 말하면, 인간은 본질적으로 희소하게 사고한다. 한 번에 몇 줄, 몇 개념, 몇 개의 선택지만 다룬다. 반면 이런 시스템은 그 탐색을 훨씬 더 촘촘하게 밀어붙일 수 있다. 인간이 직접 해답을 하나씩 만들어내는 대신, 기계가 훨씬 더 많은 후보를 생성하고 시험하면서 탐색 자체를 감당하게 되는 것이다.

이쯤 되면 질문은 자연스럽게 바뀐다.

미래의 좋은 개발자(굳이 개발자로 한정 지을 필요는 없다)는 코드를 잘 쓰는 사람일까, 아니면 무엇을 좋은 답으로 인정할지 잘 설계하는 사람일까?

나는 점점 후자에 가까워질 것이라고 본다. 생성은 점점 더 풍부해질 것이다. 코드 초안을 만들고, 대안을 제안하고, 수정안을 비교하는 일은 점점 더 싼 비용으로 가능해질 가능성이 크다. 그럴수록 오히려 희소해지는 것은 무엇을 최적화할 것인가, 무엇을 절대 넘어가면 안 되는가, 어떤 신호를 신뢰할 것인가 를 정하는 능력이다.

인간의 역할은 어디로 이동하는가

이런 의미에서 앞으로의 핵심 역량은 code writer 보다 evaluator designer 로 이동할 가능성이 크다고 본다. 즉, 평가 체계를 설계하는 사람에 가까워질 수도 있다고 본다. 나는 본질적으로 harness engineering 도 LLM 에게 평가 가능한 지표를 주는 evaluation engine 을 구축하는 과정이라고 본다.

평가 체계를 설계하는 사람은 단순히 점수 함수 하나를 적는 사람이 아니다.

• 어떤 평가 지표는 빠른 탐색용으로 쓰고, 어떤 평가 지표는 절대 넘으면 안 되는 경계로 둘지 정한다.
• 시스템이 평가 지표를 진짜로 개선하고 있는지, 아니면 단지 평가 지표를 속이는 방향으로 움직이고 있는지를 감시한다.
• 단순히 코드가 작동하는가를 넘어, 시스템이 의도치 않은 편법으로 평가 지표만 달성하지는 않는지도 방어해야 한다.
• 무엇을 바꾸게 허용할지, 무엇은 고정할지, 어떤 실패는 허용 가능하고 어떤 실패는 치명적인지 설계한다.

지금은 이 일을 암묵적으로 해오거나 실력이 뛰어난 시니어 엔지니어들이 주로 했었지만, 앞으로는 이 능력이 점점 더 직접적인 개발 실력으로 드러날 가능성이 높다고 본다.

바로 이 지점에서 autoresearch 의 장점과 한계가 동시에 드러난다. 이 프로젝트가 자동화될 수 있는 이유는 평가기가 아주 좁고 단단하기 때문이다. 5분이라는 고정된 시간 예산이 있고, val_bpb 라는 명확한 지표가 있으며, 그 결과에 따라 keep/discard 를 결정하는 규칙이 있다. 덕분에 루프는 닫히고, 에이전트는 쉬지 않고 실험을 반복할 수 있다.

하지만 동시에 좋은 연구가 단일 숫자로 심하게 압축된다. 실제로 중요한 가치들 — 예를 들어 단순성, 일반화 가능성, 향후 확장성, 인간에게 설명 가능한 구조 같은 것 — 은 그 숫자 하나에 모두 담기지 않는다.

그래서 미래의 더 좋은 체계는 아마도 하나의 점수만 최적화하는 구조가 아닌, 여러 평가기가 서로 견제하는 구조가 아닐까 싶다. Karpathy 의 Agent 용 git 을 보지는 못했지만 이러한 구조가 아닐까 싶다.

결국 누가 기준을 정하는가

그렇다면 최종 결정권은 누구에게 남을까. 나는 당분간, 그리고 꽤 오랫동안 인간에게 남을 가능성이 높다고 본다. 그 이유가 인간이 더 똑똑해서는 아니다. 지금의 AI 는 법적 주체도 아니고, 권리의 주체도 아니고, 수요를 스스로 형성하는 존재도 아니다. 결국 결과물을 소비하고, 비용을 지불하고, 제도를 유지하고, 실패의 책임을 지는 것은 인간과 인간 조직이다. 그래서 어떤 시스템이 유지될 가치가 있는지는 인간의 입맛(취향), 인간의 시장, 인간의 책임 구조를 통과해야 한다. AI 가 아무리 많은 후보를 만들어도, 어떤 것이 살아남을지는 아직 인간의 평가 체계에 묶여 있다.

이런 의미에서 autoresearch 는 단지 LLM 이 코드를 수정하는 흥미로운 장난감이 아니다. 더 깊게 보면, 이 저장소는 개발과 연구가 원래부터 탐색 문제였다는 사실을 노출시킨다. 우리가 여태 답을 직접 만들어온 이유는 그것이 언제나 본질이어서가 아니다. 그 탐색 과정을 외부화하고 자동화할 만큼 좋은 도구가 그동안 없었기 때문이다. 이제 그 루프를 기계가 실행할 수 있게 되기 시작했다면, 인간의 역할도 함께 이동할 수밖에 없다.

앞으로 더 중요한 사람은 가장 빨리 답을 만드는 사람이 아닐 수 있다. 오히려 더 중요한 사람은 어떤 탐색 공간을 열어둘지, 어떤 평가 함수를 둘지, 어떤 평가 지표를 믿고 어떤 평가 지표는 믿지 않을지, 어떤 신호를 대리 변수로 사용할지 설계하는 사람일 가능성이 크다. 다시 말해, 답을 만드는 일에서 기준을 설계하는 일로의 이동이 이미 시작되고 있다.

autoresearch 는 미래를 과장해 말하지 않는다. 대신 앞으로 무엇이 살아남을 답인지, 누가, 어떤 기준으로 결정하게 될지를 아주 작고 선명한 형태로 먼저 드러낸다.

마치며

소프트웨어 엔지니어의 입장에서 글을 대부분 작성했지만 본질적으로는 어떠한 업무든 비슷한 흐름으로 가고 있다고 본다. 대부분이 코드를 작성해서 답을 만들어내는 일이 소프트웨어의 본질이라고 믿었지만 추상적으로 바라보면 소프트웨어도 하나의 기능적 함수이다.

즉, 개발자든 아니든 문제를 이해하고, 문제를 해결하기 위해 문제를 최대한 작은 단위로 쪼개어, 작은 단위의 함수의 인풋 / 아웃풋을 설계하고, 닫힌 루프 내에서 평가 지표를 만들고 탐색 공간을 열어주는 이런 것들이 문제를 해결하는 것 자체의 본질일 수 있다. 이 과정에서 답을 우리가 만들어냈던 이유는 그만한 도구가 없었기 때문이다.

닫힌 루프를 만드는 과정에서 본인의 엔지니어링 실력(Computer Science, Math, etc) 과 같은 자질들이 큰 역할을 할 거라고 본다. 다른 의견도 많을 거라고 보지만, 난 명확하게 더 이상 개발자가 코드를 치는 미래는 없을 거라고 본다.

---

참고

• Andrej Karpathy, autoresearch — https://github.com/karpathy/autoresearch
• OpenAI, harness engineering — https://openai.com/index/harness-engineering/