《GPU Mode》 L085 2025 Mid priority transcript · failed

Factorio Learning Environment — LLM 에이전트가 공장을 짓는다

Factorio 라는 자동화 게임을 LLM 에이전트의 평가 환경으로 다시 깐 프로젝트. 단발성 코드 문제(HumanEval, MBPP) 와 도구 사용 벤치마크의 한계 너머에서 — 모델이 장기 계획, 자원 관리, 동적 디버깅을 한 시간 단위 동안 유지할 수 있는지를 본다. Jack Hopkins 가 깐 평가 디자인, metric, 모델별 결과를 외부 자료로 재구성한 학습 노트. GPU Mode 시리즈 안에서는 커널 강의 사이의 호흡 고르기 자리이지만, agent eval 의 디자인 쟁점이 LLM 시스템 엔지니어링과 직접 닿는다.

LLM agent long-horizon eval Factorio tool use RL benchmark

Speaker

Jack Hopkins

Factorio Learning Environment 저자 · 독립 연구자 · 확인 필요

강의 번호

L085

스피커

Jack Hopkins

학습 우선순위

Mid · 호흡 고르기

자막

failed · 외부 자료

하위 목차 · 12개 섹션↓ 클릭해서 이동

01강의가 풀려는 문제why this exists 02평가 환경 디자인env design 03Factorio 의 적합성why this game 04평가 metricproduction rate · time-to-task 05에이전트 loopobserve · plan · act 06모델별 결과GPT-5 · Claude · Gemini 07RL 적용RL on Factorio? 08한계limits of the env 09reproducibilityseed · save · trace 10기억할 메모key takeaways 11다른 강의로 이어지는 길connections 12열린 질문open questions

§ 01강의가 풀려는 문제· why this exists

“코드 한 줄 짜기” 와 “하루 동안 공장 짓기” 의 차이

2024–2025 시점 LLM 평가의 가장 큰 미해결 문제 — 장기 horizon. SWE-bench, HumanEval, GAIA 같은 벤치마크는 모두 짧은 호흡의 task 를 본다. 한 step 의 도구 호출, 한 PR 의 수정. 그런데 실제 production agent (Claude Code, Cursor, Devin) 는 수십 step 의 호흡으로 일한다 — 이 영역의 평가가 부족하다.

Factorio Learning Environment (FLE) 는 이 빈자리를 메우는 한 시도. Factorio 라는 게임을 평가 환경으로 wrap 해서 — LLM 에이전트가 자원 채굴, 운송 belt 깔기, 제련 공장 짓기, 더 복잡한 회로 만들기까지 — 한 세션 동안 누적된 결정으로 점수를 받게 한다.

Factorio 의 task 는 자연스럽게 long-horizon — 한 시간 안에 “automation science pack” 을 자동 생산하는 라인을 깐다는 목표는 수백 개의 작은 결정을 요구한다.
평가가 자동화 가능 — 게임 안에 “초당 생산량” 같은 측정 가능한 신호가 박혀 있다.
diverse skills — 공간 추론, 자원 관리, 디버깅, 계획 수정 — 이 모두가 자연스럽게 한 task 안에 들어 있다.

자료 한계 · 확인 필요

강의 자막이 실패했고, 슬라이드 / 코드 / 논문 링크가 GPU Mode repo 에 공개돼 있지 않다. 이 노트는 — 외부에 공개된 FLE 관련 자료(Jack Hopkins 의 GitHub, X/Twitter 발표, 관련 paper)를 합쳐 — 이 강의가 다뤘을 법한 형태로 재구성한 것. 정확한 발표 시퀀스와 수치는 보강 필요.

“agent 의 진짜 능력은 한 step 의 정확도가 아니라 — 50 step 째에 처음 step 의 결정을 어떻게 다루는가 에서 드러난다.”학습 노트 · 재구성

§ 02평가 환경 디자인· env design

Factorio 를 평가 환경으로 다시 까는 작업

FLE 는 Factorio 를 직접 fork 하지 않는다. 대신 게임의 headless 모드 + Lua API 를 wrap 해서 — agent 가 “게임 안 명령” 을 내릴 수 있는 인터페이스를 만든다.

구체적인 인터페이스 디자인은 — 외부 자료에서 확인 가능한 한도 안에서 — 대략 이런 모양으로 추정된다.

