잔디구장

카이스트에 잔디구장이 생겼다! 지난 여름방학중 시작된 동측 원운동장 공사는 한동안 우리의 궁금증을 자아냈다. ‘설마 잔디를 깔기야 하겠어?  그냥 우레탄 트렉을 만드는거겠지.’ 정도로 예상하고 있었는데 언젠가 부터 운동장이 초록색으로 물들기 시작했고 밤마다 커다란 조명탑에서 불 빛이 쏟아졌다. 카포전 직전(?)에 완성된 잔디구장은 매일 밤 12시까지 밝은 조명이 쏟아지고 있다.

졸업하기 전에 꼭 잔디구장에서 축구를 해보고 싶어서 룸메이트인 순일군의 연구실과의 경기를 추진하여 어제밤 게임이 이루어졌다.  각 팀당 몇명의 용병(DB랩, TC랩)을 포함한 PL랩 vs NC랩의 경기였다. 밤 9시에 운동장에 가보니 이미 십수명의 사람들이 경기를 하고 있었기에 1시간 넘게 기다려야했다. 그 동안 골대 뒷 쪽 공터(?)에서 미니게임을 하면서 시간을 보냈는데 사실 이 미니 게임이 더 힘들었다.

시간이 흘러 NC랩도 모두 도착하고 10시 20분쯤에서야 비로소 게임이 시작되었다. 우리랩 사람들은 이미 미니 게임으로 지쳐있었고 NC랩은 전력이 고르고 탄탄하다고 생각했기에 우리가 이길꺼라는 예상은 할 수가 없었다. 쉽게 가능한 예상대로 전반전은 우리가 내내 밀렸다. 난 오른쪽 공격수였는데 공이 수비지역에서만 머물었기에 공을 몇 번 못잡았다. 워낙 수세에 몰리다 보니 공격할 기회가 와도 공격지역에 사람이 없어서 결정적으로 드리블을 못하는 나는 어찌할 바를 모르다가 한번의 힘없는 유효슈팅을 날린 것에 만족해야했다. 하지만 우리의 수비는 건철형을 필두로 상대방의 파상공세를 훌륭하게 막아주었기에 전반전은 득점없이 비길 수 있었다.

후반전이 시작되어 용병인 DB랩의 경모형과 우리랩의 재호형이 공격으로 치고 올라 오면서 공격의 실마리가 풀리기 시작. 상대편의 최종수비수가 재호형을 제끼려고 하는 것을 본 순간 생각하기를 만약에 수비수의 약간 오른쪽에 있는 재호형을 제끼기 위해 수비수가 왼쪽으로 치고 나올 때 공이 길다면 분명 나에게 찬스가 올 것 같았다.  내 예상은 적중했고 공이 나에게로 굴러와 본능적으로 슛을 날렸는데 거짓말 처럼 골키퍼의 키를 넘기고 들어가버렸다. 나의 어설픈 볼 처리 능력에 방심하던 상대편은 아마도 적잖이 당황했을 것이다. 나에게 킬러본능이???

그 순간부터 우리가 이길 수 있다는 분위기가 느껴졌다. 상대의 코너킥 이후 혼전상황에서 날라온 골이나 다름없는 슛팅을 골키퍼 창범이가 펀칭으로 걷어냈는데 이는 한골을 넣은 것이나 다름 없었다. 아니 그 이상일지도 모르겠다. 우리는 계속 대등한 경기를 펼칠 수 있었고 경모형의 추가골로 2:0으로 깔끔하게 승리를 챙길 수 있었다. 잔디구장에서의 야간게임은 정말 즐거웠다. 졸업이 얼마남지 않은 것이 아쉬울 정도로. 다음주에는 리턴매치?

펀드수익율


지난 8월 14일 동양종금에 CMA 계좌를 개설하면서 수수료 면제 혜택을 받기 위해 적립식 펀드에 가입했다. 모든 금융자산을 우리은행에서 동양종금으로 이동하면서 두개의 펀드에 가입하고 나머지 금액은 CMA계좌에 넣어두었다. 두 펀드 모두 한달이 조금 넘은 지금 시점에서 4%를 상회하는 좋은 수익률을 올리고 있다.

