게임 프로그래밍 포트폴리오보다 개발 로그가 강했다

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

보여줄 코드가 많은데 설명할 말이 없을 때

완성작만 올렸더니 질문이 줄었습니다

개인 사이트에 게임 프로그래밍 결과물을 올릴 때 처음에는 스크린샷, 실행 파일, 짧은 소개만 있으면 충분하다고 생각했습니다. 그런데 실제로 포트폴리오를 보여주고 피드백을 받아보니, 사람들이 궁금해한 것은 결과보다 왜 그렇게 구현했는지였습니다.

Will Perone 같은 개발자 개인 사이트에서 강한 인상을 주는 지점도 단순한 프로젝트 나열이 아니라, 게임 수학과 엔진 내부 판단을 설명하는 맥락입니다. 특히 math library, collision, camera, AI 같은 주제는 코드만 보면 실력이 보이기 전에 독자가 먼저 지칩니다.

• 완성 화면은 흥미를 만들지만 깊이를 증명하기 어렵습니다.
• 코드 저장소는 근거가 되지만 읽는 사람의 시간이 많이 듭니다.
• 개발 로그는 문제, 선택지, 시행착오, 결과를 한 번에 보여줍니다.

제가 가장 크게 느낀 장점은 면접이나 협업 대화에서 다시 설명할 재료가 생긴다는 점이었습니다. “이 기능을 만들었습니다”보다 “처음에는 이렇게 망했고, 계측 후 이 방식으로 바꿨습니다”가 훨씬 오래 남았습니다.

개발 로그를 쓰기 시작한 뒤 포트폴리오가 달라졌습니다

작은 실험도 자산이 됩니다

처음에는 로그를 매일 쓰려다 실패했습니다. 게임 개발은 생각보다 흐름이 자주 끊기고, 디버깅 중에는 문장으로 남길 정신이 없기 때문입니다. 대신 저는 기능 하나가 끝날 때마다 문제-가설-구현-결과 네 줄만 적는 방식으로 바꿨습니다.

예를 들어 캐릭터가 경사면에서 미끄러지는 문제를 고쳤다면, 단순히 “버그 수정”이라고 적지 않았습니다. 접촉 노멀을 어떻게 해석했는지, 속도 벡터를 어느 축으로 투영했는지, 플레이 감각이 어떻게 변했는지까지 남겼습니다.

1. 문제 상황을 플레이어 시점 문장으로 적습니다.
2. 원인 후보를 코드나 수식 기준으로 나눕니다.
3. 실험한 값과 실패한 접근도 짧게 기록합니다.
4. 최종 선택의 장점과 남은 단점을 함께 씁니다.

이 방식은 개인 블로그에도 잘 맞았습니다. 완성작이 적어도 개발자의 사고 과정이 보이고, 검색 유입 측면에서도 game programming, developer portfolio, math library 같은 키워드를 자연스럽게 넣을 수 있었습니다.

팁: 개발 로그는 일기가 아니라 재현 가능한 기술 메모에 가깝습니다. 감상은 짧게, 판단 근거는 구체적으로 남기는 편이 오래 씁니다.

게임 수학은 코드보다 그림과 사례가 먼저였습니다

벡터 설명을 바꾸자 읽는 시간이 줄었습니다

수학 라이브러리나 게임 물리 코드를 설명할 때 가장 자주 실패한 부분은 용어였습니다. 내적, 외적, 보간, 행렬 같은 단어를 아무렇지 않게 쓰면 같은 개발자라도 읽는 속도가 크게 느려집니다.

그래서 저는 개발 로그에서 수식을 먼저 쓰기보다 “카메라가 목표를 따라가다가 왜 흔들렸는가”처럼 장면을 먼저 제시했습니다. 그다음에 벡터 차이, 길이 정규화, 보간 계수 같은 구현 요소를 붙이니 독자가 훨씬 편하게 따라왔습니다.

• 벡터: 위치 차이와 이동 방향을 설명할 때 사용했습니다.
• 행렬: 좌표 변환, 회전, 카메라 공간을 설명할 때만 꺼냈습니다.
• 보간: 애니메이션 감속, UI 이동, 카메라 추적에서 사례 중심으로 다뤘습니다.
• 난수: 재미보다 검증 가능성을 먼저 적었습니다.

특히 Will Perone 사이트처럼 game programming과 math가 함께 있는 공간이라면, 수학 설명은 포트폴리오의 핵심 경쟁력이 됩니다. 단, “수학을 안다”보다 “플레이 감각을 위해 수학을 어떻게 썼다”가 더 설득력 있었습니다.

