게임 회사 공채를 지원하는 신입 개발자들에게

매년 가을이 되면 회사마다 공채가 한창이다. 너도나도 더 좋은 신입들을 뽑기 위해서 서둘러 공채 기간을 잡고, 빡빡한 일정으로 모든 심사와 단계를 마쳐서 좋은 사람을 낚아 채 간다. 

게임 업계에 어느정도 오래 있다보니 수천건의 이력서를 보아왔다. 준비를 잘 하고 매우 잘 쓴 이력서와 포트폴리오 구성도 있는 반면에 형편없고 무성의한 준비없는 자소서와 포폴을 들이미는 지원자들도 수두룩하다. 오늘도 수많은 신입 지원자들은 똘망똘망하고 순수하고 열정적인 눈빛으로 모든 것을 할 수 있을 것만 같은 마음으로 간절한 입사를 기다리고 있으리라. 그러나, 이런 점들은 한번 확인하고 갈 필요가 있다. 

첫째로 누가 누구를 판단하고 평가하는 것이 웃긴일이긴하다. 그 사람이 어떤 사람인지를 과거를 보고 판단하는 건데, 미래에 어떤 사람이 될지 누가 알겠는가. 짐작할 뿐이고, 과거의 사람이 모여 현재의 사람을 이룬다는 것을 믿을 뿐. 그리고 보이는 것은 이력서와 자소서, 그리고 사진과 포폴뿐이다. 둘째는 몇년 일찍 업계에 들어왔고 나이가 좀 더 높다거나 이런 이유로 사람을 평가하는 위치에 있게 되는데, 그 자리가 마치 종을 다루는 주인인 듯한 모습도 아름답지 않다. 그냥 노예 관리자 정도가 태반이지 않은가. 사람이 사람을 평가할 때는 항상 조심스러워야 하고 사람대 사람으로 먼저 존중해주는 모습이 필요함을 항상 염두해두고 이력서를 훑는다. 

그 옛날 이메일이 없었을 때, 노란색 서류 봉투에 대학때까지 인생의 모든 압축이 들어있는 서류들을 차곡차곡 넣어서 직접 우체국에 가서 보내면서 지원한 적이 있었다. 그러면 회사는 전국에서 몰려온 수백, 수천통의 지원자들의 서류들을 짧은 시간 내에 분류하고 심사하여 통보를 해줘야 한다. 대부분의 회사 인사팀은 조금 큰 기업이라도 많지가 않다. 더군다나 서류 심사에 참여할 수 있는 능력이 되는 사람은 더 적어진다. 그러므로 짧은 시간안에 수천통의 서류들에 대한 심사를 마치기 위해 그들은 큰 비어있는 사무실을 빌린다. 그리고는 서류를 아예 출신 대학을 그룹지어 봉투를 툭툭 던져서 모은다. 그리하여 낮은 등급의 그룹들은 열어보지도 않고 스킵하고 높은 그룹의 지원자들만 모아서, 확인하여 심사를 빠르게 마쳤었다고 한다. 

사실 말도 안되고 불합리하다고 생각했지만 공채 심사를 겪어 보면 충분히 이해 된다. 대게 기업들이 공채를 하여 채용하는 과정은 서류 접수를 마감한 후부터 한달 내외다. 즉, 한달 남짓한 기간 정도 안에 서류심사, 시험, 1차 2차 면접 등을 거의 끝낸다. 그 과정에서 보면 서류 심사 기간은 대게 1주 내외로 끝내줘야 한다. 인사팀에서 1000명의 서류에 대한 심사를 보려면 5일간 일을 한다고 가정을 하면 하루에 200명의 서류를 심사해야 한다. (나눠서 하지 않는다고 가정. 심사의 공정성을 위해서는 여러 사람이 모든 지원자를 체크해야한다.) 하루에 200명의 서류를 심사하려면, 하루 일하는 시간을 야근해서 10시간이라고 가정하고 오로지 하루 종일 서류 심사 업무만 한다고 해도 1시간당 20명을 봐야 한다. 1시간당 20명의 지원자들의 서류를 검토하려면 1명에게 할당할 수 있는 시간은 3분이다. 

