쉬운 것은 올바르다

10년 이상된 오래된 책이지만, 지금도 읽을 만한 가치가 있는 책입니다. Microsoft가 단지 운이 좋아서 성공한 것은 아니라는 것을 알 수 있습니다. 책을 읽다 보니, 회사의 이름과 철학이 일치한다는 것을 느낄 수 있었습니다. Agile 방법론과 유사한 점도 느낄 수 있었고요. 그런데 책이 지나치게 두껍다는 것이 아쉽습니다.

인상 깊은 구절

25쪽:

빠르게 변화하는 업계에서 쉽게 뒤쳐지기 쉬운 관료적 규칙이나 형식적 교육 프로그램 없이 현장에서 좀더 경험 있는 조직원에게서 일을 배운다.

26쪽:

특히 응용 프로그램 개발에 있어서는 고객의 반응까지 직접 조사한 상황에서 제품과 프로젝트를 디자인한다.

28쪽:

고객들을 길거리에서 무작위로 데리고 와서 사용자 시험을 하기도 한다.

28쪽:

거의 모든 팀들은 단일 구역에서 공통의 개발 도구를 사용하여 일을 한다.

30쪽:

다양한 종류의 소프트웨어에서 원하는 소비자들의 욕구를 모두 이해하기는 어렵기 때문에 미리 시스템을 계획하는 것은 불가능할 뿐 아니라 무모하기까지 하다. 게다가 하드웨어 기능이 빠르게 좋아지고 고객의 욕구도 변화하는 상황에서는 더욱 그렇다. 그러므로 제품을 완성시켜 가는 과정에서 가능한 많은 계획과 생산, 검증을 동시에 해가며 이 과정을 반복해 나간다. 가능하다면 제품 개발 과정에 고객들을 참여시키는 것이 좋다.

36쪽:

체계적인 틀이 없다면 복잡한 일을 수행할 수 없어요. 우리가 할 일은 가능한 이 틀을 안 보이게 하면서 개발자로 하여금 자유롭게 할 일을 하게 하는 거죠. 맨발로 하루 종일 걷는다고 해도 아무도 뭐라 하지 않아요. 사무실에 곰 인형을 두는 것도 자유입니다. 단지 5시까지 프로그램의 코드를 체크하지 않은 사람이 누구인가 하는 사실만이 중요합니다. 그는 제가 그의 사무실을 방문할 거라는 것을 알고 있을 겁니다.

40쪽:

많은 회사들은 사업과 전략에 대한 이해력과 상관없이 단지 관리적인 능력 하나만으로 사람을 고용하고 승진시킨다. 그러나 마이크로소프트는 사람을 뽑을 때 그 사람의 기술과 함께 그 기술을 사업화할 수 있느냐 하는 점을 우선적으로 고려한다.

45쪽:

가장 좋은 개발언어가 무엇인지 토론할 필요없이 우리는 단일한 언어를 쓰고 있습니다.

46쪽:

기술분야에 대한 지식이 없는 관리자를 채용하지 않습니다.

46쪽:

프로젝트가 끝나면 그것에 대해 해부를 한 후 오류의 출처를 밝히고 대처방안을 찾습니다.

57쪽:

크리스 피터즈가 지적하듯 게이츠의 신임을 얻기 위해서는 그의 의견에 이의를 제기할 수 있어야 한다. 다만 이런 이의의 배경이 명확해야 하며 기술적인 근거와 자료가 있어야 한다.

67쪽:

복잡한 제품에 오류가 발생하는 이유는 각 부분들이 총체적으로는 어떻게 작동되는지를 이해하지 못하기 때문이다

91쪽:

하지만 여전히 직급이나 보수가 개발자에게 편중되어 있어요. 만약 당신이 개발자라면 어떤 다른 부의 조직원보다 어깨에 더 힘이 들어갈 겁니다. 어쩔 수 없는 일이죠. 그건 우리의 기업 문화니까요. 기술 중심의 회사고 대부분의 중역들이 기술 분야에서 자란 사람들입니다.

91쪽:

특히 메이플즈는 IBM에 만연했던 타입의 기업 풍토, 즉 많은 내부 갈등이 존재하고 그룹들은 윗사람에게 나쁜 소식은 숨기는 것 같은 분위기를 없애기 위해 노력했다. 빌 게이츠 또한 나쁜 소식을 듣기를 싫어하고 몇몇 관리자들은 실수를 인정하기를 꺼려했다. 하지만 게이츠는 그에게 보고되지 않은 문제를 발견하게 되면 더욱 화를 낸다.

93쪽:

조직원들이 그들 나름대로의 일정을 짜게 하라.

93쪽:

언제든지 일어날 수 있는 예기치 못하는 일정 지연에 대비하여 완충기를 가져라.

93쪽:

변화의 가능성은 늘 있기 마련이므로 처음부터 완벽한 사양서를 작성하는 데 시간을 소비하지 말라.

93쪽:

기술이나 개발과정보다는 소비자 문제에 초점을 두라.

93쪽:

