CLR

공통 타입 시스템(Common Type System, CTS)은 CLR이 지원하는 모든 데이터 타입과 관련 연산을 정의하는 형식 시스템의 핵심 규격이다. 이는 .NET 언어들이 서로 호환될 수 있는 기반을 제공하며, 서로 다른 프로그래밍 언어로 작성된 코드 간의 원활한 상호 운용성을 보장한다. CTS는 값 타입과 참조 타입이라는 두 가지 주요 범주로 모든 타입을 구분한다.

값 타입은 스택에 직접 저장되며 변수에 값 자체가 포함된다. 기본 제공 타입(예: int, float, bool), 열거형(enum), 사용자 정의 구조체(struct)가 이에 해당한다. 참조 타입은 힙에 할당되며, 변수는 힙에 있는 객체의 참조(주소)를 보유한다. 클래스, 인터페이스, 배열, 대리자(delegate)가 대표적인 참조 타입이다. 이 구분은 변수 할당, 매개변수 전달 방식, 메모리 관리 방식에 근본적인 차이를 만든다.

CTS는 모든 타입이 반드시 System.Object 클래스에서 최종적으로 상속받도록 규정한다. 이는 모든 타입이 ToString(), GetType(), Equals()와 같은 공통 메서드를 공유함을 의미한다. 또한, 타입의 가시성(public, private 등), 멤버(메서드, 속성, 필드, 이벤트)의 정의 방식, 상속 규칙 등에 대한 표준 모델을 제공하여 언어 간의 일관성을 유지한다.

이 체계 덕분에 C#에서 정의한 클래스를 Visual Basic .NET에서 인스턴스화하고 사용하는 것이 가능해진다. CTS는 공용 언어 사양(CLS)의 상위 집합으로, CLS는 언어 간 상호 운용성을 위해 CTS의 기능 중 모든 언어가 준수해야 하는 공통 부분을 규정한다.

공용 언어 사양(CLS)은 공통 타입 시스템(CTS)의 하위 집합으로, 서로 다른 프로그래밍 언어로 작성된 코드가 .NET Framework 환경에서 원활하게 상호 운용되도록 보장하기 위해 정의된 규칙과 제약 조건의 집합이다. 주된 목적은 언어 간 상호 운용성을 촉진하는 것이다. CLS는 주로 컴포넌트와 라이브러리의 개발자를 대상으로 하며, 이러한 라이브러리가 CLS를 준수하여 작성되면 다른 모든 CLS 호환 언어에서 안전하게 사용될 수 있다.

CLS 규칙은 공개적으로 노출되는 API(예: public, protected 멤버)에만 적용된다. 내부 구현(private 또는 internal 멤버)은 어떠한 언어 특성도 사용할 수 있다. 주요 규칙으로는 특정 데이터 타입의 사용 제한, 메서드 오버로딩 규칙, 예외 처리 방식의 통일 등이 포함된다. 예를 들어, CLS 규격 코드는 부호 없는 정수 타입(uint)을 공개 API의 일부로 노출해서는 안 되며, 오버로드된 메서드는 매개변수의 개수나 타입만으로 구별되어야 한다[2].

개발자는 [assembly: CLSCompliant(true)] 특성을 프로젝트에 적용하여 컴파일러가 CLS 규격을 검사하도록 할 수 있다. 이는 C#, Visual Basic .NET, F# 등 다양한 언어가 공통의 중간 언어(IL)로 컴파일된 후 하나의 애플리케이션에서 함께 작동할 수 있는 기반을 제공한다. 따라서 CLS는 .NET의 "언어 중립성"이라는 핵심 가치를 실현하는 데 필수적인 구성 요소이다.

가상 실행 시스템(VES)은 CLR의 실행 엔진으로, 중간 언어(IL)로 컴파일된 코드를 실제 컴퓨터가 이해할 수 있는 기계어로 변환하고 실행하는 역할을 담당한다. VES의 가장 핵심적인 기능은 JIT 컴파일(Just-In-Time Compilation)이다. JIT 컴파일러는 어셈블리가 로드되고 메서드가 처음 호출될 때, 해당 메서드의 IL 코드를 실시간으로 네이티브 코드로 컴파일한다. 이렇게 컴파일된 네이티브 코드는 메모리에 캐시되어, 동일한 메서드가 다시 호출될 때는 재컴파일 없이 바로 실행될 수 있다.

