LINE 서버 개발자가 되기까지 내가 준비한 것들

이 글은 마이크로소프트웨어 397호에 기고된 글입니다.

들어가며

시대와 상황이 많이 바뀌었지만, 아직 우리나라에서 ‘이직’은 낯선 단어입니다. 저희 부모님은 평생 직업과 평생 직장이라는 타이틀을 간직하며 살았던 세대인데요. 그런 부모님께 취업한 지 만 1년 6개월을 조금 넘어선 시기에 이직을 염두에 두고 있다고 말씀드렸습니다. 제 생각을 들은 부모님은 영 탐탁지 않은 표정을 지으시더니 이내 “벌써 회사를 옮기고 그게 반복되면 업계에 소문이 나서 더 이상 일을 못할 수도 있다”고 하셨습니다. 아무래도 한 직장을 10년을 넘게 다니며 이직이라는 단어는 거의 생각하지 않으셨던 부모님께는, 신입 딱지를 떼어내고 일을 열심히 할 시기에 이직하는 게 좋아 보이지 않았을 수도 있겠죠.

하지만 IT 업계에서 이직은, 잘 활용한다면 새로운 기회가 되며 나의 성장 동력원으로 삼을 수도 있다고 생각합니다.

 

이직 준비는 하루아침에 되는 것이 아니다

막상 ‘이직해야지!’라고 마음을 먹어도 무엇부터 준비해야 하는지 대부분 감이 잘 안오실 겁니다. 저도 처음 이직을 결심했을 때 그랬습니다. 아직도 주변에서는 비교적 최근에 이직한 저에게 무엇부터 준비를 해야할 지 많이 물어봅니다. 이제부터 차근차근 알려드리겠습니다.

 

앞으로 성장할 모습을 바라보고 이직할 직장과 직군 고르기

직장과 직군 선택은 처음으로 해야 할 일이자 가장 중요한 작업입니다. 본인의 커리어를 생각하고 그 커리어를 이루기 위해서 이직할 직장을 골라야 합니다. 이때 업계에서 해당 기업의 인지도나 성장 가능성 등을 고려해 볼 수 있습니다. 저는 처음 개발자로 커리어를 시작할 때부터 백엔드 서버 개발을 지망했습니다. 개발자로 취업할 때부터 백엔드 개발 혹은 서비스를 제공하기 위한 플랫폼 개발을 하고 싶었습니다. 사실 ‘백엔드 개발’, ‘플랫폼 개발’이란 단어도 상당히 큰 범위를 아우르는 단어였던 탓에 면접에서 심도 깊은 이야기를 나누는 계기가 됐는데요. 백엔드 개발은 수없이 많은 세부 갈래로 나눌 수 있고, 플랫폼 역시 엄청나게 다양한 종류가 있기 때문입니다. 자신이 원하는 직업을 상세하게 그릴 수 있다면 좋겠지만 ‘주니어’는 그럴 수 없다는 걸 우리는 너무 잘 알고 있습니다.

이직하려는 사람의 연차가 낮으면 낮을수록 해당 업무에 대한 전문성이 상대적으로 부족하고, 그 때문에 상세한 커리어를 상상하기 어렵습니다. 따라서 처음에는 세세한 내용까지 채우려 하지 말고, 커리어 관점에서 큰 그림을 그리며 목표를 세워야 합니다. 최소한의 울타리를 설정하는 것이죠. 최근엔 이런저런 방식으로 커리어 패스가 다양해지는 바람에 세세한 부분까지 고려하다간 준비 과정에서 진만 빠지게 됩니다. 명심합시다. 이직을 준비하는 첫 단추에서 중요한 것은 나의 커리어를 완성해 나갈 수 있는 직장과 직군을 고르는 것입니다. 회사의 간택을 바라며 (본인이 보기에) 이직이 쉬워 보이는 직군을 선택하는 우를 범하지 맙시다. 그런 직군은 존재하지도 않습니다. 이직은 목적이 아니라 커리어를 위한 수단이 돼야 합니다.

