나는 왜 항상 불합격일까? 취준 회고 - 이력서편

나는 왜 항상 불합격일까? 취준 회고 - 면접편 에 이어 이력서 작성 과정을 정리해보았다. 기나긴 취준 기간동안 이력서와 면접준비가 가장 큰 비중을 차지했던 만큼 회고 겸 기록으로 남겨두고 싶었다. 더불어 이력서를 처음 작성할 때의 막막함, 그리고 반복되는 서류광탈이라는 힘든 시간을 함께 겪는 동지들에게 이 포스팅이 도움이 되었으면 한다.

일단 쓰자

구글이라는 주인을 섬기는 꼭두각시 개발자인 만큼 '이력서를 써야지!' 하고 마음먹으면 당연하게도 구글에 "프론트엔드 개발자 이력서" 을 검색하게 된다. '성과를 중심으로', '팩트와 수치로 보여주기' 등 여러 포스팅을 본 이후에는 어느정도 자신감이 생긴다. 그렇게 다시 나의 텅 빈 이력서 창으로 돌아오면 텅 빈 머리속에는 하나의 생각으로 가득 찬다.

하기 싫다

서론이 길었는데, 이력서를 작성할 때 가장 중요한 일은 일단 쓰기 인 것 같다. 막막함과 자괴감을 견디고 뭐라도 쓰다보면 관성이 붙어서 어느정도 작성하게 되는 것 같다. 뭐라도 쓰기 위해 이력서 재료를 모으다보면 다들 비슷한 생각을 할거라 싶은데, 함께 정리해고를 당했던 동료들과 이력서 관련한 이야기를 나눌때에도 '아무것도 해놓은 게 없는 것 같아요', '이력서에 쓸 말이 없어요' 와 같이 자조섞인 한탄을 하게됐다. 나 역시 내세울 것 없는 보잘 것 없는 경력을 가졌지만, 어쩌겠나. 일단 내가 했던 개발과 경험을 모두 적어놓고 그 중에서 그나마 매력있는 것들을 골라 가장 돋보일 수 있게 작성했다. 그 와중에 블로그를 작성하고 기록하던 습관이 꽤나 도움이 되었다.

100장의 이력서 중 눈에 띌 수 있는 이력서 만들기

이력서 폼에 대해서도 할말이 많다. 일단 이력서를 쓰다보면 어떤 항목을 쓰고, 어떤 폼에 작성해야 할 지 고민하게된다. 그 중 많은 개발자들이 노션으로 이력서를 작성하고 노션을 추천하는 포스팅도 많다. 요새는 노션 말고도 서핏과 같이 간결한 이력서 디자인 뿐만 아니라 배포 링크까지 제공해주는 사이트도 많다.

노션 이력서를 욕하고 싶진 않다. 내용이 중요하다는 말에도 백분 공감한다. 실제로 잘 쓴 이력서의 예시에는 노션이 심심치않게 등장하고, 많은 개발자분들이 노션으로 이력서를 작성하고 관리하고 있다. 하지만 나의 이력은 소위 '잘 쓴 이력서' 에 비하면 작고 하찮고 비루하고 내게만 소중하다. 그렇기에 어떻게든 줄을 긋고 색을 칠해서 호박같은 내 이력서를 수박으로 만들어야 한다.

면접을 안부르는데 어떻게 가요

지금은 다 무너져가는 회사여도 '개발자 채용'만 써붙이면 100장 이상의 이력서가 날아드는 시국이다. 우리는 이 수많은 이력서 중에서 눈에 띄어야한다. 내가 리누스 토발즈보다 개발을 잘할지라도 일단 면접에는 붙어야 하지 않겠는가. 그렇기에 남들과 똑같은 노션이나 채용사이트 포맷을 사용하기 보다는 자신만의 이력서를 만드는 것을 추천한다.

또, 각자의 이력에는 자신있는 부분이 있을 것이다. 누구는 다양한 프로젝트를, 누구는 대규모 서비스를, 또 누구는 별의 별 문제를 해결했던 이력이 있다. 그렇기에 각자가 자신있는 부분을 강조하고 자신없는 부분은 숨길 수 있는 자유로운 형식의 이력서를 사용했으면 싶다.

물론 내가 손만 대면 보노보노 PPT를 만들어버리는 똥손이라면 기존 템플릿을 사용하는 것도 좋다. Figma Community에서 이력서를 검색해보면 수많은 무료 템플릿이 나오는데, 나는 이 중에서 괜찮아 보이는 템플릿들을 모아 조립하고 수정하면서 이력서 폼을 만들었다.

내 여자에게도 차가운 도시의 이력서

