Scent of Life

싱글턴 패턴(Singleton Pattern) - for Beginner

이 문서는 GoF(Gang of Four) Design Patterns 에 정의된 패턴 목록 중 싱글턴 패턴(Singleton Pattern)을 다시 정리하면서 내용을 요약한 것이다. 개인적으로 자바와 닷넷 양진영에 모두 경험이 있다보니 동일 패턴에 대해서 상호 비교해보는 것이 어떨까 하는 생각이 들었다. 그래서 간략하지만 Java와 C# 양쪽에 걸쳐 내용을 작성하였으며, 소스코드 템플릿 또한 *.java, *.cs로 나누어 예를 제시하였다. 어쩌면 이 코드들 때문에 내용이 조금 더 복잡해 보일지도 모르겠다.

싱글턴 패턴의 개요

GoF의 23가지 디자인 패턴 중 개발자에게 가장 익숙한 패턴의 하나가 바로 '싱글턴 패턴(Singleton Pattern)'일 것이다. 싱글턴 패턴은 해당 클래스의 인스턴스(instance)가 하나만 만들어지고, 어디서든지 그 유일한 인스턴스에 접근할 수 있도록 하기 위한 패턴의로 정의된다.

GoF에 기술된 내용 중 싱글턴 패턴을 활용할 수 있는 상황은 다음과 같다.

• 클래스의 인스턴스가 오직 하나여야 함을 보장하고, 잘 정의된 접근 방식에 의해 모든 클라이언트가 접근할 수 있도록 해야 할 때.
• 유일하게 존재하는 인스턴스가 상속에 의해 확장되어야 할 때, 클라인트는 코드의 수정 없이 확장된 서브클래스의 인스턴스를 사용할 수 있어야 할 때.

이를테면 쓰레드 풀, 캐시, 대화상자, 사용자 설정이라든가 레지스트리 설정을 처리하는 객체, 로그 기록용 객체, 프린터나 그래픽 카드 같은 디바이스를 위한 디바이스 드라이버 같은 것들이 좋은 예가 될 것이다.

싱글턴의 기본적인 구조(Structure)는 그림과 같다.

그리고 싱글턴 패턴을 구현하는 고전적인 자바 코드의 기본 템플릿은 아래와 같다.

[자바 코드 1]

// NOTE: This is not thread safe! public class Singleton {     private static Singleton uniqueInstance;         // other useful instance variables here         private Singleton() {}         public static Singleton getInstance() {         if (uniqueInstance == null) {             uniqueInstance = new Singleton();         }         return uniqueInstance;     }         // other useful methods here }

아래는 동일한 형태의 C# 버전으로 된 코드이다.

