파일을 옮기지 않고 관계만 얹었습니다: 4,501개 파일로 시험한 자료사슬

한 줄 요약
대부분의 인터넷 자료가 거치는 로컬 Downloads를 자료사슬의 유입 관문으로 삼고, 흩어진 파일을 새 폴더에 복사하거나 파일마다 관리용 sidecar를 붙이는 대신 기존 위치를 읽기 전용으로 관찰해 중앙 SQLite 하나에 자료·위치·사건·관계를 기록했습니다.

검증 상태
한 로컬 다운로드 폴더의 일반 파일 4,501개, 논리 용량 1.80GB를 대상으로 읽기 전용 canary를 실행했습니다. 원본 트리 변화 0건, payload 복사 0건, 파일별 sidecar 0개, SQLite 무결성 PASS, 외래키 오류 0건을 확인했습니다. 파일 이동·이름 변경의 실제 추적, 중복파일 격리·삭제, cron patrol, 실제 디스크 공간 회수는 모두 NOT RUN입니다.

바쁘면 이것만 읽어도 됩니다.

• Downloads는 최종 보관소가 아니라 처음 발견·출처 포착·임시 식별을 수행하는 유입 관문으로 다룹니다.

• 폴더는 파일의 위치를 보여주지만, 자료사슬은 파일의 출처·파생·버전·활용 관계를 보여줍니다.

• 파일마다 관리 파일을 만들지 않고, 중앙 SQLite 하나를 사용했습니다.

• 모든 파일을 서로 쌍으로 연결하지 않고 사건 허브에 묶어 관계 폭증을 막았습니다.

• 전체 4,501개 파일에는 메타데이터만 수집하고, 동일 크기 후보 1,360개에만 전체 SHA-256을 계산했습니다.

• 57개 동일 내용 그룹을 찾았지만, 같은 바이트라는 사실만으로 삭제 가능하다고 판정하지 않았습니다.

• 공개 글과 이미지에는 파일명과 절대경로를 넣지 않았고, 실제 경로가 든 SQLite와 원시 영수증은 비공개 작업대에 남겼습니다.

🧩 시작은 “자료들 사이의 관련성을 알기 어렵다”는 문제였습니다

이 사례의 출발점은 사용자가 직접 만든 자료사슬·파일사슬이라는 개념이었습니다.

파일사슬은 동영상·PDF·PPT·MP3·전사본·사진처럼 실제 파일 사이의 관계를 중심으로 봅니다.
자료사슬은 파일사슬에 YouTube 링크, 웹 URL, Zoom 채팅기록, 강의·회의·프로젝트 같은 사건까지 포함하는 상위 개념입니다.

사용자가 든 강의 예시는 다음과 같습니다.

강의 동영상은 강의자료인 PDF·PPT와 관련되어 있고,
강의 녹음본·전사본·결과물과도 관련된다.
YouTube 링크·URL·Zoom 채팅기록·사진도 함께 연결될 수 있다.
지금까지는 폴더로만 관리하거나 폴더로도 관리하지 못해 뿔뿔이 흩어졌고,
그래서 자료 사이의 관련성을 찾고 활용하기 어려웠다.

폴더는 “지금 어디에 있는가”에는 강하지만, 다음 질문에는 약합니다.

• 이 전사본은 어느 음원에서 만들어졌는가?

• 이 음원은 어느 영상에서 추출되었는가?

• 이 강의에 함께 쓰인 PDF·PPT·사진·채팅기록은 무엇인가?

• 이 결과물을 만들 때 어떤 원본과 중간 산출물이 사용되었는가?

• 같은 자료가 로컬·외장디스크·NAS·웹에 각각 있는가?

• 최신 교정본은 무엇이며 무엇을 대체했는가?

자료사슬은 새 폴더 체계를 하나 더 만드는 일이 아니라, 기존 저장소 위에 관계를 덧씌우는 의미 계층으로 정의했습니다.

🚪 Downloads는 최종 보관소가 아니라 유입 관문입니다

사용자는 후속 설명에서 한 가지 중요한 운영 사실을 짚었습니다.

