목적: Software engineering의 이해

주(註): 올 초, 이 책을 접하고 요 근래 다시금 읽고 있습니다. 체계적으로 읽기 위해 요점 정리를 하고는 있지만, 사실 요점 정리가 필요 없을 만큼 체계적이며 짜임새가 탄탄한 책이라고 생각합니다. 책 소개대로 바이블이라 할만 한 것 같습니다. 비효율적이기 보다는 효율적이며 영웅 프로그래머 주도이기보다는 시스템 주도의 개발을 원하신다면 일독을 권합니다.

1장. 실용주의 철학A PRAGMATIC PHILOSOPHY
　실용주의 프로그래머는 무엇이 다른가? 우리는 태도와 스타일 그리고 문제와 해법에 접근하는 철학에 차이가 있다고 생각한다. 그들은 직면한 문제 너머를 생각하며, 문제를 항상 더 큰 맥락에 놓으려 노력하고, 항상 더 큰 그림을 보려 한다. 어째건 이런 더 큰 맥락 없이 도대체 어떻게 실용적일 수 있겠는가? 어떻게 똑똑한 절충안을 내고, 정확한 사실에 근거한 결정을 내릴 수 있겠는가?

1.1. 고양이가 내 소스를 삼켰어요
　책임은 적극적으로 동의하는 것이다. 뭔가 제대로 처리하겠다고 확약을 하더라도, 모든 면에서 꼭 직접적인 통제가 가능하지는 않다. 여러분에겐 불가능하거나 위험요소가 너무 큰 상황에 대해서는 책임을 지지 않을 권리가 있다. 자신의 윤리의식과 판단에 따라 결정해야 할 것이다.
　결과에 대한 책임을 받아들인다면, 그 결과에 대해 나중에 해명할 것을 예상해야 한다. (누구나 그렇듯이) 실수를 저지르거나 잘못된 판단을 내렸다면, 정직하게 인정하고 다른 방안을 제안하도록 노력하라.
　다른 사람이나 다른 무언가를 비난하거나 변명을 만들어 내지 말라. 모든 문제가 벤더, 프로그래밍 언어, 경영진 혹은 동료 때문이라고 떠넘기지 말라. 이들이 모두 한 몫씩 했을 수 있겠지만 변명이 아닌 해결안을 제공하는 것은 여러분에게 달려 있다.

3. 어설픈 변명을 만들지 말고 대안을 제시하라.

1.2. 소프트웨어 엔트로피entropy
　‘깨진 창문’을 고치지 않은 채로 내버려 두지 마라. (1) 발견하자마자 바로 고쳐라. (2) 적절히 고칠 시간이 충분하지 않다면 판자로 덮는 것만이라도 하라. 불쾌한 코드를 주석처리 하거나, 가짜dummy 데이터로 대치해 놓거나 하라. 더 이상의 손상을 예방하기 위해 어떤 조치든 취하고 현 상황을 잘 관리하고 있다는 것을 보여 줘라.
　깨진 창문 하나는 내리막길로 가는 첫걸음이다. 깨진 창문이 꽤 있는 프로젝트를 한다면, “나머지 코드가 전부 쓰레기니까 나도 그렇게 하지 뭐.”라는 사고로 빠져들기 너무도 쉽다. 이 시점까지 프로젝트가 괜찮았다면 큰 상관은 없다. 하지만 실험에서는 일단 창문이 깨지기 시작하면 소프트웨어는 급속도로 부패 되었다.

4. 깨진 창문을 내버려두지 말라.

