[번역] 제어 역전 컨테이너와 의존성 주입 패턴 (1/4)

마틴 파울러(Martin Fowler)

자바 커뮤니티에서는 줄곧 경량 컨테이너들이 경쟁적으로 출시 되고 있습니다. 이들은 다른 프로젝트에서 가지고 온 S/W 부품을 조립해서 하나로 통합된 응용 S/W를 만드는 데 도움이 됩니다. 이 컨테이너들은 S/W 부품들을 연결하는 방법에 대한 공통 패턴을 근간으로 하고 있습니다. 이 개념을 흔히 제어 역전(Inversion of Control)이라고 부릅니다. 이 글에서는 이 패턴을 의존성 주입(Dependency Injection)과 서비스 위치탐색기(Service Locator)로 세분화하고 이들을 비교함으로 이 패턴의 작동 방식을 파고들어보려고 합니다. 이 두 가지 방식 중 어떤 것을 선택할지 논하는 것보다 S/W 부품를 이용하는 코드에서 설정을 분리하자는 원칙이 더 중요합니다.

주류 J2EE의 대안을 만들려는 엄청난 규모의 활동은 기업용 자바 세상에서 흥미있는 일 중 하나입니다.그 중 많은 수가 오픈 소스에서 일어나고 있습니다. 상당수는 무겁고 복잡한 주류 J2EE 세상에 대한 반발이지만 다수는 대안을 찾으려는 탐구와 창의적인 시도이기도 합니다. 어떻게 각기 다른 요소를 함께 연결할 것인지를 다루는 것, 예를 들어 서로를 잘 알지 못하는 여러 팀에서 각자 만든 웹 컨트롤러 아키덱처와 데이터베이스 인터페이스를 어떻게 하나로 묶을 것인지가 이것들이 해결하려는 공통 사안입니다. 다수의 프레임워크가 이 문제를 해결했고 그중 몇몇은 다른 계층의 컴포넌트들을 조립하는 일반적인 기능까지 제공하는데 이르렀습니다. 이들을 종종 경량 컨테이너라고 부르는데 피코 컨테이너와 스프링을 예로 들 수 있습니다.

이 컨테이너들은 인상적인 몇가지 설계 원칙에 기초하고 있습니다. 이 원칙들은 특정 컨테이너는 물론 자바라는 플렛폼까지 넘어서 적용될 수 있습니다. 여기서 이 원칙 중 몇가지를 탐구해보려 합니다. 예로 사용한 언어는 자바이지만 내가 썼던 다른 원칙들 대부분이 그런 것처럼 다른 객체지향 환경(특히 .Net)에도 적용할 수 있습니다.

S/W 구성 요소들을 하나로 묶는 주제를 다루려면 서비스와 컴포넌트라는 두 단어를 둘러싼 껄끄러운 용어 문제 먼저 해결해야 할 것 같습니다. 이 둘의 정의와 관련된 길고 모호한 글들을 쉽게 찾을 수 있습니다. 저는 여기서 제가 이 단어를 어떤 의미로 사용하는지 말하려고 합니다.

전 컴포넌트를 재사용되는 소프트웨어 덩어리를 의미할 때 사용합니다. 컴포넌트는 컴포넌트 제작자가 어떤 영향도 끼칠 수 없는 응용 소프트웨어에 변경 없이 재사용 할 수 있습니다. 여기서 '변경 없이'라고 한 건 응용 소프트웨어가 컴포넌트 제작자가 허용한 방법으로 컴포넌트를 확장해서 행위를 바꾸어 사용할 수는 있을지언정  컴포넌트의 소스 코드를 고치지는 않는다는 것을 뜻합니다.

서비스는 외래 애플리케이션이 사용한다는 측면에서는 컴포넌트와 비슷합니다. 주요 차이점이라면 컴포넌트가 (jar 파일, 조립, DLL, 소스코드 삽입등 같이) 지역적으로 사용될 것이라 보는 반면에 서비스는 동기 방식이든 (웹 서비스, 전문 시스템, RPC, 소켓 등) 비동기 방식이든 모종의 인터페이스를 사용해 원격에서 사용 되리라는 것입니다.

이 글에서는 대부분 서비스라고 쓰겠지만 상당수의 논리는 지역적 컴포넌트에도 똑같이 적용될 수 있습니다. 사실 원격 서비스를 쉽게 사용하려면 흔히 로컬 컴포넌트 프레임워크 같은 것이 필요합니다. 컴포넌트냐 서비스냐에 대해 논하는 글은 읽는 것도 쓰는 것도 피곤한 일입니다. 그리고 요즘은 서비스가 훨씬 더 인기있습니다.

순진한 예제

