Ralphthon@ICML 우승팀의 Research Agent Harness 설계

연구 주제를 정하고, 코드를 구현하고, 실험 결과를 해석해 논문까지 완성하는 데 주어진 시간은 단 3시간이었습니다. 그리고 이 모든 과정의 주체는 사람이 아니라 AI 에이전트였습니다.

저희가 가장 먼저 한 일은 구체적인 실험 계획을 세우는 것이 아니었습니다. 대신 다음 질문에 답하는 데 준비 시간의 상당 부분을 사용했습니다.

좋은 논문은 어떤 모습이어야 하는가?

이 글에서는 Ralphthon@ICML에서 저희가 사용한 Research Agent Harness의 설계 원칙과 운영 방식, 그리고 대회를 통해 얻은 교훈을 소개합니다. 에이전트가 실제로 어떤 가설을 세우고, 실험 결과에 따라 연구 방향을 어떻게 바꾸었는지는 후속 글에서 자세히 다룰 예정입니다.

AI 에이전트가 혼자 3시간 동안 논문을 쓰는 해커톤

Ralphthon은 사람이 아닌 AI 에이전트가 연구를 수행하는 독특한 해커톤입니다.

Ralphthon@ICML에서 참가자는 먼저 1시간 30분 동안 Research Agent를 준비합니다. 이후 Ralph Loop가 시작되면 에이전트가 3시간 동안 주제 선정부터 구현, 실험, 결과 분석, 논문 작성까지 자율적으로 진행합니다.

사람의 개입도 허용되지만 조건이 하나 있습니다. 에이전트에게 직접 지시하려면 행사에서 제공하는 우스꽝스러운 가재 의상을 입어야 합니다.

저희 Team WooandB는 KAIST 신진우 교수님 연구실 소속 박사과정 학생인 송우민과 윤병준으로 구성되어 있습니다. 저희는 감사하게도, 이번 Ralphthon@ICML AI Scientist 트랙에서 1위를 수상했습니다!

저희 에이전트가 완성한 연구는 Transformer의 깊이를 하나의 최적화 궤적으로 보고, 생략된 레이어의 residual update를 이전 레이어의 update로 예측하는 Depth-AR였습니다. 별도의 학습 없이 layer skipping 과정에서 사라진 정보를 일부 복원할 수 있는지를 실험하는 주제였습니다.

흥미롭게도 이 주제는 대회 전에 준비해 간 아이디어가 아니었습니다.

첫 번째 질문에서 연구 주제를 정하다

대회가 시작되자 개인 ChatGPT 계정에 다음과 같이 질문했습니다.

해커톤에서 3시간만에 ML 분야 논문을 써야돼. 아이디어부터 실험까지 다 해야 하는데, 어떤 주제가 좋을까? novelty가 있는 주제가 필요하면서, 빠르게 실험 iteration을 돌릴 수 있어야 해

조건은 단순했습니다.

1. 기존 연구를 조금 변형하는 수준이 아니라 명확한 novelty가 있어야 한다.
2. 3시간 안에 여러 차례 실험하고 방향을 수정할 수 있을 만큼 실험이 빨라야 한다.

개인 ChatGPT 계정의 메모리에는 평소 저희 연구와 관련해 나누었던 여러 아이디어와 문제의식이 남아 있었습니다. 해커톤을 위해 미리 논의했던 내용은 아니었습니다. ChatGPT는 기존의 서로 다른 연구 맥락을 조합해 Depth-AR라는 새로운 아이디어를 제안했고, 저희는 첫 번째 답변에서 나온 주제를 그대로 선택했습니다.

이 과정에서 중요했던 것은 길고 자세한 배경 설명이 아니었습니다. 해커톤에 적합한 주제가 충족해야 할 조건을 구체적으로 전달한 것이었습니다.

이후 에이전트 시스템을 설계할 때도 같은 원칙을 적용했습니다. 연구 과정을 하나하나 지시하기보다, 최종 결과물이 만족해야 할 기준을 먼저 분명하게 만들었습니다.

핵심 설계: 실험보다 논문을 먼저 만든다

저희 하네스의 가장 중요한 설계 원칙은 Writing First였습니다.

