주말에 난데없이 몇 년 전에 술자리에서 들었던 말이 떠올랐다. 나를 이상주의자라고 했던 말이다. 당시 상황에 따르면 현실에 맞지 않는 꿈을 꾸는 사람으로 들려 반박했던 기억이 있다. 스스로는 주어진 조건에 맞춰서 답을 낸다고 자부했기 때문이다. 하지만, 그 사람 지적이 맞고, 술기운에 하릴없이 변명을 늘어놓았다는 사실을 몇 년이 지나서야 깨달았다. 사회를 잘 안다는 사람들이 말하는 존재 이유로는 행복은커녕 불편한 마음에 견디기가 어렵다. 더 오래전으로 돌아가 대학원 후배가 '형은 욕심이 많다.' 지적한 일이 있다. 당시에도 반박했다. 많은 것을 소유하고 싶은 마음은 없었다고 확신하고 있었으니까. 어떤 면에서 욕심이 많다는 사실을 인정하지 않을 수 없다. 나는 분명 주어진 현실에 만족하지 못한다. 다만, 가슴 뛰는 일을 하..

3년 전에 이런 일이 있었다고 합니다. (기사 원문: 노대통령, 원전 해외진출 추진 지시 via http://twitter.com/jrogue) 최고위층이니만큼 대통령의 직무 추진 방식은 추상적입니다. 그런데 이번 UAE 원전 수주 기사를 보면 이명박 대통령이 김연아 선수라도 된 듯 보도합니다. 수주 가능성이 큰 상황에서 순발력 있게(?) 나서 그간 수년 아니 어쩌면 수십 년을 노력했을 많은 사람의 공을 이렇게 가로채는 모습은 대통령의 격에 맞지 않은 모습입니다. (청계천 복원, 대운하, 4대강 사업이나 이번 일에 직접 나서는 모습을 보면 건설회사 사장의 틀에 갇힌 듯하다.) 오늘 국민 여러분에게 기쁜 소식을 전하고자 이 자리에 섰습니다. 오늘 역사상 최대 규모의 원전을 수주하게 되어서 저는 개인적으로도 감명스럽습니다만 국민의 한 사람으로서 매우 자랑스럽게 생각..

딱히 찾아보려던 의도는 없었는데 트윗을 통해 알게 된 기사 'Simplified Enterprise OSGi in WAS 7'에서 아래 그림만 조금 살펴보고 글을 쓱 훑고 말려는데 Apache Aries란 생소한 프로젝트 이름이 눈에 띄었다. 제안단계인 아리스의 목표는 다음과 같이 이야기하는데, 뭉뚱그려 생각하면 Java EE 에서 사용 가능했던 기술을 OSGi 모듈 환경으로 포팅하는 의도라 느껴진다. We will initially focus on the Blueprint container and extend this with enterprise features such as support for container managed JPA and container managed transactions. Another initial focus area will be the contribution of code to support the assembly of isolated, multi-bundle applications that can be deployed as a unit. 얼마 전 SpringSource 주도로 이클립스 RT에 제안했던 제미니가 떠올랐다. 목표나 범위를 읽어보면 차이가 있지만 적어도 지향하는 방향은 같아 보인다. 그..

오픈소스 ESB 제작으로 유명한 MuleSoft가 보낸 메일에서 Tcat Server란 표현이 있어서 갸우뚱했다. 톰캣(Tomcat)을 줄여 부르는 말인가 싶었는데, 링크를 타고 확인해보니 마치 SpringSource tc Server처럼 톰캣에 감시(monitoring)와 관리 기능을 내장하여 기업용으로 판매하는 제품이다. 제품에 대한 관심보다 오픈소스를 베껴서 자사 제품을 만들지 않고 함께 사용하며 시너지를 내는 제품 다수를 만드는 모습이 좋아 보인다. 예전에 이모부가 휴대전화 악세서리 사업을 했는데, 국내에선 새로운 설비를 구매하여 국내 경쟁사를 죽이려 들지만, 당시 경쟁국인 대만에선 조합 형태로 설비를 사들이고 공유한 후에 경쟁해 부러웠다고 한다. 데자뷔를 보는 느낌이다.

Toby형이 글을 자주 올린다. 구체적인 기술을 다루는 이야기라 댓글이 많지 않았는데, 모처럼 viz란 분이 논쟁을 부르는 댓글을 올렸다. 그랬더니 Toby형 뿐 아니라 entworks님까지 몰려 왔다. 흥미롭게 이어지던 글은 아쉽게도 노이즈로 바뀌었다. frankly speaking ID를 쓰는 분이 어구가 담고 있는 뉘앙스까지 담아낸 듯하다. franklyspeaking 이란 분의 글을 보면 대단한 경력이 있어 자랑하고픈 듯하다. 그렇지만, 보편적인 문제 제기를 이해하지 못한다. 한 수 위라는 듯한 말투인데 그랬다면 Toby 형 주장의 오류를 드러낼 능력이 있어야 한다. 현장 경험을 중언부언 올린 댓글은 길기만 할 뿐이다. 기억에 남는 내용을 굳이 꼽으면 바로 이 부분이다. JavaEE는 서버사이드 소프트웨어에서 풀어야될 문제들을 대부분 해결해놓은건데 제가 우습게 볼 이유가 없습니다. ..

개발자와 아키텍트 사의 불협화음의 본질 The failure often occurs because architecture is about breadth and development is about depth. 그리고 해결책 To ensure shared understanding, we have to architect “all the way down.” Architects cannot worry only about services and developers cannot worry only about code. There is a huge middle ground that each must also focus on 아키텍처의 중요한 특성 architecture is a kind of “shared understanding" 아키텍처 수립/구현에도 기민한 접근이 필요한 이유에 대한 Temporal Aspect Instead, the emphasis is on proving the architectural decisions that are made as soon as possible, while also embracing architectural change throughout the development lifecycle. 부가 설명 On the other hand, traditional architecture involves spending significant time early in the project defining the architecture. Once the vision has been established, teams tend to resist architectural change throughout the ..