무엇인가
대부분의 저장 서비스는 구독이 끊기면 데이터도 끊긴다 — 회사가 살아 있는 동안만 기록이 산다. 디지털 아카이브 제품군은 이 등식을 깨겠다고 나선 소수다. 핵심 장치는 두 가지 — 일시불 영구 저장(월 구독이 아니라 한 번 값을 치르고 영원히)과 사후 관리(내가 죽은 뒤 누가 이 자료를 물려받는가)다.
| 서비스 | 성격 | 약속의 구조 |
|---|---|---|
| Permanent.org | 비영리 재단 | Permanent Legacy Foundation 이 운영. 저장 용량을 일시불로 구매하면 영구 보존, 사후에도 지정한 관리자(legacy contact)가 접근. 비영리 구조 자체를 수명 보장의 근거로 내건다 — "회사가 아니라 재단이라 오래 간다" |
| Forever | 상용 | 사진·기록을 유료 영구 저장. 수익 일부를 영구성 기금(permanence fund)에 적립해 "구독 중단 후에도 보존"을 약속하는 구조. 가족 공유·상속 기능 포함 |
| 플랫폼 유산 기능 | 생태계 부속 | Apple 유산 관리자(Legacy Contact)·Google 비활성 계정 관리자 등. 별도 제품이 아니라 OS·계정에 붙은 상속 스위치 — 디지털 유산이 주류 기능으로 편입된 신호 |
싸이월드 교훈 — 회사가 죽으면 기록도 죽는다
이 제품군이 왜 필요한지는 반례가 증명한다. 싸이월드는 2000년대 한국인의 미니홈피·다이어리·사진첩이었다 — 수억 장의 사진과 방명록, 한 세대의 청춘이 거기 쌓였다. 회사가 기울며 서비스가 닫히자 그 기록 전부가 인질이 됐고, 부분 복원과 재개가 있었지만 "내 청춘이 남의 서버 사정에 달려 있었다"는 각성만은 지워지지 않았다. 기록의 수명이 회사의 수명에 종속된다는 원인⑦의 가장 선명한 국내 사례다. Permanent·Forever 는 바로 이 불안을 판다 — 다만 그들의 해법(일시불·기금·재단)조차 "그 재단이 나보다 오래 사는가"라는 되물음에서 자유롭지 않다. 영구성은 약속이지 물리 법칙이 아니다.
우리 모델과의 접점
이 제품군은 우리가 개념 모델에서 원칙으로만 선언해 둔 것을 제품 형태로 미리 보여준다. 소유(원칙 8)는 "기록은 내 것이고 언제든 반출된다"는 약속인데, 그 약속을 끝까지 밀면 곧 아카이브 산업의 문제가 된다:
| 아카이브 제품군 | 우리 개념의 대응 | 상태 |
|---|---|---|
| 일시불 영구 저장 | 백업·내보내기 — md 책자·zip 반출(원칙 8) | 구현됨 — 다만 '반출'이지 '영구 보존'은 아님 |
| 회사에 종속되지 않는 수명 | local-first — 기기에 원본이 산다 | Local-first · PD6 미래(미완) |
| 사후 관리(legacy contact) | 등가물 없음 | 생각할 거리 3 |
| 반출물이 단독으로 읽히는가 | 책자(제8장 산출)가 자립 문서인가 | 성분·참조 복원 여부 — 점검 대상 |
여기서 정직한 자기 진단이 필요하다. §12(부검)의 리스크 ②가 못박듯, 우리의 수명 약속은 아직 미완이다 — local-first 는 PD6 의 미래이고, 지금 손에 있는 것은 수동 md·zip 반출뿐이다. 반출은 "회사가 죽어도 파일은 남는다"를 보장하지만, "그 파일이 10년 뒤에도 읽히고 복원되는가"까지는 보장하지 못한다. 아카이브 제품군이 파는 불안(싸이월드의 그 불안)은 우리에게도 그대로 겨눠진다.
생각할 거리
- 반출물은 단독으로 읽히는가. 아카이브의 진짜 시험은 저장 기간이 아니라 가독성의 수명이다 — 회사가 사라진 뒤 남은 파일을 다른 도구로 열었을 때 사건의 성분·참조·시대가 복원되는가. md·zip 반출이 이 시험을 통과하도록 원인⑦을 경계선 삼아 포맷을 설계할 것. 이는 라이프로깅 계보가 앓은 "저장은 됐는데 의미가 밖으로 밀려남"의 아카이브 판이기도 하다.
- 영구성은 누구의 약속인가. Permanent 는 재단을, Forever 는 기금을 수명 보장의 근거로 든다 — 결국 "우리 조직이 당신보다 오래 산다"는 베팅이다. 우리의 답은 조직이 아니라 사용자 기기의 원본(local-first, PD6)이다. 이 차이가 진짜 우위인지, 아니면 백업 관리를 사용자에게 떠넘기는 것인지 — Local-first·Solid의 데이터 주권 논의로 자기 검증할 것.
- 사후 관리를 다룰 것인가. 디지털 유산의 핵심은 "내가 죽은 뒤 이 기록을 누가 물려받는가"다 — 인생 기록 앱에는 특히 무거운 물음이다. Apple·Google 도 legacy contact 를 붙였다. 우리 모델엔 등가물이 없다. 기본 비공개(원칙 9)와 상속은 정면으로 충돌하므로("죽은 뒤엔 공개되어야 물려받는다"), 이를 액션7 범위 밖 별도 결정 과제로 열어 둘지.
- 회고록 서비스와의 분업. 회고록 서비스가 "질문으로 기록을 만든다면", 아카이브 제품군은 "만든 기록을 오래 지킨다". 우리는 둘 다 한 Event 위에서 하려 한다 — 채움(인터뷰 엔진, 제8장)과 산출·보존(책자·백업)이 같은 소스에 걸린다. 이 통합이 개별 제품의 조합보다 나은 지점을 액션8(제품 지형 검증)에서 확인할 것.
- 불변 로그와 보존의 관계. "처음 적은 문장을 보존한다"는 아이디어는 아카이브(자료 보존)를 넘어 서술의 이력 보존으로 확장된다 — 사건 서술의 수정 이력을 남기는 구조(이벤트 소싱)와 만난다. 영구 보존이 최신본만 지킬지, 궤적 전체를 지킬지의 결정이 여기서 갈린다.
더 찾아보기
- Permanent.org — permanent.org(Permanent Legacy Foundation, 비영리). 일시불 영구 저장·legacy contact 구조를 직접 확인할 것.
- Forever — forever.com. 영구성 기금 모델의 약관을 읽으면 "영구"가 어떻게 뒷받침되는지 보인다.
- 검색:
digital legacy estate planning accounts·Permanent.org permanence guarantee nonprofit·Cyworld shutdown data loss·Apple legacy contact— 사후 상속과 싸이월드 교훈이 함께 걸린다. - 짝으로 읽을 것: 원인⑦ 회사 수명 < 기록 수명(부검·싸이월드), Local-first software(수명의 대안), Solid(데이터 주권 프로토콜), 라이프로깅의 계보(가독성 수명의 실패), 회고록 서비스(채움-보존 분업). 인접 제품 지형: 자동 라이프로깅.
내 생각
이 메모는 지도 페이지의 같은 항목과 공유되며, 이 기기(브라우저)에 저장됩니다.