전공 관련 서적을 빌리러 학교 도서관에 갔지만 그 책을 찾을 수 없었습니다. 그래서 이왕 도서관에 들린 겸 해서 신간 쪽을 보다 얇고 재미있게 읽을 만한 책이 있어서 빌려 보게 되었습니다.

 책은 양장본이고 매우 얇아서 한자리에서 끝까지 다 읽을 수 있을 만큼 얇았습니다. 내용은 회사에서 일어나는 낭비에 대한 내용을 정리해 두었다. 개인적인 일상생활에서는 자신의 돈을 쓴다는 생각 때문에 절약을 하는 습관이 쉽게 몸에 배여 있겠지만, 회사에서 생활하다 보면 절약에 대한 습관이 들지 않고, 예전부터 해왔던 관례나 습관 때문에 낭비가 아무렇지 않게 나타나는 경우가 많을 것 같습니다.
 
  무엇보다도 회사는 업무나 생산 시설 등에 체계적인 방법이 이미 모두 구축되어 있습니다. 이러한 내용에 대한 변화를 제안하는 것은 회사의 권위에 도전한다는 느낌도 많이 받을 것 같습니다. 그래서 비효율적인 방법들이 변화 되지 않고 계속 남아 있게 되는 거겠죠.

  일반 생활에서의 절약 습관보다는 회사 내에서 어떻게 절약을 실천할 수 있을까에 대한 구체적 내용입니다. 누구나 생각할 수 있는 너무 간단한 내용이지만, 그런 생각이 쉽게 떠오르지 않고, 작다고 넘어가버리는 내용들이 많습니다. 작은 기업을 운영하는 사람들부터 큰 회사를 운영하는 사람들 모두에게 유용하리라 생각됩니다.

  저랑은 아직은 상관없는 내용이기는 하지만 학업에 비효율적인 것들이 없나 다시 한번 생각 해봐야겠습니다. 부모님 용돈 받아쓰는데, 습관 때문에 아무렇지 않게 나가는 비용이 아마도 많이 있을 듯하네요.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

왜 나는 눈앞의 고릴라를 못 보았을까?
Did you spot the gorilla? : how to recognise the hidden opportunities  
 
리처드 와이즈먼| 박종하 역| 세종서적| 2005.11.15 | 152p | ISBN : 8984072060 

만나기로 약속되어 있던 후배가 조금 늦을꺼라고 하기에 도서관에서 책보면서 기다리려고 도서관에 갔었다.

몇 권에 책을 보다가 제목에 끌려서 앉아서 보고 있다가 빌려 왔다. 그 후배가 많이 늦어버려 한자리에서 다 읽어 버린 책이였다.

뭔가 내용이 더 나올 것 같은 느낌 때문에 끝까지 보게 되었지만 실망스러웠다.

고릴라 이야기는 많이들 알 고 있을것이다. 하나에 집중하다 보면 눈앞에 고릴라가 지나가더라도 그 것을 인식 하지 못하는 수가 있다는 것 이다.

책의 내용은 그와 같이 자신에게 나타난 행운을 잡지 못하는 이유가 하나에 집중해서 보고 열린 개방적 사고를 하지 못해 불운하다는 것이다.

불운한게 자신의 인지 능력 때문이라는 것은 너무 억지스럽게 끼워 맞춘 것 같았다. 처음 부터 끝까지 그런 이야기로 책을 만들었다.

책의 내용이 얇아 금방 읽을 수 있기에 다 읽었지, 아마 조금만 더 길었으면 중간에 그만 봤을만한 책이다. 요근래에 읽은 책 중에서 가장 맘에 안드는 책 중에 하나이다.

고릴라 이야기를 모른다면 한 번쯤 흥미꺼리로 읽어 볼만하긴 한 책이다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

기후 변동 Atmosphere, climate, and change 
 
토마스 그레텔| 김경렬외 역| 사이언스북스| 1999.08.01 | 234p | ISBN : 8983710365 

학교에서 공대생의 책 읽기를 장려하기 위한 부경 북 클럽 지원 프로그램을 통해 처음으로 읽게된 책이다.

도서관에서 책을 빌려 보았을때 출판일에 비해 매우 낡아 있었다. Hard-cover 였는데 이렇게 낡은것을 보면, 아마도 매우 많은 사람이 빌려 본 것 같다. 아마 환경이나 기후 관련 전공 사람들이 많이 빌려보았거나, 교양 과목 책으로 빌려 본게 아닐까 생각 된다.

금뱅 네이버에서 책 정보를 찾아 보니 저자가 노벨상을 수상한 환경 과학자라고 나와 있다.