“정말로 그 직군에 해당하는 일이 무슨 일인지 하나도 모르겠어요. 어떤 일을 하는지 더 자세한 내용이 없을까요?”

있습니다! 정말로 회사가 원하는 개발자라면 두 팔 벌려 환영한다는 것이 현재 업계 관계자 대다수의 말인데요. 그렇기 때문에 서로의 니즈를 최대한 맞추기 위해서 많은 회사가 채용 공고에 직무 기술서(Job Description)를 공개하는 것은 물론, 자사 개발자가 어떻게 근무하고 있는지도 공개하는 경우가 많습니다.

아래 이미지는 제가 지원한 직군의 채용 공고입니다.

LINE 서버 플랫폼 개발 채용 공고

담당 업무와 자격 요건이 쓰여 있습니다. 무언가 내용이 쓰여 있긴 한데, 너무 광범위한 것 같습니다. 무슨 일을 하게 될 지 상상하기 어렵습니다. 이것만 보고 무슨 일을 할지 5가지 이상 상세하게 작성할 수 있나요? 대단합니다. 그렇다면 이 글을 쓰고 있는 저보다 이직에 성공할 확률이 더 높다고 할 수 있습니다.

저는 잘 알지 못했습니다. 그래서 채용 공고를 기준으로 이곳에서 일하는 분들이 남긴 블로그나 글을 찾기 시작했습니다. 다행히 현재 직장인 LINE에서 운영하는 엔지니어링 블로그에서 내부 개발자가 어떻게 일을 하고 있는지 소개하는 글을 볼 수 있었습니다. 이런 글을 통해 간접적으로 직무와 연관된 내용을 파악할 수 있었습니다.

이직을 하기 전에 제가 옮기고자 하는 파트의 직무 내용을 파악함으로써 제가 원했던 직무가 정말로 이 채용 공고에서 말하는 것인지 파악할 수 있습니다. 회사의 니즈가 아닌 나의 니즈에 맞추는 것입니다. 또 경력 기술서, 자기소개서, 포트폴리오를 해당 직무에 더 맞게 구성하는 데에도 도움이 됩니다. 이직할 때 가장 많이 하는 실수 중 하나는 신입 사원으로 지원했을 때의 습관을 버리지 못한다는 점입니다. 신입사원은 대부분 직무 내용을 정확하게 모르는 상황에서 시작합니다. 회사 입장에서도 직무 연관성 항목에서 경력 이직만큼 높은 기대를 하지 않습니다. 직무와 관련된 전공의 기본만 갖추고 있다면 대부분 합격점을 부여합니다.

하지만 경력 이직은 다릅니다. 따라서 경력 이직은 신입 때와 같이 한 번에 10~20개 회사에 동시 지원하기보다는, 직장을 하나하나 뜯어보고 지원해야 합니다. 회사에서도 이전 직장에서 무엇을 했는지, 이 직무를 얼마나 알아보고 지원했는지 기대합니다. 또한 많은 회사가 경력직에게는 온보딩 기간(새로운 직무에 적응하는 기간)을 넉넉하게 제공하지 않습니다. 하나하나 가르쳐 주지도 않습니다. 경력직은 그런 상황에서 업무에 적응해야 합니다. 명심합시다. 경력직입니다. 하나부터 열까지 가르쳐야 하는 신입이 아닙니다(물론 입사 후 기본적으로 같이 일하는 문화나 규범은 또 하나부터 열까지 배워야 합니다). 모든 과정에서 배움을 찾아 내 것으로 만들어야 하고, 인맥과 정보를 최대한 동원해 지식을 습득해야 합니다. 그렇게 습득한 지식이 지원 서류에서, 면접 과정 답변에서 자신감 있게 드러나야 합니다.

 

보기만 해도 졸린 강의 자료 다시 펼치기

