RAINSTORY.RAINMAKER

Java 를 사용하여 Singleton 패턴을 구현할 경우 주의해야 할 사항이 있다. 멀티 쓰레드 환경에서 하나 이상의 객체가 생성되는 현상이 발견된다는 것이다.

이 현상을 어디서 접하게 되었는고 하니... Tomcat 기반의 웹 어플리케이션을 개발하면서 Singleton 패턴으로 커넥션풀 라이브러리를 만들어 두었다. 여러분도 알다시피 Tomcat에는 클래스파일이 변경되었는지 자동으로 감지하는 "Watch Dog" 이라는 기능이 탑재되어 있어서, 클래스의 변경을 감지하여 웹 어플리케이션(컨텍스트)을 다시 로딩하는 작업을 수행한다. 당시 데이터베이스의 커넥션 자원을 너무 많이 소모하는 것 같아서 디버깅 작업에 착수하였는데, WatchDog에 의하여 클래스를 다시 로딩할 때 Singleton 패턴으로 정의한 클래스의 객체가 여러 개 생겼음을 발견하게 되었다!!!

당연히 Singleton 패턴을 사용하면 같은 JVM 상에서는 오직 하나만 존재할 것으로 생각했던 내게 큰 충격이 아닐 수 없었다. 하여 문제를 해결하고자 검색해보니 멀티 쓰레드 환경에서 이런 문제가 꽤나 자주 있었음을 알 수 있었으며, 다음의 두 아티클을 찾을 수 있었다. 이 글들은 Java에서의 Singleton 패턴 구현 방식에 대하여 가장 잘 정리하고 있다:

http://www-106.ibm.com/developerworks/j ··· e%3Djava
http://c2.com/cgi/wiki?JavaSingleton

첫 번째 자료는 IBM 에 게시된 자료인데 그냥 참고로 읽고, 주로 두 번째 자료를 숙독하기 바란다. 내가 두 번째 자료를 접했을 당시에는 아래와 같은 해결책이 제시되어 있었다.

public class Singleton {
// final 키워드를 사용한 것에 주의할 것!
private static final Singleton _theInstance = new Singleton();

private Singleton() {
}

// synchronized 키워드가 사용되지 않았다는 점도 눈여겨 보자
public static Singleton getInstance() {
return _theInstance;
}
}

위 해결책은 Darren Hobbs 가 제안한 방법으로 Java Spec에 근거하여 제시한 방법이다. 하지만 Adam 은 이 방식이 거의 대부분의 상황에 잘 적용되긴 하지만 Tomcat 과 JBoss 두 컨테이너에서 테스트 해보니 생성자(constructor)에서 멤버 변수를 초기화하지 못하는 문제가 발견되었다고 문제를 제기하였다.

