단일 스레드의 한계
MMO의 부담
- 수천~수만 세션의 네트워크 패킷 처리
- 전투/이동/스킬/AI 로직 계산
- DB/캐시 연동, 로그/분석 기록
- 이 모든 일을 한 스레드가 처리하면 틱 지연이 누적됩니다.
FPS(배그)는?
- FPS도 실제로는 멀티스레드를 사용하지만, 세션 단위 부하 특성이 MMO와 다릅니다.
- MMO는 동시 사용자 수 + 상태 종류 + 영속 데이터 처리가 크기 때문에 구조적 분산이 더 중요합니다.
틱 예산 관점으로 보기
- 예: 20ms 틱(50 TPS)에서 한 틱이 35ms 걸리면 바로 지연/랙이 발생합니다.
- 블로킹 I/O(DB 호출 등)가 메인 로직을 막으면 전체 게임 진행이 흔들립니다.
역할 분담 (직원 비유)
전담 직원 배치
| 역할 | 담당 업무 |
|---|---|
| 네트워크 I/O | 패킷 수신/송신, 세션 관리 |
| 게임 로직 | 이동, 전투, 스킬, 월드 상태 갱신 |
| AI/경로 계산 | 몬스터 행동, 길찾기 보조 |
| DB/저장 | 비동기 저장, 계정/인벤토리 영속화 |
분담의 효과
- 각 영역이 병렬로 일해 틱 예산을 지키기 쉬워집니다.
- DB 지연이 생겨도 네트워크/로직 루프를 분리하면 전체 멈춤을 줄일 수 있습니다.
스레드 간 연결 방식
- 핵심 패턴은 공유 메모리 직접 접근 최소화 + 메시지 큐(Event Queue) 입니다.
- 예: 네트워크 스레드가 패킷을 큐에 넣고, 게임 로직 스레드가 틱에서 소비합니다.
멀티스레드의 어려움
직원을 많이 뽑는다고 좋은가?
- 아니다.
- 스레드가 많아질수록 락 경합, 컨텍스트 스위칭, 캐시 무효화가 커집니다.
- 공유 데이터 동기화가 잘못되면 레이스 컨디션/데드락이 발생합니다.
이론 vs 현실
- 이론: 역할 분담으로 성능 향상
- 현실: 잘못 분할하면 락 때문에 싱글 스레드보다 느려질 수 있음
실무에서 먼저 하는 최적화
- 공유 상태를 줄인다(소유권 분리)
- 긴 작업(DB, 파일, 외부 API)을 비동기화한다
- 고정 스레드 풀을 사용해 생성/파괴 오버헤드를 줄인다
- 측정(프로파일링)으로 병목을 확인한 뒤 분할 범위를 조정한다
스레드 모델
| 모델 | 설명 |
|---|---|
| 1 클라이언트 1 스레드 | 구현은 쉬우나 확장성 낮음 (대규모에서 비권장) |
| 고정 워커 풀 | 작업 큐 기반으로 처리, 서버에서 가장 흔한 방식 |
| 영역(Zone/Shard) 소유 모델 | 영역별 로직 스레드가 상태를 독점 관리 |
| I/O + 로직 분리형 | 네트워크 이벤트와 게임 틱 루프를 분리 |
MMO에서 자주 쓰는 방향
- I/O 스레드 + 로직 스레드 + 비동기 DB 워커 조합이 기본 축입니다.
- 상황에 따라 월드를 존/채널로 분할해 병렬 확장합니다.
설계 원칙 한 줄
- "스레드를 늘리기"보다 먼저 "데이터 소유권을 분리"해야 성능이 납니다.
강의 시 유의사항
강조 포인트
- 멀티스레드의 목적은 "스레드 개수 증가"가 아니라 "틱 예산 안정화"입니다.
- MMO는 네트워크/AI/DB를 분리하지 않으면 지연이 시스템 전체로 전파됩니다.
- 큐 기반 메시징이 공유 데이터 직접 접근보다 안전하다는 점을 강조하세요.
체크 질문 (스스로 답해보기)
- 왜 MMO에서 DB 작업을 메인 로직 스레드에서 직접 처리하면 위험한가?
- 스레드를 늘렸는데 성능이 떨어지는 대표 원인은 무엇인가?
- 고정 워커 풀과 1클라1스레드 모델의 차이를 설명할 수 있는가?
李家네_공부방