기후란 몇 십년 동의 긴 기간 동안의 평균 적인 기상상태를 말한다. 이 책에서는 지구가 생겨난 처음 부터 지금까지의 기후 변동에 대해 소개 하고 있다. 또한 미래의 기후 변동에 대한 예측을 해보면서 책이 끝난다.

가볍게 읽기는 약간 무리가 있는책 이였다. 전공 입문서 수준의 책으로 많은 과학 용어와 화학실들이 포함되어 있어 어렵게 느껴 졌다.

지구는 계속해서 기후 변동을 해왔다. 그 원인에 대해서 아직 우리가 알지 못하는 내용도 많이 있다. 현재도 온난화로인해 혹한,혹서,폭설 등 많은 기상 이변들이 나타나고있고, 불안정한 상태가 많이 관측 된다.

이런 지구의 기후 변동이 자연 스러운 과정일지 아니면 인위적인 오염의 인한 것인지 확실하지는 않지만, 기후 변동은 일정 임계점을 스스로 안정적 상태로 돌아가려는 힘을 넘어서버리면 더 이상 손을 쓸 수 없게 되고 생명이 살 수 있는 상태로 돌아 갈수 없게 될지도 모른다.

어떤 이유인지는 모르지만, 지구 온난화가 되고 있는 것은 확실하고 이것이 인간에게 좋지 않은 영향을 주고 있다. 임계점을 넘어 회복 불가능한 상태가 오지 않도록 막아야 한다.

내 생각에는 이런 전 세계적 문제의 인간이 잘 대체할 수 없을 것 같다. 화석 연료가 바닥 나지 않는 이상은 온난화문제 해결이 어려울 것 같다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

랜스 암스트롱이라는 자전거 선수에 대한 에세이다. 젊은 시절 그는 그저 자전거를 타고 달리는 것이 좋아 자전거 선수가 되게 된다.
그때는 성숙하지 못해서 이기적이고, 그냥 힘을 발산하는 것을 억누르지 못하고, 그저 패달만을 밟았다.

코치가 마지막까지 기다렸다가 속도를 올려도 된다고 계속 해서 말했지만, 그는 죽을 힘을 다해 패달을 밟고 더이상 전진 할 수 없을때 까지 패달을 밟았다.

선수생활을 하던중 젋은 나이에 그는 고환암을 선고 받게 되고, 선수 생활을 물론 생명을 유지 할수 있을지 조차 확신할 수 없는 상태였다. 그의 생존 확율은 3%였다.

투병생활을 하게되면서 그는 자기 주위에 소중한 사람들이 있고 자신을 도와주고 있다는 사실을 깨닫기 시작한다. 그의 어머니를 비롯해 그의 아내, 친구, 동료들 모두 그를 진심으로 도와 주고있다는 사실을 그제서야 알게 된 것이다.

자기가 잘나서 자기의 능력이 뛰어나서 지금껏 내가 잘되고 있다는 생각을 가지고 있던 그는 조금씩 변해가기 시작한다.  자기 자신이 정말 강한 사람이라 생각 했지만, 자신도 방황하며 자전거를 계속 탈 수 있을 꺼란 생각이 흔들리기 시작한다. 하지만 주위 사람들의 도움을 통해 다시 자전거 선수가 되며  그 어렵다는 Tour De France에서 우승을 하게 되고 7연승까지 하게 된다.

에세이기는 하지만 글을 읽으면 소설 같이 흥미진진했다.

일부는 미국 영화에서 주로 느낄수 있는 영웅주의느낌이 많이난다고 느낄지도 모르겠다. 하지만 그의 이야기에서 자신의 성공뒤에서 지원해주는 많은 사람이 있었다는 것을 말할려고 하는 같다.

젊은 시절 방황 하는 것은 자신을 찾아가기 위해서 이다. 방황을 하지 않는 청춘은 청춘이 아니다.

이것은 자전거 이야기가 아니고 삶의 이야기이며, 영혼의 이야기이다.

아래는 랜스 암스트롱의 NIKE광고이다.



그는 현재 랜스 암스트롱 재단을 설립하여 암환자를 돕는일에 적극적으로 나서고 있다.

너무 오랜만에 글을 써서 그런지, 아니면 요즘 우울해서 그런지--;; 글이 정말 잘 안써지네요..--;;

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

선배로 부터 추천 받은 책이다. 프로그래밍고 관련된 일을 하고자 하는 분은 읽어 봐야만 한 책인 것 같다. 읽다 보면 공감 가는 부분도 많을 것이며, IT관련 대학생이라면 반드시 읽어봐야 할만한 책이다. 단순히 프로그램을 짜는 법만 가지고는 좋은 프로그래머가 될 수 없다.

