C#이 드디어 메모리 안전성에 진심을 보이기 시작했어요

왜 갑자기 메모리 안전성 이야기가 나왔을까요

요즘 프로그래밍 언어 업계에서 가장 뜨거운 화두 중 하나가 바로 메모리 안전성(memory safety) 이에요. 메모리 안전성이라는 게 뭐냐면, 프로그램이 자기가 쓸 수 있는 메모리 영역만 정확하게 쓰고, 엉뚱한 곳을 건드리거나 이미 해제된 메모리를 다시 사용하지 않도록 보장하는 성질이거든요. 이게 안 되면 어떤 일이 벌어지냐면, 그 유명한 버퍼 오버플로우, use-after-free 같은 보안 취약점이 줄줄이 터집니다. 마이크로소프트와 구글이 자기들 코드베이스의 보안 버그를 분석해봤더니, 70% 정도가 메모리 안전성 문제에서 나왔다는 통계가 있을 정도예요.

그래서 미국 백악관까지 나서서 "개발자들아, 제발 메모리 안전 언어 좀 써라"라고 권고문을 냈고, Rust가 갑자기 떠오른 것도 이런 배경 때문이에요. 그런데 흥미로운 건, C#도 이 흐름에 본격적으로 합류하고 있다는 거예요. 마이크로소프트가 .NET 블로그에 올린 글에서 C#을 어떻게 더 안전한 언어로 만들고 있는지 로드맵을 공개했거든요.

C#은 원래 안전한 언어 아니었나요?

맞아요. C#은 가비지 컬렉터(GC)가 메모리를 알아서 정리해주는 매니지드 언어라서, C나 C++처럼 직접 메모리를 할당하고 해제하다가 사고 나는 일이 거의 없어요. 그런데 문제는 C#이 단순한 웹 백엔드 언어를 넘어서 게임 엔진(Unity), 고성능 서버, 심지어 OS 커널 수준 코드까지 쓰이고 있다는 거예요. 그러다 보니 성능을 위해 unsafe 키워드를 쓰거나, Span<T>, ref 같은 저수준 기능을 활용하는 경우가 많아졌어요.

여기서 미묘한 구멍들이 생깁니다. 예를 들어 ref struct라는 게 있는데, 이건 스택에만 살아야 하는 특수한 구조체예요. 그런데 잘못 쓰면 이미 사라진 스택 메모리를 가리키는 dangling reference가 만들어질 수 있어요. 또 Span<T>로 배열의 일부를 참조하고 있는데 그 배열이 GC에 의해 정리되면? 이런 식의 미묘한 안전성 문제가 여전히 남아 있었거든요.

컴파일러 차원에서 막아준다는 게 핵심

이번 발표의 핵심은 런타임이 아니라 컴파일 시점에 잡아낸다는 거예요. 컴파일러가 코드를 분석해서 "이거 위험한데?" 싶으면 빌드를 막아버리는 방식이죠. Rust가 borrow checker로 하는 것과 비슷한 접근이에요.

구체적으로는 escape analysis를 더 정교하게 만들고 있어요. 이게 뭐냐면, 어떤 값이 자기가 살아야 할 범위(scope) 밖으로 새어 나가는지 컴파일러가 추적하는 거예요. 예를 들어 함수 안에서 만든 지역 변수의 주소를 함수 밖으로 반환하려고 하면 "안 돼!" 하고 막아주는 거죠. 또 [UnscopedRef] 같은 어트리뷰트로 개발자가 의도를 명시할 수 있게 하고, 잘못 쓰면 경고를 띄워줍니다.

그리고 allows ref struct 같은 제네릭 제약도 추가됐어요. 예전엔 ref struct를 제네릭 타입 파라미터로 쓸 수 없었는데, 이제는 "이 제네릭은 ref struct도 받을 수 있어"라고 명시할 수 있게 된 거예요. LINQ 같은 라이브러리가 Span<T>를 자연스럽게 처리할 수 있게 되는 거죠.

Rust, Swift와 비교해보면

메모리 안전성을 컴파일 타임에 보장하는 언어 중 가장 유명한 건 단연 Rust예요. Rust는 ownership과 borrowing이라는 강력한 시스템으로 GC 없이도 안전성을 보장하죠. 대신 학습 곡선이 가파르고, 코드를 쓸 때마다 컴파일러랑 싸워야 한다는 농담이 있을 정도예요.

Swift도 ARC(자동 참조 카운팅)에 더해 최근에 Rust 스타일의 ownership 모델을 도입하고 있어요. Go는 GC에 전적으로 의존하는 대신 단순함을 택했고요. C#의 접근은 이 중간 어디쯤이에요. 기본은 GC에 맡기되, 성능이 중요한 부분에서는 Rust 같은 정교한 검사를 컴파일러가 해준다는 절충안이죠. 기존 C# 개발자들이 익숙한 문법을 그대로 쓰면서 점진적으로 더 안전한 코드를 쓸 수 있다는 게 강점이에요.

한국 개발자가 알아두면 좋은 점

국내에서도 C#은 게임 업계(Unity)와 엔터프라이즈 백엔드에서 꾸준히 쓰이고 있잖아요. 특히 Unity로 모바일 게임 만드는 분들은 GC 멈춤(GC pause) 때문에 골치 아픈 경우가 많은데, Span<T>나 stackalloc 같은 zero-allocation 기법을 쓰면서도 안전하게 짤 수 있다면 큰 도움이 됩니다.

또 .NET 8, 9에서 AOT(Ahead-of-Time) 컴파일이 본격화되면서 C#이 시스템 프로그래밍 영역으로도 발을 넓히고 있거든요. 이런 영역에선 메모리 안전성이 곧 보안과 직결되니까, 새 기능들을 익혀두면 분명히 쓸 곳이 생길 거예요. 당장은 라이브러리 작성자나 성능 민감한 코드를 다루는 분들에게 가장 직접적인 영향이 있을 것 같고, 일반 비즈니스 로직 짜는 분들은 "아 그런 게 있구나" 정도로 알아두시면 충분합니다.

마무리

C#이 "편한 매니지드 언어"에서 "편하면서도 시스템 프로그래밍까지 가능한 안전한 언어"로 진화하고 있다는 게 이번 발표의 핵심이에요. GC의 편리함을 유지하면서 컴파일러 차원의 정적 분석으로 안전성까지 잡으려는 시도죠.

여러분은 어떻게 생각하세요? 메모리 안전성을 위해 Rust처럼 새 언어를 배우는 게 나을까요, 아니면 C#이나 Swift처럼 기존 언어가 점진적으로 안전해지는 흐름을 따라가는 게 나을까요?