데이터 엔지니어 경력 5년 이직준비 후기

자소서 : http://qkqhxla1.tistory.com/797
면접 후기 : http://qkqhxla1.tistory.com/799
내가 한 공부들과 방법 : http://qkqhxla1.tistory.com/802
취업을 위한 알고리즘 공부법 : http://qkqhxla1.tistory.com/990

데이터 엔지니어 경력 5년 이직준비 후기 : https://qkqhxla1.tistory.com/1193

 

오랫만에 글을 쓴다. 최근 두달동안 글이 없었는데 모든걸 이직준비에 올인하느라 글이 없었다. 제목에 적었듯이 나는 데이터 엔지니어 직군인데, 데이터만 다루는 직군은 예전부터 있었지만 데이터 엔지니어라는 명칭으로 it회사들의 채용공고에 박힐정도로 정립된지는 3~4년 정도 된것 같다.(대략 19년도즈음부터 정립이 되지않았나 싶음)

내 가정인데, 알파고vs이세돌이 16년에 대결했었는데 그 여파로 머신러닝 분야가 확 뜨면서 머신러닝 엔지니어 채용이 늘어났고.. 머신러닝 엔지니어를 채용해서 뭔가를 만들다보니 데이터를 앞에서 예쁘게 말아주는(지금의 mlops같은) 직군이 필요해지면서 데이터 엔지니어라는 직군의 수요가 확 늘어나면서 그즈음 정립이 된게 아닌가 싶다.(사실 해외에는 그 이전부터 있었다)

그래서 현재 내 경력이면(5년 4개월) 데이터 엔지니어링을 신입부터 시작한 1세대 개발자라고 볼수 있을것같다.(2017년에 처음 회사에 들어왔을때는 데이터 엔지니어라는 직군이 공고에 없었던거로 기억한다. 지금 나와 일하는 비슷한 연차의 다른회사출신 동료들에게 물어봤는데, 그분들도 처음에는 소프트웨어 엔지니어로 들어왔다고 하셨다.) 

그래서 정보가 많이 없어서 이력서나 면접을 준비하기가 참 힘들었다. 다른 글들을 보면 알수있듯이 나는 5년전(2017년)에 쿠팡 신입공채로 입사했는데, 내가 아는 동기 인맥 대부분이 스프링 백엔드 엔지니어이다. 동기 인맥을 언급한 이유는 이직한 동기들이 상당히 있는데, 면접 도움을 받으면 이직준비하기가 훨씬 수월하기 때문이다. 동기들이 전해준 백엔드 면접경험에서는 전반적인 개발자 면접의 방향성에 대해서 도움을 받았지만 다른 직군이다보니 구체적인 방향성은 면접에서 여러번 털린후 감을 잡을수 있었다.

데이터 엔지니어 경력 5년을 적은 이유는 이 연차가 주니어도 시니어도 아니면서 이직을 많이 생각하는 연차중 하나이기 때문에 적당히 참고하면 좋기 때문이다.

이력서 작성부터 합격까지, 실패와 성공했던 모든 필요했던 사소한 과정, 깨달은점등을 처음 이직준비하는 데이터 엔지니어들이 도움이 될수 있도록 적을 예정이다.

 

0. 커리어 관리

시작부터 커리어 관리라고 하면 당연하지만 뜬구름 잡는 말이긴 한데 기본적으로 이직을 위해 커리어 관리가 필요하기 때문에 전제조건으로 써놨다. 내가 아무리 이력서를 잘 써도, 경력이직시에 필요로 하는 기술 경험이 없으면 힘들다.(가능은 하다.) 그래서 현재 이직생각이 있던 없던 항상 커리어 관리는 하는게 좋다. 여기서 적은 커리어 관리라는 말은 꼭 좋은 회사에 입사하라는게 아니라 내 직군에서 많이 사용하는 기술들을 서칭하고, 이력서에 쓸수 있도록 사용해보자는 말이다. 예로 백엔드 개발자는 요즘 대부분이 자바 스프링을 기반으로 개발하므로 자바 스프링 경험이 있으면 더 유리하다.

 

채용공고들을 보면서 생각한 데이터 엔지니어의 가장 공통적으로 요구되는 기술은 하둡, 스파크라고 생각한다. 회사에서 하둡 스파크를 쓰지 않으면 최소한 도입하려는 노력은 해보자.(도입이 안되더라도 노력 자체를 자소서에 녹일 수 있다.) 도입이 되면 나중에 내가 쓸 이력서의 이력 한줄이 방금 생긴거고, 도입이 불가능한 환경이면 현재 사용하고 있는 기술을 깊이 있게 사용해보도록 노력하자.(기술을 사용한 이유, 현재 이걸 사용하는게 가장 최고의 판단인가?? 요거 나왔다던데 바꿔보면 어떨까? 뭔가 만족스럽지 않은데 더 좋은 방법은 없을까? 등) 기술을 깊게 생각해보고 사용한 것만으로도 상당한 가산점이 붙는다고 생각한다.

 

데이터 엔지니어 안에서도 여러 종류가 있고 나는 세분화해서 구분하자면 데이터 파이프라인 엔지니어인데, 경력직 기준으로는 데이터 파이프라인 제작만 하는건 경쟁력이 없는것 같다. 파이프라인 제작을 주 업무로 하지만 aws, k8s같은 인프라쪽은 물론, 데이터 플랫폼도 살짝 만져보고, ml팀과 협업도 해보고, 가벼운 웹 어드민 개발도 해봐야 경쟁력이 있다. 다른 직군이 보면 정말 이것저것 다하는데 이러면 잡부 아냐? 하는데 아직까지 데이터 엔지니어링은 직군이 정립되어가는 과도기한 시기라고 생각해서 잡부적인 경험이 더 경쟁력이 있다고 생각한다.(순수 개인의견)

(추가) 위에 빗금친 내용은 의견이 바뀌었다. 잡부적인 경험보다 하나라도 '제대로 깊게' 해본 경험이 더 선호되는것 같다. 정립된 직군을 데이터 플랫폼 개발을 예시로 들었는데, 데이터 엔지니어링의 많은 파트가 각자 정립이 되어가는것 같다. 그래서 여전히 스타트업을 제외하고 어느정도 이상 큰 기업에 가려면 본인의 파트에서 전문성을 갖는게 더 선호되는 방향으로 가고 있다고 생각한다. 하나의 경험에 대해 제대로 깊게, 나머지에 대해 기본적인 지식이 있는 T자인재가 역시 가장 좋은것 같다. 스타트업에서는 데엔인데 잡부인 케이스뿐 아니라 심지어 혼자서 분석과 데엔, 사이언스를 전부 하는 케이스도 많은것같다. 이 케이스는 경력이 아직 주니어로 쳐주는 5년 이하일때.. 좋은곳 잘 찾아가서 커리어를 잘 만드는게 정말 중요한것 같다. 그게 아니면 이력서 수정이 정말 많이 필요할거고 이직이 많이 힘들것 같다. 면접을 보면 세 분야 다 할줄아는 대단한 인재다! 가 아니라 대부분의 케이스에서 셋중 하나도 제대로 할줄 모르네.. 라는 반응이 나올 가능성이 높다. (나도 면접을 보면서 내가 뭘 모르고 있었는지 많이 깨달았다)

 

