개발자라면 아침에 눈 뜨자마자 켜는 프로그램, 아마 십중팔구는 텍스트 에디터일 겁니다. 저 역시 커피 한 잔과 함께 비주얼 스튜디오 코드(VS Code)를 실행하는 것으로 하루를 시작하곤 합니다. 마이크로소프트가 만든 이 걸작은 어느새 전 세계 개발자들의 표준이 되어버렸죠. 윈도우, 맥, 리눅스 할 것 없이 어디서나 돌아가고, 거의 모든 언어를 지원하니 안 쓸 이유가 없어 보입니다.

그런데 혹시, VSCodium이라는 이름을 들어보셨나요? “이름이 왜 이래? 짝퉁인가?”라고 생각하고 넘기셨을 수도 있습니다. 솔직히 말해서 저도 처음엔 그랬습니다. 아이콘도 비슷하고 기능도 똑같은데, 굳이 익숙한 VS Code를 두고 다른 걸 설치할 필요를 못 느꼈으니까요. 하지만 어느 날, 제 노트북의 네트워크 트래픽 로그를 우연히 뜯어보다가 깜짝 놀랐던 경험이 있습니다. 제가 아무것도 하지 않고 코드를 작성만 하고 있는데도, 백그라운드에서 끊임없이 어딘가로 데이터를 보내고 있었기 때문입니다.
그날 이후 저는 도구의 ‘편리함’ 뒤에 숨겨진 ‘대가’에 대해 진지하게 고민하게 되었습니다. 단순히 브랜드 이름의 차이가 아닙니다. 여러분이 매일 사용하는 그 도구가 실제로 어떻게 만들어지고, 여러분의 데이터를 어떻게 다루는지, 그리고 왜 일부 개발자들은 불편함을 감수하고 VSCodium을 고집하는지, 그 내막을 낱낱이 파헤쳐 보려 합니다.
오픈소스인 듯 오픈소스 아닌, VS Code의 진실
우리는 흔히 VS Code를 ‘오픈소스’라고 부릅니다. 마이크로소프트가 깃허브(GitHub)에 소스 코드를 공개했고, MIT 라이선스를 따르고 있으니 틀린 말은 아닙니다. 투명성을 중시하는 개발자들에게는 아주 매력적인 포인트죠.
하지만 여기에 함정이 하나 있습니다. 여러분이 마이크로소프트 공식 홈페이지에서 다운로드 버튼을 눌러 설치하는 그 프로그램(바이너리)은, 깃허브에 올라온 소스 코드와 100% 같지 않습니다.
요리에 비유하자면
쉽게 설명해 보겠습니다. 마이크로소프트가 “최고의 파스타 레시피(소스 코드)”를 무료로 공개했습니다. 누구나 이 레시피를 보고 요리할 수 있죠. 그런데 막상 여러분이 마트에서 사 오는 “마이크로소프트 브랜드가 찍힌 파스타 밀키트(설치 파일)”에는, 공개된 레시피에는 없는 특제 소스가 추가되어 있습니다.
이 ‘특제 소스’가 바로 빌드 과정에서 주입되는 product.json 파일입니다. 마이크로소프트는 소스 코드를 실행 파일로 컴파일할 때, 자사의 브랜딩, 갤러리 설정, 그리고 결정적으로 ‘텔레메트리(데이터 수집)’ 메커니즘을 슬쩍 끼워 넣습니다.
결국 여러분이 사용하는 VS Code는 오픈소스 코드를 기반으로 하지만, 결과물은 마이크로소프트의 독점 라이선스 정책을 따르는 사유 소프트웨어가 됩니다. “수정 금지, 역공학 금지, 재배포 금지” 같은 조항들이 붙는 이유가 바로 여기에 있습니다. 내 코드는 내 것이지만, 그 코드를 작성하는 도구는 법적으로나 기능적으로나 마이크로소프트의 생태계에 묶여 있는 셈입니다.
VSCodium이 탄생한 이유
VSCodium은 바로 이 지점에서 출발합니다. “MS의 독점적인 양념을 뺀, 순수한 요리를 먹고 싶다”는 커뮤니티의 요구가 만들어낸 결과물입니다.
VSCodium은 특별한 빌드 스크립트를 사용하여 VS Code의 오픈소스 저장소를 복제합니다. 그리고 마이크로소프트의 독점적인 커스터마이징을 전혀 거치지 않고 컴파일합니다. 결과적으로 VSCodium은 빌드 프로세스 전체가 투명하게 공개된, 진짜배기 오픈소스 소프트웨어가 됩니다. MIT 라이선스의 자유를 100% 누릴 수 있는 유일한 대안인 것이죠.
프라이버시, 당신의 코딩 습관이 전송되고 있다
개발자들은 누구보다 데이터 프라이버시에 민감한 집단입니다. 하지만 아이러니하게도 우리가 쓰는 도구는 가장 수다스러운 스파이일지도 모릅니다.
VS Code와 VSCodium의 가장 큰, 그리고 결정적인 차이는 바로 ‘데이터 수집(텔레메트리)’을 다루는 방식에 있습니다.
기본 설정의 무서움
공식 VS Code를 설치하고 실행하는 순간부터 텔레메트리는 활성화됩니다. 여러분이 어떤 기능을 자주 쓰는지, 언제 앱이 충돌했는지, 심지어 어떤 환경에서 작업하는지에 대한 데이터가 자동으로 마이크로소프트 서버로 전송됩니다.
물론 설정 메뉴 깊숙한 곳에 들어가서 이 기능을 끌 수는 있습니다. 하지만 앞서 말씀드린 product.json 파일 안에 이미 텔레메트리 엔드포인트(데이터가 전송될 목적지 주소)가 하드코딩 되어 있습니다. 즉, 앱의 구조 자체가 마이크로소프트 서버와 연결되도록 설계되어 있다는 뜻입니다.
제가 VSCodium으로 갈아타게 된 결정적인 계기도 이것이었습니다. 회사 보안 정책 때문에 네트워크 패킷을 분석하던 중, VS Code가 주기적으로 외부 서버와 통신하는 것을 보고 찜찜함을 지울 수 없었거든요.

