행복상자

미국에 온 첫날을 정말로 힘들었다. 잠은 오지 않고, 시간이 지나고 밤은 깊어 가는데, 눈과 정신은 점점 더 맑아지고...
이런 것이 시차적응이라는 것이라는 생각이 들었다.




밤 10시에 잠을 청했다가, 11시에 한국에서 온 문제 메시지 때문에 잠이 깨었다. 광고 문자 메시지였다. 한글을 영어로 풀어서 보낸건데, 사실 무슨말인지 하나도 알수가 없었다. 아니, 읽어 보려고 해독하는 것이 좋은 생각이 아니라는 것을 알기에 포기했다.

잠이 깨어 잠을 청하려 노력하였으나, 잠이란 애는 결코 다시 돌아오지 안했다. 시차 적응을 빨리하려고 일부러 비행기에서는 거의 잠을 자지 않았는데... 나의 노력을 허사였다.

그런데 이 한밤중에, 너무도 허기가 져서 방안에 가만히 있을 수가 없었기에, 옷을 간단히 챙겨 입고 프론트로 내려가 보았다. 목도 마르고 배도 고프고 해서, 요기할 거리가 찾아 나선 것이다.

피자 냄새가 로비에 있는 바에서 물씬 났다. 많은 사람들이 웃고 떠들며 담소를 나눈고 있었는데, 나는 용기가 없어 방으로 호텔 밖으로 나갔다. 밖에는 간간히 지나가는 차가 보였는데, 간단하게 요기할 수 있는 식당은 눈에 띄지 않았다. 단지 맥도날드 하나가 눈에 들어올 뿐이었다.



나를 부르는 전화 벨 소리에 잠이 깨었다. 으-- 늦잠이다. 나를 Pick-up 하기로 한 현지 연구원과의 약속 시간이 지나버렸다. 미안 하기도 했지만 마음이 급했다. 어제 겨운 잠이 든 시간은 새벽 6시였다.

호텔에서 사무실까지는 약 3.5마일 정도로, 약 10분정도 걸리는 거리이다.
연구실을 주변이 숲으로 둘러싸여 있고, 휴가로 펜션에 온 듯한 느낌을 줄 정도로 한국의 그것과는 많이 달랐다. 사무실에 도착하니 한국사람들과 미국현지에서 채용한 사람들을 소개받고 소개하는 시간을 갖은 후에 조금 늦었지만, 오전 일정을 무난하게 소화할 수 있었다.

점심 시간은 근처에 있는 카페테리아에서 식사를 하였는데, 1인당 10불까지 사용할수 있는 쿠폰이 제공되어, 원하는 만큼 음식을 고르고 나중에 계산하게 되어 있었다. 만약 적게 고르면 돈을 거슬러 주지 않지만, 추가되면 그만큼 더 지불한면 된다.

나는 피자를 하나 고르고, 콜라를 하나 골랐다. 피자는 약 5불이고 코라는 1.33불이다. 약 3불짜리 하나를 고를 수 있는데, 피자만으로도 배가 부를것 같아서 포기했다.
식당은 조용하고 넓었다.

미국은 어디를 가나 넓다는 생각이 들었다. 10불짜리 쿠폰도 마음에 들었다. 왜 미국에서만 이런 혜택을 받아야 하나? 라는 의문도 더불어 들었다.

너무 부러워 하면 그동안의 내가 불쌍할까봐, 그만 두기로 했다.

내가 처음 경험함 미국은 아직까지 내게 좋은 느낌만을 남기고 있다.
점심의 날씨는 정말로 아름다웠다. 풍광과 바람도 내게는 새로움만 줄 뿐이다.
사랑할 만한 것이 너무 많다.

 


 

미국 LAX에 도착해서 처음으로 가본 곳은 Universal Studio였다. 공항에서 가깝기도 하고, 영화를 좋아하는 터라 나를 마중나온 현지인에게 부탁해서 찾아 갔다.

지나가면서, 영화나 영화를 소개할 때 보던 HollyWood라는 커다란 간판이 숲위에 떠 있는 것을 보았다. 정말 여기가 할리우드구나. 아니 미국이라는 생각이 들었다.

스튜디오에 차를 가지고 들어가는데 인당 5불을 지불했다, 처음에는 여기부터 유니버샬 스튜디오라고 생각을 했었는데, 스튜디오로 들어가는 출구는 따로 있고 입장료도 별도로 지불해야 한다.

차를 주차하고, 여러 컨텐츠 샵을 들렀다. T-셔츠, 악세사리, 안경 그리고 슈퍼 영웅들에 대한 만화를 파는 가게가 줄지어 있었는데, 선듯 구매하기는 망설여졌다. 오늘은 이곳에서 미이라 3를 개봉하는 날인가 보다. 영화관 앞으로 Rad카펫이 깔려 있고, 배우들이 지나가는 곳은 사진을 찍을수 있는 위치가 지정되어 있었다.  아마도 저녁때에 진행될거나, 나와는 관계없는 이벤트였다.

