에이전트마다 소스 코드 브랜치만 나누면 되는 팀이라면 Git worktree부터 쓰는 편이 낫다. LayerFS를 검토할 이유는 작업 디렉터리 전체를 반복해서 준비하고, 중간 상태로 되돌리고, 여러 실험의 변경분을 합치는 일이 실제 병목일 때 생긴다. 도입 판단도 이 차이에서 출발해야 한다.
LayerFS는 에이전트별로 쓰기 가능한 작업 공간을 만들고, 공유된 이력을 바탕으로 체크포인트와 분기·병합을 다루는 프로젝트다. Ephemeral-AI가 MIT 라이선스로 공개한 오픈소스다. 2026년 10월 21일 확인한 v1.0.0 릴리스는 첫 공식 릴리스로 소개돼 있다. 다만 공개 자체가 처음은 아니다. 9월 1일 개발자 프리뷰가 먼저 나왔다. 이 글은 공식 릴리스와 공개 문서를 읽고 정리한 평가 가이드이며, 직접 설치하거나 성능·복구 동작을 시험한 후기는 아니다.
작업 공간의 변경 이력과 외부 백업은 따로 설계해야 한다. 구조를 설명하기 위한 AI 생성 개념도.
Git worktree로 충분한 일부터 구분하기
두 에이전트가 같은 저장소에서 각각 기능을 수정한다고 가정해 보자. 관심사가 커밋할 소스 파일이고, 의존성 설치와 빌드가 부담스럽지 않다면 worktree로 작업 디렉터리를 나누는 방식이 단순하다. 실험이 몇 개뿐이고 필요한 상태를 다시 만드는 비용도 작다면, 버려도 되는 디렉터리를 복사하는 방법으로 충분할 수 있다.
반면 에이전트의 작업에는 소스 외에도 설치한 의존성, 생성 파일, 테스트 도중 만들어진 상태가 섞인다. 이런 상태를 매번 준비하는 데 시간이 들거나 실험 중간으로 자주 돌아가야 한다면 파일시스템 수준의 이력이 유용할 여지가 있다. LayerFS 저장소 설명은 공통 Store의 이력에서 여러 Workspace를 만들고 변경분을 체크포인트로 남기는 구조를 제시한다. 다만 내 프로젝트에서 준비 시간과 저장 공간이 얼마나 줄어드는지는 별도 측정이 필요하다.
체크포인트와 백업을 구분해야 하는 이유
v1.0.0에서 먼저 읽을 부분은 성능 소개보다 저장 안전성 조건이다. 릴리스 문서는 Disposable 프로필에 프로그램 비정상 종료(crash)나 전원 손실에 대한 내구성 보장이 없다고 명시한다. 작업 이력을 조회하거나 이전 상태로 돌아가는 기능이 있어도, 장애 뒤에 그 이력이 온전히 남는다고 가정할 수 없다. 원본과 보존해야 할 결과물은 LayerFS 밖에 따로 보관해야 한다.
업그레이드 조건도 가볍지 않다. SDK, 네이티브 애드온, 데몬은 같은 릴리스 태그를 맞춰야 하며, 0.1.7 이하의 기존 Store는 1.0.0에서 거부된다. 새로 초기화하는 절차를 안전한 자동 마이그레이션으로 해석하면 안 된다. 이미 프리뷰를 사용했다면 보존할 데이터를 먼저 외부로 꺼내고, 새 Store에서 별도 검증하는 계획부터 세우는 편이 안전하다.
실행 환경과 보안 경계를 따로 확인하기
v1.0.0 DSH 안내를 기준으로 살펴보면 Node.js 22.19 이상, pnpm, 빌드한 DeepSeek Harness 등이 필요하다. Live 모드는 Docker를 사용하며, Store 자체는 Linux의 ext4·xfs·btrfs를 요구한다. macOS 통합은 Linux 컨테이너를 거치는 방식으로 이해해야 한다. 네이티브 macOS Store나 Windows 지원을 전제로 계획할 근거는 없다. 지원 범위도 dsh web이며 데스크톱 경로는 미검증으로 적혀 있다.
특히 Sim이라는 이름만 보고 안전한 모의 실행으로 받아들이면 곤란하다. 이 경로의 셸 명령은 컨테이너 없이 호스트에서 실행된다. Live도 여러 Workspace가 하나의 Sandbox 컨테이너를 공유할 수 있다. 작업 파일을 나누는 기능과 악성 코드를 가두는 보안 경계는 별개로 평가해야 한다. 비밀 키나 실제 고객 데이터가 있는 컴퓨터에서 낯선 에이전트 코드를 실행하는 방식으로 첫 시험을 시작하지 않는 것이 좋다.
배포는 소스 기반이다. 이 글은 설치를 직접 검증하지 않았으므로, 복사해 실행할 설치 명령은 싣지 않았다. 현재 설치 안내는 최신 문서를 찾는 출발점으로 삼되, 실제 평가에서는 선택한 태그의 문서와 의존성 조합을 대조해야 한다. 최신 안내가 곧 v1.0.0 조합의 검증 결과는 아니다.
작은 폐기용 프로젝트로 해볼 다섯 가지
첫 평가는 운영 저장소 대신 외부에 원본을 보관한 작은 테스트 프로젝트로 제한하자. 인증 정보와 중요한 파일은 넣지 않는다. 아래 항목은 제품에서 확인한 결과가 아니라, 도입 전에 팀이 직접 확인할 시험 기준이다.
- 기준선 잡기. 같은 프로젝트를 worktree 또는 단순 복사로 준비해 걸리는 시간과 디스크 사용량을 기록한다. LayerFS 평가에도 동일한 작업을 사용한다.
- 저장 경계 확인하기. 소스 파일과 생성 파일을 각각 바꾼 뒤 체크포인트를 만들고 다시 읽는다. 실행 중 변경, 저장된 변경, 커밋된 변경이 어디서 구분되는지 확인한다.
- 분기와 충돌 확인하기. 두 작업 공간에서 서로 다른 파일을 바꾸는 경우와 같은 파일을 바꾸는 경우를 나눠 시험한다. 병합 결과뿐 아니라 충돌이 어떻게 보고되고, 사람이 개입해야 하는 지점이 어디인지 적는다.
- 되돌리기와 반출 확인하기. 이전 상태에서 필요한 의존성과 결과물이 기대대로 보이는지 살핀다. 보존할 파일을 외부 저장소로 옮긴 뒤 LayerFS 없이도 읽을 수 있는지 확인한다.
- 운영 부담 비교하기. 빌드·버전 정렬·문제 재현에 드는 시간을 함께 기록한다. 작업 공간 준비가 빨라져도 유지 부담이 더 크다면 굳이 도입할 필요는 없다.
복구 시험을 하더라도 결과를 과장해서는 안 된다. 폐기용 데이터로 몇 차례 정상 복원에 성공한 것은 비정상 종료·정전 내구성 보장을 대신하지 못한다. CPU·메모리·저장 공간과 실행 시간도 이 글에서는 측정하지 않았다. 라이선스 비용과 운영비 역시 별개다. 인프라와 연결한 모델의 API 사용료까지 없어지는 것은 아니다.
이런 조건이라면 도입을 미루자
LayerFS는 작업 디렉터리 전체를 여러 갈래로 나누고 이전 상태로 돌아가야 하는 팀에 평가할 가치가 있다. 그러나 백업 도구를 찾고 있거나, 대체 불가능한 데이터의 유일한 보관소로 쓰려 하거나, 소스 빌드를 유지할 여력이 없다면 도입을 미루는 편이 맞다. worktree보다 나은 지점이 측정되지 않아도 마찬가지다.
2026년 10월 21일 조사 당시 Hacker News 글은 약 30점과 댓글 12개였고 저장소에는 반올림된 수치로 스타 1.3k개가 표시됐다. 최근 스타 증가량은 검증하지 못했다. 이는 관심의 단서일 뿐 도입 실적이나 급성장 증거는 아니다. 작은 시험에서 준비 비용이 줄고, 충돌 처리와 보존 경계를 팀이 설명할 수 있을 때 다음 단계로 넘어가자.
최초 자료 확인: 2026년 10월 21일. 공식 릴리스·라이선스·호환성 문서 추가 확인: 2026년 10월 22일. 릴리스 페이지의 표시 시각은 시간대가 확인되지 않아 UTC로 환산하지 않았다. 설치·성능·보안·장애 복구는 독립 검증하지 않았다.
함께 읽기: DeepInfer API 서비스 도입 시 살펴볼 점
댓글
댓글 쓰기