photocraft 딥다이브
— 사진 편집기 안에서 배우는 Rust 엔진 설계

1프로젝트 한줄 요약

PhotoCraft는 사진을 열어 레이어·선택 영역·마스크·브러시·필터로 편집하고, 결과를 저장하는 프로그램입니다. Photoshop과 비슷한 작업 흐름을 목표로 하며, PSD/PSB와 자체 형식 .pcraft를 다룹니다. 중요한 학습 대상은 기능 목록보다 같은 편집을 여러 인터페이스에서 재사용하는 구조입니다.

PhotoCraft에서는 화면의 버튼도 터미널의 명령도 같은 문서 모델과 편집 엔진으로 들어갑니다. 데스크톱은 egui/eframe로 화면을 그리고, 브라우저판은 Rust를 WebAssembly로 컴파일합니다. CLI는 창을 띄우지 않고 작업하며, MCP 서버는 외부 에이전트가 엔진을 호출할 수 있게 합니다.

1-1. 사진 한 장을 편집할 때 생기는 일

1. 열기: 코덱과 입출력 계층이 파일을 읽어 Document와 레이어로 바꿉니다.
2. 편집: Session이 명령과 JSON 매개변수를 받아 문서 상태를 바꿉니다.
3. 표시: 합성기가 레이어·마스크·효과를 계산해 화면에 보여 줄 픽셀을 만듭니다.
4. 되돌리기: 이전 문서 상태를 보관한 History가 실행 취소를 담당합니다.
5. 저장: 편집 가능한 문서 저장과 PNG 같은 평면 이미지 내보내기가 각각 수행됩니다.

1-2. 처음에는 이 세 파일만 잡아도 됩니다

2왜 주목받는가

2-1. Rust로 완성형 편집기를 만들겠다는 큰 목표

2026-10-23 기준 TrendShift Monthly #2이며, GitHub 스타는 71,526개입니다. 저장소 생성일은 2026-09-30으로 분석일까지 23일이 지났습니다. 이 짧은 공개 기간에 비해 편집기·파일 형식·자동화·배포를 함께 다룬다는 점이 눈길을 끕니다. 다만 저장소 생성일은 모든 코드의 개발 시작일을 증명하지 않습니다.

어떤 홍보나 커뮤니티가 유입을 만들었는지는 코드만으로 확정할 수 없습니다. 여기서 짚을 수 있는 기술적 매력은 Rust 중심의 제품 구조, 편집 엔진의 재사용, 파일 호환성 검증을 공개했다는 점입니다.

2-2. 경쟁 도구와 비교할 때의 기준

비교 기준은 학습 가능한 내부 구조와 편집 자동화입니다. Photoshop은 저장소가 명시한 기능·동작의 비교 목표이고, image는 PhotoCraft도 사용하는 Rust 영상 입출력 라이브러리입니다. 세 도구는 범위가 다르므로, 코드 공개나 명령 인터페이스의 장점을 편집 품질의 우열로 확대하면 안 됩니다.

2-3. “에이전트가 조작하는 앱”을 코드로 배울 수 있다

crates/automation/src/server.rs의 Backend는 Headless와 Bridge를 구분합니다. 전자는 프로세스 안의 엔진을 사용하고, 후자는 실행 중인 데스크톱 앱과 통신합니다. 따라서 자동화의 두 경로를 같은 도구 인터페이스 아래에서 비교할 수 있습니다.

자동화하기 쉬운 제품은 핵심 동작을 화면 밖에서도 호출할 수 있도록 설계되어 있습니다. 명령 목록에는 enabled, disabledReason, needsDocument가 포함됩니다. 단순히 실행 버튼을 제공하는 것에서 한 걸음 더 나아가, 호출자가 다음 행동을 판단할 정보를 줍니다.

2-4. README의 숫자와 소스의 현재 모습

