글을 시작하며

지난 Teo Conf2기에서 "황폐화된 개발 환경을 기름진 개발 환경으로 만들기"라는 주제로 발표를 했습니다.

첫 발표라 걱정도 많이 하고 긴장도 많이 되었는데요, 걱정과는 다르게 많은 분들이 공감도 해주시고 응원의 메시지도 보내주셔서 올해 했던 일 중 가장 뿌듯한 일이 되었어요. 아마 개발자 커리어를 쌓아나가는 과정에 있어서도 오래오래 기억에 남을 추억이 되지 않을까 싶어요.

발표를 마치고 바로 회고를 해보려고 했지만, 회사일과 건강이슈(코로나)가 동시에 터지면서 이제서야 글을 작성하게 되네요. 발표를 준비하는 과정부터 그 이후에 대한 소감 위주로 정말 회고록처럼 다뤄볼까를 생각했는데 아무래도 발표 내용에 대해서 생각보다 많은 공감대를 얻게 되어 이대로 휘발시키기는 아까워 발표 내용 위주로 저의 경험을 공유해 보려고 해요.

과거의 저처럼 혹은 저보다 더 힘든 시기를 보내고 계시는 주니어들에게 조금의 위로와 격려가 되기를 바라며 글을 시작합니다.

스피커로 발표를 하게 된 계기

주니어 리드 개발자

저는 회사에서 프론트엔드 팀을 리드하고 있어요. 팀의 리드라고 하니까 연차가 많은 시니어 개발자라는 오해를 많이 겪곤 했지만 사실 저도 이제 개발을 직업으로 삼은지는 3년이 조금 안되는 주니어 개발자랍니다.

이직 제안을 받다

첫 직장에서 퇴사를 결정하고 분주하게 이직 준비를 할 때 이직 제안을 받았어요.

회사에서 내가 필요했던 이유

회사의 기존 비즈니스 모델은 고객에게 알맞은(가장 유리한) 대출 상품을 소개해 주고 수수료로 수익을 내는 방식이었어요. 저에게 이직을 제안했을 당시에는 법이 개정되어서 고객과 대면이나 유선상으로 직접 접촉할 수 없게 되었고, 회사는 기존의 비즈니스 모델을 IT화 시키고 핀테크 플랫폼으로 전환하고자 했어요. 그리고 그 과정에서 전 직장에서 인연이 닿았던 저의 합류를 희망했어요.

내가 회사에 합류하게 된 이유

당시의 저는 주니어 레벨에서 경험하기 힘든 일들을 많이 겪어볼 수 있다는 기회라고 생각했어요. 저의 첫 직장은 SI 업체였기에 만드는 서비스에 대해 애정을 가지지 못하고 떠나보내야 하는 경우가 많았어요. 그래서 그 부분이 몹시 아쉬웠는데 제품의 출시부터 운영까지 어쩌면 제품의 마지막까지도 겪어볼 수 있다는 생각이 들었어요. 그리고 한편으로는 조금 더 연차가 쌓이게 되면 주력 도메인을 바꾸기도 주저될 테고, 새로운 도전을 해볼 기회가 줄어들 텐데 지금 연차에 도전해 볼 수 있는 마지막 기회라는 생각이 들었어요.

그렇게 저는 이직을 결정했어요.

각오했던 것보다 더 처참했던 현실

그러나 막상 이직을 하니 현실은 각오했던 것보다 훨씬 더 처참했어요. 아무것도 갖춰지지 않은 회사에 주니어 개발자가 가게 되면서 기술적으로 맞닥뜨릴 걱정은 많았지만 실제로 제가 겪게 되었던 문제와는 결이 많이 달랐어요.

베테랑이었던 내가, 지금은 주니어??

비즈니스 모델이 바뀐다는 것은 기존 비즈니스 모델에서 필요했던 직무가 없어진다는 말이었어요. 그 말인즉슨, 기존에 이 분야에서 베테랑이었던 직원들이 낯선 업무에 새롭게 배치되어 일을 배워나가야 한다는 얘기였죠. 저의 이직과 동시에 기존 직원분들의 직무도 완전히 바뀌게 되었어요. 그리고 저는 IT 관련 업무를 처음 맡으신 분들과 여러 갈등을 겪는 것이 몹시 힘들었어요. 그리고 프로덕트를 만들어나가면서 IT를 조금 더 아는 사람(개발자)으로서 남들보다 더 많은 부분을 신경 쓰고 대응해야 했어요.

