20% Project?

  • 20%의 근무 시간을 개인 프로젝트에 할당하게 해주는 제도.
  • 15% Project로 운영하는 경우도 있다.
  • Atlassian에서는 FedEx Day라 부른다.

이 제도를 시행하는 유명한 회사들

3M

3M은 1948년부터 15% 제도를 도입했다.

1930년대와 1940년대에 3M의 회장이었던 윌리엄 맥나이트(William McKnight)는 혁신적인 사고방식의 소유자이자 가식이라고는 모르는 사람이었다. 그는 "유능한 사람을 고용해서 그냥 놔둬라"라는, 간단하지만 전폭적인 신조를 지지했다. 그는 경영계에 '권한부여'라는 개념이 유행처럼 퍼지기 훨씬 이전부터 자율성을 주장했다.

(중략)

사업계의 이단아였던 맥나이트는 정통에서 벗어난 이례적인 사고방식에 기초해서 새로운 정책을 발표했다. 3M의 기술진에게 업무시간 중 15퍼센트까지를 자신이 선택한 프로젝트에 할애하도록 허용한 것이다.

  • 포스트잇
  • 그 외 수많은 제품들

윌리엄 맥나이트의 이야기는 다음 글을 참고.

Google

  • Gmail
  • Adsense
  • Google 뉴스
  • Google 번역
  • Google 스카이

'20% 시간'은 구글러들이 사이드 프로젝트라고 부르는 것이다. 그것은 개념 수준이 아니고 구글에 종사하는 사람들이 자신의 주요 업무와는 별도로 일주일에 하루를 다른 업무에 쓸 수 있게 하는 공식적인 구조다. 이 아이디어는 주 5일 근무 중 4일은 돈을 버는 데 쓰고, 나머지 하루는 혁신과 실험을 하는 데 쓰라는 뜻이다. 어디까지나 선택 사항이며, 이전 구글러들의 경우 이 아이디어는 미신이라고 주장했다. 우리의 경험에 의하면 이 개념은 실제로 가능하고 우리 3명 모두 20%의 프로젝트를 하고 있었다. 사실, 이 책에서 이야기하는 많은 툴이 20% 활동의 결과물이고, 결국에는 실체화돼 제품에 공헌했다. 하지만 많은 구글러가 자신의 20% 시간을 단순히 다른 제품에 작업하는 것을 선택했다. 따라서 20% 공헌자의 개념은 많은 제품, 특히 재밌는 새로운 제품을 즐기는 무엇인가가 됐다. 1

Atlassian

다른 위대한 기업가들과 마찬가지로 캐논-브룩스도 언제나 불만이 가득하던 시절을 겪어본 사람이었다. 그는 승승장구하던 회사들이 정체되는 것을 보면서 자기 회사만큼은 다르기를 바랐다. 그래서 창의성과 재미를 불러일으키기 위해 회사의 프로그래머들에게 정규 업무가 아니더라도 자신이 원하는 어느 문제에 대해 하루를 온전히 허용하겠다고 결심했다.

(중략)

아틀라시안에서는 24시간 동안 자유와 창의력을 맘껏 발산하는 이 날을 '페덱스 데이'라고 부른다. 하룻밤 사이에 뭔가를 배달(전달)해야 하기 때문이다.
그리고 아틀라시안은 확실한 결과를 전달해왔다. 지난 몇 년에 걸쳐 전혀 해결되지 못했을 소프트웨어의 문제점들이 이 기이한 작은 관행을 통해 많이 해결되었다. "현재 우리 회사 최고의 제품 중에는 페덱스 데이에서 나온 것이 많다"고 한 엔지니어는 말한다.2

기술 부채 해결에 사용하기도 한다

케이건(Marty Cagan)은 조직이 "20%의 세금"을 내지 않으면 필연적으로 모든 개발 및 운영 주기를 기술 부채를 해결하는 데 쏟아야 할 만큼 기술 부채가 증가할 것이라고 지적했다. 어느 시점에는 서비스가 매우 취약해져서 기능 제공이 서서히 중단된다. 모든 엔지니어가 안정성 문제와 문제 해결 작업에 매달려 있기 때문이다.