문서의 숫자는 서로 다른 시점과 집계 범위를 반영합니다. 특히 테스트 표시 수는 비동기 테스트 속성이나 매크로 생성 사례를 모두 세는 방식이 아니며, 무시되거나 환경에 따라 건너뛰는 테스트도 구별하지 않습니다.

3기술 스택 전체 지도

이 프로젝트에서 “백엔드”는 주로 기기 안에서 실행되는 편집 코어를 뜻합니다. 별도 원격 API 서버나 데이터베이스가 기본 편집 경로의 중심에 있지 않습니다. 프론트엔드는 Rust 네이티브 UI이며, 웹판도 같은 UI를 WebAssembly로 실행합니다.

3-1. 백엔드에 해당하는 편집·문서 코어

아래의 “선언”은 Cargo.toml의 버전 요구 범위이고, “잠금”은 루트 Cargo.lock에 기록된 구체 버전입니다. 예를 들어 선언 "1"은 정확히 1.0.0만 쓰라는 뜻이 아닙니다.

3-2. 프론트엔드와 플랫폼 경계

“Rust로 만든 웹 UI”는 브라우저 기능을 쓰지 않는다는 뜻이 아니라, UI와 엔진의 주 구현 언어가 Rust라는 뜻입니다. JavaScript·TypeScript 소스 파일은 이 리비전에서 발견되지 않지만, 웹 빌드에는 바인딩과 부트스트랩이 필요합니다. Tauri나 Electron을 쓰는 구조와도 다릅니다.

3-3. 인프라·빌드·CI

Rust 최소 요구 버전 1.95, Docker의 기본 빌더 1.99, CI의 stable은 서로 다른 설정입니다. 공용 릴리스 워크플로는 이 저장소 바깥의 @main을 따라가므로, 로컬 YAML만으로 서명·공증·모든 타깃의 전체 절차까지 확정할 수는 없습니다.

4아키텍처 심화 분석

4-1. 전체 시스템 구조도

아래에서 위쪽은 사용자의 입구, 가운데는 편집 상태와 계산, 아래쪽은 파일 경계입니다. 브라우저판의 ui-egui와 엔진은 WebAssembly 안에서 실행됩니다. MCP의 브리지 경로만 실행 중인 앱의 로컬 제어 채널을 거칩니다.

이 그림은 주요 호출과 데이터 흐름을 요약합니다. 상자 사이의 모든 선이 직접적인 Cargo 의존성을 뜻하지는 않습니다. 실제 계층 규칙은 xtask/src/layers.rs의 TABLE과 검사 코드에 있습니다.

4-2. 설계 패턴 ① 명령 레지스트리와 공통 실행 경로

CommandSpec은 기능 ID·메뉴 위치·단축키·매개변수 설명과 실행 함수를 함께 보관합니다. crates/engine/src/commands.rs::registry는 OnceLock으로 레지스트리를 한 번 만들고, HashMap으로 ID를 찾아 명령 배열의 항목에 연결합니다.

// crates/engine/src/commands.rs — 실행 계약과 주요 필드 발췌
type Run = fn(&mut Session, &Value) -> Result<Value>;
type Enabled = fn(&Session) -> std::result::Result<(), String>;

pub struct CommandSpec {
    pub id: &'static str,
    pub label: &'static str,
    // menu, shortcut, params 필드는 생략
    pub enabled: Enabled,
    pub run: Run,
    pub journal: bool,
}

명령 메타데이터를 읽으면 메뉴와 자동화 도구를 구성할 수 있고, enabled로 문서·레이어·선택 영역 같은 실행 조건을 검사할 수 있습니다. 다만 params는 설명 문자열이므로, 이것만으로 JSON이 완전히 타입 안전해지는 것은 아닙니다.

Session::execute는 crates/engine/src/jobs.rs의 Session::dispatch를 호출합니다. 여기서 명령 존재 여부, 매개변수가 JSON 객체 또는 null인지, 실행 권한과 공통·필터 매개변수 규칙을 검사합니다. Session::admit는 활성 조건과 작업 충돌 등도 판단합니다.

