사막의 고독한 낙타

레퍼런스 타입에 대해서는 하나의 코드만 생성하기 때문에 각각의 타입에 대해 코드를 생성하는 것에 비해 코드 양을 현저하게 줄일 수 있다. C++의 템플릿의 겨우 모든 타입에 대해 인라인 코드를 생성하는 것과 차이를 보이는 부분이라고 할 수 있겠다.

제네릭스에서 제약 지정

제네릭스로 작성된 코드를 컴파일하면 C# 컴파일러는 이후에 어떤 타입을 사용할 것인가에 무관하게 IL 코드를 생성하게 된다. 결과적으로 잘못된 타입으로 메쏘드를 호출하거나, 속성이나 멤버 변수를 사용하게 될 위험을 내포하게 된다. 이를 막기 위해 C#에서는 컴파일러에게 타입에 대한 제약을 지정할 수 있도록 한다.

제약에는 타입이 특정 타입으로부터 파생된 것이어야 함을 컴파일러에게 알려주는 파생 제약(Derivation Constraints), 제네릭스 타입은 public으로 지정될 기본 생성자(default constructor)를 가져야한다는 생성자 제약(Constructor Constraints), 그리고 제네릭스 타입이 참조 유형인지 값 유형인지를 제약하는 참조/값 제약(Reference /Value Type Constraints)이 있다. C# 제네릭스에서 제약은 복수로 지정할 수 있다.

파생 제약(Derivation Constraints)

다음 예를 보자. 제네릭스 클래스 Node는 키(Key, K)와 값(Value, T)을 제네릭스 파라미터로 가진다. Node의 속성 Key는 K 타입으로 정의되어 있다고 하자. 이 때, LinkedList 클래스의 Find 메쏘드에서 Key 속성에 대해 CompareTo라는 메쏘드를 호출하고 있다. 그런데, 만약 K 타입에 CompareTo 메쏘드를 가지지 않은 클래스를 사용하면 어떻게 될까? 이러한 문제 때문에 C# 컴파일러는 다음과 같은 코드를 컴파일하지 않고 컴파일러 오류를 발생시키게 된다.

이를 해결하기 위해서는 CompareTo 메쏘드를 정의한 인터페이스를 정의하여 LinkedList 클래스와 Node 클래스의 제네릭스 파라미터가 이 인터페이스로부터 파생된 것임을 나타낼 필요가 있다.

생성자 제약(Constructor Constraints)

제네릭스 클래스에서 제네릭스 객체를 생성할 필요가 있는 경우, 이 타입이 어떤 파라미터를 가지는 생성자를 제공하고 있는 지 알 수 없기 때문에 컴파일 오류가 발생하게 된다. 이 문제를 해결하기 위해 C#에서는 제네릭스 타입에 대해 public으로 지정된 기본 생성자를 지원해야 한다는 제약을 지정할 수 있다. 이 제약의 형태는 다음과 같다.

참조/값 제약(Reference/Value Type Constraints)

제네릭스 타입으로 사용되는 타입이 참조 유형이어야 할지 값 유형이어야 할지를 지정할 수 있는 제약이 참조/값 제약이다. struct 혹은 class 키워드를 지정함으로써 제약을 지정할 수 있다.

제네릭스 메쏘드

C++의 템플릿 함수에 대응되는 기능이 제네릭스 메쏘드(Generic Methods)라고 할 수 있겠다. 메쏘드 레벨에 제네릭스 타입을 지정할 수 있도록 하고 있는데, 제네릭스 타입을 지정하는 방법은 클래스 레벨과 유사하다. 제네릭스 메쏘드에 대해서도 제네릭스 제약을 지정할 수도 있다.

일반적인 인스턴스 메쏘드에 대해서 뿐 아니라 정적(static) 메쏘드가 있는 클래스의 경우에 대해서도 제네릭스 타입을 지정하여 사용할 수 있다. 제네릭스로 정의된 정적 메쏘드를 호출할 때는 클래스 명에 실제 사용하고자 하는 타입을 지정하여 사용하면 된다.

