벨트 갱신 순서가 멀티스레드의 벽이 될 때

병렬화 전에 실행 결과가 같아야 합니다

Factorio의 Friday Facts #364는 2021년 1월 29일 공개된 1.1 안정 버전의 개발 기록입니다. 이 글에서 살펴볼 부분은 운송 벨트 갱신을 여러 스레드로 나누면서 멀티플레이의 결정성을 유지한 방법입니다. 2026년의 새로운 엔진 기능이 아니라 기존 게임 구현에서 얻을 수 있는 기술 사례입니다.

벨트가 만나는 지점에서는 어느 운송 라인을 먼저 갱신했는지에 따라 물체의 앞뒤 순서가 바뀔 수 있습니다. 단순히 모든 라인을 동시에 실행하면 성능보다 결과의 불일치가 먼저 문제가 됩니다. 개발팀은 서로 영향을 주지 않는 운송 라인을 그룹으로 묶고, 서로 다른 그룹을 병렬로 처리하는 방향을 선택했습니다.

연결이 바뀌면 그룹도 바뀝니다

플레이어가 벨트나 분배기를 만들고 돌리면 연결 관계가 달라집니다. 개발 일지는 상호작용하게 된 그룹은 즉시 합쳐야 하지만, 분리 가능한 그룹을 다시 나누는 작업은 늦춰도 된다고 설명합니다. 서로 영향을 주는 그룹을 따로 실행하면 경쟁 상태가 생길 수 있지만, 독립된 부분을 한 그룹에 잠시 남겨 두는 것은 우선 성능상의 문제이기 때문입니다.

이 구분은 데이터 구조 갱신의 우선순위를 정할 때 유용합니다. 정확성을 위해 지금 반영해야 하는 변화와 병렬성을 더 얻기 위해 나중에 반영해도 되는 변화를 분리할 수 있습니다. 다만 모든 작업 시스템에 같은 규칙을 그대로 적용할 수 있는 것은 아니며, 실제 공유 상태를 먼저 찾아야 합니다.

벨트 밖의 공유 상태도 처리합니다

Factorio에서는 다른 그룹의 두 운송 라인이 같은 투입기를 깨울 수 있습니다. 즉 라인끼리 직접 물체를 교환하지 않아도 투입기 활성화라는 공유 상태가 남습니다. 공개된 설계는 작업 스레드가 즉시 깨우지 않고 요청 목록에 적은 뒤, 모든 작업이 끝나면 메인 스레드가 그룹 갱신 순서에 따라 처리하는 방식입니다.

독립적인 기술 자료인 Gaffer On Games의 결정적 록스텝 설명도 같은 초기 상태와 입력에서 정확히 같은 결과가 필요하다고 강조합니다. 실행 순서가 달라져 생기는 작은 차이가 누적될 수 있다는 점에서 참고할 만합니다. 이 자료는 Factorio 구현을 검증한 보고서는 아니며 결정성이라는 일반 원리를 보충하는 근거입니다.

속도와 재현성을 따로 시험합니다

내 시뮬레이션에서는 동일한 초기 상태와 틱별 입력을 저장하고 스레드 수를 바꿔 실행해 볼 수 있습니다. 최종 화면뿐 아니라 틱마다 정규화한 상태의 체크섬을 비교하면 처음 달라지는 지점을 찾기 쉽습니다. 작업 도중 연결을 합치거나 끊는 입력, 여러 그룹이 같은 대상을 활성화하는 입력도 포함하는 것이 좋습니다.

개발 일지의 성능 결과는 특정 대형 공장 사례에서 나온 것이므로 다른 게임의 보장치로 옮기지 않았습니다. 이 글에서는 실제 Factorio를 실행하거나 멀티스레드 벤치마크를 재현하지 않았습니다. 병렬 처리의 목표는 스레드를 많이 쓰는 일이 아니라 같은 결과를 더 적은 시간에 얻는 일이라는 관점에서 읽을 수 있습니다.

출처

• Factorio 개발 일지 #364 · 2021년 사례
• Gaffer On Games · 결정적 록스텝의 원리