구조와 기능
zed는 Rust로 작성된 네이티브 코드 에디터로, 저장소는 245개 크레이트(crates/)로 잘게 쪼개져 있다. 실측 기준 텍스트 파일 4,025개·1,790,496줄 중 Rust가 1,946개 파일·1,623,288줄로 전체의 약 90.7%를 차지하고, 나머지는 빌드 설정(toml, 13,529줄)과 스크립트(py, 13,276줄), Tree-sitter 쿼리(scm, 9,524줄), 프로토콜 정의(proto, 6,546줄), WASM 확장 인터페이스(wit, 4,094줄) 등으로 이어진다. scm·wit·proto 세 확장자가 상위권에 든다는 것 자체가, 이 프로젝트가 단순 텍스트 편집기가 아니라 구문 분석·원격 프로토콜·플러그인 인터페이스를 모두 자체 정의하는 플랫폼형 코드베이스라는 걸 실측으로 보여준다.
클론해 직접 읽어보면(수치는 아니므로 실측 JSON 밖 내용) crates/text/src/text.rs에 Operation enum이 Edit/Undo 두 변형으로 정의돼 있고, EditOperation은 clock::Lamport 타임스탬프와 clock::Global 버전 벡터를 들고 다닌다. 이건 zed의 텍스트 버퍼가 처음부터 다중 사용자 실시간 협업을 전제로 한 CRDT 구조로 설계됐다는 뜻이다. crates/collab, crates/collab_ui 크레이트가 별도로 존재하는 것도 이 구조와 맞물린다.
확장 생태계는 crates/extension, extension_api, extension_host, extension_cli, extensions_ui 다섯 크레이트로 나뉘어 있고, extension_api/wit/ 아래에 since_v0.0.1부터 since_v0.8.0까지 버전별 WIT 인터페이스 디렉토리가 쌓여 있다. WASM 기반 확장이 API 버전 호환성을 인터페이스 파일 단위로 관리한다는 뜻이고, 저장소 루트의 extensions/(7개 항목, glsl·html·proto 등)는 실제 예시 확장 코드다.
하이라이트
Lamport CRDT로 짠 편집 히스토리. crates/text/src/text.rs의 Operation 정의:
``rust pub enum Operation { Edit(EditOperation), Undo(UndoOperation), } pub struct EditOperation { pub timestamp: clock::Lamport, pub version: clock::Global, pub ranges: Vec<Range<FullOffset>>, pub new_text: Vec<Arc<str>>, } ``
편집을 절대 위치가 아니라 타임스탬프+버전 벡터로 표현해 순서가 뒤섞여 도착해도 수렴하게 만드는 전형적 CRDT 설계다. 협업 에디터를 직접 만들 계획이 있다면 가장 먼저 읽어볼 파일이다.
245개 크레이트 + 47개 CI 워크플로우로 버티는 빌드 규모. 실측상 커밋 수가 shallow clone 상한(1,000)을 그대로 채웠다는 건 최근 90일 활동량이 그 이상이라는 뜻이고, 이 정도 변경 빈도를 CI 워크플로우 47개로 감당하고 있다는 것 자체가 대규모 Rust 모노레포 CI 설계 사례로 참고할 만하다. 다만 각 워크플로우의 역할(빌드/테스트/린트 분포)은 이번 실측 범위 밖이라 추가 확인이 필요하다.
WIT 기반 확장 인터페이스의 버전 계층. crates/extension_api/wit/가 since_v0.0.1부터 since_v0.8.0까지 디렉토리를 나눠 하위 호환을 관리한다. 플러그인 API를 깨지 않고 진화시키는 문제를 겪어본 프로젝트라면 이 구조를 그대로 참고할 수 있다.
주의점
라이선스는 저장소 루트에 LICENSE-APACHE와 LICENSE-GPL(GPLv3) 두 파일이 함께 있는 이중 구성이다. 실측 JSON의 meta.license 필드에는 "Copyright 2022 - 2025 Zed Industries, Inc."라는 저작권 고지 문자열만 잡혔고 SPDX 식별자는 프로브가 추출하지 못했다. 크레이트별로 어느 라이선스가 적용되는지는 이번 실측 범위 밖이라, 코드를 가져다 쓸 계획이면 반드시 각 크레이트의 라이선스 파일을 직접 확인해야 한다.
largestFile이 crates/editor/src/editor_tests.rs 45,930줄이라는 점도 짚어둘 만하다. 테스트 파일 한 개가 이 정도면 에디터 코어의 회귀 테스트가 매우 촘촘하다는 신호인 동시에, 코어 로직 자체의 응집도가 높아 부분만 떼어 재사용하기는 어려운 구조라는 뜻이기도 하다(추정). shallow clone(depth 1000) 기반 실측이라 commitCount·commitsLast90d는 하한값이며, 실제 히스토리는 이보다 길다.
실측 정보
- 분석 기준 커밋
- b1a7ef0c (shallow, depth 1000)
- 90일 내 커밋 수
- 1,000+ (클론 하한값, 실제 더 많음)
- 기여자 수
- 335명
- 원격 태그 수
- 1,466개
- 텍스트 파일 / 총 라인
- 4,025개 / 1,790,496줄
- Rust 파일 / 라인
- 1,946개 / 1,623,288줄 (전체 LOC의 약 90.7%)
- 테스트 파일 / CI 워크플로우
- 506개 / 47개
적용점
- P0 · 비용 낮음crates/text/src/text.rs의 Operation/EditOperation/UndoOperation을 읽으면 Lamport 클록 기반 CRDT를 실전 코드로 배울 수 있다. 텍스트 편집 동기화를 직접 설계할 일이 있다면 참고 가치가 크다.
- P1 · 비용 중간crates/extension_api/wit/의 WIT 인터페이스(버전별 since_v0.0.1~since_v0.8.0 디렉토리로 하위호환 관리)는 WASM 플러그인 시스템의 버전 관리 패턴으로 참고할 만하다.
- P2 · 비용 높음245개 크레이트로 나뉜 워크스페이스 구조 자체를 벤치마크하려면 Cargo.toml 의존 그래프를 따로 뜯어봐야 한다. 이 리포트의 실측 범위 밖이다.
◆ 도입 후보실측만 봐도 규모와 활동성이 이례적이다. depth 1000 shallow clone인데 90일 커밋 수가 그 상한(1,000)을 그대로 채웠다는 건 실제 90일 커밋이 최소 그 이상이라는 뜻이고, 기여자 335명·원격 태그 1,466개는 단발성 실험 리포가 아니라 정기 릴리스를 도는 프로덕션 프로젝트라는 신호다. 코드 구조도 뒷받침한다. crates/text의 Operation enum이 Lamport 타임스탬프 기반 CRDT로 편집을 표현해 실시간 협업 에디터의 핵심을 코드 수준에서 확인할 수 있고, extension_api의 WIT 인터페이스(4,094줄, 77개 파일)는 WASM 샌드박스 확장 시스템이 문서만이 아니라 실제로 구현돼 있음을 보여준다. 다만 largestFile이 crates/editor/src/editor_tests.rs 45,930줄이라는 점은 에디터 코어 자체의 응집도가 매우 높다는 뜻이라 신규 기여자의 초기 진입 비용은 낮지 않을 것으로 보인다(코드는 읽었지만 이 판단 자체는 추정). 그래도 도입/참고 후보로는 충분하다: 크로스플랫폼 네이티브 에디터를 Rust로 어떻게 설계하는지, 편집-협업-확장을 하나의 데이터 모델로 엮는 실전 사례로서 값이 크다.
원문 README
아래는 zed-industries/zed 저장소의 README 원문입니다(GitHub 렌더, 수집 시점 기준). 저작권은 원 프로젝트에 있으며 원 저장소의 라이선스를 따릅니다. GitHub에서 보기
README 전문 펼치기
Welcome to Zed, a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.
On macOS, Linux, and Windows you can download Zed directly or install Zed via your local package manager (macOS/Linux/Windows).
Other platforms are not yet available:
See CONTRIBUTING.md for ways you can contribute to Zed.
Also... we're hiring! Check out our jobs page for open roles.
Zed source code is licensed primarily under GPL-3.0-or-later, with Apache-2.0 components where marked.
License information for third party dependencies must be correctly provided for CI to pass.
We use cargo-about to automatically comply with open source licenses. If CI is failing, check the following:
- Is it showing a
no license specified error for a crate you've created? If so, add publish = false under [package] in your crate's Cargo.toml.
- Is the error
failed to satisfy license requirements for a dependency? If so, first determine what license the project has and whether this system is sufficient to comply with this license's requirements. If you're unsure, ask a lawyer. Once you've verified that this system is acceptable add the license's SPDX identifier to the accepted array in script/licenses/zed-licenses.toml.
- Is
cargo-about unable to find the license for a dependency? If so, add a clarification field at the end of script/licenses/zed-licenses.toml, as specified in the cargo-about book.
Sponsorship
Zed is developed by Zed Industries, Inc., a for-profit company.
If you’d like to financially support the project, you can do so via GitHub Sponsors.
Sponsorships go directly to Zed Industries and are used as general company revenue.
There are no perks or entitlements associated with sponsorship.
판정에 대한 반론, 도입 경험, 정정 제보를 환영합니다. GitHub 계정으로 참여합니다.
