artcraft 딥다이브
— 장면을 만들고 AI를 지휘하는 창작 도구의 설계

1프로젝트 한줄 요약

ArtCraft는 이미지·영상 생성을 중심으로, 캔버스 편집과 3D 장면 구성, 여러 생성 제공자 연결을 묶은 데스크톱 창작 도구입니다. README는 이를 “예술가를 위한 IDE”라고 소개합니다. 개발자가 코드 편집기 안에서 여러 도구를 쓰듯, 창작자가 장면 구성과 생성 결과를 한 흐름 안에서 다루게 하려는 방향입니다.

이 저장소에서 배울 핵심은 AI 모델의 내부보다, 창작 화면과 외부 생성 작업을 안정적으로 연결하는 앱의 구조입니다. 기본 앱은 React 화면을 Tauri로 감싸고 Rust가 인증·네트워크·작업 추적을 담당합니다. 루트 Cargo.toml의 default-members도 crates/desktop/artcraft를 가리킵니다.

사용자 행동을 코드의 책임으로 바꿔 보기

화면 편집은 프론트엔드 라이브러리에서, 계정과 작업 추적은 데스크톱 Rust 크레이트에서 찾을 수 있습니다. 한 기능의 양쪽 끝을 함께 읽으면 “누가 데이터를 가지고 있고, 누가 다음 행동을 결정하는가”가 드러납니다.

코드의 또 다른 입구는 artcraft-native/입니다. egui 기반의 별도 Rust 앱으로, 기본 Tauri 앱과 API 클라이언트 크레이트를 공유합니다. 같은 제품 영역을 웹 기술과 Rust UI로 각각 풀어낸 사례라 비교 학습에 좋습니다.

2왜 주목받는가

선정 기준은 TrendShift Monthly #5이며, 2026-10-23 GitHub 기준 스타는 35,748개입니다. 다만 순위와 누적 스타만으로 특정 기능이 유행의 직접 원인이라고 증명할 수는 없습니다. 아래는 README의 제품 방향과 소스 구조에서 읽을 수 있는 관심을 끌 만한 이유입니다.

• 문장 외의 입력 수단: README는 구도·캐릭터·카메라 통제를 강조합니다. 실제로 pagedraw와 pagescene이라는 큰 편집 모듈이 분리되어 있습니다.
• 생성 제공자를 바꾸는 연결 계층: Rust의 artcraft_router에 제공자별 클라이언트와 요청 변환이 모여 있습니다. 계정·인증·지원 조합에 따른 제약도 코드에 드러납니다.
• 생성 이후의 작업까지 연결: 결과 파일·배치·썸네일을 작업 기록과 연결합니다. 단순히 API 응답을 화면에 출력하는 수준을 넘어갑니다.
• 공개된 응용 프로그램의 복잡성: 이미지·영상·오디오·3D가 만나는 앱에서 상태·이벤트·실패 처리를 함께 공부할 수 있습니다.

ArtCraft의 설계적 매력은 모델 선택지를 늘리는 데 더해, 생성 전의 시각적 의도를 편집 가능한 상태로 만든다는 점에 있습니다. 다만 결과의 품질·속도가 다른 제품보다 높다는 비교 실험은 이 코드 분석으로 확인할 수 없습니다.

어떤 작업 방식과 비교하면 차이가 보일까?

ComfyUI의 노드 그래프·재사용 작업 흐름 설명은 공식 README 기준입니다. 위 표는 작업 방식의 비교이며 기능 전수 조사나 성능 순위가 아닙니다. ComfyUI에도 클라우드 사용 경로가 있으므로 “ComfyUI는 로컬, ArtCraft는 클라우드”처럼 양분하면 부정확합니다.

README의 “62개 모델” 카탈로그에는 비활성·제한 표시가 섞여 있습니다. 실제 화면도 서버의 모델 목록을 받아 필터링합니다. 따라서 카탈로그 숫자를 “지금 누구나 실행할 수 있는 모델 수”로 읽어서는 안 됩니다.