1. 자신의 기술craft에 관심과 애정을 가져라.
   소프트웨어 개발을 잘 해보려는 생각이 없다면 왜 인생을 그 일을 하면서 보내는가?
   
2. 자신의 일에 대해 생각하면서 일하라!
   자동 조종 장치를 끄고 직접 조종하라. 스스로의 작업을 지속적으로 비판하고 평가하라.
   
3. 어설픈 변명을 만들지 말고 대안을 제시하라.
   변명하는 대신 대안을 제시하라. 그 일은 할 수 없다고 말하지 말고, 무엇을 할 수 있는지에 대해 설명하라.
   
4. 깨진 창문을 내버려두지 말라.
   눈에 뜨일 때마다 나쁜 설계, 잘못된 결정, 좋지 않은 코드를 고쳐라.
   
5. 변화의 촉매가 되라.
   사람들에게 변화를 가용할 수는 없다. 대신 미래가 어떤 모습일지 그들에게 보여주고 미래를 만드는 일에 그들이 참여하도록 도우라.
   
6. 큰 그림을 기억하라.
   주변에 무슨 일이 일어나는지 점검하는 일을 잊어버릴 정도로 세부사항에 빠지지 말라.
   
7. 품질을 요구사항으로 만들어라.
   프로젝트의 진자 품질 요구사항을 결정하는 자리에 사용자를 참여시켜라.
   
8. 지식 포트폴리오에 주기적으로 투자하라.
   학습을 습관으로 만들라.
   
9. 읽고 듣는 것을 비판적으로 분석하라.
   벤더, 매체들의 야단법석, 도그마에 흔들리지 말라. 여러분과 여러분 프로젝트의 관점에서 정보를 분석하라.
   
10. 무엇을 말하는가와 어떻게 말하는가 모두 중요하다.
    무엇을 말하는 가와 어떻게 말하는 가 모두 중요하다. 효과적으로 전달하지 못한다면 좋은 생각이 있어봐야 소용없다.
    
11. DRY-반복하지 마라. Don't Repeat Yourself.
    어떤 지식 한 조갇도 하나의 시스템 안에서는 모호하지 않고, 권위 있고, 단 하나뿐인 표현을 가져야 한다.
    
12. 재사용하기 쉽게만들라.
    재사용이 쉽다면, 사람들이 재사용할 것이다. 재사용을 촉진하는 환경을 만들라.
    
13. 관련 없는 것들 간에 서로 영향이 없도록 하라.
    컴포넌트를 자족적이고, 독립적이며, 단 하나의 잘 정의된 목적만 갖도록 설계하라.
    
14. 최종 결정이란 없다.
    돌에 새겨진 것처럼 불변하는 결정은 없다. 그렇게 생각하는 대신, 모든 결정이 해변 백사장 위에 쓴 글자와 같다고 생각하고 변화에 대비하라.
    
15. 목표물을 찾기 위해 예광탄을 써라.
    예광탄은 이것저것을 시도해보고 그것들이 목표와 얼마나 가까운 데 떨어지는지 보는 방법으로 목표를 정확히 맞추게 해준다.
    
16. 프로토타입을 통해 학습하라.
    프로토타이핑은 배움의 경험이다. 프로토 타이핑의 가치는 만들어낸 코드에 있지 않고, 여러분이 배운 교훈에 있다.
    
17. 문제 도메인에 가깝게 프로그래밍하라.
    사용자의 언어를 사용해서 설계와 코딩을 하라.
    
18. 추정을 통해 놀람을 피하라.
    시작하기 전에 추정부터 하라. 잠재적인 문제점들을 미리 찾아내게 될 것이다.
    
19. 코드와 함께 일정도 반복하며 조정하라.
    구현하면서 얻는 경험을 이용해서 프로젝트의 시간 척도를 세밀하게 조정하라.
    
20. 지식을 일반 텍스트로 저장하라.
    일반 텍스트 형식은 시일이 지났다고 못쓰게 되는 일이 없다. 일반 텍스트 형식은 여러분의 작업을 활용하고 디버깅과 테스팅을 쉽게 만드는 데 도움이 된다.
    
21. 명령어 셸의 힘을 사용하라.
    그래픽 사용자 인터페이스로는 할 수 없는 일에 셸을 이용하라.
    
22. 하나의 에티터를 잘 사용하라.
    에디터를 마치 손의 연장延長으로 자유자재로 다루어야 한다. 여러분이 사용하는 에디터는 설정을 바꿀 수 있고, 확장가능하고, 프로그램 가능해야 한다.
    
