[이직] 4년차 프론트엔드 개발자의 이직 후기

들어가며

이 글은  처음 경력직 이직에 마구잡이로 시도해보면서 반성과 후회가 쌓인 프론트엔드 개발자가 적은 글입니다.

엄청난 정보는 없지만 이직에 도전하는 동료개발자분들에게 한줌의 도움이 되길 바라며,

그럼 후기글 시작하겠습니다.

이직

이직... 이름만 보아도 벅차고 가슴 끓어오르는 단어입니다. 

저는 이직을 마음먹으면 바로 할 줄 알았어요. 이와 비슷하게 다이어트도 마음만 먹으면 할 줄 알았습니다.

이번에 2개를 병행하면서 아 마음먹기가 가장 어려운 거구나 라는 반성을 했네요. ㅎㅎ

이직을 막상 하려고 하는 두렵고 귀찮고 피말립니다.

저는 압도적인 개발자가 아니기때문에 저의 작고 소중한 강점과 언젠가는 고쳐야할 단점을 이쁘고 잘 꾸며서 어필해야하기 때문이죠.

동기

일단 이직을 마음먹게 된 계기, 동기가 있어야합니다. 

단순히 돈을 많이 벌고 싶다라는 건 누구나 가지는 기본적인 동기입니다.

그러니 우리는 이런 단순한 동기가 아닌 좀더 구체적인 동기를 찾아야합니다. 

잠깐 동기의 뜻을 찾아보면 동기 | 행동을 일으키게 하는 내적인 직접요인의 총칭 라고 합니다.

저는 내적인 직접요인인 동기를 2개로 나눠봤는데요. 

바로 현 회사에서 떠나려는 이유와 지원한 회사에 가려는 이유입니다.

현 회사에서 떠나려는 이유

모든 사람들은 겸손이 이유던 어떤 이유던간에 지금 있는 회사에 부정적인 얘기를 하는 경향이 있습니다.

아무래도 현재 상황을 만족하기는 힘든 일이기 때문입니다. 그러니 불만족하기에 좀 더 좋은 환경, 동료, 연봉을 찾아가는 건 어찌보면 당연한 일입니다.

저의 경우 현 회사를 떠나려는 이유는 3가지로 압축해봤습니다.

• B2C 회사로 가고 싶다.
• 비전이 있고 실행할 힘이 있는 회사
• 직무에 적합한 일에 집중하고 싶다.

지원한 회사에 가려는 이유

가려는 이유는 떠나려는 이유를 충족해줘야 가겠죠. 그래서 이유는 다음과 같습니다.

• B2C 회사로 거듭나기 위해 프론트엔드팀을 만들고 있다.
• 비전이 있고 그 비전을 위해 내가 할 수 있는 것이 많아 보였다
• 내가 할 업무가 명확하고, 업무에 대한 보상이 확실해보였다.

이 외에도 더 나이가 들기 전에 스타트업에 가서 인생 역전의 기회를 가져보고 싶기도 했습니다. ㅋㅋ

아무튼 동기는 이렇습니다.

어떤 사람은 워라벨을 또 다른 사람은 연봉을 최상의 목표로 둡니다. 그만큼 개개인만의 동기가 다를겁니다.

그런 만큼 이런 동기를 바탕으로 이직을 시작한다면 좀더 목표의식이 뚜렷해지지 않을까 생각합니다.

저는 이러지 못해, 서류 작성에만 3개월이 넘게 걸렸습니다. 
지금 회사에 불만은 있는데, 뭔가 뚜렷하게는 없었고 또 아무런 준비도 안하고 있진 않은 애매한 상태였거든요.

이직 프로세스

개발 직무의 경우, 이직 프로세스는 비슷합니다.

물론 각 단계별로 각 회사마다 다른 점이 있겠습니다만, 아무래도 사람을 뽑는건 그 사람의 능력과 성격을 알아야한다는 점에서 어쩔수 없이 보편화되는건 있습니다.

대부분의 이직 프로세스는 다음과 같습니다,

