지금까지 정리한 EMS의 기본 목표는 시스템의 상태(CPU, memory, process)를 모니터링하는 것이다.
그리고, 지금 개발하고 있는 시스템은 'Java 1.5 version'을 사용하고 있다.
자바에서 시스템을 모니터링하는 API를 제공하고 있는지 찾아 보았다.

JMX (Java Management Extention)

JMX technology provides the tools for building distributed, Web-based, modular and dynamic solutions for managing and monitoring devices, applications, and service-driven networks. By design, this standard is suitable for adapting legacy systems, implementing new management and monitoring solutions, and plugging into those of the future.

Starting with the J2SE platform 5.0, JMX technology is included in the Java SE platform. Please see the JMX documentation for the J2SE 5.0 and Java SE 6 platforms. Previous versions of JMX technology are available here.

JMX라는 API가 제공된다고 한다. 로컬 시스템 뿐만 아니라, 원격 시스템에 대한 모니터링도 가능하다고 한다.
JDK를 설치하면 샘플 프로그램도 함께 제공된다고 하니 이보다 더 좋을 수는 없다.
(샘플 소스 위치는 JDK_HOME/demo/management 디렉토리)

다만 아쉬운 점은 JMX에 대한 한글 자료가 거의 없다는 것이다.
참고 도서를 찾아보니 외국 서적들 뿐이다.
우선, 선 썬 자바 홈페이지에서 제공되는 문서를 참조해 보았다.

Monitoring & Management for the java platform

Java Management Extension Examples

JMX technology tutorial

이제 샘플 프로그램을 실행해보고, 테스트해본 후에, 조금씩 기능을 확장해 보도록 하자.

JDK와 함께 설치되는 예제 중에서 JTop을 우선 실행해 보았다.
JTop의 기능은 자바 어플리케이션 내에 실행 중인 스레드(thread) 목록을 화면에 출력하고,
CPU 실행 시간(초 단위)과 실행 상태를 보여주는 프로그램이다.

샘플 프로그램과 함께 제공되는 README.txt 파일에 실행하는 방법이 설명되어 있다.

------------------------------------------------------------------------
JTop monitors the CPU usage of all threads in a remote application
which has remote management enabled.  JTop demonstrates the use of
the java.lang.management API to obtain the CPU consumption for each thread.

JTop first establishes a connection to a JMX agent in a remote
application with a JMX service URL:

   service:jmx:rmi:///jndi/rmi://<hostName>:<portNum>/jmxrmi

where <hostName> is the hostname and <portNum> is the port number
to which the JMX agent will be connected.

To run the demo
---------------

(1) Start the application with the JMX agent - here's an example of
    how the Java2D is started
  
      java -Dcom.sun.management.jmxremote.port=1090
           -Dcom.sun.management.jmxremote.ssl=false
           -Dcom.sun.management.jmxremote.authenticate=false
           -jar <JDK_HOME>/demo/jfc/Java2D/Java2Demo.jar

    This instruction uses the Sun's built-in support to enable a JMX agent
    with a JMX service URL as described above.
    You can programmatically start a JMX agent with the RMI connector
    using javax.management.remote API.  See the javadoc and examples for
    javax.management.remote API for details.

(2) Run JTop on a different machine:

      java -jar <JDK_HOME>/demo/management/JTop/JTop.jar <hostname>:1090

    where <hostname> is where the Java2Demo.jar runs in step (1).

These instructions assume that this installation's version of the java
command is in your path.  If it isn't, then you should either
specify the complete path to the java command or update your
PATH environment variable as described in the installation
instructions for the Java SDK.

------------------------------------------------------------------------

위 내용을 아주 간략히 번역해 보자면, 다음과 같다.

JTop은 java.lang.management API를 이용해
원격 제어가 허용된 원격 어플리케이션의 스레드 실행 상태를 모니터링할 수 있다.

데모를 실행하기 위해서는 먼저 JMX agent를 포함한 어플리케이션을 실행해야 하며,
JTop 프로그램을 별도의 머신(machine)에서 실행하면 된다.

그래서, 윈도우에서 batch 파일을 2개 만들고, 각기 다른 명령 창(command window)를
실행해 보았다. (시키는대로 별도의 머신에서 꼭 실행할 필요는 없다.)

배치 파일의 내용은 다음과 같다.

runDemo.bat
-------------------------------
java -Dcom.sun.management.jmxremote.port=1090
 -Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
-jar "%JAVA_HOME%\demo\jfc\Java2D\Java2Demo.jar" 

