오늘부로 드디어 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!

날씨, 그리움.

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

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

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

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

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

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

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