(중략)

개발 및 운영 주기의 20%를 투자하면 개발과 운영이 일상 업무에서 직면하는 문제에 대한 대응책을 지속적으로 마련할 수 있으며, 서비스를 빠르고 안전하게 개발하고, 프로덕션 환경에서 운영하는 능력이 기술 부채에 방해받지 않음을 보장받는다. 작업자에게 기술 부채 추가에 대한 부담감을 높이므로 번아웃 수준도 낮출 수 있다. 3

대기열 이론의 관점에서 보는 20% project

대기열 이론은 대기열을 연구하는 응용 통계 분야다. 대기열 이론은 대기 시간과 수용량 활용 간의 관계를 정량화할 수 있게 해준다. 십지어 요청이 들어온 시간과 처리하는 데 걸리는 시간이 변동적인 경우에도 마찬가지다. 시스템이 처리하는 것보다 더 빨리 요청사항이 생기면 대기열에 들어간다.

60~80%의 활용률에서 벗어나면 대기열이 2배로 늘어난다. 활용률이 80~90%가 되면 대기열은 다시 2배가 되고, 다시 90~95%가 되면 그 2배가 된다. 80%의 활용률을 초과하면 대기열 크기가 기하급수적으로 증가하고, 100%가 되면 속도가 느려진다.

20%의 '창의적인' 시간 정책을 가진 회사에서 일해본 적 있는가? '창의적인' 시간 정책의 주된 이유는 혁신(단지 보너스)이 아니라 수용량 활용도를 100%가 아닌 80%로 유지하기 위함이다. 1948년 3M은 15%의 여유 시간을 줬고, 그로부터 몇 년 후 포스트잇을 출시했다.

서버 활용이 100%가 되지 않도록 하고, 스스로에게도 그렇게 하지 말자. 4

이 관점에서는 수용량 활용률 100%로 리소스를 가동할 때 대기 시간이 발생하게 된다는 점에 착안하고 있다.

  • 컴퓨터가 100% 사용량에 가까워지면 응답이 느려지거나 멈춘 것처럼 보이게 되는 것을 떠올려 보자.
  • 고속도로의 경우 사용량이 100%에 가까워질수록 교통 정체가 심해진다.

즉, 3M 에서 15%의 여유 시간을 준 것은 고의로 속도를 늦춘 것이 아니라 활용률이 85%를 초과하지 않도록 하기 위함이었다는 것이 위 글의 내용이다.

함께 읽기

  • [[/technical-debt]]

참고문헌

  • DRIVE / 다니엘 핑크 저/김주환 역 / 청림출판 / 1판 16쇄 2017년 4월 10일 / 원제 : Drive : The Surprising Truth About What Motivates Us
  • 구글은 소프트웨어를 어떻게 테스트하는가 / 제임스 휘태커, 제이슨 아본, 제프 카롤로 공저 / 제갈호준, 이주형 공역 / 에이콘출판사 / 초판 인쇄 2013년 03월 22일 / 원제 : How Google Tests Software
  • 데브옵스 핸드북 / 진 킴, 제즈 험블, 패트릭 드부아, 존 윌리스 저/김영기 역 외 1명 정보 더 보기/감추기 / 에이콘출판사 / 2018년 07월 06일 / 원제: The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations
  • 업무 시각화 / 도미니카 드그란디스 저/유지은, 김혜주 역/조승빈 감수 / 에이콘출판사 / 발행: 2020년 01월 31일 / 원제 : Making Work Visible

주석

  1. 구글은 소프트웨어를 어떻게 테스트하는가. 2장. 57쪽. 

  2. DRIVE 132쪽. 

  3. 데브옵스 핸드북 117쪽. 

  4. 업무 시각화. 3.1장. 190쪽.