Closure/West 2012에서의 Antoni Batchelli의 강연입니다.

Pallet – DevOps for the JVM by Antoni Batchelli

제목을 보고 JVM 기반 애플리케이션들 대한 모니터링이나 관리에 대한 얘기인 줄 알았는데, JVM 기반 언어로 만든 Configuration Management Tool이네요. 한마디로 말하자면 Closure로 만든 Cloud용 Chef나 Puppet 정도 되는 것 같습니다.

설명보다는 직접 코드를 보는 편이 훨씬 와닿으리라고 생각합니다. (InfoQ 페이지에서 Slides를 받을 수 있습니다.)

느낀 점은 두가지 정도네요.

1. Ruby나 Closure 같은 언어들이 유행하면서 라이브러리 수준의 DSL만으로 descriptive language 처럼 쉽게 기술할 수 있게 된 것은 오래되었지만, 점점 보편화하고 있군요. 특히, 주로 행동이 아닌 상태를 기술해야하는 Configuration Management Tool에서는 이러한 방식이 더욱 이해하기 쉽고, 유용하며 따라서 모듈화에도 유리한 듯. Provisioning은 적절하게 개념을 세우고 분류를 해서 DB로 만들기만 해도 어느 정도 잘 동작하지만, 대규모 Configuration Management가 필요할 때에도 어느 정도 모듈화되고 버전 관리되는 shell scripts 이상은 직접 본 적이 없고, 그 한계도 잘 알고 있는데, 이제는 Chef나 Puppet 계열을 시도해 봐야 할지도 모르겠군요.

2. 슬라이드들을 자세히 보셨는지 모르겠지만, 만족해야하는 하드웨어 요건과 설치해야하는 소프트웨어들, 노드들의 수를 기술하면, AWS  또는 VM Infra로부터 자동으로 적절한 타입의 instance를 생성해서 요구한대로 설정해주는 시나리오입니다. cloud 환경이나 VM infra 환경 하에서는 당연하게도 이런 마법 같은 일이 가능하다는 것, 가능하다는 것은 알고 있지만, 구체적인 시나리오를 보니 느낌이 새롭네요. 전통적인 인프라 환경에서는 직접 구현하려고 해도 절대 쉽지 않은 일인데요. 저런 꿈 같은 일이 보편화 하는 날이 오게 될지 매우 기대됩니다.

2007년 1월 24일 Google TechTalks에서의 Joshua Bloch의 강연입니다.

How To Design A Good API and Why it Matters (Slides)

InfoQ에서 공개되어 있는 Javapolis에서의 2005년 강연도 있습니다만, 내용은 같아 보입니다. Slides로 충분하다고 생각하지만 OOPSLA 2006에 제출하기 위해 만든 요약도 참고하세요.

Joshua Bloch에 대해서는 Effective Java에 관한 글에서 소개한 적이 있지만, 굳이 여기서 다시 언급할 필요도 없다고 생각합니다. Java의 주요 클래스 라이브러리들의 설계를 주도하여, Java의 API 설계 품질의 기준을 한층 끌어올린 그는, API 설계에 관해 전문가라고 해도 충분하다고 생각합니다.

이 강연의 주제는 제목 그대로 좋은 API를 설계하는 방법과 그 중요성에 대한 강연이고, 제가 아는 한 API 설계에 관한 대부분의 중요한 생각들을 담고 있다고 생각합니다. 그 생각들을 전달하는 면에 있어서도 매우 훌륭한 강연이기에 만약 아직 이 강연을 보신 적이 없으신 분들은 시간을 들여 직접 보실 가치가 있으리라고 생각합니다. 이 글에서는 주로 API의 설계 과정에 대한 내용에 대해 제가 현재 시점에서 인상적인 부분들에 대한 의견을 적어봅니다.

If you program, you are an API designer

예전에는 프로그래머들을 API 설계 경험이 있는 프로그래머와 그렇지 않은 프로그래머로 분류할 수 있다고 생각했습니다. API 설계를 하기 전에는 다른 프로그래머가 어떤 도메인에 대해서 어떤 생각을 가지고 있을지, 주어진 API를 사용할 때 얼마나 실수할 수 있을지, 주어진 API가 얼마나 이해하기 쉬울지에 대해서 고민해보지 않았으니까요. 그리고, 그러한 고민들을 통해서 문제들을 해결하는 방법을 깨닫는 과정이 중요하다고 생각했습니다. API 설계를 경험하고나서 제가 느낀 것은 학부 시절에 Automata 수업을 들었을 때의 느낌이었죠.

그런데, Joshua Bloch은 모든 프로그래머는 API 디자이너라고 얘기합니다. 이 말을 듣고 다시 생각해보니, 실제로는 모든 프로그래머는 자신이 만든 코드를 사용할 모든 사용자 – 즉, 최종 사용자 (end-user)이거나 다른 프로그래머들을 고려하지 않으면 안된다는 것을 깨달았습니다. 어쩌면 그만큼 프로그래머에 대한 잣대가 올라갔다는 생각도 듭니다.

Start with Short Spec–1 Page is Ideal

API 설계의 시작 단계에서는 기민성(agility)이 완전성( completeness)보다 중요하다는 이야기입니다. API 설계의 시작 단계에서는 실제로 그 API를 들고 사용자에게 부딪혀보지 않으면 그 API가 요구사항에 적합한지 알 수 없는데, 이해하기도 힘든 복잡한 API 스펙을 가지고는 사용자들이 이해하기도 힘들고, 변경하기도 힘들다는 것입니다. 일반적인 소프트웨어 개발은 기민성을 중요시하면서도 API 설계에 있어서는 기민성과 완전성 사이에서 저울질 하기가 어려운 면이 있었는데, 한 페이지라는 기준은 매우 훌륭한 기준인 것 같습니다. 그리고, 이 한 페이지를 들고 사용자와 부딪혀보는 과정들 (이를테면, Hallway testing) 도 매우 중요하게 여겨집니다.

When in doubt leave it out

API의 어떤 요소 (메서드, 파라미터, …)가 들어가야 할지 말기 고민된다면, 빼버리라는 것입니다. 이미 다른 사람들이 사용하는 API는 없애기 힘들지만, 추가하기는 쉬운 API의 특성에 기인하는 매우 중요한 특성입니다. 요구사항을 다른 부서 등과 조율하는 과정에서 애매모호한 기능 요구사항들이 항상 나타나는데 이에 대한 명확한 결정을 내리는 것이 가장 좋긴 하겠지만, 그렇지 못하는 경우도 흔히 벌어지는 일인 것 같습니다. 이 때, API의 이러한 특성은 요구사항의 결정에서도 중요한 근거가 될 수 있지 않을까 하는 생각이 드네요.

Write to Your API Early and Often

API 설계에서 가장 흔하게 겪고, 또 가장 중요한 문제점으로 드러나는 것은, API를 이용한 구현하는 도중에 특정 기능을 충족할 수 없음을 발견하는 것일겁니다. 기민한 개발 과정으로 볼 수도 있겠지만, API 사용자 입장에서는 부족한 API 설계 상의 문제를 파악하거나 API가 동작하지 않는 문제를 발견하는 것, 그리고 변경된 API를 적용하는 과정들은 매우 힘들고 비용이 많이 들 뿐만 아니라 괴로운 과정입니다. 이러한 문제들의 대부분은 결국 API를 이용해서 구체적인 프로그램을 만들어보는 것 밖에는 방법이 없고, 기본적으로 이 역할을 API 설계자에게 있어야 합니다. TDD를 한번이라도 해보신 분들은 아시겠지만, API를 사용하는 코드를 먼저 써보는 것은 API 설계에 커다란 도움이 됩니다. 그리고 이러한 과정에서 만들어진 API 예제를 사용자에게 제공하는 것은 API를 사용하는 방법을 쉽게 익힐 수 있도록 도와줄 뿐만 아니라 API 사용자들이 잘못된 사용 방법에 빠지지 않도록 도와줍니다. Joshua는 API 설계 시의 API 예제가 API를 사용하는 모든 코드 중에 가장 중요한 코드라고 얘기합니다. 이는 절대 과장이 아니라고 생각합니다. API 예제가 제공되지 않는 API를 직접 개발하거나 사용해본 입장에서 이 부분이 뼈저리게 느껴지는군요.

Document Religiously

API라고 한다면 가장 좋은 문서화가 요구되어야 하는 것은 당연한 것 같습니다. 하지만, 문서가 없는 API를 종종 봅니다. 저도 잘못된 내용의 문서화가 된 API를 쓰거나, 모든 측면의 문서화를 하지 않은 등의 실수들이 떠오릅니다. 문서화에는 정말 ‘Religiously’라는 단어 – 우리말로 굳이 옮긴다면 ‘열광적으로’ 라고 해야할까요 – 를 써야할 정도로 개발자가 그만큼 공을 들이지 않으면 안되는 것 같습니다.

Closing

이 강연은 비록 5년 전의 내용이지만, API의 설계 과정 뿐만 아니라, 일반적인 API 설계 원리, 클래스, 메서드, 익셉션의 설계에 관한 내용들을 담고 있으므로, 현재는 물론 앞으로도 계속 곱씹을 수 있는 내용이라고 생각합니다. 다시금 말씀드리지만, 한번씩은 보시기를 권해드립니다. 가능하다면, 누군가가 자막 번역을 해준다면 좋겠다는 생각이 드는군요.

제게는 API 설계에 대해서 예전에 했던 생각들을 더올리게 되면서 현재 직면하고 있는 문제들에 대해서도 새롭게 많은 고민들을 할 수 있게 해주는 강연이었습니다. 좋은 강연에 대해서 Joshua Bloch에게 감사드립니다.

Google의 20% Time 제도는 Google의 직원이라면 누구나 업무 시간의 20%, 즉 매주 하루 정도의 시간을 자신이 원하는 일에 투입할 수 있다는 제도. 이 제도는 Gmail 과 같은 성공적인 프로젝트의 요람이 된 것으로 매우 잘 알려져 있고, Google이라는 회사에서 ‘혁신’이라는 가치를 소중하게 여긴다는 사실을 대변하고 있다.

그렇다면 어떤 소프트웨어 회사든 Google의 20% Time 제도를 도입한다면 ‘혁신’에 성공할 수 있을까? 현실을 냉철하게 바라보는 사람이라면 Google에서 조차도 20% Time 제도가 ‘혁신’에 있어서 성공적인가라는 질문에 의문을 품는 것이 당연하다고 본다.

예를 들어, 당신은 어떤 소프트웨어 회사의 상위 관리자이고, ‘혁신’의 추진력을 높이기 위해 (그다지 현명한 이유는 아닐지라도) 유명한 Google의 20% Time의 도입을 검토하고 있다고 생각해보자.

이러한 관점에서 20% Time에 대한 Quora의 답변 내용을 간략하게 정리해본다. 여러 사람들이 기술한 사항들이기 때문에 주관적이기도 하고 시간이 흐르면서 변화한 사항들도 있을 테니, 이 글에 있는 모든 사항들이 정확하다고 보기에는 힘들다는 점을 유념해서 읽어주었으면 한다. Google의 employee가 아닌 입장에서 이 글을 쓰는 한 대체로 부정확하고 상상력에 기초한 우스운 글이 되기 쉽다는 것을 잘 알고 있지만, 동기 부여라는 주제에 관한 스스로의 고민의 과정을 정리해놓는 의미로 생각한다. 이 글에서 언급된 현실을 반영하지 않는 잘못된 사실이나 미묘한 의미가 있다면 지적해준다면 그러한 과정에 매우 도움이 될 것이다.

평가: 20% Time은 어떻게 평가되어야 하는가?

20% Time을 도입한다고 할 때, 가장 먼저 부하 직원들이 묻는 것이 바로 이 부분일 것이다. 20% Time은 강제로 사용하는 것인가? 선택적으로 사용하는 것인가? 어느 쪽이든 평가에 불이익이 있는 것이 아닌가?

In Google

20% Time을 모든 사람이 반드시 활용해야 하는 것은 아니다. 한편, 20% Time을 활용하고자 하는 사람이 20% Time을 사용하는 것을 직접적으로 가로막는 것은 없다. 하지만, 관리자나, 함께 main project의 일정을 고려해야 하는 동료들의 동의를 얻는 것이 바람직하다. 관리자의 승인 하에 20% Time을 모아서 한 주 동안 Full Time으로 일할 수도 있다.

또한 기본적으로 20% Time은 평가 (performance review)에서 제외되며, 포함된다고 하더라도 평가 (performance review)에 인지되기 힘들다. 동료 평가(peer review)에서 인지되는 것이 바람직하겠지만, 현실적으로 100%의 시간을 주요 프로젝트에 사용한 동료가 더욱 좋은 평가를 얻을 확률이 높고 승진도 빠를 수 있다. 정당한 평가를 위해서는 실제로 자신이 기여한 프로젝트의 PM에 대해 정당한 동료 평가를 요구하여야 한다.

이러한 현실적인 어려움 때문에, 대부분의 Google 직원들은 이를 활용하고 있지 않다.

Opinion

보통, 관리자의 입장에서 20% Time을 위한 리소스를 할당하는 것은 절대 쉬운 일은 아니라고 본다. 하지만, 이는 리소스에 대해 단기적인 시각에서 바라보았을 때의 결과라고 생각한다. 만약 20% Time이, 혁신을 유도하거나 생산성을 높이거나 적어도 Turn-over 비율을 감소시킴으로써, 투입한 비용 이상의 성과를 산출할 수 있다면, 처음에 이를 선택하는 것은 조금 과감할 필요가 있겠지만, 곧 익숙해진다면 별로 문제가 되지 않을 거라고 생각한다.

20% Time을 평가에 포함시킬 것인가, 포함시키지 않을 것인가는 매우 어려운 문제다. 평가에 포함시킨다면, 평가를 어떻게 할 것인가라는 문제를 차치하더라도, 평가 자체가 20% Time에 참여하는 사람들의 의도를 왜곡하여 20% Time의 본래 의미를 잃어버리기가 쉽다. 평가에 포함시키지 않는다면, Google의 사례와 같이 20% Time을 사용하기 위한 커다란 incentive가 사라지게 된다. 양쪽 모두가 각각의 문제를 지니고 있기 때문에, 결국은 제도 자체의 겉모습에 치중할 것이 아니라, 제도를 통해서 획득하려는 가치를 기준으로 판단해야 한다고 생각한다.

20% Time이 조직에 혁신을 위한 문화를 조성하고 실제로 혁신을 이끌어내기 위한 것이라면, Google과 같이 평가에 포함시키지 않는 쪽이 더 바람직해 보인다. 그 이유는 다음과 같다.

• 모든 사람이 혁신을 위한 아이디어를 가지고 있고, 이 아이디어를 실제로 실행할 의지를 가지고 있으며, 또 그를 성공시키기 위한 역량을 가지고 있으며, 상황적인 조건이 부합하는 것은 아니다. 아마도 이는 소수에 불과할 것이다.
• 정말로 가치 있는 일이라면 적어도 20% 정도의 보상 기회를 희생할 정도의 가치가 있어야 할지도 모른다.
• 불확실한 미래의 보상을 기대한다고 하더라도, 현재의 확실한 희생을 수용한 사람이라면, 그만큼 보람 있고 열정적으로 일 할 것이다.

물론, 실제 실행 시에는 보다 많은 미묘한 문제들이 발생할 거라고 추측되지만, 이러한 허들을 뛰어넘을 수 있는가의 여부는 실제로 실행해보지 않고서는 미리 예측하기 힘들다.

시간: 20% Time은 너무 길거나 반대로 너무 짧은 것은 아닌가?

In Google

Google에서 실제로 하나의 서비스를 launch하기 위해서는 개발 비용을 넘어서는 커다란 오버헤드를 필요로 한다. 예를 들어, 조그마한 서비스라고 하더라도 launch를 위한 기술 및 제품 승인을 얻기 위해서는 많은 노력을 필요로 한다. 자신의 프로젝트에 참여하기 위한 사람들을 찾는 것도 매우 어려운 과정 중의 하나라고 한다. 막상 서비스를 launch하더라도 수시로 발생하는 outage나 운영 상의 변화에 대응하기 위한 유지보수에 다시 20% Time을 들여야 한다. 따라서, 제대로 뭔가를 하려면 20% Time 만으로는 부족하고 야근과 주말근무를 불사해야 한다. 의견이 엇갈리기는 하지만, 20% Time은 workholic을 위한 제도라고 얘기할 정도. 20% Time은 서비스를 launch하는 수단으로서는 그다지 좋지 않다는 의견도 존재한다.

활용: 20% Time을 어떻게 활용하는가?

In Google

다음과 같은 다양한 활용이 가능하다.

• 기존 및 현재의 프로젝트에서 다른 사람들을 설득하지 못하지는 못했지만, 스스로는 가치가 있다고 생각하는 문제를 개선할 수 있다. 현재의 개발팀이 우선순위 때문에 관심을 기울이지 못하는 어떤 기능을 개선할 수 있다.
• 새로운 서비스나 새로운 소프트웨어를 개발한다.
• 이미 존재하는 전사 프로세스나 도구를 개선한다.
• 외부의 오픈 소스 프로젝트에 기여할 수도 있고, Journal에 기고하거나, 새로운 프로그래밍 언어나 UI 디자인에 대해 공부하는 등, Job Skill을 확장하기 위한 뭐든지 할 수 있다.

가치: 20% Time이 Google에게 가져다 주는 것은 무엇인가?

이에 대해서는 일단 Dion Almaer의 글을 인용해보자.

The key was the followi
ng effect:

• In order for 20% time to work, anyone must be able to see what is out there
• In fact, if you want to get some people working “for free” you need to both advertise your project, and write it in such a way that it is easy to get ramped up and productive (end result: better code)

The end result is the culture HAS to be kept very open. The ability to see the projects that are worked on, check out the code, see presentations and design docs, is a key reason why Google does so well at engineering in my opinion.

난 위의 Quora의 답변 내용에서 나왔던 사실들로부터 20% Time의 효과에 대해 원래 가지고 있었던 의심을 약간은 확인했다고 생각했는데, 이 글을 읽고 내가 지인들로부터 들었던 이야기들이 떠오르면서 그러한 생각이 완전히 바뀌게 되었다.

20% Time은 어떻게 동작하는가?

다음 사항들은 지인들로부터 들었던 이야기들이라 더욱 부정확할 수 있겠지만, 일단 정리해보자.

1. Google에서는 20% Time 프로젝트에 참여할 다른 엔지니어를 모집하기 위해 전사 메일을 보낼 수 있다. 그리고, 20% Time 프로젝트에 리소스를 승인 받거나 공개 서비스로 내놓기 위해 승인 받는 과정이 정의되어 있다.
   • 자신의 좋은 아이디어를 전사 메일로 보낼 수 있고, 참여를 호소할 수 있으며, 이것이 제도적으로 뒷받침되는 소프트웨어 회사는 과연 얼마나 될까?
   • 관리자들은 자신에게 이야기를 하면 되는데 이야기를 하지 않아서 그렇다고 생각할 지 모르겠지만, 공식적인 제도가 있는 것과 이야기를 하면 된다라는 것은 조직원 입장에서는 천지차이다.
2. Google에서는 자신이 만들어 낸 코드, 문서, 발표 자료 등을 누구든지 볼 수 있다.
   • 자신의 프로젝트에 참여하고자 하는 사람 또는 관심이 가는 프로젝트를 주도하는 사람이 얼마나 뛰어난가를 확인하는 가장 정확한 방법은 그 사람이 실제로 해놓은 것을 보면 된다. 다시 말해, 엔지니어가 다른 엔지니어의 산출물에 대해 가장 잘 평가할 수 있다.
   • 대부분의 회사에서도 어떤 방식으로 산출물이 관리되고 있긴 하겠지만, 실제로 어떤 사람의 산출물을 공개적으로 접근하는 것은 매우 어렵다.그래서, 직급이라든가, 함께 일했던 시절의 주고 받은 대화나 메일, 과거 동료들의 단평 정도를 간접적으로 이용하는 것에 불과하다.
3. Google에서는 코드 리뷰가 필수적으로 행해지고 있으며, 코드에 대한 평가를 수치화한 Readability Score라는 척도가 공개적으로 조회 가능하고, 이러한 수치가 다른 프로젝트에 대한 Commit의 허용 여부에 영향을 미친다.
   • 단순히 모든 산출물이 공개되어 있을 뿐만 아니라, 이를 정량화하고 실제로 이러한 척도가 어느 정도의 신뢰성을 가지고 동작한다는 것이 매우 놀랍다.
   • Readability Score는 평가(Performance Review)와는 무관하다.
   • Google의 코드 리뷰 제도에 관해서는 역시 Quora의 답변들을 읽어보면 참고가 될 것이다.

제도, 시스템과 문화를 통한 혁신

혁신에 관한 이야기를 꺼낸다면 아마도 대부분의 상위 관리자들은 다음과 같은 이야기를 할 것이다.

혁신에서는 시간이 있는가, 없는가가 중요한 것이 아니라, 얼마나 열정적으로 문제를 해결하려고 하는 가가 중요하다. 또한, 혁신은 아이디어가 아니라 실행이다.

나는 이런 이야기들에 거의 찬성한다. 나조차도 이런 얘기를 한 적이 분명 여러 번 있을 것이다. 조직의 구성원들의 열정은 혁신에 있어서 필수불가결한 요소이고, 시간의 부족만을 그 원인으로 진단하는 것에 대해서는 반성이 필요한 경우가 많은 것이 사실이라고 본다.

그럼에도 불구하고 혁신과 열정의 원동력이 오직 조직 구성원 내부에만 있다고 보는 관점도 온전히 옳다고만 할 수는 없다고 본다. 단지 조직원 사이에서 혁신과 열정이 저절로 꽃피어나기를 기다리는 것보다는 구성원이 혁신적인 아이디어에 대해 열정적으로 일할 수 있도록 동기를 부여하거나 지원하는, 좀 더 적극적이고 체계적인 행동이 조직에는 필요하다고 생각한다. 이 때, 적극적이고 체계적인 행동이라는 것의 의미는 관리자 개인의 능력이나 성향, 선의에 의한 동기 부여 행동과 대비되는 것을 의미한다.

제도나 시스템이 아닌 관리자 개인에 의존할 경우 다음과 같은 문제들이 존재할 수 있다.

