lunatic temporary field

이 책의 타겟이 굉장히 모호하다.
일단은 소프트웨어를 쓰는 개발에 대해 아무 것도 모르는 사용자들.
그리고 은근 슬쩍 이 책을 보며 괴로워할 개발자들.
플래시 천국을 찬양하는 웹디자이너.
등등.
정도인 거 같은데..

기분 전환으로 읽기 좋은 책이라고 생각된다.
번역하시는 분이 뒤로 갈수록 지구력이 떨어졌는지 약간의 오역과 비문이 보이긴 하지만.
(나한테도 보이는 정도면 사실은 더 오타가 있을듯?)
또한 주제도 이것 저것 복작복작해서 여기 저기 들쑤시고 다녀 난잡한 느낌이 있긴 하다만.
하드코더로만 살면 만들어 내기 어려운 "쎈쑤"가 이 책엔 있는 듯 하다.

개발자 생활을 하다보면 하드코더 유니버스에 빠져서 컴덕후가 되고, 흉측하고 복잡한 피규어를 생산해내면서 변태처럼 흐흐흐대기가 쉬운데,
적정 선에서 "그러지 말고 일주일에 한 번은 지구로 돌아와" 하고 말해주는 느낌이랄까.

음.. 근데 인터페이스에 대한 내용에 대해 약간 논란의 소지가 있는걸.

• "확인 체크 박스"에 대해서
  
  "확인 체크 박스"라는 건 다른 게 아니라, 윈도우에서 파일을 지울 때 "정말 지울거냐? 네/아니오" 하고 나오는 그 상자같은 애들을 말한다.
  
  대학교 다닐 때 "컴퓨터와 마음"이라는 심리학 수업을 들은 적 있는데(컴퓨터와 마음이지만 컴퓨터와는 별 상관 없고, 뇌심리학 개론 정도였음), 거기서 심리학 교수님은 이 박스를 예로 들며 "마이크로소프트는 천재다. 사람들이 멍청하게 무심코 파일을 무의식적으로 용도도 생각해 보지 않고 지우려고 할 때 '정말 지울래?'라는 물음을 통해 잠시 정신을 번쩍 들게 한다" 며 엄청 칭찬했던 기억이 난다. 사람의 행동 패턴을 잘 반영한 거라고.
  
  그러나 이 책을 지은 아저씨는 "쓰레기"라고 한다. 왜 괜히 팝업창을 내보내서 우리를 귀찮게 하느냐며.
  
  뭐 사람의 관점에 따른 문제인 것 같기도 하고.
  (쉉은 별로 좋아하지 않을 경우가 많다. 특히 가끔 웹페이지가 잘못 만들어져 있을 때 무한 에러창 루프를 돌 때가 있는데... 모니터에 폭탄을 던지고 싶다 ㅡㅡ)
  

보안에 대해서는 꽤 재미있는 관점을 읽을 수 있어서 즐거웠다. 보통 암호학이나 보안 수업들을 들을 때 인트로 격으로 많이 듣는 이야기가 바로 "아무리 보안 시스템 잘 만들어 봤자 도둑들면 말짱 황이다"였는데.. 뭐 사회적인 '오프라인 보안 불감증' 말고도 보안에 대한 글쓴 아저씨와 몇몇 해커들의 재미있는 철학을 살짝 볼 수 있었다.

인터페이스나 보안 말고도 컴덕후의 철학, 프로그래머의 심리, 고객의 심리, 마이크로소프트에 대한 철학 등등 여러가지 주제에 대해 이야기 하고 있다. 뭐 마소에 대한 이야기는 그냥 넋두리인 듯한 감도 없지 않아서(?) 쫌 지루했지만 나머지는 시간 들여 읽을 만 했다.

===이건 개인적인 감상===

책 자체가 그렇게 읽는 데 오래 걸리는 책은 아니지만, 들고 다니면서 차 안에서 안잘 때 가끔가끔 읽어서 시간이 좀 오래걸렸음.

제목에 낚여서 산 책이긴 하다만.
나름 재밌고, 리프레시가 되는 거 같다.

일에 대해 더 많이 배울 수록, 그 일을 전혀 다른 관점에서 관찰해야 주화입마에 들지 않고 훌륭한 어린이에 가까워지지 않을까?(쉉은 아직 배운 것보다 배울 게 오백만십배는 더 많다만 ㅡㅡ;;)

ps: 요새 쓸거리/생각할 거리가 너무 많다 보니 오히려 정리하는 게 무서워서 ㅡㅡ 그래도 책 리뷰가 금방 뚝딱뚝딱 하기 쉬우니 비중이 많은 듯 하다.