유니버셜 스튜디오 앞에 도착하였다
사람들이 줄을 서서 표를 구매하고 있었다. 현지 개발자가 물었다. 나보고 보고 싶냐고, 1인당 70불 가량 되는데 볼거냐구? 현지인의 물음은 이런걸 돈 주고 봐야 하나라는 의미가 가득 담겨 있었다.

그래서 입장하는 것은 포기하고 사진을 찍었다.
갖다 온거처럼 보이기 위해서 입구에서 사진을 찍었다.

그리고는 5시간 넘어서 거의 6시가 될 무렵에, 저녁으로, 나의 경우는 사실 저녁이 아니라 점심이었지만 우리는 타이 음식점으로 같다. 아무래도 미국은 여러나라 사람들로 이루어진 나라서, 음식에 대한 편견이 없이 쉽게 접할수 있는가 보다. 앞으로 미국내의 여러 나라 음식점을 다닐것 같은 생각이 이때 들었다.
이것이 미국적인지 아닌지는 다른 문제이다.

조금 이른 시간에 들어가서인지 사람들이 별로 보이지 않았다. 음식을 먹기 시작하니까 사람들이 채워지기 시작하였다.



타이 고유의 차를 한잔 마셨는데, 한국에서 마시는 차와 달랐다. 단듯하면서도 담백해서 나름 거부감 없이 맛있게 마셨다.

차를 마시고, 바로 돌아가기에는 아쉬워서 잠시 바닷가를 들렀다. 보노비치였던거 같은데, 사실 이름이 정확하게 기억이 나지는 않는다. 내일 꼭 물어봐야지...

이곳을 구경하다 보니까, 한국의 게를 파는 집이 여럿있었다. 처음에는 일본사람들이 해물 레스토랑을 운영한다고 생각했는데, 한국계 식당인거 같았다. 간판이 한글로 된걸 보고 무척 반가왔다.


한글로 되어 있는 간판이 보일거다.

이곳에 오니까, 낮에는 좋았던 날씨가 궂어졌다. 그러나 늘상 있는 일이라고 현지인이 말해주었다. 비오는 일은 만치 않다고, 해안가 기후여서 그렇다구.
낙시를 하는 사람드이 이곳 저곳에서 보였다. 그리고 아이들이 노는 모습도 보이고, 관광객들도 보이고, 작다고 생각했는데 많은 사람들이 오고 가튼 모습이 마치 명동 같았다.


다시 시내쪽으로 차를 몰고 가니, 파란 하늘이 보였다. 등뒤의 구름이 가득한 하늘과는 대조적이있다.
많은 즐거운 일들과 새로운 경험이 나를 기다릴 거라는 생각이 들었다.

미국이라는 나라에 대해서는 내 나이가 되도록 수 없이 많이 들어보았다. (내 나이를 공개 안합니다.  ^^) 하지만, 이 나이가 되도록 아직 한번도 미국 땅에는 와 본적이 없었다. 이 땅에 내려서 처음 느낀것은 정말 누구나 영어하는 나라이고, 아이조차도 영어로 이야기 하는 나라였다. (으흐 정말 영어 잘한다.)

이 번주는 예정되어 있었던 일정임에도, 갑자기라기 보다는 정신없이 준비해서 먼 이국땅으로 출장을 왔야만 했다. 비행기 시간과 예약된 호텔을 확인하고, 렉트카와 로밍폰을 준비하고, 생각보다는 챙려서 와야 할 것이 많았다. 물론 일을 위해 오기때문에 어떤 각오를 하고 와야 했다. 내가 전에도 이야기 했지만, 영어라는 것은 쉬운 말이 아니다. 특히 이국인의 입장에서 영어는 허물이고 피해야 할 장애물과도 같다. 하지만, 나 자신에게는 어떤면에서 즐거움이기도 하다. (아마도 이전에 내가 영어에 대한 두려움을 떨쳐 버렸다는 것이 가장 큰 수확이었다고 짧게 이야기 했었다.)
두려움이 없는 삶을 살수 있다면, 우리의 삶은 좀더 여유있을지도 모른다.

일요일 한국에서 아시아나를 타고 켈리포니아주의 LA공항에 도착한 시간을 일요일 오후 12시였다. 도착해서는 현지의 개발자에게 전화를 했다. 사실 놀러온 것은 아니지만, 그도 이전에 한국에 왔을때 신세를 졌었고, 10월경에 다시 한국에 오면, 신세를 질거다.
통화를 하고 그를 기다리면서, 집에 두고온 우리 예쁜 공주님이 생각이 났다. 내가 미국 간다고 했더니, 눈물을 글성이면서, 자기도 같이 데리고 떼를 쓰던 얼굴이 생각이 났다.
미운 짓한다고 혼내고, 혼내면 투덜데고 삐지기 잘하는 얼굴이 무척 생각이 났다. 아마도 멀리 떨어져 있어서 더 그런것 같다.

그리고 동양인을 보면 모두 한국 사람처럼 보인다. 기다리면서 보니, ELS에서 영어 연수차 대학생들이 왔나보다 그 중 한명이 ELS라고 쓴 피켓을 들고 있었다.. 한 10명 가까이 모이니, 휭하니 가버린다. 아참 그러고 보니 그사람들 모두 영어로 이야기 하고 있던데...

