Java를 아는 사람을 위한 .NET 견주어 이해하기

JDK, JRE, JVM의 구조를 알고 있다면 .NET의 거의 이름만 바꿔 읽으면 될 정도로 닮은게 많습니다. Java 와 Spring 으로  백엔드를 공부했던 저에게 한가지 개념을 제대로 이해하면 다른 언어와 프레임워크도 충분히 이해할 수 있다는 믿음이 있었는데요. 이번엔 자바에서 아는 개념이 .NET의 어디에 해당하는지를 대응표와 그림으로 정리하고, 구조는 닮았지만 설계가 갈린 지점을 따로 짚어 보았습니다.

 

 

1️⃣ 한 눈에 보는 대응표

두 언어를 공부하다 느낀 건데 두 언어의 플랫폼은 같은 뼈대를 쓴다는 것입니다. 소스를 중간 코드로 컴파일하고, 가상 머신이 그것을 JIT로 기계어로 바꿔 실행하고, 메모리는 GC가 관리합니다. 구성 요소가 거의 일대일로 매칭이 됐습니다.

 

Java	.NET	역할
JDK	.NET SDK	개발 도구 키트(아래 런타임·컴파일러 포함)
JRE	.NET Runtime	실행 엔진 + 기본 라이브러리. 만들어진 앱을 돌릴 때
JVM	CLR (CoreCLR)	GC, JIT, 타입 로딩. 실행 엔진 그 자체
클래스 라이브러리 (java.*)	BCL (System.*)	기본 클래스(컬렉션, 문자열, 파일, 네트워크)
javac	Roslyn (csc)	컴파일러(소스 → 중간 코드)
바이트코드 (.class, .jar)	IL (.dll)	중간 코드(실행 때 JIT가 기계어로 변환)
java 명령	dotnet 명령	앱 실행(.net은 SDK가 있으면 빌드도 겸함)
Maven, Gradle	MSBuild + NuGet	빌드와 패키지 관리(.NET은 SDK에 포함, 자바는 빌드 도구를 따로 설치.)
Spring MVC, Spring Boot	ASP.NET Core	웹 프레임워크
Java, Kotlin, Scala	C#, F#	같은 가상 머신 위의 언어들

 

 

 

2️⃣어떤 언어가 먼저 개발 됐을까?

C#은 이름에 C가 들어가 C, C++의 바로 다음 세대처럼 보이지만 Java보다 7년 늦게 나왔습니다. 이름의 #은 음악의 올림표(샾)이고, C 계열 문법을 이어받았다는 뜻입니다.

문법은 실제로 C 계열입니다. 중괄호, 세미콜론, for, if 같은 것들입니다. 그런데 그것은 Java도 마찬가지입니다. Java 역시 C++ 개발자가 쉽게 넘어오도록 C++ 문법을 빌려 만들었습니다.

 

 

두 언어에 대해 알아보다가 발견한건데 두 언어는 소송전을 했던 적이 있습니다.

Microsoft는 처음에 Java를 자기 방식으로 확장해 쓰려 했고(J++), 그것이 막히자 자체 플랫폼을 만들었습니다.

 

 

1995년 Java 1.0 (Sun Microsystems)이 세상에 나왔고, 1996년 Microsoft가 Java 라이선스를 받아 Visual J++ 출시했습니다. 그다음해인 1997년 Sun Microsystems이 Microsoft를 제소했습니다.(J++에 Windows 전용 확장을 넣어 Java 호환성을 깼다는 이유)

2000년에는 Microsoft가 .NET과 C# 발표했고 다음해인 2001년에 소송 합의하여 Microsoft는 Java 사업에서 손을 떼게 됐습니다.

 

 

문법의 겉모습은 둘 다 C++에서 가져왔습니다. 다만, C#은 문법은 C++에서, 실행 모델은 Java에서 가져온 언어에 가깝습니다.