아이디어를 받은 뒤 가장 먼저 떠올리기 쉬운 접근은 다음과 같습니다.

아이디어 → 구현 → 실험 → 결과 분석 → 논문 작성

저희는 이 순서를 다음과 같이 바꾸었습니다.

아이디어 → 제출 가능한 논문 초안 → 필요한 실험 정의 → 실험 → 논문 수정

실험을 모두 끝낸 뒤 논문을 쓰는 것이 아니라, 연구를 시작하자마자 완성된 형태에 가까운 논문을 먼저 만들도록 했습니다.

실험 결과가 없는데 어떻게 논문을 쓰는가

연구 주제가 정해지면 에이전트는 먼저 다음 내용을 구성했습니다.

• 논문의 핵심 주장
• 주장을 뒷받침하기 위해 필요한 실험
• 각 표와 그림이 답해야 할 질문
• 예상되는 결과와 그에 따른 스토리라인
• 결과가 예상과 다를 경우 사용할 수 있는 대안적 해석

아직 실행하지 않은 실험의 수치는 placeholder로 채웠습니다. 단, 에이전트가 이를 실제 결과로 오인하지 않도록 소스 코드 안에서 명확하게 표시했습니다. 논문을 제출하기 전에는 모든 placeholder를 실제 실험 결과로 교체해야 한다는 규칙도 함께 제공했습니다.

맥락 없이 들으면 “결과가 나오기 전에 논문을 쓴다”는 말은 결과 조작처럼 들립니다. 실제로는 정반대로, 검증이 강제되는 write-ahead log에 가깝습니다. 실행 중 에이전트는 이를 두 개의 LaTeX 매크로로 나누었고, 두 매크로는 정반대의 규칙을 따릅니다. \ph{}는 아직 측정되지 않은 값으로, 실제 측정값으로 교체되지 않으면 그 문장 자체를 삭제해야 합니다. \phm{}는 결과 파일이 뒷받침하는 값으로, 임의로 지우면 참인 주장을 없애는 셈이 됩니다. ralph/PH-LEDGER.md는 논문 속 모든 임시 수치를 그것이 기다리는 JSON 키에 일대일로 연결하고, verify-phm.py와 writing-audit.sh는 지어낸 값이 하나라도 제출본까지 살아남으면 빌드를 실패시킵니다. 지어낸 값은 실릴 수 없고, 측정된 값은 조용히 사라질 수 없습니다.

이 방식에는 두 가지 장점이 있었습니다.

첫째, 실험의 목적이 구체적으로 정해졌습니다.

에이전트는 막연히 “성능을 확인해 보자”라고 생각하는 대신, 논문 속 특정 표의 특정 칸을 채우기 위해 어떤 실험을 해야 하는지 알 수 있었습니다.

둘째, 결과가 예상과 달랐을 때 연구 방향을 빠르게 바꿀 수 있었습니다.

결과가 예상과 일치하면 placeholder를 실제 값으로 교체했습니다. 반대로 결과가 기존 가설과 충돌하면 논문의 주장과 스토리라인을 먼저 수정한 뒤, 새로운 스토리라인을 검증하기 위한 후속 실험을 설계했습니다.

3시간 동안 논문의 중심 스토리는 최소 여섯 차례 바뀌었습니다. 모든 변경은 그것을 강제한 근거와 함께 ralph/DECISIONS.md에 기록되어 있습니다. 마지막 재구성에는 말 그대로 storyline v6라는 이름이 붙어 있습니다.

실험을 모두 마친 뒤 글을 쓰는 대신, 글을 계속 고치면서 실험 전략을 결정했습니다.

좋은 논문의 기준부터 정하다

대회에서는 에이전트를 준비할 수 있는 시간이 1시간 30분 주어졌습니다. 저희는 그중 30분 이상을 글쓰기 지침을 작성하는 데 사용했습니다.

이 문서에는 Depth-AR에 특화된 실험 계획이나 모델 설정이 들어 있지 않았습니다. 특정 프로젝트에만 적용되는 계획 대신, 어떤 연구 주제에도 적용할 수 있는 논문 작성 원칙을 정리했습니다. 예를 들어, 다음과 같은 내용이 포함되었습니다.

