2004년 12월 18일

이 글의 정확한 작성 시각을 잃어버렸습니다.

다음 주가 크리스마스라니, 나이를 먹을 수록 시간은 빨리 흘러가는 것일까? 확실히 회사라는 곳 안에 있게 되면 나 자신을 위해 할 수 있는 일이 줄어들게 된다. 그래서 사람들은 늦게나마 학창시절을 그리워하고, 자식들에게 학생일때가 좋으니 열심히 공부하라고 말하는 듯 하다. 하지만 나에게는 잠시나마 그 학생이라는 조금은 어색한 신분으로 돌아갈 기회가 주어졌으니, 부디 이 기회라는 것에 익숙하게 되어 다시 수 년 전의 나로 되돌아가지는 않기를 기도해 본다.

2004년 11월 28일

이 글의 정확한 작성 시각을 잃어버렸습니다.

요즘 너무 애써서 바쁘게 살고 있지는 않은가? 그래, 삶은 계속된다. 그것은 그런데 언제 끝날지 모른다고 생각하면 불안해지고는 한다. 언제까지나 계속될 줄만 알았던 길이 끝나는 순간 나에게 남겨지는 것은 무엇일까. 끝나지는 않을까 조마조마 하면서 지냈는데 결국 길고 길게 이어지는 길이었다면 또 얼마나 허탈할까. 내가 한살의 나이를 더 먹든 먹지 않든 나의 삶은 여전히 불확실하다.

새벽 세시를 넘기고 있다. 아레오라는 회사에서 정식으로 일하게 된 지도 1년이 넘는 시간이 흘렀다. 그렇게 나쁜 기억은 없다. 하지만 그렇게 좋은 기억 또한 없다. 내가 떠나고 2년이 지난 후에도 아레오라는 회사는 계속 지금처럼 이 자리에 서 있을까? 아마 지금의 규모를 넘어서는 회사가 되기는 힘들지 않을까 싶다. 회사란 것도 아마 마찬가지인 듯 하다. 선택과 집중이 중요하다고 하지만, 누구나가 많은 것을 손에 쥐고 싶어한다. 어느 순간은 어떤 것이 정말 필요한 것처럼 느껴졌다가도 어느 사이 그 대상이 바뀌어버린다. 개인조차 잘 할 수 없는 일을 회사가 하기란 그렇게도 어렵다.

좋지도 나쁘지도 않은 이 회사의 기억처럼 나의 많은 기억들 중에 정말 너무나 좋았던 것은 얼마 없었다. 나는 어떤 일에 대해 특별한 기복이 없는 편이라 더더욱 그럴 듯 하다. 너무나 순간적으로 기쁨과 슬픔, 분노가 다가왔다가는 사라져버린다. 시간이 지나 되돌아 보면 좋은 기억도 나쁜 기억도 모두 그저 오선지의 한 옥타브에 걸쳐 있는 음계와 같다. 많은 것을 쉽게 잊어버린다는 것은 슬프면서도 기쁘지만 한편으로는 아무것도 아닌 일인지도 모르겠다.

2004년 11월 9일

이 글의 정확한 작성 시각을 잃어버렸습니다.

자바 서비스넷 대사건 – 또는 연봉파문 – 도 마무리가 되어 가는 듯 했더니 또 불이 붙고 있다. 뭐라고 글을 남길 입장이 되지 않아 보고만 있는데, 사실 조금 재미있기도 하다. 자바 서비스넷에서 활동하면서 이렇게 많은 답글이 달린 것은 정말이지 처음이 아닌가 싶다. 사람들이 나를 ‘아~ 그 연봉 얼마~’ 라고 부르지는 않을까 두렵다.