JIT 컴파일 과정은 단순한 번역을 넘어서 다양한 최적화를 수행한다. 실행 환경의 실제 CPU 아키텍처를 고려한 최적화[3]와 애플리케이션의 런타임 동작을 기반으로 한 최적화[4]가 대표적이다. 이는 정적 컴파일 언어가 가질 수 없는 상황별 최적화의 이점을 제공한다.

VES의 작동 모드는 크게 두 가지로 구분된다. 표준 JIT 컴파일 외에, 애플리케이션 설치 시 또는 실행 전에 모든 IL 코드를 네이티브 이미지로 미리 컴파일하는 NGEN(Native Image Generator) 도구를 사용할 수 있다. NGEN으로 생성된 네이티브 이미지는 시작 속도를 개선하고 메모리 사용을 최적화할 수 있지만, 런타임 정보를 활용한 동적 최적화는 적용되지 않는다.

이러한 VES와 JIT 컴파일의 구조는 "한 번 작성하면 어디서나 실행된다"는 관리 코드의 이식성 원칙을 실현하는 기술적 기반이 된다. 개발자는 특정 CPU를 대상으로 코드를 작성할 필요 없이, CLR이 제공하는 가상 머신을 대상으로 IL 코드를 생성하면 된다. VES가 해당 플랫폼에 맞는 네이티브 코드로 최종 변환을 담당하기 때문이다.

관리되는 모든 참조 타입 객체와 박싱된 값 타입은 관리 힙이라는 CLR이 관리하는 메모리 영역에 할당됩니다. 이 영역은 운영 체제로부터 예약되어 있으며, 객체 생성 요청이 들어올 때마다 힙의 다음 사용 가능한 주소에 메모리를 할당하는 연속적인 방식으로 작동합니다. 이 할당 과정은 매우 빠르며, 단순히 포인터를 이동시키는 것에 가깝습니다.

객체의 수명 주기는 루트 참조에 의해 결정됩니다. 루트 참조는 전역 변수, 정적 필드, 지역 변수, CPU 레지스터의 참조, 파이널라이저 큐의 참조 등 애플리케이션에서 객체에 접근할 수 있는 모든 경로를 의미합니다. 가비지 컬렉터는 정기적으로 또는 메모리 부족 시에 실행되어, 모든 루트 참조부터 시작하여 도달 가능한 객체 그래프를 추적합니다. 이 과정에서 도달할 수 없는 객체는 더 이상 사용되지 않는 것으로 판단되어 가비지로 표시됩니다.

가비지 컬렉션 사이클은 크게 표시(Mark), 계획(Plan), 휩쓸기(Sweep), 조각 모음(Compact) 단계로 나눌 수 있습니다. 표시 단계에서는 모든 활성 객체를 식별합니다. 계획 단계에서는 죽은 객체가 차지한 공간을 계산하고, 조각 모음이 유익한지 판단합니다. 휩쓸기 단계에서는 죽은 객체의 메모리 공간을 재사용 가능한 것으로 표시합니다. 마지막으로 조각 모음 단계에서는 살아남은 객체들을 힙의 한쪽으로 이동시켜 단편화를 줄이고, 할당 포인터를 새로운 연속된 공간의 시작점으로 재설정합니다.

객체의 최종 정리에는 파이널라이저가 관여할 수 있습니다. 파이널라이저가 정의된 객체는 가비지 컬렉션에서 즉시 회수되지 않고, 파이널라이저 스레드가 해당 메서드를 실행한 후 다음 사이클에서 회수됩니다. 이로 인해 메모리 해제가 지연되고 성능에 부정적 영향을 미칠 수 있으므로, IDisposable 인터페이스를 통한 명시적 자원 해제 패턴이 권장됩니다[6].

가비지 컬렉션은 관리 힙에서 더 이상 사용되지 않는 객체를 식별하고 회수하여 메모리를 확보하는 과정이다. CLR의 가비지 컬렉터는 성능을 최적화하기 위해 객체를 수명에 따라 0세대, 1세대, 2세대의 세 가지 세대로 구분하여 관리한다. 이는 '대부분의 객체는 짧은 시간 동안만 사용된다'는 경험적 관찰에 기반한 세대별 가비지 수집이라는 전략이다.

새로 할당된 객체는 0세대에 위치한다. 가비지 컬렉션이 발생할 때, 0세대에서 살아남은(아직 참조되고 있는) 객체는 1세대로 승격된다. 마찬가지로, 1세대에서 가비지 컬렉션이 발생한 후 살아남은 객체는 2세대로 이동한다. 2세대는 가장 오래 살아남은 객체들을 담는다. 각 세대별 컬렉션의 빈도와 방식은 다르게 설계되어 있다. 0세대 컬렉션은 가장 빈번하게 발생하며 속도가 빠르다. 2세대 컬렉션은 전체 힙을 대상으로 할 수 있어 가장 부담이 크지만, 상대적으로 드물게 수행된다.