제네릭스 델리게이트

C#에서 제네릭스로 정의할 수 있는 것은 클래스, 인터페이, 메쏘드 만이 아니다. 델리게이트(delegate)도 제네릭스로 정의할 수 있다(사실 델리게이트도 내부적으로는 클래스로 정의된다고 보면 당연한 것이라고 볼 수도 있겠다). 제네릭스 클래스 내에 델리게이트를 정의하는 것도 가능하고, 델리게이트에만 별도로 제네릭스 타입 파라미터를 지정할 수도 있다. 델리게이트는 클래스 외부에서 정의할 수도 있는데, 이 경우에도 제네릭스 파라미터를 지정할 수 있다.

제네릭스 델리게이트는 이벤트와 함께 사용할 때 매우 유용하다. UI가 강한 애플리케이션을 개발하다보면 약간씩 파라미터만 달라지는 델리게이트를 여러 개 만드는 경우가 있다. 이런 경우 제네릭스 델리게이트 하나면 공통으로 사용 가능하다.

제네릭스와 리플렉션

닷넷 프레임워크 2.0의 리플렉션(reflection)은 제네릭스 파라미터를 지원한다. 제네릭스를 지원하도록 확장된 Type 클래스의 제네릭스 관련 멤버는 다음과 같다.

이전 버전의 C#에서와 마찬가지로 Type 정보를 얻기 위해 typeof 연산자와 GetType() 메쏘드를 사용할 수 있다.두 가지 방법에 차이점이 있다면, 특정 타입이 지정되지 않은 제네릭스 타입에 대해 Type 정보를 얻으려면 typeof 오퍼레이터를 사용해야 한다는 것이다. 이 때 “<>”와 같이 빈 괄호를 사용하면 된다.

리플렉션을 사용하는 중요한 이유는 동적으로 타입 정보를 사용할 수 있다는 것이다. Type 클래스의 MethodInfo를 이용하여 메쏘드 정보를 얻어서, 이를 동적으로 호출하는 방법은 제네릭스로 정의한 클래스나 메쏘드에도 동일하게 적용될 수 있다. 다음 예제는 제네릭스로 정의된 LinkedList 클래스의 메쏘드 AddHead를 MethodInfo를 이용하여 호출하는 것을 나타내고 있다.

리플렉션은 로컬 객체에만 적용되는 것이 아니라 리모팅 객체에도 적용될 수 있다. 따라서 리모트 서버에서 제네릭스로 정의된 서버를 사용하고자 하는 타입별로 서비스하면 클라이언트에서는 해당하는 타입에 맞는 서버를 사용하면 된다. 다음 예제는 ISharedInterface 인터페이스를 통해 리모팅 서비스를 구현한 것이다. 예제의 클라이언트와 호스트 서버에서 주석처리한 부분과 같이 사용할 수 있다면 좋겠다는 생각이 들기도 한다. 주석처리된 부분의 코드는 컴파일시에는 문제가 없지만 실행시에 오류가 발생한다. 당연한 얘기지만, 제네릭스 파라미터에 대해 특정 타입을 지정하지 않으면 인스턴스를 생성할 수 없기 때문에 리플렉션으로 이러한 시도를 하면 오류를 발생하는 것이다.

이 예제에서는 원격 객체를 등록하는 작업이나, 로컬에서 이를 사용하기 위해 인스턴스를 생성하는 코드를 하드 코딩한 예를 보여주었으나, 다음과 같이 설정 파일을 통해 제네릭스 파라미터를 가지는 원격 서버 객체에 대해 설정할 수 있다.

제네릭스의 성능

실제 시스템을 개발하는 입장에서 성능은 늘 중요한 이슈가 된다. 제네릭스를 설계하고 개발한 팀의 목표는 제네릭스를 사용했을 때 성능의 저하가 없도록 하겠다는 것이었다고 한다. 여러 벤치마킹 자료들을 보면 제네릭스을 사용하여 구현한 코드가 일반적인 object형을 사용하여 구현한 코드보다 좋은 성능을 나타내는 것으로 나타나고 있다.