최근에 다시 두 번째 링크를 방문해 본 결과, Josh Bloch의 "Effective Java" 책 저술작업에 기여했던 Scot Floess 라는 사람이 David Geary가 JavaWorld에 게재한 글에 대해 Thread-safety 문제를 지적하며 제시한 해결책을 접할 수 있었다(※ 참고 : http://www.javaworld.com/javaworld/jw-0 ··· ers.html). 일단 Darren Hobbs 가 제안한 방법과 거의 같지만, 1) 클래스 선언 시 final 키워드를 붙여 상속이 불가능하도록 하였으며, 2) static 의 inner class를 사용하여 Singleton 패턴의 클래스를 감싸고 있는 형태가 다르다. 분명 이런 형태로 Singleton 패턴의 클래스를 생성하는 작업은 그 자체로 매우 무거운 작업이긴 하지만, 간단하면서도 완벽한 방식의 Singleton 패턴 구현 방식이라고 한다. 자세한 것은 링크를 참고하도록 하자.

/*
* final 키워드를 사용하여 이 클래스로부터 상속이 불가능하도록 하였다.
*/
public final class Singleton {
// static inner class (여기도 final 키워드 사용) 를 사용하여 Singleton 클래스의
// 객체를 생성함
private static final class SingletonHolder {
// 역시 이 내부에서도 static final 키워드 사용
static final Singleton singleton = new Singleton();
}

private Singleton() {}

public static Singleton getInstance() {
return SingletonHolder.singleton;
}
}

스프링은 그 이름 자체로도 많은 의미를 내포하고 있다. 봄! 이 얼마나 설레는 단어인가? 봄이라는 이름만으로도 무거운 J2EE의 사용으로 지친 개발자들에게 이제 겨울이 끝나고 새로운 계절이 돌아오고 있음을 함축적으로 표현해내고 있다. 스프링은 로드 존슨이 쓴 「Expert one-on-one J2EE Design and Development」란 책에서 소개된 소스코드를 기반으로 2003년 2월 오픈소스로 시작된 프로젝트이다. 스프링이 추구하는 바는 크게 두 가지이다.

[1] 복잡하고 무거운 J2EE 기술의 사용을 쉽고 가볍게 만들어주고, 자연스럽게 검증된 최상의 실천 사례들을 구현하도록 함으로써 좋은 프로그램이 작성될 수 있도록 유도한다.

[2] 기존의 잘 알려진 기술들을 프레임워크 내에서 일관된 방법으로 쉽게 사용할 수 있도록 돕는다.

이를 위해 스프링은 다른 프레임워크와는 차별화된 다음과 같은 특징을 가진다.

◆ 스프링은 EJB를 사용하건 하지 않건 관계없이 비즈니스 객체들을 효과적으로 구성하고, 관리하는 방법을 제공하는 데 초점을 맞춘다.

◆ 스프링은 계층화된 아키텍처를 갖고 있으며, 그 중 어떤 부분도 독립적으로 사용될 수 있도록 모듈화되어 있다. 뿐만 아니라 각각의 모듈은 일관된 방법으로 사용할 수 있기 때문에 한번 익숙해지고 나면 사용이 무척 쉽다.

◆ 스프링은 전체 프로젝트의 설정을 관리할 수 있는 일관된 방법을 제공함으로써, 개발자들이 각종 프로퍼티 파일을 작성하지 않도록 유도한다. 이것은 IoC라는 스프링의 특징 때문인데, 객체들간의 의존성이 따로 관리됨으로써 비즈니스 로직이 EJB로 개발되었건 일반 자바 객체로 개발되었건 동일한 방법으로 해당 로직을 이용할 수 있는 이점도 추가된다.

◆ 스프링 기반으로 작성된 애플리케이션은 스프링의 API에 의존하지 않는다. 이것은 어떤 애플리케이션 서버와도 쉽게 연동되도록 하며, 심지어 스프링을 사용하지 않았을 때조차도 비즈니스 로직의 재사용이 가능해지는 요인이 된다.

◆ 스프링은 AOP 지원을 통해 주요 비즈니스 로직과 시스템 전반에 걸친 기능 모듈을 완벽히 분리해내도록 도와준다.

◆ 스프링은 작성된 코드에 대한 유닛 테스트를 쉽게 할 수 있도록 도와준다.

스프링의 기능과 사용 시나리오
현재 스프링은 1.0 버전이 출시된 상태이다. 스프링 홈페이지(www.springframework.org)에서 spring-framework-1.0.2-with-dependencies.zip 파일을 다운받기 바란다. 이 파일은 의존성 있는 관련 라이브러리가 모두 포함된 버전이다. 스프링의 전체 기능은 크게 7개의 모듈로 구성된다(<표 1>).

<그림 2> 스프링의 기능 요소

<표 1> 스프링의 기능 요소

스프링 배포 파일의 압축을 풀면 dist란 디렉토리가 나타난다. 그 안에 있는 spring.jar가 앞에서 언급한 스프링의 모든 기능을 포함하는 파일이다. 각각의 기능 중 필요한 부분을 따로 사용할 경우를 위해 패키지별로 묶은 별도의 JAR 파일이 함께 제공된다.

스프링을 이용한 일반적인 형태의 웹 애플리케이션은 <그림 3>과 같은 구조를 가진다. 톰캣, 웹로직, 웹스피어, JBoss를 포함한 어떤 웹 애플리케이션 서버에서도 동작된다. IoC 컨테이너의 핵심인 Core 패키지와 AOP 지원을 위한 AOP 패키지, 기능을 구현한 빈 객체에 대한 접근을 제공하는 Context 패키지는 반드시 포함되어야 한다. 대부분 데이터베이스 처리를 수행하기 때문에 DAO 패키지도 일반적으로 포함된다.

스프링 애플리케이션은 일반적으로 ORM 솔루션을 채택하고, 특히 하이버네이트와 궁합이 잘 맞기 때문에 하이버네이트를 설치하고 ORM 패키지를 이용하는 경우가 일반적이다. 그 위에서 Web 패키지를 기반으로 Web MVC 패키지를 이용해서 애플리케이션을 개발한다.

<그림 3> 시나리오 1. 완전한 형태의 스프링 웹 애플리케이션

만일 스프링의 Web MVC 패키지를 이용하지 않고, 스트럿츠나 웹워크를 제어 계층에 사용하고 싶다면 Web MVC를 스트럿츠가 대체하는 <그림 4> 외에 같은 구조로 웹 애플리케이션이 개발될 것이다.

<그림 4> 시나리오 2. 서드파티 WAF와 ORM을 연계한 웹 애플리케이션

이 밖에도 EJB를 사용하는 경우 AbstractEnterpriseBean이라는 POJO를 이용해서 EJB를 스프링에서 관리하도록 하고, SlsbInvoker를 이용해서 EJB에 대한 접근 경로를 제공하는 EJB 사용 유형이 있다. 또한 웹 서비스를 포함한 다른 애플리케이션과 연동하는 경우를 위해 Remote 패키지가 제공되기도 한다.

스프링은 그 자체로도 한 권의 책을 쓸 수 있을 만큼 방대한 기술이다. 그 모두를 짧은 연재를 통해 소개한다는 것은 불가능하다. 그러한 이유로 스프링에 대한 소개는 이쯤에서 마무리하고, 스프링을 이해하기 위해 반드시 알아야 하는 IoC(Inversion of Control) 컨테이너의 개념과 AOP(Aspect Oriented Programming)를 간단히 설명하고, 2개의 작은 예제를 소개하는 것으로 이번 글을 마무리하겠다. 부족한 설명은 필자들이 운영하는 VSSH 포럼이나, 스프링 관련 기사 및 자료들을 정리한 리소스 맵을 통해 여러분 스스로 익혀나가기를 바란다.

IoC 컨테이너와 AOP
스프링은 다른 프로젝트에서 개발된 컴포넌트를 조립해서 응집력 있는 애플리케이션의 개발이 가능하도록 도와주는 IoC 컨테이너이며, 다른 말로 경량급 컨테이너(Lightweight Container)라고도 한다. IoC 컨테이너의 또 다른 종류로는 PicoContainer와 아파치의 아발론, 그리고 HiveMind 등이 있다.

그 중에서 현재 가장 널리 사용되고 있는 것은 스프링과 PicoContainer이다. IoC 컨테이너는 다른 컨테이너와 달리 애플리케이션 코드와 컨테이너간의 의존성을 최소화하는 것이 특징이다.

IoC 컨테이너가 컨테이너에 대한 의존성을 최소화하면서 컴포넌트를 엮어주는 일을 수행하는 밑바탕에는 제어 역행화(Inversion of Control)라는 개념이 깔려 있다. 제어 역행화는 리팩토링의 저자이기도 한 마틴 파울러의 홈페이지에 잘 정의되어 있다.

제어 역행화라는 용어는 직관적이지 못하기 때문에, 또 다른 말로 연관성 삽입(Dependency Injection)이라고도 불려진다. 연관성 삽입 패턴은 컴포넌트의 설정을 그것의 사용에서 분리해야 한다는 원칙(The principle of separating configuration from use)에서 출발한다. 그러한 원칙을 위한 또 다른 사례는 J2EE 패턴 중 서비스 로케이터(Service Locator) 패턴이다.

의존성 삽입 패턴을 이해하기 위해 간단한 예를 하나 살펴보도록 하자. 어느 특정 감독이 만든 영화를 검색해서 그 결과를 전달해주는 컴포넌트를 사용하는 것이다. 코드에서 보여지는 findAll()이라는 메쏘드를 가지는 finder 객체가 필요하단 사실을 알 수 있다.

일반적으로 이럴 때 기능 확장을 위해 MovieFinder와 같은 인터페이스를 작성하게 된다.

영화 정보가 콜론으로 구분된 CSV 파일에 기록되어 있다면, MovieFinder 인터페이스를 구현한 ColonDelimitedMovieFinder 클래스가 필요할 것이다. 또한 그 정보는 MovieLister에 생성자를 이용해서 초기화될 것이다.

전체적인 시스템 구조는 <그림 5>와 같은 형태이다. MovieLister 클래스는 MovieFinder 인터페이스 정보만을 이용해서 기능을 구현할 수 있지만, 해당 기능을 사용하기 위해 MovieFinderImpl 클래스 중에서 ColonDelimitedMovieFinder를 이용한다는 구체적인 설정 정보가 클래스의 코드에 포함되어 있다. 이것은 데이터가 DB나 XML로 변경되어 RDBMovieFinder나 XMLMovieFinder로 교체될 경우 코드를 수정해서 다시 빌드해야 한다는 사실을 의미한다.

<그림 5> 일반적인 제어 흐름을 통한 의존성 표현

사실 MovieLister는 정보가 CSV 파일에 기록되어 있건, DB에 기록되건, XML에 기록되건 영향을 받지 않아야 정상이라고 할 수 있다. 어떻게 하면 이처럼 불필요한 의존 관계를 없앨 수 있는 것일까?

<그림 6> 제어역행화 패턴을 통한 의존성 삽입

그 해답은 설정 정보에 따라 어떤 구현 객체를 사용할 것인지를 결정하는 어셈블러를 이용해서 <그림 6>에서 보여지는 구조로 애플리케이션을 개발하는 것이다.

MovieLister 클래스에서 선언된 MovieFinder 타입의 finder를 초기화하는 방법은 크게 2가지가 있다. 첫 번째는 생성자를 통해 속성을 초기화하는 것이고, 두 번째는 setMovieFinder()와 같은 Setter 메쏘드를 이용하는 것이다. 이러한 설정을 자동화하는 어셈블러를 구현해 놓은 것이 바로 IoC 컨테이너이다.

연관성 삽입은 크게 Constructor Injection, Setter Injection, Interface Injection의 3가지 유형을 가진다. Constructor Injection이 생성자를 이용해서 의존성을 설정해주는 방법이고, Setter Injection이 Setter 메쏘드를 이용해서 의존성을 설정해주는 방법이다. Pico Container는 Constructor Injection을 주로 사용하고, 스프링은 자바 빈 규칙을 이용한 Setter Injection을 주로 사용한다.

스프링의 IoC적인 특징은 AOP를 구현하는 핵심적인 원리가 되기도 한다. AOP는 아직 국내에는 생소한 분야이다. 김대곤님이 작성한 간단한 소개글을 통해 AOP의 개념을 잡아보도록 하자.

자금 이체를 하는 프로그램을 작성한다고 가정해 보자. 출금 계좌와 입금 계좌 그리고 이체 금액을 입력받아 SQL 문장 또는 함수 한 번 돌리는 것으로 모든 프로그래밍이 끝나는가? 그렇지 않다. 해킹을 방지하기 위해 사용자가 적절한 보안 프로그램을 설치했는지 점검하는 코드도 있어야 하고, 사용자가 인증되었는지 점검하는 코드도 써야 하고, 상대방 은행에서 적절하게 처리되었는지도 점점해야 하고, 혹시 사용자가 이체 버튼을 두 번 누른 것은 아닌가 체크해야 하고, 시스템 로그도 남겨야 한다.

즉, 구현하려고 하는 기능 뿐 아니라 보안, 인증, 로그, 성능과 같은 다른 기능들도 녹아 있어야 한다는 뜻이다. 어쩌면 이체를 위한 코드보다 잡다한 다른 측면의 문제들을 다루는 코드가 더 길어질 수 있다. 이런 코드들은 입금이나 출금 같은 다른 곳에서도 공통적으로 사용되는 것이다.

<그림 7> AOP의 개념

구현하려고 하는 비즈니스 기능들을 AOP에서는 Primary(Core) Concern이라는 용어로 표현한다. 보안, 로그, 인증과 같이 시스템 전반적으로 산재된 기능들은 Cross-cutting concern이라고 부른다. AOP는 Cross-cutting concern을 어떻게 다룰 것인가에 대한 새로운 패러다임이라고 할 수 있다.

그럼 AOP가 등장하기 이전에 우리는 어떻게 Cross-cutting Concern을 처리해왔을까? 매우 간단하다. Primary Concern를 구현한 프로그램에 함께 포함시켰다. Primary concern, Cross-cutting concern이 하나의 프로그램 안에 들어가게 되면, 프로그램을 이해하기가 힘들고, Cross-cutting concern 코드가 여기저기에 산재되어 수정하기 힘들게 된다. 당연히 생산성 떨어지고, 품질 떨어지고, 유지보수 비용은 많이 들게 된다.

그럼 AOP는 Cross-cutting concern를 어떻게 처리하는가? AOP에서는 Primary Concern 구현하는 코드 따로, Cross-cutting concern 구현하는 코드도 따로 작성한다. 나중에 2개를 조합한 완벽한 애플리케이션이 만들어지는 것이다.

AOP에서는 Cross-cutting concern 구현한 코드를 Advice라고 하며, Primary concern 구현한 코드를 Code라고 부른다. Code와 Advice를 연결해주는 설정 정보를 Point-cut이라고 하며, 둘을 조합해서 애플리케이션으로 완성하는 과정을 Weaving(조합)이라고 부른다.

기술적 용어로서의 ‘Aspect’는 Advice와 Point-cut을 함께 지칭하는 단어이다. Point-cut은 어떤 Advice를 Code 어느 위치에 둘 것인가 하는 것이다. 스프링의 AOP 패키지는 이러한 AOP 개념을 구현한 것으로, 그 기반에는 설정을 이용으로부터 분리하는 의존성 삽입 패턴이 녹아 있다.

예제 1. 스프링의 WebMVC를 이해하자
이제 스프링을 이해하기 위해 2가지 예제를 살펴볼 것이다. 첫 번째 예제는 스프링 공식 홈페이지에 소개된 것으로 순수하게 스프링이 제공하는 기능만을 이용해서 개발된 예제이다.

국내에는 스프링과 관련한 자료가 전혀 없는 관계로 초보자들을 위해 이 예제를 편역하고 몇 가지 설명을 추가해 총 4부 8개의 강좌로 재구성해서 VSSH 포럼에 등록해 두었다. 자세한 설명을 원하는 독자는 관련 자료를 참고하기 바란다.

여기서 소개하는 예제는 앞에서 소개한 강좌 중 2부까지 구현된 샘플이다. 예제를 실행해보기 위해서는 톰캣과 Ant, JDK 등이 설치되어 있어야 한다. 예제(springapp.zip)를 다운로드한 다음, 작업 디렉토리에서 압축을 풀면 build.properties 파일이 보일 것이다.

해당 파일을 열어 배포될 경로와 톰캣 홈, 그리고 톰캣 관리자의 URL/아이디/패스워드 정보를 자신의 환경에 맞게 변경한다. 그런 다음 build와 deploy 타겟을 ant를 이용해서 순서대로 실행한다. 웹 브라우저를 이용해서 http://localhost:8080/springapp로 접속하면 아래와 같은 결과 화면을 볼 수 있을 것이다.

<그림 8> 스프링 WebMVC 예제화면

우선 예제의 web.xml 설정부터 살펴보도록 하자. DispatcherServlet이 springapp란 이름으로 등록되어 있고, htm으로 끝나는 모든 URL 패턴이 해당 서블릿으로 매핑되어 있다. DispatcherServlet은 스트럿츠의 ActionServlet의 기능과 유사한 일종의 FrontController 서블릿이다.

그렇다면 DispatcherServlet이 처리하는 제어 행위를 위한 struts-config.xml과 같은 설정 파일이 필요할 것이다. 스프링 MVC 패키지에서는 그 파일을 해당 서블릿 이름에 "-servlet.xml"을 붙여 작성하도록 권장하고 있다. 앞의 경우 서블릿의 이름을 springapp로 주었기 때문에 springapp-servlet.xml이 설정 파일이 되는 것이다.

설정 파일을 보면, <beans>라는 루트 엘리먼트 밑에 <bean>이라는 설정이 반복되어 적용되고 있다. 이것이 스프링에서 BeanFactory를 이용해서 제공하고 있는 Setter Injection을 통해 설정과 그 사용을 분리하는 방법이다.

전체 애플리케이션의 동작 과정을 한번 살펴보자.

<그림 9> 스프링 WebMVC 예제동작 원리

웰컴 파일인 index.jsp에는 hello.htm에 대한 링크가 걸려있다. hello.htm에 대한 요청은 web.xml의 설정에 의해 springapp로 이름지어진 스프링의 web 패키지의 DispatcherServlet으로 전달된다. DispatcherServlet은 스프링의 core 패키지에 있는 BeanFactory를 이용해 IoC 컨테이너의 기본 원리에 따라 동작된다. 설정 파일인 springapp-servlet.xml을 통해 모든 의존성이 결정되어 제어가 반전되는 현상을 볼 수 있다.

<그림 10> VSSH 고객등록 예제화면

우선 <prop key="/hello.htm">springappController</prop>에 의해 hello.htm 요청을 SpringappController 클래스가 처리하게 되는데 그 사실을 DispatcherServlet은 전혀 모른다. SpringappController는 요청을 처리하는 과정에서 ProductManager의 구현을 필요로 하는데, 그게 어떤 클래스의 인스턴스인지를 본인은 모른다. 설정에 의해 자동적으로 bus.ProductManager가 결정되고, 해당 인스턴스가 거꾸로 SpringappController에 찾아와 연결된다. 이러한 제어의 반전이 스프링을 IoC(Inversion of Control) 컨테이너라고 부르게 하는 이유다.

다음 코드는 스트럿츠의 액션과 유사한 역할을 수행하는 Controller 구현 샘플이다. ProductManager를 사용하고 있는데 신기하게도 setProductManager() 메쏘드만 있을 뿐, 인스턴스를 초기화하는 호출이 이루어지지 않는다. 스프링이 빈 설정을 참고해서 자동화하기 때문이다. handleRequest()의 결과로 ModelAndView가 리턴되어 넘어가는데, 이것은 스트럿츠의 ActionForward와 컨텍스트 정보를 합친 것으로 이해하면 되겠다.

예제 2. 스프링과 스트럿츠, 하이버네이트를 통합한 예제
그럼 스프링을 기존의 스트럿츠 환경과 어떻게 연동할 수 있을까? 대표적인 ORM인 하이버네이트와는 어떻게 연동할 수 있을까? 이를 소개하기 위해 간단한 회원 관리 샘플을 개발했다. 이 예제는 벨로시티와 스트럿츠, 스프링, 하이버네이트를 통합하고자 하는 VSSH의 최종적인 모습을 보여주며, DBMS는 HSQLDB를 사용했다.

예제 파일(vssh.zip)을 다운받아 자신의 작업 디렉토리에 압축을 풀고, was.properties 파일을 열어 자신의 운영 환경에 맞게 경로를 수정한다. 그런 다음, ant를 이용해서 makeDist, war-deploy 태스크를 순서대로 실행하면 빌드 및 배포 과정이 끝난다. 웹 브라우저를 이용해서 http://localhost:8080/vssh-b01에 접속하면 아래와 같은 결과 화면을 볼 수 있을 것이다.

이 예제는 다음 강좌에서 다시 자세히 설명할 예정인데, 미리 상세한 내용을 알고 싶은 분은 LoveLazur의 홈페이지를 참고하기 바란다. 이번 예제부터는 복잡하기 때문에 이클립스와 같은 오픈소스 IDE를 이용하는 것이 좋다.

스트럿츠와 스프링의 연동 방법은 각각을 이해하고 있다면 아주 간단히 처리된다. WEB-INF/lib 디렉토리에 각각의 라이브러리 JAR 파일을 추가한 다음, 스트럿츠 설정 파일인 struts-config.xml에 플러그인 설정만 하나 추가하면 되는 것이다. 플러그인으로 설정한 ContextLoader는 전달된 설정 파일을 이용해서 전체 애플리케이션 구성에 사용될 ApplicationContext를 구성하는 역할을 수행한다.

applicationContext.xml에는 애플리케이션 로직과 관련된 객체들을 앞서 설명한 빈 설정 방식으로 연동해서, 제어 역행화가 이루어지도록 하면 된다.

주의할 점은 모든 클래스에서 사용되는 객체 참조에서 항상 자바 빈 규칙에 따르는 setter()를 만들고, 직접 인스턴스를 초기화하지 않고 객체들의 의존성을 설정 파일에 적어줌으로써 스프링이 자동으로 의존성 관계를 삽입하도록 해야 한다는 것이다.

다음의 CustomerAction을 살펴보면 ICustomerBizManager 타입의 cmgr이라는 인스턴스를 갖고 있는데, setCustomermanager()란 메쏘드만 있을 뿐 어디에도 초기화하는 루틴이 포함되어 있지 않다. 그런데도 cmgr.createCustomer()를 사용하고 있는 것을 볼 수 있다.

이것은 action-servlet.xml과 applicationContext.xml에서 다음과 같은 설정이 되어 있으므로 그 정보에 따라 적절한 customerManager가 결정되기 때문에 가능해진다.

대안 기술에 대해 관심을 갖자
지금까지 스프링 프레임워크의 필요성을 설명하고, 기본 개념이라 할 수 있는 연관성 삽입 패턴과 AOP에 대해 간단히 살펴보았다. 또한 스프링의 특징과 스프링을 활용한 예제를 소개했다. 스프링이 아직 국내에 소개된 적이 없다보니 외국의 문서와 예제, 서적들을 뒤적거리면서 관련 자료를 정리하는데 한달이 넘는 시간이 소요되었다.

하지만 아쉽게도 그동안 정리한 내용을 모두 소개하기에는 할당된 지면이 너무 부족해 꼭 필요한 부분만을 알려주는데 그친 듯하다. 설명이 미흡한 부분은 필자들의 VSSH 포럼을 활용하고, 궁금한 점이 있으면 언제든 질문해 주기 바란다.

솔직히 말해 이 글을 쓰고 있는 필자도 여러분보다 몇 달 먼저 스프링을 공부한 정도의 수준밖에 되지 않는다. 미국, 일본, 중국, 독일 어디서나 스프링 관련 자료를 쉽게 구할 수 있었지만, 안타깝게도 국내에는 전혀 자료가 없었다.

해외에서는 크게 주목을 받고 있는 스프링과 IoC 컨테이너에 대한 내용들이 왜 국내에서는 전혀 다루어지지 않고 있는지를 곰곰이 생각해본다. 우리네 개발자들은 촉박한 개발 일정에 쫓겨 신기술이나 대안 기술들을 공부할 만큼 다들 여유가 없는 것일까? 아니면 그러한 기술을 이미 익히고 있는 개발자들이 자신의 머리 속에 그 지식을 꼭꼭 숨겨두고 공개하지 않는 것일까?

지금 자바 커뮤니티는 주류 기술의 버전 향상과 신기술의 출현 그리고 오픈소스 기반의 다양한 대안 기술의 등장으로 어느 때보다 급격한 기술 변화를 눈앞에 두고 있다. 아직 그러한 변화를 느끼지 못하고 있는 개발자라면 지금이 바로 그러한 변화에 대한 대비를 시작해야 할 때임을 깨달아야 한다. 또한, 그 과정에서 얻어진 노하우를 공유함으로써 더 큰 이익이 자신에게 돌아온다는 사실도 잊지 말기 바란다. @

썬마이크로시스템즈(www.sun.com)는 오픈소스 데이터베이스 개발업체인 MySQL 인수를 위해 약 10억 달러(한화 1조원)에 달하는 최종 계약을 체결했다. 이번 인수로 썬은 150억 달러 규모의 데이터베이스 시장에 진출해 엔터프라이즈 IT 업계에서의 위상을 더욱 강화할 수 있게 되었다.

페이스북(Facebook), 구글, 노키아, 바이두(Baidu), 차이나 모바일과 같은 세계적인 기업에 수백 만개의 제품이 채택되고 있는 MySQL은, 이번 인수 계약으로 인해 MySQL의 오픈 소스 데이터베이스가 보다 많은 전통적인 애플리케이션 및 엔터프라이즈에 채택되어 소프트웨어 업계의 환경을 변화시키며, 시너지 효과를 불러일으킬 것으로 예상된다. 또한, MySQL은 인텔, IBM 및 델과의 OEM 협력 관계를 비롯한 썬의 채널을 통해 새로운 유통 조직도 확보하게 된다.

MySQL의 오픈소스 데이터베이스는 인터넷의 근간으로 여겨지는 리눅스(Linux), 아파치(Apache), MySQL, PHP/Perl로 구성된 소프트웨어 플랫폼 LAMP의 ‘M’에 해당한다. 썬은 오픈솔라리스 및 맥 OS X, GNU/리눅스 및 마이크로소프트 윈도 상에서 LAMP 스택을 강화 및 최적화하기 위해 노력하고 있다. MySQL, 오픈솔라리스(OpenSolaris) 및 글래스피시(GlassFish)의 데이터베이스는 썬의 자바 플랫폼 및 넷빈즈 커뮤니티와 함께 자신들의 애플리케이션을 웹으로 전환하려는 다양한 고객층 전반에 걸쳐 강력한 웹 애플리케이션 플랫폼을 만들어 낼 것이다.

MySQL의 오픈소스 데이터베이스 소프트웨어는 1억 번 이상 다운로드 및 유통되었으며, 매일 5만 번 추가로 다운로드 되고 있다. MySQL은 썬의 소프트웨어, 영업 및 서비스 조직에 통합될 것이며, CEO 마틴 미코스는 썬의 수석 임원으로 활동하게 된다. MySQL은 미국 캘리포니아주 쿠페르티노와 스웨덴의 웁살라에 본사가 위치하며, 25개 나라에서 400명의 직원들이 근무하고 있다.

이번 거래의 일환으로, 썬은 MySQL 전체 주식 매입에 약 8억 달러의 현금과 2억 달러 상당의 옵션을 지불하게 된다. 거래는 썬의 2008 회계연도 3분기 말이나 4분기 초에 완료될 것으로 예상된다.

EDM (Enterprise Decision Management)은 기업의 의사결정을 총체적으로 지원함으로써 수익과 성과를 극대화시키는 기술입니다. 기업의 의사결정 서비스에 있어 데이터, 비즈니스 룰 및 진보된 예측모델을 결합함으로써, 운영상 주요한 의사결정의 정밀도 및 일관성, 신속성을 높여줍니다. Korea Expert EDM 오늘날 기업은 의사결정을 위해, 더 많은 채널 및 생산라인에서 더 많은 데이터를 참조해야 하며, 경쟁우위 확보를 위해 고려해야 할 사항이나 지켜야 할 법규들이 늘어나면서 훨씬 복잡해진 제약조건 확인과 다양한 요소들간 상호 연관관계를 고려해야 하는 상황에 처해 있습니다. EDM은 다음과 같은 상황에 처한 조직들이 추구해온 해법입니다. 즉, EDM은 ROI (투자대비효과)를 높이기 위해, 경쟁 상황 또는 법규 변화로 인해 복잡하고도 정밀한 비즈니스 의사결정이 증가함에 따라, 그리고 단기적 경쟁우위에서 그칠 것이 아니라, 선점한 경쟁우위를 지속하기 위해 채택되고 있습니다. EDM Technologies 코리아엑스퍼트는 이론과 실재를 겸비한 EDM 기술의 리더로서, 오늘날 금융, 소매, 보험, 통신, 의료 등 다양한 분야에서 수 많은 고객의 비즈니스 성과 향상을 지원해 왔습니다. 코리아엑스퍼트는 고객관리에서 사기검출, 리스크 관리에서 마케팅에 이르는 다양한 의사결정 영역의 지원을 위한 기업의사결정관리 어플리케이션을 제공합니다. 코리아엑스퍼트의 기업의사결정관리 어플리케이션에는 다음의 것들이 포함됩니다. - 의사결정의 정확도를 높이는 예측적 분석방법 - 의사결정을 위한 룰을 비즈니스 유저가 신속히 작성하고 테스트하며 수정할 수 있도록 하는 비즈니스 룰 관리 - 챔피언/챌린저 전략설정 및 테스트를 통한 의사결정 전략 최적화 및 의사결정 분석 환경 이러한 어플리케이션은 의사결정 관리 및 개선에 관하여 미국 페어아이작 사(社)가 50년 이상, 코리아엑스퍼트가 20년 이상 축적한 경험과 노하우가 반영된 EDM Technologies를 기반으로 만들어집니다. EDM 기술은 특정 의사결정영역마다 패키지 솔루션을 제공하는 것이 아니라, 다음의 핵심 기술 및 도구를 이용하여, 고객의 요구에 맞는 솔루션을 개발하여 제공합니다. - Blaze Advisor™ : 비즈니스 룰 관리 시스템을 위한 세계 제일의 비즈니스 룰 솔루션 - Model Builder : 페어아이작 고유의 분석 기술과 분석 모델이 제공되는 예측적 분석 작업 환경 - Decision Optimizer : 최적의 의사결정을 제공하는 강력한 최적화 및 시뮬레이션 제품 EDM Technologies의 적용 코리아엑스퍼트의 프로페셔널 서비스는 위의 도구들을 이용하여 고객의 개별 의사결정 영역에 적합한 솔루션 개발을 돕습니다. 모든 비즈니스는 고유의 운영 환경을 가지고 있고 이에 따라 다양한 요구가 있을 수 있습니다. 하지만 고객은 코리아엑스퍼트의 기술을 이용하여 직접 개발하는 경우, 혹은 개발을 위탁하는 경우 등의 어떠한 경우에서도 최고의 기술력을 기반으로 하는 서비스를 제공받을 수 있습니다. 코리아엑스퍼트는 고객의 요구사항을 충족시키기 위해, 사전에 준비된 기술요소들과 개발 옵션들을 조합하여 특정 의사결정 영역을 위한 다양한 어플리케이션을 제공합니다. 즉, 업계에서 세계 최고라는 위상을 지니고 있는 페어아이작이 의사결정 서비스를 제공할 때 직접 사용하고 있는 업계최고의 의사결정 플랫폼을 공유함으로써 고객은 즉각적인 ROI와 수익 향상의 효과를 볼 것입니다.

SOA 도입 사례 분석을 통한 공통 패턴 제시

1996년 SOA(Service Oriented Architecture)라는 개념이 가트너(Gatner)를 통해 처음 제안된 이후, SOA는 지금까지 IT에 몸담은 사람들에게 많은 관심과 도전의 대상이 되어왔다. 그러나 많은 기고나 관련 서적들이 SOA의 등장 배경이나 정의, 구현 방법론 등 주로 원칙적이고 기술적인 부분에 치우쳐 있어 비즈니스적인 측면에서의 실제적인 SOA구현 형태와 고객에게 전달 가능한 가치에 대해서는 구체적인 가이드가 부족했다. 이번 기고를 통해 SOA를 비즈니스적 관점에서 재조명하고 성공적인 SOA구현을 위한 접근방안을 살펴보겠다. 아울러 실제 SOA 도입 사례를 분석하여 공통적인 패턴을 제시하고자 한다. 마지막으로 ERP, MDM, WEB2.0, BPM, RFID등 기업이 실제로 사용하는 IT환경에서 SOA가 어떤 형태로 사용될 수 있으며 그 가치는 무엇인지 제시하고자 한다.

IT자원의 재사용, 오픈 스탠더드 기반의 기업 애플리케이션 통합, 비즈니스 프로세스의 최적화와 그를 통한 개발, 유지보수 비용의 절감, 실시간 기업구현 등 SOA는 시장변화에 대해 IT차원의 발 빠른 대응을 가능하게 하는 다양한 가치를 쏟아내고 있다.

그러면서도 다른 측면에서는 ‘객체지향과 비슷한 새로운 기술 패러다임’, ‘비즈니스관점에서 IT를 이해하고자 하는 새로운 컨셉’ 또는 ‘소프트웨어 업체들이 제시하는 새로운 영업 캠페인’이라고 대체적으로는 모호하게, 가끔은 혹평에 섞여 회자되기도 한다.

단순히 보자면 SOA는 웹 서비스라는 학계와 IT업계가 모두 인정하는 표준화된 객체(‘기능’을 가지고 ‘인터페이스’ 될 수 있고, 그래서 IT적으로 ‘실행’될 수도 있는 객체)를 기반으로 기업이 가진 모든 프로그래밍 전산 자원을 다시 구성하거나, 아니면 새로 구입하는 소프트웨어의 경우는 웹 서비스화 된 애플리케이션을 도입함으로 기업의 모든 IT는 서비스라는 단위로 통합되고 또 재사용되어 앞서 열거한 바와 같은 ‘IT와 비즈니스가 가져온 오랜 고민거리들을 해결하게 하는 솔루션이며 프레임워크’라 할 수 있다.

하지만, 기업의 모든 전산자원이 서비스단위로 단기적으로 재개발 될 수도 없을뿐더러, 새로 도입되는 SOA 기반의 애플리케이션들 또한 기존의 레거시 자원들과의 통합에 있어 많은 고려 사항을 내포하게 된다. 즉, 도입 과정에서 서비스를 어떤 기준으로 도출하고 체계화하며, 어디에서부터 적용하여 점진적으로 전사화하여 나아갈 것인지, 그리고 SOA를 도입하게 되면 어떤 정해진 방법론을 따르고, 이후에 어떻게 관리하고 준수토록 할 것인지는 단순한 프로젝트 이슈를 넘어서 보다 고민거리를 안겨주게 된다.

이처럼 SOA는 IT 업계의 많은 관심과 도전을 함께 받으면서 지난 몇 년간 프로젝트 형태로 많이 수행되었으며, 이를 통계적으로 분석해보면 SOA의 비즈니스 측면에서의 도입 성숙도 모델을 발견할 수 있다.

즉, 우리보다 앞서 SOA를 도입한 유럽, 북미의 경우를 보면 1)SOA기반의 통합(Integration), 2)서비스기반의 새로운 애플리케이션 개발(Composite Application), 3)메인 프레임의 오픈 아키텍처화(Modernization) 정도로 적용 패턴을 분류할 수 있으며, 국내의 경우는 이와 유사하게 ‘EAI를 대체하는 통합 솔루션’과 ‘비즈니스 프로세스관리(BPM)’, 그리고 최근 들어 조금 더 확장된 개념에서 ‘프로세스 자산화’와 ‘실시간 프로세스 모니터링(BAM)’까지도 포괄적인 SOA 프로젝트 범주로 포함하고 있다.

