| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 |
- git
- multi-thread
- 독서
- design pattern
- Photon
- Data Structure
- C++
- PS
- Network Programming
- Toy Project
- Online Judge
- team project
- BOJ
- System Programming
- Unity
- c#
- Today
- Total
I'm FanJae.
Unity 게임 개발 캠프 개인 프로젝트 2일차. 인증 상태와 세션 전달 방식에 대한 고민 본문
Unity 게임 개발 캠프 개인 프로젝트 2일차. 인증 상태와 세션 전달 방식에 대한 고민
FanJae 2026. 9. 15. 23:441. 시작에 앞서
- 이전에는 로그인 서버와 게임 서버를 분리해야 하는 이유에 대해 고민했다.
- 인증과 실제 게임 로직은 처리하는 작업의 성격이 다르고, 역할과 보안 경계를 분리한다는 측면에서도 두 서버를 나눠서 생각할 수 있다고 판단했다.
- 하지만 서버를 분리하면서 새로운 문제가 하나 생겼다. 로그인 서버에서 인증된 사용자를 게임 서버에서는 어떻게 인증된 사용자라고 판단할 것인가?
- 로그인 서버와 게임 서버가 하나의 프로세스라면 인증 결과를 내부 상태로 그대로 유지할 수도 있다.
- 하지만 두 서버가 별도의 프로세스로 동작한다면, 로그인 서버가 가지고 있는 인증 상태를 게임 서버까지 전달할 방법이 필요하다.
2. 인증 상태를 이어주기 위한 정보가 필요하다.
- 이를 위해 로그인 성공 시 별도의 인증 정보를 발급하는 구조를 생각해볼 수 있다.
Client
│
│ ID / PW
▼
Login Server
│
│ 인증 성공
▼
인증 정보 발급
│
▼
Client
│
│ 인증 정보를 가지고 접속
▼
Game Server
│
│ 인증 정보 검증
▼
게임 입장
- 여기서 발급하는 값은 Session ID, Login Ticket, Token 등의 형태가 될 수 있다.
- 중요한 것은 구체적으로 어떤 방식을 사용하는가보다, 게임 서버가 클라이언트의 주장만 믿지 않고 로그인 서버에서 만들어진 인증 결과를 다시 검증할 수 있어야 한다는 점이다.
3. 세션이라는 개념에 대한 고민
- 여기서 세션이라는 개념을 다시 생각할 필요가 있었다.
- 처음에는 클라이언트와 서버 사이의 TCP 연결 하나를 하나의 세션이라고 생각하기 쉬웠다.
- 하지만 네트워크 연결과 사용자 인증 상태는 서로 다른 개념이다.
TCP Connection
= 클라이언트와 서버가 통신할 수 있는 연결 상태
Login Session
= 해당 사용자가 인증되었다는 상태
Game Session
= 인증된 사용자가 실제 게임에 진입한 상태
- 즉, 게임 서버에 TCP 연결이 만들어졌다고 해서 바로 정상적인 플레이어라고 판단할 수는 없다.
- 먼저 해당 사용자가 정상적인 인증 과정을 거쳤는지 확인하고, 이후 실제 게임 플레이를 위한 세션을 만들어야 한다.
TCP 연결
↓
인증 정보 전달
↓
인증 정보 검증
↓
검증 성공?
┌───────┴───────┐
No Yes
↓ ↓
연결 종료 Game Session 생성
↓
게임 진입
4. 그렇다면 인증 정보는 어떻게 관리할 것인가?
- 인증 정보를 사용하기로 하면 다시 몇 가지 문제가 생긴다.
- 로그인 서버가 인증 정보를 발급한다면, 게임 서버는 이를 어떤 방식으로 검증해야 할까?
Login Server
│
│ Session / Ticket 생성
▼
Client
│
▼
Game Server
│
└─ 이 값이 정말 Login Server에서 발급된 것인가?
- 여기서 몇 가지 방법을 생각해볼 수 있다.
1. Login Server와 Game Server가 동일한 Session 저장소를 사용한다.
2. Game Server가 Login Server에 직접 Session 검증을 요청한다.
3. Login Server가 검증 가능한 Token 또는 Ticket을 발급한다.
- 어떤 방식을 선택하느냐에 따라 서버 간 결합도와 구현 복잡도가 달라진다.
5. 이번 프로젝트에서는 어떻게 가져갈 것인가
- 실제 서비스 수준의 복잡한 인증 시스템을 구현하는 것이 이번 프로젝트의 목적은 아니지만, 이전에 업무를 할 당시에는 OAuth와 같은 구조를 적용해서 구현했던 바 있지만, 그때는 서로 다른 WAS에서의 통합 인증 모듈을 구축하는 것이었기 때문에 느낌이 조금 다르다. 다만, 아래와 같은 Flow로 이뤄진다고 볼 수 있다.
Login Server
↓
로그인 성공
↓
Login Ticket 생성
↓
Client에 전달
↓
Game Server 접속
↓
Login Ticket 검증
↓
Game Session 생성
- 우선, 실제 구현 과정에서 어떻게 해야할지 조금 더 잡아보려고 한다.
'Projects > MyToyMapleServer' 카테고리의 다른 글
| Unity 게임 개발 캠프 개인 프로젝트 4일차. IOCP 기반 비동기 네트워크 처리 구조 구현 (0) | 2026.09.17 |
|---|---|
| Unity 게임 개발 캠프 개인 프로젝트 4일차. Blocking 서버의 한계 (개인 공부 내용) (0) | 2026.09.17 |
| Unity 게임 개발 캠프 개인 프로젝트 3일차. 동기와 비동기, Blocking과 Non-Blocking (개인 공부 내용) (0) | 2026.09.16 |
| Unity 게임 개발 캠프 개인 프로젝트 1일차. 서버 구조에 대한 고민 (0) | 2026.09.14 |
| Unity 게임 개발 캠프 개인 프로젝트 0일차. 기본 구상. (0) | 2026.09.13 |