이 세대별 접근법의 주요 이점은 성능이다. 작은 0세대 힙 영역만을 빈번히 검사함으로써 전체 힙을 스캔하는 데 드는 비용을 줄인다. 또한, 수명이 짧은 임시 객체는 0세대에서 빠르게 회수되고, 장수하는 객체는 2세대로 이동하여 계속해서 검사 대상에서 벗어나게 되어 효율성이 높아진다. 가비지 컬렉터는 추가적으로 대형 객체 힙을 별도로 관리하여 큰 객체(일반적으로 85,000바이트 이상)가 세대 간 이동으로 인한 복사 비용을 발생시키지 않도록 한다.

이 구조는 애플리케이션의 메모리 할당 패턴에 동적으로 적응한다. 예를 들어, 많은 양의 객체가 0세대 컬렉션에서 살아남아 1세대로 승격되면, 가비지 컬렉터는 다음 컬렉션 시 1세대의 임계값을 조정하거나 1세대 컬렉션을 트리거할 수 있다[7].

어셈블리는 CLR에서 배포, 버전 관리, 보안 및 재사용의 기본 단위가 되는 논리적 단위이다. 하나의 물리적 파일(.exe 또는 .dll)로 구성될 수도 있고, 여러 모듈과 리소스 파일로 구성될 수도 있다. 어셈블리의 핵심은 매니페스트(Manifest)라고 불리는 메타데이터 테이블을 포함한다는 점이다. 매니페스트는 어셈블리에 대한 자체 설명 정보를 담고 있어, CLR이 어셈블리를 실행하는 데 필요한 모든 정보를 제공한다.

매니페스트에는 다음과 같은 주요 정보가 포함되어 있다.

이러한 구조는 의존성 지옥(DLL Hell) 문제를 완화하는 데 기여한다. CLR은 매니페스트에 기록된 버전 정보를 바탕으로 정확한 버전의 어셈블리를 로드할 수 있다. 또한 어셈블리는 전용(private)으로 응용 프로그램 디렉터리에 배치되거나, 전역 어셈블리 캐시(GAC)에 공유 어셈블리로 설치될 수 있다. 매니페스트는 어셈블리가 자체적으로 완결된(self-describing) 단위가 되어, 시스템 레지스트리와 같은 외부 정보에 의존하지 않고도 독립적으로 실행될 수 있게 한다.

리플렉션은 실행 중인 어셈블리의 메타데이터를 검사하고, 그 안에 정의된 타입, 멤버, 모듈 등을 동적으로 탐색하거나 인스턴스를 생성하고 메서드를 호출하는 기능을 제공합니다. 이는 런타임에 타입 정보에 접근할 수 있게 해주는 강력한 메커니즘입니다. 리플렉션의 핵심 클래스는 System.Type이며, typeof 연산자나 Object.GetType() 메서드를 통해 특정 타입의 Type 객체를 얻을 수 있습니다.

리플렉션을 활용하면 프로그램에서 알려지지 않은 타입을 조사하고 조작할 수 있습니다. 일반적인 활용 사례로는 타입의 필드, 속성, 메서드 목록을 열거하거나, 특정 애트리뷰트가 적용된 멤버를 찾는 것이 있습니다. 또한 Activator.CreateInstance 메서드를 사용하여 타입의 인스턴스를 동적으로 생성하거나, MethodInfo.Invoke를 통해 메서드를 호출할 수 있습니다. 이 기능은 객체 직렬화/역직렬화, 의존성 주입 컨테이너, 데이터 바인딩, 플러그인 아키텍처 구현 등 다양한 고급 시나리오의 기반이 됩니다.

리플렉션은 유연성을 제공하지만, 성능 오버헤드와 보안 고려 사항이 따릅니다. 정적으로 알 수 있는 타입 작업에는 리플렉션 사용을 피하는 것이 좋습니다. 또한 완전 신뢰 환경이 아닐 경우 필요한 권한이 제한될 수 있습니다. C#의 dynamic 키워드나 ExpandoObject 같은 후속 기능들은 일부 동적 시나리오에서 리플렉션 사용을 간소화하는 대안을 제공하기도 합니다.