• 논문은 하나의 구체적인 연구 질문에 집중할 것
• 모든 실험은 본문의 주장과 직접 연결될 것
• 표와 그림마다 독자가 가져가야 할 핵심 메시지가 분명할 것
• 결과를 나열하는 데 그치지 않고, 결과가 의미하는 바를 설명할 것
• 예상과 다른 결과가 나오면 숨기지 않고, 그 결과를 설명할 수 있는 새로운 스토리라인을 찾을 것
• 어느 시점에 열어 보더라도 제출 가능한 형태를 유지할 것
• 강한 결과를 부록에 숨기지 않고 본문에서 충분히 강조할 것

이 두 문서는 저장소에 그대로 공개되어 있고, 둘 다 특정 주제에 종속되지 않습니다. Depth-AR이라는 단어는 어디에도 등장하지 않습니다. writing-guidelines.md는 과정을 정의합니다. 무엇을 어떤 순서로 쓸 것인지, 그리고 “제출 가능한 상태”가 구체적으로 무엇을 뜻하는지를 체크리스트로 못 박습니다. 첫 번째 규칙 한 줄이 사실상 하네스 전체를 요약합니다 — “논문은 모든 시점에 제출 가능해야 한다. ‘완성’이 아니라 ‘제출 가능’이다.” writing-style-guide.md는 형식을 정의합니다. 섹션별 페이지 예산, 모든 캡션이 따라야 하는 두 부분 구조, 그리고 어떤 주장도 숫자 없이는 실릴 수 없다는 규칙이 들어 있습니다.

이 지침을 연구 주제를 제안했던 ChatGPT 세션에 다시 입력했습니다. ChatGPT는 일반적인 글쓰기 원칙을 현재 연구 주제에 맞는 구체적인 연구 및 집필 계획으로 바꾸었습니다.

저희는 이렇게 만들어진 계획을 자율 에이전트의 초기 지침으로 전달했습니다 — DEPTH-AR-PLAN.md입니다. 이 계획에서 가장 큰 역할을 한 부분은 미리 정해 둔 pivot이었습니다. 핵심 가설이 완전히 무너지는 경우까지 포함해, 모든 결과 시나리오에 대해 논문의 스토리라인을 미리 써 둔 것입니다. 실제로 실행 14분 만에 측정된 효과가 가설과 정반대 방향(anti-momentum)으로 나오며 가설이 무너졌을 때, 에이전트는 이 실망스러운 숫자가 무슨 의미인지 즉석에서 고민할 필요가 없었습니다. 계획이 이미 정해 두었기 때문입니다.

정리하면, 사람이 좋은 결과물의 기준을 정하고 모델이 그 기준을 현재 연구 주제에 맞는 실행 계획으로 구체화한 것입니다.

네 개의 에이전트로 역할을 나누다

Writing First 연구 루프를 유지하면서 구현, 실험, 집필을 병렬로 진행하기 위해 네 개의 에이전트를 구성했습니다.

표의 역할 이름은 실제 페르소나 파일로 연결됩니다. 이 파일들이 곧 하네스이며, 한자리에서 다 읽을 수 있을 만큼 짧습니다. (정확히는 세 개입니다. Monitoring 역할은 별도의 페르소나 파일이 아니라 watcher 프로세스와 10분 주기 rethink loop로 구현되었습니다.)

그리고 세 파일 아래에는 어떤 프롬프트 문구보다 큰 역할을 한 규칙이 하나 있었습니다. 에이전트 경계를 넘는 모든 것은 대화가 아니라 디스크 위의 파일이어야 한다. Writing Agent는 숫자를 결과 JSON에서 직접 읽습니다. 대화를 통해 전달된 숫자는 정의상 오염된 값으로 취급했습니다.

역할을 나눈 목적은 단순히 더 많은 에이전트를 사용하는 것이 아니었습니다.

하나의 에이전트가 코드를 구현하다가 디버깅에 깊이 빠지면 논문 작성은 오랫동안 멈출 수 있습니다. 반대로 논문의 문장을 다듬는 데 집중하면 GPU가 사용되지 않은 채 방치될 수 있습니다.

