현생이 시궁창이라 블로그에 적을 글도 없고 리프레쉬나 할 겸 세종시에서 국제기록관리포럼이 열린다고 해서 갔다왔다. 생각보다 들을 내용이 꽤 있어서 그 메모를 여기에 적어둔다.
인상적이었던 세션은 오전에 있었던 국가기록원 발표세션, NARA 발표세션, 그리고 마지막 시간에 있었던 종합토론시간이였던 듯 싶다. 우선 국가기록원 발표세션은 미래 전자기록관리에 대해서 종합적으로 설명하면서 클라우드 네이티브 전자기록관리시스템을 설계한 내용을 발표했다. 그 중에서 인상적인 장표가 한 두어개정도 있었는데 한 장표는 내 눈을 조금 의심했다.
Advanced RMS(Record Management System 전자기록관리시스템)란 장표였는데 거기에는 1세대 RMS에서 부터해서 2세대 RMS, 3세대 RMS 형태로 발전하는 RMS를 설명하고 있었다. 1세대는 전자문서시스템에서 생산된 기록물을 기록관리시스템으로 이관하여 운영하는 형태이다. 아마 대부분의 기관에서 이 형태로 RMS를 운영하고 있지 않을까 싶다. 1세대는 전자문서시스템과 RMS가 각각 별도의 서버와 스토리지에 기록물을 저장하고 있고 전자문서시스템에서 RMS로 이관절차를 걸쳐서 들어오고 RMS는 데이터를 검증하고 관리하는 형태로 운영된다. 2세대는 전자문서시스템에서 생산된 기록물을 유지하면서 기록관리시스템이 통제하는 형태이다. 물리적인 형태의 서버와 스토리지는 1대만 운영하고 논리적으로만 전자문서시스템과 RMS가 구별되어 있다. 3세대는 전자문서시스템과 기록관리시스템이 통합된 형태로, 전자문서시스템 내에서 기록관리 기능을 제공한다고 장표에는 설명되어 있었다. 2세대와 동일하게 물리적인 서버와 스토리지는 1대만 운영을 하기 때문에 비용 및 전력은 1세대보다 절감할 여지가 있어 보였다.
근데 여기서 한 가지 의문인 것은 '지금의 1세대 RMS 체제가 적극적으로 도입된 것이 2010년대 이후인 것으로 알고 있는데 왜 그때 바로 2세대나 3세대 모델을 적용할 생각을 하지 못했을까' 이다. 2010년대인데 전자문서시스템에서 기록관리기능을 넣는 것이 불가능할 정도로 기술력이 떨어졌을까? 아니면 비용 및 전력의 절감필요성을 몰라서 1세대로 도입이 되었을까? RMS를 논의하는 과정에서 2세대나 3세대 모델을 바로 적용하였을 때 예상되었던 문제점이 비용 및 전력의 절감 혹은 당시의 기술력 수준을 넘어서는 큰 문제가 아니였을까? 그렇다면 2010년대에는 지적되었던 그 문제점이 지금은 해결이 되었을까? 현장에서는 여전히 기록물관리는 성가시다는 이야기가 들린다. 과연 그 문제들을 감당할 수 있을까. 더 깊은 고민과 폭넓은 논의가 필요할 것 같다.
클라우드 네이티브 전자기록관리는 전자기록을 클라우드 베이스에 두고 관리를 하겠다는 목표를 두고 국가기록원에서 설계했던 모델인 것 같았다. 지금의 기록관리는 횡적인 모델에서 시간순으로 순차적으로 진행되는 형태인데, 클라우드 네이티브 전자기록관리모델은 종적인 모델에서 맨 밑에 기반이 되는 플랫폼 위에 개별 기능들을 스택처럼 쌓아서 상하로 서로 연결되어서 상호작용하는 형태같은 인상을 받았다. (몇 년전에 모 블로그에서 아이디어 스케치 정도는 본 것 같은 기시감이 들었다.)
크게 4가지 특성이 있는데 1) DevOps 특성은 Dev(개발)과 Ops(운영)이 통합된 형태이다. 클라우드 기술이 빠르게 발전함에 따라 개발 및 운영을 일원화하여 상시적인 업데이트 기능을 제공할 수 있다고 한다. 2) Continous Delivery 특성은 클라우드에 기록물을 보관함으로서 계속 활용이 가능해진다고 한다. 개별 컴퓨터나 서버에 종속이 된 형태가 아니라서 시간이 흘러 기술표준이 바뀌어도 지속적으로 적용하여 기술환경에 따른 영향을 줄일 수 있다고 한다. 3) Micro Services 특성은 개별 업무분야별로 완전히 독립적인 서비스를 구축한다고 한다. 각 업무별로 독자적으로 구동 및 처리를 하는데 AI툴도 개별 기능 안에 마이크로서비스 형태로 구성하여 다른 서비스에는 영향을 주지 않는다고 한다. 예를 들면 전자문서시스템에서 생산이란 카테고리 하에는 각각의 마케팅, 재무, 회계, 구매 등의 독자적인 마이크로서비스를 개발한다고 되어있다. 마찬가지로 RMS란 카테고리 하에는 각각의 이관, 품질관리, 분류, 보존기간 등의 마이크로서비스를 구성한다고 되어있다. 4) Container 특성은 마이크로서비스와 연계하여 개별 V앱을 구매하지 않아도 되게 하여서 비용을 절감할 수 있다고 한다.
미국의 연방정부 국가기록원이라서 할 수 있는 NARA(미국은 연방정부와 주정부가 각각 별도의 기록관을 가지고 있다.)에서 온 강연자는 잘 기억은 안나는데 C레벨 임원이였던 듯 하다. 미국의 공무원 직제는 잘 모르지만 아마 CTO인가 였던 것 같다. 주제는 NARA에서 제공하는 디지털 아카이브와 그 것에 대한 공공의 접근과 참여였다. 오전에 발표세션에 한 내용과 마지막 종합토론에 있었던 내용이 꽤 알찼다.
NARA는 웹사이트상에서 공공기록을 공개하여 열람을 진행 중이다. 심지어 위키피디아와 연계하여 위키피디아에서 NARA의 기록물을 링크할 뿐만 아니라 이미지 데이터도 쓸 수 있게 공개중이라고 한다. 현재 계속해서 서비스를 확대중인데 2026년까지 5억건의 페이지를 공개할 예정이라고 한다. 단, 이 경우 어느 기록물을 먼저 열람할 수 있게끔 우선순위를 지정해야 하는데 NARA의 경우에는 소수자에 관련된 기록물을 우선적으로 지원하고 있다고 한다. 이를테면 유색인종, 아메리칸 원주민(인디언), 성소수자, 이민자에 대한 기록물을 먼저 열람대상 기록물로 선정하여 공개하고 있는 것이다.
catalog.archives.gov에서 모든 연방정부의 기록물에 접근할 수 있다. 현재 카탈로그의 업데이트는 가속화되고 있는데 아마존의 스노우볼 기술을 활용하여 몇 년 전에는 몇 개월 혹은 몇 년이 걸리던 작업들을 최근에는 일주일 안에 처리하고 있다.
디지털 사본 제작시 약 80% 정도가 partnershop과 digitization lab에서 처리하고 있다고 한다. citizen archivist의 참여를 받아들여 전체 처리량의 0.27% 정도를 처리하고 있는데 전체 처리량의 0.27%라 작아보이지만 건수로 따지면 75만건이라 결코 적은 양은 아니다. 시민 아키비스트는 DC에서 통합관리하고 있으며 이노베이션 허브라는 곳에서 2015년부터 진행중인 프로젝트다. 이 경우 시민들이 참여하는 프로젝트이므로 1) 커뮤니티 규정을 세우는 것을 먼저 해야 하고 2) 참여하는 시민 아키비스트를 적극적으로 신뢰하여야 한다. 시민들 중에는 우리 아키비스트보다 더 해당 분야에는 바삭한 애호가가 참 많다. 그래서 그 분들이 더 열정적으로 참여할 수 있도록 진행하고 있다. 그 밖에는 아마존 스트랙트 앱을 활용하여 수기로 작성된 문서를 디지털로 처리할 수 있게끔 변환하는 작업을 하고 있다.
종합토론 시간에는 비전자문서이관과 AI기술에 대한 논의가 인상적이었다. NARA에서는 2026년 이후에는 모든 연방정부로부터 비전자문서를 이관을 받지 않는다고 한다. 원래는 더 빨리 비전자문서이관을 종료해야 하는데 COVID-19 등과 같은 여러 변수들로 인해 2~3년정도 미루어졌다고. NARA에서 나온 강연자의 말로는 미국에서는 온전히 전자로만 문서가 생산되고 있는데 그것을 비전자로 다시 생산하여 이관하는 것 자체가 비합리적인 일이라고 한다. 온전히 전자로만 이관을 받고 원본성 검증을 위해서 메타데이터 사양 가이던스 표준을 제정하여 제공하고 있다.
AI기술에 대해서는 2년 전에 미리 계획을 세워서 예산을 짜놓아야 하는데 기술의 발전속도가 너무 빠르다 보니 2년 후의 기술발전을 예상해서 막대한 예산이 들어가는 AI기술을 도입하기가 처음에는 쉽지 않았다고 한다. 그래서 소규모 테스팅 형태로 예산을 만들어서 AI사업을 진행하였다고 한다. 그리고 이걸 토대로 하여 예산에 도입했다. 또한 테스팅 프로젝트를 통해 AI가 해줄 수 있는 것의 역할을 정의하여 모델을 만들었고, 이를 토대로 AI가 구분하고 분류한 학습데이터를 많이 만들 수 있었다.
구체적인 사례도 설명을 해주었는데 시멘틱 서치라는 프로젝트를 진행했다고 한다. 강연자가 '게임체인져'라는 표현을 쓸 정도로 인상적인 기술이었다. 기록을 자연어로 검색하도록 지원하여야 하는데 문제는 기록물건의 수가 5억건이 넘어가다보니 그것들을 다 색인해서 결과물을 보여주기가 만만치 않았어서 미리 개별 기록물건마다 수 천개의 메타데이터를 만들어져 있어야 했다. 그래서 그것을 구글(알파벳 C, 티커명: GOOG)의 제미나이AI를 이용해서 비전자문서를 변환하여 개별 기록물건마다 수 천개의 메타데이터를 생산해낼 수 있었다고 한다. 굉장히 혁신적이었고 인상적인 작업이었다고 했다.
포럼이 끝나고 다시 집으로 내려오면서 아키비스트들에게
IT기술에 대한 강화 훈련이 시급하지 않나 하는 생각을 참 많이 했다.