Google Tunix autofinetune: LLM 파인튜닝을 밤새 자동 실험하는 구조

Google Developers Blog에 올라온 Tunix 기반 autofinetune 글은 “AI가 파인튜닝을 대신한다”는 홍보문보다 더 구체적이다. 사람이 Markdown으로 실험 규칙을 적고, 에이전트가 학습 스크립트를 수정하고, TPU에서 실험을 돌리고, 평가 점수가 좋아진 변경만 Git에 남기는 구조다. Google은 이 접근을 SFT와 GRPO 두 사례로 설명했다. FunctionGemma 270M 모델의 함수 호출 생성 정확도 실험은 Cloud TPU v5e-1에서 몇 분 단위로 20회 자동 실행했고, Gemma 3 1B의 GSM8K GRPO 실험은 TPU v6e-1에서 2~3일 동안 40회 돌려 reward를 약 10% 개선했다고 밝혔다.

수동 파인튜닝의 병목은 코드 작성이 아니라 반복 관리다

LLM 후처리 학습은 보통 같은 루프를 반복한다. LoRA rank를 바꿔보고, target module을 조정하고, learning rate schedule을 바꾸고, batch size를 바꾸고, 결과를 평가하고, 실패한 실험은 되돌린다. 개별 작업은 어렵지 않지만 사람이 계속 붙어 있어야 한다. 특히 reinforcement learning 계열은 하이퍼파라미터에 민감하고 한 번의 실험 시간이 길어 실패 비용이 크다.

autofinetune의 핵심은 이 반복을 “에이전트가 만질 수 있는 안전한 arena”로 만든다는 점이다. 사람은 program.md에 경계와 평가 기준을 쓴다. run.py는 깨끗하고 독립적인 학습 스크립트로 둔다. 에이전트는 program.md를 읽고 run.py를 수정한 뒤 학습을 실행한다. 결과는 results.tsv에 기록하고, 성능이 나빠지면 되돌린다. 좋아진 변경은 commit으로 남긴다.

program.md는 프롬프트가 아니라 실험 계약서다

이 구조에서 가장 중요한 파일은 화려한 시스템 프롬프트가 아니라 program.md다. 여기에는 허용된 변경과 금지된 변경이 들어간다. Google의 SFT 사례에서는 LoRA rank와 alpha, target projection layer, learning rate, warmup과 decay schedule, optimizer, gradient clipping, batch size, seed는 바꿀 수 있었다. 반대로 dataset, epoch 수, model architecture는 바꾸지 못하게 했다.

이 구분이 없으면 에이전트는 점수를 올리기 위해 문제 자체를 바꿀 수 있다. 데이터셋을 줄이거나 평가 함수를 느슨하게 만들거나 epoch를 늘려 공정하지 않은 비교를 만들 수도 있다. 자동 실험의 첫 번째 위험은 모델이 실험을 잘하는 것이 아니라 실험 규칙을 망가뜨리는 것이다. 그래서 program.md는 “무엇을 최적화할 것인가”보다 “무엇을 절대 바꾸지 말 것인가”를 더 명확히 해야 한다.

SFT 사례: 빠른 반복에는 작은 모델과 짧은 평가가 맞다

첫 사례는 google/functiongemma-270m-it와 google/mobile-actions 데이터셋을 사용한 Supervised Fine-Tuning이다. 목표는 함수 호출 생성 정확도 개선이었다. 하드웨어는 Cloud TPU v5e-1, 반복 속도는 실험당 몇 분, 총 20회 자동 실험이었다. 이 구성은 자동화 검증에 적합하다. 모델이 작고, 평가가 명확하고, 실패해도 비용이 낮다.

실무에서도 처음부터 큰 모델과 비싼 RL 실험으로 자동 루프를 시작하면 안 된다. 먼저 작은 모델, 짧은 데이터셋 slice, 빠른 objective metric으로 에이전트가 실험 규칙을 지키는지 확인해야 한다. results.tsv에는 최소한 run id, 변경 요약, 핵심 metric, 비용 또는 시간, commit hash, revert 여부를 남기는 것이 좋다. 그래야 사람이 아침에 결과를 보고 “왜 좋아졌는지”와 “재현 가능한지”를 판단할 수 있다.

