시작하기

얼마 전, DevCon에 다녀왔다. (사실 벌써 일주일이나 지났다..)
여러 세션을 들으며 유익한 시간을 보냈는데, 그중에서도 인프랩의 향로님 발표가 특히 기억에 남아서 기록으로 남겨본다.

처음에는 큰 기대 없이 발표를 듣기 시작했다. 제목을 보고 익숙한 주제일 거라고 생각했는데, 발표를 들으면서 내 머릿속에 신선한 충격이 날아왔다. 예상과는 다른 강렬한 메시지와 인사이트가 가득한 발표였다.

그 충격과 배움을 정리하며, 이번 DevCon에서 들었던 향로님의 발표 후기를 남겨보려고 한다.

9명의 제품팀이 48명이 되기까지의 여정

발표 제목은 “9명의 제품팀이 48명이 되기까지의 여정” 이었다.

이전 회사에서 나는 개발팀이 단 4명인 상태에서 입사했다. 내가 다섯 번째 개발자로 합류한 후, 회사를 떠날 때쯤에는 개발팀 규모가 63명까지 성장해 있었다. 이러한 경험이 있어서, 이번 발표도 비슷한 내용일 거라고 예상했다.

발표 초반 50% 정도까지는 내 예상이 맞았다. 조직이 커지면서 목적 조직과 기능 조직을 오가며 성장하는 과정, 그리고 결국 두 가지 조직 형태를 모두 운영하게 되는 흐름은 익숙한 이야기였다.

예상대로 발표도 시작은 그러했다.

탈 워드프레스

내가 다섯 번째 개발자로 입사했던 회사도, 사실 워드프레스를 걷어내기 위해 본격적으로 개발팀을 꾸린 것으로 기억한다.

약 10년 전쯤, 혼자 사업을 시작하는 사람들에게 워드프레스는 거의 대세였다. 개발 지식이 없어도 손쉽게 웹사이트를 만들 수 있었고, 다양한 플러그인 덕분에 기능 확장도 용이했기 때문이다. 하지만 규모가 커지면서 한계를 체감하는 경우가 많았다.

가장 큰 문제는 유지보수였다. 워드프레스는 PHP 기반인데, 시간이 지날수록 PHP를 다룰 수 있는 개발자가 점점 줄어들고 있었다. 또한, 사용자가 증가할수록(특히 회원 가입자 수가 많아지거나 결제가 많아지면) 성능 문제가 심각하게 드러났다. 최적화가 어렵고, 페이지 로딩 속도가 지나치게 느려지는 문제가 있었다.

그런 점에서 인프랩도 비슷한 고민을 했다는 것이 흥미로웠다. 워드프레스를 걷어내는 과정에서 JavaScript와 Node.js를 중심으로 기술 스택을 전환하고, 그에 맞는 개발자를 적극적으로 채용하기 시작했다는 점이 인상적이었다.

리드급은 바로 리드로 채용하지 않는다.

내가 재직 중인 회사에서도 어떤 리드급도(심지어 C레벨이라 하더라도) 입사하자마자 “나 리더요!” 하지 않는다. 반드시 매니저로 입사한 후, 동료들과 함께 업무를 진행하며 신뢰를 쌓고 인정받아야만 리드로 승진할 수 있다. (승진이라는 표현이 맞는지 모르겠지만, 직급이 바뀐다)

인프랩 역시 이런 구조를 따르고 있다고 했고, 내가 예상했던 것보다 훨씬 긴 매니저 기간을 계약했다고 해서 흥미로웠다.
하지만 실력은 어디 가지 않는 것 같다. 3개월 만에 인정받고 C레벨로 올라갔다고 한다.

입사하자마자 리드급이 아닌 매니저로 들어가는 것은 분명 모험이자 도전이다. 만약 3개월 후에도 동료들에게 인정받지 못한다면? 선택지는 두 가지다.

다시 이직하든가, 아니면 현실을 받아들이고 조직에 적응하든가.

연차가 높아지고 직급이 올라갈수록 이러한 선택은 더 어려워진다. 단순히 기술력이 뛰어난 것만으로는 부족하고, 조직 적응력과 리더십을 빠르게 증명해야 하기 때문이다.
그런 점에서, 리드급으로 바로 입사하는 것보다 검증 과정을 거치는 방식이 더 현실적이고 안정적인 접근일지도 모른다.

