구글의 소프트웨어 개발 체계

1. 선택된 프로젝트만 살아남는다.

매니저에 의해 일방적으로 일을 할당받는 경우는 없으며, 개발자가 직접 프로젝트 중에서 자신에게 맞는 것을 찾아서 하거나 직접 새로운 프로젝트를 제안한다. 대신 아무도 관심을 가지지 않거나 매력 없는 프로젝트는 주목받지 못하고 사라지며, 이러한 시스템에서 살아남는 것만이 구글의 서비스로 제공된다.

 

2. 소규모로 구성되는 프로젝트 팀

개발자가 자신의 프로젝트를 담당하며, 1개의 프로젝트 팀은 2~6명의 소수 인원으로 구성된다.

큰 프로젝트는 복수의 작은 프로젝트로 분할하여 계층적인 팀을 구성하는데 어느 쪽이든 하나의 팀은

소수의 인원으로 유지되고, 팀 내에서 밀접한 커뮤니케이션을 통해 프로젝트를 진행한다.

 

구글의 개발 거점은 전 세계에 걸쳐있으며, 팀 멤버도 분산되어 있다. 각 멤버는 주로 메일이나 IM(Instant Messenger), 영상회의, 팀 블로그 등을 통해 연락을 주고 받는다. 각 프로젝트 팀은 프로젝트의 제안에서부터 설계, 코딩, 테스트, 성능 평가, 데모 버전의 운용 및 Document 작성까지 전 과정을 수행하게 되며, 프로젝트의 진척 사항은 데이터베이스로 관리되고, 상황에 맞게 갱신된다.

 

모든 개발자는 담당 프로젝트와 별도로 업무 시간의 20%를 다른 새로운 프로젝트에 써야 한다. 이것이 20% 규칙이다. 20% 규칙에는 다른 사람의 프로젝트를 도와줘도 좋고, 자신이 하고 싶은 새로운 프로젝트를 구상해도 상관없다. 어쨌든 새로운 분야에도 손을 대보게 함으로써 시야를 얿히는 것이 주된 목적이다.

 

3. 코드 리뷰에 의한 품질 향상

코드 리뷰(Code Review)가 필수다. 어떤 프로그램을 작성하면 반드시 그것을 다른 개발자에게 읽어 보게 한다. 이렇게함으로써 소스 코드의 가독성과 품질이 높아지고, 동시에 잠재적인 에러를 발견할 가능성도 커진다. 또한 개발자들이 소스 코드를 통해 서로 지식을 교환함으로써 노하우 공유와 학습 효과를 얻을 수 있다.

 

코드 리뷰에는 2가지 단계가 있다. 첫 단계는 프로젝트의 오너에 의한 리뷰로 프로그램이 논리적으로 바르게 동작하는지 확인한다. 2번째는 가독성(Readability) 리뷰라고 불리는 것으로 코딩 스타일(Coding Style)이 올바른지 확인한다. 구글에서는 언어별로 코딩 스타일이 통일되어 있어 누가 작성하더라도 동일한 스타일의 소스 코드가 만들어진다.

 

4. 초기 단계부터 성능 고려

구글의 소프트웨어는 처리 성능을 중요시 한다. 하나의 소프트웨어가 몇 천 대나 되는 컴퓨터에서 작동하기 때문에 약간의 성능 갸선이라 할지라도 전체적으로 큰 영향을 주며, 그 만큼 하드웨어 비용이 억제되기도 한다.

 

5. 새로운 웹 서비스를 시작하기까지

 1) 아이디어를 제안한다: 제안된 아이디어는 우선 데이터베이스에 등록되고, 온라인 투표 시스템을 이용하여 전 직원의 의견을 모은다.

 2) 기본 설계를 문서로 만든다: 배경 및 목적(Why?), 설계(How?), 멤버(Who?), 보안 및 프라이버시에 대한 고찰, 테스트 플랜

 3) 데모를 만들고 의견을 모은다: 데모는 구글 사내 포털 사이트에 올라가고 발표의 장인 TechTalk 등 다양한 기회를 통해 소개된다.

 4) Google Labs와 Beta 버전: 외부에 공개할 정도의 완성도에 이르면 Google Labs의 새로운 서비스로 일반인에게 공개한다. 일반인의 평판이 좋은 것은 다시 베타 버전으로 격상되어 구글의 새로운 서비스의 하나로 합류한다.

 5) 정보는 철저하게 공유: 메일링 리스트와 블로그, 도큐먼트와 데이터베이스, TechTalk, TGIF, 이력서와 스니펫, 분기 보고