📘TIL-멀티플레이 숫자야구게임 2차 리팩토링

문제

기존 숫자야구에 회원가입,UI 연결 등 업데이트된 게임 구조에서는 한 번 리팩토링을 거친GameMode가 여전히 너무 많은 책임을 동시에 맡고 있었다.

하나의 클래스 안에서 다음 역할이 한꺼번에 처리되고 있었다.

• 회원가입 / 로그인 요청 처리
• 일반 채팅 / 시스템 메시지 브로드캐스트
• 턴 시작 / 턴 전환 / 시간 초과 처리
• 숫자 판정(스트라이크/볼/아웃) 및 승패/무승부 처리
• 전적 반영
• 게임 리셋
• UI 갱신 트리거

이 구조는 처음에는 빠르게 기능을 붙이기에는 편했지만, 기능이 늘어날수록 문제가 커졌다.

• GameMode 코드가 계속 비대해짐
• 채팅 수정이 턴 로직에 영향을 줄 수 있음
• 승패 처리 수정이 리셋 로직까지 함께 건드리게 됨
• 디버깅 시 원인 추적 범위가 너무 넓음
• 이후 기능 추가 시 충돌 위험이 커짐

즉, 현재 구조는 작동은 하지만 유지보수성이 떨어지는 상태였다.

---

분석

이번 리팩토링의 핵심 분석 포인트는
“기능별로 로직이 다르다”가 아니라
“상태를 관리하는 책임과 계산/출력을 담당하는 책임이 섞여 있다”는 점이었다.

예를 들어,

• 로그인은 계정 인증과 플레이어 상태 반영 문제
• 채팅은 메시지 포맷팅과 브로드캐스트 문제
• 턴 진행은 게임 흐름 제어 문제
• 승패/무승부는 경기 종료 판단 문제
• 전적 반영은 결과 저장 문제

인데, 이것들이 모두 GameMode 안에 들어가 있으면
클래스 하나가 오케스트레이터 + 로직 담당자 + 저장 처리자 + 메시지 송신자까지 겸하게 된다.

결국 GameMode는 서버 권한 아래서 전체 흐름만 조율해야 하는데,
실제로는 내부 구현까지 직접 들고 있는 God Class에 가까운 구조가 되어 있었다.

---

기존 구조의 문제점

1. 책임 집중

기존 구조는 아래처럼 정리할 수 있었다.

GameMode
 ├─ 회원가입 처리
 ├─ 로그인 처리
 ├─ 채팅 처리
 ├─ 턴 시작
 ├─ 턴 전환
 ├─ 시간 초과 처리
 ├─ 숫자 판정
 ├─ 승패/무승부 판단
 ├─ 전적 반영
 └─ 게임 리셋

이 구조에서는 어떤 버그가 발생해도 결국 GameMode를 열어봐야 했다.

---

2. 수정 범위 확장

예를 들어 채팅 메시지 출력 형식을 바꾸고 싶어도
GameMode 내부를 수정해야 했고,

턴 로직을 바꾸고 싶어도
승패 처리, 리셋 처리와 붙어 있어서 영향 범위가 커졌다.

즉, 한 기능의 수정이 다른 기능에 파급될 가능성이 높았다.

---

3. 테스트와 디버깅 난이도 증가

문제가 생겼을 때

• 입력 단계 문제인지
• 턴 진행 문제인지
• 판정 문제인지
• 결과 반영 문제인지
• UI 갱신 문제인지

를 한 번에 분리해서 보기 어려웠다.

특히 멀티플레이에서는 서버 기준 흐름이 중요하기 때문에
책임이 섞여 있으면 버그 원인 추적이 더 힘들어진다.

---

리팩토링 목표

이번 리팩토링의 목표는 단순히 파일을 나누는 것이 아니라
역할 기준으로 구조를 다시 설계하는 것이었다.

최종 방향은 아래처럼 잡았다.

• GameMode
  → 요청 진입점, 매니저 생성, delegate 연결만 담당
• MatchFlowManager
  → 턴 진행, 제한 시간, 숫자 판정 흐름, 승패/무승부, 리셋 담당
• ChatManager
  → 일반 채팅, 시스템 메시지, 브로드캐스트 담당
• RecordManager
  → 승/패/무 전적 반영 담당

즉, GameMode는 더 이상 모든 걸 직접 하지 않고
각 책임을 가진 객체를 조립하고 호출하는 구조로 바꾸는 것이 목표였다.

---

해결

1. GameMode를 라우터로 축소

가장 먼저 GameMode의 역할을 줄였다.

이제 GameMode는 다음만 담당한다.

