프론트엔드 개발자 이직 고민

Question

안녕하세요.
이직 고민이 깊은 2년차 프론트엔드 개발자입니다.
저는 현재 이천에 본사가 있고 분당 사무실에서 근무 중입니다.

개발 회사가 아니라서 백엔드 하시는 한 분과 2년 가까이 힘들게 개발하고 있고요.
회사 업무로 꾸준히 Vue를 다뤘고, React와 TypeScript 등을 열심히 공부하고 있습니다.

체계가 전혀 없기 때문에 그동안 좋은 개발 회사들을 참고하면서 체계를 잡아가려고 애썼습니다.
프론트엔드 팀이 아닌 혼자이지만, 회사 GitHub 팀 계정을 만들고, Git을 나름대로 feature 별로 branch를 나눠서 개발하고, Prettier와 ESLint 설정 파일 만들어서 관리하고... 그렇게요.

그러다가 최근에 분당에 있는 사무실의 계약이 끝나가서(8월 말) 9월부터 이천 본사로 출근하게 된다는 충격적인 소식을 접했습니다.
강남이나 판교가 아닌, 물류 회사들만 즐비한 이천으로 출근을 시작하게 된다면 커리어가 후퇴할 건 불보듯 뻔한 일이기 때문에 서둘러서 이직 준비를 하고 있습니다.

코딩테스트는 지금 급하게 준비해봤자 한 문제도 제대로 풀지 못해서 과제 테스트를 보는 곳 위주로 지원하고 있습니다.
다행히 이력서를 꾸준히 업데이트 해와서 원티드, 프로그래머스, 리멤버 같은 채널을 통해 바로 지원할 수 있었습니다.
급하게 준비해서 본 기술 면접은 두 건이나 탈락했습니다. 몇주 전에는 서류 통과를 무난하게 했었는데, 최근에 지원한 기업은 계속 탈락하고 있습니다.

그 와중에 정말 열받는 건, 지원한 곳이 감감무소식일 때 앱을 확인해보면 불합격 알람이나 메일도 없이 [불합격] 탭으로 빠져있는 겁니다.
합격해서 면접까지 가는 곳과 불합격한 곳의 차이는 기업 내부 사정이니 그러려니 합니다.
하지만, 개인적으로는 불합격이더라도 최소한 알림은 주는 게 지원자에 대한 예의라고 생각합니다.

사실 저는 지방 SI 회사 출신입니다. 2년간 프로젝트에 참여했고, 이력서에도 경력란에 가장 큰 부피를 차지하고 있습니다. 프론트엔드 개발자를 하고 싶다는 이유 하나만으로 독학해서 수도권으로 이직했거든요.
면접은 답변이 부족하면 떨어질 수 있지만, 서류 탈락의 이유가 전 직장 때문인지도 의문이 들고 괜히 후회스럽고 요즘 마음이 싱숭생숭하네요.

서론이 길었네요. 저의 고민은 이렇습니다.
1. 이대로 면접 준비를 계속 하며 계속 계속 지원해본다. (프론트엔드 기본 지식을 숙련한다)
2. 퇴사하고 부트 캠프에 지원한다.
3. 코딩 테스트를 준비한다.

하향 지원하는 것은 바라지 않고 어떻게든 더 좋은 회사에 가서 더 좋은 실력과 함께 커리어를 쌓고 싶습니다.
읽어주셔서 감사하고 답변 기다릴게요!

Benjamin Kim · Accepted Answer

열심히 노력하시는데, 결과가 그에 따르지 못해 매우 안타깝습니다

개인의견이지만 부트캠프에 지원하는건 글 쓰신분의 경력이나 이력, 실력향상에 도움이 되지 않을 것 같아요

부트캠프의 커리큘럼이 알고 계신 내용보다 더 떨어질 수 있고, 잡다한 교육내용이 많은 곳이라면 다니기 전과 후가 차이가 없을 겁니다

뽑는 사람 입장에서도 부트캠프를 다녔다고 해서 더 관심있게 보거나 높게 쳐 줄 이유가 없습니다

프론트엔드는 결과, 포트폴리오만을 평가하기  좋은 직군이라 지원하는 회사에 보여줄만한 포트폴리오를 만드는게 나을 거라 보입니다

포트폴리오도 유행하는 클론코딩이나 이런거에 휘둘리지 마시고 많은 기능 보다 적은 기능의 고도화(성능, 대량의 데이타, 디비, 네트웍, api 설계구조, ui. Ux 의 고민) 을 담고 이 고민하고 해결했던 내용을 강조한다면 가능성이 높아질 것입니다

흔한말로 부트캠프, 클론코딩이라고만 적혀 있고 그외에 별다를게 없다면 믿고 거르는 분위기인거 같아 얘기 드립니다

커밋 잔디심기, 일일 TIL, 클론코딩, 부트캠프 이런것에 현업들은 현혹되지 않습니다
왜 이런것들을 해야만 하는지 , 한다면 어떻게 해야 하는지 본질에 집중해야 합니다

커밋 하나하나에 어떤 내용을 담아야 하고 커밋 그 자체가 중요한게 아니라 자잘한 커밋으로 이 개발자가 어떤 멋지고 중요한 기능을 넣으려 했는지가 보여야 합니다

TiL 이나 블로그는, 갯수가 중요하지 않고 제목, 내용, 펼쳐나가는 글의 구조, 논리성이 중요하고 주로 어떤 문제를 만났고 어떻게 분석했으며 어떻게 해결했고 어떻게 확인했는지의 결과가 상세하게 서술되어 있어야 합니다
그냥 복붙하거나, 스택오버플로우나 타 블로그에서 생각없이 가져와도 현업은 눈치챕니다, 안 하느니만 못한겁니다

Github 는 소스를 볼 수 있지만 git 을 보러 오는 현업 입장에서 생각해보면 될듯합니다
Read.me 를 꾸며서 어떤 기능을 만들었고 어떤 부분이 자신있는지 어디 부분을 보면되고 요약해서 설명이 되어 있는게 좋습니다
뽑는 사람은 소스코드를 다 볼 시간도 없고 다 보지도 않습니다, 보통은 그럴 이유가 없는거죠

조금이나마 이직하시는데 도움이 되길 빌겠습니다