모든 것을 분명하게 하고자 실행 가능한 예제 하나를 사용하려 합니다. 제가 흔히 쓰는 예제가 그렇듯 이 예제도 엄청나게 단순합니다.  비현실적으로 보일 만큼 작지만 복잡한 실제 예의 수렁에 빠지는 일 없이 뭐가 어찌 돌아가는지 눈으로 확인할 수 있는 정도는 되리라 생각합니다.

예제는 특정 감독이 연출한 영화의 목록을 찾아주는 컴포넌트 입니다. 이 놀랍도록 유용한 기능이 메소드 하나로 구현되어 있습니다.

class MovieLister...
    public Movie[] moviesDirectedBy(String arg) {
        List allMovies = finder.findAll();
        for (Iterator it = allMovies.iterator(); it.hasNext();) {
            Movie movie = (Movie) it.next();
            if (!movie.getDirector().equals(arg)) it.remove();
        }

        return (Movie[]) allMovies.toArray(new Movie[allMovies.size()]);
    }

기능 구현이 극단적으로 단순합니다. 보유하고 있는 모든 필름 정보를 달라고 (조금 있다 얻게 될) 찾기 객체에게 요청합니다. 그리고 목록을 뒤쳐 반환할 특정 감독의 작품을 뒤집니다. 이 순진한 코드는 단지 이 글에서 진짜 다루려고 하는 내용을 위한 골격에 지나지 않으므로 손대지 않을 겁니다.

이 글에서 진짜로 관심 있는 것은 찾기 객체, 특히 MovieLister와 특정 찾기 객체를 연결하는 방법입니다. 이것이 흥미있는 이유는 이 멋진 movieDirectedBy 메소드가 영화를 보관하는 방식과 전혀 상관 없이 움직였으면 하기 때문입니다. 그래서 메소드는 단지 찾기 객체를 참조하기만 하면 되고 그 파인더는 findAll 메소드 호출에 어떻게 응답해야하는지 알기만 해도 되었으면 합니다. 찾기 객체의 인터페이스를 정의하는 것으로 이것을 실현할 수 있습니다.

public interface MovieFinder {
    List findAll();
}

이제 이렇게 해서 결합이 잘 분리되었습니다. 하지만 어느 지점에선가 실제 영화 목록을 얻으려면 구상 클래스를 얻어야 합니다. 한번 생성자에 이 코드를 넣어보겠습니다.

class MovieLister...
  private MovieFinder finder;
  public MovieLister() {
    finder = new ColonDelimitedMovieFinder("movies1.txt");
  }

구현 클래스의 이름은 콜론으로 구분되어 있는 텍스트 파일에서 목록을 얻으려고 한다는 뜻입니다. 단지 어떤 구현체가 있다는 사실만이 중요하므로 상세한 부분은 생략하겠습니다.

이 클래스를 혼자서만 쓴다면 모든 것이 훌륭하고 멋집니다. 그런데 친구들이 이 멋진 기능을 쓰고 싶은 열망에 압도되어 이 프로그램를 복사해달라고 할 때 어떤 일이 일어날까요? 그 친구들도 "movies1.txt"라는 파일에 콜론으로 구별된 형태로 영화 목록을 보관하고 있다면 모든 것이 환상적이겠죠. 만약 영화 목록 파일의 이름이 다르다면 설정 파일에 파일 이름을 넣도록 해서 쉽게 해결할 수 있습니다. 그런데 만약 완전히 다른 형태로 영화 목록을 저장하고 있다면 어떨까요? SQL 데이터베이스나 XML이나 웹 서비스나 형식이 다른 텍스트 파일이면 말입니다. 이 경우에는 다른 클래스로 데이터를 얻어 와야 합니다. 이미 MovieFinder 인터페이스를 정의 했기 때문에 moviesDirectedBy 메소드를 바꾸지 않아도 됩니다. 그렇지만 여전히 올바른 finder 구현물의 인스턴스를 얻어 제자리에 두는 어떤 방법이 필요합니다.

그림 1 : 목록 클래스에서 단순히 생성했을 때 의존성 관계

그림 1에서 지금의 의존 관계를 볼 수 있습니다. MovieLister 클래스는 MovieFinder 인터페이스와 그 구현물에 종속되어 있습니다. 인터페이스에만 종속되어 있으면 좋겠는데 어떻게하면 인스턴스를 가져와 쓸 수 있을까요?

P of EAA에는 이런 상황을 Plugin 패턴으로 설명하고 있습니다. 컴파일 시점에는 찾기 객체의 구현 클래스가 프로그램에 연결되어 있지 않습니다. 친구들이 어떤 것을   쓰려는지 모르기 때문입니다. 대신 목록 객체가 어떤 구현물과도 작동되고 나중에 언젠가 그 구현물을 별 조작없이 장착할 수 있으면 좋겠습니다. 문제는 어떻게 우리의 목록 객체가 구현 클래스에 대해 잘 모르면서도 여전히 인스턴스와 협력하여 해야 할일을 할 수 있도록 하느냐는 것입니다.