state observation — agent 가 받는 입력. 게임 안의 그리드 (entity, ore, belt, machine 의 위치), 인벤토리, 현재 생산 rate.
action API — agent 가 내리는 명령. place_entity, connect_belt, craft, research 같은 함수들.
reward signal — 통상 task 완료 또는 “초당 X 개 자동 생산” 같은 measurable.
tool calling 형태 — agent 가 Python/Lua 함수 호출 형태로 게임에 명령. LLM tool use 의 표준 패턴.
episode boundary — 새 게임 시작 / 같은 save 이어서 / partial restore 의 정의.

FIG · agent ↔ env 의 인터페이스tool-call 형태

A0 env state → agent grid map (ASCII or JSON), inventory, production rate, errors

A1 agent thinks CoT / scratchpad, plan revision, sub-goal selection

A2 agent → tool call place_entity(x,y,type) · connect(a,b) · craft(item) · wait(s)

A3 env step Factorio simulation 일정 tick 진행. 생산이 도는지 확인.

통상 한 episode 는 수십~수백 (A0–A3) 사이클. 한 cycle 의 비용 ≠ 한 LLM call. context window 가 늘어남에 따라 long-horizon 의 비용이 빠르게 큰다.

FIG · 게임 grid 의 한 토막 (예시)iron 채굴 → smelt 라인

###      .       .       .
###  →  ▶▶▶▶▶▶  →  [F]  →  ▶▶▶  →  inventory
###      .                   .
### iron ore     ▶ belt           [F] furnace

