이직 준비: 2026.08 Unreal·Unity 클라이언트와 개발 PM 채용 분석

상세 비교 표본 12건#

크래프톤 공고는 게임잡 상단에 경력 7년 이상으로 표시되지만 상세 본문은 엔진 개발 또는 상용 엔진 사용 5년 이상을 요구한다.

마감 상태는 2026년 8월 22일 확인 기준이다. 스마일게이트 네 공고는 회사 채용 페이지의 8월 31일을 따랐다.

표본 밖에서는 8월 21일 등록된 니오스트림의 Little Devil Inside 그래픽스 엔지니어가 새로 눈에 들어왔다. UE5·C++·HLSL과 Nanite·Lumen·Ray Tracing, 최적화·프로파일링을 함께 요구하는 자리다. 표본 수를 유지하려고 기존 공고와 바꾸지는 않았다. 다만 엔진·그래픽스가 별도 전문 트랙이라는 흐름은 여기서도 확인된다.

상세 비교 표본 12건#

12건 모두 2026년 8월 22일에 지원 가능한 상태를 다시 확인했다. 네오위즈 공고는 기존 ROUND8 표기가 아니라 현재 회사 원문의 ASTRA9 Studio 명칭을 반영했다.

확인한 전용 공고 17건#

에이블게임즈와 기어세컨드는 핵심 요건을 이미지로 올렸다. 넷마블네오의 공개 텍스트는 포트폴리오 안내가 중심이었다. 세 공고를 빼고 업무·자격 요건을 충분히 읽을 수 있었던 14건만 아래 빈도표의 분모로 삼았다.

클라이언트 개발은 역할 전문성으로 갈린다#

클라이언트 표본은 담당 업무·필수·우대에 신호가 명시된 경우만 공고당 한 번 셌다. 엔진을 쓴다는 이유만으로 당연히 알 것이라 추론한 기술은 제외했다. 한 공고가 여러 항목에 들어가는 것은 허용했다.

Unreal 실무가 핵심인 공고는 Unreal 표본의 9/12였고 C/C++·객체지향을 필수 또는 핵심으로 둔 공고는 8/12였다. Dedicated Server·Replication과 엔진 소스·RHI·RDG가 역할을 가르는 신호였다. Unity 표본에서는 9/12가 C#을 본문에 명시했다. 구조 설계·자료구조·알고리즘·객체지향 또는 엔진 내부 구조를 적은 공고는 9/12였다. UGUI만 보는 것도 아니었다. Addressables·AssetBundle·URP, 모바일 네이티브 연동, SDK·스토어 배포, DOTS·Burst가 역할에 따라 따로 등장했다.

이 차이에는 표본 구성도 한몫했다. Unreal 쪽에는 한 대형 프로젝트의 전투·콘텐츠·레벨 직무를 나눠 담은 반면, Unity 쪽에는 모바일 라이브, PC·Steam, 플랫폼 SDK와 엔진 최적화 역할을 넓게 배치했다. 그래서 9/12 대 5/12 같은 차이를 엔진의 시장점유율이나 절대 수요로 해석해서는 안 된다.

역할로 다시 묶으면 클라이언트 개발은 네 갈래다.

1. 게임플레이·콘텐츠·UI: 전투, 퀘스트, 플레이 로직, 카메라·시퀀스, UI와 제작 도구를 맡는다. 경험은 Unreal의 C++·Blueprint·UMG, Unity의 C#·UGUI와 데이터·에셋 흐름으로 드러난다.
2. 온라인·네트워크: 서버 권한, 상태 동기화, 지연과 대규모 부하가 주된 문제다. Unreal의 Dedicated Server·Replication과 Unity의 소켓·멀티플레이 SDK는 기술 이름만 다를 뿐 같은 시스템 질문으로 이어진다.
3. 플랫폼·출시·SDK: 빌드, 스토어, 네이티브 연동, 포팅과 자동화를 다룬다. 이번 Unity 표본에서는 모바일 SDK와 Steam·다중 플랫폼 경험이 별도 역할로 또렷하게 나타났다.
4. 엔진·성능: 메모리·로딩·렌더링, 프로파일링, 엔진 소스 또는 Bridge/API의 영역이다. 몇 개의 기능을 만들었는지보다 원인을 어떻게 분석했고 여러 팀이 재사용할 해결책을 남겼는지가 중요하다.

