개발자로 살면서 겪은 것들에 대한 이야기

아직 저는 현업 개발자 일을 한지 오래 되었다고 말할 수는 없을 것 같습니다. 그래도, 나름 이런저런 사람들을 만나고 개발을 하고 회사일을 하면서 겪었던 경험들을 누군가 (혹은 저보다 주니어 친구들) 에게 도움이 될 수 있지 않을까 하는 마음에서 정리하게 되었습니다.

1. 콜드메일

콜드메일의 정의는 위키피디아에 따르면 “콜드 이메일은 원치 않는 이메일로 사전 연락없이 수신자에게 발송됩니다.” 즉 모르는 사람에게 보내는 메일입니다. 여기서는 포지션 제안에 대한 콜드메일에 대해서 이야기 하겠습니다. 요즘은 그런 의미로 많이 쓰이기도 하고요.

콜드메일은 좋은 신호

콜드메일은 정말 무작위로 막 뿌리기는 곤란한 성격이 있습니다. 회사 이름을 걸고 뿌리는 일종의 제안서이기도 하고, 또 아무나 뿌렸다가 스팸취급 당해도 곤란하기 때문입니다. 일례로 모 사이트에서는 쪽지의 회신률이 특정 수치 이하로 떨어지면 사용에 제한일 걸리는 경우도 있습니다. 그래서 단순 스팸과는 다르게 최소한의 성의를 보이려고 하는 경우가 많습니다 (e.g. 상대방의 이름을 언급한다거나, 세부 경력사항을 언급하며 권유한다거나…)

이런 식으로 말이죠.

따라서 콜드메일을 받는 사람은 어느 정도 자격이 되는 사람들이라고 볼 수 있습니다. 서류는 높은 확률로 패스할 거고, 면접 준비만 잘하면 모셔간다고 봅니다.

그렇다고 콜드메일이 합격 보증서 같은 의미는 아닙니다! 콜드메일이라도 자격 검증을 위한 면접과 같은 절차를 모두 거쳐서 협상을 거쳐 오퍼를 받아내는 과정을 모두 거쳐야 합니다. 다만 시작이 수월할 가능성은 있죠.

자신의 경력사항을 항상 준비해두어야 함

리쿠르터들이 콜드메일을 보내는 기준은 보통 업무를 수행할만한 스펙을 갖추고 있는지 입니다. 이를 확인하기 위해서 아래 정도 정보를 보는데…

• 학벌 (안본다고는 한다지만 현실은 언제나…)
• 경력
• 직종의 관련성 (전공, 기술스펙, 사용언어 등)
• 관심분야 확인: Github 포트폴리오, 블로그 포스트, 컨퍼런스 등

그래서 이런 정보를 항상 들고 있어야 리쿠르터들이 찾아갈 수 있습니다. 즉 온라인 자소서를 쓰고, 리크루팅 사이트에 올려 두고, 꾸준히 갱신해 두어야 합니다. 약간 자기 자신을 판다는 느낌으로 접근해야 할 듯.

2. 이직

왜 다짜고짜 이직임?

왜 다짜고짜 이직이냐면… 이직을 할 수 있는 정도의 사람이 경쟁력이 있는 것은 당연하잖아요?

경쟁력이 있는 사람이 더 높은 몸값을 받는 것도 당연합니다. 그리고 개발자로서 더 높은

게다가 다행히도, 개발자 시장에서 높은 가치를 가진 사람은 언제나 부족해 왔습니다. 기회가 있다는 것을 알고 기회를 잡을 의향이 있다면, 자신의 실력과 몸값을 높일 수 있는 기회는 언제든지 있다는 뜻입니다. 그리고 그 중 가장 좋은 건 이직이라고 생각합니다.

단순 몸값을 떠나서, 훌륭한 사람들과 일할 수 있다는 것 또한 큰 이점입니다. 맨먼스 미신에서도 말했듯 개발쪽 일은 단순 사람을 많이 뽑는다고 해결되는 것이 아니고, 오히려 좋지 않은 사람이 오면 생산성이 저해될 수 있기 때문에 최대한 좋은 사람들만 모셔가려고 하고, 자연스럽게 비슷한 사람들이 모이게 됩니다. 따라서 좋은 곳으로의 이직은 인맥과 실력을 향상시키는 기회가 된다고 생각합니다.

가고 싶은 회사가 있나요?