이제 이직을 위한 마음을 다잡았으니, 고통스러운 첫 관문으로 안내하겠습니다. 이 글을 읽는 대부분의 독자가 CS(Computer Science) 계열로의 이직을 생각하고 있다고 가정합시다. 경험이 일천한 저도 이직 조언을 구하는 지인에게 강조하는 부분이 있으니, 바로 CS 기본 지식입니다. 놀라지 마세요. 실리콘밸리에서 많은 사람이 읽는 책인 ‘코딩 인터뷰 완전 분석(게일 라크만 저)’도 상당 부분이 CS 기본 지식에 관한 내용입니다. 우리가 그토록 힘겹게 잠을 이겨내 가며 공부했던(물론 즐겁게 공부한 시절이라고 아름답게 포장합니다) 자료구조, 알고리즘, 프로그래밍 언어, 소프트웨어 설계, 운영체제, 선형 대수, 데이터베이스 등의 주요 과목을 다시 공부해야 합니다. 한 번 배운 내용이니 다시 살펴보는 과정은 매우 쉬울 것입니다. 하나하나 씹고 뜯고 맛보고 즐기면 좋겠지만, 전체적인 내용을 파악하는 위주로 살펴봅시다.

실제로 신입 개발자 지망생 시절, 수차례 면접을 진행한 이후 따로 면접관과 이야기를 나눴는데요. CS 전공 지식이 가장 중요하며 이는 경력 면접자도 쉽게 간과하는 부분이라고 말했습니다. 수년 경력을 지닌 경력자가 스택과 큐의 차이점을 설명할 수도 없다면 무엇을 믿고 그 사람에게 일을 맡길 수 있을까요? 모든 고급 개발 지식과 업무의 기본 근간은 알게 모르게 우리가 배웠던 CS 기본 지식으로 연결됩니다. 그동안 많은 책에서 읽어 왔듯이 스택과 큐를 직접 구현할 일은 실무에서는 거의 없습니다(우리보다 100만 배 똑똑한 개발자가 이미 만들었습니다. 심지어 내부 유틸 함수까지도…). 하지만 구현하려는 코드에 어떤 자료구조가 알맞은지, 특정 요청의 TPS(Transaction Per Second)를 산정해야 하는 상황에서 제 성능을 내려면 어떤 알고리즘이나 자료구조를 선택해야 하는지에 관한 의사 결정은 CS 기본기에서 나온다고 해도 과언이 아닙니다. 실제로 회사 동료가 이런 탄탄한 기본기를 바탕으로 한 줄 한 줄 작성한 코드와, 코드 리뷰하면서 남긴 코멘트를 보면 그 내공이 매우 감탄스럽습니다.

이런 이야기를 들으면 그 많은 내용을 언제 다 공부할 수 있을지 한숨부터 나올 것입니다. 저도 그랬으니 말입니다. 자료구조는 또 언제 다 정리하며, CS 이론은 어느 세월에 챙겨볼 수 있냐는 말입니다. 취업 준비생처럼 하루 종일 시간이 있는 것도 아니라서 하루에 두어 시간씩 짬을 내어 카페에 앉아서 마냥 보고 있을 수도 없으니까요.

개발자에게는 유명한 격언인데요. “내가 코딩을 하며 고민하고 있는 내용은 누군가가 이미 고민해 봤던 내용이다”라는 말이 있습니다. 이를 약간 변형해 보면, “내가 면접을 준비하며 겪고 있는 고통은 누군가가 이미 겪었던 고통이다”가 될 수 있겠죠? 공유의 덕목을 갖춘 개발자에게는 무엇이든 공유하는 습관이 있으니 누군가 공유해 놓은 것을 참고합시다. 앞서 소개했던 ‘코딩 인터뷰 완전 분석’도 좋은 레퍼런스 서적이 될 수 있고, 검색 사이트에서 ‘개발자 면접 준비 책’이라고 검색하면 수많은 결과가 나오기도 합니다. 이 방대한 양을 적절히 선별해서 공부하는 것은 우리의 몫입니다. 한 가지 팁이 있다면, 여러 곳에서 동일하게 언급하는 항목이 있다면 그 부분은 정말 기본 중의 기본이라는 사실을 잊지 말라는 것입니다. 예를 들어, Java 개발자 질문 중에 가비지 컬렉션에 관한 내용이 정말 많이 등장한다면, ‘높은 확률로 면접이나 필기시험 문제에 가비지 컬렉션이 나오지 않을까?’하고 생각해야 합니다.

 