C#의 설계 책임자 Anders Hejlsberg는 그 전에 Turbo Pascal과 Delphi(델파이)를 만든 사람이어서 속성, 이벤트 같은 Delphi의 영향도 들어 있을 거라고 합니다. 설계자들의 의도를 단정할 수는 없지만, 가상 머신·중간 코드·GC·단일 상속과 인터페이스 같은 큰 구조가 먼저 나온 Java와 같다는 것은 사실입니다.

 

	C, C++	Java, C#
컴파일 결과	기계어	중간 코드 (바이트코드 / IL)
실행	CPU가 직접	가상 머신이 JIT로
메모리	직접 해제 (free, delete)	GC
포인터	자유롭게 사용	기본적으로 숨김

 

 

 

3️⃣헷갈리는 .NET 의 이름 정리

.NET 쪽은 이름이 여러 번 바뀌어 헷갈립니다. 네 개만 구분하면 됩니다.

이름	정체	Java로 치면
.NET	런타임 + 기본 라이브러리 + 도구를 합친 플랫폼. 지금의 정식 이름	Java(언어 이름이자 생태계)
.NET Core	2016년에 새로 만든 크로스 플랫폼 .NET. 5부터 이름에서 Core를 뗌	이름만 바뀐 같은 것
.NET Framework	2002년부터 있던 Windows 전용 원조. 4.8에서 멈춤	구세대 플랫폼
ASP.NET (Core)	.NET 위에서 웹 서버와 API를 만드는 프레임워크	Spring MVC / Boot

 

다만 ASP.NET과 ASP.NET Core는 다른 물건입니다. 전자는 .NET Framework용 구버전이고, 후자는 지금의 .NET 위에서 도는 새 프레임워크입니다.

ASP.NET Core 라고 부르는 이유도, .NET Framework 위에서만 돌던 옛 ASP.NET과 구분해야 하기 위함입니다.

 

지금 ".NET"이라고 하면 아래 줄을 가리킨다. 위 줄은 꼭 ".NET Framework"라고 부른다.

 

4를 건너뛴 이유는 구 플랫폼인 .NET Framework 4.x와 헷갈리지 않게 하려는 것입니다.

.NET5부터는 "Core" 를 떼긴 했지만 Core라는 말은 아직 흔적으로 많이 남아 있습니다. 런타임의 이름이 CoreCLR이고, 덤프에서 본 coreclr.dll, System.Private.CoreLib으로 표시됩니다.

 

 

 

4️⃣SDK의 구조

실행 모델은 Java에서 가져온 언어답게 JDK ⊃ JRE ⊃ JVM의 포함 관계가 .NET SDK ⊃ .NET Runtime ⊃ CLR로 그대로 옮겨집니다.

 

JDK의 구조. Java 11부터 JRE를 따로 배포하지 않지만 개념 구분은 그대로 쓰입니다.

 

 

.NET SDK 10(Windows용)의 구조. 파란 테두리가 서로 대응하는 실행 엔진입니다.

 

위 그림에서 아래 두 런타임은 .NET Runtime과 나란히 그렸지만 독립적이지 않습니다. 둘 다 .NET Runtime이 있어야 돌아갑니다. dotnet 하나가 두 역할을 하는 것은 java가 JRE와 JDK 양쪽에 있는 것과 비슷합니다. 런타임만 설치하면 앱을 실행하는 호스트로만 동작하고, SDK를 설치하면 build, run 같은 명령이 추가됩니다.

 

런타임	내용	필요한 앱
.NET Runtime	CLR + BCL	콘솔 앱, 백그라운드 서비스
ASP.NET Core Runtime	웹 서버와 웹 프레임워크	HTTP 요청을 받는 앱
Windows Desktop Runtime	WPF, Windows Forms. 설치 파일에 .NET Runtime이 함께 들어 있음.	창이 있는 Windows 프로그램

 

 

