오리대마왕님 집

오리대마왕님 집 http://kingori.egloos.com 공부하세욧 ko Fri, 20 Nov 2009 15:48:36 GMT Egloos 오리대마왕님 집 http://pds.egloos.com/logo/1/200410/22/15/b0040115.jpg http://kingori.egloos.com 80 107 공부하세욧 <![CDATA[ [독후감]Hard Code ]]> http://kingori.egloos.com/4280383 http://kingori.egloos.com/4280383

HARD CODE -

에릭 브레히너 지음, 박재호.이해영 옮김/에이콘출판

요즘 책을 너무 안읽다보니 독후감도 참 오랫만에 올린다. 이전엔 출퇴근길에 열심히 책을 읽었는데, 요즘은 그냥 시체놀이 하느라 급급하다. 서서도 졸고, 앉아서 자고. 힘들다. 이리 지치다보니 이 책을 읽는데도 꽤나 오랜 시간이 걸렸다. 재미가 없는 것은 절대 아니다. 한번 붙들면 100페이지씩 읽어버렸는데, 거 참 왜이리 책이 손에, 눈에, 머리에 안들어올까 몰라.

이 책의 저자는 나잘난 박사라는 가상의 인물의 탈을 쓰고 마이크로소프트라는 엄청난 회사의 조직, 프로세스, 여러가지 관행들에 대해 비판하고 대안을 제시하는 컬럼의 묶음이다. 원래 마이크로 소프트 사 내부의 Inside 라는 잡지에 기고한 컬럼을 다시 보완하였다고 하네.

목차를 보면 "유행하는 또 하나의 소프트웨어 공학 에세이 아닌가!" 하는 생각이 들 것이다. 프로젝트 관리, 린 과 애자일을 포함한 프로세스 개선(우리회사 전공이다), 테스트, 품질... 조금 색다른 것이라고 해 봤자 7장의 경력관리, 10장의 자기회사 자랑(^^;) 정도? 스크럼, 린, XP 등의 애자일 책 읽어보고, 맨먼스 미신, 여러 품질 서적에 대해 뭐가 차별화 포인트냐! 내가 이름도 별로 들어본 적이 없는 저자가 쓴 이 책을 왜 사야해?

분명한 구매 포인트가 있다. 이 책은 철저히 마이크로소프트을 위해, 마이크로 소프트라는 조직을 먹잇감으로 하여 마이크로 소프트 사람이 쓴 책 이다. 여러 프로세스, 방법론, 에세이, 교과서들의 문제점은 이런 저런 사항을 죄다 고려하다보니 어찌보면 뻔한 소리만을 늘어놓는 듯한 느낌을 받게 된다는 것이다. 물론 많이 공부한 사람들은 그 중에서도 핵심적인 것을 발견하지만, 그러기 위해선 상당히 많은 내공이 필요하므로 많은 사람들이 '그래서 우리 현실에 뭘 어쩌라고!' 하고 발끈하게 된다. 그럴 땐 우리 회사에서 컨설팅을 받으세요(!). 그러나 이 책은 마이크로소프트라는 특정 회사에 한정하여 실질적인 이야기를 풀어나가므로 훨씬 현실감있게 다가온다. 예시가 아니라 현실이다! 물론 헐떡이며 연명해가는 일반 SW 회사가 아닌, 마이크로소프트라는 공룡이라서 이런 현실 자체가 우리에겐 판타지 일 수 있겠지만 말이지.

무척 재밌고 흥미로운 책이다. 다만 내가 너무 띄엄띄엄 읽어서 지금 첫부분이 가물가물한데, 가장 최근에 읽은 뒷부분이기도 하고 다른 책에서 많이 다루지 않는 7장의 경력 개발 부분이 신선했다. 인맥 다지기, 인생의 불공평함 등등 아주 재밌었다. 내가 관심을 갖고 있는 부분인 프로세스에 대해서도 대기업의 관리직 답게 일방적인 애자일 칭송이 아닌, 실질적인 균형감각을 찾기 위한 고민들이 녹아있는 점이 좋았다. 읽을 땐 좋았는데 지금 기억이 잘 안난다. 아무래도 한번 날 잡고 처음부터 끝까지 휘리릭 다시 봐야 머릿속에서 내용이 살아날 듯 하네.

추천! 마이크로소프트 내부를 책으로나마 훔쳐볼 수 있는 좋은 기회를 놓치지 말자!

tag : 독후감, IT, SE, hardcode ]]> 감상문 독후감 IT SE hardcode http://kingori.egloos.com/4280383#comments Fri, 20 Nov 2009 15:47:11 GMT 오리대마왕 <![CDATA[ [공연감상]Mr.Big 내한공연 (2009/10/25) ]]> http://kingori.egloos.com/4265454 http://kingori.egloos.com/4265454
Mr.Big 내한공연 소식은 진작에 들었다. 근데 그 날이 딱 Grand Mint Festival 과 겹치고, 전날엔 밴드 MT를 갔다 돌아오는 날. 일단 토요일은 접고, 일요일에 GMF 를 갈 것인가 Mr.Big 을 갈 것인가 고민하던 차에 예전 밴드 드럼 형이 같이가자고 전화 주셔서 바로 Mr.Big 으로 선회했다.

10/25일 올림픽 공원은 정말 사방에 음악이 넘쳐났다. 체조경기장 옆의 공터엔 담장이 쳐져 있고, 마침 장기하와 얼굴들의 "달이 차오른다 가자" 가 울려펴지고 있었다. 마침 담장 낮은 쪽에서 무대와 화면이 보였기에 "아싸 째수~" 를 외치면서 잘 봤지.

일요일 공연은 7시에 시작하는 토요일과 다르게 6시에 시작했다. 동행인 형과 만나 좀 일찍 입장을 했다. 당연히 스탠딩 석이다. 폴 길버트 측 구역이었고, 앞에서 한 5째 줄 정도였다. 자리는 아~주 좋았다. 눈앞에서 폴 길버트의 기타 연주를 보게되다니!

약간 찾아본 토요일의 공연 후기와 달리 일요일 공연은 오프닝이 없이 바로 본 공연을 시작하였다. 오늘의 공연이 09년도의 월드 투어 마지막 공연이라고 하더라.

내가 Mr.Big 의 광팬은 아니어서 몇 곡은 잘 모르는 것들도 있었는데, 내가 아는 Mr.Big 곡들은 거의 다 했다. 오프닝 곡은 Daddy, brother,lover,little boy 였고 다음 곡이 take cover. 난 take cover 하나만 바라보고 갔는데 바로 두번째에 해 주셨네. 그냥 멍~ 하니 봤다. 최고로구나!!! 그 이후부터는 순서는 잘 모르겠고 내가 아는 곡으로 다음 곡들을 했다. (셋 리스트는 focus 님 블로그에서 가져옴)