요즘에는 사진 편집과 음악 감상에 푹 빠져 제대로 된 프로그래밍을 하지 못했고 거기에다가 신기술 공부라던지도 전혀 하지 않아 불안감이 깊어지고 있다. 오늘 저녁엔 프로그래밍을 했지만 프로그래밍만 하다가 새로운 기술을 보지 못하고 지나치는 것은 두렵다. 게다가 사 놓고 읽지 않은 여러 양서들을 읽는 시간이 거의 없어 또 문제다. 아무래도 위키를 사용해 일종의 스터디 노트를 만들어야 겠다. 읽은 책의 내용을 정리해서 올리면 나나 이 곳에 오는 사람들에게도 도움이 될테니 말이다.

시간이 자정을 넘었다. 영희씨를 처음 만난 지도 1년이 넘었다. 회사 근처 일본어 학원의 위치를 몰라 헤매다가 그만두려는 마지막 찰나에 발견한 학원 간판과 학원에 들어섰을때 등록할지 말지에 대한 망설임. 그리고 간신히 수업에 들어간 그 날 내 앞자리에 앉은 아름다운 목소리의 소녀를 아직도 잊을 수가 없다. 돌이켜 보면 얼핏 생각하면 별다른 에피소드 없이 지나 온 짧은 시간이지만, 눈을 감고 떠올릴 수록 많은 추억들이 떠오른다. 어쩌면 우리가 만났던 하루 하루 한 순간 한 순간이 추억이 아닌가 싶을 정도로 우리는 행복했고 또 행복하다.

언제나 나를 위해 주는 영희씨인 만큼 올해가 가기 전에 자격증이라든지 좋은 일들이 많이 있었으면 좋겠다. 그리고 그런 성공 – 또는 그것이 실패일지라도 – 의 매 순간 순간 항상 함께라면 좋겠다.

2004년 11월 3일

이 글의 정확한 작성 시각을 잃어버렸습니다.
멋진 편지를 쓴다는 것이 참 쉬울 때도 있고 그렇지 않을 때도 있다. 읽기만 해도 그 표현에 감탄이 절로 나오는 편지, 구구절절 감정이 넘쳐 흐르는 그런 아름다운 편지를 쓰고 싶은데 마음껏 되지 않는 그런 때 말이다. 새벽 이슬을 품은 공기가 물방울을 떨어뜨려 가녀린 잎새를 매끄럽게 타고 내려가듯 써 내려가진다면 얼마나 좋을까?

2004년 10월 24일

이 글의 정확한 작성 시각을 잃어버렸습니다.

홈페이지를 새단장한 뒤 한동안 일기를 쓰지 않았다. 어쩌면 나조차도 이 WikiWiki 라는 것에 익숙하지 않아서인지도 모르겠다. 하지만 이 녀석을 단순화된 웹 어서링 툴이라고 생각한다면 생각보다는 간단하다는 생각이 든다. 오캄의 면도날은 여전히 빛나고 있으니까.

회사에서의 힘든 일들에 집에서는 컴퓨터 앞에 앉기조차 힘들것이라 생각했지만 이렇게도 편안한 마음으로 컴퓨터 앞에 앉아 있는 내 자신을 보면 집이라는 것은 정말 낭만적인 것임에 틀림없다. 자기만의 공간 속에서 사람은 그 어느때보다도 커지나 보다.

Sun TechDays 2004-2005 참가 소감

여러 회사들의 기조 연설은 매우 재미있었다. 특히 웹 서비스에 관심이 많은 나에게는 많은 도움이 되었다. 학교 수업이랑은 거리가 있는지라 졸음에 꾸벅 꾸벅 졸기가 다반사였지만. (웃음)

신상철씨의 세션은 특히 재미가 있었고, 그가 나에게 티-셔츠를 두 개나 주어서 감사하고 있다. 사실 다른 세션들이 그렇게 지루하지는 않았지만 내가 다 아는 것을 다루면 재미가 없지 않은가. 인지상정이겠지 싶다.

특히 이 행사에서는 웹 서비스의 전체적인 조망과 로드맵 및 각 선두 주자들의 접근 방법에 대해 느낄 수 있어서 많은 도움이 되었다. 그동안 오라클에 대해 갖고 있던 부정적인 생각도 말끔히 해소되었고, 멀게만 느껴지던 SAP 에 대해서도 가깝게 느겨지는 계기가 되었다고 생각한다.

