개발자스럽지 않은 개발자의 개발 커리어 이야기 | (1)개발자 취준생에게 전하는 경험과 조언


안녕하세요, 4년차 Front-end 개발자 김테디라고 합니다.

인디스워크와는 “주니어 프론트엔드 개발자의 취업과 커리어” 라는 인터뷰 영상을 촬영한 이후로 두 번째 만남이네요.

지난 인터뷰 영상을 촬영할 때에 취업과 관련해 간략하게 몇 가지 이야기를 전달 드렸었는데,

최근 채용 시장이 얼어 붙으면서 취업과 이직, 그리고 커리어를 어떻게 쌓아가는 게 좋을 지 고민하는 신입, 주니어 개발자 분들이 많은 것 같아요.

그래서 저도 아직 실력적으로 많이 부족하지만 어떤 마음가짐을 갖고 어떻게 준비하는 게 좋을 지 제가 가지고 있는 팁들을 공유 드리고자

제 개인 기술 블로그에 “개발자스럽지 않은 개발자의 커리어 이야기” 라는 제목의 글을 작성했습니다.

제 글이 취업을 준비하는 개발 꿈나무 분들부터 주니어 개발자 분들이 커리어를 발전시켜 나가는 방향성을 정하는 데 있어

조금이나마 도움이 되길 바라며, 궁금하신 점은 언제든 기술 블로그를 통해 문의 주시면 감사하겠습니다!


Prologue
안녕하세요, 4년차 Front-end 개발자 김만수 (Teddy) 입니다 🧸
 
지금 이 글을 작성하는 순간에도 제가 주니어 개발자, 그리고 개발자를 꿈꾸는 취준생 분들께 조언을 드려도 되는가에 대해 고민과 걱정이 많이 드는 것 같습니다. 가장 큰 이유는 개발자 커리어를 시작하게 된 순간부터 커리어 도중 있었던 수많은 직무 변경, 그리고 2년차에 맡게 된 파트 리드, 이직 과정까지 일반적인 개발자 분들과는 많이 다른 길을 걸어왔기 때문이에요. 또한, 글의 제목에도 나와 있듯이 저는 “개발자스럽지 않은 개발자” 라는 다소 특이한 캐릭터로 개발자 커리어를 쌓아 왔습니다. 덕분에 개발에 별로 재능이 없는 제가 취업에 성공하고 함께 했던 동료 분들께 개발자로서 좋은 평가를 받을 수 있었지만, 한편으로는 대다수의 분들이 공감하고 참고하실 수 있는 일반적인 경험과 조언이 아닐 수 있겠다는 생각이 머릿속을 계속 맴돌았습니다.
 
그래서 저는 이 글을 읽어 주시는 분들께서 ‘이렇게도 신입 개발자로 취업할 수 있구나’, ‘이렇게 다이내믹하게 커리어가 뒤바뀐 사람도 있는데 나는 나름 괜찮은 상황이었구나(?)’ 와 같이 일반적이지 않은 저의 경험들을 보시고 새로운 관점과 인사이트를, 그리고 조금이나마 용기를 얻어 가실 수 있으면 좋겠다는 바람과 함께 글을 써 내려가 보려 합니다.
 
본격적으로 글을 시작하기에 앞서, 이 글이 도움이 될 수 있는 분들은 다음과 같습니다.
•    IT 스타트업을 포함해 기술 중심의 기업을 목표로 준비하고 있는 개발자 취준생 분들
•    성공적으로 취업은 해내었지만, 주니어 개발자로서 어떻게 커리어를 발전시켜 나가야 할지 고민 중인 신입 개발자 분들
•    유행하는 기술 스택에 조금 뒤떨어져 있는 레거시 기술 스택을 활용하고 있어 트렌디한 IT 서비스 기업으로 이직이 힘들지 않을까 걱정하는 주니어 개발자



 
개발자 취업을 준비하는 꿈나무 분들께 전하는 경험과 조언



저는 2020년 7월에 대학교 3학년 1학기가 끝나자마자 개발자 커리어를 시작했습니다. 뭔가 이상하죠? 제 일반적이지 않은 커리어는 시작부터 특이했습니다. 보통 4년제 대학교를 다니면 빨라야 4학년 2학기부터 취업계를 제출하고 회사 생활을 시작하게 되는데, 저는 산업기능요원 (병무청에서 지정한 업체에서 일정 기간 동안 재직하는 형식의 대체복무) 이라는 기회를 노리고 있었기 때문에 남들보다 일찍 취업을 준비해야 했습니다.
 
산업기능요원으로 복무가 가능한 업체는 대다수가 IT 스타트업, 중소 SI 기업입니다. 따라서 저도 IT 스타트업을 위주로 2학년 때부터 취업을 준비하기 시작했습니다. 여기서 몇 가지 문제를 마주하게 되는데요. 우선 가장 큰 문제는 산업기능요원은 S/W 관련 전공 2년 이상 재학 후 지원이 가능했습니다. 즉, 3학년 1학기가 끝나는 시점에 기업에 지원했던 저는 모든 지원자 중 가장 나이와 학년 모두 가장 낮을 확률이 컸습니다.
 
사실 나이, 학년 ∝ 실력은 절대 아닙니다. 어느 분야든 나이, 학년과 관계없이 엄청난 재능과 퍼포먼스를 보여주는 천재 분들은 꼭 있습니다. 문제는 제가 그 천재에 해당하지 않는다는 것, 그리고 “산업기능요원”을 “신입”으로 채용하는 “괜찮은 IT 스타트업”은 정말 적다는 것이었습니다. 나름 이른 시점인 2학년부터 취준을 염두에 두고 다양한 활동과 프로젝트를 해 왔지만, 산업기능요원을 위해 휴학하며 준비해 온 분들과 4학년, 졸업생 분들 사이에서 경쟁해야 했던 것이죠.
 
즉, 저는 개발 실력이 부족해도 채용 담당자의 눈을 사로잡을 만한 저만의 무기가 필요했습니다.



 
제가 3학년 1학기까지 했던 활동은 다음과 같았습니다.

