eBay의 이클립스, Part 2: 실전 eBay 플러그인

문서 옵션 JavaScript가 필요한 문서 옵션은 디스플레이되지 않습니다. 영어원문  제안 및 의견 피드백

난이도 : 중급

Michael Galpin, 개발자, eBay

2008 년 7 월 22 일

이클립스는 자바(Java™) 개발자들이 있는 곳이면 어디에서나 사용하는 최초의 통합 개발 환경(IDE)이 되었습니다. 이클립스는 모든 시스템에 적합한 만능 프로그램은 확실히 아니지만, 플러그인 아키텍처를 이용해 우리가 필요로 하는 특징을 추가할 수 있습니다. 이클립스는 이베이(eBay)처럼 거대한 조직에서조차도 매우 중요하게 사용합니다. 이베이 같은 거대한 조직은 그 조직에만 있는 특별한 요구 사항이 존재하기 마련입니다. 이클립스는 이런 요구에 대한 해결책으로 적합할 뿐만 아니라, 거대한 조직 전체적으로 사용할 수 있는 규모를 갖는 프로그램도 쉽게 만들 수 있습니다. "이베이의 이클립스"는 2부로 구성되며, 그 중 두 번째인 이 글에서는 이베이의 조직 관점에서 요구 사항을 살펴보고, 이 요구 사항을 만족시키는 데 이클립스를 어떻게 사용했는지도 함께 살펴보겠습니다. 우리는 이베이가 이클립스를 사용한 방법에 집중하겠지만, 여러분의 조직에도 비슷한 전략을 사용할 수 있습니다.

이번 글은 독자들이 이클립스에 기본적으로 친숙하다고 가정한다. 이클립스 V3.2와 JDK 5.0이나 그 이상 버전(참고자료에 있는 링크 참조)에 기반을 둔 이베이 개발 환경(EDE)에 대해 얘기할 것이다. HTML, 자바스크립트와 CSS를 포함한 웹 개발에 친숙하면 매우 유용하지만 필수조건은 아니다.

이베이의 도전

소프트웨어 개발은 모양도 크기도 모두 다르기 마련이다. 취미로 개발을 하는 사람도 많다. 또한 컨설팅할 수 있는 좋은 사업도 된다. 그렇기 때문에 매우 작거나 매우 큰 조직에서 모두 대접 받을 수 있다. 개인적으로 소프트웨어를 개발할 때는 좋아하는 도구를 선택하면 된다. 그리고 좋아하는 방식으로 코드를 작성하면 된다. 코드를 계속 따라가면서, 주기적으로 백업을 할 수도 있다. 그러나 다른 사람들과 일을 시작하자마자 일은 더 복잡해진다. 이 방정식은 수천 명이 있는 조직에서 개발을 하게 될 때 더 복잡해진다. 운 좋게도 이클립스는 이러한 도전에 민첩하게 대응한다. 이클립스는 표준화된 막강한 도구를 제공한다. 플러그인 아키텍처에 의해 제공되는 확장 가능성은 그 크기에 관계 없이 여러분의 조직이 구현한 기능을 더 쉽게 추적할 수 있게 해준다. 이 내용을 증명하기 위해 이베이가 자사의 요구 사항을 만족시키는 데 이클립스를 어떻게 사용했는지 살펴볼 생각이다.

이베이 조직

대부분 이베이에 대해 들어봤을 것이다. 매년 수백만 명이 물건을 사고 파는 데 이베이를 사용한다. 이베이 시장은 매초 막대한 수의 트랜잭션을 처리하는 엄청나게 변화가 많은 전자 상거래 플랫폼이다. 이런 요구사항을 만족시키려고 이베이는 수백만 줄의 코드를 기계적으로 찍어 내는 엔지니어 수천 명을 고용한다. 이로 인해 대규모 개발 관리, 소스 코드 통합 관리, 코드 일관성 및 품질 생성 같은 몇 가지 도전에 직면했다. 각 도전에 대해 알아보고, 이베이가 이 도전을 해결하는 데 이클립스를 어떻게 사용했는지 살펴보자.

대규모 개발

