RHoiScribe: AI에게 HOI4를 가르치는 것이 아니라, 무언가를 망가뜨리지 않는 법을 가르치는 것

만약 당신이 Hearts of Iron IV 모드 작업을 해본 적이 있다면, 아마 매우 익숙한 종류의 좌절감을 느껴본 적이 있을 것입니다:

AI의 결과물은 완벽하게 합리적으로 보입니다.

구조도 올바르고, 구문(syntax)도 정확하며, 심지어 Paradox Script 스타일조차 설득력 있게 모방합니다.

그러고 나서 게임을 실행하면—게임은 이 모든 세계가 존재하지 않는다고 차분하게 알려줍니다.

문제는 AI가 글을 쓸 수 없어서 발생하는 경우가 거의 없습니다.

문제는 AI가 매우 중요한 사실을 무시하는 경향이 있다는 것입니다:

HOI4 모딩에서는 "올바르게 보이는 것"과 "실제로 로드되는 것" 사이에 큰 격차가 존재합니다.

RHoiScribe는 그 격차를 메우기 위해 존재합니다.

하지만 이는 대부분의 "AI 지식 강화 (AI knowledge enhancement)" 프로젝트와는 약간 다른 방식으로 작동합니다.

모델이 더 큰 핸드북을 암기하도록 만드는 대신, 모델을 당신의 작업 환경 안에 직접 배치하려고 시도합니다. 그곳에서 당신의 프로젝트는 추상적인 정보가 아니라 살아있는 시스템입니다.

RHoiScribe의 핵심은 정적인 지식의 더미가 아니라, 워크플로 지향적 (workflow-oriented) 도구 세트입니다.

단순히 전형적인 HOI4 모드 구조가 어떻게 생겼는지 설명하는 대신, 프로젝트 구조를 분석할 수 있습니다.
참조 관계(reference relationships)를 추적할 수 있어, 모델이 단일 파일 내에서뿐만 아니라 프로젝트 전체에 걸친 변경 사항의 영향을 이해할 수 있게 합니다.
중복 체크(duplication checks)를 수행하여, 겉보기에는 무해해 보이는 중복 사항이 로드 동작을 조용히 손상시키는 것을 방지합니다.
"신호등" 스타일의 정적 검증 시스템(static validation system)—초록, 노랑, 빨강—을 제공하여, 모델이 편집하기 전에 자신이 안전하게 작업하고 있는지 아니면 엔진에 민감한 영역으로 발을 들이고 있는지 알 수 있게 합니다.

그리고 아마도 더 중요한 것은, 현실적인 디버깅 워크플로(debugging workflow) 레이어를 포함하고 있다는 점입니다.

많은 AI 실패는 생성 과정 중에 발생하는 것이 아니라, 모델이 이미 위험한 영역에 진입했다는 사실을 전혀 인지하지 못하는 순간에 발생하기 때문입니다.

RHoiScribe는 모델의 추측에 의존하는 대신, 그러한 위험을 명시적으로 드러내려고 노력합니다.

똑같이 중요한 또 다른 설계 선택 사항이 있습니다:

이것은 당신의 기존 워크플로를 덮어쓰려고 하지 않습니다.

제게 있어 이것은 그 어떤 개별적인 "스마트 분석 (smart analysis)" 기능보다 더 중요합니다.

많은 도구들이 자신들이 더 나은 구조를 알고 있다고 가정하며, 따라서 프로젝트를 그에 맞춰 재구성해야 한다고 생각합니다.

하지만 실제 모드 (mod) 프로젝트는 빈 캔버스가 아닙니다. 그것들은 진화하는 생태계입니다.

명명 규칙 (Naming conventions), 폴더 구조, 역사적 결정, 그리고 "불완전하지만 안정적인" 디자인 패턴조차 시스템의 일부입니다.

RHoiScribe는 이와 반대되는 입장을 취합니다.

이 도구는 프로젝트가 "있어야 하는" 모습이 아니라, 현재 있는 그대로의 모습으로 이해하려고 노력합니다.

이상적인 구조 모델을 강요하는 대신, 이미 존재하는 구조에 적응하며 AI가 그 안에서 안전하게 작동할 수 있도록 돕습니다.

그런 의미에서, 이 도구는 당신의 엔지니어링 스타일을 교정하려는 것이 아닙니다.

AI가 그 스타일 안에서 살아남을 수 있도록 보장하려는 것입니다.

여전히 지식 계층 (knowledge layer)이 포함되어 있지만, 이는 주도적인 역할보다는 보조적인 역할을 수행합니다.

경험을 실제로 정의하는 것은, 이러한 도구들이 AI를 확신에 찬 추상화 (abstraction) 속으로 표류하게 두는 대신, 복잡한 실제 프로젝트 내에 어떻게 접지 (grounded) 시켜 유지하느냐 하는 것입니다.

저는 좋은 개발자 도구는 조용히 머물러야 한다고 항상 믿어왔습니다.

워크플로 (workflow)를 지배해서는 안 되지만, 중요한 순간에는 신뢰할 수 있어야 합니다.

RHoiScribe는 여전히 진화 중입니다. 다음 단계는 더 깊은 참조 분석 (reference analysis), 더 엄격한 정적 검증 (static validation) 규칙, 그리고 더 세밀한 디버깅 워크플로에 집중하고 있습니다. 이를 통해 HOI4 프로젝트와 함께 작업하는 AI가 단순히 영감을 얻는 수준을 넘어, 엔지니어링 인지 (engineering awareness)를 갖추도록 만드는 것이 목표입니다.

왜냐하면 이 분야에서 가장 위험한 AI는 코드를 작성하지 못하는 AI가 아니라, 자신이 무엇을 변경했는지도 모른 채 너무나 확신에 차서 코드를 작성하는 AI이기 때문입니다.

만약 이러한 방향성이 당신의 공감을 불러일으킨다면—혹은 지나치게 확신에 찬 AI 때문에 당신의 HOI4 모드가 조용히 망가지는 경험을 해본 적이 있다면—GitHub의 RHoiScribe를 확인해 보시기 바랍니다.

아직 초기 단계이지만, 이 도구는 "개념적으로만 올바른 데모" 단계에 머물지 않고 이미 실제 프로젝트에서 실행되고 있습니다.

만약 별(Star)을 남겨주고 싶다는 생각이 드신다면, 그것은 단순히 가시성을 높이는 것보다 훨씬 더 큰 도움이 됩니다. 이는 제가 가고 있는 이 방향이 계속할 가치가 있다는 것을 조용히 알려주는 신호가 됩니다.

마음껏 탐색하고, 실험해 보세요. 그리고 이상적으로는, AI가 당신의 국가를 소리 소문 없이 존재하지 않는 것으로 다시 써버리기 전에 (그 오류를) 잡아내시길 바랍니다.