•    멋쟁이사자처럼 🦁 – 대학교 연합 프로그래밍 교육 단체
•    8기 전체 대표 (대학생 Community Manager) & 명지대(서울) 대표 운영진
•    8기 공식 Django 온라인 강의 기획 및 촬영
•    명지대(서울) 8기 지원 사이트 자체 개발 참여
•    명지대학교 인문캠퍼스 19년도 축제 공식 홈페이지 개발 참여
•    교내 창업경진대회 우수상 수상 (팀장, 발표 담당)
•    Java 기반 프로젝트 개발
•    JavaFX를 활용해 MVC 패턴 기반 교내 수강 신청 프로그램 구현
•    Swing을 활용해 Window 운영체제의 그림판 클론 코딩
•    RPA – UiPath 기반으로 업무 프로세스 자동화 프로그램 구현
•    명지대학교 입학처, 서울시 산하 공공기관에서 전공 강연, 멘토링 진행


 
하단에서 언급하겠지만, 같은 활동을 하더라도 자신의 캐릭터와 어떻게 연계하고 어필하는 지에 따라 채용 담당자에게 느껴지는 임팩트는 천차만별로 차이가 날 수 있다고 생각합니다. 저는 지원자들 사이에서 기술적인 부분은 눈에 띄기 어렵겠다고 판단했고, “현실 세계의 문제를 기술로서 풀어낼 줄 아는 신입 개발자” 라는 캐릭터로 잡아 제너럴리스트이면서 프로그램의 근본적인 기반 개념들을 이해하고 있어 유연하게 다른 언어와 기술들도 빠르게 학습할 수 있는 신입으로 어필하는 것을 전략으로 세웠습니다. 제가 여러 언어와 프레임워크를 활용해 단순한 클론 코딩, 사이드 프로젝트가 아닌 실제 우리 주위에 있는 문제들을 해결해 멋쟁이사자처럼 소속 학생들과 교내 구성원들에게 배포했던 일련의 활동들이 제가 갖고 있던 근거였죠.
 
사실 나름대로의 근거를 가지고 만들었던 전략이었지만, 당시에 취업에 바로 성공할 수 있을 것이란 기대는 전혀 없었습니다. 다른 분들은 얼마나 개발을 잘 할 수 있는지에 대해 화려한 프로젝트와 지식으로 어필하시는 사이에 저는 개발적인 어필을 할 수 있는 부분이 많이 없다고 느꼈기 때문이에요. 하지만, 방학이 시작하기 직전에 유명 데이팅 어플을 서비스하고 있는 스타트업과 구로에 있던 SI 기업의 공고가 올라왔고 호기심에 지원했더니 둘 다 서류 합격 후 면접까지 통과해 얼떨떨해 했고, 데이팅 어플 스타트업에 최종 합격하게 되었습니다.
 
나중에 문득 궁금해져 저를 채용해주신 팀장님께 제가 지원했을 때의 경쟁률이 어땠는지 물어보았을 때, ‘8대 1’ 이었다는 답변을 주셨습니다. (산업기능요원 – 보충역만 지원 가능했던 공고) 듣고 놀라서 어떤 점 때문에 저를 채용하신 건지 여쭤 봤더니, 업무 적응 속도가 빠를 것 같았고 언어와 기술에 매몰되는 게 아니라 도구로 보고 여러 비즈니스 문제를 잘 정제해서 해결해 나간 게 인상 깊었다고 하셨습니다. 신입이기 때문에 기술적인 부분은 온보딩 과정 동안 교육을 할 계획을 사전에 세워 두셨고, 중요한 건 비즈니스를 잘 분석해서 기술로 구현하는 것인데 이 부분을 적극적으로 어필한 제가 좋은 점수를 받았던 것이었습니다. 개발자 커리어에 있어 첫 번째로 마주한 행운이 바로 팀장님을 비롯해 첫 회사에서 좋은 리더 분들을 만난 것이었습니다.
 
이렇게 제가 신입 개발자로 취업을 준비하며 배웠던 점들과 함께 현재 채용 담당자로 채용에 참여하면서 느낀 부분들을 종합하여 개발자 취업을 준비하는 꿈나무 분들께 몇 가지 조언을 드려 보고자 합니다.


나를 어떻게 PR 할 건지 전략을 세우고 그에 맞춰 세부적인 전략들을 준비하자
이건 개발자 뿐만 아니라 모든 직군에 공통적으로 해당되는 부분이라고 생각합니다. 어쩌면 제가 개발적인 실력이 뛰어나지 않았음에도 취업에 바로 성공할 수 있었던 핵심적인 포인트이자, 지금 제가 서류를 평가하거나 인터뷰(면접)에서 지원자 분을 평가할 때 중요하게 보는 포인트 중 하나라고 생각합니다.
 
자신의 강점과 역량, 그리고 가치를 잘 드러내는 ‘캐릭터’를 설정하는 것은 매우 중요합니다. 캐릭터는 단순히 본인의 역량을 설명하는 것 이상의 역할을 합니다. 본인의 경험과 지식, 그리고 가치를 일관된 스토리로 연결해주며, 이것이 바로 면접관들에게 본인을 기억시키는 데 크게 도움이 됩니다.
 
그리고 이러한 ‘캐릭터’ 설정은 면접 준비 과정에서도 큰 도움이 됩니다. 자신의 캐릭터와 일치하는 방식으로 답변들을 미리 구성해보면, 실제 면접 상황에서도 훨씬 수월하게 대응할 수 있습니다. 예를 들어서, 만약 본인이 ‘기획자가 좋아하는 개발자’라는 캐릭터를 설정했다면, 면접에서도 답변을 구성할 때 단순히 기술적인 부분만 어필하는 게 아니라 기획자를 포함한 타 직군 분들도 이해하기 쉽게 풀어서 대답하거나 기획적인 대안을 제시하는 등의 전략을 세울 수 있습니다.


프로젝트는 규모가 작더라도 직접 기획하고 개발해보고 성과를 측정해보자
요즘 신입 지원자 분들의 이력서, 포트폴리오를 보면 Slack, 카카오톡을 포함해 다양한 서비스의 클론 코딩 프로젝트가 많이 기재되어 있습니다. 클론 코딩이 나쁜 건 절대 아닙니다! 몇 십, 몇 백 명의 프로 개발자가 협업해서 만든 서비스에 얼마나 복잡한 UI와 기능들이 구현되어 있겠어요. 이러한 서비스를 누군가의 도움 없이 혼자 비슷하게 구현했다면 정말 본인의 실력을 어필하기 좋은 수단이 될 겁니다. 하지만, 단순히 특정 클론 코딩 강의를 따라가면서 그대로 따라 친 프로젝트를 기재하는 건 서류 평가 담당자와 면접관에게 좋지 않은 영향을 줄 확률이 큽니다.
 
그래서 저는 클론 코딩 보다는, 우리 주위의 작더라도 불편하거나 개선하면 좋을 것 같은 문제 상황에 대해 직접 요구 사항을 정의하고 기술로 구현해 보는 프로젝트를 진행해 보는 걸 추천하는 편입니다. 개발자가 필요한 이유 중 하나는 정형화되어 있지 않은 현실 세계의 문제를 기술로 구현하기 위해 정형화 할 수 있기 때문입니다. 우리 주위의 작은 문제와 회사에서 서비스하고 있는 프로젝트에 새로운 기능을 추가하는 일도 크게 보면 “현실 세계의 문제를 기술적으로 정제해 구현한다” 라는 큰 맥락 안에 있다고 볼 수 있어요.
 
