Google의 주요 모노레포에서 IDE가 어떻게 파편화된 생태계에서 Cider와 VSCode 기반의 보다 통일된 플랫폼으로 발전했는지 돌아본다.
이전에 저는 Google의 주요 코드베이스가 코드베이스의 확장을 가능하게 하기 위해 엄격한 도구와 규약을 어떻게 강제하는지 설명한 적이 있습니다. 오랫동안 여기에 눈에 띄는 예외가 하나 있었는데, 바로 IDE였습니다.
맥락: 저는 2011년부터 2024년까지 Google에서 일했습니다. 일부 정보는 대략적일 수 있으며, 제보가 있으면 업데이트하겠습니다. 이 블로그 글은 Google의 주요 모노레포(google3)에 초점을 맞춥니다.
많은 회사와 마찬가지로 Google의 엔지니어들도 자신이 선택한 IDE를 사용할 수 있었고, 그 결과 상당한 파편화가 생겼습니다. 2011년에는 몇몇 최고참 엔지니어들에게 이런 질문이 던져졌습니다. “모든 Googler를 위한 좋은 통합 IDE를 만들 방법이 있을까?” 대답은 본질적으로 “아니오”였습니다. 그중 Jeff Dean은 다음과 같이 답했습니다.
“개발자 집단 전체가 공통 편집기에 동의하도록 하려는 것은 불행으로 가는 지름길입니다. 여기서 무엇이 중요한지에 대해 사람마다 의견이 다르고, 서로 다른 시스템의 장단점도 사람마다 다르게 평가합니다. 결국 그렇게까지 중요한 문제는 아닙니다.”
이것이 여러 해 동안 지배적인 의견이었습니다. 결국 동료들이 어떤 IDE를 쓰는지는, 그들의 코드가 좋기만 하다면 중요하지 않으니까요. 하지만 저는 Google에서 12년 동안 개발자 도구를 다루며 일했고, 가끔 이 점이 궁금하곤 했습니다.
회사의 생산성 관점에서 보면, 각 엔지니어가 편집기를 설정하는 데 너무 많은 시간을 쓰는 것은 바람직하지 않습니다. 엔지니어들이 서로 다른 IDE를 사용하더라도 유용한 통합 기능은 결국 모든 곳에서 다시 구현되어야 했습니다. Bazel 지원, Starlark 도구, 코드 포매터, 코드 검색 통합 등이 그 예입니다. Google의 내부 문화는 이를 감당 가능하게 만들었습니다. 엔지니어들은 종종 자생적으로 도구 프로젝트를 시작했고, 다른 사람들은 공유 코드베이스를 통해 그것들을 발견하고 기여했습니다. 이런 종류의 기여는 일반적으로 장려됩니다(20% 시간과 동료 보너스를 통해서입니다). 중요한 프로젝트는 결국 공식적으로 인력을 배정받게 됩니다. 예를 들어 IntelliJ 통합 전담 팀은 2015년 무렵에 꾸려졌습니다.
어떤 사람들은 왜 여기에 전담 팀 전체가 필요한지 궁금할지도 모릅니다. 처음부터 IDE가 충분히 좋지 않았던 걸까요? 이유의 일부는 Google이 고유한 도구 집합을 가지고 있고, 그것들을 IDE에 잘 통합해 주면 엔지니어들이 훨씬 더 생산적이기 때문입니다. 하지만 또 일부 문제는 모노레포의 엄청난 규모 자체에서 비롯되었습니다. 전통적인 IDE는 소스 코드, 빌드 메타데이터, 인덱싱, 분석이 모두 로컬에서 이루어진다고 가정했습니다. Google 규모에서는 그 가정이 무너지기 시작합니다.
2013년 무렵(?), 제가 예상하지 못했던 일이 벌어졌습니다. 몇몇 사람들이 Cider라는 이름의 웹 기반 편집기를 만들기 시작한 것입니다. 이 이름은 “Cloud IDE”를 가리키며, 더 기억하기 쉬운 이름을 만들기 위해 끝에 “r”을 붙인 것입니다.
대부분의 도구가 웹 기반이고, 사람들이 코드 리뷰를 하거나 Code Search로 코드베이스를 탐색하기 위해 브라우저에서 많은 시간을 보내는 회사에서, 그리고 Chromebook을 사용하는 회사에서 브라우저로 파일을 빠르게 편집할 수 있는 방법이 있다는 것은 실제로 꽤 말이 됩니다.
하지만 저를 놀라게 한 것은 Cider가 결국 엔지니어들 전반에 걸쳐 인기를 얻게 되었다는 점입니다. 처음에는 버전 관리를 다루지 않고도 마크다운 파일을 편집하고 싶어 하는 기술 문서 작성자들이 주로 사용했습니다. 오탈자를 고치는 워크플로는 매우 효율적이었습니다. 한 번 클릭하면 풀 리퀘스트를 보낼 수 있었고, 승인되면 자동으로 머지되도록 하는 옵션도 있었습니다. 오늘날에는 GitHub에도 이런 종류의 기능이 있지만, 당시에는 제게 꽤 새롭게 느껴졌습니다.
시간이 지나면서 팀은 점점 더 많은 개발자 지향 기능을 추가했습니다. 전환점은 language-server protocol을 통해 코드 완성을 지원하게 되었을 때 찾아왔습니다.
Cider는 전통적인 IDE보다 훨씬 빠르게 열리는 가벼운 클라이언트였습니다. 모든 마법은 전체 코드베이스를 인덱싱하는 백엔드에서 일어났고, 덕분에 누군가 웹페이지를 열 때마다 모든 데이터가 준비되어 있었습니다.
코드 인텔리전스는 각 식별자를 그 타입 및 참조와 연결해야 합니다. 이는 거대한 언어 그래프를 형성하며, 모든 커밋마다 업데이트되어야 합니다. 그런데 코드베이스에는 매초 수많은 커밋이 들어옵니다. 하지만 IDE는 과거 데이터에도 접근할 수 있어야 합니다. 제가 어떤 프로젝트에서 작업 중인데 동료가 자신의 코드를 머지했다면, 저는 그 변경 사항을 즉시 받아오고 싶지 않을 수 있습니다. 그러므로 제 편집기는 제 마지막 동기화 시점에 해당하는 그래프를 사용해야 하고… 물론 제 로컬 변경 사항도 거기에 덧붙여져야 합니다.
이런 기능 덕분에 Cider의 인기는 특정 집단 사이에서 계속 높아졌습니다. 예를 들어 Go 개발자들을 전환시키는 것은 Java 개발자들보다 훨씬 쉬웠습니다(후자는 훨씬 더 고급 편집기를 기대했기 때문입니다). 하지만 10억 개 파일에 걸쳐 검색하고 교차 참조를 할 수 있는 즐거움은 분명합니다.
백엔드에 대한 투자는 정당화될 수 있었습니다. 그것은 Google 특유의 문제를 해결하고 있었고, 이를 대체할 좋은 대안도 없었습니다. 하지만 프런트엔드는 꽤 제한적으로 느껴졌습니다. 빠른 수정에는 좋았지만, 진짜 IDE들과 경쟁할 수는 없었습니다.
방향이 바뀐 것은 2020년, 제가 기술 리드 중 한 명으로 팀에 합류했을 때였습니다. 당시 Cider는 회사에서 지배적인 IDE였고, 그 미래에 대한 질문이 제기되었습니다. Cider에서 VSCode 프런트엔드를 사용하기로 결정되었습니다. 이는 자연스러운 선택이었습니다. VSCode는 이미 IDE 환경을 지배하고 있었고, 언어에 구애받지 않았으며, 확장 가능했고, 웹을 위해 만들어졌기 때문입니다.
VSCode 프런트엔드로 전환하면서 우리는 성숙한 편집기, 방대한 확장 생태계, 그리고 수년에 걸쳐 축적된 기존 기능들을 물려받았습니다. Cider의 많은 기능 요청은 VSCode에서는 이미 해결된 문제였습니다. 더 중요한 것은, 확장 시스템이 회사 전반의 팀들을 열어 주고 Cider 팀이 모든 일의 병목이 되는 상황을 없애 줄 것이라는 점이었습니다.
2022년의 Cider V 스크린샷
프런트엔드 팀에 12명가량의 엔지니어가 있었음에도, Cider의 완전한 후속작을 만드는 데는 몇 년이 걸렸습니다. 2021년에는 오픈 베타를 5000명의 엔지니어가 사용했지만, 모든 것을 통합하고 경험을 다듬기 위해서는 여전히 많은 작업이 남아 있었습니다. 팀은 버전 관리를 지원해야 했고, 코드 리뷰 도구를 통합해야 했으며, Cider 백엔드를 사용해 코드 완성과 리팩터링 기능을 제공해야 했고, 확장이 배포되고 업데이트되는 방식을 재설계해야 했습니다. 그 외에도 할 일이 많았습니다.
많은 사용자는 기존 Cider 편집기에 강한 애착이 있었고, 모든 작은 세부 사항이 Cider V에서도 똑같기를 기대했습니다. 워크플로의 작은 변화나 여기저기서 클릭이 한 번 더 필요한 것만으로도 어떤 사용자들에게는 도입의 장애물이 될 수 있습니다. 그래서 프로젝트의 다듬기 단계에는 수개월의 반복 작업이 필요했습니다. 심지어 색상 구성표조차 터무니없을 정도로 많은 논의를 불러왔습니다. Joshua Bloch가 2011년에 관찰했듯이, “프로그래밍 언어보다 더 종교적인 열정을 불러일으키는 유일한 것은 텍스트 편집기와 IDE다.”
VSCode 엔지니어들과의 상호작용, 그리고 우리가 VSCode에 다시 기여한 변경 사항들에 대해서도 쓸 수 있겠지만, 이 블로그 글은 이미 충분히 깁니다. 언젠가 그것에 대해 더 써 보겠습니다. 다만 이렇게 말해 둘 수는 있겠습니다. 우리는 로컬 포크를 유지해야 했고, 매달 업데이트해야 했으며, 가능한 한 로컬 해킹을 줄이고 업스트림 코드와 정렬되도록 노력했습니다.
코드 리뷰 통합을 위한 디자인 탐색, 2022년
저는 이 글을 “모든 Googler를 위한 통합 IDE”라는 질문으로 시작했습니다. 완전히 그렇게 되지는 않았지만, 2023년에는 Google의 주요 코드베이스에서 이루어지는 개발의 80%가 Cider V에서 일어났습니다(그리고 그 수치는 계속 증가하고 있었습니다).
각 IDE에는 장단점이 있지만, Cider는 뛰어난 버전 관리 지원과 리뷰어의 코멘트가 편집기 안에 인라인으로 표시되는 코드 리뷰 통합 같은 회사 도구와의 최고의 통합을 제공함으로써 사용자를 끌어들였습니다.
제가 가장 흥미롭게 느낀 것은 대부분의 사용자가 같은 도구를 사용한다는 사실이 낳은 부수 효과였습니다. 이는 우리가 그 도구에 더 많은 자원을 투자할 수 있다는 뜻이었습니다(각 변경의 영향력이 더 커지기 때문입니다). 저는 IDE 확장성의 기술 리드였고, 곧 회사 전반의 팀들이 연락해 와서 자신들의 구체적인 워크플로를 개선하기 위한 확장을 직접 개발하기 시작했습니다. 2년 후에는 내부 확장 약 100개가 개발되고 있었습니다. 이는 이전에는 실현 불가능했던 많은 시나리오를 가능하게 했습니다.
2023년에는 경영진이 모든 팀에 더 많은 AI 기능을 통합하라고 밀어붙였습니다. 그 결과 머신 러닝으로 코드 리뷰 코멘트 해결하기, 붙여넣은 코드에 맥락 인지형 조정을 적용하는 Smart Paste 같은 멋진 기능들이 등장했습니다. 그리고 물론 AI 코드 완성도 있었습니다.
점점 더 많은 AI 기능이 IDE에 통합될수록, 단일하고 확장 가능한 플랫폼을 갖는 이점은 더욱 분명해집니다. 물론 이것은 매우 비용이 많이 들었고, 이런 종류의 작업을 정당화할 수 있는 회사는 극히 드뭅니다. 하지만 저는 “표준” IDE로의 이동이(비록 의무는 아니었다고 해도) 매우 큰 영향을 주었다고 믿습니다.
결국 표준 도구는 지렛대를 만들어 냅니다.
댓글은 닫혀 있지만, 피드백은 환영합니다. Hackernews나 Mastodon에서 이야기할 수 있습니다. 이런 종류의 콘텐츠가 마음에 든다면 RSS로 구독할 수 있습니다. 이메일 알림을 받으려면 Feedrabbit 같은 서드파티 도구를 사용해 보세요.