구성원 중 한 명인 리더쉽이 필수

스쿼드로 일하다 보면 한 조직 안에 PM, PD, FE, BE가 모두 모여 있게 된다. 그리고 PO를 제외하고 최소한 한 명 이상의 리더십 있는 사람이 반드시 필요하다고 했다.

이 말에 깊이 공감했다. 예전 회사에서도 팀의 명칭은 다를지언정 대부분 스쿼드 형태로 일해 왔기 때문이다. 스쿼드 방식에서는 공식적으로 리더라고 정해진 사람이 없는 경우도 종종 있다. 문제는 이런 상황에서 PO가 조직을 이동하거나 퇴사했을 때 발생한다.

만약 팀 내에서 누구도 리더십을 발휘하지 않는다면? 그 조직은 방향성을 잃고 흔들리기 쉽다. 의사결정이 지연되고, 결국 산으로 가는 경우도 적지 않다. 그렇기 때문에 PO가 아니라도 최소 한 명 이상의 리더십 있는 사람이 있어야 한다는 점이 더욱 중요하게 느껴졌다.

조직을 구성하는 조직도를 종종 (어쩌면 자주) 보거나 고민해보고는 하는데, 조직을 구성할 때에는 이런 부분도 충분히 고려되어야겠구나 라는 생각을 했었다.

특수 조직

현재 내가 속한 조직에서는 이러한 팀을 TF(Task Force) 형태로 운영하며, 필요에 따라 구성하고 프로젝트가 종료되면 해체하는 방식이다. 하지만 인프랩에서는 이런 조직을 상시 운영하며, 각 구성원이 R&R(Role & Responsibility)에 대한 오너십을 가져가는 형태라는 점이 흥미로웠다.

조직이 성장하면 자연스럽게 목적 조직과 기능 조직이 분리되는 것이 일반적인 형태라고 생각해왔다. 그런데 인프랩의 방식은 목적 조직 사이에 기능 조직을 병렬로 운영하는 구조라고 생각해보면 이해하면 좀 더 명확할까?

목적 조직이 독립적으로 움직이면서도, 기능 조직이 그 안에서 병렬적으로 운영되며 균형을 맞추는 구조라면, 기존에 생각했던 조직 운영 방식과는 조금 다른 접근법이라는 점에서 인상적이었다.

챕터 조직

이 시점부터 더욱 집중해서 발표를 들었던 것 같다.

인프랩에서는 정기적인 조직 이동을 한다고 했다. 나 역시 조직 이동의 적절한 주기가 어느 정도여야 할지는 아직 확신이 없지만, 정기적인 이동 자체는 반드시 필요하다고 생각한다.

특히 중요한 점은, 누군가 조직을 이동할 때 그것이 “적응을 못해서 옮기는 것”처럼 비쳐서는 안 된다는 것이다. 발표에서도 같은 이야기를 해주셨고, 이 부분에 깊이 공감했다. 조직 이동이 자연스러운 성장 과정으로 받아들여져야지, 부정적인 인식이 따라붙으면 조직 내 유연성이 크게 저하될 수밖에 없다.

조직을 주기적으로 옮기는 것의 또 다른 장점은, 다른 조직을 단순히 “남의 조직”으로만 인식하지 않게 된다는 것이다. 발표에서는 조직 이동이 많을수록 “미래의 내 조직” 이 될 수도 있다는 관점으로 바라보게 된다고 설명했다.

이런 사고방식은 코드 리뷰에서도 영향을 미친다. 만약 다른 조직에서 이상한 로직을 짜거나 구조적으로 문제가 있어 보이는 결정을 내렸다면? 평소라면 그냥 “남의 일”이라 여기고 넘어갈 수도 있다. 하지만 조직을 이동할 가능성이 높다면 이야기가 달라진다. 언젠가는 내가 속하게 될 조직, 내가 떠안을 레거시라는 생각이 들기 때문에, 더 적극적으로 코드 리뷰에 참여하고 개선하려는 태도를 가지게 된다.

이런 문화는 장기적으로 조직 전체의 코드 품질과 협업 문화를 긍정적으로 변화시키는 데 큰 영향을 줄 수밖에 없을 것 같았다.

전사의 과제 !== 개별 조직의 목표

이 부분에서 새로운 시각으로 바라보게 된 내용이 있었다.

