brunch

매거진 IT회사에서 PM으로 일합니다

라이킷 16 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 이서 Jun 29. 2021

왜 공통 서비스팀을 무시하나요?

공통팀의 운명

이야기는 보통 이렇게 시작한다.

5평 남짓한 작은 오피스. 기가 막힌 아이디어로 의기투합한 몇 명이 모여 작은 IT서비스 회사가 시작된다. 원년 멤버, 창립 멤버라 모두가 헌신적이다. 이는 자발적인 것으로 동기부여는 필요없다. 모두 스스로 희생한다. 당분간 야근, 특근, 주말출근 가리지 않고 노력한다. 회사가 생각대로 '잘 성장한다면' 규모는 점점 커진다. 그렇게 좋은 흐름을 탄다.

몇년이 지난다.

최초에 기본적인 아이템만으로 시작했지만, 새로운 아이디어와 사업은 계속 늘어나고 업무를 진행하기 위한 사이드 업무가 생겨난다. 회사 직원이 수백명 단위로 기하급수적으로 늘어난다. 개발자들끼리 시작했지만 PO,PM,디자이너,프론트,QA,CS,보안 등등 다양한 직군이 추가로 합류한다. 서비스 복잡도는 올라가고, 사일로가 생기기 시작한다.

회사 규모가 빠른 속도로 커졌고, 다양한 서비스가 생겨났고, 업무 역할이 세분화되었다. 최초 희생을 도맡아 했던 멤버들은 이제 엄연히 도메인의 담당자를 넘어서 Management 그룹이 된다. 바로 C레벨이다. 많은 새로운 사람들이 회사에 들어오고, 한 도메인에 많게는 백 명 이상의 수많은 사람들이 참여해 업무를 진행한다. 업무 협의 과정이 복잡해지고, 다양한 프로세스가 만들어진다. 대충 모여 신나게 이야기하고 '해보자!' 라고 결정했던 스타트업 시절은 이제 안녕.

자 이제 그 유명한 '그레이 영역' 이라는 것들이 생겨난다.

소위 말하는 '공통' 업무다.

어느 도메인에도 속하지 않는 일들이다. 너도 쓰고 나도 쓰는 로직이다. 근데 모두 다 '우리팀이 할 일은 아니다'라고 생각한다. 하지만 회사가 커져가고 있기에 반드시 누군가는 해야 한다. 어드민이나 안내장 등의 업무다. 딱히 어떤 서비스에 속하진 않지만 누군가는 해야 회사가 돌아간다.

이때 Management의 역량이 드러난다. 이 그레이 영역의 업무를 명확한 R&R로 분장하여 책임감을 가지고 진행할 팀을 새롭게 구축할 것인가? 아니면 현재 존재하는 '어떤 팀'에 이 업무를 할당할 것인가? 당연히 후자가 편하다. 새로 인원을 뽑을 필요도 없고, 비용을 추가할 필요도 없다. 그 '어떤 팀'에 간단하게 던지면 끝날 일이다. '이거 하세요.' 라고.

과거에는 이렇게 업무를 대충 던져도 굴러갔다. 왜냐면 작은 회사에서 소명의식을 가진 적은 수의 사람들이 모여있기 때문이다. 이들은 기본적으로 회사에 대한 로열티가 충분하고, 동기부여가 스스로 잘 되어있기 때문에 이런 식의 공통업무에 대한 거부감 없이 '그냥 한다.' 군말 없이 그냥 한다. 니꺼내꺼 그런거 없었다. 물론 몇몇 팀원들은 불만이 있을 수 있다. 하지만 그 조직의 조직장은 Management와 같은 레벨이며, 조직원들도 초기 스타트업에 합류한다는 어느 정도의 리스크를 감안하고 왔기 때문에 야근을 하든 특근을 하든 어떻게든 '그레이 영역'의 업무를 처리해준다. 이 업무가 니꺼냐 내꺼냐는 이 정도의 규모의 수준에서는 의미가 없었다. 어차피 소수의 인원으로 굴러가고, 회사는 성장해야 하기 때문에 모두가 노력할 수 밖에 없다. 다 알고 있고, 그래서 헌신한다.

