Visual Studio Code 설계 결함 (2022)

• Visual Studio Code는 MIT 라이선스 소스 코드와 Microsoft가 배포하는 독점 라이선스 제품이 분리되어 있어, VSCodium·OpenVSCode Server 같은 포크가 공식 생태계와 충돌함
• 공식 빌드는 product.json에 텔레메트리, gallery, logo 같은 Microsoft 전용 설정을 넣어 배포되고, 커뮤니티 빌드는 “clean” 빌드가 되지만 Visual Studio Code Marketplace에 연결할 수 없음
• VSCodium과 OpenVSCode Server는 공식 릴리스의 텔레메트리를 제거하거나 포함하지 않지만, 확장 자체의 데이터 수집과 Marketplace 접근 제한 때문에 사용자가 기대하는 VS Code 경험을 그대로 제공하기 어려움
• Pylance, C# 확장 로드맵, C/C++ 도구 라이선스처럼 Microsoft 확장과 언어 서버가 공식 제품·서비스에 묶이면 Gitpod, GitLab, Datacoves, OpenBB, Foam 같은 경쟁 서비스는 같은 기능을 합법적으로 제공하기 어려워짐
• OpenVSX와 오픈 언어 도구 개발, 오픈소스 유지보수자 지원이 대안으로 거론되지만, Microsoft가 기본값을 독점 도구로 바꿀 때 커뮤니티와 경쟁 제품은 기능 차이·설정 차이·법적 제약을 함께 떠안게 됨

---

소스 코드는 열려 있지만 제품은 다르게 배포됨

• Visual Studio Code는 출시 7년이 지난 시점에 소프트웨어 개발에서 사실상 표준 편집기로 자리 잡음
• Microsoft는 Visual Studio Code의 소스 코드를 MIT 라이선스로 공개했지만, 사용자가 다운로드하는 Visual Studio Code 제품은 별도의 독점 라이선스로 배포됨
• Visual Studio Code 유지보수자의 설명에 따르면 Microsoft 빌드는 vscode 저장소를 클론한 뒤 Microsoft 전용 product.json을 덮어씀
  • 이 파일에는 텔레메트리, gallery, logo 등 Microsoft 전용 기능이 들어감
  • 이렇게 만든 빌드는 Microsoft 라이선스로 배포됨
• 이 구분이 Microsoft가 오픈소스 커뮤니티를 갈라놓는 핵심 메커니즘이라는 점이 글의 중심 비판임

VSCodium과 OpenVSCode Server가 마주한 한계

• VSCodium은 커뮤니티 주도의 자유 라이선스 데스크톱 배포판임
  • upstream MIT 프로젝트를 자동으로 따라가며 바이너리 빌드를 생성함
  • 공식 릴리스에 있는 텔레메트리를 제거한 빌드를 제공함
  • 기본 product.json에는 Microsoft 엔드포인트가 설정되어 있지 않아 Microsoft 커스터마이징이 없는 “clean” 빌드가 생성됨
• 같은 코드베이스를 쓰는 VSCodium도 모든 데이터 수집을 완전히 막을 수는 없음
  • 확장은 독립적으로 데이터를 수집할 수 있어 설치하는 확장에 주의가 필요함
• OpenVSCode Server는 Gitpod의 기반이 되는 자유 라이선스 서버 배포판임
  • upstream MIT 프로젝트를 자동으로 따라감
  • gp-code/main 브랜치에 일부 오버레이 커스터마이징이 있음
  • 공식 릴리스의 텔레메트리가 포함되지 않음
• 두 배포판 모두 Microsoft Visual Studio Code Marketplace에 연결할 수 없고, 이 제한이 생태계 단절로 이어짐

Microsoft의 서비스 중심 전환과 개발 도구 전략

• Microsoft는 약 9년 전부터 소프트웨어 제공 방식을 바꾸기 시작함
  • 전담 QA 팀이 빌드를 테스트하던 방식에서 스프린트 기반 개발, rolling release, Insider Build 텔레메트리 피드백 기반 방식으로 이동함
• 같은 시기 조직 개편을 거치며 Microsoft는 서비스 회사로 전환됨
  • Azure는 이 기간 동안 AWS의 실질적 경쟁자로 성장함
• 소비자 관점에서 가장 큰 변화는 설치형 온프레미스 제품에서 Microsoft가 제공하는 서비스 소비 모델로 고객 기반이 이동했다는 점임
• 개발 도구 영역에서도 구독이 아닌 IDE는 줄어드는 흐름으로 다뤄짐
  • Apple의 Xcode처럼 다른 수익원이 있는 경우는 예외로 언급됨