제가 마이크로소프트를 방문했을 때 무엇보다 인상적이었던 일은 관리구조 전반에 걸쳐 매우 뛰어난 전문가를 만날 수 있었다는 것이지요. 컴퓨터 업계에서 기술적인 능력을 갖춘 인물이 주요 관리직에 있는 경우는 그리 흔하지 않죠.

93쪽:

마이크로소프트가 지닌 힘의 일부는 관리자들로부터 중역들까지 매우 기술적으로 유능하다는 데 있어요. 관리자들도 기술 지식이 있어야 하며 리더들도 마찬가지로 프로그램 코드를 작성하고 그들 조직원들이 개발하고 있는 제품에 무슨 문제가 생기면 해결할 수 있어야 합니다.

93 ~ 94쪽:

관리자들은 임원이 된 후에도 계속해서 기술적인 일을 해야 한다. 워드나 윈도우 NT 등을 개발하는 큰 조직의 개발 관리자도 근무 중 코드 작성에 많은 시간을 보낸다. 이렇게 하는 근본적인 이유는 관리자가 결정을 바르게 내리고 그룹 내에서 생긴 문제를 해결하기 위해서는 기술분야도 제대로 이해하고 있어야 된다는 것이다.

97 ~ 98쪽:

조직원의 자질은 헤아릴 수 없을 정도로 중요하죠. 우리들은 지나칠 정도로 MIT와 스탠포드의 최우수 학생들을 데려옵니다.

99쪽:

저는 사람을 고용하고 규칙을 정해서 조직을 운영하려고 하는 어리석은 회사를 많이 보았습니다. 문제의 일부는 규칙으로써 해결할 수 있지만, 그 문제의 보다 근본적인 원인은 규칙의 결여에 있다기 보다는 많은 규칙을 필요로 하는 사람들을 뽑는 데 있어요.

106쪽:

특히 마이크로소프트는 PC 소프트웨어 사업의 상업적인 측면까지도 이해할 수 있는 능력 있는 '수퍼 프로그래머'를 찾고 있다. 이런 기술인력은 다른 회사 개발자와 비교해 볼 때 기술적인 능력은 비슷할지 몰라도 시장성 있는 기능과 제품을 개발하는 데 더욱 창조적이며, 기술 능력을 사업화하는 데 훨씬 능숙하다.

129쪽:

인터뷰에서 중요한 관건은 추상적인 의미에서 그 사람이 얼마나 영리한가 하는 것이다. 즉 다시 말해 코드나 테스트, 마케팅 같은 전문 영역에 대해 단순히 얼마나 알고 있느냐를 측정하지는 않는다(게이츠는 채용시 네 가지 중요한 자격 요건을 보는데, 야망, IQ, 기술적인 전문성, 사업 판단력이 그것들이며 이중 IQ를 제일 중요하게 본다).

137쪽:

단순히 프로그래밍을 위한 프로그래밍에 관심을 가지는 것이 아니라 회사와 자신을 위해 돈이 되는, 즉 도전하는 자세로 제품출하를 위해 노력하는 사람을 개발자로 채용한다.

145쪽:

마이크로소프트는 연수 프로그램이나 형식적인 규칙이나 절차규정, 혹은 상세한 제품 설명서 작성에 많은 돈을 투자하기보다 스스로의 힘으로 일을 해낼 수 있는 사람을 고용하려고 노력했다. 신입사원 연수는 경험이 많은 조직원의 몫이다. 팀 리더나 특정 분야의 전문가, 혹은 공식적으로 지정된 조언자가 자기가 맡은 일 외에도 신입사원 교육의 책임을 지게 된다.

167쪽:

다른 분야의 조직원들은 개발자에 대해 거의 질투에 가까운 분노를 표현하죠. 데리 헤븐즈(Dary Havens)는 윈도우 NT 그룹의 개발자 리더 중의 한 사람이죠. 데리는 9대의 포르셰를 가지고 있죠.

287쪽:

우리가 제품을 계획된 날짜에 최종적으로 출하할 수 있는 비결은 개발일정에 완충기간을 넣어두기 때문입니다. 그 완충기간은 일이 느리게 진행되거나 잘못되는 경우를 대비한 것이 아니라, 예기치 않게 일어날 수 있는 일들에 대비하여 충분한 기간을 준비해 놓는 것이죠.

296쪽:

우리들은 각 제품을 개발할 때 원하는 기능의 3분의 2는 리스트에서 뺍니다.

344쪽:

'해커' 전통에 어긋나지 않게 API 문서화 외에 마이크로소프트는 그 제품들의 구조에 대해서 많은 기록 문서를 만들어내지 않는다.

345쪽:

크리스 피터즈는 '개발자가 할 일은 우리가 파는 코드를 작성하는 것이지, 상위 수준의 설계 문건들을 작성하는데 시간을 보내는 것이 아니기' 때문에 기록된 구조적 문건이 거의 없다고 설명했다.

345쪽:

