디자인 패턴(5) - 정리 정돈...
이승일
E-mail:gaialee@icu.ac.kr
한국정보통신대학원대학교
Homepage:http://www.icu.ac.kr/
지난 호까지는 객체의 생성 방법에 대해서만 이야기를 하였다. 지금 까지 이야기한 내용을 정리해 보자. 뉴스레터 2호에서는 객체 생성에 있어서의 타입 의존성을 줄일 수 있는 패턴에 대해서 이야기를 해 보았고, 3호에서는 동적인 객체 타입 변경을 가능하게 해 주는 패턴에 대해서 알아보았다. 그리고, 4호에서는 객체의 타입 결정 방법에 따른 객체의 생성 방법을 클래스 기반의 방법과 프로토타입 기반의 방법으로 구분 지어 보았다. 많은 도움이 되었는지 모르겠다. ^(^
이 번호에 이야기하려는 것은 생성되어 사용된 객체를 다 사용한 후에는 이를 어떻게 처리할 것인가에 대한 문제를 언급한 패턴에 대해서 이야기를 하려고 한다. 다시 말해서, 특정 객체에게 할당되었던 컴퓨터 시스템의 자원(resource)을 다른 객체들이 사용할 수 있도록 다시 시스템에 되돌리는 문제와 시스템의 오동작을 방지하기 위해서 어떤 순서로 되돌릴 것인가의 문제에 대한 한 해결책을 알아 보고자 한다. 사실 이 문제는 프로그래머들이 항상 주의를 기울여 왔던 주제일 뿐만 아니라, 컴퓨터 시스템에 관련된 대부분의 주제가 한정된 컴퓨터의 자원을 어떻게 하면 효율적으로 그리고 시스템의 정확성을 높이는 측면에서 사용될 수 있는가에 그 초점이 맞추어져 있는 것이 사실이다. 요즘에는 운영체제가 좋아져서(?) 이런 주제와 관련된 책자를 찾아보기 힘들지만, 왜 예전에 DOS를 많이 사용하던 시절에는 '메모리 관리'에 대한 주제로 쓰여진 책들을 심심치 않게 찾아 볼 수 있었던 것을 아는 독자는 기억할 것이다. 이런 이유로 요즘에는 평상시에 시스템을 디자인하고 구현하면서 객체 소멸(destruction)문제에 대해서 그리 심각하게 받아들인 독자가 많지 않을 거란 생각이 되기도 한다. 하지만, 시스템을 멋들어지게 디자인하려면 이에 대한 고려를 해 주어야 할 것이다.
1. 무엇이 문제인가?
GoF 책[1]에 나타나 있는 객체 생성에 관련된 패턴을 유심히 보면 한 가지 중요한 것을 이야기하지 않고 있다. Factory Method, Singleton 과 같은 객체 생성에 관련된 패턴들은 객체 생성에 대한 유용한 디자인을 제공해 주고 있지만, 생성된 객체가 사용된 후에 이 객체가 사용한 컴퓨터 시스템의 자원을 되돌릴 수 있는 효과적인 내용에 대한 디자인은 고려하고 있지 않다.
요즘과 같이 컴퓨팅 환경이 하드웨어적으로나 소프트웨어 적으로 아주 풍요로운 시기에는 객체 소멸에 대한 문제를 그리 심각하게 생각하지 않아도 시스템이 어느 정도 원활하게 돌아가는 것처럼 보일 것이다. 우선 하드웨어적으로 메모리의 가격이 높지 않아서, 웬만한 개인용 컴퓨터도 메모리가 충분히 크기 때문에, 메모리에 쓰레기가 좀 널려 있어도 시스템이 돌아가는 데는 그리 문제가 되지 않을 수 있을 것이다. 그리고, 최근의 운영체제들은 시스템 자원의 효율적인 활용을 위하여 여러 가지 안전장치를 포함하고 있기 때문에 운영체제 차원에서 조그마한 프로그램들이 실행되면서 남기는 쓰레기들을 회수하여 없애 버린다. 하지만, 이 문제는 일반적으로 두 가지 시스템에 있어서 아주 치명적이 될 수가 있다고 생각한다. 첫째는 서버용 프로그램과 같은 장시간 동작되어야 하는 규모가 큰 시스템의 경우이고, 두 번째는 아주 제한적인 메모리를 가지는 임베디드 시스템(embedded system)의 경우이다. 전자의 경우에는 일단 소프트웨어 시스템이 동작되기 시작하면, 하루 이틀이 아니라 몇 달 또는 몇 년 동안 운용되어야 하는 요구조건(requirement)를 만족시켜야 한다. 따라서, 이런 시스템이 장시간 아무 문제 없이 운용되기 위해서는 사용되고 난 후에 더 이상 필요 없어진 시스템의 자원은 그때그때 다른 프로세스 또는 객체가 사용할 수 있도록 반환되어야 할 것이다. 이런 필요조건을 충분히 만족시키지 못하면, 그 디자인된 시스템은 몇 일을 못 가서 전체 시스템을 다운 시키는 결과를 초래할 수도 있을 것이다. 후자의 경우는 조그마한 하드웨어 시스템에 조그마한 자체 운영체제가 운용되고 그 위에서 그 시스템을 구동하는 데 필요한 응용프로그램을 동작시키는 그러한 시스템이다. 따라서, 이런 종류의 시스템은 사용가능한 시스템 자원이 상대적으로 아주 적을 수밖에 없을 것이며, 이런 경우의 자원관리는 아주 중요한 문제가 될 것이다.
따라서, 디자인 패턴 분야에서 이런 자원 활용과 같은 문제를 효율적으로 해결할 수 있는 패턴에 대한 연구가 중요하다고 생각한다. 이런 관점에서 와싱턴 대학(Washington Univ.)의 Levine, Gill, Schmidt 가 제안한 Object Lifecycle Manager 패턴[2]은 그 의미가 있다고 개인적으로는 생각한다.
2. Object Lifecycle Manager 패턴
2.1 전체적인 구조
Levine, Gill, Schmidt 가 제안한 Object Lifecycle Manager 패턴은 그림 1에서 보이는 바와 같이 그 구조는 아주 간단하다(사실 지금까지 보아온 패턴 중에서 그 구조가 복잡한 것이 있었던가?). 일반적인 응용프로그램(application)의 개입을 빼면 세 개의 객체로 구성되어 있다. Singleton은 다른 객체 생성 패턴에 의해서 동적으로 생성되어 관리되어져야 할 일반적인 객체(dynamic object)를 나타내고( Singleton을 모르는 독자가 있는가? GoF 책을 보기 바란다. 아주 간단한 디자인 패턴이다. 여기서는 이 패턴을 이미 알고 있다는 가정하에 이야기를 할 것이다). Preallocated Object 는 응용프로그램에서 사용되기 전에 생성되어지고 응용프로그램이 소멸될 때 함께 소멸되는 정적인 객체(static object)를 의미한다. 그리고, Object Lifecycle Manager는 이 두 타입의 객체의 생성과 소멸을 응용프로그램과는 독립적으로 관리해 주는 객체이다. 이에 대한 구체적인 이야기는 좀 뒤로 미루고 그림 1의 전체적인 시스템 디자인을 보면서, 이 구조가 어떤 이점을 줄 수 있는지 한 번 생각해 보는 것이 더 중요하리라 생각한다.
그림 1. Object Lifecycle Manager 패턴
즉, 이 패턴 구조를 가만히 살펴보면 전체적으로 다음과 같음을 알 수 있다. 지난 호까지의 객체 생성
방법이 어떠했는가? 사용할 객체를 생성하는 부분을 응용프로그램의 로직(logic)에서 분리시켜서 디자인함으로써, 시스템의 객체 운용에
대한 유동성(flexibility)을 높이고, 결과적으로 시스템의 안정성(stability)도 높일 수 있음을 알 수 있었다. 이
패턴 구조는 이와 비슷하게 객체 소멸에 대한 부분까지도 응용프로그램에서 분리하여 관리 함으로써 전체적인 시스템의 안정성과 확장성
그리고 유동성을 더 높이고 있다. 결과적으로 이 패턴 구조를 전체적인 시스템 디자인에 도입하면 전체적인 응용프로그램의 구조는
객체생성, 객체소멸, 응용프로그램 로직이 모두 분리되는 구조를 가지게 되므로 앞에서 언급한 좋은 시스템 디자인이 될 것이다.
어떤가 구미가 당기지 않는가?
2.2 세부적인 내용
그림 1의 Object Lifecycle Manager에 대한 구체적인 이야기는 상당히 시스템 의존적이고 구현에 의존적인 이야기가 된다. 예를 들어서, 이 패턴이 C++로 구현할 경우와 자바(Java) 언어로 구현할 경우는 상당히 많은 차이를 보이게 될 것이다. C++ 언어를 사용할 경우에는 프로그래머가 객체가 사용하고 있었던 시스템 자원에 대해서 명시적으로 자원 소멸에 대한 구현을 해 주어야 하지만, 자바의 경우에는 언어 차원에서 Garbage collection이라는 자원 소멸에 대한 부분을 책임지는 메커니즘을 지원하고 있다. 따라서, 자바를 사용하여 위의 패턴을 고려할 경우는 그 양상이 많이 달라지게 될 것이다. 경우에 따라서는 이 패턴과 같이 명시적으로 시스템 자원 활용 측면에서 시스템 디자이너가 신경을 쓰지 않아도 되는 경우가 있을 것이다.
Object Lifacycle Manager 패턴의 저자들은 이 패턴에 구체적인 예와 그에 대한 해결책, 그리고 전반적인 이야기를 C++언어를 이용하여 시스템을 구축하는 환경에 초점을 맞추어서 설명을 해 놓았다. 하지만, 여기서는 글의 일관성을 위해서 필자들이 지적한 자바언어를 사용하여 시스템을 디자인할 경우에 이 패턴이 유용하게 사용될 수 있는 경우에 대해서만 언급하기로 하겠다. C++언어를 이용한 시스템 개발에 관심이 많은 독자는 이 패턴을 설명한 논문을 구해서 자세히 읽어보면 많은 도움이 될 것으로 생각한다. (이 논문은 99년 PLoP 컨퍼런스 사이트에 가면 무료로 얻을 수 있다).
3. Java 에서는…
혹자는 자바언어를 사용하여 프로그램을 구현하면, 더 이상 사용되지 않는 객체에 대한 처리를 생각하지 않아도 된다고 굳게(?) 믿고 있을지도 모르겠다. 좀더 구체적으로 이야기해서, 자바는 언어 차원에서 더 이상 참조(reference)되지 않는 객체를 필요 없는 객체로 판단하여 그 객체가 사용하던 시스템 자원을 다른 객체가 사용할 수 있도록 되돌리는 Garbage Collection 이라 불리는 메커니즘을 지원하고 있기 때문에 시스템 디자이너가 구지 그런 것까지 신경 쓰지 않아도 될 것 같은 생각이 들 것이다. 그러나, 경우에 따라서는 디자이너가 명시적으로 이런 것까지 신경 써줘야 할 경우가 있다. 현재 필자의 경험으로는 Object Lifecycle Manager 패턴의 저자들이 지적하고 Grand[3]도 지적한 Singleton 패턴을 사용하여 객체를 생성할 경우와 분산 객체를 이용하여 분산 시스템을 디자인할 경우이다. 후자의 경우는 필자가 연구실에서 자바를 사용하여 분산워크플로우 시스템(Distributed workflow system)을 디자인하고 구현하면서 한참을 고민하게 만들었던 기억이 있다. 후자의 경우는 이 번호에서 이야기하려고 하는 패턴과는 구조적으로 별 관계가 없으므로 여기서는 전자의 경우만을 언급할 것이다.
3.1 문제점 및 한 가지 해결 방안
(독자들이 잘 알고 있듯이?) Singleton 패턴은 한 클래스의 인스턴스가 하나만 생기도록 하는 것을 가능하게 해 주는 패턴이며, 해당 클래스 타입의 객체가 하나만 필요로 하는 경우에 아주 유용하게 사용되는 패턴이다. 이 패턴은 하나의 클래스로 구성되어 있기 때문에 이 패턴을 이용한 클래스를 Singleton 클래스라 부른다.
Singleton 클래스를 어떤 객체에서 직접적으로 참조하여 사용할 경우에는 문제가 없다. 그러나, 이 Singleton 클래스가 직접적으로 사용되지 않고, 동적으로 메모리에 적재(load)되는 객체를 통해서 간접적으로 사용될 경우에는 좀 심각한 문제를 일으킨다. 이유는 간단하다. 객체 A가 객체 B를 통해서 Singleton 클래스의 객체를 사용한다고 가정해 보자. 또한 객체 A는 동적으로 객체 B를 적재해서 사용하고 있다고 가정하자. 이 경우에 일단 객체 A가 객체 B를 동적으로 메모리에 적재하면 객체 B를 통해서 Singleton 클래스는 하나의 객체를 생성하고 이에 대한 참조자를 객체 B의 참조자에 넘겨준다. 프로그램이 수행되다가 객체 A가 객체 B에 대한 참조를 더 이상 참조하지 않으면 자바의 garbage collection 메커니즘에 의해서 객체 B와 Singleton 클래스의 인스턴스는 필요 없는 객체로 되어 버린다. 이런 상태에서, 다시 객체 A가 객체 B를 동적으로 적재하면, Singleton 클래스는 다시 새로운 인스턴스를 생성하여 이에 대한 참조자를 객체 B에 넘겨준다. 따라서, 새롭게 생성된 Singleton 클래스의 인스턴스는 다시 초기화가 되어 기존의 값을 유지하지 못하게 된다. 이 Singleton 객체가 전체 프로그램의 성능에 대한 통계 자료를 지속적으로 유지 기록하는 용도로 사용되는 것이었다면, 위와 같은 경우에 전혀 엉뚱한 결과를 유발하게 될 것이다.
위와 같은 경우의 문제를 해결하는 한 가지 방법은 Object Lifecycle Manager 패턴을 사용하는 것이다. 이 패턴에 대한 구체적인 구현 방법은 Grand의 책에도 언급되어 있는 아주 일반적인 방법을 사용한다. 다음 소스는 Grand 책에 나와있는 소스를 필자가 그림 1의 패턴에 따라 아주 조금 변형을 가해 보았다.
public class ObjectLifecycleManager
implements Runnable
{
…
private
static ObjectLifecycleManager lifeLine
=
new
ObjectLifecycleManager();
…
private
static HashSet protectedSet = new
HashSet();
…
private
ObjectLifecycleManager()
{
(new
Thread(this)).start();
}
…
public
void run()
{
try{
wait();
}catch(InterruptedException
e)
{…}
}
…
public
static void at_exit(Object o)
{
protectedSet.add(o);
}
…
public
static void destroy(Object o)
{
protectedSet.remove(o);
}
…
}
Object Lifecycle Manager의 저자들은 이 객체를 또다른 하나의 Singleton으로 구현을 하였지만, 위에 소개한 구현 예는 자바의 쓰레드(Thread)를 이용하여 응용프로그램과는 독립적으로 운용되는 ObjectLifecycleManager 객체를 통해서 생성된 Singleton 객체의 관리를 하게 한 것이다. 이렇게 함으로써 위에서 이야기되었던 자바 언어의 경우에 있어서의 문제점을 해결할 수 있을 것이다.
이 패턴의 저자들이 논문[2]에서 밝히고 있는 의도(intent)로 Object Lifecycle Manager 패턴에 대한 이야기를 줄이겠다.
The Object Lifecycle Manager pattern can be used to govern the entire lifecycle of objects, from creating them prior to their first use to ensuring they are destroyed properly at program termination. In addition, this pattern can be used to replace static object creation (and destruction) with dynamic object preallocation (and deallocation) that occurs automatically during application initialization (and termination).
Object Lifecycle Manager 패턴은 객체의 전체 lifecycle을 관리하는데 사용될 수 있다. 여기서 전체 lifecycle이라는 것은 처음으로 사용되기 전에 생성하는 것에서부터 해당 프로그램이 종료되었을 경우에 정확하게 소멸되는 것을 보장하는 것까지를 말한다. 이 패턴은 또한 해당 응용프로그램이 초기화될 때, 자동으로 동적 생성(소멸)될 수 있게 함으로써 정적인 객체 생성(소멸)에서 오는 문제점을 해결할 수 있다.
4. 관련 패턴
여기서 소개한 Object Lifecycle Manager 패턴과 관련이 있다고 저자들이 언급한 패턴은 Manger 패턴이다. 이 패턴은 96년 PLoP에 발표된 것으로써, 필자도 관련 논문을 구할 수 없어서, 아직 읽어보지 못했다. 단지, 패턴의 저자들이 비교해 놓은 내용을 보고 그 내용을 미루어 짐작할 뿐이다. 하지만, 이 패턴의 저자들이 주장하는 것은 Object Lifecycle Manager 패턴이 기존의 객체 생성 패턴을 보완하는 패턴(complementary pattern)으로써 중요성을 가진다는 점이다.
5. 맺음말
이 번호에는 별로 한 이야기가 없는 듯 하다. 그러나, 이 글을 읽으면서 독자들이 한 가지 주의를 기울였으면 하는 부분은 전체적인 시스템의 디자인 측면이다. 하나의 시스템을 디자인 할 때, 어떻게 하면 좀더 효율적이고 튼튼한 시스템을 디자인 할 수 있을 것인가 하는 것이다. 구현은 그 다음의 부차적인 문제이다. 우리가 디자인 패턴을 공부해야 하는 이유는 바로 여기에 있다고 개인적으로는 생각하고 있다. 이런 관점이 아니고 구현의 관점에서 디자인 패턴을 바라보고 그 내용을 익히려 든다면, 그 것은 거의 도움이 되지 않는 도구의 사용법을 익히고 있는 것이나 다름없을 것이다. 독자들은 어떤 생각을 가지고 디자인 패턴을 접해 왔는지 궁금하다. 이 번호로 객체 생성과 소멸에 대한 이야기를 마무리 짖고, 다음 호부터는 객체지향 시스템의 다른 관점에서 유용성이 큰 디자인 패턴들을 찾아서 이야기를 해 보려 한다.
참고 문헌
[1] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Design Patterns, Elements of Resuable Object-Oriented Software, Addison-Wesley, 1995
[2] David L. Levine, Christopher D. Gill, Douglas C. Schmidt, Object
Lifecycle Manager A complementary Pattern for Controlling Object Creation
and Destruction, PLoP 1999 conference
[3] Mark Grand, Patterns in Java, volume 1, Wiley, 1998
(글 후기 )
지난 호에 필자가 PLoP2000에 제출했던 패턴을 이 번호에 공개하리라 이야기를 했었습니다. 그러나. 이 번호에 그렇게 하질 못하였습니다. 패턴 내용이 영문으로 작성되어 있기 때문에 한글로 번역하는 작업이 필요한데… 너무 바뻐서, 할 일이 너무 많아서.. 그럴 시간이 없었습니다. 이거 너무 죄송합니다. 이 번호가 보름 가까이 늦어진 것도 필자들이 도대체 감당할 수 없을 정도로 과로에 시달려서, 개인적인 일을 거의 보기 힘들 정도였기 때문입니다. 공부하랴, 프로젝트하랴, 잡일하랴… 이해해 주시고요.. 제 논문이 한 글로 정리되는 대로 이 곳에 선 보이겠습니다. 그런데, 사실 일반적인 내용의 패턴이 아니라서, 제 패턴이 도움이 되지는 않을 것 같습니다. 몇몇 분들을 제외하고는요.. 그럼 다음 호에 뵙지요.. ^(^
oonewsletter - 2000/6/14