lightcraft 딥다이브
— 원본을 지키며 빛을 다시 계산하는 Rust 암실

1프로젝트 한줄 요약

LightCraft는 사진 라이브러리 관리와 RAW 현상을 한 엔진에 묶은 Rust 사진 편집기입니다. 별점·앨범으로 사진을 정리하고, 노출·화이트밸런스·마스크·자르기를 조정한 뒤 새 이미지로 내보냅니다. macOS·Windows·Linux용 앱과 WebAssembly 웹 앱, CLI, MCP 진입점이 있습니다.

편집의 중심은 바뀐 픽셀 파일이 아니라, 원본을 다시 그리는 데 필요한 설정 데이터입니다. crates/develop/src/settings.rs의 DevelopSettings는 직렬화 가능한 값입니다. 카탈로그가 이 값을 보관하고, crates/pipeline이 원본과 설정을 받아 결과를 계산합니다.

처음 읽을 때 잡아둘 세 가지 경계

여기서 “백엔드”는 웹 서버를 뜻하지 않습니다. 사용자 컴퓨터 안의 처리 엔진입니다. 기본 사진 편집에 계정이나 별도 데이터베이스 서버를 두는 구조가 아니며, 카탈로그는 자체 파일 저널을 사용합니다.

2왜 주목받는가

2-1. 짧은 공개 기간에 드러난 큰 구현 범위

2026-09-30 생성된 저장소가 2026-10-23 GitHub 기준 스타 14,376개와 포크 5,526개를 기록했고, TrendShift Monthly #21에 선정되었습니다. 카메라 파일 해독부터 사진 관리, GPU 계산, 웹 빌드까지 한 저장소에 들어 있습니다. 다만 이 숫자만으로 성장 원인이나 실제 사용자 수를 알아낼 수는 없습니다.

관심을 끌 만한 지점은 코드로 설명할 수 있습니다. 한 언어로 사진 처리의 바닥부터 화면과 자동화 인터페이스까지 연결한 구조가 이 저장소의 뚜렷한 학습 가치입니다. Rust 파일은 테스트·예제 등을 포함해 719개, 물리적 줄 수로 약 32만 줄입니다. “작은 필터 데모”보다 여러 실행 환경을 가진 제품의 설계를 공부하기에 가깝습니다.

2-2. 비슷한 도구와 무엇을 비교해야 할까?

비파괴 편집 자체는 새로운 발명이 아닙니다. darktable 공식 소개도 비파괴 처리와 부동소수점 파이프라인을 설명합니다. Lightroom Classic 공식 문서에는 노출·색·마스크 등 현상 도구가 정리되어 있습니다. 비교의 초점은 화질 순위보다 개발자가 구조를 이해하고 확장할 수 있는 경로에 둡니다.

2-3. 사람이 쓰는 앱과 도구가 호출하는 엔진의 접점

crates/mcp/src/lib.rs에는 실행 중인 앱에 연결하는 Remote와 화면 없이 엔진 세션을 여는 Headless가 함께 있습니다. MCP를 붙이기 위해 편집 기능을 다시 만드는 대신, 이미 존재하는 명령을 다른 통로로 노출합니다. 이것은 사진 앱뿐 아니라 문서 편집기·CAD·데이터 도구에도 적용할 수 있는 설계입니다.

3기술 스택 전체 지도

3-1. 전체를 묶는 Cargo 워크스페이스

루트 Cargo.toml은 members = ["crates/*", "apps/*", "xtask"], resolver = "3", edition = "2024", 공통 버전 0.13.0을 선언합니다. 라이브러리 크레이트 29개, 앱 3개, 빌드 도구 1개로 총 33개 멤버이며, 루트까지 매니페스트는 34개입니다.

3-2. 처리 엔진: 파일·색·연산·저장

표의 공통 선언은 루트 Cargo.toml, 행렬 연산 의존성은 crates/denoise/Cargo.toml 기준입니다. RAW 처리는 C 라이브러리를 감싼 단일 호출로 끝나지 않습니다. crates/raw 안에서 파일별 해독, 디모자이킹, 색 변환을 직접 나눕니다.

3-3. 프론트엔드: 같은 egui 화면, 서로 다른 호스트

