윤경구의 Log on Java

살아남은 국내 솔루션 업체들 오러클이 선을 인수했다. 선의 최고 히트작인 Java 언어를 인수한 것이다. Java Enterprise Edition(Java EE)의 Reference Implementation 역할을 했던 Glassfish 의 본격적인 commercial edition을 만들겠다고 한다. 분산 데이터 그리드 솔루션인 Coherence 를 결합하는 방안도 검토 중이다. Java EE 솔루션의 글로벌 경쟁은 Glassfish와 WebLogic을 인수한 오러클 외에는 IBM WebSphere와 open source 기반으로 Redhat이 인수한 JBoss 정도이다. 보통 JBoss가 경쟁하는 시장은 조금 다르다고 볼 수 있으므로 commercial Java application server 시장에서는 손쉽게 담합도 가능할 정도로 정리가 되어버렸다. 국내는 Tmax JEUS 가 시장 점유율 1위를 몇년째 유지하고 있지만, 하루하루가 쉽지 않다. 엄청난 투자를 쏟아붓고 있는 global vendor와의 경쟁에서 핵심 기능 중심으로 기술 정체성을 확립해간다는 것은 숨막히는 혈투와 같다. 홈의 잇점을 최대한 활용해서 버텨가야 한다. 한동안 위기에 빠져 투자를 본격화할 수 없었던 Sun이 자바 스튜어드 역할을 할 때와는 비교할 수 없다. 물론 핵심 영역에서의 기술 경쟁력이나 국내 영업력, R&D까지 바로 이어지는 기술지원 등 JEUS의 시장 경쟁력은 여전하고, 실제로는 많이 사용되지 않는 복잡한 기술 트렌드의 유혹에 의해 고객이 구매 대체 결정을 하지는 않을 것이다. 하지만, Java EE가 다루는 영역이 급속하게 넓어지고 있음은 누구나 동의할 수 있을 것이다. 어떤 형태로든 JEUS의 공격적인 시장 대응이 시장 점유율 유지에 필요할 것이다. Tmax는 국내에서 Tibero 라는 RDBMS 솔루션을 가지고 오러클에 또다른 도전을 하고 있다. 오러클의 모든 기능을 다 갖추진 못했으나 성능과 안정성 그리고 호환성 측면에서 조금씩

스포츠 경기를 보다 보면 지고 있던 선수가 엄청난 집중력과 투혼으로 듀스 혹은 동점을 만들어낸다. 그 여세를 몰아서 이기는 경우도 있지만, 사실은 험난한 노력 끝에 대등한 상황을 만든 다음에 어이없는 실수로 와르르 무너지는 경우가 더 많은 듯하다. 작년 초였던가 테니스 황제 로저 페더러가 왼손 천재 라파엘 나달을 맞아, 예술같은 경기 능력, 흠잡을 데 없는 완벽한 플레이를 보였지만, 이기는 경기는 쉽게 이기면서도 상대방의 서비스 게임을 듀스 혹은 어드밴티지까지는 계속 가면서도 결국 게임을 빼앗지는 못하고 긴 시간 끝에 세트 2:3으로 역전패하는 것을 본 기억이 있다. 아마 이 경기가 세계 랭킹 1위에서 2위로 물러나는 시점이었을 것이다. 지금은 나달이 부상을 당한 후 슬럼프에 빠져 페더러가 다시 1위로 복귀한 것으로 기억한다. 야구든 배구든 단체 경기에서도 이러한 상황을 많이 만나게 된다. 야구 경기에서 초반에 대량 실점하여 많은 점수차로 뒤지다가 중반에 힘겹게 동점까지 쫓아간다. 하지만, 어이없는 실수로 바로 그 다음 회에 결승점을 내어주고는 더 이상 추격하지 못한다. 이러한 상황, 마치 데자뷰 같은 느낌... 고비를 넘긴다는 것은 이러한 상황의 심리적인 도전을 담담하게 이겨내는 것이다. 어떤 일이든 매우 힘든 과정을 거쳐 고비에 다다랐다면, 고비를 채 넘기 전에 이른 안도감에 기인한 심리적인 무장 해제와 또, "왜 이렇게까지?"라는 자문에 이른다. 지리산 천왕봉을 등정하다가 굳이 정상까지 가는 이유를 스스로 물어본다면 무엇이라 답할 것인가. 이미 먼 길 떠나왔다면 등정한 후에 내려가는 길을 찾아보는 게 맞지 않겠는가. 시간이 얼마 남지 않을수록 마음속 회의와 갈등이 뒤엉킨다. 마치 인생이란 산을 오르다가 왜 오르고 있냐고 묻는 것처럼... 길에 대한 판단은 한치 앞을 보지 못하는 눈보라 속에서 할 수 있는 것이 아니다. 길이 보이지 않는다고 눈보라 속에서 가만히 서 있을 수는 없다. 가던 길, 목표했던 방향으로

