지난 주말, MoMA의 디지털 보존 소프트웨어 Binder를 되살리는 데 성공했다. 지금은 시간이 좀 지나 흥분이 가라앉았지만, 토·일 이틀 동안 내 체액은 아드레날린 맛이었다.

Binder는 2019년에 운영이 중단됐고, GitHub 저장소는 2023년에 아카이브 처리되었다. 원저자들이 남긴 문서에는 이렇게 쓰여 있다. "Binder는 운영 환경에서 사용할 준비가 되어 있지 않으며, 개발 환경에서 동작시키기 위해서도 추가 개발이 필요하다." 설치 안내서에는 한 술 더 떠 이 문서를 따라 해도 "현재로서는 작동하지 않는다."고 적혀 있었다. 리포지터리는 관짝, README.md는 강시 봉인 부적과도 같았다.

전설 속 강시를 관에서 꺼냈다. 어떻게 살렸지는 뒤에서 이야기하겠다. 먼저 이 소프트웨어가 왜 만들어졌고 왜 봉인되었는지부터 짚어야 한다. 그게 이 글의 절반이다.

1부. 세상에 없던 리포지터리

1부는 Amy Brost의 「Making Practice Practical: Developing Digital Preservation for Storage of Artworks at the Museum of Modern Art」(Electronic Media Review, Vol. 6, 2019–2020)와 참고 문헌의 사실을 재구성한 이야기다(각주1). 인물과 사건, 연도와 수치는 문헌에 근거했고, 대화와 장면은 각색했다.

Time-based media

2005년 어느 날 MoMA의 수석 보존가 짐 코딩턴이 유물 보존부의 글렌 워튼(Glenn Wharton)을 불렀다.

"컬렉션에 디지털 미디어가 얼마나 있는지 조사해 줄 수 있겠나."

결과는 62점, 총 500기가바이트였다. 지금 기준으로는 스마트폰 하나에 들어가는 양이다. 하지만 그 62점은 저마다 다른 하드디스크, 다른 컴퓨터, 다른 디스크에 담겨 작가가 건네준 그대로 수장고에 놓여 있었다. MoMA가 디지털 미디어를 수집하기 시작한 건 1991년이었다. 14년치 모은 것 치고 양이 많지는 않았지만 유물과 함께 이대로 둘 순 없었다.

2007년, 워튼은 MoMA 최초의 시간 기반 미디어(time-based media) 보존가가 되었다. 주로 비디오나 사운드 설치물, 소프트웨어 중심 아트, 인터넷 아트 등을 다루는 일인데, 이것들은 재생을 위한 특정한 미디어나 소프트웨어를 요구하고 버전도 다양해서 새로운 보존 방법이 필요했다. 그해 첫 아이폰이 나왔고 넷플릭스가 스트리밍을 시작했다. 같은 해 지구 반대편에서는 Artefactual Systems라는 캐나다 회사가 유네스코 세계기록유산 기술소위원회의 지원을 받아 Archivematica 개발에 착수했다. 2003년 ISO 14721로 발표된 OAIS 기능 모델을 그대로 구현하겠다는 소프트웨어였다. 이 두 줄기가 6년 뒤에 만나 Binder가 된다.

2008년 MoMA는 부서 간 연구 프로젝트를 띄웠다. 보존, 큐레이터, 소장품 관리, IT가 회의실에 앉았다. 결론은 짧았다.

고위험.

디지털 요소를 가진 작품은 이미 100점을 넘었고, 미디어·퍼포먼스 아트뿐 아니라 건축·디자인, 회화·조각, 사진, 판화까지 부서를 가리지 않고 들어오고 있었다. 스틸 이미지 TIFF 파일부터, 작가가 직접 쓴 코드가 특정 소프트웨어와 하드웨어 위에서만 돌아가는 복잡한 설치 작품까지 말이다. 이 그룹은 컴퓨터 기반 예술을 MoMA 컬렉션에서 가장 취약한 유형으로 지목했다.

문제는 참고할 사례가 없다는 거였다. 예술작품을 위한 디지털 리포지터리는 아직 어디에도 없었다. 인증받은 리포지터리는 도서관과 아카이브에 몇 개 있을 뿐이었다. 그중 하나가 뉴욕대(NYU) 도서관의 정보기술서비스에 있었다. MoMA는 강 건너 NYU에 손을 내밀었다.

2009년 로스앤젤레스 AIC 연차총회. 워튼과 뉴욕대 정보기술서비스의 포트폴리오 매니저 바브라 맥(Barbra Mack)이 단상에 올랐다. 발표 제목은 「디지털 보존 리포지터리의 필요성(A Case for Digital Conservation Repositories)」(각주2).

두 사람의 주장은 도발적이었다. 작품을 최상위 부모로 놓고 그 아래에 테크니컬·디스크립티브 메타데이터를 두는 계층 구조는 소프트웨어 기반 예술에 맞지 않다. 다중 컴포넌트 디지털 작품은 추상적인 IT 시스템을 이루고 있어서 계층으로 이해될 수 없다는 것이다. 맥이 비유를 꺼냈다.

“사람의 인체를 보십시오. 심장과 폐는 우리 몸의 일부이지만 각각 고유한 방식으로 돌봐야 합니다. 컴포넌트도 그렇습니다. 영상 작품처럼 형제니 파생본이니 하는 개념으로 관계를 파악할 수 있는 대상이 아니라구요.”

컴포넌트란 무엇인가. 작품 한 점을 이루는, 저마다 다른 성격과 운명을 가진 부분들이다. 백남준의 〈다다익선〉(1988)을 떠올리면 쉽다. 이 작품은 1,003대의 모니터로 이루어진 탑이다. 여기서 각각의 CRT 모니터는 하나의 컴포넌트다. 그리고 그 모니터에 재생되는 영상 채널이 또 다른 성격의 컴포넌트다. 껍데기인 강철 구조물과 영상을 재생하는 플레이어도 컴포넌트다. 국립현대미술관이 2018년 가동을 멈춘 이 작품을 복원하면서 던진 질문이 바로 이것이었다. 낡은 브라운관을 전부 LCD로 갈아 끼울 것인가, 아니면 CRT를 지킬 것인가. 결국 미술관은 아래쪽 737대는 CRT를 수리해 살리고, 맨 위 266대는 LCD로 교체했다(각주3). 똑같은 모니터라도 컴포넌트마다 다른 결정이 내려진 것이다. 어떤 컴포넌트는 원본 그대로 지켜야 작품의 의미가 유지되고, 어떤 컴포넌트는 교체해도 무방하다. 작품을 통째로 20세기 미디어 조각이라는 한 덩어리로 다루면 이 구분이 사라진다. 컴포넌트 단위로 봐야 "이건 브라운관을 지킨다, 저건 갈아도 된다"는 판단이 가능해진다.