가고싶은 회사가 있다면, 이직동기는 완벽합니다! 그 회사에 알맞는 스펙만 갖추면 됩니다. 그 스펙은 보통 JD(Job Description)에 적혀 있습니다. JD중에서 모르는 것들이 바로 공부할 내용들입니다.

신입이 고연차에 비해 이직하기 자유롭다

고연차 중에서도 특히 한 회사에서 굉장히 오랫동안 일해온 사람들의 경우가 이직에 어려움을 겪는 경우가 많습니다. 사실상 기술에 특화된게 아니라 “회사에 특화"된 모습이기 때문에, 시장에서 요구하는 기술들에 대해서 연차만큼의 기대치를 충족하기 어렵기 때문입니다. 정확히는, 이직할 수 있는 직종의 폭이 좁아집니다.

반면 신입(주니어 레벨: 2~3년 미만?)의 경우 기대치 자체가 그렇게 높지 않기도 해서 기본기가 충분하면 오히려 이직하기 쉬운 편입니다. 이 점을 잘 살려서 보다 분야의 제약을 덜 받고 이직할 수 있습니다.

이직할 때 고려해야 할 것들

저 스스로도 한 고민도 있었고, 개발자 커뮤들을 보다보면 관련 질문글들을 종종 볼 수 있습니다.

• 통근시간이 2시간이 되는데 이직해야 할까요?
• 2군데 붙었는데 스타트업이 대기업보다 20% 더 주는데 어느쪽이 맞을까요?
• 포괄임금제라는데 이거 괜찮은 건가요?
• 지분을 감안해서 연봉을 이만큼 주는데 이게 맞나요?
• 경력대비 직급이 맞는 건가요?

사실 정답은 없다고 생각하지만, 조심스럽게 제 개인적인 의견을 붙여보면…

• 연봉은 확실하게 오르는 쪽이 맞습니다.
  • 안 오르면 안 가는게 낫기도 하고, 연봉만큼 뛰어난 사람이 오는 경우가 많은 것도 현실이기 때문에…
  • 개인적으로 향상폭이 20~30% 이상이면 큰 문제사항이 없다면 이직을 고려해 볼 만 하다고 생각합니다. (물론 현재 받고 있는 페이가 이미 많다면 절대적인 수치로 고려해야 할 수도 있습니다)
  • (물론 워라벨도 분명히 고려되어야 하는 사항입니다. 돈 때문에 인생이 잠식된다면 그건 안될 일)
• 통근시간은 삶의 질과 자기개발에 아주 큰 영향을 끼치기 때문에 아주 중요한 기준이라고 생각합니다. 개인적으로는 한시간이 리미트라고 생각하고, 거주지를 옮기거나 할 수 없다면 비추입니다.
• 대기업이면 기존 스톡 및 혜택까지 고려해서 계산해야 함
  • 단순히 연봉만으로 비교하기에는 꽤 혜택이 많은 점을 절대 간과할 수 없습니다
• 포괄이든 비포괄이든 결국 TC를 맞춰주는 방향으로 가게 해 주고 협상과정에서 그 점에 대해 분명 이야기 해줍니다. 정리하면, 개인적으로 포괄 비포괄은 그렇게 중요한 요소는 아니었습니다.
• (외국계 기준) 경력대비 직급 및 페이는 여기를 참조하세요. 다만 한국내에서 일하는 경우 미국 본토보다는 훨씬 페이가 낮다는 건 아셔야 합니다. (애당초 생활비 자체가 적어서 실제 남는 거 생각하면 그렇게 나쁘지는 않음)
• 스타트업의 경우 투자처나 자금 흐름 등을 확실하게 알아두고 조인하시는 걸 추천드립니다. 조인하기 전에 기업 가치나 순이익 상황, 남은 투자자금 등을 물어볼 권리가 충분히 있습니다. (오자마자 다른 곳으로 가야 한다면 골치 아프잖아요?)
• 외국계의 경우 Glassdoor 과 같은 사이트에서 해당 정보를 확인할 수 있습니다.

추가 220805) 스톡옵션 등에 대해서는 이직할 때 확실하게 이야기하여 상응하는 보상을 받도록 고려해 볼 수 있습니다. 그리고 월급과 스톡옵션을 상호교환하는 경우에는 현재 행사가를 기준으로 어느정도 마진을 남겨두고 스톡옵션을 받는 옵션도 생각해 볼 수 있습니다. (TC에 확실하게 보장될만한 요소가 없으면 스톡옵션만 주겠다고 하는 건 고민을...) 이외 관련한 사항도 나중에 별도 글로 정리해보려고 합니다.