Software 특히 Java 언어를 사용하는 Software 개발 조직에 몸담고 있지만, 마흔을 훌쩍 넘긴 나이에 이런 글을 쓰는 것이 적합한지 의심되는데 특히 국내 SW 환경을 고려한다면 몹시 우스꽝스럽다. 이젠 개발팀장도 아니고 개발실장도 아니고 그위의 관리자이지만, 아직 완전히 제품 코드로부터 역할을 분리하지 못했고, 이러한 시간이 많이 걸리고 책임 소재가 불분명한 문제를 해결할 전문 인력을 두고 있지 않기 때문에 결국 직접 하는 경우가 생긴다. 이것은 미흡한 관리 능력의 결과라고 봐도 좋겠다. 개인적으로는 이러한 일이 전혀 나쁘지 않다. 즐거운 Software Life의 하나일 뿐이다. 관리자가 이러한 삽질을 직접 하는 것이 관리 체계를 무너뜨리는 것 아니냐고 묻겠지만... oh, give me a break.. 나중에 교육교재 만드는 데 도움이 될까해서 하는 관리 행위의 하나라고 봐주기 바람~~ ㅠ_ㅠ;; perm gen 과 class leak Permanent Generation 은 young과 old를 구분하는 Generational Collector 방식인 Sun (now, Oracle)의 HotSpot JVM에서 Old generation 중 한 영역이다. lifetime이 길다고 판단된 object들을 old generation으로 옮겨서 빈번한 gc의 대상이 되지 않도록 하는 것이 generational collector의 기본 아이디어인데 permanent generation은 old 중에서도 거의 gc 대상이 될 일이 없다고 생각되는 object들을 딴 영역에서 관리하겠다는 아이디어의 산물이다. HotSpot JVM의 Perm Area 에는 주로 자바의 클래스 객체들이나 문자열 상수 풀에 속한 String 객체들이 위치한다. 메모리 leak의 대상이 되는 것은 string constants 보다는 주로 class 객체들이다. (class 객체는 주로 객체의 타입을 나타내는 클래스나 인터페이스를 표현하는 객

R&D에 계속 몸을 담고 있지만, R과 D가 크게 다르다는 점은 별로 주목받지 못하는 것 같다. 연구 조직과 개발 조직을 완전히 분리하는 경우도 있겠지만, 내가 몸담은 조직은 개발 조직에서 연구를 함께 진행하는 경우이다. 연구와 개발은 다르다 Software 제품의 개발과 기술 심화를 위한 연구는 결과적으로는 제품이라는 형태로 가치가 외화된다는 점에서는 같은 것이라고 볼 수 있겠지만, 개발과 연구를 하나의 영역으로 간주한다면 효율과 성과 측면에서 어려움에 부닥칠 것이다. 연구를 개발의 일부로만 바라보고 제품 개발 프로세스에 직접적으로 포함시켜버린다면 연구의 깊이나 창의성은 매우 약해질 것이다. 연구가 제품의 직접적인 이슈를 해결해주기 위한 보완적 성격으로만 사용될 것이고, 장기적인 제품 비전과 질적 깊이를 이루지 못할 것이다. 반대로 연구 중심의 프로세스를 셋업하고 개발을 부차적인 프로세스로 간주한다면 Software 제품의 직접적인 품질을 결정하는 코드 품질이나 모듈화 등 기본 방법론적 측면이 약화될 것이고, 연구 성과를 제품의 일부로 흡수하기까지 너무 많은 시간을 허비하면서 제품은 그 시간 한계 속에서 시장으로부터 벗어나게 될 것이다. 연구는 흔히 투자 개념으로 바라본다. 보통 투자는 상대적으로 장기적인 관점의 수익을 기대하는 부분이지만, 시장 요구 혹은 트렌드와 무관하지는 않다. 개별 제품 개발 프로세스는 보통 진척률과 이슈, Feature Set 등을 중심으로 관리하게 되는데 연구는 핵심 기술 영역 확보 혹은 차별적인 Key Feature Set을 가지기 위한 특별한 투자로 바라볼 수 있다. 문제는 연구는 제품 개발에 비해 시간 제약이나 성과에 대한 예측이 더 어렵다는 데 있다. 제품 개발의 경우 Risk를 최소화하기 위해 여러 가지 기법들이 연구되어 있고, 마일스톤별 Feature를 축소하는 등 시장에 대한 시간 압박에 적응하기 위한 노력들이 정형화될 수 있지만, 연구의 경우는 그러한 제약들을 매우 느슨하게 적용하는