개발자스럽지 않은 개발자의 커리어 이야기 | 신입, 주니어 개발자에게 전하는 조언 (외부 기고글)

draft

date

Oct 3, 2023

slug

junior-developer-career

author

status

Public

type

Post

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 형식으로 차곡차곡 쌓이는데, 대부분 어떤 파일의 몇 번째 줄에서 문제가 났는지 친절하게 가이드 해 줍니다. 사람이 작성한 코드 뿐만 아니라 내부 엔진의 로그까지 모두 포함해서 말이죠. 따라서, 에러 로그를 분석하고 핸들링 해 보면서 우리가 활용하고 있는 기술의 내부 구조도 조금씩 탐구해 볼 수 있고 에러가 발생한 부분을 하나씩 대응해 보면서 경험치를 차곡차곡 쌓을 수 있습니다. 대응하려고 수정 했다가 또 다른 문제를 마주할 수 있습니다. 이런 잘못된 접근도 어떤 부분이 문제였고 어떻게 다른 방식으로 대응했는지 기록을 해 나가다 보면 향후 개발할 때 분명 도움이 될 겁니다.

구글링을 통해 정답을 찾아가는 것도 좋은 방법입니다. 단, 구글링을 할 때 검색에 활용하는 키워드를 어떻게 써야 효율적으로 내가 원하는 정답을 찾을 수 있을 지 한 번씩 고민해 보시는 걸 추천 드립니다. 같은 현상을 보고도 각자 가지고 있는 경험과 지식이 다르기 때문에 자신이 모르거나 놓친 부분 또한 다릅니다. 구글링을 효율적으로 많이 해 볼 수록 내가 원하는 결과값을 빠르게 추출할 수 있는 검색어를 자동으로 떠올리게 됩니다.

모르는 건 확실하게 모른다고 답변하자. 대신 최대한 답에 근접하기 위해 노력해보자

개발에 천부적인 재능과 센스를 가지고 있는 정말 몇 없는 천재(?) 개발자 분들을 제외하면, 대부분의 신입, 주니어 개발자 분들은 경험과 지식이 많지 않습니다. 하지만, 우리를 평가하는 면접관, 채용 담당자들은 우리보다 몇 년은 더 해당 업무, 직군에 대해 필드에서 일을 하고 경험을 쌓았습니다.

대부분의 신입 분들은 직군에 대해 강의 등을 통해 공부하면서 얻은 지식과 함께 취업을 준비하던 동기들과 진행한 사이드 프로젝트 등이 경험의 전부입니다. 그렇기 때문에 특정 기술에 대해 딥다이브 해 본 경험이나 프로젝트에서 어떤 방법이 더 나을지, 특정 장애 상황에 대해 어떻게 대처하면 좋을지에 대한 질문이 들어오면 대답을 못하는 경우가 대다수입니다.

면접관 또한 대답하지 못할 것이라고 예상하고 질문을 하는 경우가 대다수입니다. 여기서 답을 맞추면 최고의 시나리오겠지만, 정확하게 답을 모르겠더라도 최대한 본인만의 근거를 기반으로 답을 추론해 나가는 모습을 보여주는 것이 좋습니다. 추론해 나가면서 답을 맞추는 과정을 통해 면접관은

지원자가 전혀 접근도 못 하진 않고, 어디까지 지식은 잡혀 있구나 파악할 수 있고,

섣불리 포기하는 타입은 아니구나 라는 조금이나마 좋은 인상을 남길 수 있고,

가끔 좋은 면접관 분들을 만나게 되면 추론 과정이 타당할 경우, 조금씩 힌트를 주며 답으로 유도를 해 주시기도 하기 때문입니다.

저도 신입으로 취업할 때, 그리고 경력직으로 이직할 때 어려운 기술 질문을 많이 받았었어요. 질문을 받고 나서 머리가 새하얘졌지만, 최대한 제가 갖고 있는 지식과 경험을 활용하여 답을 추론해 나갔었습니다. 지금 제가 재직 중인 회사 또한 기술 인터뷰 당시 답이 가늠이 되지 않는 질문을 많이 받아서 당연히 떨어졌을거라 생각했는데 합격 통보를 받았었고, 추론해 나가는 과정이 인상 깊고 실제로 답에 어느 정도 근접했기 때문에 좋은 점수를 받았다는 피드백을 받았어요.

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

