DevOwen의 구직 이야기 Ch2. 이력서 작성

오늘은 이력서를 작성하는 법에 대한 이야기를 해 보려고 한다.

나는 짧막짧막한 이력들만 있었고, 사실상 신입이었다. 그래서 이 글은 경력직 분들이 보시기에는 다소 적합하지 않는 부분도 있다. 감안해서 봐 주시기를 바란다.

그리고 나는 대기업 공채는 쓰지 않았다. 이유는 대기업을 가면 연봉이나 복지, 사회적 평판은 좋을지 몰라도, 커리어를 길게 보았을 때 내 전문성을 주도적으로 가지기 어렵고 또 회사에 내가 끼칠 수 있는 임팩트가 클 수 없다고 생각했기 때문이다. 

참고로 신입은 경력직보다 구직이 (매우) 더 어렵다. 채용 공고도 더 적고, 이력도 없거나 적기 때문이다. 실무 스킬도 당연히 불리하기 때문에 여러모로 어려운 점이 참 많다.

그럼에도 불구하고 신입이 경력직에 비해서 가질 수 있는 무기가 하나 있는데... 그건 바로 '성장 가능성'이다. 실제로 많은 회사는 지원자가 지금 당장 React를 능숙하게 잘 쓰지 못하더라도, 기본기가 튼튼하고 회사에서 빠르게 새로운 기술들을 배울 수 있을 것 같으면 채용을 한다. 그래서 회사에 처음 보여지는 이력서에서부터 이러한 성장 가능성을 잘 어필해야 한다.

참고를 위해 나의 이력서를 아래에 공유한다.

이력서_오원종.pdf

0.12MB

 

이력서는 마치 영화 트레일러(예고편) 같다. 많은 관객들은 트레일러를 보고 그 영화가 재밌을 것 같은지, 노잼일지를 판단하는 경우가 많다. 영화가 재밌을 것 같더라도 영화에서 중요한 장면들이 이미 다 나와버리면, 관객들은 돈을 주고 영화를 보지 않는다. 그래서 영화 제작사는 트레일러를 만들 때 너무 길거나 지루하지 않으면서, 관객들이 호기심을 느낄 만한 떡밥들을 충분히 던져 둔다.

나는 채용 프로세스도 비슷하다고 생각한다. 채용 담당자들이 우리의 이력서를 얼마나 정성스럽게 읽는지는 모르겠지만 <당신은 더 좋은 회사를 다닐 자격이 있다>라는 책을 쓴 저자 김나이님은 인사 담당자들이 지원자의 이력서를 스크리닝 하는데 길게 봐야 "45초" 정도 쓴다고 한다.

우리가 해야 할 일은 단순하다. 인사 담당자가 길면 45초 정도 쓰는 그 시간에, "OO이가 이 회사의 OO 포지션에 적합한 사람이다." 라든지(이건 Best), 아니면 적어도 "OO이가 이 회사의 OO 포지션에 적합할지 말지는 잘 모르겠지만, 한 번 만나보고 싶다!" 는 느낌을 받을 수 있게 만들어야 한다. 우리는 이 목표를 가지고 이력서를 작성해야 한다. 이력서는 내 자랑하는 글이 아니라, 인사 담당자 또는 의사 결정권자를 설득하는 글이다.

이력서에 어떤어떤 항목들을 넣으려고 하기 전에 한 번 곰곰히 생각해 보자. "과연 그들은 나의 어떤 모습을 보고 싶어할까?", "그들을 어떻게 하면 설득할 수 있을까?" 생각의 중심을 나 자신이 아닌, 상대방의 관점으로 돌려 놓으면 생각보다 많은 것들을 쉽게 써 내려갈 수 있을 것이다. 그리고 너무 많은 내용을 넣으려고 욕심낼 필요는 없다. 신입 수준의 지원자면 이력서 1페이지로 충분하다고 생각하고, 오히려 더 많은 내용을 넣으려고 하다간, 이력서를 읽는 사람이 중요한 정보까지 대충 읽고 지나가게 될 수도 있다.

그리고 이력서를 쓰기 전에 다른 '좋은' 이력서를 많이 보았으면 좋겠다. 조금만 구글에서 검색을 해 보면 정말 좋은 이력서를 많이 발견할 수 있다. 나 같은 경우 국문/영문 이력서를 둘 다 작성해 놓아서 해외 이력서도 많이 참고했다. 최근에 봤던 이력서 중에서 인상적이었던 이력서를 세 개만 소개한다. 이처럼 꼭 pdf가 아니라 블로그나 노션 등으로 작성해서 링크를 공유하는 것도 좋은 방법이다.

이현섭님의 이력서

https://hyunseob.github.io/resume/

이력서 - 이현섭

김준영님의 이력서

https://www.notion.so/June-Kim-8e317ecc41104d2f951da3f421231a3e

June Kim 김준영

정원희님의 이력서

https://www.notion.so/Wonny-e64e2e55653c4d8b8b632118b36bdd72

Wonny | 데이터로 일하는 개발자

이력서는 여러분의 첫 인상이다. 소개팅 처음 나갈 때 어떻게 하는지 생각해 보면 쉽다. 정말 사소한 부분까지 신경쓰고 좋은 인상을 주기 위해 내 매력을 한껏 어필한다. 물론 이력서를 잘 쓴다고 바로 채용되고 그런건 절대 아니지만, 좋은 이력서를 통한 좋은 첫 인상은 이후에 많은 채용 프로세스에서 큰 도움이 될 것이라고 확신한다.

 