비행기를 타고 10시간 가까이 날아왔는데, 참 지루하기도 하고 나름 여러가지를 생각하는 시간이었다. 그리고 또 누군가를 기다리면서 생각한다.
왜 내가 여기에 있는지를....
가지 말라고 때를 쓰던 우리 공주님을 뒤고 하고 말이다. 나의 동료들은 영어 때문에 스트레스 받지 말라고 한다. 하지만 한편으로 즐길수도 있다. 실전 영어, 서버이벌 잉글리쉬가 빋을 발하는 그런 것 말이다.

앞으로 일주일동안 느낀것을 말하겠지만, 10년 후의 개발자들은 다른 나라 말을 반드시 해야할지도 모른다. 하지만 그래도 가장 중요한 것은 자기가 좋아 하는 것을 하고 있느냐와 좋아하느 것을 즐기면서 해야 한다는 것이다. 그래서 다른 나라에 와 있다는 것 자체를 즐거워 하려고 하는지도 모른다.

다행히도 나는 영어로 인해서 받는 스트레스는 적은 편이다. 하지만 많은 시간을 들여서 한 회의와 협의하면서 서로를 알아 가는 단계가 불필요하게 많지 않았으면 좋겠다. (2시간이면 될 이야기를 하루종일 하지 않았으면...)

아직도 우리 이쁜 공주님의 얼굴이 눈에 선하다. 장난끼 넘치고, 마냥 밝기도 하지만, 마음이 참 여리다.

지난번에는 Quartz를 사용하기 위한 개략적인 설명과 라이브러리 사용을 위한 문서들의 위치에 대해서 이야기 했었다.

오늘은 Quartz사용시 알아야할, 기본적이지만 정말로 중요한 개념인 Trigger와 JobDetail에 대해서 이야기 하려고 한다.

먼저, Quartz에서 Scheduling 할 수 있은 범위 또는 Scope에 대해서 설명하고, 이어서 두가지에 대해서 말하려 한다.

[Job Scheduling]

on certain days of the week (주중의 지정한 날: 특정 요일)

on certain days of the month (달주의 지정한 날: 특정 날짜)

on certain days of the year (연주의 지정한 날: 특정 날짜)

not on certain days listed within a registered Calendar (such as business holidays)

repeated a specific number of times (반복횟수)

repeated until a specific time/date (종료 시점 지정)

repeated indefinitely (무한 반복)

repeated with a delay interval (다음 실행을 위한 타임 인터벌)

위에서와 같이 스케즐러를 실행하기 위한 모든 범주들에 대해서 쿼츠는 커버 가능하다.
여기서 Job(JobDetail)과 Trigger에 대한 개념을 알아야 하는데,

먼저 Job에 대해 설명하면 Job는 실행해야 할 작업으로 이해하면 된다. 예를 들면 메이을 보낸다든지, 필요없는 로그 파일들을 정리하거나, 시스템의 자동화된 작업들을 들수 있다.
여기서는 실행되는 시간에 대한 개념은 없고, 단순히 일의 단위만 생각하면 된다.

Trigger는 Job의 실행을 위한 조건들이라고 생각하면 이해가 쉽다. 실행될 시간, 반복횟수 또는 Interval time등 여러가지 실행 조건들을 생각하면 되는데, Sheduler이니까 시간에 대한 조건들을 포함하고 있다.(시간 기반으로 동작)

Quartz기반으로 실행할 작업을 만들려면, Job과 Trigger를 각각 정의해서 묶어주면 된다.
여기서 Job은 Interface 정의되어 있다. 우리는 이를 상속받아 원하는 작업들을 정의하게 된다. 그리고 Quzrtz의 Sheduler가 실행될때, Job에 대해 이해할 수 있도록 JobDetail를 정의하면 된다.

.Job interface

void execute(JobExecutionContext context)

.JobDetai 클래스의 생성자

JobDetail(String name, String group, Class jobClass) 

  위 코드에서 name과 group는 Job를 위한 Job이름과 JobGroup를 의미한다. 이는 관리를 편하게 하기 위한 것인데, 필요시 이를 이용하여 Job의 검색이 가능하고, 만약 null값을 넣어 준다면, DEFAULT 그룹명이 할당 된다.

Trigger클래스는 JobDetail클래를 이용하여 정해진 시간에 실행이 되도록 스케즐러가 관리하는데, 이는 아래와 같은 코드를 통해서 Job에 대한 정보들을 가져오게 된다. 아래 코드는 Job의 name와 Grouup명만 있을 뿐, 직접적으로 할당하지 않지만, 내부적으로는 위에서 정의한 job의 name과 group name을 참조하여 가져오게 된다.

Trigger(String name, String group, String jobName, String jobGroup)

여기도 name과 group가 있는데, 이는 Trigger의 이름과 group 명이다.

다음에는 코드를 이용하여 실제로 Job과 Trigger을 정의하고 사용하는 방법에 대해서 설명하려 하다.