runTop.bat
-------------------------------
java -jar "%JAVA_HOME%/demo/management/JTop/JTop.jar" localhost:1090

JTop의 실행 화면은 다음과 같다.

EMS란 무엇인가?

네이버에 검색을 해보면, '국제특급우편'이라고 나온다. 그럼, 우체국 관리 시스템이란 말인가?
설마 그럴리가....?

그래서 구글에 검색을 해보았다.

Emergency Manaement System, Environment Management Sytstem....

예전에는 이렇지 않았다.
인터넷이 너무 발달하다보니, 이제는 IT 문서 찾기가 더 어려워졌다.
사실, 지금 보다 옛날이 개발하기 더 좋았다.
기술 문서 찾기도 좋았고, 알아야 할 것도 많지 않았다. 하지만...

안철수 소장님은 혈혈단신 바어러스 사태로부터 대한민국을 구원하는 V3를 만들고, 기업을 차리지 않았던가?
겨우 10년 차이일 뿐인데, 이제는 IT 바닥에서 세상을 구하는 '단 한명의 영웅' 따위는 존재할 수 없게 되었다.
약간은 서글프다는.... 그래도 배운게 도둑질이니 열심히 할 밖에...
타인의 타고난 재능을 뛰어넘을 수 있는 방법은 오로지 열정과 경험 밖에 없지 않은가?

아무리 머리가 좋고 손이 빠른 개발자라도 처음보는 버그 앞에서는 속수무책일 수 밖에 없다.
하지만, 10년이고 20년이고 버그랑 씨름한 사람이라면 비록 코딩 속도가 느리더라도
더 빨리 버그를 잡을 수 있다. 아니, 아예 버그를 만들지도 않는다. 그런게 늙은 개발자들이 살아남는 능력이다.

얘기가 삼천포로 빠져 버렸다. 하여튼, 계속 구글에서 EMS라는 단어를 찾아보니 단서가 나온다.

"Enterprise Management System"

아니, 기업 전체를 관리한다는 말인가? 내가 너무 큰 고래를 잡으려고 하는 건 아닌가?
에이허브 선장처럼 한쪽 다리를 잘리는게 아닐까?

어쨋든 EMS가 무언지를 설명하는 자료를 찾기는 찾았다.

http://www.sun.com/blueprints/0402/ems1.pdf

그럼 이제 EMS 조사 끝.

왜? 겨우 문서 하나 찾았을 뿐인데? 최종 목표가 바로 현실적인 목표가 되어야 할 필요는 없다.
언젠가 사업 아이템으로 써먹을 필요가 있을 때 다시 꺼내보면 되는 것이다.

이런 자료가 필요한 이유는 프로젝트 수행 중에 느닷없이, 멍청한 간부가 대체 EMS가 뭐냐고
물을 때, 옛다 이거나 물고 있으라고 던져줄 뼈다귀 인거다.
(다만, 번역해서 제출하라고 하면 대략 낭패 이겠지만....)

일단, 살은 버리고 뼈만 추리자~
멋지고, 환상적이고, 완벽하고, 풍부한 기능... 뭐 이런 생각은 버려야 한다.
누구나 프로그램 개발을 처음할 때는 무언가 멋진 것을 만들고 싶어한다.
하지만 그렇기 때문에 실패하는 법이다.

에디슨이 처음 만든 축음기를 인터넷에서 찾아보라. 얼마나 볼품 없는 것인지?
하지만, 결국 그가 만든 발명품들 중에 지금까지 쓰이는 게 얼마나 많은가...
남들로부터 '이게 뭐야'라는 말을 들어도 상관없다는 뻔뻔한 생각을 가져야 한다...!

첫걸음은 단순하게... 그러니, EMS라는 거창한 단어를 썼지만 처음 목표하는 기능은 단순하게 정리하자.

"시스템이 정상적으로 운영되는지 파악할 수 있어야 한다."

좀 더 구체적으로 정의해 보자. 우리가 PC를 사용하다가, 어플리케이션이 멈추었는지 어떻게 판단하는가?
control-alt-delete 키를 눌러서 '작업 관리자'를 실행한다. 그리고, 메모리를 얼마나 사용하는지,
어떤 프로그램이 떠 있으며, CPU는 얼마나 사용중인지 파악한다. 이 정도 정보라면 대략적인
상황을 파악할 수 있다. 솔직히 말해서 이보다 더 상세한 정보가 필요하겠는가?

그러면, 목표는 쉽게 정할 수 있다. 시스템의 사용 중인 메모리와 CPU 상태를 파악하면 되는 것이다.
나아가서 스레드(thread)들이 몇개나 실행되고 있는지 알 수 있으면 좋을 것이다.

