파일은 사용자가 데이터를 직접 소유할 수 있게 해주는 근본적인 자유의 형태임
이는 기밀성, 무결성, 가용성의 주권을 가능하게 함
디지털 자유의 핵심 축으로서, FOSS 라이선스와 동등하게 인식되어야 함
LLM의 추론 능력 덕분에 이제는 파일 구조를 걱정하지 않아도 됨
자연어 자체가 파일 안에 존재하고, 가독성이 곧 스펙이 됨
읽기 쉬운 사람이면 누구나 파일에 쓸 수 있고, REPL처럼 즉시 실행할 수 있음
그래서 Apple 같은 대형 기술 기업들이 파일 개념을 없애려는 시도가 불편함
데이터가 앱에 묶여 독립적으로 존재하지 못하게 만들고, 가져오기/내보내기도 어렵게 함
나는 이런 문제를 해결하기 위해 백업에서 데이터를 세분화된 파일 단위로 추출해 개인 디지털 라이브러리로 옮기는 도구를 만들고 있음
불변 데이터는 보관으로 충분하지만, 수정 가능한 데이터는 다시 ‘살아있는’ 형태로 앱에서 편집 가능하게 만드는 게 가장 큰 과제임
설정 파일은 Windows Registry 같은 중앙 저장소보다 훨씬 낫다고 생각함
임시 변경과 공유가 쉽고, 설정의 의미가 명확히 정의됨
Windows가 파일을 3등 시민처럼 취급하는 점이 마음에 들지 않음
SaaS 관점에서도 같은 생각을 함
코드가 일시적이고 도메인 특화될수록, 데이터(파일)는 표준적이고 지루할 정도로 안정적이어야 함
특정 앱만 읽을 수 있는 포맷은 기술 부채이며, 결국 프로젝트를 망하게 함
JPEG처럼 1995년 파일도 여전히 열 수 있는 이유는 소프트웨어에 종속되지 않기 때문임
10년 넘은 내 사진 관리 시스템은 파일 시스템과 EXIF를 진실의 원천으로 삼고 있음
여러 번 검증된 올바른 접근임
Google Photos나 Immich 같은 추상화 계층은 편의용일 뿐, 핵심은 파일임
업무에서도 markdown과 csv 파일로 연구와 문서를 관리함 elodie 프로젝트 링크
요즘 사진 관리의 문제는 편집, 태그, 앨범 정보가 전부 외부 메타데이터로 저장된다는 점임
플랫폼을 옮기면 모든 편집 내역이 사라짐
되돌리기 기능은 편리하지만, 이런 변경이 이식 가능하도록 표준화되길 바람
나는 agenc라는 에이전트 오케스트레이터를 만들고 있음
Claude에게 선행 연구를 물었더니 Plan 9을 제시했는데, 지금 우리가 필요한 개념이 바로 그것임
에이전트 권한 최소화라는 철학이 기업 보안 모델과 동일함
단지 Plan 9이 너무 일찍 나왔을 뿐임
새로운 파일 시스템으로는 GeFS를 살펴볼 만함
Plan 9과 UNIX가 옳았다는 걸 다시금 깨닫게 됨
가장 강력한 인터페이스는 파일 시스템 위의 텍스트 파일임
이제 9p2026을 다시 만들어야 할 때임
다만 글의 일부 기본 개념은 틀림 — 파일 시스템은 트리가 아니라 순환 가능한 그래프임
Plan 9의 핵심 기능이 무엇인지, FUSE로 붙일 수 있는지, 아니면 더 깊은 마법이 필요한지 궁금함
나에게도 깊이 공감되는 이야기임
지난 1년간 10여 개 SaaS에서 개인 데이터를 하나의 디렉터리 구조로 옮겼음 조직화된 파일 시스템이 단일 사용자에게는 충분하며, 데이터 단편화를 없앰
앞으로는 파일 시스템을 불투명하게 만들지 않으면서도 안전한 다중 사용자 쓰기를 지원하는 새로운 데이터베이스가 등장할 것 같음
QMD가 검색을 위해 하는 역할과 비슷한 느낌임
지금은 AI 활용이 아직 미성숙한 시점임
프로덕션 시스템은 일관되고 확장 가능한 데이터 구조 위에서 돌아가겠지만, 그걸 만드는 에이전트는 파일 시스템 기반 기술을 사용할 것임
UI는 데스크톱에서 벗어나 음성·시각 인터페이스로 진화할 것 같음
예를 들어 화상통화에서 표정과 억양을 읽어 더 많은 맥락을 얻는 식임
최근 본 AI 데모 영상에서는 음성과 몸짓에서 맥락을 추출해 텍스트로 변환한 뒤 LLM에 입력함
완전한 멀티모달은 아니지만 매우 흥미로웠음
그래도 텍스트 입력은 사라지지 않을 것 같음
글쓰기는 생각을 정리하게 해주고, 말처럼 즉흥적이지 않음
음성 인식(STT)이 아무리 좋아져도 인간 지능은 여전히 글쓰기 중심으로 작동함
파일은 찾을 수 있을 때만 유용함
즉, 검색과 인덱스가 필수인데, 규모가 커지면 깨지기 시작함
그래서 ‘에이전트가 다루는 지식베이스의 크기’가 핵심 질문임
나는 이 주제를 “a good agentic KB” 글에서 1차 원리로 분석해봄
코드베이스처럼 잘 정리된 여러 파일에서는 코딩 에이전트가 정보를 잘 찾음
하지만 엉망인 데이터는 파일 시스템 구조화가 훨씬 어려움
벡터 DB에서 의미 기반 검색을 하는 것보다 복잡함
코드베이스는 DRY 원칙 덕분에 자연스럽게 그래프 구조를 유지하지만, 비코드 데이터는 그렇지 않음
그래서 파일 시스템이 장기적으로 좋은 맥락 구조임에는 동의하지만, 아직 검색을 완전히 대체하지는 못함
파일 시스템은 형편없는 추상화라고 생각함
디렉터리 트리라는 의식적인 구조에 파일을 매달아야 하는 건 비효율적임
관계형 모델이나 고유 식별자 기반 구조가 더 낫다고 봄
파일 시스템의 장점은 변경의 지역성 보존임
한 브랜치의 변경이 다른 브랜치에 영향을 주지 않음
반면 데이터베이스는 UPDATE나 DELETE가 전체에 영향을 줄 수 있어 위험함
그래서 현대 OS처럼 트리 구조에 DB 인덱스를 얹는 절충형이 이상적임
NTFS는 내부적으로 MFT 데이터베이스를 사용함
파일 이름을 b+tree로 인덱싱하고, 파일 데이터도 MFT에 저장함
디렉터리는 단지 ‘directory=true’ 속성을 가진 행일 뿐임
WinFS처럼 완전한 관계형 접근은 성능 문제로 실패했고, Skydrive가 그 자리를 대체함
대부분의 파일 시스템에서 파일은 inode로 고유 식별되며, 여러 링크로 참조 가능함
이 점을 자주 잊는 듯함
UUID는 인간에게 불투명하지만, 에이전트에게는 완벽히 구분되는 식별자임
결국 S3 스타일의 blob 저장소에 좋은 인덱스를 얹고, 디렉터리는 태그처럼 온디맨드 생성되는 방향으로 갈 것 같음
“Q3 관련 자료는 이 디렉터리에 있다” 같은 그룹핑 기능만 남는 식임
Hacker News 의견들
파일은 사용자가 데이터를 직접 소유할 수 있게 해주는 근본적인 자유의 형태임
이는 기밀성, 무결성, 가용성의 주권을 가능하게 함
디지털 자유의 핵심 축으로서, FOSS 라이선스와 동등하게 인식되어야 함
자연어 자체가 파일 안에 존재하고, 가독성이 곧 스펙이 됨
읽기 쉬운 사람이면 누구나 파일에 쓸 수 있고, REPL처럼 즉시 실행할 수 있음
데이터가 앱에 묶여 독립적으로 존재하지 못하게 만들고, 가져오기/내보내기도 어렵게 함
나는 이런 문제를 해결하기 위해 백업에서 데이터를 세분화된 파일 단위로 추출해 개인 디지털 라이브러리로 옮기는 도구를 만들고 있음
불변 데이터는 보관으로 충분하지만, 수정 가능한 데이터는 다시 ‘살아있는’ 형태로 앱에서 편집 가능하게 만드는 게 가장 큰 과제임
임시 변경과 공유가 쉽고, 설정의 의미가 명확히 정의됨
Windows가 파일을 3등 시민처럼 취급하는 점이 마음에 들지 않음
SaaS 관점에서도 같은 생각을 함
코드가 일시적이고 도메인 특화될수록, 데이터(파일)는 표준적이고 지루할 정도로 안정적이어야 함
특정 앱만 읽을 수 있는 포맷은 기술 부채이며, 결국 프로젝트를 망하게 함
JPEG처럼 1995년 파일도 여전히 열 수 있는 이유는 소프트웨어에 종속되지 않기 때문임
여러 번 검증된 올바른 접근임
Google Photos나 Immich 같은 추상화 계층은 편의용일 뿐, 핵심은 파일임
업무에서도 markdown과 csv 파일로 연구와 문서를 관리함
elodie 프로젝트 링크
플랫폼을 옮기면 모든 편집 내역이 사라짐
되돌리기 기능은 편리하지만, 이런 변경이 이식 가능하도록 표준화되길 바람
Bell Labs의 Plan 9을 언급하고 싶음
Plan 9 from Bell Labs
Claude에게 선행 연구를 물었더니 Plan 9을 제시했는데, 지금 우리가 필요한 개념이 바로 그것임
에이전트 권한 최소화라는 철학이 기업 보안 모델과 동일함
단지 Plan 9이 너무 일찍 나왔을 뿐임
Plan 9과 UNIX가 옳았다는 걸 다시금 깨닫게 됨
가장 강력한 인터페이스는 파일 시스템 위의 텍스트 파일임
이제 9p2026을 다시 만들어야 할 때임
다만 글의 일부 기본 개념은 틀림 — 파일 시스템은 트리가 아니라 순환 가능한 그래프임
나에게도 깊이 공감되는 이야기임
지난 1년간 10여 개 SaaS에서 개인 데이터를 하나의 디렉터리 구조로 옮겼음
조직화된 파일 시스템이 단일 사용자에게는 충분하며, 데이터 단편화를 없앰
앞으로는 파일 시스템을 불투명하게 만들지 않으면서도 안전한 다중 사용자 쓰기를 지원하는 새로운 데이터베이스가 등장할 것 같음
QMD가 검색을 위해 하는 역할과 비슷한 느낌임
지금은 AI 활용이 아직 미성숙한 시점임
프로덕션 시스템은 일관되고 확장 가능한 데이터 구조 위에서 돌아가겠지만, 그걸 만드는 에이전트는 파일 시스템 기반 기술을 사용할 것임
UI는 데스크톱에서 벗어나 음성·시각 인터페이스로 진화할 것 같음
예를 들어 화상통화에서 표정과 억양을 읽어 더 많은 맥락을 얻는 식임
완전한 멀티모달은 아니지만 매우 흥미로웠음
글쓰기는 생각을 정리하게 해주고, 말처럼 즉흥적이지 않음
음성 인식(STT)이 아무리 좋아져도 인간 지능은 여전히 글쓰기 중심으로 작동함
파일은 찾을 수 있을 때만 유용함
즉, 검색과 인덱스가 필수인데, 규모가 커지면 깨지기 시작함
그래서 ‘에이전트가 다루는 지식베이스의 크기’가 핵심 질문임
나는 이 주제를 “a good agentic KB” 글에서 1차 원리로 분석해봄
코드베이스처럼 잘 정리된 여러 파일에서는 코딩 에이전트가 정보를 잘 찾음
하지만 엉망인 데이터는 파일 시스템 구조화가 훨씬 어려움
벡터 DB에서 의미 기반 검색을 하는 것보다 복잡함
코드베이스는 DRY 원칙 덕분에 자연스럽게 그래프 구조를 유지하지만, 비코드 데이터는 그렇지 않음
그래서 파일 시스템이 장기적으로 좋은 맥락 구조임에는 동의하지만, 아직 검색을 완전히 대체하지는 못함
파일 시스템은 형편없는 추상화라고 생각함
디렉터리 트리라는 의식적인 구조에 파일을 매달아야 하는 건 비효율적임
관계형 모델이나 고유 식별자 기반 구조가 더 낫다고 봄
한 브랜치의 변경이 다른 브랜치에 영향을 주지 않음
반면 데이터베이스는 UPDATE나 DELETE가 전체에 영향을 줄 수 있어 위험함
그래서 현대 OS처럼 트리 구조에 DB 인덱스를 얹는 절충형이 이상적임
파일 이름을 b+tree로 인덱싱하고, 파일 데이터도 MFT에 저장함
디렉터리는 단지 ‘directory=true’ 속성을 가진 행일 뿐임
WinFS처럼 완전한 관계형 접근은 성능 문제로 실패했고, Skydrive가 그 자리를 대체함
이 점을 자주 잊는 듯함
결국 S3 스타일의 blob 저장소에 좋은 인덱스를 얹고, 디렉터리는 태그처럼 온디맨드 생성되는 방향으로 갈 것 같음
“Q3 관련 자료는 이 디렉터리에 있다” 같은 그룹핑 기능만 남는 식임