crates/engine/src/filters/validation.rs::fields에서 Gaussian Blur의 radius 범위는 0.1..=1000.0입니다. crates/engine/src/filters.rs::params_for에는 기본값 1.0과 범위 제한도 있습니다. 신규 호출 검증과 예전 스마트 필터 기록의 관대한 해석이 공존하므로, 변환 함수의 제한만 보고 잘못된 입력이 모두 허용된다고 해석하면 안 됩니다.

4-3. 설계 패턴 ② 문서 모델을 데이터로 표현하기

crates/doc/src/lib.rs는 레이어 종류를 열거형으로 표현합니다. 레이어가 픽셀 배열이라는 가정으로 시작하지 않기 때문에, 문자·도형·조정·스마트 오브젝트도 같은 레이어 트리에 놓을 수 있습니다.

// crates/doc/src/lib.rs — LayerContent
pub enum LayerContent {
    Raster(Surface),
    Group(Group),
    Adjustment(Adjustment),
    Fill(Fill),
    Text(TextLayer),
    Shape(ShapeLayer),
    Smart(SmartObject),
}

Layer는 content 외에도 opacity, fill_opacity, mask, effects 등을 가집니다. 조정 레이어의 설정을 바꾸는 것과 픽셀을 직접 덮어쓰는 것을 데이터 차원에서 구분하므로, 비파괴 편집과 파일 저장이 같은 모델을 공유할 수 있습니다.

색상도 비슷합니다. crates/color/src/lib.rs의 PixelFormat은 mode, sample, alpha를 보관하고, SampleType은 실제로 U8·U16·F32 세 가지입니다. 설계 문서의 초기 계획에 등장하는 F16을 현재 문서 저장 타입에 추가된 것으로 읽으면 안 됩니다.

4-4. 설계 패턴 ③ 타일 단위 복사와 문서 스냅샷

crates/raster/src/lib.rs의 Surface는 BTreeMap<TileCoord, Arc<Tile>>에 존재하는 타일만 저장합니다. 타일 한 변은 256픽셀이며, 없는 타일은 표면의 기본 픽셀로 읽습니다. 기본 픽셀은 일반 레이어의 투명색일 수도, 마스크의 흰색일 수도 있습니다.

// crates/raster/src/lib.rs — tile_mut의 실제 구현
pub fn tile_mut(&mut self, c: TileCoord) -> &mut Tile {
    let fmt = self.format;
    let dp = &self.default_pixel;
    let arc = self.tiles.entry(c)
        .or_insert_with(|| Arc::new(Tile::filled(&fmt, dp)));
    Arc::make_mut(arc)
}

Arc::make_mut은 타일을 혼자 소유하면 그대로 수정하고, 다른 문서 상태와 공유 중이면 타일을 복사한 뒤 수정합니다. 오류를 반환하는 별도 경로 try_tile_mut에는 메모리 예약 실패를 다루는 코드도 있습니다.

Session::edit는 이전 Arc<Document>를 보관하고 문서를 복제한 다음, 편집 클로저가 성공하면 새 문서를 활성 문서에 반영합니다. 새 이력 단계가 필요하면 History::record가 이전 문서를 기록합니다. 문서 복제는 레이어·타일 참조를 복사하는 비용이 있으므로 상수 시간이라고 단정할 수 없습니다.

실행 취소를 싸게 만드는 핵심은 “이전 픽셀을 다시 계산하기”보다 “바뀌지 않은 픽셀을 함께 보관하기”에 있습니다. 같은 coalesce 키를 쓰는 연속 편집은 하나의 이력 단계로 묶을 수 있습니다. 슬라이더를 조금씩 움직일 때 수십 개의 실행 취소 단계가 생기는 문제를 줄이는 장치입니다.