• Visual Studio Code는 개발 도구 생태계를 end-to-end 소비형 서비스 모델로 옮기는 진입로라는 비판을 받음
  • GitHub Codespaces는 Visual Studio Online, Microsoft Dev Box, Microsoft Azure DevTest Labs와 연결된 기존 서비스의 white label로 설명됨

GitHub Codespaces와 Microsoft DevDiv

• Microsoft는 2018년 GitHub를 인수했고, 2019년 Visual Studio Online을 공개함
  • 여기에는 로컬에서 “codespace”를 호스팅하는 구성 요소가 포함됨
  • 이후 Codespaces 팀을 포함한 관련 요소가 GitHub로 이동함
• GitHub Codespaces는 GitHub 소속이 된 DevDiv 프로젝트로 설명됨
• Nat Friedman이 CEO에서 물러난 날 Microsoft 내부 조직 개편 메일이 공유됨
  • Julia Liuson이 Microsoft Developer Division 사장으로 승진함
  • GitHub CEO Thomas Dohmke가 Julia Liuson에게 보고하는 구조가 됨
  • Developer Division에는 Visual Studio, Visual Studio Code, .NET, C#, TypeScript, OpenJDK, Azure 개발자 SDK, Azure App Services, Functions, Logic Apps, API Management, Dapr, Redis Cache, Spring Cloud 등이 포함됨
• 해당 메일에 따르면 Visual Studio와 Visual Studio Code는 2014년 이후 16배 이상 사용량 증가를 기록함
• Julia Liuson은 승진 전 .NET 커뮤니티를 갈라놓은 마지막 순간 변경을 실행한 인물로 언급됨
  • The Verge 인용에 따르면 Microsoft 내부 익명 소식통은 이 변경을 비즈니스 중심 결정으로 봄

“설계된 단절”로 작동하는 생태계 구조

• Gitpod 같은 경쟁 제품은 Visual Studio Code 생태계 안에 존재할 수 있지만, Microsoft가 언제든 법적 위험을 만들어 시장을 나눌 수 있다는 비판을 받음
• Visual Studio Code 오픈소스 소스 코드는 사용자를 끌어들이지만, 경쟁 서비스가 공식 Visual Studio Code나 GitHub Codespaces 같은 매끄러운 경험을 제공하기 어렵게 만듦
• Gitpod뿐 아니라 GitLab, Datacoves, OpenBB, Foam 등 VS Code 소스 코드를 기반으로 Microsoft나 GitHub와 경쟁하려는 회사들도 같은 문제를 겪음
• Microsoft 도구에 의존하면 경쟁 서비스가 합법적으로 제공하기 어려운 영역으로 다음이 언급됨
  • Microsoft .NET C#
  • Python 일반 목적 및 데이터 과학 시장
  • Project Jupyter와 데이터 과학 시장 대부분
  • C 또는 C++
  • Java는 Microsoft 도구가 RedHat 도구 수준에 가까워지면 다음 대상이 될 수 있다고 예상됨
• TIOBE 지수 기준으로 위 언어·생태계 중 5개가 가장 인기 있는 축에 포함되며, Microsoft는 TypeScript를 통해 7번째로 인기 있는 JavaScript에 가까운 통제력을 가진다고 설명됨

기본값 전환과 독점 확장 문제

• Microsoft는 충분한 채택을 확보한 뒤 확장 업데이트로 독점 제공물을 기본값으로 만들 수 있다는 비판을 받음
• Python 커뮤니티에서는 오픈소스 Microsoft Python Language Server가 종료되고 독점 Pylance가 기본값이 됨
  • Visual Studio Magazine 인용에 따르면 Microsoft는 사용자를 강제로 전환하지는 않았지만 Pylance를 새 기본값으로 설정함
  • Python 확장은 VS Code Marketplace에서 약 5천만 다운로드를 기록했고, 다음으로 인기 있는 Jupyter 확장의 약 2배로 언급됨
• .NET 커뮤니티에서도 C# 확장 로드맵을 통해 비슷한 기본값 전환이 진행 중인 사례로 제시됨
• Open.NET 같은 대안 도구가 만들어져도 사용자는 플랫폼별 설정을 따로 연결해야 함
  • 데스크톱에서는 devcontainer.json에 ms-dotnettools.csharp를 넣을 수 있음
  • Gitpod에서는 gitpod.yml에 아직 존재하지 않는 오픈 도구를 넣어야 하는 식의 차이가 생김
• Microsoft 공식 생태계 안에서는 같은 devcontainer.json 설정이 데스크톱 Visual Studio Code와 GitHub Codespaces에서 그대로 동작하는 단일 설정 원천이 됨