이해도의 문제로 겪게된 갈등들

다음은 실제로 제가 초기에 맞닥뜨렸던 문제를 조금 각색하여 다룬 내용이에요.

도망칠까?

이런 종류의 갈등을 계속해서 겪다보니 생각보다 빠르게 지쳐버렸어요. 그래서 한참동안 고민했어요.

"퇴사하고 도망칠까? 아니면 회사는 적당히 다니면서 이직 준비를 할까?"

하지만 퇴사하거나 이직하는 것도 쉬운 결정은 아니었어요.
경제적인 부담도 있었고, 짧은 이직 주기가 제 커리어에 나쁜 영향을 끼치지 않을까라는 고민도 있었어요. 하지만 제일 저를 힘들게 했던 고민은 "이직하면 정말 다를까?" 라는 고민이었어요.

그러다가 개발자 행사에 참가해서 소위 "네카라쿠배"라고 불리는 빅 테크 기업의 시니어 개발자와 이야기 나눌 기회를 얻었어요. 그래서 저는 이렇게 물어봤어요.

나: 제가 지금 이런 갈등과 어려움을 겪고 있는데 조금 더 큰 회사로 가게 된다면 이런 일을 더 이상 겪지 않아도 될까요?

그리고 제가 예상했던 대답과 전혀 다른 답변이 돌아왔어요.

시니어 개발자: 여기도 다 똑같아요.

라면서 말이죠. 제가 겪고 있는 일들이 레벨의 차이는 있겠지만 개발자로서 반드시 겪어야 하는 일이며 어느 기업을 가더라도 쉽게 피할 수 없다는 얘기를 해주었어요. 그래서 저는 조금 생각을 바꿔보기로 했어요.

오히려 주체적으로 해결할 수 있는 기회를 맞이한 것은 아닐까? 그리고 여기서라면 (당시 수준이 확연히 낮았기 때문에) 더 많은 변화를 이루어낼 수 있겠다는 생각을 하게 되었어요. 그리고 이 과정의 끝에 분명히 나에게 남는 것이 있을 것이라 생각했어요.

그렇게 저는 개발과 관련된 문화라고는 아무것도 없는 황무지에서 새롭게 시작하는 것을 받아들였어요.

그래서 지금부터 제가 들려드릴 이야기는 지금보다 더 주니어 개발자 였던 제가 어떻게 발버둥쳐서 이 환경을 개척하고, 무엇을 바꿨고, 어떤 게 남게 되었는지에 관한 이야기예요. 그럼 지금부터 제가 어떻게 발버둥 쳤는지에 대한 이야기를 들려드릴게요.

소통 채널부터 하나로 만들자

우리 Slack으로 메신저를 통일해요!

여러분의 회사에서는 어떤 메신저를 사용하고 계시나요? 합류 당시 회사에서는 놀랍게도 메신저를 3개나 사용했어요! 외부 활동이 필요한 부서는 카카오톡을 사용하고, 전사용으로는 사내 메신저를 사용했고, 개발팀은 Slack을 사용하고 있었어요. 이거 뭔가 잘못되었다고 생각이 들어서 처음에는 무턱대고 이렇게 주장했어요!

개발팀이 슬랙을 사용하는데 엄청 편리해요! 자동화할 수 있는 부분도 많고, 기능도 다채로워요 그러니 전사 메신저를 슬랙으로 통일했으면 좋겠어요!

모든 설득에는 근거가 필요하더라

당연하게도 바로 회사가 수긍하기는 어려운 주장이었어요. 회사에서는 이미 3개의 메신저로 충분하다고 생각했는데 왜 가장 비싼 슬랙을 사용해서 일을 해야 하는지에 대해서 이해하지 못했어요. 저는 이때 회사에 “당연하다고 생각하는 무언가”를 바꾸기 위해 제안을 할 때도 "상황과 이해관계에 맞는 설득”이 필요하다는 것을 깨달았어요. 그리고 다음과 같이 설득할 자료를 준비해 기회를 달라는 요청을 드렸어요.
설득하는 내용에는 Slack으로 메신저를 통일했을 때 어떤 이점을 우리 조직에 가져다 줄지에 대해서 담았어요.

