처음 코딩을 배우면 문법은 이해했는데 막상 무엇을 만들어야 할지 막막해지는 시기가 옵니다. 수업에서는 이 시기를 짧게 넘기도록 작은 게임 하나를 정해 기능을 …
검토자가 블로그를 여는 순간
이력서에 블로그 주소가 있으면 모든 검토자가 열어 보지는 않지만, 포트폴리오에 관심이 생긴 지원자라면 한 번쯤 들어가 보는 경우가 있습니다. 이때 검토자가 보고 싶은 것은 글의 개수가 아니라, 이 사람이 문제를 어떻게 바라보고 해결하는지입니다.
예를 들어 내 게임에서 캐릭터가 벽을 뚫고 지나가는 버그를 어떻게 추적했는지, 원인이 무엇이었고 어떻게 고쳤는지 정리한 글 한 편은 강의 내용을 요약한 글 열 편보다 훨씬 많은 정보를 줍니다. 실제로 일하는 방식이 드러나기 때문입니다.
반대로 블로그를 열었는데 오래전에 멈춘 글 몇 개만 있거나, 남의 글을 옮겨 온 내용이 대부분이라면 오히려 아쉬운 인상을 줄 수 있습니다. 이력서에 적을 때는 보여 줄 만한 글이 있는지 먼저 확인하세요. 보여 줄 글이 한두 편뿐이라면 블로그 주소 대신 그 글의 링크를 포트폴리오 프로젝트 설명 옆에 직접 붙이는 방법도 있습니다. 검토자가 찾아다닐 필요 없이 바로 핵심 글을 읽을 수 있어 오히려 효과적입니다.
쓸 가치가 있는 글과 그렇지 않은 글
| 가치가 큰 글 | 효과가 적은 글 |
|---|---|
| 내 프로젝트에서 겪은 문제와 해결 과정 | 강의나 책 내용을 그대로 요약한 글 |
| 구조를 고민하고 선택한 이유를 설명한 글 | 문법을 나열한 정리 노트 |
| 성능을 측정하고 개선한 전후 기록 | 다른 블로그 내용을 옮겨 온 글 |
| 실패한 시도와 거기서 배운 점 | 공부했다는 기록만 남긴 짧은 일기 |
개념 정리 글이 쓸모없다는 뜻은 아닙니다. 다만 개념을 정리할 때도 내 말로 다시 설명하고, 내 프로젝트에서 어디에 썼는지 연결해야 가치가 생깁니다. 오브젝트 풀링을 설명하는 글이라면, 내 게임에서 총알을 재사용하도록 바꾼 뒤 무엇이 달라졌는지까지 쓰는 식입니다.
첫 글의 주제를 고르기 어렵다면 최근에 가장 오래 붙잡고 있었던 문제를 떠올려 보세요. 오래 막혔던 문제일수록 시도한 방법이 많고, 그 과정이 곧 좋은 글의 뼈대가 됩니다. 결국 해결하지 못했더라도 어디까지 원인을 좁혔는지 기록하는 것만으로 의미가 있습니다.
블로그가 공부에 도움이 되는 이유
글을 쓰려면 내가 무엇을 알고 무엇을 모르는지 분명히 해야 합니다. 머릿속에서는 이해했다고 생각한 내용도 글로 옮기려면 중간이 비어 있는 것을 발견하게 됩니다. 이 빈 곳을 채우는 과정에서 개념이 훨씬 단단해집니다.
또 블로그는 나만의 검색 가능한 기록이 됩니다. 몇 달 전에 해결한 문제를 다시 만났을 때, 내 글을 찾아보면 바로 해결할 수 있습니다. 면접 전에 프로젝트에서 겪은 문제를 다시 떠올릴 때도 블로그 기록이 큰 도움이 됩니다. 시간이 지나면 잊어버리는 세부 내용이 글에는 그대로 남아 있기 때문입니다.
글을 쓰는 습관은 입사 후에도 쓸모가 있습니다. 게임 회사에서는 기능 설계 문서, 버그 분석 보고, 기술 공유 자료처럼 글로 설명해야 하는 일이 생각보다 많습니다. 다른 프로그래머나 기획자가 읽고 바로 이해할 수 있게 쓰는 능력은 협업의 기본이 되고, 블로그는 그 능력을 미리 연습하는 공간이 됩니다.
블로그 때문에 시간을 잃는 경우
블로그를 꾸미는 데 너무 많은 시간을 쓰는 것은 흔한 함정입니다. 디자인을 고르고, 글을 예쁘게 다듬고, 매일 글을 올려야 한다는 부담에 쫓기다 보면 정작 프로젝트가 멈춥니다. 블로그는 포트폴리오를 돕는 보조 자료라는 점을 잊지 마세요.
글 개수를 채우려고 의미 없는 글을 올리는 것도 피해야 합니다. 매일 짧은 공부 일기를 올리는 것보다, 한 달에 몇 편이라도 깊이 있는 글을 쓰는 편이 훨씬 효과적입니다. 꾸준함은 글의 빈도보다 꾸준히 개발하고 있다는 흔적으로 보여 주면 됩니다. 글의 수가 아니라 한 편 한 편이 보여 주는 생각의 깊이가 평가됩니다. 프로젝트 마감이 다가올 때는 블로그를 잠시 쉬어도 괜찮습니다.
부담 없이 운영하는 방법
- 작업 중 막힌 문제와 해결 과정을 짧게 메모해 두기
- 프로젝트의 큰 단계가 끝날 때 메모를 모아 한 편의 글로 정리하기
- 글마다 문제 상황, 시도한 방법, 해결책, 배운 점의 순서 지키기
- 핵심 코드는 짧게 발췌하고, 전체 코드는 저장소 링크로 연결하기
- 포트폴리오와 관련 깊은 글은 상단에 고정해 두기
이 방식이라면 블로그를 위해 따로 시간을 많이 쓰지 않아도 됩니다. 개발하면서 자연스럽게 생긴 기록을 정리하는 것이기 때문에 프로젝트와 블로그가 함께 성장합니다. 깃허브 저장소의 설명 문서와 블로그 글을 서로 연결해 두면 검토자가 프로젝트를 더 깊이 이해할 수 있습니다.
글을 쓸 때는 다른 사람의 코드나 글을 가져올 경우 출처를 밝히고, 회사나 팀 프로젝트의 비공개 내용은 올리지 않도록 주의해야 합니다.
결론은 쓰면 좋지만, 쓰는 방식이 중요하다는 것입니다
개발 블로그는 없다고 감점되지 않지만, 잘 운영하면 포트폴리오와 면접 모두에 힘을 보탭니다. 지금 블로그가 없다면 대표 프로젝트에서 가장 고생했던 문제 하나를 골라 첫 글을 써 보세요. 그 한 편이 면접에서 꺼낼 수 있는 이야기 하나가 됩니다. 그다음부터는 프로젝트의 큰 고비를 넘길 때마다 한 편씩 쌓아 가면 됩니다.
어떤 프로젝트 경험을 글로 남기면 포트폴리오에 도움이 될지 고민된다면, SBS아카데미게임학원 게임프로그래밍 과정 상담에서 프로젝트와 기록 정리 방향을 함께 이야기해 볼 수 있습니다.
자주 묻는 질문
블로그와 깃허브 중 무엇을 먼저 정리해야 하나요?
코드와 실행 결과를 보여 주는 깃허브 저장소를 먼저 정리하는 편이 좋습니다. 블로그는 그 프로젝트의 과정을 설명하는 보조 자료로 붙이면 됩니다.
글을 잘 못 쓰는데 블로그가 오히려 마이너스일까요?
문장력보다 내용의 구조가 중요합니다. 문제, 시도, 해결, 배운 점의 순서만 지켜도 읽기 쉬운 글이 됩니다.
영어로 써야 더 좋은 평가를 받나요?
국내 회사 지원이라면 한국어로 충분합니다. 해외 취업을 준비한다면 대표 글 몇 편을 영어로 정리해 두는 것도 방법입니다.
가까운 캠퍼스에서 게임프로그래밍 알아보기
사는 곳과 가까운 캠퍼스를 고르면 수업 내용, 오시는 길, 상담 신청을 한 번에 볼 수 있습니다.