GPT-5.6의 Factorio 완주, 성공과 자동화 품질은 별개

13.5시간은 무엇을 뜻하나

개발자 Ryan Madden은 10월 31일 GPT-5.6 Sol의 Factorio 실행 기록을 공개했다. 글에 따르면 Codex에서 낮은 사고 수준으로 실행한 모델이 적의 공격이 없는 평화 모드에서 로켓 발사까지 도달했다. 소요 시간으로 제시된 13.5시간은 게임 내부 시간이다. 실제 경과 시간, 토큰 사용량, API 비용으로 바꿔 읽을 수 없다.

이 사례는 긴 작업을 수행하는 에이전트가 생산망을 확장하며 목표를 달성했다는 관찰로서 의미가 있다. 동시에 한 작성자가 공개한 실행 사례이며, 여러 시드에서의 성공률이나 다른 모델과 동일 조건으로 비교한 순위표는 아니다. 모델 이름과 실행 조건도 작성자의 설명에 따른다.

Factorio는 원료 채굴, 가공, 전력, 연구, 물류를 연결하는 게임이다. 로켓 사일로 안내는 목표에 이르기까지 여러 생산 요소가 필요함을 보여준다. 짧은 질의에 답하는 시험과 달리 앞 단계의 배치가 훗날의 병목으로 되돌아오는 환경이라는 점에서 장기 계획을 관찰하기 좋다.

인터페이스와 평화 모드가 평가 범위를 정한다

이번 실행은 화면을 보고 마우스를 움직이는 방식이 아니었다. 작성자는 게임 매니저와 작은 Python 라이브러리를 통해 모델이 게임에 프로그램 방식으로 접근하도록 했다고 설명한다. 캐릭터의 도달 범위와 전장의 안개처럼 사람이 GUI에서 받는 제약을 유지했다는 것이 작성자의 설명이다.

Factorio 런타임 API 문서는 게임 상태와 동작을 프로그램으로 다룰 수 있는 배경을 제공한다. 다만 공식 API 설명만으로 이번 실험 도구의 모든 제한이 검증되지는 않는다. 프로그램 인터페이스가 제공하는 관찰 정보와 행동 단위는 결과에 큰 영향을 주므로, 재현하려면 해당 도구와 설정도 함께 확인해야 한다.

또한 맵 생성 설정 문서가 설명하는 것처럼 환경 조건은 플레이 난도를 바꾼다. 이번 결과를 공격 대응이 필요한 환경이나 사람과 동일한 조작 부담을 갖는 컴퓨터 사용 능력으로 일반화하기는 어렵다. 평화 모드를 고른 것은 실험의 결함이라기보다 측정 대상이 생산과 물류에 집중됐다는 뜻에 가깝다.

완주는 했지만 공장은 완전히 자동화되지 않았다

가장 흥미로운 대목은 성공 장면보다 후반부다. Madden은 모델이 일부 생산 시스템을 제대로 연결하지 못했고, 공장 구역 사이에서 물자를 반복적으로 운반해 로켓 발사에 도달했다고 썼다. 여기서 반복 운반의 주체는 모델이다. 글의 표현을 사람이 대신 물자를 날랐다는 의미로 읽어서는 안 된다.

즉, 목표 달성과 구조적 해결 사이에 간격이 있었다. 에이전트가 즉시 필요한 재료를 옮기면 다음 단계는 진행된다. 그러나 병목이 된 운송 체계를 고치지 않으면 같은 운반을 계속해야 한다. 이는 업무 자동화에서 임시 스크립트와 재시도로 결과물을 만들지만 지속 가능한 운영 절차를 남기지 못하는 상황과 닮았다.

이 구분이 중요한 이유는 게임의 승리 조건과 기업의 도입 기준이 다르기 때문이다. 기업에서는 한 번 완료한 작업보다 다음 달에도 같은 비용과 신뢰도로 반복할 수 있는 작업이 더 가치 있을 수 있다.

한국 개발팀이 가져갈 것은 점수보다 평가 설계다

YC의 게임 에이전트 실험은 여러 에이전트의 조율 문제를 보여줬다. 이번 사례는 한 에이전트라도 생산 구조를 일관되게 유지하는 일이 어렵다는 점을 보탠다. 에이전트를 늘리기 전에 어떤 상태를 관찰하고 어떤 병목을 고치도록 보상하는지부터 정해야 한다.

도입 실험에서는 완료 여부, 반복 작업량, 오류 후 복구, 운영자 개입을 따로 기록하는 편이 좋다. 예를 들어 데이터 처리 에이전트가 누락 자료를 매번 수동 경로로 보충한다면 최종 보고서가 완성돼도 파이프라인 품질은 낮을 수 있다. 이는 이번 게임 실행에서 도출한 적용상의 해석이지 업무 환경에서 검증된 성능 수치는 아니다.

Cursor Agent SDK의 이벤트 재생과 리뷰처럼 행동 기록을 남기면 완료 직전의 화면만으로는 보이지 않는 낭비를 찾을 수 있다. DAYJOB Tax 평가 분석이 강조한 것처럼 최종 답안과 판단 과정의 요구 조건도 분리해야 한다.

경쟁 관점에서 이번 사례는 범용 모델과 도구 계층을 함께 보는 계기다. 모델을 바꿨을 때 성능이 좋아져도 관찰 인터페이스나 상태 요약 방식이 동시에 바뀌었다면 개선 원인을 한쪽에만 돌리기 어렵다. 다음 검증은 같은 환경에서 여러 번 실행하고, 완료뿐 아니라 유지 가능한 자동화 구조가 만들어졌는지 비교하는 것이다.

FAQ

13.5시간 동안 실제 컴퓨터를 계속 돌렸다는 뜻인가?

본문이 명시한 것은 게임 시간이다. 실제 경과 시간과 계산 비용은 별도 자료 없이는 확정할 수 없다.

모델이 사람처럼 화면을 보며 조작했나?

작성자에 따르면 Python 라이브러리를 통한 프로그램 방식의 상호작용이었다. 화면 기반 조작 시험과 동일시하면 안 된다.

사람이 마지막에 대신 완주했나?

글은 모델이 반복적으로 물자를 운반했다고 설명한다. 이를 사람의 대리 플레이로 해석할 근거는 없다. 다만 모든 개입 여부를 검증한 독립 감사는 아니다.

다른 모델보다 낫다는 증거인가?

이전 시도보다 나아졌다는 작성자의 관찰은 있다. 동일 조건의 반복 비교와 통계가 없으므로 일반 순위로 볼 수는 없다.

업무용 에이전트에 가장 중요한 교훈은 무엇인가?

목표 완료와 운영 품질을 따로 측정해야 한다. 반복 보충 작업, 복구 비용, 사람이 관리해야 할 부분까지 포함해야 도입 판단에 도움이 된다.