개발자 채용 프로세스

그리고 과제 전형이 코딩 테스트로 대체되는 경우도 있고, 경력직인 경우 생략되는 경우도 있습니다.

그리고 처우 협의 다음에 레퍼런스 체크를 하기도 합니다.

이제 각각 단계별로 제가 느낀 경험을 살펴보도록 할게요..

부족하지만 먼저 해본 사람으로서 가볍게 읽어주시면 감사하겠습니다.

[서류전형]

경력 이직은 서류전형에서 불합격할 확률이 낮습니다. 아무래도 신입보단 경력이 부족한 상황이니깐요.

만약 서류에서 탈락하셨다면 그건 여러분이 부족한 게 아닌 서류 자체의 구성이 잘못되었거나 내용의 핏이 맞지 않는 경우일 겁니다.
 그러길 바라고요.. 물경력이 아니시길!!🙏🙏🙏 )

이러한 서류 구성과 내용의 핏을 맞추기 위해 우린 고수님들의 구성 형식을 빌릴 필요가 있습니다.

또한 프로그래머스나 점핏등 여러 플랫폼에서 글을 작성하면 자동으로  경력기술서를 만들어주고 있습니다.

이런 구성의 경우 기본적으로 검증이 된 만큼 따라 한다면 평타는 칠 수 있을 것이라 생각합니다.

경력기술서

저는 경력기술서를 노션으로 작성했습니다.

노션으로 작성한 이유는, 업데이트가 쉽고 링크도 공유하기 쉽고 pdf로 변환이 쉽기 때문입니다.

그리고 일단 다른 플랫폼을 이용하기 전에 작성해 놓은 것이 있는지라 이용한 이유도 있습니다.

경력기술서를 쓰는 방법은 다양하지만 저는 유튜버 면접왕 이형님의 글을 참고했습니다

부족한 제 기술서지만 링크를 공유해보도록 할게요.

강경석 | 이력서

이렇게 하나를 만들어놓고 이후에 각 회사별로 추가내용을 기재하거나 자기소개서를 작성하여 제출하는 방식으로 진행했습니다.

또한 제가 어떤 책에서 읽기로는 이력서(경력기술서)의 경우 분기단위로 업데이트를 하라고 권고합니다.

이력서를 업데이트해보면서 해당 분기에 유의미한 성과와 원하는 목표에 도달했는지 점검해보면서 발전하라는 의미로요.

현 회사의 경우 분기평가를 하는데, 저는 이때에 맞춰 업데이트를 합니다. 또한 분기회고라는 스스로 생각해보는 시간을 가지곤 합니다.

2022년 2분기를 요약하자면 "이직을 위해 고군분투했고, 사이드프로젝트는 피벗중이며,  업무를 마무리하기 위해  일을 안벌렸다" 라고 할 수 있겠네요.

포트폴리오

포트폴리오는 이제껏 해온 프로젝트를 정리하는 산출물을 의미합니다.

디자이너와 같은 직군이면 필수지만 프론트엔드의 경우 선택사항입니다. 지원한 회사에서 강제사항인 경우는 없었습니다.

하지만 저는 자바스크립트, react, next를 테스트해보기 위해 포트폴리오 사이트를 계속 업데이트하고 있었던 만큼 링크로 깔끔하게 제출했습니다.

포트폴리오는 경력기술서보다 형식에 제한이 없습니다.

제한이 없고 직접 코드로 만들수 있는 만큼 여기저기 찾아보시면 정말 이쁘고 잘만든 사이트를 찾아보실수 있습니다.

저는 요새 i18n과 동적인 요소를 추가해보려고 하는데 너무 귀찮네요...ㅎㅎ

작고 소중한 제 사이트는 아래와 같습니다.

Handy | 편리함을 추구하는 개발자

쨋든 이렇게 해서 서류전형의 경우 지원한 회사 총 10개 중 9개에 합격할 수 있었습니다.

유일하게 떨어진 곳은 업비트를 만들고 있는 두나무였는데요.. 역시 평균연봉 3억에 허들은 높습니다..