이를 아래에 나타난 5단계의 SOA 도입 성숙도 모델로 나눠 보면, 대체로 아직은 1～3단계에 걸쳐 수행되고 있음을 알 수 있고, 4단계를 향한 시도가 국내에서도 조금씩 구체화되고 있다.

<그림1>SOA 도입 성숙도 모델

<그림 1>은 오라클이 SOA를 공급하면서, 서비스 컨설팅 협력업체인 엑센추어(Accenture)와 공급 모델이 된 고객인 하트포드(Hartford: 미국 대형 보험회사)와 함께 SOA가 실제로 적용되기 위한 성숙도 모델을 구체화한 좋은 가이드로서 단계별로 세부 목적과 구현 지침을 제시하고 있다.

Level-1 조직을 구성하고 전략화 하여 서비스 기반의 소규모 프로젝트를 수행

Level-2 서비스기반으로 업무 대 업무 통합을 통하여 전략적으로 SOA를 개시

Level-3 여러 업무에 걸쳐 프로세스를 자동화하고, 새로운 애플리케이션을 생성

Level-4 SOA로 구현된 애플리케이션(SLAs/KPIs)을 실시간 평가하며 이를 개선

Level-5 SOA가 기업 업무에 맞춰 최적화되며 B2B, B2C, A2A로 확장

