게임 개발(클라이언트/서버) 면접 준비 예시

픽셀브릿지에서 중급 기기 12종으로 전투 장면을 측정했을 때 평균 프레임이 38이고 드로우콜이 320개였습니다. 저는 먼저 프로파일링 결과를 기기와 장면별로 비교해 렌더링 호출이 후반 전투에서 반복되는 점을 확인했습니다. 코드 연산보다 텍스처 전환과 오브젝트 생성이 우선 병목이라고 판단해 텍스처 아틀라스를 재구성하고 반복 전투 객체에 풀링을 적용했습니다. 같은 기기와 장면에서 다시 측정하니 드로우콜은 140개, 평균 프레임은 57로 개선됐습니다. 측정 조건을 고정해야 변경 효과를 분리해 판단할 수 있다는 점을 배웠습니다.

기존에는 실력 구간을 고정해 대기 시간이 길어졌고, 조건을 한꺼번에 풀면 경기 품질이 흔들릴 수 있었습니다. 저는 대기 시간에 따라 실력 허용 폭을 넓히는 4단계를 설계하고, 각 단계에서 팀 간 실력 차가 급격히 커지지 않도록 상한을 두었습니다. 적용 전후 2주간 매칭 로그를 비교하고, 대기 시간뿐 아니라 재요청 비율과 경기 결과 편차도 확인했습니다. 평균 대기 시간은 42초에서 11초로 줄고 실패 재요청 비율은 9퍼센트에서 2퍼센트로 낮아졌습니다. 대기 시간과 품질을 함께 봐야 조건 완화가 의미 있다는 점을 배웠습니다.

재화 3종과 상품 48개를 운영하면서 클라이언트와 서버에 결제 판단이 나뉘어 지급 누락 문의가 반복됐습니다. 저는 클라이언트가 보낸 결제 완료 여부를 그대로 신뢰하지 않고, 서버에서 거래 식별 정보와 상품 지급 조건을 확인한 뒤 지급하도록 흐름을 통합했습니다. 같은 거래가 재전송돼도 중복 지급되지 않도록 처리 결과를 기록하고, 실패 응답은 재확인할 수 있게 분기했습니다. 변경 후 월간 지급 누락 문의는 21건에서 2건으로 줄었습니다. 지급의 최종 판단을 서버에 모으는 것이 이용자 신뢰와 운영 대응 모두에 중요하다는 점을 배웠습니다.

화면 전체를 저장하면 경기 한 건에 평균 12메가바이트가 필요해 저장 부담이 컸습니다. 저는 입력과 난수 시드를 기록하고 같은 입력을 재생하는 방식을 선택했습니다. 재생 환경이 달라질 때 결과가 흔들리지 않도록 물리 연산 간격을 16.6밀리초로 고정하고, 원본과 재생 결과를 자동 비교하는 검증 절차를 만들었습니다. 3,400건을 대조해 발견한 불일치 7건은 입력 순서와 연산 시점 차이를 추적해 수정했고, 재검증에서 불일치는 0건이었습니다. 검증 범위를 넓히고 조건을 고정하는 것이 재현성의 출발점임을 배웠습니다.

전투 후반 프레임 저하가 생기면 저는 먼저 재현 가능한 기기와 전투 구간을 정하고, 같은 조건에서 프레임 시간과 메모리 할당, 드로우콜을 함께 기록하겠습니다. 픽셀브릿지에서도 중급 기기 12종을 비교해 평균 프레임 38과 드로우콜 320개를 확인한 뒤 렌더링 호출을 우선 개선했습니다. 후반에만 악화된다면 누적 생성 객체와 에셋 로딩, 이펙트 증가 여부를 앞 구간과 비교해 원인을 나누겠습니다. 이후 가장 큰 비용을 만드는 항목부터 수정하고 동일 조건으로 재측정하겠습니다. 실제로 드로우콜을 140개로 줄이고 프레임을 57까지 높였습니다. 원인 확인과 재측정을 한 묶음으로 해야 안전한 최적화가 된다는 점을 배웠습니다.

접속자 수가 안정적이어도 큐가 늘면 요청 처리량과 매칭 완료율, 큐 대기 시간의 분포를 먼저 보겠습니다. 픽셀브릿지에서는 접속자 수만 기준으로 삼으면 큐 증가를 늦게 포착할 수 있어, 접속자 수와 큐 길이를 오토스케일 판단 지표로 함께 구성했습니다. 저는 두 지표가 동시에 악화되는 구간과 인스턴스 증설 뒤 회복 시간을 비교해 확장 기준을 정리했습니다. 매치 서버는 초당 평균 140건의 요청을 처리했고, 운영 중 큐 변화에 따라 확장 여부를 판단할 수 있게 됐습니다. 단순 접속자 수보다 실제 대기열과 처리 용량을 함께 봐야 병목에 맞는 대응을 할 수 있다고 배웠습니다.

