[정리] 실용주의 프로그래머 - 1. 실용주의 철학 (A Pragmatic Philosophy)

Tistory 태그: 실용주의 철학,프로그래밍 습관

Chapter 1. A Pragmatic Philosophy

 

직면한 문제 너머를 생각하며, 문제를 항상 더 큰 맥락에 놓으려 노력하고, 항상 더 큰 그림을 보려 한다. 그런데 어떻게(How) 도출할 것인가..

실용주의 프로그래밍은 실용주의 사고의 철학에서 뻗어 나온다. 이 장은 그 철학의 기본을 설정한다.

 

 

 

(1) 고양이가 내 소스코드를 삼켰어요.
: 실용주의 철학의 초석 중 하나는 자신과 자신의 행동에 책임을 지는 것이다. 자신의 능력에 대해 자부심을 가질 수 있지만 실수나 무지 같은 단점에 대해서도 정직해져야 한다.

책임지기
: 실수를 저지르거나 잘못된 판단을 내렸다면, 정직하게 인정하고 다른 방안을 제안하도록 노력하라. 다른 사람이나 다른 무언가를 비난하거나 변명을 만들어 내지 말라.


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


어설픈 변명을 늘어놓기 전에 그 변명꺼리를 없애도록 노력해 보라.

 

 

(2) 소프트웨어 엔트로피
: 소프트웨어의 무질서도가 증가할 때 프로그래머들은 이를 '소프트웨어의 부패' 라고 일컫는다.

오랜 기간 수리하지 않고 방치된 창문 하나가 거주자들에게 버려진 느낌을 스며들게 한다. 그래서 다른 창문이 하나 더 깨진다. 시간이 경과 할 수록 더 빠른 속도로 손상을 입기 시작한다. 반대로, 깨진 창문, 낙서, 기타 작은 위반 행위를 잘 단속했더니 중범죄가 줄었던 경우가 있다.

Tip 4. 깨진 창문을 내버려두지 말라. (엔트로피 법칙 or 유인 메커니즘)


발견하자마자 바로 고쳐라. 방치는 다른 어떤 요인보다도 부패를 더 가속시킨다. 엔트로피가 우리를 지배 하도록 내버려 두지 마라.
 
불끄기
: "나머지 코드가 전부 쓰레기니까 나도 그렇게 하지 뭐." 라는 사고로 빠져들지 마라. 집에 불이 났는데, 더러운 소방호스가 들어온다고 카펫을 굴려 말고 있지 말자.

 

 

(3) 돌멩이 수프와 삶은 개구리
: 돌멩이 수프 이야기는 책에 있으므로 각자 읽어보도록 하자(한 페이지 분량이므로 패스).  요는 군인들이 하나의 촉매로 작용해서 마을 사람들 스스로는 만들어 낼 수 없던 뭔가를 협동해 이룰 수 있도록 도왔다는 점이다. 일종의 시너지 효과인 셈이다.

간혹 “무엇을 해야 하는지, 어떻게 해야 하는지 정확히 아는 상황이 있다.” 전체 시스템이 눈 앞에 드러난다. 하지만, 일을 시작할 때부터, 뭔가가 지연되거나 위원회가 생기고, 예산 승인이 필요하고 점점 일은 복잡하게 된다(시작 피로, Start-up Fatigue). 바로 이때가 끓는 물에 돌멩이를 넣어야 할 때이다.

잘 만들어진 돌멩이를 보여주고, “만약 …를 추가하기만 하면 지금보다 더 나아지겠죠.” 라고 말하는 것이다. 물러나 앉아 우리가 애초에 원했던 그 기능을 추가해 달라고 그들이 부탁할 때까지 기다려라. 계속되는 성공에 합류하기란 쉽다. 그들에게 미래를 살짝 이라도 보여주면 그들은 원조를 위해 집결할 것 이다. (비젼을 보여라.)

 

Tip 5. 변화의 촉매가 되라.

 