[과제, 코딩 테스트 전형]

코딩테스트

코딩 테스트의 경우 수많은 지원자를 거르기 위한 압도적인 편리함으로 자주 사용됩니다.

코딩 테스트의 팁이라고 하면 관심을 가지고 꾸준히 하는 거밖에 답이 없습니다.

국내 회사의 경우 코딩테스트에 대한 호불호 여부가 많이 갈리고 또 없애고 있는 회사가 생기고는 있지만,

글로벌 빅테크의 경우 실제 면접에서 문제를 던져주고 하는 라이브 코딩 테스트를 많이 한다고 들어서 코테 여부와 상관없이 꾸준히 하려고 노력하고 있습니다.

프론트엔드는 코딩테스트와 같이 알고리즘을 푸는 것이 필요 없다는 의견을 가지신 분도 많습니다.

하지만 개발자인 만큼 이러한 지식과 능력은 필수적으로 가져가야 한다고 생각하는 1인으로써 일주일에 1문제는 풀려고 노력하고 있습니다.

과제테스트

코딩테스트와 달리 과제의 경우 제가 조그마한 팁을 드릴 수 있습니다.

일단 기능 구현은 기본으로 깔고 가야 합니다.

제가 과제테스트를 7번 정도 요청받고 4번을 했습니다. 모두 구현 자체는 어렵지 않았습니다.

하지만 4번중에 맨 처음 과제는 탈락을 했었습니다.

기능 구현을 했는데 뭐가 문제이지 고민하다가 여러 커뮤니티에서 조언을 듣고 2가지 추가작업을 했습니다.

1. 스토리북으로 컴포넌트 테스트
2. Jest와 react testing library로 로직 테스트

바로 테스트입니다. 실제 과제테스트에서느는 이런 테스트를 명시적으로 요구하지 않았습니다.

하지만 맨 처음 과제테스트에서 탈락하고 이후 테스트에서는 실제 업무에 사용하는 것보다 해당 테스트의 강도와 커버리지는 엄청 낮추더라도 작업을 해서 제출했습니다.

그 이후로는 모두 합격할 수 있었습니다.

그 외로 기능 구현 뿐만 아니라 신경써야할 것이 있습니다.

바로 커밋 메시지, 컨벤션 지키기, 제대로 된 변수명 쓰기 등 기본적인 것입니다. 

이 부분은 평소에도 해왔던 것이니 그냥 똑같이 한다고 생각하고 과제를 수행하시면 됩니다.

저의 경우 기술면접에서 temp로 만든 변수에 대해 질문을 받았는데요.

솔직하게 바꾸는 걸 까먹었다고 말씀드렸습니다. 그리고 어떤 식으로 이름을 작성하면 좋겠느냐고 재질문이 이어졌고 수정된 변수명을 말씀드리고 넘어갔습니다.

이렇듯 나름 핵심적인 부분은 코드단위로 살펴보고 온다는 느낌을 여럿받았습니다.

마지막으로 readme 제대로 작성하기입니다.

대부분 과제만 툭 던지는 경우도 많은데,
만약 라이브러리나 기술 스택이 제한되어있지 않다면 해당 라이브러리와 스택을 사용한 이유와 기본적인 설계내용을 적어주시면 좋습니다.

저는 실제 업무에서 쓰던 것을 가져오는 경우가 많았기에 그냥 평소에 생각했던 도입 이유를 간단히 적었습니다.

아 추가로 완성되면 코드만 보내기보다는 vercel 등으로 간단히 배포하고 해당 링크도 함께 보내면 더욱 좋을 것 같습니다.
(vercel로 배포하는데 5분도 안 걸리니 그냥 하십시오)

readme 예시

[직무 인터뷰]

주로 기술적인 질문을 물어보고 답하는 단계입니다. 기술면접이라고도 하는 단계입니다.

그리고 이 부분의 평소에 꾸준히 공부를 하거나 인터넷에서 찾아보면 많이 있습니다.

