IBM에서 에릭감마를 초청해서 "Erich Gamma와 함께 여는 개발자 세상"이라는 제목으로 세미나를 열었습니다. 에릭 감마는 아시는 분은 아시겠지만 GoF(Gang of Four)중의 한명입니다. GoF는 Design Patterns (번역서)책의 저자로 이 디자인패턴이 프로그래밍의 새로운 지평을 역사적인 서적입니다.(라고 하더군요. 내공이 딸려서 아직 못읽어봤네요.) 어쨌든 이 책을 지은 에릭 감마(Erich Gamma), 리처드 헬름(Richard Helm), 랄프 존슨(Ralph Johnson), 존 블리시데스(John Vissides) 이렇게 4명을 Gang of Four라고 부릅니다. 역사적인 분들이시죠.. ㅎㅎㅎㅎㅎ

그 중의 에릭 감마는 제가 제일 좋아하는 IDE이기도 한 Eclipse의 창시자로 지금도 Eclipse 개발그룹을 이끌고 있습니다. 2주전에 에릭감마가 온다는 얘기를 듣고는 냉큼 신청해 놓고는 눈치보다가 이번주에는 바쁜일도 없고 해서 허락을 맡고 갔다 왔습니다. GoF중의 한명인 랄프 존슨도 지난주 토요일(15일)에 국내에서 세미나가 있었습니다. 다음 달에는 켄트벡이 온다는 소식이 들리던데.... 평생 한번 볼 수나 있을까 했던 분들이 갑자기 대거 한국에 오시는군요. ㅎㅎ


행사는 위와같은 순서로 진행되었습니다.


세미나 처음에는 IBM 이승재 사업부장의 간단한 환영사와 한국소프트웨어진흥원 SW공학단의 이상은님의 축사로 시작되었습니다. 근데 머 말이 축사이지 왜하는지 알 수 없는 소프트웨어공학에 대한 PPT로 이어졌습니다. ㅡ..ㅡ

어쨌든 이어서 드디어 기다리던 에릭감마의 "협업을 위한 개방형 소프트웨어 개발 플랫폼 Jazz 및 협업 개발 환경 솔루션 RTC 소개"가 이어졌습니다.


how (8 years of) eclipse changed my views on softwaredevelopment -

에릭감마가 진행한 PPT는 "how (8 years of) eclipse changed my views on software development"라는 제목이었는데 파일로까지는 제공해 주지 않아서 에릭감마가 QCON 2008에서 한 PPT를 가져왔습니다.(작년에 한거라서 7 years이네요.. ㅎ) 약간 변경되긴 했는데 대부분은 거의 비슷하더군요.
포스팅 뒤에 IBM에서 발표자료를 보내주었습니다. IBM사이트에서 PDF 다운로드가 가능합니다 첨부했던 작년자료도 올해 발표자료로 교체하였습니다.



Eclipse 개발
발표는 이클립스에 대한 설명부터 이어졌습니다. 처음에는 이 얘기를 왜 하나 했는데 이클립스를 개발하면서 겪은 경험을 토대로 개념이 발전되면서 구성된 것이 Jazz라고 할 수 있는것 같습니다. 이클립스가 앞으로 Jazz가 된다는 것은 아니고 이클립스 개발이 진행되면서 에릭 감마가 구상한 시스템이 Jazz라는 형태로 실체화 된 것 같습니다.

이클립스를 만들고 사용하면서 바뀐 생각들부터 얘기하고 있습니다. 이클립스는 2000년에 시작되었습니다. 건물을 예로 들면 건물의 위치, 구조, 전선, 가구들의 수명이 다릅니다. 벽이나 구조, 땅 등은 수십년에서 수백년을 가지만 가구들같은 경우는 몇년마다 바뀌기도 합니다. 이클립스도 이렇게 레이어마다 수명이 다르게 구성되어야 하고 그 기반시스템(Structure foundation)을 플러그인(plug-in) 아키텍쳐로 결정하였습니다. 그리고 이 플러그인은 API에 의존적입니다.

그래서 API가 중요했고 API의 디자인이 필요했습니다. 그리고 UI는 계속 진화하고 있습니다. 여기서 중요한 결론은 모듈화가 중요하고 모든 것은 플러그인이고 API는 거대한 약속인데 안정성이 중요하고 너무 많은 것을 정의하려고 하지는 않았습니다.

이클립스 3.4에서는 API의 Baseline를 선택할 수 있게 되어 있는데 API는 계속 발전하여야 하는데 버전에 종속되지 않는 것이 좋다는 결론이 나왔습니다. 마치 인터넷 처럼 URL과 HTTP로 정의되고 각 요구들이 Link로 연결이 됩니다. 그래서 API스타일을 REST스타일로 변경하였습니다. 이것이 실체화 된것이 OSLC입니다. 이클립스는 Jazz로 발전하고 Jazz는 RTC로 구체화 됩니다.