결과 화면보다 실패 기록이 신뢰를 만들었습니다

버린 코드도 설명하면 실력이 됩니다

한 번은 2D 충돌 처리에서 직접 만든 SAT 구현을 올리려다가 망설인 적이 있습니다. 최종 코드는 짧았지만, 중간에 버린 가지가 너무 많아서 공개하기 민망했습니다. 그런데 오히려 그 실패 흐름을 쓴 글이 더 많은 피드백을 받았습니다.

독자는 완벽한 코드보다 판단 과정을 원했습니다. 왜 AABB로 충분하지 않았는지, 왜 원형 충돌만으로는 캐릭터 모서리가 어색했는지, 왜 모든 것을 물리 엔진에 맡기지 않았는지 같은 이야기가 실제 사용 후기에 가까웠습니다.

• 실패한 접근은 문제 범위를 보여줍니다.
• 버린 코드는 선택 기준을 보여줍니다.
• 남은 한계는 개발자의 현실 감각을 보여줍니다.

이런 글은 자기 과시처럼 보이지 않는 장점도 있습니다. “제가 다 압니다”가 아니라 “이 정도까지 확인했고, 여기서 이 선택을 했습니다”라는 톤이 되기 때문입니다. 개인 개발자 블로그에서 이 차이는 꽤 큽니다.

전문가처럼 보이려면 모든 답을 가진 척하기보다, 무엇을 측정했고 무엇을 아직 모르는지 분명히 쓰는 편이 낫습니다.

기술 블로그와 포트폴리오의 독자는 서로 달랐습니다

검색 독자와 채용 독자를 나눠 생각했습니다

블로그 글을 쓰면서 가장 유용했던 변화는 독자를 둘로 나눈 것이었습니다. 검색으로 들어오는 독자는 당장 문제를 해결하고 싶어 합니다. 반면 포트폴리오를 보는 독자는 이 사람이 어떤 개발자인지 빠르게 판단하고 싶어 합니다.

그래서 같은 게임 프로그래밍 글이라도 첫 문단은 문제 중심으로 쓰고, 중간에는 구현 맥락을 충분히 넣었습니다. 마지막에는 재사용 가능한 팁을 남겨 검색 독자도, 포트폴리오 독자도 얻어갈 것이 있게 구성했습니다.

• 검색 독자: 버그 원인, 구현 순서, 주의점을 빠르게 찾습니다.
• 동료 개발자: 설계 선택과 코드 품질을 봅니다.
• 채용 담당자: 문제 해결 습관과 커뮤니케이션 방식을 봅니다.

게임 업계 행사와 개발자 커뮤니티에서 발표 자료를 볼 때도 같은 점을 느꼈습니다. 예를 들어 GDC의 용어 정의를 찾아보면, 게임 개발 지식은 개인 경험을 넘어 공유 가능한 전문 영역으로 다뤄집니다. 개인 블로그도 그 흐름을 작게 구현할 수 있습니다.

글감은 프로젝트 관리에서 더 많이 나왔습니다

코드 밖의 선택도 개발 실력입니다

흥미롭게도 오래 읽히는 글감은 순수 코드보다 프로젝트 운영에서 더 많이 나왔습니다. 작업 범위를 줄인 이유, 기능을 미룬 이유, 라이브러리를 직접 만들지 않은 이유처럼 개발자가 매일 하는 선택들이 블로그에서는 좋은 콘텐츠가 됐습니다.

실제 사용 후기 형식으로 쓰면 이 부분이 더 살아납니다. “이 툴이 좋다”보다 “3주짜리 사이드 프로젝트에서 이 툴을 써보니 빌드 시간이 줄었지만 설정 파일 관리는 귀찮았다”가 훨씬 쓸모 있습니다.

1. 처음 목표와 실제 완료 범위를 나란히 적습니다.
2. 예상보다 오래 걸린 작업을 숨기지 않습니다.
3. 다음 프로젝트에서 반복하지 않을 실수를 표시합니다.
4. 비용, 시간, 유지보수 부담을 함께 기록합니다.

이 지점에서 기획 감각도 중요해졌습니다. 기획자라는 역할을 살펴보면, 게임은 아이디어만이 아니라 구현 가능한 형태로 정리하는 과정이 필요합니다. 1인 개발자나 기술 블로거도 결국 작은 기획자처럼 범위를 자르고 우선순위를 세웁니다.