반면 돌멩이 수프 이야기는 점진적인 속임수에 관한 이야기이기도 하다. 돌멩이에 집중하느라 세상의 나머지에 대해서는 까맣게 잊어버린다. 우리가 모르는 새 서서히 상황이 악화된다. 의욕과 팀 자체의 파괴는 종종 작은 것들의 누적에서 온다.

 

Tip 6. 큰 그림을 기억하라.

 

개구리를 잡아서 끓는 물 속에 넣으면 곧바로 튀어나와 버릴 거라고 생각되지만, 차가운 물에 개구리를 넣고 조금씩 물을 덥히면 개구리는 온도가 서서히 오르는 것을 감지하지 못할 것이고, 결국은 삶아질 때까지 그냥 그대로 있을 것이다.

그런 개구리처럼 되지 마라. 개인적으로 무엇을 하고 있는 가에만 정신을 쏟지 말고, 주변에서 무슨 일이 벌어지는지 지속적으로 살펴보라.

 

 

(4) 적당히 괜찮은 소프트웨어

: “적당히 괜찮은”은 너절하거나 형편없는 코드를 의미하지 않는다. 시스템이 성공하려면 사용자의 요구사항을 충족해야 한다. 단지 우리가 생산해 낸 것이 어느 정도면 적당히 괜찮은지를 결정하는 과정에서 사용자가 참가할 기회를 가져야 한다는 걸 말하고 있는 것이다.

 

타협과정에 사용자를 참여시켜라.

 

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

 

오늘의 훌륭한 소프트웨어는 많은 경우, 내일의 완벽한 소프트웨어보다 낫다. 사용자들에게 뭔가 직접 만져볼 수 있는 것을 일찍 준다면, 피드백을 통해 종국에는 더 나은 솔루션에 도달할 수 있을 것이다. (예광탄 참조)

 

언제 멈춰야 할지 알라.

: 프로그래밍은 그림 그리기와 유사하다. 언제 멈춰야 할지를 알지 못하면, 이 모든 작업을 망치게 될 것이다. 칠한 위에 덧칠하고, 세부묘사 위에 다시 세부묘사를 하다보면, 그림은 물감 속에서 사라진다.

완벽하게 훌륭한 프로그램을 과도하게 장식하거나 지나칠 정도로 다듬느라 망치지 말라. 완벽하지 않을 수도 있다. 걱정하지 마라. 완벽해지기란 불가능하다.

 

(5) 지식 포트폴리오
: 프로그래머에게 지식과 경험이야말로 가장 중요한 전문가적인 자산이다. 그러나 그것들은 불행히도 소진하는 자산(Expiring assets)이다. 여러분의 지식 가치가 점점 떨어짐에 따라, 회사나 클라이언트에 대한 여러분 자신의 가지 역시 떨어진다. 우리는 이런 일이 일어나는 걸 예방하고 싶다.

 

지식 포트폴리오 만들기

• 주기적인 투자
  : 주기적으로 지식 포트폴리오에 투자하라. 비록 소량일지라도 그 습관 자체가 금액의 합계만큼이나 중요하다.
• 다각화
  : 여러 가지를 알면 알수록 자신의 가치는 더욱 높아진다. 컴퓨터 분야의 지형은 빨리 변한다. 더 많은 기술에 익숙하다면, 변화에 더 잘 적응할 수 있을 것이다.
• 리스크 관리
  : 위험하지만 잠재적으로 보상이 높은 것에서 리스크가 낮고 보상도 낮은 것에 이르기까지 기술은 다양한 스펙트럼 위에 존재한다. 기술 달걀을 한 바구니에 모두 담지 마라.
• 싸게 사서 비싸게 팔기
  : 새롭게 떠오르는 기술이 인기를 끌기 전에 미리 알고 학습하는 것은 저평가된 주식을 찾아내는 것만큼이나 어려울 수 있지만, 이익 또한 그만큼 클 수 있다.
• 검토 및 재조정
  : 이 산업은 매우 동적이다. 지난달부터 탐구하기 시작한 인기 있는 기술이 지금에 와선 완전히 식어버릴지도 모른다.

이 모든 가이드라인 중에 제일 중요한 것은, 실행하기에 가장 간단한 것이다.

 

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

 

