한국 개발 문화 vs 구글 개발 문화. 구글의 특별함?
feat. <구글 엔지니어는 이렇게 일한다>
<구글 엔지니어는 이렇게 일한다>와 관련하여 다음 비슷한 질문들을 종종 받았습니다.
구글이 일하는 방법이 한국 개발 환경에도 맞을까요?
구글 엔지니어와 국내 기업 엔지니어의 업무 방식은 어떻게 다를까요?
제조업 기반의 SW 개발 조직에 구글과 같은 문화를 적용하는 게 현실적으로 가능할까요?
모든 질문에서 질문자들은 ‘한국이라서’, ‘한국 기업이라서’, ‘제조업 회사라서’ 같은 장벽에 부딪혀 고심 중이심을 느낄 수 있습니다. 구글 이야기가 아무리 좋게 들려도 다른 나라, 다른 문화권, 다른 분야 기업의 이야기로 들렸을지 모르겠습니다. 부럽지만 나와는 상관없는 이야기로 말이죠.
책을 읽고 비슷하게 느끼실 분이 적진 않으시겠죠? 그래서 비록 저는 구글 엔지니어가 아니지만, 제가 번역한 책을 포함하여 여러 구글 관련 정보와 주변 구글러들께 들은 이야기를 토대로 생각을 정리해 보았습니다.
한국이라서?
우리나라는 아직 수직적 문화, 개발자에 대한 인식과 역할 측면에서 걸림돌이 제법 있어 보입니다.
하지만 한국이라서 혹은 한국 기업이라서 안 되는 건 없다고 생각합니다. 15여 년 전만 해도 애자일은 우리에게는 맞지 않다는 사람이 굉장히 많았습니다. 수평적 문화도 그렇고, 테크 리드 같은 개념도 떠올리기 어려웠습니다.
하지만 요즘은 애자일이 낯설지 않고, 수평적 문화를 강조하는 회사가 늘고 있고, 테크 리드와 비슷한 제도를 시도해보는 회사도 많이 봤습니다. 이처럼 한국의 개발 환경도 점점 변하고 있으니, 당장 효과가 있을 만한 것부터 차근히 시도해보면 될 겁니다.
물론 조직이 쉽게 변하지는 않습니다. 경직된 문화의 회사가 쉽사리 유연한 문화로 바뀌는 건 상상하기 어렵죠. 윗분들의 사고가 변하길 기대하기보다는 이미 유연한 회사를 찾아 떠나는 게 빠릅니다. 심지어 내가 리더라 해도 구성원들의 업무 방식과 마음가짐을 바꾸기는 무척 어렵습니다. 하지만 이는 다른 나라도 마찬가지입니다. 미국 회사라고 해서 다 구글 같지 않습니다.
그리고 책에서도 이야기하지만 또 하나의 구글을 만들 필요는 없습니다. 동료 분들과 소통하며 현재 상황에서 한 단계 나아질 수 있는 구체적인 방식을 고민하고 도전해볼 수 있는 문화를 갖추는 데 힘쓰면 좋을 것 같습니다. 구글의 방식은 이 길을 먼저 걸어본 사람들이 내놓은 좋은 참고자료로 활용할 수 있겠고요.
제조업 회사라서?
어느 조직이든 수익을 직접 창출하는 부서의 목소리가 가장 큽니다. 제조업이라고 하면 하드웨어의 힘이 크겠죠. 그렇지만 제조업에서도 소프트웨어의 규모와 중요성이 빠르게 커지고 있다는 건 역사적 사실입니다. 좋은 예로, 오늘날 자동차와 10년 전, 20년 전 자동차에서 소프트웨어의 비중을 생각해 보세요. 심지어 테슬라는 전기차를 ‘움직이는 소프트웨어’라는 시각에서 접근했다고 하지요.
조직에서 이 변화를 빠르게 인지하고 적절히 대응한다면 경쟁사보다 앞서 나갈 기회가 더 많지 않을까 생각해 봅니다. 그리고 소프트웨어 엔지니어들 역시 소프트웨어로 더 많은 가치를 창출할 방법을 고민하고, 실력을 제대로 보여줄 아이디어를 짜내고 어필하고 스스로 기회를 만들어내야 하겠습니다. 그래야 소프트웨어 엔지니어의 목소리에 더 귀를 기울일 것입니다.
물론 이 역시 당장 변화하기는 어렵습니다. 노력 없이, 끈기 없이, 실패 없이 큰 결실을 맺기는 어느 분야나 다 어렵겠지요. 그래도 1~2년 일하실 건 아니실 테니, 인내하시며 변화에 협조해주시면 몇 년 후 달라져 있는 모습을 눈으로 확인하실 수 있을 겁니다(제 경험담이기도 합니다).
구글 엔지니어의 특별함?
구글은 ‘엔지니어 개개인’보다는 ‘기업 문화’의 차이가 더 커 보입니다. 실제 구글 엔지니어를 만나보고는 “생각보다 엄청 똑똑하다는 느낌은 못 받았다”라고 이야기하시는 분을 많이 뵈었습니다. 제가 아는 구글러들은 모두 똑똑한 분들이지만, 똑똑한 분들은 다른 회사에도 많으니깐요.
<구글 엔지니어는 이렇게 일한다>에서도 그렇게 이야기합니다. 개인의 능력보다는 일하는 문화가 중요하고, 소프트웨어의 가치와 소프트웨어 개발 방식을 이해하는 사람들이 조직을 이끈다는 점이 중요한 거 같습니다.
단, 아무리 똑똑하더라도 소통하고 도전하고 변화를 두려워하지 않는 사람이어야 구글에서 버틸 수 있다고 합니다. 오래전 구글의 한 리더분이 해주신 말씀이 떠오르네요.
“구글에서는 대학 때 배운 알고리즘이나 일반적인 오픈 소스 라이브러리를 그대로 쓸 수 있는 게 거의 없다. 오랜 세월 검증된 알고리즘도 구글 규모에서는 효율적으로 작동하지 않는다.”
구글의 특별함?
앞 질문에서 ‘엔지니어 개개인’보다는 ‘기업 문화’의 차이가 더 커 보인다고 말씀드렸습니다.
단적인 예로 구글은 다른 팀, 다른 프로젝트의 코드를 엔지니어 누구나 살펴볼 수 있습니다. 좋은 코드를 보고 배울 기회가 많고, 나아가 버그가 보이면 패치해줄 수 있고, 내게 필요한 기능을 작성해 커밋할 수도 있습니다. 자연스럽게 공동 소유라는 인식이 싹터서, 불평을 늘어놓는 대신 직접 참여해 함께 개선합니다. 사내 프로젝트끼리는 오픈 소스 개발 모델을 따른다고 생각하면 이해하기 쉬울 겁니다.
그 외에도 각 팀이 개발 방식을 자유롭게 선택하도록 하면서도 모두가 따라야 하는 규칙과 모범사례를 만드는 데도 엄청난 노력을 쏟습니다. 특정 문화나 기법을 바로 강제하기보다는 혜택을 몸으로 느껴서 스스로 따라오게 유도하는 방식을 추구합니다. 훌륭한 사람을 뽑으려 노력하고 성장을 뒷받침해 줍니다. 도움을 준 동료를 칭찬하고 보상하는 제도를 운영합니다. 최고의 인프라와 개발 환경을 제공합니다.
마치며
구글도 처음부터 지금과 같은 모습은 아니었습니다. 과거 제가 겪은 많은 문제를 구글도 한때 겪었더군요. 하지만 엔지니어 중심의 철학과 문화를 토대로 꾸준히, 갖은 시행착오를 거치며 한 걸음씩 내딛으며 지금에 이르렀습니다.
또한 구글 전체의 구석구석까지 책에서 이야기하는 수준에 도달해 있는 건 아닌 걸로 보입니다. 당연하겠지요. 책을 리뷰해주신 구글러분들도 책을 통해 새로 배운 게 많다고 하셨습니다. 어떤 면에서는 책보다 앞서 있는 팀도 당연히 있을 것이고요.
마지막으로 저자들도 구글의 방식이 옳다고 주장하지 않습니다. 우리가 비슷한 문제에 직면했을 때 참고할 수 있는 멋진 자료 정도로 생각할 수 있겠죠. 어떤 내용은 바로 따라 해도 효과가 충분할 것이고, 어떤 내용은 당장은 의미가 없거나 오히려 역효과가 클 것입니다. 또는 우리에게 맞는 다른 방법을 찾는 게 나을 수도 있고요. 그래도 분명한 건 소프트웨어는 덩치가 점점 커지고 수명이 길어지고 있습니다. 구글은 이 길을 대부분의 기업보다 먼저 걸으며 남들이 겪어보지 못한, 하지만 곧 겪게 될 가능성이 큰 문제들을 헤쳐나가고 있습니다. 그러니 확실히 곱씹어볼 가치는 있어 보입니다. (비슷한 규모의 다른 회사들은 어떻게 대처해왔는지 궁금해지네요.)