개발자 이직의 필수 항목, 포트폴리오 준비하기

포트폴리오는 중요합니다. 경력 기술서(이력서)에 우리가 무엇을 했는지를 간략하게 기술했다면, 포트폴리오는 경력 기술서에 기술한 내용의 실체를 표현하는 공간입니다. 더불어 우리가 무엇을 했는지, 어떻게 했는지, 왜 그랬는지 면접관이 가늠해 볼 수 있는 자료가 됩니다. 포트폴리오에 담을 자료는 너무 많아도 안 되고 너무 적어도 안 됩니다.

다시 채용 페이지로 돌아가서 지원하고자 하는 직군에서 원하는 자격 요건과 직무, 우대 사항을 살펴봅시다. 그 내용에 맞추어 포트폴리오를 구성하면 됩니다. 예를 들어, 위 채용 공고 중 ‘Data structure, Algorithm, Network 등의 전산 기본 지식을 이해하고 활용할 수 있는 자’라는 항목을 봅시다. 너무 어렵습니다. 내가 이런 CS 기본 지식을 잘 갖추고 있다는 것을 포트폴리오에 어떻게 드러낼 수 있을까요?

그래서 프로젝트가 필요합니다. 학교 전공 과목을 수강할 때도 수업에서 배운 내용을 바탕으로 텀 프로젝트를 진행합니다. 교수님(이라 쓰고 대부분 박사 조교라 읽는다)의 피와 땀과 눈물이 함께 들어 있는 텀 프로젝트는 해당 과목의 핵심 지식이 충분히 섞여 있을 가능성이 높습니다. 또한 그러한 핵심 지식은 면접관도 궁금해 할 확률이 높습니다. 이러한 텀 프로젝트와 비슷한 성격을 가진 내용물을 하나하나 자격 요건에 매칭해 포트폴리오를 만들면 됩니다. 하지만 경력 직군의 포트폴리오에 학부 시절, 혹은 대학원 시절에 수행했던 프로젝트를 넣는다면 식상할 수 있겠죠? 이직 지원서를 내는 시점에서 5년 이상 지난 내용은 넣지 않는 것이 좋습니다. 시간이 너무 오래 경과하기도 했고, 경력 개발자가 아직도 학부 시절의 프로젝트를 주 프로젝트로 내세우고 있다는 사실은 높게 평가하기 어렵다고 생각합니다.

그렇다면 어떻게 해야 할까요? 답은 사이드 프로젝트입니다. 사이드 프로젝트를 통해서 직무 요건을 한 번에 만족시킬 수 있습니다. 사이드 프로젝트를 거창한 내용이라고 생각하지 맙시다. 항상 신기술을 접하고 사용해야 하는 개발자에게 사이드 프로젝트는 본인에게 기본기가 있다는 점을 부각할 좋은 기회며, 면접에서 좋은 소재가 될 수 있습니다. 사이드 프로젝트 주제는 어떤 것이든 될 수 있습니다. 회사에서 진행한 일을 회사 동의를 받아 사이드 프로젝트로 발전시킬 수도 있고, 새로운 기술을 배워가며 진행한 내용을 나름의 방식에 맞게 바꿔서 진행한 내용도 사이드 프로젝트가 될 수 있습니다. 중요한 점은 ‘진행한 내용을 잘 정리하고 가능하다면 많은 사람 앞에서 공개하는 연습을 하는 것’입니다. 경력 기술서를 보면, 특정 주제에 대한 언급은 잘 없고 기술에 대한 언급만 존재합니다. 즉, 주제는 어떤 것이든 상관없다는 말입니다.