이직을 두려워 할 필요가 없다

이직을 해야겠다! 라고 마음먹어야만 시작할 필요가 없습니다. 이직 하더라도 인터뷰를 보게 해준다는 보장도, 하더라도 붙여준다는 보장도 없고, 설령 최합이 되었더라도 협상 후 계약서에 사인하기 전까지는 이직한 게 아닙니다.

그리고 의외로 정말로 뽑고 싶은 인재라면 회사에서는 어떻게 해서든지 그 사람을 데려오려고 합니다. 입사일이 늦어지거나 요구 페이가 높더라도 어떻게든 맞춰주려고 하게 될 겁니다. 그러니 다른 걱정 할 필요 없이, 이직을 염두에 두고 있다면 일단 해 보면서 경험을 쌓고, 부족했던 점을 채워보는 것이 좋다고 생각합니다.

이렇게 미리미리 이직 경험을 쌓아두면 정말 가고싶은 곳에 이직 시도 할 때 쌓아두었던 그동안의 경험이 큰 도움이 될 것입니다.

언제든 이직할 수 있게 준비되어 있기

자신이 이직을 준비할 수 없는 상황이 아니라면 (혹은 차후 이직을 염두에 두고 있다면), 항상 이직을 준비하는 것이 좋습니다. 가고 싶은 포지션의 JD를 확인하고, 그중에서 모르는 것들은 공부해둡시다.

대충 저런 것들… 조금만 구직정보 훑어봐도 모르는 스킬들이 산더미처럼 나옵니다. 근데 LXD는 또 뭐지… 나도 공부해야하는디…

그리고 평상시에 알고리즘 문제도 풀어두면 좋고… (시간 못 내더라도 코딩인터뷰 문제은행 같은것들 자연스럽게 접하는 것들 몇개 봐주는 정도면 좋은 듯 합니다 ㅎㅎ)

그리고 링크드인 같은 사이트에 이력서 꾸준히 올려두는 것도 잊지 마시고요. 리쿠르터가 자연스럽게 기회를 주러 올 겁니다.

그리고 혹시 이직 기회가 잡히게 되었다면, 비단 JD 요구사항 공부 해두는 것을 넘어, 코딩 인터뷰와 시스템 아키텍쳐 인터뷰 연습을 꼭! 해두세요. 설명하면서 푸는 연습을 할 수 있도록 해 두세요. 최근 면접은 소통능력을 중요시하게 보는 추세라고 생각합니다 🙂

• 보다 구체적인 코딩인터뷰 관련 강의나 팁들을 한번쯤은 읽어두시는 것을 추천드립니다.

외국계도 좋은 기회가 될지도

외국에서도 훌륭한 개발자의 수요가 부족한 것은 마찬가지라서, 미국에 소재지가 있는 회사들이 비교적 몸값이 저렴한 인도 혹은 아시아(싱가포르, 한국 등)에서 사람을 모집하는 경우가 점점 늘고 있습니다. 한국에서는 이른바 “유니콘 기업(몰두샌)”으로 잘 알려져 있습니다.

해당 회사들은 보통 영어 능력을 기본 요구하는데, 보통 유창할 필요까지는 없습니다. 같이 동료로서 개발할 수 있는 수준이면 됩니다. 그러니까, 영어로 된 Documentation 읽고, 영어로 된 코드 읽고, 영어로 된 PR 날릴 수 있을 정도면 보통 되는 것 같더라고요. 다들 StackOverflow 보면서 이 정도는 하잖아요? 자신감을 가집시다!

저 또한 영어를 잘 못합니다 ㅎㅎ;; 미팅가면 여전히 20%는 Loss 인 것 같아요 🥲 그럼에도 불구하고 업무상 지장은 거의 없고, 오히려 영어를 접할 기회가 많아져서 저한테는 굉장히 좋은 시간이라는 생각이 듭니다.

💡 혹시 외국계 회사의 [개발자 포지션] / [QA]에 관심이 있으시다면 저희 회사는 어떠신가요?

3. 정보에 민감해지기

SWE만큼 계속해서 공부하면서 살아가야 하는 직업이 많지 않을 것 같습니다. (이건 백엔드도 요즘 추세를 보았을 때 얄짤 없어 보입니다). 그런 점에 있어서, 어떤 것들을 공부해야 할 지 알기 위해 이 바닥의 정보에 민감해질 필요가 있습니다. 그렇다면 어디에서 좋은 정보들을 얻을 수 있을까요? 제 생각은 아래와 같습니다.