라이선스가 만드는 법적 제약

• Gitpod, GitLab, Datacoves, OpenBB, Foam 등이 제한을 우회해 ms-dotnettools.csharp 같은 Microsoft 확장을 서비스에서 제공하면 Microsoft 법무팀의 강한 법적 대응을 받을 수 있다고 경고함
• 경쟁 클라우드 개발 환경 사용자가 해당 확장을 수동 설치해도 라이선스 위반이 될 수 있음
• Microsoft C/C++ 확장 라이선스 문구는 소프트웨어를 Microsoft Visual Studio, Visual Studio for Mac, Visual Studio Code, Azure DevOps, Team Foundation Server 및 후속 Microsoft 제품·서비스와 함께만 설치·사용할 수 있다고 밝힘
• 이 조건 때문에 공식 Microsoft 배포판이 아닌 VS Code 기반 제품은 사용자가 기대하는 Microsoft 언어 도구를 그대로 제공하기 어려움

대응 방향: OpenVSX와 오픈 언어 도구

• 현재 구축되는 소프트웨어 개발 도구의 미래가 폐쇄적으로 가고 있다는 비판이 나옴
  • 일부 구성 요소가 OSI 정의를 만족하더라도 전체 구성 그래프는 그렇지 않을 수 있음
• 오픈소스는 원래 독점 온프레미스 소프트웨어를 견제하고 파일 형식 개방성을 유지하는 금융적 무기로 설명됨
  • 동시에 오픈소스로 돈을 벌기 어려운 이유와도 연결됨
• proprietary SaaS에 맞서 컴퓨팅 자유의 개방성을 보장하는 새 운동 또는 1970년대 자유 소프트웨어 운동의 재검토가 필요할 수 있다고 제안함
• Gitpod의 Open-Source Sustainability Fund는 이 생태계 단절 문제에 대한 대응 중 하나임
  • 1.5년 동안 오픈소스 커뮤니티의 언어 서버 도구 유지보수자에게 3만2천 달러 이상이 배포됨
• Gitpod는 Visual Studio Code 오픈소스 생태계의 Marketplace 문제를 일부 해결하기 위해 Open VSX를 만들고 Eclipse Foundation에 기증함
• 앞으로의 가장 큰 과제는 Microsoft가 독점 언어 서버로 커뮤니티를 이동시킨 영역마다 오픈 언어 도구를 개발하는 것임

이후 편집으로 추가된 내용

• 2022년 8월 31일 편집은 Microsoft가 VSCode를 만들고, 독점 무료 배포판과 독점 무료 확장을 제공한 뒤, 언어별 최선의 경험을 닫힌 형태의 VSCode로 묶었다고 요약함
• 2022년 12월 16일 편집은 GitLab의 VSCode MIT 기반 Web IDE와 원격 개발 경험도 같은 문제를 겪는다고 덧붙임
• 2023년 10월 13일 편집은 Google의 Project IDX도 VSCode MIT 기반이며, .NET과 Python에서 Visual Studio Code LSP가 그대로 동작할 것이라는 기대는 불가능하고 합법적이지 않다고 밝힘
• 2025년 4월 24일 편집은 Microsoft가 Windsurf와 Cursor 같은 AI 코딩 어시스턴트 경쟁을 억제하기 위해 VSCode 생태계를 의도적으로 깨뜨렸다고 비판함
  • 같은 날 Microsoft의 경쟁 제품 출시와 C/C++ 확장의 VS Code forks 접근 제한을 연결해 언급함

[unsure4000]

vim이나 zed 쓰는 방안을 고려해보고있어요

제가 opacity가 설정된 터미널을 쓰고있는데,
nvim 배경색 없에는 방법 혹시 아시나요?
이거만 찾으면 nvim 꼭 써보고싶은데...ㅁ

[siscof]

kitty 터미널을 쓰신다면 같은 배경색으로 처리하면 투명 적용 될거예요.
아니면 이런 플러그인을 고려해 보시는 것도..

https://github.com/xiyaowong/transparent.nvim

[unsure4000]

감사합니다. 한 번 알아보겠습니다

[unsure4000]

성공했습니다. 감사합니다. 좋은 하루 보내세요.

[GN⁺]

Hacker News 의견들

