게임 개발자 면접 질문 목록
가장 흔한 게임 개발자(Game Developer) 면접 질문을, 리크루터가 실제로 무엇을 보고 걸러내는지에 기반한 예시 답변과 준비 팁과 함께 정리했습니다. 면접까지 왔다는 것 자체가 이미 가파른 관문을 넘었다는 뜻입니다. Ashby의 2026년 스타트업 데이터에 따르면 기술 직무는 지원→면접 전환율이 약 5.6%였습니다. [1] 아직 그 단계까지 못 갔다면, Specific이 직무별로 맞춘 이력서를 만드는 것을 도와드릴 수 있습니다.
가장 흔한 게임 개발자 면접 질문
- 자기소개를 해주세요
- 왜 이 게임 개발자 역할을 원하시나요
- 가장 자랑스러운 게임 프로젝트는 무엇인가요
- 가장 많이 사용하는 게임 엔진과 프로그래밍 언어는 무엇인가요
- 게임플레이 프로그래밍을 어떻게 접근하나요
- 게임 성능을 어떻게 최적화하나요
- 추적하기 어려웠던 버그에 대해 이야기해 주세요
- 디자이너, 아티스트, QA와는 어떻게 협업하나요
- 타이트한 마감이나 크런치 기간을 어떻게 대응하나요
- 비판적인 피드백을 받은 경험을 말해 주세요
- 코드 품질과 일정 준수(제때 출시)를 어떻게 균형 잡나요
- 멀티플레이어 또는 네트워크 시스템 경험은 어느 정도인가요
- 게임 개발 환경에서 코드를 어떻게 테스트하나요
- 컨셉부터 출시까지 만든 기능 하나를 설명해 주세요
- 여러 이슈가 동시에 우선순위를 다툴 때 어떻게 정하나요
- 게임 개발 도구와 트렌드를 어떻게 최신으로 유지하나요
- 게임 개발자로서 업무에 AI 도구를 어떻게 활용하나요
- AI가 생성한 코드나 콘텐츠를 사용하기 전에 어떻게 검증하나요
- 게임 개발자로서 강점과 약점은 무엇인가요
- 저희에게 질문 있으신가요
답변을 해당 직무에 맞게 구체화하세요. 같은 면접 질문이라도 포지션에 따라 필요한 답이 크게 달라질 수 있습니다. 게임 개발자라면 엔진 경험, 디버깅, 성능, 협업, 출시(Ship)한 기능을 강조해야지, 다른 직무/후보자가 강조할 포인트와 같을 필요가 없습니다. 그래서 범용 지원서류보다, 맞춤 이력서와 타깃팅된 게임 개발자 커버레터가 더 잘 먹히는 경우가 많습니다.
게임 개발자 면접 질문과 답변(상세)
1. 자기소개를 해주세요
리크루터는 이 질문으로 당신이 본인의 배경을 명확하고 직무 관련성 있게 요약할 수 있는지 봅니다. 인생사를 묻는 게 아닙니다. 개발자로서 “나는 누구인지”, 어떤 게임/시스템을 해봤는지, 그리고 왜 이 역할에 경험이 맞는지의 ‘압축 버전’을 원합니다.
예시 답변: 저는 Unity와 C# 기반으로 게임플레이 중심 개발을 해왔고, 지난 몇 년간 소규모~중간 규모 프로젝트에서 플레이어 시스템, 전투 밸런싱(튜닝), 성능 최적화를 담당해 왔습니다. 최근 역할에서는 프로토타입부터 출시까지 전체 사이클로 기능을 출시했고, 플레이어가 직접 체감하는 시스템을 다듬기 위해 디자인과 QA와도 밀접하게 협업했습니다. 이 포지션에 관심이 있는 이유는, 엔지니어링 완성도와 플레이 감각(Feel)을 모두 중요하게 보는 더 큰 프로덕션에서 일할 기회라고 느꼈기 때문입니다.
2. 왜 이 게임 개발자 역할을 원하시나요
동기와 핏을 보는 질문입니다. 채용팀은 당신이 그들의 게임/스튜디오/플랫폼을 이해하고 있는지, 그리고 “일이 필요해서요” 이상의 지원 이유가 있는지 확인합니다.
예시 답변: 이 역할을 원한 이유는 시스템 디자인과 엔지니어링의 교차점에 있고, 저희가 가장 강점을 발휘하는 영역이기 때문입니다. 귀 스튜디오 게임은 순간순간의 조작감과 기술적 폴리시가 강한데, 제가 기여하고 싶은 환경이 בדיוק 그런 방향입니다. 특히 엔지니어링, 디자인, 아트가 촘촘히 반복(iteration)하는 팀에서 플레이어-facing 기능을 만들 수 있다는 점이 매력적입니다.
3. 가장 자랑스러운 게임 프로젝트는 무엇인가요
주인의식, 문제 해결력, 그리고 ‘취향/완성도 기준’을 보여달라는 의도입니다. 출시한 작업물, 사이드 프로젝트, 게임잼, 모드, 포트폴리오를 보여주기 좋은 질문입니다. 주니어라면 프로젝트 규모보다 프로젝트의 퀄리티와 설명 방식이 더 중요합니다.
예시 답변: 가장 자랑스러운 건 Unreal로 만든 코옵 프로토타입인데, 그 안에서 플레이어 어빌리티 시스템과 전투 피드백 루프를 제가 오너십을 갖고 담당했습니다. 어빌리티 입력을 단순화하고, 애니메이션 타이밍을 조정하고, 타격 피드백을 더 명확히 하면서 플레이테스트 초반 세션 리텐션을 22% 개선했습니다. 의미 있었던 건 단순히 기능을 만든 것뿐 아니라, 실제로 “재미있게 느껴질 때까지” 디자이너/테스터와 반복 개선한 과정이었습니다.
예시 답변(주니어라면): 72시간 안에 풀 버티컬 슬라이스를 만든 게임잼 프로젝트가 가장 자랑스럽습니다. 플레이어 이동, 적 AI, 세이브 로직을 담당했고, 스코프 조절, 빠른 디버깅, 코어 루프를 해치지 않으면서 기능을 과감히 컷하는 법을 많이 배웠습니다.
4. 가장 많이 사용하는 게임 엔진과 프로그래밍 언어는 무엇인가요
핏 체크입니다. 팀은 당신이 그들의 스택에서 얼마나 빨리 생산성을 낼 수 있는지 알고 싶어 합니다. 구체적으로 말하세요. 엔진, 언어, 도구, 그리고 실제로 무엇을 했는지까지.
예시 답변: Unity와 C#을 가장 많이 사용했고, 특히 게임플레이 시스템, UI 플로우, 툴링을 많이 해왔습니다. Unreal에서는 C++과 Blueprints로 프로토타이핑과 기능 통합 작업을 해본 경험이 있습니다. 엔진 작업 외에도 Git, 프로파일링 도구, CI 워크플로우를 꾸준히 사용해 왔기 때문에, 단순히 코드만 쓰는 게 아니라 팀 파이프라인의 일부로 “출시까지” 가져가는 데 익숙합니다.
5. 게임플레이 프로그래밍을 어떻게 접근하나요
프로세스를 묻는 질문입니다. 디자인 의도를 플레이 가능한 시스템으로 어떻게 바꾸는지, 어떻게 반복 개선하는지, 그리고 과도한 설계를 어떻게 피하는지 듣고 싶어 합니다.
예시 답변: 먼저 그 기능이 만들어야 하는 플레이어 경험(결과)이 무엇인지부터 정의합니다. 게임플레이 코드는 의도한 ‘느낌’을 지원할 때만 의미가 있기 때문입니다. 그 다음 가장 작은 동작 버전을 빠르게 만들고, 디자인과 초기에 테스트한 뒤 실제 피드백을 기반으로 개선합니다. 반복이 가능할 정도로 모듈화는 하되, 단순한 변경조차 어렵게 만드는 과도한 추상화는 피하려고 합니다.
6. 게임 성능을 어떻게 최적화하나요
게임에서 성능은 중요하고, 이 질문은 추측이 아니라 데이터로 일하는지 확인합니다. 프로파일링, 병목 식별, 트레이드오프 인식이 핵심입니다.
예시 답변: 먼저 프로파일링을 해서 가장 큰 병목부터 해결하고, 무작정 마이크로 최적화를 하지는 않습니다. 한 프로젝트에서는 매 프레임 실행되던 고비용 업데이트 로직을 분리하고, 오브젝트 작업을 배치 처리하고, GC를 유발하던 메모리 할당을 정리해서 프레임 타임 스파이크를 35% 줄였습니다. 또한 성능은 보통 코드만의 문제가 아니라 아트/디자인과 얽힌 크로스 디시플린 문제라서, 관련 파트와도 긴밀히 협업합니다.
7. 추적하기 어려웠던 버그에 대해 이야기해 주세요
압박 상황에서 디버깅 방법을 보기 위한 질문입니다. 좋은 답은 구조가 있습니다: 재현 → 범위 축소(격리) → 가정 검증 → 수정 → 재검증.
예시 답변: 지연(latency)이 있을 때만 발생하는 멀티플레이 프로토타입의 간헐적 애니메이션 싱크 불일치 버그가 있었습니다. 통제된 네트워크 조건에서 재현한 뒤, 상태 업데이트가 순서가 뒤바뀌어 도착하는 문제로 범위를 좁혔고, 클라이언트가 authoritative 이벤트와 애니메이션 상태를 reconcile하는 방식을 수정해 해결했습니다. 이후 QA 세션에서 desync 제보를 약 80% 줄였고, 가장 큰 교훈은 ‘숨은 타이밍 가정’을 훨씬 더 일찍 가시화해야 한다는 점이었습니다.
8. 디자이너, 아티스트, QA와는 어떻게 협업하나요
게임 개발은 협업 비중이 큽니다. 팀은 사일로에서 코드만 치는 사람이 아니라, 직군 간 번역을 할 수 있는 사람을 원합니다.
예시 답변: 구현 디테일보다 ‘결과’ 중심으로 말해서 협업 비용을 낮추려고 합니다. 디자이너와는 동작과 튜닝에 집중하고, 아티스트와는 에셋 제약을 초기에 명확히 해서 막판에 막히는 일이 없도록 합니다. QA와는 재현 절차를 명확히 문서화하고, 버그 리포트를 방해가 아니라 유용한 신호로 다룹니다. 좋은 게임 작업은 보통 직군 간 촘촘한 반복에서 나옵니다.
9. 타이트한 마감이나 크런치 기간을 어떻게 대응하나요
회복탄력성도 일부 보지만, 대부분은 판단력을 봅니다. 시간이 없을 때 침착하게 트레이드오프를 커뮤니케이션하고 품질을 지킬 수 있는지 확인합니다.
예시 답변: 데드라인 압박에서는 불확실성을 빠르게 줄이는 게 핵심이라고 생각합니다. 필수(Must-have)와 있으면 좋은 것(Nice-to-have)으로 일을 쪼개고, 리스크를 일찍 올리고, 커뮤니케이션을 촘촘히 해서 누구도 갑자기 놀라지 않게 합니다. 필요하면 강하게 밀어붙일 수는 있지만, 더 중요한 습관은 크런치가 계획이 되지 않도록 충분히 일찍 스코프 결정을 똑똑하게 하는 것이라고 봅니다.
10. 비판적인 피드백을 받은 경험을 말해 주세요
코칭 가능성(coachable)을 봅니다. 방어적인 후보는 리스크입니다. 좋은 후보는 피드백으로 일이 실제로 좋아졌다는 걸 보여줍니다.
예시 답변: 초반에 “기술적으로는 맞지만, 한 번에 너무 많은 케이스를 해결하려다 보니 다른 사람이 이해하기 어렵다”는 코드 리뷰 피드백을 받은 적이 있습니다. 그 피드백을 진지하게 받아들여 더 작고 의도가 명확한 변경으로 쪼개기 시작했고, 의도가 더 잘 드러나면서 리뷰 턴어라운드도 좋아졌습니다. 그 경험은 저를 더 좋은 코더가 아니라, 더 좋은 팀원으로 만들어줬습니다.
11. 코드 품질과 일정 준수(제때 출시)를 어떻게 균형 잡나요
성숙도를 보는 질문입니다. 출시를 막는 완벽주의도 원치 않고, 미래의 고통을 만드는 대충 작업도 원치 않습니다.
예시 답변: 나중에 고치기 비싼 부분은 보호하고, 다시 손보기 쉬운 부분은 단순화하는 방식으로 균형을 잡습니다. 코어 게임플레이, 세이브 데이터, 네트워킹을 건드리는 시스템이라면 초기에 더 투자합니다. 반대로 빠르게 학습하기 위한 임시 구현이라면 단순하게 만들고 트레이드오프를 문서화합니다. 목표는 우아함 자체를 쫓는 게 아니라, 책임 있게 출시하는 것입니다.
12. 멀티플레이어 또는 네트워크 시스템 경험은 어느 정도인가요
모든 게임 개발자 역할에 깊은 네트워크 전문성이 필요한 건 아니지만, 많은 스튜디오가 이를 가치 있게 봅니다. 경험이 있다면 구체적으로 말하고, 없다면 솔직하게 말하되 인접 경험과 연결하세요.
예시 답변: 상태 동기화, 로비 플로우, 지연을 고려한 게임플레이 동작 등 소규모 멀티플레이 기능을 작업해 본 경험이 있습니다. 한 프로젝트에서는 재접속 로직을 강화하고 드롭된 클라이언트 관련 엣지 케이스를 정리해서 내부 테스트에서 매치 시작 실패를 18% 줄였습니다. 네트워킹 스페셜리스트를 자처하진 않지만, 멀티플레이 기초 개념에 익숙하고 필요하면 더 깊게 학습할 수 있습니다.
예시 답변(직접 경험이 제한적이라면): 대부분 싱글플레이 시스템을 해왔지만, 네트워크 제약을 염두에 두고 기능을 설계했고 프로토타입을 통해 replication, authority, prediction 모델을 학습해 왔습니다. 게임플레이 시스템을 상태/타이밍/엣지 케이스 관점에서 이미 사고하기 때문에 빠르게 생산성을 낼 수 있습니다.
13. 게임 개발 환경에서 코드를 어떻게 테스트하나요
게임은 복잡한 시스템입니다. 면접관은 수동 테스트만 하는지, 아니면 계층화된 접근을 쓰는지 알고 싶어 합니다.
예시 답변: 여러 레벨로 테스트합니다. 데이터 로직이나 안정적인 시스템은 자동화 테스트를 적용하고, 동시에 많은 게임플레이 이슈는 맥락에서만 드러나기 때문에 엔진 내 검증, 디버그 툴, 구조화된 플레이테스트도 함께 활용합니다. 추측 대신 실시간 동작을 निरी할 수 있도록 작은 디버그 뷰와 로깅 훅을 만드는 편입니다.
14. 컨셉부터 출시까지 만든 기능 하나를 설명해 주세요
오너십을 측정하는 질문입니다. 일을 끝까지 가져갈 수 있다는 걸 증명하는 가장 명확한 방법 중 하나입니다.
예시 답변: 플레이어 성장(Progression) 기능을 초기 디자인 논의부터 출시까지 리드했습니다. 일정에 맞춰 시스템을 출시했고, 성장 목표를 통한 주간 참여도를 19% 끌어올렸습니다. 디자인과 함께 보상 페이싱을 맞추고, Unity에서 코어 로직을 구현하고, 플레이테스트 피드백 이후 UI 플로우를 다듬는 방식으로 성과를 만들었습니다. 가장 중요했던 건 1차 구현에서 멈추지 않고, 폴리시까지 끝까지 관여한 점이었습니다.
15. 여러 이슈가 동시에 우선순위를 다툴 때 어떻게 정하나요
의사결정을 보는 질문입니다. 팀은 심각도, 플레이어 영향, 의존성, 그리고 프로덕션 현실을 이해하는 개발자를 원합니다.
예시 답변: 우선 플레이어 영향, 그 다음 빌드 리스크, 그 다음 의존성 순으로 우선순위를 잡습니다. 크래시나 진행(Progression) 차단 이슈는 항상 외형적인 이슈보다 우선이고, 다른 팀원을 막는 이슈는 빠르게 우선순위가 올라갑니다. 또한 “급한 것”과 “시끄러운 것”을 분리하려고 합니다. 채팅에서 가장 시끄러운 이슈가 항상 가장 중요한 이슈는 아니기 때문입니다.
16. 게임 개발 도구와 트렌드를 어떻게 최신으로 유지하나요
반짝이는 것(shiny)만 쫓지 않으면서도 계속 학습하는 사람인지 봅니다. 실용적인 학습 루프를 말해 주세요.
예시 답변: 엔진 업데이트, 포스트모템, 테크 토크, 개발자 커뮤니티를 꾸준히 보되, 새로운 도구는 실제 문제를 해결할 때만 도입합니다. 또 작은 실험을 직접 만들어보면서 많이 배우는데, 실제 프로토타입에서 워크플로를 한 번 써보는 게 글로 읽는 것보다 훨씬 많은 걸 알려주기 때문입니다.
17. 게임 개발자로서 업무에 AI 도구를 어떻게 활용하나요
게임 개발자 역할에서는 이제 AI 활용 능력이 현실적인 신호가 됐습니다. 스튜디오는 도구를 ‘마법’처럼 대하지 않고 생산적으로 쓸 수 있는지 알고 싶어 합니다. 구체적으로 말하세요.
예시 답변: ChatGPT와 Claude는 디자인→구현 브레인스토밍, 엣지 케이스 체크리스트, 문서 초안 작성에 활용하고, GitHub Copilot이나 Cursor는 보일러플레이트, 에디터 툴링, 테스트 스캐폴딩 같은 반복 코딩에 씁니다. AI는 낯선 API를 탐색하거나 1차 디버그 가설을 세울 때 특히 속도를 올려주지만, 어디까지나 보조 역할로 둡니다. 아키텍처, 구현 선택, 최종 품질은 제가 책임집니다.
18. AI가 생성한 코드나 콘텐츠를 사용하기 전에 어떻게 검증하나요
이전 질문의 ‘성숙도 체크’입니다. 회의적 시각, 검증, 도메인 판단을 듣고 싶어 합니다.
예시 답변: AI 결과물도 다른 위험한 지름길과 동일하게 검증합니다. 한 줄씩 리뷰하고, 통제된 환경에서 테스트하고, 엔진 문서와 프로젝트 컨벤션에 맞는지 확인합니다. 코드라면 숨은 가정, 성능 이슈, API 오용을 특히 봅니다. 디자인/콘텐츠 제안은 문장이 그럴듯하다고 좋은 것으로 가정하지 않고, 게임에 맞는지 직접 테스트합니다. AI는 유용하지만 여전히 환각(hallucination)과 과도한 일반화를 하기 때문에, 권위가 아니라 초안 생성기로 다룹니다.
19. 게임 개발자로서 강점과 약점은 무엇인가요
자기 인식을 봅니다. 좋은 약점은 진짜이고, 관리 가능하며, 개선 중입니다. 좋은 강점은 구체적이고 직무 관련성이 높습니다.
예시 답변: 강점은 모호한 디자인 의도를 유지보수성을 잃지 않으면서도 빠르게 플레이 가능한 시스템으로 바꾸는 능력입니다. 특히 기술적 구조와 디자인과의 반복 개선이 모두 필요한 기능에서 강합니다. 개선해 온 약점은 너무 이른 시점에 엣지 케이스 처리에 과투자하는 경향이었습니다. 지금은 먼저 가장 작고 단단한 버전을 출시한 뒤, 코어 경험이 검증된 다음에만 확장하는 쪽으로 더 좋아졌습니다.
20. 저희에게 질문 있으신가요
형식적인 질문이 아닙니다. 좋은 질문은 관심, 판단력, 시니어리티를 보여줍니다. 팀 워크플로, 성공 지표, 기술적 제약, 협업 방식 등을 물어보세요.
예시 답변: 네. 기능을 반복 개선할 때 엔지니어링과 디자인이 어떻게 협업하는지, 첫 6개월의 성공을 어떤 기준으로 보는지, 그리고 이 역할이 우선적으로 해결하길 기대하는 기술적 과제가 무엇인지 알고 싶습니다.
말하는 전달력을 더 끌어올리고 싶다면, 이 가이드로 ChatGPT로 게임 개발자 면접 질문을 연습하는 방법을 참고해서 답변을 소리 내어 연습해 보세요. 그리고 인성/상황 질문(behavioral)에는 답변이 구조적으로 깔끔해지도록 게임 개발자 면접을 위한 STAR 기법을 강력히 추천합니다.
게임 개발자 면접을 따내는 건 얼마나 어렵나요?
어려운 부분은 종종 면접 자체가 아닙니다. 면접 초대를 받는 것입니다.
1차 출처 기준으로 신뢰할 만한 2025–2026 게임 개발자 전용(직무 특화) 지원→오퍼 퍼널 데이터는 없어서, 대안으로 더 넓은 범위의 기술 채용 데이터를 보겠습니다. Ashby의 2026년 스타트업 리포트에서 기술 직무는 채용 1건당 면접을 본 지원자가 약 18명이었고, 같은 데이터셋은 기술 후보자의 **지원→면접 전환율이 대략 5.6%**임을 시사합니다. [1] 즉, 누구도 당신의 면접 실력을 평가하기 전에 이력서/지원 단계에서 이미 잔혹한 필터링이 일어난다는 뜻입니다.
게임 업계는 이직 시장에 남아 있는 경력자들(정리해고로 풀린 인력)로 인한 추가 압박도 받고 있습니다. 2026 State of the Game Industry 설문에서 게임 업계 종사자의 **17%**는 지난 12개월 내 해고를 경험했다고 답했고, **28%**는 지난 24개월 동안 해고를 경험했다고 답했습니다. [2] 같은 리포트에서 해고 경험 응답자 중 **48%**는 아직 다른 직장을 찾지 못했다고 나옵니다. [2] 그래서 게임 개발자 포지션에 지원할 때는 동년배뿐 아니라, 시장에 남아 있는 경력자들과도 경쟁하는 경우가 많습니다.
LinkedIn의 2025 Economic Graph에서도 채용 속도가 둔화되면서 구직자들이 비슷한 결과를 얻기 위해 더 많은 공고에 지원해야 했다고 말하는데, 이는 게임 외 영역에서도 퍼널이 더 붐볐다는 큰 흐름을 뒷받침합니다. [3]
핵심은 간단합니다. ‘눈에 띄는 것’이 가장 큰 병목입니다. 이력서가 리크루터의 5–8초 스캔에서 “이 역할에 맞다”는 매치를 즉시 보여주지 못하면, 아무리 실력이 좋아도 존재하지 않는 사람처럼 처리됩니다. 목표는 지원은 더 적게, 면접은 더 많이입니다. 그리고 이는 지원하는 공고마다 이력서를 맞춤화하면 가능합니다. 리크루터 심리를 더 깊게 읽고 싶다면, 게임 개발자 면접에서 리크루터가 실제로 생각하는 것도 함께 읽어볼 만합니다.
왜 지원하는 공고마다 이력서를 맞춤화해야 하나요
몇 초 만에 적합성이 드러나는 이력서는, 매번 범용 CV보다 항상 더 강력합니다. 이건 모두가 이미 알고 있습니다.
진짜 문제는 노력(시간)입니다. 지원할 때마다 이력서를 다시 쓰는 건 시간이 많이 들고 금방 지칩니다. 그래서 대부분은 “맞춤화해야지”라고 생각만 하고 실제로는 못 합니다. 하지만 이제 AI가 그걸 훨씬 쉽게 만들어줍니다.
Specific은 해당 직무에 맞춘 이력서를 쉽게 만들 수 있게 해줍니다. 빠르게 스캔해도 잘 읽히고, 역할과의 매치가 명확하며, 리크루터가 추가로 파고들 필요가 줄어듭니다. 장점은 아주 실무적입니다. 1페이지 자격요건(핵심 요약), 강한 시각적 위계, 직무기술서와 정렬된 언어, 성과 중심 불릿, ATS 친화적 포맷. 그래서 양쪽 모두에게 좋습니다. 당신은 면접으로 이어질 ‘케이스’가 더 또렷해지고, 리크루터는 더 빠르게 예/아니오 결정을 할 수 있습니다.
확률을 올리고 싶다면, 다음에 지원할 게임 개발자 공고에 맞춰 tailored resume를 만들어 보세요.
다음 지원을 위한 더 나은 게임 개발자 이력서 만들기
퍼널은 빡빡합니다. 지원은 많고, 면접은 적고, 오퍼는 더 적습니다. 그러니 이력서가 ‘면접장에 들어가게 만드는 일’을 제대로 하도록 만드세요.
면접 행운을 빕니다. 그리고 다음 지원 전에는, 면접에 초대될 확률을 높이기 위해 직무 맞춤 이력서를 생성해 보세요.
출처
- Ashby. 1,100만 건의 구직 지원 데이터를 기반으로 기술 채용 퍼널 벤치마크를 제시한 2026년 스타트업 채용 리포트.
- GDC State of the Game Industry. 해고 및 재취업 데이터를 포함해 2,300명 이상의 게임 업계 종사자를 대상으로 한 2026년 설문.
- LinkedIn Economic Graph. 2025년 노동시장 분석 리포트(구직 강도 및 지원 압박에 관한 방법론 노트 포함).
