나의 가슴을 울리게한, RTC에 대한 고객의 평가, 그리고 다시 고객으로부터의 번역선물

오늘 고객으로부터 너무도 감사하고 소중한 선물을 하나 받았다.
IBM으로 옳긴 이후 가장 감동먹은(!) 일중에 하나가 아닐까 한다.

아래에 링크되어 있는 글이 jazz.net 에 올라와 화재가 되고 있는 가운데 (고객이 작성한),
오늘 이 글을 다시 번역한 글을 고객이 다시 나에게 보내준 것이다.
"툴 저변에 도움이 되라는 ..." 짧은 인사말과 함께 말이다.

마음 같아선 성함까지 언급하며 감사의 글을 남기고 싶지만, 아직 이에 대한 확답까지는 받지 못한 상황이라
회사와 성함은 다음에 기회로 미룰까 한다. (복받치는 감정을 추스리기 위해 급히 이렇게라도 글 남기고 있다.)

...
1년여 RTC라는 제품을 위해 시간과 노력을 들이며... 나름 힘든 시간과 고민의 나날을 보내고 있는 가운데
이 선물은 더운 여름으로 가며 지칠 수 있는 나에겐 너무나도 시원한 한여름의 소나기와도 같은 것이 아닐까 한다.

OOO님, 선물 너무나도 감사합니다. *^^*

+++++++++++++++++++++++++++++++++++(본문)+++++++++++++++++++++++++++++++++++

Source: https://jazz.net:443/forums/viewtopic.php?t=4383&sid=b1b8f1f9950e2b0766aedd278bfc5044

Translator: Wegra Lee

꾀 전에 사내 네트워크에 포스팅한 블로그인데, 혹 다른 사람들에게도 도움이 될까 싶어 여기 다시 올려본다.

-- Roman Smirak, Tieto

최근 Rational Team Concert (RTC)를 Jira와 Subversion 에 CruiseControl/Maven/Hudson 와 같은 빌드 시스템과 같이 쓰는 경우와 비교해달라는 요청을 받았다.

두 솔루션 비교에 대한 사람들의 관심이 높아짐에 따라, 나는 서로의 경험을 공유하고 다른 이들의 견해도 들어보고자, 이 블로그를 작성하기로 마음먹었다.

나는 몇 년 전에는 Bugzilla와 CVS, Ant 를 조합 사용했었고, 꾀 괜찮았다.

다음엔 Bugzilla와 CVS를 {JIRA+ SVN + CruiseControl} 로 갈아탔고, 그것은 멋진 경험이었다. 사용성과 통합성 면에서 개선되었고, 새로운 기능들과 확장성.. 멋지군!

그 리곤 다시 1년 반쯤 전부터 Jazz 를 파일롯 형태로 사용해보기 시작했는데, 그 결정으로 인해 나는 한 단계 더 진보한 환경을 개발 환경을 맛볼 수 있게 된 것이다. 가히 '환상적'이었다. 2007년 EclipseCon 에 참석해 Jazz의 동작 데모를 보고 갈채를 보냈던 기억이 난다. 자! 그럼 이제부터 나의 개인적인 경험과 견해들을 공유해본다.

RTC 의 단점들

열거할 거리가 몇 개 안 되니 금방 끝날 터이니 단점들부터 시작해보자. 솔직히.. 단점이 맞는지 스스로 좀 의심스럽다.

최 근에 RTC 1.0 이 공식 릴리스 되었고, 짐작되었듯 공짜는 아니었다. 그리고.. IBM 이지 않은가? Jira 역시 상용 제품이긴 하지만, RTC의 가격은 거의 ClearCase 수준이었다. 하지만 총 소유비용(TCO, Total Cost of Ownership) 관점에서 생각하면 이야기가 달라질 수 있다. 시스템 구축, 유지보수, H/W, OS, DB 가격, 다른 시스템과 통합 문제, 서비스 지원을 받기 위한 추가 비용 등을 다 고려한다면.. 글쎄, 내가 정확한 수치를 제시할 수는 없고, 뒤이어 나올 장점들을 고려하면서 여러분 스스로 RTC의 투자 효용성(ROI, Return Of Investment)을 따져보기 바란다.

