여러분의 파일 시스템은 이미 그래프 데이터베이스입니다

우리가 매일 쓰는 파일 시스템, 사실은 그래프였다

개발하다 보면 "그래프 데이터베이스"라는 단어를 한 번쯤 들어보셨을 거예요. Neo4j 같은 전문 도구를 떠올리시는 분도 있을 텐데요. 그런데 사실 우리가 매일 쓰고 있는 파일 시스템 자체가 이미 그래프 데이터베이스의 구조를 갖고 있다는 흥미로운 관점이 있어요.

이건 단순히 말장난이 아니에요. 파일 시스템의 구조를 그래프로 바라보면, 굳이 별도의 데이터베이스를 도입하지 않아도 해결할 수 있는 문제들이 꽤 있거든요.

그래프 데이터베이스가 뭔지부터 짚어볼게요

그래프 데이터베이스를 처음 듣는 분을 위해 설명하면, 데이터를 "노드(점)"와 "엣지(선)"로 표현하는 데이터베이스예요. 일반적인 관계형 데이터베이스(MySQL, PostgreSQL)가 데이터를 표(테이블) 형태로 저장한다면, 그래프 DB는 데이터 간의 "관계" 자체를 일급 시민으로 다뤄요.

예를 들어 SNS에서 "철수가 영희를 팔로우한다"를 표현할 때, 관계형 DB는 팔로우 테이블에 행을 추가하는 반면, 그래프 DB는 철수 노드에서 영희 노드로 "팔로우"라는 엣지를 그어요. 관계가 복잡해질수록 그래프 DB가 훨씬 직관적이고 조회도 빨라지죠.

파일 시스템이 그래프인 이유

자, 이제 파일 시스템을 살펴볼게요. 디렉토리(폴더)가 있고, 그 안에 파일이 있고, 디렉토리 안에 또 디렉토리가 있죠. 이걸 그래프로 보면 이렇게 돼요.

디렉토리와 파일은 각각 노드예요. 그리고 "이 디렉토리 안에 이 파일이 있다"는 관계가 엣지가 되는 거죠. 여기까지는 트리(나무) 구조처럼 보이는데요, 트리도 그래프의 한 종류이긴 하지만, 파일 시스템에는 트리를 넘어서는 요소들이 있어요.

바로 심볼릭 링크(symlink)와 하드 링크예요. 심볼릭 링크는 다른 파일이나 디렉토리를 가리키는 바로가기 같은 건데, 이게 트리 구조를 깨뜨려요. A 디렉토리 안에 있는 링크가 B 디렉토리의 파일을 가리킬 수 있으니까요. 이 순간 파일 시스템은 순수한 트리가 아니라 그래프가 돼요.

하드 링크는 더 재밌어요. 하나의 파일 데이터(inode)를 여러 이름으로 가리킬 수 있는 건데, 이건 마치 그래프에서 하나의 노드에 여러 엣지가 들어오는 것과 같아요.

이걸 실무에서 어떻게 활용할 수 있을까

이 관점이 실용적인 이유는, 간단한 데이터 관리 작업에 별도 DB 없이 파일 시스템만으로 충분한 경우가 많기 때문이에요. 예를 들어볼게요.

태그 시스템을 만든다고 해볼까요. 보통은 태그 테이블을 만들고 다대다 관계를 설정하잖아요. 그런데 파일 시스템으로도 가능해요. /tags/javascript/, /tags/tutorial/ 같은 디렉토리를 만들고, 실제 콘텐츠 파일로 심볼릭 링크를 걸면 끝이에요. 한 파일이 여러 태그 디렉토리에 링크될 수 있으니 다대다 관계가 자연스럽게 구현되죠.

또 다른 예로, 설정 파일 관리가 있어요. dotfiles를 관리할 때 심볼릭 링크를 활용해서 하나의 git 저장소에서 여러 위치의 설정 파일을 관리하는 건 이미 많은 개발자들이 쓰는 패턴이에요. 이것도 결국 파일 시스템의 그래프 특성을 활용하는 거죠.

find, ls, stat 같은 기본 유닉스 명령어가 곧 그래프 쿼리 언어가 되는 셈이에요. find /tags/javascript -type l은 "javascript 태그가 붙은 모든 콘텐츠를 찾아라"라는 그래프 쿼리와 같거든요.

Neo4j, DGraph 같은 전문 도구와의 비교

물론 파일 시스템이 Neo4j를 대체할 수 있다는 얘기는 아니에요. 전문 그래프 DB는 복잡한 관계 탐색(예: 3촌 이내의 모든 사람 찾기), 대규모 데이터, 트랜잭션 처리 등에서 압도적이에요. Cypher 같은 전용 쿼리 언어도 훨씬 강력하고요.

하지만 핵심은 "항상 전문 도구가 필요한 건 아니다"라는 거예요. 소규모 프로젝트, 빠른 프로토타입, 로컬 도구를 만들 때 파일 시스템의 그래프 특성을 의식적으로 활용하면 불필요한 의존성을 줄일 수 있어요. 유닉스 철학에서 말하는 "이미 있는 도구를 잘 써라"와도 맞닿아 있죠.

한국 개발자에게 주는 시사점

이 관점은 특히 작은 팀이나 개인 프로젝트에서 유용해요. 한국 스타트업 환경에서 MVP를 빠르게 만들 때, 데이터 관계가 단순하다면 SQLite나 Redis도 과할 수 있거든요. 파일 시스템 자체로 해결 가능한지 먼저 고민해보는 습관을 들이면, 아키텍처를 훨씬 단순하게 가져갈 수 있어요.

또한 이 글의 핵심 메시지는 기술 선택에 대한 것이기도 해요. 새 도구를 도입하기 전에 이미 가지고 있는 도구의 가능성을 먼저 탐색해보자는 거죠. 이건 파일 시스템뿐 아니라 모든 기술 선택에 적용되는 좋은 원칙이에요.