대부분의 IT 스타트업이나 서비스 기업은 자유 형식의 이력서, 포트폴리오를 서류 전형에 제출합니다. 신입 분들의 경우 이력서의 내용을 어떻게 구성할지도 어렵지만, 이력서 형식이나 폼을 어떻게 구성해야 하는지에 대해서도 감을 잡기 어려우실 것이라 생각됩니다.

“이력서 양식”이라고 검색하면 나오는 채용 플랫폼의 Word, 한글 기반 이력서 양식 등이 제일 먼저 나와서 해당 파일을 다운로드 받아 꾸며서 제출하시는 분들을 채용 과정에서 많이 봤는데요. Word로 만드는 게 잘못된 건 절대 아닙니다! Notion, 로켓펀치, 링크드인으로 이력서를 구성하는 걸 추천드리는 이유는 이력서를 깔끔하게 만드는 데 있어 효율적이고 향후 네트워킹을 위한 프로필까지 한 번에 구성할 수 있기 때문입니다.

우선 Notion의 경우, 개발자 이력서 템플릿을 구글에 검색하면 깔끔하게 만들어져 있는 템플릿을 손쉽게 구해 개인적인 내용만 수정해서 빠르게 활용할 수 있습니다. PDF Export와 함께 누구든 URL로 접근할 수 있는 Web Publishing 기능도 제공하기 때문에 PDF와 웹사이트 버전 이력서를 동시에 제작할 수 있습니다.

링크드인과 로켓펀치의 경우, 프로필에 내가 재직 중인 회사, 활동했던 단체를 기록하고 세부적으로 어떤 활동을 했는지, 어떤 기술 스택을 활용했었는지 한 번에 편하게 작성할 수 있습니다. 그리고 프로필에 작성한 내용들을 각 플랫폼의 이력서 템플릿에 맞춰 자동으로 이력서로 구성해 Export 하는 기능을 제공합니다.

개발자의 니즈에 맞춰 타 플랫폼에 비해 커스터마이징 되어 있는 프로필 작성 기능을 토대로 이력서를 편하게 작성, 관리하고 향후 해당 플랫폼을 업데이트 하며 개발 커뮤니티에서 네트워킹도 가능하기 때문에 저는 링크드인, 로켓펀치를 활용한 이력서 관리를 추천드립니다.

(혹시나 싶어 적어놓자면, 저는 저 세 곳의 업체와 어떠한 관계도 없습니다)

채용 공고의 자격 요건에 조금 부족하더라도 일단 지원해보자

항상 내 눈에 띄는 공고는 읽어 내려가다 보면 자격 요건의 최소 경력 연차나 필요로 하는 특정 기술 스택이 맞지 않는 경우가 많습니다. 자격 요건에 맞지 않으니 넘기시는 분들을 간혹 봤는데, 사람마다 다르겠지만 저는 밑져야 본전이라는 마인드로 지원해 보라고 조언합니다. (채용 담당자님들 죄송합니다)

저는 신입으로 지원할 때, 경력직으로 이직할 때 모두 자격 요건을 한 번도 맞춰본 적이 없습니다. Front-end 경력직으로 이직할 때 요즘 거의 모든 공고에서 “React 혹은 Vue로 실무에서 1년 이상 개발해 본 경험” 을 요구하지만 저는 이직 전까지 한 번도 모던 웹 프론트엔드 기술을 활용해 본 경험이 없었어요. 하지만 누구나 들어봤을 빅테크 기업부터 시작해 여러 기업에 서류를 제출했고, 지원했던 거의 모든 기업의 서류 전형을 통과했습니다 🎉

필수 자격 요건은 해당 기업, 혹은 팀의 프로덕트를 개발하는 데 쓰이거나 필수로 알아야 하는 기술 스택입니다. 해당 기술을 잘 알고 쓸 줄 아는 사람이 최고이겠지만, 해당 기술을 써 본 적이 없어도 전반적인 베이스 기술에 대한 이해도가 높고 다른 강점까지 갖추고 있다면 서류전형 담당자가 좋은 점수를 주고 면접 전형을 통해 한 번 더 검증할 수 있습니다.

회사와 도메인에 대해 최대한 많이 공부하고 숙지하고 가자