오늘은 안철수 교수님이 회사에 오셔서, 자신의 길과 안랩이 지나온 여정들을 하나 하나 집어가면서, 지나온 시간을 반추하는 시간을 가졌다.
(사실 이글은 쓰는 시간이 0시를 지나가니, 어제이다.)

이른 시간에, 아침 8시부터 시작하여 9시 30분에 마치는 세미나 인지라 사람이 없을 것만 같았다. 그러나 나의 예상과는 다른게, 아니 다들 나와 같이 생각했던것 같다. 정말 많은 사람들이 홀을 가득 매웠다. 그리고 자리가 모자라서 서서 지켜보는 사람들도 꽤 됐던것 같다.

중학교때 진공관 라디오로 시작해서, 컴퓨터를 공부하고 컴퓨터 바이러스를 치료하는 프로그램을 만들기 시작했던 이야기와 벤처를 거쳐서 또 유학을 가서 공부를 하고 다시 KIAST의 석좌 교수로서 강의장을 찾아 오기까지의 이야기들을 과장없이 해 주었다.

개발자 안철수
벤쳐 기업가 안철수
석좌교수 안철수

내가 느끼기에는 석좌 교수 안철수가 가장 잘 어울린다고 생각한다. 호칭이 괜히 안정감 있어 보이지 않는가?

처음 강단에 서서 사람들레에 인사할때는, 속으로 신문이나 방송으로 봤던 얼굴과 너무나 똑 같다고 생각했다. 카메라발 사진발 이런거와는 관계없는 사람이었다. 삶을 그렇게 살고 있어서 그런가? 가감없이 꾸미지 않고 진솔하게 살려고하는 태도 때문일까?

누군가가 그랬던거 같다. 남자 나의 40이면 얼굴에 책임질 수 있어야 한다고...

강단에 서서 사람들에게 인사하던 목소리는 너무나 작고 힘이 없어 보였지만, 1시간 30분을 책임지고 있는 사람으로서는 너무나 많은 것들을 주었다고 생각한다.
중요한 순간마다 최선의 결정을 내리고, 변화할 수 있었던 경험은 나누어 주는 소중한 시간이었다. 가치있는 삶이 무엇일까? 라는 종교적인 찰라적 각성을 주었던 시간이기도 했다.

나는 결정하고 후회하지 않으려고 한다. 아마도 내면에서는 잘못도 결정에 대한 보상 심리도 있을지도 모른다. 하지만 최선의 결정을 내리려고하지만, 그 분처럼 현대의 , IT업계의 성자와 같은 삶을 살지는 못할 거다. 내가 지독히도 이기적이기 때문에...

하지만, 지금도 나와 나와 비슷한 생각을 하는 사람들에게 길을 있다. 살아있다는 것 자체만으로도 많은 기회를 가지고 있는 것이니까...

마치 고등학교 시절처럼, 나의 한편을 생각하게 만든다.

오늘 책에 싸인을 받았다고 즐거워하는 어떤이가 갑자기 떠오른다.
 

정말 이번 주는 바쁘기도 무척 바빴지만, 더위와 높은 습도로 인하여 지치는 한주간이었다.

일반적으로 자바에서, 사용 가능한 Scheduler는 Java에서 기본적으로 제공하는 Timer(J2SE 1.3이후 제공)와 Quartz 라이브러리를 많이 사용한다.
만약, 우리가 어떤 작업들에 대해서 반복적인 처리를 하고 싶다면, 두 라이브러리의 API와 상속받은 Class를 통해서 호출이 될수 있도록 코드를 추가하기만 하면 된다.

J2SE에서 제공하는 java.utilTime와 Quartz는 기능적으로 차이가 있는데, Timer는 일정한 주기를 반복하는 기능만을 제공하므로 정해진 시간에 실행되는 기능은 제공하지 않는다.
반면에, Quartz는 두 가지 모두를 제공한다.(주기적인 실행, 지정한 시간에 실행)
물론, Quartz의 경우는 더 많은 기능들을 제공한다. Unix와 리눅스의 Cron 텝의 사용법과 유사하게 설정하여, Task또는 Job을 실행 시킬수 있다.
 
필요에 따라 둘 중에 하나를 사용하면 된다. J2SE의 Timer는 사용법이 쉽다. Quartz는 여러가지 기능을 제공하기 때문에 약간의 노력이 더 필요하다.

[Quartz 시작하기]
1. Quartz 시작 하기: http://www.opensymphony.com/quartz/
   - 위 사이트에 가면 간단하게 Quartz가 무었인가에 대해 설명해 주고 있다. Quartz는 오픈소스로 Apache 2.0의 라이센스를 사용하므로, 소스를 고치거나 사용함에 큰 무리는 없다.
   - 현재 사용할 수 있는 최신 버전은 1.6 버전이다.

2. Quartz 다운로드 하기: http://www.opensymphony.com/quartz/download.action
   - 1.6버전을 다운로드해서 사용하면 된다.

3. Quartz 관련 문서들: http://wiki.opensymphony.com/display/QRTZ1/Documentation  
   - 보아야 할 문서들이 많다. 하지만 시간이 없거나 간단하게 개념을 이해하고 싶은 사람은
     "3. Learn Quartz의 Tutorials"를 보면 된다. 기본적인 개념과 API사용법을 익히는데
     부족함이 없을 거다.

