💻 함께하고 싶은 개발팀 만들어 나가기

Posts

Resume

2024.04.12

💻 함께하고 싶은 개발팀 만들어 나가기

긴 연차와 화려한 경력을 지닌 뛰어난 개발자들에 비해, 아직 나의 경력은 갈 길이 멀지만 그래도 한번쯤 궁금해할만한 경력이라고 생각한다.

ABZ 주식회사

2021.06 ~ 2023.04 / 2024.01 ~

이번 글에서는 기술적 이야기보다 내가 만들어 나가고 싶은 개발팀은 어떤 모습인지, 그리고 나는 어떤 개발자가 되고 싶은지 적어보려 한다.

글을 쓰며 참고한 글들을 최하단에 정리해 두었습니다. 괄호 안의 번호는 해당 글들을 참고해주세요!

퇴사, 그리고 재입사

23년 4월, 회사의 경영 상황으로 인해 퇴사하게 되었다. 인원 정리가 있을 것 같다는 소식을 얼핏 전해 들었으나 그 대상에 나도 포함되리라고는 생각하지 못했던 탓에 생각보다 당황스러웠다.

하루 아침에 백수가 된 탓에 이제 뭘 해야 하나 하는 생각도 들었지만 그것도 잠깐일 뿐, "금방 이직하겠지! 개발자들 많이 뽑는다던데!" 라는 마음가짐으로 이직 준비를 시작했다.

그러나, 이직의 벽은 내가 생각했던 것보다 훨씬 높았다. 팬데믹 상황을 거치며 개발자 시장은 이미 포화 상태가 되었고 그들 사이에서 눈에 띄기란 쉽지 않은 일이었다. 운 좋게 서류를 통과하더라도 코딩 테스트, 과제 테스트 등에서 떨어지기 일수였다. 당신을 왜 뽑아야 하나요? 라는 질문에 쉽게 대답할 수 없는 개발자였다.

마지막 기회라고 생각하고 준비했던 우테코에서도 낙방한지 약 한 달 뒤, 채용 공고를 둘러보던 중 익숙한 채용 공고를 발견했다. 그렇게 나는 나의 첫 회사인 ABZ 주식회사로 돌아왔다.

구면인 동료들 몇 분과 새로운 동료들과 진행하는 첫 회의 시간, 모두의 공통 소개는 앞으로의 각오에 대한 물음이었고, 나는 다음과 같이 대답했다.

누구나 일하고 싶은 개발팀을 만들어 나가고 싶어요.

일하고 싶은 개발팀

어떤 개발팀에서 일하고 싶으세요? 혹은 어떤 회사에서 일하고 싶으세요? 만큼 명확하면서 동시에 어려운 질문이 없는 것 같다.

최신형 맥북
허리에 좋은 의자 (허먼 밀러라던가.. 허먼 밀러라던가..)
개발 문화 (블로그, 코드 리뷰 등)

이전의 나라면 아마 위와 같은 이야기를 하지 않았을까 싶다. 누구나 할 수 있는 재미없는 이야기들... 😪

그러나, 하나의 프로덕트를 진득하게 개발도 해보고, 6개월을 공 들여 만든 프로덕트를 접어도 보고, 회사를 구만두고 힘든 이직 시기를 거친 이제는, 내가 일하고 싶은 개발팀이 어떤 모습인지 말할 수 있을 것 같다.

1. 질문을 두려워하지 않는 팀

누구였는지 정확히 기억은 나지 않지만, 회사에 갓 입사한 나에게 정말이지 큰 힘이 된 단 한마디가 있다.

"오류 생겨도 우리가 다 커버쳐줄 수 있어요."

물론 오류 상황을 해결하는 것은 당연한 일이지만, "오류가 생겨도 괜찮다, 우리는 그걸 다 해결할 수 있는 능력이 있으니 두려워하지 않아도 된다." 라는 말은 정말이지 거대한 벽이 나를 뒤에서 받쳐주는 것 같은 느낌이 들었을 정도였다. 그 말 덕분에 나는 스스로 더 많은 시도를 해볼 수 있었고, 더 많은 오류 상황도 겪어보며 문제 해결 능력 또한 키울 수 있었다.