2022년 복원된 <다다익선> (1988)
https://en.wikipedia.org/wiki/The_More,_The_Better 

용어 하나를 짚고 가자. 이들이 말하는 '컴포넌트'는 전자기록관리 시간에 배웠던 컴포넌트와 다르다. MoReq2010에서 컴포넌트는 '하나의 레코드에 담긴 콘텐츠 항목(비트스트림·렌디션)'을 뜻하고, 레코드 아래에 종속된 하위 계층이다(각주4). 이는 RDB나 파일 중심 사고에서 나온 것으로 동일 기록의 물리적 표현을 관리하기 위한 것이다. “이한열 열사 장례식 사진이 인화사진, 마이크로필름, 디지털화된 TIFF, 열람용 JPEG으로 존재한다” 정도는 MoReq2010의 컴포넌트로 모델링이 가능하겠지만, 인화사진을 원본으로 하여 마이크로필름과 스캔 TIFF가 만들어지고, 그 TIFF에서 다시 열람용 JPEG이 파생되었다는 구현물들 사이의 파생이나 계보 관계 표현은 불가능하다. 기록시스템을 설계하며 컴포넌트로 모델링을 하다가 항상 한계에 다다르곤 했는데 이것 때문이었다. MoReq2010의 컴포넌트는 단일 레코드의 구성 요소를 위한 것이지, 동일 내용의 여러 표현 형태를 관리하는 것이 아니었다. 현대 아카이브에서는 링크드 데이터 기반의 시맨틱 관계 모델 중심으로 동일한 지적 내용의 관계를 표현하고 있다. OAIS(ISO 14721)에서는 애초에 관리 단위가 컴포넌트가 아니라 정보 패키지(SIP·AIP·DIP)이고, '컴포넌트'는 AIP를 이루는 정보 구성요소를 일반명사로 부를 때 쓰일 뿐이다. 반면 워튼과 맥의 컴포넌트는 미술품 보존의 개념으로, 오히려 소프트웨어 공학의 UML 컴포넌트에 가깝다. 작품을 이루는 기능적 부분이고, 서로 계층이 아니라 옆으로 의존하며, 무엇보다 작가가 부분마다 다른 가치를 부여한다. 이 셋이 헷갈리는 건 Binder 안에서 이들이 층층이 겹치기 때문이다. 작품의 컴포넌트(워튼·맥)가 AIP(OAIS)로 묶이고, 그 AIP가 파일들(MoReq2010식 콘텐츠)을 담는다. Binder의 개념 축이 'FRBR + OAIS의 AIP'인 것도 그래서다.

MoMA 컬렉션에도 이런 작품이 있다. 뒤에 나올 후루하시 데이지의 〈Lovers〉(1994)는 다섯 대의 프로젝터와 두 개의 오디오 채널, 그리고 그것들을 제어하는 컴퓨터로 구성된 설치 작품이다. 여기서 작가가 직접 만든 영상 마스터, 전시용으로 변환한 상영 포맷, 백업용 복제본은 물리적으로는 비슷한 영상 파일이지만 작가가 부여한 가치가 전부 다르다. 마스터가 상하면 작품이 죽지만, 상영 포맷은 새 프로젝터에 맞춰 언제든 다시 만들 수 있다.

Installation view of the exhibition "Teiji Furuhashi. Lovers" https://www.moma.org/calendar/exhibitions/1652?installation_image_index=3

두 가지 원칙이 나왔다. 첫째, 작가가 각 컴포넌트에 부여한 가치를 기록해야 한다. 작가가 직접 만든 요소와 교체 가능한 요소는 다르다. 그러니 작품 하나에 보존 전략 하나가 아니라, 컴포넌트마다 다른 전략을 적용해야 한다. 둘째, 컴포넌트 사이의 관계, 특히 비계층적 의존 관계를 기록해야 한다.

여기서 '관계'는 세 겹이다. 1) 작품–컴포넌트–파일로 내려가는 상하 계층, 2) 원본 마스터에서 상영본으로, 다시 포맷을 바꾼 마이그레이션본으로 이어지는 세대 계보, 그리고 3) "이 영상은 저 코덱과 저 플레이어가 없으면 재생되지 않는다"는 횡적 의존이다. 앞의 둘은 위에서 아래로 흐르는 나무지만, 세 번째는 옆으로 얽히는 그물이다. <다다익선>에서 CRT 모니터와 영상 채널의 관계, 〈Lovers〉에서 영상 파일과 프로젝터·제어 컴퓨터의 관계가 전부 이 세 번째 층위다. 부모–자식이 아니라 "A가 없으면 B가 작동하지 않는다"는 의존. 워튼과 맥이 다중 컴포넌트 작품은 계층으로 이해될 수 없다고 한 것의 실체가 바로 이것이다.

Tate는 오래전부터 두 번째 층위, 즉 미디어의 세대 계보와 상태를 색으로 구분한 '미디어 생산 다이어그램(media production diagram)'으로 그려 왔다(각주5, 각주6). 관련 미디어들의 부모 자식 관계와 상태를 색으로 표시하는 도표인데, 색이 곧 그 미디어의 신분이다. Tate의 분류를 그대로 옮기면 아카이브 마스터(AM), 작가 제공 마스터(ASM), 작가 검증 프루프(AVP), 전시 포맷(EF), 리서치 카피(RC), 복제용 카피(DC), 문서(DOC). 한눈에 어느 것이 지켜야 할 원본이고 어느 것이 언제든 다시 만들 수 있는 파생본인지 보이게 하는 장치다. Binder 스파이크에서 〈Lovers〉를 빨강·초록·주황 컴포넌트로 색을 입힌 것도 정확히 이 Tate 관습을 따른 것이다. 빨강이 아카이브 마스터, 파랑이 전시 포맷 하는 식으로.

워튼과 맥이 요구한 건 거기서 한 걸음 더 나아가는 것이었다. 계보만이 아니라 횡적 의존까지 포함한 관계의 거미줄 전체를 기록하자는 것. 그리고 이 거미줄을 색깔별 노드와 선으로 화면에 살려 낸 것이 Binder의 컨텍스트 브라우저(Context browser)다.

이 발표가 Binder의 시작이었다.

