Software Development

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

http://www.infoq.com/presentations/NoSQL-Netflix

지난 7월 QCon 발표. 이 발표자는 굉장히 여러 군데서 동일한 내용으로 발표한 모양인데도 불구하고, 실은 썩 마음에 드는 발표는 아니었지만, 실제 엔지니어링 경험이 뼈저리게 느껴져서 인상 깊게 보았던 발표다.

Netflix’s Cloud Transition

2008년 말, Netflix는 하나의 데이터센터를 가지고 있었고, SPOF와 cooling, power, space, traffic capacity 문제에 봉착하고 있었다. (문맥상 그야말로 데이터센터를 ‘보유’하고 있었던 것으로 보이는데, 미국의 경우 이러한 방식이 일반적인 방식인 것인지, 그리고, SPOF가 중요한 문제가 될 만큼 데이터센터의 신뢰성이 문제가 되는 수준인지 궁금하다.) 그리고, 놀랍게도 outsourcing을 통해,  당시 IaaS 플랫폼으로서는 leader 격이었던 AWS를 통해 해결하기로 결정한다.

Netflix의 cloud migration에서 중요한 점 중 하나는 가장 중요한 사용자 개인 정보 (PII), 결제 정보 (PCI DSS)는 그들의 데이터센터에 남겨놓고, 나머지 – 비디오의 메타데이터, 리뷰, 사용자의 비디오 큐, 시청 기록, 평점, 로그 등 만을 cloud로 이동했다는 점이다.

AWS로 가면서 자연스럽게 선택하게 된 storage는 바로 Simple DB와 S3인데, Simple DB는 RDBMS의 대체, S3는 Simple DB의 item 크기 제약을 넘어서고, single key로만 액세스하는 데이터를 저장하는데 사용한다. 그러다 Simple DB의 데이터 모델 제약이라든지, Scalability concern등의 문제들을 넘어서기 위해서 Cassandra도 사용하게 되었다고 한다. 이 발표에는 등장하지 않았지만 M-R과의 조합이 필요한 곳에는 Bigtable도 사용하는 것으로 보인다.

이 발표에서는 Simple DB와 Cassandra를 간략하게 소개하고, Simple DB를 실제로 적용할 때 겪었던 문제들을 정리하고, Cassandra 에서 이러한 문제들이 많이 해결되었다고 얘기하고 있다.

Problems in transition from RDBMS to Key-Value Data Store

당연하지만, RDMS에 있을 때 편하게 썼던 기능들이 필요해지면 application layer에서 알아서 구현해야 한다.

• partial or no sql support
  • joins이나 group by가 없기 때문에 application layer에서 구현
• no relations between domains
  • application layer에서 구현.
• no transaction
  • simple db에서는 conditional put/delete op이 존재하기 때문에 이를 이용해 optimistic locking
  • cassandra에서는 batch mutate op 이용
• no schema
  • attribute 이름 등에서 misspelling이 발생할 경우 silent하게 실패.
  • 공통 data access layer에서 validation
• no sequences
  • primary key를 위해서는 자연스럽게 발생하는 unique key나 그러한 경우가 아닐 때는 UUID 사용
  • ordering을 위해서는 distributed sequence generator (using zookeeper)나 client timestamps 사용
• no constraints (uniqueness, foreign key, referential , integrity)
  • application layer에서 구현

Workaround Issues in SimpleDB

SimpleDB의 설계나 구현이 아직 충분히 성숙되지 않았음을 엿볼 수 있기도 하고, 어떤 측면에서는 다른 DBMS에서도 충분히 겪을 수 있는 문제이나, 충분한 사용 경험이 없기 때문에 해결에 많은 시간을 들여야 할 가능성이 높다고 생각한다. 발표를 들으면서 발표자인 Siddharth Anand가 얼마나 고생했을지 감정이입이 될 정도.

• no backup and recovery
• no native support for types
  • 모든 데이터는 UTF-8 character string이고 sorting은 lexicographical만 지원하기 때문에, 숫자 sorting을 하기위해서 데이터에 zero-padding을 해야 한다는 어처구니 없는 일이 발생한다.
• null attributes are not indexed
  • null 은 indexing이 안되어있기 때문에 where clause에 is null을 쓰면 full domain scan.
    • null인지 여부를 나타내는 필드를 추가해야 하기 때문에, 결국 sparse table의 장점을 잃어버림.
  • 역시 비슷한 문제로 null일 수 있는 attribute에 대해 order by 하면 null attribute의 record는 아예 나오지 않음.

