2025년 8월 09일·7분
C#이 크로스플랫폼이자 실전 백엔드 후보가 된 과정
C#이 Windows 전용에서 리눅스, 컨테이너, 클라우드 백엔드를 위한 크로스플랫폼 언어이자 진지한 서버 사이드 후보가 되기까지의 발전 과정을 알아보세요.
C#이 Windows 전용에서 리눅스, 컨테이너, 클라우드 백엔드를 위한 크로스플랫폼 언어이자 진지한 서버 사이드 후보가 되기까지의 발전 과정을 알아보세요.
C#은 아주 ‘Microsoft-네이티브’한 언어로 시작했습니다. 2000년대 초, .NET Framework와 함께 만들어졌고 Windows 환경(Windows Server, IIS, Active Directory, 그리고 광범한 Microsoft 툴링 스택)에 자연스럽게 어울리도록 설계되었습니다. 많은 팀에게 C#을 선택하는 것은 단지 언어를 고르는 것이 아니라—Windows 우선 운영 모델을 선택하는 것이기도 했습니다.
사람들이 백엔드에서 “크로스플랫폼”이라고 말할 때, 보통 몇 가지 실용적 의미를 염두에 둡니다:
단순히 “실행 가능한가?”가 아니라, Windows가 아닌 환경에서 실행하는 것이 1급(first-class) 경험인지가 중요합니다.
이 글은 C#이 Windows 뿌리에서 다양한 환경에서 신뢰받는 백엔드 옵션으로 자리 잡기까지의 과정을 따라갑니다:
백엔드 스택을 평가 중이라면—C#을 Node.js, Java, Go, Python 등과 비교하고 있다면—이 가이드는 당신을 위한 것입니다. 목표는 C#의 크로스플랫폼 전환 이면의 ‘왜’와 그것이 오늘날 서버 측 결정에 어떤 의미가 있는지를 설명하는 것입니다.
C#은 처음부터 ‘어디서든 실행되는’ 언어로 태어난 것은 아니었습니다. 2000년대 초, C#은 .NET Framework와 밀접히 연관되었고, .NET Framework는 실질적으로 Windows 제품이었습니다. Windows 중심 API를 포함했고, Windows 구성 요소에 의존했으며, Microsoft의 Windows 개발 스택과 함께 발전했습니다.
대부분의 팀에게 ‘C#으로 빌드한다’는 것은 암묵적으로 ‘Windows용으로 빌드한다’는 의미였습니다. 런타임과 라이브러리는 주로 Windows에서 패키지되고 지원되었으며, 가장 많이 쓰이던 기능들은 Windows 기술과 깊이 통합되어 있었습니다.
그렇다고 C#이 나빴던 것은 아닙니다—오히려 예측 가능했습니다. 운영 환경이 정확히 무엇인지 알 수 있었습니다: Windows Server, Microsoft가 지원하는 업데이트, 그리고 표준화된 시스템 기능들.
전형적인 C# 백엔드 모습은 다음과 같았습니다:
웹앱을 운영한다면 배포 실행 절차는 대체로: “Windows Server VM을 프로비저닝하고 IIS를 설치한 뒤 사이트를 배포한다”였습니다.
이 Windows 우선 현실은 분명한 장단점을 만들었습니다.
장점으로는 탁월한 툴링—특히 Visual Studio와 일관된 라이브러리 집합—이 있었습니다. 개발 워크플로는 편안하고 생산적이었으며, 플랫폼은 일관된 느낌을 주었습니다.
단점으로는 호스팅 선택의 제한이 있었습니다. 특히 스타트업이나 비용 민감 조직에서는 리눅스 서버가 주류였고, 웹 호스팅 생태계는 리눅스 기반 스택에 기울어져 있었습니다. 인프라 표준이 리눅스라면 C#을 채택하는 것은 종종 흐름에 역행하거나 하나의 시스템을 지원하기 위해 Windows를 추가해야 하는 일이었습니다.
이 때문에 C#은 ‘Windows 전용’이라는 꼬리표를 달게 되었습니다: 언어 자체의 한계가 아니라, 실무상 프로덕션으로 가는 주류 경로가 Windows를 통해 이루어졌기 때문입니다.
‘크로스플랫폼 .NET’이 공식 우선순위가 되기 전, Mono는 실용적인 우회책이었습니다. 독립적인 오픈소스 구현체로서 개발자가 Linux와 macOS에서 C#과 .NET 스타일 애플리케이션을 실행할 수 있게 했습니다.
Mono의 가장 큰 영향은 간단했습니다: C#이 Windows 서버에 묶일 필요가 없다는 것을 증명했습니다.
서버 측면에서 Mono는 초기 C# 웹앱과 백그라운드 서비스를 Linux에 배포할 수 있게 했고—기존 호스팅 환경이나 비용 제약에 맞추기 위함인 경우가 많았습니다. 또한 웹 백엔드를 넘는 영역에 문을 열었습니다:
Mono가 다리를 놓았다면, Unity는 그 다리로 많은 트래픽을 보냈습니다. Unity는 스크립팅 런타임으로 Mono를 채택했고, 이로 인해 막대한 수의 개발자가 macOS와 여러 타깃 플랫폼에서 C#을 접하게 되었습니다. 비록 그 프로젝트들이 ‘백엔드’ 작업은 아니더라도, C#이 Windows 생태계 밖에서도 존재할 수 있다는 생각을 정상화했습니다.
Mono는 Microsoft의 .NET Framework와 동일하지 않았고, 그 차이는 중요했습니다. API가 다를 수 있었고, 호환성이 보장되지 않았으며, 팀들은 코드를 조정하거나 특정 라이브러리를 피해야 했습니다. 데스크톱/서버, 모바일 프로파일, Unity 런타임 등 여러 ‘플레이버’가 있어 당시 생태계는 오늘날의 통합된 .NET 경험에 비해 분열된 느낌을 주었습니다.
그럼에도 Mono는 기대를 바꾼 개념 증명이었고, 다음 단계가 나오도록 무대를 마련했습니다.
Microsoft의 리눅스 및 오픈소스 쪽으로의 이동은 브랜드 전략이 아니라, 백엔드 소프트웨어가 실제로 어디서 돌아가고 있는지에 대한 현실적 대응이었습니다. 2010년대 중반까지 많은 팀의 기본 대상은 더 이상 “데이터센터의 Windows 서버”가 아니라, 클라우드의 Linux, 종종 컨테이너에 패키징되어 자동으로 배포되는 환경이었습니다.
세 가지 실용적 요인이 변화를 밀어붙였습니다:
이 워크플로를 지원하려면 .NET도 개발자가 있는 곳—리눅스와 클라우드 네이티브 환경—으로 가야 했습니다.
과거에는 백엔드 팀들이 단일 벤더가 통제하는 스택에 베팅하기를 주저했습니다. .NET의 주요 부분을 오픈소스화한 것은 그 문제를 직접적으로 해결했습니다: 구현 세부를 검사하고, 결정 과정을 추적하고, 변경을 제안할 수 있으며, 이슈 토론을 공개적으로 볼 수 있게 되었습니다.
그 투명성은 프로덕션 사용에서 중요했습니다. ‘블랙박스’ 같은 느낌을 줄였고, 리눅스에서 24/7 동작해야 하는 서비스에 .NET 표준화를 더 쉽게 만들었습니다.
개발을 GitHub로 옮기면서 로드맵, 풀 리퀘스트, 디자인 노트, 릴리스 토론이 공개되었고 커뮤니티 기여 진입 장벽이 낮아졌습니다. 서드파티 유지보수자들도 플랫폼 변화에 더 잘 동기화될 수 있게 되었습니다.
그 결과: C#과 .NET은 더 이상 ‘Windows 우선’이라는 느낌을 주지 않았고, 다른 서버 스택과 동등한 대안으로 자리매김했습니다—리눅스 서버, 컨테이너, 모던 클라우드 배포 워크플로에 적합한 스택으로.
.NET Core는 Microsoft가 오래된 .NET Framework를 ‘확장’하려던 시도를 멈추고, 모던 서버 작업을 위해 런타임을 처음부터 재설계한 순간이었습니다. 머신 전체에 설치하는 모델을 전제로 하지 않고 모듈화되고 경량화된, 백엔드 서비스 배포 방식에 친화적인 런타임으로 태어났습니다.
.NET Core로 같은 C# 백엔드 코드베이스가 다음에서 실행될 수 있었습니다:
실무적으로 이는 팀들이 Windows에 표준화를 강제하지 않고도 C#을 표준으로 삼을 수 있게 했습니다.
백엔드 서비스는 배포가 작고 예측 가능하며 빠르게 시작되는 것이 유리합니다. .NET Core는 앱이 필요한 것만 포함하도록 패키징할 수 있는 더 유연한 배포 모델을 도입해 배포 크기를 줄이고 콜드 스타트 동작을 개선했습니다—마이크로서비스와 컨테이너 기반 환경에서 특히 중요합니다.
또 다른 핵심 변화는 단일 공유 시스템 런타임에 의존하는 방식을 벗어난 것입니다. 앱은 자신의 종속성을 함께 가지거나 특정 런타임을 타깃으로 삼을 수 있어 “내 서버에서는 동작하는데” 문제를 줄였습니다.
.NET Core는 서로 다른 런타임 버전을 사이드바이사이드로 설치할 수 있게 했습니다. 이는 조직에서 중요합니다: 한 서비스는 구버전에 머무르고 다른 서비스는 업그레이드하는 식으로 서버 전반에 위험한 변경을 강제하지 않고도 롤아웃과 롤백을 더 수월하게 할 수 있습니다.
ASP.NET Core는 ‘C# 백엔드’가 더 이상 ‘Windows 서버 필요’라는 의미가 아니게 만든 결정적 계기였습니다. 이전의 ASP.NET 스택(.NET Framework 기반)은 IIS와 System.Web 같은 Windows 구성 요소에 강하게 결합되어 있었습니다. 그 세계에서는 잘 작동했지만 리눅스나 경량 컨테이너 안에서 깔끔하게 동작하도록 설계되지는 않았습니다.
ASP.NET Core는 더 작고 모듈화된 영역을 가진 재설계된 웹 프레임워크로, 현대적인 요청 파이프라인을 제공합니다. 무거운 System.Web 모델 대신 명시적 미들웨어와 명확한 호스팅 모델을 사용합니다. 이로 인해 앱을 이해하고 테스트하며 일관되게 배포하기가 쉬워졌습니다.
ASP.NET Core는 Kestrel이라는 빠르고 크로스플랫폼인 웹 서버를 포함해 배송됩니다. 이는 Windows, Linux, macOS에서 동일하게 동작합니다. 프로덕션에서는 보통 Nginx, Apache 같은 리버스 프록시나 클라우드 로드 밸런서를 앞단에 두어 TLS 종료, 라우팅, 엣지 관련 처리를 맡기고 Kestrel이 애플리케이션 트래픽을 처리하게 합니다.
이 호스팅 방식은 리눅스 서버와 컨테이너 오케스트레이션에 자연스럽게 맞아떨어지며, 특별한 ‘Windows 전용’ 설정이 필요하지 않습니다.
ASP.NET Core를 통해 C# 팀은 현대 시스템이 기대하는 백엔드 스타일을 구현할 수 있습니다:
기본으로 제공되는 프로젝트 템플릿, 내장된 의존성 주입, 인증/로깅/라우팅/검증 등 관심사를 분리하도록 권장하는 미들웨어 파이프라인 덕분에 현대적이고 어디서나 배포 가능한 백엔드 프레임워크가 되었습니다.
한동안 ‘.NET’은 혼란스러운 계보를 의미했습니다: 기존 .NET Framework(주로 Windows), .NET Core(크로스플랫폼), 그리고 모바일용 Xamarin/Mono 툴링. 이런 분열은 ‘어떤 런타임을 표준으로 삼을까?’ 같은 단순한 질문에 답하기 어렵게 만들었습니다.
큰 전환은 Microsoft가 .NET Core 브랜드에서 .NET 5부터 시작하는 단일 통합 라인으로 옮기면서 일어났습니다. 목표는 단순한 이름 변경이 아니라 통합: 하나의 런타임 기본, 하나의 베이스 클래스 라이브러리 방향, 서버 앱의 업그레이드 경로를 명확히 하는 것이었습니다.
실무적인 백엔드 관점에서 통합은 의사결정 피로를 줄여줍니다:
여전히 웹, 워커 서비스, 컨테이너 같은 서로 다른 워크로드를 사용할 수는 있지만, 각각에 대해 완전히 다른 ‘종류’의 .NET에 베팅할 필요는 없습니다.
통합 .NET은 LTS(장기 지원) 버전을 통해 릴리스 계획을 더 쉽게 만들었습니다. 백엔드에서는 예측 가능한 업데이트, 긴 지원 기간, 덜 빈번한 강제 업그레이드가 중요하므로 LTS는 큰 의미가 있습니다.
새 프로덕션 서비스라면 안전한 기본값은 최신 LTS를 타깃으로 하는 것입니다. 특수 기능이나 성능 개선이 필요하면 최신 릴리스를 고려하되 조직의 업그레이드 수용력에 맞춰 계획하세요.
C#이 리눅스에서 실행될 수 있게 된 것만으로 진정한 백엔드 대안이 된 것은 아닙니다—런타임과 라이브러리가 실제 서버 워크로드에서 CPU와 메모리를 얼마나 효율적으로 사용하는지도 크게 개선되었습니다. 수년간 런타임과 라이브러리는 ‘충분히 좋다’에서 ‘예측 가능하고 빠르다’ 쪽으로 진화했습니다.
모던 .NET은 초기 런타임보다 훨씬 능력 있는 JIT 컴파일러를 사용합니다. tiered compilation(빠른 스타트업 코드 우선, 이후 핫 패스 최적화) 같은 기능과 프로파일 기반 최적화는 트래픽 안정화 후 서비스가 더 높은 처리량에 도달하도록 돕습니다.
실무적 결과는 보통 부하 하에서 CPU 스파이크가 줄고 요청 처리의 일관성이 좋아진다는 것입니다—비즈니스 로직을 저수준 언어로 다시 쓰지 않고도 얻을 수 있습니다.
가비지 컬렉션도 발전했습니다. 서버 GC 모드, 백그라운드 GC, 큰 할당 처리 향상 등은 긴 ‘stop-the-world’ 일시 중지를 줄여 지속적인 처리량을 개선합니다.
이것이 중요한 이유: GC 동작은 꼬리 지연(가끔 발생하는 느린 요청)에 영향을 주고 인프라 비용(요구되는 인스턴스 수)에 영향을 줍니다. 잦은 일시 중지를 피하는 런타임은 SLO를 맞출 때 더 매끄러운 응답 시간을 제공할 수 있습니다.
C#의 async/await 모델은 웹 요청, DB 호출, 큐 등 네트워크 I/O에 강하게 맞습니다. I/O를 기다리는 동안 스레드를 차단하지 않음으로써 같은 스레드 풀로 더 많은 동시 작업을 처리할 수 있습니다.
단점은 비동기 코드는 규율이 필요하다는 점—잘못 쓰면 오버헤드나 복잡성을 키울 수 있습니다. 그러나 I/O 바운드 경로에 제대로 적용하면 보통 확장성이 좋아지고 트래픽이 변동할 때 지연 시간이 더 안정적입니다.
C#이 ‘IIS를 Windows VM에 설치한다’는 의미에서 벗어나 자연스러운 백엔드 선택이 된 것은 배포 방식이 바뀌었기 때문입니다. 모던 .NET 앱은 보통 다른 서버 워크로드와 동일한 방식으로 패키징·배포·실행됩니다: 리눅스 프로세스로, 종종 컨테이너 안에서, 예측 가능한 구성과 표준 운영 훅을 가집니다.
ASP.NET Core와 모던 .NET 런타임은 머신 전역 설치에 의존하지 않기 때문에 Docker에서 잘 동작합니다. 앱에 필요한 것만 포함한 이미지를 빌드해서 어디서나 실행할 수 있습니다.
일반적인 패턴은 다단계 빌드로 최종 이미지를 작게 유지하는 것입니다:
FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
COPY . .
RUN dotnet publish -c Release -o /app
FROM mcr.microsoft.com/dotnet/aspnet:8.0
WORKDIR /app
COPY --from=build /app .
ENV ASPNETCORE_URLS=http://+:8080
EXPOSE 8080
ENTRYPOINT ["dotnet", "MyApi.dll"]
작은 이미지는 더 빠르게 풀리고 더 빨리 시작되며 공격 표면이 줄어듭니다—스케일 아웃할 때 실용적인 이점입니다.
대부분의 클라우드 플랫폼은 기본적으로 리눅스에서 동작하며 .NET은 그 환경에 편안하게 맞습니다: Azure App Service for Linux, AWS ECS/Fargate, Google Cloud Run 등 많은 관리형 컨테이너 서비스에서 잘 동작합니다.
이는 비용과 일관성 측면에서 중요합니다: 동일한 리눅스 기반 컨테이너 이미지를 개발자 로컬, CI 파이프라인, 프로덕션에서 그대로 실행할 수 있습니다.
쿠버네티스는 자동 확장과 표준화된 운영을 원할 때 흔히 목표가 됩니다. 쿠버네티스에 특화된 코드를 쓸 필요는 없고, 관례를 따르는 것이 중요합니다.
환경 변수로 구성(연결 문자열, 기능 플래그), 단순한 헬스 엔드포인트 노출(레디니스/라이브니스 체크), stdout/stderr로 구조화된 로그 작성 등 기본을 지키면 C# 서비스는 다른 모던 백엔드처럼 포터블하게 배포되고 자동화하기 쉬워집니다.
C#이 Windows, Linux, macOS 전반에서 실용적인 백엔드 선택이 된 큰 이유는 런타임뿐만 아니라 일상적 개발 경험입니다. 툴이 일관되고 자동화에 친화적이면 팀은 환경과 싸우는 대신 기능을 배포하는 데 집중할 수 있습니다.
dotnet CLI로 기기 간 일관된 워크플로dotnet CLI는 프로젝트 생성, 종속성 복원, 테스트 실행, 빌드·퍼블리시 등 일반 작업을 모든 OS에서 동일한 명령으로 수행하게 해줍니다.
이 일관성은 온보딩과 CI/CD에서 중요합니다. 새로운 개발자가 리포를 클론해 빌드 스크립트를 바로 실행할 수 있어 ‘Windows 전용’ 설치 병목을 제거합니다.
C# 개발이 더 이상 단일 도구에 묶여 있지 않습니다:
선택의 이점은 팀이 하나의 환경으로 표준화하거나 개발자 각자가 편한 도구를 사용해도 빌드 프로세스가 분열되지 않는 점입니다.
모던 .NET 툴링은 macOS와 Linux에서도 친숙한 로컬 디버깅을 지원합니다: API를 실행하고 디버거를 연결해 브레이크포인트를 설정하고 변수 조사, 코드 스텝인 등 작업을 할 수 있습니다. 이는 ‘진짜 디버깅’이 Windows에서만 일어났던 병목을 해소합니다.
컨테이너에서 서비스를 실행하면 로컬에서 프로덕션과 동일한 버전의 Postgres/Redis 등을 사용하며 디버깅할 수 있어 로컬 동등성이 향상됩니다.
NuGet은 .NET 팀의 큰 가속기 중 하나입니다. 라이브러리 추가, 버전 잠금, 정기 유지관리 시 종속성 업데이트가 간단합니다.
또한 종속성 관리는 자동화 환경에서 잘 작동합니다: 패키지 복원과 취약점 검사를 빌드 파이프라인의 일부로 만들 수 있어 수동 작업을 줄여줍니다.
생태계는 Microsoft 유지보수 패키지를 넘어 성장했습니다. 로깅, 구성, 백그라운드 작업, API 문서화, 테스트 등 공통 백엔드 니즈에 대해 강력한 커뮤니티 옵션이 있습니다.
템플릿과 스타터 프로젝트는 초기 설정을 빠르게 해주지만 만능은 아닙니다. 좋은 템플릿은 배관 작업을 줄여주되 팀이 아키텍처 결정을 명시적으로 유지할 수 있게 해줍니다.
C#은 더 이상 ‘Windows에만 묶인’ 선택지가 아닙니다. 많은 백엔드 프로젝트에서 강력한 성능, 성숙한 라이브러리, 생산적인 개발자 경험을 결합한 실용적 선택입니다. 다만 가장 단순한 도구가 필요한 경우에는 최선이 아닐 수 있습니다.
C#은 명확한 구조, 장기 유지보수성, 잘 지원되는 플랫폼이 필요한 시스템에서 특히 강합니다:
C#은 때때로 ‘과한’ 선택일 수 있습니다:
C# 선택은 기술뿐 아니라 사람의 문제이기도 합니다: 기존 .NET 기술 보유, 지역 채용 시장, 코드베이스가 얼마나 오래 유지될지 등이 영향을 미칩니다. 장기 제품에서는 .NET 생태계의 일관성이 큰 장점이 될 수 있습니다.
리스크를 줄이는 실용적 방법은 동일한 작은 서비스를 두 스택으로 프로토타이핑해 개발 속도, 배포 마찰, 운영 명확성을 비교하는 것입니다. 예를 들어 일부 팀은 Koder.ai를 사용해 생산형 기본 구조(React 프론트엔드, Go 백엔드, PostgreSQL, 선택적 Flutter 모바일)를 빠르게 생성하고 소스 코드를 내보내어 동등한 ASP.NET Core 구현과 비교해 보기도 합니다. .NET을 최종 선택하더라도 빠른 ‘비교 빌드’는 판단을 구체화하는 데 도움이 됩니다.
C#이 신뢰할 수 있는 크로스플랫폼 백엔드 스토리가 되기까지는 하루아침의 일이 아니었습니다—윈도우 전용 가정을 제거하고 리눅스 배포를 자연스럽게 만든 구체적 이정표들의 누적 결과였습니다.
변화는 단계적으로 일어났습니다:
C#을 백엔드에 평가 중이라면 가장 직접적인 경로는:
기존 .NET Framework 앱에서 온 경우, 현대화는 단계적 접근이 좋습니다: 새 서비스는 API 뒤에 격리하고, 라이브러리를 점진적으로 업그레이드하며, 적절한 곳에서 모던 .NET으로 워크로드를 옮기세요.
빠른 초기 반복이 필요하면 Koder.ai 같은 도구가 채팅으로 동작하는 워킹 앱(백엔드+DB+배포 포함)을 빠르게 띄우고 스냅샷/롤백하며 소스 코드를 내보내 표준 엔지니어링 워크플로로 가져오는 데 도움이 될 수 있습니다.
자세한 가이드와 실용 예제는 /blog 를 참조하세요. 프로덕션 배포를 위한 호스팅이나 지원 옵션을 비교하려면 /pricing 을 확인하세요.
요약: C#은 더 이상 틈새나 Windows에 묶인 선택지가 아닙니다—리눅스 서버, 컨테이너, 클라우드 배포 워크플로에 어울리는 주류 백엔드 옵션입니다.
C# 자체는 범용 언어였지만, 초반에는 .NET Framework와 강하게 결부되어 있었고, 그 프레임워크는 사실상 Windows 우선이었습니다.
대부분의 생산 환경에서의 “C# 백엔드” 배포는 Windows Server + IIS + Windows 통합 API를 전제로 했기 때문에, 실무적으로는 프로덕션 경로가 Windows에 묶여 있었습니다.
백엔드 관점에서 ‘크로스플랫폼’은 보통 다음을 의미합니다:
단순한 ‘실행 가능성’보다, Windows가 아닌 환경에서도 일류(첫손) 경험을 제공하는지가 핵심입니다.
Mono는 C#이 Windows를 벗어나 동작할 수 있음을 증명한 초기 오픈소스 구현체였습니다.
Linux/macOS에서 일부 .NET 스타일 앱을 실행할 수 있게 했고, Unity를 통해 많은 개발자에게 C#이 Windows 외부에서도 쓰일 수 있다는 인식을 심어주었습니다. 대신 호환성의 불완전함과 생태계 분열이라는 대가가 있었습니다.
다음과 같은 이유로 중요했습니다:
또한 오픈소스화로 디자인 토론, 이슈, 수정 내용을 공개적으로 볼 수 있게 되어 신뢰가 높아졌습니다.
주요 차이는 “모던한 크로스플랫폼 서버 배포”를 위해 처음부터 설계되었다는 점입니다.
실무적으로 바뀐 점들:
ASP.NET Core는 기존의 Windows 의존적 웹 스택(System.Web/IIS 가정)을 대신한 모던하고 모듈화된 프레임워크입니다.
일반적으로 다음과 같이 운영됩니다:
이 모델은 리눅스 서버와 컨테이너에 자연스럽게 맞습니다.
“.NET 5부터의 통합 .NET”은 이전의 여러 .NET 계열(.NET Framework, .NET Core, Xamarin/Mono 등)을 단일 라인으로 정리한 것입니다.
백엔드 팀 입장에서는 다음과 같은 이점이 있습니다:
런타임 성능 향상은 여러 레벨에서 이루어졌습니다:
결과적으로 별도 언어로 다시 작성하지 않고도 더 높은 처리량과 안정적인 꼬리 지연(tail latency)을 얻을 수 있습니다.
일반적인 실무 워크플로는 다음과 같습니다:
dotnet publish로 빌드·퍼블리시운영상 포터블하게 하려면:
C#은 다음과 같은 경우에 특히 강점이 있습니다:
반면 적합성이 떨어지는 경우: