레거시 운영개발팀을 수습하다.

이건 꽤 오래전, 

어떤 조직에 불끄러 들어갔을 때 이야기다.

 

Red Zone

조직 피로도를 낮춰야한다.

맨날 밤늦게 퇴근하는 것도 하루 이틀이지.

이대로는 피로도가 높아서 언젠가 빵하고 터지고 만다.

 

빵하고 터지면 "조직노하우"는 제로가 되고 만다.

매번 제로에서 새출발 할 수는 없다.

탑을 높이려면 계속 남이 쌓은 일에 뭔가를 더해가야 한다.

 

가장 급한게 "조직피로도"를 낮추는거다.

피로도를 낮추려면 "적시퇴근"을 시켜야 한다.

"정시퇴근"까진 못해도 몸이 달궈지기 전에 퇴근시켜야 했다.

 

그러려면 업무량을 자르거나

일정을 당기고 미룰 수 있어야 한다.

음, 그걸 조직에 어필할 수 있을까?

조직이 그런 딜을 받아주려면 믿음이 필요했다.

내가 펑크를 내지 않을 거라는 믿음.

일정은 고객합의까지 필요했기 때문이다.

 

어쨌든 예측가능성이 필요했다.

그러려면 업무가 계량적이고 예측가능해야 한다.

조직은 예측이 -1 틀렸다고 갈구진 않는다.

다만 잘 관리되고 있는지를 묻는다.

성과를 통해 나를 먼저 증명해야 했다.

 

예측가능하려면, 성과를 들쭉날쭉 관리하면 안된다. 

꾸준하도록 관리해야 한다.

아웃풋이 일정해지려면, 인풋이 일정해야 한다.

뭔가 뺑글뺑글 도는 느낌이지만,

일단 뛰어들면 흐름이 달라진다.

 

긴 업무가 있고, 짧은 업무가 있다.

이걸 잘 섞어서 배분하고 일정을 조율했다.

예측이 실패해서 늘어나기도 했다.

 

하지만 나도 바보는 아니다.

예측은 훈련에 의해 정교해진다.

처음엔 틀려도 2-3개월 지나니 얼추 맞아졌다.

이런 걸 "업무관리", "Task Management" 라고 부른다.

그런데 이런건 어떻게 해야 하는걸까?

누가 가르쳐주는걸까?

없다. 없으니 알아서 해야 한다.

 

1주일짜리 일이 있고, 2주짜리 일이 있다.

그 일은 상호 연관되어 있다.

얼마나 걸릴까, 얼마나 걸린다고 이야기해야 할까?

 

이걸 판단하려면 누군가 책임지고 모아서 관리해야 했다.

처음에는 내가 했다.

개발하다 말고 개발업무도 관리했다.

양이 많았다. 하지만, 죽지는 않겠지.

 

노하우가 생기면 프로세스화시키고 직원들에게 가르쳐주었다.

한동안 업무부하가 많이 걸렸다.

죽을 것 같았다.

업무를 정형화시키니 다행히 팀원들이 잘 가져가줬다.

감사했다.

죽지는 않았다.

 

Orange Zone

무거운 업무에 대해서는 보상이 필요하다.

돈이 아니라도 좋다.

적어도 밤샘근무 후 오전 근무는 빼줘야 한다.

휴식룰이 만들어져야

팀원들 스스로 일정계획이 가능해진다.

자기예측을 통한 일정계획이 가능해져야,

업무집중도가 높아진다.

 

조직피로도가 많이 낮아졌지만,

아직 주황색이다.

옐로우존까지도 가지 못했다.

 

더 낮추려면 휴가를 보내야했다.

쉬고 와야 새로운 일을 할 수 있다.

하던 일도 떨어내는 맛이 있어야 힘이 난다.

배우는 게 있어야 보람있는 일도 된다.

 

그런데 휴가를 보내려면,

한동안 누군가 빈자리를 메꿔줘야 한다.

적어도 업무가 STOP 되지는 말아야 한다.

 

그러려면 업무를 서로 백업할 수 있어야 한다.

서로의 소스도 유지보수할 수 있어야 했다.

100% 완벽하게 대체하지 않아도 된다.

어차피 메인은 메인이 하는거다.

보조는 메인이 재충전할 시간만 주면 되는거다.

 

"랭귀지"가 같아지면 상호간 백업피로도가 확 줄어든다.

IDE 도 같고 서버환경도 같아지기 때문이다.

서로 백업하기 위해 개발상황 공유가 잦아졌다.

하지만 뭔가 벽에 막힌 것 같았다.

뭘까?

 

자기 코드에 대한 애착이 컸다.

"코드공유"를 치부가 까발리는 것처럼 부끄러워했다.

"코드수정"을 잘못이 지적된 후 강제교정 당하는 것처럼 수치스러워했다.

공유와 리뷰가 되다가 말았다.

 

"내 코드야." 라는 생각을 떨쳐낼 필요가 있었다.