하지만 이제는 회사가 커졌다. 도메인은 세분화 되었고, R&R도 어느 정도 정리가 되었다. 연초에 KPI도 선언되어서 조직의 성과는 철저하게 평가된다. 평가에 따라 보상도 차등 지급 될 것이다. 이 상황에 그레이 영역? 그레이 영역은 팀 KPI에 도움이 되지도 않을 뿐더러, 우리 서비스와는 아무런 관련도 없는데? 우리가 왜? 모두가 하기 싫어한다.

그렇다고, 모두 다시 채용하여 새로운 팀을 꾸린다? 에이, 그건 비용문제인데 윗선에서 좋아할 리 없다. 이 쯤 되는 회사의 규모에서는 founder 의 마인드가 애매할 수 밖에 없다, 아직 성장하는 단계이기 때문에 '아직까진' 비용을 철저하게 아껴야 하며, 어떻게든 마른 수건을 쥐어짜내야 한다는 생각이 강할꺼다. 혹시 IPO라도 걸려있다면 더더욱. 자, 이제 그럼 기존에 존재하는 조직 중에서 이 그레이 영역을 처리할 담당 팀을 찾아야 한다. 어디로 던질까~?

CIO(혹은, CPO or CTO 뭐든 상관없다. 아무튼 누군가)는 조직도를 '슥' 훑어본다. 슥 훑어보는게 중요하다. 제대로 찬찬히 살펴보는 리더라면 그렇게 대충, 아무 팀에나 업무를 떠넘기지는 않겠지. 슥 보고, "여기가 좋겠네." 라고 결정한다. 논리는 없다. 대충 결이 맞으면 넘긴다. 생각하면 귀찮으니까 깊게 생각하지 않는다. 이 부분을 고민하고 논의하고 공감을 얻고자 하는 리더라면 해당 업무의 목적, 그리고 그 업무를 하게 될 팀의 존재 의의와 구성 방식부터 관련자 협의를 통해 정의하려고 하리라. "ㅇㅇ팀에서 진행하시죠." 라고 회의에서 간단하게 선언한다.

ㅇㅇ팀은 당황한다. 왜? 지금 이 업무가 우리 도메인과 무슨 관계가 있지? 당연히 관계가 있다. 결정권자의 머리속에서만 관계가 있다. 예를 들면 이런식이다.

“지금 R&R 문제가 되는 업무가 뭐지? 아, 우편 안내? 오케이, 안내장은 누구한테 나가지? 고객한테 나가는구나. 그럼 고객은 어디서 하지? 여기저기 걸쳐있어서 좀 복잡하다고? 됐고, 대표적인거 한 팀만 얘기해봐. CRM? 오케이. CRM에서 우편 안내장 구성 및 발송, VOC 업무를 총괄하세요. 장기적으로는 전사 메시지 발송에 대한 시스템 구축 과 운영에 대한 고민도 해주세요.” 이렇게 CRM은 메시지 플랫폼 구축 및 고도화에 대한 역할을 맡게 되었다.

ㅇㅇ팀장은 이 업무에 대한 내용을 팀 회의에서 이야기한다. 별 배경이나 당위는 없다. 보통은 'Management 결정사항입니다.' 정도로 끝난다. 팀원들은 당연히 이해하지 못한다. 이걸 왜 저희가 하나요? 류의 질문이 대부분일테다. 팀원들 중 몇은 이제 팀의 비전과 목적에 대해 의구심을 품기 시작한다. 이렇게 그레이 영역 할당의 타겟이 된 팀은 앞으로도 다양한 사이드 잡을 배정받게 될 가능성이 농후하다. 왜냐면 Management 의 머리속에는 '공통 업무를 담당하는 팀' 이라는 플래그가 박히기 때문이다.

