구글은 어떻게 전사 IDE를 사실상 하나로 모았나

‘공통 IDE’는 처음엔 말도 안 되는 얘기였음

• 2011년 구글 내부에서도 “모든 구글러가 쓸 좋은 공통 IDE를 만들 수 있나?”라는 질문이 나왔음

  • 당시 Jeff Dean의 답은 사실상 “아니오”였음
  • 개발자마다 편집기 취향이 너무 다르고, 어떤 장단점을 중요하게 보는지도 다르니 공통 에디터를 합의하려는 건 불행의 레시피라는 입장이었음

• 실제로 오랫동안 구글 엔지니어들은 각자 원하는 IDE를 썼음

  • 겉으로 보면 문제 없어 보임. 코드만 잘 나오면 동료가 어떤 편집기를 쓰든 상관없으니까
  • 하지만 회사 생산성 관점에서는 같은 통합 기능을 IDE마다 반복해서 만들어야 했음
  • Bazel 지원, Starlark 도구, 포매터, 코드 검색 연동 같은 것들이 계속 중복 구현됐음

• 구글의 내부 문화가 이 파편화를 어느 정도 버티게 해줬음

  • 엔지니어들이 20% 시간이나 피어 보너스 문화 속에서 필요한 도구를 자연스럽게 만들고, 다른 팀이 발견해서 기여하는 흐름이 있었음
  • 중요해진 프로젝트는 나중에 공식 팀이 붙기도 했고, IntelliJ 통합 전담팀도 2015년쯤 생겼다고 함

모노레포 규모가 로컬 IDE의 전제를 깨뜨림

• 문제는 구글의 메인 모노레포 google3가 일반적인 IDE 가정과 너무 달랐다는 점임

  • 전통적인 IDE는 소스 코드, 빌드 메타데이터, 인덱싱, 분석이 로컬에서 돌아간다고 가정함
  • 구글 규모에서는 그 전제가 흔들림. 코드베이스가 너무 크고, 내부 도구도 너무 많기 때문임

• 그래서 2013년쯤 웹 기반 IDE인 Cider가 등장함

  • 이름은 Cloud IDE에서 따온 말장난에 가까움
  • 구글은 코드 리뷰, 코드 검색, 내부 도구가 이미 웹 기반인 회사였고, Chromebook을 쓰는 문화도 있어서 브라우저에서 바로 파일을 고치는 흐름이 꽤 자연스러웠음

• Cider는 처음엔 개발자용 IDE라기보다 빠른 수정 도구에 가까웠음

  • 기술 문서 작성자들이 마크다운 파일의 오타를 고칠 때 많이 썼음
  • 클릭 한 번으로 변경을 보내고, 승인되면 자동 병합까지 할 수 있었는데 당시엔 꽤 신선한 경험이었다고 함

• 전환점은 코드 완성 지원이 붙으면서 왔음

  • Cider는 가벼운 클라이언트였고, 진짜 마법은 전체 코드베이스를 색인하는 백엔드에서 일어났음
  • 웹페이지를 열면 이미 준비된 코드 인텔리전스 데이터를 가져와 쓰는 구조였음

sequenceDiagram
    participant 개발자
    participant Cider브라우저
    participant 코드인텔리전스백엔드
    participant 구글모노레포
    개발자->>Cider브라우저: 파일 열기
    Cider브라우저->>코드인텔리전스백엔드: 자동완성·참조 정보 요청
    코드인텔리전스백엔드->>구글모노레포: 해당 시점의 코드 그래프 조회
    구글모노레포-->>코드인텔리전스백엔드: 타입·참조·히스토리 데이터 반환
    코드인텔리전스백엔드-->>Cider브라우저: IDE 기능용 분석 결과 제공
    Cider브라우저-->>개발자: 자동완성·정의 이동·참조 표시

• 여기서 어려운 부분은 단순히 “전체 코드를 색인한다”가 아님
  • 코드 인텔리전스는 식별자와 타입, 참조 관계를 연결한 거대한 언어 그래프를 만들어야 함
  • 구글 코드베이스는 초당 여러 커밋이 들어오기 때문에 이 그래프를 계속 갱신해야 함
  • 게다가 사용자는 동료가 방금 머지한 최신 코드가 아니라, 본인이 마지막으로 동기화한 시점의 그래프에 로컬 변경분을 더한 결과를 보고 싶어 함

Cider V는 VSCode를 프론트엔드로 삼음

• Cider 백엔드는 구글 특화 문제를 잘 풀고 있었지만, 프론트엔드는 한계가 있었음

  • 빠른 수정에는 좋았지만, 본격 IDE와 경쟁하기엔 기능과 사용성이 부족했음
  • 그래서 2020년 작성자가 팀의 테크 리드 중 한 명으로 합류했을 때, Cider의 미래 방향이 논의됐고 VSCode 프론트엔드를 쓰기로 결정함