물론 정말 어렵고 많이 고생할 확률이 큽니다. 우리 주위의 문제 상황을 인식한 후에 어떻게 해결할 것인지 아이디어를 도출해야 하고, 무에서 유를 창조하면서 기능적인 플로우나 UI를 모두 창조해야 하기 때문이에요. 개발자 취업을 준비하다 어느 순간 창업을 준비하는 느낌이 들 수도 있습니다. 평소에 이미 정제되어 있는 코드를 기반으로 진행하는 강의를 보면서 따라하는 프로젝트와는 달리, 직접 구조부터 세부적인 로직을 구현하다 보면 당연히 알고 있다고 생각했던 코드도 잘 안 쳐지고 에러를 뿜어내기 시작합니다. 강의에서 전달하는 지식은 강의자에게 맞춰 정제된 지식일 뿐, 일방향으로 전달받는 우리에게 정제된 지식이 아니기 때문이에요. 다른 사람에 맞춰 정제된 지식을 나에게 맞춰 정제하는 과정이 필요하고, 이러한 과정은 직접 나에게 필요한 코드를 작성하는 고통 속에 이루어집니다.
 
이렇게 서비스를 구현하고 실제로 배포하게 되면 여러분은 새로운 서비스를 세상에 출시하게 된 겁니다. 여기까지만 성공해도 정말 소중한 경험과 배움을 얻은 것이지만, 조금 더 나아가서 GA(Google Analytics) 와 같은 분석 툴, 플랫폼을 연동해 성과를 측정하는 것도 추천합니다. 내가 만든 서비스와 기술이 얼마나 많은 사람들에게 영향을 줬고, 연령대, 유입 경로 등을 분석해 개선하면 좋을 부분들을 찾아 서비스를 발전시킬 수 있습니다. 라이브 중에 유저들로부터 예상치 못한 이슈나 개선되면 좋을 부분들에 대한 VoC(Voice Of Customer) 를 받을 수도 있어요.
 
이런 모든 과정이 회사에서 프로덕트를 만들고 발전시켜 나가는 프로세스와 똑같습니다. 직접 해 본 사람과 그저 글과 강의로만 접한 사람은 정말 큰 차이를 보입니다.


에러를 마주했을 때 최대한 파고 들어가자. 정답이 아니더라도 도움이 된다
코드를 치다가 마주하게 되는 빨간 줄, 런타임에서 예상치 못하게 발생하는 에러 (ex. Uncaught TypeError: x is not a function) 는 우리의 머리를 지끈거리게 만드는 주범입니다. 우리가 이 때 선택할 수 있는 선택지는 크게 3가지입니다. 1) 잘하는 사람을 찾아가거나, 2) 구글에 검색하거나,  3) StackTrace를 차근차근 분석해 나가는 거죠.
 
1, 2, 3번의 순서대로 나에게 오는 고통도 커지고 문제를 해결하는 데 소요되는 시간도 기하급수적으로 늘어날 확률이 큽니다. 하지만, 알 수 없는 에러 로그들 속에는 다양한 정보들이 숨겨져 있습니다. 에러 로그는 실제 문제가 일어난 부분부터 Stack 형식으로 차곡차곡 쌓이는데, 대부분 어떤 파일의 몇 번째 줄에서 문제가 났는지 친절하게 가이드 해 줍니다. 사람이 작성한 코드 뿐만 아니라 내부 엔진의 로그까지 모두 포함해서 말이죠. 따라서, 에러 로그를 분석하고 핸들링 해 보면서 우리가 활용하고 있는 기술의 내부 구조도 조금씩 탐구해 볼 수 있고 에러가 발생한 부분을 하나씩 대응해 보면서 경험치를 차곡차곡 쌓을 수 있습니다. 대응하려고 수정 했다가 또 다른 문제를 마주할 수 있습니다. 이런 잘못된 접근도 어떤 부분이 문제였고 어떻게 다른 방식으로 대응했는지 기록을 해 나가다 보면 향후 개발할 때 분명 도움이 될 겁니다.
 
구글링을 통해 정답을 찾아가는 것도 좋은 방법입니다. 단, 구글링을 할 때 검색에 활용하는 키워드를 어떻게 써야 효율적으로 내가 원하는 정답을 찾을 수 있을 지 한 번씩 고민해 보시는 걸 추천 드립니다. 같은 현상을 보고도 각자 가지고 있는 경험과 지식이 다르기 때문에 자신이 모르거나 놓친 부분 또한 다릅니다. 구글링을 효율적으로 많이 해 볼 수록 내가 원하는 결과값을 빠르게 추출할 수 있는 검색어를 자동으로 떠올리게 됩니다.
 

모르는 건 확실하게 모른다고 답변하자. 대신 최대한 답에 근접하기 위해 노력해보자
개발에 천부적인 재능과 센스를 가지고 있는 정말 몇 없는 천재(?) 개발자 분들을 제외하면, 대부분의 신입, 주니어 개발자 분들은 경험과 지식이 많지 않습니다. 하지만, 우리를 평가하는 면접관, 채용 담당자들은 우리보다 몇 년은 더 해당 업무, 직군에 대해 필드에서 일을 하고 경험을 쌓았습니다.
 
대부분의 신입 분들은 직군에 대해 강의 등을 통해 공부하면서 얻은 지식과 함께 취업을 준비하던 동기들과 진행한 사이드 프로젝트 등이 경험의 전부입니다. 그렇기 때문에 특정 기술에 대해 딥다이브 해 본 경험이나 프로젝트에서 어떤 방법이 더 나을지, 특정 장애 상황에 대해 어떻게 대처하면 좋을지에 대한 질문이 들어오면 대답을 못하는 경우가 대다수입니다.
 
면접관 또한 대답하지 못할 것이라고 예상하고 질문을 하는 경우가 대다수입니다. 여기서 답을 맞추면 최고의 시나리오겠지만, 정확하게 답을 모르겠더라도 최대한 본인만의 근거를 기반으로 답을 추론해 나가는 모습을 보여주는 것이 좋습니다. 추론해 나가면서 답을 맞추는 과정을 통해 면접관은
1.    지원자가 전혀 접근도 못 하진 않고, 어디까지 지식은 잡혀 있구나 파악할 수 있고,
2.    섣불리 포기하는 타입은 아니구나 라는 조금이나마 좋은 인상을 남길 수 있고,
3.    가끔 좋은 면접관 분들을 만나게 되면 추론 과정이 타당할 경우, 조금씩 힌트를 주며 답으로 유도를 해 주시기도 하기 때문입니다.
 
저도 신입으로 취업할 때, 그리고 경력직으로 이직할 때 어려운 기술 질문을 많이 받았었어요. 질문을 받고 나서 머리가 새하얘졌지만, 최대한 제가 갖고 있는 지식과 경험을 활용하여 답을 추론해 나갔었습니다. 지금 제가 재직 중인 회사 또한 기술 인터뷰 당시 답이 가늠이 되지 않는 질문을 많이 받아서 당연히 떨어졌을거라 생각했는데 합격 통보를 받았었고, 추론해 나가는 과정이 인상 깊고 실제로 답에 어느 정도 근접했기 때문에 좋은 점수를 받았다는 피드백을 받았어요.



 
이력서는 Notion / 로켓펀치 / 링크드인으로 구성하면 효율적이다



