언제인지는 모르겠다. 한 컨퍼런스의 부스에서 나눠주는 경품을 받기 위해 메일 주소를 적어 준 것이 화근이었다. 그 때부터 지금까지 퀘스트 소프트웨어 코리아에서 날아오는 홍보 메일은 끊이질 않았다. 몇 번이고 수신 거부 폼을 입력하고 담당자에게 메일을 보내 보았지만 수신 거부 처리는 결코 이루어지지 않았다.

오늘도 퀘스트 소프트웨어 코리아의 프로모션 메일이 내 메일함에 와 있다. 수신 거부 폼은 마치 동작하는 것처럼 보이지만 사실은 자바스크립트로 버튼 클릭 시 바로 창이 닫히도록 작성되어 있다. 수신 거부 수단을 제공하지 않는 명백한 불법 스팸으로 보인다. 혹시 거부 폼만 보여주고 거부 처리는 해 주지 않아도 적법한 것인가?

이렇게 수신인을 기만해가면서까지 홍보 메일을 보내야 하는 절박한 사정이 있는 것인지 궁금했던 때도 있다. 하지만 알게 뭔가. 결국 퀘스트 소프트웨어에서 오는 모든 메일은 필터링되고, 퀘스트 소프트웨어는 많은 사람들에게 ‘최하’ 나 ‘악덕’, ‘저질’ 쯤으로 기억될텐데.

Update: 2009년 9월 9일 새 마켓팅 담당자님께서 적극적으로 처리해 주신다고 메일 및 답글을 보내 오셨습니다. 상황이 나아지기를 기대해 보아도 좋을 듯 합니다.

발표일 새벽까지 준비를 하다 보니 공식 사이트에 올라온 발표 자료와는 내용이 좀 다르게 되었습니다. 여기를 클릭해 실제 발표에서 쓰였던 최신 자료를 받아 보시길 바랍니다. 녹화된 동영상을 입수하면 다시 한 번 알려드리도록 하겠습니다.

다시 한 번 참석해 주신 여러분들께 감사의 말씀을 드리고 싶네요.

도안구 기자님 께서 작성하신 Bloter.net 의 인터뷰 기사입니다. 문장을 매끄럽게 다듬고, 어색하거나 오해의 소지가 있는 부분은 수정했음을 알립니다.

——

그의 명함에는 ‘수석 소프트웨어 엔지니어 (Principal Software Engineer)’라는 직함이 있다. 그는 현재 오픈 소스 미들웨어인 레드 햇의 제이보스 리모팅 프로젝트 의 리드로 활동하고 있는 전업 오픈 소스 개발자다. 그는 경기도 부천 집에서 재택 근무를 하면서 전세계 흩어져 있는 제이보스 개발팀과 협업 프로젝트를 진행하고 있다.

그는 “전지구적으로 협업을 진행하고 있답니다”라고 말했다. 전형적인 오픈 소스 회사 다운 개발 방식이라고 덧붙였다.

그는 NHN에 인수된 검색 서비스 회사인 첫눈에서 근무하다 NHN에 잠시 몸을 담갔다가 레드 햇 본사에서 함께 일하고 싶다는 메일을 받고 2007년 9월 레드 햇에 입사했다. 현재 제이보스 리모팅 과 네티, Log2Log, APIviz 프로젝트 리드와 JBoss 메시징 컨트리뷰터로 활동하고 있다.

언급된 대로 주로 네트워크 애플리케이션 프레임워크와 관련 프로토콜 개발 분야에서 주로 활동하고 있다. 네트워크 애플리케이션들을 손쉽게 개발할 수 있도록 활동해 온 것.

그의 이름은 이희승.

그를 간략히 소개하기 위해 블로그에 올라온 자기 소개서를 살~짝 인용한다.

“이희승은 다양한 오픈 소스 소프트웨어 프로젝트에 참여하고 있는 소프트웨어 엔지니어입니다. 그는 대량 SMS (Short Message Service) 게이트웨이, 경량 ESB (Enterprise Service Bus), RPC 애플리케이션 서버와 같은 자바 기반 고성능 네트워크 애플리케이션을 4년 이상 개발해 왔습니다.”

그간의 ‘오픈 소스를 말한다’ 인터뷰는 국내 오픈 소스 사업과 관련한 정부 관계자와 국내외 오픈 소스 진영 경영진들이 대상이었는데 반해 이번 인터뷰는 오픈 소스를 만들어 내는 창조자인 ‘개발자’가 주인공이다. 전업 오픈 소스 개발자이자 전세계 최대 오픈 소스 기업에 소속된 오픈 소스 개발자라는 점이 그와의 만남을 추진한 이유다.

또 가장 큰 이유는 그가 오픈 소스 프로젝트를 만들어 내고 해외 커뮤티케이션에도 성공했고, 아파치 소프트웨어 재단에서 진행한 관련 프로젝트도 매끄럽게 끝낸 장본인이었기 때문이다. 생산과 소통을 통한 커뮤니티의 활성화, 그 후 전세계 최대 오픈 소스 기업으로의 이직 등은 국내 개발자는 물론 이제 국내 기반 오픈 소스 프로젝트를 진행하려는 기업들에게 많은 것들을 시사할 것으로 판단했다.

그는 인터뷰 요청에 흔쾌히 응하고, “모처럼 부천 집을 떠나 서울 삼성동의 레드 햇코리아로 출근했습니다”라고 웃으면서 기자를 맞아주었다.

이희승씨에 대해 알기 위해서는 그가 진행한 오픈 소스 프로젝트를 잠깐 살펴봐야 한다. 그는 네티 프로젝트라는 오픈 소스를 공개하면서 오픈 소스 분야라는 강호에 이름을 알리기 시작했다.

