C# 역사 — 자바 짝퉁이 살아남기까지 20년

 

C#의 역사를 이야기할 때 늘 따라붙는 수식어가 '자바 짝퉁'입니다. 2000년 마이크로소프트가 C#을 처음 내놨을 때, 이미 시장을 잡고 있던 자바(Java)를 문법까지 베꼈다는 비판이 쏟아졌거든요. 저는 자바 진영에서 밥벌이를 해온 개발자라 이 언어를 늘 건너편에서 지켜봤습니다. 그런데 20년이 지난 지금 돌아보면, 그 짝퉁 소리를 듣던 언어가 오히려 자바가 부러워할 기능을 먼저 내놓곤 했습니다.

 

 

"C#? 그거 자바 베낀 거 아냐?"
"MS 언어라 어차피 윈도우에서만 돌아가잖아."
"요즘 C#이 그렇게 좋아졌다던데, 진짜 그래?"

 

 

제가 처음 일을 시작한 2012년만 해도 자바 개발자와 .NET 개발자는 물과 기름처럼 나뉘어 있었습니다. SI 현장에 가면 자바팀과 .NET팀이 아예 다른 언어를 쓰는 다른 부족 같았죠. 자바 쪽에 있던 저에게 C#은 '마이크로소프트가 자기네 윈도우 팔아먹으려고 만든 폐쇄적인 언어' 정도의 이미지였습니다. 솔직히 그때는 별로 궁금하지도 않았어요.

그 인식이 바뀐 건 나중 일입니다. 이 글에서는 C#이 왜 '자바 짝퉁'이라는 꼬리표를 달게 됐는지, 그 꼬리표가 정말 맞았는지, 그리고 어쩌다 지금처럼 리눅스와 클라우드에서까지 돌아가는 언어가 됐는지를 자바 개발자의 눈으로 따라가 봅니다. C#을 써본 적 없어도, 언어 하나가 20년 동안 어떻게 변하는지 보는 재미가 있을 겁니다.

목차

1. '자바 짝퉁' 소리를 들은 이유 — J++ 소송과 COOL 프로젝트
2. 델파이의 아버지, 앤더스 헤일즈버그
3. 초기 C#은 정말 자바 클론이었을까
4. LINQ, 자바 개발자를 부럽게 만든 기능
5. async와 await, 비동기를 순차 코드처럼 쓰다
6. 대반전, .NET Core로 윈도우 밖에 나오다
7. 자바와 C#, 지금은 어떻게 다른가
8. 2026년의 C#은 어디까지 왔나

1. '자바 짝퉁' 소리를 들은 이유 — J++ 소송과 COOL 프로젝트

C#이 짝퉁 취급을 받은 데는 그럴 만한 사연이 있습니다. 1990년대 후반, 썬 마이크로시스템즈(Sun Microsystems)의 자바는 'Write Once, Run Anywhere'를 앞세워 무섭게 퍼지고 있었습니다. 어떤 운영체제든 자바 가상 머신만 있으면 같은 코드가 돌아간다는 개념은, 윈도우로 세상을 지배하던 마이크로소프트 입장에선 달갑지 않았죠. 자기네 운영체제에 종속되지 않는 언어가 커진다는 건 곧 윈도우의 힘이 빠진다는 뜻이니까요.

1-1. J++와 썬의 소송

마이크로소프트가 처음 택한 방법은 정공법이 아니었습니다. 자바를 가져와 윈도우에 특화된 형태로 손본 J++를 내놓은 거죠. J++는 윈도우 API에 직접 손을 뻗을 수 있어서 실무 개발자들에게는 편했지만, 썬 입장에선 자바의 '어디서나 똑같이 돈다'는 약속을 깨는 행위였습니다. 결국 썬은 자바 라이선스 계약 위반이라며 소송을 걸었고, 긴 공방 끝에 마이크로소프트는 더 이상 자기 멋대로 자바를 확장할 수 없게 됐습니다.

