<div id="readability-page-1" class="page"><div><h2 id="9863">플랫폼 조직을 이끌면서</h2><p id="cd9a">‘공통 서비스 개발팀’ 이라는 사내 개발팀을 위한 플랫폼을 만드는 조직과, ‘인터널 프로덕트팀’ 이라는 사내 구성원을 위한 제품을 만드는 조직의 리더로 일하고 있다. 두 팀 모두, 팀 빌딩을 거의 바닥부터 해야 하는 상황에서 리더 역할을 맡았기 때문에 직접 코드를 작성하는 일도 현재까지 이어지고 있다. 그렇게 치열하게 일하고 팀이 점차 커지면서 어떤 결과를 만들어왔나 돌아보았다. 전부 다 언급할 수는 없지만, 주요 깨달음이 있었던 몇몇 과제를 돌아보자.</p><h2 id="cdf2">신규 영상 플랫폼 제공</h2><p id="00a6">당근을 사랑하는 분들은 눈치챘을지 모르겠지만, 당근 곳곳에서 영상 콘텐츠가 시작되고 있다. 전략적으로 여러 외부 서비스를 사용하면서 만든 영상 플랫폼의 원칙은 ‘<strong>당근 개발자 동료가 외부 서비스의 존재를 인지하지 않고 영상 플랫폼을 개발에 활용할 수 있어야 한다</strong>.’ 였다. 풀어서 설명하면 영상 플랫폼의 외부 서비스가 변경될 때마다 서비스 개발팀이 할 일이 생겨서는 안 된다는 의미다.</p><p id="7a4f">처음 도입한 외부 서비스의 인터페이스와 데이터 구조를 우리 영상 플랫폼에 고민 없이 그대로 반영할 수도 있었다. 하지만 다른 외부 서비스를 도입하는 경우 혹은 내재화처럼, 중장기적인 방향성과 우리 플랫폼의 인터페이스 변경을 최소화할 수 있는 것까지 고민하며 설계하는 일은 쉽지 않았다. 더군다나 당시에는 팀원도 부재하여 혼자 고민하고 실행했다. 다행히 1년 1개월 동안 새로운 외부 서비스 추가, 데이터 migration 등의 이벤트가 실제로 발생했지만 별다른 문제 없이 마무리되었다. 영상 플랫폼의 초기부터 현재까지 설계에 대한 방향성이 틀리지 않았나 보다. 서비스 개발팀으로부터, ‘저희가 할 일은 하나도 없네요?’ 라는 소리를 들으며 뿌듯해했던 기억도 있다.</p><h2 id="dff6">기존 이미지 플랫폼 개선</h2><p id="6f31">기존에 전사적으로 사용되던 이미지 플랫폼이 있었고, 일부 인프라를 변경하는 굵직한 과제가 있었다. 구체적인 기술 내용은 개인블로그 보다는 당근 테크 블로그가 적합하다고 판단하여 언급하지 않겠다. 다만, 당근에서 발생하는 트래픽의 상위 지분을 가진 이미지 플랫폼의 일부 인프라를 변경하는 일은 쉬운 결정은 아니었고, 의사결정을 위해 다양한 검증을 진행했었다. 그 검증의 목표는 딱 두 가지를 확인하고자 함이었다.</p><ol><li id="148b">플랫폼을 사용하던 <strong>서비스 팀에서 성능 변화를 겪을 지점</strong>이 있는가?</li><li id="8a7a">플랫폼을 사용하던 <strong>서비스 팀들의 변경점</strong>이 있는가?</li></ol><p id="4dfd">이 두 가지 확인을 위해 가능한 시나리오를 모두 도출하여 성능 비교 테스트를 진행했다. 또한, 서비스 팀이 사용 중인 인터페이스에는 기존 인프라에 종속적인 정보가 있었음에도 서비스 팀의 변경 없이 신규 인프라를 사용할 방법도 찾아냈다. 만약, 두 가지 중 하나라도 만족스러운 검증 결과가 나오지 않았다면 당장 이 과제는 진행하기 어렵다는 판단을 내렸을 텐데, 다행히 현시점에서는 서비스 팀의 변경점 없이 새로운 인프라의 이점을 누리고 있다.</p><h2 id="55e8">Kafka 운영/관리, 그리고 migration</h2><p id="01d8">당근은 서비스 간 이벤트/메시지 통신에 Kafka를 적극 활용하고 있고, 우리 조직은 Kafka 클러스터를 운영하고 관리하는 책임을 갖고 있다. Kafka 클러스터를 운영하고 관리하면서 다양한 고민을 해왔다. ‘진짜 중요한 알림만 받으려면 <strong>어떤 상태를 추적해야 할까?</strong>’, ‘중요한 알림을 받았지만 각 서비스 팀의 모든 상황을 알 수 없는 상황에서 <strong>우리 팀의 역할은 어디까지일까?</strong>’, ‘Kafka를 사용하는 각 서비스 팀의 성숙도 편차가 큰데, 일정 수준 이상을 보장하려면 <strong>우리 팀이 어떤 장치를 만들어야 할까?</strong>’ 등에 대한 답을 찾기 위해 여전히 다양한 시도와 변화를 경험하고 있다.</p><p id="1b1e">또, Kafka 클러스터 간 migration을 진행하고 있다. 이 과제를 진행하며 깊이 깨달은 것은, <strong>긴 호흡으로 가야만 하는 전략도 필요하다는 점</strong>이다. 몇백 개의 토픽을, 각 서비스 팀마다 사용하는 방식이 다를 수밖에 없는 환경에서 우리 팀이 아무리 멋진 도구를 만든다고 하더라도 빠른 방법은 없었다. 느릴 수밖에 없음을 인정하지만, 이때 필요한 건 <strong>팀이 지치지 않게 하는 것</strong>이다. <strong>작은 결과를 지속적으로 확인할 수 있는 장치와 계획</strong>이 무엇보다 중요하다.</p><h2 id="69d8">사내 구성원을 위한 제품</h2><p id="9c5b">사내 구성원을 위한 제품을 만드는 조직도 이끌고 있다고 말했다. 여러 작업들이 있었지만 어드민 인증 통합 과제와 계정/권한 신청 서비스 개발을 언급하고 싶다. 언뜻, 사내 구성원들이 일하며 필요한 어드민 서비스와 계정/권한 신청을 위한 서비스는 결이 비슷하겠구나,, 라고 생각할 수도 있다. 하지만 전자는 플랫폼에 가까운 일이었고, 후자는 서비스에 가까운 일이었다. 조금 풀어서 설명해보자.</p><p id="e8f5">어드민 인증 통합 과제는 사내에서 사용되는 다양한 어드민들의 통합되지 않은 인증 방식이 문제가 되어 시작됐다. 어드민을 사용하는 구성원들의 사용성에 영향을 주는 부분이 맞지만, 결국 어드민이라는 영역을 넘어서서 사내 인증 시스템으로 확장될 가능성을 염두에 두고 시작해야 했다.</p><p id="404b">계정/권한 신청 서비스 개발은 기존에 파편화된 계정/권한 신청 절차와 도구를 하나의 서비스로 제공하여 구성원들이 겪는 비효율을 제거하기 위함이었다. 플랫폼으로 확장될 가능성 보다는, 사용자인 구성원들에게 빠르게 가치를 제공하는 데 초점을 두고 진행한 과제였다.</p><p id="d0e1">이처럼 팀이 만들고 있는 제품이 <strong>플랫폼 성격인가? 서비스 성격인가?를 고민하는 일은 인터널 프로덕트팀에게 필수</strong>다.</p><h2 id="a591">앞으로는,</h2><p id="e9b5">당근은 분기별 OKR을 수립한다. 입사 후, 벌써 4번의 OKR을 수립하고 결과를 보고 있다. 모든 OKR을 달성하지는 못했지만, 지난 4번의 OKR을 돌아보며 분명한 방향성이 있었고 크고 작은 결과물들이 ‘공통 서비스 개발팀’과 ‘인터널 프로덕트팀’의 지속 가능한 힘을 증명했다고 생각한다.</p><p id="84bf">통합 로그, Feature Flags, 인증/인가, 어드민 등 새로운 과제를 열심히 진행하고 있는 요즘이다. 내년의 우리 조직들은 어떤 모습일까를 종종 상상해본다. 이미 기반이 된 플랫폼과 서비스의 영향도를 더 탄탄히 하고, 전사 영향도가 있는 새로운 플랫폼과 서비스를 제공하여 개발자 동료와 구성원 전체의 생산성을 돕는 멋진 결과를 내고 싶다. <strong>지난 1년의 시작은 혼자였지만, 새로운 1년의 시작은 든든한 팀원들이 있으니 훨씬 멋지지 않을까?</strong></p></div><div><h2 id="1bcd">또 한 번의 팀 빌딩을 하면서</h2><p id="ca66">14년의 개발자 경력 중, 절반을 매니저 역할을 해왔고 몇 번의 팀 빌딩을 경험하고 있다. 그 중 성공적이라고 말할 수 있는 경험도 있지만 분명한 실패라고 말할 수 있는 경험도 있다. 당근에서도 입사와 동시에 1년여간 팀 빌딩을 지속하고 있다.</p><p id="31de">팀원이 턱없이 부족한 상황에서 빠르게 팀원을 충원하는 일도 중요했지만, <strong>초반 팀 빌딩에서는 역시 팀의 역량과 문화를 함께 이끌어 줄 수 있는 분을 채용하는 것이 속도보다 더 중요</strong>하다고 판단했다. 기준이 확고한 만큼 속도는 느렸지만, 꾸준하게 팀의 수준을 끌어올릴 수 있는 분들이 한 분 한 분 합류하고 있다. 그래서 위에서 언급한 플랫폼 조직의 결과를 함께 만들 수 있었다.</p><p id="25d0">초반 팀 빌딩의 엄격한 기준을 고수하는 게 옳았다는 깨달음과 함께, 팀 fit이 맞지 않는 사람과 이별할 줄도 알아야 한다는 배움도 얻었다. 어떻게든 우리 팀 fit에 끼워 맞추려고 하기보다(그렇게 할 수도 없다) 서로 충분히 노력했지만 가능성이 보이지 않는다면, 팀원도 더 만족하며 일할 수 있는 환경을 찾아주려는 방향이 오히려 현명하다. <strong>이별하는 방법을 성숙하게 찾아내는 것도 리더에게 필요한 역량</strong>임을 깨우쳤다.</p><p id="797c">쉽지 않은 팀 빌딩 과정을 거치며 지금은 함께했을 때 곱절 시너지가 생기는 팀으로 성장했고, 풀어야 할 문제는 여전히 많아서 지속적으로 좋은 분들은 모시는 중이다.</p></div><div><h2 id="9969">소속감 이라는 것을 느끼며</h2><p id="19bd">정도의 차이는 있겠지만 내가 속한 회사보다는 속한 팀에 소속감을 강하게 느껴온 편이다. 당근에서는 어떤 서비스보다 빠르게 성장하며 동시에 해결해야 하는 문제가 많은 이 상황이 매력적이기도 하고, 책임/권한/위임에 대한 고민을 충분히 하는 곳이기도 하며, 역량 있는 수백 명의 동료가 든든한 모든 상황이 맞물려서인지 그 어느 때보다 당근이라는 소속감을 느끼며 일하고 있다. 그래서인지 아마도 처음으로 회사 내에서 꽤 다양한 활동을 해오고 있는 것 같다.</p><figure><figcaption>인프라실 위클리 미팅</figcaption></figure><p id="539e">우선 나는 인프라실 소속이고, 우리 실은 매주 금요일 다 같이 모여 고민과 지식을 공유하는 시간을 가진다. 1년 동안 실 동료에게 소식 혹은 고민을 공유한 게 4번 정도 된다. 이 시간을 보낸 후, 늘 후련함과 든든함을 느꼈다.</p><figure><figcaption>2024 당근 테크 밋업</figcaption></figure><p id="6be1">세미나 혹은 컨퍼런스의 연사로는 많이 참여했지만 놀랍게도 운영진 역할을 해본 적은 없었다. 당근에서 마침 규모 있는 첫 테크 밋업을 계획 중이었고, 플랫폼 트랙의 일꾼과 진행자로 참여하여 행사의 시작과 끝을 모두 경험해 볼 수 있었다. 하나의 행사를 위해 얼마나 많은 사람의 고민과 노력이 반영되는지 경험해보지 않았다면 알 수 없는 것이었다.</p><figure><figcaption>사내 루틴 만들기 채널</figcaption></figure><p id="7ed8">루틴 만드는 일을 좋아하는 사람인데, 마침 사내 #talk-routine 채널에 초대받아서 나름의 고정 멤버로 참여하고 있다. 매일 수영, 웨이트, 달리기, 풋살, 영어 공부, 독서 등의 활동을 공유하는 동료들을 보며 응원을 주고받는 소소한 일이 꽤 활력이 되고 있다.</p><p id="58bb">내가 입사한 후로 당근에서는 새롭게 시도하는 것들이 많았는데, 그 중 하나가 리더 워크샵이었다. 당근의 리더들이 함께 모여 고민을 나누고, 네트워킹 하는 이 첫 번째 행사에 감사히도 발표 세션을 요청받아 경험을 나눌 수 있었다. 입사한 지 얼마 되지 않은 리더의 경험과 원칙들을 귀 기울여 들어주는 다른 리더들에 대한 인상은 아마 오래 남을 것 같다.</p><p id="3042">당근에서는 나의 리더십 방향에 대해 공감과 응원을 많이 받아오고 있다. 그래서인지 브랜딩팀과 피플팀이 좋은 기회를 주셔서 사내 인터뷰도 진행하고, 덕분에 채용 홍보 효과도 톡톡히 누리고 있다.</p><figure><figcaption>사내 스터디 모임 참여 기록</figcaption></figure><p id="089c">벌써 4번의 사내 스터디 모임에 참여했고, 하고 있다. 팀 내에서 진행한 스터디도 있고, 다른 조직의 개발자 동료와 스터디를 진행하며 더 풍부한 이야기를 나누는 시간도 있었다. 주로 전사 사무실 근무일인 월요일과 목요일 점심시간을 활용했고, 이 시간 덕분에 (우리 조직의 고객이자) 사업 조직의 개발자 동료와도 자연스럽게 소통할 수 있게 된 건 뜻밖의 이득이었다.</p></div><div><p id="e187">글의 서두에서 직접 코드를 작성하는 일을 지금까지 이어오고 있다고 말했지만, 팀원들이 하나둘 모이며 당연히 그 시간을 줄어들고 있다. 코드 작성의 전/후에 개입하며 의견을 전달하고 일의 복잡성과 중요도에 따라 직접 의사결정을 내리는 데 더 많은 시간을 할애하고 있다. 문제를 분석하고, 일을 계획하며, 시스템을 설계하고, 결과를 추적하는 일에 시간을 많이 할애한다는 뜻이다. 10년 넘게 서비스 개발을 해온 경험과 개발자로서의 기반이 플랫폼 조직을 이끄는 지금, 탄탄한 재료가 되고 있다. 덕분에, 당근에서의 1년 1개월을 플랫폼 개발자로 그리고 리더로 굉장히 밀도 있는 시간을 보내고 있다 생각한다. <strong>플랫폼 개발은 속도와 온전히 trade off 할 수 없는 제품이며, 언제나 품질을 주요 요소로 함께 고민해야 한다는 점</strong>도 온몸으로 체감하며!</p><p id="08cd">개인에게 초점을 맞춰 글을 작성하다 보니 글이 너무 방대해 질까 봐 일과 사람을 관리하는 일에 대해서는 구체적인 이야기를 풀지 않았는데, 언젠가 적절한 시기에 또 나눠볼 수 있기를 기대한다.</p><p id="4bff">수습 통과 기념 글에서도 언급한 것처럼, 내가 당근 입사 후 원했던 모습은 <strong>일도 엄마의 역할도 완벽하기보다는 균형 있게 해내는 모습</strong>이었다. 1년 1개월의 시간을 돌아보니 아직 균형을 언급하기에 허덕이는 삶에 가깝기는 하지만, 중심에서 너무 벗어날 때마다 <strong>스스로를 다시 끌어당길 수 있는 힘은 기르지 않았나</strong> 싶다. 앞으로의 1년도 다채롭고 묵직한 것들로 차분히 채워나가고 싶다.</p></div></div>