23. 언제나 소스코드 관리 시스템을 사용하라.
    소스코드 관리는 여러분 작업을 위한 타임머신이다. 언제라도 과거로 돌아갈 수 있게 해준다.
    
24. 비난 대신 문제를 해결하라.
    버그가 여러분 잘못인지 다른 사람 잘못인지는 별로 중요하지 않다. 그것은 여전히 여러분의 문제이며, 여전히 고쳐야 할 필요가 있다.
    
25. 디버깅을 할때 당황하지 마라.
    숨을 깊게 들이고 쉬고, 무엇이 버그를 일으키는지 '생각하라!'
    
26. 'select'는 망가지지 않았다.
    OS나 컴파일러의 버그를 발견하는 일은 정말 드물게 일어나며, 심지어 써드파티 제품이나 라이브러리일지라도 드문 일이다. 버그는 애플리케이션에 있을 가능성이 가장 크다.
    
27. 가정하지마라. 증명하라.
    진짜 데이터와 경계 조건이 있는 실제 환경에서 여러분이 내렸던 가정들을 증명하라.
    
28. 텍스트 처리 언어를 하나 익혀라.
    여러분은 하루 가운데 많은 시간을 텍스트와 씨름하며 보낸다. 왜 여러분 대신 컴퓨터가 그 일의 일부를 하게끔 만들지 않는가?
    
29. 코드를 작성하는 코드를 작성하라.
    코드 생성기는 생선성을 증가시키며 중복을 막는 일에 도움이 된다.
    
30. 완벽한 소프트웨어는 만들 수 없다.
    소프트웨어는 완벽할 수 없다. 피할 수 없이 나타나는 에러로부터 여러분의 코드와 사용자들을 보호하라.
    
31. 계약에 따른 설계를 하라.
    코드가 실제로 하기로 한 것을 문서화하고 검증하기 위해 계약을 사용하라.
    
32. 일찍 작동을 멈추게 하라.
    보통은 죽은 프로그램이 절름잘이 프로그램보다 해를 훨씬 덜 끼친다.
    
33. 단정문을 사용해서 불가능한 상황을 예방하라.
    단정은 여러분이 세운 가정을 검증해준다. 확실한 것이 없는 세상에서 여러분의 코드를 보호하려면 단정문을 사용하라.
    
34. 예외는 예외적인 문제에사용하라.
    예외를 잘못 쓰면 고전적 스파게티 코드의 모든 가독성과 유지보수 문제를 그대로 겪을지도 모른다. 예외는 예외적인 일들만을 위해 남겨두어라.
    
35. 시작한 것은 끝내라.
    가능하다면, 리소스를 할당한 루틴이나 객체가 해제도 책임져야한다.
    
36. 모듈간의 결합도를 최소화하라.
    디미터의 법칙을 적용하는 '부끄럼 타는shy'코드를 작성해서 결함이 생기는 일을 피하라.
    
37. 통합하지 말고 설정하라.
    애플리케이션에서 기술 선택을 설정 옵션으로 구현하고, 통합하거나 만들어 넣지 말라.
    
38. 코드에는 추상화를, 메타데이터에는 세부 내용을.
    프로그램은 최대한 일반화해서 만들고, 세부사항들은 가능하면 컴파일된 코드 기반 바깥으로 빼라.
    
39. 작업흐름 분석을 통해 동시성을 개선하라.
    사용자의 흐름이 허용하는 동시성을 최대한 활용하라.
    
40. 서비스를 사용해서 설계하라.
    서비스, 곧 잘 정의되고 일관성 있는 인터페이스를 통해 의사소통하는 독립적이고 동시성 있는 객체들의 관점에서 설계하라.
    
41. 언제나 동시성을 고려해 설계하라.
    동시성이 가능하도록 설계하면, 더 적은 가정만 내리고서도 더 깔끔한 설계를 할 수 있다.
    
42. 모델에서 뷰를 분리하라.
    애플리케이션을 모델과 뷰의 관점으로 설계해서 적은 비용만 들이고도 유연함을 얻어내라.
    
43. 칠판을 사용해 작업흐름을 조율하라.
    참여하는 요소들의 독립성independence과 고립성isolation을 유지하면서도 개별적인 사실과 에이전트를 잘 조율하려면 칠판을 사용하라.
    
44. 우연에 맡기는 프로그래밍을 하지 말라.
    정말 믿을 만한 것만 믿어야 한다. 우발적인 복잡함을 조심하고, 우연한 행운을 목적의식을 가지고 만든 계획과 착각하지 말라.
    
