첫 시작부터 회사 시스템에 대해 많은 실망도 했고 연봉 외에는 제가 처음 추구했던 가치들에 대해 모두 충족시키지 못한다는 것을 깨닿기는 했었죠. 하지만 지난 한달여의 시간동안 많은 것들을 내려놓기도 했고 새로운 저만의 계획을 짜는 시간을 가졌습니다.
이직을 하자마자 첫 일주일이 지나기 전부터 주어졌던 pilot 프로젝트가 결과 발표 후 별 소식이 없어 그냥 흐지부지 된 것으로 생각하고 넘어갔지만, 8월 말에 3개의 pilot중 하나가 최종 선정이 되어 곧 계약될테니 9월 말까지 전 제품의 static analysis를 이 서비스로 migration 하라는 오더가 나왔죠.
그렇게 옮겨야 할 파이프라인은 총 348개. 거기에 이번에는 아직 static analysis를 돌리지 않고있는 제품들까지 다 스캐닝을 해야 한다는 조건까지 붙었는데, 그 수는 예상조차 할 수 없었죠. 추가로 현 파이프라인들이 젠킨스나 드론CI에서 도는데 이를 깃헙 액션으로 단일화하라고도 했죠. 신규 CI는 깃헙 액션으로 가는게 현재 방향성이라면서요...
언제 계약이 이뤄질지는 알 수 없었지만 일주일 이내에 계약이 되고 라이센스 키를 받는다 하여도 4주의 시간만 있었습니다.
총 20근무일에 348개의 파이프라인을 새로 만든다면 하루에 17-18개씩 해 내야하니 파이프라인 당 25분 정도의 시간만 있군요.
또, 보안 문제로 깃헙 액션은 self-hosted runners에서만 돌려야하는데, 이 시스템을 살펴보니 스케일링이 충분치 않은 상황이였습니다.
말도안되는 일정으로 밀어붙이는 것은 일단 잊고, 제 본업으로 돌아와 최대한 자동화를 시키고 각 사용자들이 self service를 할 수 있도록 하기위해 고민에 들어갔습니다.
일단 당장 스케일링과 자동화가 어려운 mac과 windows 빌드 러너는 제외시키고 리눅스 빌드에 좀 더 촛점을 맞추었고, 모든 full기능 구현이 아닌 기존 security static analysis의 요구조건에만 딱 맞도록 자동화 툴을 설계 배포할 경우 업무 범위와 일의 양을 측정 해 보니, 각 사용자들에게 3주 조금 안되는 시간을 주고 self service로 migration을 할 수 있게 드라이브 가능할 것 같았죠.
다음 날 제가 추산한 일정과 기간, 계획을 알려주고 일을 진행하려는데, 이 일을 담당하는 매니져가 제 계획에 대해 아키텍트 리뷰를 받으라고 합니다. 이 때만 해도 아무 생각없이 아키텍트에게 제 자료들을 건네주며 리뷰를 요청했는데 뭔 x 소리가 들려옵니다.
본 migration을 위한 자동화 툴을 자기가 만든 툴 내에 포함시키라는 피드백을 먼저 받았죠. 일단 제겐 생소한 golang이였지만, 기존에도 저는 가능한 CI/CD관련한 CLI툴은 각 기능별로 모듈화 시키되 원하면 단 하나의 툴이 모든 모듈의 umbrella가 되어 모든 기능이 같이 동작하는 것을 선호했기에 okay했죠.
그런데 이놈의 툴이 담긴 리포지토리의 리드미에는 아무런 문서도 없습니다.
사용자를 위한 툴 사용법도 없고, contributors 를 위한 설계나 개발 관련 문서도 없으며 그냥 자기가 이 툴로 무엇을 이루고싶은지 적은 philosophy에 대한 내용만 장문의 텍스트로 적혀 있었죠.
WTF...
아키택트에게 모듈 추가를 위해 문서 업데잇을 부탁하니 자긴 바빠서 그럴 시간 없고 저보고 작업하며 하나씩 추가 하라고 하네요.
결국 한 시간 가량 1:1 논쟁을 벌였습니다.
저도 4주가 안되는 기간 내에 ASAP로 개발팀에 툴을 공급하고 그들을 교육시켜야하여 시간이 불충분하니 서로 분리를 시키거나 합병을 위해서는 제 시간 세이브가 가능하도록 읽기 쉬운 최소한의 설계 문서라도 필요하다고 말을 했죠. 하지만 아키텍트는 인간계가 아닌 신계에서 신선놀음을 하는지, 한 달 동안 모든 제품을 migration 하는 것은 말도안되는 일정이라며 일정을 다시 짜라고 합니다. 라이센스 만료와 지시사항 등등 이야기를 해도 신선은 그냥 신선계에서 이상향 이야기만 계속 해댔죠.
결국 매니져의 중재로 제가 좀 더 빨리 개발을 해보고, 사용자들의 migration기간을 1.5-2주 정도로 줄여 이상향에 맞게 진행하도록 합의???가 되었습니다.
그렇게 툴 개발이 거의 완료되고 배포 전 사용가이드 작성과 edge case들에 대한 테스트를 하고 있는데, 아키텍트가 사용가이드에 다시 테클을 겁니다.
이번에는 해당 툴에서 static analysis를 자동 생성하는 별도의 커맨드가 있다는 것에 크게 반대를 하네요.
자기가 제 툴을 자기 툴 내에 구현하도록 한 이유는 회사에서 강제하는 이번 migration을 통해 도입률이 거의 0%에 가까운 자기 툴의 도입률을 100%로 끌어올리기 위함이였다며 이럴꺼면 처음부터 제 툴을 자기 툴 내에 추가하라고 하지 않았을꺼라 합니다.
오케이...
별도 커맨드를 없애고 단일 커맨드로 모든 기능을 도입하도록 바꾸는 것 자체는 10분도 걸리지 않을 일이죠.
그런데, 지난 아규에서 2주 가까이 지난 지금까지 그 툴의 리포에는 아무런 문서 추가가 없네요???
저도 제 툴을 추가하긴 했지만, 기존 툴에서 어떤 기능들을 수행하는지는 다 알지 못합니다. 다만 기능 수행 시 타깃 리포지토리에 40-50여개의 신규 파일을 생성하고, 15개의 깃훅을 추가시키는 정도만 알죠.
제 문제는 개발기간의 문제가 아니라 348개의 제품 팀들에게 2주라는 시간 동안 이 툴이 무엇이며 이 툴이 너희 제품에 어떠한 변화를 가져다줄지 충분히 설명시키고, 그들이 이 툴을 통해 원클릭으로 CI를 생성시키고 한 번의 PR로 모든 것을 쉽게 완료시키는 것입니다. 그런데 저도 모르는 수십여개의 새로운 기능들과 파일들이 생성되고 이것들으 어떠한 변화를 불러올지 (이 아키텍트를 제외하곤) 아무도 모르는 상황에서 어떤 오너들이 self service로 migration을 하겠습니까?
결국 이 시점이 되어 다시 한 시간이 넘는 아규가 펼쳐졌습니다.
저는 그에게 사용자 입장에서 문서를 작성하여 어떤 것들이 추가/변경되고 이것들이 그들의 개발 프로세스와 툴들에 어떠한 영향을 주는지 알려주기라도 하라고 말했지만 그의 대답은 동일했습니다.
"이 리포에는 문서가 너무 안되어있어서 그 모든 것들을 추가하기엔 난 너무 바쁘다. 내 생각엔 우리의 개발 프로세스 표준화와 자동화를 위해 다 필요한 것들인데, 그냥 쓰라고 해라."
제가 사용자 입장에서 생각해도 수십개의 모르는 파일들이 생기고, 갑자기 커밋을 생성하거나 커밋 푸쉬를 하려면 깃훅이 에러를 내는데, 아무런 설명없이 그냥 하라고 지시하면 무조건 반감이 들 것이 확실했죠.
결국 또 다시 한참동안 논쟁을 한 뒤에 2-3일간 몇몇 가장 협조적인 팀들에만 먼저 툴을 배포하고 피드백을 받아 다시 의사결정을 하기로 했습니다.
그리고 결과는... 당연히 이번 파일럿에 차가한 6명의 개발자들 중 5명은 극렬한 부정적 피드백을 주었고, 단 한명만 하나씩 뜯어보면 괜찮은것 같긴 한데, 너무 많은 파일들을 생성해내니 overwhelmed 된다는 피드백을 주었습니다.
피드백을 모아 아키텍트에게 주고 제 기능만 따로 뺀 별도의 커맨드를 유지하겠다고 하는데 여전히 아키텍트는 고집불통입니다. 허들을 낮출 방법을 생각하여 적용하라고 했죠.
결국 어쩔 수 없이 디렉터에게까지 이런 말도안되는 시시콜콜한 이야기를 하고 이것이 현재 가장 큰 걸림돌이라는 이야기를 준 뒤에야 겨우겨우 타협점을 찾을 수 있었습니다.
그런데 그 타협점도 결국 디렉터나 제가 원한 방향은 아니였죠. 해당 툴에 minimum 인스톨 옵션을 주고 현재는 static analysis CI만 generate 및 auto uploaded 되게 하고, 추후에 아키텍트가 원하는 바에 따라 minimum에 포함되는 리스트를 수정하면 모든 리포에 아키텍트가 원하는 툴들이 자동 설치되도록 만드는 것이였네요.
디렉터가 직접 개입을 했음에도 고집을 부리는 아키특트에 대해 또 디렉터에게 SOS를 칠 수도 없는 노릇이라 일단 저도 양보하고 그렇게 툴 수정을 했습니다.
이렇게 정규 8시간 근무로 1주 -1.5주에 마무리 될 예정이였던 툴 개발, 가이드 문서/비디오 제작은 2주간 제 체력이 허락되는 한에서 풀타임 근무를 하면서 마쳤죠.
이 때만 해도 저는 가장 높은 산을 넘은 것이라 생각했습니다.
처음 계획 당시에 사용자들이 self service로 migration하는 것이 이번 프로젝트의 키라고 했지만, 아키텍트의 똥고집을 마주한 후, 이 산이 더 높은 산이라 생각했죠. 하지만, 제 처음 생각이 옳았습니다. 아키텍트의 똥고집은 그냥 애교였죠.
한국에서 다녔던 삼성 이후로 제가 캐나다에서 다닌 직장들은 그 규모가 비슷했습니다. 입사 할 때엔 100-150명 정도의 엔지니어가 있었고, 톼직 할 때엔 300-400명 정도였죠. 이 회사는 입사 할 때에 이미 엔지니어 팀 규모가 1000명을 넘었습니다. 이전 직장과 달리 QA 엔지니어도 있고 (이전 직장은 100%자동화 테스트를 통한 full CD환경이였습니다) 네트워크 엔지니어와 다수의 보안 엔지니어들이 있기는 해도 이전대비 배 이상의 엔지니어입니다. 똘아이 질량 보존의 법칙에 따라 당연히 똘아이들도 두 배 이상 많겠지만, 회사가 잘 굴러가도록 해 주는 핵심적인 인물 (협조적이고 능동적인) 한 두 명은 각 팀마다 있을 터이니, 결국 제 이전 경험과 비슷하게 잘 굴러갈 것이라고 예상했죠.
하지만 2주간 수많은 팀들과 1:n으로, 또 1:1로 접촉해 본 결과... 이 회사에는 팀 당 한 두명 의 협조적이고 능동적인 인물들이 매우 희귀했습니다.
일단, 대다수의 팀들은 매우 수동적이며 방관자적 자세만 보였죠.
본격 self migration을 앞두고 해당 프로젝트의 매니져가 모든 팀의 매니져들과 리드들에게 메일을 보냈습니다. (이것도 사실 불만인게 각 팀에 리소스 할당이 필요하니 미리 사전 예고를 부탁했는데, 제 툴과 가이드 문서가 완료되니 그제서야 보내더군요 ㅠㅠ)
그리고 전 2주 self migration 기간동안 매일 아침 저녁 각 1시간씩 줌 미팅을 열고 face to face 사용자 지원을 하기로 했죠.
그렇게 본격적인 migration이 시작되고 사흘째, 전 이 회사 엔지니어들의 전반적인 성향을 알게 되었습니다. 지난 이틀과 당일 아침까지 아무도 접속을 안했습니다.
결국 매니져와 디렉터에게 좀 더 적극적인 참여가 필요하다고 어필하며 커뮤니케이션 강화를 이야기하자 결국 VP를 통해 각 팀 VP들에게 연락이 갔죠.
그렇게 사흘 째 저녁 face to face office hours 가 시작되었습니다.
이번에는 10여명의 엔지니어들이 참여했는데, 하나같이 아무런 사전 정보와 지식이 없었습니다.
모두들 묻는 질문이...
매니져가 이 미팅에 참석하라고 했는데 이거 뭔 미팅이니?
Static analysis 프레임웍을 바꾼다고? 그럼 바꾸면 되는데 난 왜 불렀어? 난 툴 잘 몰라
바꾸는거 내가 해야한다고? 왜? 난 그럼 static analysis 안할래. 아니면 난 그냥 기존 툴 쓸께. 기존 툴에 난 불만도 없어. 솔직히 그런 security scanning 있는줄도 몰랐다.
하...
그렇게 한차례 폭풍이 지나가고 나흘째, 이제는 능동적이되 비협조적인 인물들과 협조적이되 능동적이지 못한 인물들이 접속을 시작합니다.
누가 이 스캐닝 서비스 골랐냐? 왜 스캔 설정이 이따구냐? (응 위키 안읽었지? 자동화툴은 기본 설정으로 생성되고 이후 사용자 customization 가능함)
기본 설정이 왜 이따구냐? 나 golang 1.19쓰는데 왜 1.18을 CI러너에서 돌려? (응 위키 안읽었구나, 프로젝트 자동생성 yaml에서 네가 다른 프로젝트 그냥 복붙 했지? 네 프로젝트 설정에 1.18로 되어있네?)
난 unit test 있는데 왜 커버리지가 0%라고 나오냐? 버그냐? 툴 바꿔라 (응 또 위키 안읽었구나, 자동생성 ci에선 커버리지 리포팅 안해. Custom step으로 유닛테스트 돌리고 커버리지 리포팅 추가하면 됨)
왜 커버리지 자동화툴에서 지원 안해주냐? 귀찮다 해줘라! (응 프로젝트마다 빌드 스탭 다 달라서 build orchestration 툴 통합해서 다 쓰고 다 같은 커맨드로 빌드, 테스트, 클린 등등 되게 하자고 했을땐 바빠서 다들 싫다했지? 그게 없어서 못해. 툴이 사람도 아니고 각 프로젝트마다 다 다른 테스트 돌리는 커맨드를 어찌알고 알아서 다 하니?) 그러면 네가 해줘라. (응, 난 348개를 완료할 책임이 있고, 넌 3개를 완료햐야지? 누가 더 바쁠까? 그리고 우리 현재 목표는 테스트 커버리지가 아님. Security scanning 이지. 다 위키에 있음)
난 이 툴 싫어. 그냥 싫어. 난 안해 (회사 방침이고, 정부 프로젝트 요구사항에 필요함. 하셈) 그럼 난 다른툴로 스캐닝 돌려줘. 내가 툴 고를께 (응 니가 골라서 니가 스캐닝 돌려) 시러 난 안해. 바빠. 니가 해줘 내가 툴 고를께 (근데 너님 그 툴 라이센스는 있니?) 없어, 그러니 니가 라이센스도 해줘 (??? 그 툴 라이센스만 니가 니 매니져한테 말하고 알아서 받아와 그 툴 돌린거 현 스캐닝 프레임웍에 통합 가능함. 그건 가능하게 도와줄게) 아씨, 난 그거 싫다니까. 난 완전 따로 돌릴꺼야. (따로 돌리는건 좋다 쳐도, 보안팀에서 통합 데쉬보드를 원하더라. 이툴에 같이 리포팅 안하면 데쉬보드가 없어) 아, 그럼 보안팀에 해달라고 해야겠다 지들이 필요한거면 지들이 하지 왜 나보고 하라고그래. 빠이 (????)
결국 제 9월은 이렇게 흘러갔습니다.
매일 7시에 일어나 7시 반이면 인도 팀들을 위해 한시간 줌 미팅을 하고, 오후 5시에는 미국 팀들을 위해 줌 미팅을 하고, 나머지 시간들에는 각팀 공격수들의 공격을 다 몸빵으로 막고, 6시 이후이는 우리팀 아키텍트의 공격을 막으며... 한달간 4시간 이상 잔 날이 매우 드문것 같네요.
한 달이라는 빡빡한 데드라인을 밀어넣는 매니져들도 신기하고, 전에 본 적 없는 진귀한 팀웍을 보여주는 각 팀들도 그렇고... 정말 일 하기 힘든 조직인것 같아요.
그래도 이렇게 한 달을 버텨낸 이후 나름의 계획도 생겼습니다.
그간은 승진하는 것을 상당히 꺼려왔는데, 여기에서는 제가 승진을 해도 하나 이상할 것 없고, 안하면 오히려 손해보는 장사가 될 것 같아요. 어쩌면 승진 안하고 하루하루 버텨나가다는 이들과 같은 그런 수동적인 사람이 될 것도 같고요.
그래서 커리어를 시작하고 처음으로 승진이라는 것을 제 개인 목표에 넣어보기로 했습니다.
제가 생각하는 엔지니어다운 마인드셋을 지닌 엔지니어로 남기위해, 제 하루하루 상활에 조금이나마 목표와 의미를 심어주기위해 이 회사에선 승진이라는 것을 좀 해봐야 할 것 같네요.
8월 마지막 주를 시작으류 하여 지난 한달 반 가량을 참 바쁘게 살아왔는데, 부디 잠시만이라도 한 숨을 돌릴 여유를 갖고 다른 일에 들어가길 바랍니다. 제발...
IT시장 버블이 아직까지 휴효하기만 했어도 정말... ㅠㅠ
