포토샵·프리미어를 러스트로 다시 만든 무료 오픈소스 앱 13종 Crafting Apps

그림 1. 13개 앱 저장소의 별·생성일·마지막 푸시. GitHub 기록을 표로 옮긴 화면, 2026-10-26 18:20 UTC 조회

위 화면의 13개는 이미지·영상 생성 AI 서비스를 만드는 ArtCraft 팀이 9월 30일(UTC)부터 GitHub 조직 storytold에 올리기 시작한 앱들입니다. 포토샵, 일러스트레이터, 프리미어 프로, 라이트룸 같은 상용 앱이 하던 일을 처음부터 러스트(Rust)로 다시 쓴 데스크톱 앱이고 모두 무료입니다. 조회한 시각에 13곳 모두 같은 날 안에 새 코드가 올라와 있었고, 별을 합치면 약 18만 7천 개입니다. 그중 39%가 이미지 편집기 PhotoCraft 하나에 몰려 있습니다.

소개 글은 대부분 “포토샵 대체재가 나왔다”에서 끝나지만 13개는 서로 성격이 많이 다릅니다. 그래서 이 글은 앱을 하나씩 칭찬하지 않고 지도를 그립니다. 어떤 일을 하던 동네인지, 저장소가 “있다”와 “쓸 수 있다”를 어떻게 다르게 쟀는지, 별 숫자가 준비도와 얼마나 따로 노는지를 차례로 올려 보고, 사본으로 만져 볼 만한 앱을 고르는 데까지 갑니다.

용어 네 개를 먼저 풀어 둡니다. 러스트는 메모리 오류를 컴파일 단계에서 많이 막아 주는 시스템 프로그래밍 언어입니다. 이 앱들은 Electron(웹 기술로 데스크톱 앱을 만드는 틀)이나 웹뷰 없이 화면까지 러스트로 그립니다. MCP(Model Context Protocol)는 AI 에이전트가 외부 프로그램을 도구로 부르는 공통 규격입니다. 클린룸 구현은 원본 앱의 코드를 보지 않고 공개 명세와 겉으로 드러난 동작만으로 다시 만들었다는 뜻입니다.

열세 앱을 네 동네로 나누는 기준

공식 사이트 getartcraft.com/apps는 13개를 “Crafting Apps”로 묶되 상용 앱의 이름은 적지 않고 분야만 적습니다. 지도를 그리려면 기준이 필요해서 첫째로 “하던 일의 종류”를 잡았습니다. 둘째는 저장소가 스스로 쓴 개발 단계이고, 셋째는 “기능이 있다”와 “일에 쓸 수 있다”를 가르는 두 종류의 퍼센트, 넷째는 관심의 크기인 별입니다.

단계 표기는 사이트와 저장소가 다릅니다. 사이트는 PhotoCraft, PdfCraft, FigCraft만 “초기 알파”로 적고 나머지 10개를 “개발 중”이라 부릅니다. 저장소 첫머리는 대부분 “알파”이고 SoundCraft와 DesignCraft는 “프리 알파”, CADCraft는 “초기 개발”입니다. 같은 앱을 두고 표기가 둘이라는 점이 이 프로젝트의 속도를 잘 보여 줍니다. 문구가 코드보다 늦게 따라옵니다.

앱 13개 말고 하나가 더 있습니다. ArtCraft Launcher(최신 v0.8.1, 10월 25일)는 앱 목록을 보여 주고 내 운영체제와 프로세서에 맞는 빌드를 골라 설치하며, 릴리스의 SHA-256 체크섬으로 파일을 확인하고 업데이트까지 알려 주는 작은 네이티브 앱입니다. 조직에는 공식 앱 페이지의 13개에 들지 않은 저장소(AniCraft, 10월 14일 생성)와 공용 AI 연결 저장소도 있지만 이 글은 13개만 다룹니다.

하나의 명령 장부에 문이 세 개

