Google Developers Blog가 2026년 5월 28일 Tunix Hackathon 결과를 정리했습니다. 주제는 단순합니다. Gemma-2-2B와 Gemma-3-1B 같은 non-reasoning base model을 제한된 컴퓨트로 일반 추론 모델에 가깝게 만들 수 있는가입니다. 조건도 꽤 빡빡했습니다. Kaggle TPU v5e-8을 9시간 쓰는 수준의 예산입니다. 그런데 11,000명 이상이 참가했고 300개 이상의 고품질 제출물이 나왔습니다.
이 뉴스가 실무 개발자에게 중요한 이유는 “작은 모델도 생각할 수 있다”는 낭만이 아닙니다. SFT, SimPO, GRPO, LoRA, LLM-as-a-judge, rubric reward, TF-IDF reward 같은 post-training 부품을 어떻게 조합하면 작은 모델의 행동을 바꿀 수 있는지 구체적인 사례가 나왔기 때문입니다. 특히 사내 도메인 모델을 만들려는 팀에게는 모델 크기보다 학습 레시피가 더 중요하다는 신호입니다.
프런티어 모델은 복잡한 문제에서 답하기 전에 reasoning trace를 생성합니다. 하지만 이 능력을 어떻게 학습했는지는 대개 공개되지 않습니다. 인터넷에는 수학이나 코딩처럼 정답 검증이 쉬운 GRPO 튜토리얼은 많지만, 법률, 의료, 로봇, 업무 판단처럼 open-ended reasoning이 필요한 영역의 재현 가능한 레시피는 적습니다.
실무팀은 여기서 막힙니다. 사내 데이터로 작은 모델을 fine-tune하려고 해도, 단순 SFT만 하면 말투는 따라 하지만 추론 품질은 잘 오르지 않습니다. 반대로 RL을 바로 붙이면 reward 설계가 어렵고 compute budget도 커집니다. 어떤 순서로 무엇을 해야 하는지 모르면 “데이터 더 넣기”만 반복하게 됩니다.
Tunix 해커톤의 의미는 이 빈칸을 줄였다는 데 있습니다. 참가자들은 9시간 TPU 예산 안에서 structured reasoning, format control, judge reward, curriculum, domain-specific scaffold를 조합했습니다.
1위 G-RaR은 rubric-based reinforcement learning을 사용했습니다. 먼저 LoRA 기반 SFT로 약 33k 샘플을 학습해 모델이 reasoning을 특정 tag 안에 출력하도록 warm start를 만들었습니다. 이후 GRPO 단계에서 Format Reward, Exact Answer Reward, G-RaR Score를 섞었습니다. 여기서 핵심은 Gemma-3-12B judge가 task-specific rubric으로 중간 reasoning step의 품질을 평가했다는 점입니다.
2위 Pinocchio-1B는 SFT → SimPO → GRPO 순서로 갔습니다. SFT로 기본 Chain-of-Thought를 넣고, SimPO로 엄격한 XML formatting을 고정하고, GRPO로 accuracy, logic, format을 보상했습니다. DPO보다 메모리 부담이 작은 SimPO를 선택한 점도 실용적입니다.
3위 IDEA-E 접근은 윤리적 판단 프레임워크를 작은 모델에 distill하고, curriculum-guided GRPO와 TF-IDF reward를 사용했습니다. 느린 LLM judge 대신 빠른 TF-IDF reward를 일부 사용해 CPU에서 non-blocking reward 계산을 돌린 점이 눈에 띕니다.
이 사례들이 공통으로 말하는 것은 하나입니다. 작은 모델은 정답 데이터만으로 충분하지 않습니다. 먼저 출력 형식, 사고 절차, 평가 기준을 고정한 뒤 reward loop로 다듬어야 합니다.
첫 번째 단계는 SFT입니다. 목적은 모델을 똑똑하게 만드는 것이 아니라 “문제-근거-판단-답변” 같은 출력 구조를 배우게 하는 것입니다. 데이터는 많을수록 좋지만, 처음부터 수십만 개를 만들 필요는 없습니다. 중요한 것은 일관된 schema입니다. 예를 들어 고객지원 판단 모델이라면 facts, policy, decision, next_action 구조를 고정할 수 있습니다.
두 번째 단계는 format alignment입니다. 모델이 긴 설명으로 reward를 속이거나, 매번 다른 형식으로 답하면 운영에 넣기 어렵습니다. Pinocchio 사례처럼 SimPO나 유사 preference optimization으로 형식을 잠그는 단계가 필요합니다. 실무에서는 JSON schema validation, XML tag 검사, 필수 필드 누락 감점 같은 규칙형 reward를 섞는 것이 좋습니다.
세 번째 단계는 targeted RL입니다. 모든 문제를 한 번에 잘하게 만들려고 하지 말고, 특정 실패 유형을 reward로 고칩니다. 예를 들어 “환불 정책에서 예외 조항을 누락한다”, “로그 분석에서 symptom을 root cause로 착각한다”, “법률 문서에서 관할 조항을 무시한다” 같은 실패군을 잡고 GRPO 또는 preference loop를 돌립니다.
대부분의 팀은 “어떤 base model을 쓸까”부터 고민합니다. 하지만 이번 해커톤 결과를 보면 작은 모델에서도 reward 설계가 큰 차이를 만듭니다. LLM-as-a-judge는 유연하지만 비용과 지연이 큽니다. rubric score는 open-ended task에 유리하지만 judge 편향이 들어갑니다. TF-IDF reward는 빠르지만 의미 판단이 약합니다. exact match는 싸고 명확하지만 현실 문제에는 잘 맞지 않습니다.
따라서 reward는 하나로 끝내지 말고 composite로 설계해야 합니다.
이렇게 나눠야 어떤 실패가 줄었고 어떤 부작용이 생겼는지 추적할 수 있습니다.
해커톤 조건은 Kaggle TPU v5e-8 9시간이었습니다. 물론 실제 production 모델 학습은 더 많은 데이터와 검증이 필요합니다. 그래도 이 조건은 중요한 기준선을 줍니다. 모든 reasoning 개선이 거대 클러스터에서만 가능한 것은 아닙니다. 사내 업무 모델의 첫 버전은 작은 모델, LoRA, 제한된 SFT, 작은 reward loop로 시작할 수 있습니다.
특히 개인정보나 내부 문서 때문에 외부 프런티어 API에 전부 의존하기 어려운 조직은 이런 레시피를 검토할 가치가 있습니다. 작은 모델이 GPT급 general intelligence를 갖는 것은 아니지만, 좁은 도메인에서 구조화된 판단을 안정적으로 반복하는 데는 충분할 수 있습니다.
post-training을 하기 전에 반드시 evaluation set을 만들어야 합니다. 그렇지 않으면 학습이 잘 된 것처럼 보여도 실제로는 답변이 길어지거나 형식만 좋아진 것일 수 있습니다. 최소한 train, dev, held-out test를 나누고, 도메인별 실패 유형을 태깅하세요.
추천 평가 항목은 다음과 같습니다.
Tunix 해커톤처럼 공개 writeup을 참고하되, 사내 문제에는 사내 평가셋이 필요합니다. 공개 benchmark에서 좋아도 우리 데이터에서는 실패할 수 있습니다.
Tunix 해커톤 결과는 작은 모델 post-training의 방향을 꽤 현실적으로 보여줍니다. 핵심은 더 큰 모델을 기다리는 것이 아니라, 작은 모델이 지켜야 할 사고 구조와 평가 기준을 제품 문제에 맞게 설계하는 것입니다.
참고: Google Developers Blog, “How the community trained Gemma to Think with Tunix and TPUs”, 2026-05-28.