모든 자료가 대부분 이 폴더를 통해 유입되는 것 같다.
특히 인터넷에서 다운로드하는 자료는 거의 여기를 거친다.

이 사실을 반영하면 Downloads는 “정리되지 않은 임시 폴더”가 아니라, 자료사슬이 자료를 가장 먼저 만나는 intake observatory가 됩니다. 다만 자료를 계속 쌓아 두는 canonical 저장소로 삼는 것은 아닙니다.

인터넷·메일·메신저·브라우저
          ↓
[Downloads 유입 관문]
  ├─ first_seen 시각 기록
  ├─ 파일 객체·크기·형식 관찰
  ├─ 다운로드 출처 메타데이터 포착
  ├─ 임시 자료 ID 부여
  └─ 강의·회의·프로젝트 관계 후보 생성
          ↓ 사용자가 이동·개명
[새 위치]
  └─ 같은 자료 ID의 위치 이력으로 연결

macOS가 다운로드 파일에 남길 수 있는 quarantine과 WhereFroms 확장 속성을 읽기 전용으로 집계해 보았습니다. 파일명·호스트·URL은 저장하지 않고 존재 여부와 URL scheme만 집계했습니다.

이 수치는 “Downloads를 거친 파일이 37.880%뿐”이라는 뜻이 아닙니다. 확장 속성은 압축 해제·복사·다른 볼륨 이동·앱 처리 과정에서 사라질 수 있습니다. 따라서 메타데이터가 없다는 사실은 다운로드하지 않았다는 증거가 아닙니다. 반대로 메타데이터가 있다는 사실도 그 파일의 canonical 역할이나 삭제 가능성을 증명하지 않습니다.

오히려 이 결과는 유입 순간을 빨리 포착해야 하는 이유를 보여줍니다.

1. 새 파일이 나타나면 FSEvents를 재조사 신호로 사용합니다.

2. 실제 파일 상태와 확장 속성을 다시 읽어 first_seen 관찰을 확정합니다.

3. 출처 URL은 기본 공개하지 않고 로컬 원장에 필요한 범위만 보존합니다.

4. 관계가 불명확하면 arrived_via Downloads를 자동 관찰로만 기록하고, 강의·프로젝트 연결은 후보 상태로 둡니다.

5. 사용자가 파일을 옮기면 Downloads 위치를 이력으로 닫고 새 위치를 엽니다.

6. 이벤트를 놓칠 수 있으므로 정기 목록 대조를 병행합니다.

그림 1. Downloads를 유입 관문으로 본 보조 canary. 메타데이터 존재는 부분적 출처 증거이며, 부재는 미다운로드를 뜻하지 않는다.

😟 첫 걱정은 “관계를 붙이려다 파일과 용량이 더 늘지 않을까?”였습니다

사용자는 구현 가능성을 묻는 동시에 두 가지 위험을 짚었습니다.

파일이 많은데 파일마다 이것을 만들면
안 그래도 복잡한 파일이 더 많아지지 않을까?
그러다가 용량이 부족해지지 않을까?

이 문제를 그대로 받아들이면 파일마다 다음과 같은 보조 파일을 붙이고 싶어집니다.

lecture.mp4
lecture.mp4.json
lecture.mp4.md
lecture.mp4.relations

하지만 이 방식은 원래 문제를 다시 만듭니다. 원본 수만큼 관리 파일이 늘고, 이동할 때 원본과 sidecar가 갈라지며, 동기화 충돌과 누락을 별도로 관리해야 합니다.

그래서 반대 방향을 택했습니다.

파일은 그대로 두고, 관계만 중앙 원장에 기록한다.

최초 구현은 다음 네 가지 원칙으로 고정했습니다.

1. 원본 파일을 이동·개명·복사하지 않는다.

2. 파일별 JSON·Markdown·link sidecar를 만들지 않는다.

3. 중앙 SQLite 하나에 자료·위치·관계·근거를 기록한다.

4. 미리보기·OCR·임베딩 같은 큰 파생물은 핵심 DB와 분리된 제한형 캐시로 둔다.