코드 액세스 보안은 CLR이 제공하는 보안 메커니즘으로, 실행 중인 코드의 신원(예: 출처, 발행자, 암호화 서명)에 기반하여 해당 코드가 보호된 리소스나 작업에 접근할 수 있는 권한을 제어한다. 이는 전통적인 역할 기반 보안이 사용자 신원에 초점을 맞추는 것과 대비되는 개념이다. CAS 정책은 코드가 가진 증거(어셈블리가 로드된 위치, 디지털 서명, 강력한 이름 등)를 평가하여 권한 집합을 부여하는 방식으로 작동한다.

주요 구성 요소로는 권한, 증거, 정책 수준, 권한 집합이 있다. 권한은 파일 시스템 접근, 레지스트리 접근, 네트워크 연결 생성 등 보호된 작업을 나타낸다. 증거는 어셈블리와 함께 제공되어 출처를 증명하는 정보이다. CLR은 엔터프라이즈, 머신, 사용자, 애플리케이션 도메인 네 가지 정책 수준에서 증거를 평가하며, 각 수준에서 부여된 권한 집합의 교집합이 코드에 부여되는 최종 권한이 된다.

CAS의 동작은 런타임에 스택 워크를 수행하여 모든 호출자 체인에 필요한 권한이 있는지 확인하는 방식으로 이루어진다. 이는 한 코드 조각이 높은 권한을 가진 다른 코드를 호출하여 권한을 우회하는 "래더 공격"을 방지하기 위한 것이다. 또한, 코드는 특정 권한을 요구하거나, 특정 권한이 없어도 실행되도록 선언할 수 있으며, 이는 런타임이 어셈블리를 로드할 때 검사한다.

이 모델은 부분적으로 신뢰하는 코드(예: 인터넷에서 다운로드한 컨트롤)가 시스템 리소스에 피해를 주지 않도록 샌드박스 환경에서 실행되도록 하는 데 유용했다. 그러나 실제 환경에서의 복잡한 정책 관리와 성능 오버헤드, 공격 경로의 다양화로 인해 .NET Framework 4.0 이후로는 기본적으로 사용되지 않으며, 보안 투명성 모델 등 다른 접근법이 강조되었다[11].

역할 기반 보안은 CLR이 제공하는 보안 메커니즘 중 하나로, 애플리케이션이 실행 중인 사용자나 프로세스의 역할과 권한을 기반으로 특정 작업이나 리소스에 대한 접근을 제어합니다. 이는 코드 액세스 보안이 코드 자체의 신원과 권한을 검사하는 것과는 차별화된 접근법입니다. 역할 기반 보안은 주로 사용자 인증 및 권한 부여와 관련된 비즈니스 로직 수준의 보안 요구사항을 구현하는 데 사용됩니다.

이 모델의 핵심 구성 요소는 주체 객체와 권한 객체입니다. 주체 객체는 실행 중인 코드의 사용자 신원과 그가 속한 역할(예: 관리자, 일반 사용자, 게스트)을 캡슐화합니다. 개발자는 코드 내에서 IsInRole 메서드를 사용하거나 PrincipalPermission 요구를 통해 현재 주체가 특정 역할을 갖고 있는지 명시적으로 확인할 수 있습니다. 이를 통해 특정 메서드나 기능에 대한 접근을 역할에 따라 허용하거나 거부할 수 있습니다.

역할 기반 보안의 작동 방식은 다음과 같이 요약할 수 있습니다.

이 모델은 .NET Framework의 System.Security.Principal 네임스페이스에 정의된 인터페이스와 클래스들을 통해 구현됩니다. Windows 애플리케이션의 경우 WindowsIdentity와 WindowsPrincipal 클래스를 사용하여 Active Directory 도메인이나 로컬 머신의 Windows 그룹과 통합하는 것이 일반적입니다. 또한, GenericIdentity와 GenericPrincipal을 사용하면 사용자 지정 인증 시스템에 기반한 역할 기반 보안을 쉽게 구축할 수 있습니다.

CLR 호스팅은 관리되지 않는 애플리케이션이 CLR을 프로세스 내에 로드하고 실행 환경을 구성하며, 관리 코드를 실행할 수 있도록 하는 기능이다. 이를 가능하게 하는 인터페이스 집합이 CLR 호스팅 API이다. 대표적인 호스트로는 IIS, SQL Server, Microsoft Office 또는 사용자 정의 서비스 애플리케이션이 있다. 호스팅 API는 호스트가 CLR의 동작을 세밀하게 제어할 수 있게 하여, 애플리케이션 도메인 생성, 어셈블리 로드 정책 설정, 쓰레드 풀 관리, 가비지 컬렉션 동작 모니터링 등을 수행한다.

