이 번호에 다루려고 하는 디자인 패턴은 Composite 패턴[1]이다. 이 패턴은 시스템 디자인 과정에서 항상 생각하게 되는 인터페이스(interface) 설계 문제와 거의 대부분의 시스템 구조에서 등장하는 객체간의 tree 구조를 멋드러지게 해결한다는 점에서 그 중요성을 가진다고 볼 수 있다고 생각해서, 이 번호의 이야기 거리로 삼았다. 그럼 이야기를 시작해보자.

인터페이스(Interface)

시스템을 디자인하다 보면 항상 생각하게 되는 문제 중의 하나가 인터페이스(Interface)이다.여기서 인터페이스란 Graphic User Interface를 의미하는 것이 아니고 소프트웨어 모듈(module)에서 외부에 서비스(service)를 제공하기 위한 창구(?) 역할을 하는 것을 의미한다. 필자는 인터페이스만 잘 설계해도 전체 시스템의 절반 정도는 성공한 것이라는 생각을 가지고 있다. 그 이유는 좋은 인터페이스를 통해서 하나의 시스템을 구성하는 여러 모듈간의 의존성(dependency)을 줄일 수 있으며, 또한 해당 모듈의 투명성(transparency)을 높일 수 있다. 결과적으로는 시스템의 각 모듈의 재사용성을 높이고 든든하며, 유지 보수가 좋은 시스템을 설계하게 될 수 있다는 것이다. 이런 이야기는 인터페이스에 대한 개인적인 생각이라기보다는 인터페이스에 대해서 이야기가 나오면 누구나 이야기하는 그런 내용이다. 하지만, 이런 중요성에도 불구하고, 시스템 설계할 때, 인터페이스를 소흘이 하는 경향을 경험으로 많이 보아왔다.