새로운 팀이 구축되지 않는다면, 이건 결국 누군가 '희생'을 해야 한다는 얘기다. 어떤 팀이 희생을 해야 그레이 영역 업무가 돌아간다. 아무도 맡기 싫어하는 업무를 어떤 팀에서는 해야 한다. 위와 같은 '사고'를 겪은 팀은 대부분 팀명이 변경된다. 아마도 팀명에 '공통' 혹은 ‘비즈’라는 단어가 들어갈 가능성이 매우 높다. (공통 플랫폼팀 , 코어 플랫폼팀 또는 비즈 플랫폼팀 등으로 명명된다.) 어중간한 두세개의 팀을 합칠 수도 있다. 하지만 합치든 아니든 목적은 명확하다 '공통'이라는 이름으로 온갖 사이드잡을 다 던질 수 있다. '쓰레기통'이라고 생각하면 너무 지나친 비약일까? (여기서 '공통 서비스팀'이라는 명칭은 <Inspired> 에서 해당 종류의 팀을 common service 혹은 core service 로 지칭한 것을 사용했다.)

이 팀에 스스로 지원하는 개발자,기획자가 있을까?

아마 아무도 자원하지 않을 꺼다. 왜냐면 성과를 낼 수 있는 '눈에 띄는 서비스'가 아닐 가능성이 높기 때문이다. KPI는 대부분 'ㅇㅇ서비스 오픈 지원' , 'ㅁㅁ서비스 고도화 서포트' 등이 된다. ('안내 서비스 성능 향상' 등은 애초에 상관도 없는 업무였기에 아무런 동기부여가 되지 않는다.) 대부분 전사 KPI와 무관한 일들을 할 가능성이 높다. 혹은 타 도메인의 KPI달성을 '도와주는' 수준이 된다. 사실상 회사 내의 SI업체처럼 움직인다.

이런 조직은 항상 일이 많다, 그리고 긴급하다. 왜냐면 'ㅇㅇ서비스에서 이거 안되면 런칭 못한대요, 회사 차원에서 큰 이슈입니다' 라는 식으로 요청이 들어오기 때문이다. 우선 순위? '사장님 지시사항입니다.' 라는 마법의 문장이 있다.

생색은 ㅇㅇ서비스가 내고, 야근은 공통팀이 한다. 커리어가 박살나는 개발자, 기획자는 점점 일하는 이유를 잃는다. 아무도 지원하지 않고, 구성원은 동기부여가 힘들어 이탈이 잦으며, 그에 따른 허술한 진행으로 장애는 늘어난다. 이렇게 파멸의 나선으로 빠져든다.

이런 도메인의 특징을 몇가지 생각해보자.

1. 레거시가 많다.

아무도 하기 싫어하는, 여기저기서 주워모은 서비스들이 모여있기 때문에 당연히 레거시 천국이다. 코드는 엉망이며, 코드 한줄을 손대면 10건의 장애가 난다. 히스토리? 문서? 그런게 어딨나. 알음알음 사람을 찾아서 물어봐가며 수정해야 한다. 개발자들은 당연히 기피한다. 들여다보기도 싫다. 코드 볼 생각만 하면 답답하다.

2. 그래서, 고도화 해야 하는데, 주변 요청 처리하느라 정작 우리 도메인 손 볼 시간이 없다.

누군가 의지를 갖고 레거시를 정리해보고자 한다. 하지만 시간이 없다. 왜? 회사가 성장해야 하기 때문에 여러 서비스들이 요청하는 공통 업무를 처리해줘야 하기 때문이다. 그냥 분기를 태우든 언발에 오줌누기를 하든, 코드가 돌아가게만 한다. 고도화? 리펙토리? 누군가 하겠지.

3. 우리 KPI는 뒷전이 되고, 다른 도메인 성과만 올려준다.

2번과 비슷한 내용이다. 연초에 세운 KPI는 기억도 안난다. Management가 챙기는 서비스의 요구사항이 우선 1순위가 되어 최대한 리소스를 투입한다. (이런 식의 우선순위 챌린지는 1년 내내 이어진다.) 연말이 되면 '우리 뭐했지?' 라는 생각이 들며 KPI는 모두 미달성 상태로 남아있는 차트를 멍하니 바라본다. 동기부여는 남의 나라 얘기가 된다. 이 특성 때문에 연초에 계획을 세우기도 어렵다. '어차피 못할꺼잖아?' 라는 패배 의식이 팽배하다.

4. 특성상 장애에 민감하다.

