제○장. 업체 폐업 이후에도 살아남는 족보 시스템

장의 문제 제기 (서문 성격)

“족보는 수백 년을 전제로 기록되지만,
이를 관리하는 업체는 수십 년도 지속되지 않는다.”

이 장은 족보 디지털화의 최대 맹점,
즉 *‘기술은 앞서 있으나 존속성은 담보되지 않는 구조’*를 정면으로 다룬다.
핵심 질문은 다음 하나다.

• 족보는 업체가 사라진 뒤에도 존재할 수 있는가?

1절. 디지털 족보의 구조적 취약성

1-1. 기존 인터넷 족보의 공통된 실패 구조

• 로컬 프로그램 의존

• 업체 독점 DB 구조

• 폐쇄형 포맷(PDF·전용 바이너리)

• 유지보수 중단 = 족보 정지

→ 기술 실패가 아니라 ‘정책 실패’

1-2. 실제 발생 사례의 유형화

• 업체 폐업 → 서버 종료 → 족보 소실

• 유지비 갈등 → 업데이트 중단 → 사문화

• 후속 업체 인수 불가 → 데이터 재활용 불능

이 문제는 예외가 아니라 반복된 구조적 현상임을 명시한다.

2절. “족보 생존”을 위한 정책 전환의 필요성

2-1. 서비스 모델에서 자산 모델로

• 족보를 “이용 서비스”가 아닌

• **“종친회 공동 디지털 자산”**으로 재정의

2-2. 데이터 주권(Data Sovereignty) 개념 도입

• DB 소유권은 종친회에 귀속

• 업체는 기술 위탁자

• 계약 종료 ≠ 데이터 소멸

→ 족보에 주권 개념을 최초로 도입한 정책적 전환

3절. 폐업 이후에도 작동하는 시스템의 필수 조건

3-1. 기술 조건 (하드웨어·소프트웨어)

1. Full Web 구조

   • 설치형 프로그램 완전 배제

   • 서버 기반 로직 일원화

2. 범용 DB 사용

   • MSSQL / MySQL / PostgreSQL 등

   • 특정 업체 전용 엔진 금지

3. 플랫폼 독립 백업

   • CSV / SQL Dump 병행

   • 주기적 오프라인 백업

3-2. 운영 조건 (권한·관리)

• 종친회 관리자 계정 필수

• 업체 단독 관리자 구조 금지

• 서버 이전 가능성 사전 설계

3-3. 제도 조건 (계약·정책)

• 계약서에 데이터 반환 조항 명시

• 소스 접근 또는 에스크로(Escrow) 구조

• 기술 이전 시나리오 문서화

4절. 족보나라 모델의 구조적 해법

4-1. “업체 폐업을 전제로 설계한” 역발상 구조

• 폐업 가능성 = 예외가 아닌 전제

• 전제 설계는 곧 생존 설계

4-2. 시스템 구조 개요

• 서버는 이전 가능

• DB는 분리 독립

• 클라이언트는 브라우저·모바일

→ 업체 제거 후에도 운영 가능한 구조

4-3. 운영 주체 분리 원칙

• 종친회: 운영·데이터 주체

• 업체: 개발·기술 지원자

이 분리는 족보를 출판물에서 공공 기록물로 전환시킨다.

5절. 장기 존속을 위한 기술 확장 전략

5-1. 세대 교체 대응

• 고령층: 음성 입력·단순 UI

• 젊은 세대: 모바일·SNS 연계

5-2. AI의 역할 재정의

• 자동 오류 탐지

• 계보 불일치 경고

• “누가 관리하느냐”가 아니라
  “시스템이 스스로 점검하는 구조”

5-3. 국제 표준 연계 가능성

• GEDCOM 호환 구조

• 타 시스템으로의 이관 가능성 확보

→ 폐업 이후 ‘이전 가능성’이 곧 생존 가능성

6절. 문화적·사회적 의미

6-1. 종친회 분열 리스크의 완충 장치

• 단일 업체 의존 탈피

• 운영 주체의 안정화

6-2. 디지털 뿌리문화의 공공성 확보

• 개인 소유 족보가 아닌

• 공동 기록 자산

결론. 족보의 생존 조건은 기술이 아니라 구조다

“기술은 바뀌어도
구조가 살아 있으면 족보는 이어진다.”

이 장은 다음 명제를 확정한다.

• 업체가 사라져도 족보는 남아야 한다

• 이를 가능하게 하는 것은

  • 최신 기술이 아니라

  • 올바른 정책과 구조 설계다