게임 프로그래밍 포트폴리오를 고르고 공개하는 순서

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

보여줄 프로젝트를 먼저 줄입니다

많이 올리는 것보다 기준을 세우는 일이 먼저입니다

게임 프로그래밍 포트폴리오를 준비할 때 가장 흔한 실수는 만든 것을 전부 보여주려는 태도입니다. 개인 사이트나 개발자 포트폴리오에서 중요한 것은 작업량의 크기가 아니라 어떤 문제를 직접 해결했는지가 한눈에 드러나는 구조입니다.

Will Perone 같은 개발자 중심 사이트라면 게임 프로그래밍, 수학 라이브러리, 기술 프로젝트가 자연스럽게 연결되어야 합니다. 렌더링 데모 하나, 물리 계산 하나, 툴 코드 하나라도 선택 기준이 분명하면 방문자는 개발자의 강점을 더 빨리 이해합니다.

• 직접 구현한 영역이 명확한 프로젝트를 우선 고릅니다.
• 영상이나 스크린샷만 멋진 작업보다 코드 설명이 가능한 작업을 남깁니다.
• 수학, 엔진 구조, 최적화, 입력 처리처럼 전문성이 드러나는 항목을 구분합니다.
• 팀 프로젝트라면 본인이 맡은 범위와 기여도를 따로 적을 수 있어야 합니다.

포트폴리오는 작품 보관함이 아니라 판단을 돕는 기술 문서에 가깝습니다. 보여줄 것을 줄이면 오히려 개발자의 방향이 선명해집니다.

첫 목록을 만들 때는 프로젝트 이름 옆에 ‘왜 보여주는가’를 한 줄로 적어보면 좋습니다. 예를 들어 “벡터 수학 라이브러리: 충돌 판정과 카메라 이동 계산을 재사용 가능한 코드로 정리”처럼 쓰면, 단순 결과물이 아니라 사고 과정이 보입니다.

코드와 데모를 따로 보지 말고 함께 점검합니다

실행 가능한 경험이 신뢰를 만듭니다

게임 프로그래밍 포트폴리오에서 코드는 중요하지만, 코드만으로는 방문자가 체감하기 어렵습니다. 반대로 데모만 있으면 구현 깊이를 알기 어렵습니다. 그래서 공개 전에는 코드, 실행 결과, 설명 문서가 서로 같은 이야기를 하는지 확인해야 합니다.

예를 들어 수학 라이브러리를 소개한다면 단순히 “Matrix 클래스 구현”이라고 쓰는 것보다 어디에 쓰였는지 보여주는 편이 낫습니다. 카메라 변환, 충돌 판정, 보간 애니메이션, 좌표계 변환처럼 실제 게임 프로그래밍 맥락과 연결하면 검색 유입에도 유리합니다.

1. README 첫 문단에 프로젝트 목적을 3문장 안으로 적습니다.
2. 빌드 방법은 운영체제, 컴파일러, 의존성을 나누어 씁니다.
3. 데모 실행 화면은 짧은 영상이나 GIF로 보여줍니다.
4. 핵심 코드는 파일 경로와 함수 이름을 함께 안내합니다.
5. 알고리즘 설명은 수식보다 사용 장면을 먼저 제시합니다.

프로젝트 설명은 기획자의 언어도 빌려야 합니다

게임은 코드만으로 완성되지 않습니다. 규칙, 목표, 조작감, 난이도 같은 요소가 함께 움직입니다. 기획자 역할에 대한 기본 설명을 보면, 개발자가 구현할 대상이 단순 기능 목록이 아니라 플레이 경험이라는 점을 다시 확인할 수 있습니다.

따라서 포트폴리오 설명에는 “어떤 기능을 만들었다”에서 한 걸음 더 나아가 “왜 그런 구조를 선택했는가”가 들어가야 합니다. 예를 들어 A* 경로 탐색을 구현했다면, 노드 수가 늘어날 때 프레임 드롭을 어떻게 줄였는지, 디버그 뷰를 어떻게 만들었는지, 플레이어가 체감하는 변화가 무엇이었는지를 함께 적는 방식입니다.

• 나쁜 설명: 적 AI를 구현했습니다.
• 좋은 설명: 시야각, 추적 거리, 경로 재탐색 주기를 분리해 AI 상태 전환을 디버깅하기 쉽게 만들었습니다.
• 더 좋은 설명: 디버그 오버레이로 탐색 노드와 상태 변화를 표시해 튜닝 시간을 줄였습니다.

공개 전 기술 부채를 작은 표로 분류합니다

고쳐야 할 것과 설명해도 되는 것을 나눕니다

포트폴리오 프로젝트에 완벽함을 기대하면 공개가 끝없이 미뤄집니다. 반대로 미완성 코드를 그대로 올리면 개발자의 기본기가 의심받을 수 있습니다. 이 둘 사이에서 필요한 것은 감이 아니라 공개 가능 여부를 가르는 기준표입니다.

특히 게임 프로그래밍은 프레임 타임, 메모리 사용량, 입력 지연, 충돌 예외처럼 눈에 잘 보이지 않는 문제가 많습니다. 기능이 돌아간다고 해서 바로 공개할 것이 아니라, 방문자가 실행했을 때 막히는 지점을 먼저 줄여야 합니다.