네티 한국어 사용자 그룹 을 방문하면 관련 프로젝트에 대한 설명이 나온다. 잠시 인용을 한다면 ‘네티 프로젝트는 고성능과 고확장성 프로토콜 서버와 클라이언트를 신속하게 개발할 수 있도록 해 주는 비동기와 이벤트 드리븐 네트워크 애플리케이션 프레임워크과 관련 프로토콜 구현, 도구 모음을 제공하고자 하는 노력입니다’라는 설명을 볼 수 있다.

기자에게는 좀 버거운 이야기임을 실토하지 않을 수 없다. 이희승 씨는 “통신사가 인프라를 구축하면 이런 망에 다양한 애플리케이션이 탑재되는데 그런 네트워크 애플리케이션을 개발하기 쉽게 만들어 낼 수 있도록 개발 환경과 도구, 프로토콜 등을 제공합니다”라고 설명했다.

우리가 일상적으로 보내고 받는 단문메시지시스템 같은 것도 이런 프레임워크를 통해서 개발된다. 국내에는 이동통신사와 제휴해 대용량 SMS 서비스를 제공해주는 곳이 많은데, 이런 회사들에서 많이 활용한다.

처음엔 국내 커뮤니티 사이트에 소스를 오픈하고 그 다음에 영문 사이트를 만들었는데 해외 사용자들이 하나 둘 관심을 가지면서 관련 커뮤니티가 인기가 많아졌다. 그 후 전세계 최대 오픈 소스 커뮤니티인 아파치 소프트웨어 재단 (Apache Software Foundation) 에서 함께 프로젝트를 진행해 보자는 제의를 받게 됐고, 관련 프로젝트는 ‘미나‘라는 이름으로 새롭게 태어났다.

그 후 앞서 밝힌대로 첫눈에서 일하다가 NHN에 합류한 후 레드 햇의 러브콜을 받고 제이보스 개발팀으로 자리를 옮겼다. 미나 프로젝트에서는 손을 떼고 전업 오픈 소스 개발자로 일하면서 틈틈이 네티 프로젝트도 다시 시작했다. 그는 “자신이 구현하고 싶었던 것들을 마음껏 개발하고 싶었습니다”라고 그 이유를 밝혔다.

그는 소스를 왜 오픈했느냐는 질문에 대해 “PC통신 하이텔의 게임제작동아리에서 활동했습니다. 서로가 개발한 지식을 공개하면 상호 작용을 통해 더 큰 지식을 얻을 수 있었습니다. 퍼주는 것이 아니라 공유를 하면 서로가 발전할 수 있고, 저도 발전하게 되더라구요. 그 때의 경험을 그대로 이행했을 뿐입니다”라고 밝혔다.

“커뮤니티 활성화 방법은…음… 뭐랄까… 딱히 .. 방법은… 없는데요… 마법 같은 건데요..”라면서 웃던 이희승씨와의 대화 속으로 들어가 보자.

네티 프로젝트는 어떻게 해서 탄생된 건가요?

대학 졸업 후 아레오 커뮤니케이션즈 에 입사해서 대용량 SMS 게이트웨이를 개발했었습니다. 메시징 전송 대행 서비스에 사용되는 기술입니다. 당시엔 SK텔레콤, 신세기통신, LG텔레콤, KTF, 한솔PCS 등 5개 통신사가 있었는데요. 각 통신사마다 서로 다른 프로토콜을 사용하고 있었죠. 통신사와 회선 계약을 맺고 다양한 SMS를 보내야 했습니다.

개인 메시지부터 신용카드 결제 정보까지 수많은 메시지들을 처리하면서 고성능 시스템을 물론 메시지의 유실이 발생하지 않도록 하는 기술을 배웠고, 서비스 중단없이 시스템을 업그레이드하는 기술들도 익혔습니다. 당시 자바 (Java) 가 다이내믹 업데이트도 가능하고 신속한 개발도 가능해 이를 적극 활용했습니다.

그러다가 네트워크 애플리케이션 개발 프레임워크와 개발 도구들을 만들으면 좋겠다고 생각해서 틈틈이 개발해서 국내 커뮤니티 사이트에 올리고, 또 더서버사이드닷컴 (www.theseverside.com) 이라는 당시 자바 관련 최고 커뮤니티 사이트에도 올렸습니다.

당시 프로젝트 이름이 네티 (Netty) 였습니다.

네티의 뜻은 뭔가요?

네트워크 애플리케이션 프레임워크와 도구 쪽이라서 네트워크의 ‘Net’에 좀 친근한 이미지를 풍기기 위해 ‘ty’를 붙여 네티라고 했습니다.

공개한다고 모두 주목받지는 못할텐데요?

국내 커뮤니티 사이트는 좀 그랬죠. 단방향이었습니다. 커뮤니케이션이 잘 이뤄지지 않았어요. 상호작용이 많아야 하는데 아쉬웠죠. 그래도 자바서비스넷 (현 제니퍼소프트) 이원영 대표가 관련 회원들에게 메일링을 하면서 조회수나 방문자가 늘었습니다. 많은 도움을 받은 것이죠.

또 영문 사이트를 운영하다보니 해외에서도 피드백이 있더라구요. 초기엔 퀄리티가 조금 떨어졌지만 그래도 그 중 좋은 콤포넌트가 있어서 그런지 반응은 좋았습니다. 네티가 주목을 받은 이유는 2000년대 초기에는 네트워크 애플리케이션 프레임워크가 없었기 때문이에요. 상용 제품들도 없었던 시기거든요. 그래서 더 주목을 받은 지 모르겠어요.

질문에 답변을 해주다보니 점점 커졌고, 또 앞서 말씀드린대로 대용량 SMS 게이트웨이를 개발하면서 다양하게 배우다보니 하나 둘 좋은 기능들도 붙고 그래서 개발자들에게 인기가 있었던 것 같습니다. 국내 통신 환경이 다른 나라에 비해 조금 앞서 있었기 때문이기도 했을 것 같네요.

