퇴사 후 이직, 후회했을까? 3년 차 개발자의 이직 준비 기록

퇴사 후 이직, 후회했을까? 3년차 개발자의 이직 준비 기록

이직을 고민하는 개발자라면 누구나 한 번쯤 "선 퇴사 후 이직이 괜찮을까?"라는 질문을 해본 적이 있을 것입니다. 저 또한 같은 고민 끝에 이직처를 확정하지 않은 채 퇴사를 결심했고, 그 이후의 과정과 결과를 공유해보려 합니다. 저는 첫 회사에서 2년 3개월 동안 근무한 뒤 퇴사를 했고, 이 글이 비슷한 고민을 하는 개발자들에게 조금이나마 도움이 되길 바랍니다.

1. 퇴사 후 이직, 후회했을까?

✅ 선퇴사를 결정한 이유

• 왜 퇴사를 결심했는지
  웹 개발을 하는 사람으로서 프론트엔드 직무를 좀 더 다양하게 경험하고 싶었습니다. 하지만 회사의 웹 서비스 특성과 로드맵을 예상해봤을 때, 아쉬움이 남았고, 사용자 피드백을 빠르게 반영하는 개발 프로세스에 대한 갈증이 있었습니다. 그래서 B2C 서비스를 운영하는 스타트업에 대한 관심이 커졌습니다.

 

• 이직을 바로 하지 않고 먼저 퇴사한 이유
  퇴사 전, 서류를 준비하고 일부 전형을 진행해봤지만 면접 시간을 잡기 어려웠습니다. (제가 연차를 다 소진해버린 개인적인 사정 탓 😮‍💨)
  그리고 좀 더 시간을 두고 제대로 이직 준비를 해야겠다는 생각이 들었고, 또한 회사에 다니면서 업무에 집중하는 게 쉽지 않다는 점도 느꼈습니다. 이 부분이 제가 스스로에게 원하는 업무 퀄리티와 집중도의 기대치에 맞지않아 괴로웠습니다.
  
  

✅ 예상했던 것 vs. 현실

• 퇴사 후 계획했던 것들
  퇴사 후에는 여행을 다니고, 회사 다니면서 미뤄왔던 기술 부채를 처리하며 기술 블로그를 운영할 계획이었습니다. 또한, 채용 프로세스가 진행되면 그에 맞춰 집중해서 준비할 생각이었습니다. 실제로 회사에서 맡았던 프로젝트와 해결한 기술적 문제들을 중심으로 이력서를 계속 다듬었습니다. 이 과정에서 "이 한 줄에 담기엔 내가 겪은 과정이 더 많다"라고 느꼈던 기술적 과정을 블로그에 기록했습니다. 물론, 회사의 코드가 노출되지 않도록 신경 썼습니다.

 

• 실제로 겪어보니 달랐던 점
  생각보다 기술 블로그 운영은 큰 장벽이 아니었습니다. 이제 시작하는 법을 배웠으니, 재직 중에도 충분히 블로깅을 할 수 있을 것 같습니다. 예전에는 기술 블로그가 선택 사항이라고 생각했지만, 실제로 채용에 도움이 되었다고 느껴서 잘 했다고 생각합니다. 또한, 첫 이직 준비를 하면서 부담감이 커져 심리적인 여유를 갖고 싶었습니다. 그래서 충분한 시간을 확보하려고 했고 여행도 여러 차례 다녀올 수 있었습니다.
  그리고 생각외로 공백기에 대한 공격(?)이라고 느낄만한 질문내역은 많지 않았습니다. 그것보다 공백기에 대한 내 가치관이나 어떻게 활용하고자 했는지 등 의도와 실제 액션에 대한 내용을 궁금해한다고 느꼈습니다.
  
  

✅ 공백기에 대한 고민

• 심리적 부담감과 불안함
  공백기에 대한 불안감을 느끼지 않으려 했지만, 최악의 상황을 상상할 때도 있었습니다. "재직 중이었으면 최악은 피할 수 있었겠구나"라고 생각하기도 했습니다. 모든 결정에는 장단점이 있지만, 제 성향상 재직 중에 준비하기는 여유롭지 않겠다고 생각했고, 리스크는 있지만 후회하지 않도록 준비에 몰두하려 했습니다.
  최종적으로 5달 정도가 쉬게되었고, 3~4달째에 집중해서 취업준비를 했습니다.

 