웹에서도 Rust 엔진과 egui 화면을 재사용하고, 브라우저 API를 호스트에서 연결합니다. apps/lightcraft-web/Cargo.toml은 공통 crates/ui-egui와 engine을 참조합니다. 웹 화면은 WebGL2로 그리지만, 사진 현상 연산에는 아직 WebGPU 경로가 없습니다. 화면을 GPU로 표시하는 일과 사진 필터를 GPU로 계산하는 일을 구분해야 합니다.

apps/lightcraft-web/src/workers.rs의 worker_main은 별도 Web Worker에서 WASM을 실행합니다. OPFS 또는 IndexedDB에 원본·라이브러리를 저장하고, Worker를 만들 수 없으면 메인 스레드 처리로 돌아갑니다. HTML과 JavaScript는 얇은 시작 코드이며, package.json·pyproject.toml·go.mod·Dockerfile은 없습니다.

3-4. 인프라·빌드: 배포 서버보다 실행 파일과 WASM

4아키텍처 심화 분석

전체 지도를 볼 때는 의존성과 실행 시 데이터 흐름을 나누세요. UI가 엔진을 호출하지만, 엔진은 UI 타입을 몰라야 합니다. xtask/src/layers.rs의 TABLE과 UI_MIN_LAYER = 5가 이 규칙을 코드로 표현합니다.

도식은 핵심 경로를 요약한 것입니다. 브라우저의 저장은 호스트가 메모리 상태와 비동기 저장소를 연결하며, 네이티브 FsStore의 파일 동기화와 동일한 방식으로 처리하지는 않습니다. 앱과 xtask는 계층 검사에서 예외로 분류됩니다. 또한 창 조작 명령과 파일 대화상자 같은 UI 전용 동작은 호스트에 남습니다.

4-1. 패턴 ① 명령 레지스트리: 입구를 늘려도 편집 규칙은 한곳에

crates/engine/src/cmd/mod.rs의 CommandSpec에는 id·label·menu·shortcut·params·enabled·run 등이 들어갑니다. 버튼의 제목과 실행 가능 여부, 실제 처리 함수를 한 명세에 모은 구조입니다.

// crates/engine/src/cmd/mod.rs의 함수 타입
pub type Run = fn(&mut Session, &Value) -> Result<Value>;
pub type Enabled = fn(&Session) -> std::result::Result<(), String>;

crates/engine/src/lib.rs의 Session::execute는 find_command(id)로 명세를 찾고, 실행 조건을 검사한 뒤 run_command로 보냅니다. 사진 ID를 명시하는 일부 명령은 선택 상태 검사를 건너뛰지만, 해당 명령이 대상 사진을 직접 검증합니다.

노출 조정의 실제 명령은 crates/engine/src/cmd/develop.rs의 develop.set입니다. 제어 ID와 숫자를 받아 controls::set을 호출하고, Session::set_develop으로 변경을 전달합니다. UI와 CLI가 “노출을 바꾸는 서로 다른 규칙”을 가질 필요가 줄어듭니다.

# CLI 사용 예시: 예제 사진을 불러와 같은 엔진 명령 호출
lightcraft-cli run --demo develop.set control=light.exposure value=0.7

# 같은 호출을 표현한 엔진 명령 데이터
{"command":"develop.set","params":{"control":"light.exposure","value":0.7}}

run_command는 명령 주위의 패닉 방어, 자동 버전, XMP 자동 쓰기, 영속 저장을 묶습니다. 저장 실패 시 NotSaved를 돌려주는 경로도 있습니다. 명령 실행 성공과 디스크 저장 성공을 구분하는 책임까지 공통 진입점이 다룹니다.

4-2. 패턴 ② 값으로 표현한 편집 + 역연산으로 되돌리기

DevelopSettings는 화면 위젯이 아닌 데이터입니다. to_json·from_json·merged를 제공하고, 숫자 제어는 crates/develop/src/controls.rs의 CONTROLS에서 ID·범위·기본값을 공유합니다.

// ControlSpec::clamp의 실제 구현
pub fn clamp(&self, v: f64) -> f64 {
    if v.is_finite() { v.clamp(self.min, self.max) } else { self.default }
}

// 학습용 사용 예시: light.exposure의 범위는 -5..=5
let mut settings = DevelopSettings::default();
let known = controls::set(&mut settings, "light.exposure", 99.0);
assert!(known);
assert_eq!(settings.light.exposure, 5.0);