대부분의 IT 스타트업이나 서비스 기업은 자유 형식의 이력서, 포트폴리오를 서류 전형에 제출합니다. 신입 분들의 경우 이력서의 내용을 어떻게 구성할지도 어렵지만, 이력서 형식이나 폼을 어떻게 구성해야 하는지에 대해서도 감을 잡기 어려우실 것이라 생각됩니다.
 
“이력서 양식”이라고 검색하면 나오는 채용 플랫폼의 Word, 한글 기반 이력서 양식 등이 제일 먼저 나와서 해당 파일을 다운로드 받아 꾸며서 제출하시는 분들을 채용 과정에서 많이 봤는데요. Word로 만드는 게 잘못된 건 절대 아닙니다! Notion, 로켓펀치, 링크드인으로 이력서를 구성하는 걸 추천드리는 이유는 이력서를 깔끔하게 만드는 데 있어 효율적이고 향후 네트워킹을 위한 프로필까지 한 번에 구성할 수 있기 때문입니다.
 
우선 Notion의 경우, 개발자 이력서 템플릿을 구글에 검색하면 깔끔하게 만들어져 있는 템플릿을 손쉽게 구해 개인적인 내용만 수정해서 빠르게 활용할 수 있습니다. PDF Export와 함께 누구든 URL로 접근할 수 있는 Web Publishing 기능도 제공하기 때문에 PDF와 웹사이트 버전 이력서를 동시에 제작할 수 있습니다.
 
링크드인과 로켓펀치의 경우, 프로필에 내가 재직 중인 회사, 활동했던 단체를 기록하고 세부적으로 어떤 활동을 했는지, 어떤 기술 스택을 활용했었는지 한 번에 편하게 작성할 수 있습니다. 그리고 프로필에 작성한 내용들을 각 플랫폼의 이력서 템플릿에 맞춰 자동으로 이력서로 구성해 Export 하는 기능을 제공합니다.
 
개발자의 니즈에 맞춰 타 플랫폼에 비해 커스터마이징 되어 있는 프로필 작성 기능을 토대로 이력서를 편하게 작성, 관리하고 향후 해당 플랫폼을 업데이트 하며 개발 커뮤니티에서 네트워킹도 가능하기 때문에 저는 링크드인, 로켓펀치를 활용한 이력서 관리를 추천드립니다.
(혹시나 싶어 적어놓자면, 저는 저 세 곳의 업체와 어떠한 관계도 없습니다)


 
채용 공고의 자격 요건에 조금 부족하더라도 일단 지원해보자
항상 내 눈에 띄는 공고는 읽어 내려가다 보면 자격 요건의 최소 경력 연차나 필요로 하는 특정 기술 스택이 맞지 않는 경우가 많습니다. 자격 요건에 맞지 않으니 넘기시는 분들을 간혹 봤는데, 사람마다 다르겠지만 저는 밑져야 본전이라는 마인드로 지원해 보라고 조언합니다. (채용 담당자님들 죄송합니다)
 
저는 신입으로 지원할 때, 경력직으로 이직할 때 모두 자격 요건을 한 번도 맞춰본 적이 없습니다. Front-end 경력직으로 이직할 때 요즘 거의 모든 공고에서 “React혹은 Vue실무에서 1년 이상 개발해 본 경험” 을 요구하지만 저는 이직 전까지 한 번도 모던 웹 프론트엔드 기술을 활용해 본 경험이 없었어요. 하지만 누구나 들어봤을 빅테크 기업부터 시작해 여러 기업에 서류를 제출했고, 지원했던 거의 모든 기업의 서류 전형을 통과했습니다 🎉
 
필수 자격 요건은 해당 기업, 혹은 팀의 프로덕트를 개발하는 데 쓰이거나 필수로 알아야 하는 기술 스택입니다. 해당 기술을 잘 알고 쓸 줄 아는 사람이 최고이겠지만, 해당 기술을 써 본 적이 없어도 전반적인 베이스 기술에 대한 이해도가 높고 다른 강점까지 갖추고 있다면 서류전형 담당자가 좋은 점수를 주고 면접 전형을 통해 한 번 더 검증할 수 있습니다.


 
회사와 도메인에 대해 최대한 많이 공부하고 숙지하고 가자
내가 지원한 회사와 회사가 진행하고 있는 사업 리스트, 그리고 사업이 속해 있는 시장, 도메인에 대해 미리 공부해 서류에 녹여 내고 면접에 참여하면 담당자에게 있어 분명히 좋은 인상을 줄 수 있습니다.
 
우선 우리 회사에 그냥 지원한 게 아니구나 라는 진심과 성의가 담당자에게 느껴집니다. 저는 제가 지원하는 회사의 홈페이지, 그리고 서비스를 간단하게나마 한 번씩 직접 써 보고 잠시나마 고객이 되어본 후에 지원합니다. 그 후 채용 프로세스 과정에서 서비스를 쓰면서 느꼈던 점, 혹은 개선하면 좋을 것 같은 부분 등에 대해 답변에 잘 녹여내면 어떤 담당자든 좋아할 수 밖에 없을 거에요.
 
또한, 개발자는 단순히 개발만 잘 하는 사람이 아니라 프로덕트를 함께 만들어 나가는 사람 중 기술에 강점을 가지고 있는 사람입니다. 넘겨 받은 기획서에 맞춰 개발만 하는 것이 아니라, 때로는 시장에 있는 서비스들을 보면서 더 나은 아이디어를 제시하기도 하고, 사업에 대한 깊은 이해를 바탕삼아 어떠한 액션을 해야 할 지 보다 빠르게 감을 잡을 수 있습니다.
 

채용 프로세스 중에 지원자도 회사를 함께 평가해야한다
대부분 우리는 서류 제출 후 받는 “결과에 대한 알림”, 그리고 면접이 끝난 후 “내가 얼마나 잘했는지”, 그리고 면접 “결과”에 집중하는 경향이 있습니다. 하지만, 면접관과 채용 담당자들이 지원자를 평가하는 것과 같이 지원자도 회사에 대한 평가를 같이 해야 합니다.
 
서류, 면접 결과를 어떻게 알려주는 지부터, 면접을 보러 갔을 때 사무실의 전체적인 분위기, 지원자를 대하는 태도를 보고 향후 내가 입사했을 때 분위기를 미리 예측해 볼 수 있습니다. 또한, 면접관은 대부분 나와 함께 일하는 실무자, 혹은 매니저, 리더일 확률이 큽니다. 면접관의 질문과 태도, 그리고 꼬리 질문, 질의 등을 통해 면접관이 얼마나 기술적으로 성숙한 지, 경험이 많은 지 대략적으로라도 파악해 놔야 향후 내가 이 회사에 입사했을 때 내 커리어, 그리고 회사에게 서로 Win-Win 이 될 지 미리 알 수 있습니다.