아무리 하찮은 질문이라도 무시하지 않고, 질문해 주셔서 감사하다는 말부터 시작해서 지속적으로 피드백을 해주다 보니까 점점 커졌습니다. 시간이 들고 이상한 질문들도 많지만 관심을 가지고 있기 때문에 질문을 하는 거잖아요. 그러니까 성심성의껏 대답을 해줘야죠.

아파치 소프트웨어 재단에선 연락이 온 것도 그 이유 때문이었나요?

말씀드린대로 당시 관련 프레임워크가 많지 않았는데, 이미 실운영환경에 적용된 프레임워크를 제공하다보니 네티 커뮤니티가 커졌고, 자연스럽게 아파치 소프트웨어 재단에서도 관심을 가진 것 같습니다. 아파치 소프트웨어 재단엔 아파치 인큐베이팅 프로그램이 있습니다. 최고의 오픈 소스 커뮤니티다 보니 다양한 오픈 소스 프로젝트들을 스크린하고 필요할 경우 지원을 하는 것이죠. 아파치 소프트웨어 재단 지원 아래 아파치 디렉터리 프로젝트의 서브 프로젝트로 진행됐습니다.

네티 프로젝트가 미나 프로젝트로 이름을 바꿨습니다. 특별한 이유가 있었나요?

아파치 소프트웨어 재단은 상당히 오래된 오픈 소스 커뮤니티입니다. 내부에서 처음부터 진행된 프로젝트가 아닐 경우 제 프로젝트처럼 외부에서 소스를 가져올 때는 지적재산권을 면밀히 검토합니다. 그런데 시간이 너무 오래 걸린다고 하더라구요. 그래서 아예 이름을 바꿔서 처음부터 다시 작성하자고 결론이 났습니다. 당시 네티는 2.0까지 나왔었는데요. 아파치 브랜드를 이용하면 더 많은 사람들과 함께 할 수 있고 해서 저도 흔쾌히 참여하게 됐습니다. 물론 네티가 모태가 됐죠.

이희승씨가 주목을 더 받게 된 이유가 아파치 디렉터리 프로젝트의 서브 프로젝트였던 미나가 TLP (Top Level Project) 로 승급됐고, PMC (Project Management Committee) 의장으로 선출되면서인데요. 아파치 소프트웨어 재단 출신이 아닌 사람이 PMC 의장에 선출되기는 힘들다고 하던데요?

나중에 고참 아파치 멤버가 아피치소프트웨어 재단 의장도 상당히 이례적이지만 아주 자연스러운 일었다고 전해줬습니다. 설명을 드리자면 좀 긴데 아파치 소프트웨어 재단에 참여하는 구성원들의 역할을 좀 살펴봐야 됩니다.

일반적으로 관심을 갖는 이들이 있고, 커미터라고 해서 소스의 저장소에 접근해서 개발에 참여를 합니다. 멤버는 재단의 이사회 구성원을 뽑고 재단의 내부 정보를 열람할 수 있습니다. PMC (프로젝트 관리 위원회) 는 각자 담당한 프로젝트의 운영을 맡습니다. 어떤 아파치 프로젝트가 새로 생길 때 초대 PMC 의장은 커미터가 아닌 멤버가 하는 경우가
대부분입니다. 그런데 미나 프로젝트의 경우에는 당시에 커미터였던 제가 초대 PMC 의장을 맡게 되어 화제가 된 것으로 알고 있습니다. 물론 나중에는 다른 멤버의 추천을 받아 어엿한 재단의 멤버가 되었지만요.

초기엔 디렉토리 프로젝트의 서브 프로젝트였습니다. 디렉토리 프로젝트는 오픈 소스 기반 LDAP 서버 개발 프로젝트인데요, 그 프로토콜이 굉장히 복잡해요. 그런 복잡한 프로토콜을 이용해 빠르고, 고성능으로 개발할 필요가 있다고 해서 톱레벨 프로젝트로 승격이 된 것이죠.

전 멤버가 아니었는데 핵심적인 활동을 했다고 판단을 해주신 거죠.

최근에도 계속 관련 프로젝트에서 일하고 계신가요?

지금은 미나 프로젝트에 참여하고 있지 않습니다. 글로벌 프로젝트가 되면 개인적으로 가능을 추가하고 싶었던 것들은 좀 미뤄지게 되거든요. 여려 사람이 공통으로 고민하는 것부터 시작해야 하니까요. 물론 지금의 미나도 상당 부분 제 의견이 많이 반영이 됐죠. 어떤이는 견해차이나 기술의 조화 같은 것 때문에 저를 독재자로 볼 수도 있었겠지만요.

그렇지만 무난히 프로젝트가 진행됐으니 다행스러운 일이죠. 그렇지만 개인적으로 미나에 대한 로드맵이 있었어요. 하면서 느낀 미나의 구조적인 결합 등이 보이고, 소프트웨어는 지속적으로 성장을 해야 되잖아요. 미나를 능가하는 또 다른, 내가 원하는 기술적인 완성도를 구현하고 싶은 욕구가 있었어요. 그래서 지금은 제이보스에 사이트를 만들어 놓고 개인 프로젝트로 하고 있죠. 소스포지닷넷도 오픈 소스 진영에 호스팅을 해주지만 제이보스도 마찬가지예요.

제가 그쪽에 합류해서가 아니라 좋은 프로젝트라면 모두 호스팅을 해주고 누구나 참여할 수 있게 해줘요. 오히려 소프포지닷넷보다 더 좋은 것 같아요. 이렇게 네티 3 프로젝트가 진행되고 있는 것이죠.

미나는 국내에서도 많이 사용되고 있나요?