목표가 정해졌는데, 다음은 어떻게 구현할 것인가? 하는 문제다.
지금 프로젝트는 '자바'언어를 이용해서 개발하고 있다.
그렇다면, 자바 자체가 해답을 제공하고 있지는 않을까?

EMS를 만들어 달라는 요청을 받았다. 그런데, 문제는 솔직히 EMS가 무언지 모른다.
그래서 뭘 해달라는 거냐고 되물었더니, 시스템이 정상동작하는지 실시간으로 모니터링할 수 있는 기능을 만들면 된다고 한다.

아주 간단히 만들자면 일정 시간 마다, 운영 시스템에 요청을 보내고 정상적으로 응답이 오는지 확인하면 된다.
하지만, 이래서는 시스템에 어느 정도의 부하가 발생하고 얼마나 메모리를 사용하고 있는지 알 수가 없다.
아주 조잡한 수준으로 만들 수야 있겠지만, 과연 이래서야 국내 굴지의 기업에서 수긍할 것인지가 의문이다.
(게다가 개발자의 자존심이 허락하지 않는 문제가 더 크다)

그렇다고 제대로 하자면 돈이 든다. Janniffer 같은 모니터링 솔루션을 한달 동안 대여하는데 대략 수백만원이 든다.
아예 솔루션을 사려고 하면 수천만원이 드는데, 책정된 프로젝트 예산으로는 답이 안나온다.
파일럿 프로젝트가 성공하고, 제품화 하고, 서비스 개통하고나서 돈이 벌리면 그 때 가서
제대로 된 EMS 솔루션을 도입하는 것이 타당한 계획이라고 할 수 있다.

자고로 돈도 못 벌어 놓고 쓸 생각만 해서는 안되는 것이다. 나아가 나는 개발자가 아닌가?
문제를 해결하는 역할이 바로 개발자가 하는 일이다.

며칠 전, 이외수 선생의 새로운 책이 나와서 마님께 사드렸더니 그 책에 이런 내용이 있더란다.
(참고로 책 제목이 '하악하악'이라는.... 이외수 선생 센스는 여전히 본좌급...)

2차대전이 한창일 때, 독일의 U보트 때문에 고심하던 미군의 브레인들이 모여서 U보트를 막아낼 방법을 고심했단다.
그런데, 그 중 한명이 기발한 아이디어를 냈더란다.

"바닷물을 끓게 해서 독일군을 삶아 버리는건 어떨까?"

그래서 어떻게 끓일 수  있냐고 되물었더니, 이렇게 답변하더란다.

"난 몰라. 기획자이니까, 그 방법은 개발자들이 알아서 생각해야지..."

그래 난, 개발자다. 그러니, EMS를 만들어 보자.

무턱대고 프로그래밍 개발 툴을 띄우고, 코드를 작성해서는 EMS를 만들 수 없다.
어떤 일이건 간에 계획이 우선이다. 어제 케이블 TV를 시청하다가 이런 문구를 보게 되었다.

아이디어를 생각해 내는 것은 쉽다. 문제는 그것을 실현하는 것이다. (제프 베조스, 아마존 창립자)

첫번째, EMS가 무엇인지 부터 알아내자.

두번째, 내가 만들고자 하는 EMS에 어떤 기능을 넣을 것인가를 기획하자.
초기 기획 단계에서 기획자의 자문을 구해서는 안된다. 바닷물 전체를 끓이라고 할지도 모르니까....
아니면, 웹에서 EMS라는 단어로 검색한 후에 세상에 존재하는 모든 EMS 솔루션의 기능을
모두 구현해 달라고 할지도 모른다. 뭐... 양심적인 사람을 만나서 일부만 구현해도 좋다고 할 수도 있다.
하지만, 그 일부라는게 뻔하지 않은가? 수십명이 수년동안 개발해온 것들 말이다.

세번째, 기능을 구현하기 위해 필요한 기술들을 파악하자. 그리고, 샘플과 매뉴얼을 찾자.
세상 모든 기술을 내 손으로 만들겠다고 하는 의지은 오만하거나 혹은 무지한 생각에서 비롯되는 것이다.
뉴튼 선생도 자신을 거인의 어깨에 올라앉은 소년으로 비유하지 않았던가?