돈이 돈을 만든다. 현재 원금 50만원으로 대략 2만원의 수익을 올리고 있는데, 만약 원금이 5천만원이였다면 한달사이에 2백만원의 수익을 올렸을 것이다. 주식에 대해서 무지했던 어린시절에는 주식으로 수익을 올리는 것을 불노소득이라 단정지어 버리고는 부정적으로만 바라보았는데, 단타매매가 아닌 장기적인 관점에서의 투자로써 기업에 자금을 빌려주고 경제활동으로 생산된 파이를 공평하게 나눈다고 생각한다면 경제에 기여하는 일일지도 모르겠다.

한동안 경제관련 책을 읽으면서 알게된 사실(?)은 우리나라도 곧 미국의 다우지수가 10년사이에 10배로 상승한 것과 같은 시기가 올 거라는 것이다. 부동산 시장의 가치하락과 베이비붐 세대들이 경제의 중심에 서면서 투자의 방향이 주식시장으로 쏠리게 되는 등의 근거는 그럴듯해 보인다. 내년부터 돈을 벌어 투자할 수 있다는 사실이 다행스럽게 느껴지는 요즘이다. 나는 우리의 경제를 믿는다. 어차피 우리는 대한민국이라는 배를 함께 타고 있다.

Plug-in Development Environment

Plug-in Development Environment(이하 PDE)는 그 자신이 플러그인이면서 플러그인을 개발하는 환경을 제공한다. 우리가 일반적으로 다운받는 Eclipse SDK에 기본적으로 포함되어 있다. 이는 플러그인 개발의 편의를 도모하기 위해 플러그인의 정보를 담고 있는 plugin.xml을 효과적으로 편집할 수 있는 플러그인 설명서 편집기와 개발 중인 플러그인를 실행하고 디버깅할 수 있는 환경을 제공한다.


위의 그림은 여러 페이지로 구성되어 있는 플러그인 설명서 편집기이며 plugin.xml 파일을 쉽게 편집할 수 있도록 도와주는 역할을 한다. 이클립스 3.0에서 개발을 시작하였고 현재는 3.2 버전을 사용하고 있는데 플러그인의 구조가 적잖이 변경되었다. 이전에는 대부분의 정보가 plugin.xml에 저장되었던 것에 반하여 3.2 버전에서는 일부정보가 MANIFEST.MF 파일에 저장된다. 따라서 3.2 버전에서의 plugin.xml은 확장점과 확장에 관한 내용만 담고 있다.

각각의 페이지에 대해서 간략히 설명하자면,

Overview – 플러그인의 ID, 이름, 버전, 제작자등의 정보
Dependencies – 플러그인이 의존하고 있는 다른 플러그인의 집합
Runtime – 런타임에 client에게 export할 package의 집합
Extenstion – 확장정의
Extension Points – 확장점정의
Build – 빌드할때 포함해야할 파일등 플러그인 빌드 관련 설정
MANIFEST.MF – MANIFEST.MF 파일 텍스트 편집기
plugin.xml – plugin.xml 파일 텍스트 편집기
build.properties – build.properties 파일 텍스트 편집기  

정리하자면,

Overview, Dependencies, Runtime 페이지를 수정하면 MANIFEST.MF 파일이, Extenstion, Extenstion Points 페이지를 수정하면 plugin.xml 파일이, Build 페이지를 수정하면 build.properties 파일이 수정된다. 텍스트 편집기에서 파일을 직접 수정한 내용도 각 페이지의 폼에 바로 적용되어 상호보완적으로 편집할 수 있다.

플러그인의 실행을 이해하기 위해서는 host 워크벤치와 runtime 워크벤치의 개념을 이해해야한다. 먼저 host 워크벤치는 현재 PDE를 이용해 플러그인을 개발하고 있는 워크벤치를 의미한다. host 워크벤치에서 개발 중인 플러그인의 Run을 구성해 실행시키면 쉽게 말해서 이클립스가 하나 더 뜬다! 이 것이 바로 runtime 워크벤치다.


