게임 개발 면접 질문

게임 루프는 매 프레임마다 입력을 수집하고, 그 입력과 시간 경과를 반영해 게임 상태를 갱신하고, 마지막에 갱신된 상태를 화면에 그리는 사이클을 반복하는 구조입니다. 이때 델타 타임은 이전 프레임부터 현재까지 걸린 시간인데, 기기 성능이나 상황에 따라 프레임 시간이 달라지기 때문에 속도 값에 델타 타임을 곱해야 '초당 이동량'이 일정해집니다. 델타 타임을 곱하지 않으면 60프레임 기기와 30프레임 기기에서 캐릭터 이동 속도가 두 배 차이 나는 버그가 생깁니다.

고정 타임스텝은 항상 같은 간격, 예를 들어 1/60초 단위로 갱신하고, 가변 타임스텝은 실제 경과 시간만큼 갱신하는 방식입니다. 물리는 보통 고정 타임스텝을 씁니다. 적분 간격이 일정해야 수치적으로 안정적이고 같은 입력에 같은 결과가 나오는 결정성을 확보할 수 있기 때문입니다. 프레임이 튀면 가변 방식에서는 한 프레임에 너무 큰 이동이 생겨 벽을 뚫는 터널링이 발생하기 쉽습니다. 실무에서는 물리는 고정 스텝으로 여러 번 돌리고, 렌더는 가변 프레임에서 보간해 부드럽게 보여주는 조합을 씁니다.

컴포넌트 구조의 핵심 장점은 기능을 상속이 아니라 합성으로 조립한다는 점입니다. 상속 계층에서는 '날 수 있는 적'과 '총을 쏘는 적'을 조합하려면 클래스가 조합 수만큼 늘어나거나 다중 상속 문제가 생깁니다. 컴포넌트 방식에서는 이동, 체력, 공격 같은 기능을 독립 컴포넌트로 만들고 필요한 것만 붙이면 되어 재사용성이 높고 런타임에 기능을 추가·제거하기도 쉽습니다. 다만 컴포넌트 간 참조가 늘면 의존 관계 추적이 어려워지므로 통신 방식은 이벤트 등으로 정리해 두는 편이 좋습니다.

내적은 두 벡터의 방향이 얼마나 같은지를 나타내는 스칼라 값으로, 정규화된 벡터끼리는 두 벡터 사이 각의 코사인이 됩니다. 그래서 적의 전방 벡터와 적에서 플레이어로 향하는 벡터를 내적해 일정 값 이상이면 시야 안에 있다고 판정하거나, 표면 법선과 광원 방향의 내적으로 밝기를 계산할 때 씁니다. 외적은 두 벡터에 모두 수직인 벡터를 주기 때문에 삼각형 세 정점으로 면 법선을 구하거나, 결과의 부호로 목표가 내 왼쪽인지 오른쪽인지 판단해 회전 방향을 정할 때 사용합니다.

로컬 좌표는 오브젝트 자신의 원점을 기준으로 한 좌표, 월드 좌표는 씬 전체의 공통 원점을 기준으로 한 좌표, 스크린 좌표는 최종 화면 픽셀 기준 좌표입니다. 변환 행렬은 이 좌표계 사이를 옮겨주는 역할을 하는데, 모델 행렬이 로컬을 월드로, 뷰 행렬이 월드를 카메라 기준으로, 프로젝션 행렬이 이를 클립 공간으로 보내고 최종적으로 화면 좌표로 매핑됩니다. 행렬을 쓰면 이동·회전·스케일을 하나로 합쳐 계산할 수 있고, 부모-자식 계층에서 부모 행렬을 곱해 상대 변환을 표현하기도 편합니다.

세 가지는 비용과 정확도의 트레이드오프에 따라 나눠 씁니다. AABB는 축 정렬 박스라 두 축 범위 비교만으로 겹침을 알 수 있어 매우 싸고, 많은 오브젝트를 걸러내는 브로드페이즈에 적합합니다. 구는 중심 거리와 반지름 합만 비교하면 되고 회전에 영향받지 않아 캐릭터나 폭발 범위 판정에 좋습니다. 레이캐스트는 한 점에서 방향으로 선을 쏴 처음 맞는 대상을 찾는 방식이라 총 조준, 지면 착지 판정, 마우스 클릭 대상 선택에 씁니다. 실무에서는 싼 판정으로 후보를 줄이고 정밀 판정을 뒤에 두는 순서로 구성합니다.