지금까지 이력서를 어떠한 생각으로 써야 하는지에 대해 설명을 했고, 지금부터는 이력서에 어떠한 내용을 담아야 하는지를 알아보려고 한다. 사실 여기에는 정답은 없으며, 내가 작성했던 기준들을 가지고 설명을 해보려고 한다.

나는 크게 다음과 같은 요소들을 가지고 이력서를 작성하였다.

1. 이름 및 자기소개
2. 학력
3. 이력
4. 프로젝트 및 수상 실적
5. 사용할 수 있는 기술 스택
6. 연락처 및 깃허브, 블로그, 링크드인 url

영문 이력서의 경우는 여기에 추가적으로 대외 활동 등의 정보들도 넣어주기는 하였다. 외국계 회사의 경우 전공과 관련 없는 외부 활동들을 중요하게 보는 경우도 있기 때문이었으나, 국내에서 회사에 지원할 때는 딱히 필요하지 않다고 느껴서 적지 않았다. 이 외에도 저술 활동이나 강연 등을 한 경험이 있다면 적어주는 것도 좋다.

먼저 자기소개 부분은 나는 세 줄 정도로 나를 표현했다. 한 페이지의 이력서에 너무 많은 문장이 처음에 들어가는 것도 좋아 보이진 않았고, 나의 현재, 과거, 미래를 한 문장씩 가지고 표현해 보려고 노력했다.(잘 했는지는 모르겠다) 만약에 분량에 크게 제한이 없는 양식의 이력서의 경우 자기 소개 부분을 좀 더 깊이있게 쓰는 것도 좋아 보인다.

학력의 경우는 나는 학사만 적었다. 그리고 학점은 넣지 않았다. 10번 이상의 면접을 보면서 학점을 물어보는 곳은 딱 한 곳 있었다. 학점이 높을 수록 좋다는 건 누구나 알고 있는 사실이지만, 일단 내 학점은 어디 내놓을 정도로 좋은 편이 아니었고, 이력서에 필수적인 요소라고 생각하진 않아서 과감히 뺐다. 오히려 학점 말고 내가 컴퓨터 학과 전공을 어떤 수업들을 들었는지 궁금해 하시는 분들을 많이 있었다.

이력의 경우 나는 사실 경력직이 아니어서 작년에 했었던 소프트웨어 마에스트로 활동과 스타트업 인턴 및 토스 계약직 근무 이력 정도만 짧게 적었다. 질문을 가장 많이 받은 부분이기도 하다. 나의 경우 내가 이 때 했던 프로젝트나 업무를 두 줄 정도의 문장으로 압축해서 전달했는데 여기서 질문을 많이 받았던 것 같다. 그래서 좀 더 bullet point를 사용한 리스트 형태로 짧게 서너줄을 적는 것도 좋았겠다는 생각이 들었다. 또한 여기서 내가 간과한 부분이 정량적인 지표나 데이터로 내 성과를 표현하는 걸 잘 못했다. 그냥 '무슨 기능 개발했다' 이렇게 막연하게 적으면 면접관은 그 이력서를 통해 나에 대해 굉장히 제한적으로 알 수 밖에 없다. 부풀릴 필요도 없고, 축소할 필요도 없고 딱 내가 한 일들에 대해서 구체적으로 일목요연하게 정리하는 게 중요해 보인다.

프로젝트나 수상 실적은 본인이 혼자 또는 팀으로 진행했던 사이드 프로젝트, 토이 프로젝트를 적거나 해커톤, 공모전 등에서 상을 받은 내용을 적으면 된다. 둘 다 최소한 하나씩은 적어 주는 것이 좋다고 생각한다. 웹 프로젝트의 경우 배포까지 한 프로젝트이면 더 좋다. 실제로 해당 프로젝트를 보고 싶다고 하신 분들도 많았다. 프로젝트나 수상 실적 부분은 본인이 학업 또는 경력 이외에 얼마나 다양한 관심을 가지고 새로운 분야를 탐구했는지를 보려고 하는 것 같다. 회사에 들어가게 되면 본인이 익숙한 분야 이외에도 공부해야 하는 지식들이 많아지기 때문에 회사는 이렇게 다양한 분야에 호기심을 가지고 작게라도 시도해 본 지원자들을 선호하는 것 같다.

사용할 수 있는 기술 스택 역시 신중하게 적는게 좋다. 잘 모르는 기술을 많이 나열하는 건 지양해야 한다. 면접때 얼마든지 물어볼 수 있고, 그에 대해 충분하게 대답하지 못한다면 오히려 안 적느니만 못한 역효과를 낼 수도 있다. 어느 정도 질문이 들어와도 충분하게 대답이 가능한 내용들만 기술 스택에 포함하는 것을 권장한다.

마지막으로 깃허브나 (가지고 있다면) 블로그, 링크드인 링크도 이력서에 넣어주면 좋다. 앞서 말한 것 처럼 이력서는 트레일러의 역할 정도이기 때문에 당신에게 더 관심이 있는 인사 담당자들은 링크를 타고 들어가서 볼 확률이 높다. 물론 이러한 깃허브나 블로그, 링크드인 등도 미리 관리를 좀 해놓는 편이 좋다. 예를 들면 깃허브에서 대표적인 프로젝트들에 Readme.md를 작성해 놓는 식으로 말이다.

 

신입 개발자가 이력서를 어떻게 작성하면 좋은지에 대해서 나의 생각을 정리해 보았다. 다음 포스팅에서는 서류 통과 이후에 진행되는 코딩테스트, 사전 과제, 서면 질문지 등의 전형에 대해 이야기를 해 볼 예정이다.