|
Space Map
|
Last changed: 9월 28, 2007 12:32 by 박재성 Labels: myspace
구글 Analytics를 통하여 확인할 수 있는 유용한 기능 중의 하나는 내 사이트를 방문하는 사용자들이 어떤 경로를 통하여 접근하는지를 파악할 수 있는 것이다. 예상은 하고 있었지만 가장 많은 유입 경로는 역시 구글이였다. 검색을 통하여 유입이 상당한 비중을 차지하고 있었으며, 직접 사이트를 방문하는 사용자는 예상보다 많지 않았다. 또한 Referer를 통하여 유입 되는 사용자도 상당히 많다는 것을 확인할 수 있었다.
Google Adsense를 통한 수익이 지속적으로 발생하고 있어 그 이유가 궁금했는데 검색 엔진을 통하여 새롭게 유입되는 사용자들 때문인 것으로 추정된다. 앞으로 위키의 컨텐츠를 더욱 강화하여 검색을 통한 사용자들의 유입이 더 많도록 유도할 필요가 있을 것으로 생각합니다.
검색 엔진을 이용할 때 주로 검색하는 키워드를 살펴보면 다음과 같다.
Maven이 다른 수치에 비하여 높은데 이는 자바지기 위키가 maven을 심도 있게 다루고 있는 것이 아니라 국내에 Maven 관련한 문서가 너무 없다라는 생각이 든다. Maven에 대한 개발자들의 관심사는 점점 더 높아지고 있는데 국내에 참고할만한 문서가 없기 때문에 자바지기에 있는 일부 자료를 참고하기 위하여 방문하는 것으로 생각한다. 그 외에 설치 관련된 자료를 찾기 위하여 방문하는 개발자들이 많다는 것을 알 수 있다. 최근 ORM에 대한 관심도도 높아지면서 ORM, Hibernate, IBatis와 관련한 키워드도 높은 비중을 차지하고 있다. 오히려 Spring과 Struts에 대한 키워드는 많지 않다는 것을 알 수 있다. 이는 국내의 많은 사이트, 블로그들이 Spring과 Struts에 대하여 이미 다루고 있기 때문일 것이라 생각한다.
아직 구글 Analytics를 이용한지 그리 많은 시간이 지나지 않아 신뢰할만한 데이터는 아닐지라도 향후 커뮤니티를 운영하는데 많은 참고자료가 될 것으로 생각한다. 또한 개발자들이 원하는 내용이 무엇인지를 파악해볼 수 있는 유용한 정보가 되리라 생각한다.
최근 자바지기 커뮤니티의 통계 정보를 좀 더 자세하게 알고 싶어 통계툴을 찾던 중 Google Analytics를 알게 되었다. 대부분의 통계 기능이 내가 원하는 정보를 제대로 알려주지 못하는 관계로 그리 큰 기대를 하지 않고 사용하게 되었다. 그러나 예상했던 것보다는 훨씬 더 많은 정보가 나에게 필요한 정보들을 제공해주고 있어 이 곳에 간단하게 소개하고자 한다.(아래 통계 정보들은 자바지기 위키의 통계 정보이다.)
통계 페이지의 첫 화면은 통계 기능의 Overview를 볼 수 있는 Dashboard 페이지이다. Dashboard 페이지에서는 총 방문자에 대한 요약 정보를 볼 수 있다. 일별 방문자, 방문자의 접속 시간, 방문자 당 본 페이지 뷰등 다양한 정보들을 제공하고 있다. 그외 각 지역별 접속자 정보, 페이지별 방문횟수, Referer 정보등 관심을 가질 만한 모든 정보들을 한눈에 볼 수 있도록 제공해주고 있다.
Visitors Overview 기능은 각 방문자들에 대한 브라우저, Connection Speed와 접속하는 사용자들의 사용 패턴을 보여주고 있다. 그 외에도 총 방문자 수, Unique 방문자 수, Page View, 평균 페이지 뷰 등 다양한 정보를 볼 수 있다.
나에게 흥미로웠던 한가지는 Map Overlay 정보였다. 자바지기 위키에 접속하는 사람들이 어느 지역에서 접근하는지를 알 수 있어 좋았다. 처음에는 큰 기대하지 않고 봤는데 국내만이 아닌 상당히 다양한 국가에서 접속하고 있다는 것을 알 수 있었다. 개인적으로 상당히 기분이 좋았다.
5일 동안 자바지기 위키를 방문한 사람들은 총 37개 국가에서 방문하고 있었다. 우리나라가 가장 많은 방문자를 기록한 것은 당연한 결과였으며, 두번째로 많은 국가는 일본이였다. 최근에 일본에 진출한 개발자들이 많다고 하는데 위 결과를 보아도 알 수 있을 것 같다. 그 다음으로 중국, 미국, 인도 순이였다. 많은 수는 아니였지만 소수의 개발자들까지 방문하고 있는 사이트라는 것에 은근히 기분이 좋았다.
JCO 주최로 오픈 소스 컨퍼런스를 진행한단다. 내가 몸담고 있는 NHN이 골드 스폰서로 참여한다고 한다. 각 스폰서에 대한 스폰서 섹션이 있는데 해당 스폰서 섹션의 강의를 내가 담당했으면 좋겠다는 제의를 받고 흔쾌히 수락했다. 그런데 막상 수락하고 보니 무슨 이야기를 해야할지 이 막막하다. 아무래도 이번 추석 연휴를 너무 쉬지 말고 고민 좀 하라는 계시인가보다.
무슨 이야기를 하면 재미있어 할까? 내 자신에게는 또 다른 기회가 되지 않을까 생각한다. 아마도 내가 지금까지 강의한 세션 중에서 가장 많은 사람들 앞에 서게 될 거 같은데 벌써부터 긴장과 흥분이 밀려오는거 같다.
Last changed: 9월 03, 2007 19:29 by 박재성 Labels: myspace
사회 생활을 하면서 일한 결과물에 대하여 평가를 받지 않는 경우는 없다. 사소한 작업일지라도 평가와 결부되는 경우가 많다. 사실 평가라는 것이 잘하면 그만이고, 잘못할 경우에는 상당히 큰 파급효과를 가져온다. 많은 팀원들이 떠나는 경우까지 발생할 수 있다. 평가에 따라 성과 Incentive가 달라지고 연봉이 결정된다면 모든 일은 평가와 결부되는 경우가 많다.
지금까지 직장 생활을 하면서 제대로 된 평가를 받아본 경우가 없으며, 그로 인해 Incentive까지 받아본 경험은 없다. 현재 직장에서 처음 해보는 경험이었다. 현재 직장에서 총 3번의 평가를 받았다. 평가를 처음 받을 때는 은근히 신경이 쓰이고 기대치는 높아만 갔다. 그러나 모든 직장인들이 그렇듯이 자신이 기대한 만큼의 평가를 받는 일은 쉬운 일이 아니다. 모든 직장인들이 자신이 하고 있는 가장 힘든 일이며, 가치 있는 일이라고 판단하고 있기 때문에 모든 이들이 만족할만한 평가를 하기는 더더욱 힘든 일이다. 또한 하는 일의 성격은 비슷하지만 개인별로 맡고 있는 서비스에 따라 평가 결과가 달라진다는 인식이 확산되면 평가를 잘 받지 못한다고 생각되는 서비스를 맡기 꺼려하는 현상이 발생한다.
현재 직장의 평가는 1월, 7월 두번에 걸쳐 진행된다. 이렇게 두번에 걸쳐 진행되는 평가로 인해 많은 서비스들이 이 때를 오픈 목표일로 잡고 애플리케이션을 개발하는 경향이 상당히 강하다. 애플리케이션의 성격에 따라 더 많은 시간과 품질을 요구함에도 불구하고 평가라는 틀 속에도 더 빠른 오픈을 강요받고 있다. 이 얼마나 가슴 아픈 현실인가? 고객들의 만족을 최우선시 해야하는 서비스에서 고객의 만족보다 자신들의 평가를 더 중요시하고 있는 모습을 보면서 가슴이 저려오는 것을 느낀다. 비지니스적인 가치를 앞세우면서 오픈한 서비스는 당연히 많은 문제점을 가질 수 밖에 없으며, 이에 대한 많은 책임은 유지보수를 담당하고 있는 개발자들에게 전가되는 형국이다. 신규 서비스를 오픈하는 개발자들은 좋은 평가를 받을 수 밖에 없으며, 뒷치닥거리하는 유지보수 개발자들은 밀려드는 고객 문의에 허덕이면서 자신의 가치를 발휘하지 못하고 있다.
나 또한 "평가에 대하여 전혀 신경쓰지 않는다."라고 확신할 수는 없다. 하지만 단편적인 평가 결과에 연연하는 행태는 보이고 싶지 않다. 장기적인 관점에서 서비스를 바라보며, 고객들의 요구사항을 받아들이는 모습이 서비스 기획, 개발자의 자세가 아닐까 생각한다. 이 같은 행동이 단기적으로 나쁜 평가를 받을 수 밖에 없겠지만 장기적인 관점에서는 지속적으로 좋은 평가를 받을 수 있는 지름길이지 않을까? 그리고 평가에 연연해 자신의 목소리를 낼 수 없는 것보다는 자신이 하고 싶은 일을 추진하는 것이 개인적으로는 더 좋은 결과를 가져온다고 확신한다. 개인에 따라 평가가 자신이 하고 싶은 일보다 더 우선시 될 수 있겠지만 이 같은 결과는 결국에 자신만 지치지 않을까 생각한다. 자신이 기대한 결과 만큼의 평가 결과가 나오지 않는다면 그 때의 좌절감이 얼마나 클까?
개발자로서의 길도 똑같지 않을까? 단기적으로는 자신에게 큰 소득이 없는 일이지만, 자신이 좋아하는 일이며 장기적으로 비전이 있는 일이라면 한번 도전해 볼만한 일이지 않을까? 많은 이들이 너무 단편적이고 단기적인 부분만 고민하고 있는 듯하다. 좀 더 멀리볼 때 자신이 진정 원하는 일을 할 수 있지 않을까?
기반이 잘못 만들어져 있는 애플리케이션을 원상복귀하는데 얼마나 많은 시간이 소요될까? 1년, 2년.. 아니 어쩌면 10년이 걸릴지도 모른다. 그 이유는 리팩토링 진행하는 만큼 새롭게 리팩토링해야하는 소스가 만들어지기 때문이다.
최근 평가에 대하여 고민하는 부분은 개인 단위가 아닌 팀 단위로 평가가 행해졌으면 좋겠다. 많은 선진국들이 개인 위주의 평가에서 팀 단위의 평가로 변화하고 있다고 한다. 국내에도 개인 단위의 평가가 아닌 팀 단위의 평가가 더 객관적이라는 생각이 든다. 피플 웨어에서 이야기하듯이 기술적으로 뛰어난 개발자만이 꼭 필요한 존재는 아니 듯이.. 팀을 보면 팀의 활력소를 제공하는 감초 같은 이들이 있을 때 팀워크가 향상된다는 것을 국내의 많은 관리자들이 느낄 수 있었으면 좋겠다.
지금까지 웹 애플리케이션 개발 경험이 7년이 되어간다. 7년이 되는 지금까지 대부분의 개발 경험이 신규 프로젝트였다. 신규 프로젝트의 경우에는 새롭게 만든 애플리케이션이 정상적으로 동작하는 것이 확인되면 유지보수를 담당하게 될 개발자들에게 인수인계를 마치고 빠지는 형태로 지금까지 개발해왔다. 그리고 운영 업무보다는 신규 개발 업무가 훨씬 어려운 작업이며, 대단한 작업으로까지 생각하며 살아왔다. 그러나 7년의 마지막 1년.. 즉 최근 1년은 유지보수 업무와 개발 업무를 병행하고 있다. 처음 유지보수 업무를 맡았을 때 상당한 거부감이 생긴 것 또한 사실이다. 시간이 지나면서 다른 개발자이 개발한 소스코드를 분석하고 개선해 나간다는 것이 얼마나 어려운 작업인지를 새삼 느끼고 있다. 좀 더 빨리 유지보수를 업무를 해봤다면 나의 개발 스타일에도 많은 변화를 가져왔으리라 생각한다.
유지보수 업무를 맡은지 얼마되지 않아 이 책을 읽기 시작했다. 이 책의 "Legacy Code"라는 단어에 필이 꽂혀 책을 선택하게 되었다. 현재 내가 맡고 있는 모든 소스코드를 Legacy Code로 간주하고 좀 더 효율적으로 개발하고 싶은 욕심에 선택하게 되었다. 사실 처음에는 큰 기대없이 읽기 시작했다. 그러나 기대와는 달리 너무 많은 것을 느끼게 하는 책이다. Chapter를 하나씩 읽을 때마다 필자가 Legacy Code들과 얼마나 많은 시간을 싸워왔는지 피부로 느낄 수 있었다. 사실 운영 업무의 시작단계라 할 수 있는 나는 생각할 수 조차 없는 다양한 방식으로 Legacy Code가 가지고 있는 문제점들을 해결해나가는 것에 많은 것을 배울 수 있었다.
유지보수 업무의 핵심은 기존 기능을 변경하지 않는 상태에서 소스코드를 리팩토링하는 것이라 할 수 있다. 이 책은 이에 대한 다양한 해결책을 제시하고 있다. 기존 Legacy Code가 가지고 있는 문제점과 성격에 따라 다양한 해결책을 제시하고 있다. 특히 Legacy Code를 Step by Step으로 리팩토링해 가는 과정은 감동 그 자체이다. 테스트를 만들 수 없을 것으로 생각되는 Legacy Code에 테스트 코드를 만들어 가는 과정이 특히 많은 것을 배울 수 있게 했다. 지금까지 Legacy Code의 가장 큰 문제점은 테스트 코드가 없다는 것이다. 그러므로 기능을 추가하거나 리팩토링을 하더라도 해당 기능에 대해 검증할 수 있는 안정장치가 없으므로 인해 유지보수하기 힘든 것이 사실이다. 이 책은 기존의 Legacy Code에 테스트 코드를 어떻게 만들어 나갈 수 있는지에 대하여 많은 부분을 할애하고 있다.
많은 개발자들이 신규 프로젝트는 유지보수 성격의 없는 것으로 착각하고 있다. 그러나 신규 프로젝트 또한 프로젝트가 중,후반으로 진행될수록 지금까지 개발했던 코드들에 대한 유지보수 업무가 발생한다. 고객들의 요구사항은 언제든지 변경될 수 있기 때문이다. 따라서 이 책은 유지보수 업무를 담당하고 있는 개발자들에게만 필요한 것이 아니라 애플리케이션을 개발하는 모든 개발자들에게 필요한 내용이다. 신규 프로젝트를 진행하고 있는 개발자들도 자신이 개발하고 있는 소스 코드를 유지보수할 때 어떻게 하면 좋을지에 대해서 같이 고민할 필요가 있다. 현재 기능만 정상적으로 동작하면 되겠지라는 안이한 생각은 프로젝트 막바지에 자신의 발등을 찍는 경우가 종종 있다. 이 같은 코드는 추후 유지보수 업무를 전담하는 개발자들에게 큰 업무 부담으로 작용한다. 유지보수 용이한 소스코드를 작성하는 것이 다른 개발자들을 위하는 것이 아니라 자기 자신을 위하는 것이라는 것을 생각하고 이 책을 반드시 읽어봤으면 하는 바램이다. 그리고 현재 자신이 개발하고 있는 소스 코드가 이 책이 지적하고 있는 형태로 개발되고 있다면 이 책이 제시하는 방법을 이용해서 리팩토링해보는 습관을 들이는 것이 어떨까..?
유지보수 업무가 항상 재미없는 것만은 아니다. 유지보수 업무를 하면서 다른 개발자들이 구현해 놓은 소스코드를 보고 리팩토링하는 것도 무엇보다 중요한 업무이며, 많은 재미를 부여한다. 다른 개발자가 구현한 코드를 리팩토링하면서 자기 자신 또한 많은 성장을 가져올 수 있으며, 자신이 신규 프로젝트를 진행할 때 여러가지 상황에 대하여 고려하는 능력까지 키우게 된다. 나는 7년이 지난 지금에서야 유지보수 업무의 중요성을 느끼고 있다. 많은 개발자들이 좀 더 빠른 시기에 유지보수 업무를 해보는 것도 개발자로서 성장하는데 큰 도움이 되리라 생각한다. 이 책은 개발자들이 유지보수 업무를 맡아 막막할 때 새로운 즐거움을 느끼게 해 줄 책이다. 바쁜 업무 때문에 정독하는데 6개월이 걸렸지만 지금부터 다시 한번 읽고 실행해 옮겨볼 생각이다.
NHN에 입사하면서 계획했던 목표중의 하나가 영어였다. 내가 지금까지 살아오면서 가장 싫어하는 과목 중의 하나가 영어였다. 지금은 책까지 쓴 입장이지만 사실 난 국어와 영어를 가장 싫어했다. 국어 중에서도 시를 가장 싫어했다. 수학처럼 공식에 의하여 정확하게 떨어지는 답이 아닌 경우에는 답을 유추해내기가 너무 힘들었다. 특히 시는 은유적인 표현으로 인해 내포되어 있는 의미를 찾기란 더더욱 힘들었다. 고등학교 때의 점수를 보면 극명하게 들어난다. 수학이 거의 만점 수준이였다면 국어와 영어는 항상 반타작 수준이였으니.. 국어와 영어를 좀 더 좋아했더라면 지금과는 다른 삶을 살고 있으리라..
대학교 때도 나의 생각은 변함이 없었다. "영어가 뭐 중요해..난 영어 안하고 평생 먹고 살리라!"는 다짐을 하면서 영어와는 완전히 벽을 쌓고 살아왔다. 그런 각오로 진출한 사회생활.. 내가 몸담고 있는 이 바닥은 영어 아니면 새로운 지식 습득을 할 수 없을 정도로 많은 곳에서 영어를 사용하고 있다. 새로운 지식을 얻기 위해서 읽는 수 많은 영어 Article.. 자주 방문하는 대부분의 프로그램 관련 사이트는 죄다 영어이니..책은 또 어떠한가? 비싸지만 책꽂이에 꽂혀 있는 대부분의 책이 원서이다. 책 넘어가는 속도는 느리지만 그 속에서 얻게 되는 지식의 량이 무한정 크기에 포기할 수 없는 상태이다. 이제는 영어와 친구가 되기로 마음을 고쳐먹었다.
그렇게 싫은 영어를 하고자 하는 이유는 프로그래밍이 재미있고 좋기 때문이다. 더 많은 개발자들과 커뮤니케이션 하고 싶고, 더 많은 지식을 빠른 시간내에 습득하고 싶은 욕심 때문에 영어 공부를 시작하기로 마음먹었다. NHN에 입사할 때 여유가 생기면 바로 영어공부를 시작하리라 생각했는데 지금까지 바쁘다는 핑계로 미루고만 있었다. 이렇게 살아서는 안되겠다는 생각으로 드디어 영어학원 등록.. 다음주 월요일부터 영어와 가까워지려는 노력이 시작된다. 나의 콩글리쉬 발음에 우스워할 학원생들의 얼굴이 눈에 선하다. 나의 하루 일과가 바쁘게 시작될거 같다. 전날에 술 먹는 것도 자제해야 겠다는 생각이다.
6시 20분 기상 => 7시 용인 죽전 출발 => 7시 40분 분당 야탑까지 자전거로 이동 => 8시에서 9시까지 영어 회화 수업 => 9시 30분 자전거로 회사 이동
영어 공부를 시작하면서 운동량까지 늘려볼 생각이다. 지금까지 9개월을 자전거타고 출퇴근 했는데 살이 잘 안빠진다. 아무래도 회사와의 거리가 너무 가까워서 인듯하다. 지금까지 3kg 빠졌다. 학원까지는 대략 40분정도 소요되기 때문에 상당한 운동량이 되지 않을까 기대해본다. 거기다 영어까지..약간 무리한 계획이기는 하지만 답사를 해본결과 야탑까지 자전거로 출퇴근하는 것이 그리 힘들지 않을거 같다. 그 동안 운동량이 좀 되는지라 큰 무리없이 갈 수 있었다.
지금까지 살아오면서 학교를 제외한 학원을 다니는 것은 이번이 두번째이다. 첫번째 학원은 자바를 배우기 위해 다녔던 삼성 멀티캠퍼스이다. 나의 첫번째 학원 경험이 밥벌이를 위한 곳이 될 줄은 꿈에도 생각지 못했다. 이번이 두번째인 만큼 흥분되기도 한다. 사실 내가 학교 다닐 때는 사교육도 많지 않았고, 너무 깡촌이라 학원도 없었다. 중,고,대 모두 학원 다닐 필요도 없었다. 역시 사회 나오니 또 다른 도약을 위해서 학원을 선택하는 것도 좋은 길이라 생각된다. 너무 학원을 다닌 경험이 없어서인지 내 아이에게 너무 많은 학원을 강요하기는 싫다. 모든 것이 남이 아닌 자신이 선택하고 길을 만들어 가듯이 배우는 것 또한 그러하리라 생각하는데.. 주위의 많은 사람들은 나랑 다른 생각을 하고 있어서 힘들다. 심지어 내 아내까지도 완전히 다른 생각을 하고 살아가고 있으니..
이런 우여곡절 끝에 영어 학원에서 사용할 Nickname이 필요하다. 개인적으로 자바지기를 너무 좋아해서 사용하려고 했으나 주위에서 너무 길어서 좋지 않다는 반응이다. 앞으로 영어 관련해서는 계속 사용할 Nickname이라 좋은 Nickname 있으면 추천 좀 해줬으면 좋겠다. 외국인이 발음하기 쉬우면서 기억에 남을 만한 그런 Nickname.. 좋은 Nickname 만들어주는 이에게는 맛있는 식사한끼 대접한다.
기대하시라..조만간 영어 강좌가 위키의 많은 부분을 차지할지도 모른다.
근 한달만에 블로그에 글을 쓴다. NHN에 입사해서 팀장 역할을 맡고 어리버리한 상태에서 4개의 프로젝트를 동시에 진행해야 되는 상황.. 팀장이 무슨 역할을 해야되는지도 모르는 상태에서 맡겨진 프로젝트들.. 상상만해도 끔찍하지 않겠는가? 어제 상반기부터 진행해오던 4개의 프로젝트 중 마지막 프로젝트인 블로그 위젯 을 오픈 했다.
정말 많은 우여곡절 끝에 여기까지 끌고 왔다. 8월이 지나가고 있는 지금에서야 나의 2007년 상반기 업무가 완료된거 같아 마음이 홀가분하다. 그 동안 초보 팀장 밑에서 같이 고생하고 같이 웃어왔던 우리 팀원들이 있었기에 여기까지 올 수 있었으리라 생각한다. 그 동안 너무 여러개의 프로젝트로 인해 소홀히한 많은 일들을 이제부터 조금씩 챙겨나가야 겠다. 팀장이 되면 하고 싶었던 일들이 많았는데 아직 하지 못한 일들이 많다. 지금부터라도 여유를 가지고 하나씩 만들어 가는 작업을 하고 있다.
힘든 2007년 상반기 였지만 개인적으로 팀의 문화와 Teamwork을 형성하는데는 성공했다는 생각이 든다. 그리고 팀원들의 성향을 파악하고 팀원들이 자유롭게 일할 수 있는 공간으로 만들기 위하여 노력한 결과들이 조금씩 나타나고 있는 것으로 느끼고 있다. 묵묵히 일만하고 회의에서도 침묵으로 일관하던 초보 개발자들이 점진적으로 참여하는 모습을 보면서 현재 팀이 가고 있는 방향이 맞다는 것을 느끼게 된다. 요즘은 너무 시끄러운(내 목소리가 너무 커서이리라..) 팀이 되어서 다른 팀이 좀 조용히 해달라는 에피소드까지 생기고 있는 상황이다.
개인적으로 상당히 시끄러운 팀을 원한다. 개발자들이 자유롭게 이야기하고, 토론할 수 있으며, 열정이 느껴지는 그런 팀.. 우리 팀이 점점 더 그러한 모습으로 변해가는 것을 보면서 내 자신 또한 많은 열정을 느끼고 있다. 아직 부족한 부분이 많지만 새롭게 시도하는 일들에 거부감없이 따라주는 팀원들이 고맙다. 현재 팀의 변화를 위하여 진행하고 있는 일들을 정리해 보면 다음과 같다.
- 운영 업무를 맡고 있는 팀원들이 Pair로 업무 진행하는 것. 향후 점진적으로 모든 팀원들이 Pair로 일할 수 있는 분위기를 만들어 나갈 생각이다.
- 운영 개발자와 기획의 원할한 커뮤니케이션을 가져갈 수 있도록 정기적인 미팅과 Jira의 활용.
- 사용자 스토리 기반으로 반복주기를 결정하고, 반복주기가 완료될 때 QA를 받도록 개발 프로세스를 정리하는 작업.
- 선배 개발자들이 신입 개발자들의 스킬 향상을 위하여 일주일에 3-4시간 정도 할애하여 Pair로 업무를 진행할 수 있도록 한다.
이러한 작은 변화들이 아직 큰 성과를 내고 있지는 않지만 조만간 그 효과가 나타나리라 확신한다. 이외에 또 하나 준비하고 있는 작업은 팀원들이 개발하는 산출물에 대한 QA 작업이다. 리팩토링 포인트를 찾고, 버그 발생 부분을 찾는 것이 가능한 개발 환경을 많드는 것이다. 현재 팀장의 위치에서 해야할 역할이지 않을까 생각한다. 개발을 직접하는 것이 아니라 개발한 결과물에 대한 검증과 개발자들이 성장할 수 있는 바탕을 만들어 주는 것.. 나 또한 개발을 좋아한다. 하지만 언제까지나 개발하는 것이 전부일 수는 없는 듯하다. 다른 개발자들이 구현한 소스를 분석하고 그에 대한 Comment를 해주는 것 또한 재미있고 중요한 일이라 생각하면서 준비하고 있다. 나 또한 성장할 수 있으며, 팀원들 또한 나로 인해 성장할 수 있다면 그것이 최상이라 생각하면서 좀 더 역동적인 팀으로 만들어 갈 수 있으리라.
Last changed: 8월 03, 2007 20:18 by 박재성 Labels: devs
Spring IDE가 끝없이 발전하고 있는 모습을 본다. Mylyn이 Europa 버전에 포함되어 배포되지마자 바로 통합을 지원하고 있다. Spring 2.0.1에서는 Spring IDE의 핵심이라고 할 수 있는 core, 확장 기능을 제공하고 있는 AOP, JavaConfig, Web Flow를 지원하는 extension, Mylyn과의 통합을 담당하는 integration 세개의 파트로 분리된 형태로 플러그인을 제공하고 있다.
개인적으로 특히 관심이 있는 부분은 Mylyn과의 통합 부분이였다. Mylyn과 통합되면서 Spring Bean 설정 파일 중 각 Task와 연관되어 있는 Bean에 대하여 하나의 Context로 관리하는 것이 가능하다. Spring 설정 파일은 정형화된 형태이기 때문에 Java 리소스와 같이 하나의 Context로 관리하는 것이 가능하다.
향후 모든 XML에 대하여 Mylyn과의 통합은 힘들 수도 있지만 Spring 설정 파일과 같이 스키마에 기반한 XML 설정 파일의 경우에는 Mylyn과의 통합이 얼마든지 가능할 것으로 판단된다. 예를 들어 Hibernate나 IBatis 설정 파일 또한 Mylyn과의 통합이 가능할 것으로 판단된다.
Spring IDE가 Spring JavaConfig를 지원하는 줄 몰랐다. 이번에 추가된 기능인지는 모르겠지만 Spring JavaConfig에 대한 지원까지 하고 있는 것이 JavaConfig에 관심을 불러일으킨다. 조만간 JavaConfig도 한번 사용해보리라..
한 동안 글쓰는 일을 너무 등한시한 느낌이 든다. 여기에 글을 쓰는 것도 근 20일만의 일인 듯 싶다. 하지만 개인적으로 가장 재미있고 알찬 시간들을 보내고 있다. 비디오 로그를 오픈하고 마이크로 소프트에 'Jira와 Eclipse Mylyn을 활용한 효율적인 협업 전략'이라는 주제로 원고를 썼다. 원고를 쓰면서 Spring 프레임워크 강의가 3주 연속으로 토요일마다 진행됐다. 사실 3주 동안 강의를 진행하는 것이 쉽지 않은 일이지만 지나고 나면 개인적으로 많은 것을 느끼게 한다.
최근에는 사내에 Eclipse Mylyn을 홍보하기 위하여 많은 시간을 할애하고 있다. 사내 강의를 위해서 PPT 문서를 만들고, 새로운 아이디어를 생각해내는 내 모습을 보면서 한동안 조용히 숨죽여 있던 무엇인가 꿈틀거리고 있는 내 모습을 본다.
흥분될 때의 내 모습은 다르다는 것을 많이 느낀다. 위와 같은 PT는 평상시에는 잘 나오지 않는다. 내가 무엇인가 재미를 느끼고 흥분되었을 때 좋은 PT를 생각해 낼 수 있다는 생각이 든다. 위 PT는 단순하게 팀원들의 동영상에서 재미난 표정들을 화면 캡쳐해서 만들었다. 팀원들에게 위 PT를 사용했을 때의 반응은 상당했다. 항상 컴퓨터 앞에만 앉아 있어야 일을 잘할 수 있는 것이 아니라 가끔씩은 휴식을 취하는 것이 더 큰 생산성을 위한 지름길이라는 것을 많이 느낀다.
아마도 NHN에 입사하고 만족스럽지 못한 생활을 한 이유는 내가 하고자하는 방향으로 일을 추진하지 않았기 때문이리라. 지금까지는 NHN의 짜여진 틀 속에서 내 자신을 맞춰가면서 외부에서 내가 하고 싶은 일을 찾으려고 노력해왔다. 그러나 대부분의 시간을 회사내에서 일하고 있는 상황에서 외부적으로 부족한 점을 채운다는 것은 어려운 일이다. 한동안 방황아닌 방황을 한 이유가 이 때문이리라 생각한다.
올 하반기 들어서면서 내가 하고 싶은 일을 팀 내부적으로 추진해보고 싶은 욕구가 강하게 들었다. 사실 팀장으로서의 역할이 힘든 점도 있지만 내가 하고자하는 방향이 있다면 팀원들을 설득(설득하는 것도 팀장의 능력이리라..)해서 하나의 방향을 만들어갈 수 있다는 것이 큰 장점이다. 그 첫번째 일환으로 팀원들의 요구로 인해 팀내, 외 커뮤니케이션 효율화 방안, 개발 효율화 방안들에 대하여 매주 한 시간씩 의견을 나누고 있다. 그 동안 하지 못한 이야기들을 마음껏 나눌 수 있다는 것이 더 없이 기쁘다. 또 하나의 일환으로 Eclipse Mylyn을 하반기에 적용하려는 것이 나의 욕심이다. 우리 팀 만이 아니라 전사적으로 기획자, 개발자, QA가 같이 협업할 수 있는 환경을 만드는 것이다. 지금 그 일환으로 Jira와 Eclipse Mylyn의 강점에 대하여 많은 이들에게 전파하려고 노력하고 있다.
오늘 팀원들에게 내가 준비한 PT와 데모를 보여준 결과 만족할 만한 결과를 얻었다. 새로운 툴을 적용하려고 하면 많은 이들이 거부감을 표시하는데 Jira와 Eclipse Mylyn의 통합에 대해서는 그 필요성에 대하여 강한 지지를 보내주었다. 내가 추진하려고 하는 현재의 이 작업이 나 혼자만의 필요성에 의하여 하는 것이 아니라는 것을 다시 한번 느낄 수 있었다. 앞으로 팀을 벗어나 개발자 그룹, 기획, QA까지 Jira를 활용하고, 개발부터 유지보수까지 일관된 툴 하에서 관리가 가능하도록 추진해볼 생각이다.
다른 것보다 현재의 이 같은 일을 하고 있는 내 모습이 진정한 나의 모습이라는 것을 느끼고 있다. 업무 외적으로 준비하고 추진하는 일들이지만 힘들지 않고 오히려 내 자신에게 강한 자극과 열정을 느끼게 한다. 누군가 시키는 일만 하는 것이 아니라 내가 가고자하는 방향으로 업무를 진행시켜 나갈 때의 흥분됨은 이루 말할 수 없다. 내가 하고 싶은 일을 회사라는 조직내에서 모두 할 수는 없지만 내가 가고자하는 방향이 있다면 하나씩 만들어 나가면서 재미를 느끼고 싶다. 요즘 나는 살아 있는거 같아 너무 기분이 좋다.
Jira외에 또 하나의 작업을 준비하고 있다. 근무 외 시간에 틈틈이, 조금씩 준비 중인 작업이다. 아마도 조만간 그 결실을 볼 수 있을 것이라 생각한다. 내 자신이 관리자로서의 역할만이 아닌 개발자로서의 열정도 가져갈 수 있도록 하기 위하여 하나씩 적용해나가고 있다. 그 결과물이 만들어질 때 주위의 많은 이들에게 다시 한번 그 가치를 전파하기 위하여 노력해볼 작정이다. 아직 내가 원하는 방향을 만들기 위하여 많은 시간과 노력이 필요하지만 과정을 즐기다보면 좋은 결실을 얻을 수 있으리라 생각한다. 그 결실을 나 혼자만이 아닌 우리 팀원들과 같이 만들어 나갈 수 있도록 옆에서 도와주는 조력자의 역할을 자진해볼 작성이다.
NHN에서 내 모습 찾기는 이제부터 시작이다.
Last changed: 7월 06, 2007 12:56 by 박재성
Eclipse Europa 버전에서 가장 크게 달라진 부분이 Mylyn이라는 생각이 들어 지난 주말부터 Mylyn의 핵심 기능들을 사용해봤다. 제대로 된 설명서가 없었던 관계로 동영상 자료도 보고 사용자 매뉴얼도 보면서 하나하나씩의 기능을 살펴볼 수 있었다.
Mylyn에서 Task Repository로는 Jira를 사용했다. Jira에 대한 라이센스도 있는 상태였고, 현재 사내에서 버그 추적을 위해 Jira를 사용하고 있다는 것이 친숙함으로 다가왔다. Jira 세팅은 몇번 해본 경험이 있어서 어렵지 않게 진행했는데 처음 연동부터 삽질의 연속..디폴트 플러그인에 Jira 연동 모듈이 포함되어 있지 않아 별도의 플러그인 설치부터 시작하여 몇가지 추가적인 작업을 한 후에 연동하는 것이 가능했다.
기능 하나 하나를 사용했을 때의 그 짜릿함이란.. 정말 그 동안 있었으면 하고 바랬던 많은 기능들이 포함되어 있는 것을 보고 감탄하지 않을 수 없었다. 정말 이 플러그인 만든 개발자들이 존경스러울 뿐이다. Mylyn을 분석하고 있는데 마이크로 소프트 기자에게서 원고 의뢰가 들어왔다. Jira를 활용한 효율적인 협업 방법에 대하여 글을 써달라고.. 이번 달에 강의도 3주 연속 있고, 서비스 오픈도 있어 바쁘지만 정말 써보고 싶은 욕심에 흔쾌히 수락했다. 이번 원고에서는 내가 처음 CVS를 사용했을 때의 그 짜릿한 기분을 다른 개발자들에게 전하고 싶다. 많은 개발자들이 Mylyn의 강점을 이해하고 활용할 수 있으면 좋겠다. 다음번 Eclipse 강의는 CVS, Mylyn을 활용한 협업 방법에 대해서도 추가해야겠다.
이번 원고 작업을 하면서 쌓은 지식들을 바탕으로 사내에도 Mylyn 플러그인의 활용 방안에 대해서 전파해볼 생각이다. 앞으로 진행하는 많은 프로젝트에서 Mylyn을 활용해서 좀 더 효율적인 협업 전략을 가져갈 수 있도록 시도해볼 생각이다. 다른 개발자들에게 공유할 수 있는 많은 지식들을 얻을 수 있으면 좋겠다.
N사에 입사하고 많은 프로젝트에 대한 지원은 있었지만 처음부터 끝까지 프로젝트에 참여한 경우는 이번 비디오 로그가 처음이였다. 비디오 로그는 블로그의 서브 로그로서 동영상 컨텐츠만을 집중적으로 관리하기 위한 전문 블로그이다.
이미 블로그가 있고, 성장하고 있는 상황에서 새로운 로그를 추가하는 것은 좋은 전략처럼 생각되지 않았다. 그러나 이러한 측면에서 개발자와 기획자의 사고 차이가 있을 것이라 생각한다. 동영상 컨텐츠의 경우 별도의 영역에서 관리하고 싶다는 기획자들의 요구에 개발자들은 승복할 수 밖에 없었다. 개발자들이 기획적인 능력도 필요하지만 기획만을 전담해온 기획자들의 의견을 무시할 수는 없기 때문이다. 내 자신 또한 개발쪽에 너무 치우쳐져 있는 상황이였기 때문에 비지니스적으로 기획자들을 설득할 자신 또한 없었던 것이 사실이다.
이 프로젝트는 나에게 큰 의미가 있는 프로젝트였다. N사에 입사해서 전 과정을 거친 첫번째 프로젝트의 의미도 있지만, 그에 앞서 내가 관리자 역할을 맡으면서 처음으로 오픈한 서비스이기 때문이다. 관리자로서의 역할을 잘했던 잘하지 못했던 상당 부분은 결과를 통해서 이야기되기 때문이다. 또한 이러한 서비스의 오픈으로 인해 같이 일해온 팀원들에게도 많은 성취감을 안겨줄 수 있다는 것이 기쁘다.
서비스를 오픈한다는 것이 쉬운 일이 아님을 이번 오픈을 하면서 다시 한번 느꼈다. 지금처럼 많은 사용자가 사용하고 있는 서비스 오픈은 처음이였기 때문에 오픈 시간을 준수하려고 노력했다. 그러나 역시 예외 상황이 발생하는 것은 어쩔 수 없었다. 물론 철저히 준비하지 못한 우리들의 부족함이 가장 컸으리라.. 이번 오픈 과정을 통해서 부족했던 부분을 다음 오픈에서는 보완할 수 있도록 정리하는 과정을 가져야겠다.
비디오 로그 프로젝트를 진행하면서 얻게된 소중한 경험들을 발판으로 더 좋은 애플리케이션을 만들어 낼 수 있도록 지속적으로 노력해야겠다.
Last changed: 7월 02, 2007 21:07 by 박재성 Labels: reviews
웹 애플리케이션을 개발하면서 가장 많은 시간을 투자하는 작업이 관계형 데이터베이스와의 인터페이스를 담당하고 있는 퍼시스턴스 Layer에 개발일 것이다. 관계형 데이터베이스의 사용이 일반화 되면서 퍼시스턴스 Layer를 좀 더 효율적으로 개발하기 위한 많은 방법들이 자바 진영에서 등장해왔다. JDBC가 그 첫번째 역할을 담당했으며, JDBC를 한단계 추상화한 프레임워크가 iBatis이리라. iBatis와는 다른 형태의 추상화이지만 또 한 형태가 Hibernate와 같은 ORM(Object Relation Mapping) 프레임워크들이다. 프로젝트 성격에 따라 iBatis 형태의 프레임워크가 적절한지, Hibernate 형태의 ORM 프레임워크가 적절한지에 대해서는 아직까지도 많은 커뮤니티에서 논란의 여지가 있다. 사실 내 자신 또한 두개의 프레임워크가 어떤 성격의 프로젝트에 적합하다고 칼로 무를 자르듯이 분리하기란 힘들 것이다.
이 책에서는 iBatis와 Hibernate 프레임워크를 분리하면서 각각의 장,단점에 대하여 솔직하게 이야기하고 있다. 근 1년 동안 프로젝트를 진행하면서 iBatis 프레임워크를 사용하고 있다. 그 전까지 Castor나 Hibernate와 같은 ORM 프레임워크를 사용한 경험으로 비추어봤을 때 iBatis는 상당히 불편한 점이 많으며, 제약사항이 많다는 것을 느낄 수 있었다. 그러나 이 책을 읽으면서 그에 대한 많은 생각들이 깨지는 계기가 되었다. 프레임워크라는 것이 각각의 용도가 있고, 환경에 따라 적절하게 사용될 때 그 가치를 극대화할 수 있을텐데, 지금까지 내 자신은 지금까지 사용해왔던 프레임워크의 그늘에 가려 전체를 보지 못한 듯한 느낌을 지울 수 없었다.
개인적으로 iBatis는 책을 사지 않아도 프로젝트에 적용할 수 있을 만큼 충분히 배우기 쉬우며, 단순한 구조로 되어 있다. 이 책의 옮긴이인 이동국님이 번역해 놓은 PDF 문서만을 통해서도 필요로한 모든 기능을 적용하는 것이 가능하리라 판단된다. 그러나 이 책을 반드시 읽어야 하는 이유는 iBatis가 왜 등장하게 되었으며, iBatis가 목표로 하고 있는 것이 무엇인지를 느끼기 위해서이다. 개인적으로 프레임워크가 등장하게 된 배경과 어떤 성격의 프로젝트에 적합한 프레임워크인지를 아는 것이 더 중요하다고 판단된다. 프레임워크가 가지고 있는 세부적인 기능을 익히는 것은 그 다음 작업일 것이다. 이 책에서는 다른 온라인 문서에서 알 수 없었던 부분들을 포함하고 있어 더욱 좋았다. 기술적인 항목들에 대해서는 현재 iBatis 프레임워크를 적용하고 있는 단계라 편안한 마음으로 읽을 수 있었다.
역시 iBatis는 단순함을 하나의 목표로 삼고 있다. 지금 이 순간에도 더 단순해지기 위한 방법들을 찾고 있다는 저자의 글에서 많은 것을 느낄 수 있었다. 애플리케이션을 개발함에 있어 단순함 만큼 강력한 것이 또 있을까? 지금까지 많은 기술들이 살아남은 주요한 요인은 많은 요소들이 있겠지만 그 중 가장 큰 부분이 단순함이지 않을까? 단순하기 때문에 많은 개발자들이 사용했으며, 지속적으로 발전할 수 있지 않았을까? iBatis가 진정한 ORM 프레임워크가 아니라도 나름대로의 영역을 가지고 지속적으로 발전해 나갈 것이다. 특히 국내에서는 Hibernate, TopLink, OJB와 같은 ORM 프레임워크보다는 iBatis의 성장이 눈에 띄게 높을 것으로 생각된다. 국내에서 진행되고 있는 대부분의 SI 프로젝트에서는 Hibernate, TopLink, OJB와 같이 학습 곡선이 높은 프레임워크는 적용하기 너무 위험부담이 크다. ORM 프레임워크를 제대로 사용할 줄 아는 개발자도 많지 않으며, 한명의 개발자가 잘 한다고 하더라도 나머지 개발자들이 따라주지 않는다면 이 프로젝트는 실패하기 쉽상이다. 하나의 팀이 급하게 만들어졌다 사라지는 국내 개발 환경에서는 ORM 프로젝트를 적용하기 너무 힘들다. 이 같은 상황에서는 iBatis가 오히려 적합할 것이다. 이미 JDBC 기반의 SQL문 구현에 익숙한 개발자들은 몇시간, 하루정도의 교육 만으로도 iBatis에 쉽게 적응할 수 있을 것이다.
물론 iBatis 프레임워크 또한 많은 한계점을 가지고 있다. 좀 더 OOP적으로 개발하기 위한 시도를 할 때 iBatis의 사용은 많은 좌절감을 안겨준다. 개인적으로 iBatis를 사용하면서 이 같은 한계로 인해 차라리 Spring JDBC를 사용하는 것이 낳지 않을까라는 생각도 해봤다. 물론 JDBC 기반으로 개발을 하더라도 많은 코딩량이 발생하겠지만 iBatis가 가지는 제약 때문에 제대로 된 설계를 가져가지 못할 때도 있었다.
모든 프레임워크가 그러하듯이 좋은 점이 있으면, 나쁜 점이 있을 것이다. 너무 하나의 프레임워크에 대한 환상을 가지지 않는 것이 가장 좋을 것으로 판단된다. 프로젝트의 상황에 적절한 프레임워크를 선택해서 자신의 입맛에 맞도록 사용하는 것이 개발자들의 또 다른 능력이지 않을까? 이 책을 통하여 퍼시스턴스 Layer 개발에 대한 또 하나의 눈을 키웠으면 한다.
Eclipse의 발전은 어디까지일까? Eclipse가 3.2 버전까지의 버전 이름을 버리고 이번에 Europa라는 이름으로 정식 배포되었다. Eclipse는 새로운 버전이 나올 때마다 뭔가 새로운 기능을 활용하기 위하여 노력했던 기억이 있다. 그러나 버전이 바뀌면서 그렇게 많은 큰 변화가 없었기 때문에 적응하는데 큰 문제가 없었다.
이번에 배포한 Europa 버전도 이전 버전과 크게 다르지 않을 것이라 생각했다. 사실 Europa 버전을 설치하고 실행해보기 전까지 큰 변화를 느끼지 못한 것이 사실이다. 그러나 Eclipse Europa 버전을 다운 받았을 때 가장 다르다고 느낀 것은 작아진 Eclipse 파일 사이즈였다.
파일 사이즈가 이전 버전에 비해서 3분의 2가 되어 버렸다. 도대체 어떤 기능을 버렸기에 이렇게 사이즈가 작아졌을까라는 의구심이 들었다. 버전업이 되면서 기능 추가로 인해 사이즈가 증가하는 것이 일반적이였는데 이번 버전은 40Mega가 작아졌다니.. 그래서 찾아보았던 Eclipse 버전이 용도에 따라 분리되었다는 것을 확인할 수 있었다.
자바 개발자용, C, C++ 개발자용, RCP, 플러그인 개발자용, Cusomizing을 위한 용도..각각의 용도에 맞도록 최적화된 상태로 배포본을 만들었기에 파일 사이즈가 작아진 것이였다. 이와 같은 전략이 가능한 이유는 Eclipse가 가지고 있는 플러그인 방식의 개발 방법 때문일 것이다. 앞으로 Eclipse는 더 다양한 용도의 배포본을 만들어 낼 것이다. 필요하다면 새로운 플러그인만을 설치하면 될 뿐이다.
Eclipse를 시작하면서 다르다고 느낀 점은 Eclipse가 더 이상 버전을 사용하지 않고 Europa를 직접적으로 사용하고 있다는 것이다. Eclipse의 시작시 버전이 보이지 않는다는 것을 확인할 수 있다.
자바 개발자용 Eclipse 버전에서 가장 크게 달라진 점은 기본 플러그인으로 PDE가 빠지고 Mylyn이 포함되었다는 것이다. Mylyn은 Eclipse Europa가 나오기 전 Mylar라는 이름으로 알려진 Task Management를 위한 플러그인이였다. Mylar가 처음 등장했을 때 나 또한 신기한 마음에 설치하고 실행해봤던 기억이 난다. 그런데 Bugzilla, Jira와 크게 다르지 않다는 생각이 들어 사용할 필요성을 크게 느끼지 못했다. 사실 브라우저를 통하여 Bugzilla와 Jira에 접근하는 것이 아니라 Eclipse로 통합했다는 것 이외에는 별다른 새로움을 느끼지 못했기 때문이다. 그런데 이 놈이 자바 개발자 환경에 디폴트로 포함이 되다니..
뭔가 새로움이 있을 것으로 생각하고 Mylar에서 제공하는 데모를 통하여 그 기능을 다시 한번 확인했다. 그러나 내가 처음 생각했던 기능 이외에도 무수히 많은 기능이 포함되어 있으며, 개발을 하면서 부족하다고 느꼈던 부분들을 포함하고 있다는 것을 알 수 있었다. 왜 Mylyn이 디폴트로 포함되었는지는 어렴풋하게나마 데모를 통하여 느낄 수 있었다.
Mylyn의 첫번째 기능은 역시나 Bug, Issue, Task를 관리하는 Bugzilla, Jira와의 통합에 중심을 두고 있다. 내가 첫번째 느꼈던 그 기능임을 알 수 있다.
데모를 보면서 신선하다고 느낀 부분은 Task단위로 작업 범위를 관리할 수 있는 Context 개념이다. 각 Task별 작업을 관리하기 위하여 그 동안 사용했던 방법은 Workingset, Filter등을 활용해왔다. 그러나 이 방법은 너무나 짜증나는 작업이며, 각 Task단위로 분리하는 것은 거의 불가능에 가깝다. 그러나 Mylyn은 이 같은 단점을 보완하여 각 Task별 작업 범위를 관리하는 것이 가능하다.
Mylyn은 Context를 통해 각 Task별 작업 영역을 지정하는 것이 가능할 뿐만 아니라 이 Context를 각 개발자간에 공유하는 것이 가능하도록 지원한다. 과거에 내가 작업했던 Task를 다시 작업하려고 할 때 저장되어 있는 Context를 통하여 작업 영역을 확인할 수 있으며, 내가 작업한 Context를 다른 개발자들 또한 활용할 수 있도록 지원하고 있다. 사실 과거의 작업 영역을 찾거나 다른 개발자들의 작업 영역을 찾는 것이 상당히 짜증나는 작업임을 알기에 이 기능 또한 상당히 만족스러움을 알 수 있다.
또한 각 Task별 스케줄 관리까지 지원하고 있다. 아마도 현재 내가 적용하려고 하고 있는 사용자 스토리 기반의 개발에도 충분히 활용할 만한 가치가 있을 것으로 생각한다.
이외에도 더 많은 기능을 제공하고 있다. 느낌상으로는 Context별 Test기능이 마음에 든다.
아직까지 Mylyn을 본격적으로 사용하지는 않았지만 앞으로 활용가치가 무한할 것으로 생각한다. 앞으로 Mylyn에 대한 활용방안을 찾아봐야겠다. Mylyn을 이용하여 좀 더 효율적인 프로젝트 관리가 가능할 수 있을 것으로 판단된다.
Mylyn 이외에도 이번 Europa 버전에는 많은 변화가 있을 것으로 기대한다. 앞으로 조금씩 사용해보면서 그 무한한 가치를 느껴볼 생각이다. Eclipse의 끝은 어디까지 일지가 겁날 뿐이다. 이제는 자바 개발자 뿐이 아니라 C, C++ 개발자들까지 흡수해나갈 생각인가 보다.
그래도 자바 개발자들에게는 이 같은 좋은 툴을 무료로 사용할 수 있다는 것이 엄청난 매력이지 않을까? 개발자들의 삶에 Eclipse가 약간의 윤택함을 안겨줄 수 있다면 그 보다 기쁘지 않을 수 있겠는가?
몇 십년 동안 살아오면서 어머니와 같이 나들이를 한 기억이 별로 없다. 중 3 때 아버지께서 돌아가신 다음에 두 아들을 교육시키고, 결혼까지 시키느라 변변히 여행다운 여행을 해본 기억이 많지 않다. 지금도 동생이 시간적인 여유가 많지 않아 멀리 여행떠나기는 힘든 상황이다.
올해는 정말 오랜만에 어머니와 동생 식구까지 에버랜드로 나들이를 갔다왔다. 어머니 생신 때문에 모이는 자리였는데 아이들을 위해서 에버랜드행을 결정했다. 물론 어머니께서 놀이기구를 많이 타지는 않으셨지만, 오랜만에 자식들과 함께한 나들이에 무척이나 기뻐하셨다. 세명이던 식구가 몇 년 사이에 아홉명으로 늘었지만 명절이 아니면 모두 모이기 힘들었는데 짧은 이번 여행은 너무 즐거운 한 때 였다.
작년에 큰 외삼촌이 돌아가셨다. 아버지, 어머니가 모두 곁에 있지 않아 내 어머니를 친 어머니처럼 생각하는 외사촌들까지 어머니 생신을 챙겨주기 위해서 구미에서 용인까지 먼길을 와준건 또한 너무 고마웠다. 그 동안 가깝게 지내는 사촌들이지만 어머니 생신 챙겨주겠다고 그 먼길을 오는 것을 보면 이 놈들도 이제 다 컸구나라는 생각이 든다.
해가 지나면 지날 수록 그 동안 아픈 기억보다 기쁜 기억이 더 많다는 것은 나에게 큰 힘을 주는 듯하다. 그 동안 많은 슬픈 기억들 때문에 소극적으로 살아왔던 나이지만, 조금씩 변화해가는 우리 식구들의 모습을 보면서 나 또한 자심감을 가지고 하루 하루 지내고 있다. 좀 더 나은 미래를 위해서..
그리고 다음 세대를 살아갈 우리 자식들을 위해서도.. 자식들에게 많은 재산을 물려줄 욕심은 없다. 단지 평범하게 그네들이 하고 싶은 일들을 마음껏 하면서 뛰어놀 수 있는 기반만 마련해 줄 수 있다면 나는 그것으로 만족할 수 있을거 같다. 작은 행복을 소중히 여길 수 있는 사람이 진정 행복하지 않을까?
한 동안 집에서 위키에 글을 쓰는 경우가 많지 않으면서 한동안 나의 연애편지가 잠시 쉬었다. 오늘 오랜만에 일찍 퇴근했다. 한동안 신규로 오픈하는 서비스 때문에 거의 매일 야근과 토요일 출근이 반복되었다. 너무도 빨리 퇴근한 아빠를 보고서 딸내미가 하는 말..
딸 : "아빠! 오늘은 왜 이렇게 빨리 왔어?"..
침묵이 흐른 후..
나 : "아빠가 일이 빨리 끝나서"..
딸 : "아아 오늘은 일이 많지 않았나 보구나"..
아마 딸도 알고 있나보다. 아빠가 일이 바빠서 매일 늦는 줄을.. 아무 것도 모르고 있는거 같아도 아이들은 이미 다 알고 있는 듯 싶다. 숨기려고 하기보다는 아이들과 진솔하게 이야기 해보는 것도 좋다라는 생각이 가끔 든다.
오늘 편지는 사귄 후 처음 싸운거 같다. 우리는 지금도 그렇지만 싸우기 시작하면 아무말도 하지 않는다. 그냥 상대방의 화가 풀릴때까지 기다리는 것이 가장 좋은 화해방법이라는 것을 이미 알아 버렸기 때문이다.
Wendesday. AUGUEST. 7. 1996.
너에게.
지금은 저녁이야. 아직 해님은 걸려있어.
좀 전에 퇴근했다. 할머니랑 동생이랑 간식 먹고 좀 놀다가
네 생각이 나 펜을 들어.
나 오늘 다시 가입했다. 호출기 말야.
네게 전하려고 수화기를 들었었다. 근데 관뒀어. 그냥.
요즈음 넌 뭘하며 지내려나?
꽤나 잘 견디어 내는구나.
언제나처럼 넌 내게 아무런 흔들림도 보내지 않고 있어.
아무렇지도 않다는 듯이 그저 고요할 뿐야.
무심하리만치.
어쩌면.
이럴 수도 있는 거구나.
그러면서 어떻게 좋아한다 말할 수 있니?
남자들은 그럴 수도 있는거니?
아님 이게 너의 방식인거니?
특별한 걸 바라는게 아니잖아.
작은 성의라도 보여야잖아. 너를 느낄 수 있게.
너 안에서 나를 찾을 수 있도록 말야.
그래야 하는거 아니니?
집으로 돌아오는 길엔 대문 옆 우편함을 보곤 해.
혹시나 하는 마음으로.
네게선 아무런 소식도 없어.
기다리는 맘이 잘못되기라도 하듯이.
그런걸까? 이것두 내탓인거니?
언제나 넌 나를 배려한다지만 이건 무심한게 아닐까 해.
전번에 그랬잖아.
네게 해준게 너무 없다고.
앞으로 사이좋게 지내면서 노력할거라구.
그리구 보다 적극적으로 다가 갈거라구.
내가 요구한게 아니었잖아. 너의 다짐이지 않았니?
근데 이게 뭐야?
대체 뭘 어떡하란 말야?
차라리 널 놓아달라고 얘기 해.
벗어나고 싶다고, 모두 버리고 싶다고, 이젠 자유로와지고 싶다고
소리치란 말야.
왜 가만이 있는 거니?
대체 무엇을 기다리는 거야?
널 알 수가 없어.
수용하기가 힘겨워.
이런맘 모를테지 넌..
네 생각을 하면 자꾸만 화가 나.
이러지도 저러지도 못하고 있잖아.
넌 내탓이라 하고, 난 네탓이라 하고.
...
어쩌면 네게 아주 오래도록 연락하지 않을지도 몰라.
너무나 익숙해져 있는 홀로된 삶에 널 그리워하지 않으며
지낼 수도 있을 것 같아.
너의 숨소리를 잊으며 모른채로 살아갈 수도 있을 듯 해.
아무렇지도 않은 듯이 그냥 그렇게.
가끔씩 널 떠올리며 추억으로 간직한 채.
시간이 흐를수록 희미해져만 가.
아마도 넌 내게 안개가 아닐까? 밤안개.
나.
그래도 되니?
그렇게 되면 무지 서운할테야.
비오는 날 편지가 쓰고프면 어떻게 하지?
펜이 들고 플 때면 네 생각이 간절할테야. 아마도.
한번 웃어버리지 뭐..
새벽 1시경.
Jeong.
우리는 항상 이런 식으로 싸웠다. 밖으로 내색하지 않으면서 속으로 가슴앓이 하면서.. 아내 영정이도 그리워하면서 자존심 때문에 내색하지 않는 그런 사랑으로..
저녁에 시작한 편지가 새벽 1시에 끝나고 있다. 아마도 나에 대한 서운함과 그리움을 담아서 조금씩 조금씩 몇시간을 써내려간 듯하다. 지금 옆에서 성경 공부를 하고 있느라 내가 여기에 자신의 편지를 공개하고 있는지도 모르고 있지만, 지금 내 곁에 같이 있다는 것이 고마울 따름이다. 그래도 연애할 때의 알콩 달콩 싸우던 때가 가끔씩 그리워진다. 내가 아내에게 편지를 쓴지도 벌써 8년이 되어간다. 아마도 결혼하고 직장 생활을 시작하면서 편지를 쓰지 않은 듯 싶다. 가끔씩 글을 내 마음을 전할 때 사람의 소중함, 지금 아내의 소중함을 느낄 수 있었는데..지금은 곁에 있다는 이유만으로 너무 소홀히 하지는 않고 있는지 모르겠다.
내게 있어 가장 소중한 존재임에도 불구하고..
|
|
|
Community