이것을 실제 시스템으로 확대해서 보겠습니다. 실제 시스템에서는 이런 서비스와 컴포넌트가 수십개나 있을 것입니다. 이 컴포넌트들의 사용하는 곳마다 인터페이스를 통해 호출하도록 추상화 할 수 있습니다. 만약 컴포넌트가 그 인터페이스에 맞지 않다면 어댑터를 써야겠죠. 하지만 만약 이 시스템을 여러가지 다른 방식으로 배포하기 원한다면 이 서비스들과의 상호작용할 수 있도록 처리하기 위해 플러그인을 사용해야 합니다. 그러면 여러 다른 구현물은 여러 다른 배포 환경에서 사용할 수 있습니다.

이제 핵심 문제는 이 여러 플러그인들을 어떻게 조립해서 한 애플리케이션으로 만들 수 있느냐는 것입니다. 이것이 새로운 경량 컨테이너들이 해결하려고 하는 주된 문제 영역 중 하나입니다. 그리고 보편적으로 제어 역전을 그 해법으로 사용합니다.

제어 역전


경량 컨테이너들을 소개할 때에 왜 그것들이 유용한지를 말하면서 이유가 "제어 역전"을 구현했기 때문이라고 할 때면 전 무척 당황스럽습니다. "제어 역전"은 프레임워크들이 갖는 공통적인 특성입니다. 그렇기에 경량 컨테이너들이 자기들은 제어 역전을 쓰기 때문에 특별하다고 말하는 건 마치 내 차에는 바퀴가 있어서 특별하다고 하는 것과 같습니다.

질문해야 할 것은 어떤 제어를 역전하려고 하느냐는 것입니다. 제가 처음 접했던 제어 역전은 유저 인터페이스의 중심 제어에서였습니다. 초기 유저 인터페이스들은 애플리케이션 프로그램에서 제어를 했습니다. 흔히 "이름을 입력하시오", "주소를 입력하시오" 같은 일련의 명령 문구를 가지고 있고 프로그램이 이것들을 하나씩 물어보고는 답을 입력 받곤 했습니다. 그래픽(몇몇 스크린 기반도) 유저 인터페이스에서는 유저 인터페이스 프레임워크가 제어권을 가지고 있고 프로그램은 화면의 각 요소에 대한 이벤트 처리자만 마련하고 있으면 됩니다.  프로그램의 주 제어권은 역전된 것입니다. 애플리케이션에서 프레임워크로 옮겨진 것이지요.

이 새로운 컨테이너들에서의 역전은 플러그인 구현물을 찾을 방법과 관련되어 있습니다. 우리의 순진한 예제에서 목록 객체는 찾기 구현물의 인스턴스를 직접 생성해서 씁니다. 이렇게 하면 찾기 객체를 플러그인이라고 할 수 없습니다. 경량 컨테이너들이 사용하는 접근법은 플러그인을 사용하는 누구라도 어떤 관례를 따르기만 하면 독립된 조립 모듈이 구현물을 목록 객체에 주입하도록 보장합니다.

결국 이런 패턴을 지칭하는 보다 지협적인 이름이 필요한 것 같습니다. 제어 역전은 너무 일반적인 용어라서 사람들이 혼란스러워 합니다. 다양한 IoC 지지자들과 많은 토론을 한 결과 의존성 주입이라고 부르기로 합의하였습니다.

이제 여러가지 형태의 의존성 주입에 대해서 말하려고 하지만 여기서 확실해 해두고 싶은 것은 이것이 플러그인 구현물에서 애플리케이션 클래스의 의존성을 제거하는 유일한 방법이 아니라는 것입니다. 의존성 제거에 쓸 수 있는 다른 패턴으로 서비스 위치탐색기가 있습니다. 이에 대해서는 의존성 주입을 설명하고 나서 다루겠습니다.

[번역] 제어 역전 컨테이너와 의존성 주입 패턴 [1][2][3][4]

---------

워낙 유명한 글이지만 막상 이 글을 읽는 사람도 IOC나 DI의 의미를 이해하고 쓰는 사람이 많지 않은 것 같습니다. 스프링을 쓰는 몇몇 프로젝트에 참여해서 일해본 적이 있지만 매번 스프링을 이런식으로 쓰는 게 무슨 의미인가? 하는 회의만 들었습니다. 그래서 출퇴근 시간에 조금씩 번역해서 올려보려고 합니다. 대충 보니 네 부분으로 나눌 수 있을 것 같습니다. 

by 박성철 | 2009/09/28 00:37 | 프로그래밍 이야기 | 트랙백 | 덧글(0)

트랙백 주소 : http://gyumee.egloos.com/tb/2512493
☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]

:         :

:

비공개 덧글

◀ 이전 페이지다음 페이지 ▶