13개를 한 지도에 올릴 수 있는 이유는 몸통이 같기 때문입니다. PhotoCraft의 메뉴·도구·대화 상자가 하는 동작은 500개가 넘는 이름 붙은 명령으로 한 장부에 등록돼 있습니다. 곡선 조정 레이어를 만드는 동작은 layer.newAdjustmentLayer.curves이고, 메뉴에서 눌러도 터미널에서 불러도 에이전트가 불러도 같은 이름을 지납니다. 화면은 얇은 껍데기이고 일은 엔진이 합니다. 다른 앱들도 같은 규칙을 따라 DesignCraft는 모든 메뉴와 도구 동작을 JSON 제어 채널과 MCP 서버로 구동할 수 있다고 적고, CADCraft와 FilmCraft도 같은 구조입니다.

코드는 크레이트(러스트의 패키지 단위) 24개로 나뉘고 아래층이 위층을 참조하지 못하게 검사 도구(cargo xtask layers)가 막습니다. 그래서 창 없이 엔진만 떼어 CLI와 MCP에 쓸 수 있습니다. 합성은 CPU 합성기가 기준 결과를 내고 GPU(wgpu) 합성기가 같은 결과를 내는지 서로 대조합니다. 개발 지침(AGENTS.md)은 실행 코드에서 unwrap·panic! 같은 비정상 종료 경로를 금지하고, unsafe는 펜 태블릿 입력을 읽는 격리된 크레이트 하나만 예외로 둡니다. 깨진 파일은 오류 메시지로 돌려줄 뿐 앱을 죽이지 않는다는 원칙이고, 충돌을 고칠 때마다 그 충돌을 재현하는 회귀 시험을 함께 넣게 돼 있습니다.

이 구조가 의미를 갖는 곳은 에이전트가 붙을 때입니다. 입구는 세 가지이고 입구마다 건드릴 수 있는 파일의 범위가 달라서, 이 글의 마지막 절에서 따로 다룹니다.

이미지·그림 동네: RAW 현상, 벡터 파일, 조판, 화면 설계

PhotoCraft는 뒤에서 숫자를 따로 읽기로 하고, 같은 동네의 네 앱부터 봅니다. 앱마다 승부처가 다릅니다.

LightCraft는 카메라 색에서 갈립니다. 사진 라이브러리와 RAW 현상을 맡고, 저장소는 기능 수 기준으로 약 82%(핵심 기능은 98%)가 있다고 쓰며 전체 제품 준비도는 61%, 현업 사진가 기준 51%, 가벼운 사용 기준 65%로 따로 적습니다. JPEG와 DNG, 소니·파나소닉·후지필름·니콘·구형 캐논 RAW는 잘 다루지만 카메라 색 보정은 카메라 JPEG에서 뽑은 추정값이고 실측 보정은 없습니다. 올림푸스 압축 RAW와 일부 CR3는 내장 JPEG 미리보기로 대신하며, 피사체 선택 같은 AI 기능은 별도 모델(SAM 3)을 설치해야 돌아갑니다. 네트워크 드라이브의 RAW는 헤더와 미리보기만 읽어 56.5MB를 5.9MB로, 10초를 1초로 줄인다는 시험값도 README에 있습니다.

VectorCraft는 파일 형식의 폭에서 갈립니다. SVG, PDF, PDF 호환 .ai(PDF/X 포함)와 구버전 .ai, EPS, DXF, EMF/WMF를 다루고, PSD는 내보내기와 병합 이미지로서의 열기를 지원합니다. Affinity 문서(.af, .afdesign, .afpub)도 레이어와 곡선째 열어 배치합니다. 핵심 메뉴·도구·효과·형식의 약 88%가 있고 기능 깊이는 약 75%이며, 준비도는 일반 일러스트레이터 기준 65%, 추적한 기능 전체 기준 62%입니다. 11개 앱 중 가장 높은 자체 추정입니다.

