개발자의 이직 전략 : 회사 선택부터 이력서까지

개발자의 이직 전략 : 회사 선택부터 이력서까지

일자

상시

주최자

인호준 무신사 프론트엔드 개발자
유형
아티클
태그
이 아티클은 <개발자, 2025년을 맞이하며> 시리즈의 4화입니다.


왜 이직하는가?


여러분이 이직을 준비한다면, 우선 그 이유를 묻고 싶습니다. 만약 회사 규모나 내 책임과 권한, 처우 등 이직이 아니면 해결될 수 없는 문제에 직면했다면 옳은 선택을 한 겁니다.

하지만 내부적으로 해결될 수도 있는 문제들, 예를 들어 회사 기술 수준이 마음에 안 들어서, 매니저가 못살게 굴어서, 성장하는 느낌이 안 들어서 등의 이유로 이직하려고 하는 경우 대부분 이동한 회사에서 똑같은 일이 반복될 가능성이 높습니다.

충분히 해결하려 노력했지만 해소되지 않아 이직을 시도하는 것이라면 그것도 좋은 명분이 될 수 있습니다. 이 명분이 중요한 이유는 앞으로의 고된 이직 과정에서 동기부여가 되어줄 뿐만 아니라 현재 문제를 되돌아볼 수 있는 기회를 제공하기 때문입니다.

그럼에도 이직을 굳게 마음먹었다면 이제 준비를 해야 합니다. 우선 이직을 하려면 아래와 같은 사실은 잘 알고 있습니다.

  1. 어떤 회사에 들어갈지 추린다.
  2. 그 회사들에 이력서를 제출한다.
  3. 면접을 본다.

하지만 말이 쉽지 어떤 회사가 나와 잘 맞는지, 이력서는 왜 붙고 떨어졌는지 잘 알지 못합니다. 이 글을 쓰는 저도 수많은 시행착오를 겪었지만 아직도 모르는 것이 많습니다. 이번 글에서는 부족하지만 제 성공 경험을 통해 개발자 이직 준비하는 방법을 알아보겠습니다. 우선, 어떤 회사를 지원할지 고르는 방법을 알아볼 거예요.


회사 고르는 방법


회사 한번 잘못 들어가면 커리어가 힘들어지는 것처럼, 지원할 회사 한번 잘못 선택하면 시간과 에너지를 낭비하기 십상입니다. 저에게는 회사 선택에 세 가지 핵심 기준이 있습니다. 각 기준에는 우선순위가 없으며, 개인 상황과 선호도에 따라 중요도가 달라질 수 있습니다.

  1. 회사의 성장 단계
  2. 도메인 적합성
  3. 기술 전문성

실제 전형에 들어가 면접이나 회사와의 상호작용을 통해 기술 수준과 문화 적합성 등 더 많은 부분을 교차검증하고 입사를 결정하긴 하지만, 지원하는 단계에서는 위 세 가지만 판단하고 지원해도 충분하다고 생각합니다. 아래에서 더 자세히 알아보도록 하죠.


1) 회사의 성장 단계


회사를 고를 때 가장 먼저 고려해야 할 것은 회사 규모와 성장 단계입니다. 각 단계마다 장단점이 있기 때문에, 자신의 성향과 경력 목표에 맞는 단계를 선택하는 것이 중요합니다.

  1. 초기 스타트업(Zero to One) : 비즈니스 모델을 검증하는 단계입니다. 기여하게 될 제품은 아직 시장의 검증도 받지 못하거나, 받는 단계일 가능성이 높아요. 이 시기의 특징은 높은 자율성과 빠른 의사결정입니다. 새로운 기능을 만들고 실험해 볼 수 있는 기회가 많습니다. 기술 선택이나 일하는 방식도 자유롭습니다. 하지만 그만큼 책임도 크고, 사업의 불확실성도 높으며 미래 보상은 크더라도 당장은 적을 수 있습니다.
  2. 성장 단계 스타트업(One to Ten) : 검증된 비즈니스 모델을 확장하는 시기입니다. 이때는 조직이 빠르게 커지면서 개발 프로세스와 시스템이 체계화되기 시작합니다. 기술 부채를 해결하고 확장 가능한 아키텍처를 설계하는 등의 도전적인 과제가 많습니다. 기술과 조직 성장을 동시에 경험하고 싶은 개발자에게 좋은 환경입니다.
  3. 안정기 기업(Ten to Hundred) : 이미 시장에서 검증된 비즈니스를 운영하는 단계입니다. 체계적인 시스템과 프로세스, 안정적인 제품과 수많은 고객을 대상으로 대규모 트래픽을 다루거나, 복잡한 시스템을 운영하는 경험을 할 수 있습니다. 하지만 아무래도 의사결정이 느리고, 변화와 실험이 제한적일 수 있습니다. 권한도 적어 자유롭게 해 왔던 일들을 할 수 없을 수도 있습니다.