4. Quzrtz 간단 예제들: http://wiki.opensymphony.com/display/QRTZ1/Tutorial
   - 12개의 간략한 예제들이 있다. 반드시 읽어봐야 할 예제들로 구성되어 있다.
      Quartz를 사용하고 싶은 사람은 꼭 여기를 보라.

5. Quartz의 API: http://www.opensymphony.com/quartz/api/
   - Quartz 사용을 위한 API 문서로서, 기본적으로 봐야 할 클래스와 인터페이스는
      1) Scheduler
      2) Trigger
      3) JobDetail
      4) Job (가장 기본적인 Interface이다.)
      5) 기타등등( 나머지는 필요에 따라서 보면된다.)


조금 복잡할 수동 있지만 Trigger와 JobDetail 클래스(or Interface)의 사용 및 설계 의도를 이해하면 별로 어렵지 않게 Quartz를 접할 수 있을 거다.

Trigger와 JobDaeail과 Job은 다음 기회에 설명하려고 한다.

제목을 써 놓고 보니 참 거창하게 보이는데, 사실은 별로 거창할 것은 없고, Quartz와 Spring Framework를 만드시고, 지속적으로 update하고 있는 개발자들에게 무한한 감사를 올릴 뿐이다. 일반적으로 Scheduler 또는 Task Manager는 어떤 행위에 대하여 주기적으로 실행시키고, 되풀이 하도록 만들어진 Application 또는 Process의 일종이다.
하지만, 실행에 대해서는 책임을 질뿐, 실행 결과에 대해서는 책임을 지지 않는다. 실행의 결과는 어떤 행동 또는 어떠한 목적성을 가지고 있는 모듈에서 우선적인 책임을 지게 된다. 
 
이러한 아키텍처의 장점은 모듈 상화간에, 오브젝트간의 의존성을 줄여줄수 있어, 수정하기 쉽고, 개념적으로도 이해하기 쉽다는 장점이 있다.
지난주는 Quartz의 API와 Spring의 소스를 분석하면서 내가 생각하고 상상했던 것보다 더 잘 만들어진 프로그램들이라는 생각이 머리에서 떠나지 않았다.

처음에는 Spring을 이용해서 간단한 예제를 통해서, 내가 행하고자 하는 작업들을 예약하고 실행하는 것은 그렇게 어렵지 않았다. 하지만, 실제 실행되고 있는 Job정보와 Trigger에 대한 정보를 알아오기 위해서는 직접 Quartz에서 제공하는 Scheduler의 Instance를 통해서 작업을 할 수 밖에 없기에, 결국 Quartz의 API와 Ducuments들을 찾아 봐야 했다.
물론, Quartz에서 알아햐 하는 기본적인 클래스는 JobDetail와 Trigger와 Schedule이다.

이들을 통해서 내가 직접 Task Manager를 구현하다가, 갑자기 두가지가 생각이 났다.

첫째로, 왜 내가 Spring Framework를 사용하지?
둘째로, Quartz와 Transacting 그리고, Data Source의 연동에 대해서는 얼마나 많은
           작업들을 추가로 더 해주어야 할까?

사실 내가 Task Manager를 새로짜기 시작한 것은, Spring Framework의 ApplicationContext에서 xml파일로 정의된 JabDetailBean와 TriggerBean에 대해 최초 1회만 읽어서 스프링이 관하는 Map에 읽어올뿐, 만약 내가 새로운 작업 또는 Trigger를 추가하려면, 직접 Quartz의 Scheduler intergace를 얻어와서 코딩을 해주어야만 했기 때문이었다. 직접 코딩을 하려면,차라리 전체를 짜는 것이 나을 것 같았었다.

하지만, 두가지 생각이 떠오른 후에, 다시 한번 생각해 보았다.
분명의 Spring Framework을 만든 사람들은 나보다 나은 사람들일 것이다. 나는 지극히 평범한 개발자중의 한명인데, 그 들은 내가 알지 못하는 것까지 생각해서 만들었을 것이니까, 나는 단지 그 것을 빨리 찾으면 될건데 아직 모르고 있을 뿐인걸..

그래서 나는 다시 Spring의 소스를 분석해 보았다.
역시 내가 예상했던대로, JobDetail과 Trigger를 새로 추가하는 방법이 숨겨져 있었다.
SchedulerFactoryBean 클래스는 어떤 값을 설정할때 setter를 통해서 설정하게 되어 있다.
(그럴만도 한게, DI를 이용하기 위해서라고 생각된다.)

그러나 별로로 Add나 Remove를 위한 method는 제공하지 않는다. (그래서 처음에 Spring의 Scheduler 사용을 포기 했었다, 하지만 새로운 Job와 Trigger를 추가하는 것은 가능하다.)

이야기가 길이에 대한 자세한 내용은 추후에 정리해서 공유할 예정이다.
먼저,
      - Quertz에 대한 설명
      - Quertz의 Trigger와 JobDetail
      - Job와 Trigger의 Add, Delete
      - Spring에서의 Quartz 사용
      - Spring을 이용한 Task Manager작성