4-5. 설계 패턴 ④ CPU를 기준 구현으로 두고 GPU 검증하기

crates/compose/src/lib.rs::render는 레이어 트리를 부동소수점 RGBA 버퍼로 합성합니다. render_tiled는 네이티브에서 독립 타일을 병렬 계산하고, 웹 타깃에서는 직렬 계산합니다. GPU 쪽은 crates/gpu/src/lib.rs::Compositor와 crates/gpu/src/compose.wgsl이 맡습니다.

crates/gpu/tests/it/parity.rs는 두 합성 결과의 RGB에 알파를 미리 곱한 뒤, RGB와 알파의 최대 차이를 비교합니다. 실제 허용 오차 상수는 1.0 / 255.0 + 4.0 * f32::EPSILON입니다. 파일 첫 주석의 “2/255”보다 실행되는 상수와 검사 코드를 우선해 읽어야 합니다.

// crates/gpu/tests/it/parity.rs — 실제 허용 오차
const TOL: f32 = 1.0 / 255.0 + 4.0 * f32::EPSILON;

기준 구현은 최적화 결과가 맞는지 판단하는 비교점이 됩니다. GPU가 없으면 일부 테스트는 건너뛰며, WGPU_BACKEND를 명시한 경우에는 해당 백엔드를 못 쓰면 실패하도록 분기합니다. CPU·GPU 일치는 이 둘의 일관성을 뜻하며, Photoshop과의 일치까지 증명하지는 않습니다.

5디렉토리 구조 해부

5-1. 계층 번호는 “아래에서 위로” 읽습니다

xtask/src/layers.rs의 UI_MIN_LAYER = 6은 하위 코어가 egui·eframe·winit 같은 UI 의존성을 끌어들이지 않게 합니다. TABLE에는 미래·예약 항목도 있으므로, 표에 이름이 있다는 사실만으로 해당 폴더가 존재한다고 판단하지 않습니다.

5-2. 줄 수로 보면 어디가 큰가

이 집계에는 각 폴더의 테스트·예제·빌드 코드가 포함됩니다. UI 계층이 논리적으로 얇다는 말은 줄 수가 작다는 뜻이 아닙니다. 도구·패널·다국어·플랫폼 상태가 많아도 핵심 편집 규칙을 엔진에 모은다는 뜻으로 읽으면 됩니다.

6학습 포인트 (기술별)

6-1. Rust: 소유권을 데이터 보존 규칙으로 이해하기

Arc는 여러 상태가 같은 데이터를 소유하게 하고, &mut는 변경 경계를 드러냅니다. Result와 ?는 실패를 호출자에게 전달합니다. Session::edit에서 f(&mut doc, &mut active)?가 새 문서를 반영하기 전에 있다는 점을 찾아보세요.

실습 아이디어: 문서를 복제한 뒤 편집 함수가 오류를 반환하는 경우를 손으로 따라가 보세요. 활성 문서 교체와 History::record에 도달하는지 표시하면, “계산 중간의 실패가 기존 작업에 무엇을 남기는가”라는 질문을 코드로 답할 수 있습니다.

6-2. 병렬 처리: 독립적인 타일이 좋은 작업 단위가 되는 이유

crates/raster/src/lib.rs::convert_tiles는 네이티브에서 par_iter_mut를 사용합니다. 각 작업이 자기 타일의 바이트만 바꾸므로 공유 쓰기를 줄일 수 있습니다. 같은 함수의 웹 분기는 for 반복을 사용합니다.

실습 아이디어: 병렬 루프 안에서 읽는 값과 쓰는 값을 두 열로 적어 보세요. 이웃 픽셀을 읽는 필터에는 주변 영역이 필요하므로, 타일 경계가 계산 결과를 바꾸지 않게 입력 범위를 설계해야 합니다. “타일마다 나눴다”만으로 모든 영상 알고리즘이 독립적인 것은 아닙니다.