• 어떤 면에서는 이 상황이 기회가 될 수도 있음. VSCode 생태계는 여러 면에서 꽤 취약함
  cpptools는 대단한 면도 있지만 자주 오작동하고 사실상 디버깅이 불가능하며, 다른 확장도 크게 낫다고 기대하기 어려움
  더 큰 문제는 보안 모델이 매우 약하다는 점으로, 확장은 샌드박스 처리되지 않고 원격 저장소에 접근하는 클라이언트도 설계상 매우 불안전함
  회사 코드만 볼 때는 저장소가 자신을 공격할 가능성을 덜 걱정할 수 있지만, 악성 확장은 당연히 걱정해야 하고 개발 도구를 너무 쉽게 신뢰하는 데 익숙해져 있음
  LLM은 절대 신뢰하면 안 되며, 사용자를 공격하려 할 수도 있는 LLM에게 저장소에 직접 쓰거나 VSCode 일부 문맥에서 JS 코드를 실행할 권한을 주는 건 안전하지 않음
  더 나은 생태계라면 cpptools에 해당하는 도구는 인터넷 접근 권한이 없으므로 원격 측정도 없고, 작업공간 읽기·자기 캐시 파일 생성·UI 조작 정도만 가능해야 함

  • VSCode는 설계상 개발 환경의 실제 상태를 가려 버려서, 막힌 사용자를 도와주다 보면 그들이 어느 컴퓨터에 로그인했는지, 파일이 파일시스템 어디에 있는지, 어떤 Python 인터프리터를 쓰는지, HTTPS_PROXY가 무엇으로 설정됐는지조차 모르는 경우가 많음
    SSH 확장도 사용자가 연결하는 클라이언트마다 서버 프로세스를 띄우고, 연결 해제 후 상태 보존도 일관적이지 않아 보임
    결국 VSCode를 쓰며 스스로 만든 문제를 고치도록 돕는 데 시간을 많이 쓰게 됨
  • VSCode 보안 모델은 우리 정보보안 팀에도 큰 걱정거리임
    마켓플레이스의 모든 확장에 열린 접근을 허용하거나, 완전히 잠그고 로컬 파일로만 확장을 설치하게 하는 두 선택지 사이의 중간 지대가 없음
    후자는 VSCode 유지관리에 상당한 부담을 줌
  • compile_commands.json을 가지고 있거나 생성할 수 있고, 특히 CMake에서는 비교적 쉬우며, clangd가 이를 보게 할 수 있다면 clangd 확장이 내게는 훨씬 나았음
  • 원격 저장소에 접근하는 클라이언트가 설계상 극도로 불안전하다면, 서드파티 확장 보안에서 가장 나은 편집기는 무엇인지 궁금함
    내가 쓰는 Emacs도 공급망 공격을 막을 장치가 별로 없고, 대부분은 Git 저장소에서 직접 가져오는 커뮤니티 확장 집계기를 씀
    다만 Emacs 사용자는 가져오는 확장의 소스 코드를 실제로 들여다볼 비율이 훨씬 높을 것 같다는 아주 작은 장점은 있음
  • 확장이 샌드박스 처리되지 않는다는 게 사실이라면 꽤 놀라움
    Microsoft는 수년간 “보안이 전부이고 지금 가장 중요하다”고 말해 왔는데, SSH 키 같은 것이 탈취됐을 때 영향이 가장 큰 사용자층이자 보안을 가장 의식할 개발자층을 위해 그런 기본조차 챙기지 않았다니 이상함
    사람들이 무작위로 확장을 설치하고 Visual Studio Code가 “언어 지원” 명목으로 임의 확장을 추천하는 상황이 생각보다 훨씬 나빠 보임