이런식으로 정리할 될것같다. (내 기억력은 항상 한계치라, 잊기 전에 작성을 해야 하는데...)

스프링 코드를 보는 것은 결코 나쁘지 않다. 좋은 코드는 좋은 코드를 만들도록 도와준다.
이를 통해서 더 나은 것을 만들기를 바라는 것이 현재를 살고 있는 오픈소스를 통해서 기여하고 있는 훌륭한 개발자들의 바람일 것이다. 그리고 나의 바람인데, 나는 그들중에 들기에는 부끄럽다. 단시 좋아할 뿐이다.

내가  개발자로서 좋아 하는 책이 여러권있다.
굳이 내가 개발자임을 강조하는 것은, 현재 까지는 나의 생업이고(앞으로도 그렇겠지만) 아직까자 내가 가장 좋아하는 일이다.

새로운 것을 알아가고, 나의 손으로 창조하는 것이 비단 Programer 뿐이겠는가?
사람들의 눈으로 보이는 잣대로의 창조적인 작업이 아니라, 내손을 통해서 뿜어져 나오는 Code로 인해서 무언가가 만들어진다는 작가적 또는 예술가적인 희열을 비슷하게 경험할 수 있다는 것이 항상 새롭다.

내가 좋아하는 책 중에는 kant Beck이 저술했고, 국내에서는 김창준씨아 강규영씨가 옮겨서 소개진 테스트 주도 개발 이라는 책이있다. 처음 이책은 접하게 된것은 2005년 초이다.
TDD(Test Driven Development)라는 것은 나와 같이 일했던 연승훈이라는 분을 통해서 처음 알게되었다. 그래서 관심을 두기는 했지만 프로젝트에 적용하기에는 참 쉬지 않았다. Junit와 xUnit에 대해서 한국에서도 많은 사람들에게 소개되었지만, 정말 제대로 사용하는 사람들은 찾아보기 어려웠으며(이는 지금도 마찮가지이다.), 이를 적용한다고 해도 버그는 사라지지 않았다. 그리고 xUnint과 같은 Unit 테스트 툴들을 사용할 때, 정말 좋은지에 대해서 긍정하는 사람들도 그래 많지 않았다. (아마도 테스트 코드를 작성하는데, 추가적인 공수가 들었기 때문이라고 생각된다.)

지금도 많은 기업(어느 정도가 규모가 되는 회사)들은 jUnit를 도입하고, 이를 범용적으로 이용할 수 있도록 개발 프로세스와 개발시에 중요한 업무(?)로 정의해서 이를 지키도록 강요아닌 강요를 하고 있다.
개발자가 필요하다고 생각되면, 이를 사용하지 말라고 해도 몰래 사용할 것이다. 필요성과 함께 정확한 사용에 대한 교육이 당연히 뒤 따라 다녀야 한다. 이는 전적으로 나의 개인적인 생각이다. 아직도 책 하나 던져주고 담 주까지 익히라고 하는 과거의 관행은 없어졌지만 , 프로그램의 코드를 생산하는 일이 창조적이라고 생각한다면 반드시 피해야 한다. 하지만 좋은 스승은 그때 당시에 찾기 무척 어려웠다. 잡지(마이크로 소프트웨어)에서 간간히 소개가 되고는 있었지만, TDD도 xUnit은 이거라고 정의내려주는 사람은 좀처럼 찾아보기 힘들었다.

개발자에 의한,개발자를 위한 여러가지 것들에 관심이 많았던 나는 2005년 우연히 서점에서 김창준씨와 강규영씨가 번영한 켄트 백의 TDD책을 발견하고 바로 구매해서 보게되었다.
내가 좋안 하는 책들은 당연하게도, 여러번 반복해서 읽게 되는 책들인데, 이는 나의 필요에 의해서이다. 아니 내가 그들 만큼 똑똑하지 못하기 때문이다. 나는 지극히 평범하기 때문에, 나보다 앞선 선배들과 똑똑한 그들의 조언이 항상 필요하기 때문이다.

                                                    (바로 이책이다.)

내가 정확하게 2005년 3월에 그 책을 구입한 이후로 1년에 거의 2~3차례 이책을 탐독을 한다.  올해도 벌써 2번째 이책을 들여다 보고 있다. 아마 올해까지 거의 9~10회 정도를 본것 같다. 하지만 정확하게 그분(캔트 백)의 의도를 모르기 때문에 매년 이책을 반복해서 보는 것이다. 역시 나는 덜 똑똑한 사람이다. 남들은 쉽게 잘하는데...(백형 부러워요.)

하지만, 내가 이해하는 것은 TDD는 개발자 자신을 위한 것이기도 하지만, 프로젝트에 참여하는 모든 개발자와 테스트를 담담한 사람들과 결과물을 받을 사람들에게 반드시 필요하다.
이의 결과로 산출된 코드는 내가 담당한 코드의 결과를 예측케 하는데, 이는 코드의 명세서와 같은 역할을 한다. 일반적으로 잘 설계된 시스템과 Architect는 계약 관계를 어떤계 표시하는 가에 달려있다. 이는 설계자와 코드를 작성하는 개발자와 그리고 이를 테스트할 테스터와 최종 산출물을 사용할 이름 모를 사용자와의 약속이기 때문이다.