대다수의 질문들이 그 범주를 벗어나지 않으니 그냥 쭉 읽어보고 암기할 부분은 하면 됩니다.

이 부분에서 저는 좀 반성을 해야 하는 것이.. 제대로 준비를 안 하고 갔습니다..

그래서 요새 공부하고 있는 react, next에 대한 질문은 곧잘 대답하고 최신 기술 얘기를 하면서 즐겁게 대화를 했습니다. react 18에서는 어떤 것이 기대된다. tailwind 써보니 이런 장점이있는데 클래스명에 대한 러닝커브가 좀있다. 같은 내용 들이었습니다.

그런데 자바스크립트에 대한 질문에서 답변을 제대로 못했습니다.

질문 리스트들은 인터넷에 찾아보면 많이 있으니 여기서 언급은 안 할게요.

그 외로 기술 질문을 통해 점차 깊은 대화로 가는 방식과 달리 그동안 했던 프로젝트에 대한 발표를 요청한 회사도 있었습니다.

이런 유의 발표는 처음이라 인터넷에 마땅한 예시도 구할 수 없어서 과거 프로젝트를 gif로 따오고 그 뒤에 해당 프로젝트에 내용을 적는 방식으로 발표를 했습니다.( 물론 프로젝트의 경우 공개된 부분에 대해서 gif를 추가했습니다. )

내용을 보면 그냥 경력기술서에 있는 내용 그대로 가져오고 실제 프로젝트 gif밖에 추가된 것뿐입니다.

발표 ppt

그리고 프로젝트 외에도 추가적으로 적을만한 것들을 뒤에 붙였는데요.

블로그 및 문서화 관련 내용 ppt

개발도 중요하고 잘하는 사람이지만 개발 외적인 일도 신경 쓰고 관리하고 있다고 어필을 했습니다.

[조직문화 인터뷰]

컬처핏 면접, 인성, 임원 면접 등으로 불리는 단계입니다. 여기까지 온다면 어느 정도 어려운 단계는 지났습니다.

하지만 저는 여기에서 떨어졌는데요 ㅋㅋㅋ

변명을 해보자면 코로나 격리 중에 면접을 봐서 몸도 안 좋았다 라고 하고 싶네요.

아차 싶었던 질문과 대답은 다음과 같습니다.

Q) 프론트엔드의 경우 다른 사람과 커뮤니케이션을 할 일이 많은데, 서로 의견이 충돌하면 어떻게 중재하시나요?

A) 제가 생각하기론, 의견이 충돌하는 이유는 주인의식이 없기 때문이라고 생각합니다. ~~~~

라는 식으로 답변을 했습니다.

네. 컬처핏 면접을 보고 있는데 다짜고짜 남 탓하기를 시전 한 것입니다. 지금 생각해보면 면접관분이 어떤 생각을 했을지 궁금합니다.

이 말을 한 저도 제가 면접관이라면 바로 탈락일 것 같은 대답이었으니깐요..

다시 조직문화 인터뷰로 돌아가서

이 단계에서는 기술적인 질문보단 개발자로서의 목표, 자아실현 또는 취미, 스트레스 관리 등 그냥 일상적인 대화가 주를 이루게 됩니다.

앞에 단계들이 정답이 있는 질문들이었다면 이 단계에서는 정답이 없는 질문들과 대답이 오가는데요.

그중에 기억이 남는 질문은 다음과 같습니다.

Q) 동료, 비전, 연봉, 문화, 워라벨 중에 중요한 것들을 순서대로 말해주세요.
Q) 만약 친한 친구들이 지원자를 소개한다면 뭐라고 할 것 같은가요?

당연히 정답은 없는 질문이고 깊게 생각해본 적이 없는 질문들이었습니다. 여러분은 어떠신가요?

[처우협상]

일단 협상을 임하는 마음가짐에 대해 논해보겠습니다.

한 번에 만족한 대화는 협상이 아니다

그렇습니다. 협상이란 양쪽에게 win-win이 되야만 합니다. 하지만 한번에 win-win이 되는 상황은 쉽사리 오지 않습니다.