3기술 스택 전체 지도

이 저장소의 “백엔드”는 우선 데스크톱 앱 안의 Rust 코어를 뜻합니다. 운영 API 서버 전체가 들어 있는 것은 아닙니다. AGENTS.md와 _docs/dev_setup.md는 서버·회사 도구·웹사이트 빌드가 별도 artcraft-services 저장소에 있다고 설명합니다.

Rust 코어: 명령·HTTP·비동기 작업·로컬 DB

데스크톱 Cargo.toml에는 Rust edition 2021과 rust-version = "1.77.2"가 남아 있습니다. 그러나 sqlite_tasks와 artcraft_router는 edition 2024입니다. 이 단일 필드를 저장소 전체의 최소 Rust 버전 보장으로 해석하면 안 됩니다. CI는 stable 툴체인을 사용합니다.

프론트엔드: 화면 상태와 픽셀·3D·영상의 만남

Three.js의 기본 단위는 장면·카메라·렌더러입니다. 이 개념을 먼저 익히면 장면 편집 코드가 훨씬 쉬워집니다. 공식 장면 입문 문서는 이 세 요소의 관계를 설명합니다. ArtCraft 전체 엔진을 처음부터 읽기 전에 작은 장면 하나로 관계를 익히면 좋습니다.

빌드·배포·검사: 두 언어의 산출물을 묶는 연결 고리

frontend/apps/artcraft/vite.config.ts에는 wasm(), topLevelAwait(), 워크스페이스 소스 경로 해석과 React 중복 방지 설정이 있습니다. 라이브러리의 미리 빌드한 결과물 대신 소스를 연결하는 방식도 눈여겨보세요.

설정 근거: 루트 Cargo.toml, 프론트엔드 의존성, 앱 의존성, npm 잠금 파일, Cargo 잠금 파일.

4아키텍처 심화 분석

먼저 실행 경계를 봅시다. 기본 앱의 main.rs는 artcraft_app_lib::run()을 호출합니다. crates/desktop/artcraft/src/lib.rs의 run()이 플러그인을 등록하고, .manage(...)로 상태를 보관하며, 명령 처리기를 연결합니다. 화면은 시스템 WebView 안에서 실행됩니다.

Tauri의 명령과 이벤트는 프로세스 사이의 통신 수단입니다. 화면에서 Rust를 부르는 것은 일반 함수처럼 보이지만, 실제로는 직렬화된 메시지가 경계를 통과합니다. 시스템 WebView와 코어의 역할은 공식 프로세스 모델과 IPC 문서를 참고하세요.

이 도식은 핵심 책임을 요약한 것입니다. 모든 HTTP 요청이 생성 명령을 통과하는 것은 아닙니다. frontend/libs/tauri-utils/src/lib/FetchProxy.ts는 데스크톱에서 Tauri HTTP 플러그인, 일반 브라우저에서는 기본 fetch를 선택합니다. 모델 목록·미디어 조회 등에는 별도의 HTTP 호출 경로도 있습니다.

패턴 1. 경계에서 바꾸고, 새 API 필드는 보존하기

crates/desktop/artcraft/src/core/commands/generate/generate_image/generate_image_command.rs의 generate_image_command()는 uses_artcraft()와 uses_legacy_image_endpoint()를 확인합니다. 일반 ArtCraft 요청은 omni::generate()로, 일부 기존 편집 모델과 다른 제공자는 기존 처리 경로로 보냅니다.

아래는 crates/desktop/artcraft/src/core/commands/generate/omni/request.rs의 핵심 구조입니다. 명시된 세 frontend_* 필드는 완료 결과를 받을 화면과 전달할 정보를 기록합니다. 이 필드들과 provider를 제외한 나머지는 JSON 맵에 모아 새 모델 옵션이 추가돼도 쉽게 탈락하지 않게 합니다.

