[토비의 스프링 3.1] Vol.1 스프링의 이해와 원리 - 스프링 프로젝트 시작하기 (2)

9.2) 개발도구와 환경

JavaSE와 JavaEE

• JavaSE (Java Standard Edition)/JDK (Java Development Kit)
  1. 스프링 3.0은 JavaSE 5 버전에서 추가된 새로운 언어와 문법의 특징을 최대한 활용해서 개발됐기 때문에
     기본적으로 JDK 5.0 또는 그 이상을 필요로 한다.
  2. 또 일부 기능은 JDK 6.0의 API를 이용해 개발된 것도 있다.
• JavaEE (Java Enterprise Edition) /J2EE (Java 2 Enterprise Edition)
  1. 스프링 3.0이 사용될 자바 엔터프라이즈 플랫폼으로는 J2EE 1.4 버전이나 JavaEE 5.0이 필요하다.
     
  2. 스프링 자체는 JDK 6.0과 JavaEE 5.0을 기준으로 개발됐지만
     주요 기능은 JDK 5.0에서 동작하는 J2EE 1.4 버전과 호환되게 제작되어 있다.
  3. 다만 J2EE 1.4 버전 서버를 사용할 때는 JDK 5.0에서 동작하는지 반드시 확인해야 한다.

IDE

• 요즘은 대부분 개발 툴을 떠나지 않고도 개발 과정에서 필요한 모든 일을 처리할 수 있도록 만들어진 통합개발환경을 사용한다.
  1. 스프링 애플리케이션은 자바 5 또는 그 이상의 언어를 지원하는 자바 개발도구와
     스키마를 지원하는 XML 편집기 정도만 있다면 어떤 개발환경에서는 불편 없이 개발이 가능하다.
  2. 여기에 ANT나 Maven 같은 빌드 툴을 지원하고
     톰캣이나 자바 서버로 바로 배포해서 실행해볼 수 있는 환경이라면 더할 나위 없을 것이다.
  3. 자바의 표준 IDE로 여겨지는 이클립스를 비롯해서 넷빈즈, Intelli IDEA 등이 대표적인 IDE로 꼽힌다.
     이 세 가지 IDE 모두 자바 엔터프라이즈 개발을 지원하며 스프링 개발을 편하게 도와주는 스프링 지원 기능도 갖고 있다.

SpringSource Tool Suite

• 스프링 애플리케이션 개발을 위한 IDE로 이클립스를 선택했다면, 스프링 개발업체인 스프링소스가 직접 만들어 제공하는
  이클립스의 확장판인 SpringSource Tool Suite(STS)의 사용을 고려해보자.
  1. STS는 최근 이클립스를 기반으로
     주요한 스프링 지원 플러그인과 관련 도구를 모아서 스프링 개발에 최적화되도록 만들어진 IDE다.
  2. 이클립스와 같이 플러그인 방식을 지원하는 툴을 사용하면 원하는 기능을 필요에 따라 추가할 수 있지만
     각 플러그인과 아클립스의 버전을 호환되도록 계속 관리해야 하는 불편함이 있다.
  3. STS는 스프링 팀이 매번 베타 버전, RC 버전을 거쳐가면서
     플러그인의 호환성 문제나 버전 이슈를 충분히 검증해주기 때문에 STS 정식 버전을 안심하고 가져다 바로 사용할 수 있다.
     그러므로 스프링소스가 제공하는, 플러그인 조합이 완료된 STS를 사용하는 편이 여러모로 유리하다.
• STS에는 이클립스의 기본 설치 버전에는 없는 스프링 개발지원 플러그인들이 기본적으로 포함되어 있다.
  1. SpringIDE는 스프링 개발에 유용한 기능을 제공하는 플러그인의 모음이다.
     스프링 프로젝트와 설정파일 생정 위저드, 편리한 스프링의 XML 설정파일 에디터,
     빈의 의존관계 그래프, 네임스페이스 관리 기능 등의 편리한 기능과 도구를 제공한다.
  2. 이 중 XML 설정파일 에디터를 제공하기 때문에 클래스 이름이나 참조하는 빈의 이름을
     실시간으로 검증해서 오류를 확인해주기 때문에 오타로 인한 에러의 위험을 사전에 방지해준다.
     
  3. 그뿐 아니라 클래스 이름이나 프로퍼티 이름을
     자바 편집기 내의 자동완성 기능과 비슷하게 찾을 수 있게 해주어 매우 편리하다.
  4. 또한 STS에는 SpringID 외에도 AJDT라는 AspectJ 개발 플러그인이 함께 설치되므로
     SpringIDE는 AOP의 포인트컷이 적용되는 대상 빈을 설정파일 안에서 한눈에 확인할 수 있도록 도와준다.
  5. 이외에도 스프링 애플리케이션의 서버 배치 등과 같이, 스프링 프레임워크에 대한 지원을 포함한 다양한 기능을 제공한다.
     또 스프링 개발 시 자주 발생하는 예외에 대한 지식베이스를 검색해볼 수 있는 기능도 제공한다.
  6. STS를 사용하면서 추가적으로 필요한 플러그인은 호환성 문제만 주의하면 얼마든지 설치해서 사용할 수 있다.

라이브러리 관리와 빌드 툴

• 애플리케이션의 아키텍처를 결정하고 사용 기술을 선정하고 나면 애플리케이션 프로젝트를 IDE에 구성할 차례다.
  이때 가장 어려운 부분은 바로 필요한 프레임워크 모듈과 라이브러리 파일을 선택해서 프로젝트의 빌드 패스에 넣어주는 일이다.
  1. 스프링은 20개에 가까운 세분화된 jar 모듈이 존재하며 스프링이 직접 참조하는 라이브러리를 100개가 넘는다.
     스프링이 직접 참조하지 않는 프레임워크나 라이브러리까지 포함하면
     스프링으로 만드는 프로젝트에 포함될 가능성이 있는 라이브러리의 종류는 수백여 개에 달할 것이다.
     또한 라이브러리마다 여러 개의 버전도 존재한다.
  2. 하지만 20개의 모듈과 100여 개의 직접 참조 라이브러리가 있지만 그 모든 모듈과 라이브러리가 매번 다 쓰이는 건 아니다.
     필요한 기능과 사용하기로 결정한 기술에 따라서 적절한 선택이 필요하다.
  3. 그리고 이때 필요한 라이브러리의 조합을 만들다 보면 복잡한 의존관계 속에서
     같은 라이브러리의 다른 버전이 동시에 필요해서 문제가 발생하기도 하며
     어떤 경우 버전이 올라가면서 같은 클래스인데도 완전히 다른 방식으로 동작하거나
     내부 구조가 바뀌어서 전혀 호환되지 않는 경우도 있다.
     
  4. 이 문제를 풀 수 있는 방법은 한쪽 버전의 클래스를 다른 패키지로 옮겨 서로 구별되는 클래스로 만드는 재패키징 방법이다.
     두 개의 클래스가 이름은 같지만 호환이 안 된다면 그중 한 버전을 패키지를 바꿔주고
     이 버전을 사용하는 라이브러리도 이 패키지 밑에 있는 클래스를 쓰도록 만들어주는 것이다.
     하지만 이 작업은 간단하지 않기 때문에 이를 지원해주는 툴도 존재한다.
  5. 스프링이 사용하는 라이브러리의 의존관계를 따져보면 이렇게 버전이 다르면서 같은 라이브러리를 사용하는 경우가
     여럿 발견되며 재패키징을 통해 충돌 문제를 피하고 있음을 볼 수 있다.
  6. 이렇게 스프링을 이용한 애플리케이션을 만들 때 필요한 라이브러리의 종류와 버전을 적절히 선정하고
     개발하면서 추가적으로 필요로 하는 라이브러리를 추가하거나 또는 제거하는 등의 관리 작업을 결코 쉬운 일이 아니다.
     
• 자신이 직접 프로젝트를 구성하고 필요한 라이브러리를 선정, 추가, 제거하는 등의 관리를 해야하는 상황이라면
  가장 먼저 해야할 작업은 스프링으로 만드는 애플리케이션이 정확히 어떤 기능이 필요한지를 정리하는 것이다.
  1. 각 기능을 지원하는 기술이 여러 가지 종류가 있다면 그중에서 어떤 것을 사용할지도 결정해야 한다.
  2. 사용할 기능과 기술 목록이 모두 만들어졌으면 일단 스프링 모듈부터 선정한다. 스프링은 총 20개의 모듈이 있다.
     그 외의 모듈은 애플리케이션의 아키텍처와 사용 기술에 따라서 선택적으로 적용할 수 있다.
     스프링의 모듈 사이에도 의존관계가 있으며 모듈 사이의 의존관계는 필수와 선택으로 나뉠 수 있다. 
  3. 스프링의 각 모듈은 또 다른 모듈에 의존하기도 하지만 오픈소스 라이브러리
     또는 표준 API를 필요로 하기도 하고 경우에 따라서는 상용 제품의 라이브러리에 의존한다.
     때로는 각 라이브러리를 활용하는 방법에 따라서 이 라이브버리가 또다른 라이브러리(서드파티 라이브러리)를 필요로 하는
     경우도 있으므로 해당 프레임워크나 라이브러리의 문서를 참조해서 필요한 라이브러리가 어떤 것인지 직접 찾아봐야 한다.
  4. 하지만 때로는 어떤 라이브러리를 추가해야 할지 말지 애매한 경우가 있다.
     그런 경우에는 어쩔 수 없이 확실히 필요하다고 생각되는 최소한의 라이브러리와 모듈만 가지고 일단 개발을 시작해
     애플리케이션의 주요 기능을 가진 간단한 샘플을 하나 만들어가면서, 클래스를 찾을 수 없다면 예외를 만나게 될 경우
     해당 파일을 추가해주는 시행착오 방법을 이용해야 한다.
  5. 필요한 라이브리가 없으면 애플리케이션이 동작하다가 에러가 나거나 아예 컴파일되지 않는다.
     반대로 필요하지 않은 라이브러리가 있을 땐 아무런 문제가 발생하지 않지만
     애플리케이션 모듈의 파일 크기가 커지는 것은 물론이고 이후에 라이브러리를 관리하는데 심각한 애를 먹을 수도 있다.
     따라서 불필요한 라이브러리는 처음부터 추가하지 않아야 하며,
     사용 기술이나 기능이 변경돼서 불필요해진 라이브러리도 바로 제거할 수 있도록 노력해야 한다.