역할별 에이전트를 두면 Experiment Agent가 실험하는 동안 Writing Agent는 논문을 계속 정리할 수 있습니다. 각 에이전트가 다뤄야 하는 맥락도 줄어듭니다. Experiment Agent는 코드와 실험 로그에 집중하고, Writing Agent는 주장과 표, 문장 사이의 일관성에 집중할 수 있습니다.

각 에이전트의 역할을 정의한 지침은 위 표의 내용과 크게 다르지 않을 정도로 간단했습니다.

추가로 Anthropic의 멀티 에이전트 시스템 관련 블로그 글을 Main Agent에 참고 자료로 제공했습니다. 준비 시간이 부족해 저희가 직접 글을 읽고 세부 내용을 설계에 반영하지는 않았습니다. 대신 링크만 전달하고, 에이전트가 현재 작업에 적용할 만한 내용을 직접 판단하도록 했습니다.

실제로 사람이 제공한 것은 많지 않았다

초기 설정에서 저희가 직접 준비한 것은 다음 정도였습니다.

• 좋은 연구 논문의 기준을 담은 글쓰기 지침 — writing-guidelines.md, writing-style-guide.md
• Main, Experiment, Writing, Monitoring으로 구성된 에이전트 구조 — master.md, experiment.md, writing.md
• 연구 주제에 맞게 변환된 집필 및 실험 계획 — DEPTH-AR-PLAN.md
• GPU 실험 환경을 구성하기 위한 setup skill
• Git을 통한 논문 문서 작성 프로그램 Overleaf 연결
• herdr 기반 소통 스킬 — 에이전트들이 작업 상태와 결과를 주고받는 통로

그 밖의 세부 작업 계획과 문서, 코드, 실험 스크립트, 논문 초안은 대부분 에이전트가 직접 작성했습니다. 하네스 저장소에서 README를 제외한 모든 파일은 에이전트가 직접 쓴 것입니다.

에이전트의 로그 대신 논문을 읽었다

Ralph Loop가 시작되고 한 시간이 조금 지났을 때였습니다. 그동안 저희는 점심을 먹고 있었습니다.

돌아와 Overleaf를 열어 보니 이미 기본적인 논문이 완성되어 있었습니다. 연구 질문과 방법이 정리되어 있었고, 실제 실험 결과도 표에 들어가 있었습니다. 그대로 제출해도 하나의 연구 결과물로는 성립할 만한 상태였습니다.

하지만 더 개선할 수 있는 부분이 보였습니다.

이때 저희는 수많은 에이전트 로그를 따라가며 어떤 명령을 실행했는지 확인하지 않았습니다. 대신 에이전트가 작성한 최신 버전의 논문을 직접 읽었습니다. Writing First 설계 덕분에 에이전트가 현재까지 내린 판단과 연구의 진행 상황이 논문이라는 하나의 결과물에 모여 있었기 때문입니다.

저희가 전달한 피드백은 다음과 같이 논문의 방향과 연구 우선순위에 관한 내용이었습니다.

GPU가 충분히 사용되지 않고 있다. 남은 시간 동안 병렬 실험을 더 실행하자.

작동하지 않는 조건을 나열하는 데 집중하기보다, 어떤 조건에서 의미 있는 이득이 나타나는지를 중심으로 논문을 다시 구성하자.

가장 강한 결과가 부록에만 있다. 핵심 표를 본문으로 옮기자.

현재 실험 결과를 하나로 묶어 줄 더 분명한 중심 메시지가 필요하다.

지도교수가 학생의 모든 코드와 실험 명령을 직접 확인하기보다, 논문과 결과를 읽고 다음 연구 방향에 대해 의견을 주는 방식과 비슷했습니다.

논문의 큰 방향에 대한 몇 차례의 피드백만으로도 에이전트는 실험 우선순위를 바꾸고 중심 주장을 크게 개선했습니다.

Takeaway 1. 좋은 목표를 먼저 정의하라

최종 목표는 연구를 수행하는 것 자체가 아니라, 좋은 논문을 완성하는 것이었습니다.

그래서 저희는 에이전트가 연구를 어떻게 해야 하는지 세세하게 규정하기보다, 좋은 논문이 어떤 조건을 충족해야 하는지 정하는 데 시간을 사용했습니다.