전문성에 대해 예를 몇개 들어보자면 데이터 플랫폼 개발같은 경우 데이터 크기가 작은 회사에서는 쿠버네티스 위에 helm chart로 스파크 하나 대충 올리고 사용하면 된다. 쿠버네티스도 없는 경우 가장 고전적인 방법으로 올라와있는 서버 몇대 위에 스파크 서버 구성해서 써도 돌아가긴 한다. 그리고 여기서 더는 생각해볼거리가 없다. 데이터가 작기 때문에 굳이 뭔가를 더 할 필요가 없기 때문이다. 데이터가 커져서 나가는 비용이 천, 억단위가 되면 비용과 최적화에 대해서도 생각해봐야 할거고 failover도 조금 더 잘 생각해봐야 할거다. 

데이터 플랫폼 말고 DW/DM 개발에 대해서도 생각해보자. 보통 데이터가 작은 회사들은 소수(1~2명)의 데이터 엔지니어들이 모든걸 전부 처리하므로, 테이블을 설계할시에도 '적당히' 우리끼리 알아볼수 있을 정도에서 만든다. 요것도 DW/DM의 범위가 커지면 어떻게 컬럼명을 통일하고, 규칙을 만들어야 이름만보고도 데이터를 추측 가능한가, 매일 갱신되는 데이터 퀄리티를 유지하기 위해 어떻게 모니터링할것인가 등의 고민을 하게 된다. 데이터 엔지니어는 요런 것들에서 전문성이 나뉘는것 같다.

현재 데이터가 작거나 소수의 데이터 엔지니어로 구성된 회사에서 일하는분들은 본인이 맡은 분야에서 어떻게 더 최적화를 할수 있을까 고민해보는게 좋을것 같다. 그런데 이건 내가봐도 이상적인 이야기인것 같고, 내가 생각하기에 현실적으로 데이터 엔지니어로써 정말 유의미한 커리어를 쌓으려면 데이터를 소중하게 잘 다루는.. 회사나 팀에 들어가는수밖에는 없는것 같다. 보통 데이터를 잘 다루는 회사의 시스템을 접하기 이전에는 이런것도 고민거리이고 시스템화해야하는구나..? 하는걸 잘 모를수밖에 없다.(내가 그랬다) 당연한 이야기겠지만 데이터를 소중하게 다루는 회사일수록 단순 돌리고 끝이아닌 팀, 조직단위에서 더 고민을 하게 되고 이러한 고민을 접하게 되는 것만으로도 성장하는 자양분이 되는것 같다.

 

커리어 관리가 잘 되고있다는건 이력서 작성시 내가 추가적인 양념을 뿌리지않고 한 일만 그대로 적어도 합격이 되는 이력이 커리어 관리를 잘해온거라고 생각한다. 대표적으로 종종 네이버같은곳에서 재직중이던 개발자들이 갑자기 어떤일때문에 화나서 주말동안 이력정리하고 2~3주 이내로 이직했다는 썰이 종종 들리는데 이런분들이 이력관리를 잘한 분들이라고 생각한다. 물론 네이버 재직 자체가 이미 좋은 커리어이긴 하다.

 

다시 정리해서 적으면 평소에 내 연차를 채용하고 있는, 가고싶은 회사들의 채용공고에서 어떤 기술적인 것들을 요구하는지 찾아보고 부족한게 있으면 사용하도록 노력해보고, 현 시스템을 개선하기 위해 노력해보자. 그리고 현 시스템이 최선일지 고민하려고 해보자. 물론 대다수가 일하느라 이런거 할 시간이 없지만 이직하려면 해야 한다.

내가 현재 나아가는 방향이 맞는지 끊임없이 모니터링하기위해 내 직군들이 모여있는 커뮤니티에 들어가자. 오픈카톡방도 괜찮으며 꼭 기술적인 이야기가 아니더라도 여러가지 이야기를 들으면서 시야를 넓히거나 정보를 얻을 수도 있다. 

한직군이 몇백명씩 있는 오카방의 경우에는 괜찮은 회사의 채용담당자들이 들어와 있는 경우도 많아서 채용공고 알람을 받을수도 있다. 또는 인프런같은곳에서 오픈카톡방 사람들을 대상으로 할인을 푸는 등 상당히 유용한점이 많다.

 

1. 준비 단계

실질적으로 이직준비를 시작하는 단계이다. 가장 먼저 목표로 하는 기업들 리스트를 생각해놓는다. 나의 경우 이직의 가장 큰 목적은 연봉이었고, 연봉이 만족스러우면 워라벨은 나빠도 상관없고, 그정도가 아니면 워라벨까지 어느정도 괜찮은 회사를 목표로 삼았다. 블라인드 글들과 이직한 동기들의 이야기를 여러 방면으로 듣고 개인 취향을 반영한 결과 결론적으로 카카오뱅크, 당근마켓, 우아한형제들 요 3개 회사중 하나를 가는것을 목표로 삼았다.(사실 두나무, 몰로코도 있었으나 이 두곳은 가장 빡센곳이라서 마지막에 쓰려고 했는데 그전에 붙어버렸다. 그리고 붙었을때쯤 면접보고 이력서고치고 다시준비하는 반복 작업을 좀 하느라 정신적으로 많이 지친상태여서 이 두곳은 쓰지 않았다.)

 

가고싶은 회사 리스트를 정할 때에는 보통 

1. 높은 연봉을 주는 곳인가

2. 네카라(네이버, 카카오, 라인)처럼 네임벨류가 있는 회사인가(커리어에 도움이 되는 회사인가)

3. 보통 워라벨이 괜찮은 곳인가

등으로 중요도를 매긴 후 1차적으로 가고싶은 기업들을 메모장 등에 정리해놓고, 2차적으로 1차에서 추린 기업들중 내가 하고있는 업무와 관련된 공고가 열려있는지 확인후 열린 공고들을 따로 정리해놓는다. 이후 가장 가고싶은 회사순으로 정렬한 후에 가장 안갈것같은 회사부터 지원을 하면 된다.

 