FigCraft는 파일을 얼마나 믿느냐에서 갈립니다. 인터페이스 디자인 앱이고 프로토타입 연결, 변수, 개발자 전달 화면(Dev Mode)에서 CSS·HTML·React·Vue·SwiftUI·Compose 코드를 뽑는 기능까지 갖췄습니다. 그러나 저장소는 .fig 파일을 “최선을 다해” 열 뿐 실제 디자인 문서로 점검한 적이 없다고 적고, 동시 편집은 앱에서 호스팅하거나 직접 세운 서버로 하는 첫 미리보기 단계이며 계정·팀·클라우드는 없습니다. 자체 추정 준비도는 49%입니다.

DesignCraft는 샘플 잡지 한 권으로 말합니다. 저장소는 잡지 한 권을 코드로 배치해 자체 렌더러로 내보낸 결과를 싣습니다. 문단 조판은 Knuth–Plass 방식이고 IDML 가져오기·내보내기, INDD 가져오기(별도 저장소 indd-utils), 편집 가능한 .pptx 내보내기, PDF/X-4와 PDF/A-2b, EPUB 내보내기를 지원합니다. 한자·가나 등 일부 문자는 별도 저장소 craft-fonts의 글꼴을 빌드에 끼워야 합니다. 단계는 프리 알파이고 준비도 숫자는 적지 않았습니다.

영상·소리 동네: 코덱을 직접 쓴 앱과 장치를 못 고르는 앱

FilmCraft는 비트스트림 밑바닥부터 새로 썼다고 주장합니다. H.264·HEVC·ProRes·AAC 코덱을 공개 명세만 보고 러스트로 직접 구현했고, GPU 합성은 선형 광 공간에서 하며, 프레임 계산은 정수 시간으로 해서 편집을 거듭해도 어긋나지 않는다고 README가 설명합니다. 6초 960×540 H.264 렌더가 1.3초 걸리고 ffmpeg가 경고 없이 디코딩했다는 측정도 적혀 있지만, 장비 사양이 함께 적혀 있지 않으니 내 컴퓨터의 시간이 아니라 설계가 도는지에 대한 증거로 읽어야 합니다. 기능 폭은 약 86%, 준비도는 약 56%이고, 공식 사이트에서 브라우저판이 없는 앱은 FilmCraft 하나뿐입니다.

EffectCraft는 프로젝트 파일에서 갈립니다. 프로젝트가 읽을 수 있는 JSON(.ecproj)이라 버전 관리 도구에서 변경점이 깔끔하게 비교되고, 효과는 306개이며, Lottie를 불러오고 내보냅니다. 명령줄에서도 같은 렌더 대기열이 돌아 effectcraft-cli render --comp Main --out main.mp4처럼 영상을 뽑습니다. 그러나 존재 비율은 91%로 높은데 준비도는 45%이고, 저장소는 제작 현장 의뢰 작업에는 아직 권하지 않는다고 직접 적습니다. macOS에서 가장 많이 시험했으며 Linux와 Windows에서는 기본 조작 버그가 나온다고도 밝힙니다. 로토 브러시는 MobileSAM 모델(약 40MB)을 설정에서 내려받아야 씁니다.

SoundCraft는 빠진 것을 목록으로 내놓습니다. 오디오 작업 환경이고 메뉴 항목의 94%가 있으며 기능은 존재 기준 약 70%, 준비도는 약 40%로 11개 중 가장 낮습니다. 녹음·편집·믹스·바운스는 처음부터 끝까지 되지만, 오디오 인터페이스와 버퍼 크기를 고르는 일, 컨트롤러로 MIDI를 녹음하는 일, 세션 교환 형식(AAF/OMF)이 아직 없고 번역도 없습니다. 이 셋이 알파로 올라가는 점검표라고 저장소가 적습니다.

문서·사무와 도면 동네: 열고 저장하는 데서 갈리는 승부

사무 앱의 승부처는 기능 목록보다 남이 만든 파일을 열고 저장했을 때 모양이 그대로냐입니다. 저장소들이 이 약점을 비교적 솔직하게 씁니다.