스쿼드 체제로 일하면 각 스쿼드마다 개별 목표를 가지게 된다. 하지만 여기서 중요한 점은, 스쿼드의 개별 목표가 곧 전사적인 과제와 동일한 것이 아님에도 일을 진행해야 한다는 것이었다.

우리 스쿼드의 목표가 아니더라도, 그는것이 회사 전체의 목표에 부합한다면 기꺼이 돕고 협력하 문화가 필요하다는 이야기가 특히 인상적이었다.

조직 내에서는 종종 “우리 팀 일이 아니니까”라며 선을 긋거나, 스쿼드 목표에만 집중하는 경우가 있다. 하지만 중요한건 스쿼드의 목표보다 회사가 성장하고 목적을 달성하는것이 더욱 우선해야하는 한다는 것이다. 우리 스쿼드의 목표를 넘어 전사적 목표에 기여하려는 태도가 필요하다는 점을 다시금 깨닫게 되었다.

이와 관련해 발표에서는 한 가지 예를 들었는데, 이것이 특히 인상적이었다.

한 스쿼드에서 정체가 발생하면, 이는 단순히 그 스쿼드만의 문제가 아니라 전사적인 문제로 이어진다는 것이다.

예를 들어, 백엔드(BE) 업무가 과중한 상황에서 단순히 엔지니어를 더 채용한다고 해서 문제가 해결되는 것은 아니다. 단기적으로는 도움이 될 수도 있지만, 만약 시간이 지나 BE 업무가 줄어들면 새롭게 채용한 인력은 어떻게 할 것인가? 그들의 역할과 생산성을 유지하기 어려워질 것이고, 이는 결국 조직 운영의 비효율로 이어질 수밖에 없다.

따라서 중요한 것은 단순히 리소스를 늘리는 것이 아니라, 어디에서 병목이 발생하는지 정확히 파악하고, 그 부분을 조직 전체가 함께 해결하려는 자세를 갖는 것이다.

어떤 문제가 특정 팀에서 터진다고 해서 그것이 그 팀만의 문제라고 생각해서는 안 된다. 조직 전체가 하나의 유기체처럼 움직이며, 문제가 발생한 지점을 함께 해결하는 문화가 필요하다는 점이 인상 깊었다.

원래 담당하던 조직이 해당 업무를 진행하면 2개월이 걸리지만, 다른 조직이 대신 맡으면 3개월이 걸린다고 가정해 본다면 누가 하는 것이 더 효율적일까?

나는 이와 같은 고민을 평소에도 종종 해왔다. 더 빨리 할 수 있는 팀이 하는 것이 맞을까, 아니면 다른 팀이 맡더라도 진행하는 것이 맞을까?

이 발표를 들으면서 이 질문에 대한 답이 보다 명확하게 정리되었다.

핵심은 평균 속도는 떨어질지라도 전체 속도는 올라간다는 것이다. 즉, 특정 조직이 더 빠르게 할 수 있다고 해서 반드시 그 조직이 해야 하는 것은 아니다. 전사의 목표 관점에서 보면, 다른 조직이 맡더라도 회사의 전체적인 속도를 높이는 것이 더 중요하다는 것이다.

이러한 시각에서 보면, 각 스쿼드의 목표가 전사의 목표와 항상 일치하는 것은 아니지만, 전사의 입장에서 진행하는 것이 맞을 때가 있다는 점을 다시 한번 깨닫게 되었다.

단기적인 효율성만 고려하는 것이 아니라, 장기적으로 조직 전체가 더 유연하고 균형 있게 성장할 수 있도록 분배하는 것이 중요하다는 점에서, 기존에 내가 가지고 있던 사고방식을 확장할 수 있는 계기가 되었다.

결론

이번 발표를 통해 조직 성장과 협업에 대해 생각을 많이 하게 되었다.

각 스쿼드가 개별 목표를 가지고 있지만, 결국 전사적 목표를 향해 협력하고 유기적으로 움직여야 한다는 점이 가장 큰 수확이었다. 또한, 리더십의 역할과 정기적인 조직 이동이 어떻게 조직을 건강하게 성장시킬 수 있는지, 그리고 병목 현상을 해결하는 협력의 중요성을 알게된 것 같다.

“우리 팀의 일이 아니다”라는 생각을 넘어, 전체 조직을 위한 해결책을 함께 모색하는 자세가 필요하다는 점에서 앞으로의 조직 운영에 대한 시각이 조금은 더 넓어졌다.