• 주변 반응과 현실적인 조언
  주변의 반응은 반반이었습니다. "그간 열심히 일했으니 잠시 쉬면서 다음 회사를 차분히 찾는 게 좋다"는 의견과 "불안하지 않겠냐"는 의견이 나뉘었죠. 결국, 결정은 제가 내려야했으니 그때그때 필요한 조언을 스스로 구해가는 방식으로 진행했습니다.
  주로 커피챗을 통해 제가 채용되기 원하는 곳의 재직중이신 개발자나 비슷한 경험을 가진 사람들의 이야기를 듣는 방법을 택했습니다. 그외에 감사하게도 먼저 요청주신 경우도 있어 즐겁게 인사이트를 나누며 커피챗을 진행하기도 했습니다!
  
  

2. 개발 블로그가 채용에 도움이 되나요?

✅ 실제 면접에서 받은 피드백

• 블로그에서 다뤘던 기술 주제가 면접에서 언급되었는지
  블로그 운영과 글 작성에 대해 면접에서 이야기를 나누면서 기술 블로그 운영이 유의미하다는 점을 느꼈습니다. 면접관은 낯선 사람을 1시간 만에 동료로서 어떻게 파악할 수 있을지 고민하는데, 블로그가 그 역할을 했던 것 같습니다.
  
  특히, 예상외로 회고글 같은 비기술적 글들이 면접에서 큰 도움이 되었습니다.
  기술 포스팅을 이력서에 링크하여 실제 개발기를 신뢰성있게 전달하는 역할을 하였고, 비기술적인 글들은 이력서에서 보기 힘든 솔직하고 인간적인 느낌이 나는 글을 블로그에서만 볼 수 있었기에 면접에서 더 깊은 대화를 나눌 수 있는 소스가 되었습니다.

 

• 블로그가 서류 통과에 긍정적인 영향을 미쳤는지
  블로그 글이 쌓일수록 서류 합격률이 높아졌다고 느꼈습니다.
  물론, 블로그 외에도 이력서를 다듬으며 퀄리티가 높이지거나 면접 준비가 더 능숙해지는 등 여러 요소들이 복합적으로 작용했겠지만, 면접에서 블로그에 대한 이야기를 나누며 긍정적인 인상을 준 것 같다고 느꼈습니다.

3. 코딩 테스트와 기술 면접, 어떻게 준비해야 할까?

✅ 코딩 테스트 & 과제 전형 준비법

• 내가 본 코딩 테스트 & 과제 예시
  5곳의 코딩 테스트와 4곳의 과제 테스트를 진행했습니다.
  코딩 테스트는 대부분 알고리즘 테스트였고, 한 곳만 리액트를 활용한 코딩 테스트였습니다.
  과제 테스트는 대부분 기본적인 폴더 구조와 레이아웃 컴포넌트를 제공하고, 몇 가지 API를 활용해 데이터를 가져온 후 요구된 UI를 구현하는 방식이었습니다.

 

• 실제로 도움이 되었던 학습 자료
  알고리즘 코딩 테스트는 제가 보아온 코딩 테스트에서 모두 테스트케이스를 풀었기 때문에 도움이 될만한 내용을 공유할 수 있을 것 같습니다. 대학생때부터 조금씩 백준과 프로그래머스 문제들을 풀었다가 쉬었다가를 반복해서 기억 저편에 있긴한데 문제를 보자마자 풀 수 있을 정돈 아니었습니다.
  
  프로그래머스 2단계, 백준 실버 문제 정도를 해결할 수 있는 수준이었습니다. 이 정도에서는 사실 코테에 나오는 어려운 킬러문항을 풀어내기엔 어려움이 있다고 느꼈습니다.
  코테를 위해서는 기본 자료구조(map, set, stack, queue)를 활용할 수 있으면 되고, 알고리즘은 BFS/DFS/백 트래킹/투 포인터/Dynamic Programming 정도만 무리없이 활용할 수 있으면 되는 것 같습니다.

백준에서 그렇게 어려운 문제를 많이 풀지 않았습니다.
제가 느끼기에 골드4 정도를 풀면 괜찮을 것 같고,
어려운 문항은 시간이 예외 케이스를 고려하느라 항상 부족하기 때문에 어려운 문제를 많이 풀기보단 상대적 쉬운 문제를 빨리 실수없이 풀어내는게 중요한 것 같습니다.

