brunch

라이킷 7 댓글 1

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by Rapha Apr 24. 2023

Software Development Manager

슬기로운 쿠팡페이 개발생활

시작하며

쿠팡페이에는 SDM(Software Development Manager)이라는 역할이 있다. 이 역할은 왜 만들어졌으며, 어떤 일들을 하고 있는지, 일반적인 매니저들과 무엇이 다른지 소개해보고자 한다. 참고로 필자는 현재 쿠팡페이에서 SDM 역할을 수행하고 있다.

SDM 꼭 필요했을까?

처음 입사 했을 때 엔지니어는 약 15~20명 정도 있었다. 이때 개발 매니저라고 보이는 분은 한 분 정도 있었고 이 분 역시 꽤 개발을 잘했던 엔지니어였다. 쿠팡은 기본적으로 매니저라는 역할을 최소한으로 하는 수평조직을 추구하면서 각 도메인별로 Tech Leader들이 있어 기술적인 난제들을 해결해 나가는 형태였다.

조직이나 도메인의 수가 적을 때는 문제가 안 됐던 것들이 시간이 흐르면서 하나둘 나타났다.

대표적인 예들을 몇 가지 들어보겠다.

개발 매니저의 업무량이 점점 늘어났고 한계를 맞이했다. 개발 매니저 일 중 중요한 것 중의 하나는 요구사항이나 문제를 파악하고 원하는 목적지로 바로 갈 수 있게 리드하는 것인데, 각 종 결제업무나 인사, 채용, 조직 관련 업무가 너무 많아져서 중요한 업무를 제대로 못하는 상태가 되었다. 한 명의 매니저가 감당하기에는 엔지니어 수나 조직 및 도메인들이 너무 많아진 것이다. "난 내가 3명이면 좋겠어!"라는 말들이 들려왔다.

엔지니어들이 많은 회의에 참석을 해야 해서 상대적으로 개발 시간 확보가 어려워지는 상황. 장점으로는 모든 의사결정 회의에 참석을 하기 때문에 누구를 위한 것인지, 왜 개발해야 하는지, 어떤 문제를 해결하려고 하는 것인지, 등등 굳이 설명을 하지 않아도 정확히 알고 있다. 단점으로는 "그래서 구현은 언제 할 건데?"라는 말이 나올 정도로 개발할 시간이 부족했다. 이런 적도 있다. 한참을 떠들썩하게 얘기를 하다가 "근데 이거 누가 개발하나요? 해결방법은 이만 하면 됐는데 개발은 누가 하죠?" 살짝 졸린 눈을 하면서 핸드폰을 바라본 적이 있다. 도메인들이 많아지면서 모든 개발자가 모든 회의에 참석한다는 것은 효율적이지 못했고 누군가는 앞장서서 이 비효율을 효율로 바꿔야 했다.

기민하고 열정적인 조직이기에 의사결정 또한 빨랐다. 언제부턴가 엔지니어들은 의사결정이 되기를 기다리기도 하고 올바른 의사결정이 되지 않은 채 진행을 하다가 재개발을 하는 일도 있었다.

이 외에도 소소한 문제들이 있었다.

당시 나의 조직장이 어떤 목표를 세우고 SDM 역할을 만들었지는 정확히 모르지만 나는 이렇게 회상한다.

"조직의 목표를 달성하기 위해, 좀 더 효율적으로 일을 해보자! 일단 시도해 보고 맞는 길인지 알아보고 문제점이 있다면 보완해 보자."

하기 싫다... 하기 싫다...

엔지니어들은 2주에 한 번씩 할 일을 정하는 회의를 한다. 가급적이면 자신이 하고 싶어 하는 일을 가져가는 문화가 있었다. 가끔씩 안 가져가는 일들이 있었는데 이때 "나다 싶으면 한다."라는 말이 있었다. 안 가져가는 일을 정확히 정의할 수는 없다. 어려워 보이는 일, 아무도 하고 싶지 않은 일, 해도 티 안나는 일, 코드 리뷰 때 많이 챌린지가 올 것만 같은 일 등등 여러 가지가 있었다. 이때 왠지 엔지니어들의 눈치가 나를 원하는듯한 분위기가 느껴졌었는데, "제가 하겠습니다"라고 말했던 기억이 있다.