crates/catalog/src/lib.rs의 Catalog::apply는 연산을 적용하고 역연산을 반환합니다. Op::SetDevelop의 경우 새 설정을 넣으면서 이전 설정을 담은 반대 연산을 만듭니다. Session::commit은 정방향 연산을 저장 대기열에 넣고, 역연산을 실행 취소 스택에 보관합니다.

슬라이더를 드래그할 때는 begin_interaction으로 시작 상태를 잡고, set_develop으로 미리보기를 갱신합니다. end_interaction은 마지막 값을 한 번의 실행 취소 단계로 확정합니다. 중간값이 100번 바뀌어도 사용자의 한 번의 드래그라는 행동 단위를 살리는 설계입니다.

설정의 의미도 버전으로 관리합니다. crates/develop/src/settings.rs의 ProcessVersion과 Process::V1·V2는 계산법이 바뀌어도 오래된 편집을 해석할 기준을 보존합니다. 파일 형식의 버전과 렌더링 알고리즘의 버전은 서로 다른 문제입니다.

4-3. 패턴 ③ CPU 기준 구현 + 단계 캐시 + GPU 대체 경로

crates/pipeline/src/lib.rs의 plan은 설정·원본·출력 크기를 결합해 공통 Plan을 만듭니다. 여기에는 기하 변환, 출력 크기, 세부 효과의 배율, geo·lin_key 같은 단계별 캐시 키가 들어갑니다.

render_cached는 render_impl을 통해 중간 결과를 재사용합니다. StageCache의 기본 capacity는 2입니다. 노출만 바뀌었다면 원본 재샘플링과 노이즈 제거를 반복할 필요가 없고, 관련된 뒷단 계산을 다시 수행합니다.

빠른 편집의 핵심은 모든 계산을 더 빨리 하는 것뿐 아니라, 바뀌지 않은 계산을 다시 하지 않는 데 있습니다. 이것은 이미지 처리 밖에서도 빌드 시스템, 스프레드시트, 파생 상태 계산에 연결되는 생각입니다.

GPU는 CPU 구현과 Plan을 공유합니다. crates/engine/src/media.rs의 develop_image는 조건이 맞으면 lightcraft_gpu::try_render를 시도하고, 사용할 수 없거나 실패하면 pipeline::render_cached 또는 render로 이어집니다. 일부 효과는 GPU 처리 안에서도 CPU 단계를 섞으므로 완전한 단일 GPU 경로라고 이해하면 안 됩니다.

4-4. 패턴 ④ 연산 저널 + 스냅샷: 다시 열 수 있어야 편집기다

crates/catalog/src/journal.rs의 Journal은 두 파일을 관리합니다. catalog.snap은 특정 순번까지의 전체 상태, catalog.log는 그 뒤에 추가한 연산입니다. 각 로그는 seq·crc·op를 가진 JSON 한 줄입니다.

encode_record는 연산 JSON의 CRC-32를 만들고, Journal::open은 스냅샷보다 뒤의 기록만 재생합니다. 손상된 마지막 줄과 중간에 생긴 손상을 구분하며, 더 새로운 형식은 파일을 손대지 않고 거부합니다. CRC는 우발적인 손상 검출용이지 위조 방지용 암호가 아닙니다.

Store 트레이트는 read·append·write_atomic 등을 정의합니다. FsStore::write_atomic은 임시 파일 쓰기, 동기화, 이름 교체를 수행합니다. 메모리용 MemStore도 같은 인터페이스를 구현하여 파일 손상을 가정한 테스트를 쉽게 만듭니다.

기본 SnapshotPolicy는 로그 2,000개 또는 16 MiB를 스냅샷 전환 판단에 사용합니다. 저장소가 백그라운드 쓰기를 지원하면 snapshot_in_background는 복사한 상태를 저장하는 동안 새 연산을 계속 받고, poll은 스냅샷 이후 기록만 로그에 남깁니다. 지원하지 않는 저장소에서는 동기식 스냅샷으로 처리합니다. 저장 도중 어느 시점에 멈춰도 무엇을 재생할지 정하는 것이 핵심입니다.

5디렉토리 구조 해부

crates/engine 약 92,000줄과 crates/ui-egui 약 82,800줄을 처음부터 모두 읽기보다, 약 2,800줄의 crates/develop에서 설정과 제어 ID를 파악하는 편이 좋습니다. 다음으로 명령 한 개와 관련 테스트를 이어 읽으면 읽을 범위를 좁힐 수 있습니다.