WordCraft는 .docx를 읽고 쓰며 옛 .doc(97-2003) 가져오기, .odt·.rtf·.html·.md·.tex 입출력과 PDF 내보내기를 갖췄습니다. 리본·메뉴 기능의 97%에 명령이 있고, 준비도는 전체 60%, 평소 업무용 55%, 필수 기능만 쓰는 경우 63%입니다. 베타까지 남은 일로는 쪽 나눔(페이지 경계)을 원본 앱에 더 가깝게 맞추는 일, 안정성 점검, 네이티브 인쇄를 꼽습니다.

GridCraft는 .xlsx가 기본 형식이고 표준 함수 513개를 갖췄다고 쓰지만, README는 이 숫자가 구현 완료 개수가 아니라 대응 목록의 크기라고 스스로 못 박습니다. 리본 명령은 89%, 준비도는 50%입니다. 앞으로의 일은 실제 XLSX 파일의 충실도, 아주 큰 통합 문서와 다중 스레드 재계산, 차트 깊이, 옛 .xls 가져오기입니다. ODS는 저장된 값으로만 가져오고 수식은 가져오지 않습니다.

DeckCraft는 .pptx를 열고 저장하며 슬라이드·발표자 노트·유인물을 PDF로 내보냅니다. 추적한 기능의 84%(핵심 기능은 92%)가 있고 준비도는 약 55%입니다.

PdfCraft는 이 동네에서 시험 수치를 가장 구체적으로 내놓습니다. pdf.js의 시험 파일 983개 중 963개가 문제없이 열려 그려지고 충돌은 0건이라고 적었고, 기존 문서를 저장할 때는 원본 바이트를 그대로 두고 변경분만 뒤에 덧붙이는 증분 저장으로 원본을 보존합니다. 계정·원격 측정·클라우드 처리가 없다고 저장소가 밝힙니다. 반면 약점도 분명해서 오피스 문서에서 PDF로 변환하는 기능이 없고 .docx 내보내기는 레이아웃이 깨지며, 쪽 그리기는 아직 다른 크레이트(hayro)를 빌려 씁니다. 준비도는 전문 업무 전체 49%, 일상 업무 55%, 필수만 쓰면 66%로 세 갈래입니다.

CADCraft는 명령줄 입력이 중심인 도면 앱입니다. DXF는 R12부터 2018 버전까지 읽고 R2000으로 쓰며, DWG도 읽고 R2000으로 씁니다. 치수 스타일, 해치, 블록, 구속 조건, 종이 공간 배치와 PDF 플로팅을 갖췄고 인터페이스 언어는 15개입니다. 다만 모델링하지 못하는 개체는 저장할 때 보존되지 않는다고 README가 경고합니다. 단계는 초기 개발이고 준비도 숫자는 없습니다.

있다는 것과 쓸 수 있다는 것 사이의 간격

저장소가 쓰는 퍼센트는 두 종류입니다. 하나는 “기능이 있다”를 세는 존재 비율(메뉴 항목, 기능 목록 기준)이고, 다른 하나는 “일에 쓸 준비가 됐다”는 팀의 주관적 추정입니다. 아래 그림은 13개 README가 공개한 값을 잣대별로 한 칸씩 채운 것이며, 점선 칸은 저장소가 그 값을 적지 않았다는 뜻입니다.

그림 2. 저장소마다 공개한 잣대가 다르다. 존재 비율은 앱마다 센 대상(메뉴 항목, 기능 목록, 리본 명령)이 다르므로 앱 사이 비교는 대략적

존재 비율을 적은 10개 앱 모두에서 첫째 열이 둘째 열(전체 준비도)보다 큽니다. 존재 비율은 5797%인데 전체 준비도는 4062%이고, 차이가 가장 큰 앱은 EffectCraft(91%와 45%, 46%포인트, 편집부 계산)입니다. 존재 비율이 가장 높은 WordCraft(97%)도 준비도는 60%입니다. 기능 목록의 칸을 채우는 일은 빨랐고, 그 칸이 실제 파일을 견디는지는 따로 재야 한다는 뜻입니다.