직무명은 모두 클라이언트 프로그래머에 가깝다. 그래도 면접에서 확인하는 증거는 서로 다르다. 모든 기술을 한 장에 같은 비중으로 늘어놓지 말고 지원 트랙에 맞춰 대표 사례의 순서를 바꾸는 편이 낫다.

개발 PM은 기술보다 소유 범위를 묻는다#

개발 PM 공고에서 엔진 이름이 직접 나온 경우는 3/14에 그쳤다. 일정과 협업은 14/14, 프로세스는 13/14였다. 개발 지식이 있으면 회의에서 기술 제약을 알아듣고 빌드·QA·배포 흐름을 파악하기 좋다. 그렇다고 코딩 경력이 그대로 PM 경력이 되지는 않는다. 일정 충돌을 누가 드러냈는지, 의존성을 어떻게 정리했는지, 판단을 어디에 기록하고 끝까지 추적했는지가 핵심이다.

신입 가능 공고가 3건이어서 전환 경로가 완전히 닫힌 것은 아니다. 다만 17건 중 13건이 경력을 요구했고 8월 신규 등록도 3건뿐이었다. 개발 PM을 개발자의 우회 지원처로 여길 수 없는 이유다. 지금까지 맡은 조율과 운영 범위를 먼저 검증한 뒤 별도 이력서로 접근해야 한다.

출시 경험은 결과보다 문제의 범위를 보여 준다#

Unreal·Unity 표본에서 출시·라이브 경험은 각각 9/12에 등장했다. 단순히 출시작이 있는지를 묻는다기보다 어떤 범위의 문제를 풀어 봤는지 확인하는 신호에 가깝다. 개발 막바지에는 메모리와 프레임타임, 패키징, 플랫폼 SDK, 데이터 호환성, 콘텐츠 회귀와 일정 사이의 선택이 한꺼번에 생긴다. 같은 구간을 개발 PM은 마일스톤, 부서 간 의존성, 위험과 배포 판단의 문제로 다룬다.

개발 포트폴리오는 기능 목록 대신 문제 → 제약 → 분석 → 구현 → 측정 → 결과의 흐름으로 쓰는 편이 낫다. PM 전환 사례는 요청 → 의존성 → 일정·위험 → 결정 → QA·배포 순서가 알맞다. 어느 쪽이든 실제로 맡지 않은 소유권을 보태면 안 된다.

가장 가까운 지원 트랙#

1. Unreal 게임플레이·온라인: UE5·C++, 전투·AI·UI, 16인 replication과 최적화가 직접 근거로 쓰인다. Dedicated Server·예측이 필수라면 지원 전에 간극부터 확인한다.
2. Unity PC·2D 게임플레이·콘텐츠·플랫폼: 가장 가까운 경험은 출시된 Unity 게임의 핵심 시스템·UI다. Steamworks·Stove, Windows·macOS와 컨트롤러 대응도 바로 이어진다.
3. Unity XR·실시간·애니메이션: VR 네트워크 스트리밍과 다중 사용자 좌표 정합을 직접 다뤘다. 트래커와 Humanoid 리타기팅은 흔치 않은 경험이기도 하다.
4. 개발 PM 전환: 요구 구조화와 다직군 조율, 문서화, 빌드·QA 흐름이 출발점이다. 일정·마일스톤·의존성·위험을 소유한 증거가 없으므로 경력 PM이 아닌 전환형 공고로 범위를 좁힌다.
5. Unity 모바일·라이브·SDK: Unity·C#과 출시 경험은 옮겨 쓸 수 있다. 최근 모바일 스택의 증거가 얕아서 필수요건이 낮은 공고부터 골라야 한다.
6. Unreal 엔진 Low Level·Unity 렌더링/DOTS: 성능 문제를 해결한 경험이 출발점이다. 현재 이력서만으로는 전문 역할의 핵심 증거가 부족해 도전 트랙으로 남긴다.