• Maven과 ANT는 자바의 대표적인 빌드 툴이다.
  빌드 툴이 지원하는 의존 라이브러리 관리 기능에 대해 이야기해보자.
  1. 이클립스와 같은 IDE는 코드만 작성하면 자동으로 컴파일해주는 자동빌드 기능이 있고,
     관련 빌더를 추가하거나 확장하므로써 복잡한 빌드 작업도 간단히 진행할 수 있다.
  2. 하지만 IDE를 사용할 수 있는 환경이 아닌 경우에도 일관된 빌드가 가능하도록 만드는 것이 중요하다.
     예) 서버에 배치했을 때, 통합 테스트 환경에서 애플리케이션을 직접 빌드해야할 때
  3. 그래서 자동빌드 기능을 지원하는 IDE를 기본적으로 이용하면서
     ANT나 Maven 같은 환경에 독립적인 빌드 툴을 함께 사용하는 것이 바람직하다.
  4. ANT는 이클립스에 기본 내장돼서 제공될 정도로 사실상 표준 자바 빌드 툴로 자리잡고 있으며
     Maven은 단순 빌드 툴을 넘어서 개발 과정에서 필요한 빌드, 테스트, 배치, 문서화, 리포팅 등의
     다양한 작업을 지원하는 종합 프로젝트 관리 툴의 성격을 띠고 있다.
  5. Maven은 POM이라고 불리는 모델 정보를 이용하며 절차적인 스크립트와 구조가 비슷한 ANT와 달리 선언적이다.
     프로젝트의 주요한 구조와 특징, 필요한 정보를 POM의 프로젝트 모델 정보로 만들어두면,
     이를 참조해서 Maven이 미리 정해진 절차에 따라 빌드 또는 프로젝트 관리 작업을 진행할 수 있다.
     
  6. 이 중 독특한 특징 중 하나는 애플리케이션이 필요로 하는 의존 라이브러리를 선언해두기만 하면
     원격 서버에서 이를 자동으로 다운로드 받아서 사용할 수 있게 해주는 것이다.
  7. 더 흥미로운 기능은 전이적 의존 라이브러리 추적 기능으로 POM의 의존정보에 하나의 라이브러리를 지정하면,
     지정된 라이브러리가 동작하는데 필요한 여타 라이브러리까지 함께 다운로드해주는 기능이 존재한다.
     그래서 잘 정의된 의존정보를 가진 라이브러리들을 갖고 있다면 한두 개의 최상위 의존 라이브러리만 지정해줌으로써
     그에 필요한 모든 라이브러리를 쉽게 추가할 수 있다.
  8. 물론 Maven을 사용하고 POM 정보를 이용한다고 해도 실제 적용할 라이브러리를 선정하는 수고가 사라지는 것은 아니다.
     하나의 모듈이 제공하는 기능 중에서 애플리케이션에서 실제 사용하는 것에 따라서,
     또 로우레벨의 구현 기술을 어떤 것을 사용할지에 따라서 실제 필요한 라이브러리가 달라지기 때문이다.
     대부분은 경우에 따라 쓸 수도 있고 안 쓸 수도 있는 선택 라이브러리이며
     이는 Maven의 전이적 의존 라이브러리 추적 기능의 적용을 받지 못하므로 사용하려면 명시적으로 POM에 선언해야 한다.
     물론 각 모듈의 POM 적용 가능한 후보 라이브러리 목록과 호환 가능한 버전 정보를 참조할 수 있다는 도움이 된다.
  9. 이를 이용해 조직이나 팀이 관여하는 프로젝트 사이에 변하지 않고 공통적으로 사용하는 기술 목록을 만들어
     라이브러리 목록만 담긴 간단한 POM 파일을 만들고 이를 업로드해 함께 사용하도록 할 경우
     전이적 의존관계 추적 기능으로 인해 이 파일에 담긴 모든 라이브러리가 프로젝트에 자동 등록되기 때문에
     같은 조직이고 팀이라면 공통적인 모듈과 의존 라이브러리를 추출해 공통 의존 라이브러리 정보로 만들어둘 수 있다.
  10. 만약 거의 모든 프로젝트에서 사용 가능한 공통 라이브러리를 따로 선언해뒀다면,
      선택 가능한 기술들을 중심으로 의존 라이브러리 그룹을 만들어 POM 형태로 만들어둘 수 있다.
      예) common 의존그룹, springmvc 의존그룹, hibernate 의존그룹
  11. 처음 한 번과 새로운 스프링 버전이 등장했을 때만 다시 수고해주면
      지속적으로 활용 가능한 효과적인 의존관계 관리체계와 툴을 가져갈 수 있다.
  12. 만약 ANT로 빌드 스크르빝으를 갖고 있거나 Maven 사용에 익숙하지 않다면 ANT에서 사용할 수 있는 Ivy를 이용해도 된다.
      이 또한 Maven과 동일하게 빌드 중에 원격 리포지토리에서 라이브러리를 다운로드 받을 수 있는 기능을 제공한다.
      스프링은 Maven과 함께 Ivy에서도 사용할 수 있는 의존정보 파일을 제공해준다.
• 스프링 모듈 jar 파일의 이름은 두 가지 종류가 있다.
  예) core 모듈 : spring-core-3.0.7-RELEASE.jar, org.springframework.core-3.0.7.RELEASE.jar
  1. 사실 이 두 파일은 동일한 파일이지만 배포되는 기술에 따라서 관례적으로 다른 이름을 사용할 뿐이다.
  2. spring-core-3.0.7-RELEASE.jar는 Maven에서 사용하는 명명 규칙을 따른 것이다.
     Maven은 그룹 아이디(org.springframework)와 아티팩트 아이디, 그리고 버전 세 가지로 라이브러리를 정의하며
     그중에서 아티팩트 아이디(spring-core)와 버전(3.0.7.RELEASE)을 조합해서 파일 이름으로 사용한다.
  3. org.springframework.core-3.0.7.RELEASE.jar는 OSGi의 모듈 명명 규칙을 따른 것이다.
     스프링의 모든 모듈은 OSGi 호환 모듈로 만들어져 있다.
     OSGi 호환 이름을 갖는 스프링 모듈을 사용할 경우에는 Maven의 표준 리포지토리 대신
     스프링소스가 제공하는 엔터프라이즈 번들 리포지토리를 사용해야 한다.

<!-- Maven 리포지토리의 스프링 core 모듈 -->
<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-core</artifactId>
    <verson>3.0.7.RELEASE</version>
</dependency>

<!-- 스프링소스의 OSGi 번들 리포지토리의 스프링 core 모듈 -->
<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>org.springframework.core</artifactId>
    <verson>3.0.7.RELEASE</version>
</dependency>