1.3. 돌멩이 수프와 삶은 개구리
　무엇을 해야 하는지, 어떻게 해야 하는지 정확히 아는 상황이 있다. 여러분은 그 시스템이 옳다는 걸 안다. 하지만 일을 착수하려고 허락을 구하는 때부터, 뭔가가 지연되거나 사람들이 멍한 눈으로 여러분을 바라본다. 점점 일들이 복잡해지기 시작한다. 모든 사람이 각자의 자원을 지키려고 할 것이다. 때때로 이걸 ‘시작 피로start-up fatigue’라고 부른다.
　돌멩이 수프를 내놔야 할 때다. 큰 무리 없이 요구할 수 있을 만한 것을 찾아내고 그걸 잘 개발해라. 일단 되면, 사람들에게 보여주고 그들이 경탄하게 하라. 계속되는 성공에 합류하기란 쉽다. 그들에게 미래를 조금이라도 보여주면 그들은 원조를 위해 집결할 것이다.

5. 변화의 촉매가 되라.

　사람들은 개구리를 잡아서 끓는 물 속에 넣으면 곧바로 튀어나와 버릴 거라고 한다. 그렇지만 차가운 물이 든 냄비 속에 개구리를 넣고 조금씩 물을 덥히면 개구리는 온도가 서서히 오르는 것을 감지하지 못할 것이고, 결국은 삶아질 때까지 그냥 그대로 있을 것이다.
　앞서 말한 깨진 창문 이론과 다른 점은 (1) 깨진 창문은 다른 누구도 주의를 기울이지 않는다면 사람들은 엔트로피에 대항하지 않는 다는 것이며, (2) 삶은 개구리 이론은 단지 변화를 감지하지 못하는 것이다.
　그런 개구리처럼 되지 마라. 큰 그림에 늘 주의를 기울여라. 개인적으로 무엇을 하고 있는가에 만 정신을 쏟지 말고, 주변에서 무슨 일이 벌어지는지 지속적으로 살펴보라.

6. 큰 그림을 기억하라.

1.4. 적당히 괜찮은 소프트웨어
　‘적당히 괜찮은’이라는 문구는 너절하거나 형편없는 코드를 의미하지 않는다. 시스템이 성공하려면 사용자의 요구사항을 충족해야 한다. 단지 여러분이 생산해 낸 것이 어느 정도면 괜찮은지를 결정하는 과정에 사용자가 참가할 기회를 가져야 한다는 걸 말하는 것이다.

타협과정에 사용자를 참여시켜라
　여러분이 만드는 시스템의 범위scope와 품질은 해당 시스템 요구사항의 일부로 명기 되어야 한다.
　우리는 적당한 타협이 필요한 상황에 자주 처하게 된다. 놀랍게도 많은 사용자들은 완벽한 버전을 위해 일 년을 기다리느니 차라리 오늘 당장 좀 불편한 소프트웨어를 사용하고 싶어 한다. 오늘의 훌륭한 소프트웨어는 많은 경우, 내일의 완벽한 소프트웨어 보다 낫다. 사용자들에게 뭔가 직접 만져볼 수 있는 것을 일찍 준다면, 피드백을 통해 종국에는 더 나은 솔루션에 도달할 수 있을 것이다.

7. 품질을 요구사항으로 만들어라.

언제 멈춰야 할지 알라
　예술가들은 여러분에게 언제 멈춰야 할지를 알지 못하면 이 모든 고된 작업을 망치게 될 거라고 말해 준다. 칠한 위에 덧칠하고, 세부묘사 위에 다시 세부묘사를 하다 보면, 그림은 물감 속에서 사라진다.
완벽하게 훌륭한 프로그램을 지나칠 정도로 다듬느라 망치지 말라. 그냥 넘어가고 코드가 현재 상태에서 한동안은 그대로 있도록 놓아두라. 완벽하지 않을 수도 있다. 걱정하지 마라. 완벽해지기란 불가능하다.

1.5. 지식 포트폴리오
　여러분의 지식과 경험이야 말로 가장 중요한 전문가적 자산이다. 하지만, 그것들은 소진하는 자산expiring assets이다. 새로운 기술, 언어, 환경이 개발됨에 따라 지식은 옛 것이 된다. 변화하는 시장 역시 여러분의 경험을 퇴물이나 별 소용없는 것으로 만들 수 있다. 웹-년이 흘러가는 속도를 볼 때, 이런 것들은 꽤 빨리 일어날 수 있다.
　여러분의 지식 가치가 점점 떨어짐에 따라, 회사나 클라이언트에 대한 여러분 자신의 가치 역시 떨어진다. 우리는 이런 일이 일어나는 걸 예방하고 싶다.

