Zed 딥다이브
— Rust로 밑바닥부터 GPU에 직접 그린, "사람과 AI가 같은 속도로 함께 코딩하는" 에디터

zed-industries/zed. Atom과 Tree-sitter를 만든 팀이 다시 만든 고성능·멀티플레이어 코드 에디터다. 약 280개의 Rust 크레이트로 짜인 하나의 거대한 작업공간(모노레포)이며, 화면은 브라우저 엔진을 거치지 않고 자체 UI 프레임워크 GPUI가 매 프레임을 GPU에 직접 그린다. 2026년 들어 1.0 정식 출시(2026-04-29)와 함께 AI 에이전트를 에디터 안에 정식으로 들였다. (저장소: zed-industries/zed · 언어 Rust(edition 2024) · 라이선스 GPL-3.0(일부 Apache-2.0) · macOS·Linux·Windows · TrendShift 주간 라이브 멘션 등재)

1프로젝트 한줄 요약

"텍스트 편집의 모든 층을 Rust로 새로 짜서, '느려서 답답한 순간'을 구조적으로 없앤 에디터."

핵심은 "빠름을 기능이 아니라 토대로 삼았다"는 점이다. 만든 사람들은 2010년대 초 Atom(GitHub의 해킹 가능한 에디터, Electron의 출발점)과 Tree-sitter(지금 거의 모든 에디터가 쓰는 코드 구문 분석기)를 만든 팀이다. 그들이 "Atom이 느렸던 이유"를 10년간 곱씹은 끝에, 처음부터 성능을 노리고 Rust로 다시 쓴 결과물이 Zed다.

그리고 2026년의 Zed는 단순한 "빠른 에디터"를 넘어, 사람과 AI 에이전트가 같은 화면에서 함께 일하는 작업대로 방향을 잡았다. 실시간 공동편집(멀티플레이어)이 기본으로 들어 있고, 거기에 AI 에이전트를 표준 규약으로 꽂아 "사람 옆에서 같이 타이핑하는 동료"처럼 쓰게 만들었다. 이 문서는 그 구조를 한 층씩 뜯어본다.

2왜 주목받는가

"빠른 에디터" 자리에 안주하지 않고, 2026년 AI 코딩 흐름의 한복판으로 들어갔다.

Zed는 5년간 매주 빌드를 내놓다가 2026년 4월 29일 1.0을 찍었다. 그런데 화제가 된 건 버전 숫자가 아니라, "네이티브 속도" + "AI 에이전트"를 한 몸에 합친 첫 사례라는 점이다. 핵심 차별점을 하나씩 보자.

① 속도 — 브라우저를 들어내고 GPU에 직접 그린다

경쟁작 대부분은 Electron(브라우저 엔진) 위에 있다. Zed는 자체 UI 프레임워크 GPUI로 Metal(macOS)·DirectWrite/Direct3D(Windows)·wgpu/Vulkan(Linux)에 글자를 직접 올린다. 입력 지연과 프레임 시간을 줄이는 게 설계의 1순위라, 코드에는 아예 ZED_MEASUREMENTS 같은 프레임 시간 측정 스위치가 내장돼 있다.

② AI 에이전트를 "표준 규약"으로 들였다 (ACP)

Zed는 특정 AI 회사에 묶이는 대신, ACP(Agent Client Protocol)라는 공개 규약을 직접 만들어 1.0의 간판 기능으로 내세웠다. 덕분에 Claude 계열 에이전트, Codex, OpenCode 같은 여러 에이전트를 같은 방식으로 에디터에 꽂을 수 있다.

③ 병렬 에이전트 · 터미널 스레드

2026년 4월 22일 Zed는 Parallel Agents(병렬 에이전트)를 내놨다 — 여러 AI 에이전트를 한 창에서 동시에 돌려 각자 코드의 다른 부분을 손보게 하는 기능으로, "네이티브로 병렬 에이전트를 지원한 첫 에디터"로 소개됐다. 이어 5월 20일에는 Terminal Threads가 추가돼, Claude Code 같은 CLI 에이전트를 에디터 사이드바에서 함께 굴릴 수 있게 됐다.

④ 멀티플레이어가 기본 — "구글 문서처럼 같이 코딩"

