지난 화요일, 디자인패턴의 창시자 중 한 명이자, 이클립스 프로젝트의 창시자인 에릭 감마의 세미나에 다녀왔다. 에릭 감마가 새로 3~4년째 만들고 있는 협업 플랫폼인 Jazz와 그 플랫폼 상에서 동작하는 RTC(Rational Team Concert)에 관한 이야기들이었다.

행사장에 조금 늦었는데, 도착했을 때에는 시작한 지 10분쯤 지난 후였고, 동시 통역이 진행되고 있었다. 포스 넘치는 에릭 감마 아저씨가 이클립스 프로젝트에 대한 이야기를 하고 있었다. API에 대한 이야길 하는 중이었는데, API는 변화에 대한 리스크가 크기 때문에, 최소한으로 유지하는 것이 중요하다는 점. 그래서, 이클립스가 취한 전략은, Everything is a plug-in 이라고 말했다. “no exceptions”라고도 했다. APIs are a huge commitment이기 때문에, 이런 전략을 취했다고 했다. 즉, API 자체는 정말정말 최소화 하고, 기능 자체를 플러그인으로 만들었다는 소리다.

그 후에, 이클립스의 방향에 대해서 말했다. 2002년에 회사에서 이클립스를 오픈소스화 했을 때에는, 이렇게 잘 될줄은 몰랐다고 했다. 커뮤니티의 힘은 정말 굉장했다면서, 현재의 개발방향 추세에 대해서 말했다. 이클립스 프로젝트가 전세계의 많은 개발자들이 인터넷 상으로 협업을 하는 내용에 다루면서, 어떤 식으로 협업을 하는지에 대해 이야길 했다. 또한, 개발 프로세스에서 Iteration에 대한 이야길 조금 해줬다. 이 팀은 애자일 방법론들을 적용했는데, 특정 방법론에 치우친 것이 아니라, 필요한 부분만 사용했다고 했다. 그러면서, Iteration에 대한 이야길 했다. “It is all about being continuous”라고 하면서, 디자인/리팩토링, 통합/테스팅, 배포/데모, 피드백, learning 등등 모두 continuous하다고 했다.

이클립스의 observer들은 오리가 물에 떠있기 위해서 발을 엄청나게 휘젓듯이, 이클립스 팀이 그 안에서 얼마나 많은 work/stress/human factor를 소비하는지 모른다고 했다. 특히, 팀으로 프로젝트가 진행될 때의 Pain에 대한 이야기가 나왔는데, Collaboration, Development, Project Management에 대한 이야길 해줬다. 그러면서, 슬슬 내용은 (이제서야;;) 본론인 Jazz 로 넘어갔다.

Jazz는 팀 프로세스를 위한 협업 플랫폼이다. 개발, 프로젝트 관리, 애자일 프로세스 등이 통합된 플랫폼이다. 이 중에서도, RTC라고 해서, Rational Team Concert라는 플러그인(?)이 있는데, 이 플러그인이 오늘 얘기의 중점이었다. 온라인용, 또는 회사용, 애자일 개발 도구 세트 같은 느낌?

90년대말은 Point Tools에 포커스가 맞춰졌다. 이클립스는 One Developer에게 포커스가 맞춰졌다. 이젠, Team과 Collaboration을 위한 것이 있어야 한다고 했다. 이클립스 프로젝트의 주역 멤버들이 4년전부터 만들기 시작했고, 자신에게 있어서 Dream Project라고 했다. 왜냐면, 항상 이런 것을 필요로 하고 있었기 때문! (나도 완전 필요했다고!!). 이걸로 개발자들의 삶을 개선할 수 있기를 희망한다고 했다.

현대의 프로세스는, 민첩성을 원하지만, 여전히 예측이 중요하다. 투명성도 중요하다. 생산성은 하나의 개발자를 위한 것이 아닌, 전체 팀을 위한 것이라 했다. (스크럼의 소멸차트가, 개인별로 그려지는 것이 아닌, 팀 위주로 그려지는 이유도 마찬가지라 생각한다). 그래서 이런 것을 위한 것이 Jazz 플랫폼이다.