나처럼 신중하게 준비할거면 붙어도 가지 않을 면접 연습용 회사를 뽑아놓는다.(연습용으로 지원해보는건 그 회사 담당자들에게 미안하지만 많이들 이렇게 한다.) 원티드등에서 내 직군을 검색하면 채용중인 회사가 나오는데 적당한 리스트를 뽑아놓고 초반에 넣어보자. 나는 네카라중 하나, 스타트업 n개 등을 이력서, 면접 연습용으로 지원했었는데 붙었건, 떨어졌건 연습용으로 냈었던 기업들의 이름을 적는건 그래도 예의가 아니라고 생각해서 이름을 밝히지 않는다. 나처럼 첫 이직이면 이력서 작성에 익숙하지 않아서 기업들의 면접을 보고 이력서 내용이 크게 바뀌는 경우가 많으므로 어느정도 텀을 두고 지원한다.

가장 가고싶은 기업은 가장 나중에, 또는 '이정도면 어느정도 준비가 되었다'고 본인이 생각할때 쓰길 바란다. 언제 준비가 되었다고 느끼냐면 내가쓴 이력서를 기반으로 면접질문들의 범위를 구체적으로 예상할 수 있고, 면접을 볼때 예상했던 면접질문이 나오며, 그런 질문들에 대해 준비된 답변을 잘 답변할수 있을때 준비가 되었다고 생각한다. 어떤 질문이 들어올지 예상하는 능력은 면접을 보다 보면 길러지고,(이력서의 특정 구간에서 매번 비슷한 질문이 들어온다.) 더 나아가 내가 원하는 답변을 하기 위해 질문을 유도할 수도 있다. 면접도 연습이라고, 처음에는 질문 하나하나에 긴장했지만 경험이 쌓일수록 긴장감은 줄어들었다.