• 즉시 수정: 빌드 실패, 크래시, 누락된 에셋, 깨진 링크
• 설명 후 공개 가능: 실험용 코드, 제한된 플랫폼 지원, 미완성 UI
• 숨기는 편이 나음: 역할이 불분명한 팀 작업, 출처가 모호한 에셋, 재현 불가능한 데모
• 강점으로 전환 가능: 최적화 전후 비교, 리팩터링 기록, 알고리즘 선택 이유

여기서 중요한 점은 부채를 모두 없애는 것이 아닙니다. 포트폴리오 방문자는 프로젝트가 상용 게임처럼 완성되었는지보다, 개발자가 문제를 인식하고 통제할 수 있는지 봅니다. “현재 제한 사항” 섹션을 솔직하게 적으면 오히려 신뢰가 생깁니다.

감추기 어려운 한계는 설명 가능한 구조로 바꾸는 편이 낫습니다. 개발자의 판단력은 완성된 기능뿐 아니라 남긴 주석과 제한 사항에서도 드러납니다.

예산과 시간도 개발 판단의 일부입니다

개인 포트폴리오에도 예산 개념이 필요합니다. 여기서 말하는 예산은 돈만 뜻하지 않습니다. 남은 시간, 유지보수 에너지, 빌드 환경 관리 비용, 문서화 비용까지 포함합니다. 계획예산 제도의 개념처럼 목표와 자원을 연결해 생각하면, 어떤 프로젝트를 먼저 공개할지 판단하기 쉬워집니다.

예를 들어 2주 안에 개인 사이트를 정리해야 한다면 새 엔진 기능을 추가하는 것보다 빌드 재현성, 데모 영상, 코드 설명을 다듬는 편이 효율적입니다. 이미 구현한 기능의 가치를 방문자가 이해하도록 돕는 작업이 새 기능 하나보다 더 큰 효과를 낼 수 있습니다.

• 하루 안에 끝나는 수정은 공개 전 처리합니다.
• 일주일 이상 걸리는 개선은 공개 후 로드맵으로 남깁니다.
• 설명이 어려운 기능은 별도 글로 분리해 검색 유입을 만듭니다.
• 데모 안정성에 영향을 주는 변경은 공개 직전에는 피합니다.

방문자가 읽는 순서대로 포트폴리오를 재배치합니다

첫 화면은 기술 키워드보다 판단 단서가 우선입니다

개발자는 보통 자신이 오래 붙잡은 기술부터 설명하고 싶어 합니다. 하지만 방문자는 사이트에 들어온 뒤 몇 초 안에 이 사람이 어떤 개발자인지 판단합니다. 그래서 첫 화면에는 게임 프로그래밍 개발자라는 정체성, 대표 프로젝트, 핵심 기술 키워드가 빠르게 보여야 합니다.

대표 프로젝트 설명은 너무 길지 않아도 됩니다. 대신 “무엇을 만들었는가”, “어떤 기술을 썼는가”, “왜 볼 만한가”가 분리되어야 합니다. 예를 들어 “C++ 기반 벡터 수학 라이브러리”라는 제목 아래에 충돌 계산, 카메라 제어, 테스트 코드 링크를 붙이면 포트폴리오와 기술 블로그가 자연스럽게 이어집니다.

1. 상단에는 개발자 정체성과 대표 분야를 둡니다.
2. 두 번째 영역에는 가장 강한 프로젝트 2~3개만 배치합니다.
3. 각 프로젝트에는 데모, 코드, 설명 글 링크를 같은 순서로 둡니다.
4. 블로그 글은 문제 해결 기록 중심으로 연결합니다.
5. 연락처나 GitHub 링크는 찾기 쉬운 위치에 고정합니다.

게임 개발 컨퍼런스 자료를 참고하는 독자도 있으므로, 국제 행사나 발표 맥락을 다룰 때는 GDC의 의미처럼 공신력 있는 용어 설명을 함께 연결하면 좋습니다. 다만 링크는 장식이 아니라 독자의 이해를 돕는 위치에 놓아야 합니다.

우선순위는 안정성, 설명력, 확장성 순서로 세웁니다

마지막으로 공개 직전에는 우선순위를 다시 세워야 합니다. 가장 먼저 볼 것은 안정성입니다. 실행이 되지 않는 데모, 깨진 저장소 링크, 오래된 빌드 방법은 아무리 좋은 알고리즘 설명도 흐리게 만듭니다.

그다음은 설명력입니다. 방문자가 코드를 전부 읽지 않아도 핵심 의도를 이해할 수 있어야 합니다. 마지막은 확장성입니다. 앞으로 블로그 글, 수학 라이브러리 문서, 게임 프로그래밍 실험을 계속 붙일 수 있는 구조라면 개인 사이트는 단순 포트폴리오를 넘어 개발자의 작업 기록이 됩니다.

• 1순위 안정성: 링크, 빌드, 실행, 데모 영상이 정상인지 확인합니다.
• 2순위 설명력: 프로젝트 목적, 본인 기여, 핵심 기술을 짧게 읽을 수 있게 만듭니다.
• 3순위 검색성: 게임 프로그래밍, math library, developer portfolio 같은 키워드를 자연스럽게 배치합니다.
• 4순위 확장성: 새 글과 새 프로젝트를 추가해도 구조가 무너지지 않게 메뉴를 설계합니다.

공개 버튼을 누르기 전 질문은 하나면 충분합니다. “이 페이지를 처음 보는 사람이 내가 어떤 게임 프로그래밍 문제를 잘 다루는지 설명할 수 있을까?” 그 답이 예에 가까워졌다면, 포트폴리오는 이미 보여줄 준비가 된 것입니다.