Tate의 미디어 생산 다이어그램(Media production diagram).
안드레아 뷔트너의 단채널 영상 설치 작품 〈Little Sisters: Lunapark Ostia〉를 대상으로 그린 도표. 최상위의 검은 상자는 작가가 제공한 미디어의 생산 내력을 설명한다. 이어지는 녹색·빨간색 상자가 각각 하나의 컴포넌트이고, 상자를 잇는 선은 컴포넌트 간 부모/자식 관계를 나타낸다. 다만 이 선은 관계의 존재만 표시할 뿐, 복제(clone)인지 압축 파생본(derivative)인지 리랩(rewrap)인지 그 성격까지는 구분하지 않는다. 그건 각 컴포넌트의 기술에서 유추해야 한다. Binder의 컨텍스트 브라우저는 이 다이어그램에 크게 영향받았다. (Roeck, C. (2016). Fig. 3, p. 25)

Binder 탄생

2012년 MoMA는 어벤저스 자문단을 꾸려 개발 계획을 완성했다. AVPS는 DRMC(Digital Repowitory for Museum Collections) 시스템 요구사항을 완성했다. SIP, 패키지 검증과 인제스트, 저장과 무결성 관리, 색인과 데이터 관리, 장기보존 계획 등이었다(각주7). 이후 디지털 포렌식 워크플로와 미의회도서관 파일 패키징 도구 BagIt이 도입되었다.

같은 시기 MoMA Media Lounge 전시는 관람객이 여러 시청 스테이션에서 비디오 작품을 볼 수 있도록 했는데, 이를 위해 수백 개 비디오테이프의 디지털화가 진행되었다. 30테라바이트가 한 번에 들어왔다. 2014년에는 영화부 보존 작업에서 500TB의 신규 필름 스캔 파일이 들어올 예정이었다. 맨해튼 예술 서버의 미러링 복제는 백업 수준이었고 스토리지 비용도 과도했다. LTO-6 테이프 기반 저장 전환과 디지털 보존 시스템 개발이 시급했다.

2013년 Tate 출신 시간 기반 미디어 보존가 Kate Lewis가 합류하며 AIP 생성 자동화 필요성이 제기되었다. 빠르게 커지는 디지털 컬렉션을 손으로 감당할 수 없다는 게 분명해졌다. 그리고 마지막 조각, 검색, 발견, 접근, 보존 계획을 지원하는 관리 어플리케이션 계층의 명세가 만들어졌고, 개발 업체를 구하는 RFP가 나갔다. 선정된 곳은 캐나다의 Artefactual Systems. 그들은 자사 제품 AtoM(Access to Memory)과 Archivematica를 기반으로 이 커스텀 소프트웨어를 만들기로 했다.

그 소프트웨어의 이름이 Binder다.

2014년 Binder가 런칭했다. 대시보드, 작품 레코드, 컴포넌트 레코드, AIP 레코드, 지원 기술(supporting technology) 레코드, 관계 그래프를 시각화하는 컨텍스트 브라우저, Fixity 검사, 리포트, TMS(상용 컬렉션 관리 솔루션) 연동. 개념 축은 FRBR(Work→Expression→Manifestation)에 Archivematica의 AIP를 결합한 것이었다. 작품 한 점이 여러 표현과 버전, 구성 요소로 갈라지고 각각이 AIP로 묶인다.

2015년 말 Arkivum이 현장형 LTO-6 테이프 시스템을 구축했다. 폭증하는 컬렉션을 감당할 수 없어 빠른 서버 스토리지를 포기하고, 값싸고 오래가는 테이프로, 세 벌을 세 곳에 나눠 두는 체제로 옮긴 것이다. 비용과 안정성을 얻었지만, 대신 한 가지를 잃었다. 지리적으로 흩어진 테이프 세 개의 메타데이터를 일상적으로 고치는 건 불가능하다. AIP를 더 이상 편집할 수 없게 된 것이다. 이게 결국 Binder의 발목을 잡는다.

2016년 MoMA는 Binder를 가동시키기 시작했다. Bagged SIP가 스테이징 서버에 쌓이고, 자동화 파이프라인을 갖춘 커스텀 Archivematica가 AIP로 만들고, Arkivum이 관리하는 LTO-6 테이프 세 벌(온라인 둘, 오프라인 하나)에 세 곳의 다른 위치로 저장된다. 큐레이터는 Binder에서 작품을 검색한 후 메타데이터와 관계를 보고, 파일을 미리 보고, 테이프에서 꺼내오기 누르고, AIP를 검색한다. 각 AIP는 TMS에 등록된 컴포넌트 하나와 정확히 대응된다.

Binder는 3,000점, 600테라바이트를 책임지는 근간이 되었다.

Binder 수난

전성기는 짧았다. 풀리지 않은 문제가 하나 있었다. 테이프에 기록되기를 기다리는 데이터가 계속 쌓이고 있었다. 이상한 건 아무도 에러를 발견하지 못했다는 것이다.

세 시스템 모두 문제가 없었다. 원인은 일부 AIP가 서버에서 스토리지로 완전히 전송되지 않는 것이었다. 소프트웨어 통합 문제였다. 그리고 그 통합의 책임이 어디에 있는지 지정하지 않은 게 문제를 키웠다.

보존부 직원들이 1,000개가 넘는 AIP의 저장 상태를 일일이 확인했다. 데이터 손실은 없었다. 세 개의 LTO 테이프에 저장된 것이 확인되기 전에는 서버에서 아무것도 지우지 않는다는 원칙이 있었기 때문이다. 이 원칙이 컬렉션을 살렸다. 다만 신규 인제스트가 1년 넘게 멈춰 있었다. 그 사이 목적지인 LTO 테이프로 가지 못한 데이터가 미술관 서버에 100TB, 보존가들이 쓰던 데스크톱 RAID 드라이브에 20TB까지 임시로 쌓여 있었다.

이 사건은 두 가지 문제를 드러냈다.

하나. 인력이 부족했다. 기술적으로 하루 1테라바이트를 인제스트할 수 있어도, 카탈로깅과 상태 점검이 그 속도를 못 따라갔다. 250기가 디스크 이미지 네 개는 하루에 준비할 수 있지만, 합쳐서 얼마 되지도 않는 MP3 수백 개를 기술하고 담고 점검하는 데는 훨씬 오랜 시간이 걸린다. 아무리 인력을 충원해도 들어오는 양을 충당할 수 없었다. AIP를 사람이 기술한다는 게 말이 되는 건지에 의문이 생겼다.