내가 작성할 코드의 결과를 바라보는 것은, 농부가 씨를 뿌릴때 가을에 거두어야 하는 작물이 무었인지 정확하기 아는 것과 같다. 이에 맞추어서 작물에 필요한 양분과 환경을 만들어주고 추수하는 것처럼 결과에 대해 명확히 알고 씨를 뿌리는 것은 정말 중요하다. (코드 명세서는 이래서 중요하다.) TDD를 통해 작성된 코드는 정확이 이래야 한다. 무엇을 정의하고 결과로 나오야 하는 것이 무엇이지 아는 것과 모르는 것의 차이는 분명하다.
따라서 똑같은 클래스에 대해서 테스트 할때 어떤 사람은 20개를 작성하는데 어떤 사람은 200개 가까운 테스트 코드를 작성하기도 하다. (아마도 한국에는 없을 것이다.)

이렇게 작성된 TDD의 테스트 코드는 리펙토링에도 유용하다. 리펙토링은 코드의 외적인 모습을 유지하면서 내부 구조를 변경하는 것이다. 이는 리펙토링은 결코 Architecture를 흔들어서는 안된고, 현재의 상태를 가장 최적의 상태를 만드는데 초점을 두어야 한다는 의미이다.

내가 켄트 백의 책을 프로젝트의 시작 초기에 항상 읽는 이유중에 하나는 내가 부족한 면이 가장 크지만, 그의 의도와 경험을 내것으로 만들고 싶은 이유 또한 크다.  테스트 코드를 작성하지 않고는 결코 불안해서 일이 안된다는 그의 말처럼, 중요한 것을 중요하게 여기면서 프로젝트에 임하고 싶기 때문이다.
사실 켄트백과 나는 다른 점이 나는 먼저 파란 불이 들어오면, 여기서 코딩을 시작한다. 그는 붉은 불에서 시작하지만, 나는 정말 붉은 불이 두럽다.

자신에게 맞는 코딩 스타일과 방법이 있다. 이를 무시하면 안된다. 나에게는 TDD와 Unit Test는 분명이 많는 방법이지만 아직 나만의 스타일은 없다. 매년 내가 그의 책은 읽는 것은 결국은 나의 스타일이 아직 없기 때문이기도 하다. (글을 쓰다가 느낀점이다. 글은 나를 바라보네 만드는 군.)
아마도, 내가 나만의 스타일을 통해서 이전보다 많은 부분이 채워지고 다듬어 진다면, 그의 책을 좀도 쉽게 볼수도 있을 것이다. (매년 볼때마다 꼭 이렇게 해야하는가에 대해 그에게 의문을 갖지만, 결국은 그도 매번 최선을 찾아서 일할거라 생각이 든다.)

드디어 Spring Dynamic Module 1.1이 발표되었다. 공식적으로는 미국 시간으로 7월 4일 어제였다. 그런데 바로 하루전인 7월 3일 Spring Dynamic Modules 1.0.3 정식 버전의 정상적으로 Release 되었는데 말이다.

Spring Dynamic Module의 정식이름은Spring Dynamic Modules for OSGi이다. 하지만 작년까지만 해도 우리들에게는 Spring OSGi라는 이름으로 더 잘 알려져 있었다. 그러나 OSGi Appliance의 공식적인 허가 없이는 OSGi라는 명칭을 사용할 수 없기에, 지금은 Sprig Dynamic Module로 사람들에게 소개된 것이다.

다운로드 가능한 위치는 아래와 같다.
    - spring-osgi-1.1.0-with-dependencies.zip
    - spring-osgi-1.1.0.zip

위 링크와 같이 두개의 버전으로 제공이 되는데, dependencies 라고 되어 있는 모듈은 참조를 하고 있는 관련 라이브러리(.jar)파일과 소스를 포함하고 있어서 개발 환경을 구축할 때, 손쉽고 시간을 절약하도록 되와준다. (개인적으로 추천)

Spring-DM 1.1버전과 1.0.3 버전이 하루 차이를 두고 동시에 발표되었는데, 이른 두 버전의 Feature가 다르기 때문이다. 쉽게 이야기 하면 1.1과 1.0의 Feature가 다른데, 1.0버전의 새로운 Feature는 다음과 같다.

The new 1.1.x series introduces several new features over the 1.0.x branch, such as:

* web support (Servlet, JSP, Taglibs) for OSGi applications
* Spring-MVC integration
* classpath scanning
* customization hooks for Spring-DM extender and web extender
* event notifications for OSGi service importers and application contexts
* refined OSGi proxy infrastructure
* 'greedy-proxy' functionality for OSGi collections
* integration with SpringSource Bundle Repository
* support for custom locations for Spring powered bundles
* pluggable mechanism for determining service dependencies
* access to native OSGi ServiceReference for OSGi importers
* new web sample
그리고 몇가지 버그 수정들이 수정됨.