// 핵심 구조 발췌: 로컬 메타데이터는 명시적인 필드
#[derive(Clone, Deserialize, Serialize)]
pub struct OmniRequest {
  pub provider: Option<GenerationProvider>,
  pub frontend_caller: Option<TauriCommandCaller>,
  pub frontend_subscriber_id: Option<String>,
  pub frontend_subscriber_payload: Option<String>,
  #[serde(flatten)]
  pub fields: Map<String, Value>,
}

OmniRequest::api_fields()는 API에 전달할 필드만 복사하고 이름을 정리합니다. 이미지의 batch_size를 image_batch_count로, 영상의 옛 image_media_token을 start_frame_image_media_token으로 바꾸는 식입니다. canonical_model_id()는 기존 모델 별칭을 새 ID로 바꾸고, 모르는 ID는 그대로 통과시킵니다.

// 학습용 입력: 외부 요청을 보내지 않고 변환 결과만 읽습니다.
{
  "model": "future_image_v9",
  "batch_size": 2,
  "new_option": { "strength": 0.4 },
  "frontend_subscriber_id": "canvas-tab-3"
}

// api_fields(Modality::Image)의 결과
{
  "model": "future_image_v9",
  "image_batch_count": 2,
  "new_option": { "strength": 0.4 }
}

새 옵션 보존은 새 옵션의 유효성 보장과 다릅니다. 실제 지원 여부와 값 검증은 서버 응답까지 봐야 합니다. 파일 안의 future_model_and_options_survive_without_desktop_metadata 테스트는 이런 경계의 의도를 보여줍니다.

여기에는 흥미로운 예외도 있습니다. uses_artcraft()는 grok_로 시작하는 모델이나 Grok 제공자 값도 ArtCraft 경로로 보냅니다. 파일 주석은 네이티브 Grok 경로를 의도적으로 비활성화했다고 설명합니다. 따라서 Grok 관련 디렉토리가 존재한다는 사실만으로 현재 기본 화면이 직접 Grok에 연결된다고 판단하면 안 됩니다.

패턴 2. 접수와 완료를 나누고, 로컬 기록으로 연결하기

crates/desktop/artcraft/src/core/commands/generate/omni/dispatch.rs의 generate()는 로그인 정보를 확인하고, 요청 필드를 정리한 뒤 /v1/omni_gen/generate/{종류}에 POST합니다. 서버 응답에서 받은 작업 ID를 로컬 DB에 기록하고 접수 이벤트를 보냅니다. 이 시점에 최종 이미지가 만들어진 것은 아닙니다.

1. idempotency_token이 없거나 null이면 UUID를 넣습니다.
2. 견적 전용 estimate_only는 실제 생성 요청에서 제거합니다.
3. job_tokens()가 대표 ID와 all_job_tokens를 중복 없이 모읍니다.
4. 각 ID를 TaskEnqueueSuccess::insert_into_task_database_with_frontend_payload()로 기록합니다.
5. 이후 별도의 상태 조회 루프가 원격 완료와 로컬 작업을 맞춥니다.

생성 API의 접수 성공과 결과물의 완성은 서로 다른 사건이며, 작업 ID가 두 사건을 연결합니다. API를 부른 함수 하나가 끝날 때까지 화면 전체를 묶어두지 않는 것이 이 구조의 출발점입니다.

키가 자동 생성된다는 사실만으로 중복 실행을 완전히 막았다고 볼 수는 없습니다. 같은 논리적 요청을 다시 보낼 때 새 키를 만들면 서버는 별개의 요청으로 볼 수 있습니다. 재시도 동안 같은 키를 유지할지, 서버가 어떻게 보관하는지는 별도로 설계해야 합니다.

로컬 장부는 무엇을 기억할까?