JDK 와 .NET SDK 에서 다른 곳

항목	JDK	.NET SDK
런타임 묶음	하나	세 개. 기본 런타임 위에 ASP.NET Core와 Windows Desktop이 따로 있음.
UI 라이브러리	기본 라이브러리 안 (Swing, AWT)	별도 런타임 (WPF, Windows Forms)
웹 프레임워크	포함되지 않음 (Spring 등을 따로 받음)	런타임의 한 종류로 포함 (ASP.NET Core)
빌드·패키지 도구	포함되지 않음 (Maven, Gradle)	포함 (MSBuild, NuGet)
진단 도구	포함 (jmap, jstack)	포함되지 않음 (dotnet-dump 등을 따로 설치)
실행 엔진의 인터프리터	있음	없음. 처음부터 JIT

 

 

 

5️⃣메모리 영역차이

JVM 명세는 런타임 데이터 영역을 다섯 개로 정의합니다. 힙, JVM 스택, 메서드 영역, 네이티브 메서드 스택, PC 레지스터입니다. .NET의 명세(ECMA-335)에는 이런 목록이 없어서, .NET 쪽 용어는 CoreCLR 구현과 진단 도구에서 온 것들입니다.

JVM	.NET에서 해당하는 것	비고
힙	관리 힙 (GC heap). 0·1·2세대, LOH, POH	가장 잘 대응된다
JVM 스택	스레드 스택	스레드마다 하나
네이티브 메서드 스택	따로 없음. 같은 스레드 스택을 쓴다	실제 HotSpot도 한 스택에 섞어 쌓는다. 명세상의 구분
메서드 영역	로더 힙 + JIT 코드 힙	타입 정보와 컴파일된 코드가 따로 있다
PC 레지스터	따로 없음. CPU의 명령 포인터를 그대로 쓴다	인터프리터가 없어서 필요하지 않다

 

JVM의 PC 레지스터는 지금 실행 중인 바이트코드의 위치입니다. .NET은 IL을 인터프리터로 돌리지 않고 기계어로 컴파일해 실행하므로 CPU의 명령 포인터 하나로 충분합니다.

.NET에서 참조 타입의 static 필드는 관리 힙의 Object[] 배열에 저장됩니다. gcroot 출력의 "strong handle → Object[]"가 그 배열입니다. HotSpot도 Java 7부터 static 변수를 힙에 둡니다.

 

 

 

.NET에서 메모리 관련 용어와 SOS 명령어

SOS는 디버거에 “.NET 런타임의 내부 구조를 읽는 법”을 가르쳐 주는 확장 모듈입니다. Son of Strike의 약자입니다.

.NET 초기 개발 때 런타임의 코드명이 Lightning이었고, 그것을 디버깅하던 사내 도구 이름이 Strike였습니다. 번개(lightning)가 치는 것(strike)에서 딴 이름입니다. 나중에 외부 공개용으로 줄여서 만든 것이 “Strike의 아들”, SOS입니다.

dumpheap, dumpobj, gcroot, eeheap, clrstack이 전부 SOS가 제공하는 명령입니다.

 

용어	설명	보는 방법
관리 힙 / GC 힙	GC가 관리하는 객체 영역	eeheap -gc
SOH, LOH, POH	관리 힙의 세부 구역 (작은 객체, 큰 객체, 고정 객체)	eeheap -gc
로더 힙	타입 메타데이터	eeheap -loader
코드 힙	JIT된 코드	eeheap -loader
스택	스레드별 호출 스택	clrstack
핸들 테이블	GC 핸들. GC 루트의 한 종류	gchandles
네이티브 / 비관리 메모리	그 밖에 런타임과 네이티브 코드가 직접 잡은 것	WinDbg 도구 사용해서 !address -summary 명령어

 