저는 앞선 3년의 경력 동안 초기 스타트업과 성장 단계 스타트업을 모두 경험했습니다. 그러고 이직 기회가 생겼을 땐 안정기 기업에서 일해보고 싶더라고요. 그래서 최대한 시장에서 검증된 비즈니스가 있는 기업 위주로 지원했습니다.

2) 도메인 적합성


내가 관심 있고 잘 아는 분야에서 일해본 적 있나요? 그렇다면 아마 이 섹션에 크게 공감할 것입니다. 특히 내가 자주 사용하는 서비스라고 한다면 베스트죠.

도메인 적합성은 사내 문화와 그 개념이 비슷해서, 잘 맞으면 120% 시너지가 나고 잘 맞지 않으면 80% 디버프가 발생합니다. 왜냐하면, IT 서비스에서 고객과 비즈니스에 공감하는 것은 정말 중요한 가치인데 도메인 적합성이 잘 맞으면 그 가치를 더 잘 이해하고 기여할 수 있기 때문입니다.

예를 들어, 반려동물을 좋아한다면 반려동물 커머스 회사에서 일할 때 고객과 제품을 더 잘 이해할 수 있습니다. 가령 여러분이 일하는 플랫폼에 반려동물 호텔을 입점시키는 프로젝트에 참여한다고 가정해 봅시다. 반려동물에 관심이 없거나 키우지 않는 사람이 해외여행 시 혼자 남게 될 반려동물을 누구에게 맡길지 고민하는 고객들에게 선명하게 공감할 수 있을까요? 반대로 지극히 공감한다면, 고객 입장에서 문제를 정의하고 해결해 나갈 수 있습니다. 그 과정에서 재미와 보람을 느낄 수 있죠.

저는 평소에 옷 사고 꾸미는 것을 좋아해 패션 커머스 도메인을 좋아하고 돈 관리, 투자, 재테크를 좋아해 금융 도메인 또한 관심이 많습니다. 운이 좋게도 현재는 제가 가장 많이 쓰는 패션 플랫폼 서비스를 만드는 회사에서 비즈니스와 제품과 고객에 기여하고 있습니다.

3) 기술 전문성


엔지니어로서 기술적인 부분도 무시할 수 없습니다. 아무리 원하는 수준의 회사라고 하더라도 개인의 성장 없는 반복적이고 무의미한 일을 하는 것은 좋지 않습니다.

저도 이런 부분들을 각종 루트와 기술 블로그를 통해 확인하고 갔습니다. 기본 기술 스택의 경우, 웬만하면 주력 기술을 사용하면서 너무 옛날 기술을 활용하지 않고 지속적으로 트렌드에 맞춰나가는 기업을 선호했습니다. 하지만 이 섹션에서 말씀드리고 싶은 기술은 더 근본적이고 전문적인 영역입니다.

예시를 통해 회사의 기술적 특성을 확인해 보겠습니다. 제가 프론트엔드 개발자이기 때문에 웹 프론트엔드 관점에서 예시를 들어보겠습니다.

  1. 커머스 플랫폼에서는 웹 성능을 중요하게 생각합니다. 이미지나 폰트 같이 무거운 리소스를 최적화하는 것이 중요합니다. 상세 페이지처럼 트래픽이 몰리지만 서버 사이드 렌더링(Server Side Rendering)을 통해 서빙해야 하는 페이지가 많습니다.
  2. 실시간 서비스(채팅, 주식 거래 등)를 다루는 회사에서는 웹소켓(WebSocket)을 활용한 실시간 데이터 처리와 상태 관리가 중요합니다. 수많은 실시간 이벤트를 효율적으로 처리하고 버벅거림 없이 화면에 반영하는 기술이 필요합니다.
  3. 3D나 WebGL을 다루는 회사에서는 Three.js나 WebGL에 대한 깊은 이해가 필요합니다. 3D 렌더링 최적화 등 일반적인 웹 개발과는 다른 전문성이 요구됩니다.