45. 여러분의 알고리즘의 차수를 추정하라.
    코드를 작성하기 전에, 실행시간이 대략 얼마나 걸릴지 감을 잡아 놓아라.
    
46. 여러분의 추정을 테스트하라.
    알고리즘의 수학적 분석이 모든것을 다 알려주지는 않는다. 실제 대상환경에서 코드의 수행 시간을 측정해보라.
    
47. 일찍 리팩터링하고, 자주 리팩터링하라.
    정원의 잡초를 뽑고 식물 배치를 조정하는 것과 똑같이, 코드도 필요할 때면 언제라도 다시 작성하고 다시 작업하고 다시 아키텍처를 만들라. 문제의 근원을 해결하라.
    
48. 테스트를 염두에 두고 설계하라.
    코드를 한 줄이라도 쓰기 전에 테스팅에 대해 생각하기 시작해야 한다.
    
49. 소프트웨어를 테스트하라. 그렇지 않으면 사용자가 테스트하게 될 것이다.
    가차 없이 테스트하라. 사용자가 여러분을 위해 버그를 찾게 만들지 말라.
    
50. 자신이 이해하지 못하는, 마법사가 만들어준 코드는 사용하지 말라.
    마법사는 엄청난 양의 코드를 만들 수 있다. 그것들을 프로젝트에 통합해 넣기 전에 그 코드 내용을 전부 이해하는지 확실히 해놓도록 하라.
    
51. 요구사항을 수집하지 말고 채굴하라.
    요구사항이 지면에 놓여져 있는 경우는 퍽드물다. 보통은 가정과 오해, 정치政治의 지층들 속에 묻혀 있다.
    
52. 사용자처럼 생각하기 위해 사용자와 함께 일하라.
    시스템이 정말로 어떻게 사용될지 통찰력을 얻을 수 있는 가장 좋은 방법이다.
    
53. 구체적인 것보다 추상적인 것이 더 오래간다.
    구현 말고 추상화에 투자하라. 추상은 서로 다른 구현이나 새로운 기술의 출현 때문에 빗발치듯 생기는 변화를 견뎌내고 살아남을  수 있다.
    
54. 프로젝트 용어사전을 사용하라.
    프로젝트에서 쓰이는 특정 용어와 어휘들의 유일한 출처를 만들고 유지하라.
    
55. 생각의 틀을 벗어나지 말고, 틀을 찾아라.
    해결이 불가능해 보이는 문제와 마주쳤을때, 진짜 제약조건을 찾아라. 스스로에게 이렇게 물어보라. '정말로 반드시 이런 방식으로 해야 하는 일인가? 꼭 해야만 하는 일이긴 한 건가?'
    
56. 준비가 되었을 때 시작하라.
    여러분은 살아오면서 경험을 쌓아 왔다. 자꾸 거슬리는 의혹을 무시하지말라.
    
57. 어떤 일들은 설명하기보다 실제로 하는 것이 더 쉽다.
    명세의 나선에 빠지지 말라. 언젠가는 코딩을 시작해야 한다.
    
58. 형식적인 방법의 노예가 되지 마라.
    여러분의 개발 실천 방법과 개발 능력의 맥락 안에 넣어보지 않고, 맹목적으로 어떤 기법을 채택하지 말라.
    
59. 비싼 도구가 더 좋은 설계를 낳지는 않는다.
    벤더들의 과장, 어떤 분야의 도그마 그리고 가격표의 휘광에 넘어가지 말라. 도구 자체의 장점만 갖고 판단하라.
    
60. 팀을 기능 줌심으로 조직하라.
    설계자와 코더를, 테스트 담당자와 데이터 모델 담당자를 분리시키지 말라. 코드를 만드는 방식에 맞춰 팀을 만들어라.
    
61. 수작업 절차를 사용하지 말라.
    셸 스크립트나 배치 파일은 똑같은 명령을, 똑같은 순서로, 어느 때라도 반복해서 실행해준다.
    
62. 일찍 테스트하고, 자주 테스트하라. 자동으로 테스트하라.
    매번 빌드할 때마다 실행되는 테스트가 책꽂이의 테스트 계획보다 훨씬 효과적이다.
    
63. 모든 테스트가 통과하기 전에 코딩이 다된게 아니다.
    뭐 더 할 말 있나?
    
64. 파괴자를 써서 테스트를 테스트하라.
    코드의 별도 복사본을 만들고, 그 복사본에 고의로 버그를 넣은 다음 테스트가 잡아내는지 검증하라.
    