왼쪽: 철광 채굴(###). 가운데: belt(▶) 로 운송. 오른쪽: 제련소([F]). 한 episode 의 첫 task 가 보통 이 라인 짓기. agent 가 직접 그리드 좌표를 계획하고 명령을 내려야 한다.

§ 03Factorio 의 적합성· why this game

왜 다른 게임이 아니라 Factorio 인가

평가 환경 디자인의 표준 후보들 — Minecraft, StarCraft, NetHack — 와 비교해서 Factorio 가 LLM agent 평가에 자연스러운 이유를 정리.

측정 가능한 신호

“초당 X 개 생산” 같은 양적 신호가 게임 자체에 박혀 있음. reward 디자인의 ambiguity 가 적음.

progressive complexity

제련 라인 → 자동 채굴 → 회로 → blue science → purple science 까지 자연스러운 난이도 곡선. agent 의 어디서 막히는지 측정 가능.

structured action space

Minecraft 의 free-form 클릭과 달리 Factorio 의 action 은 grid + entity 단위로 이산. tool-call 인터페이스로 자연스럽게 wrap.

deterministic simulation

게임 엔진이 deterministic — 같은 seed + 같은 action sequence → 같은 결과. reproducibility 의 기초.

human baseline 풍부

스피드런 커뮤니티가 강력 — “automation science pack 까지 1시간” 같은 인간 baseline 이 다양한 난이도로 존재.

long-horizon

한 episode 가 자연스럽게 1–10 시간 단위. 짧은 task 위주의 기존 벤치마크와 다른 스케일.

강의에서 발표자가 라이브로 보여줬을 가능성이 높은 비교 — 같은 LLM 이 SWE-bench 에서는 80% 이상 풀면서 Factorio 의 자동 채굴 라인을 한 번에 못 깐다. 같은 모델이 다른 task 에서 이렇게 다른 모습을 보이는 자리가 long-horizon eval 의 가치.

단점도 분명

Factorio 가 만능 평가 환경은 아니다. multimodal 능력은 거의 안 본다 (시각 input 의 자리는 작음). natural language 추론도 약하다. 도메인 학습 효과가 크다 — 같은 모델이 Factorio 를 “알면” 점수가 크게 뛴다. eval 의 saturation 위험.

§ 04평가 metric· production rate · time-to-task

“얼마나 잘 했는가” 를 어떻게 숫자로 만드는가

FLE 가 사용하는 (것으로 추정되는) metric 묶음. 단일 score 가 아니라 — 여러 차원의 점수가 함께.

production rateper second 정해진 시간 안에 도달한 item 생산 속도. 가장 직접적인 “공장 잘 깔았는가” 의 신호. primary

time-to-taskmilestone reach “automation science pack 1개 생산까지의 wall-clock”. 각 milestone 별로 점수. primary

survivalbiter attack 적 (biter) 의 공격 안에서 공장 유지. 동적 위협에 대한 반응. advanced

resource efficiencywaste ratio 사용된 ore 대비 만들어진 item. agent 가 자원을 얼마나 잘 쓰는가. secondary

recoveryafter failure 한 라인이 멈췄을 때 agent 가 디버그하고 복구하는지. 가장 강한 신호 중 하나. advanced

action efficiencytool calls per task 같은 task 를 몇 번의 tool call 로 끝냈는가. 효율의 신호. secondary

강의에서 Hopkins 가 강조했을 입장 — “single number 로 줄이면 정보가 사라진다.” 모델 X 가 production rate 는 높은데 recovery 는 약하고, 모델 Y 는 그 반대일 수 있다. multi-dimensional score 의 보고가 long-horizon agent 평가의 표준이 되는 흐름.

“agent 의 평가가 single score 로 줄어들면 — 다음 모델이 그 score 만 최적화한다.”학습 노트 · 재구성

§ 05에이전트 loop· observe · plan · act

한 cycle 안에서 LLM 이 무엇을 보고 무엇을 결정하는가

FIG · FLE 의 agent loop한 turn 의 내부

L0 observation 직렬화 env state → text/JSON. grid 를 ASCII art 로 렌더 + entity list + inventory + recent error.

L1 scratchpad / 계획 CoT 또는 명시적 plan store. 이전 turn 의 plan 과 비교, 수정 여부 결정.

L2 tool 선택 place_entity / connect_belt / craft / wait 중 하나. 인자 결정 (좌표, 종류).

L3 env step + 관측 N tick 진행. 새 state 직렬화 → L0 으로 복귀.

L0 의 “observation 직렬화” 가 디자인의 큰 부분이다 — grid 를 어떤 표현으로 보여줄지(ASCII vs JSON vs 좌표 list)가 모델 성능에 직접 영향. 같은 모델이 같은 task 에서 ASCII 표현으로는 풀고 JSON 표현으로는 못 풀 수 있다.

이 loop 의 디자인 decisions 는 결국 context window 와 tool-use 비용의 trade-off. observation 을 풍부하게 주면 LLM 이 잘 보지만 context 가 빨리 차고, 줄이면 agent 가 detail 을 놓친다. 이 균형이 production agent 시스템의 핵심 노하우.

memory pattern

한 episode 가 길어지면 context 한 번에 다 넣기 어렵다. FLE 의 agent 들은 보통 summary memory(이전 step 의 요약) + recent window(최근 N step) + plan store(현재 sub-goal) 의 조합. Claude Code / Cursor 의 production memory 패턴과 같은 구조.

§ 06모델별 결과· GPT-5 · Claude · Gemini

같은 task 에서 모델들이 어떻게 다른가

강의에서 Hopkins 가 보여줬을 가장 흥미로운 차트 — 같은 환경, 같은 task 에서 frontier 모델들의 점수 비교. 정확한 수치는 시점에 민감하므로 확인 필요 표시 — 아래는 외부 자료에서 일반적으로 등장하는 패턴의 재구성.

FIG · automation science pack 까지의 도달율2시간 episode · 확인 필요 (개념적 수치)

GPT-5 (high reasoning)

62%

Claude Opus 4.5

58%

Gemini 2.5 Pro

48%

DeepSeek-R1

35%

Llama-4-405B

18%

human baseline

90%

위 수치는 외부 자료 / 도메인 지식으로 재구성한 개념적 형태. 강의 안의 정확한 수치는 직접 확인 필요. 일관되게 등장하는 패턴 — frontier reasoning 모델이 잘 하지만 인간 baseline 까지는 아직 큼직한 갭.

패턴에서 읽히는 사실 — model size 보다 reasoning 능력이 더 결정적. 작은 모델도 reasoning 모드가 켜지면 큰 무지성 모델을 추월. long-horizon 의 본질이 context 누적이 아니라 추론의 깊이 라는 가설과 일관.

왜 인간이 더 나은가

인간 baseline 이 90% 인 자리에서 frontier 모델이 60% 대인 이유 — 통상 “공장의 한 부분이 멈췄을 때 어디를 디버그해야 하는지” 의 능력. LLM 은 한 번에 잘 깔지만, 멈춘 후 복구가 약함. recovery 라는 metric 이 가장 큰 격차 자리.

§ 07RL 적용· RL on Factorio?

“그냥 RL 시키면 안 되나” 의 답

평가 환경이 deterministic 이고 reward 가 measurable 인 자리는 RL 의 자연스러운 표적이다. Factorio 에서의 RL 시도가 어디까지 갔는지.

기존 RL 시도

2022–2024 사이 학계의 시도들 — Factorio 에 PPO 같은 표준 RL 을 적용. 단순 task (이동, 채굴) 까지는 학습. 복잡한 라인 깔기는 fail.

action space 폭발

grid 좌표 × entity 종류 × 회전 = 매우 큰 action space. random exploration 으로는 의미있는 정책 학습 불가.

long-horizon 의 sparse reward

“automation science pack” 까지의 reward 가 끝에서만 옴. 중간 reward 디자인 없이는 학습 곡선이 안 형성.

LLM agent 가 더 잘 함

domain knowledge 가 사전학습으로 들어가 있어 — RL 이 처음부터 학습하지 않아도 reasonable 정책. tabula rasa RL 의 한계.

RL fine-tune 의 가능성

LLM 의 base policy 위에 RL fine-tune. 최근 reasoning 모델(GPT-o3, R1) 의 흐름과 일관. Factorio 의 reward 신호로 LLM 을 RL fine-tune 하는 시도가 자연스러운 다음.

data 수집 환경으로

FLE 가 RL 보다 더 자연스럽게 도는 자리 — “LLM 이 풀이를 만들고, 평가 환경이 검증하고, 그 trajectory 가 학습 데이터” 의 RL-like 파이프라인.

“tabula rasa RL 의 자리는 좁아졌다 — Factorio 에서도 LLM agent + RL fine-tune 이 가장 합리적 다음 라운드.”강의 재구성

§ 08한계· limits of the env

FLE 가 다 측정하지 못 하는 것

multimodal 부족

실제 게임 화면 인식 능력은 거의 안 봄. text/JSON wrap 이 시각 추론을 우회. real-world 시각 task 와 다른 평가.

자연어 협업 부족

단일 agent 환경. 두 agent 가 자연어로 협업하는 task 는 다른 환경 필요.

Factorio domain knowledge bias

사전학습 안의 Factorio 정보량에 점수가 의존. 모델 사이의 domain bias 보정 어려움.

closed action space

정의된 tool 만 사용 가능. real-world 에이전트가 마주하는 “모르는 도구” 의 자리는 측정 안 됨.

cost

한 episode 가 수십만 token. frontier 모델로 100 episode 평가가 수백 달러. 빠른 iteration 에 부적합.

saturation 위험

새 모델이 빠르게 좋아지면 — 1년 안에 인간 baseline 도달. 다음 challenge 가 필요.

§ 09reproducibility· seed · save · trace

“같은 평가가 다음 주에도 같은 숫자를 줘야 한다”

agent eval 의 가장 큰 취약점 — non-determinism. LLM 의 stochasticity, 환경의 stochasticity, tool call 의 race condition. FLE 가 이 자리에 어떻게 답하는지.

env seed 고정

Factorio 의 map 생성 seed, biter 출현 패턴, resource 분포가 모두 seed 로 재현 가능.

save / restore

중간 save 에서 이어서 평가 가능. agent 를 같은 시점부터 재실행 가능.

trace logging

모든 (observation, action, reward) tuple 을 기록. 사후 분석으로 어디서 막혔는지 추적.

temperature 0

평가에서 LLM temperature 를 0 으로 두는 게 표준. 하지만 reasoning 모델은 sampling 이 점수에 큰 영향 — N 회 평균.

eval suite

여러 seed × 여러 task × 여러 horizon 의 조합. 단일 episode 가 아니라 distribution 으로 점수.

human verification

복잡한 task 의 “성공” 판정은 사람이 검증. metric 자동화 불가능한 자리의 fallback.

reproducibility 의 비용

모든 detail 을 reproducible 하게 만들면 평가 비용이 빨리 큰다. 실용적으로는 “핵심 metric 은 fully reproducible, 보조 metric 은 single-shot” 의 절충. agent eval 의 일반적 패턴.

§ 10기억할 메모· key takeaways

다시 열었을 때 5분 안에 손에 잡혀야 할 것

FLE 의 위치

long-horizon LLM agent 평가 환경. Factorio 의 자동화 게임 메커닉을 LLM tool-call 인터페이스로 wrap.

왜 Factorio

측정 가능한 신호 + progressive 난이도 + structured action + deterministic + 인간 baseline 풍부.

multi-dim metric

production rate · time-to-task · recovery · resource efficiency · action efficiency 의 조합.

agent loop 4 단계

observation 직렬화 → 계획 → tool call → env step. observation 표현이 성능에 직접 영향.

model 패턴

reasoning 모델이 size 보다 강함. recovery 가 모델 vs 인간의 가장 큰 격차.

RL 의 자리

tabula rasa RL 은 어렵다. LLM base + RL fine-tune 또는 trajectory 데이터 수집 환경으로의 가치.

한계

multimodal / 협업 / 비용 / saturation 위험. 단일 환경으로 다 못 잡음.

reproducibility

env seed + save + trace + temperature 0 + N 회 평균. agent eval 의 표준 패턴.

YouTube youtube.com/watch?v=iXvYa2oIMbA

Slides official repo 에 미공개

Related Factorio Learning Environment GitHub · Jack Hopkins X/Twitter · 확인 필요

손에 새기기 — 학습 시퀀스

Factorio 직접 한 번 깔아보기 — 인간 baseline 이 90% 라는 사실을 몸으로 검증. 첫 자동 채굴 라인을 직접 깔며 “LLM 이 무엇을 어려워할지” 의 직관.
FLE GitHub 의 예시 trajectory 읽기 — agent 가 만든 plan, 실패한 곳, 복구 과정의 trace 를 한 번 정독.
같은 task 두 모델 비교 — 작은 task (iron plate 100개) 를 GPT-5 와 Claude 에게 시키고 trace 를 비교. observation 표현, plan 의 길이, tool call 빈도.
단순 task 의 RL 한 번 — “자원 채굴 라인 한 개 깔기” 같은 작은 task 에 PPO 적용. 어디서 학습이 안 되는지 직접 본다.
자기 도메인 환경으로 응용 — 작은 “tool-use 평가 환경” 을 자기 분야로 깐다. 핵심: measurable signal + progressive complexity + reproducibility.

§ 11다른 강의로 이어지는 길· connections

FLE 의 자리에 등장하는 다른 강의들

L063

LLM serving systems

agent 가 만드는 throughput / latency 의 다른 모양

L071

RL infra

RL fine-tune 의 인프라 — FLE 가 데이터 source 일 때

L082

Helion DSL

agent 가 자기 코드를 짤 때 어떤 DSL 표현이 학습에 좋은가

L088

TinyTPU

학습 환경의 다른 형태 — hardware emulator 도 같은 디자인 쟁점

§ 12열린 질문· open questions

다음에 다시 들었을 때 직접 검증해야 할 것들

강의의 정확한 수치 — § 06 의 모델별 점수는 외부 자료에서 재구성한 개념적 수치. 강의 안의 실제 수치, 비교 대상 모델 정확한 list 는 영상 직접 확인 필요.
FLE 의 GitHub repo 위치 — 공식 repo, paper 의 정확한 인용. notes 에 명시 안 됨.
observation 직렬화의 best practice — ASCII vs JSON vs structured. 모델별로 다른 답을 가지는지.
agent memory pattern — summary memory + recent window 의 정확한 디자인 디테일. context limit 이 늘면 어떻게 변하는지.
RL fine-tune 결과 — FLE trajectory 로 LLM 을 RL fine-tune 한 결과가 발표 시점 기준 어디까지 갔는가.
다음 challenge — Factorio 가 saturate 되면 어떤 환경이 다음 long-horizon eval 의 후보인가.

검증 메모

이 노트는 강의 자막 실패 + repo 자료 부재 상태에서 외부 정보 + agent eval 영역의 일반 지식으로 재구성한 형태. FLE 의 정확한 인터페이스, metric 의 정확한 정의, 모델별 정확한 수치는 모두 영상 직접 확인 / GitHub repo 검토 후 보강 필요. § 06 의 막대 그래프는 “자리잡기용 형상” 이지 정확한 측정값이 아니다.

← Lecture 084 Numerics and AI Lecture 086 → Getting Started with CuTe DSL