내가 지원한 회사와 회사가 진행하고 있는 사업 리스트, 그리고 사업이 속해 있는 시장, 도메인에 대해 미리 공부해 서류에 녹여 내고 면접에 참여하면 담당자에게 있어 분명히 좋은 인상을 줄 수 있습니다.

우선 우리 회사에 그냥 지원한 게 아니구나 라는 진심과 성의가 담당자에게 느껴집니다. 저는 제가 지원하는 회사의 홈페이지, 그리고 서비스를 간단하게나마 한 번씩 직접 써 보고 잠시나마 고객이 되어본 후에 지원합니다. 그 후 채용 프로세스 과정에서 서비스를 쓰면서 느꼈던 점, 혹은 개선하면 좋을 것 같은 부분 등에 대해 답변에 잘 녹여내면 어떤 담당자든 좋아할 수 밖에 없을 거에요.

또한, 개발자는 단순히 개발만 잘 하는 사람이 아니라 프로덕트를 함께 만들어 나가는 사람 중 기술에 강점을 가지고 있는 사람입니다. 넘겨 받은 기획서에 맞춰 개발만 하는 것이 아니라, 때로는 시장에 있는 서비스들을 보면서 더 나은 아이디어를 제시하기도 하고, 사업에 대한 깊은 이해를 바탕삼아 어떠한 액션을 해야 할 지 보다 빠르게 감을 잡을 수 있습니다.

채용 프로세스 중에 지원자도 회사를 함께 평가해야한다

대부분 우리는 서류 제출 후 받는 “결과에 대한 알림”, 그리고 면접이 끝난 후 “내가 얼마나 잘했는지”, 그리고 면접 “결과”에 집중하는 경향이 있습니다. 하지만, 면접관과 채용 담당자들이 지원자를 평가하는 것과 같이 지원자도 회사에 대한 평가를 같이 해야 합니다.

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

주니어 개발자 분들께 전하는 경험과 조언

저는 처음에 몇 번 좌초 당했습니다. 사수 분들이 친절히 체크 포인트로 환생시켜 주시고 다시 좌초 시키셨습니다.

설레는 마음으로 개발자 커리어를 시작한 저는 첫 번째 회사에서 2년의 재직 기간 중 첫 1년을 거의 의사 선생님들의 인턴 기간처럼 모든 직군을 하나씩 찍먹(?) 해 보는 기간을 가졌습니다. 4년차가 된 지금, 주변 개발자 분들께 이 이야기를 들려 드리면 대다수의 분들이 ‘?????’, 혹은 ‘도대체 어떻게 버티셨어요..?’, ‘나였으면 바로 퇴사했다’ 와 같은 반응들을 보여 주셨어요.

그래서 입사하고 처음 1년 동안 제가 얼마나 다양한 직군을 경험해 봤는지 한 번 정리해 봤습니다.

🤔

QA & Android 개발 3개월 → QA & 웹 퍼블리싱 2개월 → 웹 퍼블리싱 & 백엔드 개발 (Spring Boot & PHP 기반 API 개발 및 유지보수) 5개월 → Front-end 개발 (2개월 + a)

위에 적혀 있는 다양한 직군들을 그냥 ‘체험만’ 해 봤다면 제 첫 1년 동안의 커리어는, 아니 어쩌면 저는 개발에 대한 흥미를 복구조차 안 될 정도로 잃어 버렸을 것 같습니다. 첫 1~2년 때 어떤 환경에서 어떻게 일하고 증명하고 배우는지가 미래에 어떤 개발자로 성장하고 나아갈지 정해지는 데 정말 큰 영향을 끼친다고 믿어요.

하지만 제가 몸담고 있던 개발팀의 리더 분들은 감사하게도(?) 저를 편하게 지내게 하실 마음이 전혀 없었습니다. 모든 직군을 해당 업무 담당자 분께 스파르타 식으로 배우면서 바로 실무에 참여하도록 하셨습니다. 매주 정기 배포가 이루어지는 앱부터 서버, 그리고 QA 과정에서 조금이라도 실수를 했다간 바로 라이브 서비스 장애였고, 프로덕트에 막대한 영향을 주기 때문에 모든 힘과 정신을 끌어모아 집중할 수 밖에 없었습니다.