Zed는 처음부터 실시간 공동편집을 핵심으로 깔았다. 같은 파일에 여러 명이 동시에 커서를 두고 편집하고, 음성·화면 공유까지 붙는다(livekit_client·collab 크레이트). 에디터를 "혼자 쓰는 도구"가 아니라 "팀이 같이 들어오는 공간"으로 본 셈이다.

⑤ 자체 편집 예측 모델 — Zeta2

다음에 칠 코드를 미리 제안하는 edit prediction에 Zed는 Zeta2라는 공개 가중치(open-weight) 모델을 쓴다. 범용 추론보다 "코드 자동완성 속도"에 맞춰 튜닝된 모델이다. 관련 코드는 edit_prediction*·zeta_prompt 크레이트에 모여 있다.

경쟁 구도 한눈에

3기술 스택 전체 지도

"에디터 하나에 OS·그래픽·언어·네트워크·AI가 다 들어간다 — 그걸 전부 Rust로."

Zed의 스택은 "프론트엔드/백엔드"라는 웹 구분이 잘 안 맞는다. 데스크톱 앱이라 UI 층 · 편집 엔진 · 언어 지능 · 협업/네트워크 · AI · 확장으로 나누는 게 자연스럽다. 루트 Cargo.toml(워크스페이스 설정)에서 실제로 끌어다 쓰는 부품들로 지도를 그려 보자.

언어와 UI 층 (화면을 그리는 쪽)

편집 엔진 (글자를 다루는 쪽)

언어 지능 · 디버그 (똑똑함을 붙이는 쪽)

협업 · AI · 확장 (사람·모델·플러그인을 잇는 쪽)

4아키텍처 심화 분석 — 키 입력이 픽셀이 되기까지

"내가 'a'를 누르면, 그 글자가 화면에 찍히기까지 Zed 안에서 무슨 일이 벌어지나."

Zed의 구조를 한 장으로 그리면 이렇게 층층이 쌓인 탑이다. 아래일수록 "원초적인 글자·자료구조", 위일수록 "사람이 보는 화면·협업·AI"다.

핵심 설계 1 — Rope + SumTree: "긴 글을 통째로 들고 있지 않는다"

10만 줄짜리 파일에서 맨 앞에 한 글자를 넣는다고 해 보자. 글 전체가 하나의 긴 문자열이라면, 그 한 글자 때문에 뒤의 모든 글자를 한 칸씩 밀어야 한다 — 끔찍하게 느리다. Zed는 텍스트를 작은 조각으로 쪼개 균형 트리에 담는다. 이게 Rope(로프)이고, 그 밑을 받치는 범용 트리가 SumTree다.

핵심 설계 2 — GPUI: Entity → View → Element

GPUI는 "상태를 담는 그릇(Entity)", "그 상태를 화면으로 바꾸는 규칙(View)", "실제 배치·렌더 단위(Element)" 세 층으로 UI를 만든다. 매 프레임마다 최상위 View의 render()가 호출돼 화면을 다시 구성하고, 결과를 GPU에 넘긴다(즉시 모드). 동시에 상태는 Entity가 오래 들고 있는다(보존 모드) — 그래서 "하이브리드"다.

// GPUI 앱의 가장 작은 뼈대 — README 예시를 단순화
use gpui::*;

fn main() {
    // OS에 맞는 창·글꼴 백엔드를 자동으로 고른다
    gpui_platform::application().run(|cx: &mut App| {
        cx.open_window(WindowOptions::default(), |_, cx| {
            // 여기서 루트 View(화면)를 만들어 돌려준다
            cx.new(|_| HelloWorld)
        });
    });
}
// HelloWorld 가 Render 트레잇을 구현하면, GPUI가 매 프레임 render()를 부른다

위 코드가 말하는 건 딱 하나다 — "앱을 켜고(application), 창을 열고(open_window), 그릴 화면(View)을 하나 등록한다." 복잡한 렌더링·GPU 호출은 전부 GPUI 안에 숨어 있고, 개발자는 "무엇을 그릴지"만 적는다. 배치는 div()에 Tailwind 비슷한 메서드(.flex().p_4() 식)를 붙여 표현한다.

핵심 설계 3 — 단일 async 실행기 + Entity 소유 모델