_database/sql/artcraft_migrations/20250708000000_create_tasks_table.sql에는 작업 상태·종류·제공자·원격 ID·화면 구독 정보·성공 결과·실패 이유가 함께 정의되어 있습니다. 이미지 파일 자체를 SQLite 안에 넣는 구조로 읽으면 안 됩니다.

-- 실제 스키마의 일부 필드만 추린 읽기용 예시
CREATE TABLE tasks (
  id TEXT NOT NULL PRIMARY KEY,
  task_status TEXT NOT NULL,
  task_type TEXT NOT NULL,
  provider TEXT,
  provider_job_id TEXT,
  frontend_subscriber_id TEXT,
  frontend_subscriber_payload TEXT,
  on_complete_primary_media_file_cdn_url TEXT,
  on_failure_message TEXT
);
-- 원본에는 모델·배치·날짜·실패 유형 등의 필드도 있습니다.

crates/schema/database/sqlite_tasks/src/connection.rs의 run_migrations()는 SqliteJournalMode::Wal을 설정하고 마이그레이션을 바이너리에 포함합니다. crates/desktop/artcraft/src/core/state/task_database_version.rs의 버전은 7입니다.

완료는 폴링으로 발견합니다

crates/desktop/artcraft/src/services/storyteller/threads/storyteller_task_polling_thread/storyteller_task_polling_thread.rs의 polling_loop()는 5,000ms를 기다린 뒤 list_session_jobs(..., States::All)을 호출합니다. 작업 ID로 로컬 레코드를 찾아 성공·실패 처리기로 넘깁니다. 실시간 서버 푸시가 이 경로의 중심은 아닙니다.

handle_storyteller_successful_job.rs의 handle_successful_job()는 자동 다운로드 처리를 먼저 시도하고, DB 성공 상태를 갱신한 뒤 완료 이벤트를 보냅니다. 화면의 useGenerationCompleteEvent()는 generation-complete-event를 구독해 소리와 알림을 표시합니다.

이 순서는 유용하지만 정확히 한 번 전달을 보장하지는 않습니다. DB 갱신과 이벤트 전송이 하나의 원자적 트랜잭션은 아니기 때문입니다. DB 갱신 뒤 앱이 종료되면 그 이벤트가 다시 전송되지 않을 수 있습니다. 화면은 필요할 때 작업 목록을 다시 읽어 상태를 복원할 수 있어야 합니다.

패턴 3. 제공자 차이를 어댑터에 모으기

crates/api_clients/artcraft/artcraft_router/src/client/router_client.rs의 RouterClient는 제공자별 클라이언트를 enum으로 표현합니다. MultiRouterClientBuilder는 사용할 클라이언트를 선택해 조립하고, 없는 클라이언트를 요청하면 ClientNotConfigured 오류를 돌려줍니다.

crates/api_clients/artcraft/artcraft_router/src/generate/generate_image/generate_image_request_builder.rs의 GenerateImageRequestBuilder::build2()는 (provider, model) 조합을 보고 요청을 만듭니다. 미지원 조합은 명시적 오류가 됩니다. ImageGenerationRequest::send_request()는 실제 제공자 클라이언트로 전송합니다.

이 라우터의 지원 enum과 ArtCraft Omni의 동적 모델 경로는 같은 층이 아닙니다. ArtCraft Omni는 새 문자열 옵션을 전달하고, 라우터의 특정 경로는 알려진 제공자·모델 조합을 변환합니다. “모델을 하나 추가하면 모든 제공자에서 즉시 사용 가능”한 구조는 아닙니다.

화면에도 같은 원칙이 보입니다. frontend/libs/components/pagescene/src/lib/adapter.ts의 PageSceneAdapter는 생성·저장·업로드 등의 계약을 정의합니다. 앱 쪽 useTauriPageSceneAdapter.tsx가 Tauri·HTTP 연결을 채웁니다. 재사용 3D 편집기에 플랫폼 지식을 몰아넣지 않는 방식입니다.