새로 접한 직군의 업무를 실수 없이 바로 진행하려면 공부를 엄청 해야 할 텐데 공부는 언제 해? 라고 궁금해 하실 수 있는데, 퇴근하자마자 다음 날 출근하기 직전까지 미친듯이 공부하고 아침에 담당 시니어 개발자 분께 확인 받고 토의하는 나날을 반복했습니다. 덕분에 힘들었던 대학교 시절보다도 훨씬 많은 공부량을 이뤄낼 수 있었습니다.. 🥲

1년 간의 지옥 훈련 덕분에 Front-end 개발에 정착한 후 사수 없이 혼자 개발을 하고, 프로젝트에 필요한 Flutter 앱을 함께 개발하는 상황에서도 당황하지 않고 빠르게 학습해서 문제를 해결할 수 있었습니다. 혼자 자바스크립트를 공부하면서 백엔드 개발자 분들과 프로젝트를 진행하다 보니, 지금은 상상할 수 없는 Vanilla JS 와 Kendo UI Framework 만으로 SPA (Single Page Application) 방식의 프로젝트를 모두 구현했습니다.

이 때 Vanilla JS 로 웹 애플리케이션 내부에서 지속적으로 변하는 데이터와 UI를 관리하는 방법에 대해 계속해서 고민하고 다양한 방법을 시도해봤었는데요, 이러한 경험은 Front-end 개발자로 이직을 시도할 때 React, Vue와 같은 모던 웹 프론트엔드 기술 스택을 실무에서 전혀 다뤄본 적이 없음에도 불구하고 대부분 회사의 서류 전형을 통과하고 기술 인터뷰에서도 면접관들의 흥미를 끌어내는 좋은 소재였습니다.

이직에 성공하여 재직 중인 지금 회사에서는 React, Next.js 와 TypeScript 를 비롯한 다양한 기술을 활용해 Front-end 개발을 하고 있습니다. 메인 업무와 함께 Python을 활용한 PR 리마인더 슬랙 봇, JavaScript, Selenium WebDriver를 활용한 점심 메뉴 크롤링 슬랙 봇 등을 개발하거나 인프콘 2023 기업 부스 기획 및 운영, 사내 프로덕트 세미나 기획, 발표와 같은 DevRel 활동, 개발 커뮤니티에서의 네트워킹을 함께 하며 개발을 다양한 분야로 확장시켜 나가는 “개발자스럽지 않은 개발자”로 열심히 앞으로 한 발자국씩 나아가고 있습니다 ✨

신입 개발자로 개발자 커리어를 시작한 이후 한 치 앞을 예측할 수 없는 주니어 개발자 생활과 이직을 겪으면서 느끼고 배웠던 부분들을 종합하여 지금 무럭무럭 자라나고 계신 주니어 개발자 분들께 몇 가지 조언을 드려 보고자 합니다.

문제 해결에 있어서 코드로 구현하는 건 가장 마지막 단계다

일반적으로 프로덕트를 개발할 때 우리는 새롭게 만들어야 하는 기능에 대해 기능의 필요성, 목적 등에 대해 전달 받고 기획자, 디자이너 분들로부터 화면 설계서, 기능 정의서, Figma 와 같은 문서를 전달 받게 됩니다. 그리고 이러한 문서를 분석해 요구 사항을 정의하고 구조를 설계해 기능을 구현합니다.

이 때, 전달받은 문서 그대로 개발을 진행하는 걸 우리는 Waterfall 방식이라고 부릅니다. 클라이언트(고객이 될 수도 있고 사내의 PM, 디자이너, 기획자가 될 수 있음) 가 원하는 대로 개발로서 구현해 줄 수 있다면 개발자로서의 역할을 다 했다고 볼 수 있습니다.

하지만, 개발자는 단순히 개발을 잘 하는 사람이 아닌 팀에서 기술에 강점을 가지고 있는 “프로덕트 메이커”의 일원입니다. 새롭게 만들어야 하는 기능에 대해 비즈니스 적으로 함께 고민해보고, 전달받은 문서를 보고 디자이너, 기획자와 함께 유저의 입장에서 더 나은 UI / UX 를 제공할 수 없을지 끊임없이 의견을 제시해야 합니다. 개발자의 강점을 살려 의견을 제시하는 과정에서 관련된 데이터(Database에서 추출한 관련 데이터, Clarity 등을 통해 얻은 서비스 내 유저 히트맵 등) 를 공유해 더 나은 의사 결정을 이뤄내는 데 일조할 수도 있겠죠. 이렇게 제품에 대해 끊임없이 학습하고 이해하며 이해 관계자들이 더 나은 프로덕트를 만들기 위해 소통하고 함께 일하는 프로세스를 Agile 방식이라고 부릅니다.