[김테디의 기술 블로그 – 개발자스럽지 않은 개발자의 커리어 이야기 읽으러 가기] (https://blog.teddy-kim.com/junior-developer-career)


안녕하세요, 4년차 Front-end 개발자 김테디라고 합니다.

인디스워크와는 “주니어 프론트엔드 개발자의 취업과 커리어” 라는 인터뷰 영상을 촬영한 이후로 두 번째 만남이네요.

지난 인터뷰 영상을 촬영할 때에 취업과 관련해 간략하게 몇 가지 이야기를 전달 드렸었는데,

최근 채용 시장이 얼어 붙으면서 취업과 이직, 그리고 커리어를 어떻게 쌓아가는 게 좋을 지 고민하는 신입, 주니어 개발자 분들이 많은 것 같아요.

그래서 저도 아직 실력적으로 많이 부족하지만 어떤 마음가짐을 갖고 어떻게 준비하는 게 좋을 지 제가 가지고 있는 팁들을 공유 드리고자

제 개인 기술 블로그에 “개발자스럽지 않은 개발자의 커리어 이야기” 라는 제목의 글을 작성했습니다.

제 글이 취업을 준비하는 개발 꿈나무 분들부터 주니어 개발자 분들이 커리어를 발전시켜 나가는 방향성을 정하는 데 있어

조금이나마 도움이 되길 바라며, 궁금하신 점은 언제든 기술 블로그를 통해 문의 주시면 감사하겠습니다!


Prologue
안녕하세요, 4년차 Front-end 개발자 김만수 (Teddy) 입니다 🧸
 
지금 이 글을 작성하는 순간에도 제가 주니어 개발자, 그리고 개발자를 꿈꾸는 취준생 분들께 조언을 드려도 되는가에 대해 고민과 걱정이 많이 드는 것 같습니다. 가장 큰 이유는 개발자 커리어를 시작하게 된 순간부터 커리어 도중 있었던 수많은 직무 변경, 그리고 2년차에 맡게 된 파트 리드, 이직 과정까지 일반적인 개발자 분들과는 많이 다른 길을 걸어왔기 때문이에요. 또한, 글의 제목에도 나와 있듯이 저는 “개발자스럽지 않은 개발자” 라는 다소 특이한 캐릭터로 개발자 커리어를 쌓아 왔습니다. 덕분에 개발에 별로 재능이 없는 제가 취업에 성공하고 함께 했던 동료 분들께 개발자로서 좋은 평가를 받을 수 있었지만, 한편으로는 대다수의 분들이 공감하고 참고하실 수 있는 일반적인 경험과 조언이 아닐 수 있겠다는 생각이 머릿속을 계속 맴돌았습니다.
 
그래서 저는 이 글을 읽어 주시는 분들께서 ‘이렇게도 신입 개발자로 취업할 수 있구나’, ‘이렇게 다이내믹하게 커리어가 뒤바뀐 사람도 있는데 나는 나름 괜찮은 상황이었구나(?)’ 와 같이 일반적이지 않은 저의 경험들을 보시고 새로운 관점과 인사이트를, 그리고 조금이나마 용기를 얻어 가실 수 있으면 좋겠다는 바람과 함께 글을 써 내려가 보려 합니다.
 
본격적으로 글을 시작하기에 앞서, 이 글이 도움이 될 수 있는 분들은 다음과 같습니다.
•    IT 스타트업을 포함해 기술 중심의 기업을 목표로 준비하고 있는 개발자 취준생 분들
•    성공적으로 취업은 해내었지만, 주니어 개발자로서 어떻게 커리어를 발전시켜 나가야 할지 고민 중인 신입 개발자 분들
•    유행하는 기술 스택에 조금 뒤떨어져 있는 레거시 기술 스택을 활용하고 있어 트렌디한 IT 서비스 기업으로 이직이 힘들지 않을까 걱정하는 주니어 개발자



 
개발자 취업을 준비하는 꿈나무 분들께 전하는 경험과 조언



저는 2020년 7월에 대학교 3학년 1학기가 끝나자마자 개발자 커리어를 시작했습니다. 뭔가 이상하죠? 제 일반적이지 않은 커리어는 시작부터 특이했습니다. 보통 4년제 대학교를 다니면 빨라야 4학년 2학기부터 취업계를 제출하고 회사 생활을 시작하게 되는데, 저는 산업기능요원 (병무청에서 지정한 업체에서 일정 기간 동안 재직하는 형식의 대체복무) 이라는 기회를 노리고 있었기 때문에 남들보다 일찍 취업을 준비해야 했습니다.
 
산업기능요원으로 복무가 가능한 업체는 대다수가 IT 스타트업, 중소 SI 기업입니다. 따라서 저도 IT 스타트업을 위주로 2학년 때부터 취업을 준비하기 시작했습니다. 여기서 몇 가지 문제를 마주하게 되는데요. 우선 가장 큰 문제는 산업기능요원은 S/W 관련 전공 2년 이상 재학 후 지원이 가능했습니다. 즉, 3학년 1학기가 끝나는 시점에 기업에 지원했던 저는 모든 지원자 중 가장 나이와 학년 모두 가장 낮을 확률이 컸습니다.
 
사실 나이, 학년 ∝ 실력은 절대 아닙니다. 어느 분야든 나이, 학년과 관계없이 엄청난 재능과 퍼포먼스를 보여주는 천재 분들은 꼭 있습니다. 문제는 제가 그 천재에 해당하지 않는다는 것, 그리고 “산업기능요원”을 “신입”으로 채용하는 “괜찮은 IT 스타트업”은 정말 적다는 것이었습니다. 나름 이른 시점인 2학년부터 취준을 염두에 두고 다양한 활동과 프로젝트를 해 왔지만, 산업기능요원을 위해 휴학하며 준비해 온 분들과 4학년, 졸업생 분들 사이에서 경쟁해야 했던 것이죠.
 
즉, 저는 개발 실력이 부족해도 채용 담당자의 눈을 사로잡을 만한 저만의 무기가 필요했습니다.



 
제가 3학년 1학기까지 했던 활동은 다음과 같았습니다.

•    멋쟁이사자처럼 🦁 – 대학교 연합 프로그래밍 교육 단체
•    8기 전체 대표 (대학생 Community Manager) & 명지대(서울) 대표 운영진
•    8기 공식 Django 온라인 강의 기획 및 촬영
•    명지대(서울) 8기 지원 사이트 자체 개발 참여
•    명지대학교 인문캠퍼스 19년도 축제 공식 홈페이지 개발 참여
•    교내 창업경진대회 우수상 수상 (팀장, 발표 담당)
•    Java 기반 프로젝트 개발
•    JavaFX를 활용해 MVC 패턴 기반 교내 수강 신청 프로그램 구현
•    Swing을 활용해 Window 운영체제의 그림판 클론 코딩
•    RPA – UiPath 기반으로 업무 프로세스 자동화 프로그램 구현
•    명지대학교 입학처, 서울시 산하 공공기관에서 전공 강연, 멘토링 진행


 
하단에서 언급하겠지만, 같은 활동을 하더라도 자신의 캐릭터와 어떻게 연계하고 어필하는 지에 따라 채용 담당자에게 느껴지는 임팩트는 천차만별로 차이가 날 수 있다고 생각합니다. 저는 지원자들 사이에서 기술적인 부분은 눈에 띄기 어렵겠다고 판단했고, “현실 세계의 문제를 기술로서 풀어낼 줄 아는 신입 개발자” 라는 캐릭터로 잡아 제너럴리스트이면서 프로그램의 근본적인 기반 개념들을 이해하고 있어 유연하게 다른 언어와 기술들도 빠르게 학습할 수 있는 신입으로 어필하는 것을 전략으로 세웠습니다. 제가 여러 언어와 프레임워크를 활용해 단순한 클론 코딩, 사이드 프로젝트가 아닌 실제 우리 주위에 있는 문제들을 해결해 멋쟁이사자처럼 소속 학생들과 교내 구성원들에게 배포했던 일련의 활동들이 제가 갖고 있던 근거였죠.
 
사실 나름대로의 근거를 가지고 만들었던 전략이었지만, 당시에 취업에 바로 성공할 수 있을 것이란 기대는 전혀 없었습니다. 다른 분들은 얼마나 개발을 잘 할 수 있는지에 대해 화려한 프로젝트와 지식으로 어필하시는 사이에 저는 개발적인 어필을 할 수 있는 부분이 많이 없다고 느꼈기 때문이에요. 하지만, 방학이 시작하기 직전에 유명 데이팅 어플을 서비스하고 있는 스타트업과 구로에 있던 SI 기업의 공고가 올라왔고 호기심에 지원했더니 둘 다 서류 합격 후 면접까지 통과해 얼떨떨해 했고, 데이팅 어플 스타트업에 최종 합격하게 되었습니다.
 
나중에 문득 궁금해져 저를 채용해주신 팀장님께 제가 지원했을 때의 경쟁률이 어땠는지 물어보았을 때, ‘8대 1’ 이었다는 답변을 주셨습니다. (산업기능요원 – 보충역만 지원 가능했던 공고) 듣고 놀라서 어떤 점 때문에 저를 채용하신 건지 여쭤 봤더니, 업무 적응 속도가 빠를 것 같았고 언어와 기술에 매몰되는 게 아니라 도구로 보고 여러 비즈니스 문제를 잘 정제해서 해결해 나간 게 인상 깊었다고 하셨습니다. 신입이기 때문에 기술적인 부분은 온보딩 과정 동안 교육을 할 계획을 사전에 세워 두셨고, 중요한 건 비즈니스를 잘 분석해서 기술로 구현하는 것인데 이 부분을 적극적으로 어필한 제가 좋은 점수를 받았던 것이었습니다. 개발자 커리어에 있어 첫 번째로 마주한 행운이 바로 팀장님을 비롯해 첫 회사에서 좋은 리더 분들을 만난 것이었습니다.
 
이렇게 제가 신입 개발자로 취업을 준비하며 배웠던 점들과 함께 현재 채용 담당자로 채용에 참여하면서 느낀 부분들을 종합하여 개발자 취업을 준비하는 꿈나무 분들께 몇 가지 조언을 드려 보고자 합니다.


나를 어떻게 PR 할 건지 전략을 세우고 그에 맞춰 세부적인 전략들을 준비하자
이건 개발자 뿐만 아니라 모든 직군에 공통적으로 해당되는 부분이라고 생각합니다. 어쩌면 제가 개발적인 실력이 뛰어나지 않았음에도 취업에 바로 성공할 수 있었던 핵심적인 포인트이자, 지금 제가 서류를 평가하거나 인터뷰(면접)에서 지원자 분을 평가할 때 중요하게 보는 포인트 중 하나라고 생각합니다.
 
자신의 강점과 역량, 그리고 가치를 잘 드러내는 ‘캐릭터’를 설정하는 것은 매우 중요합니다. 캐릭터는 단순히 본인의 역량을 설명하는 것 이상의 역할을 합니다. 본인의 경험과 지식, 그리고 가치를 일관된 스토리로 연결해주며, 이것이 바로 면접관들에게 본인을 기억시키는 데 크게 도움이 됩니다.
 
그리고 이러한 ‘캐릭터’ 설정은 면접 준비 과정에서도 큰 도움이 됩니다. 자신의 캐릭터와 일치하는 방식으로 답변들을 미리 구성해보면, 실제 면접 상황에서도 훨씬 수월하게 대응할 수 있습니다. 예를 들어서, 만약 본인이 ‘기획자가 좋아하는 개발자’라는 캐릭터를 설정했다면, 면접에서도 답변을 구성할 때 단순히 기술적인 부분만 어필하는 게 아니라 기획자를 포함한 타 직군 분들도 이해하기 쉽게 풀어서 대답하거나 기획적인 대안을 제시하는 등의 전략을 세울 수 있습니다.


프로젝트는 규모가 작더라도 직접 기획하고 개발해보고 성과를 측정해보자
요즘 신입 지원자 분들의 이력서, 포트폴리오를 보면 Slack, 카카오톡을 포함해 다양한 서비스의 클론 코딩 프로젝트가 많이 기재되어 있습니다. 클론 코딩이 나쁜 건 절대 아닙니다! 몇 십, 몇 백 명의 프로 개발자가 협업해서 만든 서비스에 얼마나 복잡한 UI와 기능들이 구현되어 있겠어요. 이러한 서비스를 누군가의 도움 없이 혼자 비슷하게 구현했다면 정말 본인의 실력을 어필하기 좋은 수단이 될 겁니다. 하지만, 단순히 특정 클론 코딩 강의를 따라가면서 그대로 따라 친 프로젝트를 기재하는 건 서류 평가 담당자와 면접관에게 좋지 않은 영향을 줄 확률이 큽니다.
 
그래서 저는 클론 코딩 보다는, 우리 주위의 작더라도 불편하거나 개선하면 좋을 것 같은 문제 상황에 대해 직접 요구 사항을 정의하고 기술로 구현해 보는 프로젝트를 진행해 보는 걸 추천하는 편입니다. 개발자가 필요한 이유 중 하나는 정형화되어 있지 않은 현실 세계의 문제를 기술로 구현하기 위해 정형화 할 수 있기 때문입니다. 우리 주위의 작은 문제와 회사에서 서비스하고 있는 프로젝트에 새로운 기능을 추가하는 일도 크게 보면 “현실 세계의 문제를 기술적으로 정제해 구현한다” 라는 큰 맥락 안에 있다고 볼 수 있어요.
 
물론 정말 어렵고 많이 고생할 확률이 큽니다. 우리 주위의 문제 상황을 인식한 후에 어떻게 해결할 것인지 아이디어를 도출해야 하고, 무에서 유를 창조하면서 기능적인 플로우나 UI를 모두 창조해야 하기 때문이에요. 개발자 취업을 준비하다 어느 순간 창업을 준비하는 느낌이 들 수도 있습니다. 평소에 이미 정제되어 있는 코드를 기반으로 진행하는 강의를 보면서 따라하는 프로젝트와는 달리, 직접 구조부터 세부적인 로직을 구현하다 보면 당연히 알고 있다고 생각했던 코드도 잘 안 쳐지고 에러를 뿜어내기 시작합니다. 강의에서 전달하는 지식은 강의자에게 맞춰 정제된 지식일 뿐, 일방향으로 전달받는 우리에게 정제된 지식이 아니기 때문이에요. 다른 사람에 맞춰 정제된 지식을 나에게 맞춰 정제하는 과정이 필요하고, 이러한 과정은 직접 나에게 필요한 코드를 작성하는 고통 속에 이루어집니다.
 
이렇게 서비스를 구현하고 실제로 배포하게 되면 여러분은 새로운 서비스를 세상에 출시하게 된 겁니다. 여기까지만 성공해도 정말 소중한 경험과 배움을 얻은 것이지만, 조금 더 나아가서 GA(Google Analytics) 와 같은 분석 툴, 플랫폼을 연동해 성과를 측정하는 것도 추천합니다. 내가 만든 서비스와 기술이 얼마나 많은 사람들에게 영향을 줬고, 연령대, 유입 경로 등을 분석해 개선하면 좋을 부분들을 찾아 서비스를 발전시킬 수 있습니다. 라이브 중에 유저들로부터 예상치 못한 이슈나 개선되면 좋을 부분들에 대한 VoC(Voice Of Customer) 를 받을 수도 있어요.
 
이런 모든 과정이 회사에서 프로덕트를 만들고 발전시켜 나가는 프로세스와 똑같습니다. 직접 해 본 사람과 그저 글과 강의로만 접한 사람은 정말 큰 차이를 보입니다.


에러를 마주했을 때 최대한 파고 들어가자. 정답이 아니더라도 도움이 된다
코드를 치다가 마주하게 되는 빨간 줄, 런타임에서 예상치 못하게 발생하는 에러 (ex. Uncaught TypeError: x is not a function) 는 우리의 머리를 지끈거리게 만드는 주범입니다. 우리가 이 때 선택할 수 있는 선택지는 크게 3가지입니다. 1) 잘하는 사람을 찾아가거나, 2) 구글에 검색하거나,  3) StackTrace를 차근차근 분석해 나가는 거죠.
 