둘. 보존팀이 타 부서와 따로 놀고 있었다. 보존 부서만 자신들 맞춤형으로 만든 시스템을 독립적으로 운영하고 있었다. MoMA의 디지털 컬렉션은 전체의 작은 일부였다. Binder가 기존 시스템들과 더 깊이 통합되어야 한다는 게 분명해졌다. 가장 큰 문제는 DPX였다. 영화부에서 오는 raw DPX 필름 스캔 파일은 소프트웨어를 한계까지 몰아부쳤다. AIP 하나 처리하는 데 며칠이 걸렸고, 도중에 실패해서 몇 시간짜리 복구와 재시작이 반복되었다.

Binder 사망

2018년엔 숨통이 트였다. RAWcooked로 DPX를 무손실 패키징해 용량을 3분의 1에서 3분의 2까지 줄였고, 처리도 빨라졌다. 2019년 MoMA는 커스텀 Archivematica를 버리고 메인라인 버전(일반 Archivematica)으로 돌아갔다. 그리고 Binder 사용을 중단했다.

브로스트는 이렇게 적었다. Binder는 시간 기반 미디어 컬렉션 관리를 위한 올인원 소프트웨어 솔루션을 개척한 선구적 시도였지만, 진정으로 지속되려면 더 많은 커뮤니티의 채택이 필요했을 것이라고. 그리고 Binder를 개발할 당시 알 수 없었던 사실이 하나 있었다고 덧붙였다. 다른 미술관들이 시간 기반 미디어 작품을 수용하는 방식이 너무나 다양해서, 하나의 관리 애플리케이션이 널리 쓰이는 일은 일어나기 어려웠다는 것이다.

Binder의 기능은 뿔뿔이 흩어졌다. 메타데이터는 TMS로. 미리보기는 DAM(NetX)으로. AIP 검색과 회수는 Arkivum GUI로 흡수되었다.

OAIS 한계

브로스트의 글에서 가장 재미있던 대목은 데이터 모델 이야기였다.

MoMA는 OAIS를 부분적으로만 받아들였다. AIP를 BagIt 명세로 만들어 LTO 테이프에 넣지만, 그 요소들에 관한 정보를 AIP의 메타데이터 구조 안에 집중시키지는 않기로 했다.

이유는 두 가지다.

하나, 시간 기반 미디어엔 생애주기가 없다. 이들 작품을 구성하는 디지털 구성 요소의 활성기(active)와 이후 아카이브기(archive) 사이에 명확한 구분선이 없다. 생산(SIP)-보존(AIP)-활용(DIP)이 아니라 전시-설치-마이그레이션-재설치가 순환한다. 브로스트는 대안으로 전기적(biographical) 접근과 기록연속체 이론을 언급한다(각주8). 기록을 최종 산물이 아니라 과정으로 보는 관점 말이다. 실제로 EU의 4년짜리 프로젝트 PERICLES는 "시간 기반 미디어처럼 지속적으로 변화하는 환경에는 OAIS가 덜 적합하다"고 명시하고 연속체 관점을 택했다(각주9, 각주10).

둘, AIP를 고칠 수 없다. LTO 테이프 세 개가 지리적으로 흩어져 있는 시스템에서 AIP 메타데이터를 편집하는 건 일상 워크플로가 될 수 없다. Binder의 원설계에는 AIP '버전 관리'가 있었다. 메타데이터가 추가되거나, 작가가 설치용 새 데이터셋을 보내오면 새 버전이 생긴다는 개념. 테이프로 옮기면서 이 개념이 실질적으로 사라졌다. 2012년 요구사항 문서와 2020년 현황을 비교한 부록을 보면 "AIP에 추가 가능" 필드마다 이렇게 적혀 있다.

No; AIP는 편집되지 않음. 새 AIP를 추가함.

그래서 MoMA의 AIP 안에는 Archivematica가 생성한 기술적 메타데이터와, 이 AIP가 TMS의 어느 컴포넌트인지 알려 주는 식별자만 들어 있다. 나머지 풍부한 서사는 TMS에 있다. AIP는 "정보를 담은 것"에서 "정보가 있는 곳(TMS)을 가리키는 것", 즉 포인터로 성격이 바뀌었다.

브로스트는 SFMOMA의 '기술 서사(technical narrative)' 접근과 DRMC 데이터 모델을 나란히 놓고 비교한다(각주11). DRMC는 기계 친화적이고 SFMOMA는 사람 친화적이다. MoMA가 데이터 모델을 끝까지 구현하지 않은 건 의도한 결정이 아니었다고 그는 썼다. 그렇게 상세한 카탈로깅을 감당할 여력이 애초에 없었을 뿐이라고. 게다가 그 정보는 이미 보존가들이 널리 쓰는 서사 문서에 들어 있었다고.

여기에 실용적 이유가 하나 더 있다. MoMA의 컬렉션 갤러리는 더 이상 큐레이터 부서별로 나뉘지 않는다. 멀티미디어 설치 작품은 종이·사진·회화·조각·시간 기반 미디어 영역에 두루 걸쳐 있다. 그러니 작품에 관한 지식은 부서 상관 없이 일관된 방식으로 한 곳에 모여, 미술관 전체에서 발견 가능해야 한다. 디지털 아트를 저장하고 꺼내는 방식은 오브제 컬렉션(회화.조각 등 물리적 실물로 된 소장품)과 다르고 개척중인 영역이지만, 미술관 전체에서 볼 때는 똑같은 하나의 컬렉션처럼 느껴져야 한다는 것이다.

그리고 커뮤니티 관점의 이야기도 있다. Binder는 MoMA 전용 커스텀 브랜치와 특정 시점의 기술 스택(그때 버전의 Archivematica·AtoM·Elasticsearch)을 전제로 하는 제품이었다. 개발사인 Artefactual 입장에서 MoMA는 손이 많이 가는 고객이라 장기 유지보수의 비즈니스 인센티브가 없었다. MoMA 입장에서도 전 세계 아카이브 커뮤니티가 같이 쓰는 오픈소스 제품을 자기 입맛대로 끌고 가는 게 부담스러웠을 것이다.

AtoM 연대기를 읽은 분이라면 이 그림이 익숙할 것이다(각주15). ICA의 자금이 끊긴 뒤 Artefactual의 피터가 커뮤니티 바운티 모델로 고군분투하며 AtoM을 살려 온 이야기, 8년째 버전 2에 머물러 있는 이야기. Binder는 그 구조적 취약함 위에 세워진 커스텀 포크였다. AtoM과 Archivematica엔 재단도 없고, 대학의 안전지대도 없고, 그랜트도 없었다. MoMA가 손을 놓으면 Binder는 끝이었다.