• 관리자 개인에 따라 개인의 능력이나 성향, 선의에 따라서 동기 부여의 수준은 극단적으로 낮을 수 있다. 이러한 경우에 대한 대책이 없거나 있더라도 제대로 동작하지 않을 가능성이 있다.
  • 일반적인 hierarchical 조직에서, 관리자 개인이 조직원의 동기 부여를 크게 해친다고 하더라도 관리자 자신은 이러한 상황을 인지하지 못하거나, 인지하더라도 변화하기가 힘들며, 조직원은 변화를 위한 적절한 권한이나 역량이 없으며, 상위 조직장은 이를 인지하지 못하는 경우가 많다.
  • 조직이 보통 요구하는 것은 조직의 단기 성과를 높일 수 있는 충분한 역량을 가진 조직장이며, 물론, 동기 부여의 능력 또한 조직이 요구하고 바람직한 능력이나, 성과와 동기 부여가 충돌할 경우, 조직은 전자를 선택하는 경향이 있는 것 같다. 팀의 morale을 와해한 조직장이 승승장구하는 (적어도 살아남는) 스토리는 이러한 이유에 기인한다고 생각한다.
• 조직의 상황에 따라 동기 부여의 수단이 쉽게 희생될 수 있다.
  • 일반적인 상황에서 조직 및 이를 대변하는 관리자는 생산성의 저하 요소를 제거하기 위해서 동기 부여에 노력을 기울일 수 있다. 하지만, 조직원의 동기 부여와 우선순위와 R&R 같은 좀 더 전통적인 조직 가치가 충돌할 경우 후자를 우선시하는 경향이 있는 것으로 보인다. 이러한 선택은 조직의 구조나 목적 상 물론 불가피한 측면이 있는 것이 사실이다.
  • 문제는 이러한 조정이 개인에 의한 것일 경우, 극단적인 희생이 이루어질 가능성이 높다는 것이다. 예를 들어, 일반적인 상황에서 동기 부여를 위한 노력이 50%의 비중이었다면, 문제의 상황에서는 0%가 되어버릴 수 있다는 것이다.

단편적인 예를 들어, ‘내가 원하기만 한다면 내가 원하는 일을 언제든지 할 수 있어’와 ‘내가 원하더라도 조직장에게 얘기를 해야할까? 얘기를 한다면 불이익을 받지 않을까? 소속 조직을 옮겨야 할까? 소속 조직을 옮기기 위해 회사의 제도를 활용할 수 있을까? 또는 누구와 얘기해야할까? 그냥 이직을 해야할까?’는 조직원 입장에서 엄청난 차이일 수 밖에 없다.

Google의 20% Time에서 가장 중요한 측면 중 하나는 Google은 조직원의 동기 부여에 대한 강조가, 관리자 개인에만 의존하지 않고, 전사적인 제도와 이를 뒷받침하는 시스템, 그리고 문화를 통해 항상 일정 수준으로 이루어진
다는 것이다.

수평적인 평가와 비물질적인 보상을 통한 혁신의 동기 부여

평가와 보상이란 조직에 있어서 가장 중요한 요소 중의 하나이다. 평가의 본질적인 목적은 보상을 어떻게 공평하게 분배할 것이냐가 아니라, 조직원의 potential을 최대한 발휘하게 하여 조직 전체의 성과를 증가시키는 것에 있다.

하지만, 일반적으로 평가는 어려울 뿐만 아니라, 예측과 정량화의 어려움으로 인한 Software 개발의 본질 상 Software 개발 조직에서의 평가는 매우 어려운 것이 보편적으로 받아들여지고 있다.

<To Be Written>

Closing

Google이 20% Time을 통해서 단지 제도와 시스템 뿐만 아니라 혁신의 문화를 배양하는 것은 실제로 동작하는 사례로서 매우 높은 성취라고 생각한다. 하지만, 혁신을 위한 조직 문화를 만들기 위한 수단이 비단 Google의 20% Time만이 있는 것은 아닐 거라고 추측해본다. 보다 많은 조직에서 이에 대해 고민하고 또 실험하면서 그들만의 혁신 문화를 창조해나갔으면 좋겠다.

좀 더 읽어볼 글들:

• Google’s "20 percent time" in action
• The Google Way: Give Engineers Room
• Thoughts on Google’s 20% time