C#과 .NET이 저평가되는 이유는 상당 부분 과거의 이미지 때문이라고 느낌. 아직도 .NET을 Windows 전용으로 알거나, .NET Framework 시절 이후 C#을 살펴보지 않았거나, 디버거·핫 리로드 같은 Microsoft의 오픈소스 정책에 반감을 가진 경우가 있음.
하지만 백엔드를 매일 개발하는 입장에서는 정말 훌륭함. Roslyn 분석기, 소스 생성기, 컴파일 언어치고 쓸 만한 핫 리로드, 충실한 공식 문서가 있고 코드베이스 간 편차도 작음. Node 생태계에서 Drizzle, Prisma, TypeORM, Kysely 등을 번갈아 마주치는 것과는 다름.
이전 팀에서 TS를 C#과 F#으로 전환한 뒤 플랫폼 운영이 크게 단순해짐. 도구 체계와 패키지가 안정적이라 설정·도구 유지보수보다 개발에 집중할 수 있었고, 공식 패키지는 보안 업데이트도 꾸준함. JS/TS보다 전이 의존성에 노출되는 정도도 훨씬 작음.
안정성, 강력한 정적 분석, 타입 중심 설계, 좋은 도구 덕분에 AI 코딩 시대의 백엔드 API 개발에 특히 적합하다고 봄. CLI나 서버리스 함수 등 모든 용도에 맞지는 않음. AI가 잘 다룰 수 있는 코드베이스를 만드는 경험도 글로 정리함. https://engineering.usemotion.com/moving-off-of-typescript-e... https://typescript-is-like-csharp.chrlschn.dev/ https://chrlschn.dev/blog/2026/08/the-unexpected-ai-stack-cs...
Microsoft 제품이라는 부담이 큼. 마지막으로 확인했을 때 공식 디버거는 여전히 오픈소스가 아니었고, 그것만으로도 망설일 이유가 됨. TypeScript 컴파일러에 C# 대신 Go를 선택한 일과 Windows 네이티브 GUI 개발 환경도 C#의 평판을 깎아먹음.
언어 자체는 좋음. 최근 객체지향을 싫어하는 흐름은 과도하다고 봄. Rust도 쓰지만, 트레이트가 얕은 상속과 인터페이스 중심 클래스 설계보다 낫다는 확신은 들지 않음.
내게는 초기 설정의 번거로움이 진입 장벽임. IDE가 대신 해주더라도 언어를 가볍게 시험하기 전에 IDE부터 설치하고 싶지는 않음. Go는 go mod init이나 파일 하나로 시작할 수 있고, JavaScript도 간단한 package.json이면 됨. Python·Ruby·Perl·PHP는 파일 하나면 충분함.
내가 알기로 C# 계열은 여전히 프로젝트 파일이 필요하고, 쉽게 복사해 쓸 예제를 담은 튜토리얼도 찾기 어려움. Android 개발에 흥미를 붙이지 못하는 이유도 비슷할 수 있음. 사용하는 Linux 배포판이 도구 체계를 제공하지 않는 점도 걸림돌인데, 내가 이해하기로는 텍스트 파일만으로 부트스트랩할 수 없기 때문임.
C#과 F#은 좋아하지만, 일했던 모든 .NET 회사가 Microsoft 맹신과 대기업식 관행으로 가득했음. 그 문화는 전혀 그립지 않지만 언어는 훌륭함.
C#을 25년간 사용했고, 지금도 Windows든 Linux든 가능하면 .NET을 우선 선택함. 과거 이미지가 발목을 잡는다는 설명은 한동안 타당했지만, 이제는 .NET Core만 알고 Framework 시절과 같은 연상을 하지 않는 새로운 개발자 세대가 있음.
약 15년 전 대학생 인턴 시절 C#에 반해 졸업 프로젝트에도 쓰고, 이를 전문으로 경력을 쌓아옴. Microsoft에 종속되지 않는 범용 언어로 발전해 어디서나 실행하고 다양한 일을 할 수 있게 된 과정이 즐거웠고, 매년 더 좋아지고 있음.
C#은 VB6 다음으로 배운 두 번째 언어임. 어린 시절 무료라는 이유로 VB .NET을 받았다가 기존 VB6 프로젝트가 실행되지 않아 실망했고, 2007~2009년경 C#을 접한 뒤 큰 전환점을 맞음.
대학 졸업 후 첫 직장은 C# 업무 예정이었지만 프로젝트 승인이 나지 않아 Python과 JavaScript부터 접함. Python은 좋았고 JavaScript는 지금도 애증의 대상임. 나중에 C#을 쓰게 됐을 때는 .NET 3.5가 아니라 초기 .NET Core였는데, 상당히 고생함.
.NET으로 멋진 프로젝트를 많이 만들었지만, Microsoft가 Linux까지 지원하며 오래 유지할 크로스플랫폼 GUI 체계를 만들어주길 바람. 대안이 있어도 동료들에게 “그냥 기본 제공 기능을 쓰자”고 할 수 있는 편리함은 대체하기 어려움.
Microsoft가 차세대 기술이라고 내세운 것들을 철회하면서 세 번째 대규모 제품 재작성을 해야 할 상황이 되자, 수년 전 .NET을 떠남. AppFabric, WWF, WCF, Silverlight 때문에 큰 타격을 받아 다시 믿기 어려움.
실현되기 어려운 소원일지 몰라도, WPF만 크로스플랫폼으로 만들어줘도 더없이 기쁠 것 같음.
가격·청구·환율처럼 소수점이 중요한 일을 많이 하는 입장에서는 상당히 위험한 함정이라 긴장됨.
(decimal)0.1f도 결과가 0.100000001490116119384765625가 됨.
Microsoft에서 일했는데, Office·Security·Azure의 대규모 웹 서비스 중 일부가 Windows와 Linux에서 .NET Core로 수백만 대의 VM과 서버에 걸쳐 운영됨. 도구가 훌륭하고 확장성도 좋으며, .NET Framework와는 전혀 다름. 자사 서비스가 .NET에 의존하므로 외부 채택과 발전을 촉진하는 것이 Microsoft에도 이익임.
지금 다니는 미국의 성숙한 급여 처리 기업도 .NET Core를 폭넓게 사용하며 개발이 수월함. 다만 Rider나 Visual Studio 같은 유료 IDE는 여전히 필요하다고 느낌. VS Code의 개발 경험은 그만큼 성숙하지 않음.
서버를 개별 관리 대상이 아닌 교체 가능한 자원으로 취급하는 “가축이지 반려동물이 아니다” 접근법에서는 적절한 DevOps·SRE와 시스템 설계만 있으면 Java, Node, Python, Go, Rust, PHP로도 이런 규모를 달성할 수 있음. 다만 효율이 낮아 비용이 더 드는 언어는 있을 수 있음.
C#은 늘 좋아했지만 Linux의 IDE 환경 때문에 더 많이 쓰지 못함. VS Code를 잘 구성하려고 해봤지만 충분하지 않았고, C# 작업에는 Rider를 쓰면서도 정확히 무엇 때문인지 모르게 만족스럽지 않음.
런타임의 비동기 지원이 놀라움. 코드에 상태 머신이 없으면 스택 추적이 읽기 쉬워진다는 점은 이해하지만, 런타임 구현으로 바꾸면서 기존과 동등한 성능까지 낼 수 있을 줄은 몰랐음.
Erlang·Go·Java와 비슷한 방식으로 async·await를 구현하는 실험에서 배운 것을 바탕으로 만든 기능임.
읽기 쉬운 스택 추적에는 성능상 이점도 있음. 취소 처리는 예외를 던지는 방식인데 전체 스택 추적을 문자열로 저장하는 일을 막을 수 없어, 스택이 깊고 복잡하면 눈에 띄게 멈칫할 수 있음. 이번 변화로 그 현상도 해소되길 바람.
.NET 5 이후 CLR의 빠른 개선 주기가 가져온 성과로 보임. .NET 4 이하에서는 하나의 런타임이 여러 버전의 컴파일러와 기본 클래스 라이브러리를 지원해야 해 호환성 제약이 컸음. CLR 1.0에서 2.0으로 넘어가며 제네릭 등을 도입한 뒤에는, 특히 컴파일러에서 처리할 수 있는 기능을 런타임에 추가하는 데 소극적이었던 것 같음.
이제는 CLR과 컴파일러가 함께 갱신되고 대부분의 배포 방식에서 애플리케이션에 CLR 버전을 함께 묶는다고 가정하므로, 이전만큼 향후 버전과의 호환성을 보장하지 않음. 최근에도 작은 개선이 있었지만 이번 변화는 런타임 발전이 과거보다 빨라지고 흥미로워졌다는 뚜렷한 증거임.
실용적인 판단으로 모든 앱을 .NET MAUI로 전환했고 만족스럽게 사용 중임. 기존 네이티브 모바일 앱을 기반으로 Windows 버전을 추가 출시한 뒤, 기능이 완성되자 모바일 앱도 MAUI 버전으로 교체함.
디버깅 기간은 놀랄 만큼 짧았고 품질도 네이티브와 동등함. Apple이 Swift를 Android에 개방하려 하지 않은 점이 아쉬움. 지금의 MAUI가 바로 Swift가 되었어야 할 모습이라고 느낌.
C#과 .NET으로 개발하는 일은 정말 즐거움. 약간 더 기업용 개발 색채가 강한 Ruby on Rails 같지만, 익숙해지면 자연스럽게 작업이 이어짐. 특히 LINQ 덕분에 구성 요소가 잘 맞물리고, Roslyn Compiler Services 등을 통한 런타임 코드 컴파일과 스크립팅도 훌륭함.
요즘 C# 개발에는 어떤 IDE를 쓰는지 궁금함. 2008년 무렵에는 사실상 Visual Studio뿐이었는데, 지금 Linux에서 C#을 다시 시작한다면 무엇을 써야 할까?
내게는 여전히 Visual Studio가 유일한 실질적 선택지처럼 느껴지며, 이를 쓰기 위해 Windows로 옮기는 것도 고려할 만함. 기술적으로 가능하다는 것과 실용적이거나 즐겁다는 것은 큰 차이가 있음.
주니어 개발자들이 ORM을 쓰지 않고 스키마를 수동 관리하는 위험성을 계속 따지다가, Visual Studio의 sqlproj와 SQL 비교 기능을 보고는 달라짐. 다른 IDE에서도 외부 도구와 직접 만든 기능을 엮을 수 있지만, 실제 과제에 쏟을 시간과 에너지가 줄어듦. 도구 체계를 유지하기 위한 도구 체계를 또 관리하고 싶지 않으며, 비용을 더 내더라도 도구만큼은 믿고 쓸 수 있게 하고 싶음.
예전에는 Rider를 썼지만 이제는 느리고 불편하며 버그도 너무 많음. 코드 수정과 리팩터링이 장점이었으나, 지금은 Linux에서 AI 작업 환경을 IDE로 삼고 필요할 때 vim을 사용함. Rider는 8~9개월 동안 열지 않았고 구독 갱신도 중단함.
.NET은 명령줄에서 쓰기 쉬워 원하는 환경을 구성할 수 있음. IDE가 꼭 필요하다면 Rider를 고려할 수 있고 비상업용 무료 버전도 있는 것으로 알지만, IDE의 시대가 저물고 있다는 느낌이 듦.
Mac으로 옮긴 뒤 Rider를 잠시 쓰다가 지금은 VS Code만으로 만족스럽게 작업함. 에이전트 이전이라면 Rider 학습에 더 투자했겠지만, 이제는 수동 리팩터링용 고급 도구가 그만큼 필요하지 않음. 직접 코드를 많이 다룬다면 Rider는 훌륭하며 Visual Studio보다 나을 수도 있는 대안임.
VS Code도 대체로 충분하고, 라이선스 비용을 낼 의향이 있다면 JetBrains Rider가 전반적으로 더 나음.
.NET 11은 2년 지원하는 STS 릴리스이며, LTS와 품질·유지보수 정책은 같고 지원 기간만 다름. 그런데 핵심이 묻혀 있음. .NET 10의 지원 종료일은 2028년 11월 14일, .NET 11은 2028년 11월 9일이라, 11로 올려도 남은 지원 기간은 오히려 짧아짐.
의도는 .NET 12가 정식 출시되면 곧바로 올리라는 것이겠지만, 내 고객 중에는 2.1에서 움직이지 않거나 그 재출시 버전인 2.3으로도 올리지 않는 곳이 있음.