다행히도 MoMA와 Artefactual은 지금 Enduro와 SDPS 같은 새로운 워크플로 인프라로 디지털 보존과 리포지터리를 재구축하고 있다. Archivematica는 MoMA 덕분에 K8s 기반의 모듈화된, 몸집이 가벼운 현대적 오픈소스 프로젝트로 재탄생했다. 비운의 Binder는 역사 속으로 사라졌다.

참고1. SFMOMA의 기술 서사(technical narrative)란?

SFMOMA의 마크 헬러(Mark Hellar)가 만든, 모든 디지털 기반 작품마다 작성하는 표준 문서 양식이다. 소프트웨어 기반 예술처럼 복잡한 작품이 "어떻게 작동하고 무엇에 의존하는가"를 일관된 형식의 글로 기록해 두는 것이다. Brost 논문에 따르면 네 부분으로 구성된다.

참고2. DRMC 데이터 모델(Binder 시절의 AIP 기술)이란?

MoMA와 AVPS가 설계한, 디지털 작품 정보를 구조화된 데이터베이스 스키마(엔티티·속성·관계)로 기록하는 방식이다. SFMOMA의 기술 서사가 사람이 읽는 글이라면, 이쪽은 기계가 읽는 데이터 모델이다. 같은 정보를 담되 형식이 정반대다. Brost 논문의 ERD(Fig. 3)를 근거로 골격을 정리하면 네 부분이다.

다만 이 데이터 모델은 끝까지 구현되지 않았다. 테이프로 가면서 AIP를 편집할 수 없게 되어 버전 관리가 무력화됐고, 그렇게 상세한 카탈로깅을 감당할 인력도 없었다. 결국 AIP에는 Archivematica가 자동 생성한 기술적 메타데이터와 TMS 컴포넌트를 가리키는 식별자만 남고, 나머지 관계·서사·상태는 SFMOMA식 서사 방식으로 회귀해 TMS로 옮겨 갔다. 데이터 모델(기계 친화)로 설계했다가 인력과 테이프라는 현실 앞에서 서사(사람 친화)로 착지한 것이다.

2부. 관 뚜껑 열기

Fable 5

AtoM과 Archivematica를 공부하던 시기에 본 MoMA의 Binder 소개 영상은 내게 적잖은 충격을 줬다. 이보다 완벽한 소프트웨어가 있을까 싶었다. 작품 하나를 열면 컴포넌트가 색깔별로 갈라지고, 그 사이의 관계가 그래프로 살아 움직이고, 각 노드에서 AIP로, AIP에서 파일로, 파일에서 fixity 이력으로 내려간다. AtoM과 Archivematcia를 섞어 놓으니 카탈로깅과 디지털 보존이 한 번에 해결됐다. 어떻게든 설치해 보고 싶었지만 방법을 몰랐고 시간이 흘러 GitHub는 봉인되었다. 이후 아카이브 특강에서나 Binder를 종종 소개했다.

지난 주말, 문득 Fable 5라면 Binder 복원도 가능하지 않을까란 생각이 들었다. 서비스 종료 3일 전이기도 하고 200불 Max 구독도 하고 있고 해서 재미삼아 시작해 봤다. 깃허브 주소와 관련 논문 등 모아놓은 자료를 다 주고 복구 가능한지 물었다. 클로드의 첫 대답은 좋지 않았다.

지피티처럼 아부하진 않는구나. 신뢰가 갔다. 이어서 제안한 게 흥미로웠다. 브레인스토밍 스킬을 건너뛰고 곧장 타임박스 스파이크로 들어가자는 것. 이유가 이랬다. (스파이크는 바이브 코딩하며 자주 접하는 애자일 소프트웨어 개발 용어다. 본격적으로 만들기 전에 일단 찔러보는 작업이다. 타임박스는 시간 제한을 둔다는 것이다.)

일차 목표를 변경했다. Binder를 살리는 게 아니라, 어디서 죽는지 알아내는 걸로.

첫 번째 벽 — exit 0의 거짓말

복원에 쓴 장비는 맥북에어다. 로컬은 Apple Silicon(arm64)에 Docker. 필요한 레거시 이미지 php:5.6, mysql:5.6, elasticsearch:1.7, node:0.10, ubuntu:14.04는 전부 amd64뿐이라 에뮬레이션으로 돌려야 했다. Archivematica는 스파이크에서 아예 제외하고 AtoM/PHP 앱 + MySQL + ES + memcached만 docker-compose로 세우기로 했다. 죽는 지점을 좁히기 위한 디커플링이다.

첫 빌드. 30초 뒤 확인.

‘exit 0’은 성공했다는 말이다. 시작하자마자 좋은 신호다. 그리고 곧바로 나온 다음 메시지.

거참. 자기가 30초 전에 한 말을 바로 뒤집다니. 너무 솔직해서 허탈했지만 믿음이 더 갔다. 프로젝트가 산으로 가는데도 보고하지 않아 일을 키우는 것보다 이런 솔직함이 좋다. 원인은 php:5.6-fpm이 Debian 8 jessie가 아니라 Debian 9 stretch 기반이었던 것. Debian Linux 배포판은 버전마다 코드명이 있다. stretch 아카이브로 교정하고 패키지명도 libpng12-dev → libpng-dev, mysql-client → default-mysql-client로 고쳐 재빌드했다.

반전 — qa/0.9.x는 2014년 코드가 아니었다

그리고 결정적인 게 나왔다.

이게 무슨 뜻이냐면, 관 뚜껑에 적힌 경고문이 다른 관짝 얘기라는 거다. 원저자들이 "안 돈다"고 못 박아 둔 문서는 2015년 무렵에 쓰인 것인데, 저장소의 기본 브랜치는 그 뒤로 4년을 더 살아 있었다. 문서는 죽었고 코드는 조금 더 살았다. 그리고 아무도 문서를 고치지 않았다. 그래서 10년 동안 아무도 열지 않았다.

처음에 ES 1.7로 띄웠다가 keyword 타입 거부를 보고 5.6.16으로 재타깃한 것이 결정적이었다고 클로드가 자랑스럽게 보고했다.

스파이크 결과 — “Binder가 부팅됩니다”

여섯 개 마일스톤을 전부 통과했다. 로그인 화면이 떴을 때가 시작한 지 30분쯤 지난 시점이었던 것 같다. 2014년 발표 슬라이드에서만 보던 그 검은 헤더의 "Binder"가 내 맥북 브라우저에 떠 있었다.

37명의 감사 에이전트를 풀다