가야 할 길이 멀지만 SOA 도입은 이미 시작되고 있고, 성숙도의 관점에서 어느새 3번째 레벨을 넘어서 보다 향상된 아키텍처와 가치를 향해 계속 진화하고 있다. 앞서 간단히 거론된 국내 모델의 경우는 다음 장에서 오라클의 SOA 접근 방안을 설명하면서 좀더 논의될 것이며, 글로벌 패턴 분석 모델은 그 다음 장에서 SOA 도입을 검토하는 고객에게 방향적 지침을 줄 수 있으리라 본다. 마지막 장에서는 한국 오라클에서 최근 몇 개월에 걸쳐 SOA에 관심 있는 특정 분야별 전문 파트너사들과 함께 수행한 ‘IT환경에서 적용 가능한 SOA 구현 모델들’을 간단히 정리함으로 다음 커버 스토리들에 대한 소개로 활용하고자 한다.

국내 환경과 Oracle의 SOA 제안

최근 몇 년간 국내에서 수행되고 있는 SOA관련 프로젝트를 관찰해 보면 쉽게 그 적용 패턴을 찾아 볼 수 있다. 기존의 EAI를 대체하는 목적에서 ‘서비스(SOA) 기반의 통합’이 가장 활발하게 수행되어 왔고, 이와 더불어 통합 관점의 ‘비즈니스 프로세스관리(BPM)’ 또한 서서히, 그렇지만 빠르게 주목을 받고 있다. 최근에는 이와는 별도로 SOA나 ERP등 대형 프로젝트 수행에 앞서 ‘프로세스를 모델링하고 자산화’ 하는 부분(Process Asset Library(or Management))과 이들을 구축한 후에 ‘실시간으로 프로세스를 모니터링’ 하여 서비스 품질을 높이려는 부분(BAM :Business Activity Monitoring)에 대한 요구 역시 SOA 영역으로 포함시키고 있다.