에릭 감마가 직접 시연을 보여줬는데, 전체 느낌은, 이클립스 + 버전 트래킹 + 이슈 트래킹 + 소멸차트와 같은 애자일에 필요한 도구들 + 온라인 협업 + 코드를 쉽게 추적할 수 있는 기능 + 팀별로 룰과 프로세스를 정할 수 있는 기능 (신입은 커밋을 허락을 받아야 한다던가) + 등등의 많은 기능들을 RTC라는 이름에 다 때려넣었다. 뭔가 사용법은 이클립스를 처음 접했을때 만큼이나 복잡해보였지만 -_-;;; 익숙해지면, 엄청난 향상을 가져올 것 같은 느낌?

중요한 것은, 팀별로 각자의 프로세스가 있는데, RTC에서는 이런 규칙을 정할 수 있다고 했다. 개인별로 대쉬보드가 주어지고, 팀별 대쉬보드도 나오고, 프로세스에 대한 규칙을 정할 수도 있다. 대쉬보드는 현황을 파악하는 것 보다는, 문제에 초점이 맞춰져서, 해당 버그나 기능을 바로바로 추적해서 “지금 당장 어디부터 일을 해야하는지”를 쉽게 파악할 수 있게 해준다. 또한, 전체 프로젝트 리더를 위한, team of team을 위한 대쉬보드도 주어지고, Baglog Plan을 세울 수 있게 하고, Release, Iteration, Daily 등에 대한 것과 현재 진행사항을 정할 수 있고, Burndown Chart도 나온다. Jazz.net에서 현재 버전을 사용해 볼 수 있고, 재즈의 목적은, 각각의 개발자와 구성원들간의 팀 프로세스 상에서의 투명성과 방향성을 제공하여, 커뮤니케이션 비용을 낮추고, 협업을 돕는 것에 있다.

에릭 감마의 발표가 끝나고, 잠시 휴식을 취한 후에, 질답이 이어졌다. 질답은 무려 1시간이 넘게 했고, 많은 질답이 오갔는데, 기록을 별로 못했다. -_-a 기억에 남는 것 몇가지만 추스리자면,

Q. 에릭 감마씨는 API 개발을 많이 해보셨을텐데, API 설계시에 가장 중점을 두는 부분은 무엇인가요?

A. 첫째는, 사용의 용이성. 이해하기 쉬운가. API는 사용의 편리함이 가장 중요하다. 두번째는 UnitTest. 유닛테스트 자체가 사용 용이성의 척도이기도 하다. 세번째는, 고객의 피드백. 완성 전에 고객을 API 개발에 참여시켜야 한다. (고객이라 함은, 해당 API를 사용하는 프로그래머를 의미).

Q. 에릭 감마씨는 GoF 디자인 패턴의 저자인데, 아까 말씀하셨을 때에, 설계시에 가장 중요한 것은 “경험”이라고 하셨는데, 패턴을 굳이 학습해야 하는 이유는 무엇인지? GoF 책 말고도, 다른 패턴들이 있는데, 이것도 모두 학습을 해야 하는지?

A. 그 책은 웹브라우저보다도 오래된 패턴이 있어서, 가끔 얼굴이 화끈거린다. 다시 쓰고 싶은 부분도 있다. 하지만, 패턴은 중요하다. 책의 패턴을 템플릿처럼 그대로 쓰려고 하지 마라. GoF에 나오는 것은 물론이고, 그 책에 안 나온 더 많은 패턴을 익혀라. (예를 들어, 마틴 파울러의, 엔터프라이즈 패턴이라던가, Pattern-Oriented Software Architecture 시리즈에 나오는 패턴들이라던가.) 많은 경험이 소프트웨어 설계에서 가장 중요한 항목인 것은 맞지만, 그런 경험이 없으면, 패턴을 통해 다른 프로그래머들의 경험을 학습할 수 있다. 패턴도 많이 익히고, 경험도 많이 쌓아라.

그리고 마지막으로, 에릭 감마가, “Design is NEVER Easy”라고 강조하며 말했다. 그러니깐, 계속 수련을 하라고.

– 이상한 나라의 종텐.