순환 충돌(Cyclic Interaction) 오류의 본질
《엘더스크롤》과 《폴아웃》 시리즈를 비롯한 베데스다(Bethesda) 엔진 기반 모딩 환경에서 Mod Organizer 2, Vortex 또는 독립 도구로 구동되는 LOOT(Load Order Optimisation Tool)는 플러그인의 정렬 순서를 자동으로 계산해 주는 필수적인 도구입니다. 그러나 모드 리스트에 등록된 .esm, .esp, .esl 파일이 수백 개로 늘어나면 플러그인 정렬 절차를 완전히 멈춰 세우는 치명적인 붉은색 경고가 자주 발생합니다.
Cyclic interaction detected between plugins: "PluginA.esp" -> "PluginB.esp" -> "PluginC.esp" -> "PluginA.esp"
이 오류가 발생하면 LOOT는 즉시 정렬을 중단합니다. 기존 로드 오더는 최적화되지 않은 불안정한 상태로 고정되며, 새로 추가된 호환성 패치는 제자리를 찾지 못합니다. 이 상태에서 게임을 강제 실행할 경우, 필수 선행 모드 누락이나 패치 순서 역전으로 인해 메인 메뉴에서 바탕화면으로 튕기거나(CTD) 심각한 퀘스트·스크립트 데이터 오염이 발생합니다.
순환 종속성이 발생하는 그래프 이론적 배경과 LOOT의 규칙 처리 구조를 이해하면 모드 팩 전체를 재설치하거나 초기화하지 않고도 충돌 지점을 정확하게 찾아내 해결할 수 있습니다.
그래프 이론과 LOOT의 위상 정렬 알고리즘
LOOT는 단순한 어림짐작이나 임의의 우선순위로 모드를 정렬하지 않으며, 철저한 그래프 이론(Graph Theory)에 따라 계산을 수행합니다.
LOOT의 정렬 엔진은 활성화된 모든 플러그인을 **유향 비순환 그래프(Directed Acyclic Graph: DAG)**로 모델링합니다.
- 정점 (Vertex / Node): 게임 Data 폴더에 활성화된 개별 플러그인이 그래프의 각 노드가 됩니다.
- 유향 간선 (Directed Edge): "플러그인 A는 플러그인 B보다 먼저 로드되어야 한다"는 규칙은 노드 A에서 노드 B로 향하는 단방향 화살표($A \rightarrow B$)로 표현됩니다.
이 복잡한 상호 종속 관계를 게임 엔진이 읽을 수 있는 1차원 선형 목록(00부터 FE까지의 로드 번호)으로 변환하기 위해 LOOT는 **위상 정렬(Topological Sort)**을 수행합니다. 위상 정렬은 모든 유향 간선 $u \rightarrow v$에 대해 정점 $u$가 정점 $v$보다 항상 앞서 위치하도록 정점들을 한 줄로 나열하는 알고리즘입니다.
그래프 이론의 핵심 정리는 **"유향 그래프에서 위상 정렬이 가능하기 위한 필요충분조건은 유향 사이클(순환 고리)이 존재하지 않는 것"**입니다.
만약 "A는 B 앞($A \rightarrow B$)", "B는 C 앞($B \rightarrow C$)", "C는 A 앞($C \rightarrow A$)"이라는 규칙이 동시에 얽히면 시작과 끝이 맞물리는 닫힌 고리(사이클)가 생성됩니다. 이 상태에서는 모든 조건을 만족하는 선형 배치 순서가 수학적으로 존재할 수 없습니다. LOOT는 이 모순을 감지하는 즉시 "Cyclic interaction detected" 오류를 출력하고 동작을 정지합니다.
규칙의 위계: 하드 룰과 소프트 룰의 충돌
사이클의 원인을 규명하려면 LOOT가 그래프를 구축할 때 적용하는 두 단계의 규칙 체계를 파악해야 합니다.
1. 하드 룰 (Hard Rules, 절대 타협할 수 없는 구조적 규칙)
하드 룰은 게임 엔진의 물리적 요구 사항에 직결된 절대적인 제약 조건입니다. 하드 룰끼리 맞물려 사이클이 형성되면 정렬은 무조건 실패합니다.
- 마스터 플래그 (Master Flag):
.esm플래그가 지정된 플러그인은 일반.esp보다 반드시 먼저 로드되어야 합니다. - 파일 헤더 마스터 종속성 (Header Masters):
Plugin B내부 파일 헤더(File Header)의MAST(Master Files) 항목에Plugin A가 지정되어 있다면,Plugin A는 물리적으로 반드시 먼저 로드되어야 합니다. 순서가 뒤집히면 게임 구동 시 즉시 CTD가 발생합니다. - 공식 기본 파일 순서:
Skyrim.esm,Fallout4.esm등 엔진에 하드코딩된 공식 파일의 우선순위입니다. - 사용자 정의 '다음에 로드' 규칙 (User "Load After"): 사용자가 LOOT 메타데이터 편집기에서 수동으로 입력한 규칙은 최고 우선순위의 하드 룰로 취급됩니다.
- 필수 요구사항 메타데이터: 공식 마스터리스트에 등록된 필수 선행 모드 관계입니다.
2. 소프트 룰 (Soft Rules, 탄력적으로 생략 가능한 권장 규칙)
소프트 룰은 덮어쓰기 순서를 최적화하기 위한 지침이지만, 그래프 전체의 정렬 가능성을 위협할 경우 자동으로 폐기됩니다.
- 그룹 규칙 (Group Rules): LOOT는 플러그인을 단계별 그룹(Core, Bug Fixes, UI, Late Loaders 등)으로 분류합니다. 특정 그룹 규칙이 하드 룰과 부딪혀 사이클을 유발할 경우, LOOT는 그룹 규칙을 자동으로 무시합니다.
- 중복 덮어쓰기 규칙 (Overlap Rules): 두 플러그인이 동일한 레코드나 에셋을 변경할 때 적용되는 규칙으로, 하드 룰과 충돌 시 자동으로 제외됩니다.
LOOT가 소프트 룰의 사이클을 자체적으로 걸러내기 때문에, 지속적으로 발생하는 순환 종속성 오류의 99%는 하드 룰 간의 정면 충돌(물리적 파일 헤더 마스터와 사용자 수동 지정 규칙의 모순)에서 기인합니다.
순환 충돌이 발생하는 세 가지 대표적인 상황
실제 모드 환경에서 발생하는 사이클은 대부분 다음 세 가지 유형 중 하나에 해당합니다.
상황 1: 호환 패치 간의 상호 마스터 참조
여러 대형 모드를 설치하고 비공식 호환 패치를 중복 적용할 때 빈번하게 나타납니다.
- 모드 A는 베이스 X를 요구합니다.
- 모드 B는 베이스 Y를 요구합니다.
- 두 모드를 엮어주는
Patch1.esp가 실수로Patch2.esp를 마스터로 참조하고, 반대로Patch2.esp역시Patch1.esp를 마스터로 참조하도록 제작된 경우입니다. 두 파일이 서로를 선행 파일로 요구하므로 헤더 수준의 교착 상태가 형성됩니다.
상황 2: 사용자 수동 규칙과 파일 헤더 마스터의 역전
과거의 오래된 가이드를 보고 LOOT 편집기에서 플러그인 순서를 강제 지정했을 때 발생합니다.
- 사용자가 "
Armor_Patch.esp를Weather_Mod.esp뒤에 로드하라"는 수동 규칙을 넣었습니다. - 그러나
Weather_Mod.esp의 내부 파일 헤더에는Armor_Patch.esp가 선행 마스터로 등록되어 있습니다. 사용자의 인위적인 규칙과 파일 자체의 하드 마스터가 정면으로 충돌하여 사이클을 만듭니다.
상황 3: ESM 플래그 플러그인이 일반 ESP를 마스터로 참조
베데스다 엔진은 모든 ESM 플래그 플러그인이 일반 ESP보다 앞서 로드될 것을 요구합니다. 모더가 플러그인에 ESM 플래그를 부여했으나 선행 마스터 파일로 일반 .esp를 등록해 둔 경우:
- 마스터 규칙: 일반 ESP가 ESM보다 먼저 로드되어야 함.
- 엔진 플래그 규칙: ESM이 일반 ESP보다 먼저 로드되어야 함. 두 하드 룰이 충돌하며 LOOT가 순환 오류로 인식합니다.
단계별 순환 종속성 트러블슈팅 5단계
365Finds의 분석에 따르면, 순환 종속성 오류의 대다수는 LOOT 공식 마스터리스트의 결함이 아니라 사용자가 중첩해 설정한 '다음에 로드' 수동 규칙이나 서드파티 호환 패치가 실수로 서로를 마스터로 지정한 것에서 비롯됩니다. 커스텀 메타데이터를 초기화하고 xEdit에서 실제 레코드 참조를 확인하는 것만으로 모드 팩 재설치 없이 90% 이상의 정렬 교착 상태를 해결할 수 있습니다.
다음 절차에 따라 안전하게 충돌 고리를 끊어내십시오.
1단계: LOOT 오류 창에서 충돌 루프 확인
LOOT에서 경고가 발생하면 진단 창이나 상단 상태 카드에 적힌 경로 텍스트를 복사합니다.
예시:
Back cycle: ModAlpha.esp, ModBeta.esp, PatchGamma.esp, ModAlpha.esp
여기에 나열된 플러그인 목록을 메모합니다. 충돌 문제는 오직 이 고리 안에 포함된 파일들 사이에서만 발생하고 있습니다.
2단계: 사용자 지정 메타데이터 확인 및 삭제
파일을 직접 수정하기 전에 수동 규칙이 충돌을 일으켰는지 먼저 확인합니다.
- LOOT 메인 창에서 오류 고리에 포함된 플러그인을 찾습니다.
- 플러그인 이름 우측의 점 세 개 아이콘(⋮)을 누르고 **메타데이터 편집(Edit Metadata)**을 엽니다.
- 다음에 로드(Load After) 탭과 그룹(Group) 탭을 확인합니다.
- 사용자 정의로 추가된 수동 규칙이 있다면 휴지통 아이콘을 눌러 모두 삭제합니다.
- 체크 아이콘을 눌러 변경 사항을 저장합니다.
- LOOT 상단의 정렬 버튼을 다시 누릅니다. 정렬이 정상 완료된다면 수동 규칙 충돌이 원인이었습니다.
3단계: xEdit에서 물리 파일 헤더 점검
메타데이터를 삭제해도 오류가 지속된다면 플러그인 본체의 파일 헤더에 문제가 있습니다.
- 모드 관리자에서 xEdit(SSEEdit, FO4Edit 등)을 실행합니다.
- 플러그인 선택 창에서 우클릭 후 'Select None'을 선택하고, 사이클 고리에 포함된 플러그인들만 체크하여 불러옵니다(공식 마스터 ESM은 자동 로드).
- 로드가 완료되면 좌측 목록에서 해당 플러그인을 펼치고 최상단의
File Header를 클릭합니다. - 우측 화면에서
Master Files (MAST)하위 항목을 확인합니다. - 고리에 얽힌 플러그인들이 서로를 어떻게 마스터로 참조하고 있는지 대조합니다.
4단계: 'Clean Masters'로 가짜 마스터 제거
패치 제작자가 Creation Kit 작업 중 무관한 모드를 함께 불러와 실제로는 해당 모드의 레코드를 전혀 건드리지 않았음에도 마스터 항목만 불필요하게 남아 있는 경우가 많습니다.
- xEdit 좌측에서 불필요한 마스터를 참조하고 있는 것으로 의심되는 패치 플러그인을 우클릭합니다.
- 컨텍스트 메뉴에서 Clean Masters를 클릭합니다.
- xEdit이 플러그인의 전체 데이터를 검사하여 실제로 참조하는 FormID가 없다면
MAST헤더에서 해당 선행 모드를 안전하게 지워줍니다. Ctrl + S로 변경 사항을 저장하고 xEdit을 종료합니다.
5단계: 상호 배타적인 패치 정리
Clean Masters를 돌려도 마스터가 지워지지 않는다면 해당 패치가 실제로 양쪽 모드의 데이터를 모두 수정하고 있는 상태입니다.
- 이는 FOMOD 설치 시 중복 선택 등으로 인해 함께 설치해서는 안 되는 배타적 패치(예: Standalone 버전과 Merged 버전)가 동시에 활성화되었음을 뜻합니다.
- 모드 관리자에서 중복된 패치를 비활성화하거나 모드를 재설치하여 적절한 파일 하나만 남깁니다.
- LOOT를 다시 켜고 정렬을 실행합니다. 사이클이 해소되어 위상 정렬이 정상 완료되며 안전하게 로드 오더를 적용할 수 있습니다.