게임 서버라던가 플래시미디어스트리밍, 포스 단말기와 서버, 채팅 서버 등에서 사용하고 있다는 이야기는 들었습니다. (편집자 주: 이희승 씨는 몇군데 이야기를 했지만 함께 동석한 한국 레드 햇 홍보 담당자는 확인되지 않은 고객사 정보라면서 기사화되면 안된다고 말했다. 이럴 땐 홍보담당자가 정말 밉다.)

그런데 소스를 왜 공개하셨나요?

제가 초등학교 1학년 때 처음 컴퓨터를 접했습니다. 부모님 졸라서 샀죠. (당시 87년) 2학년 때부터 컴퓨터 학원을 다니면서 언어도 배우고, 게임도 개발해 봤어요. 초등학교 5학년 (91년도) 때 정보처리기능사도 땄습니다. (기자와 홍보담당자는 헉! 소리를 내면서 뭐 이런 인간이 다 있어하는 표정으로 이희승씨를 쳐다봤고, 그는 그냥 웃었다.) 컴퓨터잡지도 보면서 하나씩 배워나가다가 게임소프트웨어 개발에 관심을 갖게 됐어요.

게임 개발이라는 게 고급기술과 낮은 수준의 기술을 모두 배워야 하는 분야거든요. 당시 PC 통신 하이텔에 게임제작동호회가 있었는데요. 게임 라이브러리를 공유하는 장이었어요. 당시엔 다이렉트엑스도 없었던 시기였거든요. (편집자 주: 한국 위키피디아의 다이렉트엑스 설명을 보면 다이렉트엑스는 1995년 9월 30일에 처음 공개됐다. DirectX: 멀티미디어, 특히 게임 프로그래밍에서 마이크로소프트 플랫폼에서 작업을 위한 API의 집합이다. 다이렉트엑스는 OpenGL, 단순 다이렉트미디어 계층 (SDL) 과 경쟁 관계에 있으며 마이크로소프트 윈도, 세가 드림캐스트, 마이크로소프트 엑스박스 및 엑스박스 360을 위한 컴퓨터 · 비디오 게임 개발에 널리 쓰인다.)

게임라이브러리를 올리면서 자료를 공유하고, 서로 협동하면 더 큰 것을 얻을 수 있다는 걸 체험하게 됐죠. 또 지금은 게임 개발 회사에 계신 김학규 사장님도 동호회 활동에서 알게 됐습니다. 라이브러리 리뷰도 해주시고, 조언도 하고, 좋은 책도 권해주셨어요. 남이 올린 좋은 라이브러리를 보면서 공부도 더 하게 되고, 서로의 지식을 나누다보니까 더 큰 지식이 되어서 돌아오더라구요.

그 때 느꼈죠. 지식은 나누면 큰 힘이 된다는 걸요. 나중에 보니까 오픈 소스 활동들이 많더라구요. 자연스럽게 제가 만들 걸 공개한 거죠.

아니 그럼 게임 개발자로 안나서시고, 좀 엉뚱한 프레임워크 개발자로 나섰나요? 이력을 보니까 첫눈에 근무하다 회사가 NHN에 인수됐던데, 그냥 일하시지 왜 나오셨어요? NHN은 한국 개발자들이 많이 선호하는 직장이잖아요.

저는 게임 개발보다는 게임 같은 걸 만들 수 있는 프레임워크 개발에 더 관심이 많았어요. 사용하기 편하게 만들어보고 싶다는 생각이 들었죠. 일반 프로그램도 사용자가 배우기 쉽고, 사용하기 편해야 하잖아요. 그래야 널리 퍼지니까요. 인프라 애플리케이션도 똑같아요. 같은 법칙이 적용되죠. 이 분야가 저하고 더 맞는 거 같습니다.

NHN은 물론 좋은 회사죠. 근데 당시에 레드 햇에서 연락이 왔어요. 같이 일해보자구요. 제가 오픈 소스 프로젝트를 해 봤지만 전업으로 한 경우는 대학원 잠깐 다닐 때였어요. 미나 프로젝트를 보고 같이 사업을 해보자고 연락이 온 사람이 있었는데 그 때 당시에 정말 기능들을 많이 업그레이드 했죠. 근데 잘 안됐고, 학계도 잘 안맞아서 그만 두고 직장 생활을 했죠.

NHN에서 일하고 있는데 세계 최대 오픈 소스 기업에서 일하자는 제의가 왔으니 얼마나 좋았겠어요. 그래서 합류하게 된 것이죠. 요즘 NHN이 오픈 소스 분야에 많은 투자를 단행하고 있는데, 이곳에 합류하지 않았으면 아마 저도 그쪽에서 같이 일하고 있을지도 모르죠. 전업 오픈 소스 개발자로 생활할 수 있어서 정말 좋습니다.

전세계인들과 소통을 하려면 영어는 물론 기본이 돼야 할 텐데요. 국내 회사나 개발자들의 오픈 소스 기여도가 낮은 이유도 언어 문제가 좀 있기 때문이라는 지적들이 있었는데요.

지금은 해외 기술 유입 속도가 많이 빨라졌죠. 책도 3개월~6개월 정도면 번역돼서 나오구요. 번역의 질도 높아졌습니다. 그런데 제가 컴퓨터를 접할 때는 그렇지 않았어요. 정말 번역도 형편없었던 시절이 있었습니다. 정보 유입도 잘 안됐고, 자바 신기술도 원서나 영문 자료가 훨씬 많았죠. 당연히 영어로 보다 보니 친숙해 진 거죠.

지금 생각해보면 정보를 습득하는 것은 영어가 다는 아니라고 봐요. 다만 누구와 상호 작용할 것인가 생각해 봐야죠. 그래서 영어가 중요하죠. 습득한 정보를 영어로 표현해야 되니까요. 오픈 소스에 기여하고 있는 곳들 대부분이 영어로 소통을 하는 곳이예요. 공식 커뮤니티도 대부분 영어권이구요. 문제와 해결 방법을 설명해줘야 하고 정당성을 설득해야 되거든요.