저는 솔직히 말해서 ‘2018 파이콘 한국’에 튜토리얼 진행을 신청한 가장 큰 목적이 이직이었습니다(이 자리를 빌려 불온한(?) 의도를 갖고 튜토리얼을 신청한 것을 사죄합니다). 튜토리얼 주제로 이전 직장에서 수행했던 프로젝트를 파이썬으로 구현하는 방식으로 발표 제안서를 냈고, 이것이 통과돼 실제로 2018년 8월에 발표했습니다. 그리고 포트폴리오에 넣었습니다. 물론 회사 업무 내용을 콘퍼런스 발표 주제로 삼는다면, 반드시 회사 내부 컴플라이언스 팀이나 홍보 팀에 문의해 내용을 첨삭 받도록 합시다. 업무 기밀이 노출되는 불상사를 미연에 방지할 수 있습니다.

농담이 아닙니다. 진짜로 했습니다!
포트폴리오의 일부분

사이드 프로젝트라고 해서 꼭 처음부터 만들어야 하는 건 아닙니다. 지금 수행하는 작업 내용 일부를 다른 언어나 다른 방식으로 만들어도 보고, 이를 통해 느낀 점을 다른 사람과 나누는 것도 사이드 프로젝트가 될 수 있습니다. 누군가와 나누기 위해서는 주제와 관련된 이론적 배경을 심도 깊게 알아야 합니다. 내 커리어 발전을 꾀하는 이직을 위해 준비한 내용이라 할지라도, 나와 듣는 청중 모두에게 배움의 수단이 될 수 있습니다. 발표하면 실제로 어떤 질문이 들어올지 모르기 때문에 이론적인 내용과 여러 예상 문답을 확실하게 준비해야 합니다. 신기하게도 강연을 들었던 사람이 궁금해 했던 내용을 면접에서 면접관이 동일하게 질문하기도 합니다.

이런 과정을 거침으로써 포트폴리오에 확실한 내용을 추가할 수 있어서 좋고, 튜토리얼을 듣는 사람은 새로운 지식을 알아서 좋고, 우리는 더 깊은 지식을 쌓을 수 있어서 좋습니다. 일석삼조입니다. 하지 않을 이유가 없지 않나요?

 

가깝고도 너무 먼 코딩 테스트 준비하기

코딩 테스트 준비에 관한 글은 이미 인터넷에 아주 많이 있습니다. 똑같은 글을 또 쓸 이유는 없으니 간략하게 작성하겠습니다. 많은 기술 기업에서 코딩 테스트를 진행합니다. 과거 코딩 테스트는(주로 대학생 때) 프로그래밍 경시대회(ACM-ICPC)와 비슷했는데요. 특정 문제를 푸는 알고리즘을 제한 시간 내에 고안하고 테스트 케이스를 통과해 점수를 획득하는 방식이었습니다. 하지만 요즘은 프로젝트에 기반한 문제나 지원자의 설계 능력을 가늠하는 방식의 문제, 혹은 API를 설계하고 테스트하는 문제처럼 코딩 테스트의 스펙트럼이 다양하게 확장되고 있습니다. 

개발자와 코딩 테스트는 애증의 관계입니다. 실질적인 직무와 전혀 상관이 없어 보이는 문제를 단시간 내에 머리를 쥐어 뜯어가며 풀어야 합니다. 취업을 위해서는 해야 하는데, 그렇다고 너무 열심히 하자니 손해보는 것 같습니다. 저는 가끔 이 코딩 테스트를 준비하다가 어느 순간 ‘개발자 이직 = 코딩 테스트’라는 공식이 마음 속에 자리하면서 주객이 전도되는 상황을 맞이하기도 했습니다. 제발 저와 같은 우를 범하지 말기 바랍니다. 코딩 테스트의 목적은 지원자가 코드를 작성할 수 있는 능력이 있는지 없는지 검증하기 위함이라 생각하는데요. 여기서 문제는 ‘코드를 작성할 수 있는 능력’을 회사마다 다르게 정의한다는 것입니다. 회사에서 생각하는 코드를 작성하는 능력의 허들이 높으면 높을수록 문제가 어려워집니다.