그림 2. 검증된 공개용 JSON에서 생성한 데이터 파생 증거 카드. 파일명과 절대경로는 공개하지 않았다. 1.80GB는 관찰된 파일의 논리 용량이며 실제 디스크 할당량과는 다를 수 있다.

🧱 경로와 자료의 정체성을 분리했습니다

경로를 자료의 ID로 사용하면 파일을 옮기는 순간 관계가 끊깁니다. 그래서 자료사슬에서는 세 층을 분리했습니다.

이번 canary의 파일 ID는 같은 볼륨 안의 파일 객체를 구분하는 장치·inode 관찰값으로 시작했습니다. 경로 자체를 기본키로 쓰지 않았기 때문에 같은 파일 객체에 여러 경로가 생겨도 하나의 자료에 여러 위치를 연결할 수 있습니다.

다만 이 ID만으로 모든 이동을 증명할 수 있는 것은 아닙니다.

• 같은 볼륨 이동·이름 변경은 파일 객체 ID와 재조사로 이어갈 수 있습니다.

• 다른 볼륨으로 옮기면 객체 ID가 바뀌므로 전체 SHA-256 같은 내용 증거가 필요합니다.

• 원본과 새 위치가 모두 남아 있으면 이동이 아니라 복수 위치 또는 복사일 수 있습니다.

• 외장디스크가 분리된 상태는 개별 파일 삭제가 아니라 storage_offline으로 다뤄야 합니다.

• 감시 범위 밖으로 사라진 파일은 이동 완료로 단정하지 않고 missing/unknown으로 남겨야 합니다.

이동 이력을 실제로 발생시키는 fixture는 이번 canary에서 실행하지 않았습니다. 따라서 이동·이름 변경·복사·삭제의 구분은 설계 완료, 실행 검증은 NOT RUN입니다.

🔗 모든 파일끼리 연결하지 않고 사건 허브를 뒀습니다

같은 강의에 파일이 100개 있다고 해서 100개를 서로 전부 연결하면 4,950개 쌍이 생깁니다. 이 관계는 대부분 “같은 강의에 속한다”는 약한 맥락을 반복할 뿐입니다.

자료사슬은 강의·회의·프로젝트를 사건 허브로 만들고, 각 자료를 허브에 한 번씩 연결합니다.

[강의 또는 프로젝트 사건]
 ├─ member_of ─ 영상
 ├─ member_of ─ PDF·PPT
 ├─ member_of ─ 녹음본
 ├─ member_of ─ 전사본
 ├─ member_of ─ 채팅기록
 ├─ member_of ─ 사진
 └─ member_of ─ 결과물

직접 계보를 증명할 수 있을 때만 강한 관계를 별도로 둡니다.

녹음본 ─ extracted_from → 영상
전사본 ─ transcribes → 녹음본
복습노트 ─ derived_from → 전사본·PDF·채팅기록
교정본 ─ supersedes → 원전사본
웹 URL ─ published_as → 결과물

이번 canary는 전체 폴더를 하나의 시험 사건으로 두고, 파일 자료 4,501개에 member_of 관계를 만들었습니다. 전체 SHA-256이 같은 자료들은 쌍별로 모두 연결하지 않고 57개 content-identity 허브에 묶었습니다.

그림 3. 관계 오버레이의 실제 행 수를 반영한 카드. SQLite에는 자료 4,559개(파일 4,501개 + 사건 1개 + 동일 내용 허브 57개), 위치 4,501개, 관계 4,827개가 기록되었다.

🧪 말로만 설계하지 않고 4,501개 파일로 읽기 전용 canary를 돌렸습니다

canary는 한 로컬 다운로드 폴더를 대상으로 했습니다. 파일명과 절대경로는 공개 자료에서 제거했고, 실제 경로가 든 SQLite와 전후 스냅샷은 비공개 작업대에만 보존했습니다.

수집·해시 정책

전체 파일에 처음부터 전체 해시를 계산하지 않았습니다.