네번째, 아주 간단한 샘플 프로그램을 만들자.
처음부터 거대한 그림을 그리려고 시도하면 스케치를 완성하기도 전에 지쳐 버린다.
사람의 의지라는 것도 생각보다 나약하다.
하루 이틀 정도의 작업을 했는데도 아무런 성과가 없다면 금새 질려 버리고 마는 것이다.
아주 작은 것이라도 성과를 얻을 수 있어야 한다.
잘 만든 게임을 보면, 아무리 작은 행동이라도 적절한 보상이 따른다. 그래야 게이머가 게임을 계속하게 된다.
개발도 결국 게임과 다를 게 없다. 인생도, 비지니스도 마찬가지 인거다.

다섯번째, 실체를 다듬어 가자.
중간에 어느 정도 가능성이 보인다고 해서 갑자가 욕심을 부리면 안된다.
적당한 시간과 노력을 들이는 것만으로 완성할 수 있는 수준의 목표로 제한해야 한다.

여섯번째, 다음을 기획하자.
첫술에 배부를 수 없다. 다음 번에는 어떤 기능을 확장할지를 생각해보자.
인생은 하루하루가 어찌될지 모르는 일이다. 갑자기 프로젝트가 엎어질 수도 있다.
그러니까, 적당한 선에서 일단 마무리하고 차후를 기약하는 것이 현명한 태도다.
게다가, EMS 말고도 돈 벌어야 할 것도 많고, 다른 일의 우선순위가 높아질 수도 있지 않은가?

IT 분야 뿐만 아니라 세상만사를 돌아보면 늘 새로운 것이 나타난다.
그리고, 사람들은 (특히 우리나라 사람들은...) 오래된 것보다 뭔가 새로운 것을 더욱 선호한다.

한국을 IT 기술의 테스트 베드라고 부르는 이유 중에 하나가
우리나라 만큼 자주 휴대폰을 바꾸고 최신 모델을 선호하는 국민이 드물기 때문이다.
휴대폰 뿐 아니라 가전제품이나, 소프트웨어라던가, 여러가지 제도 면에서도
변화와 리스크를 별로 두려워하지 않는 점은 세계 최강이 아닐까?

하여간 그래서 IT 개발자들 그리고, IT 기업에 투자하는 사람들, 새로운 아이템을 히트 시키려고
무언가를 구상하는 사람들은 늘 기존에 없던 무언가를 만들어 사람들의 열광과 찬사를 얻고 싶어한다.
(그리고 결국 떼 돈을 벌고 싶은거다...)

그런데 세상에 없던 무언가를 만들어 내는 발상은 어떤 과정을 거치는 것일까?
전설처럼 내려오는 뉴튼의 이야기처럼 사과가 떨어지는 순간
불현듯 중력 이론을 떠오르는 천재적인 두뇌를 가졌다거나,
혹은 불운한 수학 천재 엘런 튜링처럼 한 세기를 앞서는 사고능력을 가진
사람들만이 눈부신 진보를 만들어낼 수 있는 것일까?
그렇다면 보통 사람들이나 보통 엔지니어들은 결국 세상을 변모시킬 능력따위는 어차피 없기
때문에 그저 일상적인 업무를 통해 부여받는 최소한의 벌이에 만족해야만 하는 것인가....

간결히 말하자면, 혁신은 꼭 컬럼부스적인 발상의 전환이 필요한 것인가?
실상은 전혀 그렇지 않다. 사람들의 일상 생활과 결합되지 못하는 혁신이나 변화는 결국 외면당할 뿐이다.
결론부터 말하자면, '새롭지만 결코 새롭지 않은 것'이 바로 성공의 요인이다.

모든 것을 뒤집어 버리는 발상은 사람들에게 오히려 거부감을 불러오기 마련이다.
성공의 목표는 대중들에게 어필하고 더 많은 사람들이 새로운 제안을 받아들이는 것이다.
그러기 위해서는 대중의 다수를 차지하는 보수적인 (혹은 변화를 거부하는) 사람들을 설득해야 한다.

어떤 신제품이나 신기술이건 초기에는 소수의 얼리어답터들이 받아들이기 시작한다.
(김치냉장고라던가, 휴대폰의 전파, 싸이월드 열풍, 블로그의 보편화 과정을 떠올려보자)
그러다가, 새로운 것의 효용성이나 매력이 얼리어답터들의 노력과 입소문 전파,
기사화 등을 통해 점차 더 넓은 사용자 층을 확보하기 마련이다.
그런데 더 넓은 사용자 층 (보수적인 계층)이 새로운 것을 받아들일 때는 이미 그것(새로운 무엇)은
새로운 것이 아니라 이미 일반적인 것이 되었고, 남들이 다 받아들인 것이기 때문에 당연히
받아들여야 하는 것이기 때문에 어쩔 수 없이(?) 뒤쳐지지 않기 위해 받아들이는 것이다.