앞서 SOA의 성숙도 모델에서 레벨 1～3 단계를 거론하며 ‘통합’과 ‘BPM’을 예시하였고 ‘BAM’을 거론하여 레벨 4로의 진입을 시도하고 있다고 표현한바 있다. 이 관계를 보다 주의 깊게 살펴보면, SOA의 성숙도 모델이 전체적으로 단계를 높여 가는 SOA의 라이프사이클을 따르고 있음을 알 수 있다. 즉, SOA를 위한 조직을 구성하고 프로젝트를 설계(1. Modeling)하고, 서비스환경을 구현하여 통합을 준비하며(2. Integration), 업무간 프로세스를 자동화 또는 새로운 업무 프로세스를 구현(3. BPM), 실시간으로 모니터링하고 개선점을 도출(4. BAM)하여 최종적으로는 완전한 SOA 환경을 완성하게 된다(5. SOA 기반의 BPO: Business Process Optimization).

국내 시장의 니즈는 위에 거론된 모든 요구사항을 부분, 전체적으로 적절히 필요로 하고 있으며, SOA를 제공하는 대부분 업체들의 입장에서도 SOA의 전체 라이프사이클에 걸쳐 그 해답을 제시하고자 하고 있다.

한국 오라클은 2006년 9월 BPA(Business Process Analysis) 스위트를 추가함으로 완성된 SOA 제품 로드맵을 제시하게 되었으며, SOA가 필요로 하는 전체 라이프사이클과 SOA가 제시해야 할 모든 성숙도 모델을 One-Stop으로 제공할 수 있게 되었다.