벼랑 끝에 몰린 마이크로소프트가 내린 결론은 '그럼 우리 언어를 새로 만들자'였습니다. 자바를 대체하되 윈도우 환경에 딱 맞는 언어를요. 1999년 1월에 시작된 이 프로젝트의 코드명이 바로 COOL이었습니다. 'C-like Object Oriented Language'의 줄임말이었죠. 실제로 마이크로소프트는 이 이름을 그대로 쓰고 싶어 했는데, 상표 문제에 걸려 포기했다고 합니다. 2000년 7월 개발자 콘퍼런스(PDC)에서 .NET과 함께 공개될 때는 이미 C#이라는 이름으로 바뀌어 있었고요.

 

 

💡 이름에 담긴 뜻

C#의 '#'은 음악의 샤프 기호에서 왔습니다.

반음 올린다는 뜻이죠. C++보다 한 단계 더 나아간 C라는 의미이기도 하고,

샤프 기호가 '+' 네 개를 붙여놓은 모양이라 C++++로 읽히기도 합니다.

이름 하나에도 '우리가 C 계열의 후계자'라는 주장을 담아둔 셈입니다.

 

2. 델파이의 아버지, 앤더스 헤일즈버그

새 언어를 맡길 사람으로 마이크로소프트가 데려온 인물이 앤더스 헤일즈버그(Anders Hejlsberg)입니다. 개발자라면 한 번쯤 들어봤을 이름이죠. 그는 볼랜드(Borland)에서 터보 파스칼(Turbo Pascal)과 델파이(Delphi)를 만든 사람입니다. 1980년대에 49.95달러라는 파격적인 가격으로 터보 파스칼을 내놓아 화면 전체를 쓰는 통합 개발 환경을 대중화한 장본인이기도 하고요.

그는 1996년 볼랜드를 떠나 마이크로소프트로 옮겼고, 처음에는 앞서 얘기한 J++ 개발을 맡았습니다. 그런데 소송으로 J++가 좌초되자, 그 경험을 그대로 새 언어 프로젝트에 쏟아붓게 됐죠. 자바를 윈도우용으로 다듬어본 사람이 자바를 대체할 언어의 설계를 맡았으니, 어떻게 보면 C#이 자바를 닮은 건 당연한 일이었습니다.

헤일즈버그의 철학은 분명했습니다. 학문적으로 정교한 언어보다, 개발자가 실제로 제품을 빨리 만들 수 있는 실용적인 언어를 만들자는 거였죠. C++의 복잡한 메모리 관리는 걷어내고, 자바처럼 가상 머신 위에서 돌게 하되, 컴포넌트를 조립하듯 개발하기 쉽게 만들었습니다. 델파이에서 검증했던 프로퍼티(Property), 이벤트(Event), 델리게이트(Delegate) 같은 개념이 C#에 그대로 녹아든 것도 이 때문입니다. 저는 개인적으로 C#이 초기부터 생산성이 좋았던 건 언어 자체보다 이 사람의 실전 감각 덕이 컸다고 봅니다.

 

 

📌 한 사람이 만든 언어 계보

터보 파스칼, 델파이, J++, C#,

그리고 나중에 자바스크립트를 다듬은 타입스크립트(TypeScript)까지.

우리가 지금 쓰는 언어와 도구 상당수에 헤일즈버그의 손이 닿아 있습니다.

언어의 역사를 사람으로 따라가 보면 의외로 좁습니다.

 

3. 초기 C#은 정말 자바 클론이었을까

솔직히 초기 버전만 놓고 보면 짝퉁이라는 비판이 아주 틀린 말은 아니었습니다. 자바를 만든 제임스 고슬링(James Gosling)은 C#을 대놓고 흉내라고 불렀고, 자바의 신뢰성과 생산성, 보안을 빼버린 자바 같은 것이라고 깎아내렸습니다. 문법이 워낙 비슷했으니 자바 진영에서 나올 만한 반응이었죠.

헤일즈버그 쪽 반박은 달랐습니다. C#은 자바 클론이 아니라 오히려 C++에 더 가깝다는 거였죠. 그리고 이 논쟁은 시간이 지나면서 자연스럽게 정리됩니다. 2005년 11월 C# 2.0에서 두 언어가 갈라지기 시작했거든요. 이때 제네릭(Generics)이 들어왔는데, 자바도 비슷한 시기에 제네릭을 넣었지만 구현 방식이 완전히 달랐습니다.