커뮤니티 기반이 커지면 애초에 이걸 진행한 사람 이외에 많은 이들이 참여해 서로 응답을 해줘요. 당연히 영어가 중요하죠. 전세계 사람들이 참여를 하니까요. 이 때문에 영어를 사용하지 않는 국가가 오픈 소스 커뮤니티를 잘 이끌어 가기가 힘든 것 같아요. 그리고 아파치 소프트웨어 재단 프로젝트를 해보니까 거기는 메일링으로 질문을 해야 하고, 두번 이상은 안돼요. 자꾸 질문을 해봐야 소용이 없어요.

이런 매커니즘을 알아야 하거든요. 오픈 소스 프로젝트는 비영리목적이 대부분이기 때문에 개인적으로 계속 귀찮게 하거나 보채면 안되거든요. 본의 아니게 실수를 하게되는 것이죠. 자꾸 괴리가 생기게 되기도 해요.

또 아파치 소프트웨어 재단 같은 경우는 커뮤니티의 단일성을 상당히 중요하게 생각해요. 그러니까 국가별로 따로 커뮤니티를 만드는 것을 반기지 않아요. 하지만 제이보스의 경우에는 그런 제약이 없기 때문에 네티 한국어 사용자 그룹을 개설하고 지속적으로 소통을 해 오고 있어요.

또, 아주 간단하지만 뭐랄까 무시할 수 없는 것인데요. 소프트웨어를 개발을 할 때 메소드 같은 구성요소의 이름을 부르기 쉽고 간결하게 지어야 해요. 근데 모국어가 영어가 아닐 경우 힘들죠. 버튼을 하나 만들 때도 확인이냐 알았음이냐 가지고 생각을 해봐야잖아요. 직관적인 이름 짓기가 쉽지 않은 것 같아요.

프로그램 짜는 일은 재미있으신가요? 또 해외와 커뮤니케이션을 하려면 개발자들이 기본적으로 코딩을 잘 해야 할텐데요. 그런 부분은 어떻게 준비를 하셨죠?

그렇죠. 취미가 프래그래밍이거든요. 일을 하다가 프로그램밍하고 또 일하다가 프로그램 짜고. 그러다가 앞서 말씀드린 대로 미나 프로젝트를 하면서 대학원에 1년 좀 다녔는데 풀 타임으로 일할 기회가 생겨서 정말 전문적으로 열심히 짰습니다. 그 후 회사 생활하면서 미나도 하고 회사일도 또 하고. 그랬죠.

자바와 관련돼서 자바에서 자주 사용하는 패턴이 있고, 효율적인 애플리케이션 개발을 위한 베스트 프랙티스가 나와 있었는데 그걸을 많이 따랐죠. 자료들이 많으니까요. 큰 어려움은 없었던 것 같아요. 자바의 경우 SDK (Software Development Kit) 가 잘 정립돼 있었거든요. 썬이 정한 자바 표준도 따랐구요. JDK (Java Development Kit) 을 사용하는데도 무리가 없었죠. 표준을 따르고 패턴을 사용하면 별 문제는 없을 거라고 봅니다.

오픈 소스 개발자는 명성을 얻을 수 있잖아요. 저도 물론 그런 걸 얻고 싶었죠. 열심히 하다보면 얻을 수 있지 않을까 하는 생각을 했었죠. 기술적으로 공유를 하다보면 저보다 더 높은 경지의 개발자를 만나게 되구요. 지금 제이보스의 좋은 개발자들을 만나게 된 것도 이런 과정들이 쌓여서 된 것이기 때문에 즐겁죠.

국내에서도 오픈 소스 전문 업체들이 등장하고 있습니다. 모두들 커뮤니티 활성화에 대해 고민하고 있는데요. 나름의 비법을 좀 전수해주신다면?

커뮤니티 키우기가 쉽지 않을 겁니다. 아까 말씀드린대로 국내는 일방향인 경우가 많거든요. 그대로 말씀을 드려야 하는데, 뭐랄까, 일종의 마법 같은 기술이에요.

마법이요?

뭐라고 딱히 꼬집어서 말할 수 없는 그런 것인데요. 저는 운이 아주 좋은 경우였죠. 네티도 성공했고, 미나도 성공했으니까요. 미나의 경우는 서브 프로젝트들도 생겨났거든요. 최근 진행하고 있는 네티3 프로젝트도 트래픽이나 글을 읽는 빈도 등 모든 것이 좋아지고 있거든요. 얼마나 많이 다가가느냐의 문제인 것 같아요. 어디에 적용되고 있고, 어떤 건 안되는지, 어떻게 실행되는지 계속 설명을 해줘야 해요. 말이 안되는 질문에도 친절히 답해줘야돼요.

뭔가 물었을 때 딱 그에 대한 답만 해서는 안되요. 그 이상의 것을 줘야 되는거죠. 그래야 다시 찾아오고 참여를 하거든요.

그와의 인터뷰는 이렇게 끝이 났다. 다음을 기약하면서. 공식 인터뷰가 끝나고 그는 네티 3에 대해서 아주 흥미로운 이야기를 전해주었다. 조만간 구글이 공개한 개방형 모바일 운영체제인 안드로이드 (Android) 를 지원할 예정이라는 것이다. 그렇게 되면 안드로이드를 이용해 힘겹게 개발하지 않고도 신속하고 고성능의 안드로이드 지원 네트워크 애플리케이션을 개발할 수 있다고 한다. 오픈 소스의 매력과 힘을 보여주는 것 같았다.

사족) 그와의 인터뷰는 지난 2월 28일 (토), 자바개발자들의 축제인 JCO 행사 이전에 열렸다. 그는 이번 행사에서 ‘자바 네트워킹 기초에서 응용까지’라는 네티 관련 핸즈온 랩을 마련했는데, 사전 예약 시스템 오픈 당일 50명의 사전 예약이 모두 차고, 행사 당일에도 강의가 성황리에 끝난 것으로 알려졌다.

