개발자 취업난에 대처하는 방법

<code class="language-plaintext" style="border-radius:0px;border:0px solid var(--chakra-colors-gray-200);box-sizing:border-box;color:rgb(80, 88, 96);font-family:SFMono-Regular, Consolas, "Liberation Mono", Menlo, Courier, monospace;font-size:16px;font-weight:400;hyphens:none;line-height:1.5;overflow-wrap:break-word;padding:0px;tab-size:4;text-align:left;text-shadow:rgb(255, 255, 255) 0px 1px;white-space:pre;word-break:normal;word-spacing:normal;">📌 글 작성

성장에 관심이 많은 F-Lab 백앤드 멘토 Elkein
스타트업 여럿과 NHN, 넷마블, 크래프톤 등을 거쳤으며
게임 산업, 클라우드 플랫폼 개발, 웹 개발 등을 두루 경험한 19년 차 엔지니어

개발자 붐이 일었던 몇년이 지나가고, 굳이 개발자만이 아니라 모든 채용과 투자가 얼어붙었다. 이에 대한 영향으로 많은 개발자가 구직 난을 겪고 있다. 이러한 시기를 처음 겪는 많은 주니어 개발자나 취업 준비생 분들이 막막함과 스트레스를 받는 상황은 충분히 이해되고 공감된다. 이러한 부분에 대한 이야기를 해보고자 한다.

높아진 기대치

나는 멘토링을 하고 있다보니, 주니어 개발자 분들과 매주 만난다. 그리고 그 분들이 면접을 보고 오면 자연스레 면접 경험에 대한 이야기를 나누게 된다.

 개발자에 대한 처우가 좋아진 것에 대한 반작용이 이제서 더 크게 오는 느낌인 것이, 개발자 호황기에는 조금 아쉬운 부분이 있어도 다른 기업에서 채갈까 걱정으로 채용하거나, 조금 더 여유롭게 개발자 풀을 확보해놓은 경우도 왕왕 있었다면, 지금은 다양한 관점에서 고려한 뒤 채용을 하는 트렌드로 넘어오고 있다.

 호황기를 경험했으면 경험한대로 막막하고, 호황기를 겪지 못했다면 개발자라는 길의 시작이 힘든 직업이라는 좌절감을 맛보기도 하는 듯 하다. 실제로 나의 취준 시점인 2000년대 초반과는 너무 먼 얘기라지만, 1년전에 비해서만 비교해도 급격히 올라간 허들은 부담이 되는 포인트인 것은 충분히 공감된다.

왜 이렇게 됐을까?

이러한 상황에서 시니어나 미드 레벨 엔지니어를 충분히 충원하기 어려우니, 장기적 안목에서 육성 하겠다는 기조로 대규모 채용이 많았다. 그렇다보니 스타트업이나 중소 규모의 업체에서는 조금 기대치보다 낮은 면접 결과의 개발자도 채용했어야 됐다.

 하지만 투자와 자금 흐름이 마르면서 신규 채용이 줄어들면서 상황이 바뀌고, 대규모 채용의 규모가 줄어들거나 진행하지 않는 경우가 많아졌다. 그렇다보니 채용 전반적으로 이전보다 이력서도 훨씬 많이 들어오고, 회사 입장에선 이전보다 허들을 높일 수 있는 상황에 된 것이라고 볼 수 있다.

어떻게 대처해야 될까?

1) 코딩 테스트

지원자 수와 채용 인원 자체가 비대해졌던 경험이 없던 회사들 입장에서, 채용에 대한 허들로 코딩 테스트를 두기 시작했다. 그 허들을 높이고 높일 수록 좋은 역량의 지원자를 선별 할 수 있다는 기대를 했지만, 그렇게 작용하지 않은 케이스가 많았다. 물론 코딩 테스트의 순작용도 분명히 있기 때문에, 아예 없애기 보다는 난도를 조금 낮추고 최소한의 허들로써 두는 선택을 하는 경우가 늘고 있다.

2) 화이트 보드 인터뷰

모든 회사가 그런 것은 아니지만, 많은 회사가 화이트보드 인터뷰의 비중을 높이고 있고, 화이트 보드 인터뷰는 회사 입장에서도 큰 코스트가 든다. 그렇기에 앞서 언급한 코딩 테스트를 가장 앞에 두고, 이후에 서류 검토를 하게 되는데 서류가 많은 사람들의 생각보다 더 중요도가 올라가고 있다.

3) 이력서, 자기 소개서 그리고 포트폴리오