목표 설정 하기

• 매년 새로운 언어를 최소 하나는 배워라.
• 기술 서적을 분기마다 한 권씩 읽어라.
• 비 기술 서적도 읽어라.(심리학, 문화 인류학, 건축학, 경영학 관련 서적 등)
• 수업을 들어라.
• 지역 사용자 모임에 참여하라.
• 다른 환경에서 실험해보라.
• 요즘 흐름을 놓치지 마라.
• 인터넷을 이용하라.

 

학습의 기회

: 여러분이 답이 뭔지 전혀 알지 못한다면, 허물없이 인정하고 답을 찾는 것을 개인적인 도전으로 생각하라. (ex: 구루(guru) 에게 묻기, 서적 검색)

 이 모든 독서와 연구는 시간이 걸리고, 시간은 늘 부족한 자원이다. 늘 읽을 거리를 준비하라. (수불석권)

 

비판적 사고

: ‘비판적으로’ 생각하라! 상업주의의 힘을 절대 과소평가하지 마라. 단지 검색 엔진에서 첫 머리에 나온 결과라고 해서 그것이 최선이라는 의미는 아니며, 서점에서 어떤 책을 특별하게 취급한다고 해서 그것이 좋은 책이라는, 심지어 인기 있는 책이라는 의미는 아니다.

 

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

 

 

 

(6) 소통하라!
: 효과적인 소통 없이는 어떤 훌륭한 아이디어도 고아에 지나지 않는다. 저자는 다음과 같은 유용한 아이디어 목록을 제시하였다.

• 말하고 싶은 게 무언지 알아라.
  : 무엇을 말할지 미리 계획하라. 개요를 작성하라. 그리고 자문하라. “이게 내가 말하고자 하는 것을 잘 전달하는가?” 그렇게 될 때까지 다듬어라. 상황에 맞게 제대로 전달하기 위한 전략을 몇 개 세워라.
• 청중을 알아라.
  : 청중의 요구와 관심, 능력을 이해할 필요가 있다.
  
• 때를 골라라.
  : 청중이 무엇을 듣기 원하는지 이해하기 위해서는, 그들의 우선순위를 알아야 한다. 가끔 “…에 대해 이야기할 좋은 때일까?”라는 질문을 해보는 것만으로도 충분하다.
• 스타일을 골라라.
  : 전달하는 스타일이 청중에 어울리도록 조정하라. 때로는 간단하게, 때로는 폭넓은 한담을 원한다. 하지만, 누군가가 뭔가를 간명하게 설명해 달라고 말하는데, 그 설명을 대여섯 장 이하로 줄일 수 있는 방법이 없다면, 사실이 그렇다고 말하라. 이런 종류의 피드백 역시 의사소통의 한 가지 형태임을 기억하라.
• 멋져 보이게 하라.
  : 세세한 부분까지 신경 쓰고 잘 포장하라.
• 청중을 참여시켜라.
  : 가능하다면 문서 초고에 독자가 참여하도록 하라. 피드백을 받고 더 나은 문서를 만들어라.
• 청자(Listener)가 되어라.
  : 질문을 해서 사람들이 이야기를 하도록 북돋우거나, 여러분이 한 말을 그들이 요약하도록 하라. 회의를 대화로 바꾸면 생각을 좀 더 효과적으로 전달할 수 있을 것이다.
• 응답하라.
  : 늘 사람들에게 응답을 해주면 때때로 일어나는 실수에 대해 훨씬 더 관대해질 것이고, 여러분이 그 사항을 아직 잊지 않았다는 느낌을 줄 것이다.

 

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

 

 

 

첫 번째 챕터를 마치며..

: 요즘 부쩍 이 포스팅에 저작권 관련될 수 있겠다는 생각을 한다. 하지만 필자가 정리하는 이 목록들은 “실용주의 프로그래머”라는 책에 정말 작은 일부분임을 말해두고 싶다. 이와 관련된 포스팅을 읽다가 괜찮은 내용이라고 생각된다면, 꼭 사서 혹은 빌려서 읽어보시라는 권유를 하고싶다.