• cpptools 확장 관련 좋은 스레드가 있음: https://github.com/microsoft/vscode-cpptools/discussions/126...
  소스에서 빌드하는 과정을 깊게 파보진 않았지만, 이 글을 보면 아예 불가능해 보임
  어떤 코드베이스가 OSS 라이선스이고, 그 빌드 의존성까지 OSS 라이선스인지 표현할 새 용어가 필요해질 듯함

  • 이건 정말 심각함. 나중에 Microsoft가 그 스레드를 묻어 버리면 미래 사람들은 우리가 뭘 두고 이야기했는지 궁금해할 것임
  • Debian은 배포판을 세 구성요소로 나눔: main은 자유 소프트웨어, non-free는 비자유 소프트웨어, contrib은 자유 소프트웨어지만 main 밖의 보통 비자유 소프트웨어에 의존하는 것임
    contrib이라는 용어 자체를 좋아하진 않지만, 이 분류는 꽤 타당해 보임
  • 이 작은 댓글 몇 개만으로도 더 큰 생태계가 맞닥뜨린 문제가 정확히 드러나고, 생각보다 훨씬 빨리 훨씬 나빠질 가능성이 큼
  • VSCode는 오픈소스가 아니고, 이 확장도 오픈소스가 아님
    Windows의 많은 F/OSS와 macOS의 거의 모든 F/OSS가 MSVC, Xcode, Apple 프레임워크·GUI 툴킷 같은 독점 빌드 의존성을 갖지만, 그래도 그 자체는 F/OSS일 수 있음
    하지만 이 경우는 그런 문제가 아니라, 유지관리자로 보이는 Microsoft 직원이 “우리 라이선스는 대체 VS Code 배포판에서 확장을 쓰는 것도 금지하며, Microsoft가 만든 공식 배포판에서만 사용할 수 있다”고 말한 상황임
    이는 그냥 독점 소프트웨어임
    자유 소프트웨어 정의의 자유 0은 원하는 목적을 위해 프로그램을 실행할 자유이고, VSCode의 서드파티 배포판이 공식 배포판과 같은 확장 권리나 호환 확장과 함께 쓸 권리를 갖지 못한다면 코드 일부의 라이선스와 무관하게 자유 3도 통과하지 못함
    “언어 서버 바이너리를 자체 제공물로 재배포하려는 것이라면 런타임 라이선스가 금지한다”는 말은 오픈소스 정의의 조건 1, 즉 재배포 기준을 통과하지 못한다는 뜻이고, 수정 재배포판에 원본과 같은 권리를 허용하지 않는 VSCode도 조건 3, 파생 저작물 기준을 통과하지 못함
    VSCode와 이 확장은 모두 오픈소스가 아니라, 오픈소스 구성요소를 일부 포함한 독점 소프트웨어임
    자유 소프트웨어 정의: https://www.gnu.org/philosophy/free-sw.html.en#four-freedoms
    오픈소스 정의: https://opensource.org/osd
    이 정의들은 일반 사전적 의미가 아니라, 특정 사회적·기술적 목적을 갖고 운동 내부에서 만들어진 용어라는 점도 중요함
  • 이해하기로 이 확장은 EDG에서 상업 라이선스로 가져온 독점 C++ 프런트엔드를 사용함
    같은 프런트엔드가 Visual Studio IDE에도 들어감
    대안으로 clangd 기반의 완전 오픈소스 C++ 확장이 있는 것으로 알고 있지만, 틀릴 수도 있음

• “Microsoft가 공짜로 주는 자유 소프트웨어가 충분히 열려 있지 않다”는 건 요즘 기준으로도 꽤 이상한 주장처럼 들림
  예전에는 “무료 IDE”라면 Eclipse나 확장 잔뜩 붙인 Vim을 뜻했음
  보기엔 Microsoft가 열린 대안을 방해한다기보다 그냥 그 대안들이 덜 좋을 뿐이고, 직원에게 급여를 주면서 이익도 내야 하는 회사가 만든 소프트웨어를 쓸 때는 원래 그런 면이 있음
  Microsoft의 최고 소프트웨어 소스 코드를 당연히 받아야 한다고 느끼는 사람들은 독립 비영리 단체가 유지하는 진짜 오픈소스가 어떤 모습인지 보면 됨
  기능은 하고 어쩌면 진짜 디버거도 있겠지만, 오래지 않아 돌아가고 싶어질 가능성이 큼
  사람들은 무료로 받은 소프트웨어를 너무 당연하게 여기고 있음. 그리 오래 전만 해도 IDE에 수백~수천 달러를 내야 했고, 몇 년 뒤 새 버전이 필요하면 업그레이드 비용도 냈음

  • Microsoft가 열린 대안을 방해하지 않는다고 보긴 어려움
    VSIX 확장은 어느 정도 열린 표준이어야 하는데, Pylance 같은 Microsoft 확장은 Microsoft 빌드가 아닌 VS Code에서 실행 중임을 감지하면 적극적으로 동작을 거부함
  • “Microsoft가 공짜로 주는 자유 소프트웨어가 충분히 열려 있지 않다”는 건 글의 인용도 아니고 글의 주장도 아님
    핵심은 개발자들이 속고 있으며 Microsoft의 목표가 필수 부분을 닫아 가는 데 있다는 쪽에 가까움
  • Asahi Linux 프로젝트를 보면 비슷함. 엄청난 일을 하고 있지만, 3년 된 노트북과 기본 기능 동등성을 맞추는 일도 아직 진행 중임
    기능 동등성이 끝나도 다음에는 성능 문제가 남고, 그게 언제 해결될지도 모름
    오픈소스 소프트웨어라는 생각은 좋지만, 오늘날 최고의 소프트웨어는 거의 항상 돈을 내야 얻을 수 있음
  • 내 문제는 Microsoft의 큰 계획을 모른다는 것임
    Emacs와 Vim을 쓰는 대가는 알고 있음. 이론상 완전히 무료라도 실제로는 시간, 인내, 헌신이라는 비용이 있고, 내 선택으로 나와 커뮤니티와 업계가 이익을 얻는다는 걸 앎
    예전에 IntelliJ를 쓸 때도 JetBrains가 어떻게 이익을 얻는지 정확히 알았음. 라이선스 비용을 내고 매년 갱신했으니까
    그런데 Microsoft의 계산은 뭘까? 이렇게 아름답고 괜찮은 도구를 완전히 “무료”로 주는데, 미래에 내가 어떤 대가를 치르게 될까?
    독일 GDP에 맞먹는 시가총액을 가진 거대 기업이 단지 개발자를 사랑해서 막대한 자원을 들여 “무료” 코드 편집기를 만든다고 믿기는 어려우며, 개발자는 적어도 조금은 회의적이어야 함
  • “Microsoft의 최고 소프트웨어”라는 표현은 농담처럼 들림
    Microsoft 소프트웨어는 악몽 같은 쓰레기 더미에 가깝다고 봄
    닫힌 소스 소프트웨어가 오픈소스인 척하면 그걸 쓰고 싶지 않은 사람에게도 영향을 준다는 게 글의 요점인데, 그걸 놓치고 있음
    예를 들어 Azure DevOps인지 GitHub Actions인지도 쓰고 싶지 않지만, 내가 일하는 조직이 프로젝트를 GitHub에 올려야 해서 강제로 쓰게 됨
    그 결과 내 노동과 지식이 Microsoft가 사용자들을 착취하는 데 쓰이는 느낌이 듦
    유일한 위안은 이게 유급 업무라는 점뿐이고, 개인적으로는 GitHub를 쓰지 않으며 다른 사람에게도 그렇게 권할 것임