PuTTYcyg를 이용한 “Bash Here” 컨텍스트 메뉴
PuTTY is an excellent terminal software. That’s why Mark Edgar added Cygwin support there. Consequently, it is very natural to replace crappy “Open Command Prompt Here“ with PuTTYcyg, right? Then, let’s go ahead!
PuTTY는 환상적인 터미널 소프트웨어입니다. 그래서 Mark Edgar가 거기에 Cygwin 지원을 추가한 것이겠지요. 그렇다면 논리적으로 허접한 “Open Command Prompt Here“를 PuTTYcyg로 대체하는 것은 아주 자연스러운 일이겠죠? 그렇다면 어서 바꿔버립시다!

1. Install the ‘chere‘ package in the Cygwin setup.
2. Download the latest version of PuTTYcyg and extract all files into C:Cygwinbin directory.
3. Download bash-here.zip.
4. Extract bash-here.reg file from the zip file, and merge it into your system registry by double-clicking it.

1. PuTTYcyg 최신 버전을 받아 C:Cygwinbin 디렉토리에 압축을 풀어 넣습니다.
2. Cygwin 설치 프로그램에서 ‘chere‘ 패키지를 설치합니다.
3. bash-here.zip을 다운로드합니다.
4. 받은 ZIP 파일에서 bash-here.reg 파일을 풀고, 더블클릭해 시스템 레지스트리에 합칩니다.

All done. Good bye, Command Prompt!
다 됐습니다. 명령행 프롬프트여 안녕!

이제 진짜로 2009년이다. (1월 1일부터 어제까지는 놀았다.)

2008년을 돌이켜 보자면 딱히 한 일도 없이 흘러간 한 해라고 생각한다. 기억력을 되살려 가장 많은 시간을 할애한 일들을 나열하려 하니, 운영체제 설치 및 네트워크 재구성과 같은 시간 죽이기 딱 좋은 일들이 먼저 생각나는 것을 보면 빈 말이 절대 아니다. 이런 저런 설정을 시도해 보다가 최근에는 전기세의 압박에 못이겨 전력 소모를 최소화할 수 있도록 재구성했다. 한 번 재구성하는 데 일 주일은 족히 걸리니 들인 시간에 비해 얻는 이득이 클 지는 의문이다.

그 외에 메일 클라이언트들을 이것 저것 시험해 보면서 20여만 통의 메일을 어떻게 하면 효율적으로 관리할 수 있을까 고민하며 지새웠던 나날도 있다. 다행히 얼마 전 최종의 해법을 찾아낸 것이 다행이라면 다행이다. 하지만 지금까지 들인 시간은 돌아오지 않는다. Mutt 의 수 많은 설정 옵션들을 들여다봐야 할 정도로 인생은 길지 않다던 직장 동료 Max 의 말이 떠올라 마음에 작은 후회를 남긴다. (이 친구도 대량의 메일 관리 때문에 속을 썩이고 있는 것 같던데 잘 하고 있는지 궁금하다.)

딱 하나 기술적으로 의미가 있었던 일을 이야기하자면 Netty 프로젝트를 성공적으로 진행한 것을 언급할 수 있겠다. 지금까지 재단에서 작성해왔던 것을 새로운 라이선스 하에서 처음부터 전부 다시 작성한다는 것은 귀찮으면서도 부담스러운 일이었다. 그럼에도 불구하고 이렇게 프로젝트를 정상 궤도에 올리고 기존의 내 작업물을 능가하는 무언가를 내놓았다는 사실은 스스로도 자랑스럽다.

그런데 딱히 한 일도 없이 흘러간 작년에도 꽤나 만족스러운 일이 하나 있으니, 그것은 바로 건강이다. 비록 운동 부족으로 인해 체력은 바닥을 달리지만, 순수히 건강 측면에서는 정신적으로나 육체적으로나 편안한 기분을 지속적으로 유지할 수 있었다. 이러한 편안함은 세상 일을 좀 더 여유롭게, 그리고 좀 더 객관에 가깝게 바라볼 수 있게 해 주었다. 작년의 성취를 기초로 삼아 올해에는 더 튼튼하고 건강한 모습이 되어야 겠다.

아무리 뿌듯한 일을 애써 나열해도 채울 길 없는 구멍 투성이의 작년이기에 올해의 바람은 작은 듯 크다. 몸과 마음 튼튼히 하고, 읽지 않은 책 다 읽고, 시스템 구성 작작 하고 일 좀 제대로 하는 것, 그게 내 올해의 바람이다. 다들 SMART 를 이야기하는 시대에 이런 모호한 목표로 제대로 된 한 해를 보낼 수 있을 지 모르겠지만, 일단 느낌이 좋다.

Saga Korea 의 저가형 인티 앰프인 SA-20PSD 를 사용한 지도 수 개월의 시간이 흘렀고 추천하는 의미에서 작성한 제품 소개 및 리뷰입니다.

Active Speaker vs. Passive Speaker + Integrated Amplifier

일반적으로 PC 에 연결하는 스피커들은 액티브 스피커라 하여, 내부에 자체적으로 앰프를 달고 있다. 액티브 스피커를 구분하는 간단한 방법은 전력을 공급받기 위한 전원 코드가 달려 있는지 여부를 확인하는 것이다. (물론 USB 포트로부터 전원을 공급받는 미니 스피커도 있다.)

그와는 다르게 음성 신호의 증폭 과정을 거치지 않고 출력하는 스피커를 패시브 스피커라 부르는데, 보통 인티 앰프 (Integrated Amplifier) 라 불리는 별도 전원을 공급받는 증폭 장치를 통해 증폭된 음성 신호를 전달받는다.