이직하려는 회사의 정보를 수집해 보면 코딩 테스트에 대한 정보도 얻을 수 있고, 이직 후기를 검색해 보면 어떤 유형의 문제가 나왔고 체감 난이도는 어땠는지 정도를 엿볼 수 있으니 참고하시기 바랍니다.

 

지인 찬스 활용하기

많은 기술 기업에선 항상 좋은 인재에 목말라합니다. 그래서 여러 기업에서 내부 인력을 통해서 인재를 채용하는 사내 추천 제도를 시행하고 있는데요. 보통 이 제도를 통해 인재를 추천하면 추천한 사람 또한 일정 보상을 받게 되므로 이직하려는 회사에 지인이 재직 중이라면 꼭 이 제도를 활용합시다.

단, 커뮤니티에서 잠깐 마주친 정도로는 지인 추천을 받으려 하지 맙시다. IT 업계는 넓은 것 같지만 상당히 좁습니다. 무리하게 부탁하다가 관계가 소원해 질 수 있습니다. 한 번 보고 말 사이라는 이기적인 생각은 버립시다. 그리고 상대방도 나에 대해 어느 정도는 알고 있어야 제대로 추천해 줄 수 있습니다. 평소에 관계를 잘 만들어 왔는지 점검하는 기회가 될 것입니다. 만약 현재 직장에서 원하는 직장으로 이직한 사람이 있다면, 그분 연락처를 얻어 상담도 받고 준비해서 추천받는 것을 권합니다. 

 

배운 것을 정리하기

이직을 준비할 때 고려해야 할 여러 항목을 살펴봤습니다. 하나하나 만만치 않은 주제입니다. 어느 하나라도 소홀히 한다면 면접에서 허점으로 드러나게 되고, 꼼꼼한 면접관이 그 허점을 파고든다면 곧바로 밑천이 드러날 것입니다.

이직을 준비하면서 잊지 말아야 할 중요한 마음가짐은 이직을 달성함과 동시에 성장이 동반돼야 한다는 점입니다. 이직하고 나서 대학교 중간고사, 기말고사 때 마냥 기껏 공부한 지식을 휘발성 메모리처럼 날려버린다면 무슨 쓸모가 있을까요? 그렇게 되면 우리가 갖춘 지식과 경험을 믿고 뽑았던 상급자나 동료는 무슨 생각이 들까요? 그 과정에서 소비한 시간은요?

그러니 항상 배운 것을 정리하는 습관을 지닙시다. 또한 정리했다면 꼭 블로그나 마이크로소프트웨어에 기고하는 것처럼 족적을 남겨야 합니다. 시간이 지나서 부끄러운 마음이 들어 고치는 경우가 있더라도 남겨야 합니다. 배운 것과 공부한 것을 정리하는 습관은 학습 내용의 핵심을 다시 한 번 정리하면서, 동시에 다른 사람과 공유할 수 있다는 이점이 있습니다. 체크 포인트를 찍는 과정이라고 생각합시다. 이 과정을 반복하면 학습 주기도 점차 짧게 줄일 수 있습니다.

운영 중인 블로그(junojunho.me)

이렇게 한번 정리해 두면 같은 내용을 또 공부할 때 쉽게 기억해 낼 수 있습니다.

 

이직을 준비하며 새로운 직장 외에 얻은 것들

이직에 성공했나요? 축하합니다. 이제 새로운 주인 아래에서 일하는 노예가 됐습니다(도비는 영원히 자유로울 수 없다!). 농담입니다. 새로운 직장에서 성공적으로 업무를 수행하기를 기원합니다. 이직을 준비하면서 지금까지 배운 지식을 정리하고 포트폴리오를 정리했다면, 그것만으로도 기억 저편에 흩어져 있던 기억 조각을 모아서 하나의 보석으로 만들어 낸 것입니다. 이직이라는 목표를 가지고 한 단계씩 학습한 것입니다. 만약 저와 같은 학습 곡선을 그렸다면, 새로운 직장 합격 여부를 떠나서 다음과 같은 성과를 얻었을 것으로 생각합니다.

 

더욱 강력해진 기본기