주요 인터페이스는 ICLRRuntimeHost와 ICLRMetaHost 등이 있다. 호스팅 프로세스는 일반적으로 CorBindToRuntimeEx 또는 CLRCreateInstance와 같은 함수를 사용하여 CLR 인스턴스를 초기화한다. 이후 호스트는 ICLRRuntimeHost::Start 메서드를 호출하여 CLR을 시작하고 관리 코드 실행을 준비한다. 호스트는 또한 애플리케이션 도메인 관리자(AppDomainManager)를 지정하여 특정 애플리케이션 도메인 내에서 보안 정책, 어셈블리 로드 해결 방식 등을 사용자 정의할 수 있다.

CLR 호스팅 API를 통해 호스트는 다음과 같은 고급 제어를 할 수 있다.

이러한 호스팅 기능은 서버 환경에서 여러 독립적인 애플리케이션을 단일 프로세스에서 안정적으로 격리 실행하거나, 기존 네이티브 애플리케이션에 관리 코드 컴포넌트를 점진적으로 통합하는 시나리오에서 필수적이다. 예를 들어, SQL Server는 CLR 호스팅을 통해 데이터베이스 내에서 CIL로 작성된 저장 프로시저를 실행한다.

COM 상호 운용성은 .NET 코드가 기존의 COM 구성 요소(예: ActiveX 컨트롤)를 사용하거나, 반대로 COM 클라이언트가 .NET 어셈블리를 COM 객체처럼 호출할 수 있게 합니다. CLR은 런타임 호출 가능 래퍼와 COM 호출 가능 래퍼를 자동으로 생성하여 양측 간의 데이터 형식, 메모리 관리, 오류 처리 방식 차이를 중개합니다. 이를 통해 개발자는 레거시 COM 라이브러리를 재사용하거나 .NET 컴포넌트를 Microsoft Office 같은 COM 기반 애플리케이션에 노출시킬 수 있습니다.

P/Invoke는 플랫폼 호출 서비스로, 관리 코드에서 Win32 API 같은 네이티브 DLL에 구현된 비관리 C/C++ 함수를 직접 호출하는 메커니즘입니다. 개발자는 DllImport 특성을 사용하여 대상 함수, DLL 이름, 호출 규칙, 문자열 마샬링 방식 등을 선언합니다. CLR은 이 선언을 바탕으로 필요한 마샬링 작업을 수행하여 관리 데이터 형식을 비관리 형식으로 변환하고, 함수 호출 후 결과를 다시 관리 형식으로 반환합니다.

이 두 기술은 .NET이 기존 Windows 생태계와 원활하게 통합될 수 있는 기반을 제공합니다. 그러나 성능 오버헤드가 발생할 수 있으며, 특히 P/Invoke를 통한 잘못된 포인터나 메모리 관리는 애플리케이션의 안정성을 해칠 수 있습니다. 따라서 네이티브 리소스의 정확한 해제와 데이터 마샬링에 주의를 기울여야 합니다.

.NET Framework의 초기 버전부터 CLR은 윈도우 운영체제와 긴밀하게 통합된 단일 구현체로 발전해왔다. 그러나 크로스 플랫폼과 오픈 소스라는 현대적 요구사항은 CLR의 구조에 근본적인 변화를 가져왔다.

이 변화의 핵심 결과물은 .NET Core 프로젝트에서 개발된 CoreCLR이다. CoreCLR은 원본 CLR의 핵심 기능(가비지 컬렉터, JIT 컴파일러, 기본 타입 시스템)을 유지하면서도, 모듈화와 이식성을 최우선으로 재설계되었다. 주요 차이점은 다음과 같다.

이러한 재설계는 .NET 5와 그 이후의 통일된 .NET 플랫폼으로 이어졌다. .NET 5 이상에서는 'CoreCLR'이라는 명칭이 공식적으로 사라지고, 단순히 '.NET 런타임' 또는 'CLR'로 통칭되지만, 그 기반은 CoreCLR의 모듈화되고 크로스 플랫폼인 아키텍처이다. 이 변화는 런타임이 더 가볍고, 다양한 시나리오(클라우드, 컨테이너, 임베디드)에 최적화될 수 있도록 했으며, JIT 컴파일 외에 AOT 컴파일을 통한 성능 최적화 옵션도 확장되었다[12].