<그림 2>SOA Lifecycle과 Oracle SOA suite]

그림 2에서는 SOA가 성공적으로 구현되기 위한 라이프사이클을 상세하게 나타내고 있으며, 각 단계별로 하단에는 오라클이 제시하는 솔루션들이 함께 제시되어 전체적으로 오라클 SOA 스위트로 제공되고 있다.

Oracle BPA Suite : SOA 프로젝트를 수행하기에 앞서 As-Is와 To-Be 업무 프로세스를 도출하여 분석하고 기업의 환경에 맞는 최적의 프로세스를 찾기 위해 다양한 프로세스 시뮬레이션을 수행하게 된다. 오라클은 BPA(Business Process Analysis)를 통해 이러한 일련의 프로젝트 설계 작업을 성공적으로 수행을 돕고 있으며, 더불어 설계된 프로세스 자산을 BPMN(Business Process Management Notification) 형태로 Repository에 저장, 관리하며 나아가 IT적으로 구현할 수 있는 실행 언어(BPEL)로 전환할 수 있게 한다.

Oracle ESB, BPEL PM : 이렇게 설계된 초기 버전의 실행 언어(BPEL)를 기반으로 원하는 SOA 프로젝트 또는 애플리케이션을 서비스 기반으로 IT관점에서 상세 설계함으로 개발을 완료하게 되며, 이를 위해 오라클은 ESB(Enterprise Service Bus)와 BPEL PM(Process Manager)를 제공하고 있다. ESB를 이용함으로 기업은 기존에 갖고 있는 IT 자산들을 서비스기반으로 전환할 수 있으며, BPEL PM을 통해 전환된 서비스들을 기업의 새로운 비즈니스 니즈에 맞게 애플리케이션 형태로 재구성함으로 SOA의 중요한 가치 중 하나인 Composite Application을 이룰 수 있다.

Oracle Apps Server, Enterprise Manager : ESB와 BPEL PM을 통해 SOA 프로젝트 개발이 완료되면, 오라클 애플리케이션 서버를 통해 SOA 애플리케이션이 운영 가능한 형태로 배포되며, 이후 기업이 운영하게 되는 SOA 관련 서비스, 애플리케이션 및 기타 기업 자산들은 엔터프라이즈 매니저를 통해 통합 관리된다.

Oracle BAM : SOA 프로젝트가 개발관점에서 완료되면, SOA 애플리케이션을 이용하는 최종 고객들에게 제공되는 기업의 서비스와 그 품질에 대해 주요 관리 지수(즉, KPIs 또는 SLAs)들을 실시간으로 모니터링하여 개선점을 도출 할 수 있어야 한다. 오라클 BAM은 SOA를 포함한 기타 모든 애플리케이션들에 표준화된 인터페이스를 지원하여, 기업 활동에 대한 실시간 감지(Aware), 해결 방안(Decide) 및 즉시 조치(Act)할 수 있게 함으로 궁극적으로 최근의 기업들이 지향하고 있는 RTE (Real-Time Enterprise)가 가능토록 한다.

Oracle WSM : 단일 SOA 프로젝트 이후에도 기업 내부적으로 SOA 체제가 지속적으로 유지되고 기업의 다양한 정책들에 맞춰 확장되기 위해서는 거버넌스가 필요하게 된다. 오라클  WSM(Web Service Manager)는 웹 서비스들에 대한 보안과 내부 통제를 기술적으로 지원하기 위해 제공되며, 웹 서비스들에 대한 접근제어에서부터 이들을 사용하는 조직들에 대한 모니터링, 그리고 중앙 집중적 정책 관리 등을 가능토록 한다.

