AI 에이전트 공유 두뇌 파일시스템 sfs — 멀티 디바이스 협업 워크플로우

도입 — 왜 AI 에이전트 워크플로우에 전용 파일시스템이 필요한가

2026년 6월 현재, Claude Code·Codex 같은 AI 코딩 에이전트를 일상적으로 쓰는 개발자라면 한 번쯤은 이런 상황을 겪는다. Mac mini에서 만든 메모 파일을 MacBook의 에이전트는 모르고, 어제 한 세션에서 정리해 둔 결정사항이 오늘 다른 세션의 컨텍스트에는 없는 식이다. 긱뉴스에 게재된 sfs(github.com/runbear-io) 는 여러 AI 에이전트가 같은 폴더를 공유 두뇌(shared brain)로 마운트해 동기화하는 방식으로 이 문제를 풀어준다. 단순 클라우드 드라이브가 아니라 에이전트 워크플로우에 특화된 전용 파일시스템이라 변경 추적, 오프라인 우선, 충돌 안전이라는 세 가지가 한 묶음으로 제공된다.

핵심 명령은 단 한 줄이다.

sfs mnt ./shared --remote s3://my-bucket/workspace

이 한 줄로 시작해 다른 기기에서 같은 remote로 다시 마운트하면 같은 파일이 따라오고, 누가 어떤 기기에서 무엇을 바꿨는지 추적된다. 본문에서는 sfs의 동작 원리, Google Drive 같은 일반 클라우드 동기화와 어떤 차이가 있는지, 설치와 빠른 시작, 실전 활용 패턴, 한계와 전망까지 정리한다.

sfs란 무엇인가 — AI 에이전트 전용 sync 파일시스템