• VS Code를 만드는 상근 직원 50명 이상의 연간 약 2천만 달러 예산을 어떻게 정당화할지 모델을 제시하지 않는다면, 이 비판은 “그들의 엔지니어링 성과를 우리 회사가 가져다 제품 표면만 바꾸고, 자체 개발비 없이 더 싸게 팔아 이익을 얻기 조금 불편하게 만들었다니 짜증난다”처럼 들림

  • Microsoft가 여러 부서의 내부 사용을 위해 자체 IDE를 만들고, 유연한 현대적 도구를 위해 예산을 쓰는 건 납득 가능함
    이를 오픈소스로 공개하면 다른 커뮤니티의 신뢰를 얻고, 무료 코드·버그 점검과 Microsoft 생태계 밖의 확장 작성·지원도 얻을 수 있으며, Microsoft도 그것을 계속 사용할 수 있음
    그리 복잡한 문제로 보이지 않음
  • 그건 내 문제가 아님. 내 문제는 내 직무 역량을 Microsoft의 계속된 선의에 의존하게 만들지 않는 것임
    역사적으로 그것은 노후화로 가는 보장된 길이었음
    그들의 엔지니어링 성과가 없어도 Emacs, Vim, Clang, GCC, IDEA, Eclipse, Firefox 등이 있음
    Microsoft의 관대한 담요 선물은 천연두가 딸려오지 않을 때만 관심 있음
  • 그들의 사업 모델이 나쁘다는 건 내 걱정거리가 아님. 그들은 잘못된 결정을 이용당하는 가난한 아이가 아님
    다만 이걸 대단한 놀라움처럼 보도하는 건 좀 웃김. 처음부터 명백했고, 단지 싸울 가치가 없어 보여 신경 쓰지 않았을 뿐임
    BSD/MIT 라이선스 개발자가 착취당하는 문제는 원격 측정을 꺼서 Microsoft의 사업 모델이 흔들릴 수 있다는 문제만큼이나 별 관심 없음
    다들 “대기업 선배가 우리를 알아봐 줄 거야”라고 생각하며 무엇에 들어가는지 알고도 선택했고, 실제로 알아봐 줬으니 축하할 일임
    나는 AGPL보다 약한 라이선스로는 아무것도 올리지 않겠지만, 결국 소프트웨어보다 훨씬 더 신경 쓰는 일들이 있음