부팅은 시작일 뿐이었다. ES 5.6 환경에서 남은 비호환을 찾기 위해 Ultracode 모드에서 제공하는 멀티에이전트 감사를 백그라운드로 돌렸다. 에이전트 37명이 배치되었다. 한낱 기계한테 37개라 해야 할텐데 37명이 자연스레 나왔다. 마음 같아선 서른 일곱 분으로 하고 싶다. 31분 18초, 확정 25건 / 기각 6건. 검증까지 붙여서였다.

결론이 재밌었다. 벤더링된 Elastica가 5.x 세대라 Elastica\Facet, Elastica\Filter 네임스페이스 자체가 없다. 그래서 구식 호출부는 Elasticsearch에 닿기도 전에 PHP fatal이 난다. 네트워크 문제처럼 보이는 게 실은 문법 문제였다. 정말 고쳐야 할 건 Angular UI가 실제로 쓰는 REST API 경로의 버그 4건뿐이었다.

두 번째 항목이 특히 좋았다. 조용한 필드 누락. 에러가 안 나는 버그였다.

Lovers, Grosse Fatigue, Manifestos 2

메인화면 UI는 떴는데 화면이 텅 비어 있었다. Binder의 백미인 컨텍스트 브라우저(Context browser)를 보려면 데이터가 있어야 한다. 실제 인제스트 경로(qtPackageExtractorMETSArchivematicaDIP, arFetchTmsV1)의 Propel 패턴을 그대로 복제한 멱등 시딩 태스크를 만들었다. 데모 작품은 실제 MoMA 컬렉션에서 골랐다. 후루하시 데이지의 〈Lovers〉(1994), 카미유 앙로의 〈Grosse Fatigue〉(2013), 찰스 게인스의 〈Manifestos 2〉(2013). 컴포넌트 9개를 서술 수준별로 색을 입히고, 지원 기술 레코드 1건(Pioneer LD-V8000 레이저디스크 플레이어)에 requires 관계를 걸고, 가짜 AIP 3건과 관계 6건을 연결했다.

그리고 화면이 살아났다.

"브라우저 검증 완료: 작품 브라우즈(facet 집계 포함) → 작품 상세(TMS 패널) → Context browser d3 그래프(빨강/초록/주황 컴포넌트) → AIP 상세(파일 목록 + Download + Fixity OK). 2014년 발표 슬라이드와 화면 단위로 일치합니다."

〈Lovers〉를 열면 작품 노드에서 컴포넌트가 갈라지고, 빨간색 아카이브 마스터, 파란색 전시 포맷, 주황색 복제용 카피가 각자의 AIP로 이어진다. 워튼과 맥이 2009년 로스앤젤레스에서 말한 그 거미줄이 화면에서 돌아가고 있었다. 17년 만에.

마지막으로 외부 라이브러리인 Font Awesome 3.2.1을 벤더링했다. 마크업이 icon- 프리픽스(FA3 세대)를 쓰는 걸 확인해서 정확히 그 버전을 받아 main.css가 import하는 경로에 넣었다. 온 화면에 뜨던 ☒ 상자들이 아이콘으로 바뀌었다. 소프트웨어가 갑자기 10년 젊어 보였다.

404와 fixity — 나는 진짜로 만들고 싶다

남은 문제 하나. 레거시 AtoM 서버렌더 화면(/actor/browse, /search/advanced 같은 URL)은 아무도 안 쓰는데 방문하면 500 fatal이 난다. 안 쓰는 화면이 지뢰밭으로 남아 있는 상태다. facet → aggregation 포팅은 15개 넘는 파일의 연쇄 수정이라 대공사다. 결정은 간단했다. nginx를 기본 거부(default-deny)로 재구성해서 /drmc(Angular UI), /api(REST), 정적 자산만 노출. 나머지는 전부 404. 필요해지면 그때 포팅하면 된다.

그리고 진짜 하고 싶었던 것. Storage Service 연동.

클로드는 mock(가짜 소형 서버로 흉내 내기)을 제안했지만 나는 진짜로 하자고 했다. Binder가 실제로 통신하는 상대는 Archivematica 본체가 아니라 AIP 저장·다운로드·복구를 담당하는 장고(Django) 앱 스토리지 서비스(Storage Service)다. SS v0.24.0 컨테이너를 띄웠다. Django 4.2가 MySQL 8을 요구해서 기존 mysql 5.6과 분리해 SQLite로 붙였다. 시행착오 두 건을 뚫었다. 압축 AIP는 PREMIS 압축 이벤트 없이는 pointer file 생성이 실패해서 비압축 BagIt 디렉토리로 전환했고, 디렉토리 패키지는 tagmanifest를 체크섬하길래 tagmanifest를 추가했다.

그리고 Binder가 존재하는 이유를 한 사이클로 검증했다.

AIP 페이지에 Success → Failed×2 → AIP recovery(APPROVE) → Success 타임라인이 그대로 표시됐다. 대시보드 위젯에 "Status OK / 43s ago / Checks 3". 이게 fixity다. 파일이 훼손됐다는 걸 알아채고, 사람에게 알리고, 사람이 승인하고, 복원하고, 다시 검증한다. MoMA가 15년 동안 하고 싶어 했던 게 방구석 도커 안에서 돌아가고 있었다.

마지막으로 SWORD/METS 인제스트 경로까지 통과시켰다. gearmand와 워커 서비스를 추가하는 과정에서 실버그 두 건을 더 잡았다. sword_deposit_dir 설정이 DB(QubitSetting)에 있어서 app.yml을 덮어쓰고 있었다. 어떤 설정이 어디서 오는지 아무 데도 안 적혀 있는 그 문제였다.

Phase 1 결산: 커밋 7개, 원본 실버그 10여 건 수정. 소요시간 하루 남짓. 산출물은 ArchivelabEdu/binder의 spike/docker-revival 브랜치에 있고 SPIKE.md로 전 과정을 기록했다.

브레인스토밍의 즐거움

Claude Code로 바이브 코딩한 지 수개월, 작년 겨울에 안 되던 것들이 최근엔 거의 된다. 그런데 진짜 좋은 건 코딩이 아니다. 혼자 고민하던 걸 클로드와 브레인스토밍하며 만들어 가는 과정이 너무 즐겁다. 이야기가 통하는 사람들은 있지만 비슷한 수준에서 맴돌 뿐 진척되는 일은 드물다.

