lunatic temporary field

•  "데이터베이스"의 지속적인 통합
  
  
  • DB를 소스코드와 거의 같은 방법으로 취급하는 이 책의 방식에 상당히 흥미가 생기더라. DBA의 역할은 쓰레기통 뒤치닥거리나 콜센터 요원이 아니라는 게 골자. 역시 모두가 머리싸매고 고민하는 것처럼, "기계가 할 수 있는 일은 기계한테 줘버리고 넌 사람만 할 수 있는 일을 하세요" 인 것이다. 아무래도 쉉은 대용량 자료들하고 관계있는 업계에서 일을 하다보니, DBA가 얼마나 스트레스를 받을 것인지 좀더 와닿는듯. 그러나 대부분의 회사에는 DB팀이 따로 있는지라, 윗사람이 되지 않는 이상에야 비효율을 고치는 건 상당히 힘들지도(...).
  • "개발자도 DB를 왠만큼 잘 알아야 된다!!!" 라는 설교에 뜨끔 ㅠㅠ. 쉉은 사실 DB를 좀 싫어한다. 순전 취향+걸어온 길의 영향이라고 볼 수 있지. 그래도 개발을 하는 이상(게다가 요새는 DB랑 좀 많이 상관 있어진 일을 하게 되었다 ㅡㅡ;;) 편식을 하면 안되나보다.
    
    
• "코드 검사의 자동화"
  
  
  • 왠만큼 제정신인 회사들은 형식은 조금씩 달라도 다 저마다의 "Coding Standard"를 가지고 있다. 하지만 대부분 "이렇게 제발 해주세요" 하고 매뉴얼로 권장만 하고, 강제할 수단이 거의 없다. 그래서 보통 Coding Standard를 무시하는 개발자(개발  프로세스를 무시해야 개발을 빨리 끝낼 수 있다는 미친 생각을 하는 개발자들이 세상엔 꽤 많은 것 같다)들이 개발(말 그대로 dog의 foot을 의미) 코딩을 해놓고, 다음과 같은 순서로 일이 진행되는 듯.
    
    
    • 그나마 정해놓은 Rule을 검사도 안하는 회사에선, 걍 그러고 만다. 그 코드는 시간이 지나면 만든 사람도 모르는 코드가 된다.
    •  나중에 회사에서 정한 Coding Standard를 지키기 위해 몇주씩 체력소모작업을 한다(오마이갓).
    
    솔직히 난 이걸 자동적으로 검사해 주는 툴이 있다는 정보를 잘 몰랐다. 그래서 표준을 안지키는 개발자를 원망만 했지. 때로는 나도 못된 버릇이 들어 표준을 잘 안지키기도 했고 ㅠㅠ.
    정적 검사 툴들이 얼마나 도움을 주는지 함 구해서 써봐야 할듯.
    
    
• 챕터 시작 부분마다 있는 명언(?)들
  
  
  • "이 빌어먹을 우주는 조각조각 내서 다시 구축해야 한다"
    4장 도입부의 명언이다. 우왕국!!! 머찌다!! 이 밖에도 가슴에 팍팍 꽂히는 명언들이.. 쎈쑤쟁이!!!
    
    
• 머릿말과 역자서문 아스트랄!
  
  
  • "저는 영원처럼 느껴질 정도로 오랜 세월 지속적인 통합에 푹 빠져 지내왔습니다."(폴 줄리어스의 머릿말 중)
    -->감상: 컴덕후시군요(머엉).
    
    이 책의 온갖 머릿말들은 꼭 놓치지 않고 정독하시길.ㅋ.

• 코드 리뷰
  
   정말정말정말정말 필요하다고 생각. 개슈든 버리버리 개발자든 옆에 줄주리타가 있으면 큰 힘이 되는 것이 자명하다.
  
  "페어프로그래밍"도 "눈이 네 개일 때 더 버그도 잘 잡고 일도 빨라지고 둘의 이해도도 완벽해진다"라는 배경에서 출발했지만, 나의 경우 사람에 따라 지나치게 긴장해서 체력이 급강하 되고 머리가 잘 안풀리는 문제 또한 있었다. 특히 상사의 경우, 시험감독이 뻔히 보고 있는 앞에서 덜덜덜 거리며 문제를 푸는 느낌이랄까;-;;..
  
  반면 현실적으로 부딪히는 문제는, 많은 회사의 개발자가 자기 일만으로 헐떡헐떡 거려 남의 코드를 볼 마음과 시간의 여유가 없을 때가 많다는 것. 이 여유를 만들어주고 리뷰를 귀찮다고 생각하지 않게 만드는 게 제일 허들.
  
  
  