화이트 보드 인터뷰를 보는 면접관의 코스트는 매우 크다. 그래서 한 명의 면접관이 다른 업무를 진행하지 않아도 정말 많아야 면접 4건이 최대라고 볼 수 있다. (물론 예외는 있겠지만...) 실제 화이트 보드 인터뷰는 심도 있게 검증하려면 1시간에 딱 맞춰 끝내기가 적절치 않은 프로세스기도 하고, 이를 통해 하고 싶은 검증을 잘 해내려면 1시간이라는 시간적 기준을 최우선으로 둬선 안되기도 하다.

 그래서 서류가 아주 아주 중요해지는데, 많은 주니어는 구직 경험 자체가 부족하기 때문에 이력서, 자기 소개서, 포트폴리오를 잘 작성하지 못한다. 이에 대한 팁 몇개만 간략하게 언급해보고자 한다.

서류 작성 팁

1. ‘3줄 자기 소개’ 는 좋지만, 근거까지 거론하자.
   • 예를들어 ‘리더쉽 있는 개발자 입니다.’ 라고 했다면, 부연 설명이나 사례가 필요하다.
   • 이러한 예시가 길어진다면 별도의 글에 대한 링크로 연결해도 좋지만, 출력물 기반으로 서류를 보는 회사도 많은 점도 고려해서 적정 분량 요약을 한 뒤, 자세히 보기 같은 링크로 연결하는 것을 권장한다.
      
2. 한 페이지 반 이내에 어필 포인트를 녹이자
   • 면접관은 엄청 나게 많은 이력서를 검토한다.
     • 이 과정에서 모든 이력서 페이지를 꼼꼼하게 보는 것은 불가능하다.
   • 한 페이지 반 이내에 최대한 나의 장점과 강점을 녹여내는 것을 목표로 하자.
     • 한 페이지 반 내에 매력을 느껴야 나머지 페이지들도 자세히 검토해줄 것이다.
       • 노파심에 언급하자면, 절대 한 페이지 반의 퀄리티만 신경 쓰라는 의미가 아니다.
          
3. 읽는 관점을 고려하자
   • 이력서는 면접관이 읽는 문서다.
   • 면접관이 읽게 좋게 끔 들여쓰기나, Heading Level 조정, 또는 색상 처리, Bold 처리나 Numbering 등의 다양한 방법을 통해서 읽기 좋게 내용을 배치해라.
   • 기본적인 접근은 카테고리로 묶는 것이다.
     • 내용이 짧다면 상관 없지만, 조금만 길어지더라도 읽기 부담스러워지는데, 생각보다 많은 이력서는 순서 없이 나열 되어있는 경우가 많아 피로도가 느껴지고, 이는 퀄리티가 떨어지는 이력서로 인식되기 쉽다.
   • 비슷한 맥락 별로 묶어주고, Heading Level 만 잘 지정해도 이전보다 읽기 좋은 문서가 될 것이다.
      
4. 자신의 기술 경험, 역량 위주로 이력서에 녹여내라
   • 대부분의 기술 면접관은 포트폴리오로 낸 제품보다 이 사람이 어떠한 개발자로써의 역량을 보유 했는지에 대해 훨씬 관심이 많다.
   • 그럼에도 제품에 대한 어필이나, 부연 설명을 하고 싶다면 별도의 문서를 제출해라.
      
5. ‘자기 소개서’는 대부분 의미 없다.
   • 특정 회사에 특화 된 입력 폼이나 지원 시스템이 있는 회사의 경우에도 대부분의 내용은 해당 회사에 대한 지원 동기, 본인의 장단점, 어필 포인트 등에 대한 이야기다.
     • 이러한 이야기는 이력서 말미에 충분히 녹여낼 수 있고, 별도로 요청 받지 않는다면 작성하지 않아도 무방하다.
   • 다만 별도의 기입할 공간이나 전달할 메시지가 없다고 하더라도, 어떤 회사를 특별히 지원한 동기에 대해서는 꼭 언급했으면 좋겠다.
   • 회사 입장에서의 불안감은 훌륭한 지원자를 위해 전형을 진행하며 TO를 잡아두었는데, 결과론 적으로 입사 취소를 할 것에 대한 우려다.
     • 지원자가 진정성 있는 지원을 한 것인지에 대한 불안감을 줄여준다면 조금 더 확률을 높일 수 있다.

지원자 관점에서의 고민

자 그렇다면 시간을 어떻게 쓰는 것이 합격 확률을 높이는 노력일까?

정답은 없지만, 몇가지 제안을 해고보자 한다.

학습 비중

1. 코딩 테스트 비중은 10~15% 내외를 권장
   • 이유는 위에서 언급한대로, 채용 과정의 최초 허들의 역할을 할 뿐, 채용 전형의 핵심은 아니기 때문인데, 그럼에도 최초 허들을 넘어야 나머지 것들을 보여줄 수 있기 때문에 준비해두는 것이 좋다고 생각한다.
      