GRPO 사례: 긴 실험일수록 단일 지표가 필요하다

두 번째 사례는 Gemma 3 1B를 GSM8K 수학 추론에 맞춰 GRPO로 조정하는 실험이다. 하드웨어는 TPU v6e-1, 실험당 수 시간, 2~3일 동안 40회 실행이다. Google은 outer optimization loop를 단순화하기 위해 numerical_accuracy + format_accuracy를 합친 Post_RL_metric을 사용했다고 설명했다.

이 선택은 중요하다. 에이전트에게 여러 지표를 동시에 던지면 판단이 흔들린다. 정확도는 올랐지만 형식이 깨진 실험, 형식은 좋아졌지만 풀이가 틀린 실험, 비용은 줄었지만 성능이 나빠진 실험을 어떻게 비교할지 정해야 한다. 자동 실험에서는 사람이 나중에 해석할 세부 지표를 남기되, 에이전트가 commit/revert를 결정할 기준은 하나로 줄이는 편이 안전하다.

자동 파인튜닝에서 바로 터지는 실패 패턴

첫째, 평가 데이터 누수다. 에이전트가 평가셋에 맞춘 프롬프트나 후처리를 만들면 실제 성능은 오르지 않는다. 둘째, 비용 폭주다. batch size나 rollout 설정을 잘못 바꾸면 TPU 시간이 급증한다. 셋째, 로그 불충분이다. 점수만 남기면 원인 분석이 안 된다. 넷째, 환경 드리프트다. 라이브러리 버전, seed, 데이터 전처리가 바뀌면 전날 결과와 비교할 수 없다.

따라서 자동 루프에는 기술적 guardrail이 필요하다. wall-clock timeout, 최대 실험 수, 최대 비용, 변경 가능한 파일 목록, 금지된 import, 평가셋 read-only 권한, 실패 시 자동 revert, 결과 파일 schema 검증을 넣어야 한다. Git commit을 남기는 이유도 여기 있다. 최종 모델보다 실험 이력이 더 중요할 때가 많다.

팀에서 적용하는 가장 작은 시작점

실무 팀이라면 먼저 “하루 밤 자동화”가 아니라 “10회 이하 dry-run”으로 시작하는 편이 낫다. 이미 쓰는 fine-tuning 스크립트를 run.py처럼 독립 실행 가능하게 만들고, validation metric을 하나 정한다. 그다음 program.md에 허용 변경 5개와 금지 변경 5개를 적는다. 첫 루프에서는 학습을 실제로 돌리지 말고 diff 생성과 명령 조립만 하게 해도 된다. 그 뒤 작은 모델에서 3회, 10회, overnight 순서로 넓힌다.

실행 체크리스트

• run.py는 외부 상태 의존을 줄이고 한 명령으로 재현되게 만든다.
• program.md에 allowed/disallowed 변경 범위를 명시한다.
• commit/revert 기준이 되는 primary metric을 하나로 정한다.
• results.tsv에는 metric뿐 아니라 변경 요약, 시간, 비용, seed, commit hash를 남긴다.
• 평가셋과 objective 함수는 read-only로 취급한다.
• TPU/GPU 예산, timeout, 최대 실험 수를 코드로 강제한다.
• 첫 도입은 작은 모델과 짧은 데이터셋으로 검증한다.

Tunix autofinetune의 의미는 파인튜닝 전문가가 필요 없어졌다는 것이 아니다. 반복 실험을 사람이 계속 클릭하는 방식에서 벗어나, 사람이 실험장을 설계하고 에이전트가 제한된 공간에서 탐색하게 만드는 운영 패턴이 생겼다는 뜻이다. 좋은 자동화는 모델에게 자유를 주는 것이 아니라, 바꿔도 되는 것과 바꾸면 안 되는 것을 냉정하게 나누는 데서 시작한다.