이처럼 각 회사마다 중점을 두는 기술 영역이 다릅니다. 따라서 단순히 "React를 쓴다." "TypeScript를 쓴다."가 아니라, 그 기술을 통해 근본적으로 어떤 기술적 문제를 해결하고 있는지 집중하는 겁니다. 그리고 그것이 내가 전문성을 쌓고 싶은 방향과 일치하는지 고민해 봐야 하고, 만약 내 전문성과 맞지 않아도 도전해 보고 싶다면 개인 프로젝트와 팀 프로젝트를 통해서라도 비슷한 경험을 쌓고 도전하면 됩니다.


이력서 쓰는 방법


다음으로는 실질적으로 전형을 준비해야 합니다. 면접과 과제 등 여러 단계가 있겠지만 오늘 다뤄볼 내용은 이력서입니다. 이력서에 있어서는 무엇보다도 완벽한 이력서란 없다라는 말을 먼저 해드리고 싶습니다.

멘토링을 하거나 이력서 첨삭을 하다 보면 지원자분이 지원할 때가 되었는데도 완벽한 이력서가 될 때까지 지원을 미루고 미루다 좋은 기회를 많이 놓치는 경우를 많이 봅니다. 적당히 준비가 되었다면 일단 지원해보고 시장의 평가를 받아보세요. 미루고 미루다 보면 더 간절한 사람에게 그 기회가 돌아갑니다. 이제 이력서 작성 방법을 알아보겠습니다.

1) 이력서는 경력의 단순나열이 아니다.


회사가 지원자의 이력서를 통해 궁금한 것이 참 많겠지만 무엇보다도 지원자라는 사람 자체가 궁금합니다. 어떤 생각을 가진 사람이고, 어디에서 무슨 일을 하며 어떤 성공 경험을 쌓아왔는지가 궁금하죠. 뻔한 말이지만, 지원자는 이력서로 자신을 효과적으로 소개해야 합니다.

그런 의미에서 이력서는 나를 소개하는 카탈로그라고 이해하시면 편합니다. 여느 카탈로그가 그러하듯, 중요한 내용을 문서 최상단에서 먼저 소개하고 이를 뒷받침하는 이력과 경험을 아래로 나열하는 방식으로 이력서를 작성합니다.

이력서의 최상단에는 내 소개를 작성합니다. 나는 어떤 사람이고, 어떤 방식으로 동료를 대하며 업무를 하는지 적습니다. 내가 가진 강점, 어필하고 싶은 내용을 적으면 됩니다. 아래 예시를 살펴보면 더욱 이해가 될 것입니다.

  • 사용자 경험과 개발자 경험을 통해 비즈니스 가치를 창출하는 프론트엔드 개발자 인호준입니다.
  • 개발자는 기술로도 문제를 해결할 수 있는 사람이라고 생각해요. 문제 해결에 앞서 요구사항이 고객이 겪는 문제를 정말 해결해줄 수 있는지, 진짜 문제는 무엇인지부터 생각해요.
  • 커뮤니케이션에 대한 중요성을 알고 가치관과 방법론에 대해 함께 고민해요.

그다음은 이를 뒷받침해 줄 수 있는 내 성공 경험을 나열하는 것입니다. 회사에서의 업무 경험, 외부 활동, 교육 기관에서의 경험 모두 좋습니다. 보통의 경우 업무 경험 -> 외부 활동(팀/개인 프로젝트, 커뮤니티 활동 등) -> 교육 기관 경험을 시간 순으로 나열합니다. 최근 경력과 같이 경력 증명에 필수적인 부분 누락시키면 안 되지만, 그렇지 않으면서 중요하지 않은 경험들은 과감히 제거하는 것이 좋습니다.