65. 코드 커버리지보다 상태 커버리즈를 테스트 하라.
    중요한 프로그램 상태들을 파악해서 테스트하라. 단지 많은 코드 줄 수를 테스트 범위 안에 넣는 것만으로는 충분하지 않다.
    
66. 버그는 한번만 잡아라.
    인간 테스터가 버그를 찾아 내면, 그 때가 인간 테스터가 그 버그를 찾는 마지막 순간이 되어야 한다. 그 순간 이후 부터는 자동화된 테스트가 그 버그를 담당하도록 만들라.
    
67. 한국어도 하나의 프로그래밍 언어인 것처럼 다루라.
    코드를 작성하는 것처럼 문서도 작성하라. DRY 원칙을 존중하고, 메타데이터를 사용하고,MVC 모델을 쓰고, 자동생성을 이용하고 등등.
    
68. 문서document가 애초부터 전체의 일부가 되게하고, 나중에 집어넣으려고 하지 말라.
    코드와 떨어져서 만든 문서가 정확하거나 최신 정보를 반영하기는 더 힘들다.
    
69. 사용자의 기대를 부드럽게 넘어서라
    사용자들이 무엇을 기대하는지 이해한 다음, 그것보다 약간 더 좋은 것을 제공하라.
    
70. 자신의 작품에 서명하라.
    옛날 장인들은 자신의 작업 결과물에 서명하는 일을 자랑스럽게 여겼다. 여러분도 마찬가지여야 한다.

체크리스트

• 배울만한 언어
  C, C++, 자바에 식상했는가? CLOS, Dylan, Eiffel, Objective C, Prolog, Smalltalk 혹은 을 공부해보라. 각 언어마다 서로 다른 능력과 다른 '맛'이 있다. 집에서 이들 언어 가운데 하나 또는 여러 개를 이용한 자그마한 프로젝트를 시작해보라.
  
• WISDOM 놀이
  무엇(What)을 배우길 원하는가?
  말하려는 것에서 그들의 관심(interest) 있어 하는 건 무엇인가?
  얼마나 소양(sophisticated)이 있는가?
  어느정도 구체적인(detail) 내용을 원하는 가?
  누가 정보를 소유(own)하길 원하는가?
  그들이 경청하도록 동기(motivate)를 주려면 어떻게 해야 할까?
  
• 직교성을 유지하는 방법
  독립적이고, 잘 정의된 컴포턴트를 설계하라.
  코드의 결합도를 줄여라.
  전역 데이터를 피하라.
  비슷한 함수들을 리팩터링하라.
  
• 프로토타입을 만들 것들
  아키텍처
  기존시스템에 추가할 새로운 기능
  외부 데이터의 구조 혹으은 내용
  써드파티 도구나 컴포턴트
  성능 문제
  사용자 인터페이스 설계
  
• 아키텍처에 관련된 질문
  책임이 잘 정의 되었는가?
  협력이 잘 정의 되었는가?
  결합도는 최소화되었는가?
  잠재적 중복을 찾아낼 수 있는가?
  인터페이스 정의와 제약 사항은 수용할 만 한가?
  모듈이 필요한 데이터에 필요한 때 접근 할 수 있는가?
  
• 디버깅 체크리스트
  보고된 문제가 내재하는 버그의 직접적 결과인가 아니면 단순히 증상일 뿐인가?
  보그가 정말로 컴파일러에 있나? OS에 있나? 혹은 여러분 코드에 있나?
  이 문제를 동료에게 상세히 설명한다면 어떻게 말하겠는가?
  의심이 가는 코드가 단위 테스트를 통과한다면, 테스트는 충분히 완전한 것인가? 이 데이터로 단위 테스트를 돌리면 무슨 일이 생기는가?
  이 버그를 야기한 조건이 시스템의 다른 곳에도 존재하는가?
  
• 디미터 함수 법칙
  어떤 객체의 메서드는 오직 다음 목록에 들어있는 메서드들만 호출해야한다.
  
  자기자신
  전달받은 매개 변수
  자신이 생성한 객체
  컴포넌트 객체
  
• 의도적으로 프로그래밍하는 방법
  지금 자신이 무엇을 하고 있는지 항상 의식하라.
  맹목적으로 코딩하지 말라.
  게획을 세우고 그것을 바탕으로 진행하라.
  신뢰할 수 있는 것에만 기대라.
  여러분이 내린 가정을 문서로 남겨라.
  코드뿐 아니라 가정도 테스트하라.
  노력의 우선순위를 정하라.
  과거의 노예가 되지 말라.
  