1. 일반 파일 4,501개의 경로·크기·수정 시각·장치·inode·형식을 수집했습니다.

2. 파일 크기가 반복되는 442개 후보군, 1,360개 파일만 SHA-256 대상으로 골랐습니다.

3. 후보 176.7MB를 읽어 전체 SHA-256을 계산했습니다.

4. 57개 동일 내용 그룹, 326개 자료를 확인했습니다.

5. 계산한 해시는 SQLite에 저장해 같은 canary에서 다시 계산하지 않았습니다.

같은 내용의 여분을 단순 논리 크기로 합치면 88.7MB였습니다. 그러나 이것은 삭제 시 실제로 확보되는 용량이 아닙니다. hardlink, APFS clone, 백업 역할, 활성 참조, canonical·publication 책임을 검사하지 않았기 때문에 실제 회수 가능 용량은 NOT RUN으로 남겼습니다.

중앙 오버레이의 크기

DB에는 파일명과 위치 검색을 위한 FTS5 색인도 포함했습니다. 따라서 11.1MB는 단순 행만이 아니라 최초 검색 색인까지 포함한 canary 결과입니다.

실제로 실행한 조회

• 특정 형식의 위치 수 조회

• 사건 허브 구성원 수 조회

• SHA-256 동일 내용 관계 수 조회

• FTS5 제목·확장자 검색

SQLite integrity_check는 ok, 외래키 오류는 0건이었습니다. 전후 소스 트리의 경로·크기·수정 시각·inode fingerprint도 동일했습니다.

⚖️ “같은 바이트”와 “지워도 됨”을 분리했습니다

중복 정리에서 가장 위험한 오해는 다음 등식입니다.

SHA-256이 같다 = 하나를 삭제해도 된다

SHA-256 일치는 내용이 바이트 단위로 같다는 증거일 뿐입니다. 두 위치가 서로 다른 역할을 갖는지는 별도로 확인해야 합니다.

불필요한 중복 후보가 되려면 적어도 다음을 모두 통과해야 합니다.

1. 전체 SHA-256으로 내용 동일성이 확인되었다.

2. 논리 자료·버전·운영 역할이 같다.

3. 필요한 목표 복제 수를 초과한다.

4. 삭제할 경로를 참조하는 문서·앱·manifest가 없다.

5. 보존 의무·증거 역할·삭제 보류가 없다.

6. 남길 파일이 실제로 열리고 해시도 다시 일치한다.

7. 삭제본에만 있는 Finder 태그·확장 속성·권한이 없다.

8. 삭제했을 때 실제 물리 공간이 줄어드는지 확인했다.

이번 canary는 1번의 내용 동일성 후보 확인까지만 수행했습니다. 2～8번과 격리·삭제는 실행하지 않았습니다.

그림 4. 같은 내용 그룹을 찾은 결과와 삭제 승인 경계를 분리했다. 88.7MB는 논리 동일내용 초과량이며, 실제 회수 가능 용량이나 삭제 승인량이 아니다.

🚧 cron patrol은 탐지와 삭제를 한 작업으로 묶지 않습니다

정기 patrol은 유용하지만, cron이 곧바로 파일을 삭제하도록 만들면 안 됩니다. 안전한 운영은 네 단계로 나뉩니다.

1단계 — 읽기 전용 탐지

• 새 파일·사라진 위치·크기 변화를 관찰

• 크기와 메타데이터로 후보 생성

• 실제 파일 변경 없음

• 새 후보가 있을 때만 보고

2단계 — 심층 검증

• 후보 파일의 전체 SHA-256 계산

• 역할·장애영역·참조·보존 의무 검사

• KEEP_INTENTIONAL, REVIEW, QUARANTINE_ELIGIBLE로 분류

• 논리 초과량과 예상 실공간을 구분해 보고

3단계 — 승인된 파일만 격리

• 정확한 단일 파일 경로와 생존본을 승인 단위로 고정

• 두 파일의 해시와 크기 재확인

• 원래 경로·복원 경로·격리 시각 기록

• 격리 기간 동안 복원 가능 상태 유지