즉, 공채 지원자들에게 할당된 서류 심사 위원에게 받은 자기의 시간은 3분이다. 이것보다 더 짧은 경우도 많다. 1분일수도 10초일수도 있다. 

비록 산술적인 계산이고, 가정의 오류가 다분할 수도 있으나 큰 기조는 마찬가지일 것이다. 공채 서류에 할당된 본인의 서류 검토 시간이 많다고 생각하면 큰 오산이다. 

그렇다면 시간이 적은 심사위원들과 회사 인사팀은 어떤 꼼수를 쓸 수 있는가? 될성 부른 사람은 더 많이 보고 안된다 싶은 사람은 걸러내서, 될성 부른 사람을 좀더 꼼꼼하게 검토하는 것이 낫지 않은가? 그렇다면 될성 부른 사람은 누구인가? 즉, 잘하는 사람은 누구일까? 적어도 잘할 것 같은 사람은 누구일까 라는 질문에 빠지게 된다. 

여기서 학벌과 학점이 나온다. 이것 외에 일반적으로 설득력있는 펙트가 없다. 가장 빨리 가능성 있는 자와 없는자를 구분하는 방법이고, 효과적이고 근거 있는 방법이다. 그래서 몇몇 회사는 아예 대학과 학점을 그룹으로 나눠서 서류 심사의 효율을 꽤한다. 이점은 학벌이 모든 것이라기 보다 보다 빠른 측량법, 잣대가 필요해서 더욱 그럴 것이다. 이것을 대체할 수 있는 마땅한 방법이 없다. 생각이 있는 사람이면 아무 산에서 금을 찾기 보다 금광에서 괭이질을 하며 금을 찾는 것이 더 낫다는 상식과 비슷한 맥락이다. 

그렇다면 여기서 어떤 사람이 공채에 유리한지 알 수 있다. 

첫째는 될 수 있는 한 좋은 학교를 나와야 한다. 소위 말하는 명문대학교를 나오는 것이 절대적으로 유리하다. 아무런 포폴도 없고 학점도 엉망인데 오직 사립명문이라는 이유로 인해 서류합격을 하는 경우가 있다. 둘째는 지원하는 곳과 가장 밀접한 관련 학과를 나와야 한다. 클라이언트 개발자라면 컴퓨터학과나 관련학과를 나와야 유리하다. 셋째는 학점이 높으면 무조건 유리하다. 같은 학교에 여러명이 지원했는데, 한명은 3.5 이고 다른 한명은 4.0이라면 고만고만한 포폴로써는 당연히 4.0인 애를 합격시킬 것이다. 자 이정도는 모두들 아는 기본이다.

이런 기본들을 엎을 수 있는 일말의 가능성으로 자소서와 포폴이 있다. 

자소서는 사실 정답은 없지만 다음을 추천한다. 

– 자소서는 짧고 간결하게, 본인이 이뤄낸 Fact 위주로 써라. 

문학적인 표현이 필요 없고, 관련 없는 장황한 이야기도 필요 없다. 포부를 밝히는 것도 거추장 스럽고, 제발 가족사나 인생사의 이야기들은 빼라. 자소서에 본인이 학부때 이뤄낸 성취 과업들을 잘 정리하고 그 이룬 것이 인정할 만하면 짧은 시간에 읽던 심사 위원들도 학교와 학점을 엎을 용기를 얻게 된다. 기억하자 자소서를 읽어보는 시간은 30초에서 길어야 1분이다. 

– 가능한한 지원 회사 이름을 자소서에 기록하지 마라. 