그래서 이직 프로세스를 시작하기 전에 생각했던 처우를 결정짓고 가시는 것을 추천드립니다.

처우협상 단계뿐만 아니라 다른 단계에서도 원하는 처우에 대한 얘기를 조금씩 물어보시기도 하니깐요.

가끔씩 좋은 환경, 동료, 문화를 위해 옆그레이드 하거나 연봉을 깎아서 가기도 하기도 합니다.

하지만 저는 좋은 환경, 동료, 문화, 연봉을 놓치기 싫기때문에 이직준비를 했기때문에 욕심과 탐욕을 가지고 해봅시다.

만약 처우협상이 안된다면 어쩔수 없죠. 다른 회사를 찾을 수 밖에요.

물론 대략적인 선이 존재합니다. 갑자기 제가 CTO수준의 연봉을 요구하거나 할 수는 없으니까요.

최소 처우의 기준은 전직장 + 10% 입니다. 물론 최소 처우가 회사의 기준에 훨씬 못미치거나 넘는 경우 다시 오퍼를 주거나 불발되기도 합니다.

사람의 마음이라는 것을 불발된 것에 두려움이 있으나, 우리가 갑자기 돈 2배로 줘요 이런식으로 강짜를 부리지 않는 이상 해당 기업의 인사담당자님께서 충분히 조율을 하려고 노력하실 겁니다.

그러니 나는 이정도 가치를 가지고 있다는 자신감과 협상을 하려는 겸손한 마음을 가지고 차분히 대화를 하셔보기를 추천드립니다.

[최종합격]

이제 이직의 프로세스는 거의 마무리되었습니다. 오퍼 레터를 수락하고 이리 저리 간단한 서류가 오가고 이제 회사에 퇴사 통보를 하고 진행하면 됩니다.

좋은 사람이 머문 자리는 뒤도 아름답습니다라는 말이 있습니다.

새롭게 가는 회사 동료들에게도 좋은 사람이 되는 것도 중요하지만,

지금 있는 사람들에게도 좋은 사람으로 떠나는 것도 매우 중요합니다.

이 사람들은 저와 함께 시간을 보냈고, 또 어떻게 인연이 되어 다시 만날지 모르는 미래의 잠재적 동료들입니다.

간혹 퇴사할 때 똥을 투척하고 간다는 얘기가 들려오지만, 그럴 수 있을 때는.. 흠 아무래 생각해도 없네요. ㅋㅋ

대부분의 회사 퇴사 절차는 1달 정도입니다. 그 시간 동안 하던 업무를 마무리하고 인수인계서를 작성하고 또 미뤄놨던 문서화를 최신화하는 과정이 필요합니다.

간혹 이 단계에서 기존 회사에서 카운트 오퍼가 들어오는 경우도 있습니다. 

카운트 오퍼에 응할지 아니면 본래대로 이직을 할지는 여러분의 선택이니 다시 한번 고민하고 선택하시면 됩니다.

추가로 해야할 것이, 최종합격했으나 가지 않게된 회사에 대한 회신입니다.

인사담당자든, 아니면 해당 회사를 위해 도움을 주신 분들에게 상황을 설명하고 이번엔 함께 못하게 되었다는 내용과, 다음 기회에 다시 만나뵙길 바란다라는 말을 한다면 충분합니다.

마치며

이로써 제 이직 경험기와 이곳저곳에서 들려온 내용을 취합한 간단한 이직 후기 글을 작성을 했습니다.

주변을 둘러보면 저보다 훨씬 뛰어난 개발자 형누님(저보다 뛰어나면 다 형누님임)과 프로이직러분들이 계십니다.

하지만 각자 처한 상황이 다르고 또 막상 이직이란 게 주변에 말하고 준비하기가 어려운 작업인 만큼 

인터넷에 던지듯 작성한 제 글이 여러분의 이직에 한줌의 도움이 되길 바라며 

글을 마칩니다.

끝.