패턴 4. 엔진의 사건을 UI 상태로 번역하기

frontend/libs/components/pagescene/src/lib/engine/events/EngineEventBus.ts의 EngineEventBus는 이벤트 생성자별로 리스너 집합을 보관합니다. subscribe()는 해제 함수를 반환하고, emit()은 해당 종류를 구독한 함수들만 호출합니다.

// EngineStoreBridge의 실제 연결 방식 발췌
bus.subscribe(SelectionChangedEvent, (e) =>
  usePageSceneStore.getState().setSelectedObject(e.selection),
);

// 엔진의 선택 변경 → 화면의 선택 상태 변경
// 엔진 내부 전체가 React 컴포넌트를 알 필요는 없습니다.

EngineStoreBridge.ts의 생성자가 이러한 구독을 모읍니다. 장면 엔진이 객체를 선택했다고 알리면 브리지가 Zustand 저장소를 변경하고, 화면이 그 상태를 읽습니다. 이벤트 종류 검색은 맵으로 하지만 리스너 호출 비용은 해당 구독자 수에 비례합니다. “이벤트 처리가 전부 O(1)”이라고 확대하면 안 됩니다.

이 브라우저 내부 이벤트 버스와 Tauri 이벤트는 서로 다른 통신 수단입니다. 전자는 같은 JavaScript 실행 영역 안에서 엔진과 UI를 연결하고, 후자는 Rust 코어와 WebView의 경계를 넘습니다. “이벤트”라는 이름이 같아도 범위를 구분하세요.

비교 읽기: Rust UI는 같은 비동기 문제를 어떻게 풀까?

artcraft-native/src/backend/mod.rs의 Backend::new()는 Tokio 작업 스레드 4개와 std::sync::mpsc::channel()을 만듭니다. Backend::drain()은 도착한 Event를 모아 UI에 넘깁니다. UI가 네트워크 응답을 직접 기다리지 않게 하는 역할은 비슷하지만, Tauri IPC를 사용하지 않습니다.

Native README는 이미지·영상·오디오 생성 화면을 구현했다고 설명하며, 다른 도구는 웹 앱으로 연결하는 준비 중 화면이라고 밝힙니다. 기본 Tauri 앱의 2D·3D 편집 기능이 Native에 모두 옮겨졌다고 볼 수 없습니다. 이 비교는 성능 우열보다 같은 비동기 경계를 다른 UI 환경에서 표현하는 방식에 초점을 맞추세요.

핵심 근거: Omni 생성·견적 처리, 요청 변환과 테스트, 엔진과 UI 연결.

5디렉토리 구조 해부

비슷한 이름을 분리해서 기억하기

crates/vendor/는 모두 직접 작성한 코드라는 뜻이 아닙니다. 데스크톱 Cargo.toml 주석은 HTTP 플러그인의 쿠키 내부 접근 때문에 수정 사본을 사용한다고 설명합니다. 원본과 다른 책임이 생긴 만큼 업데이트 때 변경을 유지해야 하는 비용도 있습니다.

처음부터 끝까지 읽는 대신 한 줄기를 고르기

1. frontend/libs/tauri-api/src/lib/generate/GenerateImage.ts에서 요청의 입력 형태를 봅니다.
2. generate_image_command()에서 경로 선택 조건을 읽습니다.
3. 생성 명령의 OmniRequest와 generate()에서 필드 변환·원격 접수·로컬 기록을 찾습니다.
4. storyteller_task_polling_thread.rs에서 완료를 발견하는 지점을 찾습니다.
5. useGenerationCompleteEvent.ts로 돌아와 사용자에게 어떤 피드백이 보이는지 확인합니다.

이 경로를 읽은 뒤 장면 편집이나 영상 합성으로 넓히면 됩니다. 수천 개 파일을 한꺼번에 이해하려 하기보다, 요청·응답·상태·이벤트 네 가지를 표시한 지도를 먼저 그리세요.

