워크스페이스

패키지 하나로 부족할 때 — 라이브러리, CLI, 공유 내부 크레이트가 있는 프로젝트 — 워크스페이스 로 손 뻗어: 함께 빌드되고 버저닝되는 여러 관련 패키지.

워크스페이스가 뭐냐

워크스페이스는 멤버 패키지를 나열하는 [workspace] 섹션이 있는 최상위 Cargo.toml 이야. 하나의 Cargo.lock 과 하나의 target/ 빌드 디렉토리를 공유해서, 의존성이 한 번 풀리고 컴파일 산출물이 공유돼. 루트의 cargo build 가 모든 멤버를 지어.

왜 워크스페이스로 나누나

큰 프로젝트를 워크스페이스 안 집중된 크레이트로 나누면 더 빠른 증분 빌드 (바뀐 크레이트만 재컴파일), 명확한 내부 경계 (크레이트의 pub API 가 형제들과의 계약), 일부 크레이트는 게시하고 일부는 private 로 두는 능력을 줘. 사소하지 않은 Rust 프로젝트가 조직되는 법이야.

워크스페이스가 실전 프로젝트 모양이야. 전형적 앱이 워크스페이스: core 라이브러리 크레이트, 그걸 돌리는 바이너리 크레이트, 어쩌면 공유 타입 크레이트, 매크로 크레이트. Cinder 의 네이티브 쪽이 이렇게 조직돼 — Tauri 앱 크레이트랑 지원 크레이트들이 lockfile 이랑 빌드 디렉토리 하나를 공유하는 monorepo 워크스페이스. 모듈 시스템이 크레이트 시스템으로, 크레이트 시스템이 워크스페이스로 확장돼.

모듈은 안쪽, 크레이트는 가로질러

멘탈 모델: 크레이트 안 코드 조직엔 모듈, 컴파일/게시 경계를 가로지르는 조직엔 (워크스페이스 안) 크레이트. 추론하기엔 너무 커진 크레이트가 나눌 신호; 단단히 결합된 크레이트 덩어리가 너무 일찍 나눈 신호. 균형이 기술이야.

Code

멤버 크레이트 셋짜리 워크스페이스·toml

# 워크스페이스의 최상위 Cargo.toml
[workspace]
resolver = "2"
members = [
    "core",      # 라이브러리 크레이트: 공유 로직
    "cli",       # 바이너리 크레이트: core 에 의존
    "protocol",  # 공유 타입 크레이트
]

# cli/Cargo.toml 이 형제 크레이트를 path 로 의존:
#   [dependencies]
#   core = { path = "../core" }

Exercise

작은 앱의 3-크레이트 레이아웃을 스케치해 (종이나 스크래치 워크스페이스에): core 라이브러리, 그걸 의존하는 cli 바이너리, 둘 다 쓰는 shared-types 크레이트. 워크스페이스 Cargo.toml 멤버 리스트랑 cli 의 path 의존성을 써. 모든 걸 한 크레이트에 욱여넣는 것보다 왜 나아?

Hint

별도 크레이트는 더 빠른 증분 빌드, 강제된 경계 (core 의 pub API 가 계약), 독립 게시 가능성을 줘. 한 거대 크레이트는 어떤 변경에도 전체 재컴파일하고 내부 경계를 흐려.