리지드바디는 질량, 속도, 중력 같은 물리 속성을 가지고 물리 시뮬레이션의 대상이 되는 컴포넌트이고, 트리거는 물리적으로 밀어내지 않고 겹침 여부만 이벤트로 알려주는 콜라이더입니다. 즉 리지드바디와 일반 콜라이더가 만나면 충돌해 튕기거나 멈추지만, 트리거는 통과하면서 진입·이탈 콜백만 발생합니다. 그래서 캐릭터나 굴러가는 물체는 리지드바디로, 세이브 포인트 진입, 함정 발동 범위, 아이템 획득 영역처럼 판정만 필요한 경우는 트리거로 구현합니다.

먼저 추측하지 않고 프로파일러에서 CPU 프레임 시간과 GPU 프레임 시간을 따로 측정합니다. 렌더 해상도를 절반으로 낮췄을 때 프레임이 눈에 띄게 회복되면 픽셀 처리 비용이 큰 GPU 바운드로 보고, 셰이더 복잡도·오버드로우·포스트 프로세싱을 먼저 줄입니다. 해상도를 낮춰도 그대로면 CPU 바운드로 보고 드로우콜 수, 스크립트 업데이트, 물리, 메모리 할당을 확인합니다. GPU가 CPU를 기다리는지 그 반대인지는 대기 구간 지표로 보고, 병목을 하나 해소하면 다시 측정해 병목이 옮겨갔는지 확인합니다.

원인은 오버드로우로 인한 필레이트와 메모리 대역폭 포화입니다. 불투명 물체는 깊이 테스트로 가려진 픽셀을 미리 버릴 수 있지만, 알파 블렌딩은 뒤 픽셀 값을 읽어 섞어야 해서 깊이 쓰기를 끄고 뒤에서 앞으로 정렬해 그리기 때문에 겹친 레이어 수만큼 픽셀을 반복해 칠합니다. 모바일은 대역폭이 좁아 이 비용이 더 크게 나옵니다. 대응은 오버드로우 뷰로 겹침 구간을 먼저 측정하고, 파티클 개수와 크기 축소, 빈 여백이 큰 텍스처의 폴리곤 타이트화, 전체 화면을 덮는 반투명 레이어 제거, 가능한 경우 컷아웃으로 전환입니다.

터널링 현상입니다. 물리는 고정 스텝마다 위치를 이산적으로 갱신하고 그 시점에서만 겹침을 검사하는데, 한 스텝 이동 거리가 벽 두께보다 크면 이전 프레임은 벽 앞, 다음 프레임은 벽 뒤에 있어 겹치는 순간이 아예 샘플링되지 않습니다. 해결은 세 방향입니다. 해당 오브젝트만 연속 충돌 검출을 켜서 이동 경로를 스윕 검사하거나, 물리 스텝을 줄이거나 서브스텝을 늘리고, 벽 콜라이더를 충분히 두껍게 만듭니다. 총알처럼 아주 빠른 것은 물리 이동 대신 이전 위치에서 현재 위치까지 레이캐스트로 판정하는 편이 비용도 싸고 안정적입니다.

기준은 오브젝트의 공간 분포와 갱신 빈도입니다. 모든 쌍을 비교하면 개수의 제곱으로 늘어나므로, 브로드 페이즈에서 공간을 나눠 인접 영역만 검사하도록 줄이는 것이 목적입니다. 오브젝트 크기가 비슷하고 맵에 고르게 퍼져 있으며 매 프레임 움직인다면, 삽입·삭제가 상수 시간인 균일 그리드가 유리하고 셀 크기를 탐색 반경 정도로 잡습니다. 반대로 특정 구역에 심하게 몰리거나 크기 편차가 크면 쿼드트리, 3D로 높이 분포까지 의미 있으면 옥트리가 낫습니다. 정적 지형은 트리, 동적 유닛은 그리드로 나눠 쓰는 절충도 자주 씁니다.