저는 항상 CS 기본기에 자신감이 있었습니다. 하지만 신입 공채라는 큰 관문을 겪으며 그 자신감이 산산이 부서졌습니다. 나름 전공 과목 학점도 상위권으로 잘 받았고 내용을 잘 이해하고 있다고 자부심을 가졌지만, 이론으로 뽐낼 수 있는 내용과 실무에서 필요로 하는 기본기가 다름을 절감한 순간이었습니다.

고맙게도 첫 직장에서 나에게 일할 기회를 제공해 주었고, 정말 최선을 다해 업무 경험을 쌓았습니다. 그리고 현재 재직 중인, 처음부터 일해보고 싶었던 직장에 재도전했습니다. 신입 공채 탈락이라는 아픔이 있었기에 더욱 열심히 준비했습니다. 강의 자료를 한 장 한 장 다시 살펴보며 세세한 부분도 놓치지 않으려고 부단히 노력했습니다. 이직 후 시간이 지난 지금, 한창 준비할 때처럼 대답하라면 하지 못할 것 같습니다. 하지만 업무 중 의사를 결정해야 하는 순간에 제가 공부했던 것을 떠올리면 직관적인 의사 결정에 도움이 된다는 점은 부인할 수 없는 사실입니다. 아래는 제가 면접을 준비하면서 정리했던 내용입니다. 이직을 준비할 때 여자친구보다 이 노트를 더 많이 본 것 같습니다.

 

업데이트되면서 더욱 정제된 이력서

만약 예전에 써둔 이력서가 있다면 이번 기회에 새로 작성했거나 업데이트한 이력서와 비교해 봅시다. 당연히 새로 업데이트한 이력서가 더 좋을 것입니다. 이력서를 점검하고 업데이트하는 작업은 마치 게임할 때 저장하는 것과 같고, 스냅샷을 찍는 것과 같습니다. 가장 최신의 나를 기록하는 방법이지 않을까요!

다양한 이력서를 참고하여 완성한 이력서

 

단단해진 나의 포트폴리오

포트폴리오 또한 이력서와 마찬가지로 업데이트되었을 것입니다. 포인트는 포트폴리오 내용이 각자 커리어에 맞춰졌다는 점입니다. 신입 때 썼던 포트폴리오는 넓고 얕은 내용이었다면, 경력 지원을 거치면서 커리어 패스에 맞도록 재구성됐습니다. 재구성한 포트폴리오는 앞으로 우리의 커리어를 이어나갈 방향을 제시할 것입니다. 제가 파이콘 한국에서 발표했던 주제인 ‘JWT를 파이썬으로 구현한 공통 인증 인가 라이브러리 개발’에 관한 주제는 인증 서버 구현에 대한 내용으로 가지를 뻗을 수도 있고, 마이크로 서비스 쪽으로 갈래를 잡을 수도 있습니다. 한번 시작점을 구축하면 이후 확장은 무궁무진합니다. 하나씩 확장하면서 직장에서의 커리어 발전뿐 아니라 개인 역량 개발도 함께 진행할 수 있습니다.

곰곰이 생각해보면 이직을 위해 필요한 내용은 우리가 개발자로 살아남기 위해 끊임없이 노력해야 할 내용이기도 합니다. CS 지식은 고전과 같습니다. 우리가 단단하게 쌓아나가야 할, 꼭 필요한 자양분입니다. 또한 포트폴리오와 경력 기술서는 졸업 앨범처럼 한 번 보고 고풍스러운 라면 받침대로 사용하는 문서가 아닙니다. 항상 새롭게 업데이트해야 하는 문서입니다.

 

마치며

이직은 어떻게 준비하고 실행하느냐에 따라 건강한 성장으로 이어질 수 있습니다. IT 업계는 다른 업계와 비교해 상대적으로 이직이라는 개념을 새로운 출발이라는, 좀 더 긍정적인 의미로 받아들이고 있습니다. 만약 지금 이직을 고려하고 있다면, 잘 준비하여 새로운 성장 동력원으로 삼게 되시길 바라겠습니다.