•  일일 회의
  
   매일매일 한다는 사실보다는, "모든 구성원이 말을 하게 만들어야 한다" 라는 점이 특히 공감이 간다. 한국 사회의 특성인지, 연구실이고 회사고 모임의 장으로부터 조금씩은 수직적으로 일을 하는 성향이 다들 배여 있고, 회의도 위에서부터 잔소리 듣는 시간이 되기 쉽다. 모두가 자신의 일에 대해 꿍얼꿍얼 말을 열기 시작하면, 자연스레 위아래/수평적으로 의사소통이 될 여지가 많다.
  "적당한 폴링"을 자연스럽게 하는 효과도 있을 듯.
  
  그나마 제시한 회의 형태와 가장 유사했던 게 대학원 때 일주일에 한번 진행했던 "팀미팅"이다. 물론 "교수님과 나 사이의 일방적인 보고 활동"에 가까웠다는 건 좀 아쉬웠어도, 내가 뭘 하고 있는지 내가 설명하면서 스스로가 정리되고, 남이 대충 뭘 하는지도 꿍쳐 들을 수 있는 게 좋았다. 개슈 선배들에게 조언도 많이 들을 수 있었고..
  
  일일 회의가 문제가 될 만한 게 있다면, "쓸데없는 회의는 하지 않는다"를 주장하는 개발자들도 많다는 것. 사실 그것도 그들 입장에선 맞는 말이긴 하다. "쓸데 있는 회의"를 만들어 시간낭비라고 생각하지 않게 하는 게 중요하겠지. 뭐 "매일매일"이라는 건 실제 도입했을 때 얼마나 효과가 있을지 궁금하다 정도?
  
  
  
•  테스트 주도 개발
  
   말할 필요도 없이 멋지구리!!.
  
  업종 전환 전 '임베디드 스러운' 일들을 잠시 할 때는 테스트 시나리오는 끝도 한도 없이 있고, 손으로 하지 않으면 테스트할 수 없는 기능들이 많아 머리가 아팠다("핸드폰을 켜고 새 동영상 업로드를 3건 시도하고, 3건 째가 올라가는 중에 갑자기 배터리를 손으로 뺀뒤, 다시 핸드폰을 켜본다"라는 시나리오는 로봇을 만들지 않는 이상 사람이 할 수밖에 없다. "전원을 끈다"와 "배터리를 뺀다"는 저언혀 이 세계에서 다른 개념이므로 ㅠㅠ).
  이렇게 고생스러운 분야이기에 오히려 "테스트 할 수 있는" 시나리오는 모두 빡세게 테스트 하는 습관들이 좀 된다 싶은 기업들이라면 박혀있는 듯. 테스트 가능한 아이들을 완벽히 통과시키면 그만큼 "고생스러운 테스트"에서 "괴로운 디버깅"을 할 가능성도 줄어든다는 것을 몸으로 알고 있기 때문이다(뭐 물론 무식한 회사들이 없는 건 아니다==.).
  각종 시뮬레이터와 에뮬레이터, CAD 툴들에 대해서도 수없이 많은 논문과 방법론들(반 이상은 다시는 안쓰일지도 모를)이 나오는 이유도 이것 때문이겠지.
  
  요새는 또 다른 이유로 여러 가지 머리가 지끈지끈 아픈데, 업종전환(?)을 한 분야의 테스트가 참말로 "광활하기" 때문이다. 그러나 이쪽은 머리를 잘 쓰면 훨씬 편하게 살 수 있을 여지가 있어보여 끙차끙차 중. 임베디드 쪽이 나무 구멍에다 작대기를 사흘 밤낮으로 비벼대며 불을 피울 수밖에 없는 쪽이라면 이 곳은 무려 부싯돌이 있는 느낌이랄까!!!. 가짜 객체라든지도 얼마든지 적용이 가능한 분야라니!!
  이쪽에 관련한 끙차끙차 고민거리들은 추후 가끔 포스팅에 보일지도 모르겠다.
  
  이 책의 "Test Driven"은 다른 실용주의 책과는 좀 달리 "손에서 상상할 수 있는 레벨"이라는 게 재미있다.
  

• Part 1 : 캐릭터, 종교 관념, 짐승들 등 이 책의 배경에 대한 사전 답사
• Part 2 : Castaway life (A)
  • human --> animal 로 변질(?)해 가는 Pi의 변천사(한마디로 야생라이프).
  • 다른 생물들과 어떤 관계를 맺으며 살아가는지.
• Part 3 : Castaway life (B)
  • animal --> human으로의 복귀(?)
  • "혼자됨"

여기에 16살 짜리 소년이 어떻게 부모님 없이 홀로서기 하는지 성장드라마 컨셉 추가.