Oracle Jdeveloper : 마지막으로 SOA 프로젝트가 설계단계를 거쳐 관리 규제되는 전체 사이클을 마치게 되면, 어떠한 형태로든 기업의 전체 프로세스에 비춰 프로세스가 개선 또는 자동화될 수 있는 포인트들이 도출되게 되며, 이러한 사항들은 오라클 Jdeveloper(ESB, BPEL PM 등 SOA의 공동 개발 환경)를 이용하여 적절히 반영되고 필요에 따라 재개발 되어 질 수 있다. 재개발이 필요하게 되면 다시 SOA 구현 사이클의 원점으로 돌아가 필요한 부분의 설계와 시뮬레이션을 BPA를 통해 수행하고 그 이후 단계는 앞서 설명한 바와 같이 점진적으로 수행하면 된다.

이러한 순환 반복적 개발 방법론을 통해 SOA의 성숙도 모델은 점차적으로 레벨-4를 거쳐 레벨-5로 진화하게 되며, 최종적으로 기업내의 모든 활동은 BPO(Business Process Optimization), 즉 비즈니스 프로세스적으로 최적화될 수 있다.

한국 오라클은 SOA를 도입함에 있어 위에 제시한 SOA의 라이프사이클에 기반한 점진적이고, 순환 반복적인 적용 방안과 성숙도 모델, 그에 따르는 제품군들을 함께 제안하고 있으며, 이들 제품에 대한 보다 상세한 자료는 http://www.oracle.com/lang/kr/technologies/soa/index.html를 통해 제공하고 있다.

<그림3>Oracle SOA 스위트 구성도

SOA 구현 패턴의 분석

지난해 오라클은 SOA 제안의 가치를 높이고 고객을 보다 깊이 이해하기 위해 지난 수년동안 SOA를 공급하였던 사례들을 토대로 고객과 직접적이고 심도 깊은 인터뷰를 수행하였으며, 다음과 같은 SOA 구현 패턴들이 발견되었다.

즉, 1)SOA기반의 통합(Integration), 2)서비스 기반의 새로운 애플리케이션 개발(Composite Application), 3)메인 프레임의 오픈 아키덱처화(Modernization) 등으로 분석되었으며, 이는 국내의 트렌드와도 유사하나, 메인프레임의 경우 Unix기반으로 리호스팅하는 부분이 국내에서는 대세를 이뤄 왔다.

여기에 덧붙여 ‘프로세스 모델링 및 자산화’와 ‘실시간 프로세스 및 액티비티 모니터링’ 등 새로운 SOA 적용 패턴들이 추가되거나 새롭게 발견되고 있으며, 이는 SOA가 보다 완성적인 형태로 도입 및 성숙되고 있음을 보여준다.

SOA가 도입되기 시작된 후, 지금까지 EAI(Enterprise Application Integration)를 기반으로 추진되던 기업 애플리케이션 통합 시장이 실험적으로 또한 차츰 전략적으로 ESB (Enterprise Service Bus)를 이용한 서비스기반의 프로젝트로 전향되고 있다. 기존 EAI의 벤더, 플랫폼 및 메시지 중심적인 통합으로는 개발 및 유지보수에 있어 시간, 비용, 컨설팅 노력 등 여러 가지 측면에서의 비효율성을 극복할 수 없음이 통계적으로 나타나고 있기 때문이며, SOA의 웹 서비스가 제공하는 ‘범용의 재사용성’과 ‘업무 민첩성’ 등을 장기적으로 얻을 수 없기 때문이다.

실제로 오라클은 연구 결과를 통해, 표준(SOA) 기반의 통합 방법론이 유지보수의 편의성을 (현재까지 나온 기술 중에서는) 최대로 개선할 수 있음과, BPEL을 이용하여 SOA 통합 프로젝트를 하는 경우 변경 사이클을 혁신적으로 단축할 수 있음을 실증하였다. 그 이유 중 하나는 J2EE 개발 경험이 전혀 없는 IT 개발자들도, 불과 2 주일이면 BPEL 프로세스 운영 업무에 친숙해질 수 있기 때문이다.

SOA기반의 통합은 현실적으로 웹 사이트(다수 채널)의 통합 또는 B2B 서비스를 포함하는 애플리케이션 통합과 시장의 니즈에 따라 애플리케이션 통합이 빈번히 일어나는 상황에서 보다 효과적임이 분석되었으며, 실제로 개발과 유지보수 업무에 적용하는 경우 기존 기술과 대비하여 (특정 조건을 가정하여) 각각 50%와 70%이상의 업무(또는 시간) 절감 효과를 나타내었다.

서비스 기반 새 애플리케이션 개발

기업의 필요에 맞춰 MIS, EIS, MRP, MRP II, ERP, BPR, BPM등 많은 애플리케이션들이 명멸하는 가운데 아직도 많은 환경에서 이들 IT자원들은 복합적으로 동시에 사용되고 있다. 다른 시각에서 보면 전문 소프트웨어 업체가 공급한 패키지 솔루션과 기업이 자체 요구사항에 맞춘 자체개발(In-House)로 개발한 솔루션이 혼재하여 옛것과 새로운 것이 상존하는 기업의 IT복잡도를 더욱 높이고 있다.

이렇게 복잡한 환경에서 ‘새로운 애플리케이션’을, 그것도 다른 기존의 (앞서 열거한) 많은 애플리케이션의 유사 기능 또는 프로세스를 차용하여 개발해야 한다면 여간 골치 아픈 일이 아닐 수 없다. ‘개발’ 자체도 쉽지 않겠지만, 변경이 생길 때마다 관련된 애플리케이션들을 고려하면서 ‘유지보수’하는 일은 더욱 어려워지며, 여기에 더해서 ‘다른 새로운 애플리케이션’이 필요하게 되면 그 복잡도와 비용은 갈수록 기하급수적으로 늘어나게 된다.

이렇게 기업이 그때 그때의 필요에 맞춰 개발하여 사용중인 독립적 애플리케이션(Silo applications)들을 대상으로 SOA를 적용하여, 즉 이들 독립적 애플리케이션에 대해 요구되는 기능과 프로세스를 필요한 만큼 웹 서비스 형태로 노출하고 이들을 이용하여 ‘새로운 애플리케이션’을 개발하게 되면, SOA를 처음 도입하는 시점에서의 생산성은 큰 차이가 없겠지만, ‘다른 새로운 애플리케이션’들에 대해서는 향후 기하급수적으로 생산성이 올라감은 물론이며, 이들에 대한 유지보수는 단일한 웹 서비스에 대한 관리 형태로 지극히 단순화된다.

오라클은 이번 연구를 통해 실제로 기업의 복잡한 Silo-ed Applications 환경에서 점진적으로 이들 기능과 프로세스들을 서비스화하여 새로운 애플리케이션이 필요한 경우, 단순히 요구되는 ‘서비스들’이나 ‘프로세스들’을 적절하게 조합만 함으로 새로운 서비스 기반 애플리케이션(Composite Application)을 구성할 수 있음을 확인하였다.

이러한 패턴은 다수의 백엔드 시스템(업체간 통합의 경우 포함)들의 리팩터링, 전사적 BPM의 니즈가 있는 경우, 또는 요구사항을 미리 확정할 수 없는 경쟁환경에 적용하기 유리한 SOA 적용 모델이며, 실제로 이러한 상황에 처한 고객에게 SOA가 적용되어 개발 기간 대비 75%의 단축효과와 90% 이상 구축 비용을 절감 효과를 나타낸다.

메인 프레임의 오픈 아키텍처화