6학습 포인트 (기술별)

이 코드를 공부할 때는 정상 동작을 따라가는 데서 한 걸음 더 나아가, 응답이 늦거나 순서가 뒤집힐 때를 질문해 보세요. 비동기 앱의 어려움은 요청을 보내는 한 줄보다, 오래된 응답과 사라진 화면을 다루는 데 있습니다.

// SceneState의 세대 번호 방식을 축약한 학습용 예시
let generation = 0;

async function selectImage(id: string) {
  const myGeneration = ++generation;
  const image = await loadMockImage(id);
  if (myGeneration !== generation) return;
  showImage(image);
}
// loadMockImage와 showImage는 별도 학습용 함수입니다.

처음 공부할 때는 위 주제 중 하나만 골라도 충분합니다. 예를 들어 React 경험이 있다면 이미지 선택의 경쟁 상태부터, Rust를 배우고 있다면 Option과 Result를 쓰는 제공자 접근부터 시작하세요.

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

원격 모델을 호출하는 데 필요한 장비와 3D 장면을 부드럽게 편집하는 데 필요한 장비는 서로 다른 문제입니다. 주요 생성 명령이 외부 API로 향하므로, 이 앱을 사용한다는 이유만으로 로컬 대형 모델용 VRAM을 요구한다고 볼 근거는 없습니다. 반면 장면·영상 편집에는 로컬 그래픽·메모리 자원이 사용됩니다.

RAM·디스크·GPU 숫자는 어떻게 읽어야 할까?

README와 개발 환경 문서에는 제품 전체의 공식 최소 RAM·VRAM·디스크 용량 표가 없습니다. 따라서 임의의 “최소 8GB”나 “VRAM 12GB 필수”를 공식 요구사항으로 제시할 수 없습니다. Rust 빌드 캐시와 npm 의존성, 편집 미디어가 모두 디스크를 차지하므로 소스 폴더 크기를 설치 용량으로 쓰면 안 됩니다.

Windows 게시 워크플로는 프론트 빌드에 NODE_OPTIONS=--max-old-space-size=8192를 설정합니다. 이는 Node 프로세스의 힙 한도를 조정한 값이며, 제품이 RAM 8GB 컴퓨터에서 충분히 동작한다는 측정 결과가 아닙니다.

개발 설정에서 드러나는 현실적인 제약

• tauri.conf.json의 기본 개발 주소는 localhost:5173이지만, 결합 Unix 실행기는 127.0.0.1의 5193부터 빈 포트를 찾습니다. 설정 파일 한 줄만 보고 실제 포트를 단정하지 마세요.
• 결합 실행기는 Vite 소켓이 열린 뒤 그 포트를 Tauri에 전달합니다. HTTP와 HMR은 같은 선택 포트를 쓰며 Rust 명령 통신에 별도 HTTP 서버 포트가 필요한 구조가 아닙니다.
• frontend/scripts/unix-dev.mjs는 기본으로 SQLX_OFFLINE=true를 전달합니다. 이는 쿼리 검사 환경을 위한 설정이며 서비스 인증·모델 목록·생성을 대신하지 않습니다.
• Native 앱에는 Midjourney 로그인용 wry 의존성이 있습니다. “주 UI가 egui”라는 사실을 “어떤 WebView도 사용하지 않는다”로 확대하면 안 됩니다.

플랫폼 의존성의 구체적인 설치 조건은 Tauri 공식 사전 요구사항, 앱의 현재 개발 흐름은 ArtCraft 개발 문서를 참고하세요.

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

아래 과제는 원본 소스를 읽고 별도의 학습용 프로젝트에 작은 모형을 만드는 방식입니다. API 키나 실제 계정 대신 가짜 응답을 사용합니다. 실제 모델 호출을 모의 응답으로 바꾸면, 비용과 생성 시간에 흔들리지 않고 앱의 상태 설계에 집중할 수 있습니다.