면접을 6번정도 본것같은데 코로나라 전부 구글 미트(https://meet.google.com/)로 온라인으로 진행하였으며, 온라인 면접을 위해 마이크가 동봉된 웹캠이 필요했다. 회사 맥북이 있으면 그거로 해도 되긴 하겠지만(사실 나도 초반에는 회사 맥북으로 면접을 몇번 보긴 했다.), 회사 pc라서 찝찝하거나 그러면 웹캠을 하나 구매하는게 좋다. 나는 이 상품을 구매해서 사용했다.

 

코딩테스트나 이력서를 준비하는 기간이 아닌 실제로 이력서를 내고 면접 보고 하는 기간은 한달, 좀 길게는 두달까지 목표로 잡자. 3달 이상되면 정신적으로도 힘들고 집중력이 떨어지므로, 이력서와 코테 준비가 어느정도 끝나면 그때부터 붙던 떨어지던 짧은 기간 안에 집중해서 끝내버리겠다는 마인드로 빡세게 하는게 좋다. 슬슬 준비해서 가야지~ 하다가는 회사 일이라도 조금 많아서 피곤해져서 늘어지면 몇년이 걸릴지 모른다. 나는 실제로 이력서를 내고 면접 보는 기간을 거의 두달을 가졌는데, 원하는곳에 합격했을때쯤 정신력을 너무 소모해서 가고싶은 나머지 기업들에 대해 추가로 이력서를 낼 생각도 하지 않았었다.

개인적으로 지원 초반시기의 면접주기는 일주일에 두번 정도 면접보는정도의 주기가 좋았다. 위에 적었듯이 면접 피드백을 보고 이력서를 더 좋게 수정하는 경우도 상당히 잦았기 때문이다.(난 거의 매번 이력서를 수정했다.)

면접볼수있는 최대치의 면접을 보는게 무조건 좋은것은 아니므로 본인의 상황을 보고 판단해서 더 낼지, 덜 낼지 결정하자. 쿠팡에서는 풀재택과 유연 근무를 하고 있어서 면접시간을 잡기가 편했는데도 불구하고 정신력 소모가 컸으니 이점을 유의해서 본인에게 맞는 정도를 찾자. 대부분 회사의 재 지원주기가 6개월 이상, 보통 1년이라고 보므로 한번한번의 기회에서 집중해서 되도록 많이 얻어가자.

이번에 실패하면 1년을 더 기다려야 한다.

 

2. 이력서 작성.

이력서 작성 첫단계는 적절한 포맷을 찾는것부터 보통 시작한다. 구글에서 괜찮은 포맷을 찾아보고 꾸며보고 비교하느라 시간을 많이 날렸는데, 나온 결론은 굳이 예쁜 포맷을 찾아보지 말고 그냥 원티드에서 제공해주는 이력서 양식을 쓰자.(원티드 광고 아님.)

포맷이 상당히 깔끔한 편이고(개인 의견), 내용이 중요해서 개발자 이력서 포맷이 누가누가 더 예쁜지 전혀 신경쓰지 않는다.(프론트엔드면 또 모르겠다) 난 처음에 구글에 '개발자 이력서 포맷'을 치면 내가 수정할수 있는 샘플 구글 독스 이력서 포맷이 있는데, 그걸 사용했었다가 포기했다. 구글 독스를 잘 쓰지않아서 줄맞춤이나 내가 원하는대로 커스터마이징이 힘들고 깔끔하게 정리되지 않는다고 느꼈기 때문이다. 원티드는 이력서를 출력해보면 깔끔하다는걸 바로 느낄 수 있다. 평타 이상은 한다고 생각해서 나처럼 디자인에 신경 쓰기 싫은사람은 그냥 원티드 이력서 포맷을 쓰는게 낫다. 그리고 순수 내용파트는 1~2장 정도로 요약하는게 가장 깔끔한것 같다. 내 개인적으로는 2장요약을 선호한다. 원티드에서 내용만 1장 정도 적으면 자격증이나 학교였나?때문에 두장이 나오게 되는데 내가 말한 기준은 순수 경력사항 내용파트만 1~2장 정도가 좋다고 본다.(원티드에서 뽑으면 2~3장짜리)

다시 적지만 내용이 중요하지 디자인은 별로 중요하지 않다.

 

지원하는 직군을 면접관이 알 수 있도록 이력서에 명확하게 정립해놓는다. 데이터 엔지니어도 내부적으로 여러가지 데이터 엔지니어들로 나뉘어진다.
데이터 플랫폼 엔지니어, 데이터 파이프라인 엔지니어, DW/BI 엔지니어, 시각화 엔지니어, mlops 관련 엔지니어 등.... 5가지를 적었는데 5가지가 다 롤이 다르다. 구체적으로 이름을 나눠서 모집하는 곳도 있고, 그냥 통합적으로 데이터 엔지니어로 뽑는 곳들도 많다. 보통 개발 인력이 그리 많지 않은 스타트업에서는 모든 일을 하니 직군을 세세하게 나누지 않고 데이터 엔지니어라는 직군으로 통합적으로 뽑고 규모가 있는 기업에서는 세부적인 롤로 나눠서 뽑으며, 롤마다 jd가 다르다.

데이터 플랫폼 엔지니어는 백엔드 개발이 보통 자바 스프링인것처럼 데이터 엔지니어 중에서도 롤이 어느정도 정립이 된 직군이고, 파이프라인 엔지니어는 왠만해서 대부분이 잡부(내 케이스인데 보통 기술 스택이 사람마다 다른게 일반적이다.), DW와 시각화 엔지니어는 정립이 되어있지만 그리 수요자체가 많지는 않고, mlops는 데이터 사이언스팀에서 만들어준 모델링을 자동화하는 엔지니어를 뜻한다.(얘도 어느정도 정립이 되어있다.)

직군이 세부적으로 나뉘어져서 모집공고가 있는 곳이면 하는 일을 보고 내가 하는 일이랑 매칭해서 지원할수 있을텐데, 데이터 엔지니어를 통합으로 뽑는 스타트업같은곳에 지원하면 그쪽에서도 내 이력서만 보고 내가 어떤일을 중점으로했나 판단하므로 내 롤의 특징이 확실히 드러나도록 이력서를 작성하는게 좋다. 데이터 플랫폼 엔지니어 롤을 해왔으면 데이터 플랫폼 운영 등을 중점으로, 파이프라인 제작을 많이 해왔으면 파이프라인 제작을 중점으로. 이렇게 내 롤을 확실히 드러내야 면접에서 내가 모르는 다른 데이터 엔지니어링 영역에 대해 질문받는것을 피할 수 있다.(또는 잘 몰라도 마이너스없이 그냥 넘어갈수 있다.) 지금 생각하는건데, 모르는건 모른다고 확실하게 미리 자르고 가는게 이것저것 다 할줄안다고 적었다가 면접에서 털리는것보다 1000배는 더 낫다. 나같은경우 처음에 이력서를 썼을때 내 롤을 모호하게 드러내서 내가 모르는 다른 영역에 대해서까지 질문을 받았었고 답을 못해서 마이너스가 컸다. 난 이런일 안했는데 왜 이런 질문을 했지?했는데 이력서를 모호하게 쓴 내잘못이었다.

저쪽에서 a가 필요하고 a를 물어보면 그거에 대해 잘 대답해야 면접에 붙는거 아님? 할수도 있는데 내가 해온게 b이면 b에 대해 강점이 있다고 어필하는게 맞는것 같다. 어색하게 a에 대해 아는척해봐야 왠만해서는 면접에서 물어보면 그냥 털리니, 거짓말하다 들키는것보다는 나는 b전문가이고 a에 대한 지식도 약간은 있다.. 너네가 뽑아주면 그래도 도움은 될거다!는 전략이 맞는것같다.(애초에 jd에 맞게 지원하는게 가장 좋긴 하다.)

 

첫번째로 이력서를 냈었던 기업은 유니콘 스타트업이었다. 지금보면 이력서에 어떤 부분을 집중해서 보여줘야하는지도 몰라서 막 썼는데 사람이 급했는지 면접을 봤다. 지인들에게 보통 첫면접은 아주 탈탈 털린다는 말을 들었는데 그 말을 듣고 '난 절대로 안털려야지.' 하고 준비를 하고서도 아주 탈탈 털렸다. 이력서 파트니 이력서에 대해서 몇가지 얘기하자면 위에서 말했듯이 면접시에 대답을 깊게 잘 할 자신이 없으면 조금이라도 뭔가를 더 했다는걸 어필하기 위해 전부 적지는 말자. 

내가 한 일인데 조금 한거면 지식이 짧다. 그런데 여기서 질문이 조금만 깊게 들어가도 모르는것들이 상당히 많이 나오고 이러면 나 자신에 대한 불신이 생기면서 면접 전반적으로 상당한 마이너스이다.(개인적으로 이런거 걸리면 왠만해서 떨어진다고 생각한다.) 나는 이후 이력서에서 그 내용을 아예 빼버렸다. 

나도 이 이야기를 이직준비할때 동기들에게 들었음에도 '그럼 난 준비해서 뛰어난 인재가 돼야지' 하고 생각했는데 첫번째 면접을 보고 깨달았다. 나는 내가 뭘 모르는지 모르고 있었다. 그 분야에 대해 뭘 모르는지도 모르는데 이걸 이력서에 쓰는건 아니라는걸 깨달은 이후 이력서에서 해당 내용을 빼는데 주저함이 없었다. 

 

그리고 기술보다는 비지니스 목표를 중심으로 적자. 지금보면 너무 부끄럽지만 아무것도 몰랐던 내 첫 경력이력서의 일부를 적어본다.

 

주 제목 : 쿠버네티스 인프라 구축

내용 : aws ec2의 오토스케일링 그룹을 기반으로 팀 내에서 사용할 쿠버네티스 환경을 구축하였습니다.(m4.xlarge)

 

너무너무 기술 중심적인 말이다. 쓸때없이 aws ec2 타입도 적었고 나는 데이터 엔지니어이지, 인프라 담당자가 아님에도 뭔가를 더 보여주기 위해 적었다. 그런데 너무 기술 중심적으로 적으면 면접때 풀어나갈 얘기가 적다. 왜냐하면 저런 기술적인 이야기는 면접에서 할 이야기이기 때문이다.(심지어 aws타입같은건 절대 물어볼 거리가 아닌데 아주 쓸모없는 정보를 이력서에 적었다. 이불킥 각..) 아마 이 이력서를 받았던 기업은 이사람은 왜 이런걸 적었을까? 궁금했을것이다.

저렇게 기술적으로 하는일을 적기보다는 비지니스 성과 중심적으로 적자. 현 이력서는 보안때문에 내용을 직접 가져오지는 못하고, 예시를 하나 만들어본다.(참고로 난 추천시스템을 만들지 않았다. 그냥 만든거)

 

주 제목 : 추천 시스템을 위한 데이터 파이프라인 구축

내용 : 개인화 추천 시스템 개발, 사용자 찜상품 관리 프로세스 파이프라인 구축, 머신러닝 지원 파이프라인 개발

 

위처럼 적는거로 충분하다. 그리고 면접에 들어가서 구체적인 기술에 대해 이야기를 나눈다. 

면접관 : 이력서에 찜상품 관리 프로세스 파이프라인 구축이라고 적으셨었는데 어떤 기술을 사용해서 어떻게 구현하셨나요? 요런식으로 대화식으로 이야기를 한다. 그리고 면접을 몇번 보다보면 무의식적으로 적었는데 내가 대답하기 취약한 질문들이 있는데 그런것들은 피하도록 이력서의 세부적인 내용을 계속해서 수정하자.

위에서 말했듯이 절대로 기술 중심적으로 적지 말자. 어쩔수없이 기술을 써야할것 같으면 간단하게 적자. 기술 중심적으로 적지 말자는거지 무슨 기술을 사용했는지 간단하게 적는건 좋다고 생각한다.

 

이 영상은 개인적으로 감명받은 우아한형제들의 ceo인 분이 인터뷰한 유튜브 영상인데 여기서 개발자라면 본인을 코드를 짜는 사람이 아니라 비지니스 문제를 해결하는 사람이라고 생각했으면 좋겠다는 말이 나오는데 내가 주니어를 넘어서서 시니어로 나아갈 큰 틀을 잡는데 정말 중요하게 참고할만한 말인것 같다.

이력서를 쓸 때 기술중심으로 쓰지 말고 비지니스 성과를 중심으로 이력서를 쓰자.

 

3. 코딩테스트

코딩테스트는 백엔드 엔지니어와 데이터 엔지니어는 확실히 차이가 있다. 참고로 나는 리트코드를 취미로 풀고 있고 리트코드로만 경력 코딩테스트를 준비했다.

내가 지원했던 네카라중 한곳은 직군 구분없이 개발자면 동일한 코딩 테스트를 친다. 난이도는 리트코드 이지, 미디움 하위 정도였다. 여기말고 지원했던 다른 곳들은 전부 대부분 문제의 난이도가 이지~미디움 하위정도였다. 그리고

데이터 엔지니어라 그런가 코딩테스트를 본 다른곳들은 전부 sql과 관련된 코테문제가 꼭 한문제는 나왔다.(라이브 코테 포함) 

sql문제가 최소 한문제이상 나오는데 전부 윈도우 함수를 사용하는 문제가 포함되어있었다. 데이터 엔지니어로 경력 이직을 준비하는 사람은 반드시 윈도우 함수를 공부해야하고, 단순히 개념공부만 한다고 풀수있는 문제가 아닌 경우가 많다. 나같은경우 리트코드를 결제해서 사용하고 있다. 결제를 하면 잠긴 문제를 풀수 있는데, 리트코드의 데이터베이스, 미디움 난이도의 카테고리를 보면 대부분이 윈도우 함수 문제이다. 

리트코드에서 sql 미디움만 한 20문제정도를 풀었는데 모든 sql코딩테스트에서 전혀 어려움을 겪지 않았다. 개인적으로 한달치만 결제해서 빡세게 풀어보는걸 추천하고, 그게 아니면 다른 플랫폼도 있으나 애초에 적절하게 풀어볼만한 sql문제 자체가 많지 않기 때문에 이직에 진지하다면 난 그냥 리트코드를 한달 결제하는걸 추천한다.(한달기준 35$, 한화 44000원정도. 링크) 위에 적었듯이 난 리트코트 유료 sql문제를 풀고 코테에 나왔던 sql문제는 전부 풀었다.

sql을 제외한 문제들은 블로그의 알고리즘 카테고리를 보면 알수있듯이 알고리즘 문제를 많이 풀어와서 쉬웠다. 이직 준비중에 코테 준비가 가장 걱정이 없었다.

 

4. 면접

위에 적었듯이 구글 미트(행아웃)로 면접을 보며, 1:2, 1:3, 1:4, 1:5 등 다양하게 면접을 봤고, 모든 면접이 다대일면접이었다. 면접에도 여러가지 전략이 필요하다. 면접 초반에는 면접전에 단순히 내 이력서를 한번더 읽고 내가 한 일들을 다시 정리해보고 면접때 면접관님이 질문하면 중구난방으로 그거에 대해서 연관되는 모든것을 다 말하는 방식으로 했었다. 그러니까 나에 대해 모든 정보를 다 던져놓고 판단은 니네가 해. 요런 식이었는데 당연히 이러면 안된다.

면접에서 대화시에 두괄식의 대화가 필요하다. 이게 상당히 중요한 이유가 두괄식으로 대화해야 내가 한 일들을 효과적으로 전달할수 있고, 효율적인 정보전달과 더불어 의사소통이 잘 되는 사람인지도 판명되므로 정말로 중요하다고 생각한다.

 

위의 이력서에서 만들었던 추천 시스템 예시를 다시 가져온다.(다시 적지만 난 추천시스템 관련 일을 하지 않았고 추천 시스템을 어떻게 만드는지도 모른다.)

주 제목 : 추천 시스템을 위한 데이터 파이프라인 구축

내용 : 개인화 추천 시스템 개발, 사용자가 찜한 상품 프로세스 파이프라인 구축, 머신러닝 지원 파이프라인 개발

 

면접 초반.

면접관 : 개인화 추천시스템을 만들었다 그러는데 뭘 만들었나요?

나 : 개인화 추천시스템은 요걸 만들고 저걸 만들고 이렇게 만들었습니다. 그리고 이걸 하다보니 요게 너무 어려워서 요거까지 하게되어서 저것도 만들었습니다.

-> 하나 물어봤는데 주제에서 벗어난 내용까지 너무 주절주절했다. 이러면 이후에 면접관이 뭔가를 더 물어보기도 애매하고 이후에 한 얘기를 또하게 된다. 불필요한 커뮤니케이션 비용이 발생하면서 기술적으로 설명을 잘해도 커뮤니케이션적으로 마이너스될 확률이 높다.

.....

면접관 : 머신러닝 지원 파이프라인은 어떤걸 개발하셨나요?

나 : 아 제가 이거는 아까 말했던것중에 하나인데요~... 어쩌구 저쩌구

-> 위에서 한말 비효율적으로 반복.(지양하자.)

......

면접관 : 요렇게 구현하셨다고 하셨는데 그렇게 구현하신 이유는 뭔가요? 저렇게 구현할수도 있었을텐데요.
나 : (그냥 이방법이 더 간단해서 한건데 뭐라고 대답하지) 어.. 이 방법이 괜찮다고 생각해서 저렇게 구현하는건 고려해보지 않았었습니다.

-> 질문들에 대해 준비가 되지 않음.

 

면접 중후반.(물론 아래 내가 적은 예시보다 더 좋은 답이 있을거다.)

면접관 : 개인화 추천시스템을 만들었다 그러는데 뭘 만들었나요?

나 : 개인화 추천시스템은 요걸 중점으로, 이렇게 만들었습니다. (질문에서 벗어나지 않고 과하지 않은 정제된 답을 한다.)

면접관 : 아하 그러면 요걸 만들면서 요러한 문제가 발생했을수도 있을텐데 이건 어떻게 해결하셨을까요? (이 이야기를 할때 다수의 면접관이 요러한 문제가 발생할수 있다는 질문을 이미 여러번 받아서 답변 준비가 되어있다.)

나 : 그 문제에 대해서는 요렇게 구현했습니다.

면접관 : 요렇게 구현하셨다고 하셨는데 그렇게 구현하신 이유는 뭔가요? 저렇게 구현할수도 있었을텐데요.
나 : 제가 이것저것 시도해보면서 비교를 해본 결과 요 시스템이 비해서 이 시스템은 이런 장점이 있었고 현재 시스템의 요러요러한 특성상 요런 구현의 장점을 활용하는게 더 적합하다 생각해서 이걸 하기로 정했습니다. (시스템의 특성에 대해 깊게 고민해보고 생각해봤다는 느낌을 줌. 사실은 비슷한 질문을 여러번 받아서 준비된 답변임.)

나 : 그리고 요 문제를 해결하기 위해서 요 인덱스를 사용했습니다. (요 인덱스는 특수한 인덱스. 면접관에게 왜 요 인덱스를 사용했는지 질문을 유도함.)

면접관 : 왜 요 인덱스를 사용했나요?

나 : 들어오는 데이터가 요러조러한 특성이 있어서 요 인덱스를 사용하는게 맞다고 생각했습니다.

면접관 : 그럼 조금 더 깊게 물어볼게요. 요 인덱스의 또다른 특성에 대해 아시나요? (이쯤 오면 면접관의 질문을 유도하는데 성공했고 나는 질문을 유도했던 만큼 당연히 공부를 열심히 해가서 답을 할수 있다.)

나 : 네 어쩌구 저쩌구 준비했던 답을 함.

 

이런식으로 주고받으며 대화 티키타카가 잘 이어져야 한다. 초반에는 종종 특정 기술셋을 사용했었어야한다는 무의식적인 강박이 있어서 기술적으로 답을 많이했었다. 예로 데이터 엔지니어는 일반적으로 데이터 처리시에 스파크를 많이 사용한다. 그런데 꼭 데이터 엔지니어이지만 데이터를 반드시 스파크같이 플랫폼을 써서 해결했다!는 결론이 나오지 않아도 된다.

글로 풀어놓으니 너무나 당연한 이야기지만 스파크는 문제 해결 도구중 하나이며, 문제 해결 도구는 스파크가 아니어도 된다. 다른 문제 해결 도구에 대해 면접관들에게 논리적으로 이야기를 할 수만 있으면 된다. 아래는 예시이다.

 

면접관 : 스케쥴링은 왜 airflow같은걸 사용하지 않고 크론탭으로 돌렸어요?

나 : airflow가 현재 존재하지 않고, 스케쥴링할만한 잡이 별로 없는데 굳이 airflow까지 설치해야할 필요성을 못 느껴서 그랬습니다. airflow를 설치하면 관리까지 해야하니 일이 늘어나는데 굳이 그만한 자원을 더 투자할만한 일이 아니었거든요. 물론 어느정도 규모 이상이 되면 고려하겠지만요.

면접관 : 데이터 처리는 주로 어떤것을 사용해서 했나요?

나 : 파이썬의 판다스를 많이 썼고 그냥 순수 파이썬으로도 많이 처리했습니다. 요 데이터들은 크기가 작은 경우가 많아서 스파크로 처리하는건 오버스펙이라고 생각했습니다.

 

그리고 유니콘 스타트업들의 모집공고를 보다 시니어 엔지니어 공고를 보았다. 경력 5년 이상으로 뽑는데, 별 생각없이 경력맞춰서 시니어로 지원했다가 낭패를 봤었다.

시니어 면접은 대부분 시스템 디자인 면접을 본다. ex) "추천 시스템을 설계해보세요." 그냥 진짜 이것만 딱 던져주고 데이터 처리 플랫폼부터 처리 주기, 모니터링 등등 혼자서 다 설계해야하는데 정말 난감했다. 만들면서 이슈가 생길만한 파트를 물어보면 그 파트에 대해 어떻게 처리할지 설명하면 된다. 이후에 "가상 면접 사례로 배우는 대규모 시스템 설계 기초" 라는 책을 사서 읽고 시스템디자인을 가볍게 공부했다. 하필 이 시스템 디자인 설계를 탈탈 털린다는 첫면접에 봐서 멘붕이 두배는 더 크게왔었다.