6-3. 영상 알고리즘: 흐림의 수식과 계산 비용

crates/algo/src/blur.rs::gaussian은 작은 반경에서 가우시안 커널과 conv_sep를 사용합니다. 가로·세로로 나누는 합성곱은, 한 픽셀마다 2차원 이웃 전체를 훑는 방식보다 필요한 계산을 줄일 수 있습니다.

box_widths는 반경이 4.0보다 크면 세 번의 박스 필터 근사를 선택합니다. 러닝 합은 창이 한 칸 움직일 때 빠진 값을 빼고 새 값을 더합니다. 큰 반경에서 창 안의 모든 값을 매번 다시 더하지 않도록 하는 최적화입니다.

실습 아이디어: 흑백 한 줄 [0, 0, 1, 0, 0]에 폭 3 평균을 직접 계산해 보세요. 경계 바깥을 0으로 볼 때와 가장자리 값으로 반복할 때를 비교한 다음, crates/algo/src/blur.rs의 경계 처리와 알파 미리 곱하기 흐름을 읽어 보세요.

6-4. 색상 관리: 픽셀 숫자와 눈에 보이는 색의 차이

crates/cms/src/lib.rs의 Profile, Transform, Intent는 ICC 프로파일과 색상 변환을 담당합니다. 같은 RGB 숫자라도 sRGB인지 Display P3인지에 따라 뜻하는 색이 달라집니다. 따라서 채널 깊이만 높인다고 색상 관리까지 해결되지는 않습니다.

실습 아이디어: PixelFormat::channels와 bytes_per_pixel로 RGBA8·RGBA16·CMYKA8의 저장 바이트 수를 계산하세요. 이어서 문서의 색 공간에서 표시 장치로 가는 변환이 합성 처리와 어디에서 분리되는지 찾아보세요.

6-5. 파일 형식: 파싱·모델 변환·저장 안정성은 서로 다른 문제

crates/psd는 형식 수준의 구조를 읽고 쓰며, crates/io는 이를 편집 가능한 문서 모델과 대응시킵니다. 알려지지 않은 블록을 보존하더라도, 편집기가 그 블록의 시각 효과를 계산할 수 있다는 뜻은 아닙니다.

crates/format/src/lib.rs의 자체 형식은 manifest.json과 콘텐츠 해시를 이름으로 쓰는 타일·바이너리 묶음으로 구성됩니다. PcraftWriter는 디렉토리 저장 시 기존 타일·바이너리를 재사용하고, 누락되거나 손상된 항목은 다시 씁니다. ZIP 저장에서는 압축 결과를 재사용하더라도 아카이브 전체를 다시 만듭니다.

crates/format/src/atomic.rs::atomic_write_with_progress는 대상 옆에 임시 파일을 만들고, 쓰기·동기화 이후 교체합니다. Windows에서는 기존 파일 교체 후 디렉토리 동기화 실패를 오류로 반환하고, Unix에서는 디렉토리 동기화 오류를 무시합니다. “파일 저장”이라는 버튼 아래에 플랫폼별 실패 조건이 있다는 사실을 배우기 좋은 지점입니다.

실습 아이디어: 동일한 PSD의 바이트 일치, 재저장 전후 렌더 일치, Photoshop의 합성 이미지와 일치를 별개의 시험 항목으로 나눠 보세요. 각각의 성공이 나머지 성공을 보장하지 않는 이유를 한 문장씩 적으세요.

6-6. MCP·플러그인: 확장성과 실행 권한을 함께 설계하기

crates/automation/src/server.rs::command_list와 command_run을 함께 읽으면, 도구가 명령을 발견하고 실행하는 흐름이 보입니다. 로컬 제어 채널은 crates/automation/src/security.rs에서 256비트 토큰, 요청 한 줄 1 MiB, 동시 연결 16개, 배치 256단계 같은 한계를 정합니다.