Daddy, Brother, Lover, Little Boy (The Electric Drill Song) , Take Cover , Green-Tinted Sixties Mind , Alive And Kickin’
, Just Take My Heart ,Wild World , Addicted To That Rush , To Be With You ,Colorado Bulldog , Smoke On The Water

focus 님 블로그에 나온 토요일의 set list 와 일요일 set list 는 조금 달랐다. 일요일엔 두번의 앵콜을 해 주었다. ( to be with you 와 coorado bulldog 은 첫째 앵콜, smoke on the water 와 뭔지 모를 곡은 두번째 앵콜 ) 음, 의도된 두번의 앵콜이었나? 하핫.

가장 좋았던 곡은 역시 take cover 였고, addicted to that , daddy, colorado 이 세 곡은 잘 알고 좋아하는 곡이라 좋았다. 라이브에서도 실제로 드릴을 쓰는구나!!

허접하나마 기타를 취미로 하기에 폴 아저씨의 손꾸락 보느라 2시간 반 동안 그냥 입을 헤~ 벌리고 있었다. 저게 사람인가! 그냥 최고의 시간이었다. 안왔으면 정말 후회할 뻔 했어.

빌리 시헌과 폴 길버트의 솔로도 뭐 그냥 죽여줬는데, 빌리의 솔로가 너무 길어서 조금 지겨움을 느꼈다. 처음엔 "으아~ 최고다!" 하며 감탄을 연발했지만 한 5분 지나니 슬슬 질리더라. 반면 기타쟁이라 그런지 폴의 솔로는 지겨운 줄 모르고 쳐다봤지.

아, Mr.Big 까지 라이브로 보다니. 아주 즐거웠던 공연이었음.

tag : 내한공연, 음악, mr.big ]]> 음악 내한공연 음악 mr.big http://kingori.egloos.com/4265454#comments Thu, 29 Oct 2009 15:12:34 GMT 오리대마왕 <![CDATA[ Java Transaction Design Pattern ]]> http://kingori.egloos.com/4231039 http://kingori.egloos.com/4231039

J2EE Transaction Frameworks: Building the Framework: onjava.com 에 2001년에 소개된 아주 오래된 자료이다. Transaction의 정의, Transaction 처리의 유형 및 구분 등등의 여러 개념을 설명하고 있다.
Java Transaction Design Strategies: InfoQ 에 2006년에 소개된 소책자이다. PDF로 되어있으니 읽기도 좋다. 책 이름에서 알 수 있듯이 programmatic, declarative 등의 transaction model 과 함께 EJB와 Spring 으로 이러한 transaction model을 적용할 때 활용할 수 있는 3가지 design pattern을 소개한다. 실무적으로 알아두면 좋은 내용이 많으니 한번 읽어보는 것도 좋겠다. 참고로 이 책의 존재는 Spring Reference 를 읽다가 알게 되었다.

트랜잭션 개요

트랜잭션이란?

조대협님이 작성한 글 자바로 구현하는 트렌젝션 프로그래밍에서 따온다. 참고로 난 트"랜잭"션이라 하였는데 조대협님 원글에서는 트"렌젝"션이라 하셨네. 내용은 원문 그대로 옮긴다.

1. 트렌젝션이란 무엇인가? (What is transaction ?)
트렌젝션이란, 중단없이 시작에서부터 종료까지 한번에 수행되어야 하는 하나의 작업단위를 이야기한다. 수행이 끝난후에는 중간에 작업이 실패되었을 경우에는 작업 수행전의 상태로 그대로 돌아가야 한다.

이해를 돕기위해서 쉽게 예를 들어서 설명하도록 하자, A계좌에서 B계좌로 1,000원을 계좌 이체를 한다고 가정하자. 이 작업은 다음과 같은 순서로 이루어지게 된다.
1) A계좌에서 1,000원을 인출한다.
2) B 계좌에 1,000원을 더한다.

만약 위의 작업을 수행하던 도중 A계좌에서 1,000원이 인출된 후에, 은행 시스템의 오류로 인해서 B계좌에 1,000원이 더해지지 않는다면, 중간에 1,000원이라는 돈은 공중에서 증발해 버린것이 된다. 이럴때는 다시 계좌이체를 수행하기 이전의 상태로 되돌려서 A계좌에로부터 1,000원을 인출하지 말아야 한다.

그래서 위의 1),2) 작업은 한꺼번에 이루어져야 한다. 계좌이체 작업과 같이 한번에 이루어져야 하는 작업을 트렌젝션이라고 부른다.

트랜잭션 기본속성 - ACID

역시 위와 같은 조대협님 글에서 따온다.

2. 트렌젝션의 기본속성 ACID (Transaction attribute “ACID” )
트렌젝션은 크게 4가지 특성을 가지는데 Atomicity,Consistency,Isolation,Durability로, 이 네가지를 줄여서 ACID라고 부른다.
그럼 이제 부터 이 ACID속성 각각에 대해서 좀 더 상세하게 알아보도록 하자.

Atomicity (원자성)
Database modifications must follow an all or nothing.
원자성이란, 하나의 트렌젝션이 하나의 단위로만 처리가 되어야 한다는것이다. 하나의 트렌젝션안에 여러가지 step 의 트렌젝션이, 하나로 처리가 되어야한다. 위의 계좌 이체처럼, 계좌에서 돈을 빼고, 그 돈을 다른 계좌에 넣는 것과 같이 두개이상의 step으로 구성되어 있더라도, 계좌 이체라는 하나의 트렌젝션으로 처리가 된다.
그래서, 어느 step에서라도 트렌젝션이 실패가 되었을 경우에는 모든 상태가 트렌젝션 상태 전으로 rolled back되서, 이전 상태를 유지해야 한다.
즉 트렌젝션의 원자성은 트렌젝션이 완전히 수행되거나, 아무것도 수행되지 않은 All or Nothing의 이미를 가지게 된다.
Consistency (일관성)
states that only valid data will be written to the database
트렌젝션이 종료된후에 저장되는 데이타는 오류없는 데이타만 저장되어야 한다.
다시 풀어서 이야기하자면 계좌이체 과정에서, 인출은 되었는데, 다른 계좌로 돈이 안넘어갔다던지, 트렌젝션이 끝난후에, 잘못된 데이타 값으로 변경되었던지, 데이타베이스 constraint가 깨졌던지 했을때, Consistency가 잘못되었다고 이야기하고, 이런경우에 그 트렌젝션 내용을 저장하지 말고, 이전 상태로rollback되어야 한다.
Isolation (격리성)
Multiple transactions occurring at the same time not impact each other execution
격리성이란, 트렌젝션중에 의해서 변경된 내용이 트렌젝션이 완료되기전까지는 다른 트렌젝션에 영향을 주어서는 안된다는 이야기이다.
Tx A라는 트렌젝션 수행중 EMP 테이블의 값을 변경했을때, Tx A가 완료되지 않은 상태에서 Tx B가 EMP 테이블의 값을 참고할 경우에, Tx A에 의해 변경된 값을 참고하는것이 아니라(아직 TxA가 완료되지 않았기 때문에) 기존의 값을 참고하게 해야한다.
Durability (지속성)
Ensures that any transaction committed to the database will not be lost.
지속성이랑, 트렌젝션이 완료된후에의 값이 영구저장소에 제대로 기록이 되어야한다는 의미이다. 트렌젝션이 완료되었는데, 디스크 IO에러,네트워크 등으로 그 값이 제대로 기록이되지 않거나 해서는 안된다는 이야기다.

위에 언급된 트랜젝션의 4가지 특성 중 격리성(Isolation) 에 대해서도 파고들 구석이 무척 많다. 스프링 프레임웍의 경우 트렌젝션 설정에서 이를 정의할 수 있고, DBMS 의 메뉴얼에서도 이를 찾아볼 수 있다. 궁금하면, 자바지기 박재성님의 PPT 자료, Spring JDBC를 참고하자.

관리 범위에 따른 트랜잭션 구분 - 지역 vs. 광역 트랜잭션

하나의 트랜잭션이 관리하는 자원의 범위에 따라 지역 트랜잭션(local transaction) 과 광역 트랜잭션(global transaction) 으로 구분 할 수 있다. 지역 트랜잭션과 광역 트랜잭션을 설명하기 위해서는 자원 관리자(Resource Manager) 와 트랜잭션 관리자(Transaction Manager) 개념을 먼저 설명해야 한다. 이 두 관리자들을 묶어 트랜잭션 참여자(Transaction Participants)라고 한다. 놀새님의 글, Distributed Transaction Introduce을 참고하면 자세한 그림을 볼 수 있다. 여기선 트랜잭션 참여자 각각의 간단한 설명만 소개한다. 놀새님 글의 설명을 조금 다듬었다.

자원 관리자: 트랜잭션 자원(RDBMS)에 대한 관리의 책임을 진다.
트랜잭션 관리자: 트랜잭션의 begin, commit, rollback을 책임진다. 또한 분산 트랜잭션의 경우, 분산된 자원 관리자들에 대한 "Two phase commit" protocol에 대한 책임을 진다.

내 경우 광역 트랜잭션을 써 본 적이 없어, 트랜잭션 처리를 꽤 많이 해 왔음에도 저런 개념이 있다는 것을 몰랐다. 좀 더 찾아보니, 지역 트랜잭션의 경우 DBMS가 트랜잭션 관리자와 자원 관리자 두 역할을 혼자서 수행한다. 그러니 지역 트랜잭션 만 써 본 나는 "그냥 트랜잭션 처리는 DBMS가 알아서 하나보다" 하고 넘어갔지. 좀 더 들어가면 TP 모니터(Transaction processing monitor) 유형 등등의 토픽이 있는 것 같으나(^^;) 일단 여기서 발을 뺀다. 자, 그럼 이제 다시 본론인 지역, 광역 트랜잭션으로 돌아가보자.

지역 트랜잭션은 하나의 지역 자원 관리자만이 관여하는 트랜잭션이다.
분산 트랜잭션(Distributed Transaction) 혹은 광역 트랜잭션은 여러 시스템에 걸쳐 실행되는 트랜잭션으로, 트랜잭션 실행을 위해서는 광역 트랜잭션 관리 시스템과 트랜잭션에 관여하는 모든 시스템들의 지역 데이터 관리자 간의 조정(coordination) 이 필요하다.

광역 트랜잭션 관련해서는 2PC(2 Phase Commit) 등등 토픽이 더 있는데, 관련 글들이 많으니 일단 여기선 skip~! 궁금하면 놀새님 글과 J2EE Transaction Frameworks 을 읽어보자. 광역 트랜잭션을 위해선 JDBC 드라이버도 XADriver 등의 광역 트랜잭션 지원되는 드라이버로 바꿔야 하고, 트랜잭션 관리자가 필요하다. 많은 글에선 광역 트랜잭션은 왠만하면 피하라고 한다. 운영도 힘들고, 오류가 발생했을 경우 원인을 규명하기도 쉽지 않다. 내 경험으로는, 떨어진 DBMS 간에 트랜잭션을 묶을 필요가 있을 경우 그냥 Oracle 의 DB 링크를 걸어 마치 지역 트랜잭션인 것 처럼 대응했었다. 그러나 JMS 등의 아얘 다른 기술을 묶기 위해선 광역 트랜잭션으로 갈 수 밖에 없겠지.

트랜잭션 프로그래밍

두가지 트랜잭션 프로그래밍 모델

트랜잭션을 프로그램으로 옮기는 형태를 의미하는 프랜잭션 프로그래밍 모델은 프로그램적 트랜잭션 모델(programmatic transaction model) 과 선언적 트랜잭션 모델(declarative transaction model) 두 가지가 있다.

프로그램적 트랜잭션 모델: 프로그램 코드 상에 트랜잭션을 구성하는 연산(Operation)의 묶음 혹은 절차를 상세히 기술한다. 가장 일반적인 방식은 쓰레드 상에 트랜잭션 처리를 위한 연산을 명시(marking)하는 것이다. 이에 따라 트랜잭션은 쓰레드를 umarking 하여 지연될 수 있고, 트랜잭션 컨텍스트를 지연 지점에서 재개 지점으로 전파하여 재개할 수 있다. (정확히 무엇을 의미하는 지 모르겠는데, 코드를 통해서 트랜잭션을 잠시 멈추거나 재개할 수 있다는 것으로 해석했다.) 커밋 요청은 트랜잭션에 참여하는 모든 자원 관리자에게 트랜잭션 내의 연산에 의한 변경을 영구적으로 저장할 것을 요청한다. 반대로 롤백 요청은 자원 관리자에게 트랜잭션 내 연산에 의한 변경을 취소할 것을 요청한다.
선언적 트랜잭션 모델: MS 트랜잭션 서버에 의해 관리되는 COM 컴포넌트 또는 EJB 와 같은 컴포넌트 기반 트랜잭션 처리 시스템은 선언적 트랜잭션 모델을 지원한다. 컴포넌트는 배포 시점에 트랜잭션 대상으로 명시된다. 이 방식은 두가지를 시사하는데, 첫째로 트랜잭션을 명시할 책임이 어플리케이션에서 컴포넌트를 관리하는 컨테이너로 이동한다는 것을 의미한다. (따라서 컨테이너-관리 트랜잭션이라는 이름이 붙는다). 둘째로는 트랜잭션 명시 시점이 어플리케이션 빌드 시점에서 컴포넌트 배포 시점으로 지연된다는 것이다.

정의가 좀 어렵긴 한데, 간단히 자바 개발자 시점으로 생각하면 "getConnection 해서 try 로 묶고, catch exception 하면 commit, 아니면 rollback 하라" 는 걸 코드로 짠다면 프로그램적 트랜잭션 모델, "이 컴포넌트 내의 연산은 트랜잭션 처리되어야 하며, ~~ exception 이 난 경우엔 rollback 하여라" 를 xml 등으로 명시했다면 선언적 트랜잭션 모델이라고 구분하면 되겠다.

선언적 트랜잭션 모델의 경우, 트랜잭션 적용 대상이 되는 작업의 처리 특성을 설정을 통해 시스템에 알려야 한다. 여기서 처리 특성이라 함은 트랜잭션의 ACID 속성과 관련이 깊다. 어떤 작업은 반드시 별도의 트랜잭션으로 구분되어야 하고, 어떤 작업은 트랜잭션의 범위 외어야 하는 등등이다. JTA 는 6가지 트랜잭션 속성(Transaction Attritbute) 을 정의하고 있는데, Required, Mandatory, RrequiresNew, Supports, NotSupported, Never 가 그들이다. Spring Framework 의 경우 Propagation level 에서 이를 설정할 수 있다. 상세설명은 anyframe 의 [참고] Propagation Behavior, Isolation Level를 참고한다.

EJB를 많이 해 본 개발자라면 모르겠지만, 난 Java 개발자면서도 EJB 를 한~번도 해 본 적이 없기에 Spring Framework 을 써 보기 전에 선언적 트랜잭션 모델이라는 것이 있는지도 몰랐다. 이를 위해서는 위의 설명에도 나와 있듯이, 컨테이너가 꽤 많은 작업을 떠 맡아야 하는데 대부분 EJB Container 들이 이를 맡기 때문이겠지. Spring 을 쓴 다면 Spring Container가 이를 담당한다.

세가지 트랜잭션 모델

Java Transaction Design Strategy에서는 위의 프로그래밍 모델과 관리 범위를 섞은 3개의 트랜잭션 모델로 구현 형태를 구분한다. 지역 트랜잭션 모델(Local Transaction Model), 프로그램적 트랜잭션 모델(Programmatic Transaction Model), 선언적 트랜잭션 모델(Declarative Transaction Model) 이 그 3가지 이다. 프로그래밍 모델과 이름이 겹치는데, 앞으로 동일한 명칭이 나온다면 여기서 이야기하는 트랜잭션 모델로 이해하면 된다. 참고로, 트랜젝션 프로그래밍 모델에서의 프로그램적 트랜잭션 모델과 트랜잭션 모델에서의 프로그램적 트랜잭션 모델은 동일하지 않다. 아래에 소개된 지역 트랜잭션 모델과 프르그램적 트랜잭선 모두 트랜잭션 프로그래밍 모델 구분에서 프로그램적 트랜잭션 모델에 해당한다.

지역 트랜잭션 모델: 프레임웍이 아닌 실제 데이터 소스를 제공하는 로컬 자원 관리자가 트랜잭션을 관리한다. DB의 경우, 자원 관리자는 DBMS 와 DB 드라이버를 통해 구현된다. JMS의 경우에는 특정 JMS 공급자가 구현한 큐 커넥션 팩토리가 자원 관리자에 해당한다. 지역 트랜잭션 모델에서는 개발자가 트랜잭션이 아닌 커넥션을 관리하고, 실제 트랜잭션을 관리하는 것은 자원 관리자이다.
프로그램적 트랜잭션 모델: JTA(Java Transaction API) 와 트랜잭션 서비스 구현체를 통해 트랜잭션을 관리하며, 지역 트랜잭션의 약점을 보완한다. 프로그램적 트랜잭션 모델에서 프로그래머는 커넥션이 아닌 트랜잭션을 관리하는 코드를 작성한다. 일반적으로 프로그램적 트랜잭션 모델은 권장되지 않지만, EJB의 경우 클라이언트에 의해 트랜잭션이 시작되는 경우에는 유용하게 활용된다.
선언적 트랜잭션 모델: EJB에서는 컨테이너 관리 트랜잭션(CMT;Container-Managed Transaction) 이라고도 하며, 프레임웍 혹은 컨테이너가 트랜잭션의 시작과 종료를 담당한다. 개발자는 XML 등으로 기술된 환경 인자를 통해 프레임웍에게 트랜잭션 처리 정보를 전달한다.

별다른 transaction framework 없이 개발했다면 아마 대부분 지역 트랜잭션 모델을 사용해 왔을 터이고, EJB 나 Spring Framework 등등을 사용했다면 아마도 선언적 트랜잭션 모델을 활용했을 것이다. 프로그램적 트랜잭션 모델은 좀 특별한 경우 정도에만 쓰인다고 보면 될 것 같다.

지역 트랜잭션 모델의 문제점은 아마 다들 잘 알고 있을 것이다. 일단 개발자가 오류를 범하기 쉽다. 제대로 connection 을 close 하지 않거나, autocommit 등을 해제하지 않는다던가 하는 문제를 개발자가 일일이 신경써야 한다. 또한 지역 트랜잭션 모델로는 광역 트랜잭션을 관리할 수 없다. 따라서 간단한 웹 어플리케이션 정도에 적합한 방법이다.

따라서 본격적인 트랜잭션 처리를 위해선 프로그램적 트랜잭션 모델 혹은 선언적 트랜잭션 모델로 넘어가는 것이 권장되는데, 이 중에서 선언적 트랜잭션 모델은 프로그램적 트랜잭션 모델에 비해 여러 장점이 있기 때문에 많은 경우 선언적 트랜잭션 모델이 권장된다. 선언적 트랜잭션은 개발자가 직접 트랜잭션을 시작하지 않아도 되고, 트랜잭션 속성이 빌드 시점이 아닌 배포 시점에 결정되기 때문에 재사용하기에도 잇점이 있다. 선언적 트랜잭션 모델 기반으로 작성된 코드를 한번 보면 왜 이 모델이 개발자 입장에서 좋은 지 쉽게 알 수 있을 것이다. 코드 예시는 Java Transaction Design Strategy 등에서 쉽게 찾아볼 수 있다.

트랜잭션 설계 패턴

Java Transaction Design Strategy은 제목에서 알 수 있듯이, 대표적인 3가지 트랜잭션 설계 패턴을 제시하고 있다. Client owner transaction design pattern, Domain service owner transaction design pattern, Server delegate owner transaction design pattern 이다. (한국어로 바꿔보려 했지만 난감하네.) 각 패턴은 "누가 트랜잭션에 대한 관리 책임을 가지고 있는가?" 에 의해 구분된다. 각각에 대한 간략한 설명은 다음과 같다.

Client owner transaction design pattern: Clinet Delegate 컴포넌트가 JTA 트랜잭션을 관리한다. 이 패턴은 웹 혹은 스윙 어플리케이션에서 EJB 와 원격 Stateless SessionBean 을 사용할 경우 많이 쓰이지만, 원격 어플리케이션이 아닌 경우에도 적용할 수 있다. 다수의 로컬 fine-grained 서비스 객체를 가진 어플리케이션에서 하나의 클라이언트 요청이 여러 서비스 객체들에 대한 다수의 요청을 통해 처리되는 경우이다.
Domain service owner transaction design pattern: 아마도 가장 널리 사용되는 모델일 것이다. 도메인 서비스 컴포넌트가 트랜잭션 처리를 관장한다. EJB 라면 도메인 서비스 컴포넌트를 Stateless SessionBean 로 구현하고, 선언적 트랜잭션 모델을 적용한다. Spring 이라면 POJO 형태의 도메인 서비스 컴포넌트와 선언적 트랜잭션 모델로 구현할 수 있다.
Server delegate owner transaction design pattern: 아키텍처가 Command 패턴 혹은 Server Delegate 설계 패턴을 사용할 경우 적용할 수 있다. 원격 요청에 대한 서버의 접근 지점인 Server Delegate 컴포넌트가 트랜잭션을 관장한다. 그 외의 다른 컴포넌트는 직접 트랜잭션을 관리하지 않는다.

하나 하나를 좀 더 자세히 살펴보자. 참고로 모두 Java Transaction Design Strategy 에 상세히 소개되어 있으니 이를 참고하자. 클래스다이어그램 등등을 따오고 싶으나 저작권 관계를 잘 몰라서 내용만 축약한다. (이것도 문제가 될까?) 책 원문에는 EJB 와 Spring Framework 로 이를 구현한 예제까지 제시되어 있어 쉽게 이해할 수 있을 것이다.

Client owner transaction design pattern

클라이언트가 트랜잭션을 관장하는 것 자체가 그다지 바람직하지는 않지만, 꼭 필요한 경우가 있을 경우 적용할 수 있는 패턴이다. 클라이언트가 트랜잭션을 관리하는 경우는 대부분 서버측 서비스가 매우 세분화 되어있고, 이를 통합해 주는 서비스가 제공되지 않는 상황에 해당한다. 여러 서버측 서비스에 걸친 요청을 트랜잭션 처리해야 할 경우 클라이언트가 이를 관리할 수 밖에 없다. 그러나 이는 유지보수 등 여러 문제를 불러일으킬 우려가 있다.

보통 서버가 관리한다면 트랜잭션의 범위가 서버 어플리케이션 내부이지만, 이 경우는 클라이언트에서 시작해서 서버 요청까지 범위가 확장되어야 한다. EJB 라면 클라이언트 쪽 구현은 반드시 프로그램적 트랜잭션 모델로, 서버 쪽 구현은 반드시 선언적 트랜잭션 모델로 구현해야 한다. 원격 서버일 경우 Spring Framework 는 원격 서버로의 트랜잭션 전파(Propagation) 을 지원하지 않기 때문에, RMI 등등의 protocol 을 사용해서 이를 구현해야 한다. 이는 Spring Framework reference 문서에도 명시되어 있다.

The Spring Framework does not support propagation of transaction contexts across remote calls, as do high-end application servers. If you need this feature, we recommend that you use EJB. However, consider carefully before using such a feature, because normally, one does not want transactions to span remote calls.

Domain service owner transaction design pattern

그냥 어지간한 경우는 모두 이 패턴이라고 볼 수 있다. Spring 구현을 보자면 트랜잭션 관리를 하는 Service POJO 들을 만들고, 이 Service 객체안에 조회, 생성, 수정 등등의 기능들을 구현한다. 필요에 따라 이들은 하나 이상의 DAO 등을 호출할 수 있지만, DAO 는 트랜잭션에 참여하지만, 트랜잭션 자체에 대한 내용을 알지 못한다. 클라이언트는 트랜잭션 처리를 하지 않는다. Spring 이나 EJB 모두 Service 객체에 선언적 트랜잭션 모델을 적용하여 패턴을 구현할 수 있다.

Server delegate owner transaction design pattern

위의 Domain service owner 패턴은 Service 컴포넌트가 어느정도 덩치가 있어 하나의 트랜잭션이 컴포넌트 범위를 벗어나지 않는 것을 가정하고 있다. 그러나 하나하나의 Service 컴포넌트가 세부 수준으로 작성되어 있어 복수의 Service 요청들을 묶어 트랜잭션으로 관리해야 하는 경우라면 이 Server delegate 패턴을 고려함 직 하다.

적용

우리나라의 일반적인 환경이라면, 대부분 Domain service owner transaction design pattern을 이미 활용하고 있을 것이다. 요즘은 많은 SI 프로젝트이 Spring framework 를 적용하고 있다고 하니, 선언적 트랜잭션 모델도 손쉽게 적용할 수 있을 것이다. 선언적 트랜잭션 모델을 써 보니, 예전의 connection 가져오고, try -catch 묶고, exception 발생하면 rollback 처리하던 형태로 돌아가지 못할 것 같다. 또한 국내 많은 SI 프로젝트에서 쓰는 iBatis 의 경우, Spring 의 iBatis ORM 지원 기능을 사용한다면 더더욱 쾌적하게 개발할 수 있을 것이다.

tag : java, transaction, programming, IT, spring ]]> 콤퓨타 java transaction programming IT spring http://kingori.egloos.com/4231039#comments Sat, 10 Oct 2009 18:41:00 GMT 오리대마왕 <![CDATA[ 네오딴 6회 공연합니다. ]]> http://kingori.egloos.com/4236691 http://kingori.egloos.com/4236691

이젠 네오위즈 직원도 아니건만, 염치없이(^^;) 계속 네오위즈 사내밴드 네오딴에서 기타를 치고있다. 다음주 금요일에 공연하니 많이들 보러 오이소~~

장소: 신림동 4번출구로 쭉 나오면 있는 락스타홀 (구. 타임투락)
일시: 2009.09.25(금) 20:00
입장료: 무료

근데 나 그날 야근하면 우쩌지;;;

tag : 네오딴, 공연 ]]> 음악 네오딴 공연 http://kingori.egloos.com/4236691#comments Thu, 17 Sep 2009 11:38:06 GMT 오리대마왕 <![CDATA[ windows 에 redmine 깔고, gmail 로 이슈 메일 보내기 ]]> http://kingori.egloos.com/4236006 http://kingori.egloos.com/4236006

1. redmine 설치

bitnami 를 이용하면 아주아주 쉽게 설치할 수 있다. 만약 이전에 깔아놓은 mysql 등의 DBMS, svn 등의 형상서버, apache, ruby 등을 활용하고자 한다면 해당하지 않을 수 있는데, 아무것도 없는 상태에서 redmine 만 돌리고자 한다면 정말정말 편하게 한방에 깔 수 있다. bitnami redmine 페이지에서 redmine stack 을 다운받아 설치하자. 주의할 점은 설치 중 이름 등등을 넣는 화면에서 한글을 입력하면 DB 초기화 시 에러나서 수동으로 migration 해 줘야 한다. 설치할 때는 그냥 안전하게 영어로 입력하자. 한글 입력시 설치 오류 문제는 내가 forum에 보고했다.

bitnami redmine stack 이 제대로 깔렸다면 http://localhost/ 로 들어가면 bitnami 페이지가 나오고, 거기서 redmine 클릭하면 redmine 페이지가 나올 것이다.

2. gmail smtp 설정

메일 발송 없는 이슈트레킹 시스템은 앙꼬없는 찐빵이다. 절대 사람들은 주기적으로 ITS 를 확인하지 않는다. 메일 폭탄은 피해야 하겠지만, 하여간 이슈 상태 변경 시 (적어도 등록/해결 시) 메일 보내줘야 한다. 메일 발송 설정이 꽤나 골치아프다. 별도의 smtp 서버 쓸 게 없다면 gmail 의 smtp 를 사용하자.

일단 발송을 위한 gmail 계정을 만들자. 물론 자신의 gmail 계정을 사용해도 되지만, 설정파일에 자신의 e-mail과 gmail 패스워드가 고스란히 표현되기 때문에 신규 계정을 만드는 것을 추천.

계정을 만들었다면, 이제 redmine 이 gmail smtp 를 사용할 수 있도록 설정하자. 그냥 하면 안되고, 플러그인을 하나 설치해야 한다. 전체 내용은 Setup Redmine to send email using GMail 에 잘 나와있다. 그런데 내 경우 파일이 하나도 다운로드 되지 않았다. 이 경우 git 페이지에 가서 그냥 무식하게 파일을 하나하나 local 로 복사해버리면 된다. 내 경우 C:\Program Files\BitNami Redmine Stack\apps\redmine\vendor\plugins\action_mailer_optional_tls 폴더 밑에 git 페이지의 구조대로 고스란히 퍼 왔다. 참고로 redmine gmail 로 검색해보면 git repository 가 아닌 svn repository 주소가 검색될 수 있는데, 이 plug-in 을 받으면 에러난다. 반드시 git repository 에 있는 plug-in 을 받아야 한다.

plug-in 깔았다면 redmine service 를 다시 시작하자. 이제 redmine 설정 페이지에서 test 메일을 발송해보자. 잘 날아가면 ok.

3. 만약 한글 메일 제목이 깨진다면?

특정 사용자들에게서 메일 제목이 깨져서 온다는 의견을 접수받았다. 우선 gmail 의 설정 페이지에서 모든 발송을 utf-8 기반으로 하도록 했다. 여전히 깨진다. 그래서 mailer-subject-base64.patch 를 적용하니 잘 해결되었다.

4. 메일이 너무 많이 와서 짜증난다면?

이 부분은 일종의 사파적인 해결책이라 할 수 있겠다. 기본적으로 이슈에 대한 모든 변경이 발생할 경우 메일이 발송되는데, 너무 많은 메일은 너무 적은 메일과 마찬가지로 문제이다. 너무 메일이 많이 날아가면 다들 걍 지워버리는 상황이 발생할 수 있다. 이슈에 대한 담당자가 한 명이고, 담당자 제외한 사람들은 이슈의 등록과 해결에만 관심이 있을 경우, 등록/해결 시점에만 메일을 날리면 된다. 자, 이제 직접 소스를 뜯어고칠 시점이다.

C:\Program Files\BitNami Redmine Stack\apps\redmine\app\controllers\issues_controller.rb 을 열어보면 이슈 등록,수정을 담당하는 코드가 있다. RoR 로 개발해 본 경험이 파일을 찾는데 도움이 되네. 대략 196 line 정도를 보면 다음 코드가 있다.
Mailer.deliver_issue_edit(journal) if Setting.notified_events.include?('issue_updated')
이 부분이 이슈 수정되었으면 메일 날리라는 부분이다. 그럼 난 종료에만 관심이 있으므로 if 문으로 위 내용을 감싸주자.

if @issue.closed?

   Mailer.deliver_issue_edit(journal) if Setting.notified_events.include?('issue_updated')

end

해결 끝.

tag : redmine, 이슈관리, PM ]]> 콤퓨타 redmine 이슈관리 PM http://kingori.egloos.com/4236006#comments Wed, 16 Sep 2009 11:53:57 GMT 오리대마왕 <![CDATA[ 매우 짧은 근황 ]]> http://kingori.egloos.com/4233893 http://kingori.egloos.com/4233893
같이 일하는 분들은 나보다 훨씬 빡시게 일하고 계신데 나 혼자 왜이리 지치는 것인지 모르겠다. 야근도 짜증나고. 요즘은 맘 같아선 도로 개발자로 컴백하고 싶은 마음도 든다. 그리 불평을 하면서도 IT 바닥을 떠날 용기는 나질 않는구나. 바보.

올해는 참 재미없다. 연말까지도 계속 재미 없을 예정이라 우울하구나.
]]> 잡설 http://kingori.egloos.com/4233893#comments Sun, 13 Sep 2009 15:47:32 GMT 오리대마왕 <![CDATA[ [독후감]프로그래밍 수련법 ]]> http://kingori.egloos.com/4218630 http://kingori.egloos.com/4218630

프로그래밍 수련법 -

브라이언 W. 커니핸.롭 파이크 지음, 장혜식.신성국.김정민 옮김/인사이트

그 유명한 The C Programming Language 의 저자 브라이언 커니핸 아저씨가 쓴, 좋은 프로그래밍을 위한 실천법이다. 이런 류의 실무 프로그래밍 잘 하는 방법에 관한 책을 몇 권 읽었는데 (읽은 책 중에서는 실용주의 프로그래머가 참 훌륭하였다), 이 책은 꽤나 low-level 한 수준에서 접근하고 있어서 다른 책들이 다루는 내용과 차이가 있었다. 같은 맥락에서 딱히 C 언어를 다루는 이를 위한 책은 아니지만, C 그리고 C++ 에 해당하는 내용이 상당 수 있었기 때문에 그보다 고수준 언어들 밖에 다뤄보지 않은 나는 '뭐 그렇겠구나, 중요하겠네' 하고 슬쩍 넘어간 부분이 꽤 된다. malloc, 포인터, macro 같은 녀석들과 친하지 않아서 잘 이해도 가지 않았고, 공부해도 당장 실무에 써 먹을 부분이 아니었다.