근래 회사에서 erlang을 주제로 팀스터디를 하고 있다.
꽤 템포가 빠르게 진행되어 벌써 책 한권이 다 끝날 위기(?)에 놓여 있는 상황.

스터디를 하다보니 꽤 재미있는 언어인 듯도 하고.
기왕 언어 스터디를 했으니 앞으로 여기저기 써볼 수 있는 여지가 많지 않나 해서..
만들면 재밌을 것 같은 아이들을 호구조사+생각해 보고 있다.
내가 생각하기에 얼랭으로 뭔가 짠다고 한다면, 다음과 같은 특성을 가진 예제면 더욱 좋지 않을까 한다.

1. Concurrent Programming이 필요한 예제(예를 들면 분산처리 관련이라든가..)
2. 함수지향 언어의 득을 볼 수 있는 예제(이건 좀 판별이 어렵긴 합니다만)

지금까지 후보로 올린 애들은 다음과 같다.

1. 그래픽스 관련 예제 아이들.
   
   
   • 그래픽스/아니메 시간에 배웠던 각종 근사기법들만 보아도 엄청 컴퓨팅 파워가 소모되고, 컨커런트하게 짜면 개선될 여지가 많다.
   • 예: ㅎㅁ성인님께서 쏴주신 "레이트레이싱".
   • 예상 난이도 : 중~상
     
     
2. MapReduce
   
   
   • ㄹㄹ님께서 쏴주신 주제. 물론 책에 구현예가 있긴 하지만, 사람구실을 하게 만들려면 이것저것 추가해야 할 것이 좀 있는듯.
   • http://labs.google.com/papers/mapreduce.html 에 보면 재밌어 보이는 리서치 페이퍼(?)가 있다. 휴일에 구경해야지 하고 프린트해서 왔건만. 지름신의 난때문에 아직 한줄도 못봤뜸 ;-;.
   • 예상 난이도 : 중~상
     
     
3. 엄청 컴퓨팅 시간이 오래 걸리는 계산 문제들
   
   
   • 쉉의 생각에는 NxN 행렬 계산들만 해도 충분할듯.
   • 예: ㄹㄹ님께서 쏴주신 NxN(N은 열라 큰 정수) 행렬의 eigen vector / eigen value 구하기.
   • 예상 난이도 : 중하
     
     
4. 멀티미디어 인코더 / 디코더
   
   
   • 소싯적에 관련되어 있었던 수많은 병렬처리 실험 마루타들이 여기에서도 효과를 보지 않을까 싶다. 단점은 인코더/디코더 알고리즘 자체가 흠좀무 한것들이 많아서 분석 기간이 꽤 소요된다는 것. 뭐, 병렬로 쪼갤 수 있는 모듈만 erlang으로 짜고 나머지는 C로 인터페이스 하는 방법도 있지.
   • 예: mp3 인코더인가가 책에 있었던 것도 같지만, jpeg, h26x 인코더/디코더 등 수많은 멀티미디어 예제들.
   • 예상 난이도 : 상
     
     
5. 검색 관련 테스트/분석 유틸들
   
   
   • 골자만 말하자면, 테스트 입력 set을 가지고 패턴을 관측하는 애라든지, 서버가 여럿으로 분산되어서 어떤 처리를 해야할 때 효과적은 분산방법을 찾아주는 애라든지 등등이 있음. 뭐 앗싸리 "분산 검색 엔진"을 만들어도 인생경험은 될듯(ㅎㄷㄷ).
   • 이건 부분부분 컨피덴셜(?)일 여지가 있어서 언급 생략.
   • 난이도 : 중~최상
     
     
6. 프로젝트 관리 유틸들
   
   
   • TDD에서 테스트돌릴 때, 분산해서 돌리는 유틸 같은거 만들어보면 좋을듯. TDD는 CI(지속적인 통합)에서 유용한 개념으로 적용되기도 한다. 테스트셋이 무지 큰 경우, 분산해서 수행하면 더 빠를 수도 있다.
   • 허나, 쉽게 찾아다 쓸 수 있는 유틸들이 많은 실태인지라 괜히 삽만 파고 안쓸 가능성도 조금은 있다. 게다가, 이런 정기적 테스트들은 대부분 오밤중에 걸기 때문에 왠만하면 속도는 고만고만하면 된다는 생각이 있을 수도 있음.
   • 예상 난이도 : 중
     
     
