brunch

You can make anything
by writing

C.S.Lewis

by Naserian Nov 01. 2022

응답하라 개발자 - 첫 이직 회고

둥지를 옮겼습니다

한동안 이런저런 서비스들을 구상하고 기획하는 일을 업으로 삼다 개발을 통해 선한 변화와 사회적 가치를 만들고자 커리어 전환을 한 어느 개발자의 소소한 이야기입니다.



이야기의 시작 :  체인지메이커 웹개발자로 변신




이직의 길에 들어서기까지


지난 글에서 '첫 커리어 회고'라는 이름으로 지난 직장에서의 발자취를 정리했다. 글을 다 써놓고 보니 뭔가 빠진 느낌이 들었는데 '그래서 앞으로 어떻게 할지'를 적지 못한 것이다.

보통의 이직은 새로운 거처를 정한 뒤 기존 직장을 퇴사하며 이루어진다. 무릇 from이 있으면 to가 있기 마련인데 내게는 to가 없었다.


대책 없이 퇴사를 한 것인가 하고 물어본다면 반은 맞고 반은 틀리다고 말해야 하는 상황이었다. 2022년 하반기는 투자가 필요한 스타트업들에게 혹독한 시기였고, 나의 첫 직장도 거센 바람을 맞았다. 그리고 나에게 선택지가 주어졌다. 달라진 환경에서 계속 일할 것인가, 새로운 곳을 찾아 떠날 것인가.

나이가 들수록 무모한 결정은 하고 싶지 않았고 안전한 테투리를 두텁게 만들고 싶었다. 그러면서 또 한 편으론 개발자라는 타이틀을 달게 되면 이전에 기획 일을 할 때만큼 한 곳에서 오래 머물진 않을 거라 생각해왔다. 주어진 선택지를 앞에 두고 일주일 간 고민 끝에 이직을 하겠다고 마음먹었다.

무슨 자신감이었는지 뜨거운 여름이 지나기 전, 한 달 반 정도만 쉬지 않고 구직해서 다음 직장을 정한 후에 추석을 맞이하겠다는 다짐까지 했었다.



내가 세워야 했던 기준


결정을 내린 후 퇴사까지는 그리 오래 걸리지 않았다. 무더운 8월이 되었고, 본격적인 구직을 시작해야 했다.

어디서부터 어떻게 시작해야 할까... 머리가 잘 굴러가지 않았다. 개발자로서 첫 직장이 꽤 알려진 곳이었기에 다음 직장은 더 크고 유명한 곳이어야 한다는 막연한 생각이 있었고, 다시는 같은 이유로 퇴사하고 싶지 않았기에 지원할법한 기업들의 투자/재무 상황까지 들춰보기 시작했다.


초반 2주 정도는 내게 티타임을 요청하는 리크루터들을 만나 회사 소개를 받았다. 이름만 들어도 아, 거기! 하는 곳들이 대부분이었고 마치 어디든 골라서 이직할 수 있을 것 같은 느낌이 들었다. (그게 착각이라는 걸 깨닫는 데는 얼마 걸리지 않았다.) 첫 직장을 구할 때처럼 이곳저곳에 우수수 이력서를 보내면 되는 것인지 도통 감이 잡히지 않아 함께 일했던 몇몇 시니어 개발자분들에게 티타임을 요청했다.

"무작정 많이 넣지 말고 본인의 기준에 합당한 곳을 몇 군데 추린 후 거기서 한 두 군데씩 지원해보세요."

티타임의 결론이었다.


본인의 기준, 그게 참 어려웠다. 그때부터 함께 퇴사하는 동료들에게 이직할 곳의 기준이 무엇인지 반복적으로 물어봤다. 어떤 사람은 개발 문화와 구성원의 수가 중요했고, 또 어떤 사람은 워라밸이나 재택근무 유무가 중요했다. 그렇게 답한 이들이 나는 어떤 기준을 가지고 있는지 되물었을 때 제대로 된 답을 하지 못했다.