[C# 코드 1]

// NOTE: This is not thread safe! public sealed class Singleton {     static Singleton instance=null;     Singleton()     {     }     public static Singleton Instance     {         get         {             if (instance==null)             {                 instance = new Singleton();             }             return instance;         }     } }

이 코드에서 Singleton 클래스는 private 변수와 생성자를 갖고 있으며 클라이언트에서 인스턴스를 요청할 때까지 Singleton 객체의 생성을 지연(lazy instantiation)하고 있다.

그런데 위의 코드 형태는 주석에도 달려있듯이 멀티(다중)쓰레딩 환경에서의 잠재적 문제를 안고 있기 때문에 실전에 절대 사용하면 안된다. 두개 이상의 쓰레드가 인스턴스를 획득하기 위해 getInstance() 메서드(C#의 경우 Instance 속성(Property))에 진입하여 경합을 벌이는 과정에서 서로 다른 두개의 Singleton 인스턴스가 만들어지는 좋지 않은 상황이 발생할 여지가 있다.

멀티쓰레드 환경에서의 싱글턴(Multithreaded Singleton)

위에서 제기한 문제를 해결하기 위해서는 다음 세가지의 해법을 사용할 수 있다.

1. 인스턴스를 필요할 때 생성하지 않고, 처음부터 인스턴스를 만들어 버린다. 다시 말해서 lazy instantiation을 포기하고 static 멤버필드를 사용항여 언과 동시에 초기화하는 것이다.  단, 인스턴스를 미리 만들어 버리게 되면, 특히 해당 인스턴스가 자원을 많이 차지하는 컴포넌트일 경우에는 시스템 리소스가 쓸데없이 낭비될 가능성이 있다.
2. getInstance() 메서드(C#의 경우 Instance 속성)를 동기화시킨다. 단, 동기화시키고자할 때는 getInstance()의 속도가 그렇게 중요하지 않다고 판단될 경우이며 동기화로 인한 오버헤드를 감수해야 한다. - 메서드를 동기화 시키면 일반적으로 성능이 100배 정도는 저하된다고 한다.
3. DCL(Double-checked Locking) 기법을 사용한다. 단, 자바의 경우 DCL은 자바 5 버전 이상의 JVM 환경에서 인스턴스 변수에 volatile 키워드를 사용해야만 한다. voatile 키워드는 멀티쓰레드 환경에서도 uniqueInstance 변수가 원자성을 유지하도록 하여 올바른 싱글턴 인스턴스의 초기화가 진행되도록 한다(The volatile keyword in Java를 참고하라). 하지만 자바 1.4 및 그 이전에 나온 JVM에서는 메모리 모델의 문제로 제대로 동작하지 않는다는 것에 주의해야 한다(자세한 내용은 The "Double-Checked Locking is Broken" Declaration 참고하라).

설명보다는 코드를 보고 이해하는 것이 빠를 것 같다. 각 해법을 적용하여 멀티쓰레드 환경에서 제대로 동작(thread-safe)하는 싱글턴 구현의 예제 코드들이 아래에 있다.

1. 처음부터 인스턴스를 생성하는 예제 코드

[자바 코드 2]

public class Singleton {     private static Singleton uniqueInstance = new Singleton();         private Singleton() {}         public static Singleton getInstance() {        return uniqueInstance;     } }

[C# 코드 2]

public sealed class Singleton {     static readonly Singleton uniqueInstance = new Singleton();         // Explicit static constructor to tell C# compiler     // not to mark type as beforefieldinit     static Singleton()     {     }         Singleton()     {     }         public static Singleton Instance     {         get         {             return uniqueInstance;         }     } }

2. 동기화 예제 코드

[자바 코드 3]

public class Singleton {     private static Singleton uniqueInstance;         // other useful instance variables here          private Singleton() {}         public static synchronized Singleton getInstance() {         if (uniqueInstance == null) {             uniqueInstance = new Singleton();         }         return uniqueInstance;     }         // other useful methods here }

[C# 코드 3]

public sealed class Singleton {     static Singleton uniqueInstance = null;     static readonly object padlock = new object();     Singleton()     {     }     public static Singleton Instance     {         get         {             lock (padlock)             {                 if (uniqueInstance == null)                 {                     uniqueInstance = new Singleton();                 }                 return uniqueInstance;             }         }     } }

3. DCL(Double-checked Locking) 예제 코드

[자바 코드 4]

// // Danger!  This implementation of Singleton not // guaranteed to work prior to Java 5 // public class Singleton {     private volatile static Singleton uniqueInstance;         private Singleton() {}         public static Singleton getInstance() {         if (uniqueInstance == null) {             synchronized (Singleton.class) {                 if (uniqueInstance == null) {                     uniqueInstance = new Singleton();                 }             }         }         return uniqueInstance;     } }

[C# 코드 4]

public sealed class Singleton {     static Singleton uniqueInstance = null;     static readonly object padlock = new object();         Singleton()     {     }         public static Singleton Instance     {         get         {             if (uniqueInstance == null)             {                 lock (padlock)                 {                     if (uniqueInstance == null)                     {                         uniqueInstance = new Singleton();                     }                 }             }             return uniqueInstance;         }     } }

아래 C# 코드는 위 코드와 동일하게 DCL을 사용하지만 volatile을 사용하는 다른 버전의 예제이다.

[C# 코드 5]

public class Singleton {     private static volatile Singleton uniqueInstance = null;         protected Singleton()     {     }         public static Singleton Instance()     {         if (uniqueInstance == null)         {             lock (typeof(Singleton))             {                 if (uniqueInstance == null)                 {                     uniqueInstance = new Singleton();                 }             }         }         return uniqueInstance;          } }

싱글턴 레지스트리(Singleton Registry)

서두에서 "유일하게 존재하는 인스턴스가 상속에 의해 확장되어야 할 때, 클라인트는 코드의 수정 없이 확장된 서브클래스의 인스턴스를 사용할 수 있어야 할 때" 싱글턴을 활용한다고 하였다. 이때에는 서브클래스를 만드는 것이 중요한 게 아니라, 이 새로운 서브클래스의 유일한 인스턴스를 만들어 클라이언트가 이를 사용할 수 있도록 하는 것이 관건이다.

싱글턴의 서브클래스를 만들 때 가장 유연한 방법은 싱글턴에 대한 레지스트리를 사용하는 것이다. 아래 자바 예제 코드는 레지스트리를 갖고 있는 싱글턴으로 특정 클래스 객체의 인스턴스를 생성하기 위해서 리플렉션을 사용하고 있다. 'classname'은 Singleton의 서브클래스 이름이다. 이렇게 하면 서브클래스의 선택에 있어서 런타임에 싱글톤을 결정하는 유연성을 가질 수 있다(자세한 내용은 Simply Singleton을 참고하라).

[자바 코드 5]

import java.util.HashMap; import org.apache.log4j.Logger; public class Singleton {     private static HashMap map = new HashMap();     private static Logger logger = Logger.getRootLogger();     protected Singleton() {         // Exists only to thwart instantiation     }     public static synchronized Singleton getInstance(String classname) {         Singleton singleton = (Singleton) map.get(classname);         if (singleton != null) {             logger.info("got singleton from map: " + singleton);             return singleton;         }         try {             singleton = (Singleton) Class.forName(classname).newInstance();         }         catch(ClassNotFoundException cnf) {             logger.fatal("Couldn't find class " + classname);            }         catch(InstantiationException ie) {             logger.fatal("Couldn't instantiate an object of type " + classname);            }         catch(IllegalAccessException ia) {             logger.fatal("Couldn't access class " + classname);            }         map.put(classname, singleton);         logger.info("created singleton: " + singleton);         return singleton;     } }

결론

이상으로 멀티쓰레딩 환경에서의 싱글턴 패턴 구현 코드를 들여다 보았다. 그렇다면 이 세가지 중 어떤 코드 템플릿을 사용하는 것이 좋을까?

자바에서는 Double-checked locking과 Singleton 패턴 등 (조금 오래되긴 했지만) DCL과 관련한 문서들을 참고해보면 멀티쓰레드 환경에서 제대로 동작하는 싱글턴을 만들기 위한 최상의 솔루션은 동기화를 수락하거나 static 멤버필드를 사용하는 것을 권장하고 있다. 닷넷의 경우 The Correct Double Checked-Lock Pattern Implementation를 보면 [C# 코드 2]와 같은 형태의 코드를 사용할 것을 권장하고 있다.

싱글턴 구현에 있어서 반드시 DCL을 사용해야 하는 특별한 경우가 아니라면 대부분의 상황에서는 static 변수를 사용하거나 동기화 블럭을 사용하는 것으로도 충분할 것 같다. 성능의 저하는 다소 존재하겠지만 다양한 java  및 .net 버전과 메모리 모델에 종속적이지 않은 싱글턴을 구현하는 잇점도 있다고 생각한다. DCL을 적용해야한다면 특히 자바의 경우 volatile 키워드와 함께 반드시 자바 5 버전 이상을 사용해야 한다는 것을 잊지 말아야 한다.

마지막으로 참고가 될만한 두가지 사항을 덧붙이며 싱글턴 패턴에 대한 요약을 마무리한다.

싱글턴 패턴 사용 시 주의할 점(Java 기준)

• 중복되는 얘기지만 DCL을 사용하려면 자바 5(1.5) 이후 버전을 사용해야 한다.
• 클래스 로더가 여러개 있으면 싱글턴이 제대로 작동하지 않고, 여러 개의 인스턴스가 생길 수 있다. 이 경우 클래스 로더를 직접 지정해서 사용해야한다.
• 개인적으로 최근 프로젝트 환경을 보면 슬슬 자바 5 버전으로 많이 갈아타고 있는 듯 하다. 정말 오래된 시스템을 유지 보수하는 경우가 아니라면 자바 1.2 이전 버전을 사용할 일은 없겠지만, 혹시라도 자바 1.2 이전 버전의 환경에서 작업한다면 JVM의 가비지 컬렉터 관련 버그 때문에 싱글턴 레지스트리를 사용해야할 수도 있다.

아래 코드는 클래스 로더를 직접 지정하는 예제이다. 이 코드는 Class.forName() 메서드를 대체할 수 있다(자세한 내용은 Simply Singleton을 참고하라).

[자바 코드 6]

private static Class getClass(String classname) throws ClassNotFoundException {     ClassLoader classLoader = Thread.currentThread().getContextClassLoader();     if (classLoader == null) {         classLoader = Singleton.class.getClassLoader();     }     return (classLoader.loadClass(classname)); }

정적 클래스 변수(메서드) vs. 싱글턴 패턴

굳이 싱글턴 패턴을 사용할 필요없이 전역 클래스 변수(static 멤버필드)를 사용하면 되지 않을까 하는 의문이 들 수도 있다. lazy instantiation을 구현하는 싱글턴 패턴에 비해서 전역 변수를 사용하는 경우 다음과 같은 단점들이 있을 수 있다.

• 싱글턴 패턴은 static 인스턴스를 미리 생성해놓는 경우를 제외하고는 객체가 필요한 상황이 되었을 때에 비로소 인스턴스를 생성한다. 반면 전역 변수를 사용하면 대부분의 경우는 어플리케이션을 시작할 때 미리 객체가 생성한다. 그런데 그 객체가 자원을 많이 차지하고, 실제로 어플리케이션을 종료할 때까지 한번도 쓰지 않게된다면 괜한 자원만 낭비하는 꼴이 되고만다(이러한 상황은 시스템 플랫폼에 따라 달라질 수도 있다. 어떤 JVM은 객체를 나중에 필요할 때 생성하기도 한다고 한다).
• 전역 변수를 사용하다 보면 간단한 객체에 대한 전역 레퍼런스를 자꾸 만들게 되면서 네임스페이스를 지저분하게 만드는 경향이 생긴다. 물론 싱글턴도 남용될 수 있지만, 네임스페이스가 지저분해지게 되는 것을 부추길 정도는 아니다.

참고 자료

아래는 이 포스트를 작성하기 위해 참고한 도서와 관련 사이트의 목록이다. 영어가 짧고 스크롤의 압박이 심하다보니 사이트의 글들을 죄다 꼼꼼하게 읽어보지는 못했다. ^^; 하지만 정독해보면 분명 도움이 될 내용들이라고 장담한다. ^^

Books

• GOF의 디자인 패턴, 피어슨에듀케이션 코리아
• Head First Design Patterns, 한빛미디어
• 예제로 배우는 C# 디자인 패턴, 정보문화사 (비추. 자바와 닷넷 관련한 더 좋은 패턴 책들이 많이 있다.)
• J2EE 패턴 (GoF & J2EE), SUN SL-500
• The Design Patterns Java Companion

Terms

• The volatile keyword in Java
• Double-checked locking

Articles

• Double-checked locking과 Singleton 패턴
• 디자인 패턴으로 알아본 Double Checked Lock(DCL)
• The "Double-Checked Locking is Broken" Declaration 
• The Correct Double Checked-Lock Pattern Implementation
• Simply Singleton 
• Exploring the Singleton Design Pattern
• Implementing Singleton in C# 
• Performance of techniques for correctly implementing lazy initialization 

P.S. 내용 중 잘못된 부분이 있다면 지적 바랍니다. ^^

일전에 프로젝트 후기로 간략하게 기술한 내용과 관련이 있는 기사가 이노베이터(한국마이크로소프트의 비즈니스 매거진)에 게재되었다. 이노베이터 "2007 Autumn / Vol.55"호의 Business Zone for Innovation, Case Study 5 섹션의 글이다.

...?! ...!!

기사의 성격이야 보면 알겠지만... 아무튼, 기념(?!)으로 스크랩하였다. :P

원본 : Business Zone for Innovation > Case Study 5 교보리얼코
(원문의 폭이 블로그 Contents 영역 보다 넓어 약간 축소하고 이미지도 500px로 조정하였음을 밝힌다.)


2008년 07월 07일 추가 사항

성공 사례: http://www.microsoft.com/korea/customerevidence/evidence_view.aspx?idx=102
관련 문서:

몇 년 전에 Classic ASP와 ASP.NET 비교 자료를 작성했었다. 공식적인 문서는 아니었으며, 개인적으로 정리한 글인데, 워드에 작성했던 내용을 그대로 복사하였다. 단, 원래 시스템의 이름은 "X 솔루션"으로 변경하였다.

１    개요

Microsoft의 Windows 플랫폼 상에서의 웹 응용 프로그램은 대세는 ASP.NET입니다. 기존 Classic ASP(Microsoft Active Server Pages)는 .Net 환경의 ASP.NET으로 Migration되고, 신규 개발 건은 대부분 ASP.NET으로 개발되고 있는 듯 합니다. 이런 상황에서 두 언어에 대한 차이점을 언급하는 것은 때늦은 감이 없지 않지만 현재 ASP 및 ASP.NET 웹 응용 프로그램이 공존하고 있는 “X 솔루션”을 유지 보수하고 신규 시스템들을 추가하는 시점에서 다시 한번 각 언어별 개발 효율과 서비스 품질에 대해서 짚고 넘어가는 것도 의미 있는 일이 될 것 같습니다.

 

기존 ASP는 웹 응용 프로그램에 있어서 오랫동안 수위를 고수하면서 광범위하게 적용되어 있고 개발자들에게 매우 친숙하며, 또한 scripting language로써 응용 프로그램을 빠르게 개발할 수 있는 장점에도 불구하고 여러 측면에서 볼 때 ASP.NET에 비해 한 수 뒤질 수 밖에 없습니다.

 

반면에 ASP.NET을 단순히 ASP의 업그레이드 버전으로 볼 수 없는 것이, ASP에 비해 ASP.NET은 보다 진보된 기술로 완전히 새로 작성되었으며 현격한 생산성의 향상을 가져왔습니다. ASP와 친숙한 형태의 요소들을 그대로 포함하면서 Web Forms, Web Services, 또는 Server Controls 들은 웹 응용 프로그램 개발에 강력하고 유연한 기능들을 제공하고 있습니다.

 

Classic ASP와 ASP.NET의 주요한 차이점들은 어떠한 것들이 있는지 간략히 살펴보고 왜 웹 응용 프로그램 개발에 있어서 ASP.NET에 무게가 실리는지에 대한 이유를 알아보겠습니다.

 

２    주요 차이점 간략 비교

Microsoft Active Server Pages (ASP)는 서버측(server-side) 스크립팅 기술입니다. Classic ASP로 만들어진 웹 응용 프로그램들은 주로 VB Script, COM(COM+), ADO 등의 기술 요소들을 사용하여 만들어집니다.

반면에 ASP.NET은 .Net Framework 환경에서 C#, VB.Net, ADO.Net 등을 사용해서 만들어집니다. ASP.NET은 개발자들이 Classic ASP에서 느꼈던 문제들에 대한 직접적인 응답으로 개발되었으며 또한 이미 광범위하게 적용되어 있는 Classic ASP를 위해 Microsoft는 ASP 스크립트가 .NET Framework가 탑재된 서버상에서 어떠한 수정도 없이 실행될 수 있도록 하였습니다. 따라서 .NET Framework을 설치해도 ASP 엔진, ASP.DLL 등은 수정되지 않으며, IIS는 동일 머쉰 상에서 ASP와 ASP.NET을 동시에 수용할 수 있습니다.

 

아래는 Classic ASP와 ASP.NET 간의 단순 비교표입니다 (한 라인이 반드시 동일한 주제를 나타내지는 않습니다).

 

Classic ASP	ASP.NET
VB Script - 덜 강력하지만 새로 배워야 하는 부담이 적다.	C# 또는 VB.Net - 보다 강력하지만 학습 과정이 필요하다.
대부분의 script language처럼 Top-Down 방식의 간단한 절차적 프로그래밍 모델	Control 및 Event 기반 프로그래밍 모델
ADO, File System 개체 사용을 위해 COM 개체에 접근	강력한 Data Access Object 모델인 ADO.Net을 통해 control에 데이터를 바인딩할 수 있다.
Presentation과 Logic이 혼재	Presentation과 Logic이 분리 – Code behinde page
코드의 가독성이 떨어진다.	코드의 가독성이 좋다.
File include 모델 - 코드의 재사용성이 떨어진다.	OOP - 코드의 재사용성이 뛰어나다.
DLL Locking, DLL registration	DLL Locking이 없다. 운영 중에 DLL을 교체 가능하다. DLL registration이 필요없다.
Debugging이 힘들다.	Debugging이 쉽다.
성능 저하 - ASP 페이지는 실행 시 매번 컴파일 된다	성능 향상 – ASP.NET 페이지는 컴파일 되어 있다.
Session – 웹 서버를 교차하여 공유할 수 없다.	Session – 머쉰을 교차하여 공유 가능하다.
Caching – 지원하지 않는다.	Caching – 데이터, 페이지 출력 등을 캐쉬한다.
컴파일이 필요없다. 단순 저장.	강력한 보안 및 인증 메커니즘을 지원
다양한 scripting language를 지원	Validation – 추가 코드 없이 client측 server측 form field 유효성 검사가 가능하다.
페이지당 여러 개의 Form이 존재	Web.config – 이식이 쉽고 확장 가능한 XML 기반의 사이트 환경 구성을 제공한다.
	페이지당 오직 하나의 Server Form이 존재

 

가)   Classic ASP가 갖는 문제

 

①       인터프리트 코드(interpreted code), 느슨한 형 정의(Loosely-Typed) 코드

ASP는 주로 VBScript 또는 JScript와 같은 scripting code로 작성됩니다. ASP의 스크립트 엔진은 페이지가 불려질때마다 라인 단위로 코드를 해석(interpret)하는 방식으로 작동합니다. 또한 모든 변수들은 variant의 느슨한(loosely) 형식으로 코드가 실행되는 시점에만 특정 형식에 바인딩됩니다. 따라서 이러한 요소들은 성능에 있어서 부정적인 요인으로 작용하게 되며, 또한 형식의 지연 바인딩(late binding)은 코드 작성시 에러를 감지하기 힘들게 만들어 개발 효율도 떨어지게 됩니다.

②       비즈니스 로직(스크립팅 코드)과 레이아웃(HTML)의 혼재

ASP file은 코드(스크립트)와 HTML 코드가 혼재되어 있어 코드가 길어지고 가독성이 떨어집니다. 산재된 ASP 코드와 HTML은 business logic과 contents가 반드시 분리되어져야 하는 보다 큰 웹 응용프로그램에 있어서 문제가 될 수 있으며, 이러한 스파게티 코드는 개발팀원들의 코드 일관성을 저해하고 향후 전체 코드의 유지 보수가 어렵게 되는 잠재적인 문제를 안고 있습니다.

③       제한적인 개발 및 디버깅 도구

ASP 프로그래머의 생산성 증대를 위하여 그래픽 개발 환경을 제공하는 몇몇 툴(Microsoft Visual InterDev, Macromedia Visual UltraDev 등)들이 있지만 여전히 제약적입니다. 많은 ASP 개발자들은 아직까지 텍스트 에디터(제 경우 Ultra Edit를 사용)에 의존하여 힘들게 작업하고 있습니다. 또한 소프트웨어 개발 프로세스에 있어서 디버깅은 피할 수 없는 부분이지만 ASP의 디버깅 툴은 제약적입니다. 대부분의 개발자들이 디버깅을 위해 코드 사이에 Response.Write 와 같은 trace를 위한 문장을 삽입하고 있습니다..

④       진정한 상태 관리의 부재

ASP의 세션은 클라이언트 브라우저가 쿠키를 지원할 때만 관리됩니다. 세션 정보는 ASP 세션 객체에만 의존하며, 사용자 확인 등을 위해서 추가적인 코드를 구현해야만 합니다. 따라서 웹 서버 사이에서 세션을 공유하기가 힘들어집니다.

⑤       서버 중지 상태에서의 프로그램 갱신

웹 응용 프로그램이 컴포넌트(COM, COM+ 객체)로 구성되어 있다면 갱신된 응용 프로그램 파일을 복사(배포)할 때 등록된 컴포넌트가 사용 중이거나 잠김 상태일 수 있으므로 서버를 중지시켜야만 합니다. 이것은 신속한 프로그램 배포에 있어서 문제가 될 수 있습니다.

⑥       분명하지 않은 환경 설정

ASP 웹 응용 프로그램을 위한 환경 설정 정보는 IIS 메타베이스(metabase)에 저장됩니다.     metabase는 IIS의 독립적 포맷으로 저장되기 때문에 서버 머쉰 상에서 Internet Service Manager와 같은 유틸리티로만 수정이 가능합니다. 환경 세팅에 대한 프로그램적인 조정의 제한으로 ASP 응용 프로그램을 다른 서버로 이전하는 것은 매우 번거롭고 까다로운 작업이 될 수 있습니다.

 

나)   ASP.NET의 강점

 

①       HTML과 코드의 분리

ASP.NET을 사용함으로써 business logic과 layout을 완전하게 분리(Code behind)하는 것이 가능해졌습니다. 이로 인해 프로그래머들과 디자이너가 보다 효과적으로 협력하여 작업하는 것이 가능해졌습니다.

②       컴파일되는 언어(compiled language)를 지원

개발자들은 C#이나 VB.NET 등을 사용하므로 OOP(object-oriented programming) 및 강력한 형 정의(strong type)가 가능해졌습니다. 또한 이 같은 컴파일되는 언어를 사용한다는 것은 ASP.NET 페이지의 코드를 번역함으로써 발생하는 성능상의 손실을 배제할 수 있습니다. ASP.NET 페이지는 첫번째 요청이 있을 때 바이트 코드(byte-code)로 미리 컴파일(precompile)되고 JIT(Just In Time) 컴파일 됩니다. 그 이후의 요청에 대해서는 (소스의 변경이 있기 전까지는) 캐쉬된 형태의 완전 컴파일된 코드로 바로 유도됩니다..

③       .NET Framework에서 제공되는 서비스의 사용

.NET Framework는 응용 프로그램에서 사용할 수 있는 클래스 라이브러리를 제공합니다. 여기에는 입/출력, 시스템 서비스, 데이터 접근, 이벤트, 디버깅 등의 유용한 핵심 클래스가 있습니다.

④       그래픽 개발 환경

Visual Studio .NET은 웹 개발을 위한 매우 다양한 기능을 갖는 그래픽 환경을 제공합니다.  Visual Basic 6와 같이 컨트롤을 "drag and drop"할 수 있고 속성을 편집할 수 있습니다. 코드 뿐만 아니라 HTML 및 XML에 대한 IntelliSense(자동 완성) 기능이 또한 지원됩니다.

이러한 비주얼하고 강력한 편집 기능은 개발 효율을 높여줍니다(개인적으로도 처음 ASP.NET을 접했을 때 Visual Studio .NET 개발 환경에 강한 인상을 받았습니다).

⑤       상태 관리(State management)

ASP의 상태 관리에 대하여 언급한 문제점을 보완하여, ASP.Net은 세션과 응용 프로그램의 상태관리에 대한 해법을 제시하고 있습니다. 세션 상태 정보는 메모리 혹은 데이타베이스에 저장될 수 있으며 웹 팜 환경에서의 공유가 가능하게 되었습니다. 또한 상태 정보는 클라이언트의 연결이 끊기거나 서버 작업이 실패한다 해도 복구될 수 있도록 디자인되었습니다.

⑥       서버 활성화 상태에서의 프로그램 갱신

클라이언트가 연결되거나 서버가 활성화 상태에서 프로그램 컴포넌트(파일)를 갱신시킬 수 있습니다. Framework는 새로운 버전의 컴포넌트를 가능한 빨리 응용 프로그램에 카피합니다. 이때, 삭제되거나 구 버전의 컴포넌트는 클라이언트의 연결이 끊길 때 까지 메모리 상에 위치되어 사용됩니다. 이후에는 새로운 버전의 컴포넌트가 로드됩니다.

⑦       XML에 기반한 환경 설정

ASP.NET에서의 환경 설정은 읽거나 수정하기 쉬운 XML 파일(Web.config)에 저장됩니다.이 파일은 확장 가능하며 다른 서버에 이식하기도 용이합니다. 다른 서버로 이전 시 단지 응용 프로그램 파일과 함께 XML 환경 구성 파일을 복사는 것으로 작업이 끝납니다.

３     정리

ASP는 많이 사용되어왔고 VB Script를 사용하여 많은 개발자들이 쉽게 익힐 수 있습니다. 많이 사용된 만큼 안정적이며 개발하기도 쉬워 빠르게 시스템을 구축할 수 있는 강점도 있습니다. 하지만 현재의 개발 패턴과 흐름에 부합되지 못하는 부분과 내포하고 있는 적지 않은 문제점들이 존재합니다.

 

이러한 문제들에 대한 해법을 제시하며 출시된 것이 .Net 플랫폼의 ASP.NET으로 기존 Classic ASP가 갖는 확장성 부족, 성능상의 문제, 보안 구성의 어려움, 유지보수의 어려움 등 많은 문제들에 대한 진보된 매커니즘을 보여주고 있습니다.

또한 ASP.NET 응용 프로그램을 위한 Visual Studio .NET 개발 환경은 개발 효율을 극대화 할 수 있는 방향으로 디자인되어 있습니다.

 

ASP를 구시대의 유물로 치부해 버릴 수는 없습니다. 좁은 의미에서 ASP.NET은 ASP의 확장된 버전입니다. 이것은 ASP.NET은 기존 Classic ASP에 대한 호환성을 유지하고 있다는 말입니다. 단, 스크립트 기반의 Classic ASP를 고수하는 것보다는 .Net 플랫폼 상의 ASP.NET으로 전환하는 것이 웹 응용 프로그램의 개발, 품질, 유지보수에 있어서 보다 많은 잇점이 있을 것입니다.

 

이 문서는 “ASP vs ASP.NET”에 초점이 맞춰져 있습니다. 정리를 마무리하기 전에 “X 솔루션 Upgrade와 관련한 ASP vs ASP.NET”에 관한 부분을 첨언해볼까 합니다.

 

“X 솔루션”의 경우 기존 시스템은 Classic ASP로 COM+을 사용하며, 신규 개발된 시스템의 경우 최신 ASP.NET으로 개발되어 있습니다. ASP와 ASP.NET의 비교 자료에 대한 이해로 볼 때 현재 “X 솔루션” 업그레이드를 고려함에 있어서, 기존 ASP 응용 프로그램의 ASP.NET으로의 Migration은 당연한 고민의 대상이 될 것입니다. 일전의 ACT Stress Test의 결과에서도 RPS(초당 요청 수)를 제외하고 User Connection과 CPU 점유율에 있어서 비교적 최근에 개발된 ASP.NET 응용 프로그램이 좀 더 안정적인 결과를 보여주고 있습니다(RPS에 대한 부분을 포함하여 ACT 테스트를 재검증 해볼 필요가 있습니다).

 

“X 솔루션”의 기존 ASP를 ASP.NET으로 Migration한다고 할 때, “X 솔루션” 업그레이드 여건(비용, 기간, 인력)을 고려하여 적절한 범위를 산정해야 할 것입니다. 또는 기존 ASP를 그대로 살리면서 각 시스템 내의 핵심 업무와 레포팅 서비스 부분 등을 따로 추출하여 여건에 맞는 범위를 설정한 후 ASP.NET으로 신규 개발 하는 것도 하나의 방법이 될 것입니다. Migration의 범주는 아니지만 Migration이 여의치 않을 경우, IIS 및 ASP 튜닝을 통해 시스템 성능을 최적화 하는 것도 “X 솔루션” 업그레이드에 있어서 하나의 대안이 될 수도 있습니다.

 

개인적인 생각이지만, 현재 “X 솔루션”의 서브 시스템들을 포괄하는 전체 범위에서 아키텍쳐, 코드 등 제반 사항에 대한 표준화와 정비는 필연적이고 궁극적인 부분이라 생각합니다. 현재 “X 솔루션” 업그레이드 계획을 차치하고, 적어도 “X 솔루션” 내의 각 서브 시스템들이 일관된 표준을 유지하고 유기적으로 연동되면 세션 및 상태 공유가 원활할 수 있도록, 보다 장기적인 안목에서 전체 시스템에 대한 업그레이드 계획을 수립한 후 단계적인 실행 절차를 밟아나가야 할 필요성이 있다고 생각합니다.

 

최근 몇년 사이 주목 받고 있는 IT 용어 중 하나로 X-인터넷(X-Internet)이 있다(X는 eXtended 또는 eXcutable의 의미를 갖는다). 요즘의 핵심 키워드인 Web2.0, Enterprize 2.0 등을 필두로 끊임없이 변화하고 있는 사용자의 인식과 패러다임에 발맞춰, 쉴틈 없이 새로운 기술과 이론들이 쏟아져나오고 또 사라져 가고 있는데, 혹자가 말하듯이 X-인터넷이 현재의 웹 클라이언트 환경을 대체할 만큼 충분한 파괴력 있는 개념이라고 할 수는 없을지라도 한 철 유행이라 치부할 수도 없는 것이, 최근 인트라넷 업무 시스템을 중심으로 기세를 넓혀가고 있는 것이 사실이다.

이미 X-인터넷 기반의 시스템을 도입한 곳이 적지 않고 모기업의 경우 현재 시범적으로 도입된 X-인터넷 기반 시스템을 구축하고 여타 시스템으로 확대 적용할 예정이라고 한다. 이들은 주로 X-인터넷 기반 제품(리치 클라이언트 솔루션)을 도입한 곳이 많은데, 그 제품들의 종류 또한 적지않다(그중 국산 제품이 입지가 높은 편이라 한다).

현재 진행중인 프로젝트 역시 X-인터넷 솔루션을 도입하기로 예정되어 있다. 그리고 이곳에 오기 직전 프로젝트에 대해 간단히 언급하고자 한다.

근간에 모 사이트의 프로젝트를 완료하였다. 시스템은 .Net Framework 2.0, C# 기반 하에 Smart Client와 XML Web Service, Reporting Service를 핵심 기술로 하여 구현되었다.

ASP.Net과 Classic ASP가 혼재되어 돌아가던 각각의 시스템들과 업무 개선을 위해 신규 추가되는 시스템들을 통합하여 구현하는 것이 목표였는데, S/W 아키텍처를 설계하고 기반 Framework을 구현 및 지원하는 것이 나의 역할이었다. 이전까지 스마트 클라이언트에 대한 경험이 전무한 상태였기에 초반 부담이 만만치 않았지만 결과적으로는 그럭저럭 괜찮은 시스템을 만들어 낼 수 있었던 것 같다.

기본적인 개발 환경은 다음과 같다.

• Windows 2003 Server
• Internet Information Service 6.0
• Microsoft SQL Server 2005
• Microsoft SQL Server 2005 Reporting Services (SSRS)
• Microsoft .NET Framework 2.0

IDE로 Visual Studio .Net 2005를 사용하여 개발하였다. 리포팅 툴로는 익숙하던 Crystal Reports를 버리고 모험적으로 Reporting Services를 선택했다. 써드파티 컴포넌트로는 FlexGrid(ComponentOne Studio.NET 2.0) 정도가 있다. 특이할만한 것은 초기 요구/분석, 설계 시점에 UML을 작성을 위한 모델링 도구로 스타유엠엘(StarUML v5.0.2.1570)을 사용한 것이다.

Smart Client 구현을 위한 Framework으로 초반에 Smart Client Composite UI Application Block 및 Smart Client Software Factory 또는 상용 프레임웍 도입을 고려하기도 하였으나, 결국은 위험 요소를 극복하고 자체 개발하였다. 프레임워크는 하부구조를 지원하는 Core Framework 부분과 Smart Client(Window Form)을 지원하는 PB(Project Base) Framework 부분으로 분리하여 구현하였다.

적용된 아키텍처의 간단한 모형이다.

사용자는 PC에서 설치된 메인 어플리케이션을 통해 모든 업무를 수행하게 된다. 기본적인 작업 단위는 모두 XML Web Service로 노출되어 있는데, 클라이언트는 ProxyWrapper와 리포트 뷰어를 통해 각각 웹서비스, 리포팅 서비스와 연동한다. 또한 웹서비스는 데이터 액세스 컴포넌트와 인터페이스하여 데이터를 조작하고 결과를 리턴 받는다.

메인 모듈을 제외하고 배포의 기본 단위는 몇개의 화면으로 묶여진 하나의 업무로 구성된 어셈블리이다(No-Touch Deployment). 마치 브라우저에서 자동으로 업데이트된 웹 페이지를 로드하는 것과 유사한 형태로 서버에 갱신된 버전이 있다면 클라이언트로 자동 다운로드 되어 보여진다(동일한 버전의 경우, 클라이언트는 Cache된 버전을 사용한다). 메인 모듈(메인 프로그램 및 프레임웍과 라이브러리 들)의 경우, Enterprise Library와 UAB(Updater Application Block)를 사용(Click Once를 사용하려 하였으나 몇가지 문제로 인하여 선회)하여 배포된다.

클라이언트(Smart Client)는 아래 그림과 같이 브라우저에 내장되는 방식이 아닌 독립 실행(Stand alone) 방식으로 구동된다.


개발 퍼포먼스도 좋았고 시스템도 그럭저럭 안정적으로 돌아간다. 물론 향후 업그레이드 해야할 몇가지 구조상의 문제도 있다(자세한 설명은 다음에 기회를 만들까 한다. ^^).

이번에 진행되는 프로젝트는 Java 기반이다. 이전 프로젝트와 상호 비교해볼 수 있는 좋은 계기가 될 듯 하다.