1) 공유가 되지 않는다.
사용되는 메신저가 3개니 주로 사용되는 메신저 범위 내에 국한되어서 다른 메신저를 주로 사용하는 부서와 내용 공유가 힘들다는 문제점을 지적하고, Slack의 채널 생성 및 태그 등의 기능을 소개해서 구성원끼리 공유해야 할 내용을 빠르게 공유하는 것을 장점으로 소개했어요.

2) 기록이 남지 않는다
아무래도 개발을 하다 보면 히스토리 관리가 필수적이잖아요? 하지만 메신저를 3개로 쓰다 보니 히스토리도 산발적이고 심지어 앞에서 예시를 들었던 것처럼 톡 서랍등의 유료 결제도 이뤄지고 있지 않다 보니 저희가 나누었던 생산적인 대화들이 모두 휘발되는 것을 막을 수 있다고 어필했어요. 그래서 직접 슬랙에서 검색하는 방식을 시연하기도 하고 기존 메신저에 비해서 얼마나 더 편리하게 기록을 찾아볼 수 있는지에 대해서 담았어요.

3) 불필요한 과정을 자동화 할 수 있다
저희 회사는 지금도 그렇지만 당시에는 더더욱 빠르게 프로덕트를 만들어서 정책에 대응해야 하는 일이 많았어요. 그래서 조금이라도 더 개발하고 검수하고 출시하는 과정에 있어서 군더더기가 없어야 했어요. 그래서 Slack을 도입했을 때 자동화나 봇을 사용해서 불필요한 액션 등을 줄이고 그 시간에 더 생산적인 일을 할 수 있다는 주장을 했어요. 특히 배포의 시작과 끝, 혹은 배포 과정이 잘못되었을 때를 알려주는 배포 봇이 큰 호응을 얻었어요.

이렇게 3가지의 큰 주제로 Slack의 도입을 주장했어요.

우리 Slack으로 메신저를 통일했어요

그 결과 모든 직원이 Slack을 통해서 하나의 채널에서 다 함께 소통할 수 있게 되었어요.

같이 잘하기

이제 소통의 수단을 하나로 만들었으니 이를 바탕으로 어떻게 다른 직군과 소통하면서 일을 더 잘하기 위해 노력했는지 말씀해 드릴게요.

소통의 채널을 통일했으니 단어도 통일하자

편가르기를 할 때 손바닥을 위아래로 뒤집는 이 행위.
여러분은 뭐라고 부르셨나요? 데덴찌, 젠디 제엔~디, 뺀다뺀다 또뺀다, 소라메치기 등 다양한 단어로 불리는데요.
놀랍게도 회사에서 일을 할 때도 이런 현상이 벌어지고 있었어요!
화살표가 가리키는 UI 요소를 어떤 사람은 드롭 다운, 다른 사람은 드롭박스이라고 부르고 개발자들은 셀렉트, 심지어 필터라고 부르기도 했어요. 같은 요소를 보고 서로 너무 다르게 표현한 거죠!

물론, 프론트엔드 개발자인 저는 이것을 "셀렉트"라고 부르는 것이 익숙하지만 그게 정답이라고 할 수 있을까요? 우리도 간혹 복잡한 요구사항의 셀렉트를 구현하면서 “셀렉트” 태그를 쓰지 않곤 하니까요. 그래서 저는 누구의 잘못도 아니라는 생각이 들어서 우리끼리 소통할 때 혼선을 만들지 않기 위해 용어를 먼저 맞춰나가자고 마음을 먹었어요. 기껏 Slack으로 소통의 채널을 하나로 만들어놨어도 서로 다른 언어를 쓰면 무의미하기 때문이었죠.
그래서 저는 어떻게 통일하지? 한참 고민을 하다가 우리 서비스에서 사용되는 라이브러리이면서 비 개발자도 보기 어렵지 않은 Antd라는 컴포넌트 라이브러리의 사이트를 떠올렸어요. 사이트에는 기획자나 디자이너가 쉽게 볼 수 있을 만큼 예시가 잘 나와있어서 따로 용어에 대한 정리를 할 필요도 없었고 심지어 Admin을 개발할 때 추상적으로 전달되던 기능 명세도 Antd에서 제공하는 기능을 바탕으로 전달하도록 했어요. 용어도 정리되면서 라이브러리에 있는 기본 기능을 활용한 기획으로 생산성까지 조금 더 챙길 수 있게 된 거죠!
이후에도 UI 요소뿐만 아니라 개발자가 아니라면 헷갈릴 수 있을만한 용어들을 모아서 간혹 세미나도 진행하며 서로 같은 용어로 소통할 수 있도록 했어요.

일하는 방식도 맞춰나가보자

그렇게 기획자, 디자이너와 용어를 맞춰나가다 보니 이제 "단어를 통일" 하는 영역을 넘어서 일하는 방식을 맞춰보고 더 우아하게 일을 해봐야겠다는 생각이 자연스럽게 들었어요.

먼저, 개발자가 기획자와 디자이너를 업무를 이해하는 것보다 다른 직군이 개발자의 업무와 사고방식을 이해하는 것이 더 어렵다고 판단했어요. 왜냐면 개발이라는 게 굉장히 생소한 분야잖아요. 맨날 안된다고 하고, 조금만 바꿔달라는 데 일주일이 걸린다고 하고, 반대로 생각해 보면 도통 이해하기 어려운 일이에요.
그래서, 조금 간접적으로 저희를 이해시키기 위해 작전을 세웠어요. 당시 기획, 디자인 파트를 관리하고 있던 리더분에게 몰래 책을 추천한 거죠. 개발자가 저 책을 직접 추천한다면 타 직군분들은 거부감을 느낄 수 있을 것이라는 생각 때문이었어요. 그렇게 리더분에게 메시지를 보내고 조마조마하고 있었는데요.
다행히 다른 직군도 제가 느꼈던 것처럼 더 나은 소통에 대한 갈증을 느끼고 있었다며 수용해 주셨고, 심지어 당시 회사에서 꽤 높으신 직책을 가지고 계셨던 분이 저렇게 몸소 인증샷까지 보내주셨답니다.
저는 여기서 더 동기부여가 되어서 개발자보다는 기획자나 디자이너들이 더 관심 있어할 주제들도 가져와서 공개된 채널에 역으로 제안해 보기도 했어요. 맨 처음에는 위에서처럼 반응도 적고 댓글도 없었어요.
하지만, 여러 번 반복하다 보니 지금은 무척이나 반응도 많아지고 올라온 글을 주제로 다양한 부서에서 서로 스몰토크를 진행하는 문화가 생겼어요! 그러다 보니 조금 더 욕심이 나서 더 열정 있는 직원들, 관심사가 비슷한 직원들과 함께 성장을 하고 싶어졌어요. 제가 이끌어주는 성장에 그칠 게 아니라 서로가 성장을 북돋아 줄 수 있는 관계가 되기를 바랐어요.
그래서 각자 개선하고 싶은 일들 그리고 관심 있는 영역들, 그리고 공부에 대한 의지가 얼마나 있는지를 조사해서 비슷한 곳을 바라고 달리는 열정 있는 희망자에 한 해 스터디를 진행하기로 계획하고 절찬리에 진행 중에 있어요.

그렇게 우리 조직이 같이 잘하며, 함께 자라도록 만들었어요.

너! 내 동료가 되라