두 번째 '잠재적' 단점은 무엇일까? Jira, SVN, CruiseControl/Maven/Hudson 과 같은 툴들은 시장에 등장한 지 벌써 몇 년이 되어, 이미  안정성 검증이 거의 끝났고 사용되고 있는 곳 또한 많다. 그래서 경험 있는 사람 찾기도 어렵지 않다. 뿐만 아니라 Jira와 CruiseControl의 경우엔 꾀 많은 plug-in 들을 제공한다. (단, open source 의 특성상, 커뮤니티에 의해 잘 검증/관리되는 plug-in들이 있는가 하면, 자칫 잘못하면 대재앙으로 변해버리는 plug-in 들도 있으니 주의가 필요하다) 우리는 RTC의 정식 버전이 나오기 전부터 마일스톤 빌드 (정식 버전이 아니라서 안정성 면에서 조금 부족함) 를 다운받아 사용했기 때문에, 종종 결함들과 맞딱뜨렸다. 하지만 다행히도, 우리 말고도 이미 많은 곳에서 RTC를 테스트 중이었고, 잘 활성화되어 있는 Jazz 커뮤니티 덕분에, 운영에 큰 어려움은 없었다. 그리고 Eclipse Way라는 iterative 어프로치로 개발된 1.0 버전은 아주 성숙하고 안정적인 제품으로 평할만 했다.

RTC 의 장점들

장점들은 몇 개의 챕터로 나눠서 기술할 생각인데.. 음.. RTC가 제공하는 수많은 멋진 기능들 중에서도 우리가 일하는 방식에 가장 큰 영향을 주는 특성들에 포커싱해 보았다.

장점 #1: 애자일 플래닝과 자원 관리

Jira 는 '비공식적인 Bugzilla의 후계자'라 할 수 있다. 이 말인즉.. 그 중심 사상이 결함 관리에 있음을 뜻한다. Jira는 작업 항목을 모두 '문제(Issue)'로 바라본다. - 내 친구중 하나가 최근 이런 질문을 했드랬다: 너희팀이 '모든 게 다 문제다'라는 개념을 수용한다면.. 그게 어떤 반향 (social impact)을 불러 일으킬까? :-) 뿐만 아니라 모든 UI 는 개인 개발자/사용자가 제기하고 수정한 문제들에 맞춰 디자인되었다. 이런 환경에서 팀이 애자일 프로세스를 따른려 한다면 어떻게 될까? 스크럼(Scrum)이 제안하는 집단 계획 (collective planning) 방식을 취해보고 싶다면? 음.. 생각해보자. 우리는 7명으로 구성된 팀이다. Iteration 계획 회의 열어 이번 iteration 의 주요 기능들, 그에 따른 세부 작업 항목과 결함들에 대해 논의/계획하고, 개발자들에게 할당한다. 그런데 전체 팀 관점에서의 뷰(view)나 개발 주기와 같은 정황 정보(context) 는 어디서 찾아봐야 한단 말인가. 결국 작업 항목 DB와 별도로 추가 자료를 만들 수 밖에.. 그래서 MS Word 나 Wiki 같은 것을 이용해, 우리 팀의 목표는 무엇이고, 위험요소는 뭐고, 우리가 하는 일을 어떻게 평가할 지, 또 iteration 테스트 전략은 무엇인지 등을 작성해 놓는다.

여 기서 끝나지 않는다. 이렇게 작성해 놓은 팀 계획이 얼마나 짜임새 있는지 궁금하지 아니한가? 일정에 맞춰 끝낼 수 있을 지, 특정 팀원에게 너무 많은 일이 몰려 있지는 않은지. 중간에 계획을 재조정할 필요는 없는지 등등.. Jira는 자원 관리 기능 또한 누락되어 있어 다른 툴을 따로 쓸 수 밖에 없는데.. 주로 MS Project 나 Excel 같은 것을 택할 것이다. 결과적으로 정보는 더욱 분산되게 되고, 이것들을 다 동기화해가며 관리하려는 시도는 엄청난 고통과 시간 소비를 동반한다. 또한 팀원의 휴가 일정도 거의 고려되지 않는데.. 사실 종종 큰 문제를 야기하는 문제이기도 하다. (최근 직접 경험하기도 했는데) 팀은 팀원들의 휴가 계획이 미칠 영향을 고려하지 않고, 자리를 비워 문제가 터진 후에야 상황 파악에 나서게 된다. "할 수 없지. 누구도 그 일을 쉽게 대신할 순 없겠어." - 당연히 제때 끝마치지 못했다.