좀 더 정확히 말하자면 별로 가고 싶은 곳이 없었다. 개발자로 일한 지 10년 뒤, 혹은 개발자로서 최종 목표를 생각해본 적은 있지만 그렇게 되기 위해 정작 어떤 곳에서 어떤 것들을 경험하며 어떻게 성장할 것인지, 지금 내게 무엇이 중요한 것들인지 생각해본 적이 없었다.

원하는 일을 하며 살아가기 위해 어떤 돌다리를 쌓고 건널 것인지 설계하는 일의 중요성을 처음 깨닫는 순간이었다. 다행히 합류할 회사가 정해지기까지 2달 반 동안 코 앞에 떨어진 구직이라는 불을 끄며 내가 일하고 싶은 곳의 기준을 하나씩 세울 수 있었다.



이직에 관한 착각들


내 기준이 어찌 되었든 새로운 회사에 지원하는 일은 당장 시작해야 했기에 나름의 전략을 세웠다.

한 주에 1개 혹은 2개 회사의 전형을 진행할 수 있도록 지원 회사의 수를 조정하고, 전형 중 탈락한 곳이 있으면 바로 다음 주에 그만큼 또 다른 회사에 지원하는 패턴이었다. 패턴이 이러니 지원한 회사는 매우 소수였다.

첫 회사에서의 성과나 기여가 나쁘지 않았기에 한 군데를 제외한 모든 회사의 서류 전형에 합격했고 본격적인 코딩 테스트(알고리즘 테스트)와 인터뷰가 시작되었다. 그리고 그간 단단히 잘못 알고 있던 사실들을 하나하나 알게 되었다.


1. 실력 있는 동료들과 일한 경험이 내 실력을 증명하진 않는다.

첫 직장의 규모가 커지면서 실력 있는 동료들을 많이 만났다. 함께 퇴사한 동료들이 성공적으로 유명 기업으로의 이직을 하고 있는 찰나였다. 나도 얼마 지나지 않아 좋은 소식을 전할 수 있을 것이라 믿었다.

그러나 코딩 테스트나 인터뷰는 철저히 개발자로서 '나의 실력'을 평가하는 자리이다. 그 자리에 선 나는 알고리즘 테스트를 주어진 시간 안에 수월하게 풀어내지 못했고, 기본적인 CS(computer science) 지식을 상세히 설명하지 못하는 사람이었다.

꼬리를 무는 질문에 당황하여 반대로 대답하거나 알던 내용도 한마디 꺼내지 못한 채 멘붕으로 마쳤던 몇몇 인터뷰, 손도 써보지 못한 알고리즘 문제들을 떠올리며 밤마다 이불 킥을 해대며 이 착각을 풀 수 있었다.


2. 많은 기업(좀 더 구분하자면 유명 기업)에서 알고리즘 테스트는 첫 거름망 역할을 하고 있다.

개발자로 커리어 전환을 준비하던 첫 구직 과정에서는 제대로 된 알고리즘 테스트를 치러본 적이 없었다. 서류에서 합격하는 확률도 낮았으니 알고리즘 테스트를 볼 수 있는 기회도 적었던 것이다.

그와 달리 3년 차 개발자가 되어 지원하게 된 기업에서는 셋 중 한 곳은 서류전형 직후 알고리즘 테스트를 진행했다. 평상시 알고리즘 테스트를 푸는 것이 얼마나 중요한지 머리로 알고 있었지만 바쁘다는 핑계로 많은 준비를 못했었고, 그 결과는 탈락이었다. 그간 내가 쌓아온 개발 경험이 어떻든 어쨌거나 첫 거름망은 잘 넘어가야 뽐낼 수 있다. 알고리즘 실력은 꾸준히 키워야 한다.


3. 기술 면접에서의 질문은 개발 실력의 중추를 확인하는 것이다.

구글에서 '프론트엔드 개발자 면접 질문'이라는 것을 치면 족보처럼 여러 질문들이 나온다. html/css, 네트워크, 브라우저, Javascript 언어, 모던 프론트엔드 프레임워크 등 그 영역도 다양하고 문제 은행식으로 상세하게 질문을 찾아볼 수 있다.

인터뷰 준비를 하면서 이런 질문들을 읽고 나만의 답으로 정리하긴 했지만 형식적이라는 생각을 많이 했다. 실무를 진행하면서 이런 내용을 깊이 생각할 시간이나 있나 싶어서였다.