실무에서는 "관리(managed)냐 비관리(unmanaged)냐"의 두 갈래로 먼저 나눕니다. 메모리가 늘었을 때 GC 힙이 같이 늘었으면 관리 쪽, 아니면 비관리 쪽을 봅니다.

WinDbg는 Windows 덤프 분석의 표준 도구입니다. 다만 Windows에 들어 있는 앱은 아니고 따로 설치해야 합니다. 네이티브 메모리, 크래시, 교착 등을 직접 탐색할 수 있습니다.

 

 

 

6️⃣GC 비교

자바, .NET 둘 다 세대별 GC이고 도달 가능성으로 생사를 판단합니다. 다른 점은 "무엇을 고르게 하는가"입니다. JVM은 알고리즘 자체를 고르고, .NET은 알고리즘은 하나이고 운용 방식을 고릅니다.

 

.NET의 두 모드

.NET의 기본 GC는 Workstation GC이고 Server GC 는 설정을 통해 사용할 수 있습니다. 

	Workstation GC	Server GC
우선시 하는 것	적은 메모리, 짧은 멈춤	처리량 (초당 요청 수)
관리 힙 개수	1개	논리 코어당 1개 (4코어면 4개)
GC를 수행하는 스레드	할당하다 GC를 일으킨 그 스레드 1개	코어마다 전용 GC 스레드. 병렬로 수집
0세대 예산	작다. 자주, 짧게 수집	크다. 드물게, 한꺼번에 수집
메모리 점유	낮다	높다. 힙마다 여유분을 따로 유지
적절한 곳	데스크톱 앱, 메모리가 빠듯한 서버, 한 서버에 프로세스가 여러 개인 경우	서버 한 대를 프로세스 하나가 독차지하는 웹 서버

 

“0세대 예산”은 0세대에 이만큼 할당되면 GC를 돌린다는 기준량입니다.

Server GC는 이 값이 훨씬 크고 힙이 코어 수만큼 있어서, 같은 일을 해도 프로세스가 잡고 있는 메모리가 더 큽니다.

 

 

GC가 객체를 지우는 것과 그 메모리를 OS에 반납(디커밋)하는 것은 별개의 단계입니다. GC는 비게 된 공간을 곧 다시 쓸 것으로 보고 어느 정도 쥐고 있습니다. OS에 돌려줬다가 다시 받는 비용이 크기 때문입니다.

그래서 Server GC 프로세스는 큰 작업을 한 번 치른 뒤 Private Bytes가 한참 높게 유지되는 일이 흔하고, 이것은 누수가 아니라 정상 동작입니다.
이 "쥐고 있는" 성향이 Server GC에서 훨씬 강합니다.

 

Workstation은 그렇게 오래 쥐지 않습니다. 힙이 하나이고 예산이 작아서, 전체 GC 뒤에 비게 된 영역을 비교적 빨리 반납합니다.

 

세대별 GC 중에 2세대 GC에는 두 방식이 있습니다. 백그라운드 GC와 블로킹 GC입니다.

백그라운드 GC 는 전용 스레드가 2세대를 마크하는 동안 애플리케이션은 계속 실행. 짧게 두 번만 멈춥니다.

블로킹 GC 는 처음부터 끝까지 모든 스레드를 세웁니다.

백그라운드 GC(2세대 수집을 앱과 동시에 진행)를 켤지가 별도 설정으로 있고 기본값은 켜짐입니다.

 

구분	백그라운드 GC	블로킹 GC
동작	전용 스레드가 2세대를 마크하는 동안 애플리케이션은 계속 실행. 짧게 두 번만 멈춤	처음부터 끝까지 모든 스레드를 세움
정리 방식	스윕만 함. 압축하지 않음	압축 가능. 빈 영역을 모아 OS에 반납할 수 있음
언제	평상시의 2세대 GC	메모리가 부족할 때, 압축이 필요하다고 판단될 때, 수집 중 할당이 너무 빠를 때

 

 

JVM의 GC와 놓고 보면