내가 조직장을 찾아가서 SDM이 되겠다고 말했던 상황도 이와 비슷했던 것 같다. 마음이 복잡했다. 아직 코딩이 재미가 있었고, 기술적으로 더 깊이 알아야 할 것들이 많다고 생각했다. 한편으로 조직이 점점 커지고 있었고 몇 안 되는 SDM들이 고군분투하는 모습도 심심치 않게 보였다.

문득 이런 생각이 들었다.

코딩을 포기하면서 나에게 주어진 시간을 이용해서 더 넓은 시각으로 서비스를 바라볼 수 있지 않을까? 남들은 숲을 보라고 하지만 나는 나무를 보는 것이 좋았다. 담배는 끊는 것이 아닌 참는 것이라고 하지 않던가. 아쉽지만 잠시 이별해 보자.

엔지니어들과 하나가 되어 더 많은 서비스를 경험해보고 싶다.

내가 멋있다고 생각하는 매니저처럼 이 분야에서도 잘하고 싶다.

분명 SDM을 하면서도 엔지니어에서 느낄 수 없었던 또 다른 가치가 있을 거야.

마음을 먹기 까지가 힘들었지 이후엔 쉬웠다. 코딩 금단 증상이 가끔 있었지만 주어진 일을 쳐내는 것만으로도 벅찼다.

코딩 빼고 다한다.

진짜다. 코딩 빼고 다한다. 소프트웨어 개발 및 운영관점에서 거의 모든 분야에서 엔지니어들과 함께한다. 단순한 관리자가 아니기 때문에 자연스럽게 소프트웨어에 대한 호기심이 생기고 질문이 많을 수박에 없다. 장애 발생 시 선두에 나서서 원인을 찾고 엔지니어들과 함께 해결을 한다. 소프트웨어를 개발해서 출시를 하기까지 많은 과정을 거치기 때문에 일일이 다 설명할 순 없지만 코딩 빼고 다한다는 말이 가장 적절한 말 같았다. 쿠팡페이 SDM들이 어떤 부분을 중요시하는지 얘기해 보자.

관리보다는 엔지니어링

단순히 일정 및 리소스 관리를 한다거나, 보스의 명령을 맹목적으로 추진하는 매니저가 필요했다면 굳이 개발경험이 풍부한 매니저가 필요했을까? 아닐 것이다.

우리가 만드는 소프트웨어가 누구를 위한 것인지, 어떤 문제를 해결하려고 하는지에 대한 질문이 있을 때 명료하게 설명할 줄 알아야 한다. 이것을 기반으로 우리가 만드는 소프트웨어가 올바른 길로 가도록 리드한다.

세부적인 것보다는 전체를 이해하고 전체를 이해하고 나면 세부로 들어간다. 소프트웨어 내부를 들여다보면 알고리즘, 예외 사항에 대한 처리, API 별로 주고받는 데이터, 안정성에 대한 고민들 등등 여러 가지가 있다. "코딩을 직접 해야 이런 세부적인 부분들을 알 텐데, 누가 물어보면 어떡하지? 걱정이 된다." SDM 이 되고 나서 몇 개월 동안은 이런 걱정을 했다. 이런 걱정들은 아직도 가끔 있다. :) 그런데, 엔지니어였을 때도 내가 모든 코드를 다 이해하고 있었나?라는 생각이 들었다. 나의 전략은 세부적인 것보다는 전체를 이해하고 전체를 이해하고 나면 세부로 들어가는 것이었다. 쿠팡페이는 워낙 기민하게 움직이는 조직이기 때문에 문서를 작성하기보다는 서로 대화를 자주 하는 편이다. 엔지니어링 조직 이외에 다른 조직에서 올바른 의사 결정을 할 수 있도록 앞장서는 역할 또한 SDM들이 주로 한다.

탁상공론 - 소프트웨어에 대한 깊은 이해는 많은 문제를 해결해 주고 올바른 의사결정을 하는데 핵심적인 역할을 한다. 필자는 많은 회사를 경험하면서 의미 없는 회의로 많은 시간을 보내는 것을 보았다. 얼마나 아까운 시간인가? 심지어 잘못된 의사결정으로 인한 낭비는 최악이다. 엔지니어들과 토론하고 설계하고 좋은 소프트웨어를 만들기 위한 시간이 제일 소중하다.

잘하는 사람들을 고용해서 규칙이 거의 없는 상태에서 일을 진행한다.