회전은 단위 쿼터니언, 즉 구 위의 점으로 표현되기 때문입니다. 두 쿼터니언을 그냥 선형 보간하면 경로가 구 내부를 지나 정규화가 필요하고 중간 구간의 각속도가 균일하지 않습니다. Slerp는 구면 위 최단 호를 따라가 일정한 각속도를 보장해 카메라나 무기 조준처럼 회전 속도가 중요한 곳에 맞습니다. 각도 차가 작을 때는 차이가 미미해 정규화한 Lerp로 대체해 비용을 아끼기도 합니다. 그리고 매 프레임 Lerp(현재값, 목표값, 계수)는 보간이 아니라 지수 감쇠 추적이라, 계수를 상수로 두면 프레임률에 따라 추적 속도가 달라지므로 델타 타임을 반영해야 합니다.

라이트맵은 런타임 조명 계산을 텍스처 조회로 바꿔 GPU 비용을 크게 줄이는 대신, 메모리와 빌드 시간을 쓰고 런타임에 조명이나 지오메트리를 바꿀 수 없다는 제약이 있습니다. 반대로 실시간 조명은 시간대 변화나 파괴 연출처럼 동적인 표현이 가능하지만 광원 수와 그림자 계산이 매 프레임 비용으로 잡힙니다. 그래서 움직이지 않는 벽과 지형은 구워서 간접광까지 담고, 캐릭터나 소품은 라이트 프로브로 주변 조명을 근사한 뒤 핵심 광원 하나 정도만 실시간으로 둡니다. 모바일에서는 베이크 비중을 더 높이고 실시간 그림자는 주요 캐릭터로 제한하는 편이 안전합니다.

기준은 거리 자체보다 오브젝트가 화면에서 차지하는 크기입니다. 화면 비중이 작아지면 폴리곤이 픽셀보다 촘촘해져 버텍스 셰이더와 삼각형 셋업 비용만 낭비되므로, 그 지점부터 단계별로 단순화된 메시로 교체합니다. 효과는 정점 처리량과 래스터 단계 부하 감소이고, 배칭에 유리하게 머티리얼을 통일하면 드로우콜도 같이 줄 수 있습니다. 부작용은 전환 순간의 팝핑과 LOD 메시를 여러 개 들고 있어야 하는 메모리·에셋 관리 비용입니다. 팝핑은 전환 거리 조정이나 디더링 페이드로 완화하고, 실루엣이 크게 바뀌지 않는 선까지만 단순화합니다. 물론 컬링이 먼저이고 LOD는 그다음입니다.

먼저 서버가 실제로 이동을 검증하고 있는지부터 확인합니다. 서버 권위라면 클라이언트가 보낸 위치를 그대로 반영하지 않고, 서버 시계 기준 경과 시간에 최대 이동 속도를 곱한 허용치와 비교해 초과분을 잘라내야 합니다. 진단은 로그로 합니다. 계정별 단위 시간당 이동 거리, 전송 입력 틱 수 분포를 뽑아 지연이나 패킷 몰림으로 생기는 정상 편차와 구분하고, 누적 초과량이 계속 한쪽으로 쌓이는 계정을 플래그합니다. 다만 매 틱 전체 경로를 재시뮬레이션하는 검증은 CPU 비용이 크므로, 가벼운 속도 상한 검증은 상시로 두고 충돌·경로 재검증은 의심 계정이나 샘플링으로 제한해 비용을 조절하겠습니다.

핵심은 상태를 들고 있는 부분과 그렇지 않은 부분을 분리해 확장 축을 다르게 가져가는 것입니다. 로그인·매치메이킹·세션 서버는 상태가 거의 없어 앞단에 서버를 추가하는 것만으로 수평 확장이 되지만, 게임 서버는 플레이어와 월드 상태를 메모리에 들고 실시간 틱을 돌리므로 존이나 인스턴스 단위로 쪼개서 확장해야 합니다. 그래서 필드는 존 단위로, 던전·전장은 인스턴스 단위로 나누고 세션 서버가 어느 서버에 붙을지 라우팅합니다. 영속 데이터는 게임 서버 메모리가 아니라 DB에 주기적으로 반영하고, 서버가 죽었을 때 마지막 저장 시점으로 복구하거나 다른 인스턴스로 재배치할 수 있게 설계하겠습니다.