Zed는 스레드를 마구 띄우는 대신, OS 이벤트 루프와 통합된 비동기 실행기(async executor) 하나 위에서 작업을 돌린다(smol 런타임 계열). 그리고 모든 앱 상태는 GPUI가 소유하는 Entity로 관리되어, Rc(참조 카운트 스마트 포인터) 비슷한 핸들로만 접근한다. 이 두 가지가 합쳐져 "데이터 경쟁(race) 없이도 빠른" 단일 모델을 만든다 — Rust의 소유권 규칙이 컴파일 시점에 사고를 막아준다.

핵심 설계 4 — 협업과 AI는 "같은 편집 스트림"으로

실시간 공동편집(다른 사람)과 AI 에이전트(모델)는 사실 Zed 입장에서 비슷한 일이다 — "내가 아닌 누군가가 버퍼를 고친다". 그래서 둘 다 편집 연산(operation)을 주고받는 같은 길을 탄다. 사람 편집은 rpc/proto로, AI 편집은 acp_thread·action_log로 흐르지만, 끝에서 만나는 곳은 같은 버퍼다. 그래서 "AI가 고친 걸 사람이 이어서 고치고, 그걸 또 다른 협업자가 보는" 일이 자연스럽다.

5디렉토리 구조 해부

"크레이트가 280개라 무섭지만, 사실 6~7개 그룹으로 묶인다."

저장소 루트는 단순하다. 거의 모든 코드는 crates/ 안에 있고, 나머지는 확장·도구·문서다.

읽는 순서를 추천하면 이렇다. 처음 길을 잡을 땐 crates/zed(진입점) → crates/workspace(창 뼈대) → crates/editor(편집 화면) 순으로 따라가면 "앱이 켜지고 화면이 뜨는 흐름"이 잡힌다. UI 자체가 궁금하면 crates/gpui/README.md가 친절한 출발점이다.

6학습 포인트 (기술별)

"Zed 한 채에 현대 시스템 프로그래밍의 거의 모든 주제가 들어 있다 — 보물창고처럼 골라 배우자."

Zed는 "큰 Rust 코드베이스"의 모범 사례라, 읽기만 해도 배울 게 많다. 분야별로 무엇을 배울지 + 작게 실습할 아이디어를 정리했다.

7하드웨어 / 시스템 요구사항

"쓰는 건 가볍지만, 소스에서 빌드하는 건 묵직한 작업이다."

그냥 쓰기 (설치본)

일반 사용은 가볍다. macOS·Linux·Windows용 빌드를 zed.dev/download에서 받거나 패키지 매니저로 설치한다. 단, GPU 렌더가 핵심이라 그래픽 가속이 되는 환경이 필요하다(아주 오래된 가상머신·헤드리스 환경에선 렌더가 제한될 수 있다). 웹 버전은 아직 없다.

소스에서 빌드하기 (개발자)

# 소스에서 Zed 빌드·실행 (개발 빌드)
git clone https://github.com/zed-industries/zed
cd zed
cargo run            # 첫 실행은 수백 개 크레이트를 컴파일 → 시간 걸림(커피 한 잔)

# 프레임 렌더 시간을 stderr로 출력 (성능 비교용 — 코드에 내장된 스위치)
export ZED_MEASUREMENTS=1
cargo run --release

복사해서 그대로 쳐도 된다. 핵심은 cargo run 한 줄이면 Zed가 통째로 빌드돼 뜬다는 것 — 다만 첫 빌드는 부품이 많아 오래 걸린다는 점만 각오하면 된다. ZED_MEASUREMENTS=1은 "한 프레임 그리는 데 몇 ms 걸렸나"를 찍어주는, 성능을 1순위로 여기는 이 프로젝트의 성격이 드러나는 스위치다.

8직접 해볼 수 있는 실습 과제

"읽기만 하면 안 남는다 — 난이도별로 손을 움직여 보자."

9관련 기술 심화 학습 로드맵

"Rust를 모르는 상태에서 Zed에 기여하기까지 — 7주 코스 예시."

아래는 "Rust 입문자가 Zed 코드를 읽고 작게 기여할 수 있는 수준"까지의 한 가지 길이다. 본인 속도에 맞춰 늘리거나 줄여도 된다.

10핵심 키워드 사전

"이 문서와 Zed 코드에서 거듭 나오는 용어들 — 한 곳에 모아 풀었다."

11참고 링크

공식 저장소·문서·개념 출처.