위의 그림에서는 PDE에서 vicode 플러그인의 Run을 구성하고 있다. 여기서 Plug-ins 탭으로 들어가보면 host 워크벤치와 runtime 워크벤치의 개념을 이해할 수 있다. 여기서 선택된 것은 runtime 워크벤치를 실행할 때 포함하는 플러그인을 의미한다. 다시 말하면 runtime 워크벤치는 host 워크벤치에 포함된 플러그인에 더하여 현재 개발 중인 플러그인을 추가한 워크벤치를 의미한다. (물론 개발하는 플러그인과 의존관계가 없는 플러그인은 제외하고 수행해도 무방하다)  

개념을 잡는 것에 도움을 드리기 위해 씌여지고 있는 글이기 때문에 실제 PDE를 사용하는 예제를 수행해보고 싶으신 분은 이클립스 메뉴의 Help > Help Contents를 클릭하시고 나오는 메뉴얼에서 Platform Plug-in Developer Guide > Simple plug-in example을 참조하시기 바랍니다.

1리터의 눈물


지난 주말 이틀동안 한번에 몰아보았던 일본 드라마 “1리터의 눈물”. 드라마 내용이 슬퍼서 1리터까지는 아니였지만 11화를 보면서 내내 울었던 것 같다. 이 드라마는 실제 인물을 바탕으로 하고 있어서 더 마음이 아팠다. 시간이 지날 수록 소뇌가 부서지면서 운동능력을 상실하여 점차 걸을 수도 말할 수도 없게 되는 ‘척수소뇌변성증’이라는 불치병을 앓게되는 15세의 소녀가 이 병을 받아들이고 현실을 인정하면서 끊임없이 삶의 의미를 찾고자 노력하는 과정을 그리고 있다. 주인공인 아야가 25세에 숨을 거두기까지 썼던 일기들이 모여 책으로 출판되었고 일본에서 많은 사랑을 받고 있다고 한다. 지금까지 보았던 어떤 드라마보다도 감동적이였고 많은 생각을 하게 해주었다. 15세의 아야가 의사에게서 자신의 병을 듣고 나서 이런 질문을 한다.

“왜 제가 병에 걸린거죠?”

그 누구도 이 질문에 대답할 수 없었다. 운명으로 받아들이라고 하기에는 너무 가혹하다. 공평하다고 믿고 싶은 이 세상에서 일어나는 이러한 불공평한 일들을 나는 어떻게 설명할 도리가 없다. 하지만 한가지는 분명한 것은 자신의 의지로 장애를 짊어지고 살아가는 사람은 없기에 우리는 서로 돕고 살아야 한다는 것. 건강하게 살아갈 수 있다는 것 만으로도 열심히 살아가야 할 의무가 있지 않을까?

확장점과 확장

플러그인이란 무엇인가? 이클립스에 어떤 기능을 제공하기 위한 것들의 집합이다. 기능을 제공하기 위해서 필요한 것에는 무엇이 있는가? 예를 들어 선택된 파일을 리눅스 콘솔에서 실행하는 기능을 제공한다고 가정하자. 이 때 필요한 것은 이클립스의 어떤 부분(확장점)을 통해 이 기능을 제공할 것인지에 대한 정보(파일을 선택하고 오른쪽 버튼을 눌렀을 때 나오는 팝업메뉴에서? 혹은 파일을 선택하고 툴바의 버튼을 눌러서?)와 이 기능의 이름이 화면에 어떻게 표시 될 것인지, 툴바에 버튼이 추가 된다면 icon 파일은 무엇을 사용할 것인지 등의 정보가 필요할 것 이다. 가장 중요한 것은 메뉴선택이나 툴바버튼이 눌렸을 때 수행되는 일이 무엇인지를 정의하는 것이다.

정리하자면, 이클립스에 기능을 제공하기 위한 플러그인이 가져야 할 정보는 텍스트 데이터와 자바 코드로 나누어 볼 수 있다. 우리는 이 사실로 부터 플러그인의 구조를 유추할 수 있다. 하나의 플러그인 프로젝트는 텍스트 데이터를 담고 있는 plugin.xml 파일과 자바소스코드들로 구성되어 있다. 다음의 다이어그램을 보고 좀 더 상세히 살펴보자.