오른쪽 두 열은 읽는 법이 다릅니다. 필수 기능만 쓰는 사람의 값을 적은 네 앱(PhotoCraft 61%, PdfCraft 66%, WordCraft 63%, LightCraft 65%)은 모두 전체 값보다 높습니다. 반면 일반 업무 값은 PhotoCraft·WordCraft·LightCraft에서 전체보다 낮고 PdfCraft와 VectorCraft에서는 높습니다. 같은 앱도 쓰는 사람에 따라 쓸 만한지가 갈린다는 이야기여서, 소개 글이 말하는 “쓸 만하다”는 어느 사용자 기준인지를 먼저 물어야 합니다. 그리고 이 값은 모두 저장소 팀이 매긴 추정이어서 외부 시험이 아닙니다.

별 7만 개와 준비도 45%

관심의 크기는 별로 볼 수 있습니다. 아래 그림은 가로축을 별 수(로그 눈금), 세로축을 같은 앱의 전체 준비도로 놓았습니다.

그림 3. 별이 가장 많은 앱이 준비도로는 11개 중 공동 9위. 준비도는 각 저장소의 자체 추정

PhotoCraft는 별이 두 번째 앱의 4배 남짓인데 준비도는 EffectCraft와 같은 45%로, 11개 중 아래에서 둘째로 낮은 값을 둘이 나눕니다. 반대로 준비도가 가장 높은 VectorCraft와 LightCraft는 별이 1만~1만 5천 개대입니다. 별은 한 앱에 크게 쏠려 있고, 이 11개에서는 준비도와의 관계가 보이지 않습니다.

속도의 이면도 숫자로 남아 있습니다. PhotoCraft는 10월 2일부터 25일까지 릴리스를 시험 빌드까지 포함해 18번 냈고 병합된 풀 리퀘스트(수정 제안)가 3,234건, 기여자로 집계된 계정이 411개입니다. 열린 이슈는 로드맵이 적은 10월 13일의 953건에서 10월 26일 18:20 UTC의 GitHub 검색 값 2,129건으로 늘었고 열린 풀 리퀘스트도 1,109건 쌓여 있습니다. 코드가 문서보다 빨리 움직이는 흔적은 문서 사이에서도 보입니다. PhotoCraft README는 아직 없는 도구가 15개라고 적지만 같은 저장소의 gaps 문서(10월 25일 갱신)는 빠진 도구가 없다고 셉니다. 그래서 이 글의 숫자는 한 문서를 그대로 옮기지 않고 가장 최근에 갱신된 문서와 GitHub 기록 중에서 골랐습니다.

PhotoCraft의 숫자 읽기: 307, 249, 190은 서로 다른 시험

한 앱 안에서도 같은 일이 벌어집니다. PhotoCraft의 PSD 신뢰도를 말할 때 가장 자주 인용되는 숫자는 “309개 중 307개”인데, 같은 저장소 안에 비슷해 보이는 숫자가 더 있고 각각 잰 것이 다릅니다.

그림 4. 같은 앱의 PSD 시험도 묻는 질문에 따라 99%에서 17%까지. 분모는 시험 모음마다 다르다

첫 줄은 공개 시험 모음(psd-tools)의 파일을 열었다가 다시 저장해도 화면이 그대로인 경우의 수이고, 둘째 줄은 같은 309개에서 PhotoCraft가 그린 결과가 파일에 저장된 합성 이미지와 맞는 경우의 수(gaps 문서가 적은 하한)입니다. 셋째 줄은 포토샵으로 만든 시험 파일 258개의 합성 이미지와 맞는 경우, 넷째 줄은 스마트 필터를 다시 그렸을 때 일치한 경우입니다. 앞의 것은 “열고 저장하는 사이에 내용을 잃지 않는다”는 약속이고 나머지는 “포토샵과 똑같이 보인다”는 약속입니다. 마지막 줄은 부분 기능의 시험이라 표본이 30개뿐입니다. 또 여기 숫자는 모두 PhotoCraft가 포토샵 파일을 읽는 쪽입니다.