회사에 입사했을 때 "어떻게 이런 인재들만 모아놨지!"라는 생각이 들 때가 있었는가? 보통 한두 명의 엔지니어들만 눈에 띄는데 거의 다 잘하는 것이었다. 무엇을 해야 하고 왜 해야 하는지에 대해서만 명확하다면 엔지니어들의 회의는 금방 뜨거워졌다. 무엇을 만들어야 한다고 말 한마디만 했을 뿐인데, 회의에서 이미 어떤 걸 구현해야 하고 더 심도 있게 알아볼 것이 무엇인지, 테스트는 무얼 해야 하는지, 배포 일정까지 다 나왔다. 관리를 한다기보다는 그들과 같이 호흡을 하고 문제에 대해 집착한다. 규칙을 만들기보다 엔지니어들의 창의성이 나오도록 옆에서 지켜보고 어떤 것을 해야 하는지 화두를 계속 던진다.

당신 없이 아무것도 되지 않는 팀을 만들지 말아라.

SDM이 됐을 때부터 나를 대처할 2명 정도의 엔지니어를 만들고 싶었다. 이전 회사에서 나는 실제로 경험을 했다. 서비스 오픈을 하고 2일 정도 휴가를 갔는데 장애가 났던 거다. 장애시간은 길어져만 갔고 해결할 기미가 보이지 않았다. 문제점 중의 하나는 업무를 위임하지 않고 혼자만 알고 혼자만 해결할 수 있는 일이 많았던 것이다. 나의 목표는 2명이 아니라 모든 팀원들이 스스로 생각하고 행동하는 엔지니어였으면 하는 거다. 한 달, 한 해가 지날수록 팀원들이 성장했으면 좋겠다. 내가 없어도 잘 돌아가는 팀이 되었을 때 비로소 나는 다른 차원의 일을 하게 될 것이다. 앞에서 내가 멋있다고 생각한 매니저는 이런 모습을 몸소 보여줬고 현재는 더 큰 차원의 일을 하고 있다.

그냥 되는 일은 없다. 파도를 일으킬 때를 알아야 한다.

아무 일도 하지 않는다면 아무 일도 일어나지 않는다. 예를 들어 운영을 하다 보면 여러 가지 부가적으로 해야 할 일들이 많은데 우선순위에 밀리거나 필요성이 낮아서 안 하게 되는 경우가 있다.

가끔씩 Full GC, Minor GC (GC - Garbage Collection)가 발생을 해도 금방 정상적으로 돌아오기 때문에 자세히 들여다보지 않는다. 우리는 개발을 할 때 문제가 있다면 문제를 알리도록 개발을 했고 여러 가지 기본적인 시스템 자원에 대해서 모니터링하도록 구축을 한다. 이렇기 때문에 우리는 소프트웨어의 아픈 곳을 필연적으로 알고 있지만 가끔 지켜만 보는 경향이 있다.

정기적으로 데이터를 수동으로 추출해서 제공한다. - 엔지니어는 수작업을 싫어해야 하며 스스로 할 수 있도록 도구를 만들어 제공해야 한다.

아키텍처 리뷰를 주저한다. 보통 엔지니어들은 개발하는 것을 좋아하지 공유하는 것을 불편해한다.

FrontEnd 기술 트렌드도 자주 변화하긴 하지만 BackEnd 기술 트렌드도 여러 분야에서 좋은 시도들이 있고 때론 과감히 도입할 필요가 있다. 이전걸 고집하기보다는 도전하는 자세가 필요하다. 그래야 한걸음 더 나아갈 수 있다.

당신의 모든 세포가 그걸 하지 말라고 뜯어말려도 파도를 일으켜야 한다.

Influence without Authority

합리적 근거보다는 권위를 내세워 의사결정을 하려는 매니저들이 있었다. 요즘에는 거의 없을 거라고 생각한다. 이 방법이 실패했다는 건 이미 증명됐다. 일시적으로 진행은 되겠지만 잘못된 결정들은 곧 부메랑이 되어 돌아오고 사업을 망치거나 많은 낭비를 초래한다. 권위를 내세우는 매니저가 많은 회사의 미래는 밝지 않다. 합리적인 의사 결정을 위해 데이터나 비즈니스 및 소프트웨어에 대한 이해가 필요하다. 물론, 매니저라고 해서 그냥 얻어지는 것이 아니다. 긴장해야 하고 진지해야 하며 항상 공부해야 한다. 그리고 한 가지 더는 엔지니어들과 계속 대화해야 한다.