7. 분산 파일 시스템
   
   
   • 말 그대로 분산 파일 시스템.
   • 내가 만들지 않으면 지구상 누군가가 언젠가 "얼랭으로 DFS 만들었어염!!!" 하고 우쭐댈지도 모른다(아니면 누군가가 벌써 만들었거나). 시간은 쩜 오래 걸릴지도.
   • 일단 쉉이 만들려면 분산 파일 시스템에 대해 공부를 좀 더 해야 하고, 혼자 만들면 쓸만한게 나오기 힘들기 때문에 깡좋은 누군가들을 섭외해야(...).
   • 예상 난이도 : 상~최상
     

대부분이 개인적인 흥미에 치중된 지라 팀스터디에 추천하긴 그닥 좀 그런 애들(...).
이 외에도 누가 그럴싸하다 싶으면 추천점 부탁염 ;-;/.

ps: 개인적으로 쉉은 7번은 꼭 해보고 싶다!!!. 스터디에서 할 수 있는 규모는 아니지만.
ㄹㄹ님도 DFS에 워어어 불타시는 걸로 보아 유피넬 웕샵에 던지던지, 직딩 모임이라도 만들어서 추진해 볼까!!

5만원 이상 5천원 할인쿠폰을 쓰기 위해(...) 겸사겸사 구입하였던 책.
"Ship it!"의 일부분과 내용이 좀 겹치지만,
개발 프로젝트에서의 "지속적인 통합"에 대해 한층 더 심도 있게 다루었다고 생각된다.

인상 깊은 부분들을 가리자고 하면 다음과 같다. "Ship it!"과 겹치는 부분은 가능한한 배제했음.

보기-스포일러지뢰밭

물론 평사원이 범접할 수 없는 영역들이라는 것도 있게 마련이지만(또한 쉉은 이빠시 마루타가 되어본 뒤 이게 좋다고 확신하기 전까지는 남에게 이게좋아!!! 하고 주장할 수 없는 성질이기도 하다;-;).
자기가 할 수 있는 영역 내에서 계속 새로운 시도를 하면서 일을 하면 좀더 일이 신나지 않을까나.
취미 생활도 마찬가지고.

ps: Ant라는 게 이책 저책에 계속 주연급으로 나오는군. 함 써볼까 ㅡㅡ.

오랫만에 잡담 포스팅.

어딘가 웹을 허부작대다가

"자기 일 다 끝났다고 분위기 파악 못하고 노는 개발자넘은 재섭다"
라는 내용의 글을 봤다.

뭐 그 사람의 의도는 그게 아니었다고 생각되나.
확실히 작년 1년동안 나의 특성이 변질된건지.
머리 속에서 버럭! *$#^*#(!!!! 하고 폭발이 있었다.

대충 이런 내용의 생각들.
"내 일 끝났어도 다른 사람이 일 못끝냈다고 일요일->월요일로 넘어가는 새벽 네시반까지 일해야 되는거냐!" 라든지.
"애당초 못끝낼 일을 오케이하라고 시킨/오케이 한 누군가가 잘못이지!" 라든지.
그 밖에 꿀렁꿀렁.

뭐 저런 건 지극히 극단적인 경우일지도 모르지만.

지금도 약간은 적용되는 논리.

아는 사람은 알다시피 쉉은 현재 서비스 개발(이라고 쓰고 개발겸 영자라고 읽는다) 노릇을 하고 있는데.
요새의 고민거리(?)라고 한다면.
"어떻게 하면 AS를 줄이고 탱자탱자 놀 것인가?" 이다.

짧은 시간이지만 영자를 하면서,
"이건 이렇게 하면 내가 더 놀 수 있겠구나."
"이런 툴을 만들면 난 더 땡땡이 칠 수 있겠구나."
이런 생각 하면서 영자 한 두달 정도 공부도 하고, 툴도 만들고, 코드도 다듬고 해서.
실제로 처음에 수동작업으로 처리했을 때보다 AS처리가 적어도 30%는 감소한 것 같다.
뭐 별로 대단하고 어려운 일을 한 건 아니다만(나를 아는 사람은 내가 어렵고 아름다운 일을 하기엔 한없이 허당이란 걸 잘 안다ㅠㅠ), 아주 간단한 일들만 해도 이렇게까진 할 수 있더라..

30% 감소한 시간동안 놀기도 하고, 다른 공부들도 했지만 별 죄책감은 없다.

만약 내가.
"우주 성실맨이 되어야지. 남이 귀차나 하는 일도 내가 다 해야지!!" 라든지
"야근따위 백만번 해도 상관업써 무조건 열씨미!" 라는 생각을 품었다면.
저렇게 잔머리 굴리고 더 관리하기 편한 방법을 모색하고 그랬을까나.
완전 무식쟁이처럼 영자노릇을 하면서 나는 성장하고 있구나 하는 말도 안되는 망상으로 므흣해했겠지.