• 아직도 무엇이 문제인지 파악하려는 중임
  Microsoft가 더 나은 cpptools/C++ 확장을 만들고 있는데 많은 Microsoft 구성요소가 닫혀 있어서 완전한 OSS 버전을 빌드할 수 없다는 뜻처럼 들림
  그리고 사용자가 어떤 웹 인터페이스에서도 네이티브 확장을 쓸 수 없다는 걸 알게 되면, 그게 웹 인터페이스 쪽 사람들의 문제가 된다는 건가 싶음
  사람들이 OSS 대신 프리웨어를 쓰고 싶어 한다면 실망스러울 수는 있어도 정말 문제인지 모르겠음
  답이 있다면 누가 책임져야 하는지 더 명확히 알리는 쪽일 듯함
  오픈소스 업체들은 자신들의 제공물이 오픈소스이면서 열린 생태계라는 점을 더 분명히 하고, 모든 확장이 그런 것은 아니며 Microsoft의 대체 확장은 그렇지 않다는 점을 개발자에게 알려야 함
  주요 확장 프로젝트들이 뜻을 모으면, 마켓플레이스 설명에 vscode-cpptools는 OSI 승인 라이선스가 아니고 검토되지 않은 바이너리 블롭이 많으며, Microsoft가 네이티브 오픈소스 빌드나 웹 서비스용 VSCode 제공에서 재배포를 허용하지 않는다는 식의 안내를 붙일 수 있음
  법적으로나 문화적으로나 Microsoft는 몇몇 OSS 프로젝트가 자기 라이선스 조건을 Microsoft 조건과 비교했다는 이유로 마켓플레이스 접근을 막고 싶지 않을 것임
  Apple도 지금 마켓플레이스 소송을 겪고 있고, Microsoft는 마켓플레이스나 또 다른 반독점 소송을 원하지 않을 것임

  • 간단한 예를 들면, 공개 함수 하나로 된 API를 만들고 그 API를 닫힌 소스 라이선스의 바이너리로 컴파일함
    그런 다음 공개 함수 하나짜리 다른 API를 만들고, 그 함수는 그 라이브러리 바이너리로 extern 호출만 함
    두 번째 API를 GitHub에 MIT 라이선스로 올리고 오픈소스라고 선언함
    넓게 보면 소프트웨어 기능의 100%가 닫힌 소스 컴파일 바이너리 안에 있다면, 그것을 오픈소스라고 부르는 건 허위 광고여야 하느냐는 문제임
    다시 말해 누군가 착취적인 이유로 오픈소스의 의도를 넘어설 때 누가 선을 긋느냐의 문제임
    cpptools 기능이 100% 닫혀 있는지는 모르지만, 실제로는 MIT 라이선스라고 되어 있는 저장소 안에서 동의해야 하는 다른 라이선스가 세 개 더 있음

• 실제 요점이 뭔지 알아내는 데 너무 많은 글을 읽어야 하고, “분열된 생태계”라는 개념이 설명 없이 여러 번 나옴
  “분열시키도록 설계된 파리지옥” 같은 표현은 도대체 무슨 뜻인지 모르겠음
  VS Code는 Microsoft에서 무료로 내려받아 쓸 수 있는 IDE이지, Microsoft가 통제하지 않는 마법 같은 오픈소스 플랫폼이나 생태계가 아니라 제품임
  모두가 “범용” 개발자 서비스를 만들고 싶어 하지만 정작 IDE를 만들거나 자금을 대려 하진 않거나, 너무 어렵거나 한 것 같음
  그건 Microsoft 잘못이 아님

• Microsoft를 옹호하려는 건 아니지만, 거대한 코드베이스를 무료로 제공했고 그 위에 대부분 무료인 제품을 만든 것임
  포크하면 Microsoft 서버에 접근하지 못할 뿐인데, 그 정도면 충분히 공정하지 않나 싶음
  그리고 Monaco는 압도적으로 좋은 편집기라서 프런트엔드들이 쓰는 것임. 예전에는 CodeMirror나 Ace가 최선일 때 그것들을 설치했음
  Monaco 생성 뒤에 거대한 마스터플랜이 있었다기보다는, 오히려 독립 프로젝트로 만들면 수많은 웹 UI가 가능해진다는 기회를 본 것에 가까워 보임