저장소 문서의 숫자는 작성 시점에 따라 다릅니다. docs/architecture.md의 약 202,000줄·505파일·라이브러리 24개는 2026-10-10의 집계입니다. 커밋 23e1812의 319,925줄·719개 Rust 파일·라이브러리 29개와 구분해야 합니다.

6학습 포인트 (기술별)

6-1. Rust: 큰 데이터를 복사하지 않고 안전하게 공유하기

crates/raster/src/lib.rs는 Rgb32f = Image<[f32; 3]>와 Rgba8 = Image<[u8; 4]>를 구분합니다. 전자는 계산용 선형 RGB, 후자는 주로 표시용 결과입니다. 타입 이름만으로 어느 단계의 버퍼인지 드러내는 장점을 먼저 보세요.

엔진과 캐시는 큰 이미지에 Arc<Rgb32f>를 사용합니다. Arc::clone은 픽셀 전체 복사와 다르지만, 내부 이미지를 clone하면 실제 데이터가 복사될 수 있습니다. pipeline::render_impl의 Arc::unwrap_or_clone과 캐시 유무 분기를 나란히 읽어보세요.

작은 실습: 픽셀 버퍼를 가리키는 Arc 두 개를 그림으로 표시한 뒤, “참조만 복제한 위치”와 “픽셀을 복제한 위치”를 구분하세요. 디스크 캐시, 중간 단계 캐시, 원본 캐시가 각각 어떤 값을 소유하는지도 함께 적어봅니다.

6-2. 색 과학: 화면 숫자와 빛의 양을 구분하기

crates/color/src/transfer.rs의 srgb_to_linear는 화면에 저장된 sRGB 값을 빛의 계산에 맞는 선형 값으로 바꿉니다. sRGB의 0.5는 선형 밝기 약 0.214에 해당합니다. 검정과 흰색을 선형 공간에서 반씩 섞은 값 0.5를 다시 sRGB로 바꾸면 약 0.735가 됩니다.

// transfer.rs의 실제 변환 함수
pub fn srgb_to_linear(v: f32) -> f32 {
    if v <= 0.04045 { v / 12.92 }
    else { ((v + 0.055) / 1.055).powf(2.4) }
}

작은 실습: 두 숫자를 그대로 평균하는 경우와 선형 변환 후 평균하는 경우를 종이에 비교하세요. 이후 crates/raw/src/color.rs의 카메라 색 → 선형 Rec.2020 변환, crates/pipeline/src/output.rs의 출력 색 공간으로 학습 범위를 넓힙니다.

6-3. 데이터 모델: 과거 파일을 오늘도 읽게 만들기

DevelopSettings::merged는 부분 JSON을 병합한 뒤 제어 범위를 다시 맞춥니다. 누락 필드의 기본값과 ProcessVersion의 과거 해석 규칙은 저장 데이터가 오래 살아남게 하는 장치입니다. 반대로 카탈로그는 지원하지 않는 새 형식을 거부합니다. 설정 필드를 유연하게 읽는 방식과 카탈로그 형식을 엄격히 보호하는 방식을 구분하세요.

작은 실습: 노출만 있는 설정, 빈 설정, 미래 처리 버전이 있는 설정을 나란히 놓고 어떤 값이 기본값을 받으며 어떤 정보가 보존되는지 표로 정리합니다. “기본값을 추가했더니 예전 사진의 모습이 바뀐다”는 문제를 버전 모델이 어떻게 막는지도 설명해 봅니다.

6-4. 병렬 처리: 빠르게 계산하는 일과 화면을 멈추지 않는 일

crates/raster/src/lib.rs의 par_rows는 기능 설정에 따라 Rayon의 par_chunks_mut 또는 순차 chunks_mut를 사용합니다. 서로 겹치지 않는 행 조각을 나눠 작업한다는 점이 안전성과 병렬성의 연결점입니다.

한편 crates/preview/src/pool.rs의 JobPool은 작업 우선순위와 중복을 관리합니다. 네이티브의 PreviewCache::put_deferred_at은 새 이미지를 포함한 디스크 쓰기 대기량이 128 MiB를 넘으면 그 이미지의 디스크 쓰기를 생략합니다. 결과를 메모리 캐시에 넣되, 느린 저장 장치 때문에 대기열이 끝없이 늘어나지 않게 합니다.

작은 실습: 현재 보이는 썸네일 10개와 화면 밖 썸네일 1,000개의 처리 순서를 설계해 보세요. 사용자가 빠르게 다음 사진으로 이동할 때, 오래된 결과가 현재 화면을 덮지 않도록 필요한 ID도 적습니다.