모든 엔지니어가 수 많은 코드를 생산한다. 이렇게 만들어진 코드는 한 번만 쓰고 버리는 코드가 아니다. 코드를 개발한 조직과 동일한 거대한 조직이 이 코드를 직접 유지해야만 한다. 이 말은 대부분 한 개발자에 의해 작성된 동일한 코드가 다른 다수의 엔지니어에 의해 쓰이고, 수정됨을 의미한다. 이 정도 규모라면 코드 조직, 코딩 규약, 도구를 표준화하는 방법밖에 없다. 할 수 있는 모든 것을 표준화해야 한다.

엄청난 규모의 코드 기반을 둔 조직이 직면하는 첫 번째 문제는 코드를 어떻게 조직화할 수 있느냐다. 수천 개의 패키지와 클래스가 있는, 믿을 수 없는 의존성 목록을 볼지도 모른다. 올바른 클래스패스로 프로젝트를 구성하는 것만 해도 얼마나 어려운지 상상할 수 있다. 개발자 수천 명이 개발을 시작하는 데 얼마나 걸릴지 이제 상상이 갈 것이다. 유지 보수나, 환경을 구축하려고 기존 코드를 받아와 컴파일하는 데만 해도 엄청난 시간을 허비하게 된다.

이 문제를 이베이에서는 이클립스 플러그인을 사용한 자동화를 통해 해결했다. 이베이는 꽤 복잡하고 독자적인 XML 설정 메커니즘을 사용해 프로젝트와 프로젝트 간 상호 의존성을 계속 추적한다. 각 파일은 프로젝트에 대한 코드를 조직하고, 해당 프로젝트가 의존하는 다른 프로젝트를 지정한다. 이 파일에 대한 예를 Listing 1에서 볼 수 있다.

                
<project
    type='JAR' 
    path='v4samplecode' 
    javac.source='1.5' 
    javac.target='1.5'
    hasV4Js='true'
    hasV4Css="true"
    >
    <src>
        <dir path='src'/>
    </src>
    <dependencies>
        <project name='GlobalEnvironment'/>
        <project name='DocumentFramework'/>    
        <project name='DarwinTestUtils'/>
        <project name='DarwinCoreUtils'/>
        <project name='DarwinCoreComponents'/>
        <project name='DarwinCoreApp'/>
        <project name='DarwinCoreAppResources'/>
        <project name='V4DeCodeContent' />
        <project name='DarwinTools' />
        <project name='DarwinCodeGenImpl' />
        <library name='DSF-Foo' />
        <library name='EbayResources'/>
        <project name='EbayUrlServices'/>
        <library name='Darwin'/>
        <library name='DarwinTests'/>
        <library name='Dsf'/>
        <library name='Kernel'/>
        <library name="KernelTestAPI"/>
        <library name='xml'/>
        <library name='commons-jxpath'/>
        <library name='icesoft-sdk'/>
        <library name='junit'/>
        <library name='servlet-api'/>
        <library name='jsp-api'/>
        <library name="jakarta-taglibs-standard"/>
    </dependencies>
</project>

이 파일은 이베이 플러그인에서 이클립스 프로젝트(.project와 .classpath 파일들)를 생성할 수 있게 해주고, 클래스패스에 있는 다른 이클립스 프로젝트를 참조하게 해준다. 분명히 이 파일은 매우 중요하며, 이베이는 이 파일을 수정하고, 내용을 시각화해 주는 플러그인을 만들었다.

XML 파일은 소스 컨트롤(차후에 더 자세히 알아보자)에 체크인할 수 있으며, 그러고 나서 이베이 플러그인이 모든 이클립스 프로젝트를 생성하고, 개발자의 작업공간(workspace)으로 가져가 준다(import). 개발자들은 그림 2에서 볼 수 있듯이 버튼 하나만 클릭하면 된다.

툴팁(tool tip)에서 볼 수 있는 것처럼, 빌드 플러그인은 많은 일을 한다.

OK를 클릭하면 이클립스 프로젝트를 모두 생성하고 빌드를 수행한다. 상대적으로 작은 규모의 작업공간 예를 아래 그림에서 볼 수 있다.

