하, Frontend 개발자형들!

Laeyoung·2023년 1월 9일
492
post-thumbnail

몇명만 더 보면 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를 달면 평가 하는 사람이 지원자가 어떤 것을 했고, 어떤 퀄리티의 코드를 짜는지 확인하기 쉬울 것이다. 그리고 회사에 와도 이와 비슷하게 잘 정리된 방식으로 작업을 할거라는 좋은 인상도 심어줄테고.

마지막으로

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

profile
함께, 자라기

27개의 댓글

comment-user-thumbnail
2023년 1월 10일

너무 공감이 되면서 정말 중요하다고 느껴지는 점 콕 잘 짚어서 얘기해주신 것 같아요. github에 코드를 올려두면 알아서 보시겠지라는 생각은 너무 나이브하죠. 특히 프론트엔드라면 결국 사용자와 마주하게 되는 직군인데 내가 만든 코드이전에 1) 서비스를 보여줘야 하고 2) 내가 만든 프로젝트의 문서를 보여줘야 하고 3) 내가 실제 작업한 부분을 알려줘야 한다는 점 현재 이력서를 쓰고 포트폴리오를 준비하시는 많은 프론트엔드 분들에게 전달이 되었으면 좋겠습니다. :)

답글 달기
comment-user-thumbnail
2023년 1월 11일

구직자에게 바라는게 많은 느낌이 드네요.
이력서가 취업을 하기 위한 필수 사항이고, 나머지는 있으면 좋은, 채용에 가산점을 줄 수 있는 사항인데 그걸 주저주저리 적어 놓은 것 자체가 넌센스임.
차라리 벨로그에 쓸 글을 채용 공고에 적어서 본인의 시간을 낭비를 최소화하는게 좀 더 영리한 방법이었을 것 같네요

3개의 답글
comment-user-thumbnail
2023년 1월 12일

제품을 배포해서 바로 볼 수 있는게 프론트의 가장 큰 매력이라고 생각해요! ㅎㅎ 프론트짱짱맨

답글 달기
comment-user-thumbnail
2023년 1월 12일

취준인데 마지막 문장이 너무 인상적이네요.
저에겐 아직 오징어게임이지만, 놀이터에서 뵐 날이 왔으면 하네요.
도움이 되는 좋은 글 감사합니다.

답글 달기
comment-user-thumbnail
2023년 1월 12일

좋은 글 감사합니다!

답글 달기
comment-user-thumbnail
2023년 1월 13일

끝내주는 글이네용

답글 달기
comment-user-thumbnail
2023년 1월 13일

안녕하세요! 저는 프론트엔드 개발자를 꿈꾸며 취업을 준비중입니다! 도움이 되는 글 잘 읽어보았습니다 감사합니다! 질문이 있어 댓글을 남겨요 3번에서 팀프보다는 개인프로젝트가 더 좋다고하셨는데 개발자는 협업이 중요하고 채용공고에서도 협업경험조건을 많이 보았는데 팀프로젝트를 이력서에 안넣어도 정말 괜찮을까요? 보통 부트캠프광고글에도 백엔드와 협업하여 프로젝트를 진행할수있다는 것을 내세워 마케팅을 해서 이력서에 팀프로젝트를 넣으면 큰 플러스요인이 될거라고 생각했거든요..

2개의 답글
comment-user-thumbnail
2023년 1월 14일

마지막 문장에 무릎을 탁!하고 치게 되네요 :-)

2개의 답글
comment-user-thumbnail
2023년 1월 15일

좋은 글 참고가 많이 되었습니다!

답글 달기
comment-user-thumbnail
2023년 1월 17일

좋은 글이라고 생각합니다 :D

답글 달기
comment-user-thumbnail
2023년 1월 18일

참 저도 개발은 오래했는데 보여줄 서비스하나 없는게 반성이 되기도하네요. 이번에 한번 진지하게 만들어봐야겠습니다!!

답글 달기
comment-user-thumbnail
2023년 6월 23일

감사합니다.
어떻게 준비하고 지원해야할 지 알게 되는 유익한 글이었습니다!

답글 달기
comment-user-thumbnail
2023년 8월 21일

감사합니다. 생각 못한 부분에 대해서 많이 깨달았습니다.

답글 달기
comment-user-thumbnail
2023년 12월 3일

이글 많이 공감. 한편으로는 github 실행까지... 정말 성의를 가지고 서류단계에서부터 지원자를 꼼꼼히 살펴보시는 점 존경! 아무튼 올해 초 글인데 이제서야 보게되었네요.. 👍

답글 달기
comment-user-thumbnail
2024년 2월 14일

내용이 알찹니다 공감이 많이되는 글이었습니다. 즐거운 하루되세요.

답글 달기