사실 명시적으로 언급을 하지는 않았지만, 지금까지 필자가 써온 디자인 패턴관련 글의 내용에는 알게 모르게 인터페이스에 관련된 내용이 포함되어 있다. 더구나, 필자가 디자인 패턴 글에서 사용하고 있는 Java 프로그래밍 언어에는 이미 인터페이스에 대한 개념이 잘 반영되어 있다는 것을 ‘interface’라는 예약어(keyword)를 통해서 명시적으로 발견할 수 있다. 이 번호에서는 그 동안 말없이 사용해 왔던 인터페이스라는 개념을 Composite 패턴을 통해서 아주 조금 드러내 놓고 생각해 보려고 하는 것이다(사실 필자가 객체지향 뉴스레터 2호에서 인터페이스와 관련한 내용을 정리하고 싶다는 이야기를 했었는데.. 필자의 사정으로 그러하질 못했다^(^).  다음 절에서부터는 파일 시스템(file system)의 예를 통해 Composite 패턴이 어떻게 적용될 수 있으며, 이 때 이 패턴이 인터페이스와 관련하여 어떤 이야기들이 논의되어 질 수 있는지를 생각해 보려고 한다. 그럼 이야기를 시작해 보자.

파일 시스템(file system)

Composite 패턴을 설명하기 위해서 컴퓨터를 사용하는 모든 사람들에게 익숙한(매일 사용하는 시스템이니까..) 파일 시스템(file systems)의 예를 들어 설명하겠다. 사실 이 절의 내용은 John Vlissides가 자신의 책 Pattern Hatching[3]에서 패턴을 사용해서 시스템을 디자인 한다는 것이 무엇을 의미하는지를 보이기 위해서 사용한 예를 필자가 여기서 극히 일부분만 본 글의 의도에 맞추어서 수정하여 다룬 것이다. (패턴에 관심을 가지고 있는 독자는 Pattern Hatching의 2장을 꼭 읽어 보기를 권한다. 패턴의 중요성(또는 유용성)을 극명하게 들어내주는 글로 아주 인상적이다. 요즘 필자는 개인적인 프로젝트의 아이디어를 얻고자 John의 글을 다시 꼼꼼히 읽고 있는데, 그 내용에 다시 한번 감동 받고 있다.)

그럼 이제 본격적인 논의로 들어가자. 사람들이 컴퓨터를 사용할 때, 알게 모르게 항상하고 있는 작업 중의 하나가 디렉토리(directory) 또는 파일(file)의 생성, 삭제, 복사, 이동, 수정에 관한 작업일 것이다. 컴퓨터를 그냥 키고 끄기만 해도 해당 시스템에 설치되어 있는 운영체제(Operating System)관련 파일 중에서 이와 관련된 파일에는 조그마한 변화가 가해질 것이다. 이처럼 현대 컴퓨터 시스템의 개념에서 파일 시스템의 중요성은 엄청난 것이다. 다시 말해서, 파일 시스템 없는 컴퓨터 시스템은 생각할 수 없다. 그러나, 그 중요성에도 불구하고 너무도 흔한 작업이라, 컴퓨터 시스템을 사용하고 있는 사람들 중에서 그 중요성을 인식하고 있는 사람은 거의 없는 것 같다. 마치 우리가 살아있으면서 공기의 중요성을 망각하고 있듯이..

어쨋든, 이렇게 중요한 파일 시스템을 우리가 한 번 디자인 한다고 생각해 보자. 자 그럼, 이제 무엇부터 생각을 해야 할까?  여기서는 새로운 개념의 파일 시스템을 디자인한다는 것 보다는 기존의 파일 시스템의 개념을 바탕으로 나름대로 그 내부를 디자인 한다는 것을 가정한다. 이런 가정하에서 우리가 파일 시스템을 머리 속에 떠올릴 때, 쉽게 생각할 수 있는 것은 파일 시스템은 디렉토리와 파일이라는 크게 두 개의 요소로 구성되어 있다는 것이다.  따라서, 이런 구조를 가지는 시스템을 디자인 해 보라고 하면 아마 대부분의 개발자나 시스템 디자이너는 각 요소를 하나의 객체로 나타내어 그림 1과 같이 디자인 할 것으로 생각이 든다(이야기를 진행시키기 위한 fiction..  ^(^).

그림 1. 파일 시스템 디자인 #1

그림 1과 같은 디자인도 별 문제는 없어 보인다. Directory 객체는 여러 파일 타입에 상관없이 동일한 “File” interface를 통해서 여러 타입의 File객체들을 일관성(uniformity)을 가지고 다룰 수 있을 뿐만 아니라, 자신과 같은 타입의 객체(Directory)를 포함시킬 수 있게 되어 있다. 디렉토리와 파일간의 관계만 보면 파일 시스템 구조 자체에 대해서 무리가 없는 디자인으로 볼 수 있을 것이다. 하지만, 생각을 좀 더 넓혀 보자. 실질적으로 디렉토리와 파일을 다루는 클라이언트(client)의 입장에서 생각해 보자. 다시 말해서, 디렉토리와 파일을 생성, 수정, 이동 등의 일을 하는 클라이언트의 입장에서는 그림 1과 같은 디자인이 어떻게 보일까를 생각해 보아야 할 것이다.

그림 1과 같은 디자인으로 구현되어 있는 파일 시스템을 이용하는 클라이언트를 구현한다고 가정해 보자. 이 클라이언트에서 디렉토리의 이름과 파일의 이름을 읽어 들이는 것과 같은 작업을 구현하기 위해서는 어떻게 해야 하는가?  대상이 되는 객체의 타입이 Directory인지 File인지를 먼저 구분해야 하는 작업을 해야 할 것이다. 그 이유는 각각의 객체가 서로 다른 외부의 응용프로그램들에게 제공하는 동일한 인터페이스 (getName())가 없기 때문이다. 다시 말해서, Directory 타입이 객체는 pubic visibility를 가지는 자신에 속한 method인 getName()을 통하고, File 타입의 객체는 File이라는 interface의 getName()을 통해서 외부에 해당 객체의 이름 정보를 담고 있는 attribute의 값을 볼 수 있는 서비스를 제공하고 있는 것이다. 결과는 소스 1과 한 구현 예다.

Class AClient {
             …
             Directory rootDir_;
             File file_;
             Directory dir_;
             …
             void fileList() {
                           for(int i=0; i < rootDir_.getFileSize(); i++) {
                                        System.out.println((rootDir_.getFile(i)).getName());
                           }
             }
             …
             void dirList() {
                           for(i=0; i < rootDir_.getDirSize(); i++) {
                                        System.out.println((rootDir_.getDir(i)).getName());
                           }
             }
             …
}

소스 1

소스 1을 보면 rootDir_에 포함되어 있는 Directory와 File 객체에 따라서 서로 다른 method(fileList(), dirList())를 두어 구현되어 있다. 이렇게 해당 작업을 하기위해서 두 개의 method로 구지 구분할 필요는 없지만, 앞에서 이야기했듯이 Directory와 File이라는 타입을 어떤 형태로든 소스에서 static하게 구분해 주어야만 한다. 즉, 그림 1과 같은 디자인을 사용할 경우는 이런 파일 시스템을 사용하는 클라이언트의 소스가 복잡해지는 것을 피할 수 없을 것이다. 그럼 다른 대안을 없는 것인가?

Composite 패턴

그림 1과 같은 디자인의 문제점으로 생각되는 것은 Directory와 File 객체가 서로 다른 인터페이스를 가지고 있다는 것이다. 그렇다면 그림 1의 디자인이 발생시키는 클라이언트의 복잡성을 줄이기 위해서 두 객체가 동일 인터페이스를 가지게 하면 어떨까? 그림 2는 그림 1의 디자인의 대안으로 Directory와 File 두 객체가 Node라는 동일한 인터페이스를 가지는 구조로 되어 있다.

그림 2. Composite 패턴을 적용한 파일 시스템 디자인

그림 2의 디자인은 Composite 패턴(아래 그림 3)을 적용한 것으로 tree 구조를 가지는 객체들을 표현할 때 아주 유용하게 적용할 수 있는 패턴이다. 이 글의 예에서는 File이 tree 구조의 leaf역할을 하고 Directory는 또 다른 Directory나 File 객체를 포함하는 composite의 기능을 가지는 internal node의 역할을 하고 있기 때문에, Composite 패턴을 여기서의 예에 적용하면 그림 2과 같이 구성될 수 있는 것이다 (tree구조를 이야기할 때 사용되는 leaf, internal node와 같은 용어를 혹시 모르는 독자가 있다면 자료구조 책을 꼭 보기 바란다. 프로그램을 짜는 사람이 tree 구조를 모른다는 것은 전혀 말이 되지 않기 때문이다).

그림 3. Composite 패턴

그림 2의 디자인을 살펴보자. 이 디자인은 그림 1의 디자인에서 문제점으로 생각되던 것을 보완하기 위해서 Directory와 File이 Node라는 동일한 인터페이스를 외부에 제공하도록 되어 있다. 따라서, 해당 파일 시스템을 사용하는 클라이언트는 Directory와 File을 구분하지 않고 동일하게 대상 Node에 대해서 여러 가지 작업을 할 수 있게 된다. 그만큼 해당 파일 시스템을 사용하는 클라이언트의 복잡성이 사라진다는 것을 의미한다. 이외에도 Directory가 다시 Directory나 File을 포함하는 구조를 나타내기 위해서 Directory가 Node를 aggregate하도록 하였다.

구체적으로 클라이언트의 소스 1은 소스 2와 같이 단순화될 수 있을 것이다. 소스 2에 보면 클라이언트에게는 해당 Node가 Directory인지 File인지 전혀 드러나 있지 않다. 하지만, 클라이언트는 소스 1에서와 마찬가지로 rootDir_가 포함하고 있는 Directory와 File 객체의 이름을 나타내는 attribute를 외부에 제공하는 서비스를 사용할 수 있다. 즉, 클라이언트가 Directory와 File에 대해서 가지는 인터페이스는 Node 하나이므로 클라이언트는 Directory와 File에 상관없이 동일한 메소드(getChild())를 사용할 수 있게 된 것이다.

Class AClient {
             …
             Node rootDir_;
             …
             void list() {
                           for(int i=0; i < rootDir_.getSize(); i++) {
                                        System.out.println((rootDir_.getChild(i)).getName());
                           }
             }
             …
}

소스 2

위에서 두 개의 디자인을 비교하여 보았다. 첫 번째 디자인은 각각의 객체가 서로 다른 인터페이스를 외부에 제공함으로써, 해당 파일 시스템을 사용하는 클라이언트가 각각의 객체 타입을 구분하여 해당 객체의 서비스를 이용하도록 되어 있다. 반면에 두 번째 디자인은 두 객체가 동일한 인터페이스를 외부에 제공함으로써 이렇게 디자인된 파일 시스템에 대한 클라이언트가 해당 객체의 타입을 고려하지 않고, 즉, 시스템이 투명성(transparency)을 제공하여, 서비스를 일관성(uniformity) 있게 이용할 수 있게 되어 있다. 어느 디자인이 좋다고 생각되어 지는가? 답은 디자인 하고 있는 시스템의 성격에 따라 다르다는 것이다. 그 이유는 이렇다. 먼저 첫 번째 디자인의 경우에는 클라이언트가 복잡해지는 문제가 있지만, static하게 타입을 결정할 수 있기 때문에, 좀 더 안정적인 시스템을 처음부터 구현할 수 있다는 장점이 있다. 이와 반대로 두 번째 디자인은 앞에서 이야기한대로 해당 객체의 타입이 runtime에 결정됨으로써 타입 오류로 인한 오동작을 유발할 수 있는 소지를 남기게 된다. 이 것은 시스템에 투명성을 제공하는 것에 대한 대가인 것이다. (눈치 있는 독자는 그림 3의 Composite 패턴에서 method 사용의 이상한 점을 발견했을 것으로 생각되는데..) 사실 안정성이 먼저냐, 아니면 투명성이 먼저냐 하는 것에 대한 결정은 Composite 패턴 내에서 add, remove, getChild 같은 leaf에게는 의미 없는 method를 component에 넣느냐, 아니면 composite에 넣느냐를 결정하는 곳에서도 해야 한다. 왜 그런가? add, remove, getChild의 method를 component에 넣게 되면 투명성이 제공되지만, leaf에서는 의미 없는 method에 대한 구현 작업을 해야 하고, 이 method들을 composite에 넣으면 투명성은 잃어버리지만, static하게 타입이 결정되고 leaf에서 의미 없는 method에 대한 구현 작업을 할 필요성이 없어지기 때문이다.

결론적으로 그림 1의 디자인과 그림 2의 디자인의 차이는 파일 시스템이 외부에 제공하는 인터페이스에 대한 차이라고 볼 수 있을 것이다. 사실 이 문제가 별 것 아닌 것처럼 보인다고 생각하는 독자도 있을 수 있지만, 그것은 이 글에서 다루고 있는 예의 내용이 단순하기 때문에 그렇게 보이는 것 뿐이다. 실재의 복잡한 시스템에서는 인터페이스의 설계가 전체 시스템의 성공여부를 결정지을 수 있는 중요한 요소로 작용할 수 있다.

Composite 패턴에 대해서도 이야기하고, 이를 통해서 인터페이스라는 주제에 대해서도 조금 이야기를 해 보려는 욕심을 가지고 글을 썼는데..  너무 두서 없는 글이 되어 버린 것 같다. 인터페이스를 이 번호에서 명시적으로 언급했으니까, 앞으로 기회가 될 때마다 논의해 보려고 한다. 잘 될지 모르겠다. ^(^ 지난 호에서와 마찬가지로 GoF책 저자들이 밝히고 있는 Composite 패턴의 의도를 정리하는 것으로 이 번 글을 마무리 짓겠다.

의도(Intent)

Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly

Composite 패턴은 객체간의 존재하는 부분-전체의 계층 구조를 tree 형태로 나타내주며, 클라이언트가 각각의 객체와 객체를 포함하는 객체(composite)를 일관되게 다룰 수 있게 해 준다.

관련 패턴

이 패턴의 저자들이 관련패턴이라고 언급한 패턴은 Responsibility, Decorator, Flyweight, Iterator, Visitor이다[1]. 지금까지 다루어왔던 패턴들보다 그 수가 많은 이유는 Composite 패턴은 그 자체가 아주 기본적인 tree 구조만을 나타내고 있기 때문에 디자인에 따라서 구조에 관계된 다른 패턴이나 행위와 관련된 다른 패턴과 유기적으로 엮어질 수 있는 가능성이 아주 많기 때문이 아닌가 생각해 본다.

맺음말

이 번호에서 다룬 Composite 패턴 또한 클래스 세 개로 이루어진 아주 단순한 구조이다. 하지만, 이 패턴을 가지고도 생각할 것들은 아주 많다. 이 글에서는 그 중에서 인터페이스 측면에서 부각을 시키려고 시도해 보았는데 잘 되었는지 모르겠다. 다른 것도 마찬가지라고 생각하지만, 컴퓨터 소프트웨어 시스템에서 인터페이스가 왜 그렇게 중요한지는 경험해 보지 않고는 이해하기 힘든 디자인 요소중의 하나라는 생각이 든다. 개인적으로는 이 글이 경험이 많은 독자에게는 디자인 패턴의 중요성을 인식시킬 수 있는 것이 되고, 경험이 적은 독자에게는 Composite 패턴을 통해서 그 동안 가볍게 봐왔던 인터페이스에 대해서 깊이 있게 생각할 수 있는 기회가 되었으면 하는 바람을 가진다.

참고 문헌

[1] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Design Patterns, Elements of Resuable Object-Oriented Software, Addison-Wesley, 1995

[2] Mark Grand, Patterns in Java, volume 1, Wiley, 1998  

[3] John Vlissides, Pattern Hatching: Design Patterns Applied, Addison-Wesley, 1998