올바른 Shogun 2 모딩 도구를 선택하는 것은 프로젝트가 완성될지 아니면 중단될지를 결정하는 가장 중요한 요소입니다. Total War: SHOGUN 2 모딩 씬은 소수의 언패커, 테이블 에디터, 그리고 방대하게 문서화된 커뮤니티 워크플로우 위에서 돌아가기 때문입니다. 카타나 사무라이의 단일 스탯을 리밸런싱하거나, 유닛 로스터를 Fall of the Samurai 오버홀용으로 교체하거나, 완전한 토탈 컨버전을 만드는 것이 목표이든, 동일한 소수의 유틸리티가 계속해서 등장합니다. 이 가이드는 각 도구가 실제로 무엇을 하는지, 빌드 파이프라인에서 어디에 위치하는지, 그리고 Complete Edition 빌드와 2011년 레거시 빌드가 서로 충돌하지 않도록 관리하는 방법을 안내합니다. 모딩 계층에서도 동일한 중복을 발견할 수 있는데, Shogun 2 Rise Of The Samurai Mods는 동일한 캠페인 프레임워크가 실제로 클래식 에디션과 Complete Edition 설치본을 모두 지탱하는 방식을 보여줍니다.
모딩 스택 한눈에 보기
어떤 도구를 열기 전에 전체 스택을 파이프라인으로 파악해두는 것이 도움이 됩니다. 모든 Shogun 2 모드는 최소 세 가지 계층에 관여합니다: 게임 데이터를 담고 있는 압축된 팩 파일, 유닛 스탯, 건물 체인, 캠페인 스크립팅을 구동하는 데이터베이스 테이블, 그리고 런처와 Workshop이 완성된 제품을 게시할 때 사용하는 프론트엔드 파일이 그것입니다. 각 계층마다 도구가 존재하며, 초보자가 겪는 대부분의 마찰은 데이터베이스에서 편집해야 할 것을 팩 파일 도구로 편집하려 하거나, 그 반대의 경우에서 발생합니다.
| 계층 | 포함 내용 | 주요 도구 | 형식 |
|---|---|---|---|
| 팩 파일 | 텍스처, 메시, UI, 오디오, 스크립트 이벤트 | Pack File Manager / RPFM | .pack (Caesar IV / Empire 시대 아카이브) |
| 데이터베이스 | 유닛 스탯, 건물 체인, 테크 트리, 진영 | DB 에디터 (TWC DBTable / RPFM 테이블 뷰) | .db (SQLite 방식) |
| 프론트엔드 | Workshop 메타데이터, 로드 순서, 모드 매니저 | Steam Workshop + 인게임 모드 매니저 | .info, .vmod |
| 스크립팅 | 캠페인 이벤트, 미션 스크립팅, AI 훅 | Notepad + schema.xml 참조 | 팩 내부의 .lua 방식 트리거 |
| 현지화 | 모든 UI 요소의 문자열 테이블 | 스키마 인식 CSV 에디터 | 팩 파일 내부의 loc 테이블 |
첫 프로젝트는 데이터베이스와 팩 파일 계층만 다루는 것이 깔끔합니다. 스크립팅과 현지화 계층은 그 이후, 즉 모더가 새로운 메커니즘을 추가하거나, 캠페인 이벤트를 분기하거나, 재구성된 Complete Edition 클라이언트를 위해 커스텀 유닛 이름을 일본어와 중국어로 번역해야 할 때 다루게 됩니다.
스택이 이런 모습을 띠는 이유
Creative Assembly의 엔진 계열은 Empire, Napoleon, 그리고 두 개의 Total War: SHOGUN 2 캠페인에서 도구를 공유합니다. 그렇기 때문에 동일한 팩 파일 형식이 Rise of the Samurai, 기본 1530년 센고쿠 캠페인, 그리고 Fall of the Samurai의 1864년 보신 전쟁 배경을 모두 커버합니다. DB 테이블은 유닛 카드, 건물 효과, 진영 보너스에 대해 공통 스키마를 공유하므로, 기본 게임에서 Shimazu를 위한 리밸런스는 근대화된 유닛 로스터에 맞춘 사소한 조정만으로 Fall of the Samurai 서브 모드로 이식되는 경우가 대부분입니다. 이러한 공유 백본이 있기에 베테랑 모더들은 방대한 도구 세트 대신 한두 가지 핵심 도구를 추천하는 경향이 있습니다. 의도와 바이너리 사이의 변환 단계가 적을수록 QA에서 걸리는 예외 사례도 줄어들기 때문입니다.
팩 파일 편집: 모든 모드의 시작점
팩 파일 편집은 모든 Total War: SHOGUN 2 모드의 기반 계층입니다. 게임은 거의 모든 것 — 텍스처, 모델, UI 레이아웃, 오디오 큐, 스크립트 전투 — 을 설치 디렉터리의 data 폴더 아래에 있는 압축된 .pack 아카이브 안에 저장합니다. 팩을 언팩하고, 파일을 교체하고, 깔끔하게 리팩할 수 있는 모더라면 데이터베이스 행을 하나도 건드리지 않고도 텍스처 오버홀, 유닛 리스킨, 사운드 교체를 게시할 수 있습니다.
이 계층을 지배하는 두 가지 도구는 Pack File Manager(흔히 PFM으로 줄여 부르며, TWC 모딩 커뮤니티가 오랫동안 유지 관리해온 커뮤니티 유틸리티)와 Rust로 작성된 더 최신의 크로스 플랫폼 후속작인 **Rusted PackFile Manager (RPFM)**입니다. 둘 다 .pack 아카이브를 직접 열고, 보고, 편집할 수 있으며, 게임의 내부 폴더 구조를 이해합니다. 즉, 에디터 내 올바른 가상 폴더에 드래그한 파일이 아카이브 내 올바른 위치에 배치됩니다.
| 기능 | Pack File Manager | Rusted PackFile Manager |
|---|---|---|
| 플랫폼 | Windows | Windows / macOS / Linux |
| 활성 개발 | 유지 보수 모드 | 활성, 잦은 업데이트 |
| 스키마 인식 | 제한적 | 자동 완성이 포함된 전체 DB 스키마 |
| 팩 편집 | 가능 | 가능 |
| DB 테이블 편집 | 불가 (외부) | 내장 |
| 적합한 용도 | 레거시 호환성 | 신규 프로젝트 |
2026년의 완전히 새로운 프로젝트라면 RPFM이 더 나은 출발점입니다. 통합 테이블 뷰를 함께 제공하고 Creative Assembly가 데이터를 조정할 때마다 스키마 업데이트를 추적하기 때문입니다. 기존 2011년대 빌드와 함께 출시해야 하는 모드의 경우, Pack File Manager가 순수 호환성 면에서 때때로 우위를 점합니다. 일부 오래된 모드 팩은 PFM의 특정 특성에 맞춰 제작되었기에 RPFM을 거치면 경고 없이는 정상적으로 왕복되지 않기 때문입니다. 대부분의 모더는 둘 다 설치해두고, 문제의 팩을 깔끔하게 열어주는 쪽을 골라 사용합니다.
깔끔한 팩 편집 워크플로우
전형적인 첫 팩 편집은 대략 이렇게 진행됩니다: 변경하려는 파일이 담긴 팩을 찾고(유닛 텍스처라면 거의 항상 roman_imperial.pack 또는 특정 진영용 형제 팩), RPFM으로 열고, 교체 파일을 일치하는 가상 경로에 드래그하고, 원본이 손대지 않도록 새 이름으로 팩 사본을 저장하고, 이름을 바꾼 그 팩을 새 모드 디렉터리의 data 폴더에 넣고, Workshop 업로더에서 결과를 구독합니다.
여기서 많은 수고를 덜어주는 두 가지 규칙이 있습니다. 첫째, 절대 팩을 그 자리에서 편집하지 마세요. 항상 복사하고, 이름을 바꾸고, 사본을 편집하세요. 손상된 팩 하나가 런처를 멈추게 하고 검증을 강제할 수 있습니다. 둘째, 원본 파일명 구조를 그대로 유지하세요. 엔진은 많은 에셋을 정확한 경로로 해석하며, ui/skill_icons/에 배치된 텍스처는 UI/Skill_Icons/에 있으면 인식되지 않습니다. 대부분의 플랫폼에서 팩 파일 조회는 대소문자를 구분하기 때문입니다.
DB 에디터: 스탯과 시스템이 사는 곳
팩 파일 편집이 기반이라면, 데이터베이스 에디터는 구조 골조입니다. 플레이어가 보는 모든 수치 — 야리 아시가루의 근접 공격력, 조총 아시가루의 비용, 성 영지가 방어에 부여하는 보너스 — 는 DB 테이블에 담겨 있으며, 이 수치를 바꾸는 것이야말로 대부분의 모더가 말하는 "진짜 모딩"입니다. 이 계층의 커뮤니티 표준은 수년간 변화해왔지만, 현재의 모범 사례는 가벼운 편집에는 RPFM의 내장 테이블 뷰를, 무거운 스키마 작업에는 TWC DBTable 에디터(오랫동안 유지 관리해온 Althaea의 이름을 따 Althaea 에디터라고도 불림)를 사용하는 것입니다.
단일 유닛에 대한 DB 테이블 편집은 보통 이렇게 진행됩니다: RPFM 안에서 units_tables DB를 열고, 키(예: yari_ashigaru)로 유닛을 필터링하고, melee_attack, melee_defence, 또는 cost 열을 변경하고, 저장하고, 리팩합니다. 이 변경은 유닛이 참조되는 모든 곳에 전파되며, Fall of the Samurai 서브 모드도 포함됩니다. 두 캠페인이 대부분의 핵심 유닛에 대해 기반 스키마를 공유하기 때문입니다.
알아둘 가치가 있는 핵심 테이블
| 테이블 | 담고 있는 것 | 일반적인 모드 활용 |
|---|---|---|
units_tables | 유닛별 스탯, 비용, 모집 건물 | 리밸런스, 스탯 조정 |
unit_stats_land | 육상 유닛 전투 속성 | 전투 오버홀 |
building_chains | 영지 건물 트리, 효과 | 경제 오버홀 |
technologies | 연구 트리, 예술의 정수 | 테크 리밸런스 |
factions | 가문 시작 위치, 보너스, 특성 | 신규 진영 |
campaign_map | 전략 계층의 맵 데이터 | 맵 오버홀 |
battle_set_pieces | 거점과 전장 레이아웃 | 공성전 오버홀 |
흔한 첫 프로젝트는 단일 저활용 유닛의 리밸런싱입니다. 예를 들어 노다치 사무라이에 약간의 근접 방어 버프를 주어 Takeda 스택에서 중간 티어 옵션으로 쓸 수 있게 만드는 것입니다. 이 변경은 전적으로 units_tables 내부에서 이루어지며, 5분이면 끝나고, 플레이어가 바로 다음 캠페인 턴에서 체감할 수 있는 결과를 만들어냅니다.
초보자를 위한 DB 에디터 워크플로우
DB 에디터를 한 번도 열어본 적 없는 사람에게 가장 저항이 적은 경로는 이렇습니다: RPFM을 설치하고, 스키마를 읽을 수 있도록 Shogun 2 설치 디렉터리를 지정하고, units_tables를 열고, 변경하려는 유닛을 찾고, 수치 하나를 편집하고, 저장하고, 게임을 실행하고, 결과를 확인합니다. 이 단일 루프만으로 팩 리패키징, 스키마 마이그레이션, 로드 순서 관리를 한꺼번에 배우는 부담 없이 워크플로우를 익힐 수 있습니다.
그 루프에 익숙해지면, 다음 단계는 동일한 패치에서 관련 테이블을 함께 변경하는 것입니다. units_tables에서 유닛의 모집 비용을 올리고, building_chains에서 건물 요구 사항을 조정하고, 리밸런스가 특정 테크를 통해 전개되도록 설계되었다면 technologies에서 작은 보너스를 부여하는 것입니다. 이 패턴은 모드가 버전 관리와 변경 로그 노트로 추적되는 조율된 변경 사항들의 작은 생태계가 될 때까지 반복되며, 그래야 다른 모드와의 충돌을 완전한 삭제 없이도 진단할 수 있습니다.
모드를 끝까지 완성하기: 아이디어에서 Workshop까지
첫 완성 모드 — 작은 유닛 팩이나 집중적인 리밸런스 — 는 워크플로우를 배우기에 적절한 범위입니다. 스크립팅이나 현지화를 끌어들이지 않으면서 모든 계층을 실습할 수 있기 때문입니다. 초보자 모드 프로젝트의 현실적인 엔드투엔드 파이프라인은 다음과 같습니다: 한 페이지 설계 문서로 범위를 정의하고, data/ 아래에 모드 폴더를 만들고, Pack File Manager와 RPFM을 모두 설치하고, 변경할 테이블과 팩을 파악하고, 작은 커밋 단위로 변경하고, 리팩하고, 인게임에서 테스트하고, 반복하고, 마지막으로 Steam Workshop 업로더를 통해 게시합니다.
올바른 범위 선택
범위는 첫 프로젝트가 주말 안에 완성될지, 3개월째에 죽을지를 결정하는 변수입니다. 단일 유닛, 단일 건물, 또는 단일 테크놀로지를 다루는 모드는 현실적인 첫 프로젝트입니다. 이 세 가지에 커스텀 UI와 캠페인 이벤트까지 더하는 모드는 잘 정체되기 쉽습니다. 계층이 하나 추가될 때마다 QA 부담이 곱해지기 때문입니다. 커뮤니티 경험도 이를 뒷받침합니다. Workshop에 있는 오래 지속되는 Shogun 2 모드 대부분은 범위가 좁은 밸런스 오버홀이거나 5인 이상 팀이 만든 대형 토탈 컨버전이며, 그 중간 지점에서 성공한 프로젝트는 의외로 적습니다.
유용한 경험 법칙은 모드를 한 문장으로 설명할 수 있는지 스스로에게 묻는 것입니다. "노다치 사무라이의 근접 방어를 5 올리고 모집 비용을 50 코쿠 줄인다"는 훌륭한 첫 프로젝트입니다. "역사적으로 정확한 병력 비율로 센고쿠 시대 전체를 리밸런싱한다"는 팀이 필요한 5년짜리 연구 프로젝트입니다. Workshop은 전자에 보상을 주고 후자를 묻어버립니다. 플레이어는 집중된 모드를 단일 캠페인으로 검증하고 모호함 없이 구독하거나 구독 해제할 수 있기 때문입니다.
버전 관리, 로드 순서, 모드 매니저
모드가 단일 파일 이상이 되는 순간, 버전 관리가 핵심 엔지니어링 문제가 됩니다. Steam Workshop은 배포를 처리하지만 시맨틱 버저닝을 강제하지 않으며, 내장 의존성 해결기도 없습니다. 따라서 다른 모드의 프레임워크에 의존하는 모드는 설명에 그 의존성을 명시하고 플레이어가 읽어주기를 바랄 수밖에 없습니다. 로드 순서는 동일한 테이블을 다루는 모드에서 중요합니다. 마지막에 로드된 팩이 보통 승리하며, 구독자에게 밀린 깨진 모드는 구독 해제할 때까지 게임을 비활성화할 수 있기 때문입니다.
실용적인 로드 순서 관리에는 런처에서 접근할 수 있는 인게임 모드 매니저가 적합한 도구이며, 최근 모드 매니저 활성화 워크스루는 해당 옵션이 잠시 숨겨졌던 2023년 5월 패치 변경 사항을 다룹니다. 기본 규칙은 다음과 같습니다: 프레임워크 모드를 먼저 로드하고, 그다음 콘텐츠 모드, 그다음 비주얼 오버라이드를 로드하며, 동일한 DB 테이블을 편집하는 두 모드를 병합 테스트 없이 동일한 로드 위치에 두지 마세요.
2026년의 Shogun 2 모딩 커뮤니티
커뮤니티는 도구와 데이터와 더불어 스택의 세 번째 기둥입니다. 질문하고, 스키마 발견을 공유하고, 호환성 테스트를 조율할 장소가 없다면, 도구를 잘 갖춘 모더라도 구글에서 찾을 수 없는 첫 번째 오류 앞에서 멈춥니다. 다행히 Shogun 2 모딩 커뮤니티는 2026년까지 활발하게 유지되어 왔으며, 최근의 Complete Edition 재구축은 2011년부터 동일한 팩 파일로 작업해온 베테랑들과 함께 첫 모드를 게시하는 새로운 기여자들의 물결을 가져왔습니다.
커뮤니티가 실제로 모이는 곳
| 리소스 | 제공하는 것 | 적합한 용도 |
|---|---|---|
| Steam Workshop | 원클릭 설치, 자동 업데이트 | 모드 구독 |
| Mod.io (Complete Edition 내) | 인게임 브라우저, Steam 오버레이 불필요 | 런처 내 모드 탐색 |
| TWC 포럼 | 깊이 있는 기술 스레드, 스키마 문서 | 도구 관련 질문 |
| Reddit r/totalwar | 모드 쇼케이스, 밸런스 토론 | 노출과 피드백 |
| YouTube 튜토리얼 | 일반적인 편집의 시각적 워크스루 | 첫 설정 |
| Discord 서버 | 실시간 문제 해결 | 빠른 질문 |
초보자에게 가장 중요한 리소스는 TWC(Total War Center) 포럼의 고정된 모딩 가이드입니다. 어떤 도구도 경고해주지 않는 스키마 특성들을 다루기 때문입니다. 예를 들어, units_tables에 새 항목을 추가할 때 unit_stats_land에 일치하는 행이 없으면 해당 유닛이 처음 모집될 때 하드 크래시가 발생한다는 점, 또는 Fall of the Samurai 캠페인에는 별도로 편집해야 하는 자체 units_tables 오버라이드 세트가 있다는 점 등입니다.
Complete Edition 재구축에 대한 참고 사항
Complete Edition은 최신 하드웨어를 위해 Shogun 2 클라이언트를 재구축했으며, Total War: SHOGUN 2 Complete Edition 공식 스토어 페이지에 따르면 재작업된 조명, 4K UI 스케일링, 새로운 일본어 및 중국어 음성 연기가 포함되어 있습니다. 이 재구축은 파일 레이아웃에 영향을 미쳤고, 그 결과 소수의 레거시 모드 — 특히 UI 스케일링 테이블을 편집했거나 특정 폰트 파일에 의존했던 모드 — 가 2026년 업데이트 이후 로드되지 않게 되었습니다. 2011년 Steam Workshop 카탈로그는 여전히 토탈 컨버전, 리얼리즘 오버홀, 블러드 모드, 유닛 팩의 방대한 백 카탈로그를 호스팅하고 있으며, Complete Edition의 Mod.io 브라우저가 그 위에 인게임 계층을 추가하므로, 대부분의 모드는 어느 한 경로로는 접근 가능합니다.
모더에게 실질적인 시사점은, 새 프로젝트를 게시하기 전에 레거시 2011 빌드와 Complete Edition 클라이언트 양쪽에서 테스트해야 한다는 것입니다. 한쪽에서는 작동하고 다른 쪽에서는 깨지는 모드는 잠재 구독자의 절반을 잃게 되기 때문입니다. 특히 Fall of the Samurai 서브 모드는 명시적인 호환성 확인이 필요합니다. 보신 전쟁 캠페인은 새로운 영지(홋카이도, 다네가시마, 쓰시마, 고토)를 추가하고 턴 구조를 1년에 24턴, 계절당 6턴으로 변경했기 때문에, 장기 캠페인에서 군대의 이동 방식과 소모의 누적 방식이 달라집니다.
자주 묻는 질문
Shogun 2 모딩을 시작하기 위한 최소 도구 세트는 무엇인가요?
초보자는 Rusted PackFile Manager와 텍스트 에디터만으로 시작할 수 있습니다. RPFM이 팩 파일 편집과 DB 테이블 조회를 하나의 애플리케이션에서 모두 처리하기 때문입니다. 배포를 위한 Steam Workshop 업로더와 팩 외부 텍스트 편집을 위한 Notepad++ 또는 VS Code를 추가하면, 열기-편집-저장-테스트의 기본 루프가 유료 소프트웨어 없이도 완비됩니다.
Shogun 2 모드는 2011 빌드와 Complete Edition 양쪽에서 작동하나요?
대부분의 모드는 작동하지만, Complete Edition 재구축이 파일 레이아웃을 변경하고 새로운 UI 스케일링을 추가했기 때문에, 폰트 파일, 특정 UI 테이블, 또는 4K 에셋을 다룬 모드는 때때로 로드에 실패합니다. 양쪽을 대상으로 하는 모드는 게시 전에 각 클라이언트에서 테스트해야 하며, Workshop 설명에 어떤 빌드가 지원되는지 명확히 적어두어야 합니다.
Shogun 2 DB 스키마에 대한 문서는 어디서 찾을 수 있나요?
TWC 모딩 포럼이 가장 완전한 스키마 문서를 호스팅하며, 고정된 스레드에서 각 테이블의 용도, units_tables와 unit_stats_land의 관계, 그리고 Fall of the Samurai 전용 오버라이드를 다룹니다. RPFM 내부의 스키마가 두 번째로 좋은 참고 자료입니다. 라이브 게임 파일에서 자동 완성되고 Creative Assembly가 패치할 때마다 최신 상태로 유지되기 때문입니다.
기본 게임과 별개로 Fall of the Samurai를 모딩하는 것이 가능한가요?
네, Fall of the Samurai는 자체 캠페인 맵, 근대화된 변형이 포함된 자체 유닛 로스터, 자체 테크 트리를 사용하지만, 기본 1530년 센고쿠 캠페인과 기반 팩 파일 형식과 대부분의 DB 스키마를 공유합니다. Fall of the Samurai를 대상으로 하는 모드는 해당 캠페인이 활성화되어 있을 때만 로드하면 되며, 모드 매니저를 통해 플레이어가 캠페인별로 필터링하여 충돌을 피할 수 있습니다.
Creative Assembly 패치 이후 Shogun 2 모드가 깨지는 원인은 무엇인가요?
패치 이후의 대부분의 문제는 스키마 변경에서 비롯됩니다. Creative Assembly가 units_tables 또는 building_chains의 열을 추가하거나 이름을 바꾸면, 이전 열을 참조하던 모드가 로드 시 크래시됩니다. 완화 방법은 TWC 모딩 공지를 구독하고 주요 패치 후 일주일 이내에 호환 업데이트가 있는지 확인하거나, RPFM에서 안정적인 스키마 기준으로 모드를 제작하고 모드 설명에 해당 스키마를 명시하여 구독자가 모드가 어떤 빌드에 고정되어 있는지 알 수 있도록 하는 것입니다.