만약 회사 이름을 바꾸는 것을 깜박하고 지원했다면 100% 탈락이다. (현대 지원인데, 이러이러해서 삼성을 지원하게 되었습니다. -_-;) 지원 회사 이름을 잘못 기록하여 합격한 지원자를 본적이 없다.

– 비전공, 무관 아르바이트들은 오히려 기록하지 않는 것이 좋다.

회사는 그 일을 잘 해낼 수 있는 사람을 원하지, 아르바이트를 오래한 사람을 좋아하지 않는다. 아르바이트의 성실함이 도움이 되지 않을까 하는데, 도움이 안된다. 오히려 아르바이트를 하면서 빼앗긴 시간에 정작 자기 계발을 못한 점을 고려하여 마이너스를 준다.

– 해당 분야를 좋아한다라는 것을 어필하지 말고 해당 분야를 잘 한다는 점을 어필해야한다. 

클라이언트 개발자인데 어떤 게임을 플레이해보았고, 어떤 게임을 좋아했다라고 장황하게 기술된 케이스를 많이 본다. 심사 위원은 관심도 없다. 클라이언트 개발자라면 오히려 얼마나 개발 잘하는지가 훨씬 더 관심이 있다. 즉, 개발자 지원이면 개발을 좋아한 것을, 디자인 지원이면 디자인을 잘 한 것을 기록해야 한다. 좋아하는 것과 직접 해서 잘하는 것은 다르다는 건 상식이다. 

– 실패한 경험보다는 이뤄낸 Fact를 적어야 한다. 

실패해서 이러이러한 것을 배웠고, 다시 성공했다는 것은 괜찮으나 실패 그 자체로 마무리된 건 오히려 적지 않는 것이 좋다. 실패해서 이런 이런 것을 배웠습니다를 보는 것이 아니라 실패하여 능력이 부족하구나로 해석하여 마이너스를 주게 된다. 따라서, 이런 저런 대회 참가해봤습니다 라는 참여가 중요한 것이 아니라, 참가하여 수상하거나 입상하는 것이 중요하다. 이런 저런 동아리 참여 했습니다가 중요한 것이 아니라 그 결과 무슨 결과물을 만들어 냈는가가 중요하다.

– 자소서는 특별한 포멧이 없다면 PDF를 추천한다. 

Hwp 한글 문서를 사용하는 사람이 있다. 요즘 회사에서 한글을 거의 안쓴다. 공무원 공기업이 아니고서야. 일단 마이너스다. PDF나 차라리 Doc 오피스 파일 추천.

한편으로, 포폴이 정말 뛰어나면 엎을 수도 있다. 포폴은 다음의 지침이다. 

– 다다익선이다. 

학부때의 과제와 이뤄낸 성과들을 잘 모아두고 정리해 둬야 한다. 많을 수록 유리하고 퀄러티가 좋을 수록 유리하다. 

– 마찬가지로 포폴도 특별한 포멧이 없다면 PDF를 추천한다. 

– 가능한 심사위원의 시간을 줄여주는 방식으로 구성해야 한다. 

너무 페이지가 많지 않도록. (소스 코드를 수십페이지로 붙여서 내는 사람, 감점이다.). 게임 클라이언트라면 Link를 타고 원클릭으로 영상을 확인할 수 있도록 하며, 포폴 내에 스샷을, 혹은 다른 공모전 수상이라면 사진을 간단히 정리하여 첨부해야한다. 그들의 마우스를 가능한 사용하지 않도록 하고, 심사위원들의 시간을 금쪽같이 아껴주는 지원자가 되라. 

– 포폴 주제를 잘 선택해야 한다. 

졸작이라면, 혹은 학원 과제라면 선택을 잘해야한다. 게임 클라이언트 지원자들은 엉성한 RPG 포폴 일색이다. 차라리 모두에게 익숙한 고전 게임을 똑같이 구현하거나, 유명한 게임 리소스를 구해서 그대로 그 게임을 흉내내서 개발하는 것이 더 좋은 반응을 불러 일으킬 수 있다. 무관한 포폴 준비라면 유관 포폴보다 마이너스를 받게된다. 

