늦여름 게임 개발 포트폴리오를 진단하고 완성하는 순서

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

휴가철이 끝나고 채용 공고와 프로젝트 준비가 다시 활발해지는 늦여름에는 게임 개발 포트폴리오를 손보기 좋습니다. 새 데모를 무리하게 하나 더 만드는 것보다, 이미 만든 프로젝트에서 프로그래밍 역량이 선명하게 보이도록 구조를 바꾸는 편이 훨씬 효과적입니다.

실행 파일만 올려 두었거나 Git 저장소 주소만 나열했다면 검토자는 핵심을 찾는 데 시간을 써야 합니다. 이 글에서는 프로젝트를 선별하고, 기술 설명을 보강하고, 데모를 안정화한 뒤 실제 지원 자료로 묶는 과정을 늦여름 일정에 맞춰 다룹니다.

첫 주에는 프로젝트를 줄이고 역할부터 선명하게 만듭니다

완성작 수보다 판단 가능한 증거를 고릅니다

포트폴리오를 열었을 때 프로젝트가 일곱 개나 보이지만 각 설명이 두 줄뿐이라면 풍성해 보이기보다 초점이 흐려집니다. 반대로 두세 개의 프로젝트라도 문제 상황, 선택한 알고리즘, 구현 범위와 결과가 연결되어 있으면 검토자는 개발자의 수준을 빠르게 판단할 수 있습니다. 대표 프로젝트 2개와 보조 프로젝트 1개 정도에서 시작해 보세요.

선정 기준은 그래픽의 화려함이 아니라 지원 직무와의 관련성입니다. 게임플레이 프로그래머라면 입력 처리, 상태 전환, 전투 규칙처럼 플레이 경험에 직접 닿는 코드를 앞에 둡니다. 엔진이나 시스템 직무를 원한다면 메모리 관리, 에셋 파이프라인, 멀티스레딩, 수학 라이브러리처럼 기반 기술을 대표 사례로 올리는 편이 좋습니다.

1. 지원 직무와 연결되는가: 공고에서 반복되는 역량을 실제 코드나 동작으로 보여줄 수 있어야 합니다.
2. 본인의 기여를 분리할 수 있는가: 팀 프로젝트라면 담당 모듈과 다른 구성원의 작업을 명확히 구분합니다.
3. 실행 결과를 재현할 수 있는가: 영상뿐 아니라 빌드, 테스트 로그 또는 코드 일부로 결과를 확인할 수 있어야 합니다.
4. 기술적 선택을 설명할 수 있는가: 왜 그 자료구조와 수학 모델을 사용했는지 말할 수 있어야 합니다.
5. 실패와 개선 기록이 있는가: 처음부터 완벽했던 결과보다 병목을 발견하고 수정한 과정이 더 강한 증거가 됩니다.

프로젝트마다 한 문장 역할표를 작성합니다

팀 작업의 소개문에 “전투 시스템 개발에 참여했습니다”라고만 쓰면 실제 범위를 알기 어렵습니다. “C++로 능력 상태 전환과 쿨다운 스케줄러를 구현하고, 디자이너가 데이터 테이블에서 값을 조정할 수 있도록 편집 흐름을 연결했다”처럼 언어·시스템·사용자·결과를 한 문장에 담으세요. 기획 직군과의 협업 범위를 설명해야 한다면 게임 기획자의 역할 정의를 참고해 용어의 경계를 맞출 수 있습니다.

그다음에는 기여도를 퍼센트로 과장하기보다 소유한 기능을 명시합니다. 예를 들어 캐릭터 이동 전체를 담당했는지, 기존 이동 시스템에 벽 타기만 추가했는지, 애니메이션 상태 연결까지 맡았는지를 적습니다. 이 구분은 면접 질문의 범위를 예측하게 해 주며, 모르는 영역을 아는 척해야 하는 상황도 줄여 줍니다.

대표작을 고를 때 “가장 오래 만든 것”보다 “내 판단 과정을 가장 구체적으로 설명할 수 있는 것”을 우선하면 면접까지 이어지는 자료가 됩니다.

둘째 주에는 코드와 게임 수학의 선택 과정을 보여줍니다

코드 화면보다 문제와 제약을 먼저 설명합니다