구직시장의 JD 꾸준히 살펴보기

위에서도 언급했듯이, JD를 통해 이직에 필요한 기술들을 역으로 찾아낼 수 있다고 말씀드렸습니다.

또한 이렇게 지속적으로 일자리 시장을 확인하는 것이 현재 회사에 기여하는 방법이 되기도 합니다. 시장에서 요구되는 기술 스펙들은 보통 최신의 기술들이 많은데, 이들 중 효율적인 기술들을 현재 회사의 Tech Spec에 적용하면 분명 모두가 좋아할 것이고, 본인 스스로의 이력서에 한줄 더 담을 내용이 될 것입니다.

• 실제로 legacy에 지친 사람들이 퇴사하는 경우도 많기 때문에, 매니징 트랙이라면 이 점에 대해서도 신경을 분명 써야 한다고 생각합니다.

개발자 커뮤니티 주시하기

커뮤니티의 종류는 다양합니다. 페이스북 개발자 커뮤니티도 있고 블라인드 IT 서비스 게시판도 있고… 어디든 마음에 맞는 곳을 하나 집어서 종종 보면 재미있는 글들을 보게 됩니다. 면접관에 대한 험담, 재미있는 인터뷰 후기, 프레임워크에 대한 이야기, 이직에 대한 고민 등…

커뮤니티의 특성상 최근 트랜드에 관련한 이야기가 자연스럽게 많이 올라오게 되고, 분명 몰랐던 정보나, 우리 회사와 다른 다른 회사의 특징을 알게 되기도 합니다. 그 중 좋은 정보가 있으면 자연스럽게 들고와서 회사에 적용해 볼 수도 있고, 혹은 몰랐던 분야에 대해서 공부해 볼 수 있는 기회가 되기도 합니다.

혹은 GeeksforGeeks와 같이 개발자간 정보를 공유할 목적으로 만들어진 커뮤니티에서 쓰인 글을 읽는것도 큰 도움이 되었습니다.

또 근래에는 개발자 로드맵과 같이 공부해야 할 내용을 체계적으로 정리해주는 사이트도 나와서 읽으면 큰 도움이 됩니다. 정보는 많으니 열심히 찾아 다닙시다!

책 읽기

책을 읽는것도 정보를 얻는데 있어 큰 도움이 됩니다. 커뮤니티에 비해 체계적이고 전문적인 내용을 다루고 있어서 처음부터 내용을 익혀야 하는 경우나, 보다 검증된 정보를 얻어야 할 필요가 있을 때 도움이 됩니다.

읽어보면 좋은 책도 크게 기술서적과 매니징 관련 서적 투트랙으로 나눌 수 있을 것 같습니다. 기술서적은 언어나 아키텍쳐 설계상에 대한 정보를 얻을 때 큰 도움이 되고, 매니징 서적은 실제 기업에서 어떤 식으로 인력이나 이슈들을 관리하는지에 대한 내용으로 “멘먼스 머신”이나 “구글 엔지니어는 이렇게 일한다"와 같은 책들이 큰 도움이 되었습니다.

• 근데 요즘 최신 기술 및 아키텍쳐들은 책으로 정보가 얻기가 많이 어려워지고 있습니다. 공식 도큐먼테이션이 아주 잘 되어 있기도 하고, 제대로 된 서적이 나오는 속도보다 유저 커뮤니티/공식 문서가 더 훌륭한 경우가 꽤 있어서요. 어느정도 된 기술이 (C/C++, Java같은) 아니고서는 예전만큼의 위상은 아닌 듯.

개인적으로는 1티어 기업들로 이직하지 못하더라도, 그들이 가진 생각과 매니징 방식을 어깨 너머에서 배우는 것과 같은 효과를 줄 수 있는게 바로 책이라고 생각합니다. 그런 수단으로서 책은 여전히 도움되는 유효한 수단으로 생각합니다.

---

위 내용들은 저 스스로도 아직 배우고 공부하고 있는 입장이라 틀린 정보가 있을 것이고, 이 분야가 빠르게 바뀌는 분야인 만큼 이 문서는 언제든지 outdated 될 수 있다고 생각합니다. 혹시 보신다면 감안하고 읽어주시면 좋겠습니다.