그렇지만 이런 C 언어-의존적인 부분 보다는 일반적인 프로그래밍을 다루는 부분이 훨씬 많으므로 이 책을 구매하는 것을 주저할 필요는 없다. 물론 C 나 C++ 을 다루는 사람이라면 더 많은 도움을 받을 것은 확실하지만 말이다. 그리고 이 책의 문체는 꽤나 명료하기 때문에 신뢰가 간다. "이런 것도 해 보면 더 좋지 않을까?" 와 같은 미심쩍은 표현보다는 "이러쿵 저러쿵하는 특별한 상황이 아니라면 이렇게 해라" 라고 딱 잘라 이야기 해 준다. 이 바닥 고수인 아저씨들 얘기니까 믿고 따라보자. 책 마지막에는 원칙 일람이라고 해서 책에서 제시한 교훈들을 보기 좋게 모아놓았으니 머리맡에 두고 코딩할 때 마다 새겨보자.

C 언어 관련된 부분을 더 잘 알았다면 별점을 더 줬겠지만, 슬렁슬렁 넘어간 부분이 좀 아쉬웠다. 그리고 그렇게 쉽지는 않고 천천히 고민해가면서 접근해야 하는 책이다. 나는 이해 못하고 그냥 넘긴 부분이 종종 있었다. 그래도 좋은 코딩을 위해서 고민하는 분들이라면 읽어봐도 좋겠다. 그러나 Java 개발자라면 effective java와 함께 좀 더 일반적인 접근을 하는 프로그래밍 책을 읽는 게 더 도움이 되지 않을까?

tag : 독후감, IT, programming, 프로그래밍수련법 ]]> 감상문 독후감 IT programming 프로그래밍수련법 http://kingori.egloos.com/4218630#comments Mon, 24 Aug 2009 13:09:43 GMT 오리대마왕 <![CDATA[ [독후감] 파인만 씨, 농담도 잘하시네! ]]> http://kingori.egloos.com/4212468 http://kingori.egloos.com/4212468

파인만 씨, 농담도 잘하시네! 2 -

리처드 파인만 지음, 김희봉 옮김/사이언스북스

내가 다닌 대학교는 2학년 때 전공을 선택하는 특이한 시스템을 자랑하고 있어서, 1학년 때에는 마치 고등학교처럼 신입생들을 반별로 배치하였다. (난 이것이 매우 좋은 제도라고 생각한다. 고등학교에서 똑같이 배우고 올라온 애들에게 평생 밥벌이를 좌지우지 할 수도 있는 전공을, 그것도 점수대별로 선택하라는 것은 너무 과격한 처사이다) 기본적으로 반 별로 교과과정에 큰 차이는 없었으나 한가지, 물리만은 예외였다. 총 20반 중 1,2반은 기초물리였던가? 하여간 좀 쉬운 물리, 19,20반은 고급물리로 어려운 물리를 배우는 반이었다. 나야 그냥 무난하게 일반 반으로 배정되었다. 그 당시 19,20반의 고급물리반에서 사용한 교재가 이 책의 저자인 리처드 파인만 아저씨가 쓴 Lectures On Physics 였다. 깜장색 하드버커에 박힌 글씨가 참 멋졌다. 친구가 고급물리반이라 이 책을 좀 들춰봤는데, 고급물리 선택안한것이 참으로 탁월한 선택이었음을 알게되었다. 너무 어려워!

이 책은 이 유명한 물리학자인 리처드 파인만의 소소한 에피소드를 기록한 에세이집이다. 소소한 에피소드라고는 하나, 아인슈타인과 대화를 하고, 전산장이들이라면 아인슈타인보다 더욱 벌벌벌한 인물인 폰 노이만도 살짝 등장하는 등 전혀 소소하지 않은 내용들도 나온다. 노는 물이 틀리니 뭐...

책 내용을 한 문장으로 정리하자면, "나 리처드 파인만인데, 난 좀 짱이야!" 으로 정리할 수 있겠다. 이 책을 빌려준 친구도 빌려주면서 지 자랑만 가득하다고 했는데, 맞네. 근데, 이 형아는 짱이라서 자기 자랑만 줄줄이 늘어놓아도 전혀 위화감이 없어. 허허

1권은 어린 시절의 일화가 많고, 1권 후반부터 2권은 본격적인 성인물로, 원자폭탄 만들고 교수로 강의하는 등의 학자로서의 활동을 얘기하고 있다. 나는 1권의 초반부는 그다지 재미가 없었는데 1권 말미부터는 아주 재밌게 읽었다.

위대한 학자 중 한명의 소소한 일상을 들여다볼 수 있었다는 것이 참으로 흥미로운 책이었다. 딱히 공대생을 위한 책은 아니지만, 공대생이 아니라면 이 책 자체에 흥미를 느낄 수 있을까? 그런 연고로 공대생에 한정하여 추천.

tag : 독후감, 에세이, 과학, 리처드파인만 ]]> 감상문 독후감 에세이 과학 리처드파인만 http://kingori.egloos.com/4212468#comments Sun, 16 Aug 2009 11:10:19 GMT 오리대마왕 <![CDATA[ [독후감]Harnessing Hibernate ]]> http://kingori.egloos.com/4206701 http://kingori.egloos.com/4206701

하이버네이트 프로그래밍 Harnessing Hibernate -

제임스 엘리어트 외 지음, 정미영.황용대 옮김/한빛미디어

알라딘 링크에 한국어 번역판만 나와있어서 사진은 한국어판인데, 난 원서로 읽었으므로 이 점을 감안해 주시길 바란다. (변방 블로그라서 읽는 분도 얼마 안계시지만 하하하핫)

ORM Framework 은 예전에 써 본 적은 있으나, 그 이후로는 iBatis 정도의 SqlMapping 도구만 사용해왔다. 2006년 이후로는 개발 자체를 거의 안했고.

SI 위주의 우리나라 상황에서는 아직 널리 활용되지 않는 듯 하나, 외국에서는 거의 Spring + Hibernate 류의 조합이 굳건히 자리를 잡고 있다고 한다. ORM Framework 자체에도 관심이 많고, Hibernate 사용법도 미리 알아는 둬야겠고 하여 이 책을 집어들었다.

Hibernate이 전혀 낯설지는 않았다. 2004년에도 개발할 때 써 보려고 몇번 시도를 하다가 영 불편하고, column 일일이 매핑하는 게 짜증나서 그냥 자체적으로 만든 짝퉁 iBatis 을 사용했었다. 그때 내가 reference 문서를 제대로 읽지 않아서 삽질을 한 것이었는지, 아니면 당시의 Hibernate 성숙도가 낮아서 그랬는지는 모르겠지만.

서론이 너무 길었다. 책으로 돌아와서...