이렇게 의사소통을 하면서 굳이 개발로 풀어내지 않더라도 기획을 변경하거나 디자인, 플로우를 일부 수정하는 식으로 문제를 해결할 수도 있습니다. 정말 개발과 기술로 풀어내야 하는 문제들을 정제해서 가장 마지막 단계에서 코드를 구현하는 것이 좋은 프로덕트를 만들어 내고 개발 리소스를 효율적으로 활용할 수 있는 길이라고 생각합니다.

모든 개념을 일반화(추상화) 해 보자

위에 적혀있듯이, 저는 첫 회사에서 Front-end 개발을 JavaScript ES7, jQuery, Kendo UI Framework 로만 경험했었습니다. React, Vue, TypeScript 와 같은 모던 웹 프론트엔드 기술은 개인적으로 조금씩 공부만 해 봤을 뿐, 실무에서는 한 번도 다뤄보지 못했습니다. 하지만 이직을 위해 여러 회사에 지원했을 때 서류 전형은 거의 다 통과했고, 기술 인터뷰에서도 좋은 평가를 받았습니다. 어떻게 가능했던 걸까요?

바로, 특정 기술에 집중하지 않고 기술들이 가지고 있는 근본적인 배경과 원리에 집중했기 때문이라고 저는 생각합니다. React를 비롯해 최근에 모던 웹 프론트엔드 개발에 쓰이고 있는 기술들은 . 하지만 결국 이러한 기술들이 왜 나왔을까 에 초점을 두고 생각을 해 보면 “지속적으로 변화하는 데이터에 따라 미리 만들어 둔 디자인 (컴포넌트)를 보여주는 과정을 편하게 관리하자” 라고 생각합니다.

저는 <script type=”template”> 이라는 태그 안에 정적인 컴포넌트 디자인을 구성하고 내부에 동적으로 표현해야 하는 데이터는 {value} 와 같이 일정한 정규식을 구성했어요. 그리고 동적으로 컴포넌트를 렌더링해야 할 때, template의 내부 코드를 가져와 API 응답값 등을 정규식 코드에 replace 해서 DOM Tree에 Node로 추가했었습니다. 이렇게 하다 보니 자연스럽게 DOM 구조에 영향이 가면서 reflow 가 많이 발생했고, 자연스럽게 React 의 Virtual DOM이라는 개념이 어떤 배경에서 탄생했을 지 이해하고 공감할 수 있었습니다.

이런 식으로 최근에 정말 많은 언어와 라이브러리, 프레임워크가 시장에서 활용되고 있지만, 결국 왜 이 기술이 탄생하게 됐고 어떤 특징을 가지고 있는지 분석하다 보면 모두 비슷한 고민과 문제를 해결하기 위해 시작되었다고 느낍니다. 따라서, 핵심적인 원리를 이해하고 있으면 이러한 기술은 개념을 확장해 나가는 식으로 빠르게 공부하고 이해할 수 있다고 믿습니다.

(실제로 이직을 진행하던 중 모 대기업의 면접관 분께서 본인도 jQuery에 Redux를 활용해 상태관리를 하면서 Front-end 개발을 하신 경험이 있는데, 결국 다 똑같은 개념이기 때문에 React로 개발하는 건 공부해서 충분히 할 수 있을 것 같다고 하셨습니다. 그리고 최근에 이렇게 개발을 한 사람을 또 볼 줄은 몰랐다고 신기해하셨습니다)

회사는 최고의 샌드박스다

(주의) 자유롭게 사고쳐도 된다는 뜻은 절대 아닙니다.

‘모래 상자’라는 뜻을 가지고 있는 샌드박스는 ‘자유롭게 실험하고 배울 수 있는 공간’을 의미하는 용어입니다.

