πFS - 데이터를 하드 드라이브 대신 π에 저장한다는 파일 시스템

2026-06-11 · 2026-06-11_pifs-data-free-filesystem.md

#filesystem #pi #compression #joke-project #information-theory #satirical

원문 출처

πFS - 데이터를 하드 드라이브 대신 π에 저장한다는 파일 시스템

한 줄 요약

π(파이)의 무한한 숫자열에 모든 파일이 이미 존재한다는 가정을 바탕으로, 실제 데이터 대신 'π 안에서의 위치 정보'만 저장하는 파일 시스템 — 압축이 아니라 오히려 메타데이터가 원본보다 커지는 위트 있는 장난 프로젝트.

원문 분석

πFS가 무엇인가

πFS는 Philip Lello가 만든 장난 파일 시스템이다. 이름 그대로 파일의 실제 데이터를 하드 드라이브에 저장하지 않고, 수학 상수 π(3.14159...)의 숫자열 속에 이미 존재한다고 가정한다. 핵심 논리는 다음과 같다.

  • π는 정규수(normal number)로 추정된다. 정규수란 모든 유한한 숫자 조합이 무한히 반복해서 나타나는 수를 말한다. 즉, π 안에 당신의 전화번호, 영화 파일, 심지어 이 분석글 자체까지 모두 이미 들어 있다는 뜻이다.
  • 따라서 파일 데이터를 저장할 필요가 없다. 필요한 것은 오직 그 데이터가 π의 어느 위치(index)에 있는지 알려주는 메타데이터만 저장하면 된다.
  • 16진수(hexadecimal)로 π를 다루면 바이트와 숫자 조합을 매핑하기 쉬워진다.

어떻게 작동하나

  1. 파일을 개별 바이트(byte) 단위로 분해한다.
  2. 각 바이트를 π의 숫자열에서 찾아 해당 위치(index)를 기록한다.
  3. Bailey-Borwein-Plouffe 공식이라는 수학적 공식을 사용해 π의 특정 위치 숫자를 직접 계산할 수 있다.
  4. 실제 데이터 대신 이 위치 정보들만 메타데이터 디렉토리에 저장한다.
  5. 파일을 읽을 때는 저장된 index에서 π의 해당 위치를 계산해서 데이터를 재구성한다.

성능 — 의도적으로 느림

  • 400줄짜리 텍스트 파일을 저장하는 데 5분이 걸린다.
  • 이유: 각 바이트를 π에서 개별적으로 찾아야 하기 때문이다.
  • 저자의 설명: "초기 프로토타입일 뿐이고, 무어의 법칙이 항상 우리를 지켜줄 거야!"
  • 실제로는 256개의 가능한 바이트 값에 대한 룩업 테이블(사전)로 간단히 최적화할 수 있지만, 저자는 의도적으로 그렇게 하지 않았다. 이 느림 자체가 장난의 일부다.

진짜 문제 — 메타데이터가 더 큼

이 프로젝트의 가장 중요한 점은 메타데이터가 원본 파일보다 항상 크다는 사실이다.

  • 예를 들어 128비트(16바이트) 파일을 저장한다고 하자. π에서 해당 시퀀스를 찾을 때까지 평균적으로 2^128번의 시도를 해야 한다.
  • 그 위치(index)를 기록하는 데 필요한 비트 수가 원본 데이터 크기보다 훨씬 커진다.
  • HN 댓글에서 nyc_pizzadev가 지적했듯이, 소스 코드를 보면 입력 8비트당 16비트를 쓴다. 즉, 데이터가 2배로 부풀어 오르는 것이다.
  • bilsbie의 댓글: "전화번호 하나만 해도 π 안에서의 인덱스가 전화번호 자체보다 더 많은 숫자가 필요할 거야. 진짜 압축이 아니지."

저작권 농담

README에는 다음과 같은 농담이 있다: "저작권 침해? 그런 건 존재하지 않아. 파일들은 π에 항상 있었으니까." 이는 데이터 소유권과 저작권 개념에 대한 풍자다.

설치 방법

# 의존성 설치
sudo apt-get install autoconf automake libfuse-dev

# 빌드
./autogen.sh
./configure
make
make install

# 사용
πfs -o mdd=<메타데이터 디렉토리> <마운트 포인트>

FUSE(Filesystem in Userspace)를 기반으로 Linux/macOS에서 작동한다.

저자의 다른 프로젝트 — InferenceFS

저자가 πFS의 후속작으로 만든 InferenceFS는 더 최신 버전의 장난이다. π 대신 LLM(대규모 언어 모델)의 잠재 공간(latent space)에 데이터를 저장한다는 개념이다. 파일 이름 자체가 메타데이터가 되므로, "πFS는 데이터 크기에 비례하는 메타데이터가 필요했지만, InferenceFS는 파일 이름 크기에 비례하는 메타데이터만 필요한다"고 주장한다. 이 또한 실제로는 메타데이터가 더 큰 동일한 논리의 변주다.