그러다 5년 차 이상 개발자를 구하는 어느 기업과의 인터뷰를 통해 이 생각을 크게 깰 수 있었다. 경력이 있는 개발자를 뽑길래 실무에서의 경험이나 문제 해결 사연들을 풀어가면 되겠다는 생각을 가지고 인터뷰에 임했으나 실제로 대부분의 질문은 브라우저, Javascript 언어, css에 관한 "잘 알려진 질문"들이었다. 꼬리에 꼬리를 무는 질문을 모두 연결해보니 '프론트엔드에서의 성능 최적화에 대해 잘 이해하고 있는가'를 확인하려는 큰 맥락이 있었다. 물론 이 인터뷰 또한 시원하게 말아먹고 나서 이불 킥을 해대며 왜 내게 이런 질문들을 연쇄적으로 던졌는지 한참 생각해보다가 깨달은 것이다.

기술 면접에서 모든 질문을 잘 답하더라도 실제 구현 실력이 엉망일 수도 있다. 그러나 기본 지식이 탄탄하지 않고 구현만 뛰어난 사람의 문제 해결력은 모래성과 같을 가능성이 더 높다. 개발 실력의 중추는 늘 튼튼하게 유지해야 한다.


첫 이직을 마치며


한 달간의 시행착오를 겪은 후 두 번째 달에 들어 지원했던 모든 기업에서 합격 연락을 받았다.

알고리즘 테스트보다는 과제를 주고 과제 중심으로 인터뷰하는 곳으로, 최근 펀딩을 받아 공격적으로 규모를 키우는 기업보다는 사용자들이 많이 찾는 도메인과 IT 중심으로 제품을 풀어나가는 기업 위주로 그 방향을 맞춰가면서 지원한 결과였다.

추석은커녕 가을의 끝이 되어서야 개발자로서 두 번째 둥지를 찾게 되었다. 성공했다는 성취감보다 겁 없이 시작했던 백수 생활이 끝나 참 다행이라는 안도감이 컸고, 다 끝나서 손 탈탈 털고 싶은 마음보다 그동안 내가 몰랐던 것, 공부해야 하는 것들을 숙제로 받은 마음이 컸다.


누군가 본인의 실력을 확인하고 싶다면 구직 시장에 나가보라 하였다.

나는 왜 그간 이 부분을 공부하지 않았을까, 3년 차나 되어서 기술 면접 질문들을 속 시원히 답하지 못하는 부족한 내 실력이 창피했고 그 때문에 굉장히 고통스러웠다. 내 실력을 파악하기 위해 과제로 제출한 코드를 리뷰해주고 하나라도 답할 수 있도록 힌트를 던져주며 인터뷰를 진행했던 같은 업계의 선배들에게 감사한 마음도 들었다. 다음에 그들을 만나게 되면 더 공부하고 성장하여 지금보다는 나아진 나의 모습을 보여주겠노라 다짐했다.


이번 이직 과정 중 가장 마지막으로 진행했던 인터뷰에서 '2-3년 후 나는 어떤 개발자일 것 같냐'는 질문을 받았다. 나는 어느 때보다도 뚜렷하게 답했다.

단순 구현 외에 구조의 확장성을 고려하는 개발자
주어진 환경을 잘 이해하고 사용 가능한 기술의 장단을 파악해 최적이라 생각하는 기술을 동료들에게 설득하고 도입할 수 있는 개발자
의도를 파악할 수 있는 코드를 작성하는 개발자


얼렁뚱땅 시작한 이직 기간에 마냥 시간이 흘러가는 것에 대한 불안감이나 어딘가에 소속되지 못한 부유감 등으로 감정적 소모가 컸지만 어디서 일하고 싶은지 기준조차 찾지 못했던 몇 달 전의 어리숙한 모습에서부터 달라진 스스로를 느낄 수 있었다.


다사다난했던 개발자로서 첫 이직 과정을 맺으며

다시 한번 정신 차리고 새 둥지에 빠르게 적응해 나가기를…!




Photo by Hello I'm Nik on Unsplash

매거진의 이전글 응답하라 개발자 - 첫 커리어 회고
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari