iBatis에서도 Spring DAO Template 과 유사한 기능을 제공하는 iBatis DAO가 갖춰져 있다는 사실을 OnJava.com의 한 기사를 통해 오늘에서야 알게 되었습니다.

둘 중 어느 프레임워크를 사용할 지는 각자의 고민이겠지만 스프링 특유의 지저분한 getter/setter 들을 보고 싶지 않으신 분들이라면 iBatis 를 적극적으로 검토해 볼만 합니다. 또 이 iBatis DAO 는 XML DAO Template 을 지원하여 RDBMS 가 아닌 XML I/O 도 가능한 것이 특징입니다.

에릭 라슨의 화이트 시티를 구입하면서 영희씨에게 선물했던 프랑수아 끌로르의 꾸뻬 씨의 행복 여행을 여행 중에 읽었다.

얼마 전에 소개한 선물처럼 큼지막한 글씨, 그리고 거기에 곁들여진 베아트리체 리의 그림은 휴양지에 어울렸다. 이 책은 불행한 사람들을 치료하면서도 왠지 불행한 ‘주 마뻴 꾸뻬’ 라는 정신과 의사가 무엇이 사람을 행복하게, 아니면 불행하게 만드는지 알아보고자 떠난 독특한 여행 이야기를 담고 있다. 단순해 보이는 이야기 속에 다양한 재미를 불어 넣고, 주인공이 겪는 다양한 사건들을 행복의 관점에서 바라볼 수 있도록 하여, 마음이 아픈 현대인들에게 잊혀진 행복을 잔잔히 일깨워 주고 있다.

구체적인 해결책을 제시해주는 기술서나 미국인들의 책들을 주로 읽어 온 나에게 이 책은 나에게 조금은 생소하게 다가왔다. 하지만 저자가 독자에게 선물하고자 하는 특유의 배려가 행간에 묻어나와 그렇게 편안하지 않을 수가 없었다. 덕택에 반복하여 읽으며 나 스스로도 행복에 대해 적지 않은 고민을 할 수 있었다.

지금까지 불행하다고 생각해 본 적은 없다. 나는 그저 ‘인생은 그냥 죽음을 향해 끊임없이 살아가는 것이다’ 라고 생각해 왔다. 한 번 사는 인생이라면 더 능률적으로 더 좋은 일을 하면서 살고 싶었고, 그래서 내 나름의 최선을 다했다. 일이 잘 풀리지 않으면 속상하기도 했고, 스트레스를 가능한 한 적게 받기 위해 많은 노력을 기울였다. 그 결과 나는 ‘행복’이라는 단어를 잊고도 그럭 저럭 잘 지내 왔던 것 같다. 적어도 불행하지는 않은 것이다.

요즘은 집에서 사람들과 오픈 소스 소프트웨어를 개발한다. 참 즐거운 일이다. 한때는 단순히 금전을 위해 동시에 두 가지 이상의 일을 해 본 적도 있다. 그저 막연히 어떤 일이든 그리 어렵지 않고 나름대로 즐길 수 있는 일일 것이라고 생각했지만, 생각만큼 그렇게 재미있는 일이 아닌 경우가 많았다. 나는 심한 스트레스의 댓가로 많은 수입을 얻었다. 돌이켜 보면 매사에 남들보다 더 빨리 무언가를 성취하고, 더 높은 단계로 올라가고 싶은 욕구와 궁핍한 상황이 함께 가져온 결과였다.

많은 시행착오 끝에, 끝이 없는 도전 속에서도 행복할 수 있는 방법을 이제는 조금씩 알아가고 있다. 항상 마음속에 담아왔던 생각들을 한 시인은 이렇게 읊었다:

춤추라, 아무도 바라보고 있지 않은 것처럼.
사랑하라, 한번도 상처받지 않은 것처럼.
노래하라, 아무도 듣고 있지 않은 것처럼.
일하라, 돈이 필요하지 않은 것처럼.
살라, 오늘이 마지막 날인 것처럼.

이 글귀가 ‘꾸뻬 씨의 행복 여행’ 에도 엽서로 큼지막히 꼽혀 있다는 사실은 정말 많은 것을 암시하지 않나 싶다.

원문: Meme Agora by Neal Ford

SOA (서비스 기반 변형)

싱가포르의 SOA 컨퍼런스에서 다른 발표자들과 이야기하는 동안, 나는 SOA 에는 기술과는 전혀 상관 없는 부작용이 있다는 사실을 생각해 냈다. SOA 가 실제로 힘을 발휘아기 위해서 기업은 개발자가 그것을 표현하는 서비스를 만들 수 있을 정도까지 그 역할이 엄격하게 정의되어야 한다는 사실이다. 그 사실이 애를 먹인다 — 대부분의 기업들은 그들 자신의 업무를 그정도로 자세하게 이해하고 있지 않다. 시간이 지날수록, 나는 프로젝트를 수행하는 분석가와 개발자들이 실제로 고객의 비즈니스 프로세스를 기억이 지금까지 가졌었던 것보다 훨씬 세밀한 수준까지 정의한다는 것을 계속해서 눈치챘다. 나와 일했던 몇몇 고객들은 개발 프로세스 덕택에 그들의 업무를 더 잘 이해하게 되었다고 언급하기까지 했다.

물론, 정 반대도 사실이다 (아! 그리고, 더 자주) — 엉성하게 정의된 업무 프로세스를 가진 회사들은 SOA 를 도입하려고 시도하고 끔찍하게 실패할 것이다. 그리고 기술이 아무런 관계도 없음에도 불구하고 SOA 실패에 대한 케이스 스터디를 하나 추가하게 된다. 더 나쁜 것은 Enterprise Service Bus 와 같은 고가의 개발 툴 벤더들은 자신들의 툴을 다신들의 업무 프로세스를 “고쳐”주리라고 믿어 의심치 않는 고객들에게 팔아 넘길거라는 점이다. 돼지에게 드레스를 입힌다고 해서 돼지가 예뻐 보이는 것은 아니다. 단지 돼지를 신경쓰이게 할 뿐이다. 다른 많은 기술적 진보 (개체지향, 컴포넌트 기반 프로그래밍을 보라) 와 같이, SOA 는 문제가 있는 업무의 문제를 해결해 주지는 않을 것이다.

오늘의 어휘

• abberration – 변형. 색수차.
• occur to someone – 생각해 내다. 떠올리다.
• business – ‘업무’라는 뜻 외에도 ‘법인, 기업’의 뜻을 가짐
• rub – ‘문지르다’ 외에도 ‘애를 먹이다 속썩이다’의 의미를 가짐 (e.g. That’s the rub. – 그게 바로 애를 먹이는 점이다.)
• alas – (비통해 하며) 아!
• unsuspecting – 믿어 의심치 않는

할일이 많고 욕심도 많아 허둥대고 있는 나를 위해 절친한 친구이자 연세 정보특기자 동기인 재헌이 추천한 스펜서 존슨의 선물 (The Present)을 읽게 되었다. 대학교 학창 시절 리차드 칼튼의 우리는 사소한 것에 목숨을 건다를 읽고 많은 도움을 받았었는데, 한동안 잊고 있었던 미덕들도 되살리고 좀더 간결하면서도 중요한 내용을 잘 전달하고 있어 마음에 들었다.

이미 알고 있었으면서도 지키지 못했던 것들에 대한 부끄러움도 들었다. 그냥 해 버리면 되는데 습관처럼 지나쳐버리는 일들을 이제는 그때 그때 끝마쳐버려야 하는데 내키지는 않는 일들. 계속해서 미루기가 일쑤였다. 내가 원하는 즐거운 일을 찾으려고 하지 않고 당장의 금전적 이득을 위해 관심 분야에서 벗어난 일들에 대한 제안도 쉽사리 거절하지 못하곤 했다. 모두 내 스스로에 대한 큰 계획과 모토가 없어서 생긴 우스운 해프닝이 아닌가 싶다.

좋은 책을 소개해 준 재헌에게 감사하고, 내 주위의 모두들도 스스로의 큰 목표를 갖고 그 목표를 지켜 나아가는 멋진 사람이 된다면 좋겠다. 그리고 그 목표들이 모여 우리 혼자가 이룰 수 없는 이 세상을 바꾸는 힘이 되기를 기원해 본다.

