작성: COZYGONO 개발·편집팀 · 수정:
강호의 도리 개발 노트: 명령과 결과를 나누어 문파의 기록 지키기
문파의 이야기가 이어지려면 저장된 결과가 흔들리지 않아야 합니다. 현재 아키텍처 문서를 바탕으로 명령·정산·이벤트 기록을 나누는 이유와 검토 방법을 소개합니다.
- 탭 A가 오전 10시에 인물 정보(무공 1성)를 읽어 메모리에 보관
- 오전 10시 30분, 서버 정산이 돌아 인물 무공이 2성으로 승급
- 오전 11시, 탭 A에서 단순 배치 순서만 변경 후 저장 요청
- 탭 A가 들고 있던 옛 사본(무공 1성)이 통째로 기록되며 승급 내역 증발
- 인물 정본: 능력치·무공 경지는 서버 정산(Settlement)과 수련 명령만 수정 가능
- 문파 운영 정본: 배치·표시 순서 변경은 해당 필드만 부분 패치(Partial Patch)
- 실행 원장(Append-Only): 모든 정산 결과를 결정 ID와 함께 이력으로 보존해 복구 가능성 확보
1. 세계관이 쌓이는 곳은 상태 기록이다
문파의 무공, 인물 관계, 수련 결과는 다음 선택의 출발점입니다. 이전에 얻었던 결과가 사라지거나 같은 명령이 두 번 적용되면 숫자 문제에 그치지 않고 플레이어가 이해하던 이야기도 끊어집니다. 강호의 도리에서 오래 지속되는 세계를 만들려면 연출과 함께 기록의 경계를 설계해야 합니다.
2. 현재 설계 문서가 나누는 책임
2026년 9월 4일 확인한 아키텍처 문서는 인물·문파·관계 등의 현재 상태와 실행 원장을 구분합니다. 서버 권한 모드에서는 화면이 결과를 직접 덮어쓰는 대신 명령을 만들고, 처리 경로가 변경 결과를 기록하는 구조를 설명합니다. 무엇을 시도했는지와 무엇이 실제로 적용됐는지를 별개의 정보로 보존하려는 선택입니다.
명령 목록은 의도이고 현재 상태는 적용된 결과입니다. 둘이 같을 것이라고 가정하지 않으면 처리 중이거나 거절된 명령도 설명할 수 있습니다. 여기서 읽은 설계는 게임의 모든 화면이 항상 같은 운영 모드라는 주장이 아닙니다. 실제 적용 여부는 현재 모드와 해당 기능의 처리 경로를 함께 보아야 합니다.
3. 필요한 부분만 기록하는 이유
문서에는 변경된 필드와 실행 시점의 패치·이벤트를 함께 기록하는 원칙이 있습니다. 예를 들어 배치 순서를 바꾸는 동작이 인물의 수련 결과까지 다시 저장한다면 오래된 화면이 최신 수련을 덮어쓸 수 있습니다. 배치 변경은 배치에 필요한 값만 건드리고, 수련 결과는 정산 경로의 책임으로 남기는 편이 추적하기 쉽습니다.
이것은 소유권을 명확히 하는 문제입니다. '저장' 버튼이 하나라고 해서 모든 데이터를 통째로 저장해야 하는 것은 아닙니다. 한 동작이 어떤 기록을 바꿀 수 있는지 좁혀 두면 다른 기능의 변경과 충돌할 면적도 줄어듭니다.
4. 재시도는 새로운 행동과 다르다
네트워크가 늦어 처리 요청을 다시 보냈을 때, 사용자가 새 행동을 선택한 것인지 같은 처리를 재시도한 것인지 구분해야 합니다. 아키텍처 문서는 결정 ID와 실행 권한 검사를 통해 중복 적용과 오래된 처리자의 기록을 막아야 한다는 조건을 남깁니다. 이는 현재 설계상 요구사항을 설명한 것이며 모든 장애에서 이미 문제가 없다고 보증하는 표현은 아닙니다.
5. 개발자가 비교할 장면
수련 전후에 인물 상태, 요청한 명령, 적용 이벤트를 나란히 보면 변화가 어디에서 생겼는지 확인하기 쉽습니다. 오래 열어 둔 화면에서 배치를 바꾸는 경우라면, 배치만 바뀌고 최신 수련 결과는 그대로 남아야 합니다. 요청을 재전송한 경우라면 같은 결과가 중복 지급되지 않아야 합니다. 이처럼 예상 결과를 먼저 적어 두면 '이상하다'는 감상에서 재현 가능한 점검으로 넘어갈 수 있습니다.
6. 플레이 안내를 쓰는 기준
플레이어에게는 내부 저장 구조보다 선택의 결과를 알아볼 수 있는 기록이 중요합니다. 개발 노트에는 구현 이유를 남기고, 게임 안내에는 무엇을 선택하고 어디에서 결과를 확인하는지를 적으려 합니다. 문파의 흥망을 오래 기억할 수 있는 세계는 큰 사건뿐 아니라 작은 상태 변경이 일관되게 이어질 때 만들어집니다.