삐뚤어진 MZ 신입사원에서 신임받는 프로젝트 리더로
얼마 전 회식자리에서, 팀장님이 제 칭찬을 하시면서 팀장 회의에서 프로젝트 리드를 맡긴다고 했을 때, 아무도 우려를 표하지 않을만큼 신임받는 사람이라고 말해주셨습니다.
문제가 생기면 가장 먼저 의심받던 MZ 신입사원이었는데, 이제는 내가 많이 변했구나 싶은 생각이 들었습니다.
입사 초반을 돌이켜보면 함께 일했던 분들에게 죄송하다는 말씀을 드리고 싶어요. 책임감없는 태도로 불만만 가득했던 제 모습이 지금도 부끄럽습니다. 지금은 개발실력이 늘었다 기 보다는, 어느샌가 사람들을 대하는 태도가 변했고 이전에 비해 성숙해진 모습이 되었다고 느껴져요. 그리고 지금, 취업한지 2년이 좀 넘은 시점에서 그동안의 회사생활에 대한 회고를 해보려고 합니다.
제가 다니는 회사는 자체 서비스를 운영하고 있고, 40명 정도 되는 인원을 가진 작은 스타트업입니다. 입사 초기에는 개발을 잘하고 싶었어요. 개발자는 개발로써 인정을 받는다고 생각했고, 좋은 시니어 밑에서 코드리뷰를 받으면서 성장하고 싶었어요. 그렇지만 제가 입사한 곳의 팀장님은 리액트를 전혀 모르시는 시니어 개발자셨고, 팀의 관리를 위해 임명된 분이었어요. 또, 프론트엔드 팀원은 저 같은 신입 개발자로만 이루어진 신생팀이었습니다. '이런 곳은 성장할 수 없는 회사야!' 라고 생각하면서, 딱 3개월만 일하고 퇴사하자 라면서 첫 직장생활을 시작했어요.
서론이 길었네요. 지금부터는 3개월만 일하고 퇴사한다는 신입사원이 적는 2년 근속 회고입니다.
최고의 복지는 동료
그렇게 책임감 없던 제가 회사를 계속해서 다니게 된건 두가지 이유가 있었어요. 첫번째로는 이직에 성공하지 못한 것입니다. 당연한 일이겠죠. 그동안 계속 불합격만 받던 비전공 신입 개발자가 회사와 병행하면서 준비한다고 성공할 수 있을까요. 그리고 두번째는 지금도 함께하고 있고, 감사드리는 프론트팀을 포함한 동료들 덕분이었습니다. 그 당시에는 '왜 이런 회사에..?' 라고 느껴질만큼 잘한다고 생각했고, 지금도 한명한명 엄청난 능력이 있다고 생각해요. 주니어 개발자로서 함께 성장해나가면서 코드와 지식을 공유하는 경험은 너무나 즐거웠고 도움되는 일이었어요. 과연 앞으로도 이런 팀을 만날 수 있을까? 라는 생각이 들 정도로 제게는 완벽한 팀이었습니다.
특히나 프론트엔드팀은 제가 애정을 갖고 있는데요. 제가 좋아하는 영화인 엑스맨처럼, 저희 팀원들은 모두 특별한 능력을 갖고 있었어요. 기술 트렌드에 밝아 이런저런 기술을 시도해보면서 지식을 공유해주는 분도 있고, 기술 자체에 대한 관심으로 자바스크립트나 브라우저의 동작방식이나 개념을 상세하게 아시는 분도 있었죠. 어떤 분은 정말 다른 레벨의 수준으로 문서작성을 하시고, 심지어 문서 쓰는 것을 즐겼어요. 한번은 그분의 작업들을 인수인계 받게 된 적이 있는데, 문서만 봐도 프로젝트의 흐름과 진행과정을 알 수 있어서 감탄하기도 했어요. 마지막 한분은 모든 사람이 좋아하는 사람이었어요. 그분이 활짝 웃으며 커뮤니케이션하는 모습을 보고 있으면 이것도 다른 레벨이겠구나 싶었어요.
그리고 저는 항상 저희 팀원분들을 유심히 지켜보면서 그 능력들을 가지려 했어요. 팀원 분들이 멋진 히어로라면, 전 마치 원피스의 검은수염 티치 같네요. 기술 트렌드를 컨퍼런스 영상이나 특정 아티클에서 얻는 것을 보고 유명 컨퍼런스들을 챙겨보고, 오프라인 컨퍼런스에 참석해보기도 했어요. 자바스크립트를 포함한 소위 기본기에 대해 잘 알고 계신 분께는 특히 질문을 많이 드렸는데요. 개발 도중 문제가 발생할 때, 동작원리와 흐름에 의거해서 문제를 찾아내는 모습을 보면서 개인적으로 많이 배울 수 있었습니다.
팀원분들의 이런 모습들을 보면서 나는 무슨 능력을 가지고 있을까? 하는 생각도 정말 많이했는데요. 퇴사하는 날, 여러 사람들과 여러번의 식사와 커피타임을 가지면서 제 능력이 무엇인지 알려주셨어요. 이 능력들은 퇴사 회고에 마저 적도록 하겠습니다.
시니어에 대한 존경
좋은 동료들과 회사를 다니게 되면서 크게 느낀점이 또 하나 있는데요. 바로 존경심입니다.
높은 DAU와 화려한 아키텍처, 최신 기술이 좋은 서비스 회사의 지표라고 생각했던 어린 날에는 '이 회사는 배울 것이 없는 곳이야!' 라고 생각했어요. 하지만 알고보니 저같은 MZ 신입사원을 사람구실할 수 있게 만들어줄 만큼 정말 존경스러운 사람들이 모여있는 곳이었습니다.
20년이 훌쩍 넘는 시간동안에도 꾸준히 개발을 공부하시는 시니어분들도 있었고, 마흔이 넘는 나이에도 해외 취업을 위해 영어를 공부하시는 시니어분도 계셨어요. 주니어 분들의 커리어를 위해 진지하게 고민하고 도와주는 모습이나, 감정을 조절하지 못한 채 격앙된 모습을 하는 주니어에게 부드럽게 왜 이렇게 개발이 진행되고 있는지를 알려주는 시니어분들의 모습을 보면 개발자라는 타이틀을 넘어 정말 존경스러운 사람이라고 생각되었어요.
사회 생활에서 배운 얕은 지혜
그리고 짧게나마 사회생활을 하면서 얕게나마 알게된 것도 있습니다.
싫은 사람이 생기면 내가 손해다. 그리고 사람은 누구나 입체적이다.
저는 누군가가 싫어지면 그사람의 행동 하나하나에 신경쓰게 되고, 혼자서 스트레스 받게 되는 것 같아요. 그래서 애초에 누군가를 싫어하지 않는 것이 그 사람을 싫어하는 것보다 좋은 선택임을 알았어요. 사람을 싫어하지 않는다는 것이 말이 안된다싶지만, 사람은 누구나 입체적이라고 생각하니 크게 어렵지는 않았어요. 모두가 좋아하는 사람은 없듯이, 모두가 싫어하는 사람은 없으니까요. 누군가의 단점이 보이기 시작하면, 이 사람의 단점보다 장점을 보려 노력하려고 합니다.
또, 절대 남을 비난하지 말자. 비난에 굳이 동조하지 말자 라는 것도 마음에 새겼는데요. 회사 생활을 하다보면 앞에서든 뒤에서든 남을 비난하는 모습을 종종 볼 수 있죠. 하지만 그럴 때 마다 비난하는 대상보다는 비난하는 사람이 좋지 않게 보이더라구요. 내가 누군가를 비난하면 남들도 나를 그렇게 보겠구나 라고 생각하니, 남을 비난하지 않도록 다짐하게 되었어요. 혹여나 누군가 남을 비난하는 모습을 보더라도, 그 분위기에 휩쓸려서 굳이 비난할 필요도 없는 것 같아요. 그런 상황에서는 대부분 제가 동조하지 않아도 말을 내뱉는 것만으로도 충분히 만족하는 것 같아요.
지 금 생각하는 잘하는 개발이란?
개발자끼리 이야기를 하다보면 잘하는 개발은 무엇인가? 라는 주제가 자주 등장하곤 하는데요. 저는 항상 가독성 좋은 코드를 짜는 것이 잘하는 개발이라고 했었는데, 어떻게 해야 가독성 좋은 코드이냐 라고 묻는다면 자세히 답하기가 어려웠습니다. 지금 생각하는 잘하는 개발은 그것과 같은 궤를 하고 있지만, 조금 더 구체적으로 말할 수 있습니다.
회사에서 하는 개발은 지금의 동료 뿐만이 아니라, 과거와 미래의 동료 혹은 자신과 협업을 해야 할 수도 있습니다. 그리고 그 과정에서 쉽게 적응하고 개발하기 좋았던 코드들은 높은 응집도와 낮은 의존성을 가지고 있었습니다. SOLID 원칙처럼 너무 흔하고 당연한 점이지만, 직접 겪어보니 더 크게 와닿더군요. 이미 개발되어 있는 기능과 비슷한 기능을 개발할 때, 낮은 의존성을 가진 컴포넌트를 재조합 하다보면 정말 몇 배로 빠른 개발이 가능했습니다. 앞선 개발자에 대한 존경은 덤이구요. 또, 기존 기능을 수정하거나 유지보수 할 때에면 높은 응집도가 빛을 발했습니다. 어떤 문제가 생겼을 때, 해당 기능의 이름을 가진 폴더 혹은 파일을 찾으면 끝이었으니까요. 수정이 필요한 기능들은 대체로 같은 폴더에 놓여져 있기 때문에 사이드이펙트를 검증할 때에도 큰 어려움이 없었습니다.
불편한 코드를 짜는 것도 잘하는 개발이구나 라고 느끼기도 했는데요. 제가 본 잘하는 개발자분들은 협업을 위해서 일부러 불편한 코드를 짜기도 했었어요. enum이나 zod같은 기능을 사용하기도 하고, 특정 키값들을 constant로 설정하여 한 파일에서 관리하도록 하도록 강제하면서 협업을 하는 사람이 실수하지 못하도록 강제하는 것이죠. 멋있는 말로는 휴먼 에러를 줄이는 것이라고 하더군요.
또, 실무에서 말하는 잘하는 개발에는 코드 만큼이나 중요한 것이 있다고 생각하는데요. 바로 일정에 맞추는 개발입니다. 개발을 할 때마다 협업 과정에서 병목현상이 생기거나 CS(Consumer Service)를 우선적으로 처리해야 하는 일들이 빈번했는데요. 단순히 기능 개발에 필요한 기술이나 분량로는 책정할 수 없는 일정들을 겪으면서 이런 것 까지 맞출 수 있는 개발자가 진짜 잘하는 개발자가 아닐까 싶었어요.
꾸준히 공부하는 방법
2년 간 회사생활을 하면서 제가 자부하고 싶은 점이 하나 있습니다. 바로 꾸준히 공부해왔다는 점인데요. 물론 이런저런 사정으로 짧게는 일주일, 길게는 한달까지 쉴 때도 있었지만, 대체로 개발을 손에서 놓지 않았다고 생각합니다. 제가 이럴 수 있었던 건 함께 공부했기 때문이 아닐까 싶은데요. 저는 매주 일요일마다 봉천역에 있는 청년공간에서 개발 스터디를 하고 있는데요. 그냥 개발자끼리 모여서 각자 하고 싶은 개발을 하는 것입니다. 그리고 그 과정에서 꾸준히 나오는 사람들을 보면서 서로 동기부여를 받기도 하고, 네트워킹도 하다보니, 매주 일요일마다 나가는 것이 어렵지 않게 느껴졌어요.
하지만 각자 공부하다보니 어느순 간 내가 재밌어하는 개발만 하게 되었고, 이직이나 회사에서 원하는 지식들과는 거리가 먼 공부를 하게 되더라구요. 때문에 신기술 사용과 같이 내가 재미를 느끼는 개발은 평일에 하고, CS 공부와 같이 필요한 공부는 주말에 하는 것으로 정하기도 했어요.
그리고 이것은 실패에서 배운 경험이기도 한데요. 저는 어떤 목표를 정할 때 너무 큰 목표를 세우는 것보다 작은 목표 여러개를 두는 것이 좋았어요. 사이드 프로젝트 같은 경우를 예를들면 사이드 프로젝트 완성! 을 목표로 세우는 것은 목표를 달성할 때 까지 오랜 시간이 걸리다보니, 보상을 받지 못하는 느낌이 들고, 흥미도 떨어지더라구요. 때문에 언제까지 특정 기능 개발! 과 같이 조금 더 짧은 기간의 구체적인 목표를 세우는 것이 동기부여에도 좋은 기능을 했어요. 작은 목표를 이뤘을 때에도 기분좋게 쉴 수 있기도 했구요.
함께 일하고 싶은 사람이 되자
2년이라는 시간동안 저는 스스로 꽤 많이 성장했다고 생각하는데요. 막상 회고를 적어보니 생각보다 훨씬 더 하고 싶은 말이 많아서 엄청 길어졌네요. 그리고 아직도 다 못다한 이야기가 많은데, 이는 퇴사회고에서 다시 다뤄볼까 합니다. 그래도 이 기나긴 회고를 한 문장으로 요약하라 한다면, "함께 일하고 싶은 사람이 되자" 로 정하고 싶어요. 결국 개발을 잘하는 사람이나, 일을 잘하는 사람, 그리고 존경받는 사람들은 결국 함께 일하 고 싶은 사람이니까요. 회고라는 것은 사실 다른 사람이 보는 것보다, 미래의 내가 보라고 쓰는 글이라고 생각하는데요. 2년이 지날 무렵의 나는 이런 생각을 하고 있었는데, 3년 혹은 더 이후의 미래의 저는 어떤 생각을 하는지도 문득 궁금해지네요. 그때의 저는 더욱 함께 일하고 싶은 사람이었으면 좋겠습니다.