자바 제네릭은 컴파일할 때 타입 정보를 지워버리는 방식이라 런타임에는 타입을 알 수 없습니다. 자바를 좀 만져본 분이라면 '타입 소거(type erasure)' 때문에 골탕 먹은 기억이 있을 거예요. 반면 C#은 런타임에도 타입 정보가 살아 있는 방식을 택했습니다. 겉보기엔 비슷한 기능인데 속을 열어보면 완전히 다른 선택을 한 거죠. 이 지점부터 저는 C#을 그냥 짝퉁으로만 보기 어렵겠다고 생각했습니다.

4. LINQ, 자바 개발자를 부럽게 만든 기능

C#이 자바를 확실히 앞서간 순간을 꼽으라면 저는 주저 없이 LINQ를 듭니다. 2007년 C# 3.0에 들어온 기능인데, 정식 명칭은 Language Integrated Query, 그러니까 '언어에 통합된 쿼리'입니다. 이게 왜 부러웠는지는 그 전에 우리가 어떻게 코딩했는지를 보면 이해가 됩니다.

LINQ 이전에는 데이터를 다루는 방식이 제각각이었습니다. 데이터베이스는 SQL로, XML은 또 다른 문법으로, 메모리 안의 객체는 for문과 foreach문을 돌려가며 처리했죠. 같은 '걸러내고 정렬한다'는 작업인데 대상이 뭐냐에 따라 코드가 전부 달랐습니다. LINQ는 이걸 하나의 문법으로 묶었습니다. SQL을 아는 사람이라면 from, where, select 같은 구문으로 메모리 안 객체까지 다룰 수 있게 된 거죠.

여기에 람다 표현식과 확장 메서드가 함께 들어오면서, 복잡한 반복문 없이도 '무엇을 원하는지'만 적으면 되는 방식으로 바뀌었습니다. 문제는 자바였습니다. 자바가 람다와 스트림(Stream)을 손에 넣은 건 2014년 자바 8에 와서였거든요. C#보다 7년이 늦었습니다. 그 7년 동안 자바 개발자들은 익명 클래스로 지저분한 코드를 짜면서 C# 쪽을 곁눈질했습니다. 저도 그중 한 명이었고요.

 

 

💡 짝퉁이 원본을 앞지른 순간

자바를 베꼈다던 언어가,

정작 데이터를 다루는 방식에서는 자바보다 7년을 앞서갔습니다.

LINQ는 이후 다른 언어들이 비슷한 기능을 만들 때 참고하는 기준점이 됐고요.

이쯤 되면 누가 누구를 베꼈는지 애매해집니다.

 

5. async와 await, 비동기를 순차 코드처럼 쓰다

C#이 또 한 번 앞서간 게 비동기 프로그래밍입니다. 2012년 C# 5.0에 들어온 async와 await 키워드 얘기인데요. 네트워크 요청이나 파일 입출력처럼 시간이 걸리는 작업을 처리하는 방식을 바꿔놨습니다.

그전까지 비동기 처리는 고역이었습니다. 콜백 안에 콜백을 넣고 또 넣는 이른바 '콜백 지옥'을 견디거나, 스레드를 직접 관리하며 씨름해야 했죠. 코드가 위아래로 흐르지 않고 여기저기 흩어지니 나중에 읽는 사람은 흐름을 따라가기가 힘들었습니다. 그런데 async와 await는 비동기 코드를 마치 동기 코드처럼 위에서 아래로 쭉 읽히게 만들었습니다. await를 만나면 컴파일러가 알아서 뒤에서 복잡한 처리를 해주고, 작업이 끝나면 원래 자리로 돌아오는 식이죠.

이 방식이 워낙 편해서, 이후 여러 언어가 비슷한 문법을 가져다 썼습니다. 특히 자바스크립트의 async/await는 C#의 영향을 직접 받은 것으로 알려져 있습니다. 재미있는 건 자바스크립트를 다듬은 타입스크립트도 헤일즈버그가 만들었다는 점이에요. 자바는 이 부분에서도 한참 뒤였습니다. 비슷한 편의를 CompletableFuture나 최근의 가상 스레드로 채워가고 있긴 하지만, 개발자가 체감하는 매끄러움은 결이 좀 다릅니다.

6. 대반전, .NET Core로 윈도우 밖에 나오다

여기까지만 보면 C#은 기능은 좋은데 치명적인 약점이 하나 있었습니다. 바로 '윈도우에서만 제대로 돌아간다'는 점이었죠. 서버는 리눅스가 잡고 있는데 C#은 윈도우에 묶여 있으니, 클라우드 시대로 넘어가면서 이 한계는 점점 커졌습니다. 제가 C#을 굳이 배울 필요를 못 느낀 이유도 여기 있었습니다. 어차피 우리 서버는 리눅스였으니까요.

그런데 2014년, 판이 뒤집혔습니다. 사티아 나델라(Satya Nadella)가 마이크로소프트 CEO로 올라선 뒤였죠. 그해 10월 나델라는 무대 위에서 "Microsoft loves Linux"라는 슬라이드를 띄웠습니다. 리눅스를 암 덩어리라고까지 불렀던 전 CEO 시절을 기억하는 사람에게는 충격적인 장면이었어요. 그리고 그해 11월, 마이크로소프트는 .NET 서버 스택을 오픈소스로 풀겠다고 발표합니다.

그 결과물이 .NET Core였습니다. 무거웠던 기존 .NET 프레임워크를 버리고 처음부터 다시 설계한 물건인데, 리눅스와 macOS, 윈도우에서 모두 돌아가는 진짜 크로스 플랫폼이었죠. 도커나 쿠버네티스 환경에도 잘 맞아서 마이크로서비스를 짤 때 쓸 만한 선택지가 됐습니다. 저처럼 '.NET은 윈도우 전용'이라고 못 박아뒀던 자바 개발자들에게는 인식을 다시 해야 하는 사건이었습니다.

7. 자바와 C#, 지금은 어떻게 다른가

초기에는 쌍둥이 소리를 들었지만 20년이 지난 지금 두 언어는 꽤 다른 길을 걷고 있습니다. 어느 쪽이 낫다기보다 강점이 갈린다는 표현이 맞겠네요. 자바 진영에 오래 있었던 제 눈에 보이는 차이를 정리하면 이렇습니다.

반응형

항목	자바(Java)	C#
출발	1995년, 썬 마이크로시스템즈	2000년, 마이크로소프트
주력 무대	엔터프라이즈 백엔드, 안드로이드	게임(유니티), 엔터프라이즈, 데스크톱
람다·스트림	2014년 자바 8	2007년 C# 3.0 (LINQ)
비동기 문법	CompletableFuture, 가상 스레드	async / await (2012년부터)
생태계 색깔	오래된 오픈소스 문화	뒤늦게 합류했지만 빠르게 성장

표로 정리하니 깔끔해 보이지만, 실무에서는 이 경계도 흐려지고 있습니다. 요즘은 한 회사 안에서 자바와 C#을 상황에 맞게 섞어 쓰는 경우도 흔하고요. 결국 언어는 도구라, 팀이 익숙한 걸 잘 쓰는 게 정답에 가깝다고 생각합니다.

8. 2026년의 C#은 어디까지 왔나

지금(2026년) C#은 초기의 짝퉁 이미지를 완전히 벗었습니다. 2025년 11월에 나온 .NET 10이 최신 장기 지원 버전이고, C# 14가 함께 나왔습니다. TIOBE 같은 인기 지표에서도 꾸준히 상위권을 지키고 있죠. 무엇보다 쓰이는 곳이 넓어졌습니다.