4단계 — 보존기간 뒤 별도 영구삭제 승인

• 생존본 존재·해시·열기 상태 재확인

• 새 참조와 복원 요청 부재 확인

• 격리본이 이후 변경되지 않았는지 확인

• 그 뒤에도 영구삭제는 별도 승인으로 실행

이번 사례에서는 cron을 만들거나 등록하지 않았고, 어떤 파일도 격리·삭제하지 않았습니다. 첫 운영 단계의 권장값은 자동 탐지와 검증까지, 영구삭제는 승인 뒤입니다.

✅ Before와 After는 “정리된 폴더”가 아니라 “검증 가능한 관계”로 비교했습니다

시간 절감, 검색 성공률, 장기 DB 성장률은 측정하지 않았습니다. 이 canary가 증명한 것은 비파괴형 중앙 오버레이가 실제 파일 수천 개 위에서 작동했고, 관계 메타데이터가 payload를 복제하지 않았다는 것입니다.

🧭 다음 단계는 “기존 전체 자료를 한 번에 정리”가 아닙니다

안전한 확장 순서는 다음과 같습니다.

1. 대표 강의·회의·프로젝트 하나를 사건 패키지로 선정합니다.

2. 영상·PDF·PPT·음원·전사본·채팅·사진·URL·결과물의 관계를 확인합니다.

3. 변환 도구가 input → run → output 영수증을 만들 때 강한 관계를 자동 등록합니다.

4. 같은 볼륨 이동·이름 변경, 다른 볼륨 복사·이동, 외장디스크 offline/online fixture를 실행합니다.

5. 관계가 경로 변경 뒤에도 남는지 검증합니다.

6. 읽기 전용 patrol에서 중복 후보만 보고하게 합니다.

7. 충분한 검증 뒤에만 격리 생명주기를 별도 승인으로 엽니다.

8. 신규 흐름이 안정된 뒤 오래된 자료를 프로젝트별 배치로 편입합니다.

자료사슬은 모든 파일을 중앙 저장소로 다시 모으는 프로젝트가 아닙니다. 원본·canonical·백업·publication의 의도적 복제는 유지하면서, 논리 ID와 위치 이력으로 서로를 찾게 만드는 프로젝트입니다.

💡 이 사례에서 얻은 운영 원칙

1. 파일 정리보다 먼저 자료의 정체성을 분리합니다

경로는 바뀌지만 자료의 계보는 남아야 합니다. 논리 자료와 위치를 분리하면 이동·복수 위치·offline 상태를 같은 모델에서 다룰 수 있습니다.

2. 약한 관계는 사건 허브, 강한 관계는 직접 edge로 둡니다

모든 파일을 서로 연결하는 것은 정확하지도 효율적이지도 않습니다. 같은 강의·회의에 속한다는 관계와 직접 파생·대체 관계를 구분해야 합니다.

3. 해시는 지연 계산하고 결과를 재사용합니다

해시는 용량을 거의 늘리지 않지만 대용량 파일을 읽는 비용이 있습니다. 메타데이터 → 후보 → 전체 SHA-256 순서로 좁혀야 합니다.

4. 동일성과 삭제 가능성을 합치지 않습니다

자동화는 후보 탐지에 적극적이어도 되지만, 삭제는 역할·참조·보존·생존본·실공간 Gate를 모두 통과해야 합니다.

5. 공개 자료와 비공개 원장을 나눕니다

경로와 파일명은 운영에 필요하지만 공개 글에는 불필요합니다. 이번 글은 공개용 집계 JSON과 데이터 파생 카드만 사용했고, 실제 경로가 든 DB·스냅샷은 발행 대상에서 제외했습니다.

📋 재사용 가능한 프롬프트

프롬프트 1 — 비파괴형 관계 오버레이 설계