플러그인은 별도 경계입니다. crates/plugins/src/runtime.rs::Plugin::load는 호스트 임포트를 가진 모듈을 거절하며, 기본 한계는 모듈 32 MiB·선형 메모리 512 MiB·재귀 깊이 1,024입니다. WebAssembly 명령 실행량에 따라 연료를 소모하고, 네이티브에서는 기본 60초 시간 제한도 사용합니다.

실습 아이디어: MCP는 누가 어떤 파일을 만질 수 있는지, 플러그인 런타임은 어떤 계산 자원을 쓸 수 있는지 구분해 표로 그려 보세요. 웹판에서는 단조 시계 대신 연료 제한으로 실행을 묶는 차이도 찾아보세요.

이 저장소에서 가져갈 가장 큰 기술은 기능을 추가할 때 데이터·계산·화면·검증의 경계를 함께 생각하는 습관입니다.

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

7-1. 24 MP 사진의 메모리를 계산해 보기

6000 × 4000은 2,400만 픽셀입니다. 픽셀 전체가 채워진 단일 레이어를 단순 배열로 계산하면 다음과 같습니다. 아래 값은 채널 데이터만의 이론값이며 타일 가장자리 여유, 이력, 메타데이터, 임시 버퍼는 제외합니다.

합성용 부동소수점 버퍼, 필터 작업 버퍼, GPU 복사본까지 더해지면 실제 메모리는 커집니다. 빈 레이어는 희소 타일 덕분에 가볍지만, 전체를 바꾸는 필터는 많은 타일을 새로 만들 수 있습니다. 메모리 요구량은 사진 파일의 압축된 용량보다 풀린 픽셀과 동시에 보관하는 상태 수에 더 크게 좌우됩니다.

7-2. 기본 메모리 설정을 최소 사양으로 읽지 않기

crates/engine/src/prefs.rs::Performance::default에는 메모리 예산 8192, 이력 50단계, 효과 캐시 768, GPU 예산 0이 설정됩니다. 바이트 변환에 1 << 20을 쓰므로 메모리 예산 8192는 8 GiB에 해당하고, GPU의 0은 자동 설정을 뜻합니다. 이 값은 설치에 필요한 최소 RAM을 선언한 수치가 아닙니다.

처음 실험할 때는 512 × 512 이미지와 적은 레이어로 결과의 정확성을 확인하세요. 이후 해상도·깊이·레이어 수 중 하나만 늘리면 어느 자원이 비용을 만드는지 관찰하기 쉽습니다. CPU CLI 실습과 GPU 화면 실습을 나누면 환경 문제를 좁히는 데도 도움이 됩니다.

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

시간은 학습 계획용 대략값입니다. 먼저 소스 읽기로 흐름을 설명하고, 실행 실습은 개발 환경을 준비한 뒤 작은 합성 이미지로 진행하면 됩니다. 코드를 추가하는 과제는 별도의 학습용 사본에서 진행하세요.

# 저장소 루트에서 명령 등록 지점과 알고리즘 찾기
rg -n 'gaussianBlur|params_for' crates/engine
rg -n 'fn gaussian|fn box_widths' crates/algo/src/blur.rs

# CLI 실행 파일이 준비되어 있다면 명령 메타데이터 확인
photocraft-cli commands --json --filter gaussian

다음은 photocraft-raster, photocraft-color, photocraft-geom을 사용할 수 있는 Rust 학습 코드에 넣는 예시입니다.

use std::sync::Arc;
use photocraft_color::PixelFormat;
use photocraft_geom::{Rect, TileCoord};
use photocraft_raster::Surface;