허무한 디버깅에 시간을 많이 써버리면 힘드니까요... (생각보다 매우 중요합니다. :fire: )
 
특히, 어떤 문제를 풀어야할지 모르겠거나 문제가 막혔을때 해설이 필요한 경우에는 인프런의 10주완성 C++ 코딩테스트를 추천합니다. 두고두고 볼수있어서 꽤 도움을 많이 받았습니다.
유형별로 백준 문제도 정리해주셔서 문제 고르고 해설 검색해다니는 시간을 소비하지 않아도 되는 점에서 큰 만족도를 느꼈습니다.

알고리즘 코테 관련하여 불안감이 있으신 분이 많은것같습니다. 더 궁금하신 부분이 있으시면 댓글 혹은 메일 주시면 더 답변드리겠습니다. 😖
- 메일은 하단에 있습니다.

 

전 JavaScript로 코테를 봤는데, 인강은 C++를 사용하십니다. 그래도 알고리즘 설명에는 무관하여 별 어려움은 없었습니다.

과제 전형은 4곳 중 1곳 미응시/2곳 합격/1곳 탈락이었습니다.
합격률이 썩 좋지않아서 준비법이라고 공유하기 어려울 것 같지만, 내가 또 과제를 본다면 최대한 추가 라이브러리를 안쓰고 가볍게 구현하는 방식으로 볼 것 같습니다.

과제전형에서 나오는 수준은 라이브러리를 사용할 정도로 복잡하지 않고 최대한 내 코드 스타일을 보여주는게 좋다고 생각했고, 대신 간략하게 기능 구현을 진행하고 시간을 나눠서 E2E 테스트를 작성해보면 좋았겠다고 생각합니다.

✅ 기술 면접에서 받았던 질문(이력서 기반, CS 개념)과 대비 방법

• 기술 면접 진행
  기술 면접은 보통 이력서 기반의 기술 질문과 퀴즈 형식의 질문으로 나뉩니다. 가장 먼저 자기소개를 하면서 내가 가장 내세우고 싶은 기술과 프로젝트를 설명한 후, 이에 대해 이야기를 나누며 면접이 진행됩니다. 이후 이력서 기반의 기술적인 내용이나 프로젝트 경험에 대해 질문이 이어졌습니다. 
  대부분 이렇게 본인의 경험에 대한 이야기를 나눈 후 퀴즈 형식의 질문을 진행했습니다. 아마 긴장을 먼저 풀기 위함이었을것이라고 생각합니다. 실제로도 개인적 경험을 이야기하다보면 긴장이 꽤나 풀리는 것을 경험하였습니다. ㅎㅎ

 

• 이력서 기반 질문
  프로젝트가 생긴 맥락이나 비지니스 상황을 이야기하기도 하고, 어떤 문제가 생겼고 그걸 어떻게 접근하여 해결하려고 했는지를 파악하는게 중요하다 보니 상황을 간략하게 정리해서 전달하는게 중요했습니다. 너무 자세히 이야기하려고 하면 듣는 사람이 지루해져서 역효과가 날 수 있으니 주의하면 좋을것같습니다.
  
  그리고 수동적인 상황 설명보다는 내가 결정한 의사가 아니더라도 이런 상황이었고 그래서 회사입장에서 이런게 필요했다와 같이 비지니스와 맥락을 이해하고 있고 난 그 안에서 어떤 기술적 직무를 수행했다는 흐름으로 이야기를 전달하는게 좋았던 것 같습니다. 그리고 특히나, 기술적 해결 방법에는 여러 가지 선택지 중 하나를 고르게 되기 때문에 한두가지 선택지를 설명하고 그중에 이런 이유로 선택했다는 배경이 있으면 전달하는 것이 좋았습니다.

 

• 주요 질문 유형 및 경험 공유
  여러 기업에서 무조건 질문하는 것들이 몇가지 있었습니다. 이 질문 외에는 인터넷 질문 리스트를 보면서 공부하고 설명이나 사례 등이 빈약해도 좋으나, 이 질문들은 명확한 기술 용어를 사용하면서 확실히 대답할 수 있어야 한다고 느꼈습니다.