요즘에는 괜찮은 음질의 액티브 스피커도 발매되고 있지만 하이파이는 전통적으로 패시브 스피커의 영역이었다. 그렇다 보니 패시브 스피커 쪽이 더 나은 음악적 경험을 위한 선택의 폭이 훨씬 넓은 것이 사실이고, 또 그렇다 보니 인티 앰프도 구입해야 할 필요가 생기게 된다.

패시브 스피커 자체의 가격도 만만치 않지만, 패시브 스피커 가격 못지 않은 인티 앰프의 가격이 훨씬 부담스러운 것이 사실이다. 현재 내가 거실에 두고 사용하고 있는 마란츠의 PM6010OSE 의 가격만 하여도 30만원이 넘고, 마란츠의 최저가 모델인 PM4001 의 가격도 20만원을 넘는다. PC USB Audio DAC 와 연결할 적당한 패시브 북셸프 스피커의 가격이 20만원대임을 감안할 때 배보다 배꼽이 크다고 밖에 할 수 없다.

SA-20PSD 소개 및 장점

비용을 절감하기 위해 자작 앰프를 만들어 볼 수도 있겠지만 납땜 한 번 제대로 해 본 적 없는 나에게 그럴 시간과 용기는 쉽게 나지 않았다. 그러던 와중에 발견한 것이 바로 Saga Korea 의 저가형 인티 앰프인 SA-20PSD 이다.

무엇보다도 10만원대 초반의 저렴한 가격과 기존의 인티 앰프와는 비교도 할 수 없을 정도로 작은 사이즈가 매력적이다. 크기가 작아서 모니터 바로 밑에 놓고 사용할 수 있다. 보통의 인티앰프를 샀다면 공간상의 제약으로 절대 책상 위에 올려놓지 못했을텐데, 볼륨 노브를 가까운 곳에 둘 수 있다는 것은 큰 즐거움이 아닐 수 없다.

노이즈 면에서도 대단히 만족스럽다. 비록 출력은 다소 약하지만 적당한 효율의 패시브 스피커로 자기 방을 채울 정도의 능력은 충분한데다가 최고 출력시의 노이즈도 대단히 적은 편이어서, SSD 와 팬리스 파워 가 장착된 수냉식 시스템 을 사용하고 있음에도 불구하고 심야에도 화이트 노이즈가 쉽게 느껴지지 않는다.

SA-20PSD 단점

물론 SA-20PSD 가 장점만 갖고 있는 것은 아니다. SA-20PSD 의 가장 큰 단점은 빌드 퀄리티가 떨어진다는 점이다. 우선 각종 노브가 싼티가 철철 흘러서, 심지어 노브를 잡아당기면 노브가 빠져 버리고 가번 저항이 드러날 지경이다. 다행이 다시 꼽으면 원래대로 들어가지만 실소를 금치 못할 부분이 아닐 수 없다.

그뿐만이 아니다. 전면 패널이 미묘하게 잘 맞지 않아 특정 노브가 꽉 끼어 노브를 돌릴 때 쇳소리가 나고 가변 저항에 불필요한 힘이 가해져 스피커로 기분나쁜 잡음을 내보내기도 한다. 보통은 볼륨 노브만 사용하기 때문에 전면 패널을 재조립해 볼륨 노브가 매끈하게 돌아가도록 손을 봐주면 해결이 되지만 제조시에 조금 더 신경 써 주었더라면 좋지 않았을까 한다.

그 외에도 전원 LED 가 지나치게 밝아서 앰프 분해 후 선을 구부려 빛이 직접적으로 눈에 닿지 않도록 해야 했다. 분해하면서 자연스럽게 내부 기판을 구경하게 되었는데, PC 메인보드의 깔끔한 PCB 와는 사뭇 다른 모습에 깜짝 놀랐다. 물론 기기의 성능과는 직접적으로 관련이 없는 부분이지만, 그 투박한 모습은 요즘의 전자 기기에서 찾아보기 힘들 정도의 것이었다.

결론 및 앞으로의 기대

Saga Korea 의 SA-20PSD 는 놀라운 가격대 성능비를 가진 인티 앰프로, 협소한 공간과 낮은 예산범위 내에서 데스크탑 PC 기반의 하이파이 사운드 시스템을 구성하고자 하는 사람에게 강력 추천할만 하다.

나는 현재 SA-20PSD 에 StyleAudio 의 CARAT-UD1 USB Audio DAC 와 AudioPro 사의 Image 12 컴팩트 북셸프 스피커를 연결해 일상적으로 음악을 즐기고 있는데, 음질 면에서 거실에서 쓰고 있는 바이와이어링한 마란츠 PM6010OSE 앰프와 모던쇼트 MS-914 톨보이 스피커와 비교했을 때 뒤떨어지는 부분이 특별히 없다고 생각한다. 40만원도 채 되지 않는 시스템 (SA-20PSD 11만원, USB Audio DAC 6만원, AudioPro Image 12 19만원) 으로 양질의 사운드를 경험할 수 있다니 놀라울 따름이다.

제품의 빌드 퀄리티는 개선의 여지가 많지만 저렴한 가격과 최종적으로 표출되는 음질을 고려했을 때 충분히 납득할 만 하다.

한편, 가까운 시일 내에 누군가 USB Audio DAC 와 인티 앰프가 통합된 모델을 출시해 좀 더 깔끔한 데스크탑 하이파이 환경을 구축할 수 있도록 해 주었으면 하는 바램이 있다. 해외에는 이미 KingRex T20U 같은 괜찮은 제품이 나와 있는데, 국내에는 아직 헤드폰 앰프만 탑재된 제품들 뿐이라 아쉬움이 크다.

추운 겨울 날, 가만히 식탁에 앉아 어머니께서 끓여 놓고 가신 고등어 조림을 먹었다. 감기 걸린 몸에 며칠 째 같은 반찬이지만 고등어 조림을 입에 넣었을 때의 따스한 느낌은 변함이 없다. 부모님의 사랑이 몸 구석구석을 파고든다는 것은 이런 느낌이겠지? 나도 모르게 감동한 채로 식사를 마친다.