fn observe_cow() -> Result<(), &'static str> {
    let c = TileCoord::new(0, 0);
    let mut a = Surface::new(PixelFormat::RGBA8);
    a.fill_rect(Rect::new(1, 1, 2, 2), &[1.0, 0.0, 0.0, 1.0]);
    let mut b = a.clone();

    assert!(Arc::ptr_eq(
        a.tile(c).ok_or("원본 타일 없음")?,
        b.tile(c).ok_or("복제본 타일 없음")?,
    ));
    b.fill_rect(Rect::new(1, 1, 2, 2), &[0.0, 1.0, 0.0, 1.0]);
    assert!(!Arc::ptr_eq(
        a.tile(c).ok_or("원본 타일 없음")?,
        b.tile(c).ok_or("복제본 타일 없음")?,
    ));
    Ok(())
}

photocraft-cli run \
  --new '{"width":128,"height":128,"background":"transparent"}' \
  --cmd layer.new.layer --params '{"name":"Ink"}' \
  --cmd paint.stroke \
  --params '{"points":[[32,64,1],[96,64,1]],"size":16,"color":"#ff0000"}' \
  --cmd filter.blur.gaussianBlur --params '{"radius":4}' \
  --out exercise.png

정상 호출에서는 붓 자국의 가장자리가 부드러워집니다. 실패 사례마다 새 출력 이름을 사용하면 이전 결과와 혼동하지 않고 확인할 수 있습니다.

실습의 완료 기준은 “실행됐다”에서 끝내지 말고, 어떤 입력에서 어떤 상태가 보존되는지 설명하는 데 두세요. 고급 과제에서는 허용 오차를 키워 통과시키기 전에 기준 구현·출력 표현·비교 방식을 먼저 확인해야 합니다.

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

주당 4~6시간을 가정한 계획입니다. Rust가 처음이라면 1주차를 늘리고, 그래픽스 경험이 있다면 3~4주차에서 직접 손으로 계산하는 시간을 늘리세요. 각 주는 읽을 개념, 소스 근거, 설명 가능한 산출물로 묶었습니다.

9-1. 길을 잃었을 때 돌아올 세 질문

1. 데이터: 이 기능이 바꾸는 값은 Document 안에 있는가, UI 상태에 있는가?
2. 계산: 같은 입력으로 화면 없이 결과를 만들 수 있는가?
3. 검증: 정확성을 무엇과 비교하며, 실패 후 어떤 상태를 보존하는가?

새로운 라이브러리를 많이 외우는 것보다, 기능 하나의 데이터 흐름과 검증 기준을 끝까지 설명하는 편이 오래 남습니다.

10핵심 키워드 사전

11참고 링크

11-1. 저장소와 구현 근거

• 공식 GitHub 저장소 · v0.14.0 릴리스
• 공통 패키지·버전·빌드 설정 · 실제 의존성 잠금 버전
• 명령 레지스트리 · 세션·편집 경계
• 희소 타일과 복사 시 쓰기 · 문서 스냅샷과 실행 취소
• CPU·GPU 결과 비교 테스트 · PSD 기준 이미지·왕복 검사
• 아키텍처 문서 · 개발 안내
• 로컬 제어 프로토콜 · 플러그인 런타임의 제한
• 알려진 기능·호환성 격차 · 품질·성능 점수표

11-2. 관련 기술 공식 자료

• Rust 공식 입문서 · Cargo 워크스페이스 · 표준 라이브러리 Arc 문서
• egui·eframe 공식 저장소 · wgpu 공식 저장소 · WGSL 명세
• Rayon 공식 저장소 · wasm-bindgen 공식 안내
• MCP Rust SDK · wasmi 공식 저장소
• Adobe PSD·PSB 파일 형식 명세 · ICC 색상 프로파일 명세
• TrendShift — 트렌딩 맥락을 살펴볼 출발점

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

코드 규모는 커밋 ff47388의 저장소 전체에서 .git을 제외하고 확장자별로 센 물리 줄 수입니다. 비어 있지 않은 마지막 줄에 줄바꿈이 없어도 한 줄로 셉니다. 파일 수나 줄 수는 기능 수·품질·개발 기간을 직접 나타내지 않습니다.