에이전트들이 식량 배급 규칙과 정부를 만들었다고 해서 식량 문제가 해결된 것은 아닙니다. YC의 Minecraft 실험은 협업처럼 보이는 대화와 환경에서 확인된 성과를 분리해서 읽을 만한 사례입니다.

YC Labs와 Olam Labs의 공식 실험 기록은 GPT-6.1 Sol 에이전트 50개를 생존 월드에서 3시간 실행하고 약 5,900개 메시지를 관찰했다고 설명합니다. 첫날 밤에 전체 34회 사망 중 22회가 발생했고, 이후 에이전트들은 더 조심스러워졌습니다. 페이지는 발표 시점을 2026년 10월로 표시합니다. 이 글의 10월 30일은 자료 검토일이며, 실험을 재실행한 날짜가 아닙니다.

위험 회피가 성과인가, 정체인가

죽지 않으려고 대피하는 행동은 당장의 생존에는 맞을 수 있습니다. 그러나 목표가 문명 건설이라면 탐사와 생산을 계속 줄이는 정책은 장기 성과를 떨어뜨릴 수도 있습니다. 어느 쪽인지는 메시지의 설득력으로 판단할 수 없습니다.

실험 기록의 배급 메모에는 물건을 전달했다는 보고와 실제 수령·섭취 확인을 구분하는 과정이 나옵니다. 개발팀에도 익숙한 문제입니다. “수정했습니다”라는 응답과 테스트가 확인한 수정, “배포했습니다”라는 응답과 실제 서비스 상태는 다른 증거입니다.

다만 이 관찰만으로 인원이 많아서 실패했다거나 특정 모델이 협업을 못한다고 단정할 수는 없습니다. 동일 시드·예산·도구로 1개와 50개를 반복 비교한 통제 실험을 확인하지 못했습니다. 이 사례에서 얻을 것은 에이전트 수의 최적값보다 협업의 어떤 상태를 측정해야 하는가에 가깝습니다.

공개 하네스에서 확인한 네 가지 상태

공개 저장소의 초기 공개 커밋 775d558은 10월 29일 05:00 UTC에 기록돼 있습니다. 다음 해설은 이 커밋의 문서와 코드를 대조한 결과입니다. 공개 코드가 Civ50 실행 당시와 한 줄도 다르지 않다고 확인한 것은 아닙니다. 현재 README의 기본 모델인 Terra와 Civ50에 사용한 Sol도 구분해야 합니다.

층 실제 코드에서 확인한 동작 보장 범위에서 구분할 것
관찰 session.js가 모델 호출마다 새 관찰을 주입 다른 에이전트의 오래된 보고가 현재 세계 상태가 되지는 않음
대화 이력 같은 파일의 최근 세션 이력으로 재개 대화 복구와 세계의 외부 효과 복구는 별개
메시지 mailbox-store.js의 SQLite DM·읽음 기록 메시지를 읽었다는 기록은 작업 인수나 완료 증명이 아님
신체 행동 runtime.js의 행동 직렬화·취소 처리 한 봇의 동시 행동 제어가 여러 봇의 자원 예약까지 해결하지는 않음

관찰 훅은 transformContext이고, 재개에는 SessionManager.continueRecent를 사용합니다. 세션을 잘 저장해도 이미 수행한 외부 작업을 다시 실행할 수 있고, 메시지가 안전하게 저장돼도 두 작업자가 같은 자원을 자기 몫으로 생각할 수 있습니다. 메시지 계층의 신뢰성과 작업 계층의 신뢰성은 따로 시험해야 합니다.

공유 메모를 읽은 두 작업자가 같은 일을 시작한다면

다음은 CodeBridge가 작성한 로컬 교육용 예제입니다. Node.js 18 이상에서 ownership.mjs에 저장하고 node ownership.mjs로 실행할 수 있습니다. 추가 설치·게임 서버·모델 호출은 필요 없습니다. 두 작업자가 같은 버전을 읽었을 때 뒤늦은 인수를 거부하는 상황만 재현합니다.

const task = { revision: 0, owner: null };
const seenByAda = task.revision;
const seenByBram = task.revision;

function claim(name, expectedRevision) {
  if (task.revision !== expectedRevision || task.owner !== null) {
    return "replan";
  }
  task.owner = name;
  task.revision += 1;
  return "claimed";
}

console.log(claim("Ada", seenByAda));
console.log(claim("Bram", seenByBram));
console.log(task.owner, task.revision);

실제 로컬 실행 출력은 다음과 같습니다. YC 하네스의 실행 결과는 아닙니다.

claimed
replan
Ada 1

JavaScript 프로세스 하나에서 순서대로 실행했기 때문에 이 예제에는 분산 경쟁이 없습니다. 실제 시스템에서는 비교와 갱신을 데이터베이스의 조건부 갱신이나 트랜잭션으로 묶어야 합니다. 작업자가 죽었을 때의 임대 만료, 오래된 작업자의 쓰기를 막는 세대 번호, 이미 발생한 외부 효과의 확인도 별도로 필요합니다. 이 예제는 완성된 락 구현이 아닙니다.

대화량 대신 작업의 이동을 기록하기

팀의 멀티에이전트 실행에는 다음처럼 결과와 연결된 지표를 붙일 수 있습니다. 아래 지표는 제안이며 YC가 측정한 수치가 아닙니다.

질문 남길 기록 해석할 때의 주의점
메시지가 실제 일로 이어졌나 검증된 완료 작업당 메시지 수 완료 기준이 바뀌면 비교 불가
같은 일을 둘이 했나 동일 작업 ID·세대의 중복 실행 중복 탐색이 의도된 경우는 분리
실패 뒤 다시 움직였나 실패 관찰부터 다음 실행 가능한 계획까지의 시간 안전상 보류와 계획 불능을 구분
보고가 현실과 맞나 완료 주장과 외부 상태 검증의 불일치 “도구 호출 성공”만 완료로 삼지 않기

메시지를 줄이는 것 자체도 목표가 아닙니다. 필요한 복구 대화가 늘면서 실제 완료율이 오를 수 있기 때문입니다. 토큰 사용량·경과 시간·실패 복구 비용을 같은 작업 ID에 연결해야 비용과 성과를 함께 볼 수 있습니다. YC의 3시간과 메시지 수만으로 작업당 비용은 계산할 수 없습니다.

이 공개 프로젝트를 직접 실행할 때는 셸 경계도 읽어야 합니다. README는 환경에 따라 로컬 셸로 폴백하며 그 명령은 사용자 권한으로 실행된다고 설명합니다. 여기서는 하네스를 설치하거나 유료 모델을 호출하지 않았습니다.

이 실험의 유용한 질문은 “50개가 사람처럼 회의했는가”보다 “공유된 보고가 언제 검증된 작업 상태로 바뀌었는가”입니다. 장기 실행의 체크포인트와 재개를 설계할 때도 이 경계를 함께 두는 편이 좋습니다.

에이전트 실행·검증·역할 분담의 구조를 더 배우려면 아래 공개 유료 강의를 참고할 수 있습니다. Minecraft 실험의 재현이나 모델 접근권을 제공한다는 의미는 아니며, 링크는 홍보 링크입니다.