'아니 원래 경력 5년에 이직하려면 이런것도 준비해야돼?' 하고 많이 당황했었는데 이후에 다른 스타트업에서 시스템 디자인 설계 면접을 한번 봤을뿐,(첫번째와 비슷했음) 나머지 회사들에서는 시스템 디자인과 관련된 질문을 받지 않았다.

 

기술면접은 직접 말을 내뱉고 상대방과 의사소통하는것이기 때문에 내가 시뮬레이션했던거와는 다르다. 실전 면접에서는 말을 내뱉다가 필요한 문장을 빠트릴 수도 있고, 막히는 경우도 있다. 이를 위해 집에서 혼자 소리내어 내뱉는 연습을 해보자. 이건 내 동기가 추천해준 방법인데 효과가 괜찮은것 같다. 많은 개발자가 코로나라 재택근무하면서 말수가 줄어들었을텐데, 소리내어 연습하는 훈련은 이를 보완해준다. 솔직히 민망하긴 한데 이런 훈련이 내 연봉을 올려준다고 생각하면 민망함이 사라진다.

 

그리고 가장 중요한것중 하나로 면접이 끝나자마자 답을 못했거나 애매했던 면접 질문들을 정리해야한다. 하루만 지나도 많은 질문들이 기억이 나지 않는다. 난 안했던건데 면접을 온라인으로 진행할 경우 녹음기를 키고 면접을 보는것도 괜찮은것 같다. 내가 어떤부분에서 답변을 잘 못했는지, 어떤 내용을 말했었어야 하는데 말을 못했는지 등을 파악할수 있다고 한다. 나는 내목소리듣는게 민망해서 녹음은 안하고 면접후 바로 메모장에 정리해놓는 방식으로 했었다.

 

