일하는 구조

입사 당시 팀은 기획, 디자인, 개발이 다 따로 나뉘여 있었다. 조직 구조상으로 말이다. 실질적으로 개발과는 한 몸이나 다름 없게 움직였는데, 그도 그럴 것이 자리도 가까웠고 심지어는 업무 편의를 위해 밀착하여 지낼 수 있도록 개발자들 사이 자리에 앉아서 몇 개월간 지내기도 했다. 개발 쪽 스크럼에 나도 참석을 할 때가 있었고 서로서로 무슨 일을 어떻게 진행하고 있는지 훤히 꿰고 있는 편이었다. (디자인의 경우에만 담당팀 팀장에게 리소스 요청을 하여 디자이너를 배정 받는 형태였다.)

이후에는 서비스 단위로 기획, 디자인, 개발, UX까지 한 팀으로 일을 했다. 인원이 많아도 여전히 한 묶음으로 남았고, 주위의 다른 서비스 담당자들이 기능조직 형태로 나뉠 때도 우리는 여전히 목적조직으로 일했다. 그리고 그게 만 4년간 유지되었다.

지난 해 초, 전사 차원에서 모든 조직을 뿌리부터 기능조직화하고, 중요한 단기 프로젝트 위주로 TF 겸직 발령을 내는 형태로 바뀌었다. 그 변화에 따라 우리 또한 바뀌었다. 기동력 있고 효율적으로 목표 달성을 위해 일할 수 있도록.

조직개편 때마다 목적이 무엇일까 생각한다. 크게 봐서 목적조직과 기능조직이라 불리는 두 가지 형태가 갖는 대표적인 장단점들이 있으니까 말이다.

목적조직 형태로 일할 때 션이 했던 말이 있다. 우리는 직군이 무엇이든 모든 담당자들이 합의를 이루는 데에 많은 의사결정 비용을 들이지만, 한 번 결정을 한 후에는 각자가 그간 쌓은 경험과 캐파를 바탕으로 빠르게 달릴 수 있다고. 하나의 목적을 이루는 것에 포커스를 맞추므로 각자의 포지션에서 그 목적 달성을 위한 최선의 솔루션이 무엇일까 고민한다. 그 과정에서 갈리는 부분을 조율하는 데에 시간도 걸리고 충돌도 많지만 그만큼 이해도도 높아지고 책임감도 늘어난다. 오너십과 관여도가 높아지니 본격적으로 프로덕트를 만드는 중에는 초기의 의도에서 어긋나는 일이 줄어든다. 일이 잘 되고 있는지를 판단하는 기준도 뾰족하고 명확하다. 잘된 프로젝트인가-라는 평가 지표 또한 하나의 목적 달성 여부이니 성과에 대해서는 담당자 간의 온도차가 줄어든다.

기능조직 형태에서는 비교적 워터폴 모델(waterfall model)로 일하기 좋다. 목적 달성을 위한 전략을 발제하고 목표를 설정하는 롤을 기획에서 무게 있게 가져간다. 기획안과 시나리오가 완성되면 디자인, 개발 리소스를 할당 받고 디자이너와 개발자는 시나리오를 바탕으로 각각의 작업을 진행한다. 그들에게 프로젝트에 한정해선 좋은 UI, UX가 나왔는가, 결함이 없는 프로덕트를 개발해냈는가 하는 게 성과 평가의 기준이 된다. 기획자와는 다소 다른 의도를 갖고 프로젝트를 진행하게 되는 것이다.

기능조직 구조가 된 후로 기동성이 좋아졌을까. 프로젝트 진행상 이전에 비해 비용이 줄었을까. 효율적으로 프로젝트가 굴러가고 있을까. 조직개편에 대한 사전 공유 및 올핸즈 미팅이 있던 자리에서 로건에게 물었었다. 목적조직으로 오랫동안 일하면서 얻을 수 있었던 장점이 우리 서비스에는 아주 유효하게 작용했다고 생각하고 앞으로 많이 아쉬워질 것 같단 생각이 드는데, 그 아쉬움을 완화하고 기능조직으로 더 잘 일하려면 염두해둘 게 있겠냐고. 명쾌한 답을 듣지 못 했다. 나라도 대답하지 못했을 것이다. 1년이 지났다. 이번에는 기능조직이되, 조금 더 서비스별로 달라붙은 형태로 바뀐다고 한다. 1년 전 대답을 들을 수 없었던 이유에 대한 보완이 이번 조직개편이겠지 하고 기대한다.

쉬는 사이에 눈앞에 떨어진 것들 덕분인지 입 안이 다 터졌다. 출근하면 해야할 일을 두서없이 머릿속에 떠올리고 있다. 잘 될 거야. 열심히 해야지. 위기라고 느낄 때마다 과하게 긍정하려 드는 습관이 또 불쑥 고개를 든다. 그래도, 열심히 해야지.