이하의 글은 2011년에 쓴 것입니다. 오래된 글인 만큼, 현재의 생각과 전혀 다른 내용도 많이 포함되어 있고, 당시와는 상황이 많이 달라진 점도 있습니다. 또한, 그 당시에 잘못 알려졌던 정보도 포함되어 있을 수 있습니다. 어찌됐든 저는 제 오래된 글이 회자되는 것을 저어합니다. 읽기에 앞서 양해를 부탁드립니다.
Hacker Entropy
모든 IT 기업에는 (내가 임의로 이름지은) 해커1 엔트로피(hacker entropy) 법칙이 적용되는 듯하다. 일단 해커라는 족속의 특징을 나열해보자.
- 해커는 가만히 있어도 쉽게 업무에서 지루함2을 찾아낸다.
- 해커는 자신이 생각하기에 멍청하게 여겨지는 업무를 하기를 싫어한다.
- 해커는 멍청한 사람이나 그런 사람과의 협업을 싫어한다.
- 해커는 멍청한 사람이 만들어놓은 한뭉텅이의 멍청하고 깨지기 쉬운(fragile) 코드더미를 싫어한다.
따라서 해커는 매우 빠른 속도로 자신이 속한 회사에 정을 떨어뜨리고 회사의 모든 시스템이 잘못된 레거시라고 여기게 된다. 그리고 대부분의 경우 그건 사회적인 이유로 개선 불가능하다고 결론짓는다. 그래서 회사를 나가거나 자신의 능력을 전혀 발휘하지 않게 된다.
이는 모든 회사에서 아무런 인위적인 조작
을 하지 않을 경우 자연스럽게 생기는 현상으로, 어찌보면 회사의 문제라기 보다는 해커들의 특성에 기인한 문제이다. 회사는 유능한 해커들을 부리고 싶다면 이러한 엔트로피 법칙을 거스르려 노력해야 한다. 이를 거스르는 방법을 뭉뜽그려 말하면 다음과 같다.
- 해커들이 지루해하는 일을 스스로 최적화하도록 냅둘 뿐만 아니라, 그것을 업무로 강제한다. (해커들은 비생산적인 현상을 지루해하므로 회사의 생산성은 단기적으로 낮아질 수도 있으나 장기적으로 크게 높아질 것이다.)
- 해커들이 싫어하는 멍청한 사람들을 회사에 들여놓지 않는다.
- 반복해서, 멍청한 사람들이 멍청한 코드를 만드는 것으로 해커들을 방해하여 생산성을 떨어뜨리지 못하도록, 멍청한 사람들을 회사에 들여놓지 않는다.
Google은 정말 뛰어난 사람이 아니면 받지를 않는다고 한다. 뛰어난지 아닌지 헷갈리면 받지 않는 것이다. (즉, false negative를 감수해서라도 false positive를 차단한다.) 뛰어난 사람이 업무 생산성을 높이는 것이 아니다. 뛰어나지 않은 사람이 생산성을 낮추는 것이다. 팀의 역량은 구성원 생산성의 합집합 혹은 평균이 아니라, 거의 항상 교집합에 수렴하는 듯하다. 뛰어난 해커 9명과 멍청한 사람 하나가 있으면 생산성은 멍청한 사람이 낼 수 있는 최대 퍼포먼스에 가깝게 맞춰지는 것이다. 비약이라고 생각할 수 있지만 이는 심리적인 효과 때문에 실제로 일어나는 일이다.
깨진 유리창 법칙이 있다. 빌딩에 유리창 하나가 깨지면, 그 뒤로는 모든 유리창이 빠른 속도로 깨지기 시작한다는 이야기다. 누가 바닥에 쓰레기를 버리면 모두들 그곳이 쓰레기를 버리는 곳이라고 생각하고 쓰레기가 쌓이게 된다. 해커들은 남이 쓰레기 같은 코드를 작성하면 이 시스템의 수준이 쓰레기라고 생각하여 딱 그 정도 수준의 코드로 시스템의 다른 부분을 채우기 시작한다—그 코드는 자신의 코드가 아니며, 그 코드가 더러운 이유도 자신 때문이 아니라고 생각하면서.
게다가 해커들은 대부분 대화를 통해 상황을 개선하려는 시도에 대해 남들보다 큰 용기를 필요로 하기 때문에 대체로 잘못된 상황을 마주해도 쉽게 반발하지 못하며 스스로 생각하기에 멍청한 방법을 따르는 편이며, 반발한다 해도 멍청한 방법을 제시한 당사자 입장에서는 그러한 반발이 너무 까다로운 방식
으로 비춰지는 것 이상의 효과가 없기 때문에 해커만 비사회적인 구성원으로 여겨지기 십상이다.
두루뭉실하게만 말하지 말고 구체적인 예를 들어보자. 구성원이 VCS를 이용하지 않고 있었고 해커가 용기를 내어 DVCS를 쓰자고 제안한다. 비해커는 그러한 제안을 듣고 왜 이런 쓸데없이 복잡한 시스템을 도입해야 하는지 이해하지 못하고 소극적으로 대응한다. 행여 버전 관리를 해야 한다는 것은 옳은 말이나 VCS는 복잡하므로 버전별 스냅샷을 타볼 아카이브로 매일 저장합시다
와 같은 소리가 나온다거나 하면, 해커는 매우 실망하며 그 즉시 이직이나 자기 자신이 세울 스타트업 궁리를 시작하게 된다. 예로 든 VCS 도입 이야기는 매우 낮은 수준의 이야기이지만, 실제로 소프트웨어의 디자인 전반에 대해 이러한 멍청한 결정들이 우리 주변에서 매우 자주 일어나곤 한다.
내가 실무 경험이 그리 많은 것은 아니지만, 내 경험상 해커가 아닌 사람을 해커로 만드는 것은 매우 큰 비용이 든다. 특히 정신적인 비용이 큰 것 같다. 특히 한 사람을 고치는 게 아니라 팀을 바꾸는 것은 마음의 상처를 단단히 각오해야 한다. (그리고 그런 시도는 대개 실패한다.) 해커가 그렇게까지 해서 팀에 남을 이유가 크지 않다. 대부분의 해커는 이런 이유로 팀에 정을 붙이지 못한다. (그리고 똑똑한 사람들이 모여 있는 오픈 소스 프로젝트의 구성원과 IRC에서 대화하며 하루의 스트레스를 풀기도 한다. 제길 우리 회사에서는 CI 같은 것 근처에도 가질 않아요! 중간에 삽입을 해야 하는데 자꾸 링크드 리스트가 메모리 파편화가 심하니 벡터만 쓰라고 강요해요! predicate function이 전역 변수에 접근해서 deterministic하지 않아요! 엉엉!
하면서…)
만약 내가 스타트업을 하게 된다면 적어도 나보다 잘하는 사람들을 찾거나, 그런 사람을 찾지 못한다면 혼자서 할 수 있을 정도의 비즈니스 이상으로 규모를 키우지 않을 것이다.