엔지니어가 이 모든 프로젝트를 직접 생성해 나가면서 스스로 구축해야 한다면 얼마나 고통스러울지 상상이 갈 것이다. 이러한 거대한 코드 기반으로 이루어지는 작업은 복잡성을 지닌다. 이베이 해결책은 모든 경우에 대해 완전한 해결책(silver bullet)이 되지는 않는다. 상호 의존성을 갖는 수많은 프로젝트를 생성해, 모든 프로젝트를 실행 가능하도록 빌드하는 것은 만만히 볼 일이 아니다. 이베이 플러그인은 이 모든 것을 완벽히 자동화했다. 그렇지만 대규모 프로젝트를 이클립스로 작업해 봤다면, 잘 조직했다고 해서 모든 문제를 해결할 수 없다는 점을 알 것이다. 수많은 파일과 클래스가 문제가 될 수 있다. 이 문제는 이클립스 플러그인의 도움을 받아 해결할 수 있는 또 다른 도전이 된다.

위로

Megajars

위에서 봤듯이, 대규모 코드 기반에서 수많은 클래스를 사용해 프로젝트를 준비하는 일은 쉬웠다. 소스 파일 수십만 개를 이클립스에서 실행해 본 적이 있는가? 실행하면, 시스템에 엄청난 부담을 주고, 많은 메모리를 필요로 해(이클립스에서 out of memory 예외를 받아 본 적이 있는가?), 시스템이 극단적으로 느려지는 원인이 된다. 이런 경우 시스템에서 실제 소스 코드를 받아 오는 대신 컴파일된 코드로 연결하는 것이 더 좋은 방법이 된다. 이베이는 Megajars라 부르는 플러그인을 사용해 이 문제를 해결한다.

실제로 해결책은 매우 간단하다. 특정 프로젝트가 12개 혹은 프로젝트 자체적으로 의존성 트리를 갖는 다른 프로젝트에 의존하고 있다고 생각해 보자. 프로젝트에는 어떠한 변경도 줄 수 없다고 예상해 보자. 소스 코드를 모두 컴파일해 JAR로 만들고 싶다. 이클립스에서 코드에 대한 JavaDoc을 제어할 수 있는 효과를 잃고 싶지 않지만, 이클립스는 우리 목적에 맞게 소스 코드와 JAR를 쉽게 연계해 준다.

이제 Megajars가 어떻게 동작하는지 살펴보자. 빌드 대상이 되는 코드 집합을 제공하면, 이베이 빌드 시스템은 이에 대응하는 Megajar를 제공한다. 빌드 플러그인은 소스 코드 대신 Megajar로 작업공간을 다시 빌드한다. 물론, 이 모든 일을 플러그인으로 실행한다. 그림 5에서는 Megajars 뷰를 보여준다.

Megajar 아이콘을 클릭하면 Megajar 프로세스가 시작된다. 어떤 일이 일어났는지 정확하게 보여주는 정보 상자를 받게 된다.

이 내용은 전체적으로 보면 단지 한 단계에 불과하지만, 매우 가치 있는 일이다. 컴퓨터에 부담을 제거해 주며, 더 빠르게 시스템을 빌드하고, 배포해 준다. 이 기능은 시간을 절약해 주고, 느린 시스템 때문에 좌절에 빠진 개발자를 구해 준다. 요점은 코드 조직 관점에서 보면 거대한 코드 관리에 진정한 도움을 준 것이다. 이베이 팀은 대규모 코드 기반으로 작업하는 개발자를 도와주는 몇 가지 다른 도구를 만들었다. 이러한 도구들은 이베이 개발자들이 대규모 코드 기반으로 작업 시에 정확한 길로 더 쉽게 찾아갈 수 있도록 시각화를 사용한다.

위로

프로젝트 규모 관리하기: 시각화와 검색 도구

모든 소프트웨어 애플리케이션에는 상대적으로 더 중요한 특정 파일/클래스가 있다. 많은 수의 클래스를 포함하는 코드가 될 때도 있다. 이러한 클래스들은 찾아내기 더 어렵다는 것이 큰 차이점이다. 다행스럽게도 이 문제는 도구의 도움을 받을 수 있는 유형의 문제다.