• data set partitioning

  • domain에 10GB limit와 1B attributes limit가 존재하기 때문에 domain을 application level에서 sharding 해야 함.
  • write throughput을 늘리기 위해서는 sharding 해야 함.

• attribute name이 case-sensitive하므로 miscased나 misspelled attribute names을 체크해야 함.
• limit N clause가 없으면 100개의 row만 return 되므로 실수하지 않았는지 체크해야 함.
• 하나의 statement 내에서 하나의 attribute를 업데이트하고 다른 attribute는 null out할 수 없음.

Thoughts

흔히 NoSQL로 분류되는 storage들은 RDBMS가 아니라는 것 외에는 별로 공통적이라고 할만한 것이 없다. 그래서 NoSQL이라는 말을 쓰는 것을 매우 싫어하는 편이다. 이 발표를 들으면서 이러한 생각에 좀 더 확신이 들었다고 할 수 있을 것 같다.

NoSQL이라고 하는 storage들을 실제로 자세히 들여다보면 각각마다 데이터모델, 오퍼레이션 특성, 성능 특성, 성숙도는 천차만별이다.  결국 하나의 storage를 채용하기 위해서 서로 다른 특성들을 이해하고, 유효한 방법으로 평가는 일만 하더라도 결코 쉬운 일이 아닐뿐더러, 채용하기로 결정한 storage의 데이터모델에 적합하게 데이터를 구성한다든가, 위의 사례에서 보았듯이 각 storage별 세부 특성이나 결함 등을 처리하는 일까지 더한다면 하나의 storage solution을 도입하는 일은 보통 일이 아니다. 그래서, “NoSQL이란 거 좋다면서?”라고 말을 꺼내는 사람이 있으면 “그냥 RDBMS 쓰세요”라고 얘기해주는 것이 정답이라고 본다. NoSQL이라는 bandwagon에 타려고 발걸음을 서두르기 전에, 남들이 하는 이야기들을 반복하기 전에, 왜 RDBMS를 쓰면 안되는 지부터 자신의 도메인에서 고민해보았으면 한다.

주변 사람들에게는 몇 번 얘기했었지만, 이 발표를 들으면서 한가지 매우 인상 깊었던 얘기는 consistency가 깨질 수 있는 것을 인정하고 배치의 형태로 항상 백그라운드에서 동작하고 있는 data fixer를 개발하고 있다는 내용이었다. 별 것 아니라고 생각할 수도 있지만, 이러한 패러다임은 RDBMS를 사용하던 시절에는 inconsistency를 유발하는 원인이 있다면 이를 제거해야 하는 것으로 보는 것 (아니면 아예 무시하거나)과는 완전히 다른 패러다임이다. 현재로서는 weak consistency의 NoSQL storage를 사용하면서도 아직 기존의 패러다임에 젖어 있는 것이 사실인 듯 하다. 지금은 transaction 없이 application layer에서 index를 만들고 나중에 consistency가 깨어지지 않기를 기도하겠지만, 앞으로는 application layer에서도 anomaly를 탐지하고 자연스럽게 해결할 수 있도록 해야할 뿐만 아니라, 지속적인 validation & flx 작업이 필요할 것이다. RDBMS도 경쟁하고 있는 환경에서 wea
k consistency 모델이 얼마나 유행할지는 잘 모르겠지만, weak consistency 모델의 이러한 데이터 운영 패러다임을 간략한 개념과 구현으로 정리할 수 있다면 바람직할 것 같다.

어제 송년회가 피곤했던지 일찍 잠들었다 새벽에 깨는 바람에, QCon SF 2010에서 Google의 Engineering Manager인 Ashish Kumar가 발표한 Development at the Speed and Scale of Google이라는 Presentation을 보게 되었다.

이 발표의 내용은 Google의 Infrastructure 중 하나인 빌드 시스템에 관한 내용으로 아주 재미있는 발표는 아니었지만, 몇 가지 흥미로운 점이 있었다.

Monolithic Code Tree

Google은 어느 정도 알려진 바와 같이, 하나의 코드 저장소에 모든 코드를 관리하고 있으며, 누구든지 필요한 소스코드를 체크아웃해서 사용할 수 있다.

Reducing Checkout Costs