오히려 얼굴을 마주하면서는 쉽사리 느끼지 못하던 것도 이렇게 사소한 일을 통해 전해진다니, 애잔하기 그지없다. 가족간의 사랑이란 세월이 흘러 닳고 닳아도 이렇게 그대로다.

나의 가족이여, 사랑합니다.

I have been trying to switch from Eclipse to IntelliJ IDEA recently. However, IDEA 8, the latest version, has shown me horribly unresponsive UI. Especially, the slow scroll in the editor window was intolerable; any keystroke that involves scrolling took up 100% CPU and only a couple lines were scrolled for a second. I could hardly edit my source code and had to go back to Eclipse.

Today, I’ve finally figured out what exactly was causing the problem – the intel video driver of X.org X11 server. In Fedora 10, the default video acceleration method of the intel video driver is ‘EXA’. According to the man page of the intel video driver (type man intel in your terminal), EXA is a newer and simpler acceleration architecture designed to better accelerate the X Render extension.

However, it seems like there’s a known performance issue with EXA that slows down most Java Swing applications and some web pages in Firefox. So, I switched back to XAA, the old XFree86 based acceleration architecture. Switchback is as simple as modifying the Device section of the /etc/X11/xorg.conf file:

Section "Device"
    Identifier  "Default Video Card"
    Driver      "intel"
    ...
    Option      "AccelMethod"  "XAA"
    ...
EndSection

After restarting the X server, I am seeing noticeable improvement in the responsiveness of all GUI applications including IDEA 8, Firefox, and even some GTK+ applications.

Update (Dec 16, 2008)

However, some users have reported that switching back to XAA causes artifacts in rendering and segmentation faults in some applications. Actually, I also experienced some UI glitches in a particular application, but I didn’t care much about it. A couple days ago, I found a way to improve the overall performance of EXA. Update your xorg.conf as follows:

Section "Device"
    Identifier  "Default Video Card"
    Driver      "intel"
    ...
    Option      "AccelMethod"          "EXA"
    Option      "MigrationHeuristic"   "greedy"
    Option      "ExaNoComposite"       "false"
    Option      "ExaOptimizeMigration" "true"
    ...
EndSection

IntelliJ wouldn’t perform as well as it does with XAA, but you will find it acceptable.

I am using Apache Continuum as a continuous integration server to test Netty, the Java NIO Client Server Network Application Framework.

I’m pretty satisfied with the CI server since it’s running more than 1000 Netty test cases about 4000 times a day with 7 different JDKs (see the live report here). It increases the chance for me to catch a hidden race conditions which might cause a problem in a production environment. I actually was able to find a couple critical issues like a dead lock thanks to the intensive automated testing.

However, the caveat of running big number of tests a day is that too many build results are filed into the build report database, slowing down the overall performance of the CI server. Moreover, Continuum doesn’t provide the paginated view of build results at this moment, and therefore the large number of build results can lead to high memory footprint and poor UI response time.

So, I ended up with a simplistic tool that removes the successful build results which are older than the certain amount of time (e.g. 6 hours). Continuum provides an easy-to-use client API which is based on XML–RPC, so it didn’t took long.

I run reap-old-builds command every 10 minutes to keep the build result set as small as possible, and now Continuum is responding much faster than before. If you are interested, please check my latest work from the following Subversion repository:

• https://t.motd.kr/repo/svn/continuum-tools/trunk

Ant2IDE generates Eclipse (or other IDE-specific) project files with proper classpath and source folder settings from Ant build.xml automatically.

I wrote ant2eclipse long time ago with my crude shell script skill to generate Eclipse project files from an Ant build.xml file.

In Ant2IDE, I extended the idea so that it works in a more elegant way using the BuildListener interface. The usage is pretty simple:

1. Add ant2ide.jar to the classpath:

   export CLASSPATH="/usr/local/libexec/ant2ide.jar:$CLASSPATH"

2. Change the working directory to the project home:

   cd /home/trustin/workspace/myAntProject

3. Clean the build

   ant clean

4. Run ant with the -listener option and appropriate task(s):

   ant -listener net.gleamynode.ant2ide.EclipseProjectGenerator compiile-main compile-test

You might prefer to use the following simple shell script:

#!/bin/sh
# Path: /usr/local/bin/ant2eclipse
export CLASSPATH="$CLASSPATH:/usr/local/libexec/ant2ide/ant2ide.jar"
ant -listener net.gleamynode.ant2ide.EclipseProjectGenerator "$@"

How it works

How does Ant2IDE generate the Eclipse project files? It listens to the build events fired by Ant and records the source and destination directory of the javac tasks into its internal data structure. Once build is completed successfully, Ant2IDE processes the recorded information to generate IDE-specific project files. It’s very simple but it works much better than analyzing build.xml directly or creating a new Java project from an Eclipse workbench.

Caveats

Of course, Ant2IDE is not a silver bullet – there’s some limitation in this approach.

First, you can’t get the correct build information unless you provide a proper Ant target. For example, clean target will never help AntIDE generate the project files. You should specify the target that compiles all source code, such as build-all or all, test-all.

Second, it doesn’t add all resource directories automatically. You have to add them manually for most cases. There’s no way to determine exactly whether a copy task copies resource files for now. One exception is when your project has a directory layout which is similar to that of Maven 2 project; Ant2IDE looks for a resources directory when the name of the source code directory is java, and add the resources directory to the source path automatically.

Third, Eclipse JDT is the only IDE that Ant2IDE supports at this moment. It’s designed to support other IDEs such as NetBeans and IntelliJ, but I don’t use them these days. Any contribution would be great.

Changelog

• Nov 19, 2008 – Added auto-detection of resources directory
• Nov 14, 2008 – Initial implementation