SOA를 기반으로 메인 프레임을 개방 아키텍처 환경으로 이전하는 경우는 드물게 나타나고 있지만, 실제로 SOA가 가치를 가져올 수 있는 대표적인 레거시 환경이기도 하다. 메인 프레임은 대표적인 강결합(Tightly-Coupled) 구조를 갖는 IT자원으로 이를 사용하는 기업은 평균 연간 IT 예산의 70～80%를 메인 프레임의 유지보수에 사용하고 있다.

이러한 메인프레임을 SOA기반으로 바꾸는 일은 많은 비용과 더불어 단계별로 장기적인 마스터 플랜을 세워 진행할 필요가 있으며, 여기서는 한 고객의 예를 들어 보기로 한다.

이 고객은 SOA를 도입하기로 결정한 후에 그 첫 단계로서 메인프레임 애플리케이션의 프로세스 코드를 버리고, BPEL을 이용하여 메인프레임의 비즈니스 로직을 서비스 계층과 프로세스 계층으로 재개발하였으며, 이를 통해 추후 발생한 문제들에 대한 Trouble-Shooting 기간을 크게 단축하게 된다.

두 번째 단계로서, COBOL 비즈니스 로직의 논리적 그룹들을 J2EE로 리팩토링하는 작업을 진행하였으며, 이 변경 작업은 메인 프로세스 플로우와 격리된 상태에서 안정적인 서비스 계층을 기반으로 진행하였기에 점진적이고 유연한 마이그레이션이 가능하였다. 마지막으로 이에 덧붙여 비즈니스 프로세스를 실시간으로 관리하고, 성능의 병목점을 확인하여 프로세스 개선점을 찾기 위해 비즈니스 액티비티 모니터링을 적용함으로 감시 및 개선 업무를 강화하게 된다.

종합해 보면, 비즈니스 로직을 대상으로 서비스(또는 프로세스) 단위로 점진적 재개발을 추진하며, 전체 백엔드 시스템에 대해 다시 리팩토링을 수행하여 단계적인 SOA 업무환경을 구축한 후, 룰 엔진과 BPM, BAM을 클로즈 된 순환 구조 형태로 구현함으로 고객사는 구축 이후 첫 1 년 동안 유지 보수비용을 대략 1백만 달러(1 Million$) 절감하는 성과를 얻었다.

오픈 아키덱처화를 통해 SOA의 가치를 얻을 수 있는 적용 대상은 강결합된(tightly coupled) COBOL 메인프레임 애플리케이션들이 많은 기업, 문제 진단 및 테스트 사이클에 오랜 시간이 걸리는 애플리케이션들을 운용하는 기업, IT유지보수 비용이 많이 드는 오래된 애플리케이션들이 많은 기업들이 될 수 있으며, 이들 기업은 위에서 간단히 사례를 든 바와 같이 BRE, BPM, BAM등을 추가로 적용하여 ‘Closed Loop Feedback’을 구성함으로 업무 프로세스를 최적화할 수 있다.

실제 SOA 적용 가능 업무 모델

지금까지 SOA의 도입 성숙도 모델과 SOA가 성공적으로 구현되기 위한 라이프사이클, 그리고 그에 따른 프로젝트 수행 패턴들을 간단하게라도 분석해 보았다. 그렇다면, 실제로 기업이 관심 있어 하는 여러 가지 전산 환경, 즉 ERP, MDM(Master Data Management), BPM (BPR), WEB2.0, RFID등 이미 기업이 사용 중이거나 향후 도입 예정인 이들 업무환경에서 SOA는 어떤 형태로 사용될 수 있고, 또 사용자들에게 어떤 가치를 가져 다 줄 수 있는지 살펴보고자 한다.

이를 위해 한국오라클은 앞서 제시한 IT기술 업무 분야들에 전문성을 갖춘 오라클 협력사들과 각 분야별로 SOA를 도입하기 위한 방안을 함께 고민하였고, 그 결과로서 SOA 프로토타입 시스템들을 구축하여 보았다. 이번 장에서는 앞으로 이어갈 SOA시리즈들에 대한 간단한 소개를 함으로 실용의 측면에서 SOA를 전체적으로 바라볼 수 있도록 돕고자 한다.

▶전사적 자원관리 시스템(ERP)은 기업내의 생산, 회계, 인사 등의 기업 전반의 업무 프로세스들을 지원하고 이 정보들을 상호 공유하여 신속한 의사결정을 지원하는 패키지 소프트웨어로 이 자체가 기업의 모든 업의 노하우와 프로세스를 가지고 있다. 그렇기 때문에 ERP를 도입하기에 앞서 기업이 가진 현재의(As-Is) 모든 프로세스 자산을 테이블 위에 올려놓고 토론을 거듭 거쳐 향후 가져가야 할(To-Be) 최적의 프로세스를 도출하게 된다. 이 과정에서 여러 번의 시뮬레이션이 일어나게 되고, 최종의 결과물은 프로세스 자산으로서 기록되게 된다. 이러한 일련의 프로세스 모델링, 시뮬레이션 및 자산화 업무에 SOA 라이프사이클 중 첫 번째인 ‘설계 및 자산화’가 가장 적합할 것이며, 대표적인 솔루션으로는 오라클 BPA 스위트를 들 수 있다. 이후 ERP가 기업의 IT시스템에 적용되는데 있어 가장 우선 고려할 부분은 Non-ERP 시스템과의 인터페이스가 될 것이며, 이때 단순한 데이터/메시지 통합이 아니라 프로세스 관점에서 통합함으로, Non-ERP 시스템들과 단순 반복적으로 일어나는 프로세스들을 자동화할 수 있고, 더불어 새로운 애플리케이션 요구가 발생하였을 때 Non-ERP와 ERP시스템의 서비스와 프로세스들을 차용하여 쉽게 구현할 수 있게 해준다(Composite Application). 마지막으로 ERP의 주요 프로세스 모듈들 또는 Non-ERP의 주요 업무 프로세스를 BAM을 이용하여 실시간으로 모니터링함으로 업무에 발생한 문제점 또는 프로세스상의 병목/문제점을 통합 대시보드를 통해 한눈에 파악하게 함으로 프로세스 개선과 업무 최적화를 꾀할 수 있게 한다.

▶Master Data Management(MDM)은 기업내부에 걸쳐 불완전 또는 중복적으로 분포되어 사용중인 중요 데이터, 즉 상품, 설비, 자재 또는 고객 데이터들을 완전한 기준 데이터로 통합 관리하는 시스템이다. MDM이 기업의 다양한 업무 또는 분석 시스템들, 그리고 협력사의 관련 애플리케이션들과 연동하여 기준 데이터를 통합하고 배포하는 관점에서 SOA는 이들간의 인터페이스를 표준화하고 필요한 업무별로 프로세스를 최적화할 수 있다. SOA라고 하는 표준 기술을 통해 데이터 서비스가 제공됨으로 기업 내 다른 업무 시스템들 외에도 고객 및 협력사 IT환경에서 쉽고 빠른 마스터 데이터 기반의 업무 개발을 가능케 하며, 유지보수에 있어서도 기존 기술들에 대비하여 최대 70%이상 비용과 노력을 절감할 수 있게 한다. 또한 이렇게 구축되어 사용되고 있는 MDM과 다른 IT시스템들간의 데이터를 모니터링하여 기업의 여러 가지 서비스 품질 및 주요 업무 성과 지수들을 판단하고, 그 품질을 높이는데 기여할 수 있다. .

▶BPR(Business Process Re-Engineering)은 기업의 내부 또는 외부의 고객요구사항을 접수하여 최종적으로 전달되는 일련의 과정을 하나의 프로세스로 설정하여, 경쟁사보다 월등한 성과를 내기 위해 시도하는 프로세스 혁신 운동이다. 국내의 경우는 주로 금융권에 먼저 도입되어 고객업무를 지원하는 백엔드 프로세스(Backend Process)를 대상으로 여신 및 수신, 외환, 지원, 카드 등 다양한 업무에 적용을 완료했거나 현재 구축 중에 있다. BPR