반대 방향은 시험이 없습니다. gaps 문서는 내보낸 파일을 제3자 편집기에서 열어 보는 시험이 없다고 직접 적고, 사용자 보고로 “포토샵 26.6에서 우리 파일을 다시 열 수 없다”(#1281), “PSD가 포토샵에서 열리지 않는다”(#2469) 같은 이슈를 나열합니다. 재저장한 파일은 원본과 바이트가 같지도 않습니다. 이미지 리소스, 레이어 레코드, 합성본을 다시 쓰기 때문입니다. 팀이 로드맵 1순위로 잡은 일이 “포토샵이 믿는 PSD”이고 150~250시간으로 추정합니다. 그전까지는 PhotoCraft에서 저장한 PSD를 작업 파일로 쓰지 않는 편이 안전합니다.

앱 안의 영역별 격차도 로드맵에 공개돼 있습니다. 영역별 준비도는 조정·필터와 색상 관리가 70%, 레이어·마스크·스마트 오브젝트가 65%로 높고, 글자 입력(Type)과 작업 공간·패널이 40%, 영상·타임라인이 30%, 생성형 AI가 10%로 낮습니다. 차원별로는 성능이 25%(성능 예산 25개 중 3개만 충족, 10월 17일 기준), 플러그인·액션 생태계가 15%입니다. 전체는 45%(범위 4050%)이고, 팀은 베타까지 에이전트 작업 시간으로 1,1001,800시간이 남았다고 계산합니다.

속도 수치도 같은 방식으로 읽습니다. README는 3.6메가픽셀 이미지에 반지름 180짜리 가우시안 블러가 1초 안에 끝난다고 적지만 측정 장비 사양이 없으니, 큰 반지름도 모든 코어를 써서 느리지 않게 처리하려는 설계가 돈다는 증거로 읽는 것이 맞습니다. 로드맵의 “25개 중 3개”는 성능 시험 목록 전체의 통과율이므로 둘은 모순이 아닙니다. 하나는 잘 된 한 가지 사례이고 다른 하나는 전체 목록의 통과 비율입니다. PhotoCraft는 한글 화면 문구 번역률이 100%로 집계돼 있지만 엔진이 내는 일부 메시지가 아직 영어여서, 로드맵은 모든 언어를 “부분 지원”으로 분류합니다.

클린룸 선언, AI가 쓴 코드, 라이선스

각 저장소는 스스로를 클린룸 재구현이라고 부릅니다. 상용 앱의 코드·셰이더·아이콘·프로파일을 쓰지 않고 공개 명세(PSD 명세, ICC, ISO 32000)와 관찰한 동작만으로 구현했다는 선언이며, 포함한 비코드 자산은 작성자·출처·라이선스를 적은 ATTRIBUTION.md에 모아 둡니다. PhotoCraft 로드맵은 비교 대상인 포토샵 2026 27.11.0을 설치해 측정했다고도 적습니다. 이 선언은 팀이 쓴 문장이어서 제3자가 검증한 것이 아닙니다.

개발 과정이 AI 중심이라는 점은 팀이 숨기지 않습니다. 로드맵은 남은 일을 병합된 풀 리퀘스트 1,004건으로 보정한 에이전트 작업 시간으로 환산하고, 소프트웨어 전문 매체 Phoronix는 10월 8일(UTC) 이 앱들을 Claude Code와 AI 에이전트가 만들었다고 전했습니다. 한 IT 매체는 PhotoCraft를 완전한 포토샵 대체재로 보기 어렵다고 평가하며 글자 조판·브러시·플러그인의 한계를 짚었습니다. 두 보도 모두 Adobe의 대응이나 구체적인 법적 분석은 싣지 않았습니다. 기능을 흉내 낸 앱과 상용 앱의 특허·상표가 어떻게 만나는지는 법률 해석이 갈리는 영역이므로, 회사 제품에 넣거나 납품물에 쓸 계획이라면 법무 검토가 필요합니다. 개인이 학습·취미로 쓰는 데는 이 부담이 작습니다.

라이선스는 단순합니다. 앱은 MIT 또는 Apache-2.0 중에서 고르는 이중 라이선스입니다. 이런 허용형은 고쳐서 상용 제품에 넣고 소스를 공개하지 않고 배포해도 되는 반면, GIMP(GPL-3.0 이상)나 Krita(GPL-3.0) 같은 GPL 계열은 그렇게 만든 배포본에 소스 공개 의무가 따라옵니다. 내가 쓰기만 한다면 차이가 없고, 엔진을 내 제품에 끼워 넣을 때 갈립니다. 다만 ArtCraft 이름과 로고는 라이선스 밖의 상표라서 변경 없이만 쓸 수 있고 포크는 로고를 빼야 합니다.

받기 전에 확인할 것

안정성이 필요한 작업은 지금 쓰는 도구에 두는 편이 안전합니다. 이미지 편집은 GIMP나 Krita(PSD 저장 가능), 벡터는 Inkscape, 영상은 Kdenlive나 Shotcut이 오래 다듬어 온 선택지이고, Crafting Apps는 사본으로 시험해 보는 자리가 현실적입니다. 시험해 보기로 했다면 설치 전후에 아래를 확인합니다. v0.16.0 기준 PhotoCraft 설치 파일은 macOS 유니버설 DMG가 약 99MB, Windows x64 MSI가 약 75MB, macOS용 CLI 압축 파일이 약 72MB, 브라우저판 zip이 약 12MB입니다.

• 내려받는 곳은 공식 사이트 getartcraft.com과 storytold 조직 저장소의 릴리스, 또는 ArtCraft Launcher뿐이다. 검색하면 이름이 비슷한 비공식 소개·다운로드 사이트가 여러 개 나온다
• 받은 파일의 SHA-256을 릴리스에 붙은 SHA256SUMS.txt의 같은 파일 줄과 맞춰 본다(shasum -a 256 파일, Windows는 Get-FileHash)
• Windows 설치 파일은 Get-AuthenticodeSignature로 서명자를 직접 읽는다. README는 서명됐다고 적지만 gaps 문서의 배포 항목에는 코드 서명 인증서를 아직 구하지 못했다는 줄이 남아 있어 문서끼리 어긋난다
• macOS의 CLI는 별도 압축 파일이고 앱 안에는 데스크톱 앱만 있다. 압축을 풀고 spctl --assess --type install -vv로 공증을 확인한다
• 시험용 PSD와 사진은 복사본으로만 열고, 저장은 다른 이름으로 한 뒤 쓰던 앱에서 열어 비교한다
• 브라우저판은 자동 저장과 충돌 복구가 없으니 닫거나 새로 고치기 전에 저장(다운로드)한다. Linux의 Wayland 세션에서는 창에 파일을 끌어다 놓아도 열리지 않으므로 File > Open을 쓴다
• 오프라인 환경이면 선택형 AI 기능(LightCraft의 일부 선택 기능, EffectCraft의 로토 브러시)이 모델을 따로 내려받아야 한다는 점을 먼저 본다. PdfCraft는 계정·원격 측정·클라우드 처리가 없다고 밝힌다

버그나 취약점을 찾았다면 PhotoCraft의 SECURITY.md가 파일 형식 파서, 제어 서버, MCP 서버, 릴리스 서명을 제보 범위로 적습니다. 다만 전용 비공개 신고 창구는 현재 문서에 없다고 밝히고, 악성 시험 파일은 공개 이슈에 붙이지 말고 형식·크기·해시·관찰된 현상·재현 명령만 적으라고 안내합니다.

에이전트에게 폴더 하나만 열어 주기

앱들이 에이전트 연결을 앞세우는 만큼 여기서 접근 범위가 정해집니다. PhotoCraft의 자동화 문서는 입구 세 개를 서로 다르게 지킵니다. 위쪽 줄일수록 넓고 아래쪽 줄일수록 좁게 막힙니다.

그림 5. 같은 명령 장부라도 입구마다 건드릴 수 있는 파일의 범위가 다르다

CLI(photocraft-cli)는 convert·info·run·batch·commands·mcp·serve 등을 제공하며 경로를 운영체제 경로 그대로 받습니다. 작업 폴더 제한이 없고, batch는 출력 폴더가 입력 폴더와 같으면 거절하는 안전장치(--in-place를 주면 해제)만 있습니다. 출처를 모르는 액션 파일은 격리된 계정이나 환경에서만 돌리라고 문서가 적습니다. 헤드리스 MCP는 읽기 루트와 쓰기 루트를 실행할 때 따로 지정하고, 지정하지 않은 쪽은 권한이 아예 없는 것으로 처리됩니다. 루트 밖의 절대 경로, 상위 폴더 이동, 링크를 통한 탈출은 파일에 닿기 전에 거절되고 네트워크 포트는 열지 않습니다. 브리지 모드는 photocraft --control <포트>로 시작한 실행 중인 앱에 붙어 에이전트가 화면을 보고 조작하게 합니다. 256비트 토큰이 있어야 하고 루프백(127.0.0.1)에서만 받으며, 허용 폴더는 CLI가 아니라 앱을 시작할 때 정한 값을 따릅니다. MCP 배치 한 번에 256단계, 응답 8MiB, 동시 연결 16개 같은 상한도 문서에 있습니다.

토큰의 권한은 생각보다 넓습니다. 보안 모델 문서는 토큰이 비밀을 가졌다는 증명일 뿐 일반적인 메서드 권한을 나누지 않는다고 적고, 도구별 권한 범위와 감사 기록은 아직 제안 단계라고 밝힙니다. 도구의 입력 규격(스키마)은 권한 경계가 아니라고도 못 박습니다. 그래서 토큰 파일은 본인만 읽을 수 있는 위치에 두고, 공유 폴더나 로그에 남기지 말며, 프록시나 터널로 외부에 열지 않는 것이 문서의 실무 지침입니다. 에이전트에게 맡길 때는 CLI가 아니라 루트를 지정한 헤드리스 MCP를, 원본이 아니라 복사본만 들어 있는 폴더 하나에만 연결하는 구성이 가장 좁습니다. 루트는 절대 경로로 적어야 합니다. 상대 경로는 에이전트 프로그램을 시작한 위치 기준으로 풀려 의도와 다른 폴더가 열릴 수 있습니다. 문서가 소개하는 형태를 그대로 옮긴 Claude Code 등록은 이렇습니다.

# 1) 사본만 담을 작업 폴더를 만들고, 원본은 건드리지 않게 복사해 넣는다
mkdir -p "$HOME/photocraft-work"
cp ~/Pictures/poster.psd "$HOME/photocraft-work/poster-copy.psd"

# 2) 읽기 루트와 쓰기 루트를 같은 폴더 하나로, 절대 경로로 지정해 등록한다
claude mcp add photocraft -- photocraft-cli mcp \
  --automation-read-root "$HOME/photocraft-work" \
  --automation-write-root "$HOME/photocraft-work"

# 3) 확인용 첫 요청: poster-copy.psd를 열어 레이어 구성을 알려 주고,
#    결과를 poster-v2.png로 내보내라고 시킨다.
#    같은 요청을 ../originals/poster.psd 처럼 루트 밖 경로로 하면
#    도구가 파일을 건드리기 전에 오류로 거절해야 정상이다

# 같은 형태로 다른 앱도 등록할 수 있다 (EffectCraft 예시, 루트 옵션은 앱 README로 확인)
claude mcp add effectcraft -- effectcraft-cli mcp