• 플레이어 접속 시 초기 등록
• 로그인/회원가입 요청 진입
• 추측 입력 요청 전달
• 일반 채팅 요청 전달
• 매니저 생성 및 초기화
• delegate 바인딩

즉, 직접 턴을 돌리거나, 직접 채팅을 뿌리거나, 직접 전적을 갱신하지 않는다.

구조적으로 보면 이렇게 바뀐 셈이다.

Before
GameMode = 요청 처리 + 게임 흐름 + 채팅 + 전적 + 리셋

After
GameMode = 요청 진입 + 매니저 연결

---

2. MatchFlowManager 분리

가장 큰 책임 덩어리는 경기 진행 흐름이었다.

이를 MatchFlowManager로 분리했다.

이 매니저는 아래 역할을 맡는다.

• 등록된 플레이어 목록 관리
• 로그인 플레이어 수 검사
• 경기 시작 가능 여부 판단
• 현재 턴 플레이어 관리
• 턴 시작 / 다음 턴 전환
• 시간 초과 처리
• 추측 입력 판정 요청
• 승리 / 무승부 판정
• 라운드 리셋 스케줄링

즉, 게임 한 판이 어떻게 흘러가는지를 전담하는 객체가 되었다.

---

3. ChatManager 분리

채팅 출력은 게임 규칙과는 별개 성격이 강하기 때문에 분리했다.

이 매니저는 다음을 담당한다.

• 일반 채팅 메시지 포맷팅
• 시스템 메시지 브로드캐스트
• 로그인 안내 메시지 출력
• 턴 시작 / 시간 초과 / 경기 종료 메시지 출력

예를 들어,
PlayerName: Hello
같은 일반 채팅 포맷도 이제 ChatManager에서 처리한다.

---

4. RecordManager 분리

승/패/무 기록 반영도 별도 책임으로 분리했다.

이 매니저는

• 승리 플레이어 전적 갱신
• 패배 플레이어 전적 갱신
• 무승부 플레이어 전적 갱신

을 담당한다.

이렇게 분리함으로써,
경기 종료 판단과 전적 저장 로직이 분리되었다.

즉,

• 누가 이겼는지 판단하는 것은 MatchFlowManager
• 그 결과를 DB/PlayerState에 반영하는 것은 RecordManager

가 담당하게 되었다.

---

5. Delegate 기반 연결

매니저 간 직접 결합을 줄이기 위해 delegate를 사용했다.

MatchFlowManager는 경기 흐름 이벤트를 발생시키고,
ChatManager가 이를 구독하도록 구성했다.

예를 들면 다음과 같은 흐름이다.

MatchFlowManager
 ├─ OnTurnStarted
 ├─ OnTurnTimedOut
 └─ OnMatchEnded

ChatManager
 ├─ 턴 시작 메시지 출력
 ├─ 시간 초과 메시지 출력
 └─ 경기 종료 메시지 출력

이 구조의 장점은
MatchFlowManager가 채팅 출력 방식을 알 필요가 없다는 점이다.

즉, “턴이 시작되었다”라는 사실만 알리고,
그걸 어떻게 보여줄지는 ChatManager가 맡는다.

---

리팩토링 전후 클래스 구조

Before 구조

+----------------------+
| ABACGameModeBase     |
+----------------------+
| - AllPlayerControllers
| - SecretNumberString
| - TurnTimerHandle
| - ResultResetTimerHandle
+----------------------+
| + HandleRegisterRequest()
| + HandleLoginRequest()
| + HandleGuessRequest()
| + HandlePlainChatMessage()
| + BroadcastChatToAll()
| + BroadcastSystemMessageToAll()
| + StartTurn()
| + StartTurnByIndex()
| + AdvanceTurn()
| + HandleTurnTimeout()
| + JudgeGame()
| + ResetGame()
| + UpdateUserRecordOnWin()
| + UpdateUserRecordOnLose()
| + UpdateUserRecordOnDraw()
+----------------------+

문제는 하나의 클래스에 너무 많은 기능이 응집되어 있다는 점이었다.

---

After 구조

+----------------------+
| ABACGameModeBase     |
+----------------------+
| + BeginPlay()
| + OnPostLogin()
| + HandleRegisterRequest()
| + HandleLoginRequest()
| + HandleGuessRequest()
| + HandlePlainChatMessage()
| + BindManagerDelegates()
+----------------------+
          |
          v