긴 소스 파일을 캡처해 넣는 것만으로는 코드 품질을 증명하기 어렵습니다. 검토자는 프로젝트 전체 맥락을 모르기 때문에 해당 코드가 무엇을 해결하며 어떤 제약 속에서 작성되었는지 알 수 없습니다. 각 사례를 문제 상황→선택지→구현→측정 결과의 순서로 구성하면 기술적 판단이 훨씬 잘 드러납니다.

예를 들어 수백 개 투사체의 충돌 후보를 줄인 사례라면 처음부터 공간 분할 코드로 들어가지 마세요. 모든 객체 쌍을 검사했을 때 객체 수가 늘수록 CPU 비용이 급격히 증가했다는 문제를 먼저 제시합니다. 이어 균일 그리드와 쿼드트리를 비교하고, 맵 구조와 객체 분포를 근거로 균일 그리드를 선택했다고 설명해야 game programming 역량이 보입니다.

• 문제: 어느 장면에서 어떤 현상이 발생했는지 수치와 함께 기록합니다.
• 제약: 목표 플랫폼, 프레임 예산, 메모리 한도, 개발 기간을 적습니다.
• 대안: 검토한 방법을 두 가지 이상 밝히고 제외한 이유도 덧붙입니다.
• 구현: 핵심 인터페이스나 의사코드를 20~40줄 안쪽으로 보여 줍니다.
• 검증: 동일한 기기와 장면에서 측정한 전후 수치를 나란히 제시합니다.

성능 수치는 조건이 없으면 의미가 약합니다. “두 배 빨라졌다”보다 “Ryzen 5급 개발 PC, 오브젝트 1,000개, 동일 카메라 경로에서 업데이트 중앙값이 4.2ms에서 1.9ms로 감소했다”가 신뢰를 줍니다. 평균값만 쓰지 말고 가능하다면 중앙값과 상위 1% 지연도 함께 남기세요. 프레임이 간헐적으로 끊기는 문제는 평균 프레임만으로 감춰질 수 있습니다.

게임 수학은 공식보다 좌표계와 검증법을 드러냅니다

게임 수학 포트폴리오에서는 벡터 내적이나 행렬 곱 공식을 복사하는 것보다 실제 엔진에서 발생한 문제를 어떻게 다뤘는지가 중요합니다. 왼손·오른손 좌표계, 행렬의 저장 순서, 각도의 단위, 정규화 시점처럼 구현 오류가 잦은 조건을 문서 앞부분에 선언하세요. 이 네 가지가 분명하면 독자는 코드의 전치 연산과 곱셈 순서를 오해하지 않습니다.

카메라 흔들림을 줄인 사례라면 단순히 보간 공식을 제시하는 데 그치지 않습니다. 선형 보간을 프레임마다 고정 비율로 적용했을 때 프레임레이트에 따라 결과가 달라졌고, 시간 기반 감쇠식으로 바꾼 뒤 30fps와 120fps에서 유사한 응답을 얻었다는 흐름을 보여 주세요. 쿼터니언 회전처럼 기존 게시글과 겹치기 쉬운 소재 대신, 투영 행렬 검증이나 충돌 기하, 보간 안정성 등 본인의 다른 수학적 판단을 골라도 좋습니다.

1. 영벡터 정규화, 평행선 교차, 180도 회전처럼 경계 입력을 먼저 나열합니다.
2. 손으로 계산 가능한 작은 값으로 기준 결과를 만듭니다.
3. 단위 테스트와 화면 디버그 도형을 함께 사용해 수치와 시각 결과를 교차 검증합니다.
4. 부동소수점 비교에는 무조건 같은 오차 범위를 쓰지 말고 값의 규모와 연산 특성을 고려합니다.
5. 실패한 테스트가 어떤 버그를 막는지 한 줄 주석으로 남깁니다.

공개 저장소에는 빌드 배지와 테스트 실행 방법도 추가합니다. 저장소를 복제한 사람이 명령 한두 개로 테스트를 돌릴 수 있다면 라이브러리가 개인 실험을 넘어 유지 가능한 기술 자산으로 보입니다. 반대로 절대 경로, 누락된 서브모듈, 특정 IDE에만 의존하는 설정은 검토자의 첫 실행을 막으므로 늦여름 정비 기간에 우선 제거해야 합니다.

셋째 주에는 데모 빌드와 문서를 낯선 환경에서 검증합니다