이런 이야기를 압축해보자. 처음에 얼리어답터들을 끌어들이기 위해서는 무언가 '새로와'야 한다.
하지만, 대중적인 친화력을 가지기 위해서는 '지나치게 새롭지 않아야' 한다.
지나치게 새로운 것은 결국 보수적인 대중들이 거부하게 될 것이기 때문이다.

IT 분야에서는 늘 새로운 기술들이 나타난다.
개발자들과 IT 종사자들은 늘 새로운 것을 배워야 한다는 스트레스에 시달린다.
혹은 새로운 유행이나 트렌드를 스스로 만들어내지 못한다는 자괴감으로 대해서 강박관념에 시달리기도 한다.

하지만, 문제의 해법은 의외의 장소에 있기 마련이다. 낡은 것이 좋은 것이다.
새로운 무언가를 만들기 위해서는 기존의 기술을 연구해야 한다.

C언어는 30년이 넘게 대부분의 주류 언어에 영향을 미치고 있다.
네트워킹 시스템에서 TCP/IP 프로토콜이 사라지겠는가? 단지, 웹으로 그리고 모바일로 확장될 뿐이다.
SNS(Social Networking Service)는 하이텔에서 싸이월드로 외형은 바뀌었지만 그 근본은 똑같다.
1대1 대화를 위한 ICQ 서비스도 MSN이나 Nate로 변화할 지언정 사라지지 않을 것이다.

과거의 기술에서 배우자, 그리고 그 포장을 어떻게 변화시킬 수 있을 것인지를 고민하자.

어제 보스가 회사의 R&D 전략을 관계자들에게 메일로 보냈는데,
그 내용이 모두 이미 나와 있거나, 여러 사람들을 만나면서 논의했던 것들이었다.
결국 누구나 비슷한 생각을 한다. 그리고, 그들 중에서 가장 보수적인 대중들을 사로잡는 사람들이 성공한다.

나는 그래서 여전히 C언어와 TCP/IP와 멀티스레딩 기법을 계속 공부하고 있다.
진정한 금맥은 발 밑에 있는 법이다. 너무 뻔한가? 그런데 뻔하기 때문에 잊고 사는 법이다.

개발자는 프로그램만 잘 만들어야 한다.
그렇다면, 프로그램을 잘 만드는 비법은 무얼까?

프로그램을 잘 만드려면 말을 잘해야 한다.
프로그래밍이라는 것은 컴퓨터에게 개발자의 의지를 전달하는 것이다.
컴퓨터라는 복잡한 장난감이 개발자의 의도대로 움직이도록 만드는 것이다.
프로그래밍 언어도 또 하나의 언어이기 때문이다.

언어는 사고를 만들고, 사고는 사상을 만들어낸다.
그리고 사상이 시스템을 구축하는 것이다.
아주 단순한 어휘만을 구사하는 사람은 복잡한 사상체계나 사회구조를 만들 수는 없다.

말을 배우기 위해서는 모방이라는 과정을 거쳐야 한다.
나보다 더 나은 사람들의 사고와 사상을 모방하는 과정을 거쳐서 자신만의 체계를 구축하게 되는 것이다.

남들이 만들어낸 프로그램 코드 몇 줄을 따라하는 것만으로는
단연코 복잡한 사고 체계를 이해할 수 없다.

다른 개발자들의 생각을 받아들이기 위해서는 그 사람의 감성까지도 이해해야 한다.
스트럿츠라던가 스프링 같은 유명한 프레임워크들은 단순한 코드의 집대성이 아니다.
그 내부에는 설계자 혹은 아키텍트들의 감정까지도 녹아 있다.

그런 부분들을 이해할 수 없다면, 타인의 코드를 복사기 처럼 따라할 수는 있을 지언정
자신만의 시스템을 구축할 수 없게 된다.

감정을 읽는 법은 어떻게 배울 수 있는가?
소설과 논픽션, 그리고 다양한 사람들의 저술을 읽어볼 필요가 있다.

타인의 감정을 해석해야 하는 또 하나의 이유는 그것이 바로 동기부여가 되기 때문이다.
자신보다 앞선 사람들이 쌓아올린 위대한 업적을 마주하고 느끼게 되는 감동을 통해
우리는 더 높고 위대한 자아를 만들고자 하는 성취 욕구를 느낄 수 있기 때문이다.

감동을 느끼지 못하는 사람은 무력함과 권태의 노예가 되고 말 뿐이다.