Phase 2. ‘현대적 코드로 재설계’에 들어가면서 클로드는 질문을 던지기 시작했다. 새 시스템은 누가 어떤 상황에서 쓰나(실기관 운영용). 보존 대상 컬렉션의 성격은(미디어 아트와 일반 기록물 혼합). 기술 스택은(TypeScript 풀스택). 인제스트와 보존 처리는 Archivematica에 맡길 것인가(그렇게 하되 어댑터를 인터페이스로 추상화). 기술 메타데이터 원본은 어디에 있나(Omeka S나 AtoM, ArchivesSpace, 혹은 상용 시스템에서 REST API로 연동). 아키텍처는 A안.모노레포인가 B안.멀티레포인가(A로 하되 후일 B 마이크로서비스로 전환 비용 최소화).

이건 컨설턴트와의 대화지 도구 사용이 아니다. 10년 넘게 혼자 굴려 온 질문들에 처음으로 대꾸가 돌아왔다. 평생을 시스템 설계한 현역 실리콘 밸리 구루와 대화하는 기분이랄까. 아니, 루치아나 듀란티와 앤 길리랜드, 스티브 잡스와 팀 버너스 리를 합쳐놓았달까. 데이터 모델링과 아키텍처 설계, 코딩에서만큼은 대단한 능력을 발휘한다. 최신의 도구와 방법론을 척척 알려주니 나는 묻고 또 물어 이해한 뒤 결정만 하면 된다. 나랑 얘기한 걸 기획안으로 만들어라, 중요한 발견은 스펙으로 정리해라는 말 안해도 기본 장착. 직원들 교육하게 노션에 올려라, 노트북이 느려졌으니 안쓰는 도커 이미지 내려라. 논문 100개를 몇 분만에 이해하고 지겨운 메타데이터 수정과 머리 아픈 관계 연결도 척척 해낸다. 지난 6월 익명의 누군가가 워렌 버핏과 점심 식사한 값이 130억 원이었다는데 월 20불이면 가능한 클로드와의 대화는 값이 지나치게 합리적이다.

루프

Phase 2의 데이터 모델은 4렌즈 적대 리뷰를 거쳤다. 서로 다른 관점의 에이전트들이 설계를 물어뜯게 두는 것이다. 42건이 나왔고 그중 반드시 고쳐야 할 게 19건이었다. 그걸 반영해 단일 nodes 스파인 + 30테이블로 확정했다.

구현은 태스크마다 새 서브에이전트를 파견하고 그 사이에 클로드가 리뷰하는 방식으로 돌렸다. 여기서 가장 인상 깊었던 장면이 있다.

Task 6 감사 로그를 위한 diff 헬퍼 구현 작업의 리뷰어가 이런 보고를 올렸다. 비교함수인 deepEqual을 JSON.stringify 비교로 구현했는데, PostgreSQL JSONB는 키 순서를 보존하지 않으므로 의미상 동일한 객체가 키 순서만 달라져 가짜 감사 로그가 기록될 수 있다는 것. 그런데 이 결함은 구현자의 잘못이 아니라 계획서의 예시 코드 자체가 담고 있던 것이었다. 눈앞에서 에러가 안 나는데도, ‘JSONB는 키 순서를 보존하지 않는다’는 데이터베이스의 깊은 특성까지 추론해서 미래에 터질 문제를 미리 짚어낸 것이다. 또 이 리뷰어는 자기 마음대로 고치지 않고 나에게 결정을 물었다. 결함의 진원지를 정확히 짚었고, 자기 권한의 경계를 지켰고, 진짜 중요한 판단을 내게 넘겼다. 이게 바로 하니스고 제대로 된 루프였다.

최종 whole-branch 리뷰어는 더했다. 감사 헬퍼가 Date 변경을 조용히 놓치는 버그를 잡아냈다. Drizzle의 timestamptz가 Date 객체로 오는데 열거 키가 없어서 항상 "같음"으로 판정되고 있었다. 그리고 동어반복이라 애초에 실패가 불가능했던 멱등성(idempotency, 몇 번을 반복해도 결과가 똑같은 성질) 테스트도 함께 잡혔다. 작년 겨울에 안되던 게 지금은 되는 이유 중 하나가 이것이다. 리뷰어들이 짠 적대적 테스트를 모두 통과해야만 구현에 들어간다. 심지어 이 리뷰어는 자기가 짠 테스트가 무의미하다는 걸 자기가 지적한 것이었다.

Phase 1이 끝나고 Plan 01 Foundation을 마쳤을 때 29/29 테스트가 그린(반대는 레드)이었다. Phase 1, 2에 이틀 남짓 걸렸다. 이틀만에 Claude Code 맥스 200불, 회사 팀 요금제, 서울대 Codex(100불 상당) 주간 한도가 동이 났다.

현재는 Phase 2 '현대화 재구현'을 거쳐 완전히 새로운 소프트웨어를 만드는 Phase 3로 넘어갔다. 이 제품에는 내가 하고 싶었던 모든 걸 넣어 보고 있다. RiC-O와 Linked Art 데이터 모델, 지식 그래프 추출, Identity Manager, AI 검색. Binder 정도는 무색할 소프트웨어가 쭉쭉 나왔다. 7월 18일 토요일, 다소 진정된 상태로 MoMA의 사례를 정리하다 보니 앞으로 확인하고 손봐야 할 것들이 여럿 떠올랐다. 세계 최고의 소프트웨어를 이틀만에 만든 줄 알았더니 이게 다 아드레날린 때문이었다.

Binder의 교훈

되살려 놓고 보니 Binder는 여전히 이상적인 소프트웨어다. 컴포넌트마다 다른 가치, 관계의 거미줄, 작품에서 파일까지 한 화면에서 내려가는 경로, 손상을 감지하고 사람에게 묻는 fixity. 2009년 로스앤젤레스 AIC에서 나온 개념들이 2014년에 코드가 됐고, 2019년에 멈췄고, 2026년에 다시 부팅됐다.

MoMA가 Binder를 만들며 밝혔듯이 미술관에서 디지털 아트 작품을 어떻게 보존할지에 대한 고민은 아직도 알파, 퍼머넌트 베타이다. Binder는 너무나 이상적이어서 조직에 통합되지 못한 게 패착이었다. 기술적.논리적으로 뛰어난 시스템이었지만 레거시 시스템에 녹아드는 데에는 실패했다. 업무 프로세스와도 동떨어져 있었다. 조직은 슬로운데 혼자 뛰쳐나갔다. 좋은 솔루션의 기본은 쓰는 사람들의 수준과 역량에 맞추는 것이다. 레거시를 하드캐리하는 카리스마가 있다면 훌륭한 시스템이다. 조직의 필요에 따라 모듈화되고 유연하게 진화할 수 있다면 현대적인 시스템이 된다. MoMA는 앞의 둘에 실패했지만 마지막은 놓치지 않았다. Archivematica를 K8s 기반의 Enduro와 SDPS로 진화시킨 것 말이다.