1, 2, 3번의 순서대로 나에게 오는 고통도 커지고 문제를 해결하는 데 소요되는 시간도 기하급수적으로 늘어날 확률이 큽니다. 하지만, 알 수 없는 에러 로그들 속에는 다양한 정보들이 숨겨져 있습니다. 에러 로그는 실제 문제가 일어난 부분부터 Stack 형식으로 차곡차곡 쌓이는데, 대부분 어떤 파일의 몇 번째 줄에서 문제가 났는지 친절하게 가이드 해 줍니다. 사람이 작성한 코드 뿐만 아니라 내부 엔진의 로그까지 모두 포함해서 말이죠. 따라서, 에러 로그를 분석하고 핸들링 해 보면서 우리가 활용하고 있는 기술의 내부 구조도 조금씩 탐구해 볼 수 있고 에러가 발생한 부분을 하나씩 대응해 보면서 경험치를 차곡차곡 쌓을 수 있습니다. 대응하려고 수정 했다가 또 다른 문제를 마주할 수 있습니다. 이런 잘못된 접근도 어떤 부분이 문제였고 어떻게 다른 방식으로 대응했는지 기록을 해 나가다 보면 향후 개발할 때 분명 도움이 될 겁니다.
 
구글링을 통해 정답을 찾아가는 것도 좋은 방법입니다. 단, 구글링을 할 때 검색에 활용하는 키워드를 어떻게 써야 효율적으로 내가 원하는 정답을 찾을 수 있을 지 한 번씩 고민해 보시는 걸 추천 드립니다. 같은 현상을 보고도 각자 가지고 있는 경험과 지식이 다르기 때문에 자신이 모르거나 놓친 부분 또한 다릅니다. 구글링을 효율적으로 많이 해 볼 수록 내가 원하는 결과값을 빠르게 추출할 수 있는 검색어를 자동으로 떠올리게 됩니다.
 