Hacker News 커뮤니티 반응

HN 점수 548점, 댓글 139개. 대부분 유머러스한 반응이었지만 몇 가지 의미 있는 지적도 있었다.

정보 이론 관점 — 압축이 불가능한 이유

jamwise의 댓글이 가장 핵심적인 분석이다:

"바벨의 도서관을 데이터 압축 도구로 써보려 했던 때가 떠올라. 결론은 데이터의 위치 주소를 표현하는 데도 데이터 자체와 거의 같은 양의 정보가 필요해서 압축에는 효과가 없다는 거야. 재미있는 사고실험에 가깝지."

이는 정보 이론(information theory)의 기본 원리다. 어떤 데이터를 uniquely(독일적으로) 식별하려면 그 데이터의 엔트로피(정보량)만큼의 비트가 필요하다. π 안에서의 위치를 지정하는 것은 결국 그 데이터를 다시 한번 표현하는 것이므로, 압축이 될 수 없다.

thangalin이 CS StackExchange 답변을 인용하며 보충했다:

"π에서 충분히 일찍 등장해서 의미 있는 압축을 달성하는 매칭은 단조로울 것이다. 즉, π를 사용해 흥미로운 실제 데이터를 압축하는 것은 불가능해. 실제 문자열은 π의 초반부에 등장할 가능성이 거의 없으니까."

LLM과 πFS의 연결 — 손실 압축의 관점

jamwise가 제시한 흥미로운 연결점:

"요즘 기준으로 흥미로운 점은 LLM이 이런 도구들이 실패한 목표의 요지를 실제로 달성하는 손실 압축의 한 형태라는 점이야. 물론 손실이 있고, 거대한 기반이 필요해."

LLM은 텍스트를 압축하는 방식이 πFS와 개념적으로 유사하다. 둘 다 '어딘가에 이미 존재하는 데이터'를 참조한다는 점에서. 하지만 LLM은 손실 압축(lossy compression)을 한다 — 원문을 완벽하게 복원하지 않고 'gist(gist, 핵심 의미)'만 기억한다. 반면 πFS는 손실 없는 복원을 목표로 하지만 실제로는 불가능하다.

수학적 엄밀성 — π의 정규성은 증명되지 않음

여러 사용자가 반복적으로 지적한 중요한 점:

  • keithnz: "π가 disjunctive(모든 유한 문자열 포함)이거나 정규수라는 것은 증명되지 않았어."
  • windward: "인공적으로 구성한 무리수가 아닌 어떤 수에 대해서도 정규성이나 분산성이 증명된 적이 없어."
  • anon291: "무한하다고 해서 모든 시퀀스를 포함하는 것은 아니다. 예를 들어 0.1010010001... (N개의 0 뒤에 1이 반복되는 수)은 무한하고 무리수지만 모든 시퀀스를 포함하지 않아."

즉, πFS의 전제 자체가 수학적으로 증명되지 않은 가설에 기반하고 있다. π가 정규수가 아니라면, 어떤 파일은 π에 존재하지 않을 수 있다.

유사한 장난 프로젝트들

  • nsafs (National Security Agency Filesystem): 정부가 비용을 내서 저장하므로 사용자에게는 '무료'라는 설정의 장난 파일 시스템
  • Sloot Digital Coding System (SDCS): 무한한 문자열을 저장 매체로 사용하는 동일한 개념
  • 바벨의 도서관 (Jorge Luis Borges): 모든 가능한 책이 존재하는 도서관을 상상한 소설 — chris_sn이 "Service Model"이라는 책에서 비슷한 비브(vibe)를 발견했다고 언급

위트 있는 댓글들

  • layer8: "각 비트를 개별적으로 고려하면 더 성능이 좋을 거야. 인덱스 2와 33만 있으면 되고." (π의 16진수 표현에서 첫 번째 1과 첫 번째 3의 위치를 지적한 농담)
  • z3t4: "'나는 π의 어디에 있는지' 서비스를 만들어야 해. 단축 링크로 쓸 수 있고, 하드웨어 가속 π 칩도 나오고, 모든 컴퓨터에 π가 사전 설치되겠지."
  • Levitating: "SDCS는 키가 무한대가 되거나 데이터 스토어가 무한대가 되어야 하는데, 이건 물론 쓸모없어. 하지만 π는 무한하지. 그러니 무어의 법칙이 우리 편인 한 이 천재적인 장치는 작동할 거야 :)"
  • dwheeler: "끔찍해. 훌륭해. 좋아."
  • mike_hock: "π가 과거와 미래의 모든 지식을 포함한다는 건 불편해. 내가 언제 죽는지도 들어있으니까. 하지만 거짓 정보도 모두 포함하고 있고, 어떤 게 진짜인지 미리 구분할 방법도 없어."