RTC 는 언제든 전체 팀에 대한 정보를 한 눈에 볼 수 있는 팀 뷰(team view)를 제공한다. - 팀 중심(team first)은 Jazz 설계의 핵심 사상 중 하나인 것이다. 일원화된 자원 관리로 팀원들이 일에 투입할 수 있는 시간, 휴가 일정, 그 지역의 시간대 까지 고려된 계획을 세울 수 있다. 이런 정보들을 바탕으로 우리는 개발 계획의 품질을 실시간으로 확인 가능하다. 과다한 업무로 도움이 필요한 사람이 누구인지, 누가 그 사람을 도와줄 여력이 있는지.. 그래서 우리 팀이 무사히 제 시간에 목표한 개발을 끝마칠 수 있는지를 한 눈에 확인할 수 있다. 그리고 이 뷰는 개발이 진행되면서 실시간으로 업데이트된다.

그림 1: RTC의 Iteration 계획 화면

RTC 를 사용하게 되면서 가장 먼저 접하게 될 것은 바로 Iteration과 Iteration 계획이다. Iteration 은 시작 날자와 끝 날짜를 속성으로 갖고, (RUP 방식을 따른다면) phase 별로 그룹지을 수 있다. Iteration 계획의 개요 페이지는 앞서 언급한 모든 정보들을 담는다. 목표, 위험 요소, 평가 기준, 등등.. 그리고 테스트 계획 등 필요하다면 다른 페이지를 추가하는 것도 가능하다. 별도로 작성하던 Word 문서로부터의 해방이다.

사 용성 역시 두말할 필요가 없다. 마우스 조작만으로도 전체 요구사항 리스트(product backlog)에서 이번 Iteration 으로 작업 항목들을 끌어다 놓을 수 있다 (Drag & Drop). Jira에 GreenHopper 플러그인을 써서 꾸며놔 봐야 Eclipse 기반의 강력한 UI로 무장한 RTC는 비교조차 거부한다. 직접 양 플랫폼에서 동일 작업을 수행해보고 클릭 수를 세어보라. Jira로는 Iteration 간에 작업 항목들을 옮겨보고, resolve 시키는데 필요한 마우스 클릭과 웹 페이지 다운로드 수만 해도 상당함을 느낄 수 있을 것이다. 하찮은 장점이라 생각할 지 모르지만, 매일매일의 작은 차이가 쌓여 큰 플러스를 안겨줄 것이다.

장점 #2: SCM 기능 내장

앞 서 얘기했듯, 우리는 몇년 전에는 CVS를 사용했었다. 단순하지만 강력했다. 후에 Subversion (SVN) 으로 옮겨 타면서 향성된 속도와 바이너리 파일 처리, 리비전 넘버라는 사랑스런 개념들을 경험하게 되었다. 태그 다는 것은 더이상 필요 없었고, 각각의 빌드마다 리비전 넘버만 저장하면 끝!! 마법이 따로 없었다.

그러다 처음 RTC로 옮겨탄 1년 전에는 무척 혼란스러웠다. Commit, update 같은 익숙했던 개념은 어디로 사라지고, deliver 같은 생소한 개념들과 친해져야했다. 하지만 겨우 이런 작은 이슈로 쇼를 그만 두는 것은 어리석은 짓! 진화의 과정에선 꼭 거쳐야만하는 관문이 아닌가 말이다.

그래서 새 개념들에 대해 숙고하기 시작했고.. 와우!! 드디어 그 위력을 깨달았다. 변경 셋(change-set)과 흐름(flow), 리파지토리 서버가 관리해주는 내 워크스페이스(my workspace), 개인 빌드(private build)와 통합(integration) 등등..

자 신의 코드를 리파지토리에 체크인하는 작업을 SVN/CVS 와 비교해보겠다. 보통 우리는 코드 작성을 마치고 스스로 빌드까지 성공했다면 나름 최선을 다했다 생각하고 리파지토리 서버로 체크인한다. 하지만 잠시후 빌드 실패 통지가 날아온다. 아마도 최근에 수정한 동료의 코드를 미처 반영하지 못했을 것이다. 아니면 단순히 자신의 변경 사항 일부를 빼놓고 체크인했을 수도 있고.. 원인이야 얼마든지 있을 수 있다. 어쨌든 문제를 파악해 코드를 약간 더 수정한 후 빌드 & 체크인.. 앗!! 또 실패하고.. 몇 차례 반복하다보면 자잘한 변경에 대해선 더 이상 리비전 주석을 달지 않게 된다. (나중에 머지나 롤백이 필요할 때 혹독한 결과를 낳겠지만..)