5만 줄의 코드를 들고 생면부지인 같은 회사 사람에게 질문한 김범준 님(전 우아한형제들 대표, 현 네이버 COO)과 그에게 도움을 준 분의 일화처럼, 질문을 두려워하지 않는 팀을 만들어 나가고 싶다.

모르는 내용이 있다면 상대의 연차와 실력이 어떻든 질문할 준비가 되어 있으며, 동시에 내가 아는 내용을 기꺼이 답해줄 수 있는 팀의 일원으로 성장해가고 싶다.

주춤할지라도 도와줄 팀원은 항상 있다.

2. 실패하는 법을 아는 팀

다시 회사로 돌아오게 되며 구면인 동료 개발자분들과 나눈 이야기가 있다. "저와 같은 실패를 겪지 않도록 이전보다 더 최선을 다하겠다. 그러니 같이 고민해달라."

어찌 보면 나는 한 번의 실패를 겪은 셈이다. 같은 기간에 퇴직한 동료 개발자들은 모두 훌륭한 회사로 이직을 성공한 반면 나는 그러하지 못했기 때문이다.

그러나, 나는 이 기간을 실패라고 생각하지 않는다. 이전과 같은 마음가짐으로 회사에 고인 물로 남아있었다면, 나는 React를 어정쩡하게 사용할 줄만 아는 프론트엔드 개발자로, 일하고 싶은 개발팀에는 크게 관심이 없는, 그저 회사에서 하는 일만으로 고민하는 개발자로 남아있었을 것이다.

회사와 팀도 마찬가지라고 생각한다. 한 번 넘어져봤다면, 다시는 같은 이유로 넘어지지 않도록 더욱 단단해지게 된다. 혹시라도 비슷한 위기 신호가 오더라도 사전에 감지할 수 있는 일종의 센서가 발달하게 되어, 이전보다 더 성장할 수 있게 된다.

그래서 나는 실패하는 법을 아는 팀을 만들어 나가고 싶다. 그래야 다시 일어날 수 있으니까.

지금의 실패는 당시의 최선이었다. 그러니 자책하지 말자.

3. 우쭐거리는 법을 아는 팀

일 잘하는 개발팀을 가지고 있는 회사들의 공통점 중 하나는 우쭐거리는 법을 아는 팀이라는 것이다. 나는 우쭐거리는 법을 다음과 같이 설명하고 싶다. 단순히 "우리는 너무 대단해", "우리만 이런 걸 할 수 있어" 가 아닌, 자신들의 성과를 블로그나 SNS 등을 통해 홍보하고 이를 통해 자연스레 채용까지 법을 아는 것.

개발자들 사이에서 꿈의 회사로 불리는 네카라쿠배당토 (요즘에는 몰로코, 두나무, 센드버드까지 합쳐서 네카라쿠배당토몰두센이라더라) 는 모두 자신들의 기술적 고민을 기록해 나가는 문화를 잘 갖추고 있다고 생각한다. 나아가 유튜브, 자체 행사 (토스의 SLASH 등), LinkedIn 등을 통해 이를 우쭐대는 법도 잘 알고 있다.

회사의 규모와 상관없이 개발자들만이 할 수 있는 고민과 달성할 수 있는 성과가 있다고 생각한다. 그리고 이 고민과 성과는 직접 우쭐대지 않으면 외부에서는 알기 힘들다. 기술 스택을 변경하는 프로젝트, 성능 개선을 위한 고군분투 등 이 글을 읽는 개발자들 모두 분명 우쭐댈만한 거리가 있을 것이다. 문화적으로 이런 부분이 잘 갖춰진다면 개발자들 또한 일함에 있어 훨씬 큰 보람과 동기를 느끼게 되고 회사 차원에서도 더 우수한 인재를 모집하는 데 도움이 될 것이라고 생각한다.