새로운 시각

메타데이터 산업의 풍자

이 프로젝트가 단순한 수학 장난을 넘어 의미 있는 풍자가 되는 이유는 현대 IT 산업의 메타데이터 중독을 비틀어 보여주기 때문이다.

저자가 README에서 쓴 문장: "오래된 방식의 데이터로 시간을 낭비할 게 아니라, 메타데이터로, 그리고 수많은 메타데이터로만 처리하면 돼!"

현대 데이터 산업에서 실제로 일어나고 있는 일을 생각해보자:

  • 데이터 레이크(data lake)에 테라바이트의 원본 데이터를 쌓아두고, 실제 사용되는 것은 메타데이터 인덱스 몇 기가바이트뿐인 경우
  • 클라우드 스토리지에서 파일 자체보다 ACL, 태그, 버전 히스토리, 감사 로그 같은 메타데이터 관리에 더 많은 비용이 들어가는 경우
  • 데이터 거버넌스 팀이 데이터 자체보다 '데이터에 대한 데이터'를 관리하는 데 더 많은 시간을 쓰는 현실

πFS는 이 상황을 극단적으로 밀어붙여 보여준다. "데이터는 π에 맡기고 메타데이터만 관리하자"는 말은 현대 데이터 엔지니어링의 우스꽝스러운 면을 드러낸다.

LLM을 손실 압축기로 보는 관점

HN에서 jamwise가 제시한 LLM과 πFS의 연결점은 단순한 비유를 넘어 AI 연구의 새로운 렌즈를 제공한다.

LLM이 정말로 하는 일은 무엇인가? 훈련 데이터의 손실 압축이다. 수백 기가바이트의 텍스트를 모델 가중치(수십~수백 기가바이트)로 압축한다. 완벽하게 복원하지는 않지만, 핵심 의미와 패턴은 보존한다.

πFS는 손실 없는 압축을 시도하지만 실패한다. LLM은 손실 압축을 하므로 성공한다. 이 차이는 정보 이론에서 엔트로피 코딩과 의미론적 압축의 차이와 연결된다.

교육적 가치 — 정보 이론 입문서

jamwise가 "정보 이론을 처음 접하게 됐음"이라고 말한 것처럼, πFS는 정보 이론을 배우기 위한 완벽한 사고실험이다.

왜 압축에는 한계가 있는가? 왜 데이터의 위치를 지정하는 것도 데이터와 같은 양의 정보가 필요한가? 왜 무한하다고 해서 모든 것을 포함하는 것은 아닌가? 이러한 질문들이 자연스럽게 정보 엔트로피, 콜모고로프 복잡도, 정규수 가설 등 깊은 개념들로 이어진다.

자녀/미래 영향

아인, 석현, 은한에게 설명하는 방식

"π는 3.1415926535... 이렇게 끝없이 이어지는 숫자야. 누군가가 '이렇게 끝없는 숫자열이라면, 아마도 이 안에 모든 숫자 조합이 들어있겠지'라고 생각했어. 그래서 '파일 데이터를 하드에 저장할 필요 없이, π 안에 이미 있는 데이터를 찾아서 그 위치만 기억하면 되지 않을까?'라고 생각한 거야.

하지만 문제가 있어. 예를 들어 네 생일 '20180315'가 π의 100만 번째 숫자에서 나온다고 해. 그럼 '100만'이라는 숫자를 저장해야 하는데, 이건 '20180315'를 직접 저장하는 것보다 더 많은 숫자가 필요할 수 있어. 결국 더 많은 공간을 쓰는 셈이지.

이 프로젝트는 실제로 데이터를 저장하는 게 아니라, '데이터를 저장하지 않는다는 아이디어' 자체가 재미있는 장난이야. 수학적으로도 π가 정말 모든 숫자 조합을 포함하는지는 아직 증명되지 않았어."

미래 기술과의 연결

  • 양자 컴퓨팅 시대: π 계산이 하드웨어 가속된다면 πFS의 성능이 개선될 수 있을까? — 여전히 메타데이터 문제는 해결되지 않지만, 계산 속도는 빨라질 것이다.
  • 분산 저장소: π는 전 세계 사람들이 공유하는 '무료 저장소'일 수 있다. 하지만 위치 정보(index)를 공유하려면 여전히 중앙화된 메타데이터 서버가 필요하다.
  • 블록체인과의 조합: π를 '공공 도메인 데이터 레이어'로 보고, 메타데이터만 블록체인에 저장하면 '탈중앙화 스토리지'가 될 수 있을까? — 이론적으로 가능하지만 실제로는 더 비효율적이다.

관련 노트