• 언제 리팩터링을 해야 하는가
  DRY 원칙의 위반을 발견했을 때
  더 직교성이 좋게 만들 수있는 것들을 찾았을 때
  여러분의 지식이 더 나아졌을 때
  요구사항이 진화했을 때
  성능을 향상시킬 필요가 있을 때
  
• 고르디우스의 매듭을 자르기
  
  불가능해 보이는 문제를 풀때, 스스로에게 다음처럼 질문해보라.
  
  더 쉬운 방법이 존재하는가?
  지금 진짜 문제를 푸고 있는가?
  왜 이것이 문제인가?
  무엇이 이것을 어렵게 만드는가?
  반드시 이 방법으로 해야 하는건가?
  반드시 해야 하는 일이긴 한가?
  
• 테스트의 유형
  단위 테스트
  통합테스트
  유효성 평가validation와 검증verification
  자원 고갈, 에러 그리고 복구
  성능 테스트
  사용편의성 usability 테스트
  테스트 자체를 테스트하기

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

 연암 박지원의 고전 산문을 정음이라는 사람이 풀어서 옮겨 놓은 책이다.

고전을 읽는 것이 너무 생소 했다..

솔직히 연암이 누구인지 어떤 사람인지도 모른다.... 책 제목은 무엇인가 재미 있는 내용이 있을 거란 생각이 들었지만.. 처음 부터 고전이라는 것을 알고 접했기에 어렵지 않을까 읽기에 부담 스럽지 않을까 거정 했던 책이다.

요즘들어 책관련 Posting을 자주 하는 것 같았다. 책읽기에 맛을 너무 늦게 들이는것 같다. 매일 같이 전공 & 영어 공부만 죽어라고 하고... 책은 거의 읽지 않고 지내다가.. 1 년쯤 전부터 책을 조금씩 조금씩 읽게 되는 것같다..

군대 가기전 1학년때는 단 한번도 도서관에서 책을 빌려 본적이 없었다.. 그에 비해서 요즘은 그나마 책을 한달의 한권쯤은 읽고 있다..

이번에 이책은 우연히 도서관에서 제목이 맘에 들어 빌린 책은 아니다. 독서 토론 클럽에 가입 하게 되었고, 그로 인해 이 책을 빌려 보게 되었다..

만약 독서 토론 클럽에 강비 하지 않았다면.. 내 생에 절대로 빌려 보거나 사보지 않았을 책이다..

고전은 대입 수능 시험 지문에서나 볼 수 있는 책이였고, 그 이후는 아마 고전을 읽어 본적이 없었다.

너무나 어렵게 느껴졌고, 책을 다 읽은 후에도 어렵다는 생각은 여전했다.

아무래도 고전은 다른 시대에 쓰여진 글이라서, 그 때의 사회 분위기에 따라 내용이 반영 되는데, 그런 내용을 잘 알지 못하고서는 쉽게 읽기는 어려운 것 같다.

워낙 책을 많이 않읽어서 그런 것일 수 있지만, 고전을 쉽게 해석하고, 접할 수 있도록 만든 책이였음에도 읽기에는 부담스러운것은 마찬 가지였던것같다.

차라리 본문은 책 내용에서 제외하고, 재 해석 해놓은 부분만 새롭게 구성하여 책으로 엮는 것이 조금더 괜찮았을 것 같다. 책에서도 형식이나 모양이 중요한 것이 아니라 그 것이 담고 있는 내용이 중요하다고 하였었지 않나?

사람들에게 좀더 쉽게 이해되고, 좀더 많은 사람이 볼 수 있어야 좋은 것이 아닐까 생각된다.

그 중 일야구도하기는 이미 고등학교때 읽어본 글이다.. 그때 당시에도 인상깊에 봤던 글이였다..

그리고 요즘 마음에 드는 내용중에 하나가, 너무 칼로 자르듯이 경계 지으려는 것을 비판하는 내용도 인상 깊었다. 요즘 사람은 어떤한 의제에 대해 반대, 혹은 찬성으로 나누어 토론 하기를 좋아하는 것같다...

조금더 유연한 사고를 가질 수 있음에도 불구하고.. 자신과 반대의 생각을 가진 사람은 설득을 해야 되고.... 그로 인해 언성을 높혀 가며 토론 하다가.. 결국에는 그 사람이 미워지게 되는... (조금 극단 적이기는 하지만, 실제로도 있는 것같다..)

마음이 안맞으니 그 사람이 싫어지게 되는..

그 사람의 생각 뿐만 아니라 사람 자체가 싫어 지는 경우도 종종 있지 않은가 생각 해봐야 겠다..

토론 주제는 다음과 같다..
오늘이 모임에 날인데 가서 말이나 제대로 하고 올 수 있을가 걱정 스럽다..

소주제.
1. 읽은 후 소감 및 느낀점.

2. 감명깊었던 이야기나 글귀는?

3. 이 책을 읽은 후 한국 고전에 대한 생각이 변했다면?

4. 위기의 고전, 대중들에게 다가갈 수 있는 방법은?

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

방학이라 책을 자주 읽어 보려고 했지만, 맘데로 되질 않았다. 다른 한일도 많고, 대연도서관이 공사중이라 책을 빌려 볼 수 없어서 어쩔수 없다는 나름데로의 핑계거리가 있어서 생각과는 달리 방학때 많은 책을 보지 않고 있다.

그러던 중 한 선배가 20대에 읽어야할 책 목록 100여권을 가져와서는 다는 못보더라도 하나씩 읽어보면서 토론해 보지 않을려는 제안을 해왔다. 물론 혼자서 하는것보다 여러사람이 같은 책을 돌려 보게되면 연대의식이 생겨 나의 나약한 의지를(?) 해결할 방법이고.. 책도 많이 읽을 기회라 생각 하여 같이 책을 읽기로 하였다.

첫번재 선택한 책은 『나는 빠리의 태시운전사-홍세화』이다. 이전에 읽어본적이 없는 책이다. 제목은 꽤나 재미 있었고, Flap에는 지은이가 망명중이라는 예기도 나와있었다.

책은 파리에 대한 소개로 시작한다. 파리에 대한 간략한 소개를 끝으로 자신의 이야기를 하겠다며, 첫 장이 시작된다.

자신이 택시 운전사를 시작하면서 파리에서 겪에되는 이야기와 함께 망명오기전 한국에서의 기억들이 비교되듯이 나타난다.

필자는 70년대 한국에서의 남민전(남조선민족해방전선) 활동으로 인해 한국으로 돌아기지 못하고 프랑스에 남게 되었다. 프랑스에 남게된 필자는 생계 문제때문에 택시 운전을 시작하게 된다. 프랑스에서는 에뜨랑제(?외국인)도 빠리지앵(?프랑스인)과 동일하게 택시 운전기사가 될 수 있는 요건을 요구한다. 그렇게 빠리에서 택시 운전사를 시작하고 빠리지앵과 빠리에 대해 점차 알아가게 된다.

처음에는 프랑스에 문화와 한국 문화의 차이점을 통해 과거 우리나라가 가졌던 독재에 대한 비판을 하는것 같았다. 하지만 그것은 문화의 차이에서 오는 것이 아니였고 빠리지앵이 가진 똘레랑스 때문에 나타나는 것이였다.

한국 사람이 가진 "정"과 같이 빠리지앵들의 생각 속에는 똘레랑스가 녹아있다.
똘레랑스는 서로의 다름을 인정한다는 것이다. 다른 사람을 존중해줌으로 자신도 존중받을 수 있다.

종교, 문화, 사상은 자신에게 매우 고귀한 것이다. 또한 이것은 다른 사람에게도 역시중요한 것이므로 다른 사람에게 강요할 수 없고 차이를 인정해 준다는 것이다.

나의 생각은 다음과 같다. 우리나라사람이 똘레랑스를 가지고 있지 않아서 70년대 한국 정권이 시민들의 사고를 억업하고 통제하게 된 것은 아닌것 같다. 이런 시대를 겪고 지내 왔기 때문에 한국 사람들이 똘레랑스가 사라져버린게 아닌가 생각된다.

권력자들이 자신의 권력을 확장하기 위해 [나와 같은 종교, 나랑 같은 생각을 가진사람은 나와 한편이고 다른 종교, 다른 생각을 가진 사람은 적(敵)으로 만들어야 한다] 는 논리를 사람들 머리속에 심어 넣었고, 그로 인해 한국 현대사의 비극이 발생한 것이 아닌가 생각 된다.

한국 현대사에 대해 너무 모르고 있었던것 같다. 글을 읽다보니 한국에 대한 이야기가 너무나도 생소 했다. 그래서 그런지 책을 읽으면서 부끄러운 생각이 들었다.

PS. 그런데 지금 이런 생각이 든다. 사람들에게 똘레랑스가 필요 하다. 하지만 똘레랑스를 가지자고 다른 사람에게 주장하고 강요하는 것은 똘레랑스에 위배 된다. 그럼 똘레랑스가 있는 사회를 구성하기 위해서는 어떤 방법이 있는 것일까?

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조