다운로드부터 첫 플레이까지의 마찰을 줄입니다

개발자 PC에서 실행되는 빌드가 다른 컴퓨터에서도 열린다는 보장은 없습니다. 누락된 런타임, 잘못된 상대 경로, 보안 경고, 해상도 차이 때문에 첫 화면에 도달하지 못하는 경우가 흔합니다. 데모는 작품 자체만큼이나 배포 상태가 평가되므로, 깨끗한 환경에서 설치부터 종료까지 직접 확인해야 합니다.

윈도우 빌드라면 지원 운영체제와 그래픽 요구 사항, 압축 해제 방법, 실행 파일명을 다운로드 영역 가까이에 적습니다. 웹 데모라면 첫 로딩 용량과 지원 브라우저를 밝히고 모바일 접속에서 의도치 않은 다운로드가 시작되지 않게 설정합니다. 소스만 공개할 때도 컴파일러 버전, 외부 의존성, 빌드 명령, 예제 실행 순서를 README 첫 화면에서 찾을 수 있어야 합니다.

• 새 사용자 계정 테스트: 개발 도구와 환경 변수가 없는 계정에서 실행합니다.
• 네트워크 차단 테스트: 오프라인에서도 필요한 로컬 에셋이 정상 로드되는지 확인합니다.
• 입력 장치 테스트: 키보드·마우스만 있을 때와 게임패드가 연결됐을 때를 각각 점검합니다.
• 화면 테스트: 1080p, 울트라와이드, 창 모드에서 UI가 잘리지 않는지 봅니다.
• 종료 테스트: 설정과 저장 데이터가 정상 기록되고 프로세스가 남지 않는지 확인합니다.

테스트를 부탁할 친구가 없다면 하루 간격을 두고 직접 새 사용자처럼 접근해 보세요. 설명을 작성한 직후에는 작성자가 빠진 단계를 무의식적으로 보완하기 쉽습니다. 다운로드 링크를 받은 사람에게 아무 설명도 하지 않고 “실행해서 첫 목표를 완료해 달라”고 요청하면 실제 마찰 지점을 더 정확히 찾을 수 있습니다.

90초 영상에는 기술적 장면만 남깁니다

포트폴리오 영상은 게임 트레일러와 목적이 다릅니다. 긴 로고 애니메이션과 세계관 자막보다 구현 기능이 바로 움직이는 장면이 필요합니다. 첫 10초에는 가장 강한 결과를 보여 주고, 이후에는 기능의 입력과 반응, 디버그 화면, 개선 전후 비교를 배치하세요. 음소거 상태에서도 이해되도록 짧은 자막을 넣되 코드 전체를 영상 안에서 읽게 만들지는 않습니다.

추천 구조는 0~10초 핵심 결과, 10~35초 사용자 관점 동작, 35~65초 내부 시스템과 디버그 표시, 65~80초 전후 성능 비교, 마지막 10초 담당 범위와 링크입니다. 개발자 행사 발표에서 기술을 전달하는 방식이 궁금하다면 GDC의 성격과 배경을 살펴보고, 발표처럼 문제와 해법이 이어지는 구성을 참고할 수 있습니다.

영상, 문서, 저장소는 같은 내용을 반복하는 세 복사본이 아닙니다. 영상은 결과를 보여 주고, 문서는 판단을 설명하며, 저장소는 구현의 신뢰도를 증명하게 역할을 나누세요.

공개 전에는 라이선스와 권리 관계도 살펴야 합니다. 팀원의 코드, 구매한 에셋, 회사에서 작성한 소스, 비공개 SDK를 임의로 올리면 안 됩니다. 공개 권한이 불분명하면 실제 코드를 제거하고 구조도, 의사코드, 직접 다시 만든 최소 예제로 기술을 설명하세요. 저장소 기록에서 API 키를 삭제할 때는 현재 파일만 지우는 것으로 끝나지 않을 수 있으므로 키를 즉시 폐기하고 전체 기록 노출 여부를 확인합니다.

마지막 주에는 지원 경로를 재현하고 30분 수정에 착수합니다

검토자의 클릭 순서대로 한 번 더 걸어봅니다