JVM	비슷 .NET 설정	공통점
Serial	Workstation, 백그라운드 끔	스레드 하나로 수집. 메모리를 적게 씀
Parallel	Server, 백그라운드 끔	병렬 수집. 처리량 우선
G1 (JDK 9부터 기본)	Server, 백그라운드 켬	병렬 수집 + 마크의 일부를 앱과 동시에
ZGC, Shenandoah	대응하는 것 없음	압축까지 앱과 동시에. 멈춤이 매우 짧음

 

JVM은 CPU가 2개 이상이고 메모리가 약 2GB 이상인 환경에서 G1을, 그보다 작으면 Serial을 고릅니다. .NET이 프로젝트 종류로 기본값을 정하는 것과 달리 하드웨어를 보고 정합니다. 정확히 일치하는 짝은 없고 성격이 가까운 것끼리 놓은 표입니다.

 

가장 큰 차이 - 힙 상한

GC를 비교하면서 제가 가장 놀랐던 부분은 알고리즘이 아니라 힙의 최대 크기를 정해 두느냐였습니다. Java를 하던 습관대로 "힙은 어딘가에서 막히겠지"라고 생각했는데, .NET은 기본으로 막는 곳이 없었습니다.

 

	JVM	.NET
힙 최대 크기의 기본값	물리 메모리의 1/4 (-Xmx로 변경)	상한 없음 (GCHeapHardLimit을 따로 줘야 함)
힙이 계속 커지면	상한에 닿으면 OutOfMemoryError. 그 프로세스만 죽는다	OS가 내줄 수 있는 만큼 커진다. 서버 전체가 메모리 압박을 받는다
멈춤 시간 목표	G1은 기본 200ms 목표를 두고 수집량을 조절	밀리초 단위 목표를 주는 설정은 없음

 

JVM은 따로 옵션을 주지 않아도 물리 메모리의 1/4에서 힙을 멈춥니다. 8GB 서버라면 약 2GB입니다. 거기서 더 필요하면 전체 GC를 반복하다가 OutOfMemoryError를 던지고, 문제가 그 프로세스 안에서 분명한 오류로 드러납니다.

 

 

.NET은 반대입니다. GCHeapHardLimit을 지정하지 않으면 관리 힙에 정해진 상한이 없습니다. 물리 메모리 사용률이 90%에 가까워지면 GC가 압축 GC를 더 적극적으로 돌리긴 하지만, 그래도 계속 살아 있는 객체가 늘어나면 힙도 같이 커집니다. 그래서 문제는 "이 프로세스가 죽었다"가 아니라 "서버 전체가 느리다"는 모습으로 나타나기 쉽습니다.

 

 

한 가지 예외는 컨테이너입니다. 컨테이너처럼 메모리 한도가 걸린 환경에서는 .NET도 그 한도의 75%(또는 20MB 중 큰 값)를 기본 상한으로 잡습니다. 반대로 Windows 서버에 그냥 띄운 프로세스라면 상한이 없는 셈입니다.

상한을 직접 주고 싶다면 runtimeconfig.json에 다음처럼 넣으면 됩니다. 바이트 단위이고, 아래 값은 2GiB입니다.

{
  "runtimeOptions": {
    "configProperties": {
      "System.GC.HeapHardLimit": 2147483648
    }
  }
}

비율로 주고 싶으면 System.GC.HeapHardLimitPercent를 쓰고, 환경 변수로는 DOTNET_GCHeapHardLimit(16진수 값)으로도 줄 수 있습니다.

 

 

 

7️⃣설계가 갈린 곳

지금까지는 닮은 점 위주로 봤다면, 이번엔 같은 뼈대 안에서 서로 다른 선택을 한 지점들입니다. 위에서 따로 다룬 것들도 한 표에 모아 보았습니다.

 

	Java	.NET