침묵을 지키는 VSCodium
반면 VSCodium은 수다스럽지 않습니다. 빌드 과정에서 추적 메커니즘을 아예 뜯어냈기 때문입니다. 마이크로소프트가 추적을 위해 사용하는 독점 설정 파일이 주입되지 않았으므로, 텔레메트리 엔드포인트 자체가 존재하지 않거나 무력화되어 있습니다.
법적으로나 기능적으로나 마이크로소프트의 데이터 수집 서버와는 완전히 연결이 끊겨 있습니다. 별도의 설정 없이도, 설치하는 순간부터 여러분의 작업 환경은 외부와 차단된 안전한 상태가 됩니다. 보안이 중요한 기업 환경이나, 개인정보에 민감한 개발자에게 VSCodium은 선택이 아닌 필수일 수 있습니다.
편의성의 대가, 확장 프로그램 생태계의 분열
여기까지만 들으면 “당연히 VSCodium을 써야지, 왜 아직도 사람들은 VS Code를 쓰는 거야?”라고 반문하실 수 있습니다. 하지만 현실은 그렇게 간단하지 않습니다. 우리가 VS Code를 떠나지 못하는 가장 큰 이유, 바로 ‘확장 프로그램(Extensions)’ 때문입니다.
마켓플레이스의 장벽
VS Code의 강력함은 수만 개의 확장 프로그램을 클릭 한 번으로 설치할 수 있는 마이크로소프트 마켓플레이스에서 나옵니다. 린터(Linter), 디버거, 테마 등 필요한 모든 도구가 거기에 있죠.
하지만 마이크로소프트는 마켓플레이스 이용 약관에 “이곳의 확장 프로그램은 마이크로소프트 제품에서만 사용해야 한다”라고 명시해 두었습니다. 법적으로 VSCodium은 이 공식 저장소에 접근할 수 없습니다.
Open VSX, 그리고 호환성 이슈
이 문제를 해결하기 위해 VSCodium은 이클립스 재단(Eclipse Foundation)이 호스팅하는 ‘Open VSX Registry’를 사용합니다. 벤더 중립적인 오픈소스 대안 저장소죠. 다행히 대부분의 인기 있는 확장 프로그램들은 이곳에도 등록되어 있습니다.
하지만 문제는 ‘마이크로소프트가 직접 만든’ 핵심 도구들입니다.
제가 C# 개발 프로젝트를 진행할 때 겪었던 일입니다. VSCodium을 설치하고 의기양양하게 시작했지만, 공식 ‘C# Dev Kit’이 검색되지 않아 당황했습니다. 알고 보니 이 확장 프로그램의 라이선스는 마이크로소프트 공식 빌드에서만 작동하도록 제한되어 있었습니다.
이뿐만이 아닙니다. 최근 개발의 핵심이 된 AI 도구 ‘GitHub Copilot’, 실시간 협업 도구 ‘Live Share’, 원격 개발을 위한 ‘Remote Development(SSH, WSL)’ 등 마이크로소프트의 킬러 기능들은 VSCodium에서 사용하기 매우 까다롭거나, 아예 불가능합니다.
물론 수동으로 파일을 다운로드하여 설치하는 우회 방법들이 존재하지만, 업데이트 때마다 번거로운 과정을 거쳐야 합니다. 결국 ‘편리함’이라는 강력한 무기 앞에서 많은 개발자가 다시 VS Code로 돌아가게 되는 이유입니다.
VS Code vs VSCodium 핵심 비교 분석
복잡한 내용을 한눈에 파악하실 수 있도록 주요 차이점을 정리해 보았습니다.
| 비교 항목 | Visual Studio Code (MS 공식) | VSCodium (커뮤니티 빌드) |
| 라이선스 | 독점 라이선스 (Proprietary) | MIT 라이선스 (Open Source) |
| 데이터 수집 | 기본 활성화 (MS 서버로 전송) | 완전 제거됨 (전송 안 함) |
| 빌드 구성 | 오픈소스 + MS 독점 커스터마이징 | 순수 오픈소스 빌드 |
| 확장 프로그램 | MS 공식 마켓플레이스 (모든 기능 사용 가능) | Open VSX Registry (일부 MS 전용 기능 제한) |
| 주요 제한 기능 | 없음 | Copilot, Live Share, Remote SSH 등 |
| 설치 및 업데이트 | 매우 간편 (자동 업데이트) | 패키지 관리자 등을 통해 관리 필요 |
어떤 것을 선택해야 할까?
결국 선택은 여러분이 무엇을 더 중요하게 생각하느냐에 달려 있습니다. 정답은 없지만, 상황에 따른 추천은 드릴 수 있습니다.
이런 분들은 VS Code를 계속 쓰세요
가장 중요한 것이 ‘생산성’과 ‘편리함’이라면 고민할 필요 없이 VS Code입니다. 특히 현업에서 팀 단위로 움직이거나, 마이크로소프트의 생태계(Azure, GitHub Copilot, C# 등)를 적극적으로 활용하고 있다면 VSCodium은 오히려 걸림돌이 될 수 있습니다. 설정하느라 시간을 낭비하는 것보다, 그 시간에 코드를 한 줄 더 짜는 것이 이득일 테니까요.
이런 분들에게는 VSCodium을 강력 추천합니다
반면, “내 컴퓨터에서 나가는 모든 데이터는 내가 통제해야 한다”는 신념을 가진 분들, 혹은 순수한 오픈소스 정신을 지지하는 분들에게 VSCodium은 최고의 선물입니다. 단순히 찝찝함을 없애는 것을 넘어, 실제로 더 가볍고 투명한 환경에서 개발에 집중할 수 있습니다. 특히 파이썬이나 자바스크립트처럼 특정 벤더 종속성이 낮은 언어를 주로 다룬다면, VSCodium으로 전환해도 불편함을 거의 느끼지 못하실 겁니다.
마무리하며
도구는 도구일 뿐이라고 말하지만, 개발자에게 에디터는 단순한 도구 이상입니다. 그것은 매일 마주하는 작업 공간이자, 창조가 이루어지는 집과도 같습니다.
저는 현재 두 가지를 모두 사용하고 있습니다. 회사의 윈도우 노트북에는 협업을 위해 VS Code를 설치했고, 개인적으로 사용하는 맥북에는 VSCodium을 깔아두었습니다. 처음에는 VSCodium의 확장 프로그램 설정이 조금 낯설었지만, 이제는 그 깔끔함과 가벼움에 꽤나 만족하고 있습니다.
여러분도 막연히 남들이 쓰니까 쓰는 것이 아니라, 한 번쯤은 “내가 쓰는 이 도구가 정말 나에게 맞는 옷인가?”를 고민해 보셨으면 좋겠습니다. 오늘 당장 VSCodium을 한번 설치해 보세요. 어쩌면 그동안 느끼지 못했던 묘한 해방감을 맛보실 수도 있으니까요.