전형적인 시나리오다. 그렇지 않은가?

그 에 반해.. Jazz는 리파지토리에 개인 워크스페이스을 만들어준다 (SVN의 브랜치와 유사하다). 이건 개인 PC의 로컬 공간이 아니라 서버 상에 존재한다. 이 공간에서의 변경은 상위 스트림(팀의 통합 스트림)에 영향을 미치지 않기 때문에, 개인은 언제든 부담없이 이 공간에 체크인하고 서버에 빌드를 요청할 수 있다.

빌드 엔진과의 통합이 무엇을 의미하는지 짐작되는가? 동료의 리뷰/승인 내용, 단순한 커맨트에서 질문들까지, 모든 변경 내용들은 자동적으로 당신의 작업 항목과 연결된다. 따라서 각 작업 항목은 어떤 논의 과정을 거쳐, 무슨무슨 파일/코드들이, 어떻게 변경되었는지에 대한 모든 정보를 담게 된다. 물론 역으로 변경 셋에서 관련 작업 항목을 찾아볼 수도 있다. 코딩 하나를 하더라도 관련된 모든 정황 정보(context)들 속에서 작업할 수 있는 환경이 마련되는 것이다.

그림 2a: 작업 항목에 변경 셋 연결짓기

그림 2b: 변경 셋과 연결된 작업 항목

개 인 빌드 성공했다면 여타 모듈들과의 모든 통합이 끝났고, 유닛 테스트 성공, 여타 룰들에 모두 다 만족했음을 뜻한다. 이제 개인의 변경 내용이 전체 빌드를 깨먹지 않을 거라고 안심해도 좋다. 그리고 다른 팀원에 의한 리파지토리 변경도 곧장 통보되기 때문에, 필요한 것들을 그 때 그 때 반영하기도 쉽니다. 이렇게해서 팀의 리파지토리를 엉망으로 만들어버리는 실수는 훨씬 줄어들게 된다.

이쯤이면 아마도 '우리도 Jira와 SVN은 연동해서 쓰고 있어' 라고 말할 사람들이 있을 것 같다. 좋다. 하지만 Eclipse 기반의 UI 를 간과해서는 안된다. 최근, 여전히 Jira 를 사용해 일하고 있는 친구를 봤는데.. 옆에서 지켜고 있는 것마져도 고통스러웠다. 수많은 클릭, 못생긴 인터페이스. 더욱이 정황 정보들의 통합 기능까지 흉내내려면, Mylyn 같은 추가 툴을 이용하거나, 아니면 모든 Jira 이슈 ID를 모든 리비전 커맨트에 복사해 넣도록 모든 개발자들을 다그쳐야 한다. 고통은 말할 것 없고.. 몇 달이나 지속할 수 있다고 보는가?

자! 이제 코드도 다 짰고, 빌드와 테스트도 잘 마쳤으니 팀 스트림에 넣어보자(deliver). 그 즉시 당신의 변경 사항을 다른 동료들이 볼 수 있게 된다. (앞서 설명한 것처럼) 이 과정에서 실수가 현격히 줄어드는 것 외에도, 당신의 작업에 의한 변경 사항(delta)을 확인하는 것도 무척 간단하다. 반면 Jira-SVN 조합에서는, 그 작업과 관련해 일어났던 모든 커밋(commit) 들을 찾아서 일일이 컴파일해본 후라야 무슨 일이 발생했는지 전체 그림을 볼 수 있다. 이것 그냥 '어렵다' 수준이 아니라, (별도의 툴 도움 없이는) 거의 불가능에 가깝다.

변경사항을 팀의 통합 스트림(한 단계 상위 스트림)에 딜리버리. 이로부터 통합이 완료된 완정된 증분을 얻게 되면, 똑같은 방식으로 다시 수정하고 상위 스트림에 밀어 넣고.  단순하면서도 강력하다.

규칙을 지정해 리더의 승인 없이는 누구도 딜리버리하지 하지 못하도록 강제할 수 있음도 잠시 가볍게 언급해 두고 싶다. Jazz 의 또 다른 강점이다. 하하.. 일일이 다 열거하기도 힘들다. (더 자세히 알고 싶으면 여기로)

장점 #3: 중앙 통제형 빌드 시스템 내장