"내가 만들었지만, 남의 코드다."

"회사코드를 내가 더하고 수정하는거다."

이렇게 인식시켜주었다.

그러니 코드공유의 필요성이 절실해졌다.

 

내 것이 아니니까 서로 잘 관리할 규칙이 필요해졌다.

코드품질관리 규칙과 프로세스를 만들 수 있었다.

물론 Best code 는 만들어질 수 없었다.

Best code 는 한사람이 미친듯 품질을 올려야 하기 때문이다.

그러려면 강한 소유본능이 필요한데,

그건 현재 조직에 어울리지 않았다.

 

그냥 Bad Code 가 방치되지 않는 것,

Good Quality 수준에서 유지되는 것에 만족했다.

 

그런데, 코드품질이 올라도 장애는 발생했다.

오래된 레거시라 배포직후, 1주일 후, 한달 후

다양한 형태로 자주 발생했다.

배포과정이 문제였다.

 

그걸 교정하기 위한 "배포프로세스"란 게 있었다.

그런데 "누군가"를 검증자로 만들고 책임을 거기다 떠밀고 있었다.

미친...

그런 프로세스를 폐기시켰다.

 

"검증"은 "책임의 이동"이 아니다.

"검증"은 "불완전성의 보완"이다.

그냥 서로 검증하도록 프로세스를 만들었다.

조금 실수해도 나무라지 않았다.

대신 빨리 변경조치하거나, 원복하면 되었다.

 

프로세스를 처음 만드니, 어떻게 해야 할지 몰랐다.

처음에는 내가 해보았다.

서툴러서 우스꽝스러웟다.

내가 무슨 말 하고 있는지도 몰랐다.

검증사항을 빠뜨리는 일도 잦았다.

하지만, 곧 익숙해졌다.

시간이 지나니 팀원들은 노련해지고, 서로 배려하기 시작했다.

 

 

Yellow Zone

휴가를 보낼 수 있게 되었다.

휴가를 보냈다.

 

하지만 새로운 문제가 등장했다.

코드에 대한 책임감에서 자유로워지자 회사를 그만두고 싶어했다.

이런 착한 것들.

다들 자기 빠지면 서버 안돌아갈까봐 그동안 그만두질 못했던거다.

하지만, 자꾸 그만두는 분위기면 곤란한데.

 

깊은 면담을 했다.

고민이 이해가 되었다.

다른 곳으로 가게 해주는 것이 맞았다.

그 사실을 팀원들에게도 공유를 했다.

서로 공감했다.

 

떠나고 싶은 사람은 떠날 수 있게 해주었다.

다만 미리 말해주도록 부탁을 했다.

조용히 귀뜀만 받았다.

 

떠나는 사람도 남겨지는 사람도 어색하지 않게 해주었다.

조직이 못채워주는 건 어쩔 수 없다.

내 책임도 아니고, 팀원의 책임도 아니다.

회사가 더 성장해야만 가능한 거다.

하루 아침에 되는 일이 아니다.

 

예쁘게 떠날 수 있게 되니, 조직은 더 안정화되었다.

언젠가 떠나기 위해 더 열심히 진화에 동참했다.

예쁘게 떠나기 위해 서로 더 노력했다.

 

팀을 새로 채워야 했다.

다소 어린 친구들로 채웠다.

대용량 데이터를 다뤄본다는 것,

24시간 가동중인 시스템을 만져본다는 것,

msec 단위로 돈버는 시스템을 만져본다는 것.

그런게 그들의 동기가 되었다.

적절한 발전욕구도 충족시켜줬다.

 

레거시 코드는 필요할 때마다 뜯어고쳤다.

과도하게 집착하진 않았다.

삶을 해치는 순간 팀이 망가지기 때문이다.

 

운영개발은 계속해서 레거시 코드를 덧칠하는 일이다.

결코 깨끗해질 수 없는 상태다.

클린에 대한 과도한 욕구를 떨쳐낼 필요가 있었다.

 

 

Green Zone

데이터가 제대로 보이자, "검증필요성"이 생겼다.

데이터를 보면서, "로직 허점"을 짚어내기 시작했다.

생각보다 "서버 아키텍쳐" 문제도 컸다.

천천히 바꾸어 나갔지만, 바꿀 수 없는 부분도 있었다.

레거시니까.

하지만, 이유없는 "장애현상"은 확실히 줄었다.

 

검증문제를 해결하고 나니 여유가 생겼다.

사업에 관계된 기능과 데이터를 들여다볼 여유도 생겼다.

데이터에서 예측은 매출과 직결된다.

 

예측은 사업을 잘 이해해야만 한다.

사업팀과 많은 대화를 나누었다.

우리에겐 충분히 좋은 데이터가 있지만 사업팀은 알지 못했다.

 

Terra 급의 데이터를 가공한다고 해서 훌륭한 일이 되진 않는다.

훌륭한 듯 보이는 일도 사업세계에서는 무의미했다.