완성된 포트폴리오는 프로젝트 보관함이 아니라 검토자를 위한 짧은 경로여야 합니다. 첫 화면에서 직무, 핵심 기술, 대표작, 연락 방법이 보여야 하며 각 대표작은 한 번의 클릭으로 상세 설명에 도달해야 합니다. 모바일 화면에서도 제목과 링크가 겹치지 않는지 확인하세요. 채용 담당자는 반드시 큰 모니터에서만 자료를 보지 않습니다.

영문 페이지를 함께 운영한다면 기계 번역 문장을 그대로 두지 말고 기술 용어와 동사의 일관성을 확인합니다. “participated in”을 반복하기보다 implemented, profiled, designed, integrated처럼 수행한 행동을 구체적으로 적는 편이 좋습니다. 다만 실제로 설계하지 않은 시스템을 designed라고 표현해서는 안 됩니다. 한국어와 영어 페이지의 담당 범위가 서로 달라 보이지 않게 최종 대조하세요.

1. 검색 결과나 프로필 링크에서 포트폴리오 첫 화면으로 들어갑니다.
2. 10초 안에 목표 직무와 주력 기술을 찾을 수 있는지 확인합니다.
3. 대표 프로젝트를 열고 본인 기여와 사용 기술을 찾습니다.
4. 영상 재생, 데모 다운로드, 저장소 이동을 각각 눌러 봅니다.
5. 연락처와 이력서 링크가 현재 파일을 가리키는지 확인합니다.
6. 브라우저의 비공개 창에서 접근 권한 오류가 없는지 점검합니다.

시간을 배분할 때는 모든 부분을 같은 비중으로 고치지 마세요. 목표 직무와 직접 연결되는 대표작, 실행을 막는 오류, 담당 범위 설명을 먼저 처리하고 색상이나 애니메이션 같은 장식은 뒤로 미룹니다. 한정된 자원을 목적에 맞춰 배분한다는 관점은 계획예산 제도의 기본 개념처럼 목표와 비용을 연결하는 사고와도 닿아 있습니다.

지금 타이머를 켜고 대표작 첫 화면 하나를 바꿉니다

포트폴리오 개선이 미뤄지는 가장 큰 이유는 전체 사이트를 한꺼번에 새로 만들려고 하기 때문입니다. 지금 당장 할 수 있는 행동은 단순합니다. 타이머를 30분으로 맞추고 대표 프로젝트 하나의 첫 화면에 문제, 담당 기능, 핵심 기술, 측정 결과 네 줄을 추가하세요. 디자인 도구를 열 필요도 없고 새 엔진 프로젝트를 만들 필요도 없습니다.

첫 5분에는 기존 문장에서 “참여”, “개발”, “최적화”처럼 범위가 넓은 단어에 표시합니다. 다음 15분에는 각 단어를 실제 행동과 대상 모듈로 바꾸고, 이어지는 5분에는 검증 가능한 수치를 넣습니다. 마지막 5분에는 처음 보는 사람이 이해하지 못할 사내 용어와 프로젝트 약어를 풀어 씁니다.

• 문제: 적 300개가 등장하는 전투에서 프레임 시간이 순간적으로 25ms를 넘었습니다.
• 담당: 개체 업데이트 스케줄러와 거리 기반 활성화 규칙을 직접 구현했습니다.
• 기술: C++, 데이터 지향 배열, 프로파일러 마커, 자동 성능 장면을 사용했습니다.
• 결과: 동일 장면의 프레임 시간 상위 1% 값을 25ms에서 14ms로 낮췄습니다.

수치가 아직 없다면 꾸며 쓰지 말고 “측정 예정”이라고 적은 뒤 재현 장면부터 만드세요. 측정 장면의 카메라 경로, 개체 수, 빌드 설정을 고정하면 다음 수정의 효과도 비교할 수 있습니다. 이 작은 작업은 문장 하나를 고치는 데서 끝나지 않고, 부족한 테스트와 기록을 찾아내는 출발점이 됩니다.

늦여름 저녁 한 번을 전면 개편에 쓰기보다 대표작 첫 화면의 네 줄을 완성하는 데 사용해 보세요. 30분이 끝나면 비공개 창에서 그 페이지를 다시 열고, 기술을 모르는 지인이 읽어도 “어떤 문제를 무엇으로 해결했는지” 답할 수 있는지 확인하는 것까지가 오늘의 행동입니다.