“개발 문화를 근사하게 바꿔나고 있구나!”라고 생각이 들 때쯤, 미뤄두었던 기술 부채가 눈에 들어오기 시작했어요. 그리고 더 이상 저 혼자서는 이 기술 부채를 해결하기는 버겁다는 생각이 들었어요. 그래서 회사에 채용이 필요하다는 의견을 내었고, 다행히 회사에서도 채용에 대해 긍정적인 답변을 주셨어요. 그래서 채용공고를 내고 지원자를 받기 시작했어요.
하지만, 기대와는 달리 지원자가 너무 적었어요.
왜 지원을 하지 않을까? 고민하다가 대수롭지 않게 생각한 채용공고 내용을 다시 보았어요. 제가 지원자라고 하더라도 우리 회사에 큰 지원 동기가 생기지 않겠더라고요. 그저 추상적인 자격요건들을 나열해두었고, 선택이 아닌 필수가 되어버린 Typescript에 관한 이야기도 일절 없었으니 말이죠.
그래서 다른 회사의 채용공고를 한참 들여다봤어요. 그러면서 내가 지원하고 싶은 마음이 드는 회사들을 모아보니, 우리 채용공고에도 이런 내용을 추가하고 싶다는 생각이 들었어요! 그런데 없는걸 쓸 수는 없잖아요? 그래서 한참을 고민하다가
“채용공고를 채우기 위해서 내가 더 성장해서 채워 넣자!”라는 마음가짐으로 새로운 도전을 하게 되었어요.
요즘 개발 스택 중 필수로 알아야 된다고 생각이 드는 것들을 위주로 먼저 공부하고, 그중 회사에 필요하기도 한 기술들은 야근을 해서라도 최대한 빠르게 적용시켰어요. 그렇게 적용된 기술들은 "자격요건"란에 기입할 수 있었어요. 그리고 당장 적용은 못하지만 앞으로 회사에서 적용할 예정이 있거나 합류해서 함께 연구해 나가고 싶은 기술들은 "우대사항"에 기술했어요.

마지막으로 저와 함께 개발 문화를 개선해 나갈 사람들을 원했기에

"개발 문화 발전에 기꺼이 함께해 주실 분"

이라는 문구를 우대사항에 마지막으로 넣었어요.
그렇게 수정한 채용공고를 등록했더니 10명 정도였던 지원자의 수가 150명 넘게 지원하는 수준으로 급상승했어요. 쏟아지는 이력서를 보느라 업무에 차질이 생겨서 예정보다 빠르게 채용공고를 내리는 경우도 발생했어요.

그리하여 함께 개발 환경을 일궈나갈 멋진 동료들을 얻을 수 있었어요!

근데 또 남은 게 동료뿐만이 아니었어요. 놀랍게도 채용공고를 채우기 위해 발버둥 치고 밤을 지새우며 노력했던 경험이 저에게는 큰 지식이라는 부산물을 남기게 되었어요. 기술의 부채를 해결하고자 동료를 모집하는 과정에서 더 나은 동료를 얻기 위해 제 스스로 더 나은 개발자가 된 것이죠.

주니어 리드 개발자

그렇게 아무것도 없던 땅에 홀로 떨어졌던 주니어 개발자는 졸지에 비슷한 연차의 동료들, 그리고 팀을 이끄는 리드 개발자의 역할을 해야 했어요.
새로운 동료들이 오면서 Typescript도 도입하고, Husky로 자동화도 하고, 나 혼자서는 당연히 할 수 없었던 코드 리뷰도 하면서 정말 많은 부분이 좋아지고 있었어요.
그런데 한편으로는 제 스스로 위기감을 느꼈어요. 회사 입장에서 제가 아닌 비슷한 연차의 다른 개발자라는 비교의 대상이 생겼으니까요!
그렇게 위기감을 느꼈던 순간, 부끄럽게도 아주 잠깐 자만했던 시기가 있었어요. "나는 스타트 멤버고, 개발의 모든 히스토리를 알고, 조직 문화를 얼마나 많이 개선했는데?"라고 생각을 했었어요.

그러던 찰나에 문득 이런 생각이 들더라고요. 이런 배경 없이 다른 곳으로 갔을때, 그게 내 실력이라고 할 수 있을까? 개발자로서 내가 평가받을 때 부끄럽지 않을 수 있을까?

그래서 "이제는 주니어에서 벗어날 때가 된 것 같다!"라고 생각하며 리더로서 해야 할일을 찾기 시작했어요.

먼저, 정신을 차리고 리더로서 채용한 실력 있는 동료들에게 당당하기 위해서, 내 자신이 주니어에서 벗어나기 위한 개인의 성장을 일궈내는 기간을 가졌어요. 회사가 끝나면 스터디도 하고, 미뤄두었던 개발 관련 서적도 읽고, 인터넷 강의도 출퇴근 시간에 보고, 사이드 프로젝트도 진행하며 저 자신을 혹독하게 성장시켰어요.

