서론
최근에는 여러 곳에서 열리는 채용 관련 행사에 참여를 하고 있다. 학교에서 주최하는 취업 행사는 물론이고, 회사에서 진행하는 인턴십이나 추후에 열릴 공개 채용도 꼼꼼히 파악하고 있다. 특히 지난주에는 내가 알고 있던 회사에서 인턴십을 주최하길래 채용 경험을 위해 이력서와 포트폴리오를 작성해 지원도 했었다.
솔직히 말하자면, 적어도 서류는 통과할 줄 알았다. 지금까지 세 통의 메일에서 ‘아쉽지만’을 조우하고, 여러 생각을 거친 끝의 결론은 ‘아직 부족하다’였다. 취업을 준비하기 전에 내가 세운 목표는 ‘기본에 충실히’였다 (지금 와서 생각해 보면 기본도 안됐던 것 같다). 그래서 다양한 기술을 공부하기보다는 내가 했던 것을 그대로 보여주고, 백엔드 신입으로써 기본적으로 갖춰야 할 기술들에 포커스를 두고자 했다. 하지만 세 번의 불합격을 통해 생각이 조금 달라졌다. 그래서 이번 글에서는 내가 며칠간 고민한 생각과 느낀 것들을 작성해 보고자 한다.
이력서 콘텐츠 부족
내 이력서 내용 중 프로젝트 부분
내가 합격하지 못한 이유는 당연히 내가 다른 지원자들의 이력서와 포트폴리오보다 부족한 점이 있어서 일 것이다. 그렇다면 어떤 부분이 부족했을까? 내가 이력서를 작성할 때 가장 고민했던 부분은 ‘뭘 작성하지?’였다. 작성할 프로젝트는 있었지만, 그 프로젝트에서 마땅히 내세울 것이 없었다. 대부분 진행했던 프로젝트가 대회 출전 혹은 학교 프로젝트를 위한 것이라 많은 기능을 제공하는 것이 아닌 핵심적인 기능만 제공하고 있었기 때문이다. 그래서 이력서를 작성할 때 이러한 부분을 최대한 부풀려 작성할 수밖에 없었고, 그것이 원인이라 생각했다.
위 사진의 이력서 내용은 사실 ‘병목현상이 발생하여 메시지 큐가 필요했고, 이를 위해 메시지 큐잉 시스템을 직접 구현했다.’로 정리할 수 있는 내용이지만 굳이 이 문장을 부풀려 두 개의 챕터에 걸쳐서 작성했다. 수 백 명의 지원자가 제출한 이력서를 봐야 하는 채용 담당자 입장에서 이러한 요소는 분명히 마이너스 요소가 되었을 것이다. 하지만 그렇다고 내세울 만한 점이 없는 프로젝트에서 꾸밈없이 단순하게 적는 것도 좋은 방법은 아니라고 생각한다. 그래서 내린 결론은 해당 프로젝트를 더 디벨롭하는 것이다.
지금 봐도 내가 이력서에 넣은 프로젝트는 너무 단순한 기능들이고, 프로젝트에 사용된 개발 스택과 작성한 개발 내용이 서로 상이했다. 그래서 이 프로젝트에 대해 기능을 더 보완하고, 기능을 개발하는 중 발생했던 이슈들에 대해 어떻게 해결했고, 그 결과가 어땠는지를 작성할 것이다. 그리고 이력서에서 채용 담당자의 관심을 얻을 수 있는 방법 중 하나는 수치를 넣는 것이라고 한다. 그래서 성능을 얼마나 개선했는지 혹은 활성 사용자 수를 얼마나 증가시켰는지 등 수치화할 수 있는 것들을 추가하는 것이 좋을 것이다.
기술 스택 부족
내 이력서 내용 중 스택 부분
내가 기본에 충실하자는 목표를 가진 이유는 실제로 규모가 있는 기업의 경우 신입을 뽑을 데 다양한 기술 스택도 중요하지만 기본기가 탄탄한 지원자를 더 매력적이게 본다는 말을 들었고, 나 또한 그렇게 생각했기 때문이다. 기반이 부실하면 그 위에 뭘 쌓든 결국에는 무너지기 때문에 기반을 제대로 갖추어야 한다고 생각했다. 그래서 다양한 기술을 경험하기보다는 내가 배웠던 것에 집중해서 프로젝트를 진행했던 것 같다.
그러다 보니 특히 백엔드 프로젝트에 대부분 요구되는 Redis나 최근 대부분의 기업들이 사용 중인 클라우드 기술들, 심지어 내가 기술 스택에 넣은 MariaDB 조차도 이력서 내용 중에 담당자의 입장에서 눈에 띌만한 요소가 없었던 것 같다. 내가 이력서에 작성한 내용 대부분은 어떤 기술 스택을 이용해서 이런 걸 만들었다는 것보다는 어떤 걸 만들기 위해 이와 관련된 기술 스택을 이용하는 것이 아닌 내가 직접 자료구조를 이용해 제작했다가 주를 이루었다. 어떻게 보면 이런 점들은 신입을 뽑아서 공부시키길 원하는 대기업과 얼추 맞는 듯 보이나 사실 누구나 만들 수 있는 것들이기 때문에 그렇게 강력한 차별점은 아니라고 생각한다.
그렇다면 대기업이 아닌 기업에서는 어떨까? 이런 기업에서는 빠르게 서비스를 제작해야 하기 때문에 신입을 뽑아 공부시키는 것이 아닌 지금 바로 투입이 되어도 괜찮은 신입을 뽑을 것이다. 그래서 결국 내 이력서는 대기업도 중소기업도 원치 않는 이력서가 된 것이다. 사실 신입이 갖춰야 할 스택에 대한 기준이라는 게 정말 정하기 어려운 것 같다. 내가 생각한 신입 백엔드의 기본은 CS 지식, Spring Boot 지식과 간단한 DB 지식 정도라고 생각했었는데 지금 와서 생각해 보면 그 기준을 내가 너무 낮게 잡았던 것 같다. 최근 대부분의 기업들의 신입 채용 우대 조건으로 Redis, MongoDB, AWS 등의 기술 스택을 명시하기 때문에, 이후에 내가 지원하고 싶은 회사들의 포지션들을 분석한 뒤에 구체적으로 어떤 스택을 잡아야 할지 선택할 것이다.
나만의 차별점 부족
내 이력서 내용 중 자기소개 부분
이력서의 첫 시작은 나의 인적사항들과 함께 보이는 자기소개이다. 이 자기소개를 통해 채용 담당자에게 간단하게 내가 어떻게 개발을 해왔고, 앞으로 어떻게 성장할 것인지를 구체적이지만 간결하게 설명해야 한다. 이를 위해서는 그냥 무작정 소개를 작성하는 것보다 사업 아이템을 구상하듯 나를 소개할 수 있는 간단한 문장에 대한 아이디어를 찾는 것이 중요하다. 언제 한번 이력서 관련 특강에서 들었던 내용이 작성한 글이 남들도 쉽게 작성할 수 있고 생각할 수 있는 부분이라면 그 부분을 과감하게 삭제해야 한다는 것이다.
그런 관점에서 봤을 때 누구나 적을 수 있는 문장들로 구성된 나의 이력서는 빈틈투성이였다. 이력서는 짧은 시간 내에 나에 대한 소개를 임팩트 있게 전달하고, 내가 성장 가능성이 있음을 설득해야 하는 서류이다. 그렇기 때문에 이력서 내의 문장들은 필터링을 거쳐서 독자가 읽기 수월하게끔 작성해야 하며, 어떤 개념을 설명할 때에도 임팩트 있게 전달할 수 있는 방법을 꾸준히 고민해야 할 것이다.
결론
사실 이렇게 고민하고 생각한 것들이 어쩌면 완전히 잘못 짚은 것일 수도 있다. 하지만 만약 그렇다고 해도 내가 세 번의 불합격 메일을 받고, 나의 문제점을 파악하고, 앞으로는 어떻게 해야 할지 방향을 수정하는 과정이 되게 뜻깊었던 것 같다. 취업이라는 큰 산을 오르기 위해서는 수많은 고개를 넘어야 하는 노력이 수반되기 마련이다. 최종 목표만 보고 발걸음을 내디디면 넘어야 하는 고개가 많다는 현실 앞에 주저앉을 수 있다. 하지만 최종 목표에 포커싱하는 것이 아닌 현재 내 앞에 놓인 고개에 포커싱하여 걸음을 옮기면 훨씬 수월할 것이다.
앞으로 나의 계획은 프로젝트를 디벨롭하며 이력서 내용도 전반적으로 수정할 것이다. 그리고 나를 가장 잘 표현할 수 있는 문장에 대한 아이디어를 반영하여 자기소개 부분도 다시 수정할 계획이다. 무엇보다 내가 희망하는 회사들에 대한 기술 스택을 분석하여 내가 갖춰야 할 기술 스택에 대해 정의해 볼 생각이다.
앞으로 할 일이 많겠지만 하나씩 헤쳐나가 보자!
Comments powered by Disqus.