잘 이해하긴 힘들었지만 어쨌든 대화를 했다.

 

서툴렀다.

업무의 "적정수준" 맞추기.

그게 힘들었다.

최선을 다하는 것, 최고를 뽑는 건 오히려 쉬웠다.

하지만, 현장에선 번아웃되기 십상이다.

"그만두고 싶습니다."

팀원으로부터 이 말을 듣는 것만큼 현타가 오는 건 없다.

 

어깨에 힘을 뺐다.

과도한 분석과 통계기법을 빼고,

평균치 예외치만 따로 보았다.

 

대신 이야기를 많이 나누었다.

사업에 필요한 데이터가 어떤건지 이해하기 시작했다.

"데이터보고서"가 달라졌다.

보고서가 달라지자 사업팀이 관심을 보이기 시작했다.

 

사업팀은 많은 걸 물었고, 많은 교훈을 얻어갔다.

고민을 통해 사업에 반영하기 시작했고,

직접적인 매출향상으로 이어졌다.

 

물론 혁신적인 변화가 일어나진 않았다.

운영개발은 홈런치는 게임이 아니다.

안타를 꾸준히 뽑아내는 게임이다.

긍정효과는 분명했다.

기여가 분명해지자 개발팀의 자존감도 올라가기 시작했다.

 

 

Blue Zone

일을 수습만 하다가 능동적으로 해결하게 된 것.

"지나간 일 쫒아가기"에서 "앞으로의 일 미리하기"가 된 것.

팀원들이 시간을 대하는 마음가짐이 달라졌다.

조직이 안정되고, 팀의 효율이 올라갔다.

 

운영업무 외의 새로운 업무에도 시간을 쓸 수 있었다.

바로 우리들만의 프로젝트였다.

 

하지만, 거기서부턴 잘되지 않았다.

새로운 서비스를 만드는 건

레거시와 싸우는 것과 달랐다.

 

가벼운 일을 너무 진지하게 상대했다.

속도도 느리고, 발걸음이 무거웠다.

하지만, 업무습관을 바꾸라고 요청할 순 없었다.

 

결국 잘 되진 못했다.

하지만 잘 안되어도 좋았다.

새로운 기술에 대한 갈증은 어느정도 풀렸다.

 

 

Retro

1년이 지났다.

스스로 평가해 보았다.

100 점짜리가 되었을까?

그렇게 되진 못한 것 같았다.

하지만, 70점은 되지 않았을까?

팀원들 서로 격려하고 좋은 관계가 되었다.

Before 가 -100 점이었기 때문이다.

 

채워지지 못한 30점에 대한 갈증은 있었다.

잘 따라와준 팀원들을

부자되게 만들어주고 싶었기 때문이다.

그러려면 "주식"을 나눠줘야 한다.

 

세상에 없던 걸 만들어야 했다.

하지만, 운영개발에 길들여진 친구들은 적응하지 못했다.

숙제로 남았다.

 

 

Base

사람에 대한, 팀에 대한 믿음이 제일 중요했다.

 

우리나라 대학교육 우수하다.

하다보면 적응하고 진화한다.

신입사원도 바보가 아니다.

30살 아저씨를 20살짜리로 대하면 20살짜리 성과만 나온다.

 

서투르지만, 없는 것보다 낫다.

서투른채로 시작해서, 하면서 나아지는거다.

완벽해야만 문제를 풀 수 있는 게 아니다.

손을 댄 만큼 문제가 풀리는 거다.

 

모두 맡은 자리에서 최선을 다하고 있다.

부정에너지가 넘치는 건 아무도 일을 안해서 그런거다.

일이 언제 끝날지 모르면, 출구 없는 감옥이다.

나라도 "흑화"할거다.

 

"상벌"은 어줍잖아도 꼭 했다.

모자란 것도 없는 것보단 낫다.

꼭 돈만 상이 아니다.

칭찬도 상이 될 수 있다.

베풀 게 없으면 말이라도 좋게 하는거다.

 

 

Error

항상 좋은 사람만 팀원이 되지는 않았다.

이상한 사람도 많았다.

내 책임이었다.

고민이 많았다.

힘들었다.

여기선 적지 않겠다.

 

 

Replication

이 성공경험을 복제할 수 있을까?

몇번 복제를 했다.

불난 프로젝트 많이 껐다.

물론 안되는 경우도 있었다.

언제나 사람이 문제였다.

코드는 내가 고치면 되었다.

사람 나쁜 건 답이 없었다.

 

 

Add.

이거 하고 나서 몸이 많이 상했다.

건강을 불살라서 한다는 마음으로 했다.

다시 돌아간다면 아마 하지 않을 것 같다.

 

누군가의 희생으로 채워지는 완벽함이란,

복제 및 재현이 가능하지 않다.

즉, 확장가능한 조직모델이 아니기 때문에

지속가능하지 않다.

 

더 많은 배움이 있었는데,

이야기가 길어지니

여기선 스킵한다.

 

FIN.