Eclipse의 오픈소스화
2002년에는 이클립스에게 큰 변화가 생기는데 이클립스의 오픈소스화가 결정됩니다. 그 이전까지는 스위스 은행처럼 폐쇄적인 방식이었습니다. 그래서 개발자와 사용자간의 소통이 없었고 사용자들이 무언가를 물어보아도 알려줄 수 없다는 대답만 할 뿐이었습니다. 하지만 에릭감마는 개발자와 사용자의 커뮤니티를 믿고 있습니다. 그래서 2002부터 오픈소스화가 결정되어 그뒤로는 오픈소스로 진행이 됩니다.

이클립스팀은 선적(Shipping)을 중요하게 생각합니다. 일정 퀄리티이상이 되었을 경우에만 선적을 하며 얼마나 선적했냐가 팀의 공헌도를 증명하게 됩니다. 오픈소스화가 되니까 공개적으로 기술적인 논의를 하는 것이 솔직히 좀 두려웠었다고 합니다. 이 과정에서는 오픈소스는 투명한 사용자 커뮤니티와 개발자간의 피드백이 선순환 되는 아주 훌륭한 이 모델이며 오픈소스프로젝트에 제한은 없기 때문에 이 모델을 상용에 적용하여 개방형 상용개발을 할 수 있습니다.

개방형 상용개발(Open Commercial Development)을 Jazz에 적용하였고 사용자 피드백으로 품질을 향상시킬 수 있었습니다. Eclipse Way Practices는 특별한 것은 없습니다. 여러가지 방법론등이 있는데 그 방법론 자체는 중요하지 않고 어떻게 조합하는 가가 중요합니다. 그렇게 해서 점진적으로 가치(Value)를 증가시켜야 합니다. 그래서 원하는 Value(보통은 일정)을 극대화 할 수 있도록 하였습니다.


위 화면은 에릭감마가 강조하였던 그림입니다. 과거에는 빨간줄처럼 되었다면 이제는 늘어지지 않게 반복주기를 촘촘하게 함으로써 스트레스를 줄입니다. 반복적이고 적응되어가는 계획, 디자인/리펙토링, 통합과 테스팅, 딜리버링과 데모, 피드백, 학습등을 끊임없이(continuous) 수행되어야 할 일들입니다. (이건 애자일에서 얘기하는 것을 말한것 같군요.)



JAZZ와 Team Concert
하지만 이클립스에서 어려운 점(Pain Points)들이 있었습니다. 그것은 협업(Collaboration), 개발(Development), 프로젝트 관리(Project Management)입니다.

이클립스를 만들때에는 한명의 개발자에게 초점을 맞추었었습니다. 하지만 지금은 팀과 팀의 협업에 초점을 맞추어야 합니다.그것이 Jazz와 Team Concert입니다. Open Lifecycle services Interrations위에 Jazz Team Server가 올라가고 그 위에 많은 툴들이 올라가고 서로 Intergration이 가능합니다. RTC(Rational Team Concert)가 그중 하나입니다.

RCT의 개발은 4년전부터 이클립스 팀에 의해서 시작되었습니다. 소스관리, Work Item, 빌드, 프로젝트 상태들이 통합되어 있습니다. Invitation메일을 받고 팀원들이 가입을 할 수 있으면 일정, 현재 하는 질, 진행사항, 테스트, 소스코드, 일 할당, 결정 추적, 소스리뷰등이 통합되어 있습니다. 이 모든 것을 Jazz의 대쉬보드에서 볼 수 있습니다. (보통은 문서로 만들어서 잘 안읽어보게 되는)팀내의 룰이나 프로세스를 강제해서 새로온 참여한 팀원들에게 강제할 수 있습니다.

목표는 팀작업의 효율성을 높이는 것입니다. 문제가 생길 경우 Jazz의 대쉬보드를 통해서 쉽게 파악할 수 있습니다. 개인적인 대쉬보드와 팀의 대쉬보드뿐만 아니라 팀들의 팀단위(프로젝트 레벨)의 대쉬보드도 제공하고 있습니다.

오기전에 Jazz와 RTC(Rational Team Concert)에 대해서 좀 공부를 했었는데 내용이 복잡해서 대충 감정도만 잡았습니다. 에릭감마가 만든 Jazz는 개방형 협업 개발플랫폼이고 RTC는 Jazz플랫폼에 올라가는 Product중 하나로 애자일개발에 맞게 구성된 솔루션입니다.


생각보다 양이 많아져서 포스팅을 나눠야겠습니다.

아무래도 Jazz플랫폼과 RTC라는 툴에 대한 세미나 였기 때문에 툴 사용법을 가르쳐 주는 것을 의도에 맞지 않았을 때고 가볍게 시연을 해주기는 했지만 협업플랫폼이라는 타이틀도 규모가 크고 RTC자체가 기능이 너무 많아서 시연정도로 다 파악하기엔 무리였습니다. 결국 제대로 어떤 툴인지 파악하기 위해서는 실제로 사용을 점 해보아야 할 것 같습니다.