이력서를 쓰는 과정에서 가장 힘들었던 부분이다. T없이 맑은 감성넘치는 F 개발자로서, 이력서를 쓰다보면 묘하게 '이사람, 개발 못할 것 같은데?' 싶은 냄새를 풍기게 된다. 그 이유를 수많은 탈락 후에야 알 수 있었는데, 내가 쓴 글에는 쓸데없는 말들과 추상적인 글들이 너무 많았다.

과거 내 이력서의 초반부는 다음과 같이 시작했다.

직장도 없는 것이 스스로를 같이 일하고 싶은 개발자 라고 칭한다. 그리고 경력사항에서 알게 될 당연한 정보들로 가장 중요한 이력서의 첫인상을 낭비하고 있다.

이력서를 작성하면서 가장 도움이 되었던 말이 있었는데, 바로 이력서는 전문적인, 문서중에서 가장 dry한 문서 라는 말이었다. 쓸데없이 담백한 서론은 집어치우고, 내가 어떤 사람인지 각인시켜야 한다. 시간이 많이 소요되는 웹앱 인터페이스 과정을 react-query의 캐싱을 사용하여 최소화하였습니다. 처럼 쓸데없는 친절로 면접관의 시간을 뺏어서도 안된다. 캐싱을 통한 웹앱 인터페이스 최소화와 같이 간결하게 정보를 표기해야 한다.

여러 사람에게 피드백 받기

이력서를 쓰다보면 내가 잘 쓰고 있는건지, 이게 맞는건지 싶은 순간이 온다. 그럴땐 주변 사람들에게 이력서 피드백을 받아보는 것을 강력히 추천한다. 이력서가 미완성이어도 좋다. 아직 남들에게 보여주기 부끄럽다면 더더욱 좋다. 이력서가 부끄러운 만큼 수많은 피드백이 돌아올 것이고, 날카로운 피드백은 곧 양질의 이력서를 위한 양분이 되어줄 것이다.

어느정도 완성되었다면 실력있는 개발자 분들에게도 피드백 받아보기를 권한다. 주변의 개발자 분들에게 요청해도 좋고, 개발자 모임에 나가서 받아도 좋다. 최근에는 유료로 이력서를 피드백해주는 실력있는 개발자 분들이 많이 있는데, 비교적 저렴한 가격의 컨설팅도 꽤나 도움이 되는 피드백을 주시니 한번 쯤 받아보는 것도 좋다.

나 역시 주변 개발자를 붙잡고 피드백만 수십번 부탁드렸던 것 같다. 지인은 물론, 개발 스터디나 면접 스터디에서도 수없이 피드백을 부탁드렸고, 유료 피드백도 3만원, 8만원을 지불하고 2번정도 받아봤다. 피드백을 받을 때 유의할 점은 좋은 이력서의 기준은 개개인마다 다르고, 면접관마다도 다르기 때문에 모든 피드백을 받아들이기보다는 자신만의 기준으로 납득가는 피드백만 받아들여야 한다는 것이다. 실제로 잘 썼다고 칭찬받았던 부분을 이 부분은 필요없을 것 같다는 피드백을 받는 경우가 꽤나 있었다. 그렇기에 피드백을 부탁해놓고 피드백이 맘에 들지 않는다고 무시해버리는 파렴치한 태도도 어느정도는 필요하다.

내가 어떤 개발자인지 정의해보자

나는 이력서에서 가장 먼저 '불편함을 해결하는 이펙티브 개발자' 라고 나를 소개하였는데, 이것이 면접관에게 나를 각인시키고 이력서의 방향을 정하는데 가장 큰 도움이 되었다고 생각한다. 사실 이력서를 쓰기 전에 생각해 둔것은 아니고,이력서를 작성하다보니 떠오른 것이다. 이력서를 작성하면서 내가 해왔던 개발들을 보다보니 한가지 흐름이 눈에 띄었다. 업무 내외적으로 어떻게든 편하게 하려고 반복작업을 없애거나 비효율적인 문제를 해결하는 개발들을 해왔는데, 돌이켜보니 이러한 개발이 나를 표현할 수 있는 강점이라고 느껴졌다.

함께 개발을 하다보면 어떤 개발자분은 이런 강점이 있고, 어떤 개발자분은 저런 강점이 있는지 보이게 된다. 마찬가지로 누구나 돋보이는 능력이 있을 것이고 이를 살려서 이력서 방향을 잡는다면 조금 더 수월하게 이력서를 쓸 수 있지 않을까 싶다. 만약 나는 아무런 장점이 없어! 라는 생각이 든다면 주변사람에게 물어보자. 아주 작은 장점이라도 나만의 강점이 되기에는 충분할 것이다.