
처음 코딩을 배우면 문법은 이해했는데 막상 무엇을 만들어야 할지 막막해지는 시기가 옵니다. 수업에서는 이 시기를 짧게 넘기도록 작은 게임 하나를 정해 기능을 …
네트워크 기초는 게임 상황에 붙여서 답합니다
가장 먼저 나오는 질문은 TCP와 UDP의 차이입니다. 교과서 정의만 말하면 평범한 답이 됩니다. "TCP는 순서와 도착을 보장하지만 재전송 때문에 지연이 생길 수 있고, UDP는 보장이 없지만 빠르다"고 말한 뒤, "그래서 결제나 아이템 획득처럼 빠지면 안 되는 정보와, 매 순간 갱신되는 위치 정보는 처리 방식을 다르게 볼 수 있다"처럼 게임 상황으로 연결하면 좋습니다.
패킷 설계 질문도 자주 나옵니다. 클라이언트와 서버가 주고받는 메시지를 어떻게 정의했는지, 메시지 크기를 줄이려고 무엇을 했는지, 버전이 다른 클라이언트가 접속하면 어떻게 하는지 같은 질문입니다. 포트폴리오에서 직접 패킷 구조를 정의해 봤다면 그 표를 떠올리며 설명할 수 있게 준비하세요.
"클라이언트가 보낸 값을 그대로 믿으면 안 되는 이유"도 단골 질문입니다. 데미지나 이동 속도를 클라이언트가 계산해 보내면 조작된 값이 들어올 수 있다는 점, 그래서 중요한 판정은 서버에서 검증한다는 원칙을 말하면 됩니다.
동시성 질문은 실제로 겪은 문제로 답할수록 강합니다
여러 플레이어의 요청이 동시에 들어오는 서버에서는 같은 데이터를 두 곳에서 바꾸는 문제가 자주 생깁니다. 면접에서는 "두 플레이어가 동시에 같은 아이템을 주우면 어떻게 되나요?" 같은 구체적인 상황으로 묻는 경우가 많습니다.
- 락(잠금)을 걸어 한 번에 하나만 처리하게 하는 방법과 그 비용
- 락을 여러 개 쓸 때 서로 기다리다 멈추는 교착 상태가 생기는 이유
- 작업을 한 줄로 세워 순서대로 처리하는 큐 방식
- 같은 요청이 두 번 들어와도 결과가 한 번만 반영되게 하는 설계
정답이 하나인 질문이 아니므로, 방법마다 장단점을 짚고 "이 상황에서는 이것을 고르겠다"고 이유를 말하는 것이 좋습니다. 포트폴리오에서 실제로 데이터가 꼬였던 경험이 있다면 원인을 어떻게 찾았는지까지 말해 보세요.
데이터베이스와 저장 시점에 관한 질문
게임 서버는 캐릭터 정보, 인벤토리, 재화 같은 데이터를 데이터베이스에 저장합니다. 면접에서는 트랜잭션이 무엇인지, 즉 여러 변경을 한 묶음으로 처리해 중간에 실패하면 전부 되돌리는 개념을 묻고, 이를 게임의 거래나 강화 같은 기능과 연결해 보라고 합니다.
"플레이어 정보를 언제 저장하나요?"라는 질문도 자주 나옵니다. 변경될 때마다 바로 저장하면 안전하지만 데이터베이스 부담이 커지고, 모아서 저장하면 가볍지만 서버가 갑자기 꺼질 때 일부가 사라질 수 있습니다. 재화처럼 중요한 데이터와 위치처럼 덜 중요한 데이터를 나눠 저장 주기를 다르게 둔다는 식으로 판단 기준을 말하면 됩니다. 인덱스를 왜 거는지, 자주 읽는 데이터를 메모리에 올려 두는 캐시를 언제 쓰는지도 함께 준비해 두세요.
장애와 운영 상황을 가정한 질문
서버 프로그래머는 라이브 서비스 중 문제가 생기면 가장 먼저 호출되는 직무입니다. 그래서 "갑자기 접속자가 몰려 서버가 느려지면 무엇부터 보겠어요?", "아이템이 복사되는 버그가 보고되면 어떻게 하겠어요?" 같은 질문이 나옵니다.
답변 방향은 침착한 순서입니다. 먼저 피해가 더 커지지 않게 막고, 로그로 원인과 범위를 확인하고, 고친 뒤에는 같은 문제가 다시 생기지 않도록 재발 방지책을 남기는 흐름입니다. 이를 위해 평소에 어떤 로그를 남겨야 하는지, 즉 누가 언제 무엇을 얻고 잃었는지를 기록해야 추적이 가능하다는 점까지 말하면 실무 감각이 드러납니다.
신입에게 운영 경험을 기대하지는 않습니다. 다만 포트폴리오 서버를 여러 명이 접속하게 해서 시험해 봤거나, 일부러 부하를 걸어 본 경험이 있다면 큰 차별점이 됩니다.
포트폴리오 서버는 그림으로 설명할 준비를 합니다
서버 포트폴리오는 화면으로 보여 줄 것이 적어서 설명이 더 중요합니다. 면접관이 "서버 구조를 그려 보세요"라고 하면, 접속을 받는 부분, 게임 로직을 처리하는 부분, 데이터를 저장하는 부분이 어떻게 연결되는지 박스와 화살표로 그릴 수 있어야 합니다.
그림을 그린 뒤에는 "접속자가 지금보다 열 배 늘어나면 어디가 먼저 버티지 못할까요?"라는 꼬리 질문이 이어지기 쉽습니다. 병목이 될 부분을 스스로 짚고, 서버를 여러 대로 나누거나 역할별로 분리하는 방향을 말하면 됩니다. 실제로 구현하지 않았더라도 확장 방향을 고민해 봤다는 것만으로도 좋은 인상을 줄 수 있습니다.
사용한 언어와 라이브러리를 고른 이유도 함께 정리해 두세요. "수업에서 배워서"라는 답보다, 비동기 입출력을 다루기 쉬웠다거나 참고 자료가 많아 막혔을 때 해결하기 좋았다는 식의 판단 근거가 더 낫습니다. 다른 선택지와 비교해 본 경험이 있다면 짧게 덧붙이세요. 회사가 쓰는 언어와 다르더라도 서버 구조를 이해하는 원리는 그대로 옮겨 갈 수 있다는 점을 보여 주는 것이 핵심입니다.
클라이언트·기획과의 협업, 그리고 마지막 점검
"클라이언트 프로그래머와 패킷 규칙을 어떻게 맞추나요?"라는 질문에는 문서나 공통 정의 파일로 약속을 먼저 정하고, 바뀔 때는 반드시 알리는 절차를 둔다고 답하면 됩니다. 기획자의 요구가 서버에 큰 부담을 주는 경우에는 부담이 생기는 이유를 쉬운 말로 설명하고 대안을 제시하는 태도가 중요합니다.
면접 전에는 내 서버 코드에서 동시성 처리와 저장 처리를 한 군데씩 골라 다시 읽어 보세요. 그 두 곳이 가장 깊이 질문받는 부분입니다. 서버 포트폴리오를 어느 규모까지 만들어야 할지 고민된다면, SBS아카데미게임학원 게임프로그래밍 과정 상담에서 지금 수준에 맞는 서버 프로젝트 범위를 함께 정해 볼 수 있습니다.
자주 묻는 질문
게임 서버 면접에서 웹 서버 경험도 인정되나요?
네트워크와 데이터베이스 기초는 그대로 통하기 때문에 도움이 됩니다. 다만 실시간으로 상태를 주고받는 게임 서버의 특징을 따로 공부해 두는 것이 좋습니다.
서버 면접에서 운영체제 질문도 나오나요?
프로세스와 스레드의 차이, 메모리 구조처럼 동시성과 연결되는 기본 개념은 자주 나옵니다. 서버 동작과 연결해 설명할 수 있게 준비해 두세요.
가까운 캠퍼스에서 게임프로그래밍 알아보기
사는 곳과 가까운 캠퍼스를 고르면 수업 내용, 오시는 길, 상담 신청을 한 번에 볼 수 있습니다.