1. 브라우저에 주소창 검색한 후 일어나는 내용: DNS가서 IP 찾아오고 필요한 리소스 가져옴. HTML 파싱하면서 돔트리, CSSOM, 렌더트리만들고 layout, paint, composition 과정
2. 이벤트 루프: Call stack, Micro Queue, Microtask Queue, render 설명
3. Stack, Queue 자료구조 설명과 사용 예시
4. 클로저 설명과 예시
5. JavaScript 가비지 컬렉터 알고리즘과 메모리 누수 발생 예시
6. 브라우저 렌더링 과정에서 reflow 가 무엇이고 왜 중요한지. 발생시키지 않으려면 어떻게 해야하는지 예시 설명.

이정도가 여러 곳에서 공통으로 나오는 기술 질문이었습니다. 처음엔 긴장해서 버벅이기도 했지만, 면접을 계속 보다보니 입에 붙어서 줄줄 설명할 수 있게되어 경험이 쌓일 수록 수월할 수 있었습니다!

5. 채용 프로세스는 보통 어떻게, 얼마나 걸리나요?

✅ 지원에서 서류합격까지 오는 시간 평균

보통 아래와 같은 절차로 진행되었습니다.

• 서류 → (코딩/과제 테스트) → 기술 면접 → 최종 인터뷰 → 오퍼

개인적으로 서류 합격까지 걸린 시간을 평균을 내보고싶었습니다. 지원한 모든 전형을 노션으로 정리하여 평균을 내보았습니다.

채용 지원 현황 노션 데이터베이스 정리

채용지원현황 노션 템플릿이나 정리 관련 더 궁금하신 부분이 있으시면 댓글 혹은 메일 주시면 더 답변드리겠습니다. 😖
- 메일은 하단에 있습니다.

36개 지원하여 9개 회사에서 서류 합격회신이 왔습니다.
이 중 가장 빠른 곳을 1일만에 왔고, 가장 느린 곳은 15일만에 왔습니다. 평균 6.2일이 걸렸습니다! 🎉
(4일에 서류를 지원해서 6일에 합격회신이 왔다면 2일 걸린 것으로 본다.)

• 1일 1곳
• 2일 2곳
• 4~7일 4곳
• 15일 2곳

생각보다 늦게 오는 곳들도 있었어서 정리하면서 재밌네요 ㅎ

✅ 지원부터 최종 오퍼까지 걸린 시간

최종 합격한 2곳이 있었습니다.
한 곳은 7주가 걸렸으나, 중간에 설 연휴 1주를 감안하면 워킹데이 약 6주가 걸렸고, 한 곳은 3주 정도로 빠르게 진행되었습니다.
거의 2배 정도 차이네요... 아마 인터뷰 횟수와 레퍼런스 체크하는데 드는 시간때문에 차이가 나는 것 같았습니다.

✅ 선퇴사를 고려하는 개발자를 위한 현실적인 조언

• 선퇴사를 고려할 때 꼭 체크해야 할 것들
  이직을 고려할 때 이력 정리를 먼저 해보면 어떤 스토리가 생길지, 어떤 것들을 더 경험해볼 수 있을지 알 수 있어서 퇴사 전에 준비하는 것이 중요하다고 생각했습니다. 이력 정리 없이 퇴사하는 것은 조금 아쉬울 수 있어요. 퇴사 전에 현재 회사에서 할 수 있는 업무나 경험을 최대한 쌓고, 후회 없이 이직을 준비하는 게 좋습니다. 회사에 단점이 있더라도 다양한 시도를 할 수 있는 기회가 될 수 있고, 실패하더라도 그 경험은 소중한 이력이 될 것입니다.

또한, 지금 회사에서 아쉬운 점을 잘 고민해보면서 단순히 연봉이나 복지 조건만 보고 다음 회사를 선택하는 것보다는 내가 가장 원하는 것을 신중하게 정리하는 과정이 중요하다는 걸 느꼈습니다.

---

이직은 누구에게나 쉽지 않은 과정입니다. 하지만 충분한 준비와 계획이 있다면 더 나은 기회가 올 수 있습니다. 이 글이 퇴사 후 이직을 고민하는 개발자들에게 도움이 되길 바랍니다!
 
+) 추가로, 이 글이 제 예상보다 많은 이들에게 닿고 있는 것 같습니다.
혹시 직접 질문이나 의견이 있으시다면 댓글 혹은 ghdqlsdl9633@gmail.com 메일로 보내주시면
최대한 제 기억과 경험을 살려 도움이 되도록 지원드릴 수 있다면 즐거운 경험일 것 같습니다. 🙂