필자도 간단히 Stack을 제네릭스를 사용한 경우와 object형을 사용하여 각각 구현하고 다음과 같은 테스트 코드를 작성하여 성능을 비교해 보도록 하겠다.

비교를 위해 C++ 템플릿을 사용한 경우를 이와 동일하게 구현하여 테스트를 수행하였다. C++의 경우 object형과 string형이 없어 테스트를 생략하였다. 결과는 <표 1>과 같다.

object형이나 string에 대해서는 object로 구현한 Stack이나 제네릭스을 사용하여 구현한 Stack이나 별반 차이가 없다. 하지만 int나 double과 같은 value type에 대해 연산을 수행한 경우 제네릭스를 사용하여 구현한 Stack이 3배 이상 좋은 성능을 보여주고 있다. 이는 value type에 대한 박싱과 언박싱이 제거된 효과이다.

좋은 무기는 사용할 때 가치가 있다

C#의 제네릭스는 성능이나 생산성의 저하 없이도 타입에 대해 안전한 클래스를 정의할 수 있도록 해준다. 뿐만 아니라 CLR 차원에서 제네릭스를 지원하고 있기 때문에 개발할 때 뿐 아니라, 실행할 때도 코드의 재사용이 이루어진다.

제네릭스로 정의할 수 있는 것은 클래스와 인터페이스뿐 아니라, 메쏘드와 델리게이트를 포함한다. 제네릭스는 C#과 닷넷 프레임워크 2.0의 핵심적인 기능으로 리플렉션과 리모팅에서도 사용 가능하며, 프레임워크 라이브러리의 많은 부분이 제네릭스를 지원하고 있다.

아쉬운 점은 웹 서비스에서 제네릭스를 사용할 수 없다는 것이다. 이것은 C# 혹은 닷넷의 제약이라기보다는 웹 서비스 표준이 제네릭스를 지원하지 못하는 것 때문이라 할 수 있겠다. 또한, 엔터프라이즈 서비스(enterprise service)에서 서비스 컴포넌트(serviced component) 를 만들 때, 제네릭스 타입을 사용할 수 없다. 이 제약 역시 닷넷 자체적인 제약이 아니라, COM이 제네릭스를 지원하지 않기 때문이라고 할 수 있다(혹시나, 템플릿으로 COM을 정의할 수 있는데, 왜 닷넷에서는 안 되는 것일까 하고 생각하는 독자가 있다면 혼동 없길 바란다. 템플릿을 사용하여 COM을 정의할 수는 있지만, COM 컴포넌트 자체가 파라메트릭하게 정의되는 것은 아니다).

C# 제네릭스를 사용하지 않는 것은 앙꼬 없는 찐빵 먹기에 비유하면 좀 지나친 비유가 될지 모르겠다. 먹는 것이야 취향에 따라 다를 수 있는 문제니 웃어넘긴다 해도, C# 2.0에서 제네릭스를 사용하지 않겠다는 것은 정말 값진 무기를 가지고 있음에도 단검으로 싸우겠다는 것과 같다. 적극적으로 제네릭스에 도전하고 사용하여, C++의 STL과 같이 멋진 라이브러리가 C#으로도 만들어졌으면 하는 바람이다.

참고자료

① Design and Implementation of Generics for the .NET Common Language Runtime. Andrew Kennedy, Don Syme, http://reserach.microsoft.com/projects/clrgen/generics.pdf
② An Introduction to C# Generics, Juval Lowy, http://msdn.microsoft.com/library/defualt.asp?yrl= /library/en-us/dnvs01/html/csharp_generics.asp
③ Introducing Generics in the CLR, Jason Clark, http://msdn.microsoft.com/msdnmag/issuses/03/09/NET/
④ More on Generics in the CLR, Jason Clark, http://msdn.microsoft.com/msdnmag/issuses/03/10/NET/
⑤ Generics in the Java Progamming Language, Gliad Bracha, http://java.sun.com/j2se/1.5/pdf/generics-tutorial.pdf