6-5. WASM·MCP: 엔진을 새 실행 환경에 연결하기

apps/lightcraft-web/src/workers.rs는 컴파일된 WASM 모듈을 Worker에 전달하고, 작업을 JSON으로 보내며 결과 RGBA 버퍼를 전송합니다. 공유 메모리 기반 WASM 스레드를 요구하는 구조와 다릅니다. Worker마다 모듈 인스턴스와 캐시가 있으므로 메시지·메모리 비용까지 생각해야 합니다.

MCP 쪽 Server::handle_line은 JSON-RPC 메시지를 받아 Backend로 연결합니다. crates/mcp/src/server.rs의 기본 프로토콜 버전은 2025-06-18입니다. tools.rs의 command_tool_name은 엔진 명령 ID를 도구 이름으로 바꿉니다.

작은 실습: develop.set을 GUI 버튼, CLI 인자, MCP 인자로 각각 표현하고, 끝에서 같은 엔진 명령에 도착하는 지점을 그려보세요. 새 인터페이스를 만드는 실력은 핵심 기능을 복제하는 대신 기존 규칙에 연결하는 능력에서 드러납니다.

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

7-1. 사진 한 장도 메모리로 풀면 커집니다

Rgb32f의 픽셀은 RGB 세 채널에 각각 4바이트를 씁니다. 6,000 × 4,000, 즉 24 MP 이미지를 한 벌만 펼쳐도 다음 크기입니다.

6,000 × 4,000 × 3 × 4바이트
= 288,000,000바이트
≈ 274.7 MiB

# 원본 파일 크기나 앱 전체 메모리 사용량과는 다른 값
# 중간 결과·마스크·GPU 버퍼·출력 버퍼가 추가될 수 있음

crates/engine/src/memory.rs의 default_budget은 RAM을 읽을 수 있으면 그 1/4을 256 MiB~1.5 GiB 범위로 제한해 기본 예산으로 사용합니다. RAM을 읽지 못하면 1.5 GiB를 쓰며, LIGHTCRAFT_MEMORY_MB로 바꿀 수 있습니다.

캐시 예산은 프로세스 전체 메모리 사용량의 상한이 아닙니다. 소스 설명에서도 작업 중 이미지, UI 텍스처, 할당자, GPU 드라이버의 메모리를 구분합니다. 배치 내보내기는 추가 작업 메모리를 사용할 수 있으므로 예산 숫자만 보고 대용량 병렬 처리를 결정하면 안 됩니다.

7-2. 최소 사양을 꾸며내지 않는 학습 환경 제안

공통 CPU 모델·RAM·VRAM 최소값 대신, 학습용 제안으로 RAM 8 GB급에서는 작은 JPEG 한 장부터, 16 GB 이상에서는 RAW 한 장씩 처리하는 순서를 권합니다. 이는 공식 최소 사양이나 동작 보장이 아닙니다. 모델 추론·고해상도 배치에는 별도 여유가 필요합니다.

빌드도 메모리를 사용합니다. README에는 16 GB 환경에서 동시 릴리스 링크 중 메모리 부족 사례가 기록되어 있습니다. xtask/src/main.rs의 ci_jobs는 사용 가능 메모리를 1,536 MiB로 나눠 빌드 병렬 수를 잡고, 테스트 스레드는 최대 4개로 제한합니다. 일반 cargo build에 이 정책이 자동 적용되는 것은 아닙니다.

# 독자가 소스 빌드를 선택할 때 참고할 명령
CARGO_BUILD_JOBS=1 cargo build --release -p lightcraft -p lightcraft-cli

7-3. 성능 숫자는 조건과 함께 읽기

README의 24 MP RAW·Apple M4 Pro 사례는 슬라이더 약 4 ms, 2.5 MP 보기 약 30 ms, 전체 크기 내보내기 약 0.3초입니다. 프로젝트 문서의 측정 사례이며, 보편적인 보장 수치가 아닙니다. 입력 형식, 캐시 상태, 효과, 출력 크기, GPU에 따라 시간이 달라집니다.

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

읽기만으로 풀 수 있는 부분부터 시작하고, 실행·수정 실습은 독립된 연습용 사본과 복사한 사진으로 진행하세요. 아래 명령은 독자가 사용할 예시입니다. 원본 촬영본 대신 재생성 가능한 입력을 사용하면 결과를 비교하기 쉽습니다.