그렇다면 이력서에 올릴 경험은 어떻게 판단해야 할까요? 그것은 어떤 경험이 내가 소개한 내용을 뒷받침해 주는지를 기준으로 삼으세요.

가령 자신을 소개할 때 사용자 경험을 중시한다고 적었다고 가정해 봅시다. 그렇다면 아래에는 사용자 경험에 대해 고민하고 기여한 경험이 있어야 할 것입니다. 빠르게 실행하고 시장 반응을 받아 제품을 개선하는 업무 방식을 선호한다고 적었다면 그런 방식으로 업무를 해서 성과를 냈던 경험이 있어야겠죠. 업무 효율성과 개발자 경험을 중시한다고 적었다면 적어도 자동화를 통해 업무 생산성을 향상시킨 경험이 있어야 할 것입니다.
이력서 예시 ⓒ인호준


<이력서 쓸 때 참고하면 좋을 세 가지 팁>

  • 꼭 숫자로 녹여내지 않아도 되지만 숫자만 한 게 없습니다. (비즈니스, 생산성 혹은 성능 지표 등)
  • 같은 회사 경력에서는 중요도 순으로 적으세요. 꼭 시간순으로 적을 필요는 없습니다.
  • 구체적으로 적으면 이력서가 길어집니다. 핵심 위주로 간결하게 적고, 구체적인 내용은 따로 문서로 작성해서 첨부해 보세요.

명심해야 할 점은 성공 경험이 많다고 다 좋은 것도 아니고, 너무 적다고 부족한 게 아니라는 점입니다. 무엇보다 중요한 것은 나를 소개하는 내용을 지속적으로 뒷받침해 주고 있는지입니다.

2) GIGO(Garbage in, Garbage out)


컴퓨터 과학에서 ‘GIGO(Garbage in, Garbage out)’라는 유명한 격언이 있습니다. 이 약어는 입력된 데이터가 퀄리티가 낮으면 출력되는 결과도 퀄리티가 낮다는 것을 의미합니다.

이력서도 똑같습니다. 좋은 경험이 있어야 하고, 우리가 해야 할 일은 성공 경험들을 우선순위에 맞게 간결하고 핵심을 포함하도록 작성해서 나열할 뿐입니다. 아마 여기서 어떤 경험이 성공 경험인지 이해가 안 될 수도 있어요. 한번 예시를 나열해 볼까요?

  • 비즈니스 측면에 큰 기여를 한 경험
  • 실패 경험을 성공 경험으로 전화위복 한 사례
  • 기술적으로 어려운 문제를 풀었던 경험
  • 협업이나 커뮤니케이션으로 문제를 해결했던 경험
  • 업무 시스템을 개선하거나 만들었던 경험
  • ...

성공 경험은 조직에 기여하며 스스로 성장했던 모든 경험을 총칭입니다. 만약 이직을 준비하고 있는 단계에서 스스로 느끼기에 성공 경험이 없다고 생각한다면 먼저 현재 있는 조직에서 이런 경험을 쌓아보세요. 현재 단계에서 무엇을 어떻게 기여하면 될지 조차 모르겠다면, 주변 사람들 혹은 커뮤니티 등을 활용해 도움을 구해 보세요.


글을 마치며


개발자 채용의 절대량이 줄고 문턱이 더욱 좁아지고 있습니다. 예전엔 붙었던 이력서가 이번엔 떨어지고, 요구하는 역량의 너비와 깊이가 확대되고 있어요.

하지만 길이 없는 건 절대 아닙니다. 저도 이번 이직에 100번 넘게 지원하면서 수많은 시행착오를 겪었습니다. 그 과정이 힘들고 희미할지언정 묵묵히 우리가 바꿀 수 있는 것들을 차례로 바꿔나가며 조금씩 나아가는 방법뿐입니다.

이번 글에서 나눈 제 경험과 지식이 여러분의 이직 준비에 도움이 되었길 간절히 바랍니다.



글 인호준 무신사 프론트엔드 개발자

💻 dev-blog : hojunin.com
🐱 github : https://github.com/hojunin
📝 brunch : https://brunch.co.kr/@dlsghwns



발행일 25.02.21
이벤트 모두 보기