평소에 책과 다양한 자료를 통해 개발적인 지식을 공부하고 나면 이를 실제로 활용해 보면서 내 것으로 만들 기회가 많지 않습니다. 하지만, 회사 프로젝트를 개발하면서 자신이 공부한 내용을 직접 구현해보고, 그 결과를 유저들이 사용하는 것을 보며 어떤 부분이 잘 작동하고 어떤 부분이 개선되어야 하는지 직접 확인할 수 있습니다. 단, 새로운 시도를 실제 라이브 중인 서비스에 적용할 때에는 항상 장애가 발생할 여지가 없는 지, 함께 개발을 하는 동료, 이해 관계자들과 충분히 이야기 해 보고 진행해야 합니다.

추가로, 간단한 사이드 프로젝트나 토이 프로젝트를 구현해 사내 구성원들에게 배포하는 것도 좋습니다. 저는 업무 시간 외에 개인적으로 회사 생활에 도움이 될 만한 점들을 추려내 슬랙 봇 등을 개발했었는데요. 평소에 해 보고 싶었던 슬랙 봇 개발과 웹 크롤링을 공부해보고 사내 구성원들의 좋은 반응을 보면서 뿌듯함도 느낄 수 있었습니다.

즉, 회사라는 샌드박스에서 자신만의 방식으로 실험하며 성장하되 주변 동료와 협력하여 서비스 안정성 등 필수적인 요소도 항상 유지할 수 있어야 합니다. 이런 경험이 바탕이 되어 앞으로 다양한 문제 상황에서 대처할 수 있는 능력을 키우게 될 것입니다. 이런 식으로 회사라는 샌드박스를 잘 활용해 나와 회사 모두 성장하는 경험을 축적하면, 개발자로서의 역량을 한 단계 더 향상시킬 수 있습니다.

기회는 예고 없이 찾아온다. 왔을 때 잡는 건 실력이다

‘받은 만큼만 일을 하면 된다’ 라는 문장에 저는 개인적으로 동의하지 않는 편입니다. 틀렸다는 건 절대 아니에요. 바라보는 관점에 따라 충분히 일리 있는 이야기입니다.

제가 첫 회사에 입사한 후 팀장님께 들은 이후로 개발자 커리어 내내 좌우명으로 새기고 있는 문장이 있습니다.

💡

“돈 받고 일을 하는 순간 우리는 모두 프로다. 1군, 2군과 같이 실력에 따라 레벨이 나누어질 수 있어도 우리는 프로의 자세로 최선을 다 해야 한다”

이러한 좌우명에 따라 항상 제 능력으로 이뤄낼 수 있는 최대한의 결과물을 얻기 위해 노력하고 놓친 부분은 없는 지 끊임없이 의심하고 체크하다 보니 자연스럽게 일을 하는 데 소모되는 에너지도 많아지고 야근도 적게 하는 편은 아닙니다.

누구에게든 예고 없이 생각하지도 못했던 기회들이 찾아 옵니다. 평소에 정말 해 보고 싶었던 프로젝트에 참여할 기회를 제공 받거나, 해 보고 싶었던 업무를 “한 번 해 볼래?” 라는 식으로 말이죠. 이렇게 행운이 찾아왔을 때 본인이 미리 준비가 되어 있고 사전에 충분한 공부가 이루어져 있어야 확실하게 잡아서 내 커리어를 한 단계 발전시킬 수 있다고 생각합니다. 그렇기 때문에, 평소에 본인에게 주어진 업무가 작은 사이즈 이더라도 최선을 다해 완성하고 어떻게 확장시켜 나갈 수 있을 지, 다른 부분에 영향을 주는 포인트는 없을 지 고민하는 등의 노력을 시도하다 보면 좋은 결과로 돌아올 거에요.

동료들과 잘 지내자. 좋은 관계는 새로운 기회를 열어준다

이동욱 님의 ‘기억보단 기록을’ 블로그의 ‘인연은 어디서나’ 라는 글의 말미에 다음과 같은 구절이 있습니다.

지금 내가 내린 선택은 수많은 인연들 속에서 발생한 우연들의 결과라는 생각을 많이 한다.

함께 일하는 동료들은 자연스럽게 서로 어떤 사람인지 이해하게 됩니다. 코드 리뷰를 하면서, 평소에 이야기를 나누면서, 업무적으로 회의를 하고 가끔 정신없고 힘든 시간을 공유하며 각자가 어떤 사람인지, 함께 일하고 싶은 사람인지 판단할 수 있는 데이터가 쌓입니다.