+----------------------+     +----------------------+     +----------------------+
| UBACMatchFlowManager | --> |   UBACChatManager    |     | UBACRecordManager    |
+----------------------+     +----------------------+     +----------------------+
| 턴 진행               |     | 채팅 출력             |     | 전적 반영             |
| 시간 제한             |     | 시스템 메시지         |     | 승/패/무 저장         |
| 입력 판정 흐름         |     | 브로드캐스트          |     | PlayerState 갱신      |
| 승패/무승부 처리       |     | 안내 메시지           |     | AccountService 연동   |
| 리셋                  |     | delegate 수신         |     |                      |
+----------------------+     +----------------------+     +----------------------+

---

시퀀스 흐름도

1. 일반 채팅 처리 흐름

Client UI
 -> PlayerController
 -> GameMode.HandlePlainChatMessage()
 -> ChatManager.HandlePlainChatMessage()
 -> ChatManager.BroadcastChatToAll()
 -> 각 ClientRPC
 -> ChatPanel ScrollBox 출력

---

2. 추측 입력 처리 흐름

Client UI
 -> PlayerController
 -> GameMode.HandleGuessRequest()
 -> MatchFlowManager.SubmitGuess()
    -> 로그인 여부 검사
    -> 현재 턴 여부 검사
    -> MatchService.ValidateGuess()
    -> MatchService.JudgeGuess()
    -> 결과 채팅 출력
    -> 승리 / 무승부 / 다음 턴 판단

---

3. 경기 종료 처리 흐름

MatchFlowManager
 -> 승리 또는 무승부 판단
 -> RecordManager 전적 반영
 -> OnMatchEnded Broadcast
 -> ChatManager 종료 메시지 출력
 -> 결과 패널 갱신
 -> 일정 시간 후 ResetRound()

---

클래스 책임 정리

ABACGameModeBase

• 서버 진입점
• 요청 라우팅
• 매니저 생성
• delegate 연결
• 로그인 시 PlayerState 기본값 반영

UBACMatchFlowManager

• 경기 생명주기 관리
• 턴 상태 관리
• 제한 시간 관리
• 추측 결과 흐름 제어
• 경기 종료 후 리셋

UBACChatManager

• 일반 채팅 메시지 처리
• 시스템 메시지 처리
• 경기 흐름 이벤트를 텍스트로 출력
• 클라이언트 채팅 UI 반영 트리거

UBACRecordManager

• 전적 갱신 책임 분리
• AccountService 연동
• 승/패/무를 PlayerState와 저장소에 반영

---

이번 작업에서 얻은 핵심 효과

1. 유지보수성 향상

이제 채팅 수정은 ChatManager,
턴 로직 수정은 MatchFlowManager,
전적 수정은 RecordManager 중심으로 보면 된다.

즉, 수정 범위가 명확해졌다.

---

2. 디버깅 범위 축소

문제가 발생했을 때

• 채팅이 안 뜨면 ChatManager
• 턴이 꼬이면 MatchFlowManager
• 전적이 반영되지 않으면 RecordManager

처럼 원인 추적 범위를 빠르게 좁힐 수 있다.

---

3. 확장성 확보

이 구조에서는 앞으로도 기능을 더 붙이기 쉽다.

예를 들어,

• PlayerRegistryManager
• AuthCoordinator
• ResultPanelManager
• RoomManager

같은 추가 분리도 자연스럽게 가능하다.

즉, 이번 리팩토링은 단순히 코드 정리가 아니라
다음 기능 추가를 위한 구조적 기반 마련이라는 의미가 있다.

---

회고

이번 작업은 단순히 GameMode 코드를 나눈 것이 아니라
서버 중심 멀티플레이 구조에서 책임을 어디에 둬야 하는지 다시 정리한 작업이었다.

기존에는 작동 자체는 했지만,
게임 흐름과 채팅, 전적, 리셋이 한 클래스에 몰려 있어서
규모가 커질수록 불안정해질 구조였다.

이번 리팩토링을 통해

• GameMode는 조립자
• MatchFlowManager는 경기 흐름 담당
• ChatManager는 출력 담당
• RecordManager는 결과 저장 담당

으로 역할이 명확해졌고,
이후 로그인 구조 분리, 플레이어 등록 관리, 룸 단위 확장까지 이어갈 수 있는 기반을 만들었다.

---

오늘의 정리

• 숫자야구 게임 리팩토링의 핵심은 단순한 파일 분리가 아니라
  GameMode에 몰려 있던 게임 흐름 / 채팅 / 전적 / 리셋 책임을 역할별 매니저로 분리함으로써 기능 수정 범위와 디버깅 포인트가 분명해져 이후 확장과 유지보수가 훨씬 쉬운 형태로 정리할 수 있게 되었다.