서버란 무엇인가
한 줄 정의
서버(강의 맥락): 네트워크 요청을 받아 처리하도록 대기(listen)하는 프로그램
- 게임 서버 맥락에서는 보통 24/7 상시 운영을 전제로 이야기합니다.
- 핵심은 "컴퓨터"가 아니라 "요청을 처리하는 실행 중인 프로세스"입니다.
"서버" 용어의 다의성
| 의미 | 설명 |
|---|
| 프로그램(프로세스) | 실제로 실행 중인 서버 프로세스 |
| 컴퓨터(머신) | 서버 프로그램이 올라간 물리/가상 장비 |
| 소프트웨어 | 서버 기능을 구현한 코드베이스 |
| 서비스 | 사용자에게 제공되는 기능 단위 (예: 로그인 서버) |
게임 개발자 관점 핵심: "서버" = 실행 중인 프로그램(프로세스) 으로 이해하면 혼동이 줄어듭니다.
식당 비유 (강의 시 핵심 비유)
┌─────────────────────────────────────────────────────────────────┐
│ 식당 운영 │
├─────────────────────────────────────────────────────────────────┤
│ 1. 식당이 닫혀 있으면 → 손님을 받지 못함 │
│ 2. 영업시간이 되면 → 문을 열고 대기 │
│ 3. 손님이 오면 → 메뉴·정책에 따라 서비스 제공 │
└─────────────────────────────────────────────────────────────────┘
↕
┌─────────────────────────────────────────────────────────────────┐
│ 서버 동작 │
├─────────────────────────────────────────────────────────────────┤
│ 1. 서버가 꺼져 있으면 → 클라이언트 접속 불가 │
│ 2. 서버가 실행되면 → 연결 대기 상태 │
│ 3. 클라이언트 접속 시 → 통신을 통해 서비스 제공 │
└─────────────────────────────────────────────────────────────────┘
서버의 최소 동작 사이클
- 소켓 생성/바인딩
- 연결 대기(listen/accept) 또는 패킷 수신
- 요청 파싱 및 로직 처리
- 응답 전송
- 상태 갱신 및 다음 요청 대기
웹서버 vs 게임 서버
핵심 비교표
| 구분 | 웹서버 (기본 HTTP) | 게임 서버 (TCP/UDP + Stateful) |
|---|
| 비유 | 테이크아웃(맥도날드) | 일반 식당 |
| 기본 패턴 | 요청 -> 응답 -> 종료 | 연결 유지, 지속 동기화 |
| 지연 시간 요구 | 상대적으로 낮음 | 매우 낮음(실시간) |
| 서버 -> 클라 푸시 | 기본 HTTP는 제한적 (WebSocket/SSE로 가능) | 기본적으로 가능 |
| 상태 관리 | Stateless 중심 | Stateful 중심 |
| 데이터 형식 | 텍스트(JSON/HTML) 중심 | 바이너리 프로토콜 빈번 |
웹서버 사용 예
- 게임 계정/로그인/결제/상점/랭킹 API
- 패치 정보 제공, 공지/운영 데이터 제공
- 이유: 인증/권한/트랜잭션 처리에 웹 생태계가 강함
게임 서버 사용 예
- 스타크래프트류 RTS/FPS: 이동/사격/피격 이벤트를 실시간 브로드캐스트
- MMO: 다수 플레이어 위치/전투/AI를 권위(authoritative) 상태로 동기화
실제 서비스 구조 (혼합형)
- 대부분의 온라인 게임은 웹서버 + 게임서버를 함께 사용합니다.
- 예: 로그인은 웹 API, 실제 전투는 게임 서버 세션에서 처리
웹 프레임워크 예시
| 언어/환경 | 프레임워크 | 사용처 |
|---|
| C# | ASP.NET | .NET 기반 |
| Java | Spring | 한국 대기업·공공기관 |
| JavaScript | Node.js | 스타트업·소규모 |
| Python | FastAPI/Django | 운영툴·백오피스·API |
| PHP | Laravel 등 | 레거시·특수 목적 |
게임 서버와 프레임워크
클라이언트 vs 서버
- 클라이언트: 유니티·언리얼 등 표준화된 엔진 존재
- 게임 서버: 장르별 요구사항이 달라 통일된 프레임워크가 거의 없음
서버 프레임워크 통일이 어려운 이유
- 장르별 네트워크 모델 차이(FPS, RTS, MMO, 턴제)
- 동기화 방식 차이(락스텝, 서버 권위, 예측/보정)
- 데이터 일관성 요구 수준 차이(전투, 거래, 길드, 경매장)
- 운영/샤딩/매치메이킹 구조가 프로젝트마다 다름
MMO vs FPS (경향 비교)
| 장르 | 서버 제작 방식 | 소요 기간 |
|---|
| MMO | 코어부터 커스텀 구현 비중 큼 | 2~5년+ |
| FPS(배그 등) | 데디케이티드 서버/엔진 네트워킹 적극 활용 | 상대적으로 짧음 |
데디케이티드 서버 (Unreal)
- 클라이언트/서버 코드를 분리 빌드하여 서버 전용 실행 파일을 생성
- 엔진의 네트워킹/복제(replication) 기능을 활용해 개발 속도 향상
- 단, 대규모 운영(매치메이킹/세션 배치/관측/로그)은 별도 플랫폼 계층이 필요
강의 시 유의사항
강조 포인트
- 식당 비유를 먼저 던지고, 네트워크 용어로 대응시키면 이해가 빠릅니다.
- "서버 = 프로그램"과 "서버 = 머신"을 반드시 분리해 설명합니다.
- 웹서버/게임서버는 "대체 관계"가 아니라 "역할 분담 관계"임을 강조합니다.
자주 하는 오해
| 오해 | 바로잡기 |
|---|
| 웹서버는 서버 -> 게임서버 불필요 | 실시간 동기화는 게임서버 역할이 필수 |
| 게임서버만 있으면 운영 가능 | 인증/결제/백오피스 등은 웹 API 계층 필요 |
| 데디케이티드 서버면 운영도 자동 해결 | 운영 플랫폼(매치, 모니터링, 배포)은 별도 구축 |
체크 질문 (스스로 답해보기)
- 왜 게임 개발에서 "서버 = 실행 중인 프로세스"로 정의하는 것이 중요한가?
- 기본 HTTP와 게임 세션 서버의 통신 모델 차이는 무엇인가?
- MMO 서버 개발이 FPS 대비 장기화되는 이유를 2가지 이상 말할 수 있는가?