2. CS 기초에 대한 학습은 10~30% 사이를 권장
   • 중요한 것은 실습이다.
   • 가볍게라도 혹은 다른 사람이 작성한 오픈 소스라도 실습을 해봐야 이해도가 크게 오르는 효과를 거둘 수 있다.
      
3. 프로젝트 (포트폴리오)
   • 냉정히 말해서 중요도가 크지 않지만, 중요하기도 하다
   • 권장 비중은 10~50%다.
     • 왜 이렇게 편차가 크냐하면, 프로젝트를 어떤 용도로 쓸 것인지가 중요하기 때문이다.
     • 다양한 모의 경험을 위한 용도로 쓰고, 이를 통해 개인의 역량 발전에 활용하는 것을 권장한다.
       • 모의 경험이라 함은 성능 테스트, 정합성 검증 등이 있을 수 있다.
          
4. 책 읽기, 동영상 강의
   • 권장 비중은 20~30%다.
   • 생각보다 비중이 높은 이유는, 기본적으로 나는 어떠한 일에 퀄리티를 높이기 위해서는 시간을 붓는 것보다, 생각과 판단이 시너지를 내기 시작해야 큰 성장으로 이어진다고 생각한다.
     • 시너지를 내려면 많은 지식과 경험이 동반되어야 하는데, 모든 경험을 실습만으로 할 순 없으니 책이나 동영상 강의를 통해서 다양한 부분을 빠르게 습득하고 체험해보는 경험과, 책을 통해서 지식을 습득하는 경험이 일정 비율 균형적으로 가져가는게 좋다고 생각하기 때문이다.
        
5. ‘RSS’, ‘News Letter’, ‘커뮤니티’ 글 읽기
   • 권장 비중 10% 이내
   • 권장 비중이 낮은 이유는 대 부분 꽤 거리가 먼 주제를 많이 마주하게 될 수도 있어서 그렇다
   • 얕고 넓게 아는 부분이 있어야, 어떠한 기술의 원리나 핵심을 파악할 때 저항감이 낮아지는데, 그러기 위한 코스트로 10% 이내면 충분하기 때문이기도 하다.

찐 개발자

사실 내가 취준생이던 20년 전에도, 10년전에도, 지금도 많은 채용 담당자들은 본능적으로 찐 개발자를 뽑고 싶어한다. 여러가지 리스크가 있고, 결어된 부분이 느껴지는 지원자라 할지라도 찐 개발자스러움이 있다면 뽑고 싶은 마음이 요동 친다. 자 그렇다면 찐 개발자의 정의는 무엇일까?

찐 개발자의 정의

• 자신만의 프로젝트가 있음
  • 이 프로젝트는 누가 시켜서도, 취업을 위해서가 아닌 진짜 개발이 즐겁고 자발적으로 만들면서 성장을 체감하는 토이 프로젝트
  • 자신의 일상에 개선 포인트에 대한 것도 좋고, 주로 자신이 필요한 앱인데 기존 앱 중에서 존재하지 않아서 만드는 경우도 좋다.
• Github도 재미난 주제 흥미있는 주제를 체감하며 성장하고 있음이 느껴짐
  • 이 역시 취업 위주의 알고리즘 스터디 자료나, 각종 템플릿을 포킹해서 따라하기 위주면 좋은 점수를 주기 어렵다.
• 지적 호기심과 논리력이 느껴지는 다양한 블로그 글

아이러니하게도, 우리 모두 좋은 회사에 취업하는 것이 중요하지만, 찐 개발자로 느껴지려면 취업이 1순위가 아니게 느껴질 때 더 매력적인 지원자로 느껴진다는 것이다. 그리고 찐 개발자가 되기 위한 노력은 잔디 심기를 늘리는 것보다, Today I Learn을 매일 작성하는 것보다 훨씬 어렵지만, 그만큼 가치 있다. 그리고 이번 글에서 주로 언급한 주제인 좁아진 채용 관문을 뚫는 데에 더 큰 무기로 작용할 수 있다는 점도 염두에 두면 좋겠다.

마치며

여러가지 상황이 맞물려 이렇게 허들이 높아진 이상, 이 상황에 맞는 최선을 대비하는 것이 좋다. 이미 많은 개발자 지망생은 몇개월 혹은 몇년의 시간을 들여왔을 것이고, 그 노력이 헛되지 않게 하기 위해 열심히 노력하고 있는 것을 잘 안다. 다만 그러한 노력이 희석 되지 않기 위해서 위에서 언급한 포인트 들을 참고해 좀 더 좋은 결과로 맺었으면 하는 바램이다.