모르는 건 확실하게 모른다고 답변하자. 대신 최대한 답에 근접하기 위해 노력해보자
개발에 천부적인 재능과 센스를 가지고 있는 정말 몇 없는 천재(?) 개발자 분들을 제외하면, 대부분의 신입, 주니어 개발자 분들은 경험과 지식이 많지 않습니다. 하지만, 우리를 평가하는 면접관, 채용 담당자들은 우리보다 몇 년은 더 해당 업무, 직군에 대해 필드에서 일을 하고 경험을 쌓았습니다.
 
대부분의 신입 분들은 직군에 대해 강의 등을 통해 공부하면서 얻은 지식과 함께 취업을 준비하던 동기들과 진행한 사이드 프로젝트 등이 경험의 전부입니다. 그렇기 때문에 특정 기술에 대해 딥다이브 해 본 경험이나 프로젝트에서 어떤 방법이 더 나을지, 특정 장애 상황에 대해 어떻게 대처하면 좋을지에 대한 질문이 들어오면 대답을 못하는 경우가 대다수입니다.
 
면접관 또한 대답하지 못할 것이라고 예상하고 질문을 하는 경우가 대다수입니다. 여기서 답을 맞추면 최고의 시나리오겠지만, 정확하게 답을 모르겠더라도 최대한 본인만의 근거를 기반으로 답을 추론해 나가는 모습을 보여주는 것이 좋습니다. 추론해 나가면서 답을 맞추는 과정을 통해 면접관은
1.    지원자가 전혀 접근도 못 하진 않고, 어디까지 지식은 잡혀 있구나 파악할 수 있고,
2.    섣불리 포기하는 타입은 아니구나 라는 조금이나마 좋은 인상을 남길 수 있고,
3.    가끔 좋은 면접관 분들을 만나게 되면 추론 과정이 타당할 경우, 조금씩 힌트를 주며 답으로 유도를 해 주시기도 하기 때문입니다.
 
저도 신입으로 취업할 때, 그리고 경력직으로 이직할 때 어려운 기술 질문을 많이 받았었어요. 질문을 받고 나서 머리가 새하얘졌지만, 최대한 제가 갖고 있는 지식과 경험을 활용하여 답을 추론해 나갔었습니다. 지금 제가 재직 중인 회사 또한 기술 인터뷰 당시 답이 가늠이 되지 않는 질문을 많이 받아서 당연히 떨어졌을거라 생각했는데 합격 통보를 받았었고, 추론해 나가는 과정이 인상 깊고 실제로 답에 어느 정도 근접했기 때문에 좋은 점수를 받았다는 피드백을 받았어요.



 
이력서는 Notion / 로켓펀치 / 링크드인으로 구성하면 효율적이다