먼저 어긋난 정확한 틱을 찾는 게 우선입니다. 틱마다 시뮬레이션 상태의 체크섬을 남기고 원본 플레이와 리플레이를 비교해 최초로 달라지는 틱과 엔티티를 특정합니다. 그다음 비결정성 후보를 배제합니다. 부동소수점 연산 순서나 플랫폼·최적화 차이, 해시 컨테이너나 포인터 주소에 의존한 순회 순서, 난수 시드를 시뮬레이션과 연출이 공유하는 경우, 실제 프레임 델타 타임에 의존한 로직, 비결정적인 물리 엔진 사용 등이 대표적입니다. 대응은 시뮬레이션 계층을 고정 스텝·고정 순서로 만들고 정렬된 컨테이너와 전용 난수 스트림을 쓰는 것이며, 오차가 누적되는 구조면 고정소수점 도입까지 검토하겠습니다.

먼저 스레드 타임라인 프로파일링으로 워커가 실제로 일하고 있는지, 아니면 메인 스레드가 기다리고 있는지부터 봅니다. 흔한 원인은 세 가지입니다. 첫째, 잡 단위가 너무 잘게 쪼개져 스케줄링·동기화 오버헤드가 작업 시간보다 큰 경우. 둘째, 잡 사이 의존성 체인이 길어 결국 직렬 구간이 남는 경우로, 병렬화되지 않는 구간이 한계를 정합니다. 셋째, 공유 자료구조에 락이 걸려 경합하거나 렌더 커맨드 생성처럼 메인 스레드에서만 가능한 일이 남아 있는 경우입니다. 확인 후에는 잡 크기를 키우고 의존성을 줄이며, 공유 쓰기를 스레드별 버퍼로 분리해 병합하는 방향으로 손보겠습니다.

가장 먼저 의심하는 건 실행 파일 버전과 에셋 번들 버전의 불일치입니다. 제보 유저의 클라이언트 빌드 번호, 받은 카탈로그 버전, 번들 해시를 로그로 수집해 정상 유저와 비교하는 것이 첫 단계입니다. 흔한 원인은 CDN 엣지나 단말 로컬 캐시에 구버전 번들이 남아 새 카탈로그와 섞이는 경우, 그리고 번들 간 의존 관계가 있는데 일부만 갱신돼 참조가 깨지는 경우입니다. 대응은 카탈로그와 번들에 버전·해시를 강제 검증해 불일치 시 재다운로드하게 만들고, 우선 직전 버전으로 롤백해 피해를 막은 뒤 원인을 고칩니다. 이후에는 의존 관계가 있는 번들을 함께 묶어 배포하는 규칙을 세우겠습니다.

무작정 코드를 뒤지기보다 데이터로 범위를 좁히는 순서로 갑니다. 먼저 심볼을 제대로 복원해 콜스택이 의미 있게 보이는지 확인하고, 같은 원인으로 묶이는 이슈를 그룹핑해 발생 빈도와 영향 유저 수로 우선순위를 정합니다. 다음으로 리포트의 부가 정보에서 공통점을 찾습니다. 기기·OS·메모리 용량, 직전 씬, 특정 콘텐츠 진입 여부 같은 조건이 몰려 있으면 가설이 나옵니다. 메모리 부족이나 해제된 객체 접근처럼 흔한 패턴은 그쪽 코드를 우선 점검합니다. 재현이 안 되면 다음 패치에 브레드크럼 로그와 방어 코드를 넣어 크래시 직전 흐름을 수집하고, 가설을 하나씩 검증하는 방식으로 접근하겠습니다.

고무줄 현상은 대부분 예측 결과와 서버 권위 상태가 벌어졌을 때 그 차이를 한 번에 적용해서 생깁니다. 서버가 보낸 확정 상태와 시퀀스 번호를 받으면 클라이언트는 그 시점으로 되돌린 뒤 아직 확정되지 않은 입력을 다시 적용하는데, 이 재적용 결과가 크게 다르면 눈에 띄게 튑니다. 원인 후보는 서버와 클라이언트의 이동·충돌 로직 불일치, 패킷 손실이나 입력 버퍼 부족으로 서버가 입력을 누락한 경우, 넉백이나 마찰처럼 예측하기 어려운 요소입니다. 그래서 먼저 서버와 클라이언트의 확정 위치 차이를 로그로 재보고, 로직을 같은 코드로 공유하게 맞춘 뒤, 오차가 작을 때는 여러 프레임에 걸쳐 나눠 보정하는 스무딩을 적용하겠습니다.