Stories by Mijeong (Rachel) on Medium

당근에 입사한 뒤 수습 통과 기념 글을 올렸었고, 이어서 1년이 지난 시점에 또 글을 올리는 걸 보니 나는 당근에서의 일과 삶을 꽤 만족스럽게 보내고 있는 것 같다.
‘일하는 엄마’ 가 된 후 달라진 삶의 태도 — 당근 수습 통과 기념
정확히 말하자면, 글을 쓰는 지금은 당근에 입사한 지 1년하고 1개월이 지났다. 10년 넘도록 흔히 이야기하는 목적 조직의 형태에서 서비스를 위한 백엔드 개발을 주로 해왔던 내가, 사내 개발팀 혹은 사내 구성원을 고객으로 플랫폼과 서비스 개발을 해온 시간이 1년 1개월이 됐다는 말이기도 하다.
플랫폼 조직을 이끌면서
‘공통 서비스 개발팀’ 이라는 사내 개발팀을 위한 플랫폼을 만드는 조직과, ‘인터널 프로덕트팀’ 이라는 사내 구성원을 위한 제품을 만드는 조직의 리더로 일하고 있다. 두 팀 모두, 팀 빌딩을 거의 바닥부터 해야 하는 상황에서 리더 역할을 맡았기 때문에 직접 코드를 작성하는 일도 현재까지 이어지고 있다. 그렇게 치열하게 일하고 팀이 점차 커지면서 어떤 결과를 만들어왔나 돌아보았다. 전부 다 언급할 수는 없지만, 주요 깨달음이 있었던 몇몇 과제를 돌아보자.
신규 영상 플랫폼 제공
당근을 사랑하는 분들은 눈치챘을지 모르겠지만, 당근 곳곳에서 영상 콘텐츠가 시작되고 있다. 전략적으로 여러 외부 서비스를 사용하면서 만든 영상 플랫폼의 원칙은 ‘당근 개발자 동료가 외부 서비스의 존재를 인지하지 않고 영상 플랫폼을 개발에 활용할 수 있어야 한다.’ 였다. 풀어서 설명하면 영상 플랫폼의 외부 서비스가 변경될 때마다 서비스 개발팀이 할 일이 생겨서는 안 된다는 의미다.
처음 도입한 외부 서비스의 인터페이스와 데이터 구조를 우리 영상 플랫폼에 고민 없이 그대로 반영할 수도 있었다. 하지만 다른 외부 서비스를 도입하는 경우 혹은 내재화처럼, 중장기적인 방향성과 우리 플랫폼의 인터페이스 변경을 최소화할 수 있는 것까지 고민하며 설계하는 일은 쉽지 않았다. 더군다나 당시에는 팀원도 부재하여 혼자 고민하고 실행했다. 다행히 1년 1개월 동안 새로운 외부 서비스 추가, 데이터 migration 등의 이벤트가 실제로 발생했지만 별다른 문제 없이 마무리되었다. 영상 플랫폼의 초기부터 현재까지 설계에 대한 방향성이 틀리지 않았나 보다. 서비스 개발팀으로부터, ‘저희가 할 일은 하나도 없네요?’ 라는 소리를 들으며 뿌듯해했던 기억도 있다.
기존 이미지 플랫폼 개선
기존에 전사적으로 사용되던 이미지 플랫폼이 있었고, 일부 인프라를 변경하는 굵직한 과제가 있었다. 구체적인 기술 내용은 개인블로그 보다는 당근 테크 블로그가 적합하다고 판단하여 언급하지 않겠다. 다만, 당근에서 발생하는 트래픽의 상위 지분을 가진 이미지 플랫폼의 일부 인프라를 변경하는 일은 쉬운 결정은 아니었고, 의사결정을 위해 다양한 검증을 진행했었다. 그 검증의 목표는 딱 두 가지를 확인하고자 함이었다.
플랫폼을 사용하던 서비스 팀에서 성능 변화를 겪을 지점이 있는가?
플랫폼을 사용하던 서비스 팀들의 변경점이 있는가?
이 두 가지 확인을 위해 가능한 시나리오를 모두 도출하여 성능 비교 테스트를 진행했다. 또한, 서비스 팀이 사용 중인 인터페이스에는 기존 인프라에 종속적인 정보가 있었음에도 서비스 팀의 변경 없이 신규 인프라를 사용할 방법도 찾아냈다. 만약, 두 가지 중 하나라도 만족스러운 검증 결과가 나오지 않았다면 당장 이 과제는 진행하기 어렵다는 판단을 내렸을 텐데, 다행히 현시점에서는 서비스 팀의 변경점 없이 새로운 인프라의 이점을 누리고 있다.
Kafka 운영/관리, 그리고 migration
당근은 서비스 간 이벤트/메시지 통신에 Kafka를 적극 활용하고 있고, 우리 조직은 Kafka 클러스터를 운영하고 관리하는 책임을 갖고 있다. Kafka 클러스터를 운영하고 관리하면서 다양한 고민을 해왔다. ‘진짜 중요한 알림만 받으려면 어떤 상태를 추적해야 할까?’, ‘중요한 알림을 받았지만 각 서비스 팀의 모든 상황을 알 수 없는 상황에서 우리 팀의 역할은 어디까지일까?’, ‘Kafka를 사용하는 각 서비스 팀의 성숙도 편차가 큰데, 일정 수준 이상을 보장하려면 우리 팀이 어떤 장치를 만들어야 할까?’ 등에 대한 답을 찾기 위해 여전히 다양한 시도와 변화를 경험하고 있다.
또, Kafka 클러스터 간 migration을 진행하고 있다. 이 과제를 진행하며 깊이 깨달은 것은, 긴 호흡으로 가야만 하는 전략도 필요하다는 점이다. 몇백 개의 토픽을, 각 서비스 팀마다 사용하는 방식이 다를 수밖에 없는 환경에서 우리 팀이 아무리 멋진 도구를 만든다고 하더라도 빠른 방법은 없었다. 느릴 수밖에 없음을 인정하지만, 이때 필요한 건 팀이 지치지 않게 하는 것이다. 작은 결과를 지속적으로 확인할 수 있는 장치와 계획이 무엇보다 중요하다.
사내 구성원을 위한 제품
사내 구성원을 위한 제품을 만드는 조직도 이끌고 있다고 말했다. 여러 작업들이 있었지만 어드민 인증 통합 과제와 계정/권한 신청 서비스 개발을 언급하고 싶다. 언뜻, 사내 구성원들이 일하며 필요한 어드민 서비스와 계정/권한 신청을 위한 서비스는 결이 비슷하겠구나,, 라고 생각할 수도 있다. 하지만 전자는 플랫폼에 가까운 일이었고, 후자는 서비스에 가까운 일이었다. 조금 풀어서 설명해보자.
어드민 인증 통합 과제는 사내에서 사용되는 다양한 어드민들의 통합되지 않은 인증 방식이 문제가 되어 시작됐다. 어드민을 사용하는 구성원들의 사용성에 영향을 주는 부분이 맞지만, 결국 어드민이라는 영역을 넘어서서 사내 인증 시스템으로 확장될 가능성을 염두에 두고 시작해야 했다.
계정/권한 신청 서비스 개발은 기존에 파편화된 계정/권한 신청 절차와 도구를 하나의 서비스로 제공하여 구성원들이 겪는 비효율을 제거하기 위함이었다. 플랫폼으로 확장될 가능성 보다는, 사용자인 구성원들에게 빠르게 가치를 제공하는 데 초점을 두고 진행한 과제였다.
이처럼 팀이 만들고 있는 제품이 플랫폼 성격인가? 서비스 성격인가?를 고민하는 일은 인터널 프로덕트팀에게 필수다.
앞으로는,
당근은 분기별 OKR을 수립한다. 입사 후, 벌써 4번의 OKR을 수립하고 결과를 보고 있다. 모든 OKR을 달성하지는 못했지만, 지난 4번의 OKR을 돌아보며 분명한 방향성이 있었고 크고 작은 결과물들이 ‘공통 서비스 개발팀’과 ‘인터널 프로덕트팀’의 지속 가능한 힘을 증명했다고 생각한다.
통합 로그, Feature Flags, 인증/인가, 어드민 등 새로운 과제를 열심히 진행하고 있는 요즘이다. 내년의 우리 조직들은 어떤 모습일까를 종종 상상해본다. 이미 기반이 된 플랫폼과 서비스의 영향도를 더 탄탄히 하고, 전사 영향도가 있는 새로운 플랫폼과 서비스를 제공하여 개발자 동료와 구성원 전체의 생산성을 돕는 멋진 결과를 내고 싶다. 지난 1년의 시작은 혼자였지만, 새로운 1년의 시작은 든든한 팀원들이 있으니 훨씬 멋지지 않을까?
또 한 번의 팀 빌딩을 하면서
14년의 개발자 경력 중, 절반을 매니저 역할을 해왔고 몇 번의 팀 빌딩을 경험하고 있다. 그 중 성공적이라고 말할 수 있는 경험도 있지만 분명한 실패라고 말할 수 있는 경험도 있다. 당근에서도 입사와 동시에 1년여간 팀 빌딩을 지속하고 있다.
Software Engineer, Backend - 공통 서비스 개발 | 당근 팀 채용
Software Engineer, Backend - 인터널 프로덕트 | 당근 팀 채용
팀원이 턱없이 부족한 상황에서 빠르게 팀원을 충원하는 일도 중요했지만, 초반 팀 빌딩에서는 역시 팀의 역량과 문화를 함께 이끌어 줄 수 있는 분을 채용하는 것이 속도보다 더 중요하다고 판단했다. 기준이 확고한 만큼 속도는 느렸지만, 꾸준하게 팀의 수준을 끌어올릴 수 있는 분들이 한 분 한 분 합류하고 있다. 그래서 위에서 언급한 플랫폼 조직의 결과를 함께 만들 수 있었다.
초반 팀 빌딩의 엄격한 기준을 고수하는 게 옳았다는 깨달음과 함께, 팀 fit이 맞지 않는 사람과 이별할 줄도 알아야 한다는 배움도 얻었다. 어떻게든 우리 팀 fit에 끼워 맞추려고 하기보다(그렇게 할 수도 없다) 서로 충분히 노력했지만 가능성이 보이지 않는다면, 팀원도 더 만족하며 일할 수 있는 환경을 찾아주려는 방향이 오히려 현명하다. 이별하는 방법을 성숙하게 찾아내는 것도 리더에게 필요한 역량임을 깨우쳤다.
쉽지 않은 팀 빌딩 과정을 거치며 지금은 함께했을 때 곱절 시너지가 생기는 팀으로 성장했고, 풀어야 할 문제는 여전히 많아서 지속적으로 좋은 분들은 모시는 중이다.
소속감 이라는 것을 느끼며
정도의 차이는 있겠지만 내가 속한 회사보다는 속한 팀에 소속감을 강하게 느껴온 편이다. 당근에서는 어떤 서비스보다 빠르게 성장하며 동시에 해결해야 하는 문제가 많은 이 상황이 매력적이기도 하고, 책임/권한/위임에 대한 고민을 충분히 하는 곳이기도 하며, 역량 있는 수백 명의 동료가 든든한 모든 상황이 맞물려서인지 그 어느 때보다 당근이라는 소속감을 느끼며 일하고 있다. 그래서인지 아마도 처음으로 회사 내에서 꽤 다양한 활동을 해오고 있는 것 같다.
우선 나는 인프라실 소속이고, 우리 실은 매주 금요일 다 같이 모여 고민과 지식을 공유하는 시간을 가진다. 1년 동안 실 동료에게 소식 혹은 고민을 공유한 게 4번 정도 된다. 이 시간을 보낸 후, 늘 후련함과 든든함을 느꼈다.
세미나 혹은 컨퍼런스의 연사로는 많이 참여했지만 놀랍게도 운영진 역할을 해본 적은 없었다. 당근에서 마침 규모 있는 첫 테크 밋업을 계획 중이었고, 플랫폼 트랙의 일꾼과 진행자로 참여하여 행사의 시작과 끝을 모두 경험해 볼 수 있었다. 하나의 행사를 위해 얼마나 많은 사람의 고민과 노력이 반영되는지 경험해보지 않았다면 알 수 없는 것이었다.
루틴 만드는 일을 좋아하는 사람인데, 마침 사내 #talk-routine 채널에 초대받아서 나름의 고정 멤버로 참여하고 있다. 매일 수영, 웨이트, 달리기, 풋살, 영어 공부, 독서 등의 활동을 공유하는 동료들을 보며 응원을 주고받는 소소한 일이 꽤 활력이 되고 있다.
리더는 혼자가 아니니까, Cheer Leaders! | 당근 블로그
내가 입사한 후로 당근에서는 새롭게 시도하는 것들이 많았는데, 그 중 하나가 리더 워크샵이었다. 당근의 리더들이 함께 모여 고민을 나누고, 네트워킹 하는 이 첫 번째 행사에 감사히도 발표 세션을 요청받아 경험을 나눌 수 있었다. 입사한 지 얼마 되지 않은 리더의 경험과 원칙들을 귀 기울여 들어주는 다른 리더들에 대한 인상은 아마 오래 남을 것 같다.
성장하는 엔지니어링 리더는 어떻게 일할까 | 당근 블로그
당근에서는 나의 리더십 방향에 대해 공감과 응원을 많이 받아오고 있다. 그래서인지 브랜딩팀과 피플팀이 좋은 기회를 주셔서 사내 인터뷰도 진행하고, 덕분에 채용 홍보 효과도 톡톡히 누리고 있다.
벌써 4번의 사내 스터디 모임에 참여했고, 하고 있다. 팀 내에서 진행한 스터디도 있고, 다른 조직의 개발자 동료와 스터디를 진행하며 더 풍부한 이야기를 나누는 시간도 있었다. 주로 전사 사무실 근무일인 월요일과 목요일 점심시간을 활용했고, 이 시간 덕분에 (우리 조직의 고객이자) 사업 조직의 개발자 동료와도 자연스럽게 소통할 수 있게 된 건 뜻밖의 이득이었다.
글의 서두에서 직접 코드를 작성하는 일을 지금까지 이어오고 있다고 말했지만, 팀원들이 하나둘 모이며 당연히 그 시간을 줄어들고 있다. 코드 작성의 전/후에 개입하며 의견을 전달하고 일의 복잡성과 중요도에 따라 직접 의사결정을 내리는 데 더 많은 시간을 할애하고 있다. 문제를 분석하고, 일을 계획하며, 시스템을 설계하고, 결과를 추적하는 일에 시간을 많이 할애한다는 뜻이다. 10년 넘게 서비스 개발을 해온 경험과 개발자로서의 기반이 플랫폼 조직을 이끄는 지금, 탄탄한 재료가 되고 있다. 덕분에, 당근에서의 1년 1개월을 플랫폼 개발자로 그리고 리더로 굉장히 밀도 있는 시간을 보내고 있다 생각한다. 플랫폼 개발은 속도와 온전히 trade off 할 수 없는 제품이며, 언제나 품질을 주요 요소로 함께 고민해야 한다는 점도 온몸으로 체감하며!
개인에게 초점을 맞춰 글을 작성하다 보니 글이 너무 방대해 질까 봐 일과 사람을 관리하는 일에 대해서는 구체적인 이야기를 풀지 않았는데, 언젠가 적절한 시기에 또 나눠볼 수 있기를 기대한다.
수습 통과 기념 글에서도 언급한 것처럼, 내가 당근 입사 후 원했던 모습은 일도 엄마의 역할도 완벽하기보다는 균형 있게 해내는 모습이었다. 1년 1개월의 시간을 돌아보니 아직 균형을 언급하기에 허덕이는 삶에 가깝기는 하지만, 중심에서 너무 벗어날 때마다 스스로를 다시 끌어당길 수 있는 힘은 기르지 않았나 싶다. 앞으로의 1년도 다채롭고 묵직한 것들로 차분히 채워나가고 싶다.

당근에서 ‘두 팀의 리더’로, 그리고 1년 후

댓글