• 게임 - 유니티(Unity) 엔진이 C#을 스크립트 언어로 쓰기 때문에, 전 세계 모바일 게임 상당수가 C#으로 만들어집니다.
• 웹 프론트엔드 - Blazor를 쓰면 자바스크립트 없이 C#만으로 브라우저에서 도는 화면을 만들 수 있습니다.
• 모바일·데스크톱 - .NET MAUI로 하나의 코드베이스에서 여러 플랫폼용 앱을 뽑아냅니다.
• 클라우드·서버 - .NET Core 이후로는 리눅스 서버와 컨테이너 환경에서 자연스럽게 돌아갑니다.

자바를 베꼈다는 소리로 시작해서, 어떤 영역에서는 자바보다 앞서갔고, 결국 윈도우라는 울타리까지 스스로 허물었습니다. 언어 하나가 20년 동안 이렇게 자기를 갈아엎는 경우는 흔치 않아요. 개인적으로는 C#의 역사가 '기술이 좋으면 짝퉁 소리도 결국 실력으로 덮을 수 있다'는 사례로 남을 것 같습니다. 확실하진 않지만, 자바 개발자로서 건너편을 지켜본 입장에서는 그렇게 느껴집니다.

자주 묻는 질문

C#은 자바를 베낀 언어가 맞나요?

초기 버전은 문법이 매우 비슷해서 그런 비판을 받았습니다. J++ 소송으로 자바를 다룰 수 없게 된 마이크로소프트가 대체 언어로 만든 배경도 있고요. 다만 2005년 C# 2.0의 제네릭부터 구현 방식이 갈리기 시작해, 지금은 상당히 다른 언어가 됐습니다.

C#은 아직도 윈도우에서만 돌아가나요?

아닙니다. 2014년 발표된 .NET Core부터 리눅스와 macOS에서도 정식으로 돌아갑니다. 지금 쓰는 .NET은 크로스 플랫폼이라 클라우드와 컨테이너 환경에서 널리 쓰입니다.

자바를 하다가 C#으로 넘어가기 어렵나요?

문법 뿌리가 비슷해서 진입 장벽은 낮은 편입니다. 자바 개발자라면 C#의 기본 문법은 며칠이면 익숙해집니다. 오히려 LINQ나 async/await처럼 자바에 늦게 들어온 기능들을 먼저 만나게 되는 경험이 흥미로울 수 있습니다.

지금 C#을 배운다면 어디에 쓰게 되나요?

게임 개발이 목표라면 유니티 때문에 거의 필수에 가깝고, 엔터프라이즈 백엔드나 데스크톱 앱 쪽에서도 수요가 꾸준합니다. 다만 어떤 분야를 하느냐에 따라 다르니, 관심 있는 회사들의 채용 공고에서 어떤 언어를 요구하는지 먼저 확인해보길 권합니다.

마무리

C#의 역사를 자바 개발자의 눈으로 따라가 보면, '짝퉁'이라는 첫인상이 얼마나 오래 갔는지, 그리고 그걸 뒤집는 데 얼마나 오랜 시간이 걸렸는지가 보입니다. 문법을 베꼈다는 비판에서 출발해, LINQ와 async/await로 원본을 앞지르고, 끝내 윈도우라는 자기 울타리까지 허문 과정이었죠. 언어를 고를 때 저는 '어느 게 더 좋냐'보다 '내가 하려는 일에 뭐가 맞냐'를 봅니다. 그 기준에서 C#은 이제 무시하기 어려운 선택지가 됐다는 것, 그 정도가 자바 진영에 오래 있던 제가 인정하게 된 부분입니다.

📚 함께 보면 좋은 글

C++는 왜 C+1이 아닐까? 이름에 담긴 1983년의 농담과 탄생 배경

Go 언어(Golang)는 왜 태어났을까 - 구글 천재들이 현타 와서 만든 언어

객체지향 프로그래밍(OOP)은 어떻게 태어났나 - 스파게티 코드와 소프트웨어 위기의 역사

MAS(멀티 에이전트 시스템)란 무엇인가 - 모놀리식부터 AI 에이전트까지, 분산 아키텍처의 역사

MVC 패턴이란 무엇인가 - Model·View·Controller가 개발 현장을 바꾼 이야기카테고리: 언어의역사