대부분의 IT 스타트업이나 서비스 기업은 자유 형식의 이력서, 포트폴리오를 서류 전형에 제출합니다. 신입 분들의 경우 이력서의 내용을 어떻게 구성할지도 어렵지만, 이력서 형식이나 폼을 어떻게 구성해야 하는지에 대해서도 감을 잡기 어려우실 것이라 생각됩니다.
 
“이력서 양식”이라고 검색하면 나오는 채용 플랫폼의 Word, 한글 기반 이력서 양식 등이 제일 먼저 나와서 해당 파일을 다운로드 받아 꾸며서 제출하시는 분들을 채용 과정에서 많이 봤는데요. Word로 만드는 게 잘못된 건 절대 아닙니다! Notion, 로켓펀치, 링크드인으로 이력서를 구성하는 걸 추천드리는 이유는 이력서를 깔끔하게 만드는 데 있어 효율적이고 향후 네트워킹을 위한 프로필까지 한 번에 구성할 수 있기 때문입니다.
 
우선 Notion의 경우, 개발자 이력서 템플릿을 구글에 검색하면 깔끔하게 만들어져 있는 템플릿을 손쉽게 구해 개인적인 내용만 수정해서 빠르게 활용할 수 있습니다. PDF Export와 함께 누구든 URL로 접근할 수 있는 Web Publishing 기능도 제공하기 때문에 PDF와 웹사이트 버전 이력서를 동시에 제작할 수 있습니다.
 
링크드인과 로켓펀치의 경우, 프로필에 내가 재직 중인 회사, 활동했던 단체를 기록하고 세부적으로 어떤 활동을 했는지, 어떤 기술 스택을 활용했었는지 한 번에 편하게 작성할 수 있습니다. 그리고 프로필에 작성한 내용들을 각 플랫폼의 이력서 템플릿에 맞춰 자동으로 이력서로 구성해 Export 하는 기능을 제공합니다.
 
개발자의 니즈에 맞춰 타 플랫폼에 비해 커스터마이징 되어 있는 프로필 작성 기능을 토대로 이력서를 편하게 작성, 관리하고 향후 해당 플랫폼을 업데이트 하며 개발 커뮤니티에서 네트워킹도 가능하기 때문에 저는 링크드인, 로켓펀치를 활용한 이력서 관리를 추천드립니다.
(혹시나 싶어 적어놓자면, 저는 저 세 곳의 업체와 어떠한 관계도 없습니다)


 
채용 공고의 자격 요건에 조금 부족하더라도 일단 지원해보자
항상 내 눈에 띄는 공고는 읽어 내려가다 보면 자격 요건의 최소 경력 연차나 필요로 하는 특정 기술 스택이 맞지 않는 경우가 많습니다. 자격 요건에 맞지 않으니 넘기시는 분들을 간혹 봤는데, 사람마다 다르겠지만 저는 밑져야 본전이라는 마인드로 지원해 보라고 조언합니다. (채용 담당자님들 죄송합니다)
 
저는 신입으로 지원할 때, 경력직으로 이직할 때 모두 자격 요건을 한 번도 맞춰본 적이 없습니다. Front-end 경력직으로 이직할 때 요즘 거의 모든 공고에서 “React혹은 Vue실무에서 1년 이상 개발해 본 경험” 을 요구하지만 저는 이직 전까지 한 번도 모던 웹 프론트엔드 기술을 활용해 본 경험이 없었어요. 하지만 누구나 들어봤을 빅테크 기업부터 시작해 여러 기업에 서류를 제출했고, 지원했던 거의 모든 기업의 서류 전형을 통과했습니다 🎉
 
필수 자격 요건은 해당 기업, 혹은 팀의 프로덕트를 개발하는 데 쓰이거나 필수로 알아야 하는 기술 스택입니다. 해당 기술을 잘 알고 쓸 줄 아는 사람이 최고이겠지만, 해당 기술을 써 본 적이 없어도 전반적인 베이스 기술에 대한 이해도가 높고 다른 강점까지 갖추고 있다면 서류전형 담당자가 좋은 점수를 주고 면접 전형을 통해 한 번 더 검증할 수 있습니다.


 
회사와 도메인에 대해 최대한 많이 공부하고 숙지하고 가자
내가 지원한 회사와 회사가 진행하고 있는 사업 리스트, 그리고 사업이 속해 있는 시장, 도메인에 대해 미리 공부해 서류에 녹여 내고 면접에 참여하면 담당자에게 있어 분명히 좋은 인상을 줄 수 있습니다.
 
우선 우리 회사에 그냥 지원한 게 아니구나 라는 진심과 성의가 담당자에게 느껴집니다. 저는 제가 지원하는 회사의 홈페이지, 그리고 서비스를 간단하게나마 한 번씩 직접 써 보고 잠시나마 고객이 되어본 후에 지원합니다. 그 후 채용 프로세스 과정에서 서비스를 쓰면서 느꼈던 점, 혹은 개선하면 좋을 것 같은 부분 등에 대해 답변에 잘 녹여내면 어떤 담당자든 좋아할 수 밖에 없을 거에요.
 
또한, 개발자는 단순히 개발만 잘 하는 사람이 아니라 프로덕트를 함께 만들어 나가는 사람 중 기술에 강점을 가지고 있는 사람입니다. 넘겨 받은 기획서에 맞춰 개발만 하는 것이 아니라, 때로는 시장에 있는 서비스들을 보면서 더 나은 아이디어를 제시하기도 하고, 사업에 대한 깊은 이해를 바탕삼아 어떠한 액션을 해야 할 지 보다 빠르게 감을 잡을 수 있습니다.
 

채용 프로세스 중에 지원자도 회사를 함께 평가해야한다
대부분 우리는 서류 제출 후 받는 “결과에 대한 알림”, 그리고 면접이 끝난 후 “내가 얼마나 잘했는지”, 그리고 면접 “결과”에 집중하는 경향이 있습니다. 하지만, 면접관과 채용 담당자들이 지원자를 평가하는 것과 같이 지원자도 회사에 대한 평가를 같이 해야 합니다.
 
서류, 면접 결과를 어떻게 알려주는 지부터, 면접을 보러 갔을 때 사무실의 전체적인 분위기, 지원자를 대하는 태도를 보고 향후 내가 입사했을 때 분위기를 미리 예측해 볼 수 있습니다. 또한, 면접관은 대부분 나와 함께 일하는 실무자, 혹은 매니저, 리더일 확률이 큽니다. 면접관의 질문과 태도, 그리고 꼬리 질문, 질의 등을 통해 면접관이 얼마나 기술적으로 성숙한 지, 경험이 많은 지 대략적으로라도 파악해 놔야 향후 내가 이 회사에 입사했을 때 내 커리어, 그리고 회사에게 서로 Win-Win 이 될 지 미리 알 수 있습니다.


[김테디의 기술 블로그 – 개발자스럽지 않은 개발자의 커리어 이야기 읽으러 가기] (https://blog.teddy-kim.com/junior-developer-career)

Unpublish ON
previous arrow
next arrow