이 책의 성격을 딱 보여주는 것이 아마존 평점이다. 16명만 참가했으니 신뢰도는 떨어지긴 하다만, 5점이 전체 인원의 반인 8명인 반면, 3점 이하가 6명이다. 왜 그럴까?

목차를 한번 볼까?. 1부는 일반적인 ORM framework 책에 나올 법한 장들로 구성되어 있는 반면, 책 반절에 가까운 2부는 framework 자체와 크게 관계가 없는 도구 사용과 관계된 내용이다. Eclipse, Maven, MySQL connection 등등.

이 책의 미덕은 Hibernate(혹은 ORM Framework)를 처음 접하는 사람이 전혀 위화감없이 이런 새로운 환경에 적응할 수 있도록 친절히 가이드하는데에 있다. 그리고 프로젝트를 진행하는 데 있어 보다 편리하게 활용할 수 있도록 ant/maven 등의 자동build script 활용, Eclipse 등의 IDE 활용 방법을 제시하고 있다.

반면 내가 처음에 기대한 것(그리고 아마존에서 낮은 평점을 메긴 사람들의 커맨트에서 보이는 것)은 1. 복잡한 상황에서 Hibernate 를 효과적으로 활용하기 2. Troubleshooting 3. ORM 에서 흔히 지적받는 성능문제에 대한 해결책 이다. 이런 내용에 대한 답을 이 책에서 구하기는 힘들었다.

성격이 분명하여 호불호가 가릴 수 있는 책이다. 처음 접하는 사람이 보기엔 아주 좋다. 단계적으로 아주~ 친절히 설명하고 있고, ant script 를 통해서 쉽게 따라 할 수 있게 구성되어 있다. 이렇게 하면 뭐가 되었으니 다음엔 이걸 해 볼까요? 식의 접근법이다. 그러나 뭔가 더 복잡한 상황에 대한 해결책을 찾고자 하면 번지수가 틀렸다.

책 자체는 좋으나, 나의 욕구를 채워주지 못하여 별점은 낮게 주었다. 그러나 아마존 평점에서 볼 수 있듯이, 어떤 이들은 5점을 줄 수 있을 것이다.

tag : 독후감, IT, ORM, java, hibernate, programming ]]> 감상문 독후감 IT ORM java hibernate programming http://kingori.egloos.com/4206701#comments Sat, 08 Aug 2009 05:24:24 GMT 오리대마왕 <![CDATA[ [독후감]무지개를 풀며 ]]> http://kingori.egloos.com/4179463 http://kingori.egloos.com/4179463

무지개를 풀며 -

리처드 도킨스 지음, 최재천.김산하 옮김/바다출판사

"이기적 유전자", "눈먼 시계공"에서 최근에 나온 "만들어진 신" 까지, 리처드 도킨스는 아마 가장 많은 이슈를 몰고다니는 글 쓰는 과학자가 아닐까 생각한다. 아직 도킨스의 책을 한권도 읽어보지 않았기에 언제는 한번 읽어봐야지~ 하고 있다가 친구가 이 책을 빌려줘서 읽었다.

으음, 어렵다 어려워. 저자가 명성이 있는 사람인데 당췌 뭔 소린지 이해가 잘 안가요. 좀 더 끈질기게 붙들고 읽는다면 이해를 할 수도 있겠지만 굳이 그런 식으로 읽을 필요가 있는 책도 아닌터라 그 정도 에너지를 쏟지는 않았다. 어디까지나 과학 교양서인데 뭐 이리 불친절한지 모르겠다. 무지개에 대한 광학적인 이야기에서는 최소한 그림 하나라도 그려줬다면 이해가 훨씬 쉬웠을텐데 말로만 그 많은 내용을 줄줄이 설명하니 이거야 원.

번역자의 번역이 별로인가, 내용이 워낙에 어려운 것인가? 어찌되었건 '어이쿠, 리처드 도킨스는 좀 보류해야 겠어!' 라는 생각만 들었다. 나도 나름 재료공학과를 나온 공대 체질인데도 이리 이해가 안가는데, 이런 저런 서평에서 '참 좋았다' 고 말하는 사람들은 1) 나보다 지적 능력이 뛰어나거나 , 2) 나보다 이 책을 읽는데 에너지를 많이 쏟았던가, 3) 이해 못했으면서 구라치는 것이라 생각했다.

일단 전체를 관통하는 내용은 단순하다. 일반적으로 널리 퍼져 있는, 과학은 매우 고루하고, 온갖 아름다운 상상을 갉아먹는 냉혈한이라는 생각은 엉터리라는 것이다. 오, 이 아름다운 무지개 속의 광학을 보아라! 통계를 통해 입증 된 이 놀라운 결과들을 보아라! 우리 세포 속의 이 놀라운 현상들을 보아라! 과학이 얼마나 멋지고, 또한 우리의 상상력을 키워주는 지를 보아라! 나도 여기엔 동감. 물론 제대로 공부를 하려면 정말 팔다리가 배배 꼬일만큼 어렵지만, 그 와중에 하나하나 알아가는 맛이 또 있지 않은가.

또한 도킨스는 반대 시각에서 사이비 과학들이 과학인양 행세하고, 미신들이 판 치는 세태를 비판한다. 이러한 사이비 과학들 사이에는 지적 설계론과 가이아 같은 널리 알려진 내용들도 포함되어 있다. 다 알만한 사람들이 점집을 다니고, 통계적으로 뻔할 수 밖에 없는 결과에 '오, 놀라워!' 하는 반응을 보이는 것에 대해선 '얘들아, 제발 과학 공부 좀 해라' 라고 충고의 멘트를 날리신다.

근데 저자의 의도에는 참으로 동감을 하지만, 하나하나의 내용이 너무 어렵다. 그림만 좀 넣어줘도 훨씬 이해가 쉬울텐데. 앞단에 나오는 무지개의 산란의 경우도 물리학 박사를 받은 친구 녀석이랑 버스 옆자리에 앉아 가면서 이리저리 설명을 들으니 그제서야 이해가 가더라. 심오한 내부를 파헤치면서 발견하는 놀라움도 있겠지만, 좀 쉽게 풀어서 써 주지. 교과서라도 옆에 펼쳐봐야겠더라고.

별로 추천하고 싶지 않다. 전체적인 맥락에는 고개를 끄덕이게 되지만, 페이지 넘기기가 너무 괴롭더라. 내용을 가볍게 하는 것이 아니라, 조금만 더 친절했더라면 어땠을까. 도킨스의 다른 책은 좀 나으려나?

tag : 도킨스, 과학, 무지개를풀며 ]]> 감상문 도킨스 과학 무지개를풀며 http://kingori.egloos.com/4179463#comments Thu, 02 Jul 2009 12:07:34 GMT 오리대마왕