Binder를 만든 이들의 노력과 철학은 오픈소스로 계승되었다. 10년이 지난 지금 이걸 복원해 뜯어보고 새로운 소프트웨어로 발전시키는 사람이 나왔으니까. 긴 글이지만 디지털 보존에 관심 있는 분께 도움이 되길 바라며 분량을 아끼지 않았다.

2026년 복원한 Binder 소스코드는 깃허브에 공개했다.

https://github.com/ArchivelabEdu/binder-classic(각주17)

써보고 싶으신 분들은 Claude Code에 이 주소 던져주고 로컬에 띄워 달라 하면 된다.

새 소프트웨어를 데모하고 싶으신 큐레이터나 작가, 연구자는 깃허브 이메일로 연락 주시라.

바이브 코딩이나 디지털 아카이브, 아카이브시스템을 깊게 연구하고 싶으신 분들도 마찬가지.

복원한 Binder의 스크린샷과 브랜딩 이미지를 몇 개 올린다.

복원한 Binder 스크린샷

Binder - 작품 레코드 탐색

Binder - Lovers (1994) by 데이지 후루하시 컨텍스트 브라우저.
5대의 프로젝터와 2개의 오디오 채널, 제어 컴퓨터, 재생되는 원본 영상과 설치 매뉴얼 등이 포함되어 있다.

Binder - Tetris (1984) 컨텍스트 브라우저.
IBM PC버전, 닌텐도 에디션, 게임보이 에디션으로 구분되어 있다.

Binder - Grosse Fatigue (2013) 컨텍스트 브라우저.
작품 구동에 필요한 맥미니, 블루레이와 DVD, BagIt 패키지 등이 포함되어 있다.

Binder 브랜딩 이미지

2014년 저장해 놨던 Binder 영상과 발표자료 스크린샷들이다. 지금은 다 없어져 Wayback Machine을 열심히 탐색해야 나온다.

참고문헌

각주1. Brost, Amy. "Making Practice Practical: Developing Digital Preservation for Storage of Artworks at the Museum of Modern Art." Electronic Media Review 6 (2019–2020). https://resources.culturalheritage.org/emg-review/making-practice-practical-developing-digital-preservation-for-storage-of-artworks-at-the-museum-of-modern-art/

각주2. Wharton, Glenn, and Barbra Mack. "A Case for Digital Conservation Repositories." Electronic Media Review 1 (2012): 23–44.

각주3. 백남준, 〈다다익선〉(1988), 영상 설치(4채널 영상, 컬러, 사운드; 모니터 1,003대, 철 구조물), 국립현대미술관 소장(관리번호 03036), 과천관 램프코어. https://www.mmca.go.kr/collections/collectionsDetailPage.do?wrkinfoSeqno=3036 (복원 경과는 The More, The Better, Wikipedia: https://en.wikipedia.org/wiki/The_More,_The_Better 참조)

각주4. DLM Forum. MoReq2010: Modular Requirements for Records Systems, Volume 1. ("각 레코드는 하나 이상의 컴포넌트를 가진다"는 정의는 Component Series 참조) https://moreq.info/files/moreq2010_vol1_v1_1_en.pdf

각주5. Roeck, C. (2016). Preservation of digital video artworks in a museum context: Recommendations for the automation of the workflow from acquisition to storage [Master's thesis, Bern University of the Arts]. Academia.edu. (Tate '미디어 생산 다이어그램'과 컴포넌트 상태 분류의 1차 자료; 도판은 Fig. 3, p. 25) 본문 — https://www.academia.edu/41381787/ · 부록(도판) — https://www.academia.edu/41381788/Masters_Thesis_Appendix

각주6. Tate, "Time-based media" (Conservation). https://www.tate.org.uk/about-us/conservation/time-based-media

각주7. MoMA — 뮤지엄컬렉션을 위한 디지털리포지터리 DRMC 소개 — https://osasf.net/discussion/261/ ; Binder 소개 — MoMA의 디지털 보존 비전 — https://osasf.net/discussion/301/ ; Introducing Binder: A Web-based, Open Source Digital Preservation Management Application — https://www.slideshare.net/accesstomemory/introducing-binder-a-webbased-open-source-digital-preservation-management-application

각주8. McKemmish, Sue. "Placing Records Continuum Theory and Practice." Archival Science 1, no. 4 (2001): 333–359.

각주9. PERICLES Project (Promoting and Enhancing Reuse of Information throughout the Content Lifecycle taking account of Evolving Semantics), EU FP7, 2013–2017. https://cordis.europa.eu/project/id/601138

각주10. Daranyi, Sandor, et al. "PERICLES — Digital Preservation Through Management of Change in Evolving Ecosystems." In The Success of European Projects Using New Information and Communication Technologies (2015): 51–74. (OAIS가 시간 기반 미디어에 덜 적합하다는 논의 및 연속체 관점 채택)

각주11. Griesinger, Peggy. "Process History Metadata for Time-Based Media Artworks at the Museum of Modern Art, New York." Journal of Digital Media Management 4, no. 4 (2016): 331–342. (SFMOMA 기술 서사·DRMC 데이터 모델 비교의 보조 근거) https://www.henrystewartpublications.com/sites/default/files/Griesinger.pdf

각주12. Van Saaze, Vivian, Glenn Wharton, and Leah Reisman. "Adaptive Institutional Change: Managing Digital Works at the Museum of Modern Art." Museums & Society 16, no. 2 (2018): 220–239.

각주13. MoMA and Artefactual launch new digital preservation management system — https://groups.google.com/g/archivematica/c/FXsRgbrBywE

각주14. artefactual-sdps/preprocessing-moma — https://github.com/artefactual-sdps/preprocessing-moma

각주15. 안대진. (2019). 기록시스템의 오픈소스 전략 연구. 박사학위논문, 명지대학교.

각주16. MoMA Binder 소개 영상 — Binder: A New Tool for Managing Digital Preservation https://web.archive.org/web/20200115220948/https://www.youtube.com/watch?v=TelwvLkt-84

각주17. artefactual/binder (복원 대상 원본 저장소) — https://github.com/artefactual/binder ; 복원본 binder-classic — https://github.com/ArchivelabEdu/binder-classic ; 원저자 상태 문서 artefactual/binder-docs, project-status.rst — https://github.com/artefactual/binder-docs/blob/master/source/user-manual/overview/project-status.rst