[NBT가 일하는 방식 #1] NBT 제품 개발 조직의 구조

사람은 환경의 지배를 받는다. 어떤 환경에 놓여있는가에 따라 그 사람의 생각과 행동이 크게 달라질 수 있기 때문이다. 나는 어떤 조직에 속해있는지에 따라 같은 사람이라도 역량, 생산성, 의사소통, 리더십 같은 것들이 크게 달라진다고 믿는다. 하지만, 거꾸로 사람이 환경을 지배하기도 한다. 다시 말해서 사람은 자신에게 주어진 환경을 능동적으로 변화시킬 수 있는 힘을 갖고 있다.

나는 2014년 1월에 NBT에 합류한 이후 지금까지 다른 구성원들과 함께 “어떤 조직 구조가 현재 우리에게 최선일까?”에 대한 고민을 끊임없이 해왔다. 2년 넘게 지속적으로 변화해 온 NBT 제품 개발 조직의 현재 모습을 소개해보려고 한다.

파티/클래스 시스템

NBT 제품 개발 조직의 현재 모습은 Spotify의 조직 구조에서 많은 부분을 빌려왔다. 모든 단위 조직은 매일 모여 현재 상황을 공유하고 문제를 해결하는 데 도움이 될 수 있는 액션 아이템을 만들고 행동한다.

온라인 게임을 해본 사람들은 알겠지만, 던전에 들어가서 퀘스트를 성공적으로 완수하려면 탱커, 딜러, 힐러, 때로는 하이브리드 캐릭터까지 다양한 클래스가 함께 모여 파티를 구성해야 한다. 파티나 클래스라는 용어는 게임에서 따온 것이다.

파티

파티는 공통의 방향성을 갖고 함께 일하는 기본 단위 조직이다. 각자 다양한 전문성을 갖고 있는 사람들이 함께 모여 긴밀하게 협업하고 있으며, 기본적으로 같은 비전을 공유한다.

매일 일일 스탠드업 회의에 모여 프로젝트 진행 상황을 공유하고, 매주 금요일 회고를 통해 다음 주에 좀 더 좋은 방법으로 일할 수 있는 방법을 함께 논의한다. 짝 프로그래밍이나 몹 프로그래밍과 같은 활동도 활발하게 일어나고 있으며, 한 자리에 모여 앉아있기 때문에 프로젝트를 진행하면서 이슈를 쌓아두지 않고 바로바로 해결할 수 있다.

캐시슬라이드를 개발하는 파티는 모두 세 파티인데, 각 파티는 광고 시스템을 위주로 포인트 적립, 상점 등의 포인트 소비, 앱 컨테이너나 가입/로그인/뉴스 등과 같은 사용자 기본 기능을 담당한다.

클래스

클래스는 같은 전문성을 갖고 있는 사람들이 서로의 성장을 돕고 공통의 관심사를 공유하는 조직이다. 모여 앉아있지 않기 때문에 평소의 결속력은 파티보다 약한 편이지만, 정기적으로 모여 진행하는 다양한 활동이 있다. 파티 내에서 다루기 어려운 문제가 생기면 함께 해결 방안을 찾아보기도 하고, 다 같이 코드 리뷰를 진행하기도 한다.

클라이언트 – 주로 안드로이드 앱을 개발하는 엔지니어들이 속해있다. 캐시슬라이드 앱의 개발과 테스트를 담당한다.
서버 – 주로 루비 온 레일즈로 서버 개발을 담당하는 엔지니어들로 구성되어 있다. 캐시슬라이드 백엔드를 개발하고 테스트한다. 클라이언트 클래스도 마찬가지이지만, 좋은 소프트웨어를 개발하려면 필요한 것이 코딩만은 아니다. 그렇기 때문에, 요구 분석, 설계, 타 팀과의 의사 소통, 테스트, 배포, 기능 출시 후의 성과 분석 등 제품을 개발하고 유지보수하는 데 필요한 모든 활동이 소프트웨어 개발이다. NBT의 소프트웨어 엔지니어는 소프트웨어를 개발하는 데 프로그래밍이 전부하고 생각하지 않으며, 파티 단위로 이루어지는 다양한 개발 활동에 적극적으로 참여한다.
이매지니어 – “Imagineer“라는 단어는 Imagine(상상) + Engineering(공학)의 합성어다. 새로 만들어낸 말이 아니라 영어 사전에 당당히 등재되어 있는 단어다. 위키백과를 찾아보면 “Imagineering is the implementing of creative ideas into practical form.”라고 정의하고 있다. 이매지니어는 사실 다른 것이 아니라 다른 회사에서 흔히 말하는 “기획자”다. 아직 많은 사람들이 이 이름을 어색해하고 있지만, 나는 사람들이 “기획자”라는 단어를 들었을 때 본능적으로 발생하는 (역할과 책임에 대한) 사고의 제한을 원치 않았기 때문에, 굳이 이런 생소한 이름을 선택했다. 우리 이매지니어는 요구 사항을 전달한 내부 고객을 파티에 대변하고, 파티를 고객에게 대변하면서 프로젝트 진행의 중추를 담당한다. 이매지니어 역시 파티에 소속되어 다른 구성원들과 함께 협업하기 때문에, 기획서 작성을 완료했을 때 프로젝트가 끝나는 것이 아니라, 고객에게 가치를 전달했을 때 프로젝트가 끝난다는 것을 잘 알고있다.
데브옵스 – 캐시슬라이드의 시스템 아키텍처를 책임지고 있다. 캐시슬라이드가 24시간 비행 중인 비행기라면 이들은 이 비행기가 안전한 비행을 계속할 수 있도록 해주는 사람들이다. 지금은 파티에 속해있지는 않고, 독립적으로 시스템 측면에서 각 파티를 지원하고 있다.
엔지니어링 컬처 – 아마도 다른 회사에는 없는 가장 독특한 클래스가 아닐까 생각한다. 스크럼팀에서 이야기하는 스크럼 마스터와 가장 가깝다고 할 수 있다. 엔지니어링 컬처 클래스가 지향하는 궁극적 목표는 파티 구성원들이 스스로 더 좋은 환경을 만들어내고 더 높은 역량을 발휘할 수 있도록 지원하는 것이다. 일일 스탠드업 회의, 주간 회고 등을 퍼실리테이션하고, 개발 프로세스를 개선하여 칸반 보드에 반영하며, 개발 생산성 지표를 관리하면서, 끊임 없이 개선 지점을 찾고 해결 과정을 돕는다. 또 한 가지 특징은 QA를 함께 맡고 있다는 점이다. 개발 결과물을 테스트한다는 것이 아니라, 제품의 품질을 처음부터 끝까지 항상 주시하고 있으며, 다양한 방법을 통해 품질을 높일 수 있는 방법을 모색한다.

PD와 길마

이렇게 파티와 클래스가 씨줄과 날줄로 얽혀있는 제품 개발 조직 전체를 NBT에서는 “길드“라고 부른다. (스포티파이의 길드와는 다르다.) 길드에는 조직 전체 관점 (또는 전사 관점)에서 구성원들을 지원하는 두 가지 역할이 있다.

PD – 제품의 방향을 제시하고, 제품 관련 의사 결정을 위한 기준 및 가이드라인을 수립하여 더 좋은 제품을 개발할 수 있도록 한다. 현재는 CTO 역할을 겸임하고 있고, 길드의 WHAT을 담당한다.
길드 마스터 – 업무 개선 지점을 도출하고, 자발적으로 개선이 이루어질 수 있는 업무 환경을 구축하여, 더 좋은 방법으로 개발할 수 있도록 한다. 현재 내가 수행하고 있는 역할이고, 길드의 HOW를 담당한다. (규모를 축소하여 파티 관점에서 보았을 때, 파티의 WHAT은 이매지니어 클래스가 HOW는 EC(엔지니어링 컬처) 클래스가 담당한다.)

중요한 것은 PD와 길마가 WHAT과 HOW와 함께 WHY를 고민하는 것을 잊지 않는다는 점이다. 우리의 존재 이유는 무엇인가? 우리는 왜 이 일을 하고 있는가? 우리는 왜 이런 방식으로 일하고 있는가?

스타트업 클러스터

좋은 소프트웨어를 설계하는 원칙과 좋은 조직을 설계하는 원칙은 별로 다르지 않다. 소프트웨어를 훌륭하게 설계하려면 흔히 “응집도는 높고, 결합도는 낮은” 모듈로 설계하라고 이야기한다. 조직을 구성할 때도 마찬가지다.

혼자 프로젝트를 진행하는 경우라면 별다른 의사 소통이 필요없다. 그러나 프로젝트에 참여하는 사람이 늘어날 수록 필요한 의사 소통의 양은 기하급수로 증가한다. 다음은 단일 조직 내 의사 소통 경로를 계산하는 공식이다.

C = N(N-1)/2

사람은 주변에서 발생하는 정보량이 받아들일 수 있는 수준을 넘어서면, 본능적으로 그 수준을 감당 가능한 정도로 낮추기 위해 받아들이는 정보의 양을 줄인다. 하지만 정보를 걸러내는 필터의 기준이 사람마다 다르기 때문에, 그 때부터 “의사 소통이 부족해요.”, “전달에 실수가 있었나봐요.”, 심지어 “저 사람하고는 말이 안통해요.”와 같은 현상이 늘어나기 시작하는 것이다.

프로젝트에 참여하는 인원이 늘어나면, 필요한 의사 소통의 양이 많아지고, 당연히 실수가 발생할 가능성이 높아진다. 이 때 필요한 것이 바로 “응집도는 높고, 결합도는 낮은” 조직이다.

Scale-out vs. Scale-up

서버의 처리 능력을 높이는 방법은 크게 두 가지가 있다. 하나는 서버 자체의 성능을 올리는 스케일-업(scale-up)이고, 다른 하나는 서버 대수를 늘리는 스케일-아웃(scale-out)이다.

대부분의 조직은 스케일-업 방식으로 조직을 확장한다. 즉, 그냥 무작정 인원만 늘리는 것이다. 업무를 처리할 수 있는 사람이 늘어나면 거기에 비례해서 업무 처리량도 함께 늘어날 것이라고 생각한다. 기계도 스케일-업 방식으로는 확장에 한계가 있다. 성능을 무한정 높일 수 없을뿐더러 비용도 기하급수적으로 증가한다.

상대적으로 스케일-아웃은 확장 비용이 적게 들고, 변화에 유연하게 대응할 수 있다. 그러나 스케일-아웃의 단점은 관리 비용이 증가한다는 점이다. 로드를 상황에 따라 분산시킬 수 있는 로드 밸런서도 있어야 하고, 서버가 한 대일 때는 필요하지 않았던 병렬 프로그래밍, 파일 시스템의 클러스터링 같은 기술도 필요하게 된다. (그래서, 관리자가 필요하지 않다고 이야기하는 스크럼팀과는 다르게, NBT 개발 조직에서는 관리자의 역할을 중요하게 생각한다. 하지만 우리 조직에서 관리자는 책임과 권한을 갖고 상황을 통제하는 관리자가 아니라, 환경을 만들고 필요한 지원을 하는 관리자다.)

우리 NBT에서 선택한 조직 확장 방법은 스케일-아웃이다. 필요할 때마다 상황에 따라 유연하게 변화할 수 있다. 궁극적으로 각 파티가 마치 독립적인 “스타트업”처럼 운영되는 방향을 지향하고 있으며, 그래서 파티/클래스 시스템을 스타트업 클러스터 방식이라고 부르기도 한다. 현재는 3개의 파티로 길드가 구성되어 있지만, 그것은 현재 3개의 파티가 필요하기 때문이다.

파티는 “스타트업“과 같이, 클래스는 “커뮤니티“와 같이 작동하는 것이 NBT 제품 길드의 조직 구성 철학이다.

향후 계획

NBT는 창업 3년차 스타트업으로는 이례적으로 성장하면서 많은 변화를 겪어왔고, 그 변화는 현재 진행형이다. 당연히 조직 구성에 있어서도 기대 이상으로 잘 움직이는 부분도 있고, 실망스러운 부분도 있다. 지금도 많은 개선 지점들이 있으며 그런 문제들을 어떻게 더 좋게 만들 수 있을지, 그래서 어떻게 하면 우리가 더 좋은 제품을 더 행복하게 만들 수 있을지 치열하게 고민하고 있다.

분명한 것은, 현재의 조직 구조로 계속 머물지는 않을 것이라는 점이다. 인원 수, 내부 구성원들의 역량, 시장 상황, 제품 개발 단계 등 모든 것이 끊임없이 변화하기 때문에, 최선의 조직 구조는 거기에 맞춰 항상 변화할 수 밖에 없다. 앞으로도 NBT는 상황에 떠밀려 어쩔 수 없이 조직 구조를 바꾸는 회사가 아니라, 상황을 우리에게 유리하게 변화시킬 수 있도록 조직 구조를 바꿔가는 회사가 되려고 한다.