모든 것을 소스로부터 빌드하기 때문에, 의존성을 가진 코드들을 체크아웃하는 비용을 무시할 수가 없는데, 사실 변경하려는 코드가 아닌 코드에 대한 로컬 복사본은 필요 없으므로, FUSE 기반 파일 시스템을 이용한 전체 code tree의 읽기 전용 복사본을 이용한다고 한다.

Reducing Code Review Costs

Google의 개발 프로세스를 보면 commit 이전의 코드 리뷰가 필수적으로 들어가있는 것으로 보이며, 코드 리뷰의 비용을 줄이기 위한 시도로서, 웹 상에서 graphical diffs를 조회하고 이에 대한 comment를 남길 수 있는 code review 도구와 lint error, code coverage, code analysis, test results 등이 제공된다.

IDE 기반의 도구에 대비해, 웹 기반 도구를 사용하고 있는 것이 흥미로운 점인데, C/C++ 계열에는 적절한 IDE가 부족한 점도 있겠지만, 아무래도 웹 기반 도구는 그 기본적인 특성 덕분에 하나의 정보를 여러 사람들에게 공유하기가 매우 쉽다는 점이 커다란 장점으로 작용하는 듯 하다. 다시 말해, 웹 만큼 훌륭한 shared workspace는 흔치 않다.

Reducing Build Costs

개발 과정에서의 커다란 비용 중의 하나로 지적하고 있는 것이 바로 build를 하는 도중 기다리는 비용인데, 이를 줄이기 위해서 object 파일들의 캐슁, 빌드 결과물에 대한 lazy한 액세스, incremental link (old binary + modified object files) 등을 지원하는 분산 빌드 시스템을 채용하고 있는 것 같다.

Continuous Integration

지속적인 통합 (Continuous Integration)이 실패했을 때 발송되는 메일에는 빠르게 원인을 파악할 수 있도록, 실패한 테스트의 목록, 실패를 유발한 Difff를 포함하고 있으며, 테스트 결과, 변경사항, 빌드 결과에 해당하는 웹 도구들에 대한 직접적인 링크를 포함하고 있다.

흔히 이러한 종류의 메일 보고서의 내용은 소홀한 경우가 많은데, 문제에 대한 진단이라는 것이 최종적인 목표라는 점을 생각한다면, 이러한 메일 보고서의 내용을 잘 갈고 닦을 필요가 있다.

Infrastructure

Google의 빌드 시스템은 외부에서도 사용할 수 있는 형태로 공개되어 있지는 않지만, 원래는 존재하지 않던 도구들을 Google이 사용하고 있는 것은 아니다. 가장 중요한 것은 아무래도 모든 도구들과 시스템이 통합된 형태로, 아무런 비용을 지불하지 않아도 전사적으로 제공되며, 실제 개발 과정에서 가능한 한 보이지 않는 형태로 제공되는 것으로 보인다.

여러 가지 종류의 도구들 (예를 들어, 여러 회사의 도구)을 혼합해서 사용하는 경우, 절대로 기능적인 면은 통합된 도구에 비해서 부족하지 않겠지만, 실제로는 접근성 등에 있어서 균질적이지 않아서, 어떤 도구는 사용하지만, 어떤 도구는 상대적으로 소외되어서 결과적으로 효율 차이가 발생하는 것으로 보인다.

Measurement

빌드 시스템 자체와는 별개로 흥미로웠던 것은 빌드 시스템의 각 요소에 대한 필요성을 실제 데이터로 증명하고, 빌드나 빌드 시스템의 개선을 위해서도 측정의 중요성을 지속적으로 강조하고 있다는 점이다. 즉,  ‘Cannot improve what we don’t measure’라는 모토인데, 엔지니어로서는 더 이상 공감하기 어려운 이야기라고 생각한다. 단기간의 개선은 직관이나 추측이 잘 먹힐지는 몰라도, 장기간에 걸친 개선에 있어서 측정은 필수적이다.

현실에서는 time-to-market 요구사항이나 엔지니어 개인의 취향, 심리적 상태와 같은 요소 때문에 측정이 희생되는 모습을 자주 보게 된다. 다소 공격적으로 얘기해서, 합리적인 trade-off를 통해 희생하거나, 다른 요소에 의해 제약 받지 않은 상태임에도 불구하고, 측정을 소홀히 하는 엔지니어는 엔지니어로서의 기본적인 소양이 부족한 것이 아닌가 생각을 해본다.