기술적인 부분에 관해서는 백엔드 동기들에게 들었던것들중 나와 겹치는것같은 부분들을 준비해갔었다. 예로 백엔드는 mysql index구조를 종종 물어본다고 한다. 나도 공부를 했다. mysql index구조는 b+ tree구조이고 브랜치가 어쩌고, 리프가 어쩌고, b tree와의 차이점은 어쩌고를 다 공부했는데 mysql index구조를 물어봤던 면접은 한곳도 없었다.

기술적으로 세세하게 들어가는 질문보다는 내가 해왔던 업무와 내가 기술을 도입시에 여러가지 고민을 해봤는지(별생각없이 쓰지는 않았는지), 문제해결력과 관련된 질문을 받았는데, 이건 내 이력서가 잡다한 여러 일을 했다고 적어서 특정 기술을 기술적으로 깊게 물어보기보다는 개발자로써의 전반적인 역량을 파악하는게 더 좋다고들 생각해서 이랬던것같다.

지금 다시 생각해보니 내가 정말 데이터 엔지니어로써 하나만 깊게 팠었으면(mlops만 한다던지, 데이터 웨어하우스 제작만 한다던지)였다면 이러한 내용들에 대해 깊게 질문했을것 같다.

나는 데이터 엔지니어가 보통 스파크를 많이쓰니 스파크에 대해 깊게 공부했다. 스파크의 메모리 구조가 어떻고, dataframe이 어떻고 등등. 근데 예상했던 스파크에 관한 얕은 기술적인 질문은 들어왔지만 깊은 질문들은 들어오지 않았다.

 