나 는 꾀 오랫동안 CruiseControl 을 사용해왔다. 솔직히 이 시절엔 빌드 관련 정보를 관리하기 위해 별도의 wiki 를 두어야만 했다. 빌드 레이블마다 (빌드 성공, 검증 완료, 고객 수용 여부, 정식 릴리스 번호 등의) 빌드 상태 정보를 기록하고, 어떤 고객이 가져가 사용하고 있는지를 기록했던 것이다. 물론 수작업으로 작성할 수 밖에 었었으니 종종 오류가 발생하는 것은 피할 수 없었다. 특히 릴리스 직전의 분주한 시기에 집중적으로 ˆˆ; 그리곤 나중에 고객이 전화를 걸어 버그에 대해 문의해오면, 이럴 때를 대비해 개인 PC에 지우지 않고 남겨둔 이전 워크스페이스를 열어본다. (이 시점이면 보통 새로운 버전 개발에 착수했거나, 유지보수로 변경 사항이 많을 테니) 하지만 곧 수많은 컴파일 에러들을 마주하고는 그 워크스페이스를 지워버린다. 다시 정확한 리비전을 확인해보고 해당 소스들을 리파지토리로부터 체크 아웃.. 어라라. 그런데 그 당시 쓰던 라이브러리 X의 버전이 몇이었지? 이렇게 한 시간쯤 허비하고도 아직 워크스페이스 복원은 오리무중이다. 결국 포기하고, 잘 돌고있는 최신의 워스크페이스로 회귀. 헛!! 여기선 문제가 재현되지 않잖아! 젠x -_-;;

Jazz 는 변경 정보들, 관련 작업 항목, 테스트 성공/실패 여부 등의 빌드와 관련된 모든 정보들을 자동으로 취합해주고, 원클릭으로 당시의 워크스페이스를 정확하게 복원해준다.

그림 3: 빌드 결과 화면

빌드별 태깅도 가능해 나중에 검색도 된다. 테스터가 특정 빌드에 해당하는 결함을 등록할 때도 역시 원클릭. 가히 21세기 UI 라 하겠다. 조금씩 조금씩, 하루가 끝날 즈음엔 막대한 시간이 절약되었음을 느낄 수 있을 것이다.

사 용자 친화적 인터페이스 외에, 아키텍쳐적 관점에서도 장점이 크다. Jazz는 중앙 제어 서버와 빌드 엔진이 분리되어 있다는데.. 그래서 어떤 장점이?  C, C++, Visual Basic, Java, Flash 등을 혼용하는 제품을 개발하면서 continuous integration 을 적용하기가 얼마나 어려운지 잘 알 것이다. 제품의 조각조각을 각자에 맞는 이질적 플랫폼에서 빌드하고 테스트하고 이 결과들을 종합해야 한다. 모두를 한 곳에서 처리하려면 컴파일에 들어가는 시간만으로도 기가 꺾일 것이다.

Jazz 를 이용한다면, 하나의 서버에 여러 빌드 엔진들을 등록해 사용할 수 있다. 필요하면 수십개도 거뜬히 ^^ 각각의 엔진들은 서로 다른 플랫폼, 머신에서 동작하기 때문에 필요한 만큼 나누어 병렬 빌드가 되는 것이다. 멋지지 않은가?

Windows 용과 Linux 용 빌드를 병렬로, 그러면서도 제어와 결과 관리는 한 곳에서 이루어진다. (더 자세히 알고 싶으면 여기로)

장점 #4: 통합 플랫폼, 그리고 공개 표준

'괜찮네. 그래도 난 지금의 Jira-SVN-CruiseControl (또는 다른 무엇이 되었건) 솔루션으로도 족해. 뭐.. 그정도까진 좋지 않을 수 있지만, 그래도 잘 쓰고 있잖아." 혹시 아직도 이런 생각을 하고 있는가?

그 럼 난 이렇게 얘기해주고 싶다. '정말 큰 문제는 세세한 곳에서 숨어 있다(the devil is in the detail)'고.. 직접 써보고 그 차이를 스스로 느껴보길 권한다. Jazz는 설계 단계에서부터 의도적으로 이러한 모든 기능들을 조화롭게 융합시켜 놓았다. 서로간의 충분한 고려 없이 독립적으로 제작된 제품들을 나중에 합치려고 하는 것과는 분명한 차이가 있다. 후자의 방식은 필연적으로 이러저러한 한계에 봉착할 수 밖에 없다.