• VSCode 선택은 꽤 자연스러웠음

  • 이미 IDE 시장에서 지배적인 위치였고, 언어 중립적이며, 확장 가능하고, 웹 기반으로도 잘 맞았음
  • 기존 Cider 기능 요청 상당수는 VSCode에서는 이미 해결된 문제였음

• 더 큰 장점은 확장 시스템이었음

  • Cider 팀이 모든 기능 요청의 병목이 되는 대신, 구글 내부 팀들이 자기 워크플로에 맞는 확장을 직접 만들 수 있게 됨
  • 이후 2년이 지나자 약 100개의 내부 확장이 개발되고 있었다고 함

• 그래도 전환은 오래 걸렸음

  • 프론트엔드 팀에 10명 넘는 엔지니어가 있었는데도 Cider의 완전한 후속 제품을 만드는 데 몇 년이 걸림
  • 2021년 오픈 베타는 5,000명의 엔지니어가 썼지만, 버전 관리, 코드 리뷰 통합, Cider 백엔드 기반 자동완성·리팩터링, 확장 배포·업데이트 구조까지 다듬어야 했음

• 사용자 전환에서 가장 어려운 건 기능 목록보다 “손에 익은 흐름”이었음

  • 기존 Cider 사용자들은 작은 동작 하나까지 똑같기를 기대했음
  • 클릭 한 번이 늘어나거나 워크플로가 아주 조금 바뀌어도 채택을 막는 요소가 됐음
  • 심지어 색상 테마도 엄청난 토론거리가 됐다고 함. IDE 얘기는 늘 그렇다

표준 IDE가 되자 레버리지가 생김

• 2023년에는 google3 개발의 80%가 Cider V에서 이뤄졌음

  • 완전한 강제 표준은 아니었지만, 사실상 구글 메인 코드베이스의 지배적 IDE가 된 셈임
  • 가장 큰 유인책은 회사 내부 도구와의 통합이었음. 버전 관리 지원과 코드 리뷰 댓글을 에디터 안에 인라인으로 보여주는 기능이 특히 강했다고 함

• 단일 플랫폼의 부작용이 오히려 장점으로 바뀜

  • 사용자가 한 도구에 모이면, 그 도구에 투자하는 한 번의 개선이 훨씬 많은 엔지니어에게 영향을 줌
  • 사내 팀들도 공통 확장 플랫폼 위에서 자기 팀의 워크플로를 직접 개선할 수 있음

• AI 기능을 넣는 데도 공통 IDE가 큰 이점이 됨

  • 2023년 경영진이 팀들에 AI 기능 통합을 더 밀어붙였고, 코드 리뷰 댓글을 머신러닝으로 해결하는 기능이나 문맥 인식 붙여넣기(Smart Paste), AI 코드 완성 같은 기능이 나옴
  • IDE가 하나의 확장 가능한 플랫폼이면 이런 기능을 배포하고 실험하는 속도가 훨씬 빨라짐

• 결론은 꽤 단순함. 표준 도구는 레버리지를 만든다는 것임

  • 물론 구글 같은 투자는 극소수 회사만 정당화할 수 있음
  • 그래도 대규모 조직에서 개발자 도구 표준화가 단순한 통제가 아니라 생산성, 확장성, AI 도입의 기반이 될 수 있다는 사례로는 굉장히 강함

기술 맥락

• 구글이 처음부터 IDE를 하나로 강제하지 않은 건 현실적인 선택이었어요. 개발자 편집기 취향은 생산성 도구이면서 동시에 습관이라, 억지로 바꾸면 반발이 크거든요. 그래서 초반에는 각 IDE에 필요한 통합을 따로 붙이는 방식으로 버틴 거예요.

• 그런데 google3 같은 초대형 모노레포에서는 로컬 IDE가 모든 걸 감당하기 어렵다는 문제가 생겨요. 코드 검색, 타입 정보, 참조 관계, 빌드 메타데이터가 너무 커지고 너무 자주 바뀌니까요. 그래서 Cider는 브라우저를 가벼운 클라이언트로 두고, 무거운 코드 인텔리전스는 백엔드에서 처리하는 구조를 택했어요.

• VSCode를 프론트엔드로 고른 이유도 직접 에디터를 계속 만들 필요가 줄어들기 때문이에요. 이미 성숙한 편집 경험과 확장 생태계가 있으니, 구글은 자기들만의 문제인 모노레포 백엔드와 내부 도구 통합에 더 집중할 수 있었던 거죠.

• 표준 IDE의 진짜 효과는 사용자가 모인 뒤에 나와요. 사내 팀들이 각자 확장을 만들 수 있고, AI 코드 완성이나 코드 리뷰 자동 처리 같은 기능도 한 플랫폼에 얹어서 넓게 배포할 수 있거든요. 그래서 이 사례는 ‘도구 통일’보다 ‘공통 플랫폼을 통한 투자 효율’ 얘기에 더 가까워요.