이력서가 완성되고,(본인이 느끼기에 이정도면 잘썼다, 바꿀게 없다라고 생각하는 시점) 바뀌지 않는 이력서로 면접을 2,3번정도 보면 물어보는 질문들 리스트가 어느정도 정형화된다.(어느 타이밍에 어느 질문이 많이 나오는지도.) 대답하기 힘든 질문들이 나오고, 대답하기 힘든 질문에 대해서는 이미 다른곳에서 받은 질문이면 생각해봤던 문제지만 모르는척하고 미리 생각했던 좋은 답을 낸다던지, 일부러 내 문제해결력을 어필하기 위해 어떠한 위기가 있었다는 식으로 이야기를 풀어나가서 어떻게 해결했나요? 하는 질문을 유도한다던지. 하는 능청(?)이 필요하다.(면접을 어느정도 보다 보면 이 다음에 나올 질문이 벌써 예상되어서 물어보기도 전에 먼저 말이 나오기도 한다.) 이런 경험 때문에 다들 가장 가고싶은곳은 맨 마지막에 쓰라고 하는것같다.

 

내 추측인데 주변 이야기와 경험을 종합해보면 주니어 연차(보통 경력 3년까지)는 cs지식이나 기본기, 시키는 일에 대해서 1인분은 할수 있겠나, 성장성은 어떻게되나를 중점적으로 체크하는것 같은데 중니어 연차(경력 5년부터 9년정도까지)는 기본기도 보지만 좀더 나아가서 한 프로젝트에 대해 혼자서 맡아서 진행할수 있는지? 정도를 보는것 같다. 신입때는 배우겠다는 말을 하는 사람이 많은데 경력이직이면 주니어여도 이제는 프로이므로 배우겠다는 식의 표현은 하지 않는게 좋은것같다.

 

5. 최종결과

가고싶었던 회사 3개.

카카오뱅크 : 서류탈. (이력서를 쓸줄 몰랐을때 냈다. 개발자 대란이라는데 면접까지는 보겠지! 하는 무대포 자신감으로 냈는데 그냥 서류탈했다. 이때 충격먹고 이력서를 다시쓰기 시작했다. 지금 생각해도 뭔 자신감이었는지 모르겠다.)

당근마켓 : 서류탈. (여러곳 면접보고 거의 마지막에 낸거라 이력서도 잘 썼고, 내부 지인에게 추천 버프도 받았는데 서류탈. 이유가 궁금해서 물어보니 사용해온 기술셋이 맞지 않는다고 한다. 면접은 볼줄 알았는데 좀 충격..)

우아한형제들 : 최종합

 

총 최종결과.

서류탈 : 유니콘 스타트업 하나, 네카라중 하나, 카카오뱅크, 당근마켓

면접탈 : 작은 스타트업 하나, 유니콘 스타트업 둘

최종합 : 중간 스타트업 둘, 우아한형제들

 

우아한형제들 입사 예정.

 

6. 개인적인 추가의견

코테 준비는 중간에 좀 쉬더라도 꾸준히 하자. 물론 코테 안보는곳 지원해서 합격하면 되겠지만 이직을 결심하게 되고 실제 지원까지 오래걸리는 많은 경우가 코테에 대한 자신감 부족 때문이 많은것같다. 이제 이직생각이 없으면 모를까 코테는 중간에 몇달 쉬더라도 다시 조금씩 해서 감을 잡아놓자. 난 정말 코테가 안맞는다 싶으면 빨리 마음먹고 면접만 보는곳을 쓰던가 과제만 보는 곳들을 중점적으로 지원하자. 요즘은 코테 안보면서도 괜찮은 곳들이 은근히 많다.(ex) 토스는 코테를 안본다.)

 

같은 직군의 인맥을 되도록 많이 만들어놓자. 회사 내의 내부사정을 들을 수 있을 뿐더러, 바깥에 공개되지 않는 추천으로만 뽑는 채용공고정보등도(히든퀘스트라고들 한다..) 얻을 수 있고 같이 일했던 사람이면 내부추천의 영향력이 있다. 나도 어느정도 느낀것같고 나 외에 다른 동기들과 이야기할때도 추천의 영향력을 어느정도 느꼈다고들 한다.
면접을 볼때 처음보는 사람이면 면접관들이 ??? 하면서 들어오지만 어느정도 괜찮은 지인의 추천이면 이미 면접보기 전부터 지원자에게 미세한 호감버프를 갖고 면접을 시작한다고 보면 된다. 왜냐면 기본적으로 인성이던 실력이던 어느정도 괜찮다는게 1차적으로 증명이 되었다는 거니(추천해주는 사람이 인성이던 실력이던 나를 별로라고 생각했으면 추천을 안 해줬을거니까.) 기본실력만 면접으로 어느정도 검증이 되면 나는 뽑는걸 고려해볼만한 인재가 되는거다.
추천을 안 받은 곳의 면접에서 100을 증명해야 합격하는 느낌이면, 추천을 받았던 곳은 70~90(기업마다 다르다는 의미)정도만 보여줘도 되었던것 같다. 사실 내가 면접을 그렇게 많이 보지 않아서 명확하게 말하긴 힘들고 그냥 순수 내 느낌이다. 이제와서 다시 깊게 생각해보면, 내 사례말고도 동기들의 사례까지 종합해보면 특히 스타트업의 경우에 추천의 영향력이 더 큰것같았다.(실력하방을 좀더 중요시하는 느낌?)