예산 이야기도 피할 수 없습니다. 무료 엔진, 유료 에셋, 테스트 기기, 빌드 서버 비용은 개발 로그의 현실감을 높입니다. 필요하다면 계획예산 제도처럼 예산을 계획과 연결해 보는 관점도 참고할 만합니다.

제가 쓰는 개발 로그 템플릿과 실제 장단점

짧지만 빠뜨리면 안 되는 항목들

여러 번 바꿔본 뒤 지금 가장 편한 형식은 한 글에 하나의 기술 판단만 담는 방식입니다. 예를 들어 “카메라 시스템 전체”가 아니라 “카메라가 벽 근처에서 떨리는 문제”만 다룹니다. 주제가 작아야 실제 경험이 선명해집니다.

템플릿은 단순합니다. 문제를 먼저 쓰고, 실패한 시도를 숨기지 않고, 최종 구현을 코드 조각이나 의사 코드로 설명합니다. 마지막에는 성능, 유지보수, 체감 품질 중 무엇이 좋아졌는지 적습니다.

• 문제: 플레이 중 어떤 불편이 있었는지 한 문장으로 씁니다.
• 환경: 엔진, 언어, 프레임 목표, 입력 장치를 적습니다.
• 시도: 성공한 방법뿐 아니라 버린 방법도 남깁니다.
• 결과: 숫자, 체감, 코드 복잡도 변화를 함께 씁니다.
• 다음 작업: 다시 열어볼 조건을 명시합니다.

장점은 글쓰기 부담이 줄고, 단점은 사소한 글이 많아질 수 있다는 점입니다. 그래서 저는 세 편 정도 쌓이면 하나의 긴 글로 묶거나, 포트폴리오 페이지에서 관련 로그를 연결했습니다. 이렇게 하면 블로그와 portfolio가 따로 놀지 않습니다.

표로 남기면 다시 보기 쉽습니다

복잡한 판단은 표가 효과적이었습니다. 특히 math library 선택, 좌표계 규칙, 데이터 구조 비교처럼 나중에 다시 헷갈릴 만한 내용은 표로 남겨야 재사용하기 좋았습니다.

• 직접 구현: 학습과 제어에는 좋지만 유지보수 부담이 큽니다.
• 엔진 기능 사용: 빠르게 안정화되지만 내부 동작을 모르면 디버깅이 막힙니다.
• 외부 라이브러리: 검증된 기능을 얻지만 버전과 의존성 관리가 필요합니다.

개인적으로는 “왜 이 선택을 했는가”를 표 아래에 꼭 덧붙입니다. 표만 있으면 비교는 되지만, 프로젝트 맥락이 사라집니다. 개발 로그는 결국 상황을 가진 기록이어야 합니다.

포트폴리오에 모든 글을 올려도 괜찮을까

많이 올리는 것보다 연결 방식이 중요했습니다

가장 많이 받은 질문은 이것입니다. “개발 로그를 많이 쓰면 포트폴리오가 지저분해 보이지 않을까요?” 제 경험으로는 양보다 구조가 문제였습니다. 모든 글을 같은 무게로 보여주면 산만하지만, 핵심 프로젝트 아래에 관련 로그를 묶으면 오히려 신뢰가 올라갑니다.

예를 들어 하나의 2D 액션 프로토타입이 있다면, 상단에는 실행 영상과 핵심 설명을 두고 아래에는 입력 처리, 카메라, 충돌, 수학 유틸리티 로그를 연결합니다. 그러면 방문자는 빠르게 훑을 수도 있고, 관심 있는 부분만 깊게 볼 수도 있습니다.

1. 대표 프로젝트는 3개 이하로 제한합니다.
2. 각 프로젝트마다 핵심 기술 로그를 3~5개만 연결합니다.
3. 오래된 실험은 삭제보다 아카이브로 이동합니다.
4. 읽는 순서를 추천해 방문자의 부담을 줄입니다.

저는 포트폴리오 첫 화면에는 완성도 높은 결과물을 두고, 상세 페이지에서 개발 로그를 보여주는 방식을 가장 만족스럽게 썼습니다. 첫인상은 선명하게, 깊이는 선택적으로 제공하는 구조입니다.

특히 Will Perone처럼 developer, game programming, math, portfolio가 한 사이트 안에 함께 있는 경우라면 이 방식이 잘 맞습니다. 결과물은 개발자의 방향을 보여주고, 로그는 그 방향이 우연이 아니라 반복 가능한 실력이라는 점을 보여줍니다.