포트폴리오 만들기

• 주기적인 투자 자신의 지식 포트폴리오에 주기적으로 투자해야한다.
• 다각화 여러 가지를 알면 알수록 자신의 가치는 더욱 높아진다.
• 리스크 관리 여러분의 기술 달걀을 한 바구니에 모두 담지 마라.
• 싸게 사서 비싸게 팔기 새롭게 떠오르는 기술이 인기를 끌기 전에 미리 알고 학습하는 것은 어려울 수 있지만, 이익 또한 그만큼 클 수 있다.
• 검토 및 재조정 지난달부터 탐구하기 시작한 인기 있는 기술이 지금에 와선 완전히 식어버릴지도 모른다. 한동안 사용하지 않았던 데이터베이스 기술을 복습해야 할 필요가 생길지도 모르겠다.

8. 지식 포트폴리오에 주기적으로 투자하라.

목표

• 매년 새로운 언어를 최소 하나는 배워라
• 기술 서적을 분기마다 한 권씩 읽어라
• 비 기술 서적도 읽어라
• 수업을 들어라
• 지역 사용자 모임에 참여하라
• 다른 환경에서 실험해보라
• 요즘 흐름을 놓치지 마라
• 인터넷을 이용하라

비판적 사고
　마지막으로 중요한 점은 읽거나 듣는 것에 대해 ‘비판적으로’ 생각하는 것이다. 자신의 포트폴리오에 있는 지식이 정확하고, 벤더나 매체의 과대광고에 흔들림 없도록 확실히 해야 할 필요가 있다. 자신의 도그마dogma가 유일한 답이라고 주장하는 열광자들을 주의하라. 그것은 여러분과 여러분의 프로젝트에 적용될 수도 있고, 안 될 수도 있다.
　상업주의의 힘을 절대 과소평가하지 마라. 단지 웹 검색 엔진에서 첫 머리에 나온 결과라고 해서 그것이 최선이라는 의미는 아니다. 콘텐트 제공자가 돈을 지불했을 수 있다. 서점에서 어떤 책을 특별하게 취급한다고 해서 그것이 좋은 책이라는 의미는 아니다. 누군가 좋은 자리를 차지하려고 돈을 지불했을 수 있다.

9. 읽고 듣는 것을 비판적으로 분석하라.

1.6. 소통하라!
　뭘 가졌느냐 만이 아니라 그걸 어떻게 포장하느냐도 중요하다. 최고의 아이디어, 최상의 코드 혹은 가장 실용주의적인 사고 등이 있다고 해도 다른 사람들과 소통할 수 없다면 그것들은 궁극적으로 아무 효용이 없다. 효과적인 소통 없이는 어떤 훌륭한 아이디어도 고아에 지나지 않는다.

10. 무엇을 말하는가와 어떻게 말하는가 모두 중요하다.

• 말하고 싶은 게 무엇인지 알아라.
• 청중을 알아라
  WISDOM – 청중 이해하기
  무엇(What)을 배우길 원하는가?
  말하려는 것에서 그들이 관심(interest) 있어 하는 건 무엇인가?
  얼마나 소양(sophisticated)이 있는가?
  어느 정도의 구체적인(detail) 내용을 원하는가?
  누가 정보를 소유(owe)하길 원하는가?
  그들이 경청하도록 동기(motive)를 주려면 어떻게 해야 할까?
• (이야기할) 때를 골라라.
• (청중에 맞게 전달하는) 스타일을 골라라.
• (문서를) 멋져 보이게 하라.
• (문서 초고에) 청중을 참여시켜라.
• 청자listener가 되어라.
• 응답하라.

출처
인사이트 – 앤드류 헌트, 데이비드 토머스의 실용주의 프로그래머The Pragmatic Programmer