소스 코드와는 별개인 문서를 갖는 어떤 방법론이 있다. 만약 당신이 문건작성에 많은 시간을 소비하여 대단한 효율을 얻으려고 생각하면 그것은 어리석은 것이다. 자연에 존재하는 상당히 고착된 많은 규칙들은 어리석은 것들이 많다. 위대한 설계를 만들고 위대한 소프트웨어를 만드는 데 기여하는 것들은 많은 실용적인 것들이다. 하나의 문서 단하나. 그것은 바로 소스코드이다. 그것이 당신이 가는 단 한 곳이다. 당신은 거기서 모든 것을 배우고 그곳에서 모든 것을 알게 된다.

359쪽:

일주일 이상 걸리는 일정을 세운 사람은 분명히 그 일에 대한 생각을 충분하게 하지 않고 계획을 세웠다는 것을 증명합니다.

363쪽:

명심할 것은 아이디어가 부족한 것이 아니라 아이디어가 너무 많은 것이 늘 문제죠.

380쪽:

마이크로소프트에는 규칙이란 것이 거의 없지만, 모든 프로젝트에서 빈번히 build를 실행한다는 규칙만은 엄격히 지켜지고 있다.

394쪽:

사실 크리스 피터즈는 코드가 너무 금방 낙후되기 때문에 마이크로소프트는 재이용이 가능한 코드를 작성하는 것에 그다지 중점을 두지 않는다는 것을 인정했다.

403쪽:

마이크로소프트의 관리자는 본사에서 일하는 직원을 지원하기 위해 설비투자를 아끼지 않는다. 하계 연수생과 간혹 신입사원의 경우 예외도 있으나 거의 전사원에게 개인 사무실이 주어진다. 건물은 X자형이라서 상당수의 개인 사무실에 창문이 있다.

405쪽:

따라서 최종 사용자에게 제품을 설명할 때 개발의 어느 방법을 사용했다든지, 어느 방법을 사용하지 않았다든지에 대해 떠벌릴 이유가 없다.

407쪽:

그러나 시스템 프로젝트에서 헝가리식 표기는 그렇게 많이 사용되지 않는다. 이것은 아마 헝가리식 표기와 찰즈 시모니가 시스템 부문의 일부가 되지 못했기 때문일 것이다. 로우 페라졸리는 이 표기법의 장점에 대해 너무 깊이 토론하고 싶지 않다고 말하면서도 자신의 우려와 그 팀의 다른 개발자의 경험에 대해 이렇게 이야기하고 있다. "헝가리식 표기는 개발자에게 방해가 되기 때문에 코드를 읽기도 하고 보수하는 데에는 별 도움이 되지 않는다."

434쪽:

지속적인 테스트를 행하는 또 다른 중요한 방법은 신제품이나 개발중인 제품을 사내에서 가능한 빨리 사용해 보는 것이다. 마이크로소프트는 이러한 방법의 중요성을 확신하고 있어, 때때로 이러한 사내 사용 관행을 '자신이 만든 개먹이를 먹어본다'(6장 참조)라 부르기도 한다.

435쪽:

그러나 6장에서 더 논의할 것이지만 self-hosting과 마이크로스프트 직원을 이용한 사내 테스트에는 한계가 있는데, 이들이 항상 가장 대표적인 고객층을 반영하지는 않는다는 것이다. 빌 게이츠도 이 점을 인정한다. "마이크로소프트가 모든 마이크로소프트 제품의 가장 전형적인 사용자는 아니다. 따라서 이들에게 테스트할 매우 중요한 것을 놓칠 수 있다."

487쪽:

지금까지의 나의 작업 행로를 돌이켜보면 개발자들이 고객들이 사용하는 것보다 한 세대 앞선 하드웨어를 사용하여 작업하는 프로젝트는 나중에 모두 성능에 문제가 발생하였다.

525쪽:

윈도우 3.0이 그때 막 출하되었고 그것은 아주 대성공이어서 어쩔 줄을 몰라 했다. 그래서 나는 내 개발팀 전원을 2주일 간 지원 부문에 보내 그들을 도와주도록 하였다. 이러한 조치로 개발자는 고객의 요구에 아주 민감해졌다. 그것이 바로 나의 철학이다. 즉 개발자를 포함한 모든 부문의 요원들이 고객의 시각을 갖도록 하는 것이다. 고객이 우리의 주인이라는 것을 기억하는 것, 우리가 성공할 수 있는 유일한 요인은 고객이 우리의 제품을 좋아해야 하는 것이다.

536쪽:

피터즈는 유용성 실험소에서 사용자를 관찰하여 얻은 교훈을 열거하였다. 하나는 개발자의 상식이 항상 이해하기 쉬운 제품을 만들어내지는 않는다는 것이다.

537쪽:

피터즈가 얻게 된 두 번째 교훈은 대부분의 사람들이 메뉴얼을 이용하지 않기 때문에 대개 불필요하다는 것이다.

537쪽:

당신은 사람들이 매뉴얼 없이 작동을 시도해 본다는 사실을 인정해야 한다.

563쪽:

마이크로소프트의 경영진은 기술이 뛰어나다고 해서 그 기술이 반드시 값어치가 있다고 생각하지 않으며, 규정이나 절차를 제품 출하보다 더 중요시하지도 않는다. 빌 게이츠와 다른 마이크로소프트의 임원들이 가장 중요하게 생각하는 것은 이익 창출이다.