신규 인력에게 작업 환경을 세팅해주는 것도 훨씬 간단하다. 신참이 들어오면 IDE 와 모든 플러그인들, 모든 라이브러리들을 다운로드 받아 설치해야 해야 하고. 음.. 또 추후 원활한 작업을 위해선 몇몇 URL 들은 모두 북마크해둘 필요도 있다. Jazz가 아니더라도 물론 필요한 모든 프로그램들의 다운로드 링크와 설치 순서 같은 가이드라인을 만들 수는 있고 별로 어려운 일도 아니다. 하지만 정신없이 바쁜 와중에 (즉, 거의 언제나ˆˆ) 이들을 최신 상태로 유지하기란 결코 만만치 않다.

최 근에 신참 한 명이 팀에 합류했다. 내가 해준 일은 서버에 그 친구의 계정을 새로 추가하는 것 뿐이었다; Jazz 는 그 즉시 환영 메일을 보낸다. 신참은 자신의 PC에 RTC 클라이언트만 다운받아 설치하기만 하면 모든 것이 끝!! 워크스페이스, 프로젝트 일정/계획, 빌드, 다양한 리포트 등등.. 한 자리에서 클릭 몇 번으로 모두 확인할 수 있는 상태가 되는 것이다. 자! 자! 이제 일 시작하자. :-)

Jazz는 Open Collaboration Lifecycle 이라 불리는 오픈 표준을 제공하여, 다른 소프트웨어 밴더 누구라도 이와 연동되는 제품을 개발할 수 있게 문을 활짝 열어놓았다. 글을 쓰는 현 시점에도 이미 SVN, ClearCase, Microsoft SharePoint 등이 이 표준을 통해 연동되고 있는 상태이다. 만약 당신이 여러 소스에 분산되어 있는 데이터들을 수집/통합하는 이슈로 골머리를 앓고 있는 CTO라면 Jazz를 한 번 고려해보길 권한다. 이를 통하면 더 이상 특정 기술이나 소프트웨어 밴더 하나에 억매여 있을 필요가 없어진다.

나는 이것이 다양성을 가능케 하는 핵심이라 믿는다. 우리 회사는 지금 독일의 오스트라바에 위치한 연구소에서 새 프로젝트를 시작하는데 어려움을 겪고 있다. 다른 팀들과 같은 툴과 환경을 갖춰줘야 하는데.. 그쪽 사람들은 자신들에게 익숙한 툴들을 더 이상 쓰지 못하는 처지이고, 새로운 툴들의 라이선스를 취득해야만 한다. 정상화가 되기까지는 시간이 꾀 걸릴 것이다.

관리자 입장에서도 문제가 많다. 부서나 프로젝트마다 완전히 다른 환경을 쓰게 된다면 여러 부서와 여러 프로젝트들을 어우르는 지표를 도저히 뽑아볼 수가 없는 것이다.

그래서 요즘 우리는 파일럿 프로젝트를 하나 진행 중이다. 그 결과로 Jazz 를 이용해 기존의 Jira 와 연계시키고, 서로 다른 소스들로부터 데이터들을 취합해 지표를 뽑아내는 것을 시연해볼 생각이다.

장점 #5: 풍부한 자료와 훌륭한 기술 지원

Jazz 와 Rational Team Concert 는 이제 갓 시장에 데뷔한 제품답지 않게, 이미 수준 높은 자료들이 많이 공개되어 있다. 몇 가지 나열해보자.

* Jazz 의 기본 기능: https://jazz.net/pub/capabilities/

* Jazz 란 무엇인가: https://jazz.net/learn/LearnItem.jsp?href=content/docs/welcome/what-is-jazz.html

* Jazz 동작 시연 by Erich Gamma: Jazz Update from EclipseCon with Erich Gamma

* 다른 동영상 자료들: https://jazz.net/learn/videos/videos.jsp

* 오픈 포럼: open forums at jazz.net - 가입만 하면 아주 색다른 지원을 받을 수 있을 것이다 (이미 Eclipse 커뮤니티에 익숙한 사람은 제외). 내가 겪고 있는 문제에 대해 전혀 이해하지 못하고, 이것저것 끊임없이 캐묻기만 하는.. 그런 속터지는 고객 지원 부서의 친구들은 잊자. 이 포럼에서는 Jazz의 개발자들이 직접 여러분을 상대해준다. 아마 이렇게 빠르고 정확한 지원 서비스는 처음일 것이다.

   

-- Roman Smirak, Tieto --