위의 내용은 별도로 번역을 하지 않아도 이해가 가능할것이다. 기능에 대한 새로운 Feature들에 대한 설명인데, 이는 Spring Dynamic Module의 Reference Documentation 참고 하면 된다. (Chapter 3 What is new?)

그래도 간락하게 설명을 하면.
* OSGi상에서 Web Application 지원(Web Serport)
    - Appach Tomcat and Jetty와 같은 Container 지원
    - Spring-DM은 Servlet을 사용하는 WAR 파일을 지원하고,
    - JSP와 Taglib를 위해 거의 변경없이 바로 사용할 수 있게 해준다.
         ==> 참조 : Chapter 8, Web Support
    - Spring-MVC를 OSGi 환경하에서 지원함
        ==> 참조 :  Section 8.7, “Spring-MVC Integration”
    - Classpath Resource 탐색지원 :  classpath: and classpath*: 
       ==> 참조:  component scanning
   - 다양한 extender를 위해 default configurantin 을 쉽게 변경할 수 있음
   - Spring Application의 Lift cycle의 인지 아래 발생하는 Event를 받을 수 있음
   - Proxy Creation(생성)의 성능향상으로 번들의 Package wiring이 좋아짐.

일부에서, 스프링 DM을 이용한 프로젝트에 대해 우려를 많이 한다.
몇가지 알려진 문제들이 있는데, 이들은 이번에 발표된 1.1버전에서 많이 해결되었다.
가장 큰 문제는 Thread 지원과 Class Loder에 관한 부분들이었는데, 1.1의 지원으로 해결됨이 기쁜 일중에 하나이다.

역시 공부할 것은 자꾸 늘어간다. 스스로 실력없음을 항상 느낀다. 스프링의 방대한 소스를 보면서 더 많이 느낀게 되지만, 그래도 즐겁다.

요즘 Spring Framework의 소스 코드를 보는 시간이 많아져서  즐겁기도 하고, 배움의 깊이가 깊어지는 것 같아, 행복하기도 하다.(자아 도취 ?, 만족? )

내가 개발자의 길을 고집하는 것은 좋아하는 일을 업으로 살아갈수 있다는 것이다. 좋아하는 것을 한다는 것은 배움에 있어 거부감없이 이해하는 만큼 흡입할 수 있다.
잘 된 코드를 보고 배울 수 있다는 것은 기능에 대한 이해와 더불어 더 많은 것을 보도록 해준다. 예전에 일민이(Toby)가 소스를 보고 공부하라고 했을때는 별로 필요가 없기도 하고, 기능만 알면 개발할 수 있는데라는 얇팍한 마음에 무시했었다. 그러나 지금 보니 참 많은 것을 얻을 수 있었는데, 좀더 빨리 시도할 걸이라는 마음이 든다.

어제는 Spring Framework에서 Singleton 또는 Prototype으로 Bean을 등록하고 사용하기 위해서 getBean() 메소드를 이용하는 것에 대해서 공부했다.
Bean은 기본적으로 ApplicationContext에 HashMap에 담겨져 있고, 필요시 불리우게 되는데, 이는 ApplicationContext를 통해서 Singleton처러 한개의 인스턴트로 동작하기 때문이다.

이에대해서는 일민이가 스프링 포럼을 통해서 질문에 답한 글을 올렸는데, 쉽게 잘 정리 되어 있다.(필독이다.)


web.xml을 통해서 Root ApplicationContext 로 여러 파일들을 읽어 오려면,

 <context-param>
     <param-name>contextConfigLocation</param-name>
     <param-value>
          /WEB-INF/applicationContext.xml  /WEB-INF/schedulingContext-quartz.xml
     </param-value>
 </context-param>

와 같이 추가해 주면, 클래스 패스 아래 정의된 두개의 설정 파일을 읽어 오게 된다.

아니면, 빈 설정 파일에서 다른 설정 파일들을 import해서 읽어 올수 있다.

<beans>
    <import resource="services.xml"/>
    <import resource="resources/messageSource.xml"/>
    <import resource="/resources/themeSource.xml"/>

    <bean id="bean1" class="..."/>
    <bean id="bean2" class="..."/>
</beans>

xml 파일이 커지거나 작업별로 분리할 필요가 있을때 유용하다.

그리고, 다음과 같이 ApplicationContext Interface를 통해서 여러 설정 파일들을 읽어 올수 있다. 이는 테스트할 때 편리하다.

ApplicationContext context = new ClassPathXmlApplicationContext(
        new String[] {"services.xml", "daos.xml"});
BeanFactory factory = context;

Spring MVC를 이용하여 Web Application을 개발할 경우에는
<servlet>
      <servlet-name>image</servlet-name>
      <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
      <load-on-startup>2</load-on-startup>
</servlet>

와 같이 설정파일에 정의하게 되는데, Spring의 DispatcherServlet에서 서블릿을 정의하고, 이를 위한 Config 파일을 읽을 때는 기본적인 Naming rule을 따르는데, {servlet-name}-servlet.xml 같은 형식의 파일을 생성하고 정의하면 된다.
위의 경우라면 image-servlet.xml과 같이 사용하면 된다.

오늘도 두서 없이 적었다.