우리 회사 또한 미디엄(#3)을 통해 다양한 고민과 비즈니스 전반적인 내용들을 풀어내기 위해 노력하고 있다. 돌이켜 생각해보면 복잡하고 생소한 도메인일지라도 직접 부딪혀가며 결국 성공을 거두고 이를 우쭐댔을 때 행복하게 일할 수 있었던 것 같다.

일단 우쭐대보자. 그러면 뭐라도 될 테니.

개발팀 만들어 나가기

GEEKS

규모가 큰 개발팀을 지닌 회사의 공고를 보며 항상 부러웠던 점이 개발에 온전히 집중할 수 있는 환경이었다. 오늘의 집의 Fix-it Week(#4), 토스의 엔지니어링 데이(#5)와 같은 문화를 보며 우리도 쌓여있는 기술 부채, 챌린지 등을 고민할 수 있는 시간을 정기적으로 가질 수 있으면 좋겠다 생각이 들어, GEEKS라는 문화를 만들었다.

소위 말하는 덕후를 뜻하는 GEEK 들이 모였다는 의미의 GEEKS는 말 그대로 사내 개발자들이 일주일에 한 번 모여 개발 관련된 어떤 이야기라도 나눌 수 있는 자리다.

// 내가 만든 GEEKS Intro 문구
일주일에 한번, 짧게라도 모여서 개발 관련된 이야기를 나눠 보아요
그 어떤 것도 좋아요! (사이드 프로젝트 코드, 재밌게 읽은 블로그, 소개하고 싶은 뉴스레터)
업무 코드에만 갇히지 않는 건강한 GEEK 생활을 위해..

정해진 주제도 형식도 없다 보니 처음엔 어색하지만 이제는 모두 자유로운 주제로 이야기하는 것에 익숙해졌고 실제로 프로덕트, 우리의 문제를 해결하기 위한 방안들이 여럿 보여 개인적으로 매우 만족스러운 개발 문화이다.

향후 여기서 더 나아가 스터디를 진행하거나, Fix-it Week처럼 개발 문제를 해결하는 주간을 가질 수 있도록 꾸준히 이 자리를 가꾸어 나갈 생각이다.

코드 리뷰와 개발 문서

내가 합류하면서 다시 프론트엔드 개발자가 2명이 되었기에 코드 리뷰를 다시 진행하게 되었다. 단기간 내에 공동구매 시장이라는 복잡한 도메인을 프로덕트로 구현하다 보니, 코드의 중복, 불필요한 코드의 사용, 개선할 수 있는 부분 등을 서로서로 마구 발생시켜가며 개선해 나가는 중이다.

궁극적으로는 우리만의 CoC를 만들어 누가 읽어도 이해할 수 있는 코드를 만들고, 새로운 개발자의 온보딩 과정에서 활용할 수 있도록 코드 리뷰와 더불어 사내 개발 문서를 꾸준히 완성해 나가는 중이다.

언젠가 내가 만든 개발 문서를 채용 공고에 올릴 수 있는 날까지..!

나는 어떤 개발자가 되고 싶은가

동료 개발자들과 재회한 자리에서 건넨 일종의 충고가 하나 있다. "어떤 개발자가 되고 싶은지는 우리가 스스로 만들어 나가야 해요. 그래야 이 사람과 일하고 싶은 마음이 드니까" 스스로가 아니면 그 누구도 내가 어떤 일을 남들보다 더 잘하는지, 더 재미있어 하는지 알 수 없기에 이 글을 읽는 모두 내가 어떤 일을 재미있어 하는지 한번 생각해보길 바란다.

나는 불편함을 불편해하는 개발자가 되고 싶다. 그 대상이 서비스를 사용하는 유저가 될수도, 팀 내에서 일하는 과정이 될수도, 우리의 프로덕트가 될 수도 있다. 나는 누가 시키지 않아도 스스로 불편함을 찾기 위해 밤낮으로 고민하고 이를 해결하기 위해 노력하는 개발자로 성장하고 싶다. (#6)

또한, 부피와 밀도를 동시에 갖춘 개발자가 되고 싶다. 단순히 연차만 늘어가는 것이 아닌, 다양한 도메인과 트렌드에 대해 관심을 갖고 남에게 도움을 줄 수 있는 개발자가 되고 싶다. 이 밀도를 바탕으로 미래에는, 공간과 시간에 구애받지 않고 나만의 서비스를 만들어 나가는 개발자로 성장해 나가고 싶다.

마치며

기술적 내용이 아니라 그런지 몇일을 썼다 지웠다 되풀이한 끝에 겨우 마무리하게 되었다. 글을 읽으면 그 사람이 보인다는 동료 개발자의 말처럼, 더 나은 글을 통해 더 나은 개발자가 되어야지 다짐을 하게 된다.