1부에서 이베이의 V4 아키텍처에 대해 얘기했다. V4에는 대규모 웹 애플리케이션 개발의 도전을 해결해 주는 이베이가 개발한 프론트엔드 프레임워크가 나온다. V4의 가장 중요한 구성 요소 중 하나로 (별로 놀라지 않겠지만) 애플리케이션 스펙(application spec)이라는 개념이 있다. 단일 프로젝트에서 페이지 자체적으로 내용, CSS, 자바스크립트 등을 포함하는 엄청난 크기의 웹 페이지를 만들 수 있다. 이런 다양한 페이지와 자원 모두는 많은 수의 클래스를 가져갈 수 있지만, 이 모든 자원은 단일 애플리케이션 스펙으로 구성된다. 다행히도 이베이는 아래 그림에서 볼 수 있듯이, 애플리케이션 스펙을 찾고 관리하는 도구인 Application Explorer를 만들었다.

Application Explorer는 주어진 프로젝트에 대해 빠르게 애플리케이션 스펙을 식별할 수 있고, 각 애플리케이션 스펙의 메타데이터를 시각화해 보여준다. 일반적인 이클립스 익스플로러(Eclipse explorer)의 프로젝트 위에서 간단하게 마우스 오른쪽 버튼을 클릭해 접근할 수 있다.

애플리케이션 스펙은 V4 아키텍처의 중요한 고수준 객체다. 애플리케이션은 다수의 페이지를 갖게 될 수 있다. 각 페이지는 div, span, form 등을 추가하는 저수준 API로 구축될 수 있다. 그렇지만 V4는 컴포넌트 아키텍처이며, 많은 페이지가 실제로 이런 컴포넌트를 사용해 구축된다.

컴포넌트 재사용은 이베이 개발자들의 생산성 향상에 많은 도움을 준다. 컴포넌트 재사용에는 몇 가지 중요한 핵심이 있다. 일단 분명한 점은 다양한 시나리오에서 재사용할 수 있는 컴포넌트를 가지고 있어야 한다는 점이다. 또한 컴포넌트에 대한 방대한 카탈로그(catalog)가 필요하다. 우리가 쉽게 무시하지만 중요한 핵심은 모든 컴포넌트를 검색할 수 있어야 한다는 것이다. 여기서도 이베이는 아래 그림처럼 Component Viewer라는 이클립스 플러그인을 만들어 이러한 필요성을 충족시켰다.

Explorer는 이클립스 작업공간에 포함된 프로젝트에 있는 모든 컴포넌트를 프로젝트 단위로 구성해 보여준다. Explorer를 쭉 훑어보면서 필요한 컴포넌트를 찾아 보고, 프로젝트 의존성 플러그인(그림 1 참조)을 사용해 프로젝트 의존성에 적용할 수 있다.