P0 — 지원 전에 바로 정리할 것#

1. 이력서 첫 화면을 세 벌로 나눈다. Unreal 버전은 UE5·C++, replication·AI 최적화, UE4→UE5와 Night of the Dead 1.0으로 시작한다. Unity 버전의 첫 사례는 C#·Unity로 만든 PC·macOS 게임의 핵심 시스템·UI다. 개발 PM 전환 버전에는 요구 구조화, 부서 간 결정, 문서, 빌드·QA 흐름을 앞세운다.
2. PM 이력서에는 맡았던 범위까지만 쓴다. 기술 리딩과 조율을 일정·예산·인력 관리로 바꾸지 않는다. 내가 내린 결정과 참여자, 충돌한 제약, 후속 행동과 결과를 한 사례로 엮는다.
3. 새 대형 샘플을 만들기 전에 기존 출시·VR 사례부터 정리한다. 문제 → 제약 → 설계 → 구현 → 측정 → 결과 순서로 다시 쓰되 회사 코드·데이터는 뺀다. 화면·다이어그램·수치도 공개 가능한 것만 쓴다.
4. 성능 수치에는 측정 문맥을 붙인다. 실제로 사용한 도구와 테스트 맵·개체 수·하드웨어·빌드 설정을 함께 기록한다. 정확성과 공개 가능성을 확인한 범위까지만 적는다.
5. 공통 면접 기반도 보강한다. C++의 수명·소유권·멀티스레딩, C#의 GC·비동기·객체 설계, 자료구조·알고리즘을 암기 항목으로 두지 말고 프로젝트의 결정과 연결해 설명한다. PM 전환 면접에서는 같은 프로젝트의 의존성·위험·우선순위 질문까지 준비한다.

P1 — 필요한 증거만 작게 보강할 것#

• Unreal 온라인 역할에 집중할 때는 작은 UE5 Dedicated Server 샘플 하나면 된다. 상태 소유권, relevancy·dormancy, 지연·부하 테스트, Unreal Insights와 Automation Test를 한데 묶는다.
• Unity 공고에서 최근성이 계속 걸리면 작은 Unity 6 샘플을 만든다. Addressables, Profiler·Memory Profiler, Edit/Play Mode Test와 한 플랫폼 빌드까지 보여 준다.
• 개발 PM 전환에는 새 앱보다 공개 가능한 운영 사례가 먼저다. 실제 프로젝트 하나를 요청 → 의존성 → 마일스톤·위험 → 결정 기록 → QA·배포 순으로 정리한다. 직접 소유한 범위와 지원한 범위는 분명히 가른다.

세 가지를 한꺼번에 만들 필요는 없다. 실제 지원 목록의 필수요건에서 반복되며 면접에서 바로 검증될 증거 하나부터 끝낸다.

P2 — 지원 트랙별로 선택할 것#

• 게임플레이·콘텐츠: Blueprint와 C++의 책임 경계, UMG·Slate, 에디터 확장과 데이터 검증
• 온라인·네트워크: prediction·lag compensation, 네트워크 프로파일링, 보안·치팅 대응
• Unity 콘텐츠·플랫폼: UGUI·UI Toolkit, Addressables, IL2CPP·네이티브 플러그인, 모바일·스토어 빌드
• 엔진·플랫폼: UObject·GC·Asset Manager·비동기 로딩, Unreal RHI·엔진 소스 분석, DOTS·Burst·Jobs, PIX·RenderDoc·VTune
• 개발 PM: WBS·마일스톤·의존성·위험 기록, Jira·Confluence·Notion, 빌드·브랜치·QA·배포 흐름
• 대형 스튜디오 개발 환경: 보유한 GitLab·TeamCity·Linear 경험을 Perforce·Jira·Jenkins 흐름에 어떻게 옮길지 설명

공백을 한 번에 전부 채우지 않는다. 실제 지원 공고의 필수요건에서 두 번 이상 반복되는 항목부터 고른다.