흩어진 [자료 종류]를 이동·개명·복사하지 않고 관계만 추적하는 중앙 오버레이를 설계해 주세요.
논리 자료, 위치, 사건 허브, 직접 파생 관계를 분리하고, 파일별 sidecar는 만들지 마세요.
메타데이터 우선·지연 해시·단일 writer SQLite·제한형 캐시 원칙을 적용해 주세요.
확인된 관계, 자동 관찰, 후보, 충돌, missing/offline 상태를 구분하고 검증 기준을 함께 제시해 주세요.

프롬프트 2 — 중복 patrol의 삭제 금지형 검토

[대상 폴더 또는 저장소]를 읽기 전용으로 조사해 동일 내용 후보를 찾아 주세요.
파일명이나 크기만으로 중복을 확정하지 말고, 필요한 후보에만 전체 SHA-256을 계산해 주세요.
같은 바이트인지와 삭제 가능한지를 분리하고, 원본·canonical·backup·publication·증거·휴대 패키지는 기본 보호하세요.
실제 파일은 이동·격리·삭제하지 말고 KEEP_INTENTIONAL / REVIEW / QUARANTINE_ELIGIBLE 후보와 그 근거만 보고해 주세요.

🧾 검증 영수증

• Downloads 유입 관문 메타데이터 관찰 — PASS
  일반 파일 4,501개의 확장 속성을 읽기 전용으로 집계했습니다. quarantine 흔적 1,705개, WhereFroms 79개·URL 항목 137개를 확인했고 파일명·호스트·전체 URL은 공개 집계에 보존하지 않았습니다. 메타데이터 부재는 미다운로드의 증거로 사용하지 않습니다.

• 읽기 전용 관찰 — PASS
  한 로컬 다운로드 폴더를 전후 스냅샷으로 조사했습니다. 일반 파일 4,501개를 관찰했고 전후 tree fingerprint가 같았습니다. 변화가 발견되면 기존 판정을 버리고 새 run으로 재조사합니다.

• 지연 해시 — PASS
  반복 크기 후보 1,360개·176.7MB만 SHA-256으로 읽었고 오류는 0건이었습니다. hash 중 파일이 바뀌면 동일성 확정을 내리지 않습니다.

• 중앙 오버레이 — PASS
  DB는 11.1MB였고 SQLite 무결성은 ok, 외래키 오류는 0건이었습니다. schema나 DB가 바뀌면 무결성 검사를 다시 실행합니다.

• 최소 검색 — PASS
  위치·사건·동일 내용·FTS에 대해 4개 query를 실제로 실행했습니다. 장기 성능과 사용자 화면은 별도 canary 대상입니다.

• 내용 동일성 — PASS
  57개 그룹·326개 자료의 바이트 동일성을 확인했습니다. 삭제 가능 여부는 별도 Gate를 통과해야 합니다.

• 이동·격리·삭제·cron — NOT RUN
  실행 영수증이 없습니다. 격리 fixture와 승인 정책을 만든 뒤 별도 단계로 검증해야 합니다.

📌 발행 경계와 개념 출처

• 개념 출처: ‘자료사슬·파일사슬’은 사용자가 창안하고 강의 영상·교재·녹음·전사·URL·채팅·사진의 관계 예시로 정의한 개념입니다.

• 실행 근거: 본문의 수치는 2026년 8월 10일 23:27 KST의 중앙 SQLite canary와 23:57 KST의 다운로드 출처 메타데이터 읽기 전용 집계에 한정됩니다.

• Library: 이 글과 공개용 카드 4장만 검증된 Library 판본으로 발행합니다.

• 비공개: 원시 파일명·절대경로·SQLite·전후 파일 목록·내부 검증 영수증은 발행하지 않습니다.

• 외부 공개: 웹·커뮤니티·이메일 발행은 수행하지 않았습니다.

• 미실행: 이동·이름 변경·복사·offline·삭제·복원의 실제 fixture, cron 설치, 격리와 영구삭제, 실제 공간 회수는 수행하지 않았습니다.

자료사슬의 첫 성과는 파일을 더 잘 옮긴 것이 아닙니다. 파일을 건드리지 않은 채, 흩어진 자료 사이의 관계를 조회할 수 있는 최소 원장을 실제 데이터 위에서 만든 것입니다.