혹은 내가 추천받은곳들은 추천받고 떨어지면 민망하니까 여기저기서 미리 연습하고 거의 이직준비의 끝부분에 몰려있어서 실제 난이도는 다른곳들과 비슷했고, 추천의 영향력은 딱히 없었지만 내가 면접에 익숙해져서 더 쉽게 느꼈던걸 추천의 힘으로 생각했을수도 있다. 여러 사람들의 말을 들어보면 추천 영향력이 딱히 없었다는 사람들도 많아서 여러 케이스가 있는것 같긴 한데 내가 보기에 위에도 적었지만 스타트업의 경우에 좀더 영향력이 있었던것 같고 대기업이라도 받아서 나쁠건 당연히 없으니 받도록 노력하자.

내가 받게되는 추천버프의 정도는 나를 추천해준 사람이 현재 그 회사에서 괜찮은 사람인가, 같이 직접적으로 일을 했던 사람인가, 현재 내가 지원하는 팀의 맴버인가 등등에 따라 추가되는 효과의 정도가 다른 것 같다.
추가로 우형에 들어와서 직원들이 CEO나 인사팀에게 질문을 하는 시간이 있는데, 여기에 어떤분이 왜 내가 추천한 인재들은 전부 떨어지는지 질문을(가장한 하소연) 한 사람이 있는거보면 또 그렇게 추천 영향력이 생각만큼 없는것같기도 하고? 그렇다.

 

그리고 이건 동기들이나 아주 친한 인맥만 해당되는 이야기일것 같은데 나와 같은연차가 다른 회사에서 어느정도의 보상을 받고있는지 알수있다.(보통 친하지 않는이상 연봉얘기는 잘 안하니.) 그것을 기반으로 최종합격후 내가 제시할수 있는 연봉의 대략치를 알 수 있으니 상당히 좋은 정보이다. (물론 전직장 베이스라서 상한선은 있으나 최대한 효율을 내는게 좋으니)

나같은 경우는 스타트업이나 네카라로 간 동기들 5명정도에게서 계약연봉과 원천징수를 들어서 어디 합격했을때 어느정도를 제시하면 좋을지, 그 이하면 안가는게 맞는것같은지 등의 데이터를 가지고 있었다. 이 정보가 없으면 가는곳에서 내 연봉을 후려치는 것인지, 잘 대우해주는건지 평타인지 알수있어서 좋다. 별생각없이 회사측에서 현연봉에서 500올려서 제시가 왔고 나는 그정도면 만족해서 싸인했는데.. 알고보니 내 동기들은 그 회사 들어갈때 1000씩 올리고 갔으면.? 물론 면접 결과에 따라 다르고 동기가 1000을 올렸다고 나도 1000 올릴수 있다는 보장이 있는건 아니나 이미 정보를 알고 말이라도 꺼내봤으면 후회는 안하지 않을까 싶다.

보상에 대해서는 같은 경력의 나보다 더 많이 받는 사람을 보고 현타(?)를 원동력으로 이직을 준비하자. 정신적으로 스트레스를 많이 받는 경우도 많은데, 이런 경우를 잘 조절하자. 무조건 남과 비교만 하다가는 너무 불행해질수 있다. 보상을 알고 나면 현타때문에 일을 못하는 사람들도 많은데, 커리어나 보상에 욕심이 있으면 알아야 할 정보이므로 미리미리 대략적으로는 알아둬서 충격을 낮춰두자. 나같은 경우도 만약 내가 평균보다 못받는 케이스면 현타때문에 일을 잘 못하겠는 경우인데, 나는 이직생각이 없는 기간에는 다른 사람들에게 서로 보상정보는 말하지 말자고 한다. 그러다가 이번에 이직하고 싶을때 내 자신이 이직공부를 더 열심히 준비할수 있게끔 보상정보를 듣고 '이직하면 훨씬 더 받을수 있는데 이직못하면 난 바보 멍청이다'로 나 자신을 압박하면서 공부를 불태우는 수단으로 사용했다.(물론 이러다 이직실패하면 현 직장에서 현타만 커지니 알아서 잘하자..)

아니면 아예 포기하고 이런 보상에 관한 정보들은 아예 모르고 나만 행복하게 만족하면서 일하는것도 괜찮은것같다. 연봉이라는게 한번 알게되면 긍정적으로는 끊임없는 자기개발의 원동력이 되지만 부정적으로는 불행의 씨앗이 될수도 있으니말이다.

 

그리고 지인들에게 합격한 이력서나 면접 관련 정보도 얻을수 있을테니 잘 참고하자. 글을 읽으면서 내 연봉정보나 이력서를 준다고?하고 의문을 갖는 사람들도 있을텐데 주니어 레벨에서는 특히 서로 공유하는 케이스가 은근히 많고 지금도 친한 동기와는 보상정보를 공유하면서 어디가 잘주네 저기가 잘주네 이런 이야기를 많이 한다.(물론 다른 회사 동기들)

나도 처음 이직 이력서를 작성할때 어떻게 작성해야 할지 몰라서 좋은곳 합격한 동기들의 이력서를 4개정도 받아서 참고하고 첨삭받았다. 신입때는 별 정보가 없었으니 인맥 그런게 뭐가중요해. 나만 잘하면 이직 잘하고 잘먹고 잘산다~ 인 마인드였으면, 지금은 나름 이런 인맥이나 정보의 중요성을 알았다고 해야 하나.. 그렇다.

 

그리고 이직 경험이 없으면 지금 이직생각이 없더라도 반드시 시간을 내서 이직준비를 해보고 최종합격까지 가보자. 내가 상상했던, 들었던 이직 프로세스와 실제로 겪는것은 정말로 다르다. 난 처음에 지금 개발자 대란이고, 이직이 잘되는 연차이고, 현직장도 괜찮고, 공부도 계속 해와서 10곳 넣으면 반이상은 최종합할줄알았다. 이 근자감이 처음 넣은 기업에서 서탈, 첫 면접때에는 털리는등 바사삭 깨지면서 현실파악을 빠르게해서 다행인것 같다.

그리고 깨달은점은 최종합격까지 한번은 겪어봐야 나중에 내가 진짜로 이직하고싶을때 할수있다는거다. 지금 이직 생각이 없더라도 1,2년후에 이직 생각이 있다면 이번년에 반드시 끝까지는 가보자. 안하면 막상 실제로 이직하고싶은 년도에 실패하고 연습해둘걸.. 후회할 확률도 높다.

이직 시도도 해보고, 떨어져도 봐야 내가 정말로 어떤 부분이 부족한지 깨닫고 현실파악을 할 수 있다.