– 소스코드를 덕지덕지 붙이지 마라. 

Senior가 Junior의 소스코드에 무엇을 기대한다는 말인가? 소스코드를 읽고 파악할 시간이 사실 없다. 클라이언트 개발자가 자기 소소 코드로 포폴의 절반 이상을 붙여넣는 경우가 있는데 감점이다. 정말 그것을 한줄한줄 읽어주지 않을 뿐더러 포폴의 이해와 구성의 저해하는 주요한 감점 대상이다. 

– 포폴로 소스코드와 프로젝트 실행파일을 첨부하지 마라.

소스코드를 IDE로 거의 실행해 보지 않는다. 심사 위원들에겐 그럴만한 시간이 없다. 실행 파일도 감점이다. 해당 PC에서 실행이 되지 않을 수도 있고, 맥인데 EXE를 첨부하면 어떻게 하란 말인가. 만약에 지원자의 악의로 바이러스라도 있으면 이라는 생각이 들면 더더욱 실행하지 않는다. 

포폴의 안좋은 케이스로 이런 경우가 있다. 

포폴이 zip 파일이다. 이 zip을 여니 txt파일로 링크가 나온다. 링크를 복사하여 웹사이트로 가니(심사위원이 이쯤되면 조금 짜증), 또다시 zip을 받는 링크가 나온다. (파일 용량 문제였으리라. 하지만, 심사위원이 여기서 브라우져를 꺼버릴 수 있다.). 어찌어찌하여  문서를 열어보니 그 안에 HWP 파일, 즉 한글 문서 파일이 나온다. 심사 위원들의 PC엔 한글이 깔려있지 않다. ㄷㄷㄷ. 뷰어를 깔고…확인을 하며… 해당 지원자에게 좋은 점수를 줄 수 있을까? 

이러한 분들은 참 아쉽다. 학점도 좋고 학교도 괜찮은데, 수많은 아르바이트로 인해 포트폴리오가 없으신 분들이 있다. 생활의 어려움을 이겨내고 높은 학점을 받아내는 성실함을 가지신 분이지만 포트폴리오를 준비할 시간이 차마 없으신 듯 포폴이 없는 경우가 있다. 이 경우 학점이 높고 포폴을 잘 준비한 다른 지원자에게 더 후한 점수가 간다. 또한, 이리저리 지저분한 경력을 가지고 계시다가 뒤늦게 이쪽으로 이직하고자 하여 열심히 하려는 분들도 있다. 이런 분들의 수고와 열정 노력은 인정하지만, 1학년때부터 전공자로 착실하게 준비하고 학점과 포폴을 잘 관리해온 사람을 두고 누구에게 더 점수가 갈지는 짐작할 만하다. 또한, 전공이 아닌데, 이쪽을 하고 싶어서 준비하신 분들도 서둘러 준비하거나 짧게 학원을 다니시는 분이 많아서 대게는 안타까운 마음이 든다. 

공채는 경쟁이 매우 치열하다. 회사는 1년마다 각 대학(간혹 고등학교)에서 몰려오는 좋은 지원자들을 받을 절호의 기회이다. 지원자들은 학부 때 했던 자기의 모든 노력들이 결실을 맺는 기간이기도 하다. 그러므로, 지원자들은 더 잘 준비해야 한다. 대게는 1학년때부터 착실하게 학점을 준비하고, 프로젝트들을 성공해 내고, 공모전에서 우승하고, 학원에서 실력을 업그레이드 한 사람들이 통과하는 것이 공채이다. 그러므로 공채를 무난하게 통과하기 위해서는, 가능한 미리 목표 회사를 정하고 지원자 스스로를 잘 파악하고 무엇을 해야하고, 무엇을 하지말아야 할지 오래전부터 고민하고 생각하며 준비해야 한다.