동료와 함께 일하는 과정에서 성격 충돌이나 의견 차이 등 문제가 발생할 수 있습니다. 그러나 이럴 때 오히려 프로페셔널함을 유지하며 상황을 해결하는 모습을 보여주면 그것만으로도 크게 인상적일 것입니다. 받은 피드백도 개인적으로 받아 들이기 보다는 업무와 관련된 부분에서 성장하기 위한 자극으로 받아들여야 합니다.

더 나아가 동료와 잘 지내는 것은 단순히 현재 일하는 환경을 좋게 만드는 것 뿐만 아니라 앞으로 커리어에 있어서도 크게 도움이 됩니다. 서로 다른 경로로 나아갔다 해도 그간 쌓아온 인간관계와 네트워크는 여러분에게 새로운 기회를 제공할 수 있습니다. 그것이 새로운 프로젝트일 수도, 좋은 회사의 내부 추천일 수도 있습니다.

외부 네트워킹을 조금씩 도전해보자

모든 개발자 분들이 그러신 건 아니지만, 꽤 많은 개발자 분들이 네트워킹에 대해 두려움을 조금씩 가지고 계십니다. 주니어 개발자 분들의 경우 ‘나 같은 주니어가 갔다가 할 이야기도 없고 이야기 수준 못 따라가는 거 아니야..?’ 라는 걱정이 있다는 이야기를 주변에서 많이 들었던 기억이 납니다.

하지만 실제로 네트워킹 모임에 나가거나 외부 컨퍼런스에서 다른 개발자 분들과 이야기를 나누어 보면 오히려 서로 모르기 때문에 함께 고민을 하며 답을 찾기도 하고, 개발뿐만 아니라 다양한 회사 이야기, 새로운 트렌드 등 정말 다양한 이야기를 나누고 인사이트를 공유하게 됩니다.

개발자로서 개발을 잘 하는 것도 중요하지만 현재 IT 시장의 트렌드를 파악하고 이슈를 파악하는 것도 꾸준히 롱런하기 위해 중요한 요소 중 하나라고 저는 생각합니다. 네트워킹을 통해 최신 정보도 빠르게 습득하고 개발적으로 서로 도움을 주고 받으면서 향후 특정 기업의 공고가 열렸을 때 추천을 받을 수도 있기 때문에 저는 조금씩이라도 네트워킹 모임을 찾아 참석해보거나 링크드인과 같은 커리어 플랫폼을 관리해 보는 것을 추천드립니다.

네트워킹을 하면서 좋은 점은 유명 IT 기업들의 오피스를 둘러 볼 수 있다는 겁니다 (오피스 덕후 행복)

Epilogue

본문에 나와 있듯이, 저는 운이 정말 좋았습니다. 소프트웨어를 전공하고 있었음에도 개발적인 능력이 뛰어나지 않았던 저에게 개발자 커리어를 시작할 수 있게 기회를 주신 팀장님부터 정말 좋은 분들을 많이 만나고 도움을 받을 수 있었어요.

하지만, 어쩌면 이렇게 예고 없이 찾아온 행운을 놓치지 않고 잡아서 저에게 또 다른 기회를 만들어 줄 수 있도록 발전시키는 연습을 꾸준히 하고 있었기 때문에 저만의 개발자 커리어를 쌓아올 수 있었다고 생각이 됩니다.

어떻게 개발자 커리어를 시작하고 어떻게 쌓아가는 게 정답이다 라고 말할 수 없습니다. 최선을 다해 개발자로서 성장하고 본인만의 성과물을 만들어 내고 있다고 느끼고 만족하고 앞으로 더 나아가는 게 중요한 것 같아요. 그리고 성공 여부와 관계 없이 나만의 경험을 다른 개발자들에게 공유하고 개선해 나가다 보면 모두가 정말 훌륭한 시니어 개발자가 되어 있으실 거라 믿습니다.

요즘 같은 채용 시장 한파에 개발자를 꿈꾸는 꿈나무 분들부터 주니어 개발자 분들까지 모두 파이팅하세요! 긴 글 읽어 주셔서 감사합니다.

📌

이 글은 커리어 플랫폼 인디스워크 기고글입니다. 이 글의 내용과 관련해 과거 인디스워크에서 촬영했던 인터뷰 영상은 하단에서 확인할 수 있습니다