하, Frontend 개발자형들!

몇명만 더 보면 50명이 넘으려나? 연말부터 회사로 들어오는 개발자 이력서를 하나하나씩 검토하고 있는데 이게 일이 쉽지는 않다. 개발자분의 능력을 달랑 1~2장짜리 이력서 페이지만 가지고 확인 할 수 없다. 시간을 내서 이력서에 적힌 Github 계정에 가서 코드도 보고, 포트폴리오에 적어주신 프로젝트들도 실행해보고, 개인블로그에 적힌 글들도 읽어보고 그러려면 1명당 못해도 15분, 길면 30분이 넘게 걸리는 일이 된다.

30분이 길다고 투덜대었지만, 사실 이력서를 내신 분들은 이것보다 몇배는 더 많은 시간을 썼을거라 생각한다. 그렇게 정성것 만든 이력서를 보다가 공통으로 꼭 말해주고 싶은 답답한 구석이 있어서 이 글을 쓰게 되었다. 특히 Frontend 개발하는 분들에게, 딱 3가지만 말해주고 싶다.

(짤이 좀 험악하지만)

1. 길고 짧은 것은 대어 보아야 안다

지원자 입장에서 Frontend의 가장 큰 장점은 자신의 결과물을 직접 보여 줄 수 있다는 것이다. 아무리 좋은 이력서도, 아무리 잘 꾸며진 Github 계정도, 이력서를 보는 사람이 직접 접속해 볼 수 있는 웹사이트 링크 1개, 앱을 직접 받을 수 있는 앱스토어 링크 1개 보다 못하다. Backend는 이걸 보여주기 힘들기 때문에 이력서나 포트폴리오에 주저리주저리 본인이 했던 프로젝트에 대한 내용과 풀어낸 기술적 난제를 말하지만, Frontend는 바로 써보고 해주면 끝이다. 맛집도 한번 가서 음식을 먹어보면 진짜 맛집인지 아닌지 바로 알 수 있는 것처럼.

제발 vercel, netlify, heroku, github,io 등 무료로 Frontend 프로젝트를 배포 할 곳이 많으니, 이력서에 적어놓은 프로젝트라면 꼭 배포를 하고 이력서에 링크를 달아놓자. App 개발자라면, 개발된 앱을 스토어에 올리고 바로 다운받아서 쓸 수 있게 링크를 달아놓자. 이거를 안해서 서류 평가에서 다음 단계로 넘기지 못하는 Frontend 개발자분들이 너무 많았다. 이력서를 검토하는 입장에서도 뭔가 볼게 있어야, 평가를 하지 않는가? 볼게 있어야 길고 짧은 지 알 수 있다.

2. Github 계정 말고 프로젝트의 README.md를 꾸며라

알록달록한 Github 계정을 꾸미는게 유행인 걸 알지만, 정작 평가단계에서는 별 다른 도움이 안된다. 나는 아직도, 그리고 10년 뒤에도 JavaScript A+ 이라는 평가를 못 적을 것 같은데. 개발을 시작한지 1년 남짓한 분들이 A+이라고 적어 놓는 모습을 보면 그냥 유행이라고 생각하고 넘어간다.

실제 이력서에 달린 프로젝트를 검토 할 때 보는 것은 그 프로젝트이 Repo이다. Github Repo에 가보면 알겠지만, 해당 페이지에서 제일 처음 보여주는 것은 README.md 파일의 내용이다. README.md 파일이 잘 되어 있고, 해당 프로젝트를 clone 한 다음에 어떻게 실행하는지에 대한 설명이 잘 되어 있고, 실제로 clone 받고 그대로 동작하는 프로젝트는 좋은 평가를 할 수 밖에 없다.

실제로 지원자 분들의 Github Repo에 가보면, 프로젝트 생성 할 때 기본적으로 되어 있는 README.md가 그대로 인 경우도 있고, README.md에 있는대로 설치하고 실행해도 안되는 경우가 많다. 후자는 보통 npm install -g pakcage_name 로 설치해 놓고, 다른 컴퓨터에서도 되겠지 하는 경우가 많은 듯한데, 이러면 또 실행이 안되니 평가가 어렵다. 물론 1번 단계를 잘 했다면, 이 부분은 크게 문제가 되지는 않을 것이다. 실행된 버전을 확인 할 수 있으니, Repo에 가서는 코드 단위로 보게 되어서.

3. 가능하다면, Frontend는 나 혼자 했던 프로젝트가 좋다

실제 회사에서는 팀 단위로 프로젝트를 하기 때문에 팀 프로젝트는 좋다. 그러나 이력서를 보는 입장에서는 이게 단점이 되기도 한다. 지원자가 이력서에 적은 프로젝트 하나가 5명이 진행한 프로젝트이고 Backend 2명, Frontend 3명이 같이 했다면, 이 프로젝트를 평가하기 위해서 Github에 있는 프로젝트를 commit 단위로 확인해 봐야한다. 3명 중 지원자가 한 부분이 어디인지 확인하려면, 그 방법 밖에 없다.

그래서 가능하다면, Frontend 부분을 나 혼자 하는 팀프로젝트를 하게 된다면 자신이 한 부분을 어필하기 좋다. 모든 Frontend의 결과물이 본인이 만든 것이니, 그 뒤에 기획, Backend 등등이 누가 했건, 얼마나 많은 사람이 했건 상관이 없으니.

이게 불가능하다면, 최소한 페이지 단위로 역할을 나눠서 개발을 하자. 그리고 이력서에 본인이 했던 페이지나, 주요 PR들을 설명하고 Link를 달면 평가 하는 사람이 지원자가 어떤 것을 했고, 어떤 퀄리티의 코드를 짜는지 확인하기 쉬울 것이다. 그리고 회사에 와도 이와 비슷하게 잘 정리된 방식으로 작업을 할거라는 좋은 인상도 심어줄테고.

마지막으로

지원하시는 분들이 보는, 특히 신입으로 지원하는 분들이 보는 채용 과정은 드라마 <오징어 게임>에 가깝다고 느끼시겠지만, 현실은 어렸을 때 놀이터에서 놀던 놀이 <오징어 게임>에 더 가깝다. 이번 게임에서는 합격자와 탈락자가 나눠지겠지만, 결국엔 다 같이 놀고 어디선가 다 같이 만나는 같이 놀이터에서 함께 노는 친구들임을 잊지 않았으면 좋겠다.