# 설치된 CLI가 있을 때 제어 명세를 살펴보는 예시
lightcraft-cli controls --json
lightcraft-cli commands --json

# 사진 사본을 작은 결과로 내보내는 예시
lightcraft-cli render sample.jpg -o practice.jpg --size 1600 \
  --set light.exposure=0.7

// 연습용 테스트의 핵심. 필요한 타입·모듈은 별도 import
let mut s = DevelopSettings::default();
assert!(controls::set(&mut s, "light.exposure", 99.0));
assert_eq!(s.light.exposure, 5.0);
assert!(controls::set(&mut s, "light.exposure", f64::NAN));
assert_eq!(s.light.exposure, 0.0);
assert!(!controls::set(&mut s, "light.noSuchControl", 1.0));

과제마다 결과 사진만 남기지 말고 입력 조건과 기대 결과를 적으세요. 특히 캐시·영속성·병렬 처리는 겉으로 같은 화면이 보여도 내부 상태가 틀릴 수 있어, 관찰 가능한 기준을 먼저 세우는 연습이 중요합니다.

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

Rust가 처음이라면 공식 입문서의 소유권·구조체·열거형·오류 처리를 먼저 익히세요. 아래 일정은 제안이며, 이미지 수학을 모두 배운 뒤 코드를 읽을 필요는 없습니다. 한 주에 새로운 개념 하나와 검증 가능한 결과물 하나를 연결하는 편이 지속하기 쉽습니다.

6주 뒤 선택할 심화 방향

• 시스템 개발: RAW 헤더의 크기 계산, 경계 검사, checked_mul과 잘못된 입력 테스트를 공부합니다.
• 그래픽스: crates/gpu/src/wgsl/의 한 커널을 CPU 함수와 대응시키고, 오차 기준의 단위를 설명합니다.
• 앱 설계: 사진 도메인 대신 할 일 목록으로 명령·역연산·저널을 작게 다시 설계해 봅니다.
• 웹 시스템: Worker 실패, 저장 공간 부족, 미저장 상태의 UI 표현을 중심으로 비동기 경계를 읽습니다.

10핵심 키워드 사전

처음부터 모든 약어를 외울 필요는 없습니다. “사진 원본은 무엇인가 → 설정은 무엇인가 → 계산 결과는 무엇인가 → 저장 기록은 무엇인가”로 묶으면 비슷해 보이는 타입과 파일도 역할을 나눠 이해할 수 있습니다.

11참고 링크

11-1. 저장소와 핵심 소스

• 공식 GitHub 저장소 · v0.13.0 릴리스 · TrendShift
• 공통 버전·빌드 프로필 · 정확한 의존성 버전
• 제어 ID와 범위 · 설정 스키마와 처리 버전
• 명령 레지스트리 · 세션·실행 취소·저장 진입점
• 렌더 계획과 단계 캐시 · GPU 선택과 CPU 대체 경로
• 저널과 복구 규칙 · 파일·메모리 저장 추상화
• CPU/GPU 비교의 실제 허용 오차 · GPU 실패 대체 경로 테스트
• 실제 계층 검사 규칙 · 릴리스 워크플로

11-2. 프로젝트의 공식 설명과 한계

• 기능 소개·시작 안내 · 성숙도와 로드맵
• 아키텍처 문서 · 카메라 RAW 지원 범위
• GPU 구현과 측정 조건 · 하드웨어·플랫폼 차이
• 웹 앱과 브라우저 저장 · MCP 사용 문서
• SAM 3 모델·원격 실행 · 노이즈 제거 모델 설정

11-3. 관련 기술의 공식 학습 자료

• Rust 공식 입문서 · Cargo 워크스페이스 · Serde
• egui 0.36.2 API · wgpu 30.0.1 API · WGSL 명세
• wasm-bindgen 안내 · Web Workers · MCP 2025-06-18 명세
• darktable의 공식 설계 소개 · Lightroom Classic 현상 도구 공식 문서

현재 상태 (2026-10-23 확인)

줄 수는 파일 확장자별 물리적 행의 합입니다. 실행되는 제품 코드만의 크기, 구현 품질, 개발 시간과 같지 않습니다. crates/engine 92,033줄, crates/ui-egui 82,846줄, crates/raw 38,311줄에는 해당 디렉토리의 테스트·예제도 포함됩니다.