// 가짜 입력과 기대 출력: 실제 API 요청이 아닙니다.
const input = {
  model: "future_image_v9",
  batch_size: 2,
  image_batch_count: 3,
  new_option: true,
  frontend_subscriber_id: "tab-7",
};

const expected = {
  model: "future_image_v9",
  image_batch_count: 3,
  new_option: true,
};

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

JavaScript 함수·배열·객체와 기본 HTML을 아는 독자를 기준으로 잡았습니다. Rust가 처음이라면 소유권·빌림·Option·Result를 익히는 준비 기간을 추가하세요. 각 주차의 결과물은 같은 작은 가짜 생성 앱에 쌓아갑니다.

학습의 완성 기준은 라이브러리 이름을 많이 아는 것이 아니라, 요청 하나의 성공·실패·재시작 경로를 설명하고 구현하는 것입니다. 6주차까지도 외부 모델이 꼭 필요하지 않습니다. 화면 조작과 작업 수명이 연결되면 핵심 설계는 충분히 연습한 셈입니다.

그다음에는 관심에 따라 갈라집니다

• 프론트엔드 중심: 장면 이벤트를 필요한 UI 상태로만 옮기기, 이미지·텍스처 수명 관리, 편집 결과 내보내기를 공부합니다.
• 시스템 중심: 재시도·속도 제한·요청 식별·DB 복구를 공부하고, 서버 계약이 없는 경우의 한계를 정리합니다.
• 그래픽 중심: 좌표계·카메라·투영·레이어·알파 합성을 익힌 뒤 영상 합성기의 캐시 구조로 확장합니다.
• Rust UI 중심: artcraft-native의 채널과 Event 처리를 Tauri 앱과 비교합니다. 인증·API 클라이언트는 공유하면서 UI 경계는 달라지는 점을 찾아보세요.

10핵심 키워드 사전

11참고 링크

프로젝트와 핵심 소스

• 공식 저장소 · 공식 제품 사이트 · artcraft-v0.41.0 릴리스
• 커밋 800217e의 README · 로드맵 · TrendShift
• Tauri 앱 초기화·상태·명령 등록 · 화면의 이미지 생성 요청
• 생성 경로 선택 · API 필드 정리 · 원격 접수와 로컬 기록
• 조회 전 5초를 기다리는 루프 · 결과 처리 순서
• 로컬 작업 스키마 · DB 연결과 재생성 정책
• 3D 편집기의 플랫폼 계약 · 이벤트 버스 · 캔버스 상태와 오래된 응답 방지
• 별도 Rust UI 앱 설명 · Native API·채널 처리 · 라이선스 적용 범위와 제3자 자산 고지

공식 기술 학습 자료

• Rust 공식 책 · Tokio 비동기 입문 · Serde flatten 설명
• Tauri 프로세스 모델 · Tauri IPC · 플랫폼 사전 요구사항
• React 공식 학습 · Zustand 입문 · Konva 문서
• Three.js 장면 입문 · SQLite WAL · SQLx 0.7.4 API
• egui 공식 저장소 · 작업 방식 비교: ComfyUI 공식 README

저장소 현황 (GitHub 메타데이터는 2026-10-23 기준)

줄 수는 기능의 완성도나 직접 작성한 코드의 양을 뜻하지 않습니다. 특히 frontend/apps/artcraft/app/public/의 자산·보조 코드와 crates/vendor/까지 포함한 값입니다. 실제 학습은 전체 크기보다 한 기능의 호출 경로를 기준으로 나누는 편이 좋습니다.

ArtCraft를 통해 가져갈 가장 큰 배움은, 복잡한 창작 기능을 요청·상태·저장·이벤트의 경계로 나누어 읽는 방법입니다. 작은 모의 생성 앱에서 이 경계를 먼저 구현하면, 큰 저장소도 기능 단위로 차근차근 이해할 수 있습니다.