다만 아쉬운 점이 있었다면, 제공된 음식이 호텔 측에서 준비한 것임에도 불구하고 형편 없었다는 점, 입장이 양일 모두 10분 이상 지연되었다는 점이다. 또, 각 세션에 대한 기술 난이도를 기재하여 자신에게 적합한 세션에 참가하여 시간을 절약할 수 있었으면 좋았 겠다는 생각도 든다. 위화감이 조성되려나?

그리고 오늘 드디어 ASF SVN Repository 에 처음으로 commit 을 했다. 나만의 작은 역사가 시작된 셈이다.

오늘 컨퍼런스의 기조 연설을 담당한 사람들, 에반젤리스트들, 그리고 첫 번째 ASF Commit. 나에게 모든 것이 중요하게 다가왔다.

ASF Committer 겸 Project Leader 가 되다

오늘부로 드디어 ASF의 공식 Committer 가 되었다. 동시에 SEDA 프로젝트의 PL (Project Leader) 까지. ASF 사무소에 ICLA (Individual Contributor License Agreement) 에 사인만 해서 팩스로 보내면 형식적인 절차까지 마무리된다.

이렇게 되기까지는 내가 진행하고 있던 Netty2 프로젝트의 도움이 컸다. Netty2 를 사용하여 Apache Eve 에 Kerberos 기능을 추가한 Enrique Rodriguez 가 Apache Eve 의 프로젝트 리더인 Alex Karasulu 에게 Netty2 에 대한 이야기를 꺼내게 된 것이 중요한 계기였다. 나 자신도 이렇게 되리라고는 생각하지 못했지만 어쨌든 Netty2 의 유용함이 결정적으로 증명된 순간이었다.

앞으로 Netty2 에서 얻은 노하우를 바탕으로 Apache SEDA 프로젝트를 진행할 것이고, 나는 그것이 최고의 Java 고성능 네트워크 어플 리케이션 프레임워크가 될 것이라 자신한다.

The best is yet to come!

2004년 9월 27일

날씨, 그리움.

오렌지 빛으로 물든 채 미동도 하지 않는 하늘의 구름을 올려다보며 아름답다고 말할 수 있는, 눈을 감고 침대에 누워 음악의 깊이를 느낄 수 있는, 깊은 밤 조용히 책상에 앉아 러브레터를 써 내려갈 그런 여유를 마지막으로 가져 본 것이 언제일까?

언젠가는 좋아하는 음악을 틀고 침대에 누워, 창가에 걸친 해질녘의 구름을 바라보며 사랑하는 사람에게 편지를 쓰고 싶다.

위기 관리 (Risk management)

개발자는 버그를 만든다. 버그는 서비스에 손실을 끼칠 수 있으며, 그것은 금전상의 손실을 발생시킬 수 있다. 그렇다면 개발자는 이에 대해 사과해야 하는가?

나의 대답은 ‘No’ 다. 프로젝트를 관리하거나 계약을 진행하는 자는 버그의 발생으로 인해 생기는 손실을 총 비용에 포함 해야 한다.

또한 바꾸어 생각하면 관리자가 계약 진행자가 일을 잘못 진행하여 개발자가 힘든 하루하루를 보내게 되었다면 관리자는 이에 대해 사과해야 하는가?

문제는 모두가 이 사실에 대해 책임을 지는가로 귀결된다. 만약 관리자의 잘못은 드러나지 않고 그 결과 개발자가 겉으로 드러나는 책임을 지게 된다면 이것은 명백한 시스템의 문제다.

잘 가꿔진 팀이라면 누구도 사과할 필요가 없다. 그것은 단지 프로젝트 진행상의 예측치의 일부에 오차가 발생해 수정 이 필요하게 되는 일상적인 ‘Risk management’ 아닌가?