Autoresearch는 AI 에이전트가 제한된 훈련 코드를 수정하고, 정해진 시간 동안 학습한 뒤, 평가 결과에 따라 변경을 유지하거나 버리는 반복 실험 프레임워크입니다. 숫자 몇 개를 자동 탐색하는 데서 그치지 않고 코드 수준의 가설을 시험할 수 있다는 점이 핵심입니다. 다만 짧은 단일 GPU 실험의 승자가 장기 학습과 다른 하드웨어에서도 최선이라는 보장은 없습니다.
카파시의 Autoresearch는 무엇을 자동화하나: 반복 실험의 범위와 한계
Autoresearch는 정확히 무엇을 자동화하나
Autoresearch 저장소가 보여 주는 기본 루프는 단순합니다. 사람이 연구 목표와 제약을 적고, 에이전트가 허용된 훈련 파일을 바꾸며, 제한된 시간 안에 실행한 결과를 지표로 비교합니다. 개선으로 판정된 변경은 다음 실험의 출발점이 되고 그렇지 않은 변경은 버립니다. 이 과정은 연구 가설 생성, 구현, 짧은 평가, 기록이라는 반복 작업의 일부를 자동화합니다.
여기서 자동화되지 않는 부분도 분명합니다. 어떤 문제를 풀지, 어떤 데이터와 지표를 신뢰할지, 어느 파일을 고정할지, 얼마나 긴 후속 검증을 할지는 사람이 정해야 합니다. 지표가 실제 목표를 잘못 대변하면 에이전트는 그 잘못된 목표를 빠르게 최적화할 뿐입니다. 따라서 이 도구를 자율 연구소라기보다 통제된 코드 실험 반복기로 이해하는 편이 정확합니다.
세 파일을 분리한 이유는 무엇인가
기존 글에서 소개된 구성은 prepare.py, train.py, program.md의 역할을 나눕니다. prepare.py는 데이터 준비와 토크나이저 같은 비교 환경을 담당하고 에이전트의 수정 대상에서 제외됩니다. train.py는 실제 훈련 로직과 모델 구조가 들어 있는 수정 대상입니다. program.md에는 에이전트가 따라야 할 목표, 제약, 실험 규칙이 적힙니다.
이 분리는 편의를 위한 폴더 정리보다 실험의 인과 관계를 지키는 장치에 가깝습니다. 데이터 전처리와 평가 데이터까지 매번 바뀌면 점수 개선이 모델 변경에서 왔는지 입력 조건 변경에서 왔는지 알 수 없습니다. 반대로 모든 코드를 잠그면 기존 자동 튜너처럼 제한된 숫자만 찾게 됩니다. 고정 영역과 탐색 영역의 경계를 명시해야 코드 수준 탐색과 공정한 비교를 동시에 유지할 수 있습니다.
운영할 때는 파일 이름보다 변경 권한이 중요합니다. 평가 함수, 검증 데이터, 시간 측정 코드, 결과 기록기를 수정 금지 대상으로 두고 훈련 경로만 허용해야 합니다. 에이전트가 오류를 숨기거나 평가 표본을 줄여 더 좋은 점수를 만드는 우회가 가능한지도 사전에 점검해야 합니다.
고정된 실행 시간은 왜 중요한가
에포크나 스텝 수를 고정하면 한 스텝이 느린 모델과 빠른 모델이 같은 계산 예산을 썼다고 보기 어렵습니다. Autoresearch의 고정된 벽시계 시간은 주어진 하드웨어에서 제한 시간 안에 얼마나 좋은 결과를 만드는지 비교하려는 선택입니다. 계산량이 큰 구조는 같은 시간에 더 적게 학습하고, 효율적인 구조는 더 많은 업데이트를 수행하므로 속도와 품질을 하나의 현실적인 예산 안에서 경쟁시킬 수 있습니다.
하지만 이 기준은 하드웨어에 종속됩니다. 메모리 대역폭, 커널 지원, 정밀도, 컴파일 오버헤드가 달라지면 같은 코드의 상대 순위도 바뀔 수 있습니다. 첫 실행에만 큰 컴파일 비용이 드는 방법은 짧은 제한에서 불리하고, 장시간에는 유리할 수도 있습니다. 따라서 시간 비교에는 워밍업 여부, 데이터 로딩 시간 포함 범위, 측정 시작점과 종료점을 고정해서 기록해야 합니다.
짧은 예산은 가설을 빠르게 거르는 1단계로는 유용하지만 최종 결론은 아닙니다. 좋은 후보를 더 긴 시간으로 승격하고, 최종 학습 예산에 가까운 설정에서 다시 비교하는 단계가 필요합니다. 제한 시간이 바뀌었을 때 순위가 유지되는지도 확인해야 특정 시간 구간에만 맞춘 변경을 걸러낼 수 있습니다.
val_bpb는 무엇을 비교하게 해 주나
기존 설명에서 사용한 val_bpb는 검증 데이터의 바이트당 비트 수를 기준으로 압축 효율을 나타내는 지표입니다. 토큰 단위 손실은 토크나이저의 어휘와 분할 방식이 바뀌면 직접 비교하기 어려울 수 있습니다. 원시 바이트 양을 공통 분모로 삼으면 서로 다른 토큰화 조건을 비교할 때 생기는 일부 불공정을 줄일 수 있습니다.
그렇다고 val_bpb 하나가 언어 모델의 모든 품질을 대표하지는 않습니다. 검증 분포에 대한 압축 성능이 좋아져도 지시 이행, 사실성, 긴 문맥 처리, 안전성은 달라질 수 있습니다. 에이전트가 토크나이저나 데이터 경로를 실제로 수정할 수 있는지도 저장소의 허용 범위와 함께 확인해야 합니다. 지표의 장점과 수정 권한을 섞어 “무엇이든 공정하게 비교한다”고 확대 해석해서는 안 됩니다.
기존 자동 탐색과 어떻게 다른가
베이지안 최적화나 격자 탐색은 사람이 미리 정한 학습률, 배치 크기, 드롭아웃 같은 변수 공간에서 후보를 고르는 데 강합니다. 결과를 표로 비교하기 쉽고, 잘 정의된 공간에서는 반복 가능성도 높습니다. 반면 모델 블록의 순서를 바꾸거나 새로운 스케줄러 로직을 구현하는 일은 보통 탐색 공간 밖에 있습니다.
Autoresearch 방식은 에이전트가 파이썬 코드 구조와 로직을 바꿀 수 있어 탐색 범위가 넓습니다. 새로운 아이디어를 구현하는 비용이 낮아지는 대신 문법 오류, 사용하지 않는 코드, 평가 경로 변경, 이전 실험과의 의존성 같은 실패가 추가됩니다. 숫자 탐색의 후보 하나와 코드 변경 하나는 위험도가 다르므로 실행 성공 여부만으로 유효한 실험이라고 판정해서는 안 됩니다.
선택 기준은 문제에 따라 달라집니다. 이미 후보 변수와 허용 범위가 명확하다면 전통적인 탐색이 더 단순하고 감사하기 쉽습니다. 코드 구조 자체를 바꾸는 작은 연구 가설을 많이 시험하려면 Autoresearch 유형의 루프가 맞을 수 있습니다. 두 방식을 결합해 에이전트가 구조 후보를 만들고 안정적인 숫자 조정은 별도 탐색기로 넘기는 구성도 검토할 수 있습니다.
짧은 성과가 장기 학습에서 실패하는 이유는 무엇인가
에이전트의 목표가 제한 시간 안의 점수뿐이면 초기 수렴을 빠르게 만드는 변경을 선호할 수 있습니다. 높은 학습률, 약한 규제, 작은 모델처럼 초반에는 유리하지만 긴 학습에서는 불안정하거나 최종 성능이 낮은 선택이 남을 수 있습니다. 제한 시간 직후의 한 점만 보면 발산 직전의 후보와 안정적으로 개선 중인 후보를 구분하기 어렵습니다.
이 문제를 줄이려면 후보 승격 단계를 나누는 것이 좋습니다. 첫 단계에서는 짧은 예산으로 다수의 아이디어를 거르고, 두 번째에서는 더 긴 학습과 여러 시드로 평균과 변동을 확인합니다. 마지막에는 원래 기준선과 동일한 최종 예산으로 비교하고, 손실 곡선과 처리량, 최대 메모리, 실패 실행까지 함께 기록합니다.
단기 지표를 악화시키지만 장기적으로 좋아지는 아이디어도 놓칠 수 있습니다. 워밍업이 길거나 초기에 강한 규제를 쓰는 방법은 짧은 평가에서 탈락하기 쉽습니다. 따라서 연구 목적이 최종 품질인지 제한 시간 내 효율인지 먼저 정하고, 그 목적에 맞는 승격 기준을 별도로 설계해야 합니다.
코드가 누적되며 무너지는 문제는 어떻게 막나
여러 실험의 변경을 계속 덧붙이면 훈련 파일이 복잡해지고 이전 가정이 남습니다. 변수 이름과 텐서 형태가 어긋나거나, 비활성 분기처럼 보이는 코드가 실제 평가에 영향을 줄 수도 있습니다. 컨텍스트가 길어질수록 에이전트가 모든 의존성을 정확히 추적한다고 기대하기 어렵습니다.
각 실험은 작은 변경으로 제한하고, 실행 전에 문법 검사와 짧은 스모크 테스트를 통과하게 해야 합니다. 결과 기록에는 코드 차이, 실행 명령, 환경, 시드, 지표와 오류 로그를 연결합니다. 일정 횟수마다 기준선에서 다시 시작해 살아남은 변경을 하나씩 재적용하면 우연히 함께 들어온 수정이나 누적된 찌꺼기를 찾기 쉽습니다.
리팩터링도 성능 실험과 분리하는 편이 좋습니다. 동작을 바꾸지 않는 정리 단계와 지표를 개선하려는 단계가 섞이면 점수 변화의 원인을 알 수 없습니다. 자동 포매팅이나 테스트가 파일을 기계적으로 바꾸더라도 해당 변경을 별도의 커밋과 로그로 남겨야 합니다.
하드웨어가 바뀌면 무엇을 다시 확인해야 하나
한 GPU에서 제한 시간 내 빠른 구현이 다른 GPU나 여러 장의 GPU에서도 빠르다는 보장은 없습니다. 특정 연산의 커널 효율, 통신 비용, 메모리 사용 패턴이 달라지기 때문입니다. 단일 GPU에서 작은 배치에 유리한 구조가 분산 학습에서는 통신 병목을 키울 수 있고, 반대로 큰 모델에 유리한 최적화는 짧은 로컬 실험에서 후보조차 되지 못할 수 있습니다.
이식 전에는 대상 하드웨어에서 처리량, 메모리, 컴파일 시간, 통신 비율을 다시 측정해야 합니다. 모델 품질이 같아도 운영 비용이 커지면 실용적인 개선이 아닐 수 있습니다. 로컬 결과는 아이디어 선별 자료로 취급하고 실제 학습 환경에서 재현한 결과만 본 실험의 근거로 승격하는 것이 안전합니다.
실무 도입 여부는 어떤 순서로 결정할까
먼저 반복 실행이 싸고 결과를 자동 판정할 수 있는 작은 문제를 고릅니다. 수정 대상 파일과 고정 파일을 분리하고, 데이터 누수와 평가 코드 변조를 막습니다. 그런 다음 기준선을 여러 번 실행해 자연 변동을 측정합니다. 개선 폭이 그 변동보다 작다면 한 번의 승리로 변경을 채택해서는 안 됩니다.
다음으로 실패 예산을 정합니다. 연속 오류 횟수, GPU 시간, 저장 공간, 비정상 손실, 수정 가능한 코드 크기에 상한을 둡니다. 에이전트가 외부 명령이나 파일에 접근한다면 권한도 최소화해야 합니다. 마지막으로 짧은 실험의 우승 후보를 더 긴 예산과 여러 시드에서 사람이 검토한 뒤 본 학습으로 넘깁니다.
Autoresearch의 실제 가치는 연구자의 판단을 제거하는 데 있지 않습니다. 구현과 반복 측정의 비용을 낮추고, 사람이 평가 설계와 인과 검증에 더 집중할 수 있게 하는 데 있습니다. 자동화 범위를 작게 시작하고 승격 기준을 엄격히 두면 흥미로운 실험 도구가 될 수 있지만, 결과를 곧바로 일반 법칙처럼 받아들이면 빠른 최적화가 빠른 오판으로 바뀔 수 있습니다.
함께 읽으면 이해가 이어지는 글
- DeepSeek Engram이 VRAM을 DRAM으로 옮길까: O(1) N-gram 조회와 PCIe 병목 — 정적 N-gram 지식을 DRAM, CXL에서 조회하고 GPU를 추론에 집중시키는 Engram의 구조와, 초기 레이어 삽입, PCIe, OOV, 데모 코드 한계를 정리합니다.
- oMLX: 애플 실리콘에서 AI 코딩 에이전트 속도를 극대화하는 MLX 추론 서버 — oMLX는 애플 실리콘 Mac 환경에서 MLX 프레임워크를 기반으로 작동하는 고성능 LLM 추론 서버입니다. 페이징 처리된 SSD KV 캐싱과 연속 배칭을 통해 AI 코딩 에이전트의 첫 토큰 생성 시간(TTFT)을 획기적으로…
- Wigolo: AI 코딩 에이전트에게 무제한 로컬 웹 검색과 크롤링 능력을 달아주는 법 — Wigolo는 외부 API 과금 없이 내 PC의 자원을 활용해 AI 코딩 에이전트에게 무제한 웹 검색, 크롤링, 캐싱을 제공하는 로컬 기반 MCP 서버입니다. 단순한 검색을 넘어 JS 렌더링, PDF 파싱, 데이터 영속성 관리를 통해…
자주 묻는 질문
Autoresearch는 Optuna 같은 하이퍼파라미터 탐색 도구와 무엇이 다른가요?
정해 둔 숫자 후보만 고르는 것이 아니라 에이전트가 허용된 훈련 코드 자체를 수정할 수 있다는 점이 다릅니다. 그만큼 탐색 범위가 넓지만 코드 오류와 비교 조건 오염도 함께 관리해야 합니다.
짧은 실험에서 좋아진 결과를 장시간 학습에도 그대로 쓸 수 있나요?
그대로 쓸 수 있다고 단정하면 안 됩니다. 초기 수렴 속도를 높인 변경이 장기 안정성이나 최종 품질을 해칠 수 있으므로 더 긴 예산과 여러 시드로 다시 확인해야 합니다.
Autoresearch를 운영할 때 사람이 반드시 결정해야 하는 것은 무엇인가요?
수정 가능한 파일과 금지 행동, 평가 지표, 계산 예산, 중단 조건, 승격 검증 절차는 사람이 정해야 합니다. 에이전트가 만든 변경을 본 학습과 배포로 넘기는 승인도 분리하는 편이 안전합니다.
표지 1 —
←→ 키와 좌우 스와이프를 지원합니다. 읽던 페이지는 이 기기에 저장됩니다.
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.