S9 · REF살아 있는 서비스들 — 렌즈별

아카이브 · 디지털 유산

Permanent.org · Forever · (싸이월드 교훈)

"기록은 앱보다 오래 산다"를 정면으로 제품화한 갈래다. Permanent.org 와 Forever 는 일시불로 값을 치르면 영구히 보존하겠다고 약속하고, 사후 계정·자료의 상속(디지털 유산)까지 다룬다. 우리에게 이 제품군은 원인⑦ 회사 수명 < 기록 수명 — 싸이월드가 남긴 교훈 — 에 대한 직접 대응이자, 백업·내보내기(원칙 8)와 local-first(PD6)라는 우리 미완의 약속을 비추는 거울이다.

무엇인가

대부분의 저장 서비스는 구독이 끊기면 데이터도 끊긴다 — 회사가 살아 있는 동안만 기록이 산다. 디지털 아카이브 제품군은 이 등식을 깨겠다고 나선 소수다. 핵심 장치는 두 가지 — 일시불 영구 저장(월 구독이 아니라 한 번 값을 치르고 영원히)과 사후 관리(내가 죽은 뒤 누가 이 자료를 물려받는가)다.

서비스성격약속의 구조
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년 뒤에도 읽히고 복원되는가"까지는 보장하지 못한다. 아카이브 제품군이 파는 불안(싸이월드의 그 불안)은 우리에게도 그대로 겨눠진다.

기록은 앱보다 오래 살아야 한다 — 그리고 우리는 아직 그 약속을 절반만 지켰다. 소유(원칙 8)는 선언이 아니라 검증 항목이다. 반출물이 단독으로 읽히는지(성분·참조가 파일 안에서 복원되는지), 그것을 Local-first·Solid의 수명 이상에 대고 반복 점검해야 한다. 아카이브 제품군은 그 이상을 이미 상품화한 경쟁 지형이자, 우리가 무엇을 아직 안 지켰는지 알려주는 척도다.

생각할 거리

  1. 반출물은 단독으로 읽히는가. 아카이브의 진짜 시험은 저장 기간이 아니라 가독성의 수명이다 — 회사가 사라진 뒤 남은 파일을 다른 도구로 열었을 때 사건의 성분·참조·시대가 복원되는가. md·zip 반출이 이 시험을 통과하도록 원인⑦을 경계선 삼아 포맷을 설계할 것. 이는 라이프로깅 계보가 앓은 "저장은 됐는데 의미가 밖으로 밀려남"의 아카이브 판이기도 하다.
  2. 영구성은 누구의 약속인가. Permanent 는 재단을, Forever 는 기금을 수명 보장의 근거로 든다 — 결국 "우리 조직이 당신보다 오래 산다"는 베팅이다. 우리의 답은 조직이 아니라 사용자 기기의 원본(local-first, PD6)이다. 이 차이가 진짜 우위인지, 아니면 백업 관리를 사용자에게 떠넘기는 것인지 — Local-first·Solid의 데이터 주권 논의로 자기 검증할 것.
  3. 사후 관리를 다룰 것인가. 디지털 유산의 핵심은 "내가 죽은 뒤 이 기록을 누가 물려받는가"다 — 인생 기록 앱에는 특히 무거운 물음이다. Apple·Google 도 legacy contact 를 붙였다. 우리 모델엔 등가물이 없다. 기본 비공개(원칙 9)와 상속은 정면으로 충돌하므로("죽은 뒤엔 공개되어야 물려받는다"), 이를 액션7 범위 밖 별도 결정 과제로 열어 둘지.
  4. 회고록 서비스와의 분업. 회고록 서비스가 "질문으로 기록을 만든다면", 아카이브 제품군은 "만든 기록을 오래 지킨다". 우리는 둘 다 한 Event 위에서 하려 한다 — 채움(인터뷰 엔진, 제8장)과 산출·보존(책자·백업)이 같은 소스에 걸린다. 이 통합이 개별 제품의 조합보다 나은 지점을 액션8(제품 지형 검증)에서 확인할 것.
  5. 불변 로그와 보존의 관계. "처음 적은 문장을 보존한다"는 아이디어는 아카이브(자료 보존)를 넘어 서술의 이력 보존으로 확장된다 — 사건 서술의 수정 이력을 남기는 구조(이벤트 소싱)와 만난다. 영구 보존이 최신본만 지킬지, 궤적 전체를 지킬지의 결정이 여기서 갈린다.

더 찾아보기

  • 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(데이터 주권 프로토콜), 라이프로깅의 계보(가독성 수명의 실패), 회고록 서비스(채움-보존 분업). 인접 제품 지형: 자동 라이프로깅.

내 생각

이 메모는 지도 페이지의 같은 항목과 공유되며, 이 기기(브라우저)에 저장됩니다.