경기 결과 저장 구조를 직접 설계한 경험은 없습니다. 다만 픽셀브릿지에서 입력과 난수 시드만 기록해 경기 한 건의 저장 용량을 12메가바이트에서 90킬로바이트로 줄이고, 3,400건을 재생 대조한 경험이 있습니다. 결과 데이터는 경기 식별자와 참가자, 판정 결과처럼 조회에 필요한 항목을 영속 저장하고, 상세 입력 기록은 별도 보관 주기와 접근 패턴을 고려해 분리하겠습니다. 캐시에는 대기 중이거나 자주 조회되는 임시 정보를 두고, 최종 결과는 영속 저장소와 대조하겠습니다. 입사 후 첫 한 달 안에 기존 경기 흐름과 조회 요구를 파악하고, 서버팀과 저장·재시도·중복 기록 검증 기준을 정리하겠습니다.

저는 먼저 매칭 지연과 기기별 크래시가 같은 배포 시점부터 늘었는지 지표와 버전을 나눠 확인하겠습니다. 픽셀브릿지에서는 크래시 리포트를 기기와 발생 빈도별로 묶어 상위 원인 9건을 수정했고, 크래시 발생률을 1.4퍼센트에서 0.3퍼센트로 낮췄습니다. 같은 기간의 매칭 대기 시간과 큐 길이도 함께 비교해 공통 배포 요인인지 별개 서버 부하인지 나누겠습니다. 이용자 영향이 큰 반복 크래시와 급격히 늘어난 대기 지표를 우선 재현하고, 수정 후 같은 기기군과 시간대의 지표를 확인하겠습니다. 증상을 한 원인으로 단정하지 않고 영향 범위부터 좁히는 것이 중요하다고 배웠습니다.

실시간 네트워크 동기화나 롤백을 구현한 경험은 없습니다. 가장 가까운 경험은 픽셀브릿지에서 입력과 난수 시드를 기록해 전투를 재생하고 결과를 대조한 일입니다. 저는 물리 연산 간격을 16.6밀리초로 고정하고 3,400건을 자동 비교해 불일치 7건을 찾아 수정했으며, 재검증에서 불일치 0건을 확인했습니다. 이 경험은 재현성과 판정 검증에 관한 것이지 실시간 동기화 구현과 같지는 않습니다. 입사 후 첫 한 달 동안 클라이언트 입력부터 서버 판정까지 흐름을 따라가고, 이후 비공개 테스트에서 지연·패킷 순서 변화에 따른 불일치 사례를 수집해 보정 방식의 요구사항을 익히겠습니다.

게임플레이 입력 검증이나 안티치트 탐지 구조를 구현한 경험은 없습니다. 다만 픽셀브릿지에서 재화 3종과 상품 48개의 지급 흐름을 서버 단일 검증으로 바꾸며, 클라이언트의 결제 완료 판단을 최종 근거로 삼지 않도록 했습니다. 저는 서버가 거래 정보와 지급 조건을 확인하고 같은 거래의 중복 처리를 막도록 흐름을 정리해 월간 누락 문의를 21건에서 2건으로 줄였습니다. 이는 재화 지급 검증 경험이며 전투 입력 검증과는 다릅니다. 입사 후 첫 한 달에 서버 판정 경로와 신뢰 경계를 파악하고, 3개월 안에 입력 유효성 검사와 비정상 요청 로그 기준을 테스트 시나리오로 정리하겠습니다.

아라온게임즈에서 스테이지 1,200개를 수작업으로 반영해 밸런스 변경 한 번에 약 3시간이 걸렸습니다. 저는 반복 입력과 형식 변환을 자동화하되, 콘텐츠 담당자가 난이도와 실제 플레이 흐름을 확인하는 단계는 남겼습니다. 스프레드시트 데이터를 읽어 게임 데이터로 변환하는 도구를 만들고, 필수 값 누락과 허용 범위를 자동 검사하도록 구성했습니다. 반영 시간은 20분으로 줄었고, 변경 뒤에는 담당자가 샘플 스테이지를 확인한 다음 전체 적용 결과를 점검했습니다. 자동화는 검수를 없애는 것이 아니라 사람이 판단해야 할 부분에 시간을 돌려주는 방식이어야 한다고 배웠습니다.

운영팀이 재화 지급과 회수 요청을 수작업으로 전달해 주 14건 정도의 반복 요청이 발생했습니다. 저는 자주 반복되고 대상과 수량을 명확히 지정할 수 있는 작업을 골라 운영툴 기능 6종으로 만들었습니다. 지급·회수 전에 대상 계정과 재화 종류, 수량을 다시 확인하는 입력 절차를 두고, 처리 결과를 기록해 운영팀이 완료 여부를 확인하도록 구성했습니다. 적용 뒤 수작업 요청은 주 3건으로 줄었습니다. 운영 편의만 높이면 실수 위험도 커질 수 있어 확인과 기록을 기능 안에 함께 두는 것이 중요하다는 점을 배웠습니다.