• "alpha male" vs "omega male"
  
  보통 우리는 "alpha"는 시작, "omega"는 끝을 의미한다고 많이 알고 있다. 이와 유사하게, alpha male과 omega male은 서로 반대의 의미이다. 간단히 말하면 alpha male은 "leader", omega male은 "follower"이라고 할 수 있겠다.
  
  이 이야기에서 파이와 호랑이 리차드 파커는, 타고 있던 배가 침몰하고 이러저러하다 달랑 둘만 남아 오랜 시간을 표류한다. 이 시간 속에 파이와 리차드 파커의 관계는 다음과 같이 변한다.
  
  
  
  • 초기 : 파이는 리차드파커가 무서워요. 여차하면 도망갈래!! 하고 피난처(?)를 만든다
  • 중반 : 동물원 가정(?)에서 자란 파이는 "내가 살려면 별수 없이 호랑이를 길들여야돼"라고 생각하기 시작하고, 살기 위해 별수 없이 길들이기를 시작한다.
  • 말기(?) : 파이는 능히 호랑이를 컨트롤 할 수 있게 된다. 무려 나중엔 서커스 재주넘기도 시킨다(머엉).
  
  
  보통 사람 보통 정신이면 당최 애시당초 잡아먹혔을 텐데 갱장한데~!! 라는 소감은 일단 제껴두고(...).
  
  즉 파이는 이런 과정들을 통해 점점 리차드 파커 호랭이를 "omega male", 자신을 "alpha male"로 각인시켜간다.
  물론 나중에 헷갈리는 대화들을 보면 파이는 리차드 파커를 자기 자신이라고도 생각한 것 같고, 인생의 위기를 같이 헤쳐나간 친구라고도 생각한 듯 싶다. 단순히 주종관계는 아닌거지.
  내가 파이를 "alpha male"이라고 생각하지 않은 이유도 그거다. 그 또한 결국 외로움 때문에 호랑이를 떨궈내지 못한 거잖아? 게다가 호랑이는 그를 alpha male이라고 전혀 인식하지 않고 있다. 그가 진정한 alpha male이었다면, 호랑이의 영역을 마구 들어가도 호랑이는 깨갱 날 잡아잡수 했을텐데, 파이는 소심하게 경계선에서 어물쩍어물쩍하고 있었을 뿐.
  
  
• And so goes it with God.
  
  기적적으로 살아남은 파이가 일본에서 조사나온 양반들에게 어떻게 살아남았는지를 들려준다. 처음에 얼룩말, 하이에나, 오랑우탄, 호랑이가 있었고, 얼룩말, 하이에나, 오랑우탄은 죽어버려(긴 이야기라 설명 생략;) 호랑이랑 자신이 남았고, 어떤 일들이 있었고.. 이런 이야기들.
  
  그러나 당연하겠지만 그 양반들은 이야기를 믿지 못하고, 그런 짐승 나오는 얘기 말고 배가 왜 침몰했지 그런 얘기를 해주세요 하고 조른다. 파이는 "아 짐승 없는 얘기요?" 하면서 하이에나를 요리사로, 얼룩말을 항해사로, 오랑우탄을 엄마로, 호랑이를 자기 자신으로 transformation 해버린 버전을 들려준다ㅡㅡ;.
  
  짐승 버전과 사람 버전중에 어느 버전이 진짜같냐고 물으니, 일본 양반들이 "짐승 버전이 그럴 듯 하구나" 라고 답한다(솔직히 나는 사람 버전도 너무 리얼해서 이넘 정말 미친 게 맞구나라고 생각했다. 항해사의 다리를 요리사가 찢어버리고 요리사가 엄마를 죽여버리고 ㅡㅡ;;).
  
  아마 일본인 양반들은 둘다 말도 안된다고 생각하지만 어쩔수 없이 비위를 맞춰 줘야 하니 그런 말을 했을 게야.
  여튼 그 답에 이어서 파이는 이 말을 꺼낸다.
  
  "And so goes it with God."
  
  이게 당최 무슨 뜻인지 몰라서 "God knows it"과 비슷한 뜻일 거라 추측하고, "이게 진짜랍시고 파이가 말하는거냐, 아니면 표류생활동안 정신이 헷가닥해서 얘기를 몇백 페이지동안 마구 지어낸 거냐?"하고 헷갈려 했는데,
  
  원래 뜻은 인도에서 하는 인사인 "인샬라"라고. "If God is with me..." or "If God is willing..."이랑 비슷한 뜻이라 한다. 즉, 파이 자신은 표류 동안 벌어진 모든 이야기가 진실이라는 걸 확신하고 있었다는 것. "신이 날 보고 있었다면, 내 말이 진실이라는 걸 다 알고 있었을 게야." 이 정도라고 하겠다.
  
  (흠.. 근데 일본인들이 보고서에 "그는 정말 호랑이를 조련했어!!"라고 쓴건 뭐였을까. 결국 믿게 된거였을까나.)
  
  
• delusional
  
  "망상의"라는 뜻이다.
  "delirium"은 "delusion"의 동의어(그런데 스티브샘은 이걸 "미친 imagination"이라고 설명하더라 푸핫 ;-;ㅋ).