Page 21 -

예제 2-3은 ArrayList를 StringCollection으로 바꾼 것을 제외하면 예제 2-2와 완전히 동
일하다. StringCollection은 범용 컬렉션처럼 보이지만 실제로는 문자열만 저장할 수 있는 특
화된 컬렉션이다. StringCollection.Add는 string 타입만을 매개변수로 취하기 때문에 더 이

상 WebRequest 타입의 객체를 삽입할 수 없다. 결국, 이름을 출력할 때도 foreach 루프 내에서
string 타입 외의 다른 타입을 가져올 가능성이 없다(사실 null 참조를 가져올 가능성은 여전히
존재한다).

항상 문자열만 사용한다면 모를까, 문자열이 아닌 다른 타입을 컬렉션에 저장하고 싶다면 프레임
워크가 요행히 필요한 타입의 컬렉션을 제공하거나 혹은 직접 만들어 써야 한다. 임의의 타입을
저장할 수 있는 컬렉션을 직접 만들어야 하는 경우, 공통적으로 처리해야 할 부분을 사전에 구현

해 두어 반복적인 작업을 줄여 주는 클래스가 바로 System.Collections.CollectionBase 추상 클
래스이다. 또한 코드 생성기(code generator)를 활용하면 직접 코드를 입력해야 하는 수고를 덜 수
있다.

이 같은 방법으로 앞서 살펴봤던 문제들을 해결할 수 있지만, 매번 타입을 추가적으로 작성해야
하므로 비용이 적지 않다. 게다가 만일 코드 생성기가 변경되기라도 한다면, 기존 코드를 최신의
상태로 유지하기 위한 비용 또한 치러야 한다. 더불어 컴파일 소요 시간, 어셈블리의 크기, 지팅

(JITting) 시간, 코드를 저장하는 메모리 등도 무시할 수 없는 비용이다. 물론 가장 비싼 비용을 치
러야 하는 부분은 자체 개발한 컬렉션을 유지하기 위해 개발자가 계속 시간을 써야 한다는 점일
것이다.

비용을 애써 무시하더라도, 이런 방식으로는 다양한 컬렉션에 대해 타입 안정적으로 동작하는 메
서드를 작성할 수 없다. 일반적으로, 컬렉션이 저장하는 요소의 타입은 메서드를 작성할 때 매개
변수의 타입으로 사용하거나 반환 타입으로 사용하는 경우가 많기 때문이다. 예를 들어 컬렉션의

첫 번째 요소부터 N번째 요소까지 담고 있는 새로운 컬렉션을 반환하도록 메서드를 작성해야 한
다고 생각해 보자. ArrayList를 반환하도록 할 수도 있겠지만, 이렇게 하면 정적 타이핑의 장점
을 잃게 된다. 이와는 별도로 특정 메서드를 작성할 때 StringCollection 타입을 인수로 취하도
록 작성했다면, StringCollection 타입을 반환하는 메서드도 있을 것으로 미루어 짐작하게 된다.

이런 이유로 StringCollection의 요소 타입인 string은 메서드의 또 다른 입력으로 간주할 수 있
고, 반환 타입에도 직접적으로 영향을 미친다. C# 1에서는 이를 표현할 방법이 없었다. 이제 제네
릭을 살펴보자.

062