[조직 문화] 조직 바꾸기 실패/성공 사례 모음
<구글 엔지니어는 이렇게 일한다> A/S
★ 저는 주니어 시절 한창 의욕이 넘처서 거대한 조직을 바꿔보겠다며 좌충우돌하였습니다. 그 과정에서 작게 성공한 경험도 있고 실패한 경험도 많은데, 그중 일부를 정리했습니다. 그 시절의 나를 만날 수 있다면 해주고 싶은 이야기가 많은데, 그 시절의 내가 과연 이해하고 받아들일지는 자신이 없네요. ;-)
분산 빌드
신입 사원 시절, 저는 품질보증(QA)팀 소속으로 개발팀을 지원하는 일을 했습니다. 이번 사례의 대상 개발팀은 C/C++를 이용했고, 프로젝트 덩치가 꽤나 커서 클린 빌드가 40분 이상 걸렸습니다. 이 일을 수십 명의 개발자가 거의 매일 수행했습니다. 저도 검증을 위해 수시로 해야만 했고요.
당시 제 주력 언어는 자바였는데, 자바에서는 증분 빌드가 널리 쓰여서 파일 저장과 거의 동시에 빌드가 완료되었습니다. 그런 저에게 40여 분의 빌드는 난처하고 답답한 경험이었습니다. 그래서 C++용 분산 빌드 솔루션을 찾아 선임을 통해 개발팀에 이야기를 전달했습니다.
처음에는 별다른 반향이 없었습니다. 그래서 우선 QA팀 사람들 컴퓨터에 에이전트를 깔고 자체적으로 평가 데이터를 뽑아냈습니다. 컴퓨터 몇 대만 연동시켰을 뿐임에도 빌드 시간이 7분 정도로 크게 줄었죠. 이렇게 얻은 데이터를 정리해 전달하니 개발팀도 적극적으로 움직이기 시작했습니다.
솔직히 이 부분은 기억이 살짝 희미한데, 초기에 툴을 소개한 후로 개발팀에서도 일부 개발자들이 자체 테스트를 진행했다는 것도 같습니다. 저는 신입이었고, 개발팀과의 소통은 선임이 하셨기 때문에.. ^^
어쨌든 수십 명이 하루 30분씩만 절약한다고 해도, 툴 하나가 엔지니어 몇 명치의 일을 해주는 효과가 생깁니다. 효과가 확실하게 눈에 보였기에 개발팀을 움직이는 건 어렵지 않았습니다.
의외의 복병은 재무팀 설득이었습니다. 비싼 툴도 아니었는데, ‘툴 사주면 얼마나 일찍 퇴근할 수 있느냐?’부터 해서 이상한 데이터를 자꾸 요구해서 전면적인 도입에 몇 개월이 걸렸던 것으로 기억합니다.
→ 기존 워크플로와 매끄럽게 통합되면서 효과가 확실하면 변화시키기가 상대적으로 수월합니다. 단, 현재 프로젝트를 대상으로 직접 시험하여 데이터로 입증하는 수고는 필요할 것입니다.
애자일 문화
품질보증에서 개발팀으로 옮긴 후의 이야기입니다. 제가 속한 조직은 전통적인 폭포수 모델에 이터레이션을 섞은, 통합 프로세스(Unified Process) 느낌을 개발 모델을 따랐습니다. 프로세스 자체는 나쁘지 않았다고 생각했는데 운영 면에서는 미흡한 점이 꽤 되었습니다. 특히 팀원 수십 명에 개발 브랜치도 많았고, 통합은 몇 개월에 한 번씩 이루어졌습니다.
장기간 따로 개발되던 브랜치들이 쉽게 통합될 리 없어서, 통합 때마다 며칠은 기본이고, 길게는 몇 주가 지연되기도 했습니다. 그 여파로 고급 개발자인 중간 관리자들이 일정 재조정에 대부분의 시간을 쏟는 느낌이 들 정도였죠.
저는 지속적 통합(CI)과 애자일 이야기를 많이 했고, 따로 그룹을 조직해 관심 있는 동료들과 스터디도 많이 했습니다. 하지만 사원~선임(대리) 시절이어서 발언의 힘도 약했고 권한도 없었습니다. 스터디 참가자들도 대체로 고만고만한 사정이었고요.
당시는 ‘통합 = 야근 + 지연’이었기에, 통합을 더 자주 한다는 아이디어가 쉽게 먹히지 않았고, 애자일도 큰 프로젝트에 적용하기는 어렵다는 견해가 지배적이었습니다.
다른 조직에서는 일부 애자일을 적용하기도 했지만, 우선 리더가 애자일에 관심이 많았고 크리티컬 하지 않은 작은 프로젝트라는 게 공통점이었습니다.
훗날 저 역시 메인 프로젝트와는 별개인 작은 프로젝트를 리드할 기회가 생겼는데, 이때서야 애자일을 실무 프로젝트에 적용할 수 있었습니다. 지역적으로 개발팀이 인도, 미국, 한국에 흩어져 있는 프로젝트라서 나름대로는 의미도 있고 성공적이었습니다만, 소임을 마치면 사라질 운명의 프로젝트였던지라..
→ 하루하루 정신없이 굴러가는 큰 조직에서 개발 방법론 같이 큰 변화를 상향식으로 이끌기는 정말 어려운 것 같습니다. 하지만 혼자라도 끈을 놓지 않고 정진하다 보면 기회가 왔을 때 작게나마 실천해볼 수 있습니다. 또한 큰 조직도 세월이 흐르다 보면 인력이 교체되고, 인프라가 발전하고, 주변 세상의 트렌드가 바뀌면서 서서히 변화가 일어납니다. 내가 준비되어 있다면 그 과정에서 중요한 역할을 맡을 기회를 거머쥘 수 있을 겁니다.
지속적 통합
앞의 예에서 이어집니다. 조직은 더 커졌고, 통합의 고통은 그보다 훨씬 더 커지며 몇 년이 흐릅니다. 새로운 인력이 계속 충원되었는데, 마침 다른 조직에서 지속적 통합(CI)을 도입해본 사람이 합류했습니다. 저는 이때다 싶어서 영향력 있는 중간 관리자와 새로 오신 분께 바람을 불어넣었습니다. CI 때문에 충원된 분은 아니었지만, 그 후 몇 개월에 걸쳐 그분이 주도하여 CI가 조직에 뿌리내렸습니다.
이 과정에서 제 역할이 얼마나 있었는지는 미지수입니다. 통합에 따른 고통은 나날이 커졌고, CI를 도입하는 회사가 점점 늘어나고 있었습니다. 우리 조직 리더들도 귀를 닫고 사시지는 않았으니, 제가 없었더라도 결과는 같았을지 모릅니다.
그럼에도 저는 어떤 변화가 절실한지 관심을 기울였고, 변화시킬 기회가 왔을 때 그 시발점이었을지 모르는 한 마디를 보탰다는 데서 뿌듯함을 느낍니다.
→ 어떤 변화가 필요한지 평소 관심을 기울이고, 변화할 수 있는 기회가 오면 힘을 보태주세요. 때론 작은 응원 한 마디가 큰 변화의 원동력이 됩니다.
ALM 도구
애플리케이션 생애주기 관리(Application Lifecycle Management) 도구는 요구사항 → 설계 → 개발 → 릴리스에 이르는 개발 전 과정에서 태스크 관리, 코드 작성, 버전 관리, 이슈 추적, 빌드, 지속적 통합 등 모든 일을 통합 관리해주는 도구를 말합니다.
대부분의 조직에서는 각 단계에 특화된 도구를 개별적으로 사용합니다. 코딩에는 인텔리J, 버전 관리에는 Git, 태스크 관리에는 컨플루언스, CI에는 젠킨스 등등.. 하지만 ALM 도구는 이 모두를 단 하나에서 처리해줍니다.
ALM 도구를 사용하면 프로세스와 도구에 대해 배워야 할 지식의 ‘총량’이 획기적으로 줄어듭니다. 단계별 도구들을 따로 설정할 필요도 없고, UI도 일관되고, 모든 정보가 중앙 DB에 저장되어 있으니 툴에서 자동으로 처리해줄 수 있는 일이 많습니다. 그래서 저는 개발자들이 환영하고 빠르게 수용할 거라 기대했습니다.
큰 착각이었죠. ^^
도입을 위해 한참을 씨름했지만 잘 정착되지 못했는데, 나중에 돌아보며 너무 무리하게 추진했다고 결론지었습니다.
첫째, 전체를 보면 배울 게 적다지만, 그 모든 걸 한꺼번에 배워야 함을 간과했습니다. 난이도 1짜리 도구 10개를 주면 필요한 순으로 하나씩 배워 언젠가는 모두를 숙달할 수 있습니다. 하지만 처음부터 난이도 7짜리 도구를 던져주면 대부분은 기겁할 테지요.
둘째, 자유도가 너무 떨어집니다. 각 단계에는 수많은 경쟁 도구가 있고 나름의 특색과 장점이 있습니다. 사람에 따라 선호하는 게 다르고요. 이런 걸 무시하고 통합해버리니, 적어도 몇 개 단계에서는 내 취향이나 개발 방식과 맞지 않을 확률이 높습니다. 어쩌면 모두에게 불만족인 툴이었겠다는 생각도 듭니다.
그 외, 툴이 무겁다 등등 여러 문제가 있었습니다.
→ 만능인 하나의 도구는 없고, 너무 큰 변화를 한꺼번에 시도하면 성공하기 어렵습니다. 작게 하나씩.. 변화에 동참해야 할 사람들의 여건과 학습 난이도까지 고려하여 체계적으로 접근해야 성공 가능성이 높습니다.
공유 문화
거창한 이야기는 아닙니다. 저는 어려서부터 제가 배운 것을 정리하고 공유했습니다. 특별한 목적이나 계기가 있던 건 아니고, 자연스럽게 그렇게 살아왔습니다.
대학생 때는 학교 과제를 홈페이지에 공개했고, 개발자 시절에는 기술과 개발 문화 관련 블로그를 운영했고, 편집자가 되어서는 글쓰기나 번역 노하우 등을 정리해 공개했습니다. 조직 내에서도 마찬가지였습니다. 멋진 자료를 발견하면 관련된 사람들에게, 때론 조직 전체에 메일을 뿌리곤 했죠. 스팸이 되지 않도록 정말 쓸만한 정보만 가끔씩.. 그리고 뜻이 맞는 사람들을 모아 스터디도 종종 했고요.
안타깝게도 당시의 제게는 조직에 공유 문화를 만들어야 한다는 개념 자체가 없었습니다. 그러니 모든 활동이 단발성으로 끝나버린 건 당연한 결말이었습니다. 하지만 폐쇄적이었던 조직에서도 한 명 두 명 동참하기 시작하였고, 질 좋은 정보를 공유하는 게 뜬금없고 튀는 행동이 아닌 분위기로 바뀐 건 분명히 느껴졌습니다. 일면식 없는 사람에게 고맙다는 답신도 받아보고, 제가 정리한 자료를 다른 곳에 활용해도 되겠냐는 문의도 받았습니다. 콘퍼런스에 참석했다가 저를 알아보고 한 번 만나보고 싶었다는 분도 뵌 적 있고요.
하지만 돌이켜보면 더 제대로 해봤으면 어땠을까 후회도 됩니다. 거대한 조직에서 일개 팀원이 어디까지 할 수 있었을지는 모르겠지만 시도하고 실패하는 과정에서도 배우는 게 적진 않았겠지요. 운 좋게 뜻이 맞는 동료를 찾게 되면 실제로 무언가를 이루어냈을 수도 있었을 테고요.
→ 직접적인 대가가 없더라도 누군가에게 기여해보는 일도 좋은 경험이 될 겁니다. 삭막한 조직에 작게나마 활기를 줄 수도 있고, 뜻을 함께 하는 멋진 동료를 만날 수도 있습니다. 물론 아무런 반향이 없을 때도 많습니다. 하지만 공유하기 위해 내 생각과 지식을 정리하는 과정에서 적어도 나 자신은 조금 더 성숙해질 것입니다.
조직을 바꾸려면..
제가 번역한 <구글 엔지니어는 이렇게 일한다>는 저자가 무려 26명입니다. 기여자의 수는 그 몇 배에 달합니다. 여기에는 무슨 의미가 숨어 있을까요?
지금의 구글이 있기까지, 20년 이상 세계 톱 경쟁력을 유지하도록 끊임없이 변화/발전시킨 것은 특출난 영웅 몇 명이 아니었다는 이야기입니다. 수많은 사람이 각자의 영역에서 한 걸음씩 앞으로 나아갔고, 그 노력들이 모이고 융합되어 지금의 모습이 되었습니다.
우리도 조직이 마음처럼 빠르게 변하지 않는다고 해서, 동료들이 잘 따라와 주지 않는다고 해서 쉽게 좌절해서는 안 될 것입니다. 지금도 내가 모르는 곳에서 누군가는 작은 변화를 일으키고 있을 게 분명합니다. 여러분도 여러분의 자리에서 할 수 있는 일들을 꾸준히 해나가다 보면 언젠가 그 사람들과 만나는 날이 올 것입니다. 그날이 오면 함께 옛날을 추억해보세요. 조직은 어느새 내가 바랐던 모습에 성큼 다가서 있음을 깨달을 겁니다.
제가 주니어이던 시절, 갑갑해하는 저에게 “나도 너와 같았다. 하지만 8년쯤 지나 되돌아보니 어느새 많은 것이 과거의 내가 바랐던 모습으로 변해 있더라”라고 말씀해주신 분이 계셨습니다. 물론 당시의 저에겐 와닿지 않는 말이었죠. 하지만 살아보니 인생에서 8년은 그리 길지 않았습니다. 그리고 정말 8년 가까이 흐른 후 돌아보니 꿈쩍도 않는 듯 보이던 거대한 조직이 몰라보게 달라져 있었습니다. 내가 모르는 수많은 분들이 어디서엔가 작은 변화의 돌들을 쌓고 계셨던 것이죠. 그러니 (너무 힘들면 잠시 쉬시더라도) 절대 포기하지 마시고, 모두 파이팅하십시다!
마지막으로 제가 2014년에 정리해둔 글과 2022년에 새로 정리한 글의 링크를 첨부합니다. 2014년 버전은 치열했던 개발자 시절을 뒤로하고 출판 편집자로 전향한 후 쓴 글인데, 지금 생각도 크게 다르지 않습니다.
조직 문화 바꾸기 - 2014년
(멘탈 부여잡고) 좋은 문화 뿌리내리기 - 2022년