• “앞으로 만들어지는 소프트웨어 개발 도구의 미래가 완전히 닫혀 있는데, 일부 구성요소가 OSI 정의를 만족한다는 이유로 사람들은 큰 그림을 놓치고 괜찮다고 여긴다”는 지점이 매우 큰 문제임
  특히 VC 투자를 받은 여러 회사가 오픈소스라는 용어를 너무 느슨하게 쓰면서 언어와 의미, 오픈소스 운동의 정신까지 나쁘게 바꾸고 있음
  YC도 오픈소스라고 주장하지만 그 정신은 전혀 따르지 않는 회사들을 여럿 지원하고 있음

  • 문제는 회사들이 그렇게 한다는 것보다 사용자와 개발자들이 별로 신경 쓰지 않거나 그런 우려를 공유하지 않는다는 데 있음
    정신이나 윤리 같은 도덕론은 그리 관련성이 크지 않음
    중요한 건 소프트웨어 라이선스가 법률 문서이고, 그 해석이 의미를 갖는 곳은 법정이라는 점임
    VS Code 관련 소송이 많아 보이지 않고, Microsoft는 그 부분을 대체로 정리해 두는 편임
    법적 의미에서는 VS Code가 충분히 안전해 보임. 일부 확장이 OSS 라이선스가 아니거나 아예 닫힌 소스인 건 맞지만, 그게 싫으면 쓰지 않으면 됨
    더 나아가 직접 오픈소스를 만들어 고치면 됨. 오픈소스는 권리가 아니라 제작자의 재량으로 주어지는 특권이지, 요구할 수 있는 것이 아님
    VS Code는 많은 OSS 구성요소를 포함한 닫힌 소스 제품이고, 그 구성요소가 많아서 완전 OSS인 VS Codium도 존재함
    그 OSS 구성요소들 중 다수는 다른 제품에서도 쓰이고, 일부는 완전히 오픈소스임
    VS Code 생태계의 가치는 이런 구성요소와 제품 생태계가 번성하게 한다는 데 있음

• 누구도 VS Code를 공짜로 받을 자격은 없음. 사실 어떤 것도 공짜로 받을 자격은 없음
  대안은 비대해진 상용 IDE에 돈을 내는 것임
  VS Code는 괜찮고, 범용적이며, 무료이고, 포크할 수 있을 만큼은 열려 있음
  사람들은 이것이 공학적으로 놀라운 산물이라는 점을 잊음. 코드를 들여다보면 공짜로 나오는 수준이 아님
  Microsoft든 어떤 회사든 누구에게도 무료로 빚진 것은 없고, 이런 권리의식은 제어될 필요가 있음

  • 맞음, 차라리 가격표를 붙이면 됨. 여기 사람들도 VSCode에서 충분한 효용을 얻으니 돈을 낼 것임
    문제는 무료 제공물이 사실상 법적 책임과 상한 없는 금전 책임의 늪에 빠뜨리도록 설계됐을 때임
    특히 VSCode처럼 일회성 구매가 아니고 확장과 업데이트를 통해 Microsoft에 계속 의존해야 하는 서비스에서는 더 그렇고, 실제로 그렇게 설계돼 있음
    한 번 깔끔하게 지불하고 끝내는 쉬운 선택지를 만들지 않고, 사용자의 저항 정도에 따라 장기적으로 모호한 금액을 뽑아내는 쪽을 택한 것임
  • JetBrains 제품은 가치가 있어서 여러 해 돈을 냈음. Eclipse 기능과 비교하면 훨씬 앞서 있었고, 그건 돈 낼 만했음
    오픈소스에 대해서도 늘 말하지만, 큰돈이 뒤에 없는 프레임워크를 채택하는 데는 회의적임
    임의의 인터넷 천재 엔지니어 변덕에 의존하는 건 위험함
    Microsoft는 VSCode로 돈을 벌 것임. Google이 Chrome으로 돈을 버는 것처럼 직접적이지 않을 뿐임
  • 정말 공학적으로 놀라운가? 비대한 브라우저 기술과 냅킨에 설계한 듯한 언어로 겨우 기능하는 IDE를 만든 건, 아이스크림 막대와 껌으로 1마일짜리 보행자 다리를 지은 것만큼 “인상적”이라고 봄

• OSS는 훌륭하다고 생각하지만, 내가 VS Code를 쓰는 이유는 그게 아님
  Eclipse 같은 괴물이 아닌, 쓸 만한 편집기가 필요하다는 문제를 해결해 줬기 때문에 씀
  이 영역에는 Sublime 같은 다른 선택지도 있지만, VS Code가 항상 가장 덜 방해되는 느낌이었음
  이전에 비슷한 Adobe Brackets도 있었지만 어쩐지 매우 느리고 버그가 많았음
  OSS 열성가라면 글의 지적은 타당함. 하지만 결국 소스 코드는 있고, 원한다면 자기 마켓플레이스도 운영할 수 있음
  시간과 돈이 들지만 그 아이디어를 믿는다면 거대 기업에 의존하지 말고 투자해야 함
  가질 수 없는 독점 확장이 있다면 아쉽지만, 누군가 OSS 버전을 만들 수도 있음
  전반적으로 글에는 동의하지만, Microsoft가 오픈소스에 대한 신념 때문에 이렇게 한다는 환상은 없고, 최악의 경우 다른 선택지가 있으니 괜찮음