고로 지금은.
"개발(과운영) 역량의 발전은 61%의 귀찮음과 29%의 책임감, 9.5%의 외계통신, 42%의 지겨운 일을 재밌는 일로 만들기, 34%의 전력토끼로 이루어진다" 주의인지라.

코웍이 정말 중요하긴 중요하지만.
그게 "니가 좀 느리면 내가 니꺼까지 다 떠맡아서 몇날 며칠 밤새서라도 해줄께"의 의미는 아닌데... 싶다.

서로가 서로의 줄주리타가 되어서 도와주고.
그 결과 달 한명은 주룩주룩 야근할 일을 한달 모두모두 칼퇴근으로 해낼 수 있으면,
거기까지가 아니어도 그 한명이 일주일 정도만 야근할 수 있도록 도와주면.
그게 킹왕짱이 아닌가나.
이렇게 만들기도 무지무지 어려운데!.
놀지도 말라는거냐!.

그렇다고 성실함은 아무 쓸모도 없다는 얘기는 아니고.
다른 도메인의 성실함이 필요한듯.

눈치 보느라 못놀고.
눈치 보느라 말도 안되는 얘기에 반박도 몬하고.
눈치 보느라 없는 야근 지어내서 잠못자고.
아무리 재밌는 일이라도 생존권을 침해하면 재미있을 리가 없다.
전력으로 시러한다 ㅡㅡ.

ps: 머 내가 10년 넘게 이 업계에서 일하면 가치관이 바뀔지도 모르겠지만.
허당 초보일 때 쉉은 이렇게 생각했습니다 하고 남겨놔야지.

Ship it! 은 개발 프로젝트 수행 단계, Release it은 개발이 끝나고 라이브가 진행중인 단계에 도움이 될만한 책이라고 널리(?) 알려져 있다.
근데 난 어찌 순서가 좀 거꾸로 된듯 싶은게, Release it을 먼저 (빌려)읽은 후 이 책을 봤다(...).

Release it 같은경우 번역 문제도 그랬지만(참고로, r모님 말씀대로 Release it 같이 좋지 않은 번역서는 정말 번역서 질의 향상을 위해서라도 사서 보아선 안된다고 생각한다.), 특정 분야를 어느 정도 잘 알고 있지 않으면 원서로 보아도 많이 힘들 것으로 생각된다.

반면!.
ship it은 개발자에게도 좋은 참고/재밌는 이야깃거리가 될 뿐더러(개발자는 한번 두번 세번, 사과를 그려가며 읽어도 재밌다), 개발자와 같이 일해야 하는 비개발자들도 한번 거들떠 보면 더불어 살아가는 데 좋을 듯한 책이다.
다른 실용주의 개발 책들과 달리, 실험해 볼 수 있는 실제적인 방법들을 비교적 소상히(?) 소개하고 있다.
난 특히 다음과 같은 소재들이 마음에 들었다(스포일러이므로 볼 사람만 보시오).

===몇가지 소재들===

위의 스포일러도 호기심이 가지만, 정말 공감했던 부분은 Co-work의 중요성이다. 개발자 동료가 또라이라도, 덕후라도, 히스테리 노처녀라도, 혹은 히키코모리라도 이에 굴하지 않고 팀웍을 다지고 모두들 똑똑해지는 게 얼마나 중요한 일인지 강조하는 게 참 맘에 들었다. 아쉽게도 그건 현실에서 백만톤 정도 힘든 일이긴 하지만. 처음부터 어긋난 만남이라는 게 얼마나 무서운지. 일터가 평화로울지 전쟁터가 될지는 이미 구성원에서 XX% 정해진다고 난 믿는다. 아무리 좋은 프로세스/도구가 있어도 사람들이 고집스럽게 이를 무시하고 막나가거나 배째는 경우 결말은 "nice boat"임이 뻔히 보이는 것을(머엉).

대부분의 한국 회사(뿐만 아니라 외국에 있는 회사들도 어느 정도 그렇다고 들었지만,)는 수직적인 성향이 강하여 아래로부터 멋지구리하다고 생각하는 팀웍들을 실험해 볼 여지가 그닥 많지는 않다고 본다. 그래도 지금 버리버리 개발자 레벨일 때 이리저리 "어떻게 하면 정신줄 놓는 일을 덜 만들 수 있을까", "어떻게 하면 일을 확 줄여서 빈둥빈둥 일해도 월급 잘 받아 먹으며 살 수 있나" 잔머리 굴려보고 뚝딱뚝딱 해보는 건 정신/육체 건강에 꽤 도움이 될 듯.