연구 주제를 정할 때도 마찬가지였습니다. 단순히 “새로운 주제를 찾아 달라”고 요청하지 않았습니다. novelty가 있어야 하고, 실험이 빨라야 하며, 3시간 안에 여러 차례 iteration을 돌릴 수 있어야 한다는 조건을 함께 전달했습니다.

에이전트에 모호한 목표를 주면 그 모호함은 긴 작업 과정 전체로 퍼집니다. 반대로 원하는 최종 상태가 구체적이면, 에이전트는 그 상태에 도달하기 위한 중간 단계를 비교적 잘 찾아냅니다.

좋은 하네스를 만들려면 먼저 원하는 결과물이 어떤 모습이어야 하는지 설명할 수 있어야 합니다.

Takeaway 2. 장시간 실행되는 에이전트에는 앵커가 필요하다

Research Agent는 쉽게 세부적인 문제에 사로잡힙니다.

코드의 특정 부분을 수정하다가 관련 구현을 계속 따라가거나, 논문의 핵심 주장과 큰 관련이 없는 작은 실험을 반복할 수 있습니다. 작업 시간이 길어지면 현재의 우선순위와 처음 세웠던 목표를 놓치기도 합니다.

컨텍스트 압축이 발생하면 상황은 더 어려워집니다. 이전에 어떤 판단을 내렸는지, 왜 현재 실험을 하고 있었는지에 대한 세부 정보가 사라질 수 있기 때문입니다.

따라서 장시간 실행되는 에이전트에는 주기적으로 전체 작업을 다시 바라보게 하는 앵커링(anchoring) 장치가 필요합니다.

저희 시스템에서는 논문이 앵커 역할을 했습니다.

새로운 실험 결과가 나오면 에이전트는 그 결과가 논문의 어느 주장과 연결되는지 확인해야 했습니다. 결과를 논문에 반영하는 과정에서 자연스럽게 다음 질문을 다시 검토하게 됩니다.

• 이 결과는 현재의 중심 주장을 지지하는가?
• 기존 표의 어떤 값을 바꿔야 하는가?
• 예상과 다르다면 스토리라인을 어떻게 수정해야 하는가?
• 논문을 완성하려면 다음으로 어떤 실험이 가장 필요한가?

논문을 항상 제출 가능한 상태로 유지한다는 규칙이 에이전트로 하여금 반복적으로 큰 그림을 확인하게 만들었습니다.

사람 역시 중요하지 않은 세부 사항에 몰두하다가 연구의 중심 질문을 놓칠 수 있습니다. 논문 초안이나 연구 노트가 사람에게 앵커가 되는 것처럼, 장시간 실행되는 에이전트에도 현재 작업과 최종 목표를 연결하는 외부 결과물이 필요합니다.

Takeaway 3. 하네스는 실제 사용 경험을 반영하며 발전해야 한다

대회 중 저희가 전달한 피드백 중 일부는 사실 처음부터 지침에 포함할 수 있는 내용이었습니다.

예를 들면 다음과 같습니다.

• GPU가 유휴 상태가 되지 않는지 주기적으로 확인할 것
• 남은 시간과 사용 가능한 자원에 맞춰 실험 규모를 조절할 것
• 부정적인 결과만 나열하지 말고, 관찰된 긍정적인 패턴을 중심으로 건설적인 스토리라인을 만들 것
• 가장 강한 실험 결과가 본문에 포함되어 있는지 확인할 것
• 제출 전에 표, 본문, 부록의 수치가 서로 일치하는지 검사할 것

이러한 내용은 에이전트가 실행된 뒤에야 저희가 떠올렸을 뿐, 실행 중에만 전달할 수 있는 정보는 아니었습니다.