그리고 리더로서 팀원들이 더 윤택하기 일하기 위한 환경 만들어줘야겠다 라고 생각하고, 회사에 적극적으로 어필하여 노션 결제를 승낙 받았어요. 그리고 노션을 도입하면서 저도, 동료들도 더 개발에 집중할 수 있게끔 여러 가지 시스템을 만들었어요.

먼저, 파편화되었거나 코드 리뷰상에만 남아있던 저희 팀의 컨벤션을 문서화했어요.

다음으로, 아이디어라는 제도를 만들었어요. 아이디어는 평일에 업무를 보면서 나누고 싶던 이야기들을 칸반 보드 형태로 남겨 매주 금요일 오전에 토론하는 시간을 가지는 제도에요. 아이디어 제도를 통해서 업무에 집중해야 할 때는 흐름을 그대로 가져가고 논의하고 싶던 이야기는 칸반 보드로 남긴 후 정해진 시간에 서로의 아이디어에 공유하며 우리 개발 환경을 일궈나가는 추진력이 되었어요.

그리고 KPT 형식의 주간 회고록도 진행하기 시작했어요. 매주 서로가 어떤 문제(개발 외적인 문제를 포함)를 맞이하고, 어떻게 풀어나갔는지 그리고 어떻게 더 발전해나갈지 공유하며 서로를 격려하고 북돋아 주었어요.

그리고 개발에만 몰두할 수 있도록 외부에서 오는 노이즈를 최대한 차단시키도록 다음과 같은 노력을 했었어요. 다른 부서와 함께 수많은 논의를 거쳐서 프로젝트를 노션으로 관리하기 시작했어요. 노션으로 전환하며 기획팀 주도(PM이나 PO가 따로 없던 상황)로 일정관리를 시작하게 함으로써, 개발팀이 복잡한 일정관리에서 벗어나서 조금 더 개발에만 신경 쓸 수 있도록 유도했어요.

오류 접수 양식도 개발에만 집중하도록 변화시킨 방법 중 하나인데요. 오류를 접수 시에 비 개발자도 충분히 기입할 수 있는 항목들의 양식을 만들어서 우리 팀원들이 불필요한 QA로 시간을 허비하는 것을 막았어요.

그렇게 저는 기술적인 성장을 통해서 제 자신에게 당당하고 더 나은 업무환경을 동료들에게 만들어주며 동료들에게 인정받는 주니어 리드 개발자가 되었어요.

앞으로 더 가꿔나갈 것들

그리고 우리 팀은 앞으로도 멈추지 않고 새로운 도전들을 해보려고 해요.

먼저 올해 안에 테스트 코드를 도입해서 안정성을 높히고, 다양한 라이브러리들의 버전업 등을 통해서 성능 최적화에 도전해 보려고 해요.
그리고 내년 중으로 우리가 얻었던 지식들과 경험을 남들에게 공유할 수 있을 만큼 멋지게 정리하여 기술 블로그를 게시하겠다는 야망을 가지고 있어요.

글을 마치며

여기까지 다뤘던 이야기는 제가 어떻게 개발 환경을 가꾸어왔는지 그리고 앞으로 어떻게 더 가꾸어 나갈지에 대한 내용이었어요. 제가 컨퍼런스를 준비하면서 돌이켜보니 이러한 고난들도 결국 “개발”이라는 큰 흐름 속에서 필연적으로 겪게 되는 하나의 과정이더라고요.

기획자와 디자이너와 함께 소통하는 것도, 채용을 통해서 동료를 찾고 성장하는 것도, 더 나은 환경을 만드는 것에 대해 끊임없이 고민했던 것도 언젠가는 개발자라면 누구나 맞이하게 될 한 과정일 뿐이었어요. 그리고 저는 그 과정을 남들보다 낮은 연차에 일찍 겪게 된 것뿐이었죠.

그래서 저는 이 글을 읽은 여러분에게 이런 이야기를 해주고 싶어요. “이상적인 개발 환경”이라는 환상을 좇지 마시라고요.