어제 짬을 내 Lorentz 2.0을 릴리즈하고, TheServerSide.com, JavaService.net, OKJSP.pe.kr에 발표했다. 만 하루가 지난 지금 JavaService.net 과 OKJSP.pe.kr 에 달린 답글은 0, TheServerSide.com 에 달린 답글은 내 것을 제외하고는 8개다. 이 작은 숫자의 차이는 한국의 오픈 소스 문화, 나아가 소프트웨어 개발 문화의 현재와 미래를 보여준다.

창조라는 것은 아이디어를 구체화하는 구체적인 프로세스다. 아이디어를 구체화하는 데 필요한 것은 아이디어의 지속적인 검증 (피드백) 과 보완 (피드백의 반영) 이다. 즉, 창조가 이루어지기 위해서는 아이디어를 적극적으로 실현하고자 하는 사람과, 참여하지는 않더라도 그 과정에 영향을 미쳐 실현 과정을 옳은 방향으로 이끌어 가고자 하는 사람이 모두 필요한 셈이다. 전자가 없다면 아이디어는 시작조차 되지 않으며, 후자가 없다면 어떤 좋은 아이디어라도 더 많은 두뇌의 합산을 통한 창발을 겪지 못한 채 도태될 수 밖에 없다.

술자리에서 사람들은 아쉬움 섞인 목소리로 자신이 몇 년 전에 생각했던 아이디어가 이렇게 저렇게 실용화되어 대 성공을 거두었다고 이야기하곤 한다. 아, 그때 그걸로 어떻게 잘 해 보는 거였는데 하는 수 많은 후회들. 그것은 정말 아무 의미도 없이 허공으로 흩어지고 있는 각자의 시간 외에는 아무 것도 의미하지 않는다. 머릿속에 백일몽처럼 스쳐 지나간 수 많은 아이디어들 중 어느 하나라도 누군가와 공유하고, 머릿속에서라도 논리적으로 시험해 본 적이 있는가? 시도해 보지 않았다면 멋져 보이는 아이디어라는 것이 처음에는 얼마나 공허한지를, 그것을 현실 세계까지 데려오는 데 얼마나 많은 노력이 필요한지를 모르는 것은 아닌가? 그렇다면 그 노력을 인정할 준비는 되어 있는가? 아니면 그저 부러워하고 이유 없이 시기할 따름인가?

아이디어는 실행되어야 한다. 그리고 활발한 상호작용을 통해 끊임없이 개선되고 조정되어야 한다. 마지막으로 그 노력이 정당하게 인정받거나 비평받아야 한다. 이 세 단계 없는 백일몽과 술자리의 잡담은 우리 현실을 풍족하게 만들어 줄 리 만무하다.

나는 종종 생각한다. 내가 지금 하고 있는 일들이 어쩌면 정말 수십억 인류의 행복을 앞당기는 데 도움이 되고 있다고. (훌륭한 소프트웨어는 한 나라의 IT 환경을 더 빨리 개선할 수 있도록 돕는다.) 아니면 적어도 지금도 밤샘을 하고 있을 수천 수만의 개발자들의 환경을 한 걸음 한 걸음 개선해 나아가고 있다고.

컴퓨팅 환경을 개선하고자 하는 이런 작은 노력들이 얽히고 섥혀 이론에 불과했던 RDBMS , Garbage Collection, Common Language Runtime 등 수 많은 개념이 구현되었다. 자꾸만 생기는 비슷한 문제를 해결하기 위해 미들웨어도 탄생했다. 디자인 패턴이라는 책이 세상을 뒤흔들었다. 여러분은 언제까지 각개격파만 하고 Boilerplate 에만 의존할 것인가? 지금 우리에게 당면한 공통된 문제는 무엇인가? 내가 무엇을 해결할 수 있는가? 나의 능력을 어떻게 하면 전 인류와 공유할 수 있을까? 그런 고민과 사명감이 우리를 우리의 아이디어에 헌신하게 만들고, 우리 스스로의 힘을 넓히고, 희열 넘치는 성공을 불러온다.