C#있는데 왜 Golang씀?

Summary C# 대신 Go를 선택하는 이유는 운영 비용 절감, 경량 동시성, 간단한 빌드 및 배포, 클라우드-네이티브 생태계에서의 표준 언어로서의 위치, 그리고 협업 비용 감소 때문이다. Go는 Docker, Kubernetes, Terraform 등 주요 도구와의 호환성 덕분에 인프라 및 시스템 엔지니어들에게 선호된다. 반면 C#은 비동기 처리에서 강력하지만, 복잡한 설정과 큰 이미지 용량으로 인해 마이크로서비스 및 CLI 도구에서는 Go가 더 유리하다.

왜 C#대신에 Go를 쓰는가? 인프라엔지니어나 시스템엔지니어나 클라우드엔지니어들이! C#도 코루틴이 있고, 심지어 C#의 async/await 쓰면 도중에 반환도 가능한데?

→ 요약하자면 “엔지니어들은 코드보다 운영 비용을 줄이는 언어를 택한다”—바로 그 이유가 Go다.

한마디로 정리하면, Go는 ‘가볍고, 단순하며, 배포가 쉬운 언어’라는 점 덕분에 Docker·Kubernetes·Terraform 같은 핵심 클라우드-네이티브 도구들의 사실상 표준 언어가 되었고, 그래서 인프라·시스템·클라우드 엔지니어들이 C# 대신 Go를 우선 선택한다. goroutine은 8KB 스택으로 OS 스레드와 M:N으로 매핑되어 수십만 개를 띄워도 부담이 적다. 또한 정적으로 묶인 단일 실행 파일은 이미지 용량을 수 MB까지 줄여 컨테이너 배포·업그레이드를 단순화한다. 반면 C#은 강력한 async/await를 제공하지만, 런타임·라이브러리·컨테이너 이미지까지 함께 실어 나르므로 기본 용량이 수백 MB에 달한다. 게다가 “async all the way” 패턴으로 인해 코드·학습·디버깅 난이도가 올라간다는 점이 실무에서 자주 문제로 언급된다.

기 – 왜 이 이야기가 나오나

C#은 async/await와 코루틴(Task)으로 비동기를 잘 처리하고, .NET ThreadPool이 자동으로 워커 스레드를 조절한다 .
그런데 DevOps 세계에서 주력 도구(예: Docker Engine, Compose v2, Kubernetes, Terraform 등)는 모두 Go로 작성돼 있다 .
“내가 쓰는 툴이 Go인데, 그 툴용 플러그인·컨트롤러·Operator를 C#으로 짜려면?”—자연히 빌드·배포·디버깅이 한 번 더 꼬인다.

승 – Go가 선택되는 다섯 가지 근거

1) 경량 동시성: goroutine + 채널

goroutine은 런타임이 직접 스케줄링하는 초경량 스레드다(8 KB 스택, M:N 모델) .
벤치마크 비교에서 동일 작업을 돌렸을 때 Go가 C# Task-based 코드보다 2–3배 빠르거나 메모리를 덜 쓰는 경우가 흔히 보고된다 .
idle 시 메모리도 Go < C# 순으로 나타난다 . 2) 빌드·배포 단순화: 한 파일이면 끝
go build만 하면 외부 의존성이 없는 정적 바이너리가 나온다 .
멀티스테이지 Dockerfile로 scratch 이미지를 쓰면 API 서버 하나가 6 MB 이미지로 줄어든 사례가 있다 .
동일한 Hello-world급 프로젝트를 .NET SDK/ASP.NET 기본 이미지로 빌드하면 80 ~ 224 MB대가 흔하다 . 3) 개발 흐름을 끊지 않는 툴체인
go fmt/go vet/go test가 표준화돼 PR 리뷰 때 코드 스타일 논쟁이 사라지고 CI 스텝이 짧다 .
컴파일 속도 역시 “Go » C#/Java”라고 비교 표에서 강조된다 . 4) 클라우드-네이티브 생태계의 ‘공용어’

프로젝트	언어 근거
Docker Engine & Compose v2	“Docker는 Go로 작성됐다” 공식 문서
Kubernetes & kubectl	client-go 라이브러리가 공식이며, Go 업그레이드 정책까지 블로그에 명시
Terraform	Core/플러그인·Provider 모두 Go로 작성·지원 (SDK도 Go 전용)

Go를 쓰면 “네이티브 SDK + 샘플 코드 + 커뮤니티 블로그”가 모두 같은 언어라 학습 자산을 바로 재활용할 수 있다.

5) 언어 규모와 협업 비용

Go 스펙은 전체가 한 문서 ~ 한 시간 이내면 읽을 수 있을 정도로 작다 .
C#은 제네릭·LINQ·nullable·async/await·Span·Source Generator 등 최신 기능을 익히려면 러닝커브가 길어지고, “async all the way” 때문에 함수 서명이 전파되는 점이 실제 프로젝트에서 부담으로 작용한다 .

전 – 그렇다고 C#이 나쁜가?

.NET 8부터 AOT + /p:PublishTrimmed=true를 쓰면 3 MB짜리 scratch 이미지도 가능하다지만 설정이 훨씬 복잡하다 .
비동기식 I/O·JIT·GC 최적화 덕분에 CPU 성능은 Go와 비슷하거나 우위인 벤치마크도 있다 .
Windows GUI·WPF·Blazor처럼 Go에 없는 영역은 당연히 .NET 진영이 강하다. 그러나 인프라용 마이크로서비스·CLI·운영 툴에서는

런타임 없는 단일 바이너리,
컨테이너 이미지 최소화,
Go 생태계 도구와 직접 연동,
간단한 언어 스펙으로 빠른 리뷰/온보딩 …이 더 큰 가치를 만든다.

결 – “도구를 따라가면 언어가 보인다”

내가 배포·운영해야 할 Docker/K8s/Terraform 모듈이 전부 Go로 짜여 있다면, 같은 언어로 확장 코드를 쓰는 편이 유지보수·CI/CD 흐름·팀 러닝커브 모두 유리하다.
C#은 데스크톱·웹·비즈니스 로직에서 여전히 강력하지만, 클라우드-네이티브 인프라의 ‘작고, 빠르고, 단순한’ 요구를 만족시키기 위해 Go가 더 자주 선택된다는 것이 현장의 실감이다.
요약하자면 “엔지니어들은 코드보다 운영 비용을 줄이는 언어를 택한다”—바로 그 이유가 Go다.

#Go