drchung's weblog

(1 편에서 계속)

이 책의 세번째 챕터 ‘Don’t be evil: How Google built its culture’는 구글의 문화에 대한 이야기. 이 장에서 내 기억에 가장 남는 것은 구글의 문화는 – 우리나라에서도 많이 들어본 – 몬테소리식 교육에 바탕을 두고 있다는 것이다. 구글 VP인 머리사 메이어(Marissa Mayer)는 다음과 같이 말했다고 한다. (p 121)

You can’t understand Google unless you know that both Larry and Sergey were Montessori Kids.

몬테소리란 단어를 어렸을 때부터 봤고, 유치원을 졸업한 아이가 있는 나이지만 사실 몬테소리 교육이 뭘 뜻 하는 지는 이 책을 보고서야 알았다. 몬테소리는 아이들은 좋아하는 것을 해야 한다고 믿는 교육 철학이라고 한다(이 철학의 주창자 마리아 몬테소리에 대한 소개 링크). 머리사 메이어가 말한  몬테소리와 구글의 두 창업자 얘기를 좀 더 옮겨 보자면 (p 121)

“In a Montessori school, you go paint because you have something to express or you just want to do it that afternoon, not because the teacher said so,” she says. “This is baked into how Larry and Sergey approach problems. They’re always asking, why should it be like that? It’s the way their brains were programmed early on. (“몬테소리 학교에서는 학생이 표현하고 싶은 게 있거나 그냥 그리고 싶기 때문에 그리는 것이지, 선생님이 시켜서 그리는 것이 아니다. 이런 게 래리와 세르게이가 문제를 푸는 방식에 그대로 반영돼 있다. 래리와 세르게이는 항상 그건 왜 꼭 그렇게 해야하지?라고 묻는데 이건 어렸을 때부터 그들의 두뇌가 그렇게 프로그램 됐기 때문이다.”)

최고의 IT기업이라고 인정 받는 구글의 두 창업자가 모두 몬테소리 교육을 받았고 그 회사의 문화 밑바탕엔 몬테소리 철학이 깔려 있다니, 사교육에 관심 많은 우리나라 사람들이 이 사실을 알면 대단히 혹할 내용인 것 같다.  나도 울 둘째에게는 몬테소리 교육을 받게 하고 싶다는 생각이 들었음. 그런데 와이프 말로는 유치원에서만 몬테소리 교육을 받는 건 부족하고 집에서도 해야 하는데, 그러면 교구가 필요하고, 그 교구가 엄청 비싸다는… -_-;

하여튼 이 몬테소리 교육을 받은 두 창업자의 영향을 받아, 전통이나 구태의연함을 뛰어 넘는 혁신을 만들어 내는 구글 문화가 형성 됐다는 건데… 그럼 상식을 깨는 구글 문화엔 어떤 게 있는지 보면… (책 읽으며 밑줄 쳐 뒀던 몇 구절)

1. 구글에는 개발자이 업무 시간의 20%를 자신이 원하는 프로젝트에 사용할 수 있는 20% 프로젝트 문화가 있다. 창의적인 뭔가를 만들어 낼 수 있다고 부러워 하는 사람이 많은 걸로 안다. 그런데 실제로는 할 일 다하고 해야해서 120% 프로젝트란 농담이 있다고. (p 124) 자, 이제 이런 거 부러워하지 말자. 응? ㅎㅎ

2. 원래 래리와 세르게이는 모든 개발자들을 중간 관리자가 아닌 개발조직장 (head of engineer) 아래 수평적으로 두길 원했다고 한다 (p 158). 개발자들이 자발적으로 삼삼오오 모여 프로젝트를 하고 개발조직장에게 보고 하길 바랐던 것. 회사의 비공식 멘토(unofficial executive coach)였던 빌 캠벨 (Bill Campbell)은 그게 마음에 안들었기 때문에 래리 페이지와 함께 야근을 하는 개발자들을 하나 하나 불러 중간 관리자에게 관리를 당하고 싶냐고 물어 봤단다. 놀랍게도 모두 원한다고 대답했다고. 그 이유는 뭔가를 배울 수 있는 누군가를 원했고, 동료끼리의 토론이 결론이 안 나면 결정을 해 줄 사람이 필요하다는 것. (그럼에도 불구하고 래리와 세르게이는 중간관리자를 없앴지만 개발자 수가 확 늘어나면서 중간관리자가 필요하게 돼 다시 팀장들을 고용) 많은 수의 개발자들이 팀장을 원했다는 게 좀 의외.

3. PM (Product manager: 제품 관리자) 자리에 MBA 출신보다 개발자를 선호 하는 것도 상식을 깨는 것. CEO인 에릭 슈미트가 제품 관리 임원 자리를 맡기기 위해 조나단 로젠버그 (Jonathan Rosenberg)를 데려왔는데 두 창업자는 신경도 안 썼고 “계획 같은 거 세우지 말고 그냥 개발자 말이나 잘 들어라”는 말이나 했다고. (p 160) 이런 처지였으니 조나단이 PM을 고용하기도 힘들었다고 한다. 똘똘한 MBA 출신 PM 후보들은 번번히 래리에게 퇴짜를 맞았는데, 머리사 메이어는 “래리가 개발자를 이해하는 똑똑한 PM보다는 개발자들이 PM을 하는 걸 원했기 때문”이라고 추측. 구글의 PM은 개발자들에게 명령을 하는 자리가 아니라 개발자들을 잘 꼬셔 원하는 방향으로 생각하게 만드는 자리란다. (p. 161)

4. 사람을 뽑을 때도 마찬가지인데, 사람이 앞으로 일 할 분야의 경력을 얼마나 가지고 있는지를 보는게 아니라 그 사람 자체가 얼마나 똑똑한지 위주로 본단다. (“We value insight over experience”) (p 161) 똘똘한 친구들은 무슨 일을 시켜도 잘 한다는 가정이겠지?

5. OKR(Objective and Key Results)이란 성과 지표를 사용하는데, 개인이 달성한 이 OKR 값이 인트라넷의 개인정보에 포함돼 있어 아무나 볼 수 있다고 한다 (p. 163). 나의 성과를 관리자가 아니라 아무나 볼 수 있다니 좀 무서운데, 확실히 깨는 발상이다. 이런 투명성이 직원 사이의 갈등을 불러 일으키지 않을진 모르겠다. 야후!에 있을 때 비슷한 MBO (Management by Object)란 지표를 사용했지만 유명무실 했던 기억이 난다.

    (2014년 11월 내용 추가) 이 OKR방식에 대해 Business Insider에서 자세히 다룬 기사가 있어 링크한다. 읽어보니 정량적 평가가 가능하고 분기당 한 번씩 정해 실제 하는 일과 거리가 없이 적용될 수 있다는 게 강점 같다.