'공통'이기 때문에, 전사에 영향범위가 넓게 펼쳐져 있다. 1번에 이야기 했듯 레거시가 많아 사소한 코드 수정이 큰 문제를 일으킬 수 있다. 장애가 나면 전사장애로 이어진다. 열심히는 하는데, 장애 하나로 회사에 피해를 입힌 역적이 된다. 일은 일대로 하고, 욕은 욕대로 먹는다.

5. 위와 같은 이유로 보상에 취약하다.

1,2,3,4 번과 같은 이유로 결국 연말 평가는 최하위에 그칠 가능성이 높다. 평가는 연봉 및 보상과 연계된다. 차가운 보상에 팀원들은 의욕을 잃는다.

6. 이탈자가 많다. 합류자가 적다.

큰 꿈을 안고 나름 핫하다는 회사에 들어왔는데, SI처럼 일 할 줄은 몰랐다. 말해 무엇하랴.

그렇다면 이런 팀은 어떻게 해야 성과를 낼 수 있을까?

팀의 최초 구성 목적과 목표에 대한 정의가 굉장히 중요하다. 이 팀은 왜 존재하고, 어떤 일을 하며, 그것이 이 회사에 무슨 기여를 하는지에 대한 최초 정의를 '반드시' 해야 한다. 그래야 '사내 SI팀'이라는 패배주의의 확산을 사전에 막을 수 있다. 절대로 기존 팀에 대충 그레이 업무를 떠넘기며 공통팀으로 전환시키면 안된다. 최초부터 '공통'업무를 하는 팀이라는 목적을 선언하고 팀빌딩을 해야한다.

레거시 코드, 아키텍쳐 기술 부채를 해결 할 수 있는 물리적 시간을 강제로라도 보장해줘야 한다. 이리 치이고 저리 치이다 보면, 해결하지 못한 내부 문제가 쌓여 언젠가 대형 장애를 유발할 수 있는 위험으로 다가온다. 외부 요청사항을 처리하는 리소스와 별개로, 내부 고도화를 위한 리소스를 Fix하여 추가 배정해주는 것으로서 잠재적 위험 요소를 사전에 관리해야 한다. '바빠죽겠는데, 우리가 지금 그런거 할 시간이 어딨어?'라는 말이 나오지 않도록 신경 써줘야 한다.

또한, 해당 팀원의 동기부여에 대한 강한 드라이브가 필요하다. 무엇보다 차별화된 보상 정책이 필요하다. 궂은 일을 하고 있다는 격려와, 그에 따른 보상만이 팀원의 사기를 북돋을 수 있고, 그것이 공통팀의 성과를 자연스럽게 이끌 수 있다. (C레벨 직속 조직으로 관리하며 챙기는 것도 방안이 될 수 있겠다.)

해당 팀장은 팀원의 동기부여를 위해 끊임없이 노력해야 한다. 단순히 '업무를 던지는' 식의 진행으로는 제대로된 성과를 기대할 수 없다. 파멸의 나선은 팀장의 행동으로 부터 시작된다. 팀장 스스로 해당 팀의 목적과 소명에 대한 명확한 비전을 가지고 팀 리딩에 임해야 한다. '어차피 누군가는 해야 하니까' 정도의 논리만으로는 아무도 공감하지 않는다. 개인의 영달을 위해 정치적 목적을 가진 팀장이 이 팀에 부임한다면, 그 결과는 비참할 수 밖에 없다.

공통 서비스팀은 어느 회사에나 존재하며, 아무도 신경쓰지 않는 곳에서 열심히 회사의 성장과 안정을 위해 노력하고 있다. 회사 매출에 직접적으로 기여하는 서비스에 대한 케어 및 보상도 물론 중요하다. 하지만, 이렇게 음지에서 열심히 노력하는 지원 조직의 기여도를 무시한다면, 결국 예상치 못한 곳에서 대형 장애를 일으킨다거나, 업무 지식 부족으로 인해 지연이 일어나는 등 갑작스런 문제를 맞이할 수 있다.

지금도 야근을 하며 다른 서비스 지원을 위해 열심히 고생하고 있을 대한민국의 여러 공통 지원팀들에게 박수와 응원을 보낸다. 여러분들은 잘 하고 있습니다. 화이팅.

keyword