왼쪽은 이클립스 워크벤치에 해당하는, 즉 이클립스 플랫폼에 기본적으로 포함되어 동작하는 플러그인이며 오른쪽은 우리가 개발하고 있는 플러그인 이라고 하자. 왼쪽의 플러그인은 다른 플러그인이 자신의 기능을 확장할 것을 고려하여 확장점(extenstion-point)를 plugin.xml에 정의하고 있다. 오른쪽의 플러그인은 이 확장점(popupMenus)을 이용하여 확장(extension)하고 있다. 쉽게 이야기 하면 왼쪽의 플러그인은 다른 플러그를 꽂을 수 있는 콘센트를 제공하고, 오른쪽 플러그인은 그 콘센트에 꽂을 수 있는 플러그가 되는 것이다!

확장을 할 때 필요한 정적인 정보는 오른쪽 플러그인의 plugin.xml 파일의 extenstion태그 아래 기술 될 것이며 팝업메뉴가 클릭되었을 때의 동작은 MyObjectAction 클래스에 정의한다. 확장점을 열어주는 입장(Workbench plug-in)에서는 확장하는 방법을 제공해주어야 한다. 즉 확장하는 플러그인(MyAction plug-in)에서 아무렇게나 MyObjectAction 클래스를 정의한다면 제대로 확장이 이루어질 수 없다. 확장점을  열어주는 플러그인에서는 IOjbectActionDelegate 인터페이스를 제공함으로써 확장하는 클래스가 이를 구현하여 자신에게 필요한 코드를 정의하도록 유도한다.

확장점을 열어준 플러그인은 자신을 확장한 플러그인에 대해서 처리해야할 책임을 갖는다. 현재 자신이 제작하고 있는 플러그인에서도 확장점을 얼마든지 정의할 수 있고 이를 다른 사람 혹은 자신이 제작하는 또 다른 플러그인에서 확장이 가능하다. 필자의 경우에는 다른 플러그인이 VICODE를 확장할 가능성을 염두해 두지 않았기 때문에 이클립스 워크벤치가 제공하는 기본 확장점을 이용하고 따로 확장점을 정의해본 경험이 없다.

     <extension
        point=”org.eclipse.ui.popupMenus“>
     <objectContribution
           adaptable=”false”
           id=”edu.kaist.vicode.consoleContribution”
           nameFilter=”*.console”
           objectClass=”org.eclipse.core.resources.IFile”>
        <action
              class=”edu.kaist.vicode.actions.RunConsoleProgramAction
              enablesFor=”1″
              icon=”icons/exec_obj.gif”
              id=”edu.kaist.vicode.actions.esterelSimulation”
              label=”Run Console Program”/>
     </objectContribution>

위의 예제는 실제 VICODE에서 확장자가 *.console인 파일을 선택하고 오른쪽 버튼을 눌렀을 때 나타나는 팝업메뉴에서 리눅스 console 프로그램을 수행하는 기능을 제공하기 위한 것이다. 자세한 내용은 나중에 팝업메뉴 확장하기에 대한 글에서 다루도록 하고 여기서는 확장점과 확장의 관점에서 살펴본다.

이 플러그인은 org.eclipse.ui.popupMenus 라는 확장점에 확장하고 있다. 이 확장점이 필요로 하는 정보가 obejctContribution 태그 아래로 정의되어 있는 것을 볼 수 있다. 정적인 정보는 이렇게 plugin.xml에 정의되고 behavior에 해당하는 내용은 확장점이 기대하는 behavior를 정의한 IOjbectActionDelegate 인터페이스를 구현한 RunConsoleProgramAction 클래스에 정의된다.

이클립스 플랫폼이 구동될 때 플러그인의 정적인 정보를 담고 있는 plugin.xml 파일을 읽어 확장점과 확장의 관계를 고려하여 화면의 UI를 구성한다. 그리고 효율성을 위해 자바 클래스는 그 것이 필요한 시점, 즉 action이라면 메뉴가 클릭되었을 때 객체가 생성되어 수행된다.