사실 이 과정의 일부는 실행 중에 이미 일어났습니다. 페르소나 파일들은 단순한 역할 설명으로 시작했지만, 실행이 끝날 무렵에는 번호가 매겨진 규칙 11개가 덧붙어 있었습니다. 결과를 흐리는 표현 금지, dtype을 고려한 오차 허용 범위, 직접 눈으로 확인하지 않은 그림은 논문에 넣지 않는다는 시각 검증 게이트, 그리고 값이 아니라 키로 인용하라(cite by identity, never by value) 같은 규칙들입니다. 모두 문제가 실제로 드러난 순간에 그 자리에서 작성된 것입니다. master.md의 규칙 절과, 그 규칙을 만들어 낸 ralph/DECISIONS.md 속 사건들을 나란히 놓고 읽어 보면, 하네스가 스스로 학습해 가는 과정이 가장 선명하게 드러납니다.

다음 실행에서는 나머지 피드백도 초기 지침이나 자동 점검 항목에 추가할 수 있습니다. 그러면 같은 문제에 사람이 다시 개입할 필요가 줄어듭니다. 이후 새로운 실패 사례가 발견되면 그 내용도 다시 하네스에 반영할 수 있습니다.

앞으로 실행 기록과 사람의 피드백이 쌓이면, 자주 반복되는 개입을 새로운 규칙이나 자동 점검 절차로 바꿀 수 있습니다. 실제 사용 과정에서 발견한 문제를 다음 버전에 반영하면서 하네스 자체를 계속 다듬어 나갈 수 있는 것입니다.

결국 하네스는 한 번 작성하고 끝나는 프롬프트가 아니라, 사용할수록 발전하는 시스템이어야 합니다.

Takeaway 4. 완전 자율 연구도 가능하다. 하지만 지금은 Co-Scientist가 더 강하다

이번 경험만으로 에이전트가 독립적으로 새로운 과학적 발견을 수행할 수 있다고 주장할 수는 없습니다. Ralphthon은 시간과 자원, 결과물의 형식이 분명하게 제한된 환경이었습니다.

그럼에도 주제 선정, 구현, 실험, 결과 해석, 논문 작성으로 이어지는 end-to-end 연구 루프가 실제로 작동한다는 점은 확인할 수 있었습니다.

사람이 점심을 먹는 동안에도 에이전트는 실험을 실행하고 논문을 수정해 심사 가능한 결과물을 만들었습니다.

다만 가장 좋은 결과는 완전 자율 실행만으로 나오지 않았습니다.

사람은 다음과 같은 판단에서 여전히 큰 가치를 제공했습니다.

• 어떤 결과를 논문의 중심에 배치해야 하는가
• 남은 시간 동안 어떤 실험을 추가로 진행해야 하는가
• 현재 결과를 가장 설득력 있게 설명하는 관점은 무엇인가
• 기술적으로 맞는 논문과 읽고 싶어지는 논문의 차이는 무엇인가

반대로 사람이 모든 코드와 실행 로그를 직접 감독할 필요도 없었습니다. 에이전트가 작성한 논문을 읽고, 연구의 우선순위와 방향을 조정하는 것만으로도 결과를 크게 개선할 수 있었습니다.

적어도 현재로서는 Research Agent를 연구자의 완전한 대체재로 활용하기보다, 빠르게 구현하고 실험하며 논문을 수정하는 Co-Scientist로 활용하는 방식이 더 강력하다고 생각합니다.

마치며

Ralphthon은 Research Agent가 어디까지 연구를 수행할 수 있는지 짧은 시간 안에 직접 확인할 수 있었던 즐거운 경험이었습니다.

행사를 준비해 주신 Team Attention과 모든 운영진, 그리고 OpenAI, Weights & Biases, VESSL AI, DALPHA, NAVER D2SF를 비롯한 스폰서 여러분께 감사드립니다.

저희는 모든 것을 공개했습니다. 전체 하네스와 함께, 논문과 그 전체 리서치 트레이스까지 — 의사결정 원장, 모든 결과 파일, 그리고 에이전트가 직접 남긴 커밋 히스토리를 민감 정보만 제거한 뒤 그대로 공개했습니다.

후속 글에서는 에이전트가 실제로 어떤 가설을 세웠는지, 실패한 실험 결과를 어떻게 해석했는지, 그리고 3시간 동안 논문의 스토리라인을 어떻게 바꾸어 갔는지를 자세히 소개하겠습니다.

앞으로도 자율 연구 에이전트와 Co-Scientist 시스템을 계속 개발하고 공개할 예정이니, 많은 관심 부탁드립니다!