값 타입	기본형 8개뿐. 사용자가 직접 정의할 수 없음	struct로 직접 정의. 힙 할당 없이 스택이나 배열 안에 통째로 들어감
제네릭	컴파일 때 타입 정보가 지워짐. List<Integer>는 항상 박싱	런타임까지 타입 유지. List<int>는 박싱 없이 정수를 그대로 저장
실행 방식	인터프리터로 시작해 자주 도는 코드만 JIT	처음부터 JIT (단계별 재컴파일은 있음)
힙 상한	기본으로 있음	기본으로 없음 (컨테이너 제외)
GC 선택	알고리즘 자체를 고름	운용 방식만 고름
런타임 묶음	하나	용도별로 세 개
진단 도구	JDK에 포함	따로 설치
구현체	여러 벤더 (OpenJDK 기반 배포판들)	사실상 Microsoft가 주도하는 것 하나

 

이 중에서 Java 개발자가 가장 낯설게 느낄 부분은 값 타입과 제네릭이라고 생각합니다. 둘은 따로 노는 이야기가 아니라 같이 묶여 있습니다.

Java의 제네릭은 컴파일이 끝나면 타입 정보가 지워집니다(타입 소거, Type Erasure). 런타임에는 List<Integer>나 List<String>이나 똑같이 Object를 담는 리스트일 뿐이라, int를 넣으려면 Integer 객체로 감싸야(박싱) 합니다.

List<Integer> list = new ArrayList<>();
list.add(1);   // int → Integer 객체로 박싱되어 힙에 올라간다

 

 

.NET은 제네릭 타입 정보를 런타임까지 들고 갑니다. 그래서 List<int>는 내부 배열이 int[]이고, 정수를 객체로 감싸지 않고 그대로 저장합니다.

List<int> list = new List<int>();
list.Add(1);   // 박싱 없음. 내부 int[] 배열에 4바이트 정수로 들어간다

즉, 요소가 수백만 개쯤 되면 Java 쪽은 그만큼의 Integer 객체가 힙에 생기고, .NET 쪽은 정수 배열 하나로 끝납니다. 대신 .NET에서도 값 타입을 object나 인터페이스 자리에 넘기면 박싱이 일어나기 때문에 "박싱이 없다"가 아니라 "피할 수 있는 길이 있다"로 이해하시면 됩니다.

 

 

 

 

✨마무리

처음 .NET 을 공부했을 때는 coreclr.dll, 로더 힙, Workstation GC 같은 낯선 이름들 때문에 완전히 다른 세계처럼 느껴졌습니다. 그런데 하나씩 Java에 대응시켜 보니 대부분은 이름만 다를 뿐 이미 알고 있던 개념이었습니다.

처음에 말씀드린 "한 가지 개념을 제대로 이해하면 다른 것도 이해할 수 있다"는 믿음이 이번에도 어느 정도 맞았던 것 같습니다.

정리하면 다음과 같습니다.

1. JDK ⊃ JRE ⊃ JVM 구조는 .NET SDK ⊃ .NET Runtime ⊃ CLR로 거의 그대로 옮겨집니다. 이름만 바꿔 읽어도 큰 그림은 잡힙니다.
2. 메모리 영역은 JVM 명세처럼 정해진 목록이 없어서, 관리 힙·로더 힙·코드 힙 같은 CoreCLR 쪽 이름을 따로 익혀야 합니다.
3. GC는 JVM이 알고리즘을 고르고, .NET은 Workstation/Server와 백그라운드 여부라는 운용 방식을 고릅니다.
4. 가장 조심해야 할 차이는 힙 상한입니다. Java처럼 "어딘가에서 막히겠지"라고 생각하면 .NET에서는 서버 전체가 메모리를 내주게 될 수 있습니다.
5. 값 타입과 제네릭은 닮은 구조 안에서 설계가 가장 크게 갈린 곳이고, 메모리 사용량에 직접 영향을 줍니다.