Component Viewer는 이베이 애플리케이션에서 사용하는 특정 타입의 클래스를 찾는 것을 도와준다. 이베이는 결국 클래스, 특히 라이브러리 클래스 검색이라는 좀 더 일반적인 이슈에 대한 도구를 갖게 되었다. 이베이 엔지니어는 DRTW(Don't Reinvent The Wheel: 바퀴를 다시 발명하지 말라)에 대한 명백한 믿음을 갖고, 오픈 소스 라이브러리를 공격적으로 활용한다. 이러한 방법은 수 많은 라이브러리와 라이브러리 클래스를 필요로 한다. 이러한 클래스를 검색하는 도전이 발생했고, 다시 한 번 이베이는 이 도전 해결을 도와주는 플러그인으로 JAR Explorer를 만들었다.

이 도구는 시각화를 통한 통찰력(insight)을 제공해 개발자가 필요로 하는 클래스를 찾을 수 있도록 도와준다. 이베이는 자사 개발자를 도와주기 위해 모든 플러그인을 만든 것이다. 이클립스에서는 많은 플러그인을 이용할 수 있기 때문에, 필요한 부분을 찾아 이를 충족시켜 주는 플러그인이 이미 만들어져 있는지 간단한 식별을 통해 조직에 적용할 수 있다. 이베이에서 플러그인을 적용한 몇몇 상황을 함께 살펴보자.

위로

이클립스 플러그인 활용하기

각 조직마다 특별한 필요성을 가지고 있다고 해도 과언이 아니다. 이클립스는 조직의 요구를 해결해 주는 플러그인을 제작할 수 있는 플랫폼을 제공한다. 이베이와 같은 특별한 요구 사항이 있는 조직의 경우에 문제를 어떻게 해결했는지 살펴 봤다. 모든 요구 사항이 절대적으로 특정 조직에만 맞춰진 것은 아니다. 각 조직에 특화된 경우도 있지만, 대부분의 경우 다른 조직에서도 필요한 공통적인 요구다. 이렇게 공통적인 요구사항인 경우, 이 문제를 해결해주는 이클립스 플러그인은 이미 만들어져 있을 것이다. 이 방법이 이베이에서만 매력적인 것처럼 볼 수도 있겠지만, 이클립스와 플러그인 생태계를 사용할 수 있는 건 이베이에서만 할 수 있는 유일한 방법은 아니다.

이베이 개발자들은 다른 어느 곳에서보다 많은 공통된 일을 한다. 개발자들이 애플리케이션 서버로 개발을 할 필요가 있을 수 있다. 이베이의 경우, 아파치 제로니모(Apache Geronimo)를 기본으로 하는 IBM® WebSphere® Application Server Community Edition을 사용한다. 자연스럽게 이베이는 아래 그림처럼 애플리케이션 서버를 관리하고, 배포해주는 서버 뷰와 같은 플러그인을 사용하는 이클립스 WTP(Web Tools Project)를 활용한다.

"recycling the server"에 대한 메시지를 포함하는 Megajar 대화상자(그림 6 참조)를 기억할지 모르겠다. 이 메시지가 대상 서버 상태를 의미한다. WTP의 오픈 소스 특징은 이베이가 만든 플러그인과 자동으로 미리 구성해 놓은 서버 인스턴스를 생성하는 WTP가 상호작용할 수 있게 해준다. 이런 일을 하는 데 개발자들이 시간을 허비할 필요가 전혀 없다. 서버에서 코드를 실행하는 일은 모든 웹 개발자의 공통된 작업이다.

어느 규모의 조직에서든 모든 개발자의 또 다른 공통된 일은 소스 코드를 관리하는 일이다. 이베이처럼 규모가 큰 조직에서는 어떻게 소스 관리를 처리하고, 또 여기서 이클립스는 어떤 역할을 수행하는지 함께 살펴보자.

위로

소스 컨트롤 통합: Rational ClearCase 플러그인

소스 코드 관리는 잘 알려진 문제이며, 솔루션이 많다. 이클립스는 기본적으로 CVS를 포함한다. 이베이에서는 IBM Rational® ClearCase®를 사용한다. EDE에는 아래 그림처럼 ClearCase 플러그인이 설치되어 있다.

ClearCase 같은 도구와의 통합은 이클립스 같은 IDE를 사용하는 가장 큰 이유 중 하나다. ClearCase 플러그인은 파일에 대한 쉬운 체크인, 체크아웃처럼 우리가 소스 코드 관리 도구에 바라는 모든 일을 해준다.

기업에서 어느 소스 코드 관리 도구를 선택하는지 문제가 될 건 없지만, 이번 기회에 ClearCase의 이클립스 플러그인을 사용해보자. 이클립스의 이러한 특징이 자바 개발을 넘어 이클립스의 인지도가 급격하게 높아진 이유가 된다. 대규모 시스템에서 소스 컨트롤은 어려운 문제지만, 이클립스와 소스 코드 관리 통합으로 많은 도움을 받을 수 있다. 이베이의 규모 때문에 직면한 또 다른 과제는 소스 코드의 일관성을 관리하는 것이다. 일관성 관리는 이클립스 플러그인을 사용해 문제를 해결할 수 있는 또 다른 도전 영역이 된다.

위로

코딩 표준 강요하기: FindBugs

정적인 분석은 대규모 코드 기반 관리를 돕기 위해 많은 조직에서 사용되는 가치 있는 도구다. FindBugs 오픈 소스 프로젝트는 자바 코드에 대한 정적 분석 도구로 인기가 높고, 물론 이클립스 플러그인을 제공한다. 이베이는 모든 소스 코드에 FindBugs를 적용해 사용한다. EDE는 개발자가 자체적으로 실행하고 모든 문제를 찾아내 수정할 수 있도록 FindBugs를 통합했다. 간단하게 클래스, 패키지나 프로젝트에 대해 실행할 수 있다.

FindBugs는 소스에서 발생할 수 있는 공통적인 문제를 식별해낸다. Listing 2를 살펴보자.

                
import java.util.HashSet;
import java.util.Set;

public class DataStruct {

    private int id;
    private String code;
    
    public DataStruct(int id, String code){
        this.id = id;
        this.code = code;
    }
    public boolean equals(DataStruct other){
        return (this.id == other.id  && 
                this.code.equalsIgnoreCase(other.code));
    }
    public int hashCode(){
        return 1000*id + code.hashCode();
    }

    public static void main(String[] args) {
        Set<DataStruct> data = new HashSet<DataStruct>();
        data.add(new DataStruct(24, "ESX"));
        data.add(new DataStruct(24, "ESX"));
        System.out.println(data.size());
    }
}

메인 메서드를 실행했을 때 무슨 일이 생기는가? 1이 출력되기를 기대하겠지만, 대신 2가 출력됐다. 왜 이런 결과가 나왔나? FindBugs를 실행해 왜 이런 상황이 발생했는지 밝혀보자.

아, FindBugs는 우리가 equals(DataStruct) 메서드를 정의했지만, 실제로는 여전히 Object.equals(Object)를 사용하고 있다고 말해준다. 우리는 Object.equals(Object) 재정의를 원하는데, 메서드 선언부 실수로 잘못 선언했다. 이러한 종류의 버그는 쉽게 생길 수 있지만, 이베이에서는 현명하게 FindBugs를 사용했기 때문에 이러한 버그가 훨씬 적게 발생한다.

위로

결론

이베이가 직면한 수 많은 도전을 해결하는 데 이클립스를 어떻게 사용했는지 함께 살펴봤다. 이러한 도전 대부분은 이베이의 환경에서만 특별하게 나타난다. 이베이는 항상 새로운 소프트웨어(웹 애플리케이션)를 발표하는 거대한 개발 조직이다. 이클립스는 이베이가 개발한 플러그인으로 이베이의 독특한 요구를 해결할 수 있게 해줬다. 이런 요구는 이베이에만 나타날 뿐만 아니라, 엄청난 수의 이클립스 플러그인을 사용하면 다른 조직의 좀 더 일반적인 요구에도 도움을 줄 수 있다. 여러분의 조직이 같은 패턴을 따라 할 수 있다면, 조직에 특화된 플러그인을 개발하고, 또는 기존 플러그인을 효과적으로 사용해 보자. 이 기술은 이클립스를 사용하는 조직을 생산적으로 만드는 데 도움이 된다.

참고자료

• 이베이 프로그래머가 직면한 도전을 이해하기 위해 "eBay의 이클립스, Part 1: eBay 아키텍처에 맞춘 이클립스"로 이번 연재를 시작하자.
  
  
• FindBugs를 사용하는 방법은 "FindBugs, Part 1: Improve the quality of your code"에서 도움을 받을 수 있다.
  
  
• "사람을 위한 자동화: Eclipse 플러그인으로 코드 품질 높이기"에서 이클립스에서 제공하는 다른 정적 분석 플러그인을 찾아보자.
  
  
• "Java theory and practice: Testing with leverage"에서 전체적으로 코드에 있는 문제 클래스들을 FindBugs가 어떻게 통합해 나가는지 배워보자.
  
  
• "Eclipse, WTP, Derby로 웹 애플리케이션 구현하기"에서 이클립스 WTP의 장점을 느껴보자.
  
  
• ClearCase를 사용해본 적이 있는가? "The art of ClearCase deployment"에서는 ClearCase 사용 방법에 대해 대부분 다루고 있으니 읽어보자.
  
  
• 이클립스 플러그인을 만드는 작업은 우리가 생각하는 것보다 쉽고, 특히 템플릿을 사용하면 더 쉽게 만들 수 있다. "Building template with the Eclipse Plug-in Development Environment"에서 더 많은 내용을 배워보자.
  
  
• "Eclipse 플러그인 개발하기"에서 자체적인 이클립스 플러그인을 만드는 방법에 대해 배워보자.
  
  
• 이클립스로 웹 개발을 할 수 있는가? "Eclipse용 Ajax Toolkit Framework"를 읽어보기 바란다.
  
  
• "Eclipse 마법사를 이용한 빠른 개발"을 읽고 이클립스 마법사를 만들어 자신의 개발을 시작하자.
  
  
• "How did eBay start?"에서 간단히 요약된 이베이의 역사에 대해 읽어보자.
  
  
• Simon Willison의 "A (Re)-Introduction to JavaScript"를 읽어보자.
  
  
• "Eclipse 추천 도서 리스트"를 확인해보자.
  
  
• 한국 developerWorks에서 모든 이클립스 기사를 열람해보자.
  
  
• 이클립스로 새로운 일을 할 생각인가? developerWorks의 "Eclipse Platform 시작하기"를 읽고 이클립스의 기원과 아키텍처를 배워보고, 어떻게 플러그인이 이클립스를 확장하는지 알아보자.
  
  
• IBM developerWorks의 Eclipse 프로젝트 리소스를 검색해 이클립스 기술을 향상시키자.
  
  
• developerWorks 포드캐스트에서 소프트웨어 개발자들의 흥미로운 인터뷰와 토론을 들어보자.
  
  
• developerWorks의 기술 행사와 웹 캐스트에 주의를 기울이자.
  
  
• developerWorks 온디맨드 데모를 보고 무료로 IBM과 오픈 소스 기술 및 제품 기능에 대해 배우자.
  
  
• IBM 오픈 소스 개발자들이 흥미로워하는 전 세계에 걸친 최신 컨퍼런스, 전시회, 웹 캐스트와 기타 다양한 행사가 있는지 확인하자.
  
  
• 오픈 소스와 IBM 제품을 사용해 개발을 도울 수 있도록 광범위한 최신 정보, 도구, 그리고 프로젝트가 업데이트되는 한국 developerWorks의 오픈 소스 존을 방문해보자.
  
  

• IBM alphaWorks에서 최신 이클립스 기술 다운로드를 확인하자.
  
  
• 이클립스 플랫폼과 이클립스 기반 관련 프로젝트를 다운로드하자.
  
  
• IBM 제품 평가판을 다운로드하고, DB2®, Lotus®, Rational®, Tivoli®, WebSphere® 같은 애플리케이션 개발 도구와 미들웨어 제품을 직접 다뤄보자.
  
  
• 다운로드나 DVD로 이용할 수 있는 IBM 시험판 소프트웨어를 다음 오픈 소스 개발 프로젝트에 도입해보자.

• 이클립스 플랫폼 뉴스 그룹은 이클립스에 관련된 질문을 토론하는 첫 번째 장소가 될 수 있다(이 링크를 누르면 기본 유즈넷 뉴스 리더 애플리케이션이 실행되고 eclipse.platform 뉴스그룹이 열린다).
  
  
• 이클립스 뉴스 그룹은 이클립스를 사용하고, 확장하는 데 흥미가 있는 사람을 위한 많은 참고자료를 갖고 있다.
  
  
• developerWorks 블로그에 들어가 developerWorks 커뮤니티의 토론에 참여하자.
  
  

필자소개

		Michael Galpin은 1998년부터 전문적으로 자바 소프트웨어를 개발하고 있으며 이베이에서 근무중이다. 캘리포니아 공대에서 수학을 전공하였다.

기사에 대한 평가

보다 나은 서비스를 제공하기 위함이오니 잠시 짬을 내어 이 양식을 제출하여 주십시오. 귀하께서 원하시는 정보를 얻었습니까? 예 아니오 잘 모르겠음   이 페이지 개선을 위한 의견을 주십시오:   이 정보가 얼마나 유용했습니까? (1 = 전혀 도움이 되지 않음, 5 = 매우 유용함) 1 2 3 4 5

이 문서 북마킹 하기 mar.gar.in naver eolin del.icio.us

위로