소위 네카라쿠배라고 불리는 기업들의 경우에도 “이상적인” 개발 환경, 확실한 체계와 프로세스가 과연 존재할까요? 물론 정도의 차이는 있겠지만 그런 우리가 익히 알고 있는 기업들조차도 체계가 부족하고 비즈니스 일정을 맞추기 위해서 많은 부분에서 애를 먹고 포기하는 경우가 있다고 해요.

완벽한 프로세스가 없는 곳에 새로 합류하게 된, 연차가 적은 주니어 개발자분들의 경우에 상상했던 개발과정과는 다른 현실을 맞이하며 “이상과 현실에 대한 괴리감”을 느끼고 그 “괴리감 속에서 실망감”을 느끼시더라고요. 그리고 더 한 경우에는 “아 왜 내가 조금 더 노력해서 더 좋은 곳으로 가지 못했지?”라면서 자책하며 힘들어하시는 경우도 있어요.

테오의 프론트엔드 방이나 개발 커뮤니티를 보다 보면 옛날의 저와 비슷하거나 혹은 더 힘든 환경에서 시작하는 주니어 개발분들도 많은 것 같아요. 그리고 간혹 생각했던 “이상과는 다른 현실"에 속상함을 토로하는 분들도 많이 뵙게 되는 것 같아요.

하지만 여러분들을 위해서 이렇게 생각해 보면 어떨까요? "지금의 환경이 이상적이지 못하다는 것은 그만큼 내 손으로 바꿔나갈 수 있는 부분이 많다는 얘기"라고 말이에요.

멋지게 표현한다면 그만큼 내가 성장할 수 있는 기회가 주어졌다는 것이고, 우리끼리 조금 더 솔직하게 표현한다면 실적을 낼 부분이 많고, 여러분이 이력서에 기술할 수 있는 부분이 남들보다 훨씬! 많다는 것이에요. 그리고 이 경험은 여러분의 커리어에 분명 긍정적인 영향을 미칠 거에요.

그래서 오늘 저의 이야기가 여러분에게 조금의 동기부여가 되었다면 좋겠다고 생각했어요. 제가 말씀드린 이야기가 정답이라는 것은 절대 아니에요. 저의 경험들보다 더 심각하고, 더 황폐화된 환경에서 일을 하고 있는 분들도 분명 계실 거예요. 다만, 여러분은 황폐화된 개발 환경에서 조금 더 기름진 개발 환경으로 가꾸어 나가기 위해 발버둥 쳤던 저의 이야기를 듣고 현실에 대한 도피가 아닌 조금의 위로와 조금 더 나은 환경으로 바꿔보려는 용기를 얻어 가기를 바랄 뿐이에요.

온라인상에서도 커피 챗을 하다가도 개발자 행사에서 만나더라도 언제 어느 공간에서 만나더라도, 서로를 위로하고 북돋아 주기를 바라면서 글을 마칩니다.

이상과 현실의 괴리감속에 힘들어하는 주니어 여러분이 조금의 위로와 용기를 얻기를 바라며

---

추신 1) 저의 이야기를 나눌 수 있는 기회를 만들어 준 테오, 그리고 발표를 만들어 나가기 위해 많은 피드백과 도움을 주었던 스피커(허브, 오웬, 준, 달리)에게 다시 한번 감사를 표합니다.

추신 2) 다른 곳보다 갖춰지지 않은 환경에 합류해 적극적으로 개선하기 위해 애쓰고 있는 우리 프론트엔드 팀원들에게 항상 진심으로 고맙고 또 어디서 이런 좋은 동료들과 일할 수 있을까라는 생각만 자주 하게 되는 요즘이네요 감사합니다.

추신 3) 발표가 끝난 직후, 그리고 그 이후로 이메일과 링크드인으로 인사주시고 제 경험을 토대로 시도해 보거나 잊고 있었던 열정을 다시 한번 느끼게 되었다고 응원의 메시지를 보내주신 분들 모두 감사합니다. 정말 큰 동기부여가 되어 이후로 제가 더 좋은 사람이 되고자 많은 노력을 하고 있습니다. 연락 주신 모든 분들의 앞날에 좋은 결과가 있기를 바랍니다 :)

---

링크드인
이메일: teabs1125@gmail.com