sfs는 로컬 폴더를 동기화 볼륨으로 마운트해주는 CLI 도구다. macOS와 Linux를 지원하며 brew install runbear-io/tap/sfs 한 줄로 설치된다. 백엔드는 S3(s3://), GCS(gs://), S3 호환 저장소(MinIO·Cloudflare R2), 일반 공유 폴더(file://, NAS 포함)까지 모두 호환된다.

README 기준으로 명시된 핵심 특징은 다음과 같다.

• Mount anywhere — sfs mnt ./folder 한 줄로 어떤 폴더든 동기화 볼륨으로 만든다.
• Multi-device sync — 기기들은 각자 자신의 append-only 저널만 쓰므로 락 서비스·중앙 서버가 필요 없고 어떤 object store든 동작한다.
• Change tracking — sfs log 로 디바이스·작성자·시각·파일을 모두 추적. 덮어쓰거나 삭제한 파일도 콘텐츠 주소 기반 저장 덕분에 보존된다.
• Offline-first — 네트워크 없이 폴더는 완전히 동작하고, 복구되면 자동 푸시.
• Conflict-safe — 동시 편집은 (lamport, time, device) 순서로 결정적 재생. 진 쪽은 name.sfs-conflict-- 파일로 보존되어 조용히 사라지는 일이 없다.

즉 sfs는 단순한 "파일 동기화"가 아니라, 에이전트 협업을 위한 두뇌(shared brain) 인프라다. 같은 폴더를 마운트한 에이전트라면 어느 기기에서든 동일한 메모·계획·아티팩트를 즉시 읽을 수 있다.

Google Drive·iCloud와 무엇이 다른가 — 에이전트 워크플로우 관점

긱뉴스 글쓴이는 "처음엔 그냥 Google Drive 같은 걸 쓰면 되지 않나 싶었다"고 토로하지만, 실제 에이전트 워크스페이스로 써 보면 세 가지 큰 문제가 나타난다고 지적한다. sfs가 어떤 차이를 만드는지 비교하면 다음과 같다.

| 항목 | Google Drive / iCloud | sfs |

|------|----------------------|-----|

| 디스크 점유 | 로컬 오프로드 자주 발생 → 에이전트가 읽을 때마다 클라우드 fetch | 항상 로컬 디스크에 실파일 존재 |

| 로드 동작 | 스트리밍 마운트 방식 → Claude가 파일 로드 중 블로킹 빈번 | 일반 파일처럼 즉시 read/write |

| 설계 타깃 | 사람이 GUI에서 클릭하는 워크플로우 | AI 에이전트 워크플로우 |

| 변경 추적 | 파일 단위 diff / 클라이언트 히스토리 | 디바이스·작성자·시각·콘텐츠 주소 기반 |

| 오프라인 | 동기화 지연 발생 | 오프라인 우선, 복구 시 자동 푸시 |

| 충돌 | 클라이언트 정책에 따라 silent overwrite | 결정적 재생 + loser 보존 (.sfs-conflict-*) |

| 백엔드 | 벤더 종속 | S3·GCS·R2·MinIO·file:// 자유 |

핵심은 모든 파일이 항상 로컬 디스크에 실제로 존재한다는 점이다. 에이전트는 일반 파일처럼 즉시 읽고 쓸 수 있고, 백그라운드에서 동기화가 일어난다. 디스크 절약을 위한 오프로드가 없으므로 Claude가 cat 하거나 read_file 호출 시 블로킹이 없다. AI 에이전트 워크플로우를 처음부터 염두에 두고 설계된 도구라 통합 작업이 제로(zero integration)다.

설치와 빠른 시작 — 명령어 5개면 충분

README에 정리된 설치/시작 시퀀스는 다음과 같다.

# 1. 설치 (macOS / Linuxbrew)
brew install runbear-io/tap/sfs

# 또는 소스에서 직접
go install github.com/runbear-io/sfs/cmd/sfs@latest

# 2. 폴더 마운트 + S3 백엔드로 동기화 시작
sfs mnt ./notes --remote s3://my-bucket/notes

# 3. 평소처럼 파일 작업 (에디터·에이전트 모두 동일)
echo "remember this" > notes/memory.md

# 4. 다른 기기에서 같은 remote로 마운트
sfs mnt ./notes --remote s3://my-bucket/notes

# 5. 상태/히스토리/동기화 명령
sfs log ./notes        # 누가, 언제, 어느 기기에서 무엇을 바꿨는지
sfs status ./notes     # 마운트·데몬·펜딩 변경
sfs sync ./notes       # 즉시 한 번 동기화 (데몬이 자동으로도 동작)
sfs umnt ./notes       # 동기화 중단 (파일은 디스크에 남음)

자격 증명은 각 클라우드 표준 체인을 그대로 쓴다. s3:// 는 AWS_PROFILE·~/.aws/credentials·환경 변수·IAM role, gs:// 는 ADC(gcloud auth application-default login) 또는 GOOGLE_APPLICATION_CREDENTIALS, file:// 는 자격 증명 자체가 없다. 별도 인증 시스템을 추가할 필요가 없다.

추가로 이 저장소는 Claude Code agent skill 을 함께 제공한다. .claude/skills/ 디렉토리에 자동 디스커버되므로 Claude Code는 별도 설정 없이 mount/unmount/sync, 백엔드 선택, status/log/identity 검사 명령을 바로 활용한다. 전역으로 쓰려면 ~/.claude/skills/ 로 심볼릭 링크만 걸면 된다.

동작 원리 — 콘텐츠 주소 저널과 Lamport 클럭

README가 설명하는 내부 구조는 다음과 같다.

working folder ←materialize/scan→ local volume store ←push/pull→ object store
                              ~/.sfs/volumes/
                                          ├─ blobs/        content-addressed (sha256)
                                          ├─ journal/      one append-only op log per device
                                          ├─ state.json    what's materialized
                                          └─ sync.json     lamport clock + push cursor

모든 변경은 이 디바이스의 append-only 저널에 put / delete op 로 기록되고, Lamport clock + wall-clock + device ID + author 가 함께 스탬프된다. 파일 콘텐츠는 sha256 기반 콘텐츠 주소 저장소(blobs/)에 들어간다. 동기화는 새 blob을 업로드한 뒤 저널을 업로드하고, 다른 디바이스의 저널과 누락된 blob을 다운로드하는 식으로 동작한다.

각 디바이스는 자기 저널만 쓰므로 동일 객체에 대한 동시 writer가 없고, 따라서 어떤 dumb object store 든 백엔드로 동작한다. 폴더의 상태는 모든 저널을 (lamport, time, device) 순서로 재생한 결정적 결과이며, 모든 디바이스는 같은 뷰로 수렴(converge)한다. 동시 편집은 last-writer-wins 으로 결정되고 진 쪽은 name.sfs-conflict-- 파일로 보존되므로 조용히 사라지는 일이 없다.

실전 활용 패턴 3가지

긱뉴스 글쓴이가 직접 든 활용 사례는 다음과 같다.

1. Support agent ↔ Engineering agent 협업 — 고객 이슈 관련 메모·맥락을 공유 폴더에 두고 두 에이전트가 함께 본다.
2. Mac mini ↔ MacBook 간 변경 공유 — 기기 간 파일/폴더 변경이 즉시 따라온다.
3. 회사 위키(company brain) — 팀원들 각자의 에이전트가 같은 폴더에 회사 위키를 누적한다.

추가로 README가 강조하는 시나리오는 "여러 기기에서 같은 ~/agent-workspace 를 마운트"하는 것이다. 메모·계획·메모리 파일·아티팩트가 모든 머신을 따라다니며 누가 어떤 에이전트/사람이 무엇을 바꿨는지 전체 audit trail 이 남는다. 회사 wiki 운영, 멀티 디바이스 개발, 에이전트 간 컨텍스트 공유 같은 워크플로우에서 강점이 두드러진다.

한계와 전망 — 초기 버전이라 남은 과제

긱뉴스 원문 마지막에 "아직 초기 버전이라 피드백/이슈 환영합니다" 라고 명시되어 있다. README 기준 다음은 미해결·제한 영역이다.

• 플랫폼 — macOS와 Linux만 지원. Windows는 아직 공식 빌드가 없다.
• 백엔드 안정성 — append-only 저널을 dumb object store에 두는 설계라 IAM 정책이 빈번한 환경에서는 인증 만료·버킷 정책 변경에 민감하다.
• 대용량 파일 — 콘텐츠 주소 기반 sha256 스토어라 큰 단일 파일(GB 단위)에서는 blob 단위 처리 비용이 커진다.
• 부분 동기화·필터 — 폴더 단위 동기화가 기본이고 .gitignore-스타일 부분 동기화는 향후 과제로 보인다.

2026년 6월 시점에서 sfs는 에이전트 협업 인프라의 초기 생태계를 형성하는 단계다. Claude Code skill 이 동봉되어 있고, S3·GCS·R2·NAS 까지 백엔드가 자유롭다는 점에서 멀티 에이전트·멀티 디바이스 워크플로우의 기반 도구로 빠르게 자리잡을 가능성이 높다. Windows 지원, 부분 동기화, GUI 클라이언트 같은 확장만 더해지면 에이전트 협업 파일시스템의 사실상 표준이 될 여지가 충분하다.

정리

sfs는 AI 에이전트가 여러 기기/세션에서 같은 두뇌를 공유하도록 만든 sync 파일시스템이다. 한 줄의 sfs mnt ./folder --remote s3://... 로 폴더를 마운트하면 모든 기기에서 같은 메모·계획·아티팩트가 따라다니고, 콘텐츠 주소 기반 변경 추적·오프라인 우선·결정적 충돌 재생이 기본으로 제공된다. Google Drive / iCloud 와 달리 오프로드 없이 항상 로컬 실파일이 존재해 에이전트가 블로킹 없이 즉시 read/write 가능하며, s3:// · gs:// · file:// 모두 백엔드로 쓸 수 있어 클라우드 종속이 없다.

지금 당장 시작하려면 brew install runbear-io/tap/sfs 로 설치하고, S3 버킷 하나만 준비한 뒤 sfs mnt ./notes --remote s3://my-bucket/notes 부터 실행해 보면 된다. Mac mini에서 만든 메모가 MacBook 에이전트에 그대로 따라오는 순간, "왜 이제야 이런 도구가 나왔을까" 라는 생각이 자연스럽게 든다. 2026년 6월 현재로서는 멀티 에이전트 협업 워크플로우의 가장 가벼운 시작점이 sfs 다.