차세대 기록관리 모델 재설계 연구 개발 a Study on Conceptual Redesign of the Next Generation Record Management

발 간 등 록 번 호 연 구 결 과 보 고 서 - 2 11-1741050-000011-01

차세대 기록관리 모델 재설계 연구 개발 A Study on Conceptual Redesign of the next generation record management

(2세부 연구과제)

주관수행 : 명지대학교 산학협력단 디지털아카이빙연구소

공동수행 : ㈜아카이브랩, 네모아이씨티(주), ㈜알엠소프트, ㈜에이더블유아이

국가기록원

제 출 문

국가기록원장 귀 하

이 보고서를 “차세대 기록관리모델 재설계 연구(명지대학교 디지털아카이빙연구소/이해영)” 과제의 연구결과보고서로 제출합니다.

2017. 12.

주관연구기관명 : 명지대학교 디지털아카이빙연구소

주관연구책임자 : 이해영

제 1세부과제명 : 차세대 전자기록관리의 개념설계와 정보 거버넌스형 기능·조직·법제 구축 방안 (제1세부연구기관/세부과제책임자): 명지대학교 디지털아카이빙연구소/김익한

제 2세부과제명 : 차세대 전자기록관리 프로세스와 시스템 설계 (제2세부연구기관/세부과제책임자): 네모아이씨티(주), (주)에이더블유아이, ㈜알엠소프트/오세라

제 3세부과제명 : 차세대 지능형 기록 서비스 모델 설계 (제3세부연구기관/세부과제책임자): ㈜아카이브랩/안대진

목 차

Ⅰ. 연구개발결과 요약문 (한글) 차세대 기록관리모델 재설계 연구 (영문) A Study on Conceptual Redesign of the next generation record management

Ⅱ. 제2세부연구개발과제 연구결과 제1장 제2세부연구개발과제의 최종 연구개발 목표 ····················································· 1P 제2장 제2세부연구개발과제의 연구대상 및 방법 ·························································4P 제3장 제2세부연구개발과제의 최종 연구개발 결과 ··················································· 10P 제4장 제2세부연구개발과제의 연구결과 고찰 및 결론 ············································405P 제5장 제2세부연구개발과제의 연구성과 ···································································· 406P 제6장 기타 중요변경사항 ···························································································· 408P 제7장 참고문헌 ············································································································· 408P 제8장 첨부서류 목록 ···································································································· 408P

연구결과보고서 요약문

연구과제명 차세대 기록관리 모델 재설계 연구 개발

중심단어 4차 산업혁명, 정보 거버넌스, 차세대 전자기록관리, 차세대 전자기록관리시스템, 지능형서비스

주관연구기관 명지대학교 산학협력단 주관연구책임자 이해영

연구기간 2017. 4. 10- 2017 . 11. 30.

□ 연구목표 ० 차세대 전자기록관리 개념 설계, 정보 거버넌스형 기록관리 조직 개편 및 조직별 기능 설계, 법제도 개선 방향 및 차세대 기록관리 체계 구축 방안 도출 ० 2세부 연구목표 전자기록관리 현황 및 ICBM 기술 동향 분석을 통하여 제시하는 설계 방향에 기반한 클라우드 환경 차세대 기록관리 시스템과 중앙영구기록물관리시스템 및 영구기록물관리시스템 설계 ० 3세부 연구목표 신기술 기반의 차세대 기록정보서비스 모델 제시, 테스트베드를 통해 대표적 신기술의 기록관리 적용 가능성 파악 및 전략의 완성도 향상, 지능형 서비스를 위한 장기적 실행전략 수립

□ 각 세부연구과제별 연구 결과 ० 제 1세부연구과제 전자기록관리 개념 재설계를 위한 내․외부 환경 분석 차세대 전자기록관리 재개념화 3대 전략 10대 아젠다 도출 정보 거버넌스형 기록관리 조직 및 기능 재구성 제안 기록관리법․표준 체계 개편 방안 차세대 기록관리체계 구축 로드맵 ० 제 2세부연구과제 현행 전자기록관리 프로세스와 시스템 분석 행정정보 데이터세트 기록관리체계 설계 차세대 기록관리시스템 설계 중앙영구기록관리시스템 재설계 영구기록관리시스템 설계 ० 제 3세부연구과제 국가기록원 기록정보서비스 현황분석 및 사례연구 기록의 의미 발견을 위한 빅데이터 활용모델 제시 기록의 연계를 위한 시맨틱 웹 모델 제시 기록 서비스의 지능화 모델 제시 지능형 서비스 테스트 및 프로토타입 구현 차세대 기록정보서비스 전략 수립

Summary

Title of Project A Study on Conceptual Redesign of the next generation record management

4th industrial revolution, Information Governance, next generation electronic record Key Words management, next generation electronic record management system, Intelligent Service Institute of Digital Archiving Institute Project Leader Rieh, Hae-young Myongji University

Project Period 2017. 4. 10- 2017 . 11. 30.

□ Research Purpose ० Research Task Number1 Designing next-generation electronic records management concept, reorganizing records management organization of information governance type, designing function by organization, developing direction of improvement of legal system and establishment of next generation record management system. ० Research Task Number2 Designing next generation records management system(RMS), central archival management system(CAMS), archival management system(AMS) in Cloud environment based on the design direction presented through electronic records management status and ICBM technology trend analysis. ० Research Task Number3 Presenting of a next-generation records information service model based on new technology, Identifying the applicability of records management of representative new technologies and improving the completeness of strategy through test bed, Establishing long-term strategy for intelligent services. □ Research Result ० Research Task Number1 Internal and external environment analysis for electronic records management concept redesign. Three Strategies Ten Agendas Derived for Next Generation Electronic Records Management Re-conceptualization. Information governance type records management organization and function reconstruction proposal. Records Management Law․Standard System Reorganization Plan. A road map for Next-generation records management system construction. ० Research Task Number2 Analysis of Current Electronic Records Management Process and System. Administrative information data set records management system design. Next generation records management system design. Redesign of Central Archival Management System(CAMS). Design of archival management system(AMS). ० Research Task Number3 Analysis and case study of the National Archives records information service. Presentation of Big-Data utilization model to find meaning of records. Presentation of semantic web model for linking records. Presentation of intelligent model of recording service. Intelligent service test and prototype implementation. Establishment of next-generation records information service strategy.

제2세부연구개발과제 연구결과

1. 제2세부연구개발과제의 목표

가. 연구배경 및 목적

○ 제4차 산업혁명을 맞이하는 IT 환경 변화에 대응하여 기록관리 참조 모델의 재조명 필요

현행 기록관리체계는 2005년 기록관리시스템 혁신 ISP 사업에 의해 수립되어 공문서 전자기록 생산과 보존에 적합

컴퓨팅 환경의 빠른 변화 속에서 클라우드, 빅데이터, 모바일, 사물 인터넷 등 새로운 기술에 대한 연구와 실용화가 가속화되고 있음

클라우드, 빅데이터, 모바일, 사물인터넷 등 분야의 신기술을 활용한 기록관리 모델 정립

○ 정보거버넌스 실현을 가능하게 하는 프로세스 및 데이터 모델 설계 필요

기록관리시스템으로부터 국가기록원 중앙영구기록물관리시스템으로 이관 과정에서 보존 포맷 변환 오류, 현행 XML 기반 NEO 보존 포맷 변환의 비생산성에 대한 문제 발생

결재문서 중심 국소적 개념에서 다양한 유형 전자기록을 포괄하는 대상 기록 유형의 확대 요구

행정데이터세트 기록화 및 활용대책 수립 필요

○ 범정부 클라우드 구축과 기록 생산시스템의 클라우드 전환 가속화에 부응하는 기록관리 모델 필요

클라우드 온-나라, 클라우드RMS 시스템의 확산으로 기록관리 프로세스 전환이 시급해짐

이관 규격 변환, 이관 경험으로부터 비생산성, 기록 유실, 활용성 저하 등 문제 해결의 기술적 기반 마련

○ 유연하고 확장 가능한 기록시스템으로의 전환 필요

각급 기관 도입비 3천억 원이 투입된 현행 기록관리시스템의 실제 활용률은 전체 기능의 10%만 활용되고 있음(이소연, 2014)

CAMS, PAMS 등 영구기록물관리시스템은 지속적인 기능 추가에 따라 소스코드 복잡도 증가로 근본적인 개선이 요구됨

시스템 문제의 원인인 모놀리식(Monolithic) 설계를 마이크로서비스 기반 모듈형 아키텍처로 전환 필요

나. 연구의 목표

○ 전자기록관리 현황 및 ICBM 기술 동향 분석을 통한 설계 방향 제시

○ 차세대 기록관리 프로세스 설계

○ 차세대 기록관리 시스템 설계

2. 제2세부연구개발과제의 개발과제의 목표 달성도

○ 본 연구팀은 당초 계획했던 연구 목표를 모두 달성하였음

연구개발 일정 연구개발 추진내용 달성도 1 2 3 4 5 6 7 8 9 10 11 12

ICBM 기술 및 국내외 관련 100% 시스템 현황 분석 현행 전자기록관리 100% 프로세스와 표준 시스템 분석 제 차세대 2 전자기록 차세대 기록관리 프로세스 100% 세 관리 프로 설계 부 세스와 범정부 클라우드 환경 100% 과 시스템 기록관리 시스템 설계 제 설계 행정정보데이터세트 100% 기록관리 체계 설계 중앙영구기록물관리기관 100% 전자기록관리시스템 재설계

3. 국내 외 기술개발 현황

가. 국내 기록관리시스템 연구

○ 표준기록관리시스템의 기능과 활용성에 대한 최근 연구로서 대표적으로 표준기록관리시스템의 활용현황 연구(이소연, 2015), 표준기록관리시스템 검색 기능 평가(이경남, 2013), 표준기록관리시스템의 기준관리 기능 및 이용 평가(정상희, 2013)이 있으며 이들은 기능 개선의 방향을 제시하고 있음

○ 표준기록관리시스템은 2015년 클라우드 전환 검증 정보화전략계획을 추진한 뒤 2016년 클라우드 기록관리시스템을 개발하여 행정안전부 대상으로 시범 운영했고, 2017년 하반기부터 고용노동부, 공정거래위원회 등 15개 기관을 시작으로 2018년 27개 기관, 2019년 5개 기관으로 확산 예정. 클라우드 기록관리시스템은 다수 부처가 공동 결재한 문서 관리, 타 부처 기록물 검색 활용 기능을 제공하며, 인프라면에서 정부조직 개편에 빠르게 대응할 수 있을 것으로 기대됨. 그러나 참여 개발자는 국가기록원이 주관하는 유지보수 사업의 참여 업체에 제한되기 때문에 기술적인

문제와 해결 방안에 대한 고찰 및 설계 방향을 제시하는 연구는 부족한 실정임

○ 기록관리시스템을 구성하는 부분적 기술 요소인 문서보존포맷과 장기보존포맷에 관하여 오픈 포맷과 BagIt 등과 같은 정의와 변환이 쉬운 대체 포맷에 대한 연구가 시작되어 서울기록원에서 개발을 계획 및 착수한 바 있으나 성과가 공개되지 않은 상태로서 보다 많은 연구가 필요한 상황임

○ 국내의 영구기록관리시스템은 중앙영구기록물관리시스템 외 지방기록물관리기관의 설립은 서울기록원이 가장 선도적이나 정보화전략계획 후 추진 1차년도 진행 중으로 영구기록물관리 시스템의 요건이나 기술 기반에 대한 연구 또한 미비한 실정

나. 해외 기록관리시스템 연구

○ 해외 표준으로서 MoReq(Model Requirements for the Management of Electronic Records)은 기록관리시스템의 기능 규격으로서 2011년 MoReq2010을 발표하였음. 최신 MoReq2010은 중앙집중형의 기록관리시스템을 포함하여 조직의 다른 업무 시스템을 연계하여 통합하는 모델, 클라우드 등의 신기술의 적용, 서로 다른 기록관리시스템이 공통 핵심 서비스의 공유 등 기존 MoReq2 이후 변화된 기록관리 환경을 반영함

○ 최근 공개소프트웨어 활용이 활발하여지고 있어서 디지털 아카이브 분야에서는 OAIS, PREMIS, METS, MODS, EAD 등 오픈 표준의 중요성이 점차 강조되고 있고(Corrado, 2005) 시스템 구축 방식의 특징은 오픈 표준의 지향과 공개 소프트웨어의 활용, 모듈화된 설계, 서비스 기반 아키텍처(Service Oriented Architecture, 이하 SOA) 등이 있음.(안대진, 2017)

○ 미국 ERA는 오픈 표준인 OAIS, PREMIS 등을 준수하여 핵심 미들웨어를 두고 도서관 및 아카이브 커뮤니티에서 개발한 오픈소스 소프트웨어 도입을 권장하여 개별 기능을 모듈화 하여 쉽게 추가할 수 있도록 설계했다,(안대진, 2016) 영국국립기록관리청(이하 TNA)의 영국 민간 소프트웨어 개발사와 협업을 통해 클라우드 기반의 스토리지와 보존시스템 개발하였음

○ 해외 아카이브 선진 사례로서 Preservica, Archivematica가 있음

다. 행정정보 데이터세트 기록화 연구

○ 데이터세트 기록의 관리체계 전반에 관한 연구로서 현문수(2005)는 기록으로서의 데이터세트 관리의 필요성을 지적하고, 데이터세트의 조직 및 기술을 중심으로 제언하면서 데이터세트 기록 관리의 기초자료를 제공하였고, 데이터세트의 식별하는 기준과 절차 및 품질요건에 대한 연구를 수행한 바 있다. 이들 연구는 데이터세트 기록의 아카이빙 체계를 갖추는 과정에서 필요한 개념, 프로세스 등 기반 구축에 대한 일반론적인 방법론(조은희, 2007) 연구가 행해졌음

○ 이관과 보존 기술 영역에서 행정정보 데이터세트의 선벌 기준과 절차, 이관 시 데이터 보정 및 품질 개선 방법, 데이터세트 이관 시 무결성, 진본성 보장 방안, 아카이빙 방안이 연구되었음

○ 행정정보 데이터세트의 생산기관의 관점에서 어떻게 기록 관리 대상으로 정의하고 관리해야 될지에 대한 연구는 국내외 모두 전무한 상태이며, 국가기록원이 세운 행정정보 데이터세트 기록관리 방안이 유일함

1. 연구 대상

가. 현행 전자기록관리 프로세스와 표준 시스템 분석

○ 생산 단계 및 이관 보존 활용 프로세스 분석

○ 현행 기록관리시스템 아키텍처 및 기능 분석

○ 영구기록물관리기관 설치 대상 기관 현황 조사

○ 영구기록관리 프로세스 및 시스템 기능.아키텍처 분석

○ 중앙영구기록관리시스템 HW, SW, NW, 연계 현황 분석

나. ICBM 기술 및 국내외 관련 시스템 현황 분석

○ ICBM 대상 기술 동향 및 적용 가능성 검토

클라우드, 블록체인, 패키징, 능동형 보안 (Security Information and Event Management, Data Loss Prevention, Data Audit Protection), 음성 인식, 이미지 인식, 마이크로서비스 아키텍처, 애자일 개발

○ 국내외 기록관리 시스템 현황

해외 기록관리시스템(ERA, Archivematica, 해외 내셔널 아카이브 등), BagIt 패키징 사례, 마이크로서비스 아키텍처 운영사례(Archivematica), 기록관리 기관 오픈소스 프로젝트(POWRR, PREFORMA, VeraPDF, AtoM, Omeka 등)

○ 기록관리시스템 관련 현황

범정부 클라우드 구축 현황, 공공빅데이터 추진현황, 기록관리 선진기술 연구 현황

다. ICBM 적용 기술 참조 모델

○ 다양한 기록 유형(행정정보, 멀티미디어, 웹링크 등) 포착관리

분산 환경에서 디지털 객체의 식별(Identification), 포착(Capture), 입수(Ingest)를 위한 다양한 기술 검토 및 분석

디지털 시대의 필수기록과 보존 위험요소를 식별하고, 기록관리의 전 생애주기 동안 보존과 활용을 제공하기 위한 기반 수립

○ 신유형 전자기록 보존포맷 기술

생산포맷, 보존포맷, 장기보존포맷 구분 및 현행 NEO 패키지의 비효율성 해결방안 모색

클라우드 환경 전환에 따라 데이터의 물리적 이관행위 축소가 논의되고 있으나, 여전히 ISO 14721(OAIS)의 정보 패키지 개념은 유용하며, 기록/정보 덩어리의 논리적 패키징 기술은 무결성/진본성을 보장하는 정보 유통의 기술기반을 제공함

Base64 인코딩의 대안으로 ZIP 기반의 BagIt 방식이 논의되고 있으며 선행 연구를 바탕으로 보다 심화된 보존 포맷 연구 수행 필요

○ 진본성 인증과 능동형 보안

진본성 및 무결성 인증 위한 과도한 기술처리(예: 공인인증서, 타임스탬프, 해쉬, Base64 등) 를 배제하고 효율적 대안을 모색

분산네트워크 환경의 식별체계(UUID 등), 진본확인(Blockchain), 능동형 보안(SIEM : Security Information and Event Management, DLP : Data Lost Prevention, DAP : Data Audit Protection 등 기술분석 및 참조모델 수립

○ 애자일 개발 방법론 적용 가능한 설계 방안

표준RMS, CAMS, PAMS 문제의 근본 원인은 모놀리식(Monolithic) 설계. 기능 추가할수록 복잡도 증가하는 한계 존재

마이크로서비스는 SOA(서비스 지향 아키텍처) 방식의 고비용 문제를 해결하는 대안으로 각광받고 있음 (OAIS 기반의 오픈소스 보존시스템인 Archivematica에도 적용)

마이크로서비스의 통합과 통신, 테스트와 운영 등 실제 개발에 필요한 모든 요소의 면밀한 검토와 사례연구가 필요함

구성된 요건을 오픈소스 컴포넌트로 구현하기 위한 평가/개발 방안과 PaaS, SaaS를 활용한 App 생성 및 API 제공방안 마련

○ DevOps 기반의 애자일 프랙티스와 IT 운영 방안

DevOps는 소프트웨어 개발자들과 IT 종사자들 사이의 의사소통, 협업, 융합을 강조한 개발 방법론이며, 소프트웨어 개발과 IT운영간의 조화를 지향

표준 기록시스템 실패를 교훈 삼아 개발 후 지속적인 개선이 이루어질 수 있는 IT운영과 관리방안 모색 (ITIL(IT Infrastructure Library) 등의 프레임워크 활용방안 모색)

다. 차세대 기록관리 프로세스 설계

○ 생산기관 프로세스 설계

클라우드 온-나라 시스템 확산에 따라 ODF가 기록의 주요 생산포맷으로 정착할 것으로 예상됨. ODF는 XML 기반으로 현행 문서보존포맷인 PDF/A-1 변환이 적절한지에 대한 여부 검토가 필요함

현행과 같은 기록 생산 후 철단위의 일괄 이관은 추가적인 이관 업무 부담과 시간 소요의 문제를 가지고 있음. 이에 기록 생산과 동시에 기록시스템(RMS/AMS) 으로 이관하는 건단위의 자동 이관을 지향함

생산 시점에 영구보존 대상기록으로 식별될 경우 영구기록관리시스템에 바로 입수하거나, 스토리지/메타데이터를 공유하는 방안 검토 필요

○ 기록관/영구기록관리기관 프로세스 설계

문서보존포맷으로 플랫폼 독립성이 높은 PDF/A-1로 변환하고 있으나 변환 과정에서 오류 발생이 높음. 문서보존포맷에 대한 근본적인 재검토 필요

현행 국가기록원 장기보존포맷 변환 프로세스의 특징은 전자기록의 계층적 구조를 반영할 수 있는 XML로 표현 , 메타데이터, 원문파일, 문서보존포맷 파일(PDF/A), 전자서명으로 구성, 원문파일, 문서보존포맷 파일은 Base64 인코딩을 통해 텍스트 스트림으로 변환, 진본성 및 무결성 보장을 위해 기관인증서, 서명정보, 잠김 인증정보를 포함

다양한 패키징 방식에 대한 심층 연구를 통해 최적의 패키징 방식 선택 필요. 미국의회도서관 등에서 실용화된 BagIt 방식은 ISO/IEC 21320 ZIP 방식의 패키징으로 단순하면서 유연성 있는 패키징 방식으로 주목 받고 있음

○ 장기보존 및 패키징 기술

현행 장기보존포맷의 문제점

BagIt을 이용한 장기보존 포맷 규격

○ 무결성 검증을 위한 체크섬

현 국가기록원 장기보존포맷 NEO규격의 전자서명을 이용한 진본성 검증의 대안으로 이용 가능함

BagIt 패키징 기술의 이용 사례

클라우드 환경, 사본이 많은 전자기록의 환경에서 진본을 식별하기 위해 UUID 등 분산 컴퓨팅 환경에서 쓰이는 고유 식별 체계 도입 방안 마련

라. 범정부 클라우드 환경 기록관리시스템 설계

○ IaaS와 전자기록관리 체계 재설계

서울기록원ISP에서 물리적 이관으로 인한 검증/에러 등의 문제를 클라우드 저장소 공유를 통한 관할권 이관방식으로 해결하고자 했으나, 범정부 클라우드에 국한된 제안에 그침

클라우드 구축형태 및 IaaS 레벨의 다양한 구성방식을 조사 분석하여 최적의 인프라를 설계

○ PaaS, SaaS와 전자기록관리 체계 재설계

글로벌 기업들은 자사의 PaaS 플랫폼에서 자유롭게 App을 개발하고 다양한 SaaS 제품이나 API 제공서비스로 진화하고 있음

○ 기록관리에 필요한 기능 컴포넌트들이 PaaS와 SaaS 기반에서 조합되어 맞춤형 시스템의 기능을 구현하는 체계로 재설계

○ 차세대 기록시스템의 표준 기능모델 수립

NARA ERA, 아카이브매티카(Archivematica) 등의 사례를 참고하여 기록시스템(RMS와 AMS 포함)의 기능요건을 최소단위로 분할 및 요건 작성

도출된 요건은 시스템 아키텍처 설계 시 개별 서비스 단위로 API를 통해 필요로 하는 곳에 전달됨

○ 차세대 기록시스템의 인프라 아키텍처 설계

마. 행정정보데이터세트 기록관리 체계 설계

○ 행정정보 데이터세트의 서비스 및 장기보존

행정정보시스템의 데이터세트는 빅데이터 시대의 raw data 보고(寶庫)로 재인식될 필요 가 있음(ex.서울시제공 데이터세트 약 5천 개)

데이터세트의 현황관리, 이관, 보존방안 연구를 넘어 클라우드 상의 포착/분석/처리/활용 전략으로 개념 확장

○ 행정정보데이터 기록관리 추진 경과

행정정보데이터세트 기록관리 연구용역(‘07.12, 프로세스혁신팀)

행정정보데이터세트 기록관리 시범 시스템 구축(‘09.12, 기록정보화팀)

데이터세트 구조분석 및 진본성보장 기능모델 연구(‘15.12, 정책기획과)

행정정보시스템 현황 조사 및 데이터 분석(‘16년, 전자기록관리과)

“행정정보데이터세트 기록관리 방안” 마련·보고 : (‘16. 12, , 전자기록관리과)

○ 행정정보데이터 기록관리행정정보데이터 기록관리 방향

행정정보데이터세트 기준표(인벤토리)에 기반한 데이터세트 관리

생산기관 자체 데이터세트 관리 원칙, 중요 데이터 국가기록원 이관 보존

<그림 2> 행정정보데이터세트 기록관리 설계기본 계획 (전자기록과 2016.12)

○ 행정정보데이터 활용 방안 연구

공공 데이터 포털 현황 (2017.03 현재 21,751개 데이터 목록 공개) 및 기록 활용서비스 현황 분석

공공기록관리 주체 역할과 위상 정립

행정정보시스템의 양적, 다양성 증가에 대비 고려사항 검토

로드맵 상 발전 방향 수립

바. 중앙영구기록관리시스템 (CAMS) 재설계

○ CAMS 구축 추진 경과

‘06년: 중앙영구기록관리시스템(CAMS) 신규 구축

’07년 : 시소러스 및 생산기관 변천연혁관리시스템 기능 추가

’08년 : 행정박물, 구술기록물 등 특수기록물관리 기능 개발

’09년 : 비밀기록물관리시스템 구축 및 CAMS 기능 보강

’10년 : 열람활용기능 및 기록물 연계등록기능 보강

’11년 : 특수유형 기록물 세부관리기능 보강

’12년 : 지자체 BRM 및 대용량시청각기록관리시스템 등 유관시스템 연계

’13년 : 전자기록물 이관기능 성능 개선, 기술·재분류, 보존업무 등 전자·비전자 통합처리 기능 개발, 시험이관 등

’14년: 중앙영구기록관리시스템 개편 사업

○ CAMS 기능 구성도

<그림 3> 중앙영구기록관리시스템 재설계 방향

모듈화 및 기능 분리 신기술 적용 가능 기능 검토 및 고도화

세대 기록관리체계 로드맵 상 발전 방향 수립

2. 연구 방법

가. 법령, 표준 및 가이드라인 분석

○ 각국의 클라우드 정책 및 내셔널 아카이브의 클라우드 기반 기록관리 가이드라인 분석 (NARA, TNA, NAA 등)

○ 차세대 기록관리 모델 재설계 실현을 저해하는 요소들을 확인하고 이를 정비할 수 있는 방안을 제시

나. 문헌 연구

○ 클라우드 환경의 전자기록관리 프로세스 변화 및 고려사항, 빅데이터 분석, 다양한 유형의 기록 포착과 관리, 서비스 방안을 정리한 보고서와 학술연구 분석

○ 문헌을 통한 현행 프로세스 분석으로 실질적인 문제에 대한 이해와 해결책을 제시함으로써 차세대 전략 방향 도출

다. 국내 전자기록관리 프로세스 및 시스템 분석

○ 현행 전자기록관리 단계별 프로세스 및 생산, 준현용, 비현용 단계의 시스템 기능과 아키텍처, 한계점 분석

○ 정부 표준프레임워크의 기술적 구조, 오픈소스 컴포넌트 적용현황, 변화상, 향후 전략 분석

○ 클라우드 환경에서의 기록 생산·관리 기관 별 R&R 및 H/W, M/W, S/W 분석

○ 지속적인 개발과 배포를 위한 오픈소스 라이선스의 적용 및 오픈소스 프로젝트 형성과 유지를 위한 예산, 기간 투여의 제약을 줄일 수 있는 방안 모색

라. 사례 분석

○ 해외 전자기록관리 프로세스 및 시스템 개발, 운영 우수사례 분석(미국, 영국, 호주 등 내셔널 아카이브 및 ERA, Archivematica 등 시스템 개발사례)

○ 국내외 기록관리 기관 협력 및 오픈소스 프로젝트 운영 사례 분석(POWRR, PREFORMA, VeraPDF, AtoM, Omeka 등)

○ 데이터세트 아카이빙 현황 및 서비스 플랫폼 분석(Arkivum 등)

○ 마이크로서비스 아키텍처 설계 및 IT운영사례 분석(Archivematica 등)

○ BagIt 규격 활용사례 분석(미국 LC, Archivematica 등)

1. 현행 전자기록 프로세스와 표준 시스템 분석

1.1. 기록관리 프로세스

가. 기록관리체계

○ 현행 기록관리 프로세스 기록의 생애주기에 따라 현용 및 준현용 기록의 생산과 이후 보관 및 활용 단계, 그리고 비현용 기록의 보존의 3단계로 진행함

<그림 4> 기록관리체계 3단계

○ 각 단계에서의 관리 주체가 다르기 때문에 생산 단계를 처리과 프로세스, 보관 및 활용 단계는 기록관 프로세스, 마지막 보존 단계는 영구기록관리기관 프로세스임

○ 단계별 세부 프로세스는 다음과 같으며 순차적으로 진행함

<그림 5> 각 단계 주요 프로세스

○ 생산시스템 현황

2004년 이래 전자문서시스템이 주요 기록 생산시스템으로서 생산해온 시행문 및 접수문서 서식의 전자결재문서가 주요 기록관리 대상임

2008년 하반기 “통합 온-나라시스템”이 중앙행정기관에 보급 완료되어 전자문서시스템으부터의 생산방식은 중지하고 생산시스템을 일원화함. 온-나라시스템 생산되는 단위과제카드, 문서관리카드, 메모보고, 지시사항 등이 추가됨

2016년 국회 결산 시 정부는 각종 회의가 개최된 경우 공공기록물 관리에 관한 법률에 따라 회의록을 기록· 관리·유지하도록 시정 요구가 있었음. 이에 따라 2017년 각급기관에서 공공기록물법 시행령 제18조 제1항 각호에 해당하는 회의를 개최한 경우 반드시 회의록· 속기록을 작성하여 관리하는 지침이 전달되었으며 회의록 증가가 예상됨1)

온-나라 시스템은 2016년 클라우드 온-나라시스템 개발 이래 2017년 중앙부처 확산 보급 추진 중으로서 기록 유형에는 변동이 없으나 전자기록 포맷으로서 공개형 문서 포맷 (Open Document Format)이 도입됨

과거 종이 기록을 디지털화하거나 대면 결재를 통해 생산 또는 민원 문서 등 비전자 기록 또한 기록관리 대상으로서 전자문서시스템 또는 온-나라시스템에 등록하거나 기록관리시스템에 등록하고 있음

나. 전자기록 관리체계

○ 전자정부구현을위한행정업무등의전자화촉진에관한법률(2001.3.28. 제정) 이래 전자문서가 결재에 의해 성립되는 근거가 마련됨에 따라 신전자문서시스템과 업무관리시스템이 전국 공공기관에 구축되었음. 양 시스템은 전자문서 생산시스템으로서 2004년 이래 대량의 전자기록을 생산해오고 있음

○ 전자기록은 ISO 15489에서 기술한 전자기록의 특성으로 인해 전통적인 기록과 다른 개념 정립을 필요로 함2)

진본성 (authenticity)

신뢰성 (reliability)

무결성 (integrity)

가용성 (usability)

○ 전자기록의 특성을 관리체계에 반영하여 전자기록관리체계는 생산이전단계를 도입한 4단계 기록관리체계가 제안되었음3)

1) 국가기록원, 2017년 기록물 관리지침, 2016.12 2) 전자기록물 영구보존 기반기술 연구, 국가기록원, 2005 3) 전자기록물라이프싸이클 4단계 모형, 국가기록원 (http://archives.go.kr/next/manager/electronicSys.do)

<그림 6> 전자기록관리체계 4단계

생산이전단계는 가상의 관리단계로서 다음과 같은 세부 프로세스에 의해 전자기록 관리의 기본 계획과 정책을 수립함

· 관리를 위한 전산시스템 구축

· 진본성, 무결성을 지닌 기록관리 시작점

· 조직 업무분석, 분류체계 확립

· 가치평가를 통한 처리일정의 확립 필요

○ 처리과 프로세스

처리과는 기록의 생산자로서 업무관리시스템 및 전자문서시스템, 비전자 기록물을 생산하고 매년 정리하여 생산현황보고를 시행하며 기산일로부터 2년 범위 내에서 보관

기산일로부터 2년경과 시 기록관으로 이관

<그림 7> 처리과 프로세스

○ 기록관 프로세스

기록관은 매년 생산현황보고를 취합하며 인수한 기록의 평가를 실시하여 공개여부 및 보존기간을 재분류함

서고관리, 매체수록 등의 비전자 기록 보존관리 프로세스가 존재함

기록관이 보유한 기록 중 생산 후 10년이 경과한 기록 중 보존기간 30년 이상의 기록은 해당 기관의 영구기록관리기관으로 인계함

보존기간이 경과한 기록은 기록물평가심의회를 개최하여 폐기, 보류, 또는 보존기간 재책정을 해야 함

<그림 8> 기록관 프로세스

○ 영구기록물관리기관 프로세스

영구기록관리기관은 기록관으로부터 인수한 생산현황보고를 최종 취합함

처리과 프로세스에서 기록관으로 이관된 기록을 최종 장기 보존하는 단계로서 보존기간 30년 이상의 기록은 보존포맷으로 변환하여 보존함

비전자기록의 보존처리, 서고관리 프로세스가 있음

보유 기록 활용을 위한 컨텐츠, 열람 등의 프로세스 포함

공개여부, 보존기간의 재분류 실시

영구기록관리기관의 폐기 대상 기록물에 대하여 생산기관과 협의하여 기록물평가심의회 및 국가기록 관리위원회 심의를 거쳐 폐기

<그림 9>영구기록관리기관 프로세스

다. 각급 기관별 기록관리 프로세스

○ 공공기관은 관할 기록관 또는 특수기록관을 설치하여야 하며4) 기산일로부터 2년경과 시 기록관으로 이관하여야 함. 기록관리체계 3단계의 현용 및 준현용 단계의 기록은 생산기관에서 관리

<그림 10> 기록관리체계 3단계와 관리 주체 기관

4) 공공기록물 관리에 관한 법률 제13조(기록관) ① 공공기관의 기록물을 효율적으로 관리하기 위하여 대통 령령으로 정하는 공공기관은 기록관을 설치·운영하여야 한다. 다만, 제14조에 따른 특수기록관을 설치·운 영하는 공공기관의 경우에는 그 공공기관 내에 기록관을 설치할 수 없다. 공공기록물 관리에 관한 법률 시행령 제10조(기록관의 설치) ①다음 각 호의 어느 하나에 해당하는 공공 기관은 법 제13조제1항에 따라 기록관을 설치·운영하여야 한다.

○ 생산기관의 현용 및 준현용 기록 관리 프로세스

<그림 11> 생산기관 업무 프로세스

○ 영구기록물관리기관의 비현용 기록 관리 프로세스

<그림 12> 영구기록물관리기관 업무 프로세스

1.2. 표준 기록관리시스템

가. 표준기록관리시스템 구축 현황

○ 표준기록관리시스템 개발 배경

표준기록관리시스템이 도입되기 전 신전자문서시스템의 기록을 인수하기 위한 시스템으로서 자료관시스템이 개발되어 구축되고 있었음

그러나 업무관리시스템의 도입과 확산, 전자기록에 대한 연구 진전에 따라 새로운 기록관리시스템에 대한 요구 발생함. 다음과 같은 주요 도입 필요성

· 공공기록물 관리에 관한 법률 법령 이행 : 전자기록물 관리법령에 의거 전자기록관리 체계 마련 (제6조) - 전자문서 2년, 업무관리 (온-나라) 시스템 1년 단위로 전년도 생산기록물을 기록관으로 이관

· 전자기록물의 대한 진본성 보장을 위한 장기보존관리 체제 마련 : 전자기록물에 대한 진본성 유지를 위한 데이터 관리 체계 구축, 기록물의 위·변조, 훼손 방지를 위한 인증정보 탑재

· 기록물의 업무처리 자동화로 효율성 증대 요구 : 기록물의 인수, 보존, 평가, 폐기 등 업무처리 온라인화로 업무효율성 증대

· 기존 자료관 업체 지원 곤란 : 자료관시스템 개발업체 도산 등으로 기록물 인수를 위한 기술지원 불가

○ 표준기록관리시스템 보급 추진 경과

국가기록원을 중심으로 2005년 표준 기록관리시스템 혁신 ISP 이후 표준 기록관리시스템의 구축과 전 공공기관 확산이 추진되었음

<그림 13> 표준 기록관리시스템 확산 연혁

2012년 이후 표준기록관리시스템 안정화를 위한 기능보강 (관리대상 기록물의 범위 확대, 업무처리 절차 간소화 등)이 추진되었고

2014년 ~ 2016년 전자정부 프레임 적용 및 전행정기관에 보급하였으며

2016년 범정부 클라우드 기반 기록관리체계 구축을 시작하여

2017년 현재 클라우드 기록관리시스템 개발을 완료하고 2017.03.30. 이래 행정자치부에서 시범 운영 중이며 확산 예정

국가기록원은 2016년 표준기록관리시스템 보급 대상 행정기관에 100% 보급을 완료하였음5)

<그림 14> 기관별 표준기록관리시스템 보급 현황(2016년 12월 말 기준)

○ 표준기록관리시스템과 타 시스템 연관 개념도

표준기록관리시스템은 생산 시스템으로서는 온-나라시스템, 전자문서시스템과 연계되며 정부기능분류(BRM)을 기록물 분류체계로 연계하고 있음

표준기록관리시스템 구축 기관의 업무 담당자에게 서비스를 제공하고 현용 및 준현용 단계에서는 정보공개 시스템을 통하여 대국민에게 기록 서비스를 제공. 표준기록관리시스템 1.0 버전은 통합정보공개시스템과 연계 기능이 구현되어 있지 않았으며, 전일 결재 문서 목록과 원문공개를 목적으로 하기 때문에 온-나라시스템이나 전자문서시스템이 정보공개시스템과 연계하여 목록 및 원문공개 서비스를 제공하고 있음

영구기록물관리기관으로 이관한 기록물은 영구기록관리시스템에서 보존 및 활용됨

<그림 15> 표준기록관리시스템과 타 시스템 연관 개념도

5) 2016 국가기록백서, 국가기록원

○ 클라우드 기록관리시스템 등장

클라우드 기록관리시스템 개발

· 2014년 정부3.0 발전계획 핵심과제인 ‘클라우드 기반 지식 정부 구현’ 국정과제 및 ISP를 시작으로 2015년 클라우드 온-나라 시스템의 개발과 더불어 클라우드 기록관리시스템 설계에 착수

· 2016년 클라우드 기반의 협업 및 공유기반 고도화 사업을 통해 클라우드 기록관리시스템 개발을 완료하여 시범 적용

· 2017년 현재 14개 기관 1차 확산 예정

클라우드 기록관리시스템에서 개발 완료된 기능은 기록물 인수, 기록물 보존, 기록물 이관, 검색, 통합 검색, 보존포맷 변환 서비스이며 범정부 클라우드 환경 하에서 클라우드 온-나라시스템, 클라우드 디렉토리 등과 연계함

<그림 16> 클라우드 기록관리시스템 연계 개념도

범정부 클라우드 환경에서 운영되는 클라우드 기록관리시스템의 위치 및 구성은 다음과 같음

<그림 17> 범정부 클라우드 환경 기반의 클라우드 기록관리시스템

나. 기록관리시스템 기능

○ 표준기록관리시스템은 업무관리시스템과 전자문서시스템과 연계 생산 기록의 생산현황보고와 연계 인수, 기록 재분류를 위한 평가, 보존포맷 변환, 보존관리 기능으로 구성됨

<그림 18> 표준기록관리시스템 기능 흐름도

○ 표준기록관리시스템 기능

표준기록관리시스템은 117개의 소기능으로 구성됨 ※ [첨부] 표준기록관리시스템 기능 목록

기록물 인수

· 온-나라 시스템과 전자문서시스템과 연계 인수 가능, 비전자기록은 수동으로 등록 인수 가능

<그림 19> 표준기록관리시스템의 기록물 인수

기록물 보존

· 장기보존 시 전자파일 내용 재현을 보장하기 위하여 국제적인 표준 문서 포맷인 PDF/A로 변환

· 영구기록물관리기관으로 이관하는 기록은 표준 장기보존포맷인 NEO 포맷으로 변환

<그림 20> 표준기록관리시스템의 기록물 보존

기록물 이관

· 장기보존포맷으로 변환된 기록을 영구기록물관리기관 시스템으로 이관

<그림 21> 표준기록관리시스템의 기록물 이관

기록물 평가

· 평가대상(매5년 공개재분류, 보존기간 만료 등) 에 대한 자동선별과 평가 단계별 자동 관리 및 처리결과 이력 확인

<그림 22> 표준기록관리시스템의 기록물 평가

검색 및 활용

· 조건별/분류체계별 기록물철/기록물건 검색 및 각종 통계 분석

<그림 23> 표준기록관리시스템의 검색 및 통계

다. 하드웨어 및 소프트웨어

○ 표준기록관리시스템 구축 시 서버는 AP 서버, DB 서버 및 보존포맷변환 서버로 구성됨

<그림 24> 표준기록관리시스템 서버 구성도(예시)

○ 표준기록관리시스템 구축 시 필수 도입해야 하는 하드웨어 및 소프트웨어의 목록은 다음과 같음

구 분 내 역 수량

· 1. 표준 기록관리시스템 DB 서버 · 1식

· 2. 표준 기록관리시스템 AP 서버 · 1식

H/W · 3. 보존포맷(PDF) 변환서버 · 1식

· 4. 일반스토리지(U6TB 이상) · 1식

· 5. 서버 랙 및 콘솔(KVM포함) · 1식

· 1. WEB / WAS Server · 1식

· 2. DBMS · 1식

· 3. Anti-Virus 솔루션 · 1식

S/W · 4. 대용량 송수신 S/W · 1식

· 5. 검색엔진 · 1식

· 6. 백업소프트웨어 · 1식

· 7. 보존포맷 변환 S/W · 1식

<표 7> 표준기록관리시스템 구축 HW와 SW

○ 하드웨어 및 소프트웨어에 대하여 상용 하드웨어 및 소프트웨어 중 선택 가능함

1.3. 중앙영구기록물관리시스템(CAMS)

가. 중앙영구기록물관리시스템 구축 연혁 및 주요 이슈

○ 개별 시스템으로 독립적으로 운영하던 문서기록물, 시청각 등 8종 시스템을 통합한 후, 지속적인 기능 개선을 해왔음

<그림 25> CAMS 구축 추진 경과

주요 개선 사항

· CAMS최초 구축 · 기록종류별 개별시스템 8종(문서기록물, 시청각기록물, 정부간행물, 분류기준표, 2006 외국기록물, 1945년 이전 기록물, 대통령기록물, 비밀기록물) 구축, 운영으로 통합관리 미비 · 기록관리시스템과 국가기록원시스템 미연계 상태

주요 개선 사항

· 기능고도화 및 관련시스템 연계(총 317개 구현) EX)보존관리 102개, 기록물기술 47개, 열람활용 58개, 관련시스템 연계 110개 2007 · 검색어 조합(AND, OR)불가, -> 검색조건지정가능 · 보존처리 스케줄링 작업 1회로 축소

· 특수기록물 등록/보존관리 기능, 장기검증시스템 고도화, 표준/보존포맷 시스템 고도화 2008 등 10건

2009 · 통계현황 관리기능, 비밀기록물목록관리, 복제방지 기능, 오류검사 프로그램 개발

· 대국민 서비스 제고를 위한 열람업무 프로세스 개선, 다양한 유형의 기록물 등록 기능 개선 2010 · DIP시범 서비스 모델

2011 · 해외/민간기록물 등록 및 검색, 간행물 등록, 기록물 복제관리, 기록물 반출입 관리 등

· 사용자 편의를 위한 주요기능 개선 2012 · 사용자 및 관리운영 매뉴얼 현행화 · 종합진단 완료보고 2012 · CAMS 진단지표 개발, 구조의 정밀번숙 및 개선방안, 개선모델 기본 설계, 개선모델 추진을 위한 이행계획 수립 (진단결과 심각55%, 미흡 30%, 적정15%)

· 인수기능개선, 통합관리기능개선, 연계기능개선, 관리기능개선 2013 · 전자기록물 시험이관 · 원문검색, 열람, 통계 기능 개발, 육안검수 조건별 샘플링, 바이러스 검출기록물 2014 인수기능 개발 등 2015 · 전자 전자화기록물의 대량 대용량화에 따른 시스템 보강

· RMS와 CAMS간 이관 규격 간소화 2016 · 무손실압축 전자기록물 관리체게 확대, 대량목록 조회 및 저장 업무처리 성능 개선

<표 8> CAMS 고도화 추진 내역

나. CAMS 운영 현황

○ 이관 기록물 외에 역사적 가치를 지닌 수집 기록 및 대량의 시청각 기록을 보유하고 있음

구분 시대별 보유량(권,매) 주요내용 소계 3,657,270 조선시대 1,193 조선왕조실록, 구황실문서, 기타 문서 일제시대 40,500 조선총독부문서 등 정부수립후 3,615,577 각 기관 이관기록물 소계 226,613 조선시대 288 기상관측도 등 도면 일제시대 34,718 지적원도, 국유림경계도, 삼각원도 등 정부수립 후 191,607 광구도, 청사설계도, 각종공사설계도 등

구분 시대별 보유량(권,매) 주요내용

소계 422,715 카드 조선시대/일제시대 0 정부수립후 422,715 인사기록, 병적카드, 공무원연금카드 등 소계 2,908,342 비디오류 54,024 대한뉴스 및 기록영화, 대통령해외순방 등 대통령 신년사ㆍ기자회견, 대통령 주재 주요 시청각 오디오류 12,874 회의 등 사진류 2,841,444 역대 3부 요인 및 역대 장관, 국가 주요 행사 등 소계 62,873 관인류 18,004 국새, 직인, 청인 상장물, 견본류 8,362 화폐, 우표, 훈장ㆍ포장 기념물 상징류 957 현판, 기,휘호, 모형, 의복, 공무용품 기념류 33,786 포스터, 팜플릿, 기념품, 등록카드 상장훈장류 103 상장, 상패, 메달, 트로피 사무집기류 사무집기류 61 사무집기 기타 그밖의 유형 1,600 영구기록관리기관의 장이 지정한 그 밖의 유형 행정간행물 권 561,352 기관별 수집 간행물, 일반출판사 발행도서

<표 9> CAMS 기록 보유 현황

다. CAMS 기능

<그림 26> 영구기록물관리기관 기록관리 기능 흐름도

<그림 27> CAMS 업무 기능 구성도

1.4. 현행 기록관리 프로세스 및 시스템 분석 시사점

○ 전자결재 문서 중심 기록관리체계

전자문서시스템과 온-나라시스템에 제한적으로 연계 인수

행정정보 데이터세트, 시청각기록 등의 다양한 유형 관리에 미흡

○ 표준기록관리시스템 활용 저조

시스템 불안정성

사용자 사용 시 복잡, 불편

활용을 위한 기초 작업 미비

비전자기록 관리 지원 기능 불충분

○ 보존포맷 대안 모색

문서 생산 포맷의 변화로 문서보존 포맷

클라우드 온-나라시스템은 HWP 외 ODF를 생산 포맷으로 저장하는 기안기를 탑재하고 있어 ODF 결재 문서의 비중이 높아질 것으로 예상됨

장기보존포맷 비효율성

· 현행 장기보존포맷은 XML 기반 포맷으로서 기록물건을 구성하는 모든 파일을

Base64 방식으로 인코딩하여 텍스트화하여 삽입함. 이 방식은 기록물건의 모든 요소를 1개 패키지로 만든다는 점에서 기록물건의 무결성, 진본성, 신뢰성을 보장하기 위한 보존 포맷으로서 적합함 · 그러나 포맷 변환에 투입되는 시간, 자원이 많이 소요되어 이관 프로세스의 지연 원인이 되며 이용이 어려움

<그림 28> 장기보존 기록 이관 업무 흐름도

○ 기록관리 기능 간소화 요구

생산현황보고는 국가의 기록관리 현황을 파악하고 정책 수립의 기초 자료로서 활용 가능하기 때문에 중요한 기능이나 기록관리에 대한 처리과나 기타 담당자들의 인식 부족, 시스템 기능 사용의 불편, 시스템 오류 등으로 실제 업무 부담을 가중시키나 생산현황보고 본래의 취지와 목적에 맞도록 활용되지 못 하고 있음

이에 생산현황보고 프로세스를 간소화하거나 시스템에 의한 자동 생성으로 업무 부담을 줄이면 동시에 활용을 높일 필요 있음

○ 표준기록관리시스템 개발과 확산 방식의 문제

국가기록원 표준기록관리시스템을 개발하고 표준시스템을 전국 공공기관에 보급하는 현행 방식은 수많은 기관의 다양한 요구를 수용하기 어려움

기록관리를 위한 다양한 도구와 시스템 개발의 기회가 협소하여 관련 분야 소프트웨어 개발사들의 참여를 유도하지 못 하므로 새로운 기술의 적용과 시험에 의한 빠른 기술 발전을 기대하기 어려움

2. ICBM 기술 및 국내외 관련 시스템 현황 분석

2.1. 클라우드

가. 개요

○ 정의

클라우드 컴퓨팅(Cloud Computing)은 각 PC 단말에서 개별적으로 프로그램을 설치해 데이터를 저장하던 기존 방식에서 벗어나, 인터넷 네트워크상에 모든 컴퓨팅 자원을 저장하여 개별 컴퓨터에 할당하는 개념

· 서로 다른 물리적 위치에 존재하는 컴퓨터의 리소스를 가상화 기술로 통합 제공하는 것이 기본 원리

· IT자원을 필요할 때 필요한 만큼 빌려 쓰고, 이에 대한 비용을 지급하는 방식의 서비스를 구현

· 개별 단말에 따로 데이터를 저장하는 것보다 데이터를 중앙 서버에 통합 처리하는 편이 데이터 업데이트와 정보보안에 효과적이고, 스토리지 관리 면에서도 유용함

○ 클라우드 종류

공용 클라우드(Public Cloud)

· 누구나 함께 이용할 수 있게 구축된 대규모 서비스

· 트래픽 및 자원 사용량 증가 시 바로 확장이 가능한 확장성, 저렴한 서비스 비용으로 인한 경제성, 시스템 유지보수나 장애 대응을 위한 효율성에 최적화

사설 클라우드(Private Cloud)

· 내부에 직접 클라우드 인프라를 구축한 형태로 직접적인 통제 권한을 가진 서비스

· 공용 클라우드와 달리 구성된 여유 자원이 한정되어 있어, 확장에 제약이 있을 수 있음

하이브리드 클라우드(Hybrid Cloud)

· 공용 클라우드와 사설 클라우드를 함께 이용하는 형태

· 보안이 중요한 서버들은 사설 클라우드 환경으로 구성하여 외부 접속을 차단

· 기존에 운영 중이거나, 높은 성능을 필요로 하는 물리 서버들과 연동하여 사용자의 요구에 맞는 최적의 인프라를 설계할 수 있는 장점

○ 클라우드 서비스 유형

<그림 29> 클라우드 유형별 관리 영역

IaaS(Infrastructure as a Service)

· 서버, 스토리지, 네트워크 등과 같이 시스템이나 서비스를 구축하는데 필요한 IT자원을 서비스로 제공

· Networking~Server(가상화 포함)까지의 서비스를 제공

PaaS(Platform as a Service)

· 시스템 구현을 위한 개발 도구, 개발 환경, 실행 환경 등의 플랫폼을 서비스로 제공

· IaaS에 O/S, Middleware, Runtime이 포함되어 있는 구조

SaaS(Software as a Service)

· 인터넷 환경에서 사용자가 원하는 소프트웨어를 서비스로 제공

· Application까지의 모든 영역을 서비스로 제공

나. G-클라우드

○ 정의

G-클라우드는 ‘Government’, ‘Global’을 뜻하는 정부통합전산센터 클라우드의 고유 명칭으로서 스마트 전자정부 서비스를 위해 행정기관의 IT자원 수요를 모아 정보자원을 통합하여 일괄구축ㆍ공동 활용하고, 필요한 만큼 신속하게 제공하는 기술 및 서비스

○ 주요 특징

정부 전용 사설 클라우드

· 통합센터가 직접 구축하고 운영

· 행정기관 간 자원을 공동 활용하는 커뮤니티 클라우드 형태 · IaaS 서비스 제공, PaaS 및 SaaS 서비스 제공 목표

표준화, 범용화, 규격화된 인프라

· 공개 SW 기반으로 운영환경 표준화

· 범용 HW 사용을 통한 제조사 의존성 탈피

· 규격화 된 인프라 구성을 통해 일관성 있는 시스템 구축

정부 클라우드 서비스에 최적화된 보안환경

· 통합보안 9방어 5분석 하에 클라우드 전용 보안환경 추가 제공

· 네트워크 가상화를 통해 기관별 독립된 환경 제공

· 기술 내재화를 통한 공개SW 기반의 보안솔루션 적용

범용 x86 서버, 공개SW 적용으로 관련 산업 육성

· G-클라우드 전용으로 국산화 가능한 x86 서버 4종 규격을 마련

· 공개SW 및 국산SW 사용 확대로 국내 중소 SW 업체 활성화

○ 추진 현황

정보자원 통합 추진 현황

· 2005년 행정기관 정보시스템의 위치 통합을 시작하여 2009년부터 하드웨어 통합

· 2013년부터 기존 정보시스템을 가상화 기반의 클라우드 컴퓨팅 환경으로 전환

· 2015년부터 범정부 빅데이터 공통기반 플랫폼 구축사업

<그림 30> 정보자원통합을 위한 추진 내용

클라우드 전환 추진 현황

· 정부는 독자운영이 요구되는 시스템을 제외한 740개 시스템을 2017년까지 G-클라우드 전환 계획

연도 2012 2013 2014 2015 2016 전환 시스템 수 42 77 141 158 159

<표 10> G-클라우드 년도별 시스템 전환 현황

다. 클라우드 표준 기록관리시스템

○ 배경

2016년 클라우드 온-나라 개발 및 보급에 따라 개방형 문서 표준(ODF)이 적용되면서 효율적인 기록관리시스템 개발 필요

RMS는 2006년 개발된 이후 지속적인 고도화를 통하여 표준 시스템으로 확산이 진행되었으며, 공유ㆍ협업 중심의 기록관리 업무수행을 위하여 클라우드 RMS가 개발되었음

<그림 31> 범정부 클라우드 어플리케이션 구성도 출처 : 행정자치부, “정부지식 공유활용기반 고도화 완료보고서”, 2017.

○ 주요 개선 사항 및 기대효과

업무구분 개선내용

· 클라우드 환경을 고려하여 주요 모듈을 분리 및 재배치를 모듈분리 및 재배치 통한 유연한 구조로 설계 · 클라우드 환경에서 RMS가 개발됨에 따라 소규모 기록관 소속기록관 독립 RMS 운영 단위 운영이 가능해짐 · 대용량 송수신 SW기반의 인수방식에서 클라우드 환경의 온-나라시스템 기록물 인수 공유저장소를 활용한 스토리지 기반의 인수를 통해 안정성과 기능 개선 속도가 개선

CAMS기록물 이관 기능 · CAMS 이관을 위한 표준 대용량 송수신 SW를 개발하여 개선 클라우드 환경 특성을 고려한 이관 기능을 개선함 병렬처리를 통한 포맷변환 · 병렬처리를 통한 다수 기관의 기록물 포맷변환 작업 수행 다기관 지원/성능 개선 기록관 통합검색 기능 개선 · 클라우드 RMS 사용 기관의 기록물 통합검색 환경 구축

<표 11> 클라우드 RMS 개선사항 요약

클라우드 RMS는 정부 3.0 실현을 위한 기록정보서비스 구현의 초석이 됨

대국민, 공무원, 시스템, 비용 측면에서 다음과 같은 기대효과를 예상

· 대국민 측면 : 기록정보서비스 확대 기반 마련

· 공무원 측면 : 소통/협업/공유를 통한 업무 효율 향상

· 시스템 측면 : 시스템 운영ㆍ관리 효율성 제고

· 비용 측면 : 시스템 구축ㆍ운영비용 최소화

○ 추진 현황

온-나라/RMS 등 공통업무의 클라우드 전환을 통해 범정부 협업ㆍ지식행정 기반 조성 환경을 구축하여 클라우드 RMS 확산 계획을 수립

2015년 클라우드 RMS 설계를 기반으로 2018년 전 중앙부처 확산을 목표

구축년도 기관수 대전 통합전산센터 광주 통합전산센터 단독형

‘16 ~ ’17 1개+소 행정자치부+소속위원회 - - 상반기 속위원회 공정거래위원회, 국민권 고용노동부, 국가보훈처, 보 익위원회, 국토교통부, 병 2017년 14개 건복지부, 조달청, 행정중심 무청, 산림청, 식품의약품 - 하반기 복합도시건설청, 환경부 안전처, 중소기업청, 농림 축산식품부

구축년도 기관수 대전 통합전산센터 광주 통합전산센터 단독형

감사원, 관세청, 교육부, 국 무조정실, 국무총리비서실, 국민안전처, 금융위원회, 국가인권위원회, 기상청, 기획재정부, 문화체육관광 농촌진흥청, 문화재청, 법 2018년 27개 부, 미래창조과학부, 민주 무부, 새만금 개발청, 여 - 평화통일자문회의, 방송통 성가족부, 인사혁신처, 통 신위원회, 법제처, 산업통 일부, 특허청 상자원부, 원자력안전위원 회, 통계청, 해양수산부

경찰청, 국방부, 외교부, 2019년 6개 - - 방위사업 이후 청, 국세청, 대검찰청

<표 12> 클라우드 RMS 기관별 확산 추진 경과 및 일정

2.2. 블록체인

가. 기술요소

○ 등장배경

최근 디지털 및 IT 기술을 통하여 사람-사람(P2P), 사람-사물(P2M), 사물-사물(M2M)은 온라인과 오프라인을 넘나들며 긴밀하게 연결되는 초-연결사회로 진입하고 있음. 초-연결사회란 IT를 바탕으로 사람, 프로세스, 데이터, 사물이 서로 연결됨으로써 지능화된 네트워크를 구축하여 이를 통해 새로운 가치와 혁신 창출이 가능한 사회임. 따라서 제 3자의 개입 없이 구성원 사이의 협업을 통해 지능화된 네트워크 신뢰를 구축할 수 있는 블록체인 플랫폼 기술은 전 산업 부문에서 관심이 확대됨

4차 산업혁명을 견인하는 7대 기반기술 (빅데이터, IoT 등) 중 가장 핵심적인 기술로 블록체인(분산원장) 선정.6) 블록체인은 4차 산업혁명에서 기존 산업의 연결과 융·복합을 기반으로 한 패러다임 변화의 도구로 소비자와 생산자를 실질적으로 연결하는 네트워크의 혁신중 하나임. 세계경제포럼(WEF)에 참가한 글로벌 전문가 및 경영진의 50% 이상이 ‘25년까지 블록체인 기반의 플랫폼이 전 세계 GDP의 약 10%를 차지할 것으로 전망

6) (세계경제포럼, 2016.08)

○ 블록체인 개념

사이버 거래정보를 P2P 네트워크에 공동으로 관리하는 신개념 분산거래장부로 네트워크에서 모든 참여자가 공동으로 거래 정보를 검증/기록/보관하는 보안기술. 개인과 개인, 공공기관과 개인, 기업과 기업 사이에 발생하는 다양한 형태의 거래관계를 획기적으로 개선시킬 수 있는 데이터·네트워크·암호·저장방식 등의 기술적 요소를 모두 결합한 신개념 기술 기반 거래 플랫폼.7)

<그림 32> 블록체인의 요소 금융위원회, 성신여대, 블록체인기술 금융분야 도입방안을 위한 연구, 2016.06.

○ 블록체인 특징 : 디지털 정보의 보안 · 관리 이슈에 대한 중재자가 필요 없는 신뢰 프로세스

대규모의 노드들 사이에서 각 노드에 분산 저장된 장부의 데이터를 항상 최신 버전으로 유지할 수 있도록 하는 합의 수렴 알고리즘으로 볼 수 있음. 이러한 능력은 노드가 익명으로 실행되거나, 연결이 좋지 않거나, 심지어 신뢰할 수 없는 운영자가 참여하는 것도 가능하게 함

모든 탈중앙 암호화폐의 노드는 부분 또는 전체의 블록 체인을 소유. 이것이 페이팔과 같은 시스템에서 필요로 하는, 중앙 집중형 데이터베이스를 가지고 있을 필요를 없게 함. 일반적인 장부에는 수표나 영수증 또는 약속어음의 교환내역이 기록되는 반면에, 블록 체인은 그것 자체가 거래장부인 동시에 거래증서(수표, 영수증, 약속어음). 비트 코인에서는 거래들의 지불되지 않은 결과의 형태로 존재한다고 표현. "지불인 갑이 00원을 수취인 을에게 보내다" 형식의 거래는 소프트웨어 앱(비트코인 지갑앱 등)을 통해 블록 체인 네트워크에 뿌려지고, 블록 체인 네트워크의 노드들은 거래를 검증한 다음, 자신의 장부에 거래를 추가. 그리고 이 거래가 추가된 장부를 네트워크의 다른 노드들에게 전달

○ 블록체인 원리

7) KEMRI 전력경제 REVIEW ,블록체인 개념 및 활용사례 분석, 2017년 제 17호, 2017.4.3.

모든 구성원들이 네트워크와 위·변조 방지 프로그램을 통하여 정보를 검증함. 블록체인은 특정 시간(10분)마다 발생한 모든 거래기록 정보에 대하여, ① 정보 집합(블록)을 생성하고 (A가 B에게 송금요청) ② 거래내역이 담긴 블록 생성하여 ③네트워크상의 모든 참여자들에게 블록 전송 ④ 전송된 블록의 유효성이 확인될 경우 (작업증명) ⑤ 기존 블록체인에 최근 블록(Block)을 추가적으로 연결(Chain)하면 ⑥ 거래 승인 및 송금되는는 방식으로 구현. 8)

<그림 33>블록체인 원리 * 출처 : Finector, 블록체인 기술의 발전과정과 이해, ‘16.10

블록은 거래내역 및 발생시간 등의 내용을 문자, 숫자형태로 암호화하여 포함한 것으로 순차적으로 연결된 일종의 데이터 패킷을 의미함. 헤더와 바디로 구성된 구조체로 헤더에는 이전, 현재 블록의 해시 값, 넌스(Nonce) 등을 포함하고 있으며, 블록 검색 시 데이터 베이스 인덱스1) 방식으로 데이터 값을 획득. ※ 블록 헤더에는 다음 블록의 해쉬 값을 포함하지 않으나, 편의상 값을 추가하여 이용

○ 블록체인 유형9)

주요 필요/선결 구분 개념 및 특징 예시 요건 · 최초의 블록체인 활용사례 · 네트워크 효과 Bitcoin, Ripple, ① 공용블록체인 (비트코인) 안정적인 Li te coi n,Op en (Public · 인터넷을 통해 모두에게 공개, Ecosystem Bazaar Blockchain) 운용 가능한 거래장부 · 위험(Risk) DASH, · 컴퓨팅 파워를 네트워크에 제공 관리 Ethereum 등 ① 공용블록체인 함으로서 누구든 공증에 참여

8) KEMRI 전력경제 REVIEW ,블록체인 개념 및 활용사례 분석, 2017년 제 17호, 2017.4.3. 9) Let′s Talk Payments, Public and Private Blockchain Concepts and Examples, 2015.8.10., 국내외 금융분야 블록체인(Blockchain) 활용 동향, 금융보안원, 2015.11.23.

주요 필요/선결 구분 개념 및 특징 예시 요건 · 네트워크 확장이 어렵고 거래 (Public 속도가 느림 Blockchain) · Timeline : 현재

· 개인형 블록체인 · 시스템 변경 · 1개의 주체가 내부 전산망을 ② 사설블록체인 감수 /안정성 NASDA Q , 블록체인으로 관리 (Private 확보 Overstock, · Private Blockchain 개발을 위한 Blockchain) · 1개의 주체 내 Chain 등 플랫폼 서비스도 등장 글로벌 Branch · Timeline : 2016년 · 반중앙형 블록체인 · 미리 선정된 N개의 주체들만 · 참여 ③컨소시엄블록체 R3 CEV, HSBC, 참여 가능 주체들간의 비 인 Citi, · N개의 주체들 간의 함의된 즈 니 스 적 인 (Hybrid or B a r c l a y s , Rule을 통해 공증 참여 동의/합의 Consortium Goldman · 네트워크 확장이 용이하고 거래 · 시스템안정성 Blockchain) Sachs,BoA 속도가 빠름 확보 · Timeline : 2017~2018년

<표 13> 블록체인의 유형

나. 기술동향

○ 블록체인 기술 활용 분야

디지털 정보의 저장 : 네트워크 참여자들이 공동으로 거래 정보를 검증하고 이를 기록 및 보관 가능하고 분산원장 기술의 장점 중 하나로 향후 개별 거래와 관련된 정보 추적이 용이

개인정보에 기반한 디지털 인증 : 주소, 전화번호 등 기존의 개인정보 뿐만 아니라 사용자의 생체 정보도 추가한 디지털 신분증으로 더욱 간편하고 안전한 인증임. 그리고 대학, 기업, 정부 등 개인이 아닌 제3자가 인증한 정보도 블록체인에 등록함으로써 신원 도용, 자금 세탁, 금융사기 및 테러 자금 조달 방지가 가능

디지털 자산의 거래( 결제 및 해외송금 : 시장 변동성에 민감한 각종 금융자산(ex. 기업대출, 주식, 파생상품 등)의 거래 후 정산 과정의 속도와 효율성을 높여 자산거래의 변동성 위험이 낮음. 블록체인 해외송금서비스는 기존의 중개은행을 거치는 방식인 SWIFT망에 비해 보안성은 높고 송금수수료는 낮을 것으로 예상. ※ SWIFT: 국제은행 간 통신협회로 현재 전 세계 약 200개 국, 1만1천여 개 금융기관이 매일 SWIFT망을 통해 돈을 지불하거나 무역대금을 결제. 또한 디지털 화폐로 해외 송금 시 환전할 필요 없이 중개인을 거치지 않고 당사자 간 직접 거래가 가능

분야 내용

제 3자 신용기관 없이 사용자 간 인증을 통해 안전하게 유통이 가능하도록 전자화폐 한 가상 화폐 예) 비트코인

해외 송금 수수료를 획기적으로 낮출 수 있음 해외송금 비트코인과 문자메시지(SMS)를 결합한 해외송금서비스 예) 37Coins

나스닥 장외 주식거래소인 Private market에 블록체인 기술 시범 적용 기존 변호사를 통한 거래승인절차를 블록체인을 통해 자동화 및 안전하게 장외거래 실물증권을 관리하고 보관함 예) NASDAQ Private Market

국가토지대장을 블록체인을 통해 기록하여 해킹 및 조작을 원천적으로 데이터 저장 및 방지 보호(소유권기록) 예) 온두라스의 국가 토지 대장

사용자가 만든 P2P 네트워크상에서 상호 주고 받는 메시지를 암호화 및 메시지 보호 및 메시지를 보내고 받는 당사자의 주소도 추적할 수 없는 형태가 됨 저장 예) 비트 메시지

<표 14> 디지털 화폐의 거래

다. 활용 사례

○ 블록체인 활용 동향

글로벌 금융기업들은 블록체인 표준 플랫폼을 공동 개발하는 R3CEV라는 컨소시움을 구성하여 향후 1~2년 내에 전세계 은행들이 공통으로 사용할 수 있는 표준화된 블록체인을 선보일 예정이며, JP모건, 뱅크오브아메리카, 씨티그룹, 모건스탠리, 홍콩 상하이은행, UBS, 도이치뱅크 등 70여개의 글로벌 기업과 은행들은 핀테크 기업 R3*와 제휴하여 진행 * R3는 기본 시스템 설계 및 기술 개발을 담당하고, 글로벌 은행들은 자사 API에 연 결해 테스트 및 사용자 인터페이스를 디자인하는 역할 담당. 국내에서는 KEB하나은행, 신한은행, 국민은행, 기업은행 등 5개 은행이 참여. 마이크로소프트(MS)나 IBM 등 글로벌 기업도 블록체인 기반 플랫폼에 관심을 갖고 자사 비즈니스와의 연계 및 상용화에 집중하고 있음. 삼성전자는 주요 계열사간 금융거래 플랫폼을 블록체인 기술을 기반으로 개발하여 2017년 중 실제 업무에 도입 예정이며 LG는 2015년 비상장주식 유통 플랫폼 개발에 성공하여 스타트업 5개사의 전자증권 발행에 활용

○ 국내 블록체인(Blockchain) 활용 동향

최근 금융권에서 블록체인 기술에 대한 관심 증가하고 있으며, 선도적 이미지 구축을 위해 금융회사, PG사, 핀테크 스타트업 등에서 다양한 실험적 시도가 있음. 주요 내용은 아래의 표 참고

10)

구분 블록체인 연구 및 활용을 위한 주요 활동

신한은행 외환 송금서비스에 블록체인 기술을 적용한 스타트업과 협업 외환송금서비스, 개인인증서, 문서보안서비스 등에 국내 스타트업과 KB 국민은행 제휴를 추진하고 서비스 개발에 15억원 투자 NH핀테크 오픈플랫폼 사업 추진의 일환으로 서비스 모델링을 위해 NH 농협은행 핀테크 기업 20곳과 양해각서를 체결, 이중 국내 최초 비트코인 거래소 코빗 포함 KEB 하나은행 핀테크 기업 육성센터를 통해 블록체인 기술 업체와의 협업을 준비 중 블록체인 기술을 적용한 KSM(Korea Startup Market) 프로젝트를 한국거래소 직행, 美 나스닥에 이어 세계에서 두 번째로 블록체인 기술을 자본 금융 시장에 적용 한 국 예 탁 결 제 2016년 7월부터 글로벌 블록체인 프로젝트인 ‘하이퍼 레저(Hyper 원 Ledger)’에 회원으로 참여 핀테크 협업 프로그램 위비핀테크랩을 통해 7개 핀테크 스타트업을 우리은행 선발, 전북은행 블록체인기반한 스마트 뱅킹 로그인 도입 블록체인 기반 인증시스템(공인인증서나 비밀번호 없이 지문인증) 롯데카드 상용화 IBK 은행 외환송금, 문서공증 등 금융서비스 개발 코빗과 제휴 IBM과 함께 블록체인을 이용하여 사물인터넷(IoT) 기기가 서로 소통하는 P2P네트워크에 활용* 삼성전자 국제전자제품박람회에서 IBM이 사물인터넷 플랫폼 어뎁트 (ADEPT, Autonomous Decentralized Peer-to-Peer Telemetry)에서 발표 삼성SDS 블록체인 관련 플랫폼 ‘넥스레저’ 개발 국내 스타트업 기업과 금융 상품 유통플랫폼 파일럿시스템 구축을 LG CNS 위한 사업 협력 MOU(업무협약)를 체결 입금, 정산, 에스크로 등을 처리하는 블록체인 플랫폼을 핀테크 업체에 페이게이트 공개하고 블록체인을 데이터베이스 및 정산소로 활용 블록체인 기반의 비트코인 거래소 및 전자지갑, 개인인증서 서비스 비금융 코인플러그 제공 휴대폰을 이용하여 송금하고 ATM에서 수신할 수 있는 송금형태 한국 최초의 비트코인 스타트업 회사로 국내 최대의 비트코인 거래소 코빗 운영 스트리미 블록체인 네트워크를 이용한 해외송금서비스 제공 블록체인을 활용한 서비스를 개발할 수 있도록 클라우드 기반의 개발 블로코 플랫폼 제공 암호키를 분산 저장하여 거래소가 해킹당하더라도 비트코인을 보호할 디바인랩 수 있도록 안전성을 강화한 비트코인 월렛 제공 포티스 동남아시아 지역에 블록체인 기반의 오픈 페이먼트(지불) 솔루션 적용

<표 15> 국내 주요 블록체인을 활용 현황

10) 국내외 금융분야 블록체인(Blockchain) 활용 동향, 금융보안원, 2015.11.23., 이대기. ‚금융업의 블록체인 국내외 활용사례 및 시사점‛, 한국금융연구원, 2016.9, 머니투데이. ‚금융권 뒤흔들 ‘블록 생태계’…LG CNS가 ‘첫 삽’ 뜬다‛,

○ 전력분야의 블록체인 활용

<그림 35> TransactiveGrid Brooklyn Microgrid Project * 출처 : PwC, ‘Blockchain-an opportunity for energy producers and consumers’, ‘16.3

Rocky Mountain Institute와 Grid Singularity에 설립한 스위스 비영리기관으로 Energy Web Foundation (EWF)의 미션은 전력분야 내 블록체인 기술 활성화한다. 전력분야 블록체인 활성화를 위한 주요 활동 내역으로는 블록체인 활용 가능 케이스 평가 및 구체화, 블록체인 소프트웨어 인프라 구축 및 제공, 블록체인 사용자 및 개발자 생태계 조성, 규제기관 및 블록체인 시스템 사용자 교육함

독일 EV 충전 지불 시스템 (無 계약) Block Charge 프로젝트 (Slock.it & RWE)는 전기차 충전기에 블록체인을 활용한 이더리움 어플리케이션 프로젝트 추진하여 중개자에 의존하지 않고 블록체인을 활용한 무 계약 지불 시스템 개발하였다. App으로 동작하는 스마트 플러그를 이용한 전기자동차 재-충전 시스템으로 모든 거래(충전 및 거래)는 블록체인 기반 시스템을 이용하여 관함. 특징으로는 사물통신(M2M, Maching to Machine)을 구현하여 편리성 추구, 스마트 계약을 활용하여 간편하고 안전한 지불 시스템. 충전 · 지불 프로세스를 충전소와 상호작용하여 결제 절차를 자동적으로 관리함11)

스마트미터를 이용한 크라우드 펀딩 플랫폼 (Bankymoon)는 블록체인 기반의 비트코인을 활용한 남아공 스타트업 기부 플랫폼. 남아공의 전력부족을 겪는 학교들에게 비트코인 기부를 통하여, 전력 및 가스 등의 에너지를 공급받을 수 있는 마켓 창출한다. 선불 유심

2015.11.20. , 브릿지경제. ‚삼성도 열공하다? ‘블록체인’이 뭐길래 이렇게 열광하나‛, 2016.9.21. , 서울경제. ‚스타트업 주식 사고파는 장외시장 문 연다‛, 2016.11.7. , 조선비즈.은행 장부 분산시켜 해킹 봉쇄…‘블록체인’ 기술로 年46조 아낀다‛, 2016.6.13. , 11) blocko, 스마트그리드 블록체인 도입 사례, ‘17. 1.’

(pre-paid airtime) 사용과 같은 방식으로 기부자가 지정한 비트코인 주소로 전력 credit 전송 → 학교 스마트미터에 전력 추가한다. 학교, 병원 및 공공기관의 공과금(전기, 수도 등) 결제 시스템으로 확장 가능

<그림 36> 스마트미터의 플랫폼

○ 국외 금융 활용 사례

블록체인 기술을 활용해 해외 송금, 부동산 및 금·다이아몬드 등 실물자산의 거래가 가능하며, 거래 가능한 모든 자산으로 확대되는 추세. 나스닥은 2015년부터 비상장 주식 거래에 블록체인 기술 시범 도입하여 전문투자자용 장외시장에 블록체인 도입 결과 주문-결산- 승인 등에 있어서 최소 3일 걸리던 시간을 10분으로 획기적으로 단축. 미국 핀테크 기업 Ripple은 블록체인 기술을 활용해 중개기관에 의한 수수료 부담을 최소화하는 해외송금 서비스를 제공하고 있으며, Fidor Bank(독일), Westpac/ANZ(호주) 등의 은행들이 본 서비스를 이용 중이거나 테스트 중. 핀테크 기업 Chain은 항공 마일리지 등 로열티 포인트를 가상 화폐화 하여, 블록체인을 통해 연결된 국내외 어디에서나 보유 포인트를 사용할 수 있도록 하는 로열티 프로그램 개발 중

○ 제조·유통 산업 활용 사례

사물인터넷의 기반 기술로 블록체인을 활용하여 제품 제조 및 유통에 관한 모든 과정을 관리할 수 있음. 블록체인상의 기록을 사물인터넷에 적용하면 제조사, 제품을 구성하고 있는 원자재들에 대한 정보 파악이 용이해짐. IBM은 삼성과 함께 블록체인 개념을 사물인터넷(IoT)에 적용하려는 시도로 ADEPT플랫폼*을 제안. * ADEPT플랫폼은 삼성전자의 스마트 세탁기를 IoT에 연결하여 주변사물들과 소통을 통해 소모품 교체를 위한 주문, 자체 점검 시스템을 통한 유지 관리 등을 스스로 해결하는 솔루션

거래에 있어서는 스마트 계약이 가능해지므로 공급사슬 가시성 및 투명성 향상에 기여할 것임

○ 공공 서비스

각국에서 토지·주택·차량관리, 선거 및 투표관리, 의료정보관리 등 다양한 공공서비스 영역에 블록체인기술을 적용하기 위한 검토 작업을 진행 중

블록체인 기술이 확대·적용되면 정부예산의 투명성이 제고되고, 전 국민을 대상으로 정부가 보유하고 있는 정보를 공유하는 것을 지향하는‘공유정부’의 모습으로 각국의 정부형태가 변화될 전망12)

12) 한국지식재산연구원, 곽현, 심층보고서, 블록체인(BlockChain)기술의 산업동향 및 특허동향,

국가 활용현황 및 계획 · 블록체인기반의 QR코드로 결제할 수 있는 서울시의 ‘에스코인(S-Coin)’ 한국 시범사업계획 · 경기도는 블록체인 시범시로 전자 투표를 실시하는 등 다양하게 적용 중 · 영국과학부의 블록체인관련 분석보고서를 토대로 공공서비스 전 영역에 블록체인기술 도입 논의 영국 · 각종 공과금 및 과징금의 징수, 납세, 공공서비스 관련 시민행정, 여권 발급, 토지등기 내역 등 일선 공공업무와 기록들을 통합 관리 미국 · 우편서비스나 의료정보의 기록 및 공유 등에 블록체인기술 활용 검토 · 일본 FSA(Financial Service Agency)에서 정부차원의 블록체인활용 지원 일본 검토 · 부정 투표 방지를 포함하여 블록체인기술을 다양한 사례에 어떻게 적용할 러시아 것인지 모색 우크라이나 · 투표 관리 및 운영에 블록체인기술을 적용하기 위한 논의 · '키없는 전자서명 인프라스트럭처(KSI)’를 공공서비스분야에 도입해 에스토니아 현장업무에 활용하고 있음 · 국가 토지대장 관리를 기존의 단순 전산 데이터베이스 방식에서 블록체인 온두라스 방식으로 전환하여 안전한 주택담보, 대출, 계약, 광물권리에 적용시킬 계획 · 블록체인을 활용한 전자투표 도입논의, 증권거래소청산결제시스템에 호주 블록체인 도입검토

<표 16> 세계 각국의 공공서비스 분야 블록체인 활용 현황 및 계획

○ 문화 콘텐츠 산업 사례

블록체인기반의 콘텐츠 인증서비스를 통해 작품출처의 정확성과 거래의 투명성 확보가 가능해짐

· 블록체인 기술을 통해 소유자들의 이력을 포함한 모든 거래 내역을 기록할 수 있기 때문에 소유권에 대한 추적을 가능하게 한다는 점에서 저작권 측면의 활용 가능성이 높음

· 미술, 음악 등 예술작품의 인증에 블록체인 기술을 이용하면 작품의 출처파악이 쉽고 사용이투명하게 이루어지게 되므로 불법적인 복제와 유통을 미연에 방지가능. 블록아이(BLockai)의 예술작품 저작권보호 서비스는 블록체인기술을 이용해 저작권 데이터를 수집 활용하는 스타트업 회사로 2015년 미국 샌프란시스코에 설립. 예술가들이 자신의 사진에 대한 저작권을 저비용으로 보호받을 수 있도록 블록체인 기술을 이용해 저작권데이터를 수집 및 활용. 기존 고가의 저작권 보호 방식에서 벗어나 합리적인 가격과 안전한 보안방식으로 서비스를 제공하며 블록체인 기반의 새로운 저작권 보호 방식 제시

· 디지털 음원 유통에 블록체인 기술을 활용하면 음원 유통사의 개입 없이 저작료 지급이 이루어짐. 미국의 버클리음대는 저작권료 지급시스템을 블록체인기술로 구축할 예정으로 곡마다 은행계좌 같은 결제 체계를 갖추고 있어 음악을

소비하는데 지불하는 비용은 모두 원작자에게 돌아감

○ 블록체인 표준화의 필요

블록체인의 단점

· 불분명한 개념 : 블록체인에 대한 실제적인 정의를 찾아 합의필요. 블록체인의 정의를 "한 번 쓰면 부가 기록만 추가할 수 있을 뿐 덮어쓸 수 없는 레코드(기록) 저장소"라고 규정하고 분산돼 있고, 완전히 또는 부분적으로 복제할 수 있으나 현재 클라우드나 빅데이터처럼 여러 의미로 사용됨

· 보안과 위험, 접근 관리의 문제점 : 레코드가 변경되면 체인을 확인하는 사람이 이를 즉시 알 수 있으나 "블록체인 의 콘텐츠가 순수한 테스트이므로 오히려 정보가 노출될 수도 있음. 특정인에 대한 정보가 너무 많으면 개인의 보안이 침해되는 문제가 발생. 또한, 정보에 접근할 수 있다면 이와 관련된 사기 사건의 파급이 큼. 개인 정보 및 데이터 보호에 관한 법과 규정을 위반 가능하고 악용 가능함

· 키 관리 문제 : 블록체인은 한 번 쓰면 변경할 수 없는 레코드이다. 그런데 실수를 저지르는 사람들이 있을 것이다. 체인을 악용하려는 사기성 거래도 있을 것이다. 돈이 있는 곳에는 범죄가 있기 마련이다. 체인을 이용해 훨씬 쉽게 이를 파악할 수 있을지 몰라도 이를 방지의 어려움. 체인에 사용하는 키가 도난당했을 때 해결 방안필요

· 접근 권한과 승인 : 승인과 암호화 관리를 위해 운용방법 및 승인을 취소하는 방법, 체인이 기능하는 방식, 사용할 합의(Consensus) 알고리즘, 암호화를 사용여부, 노드의 수 , 체인 내·외부에 스토리지가 여부 등 기준이 필요함

· 엔터프라이즈급 배포 : 블록체인은 미성숙한 기술이 포함되어 있어 해당 부분에 성숙한 인재가 부족하여 상업적 적용에 어려움

· 스토리지 : 컴퓨팅 자원을 많이 요구하는 트랜잭션은 지연 시간(latency) 문제 때문에 여러 데이터베이스에 분산해 복제해야하고 많은 컴퓨팅 자원이나 스토리지가 필요

2.3. 패키징

가. 기술 요소

○ 개요

문서자체의 보존뿐만 아니라 설명정보 등을 포함하고, 영구적으로 보존, 유지, 활용하기 위해 내용정보와 설명정보를 모두 포함하기 위해 필요한 기술

문서를 장기보존하기 위해 기본적인 전략으로 문서보존포맷으로 변환 후 장기보존포맷으로 변환함. 관리할 문서를 문서보존포맷으로 변환을 하고 원문, 문서보존포맷, 기록관리 메타데이터, 전자서명을 넣어 장기보존포맷으로 변환함

<그림 37> 장기보존포맷 패키징 절차 출처 : 공개포맷에 기반한 전자기록 장기보존포맷 재설계 방향 연구. 2016

구조적 변경이나 데이터의 손실 없이 원래의 형태로 보존 및 활용하기 위해 필요한 절차. 기록의 맥락, 내용, 구조를 유지하면서 장기적인 측면에서 접근과 이용을 하기 위해 원문서를 포함하여 여러 가지 정보들이 필요함. 패키징 기술을 통해 모든 데이터를 하나로 묶는 기록관리에 사용함

○ 포맷

데이터의 저장이나 전송 시의 구성 방법 즉, 자료를 파일로 저장할 때 파일의 구조

독점 라이선스에 의해 만들어진 포맷은 장기간 많은 문제점들이 있음. 비용적인 측면이나 장기적으로 불확실한 서비스 제공

상용 포맷의 문제점에 의해 공공기관이나 기업에서는 개방형 표준 포맷의 사용이 보편화 되어가고 있음. 이에 다양한 소프트웨어를 사용하여 읽을 수 있고 다른 보존포맷으로 변환할 필요도 없게 됨

개방형 표준 포맷은 애플리케이션 버전 및 소멸, 운영체제 또는 플랫폼이 차이에 영향을 받지 않음

· 안전성, 표현력, 상호 운용성, 진본성, 편재성

나. 기술 동향

○ 종류

패키징 방법은 tar, zip, bagIt, gzip 등 다양하며 압축여부, 손실여부, 해제용이성 여부 등을 고려하여 결정할 수 있음

Archive Formats

· Archiving only · ar, cpio, shar, tar, LBR, BagIt, WAD

· bzip2, gzip, lzip, LZMA, lzop, xz, SQ, · compression only compress

· 7z, ACE, ARC, ARJ, B1, Cabinet, cfs, 쳇, · archiving and compression DGCA, 읗, egg, kgb, LHA, LZX, MPQ, PEA, RAR, rzip, sit, SQX, UDA, Xar, zoo

<표 17> 아카이브형식

· 단일 아카이브 파일로 유지하는 Unix 유틸리티

· 오늘날 일반적으로 링크 편집기나 링커가 사용하는 정적 라이브러리 파일을 만들고 업데이트하는 데비안 제품군의 .deb 패키지를 생성하는 용도로만 사용함

· 파일의 헤더는 일반적으로 숫자 값은 ASCII류 인코딩되고 모든 값은 ASCII 공백 (0x200)으로 채워짐

<그림 38> ar형식의 파일 헤더

cpio

· Version 7 Unix에서 Programmer’s Workbench 프로젝트에 처음 등장함

· 테이프 파일에 백업 파일 아카이브를 연속적으로 저장하도록 설계 됨

· Unix 계열에서 사용되며 tar와 가은 다른 백업 및 아카이빙 프로그램도 지원함

tar

· tape와 archive의 앞 글자만 따서 만든 소프트웨어로 순차 입출력 장치에 데이터를 쓰도록 개발되었음

· 데이터 세트에는 이름, 타임스탬프, 소유권, 파일 액세스 권한 및 디렉터리 구성과 같은 다양한 파일시스템 매개 변수가 들어 있음

· 파일 헤더레코드에는 파일에 대한 메타 데이터가 들어 있음. 다른 아키텍처에서 이식성을 확보하기 위해 헤더 fphem의 정보는 ASCII로 인코딩 됨

<그림 39> tar 형식의 파일 헤더

BagIt

· 미의회도서관(Library of Congress)에서 개발한 규격

· 페이로드와 태그로 구성되며, 태그는 보관 및 전송을 문서화하기 위한 메타데이터 파일

· XML래핑과 비교할 때 인코딩 할 필요가 없음. 따라서 시간과 공간이 절약됨

· manifast파일을 검사하여 페이로드 파일의 유무, 체크섬의 정확성을 확인함. 이로 인해 손상된 파일을 식별할 수 있는 점이 특징

· 다음과 같이 소수의 필수 요소와 그 외 선택적인 요소로 구성되어 있음

구성요소 설명

BagIt 버전과 태그 사용(반드시 1줄로 작성) bagit.txt 사례 : BagIt-Version : MN Tag-File-Character-Encoding : UTF-8 필수 요소 Payload 관할 정보 포함한 8자리 문자열로 구성 Directory:data/ Payload Manifest : 탑재 파일과 특정 알고리즘에 의해 생성된 체크섬 manifest-.txt 사례 : manifest-md5.txt manifest-sha1.txt 다른 태그파일 및 특정 bag 체크섬을 이용한 Tag manifest : 선택 요소 태그파일의 체크섬 알고리즘 tagmanifest-.txt 사례 : tagmanifest-md5.txt, tagmanifest-sha1.txt

구성요소 설명

Bab Metadata : Bag 및 Payload 파일을 기술하는 메타데이터 요소를 bag-info.txt 포함한 태그파일 Bag은 효율성을 위해 완전성 체크 이전에 파일 목록을 Fetch File : fetch.txt 탑재(payload)부분에 추가 각 라인은 URL LENGTH FILENAME 형식 선택 요소 기타 태그파일 기타 태그파일 포함 가능 텍스트 태그파일 포맷 모든 태그파일은 텍스트 태그파일을 고수해야 함 최소한 2개의 체크섬 알고리즘을 지원 Bag 체크섬 알고리즘 -md5 [RFC1321] -Sha1 [RFC3124]

<표 18> BagIt의 구성 요소

· 필수 구성 요소만을 가진 BagIt의 manifest파일의 내용이나 내용물의 파일 구조는 매우 간단함

<그림 40> BagIt의 단순한 패키지 예시 출처: The BagIt File Packaging Format (V0.97)

<그림 41> 페이로드에 2개 파일을 갖는 bagIt 예시

다. 활용 사례

○ 각국의 아카이브와 도서관들은 오픈소스 기반의 파일 포맷 패키지인 BagIt 포맷을 많이 채택함

기관명 장기보존포맷 구성요소 플랫폼

영국 TNA BagIt 원문파일+보존포맷+메타데이터 Preservica

미국 NARA AAP(자체패키지) 원문파일+보존포맷+메타데이터 ERA 스위스 BagIt 원문파일+보존포맷+메타데이터 Preservica 연방아카이브 원문파일+보존포맷+메타데이터+ PROV Digital 호주 PROV VEO 전자서명(Base64 인코딩) Archive System 국가기록원 NEO 원문파일+보존포맷+메타데이터 Archivematica 캐나다 벤쿠버 시 BagIt 원문파일+보존포맷+메타데이터 Archivematica 아카이브 미의회도서관 BaIt 원문파일+보존포맷+메타데이터 Archivematica

뉴욕현대미술관 BaIt 원문파일+보존포맷+메타데이터 Archivematica

<표 19> 해외 장기보존포맷 현황

○ APP(Archival Assert Package)

미국 국립기록관청(NARA)의 전자기록물 아카이브인 ERA(Electronic Records Archives)의 장기보존 패키지

서비스와 시스템 간 Expert&Import에 사용되는 데이터 모델

<그림 42> APP 개념도. 출처 : ACERL-Aprill.17p. 2011

장기보존 메타데이터(ACE)와 디지털 콘텐츠를 인캡슐레이션한 형태

○ VEO(VERS Encapsulated Object)

비용 효과적인 장기보존과 충분한 메타데이터 획득에 우선순위를 두며, 현재 또는 미래에 어떠한 기록물에 대해서든 내용과 의미를 이해하고 지속적으로 접근할 수 있도록 VEO라는 단일한 장기보존포맷을 개발함

빅토리아 주 전자기록관리전략(VERS)표준에는 전자 기록의 보존을 위한 시스템 요건, VERS 메타데이터 스킴, VERS 표준 전자 기록 포맷, VERS 장기 보존 포맷, 빅토리아 주립 보존 기록관으로의 전자 기록 이관 표준 등이 포함. VERS의 메타데이터 스킴을 준수하고 XML을 사용하여 인캡슐레이션 되는 객체인 VEO는 우리나라는 물론 세게 각국에서 진본 전자 기록의 장기 보존 전략에 응용되고 있음

<그림 43> VEO 상위계층 구조

VEO 메타데이터, 서명된 객체, 한 개 또는 그 이상의 서명 블록, 잠금서명 블록 (Lock Signature Block)으로 구성

파일 패키지(File VEO), 레코드 패키지(Record VEO), 수정된 패키지(Modified VEO) 등 3가지 유형으로 구분

<그림 44> VERS 메타데이터 구성

VEO를 구성하는 159개 메타데이터 항목을 가지며, 37개의 필수 메타데이터 항목은 자동 생성되고 다른 메타데이터 항목으로부터 추출하거나 기본 값으로 설정할 수 있음

○ NEO(NAK Encapsulated Object)

호주 빅토리아 기록관의 장기보존포맷(VEO)을 벤치마킹하여 국가기록원이 도입한 장기보존 패키지

구성요소

· 기록물철 장기보존포맷 : 기록물철 메타데이터, 전자서명

· 기록물건 장기보존포맷 : 기록물건 메타데이터, 컴포넌트 메타데이터, 인코딩된 원문, 문서보존포맷 데이터, 전자서명

장기보존 메타데이터

<그림 45> 기록물철/건에 대한 매핑 구조

· 컴포넌트 메타데이터는 기록물건 장기보존포맷 구성요소로 함께 인캡슐레이션 됨

· 기록물철 장기보존포맷 메타데이터는 장기보존포맷 객체에 대한 전체적인 정보를 기술하는 객체메타데이터, 기록물의 정보를 표현하는 객체콘텐츠, 전자서명에 대한 메타데이터 인증정보, 잠김 인증정보로 구성됨

<그림 46> NEO 메타데이터 구성 * 출처 : 전자기록물 장기보존포맷 기술규격-국가기록원

장기보존포맷의 메타데이터는 장기보존포맷객체 메타데이터, 서명된 객체에 대한 객체 메타데이터와 객체내용인 기록물건, 문서메타데이터, 그리고 인증정보, 잠김 인증정보에 대한 메타데이터로 구성됨

○ BagIt 패키지

미의회도서관(Library of Congress)는 전자기록 이관을 위해 BagIt 규격을 개발하였고 여러 프로젝트에서 이용하였음

오픈소스 아카이빙 시스템인 Archivemetica는 보존 포맷으로 BagIt을 채택

미국 스탠포드 대학의 Stanford Digital Repository에서 인수 포맷으로 이용

Ghent University, New York University, Purdue University, State Library of New South Wales 등 대학 도서관, 박물관, 등에서 전자기록의 인수와 보존 포맷으로 이용하고 있음

2.4. 영상인식

가. 기술요소

○ 정의

카메라와 같은 영상을 입력할 수 있는 장치에 의해 입력받은 디지털 신호를 이용하여 기하학적 특징들을 찾아 관계를 파악하여 시스템의 DB와 비교, 물체를 판단함

얼굴인식, 문자인식, 동작인식 등 인식대상에 따라 각 다른 방법론들을 적용하여 성능개선을 위한 연구가 진행되고 있음

○ 알고리즘

<그림 47> 이미지인식의 기본적인 알고리즘

전처리 : noise, RST invariant 등 성능 개선을 위한 전처리 단계

특징추출 : edge, color 등 특징추출기를 통해 영상의 특징을 추출. 여러 가지 특징 추출기 중 적합한 방법을 통해 추출

학습 : 추출된 특징데이터를 학습모델의 입력으로 넣어 웨이트 값을 갱신, 보통 여러 번 반복하여 웨이트 값을 갱신 함

확률분석/분류 : 분류기를 사용하여 기존의 학습데이터(신경망)의 input layer 현재 영상의 특징 값 벡터를 넣어 유사도에 의한 분류를 수행

나. 기술동향

○ CNN(Convolutional Neural Network)

딥러닝(Deep Learning)구조 중 이미지 분야에서 아주 좋은 성능을 보이고 있음

신경망에 기존의 필터기술을 병합하여 2차원 영상을 잘 습득할 수 있도록 최적화시킨 방 법으로 특징추출기+분류기의 기능을 수행 함

뉴욕대 교수와 Facebook 인공 지능 연구소의 기술이사로 활동중인 Yann LeCun에 의해 LeNet-1구조를 발표하여 CNN의 개념이 최초 탄생하였고, 이를 개선시켜 CNN에서 유명한 LeNet-5를 탄생시킴

<그림 48> LeNet-5구조 * 출처 : LeCun, “Gradient-based learning applied to document recognition”, 1998.

매년 열리는 ‘ImagetNet’ 대회에서 2012년 AlexNet팀이 딥러닝을 사용하여 아주 우수한 결과로 우승을 하면서 딥러닝의 관심이 높아짐

이 후, 대부분의 팀은 딥러닝 구조를 선정하여 대회에 참여하였고. 2015년 ResNet은 인간보다 더 낮은 error rate 3.57%로 우승을 함

딥러닝 발전의 배경으로 알고리즘, 빅데이터, 하드웨어의 발전에 의해 적은 시간으로 많은 연산을 수행할 수 있게 되었고, AlexNet의 8layer의 시작으로 152layer로 뉴럴넷 구조의 깊이가 깊어질수록 좋은 성능을 보이고 있음

<그림 49> ImageNet classification top-5 error (%)

다. 활용 사례

○ Facebook(Deep Face)

딥페이스라는 얼굴 인식 알고리즘을 개발하여 이용자가 올린 이미지의 얼굴만 측면만을 통해 어떤 이용자인지 판별해낼 수 있음

인식 정확도는 97.25%로 인간 눈의 정확도 97.53%와 거의 차이가 없음

사진 자동 태그 서비스를 일부 제공하고 있지만, 인물의 눈 사이 거리, 눈과 코의 거리 등 을 분석하는 수준이라 정확도가 떨어지는 단점이 있지만, 딥페이스 기술을 적용하여 성능을 개선함

최근 패스워드 분실 시 찾기 서비스로 자신이 팔로우한 계정의 인물사진을 보여주고 누구인지 맞추면 패스워드를 변경해주는 서비스를 제공하고 있음

<그림 50> 딥페이스를 이용한 얼굴인식 과정 출처 : facebook

○ Google(Deep Dream)

인공신경망 기반의 컴퓨터 학습 방식인 딥러닝 기술을 시각 이미지에 적용한 기술인 인공지능 화가 ‘딥드림(Deep Dream)은 기존 화가들의 작품의 특징들을 학습하여 새로운 이미지를 생성하는 기술

새로운 이미지가 입력되면 그 요소 하나하나를 잘게 나누어 자신이 기존에 알고 있던 이미지 패턴과 유사한 것과 그렇지 않은 것을 구분하고, 기존에 학습된 이미지 패턴은 고정하여 처음 본 이미지는 자신이 알고 있는 패턴을 적용하여 인식 결과가 나타나도록 이미지를 조작 및 왜곡하여 새로운 이미지를 만드는 방법

인간 고유의 영역이라고 믿었던 작품의 창작 활동에까지 인공지능의 참여가 이루어지고 있으나 어디까지나 기존의 작곡가나 작가의 스타일을 모방하여 약간의 변형을 가하여 재창조해 내는 수준

<그림 51> 딥드림의 예 출처 : Leon A, Gatys et al, “image Style Transfer Using Convolutional Neural Networks’, CVPR, 2016

○ Lunit

루닛(Lunit)은 지난 2013년 설립된 딥러닝 알고리즘 기반의 이미지 인식 기술을 보유한 업체. 엑스레이(X-ray) 영상을 통해 감별진단에 도움을 주는 시스템 개발

10만장 이상의 X선 사진을 학습하면서 정확도를 높였고, 5초 만에 사진을 판독하여 질병 여부를 검출함. 정확도는 95%에 달함

이 기술을 활용하면 X선 판독 속도가 빨라져 병원의 업무 효율성이 높아지고, 나아가 의사가 없는 지역에서도 X선만 있다면 질병 유무를 검진 받을 수 있음

<그림 52> 인공지능을 활용한 결핵 검출의 예 * 출처 : NIH, 루닛

○ NVIDIA

세계 주요 도시에서 포착되고 있는 폐쇄회로(CCTV) 영상 데이터를 수집한 뒤, 익명화된 사람과 자동차, 시설 등을 분석해 공공안전 및 관리 효율성을 높이는 스마트 시티를 조성

실제 전 세계에서 가장 많은 데이터를 생성하고 있는 게 CCTV 동영상. 현재 수억대 CCTV 카메라를 통해 공공재산 및 대중교통, 상업 건물 등이 포착되고 있으며, 오는 2020년 누적 카메라 수는 약 10억 대에 달하는 채널에서 데이터를 수집하게 된다면 의미 있는 결과를 얻을 수 있음

<그림 53> NVIDIA의 스마트 시티 예 출처 : NVIDIA Korea

2.5. 음성인식

가. 기술 요소

○ 정의

자동적 수단에 의하여 음성으로부터 언어적 의미 내용을 식별하는 것. 구체적으로 음성파형을 입력하여 단어나 단어 열을 식별하고 의미를 추출하는 처리 과정이며, 크게 음성 분석, 음소 인식, 단어 인식, 문장 해석, 의미 추출의 5가지로 분류됨

음성인식기술은 컴퓨터가 마이크와 같은 소리 센서를 통해 얻은 음향학적 신호(acoustic speech signal)를 단어나 문장으로 변환시키는 기술

○ 알고리즘

<그림 54> 음성인식기술의 일반적 구조

음성 검출 : 음성신호를 입력받게 되면 실제 화자가 발성한 음성부분만을 검출하여야 하는데 이 음성 검출 부분은 인식성능에 매우 큰 영향을 미치게 됨. 왜냐하면 아무리 좋은 음성 인식 알고리즘을 사용한다 하더라도 음성검출이 제대로 이루어지지 않으면 좋은 인식률을 기대하기 어렵기 때문에 인식률을 높이기 위해서는 음성 인식에 앞서 정확한 음성검출이 요구됨

특징 추출 : 음성은 똑같은 언어라 할지라도 발음하는 사람의 성별, 나이, 발음 시의 상태 등 에 따라 매우 복잡하게 변할 뿐 아니라 단독으로 발음될 때와 단어나 문장 내에서 발음 될 때마다 그 성질이 변하기 때문에 음성의 특징을 잘 표현할 수 있는 특징검출이 중요함. 즉, 특징 추출 과정에서는 불필요하게 중복되는 음성정보를 없애고 동일 음성 신호들 간의 일관성을 높임과 동시에 다른 음성 신호와는 변별력을 높일 수 있는 정보를 추출하여야 됨

음성 인식/매칭 : 특징 추출에서 얻어진 특징벡터는 유사도 측정 및 인식과정을 거치게 됨. 음성의 신호적인 특성을 모델링하여 비교하는 음향모델과(Acoustic Model) 인식어휘에 해당하는 단어나 음절 등의 언어적인 순서 관계를 모델링하는 언어모델(Language Model)이 사용됨. 일반적으로 분류기는 DTW(Dynamic Time Warping), HMM(Hidden Markov Model), NN(Neural Network)를 이용하였으나 최근 딥러닝(Deep Learning)기술이

발달함에 따라 파생된 모델 중 RNN(Recurrent Neural Network)를 대부분 사용함

나. 기술 동향

○ RNN(Recurrent Neural Network)

딥러닝 모델 중 음성인식 분야에서 좋은 성능을 보이는 구조

기존의 FNNs(Feedforward Neural Networks)는 각각의 학습 벡터에 대해 독립적으로 진행을 하였으나 실세계에서는 문장, 영상 및 음성 데이터 등 시간 t-1에서의 입력과 결과가 t에서의 입력과 결과에 영향을 주는 경우가 많이 존재하는 점을 이용하여 만들어진 구조

순차적으로 입력되는 순차데이터(Sequence data)에서 이전의 데이터의 값이 현재의 결과 값에 영향을 미치게 하여 순차 및 연관성에 관련이 있는 데이터를 기반으로 하는 머신러닝에서 좋은 성과를 보이고 있음

<그림 55> RNN의 기본 구조 및 수식

출처 : http://colah.github.io/posts/2015-08-Understanding-LSTMs/

○ LSTM(Long Short Term Memory networks)

RNN은 “장기 의존성”에 대한 문제가 심각함. 즉, 아주 이전의 데이터에 대한 기억을 하지 못함. 그런 문제를 해결하기 위해 ‘LSTM’ 모델이 개발되었음

첫 단계는 셀 상태에서 어떤 정보를 버릴지 결정. 새로운 정보를 셀 상태에 저장할지 결정. 낡은 셀 상태를 어떤 새로운 셀 상태로 갱신을 할 것인가를 결정. 무엇을 출력할지 결정. 등 총 4단계 연산을 수행함

언어 모델을 예로 들면, 입력데이터로 주어를 받게 되면 그 주어가 다음에 다시 나올 때를 대비해, 주어가 단수인지 복수인지와 같이 동사가 어떤 형태로 활용되어야 하는지 예측을 함

<그림 56> LSTM 구조 * 출처 : http://colah.github.io/posts/2015-08-Understanding-LSTMs/

다. 활용 사례

○ AI비서

인공지능 비서들은 음성 인식기술에 딥러닝을 적용하여 사용하면 할수록 데이터가 늘어나 이를 바탕으로 학습하여 음성 인식률이 더 높아지고, 이해할 수 있는 단어와 문장도 대폭 증가하게 됨

사용자가 몸을 움직이거나 휴대폰 앱을 켜지 않아도 음악을 검색하거나 일정을 확인하고 조명을 켜고 끌 수 있음

이 모듈은 향후 스마트 홈 허브로 발전할 것으로 전망이 됨. 건설사와 협약을 맺고 자사의 솔루션을 도입하는 추세

에코 아마존의 음성인식 솔루션인 ＇알렉사’를 에코에 탑재하여 타 사보다 막강한 (Amazon) 경쟁력을 보이고 있음 어시스턴트 사람의 음성을 인식해 질문을 파악하고 음악 재생, 예약, 스케줄 조회, 메시지 (Google) 전송 등을 수행 빅스비 음성뿐 아니라 터치, 카메라 등 다양한 입력 방식을 통해 정보를 받는 것이 (Samsung) 특징 누구 ‘누구’ 인공지능비서의 상용화 과정에서 축척한 노하우로 모바일 (SKT) 네비게이션인 T맵과 결합하여 차량용 AI비서를 연구 중 올레TV, 지니뮤직 등과 연동되는 미디어서비스, 일정관리와 일상생활을 돕는 기가지니 AI 홈비서, 홈IoT 허브, 음성 및 영상통화 기능을 제공하는 커뮤니케이션 (KT) 서비스 등 4가지 분야의 서비스를 제공

<표 20> 국내외 기업의 AI비서 종류

○ 번역기

일반적으로 음성번역이라 함은 STT(Speech to Text)방식으로 음성으로 입력되는 신호를 텍스트로 바꾸는 기능, 최근 인식률의 발달로 음성으로 된 사람의 명령을 입력받아

수행하는 기능도 있음

현재 AI번역 서비스는 음성에 대해서 순차 통역을 함. 음성을 문자로 변환해 인식하고, 다시 텍스트 번역 결과를 음성으로 바꿔주는 방식. 음성 자체를 인식하려면 텍스트가 아닌 음성에 관한 학습 데이터가 필요함. 동시통역 기술은 현재 학계에서나 일부 기업에서 연구는 하고 있지만 상용화하기에는 이른 단계임

<그림 57> Google 번역기 사용 예시

○ 의료 진찰기록

셀바스AI, 연세대학교 세브란스병원은 체크업을 통해 수집한 다양한 음성의료 데이터를 음성인식기술을 활용해 저장하고 문서화시키는 작업을 수행 중. 이 의료녹취 서비스는 외래 진료 시 의사의 진단과 처방, 영상 판독 소견, 수술 시 의사의 진료 내용 등 각종 의료 기록을 음성인식 기술을 활용해 저장함

본부산대병원은 전자차트 음성입력 시스템인 ‘Voice Keyboard’를 국내 최초로 선보임. 이 시스템은 음성인식 기술을 활용해 진료 시 의사의 진단과 처방, 영상 판독 소견 등을 일일이 손으로 입력할 필요 없이 자동으로 문서화를 가능하게 하는 시스템

2.6. 마이크로서비스 아키텍처

가. 기술 요소

○ 배경

2014년 마틴 파울러(Martin Fowler)와 제임스 루이스(James Lewis)가 마이크로서비스 아키텍처로 인한 새로운 패러다임에 대한 글을 블로그에 포스팅하면서 본격적으로 알려짐. 가트너에서는 이 기술이 높은 Business Impact를 가져올 것이라고 얘기하고 있으며, Amazon, Netflix, Google, eBay 등 글로벌 기술 선도 기업들은 이미 이 키워드가 나오기 전부터 마이크로 서비스 아키텍처를 도입함

○ 정의

대규모 소프트웨어 개발에 적용하기 위한 것으로 단독으로 실행 가능하고 독립적으로 배치될 수 있는 작은 단위로 기능을 분해하여 서비스하는 아키텍처. 작은 단위로 기능을 분할할 때 수평 방향의 계층별 절단이 아니라, 수직 방향의 기능별로 절단함. 절단된 독립적은 작은 모듈을 마이크로서비스라 함

서비스 디자인스타일로서 작은 서비스의 결함을 통해 하나의 응용프로그램을 개발하는 방법으로, 각각의 서비스는 독립적인 비즈니스 로직으로 구성되며, 완전 자동화된 개발, 배포환경에 의해 각각 독립적으로 배포될 수 있음. 최소한의 중심적인 관리체계가 있으며, 이 시스템은 각각 다른 프로그래밍 언어, 다른 데이터스토리지 기술로 작성하는 것이 가능

○ 특징

개발 생산성(Development Agility)

· 서비스를 충분히 작은 크기로 나누어 독립적으로 개발하고, 마이크로서비스 간에는 API 규약에 따라 상호 연계. 따라서 개발자는 해당 비즈니스 로직에만 집중해서 개발할 수 있으며, 테스트 시에도 연관 마이크로서비스만 테스트를 수행하면 되므로 개발-테스트 -배포 일정이 대폭 줄어듬

· 일부 기능을 수정할 때 모듈 간 영향도 평가가 어렵고 전체 시스템 단위로 소스코드 통합, 테스트가 이루어지는 모놀리식에 비해 생산성이 뛰어남

배포 유연성(Deployment Flexibility)

· 개별 서비스 단위로 개발, 패키징, 빌드, 테스트, 배포가 가능하므로 각 서비스를 각자의 로드맵에 따라 개발 및 배포를 할 수 있어 더욱 유연하게 스케줄을 가져감

· 작은 변경에도 전체를 다시 테스트/배포하는 모놀리식에 비해 유연함

정교한 확장성(Precision Scalability)

<그림 58> 모노리스(왼쪽)방식과 마이크로서비스(오른쪽)의 접근 형태 * 출처 : Microsoft Azure 홈페이지

○ 장단점

장점

· 단일체 소프트웨어에서는 코드 저장소로써 개발자는 오직 하나의 언어로 개발하여야 하지만, 마이크로서비스는 독립적이고 새로운 프로젝트이며 요구사항에 맞는 어떤 언어든지 사용하여 개발이 가능함

· 각 모듈마다 자신의 데이터베이스를 가지고 있기 때문에 제약 없이 NoSQL 또는 관계형 데이터베이스를 선택할 수 있음

· 시스템 확장이 효과적이고 기술의 다양성, 팀 운영의 자율성이 높아짐

단점

· 큰 규모의 프로젝트에서는 서비스 호출을 추적하거나 서비스들의 모니터링이 어려움

· 하나의 서비스는 다른 서비스와 Rest API를 통해 소통하기 때문에 단일체의 프로세스간 통신에 비해 느림

· 디버깅이 어렵고, 시스템 전체 정합성, 무결성을 관리하기 어려워짐

나. 기술 동향

○ 프레임워크

Inner Architecture와 Out Architecture로 구성되어 있음

· Inner Architecture : 개별 마이크로서비스 구축을 위한 아키텍처

· Outer Architecture : 개별 마이크로서비스가 개발, 배포, 실행되는 운영환경과 관리 기능

Inner Architecture는 최대한 독립적이고 간단하게 구성하여 개발 생산성과 배포 유연성을 높임. 분산 환경과 운영의 복잡성은 Outer Architecture에게 해결하도록 하는 모델을 지향

○ 오픈소스

마이크로서비스를 지원하기 위해 많은 곳에서 솔루션과 오픈소스 S/W를 내놓고 있음. 그 중에서 Netflix에서 개발하고 오픈한 S/W가 가장 활용도가 높음

Netflix의 주요 오픈소스 S/W

· Asgard(애플리케이션 배포 자동화 및 클라우드 관리 툴)

· Hystrix(서비스 가동성/오류 모니터링 및 관리)

· Eureka(서비스 등록 및 검색) · Ribbon(Client-side 로드밸런싱)

○ 서비스 크기 식별

Domain-Driven Design

· 코드의 줄 수, 팀 크기 등을 통해 정량적으로 정의할 수 없는 문제점이 있으므로

에릭 에반스(Eric Evans)가 주장한 DDD사상을 기반으로 서비스 단위 결정이 효율적

<그림 59> Microservice 서비스 식별 프로세스

· 후보 분할 단위는 업무에 대한 유지 보수, 배포 적절성과 CSR 등을 통해 시스템 변경이 잦은 단위로 후보를 결정

· 업무간 Dependency 분석을 하여 시스템 호출 관계도 분석과 CRUD Matrix 분석을 통한 DB 연관도 분석을 통한 DB 연관도 분석을 통해 분리가능 여부를 검토

· 마이크로서비스 단위를 도출할 때 처음 도입 시에는 큰 단위로 도출하고 업무 니즈를 고려하여 점점 작은 크기로 서비스를 도출하는 것이 효율적

· 단위가 결정되면 운영을 통해 원하는 시점에 독립된 배포 지원 여부, 배포까지 Lead Time 등을 측정하여 마이크로서비스 적용에 대한 효과를 판단하여 추후 재조정을 통해 비즈니스에 맞는 서비스 크기로 재조정할 수 있음

다. 활용 사례

○ 현황

마이크로서비스 아키텍처의 적용 사례는 기술의 인지도에 비해 적음. Netflix, Amazon, Gilt와 같은 곳은 시스템 규모와 복잡도의 증가로 인해 개발 생산성 및 품질 저하를 해결하기 위해 수 년 전부터 마이크로서비스 아키텍처를 도입하였으나, 대부분의 기업들에게는 생소한 개념

○ 분야

기술을 중요하시는 기업을 중심으로 도입이 진행되고 있음. 금융 산업에서도 일부 선도 기업들이 도입중이며, 공공분야의 경우 영국 전자정부에서 도입함. 커머스 산업이나 O2O 기업들이 많이 도입하고 있고 부동산, 제조, 엔터테인먼트, 인터넷 서비스 등에서도 조금씩 도입하는 추세

분야 기업

CapitalOne, Citibank, Nasdaq, Wells Fargo, Goldman Sachs, Lending 금융 Club

커머스 Gilt, eBay, Amazon, Walmart, Groupon, Autoscout24, 쿠팡, GS홈쇼핑

인터넷 서비스 Twitter, Soundcloud, Karma, Dropbox, SK플래닛

미디어/엔터테인먼트 Netflix, Disney, Guardian

O2O Uber, Hailo, Instacart, Airbnb

UK Goberment Digital Service(공공), Nike(제조), 기타 Realestate.com.au(부동산)

<표 21> 분야별 마이크로서비스 활용 기업

3. 행정정보 데이터세트 조사 연구 결과

3.1. 선행 연구 분석

가. 행정정보 데이터세트의 개념

○ 행정정보 및 행정정보시스템의 정의

전자정부법 제2조에 의하면, "행정정보"란 행정기관 등이 직무 상 작성하거나 취득하여 관리하고 있는 자료로서 전자적 방식으로 처리되어 부호, 문자, 음성, 음향, 영상 등으로 표현된 것을 말함

행정 효율과 협업 촉진에 관한 규정 제3조에 의하면, "행정정보시스템"이란 행정기관이 행정정보를 생산·수집·가공·저장·검색·제공·송신·수신하고 활용할 수 있도록 하드웨어· 소프트웨어·데이터베이스 등을 통합한 시스템을 말함

○ 데이터세트의 정의

기록학용어사전은 컴퓨터가 처리하거나 분석할 수 있는 형태로 존재하는 관련 정보의 집합체로 정의하고 있으며, SAA(Society of American Archivists)는 컴퓨터가 분석할 수 있도록 형식을 갖춘 연관성 있는 정보들의 집합으로, 데이터파일 혹은 데이터베이스와 유사한 개념으로 정의하고 있음

행정정보시스템 데이터세트 기록관리방안 연구보고서(국가기록원, 2007)에 의하면, "행정정보 데이터세트"를 행정정보시스템에서 생산․관리되는 행정정보 중 전자문서가 첨부되지 않고, 테이블 형식의 구조화 된 데이터의 특징을 가진 집합으로 정의하고 있으며, 데이터세트 구조분석 및 진본성 보장 기록관리 기능모델 연구(국가기록원, 2015)에 의하면,

"행정정보 데이터세트"를 각급 행정기관에서 업무상 사용하고 있는 행정정보시스템에서 생산되는 관련성 있는 정보의 집합체로 정의하고 있음

행정정보시스템에 전자문서가 첨부되는 경우는 매우 흔한 경우로 행정정보 데이터세트를 테이블 형식의 구조화된 데이터 집합이라는 협소한 정의나, 행정정보의 생산과 관련된 정보의 집합체라는 제한된 정의보다는 「전자정부법」제2조에 의한, "행정정보"의 집합체로 단순하게 정의할 필요가 있으며, 데이터베이스에 저장된 정형 데이터만이 아니라 첨부 자료로서 함께 관리되는 다양한 포맷의 전자 파일까지 포함하게 됨

나. 행정정보 데이터세트의 유형

○ 행정정보시스템의 유형 분류

행정정보시스템 데이터세트 기록관리방안 연구보고서(국가기록원, 2007)에서 기록관리 측면에서 행정정보시스템의 유형을 다음과 같이 구분하고 있음

· 데이터베이스 가치에 따라, 인덱스/검색도구, RMS, 통계데이터베이스, 지원시스템으로 구분

· 조직의 기능에 따라 조직레벨 시스템, 지식레벨 시스템, 관리레벨 시스템, 전략레벨 시스템으로 구분

· 데이터의 처리에 따라 EDMS 유형, OLTP 유형으로 구분

· 데이터의 범위에 따라 공동자원 유형, 내부자원 유형으로 구분

· 데이터의 성격에 따라 데이터 처리 시스템, 데이터 집계 시스템, 데이터 관리 시스템, 데이터 검색/서비스 시스템으로 구분

○ 행정정보 데이터세트의 유형 분류

행정정보시스템 데이터세트 기록관리방안 연구보고서(국가기록원, 2007)에서 행정정보의 유형을 첨부 문서의 유무에 따라 구조화된 테이블 형태의 유형과 전자문서를 포함하는 유형으로 구분하고 있으며, 데이터세트의 유형을 데이터 성격에 따라 동적 데이터세트와 정적 데이터세트로 구분하고 있음

데이터세트 구조분석 및 진본성 보장 기록관리 기능모델 연구에서는, 행정정보 데이터세트 유형을 데이터 특성, 처리방식, 업데이트 형태에 따라 구분하고 있음

· 데이터 특성에 따라 Structured, Semi-Structured, Unstructured 데이터로 구분

· 데이터 처리 방식에 따라 OLTP, OLAP, Big Data Analysis로 구분

· 데이터 업데이트 형태에 따라 Read-only, Append-only, Continuous-update로 구분

행정정보 데이터세트 기록의 선별 기준 및 절차 연구(조은희, 2009)는 아카이빙된 데이터 세트의 서비스 특성을 고려하여, 통계 및 설문 등을 수행한 원자료(raw data), 각종 카드 및 대장류, 전자문서와 업무트랜잭션 데이터, 관측데이터 유형으로 구분하고 있음

· 통계 및 설문의 원자료 유형은 관계형 데이터베이스에 데이터를 보존하여 분석·활용 서비스 가능함

· 카드 및 대장류 유형은 관계형 데이터베이스에 데이터를 보존하되 카드 및 대장 서식의

재현과 증명서 발급 서비스 가능함

· 전자문서와 업무트랜잭션 데이터 유형은 사안별로 진행과정을 추적할 수 있도록 전자문서와 업무트랜잭션 데이터를 기록화 함

· 관측데이터 유형은 데이터의 구조와 연관관계를 이해하고 재현할 로직과 어플리케이션을 함께 기록화 하여 활용함

○ 행정정보시스템 단위의 구분 방법

기관내부에서 행정정보시스템을 구분하는 단위기준이 명확하지 않거나 복합적 응용프로그램을 통칭하는 등 시스템을 구분하는 기준이 모호함

행정정보시스템 데이터세트 기록관리방안 연구보고서(국가기록원, 2007)는 행정정보시스템 단위를 응용프로그램 기준과 데이터 리파지토리 기준, 기관 외부와 네트워크로 연계된 시스템인지 구분하여 접근하는 방법을 제안하고 있음

최근 행정정보시스템이 클라우드 서비스 환경으로 전환되는 상황에서 서비스 관점의 시스템 구분과 데이터 서비스 또는 데이터 리파지토리 관점에서 데이터세트를 정의할 필요가 있음

○ 데이터세트 건 단위 식별

행정정보 데이터세트 기록의 선별 기준 및 절차 연구에서는, 건 단위 식별 기준을 첫째, 기록관리 생애 주기 및 관리단계에 따라 통제 및 관리가 가능한 단위이어야 하며, 둘째, 기술·분류·처분 등을 수행할 때 계층별로 논리적 연관성을 가져서 하위 계층에서 상위계층의 속성을 상속받거나 물리적 매체관리와의 관련성을 가지는 등 설계 및 수행에 현실적인 편의성을 제공할 수 있어야 하며, 셋째, 업무적·논리적·물리적 연관성을 가진 데이터세트가 범주화될 수 있어야 함

네덜란드 Dgital Preservation Testbed 프로젝트에서는 기록으로서의 데이터베이스를 식별하는 것에 대한 개념을 다음과 같이 나누어 제시하고 있음

· 시스템 전체가 하나의 전자기록

· 데이터베이스가 하나의 전자기록

· 하나의 데이터베이스 테이블에 저장된 하나의 열이 전자기록

· 응용프로그램에 의해 스크린에 표현된 데이터베이스 내의 정보가 전자기록

데이터베이스 단위로 기록건을 식별하는 경우 기록통제의 기본 단위가 커서 세밀한 통제가 어려울 수 있으며, 테이블 단위는 작은 정보 단위이기 때문에 여러 테이블에 걸쳐 이루어지는 업무트랜잭션을 충분히 반영하지 못할 가능성이 있기 때문에, 기록의 맥락정보와 참조정보를 잘 구성해주어 함

다. 기록관리 방안

○ 데이터세트 기록화를 위한 선별 기준 및 절차

데이터세트 구조분석 및 진본성 보장 기록관리 기능모델 연구에서는, 행정정보시스템 중 정부부처의 주요한 정책과 활동에 관한 시스템, 정부의 의사결정 프로세스 및 구조에 관한 시스템, 국민생활과 관련된 행정정보시스템, 물리적 환경과 관련된 행정정보시스템을 대상으로 하여, 평가나 가치 있는 기록을 선정하는 기준을 수립할 것을 제시하고 있음

행정정보 데이터세트 기록의 선별 기준 및 절차 연구에서는, 행정정보시스템 기록화를 위한 데이터세트 선별 절차를 (1)기록화 대상 데이터세트 결정, (2) 데이터세트 기록건 식별 단계, (3)데이터세트 기록의 관리계층 구성 단계를 구분하고 있음

○ 데이터세트 기록관리 계층구조

행정정보시스템 데이터세트 기록관리방안 연구보고서(국가기록원, 2007)에서는 데이터세트 계층을 시리즈-데이터세트-테이블로 구분하고, 시리즈 계층에는 각 기관이 소유한 행정정보시스템을 두고, 이관연도별 서브시리즈를 구성하는 방법을 제시하고 있음

데이터세트 구조분석 및 진본성 보장 기록관리 기능모델 연구(국가기록원, 2015)에서는, 데이터세트 계층을 행정정보시스템-단위기능-시리즈-데이터베이스-테이블-행의 기록관리 계층구조를 제안하고 있으며, 균일한 데이터세트를 대상으로 하는 최소 기능단위 중 Read를 제외한 Create, Update, Delete 연산이 이루어지는 단위로 정의하고 있음

라. 이관 데이터 보정 및 품질 개선 방법

○ 행정정보 데이터세트 기록 이관 시 데이터 보정 및 품질개선 방법 연구(임진희, 2010)에서는, 데이터세트의 이관이 데이터웨어하우스의 ETT(Extraction, Transformation, Transportation) 과정과 유사성을 가진다는 점에 착안하여, 데이터웨어하우스 구축을 위해 데이터를 추출하여 변형 후 전송하는 절차와 방법을 참조하여 이관하는 행정정보 데이터세트 기록의 보정 및 품질 개선 방법을 제시하고 있음

○ 구체적으로 데이터세트 기록 이관 시, 데이터세트 수량과 유효 값 확인, 일관된 코드 값의 부여를 위한 코드변환, 복합정보의 컴포넌트화, 날짜데이터의 정밀도 결정, 데이터 표준화, 코드 값의 설명정보, 메타데이터 확보 등 7가지를 제시하고 각각의 처리방법을 제안하고 있음

마. 해외 데이터세트 관리 사례

○ 영국 TNA(The National Archives)

정부기관의 데이터세트를 인수하여 NDAD(National Digital Archive of Dataset)에서 보존하고 공개하는 프로젝트를 1997년부터 2010년 추진. NDAD는 데이터 포맷을 CSV(Comma Separated Values) 포맷으로 변환하여 NDAD 웹사이트에서 제공

<그림 60> 영국 National Digital Archive of Dataset 서비스

2010년부터 데이터세트 아카이빙은 UK Government Web Archive로 통합되어 보존 및 서비스하고 있음

○ 미국 Access to Archival Database

미국 NARA(National Archives and Records Administration)에서 구축하여 운영하고 있는 데이터베이스) 아카이브로서 연방정부의 업무 수행 중에 생산된 데이터세트를 보존하고 서비스하기 위해 구축. 30개 이상의 미연방정부기관과 기증받은 컬렉션, 약 8천 5백만 건에 대한 데이터를 제공하며, 이에 대한 카테고리별, 시기별, 주제별(145개) 검색과 전문 및 필드 검색 제공

<그림 61> 미국 Access to Archival Database 서비스

○ 호주

호주 National Archives of Australia는 Digitaly Continuity 2020 계획 아래 정부 조직에서 필요한 정보 생산부터 처분과 활용까지 체계적으로 관리하기 위한 8대 원칙을 세워 추진하고 있음

각 정부 조직에서 생산한 데이터세트를 생산 조직에서 관리하고 호주 정부의 정보공개 정책에 따라 data.gov.au, Nationa.Map, FIND를 통해 공개할 것을 권장하며 지침을 제공하고 있음. 대표적인 데이터세트로서 호주 통계청, 공간 데이터, 기후 데이터 등이 있음

○ 스위스

스위스 연방 기록원은 관계형 데이터베이스를 보존하기 위하여 SIARD(Software Independent Archiving of Relational Database) 규격을 개발하여 데이터세트를 인수하여 보존하고 있음. SIARD 규격은 스위스 전자정부 표준 포맷으로서 공급사의 관계형 데이터베이스 관리 도구에 의존하지 않는 중립적이며 장기 보존에 적합하도록 개발된 SIARD는 XML 기반으로 데이터를 추출하여 스위스 연방 기록원으로 이관함

연방 기록원에서 보존 중인 데이터세트는 1960년부터 2014년 사이 통계, 국방, 법무, 및 치안 관련 기관으로부터 입수한 병무기록, 급여기록 등의 41개 데이터베이스, 96개 SIARD 파일, 120GB(2014년 기준)

연방 기록원은 규격과 함께 관계형 데이터베이스로부터 SIARD 규격으로 파일을 생성하는 SIARD Suite를 공개하여 보급하고 있음

3.2. 행정정보 데이터세트 조사 연구 배경

가. 행정정보 데이터세트 기록관리의 문제

○ 행정정보데이터세트 기록관리 방안(국가기록원, 2016)는 행정정보 데이터세트를 기록으로 서 포착하여 관리함에 있어 당면한 문제점을 5가지 지적하였음

시스템 유형 및 데이터 특성 등이 다양하여 획일적 기준 적용 곤란

IT기술 및 환경 변화에 따른 시스템 구조 및 서비스 내용의 잦은 변경

데이터의 장기간 운용, 반복적인 수정과 변경

다양하고 방대한 데이터세트 이관을 위한 기술·비용 문제

시스템 및 데이터의 전문적 분석 필요

○ 위의 문제점은 데이터세트의 선별 및 보존 포맷과 같은 기술적 요소 중심의 선행 연구와 현행 전자문서 중심 기록관리체계로 해결할 수 없는 현실적인 장애물로 볼 수 있음. 정보기술적 해결만이 아니라 제도 및 조직적인 여건 마련을 포함하는 총체적 관점에서 행정정보데이터세트 기록관리 방안(국가기록원, 2016)은 다음의 관리 방향을 제시하였음

다양한 유형의 모든 시스템 적용 가능한 범용관리모델 마련

· 시스템 개발언어, 구조, 데이터베이스, 데이터 모델, 기능 등 다양성을 고려하여 적용 가능한 모델 마련

업무환경 및 시스템 변화에 유연한 관리체계

· 시스템 운영 환경의 변화에 지속적 대처가 가능하며

· 시스템과 데이터 변경사항을 현행화하며 통제와 관리 가능한 체계

생산기관 자체관리체계 및 데이트세트관리 프로세스 간소화

· 생산기관에서 자체 관리 가능한 체계

· 기록관리 3단계(생산 -> 기록관 -> 영구기록물관리기관) 간소화

전문조직 구성 및 운영기관과 국가기록원의 협업관리체계

· 데이터세트 보존, 평가, 이관 등 생산기관과 기록원 간 전문가 협업에 의한 업무 체계

· 시스템 운영자, 기록관리전문요원, 정보기술 전문가, 보존전문가 등이 참여하는 인력 조직

3.3. 행정정보 데이터세트 조사 계획

가. 조사 목표

○ 행정정보 시스템의 다양성을 유형화하여 차이점, 공통점 및 시사점을 도출하여 포괄적 관리체계 수립 기초 자료 마련

○ 데이터세트 기록관리의 기준 개발을 위한 기초 과정

아래 데이터세트 기준표 개발 단계에 따라 현장조사 및 시스템 분석을 진행

<그림 62> 현장조사기반 데이터세트 기준표 개발 단계

○ 데이터의 생산 및 운영 현황을 파악하고 결과를 분석함

시스템 목적 및 시스템 사용자, 서비스 내용 등 시스템의 전반적인 현황을 파악하여 정확한 분석이 가능하도록 이해

시스템 기능구조를 파악하고 기능적 연계시스템을 분석하여 사용자 입장에서 기능관점으로 데이터 관리단위를 식별함

물리적 데이터베이스 및 논리적 데이터 구조를 파악·분석하여 데이터관점으로 관리단위를 식별함

○ 데이터세트 식별 및 기록관리의 이슈사항 도출

기능 분석 및 데이터 분석을 통해 해당 시스템 내 기록화 대상 관리단위를 식별, 데이터 세트를 정의

데이터세트 기록관리의 공통 이슈 도출 및 개별 이슈 도출

나. 조사 대상 시스템 선정

○ 행정정보시스템의 개수와 종류가 매우 많기 때문에(범정부EA 포털 집계, 2017년 기준 23,856개 시스템) 사용 기관 사이의 관계에 따라 시스템 유형을 분류함

○ 조사 대상 각 유형별로 기관 협조와 기록관리 이슈를 고려하여 1-2개 시스템 선정. 단, 중앙 집중형은 연계 기관과 데이터 이용 형태가 더 복잡한 중앙-지방 연계형 및 중앙-지방 연계형과 통합하여 선정하였음

시스템 유형 설명 조사 시스템

· KAIST · 업무 또는 서비스를 위해 단독 시스템으로 구성되어 전자연구노트시 단일기관 스템 있으며, 단일기관에서 운영, 관리 단일시스템 · 산림청 · 타기관 및 타시스템과 데이터 연계가 없는 단순 구조 산림자원통합관 리시스템 · 특허청 · 한 개 기관에서 업무별 다수 시스템이 통합DB를 통해 특허넷시스템 단일기관 상호간 데이터를 공유ㆍ참조ㆍ생성 · 화학물진안전원 연계시스템 · 예) 특허청 특허넷시스템 화학물질종합정 보시스템 · 동일 부처 내 다수의 기관이 중앙시스템에 접속하여 데이터를 생성ㆍ처리, 중앙시스템에 다수 기관에서 중앙집중형 생성된 데이터는 업무처리를 위해 각 기관에서 참조 · 예) 미래부 주파수분석시스템

· 1개 기관 시스템에서 생산된 데이터를 다수 기관에서 다수기관 연계 또는 참조하여 업무 처리하는 유형 · 권익위 데이터 연계형 · 각 부처간 업무처리 효율성 등을 위해 국민신문고 · 예) 권익위 국민신문고, 식약청 식의약품정보

시스템 유형 설명 조사 시스템

· 시도, 시군구별 데이터를 생성하며, 지자체간 중계서버를 통해 상호 데이터를 공유 및 저장 · 중앙 중계서버를 통해 시도, 시군구에서 생성된 중앙-지방 · 국토교통부 데이터를 통계성 또는 일부 데이터 활용 등을 위하여 연계형 국토정보시스템 중앙부처와 데이터 연계 · 예) 국토교통부 국토정보시스템, 시도행정정보시스템, 새올행정정보시스템,

<표 22> 행정정보시스템 유형 분류 다. 조사 내용 계획

○ 시스템이 제공하는 서비스의 유형

이용기관 유형에 따라 단일기관형, 개별기관형, 기관 공유형으로 구분함

· 단일기관형은 하나의 이용기관이 단일 데이터서비스를 이용하는 경우

· 개별기관형은 다수의 이용기관이 개별 데이터서비스를 이용하는 경우

· 기관공유형은 다수의 이용기관이 공통 데이터서비스를 이용하는 경우

통합유형에 따라 단독형(Standalone), 통합형(Integrated), 집합형(Aggregated), 분산형 (Distributed)으로 구분함

· 단독형은 단독적인 데이터구조로 서비스되는 경우

· 통합형은 하나의 통합된 데이터구조로 서비스되는 경우(예. 국민신문고)

· 집합형은 통합되지 않은 데이터구조롤 서비스되는 경우(예. 데이터웨어하우스, 데이터개방)

· 분산형은 지역 또는 영역별로 운영, 서비스되는 경우

운용유형에 따라 주기적, 한시적, 상시적 서비스로 구분

· 주기적은 주기적으로 (새로운) 데이터서비스를 운용하는 경우(예. 연말정산 등)

· 한시적은 법령 등에 의해 한시적으로 데이터서비스를 운용하는 경우

· 상시적은 일반적인 데이터서비스

행정정보시스템 데이터세트 기록관리방안 연구보고서 등 기존 연구의 유형 구분 또한 고려함

· 기능수준에 따라 조직수준, 지식수준, 관리수준, 전략수준으로 구분

· 서비스의 성격에 따라 데이터처리, 데이터집계, 데이터관리, 데이터검색 서비스로 구분 · 처리 및 분석 유형에 따라 처리형(OLTP), 분석형(OLAP)로 구분

○ 데이터의 유형 구분

업무성격에 따라 공통데이터, 운영데이터 업무데이터로 구분함

· 공통데이터는 이용기관별 데이터베이스에 공통적으로 활용하기 위해 정의한 데이터

· 운영데이터는 데이터서비스 운영을 위해 정의한 데이터 · 업무데이터는 이용기관별 데이터서비스를 위해 정의한 데이터

데이터의 운용유형에 따라 정보변경형, 처리절차형, 조회참조형으로 구분함

· 정보변경형은 정보관리가 주 관심인 경우(예. 사업자등록원부관리)

· 처리절차형은 처리절차가 주 관심인 경우(예. 사업자등록변경관리)

· 조회참조형은 서비스 내부에서 데이터요소의 생애주기가 관리되지 않는 경우(예. 우편번호)

데이터의 참조유형에 따라 기준데이터, 처리데이터, 참조데이터로 구분함

· 기준데이터는 서비스 내부의 다른 데이터요소를 (외부키로) 참조하지 않는 데이터로 서비스 내부에서 데이터의 생애주기가 관리되고, 내부의 다른 데이터나 외부 서비스에서 참조함 · 처리데이터는 기준데이터의 변경처리 등 처리절차가 주 관심인 경우로 거래데이터가 외부시스템의 생성 데이터가 된다면, 해당 외부시스템 관점에서는 기준데이터가 될 수 있음

· 참조데이터는 내부에서 데이터요소의 생애주기가 관리되지 않고 주로 참조용으로 운용하는 데이터

라. 조사 추진 경과

○ 현장조사 수행 절차

<그림 63> 현장조사 수행 단계

○ 현장조사 준비

조사 대상 시스템 선정

· `16년 조사·분류한 유형중 기관 협의를 통해 6개 시스템을 선정하여 현장조사를 진행

현장조사 계획 수립

· 현장 조사의 효율성을 높이기 위한 준비과정으로 대상 시스템을 최대한 이해하고 질문 및 현장 확인 사항을 추출하여 숙지

· 각 시스템에 대한 기술 자료를 입수하고 각 시스템별 분석 포인트를 도출하는 활동을 함

조사표 준비

· 방문조사 전 사전 자료 분석을 통해 조사표를 사전에 작성

○ 기관별 요청 자료 및 조사팀 조직

각 시스템 관리 기관에 관련 자료 준비와 조사 내용 및 수행 조직에 관하여 조사 대상 기관과 사전 협의함

시스템 관리 기관 현장 조사팀 분야 문서 인력 인력

HW 및 SW 구성도 프로그램 목록 및 명세서 (기능 명세서) 업무 아키 프로그램 관계도 담당자 아키텍처 소프트웨어 아키텍처 정의서 〮 전문가 시스템 사용설명서 시스템 / 운영설명서 운영자/ 컨설 내외부 연계 현황 개발자/ 턴트 (온나라/전자문서 포함) 유지보수담당 운영 통계 (이용자수, 데이터량 등) 고도화 및 개선 계획

논리 ERD 물리 ERD DB 테이블 목록 및 명세서 시스템 데이터 흐름도 데이터 데이터 개발자/ 코드 명세서 전문가 유지보수담당 백업 정책 운영 현황 (데이터량 등) 데이터 개방 현황

기관 기능분류체계 기록 기록 기록관리 단위과제 목록 연구사 전문가

<표 23> 시스템 관련 요청 자료 및 수행 인력

○ 현장조사

기관 방문 및 인터뷰

· 사전에 작성한 조사표를 기반으로 대상 시스템의 담당자 인터뷰를 진행하고, 시스템 시연 및 데이터 생산 및 운영 현황, 해당 기관의 기록관리 현황을 파악

· 기관 업무 담당자를 통해 업무 프로세스상 핵심 이슈를 확인하고 기관의 비전/목표 달성을 위한 향후 방향 및 주요 이슈를 확인

· 시스템 운영 및 관리 담당자를 통해 시스템 정보 및 기능 현황을 파악하고 데이터

구조 및 흐름현황을 파악

<그림 64> 인터뷰 주요 내용

시스템 및 데이터 조사

· 프로그램 목록 및 기능 명세서, 각종 매뉴얼 등를 통해 기능 구조를 조사

· 물리적 데이터베이스관리시스템(DBMS) 및 사용자, 데이터량 등 개략적인 데이터베이스 현황을 파악 · ERD(Entity Relationship Diagram) 및 테이블 명세서를 통해 데이터의 구조를 조사하 였으나, ERD가 제공 안 되는 경우에는 테이블 목록 및 명세서 등 다른 산출물, 또는 시스템 운영 및 관리 담당자 인터뷰를 통해 개괄적인 데이터 구조를 조사함

현장 조사표 작성

· 2~3차례에 걸쳐 현장조사를 진행한 내용을 조사표 양식에 맞게 작성하여 분석 및 데이터세트 기준표 작성의 기초자료를 준비

· 1차 조사시에는 시스템 개요 및 연계, 변경 이력과 데이터의 현황을 조사하며, 2차 조사시에는 구체적인 데이터 유형 및 목록 조사를 통해 데이터세트 기준표 설계의 기초자료를 만드는 것에 중점

· 물리적 데이터베이스 분석은 2차 현장 조사시 함께 진행하거나 해당 기관 상황에 맞춰 별도로 진행

조사단계 분류 조사항목

기관 및 담당부서 기관명, 부서명, 담당자명, 전화번호, 전자메일, 비고

시스템 명칭, 주요 사용자, 시스템 목적 서비스 내용, 관련 법령정보 시스템 정보 연계 시스템, 주요 변경이력 1차 조사 주요 H/W 정보, 주요 S/W 정보,DBMS 정보 시스템 URL, 구축연도, 비고 데이터베이스 개수, 계정 개수 용량, 테이블 개수 데이터베이스 마스터데이터 목록, 주요 마스터테이블 row수 타 시스템 정보 연계 (입수출 정보 및 방법)

업무데이터베이스 목록 데이터베이스 구분명, 주요 데이터 정보

사용자 유형별 역할 및 DB 구분명, 사용자 유형, 역할 및 권한 권한

이용기관 유형(단일기관형,개별기관형,기관공유형) 이용기관 및 통합 유형 데이터통합 유형(단독형,통합형,집합형,분산형) 서비스운용 유형(상시적,주기적,한시적)

주요 기준데이터 목록 데이터 구분명, 설명

주요 처리데이터 목록 데이터 구분명, 설명

주요 참조데이터 목록 데이터 구분명, 설명

공통 및 운영데이터 데이터 구분명, 설명 목록 2차 조사 주요 데이터의 등록 및 데이터 구분명, 등록기준, 확정기준 확정 기준 주요 데이터의 생성 데이터 구분명, 생성 방식 방식 연계에 의해 생성되는 데이터 구분명, 연계서비스 설명 데이터 목록

조회 연계 서비스 목록 데이터 구분명, 연계서비스 설명

운용 연계 서비스 목록 데이터 구분명, 연계서비스 설명

개인정보 목록 구분명, 관련 데이터 및 이용 설명

개인정보관리 정책 및 개인정보 정책 유무, 보존기간, 보존기간 근거 보존정책 폐기/이관, 폐기 근거

<표 24> 현장 조사표 조사 항목

○ 현장 조사 결과 분석

기관 업무 분석

· 기초조사 및 인터뷰를 통해 도출된 기관의 업무 개괄에 대해 조사 및 이해

시스템 서비스/기능 분석 (서비스/기능 관점)

· 해당 시스템의 업무의 프로세스가 복잡할 시 주요 업무에 대한 프로세스를 도식화하여 분석

· 프로그램 명세서, 사용매뉴얼을 통해 기능 구조를 분석, 관련 산출물이 없는 경우 서비스 화면상 메뉴 구조를 통해서도 기능 구조를 파악함

· 기능적 연계시스템을 파악하고 해당 연계 시스템이 기능적으로 어떠한 위상을 가지고 있는지 분석

· 파악한 기능 구조를 통해 기능 관점에서 관리단위를 판별

데이터 구조 분석 (데이터베이스 관점)

· 데이터베이스 스키마를 분석하여 엔터티의 최소단위가 테이블인지, 더 작은 단위인지 분석

· 물리적 데이터형식을 분석하여 추후 해석이 어려운 데이터 형식이 존재하는지, 또는 비정형 데이터를 저장할 수 있는 데이터 형식이 존재하는 지 분석하여 해당 데이터의 명세를 기록 · 물리적 테이블 관계 분석을 통해 데이터 그룹을 도출하고, 데이터 그룹을 통해 관리단위를 판별

· 데이터베이스내 또는 별도의 파일시스템내 저장된 비정형 데이터의 보유 현황을 분석

○ 현장 조사 수행중 문제점

사전 자료 입수 및 분석 단계

· 해당 기관의 산출물 현행화에 대한 부담과 외부 유출 제한으로 인해 사전 자료 입수 불가한 경우가 다소 발생

· 사전 협조 신뢰 관계구축이 필요

기관 방문 및 인터뷰 단계

· 사전 자료 부족으로 인해 해당 기관의 업무와 시스템에 대한 이해가 부족한 상태에서 인터뷰를 진행할 시 조사 결과물의 질이 하락

· 단계별 방문 조사의 필요성이 있으며, 방문 시 업무와 시스템에 대한 사전 이해가 우선 필요

기능 분석 및 데이터 분석

· 기관별 상이한 산출물 양식 및 항목으로 인해 모든 기관에 대한 일관적인 시스템 분석이 어려움

· 기능명세서, ERD, 테이블 명세서 등 시스템 구축 및 운영 산출물은 외부 유출 제한 등 기관 사유로 인해 입수하기 어려워 상세한 분석이 어려움

· 필요 시 기관에서 직접 작성할 수 있는 분석서나 현황 통계 등 표준 검출 방안 제공

3.4. 행정정보시스템 조사 결과

가. 산림자원통합관리시스템

○ 조사 개요

조사 대상 시스템 : 산업자원통합관리시스템

관리기관 : 산림청

기관 시스템 담당 : 산림청 정보통계담당관

조사 추진 경과

· 1차 조사 (2017.6.5.) - 시스템 개요 조사 및 1차 조사표 작성

· 2차 조사 (2017.6.15.) - 기능 및 데이터베이스 조사 및 2차 조사표 작성

· 3차 조사 (2017.6.21.) - 시스템 기능 추가 조사, 기록관리 조사

시스템 선정 배경

· 다수기관 데이터연계형( 한 기관에서 생산한 데이터를 다수 기관에서 연계 또는 참조하는 형태)의 대표 시스템으로 선정하였으나 시스템 분석 결과 다수 기관 연계형이 아니며 산림청 내 산림경영정보시스템, 지리정보시스템과 연계되는 단일기관 단일시스템으로 판별되었음

시스템 구축 배경

· IT기반 효율적인 산림행정 및 현장업무 지원을 통한 기후변화에 대응한 산림자원의 가치 제고 및 산림사업의 경쟁력 강화

· 핵심 탄소흡수원인 산림의 역할과 중요성에 부합하는 국가산림 업무에 대한 종합적 관리

· 산림자원업무(종묘→조림→숲가꾸기→벌채)에 대하여 기존에 기관별로 가지고 있는 상이한 업무 프로세스와 양식, 현장 데이터 중복 입력, 산출식 수동 계산 등을 표준화 및 자동화

시스템 구축 연혁

· 2012 년에 시스템을 구축, 운영을 시작하였으며 2017년 추가 기능 구현 및 기존 기능 고도화와 DBMS 변경을 진행중임 · 2012년 시스템 구축 이전의 데이터는 인쇄물로 보관하고 있음

년도 구축 내용

2012 시스템 구축 및 운영 개시

2014 산림공간정보 연계 2015 모바일 현장업부지원시스템 연계 산림공간정보 연계고도화 (산림자원관리업무의 비표준사업 관리 기능 구현, 2017 국유림경영계획 평가 연계기능 고도화, 공간정보를 조회 및 검토 기능 구현, 온-나라 결재 연계 기능 개선, DBMS Oracle->Tibero 변경 등) 진행 중

<표 25> 산림자원통합관리시스템 년도별 구축 내용

관련 법률

· 산림자원 조성 및 관리와 탄소 흡수원 유지 및 증진을 목적으로 제정된 법률을 근거로 시스템이 구축되었음

번호 법령

산림자원의 조성 및 관리에 관한 법률 1 (2005.8.4 제정, 2016.12.2 개정, 2017.6.3 시행) 탄소 흡수원 유지 및 증진에 관한 법률 2 (2012.2.22 제정, 2016.5.29 개정, 2017.7.30 시행)

<표 26> 산림자원통합관리시스템 관련 법률

○ 시스템 현황

시스템 목적

· 국유림 산림 장원에 대한 사업관리를 목적으로 구축되었으며, 구축 전 관리 내용을 엑셀로 작성하는 환경을 전산화함

시스템 사용자

· 산림청내 산림자원과와 목재산업과 직원, 산림청 산하 5개 지방청 및 소속 국유림관리소 담당자, 약 931명이 사용 중

<그림 65> 산림청 조직

산림청 정보화 현황

· 산림행정서비스 제공 시스템 19개 중 1개, 산림공간정보서비스, 일반행정서비스, 모바일서비스 내 시스템과 연계

<그림 66> 산림청 정보시스템 구성 현황 (2016) 출처 : 국가산림통합정보체계 구축(2차) 제안요청서, 산림청, 2016

<그림 67> 국가산림통합정보체계 목표시스템 (2017) 출처 : 국가산림통합정보체계 구축(3차) 제안요청서, 산림청, 2017

시스템 서비스 내용 및 대기능 분석

· 산림자원사업관리시스템의 업무영역은 ①조림, ②숲가꾸기, ③벌채, ④매각의 4개 영역으로 구성되어 있음

· ①조림 영역의 내용은 나무 심기, 결제림 조성, 경관림 조성업무이며, ②‘숲가꾸기’영역은 가지치기, 어린나무가꾸기, 솎아베기, 쳔연림가꾸기 등 인공조림지나 천연림이 건강하고 우량하게 자랄 수 있도록 숲을 가꾸고 키우는 사업을 관리하는 업무임

· ③벌채 영역은 조림을 통해 얻어진 목재를 베어서 다른 형태로 가공이 가능하도록 목재를 생산하는 사업을 관리하는 업무이며, ④‘매각’영역은 목재 매각의 의뢰와 처리 업무를 담당

· 위 업무 영역을 통해 구분 가능한 업무 영역은 4개이며, 각 세부 서비스의 분리가 가능하다는 사실을 도출

<그림 68> 산림자원통합관리시스템 서비스 구성도

출처 : 국가산림정보화 기반조성 5단계 구축 제안요청서, 산림청, 2014

주요 하드웨어 현황

· 해당 시스템이 구동되고 있는 주요 하드웨어 현황은 WEB용 서버 1식, WAS용 서버 1식, Database용 서버 1식으로 구성

서버명 모델명 CPU MEM DISK 외장DIS ******* 내부망 통합WEB ************* **** ********* ** ******* 내부망 통합WAS ************* **** ********* ***** ** 내부망 ******* ************* **** ********* 자원정보DB **

<표 27> 산림자원통합관리시스템 주요 하드웨어 목록

소프트웨어 운영 현황

· 해당 시스템은 WEB서버는 ***********, WAS서버로는 *************을 운영하고 있음 · 웹하드 소프트웨어로 ***********이 있고 해당 소프트웨어를 구동하기 위해 ****************************************을 운영하고 있으나, 이는 웹하드에 포함된 SW로서 산림자원통합관리시스템이 이용하지 않음

○ 시스템 기능 조사 결과 분석

주요 프로세스(조림, 숲가꾸기, 벌채)

· 기본정보 작성 -> 사업추진계획보고 -> 전자계약 체결 -> 현장인도보고 -> 중간점 검 및 지도보고 -> 완료보고 및 준공 -> 사업정산

<그림 69> 산림자원통합관리시스템 산림사업 업무 프로세스

주요 프로세스(매각)

· 조림/숲가꾸기/벌채 사업 결과 조회 및 선택 또는 직접 입력 하여 매각 의뢰 생성

· 매각의뢰 후 선택하여 매각처리 실시. 매각처리로 진행하지 않고 의뢰로 끝나기도 함

<그림 70> 산림자원통합관리시스템 매각사업 업무 프로세스

기능 구조

· 산림자원사업관리시스템의 화면 구성상 메뉴를 기준으로 기능을 분석한 바 해당 시스템은 크게 조림/숲가꾸기/벌채/특수 사업 추진을 위한 ‘사업조회(산림사업)’메뉴와 매각의뢰 및 처분을 위한 ‘매각’메뉴로 구분되어 사용되고 있음

기능 관점 관리단위 판단 (1안)

· 메뉴 구조를 통해 구분 가능한 기능은 크게 ①사업(산림사업)과 ②매각 2개의 관리단위 분리할 수 있음

<그림 71> 산림자원통합관리시스템 메뉴 구조도

기능 관점 관리단위 판단 (2안)

· 산림사업이 조림, 숲가꾸기, 벌채 등으로 나뉘어져 있고, 각 영역이 다소 다른 기능을 수행하므로 아래와 같이 ①조림, ②숲가꾸기, ③벌채, ④매각을 관리단위로 도출할 수 있음

기능 고유 기능

조림 단가 및 원가 계산 숲가꾸기 조사야장, 집계표 및 원가계산 벌채 자재조사계획, 조사야장, 집계표 및 원가계산 매각 검척내역, 재적집계표, 대금사정인자조사서

<표 28> 산림자원통합관리시스템 주요 기능 명세

기능적 연계 시스템

· 산림자원통합관리시스템은 국유림경영정보시스템과 실적과 경영계획 정보를 연계하고 있으며, 산림사업용역관리 및 산림공간정보서비스 시스템으로부터 사업정보 및 공간정보를 제공받고 있음

· 산림자원통합시스템의 서비스는 추진계획보고, 전자계약체결, 중간점검 및 지도보고, 완료보고의 순으로 진행되며 각 보고 단계는 온나라시스템과 연계 되어 기안문 생성 후 결재를 받아야 함. 따라서 기안 데이터가 온나라시스템의 기록물건으로도 존재함

<그림 72> 산림자원통합관리시스템 외부 시스템 연계도

○ 데이터베이스 및 데이터 구조 조사 결과 분석

데이터베이스 현황

· ***********환경 내 단일 데이터베이스로 구성하여 상시적으로 운용되고 있으며, 2012년 이후 축적된 데이터베이스 용량은 600M로 산술적으로 매년 120M정도 증가하고 있으나, 현 기준 증가 추세를 반영한 년간 증가량 추정치는 약 200M로 예상되고 있음

DBMS ********** Database 개수 1개

현재 용량 600M 년간 증가량 약 200M/년

<표 29> 산림자원통합관리시스템 데이터베이스 현황

· 개인정보 : 없음

· 정보공개 정책 및 청구 내역 : 없음

· 공공 데이터 포털에 공개 여부 : 없음

데이터 분산 및 연계 분석

· 유입되는 정보는 많지 않으며, 사업 완료 시 실적 정보를 국유림경영정보시스템으로 전송, 공공데이터 포털 연계나 데이터 활용 없음

데이터 연계 시스템 형태 데이터 추진시점/빈도 저장 여부 국유림경영계획시스템 입 **** 사업 등록 시 1회 저장 없음 사업 완료 후 1회 사업 데이터 국유림경영계획시스템 출 ***** 최종 실적 전송 중 일부 ***************** 사업 조회 시마다 산림공간정보서비스 입 저장 없음 ******* 수시 시스템에서 등록한 사업 데이터 산림사업용역관리 입 ***************** 사업과 동일한 저장 테이블에 저장 계 획 보 고 , 온나라시스 전 자 계 약 체 결 , 템 결재문서 온나라 시스템 출 ***** 현장인도보고,중간 첨부 파일로 점검보고, 완료보고 저장

<표 30> 산림자원통합관리시스템 연계시스템 현황

데이터베이스 스키마 분석

· 테이블 분석 결과 총 188개의 테이블이 식별되었으며 각 테이블의 컬럼의 개수를 확인하여 컬럼의 개수가 많은 테이블 중 논리적 엔터티가 하나의 물리적 테이블로 구성되지 않았는지 테이블 명세서를 통해 확인하였으나 특이점이 발견되지 않아, 논리적 엔터티의 최소 단위를 물리적 테이블로 판단해도 무방

테이블명 매핑되는 엔터티명 컬럼개수

*********************** ****** 56

****************** **** 51

******************** **** 39

******************** ***** 37

******************** ***** 34

************* *** 28

<표 31> 컬럼개수가 상대적으로 많은 물리적 테이블

· 데이터형식(Data Type) 및 컬럼 분석 결과 사용자정의 데이터형식(User Defined date type)은 발견되지 않았으며, 모두 리터럴을 저장하는 스칼라(Scalar) 데이터 형식이었으나 바이너리(비정형 데이터)를 저장할 수 있는 BLOB type을 사용하고 있는 컬럼이 존재함. 바이너리에 저장된 데이터를 비정형 데이터로서 보존 시 데이터베이스 외부에 존재하는 파일로 보존할지 결정하도록 함

테이블명 엔터티명 컬럼명 어트리뷰트명

************************ ***** *************** 도면이미지내용

***************************** ******* *************** 도면이미지내용

<표 32> 바이너리 데이터형식의 컬럼 목록

· 숫자 타입(NUMBER) 컬럼 비중이 높음. 이는 수치, 요율 등 숫자 데이터, 과거 엑셀로 작성하던 각종 서식을 시스템화했기 때문에 데이터세트는 숫자 타입 데이터가 많은 비중을 차지함

컬럼 NUMBER 물리 테이블명 엔터티명 설명 개수 컬럼 개수

**************** 산림자원통합 수고측정지별 ****** 4 4 ********* 수고 정보를 관리

사업의 운반로 작업로 구분에 **************** ******** 따른 단가 기초자료정보를 7 6 ******* 관리

**************** 사업의 수고측정지 번호별 ****** 7 6 ******* 직경별 평균수고 정보를 관리

**************** 매각 사업의 사정금액 내역의 ***** 11 9 ********* 정보를 관리

사업의 조재율번호,수종, ************* *** 공시목번호,생산재번호별 11 9 공시목 정보를 관리

<표 33> NUMBER 타입 데이터 저장 테이블 예시

테이블 당 평균 컬럼 수 10개

NUMBER 타입 컬럼 비중 50% 이상 테이블 56개

NUMBER 타입 컬럼 100% 테이블 *********************************

<표 34> 스키마 외형적 특성

테이블 관계 분석 및 테이블 그룹 도출

· 물리적 테이블 관계 분석을 통해 최상위계층(root node)에 위치한 테이블은 총 52개로 식별되었으며, 이 테이블을 하위계층의 연관관계 분석과 논리 엔터티 매핑 분석을 통해 3개의 핵심기능 데이터 유형과 참조데이터 유형, 기초 및 코드자료 유형, 보고· 통계용 데이터 유형, 단순 기능지원 데이터 유형으로 분류가 가능함

유형 테이블명 · **** 핵심기능 데이터 · ********** · ********** · ********** · ******** 산림사업 참조 · **** 데이터 · **** 참조데이터 · ****** · ******* 산림사업/매각사업 · *** 공통 참조 데이터 · ***** · ********* · ****** · ******** 기초자료 및 코드 데이터 · ********** · *********** · ****** · ******** 보고·통계용 데이터 · ***** · ******** · **** · ******* 기능지원 데이터 · ****** · ********* 참조 데이터 · ***

<표 35> 물리적 테이블 관계 분석을 통한 데이터 유형 분류

· 이중 참조 데이터는 논리적으로 각 핵심기능 데이터의 그룹에 포함을 시킬 수 있으며 기능지원 데이터와 참조 데이터는 관리단위로 판별되지 않으므로 최종적으로 핵심기능 데이터 유형으로 식별된 3개 테이블 그룹과 보고·통계용 데이터 유형인 6개 테이블, 총 9개의 테이블 그룹이 식별되나, 보고·통계용 데이터 유형을 관리단위로 판별할 것인지 추가 판단이 필요

데이터 관점 관리단위 판단

· 데이터베이스 연관관계를 분석한 결과 조림/숲가꾸기/벌채 사업에서 생성한 데이터를 매각사업에서 참조, 조회하고 있고, 산림사업에서 확정된 데이터 중 일부는 매각사업에서 처리 완료를 위해 참조하고 있음

· 이는 기능 조사 결과 분석에서 식별한 2개의 관리단위(산림사업과 매각)는 서로 의존적임을 알 수 있으며, 매각(매각의뢰/매각처분) 데이터와 사업(조림/숲가꾸기/벌채) 데이터는 독립적으로 분리할 수 없음을 확인함

<그림 73> 산림자원통합관리시스템 논리 ERD 일부

비정형 데이터 보유 현황

· 산림사업과 매각 기능 모두 비정형 데이터를 첨부파일 형태로 포함하고 있으며, 파일 유형에 제약을 두고 있지 않음

확장자 건수 확장자 건수

jpg 195 tif 20 xml 18 shx 39 bmp 7 dxf 2 lnk 2 dwg 2 xlsm 3 gdf 3 shp 75 xlsx 430 txt 1 mht 2 png 2 hwp 7,996 pdf 1,504 xls 753 zip 165 총건수 11,219 총용량* 52,53G

<표 36> 산림자원통합관리시스템 비정형 데이터 확장자 목록

○ 시스템 기능 및 데이터 분석을 통한 관리단위 식별

대기능과 데이터(테이블) 매핑

· 조림, 숲가꾸기, 벌채 기능은 하나의 테이블 그룹에서 데이터가 저장·관리되고 있으므로 삼림사업이란 기능으로 묶여야 하며, 다른 테이블 그룹인 매각사업 정보도 산림사업

기능에서 사용되고 있는 테이블을 공유하고 있어 독립적으로 구분되어지지 않음

<그림 74> 산림자원통합관리시스템 대기능과 데이터 매핑도

관리단위 : 산림자원관리사업

· 시스템 기능 및 데이터 분석과정과 기능 및 데이터 매핑 분석과정을 통해 식별한 관리단위는 조림, 숲가꾸기, 벌채 등 ‘산림사업’과 ‘매각사업’ 데이터를 아우르는 ‘산림 자원관리사업’으로 식별됨

○ 보존기간

보존기간이 책정되어 있지 않으며 폐기 필요 원인이 없었음

사업의 대상인 산림의 유지 기간이 장기간이고 산림자원의 관리 증빙의 목적으로 볼 때 영구 보존이 적합하다고 기관과 조사팀은 판단함

보존기간 설정 단위 : 데이터베이스 단위 영구 보존

나. 국민신문고시스템

○ 조사 개요

조사 대상 시스템 : 국민신문고

관리기관 : 국민권익위원회

기관 시스템 담당 : 국민권익위원회 국민신문고과 전산사무관

조사 추진 경과

· 1차 조사 (2017.6.7.) - 시스템 개요 조사 및 1차 조사표 작성

· 2차 조사 (2017.6.21.) - 기능 및 데이터베이스 조사 및 2차 조사표 작성

· 3차 조사 (2017.7.6.) - 데이터베이스 상세 조사

시스템 선정 배경

· 다수기관 데이터연계형( 한 기관에서 생산한 데이터를 다수 기관에서 연계 또는 참조하는 형태) 대표 시스템으로 선정 · 여러 기관 통합과 민원 데이터 보존기간으로 인한 이슈가 존재할 것으로 예상

시스템 구축 배경

· 스마트한 국민신문고 서비스 체계 마련

· 국민신문고 시스템의 업무환경 변화에 따른 대응 및 지속적인 개선 추진을 통해 실질적인 업무 활용성 및 생산성 증대

· 온라인 국민소통 창구 확대에 대한 적극적 대응으로 국민신문고 이용 활성화 도모 · 개별기관에 중․반복적으로 제기되는 동일․유사민원과 제안의 효과적이고 효율적인 처리 필요- 동일․유사민원의 처리에 행정기관의 업무 부담이 크고, 기관별로 처리결과가 달라 민원처리에 대한 신뢰성 저하 문제 발생

시스템 구축 연혁

· 2003년부터 2005년까지 계획수립 및 시범구축을 진행하였으며 2005년부터 2006년까지 모든 중앙부처 통합완료를 통해 본격적인 운영을 시작. 2006년부터 해당 시스템의 운영이 본격적으로 시작

· 2011년까지 주요 공공기관의 연계를 확대하여 2017년 현재 기능 고도화 사업 진행 중으로서 민원 폐기를 위한 기록관리기능을 구현할 예정. 사업을 발주하게 된 가장 주요 동기는 민원에 포함된 개인정보를 폐기로서, 폐기 기능이 부재함을 물론 민원 처리 기관은 권익위가 아닌 전국 공공기관으로서, 현행과 같이 데이터세트 기록관리 방안과 근거 법령이 정비되지 않은 실정이므로 각 사용기관이 폐기할 수 있도록 기능 개발을 우선 추진하게 되었음

년도 구축 내용

2004 정보화 전략체계(BPR/ISP) 수립

온라인국민참여포털시스템 구축 시범사업 - 민원․국민제안․정책토론을 포함한 통합서비스 개시(’05.8월) 2005 온라인국민참여포털시스템 확대 1단계 구축사업 (56개 중앙행정기관의 민원․국민제안․정책토론 등 국민소통 업무 및 관련 대국민서비스 통합) 56개 중앙행정기관 민원․국민제안․정책토론 등 국민소통 업무 및 관련 대국민서비스 통합 완료 2006 온라인국민참여포털시스템 확대 2단계 구축사업 - 지자체․공공기관 민원시스템 시범연계 및 확대방안 수립(’07.4월) 온라인국민참여포털시스템 확대 3단계 구축사업 2008 - 시범연계를 제외한 231개 지방자치단체 및 11개 공공기관 민원시스템 연계

년도 구축 내용

2010 국민신문고 애플리케이션 (’10.7월) 및 모바일 웹서비스(’11.7월) 개발

2017 기능 고도화(신문고 기록관리 시스템 등)

<표 37> 국민신문고 년도별 구축 내용 관련 법률

번호 법령

국민제안규정 1 (대통령령 제27763호, 2017.1.6., 전부개정) 국민제안규정 2 (행정자치부령 제105호, 2017.1.6., 전부개정) 행정절차법 3 (법률 제12923호, 2014.12.30., 일부개정) 온라인 국민참여포털의 운영에 관한 규정 4 (대통령훈령 제343호, 2015.6.10., 일부개정)

<표 38> 국민신문고 관련 법률

○ 시스템 현황

시스템 목적

· 정부에 대한 모든 민원·제안·신고와 정책토론 등을 인터넷으로 간편하게 신청하고 처리하는 범정부 대표 온라인 소통 창구로, 모든 행정기관(중앙·지자체·교육청·해외공관), 사법부, 주요 공공기관과 연결되어 원-스톱 서비스를 제공

<그림 75> 국민신문고 기관 연계

시스템 사용자

· 국민과 중앙행정기관 및 기타 공공기관의 민원 접수 및 처리 담당자 (500여개)가 사용중

<그림 76> 국민신문고 이용기관 현황 출처 : 국민신문고 시스템 기능 고도화 사업 제안요청서, 국민권익위원회, 2017

업무 현황

· 중앙행정기관 및 기타 공공기관 500여개 기관이 국민신문고시스템에 접속하여 민원 처리

· 지방자치단체 및 교육청 등 400여개 연계 기관은 국민신문고에서 신청된 민원을 이첩하거나 이첩 받도록 연계하고 있음

· 현재 진행 중인 고도화를 통하여 민원 업무 처리만이 아니라 Q&A 서비스 추가 제공 예정

<그림 77> 홈페이지 – 민원 · 정책 Q&A 서비스 제공 출처 : 국민신문고 시스템 기능 고도화 사업 제안요청서, 국민권익위원회, 2017

국민신문고 정보화 현황

· 모든 행정기관(중앙부처·지자체·해외공관·교육청), 사법부 및 주요 공공기관과 연결되어 원-스톱 소통 서비스 제공

<그림 78> 현행 시스템 개념도

출처 : 국민신문고 시스템 기능 고도화 사업 제안요청서, 국민권익위원회, 2017

기록물 및 이용기관 현황

· 2015년 기준 년간 생성되는 기록물은 민원 190만여건, 제안은 16만 여건 등 200만 여건이 생산되고 있음

구분 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015

민원 4,473 402,442 556,532 623,434 696,715 798,570 1,073,499 1,247,711 1,523,787 1,691,223 1,901,944

제안 3,311 7,557 8,272 13,461 19,560 30,198 29,234 24,025 63,548 112,077 164,705

정책 83 608 1,008 1,231 984 872 1,096 1,697 2,297 4,780 5,734 토론 예산 ------3,347 3,505 2,864 1,119 낭비 공익 ------5,258 11,896 14,564 신고

<표 39> 국민신문고 기록물 현황 출처 : 국민신문고 시스템 기능 고도화 사업 제안요청서, 국민권익위원회, 2017

중앙행정기관 지방자치단체 교육청 공공기관 재외공관 계

58 245 209 228 172 912

<표 40> 국민신문고 기록물 및 이용기관 현황 출처 : 국민신문고 시스템 기능 고도화 사업 제안요청서, 국민권익위원회, 2017

외부 시스템 연계현황

타 기관 시스템에서 신청된 신청 민원 EAI / ESB

처리 기관으로 이송한 신문고 신청 민원의 처리 결과 EAI / ESB 입수 방법 정보 사용기관의 민원 처리 중 연계 기안하여 온나라시스템에서 결재 완료된 민원의 결재내역 및 XML 수정 문서

처리 기관으로 이송하는 신문고 신청 민원 EAI / ESB 입출 사용기관의 민원 처리 중 온-나라시스템에서 결재 방법 정보 XML 받기 위한 기안문

<표 41> 국민신문고 연계 데이터 현황

· 연계 시스템의 종류는 타 기관 민원시스템, 타 기관 민원신청 시스템, 온-나라시스템과 민원정보분석 시스템 4가지가 있으며, 각 기관의 종류가 많기 때문에 연계에 의해 복사되는 데이터가 많이 발생

<그림 79> 국민신문고 외부 시스템 연계도

시스템 서비스 내용 및 대기능

· 국민신문고의 기능은 ①민원, ②국민 제안, ③공무원 제안, ④정책참여, ⑤예산낭비, ⑥공익신고 등 총 6개의 대기능으로 분류 가능

· ①민원 영역은 민원 신청 및 처리 결과 조회 기능이며 · ②국민 제안 영역은 일반 제안 및 공모 제안을 처리하고

· ③공무원 제안은 공무원 사용자의 제안을 처리

· ④정책참여는 기관에서 발제한 정책에 대한 의견 수렴 창구, 댓글을 통한 의견 제출, 전자공청회, 설문조사 등의 기능이 있으며

· ⑤예산낭비 영역은 예산 낭비 신고 및 절감을 위한 제안, · ⑥공익신고는 공익침해 행위 신고 영역임

소프트웨어 운영 현황

· ******************************* 등 다수

민원이 국민신문고 시스템에서 가장 많이 사용되는 기능이며, 가장 많은 데이터를 보유하고 있으므로 민원 기능 중심으로 분석하였음

○ 시스템 기능 조사 결과 분석

민원처리 흐름도

· 국민신문고의 민원처리는 그게 신청, 접수, 처리단계로 나눠지며 각 민원처리담당자의 소속에 따라 데이터의 흐름 트랜잭션이 같이 발생.

· 민원의 처리가 종료되고 답변확인 및 만족도조사를 하면 해당 민원의 생애주기는 일단 종료된다고 판단할 수 있음

<그림 80> 민원처리 흐름도 *출처 국민신문고 매뉴얼-국민신문고 이용자 교육, 국민권익위원회, 2016

<그림 81> 국민신문고 데이터 연계 흐름도

메뉴 구조

구 분 설 명

•민원인이 해당 기관에 민원을 신청하는 화면

•메뉴 명칭은 기관별 코너 별 성격에 맞도록 설정 민원신청 필수메뉴

민원 ※필요한 경우, 해당코너에 공개로 신청된 민원 목록 조회 서비스 이용 가능

•해당기관에서 작성한 민원처리사례 및 정책 민원·정책 Q&A 선택메뉴 Q&A 목록 조회 서비스 화면 민원소개 선택메뉴 •민원소개 정보제공

일반제안 신청 필수메뉴 •제안인이 해당 기관에 제안을 신청하는 화면

•다수의 기관이 함께 특정과제를 지정하여 공모 공모제안 필수메뉴 기간 동안 아이디어를 모집하는 화면 국민제안 •해당기관에서 우수제안으로 발굴한 사례 제공 공개·우수제안 선택메뉴 화면 국민제안 스토리 선택메뉴 •제안스토리 정보 제공 국민제안 소개 선택메뉴 •제안제도 정보 제공 정책토론 선택메뉴 •해당기관에 개설된 토론 정보 제공 전자공청회 선택메뉴 •해당기관에서 개설한 전자공청회 정보 제공 정책참여 설문조사 선택메뉴 •해당기관에서 개설한 설문조사 정보 제공

구 분 설 명

•정책참여 캘린더는 정책토론, 전자공청회, 설문 정책참여 캘린더 선택메뉴 조사 시작일 기준으로 일정이 표시

정 책 •행정기관의 정책 홍보와 정책 결정에 있어 국민 참 의 다양한 목소리를 수렴하고, 국민은 정부정책의 선택메뉴 여 소 •수립, 집행, 평가 과정에 참여하여 의견을 제시 개 제공 정 정책참여 책 선택메뉴 •정책토론 정보제공 소개 토 론 전 •전자공청회를 통해 등록된 입법예고 정보 제공 자 공 선택메뉴 청 •전자공청회를 통해 등록된 행정예고 정보 제공 회

•신고 및 제안인이 해당기관으로 신청한 전체 예산낭비신고 필수메뉴 낭비신고 및 절감제안의 처리상태를 확인하는 화면

예산낭비 예산절감제안 필수메뉴 •제안인이 해당 기관에 절감제안을 신청하는 화면

예산낭비신고 •신고인이 해당 기관에 예산낭비신고를 신청하는 필수메뉴 소개 화면 •공익신고는 국민의 건강과 안전, 환경, 소비자 공인신고 신청 필수메뉴 이익과 공정한 경쟁을 침해하는 행위를 소관 공익신고 행정·감독 공인신고 소개 선택메뉴 •공익신고 정보제공

<표 42> 국민신문고 메뉴구조

기능 구조 및 관리단위

· 국민신문고의 메뉴구조상 민원, 국민제안, 정책참여, 예상낭비, 공익신고로 크게 나눠볼 수 있으나, 각 대메뉴내 하위메뉴까지 분석하여 정적기능, 보조기능 등을 제거하면 ①민원, ②국민 제안, ③공무원 제안, ④정책참여, ⑤예산낭비, ⑥공익신고 등 총 6개의 대기능으로 분류가 가능

○ 데이터베이스 및 데이터 구조 조사 결과 분석

데이터베이스 현황

· 국민신문고내에는 여러 가지 DBMS가 존재하나 국민신문고의 주서비스의 DBMS는 단일 시스템으로 구성되어 있음. (나머지는 기능적인 목적의 DBMS로 판별)

S/W용도 제품명 설치시스템 도입년도 수량

************* DB서버 2 ********* DW서버 1 ****** SNS DB 1 DBMS ***** 메일 발송서버,채팅서버 2 ***** 메일 발송서버 **** 1 ***** *********** 1

<표 43> 국민신문고 전체 DMBS 현황

· 국민신문고의 데이터는 ****** DBMS환경내 단일 데이터베이스로 구성하여 상시적으로 운용되고 있으며, 2017년 6월 현재기준 약 1.2T의 용량 운용

DBMS ************* Database 개수 1개

현재 용량 1.2T(인덱스 포함) 년간 증가량 -

<표 44> 국민신문고 데이터베이스 현황

· 개인정보 : 민원 청구인 연락처의 개인정보 및 민원 내용 중에 개인정보 존재

· 정보공개 정책 및 청구 내역 :청구 있음

· 공공 데이터 활용현황 : 권익위 내 민원정보분석 시스템의 빅데이터로 제공

데이터베이스 스키마 분석

· 테이블 분석 결과 총 696개의 테이블이 식별되었으며 각 테이블의 컬럼의 개수를 확인하여 컬럼의 개수가 많은 테이블 중 다수 논리적 엔터티가 1개 물리적 테이블로 구성되지 않았는지 테이블 명세서를 통해 확인하였음. 해당 테이블들은 시연이나 로그용 테이블이 많았으며 고충민원접수 등 주요 테이블의 컬럼을 확인하여 별도의 엔터티가 없음을 확인

테이블명 매핑되는 엔터티명 컬럼개수 ************ ****************** 166 *********************** ****** 142 ****************** **** 141 ******************* ******* 115 **************** ****** 100 ********************* ************************* 99 ****************** **** 94

<표 45> 컬럼개수가 상대적으로 많은 물리적 테이블

· 데이터형식(Data Type) 및 컬럼 분석 결과 ‘******’란 사용자정의 데이터형식(User Defined date type)을 발견하였으나, 해당 테이블을 분석한 결과 시스템 정보를 저장하지 않고 사용하지 않는 관리제외 테이블로 판별되었음

· 암호화된 정보는 **************에 저장하고 있음

· 민원 및 답변, 제안, 정책토론의 내용은 텍스트형의 테이터로서 *********타입 이용하고 있음

테이블 관계 분석 및 테이블 그룹 도출

<그림 82> 테이블 그룹별 의존관계 · 대기능에 따라 사용 테이블이 분리되어 있으며, 기능별로 약어를 사용하고 있음

기준데이터

1 민원: 일반, 고충

2 국민제안: 일반, 공모

3 공무원제안

4 정책토론, 전자공청회

5 설문조사

6 예산낭비신고

7 공익신고

<표 46> 신문고 마스터 테이블

비정형 데이터 보유 현황

· 국민신문고는 비정형 데이터의 확장자 종류가 393건으로 첨부파일 등록시 비정형 포맷의 제약을 두지 않는 것으로 분석됨

확장자 종류 용량

393건 66T

<표 47> 국민신문고 비정형 데이터 확장자 목록

○ 시스템 기능 및 데이터 분석을 통한 관리단위 식별

대기능과 데이터(테이블) 매핑

· 민원, 국민제안, 공무원제안, 정책토론, 예산낭비신고, 공익신고 대기능은 데이터 구조상 회원 및 기능테이블제외 서로 연관관계가 식별되지 않음

<그림 83> 국민신문고 대기능과 데이터 매핑도

관리단위 : 민원, 국민제안, 공무원제안, 정책토론, 예산낭비신고, 공익신고

· 시스템 기능 및 데이터 분석과정과 기능 및 데이터 매핑 분석과정을 통해 민원, 국민제안, 공무원제안, 정책토론, 예산낭비신고, 공익신고로 관리단위가 식별됨

○ 보존기간

· 민원에는 2개 종류가 존재하며 처리 프로세스가 약간 다르나 같은 저장 테이블과 컬럼을 공유함. 그러나 기록관리 관점에서 분석 시 보존기간이 상이하여 일반민원은 10년, 고충민원은 준영구에 해당

· 보존기간의 설정 단위는 민원 테이블에서 민원 종류 조건으로 추출되는 데이베이스 레코드여야 함

구분 일반민원 고충민원 부패방지 및 국민권익위원회의 법령 민원 처리에 관한 법률 제2조 제1항 설치와 운영에 관한 법률 제2조 제5항 법정민원(법령·훈령·예규·고시·자치법규 등에서 정한 일정 요건에 따라 인가·허가·승인·특허·면허 행정기관등의 위법·부당하거나 등을 신청하거나 장부·대장 등에 등록·등재를 신청 소극적인 처분(사실행위 및 또는 신고하거나 특정한 사실 또는 법률관계에 부작위를 포함한다) 및 관한 확인 또는 증명을 신청하는 민원), 불합리한 행정제도로 인하여 질의민원(법령·제도·절차 등 행정업무에 관하여 국민의 권리를 침해하거나 정의 행정기관의 설명이나 해석을 요구하는 민원), 국민에게 불편 또는 부담을 건의민원(행정제도 및 운영의 개선을 요구하는 주는 사항에 관한 민원), 기타 행정기관에 단순한 행정절차 또는 민원(현역장병 및 군 관련 형식요건 등에 대한 상담·설명을 요구하거나 의무복무자의 고충민원을 일상생활에서 발생하는 불편사항에 대하여 알리는 포함한다) 등 행정기관에 특정한 행위를 요구하는 민원 처리기간 7일(단순 질의상담) 14일(법령질의) 이내 60일 이내 보존기간 10년 준영구

<표 48> 민원의 종류에 다른 보존기간

다. KAIST 전자연구 노트관리시스템

○ 조사 개요

조사 대상 시스템 : 한국과학기술원 전자연구노트시스템

관리기관 : 한국과학기술원

기관 시스템 담당 : 한국과학기술원 학술정보개발팀 전문선임기술원

조사 추진 경과

· 1차 조사 (2017.7.3.) - 시스템 개요 조사, 데이터 구조 등 도출 및 1차 조사표 및 2차 조사표 작성

시스템 선정 배경

· 단일시스템(공공기관)의 대표 시스템으로 선정

시스템 구축 배경

· 국가연구개발사업 수행 연구기관으로서 연구노트 관련 규정을 준수할 수 있도록 체계적 관리 및 활용 방안을 마련하고, 장기적으로 연구노트를 보존하고 관리를 할 수 있도록 전자기록의 구조를 반영할 필요 존재

시스템 구축 연혁

· 2009년 전자발명일지 시범 보급 사업으로 구축된 운영시스템의 기능 미비와 노후화로 한국과학기술원 연구원들의 요구사항과 편의성을 반영하여 2016년 전면 재구축

년도 구축 내용

2009 특허청의 전자발명일지 시범 보급 사업에 의해 구축 기존시스템 폐기 후 재구축 (데이터 마이그레이션) - 주요 기능개편 2016 · 서면연구노트 관리 및 전자연구노트 업로드 기능 · 결재 기능 및 특허 연계 · 관리자 기능 강화

<표 49> 전자연구노트시스템 년도별 구축 내용

관련 법률

· 미래창조과학부 ‘연구노트지침’에 의해 시스템 구축. 법률적으로 필수적으로 구축해야 하는 시스템은 아님

번호 법령

1 ‘국가연구개발사업의 관리 등에 관한 규정’제29조 2 미래창조과학부 훈령 제44조‘연구노트지침’

<표 50> 전자연구노트시스템 관련 법률

○ 시스템 현황

시스템 목적

· 연구원들이 연구과정에서 발생하는 각종 프로세스 및 결과를 기록하고 연구과제를 같이 수행하는 연구원들 간 지료를 공유함으로써 연구 수행의 효율성을 높이고, 기록으로 보존하기 위함

시스템 사용자

· 한국과학기술원 전체 전체직원(교수,학생,직원) 총 17,063명

시스템 서비스 내용 및 대기능 분석

· 서면연구노트관리, 전자연구노트관리, 결재 등

주요 하드웨어 현황

· ********************* 2.4GHz / 32GB Memory / 8Gb FC Single-port HBA / 300GB 10K SAS Disk * 2EA

소프트웨어 운영 현황

· OS : ******************

· ****** 2.4 (Web Server)

· ****** 7.0.72 (WAS)

· ******** 5.1.0

<그림 84> 전자연구노트시스템 데이터 흐름도

100

○ 시스템 기능 조사 결과 분석

기능 구조

· 기능분석을 통해 도출된 기능구조는 아래와 같으며 이중 대기능은 전자연구노트관리, 서면 연구노트 상태관리로 도출

구분 기능

전자연구노트/서면연구노트 신청 연구노트 신청 점검자/열람자 지정 신청서 결재 상신 표지 등록

서면연구노트 관리 연구노트 상태 관리 (등록, 제출, 비치, 대여, 활용)

연구노트 상태 이력 파일 관리 기능 시점인증 신청 기능 시점인증 검토 기능 시점인증파일 버전 관리 기능 전자연구노트관리 점검자 관리 기능 기록자 위임 기능 PDF 변환 및 시점 인증 요청 기능 시점인증파일 Web 기반 보기 기능 대용량 파일업로드/다운로드 기능 공유된 연구노트 조회 기능 전자연구노트 공유 공유된 파일 열람/인쇄 기능 연구노트 단위 권한 관리 기능 권한관리기능 파일단위 권한관리 기능 열람 및 인쇄의 경우 승인 처리 기능 과제명, 파일명, 기록자, 원문 검색 검색 시점인증파일 필터링 기능 기록자/계정책임자에게 연구노트 작성 안내 메일 메일알림 과제 종료시 기록자/계정책임자에게 연구노트 제출 안내 메일 과제책임자 위임 기능 과제별 관리 기능 과제별 자료실 기능 시점자동인증, 점검자, DRM 적용 선택 기능 공지사항 연구노트 등록 현황 관리자 기능 및 기타 접속현황 이용자, 조직 관리 대용량 파일업로드/다운로드 기능

<표 51> 전자연구노트시스템 주요 기능 명세

101

기능 관점 관리단위 판단

· 메뉴 구조를 통해 구분 가능한 기능은 크게 ①‘전자연구노트’와 ②‘서면연구노트’등 2개의 관리단위 분리할 수 있음. 그러나 과제라는 개념이 상위의 레벨에서 전자연구노트와 서면연구노트를 아우르고 있음

<그림 85> 전자연구노트시스템 핵심 메뉴 노출 화면

기능적 연계 시스템

· 한국과학기술원 내부의 인사시스템, 연구관리시스템, 특허관리시스템 등과 연계하여 인사정보와 연구과제정보를 송수신함

연계 시스템 연계 목적 비고 ***** 사용자 인증 서비스 ***** 사용자, 조직 정보 확인 ******* ******* 연구과제 및 참여연구원 분류 ******* 특허정보 검색 *** ******* 등록된 연구노트의 시점 인정 ********* · <표 52> 외부시스템 연계 현황

○ 데이터베이스 및 데이터 구조 조사 결과 분석

데이터베이스 현황

· *******DBMS환경 내 단일 데이터베이스로 구성하여 상시적으로 운용되고 있으며, 전체 데이터 축적량은 2T로 학생들의 과제제출용 연구노트 등 보존의 필요성이 낮은 파일들이 많은 용량을 차지

DBMS ********** Database 개수 1개

현재 용량 15T 년간 증가량 -

<표 53> 전자연구노트시스템 데이터베이스 현황

· 개인정보 : 없음

102

· 정보공개 정책 및 청구 내역 : 없음 · 공공 데이터 포털에 공개 여부 : 없음

데이터 분산 및 연계 분석

· 데이터 분산은 존재하지 않았음

데이터베이스 스키마 분석

· 테이블 분석 결과 총 20개의 테이블이 식별되었으며 각 테이블의 컬럼의 개수를 확인하여 컬럼의 개수가 많은 테이블중 다수 논리적 엔터티가 1개 물리적 테이블로 구성되는지를 테이블 명세서를 통해 확인하였으나 특이점이 발견되지 않음. 따라서 논리적 엔터티의 최소 단위를 물리적 테이블로 판단함

테이블명 매핑되는 엔터티명 컬럼개수

****************** 특허 사례 60

************ 특허 25

************** 연구 21

<표 54> 컬럼개수가 상대적으로 많은 물리적 테이블

· 데이터형식(Data Type) 및 컬럼 분석 결과 사용자정의 데이터형식(User Defined date type)은 발견되지 않았으며, 모두 리터럴을 저장하는 *********** 데이터 형식임

테이블 관계 분석 및 테이블 그룹 도출

· 물리적 테이블 관계 분석을 통해 최상위계층(root node)에 위치한 테이블은 총 52개로 식별되었으며, 이 테이블을 하위계층의 연관관계 분석과 논리 엔터티 매핑 분석을 통해 3개의 핵심기능 데이터 유형과 참조데이터 유형, 기초 및 코드자료 유형, 보고· 통계용 데이터 유형, 단순 기능지원 데이터 유형으로 분류가 가능

데이터 관점 관리단위 판단

· 연구과제를 최상위로 (전자)연구노트-서면연구노트로 관리하여 전자연구노트와 서면연구노트는 분리하여 관리할 수 없음

마스터테이블 1차 관계 2차 관계 연구과제 연구과제 매핑 연구노트생성 연구노트 서면연구노트 서면연구노트추가 사용자 정보 폐기관리 서면연구노트 신청서

<표 55> 연구노트 관리

103

비정형 데이터 보유 현황

확장자 종류 등록건수

25종 21,095건

<표 56> 전자연구노트시스템 비정형 데이터 확장자 목록

○ 시스템 기능 및 데이터 분석을 통한 관리단위 식별

대기능과 데이터(테이블) 매핑

· 전자연구노트, 서면연구노트의 테이블이 서로 독립적이지 않고, 연구과제 및 연구노트를 기준으로 연관되어 있음

<그림 86> 전자연구노트시스템 대기능과 데이터 매핑도

관리단위 : 연구노트

· 시스템 기능 및 데이터 분석과정과 기능 및 데이터 매핑 분석과정을 통해 연구노트라는 단일 항목으로 관리단위가 식별

○ 보존기간

연구노트는 근거 연구노트 지침에 따라 30년 보존해야 함

제11조(보관 및 관리)

① 연구노트를 소유하고 있는 연구기관의 장은 국가연구개발사업의 수행을 통해 얻은 연 구노트를 보관하고 관리할 책임이 있다.

② 연구노트는 다음 각 호에 따라 보관·관리하여야 한다.

1. 연구노트의 보존기간은 작성일 부터 30년으로 한다. 다만, 기관 특성과 과제 성격을 감안하여 별도로 연구기관의 장이 정할 수 있다.

보고서 성격의 노트가 존재하며 특히 타 연구 참고용 또는 증빙 모든 면에서 보존 가치가

104

없는 서면 노트를 보존하기 위하여 인적 및 보존서가와 같은 물리적 자원이 소요되고 있어 한국과학기술원은 기록관리 부서는 보고서 성격의 노트는 10년으로 책정하길 희망하고 있음

라. 특허넷

○ 조사 개요

조사 대상 시스템 : 특허넷 시스템

관리기관 : 특허청

조사 추진 경과

· 1차 조사 (2017.7.5.) - 시스템 개요 조사 및 1차 조사표 및 2차 조사표 작성

시스템 선정 배경

· 단일기관 연계형의 대표 시스템으로 선정

시스템 구축 연혁

· 1999년 1월부터 본격적으로 시스템 활용

년도 구축 내용 제1차 특허행정 전산화 - FD 부본 출원제도 시행(‘96) 1995년 ~ - 서면출원에 대한 특허문서전지와사업 개시(‘97) 2002년 - 모든 출원서 컴퓨터를 이용한 심사로 대체(‘99) - 사이버통합민원실 구축 개통(‘02) 특허넷Ⅱ 개발 및 고도화 2003년 ~ - 자택심사시스템 구축 등 특허넷Ⅱ 개발(‘05~‘08) 2010년 - 특허정보 통계 시스템 구축 등 U-특허청 구현사업(‘06~’07) - 청내외 검색 인프라 통합 DB 표준화 등 고도화 진행(‘08~’10) 3세대 특허넷 구축 2010년 ~ - 메인 시스템 분석·설계(‘10) 2012년 - 메인 시스템 구현·시험, 부가 시스템 개발 1차(‘11) - 특허넷Ⅲ 1차 개통 및 부가 시스템 개발 2차(‘12)

<표 57> 특허넷 시스템 구축 경과

관련 법률

번호 법령 1 특허법 법률/대통령령/시행규칙 2 실용신안법 법률/대통령령/시행규칙 3 디자인보호법 법률/대통령령/시행규칙 4 상표법 법률/대통령령/시행규칙

105

번호 법령 5 발명진흥법 법률/대통령령/시행규칙 6 부정경쟁방지 및 영업비밀보호에 관한 법률 7 반도체집적회로의 배치설계에 관한 법률 8 변리사법 9 특허 협력 조약 등 특허와 관련된 11여개 국제조약

<표 58> 특허넷 관련 법률 ○ 시스템 현황

시스템 목적

· 출원·심사·등록·심판 및 공보발간 등의 모든 특허행정 업무처리를 통합하여 전산화

시스템 사용자

· 국민(출원인) 및 특허청 진직원 약 1,600여명이 사용

특허넷 시스템 현황

· 특허넷 시스템은 출원, 접수, 심사, 심판, 검색, 공보 등 총 33개의 단위시스템으로 구성

· 참고로 특허넷시스템이 포함된 특허행정보시스템에는 특허넷시스템 33개와 일반행정 시스템(14개)의 2개 범주, 총 47개 단위 시스템으로 구성

<그림 87> 특허넷 시스템 구성 현황

106

○ 시스템 기능 조사 결과 분석

주요 프로세스

· 특허심사의 주요 프로세스는 방식심사, 심사청구, 출원공개, 실체심사, 특허결정, 설정등록과 등록공고, 거절결정, 거절결정불복심판, 무효심판 등의 프로세스를 거침

<그림 88> 특허출원 및 심사절차 흐름도. 출처 : 특허청 홈페이지

<그림 89> 특허출원후 심사 흐름도. 출처 : 특허청 홈페이지

107

기능 구조

구분 시스템 상세 시스템 수 -통합keaps, 통합뷰어 -전자문서작성기(문서변환기포함) 전자출원소프트웨어 -첨부서류입력기/통지서열람기 -서열목록작성기/MM서식작성기 출원 2개 시스템 -모의전자출원 -상표홈페이지출원 웹출원시스템 -특실홈페이지출원 -디자인홈페이지출원 -온라인접수/서면접수 (출원,PCT, 등록, 심판, 마드리드, 통합접수시스템 기술평가 /이의신청 포함) -미생물기탁 -특허기술상 -출원 방식 접수 통합방식시스템 -지정관청방식(PCT국내단계) 4개 시스템 -국제상표 방식 -수수료정보관리 수수료관리시스템 -온라인수수료납부 -사전등록절차 출원인대리인시스템 -출원인대리인 -변리사통합관리 -등록/이의신청방식/기술평가 방식 -등록/이의신청 사무처리 등록 등록시스템 1개 시스템 -기술평가사무처리 -국유특허 특실심사시스템 -특실심사사무처리 디자인심사시스템 -디자인심사사무처리 상표심사시스템 -상표심사사무처리 심사 6개 시스템 국제상표심사시스템 -국제상표심사사무처리 심사평가시스템 -심사평가사무처리 국제디자인심사시스템 -국제디자인심사사무처리 -심판방식 심판 심판시스템 1개 시스템 -심판․특허소송사무처리

-PCT 방식(국제단계:RO, ISA, IPEA) PCT시스템 -PCT 심사(국제조사, 예비심사)

국제 -K-PION 2개 시스템 특허정보국제공개시스템 -T-PION(일본, 미국, 유럽) -TDA-PDX(일본, 미국, 유럽)

108

구분 시스템 상세 시스템 수

공보 공보발간시스템 -공보발간 1개 시스템

-특허검색 특실검색시스템 -생명공학검색, 메타검색 (KOMPASS) -개인DB클라이언트(PMS) 디자인검색시스템 -디자인검색 검색 6개 시스템 상표검색시스템 -상표검색 심결문/판결문검색시스템 -심결문/판결문검색 비특허문헌검색시스템 -비특허문헌검색 키프리스검색시스템 -국내·외지재권검색 -종합정보관리 -특허정보통계 특허정보통계시스템 -DW메타데이타관리 -심사참고문헌열람서비스 특허정보 -온라인제증명신청발급 3개 시스템 제공 제증명시스템 -서면제증명신청발급 -나의출원등록조회 나의출원등록조회시스템 -나의심판조회 -웹서비스 특허문서전자화시스템 -서면출원전자문서화 데이터품질관리시스템(DQ -데이터품질관리 MS) EA관리시스템(EAMS) -EA 관리시스템

정보화사업관리시스템(PMS) -정보화사업관리 지원 6개 시스템 -ITSM(서비스데스크), -고객지원요청(CSR) IT서비스관리시스템 -모델오피스 (ITSM) -데이터맵 -데이터수정관리 통합결재시스템 -통합결재, 발송 -반도체배치설계권접수 반도체배치설계 기타 -반도체배치설계권방식 1개 시스템 권관리시스템 -반도체배치설계권등록

<표 59> 특허넷 시스템의 분류 및 기능 기능 관점 관리단위 판단

· 특허시스템의 구성과 논리적 기능에 따라 ①출원,②접수,③등록,④심사,⑤심판,⑥공보, ⑦검색으로 관리단위로 판단

기능적 연계 시스템

· 지식재산연수원, 한국발명진흥회, 한국특허정보원 등 소속기관과 유관기관이 관리하고 있는 시스템이 특허넷 시스템과 일부 연계

109

기관명 시스템명 서비스 내용 설명

특허기술거래시스템 국유특허정보 제공, 4대 산업재산권 판매 기술 등록 (IP-Mart) 및 검색

기술(특허) 정보, 특허서지 및 경과 정보 등을 이용 온라인특허평가시스템 한 특허 평가 각 지역별(지역 브랜드) 특허기술동향 조사 분석 사 지역지식재산센터 발명진흥회 업 결과 제공 e-특허나라 특허분석보고서, 국제특허분쟁지도, 특허분석데이터, (특허분석정보제공시스템) 국가R&D특허동향 조사 산출물 IP휴먼네트워트 지식재산 전문인력 양성의 기반 인프라 제공 (지식재산인력종합관리) 발명에서 특허권리창출, 분쟁해결까지 지식재산권 국가지식재산교육포털 전 분야에 대한 교육 콘텐츠 제공 산업재산권 정보의 판결 관련 선행기술정보 자료의 판례DB검색시스템 보급 국가R&D특허성과 국가 연구개발사업의 특허성과를 수집, 분색해 가공 종합관리시스템 한 정보를 보급

한국특허정보원 전통지식검색 전통지식 관련 선행기술정보자료의 보급

특허정보검색서비스 특허, 실용신안, 디자인, 상표, 해외특허, 심판, 행정 (KIPRIS) 정보 등 특허정보 검색 및 열람 서비스 제공

표준화기구에서 제정한 표준규격이 포함되어 있는 표준특허시스템 표준특허 관련 정보 제공 국가연구개발사업 전 과정에 걸친 지재권 관리/활 R&D 특허센터(홈페이지) 용 전략 제시 및 상담 서비스 제공 한국지식재산연구 지식재산 관련 단행본, 정기간행물, 보고서, 학술 지식재산전문도서관 원 DB 정보 제공 지식재산권 관련 국내외 동향(주제별, 국가별), 발간 지식재산정책정보시스템 물 및 행사 정보 제공

<표 60> 특허넷 기능 연계 시스템 현황

○ 데이터베이스 및 데이터 구조 조사 결과 분석

데이터베이스 현황

· ****** DBMS환경 내 단일 데이터베이스로 구성하여 상시적으로 운용되고 있으며, 현재 기준 용량은 15T

DBMS ********* Database 개수 1개

현재 용량 15T 년간 증가량 -

<표 61> 특허넷 데이터베이스 현황

110

· 개인정보 : 출원인정보 · 정보공개 정책 및 청구 내역 : 없음

· 공공 데이터 포털에 공개 여부 : 없음

데이터 분산 및 연계 분석

· 물리적 데이터베이스 관점에서의 데이터 분산은 존재하지 않음

데이터베이스 스키마 분석

· 내부 보안정책 이슈로 ERD나 테이블 명세서 분석 등 실체적 접근방식의 분석은 진행하지 못하였으나, 인터뷰를 통해 물리적 데이터베이스의 구조를 파악한 결과 특허 출원정보를 기준으로 대부분의 테이블이 연관관계가 복잡함

비정형 데이터 보유 현황

· 냄새, 이미지, 소리파일 등 특허출원과 관련된 모든 비정형 자료를 보관 · 비정형 데이터는 별도의 파일관리시스템********에 저장

저장방식 용량

****** 약 100T

<표 62> 특허넷의 비정형 데이터 확장자 목록

○ 시스템 기능 및 데이터 분석을 통한 관리단위 식별

대기능과 데이터(테이블) 매핑

· 특허출원 데이터의 생애주기가 길고, 각 대기능이 각 생애주기에 관여하고 있어서 각 대기능의 데이터들은 서로 밀접하게 연결되어 있음

<그림 90> 특허넷시스템 대기능과 데이터 매핑도

111

관리단위 : 특허넷시스템

· 시스템 기능 및 데이터 분석과정과 기능 및 데이터 매핑 분석과정을 통해 특허넷 시스템의 단위서비스가 관리단위로 식별됨

○ 보존기간

해외로부터 과거 특허 정보 제공이 요청되기도 하며 언제 어떤 정보가 요청될지 예측할 수 없기 때문에 사실상 영구보존으로 보아야 함

보존기간 설정 단위

· 데이터베이스 단위 영구 보존

마. 국토정보시스템

○ 조사 개요

조사 대상 시스템 : 국토정보시스템

관리기관 : 국토교통부

기관 시스템 담당 : 국토교통부

조사 추진 경과

· 1차 조사 (2017.7.6.) - 시스템 개요 조사 및 1차 조사표 작성

· 2차 조사 (2017.7.21.) - 데이터베이스 현황 조사 및 2차 조사표 작성

시스템 선정 배경

· 중앙·지방 연계시스템의 대표 시스템으로 선정

시스템 구축 배경

· 모든 국토정보를 관리하고 인터넷을 통해 대민 대국민 정보 제공 서비스를 하며, 법적근거에 의해 타기관에 자료를 제공

시스템 구축 연혁

· 2010년부터 전국의 부동산관련 속성 및 공간정보를 국내에서 유일하게 서비스하고 있음

112

년도 구축 내용

개별 구축 및 운영 1990.07 ~ - 지적정보시스템, 본부시스템, 구 토지대장시스템, 동산정보관리시스템, 2010.04 지적도면 통합시스템 구축(舊 행자부)

2008.08 ~ 시스템 통합 정보화 전략 수립 2008.12 - 국가공간정보센터 시스템 통합 ISP 수행

부동산관련 시스템 통합 사업 2009.04 ~ - 정보화 전략 수립에 따른 1단계 사업 실시(’10.05 국토정보시스템 서비스 2010.04 개시) 2010.08 ~ 시스템 기능 고도화 2016.12 - 공간정보와 부동산 정보를 융·복합 서비스 제공체계 구축

<표 63> 국토정보시스템 년도별 구축 내용

관련 법률

번호 법령

1 국가공간정보 기본법 2 공간정보의 구축 및 관리 등에 관한 법률 3 공간정보산업 진흥법 4 지적재조사에 관한 특별법 5 국가공간정보센터 운영규정 6 국가공간정보센터 운영세부규칙

<표 64> 국토정보시스템 관련 법률

○ 시스템 현황

시스템 목적

· 토지대장, 건축물대장, 지적도 등 부동산정보 융복합을 통한 종합정보를 인터넷을 통해 대국민 서비스를 하며, 법적근거에 의해 타기관에 자료를 제공

시스템 사용자

· 국토교통부 (170여명) 및 지방자치단체 및 연계기관 (4,500여명)

시스템 구성

· 개별적으로 운영 중이던 부동산관련 6개 시스템을 통합하여 중복투자를 방지하고 전국 단위의 통합DB 관리를 통하여 부동산정보의 효율적 관리 및 공동 활용, 고품질의 정책정보 제공 · 주요 기능 : 통합부동산정보 제공, 정책정보 제공 , 공공사업 보상 업무 지원, API 서비스, 스마트국토정보

113

<그림 91> 국토정보시스템 서비스 구성도

시스템 서비스

· 부동산 정보 조회 : 지적도 기반의 토지, 건물 등 부동산 정보를 조회

- 지적도, 토지대장, 건축물 대장, 공시지가 등 부동산 정보 조회 등 · 정책정보 제공 : 부동산 정보 제공 - 3억3천만 필지 (기준 : 2015년 정보 제공 실적)

- 토지소유현황, 국유재산 실태, 기초생활 수급 대상자, 공직자 재산조회 등

· 공공사업 보상업무 지원 : 정확한 보상정보를 실시간 제공(2011년 7월 서비스 실시)

- 지적도를 기준으로 토지대장, 건축물대장, 가격정보 등 보상 기본정보 제공 · 스마트 국토정보시스템 운영：스마트 폰을 활용하여 지번, 지목, 공시지가 등 20여 가지 정보 제공

- ‘m.nsdis.go.kr’의 web서비스와 안드로이드, iOS 기반 App 서비스

· 공개API 서비스 : 센터 보유정보를 중앙부처 및 지자체간 온라인 정보 공유 체계 구축

- 국토정보 제공에 따른 중복 개발 방지를 통한 예산 절감 및 표준화 가능

주요 하드웨어 현황

· 정보통합전산센터(대전) : 서버(WEB/WAS/DB) **식, 스토리지 *식

· 정보통합전산센터(광주) : 서버(WEB/WAS/DB) *식, 스토리지 *식

소프트웨어 운영 현황

114

S/W 용도 제품명 수량

**************************** ******************************** ***************************** 공간엔진 ****************************s 각 1식 *************************************************** **************************** - Up to 8 Cores ****************************** - Up to 4 Cores(SDE) OLAP *********** 1식 ETL ********* 1식 모니터링툴 ************* 1식 문서보안 ********* DRM 1식 레포팅툴 ******* 1식 암호화 ******** 1식

<표 65> 국토정보시스템 소프트웨어 운영 현황

○ 시스템 기능 조사 결과 분석

기능 구조

<그림 92> 국토정보시스템 연관 시스템(국가공간정보센터)

115

<그림 93> 국토종합시스템의 시스템 연계 및 자료 제공 현황

○ 데이터베이스 및 데이터 구조 조사 결과 분석

데이터베이스 현황

구분 DBMS 수량

국토정보SDW ********** 2식 국토정보통합DB ********** 1식 연계서버대장 ********** 1식 지적도면통합DB ********* 1식 KLIS 취합 ********** 1식 KLIS DB ********** 1식

<표 66> 국토정보시스템 전체 DBMS 현황

· 국토정보시스템에 수개의 DBMS가 있으나 현재 국토정보통합DB를 국토정보시스템의 주 데이터베이스로 운용

· DBMS환경 내 단일 데이터베이스로 구성하여 상시적으로 운용되고 있으며, 2017년 현재 데이터베이스 용량은 5T정도 이며, 현기준 증가 추세를 반영한 년간 증가량 추정치는 약 51G로 예상되고 있음

116

DBMS ********* Database 개수 1개

원천자료(1,119종) : 약 3TB 현재 용량 DW/DM (177종, 108개테이블) : 약 400GB 년간 증가량 약 51GB DW/DM 백업분 (277종) : 약 1.5TB

<표 67> 국토종합시스템 데이터베이스 현황

· 개인정보 : 존재 (******* 암호화하여 저장)

· 정보공개 정책 및 청구 내역 : 없음

· 공공 데이터 포털에 공개 여부 : 없음

원천자료 현황

· 건수 : 10,268,544,371 건

· 용량 : 4,787,941 MB

테이 관리기관 시스템 생산위치 데이터 건수 비고 블수

국토정보시스템 21 시도 134,773

부동산거래관리시스템 8 시군구 12,569,607 국토교통부 부동산종합공부시스템 1078 시군구 9,874,328,644

산업입지정보시스템 4 국토교통부 4

국립농업과학원 농업관리시스템 1 국립농업과학원 64

국립해양조사원 종합해양정보시스템 1 국립해양조사원 312

수지지형도관리시스템 12 국토리지정보원 151,050

영상관리시스템 1 국토리지정보원 17,713 국토지리정보원 국토공간영상정보시스템 1 국토리지정보원 530

연속수치지형도시스템 1 국토리지정보원 84

산림청 산림재해통합관리체계 10 산림청 1,895,123

조달청 국유재상조사관리시스템 1 조달청 30,335

한강홍수통제소 하청관리지리정보시스템 2 한강홍수통제소 2

한국감정원 감정평가시스템 2 한국감정원 7,706,520

한국농어촌공사 농지정보시스템 15 한국농어촌공사 66,546,137

한국도로공사 Hi-토지시스템 1 한국도로공사 521,431

117

테이 관리기관 시스템 생산위치 데이터 건수 비고 블수

국가수자원관리종합정보 한국수자원공사 2 한국수자원공사 430 시스템

해양수산부 연안관리정보시스템 7 해양수산부 12

행정자치부 주민등록시스템 11 시군구 304,622,930

환경부 환경지리정보시스템 7 환경부 550

수치지형도관리시스템 1 14개 시군 17,065 지자체 공간정보시스템 4 제주도 1,050

<표 68> 국토정보시스템 원천자료 현황

데이터웨어하우스 현황

· 원천 데이터를 기반으로 총 11개의 데이터웨어하우스를 구축하여 각종 정책 등의 기반자료로 데이터를 제공

테이블설명 물리 테이블명

토지임야기본 *******

토지임야소유권 *******

지적기본통계 *******

소유권변동정리상황 *******

민원처리상황 *******

토지이용정리상황 *******

지적공부등록지현황 *******

주민번호 Filter작업 ************

건물 *******

건물세부용도 *******

건물소유 *******

<표 69> 국토정보시스템 데이터웨어하우스 현황

데이터마트 현황

· 각 항목별로 지역(전국, 시군구) 및 건물별(건물, 주택, 아파트) 구분하여 생산, 관리하 며 아래는 항목만 조사

118

국가기관별 소유현황 세대별과다소유현황

토지기본정보 개인별거주지별건물보유현황

토지지목변동내역 개인별건물소유분포

지목변동추이분석 개인별과다소유현황

개인별과다보유현황 개인별주택소유분포

개인별토지소유분포 개인별주택소유현황_아파트

연령대별소유현황 거주지별주택소유상세

연령십세대별소유현황 세대별거주지별건물보유현황

거주지별토지소유현황 세대별건물소유분포

거주자별토지분포현황 무주택세대의 세대주 연령별 현황

개인별토지소유분포 주택수별 세대주의 연령현황

세대별과다보유현황 세대별주택소유분포

세대별토지소유분포 주택수별 세대주의 연령현황

토지소유기관수 세대별주택소유분포

건물소유현황 세대별주택소유현황

개인별과다소유현황 주택수별 세대주의 연령현황

개인별건물소유분포 주거용 건물의 주택유형별 주택수 현황

개인별거주지별건물보유현황

<표 70> 국토정보시스템 데이터마트 현황

원천 자료 수집 수기 및 수집 데이터

관리기관 시스템 수집 주기 수집 데이터 형식

국토정보시스템 실시간 DB

부동산거래관리시스템 매월 DB 국토교통부 부동산종합공부시스템 실시간 DB

산업입지정보시스템 변경발생시 파일

국립농업과학원 농업관리시스템 변경발생시 파일

국립해양조사원 종합해양정보시스템 변경발생시 파일

119

관리기관 시스템 수집 주기 수집 데이터 형식

수지지형도관리시스템 변경발생시 파일

영상관리시스템 변경발생시 파일 국토지리정보원 국토공간영상정보시스템 변경발생시 파일

연속수치지형도시스템 변경발생시 파일

산림청 산림재해통합관리체계 매일 DB

조달청 국유재상조사관리시스템 매월 DB

한강홍수통제소 하청관리지리정보시스템 변경발생시 파일

한국감정원 감정평가시스템 매월 DB

한국농어촌공사 농지정보시스템 매월 DB

한국도로공사 Hi-토지시스템 2개월 DB

한국수자원공사 국가수자원관리종합정보시스템 변경발생시 파일

해양수산부 연안관리정보시스템 변경발생시 파일

행정자치부 주민등록시스템 매월 DB

환경부 환경지리정보시스템 변경발생시 파일

수치지형도관리시스템 변경발생시 파일 지자체 공간정보시스템 변경발생시 파일

<표 71> 국토정보시스템 원천자료 수집 주기 및 수집 데이터 형식

데이터베이스 스키마 분석

· 컬럼 분석과정중 비스칼라 데이터로 판단되는 타입을 원천데이터에서 발견하여 확인

· **********(256) datatype · 위 데이터타입에 는 모든 공간데이터를 저장하고 있음을 확인

시스템명 엔터티, 어트리뷰트 테이블.컬럼

*************** ********************** 부동산종합공부 **************** ******************* 시스템 ********** *********************

<표 72> ***********데이터유형 사용 예시

테이블 관계 분석 및 테이블 그룹 도출

· 원천데이터 : 물리적으로는 테이블간 연관관계가 없음

· 데이터웨어하우스 : 각기 독립적

120

· 데이터마트 : 각기 독립적

데이터 관점 관리단위 판단

· 원천데이터, DW, DM 의 테이블세트가 모두 독립적으로 구성되어 있어서 논리적 판 단을 통해 관리단위를 도출하는 것이 바람직

비정형 데이터 보유 현황

· 구토지대장 이미지파일(cmp, tif) : 약 1.2억건 (색인기준)

· 게시판

이미지 문서 압축파일 기타 pdf 합계 (jpg,png) (doc,hwp,txt,ppt) (zip,egg) (cer,wmf)

25 55 12 16 3 111

<표 73> 국토정보시스템 게시판내 비정형 데이터 현황

○ 시스템 기능 및 데이터 분석을 통한 관리단위 식별

대기능과 데이터(테이블) 매핑

· 원천데이터, 데이터웨어하우스와 데이터마트는 모두 독립적인 테이블세트를 보유하고 연관관계가 없음

<그림 94> 국토정보시스템 대기능과 데이터 매핑도

관리단위 1안 : 데이터웨어하우스, 데이터마트

· 시스템 기능 및 데이터 분석과정과 기능 및 데이터 매핑 분석과정을 통해 데이터 웨어하우스와 데이터마트로 관리단위를 식별할 수 있음

121

관리단위 2안 : 11종의 개별 데이터웨어하우스, 데이터마트

· 데이터웨어하우스의 중요도 상대적으로 높으므로 데이터웨어하우스의 개별 데이터를 관리단위로 관리하여 11종의 데이터웨어하우스와 데이터마트, 총 12종의 관리단위를 식별할 수 있음

○ 보존기간

토지의 존속기간이 영구적이기 때문에 국토정보 원천 데이터베이스는 영구 보존

데이터웨어하우스와 데이터마트 데이터베이스에 대하여 폐기 필요가 발생하지 않았기 때문에 보존기간에 대하여 검토하지 않았었음. 토지대장 변경 시 기존 데이터를 남기지 않고 수정하기 때문에 특정 시기의 국토정보 현황을 알 수 있는 기초 자료로서 유일하므로 영구 보존이 적합함

바. 화학물질종합정보시스템

○ 조사 개요

조사 대상 시스템 : 화학물질종합정보시스템

관리기관 : 환경부 화학물질안전원

기관 시스템 담당 : 화학물질안전원 공업연구관

조사 추진 경과

· 1차 조사 (2017.7.11.) - 시스템 개요 조사, 데이터베이스 조사 및 1차 조사표, 2차 조사표 작성

시스템 선정 배경

· 중앙집중형의 대표 시스템으로 선정

시스템 구축 배경

· 관련법(화관법,화평법)에 근거하여 대국민 화학물질 정보제공 및 화학물질과 관련된 모든 온라인 민원접수 및 처리

시스템 구축 연혁

년도 구축 내용

2014 전자문서처리시스템 구축

2015 관세청연계 등 부가기능 구축

2016 화학물질 종합정보시스템 포털 구축

<표 74> 화학물질정보시스템 년도별 구축 내용

122

관련 법률

번호 법령

화학물질의 등록 및 평가 등에 관한 법률 (법률 제11789호, 2013.5.22 제정, 2015.1.1 1 시행)

2 화학물질관리법 (법률 제12490호, 2014.3.18 타법개정, 2015.1.1. 시행)

<표 75> 화학물질정보시스템 관련 법률

○ 시스템 현황

시스템 목적

· 관련법인 화학물질관리법(이하 화관법), 화학물질의 등록 및 평가 등에 관한 법률 (이하 화평법)에 근거하여 대국민 화학물질 정보제공 및 화학물질과 관련된 모든 온라 인 민원접수 및 처리

시스템 사용자

· 환경부 직원 100여명, 화학물질취급업체 22,600곳 등 총 22,700여명이 사용 · 내부 직원 사용 시스템 외 대국민 서비스 포털과 민원 시스템 운영

업무 내용

· 화평법을 근거로 화학물질의 체계적 관리와 화학사고 예방을 위해 화학사고 현황 등 관련정보 제공과 화학물질 안전관리, 화학물질정보, 사고이력, 배출량을 조사

시스템 서비스 내용

· (국민) 화학물질 종합정보시스템 대국민 포털

· (기업, 정부) 화관법 민원처리를 위한 화학물질안전관리행정시스템 · (기업, 정부) 유해화학물질 운반계획서

· (정부) 유해화학물질 제조수입자의 사후관리에 관한 업무를 처리하기 위한 수입관리시스템

· (국민, 기업) 화학물질안전 관련 시스템 통합

· (기업, 정부) 화관법 안전관리 업무지원시스템

123

<그림 95> 화학물질종합정보시스템 구성도

연계 시스템

· 화학물질종합정보시스템은 환경부내 화학안정정보공유시스템 등 4개 시스템으로부터 데이터를 주기적으로 이관하여 데이터를 축적하고 있으며 수입신고와 관련하여 관세청과 데이터를 연계하고 있음

주기적 수작업 화학안전정보공유시스템(CSC) > 사고이력정보 export/import

화학물질사고대응정보시스템(CARIS) > 주기적 수작업 화학물질대응 정보 export/import

입수 화학제품응급대응정보시스템(CEIS) > 화학제품 주기적 수작업 응급대응정보 방법 export/import 정보

화학물질안전관리정보시스템(KISChem) > 주기적 수작업 화학물질 export/import

관세청 > 수출입 신고자료 FTP 통신(xls)

관세청 > 수입요건확인서 결과 HTTP통신(ebXML)

관세청 > 수입신고허가정보, 수입위반업체 FTP 통신(xls) 입출 방법 정보 관세청 > 수입요건 확인서 HTTP통신(ebXML)

<표 76> 화학물질종합정보시스템 연계 데이터 현황

124

주요 하드웨어 현황

· 해당 시스템은 G-Cloud환경에 구축되어 있음

위치 목적 수량 비고

WEB서버 4식 포털 2식+민원24 2식

WAS서버 4식 포털 2식+민원24 2식 인터넷망 DB서버 4식 포털 2식+민원24 2식

메일/지도서버 1식

WEB서버 2식

행정업무망 WAS서버 2식

DB서버 2식

<표 77> 화학물질종합정보시스템 주요 하드웨어 목록

소프트웨어 운영 현황

S/W용도 제품명 설치시스템 수량

OS ************* 전체 서버 19 Web Server ***** 전체 WEB서버 6 WAS ***** 전체 WAS서버 6 웹구간암호화 ****************** 전체 WEB서버 6 ************ 민원24 +행정업무 WAS서버 4 DATA 암호화 ***** 전체 DB서버 4 웹리포팅 ********* 민원24 +행정업무 WAS서버 4 문서위변조방지 ************ 민원24 WAS서버 2 ********************* 민원24 WEB서버 2 ******************* 민원24 WAS서버 2 PKI인증 ********** 행정업무 WEB서버 2 ************* 행정업무 WEB서버 2 백업 ************ 전체 서버 19

<표 78> 화학물질종합정보시스템 소프트웨어 현황

125

○ 시스템 기능 조사 결과 분석

주요 프로세스

<그림 96> 화학물질종합정보시스템 민원 업무 흐름도

기능 구조

<그림 97> 화학물질종합정보시스템 민원 업무 메뉴 구조도

126

기능 관점 관리단위 판단 (1안)

· 기능 구조 및 인터뷰를 통해 구분 가능한 기능은 크게 ①민원과 ②화학물질정보 ③사고이력 등 3개의 관리단위 분리할 수 있음

기능 관점 관리단위 판단 (2안)

· 2안의 ‘민원’ 단위를 현재 오픈 기준으로 ‘수입신고 관리’과 ‘운반계획서 관리’로 나눌 수 있어 ①수입신고 민원과 ②운반계획서 민원 ③화학물질정보 ④사고이력의 관리단위를 도출할 수 있음

· 그러나 시스템 내 미구축된 민원서류까지 합치면 총 73종(이중 민원인 작성 37종)이 존재하며 순차적으로 데이터 구축 예정이므로 이와 같이 관리단위를 세부화할 시 관리단위 개수 증가로 관리 부담이 커질 것으로 예상됨

○ 데이터베이스 및 데이터 구조 조사 결과 분석

데이터베이스 현황

· DBMS 환경 내 단일 데이터베이스로 구성하여 상시적으로 운용하고 있으며, 2012년 이후 축적된 데이터베이스 용량은 600M로 산술적으로 년간 120M정도 증가하고 있으나, 현 기준 증가 추세를 반영한 년간 증가량 추정치는 약 200M로 예상됨

DBMS ******** Database 개수 1개

현재 용량 329G 년간 증가량 -

<표 79> 화학물질종합정보시스템 데이터베이스 현황

개인정보 : 포함(민원24 사업장 회원 가입 정보)

· 정보공개 정책 및 청구 내역 : 없음

· 공공 데이터 포털에 공개 여부 : 없음

엔터티명 레코드수 비고

화학물질 안전정보 67,000 변동이 거의 없음

사고이력 600

민원 57,000

<표 80> 주요 테이블의 레코드 수

데이터 분산 및 연계 분석

· 민원24와 행정업무 DB는 분산트랜젝션 기술로 동기화하고 있음

· 화관법상 73종의 민원문서중 현재 3~4종이 시스템으로 구성되어 있음

· 사고이력시스템(CSC내 존재)과 현재 주기적으로 데이터를 동기화 하고 있으나, 추후

127

사고이력시스템을 본 시스템으로 통합 예정

테이블 관계 분석 및 테이블 그룹 도출

· 마스터 테이블에 위치하는 데이터는 회원, 사업장, 코드, 공통민원 정보, 화학물질, 사고이력으로 식별

· 이중 회원, 사업장, 코드는 관리 제외 대상이므로 공통민원, 화학물질, 사고이력이 명료하게 서로 분리되어 있음을 확인

· 운반계획서, 수입신고 등의 민원은 민원인정보, 처리결과 등 중복되는 요소로 인해 상위 레벨의 공통민원정보 테이블을 두고 서로 공유하고 있음

<그림 98> 화학물질종합정보시스템 ERD중 일부

비정형 데이터 보유 현황

· 서비스를 오픈한 지 6개월 미만으로 비정형데이터는 운반계획서외에는 식별되지 않았으며, 용량도 무의미한 수준임

유형 포맷

***** Excel

기타 첨부파일 jpg, gif, png, zip, hwp, xls, xlsx, ppt, pptx, doc, docx, txt, pdf

<표 81> 화학물질종합정보시스템의 비정형데이터 유형

○ 시스템 기능 및 데이터 분석을 통한 관리단위 식별

대기능과 데이터(테이블) 매핑

128

· 화학물질정보, 사고이력, 민원데이터는 서로 데이터가 연관되어 있지 않음 · 운반계획서, 수입신고 데이터는 공통민원테이블을 공유하고 있어 하나의 관리단위로 구별하는 것이 바람직

<그림 99> 화학물질종합정보시스템 대기능과 데이터 매핑도

관리단위 : 화학물질정보, 사고정보, 민원

· 시스템 기능 및 데이터 분석과정과 기능 및 데이터 매핑 분석과정을 통해 화학물질정보, 사고이력, 민원으로 관리단위를 식별

○ 보존기간

· 화학물질은 영구히 존재하므로 화학물질정보는 영구

· 화학물질관리법상에는 유해물질 취급 관련 민원 서류는 5년에 해당

3.5. 데이터세트 조사 분석 결과 시사점

가. 행정정보 데이터세트 조사 결과 요약

기관

산림자원통합 국민신문고 전자연구노트 국토정보 화학물질종합 시스템 특허넷 관리시스템 시스템 시스템 시스템 정보시스템

운영자 산림청 국민권익위원회 한국과학기술원 특허청 국토교통부 화학물질안전원

산림청 본청, 국민 지차체 산하 5개 지방청 원내 교수, 특허청 진직원 환경부 이용자 연계기관 국토교통부 및 소속 학생, 연구원 국민(출원인) 국민(민원인) 민원처리 담당자 일부 공공기관 국유림관리소 2016 2015 (2009년 구축 (연차사업으로 구축년도 2012 2006 1999 2010 시스템 전면 2019년까지 재구축) 구축예정)

129

기관

산림자원통합 국민신문고 전자연구노트 국토정보 화학물질종합 시스템 특허넷 관리시스템 시스템 시스템 시스템 정보시스템 정부에 대한 모든 국토정보를 관련법(화관법, 모든 관리하고 화평법)에 민원·제안·신고 인터넷을 통해 근거하여 대국민 국유림 대상 와 정책토론 연구과제 수행 특허행정(출원- 대민 대국민 화학물질 사업(조림/숲가 등을 인터넷으로 중 작성하는 심사-등록-심판) 업무 정보 제공 정보제공 및 꾸기/벌채/매각 간편하게 연구성과를 을 전체적으로 서비스를 하며, 화학물질과 사업) 관리 신청하고 등록 관리 관리함 법적근거에 의해 관련된 모든 처리하는 범정부 타기관에 자료를 온라인 민원접수 대표 온라인 제공 및 처리 소통 창구

대기능

포함(민원24 포함(민원신청인 포함 (연구 포함(출원인 포함(소유주 개인정보 없음 사업장 회원 , 민원 내용) 내용 중 가능) 정보) 정보) 가입 정보) DBMS ********** ********** ****** ********** ********** ********

원천데이터 3T DB크기 600M 1.2T 2T 15T DW/DM (400G, 329G 백업 15.T)

테이블수 188개 696개 20개 1,560개 108개 90개

사업장정보,공통

타 대기능에서 출원데이터를 코드,민원공통정 대기능별 사용 연구과제를 108개 테이블이 생성한 데이터를 기준으로 보외 주요 물리 테이블 중심으로 연계(13종의 이용하여 처 대부분의 정보는 독립적인 분리 연구노트가 연관 DW, 164종의 리 테이블이 연계 테이블에 저장 대기능과 DM으로 구성) 테이블 매핑

130

기관

산림자원통합 국민신문고 전자연구노트 국토정보 화학물질종합 시스템 특허넷 관리시스템 시스템 시스템 시스템 정보시스템 민원, 국민제안, 공무원제안, 데이터 산림자원관리 데이터웨어하우 화학물질정보, 정책토론 연구노트 특허넷시스템 세트 사업 스,데이터마트 사고정보, 민원 예산낭비신고, 공익신고

<표 82> 행정정보 데이터세트 조사 결과 비교

나. 관리단위 식별을 위한 데이터 모델 분석 필요성

○ 현황

기능 분석후 도출한 대기능에서 사용되어지는 데이터베이스의 테이블이 서로 의존 관계가 존재하거나 특정 테이블을 공유하는 경우가 존재

이에 기증 분석에서 도출한 대기능이 서로 물리적으로 분리할 수 없는 단위로 판별

<그림 118> 기능분석과 데이터 모델 분석 시 관리단위 도출 예시

○ 관리 방안

관리단위는 기능 분석 후 도출한 대기능에서 데이터베이스 물리구조를 분석하여 서로 독립적으로 분리가 가능한지 판별하여 도출하여야 함

시스템에서 데이터 보유 기간 동안 지속적 모니터링과 변경 이력 관리가 가능하려면 물리적인 구조에 필연적으로 의존하기 때문

131

다. 활용 목적 복사 데이터의 관리 주체

○ 현황

데이터 생성, 수정 권한을 갖는 데이터 생산자와 데이터 관리자가 불일치하는 경우가 존재

빅데이터 분석 및 공공데이터 활용 증가에 따른 데이터 제공이 증가

시스템 연계에 의한 데이터 유통이 증가

<그림 119> 원천데이터를 통한 참조 서비스 예시

○ 관리 방안

원천 데이터를 생산 및 관리하는 행정정보시스템에서 데이터세트를 정의하여 관리하도록 함

타 기관 시스템에서 생산한 데이터를 복사하여 참조하거나 활용하는 시스템의 경우는 데이터 기록관리 여부는 활용 기관이 결정하도록 함

동일 법령에 근하여 생산된 데이터는 관리 시스템에 상관없이 동일하게 관리하고 처분되어야 함

라. 데이터 생산기관과 관리기관 불일치 기록의 관리 주체

데이터 생성, 수정 권한을 갖는 시스템 사용자와 데이터 운영자 불일치하는 경우로서 전형적인 사례가 국민신문고의 민원 시스템이 해당

132

<그림 120> 국민신문고 민원 데이터세트에 대한 생산기관과 관리기관 불일치 사례

시스템 연계에 의한 데이터의 유통이 증가하고 있기 때문에 데이터세트에 대한 처분권을 소유한 기관을 판별하기 어려운 사례가 증가할 것으로 예상됨

데이터세트에 대한 처분권이란 관리 권한이며 이를 생산기관에게 줄 경우 데이터베이스를 논리적으로 분리해야 해야 하거나 추출해야 됨. 이는 현실적으로 관리기능을 생산시스템이나 기록관리시스템에 시스템별로 구현해야 하는 신규 및 수정 개발의 부담은 물론 관리 프로세스를 복잡하게 하여 현실적으로 실현이 어려움

따라서 동일 법령에 근거 생산된 데이터는 시스템과 상관없이 동일하게 관리 및 처분하는 원칙 하에 데이터세트의 관리 시스템에서 관리기관에게 관리와 처분의 권한을 주어야 함

그러나 다른 목적, 다른 업무 상 달리 관리되어야 할 경우 관리권을 가진 시스템에서 결정하도록 함

마. 데이터 처분 정책에 대한 인식

○ 현황

행정정보시스템의 운영 기관에서 보존기간 정책 수립의 필요성이 제기된 경우가 거의 없음. 그 이유는 다음과 같음

· 조사대상 행정정보시스템 보유 데이터의 나이가 30년 이하 · 스토리지, 네트워크 등 하드웨어 비용 감소로 인해 데이터 유지 비용이 감소

· 민간정보시스템의 Petabyte 용량수준 대비 행정정보시스템은 Terabyte 용량

보존기간이나 폐기를 검토하지 않은 이유 중 가장 주요하게는 데이터세트 특성상 폐기 없이 계속 보유해야 하는 경우가 다수이기 때문

· 계속 수정되어야 하는 데이터 특성상 처분 계획이 불필요

133

· 데이터는 확정되었으나 계속 참조 요구가 있는 데이터도 존재

○ 관리 방안

데이터 처분 정책에 대한 인식 제고 필요

· 모든 데이터세트는 새로운 데이터가 등장하는 생성 시점과 데이터 확정 시점(수정 불가 시점)이 존재함. 각 시스템 별 생성과 확정의 정의 및 방법과 시점이 다르므로 데이터세트의 기록관리 정보 중에 보존기간의 기준을 정의해야 함 · 확정 시점 이후 수정은 명시적인 수정 기능을 통하여 수정 일시, 수정자, 수정 방법에 대한 이력정보를 기록해야 함

데이터세트의 메타데이터로 처분 일정 정의

· 데이터세트 복사, 축적, 유통시 처분 계획을 메타데이터로 첨부하여 관리하게 함

· 정보화 계획, 시스템 기획 시 기록관리 계획을 같이 수립할 필요가 있음

바. 관리단위 내 보존기간

○ 현황

동일 관리단위(단위기능) 내 보존기간이 상이한 경우가 존재

· 보존기간과 관련한 법규 및 정책에 따라 관리단위별로 동일한 보존기간을 적용할 수 없는 경우가 존재함

· 예를 들면 민원시스템의 경우 일반민원은 10년, 고충민원은 준영구로 민원유형에 따라 상이하건, 연구노트는 30년이나 보고서류의 연구노트는 10년

<그림 121> 동일 관리단위(단위기능)내 보존기간이 상이한 사례

관리단위란 관리 대상으로 식별하고 정보를 등록하는 단위이며 관리 행위(이관, 보존, 페기 등) 를 가하는 최소의 단위

단위기능을 관리단위로 설정할 때 일부 데이터세트는 단위기능 중 조건에 따라 추출하여 폐기해야 됨. 즉 단위기능이 폐기의 단위가 되지 못 하기 때문에 최소 단위라는 단위기능 정의와 모순 발생

134

○ 관리 방안

동일 관리단위(단위기능)내 종류, 유형별 보존기간을 달리 적용할 수 있는 방법이 필요

단위기능 내에 다른 처분 단위가 존재하는 경우는 3가지 형태가 있을 수 있음.

· [형태1: 동일 테이블 내 다른 조건] 1개 테이블의 특정 컬럼값에 따라 해당되는 레코드/ROW가 다른 경우. (예: 한국과학기술원의 전자연구노트, 권익위 신문고 민 원)

· [형태2: 비독립적 별개 테이블1] 서로 다른 테이블의 데이터이나 같은 테이블과 의존관계에 있는 경우

· [형태3: 독립적 별개 테이블2] 서로 다른 테이블의 데이터이고 직접적으로는 공유 테이블이 없으나 간접적으로 공유하는 테이블이 존재하는 경우. [형태2]와 결국 같은 형태라고 볼 수 있음

· [형태4: 독립적 별개 테이블] 서로 다른 테이블의 데이터이고 공유하는 테이블도 없는 경우

<그림 122> 형태1: 동일 <그림 123> 형태2: <그림 124> 형태3: <그림 125> 형태4: 테이블 내 다른 조건 비독립적 별개 테이블1 비독립적 별개 테이블2 독립적 별개 테이블

· 단위기능 식별 시 처분 조건을 고려하여 1개 단위기능의 보존기간도 일치하도록 식별해야 함. [형태4: 독립적 별개 테이블] 의 경우 단위기능을 분리하여 단위기능과 처분조건이 일치시키도록 함

<그림 126> 단위기능 분리

135

단위기능을 분리할 수 없는 [형태2]는 [형태3]과 같은 이유이므로 처분단위와 단위기능의 불일치 경우는 동일 데이터 구조이나 데이터 내용이 다른 [형태1]과 다른 구조와 다른 내용의 [형태2]로 좁혀지며, 두가지 경우 모두 단위기능을 분리할 수 없음

단위기능 대 처분단위

· 처분단위와 단위기능이 일치시키지 않으면 단위기능이 최소 관리단위라는 정의에 모순

· 단위기능보다 세분화된 처분단위를 최소 관리단위로 설정하면 복잡한 구조와 대량의 데이터세트를 쉽게 관리하기 위해 도입한 단위기능의 목적에 위배됨

처분단위를 관리단위로 설정 시 문제

· 현장조사한 시스템 6개 중 4개의 단위기능이 데이터베이스 전체로 식별되었고, 처분단위와 단위기능의 불일치가 발생한 시스템(전자연구노트, 민원)도 데이터베이스가 단위기능으로 식별되었음. 즉 이들 시스템에서 처분단위가 물리적으로 분리되지 않음

· 대부분의 시스템에서 처분단위의 수준은 레코드 수준일 것으로 예상됨. 레코드 수준 관리단위는 데이터세트 관리체계 적용을 어렵게 함

관리단위는 단위기능으로 정하고, 데이터세트 관리기준표의 기록정보 중 보존기간 및 처분 정책 항목에서 “처분단위” 항목을 추가하여 처분 조건을 명시하는 방안이 바람직

처분단위의 예는 다음과 같음. 각 처분단위별로 보존기간, 기산일, 검색조건, 책정사유, 처분방법을 기술하도록 함

처분 단위 보존기간 설명

1 단위기능 영구 단위기능과 처분단위가 일치하는 경우

(1) 일반민원 10년 2 보존기간이 다른 2개의 처분 단위 (2) 고충 준영구

(1) 연구노트 30년 3 보존기간이 다른 2개의 처분 단위 (2) 연구보고서 10년

<표 83 >처분 단위의 사례

사. 보존기간 기산일

○ 현황

현행 전자문서의 기산일은 “기록물의 처리가 완결된 날이 속하는 다음 연도의 1월 1일”이나 데이터세트는 기산일 기준으로 데이터생성일 또는 데이터처리종결일을 검토할 수 있음

데이터 생성일이란 해당 데이터가 단위기능에 최초 입력되어 저장된 일시이고, 데이터 종결일이란 해당 데이터를 처리한 뒤 더 이상의 수정이 금지된 일시

데이터세트 생성일을 기산일 기준으로 정할 시 데이터세트의 특성 상 생성일 이후 처리

136

기간이 필요하고 오랜 기간 수정이 일어날 수 있음에도 보존기간 도래로 폐기하여 필요한 데이터가 유실되는 결과를 초래. 예를 들어, 보존기간이 1년인 단위기능에서 2017년 12월 31일 생성된 데이터는 다음날이 기산일로서 2018년 보존기간이 만료됨. 이 기간 업무 프로세스는 계속 진행되어 이 데이터는 2019년에도 수정되어야 하는 경우 데이터 운용 기간과 보존기간이 불일치하여 운용 기간 중 보존기간이 도래하는 경우가 발생할 수 있음

데이터세트 종결일을 기산일 기준으로 정할 시 데이터세트의 종결일은 모든 시스템에서 정의가 다르고 시점이 다름. 명확한 경우의 예는 산림사업(사업 정산일), 민원(민원 답변일), 전자연구노트(프로젝트 완료일)이며, 종결일을 정의할 수 없는 데이터세트의 예로 토지대장, 화학물질정보은 데이터의 종결이 없는 업무이기 때문에 종결일 정의가 불가함

또한 데이터세트의 논리적 단위로 발생 건(예: 민원 1건, 화학물질 1개)을 단위로 보존기간 산정 시 레코드별로 보존기간이 산정되어 평가 대상의 수가 관리 가능 범위를 초과하게 됨

○ 관리 방안

처리 완결일의 정의가 시스템별로 다르기 때문에 획일적으로 정할 수 없기 때문에 생성일을 기준으로 삼을 수 있으나 종결일 기준 시에도 문제가 있으므로 1가지로 정할 수 없음

따라서 시스템별로 기준을 생성일 또는 종결일을 정의하도록 하는 편이 현실적임

4. 행정정보 데이터세트 기록관리체계 설계

4.1. 데이터세트 기록관리체계 설계의 방향

○ 행정정보시스템과 데이터세트 조사 분석을 통하여 데이터세트 기록관리 기본 방향의 타당성을 확인하고 도출한 시사점을 기반으로 설계 기본 방향을 세움. 데이터세트의 생성부터 운용, 그리고 보존과 처분의 생애주기에서 활성 데이터로서 참조는 물론 변경이 가해지는 시기에는 데이터세트관리기준표를 도구로 하여 데이터세트에 관련된 정보와 관리 행위를 관리하고, 비활성화 단계로서 데이터 변경이 없고 참조되지 않는 보존 이후의 시기에는 생산기관에서 데이터세트 특성에 따라 자체 보존, 이관 보존, 폐기를 결정하여 시행하도록 함

○ 데이터세트 관리체계를 구현하는 추진력은 국가기록원과 생산기관이 모두 참여하는 협업 조직이며 국가기록원은 생산기관이 시스템 분석부터 보존까지 주도적으로 수행할 수 있도록 정보 및 보존 기술 전문 인력을 지원해야 할 것임

137

<그림 127> 데이터세트 기록관리 개념도

가. 생산시스템에서 관리

○ 현행 공공기록물관리는 기록관과 영구기록물관리기관으로 이관하여 관리하는 체계이나 데이터세트는 영구적인 생명주기와 크기로 인해 이관이 불가함

조사 분석 결과 생산시스템에서 지속적으로 참조해야 하는 데이터세트가 많았음. 산림자원통합관리시스템, 특허넷, 국토정보시스템, 화학물질종합정보시스템이 사례로서 기한 없이 데이터가 변경되거나 또는 종결된다 할지라도 계속적으로 참조 요구가 발생하여 생산시스템에서 계속 보유해야 함

시스템 운영 기간과 데이터세트의 데이터 타입에 따라 데이터세트 크기가 다르지만, 10년 이상 운영한 특허넷은 15T, 전국 토지 정보를 대상으로 한 국토정보시스템 데이터 웨어하우스와 데이터 마트가 과거 데이터 포함 2T에 이름. 이 크기의 데이터를 이관하기 위한 생산기관의 인적 자원 및 소요 시간과 물적 자원의 부담은 전자문서 이관과 비교할 수 없을 정도로 클 것이며, 이를 인수하는 영구기록물관리기관에서의 물적 자원 역시 시스템 증가에 따라 빠르게 증가할 것으로 예상됨

○ 데이터세트는 우선 생산시스템에서 관리해야 하는 타당한 사유가 있음. 따라서 기록관과 영구기록물관리기관에서 기록을 인수하여 관리하는 현행 관리체계는 데이터세트에 적용할 수 없으며, 대신 생산시스템에서 처분 없이 계속 관리, 또는 이관 없이 폐기하거나 보존할 수 있는 체계를 설계해야 함

138

○ 그러나 국가적 보존과 활용 가치가 있다고 판단되는 데이터세트는 중앙기록물관리기관이나 관할 영구기록물관리기관으로 이관할 수 있도록 방안을 마련해야 함

나. 관리 프로세스의 단순화

○ 기록물 종결 후 기록관으로 이관한 뒤 보존기간 30년 이상 기록물은 영구기록물관리기관으로 이관하는 현행 3단계 프로세스는 데이터세트의 경우, 영구 운용해야 하는 특성과 거대한 크기로 인해 시행이 불가함. 따라서 기록이 물리적으로 이관되는 현행 이관 프로세스는 생략되거나 간소화되어야 함.

○ 데이터세트는 현행 생산현황보고처럼 기록물철과 건 단위로 생산량을 파악할 수 없기 때문에 생산현황보고의 방법과 내용 역시 바뀌어야 함

○ 이와 같은 특성을 반영하여 이관과 물리적 이동을 최소화하는 프로세스로 관리체계를 설계해야 함

다. 생산기관 자체 관리

○ 생산시스템에서 관리와 프로세스의 단순화는 생산기관에서 생성부터 보존이나 폐기까지 관리하는 체계를 의미함. 생산기관의 관리 책임은 기관의 설명책임성을 강조하는 차세대 기록관리 개념 연구 결과에서도 제시된 바 있으며 데이터세트 관리의 방향과 일치함

○ 생산기관이 관리하기 위해서는 기록관리기준표의 역할을 하는 관리기준표가 필요함. 이 기준표는 데이터세트 기록관리의 기준을 명시함은 물론, 관리기준표를 근거로 기록관리 현황을 점검하고 개선하기 위한 생산기관과 영구기록물관리기관 사이의 매개체 역할을 하게 됨

○ 기준표와 함께 생산기관 주도의 프로세스가 설계되어야 하며 생산기관에서 쉽게 기준표를 현행화하고 실제 관리할 수 있어야 함

○ 기록관리의 주체로서 생산기관에게 권한과 책임을 부여되는 반면, 중앙기록물관리기관이 나 영구기록물관리기관은 관리 현황을 점검 및 감독하며 생산기관이 제 역할을 할 수 있도록 지원하는 관리체계가 필요함

라. 생산시스템의 다양성 수용

○ 모든 행정정보 시스템과 모든 데이터세트에 동일한 기록관리 기준과 속성을 적용하기 어려움을 조사 분석 과정 중 관리단위 추출 및 보존기간 설정에서 발견할 수 있음

관리단위의 형식과 내용은 시스템마다 달라서 데이터베이스 전체가 관리단위인 시스템 (산림자원통합관리시스템, 전자연구노트시스템, 특허넷), 일부 다수의 테이블인 시스템 (신문고, 국토정보시스템, 화학물질종합정보시스템)이 있음

관리단위 내에서도 보존기간이 다른 데이터세트도 있어 일반민원과 고충민원, 연구노트와 연구보고서는 데이터 모델로서는 분리할 수 없기 때문에 동일 관리단위로 식별되나 처분

139

일정을 달리 적용해야 함

○ 보존기간을 책정하려면 기산일이 정의되어야 하나 보존기간을 책정할 수 없는 데이터세트도 있으며, 책정할 수 있다하더라도 기산일을 개별적으로 정의해야 함

· 기산일을 정의하려면 생성일이나 처리 종결일을 정의해야 하나 데이터 자체를 종결할 수 없는 데이터세트로서 국토정보시스템의 토지대장, 화학물질종합정보시스템의 화학물질정보, 산림사업과 같은 데이터세트가 있음

· 처리 종결일은 데이터세트마다 달라서, 연구과제 완료, 민원 답변 완료와 같이 시스템 별로 정의해야 함

○ 현행과 같은 표준 프로세스와 데이터 규격, 기록관리기준을 동일하게 적용할 수 없음을 알 수 있으며, 데이터세트 관리 지침은 역할과 기본 원칙을 명시하고 각 시스템별 다양한 특성을 반영하여 개별적으로 정의하고 시행하는 관리체계여야 함

마. 수행 조직

○ 행정정보 시스템에 대하여 가장 잘 아는 생산기관과 기록관리 현황을 점검하고 보존 기술을 보유한 국가기록원과 같은 영구기록물관리기관이 협조해야만 정확히 데이터세트를 판별하여 기록관리기준을 세우고 지속적인 관리를 할 수 있음

본 조사 과정에서 보안 사유나 산출물이 현행화되지 않아 시스템의 개발 산출물을 이용할 수 없는 경우가 있었으며, 개발 산출물을 제공 받은 경우에도 생산기관 담당자의 인터뷰나 설명 없이는 산출물 이해에 장시간 소요되었음. 자료의 제공과 효율적인 이용을 위해서는 생산기관의 참여가 절대적으로 필요함

국가기록원은 다수의 행정정보시스템을 분석하고 관리한 경험을 보유하여 타 시스템과 비교 및 표준 방법론 적용이 가능하므로 국가기록원 참여 역시 필수적임

○ 시스템 조사 전에 예상한 바와 같이 데이터세트는 정보기술 의존성이 높기 때문에 정보기술 분야 전문가 참여가 필수적으로 다음과 같은 인력이 요구됨

시스템 구축 근거 법령 및 목적, 기능, 내역에 대하여 설명할 수 있는 생산기관 업무 담당자와 해당 시스템의 개발이나 유지보수 인력

데이터베이스 분석과 설계가 가능한 데이터 전문 인력, 보존정책에 대한 기술 지원을 해줄 보존기술 전문가, 시스템 개발 또는 정보화전략계획이 가능한 컨설팅 인력

○ 조사 과정에서 정보기술 인력이 기능 분석, 데이터 모델 분석을 절차대로 수행하였으나 기록관리 프로세스와 처분일정에 대한 이해가 부족하여 기록관리 항목 작성에 어려움이 있었음. 정보기술 전문가만으로는 데이터세트를 관리할 수 없으며 기록관리전문가가 참여해야 영구 보존까지 대비할 수 있음

○ 데이터세트 기록관리 조직으로 2개의 협력 축, 즉 생산기관 – 중앙기록물관리기관의 협력 축과 기록관리 전문가 – 정보기술 전문가의 협력 축을 구축할 수 있도록 관리체계를 설계하여야 함

140

4.2. 데이터세트 조사분석 방법론

가. 개요

○ 방법론 적용 범위

관리 대상 시스템이 결정된 뒤 시스템 조사와 분석 후 데이터세트 기준표를 수립 완료하는 단계에서 행정정보 데이터세트 기준표의 개발 방법임

○ 방법론 개요

본 방법론은 서면조사나 전산시스템 기반 조사를 통한 분석 방식이 아닌 ① ‘현장조사 주도 분석’을 특징으로 가지고 있으며, 각 분석단계를 폭포수형 단계식 진행을 통한 분석보다는 ② ‘나선형 점층식 분석’을 강조

또한 시스템 기능 관점, 데이터 관점 등 ③ ‘두 가지 관점에서 단위서비스를 분석’한 후 각 관점에서 관리단위를 도출하여 ④ ‘매핑 분석과정’을 통해 분석단계 관리단위를 도출함

<그림 128> 행정정보데이터세트 기준표 정의 절차

○ 현장조사 주도 분석

최근의 행정정보시스템은 기술의 발전과 더불어 수차례의 고도화를 통해 서비스의 복잡도가 증가하고 있어 관련 문서를 기반으로 분석하는 것은 양적, 질적 측면에서 한계가 있음. 또한 시스템 관련 산출물이 해당 시스템을 정확히 기술하지 못하고 있거나 현행화가 안되어 있는 경우도 있으며, 시스템별로 상이한 양식과 항목을 가지고 있음

141

충분한 사전조사를 거쳐 해당 기관의 업무 담당자, 기록연구사, 시스템 담당자 등과 인터뷰와 산출물에 대한 설명을 듣고, 산출물 내 필요한 분석자료의 최적의 접근 방법을 판단하여 분석을 진행함

○ 나선형 점층식 분석

현장조사에서 도출한 자료와 협조 받은 자료를 기반으로 분석을 진행하고 해당 분석의 내용이 해당 시스템과 일치하는 지와 추가적인 조사 항목을 가지고 현장을 방문하여 확인함. 분석 자료가 어느 정도 목적한 바에 다다를 때까지 조사, 분석을 반복하여 분석의 질을 높임

○ 분석의 두 가지 관점

해당 시스템을 분석하는 관점은 수가지가 존재하지만, 분석이 현실적으로 가능한 측면과 효율적인 측면을 고려하였을 시 행정정보 데이터세트 기준표 작성에 가장 적합하고 빠른 관점은 ①기능적 관점과 ②데이터 관점으로 판단하여 관점을 축소시킴

○ 매핑 분석과정을 통한 관리단위 도출

위에 언급한 ‘기능적 관점’의 경우 실제 물리적 데이터 구조와 상이할 가능성이 존재함. 이 경우 현실적으로 보존, 관리, 이관 등이 어렵거나 물리적으로 불가능한 관리단위가 도출될 수 있음

‘데이터 관점’만 가지고 분석을 진행할 경우 기능적으로 가치 없는 데이터가 핵심데이터로 식별되어 기록으로 무의미한 관리단위가 판별될 수 있음

이에 기능적 관점에서 나온 관리단위를 기준으로 데이터를 분석하여, 데이터 관점에서 다시 관리단위를 도출하여 다시 기능적 관점의 관리단위와 매핑하여 관리단위의 적합성을 검증함

나. 시스템 현장조사 방법

○ 사전 활동

조사절차를 수립하고 인터뷰 방법을 사전에 준비

○ 주요 활동

기관에서 받은 사전 조사 자료와 공개 자료 조사를 통해 해당 시스템의 사전 분석을 진행함

점층적으로 1차 조사와 2차 조사를 진행하며, 조사표를 작성함. 조사표와 협조 받은 산출물을 통해 시스템 기능과 데이터 분석을 일부 진행하여, 식별되지 않는 기능이나 데이터는 다음 조사 시 인터뷰나 현장 확인을 통해 보완함

142

<그림 129> 시스템 현장조사 방법

다. 시스템 자료 활용 방법

○ 시스템 개발 산출물 등 자료를 목적에 따라 적절히 활용하기 위해 개발 산출물의 종류를 파악하고 이해해야 함

<그림 130> 시스템 자료 활용 방법

143

라. 시스템 분석

○ 유용한 시스템 기능 분석 도구

1차 현장조사표, 업무 담당 부서 인터뷰 내용, 시스템 기능 설명 자료를 도구로 개발 산출물을 분석하여 업무기능 단위를 도출

<그림 131> 시스템 기능 분석 도구

마. 데이터 베이스 분석

○ 유용한 데이터베이스 분석 도구

2차 조사표, 시스템 운영자와 데이터관리자(DataBase Administrator) 인터뷰 내용을 기반으로 DB설계 산출물을 분석하여 업무기능 단위를 도출

<그림 132> 데이터베이스 분석 도구 활용 방안

144

4.3. 단위기능 도출 방법

가. 단위기능 도출 단계

<그림 133> 단위기능 도출 절차

○ 1차 기초 조사

1차 기초 조사표 작성

· 전체적인 정보시스템의 이해와 기능 분석을 위한 기반 데이터를 도출하고 2차 기초 조사표 설계의 방향을 설정하는데 목적이 있으며 “기능 분석을 위한 기반 데이터 도출”을 본 단계의 결과로 예상할 수 있음

○ 기능 분석

주 데이터 후보 도출

· 해당 시스템내의 주 데이터의 후보를 찾아 이후의 분석과정의 효율을 높임

대기능 도출

· 주 데이터 후보를 중심으로 기능 및 서비스들을 그룹핑하여 대기능을 도출. 대기능은 단위기능 후보가 될 수 있음

업무유형 분석

· 업무유형에 따라 관리제외 대상을 판별하여 관리대상 후보에서 제거함

대기능 재분류

· 기능 관점 관리대상 후보를 보정함

145

<그림 134> 단위기능 도출을 위한 기능 분석 예시

○ 2차 기초 조사

2차 기초 조사표 작성

· 데이터 모델 분석을 위한 기반 데이터 도출

○ 데이터 모델 분석

물리 데이터 분석

· 상위 단계에서 도출된 대기능을 독립성(물리적 분리가능여부)을 판별, 재분류하여 (기록)단위기능 후보를 도출

비정형 데이터 연계 분석

· 비정형데이터로 인해 물리적 분리가 불가능한지 판단하여 재분류함

데이터 목적 분석

· 각 주 데이터의 관리제외 대상 식별함

146

<그림 135> 단위기능 도출을 위한 데이터 모델 분석 예시

○ 단위기능 검토

단위기능 검토 및 도출

· 도출된 단위기능을 협의체를 통해 검토, 의견접수, 추가 분석 여부 판단

나. 관리기능 도출시 참여 인력 및 역할

○ 관리기관 업무 담당자

1차, 2차 기초 조사표의 내용을 작성하며, 기록 전문가 및 정보 기술 전문가가 해당 행정정보시스템을 정확히 분석할 수 있도록 분석 기반 자료를 제공하고 자료의 내용을 설명

기능 분석 단계에서 도출된 대기능이 해당 행정정보시스템의 기능과 일치하는 지 확인

○ 기록 전문가

정보 기술 전문가와 기능 분석을 함께 하며 기록관리 관점에서 관리기능을 판별하는데 중점을 둠

○ 정보 기술 전문가

관리기능 도출시 기능 분석 및 데이터모델 분석을 주도하며 관리기관 업무담당자를 통해 정확한 시스템 이해를 도모하고, 기록 전문가와 협력하여 관리기능을 판별

147

다. 기능 분석 상세 방법

○ 대표 데이터 도출

분석 목적

· 해당 시스템내의 대표 데이터를 찾아 이후의 분석과정의 효율을 높임

분석 방법

· 정보시스템의 업무담당자의 인터뷰나 서비스내용 분석을 통해 주 데이터(핵심 도메인) 들을 도출. 도출된 주 데이터는 이후 단계의 분석과정을 통해 정제됨 · 인터뷰 질문의 예) 본 시스템에서 서비스하고 있는 기능 및 각 서비스가 관리하고 있는 핵심 대상(데이터)은 무엇(들)인가?

분석 기반 자료

· 인터뷰: 업무담당자 인터뷰

· 1차조사표: 서비스목표, 서비스내용

분석 도출 결과

· 주 데이터 후보 도출

○ 대기능 도출

분석 목적

· 대표 데이터를 중심으로 기능 및 서비스들을 그룹핑하여 대기능을 도출함. 도출된 대기능들은 단위기능 후보가 됨.

분석 방법

· 메뉴, 서비스, 기능 구조를 주 데이터 후보를 중심으로 그룹핑하여, 기능 관점 단위기능 후보를 도출함.

· 각 대기능에서는 관리되고 있는 대표 데이터를 같이 기록함

· 1단계에서 도출된 주 데이터가 없는 기능의 경우는 기능분류나 메뉴로 그룹핑을 진행하여 1단계에서 누락된 주 데이터들을 추가적으로 도출함.

분석 기반 자료

· 산출물 : 메뉴구조도, 서비스구조도, 기능명세서

분석 도출 결과

· 대기능 도출

○ 업무유형 분석

분석 목적

148

· 업무유형에 따라 관리제외 대상을 판별하여 단위기능 후보에서 제거함

분석 방법

· 도출된 대기능의 업무 유형을 판단하여 관리제외 대상을 판별함

· 해당 기능의 업무 유형이 "기관고유업무", "공통행정업무", "단순업무지원", "보안,네트워크" 등으로 분류하였을 시 "기관고유업무"유형외 나머지 유형이 기록관리대상제외로 판단 될 수 있는지 재확인

분석 기반 자료

· 1차조사표 : 기능정보, 메뉴구조도, 인터뷰 등

분석 도출 결과

· 대기능 축소

○ 대기능 재분류

분석 목적

· 대기능 재분류를 통해 기능 관점의 대기능(단위기능 후보)를 최종 도출

분석 방법

· 정제된 대기능별로 주 데이터의 위상이 비슷한지, 해당 대표 데이터간 연관관계는 대기능별로 존재하지 않는 지 분석하여 대기능을 재분류 한다.

· 위상이 다르다고 판단될 경우에는 해당 데이터의 업무유형을 재판단해보고, 각 서비스간 계층구조를 재판별함

· 대표 데이터가 타 대기능에서 사용되고 있다면, 타 대기능까지 묶어 하나의 대기능으로 분류할 지 판단

분석 기반 자료

· 상위 단계 분석 자료

분석 도출 결과

· 대기능 재분류

라. 데이터 모델 분석 상세 방법

○ 물리 데이터 분석

분석 목적

· 상위 단계에서 도출된 대기능을 독립성(물리적 분리가능여부)을 판별, 재분류하여 (기록)단위기능 후보를 도출

분석 방법

· 물리적 데이터베이스 분리/통합여부를 판단하여 각 대기능이 독립적으로 분리될 수

149

있는지 파악하여 단위기능 후보를 도출

· 물리적으로 분리가 불가능한 경우에는 해당 대기능을 묶어 새로운 단위기능 후보 도출

· ERD나 물리적 테이블 관계를 분석하여 누락된 주 데이터와 대기능별로 연관되는 데이터가 없는지 판단

· 단 연관데이터가 관리제외대상인 경우 독립성을 유지하고 있다고 판단함

분석 기반 자료

· 2차조사표: 업무 데이터베이스 목록

· 2차조사표: 데이터 통합유형 · 산출물: ERD, 테이블 명세서

분석 도출 결과

· 단위기능 후보 도출

○ 비정형데이터 연계 분석

분석 목적

· 비정형데이터로 인해 물리적 분리가 불가능한지 판단하여 대기능을 재분류함

분석 방법

· 각 대기능별로 연계된 비정형데이터가 기록관리관점에서 관리대상인지 판별

· 관리대상 비정형데이터의 경우 각 단위기능 후보별로 물리적 분리가 가능한지 확인

· (일반적으로 RDMS 테이블의 컬럼으로 비정형데이터가 관리되던가 별도의 솔루션 (CMS시스템이나 파일관리 솔루션 등)으로 관리되는 경우에는 분리가 가능)

분석 기반 자료

· 1차조사표 : 비정형 데이터

· 산출물 : ERD

분석 도출 결과

· 단위기능 후보 재분류

○ 데이터 목적 분석

분석 목적

· 각 대기능중 관리제외대상을 식별함

분석 방법

· 단위기능별 대표 데이터의 목적(기준, 처리, 참조, 공통 및 운영)을 분석하고 각 데이터의 관리 제외 대상을 식별

· 대표 데이터의 생성 방식을 분석(자동 입력의 경우 단위기능이 아닐 수 있음)

150

· 대표 데이터가 연계에 의해 생성되는 지 분석 (연계 생성의 경우 타 시스템에서 관리되어야 할 대상인지 판단)

분석 기반 자료

· 2차조사표 : 주요 기준데이터, 처리데이터, 참조데이터, 공통 및 운영데이터 · 2차조사표 : 주요 데이터의 생성 방식, 연계에 의해 생성되는 데이터 목록, 조회 연계서비스 목록

분석 도출 결과

· 단위기능 후보 축소

4.4. 데이터세트관리기준표 설계

가. 데이터세트관리기준표 요소

○ 데이터세트관리기준표는 데이터세트의 관리 기준을 정하는 서식으로서, 행정정보시스템에 대한 기술 정보를 비롯한 관련 업무, 근거 법령, 그리고 데이터 내용과 형식에 대하여 기술하여 데이터세트의 내용을 이해하기 위한 정보를 담고 있음. 기록관리의 기준을 관리 단위인 단위기능별로 기술하며, 상이한 보존기간을 책정해야 하는 처분의 단위별로 처분 일정을 설정함

<그림 136> 데이터세트 관리를 위한 정보

○ 데이터세트관리기준표의 각 정보 영역별 세부 항목은 다음과 같음

대 중 소 설명 필수 작성 목적 작성 시 참고사항

행정정보시스템의 운영과 정보시스템의 관리 기관명 필수 기본 정보 관리를 책임지는 기관의 관리기관을 기록한다. 기관 명칭 정보 정보시스템의 관리 행정정보시스템의 운영과 부서명 필수 기본 정보 부서를 기록한다. 관리 책임 부서 행정정보시스템을식별하는 시스 공식명칭. 향후 정보시스템의 공식 템 시스템명 필수 기본 정보 지속적으로 사용할 수 있는 시스템명을 기록한다. 정보 명칭으로 정함. EA에 등륵된 명칭 참조할 것.

151

대 중 소 설명 필수 작성 목적 작성 시 참고사항

구축연도와 서비스개시연도가 처분 시점 틀리다면 구축연도 정보시스템의 최초 필수 예측, 데이터 서비스개시연도를 기록 구축연도를 기록한다. 수량 예측 (서비스개시연도의 의미는 실데이터가 축적되기 시작한 연도를 의미함) 스위치등 네트워크 장비를 중앙기록물관 기록하지 않으며, 실제 리기관 인수 HW HW명을 기록한다 (예. 시스템이 구동되는 장비를 필수 보존 시 재현 명 서버, 스토리지 등) 기록 (대부분의 계획 기초 행정정보시스템은 자료 "서버"임) H WEB서버, WAS서버, 해당 HW의 용도를 DB서버, 스토리지 등 W 용도 필수 상동 기록한다. 구체적인 HW의 용도록 내 기록 역 클러스터링(이중화) 등의 해당 HW의 수량를 수량 필수 상동 환경을 고려하여 해당 기록한다. HW의 수량을 기록 해당 HW의 대략적인 CPU, RAM 등의 시스 사양 옵션 상동 사양을 기록한다. 개괄적인 사양을 기록 템 타 시스템과 공유하여 해당 HW의 특이사항을 정보 비고 선택 상동 운영하는 경우에는 해당 기록한다. 내용을 비고란에 기록 중앙기록물관 리기관 인수 해당 시스템이 해당 시스템을 보존 시 이관 용도 구동되는 SW정보를 필수 재현(구동)하기 위한 SW 방안 및 재현 기록한다. 정보를 기록 계획 기초 자료 제품 제품명을 기록한다. 필수 상동 - 명 S 제조 제조사를 기록한다. 필수 상동 - W 사 내 수량 수량을 기록한다. 필수 상동 - 역 버전 SW버전을 기록한다. 선택 상동 - 상용, 오픈소스 등 시스템 라이 해당 SW의 라이선스 재현시 해당 SW를 선택 상동 선스 정책을 기록한다. 구매해야 하는지 여부를 판단할 수 있게 기록

설치 해당 SW가 설치된 선택 상동 HW HW명을 기록한다

152

대 중 소 설명 필수 작성 목적 작성 시 참고사항

-중앙기록물관 리기관인수보 DBMS종류 및 버전을 존시이관방안 기록하고, NoSQL 등의 및재현계획기 비RDMBS에 정형데이터가 저장되는 DBMS 필수 초자료 비정형데이터를 DBMS정보를 기록한다. -데이터모델분 구조화하여 저장하고 석시산출물의 있다면 함께 기록 이해,현황분석 (누락주의) 을위한자료 데이터베이스 의 백업이 백업 백업 대상을 기록한다. 필수 정상 작동하고 백업대상별로 기록 대상 있는지 점검 백 기준 마련 업 백업 정 백업 주기를 기록한다. 필수 상동 - 주기 책 백업 시스 백업방법이나 백업된 방법 템 정보가 저장된 매체를 선택 상동 - 및매 정보 기록한다. 체 데아터 정보시스템의 주 활용도와 타 기관 사용 여부, 국민 사용자를 기록한다. 사용자 시스템 변경 사용 여부 명시, 열람만 해당 사용자수를 필수 현황 난이도 및 가능한 사용자의 경우에는 추정할 수 있으면 영향 정도 별도 명시 추정치를 기록한다. 측정 최초 기준표 작성시(기존 기준표 변경의 원인이 기준표 이력 기록관리정보를 소급하여 이력관리 되는 시스템 정보 필수 관리 적용하지 않는 경우)에는 변경사항을 기록한다. 공란으로 비워둠 시스템 분석 ERD, Table Layout, 및 이관 상세 프로그램연관도, 개발 개발 기술사항 결정 산출물 등 시스템 구축 선택 - 산출물 시 참고할 및 운영과 관련된 산출물의 종류 산출물만 표기 파악 데이터세트의 내용 이해, 업무 시스템의 업무적 영구기록물관 시스템 사용 목적을 업무목적 필수 정보 목적을 기록한다. 리기관 이관 간략히 작성 여부 결정 시 참고

153

대 중 소 설명 필수 작성 목적 작성 시 참고사항

데이터세트의 해당 시스템에서 내용 이해, 업 행정정보시스템에서 제공하는 주요 영구기록물관 무 필수 제공되는 서비스가 여러 서비스의 업무명을 리기관 이관 명 개의 경우 모두 기록 업 기록한다. 여부 결정 시 업무 무 참고 정보 내 세 용 부 업무의 상세내용을 필수 상동 - 내 기록한다. 용 대 서비스의 대상을 필수 상동 - 상 기록한다. 보존기간과 법령, 처분 정책, 정보시스템과 관련된 법규 고시, 비공개, 비밀 법령, 고시, 규정, 필수 - 정보 규정, 기록 여부의 표준을 기록한다. 표준 근거 법령 파악 데이터의 대표 대표 데이터의 내용과 필수 종류, 내용 - 데이터 컬럼을 작성 파악 데이터베이스 구조 외 포맷의 데이터 존재와 종류를 종 비정형데이터 종류나 필수 파악하여 포맷 - 류 확장자를 기록한다. 정보 관리 및 이관 계획 시 기초 자료 비 데이 활용 정 해당비정형데이터를대표할 터 데 해당 비정형 데이터의 형 수있는데이터명을기록한다. 정보 이 데이터 구분명을 필수 상동 데 작성예시: 민원 첨부파일, 터 기록한다 이 특허출원서 등 터 구 해당 비정형 데이터를 동 구동할 수 있는 SW를 선택 상동 - 한 판별할 수 있는 경우 SW 해당 SW를 기록한다. 작성 예시 : 저 데이터베이스-Blob타입등 장 비정형데이터의 저장 선택 상동 데이터베이스내 저장, 별도 방 방법을 기록한다. 파일관리SW이용, 법 스토리지에 저장

데 데 데이터만으로는 해석이 선택 데이터 재현 개인정보 등 데이터해석이

154

대 중 소 설명 필수 작성 목적 작성 시 참고사항

불필요한 경우, 사유를 이 불가능한 데이터의 시 필요한 기록하고 해석방법 기록은 터 현황과 해석방법 사항 파악 생략 비 이 평 데이터를 인코딩한 터 문 선택 상동 - 기술을 기록한다. 해 기 석 술 의 해 데이터를 해석할 수 존 석 있는 기술적 방법을 선택 상동 - 성 방 기록한다. 법 데이터가 비평문으로 사 저장하지 않는 사유를 선택 상동 - 유 기록한다. 공공데이터 포탈 등 대국민 공개하는 데이터 존재 정보공개 대상 구 정보공개 구분명을 여부는 데이터(또는 서비스)가 필수 데이 분 기록한다. 데이터세트 여러종류의 경우 각기 터 정 이용가능성 기록한다. 정보 보 평가에 기초 공 자료로서 개 보존정책 수립에 필요 방 정보를 공개하는 필수 상동 - 법 방법을 기록한다. 공 개 공개자료의 대상(또는 필수 상동 - 자 범위)를 기록한다 료 해당 시스템 생산 데이터와 연 데 연계 입수, 계 이 타 시스템 연계로 생성 또는 타 데 터 또는 활용되는 필수 시스템으로의 - 이 내 데이터를 기록한다. 입출 데이터를 파악하여 동일 터 용 데이터의 중복 현 정도 파악 황 연 연계가 되는 대상 필수 상동 - 계 시스템명을 기록한다.

155

대 중 소 설명 필수 작성 목적 작성 시 참고사항

시 스 템 연 계 연계를 하는 기술적 작성예시: URL 링크, DB 필수 상동 방 방법을 기록한다. 접속, XML, TXT 등 법 활 용 해당 데이터의 활용 필수 상동 작성예시: 수정, 참조 등 데이 방 방법을 기록한다. 터 법 정보 연 계 입력, 출력 등 연계 필수 상동 작성예시: 입력, 출력 방 방향을 기록한다. 향

최초 기준표 작성시(기존 기준표 변경의 원인이 데이터세트 기록관리정보를 소급하여 이력관리 되는 데이터 정보 필수 변경 이력 적용하지 않는 경우)에는 변경사항을 기록한다. 기록화 공란으로 비워둠

단위기능을 도출된 단위기능을 단위기능 필수 식별하기 기록한다. 위하여 작성 관리단위의 상세 설명으로, 상위 행정정보시스템에서 업무활용 관리단위의 업무활용상 단위기능의 업무적으로 활용되어지고 필수 목적 목적을 기록한다. 내용 이해 있는 목적을 기록 기록 (기록관리 단계의 활용 관리 목적을 기록하는 것이 정보 아님) 주제어별 (단 단위기능과 관련된 단위기능을 위기 주제어 주제어(keyword)를 필수 검색하기 위해 능별 기록한다. 작성 작성) 데이터 데이터 처분 시 데이터 데이터를 생산 및 소유와 관리 소유기관과 관리기관의 필수 소유권 처리하는 기관 기관 불일치 일치 여부 체크를 위해 여부 파악 작성 데이터 데이터 처분 시 데이터 소유와 관리 소유기관과 관리기관의 데이터 관리 기관 필수 관리권 기관 불일치 일치 여부 체크를 위해 여부 파악 작성

156

대 중 소 설명 필수 작성 목적 작성 시 참고사항

단위기능이 포함된 행정정보시스템의 시스템 단위기능 시스템 및 접근권한의 관리 권한은 제외하고, 접근권한 데이터에 접근할 수 선택 관리 여부 단위기능의 데이터나 있는 권한을 기록한다. 점검용 기능에 대한 접근권한을 기록 이용가능성 비공개 대국민 비공개 정보 평가와 활용 선택 대상 포함 여부와 종류 방안 수립 기초자료 이용가능성 평가와 활용 비밀 여부 비밀 기록 여부 선택 방안 수립 기초자료 처 처분의 단위를 처분단위가 단위기능과 분 처분단위의 명칭을 필수 식별하기 위해 일치한다면 단위기능명을 단 기록한다. 작성 기록 위 보 보존/이관/폐 존 1년부터 영구 사이 년도 기 시행 필수 기 단위로 기간 시기의 기준 간 설정 데이터생성일(데이터가입 력된날짜)이나 업무 종결일, 또는 보 기 행정정보시스템 기록 보존기간 시작일 보존기간 존 산 필수 업무유형에 맞게 기산일 관리 기준을 설명한다 만료 기준 기 일 정의 정보 간 예) 사업보고 완료일 다음 (단 연도 1월1일, 민원 등록일 위기 및 다음 연도 1월1일 능별 단위기능 전체 또는 조건에 처 작성) 적 맞는 일부 데이터인지 분 단위기능 전체 또는 용 보존/이관/폐 표시. 기산일 정보로 검색 일부, 추출 조건을 필수 범 기대상 조건을 명시할 수 없다면 명시한다. 위 추출 조건을 별도로 기록. 예) 민원유형이 일반

책 보존기간을 책정한 보존기간 정 법률적 사유 또는 필수 책정 기준과 사 유 정책을 기록한다. 근거 처 장기보존 분 보존기간 도래 시 처분 작성 예시 : 이관, 폐기, 필수 정책 수립 방 방법을 기록한다. 자가 보존 자료 법

<표 84> 데이터세트관리기준표

157

○ 관리기관 정보

기관명

· 행정정보시스템의 운영과 관리를 책임지는 기관의 명칭을 기록

· 작성 기반 자료: 1차 조사표 > 기관명

· 필수 여부: 필수

부서명

· 행정정보시스템의 운영과 관리 책임 부서의 명칭을 기록

· 작성 기반 자료: 1차 조사표 > 부서명

· 필수여부: 필수

○ 시스템 정보

시스템명

· 정보시스템을 식별하는 공식 명칭을 기록

· 작성 기반 자료: 1차 조사표 > 시스템명

· 필수 여부: 필수

구축 연도

· 행정정보시스템의 최초 구축 연도를 기록하며 이는 추후 처분 시점 및 데이터 수량을 예측하기 위해 기록. 구축 연도와 서비스 개시 연도가 틀리다면 서비스 개시 연도를 기록하며 서비스 개시 연도의 의미는 실데이터가 축적되기 시작한 연도를 의미함에 주의. 다른 행정정보시스템과 HW를 공유하여 운영하는 경우에는 해당 내용을 비고란에 기록

· 작성 기반 자료: 1차 조사표 > 구축연도

· 필수 여부: 필수

HW 내역

· HW명, 용도, 수량, 사양 등을 기록하며 이는 중앙기록물관리기관 인수 보존 시 재현 계획의 기초 자료로 사용됨. 스위치등 네트워크 장비는 기록하지 않으며 실제 시스템이 구동되는 장비를 기록

· 작성 기반 자료: 1차 조사표 > 주요 H/W 정보 · 필수 여부: 필수

158

HW명 용도 수량 사양 비고 가상컴퓨팅 인터넷망 WEB서버 4식 (vCPU 4, 16G RAM) 가상컴퓨팅 인터넷망 WAS서버 4식 (vCPU 8, 32G RAM) 가상컴퓨팅 인터넷망 DB서버 4식 (vCPU 4, 8G RAM) 가상컴퓨팅 서버 인터넷망 메일/지도서버 1식 (vCPU 2, 8G RAM) 가상컴퓨팅 행정업무망 WEB서버 2식 (vCPU 2, 8G RAM) 가상컴퓨팅 행정업무망 WAS서버 2식 (vCPU 2, 8G RAM) 가상컴퓨팅 행정업무망 DB서버 2식 (vCPU 2, 8G RAM)

<표 85> HW 내역 작성 예시

SW 내역

· SW의 용도, 제품명, 제조사, 수량, 버전, 라이선스 정보, 설치 HW 등 해당 시스템이 구동되는 SW를 기록. 이는 중앙기록물관리기관 인수 보존 시 이관 방안 및 재현 계획의 기초자료로 사용됨. 라이선스 정보는 상용, 오픈소스 등 시스템 재현시 해당 SW를 구매해야 하는지 판단할 수 있게 기록

· 작성 기반 자료: 1차 조사표 > 주요 S/W 정보

· 필수 여부: 필수

라이선 용도 제품명 제조사 수량 버전 스 설치HW Linux (보안 CentOS centos OS 19 오픈소스 전체 서버 OS) Project 7 Web Server **** A사 6 6 상용 전체 WEB서버 WAS **** A사 6 6 상용 전체 WAS서버 *********** 웹구간암호화 B사 6 - 상용 전체 WEB서버 ****** OO Libray C사 4 - 상용 전자민원+행정업무 WAS서버 DATA 암호화 OO C사 4 - 상용 전체 DB서버 웹리포팅 ********* D사 4 7.0 상용 전자민원+ 행정업무 WAS서버 문서위변조방 ********* E사 2 2.5 상용 전자민원 WAS서버 지 OO for NP F사 2 4.0 상용 전자민원 WEB서버 Agent OO for NP F사 2 4.0 상용 전자민원WAS서버 KIT 행정전자서 PKI인증 GPKI Agent 명인증관리 2 1.4 공공 행정업무 WEB서버 센터 행정전자서 GPKI Tool 명인증관리 2 1.4 공공 행정업무 WEB서버 KIT 센터 ******** 백업 Backup G사 19 5.4 상용 전체 서버 Agent

<표 86> SW 내역 작성 예시

159

DBMS

· 정형데이터가 저장되는 DBMS정보를 기록. 이는 중앙기록물관리기관 인수 보존 시 이관 방안 및 재현 계획의 기초자료 및 데이터 모델 분석 시 산출물의 이해와 현황 분석을 위한 자료로 활용됨. DBMS종류 및 버전을 기록하고 NoSQL 등의 비RDMBS에 비정형데이터를 구조화하여 저장하고 있다면 함께 기록 · 작성 기반 자료: 1차 조사표 > DBMS 정보

· 필수 여부: 필수

백업 정책

· 백업 대상별로 백업대상, 백업죽, 백업방법 및 매체를 기록하여 데이터베이스의 백업이 정상 작동하고 있는지 점검 기준을 마련함

· 작성 기반 자료: 2차 조사표 > 데이터 관리 현황

· 필수 여부: 필수

백업대상 백업주기 백업방법 및 매체

전체시스템 주간,월간 NAS

전체 Datatase 일간 Disk

전체 비정형데이터 격일 NAS

<표 87> 백업정책 작성 예시

사용자 현황

· 정보시스템의 주 사용자를 기록. 해당 사용자수를 추정할 수 있으면 추정치를 기록. 데이터 활용도와 시스템 변경 난이도 및 영향 정도 측정의 목적. 타 기관사용 여부, 국민 사용 여부 명시, 열람만 가능한 사용자의 경우에는 별도 명시

· 작성 기반 자료: 1차 조사표 > 주 사용자

· 필수 여부: 필수

이력 관리

· 기준표 변경의 원인이 되는 시스템 정보 변경사항을 기록. 기준표 이력 관리 목적. 최초 기준표 작성시(기존 기록관리정보를 소급하여 적용하지 않는 경우)에는 공란으로 비워둠

· 작성 기반 자료: 1차 조사표 > 주요 변경이력 · 필수 여부: 필수

개발 산출물

· ERD, Table Layout, 프로그램연관도, 개발 산출물 등 시스템 구축 및 운영과 관련된 산출물만 표기. 시스템 분석 및 이관 상세 기술사항 결정 시 참고할 산출물의 종류 파악이 목적

160

· 작성 기반 자료: 1차 조사표 > 보유(관리) 산출물 현황 · 필수 여부: 옵션

○ 업무 정보

업무 목적

· 시스템의 업무적 목적을 기록. 데이터세트의 내용 이해, 영구기록물관리기관 이관 여부 결정 시 참고가 목적 · 작성 기반 자료: 1차 조사표 > 업무 목적

· 필수 여부: 필수

업무 내용

· 업무명, 세부내용, 대상을 기록. 데이터세트의 내용 이해, 영구기록물관리기관 이관 여부 결정 시 참고가 목적. 행정정보시스템에서 제공되는 서비스가 여러 개의 경우 모두 기록

· 작성 기반 자료: 1차 조사표 > 서비스 내용

· 필수 여부: 필수

업무명 세부내용 대상

유해물질 종합정보 제공 유해물질과 관련된 종합정보를 제공 국민

민원처리 유해물질 관련 민원처리를 위한 행정시스템 기업, OO부

유해물질 운반계획서 유해물질 운반계획서 관리 기업, OO부

유해물질 수입관리 유해물질 제조수입자의 사후관리에 관한 업무를 처리 OO부

<표 88> 업무내용 작성 예시

○ 법규 정보

법령, 고시, 규정, 표준

· 정보시스템과 관련된 법령, 고시, 규정, 표준을 기록. 보존기간과 처분 정책, 비공개, 비밀 기록 여부의 근거 법령 파악이 목적

· 작성 기반 자료: 1차 조사표 > 관련 법령 정보

· 필수 여부: 필수

○ 데이터 정보

대표 데이터

· 대표 데이터의 내용과 컬럼을 작성. 데이터의 종류, 내용 파악이 목적

· 작성 기반 자료: 2차 조사표 > 정형 데이터 현황

· 필수 여부: 필수

161

비정형 데이터

· 종류, 데이터, 구동 가능한 SW, 저장방법을 기록. 데이터베이스 구조 외 포맷의 데이터 존재와 종류를 파악하여 포맷 정보 관리 및 이관 계획 시 기초 자료 활용이 목적. 종류는 비정형데이터 종류나 확장자를 기록. 데이터는 해당 비정형 데이터의 데이터 구분명을 기록. 해당 비정형 데이터를 구동할 수 있는 SW를 판별할 수 있는 경우 해당 SW를 기록

· 작성 기반 자료: 2차 조사표 > 데이터 관리 현황

· 필수 여부: 필수

데이터 종류 구동 가능한 SW 저장방법 Microsoft Excel 2000이상 스토리지에 저장후 유해물질 xls 유해물질 운반계획서 OpenOffice 1.0 이상 운반계획서 테이블에 경로 xlsx LibereOffice 1.0 이상 저장 ... AdobeReader pdf ... Microsoft Word 2000이상 한글과 컴퓨터 2002 doc 이상 OpenOffice 1.0 이상 LibereOffice 1.0 이상 민원게시판 첨부파일 ... 스토리지에 저장후 민원정보 게시판 테이블에 경로 저장 Microsoft PowerPoint 2000이상 ppt OpenOffice 1.0 이상 LibereOffice 1.0 이상 ... PhotoShop jpg Windows 그림판 ......

<표 89> 비정형데이터 작성 예시

데이터 해석 의존성

· 데이터, 비평문 기술, 해석방법, 사유를 기록. 데이터 재현 시 필요한 사항 파악이 목적. 개인정보 등 데이터해석이 불필요한 경우, 사유를 기록하고 해석방법 기록은 생략

· 작성 기반 자료: 2차 조사표 > 정형 데이터 현황 · 필수 여부: 옵션

데이터 비평문 기술 해석방법 사유

유해물질 취급업체 기관 업체 정보 3-DES 3-DES 복호화 대표자 인적사항 보호 정책

<표 90> 데이터 해석 의존성 작성 예시

162

정보 공개

· 구분, 방법, 공개 자료를 기록. 공공데이터 포탈 등 대국민 공개하는 데이터 존재 여부는 데이터세트 이용가능성 평가에 기초 자료로서 보존정책 수립에 필요. 정보공개 대상 데이터(또는 서비스)가 여러 종류의 경우 각기 기록

· 필수 여부: 필수

구분 방법 공개자료

유해물질과 관련된 종합정보 정보제공 및 민원접수 사이트 웹사이트 제공

<표 91> 정보공개 작성 예시

연계 데이터 현황

· 데이터 내용, 연계 시스템, 연계 방법, 활용 방법, 연계 방향을 기록. 해당 시스템 생산 데이터와 연계 입수, 또는 타 시스템으로의 입출 데이터를 파악하여 동일 데이터의 중복 정도 파악이 목적

· 작성 기반 자료: 2차 조사표 > 외부 시스템 연계 현황

· 필수 여부: 필수

활용 연계 데이터 내용 연계 시스템 연계 방법 방법 방향 주기적 수작업 유해물질 사고이력정보 유해물질 사고정보공유시스템 참조 입력 export/import

주기적 수작업 유해물질대응 정보 유해물질사고대응정보시스템 참조 입력 export/import

주기적 수작업 유해제품 응급대응정보 유해제품응급대응정보시스템 참조 입력 export/import

주기적 수작업 유해물질 유해물질안전관리정보시스템 참조 입력 export/import

유해물질 수출입 신고 관세청 FTP 통신(xls) 참조 입력 자료

수입요건확인서 결과 관세청 HTTP통신 (xml) 참조 입력

수입신고허가정보, 수 관세청 FTP 통신(xls) - 출력 입위반업체

수입요건 확인서 관세청 HTTP통신 (xml) - 출력

<표 92> 연계 데이터 현황 작성 예시

163

이력 관리

· 기준표 변경의 원인이 되는 데이터 정보 변경사항을 기록. 데이터세트 변경 이력 기록화가 목적. 최초 기준표 작성시(기존 기록관리정보를 소급하여 적용하지 않는 경우)에는 공란으로 비워둠

○ 기록 관리 정보 (단위 기능별로 기록)

단위 기능

· 도출된 단위기능을 기록. 단위기능을 식별하기 위하여 작성함 · 작성 기반 자료: 시스템 분석보고서

· 필수 여부: 필수

업무 활용 목적

· 관리단위의 업무활용상 목적을 기록. 단위기능의 내용 이해가 목적. 관리단위의 상세 설명으로, 상위 행정정보시스템에서 업무적으로 활용되어지고 있는 목적을 기록 (기록관리 단계의 활용 목적을 기록하는 것이 아님)

· 필수 여부: 필수

주제어

· 단위기능과 관련된 주제어(keyword)를 기록. 주제어별 단위기능을 검색하기 위해 작성

· 필수 여부: 필수

데이터 소유권

· 데이터를 생산 및 처리하는 기관. 데이터 소유와 관리 기관 불일치 여부 파악. 데이터 처분 시 소유기관과 관리기관의 일치 여부 체크를 위해 작성

· 필수 여부: 필수

데이터 관리권

· 데이터 관리 기관. 데이터 소유와 관리 기관 불일치 여부 파악. 데이터 처분 시 소유기관과 관리기관의 일치 여부 체크를 위해 작성

· 필수 여부: 필수

접근 권한

· 단위기능 시스템 및 데이터에 접근할 수 있는 권한을 기록. 접근권한의 관리 여부 점검용. 단위기능이 포함된 행정정보시스템의 시스템 관리 권한은 제외하고, 단위기능의 데이터나 기능에 대한 접근권한을 기록

· 필수 여부: 옵션

비공개 대상

· 대국민 비공개 정보 포함 여부와 종류. 이용가능성 평가와 활용 방안 수립 기초자료.

· 필수 여부: 옵션

164

비밀 여부

· 비밀 기록 여부. 이용가능성 평가와 활용 방안 수립 기초자료. · 필수 여부: 옵션

보존 기간 및 처분

· 처분단위명, 보존기간, 기산일, 적용범위, 책정사유, 처분 방법을 기록

· 처분단위: 처분단위의 명칭을 기록. 처분단위를 식별하기 위해 작성. 처분단위가 단위 기능과 일치한다면 단위기능명을 기록

· 보존기간: 1년부터 영구 사이 년도 단위로 기간. 보존/이관/폐기 시행 시기의 기준 설정

· 기산일: 보존기간 시작일 기준을 기록. 일반적으로 데이터 생성일. 데이터가 입력된 날짜이나 해당 행정정보시스템 및 업무 유형에 맞게 기산일을 작성. (예) 사업보고 완료일 다음 연도 1월 1일, 민원 등록일 다음 연도 1월 1일

· 적용범위: 단위기능 전체 또는 일부, 추출 조건을 기록. 보존/이관/폐기 대상. 단위기능 전체 또는 조건에 맞는 일부 데이터인지 표시. 기산일 정보로 조건을 특정 지을 수 없다면 추출 조건을 별도 기록함. 작성예) '단위기능 전체', '일부 데이터'

· 책정 사유: 보존기간을 책정한 법률적 사유 또는 정책을 기록. 보존기간 책정 기준과 근거

· 처분 방법: 보존기간 도래 시 처분 방법을 기록. 장기보존 정책 수립 자료. 작성예) 이관, 폐기, 자가 보존

· 작성 기반 자료: 2차조사서 > 보존 정책 및 활용

· 필수 여부: 필수

처분단위 보존기간 기산일 적용 범위 책정 사유 처분 방법

유해물질관리법 유해물질 데이터 생성일 5년 일부데이터 유해물질 폐기 사고정보 다음 연도 1월 1일 취급조항

<표 93> 보존 기간 및 처분 작성 예시

나. 데이터세트 관리 기준표 주요 고찰 내용

○ 단위 기능

단위기능의 정의

· 행정정보시스템의 기록 관리의 단위로서 행정정보시스템내 업무활용 목적이 명료하게 구분되는 대기능이며, 이관/보존/폐기 등 해당 기능에서 생산된 데이터의 처분활동이 가능한 최소단위

단위기능과 처분단위의 차이

· 실질적 처분이 가능한 최소단위이나 처분의 단위와 일치하지 않을 수 있음. 처분 정책은

165

변화할 수 있으며 그 정책에 따라 기록관리의 단위가 변경되는 것은 바람직하지 않음. 단위기능 내 여러 처분 단위가 존재한다면 기록관리정보에 해당 처분단위별로 기록해야 함

단위기능과 단위과제의 차이

· 행정정보시스템내 데이터 구조는 단위과제별로 명료하게 분리되어 생산되어지지 않는 경우가 많고 각 데이터간 연관관계가 존재함. 또한 업무활용 목적상 여러 단위과제가 하나의 대기능으로 구성된 경우가 많음. 즉, 경우에 따라 동일할 수 있으나 일치한다고 단정할 수 없음

단위기능의 분류 방법

· 행정정보시스템은 다양한 목적에 따라 구축되고 있으므로 범용적인 계층형 분류를 적용하기에는 현실적으로 어려움. 이에 단위기능과 관련한 여러 개의 주제어 (keyword)를 통해 단위기능을 분류/검색/활용하며 추후 적합한 분류체계가 개발되면 해당 분류체계 적용을 고려

○ 보존 기간 및 처분

보존기간의 결정 방법

· 데이터세트의 보존기간은 해당 행정정보시스템의 업무목적 및 정책에 맞게 결정되어야 하므로 획일적으로 정할 수 없음. 1년~영구 내 년도 단위로 처분단위별로 해당 업무목적 및 정책에 맞게 기록하여 관리하는 것이 바람직

처분 적용 범위

· 데이터세트는 비전자 기록물의 건, 철의 개념을 적확하게 적용하기 어려움. 예를 들면 관계형 데이터베이스의 테이블, 레코드를 건, 철의 용어로 대체하더라도 연관관계를 적용할 수 있는 개념은 존재하지 않음. 이에 데이터세트의 처분 적용범위를 구체적으로 기록하여 데이터세트에 적합한 처분 대상을 관리할 필요가 있음

기산일

· 데이터세트는 일반적으로 고정적이기 보다 유동적으로 변화한다고 봐야 함. 데이터 생성일(해당 데이터가 최초 입력된 날짜)을 기산일 기준으로 삼을 수도 있지만, 경우에 따라 데이터 최종 수정일이나 활용 종료일 등 해당 데이터 유형에 맞게 관리되어야 함

· 단, 최종 수정일이나 활용 종료일을 판단할 수 없는 데이터세트가 존재할 수 있으므로 데이터 생성일을 기본적인 기산일 기준으로 관련 법규 등에 명시하는 것이 바람직

· 기산일은 사유 발생시점을 기준으로 관리하면 매일(또는 매근무일) 발생되는 데이터로 인해 매일 처분활용을 해야 하므로 합리적이지 않음. 특별한 경우(관련 법규나 지침 유무)가 아닌 이상 사유 발생 다음해 1월 1일을 기산일로 지정함이 합리적

166

4.5. 데이터세트 관리 프로세스

가. 프로세스 개요

<그림 137> 행정정보 데이터세트 관리 단계

나. 전체 프로세스

<그림 138> 행정정보 데이터세트 관리 전체 프로세스

167

다. 프로세스 1.1 데이터세트관리 협의체구성

<그림 139> 행정정보 데이터세트관리협의체 구성 프로세스

라. 프로세스 1.2 시스템 분석

<그림 140> 행정정보 데이터세트 시스템 분석 프로세스

168

마. 프로세스 1.3 기관 기준표 확정

<그림 141> 행정정보 데이터세트 기관 기준표 확정 프로세스

바. 프로세스 2.1 데이터 관리

<그림 142> 행정정보 데이터세트 데이터 관리 프로세스

169

사. 프로세스 2.2 시스템 변경 관리

<그림 143> 행정정보 데이터세트 시스템 변경관리 프로세스

아. 프로세스 2.3 기관 기준표 관리

<그림 144> 행정정보 데이터세트 기관 표 관리 프로세스

170

자. 프로세스 2.4 처분

<그림 145 > 행정정보 데이터세트 처분 프로세스

차. 프로세스 3.1 기록관리 모니터 링

<그림 146> 행정정보 데이터세트 기록관리 모니터링 프로세스

171

카. 프로세스 3.2 총괄 기준표 관리

<그림 147> 행정정보 데이터세트 총괄 기준표 관리 프로세스

타. 프로세스 3.3 인수

<그림 148> 행정정보 데이터세트 인수 프로세스

172

파. 프로세스 3.4 보존

<그림 149> 행정정보 데이터세트 보존 프로세스

하. 프로세스 3.5 활용 서비스

<그림 150> 행정정보 데이터세트 활용 서비스 프로세스

173

4.6 데이터세트 기록관리를 위한 법 제도 검토

가. 공공기록물 관리에 관한 법률

○ 「공공기록물 관리에 관한 법률」 [시행 2017.9.22.] [법률 제14613호, 2017.3.21., 일부개정] 이 행정정보 데이터세트 기록관리의 근거 법률 적용이 가능하도록 현행 조문을 검토하여 개정이 요구되는 사항을 정리함

개선안 목적 현행

제00조 (행정정보 데이터세트의 관리) 공공기관은 업무수행과 관련하여 행정정보 시스템에서 생산한 데이터세트를 대통령령으로 정하는 바에 따라 관리하고 중앙기록물관리기관과 협의 하에 처분하여야 한다.

제5장(기록물관리) 아래 ① 공공기관은 대통령령으로 정하는 바에 2 2 조 ( 간 행 물 관 리 ), 따라 데이터세트의 보존기간, 소유권 및 23조(시청각 기록물의 관리권 등을 관리하여야 한다. 관리), 24조(행정박물의 ② 행정정보 데이터세트는 보존기간 동안 관리)에서 전자문서와 다른 행정정보시스템에서 공공기관이 운용하며 유형에 대한 관리를 별도로 1 관리한다. 없음 명시하고 있음. 따라서 ③ 공공기관은 데이터세트의 처분 시기와 데이터세트 관리 의무를 방법을 정하여 시행하되, 명시한 조항 신설 중앙기록물관리기관의 장이 국가적 보존가치가 높아 수집, 보존이 필요하다고 제19조(기록물의 관리 등)와 인정하여 지정한 데이터세트는 대응되는 조 신설 중앙기록물관리기관으로 이관하여 보존하여야 한다. 공공기관이 이관 후에도 업무수행에 사용할 필요가 있는 경우에는 폐기하지 않고 유지할 수 있다. ④ 중앙기록물관리기관은 공공기관의 데이터세트 관리 상태를 정기적으로 또는 수시로 점검하여야 한다.

<표 94> 공기록물 관리에 관한 법률 개선안

○ 「공공기록물 관리에 관한 법률 시행령」 [시행 2017.9.22.] [대통령령 제28303호, 2017.9.19., 일부개정]이 행정정보 데이터세트를 관리하기 위한 상세 내역을 정하도록 내용 을 검토하여 개정 요구 사항을 정리함

174

개선안 목적 현행

제2조(정의)에 시행령에서 12. “단위기능”이라 함은 행정정보 데이터세트 관리를 데이터세트의 특성을 반영하여 정한 1 기술하기 위해서 새로 없음 데이터세트 분류와 관리의 기본 단위를 도입되어야 할 용어를 말한다. 정의해야 함

<표 95> 공공기록물 관리에 관한 시행령 개선안

데이터세트의 기록관리는 기록물의 생산, 기록물의 관리, 기록물의 공개, 열람 및 활용에 관한 장은 전자문서시스템과 업무관리시스템에서 생산한 기록물 관리를 규정하고 있어 특히 제4장 기록물의 생산(제16조) ~ 제5장 기록물의 관리(제53조)는 데이터세트에 적용이 어려운 사항이 많음. 따라서 데이터세트에 관하여는 현 조항을 수정하고 동시에 신설해야 하므로 신설 조항을 별도의 장으로 모으는 편이 관리 규정의 이해에 유리함

개선안 목적 현행 (행정정보 데이터세트 관리 협의체의 구성) (1) 행정정보시스템을 운영⦁관리하는 공공기관의 장은 행정정보시스템이 생산하는 데이터세트의 행정정보 데이터세트 기록관리를 기록관리를 위하여 기록관리 담당자, 정보기술 위해서는생산기관과정보기술지식과 담당자, 업무담당자로 구성된 협의체를 경험을 보유한 전문가의 협조가 중앙기록물관리기관과 공동 구성하여 1 절대적임. 없음 운영하여야 하며, 다음의 역할을 한다. 생산기관과중앙기록물관리기관이 1. 단위기능 정의 공동협력하여데이터세트 관리할 2. 데이터세트관리기준표 작성 및 유지 관리 수 있는 근거 마련 3. 행정정보시스템 구축∙개선 시 분석 및 .검토 4. 행정정보 데이터세트 기록관리 상태 점검 (행정정보 데이터세트의 기록관리 대상) 데이터베이스에 저장된 데이터만이 공공기관은 업무 수행을 위해 운영∙관리하는 제16조(기록화 아니라 데이터세트의 첨부 자료나 2 행 정 정 보 시 스 템 의 있 는 데 이 터 세 트 를 및 기록관리 이력 정보도 기록화 대상임을 단위기능으로 정의하고 단위기능으로 정의된 대상) 명문화 함 데이터세트를 기록물로 관리하여야 한다. (행정정보 데이터세트의 등록) ①행정정보시스템 데이터세트의 관리단위를 생산등록번호 부여 및 표기와 식별하여 단위기능을 정의한다. 다른 데이터세트의 고유한 제20조(기록 3 ②데이터세트의 단위기능의 데이터세트 등록 방법과 식별번호 구성 물의 등록) 관리기준표를 작성하고 중앙기록물관리기관이 설명 정한 절차와 방법에 따라 등록하여 고유 식별번호를 부여한다.

175

개선안 목적 현행 ③ 식별번호는 시스템구분, 기관코드, 행정정보시스템코드와 단위기능 코드로 구성한다. ④ 행정정보 데이터세트에 포함된 첨부물은 데이터베이스와 상호 맥락을 유지할 수 있도록 관리하여야 한다. 처리과별 단위과제별이 (행정정보 데이터세트의 분류) ① 아닌 데이터세트를 생산 행정정보 데이터세트는 기관별 제22조(기록 4 또는 관리하는 행정정보시스템별 단위기능별 분류하여야 물의 분류) 행 정 정 보 시 스 템 별 한다. 단위기능별 분류 함 데이터가 생산될 때 생산과 (행정정보 데이터세트의 편철과 관리) 동시에 편철되는 것으로 행정정보 데이터세트는 생성 시 연도 제23조(편철 5 간주. 구분이 가능하도록 저장됨으로써 편철된 및 관리) 단, 연도 구분이 가능하도록 것으로 간주한다. 저장하기로 함 (행정정보 데이터세트의 정리) ① 공공기관은 운용 중인 행정정보 기록물 정리 의무를 정하되 데이터세트에 대하여 시행 내용은 완결된 제24조(기록 6 데이터세트관리기준표에 따라 관리되고 기록물의 분류 편철 확정이 물의 정리) 있는지 수시로 점검하고 정정보시스템과 아닌 기록관리기준표의 행정정보 데이터세트에 관한 변경사항을 현행화로 명시 데이터세트관리기준표에 반영하여야 한다. (데이터세트관리기준표) ① 공공기관은 행정정보 데이터세트의 단위기능별로 기록관리기준표를 작성하여야 한다. ② 기록관리기준표는 관리기관 정보, 시스템 정보, 업무 정보, 법령 정보, 데이터 정보, 기록관리정보 등을 포함한다. 기록관리정보애는 단위기능, 비정형데이터, 보존기간, 데이터 소유권, 보존기간, 처분 등이 포함된다. 데이터세트 기록관리기준표 제25조(기록 7 ③ 중앙기록물관리기관의 장은 행정정보 작성 주체와 내용 설명 필요 관리기준표) 데이터세트의 진본성, 무결성, 이용가능성을 보장에 필요하다고 판단하는 경우 관리항목을 변경할 수 있다. ④ 데이터세트 기록관리기준표는 중앙기록물관리기관이 정한 절차와 방법에 따라 생성, 관리하여야 한다. ⑤ 행정정보시스템 관리 기관과 중앙기록물관리기관의 협력 하에 데이터세트 관리 협의체는

176

개선안 목적 현행 기록관리기준표를 작성하고 변경 사항을 반영하여 지속적으로 관리하여야 한다. ⑥ 공공기관은 매년 기록물 정리기간 종료 직후 전년도에 신규로 등록하였거나 변경된 데이터세트관리기준표의 기록관리정보를 관보(지방자치단체의 경우에는 공보를 말한다) 또는 그 기관의 홈페이지 등 정보통신망에 고시하여야 한다. 다만, 국가정보원장은 중앙기록물관리기관의 장과 협의하여 국가정보원의 고시범위를 달리 정할 수 있다. (행정정보 데이터세트의 보존기간) ① 행정정보 데이터세트의 보존기간은 데이터세트관리기준표에서 정한 처분 단위별로 책정한다. ② 보존기간은 데이터세트의 증거적 가치 및 정보로서의 가치를 평가하여 1년부터 영구 범위 내에서 정한다. 다만, 행정정보시스템 관련 법령이 있는 경우 그 데이터세트는 보존기간 8 법령을 따른다. 책정 단위와 기산일이 제26조(보존 ③ 보존기간의 기산일은 단위기능 또는 다르므로 따로 정함 기간) 처분단위별로 데이터세트가 생성된 날이 속하는 다음 연도의 1월 1일로 한다. 다만, 데이터세트의 특성이나 업무 특성 상 달리 보존기간의 구분 및 기산일을 정해야 하는 경우 공공기관의 장이 중앙기록물관리기관의 장과 협의하여 정한다. 공개여부 책정 단위를 (행정정보 데이터세트의 공개여부의 단위기능으로 명시하고 제27조(공개 9 구분관리) 공공기관은 단위기능별로 공개여부 설정이 실제 여 부 의 공개여부를 구분하고 관리할 수 있다. 어렵기 때문에 구분관리) 선택사항으로 함 (행정정보 데이터세트의 접근권한 관리) ① 공공기관은 행정정보 데이터세트의 행 정 정 보 시 스 템 은 무결성 보장 및 비공개 데이터세트의 접근권한을 관리해야 하며 제28조(접근 10 체계적 관리를 위하여 접근범위를 시스템에 적용된 정책을 권한 관리 구분하여 관리할 수 있도록 필요한 조치를 따름 수립·시행하여야 한다. (행정정보 데이터세트의 보존방법) ① 데이터세트에 적용할 11 행정정보 데이터세트는 진본성, 무결성 및 보존방법을 명시하고 꼭 제29조(보존

177

개선안 목적 현행 이용가능성을 유지하도록 보존 계획을 수립하여 다음 각 호의 어느 하나 방법으로 보존하여야 한다. 1. 행정정보시스템에 운용 데이터와 같이 보존 2. 행정정보시스템이 제공하는 보존 기능을 이용하여 데이터세트 별도의 저장소에 보존 필요사항 명시 방법) 3. 외부 매체에 보존 4. 기타 방법 ② 제1항의 3호와 4호는 데이터세트의 재현 방법을 함께 보존하여 보존 중에도 재현할 수 있어야 한다. (3) 보존 계획은 행정정보 데이터세트에 포함된 전자파일의 재현 대책을 포함하여야 한다. (행정정보 데이터세트의 보존장소) ① 공공기관은 행정정보시스템에서 데이터세트는 30년 이상 보존기가넹 따라 데이터세트를 보존한다. 기록도 이관하지 않을 수 다만 중앙기록물관리기관의 장이 국가적 있기 때문에 제30조(보존 12 보존가치가 높아 수집, 보존이 필요하다고 행정정보시스템을 운영 및 장소) 인정하여 지정한 데이터세트는 공공기관과 관리하는 공공기관에서 협의하여 중앙기록물관리기관으로 보존할 수 있도록 해야 함 이관하여 보존하여야 한다. (행정정보 데이터세트의 기록물의 이관) ① 공공기관은 처분 계획을 수립하여 행정정보시스템의 특성 및 데이터세트관리기준표에 명시하여야 한다. 업무 상 필요에 의해 처분 계획은 보존기간, 보존방법과 생산기관에서 보존 보존장소 등을 포함한다. 가 능 하 며 , ② 공공기관은 보존 계획에 따라 행정정보 중 앙 기 록 물 관 리 기 관 이 데이터세트를 보존해야 한다. 단, 이관을 지정할 시 중앙기록물관리기관의 장이 국가적 이관하여야 함. 제32조(기록 13 보존가치가 높아 수집, 보존이 필요하다고 공공기관이 정해진 물의 이관) 인정하여 지정한 데이터세트는 규격으로 변환하여 하여야 중앙기록물관리기관으로 이관하여 하며 이관 규격은 보존하여야 한다. 중 앙 기 록 물 관 리 기 관 이 ③ 공공기관은 이관 대상 데이터세트를 정하고, 수반되는 중앙기록물관리기관이 정한 이관 규격에 기술사항은 협의체가 따라 이관하여야 한다. 기타 기술사항은 결정하여 시행하도록 함 공공기관은 장과 중앙기록물관리기관이 협의하여 결정한다. 14 (행정정보 데이터세트의 데이터세트 데이터는 수시로 생산,

178

개선안 목적 현행 기록관리현황 통보) ① 공공기관은 변경되며 통보 단위의 데이터세트관리기준표 해당 사항이 변경될 지정과 측량이 불가하므로 제33조(처리 때 또는 행정정보 데이터세트에 평가, 생산현황통보를 할 수 없음. 과 의 보존, 이관 등의 기록관리 행위를 가했을 그러나 변경 또는 관리 행위 기 록 물 생 산 때 그 내용을 발생일로부터 30일 이내 발생 시 기록관리기준표와 현황 통보) 반영하여 수정하고 중앙기록물관리기관에 관리 이력을 현행화하여야 통보하여야 한다. 함 (행정정보시스템 구축⦁개선 시 사전 협의 등) ① 공공기관의 장은 행정정보시스템 행정정보시스템의 변경 시 구축 계획을 중앙기록물관리기관의 장과 검토 대상은 기록물관리 제 34 조 의 2 ( 협의하여야 한다. 기능만이 아니라 시스템 전 자 기 록 생 ② 행정정보시스템의 개선 시 15 정보, 데이터베이스, 데이터 산 시 스 템 의 데이터세트관리기준표의 기록관리 항목의 모델, 서비스 기능의 구 축 · 개 선 해당 사항이 변경 될 경우 공공기관의 변경까지 포함함. 대상 변경 시 사전협의 장은 중앙기록물관리기관의 협의하여야 사항의 범위를 확대해야 함 등) 하며 변경 내역을 데이터세트관리기준표에 반영하여야 한다. (행정정보 데이터세트의 평가 및 폐기) ① 공공기관의 장은 행정정보 데이터세트 중 보존기간이 경과한 데이터세트에 대하여는 법 제27조제1항에 따라 생산부서 의견조회, 법 제41조제1항에 따른 기록물관리 전문요원(해당 기록관 또는 특수기록관 소속 기록물관리 전문요원을 말한다)의 심사 및 제4항에 따른 기록물평가심의회의 심의를 거쳐 보존기간 재책정, 폐기 또는 보류로 구분하여 제43조(기록 처리하여야 한다. 생산기관에서 폐기하기 관 및 ② 중앙기록물관리기관의 장은 기록관 되며 현행과 다른 폐기 특 수 기 록 관 16 또는 특수기록관의 장과 협의하여 제1항에 서식을 사용하고, 폐기 시 의 소관 따라 폐기되는 데이터세트 원본 중 시스템과 외부 매체로부터 기록물 평가 보존가치가 있는 원본은 선별·보존할 수 삭제함 및 폐기) 있다. ③ 공공기관의 장은 제1항에 따라 평가된 기록물 중 보류로 구분된 기록물은 평가일부터 10년마다 보존가치를 재평가하여야 한다. ⑤ 공공기관의 장은 행정정보 데이터세트 평가 및 폐기를 위하여 기록물평가심의회를 구성·운영하되, 기록물평가심의회의 위원은 데이터세트의 보존가치 평가에 적합하다고 인정되는 5명

179

개선안 목적 현행 이내의 민간 전문가 및 소속공무원으로 구성하고, 2명 이상의 민간 전문가를 포함하여야 한다. 다만, 통일, 외교, 안보, 수사, 정보 등의 데이터세트를 생산하는 기관의 경우에는 민간 전문가 참여를 1명 이상으로 할 수 있다. ④ 행정정보 데이터세트를 폐기하고자 할 때는 폐기 대상 데이터세트를 행정정보시스템에서 삭제하고, 만약 행정정보시스템외 매체에 저장되어 있다면 이 매체에서도 삭제한다. ⑦ 폐기 시 폐기 대상 단위기능, 처분 단위, 폐기일자, 폐기자 등 폐기 정보를 [별지 제00호 서식]에 따라 작성해야 한다. 공공기관의 장이 폐기 대상 데이터세트의 상세 목록이 필요하다고 판단 시 목록을 첨부할 수 있다. (행정정보 데이터세트의 인수) ① 중앙기록물관리기관의 장은 매년 11월 인수 시 행정전자서명의 30일까지 공공기관별 이관일정 및 확인 등 진본 확인 절차를 이관대상 등이 포함된 다음 연도의 수행하여야 하며, 데이터세트 수집계획을 수립·시행하여야 메타데이터 오류 검사 한다. 불가하므로 품질검사 제44조(기록 ② 공공기관은 중앙기록물관리기관이 종류를 “바이러스 검사 관 및 17 정한 이관 규격을 따라 행정정보 등“으로 축소 특 수 기 록 관 데이터세트를 이관하여야 한다. 의 기록물 ③ 중앙기록물관리기관이 데이터세트를 이관 후에도 계속 인수) 인수하는 경우에 바이러스 검사 등 참조되거나 운용에 필요할 품질검사를 실시하여야 한다. 경우 파기하지 않고 유지할 ④ 공공기관은 이관 후에도 업무 수행을 수 있도록 근거 조항 마련 위해 필요할 시 행정정보 데이터세트를 삭제하지 않고 유지하여야 한다. (중앙기록물관리기관의 행정정보 영구기록물관리기관장을 데이터세트 보존 및 관리) 중 앙 기 록 물 관 리 기 관 으 로 제46조(영구 ① 중앙기록물관리기관의 장은 공공기관이 변경 기 록 물 관 리 생산한 행정정보 데이터세트의 효율적인 현행 ②항 삭제 기 관 의 이관과 보존 중인 행정정보 데이터세트의 현행 ⑤항 삭제 18 전 자 기 록 물 안전한 보존관리를 위하여 필요한 대책을 보존 및 수립·시행하여야 한다. ④ ⑤항에 기록관리기준표 관 리 < 개 정 ③ 행정정보 데이터세트의 저장은 진본성, 등록 관리를 포함한 2010.5.4.>) 이용가능성 등이 유지될 수 있는 방법이나 데이터세트 기록관리 형식으로 처리하여야 하며, 승인받지 현황관리 시스템 구축 근거

180

개선안 목적 현행 아니한 접근, 폐기 등으로부터 행정정보 데이터세트를 보호하는 방안을 수립·시행하여야 한다. ④ 중앙기록물관리기관은 각종 재난 등에 의한 행정정보 데이터세트의 손실을 방지하기 위하여 데이터, 기록매체, 시스템 등에 대한 전자적 복구 체계를 수립·시행하여야 한다. 마련 ④ 중앙기록물관리기관의 장은 공공기관이 데이터세트관리기준표를 등록하기 위한 절차와 방법을 마련해야 한다. ⑤ 중앙기록물관리기관의 장은 공공기관의 행정정보 데이터세트 관리 현황을 총괄하여 체계적으로 관리하고 점검 및 감독하기 위한 방안을 수립·시행하여야 한다. 데이터세트의 관리자에게 모든 권한을 주어, 데이터를 (행정정보 데이터세트의 관리 권한) 생성한 기관과 데이터 생성 행정정보 데이터세트의 관리를 책임지는 시스템과 데이터를 운영 및 공공기관의 장이 그 데이터세트의 관리와 관리하는 관리기관이 다를 19 처분을 결정하고 시행할 책임과 권한을 없음 시 관리기관에게 모든 가진다. 공공기관의 장은 필요 시 권한과 책임을 줌으로써 행정정보 데이터세트를 생성한 기관의 현실에 적용 가능하고 장에게 의견을 물을 수 있다. 효율적인 관리가 가능하도록 근거 마련 (행정정보 데이터세트의 기록관리 점검 기록관리자는 데이터세트의 감독 권한) ① 행정정보 데이터세트의 관리와 실래 점검, 기준표 관리를 책임지는 공공기관의 장은 해당 현행화 등을 위해 수시로 기록관의 장에게 상시 데이터세트의 시스템에 접근하여, 조회할 기록관리 실태 점검과 감독의 권한을 20 수 있어야 함. 그러나 없음 허가해야 한다. 시스템 관리 부서가 권한 ② 기록관의 장은 관리 대상 부여를 거부할 가능성이 행정정보시스템 관리 책임 부서장과 높으므로 이를 의무화해야 협의하여 점검 및 감독의 수단을 제공해야 함 한다.

<표 96> 행정정보 데이터세트 관리에 관한 신설 조항

181

[별지 제00호서식] 행정정보 데이터세트 평가심의서 ※ 처분단위 내 데이터세트 상세 목록은 필요에 따라 첨부할 수 있음

시스템 업무 담당자 기록물관리전문요원 단위기능 단위 보존기간 폐기 심의회 폐기자 폐기일 식별번호 기능 만료일 조건 처리 의견 사유 평가의견 사유 의견

<표 97> 행정정보 데이터세트 평가심의서

4.7. 데이터세트 기록관리를 위한 생산기관의 역할

가. 생산기관 역할의 중요성

○ 행정정보시스템에서 데이터가 생산된 이후 생산기관이 책임지고 관리하며 영구기록물관리 기관의 이관 요구가 없는 한 폐기 및 보존까지 생산기관이 수행해야 함

○ 따라서 데이터세트 생산기관이 데이터세트의 생애주기 전체에서 적극적으로 기록관리를 시행하여야 하므로 생산기관의 주체적 역할이 요구됨

○ 생산기관의 기록관리 담당자는 데이터세트의 생산, 폐기, 보존, 이관을 주관하는 중요한 역할자로서 영구기록물관리기관과의 협력 하에 정보기술 전문가 및 보존기술 전문가들과 행정정보시스템이 존속하는 오랜 기간 업무를 수행해야 하는 핵심 인력임

나. 생산기관의 역할

단계 프로세스 해야 할 일 영구기록물관리기관의 데이터세트 기록관리 계획을 접수 또는 기관 1 스스로 데이터세트 기록관리 계획을 수립하여 영구기록물관리기관에 통보한다. 데이터세트 대상 데이터세트를 관리하기 위하여 영구기록물관리기관과 생산기관이 준비 관리협의체 공동 참여하는 협의체 구성 계획을 수립한다. 계획에는 협의체 구성원을 등록 구성 2 포함한다. 협의체 구성원은 대상 행정정보시스템의 현업 담당과 시스템 담당이 참여해야 한다. 협의체 구성에 관하여 관련 부서의 협조를 요청한다. 3 시스템 및 현업 부서는 해당 시스템이 기록관리 대상임을 인식하고

182

단계 프로세스 해야 할 일 협의체에 참가할 담당자를 결정하여 기록관리 담당자에게 통보한다. 4 영구기록물관리기관의 협의체 구성원을 받아 협의체 활동을 개시한다. 관리 대상 시스템의 데이터세트 관리 단위를 결정하고 데이터세트 5 관리기준표 작성을 위하여 시스템을 분석하기 위한 계획을 수립한다. 시스템 필요 시 협의체의 영구기록물관리기관 담당자들의 협조를 요청한다. 분석 협의체의 영구기록물관리기관 담당자들이 시스템 분석을 위하여 자료 6 요청 시 생산기관의 해당 담당자들로부터 자료를 취합하여 제공한다. 만약 시스템이 개발 중일 경우 단위기능 추출과 단위기능별 폐기/보존이 7 쉽도록 기록관리 기능 추가를 요청한다. 시스템 시스템 담당자는 기록관리 기능을 검토하여 구현한다. 분석 협의체는 운영 중인 시스템을 산출물 및 시스템 실사, 인터뷰 등을 8 통하여 시스템을 조사하고 분석한다. 9 분석 결과를 이용하여 데이터세트관리기준표를 작성한다. 데이터세트관리기준표를 영구기록물관리기관이 정한 절차와 방법에 준비 따라 등록한다. 영구기록물관리기관이 평가 후 승인하면 식별번호 등록 (시스템 구분 + 기관코드 + 행정정보시스템 코드 + 단위기능 코드)를 10 받는다. 데이터세트 기준표의 등록과 식별번호를 받음으로써 기록관리 대상으로서 생산된 관리기준표 것으로 본다. 확정 행정정보시스템 운영 기간 동안 데이터의 생성, 운용, 참조가 일어날 때 데이터세트의 무결성을 보장할 수 있도록 시스템 담당자는 접근 제어 11 기능을 구현하고, 데이터에 대한 접근 내역을 모니터링할 수 있도록 감사추적 기능을 구현해야 한다. 데이터 시스템 담당자는 데이터베이스의 백업 정책을 세우고 백업을 실시해야 12 관리 한다. 시스템의 설계 변경이 일어날 시 시스템 담당과 현업 담당은 13 데이터세트관리기준표에 미치는 영향을 검토하여야 한다. 시스템 검토 결과 기준표의 내용만 변경될 경우 계획대로 설계 변경과 개발을 14 변경 관리 진행한다. 변경 내역을 기준표에 반영하여 수정한 뒤 영구기록물관리기관에 15 생산 통보한다. 기관 보존기간 도래 또는 시스템 중단이나 기관 폐지 등 처분 사유 발생 시 기록 16 기록관리 담당은 이를 인지하고 시스템 담당에게 처분 대상 검색 조건을 관리 명시하여 검색을 의뢰한다. 시스템 담당은 대상을 검색하고 검색 결과를 기록관리담당에게 17 처분 통보한다. 기록관리 담당은 생산 부서의 의견을 조회하여 처분 대상 단위기능을 18 심사한다. 기록관리 담당은 기록물평가심의회를 구성하여 처분 대상에 대하여 19 심의한다. 생산 심의 결과 폐기로 결정된 단위기능은 검색 조건과 함께 시스템 담당에게 20 기관 처분 폐기를 의뢰한다. 기록 21 시스템 담당은 폐기 대상을 운영 시스템과 추가 보존 장소로부터

183

단계 프로세스 해야 할 일 삭제한다. 심의 결과 기관 자체 보존이 필요할 시 협의체는 자체 보존을 위한 22 계획을 수립한다. 관리 23 심의 결과 처분 보류 시 운영 시스템에서 그대로 유지한다. 심의 결과와 그에 따라 실시한 처분 행위 내역을 기준표에 반영하여 24 수정한 뒤 영구기록물관리기관에 통보한다. 시스템 및 데이터의 변경, 또는 처분 등의 기록관리 활동으로 인해 25 데이터세트관리기준표의 내용 변경이 일어날 때 기준표를 현행화해야 기록관리 한다. 영구 모니터링 영구기록물관리기관의 기록관리 실태 점검 결과 이슈가 발견될 시 기록 26 협의체는 개선 방안을 수립하고 조치한 뒤 보고한다. 관리 데이터세트의 영구기록물관리기관 이관이 요청될 시 협의체는 이관 인수 27 방안을 협의하여 영구기록물관리기관이 제시하는 이관 규격에 따라 이관할 수 있도록 준비한다.

<표 99> 행정정보 데이터세트 생산기관의 역할

4.8. 데이터세트관리 시스템 설계

가. 시스템 서비스 개념도

<그림 151> 데이터세트 기록 관리 시스템 서비스 개념도

184

나. 기능 명세 및 개념 데이터 모델링

○ 기록관리 준비

기초 정보 관리

· 생산기관: 데이터세트 기록 관리 계획의 대상 생산기관을 등록, 관리

- 필수여부: 필수

- 프로세스명: 데이터세트 관리 협의체 구성

- 영구기록물 생산기관 담당자: 데이터세트 담당자 · 시스템 기초 정보: 데이터세트 기록 관리 계획의 대상 시스템의 기초 정보(생산기관, 정보시스템명)를 등록, 관리

- 필수여부: 필수

- 프로세스명: 데이터세트 관리 협의체 구성

- 영구기록물 생산기관 담당자: 데이터세트 담당자

데이터세트 기록 관리 준비 계획

· 기록 관리 준비 계획 등록: 데이터세트 기록 관리 계획을 수립하여 등록. 생산기관에 등록할 안내공문을 출력기능이 포함

- 필수여부: 선택

- 프로세스명: 데이터세트 관리 협의체 구성

- 영구기록물 생산기관 담당자: 데이터세트 담당자 · 기록 관리 준비 진행 현황: 관리 계획의 진행단계를 기록하고, 모니터링

- 필수여부: 선택

- 프로세스명: 데이터세트 관리 협의체 구성 - 영구기록물 생산기관 담당자: 데이터세트 담당자

데이터세트 준비상황 모니터링

· 준비단계 시스템 조회: 기준표가 확정되지 않은 시스템(기록관리 준비단계)의 목록을 진행 상태별로 검색, 조회, 진행상황 열람

- 필수여부: 선택

- 프로세스명: 데이터세트 관리 협의체 구성

- 영구기록물 생산기관 담당자: 데이터세트 담당자

협의체 관리

· 협의체 구성: 각 시스템별로 결정된 협의체 구성원을 등록하고 변경, 관리. 구성원별 역할 지정

- 필수여부: 선택

185

- 프로세스명: 데이터세트 관리 협의체 구성 - 영구기록물 생산기관 담당자: 데이터세트 담당자

○ 시스템 조사

시스템 조사 계획

· 시스템 조사 계획서: 시스템 조사 계획서를 등록, 협의체 구성원에게 전달 - 필수여부: 선택

- 프로세스명: 시스템 분석

- 영구기록물 생산기관 담당자: 데이터세트 담당자

· 시스템 조사 계획 의견: 시스템 조사 계획에 대한 의견을 등록. (접수된 의견을 참고 하여 조사 계획 수정) - 필수여부: 선택

- 프로세스명: 시스템 분석

- 생산기관 담당자: 업무 담당자. 시스템 담당자. 기록 담당자

- 영구기록물 생산기관 담당자: 데이터세트 담당자. 보존 담당자. 시스템 담당자

시스템 사전 조사

· 자료요청 및 제출: 사전조사 관련 자료를 요청. 요청받은 자료를 요청항목별로 제출

- 필수여부: 선택

- 프로세스명: 시스템 분석

- 생산기관 담당자: 업무 담당자. 시스템 담당자. 기록 담당자

- 영구기록물 생산기관 담당자: 데이터세트 담당자

· 사전조사 자료 열람: 사전조사 자료를 열람하고 다운로드

- 필수여부: 선택

- 프로세스명: 시스템 분석 - 영구기록물 생산기관 담당자: 데이터세트 담당자. 보존 담당자. 시스템 담당자

시스템 조사

· 시스템 조사서 설계: 각 단계별로 시스템 조사서를 템플릿을 기반으로 설계하여 등록

- 필수여부: 선택

- 프로세스명: 시스템 분석

- 영구기록물 생산기관 담당자: 데이터세트 담당자

· 시스템 조사서 설계 의견: 설계안에 대한 의견을 등록. (접수된 의견을 참고하여 조사서 항목 수정)

- 필수여부: 선택

186

- 프로세스명: 시스템 분석 · 시스템 조사서: 시스템 조사서의 내용을 작성, 관리, 수정. 수정된 조사항목은 이력 (이전내용,이후내용,수정자,수정일,수정사유) - 필수여부: 선택

- 프로세스명: 시스템 분석

- 생산기관 담당자: 업무 담당자. 시스템 담당자. 기록 담당자 - 영구기록물 생산기관 담당자: 데이터세트 담당자. 보존 담당자. 시스템 담당자

시스템 분석

· 시스템 분석보고서: 시스템 조사결과에 근거에 분석보고서 작성, 관리

- 필수여부: 선택 - 프로세스명: 시스템 분석

- 생산기관 담당자: 업무 담당자. 시스템 담당자. 기록 담당자

- 영구기록물 생산기관 담당자: 데이터세트 담당자. 보존 담당자. 시스템 담당자

○ 기준표 작성

기준표 작성

· 기준표 작성: 생산기관에서 기준표 템플릿에 근거하여 기관 기준표 작성, 수정

- 필수여부: 필수

- 프로세스명: 기관 기준표 작성

- 생산기관 담당자: 업무 담당자. 시스템 담당자. 기록 담당자

기준표 평가 및 보완

· 기준표 평가: 생산기관에서 작성된 기준표를 평가하여 의견을 작성. (수정의견이 있으면 생산기관에서 기준표를 보완) - 필수여부: 선택

- 프로세스명: 기관 기준표 작성

- 영구기록물 생산기관 담당자: 데이터세트 담당자. 보존 담당자. 시스템 담당자

· 기준표 보완: 기준표 평가의견에 따라 기준표 보완. (보완된 기준표는 다시 기준표 평 가를 진행)

- 필수여부: 선택

- 프로세스명: 기관 기준표 작성

- 생산기관 담당자: 업무 담당자. 시스템 담당자. 기록 담당자

기준표 승인

· 기준표 승인: 기준표 평가에 따라 수정의견이 없으면 기준표 승인

187

- 필수여부: 필수 - 프로세스명: 기관 기준표 작성

- 영구기록물 생산기관 담당자: 데이터세트 담당자

· 기록 등록: 승인된 기준표에 의거하여 관리단위별로 기록관리번호 부여 (기록관리번호는 기준표시스템에서 UUID기반으로 자동 부여)

- 필수여부: 필수 - 프로세스명: 기관 기준표 작성

- 생산기관 담당자: 기록 담당자

<그림 152> 개념 데이터 모델 - 「준비 등록」 프로세스 단계

○ 백업 및 보존

백업

· 백업 계획: 관리단위별로 백업계획을 수립, 등록

- 필수여부: 선택

- 프로세스명: 데이터 관리

- 생산기관 담당자: 업무 담당자. 시스템 담당자. 기록 담당자

· 백업 결과: 백업시 마다 백업 결과를 기록하고 현황을 조회

- 필수여부: 선택

- 프로세스명: 데이터 관리

- 생산기관 담당자: 업무 담당자. 시스템 담당자. 기록 담당자

보존

· 보존 계획: 운영데이터베이스외 데이터베이스에 보존하는 경우 계획을 등록

188

- 필수여부: 선택 - 프로세스명: 데이터 관리

- 생산기관 담당자: 업무 담당자. 시스템 담당자. 기록 담당자

· 보존 결과: 데이터베이스 보존 결과를 기록하고 현황을 조회 - 필수여부: 선택

- 프로세스명: 데이터 관리

- 생산기관 담당자: 업무 담당자. 시스템 담당자. 기록 담당자

· 메타데이터 등록: 보존단위별로 메타데이터 입력 등 관리

- 필수여부: 선택

- 프로세스명: 데이터 관리 - 생산기관 담당자: 기록 담당자

○ 감사 추적

감사추적

· 감사추적 API: 기록관리 대상 데이터의 생성, 운영, 참조 등 기록관리 항목 발생시 해당 결과내용은 행정정보시스템에서 감사추적서비스로 데이터를 전송하고, 수집할 수 있는 API

- 필수여부: 선택

- 프로세스명: 데이터 관리

· 데이터 생성 추적: 데이터 생성 내역을 조회, 기간별, 데이터별 통계 열람

- 필수여부: 선택

- 프로세스명: 데이터 관리

- 생산기관 담당자: 업무 담당자. 시스템 담당자. 기록 담당자

· 데이터 운용 추적: 데이터 운용 내역을 조회, 기간별, 데이터별 통계 열람

- 필수여부: 선택 - 프로세스명: 데이터 관리

- 생산기관 담당자: 업무 담당자. 시스템 담당자. 기록 담당자

· 데이터 참조 추적: 데이터 참조 내역을 조회, 기간별, 데이터별 통계 열람

- 필수여부: 선택

- 프로세스명: 데이터 관리

- 생산기관 담당자: 업무 담당자. 시스템 담당자. 기록 담당자 · 감사추적데이터 문서화: 추적데이터를 주기별로 문서화하는 기능을 수행하는 기능

- 필수여부: 선택

- 프로세스명: 데이터 관리

189

- 생산기관 담당자: 업무 담당자. 시스템 담당자. 기록 담당자

○ 기준표 관리

기준표 변경사유

· 설계 변경 계획: 설계 변경 계획 등록

- 필수여부: 선택 - 프로세스명: 시스템변경관리, 기관기준표 관리

- 생산기관 담당자: 업무 담당자. 시스템 담당자

· 설계 변경 계획 의견: 설계 변경 계획을 보고 기존 기준표 영향(변경)에 대한 의견 작성 (기준표 변경 필요시 기준표 변경사유 등록)

- 필수여부: 선택 - 프로세스명: 시스템변경관리, 기관기준표 관리

- 생산기관 담당자: 기록 담당자

· 설계 변경 결과: 설계 변경 계획에 따라 시스템의 설계변경을 수행한 경우 작성

- 필수여부: 선택

- 프로세스명: 시스템변경관리, 기관기준표 관리

· 기준표 변경사유 등록: 기준표 변경 사유를 등록, 협의체 구성원에게 전달

- 필수여부: 선택

- 프로세스명: 시스템변경관리, 기관기준표 관리

- 생산기관 담당자: 기록 담당자

· 기준표 변경사유 검토: 기준표 변경사유에 따른 기준표 변경 의견 작성, 관리

- 필수여부: 선택

- 프로세스명: 시스템변경관리, 기관기준표 관리 - 생산기관 담당자: 업무 담당자. 시스템 담당자. 기록 담당자

- 영구기록물 생산기관 담당자: 데이터세트 담당자. 보존 담당자. 시스템 담당자

기준표 수정

· 기준표 수정: 기준표 변경사유 의견에 따라 생산기관에서 기준표 수정

- 필수여부: 필수

- 프로세스명: 시스템변경관리, 기관기준표 관리

- 생산기관 담당자: 업무 담당자. 시스템 담당자. 기록 담당자

기준표 수정 평가 및 보완

· 기준표 수정 평가: 생산기관에서 수정한 기준표를 평가하여 의견을 작성. (수정의견이 있으면 생산기관에서 기준표를 보완)

190

- 필수여부: 선택 - 프로세스명: 시스템변경관리, 기관기준표 관리

- 영구기록물 생산기관 담당자: 데이터세트 담당자. 보존 담당자. 시스템 담당자

· 기준표 수정 보완: 기준표 수정 평가의견에 따라 기준표 보완. (보완된 기준표는 다시 기준표 평가를 진행)

- 필수여부: 필수 - 프로세스명: 시스템변경관리, 기관기준표 관리

- 생산기관 담당자: 업무 담당자. 시스템 담당자. 기록 담당자

기준표 수정 승인

· 기준표 수정 승인: 기준표 수정 평가에 따라 수정의견이 없으면 기준표 승인 - 필수여부: 필수

- 프로세스명: 시스템변경관리, 기관기준표 관리

- 영구기록물 생산기관 담당자: 데이터세트 담당자

<그림 153> 개념 데이터 모델 - 「기관 기준표 관리」 프로세스 단계

○ 처분, 보존

처분 계획

· 처분검토요청: 시스템 구조 변경 및 폐지 등으로 보존기관 도래와 관계없이 기록물 처분 검토가 필요한 경우 등록

- 필수여부: 선택

- 프로세스명: 처분

- 생산기관 담당자: 업무 담당자. 시스템 담당자. 기록 담당자

· 처분대상현황: 보존기간이 도래하였거나 처분 검토요청이 있는 처분대상 기록물을 조회, 검색

191

- 필수여부: 필수 - 프로세스명: 처분

- 생산기관 담당자: 업무 담당자. 시스템 담당자. 기록 담당자

· 처분 대상 선정: 처분대상현황에 조회된 기록물과 시스템 폐지 등의 사유로 발생한 처분 대상을 선정

- 필수여부: 선택 - 프로세스명: 처분

- 생산기관 담당자: 기록 담당자

· 처분 계획: 선정된 처분 대상별로 처분계획을 수립, 작성 - 필수여부: 선택

- 프로세스명: 처분

- 생산기관 담당자: 기록 담당자

· 의견등록: 처분 계획에 대한 담당자의견을 등록 (의견을 참고하여 처분계획을 수정)

- 필수여부: 선택

- 프로세스명: 처분 - 생산기관 담당자: 업무 담당자. 시스템 담당자. 기록 담당자

폐기심의

· 폐기심의: 평가폐기 심의회 개최를 위하여 심의서 작성 및 기록물평가심의회에서 결정한 심의결과를 등록하는 기능

- 필수여부: 선택

- 프로세스명: 처분 - 생산기관 담당자: 기록 담당자

- 영구기록물 생산기관 담당자: 데이터세트 담당자. 보존 담당자

처분 처리

· 처분 처리: 폐기 또는 자가보존, 이관 등 처분 결과를 등록 - 필수여부: 필수

- 프로세스명: 처분

- 생산기관 담당자: 업무 담당자. 시스템 담당자. 기록 담당자 · 자가보존 계획: 처분계획단계에서 자가보존으로 결정된 기록물에 자가보존 계획을 수립, 등록

- 필수여부: 선택

- 프로세스명: 처분

- 생산기관 담당자: 업무 담당자. 시스템 담당자. 기록 담당자

192

· 결과반영: 폐기 또는 자가보존, 이관 등 처분 결과를 등록 - 필수여부: 필수

- 프로세스명: 처분

- 생산기관 담당자: 업무 담당자. 시스템 담당자. 기록 담당자 · 처분 처리 현황: 처분대상 기록물별로 처분현황(처분요청, 계획수립중, 심의중, 자가보존, 폐기, 이관, 처분보류)을 조회 - 필수여부: 필수

- 프로세스명: 처분

- 생산기관 담당자: 업무 담당자. 시스템 담당자. 기록 담당자 - 영구기록물 생산기관 담당자: 데이터세트 담당자. 보존 담당자. 시스템 담당자

<그림 154> 개념 데이터 모델 - 「처분」 프로세스 단계

○ 기록관리

기록관리 등록

· 기록관리 자동 등록: 각 관리단위별로 사용자의 모든 행위가 기록(사용자, 일시, 기록관리행위, 변경전데이터, 변경후데이터)

- 필수여부: 필수

- 프로세스명: 기록관리모니터링

- 생산기관 담당자: 업무 담당자. 시스템 담당자. 기록 담당자 - 영구기록물 생산기관 담당자: 데이터세트 담당자. 보존 담당자. 시스템 담당자

· 기록관리 수동 등록: 각 관리단위별로 기록관리 행위를 수동으로 등록. 기록관리 행위 등록 시 이슈도 등록

- 필수여부: 필수

- 프로세스명: 기록관리모니터링

- 생산기관 담당자: 업무 담당자. 시스템 담당자. 기록 담당자

193

- 영구기록물 생산기관 담당자: 데이터세트 담당자. 보존 담당자. 시스템 담당자

기록관리 현황

· 기록관리 현황: 기록관리 현황을 조회 (시스템별, 관리단위별, 수동/자동, 행위별, 사용자별, 기간별, 이슈구분별, 기준표템 플릿 버전별, 모니터링결과 등록여부별) - 필수여부: 필수

- 프로세스명: 기록관리모니터링

- 영구기록물 생산기관 담당자: 데이터세트 담당자

· 기록관리 모니터링 결과: 기록관리 현황을 조회하고 조회된 기록관리 행위에 대한 모니터링 결과를 등록. 기준표 수정이 필요하면 해당 의견 기록 - 필수여부: 필수

- 프로세스명: 기록관리모니터링

- 영구기록물 생산기관 담당자: 데이터세트 담당자

기록관리 개선

· 개선 방안 계획: 기록관리와 관련된 문제에 대산 개선계획을 수립

- 필수여부: 선택

- 프로세스명: 기록관리모니터링

- 생산기관 담당자: 업무 담당자. 시스템 담당자, 기록 담당자

- 영구기록물 생산기관 담당자: 데이터세트 담당자, 보존 담당자, 시스템 담당자

· 개선 방안 조치 결과: 기록관리 개선 계획에 따른 조치 결과를 기록, 관리 - 필수여부: 선택

- 프로세스명: 기록관리모니터링

- 생산기관 담당자: 업무 담당자. 시스템 담당자, 기록 담당자

- 영구기록물 생산기관 담당자: 데이터세트 담당자, 보존 담당자, 시스템 담당자

○ 감사 추적

감사추적

· 데이터 생성 추적: 데이터 생성 내역을 정보시스템별, 관리단위별 조회, 기간별, 데이터별 통계 열람

- 필수여부: 필수 - 프로세스명: 기록관리모니터링

- 영구기록물 생산기관 담당자: 데이터세트 담당자, 보존 담당자, 시스템 담당자

· 데이터 운용 추적: 데이터 운용 내역을 정보시스템별, 관리단위별 조회, 기간별, 데이터별 통계 열람

- 필수여부: 필수

194

- 프로세스명: 기록관리모니터링 - 영구기록물 생산기관 담당자: 데이터세트 담당자. 보존 담당자. 시스템 담당자

· 데이터 참조 추적: 데이터 참조 내역을 정보시스템별, 관리단위별 조회, 기간별, 데이터별 통계 열람

- 필수여부: 필수

- 프로세스명: 기록관리모니터링 - 영구기록물 생산기관 담당자: 데이터세트 담당자, 보존 담당자, 시스템 담당자

· 감사추적데이터 문서화: 추적데이터를 주기별로 문서화하는 기능을 수행하는 기능

- 필수여부: 필수 - 프로세스명: 기록관리모니터링

- 영구기록물 생산기관 담당자: 데이터세트 담당자, 보존 담당자, 시스템 담당자

○ 총괄 기준표

총괄 기준표 관리

· 기준표 관리 현황: 생산기관, 영구기관별 기준표 관리 현황을 조회, 열람

- 필수여부: 필수

- 프로세스명: 총괄 기준표 관리

- 영구기록물 생산기관 담당자: 데이터세트 담당자, 보존 담당자, 시스템 담당자

· 기준표 관리 현황 통계: 생산기관, 영구기관별 기준표 관리 현황에 대한 통계 정보 및 보고서를 생성, 열람, 다운로드

- 필수여부: 필수

- 프로세스명: 총괄 기준표 관리

- 영구기록물 생산기관 담당자: 데이터세트 담당자, 보존 담당자, 시스템 담당자

기준표 템플릿 관리

· 기준표 항목 관리: 기준표 템플릿에 사용되는 항목을 설계 (각 항목에는 항목명과 입력규칙, 예시, 주의사항 등이 명시)

- 필수여부: 필수

- 프로세스명: 총괄 기준표 관리

- 영구기록물 생산기관 담당자: 데이터세트 담당자

· 기준표 템플릿 관리: 기준표 템플릿을 설계, 작성. 개발단계, 버전별로 관리하여 생산기관 기준표의 템플릿버전을 추적. (템플릿 개발단계에 따라 Pre-alpha, Alpha, Beta, RC, GA로 구분) - 필수여부: 필수

- 프로세스명: 총괄 기준표 관리

195

- 영구기록물 생산기관 담당자: 데이터세트 담당자 · 기준표 템플릿 개선: 기준표 템플릿의 버전별로 개선사항을 기록. 시범적용 현황 및 평가를 기록 - 필수여부: 선택

- 프로세스명: 총괄 기준표 관리

- 영구기록물 생산기관 담당자: 데이터세트 담당자. 보존 담당자. 시스템 담당자

시스템 조사서 템플릿 관리

· 시스템 조사서 항목 관리: 시스템 조사서 템플릿에 사용되는 항목을 설계 (각 항목에는 항목명과 입력규칙, 예시, 주의사항 등이 명시) - 필수여부: 선택

- 프로세스명: 총괄 기준표 관리

- 영구기록물 생산기관 담당자: 데이터세트 담당자

· 시스템 조사서 템플릿 관리: 시스템 조사서 템플릿을 설계, 작성. 개발단계, 버전별로 관리하여 시스템 조사 결과의 템플릿버전을 추적. (템플릿 개발단계에 따라 Pre-alpha, Alpha, Beta, RC, GA로 구분)

- 필수여부: 선택

- 프로세스명: 총괄 기준표 관리

- 영구기록물 생산기관 담당자: 데이터세트 담당자

· 시스템 조사서 템플릿 개선: 시스템 조사서 템플릿의 버전별로 개선사항을 기록. 시범적용 현황 및 평가를 기록

- 필수여부: 선택 - 프로세스명: 총괄 기준표 관리

- 영구기록물 생산기관 담당자: 데이터세트 담당자. 보존 담당자, 시스템 담당자

<그림 155> 개념 데이터 모델 - 「기록관리 모니터링, 총괄 기준표 관리」 프로세스 단계

196

○ 이관, 인수

인수준비

· 인수대상 목록: 처분단계에 이관 처분 결정된 기록물과 처분보류 기록물 조회

- 필수여부: 필수

- 프로세스명: 인수 - 생산기관 담당자: 기록 담당자

- 영구기록물 생산기관 담당자: 데이터세트 담당자

· 인수계획: 인수방법, 일정, 협의체, 의견을 등록, 관리

- 필수여부: 선택

- 프로세스명: 인수

- 생산기관 담당자: 기록 담당자

- 영구기록물 생산기관 담당자: 데이터세트 담당자. 보존 담당자, 시스템 담당자

인수진행

· 인수 처리 결과: 인수계획에 따른 처리 결과(진행상태, 검수결과, 의견, 반려 등)를 기록, 조회

- 필수여부: 필수

- 프로세스명: 인수

- 생산기관 담당자: 업무 담당자, 시스템 담당자, 기록 담당자

- 영구기록물 생산기관 담당자: 데이터세트 담당자, 보존 담당자, 시스템 담당자

· 인수현황 모니터링: 인수대상, 인수계획, 인수 처리 결과 등 인수현황을 총괄적으로 조회

- 필수여부: 선택

- 프로세스명: 인수

- 생산기관 담당자: 업무 담당자, 시스템 담당자, 기록 담당자 - 영구기록물 생산기관 담당자: 데이터세트 담당자, 보존 담당자, 시스템 담당자

인수목록

· 인수대장: 인수가 완료된 기록물의 처리 결과를 조회, 열람

- 필수여부: 필수

- 프로세스명: 인수

- 영구기록물 생산기관 담당자: 데이터세트 담당자. 보존 담당자. 시스템 담당자

○ 보존 포맷

문서보존포맷변환

· 문서 포맷 변환: 기록물별로 문서보존 대상을 포맷변환작업을 실행하고, 포맷변환

197

결과를 등록

- 필수여부: 선택

- 프로세스명: 보존

- 영구기록물 생산기관 담당자: 보존 담당자

· 포맷변환현황: 기록물 분류, 데이터세트 항목을 기준으로 문서보존포맷 변환대상 및 변환작업 진행 상태를 조회

- 필수여부: 선택 - 프로세스명: 보존

- 영구기록물 생산기관 담당자: 보존 담당자

데이터세트 컨텐츠

· 데이터세트컨텐츠해석기능: 각 관리단위별 데이터세트를 해당보존시스템의 agent를 통해 컨텐츠를 검색, 열람할 수 있는 기능

- 필수여부: 선택

- 프로세스명: 보존

- 영구기록물 생산기관 담당자: 보존 담당자

· 데이터세트 컨텐츠 해석기 관리: 각 기록물별로 컨텐츠 해석엔진 정보를 기록, 구동 테스트를 진행할 수 있는 기능

- 필수여부: 선택

- 프로세스명: 보존

- 영구기록물 생산기관 담당자: 보존 담당자, 시스템 담당자

○ 재평가 및 재분류

보존기간 재평가

· 보존기간 재평가: 기록물별로 보존기간을 변경해야 하는 항목을 추출하여 재평가 계획을 등록, 계획별 결과를 기록

- 필수여부: 선택

- 프로세스명: 보존

- 영구기록물 생산기관 담당자: 보존 담당자 · 보존기간 재분류: 보존기간 재분류가 결정된 기록물을 재분류

- 필수여부: 필수

- 프로세스명: 보존

- 영구기록물 생산기관 담당자: 보존 담당자

· 보존기간 재분류 현황: 보존기간 재분류가 된 기록물의 현황 조회 및 상세 과정 열람

- 필수여부: 필수

198

- 프로세스명: 보존 - 영구기록물 생산기관 담당자: 보존 담당자

공개 재평가

· 공개 재평가: 기록물별로 공개 재분류 대상을 추출하여 재평가 계획을 등록, 계획별 결과를 기록

- 필수여부: 선택

- 프로세스명: 보존

- 영구기록물 생산기관 담당자: 보존 담당자

· 공개 재분류: 공개 재분류가 결정된 기록물을 재분류

- 필수여부: 필수 - 프로세스명: 보존

- 영구기록물 생산기관 담당자: 보존 담당자

· 공개 재분류 현황: 공개 재분류가 된 기록물의 현황 조회 및 상세 과정 열람

- 필수여부: 필수

- 프로세스명: 보존

- 영구기록물 생산기관 담당자: 보존 담당자

분류체계 재평가

· 분류체계 재평가: 기록물별로 분류체계 재평가 대상을 추출하여 재평가 계획을 등록, 계획별 결과를 기록 - 필수여부: 선택

- 프로세스명: 보존

- 영구기록물 생산기관 담당자: 보존 담당자

· 분류체계 재분류: 분류체계 재분류가 결정된 기록물을 재분류

- 필수여부: 필수

- 프로세스명: 보존 - 영구기록물 생산기관 담당자: 보존 담당자

· 분류체계 재분류 현황: 분류체계 재분류가 된 기록물의 현황 조회 및 상세 과정 열람

- 필수여부: 필수 - 프로세스명: 보존

- 영구기록물 생산기관 담당자: 보존 담당자

○ 접근 제어

접근 제어

199

· 접근 관리: 보존중인 데어터세트에 대한 접근(활용, 관리) 권한 설정 - 필수여부: 필수 - 프로세스명: 보존

○ 보존 현황

보존현황 · 보존 기록물: 보존 활동 및 기록관리 활동현황 등을 등록, 조회 - 필수여부: 필수 - 프로세스명: 보존 - 영구기록물 생산기관 담당자: 보존 담당자

○ 메타데이터

메타데이터 관리 · 메타데이터 설정: 메타데이터 표준을 참고하여 메타데이터의 초기 값을 설정, 편집하는 기능 - 필수여부: 필수 - 프로세스명: 보존 - 영구기록물 생산기관 담당자: 데이터세트 담당자, 보존 담당자 · 메타데이터 관리: 보존단위별로 메타데이터 입력 등 관리 - 필수여부: 필수 - 프로세스명: 보존 - 영구기록물 생산기관 담당자: 보존 담당자

<그림 156> 개념 데이터 모델 - 「인수, 보존」 프로세스 단계

○ 요청 및 승인

데이터 세트 요청

· 데이터세트 요청 목록: 서비스 API를 통해 요청된 목록을 조회. 타방법(이메일, 공문등)

200

을 통해 접수된 요청건을 등록

þ 필수여부: 선택 þ 프로세스명: 활용 þ 생산기관 담당자: 업무 담당자, 시스템 담당자, 기록 담당자 þ 영구기록물 생산기관 담당자: 데이터세트 담당자, 보존 담당자, 시스템 담당자 데이터 세트 열람 승인 · 데이터세트 검색: 생산기관 및 영구기록물 생산기관 전체의 데이터세트 기준표를 기준 으로 데이터세트 정보 검색

þ 필수여부: 필수 þ 프로세스명: 활용 þ 생산기관 담당자: 업무 담당자, 시스템 담당자, 기록 담당자 þ 영구기록물 생산기관 담당자: 데이터세트 담당자, 보존 담당자, 시스템 담당자 · 데이터세트 검색 및 열람 승인: 요청한 데이터세트의 기록현황을 검색하여 열람을 승인, 열람방식은 API나 문서출력, 문서다운로드를 선택

þ 필수여부: 필수 þ 프로세스명: 활용 þ 생산기관 담당자: 기록 담당자 þ 영구기록물 생산기관 담당자: 데이터세트 담당자 · 데이터세트 요청/열람 API 관리: 데이터세트 요청/열람 API의 등록현황(시스템, 도메인, 승인키)을 관리

þ 필수여부: 선택 þ 프로세스명: 활용 þ 생산기관 담당자: 시스템 담당자 þ 영구기록물 생산기관 담당자: 시스템 담당자

<그림 157> 개념 데이터 모델 - 「활용」 프로세스 단계

201

4.9. 데이터세트 장기보존 방안

가. 데이터세트 장기보존 전략

○ 데이터세트 현장조사 분석 결과 및 설계 방향에서 확인한 바와 같이 데이터세트마다 고유한 특성이 다르기 때문에 장기보존 기본 원칙을 지키되 데이터세트의 특성을 기반으로 장기보존 계획을 수립해야 할 것임

○ 데이터세트의 구성 요소는 정형 데이터베이스와 비정형 전자파일임. 이 중 데이베이스는 데이터세트 현장조사 결과에서 보듯이 모두 관계형 데이터베이스가 대부분을 차지함. 관계형 데이터베이스 이관 및 보존 포맷 규격으로 스위스 국가기록원이 특정 데이터베이스관리시스템 공급자로부터 독립적인 포맷으로 개발한 SIARD가 유럽을 중심으로 아카이브 기관에서 많이 이용되고 있음. 국내에서도 관계형 데이터베이스 이관과 장기보존 시 SIARD(Software Independent Archiving of Relational Databases) 포맷과 오픈소스 도구를 검토하여 활용할 필요가 있음

○ 기타 비정형 전자 파일은 유형 별 보존포맷으로 변환하도록 하며, 이 때 국가기록원에서 제공하는 포맷 레지스트리(Digital Format Registry, DFR)와 연계하여 포맷을 검증하고 재현과 관련된 정보를 획득하여 보존 포맷 변환 또는 재현 시 이용함으로써 다양한 유형 전자기록 보존

○ 영구기록관리기관은 보존 패키지를 입수하여 검수 후 영구보존하며 보존 패키지를 활용용 포맷으로 변환하여 빠르고 효율적인 검색 등의 활용 서비스를 제공하도록 함. 데이터세트의 구성요소로서 이관된 비정형 전자 파일 재현 시 역시 포맷 레지스트리를 활용하도록 함

<그림 158> 데이터세트 장기보존 전략

202

나. 스위스 국가기록원 데이터세트 보존 사례

○ 선행 연구는 해외에서 데이터세트를 장기보존하거나 이관한 사례를 고찰하였으며, 특히 많은 기관이 스위스 국가기록원이 개발한 SIARD 규격을 많은 채택하고 있음. 이에 본 연구에서는 시스템별 이관 방법과 절차를 계획할 때 모범 사례로서 참조할 SIARD 사례를 고찰하고자 함

○ 스위스 국가기록원(Swiss Federal Archives, 이하 SFA)에서는 Digital Archiving Policy를 통해 데이터세트를 포함한 전자기록물에 대한 아카이빙 방안을 제시한다. 텍스트, 이미지, 오디오, 문서, 데이터베이스 등을 전자기록물로 정의하고 있음

○ 데이터세트

행정정보와 관련된 기록물의 아카이빙 필요성을 느끼고 있기 때문에, 이에 대한 아카이빙을 하고 있는 것으로 데이터세트의 범주를 명확하게 정의하고 있지는 않고 있으나, 데이터베이스에 저장되는 행정, 과학, 경제 등 국가적으로 가치가 있다고 판단되는 데이터를 데이터세트로 간주함

실제 데이터(primary data)와 그에 대한 설명데이터(descriptive metadata)를 디지털 아카이빙 범위로 지정

primary data란 실제 데이터베이스에 저장되는 기록

descriptive metadata란 실제 데이터베이스에 저자되는 기록의 의미를 설명하는 데이터로써, 데이터만 보존할 경우 향후 해당 데이터가 의미하는 바를 알 수 없기 때문에 메타데이터를 함께 보존하여야 함

SFA에서는 디지털 기록물을 다음과 같이 분류하고 있다. 기록관리시스템(Record Management System)으로부터 생산된 기록물, 데이터베이스(Relational Database)로부터 생산된 기록물, 그 밖의 전자 기록물(ex. 파일시스템)

○ 아카이빙 프로세스

‘아카이빙’ 과 ‘아카이빙 프로세스’의 의미는 기록관리를 위한 모든 프로세스를 일컬으며 아래의 5단계로 나누고 있음

· 1단계 사전 작업(Pre-archiving advisory service) : 기록물생산(제출)기관에서 이관을 위한 준비를 하는데 있어 필요한 정보를 지원하고 기록물생산기관에서 새로운 시스템을 구축할 경우, 아카이빙 요구사항에 대한 지원(technical application, database, records, precess management system) 함. 기록물 아카이빙에 대한 지식이 부족한 기관에 대해서 스위스 국가기록원에서 지원

· 2단계 평가(Appraisal) : 이관대상 기록물 선정을 위한 평가는 기록물생산기관과 SFA간의 협업을 통해 이루어져야 함. 기록물생산기관의 성격에 따라 선정에 필요한 기준을 마련하고, 해당 기준을 통해 대상 기록물 선정을 하는 것까지 기록물생산기관 담당자와 SFA담당자간의 협업을 통해 이루어짐

· 3단계 이관(ingest) : SIP specification에 따라 생성된 SIP만을 이관해야 한다. SIP

203

구조, 컴포넌트, 데이터 포맷, 메타데이터 프레임워크 등에 대한 스펙을 정의하고 있고, 기록물생산기관은 다음과 같은 책임이 수반됨. SIP에는 실제 데이터(primary data)와 그에 대한 메타데이터(related metadata)를 포함함. 이관 대상 기록물은 특정 애플리케이션에 의존하지 않는 보존 파일 포맷으로 변환(Software-independent)하고 SFA requirements에 따른 SIP 생성. 이관 대상 기록에 대한 입수 단계에서 SIP를 검사하고 패키징이 제대로 되지 않은 경우 인수하지 않음. 습득된 SIP는 그대로 SFA’s digital repository에 AIP로 보관하게 됨

· 4단계 기록물 보존(Safe-keeping) : 기록물의 생산, 저장, 보존 단계에서 기록물의 무결성, 진본성을 보장하기 위한 계획이 수립된다. 다양한 전자기록물 유형을 모두 포괄할 수 있는 메타데이터(administrative, descriptive, structural and technical metadata)를 이용하여 무결성, 진본성을 보장함. 메타데이터는 Archive information system(AIS)에 기록물(primary data)와 함께 AIP로서 보관됨. SFA는 안전한 보존을 위하여 전자기록물을 3개의 복사본(copies)으로 구성하여 분산 저장. 분산 저장은 물리적으로 분리된 저장 공간(storage)에 나누어 보관하고 한번 SFA’s digital repository에 AIP로 저장된 기록물에 대해서는 삭제하지 않음. 보존된 기록물에 대한 수정본을 새롭게 보존할 경우에는 새로운 AIP를 생성하되 기존 AIP를 삭제하지 않고 보관(versioning). 기록물에 대한 버전 관리를 통해 예전 버전에 대한 접근도 가능하도록 함

· 5단계 배포 및 접근(Access) : SFA에서는 보존 기록물에 대한 무결성 보장 및 예전 버전에 대한 접근이 가능하며, 이를 보장하기 위한 정보(AIP-ID, dossier-ID)를 AIS에 저장. 이관 기록물마다 AIP-ID(SFA‘s digital repository 에 존재하는 전체 기록물에 대한 유니크한 ID), dossier-ID(하나의 Information Package에서 유니크한 ID)를 가진다. dossier-ID는 서로 다른 버전의 기록물들 간에 구분을 위한 식별자에 해당됨. AIP-ID의 경우 UUID(Universally Unique Identifier)를 이용. SFA는 기록물 접근에 대한 다음과 같은 방법을 제공함. 일반 사용자가 접근 가능한 기록물 제공, 기록물생산기관이 접근 가능한 기록물(보통 기록물생산기관 자체 기록물로써 SFA와 기록물생산기관간의 협의를 통해 결정)을 제공, 온라인 접근이 가능하고 요구가 있는 기록물들에 대해서는 온라인 접근을 제공함. 아카이빙 기록물을 제공하기 위해서는 실제 기록물(primary data)와 그와 관련된 메타데이터를 제공해야 함. 배포 및 접근을 위해 AIP에서 제공될 수 없는 정보를 제외한 DIP를 생산하고 SFA에서는 DIP(Dissemination Information Package)형태로 제공하며, 실제 기록물(primary data)와 AIP 내부의 메타데이터 중 일부(배포를 위한 일부요건)로 구성됨

○ 아카이빙 전략

SFA에서는 Migration principle을 기본 전제로 하기 때문에 기록물에 대해 필요할 때마다 알맞은 포맷으로 마이그레이션을 수행함으로써 가용성(usability)를 유지함

관계형 데이터베이스에 대해서는 SIARD 포맷으로 변환하여 Software-independent를 유지

기존의 데이터세트 관리를 위한 시스템 애플리케이션에 종속되지 않는 독립적인 아카이빙 전략(application-independent archiving)

이관대상 전자기록물은 콘텐츠와 콘텐츠간 관계정보를 SFA 저장소로 전송

204

○ 보존포맷

기록물생산기관은 지정된 포맷으로 변환하여 이관할 책임이 있고, SFA에서는 포맷 변환에 대해서 기록물 생산기관에서 필요로 하는 사전 작업을 위한 조언 및 지원(pre-archiving advisory services)를 제공

기존 보존 포맷이 구형화될 경우 새로운 보존 포맷으로 대체할 수 있으며, 기존에 저장되어 있던 구형 포맷에 대해서는 SFA에서 새로운 보존 포맷으로 변환

이관 당시의 보존 포맷 변환은 기록물생산기관에서 수행하지만, SFA로 이관된 이후의 기록물에 대한 새로운 보존 포맷으로의 변환은 SFA에서 담당

데이터유형 제목

UTF-8 UTF-16 Text(unstructured) Plain text ISO-8859-1 ISO-8859-15 US-ASCII

“Office”document PDF/A

Tables CSV

Relational databases SIARD RDB DATA

Raster image TIFF

Audio WAVE

<표 100> 디지털 레코드에 대한 아카이빙 표준 포맷

○ SIARD Suite

SIARD Suite는 DBMS의 DB를 SIARD 파일로 변환시켜주는 도구로 관계형 데이터베이스에서 사용 되며, 데이터 보관시 SIARD 포맷으로 변환함. 데이터 마이그레이션 도구로도 사용함. SIARD Suite (SIARD Suite-1.91a 버전 사용) 메인화면은 다음과 같음

205

<그림 159> SIARD Suite 메인 화면

SIARD Suite 기능

· New from database는 DBMS의 데이터베이스를 SIARD 파일로 변환하는 기능

· Export metadata는 SIARD 포맷의 메타데이터를 추출하는 기능

· Load into database는 SIARD 파일에 저장되어 있는 데이터를 DBMS에 적재 시키는 기능

SIARD 포맷으로 변환

· New from database를 눌러서 SIARD 포맷의 이름을 정하면 Load SIARD file from Database 화면이 나옴

· Connect type에서는 사용하고 있는 DBMS를 선택(5가지의 DBMS를 지원)

· Connection Info에서는 DBMS의 서버를 기입

· Database user, Database password를 입력하고 Open 버튼을 클릭하면 SIARD 포맷으로 변환이 시작

206

<그림 160> 데이터베이스로부터 추출한 SIARD 파일

SIARD 파일의 데이터 확인

· SIARD 포맷으로 변환이 완료 되면 SIARD Suite에서 SIARD 파일의 데이터를 아래 그림과 같이 확인할 수 있고, 파일명.SIARD 파일이 생성

<그림 161> SIARD 파일의 데이터 확인

○ ZIP64

라이브러리의 오리지널 코드는 스위스 국가기록원의 SIARD Suite의 부분으로 2007년에 개발 되었고 많은 양의 데이터베이스를 표준화된 독립 플랫폼 컨테이너 포맷으로 아카이빙하기

207

위해서는 4GB 보다 큰 파일들과 기존 툴에 의해 수용될 수 있었던 65536개의 파일보다 많은 파일을 수용하는 것을 필요로 함으로써 XML 파일을 포함하고, 메타데이터를 보유하며, 데이터베이스 구조를 묘사할 수 있는 ZIP 파일을 결정하게 됨

XML 파일은 Primary 테이블 데이터와 LOBS(관계데이터베이스의 장기간 보존을 위한 기본 포맷)와 같은 데이터베이스 바이너리 파일을 포함함

SIARD파일은 SIARD Suite에서 생성될 때 ZIP64에 의해서 SIARD 포맷으로 압축됨

SIARD파일을 압축을 풀어보면 다음과 같다. zip64-1.04 버전으로 java -jar “zip64.jar 경로” x “-d=압축을 푼 후 생성 될 폴더의 경로” “.siard 파일의 경로”로 압축을 해제한 예임

<그림 162> SIARD 파일을 zip64로 압축풀기

5. 차세대 기록관리시스템 설계

5.1. 차세대 기록관리시스템 설계 방향

가. 개요

○ 기록관리 대상의 확대와 정보시스템 환경 변화 및 정보기술의 비약적 발전으로 기록관리 프로세스의 전면적 개편이 필요

정보화 사회로 접어들면서 정보와 기록, 데이터의 경계선을 구분하는 것 자체가 무의미해지고 있는 현실에서 관리대상 기록의 설정과 관리 방법에 대한 재정의 요구

또한 기록정보 자원에 대한 유연한 관리접근을 위한 정보거버넌스 필요

클라우드를 기반으로 한 정보시스템 환경 변화와 다양한 애플리케이션간의 유기적 결합의 용이성은 기록정보자원 간 연계를 통한 보다 가치 있는 기록정보서비스를 실현할 수 있는 여건이 조성 됨

빅데이터, 인공지능 등 기록정보 서비스의 품질을 고도화 시킬 수 있는 정보기술 분야의 성장을 활용할 수 있는 기록관리 프로세스 변화 요구

208

현재 사용 중인 장기보존 포맷이 여러 가지 한계에 부딪히고 있는 상황에서 BagIt과 같은 공개 패키지 규격에 대한 검토가 이루어지고 있으며, 따라서 보존포맷변환 또한 장기보존 포맷 기술 변화를 고려한 변화 필요

○ 처리과 - 기록관 - 영구기록물관리기관 체계를 벗어난 기관별 기록관리자치제 도입 모색

중앙에서 의무적으로 통제하는 형태의 현재 기록관리 조직체계는 강제적 기록관리 틀 안에 가로막혀 기관별로 단절된 기록관리를 유도하고 있으며, 기록관리 수준을 하향평준화 시키고 있는 실정

기록관리로 인한 업무효율의 실현과 중요 기록정보자원의 후대계승을 통해 기록관리의 기본가치를 회복하고 그 위상을 회복할 수 있는 전환적 변화가 필요

RMS와 AMS의 강제적 구분 철폐, 업무기반의 기록관리 모델 설계와 조직의 의지에 따른 자체 기록관리 범위를 허용

영구기록물관리기관의 기록관리 영역을 조직간 정보연계와 중요 기록정보자원의 식별로 최소화함으로써 서비스 기반의 실효성 있는 수평적 기록관리 조직 모델 설계 진행 중

나. 기록관리의 효율성을 극대화 한 Preservation Layer / Business Layer 구분

○ 각 기관별 맞춤형 기록관리시스템 사용을 위한 초석

<그림 163> 공통된 업무에 대한 기관별 상이한 워크플로우 프로세스

기관마다 하나의 업무에 대해 정해놓은 워크플로우가 상이함

현재 공공기관은 기관별 업무특성을 고려하지 않은 표준RMS의 일괄도입으로 실제 업무와 기록관리시스템의 기능이 명확하게 매칭되지 않음

기관별 특성을 고려하여 업무 형태 및 단계에 알맞은 기록관리시스템2017년 11월 9일 제공

필수적인 기본 기록관리기능 외 실제 업무에 빗대어 필요한 기능만 선별하여 기관 맞춤형 기록관리시스템 사용

209

<그림 164> Business Service Layer와 Preservation Service Layer의 차이

○ 기록관리 본연의 기능만을 위한 보존측면의 Preservation Service Layer

‘기록물 관리’에 집중된 핵심적인 기능인 인수, 처분, 보존, 관리, 보안기능 제공

기록물의 유형별 특징을 파악하여 각 유형에 따른 관리기능 제공

타 시스템에서 이관된 기록(Record)을 표준화된 메타데이터 및 집합체를 이용한 세밀한 계층분류 가능

기록물 건 단위 인수 및 개별 컴포넌트 관리 가능

개별 기록물 및 기록물 집합에 대한 보존기간 및 처분일정 기산

유형별 기록물의 특성을 분석한 효율적인 메타데이터 관리 및 독립적인 모듈성을 지닌 서비스의 조합을 통한 유연한 기록관리 가능

○ 실제 기록관 업무에 초점을 맞춘 활용측면의 Business Service Layer

Preservation Service Layer의 ‘기록물 관리’를 뒷받침하기 위한 기록관 실제 업무 중심 서비스 제공

기록물 이관, 대출반납, 열람 등 기록관과 처리과와 인터랙션하면서 발생되는 업무의 관리기능 제공

기록관에서 수행하는 분류체계 수립, 공개재분류, 기록물 평가, 정수점검 등의 업무의 관리기능 제공

원문공개, 저작권 관리 및 보호 등 기록의 활용성 측면에서 발생하는 업무의 관리기능

○ 기관별 특성 및 업무 프로세스에 걸맞는 차세대 기록관리시스템 구성

210

<그림 165> 기관별 특성에 알맞게 Preservation Service와 Business Service 구성

기관 특성에 맞게 차세대 기록관리시스템의 Preservation Service와 Business Service를 맞춤형으로 구성 가능

기록관리업무 3단계(생산->보존->관리)에 적합한 기관과 자체적으로 보존 및 관리를 함께 하는 기관 등 다양한 기록관리환경에 적합한 모델

표준화된 메타데이터 및 마이크로서비스로 구성된 각 서비스들의 호환성 중시

다. 이관개념의 확대

○ 기록물의 업무적 기능과 특성을 파악한 인수

기록물의 유형을 분석하여 각 기록물마다 효과적인 인수형태 지정 및 활용 (대부분의 기관들이 형태 1, 2, 3을 모두 선택할 가능성이 있음)

여러 컴포넌트로 구성된 기록물의 경우 동일한 컴포넌트 관계 유지

여러 유형의 기록물 특성 및 해당 포맷 정보 등을 유지한 기록물 인수

기록물 특성에 따라 기록물의 전체 인수, 일부 인수 가능

○ 기록물 유형에 맞는 효과적인 인수형태 활용

생산시스템에서 기록관리시스템으로 기록물 전체를 이관해 오는 형태 (형태1) 모든 기록물의 총 목록정보와 관리정보를 보유하고 통제하는 역할을 해야 함

생산시스템 내 기록물을 그대로 유지하되 기록관리시스템에서는 메타데이터 값만 인수하여, 해당 기록물을 포인팅 하는 형태 (형태2)

생산시스템 내 기록관리 기능이 탑재되어있어 한 시스템에서 통합적으로 기록물을 관리하는 형태 (형태3)

211

형태1. 형태2. 형태3. 생 산 시 스 템 에 서 기 록 관 리 기록관리 시스템에서는 메타데이터 생산시스템 내 기록관리 기능이 시스 템 으로 기록 물 전체 를 값만 인수하여, 해당 기록물을 탑재되어있어 하나의 시스템에서 이관해오는 형태 포인팅 하는 형태 통합적으로 기록물을 관리하는 형태

<표 101> 기록물 인수 형태

라. 모듈성 (modularity)을 지닌 기록관리시스템 구성

<그림 169> 차세대 기록관리시스템의 마이크로서비스 아키텍처 개념도 >

○ 모듈화된 마이크로서비스(Microservice) 아키텍처 장점

서비스별 독립적 DB관리를 통한 서비스 독립성 확보

쉬운 기능 변경 및 확장, 프로세스 변화 및 사용자 요구에 빠르게 대응

API 호출에 의한 서비스 사이 커뮤니케이션

클라우드 SaaS 구현으로 인프라 및 유지보수 비용절감

○ 독립적으로 모듈화된 서비스로 구성된 기록관리시스템

기관에 특성에 맞게 맞춤화되어 기록관리 업무를 지원하기 위하여 기록관리 프로세스에 공통적으로 사용되는 기능들을 기능별 서비스로 나누어 접근

212

모듈화된 기록관리시스템은 시스템을 보다 유연하고 지능적으로 관리할 수 있으며, 데이터별로 얽혀있는 복잡한 관계 및 설계를 단순화시킴

체계적으로 구성된 최적의 서비스 결합으로 효율적인 기록관리 프로세스 지원

각 서비스 별 API 호출로 정보 호환

○ 마이크로서비스를 통한 명확한 모듈화

독립적으로 모듈화된 각 Layer의 서비스들은 마이크로서비스로 구성되며 모듈화된 서비스에 대한 명확한 경계 부여 가능

마이크로서비스를 적극 활용하여 상이한 기관별 세부업무에 명확하게 부합

마이크로서비스로 구성된 서비스는 클라우드 환경에서의 어플리케이션의 수정 및 버전업데이트 등이 용이

기능적으로 수정해야 하거나 커스터마이징 되어야 할 부분을 변경할 때 용이

개별 언어, 라이브러리, 저장소 등으로 구성된 각각의 마이크로서비스는 적절한 도구 및 기술의 다양성 제고

[As-is] 표준 기록관리시스템 [To-be] 차세대 기록관리시스템 · 독립적인 서비스화를 통한 기관별 맞춤형 · 10년 이상의 기간 동안 지속적 기능별 개선 RMS활용 · 기능 간 종속성 발생으로 비효율성 및 · SaaS형식으로 제공하여 별도 인프라 및 개발비용 증가 관리인력 비용절감 · 다양한 전자기록생산시스템과의 연계, · 오픈소스화를 통한 각 서비스의 개선 및 다양한 형태, 유형의 기록정보자원 관리의 버전관리 가능 한계 · 서비스별 DB관리를 통한 유연성, 확장성 제고

<표 102> 기존 표준 기록관리시스템과 차세대 기록관리시스템의 서비스 구성 차별성

마. 오픈소스화를 통한 차세대 기록관리시스템 및 체계 발전 이바지

○ 오픈소스 정책 활용의 이점

213

기능별 오픈소스 프로젝트 독립적 수행 가능, 모듈화된 시스템에 적합

특정 업체 락인(Lock-in) 방지

오픈소스 프로젝트 독립적 수행 가능, 모듈화된 시스템 개발에 적합

○ 검증된 오픈소스를 통해 안정성과 신뢰성 확보

Preservation Service Layer의 코어기능을 오픈소스화

최소비용으로 기관의 제 특성에 맞는 시스템 활용 가능

Preservation Service Layer와 Business Service Layer 서비스 간 유연한 호환성 증대

활발한 버그리포팅을 통한 오류 감소

○ 기술발전에 부합하는 기록관리시스템의 동적인 개선

자유로운 수정 및 배포를 통해 각 서비스별 기능들을 개선하고, 사용환경, 필요기능별 버전관리 용이

집단지성 및 트렌드에 걸맞은 기록관리시스템의 기능 업데이트

시스템 필요 기능의 Open API를 구현하여 다른 타 시스템과 연동 가능

다양한 패치 개발로 기록관리시스템 성장 가능성 제고

<그림 171> 현행 기록관리시스템과 차세대 <그림 172> 기록관리시스템 보급 벤더의 보급 방식 비교 역할 변환

○ 해외 기록원의 오픈소스 정책 사례

해외의 기록원에게 오픈소스 정책은 이질적인 정책이 아니며, 오픈소스 소프트웨어를

214

이용하기도 하고 연동 규격을 공개하여 오픈소스 도구 개발을 장려하고 있음

해외 기록원 오픈소스 정책

· 기록관리 담당자를 위한 오픈소스 73종 정보 제공 미국 · GitHub에 ERA-tools(파일포맷 식별도구), File Analyzer 등 ERA 기능 NARA 일부 공개 (https://github.com/usnationalarchives) · 기록관리 담당자를 위한 오픈소스 툴과 라이선스 정보 제공 영국 TNA · 상용 AMS인 Preservica 공동 개발. BagIt, FFMpeg 등 다수의 OSS 활용 호주 NAA · 2001년부터 디지털 보존을 위한 OSS 4종 개발 및 전세계 아카이브 공유 · Planets 등 디지털 보존, 에뮬레이션 연구 결과를 OSS로 공개 유럽 · POWRR 등 공공 영역의 소프트웨어를 공동으로 조달하고 OSS 커뮤니티 활성화 노력

<표 103> 해외 기록원 오픈소스 정책

○ 기록관리 오픈소스 사례

전세계 기록관리 오픈소스를 공유하고 지원하는 비영리 오픈소스 지원 조직들이 있으며 약 400여개 이상의 오픈소스가 공개되어 있음

오픈소스 지원 조직 오픈소스 기록관리 도구 현황

Community Owned digital Preservation Tool Registry (COPTR)

Preserving Digital Objects with Restricted Resources (POWRR)

The Open Preservation Foundation (OPF)

The Digital Curation Centre (DCC)

The Digital Curation Exchange (DCE)

National Digital Stewardship Alliance (NDSA)

<표 104> 기록관리 오픈소스 현황

○ 오픈소스 정책 전개를 위한 전제 조건

215

국내 행정기관, 공공기관이 정보화사업을 추진하고자 하는 경우에 ‘행정기관 및 공공기관 정보시스템 구축․운영 지침(행자부고시 제2016-48호, 2016.12.26.)이 적용됨

위 지침 제8조는 보안성 검토 의무를 정하고 있음

· 제8조(보안성 검토 및 보안관리) ① 행정기관등의 장은 정보시스템을 신·증설하는 경우 "국가 정보보안 기본지침" 제109조, 제110조에 따라 국가정보원장에게 보안성 검토를 의뢰하여야 한다.

한국인터넷진흥원은 전자정부 SW 개발∙운영자를 위한 소프트웨어 보안 가이드를 제공하여 소프트웨어 분석, 설계, 구현의 모든 단계에서 보안성을 강화하기 위한 활동을 지원하고 있으며 구현단계에서 시큐어코딩 가이드를 따라야 함. 공공개관에서 기록관리시스템을 오픈소스 정책 기반으로 개발할 때 시큐어코딩 가이드를 따라야 할 것이며, 이미 공개된 오픈소스 소프트웨어 활용 시에도 시큐어코딩 여부를 점검해야 할 것임

시큐어코딩과 같은 구현 단계의 지침 만이 아니라 전자정부 보안 지침이 오픈소스 활용은 물론 기관의 소스 오픈을 허용하도록 법․제도 정비가 수반되어 야 함

바. 상호운용성 (Interoperability)이 강조된 설계

○ 상호

다양한 기록관리시스템(레거시/자체 개발/해외…), 아카이빙시스템, 행정정보시스템

국제 메타데이터 표준에 기반한 메타데이터 엑스포트

기록유형별 맥락메타데이터 엑스포트

<그림 180> 상호운용성을 중시하는 차세대 기록관리시스템 서비스

○ 다양한 메타데이터 수용 가능

216

· ISAD(G) 또는 더블린코어를 준용한 차세대 기록관리시스템만의 메타데이터 생성 및 관리

· 차세대 기록관리시스템 표준 메타데이터와 외부 아카이브시스템 메타데이터를 매핑하여 효과적인 기록물 인수

· 타 시스템으로 Export시 데이터 변형 없이 그대로 Import될 수 있도록 표준 메타데이터 지정

· 유형별 기록물의 특성을 고려한 메타데이터 항목 정의를 통해 호환성 제고

· 모든 개체(집합체, 레코드 그룹 등)의 시스템 메타데이터, 맥락 메타데이터를 기관 기록관리 프로세스에 맞추어 응용하여 정의 가능

<그림 181> 상호운용 가능한 시스템 예시

○ 다양한 기록물의 추후 활용성 증대

여러 외부 시스템의 기록물 인수 시 메타데이터가 정리되어 추후 대민서비스 제공 등 편리한 사용성 및 활용성 부여

서로 다른 폴더에 속해있는 기록물 건들도 서로 관계(Relationship)를 구성하여 연관된 기록물들 접근 가능

검색된 기록물의 경우 분류체계 및 속한 집합체(Aggregation), 레코드그룹(Record Group), 기록물 건(Item)에 대한 메타데이터로 연관된 다른 기록물 건에 대한 링크정보를 제공하여 활용성 증대

사. 기록관리 기능 고도화

○ 기록물 집합체 내 개별적 건 단위 관리

건 단위마다 본문, 첨부 콘텐츠, 유형 등 개별 기록물 건(ITEM) 고유의 컴포넌트 구성

효율적인 집합체 관리 및 구성으로 기록물 건 단위(ITEM) 관리

기록물 건 별로 보존기간, 처분일정을 부여하여 세밀한 기록물 관리

가상 집합체(Virtual Aggregation), 임시 집합체(Temporary Aggregation), 일반 집합체

217

(Normal Aggregation)로 구분하여 기록물 체계의 효과적인 정리

집합체(Aggregation), 레코드그룹(Record Group) 계층별 연관 관계(Relationship)를 주어 관련 있는 기록물 건 간 연결

<그림 182> 차세대 기록관리시스템의 집합체, 분류체계, 처분일정 분리 등 다양한 관계 조합

○ 개별 기록물 건의 처분일정 산정 가능

한 기록물 집합체에 종속되어 있는 개별 기록물에 대한 처분일정 산정 가능 (각 기록물의 개별적 기산일 부여)

집합체 및 폴더, 개별 기록물에 각각 처분 트리거를 규정하여 처분일정 산정

기록물 집합체 내 종속된 개별 기록물이 다른 집합체 및 폴더로 이동할 경우, 이동된 클래스의 처분일정을 자동으로 상속받지만, 개별 기록물별 처분일정 부여 가능

○ 효과적인 처분일정(Record Schedule)관리

처분 일정이 도래된 기록물의 목록을 조회하고, 내보낼 수 있음

처분이 확정된 기록물의 경우 시스템 내 메타데이터 수정을 통해 처분여부 변경

비전자기록물의 경우 실제 처분 시점 관리 가능

○ 활용성 극대화 및 효율적인 기록물 관리를 위한 다중분류체계

기능분류체계 외 주제별, 조직별 분류체계 외에도 다양한 분류체계 활용 가능

사용자의 다양한 각도의 접근으로 인한 기록물의 가치 극대화

기록물 건 별 다중 분류가 가능하게 하여 사용자의 유기적인 접근 제고

기록물 특성에 맞는 구체적이고 체계적인 다중 분류체계를 통한 전문성 확보

218

○ 진본성 유지를 위한 확장된 감사 추적(Audit Trail) 기능

개별 기록물에 대한 생성부터 폐기까지의 모든 이력들을 확인 가능

기록물 집합체 및 폴더에서 다른 집합체 및 폴더로 이동 시에도 이력 확인 가능

내보내기(export)시 기록물 집합체, 폴더, 기록물 건 정보뿐만 아니라 기록물에 대한 생성, 이관 등의 이력도 포함

기록물을 열람하거나 접근한 사용자에 대한 이력 확인 가능

기록물 건에 대한 폴더 이동, 수정, 추가 등은 관리자 확인 후 반영

분류체계 추가시 작성 중 임시저장 및 추가 수정을 충분히 한 후 관리자 확인 후 로그 기록

기록물 건 및 집합체에 대한 분류체계 매핑시에도 로그 기록

기록관리시스템 내 사용자의 접근 관리 리스트(Access Control List)를 통한 효과적인 접근 관리 가능

○ 본연의 기록관리 보존의 기능을 위한 서비스 구분

독립된 워크플로우 서비스를 기반으로 한 각 서비스들의 세부 워크플로우 적용 및 총괄 가능

유형별 SIP에 대한 DFR기반의 포맷관리 및 지정 솔루션 연결 가능 서비스 구현

재난발생시 기관내 업무수행에 핵심적인 기록물을 위한 필수기록물 서비스

기록생산의 정확한 맥락이해 및 효과적인 활용을 위한 전거데이터 서비스

아. 모든 기록유형을 포괄하는 메타데이터 구조

○ System Metadata와 Contextual Metadata의 명확한 구분

시스템에 필요한 System Metadata와 업무 활용에 필요한 Contextual Metadata에 대한 구분으로 기록물에 대한 체계적인 관리 가능

모듈화된 시스템 별 적절한 교차 Entity 설계를 통한 구조적인 안정성 제고

유연한 데이터 설계로 인한 시스템 확장성 제고

219

<그림 183> 아이템과 컴포넌트 사이 Entity 구성

자. 클라우드 서비스로서의 기록관리시스템 제공

○ 서비스 형태의 기록관리 어플리케이션(Record Application) 제공

별다른 인프라 등을 설치할 필요 없이 어플리케이션 형태의 기록관리시스템 솔루션 제공 (SaaS)

Scale-out, 멀티테넌트, 프로비저닝 등의 플랫폼제공 및 상용 S/W, 시스템 S/W, 서버의 가상화

마이크로서비스, 설치비용 최소화, 손쉬운 커스터마이징 도구 및 모듈 제공으로 인한 기관맞춤 가능

Open Source 및 Open API를 이용한 커스텀화 제공 및 타 서비스와의 연동성 증대

<그림 184> 현행 기록관리시스템의 서비스 제공 방식 전환

220

차. OAIS 참조모형의 Information Package유형에 기반한 서비스방향 설계

○ OAIS 외부 데이터 상호작용 모형에 따른 방향 설계

<그림 185> OAIS 외부 데이터 상호작용 모형

출처: CCSDS 2012, Reference Model For An OAIS

Open Archival Information System Reference Model 준수

단계별 Package들에 대한 특성에 맞게 차세대 기록관리시스템 서비스 모델 수립

서비스별 상호 운용성(Interoperability)을 강조한 설계

○ SIP, AIP, DIP 흐름에 따른 서비스 구현

<그림 186> OAIS 모형에 입각한 차세대 기록관리시스템의 Preservation Service Layer

221

기록의 생산자가 SIP(Submission Information Package)를 Ingest Service에 제공

Ingest Service는 AIP(Archival Information Package)를 생성하여 저장, 유지, 검색 등 해당 기록물의 활용이 가능할 수 있게 Conservation Service에 제공

Ingest Service는 관련된 기술정보(Descriptive Information)을 추출하여 Record Service에 제공

사용자는 적절한 접근 툴을 활용하여 정보 탐색 및 입수할 수 있는 DIP 요청 후 Export Service에서 DIP생성

입수/저장된 기록의 정보를 장시간 보존이 가능할 수 있게 하는 Conservation Service 제공

모든 서비스는 System의 총괄 Admin에 따라 운영됨

5.2. 차세대 기록관리시스템 개념도 및 주요기능

○ 차세대 기록관리시스템은 Preservation Service Layer와 Business Service Layer로 분리된 층에 독립적 수행이 가능한 서비스 모듈로 구성됨. 기록 객체의 정보를 관리 및 보존하는 Preservation Service Layer의 서비스들은 모든 시스템에 필수적으로 포함되어야 하는 필수(Mandatory) 서비스와 기록관리를 위해서 필수적이나 없어도 시스템이 최소 기능으로 작동은 가능한 기본(Essentia) 서비스, 그리고 선택 사양인 선택(Optiona) 서비스로 구성됨

<그림 187> 차세대 기록관리시스템 서비스 구성도

가. Preservation Service Layer

222

○ 필수(Mandatory) 및 기본(Essential) 서비스 기능 설명

구분 서비스명 서비스 기능설명

•집합체, 레코드그룹, 아이템, 컴포넌트 단위로 기록물을 계층 및 기록 레벨단위로 관리 Mandatory P1 서비스 •레벨 단위로 상속을 지원하며, 가상(Virtual)/임시(Temporary)/일반(Normal) 집합체로 구분하여 효과적인 기록물 관리

•RMS 내 모든 기록물에 대한 접근 이력, 수정 이력 등 시스템관리 Mandatory P2 추적 관리 서비스 •디지털 서명관리 및 시스템 설정

•선택된 서비스에 따른 맞춤형 통계 Dashboard와 레코드그룹, 아이템, 컴포넌트, 메타데이터에 대한 다양한 포탈 Mandatory P3 검색옵션을 통한 통합검색 제공 서비스 •기록물에 매핑된 집합체 및 분류체계 정보 제공, 연관 기록물 링크 제공

•전자/비전자기록물 등 각종 생산시스템의 모든 형태의 입수 기록물을 입수, 수집된 데이터 건 단위 인수 Essential P4 서비스 •기록물 유형별 인수형태 선택가능(ISO 16175 옵션 및 확장)

•기능별, 주제별, 조직별 분류체계를 기본적으로 보유하며 분류체계 Primary Classification Schema지원 Essential P5 서비스 •사용자가 분류체계를 추가, 수정할 수 있으며 집합체와 매핑됨

•유형별 모든 형태의 기록물을 사용자가 브라우저에서 볼 디지털콘텐츠 Essential P6 수 있게 제공 서비스 •기록물 포맷 유형별 솔루션 연계

•처분일정 트리거 작동을 통해 레코드그룹, 아이템에 각각 처분일정 처분일정 부여 가능 (상속 포함) Essential P7 서비스 •처분일정을 유형별로 관리할 수 있으며, 분류체계에도 적용 가능 •사용자 및 사용자그룹에 시스템 ROLE을 적용하여 접근권한 Permission 부여 Essential P8 서비스 •Access Control List를 통해 레코드그룹, 아이템과 연결 가능

223

구분 서비스명 서비스 기능설명

•전자기록물의 진본성, 무결성보장 및 보존포맷 변환, 디지털 마이그레이션 등 지원 Essential P9 스토리지 •스토리지 할당량 조절 및 임시/보존 스토리지를 통해 서비스 기록물 관리

•비전자기록물의 위치관리(서고-서가번호, 보존상자 위치 서고관리 Essential P10 등) 서비스 •반입반출, 열람 등 상태 및 추적

디지털보존 •기록물 포맷 변환, 장기보존 포맷 변환 및 관리 Essential P11 서비스 •대체보존(서버-매체, 매체-매체) 기능

○ 선택(Optional) 서비스 기능 설명

구분 서비스명 서비스 기능설명

•처분동결 트리거 작동을 통해 레코드그룹, 아이템에 각각 처분동결 Optional P12 처분보류(동결) 설정/해제 및 유형 선택 가능(상속 포함) 서비스 •레코드그룹 및 아이템에 처분동결을 복수로 부여 가능

•일반 집합체에 속한 아이템, 컴포넌트에 대해 전거레코드 전거관리 Optional P13 부여 서비스 •유형별 기록물 출처를 밝힐 수 있는 시스템 정보부여

•반출대상 메타데이터, 이벤트 연혁(접근감사 이력, Audit 내보내기 Optional P14 Trail)등 설정 서비스 •XML, Jason 등 반출형태 선택 가능, DIP생성

리드케이스 Optional P15 •수집된 기록물의 진본확인 및 케이스/리드데이터 관리 관리 서비스

•필수 기록물이 속해있는 집합체, 레코드그룹, 아이템에 필수기록물 Optional P16 대한 정보 및 갱신여부 확인 관리 서비스 •매체(Storage, Server 등)수록 및 복본생성

•각 서비스별 워크플로우 Activity 정의 및 수정가능 워크플로우 Optional P17 •기록물 입수시 아이템에 대한 바이러스검사 및 서비스 메타데이터, Checksum점검, AIP생성

224

○ 서비스별 세부 기능

<그림 205> Preservation Service 세부 기능

나. Business Service Layer

○ 비즈니스 서비스는 기록관리 행위를 지원하는 서비스로서 선택 모듈이며 각 서비스의 기능은 다음과 같음

구분 서비스명 서비스 기능설명

•정보공개청구신청서 접수 및 처리과별 분류, 처리과 공지 원문공개 및 회신 기능 Optional B1 서비스 •RMS내 기록물 위치 및 공개값 확인 후 사전정보 공표 또는 원문공개

225

구분 서비스명 서비스 기능설명

•기록관내 비전자기록물에 대한 목록검색 및 기록물 대출 반입반출 예약 가능 Optional B2 서비스 •RMS상 기록물 보관상태 확인 및 대출일자, 대출자, 반납일자 등 관리

•보존기간이 도래한 폐기대상 목록확인 및 부서의견, 평가 Optional B3 기록관의견 관리 서비스 •평가심의회 및 평가심의위원 관리

•기록관내 비전자기록물에 대한 목록검색 및 기록물 열람 열람관리 Optional B4 예약 가능 서비스 •열람일시, 열람자의 처리과 등 기본정보 관리

•서고내 비전자기록물에 대한 정수점검 일정 계획 수립 정수점검 Optional B5 및 대상목록 관리 서비스 •정수점검 결과 RMS내 반영

•기록물에 대한 지적재산권 정보 관리 지적재산권 Optional B6 •기록에 대한 CCL(Creative Commons License)을 관리 서비스 도입하여 사용조건 및 범위 관리

•처리과에서 기록관으로 기록물 이관 시 목록 검토, 기록물이관 Optional B7 의견회신 기능 서비스 •목록확인 후 이관보류 및 부분이관 목록관리 가능

•분류체계에 대한 처리과의견 반영, 단위업무 신청, 분류체계 접수/반려 기능 Optional B8 서비스 •처리과 내 서무담당자 등 인력관리 및 분류체계 기준 수립 가능 •공개재분류 대상 기록물 목록관리, 유형별 기록물 분류, 공개재분류 기준서 및 검토서 작성 Optional B9 서비스 •생산기관 의견 조회, 기록물 공개심의회, 국가기록원 심의회 등 지원

•기관 내 행정조직 변천 이력 관리 조직관리 Optional B10 •조직변천 시각화 리포팅, 통계/출력양식 표준화, 서비스 RMS연계

리드케이스관 •수집계획 수립, 소장자, 접촉상황, 수집현황 등을 관리할 Optional B11 리 리드 개발 및 관리 서비스 •개발된 리드를 바탕으로 케이스파일 작성 및 관리

226

구분 서비스명 서비스 기능설명

•메타데이터를 기반으로 사용자 입력 검색어 및 의도 지능형검색 분석 Optional B12 서비스 •의미기반 연동을 통한 검색된 기록물의 관련 기록물, 콘텐츠 추천

필수기록물관 •필수 기록물이 속해있는 집합체, 레코드그룹, 아이템에 Optional B13 리 대한 정보 및 갱신여부 확인 서비스 •필수기록물 검색 및 목록 출력

5.3. 현행 표준기록관리시스템 대비 주요 개선 내용

가. 전자기록 생산시스템에서의 건 단위(item) 자동이관

※ 표준기록관리시스템 메뉴 [1depth>2depth]

[기록물인수>연계인수] 기록물 인수 일정수립

· 생산시스템의 전자기록물 As 인수일정 기간과 연계하여 Is 인수일정 수립 후 연계인수 진행 · 인수일정 미수립 시 인수불가

· 기록물 생산 시 건별 자동이관 [전자기록물] 생산시스템 생산완료 시 건별 자동이관 · [비전자기록물] 비전자기록물 형태 및 크기 등 고려하여 방안 적용 ①생산시스템에 메타데이터만 또는 To 디지털화 파일 동시 등록 Be ②자동이관 ③비전자기록물 정리 및 기록관 이관 ④서가배치 등 관리정보시스템 등록 ⑤메타데이터만 등록 경우 중요도를 고려하여 디지털화 진행 후 파일 등록 [전자기록물+비전자기록물] 비전자기록물 절차와 동일 · 자동이관 주기 및 대상은 설정가능

227

[기록물인수>연계인수], [기록물인수>생산현황접수·통보·통보결과] 기록물 인수 일정수립

As Is

· 접수-검수-인수 각 단계별 확인 및 반려절차 진행 · 생산현황접수와 접수결과를 정리하여 통보 · 접수-검수-인수는 설정한 기준으로 자동 처리 · 검수 과정에서 발생한 오류들에 대해서는 자동분류 후 향후 일괄작업 제공 To · 별도의 생산현황접수 없이 건별 자동이관 및 비전자기록물 생산시스템 등록이관, Be 기록관리시스템 등록이관 정보를 사용자가 기간단위로 조회하여 상시 보고 가능. 보고 이력은 현재와 동일한 관리프로세스 적용

나. 유연한 검수 항목 설정 및 오류처리 방식 적용

[기록물인수>연계인수] 검수 절차와 오류처리

§ 검수항목 선택 불가, 시스템에서 정의된 검수항목에 대한 오류검사 후 결과 값 제공 As § 생산시스템과의 연계를 통한 오류 Is 처리 작업 편의성 부재 § 작업 단위가 처리부서인 관계로 정 상적인 철(folder) 및 건(item) 단위 인수 불가

§ 워크플로우를 이용한 자동 검수 § 워크플로우 Job을 이용하여 검수 To 항목 사용자 설정 가능 (ex. 특정 Be 부서 기록물 바이러스 체크 제외) § 철(folder), 건(item) 단위의 검수 및 인수 작업

228

다. 철/건 단위의 인수 및 폐기

[기록물인수>등록인수] 기본 철단위 등록인수 · 철단위 등록인수로 인해 대량의 정비되지 않은 기록물 인수가 불가 · 대량의 기록물을 인수 시 “기록물 일괄등록” 기능을 사용, 이를 위해 해당 기록물에 대한 일괄규격 변환 필요(규격적용기준. 기록관리시스템 As 구축기록물의 기록관리시스템 Is 규격(안)") ※필요 시 업무 현장에서는 외부 용역을 통해서 진행하고 있는 상황 · 폐지된 부서 또는 하위기관의 기록물을 등록해야 할 경우 신속한 처리 불가

To Be · SIP Creator를 사용하여 기록물을 인수받기 위한 구조 생성 (메타생성, 아이디부여,

이관규격세팅 등) · 임시 aggregation을 구성하여 등록 · 등록 후 시스템 내에서 정리 작업 가능 · 임시 aggregation 기록물의 통합검색 제공 여부 또한 기록관의 정책에 따라 설정

[기록물인수>등록인수] 행정박물관리

· 건(item) 단위로 유형 구분을 통해 관리 As · 관리대상 행정박물과 관련한 Is 사진/필름, 음성/영상류 기록물과 연결한 관리 불가

· 관련한 행정박물에 대한 To 임시 집합체 (Temporary Be Aggregation)을 구성하여 효율적으로 관리 가능

229

[기록물평가>평가폐기] 기록물 평가 폐기

§ 철 단위 평가폐기만 지원

§ 건 단위로 식별되는 중요 기록 As 물에 대한 세밀한 관리체계 미 Is 비로 중요 기록정보 유실위험 존재

§ 공개재분류 절차와 동일하게 건 단위 기록물 폐기

§ 대상선정, 의견등록, 평가심의 등의 업무기능들은 Business To Service Layer에서 수행 Be § 최종 평가 결과에 대한 실제 기 록물 처리는 Preservation Service Layer에서 수행한다

§ 각 기관 성격에 맞는 평가폐기 업무 적용 가능

라. 행정정보시스템 기록정보 이관

행정정보시스템 이관기능 부재

· 기록관리시스템 등록 규격대로 정비된 비전자기록물 또는 As 구전자문서 일괄등록 기능만 Is 제공 · 행정정보시스템 이관 기능 부재

· 이관대상 행정정보시스템에서 식별한 관리대상 기록정보를 SIP To creator를 통해 생성 Be · 물리적 이관 여부에 대한 설정 기능 제공

230

마. 간행물 발간등록번호 관리

간행물 발간등록번호 관리기능 부재 · 간행물 발간등록번호의 경우 기본형식은 국가기록원 발급, 임의입력은 각급기관 발급 · 기본형식의 간행물보다 임의입력 As 형식의 간행물 생산이 많음 Is · 발간등록번호 발급관리를 오프라인을 통해 진행하는 과정에서 대부분의의 생산되고 있는 간행물이 기록관리 범위에서 누락되고 있음

· 기본형식은 영구기록물관리시스템과의 연계를 To 통해 발급 Be · 임의입력은 기관 내 기록관에서 기록관리시스템을 통해 발급

바. 보존포맷 변환

[기록물보존 >포맷관리 ] 보존포맷 변환 관리

· 문서보존포맷은 PDF/A-1 장기보존포맷 NEO As · · 포맷변환을 위한 Is [조회-변환-오류처리]의 개별 절차를 사용자가 수행

To Be

· 포맷변환 스케쥴링 설정을 통한 포맷변환 작업 자동화 · NEO 외 BagIt 등 보존포맷 규격 추가 가능 설계 · 다양한 유형의 파일 포맷을 장기보존 변환가능하며, 포맷변환 솔루션도 등록가능

231

사. 접근권한 관리

[기록물평가>접근범위재분류] 접근범위 관리

As · 전체열람, 목록열람, 열람불가 Is 3가지의 접근범위로 관리

§ 기록물의 특성이나 이슈에 따라 접근 범위를 (1)부서나 업무담당자별로 설 To 정하거나 (2)특정기간을 설정하여 접 Be 근권한을 접근권한에 대한 유연한 관 리 가능

아. 기준 관리

[기준관리>기록관리기준표] 분류체계 관리

· BRM시스템 연계를 통한 기준관리 지원(기록관리기준표), 과제관리를 위한 목적별분류체계 미연계로 기록관리시스템에 등록인수 시 목적별 분류체계 As 적용 불가 Is · 전자문서시스템 사용기관을 위한 기록물분류기준표 지원 · 기관에서 사용 중인 업무분류체계를 적용을 병행할 수 없음

· 기준관리 모듈을 통해 다중분류체계 실현 · 분류체계만으로 사용자가 원하는 검색범위 설정 활용 가능 To ⇒사용자 중심의 정확한 Be 정보제공 · 적용한 분류체계를 기반으로 한 A.I. 기술기반의 학습을 통해 향후 자동분류체계 완성

232

자. Aggregation 생성ㆍ관리

집합체 관리

· 기록물이 철과 건구조로만 관리됨 As · 기록물의 어그리게이션을 Is 형성 할 수 없음 · 건별 이동이 불가능 하며, Virtual을 생성 할 수 없음

· 기록물의 철ㆍ건 구조를 탈피 하고 Aggregation 기술 계층을 생성 하도록 실현 · 이관당시 기록물의 구조를 그대로 보존 가능 To · Aggregation 계층별로 기록물 Be 탐색이 가능 하며, 건별 이동이 가능 하도록 실현 · Virtual Aggregation을 생성 하여, 관련기록물을 재정리 하도록 실현

차. 처분일정 생성

[기록물 평가>평가ㆍ폐기] 처분일정 관리

· 평가폐기년도를 기준으로 As 보존기간이 도래한 기록물을 Is 대상으로 선정함

· RG, GRS에 따라 처분일정 기산일을 적용 하도록 함 To · 처분사유를 등록ㆍ관리 가능 Be 하며, 기관의 특성에 따라 처분 사유(RS)를 생성 하여 관리하도록 실현

233

카. 처분동결

[기록물 평가>평가ㆍ폐기] 처분보류 관리

· 기록물 폐기 보류를 최대 5년까지만 설정 가능 As · 처분 보류 사유에 대한 관리가 Is 불가능 · 처분 보류 기록물에 대한 검색 및 이력 관리가 불가능함

· 처분 동결 사유와 차수를 등록ㆍ관리 할 수 있도록 실현 To · 처분 사유는 기록물과 매핑하여 Be 처분 동결 사유별로 기록물을 관리 할 수 있도록 실현

타. 메타데이터 관리

메타데이터 관리

· 기록물 철과 건메타로 구분됨 · 정해진 메타 데이터를 사용해야 As 하며, 추가 메타를 등록 할 수 Is 없음 · 기록유형에 따른 메타데이터 구분이 명확하지 않음

· 시스템 메타 데이터와 맥락 메타 데이터로 구현 · 아이템 유형에 따른 메타 데이터 To 구분 Be · 기록물의 특성에 따라 추가메타를 설정 하여, 사용 할 수 있도록 실현

234

파. 워크플로우

워크플로우 관리

· 이관 유형에 따라 별도 서비스로 구성 됨 As · 정해진 프로세스에 따라 기록물 Is 이관을 받아야 함 · 여러 개의 이관 프로세스를 동시에 진행 할 수 없음.

· 기록물 이관에 필요한 프로세스를 세분화 하여, 잡(Job)로 구성 · 여러 개의 잡(Job)으로 구성된 워크플로우를 생성 하도록 실현 To · 잡(Job)를 구성한 순서에 따라 Be 워크플로우가 실행되도록 실현 · 여러 개의 워크플로우를 실행 가능 하도록 구현 · 이관 유형에 따라 워크플로우를 생성 하도록 실현

5.4. 차세대 기록관리시스템 서비스 관계도

가. 기록관리 보존기능

● Preservation Service Layer - 타 시스템에서의 기록물 입수 - 기록 집합체(Aggregation) 생성 - 분류체계 생성 및 집합체와 매핑 - 기록물에 대한 처분일정 관리 - 기록물에 대한 처분동결 관리 - 기록 보존포맷 변환 등

<표 124> 차세대 기록관리시스템 서비스 관계도 – 기본 기록관리

235

나. 기록물 이관 및 인수

● Business Service Layer - 기록관과 처리과 사이 기록물 인수일정 확정 - 처리과에게 기록물 인계 요청 - 처리과 인수인계서 작성 및 기록관에 전달 - 기록관 인수인계서 검토 및 회신 ● Preservation Service Layer - 실제 인수된 기록물 시스템에 등록 - 기록물에 대한 메타데이터 검토/수정 및 대상 기록물에 대한 분류체계 확인 - 기록물 특성에 따른 알맞은 집합체 매핑 또는 집합체 및 Record Group생성 - Temporary Aggregation으로 이동 및 SIP 준수여부 체크 - 썸네일 생성 및 파일포맷 식별

<표 125> 차세대 기록관리시스템 서비스 관계도 – 기록 인수

다. 기록물 평가 및 처분

● Business Service Layer - 보존기간이 만료된 기록물 평가대상 선정 - 기록물에 대한 보류, 폐기에 대한 의견조회 - 기록관 검토 및 평가심의서 작성 - 평가심의회 개최 및 평가위원 관리 - 기록물 처분대상 확정 ● Preservation Service Layer - 기록물의 Record Schedule 확인 - 처분트리거를 통한 처분대상 Aggregation, Record Group, Item 확정 - 처분동결 여부 생성 및 처분동결트리거 작동 - 잔존메타데이터 선별 및 메타데이터 정리 - Record Schedule 상속 여부 체크 - 기록물 처분 후 집합체 정리

<표 126> 차세대 기록관리시스템 서비스 관계도 – 평가 및 처분

236

라. 기록물 검색 및 활용

● Business Service Layer - 처리과 업무 참고의 용도로 열람 - 대출시 위치정보 및 대출여부, 예약 확인 - 반납일정 확인 및 반납여부 처리 - 사용자 이력확인 - 정보공개요청 접수 및 처리

● Preservation Service Layer - 유형별 기록물에 대한 솔루션 연동 - 사용자 그룹 식별 및 권한 확인 - 검색 인덱스 업데이트 - 연관 메타데이터를 통한 전거레코드 확인 - 기록물에 대한 위치정보 확인 - 썸네일 디렉토리 확인 - 파일포맷 식별 - 접근권한 및 이력관리

<표 127> 차세대 기록관리시스템 서비스 관계도 – 검색 및 활용

마. 비전자기록물 관리

● Business Service Layer - 기록물 정수점검 일정계획 수립 - 정수점검 결과 값 입력 및 관리 - 필수기록물 선정 및 목록 확인/출력 - 공개재분류 대상선정 및 목록관리 - 유형별 기준서 및 검토서 작성 ● Preservation Service Layer - 기록물 위치 정보 관리 및 업데이트 - 매체수록에 대한 정보관리 및 복본정보관리 - 공개값 확인 및 메타데이터 업데이트 - 필수기록물에 대한 정보 및 갱신 여부 확인 - 스토리지 할당량 조절

<표 128> 차세대 기록관리시스템 서비스 관계도 – 비전자기록물 관리

237

5.5. 차세대 기록관리시스템 기능요건

○ 시스템 기능요건 개발 시 다음을 참조하였음

· Moreq 2010’의 분류체계와 집합체, 보유와 처분, 접근권한 관리 개념

· ‘Preservica’의 SIP creator와 모듈별 워크플로우 구동, PRONOM 관리

· ‘Archivematica’의 import, export 방법

· IBM FileNet Content Manager 기능

· HP Content Manager 기능

○ 반드시 적용이 필요한 필수 기능은 “M”, 기관의 선택에 따라 적용가능한 요건은 “O”로 표기함

가. Preservation Service Layer

P1. 기록 서비스

n 집합체, 아이템, 컴포넌트 집합체: 조직/업무 활동을 증명해주며 축적된 아이템의 집합을 집합체라 한다. 집합체는 연관 있는 기록들을 모아서 묶는 과정을 말하며, 다른 기록의 맥락과 나란히 배치함으로써 각 주제의 생생한 기술적 묘사를 총체적으로 제공. 집합체는 동일한 업무처리나 절차, 업무분류, 주제 영역이나 사안, 인물·장소·프로젝트·사건·고객·이벤트, 메타데이터, 출처·형식, 접근통제, 보유 와 처분 조건에 따라 만들 수 있음 아이템: 하나의 개체로 관리되는 기록물의 최소 개별 단위를 아이템. 아이템은 집합체에 묶어서 관리해야 하며, 결재문서, 이메일, 회의록, 웹문서 등 다양한 유형이 존재함 컴포넌트: 아이템을 구성하는 기록물의 최소 단위. 일반문서 유형일 경우 종이문서, 전자문서의 본문·콘텐츠 등이 아이템을 구성하는 컴포넌트가 됨. 다른 기록 유형인 경우 각 아이템을 구성하는 고유의 컴포넌트 형식을 가짐.

<그림 247> 기록의 계층 모형

238

n 메타데이터와 상속

기록 서비스에서 메타데이터는 필수적으로 관리하는 시스템 메타데이터와 업무에 따라 관리하는 맥락 메타데이터로 구분됨

집합체, 아이템의 메타데이터는 시스템 메타데이터와 맥락 메타데이터가 1:1로 구성되며 유형이 다르더라도 시스템 메타데이터는 동일하게 관리되어야 함

컴포넌트는 DFR 메타데이터를 포함하는 시스템 메타데이터를 가지고, 콘텐츠에 따라 컴포넌트 유형을 가짐

자식 개체가 부모 집합체에 상속되며 분류정보, 접근통제정보, 처분정보 등에 대한 메타데이터도 상속됨 n 집합체 종류

기록 서비스에서 집합체는 활용에 따라 임시 집합체(Temporary Aggregation), 일반 집합체 (Normal Aggregation), 가상 집합체(Virtual Aggregation)로 구분됨

‘임시 집합체’는 기록물 입수시 또는 정리 과정 중인 집합체를 말함. 기록 서비스를 위해 기록물을 재조직화하는 집합체임

‘일반 집합체’는 임시 집합체에서 기록물 정리가 마무리되면, 웹 서비스를 할 수 있는 상태의 집합체를 말함

‘가상 집합체’는 일반 집합체의 맥락과 또 다른 맥락을 만들기 위해 가상으로 만든 집합체를 말함. 가상 집합체에 묶여 있는 기록은 레퍼런스만 가지며 실제 기록은 일반 집합체에 존재함. n 집합체의 제한

기록 서비스에서 다른 집합체의 자식이 아닌 집합체를 ‘최상위 집합체’라고 함. 기록 서비스에 서 최상위 집합체의 개수 제한이 없다. 이것은 여러 조직이나 조직 내의 여러 부서에서 사용될 것을 고려한 것이며, 각 사용자들은 동일한 기록 서비스 내에서 다른 집합체나 기록을 참조하지 않고 각각 다른 집합체나 기록을 관리 할 수 있음.

전자적으로 생성된 아이템(전자기록물), 전자화하여 생성된 아이템(비전자기록물)은 반드시 집합체에 묶어 관리되어야 함. 집합체에 묶여있지 않은 아이템은 맥락을 알 수 없어 기록의 의미 이해를 저해함.

아이템은 집합체의 어느 계층에나 묶일 수 있으며, 아이템이 존재하지 않은 집합체는 존재 할 수 없음.

239

<그림 248> 기록 서비스 내에서 아이템의 배치 n 기능 요구사항

P1-1. 집합체는 계층구조를 가지며, 아이템은 집합체에 묶어서 관리되어야 한다(M). P1-2. 기록 서비스에 의해 정의된 요소를 사용해야 하며, 외부 시스템 식별자를 사용해서는 안된다(M).

P1-3. 모든 기록물에는 시스템 고유의 UUID가 부여되어야 하며, 기록 서비스에 의해 정의된 요소를 사용하지 않고 외부 시스템 식별자를 사용해서는 안된다(M).

P1-4. 모든 기록물은 공통된 라이프사이클 체계(최초 생산, 최초 사용, 종결, 폐기)로 상태를 정의할 수 있어야 한다(M).

P1-5. 기록 서비스는 ISAD(G), Dublin Core 등 국제 표준 메타데이터를 기반으로 한 표준 메타데이터를 가지고 있어야 한다(O).

P1-6. 집합체의 시스템 메타데이터는 아래와 같은 값을 포함한다(M).

집합체 UUID 집합체 유형(임시, 일반, 가상 집합체) 집합체명 계층정보 최하위 집합체 여부 개시일 종결일 시작일 종료일 설명

240

노트 P1-7. 아이템의 시스템 메타데이터는 아래와 같은 값을 포함한다(M).

아이템 UUID 아이템 유형 전자 여부 등록자, 등록일시 수정자, 수정일시 설명 노트 P1-8. 컴포넌트의 시스템 메타데이터는 아래와 같은 값을 포함한다(M).

컴포넌트 UUID DFR 컴포넌트 유형 공개여부 용량 썸네일 체크썸 설명 노트 P1-9. 집합체는 3가지 종류로 관리 할 수 있다(O).

임시 집합체(Temporary Aggregation) : 기록물을 입수하기 전에 생성하는 집합체를 말함. 임시 집합체에서는 사용자가 입수된 기록물에 대한 레코드 그룹, 시리즈, 파일로 계층을 만들 수 있으며, 메타데이터 정리도 가능

일반 집합체(Normal Aggregation) : 임시 집합체에서 모든 기록물의 정리가 끝나고 활성화 된 집합체

가상 집합체(Virtual Aggregation) : 일반 집합체에서 원하는 아이템을 선택하여 따로 컬렉션으로 지정한 후 실제 아이템을 레퍼런스하여 보여주는 집합체 P1-10. 집합체의 계층은 반드시 순서대로 생성하지 않아도 된다(M).

P1-11. 최하위 집합체에 플래그 표시를 해야 한다(M).

P1-12. 일반 집합체인 경우 반드시 계층레벨명을 선택해서 만들어야 하며, 임시 또는 가상 집합체인 경우 계층레벨명 없이 생성 가능해야 한다(M).

P1-13. 가상 집합체에는 기록물의 레퍼런스만 존재한다. 기록물의 원본은 일반 집합체에 존재해야 한다(O). P1-14. 일반 집합체는 다수의 분류자로 매핑 할 수 있다(M).

241

P1-15. 일반 집합체에만 전거 레코드를 부여할 수 있어야 한다(M).

P1-16. 모든 아이템은 집합체에 속해야 하며, 처음 입수된 기록물은 임시 집합체에 속해야 한다(M). P1-17. 아이템은 전자기록물과 비전자기록물을 구분할 수 있어야 한다(M).

P1-18. 하나의 아이템에는 N개의 컴포넌트를 가질 수 있다(M).

P1-19. 아이템 유형에는 결재문서, 이메일, 회의록, 웹문서 등이 있으며, 시스템 메타데이터와 맥락 메타데이터는 1:1의 구조를 가진다. 단, 필요에 따라 아이템의 맥락 메타데이터를 추가/삭제할 수 있으나, 시스템 메타데이터는 유지되어야 한다(M).

P1-20. 이메일 유형의 경우 아이템의 맥락 메타데이터에는 이메일 발신자, 수신자, 참조자 등 이메일의 헤드(HEAD)부분이 포함되어야 하고, 본문과 콘텐츠는 컴포넌트 맥락 메타데이터로 포함되어야 한다(M).

P1-21. 결재 문서 유형의 경우 아이템의 맥락 메타데이터에는 결재 문서 생산자, 발신자, 수신자, 참조 등 이 포함되어야 하고, 본문과 콘텐츠는 또 다른 맥락 메타데이터로 관리한다(M).

P1-22. 전자문서인 경우 본문·콘텐츠 등이 아이템을 구성하는 컴포넌트가 되며, 콘텐츠 유형에 따라 개별 엔티티를 만들어 관리해야 한다. 컴포넌트 메타데이터는 시스템 메타데이터와 맥락 메타데이터는 1:N의 구조를 가진다(M).

P1-23. 모든 컴포넌트의 메타데이터에서 키워드를 추출해낼 수 있다(O).

P1-24. 컴포넌트 별로 외부 서비스(대시민 등)에 공개여부를 결정하는 메타데이터를 가지고 있어야 한다(O).

P1-25. 각각의 컴포넌트에는 사본정보(Copy Entity)를 가지고 있어야 한다. 사본정보에는 복사본, 썸네일 이미지, 전자파일 등으로 구성된다(M). P1-26. 기록 서비스 API

계층 정보 제공 집합체 정보 제공 아이템 정보 제공 컴포넌트 정보 제공, 상속

242

n 기록서비스 ERD(Entity Relationship Diagram) 전체 ERD

<그림 249> 기록서비스 전체 ERD

243

A, B 부분

<그림 250> 기록서비스 상세 ERD (A, B)

C 부분

<그림 251> 기록서비스 상세 ERD (C)

244

D부분

<그림 252> 기록서비스 상세 ERD (D)

P2. 시스템관리 서비스

n 서비스 기반 아키텍처 차세대 기록관리시스템은 서비스별 아키텍처를 분할함으로써 각 기관에 요구되는 서비스를 선택적으로 활용을 할 수 있음 차세대 기록관리시스템의 Preservation service layer는 ‘Fundamental service’, ‘Essential service’, ‘Optional service’로 구분할 수 있음 Mandatory service : 기관 간에 공유 할 수 없으며 기록관리를 위해 의무적으로 요구되는 핵심 서비스 (기록 서비스, 시스템 서비스, 포탈 서비스) Essential service : 기관의 기록관리를 위해 요구되는 필수 서비스 (입수 서비스, 분류체계 서비스, 디지털 콘텐츠 서비스, 처분일정 서비스, 접근권한 관리 서비스, 디지털 스토리지 서비스, 서고관리 서비스, 디지털 보존 서비스) Optional service : 기록관리를 위해 기관의 요구사항에 맞춰 사용하는 서비스 (처분동결 서비스, 전거 관리 서비스, 내보내기 서비스, 리드케이스 관리 서비스, 필수기록물 관리 서비스, 워크플로우 서비스)

245

<그림 253>. 차세대 기록관리시스템의 서비스 구분

n 엔티티 개요 엔티티는 3가지 정보를 세트로 가지고 있다. 메타데이터 : 엔티티를 설명하는 정보이며, ‘시스템 메타데이터(System metadata)’, ‘맥락 메타데이터(Contextual metadata)’로 구분 이벤트 이력 : 엔티티에서 수행된 다른 기능에 대한 정보를 저장하는 엔티티와 관련 이벤트 이력 접근통제 이력 : 어떤 사용자 및 그룹이 엔티티의 기능을 수행할 수 있는지, 기능의 특정 세트가 역할로써 정의되었는지에 관해 명시된 접근통제 항목의 목록

<그림 254> 엔티티의 구성

엔티티에서 가장 중요 메타데이터 요소는 시스템 식별자이다. 차세대 기록관리시스템은 서비스에 대한 범용고유시별자(UUID)를 요구함

246

n 기능 요구사항

P2-1. 차세대 기록관리시스템은 다음의 서비스를 필수적으로 구현해야한다(M).

기록 서비스 시스템 관리 서비스 포탈 서비스 입수 서비스 분류체계 서비스 디지털 콘텐츠 서비스 처분일정 서비스 접근권한 관리 서비스 디지털 스토리 서비스 서고관리 서비스 디지털 보존 서비스 P2-2. 차세대 기록관리시스템은 기관의 요구에 따라 다음의 서비스를 선택적으로 구현할 수 있다(O). 처분동결 서비스 전거 관리 서비스 내보내기 서비스 리드케이스 관리 서비스 필수기록물 관리 서비스 워크플로우 서비스 P2-3. 엔티티는 다음의 메타데이터를 필수적으로 가지고 있어야 한다(M). 시스템 식별자(UUID) 제목(Title) 설명(Discription) 노트(Notes) P2-4. 차세대 기록관리시스템은 집합체, 아이템, 컴포넌트, 콘텐츠, 분류체계, 메타데이터 등 의 모든 종류의 개체를 감사추적 이력을 남길 수 있어야 한다(M). P2-5. 차세대 기록관리시스템은 아래와 같은 기능 및 이벤트를 감사추적 이력으로 남길 수 있어야 한다(M). 기록물 입수 정보 집합체 생성 및 수정 정보 분류체계 생성 및 수정 정보 집합체 내 기록물 건 이동 정보 처분일정 트리거, 처분동결 트리거 변경 정보 처분확정 시점 및 실제 처분 시점에 대한 정보 메타데이터에 관련된 모든 정보(생산, 수정, 삭제, 제공 등) 전자기록물 및 비전자기록물 위치 수정 정보

247

사용자의 열람 정보 P2-6. 이관을 위한 내보내기(export)에서는 기록물에 대한 모든 변경, 이동, 수정, 생성 등의 감사추적 이력도 함께 포함하여 내보낼 수 있어야 한다(M). P2-7. 엔티티별 수정 및 생성 이력을 관리해야 한다(M). P2-8. 시스템 오류에 대한 이력도 관리해야 한다(M). P2-9. 각 서비스별 데이터 통신을 위해 신뢰성, 안정성이 검증된 서비스 API와 프로토콜을 수용할 수 있어야 한다(M). P2-10. 다른 네트워크 환경에 위치한 시스템의 기록물도 접근할 수 있도록 지원하여야 한다 (M). P2-11. 전체 시스템을 지속적으로 모니터링할 수 있어야 하며, 사용자의 접근권한과는 별도로 설정변경을 임의로 통제할 수 있어야 한다(M). P2-12. 시스템의 운영체제, 성능 등에 대한 모든 정보를 로그로 남겨야 한다(M). P2-13. 시스템 내에서 정의되지 않은 메타데이터, 포맷정보 등을 식별할 수 있어야 한다 (M). P2-14. 시스템에서 오류 발생 시 즉각적으로 관리자에게 알려야 한다. 알리는 방법은 관리자가 설정할 수 있어야 한다(M). P2-15. 오픈소스를 이용한 서비스들의 수정이 잦은 만큼 안정적이고 유연한 아키텍처를 제공해야 한다(M). P2-16. 시스템 관리 서비스 API 감사 기록물 접근 추적 기록물 수정 이력 공통코드 제공 메시지 제공 환경설정 정보 제공 n 시스템관리 서비스 ERD(Entity Relationship Diagram)

전체 ERD

<그림 255> 시스템관리 서비스 전체 ERD

248

A, B부분

<그림 256> 시스템관리 서비스 상세 ERD (A, B)

C부분

<그림 257> 시스템관리 서비스 상세 ERD (A, B)

249

P3. 포탈 서비스

n 검색 사용자가 차세대 기록관리시스템에서 기록을 검색하는 방법은 크게 두가지로 구분할 수 있음. 하나는 사용자가 기록을 관련 엔티티를 탐색(Browse)하는 것이고, 다른 하나는 특정 검색어를 검색하여 기록을 찾는 것임 효과적인 검색을 위해 시스템/맥락 메타데이터를 활용한 검색, 동일 검색용어를 사용하는 전문 검색, 별도의 검색기준을 결합한 검색이 가능해야 함 사용자가 검색 결과 리스트 내의 엔티티를 정렬하고, 엔티티 리스트에 속하는 메타데이터 요소를 선택 하여 검색 결과를 만들 수 있어야 함

n 기능 요구사항 P3-1. 모든 아이템, 컴포넌트의 메타데이터 요소를 검색에 활용할 수 있어야 한다(M). P3-2. 관리자는 모든 집합체를 검색할 수 있어야 한다(M). P3-3. 관리자 뷰(view)와 사용자 뷰를 구분해야 한다(M). P3-4. 서비스별 대시보드에 보여줄 통계정보를 관리자가 설정할 수 있어야 한다. 관리자가 설정해준 범위 내에서 사용자가 다시 재배치 할 수 있어야 한다(M). P3-5. 서비스별 대시보드는 표와 그래프 형식 모두 선택이 가능하며, 복수 선택도 가능해야 한다(M). P3-6. 사용자는 사용자권한에 따라 보고서 리포트의 대상을 정의할 수 있어야 한다(M). P3-7. 하나의 뷰에서 여러 서비스의 통계를 볼 수 있어야 한다(M). P3-8. 기록물 유형, 생성일자 등 다양한 조건으로 검색을 할 수 있는 검색도구를 제공해야 한다(M). P3-9. 키워드 하나부터 여러 키워드를 조합하여 검색할 수 있는 상세검색 기능을 제공해야 한다(O). P3-10. 검색 된 아이템의 매핑된 분류체계 정보를 제공해야 한다(M). P3-11. 검색 된 컴포넌트가 속해있는 아이템, 분류체계 정보를 제공해야 한다(M). P3-12. 검색된 기록물에 대한 연관된 다른 기록물 링크를 제공해야 한다(O). P3-13. 검색된 결과 목록에 기록물 건의 사본여부를 제공해야 한다. 사본이 다른 시스템에서 쓰이고 있는 경우 그 사용하고 있는 시스템 명까지 제공해야 한다(O). P3-14. 검색된 기록물이 부분공개의 경우 발췌사본으로 제공해야 한다(O). P3-15. 검색 결과 목록은 내보낼 수 있게 엑셀 등 다양한 포맷으로 저장 및 인쇄기능을 제공해야 한다(M). P3-16. 출처, 생산자별로 검색결과를 정렬할 수 있어야 한다(M). P3-17. 기록물 검색 시 전거 레코드를 포함하여 검색되어야 하며, 전거 레코드를 기반으로 관련된 기록물들이 연계 검색되어야 한다(M). P3-18. 검색 결과는 사용자에 의해 재정렬 할 수 있는 기능을 제공해야 한다(M). P3-19. 포탈 서비스 API 서비스별 통계정보 제공

250

P4. 입수 서비스 n 입수 방법 전자 기록의 입수 방법은 2가지 방법으로 이루어진다. BagIt 포맷으로 변환 후 일괄로 이관 개별 데이터의 직접 이관

<그림 258> 전자기록 입수 프로세스 n 기능 요구사항 P4-1. 모든 유형의 기록물을 일괄 또는 개별로 입수할 수 있어야 한다(M). P4-2. 차세대 기록관리시스템은 기록물 입수시 SIP creator 등을 활용하여 Bagit 형태로 포맷을 변환하여 입수할 수 있어야 한다(M). P4-3. 전자문서생산시스템에서 생산된 기록물의 메타데이터를 모두 입수할 수 있어야 한다 (M). P4-4. 전자기록물의 경우 오프라인 경로로 매체 등을 통해 입수한 기록할 수 있어야 한다. 단, 인수한 기록물의 출처정보도 누락하지 않아야 한다(M). P4-5. 기록물을 건 단위로 인수할 수 있어야 한다. 또한 기록물 건에 속하는 컴포넌트와 콘텐츠들도 관계를 유지한 채로 입수할 수 있어야 한다(M). P4-6. 기록물 입수 시 기록물 고유의 포맷을 유지한 채 인수할 수 있어야 한다(M). P4-7. 아이템에 대한 사본이 존재할 경우, 사본에 대한 메타데이터도 차세대 기록관리시스템 내에서 관리될 수 있어야 한다(M). P4-8. 아이템의 본문과 콘텐츠, 사본의 정보 및 메타데이터는 각각의 컴포넌트로 구분하여 관리될 수 있어야 한다(M). P4-9. 아이템 유형별로 아래의 유형으로 입수할 수 있어야 한다(M). 생산시스템에서 기록관리시스템으로 기록물 전체를 이관해 오는 유형 생산시스템 내 기록물을 그대로 유지하되 기록관리시스템에서는 메타데이터 값만 입수하여, 해당 기록물을 포인팅하는 유형 생산시스템 내 기록관리 기능이 탑재되어있어 한 시스템에서 통합적으로 기록물을 관리하는 유형 P4-10. 기록물 건에 대한 생산 전거 레코드(Authority Record)를 포함하여 입수할 수 있어야 한다(O). P4-11. 기록물 입수 시 생산 히스토리 및 이관이력도 입수할 수 있어야 한다(M). P4-12. 외부 시스템 이관 외 직접 차세대 기록관리시스템에 아이템에 대한 정보를 등록할

251

수 있어야 한다(M). P4-13. 생산 시스템에서 부여된 기록물 고유 식별번호도 메타데이터에 포함하여 입수할 수 있어야 한다(M). P4-14. 입수된 모든 아이템은 임시 집합체로 입수 받을 수 있어야 한다(M). P4-15. 기록물 입수 시 무결성을 검증하기 위해 워크플로우가 자동으로 실행될 수 있도록 해야 한다. 워크플로우 Job은 아래와 같아야 한다(O). Select Package and Import From Transfer Area : SIP 대상파일을 입수 디렉토리 (Transfer Area) 에서 작업 디렉토리(Working Area) 로 이동한다. SIP Package Check : SIP Package 구조를 분석해서 이상유무를 확인한다. Virus Check : 감염시 작업진행 여부 및 치료여부를 설정한다. Fixty Check : Cheksum 이 부정합할 경우에 진행여부 및 생성여부를 확인한다. Metadata Integirity : 메타 데이터를 검증 한다. (필수 항목 여부, Data Format, Data Size등) Characterise : Contents의 파일 포멧정보를 식별하고 DFR정보와 PRONOM ID를 부여한다. Store Metadata : Metadata를 DB에 저장한다. Store Contents : Contents유형에 따라 설정된 저장 공간에 Contents를 저장한다. Thumbnail Creation : 섬네일 생성 가능한 포멧인 경우에 섬네일을 생성한다. P4-16. 시민기록을 수집할 때에는 사용자가 직접 기록물을 등록할 수 있어야 한다(M). P4-17. 입수 서비스 API 메타 데이터 정합성 확인 바이러스 체크 기록물 등록 n 입수 서비스 ERD(Entity Relationship Diagram) 전체 ERD

<그림 259> 입수 서비스 ERD

252

P5. 분류체계 서비스 n 분류체계, 분류자 모든 기록은 분류되어야 함. 이 의미는 모든 기록이 입수되어 관리할 때 항상 분류자와 연관된다는 것을 말한다. · 분류체계(Classification scheme) : 유사한 특징을 가진 자료를 모으고, 다른 특징을 가진 자료를 구분하기 위한 기준을 제시한 체계를 말함. 분류체계는 계층을 가질 수 있도 있고, 계층 없이 분류자만 등록하여 관리 할 수 있어야 한다. · 분류자(Class) : 업무기능, 활동, 트랜잭션을 나타내며, 기록을 분류자와 연관시키는 것은 기록을 생성되었던 업무 프로세스로 계속해서 링크시킴으로써 가장 확실한 업무 맥락 제공할 수 있다. 기관의 업무 기능에 따라 다양한 유형의 분류체계를 만들 수 있으며, 필요에 따라 한 기관에 다양한 분류체계가 존재 할 수 있음. 차세대 기록관리시스템은 다중 분류체계를 관리할 수 있어야 하며, 분류자 관리를 효과적으로 할 수 있어야 함

<그림 260> 다중 분류체계 관리 n 분류하기(상속) 집합체 내의 아이템이 동일한 업무 맥락을 공유하는 경우 그들의 부모 집합체에서 직접 자신의 분류자를 상속 할 수 있다. 이런 분류는 많은 양의 기록을 개별적으로 분류하지 않을 수 있어 업무효율성을 높일 수 있음 집합체 내의 기록이 동일한 업무 맥락을 공유하지 않은 경우 다른 분류자에 분류할 수 있음. 집합체 내의 아이템이 다른 업무 맥락을 가질 경우 다른 분류자에 아이템을 분류할 수 있음. 이런 경우 아이템은 그들의 부모 집합체에서 상속받은 기존 분류자 정보를 새로운 분류자 정보로 덮어쓰기(overriding)하여 개별적으로 분류함

253

<그림 261> 기록의 분류와 상속 n 기능 요구사항 P5-1. 모든 기록은 분류하여 관리해야 한다(M). P5-2. 관리자가 필요에 따라 분류체계를 추가할 수 있어야 한다(M). P5-3. 분류체계에 분류레벨의 제한을 두지 않아야 한다(M). P5-4. 분류자는 집합체, 아이템 어디에나 매핑할 수 있어야 한다(M). P5-5. 집합체가 분류된 경우 분류자의 정보가 집합체 상속되며, 집합체에 묶인 아이템도 분류자 정보를 상속받는다(M). P5-5. 아이템은 기본적으로 부모 집합체가 매핑한 분류 정보를 상속 받지만, 필요에 따라 직접 분류자와 매핑 할 수 있다(M). P5-6. 아이템은 분류체계별 하나의 분류자를 가지나 특정 분류체계의 분류자를 가지지 않을 수 있다(M). P5-7. 관리자는 분류자의 분류자명, 설명, 노트 정보뿐만 아니라 모든 맥락 메타데이터를 수정할 수 있어야 한다(M). P5-8. 분류자에 처분일정을 매핑 할 수 있다(M). P5-9. 관리자는 분류자에 매핑된 처분일정을 새로운 처분 일정으로 변경할 수 있다(M). P5-10. 분류자의 처분일정이 변경되면 해당 분류자로 분류된 모든 기록은 새로운 처분일정으로 변경되어야 한다(M). P5-11. 분류자의 시스템 메타데이터는 아래와 같은 값을 포함한다(M). 분류자 UUID 분류체계 유형 분류자명 계층정보 시작일 종료일

254

설명 노트 P5-12. 분류체계 서비스 API

다중 분류체계 제공 기록물 분류 정보 제공 기록물 분류 n 분류체계 서비스 ERD(Entity Relationship Diagram)

전체 ERD

<그림 262> 분류체계 서비스 전체 ERD

A부분

<그림 263> 분류체계 서비스 상세 ERD (A)

255

B부분

<그림 264> 분류체계 서비스 상세 ERD (B)

P6. 디지털콘텐츠 서비스 n 콘텐츠 기록의 실제 내용(contents, 이하 콘텐츠)이나 데이터는 차세대 기록관리시스템의 엔티티에 분산되어 있고, 별개의 장소나 데이터베이스에 저장될 수 있음 각 기록의 콘텐츠는 다양한 형태를 가질 수 있음 전자문서와 같은 디지털 데이터 파일 웹 브라우저에 웹 페이지를 렌더링하는데 필요한 데이터 파일 데이터베이스 테이블의 행이나, 관계 테이블의 행 비즈니스 시스템의 엔티티 아이템과 콘텐츠의 연계는 컴포넌트 엔티티를 통해 이루어진다. 하나의 아이템은 1개 이상의 컴포넌트를 가지며, 각각의 컴포넌트는 콘텐츠의 개별 아이템을 참조한다.

<그림 265> 아이템의 구성

256

n 기능 요구사항 P6-1. 콘텐츠 서비스가 다루는 콘텐츠는 모두 비트스트림이다(M). P6-2. 콘텐츠 서비스를 통해 모든 유형의 기록물을 사용자가 열람할 수 있어야 한다(M). P6-3. 모든 기록물은 차세대 기록관리시스템 내 지정되어 있는 포맷형식으로 관리되어야 한다(M). P6-4. 유형별 포맷 솔루션을 관리자가 지정할 수 있어야 한다(M). P6-5. 콘텐츠 서비스는 메뉴나 특정기능으로 구현되지 않아야 하며, 관리자가 지정한 솔루션을 통하여 기록을 제공할 수 있어야 한다(M). P6-6. 영상음성 기록물의 경우 길이를 편집할 수 있어야 한다. 또한 영상기록물 내의 썸네일을 추출할 수 있어야 한다(M). P6-7. 이미지 기록물의 경우 해상도나 크기 등을 편집할 수 있어야 한다(M). P6-8. 특정 소프트웨어가 있어야 열 수 있는 형태의 포맷(hwp, ppt, cad 등)을 가진 기록물의 경우 차세대 기록관리시스템 내 뷰어를 통해 콘텐츠 정보를 제공할 수 있어야 한다 (M). P6-9. 1개의 콘텐츠에 2개 이상의 아이템 레퍼런스가 가능해야 한다(M). P6-10. 콘텐츠 저장장소는 System Parameter로 설정하고, 컴포넌트에는 상대경로 값만 가지고 있어야 한다(M). P6-11. 디지털 콘텐츠 서비스 API 포맷유형별 뷰어 솔루션 연계 P7. 처분일정 서비스

n 기록 생애주기 처분일정은 차세대 기록관리시스템 상의 기록의 생애주기 관리에 사용됨 기록이 생산되면 존재하지 않았던 것과 같이 완전히 삭제할 수 없음. 비록 완전한 기록과 그 내용이 더 이상 존재하지 않더라도 차세대 기록관리시스템은 그 기록을 한 때 관리하고 있었다는 사실을 잔존 기록(residual record)으로 가지고 있어야 함

<그림 266> 기록 생애주기

257

n 처분일정 및 처분행위 처분일정 관리는 기록관리에 있어서 매우 중요하며, 차세대 기록관리시스템은 처분일정 관리를 통해 처분 행위가 이루어져야 함 처분일정에 따라 다음의 4가지 중 하나의 결과를 규정하여 처분행위를 해야 함 영구보존 보유기간이 지난 후 검토 보유기간이 지난 후 이관 보유기간이 지난 후 폐기 n 보유기간 산정과 트리거 처분일정은 일, 주, 월, 년 수로 정의된 보유기간이 있고, 특정일을 기준으로 보유가 시작되어 특정일에 보유가 종료되는 보유기간이 있음 기간을 산정하는 처분일정은 보유 트리거에 의해 관리되어야 함 차세대 기록관리시스템의 보유 트리거는 개별 아이템이나 아이템의 부모집합체와 관계를 가짐 n 기록 폐기 생애주기 생산된 기록에 처분일정이 부여되고, 보유기간 동안 기록은 차세대 기록관리시스템 상에 존재함 처분 예정일이 도래한 기록물 은 폐기 여부 확인을 위해 폐기 대상 기록물로 분류됨. 단, 처분동결 상태의 기록은 처분 예정일이 도래하여도 폐기 대상 기록물로 분류되지 않음. 처분 동결 상태의 기록을 폐기하기 위해서는 처분동결이 먼저 해제되어야 함 폐기 대상 기록은 검토 후 새로운 처분일정이 부여되거나 폐기 행위가 이루어지며, 폐기하는 기록은 잔존 엔티티만 남기고 폐기됨

<그림 267> 기록 폐기 생애주기 n 기능 요구사항 P7-1. 모든 기록물은 처분일정에 의해 처분 관리 되어야 한다(M). P7-2. 처분일정은 GRS(General Records Schedule)과 RS(Records Schedule)로 구분하여 관리해야 한다(M).

258

P7-3. 집합체, 아이템, 분류자에 처분일정을 부여할 수 있어야 한다(M). P7-4. 아이템은 기본적으로 자신이 속한 집합체에 부여된 처분일정을 상속받는다(M). P7-5. 처분일정은 연/월/주/일 단위로 기록에 따라 보유기관을 달리하여 관리될 수 있어야 한다(M). P7-6. 관리자는 분류자, 집합체, 아이템에 트리거를 활용하여 처분일정을 부여할 수 있다. 분류자나 집합체에서 상속된 처분일정을 가지고 있는 아이템은 관리자가 처분일정 을 수정할 수 있어야 한다(M). P7-7. 아이템의 부모 집합체 정보가 변경되었을 경우, 부모 집합체의 처분 일정이 상속된 아이템은 변경된 집합체의 처분일정을 새로 상속받을 수 있어야 한다(M). P7-8. 집합체에서 상속된 처분 일정이 아닌 사용자가 임의적으로 처분일정을 수정했을 경우에는 집합체를 변경해도 임의로 설정된 처분일정을 유지할 수 있어야 한다(M). P7-9. 사본기록물은 처분일정과 관계없이 언제든지 파기할 수 있어야 한다. 또한 사본 기록물을 활용하고 있는 외부 시스템에도 파기정보를 제시하여야 한다(M). P7-10. 아이템 수준에도 처분여부를 제시해주어야 한다(O). P7-11. 처분 일정이 도래한 기록물의 목록을 조회할 수 있어야 하며, 엑셀 등으로 내보내기 할 수 있으며 인쇄 할 수도 있어야 한다(M). P7-12. 시스템으로 폐기된 기록물이 비전자기록물인 경우 물리적 기록물 처분여부를 관리해야 한다(O). P7-13. 메타데이터 값만 관리하는 전자기록물의 경우 실제 전자기록물 원본이 있는 시스템에 처분 일정이 도래한 사실을 알려주어야 하며, 실제 처분 여부를 관리해야 한다(M). P7-14. 기록물 폐기 시 기록물의 잔존 메타데이터는 남겨두어야 한다(M). P7-15. 처분확정일과 실제 처분일정은 다를 수 있으므로 두 정보 모두 관리 가능해야 한다 (M). P7-16. 아이템의 메타데이터에서는 집합체에서 처분일정을 상속받았는지, 또는 사용자가 임의로 설정했는지의 여부를 판단할 수 있어야 한다(M). P7-17. 모든 처분일정은 관리자가 상·하향조정 할 수도 있어야 한다(M). P7-18. 처분일정 서비스 API 일반 처분일정(GRS) 정보 제공 처분일정(RS) 정보 제공 n 처분일정 서비스 ERD(Entity Relationship Diagram) 전체 ERD

259

<그림 268> 처분일정 서비스 전체 ERD

P8. 접근권한 서비스

n 사용자 및 그룹 관리 사용자 및 그룹을 잘 관리하는 것은 차세대 기록관리시스템의 성공적인 운영을 위한 필수 요소 차세대 기록관리시스템은 역사적인 정보를 포함하여 사용자 및 그룹에 관한 정보를 추가하고 안정적으로 유지해야함 시스템 식별자를 사용하는 것, 엔티티의 메타데이터 변경사항을 추적하는 것, 엔티티가 더 이상 활동하지 않을 경우 시스템에서 엔티티를 완전히 삭제하는 대신 잔존 엔티티를 남기고 사용자 및 그룹이 폐기된 후에도 정보를 유지해야함 사용자 및 그룹 간의 다대다 관계 설정을 통해 각 사용자가 다양한 그룹에 속할 수 있으며, 많은 사용자가 동일한 그룹에 속할 수 있어야 함

260

<그림 269> 사용자와 그룹의 다대다 관계 설정 n 기능 요구사항 P8-1. 차세대 기록관리시스템은 사용자와 그룹으로 관리될 수 있어야 하며, 집합체, 아이템에 접근 및 권한을 관리할 수 있어야 한다(M). P8-2. 차세대 기록관리시스템 내 모든 기능과 발생하는 이벤트를 관리 할 수 있어야 한다 (M). P8-3. 사용자와 그룹의 권한을 연결할 수 있어야 하다(M). P8-4. 관리자는 전체 사용자 권한을 가지면 시스템을 총괄 관리 할 수 있어야 한다(M). P8-5. 사용자를 그룹으로 묶은 후 접근 통제 목록(Access Control List, 이하 ACL)을 구성하여 관리해야 한다(M). P8-6. 사용자에게 집합체, 아이템, 컴포넌트 별로 접근권한을 부여 할 수 있어야 한다(M). P8-7. 사용자에게 서비스 단위, 엔티티 단위 수준으로 접근권한을 부여 할 수 있어야 한다 (M). P8-8. 부모 집합체에 접근권한이 설정되면 자식 집합체에도 그 권한이 종속되며, 자식 집합체는 접근권한을 변경 할 수도 있다(M). P8-9. 개별 사용자는 N개의 그룹에 포함될 수 있어야 한다(M). P8-10. Preservation Service Layer와 Business Service Layer는 사용자 관리를 별도로 할 수 있어야 한다(O). P8-11. 권한의 시스템 메타데이터는 아래와 같은 값을 포함한다(M). 권한 UUID 제목 생성일 설명 노트 P8-12. 그룹의 시스템 메타데이터는 아래와 같은 값을 포함한다(M). 그룹 UUID

261

제목 생성일 설명 노트 P8-12. 제목, 사용자 엔티티, 사용자 세부사항 등에 대한 변경사항을 반영하기 위해 모든 맥락 메타데이터의 수정을 관리자가 할 수 있어야 한다(M). P8-13. 활성 그룹에 사용자를 추가 및 삭제할 수 있어야 하며, 추가/삭제가 발생할 때 마다 이벤트가 생성 관리되어야 한다(M). P8-14. 특정 역사적인 일시에 지명된 그룹에 속한 사용자를 목록화하여 보고서를 생성할 수 있어야 한다(M). P8-15. 접근권한관리 서비스 API 퍼미션(Permission) 정보 제공 사용자 및 사용자그룹별 역할(Role) 정보 제공 기록물 접근권한 정보 제공 n 접근권한 서비스 ERD(Entity Relationship Diagram) 전체 ERD

<그림 270> 접근권한 서비스 ERD

P9. 디지털스토리지 서비스

n 기능 요구사항 P9-1. 모든 전자기록물의 스토리지 위치, 논리 디렉토리 정보를 관리해야 한다(M). P9-2. 기록물의 유형(일반문서, 도면, 이미지, 영상 등)에 따라 별도 스토리지가 있어야 한다 (O). P9-3. 임시 집합체의 경우 별도의 임시 스토리지를 가지고 있어야 한다(O).

262

P9-4. 임시 집합체에 위치한 기록물이 일반 집합체으로 이동하게 되면 임시 스토리지에서 아카이빙 스토리지로 위치를 변경해주어야 한다(M). P9-5. 관리자가 스토리지의 용량을 설정할 수 있어야 하며, 잔여 용량을 확인할 수 있어야 한다. 또한 저장 용량이 한계치에 다다를 경우 관리자에게 알려주어야 한다(M). P9-6. 전자기록물을 분할하여 저장 할 수 있어야 한다(O). P9-7. 기록물의 스토리지를 관리자가 직접 선택하여 저장할 수 있어야 한다(M). P9-8. 관리자가 백업주기, 백업대상 스토리지를 설정할 수 있어야 한다(M). P9-9. 백업시 모든 메타데이터 정보를 포함해야 한다(M). P9-10. 시스템에서 오류가 발생했을 경우 최근 백업한 정보를 복구할 수 있어야 한다(M). P9-11. 백업한 정보를 복구하였을 경우 데이터 무결성을 검증할 수 있는 기능을 제공해야 한다(M). P9-12. 관리자는 백업한 정보를 복구할 때, 부분복구 또는 전체복구를 선택할 수 있어야 한다(M). P9-13. 필수기록물의 경우 별도 스토리지에 저장해야 한다(O). P9-14. 저장 진행 및 완료 상태를 실시간으로 확인할 수 있어야 한다(O). P9-15. 콘텐츠 유형별로 저장위치를 구분해서 관리할 수 있어야 한다(O). P9-16. 디지털스토리지 서비스 API 스토리지 할당 물리적 위치정보 제공 논리적 위치정보 제공 n 디지털스토리지 서비스 ERD(Entity Relationship Diagram)

전체 ERD

<그림 271> 디지털스토리지 서비스 전체 ERD

263

A부분

<그림 272> 디지털스토리지 서비스 상세 ERD (A)

B부분

<그림 273> 디지털스토리지 서비스 상세 ERD (B)

264

P10. 서고관리 서비스

n 기능 요구사항 P10-1. 모든 비전자기록물의 배치정보를 관리할 수 있어야 한다(M). P10-2. 비전자기록물의 경우 서고, 서가, 행열단, 컨테이너 각각의 위치를 가져야 한다(M). P10-3. 서고의 경우 사용여부를 제한하게 되면 해당 서가정보도 넣을 수 없어야 한다(M). P10-4. 서고, 서가, 행열단, 컨테이너의 정보를 최초로 등록한 자, 수정한 자, 서고 사용여부 를 종료한 자를 각각 관리할 수 있어야 한다(M). P10-5. 처분 일정이 도래하여 처분 확정된 기록물의 경우 논리적 처분 실행시점과 물리적 처분 실행시점이 다르므로 실제 처분실행이 이루어질 때까지 위치를 관리해주어야 한다(M). P10-6. 서고관리 서비스 API 위치 정보(서고, 서가, 행, 열) 제공 비전자기록물 배치 비전자기록물 변경 정보(반입, 반출, 열람) 관리 n 서고관리 서비스 ERD(Entity Relationship Diagram) 전체 ERD

<그림 274> 서고관리 서비스 전체 ERD

265

A부분

<그림 275> 서고관리 서비스 상세 ERD (A)

B부분

<그림 276> 서고관리 서비스 상세 ERD (B)

266

P11. 디지털보존 서비스 n 기능 요구사항 P11-1. 차세대 기록관리시스템은 기록에 대한 장기보존 계획(에뮬레이션, 마이그레이션, 인캡슐레이션)의 기능을 가지고 있어야 한다(M). P11-2. 시스템 내 지정한 포맷의 정보는 DFR(Digital Format Registry)과 연동되어야 한다 (M). P11-3. 시스템 내 DFR에 대한 마스터 엔티티를 생성해야 한다(M). P11-4. DFR과 컴포넌트를 연결시켜 관리해야 한다(M). P11-5. 시스템 내 지정되지 않은 포맷은 지정된 포맷으로 변환시켜 주어야 한다(M). P11-6. 포맷변환은 별도의 툴을 관리자가 지정할 수 있어야 한다(M). P11-7. 중요 기록물의 장기보존을 위해 보존용 사본 제작을 할 수 있는 기능이 있어야 한다 (M). P11-8. 매체의 노후화에 따른 매체 전환, 이전을 할 수 있어야 한다(M). P11-9. 매체등록 및 관리를 할 수 있어야 한다(M). P11-10. 매체를 이전했을 경우 관리자는 실시간으로 처리과정과 결과를 확인할 수 있어야 한다(O). P11-11. 장기보존포맷 형식으로 AIP(Archival Information Package)를 생성할 수 있어야 한다(M). P11-12. 장기보존 실행을 계획할 수 있는 기능이 있어야 한다. 관리자가 지정한 일시가 도 래하면 시스템 내에서 관리자에게 알려줄 수 있어야 한다(O). P11-13. AIP 생성의 경우 아이템 단위까지만 패키징 가능하며, 컴포넌트, 콘텐츠는 해당되 지 않는다. 아이템을 패키징하면 아이템 하위에 해당되는 컴포넌트와 콘텐츠가 포함 되어 패키징 될 수 있어야 한다(M). P11-14. 아이템 단위부터 AIP를 생성할 수 있어야 한다(O). P11-15. 포맷 변환은 컴포넌트 단위까지 가능하다(M). P11-16. 보존포맷 변환의 경우 처분 일정을 기준으로 포맷을 분류해서 설정할 수 있어야 한 다(M). P11-17. 디지털 보존 서비스 API 보존포맷 변환 장기보존 포맷변환 n 디지털보존 서비스 ERD(Entity Relationship Diagram) API관리 전체 ERD

267

<그림 277> 디지털보존 서비스 전체 ERD

API관리 A부분

<그림 278> 디지털보존 서비스 상세 ERD (A)

268

API관리 B부분

<그림 279> 디지털보존 서비스 상세 ERD (B)

포맷변환 전체 ERD

<그림 280> 포맷변환 전체 ERD

269

포맷변환 A부분

<그림 281> 포맷변환 상세 ERD (A)

포맷변환 B부분

<그림 282> 포맷변환 상세 ERD (B)

270

포맷변환 C부분

<그림 283> 포맷변환 상세 ERD (C)

매체이전 전체 ERD

<그림 284> 매체이전 전체 ERD

271

P12. 처분동결 서비스

n 기능 요구사항 P12-1. 처분동결은 집합체, 아이템에 설정할 수 있어야 한다(M). P12-2. 처분동결 이벤트를 추가, 수정, 삭제 할 수 있어야 한다(M). P12-3. 아이템의 집합체 정보가 변경되었을 경우 변경된 집합체의 처분동결 일정을 새로 상속받을 수 있어야 한다(M). P12-4. 집합체에서 상속된 처분동결 일정이 아닌 사용자가 임의적으로 처분동결 일정을 부여했을 경우에는 집합체를 변경해도 임의로 설정된 처분동결 일정을 유지할 수 있어야 한다(M). P12-5. 처분동결 상태인 기록물은 처분예정일이 도래하여도 처분대상에 포함되지 않는다 (M). P12-6. 아이템단위로 처분동결 여부를 제시해주어야 한다(M). P12-7. 처분동결 상태인 아이템은 동결해제 관련 재검토 일정이 도래할 경우 기록물 목록을 조회할 수 있어야 하며, 엑셀 등으로 저장 및 인쇄 기능으로 내보낼 수 있어야 한다(M). P12-8. 처분동결이 확정된 기록물은 처분동결에 대한 플래그 값을 가진다(M). P12-9. 하나의 아이템에 여러 개의 처분동결 사유가 적용될 수 있다(M). P12-10. 처분동결 사유에 대한 엔티티를 별도로 관리해야 한다(O). P12-11. 처분동결 차수는 처분동결 사건에 행위를 할 때 마다 누적되어야 한다(O). P12-12. 처분동결 여부 및 일정은 집합체, 아이템에 상속이 가능해야 한다(M). P12-13. 처분동결을 해제할 경우 처분동결 플래그를 아이템에서 삭제해야 한다(M). P12-14. 처분일이 도래했지만 처분동결로 처분하지 못한 대상 기록물은 별도 리스트로 관리자에게 제공할 수 있어야 한다(M). P12-15. 처분동결 서비스 API 처분동결 이벤트 제공 처분동결 차수 제공 기록물 처분동결 및 해제

n 처분동결 서비스 ERD(Entity Relationship Diagram) 전체 ERD

272

<그림 285> 처분동결 서비스 전체 ERD

P13. 전거 관리 서비스

n 기능 요구사항 P13-1. 모든 집합체, 아이템, 컴포넌트는 전거 레코드에 의해 관리 할 수 있어야 한다(M). P13-2. 전거 레코드에는 아래의 아이템 유형과 같은 생산자 또는 출처를 밝힐 수 있는 시스템 정보를 보유하고 있어야 한다(M). 개인 단체 건물

273

사건 각종 출처 시스템 P13-3. 전거레코드에 대한 트랜잭션을 별도로 관리해야 한다(M). P13-4. 전거레코드에 대한 마스터 테이블을 구성해야 하며, UUID를 사용하여야 한다(M). P13-5. 전거레코드에 대한 마스터 테이블에는 생산시스템, 인물, 조직(부서), 단체, 장소(주소 제외), 사건명 등이 관리되어야 한다(M). P13-6. 일반 집합체에 속한 컴포넌트에만 전거레코드를 입력할 수 있어야 한다(O). P13-7. 전거레코드가 없는 경우도 허용해야 한다(M). P13-8. 기록물 인수시 전거정보를 함께 인수할 경우 각각의 기록물마다 이전 시스템의 전거 정보와 비교할 수 있는 기능을 제공해야 한다(O). P13-9. 집합체 정보 수정시 전거레코드 대상은 전거레코드를 재 선택할 수 있게 API를 설계해야 한다(M). P13-10. 전거레코드로 통제된 데이터는 하이퍼링크가 되어야 한다(O). P13-11. 전거 관리 서비스 API - 기록물 전거

P14. 내보내기 서비스

n 기능 요구사항 P14-1. 모든 통계화면에서는 내보내기(Export) 기능이 제공되어야 한다(M). P14-2. 내보내기 유형은 사용자가 선택할 수 있어야 한다(M). P14-3. 웹 서비스 시스템과 주고받은 트랜젝션을 관리할 수 있어야 한다(M). P14-4. 내보내기를 실행한 사용자의 이력과 해당 내보내기 데이터를 이력으로 남길 수 있어야 한다(M). P14-5. 내보내기 결과는 엑셀, xml, Jason 중 선택이 가능해야 한다(M). P14-6. 내보내기 실행시 Audit Trail 생성하고, 내보내기 대상을 선택할 수 있어야 한다(M). P14-7. 내보내기는 시스템 내 표준화된 메타데이터로 관리되어야 한다(M). P14-8. 내보내기 실행시 Query, 일시정보, 주체, 시스템이름 등의 정보가 개별 파일로 제공 되어야 한다(M). P14-9. 내보내기 실행시 진본성 확인을 위하여 Audit Trail 정보도 포함되어야 한다(M). P14-10. Audit Trail의 경우 수정하지 않고 표준화된 포맷으로 제공되어야 한다(M). P14-11. 기록물 사본이 내보내기 할 경우 발췌사본 정보를 시스템 내에서 가지고 있어야 한다 (M). P14-12. 아이템과 관련된 메타데이터를 출력할 수 있어야 한다(O). P14-13. 기록물의 검색결과를 목록을 출력할 수 있어야 한다(O). P14-14. 집합체의 계층정보 자체를 내보낼 수 있어야 한다(O). P14-15. 내보내기 서비스 API 형태별(XML, Jason 등) DIP 생성

274

n 내보내기 서비스 ERD(Entity Relationship Diagram) 전체 ERD

<그림 286> 내보내기 서비스 전체 ERD

A부분

<그림 287> 내보내기 서비스 상세 ERD (A)

275

B부분

<그림 288 > 내보내기 서비스 상세 ERD (B)

P15. 리드케이스관리 서비스

n 기능 요구사항 P15-1. 수집된 기록물에 대한 메타데이터 정보를 별도로 관리할 수 있어야 한다(M). P15-2. 수집된 기록물은 출처, 생성자 등 관리자가 지정한 조건으로 검색이 가능해야 한다 (O). P15-3. 수집된 기록물은 양도, 구입, 기증, 위탁 등의 수집유형을 관리할 수 있어야 한다 (M). P15-4. 수집된 기록물에 대한 기본적인 리드정보를 관리할 수 있어야 한다(M). P15-5. 수집된 기록물에 대한 진본을 확인할 수 있는 툴을 제공할 수 있어야 한다(M). P15-6. 수집된 기록물은 인수된 기록물과 마찬가지로 유형별로 관리되어야 한다(M). P15-7. 수집된 기록물을 시스템에 등록할 경우 임시 집합체에 관리한다(M). P15-8. 관리자 및 인가된 사용자는 임시 집합체에 속한 수집된 기록물에 대해 확인 후 일반 집합체로 이동할 수 있어야 한다(M). P15-9. 일반 집합체로 이동한 수집 기록물은 분류체계와 매핑 할 수 있어야 한다(M). P15-10. 수집된 기록물에 처분일정 및 처분동결 일정을 부여할 수 있어야 한다(M). P15-11. 수집된 기록물을 별도로 통계되어 제공될 수 있어야 한다(M). P15-12. 리드케이스 관리 서비스 API - 수집기록물 분류

276

P16. 필수기록물관리 서비스

n 기능 요구사항 P16-1. 관리자 및 인가된 사용자가 지정한 필수 집합체, 아이템에 대한 정보를 관리할 수 있어야 한다(M). P16-2. 관리자 및 인가된 사용자는 필수 기록물의 갱신 주기를 설정할 수 있어야 한다(M). P16-3. 시스템 내에서 갱신주기에 맞추어 관리자 및 인가된 사용자에게 지정된 방법으로 알려줄 수 있어야 한다(M). P16-4. 필수기록물은 비상운영 기록물과 권한보호 기록물의 유형으로 관리되어야 한다(M). P16-5. 필수기록물의 특성에 맞추어 집합체, 아이템별 보관 및 관리 방법을 각각 설정할 수 있어야 한다(M). P16-6. 동일한 필수 기록물일지라도 최신 기록물 정보로 업데이트 해주어야 한다(O). P16-7. 필수기록물 관리 서비스 API - 필수기록물 선별 - 필수기록물 이중보호 및 분산보호

P17. 워크플로우 서비스

n 기능 요구사항 P17-1. 차세대 기록관리시스템을 구성하고 있는 각각의 개별 서비스에 대한 워크플로우 Job을 설정 및 통제할 수 있어야 한다(M). P17-2. 관리자 및 인가된 사용자는 워크플로우를 통해 집합체, 아이템의 상태를 실시간으로 모니터링 할 수 있어야 한다(M). P17-3. 메타데이터에 대한 워크플로우와 콘텐츠에 대한 워크플로우를 별도로 설정할 수 있어야 한다(M). P17-4. 워크플로우 Job에 대한 엔티티가 존재해야 한다(M). P17-5. 워크플로우 Job의 수를 제한하지 않아야 한다(M). P17-6. 관리자 외 인가되지 않은 사용자는 워크플로우를 변경할 수 없도록 해야 한다(M). P17-7. 워크플로우의 모든 변경 사항의 이력이 관리되어야 한다(M). P17-8. 워크플로우 내에 아이템들에 대한 우선순위를 부여할 수 있어야 한다(O). P17-9. 워크플로우 Job 중 오류가 발생했을 경우 실시간으로 관리자에게 알려야 한다(M). P17-10. 워크플로우의 Job 중 하나의 Step에서 오류가 발생했을 경우 오류를 즉각 보정해서 워크플로우를 계속 진행할 수 있어야 한다(M). P17-11. 워크플로우에서 오류가 발생했을 경우 관련이 없는 전체 워크플로우가 멈추지 말아야 한다(M). P17-12. 워크플로우에서 오류가 발생했을 경우 개별 아이템을 선별하여 수동으로 다음 Step으로 진행할 수 있어야 한다(M). P17-13. 인가된 사용자의 경우 워크플로우 Job을 수정가능하며, 수정한 사용자의 이력을 관리해야 한다(M).

277

P17-14. 워크플로우를 통해 관리된 아이템의 경우 작업량, 진행사항 등을 보고서로 작성될 수 있어야 한다(M). P17-15. 워크플로우 서비스 API 워크플로우 목록 제공 워크플로우 실행 워크플로우 실행결과 제공 n 워크플로우 서비스 ERD(Entity Relationship Diagram)

전체 ERD

<그림 289> 워크플로우 서비스 전체 ERD

278

A, B부분

<그림 290> 워크플로우 서비스 상세 ERD (A, B)

나. Business Service Layer

B1. 원문공개 서비스

B1-1. 차세대 기록관리시스템 Preservation Service Layer와 API호출로 연계 가능해야 한다(M). B1-2. 사용자의 접근권한별 정보를 관리하기 위한 사용자 권한 등록, 수정, 삭제, 조회 기능을 제공하여야 한다(M). B1-3. 일반 사용자에게 정보공개청구신청서를 접수 받을 때 아래 기재사항을 관리해야 한다 (M). 청구인의 이름, 주민등록번호, 주소 청구일시 청구하는 정보내용 공개형태 수령방법

279

B1-4. 기관 내 조직정보를 관리자 설정주기대로 업데이트 할 수 있어야 한다(M). B1-5. 정보공개청구신청서가 접수되면 처리과에게 실시간으로 공지될 수 있어야 한다(O). B1-6. 전자결재 문서의 공개 여부 및 비공개 사유 변경 기능을 제공해야 한다(O). B1-7. 결재문서 비공개 시 비공개 상세사유를 필수 입력할 수 있어야 한다(M). B1-8. 일정기간 원문정보의 공개/비공개 유예가 필요한 경우 제한종료일을 설정할 수 있어야 하며, 해당 제한종료일에 도래하면 자동공개 할 수 있도록 공개제한 일자를 설정할 수 있는 기능을 제공해야 한다(M). B1-9. 차세대 기록관리시스템 Preservation Service Layer 단과 연계하여 원문정보 목록을 관리할 수 있어야 한다(M). B1-10. 차세대 기록관리시스템 Preservation Service Layer 단과 연계하여 대상 기록물에 대한 위치정보 및 공개/비공개 여부를 확인할 수 있어야 한다(M). B1-11. 청구대상 기록에 대한 본문, 붙임자료 등에 개인정보가 있을 경우 필터링하여 공개할 수 있도록 필터링 기능을 제공해야 한다(M). B1-12. 청구대상 기록에 개인정보가 있을 시 개인정보 포함 내역을 통보할 수 있어야 한다 (M). B1-13. 기간별 원문정보 접수, 공개/비공개 여부 등의 현황을 통계로 제공할 수 있어야 한다 (O). B1-14. 처리과별 원문정보공개 처리 현황을 통계로 제공할 수 있어야 한다(O). B1-15. 대상 기록물은 PDF, 엑셀 등 관리자가 설정한 형태로 변환하여 제공해야 한다(M). B1-16. 원문공개가 되는 대상에 대해서 목록으로 관리될 수 있어야 한다(M). B1-17. 원문공개가 시행된 내역에 대해서 별도의 로그로 관리될 수 있어야 한다(M). B1-18. 원문공개 대상문서의 붙임자료에 대한 개별 공개/비공개 기능이 있어야 한다(M). B1-19. 원문정보공개 대상문서의 본문 및 붙임자료에 포함된 개인정보 유출방지를 위하여 개인정보 및 금칙어 검출 기능을 제공하여야 한다(M). (전화번호, 주민등록번호, 외국인 등록번호, 전자우편, 계좌번호, 신용카드 번호, 생년월일, 주소 등)

B2. 반입반출 서비스

B2-1. 차세대 기록관리시스템 Preservation Service Layer와 API호출로 연계 가능 해야 한다 (M). B2-2. 차세대 기록관리시스템 Preservation Service Layer와 연계하여 기관 내 처분되지 않은 기록물에 대한 목록을 조회할 수 있어야 한다(M). B2-3. 관리자의 권한은 기관 내 기록물 반출입 담당자 또는 기록연구사에게 부여해야 하며, 사용자의 권한은 기관 내 처리과 담당자에게 부여해야 한다(M). B2-4. 해당 기관 내 서고에 위치해있는 기록물의 목록을 조회할 수 있어야 한다(M). B2-5. 생산부서, 제목, 생산년도, 종료년도의 검색요건을 통해 기록물에 대하여 검색할 수 있어야 한다(M). B2-6. 기록물을 반출입하는 사용자의 아래와 같은 정보를 관리할 수 있어야 한다(M). 사용자 아이디

280

사용자 이름 소속 처리과 반출입 일시 반출입 사유 B2-7. 대상 기록물에 대한 현재 상태(반출입 여부)를 검색 할 수 있어야 한다(M). B2-8. 사용자는 대상 기록물에 대해 반출예약을 할 수 있어야 한다(M). B2-9. 관리자는 기록물의 목록, 반출입 이력의 목록을 엑셀의 형태로 제공받을 수 있어야 한다(M). B2-10. 사용자는 모든 검색결과에 대하여 엑셀의 형태로 제공받을 수 있어야 한다(M). B2-11. 사용자는 서비스 내에서 기록물 반출반입서를 등록 할 수 있어야 한다(M). B2-12. 관리자는 기록물 반출반입서에 대한 처리과별, 사용자별, 일자별로 조회 및 관리할 수 있어야 한다(M). B2-13. 관리자는 사용자가 반출예약한 기록물에 대한 통제를 할 수 있어야 한다. 또한 반출 불가 사유를 통보할 수 있어야 한다(M). B2-14. 대상 기록물에 대한 붙임자료의 유무정보 및 형태에 대한 정보를 제공할 수 있어야 한다(M).

B3. 평가 서비스

B3-1. 차세대 기록관리시스템 Preservation Service Layer와 API호출로 연계 가능해야 한다 (M). B3-2. 관리자의 권한은 기관 내 기록물 평가 담당자 또는 기록연구사에게 부여해야 하며, 사용자의 권한은 기관 내 처리과 담당자에게 부여해야 한다(O). B3-3. 차세대 기록관리시스템 Preservation Service Layer와 연계하여 처분일정이 도래한 기록물에 대한 목록을 조회할 수 있어야 한다(M). B3-4. 관리자 및 사용자는 처분일정이 도래한 기록물의 목록을 엑셀로 다운받을 수 있어야 한다(M). B3-5. 관리자는 임의로 수정한 목록을 서비스 내에 업로드, 수정, 다운로드 할 수 있어야 한다. 또한 차세대 기록관리시스템 Preservation Service Layer에서 제공받은 원 목록과 따로 관리할 수 있어야 한다(M). B3-6. 관리자는 서비스 내에서 처리과 서무 담당자(사용자)에게 목록을 제공하고, 의견을 회신 받을 수 있어야 한다(M). B3-7. 관리자 및 사용자는 대상 기록물과 대상 기록물에 대한 처리과 의견을 연계하여 볼 수 있어야 한다(M). B3-8. 대상 기록물에 대한 현재 상태(반출입 여부) 및 위치정보를 검색 할 수 있어야 한다 (M). B3-9. 관리자는 기록물평가심의서를 작성하고 처리과별, 사안별, 단위업무별 등의 여러 조건에 따라 관리할 수 있어야 한다(O). B3-10. 관리자는 기록물평가위원의 명단 및 참여일시, 참여여부 등의 정보를 저장하고, 관리할 수 있어야 한다(O).

281

B3-11. 관리자는 처분대상 기록물에 대한 실제 처분 절차의 워크플로우를 정의할 수 있어야 한다(M). B3-12. 기록물을 처분할 때 관련된 정보(폐기업체 정보, 폐기장소 등)를 이력으로 관리할 수 있어야 한다(M). B3-13. 실제 폐기시 집행담당자, 집행용역 등의 정보를 이력으로 관리할 수 있어야 한다 (M).

B4. 열람관리 서비스

B4-1. 차세대 기록관리시스템 Preservation Service Layer와 API호출로 연계 가능해야 한다 (M). B4-2. 관리자의 권한은 기관 내 열람관리 담당자 또는 기록연구사에게 부여해야 하며, 내부 사용자 권한은 기관 내 처리과 담당자에게 부여해야 한다. 또한 외부 사용자 권한은 기관 외 열람을 요청하는 사용자에게 권한을 부여해야 한다(M). B4-3. 차세대 기록관리시스템 Preservation Service Layer와 연계하여 기관 내 처분되지 않은 기록물에 대한 목록을 조회할 수 있어야 한다(M). B4-4. 해당 기관 내 서고에 위치해있는 기록물의 목록을 조회할 수 있어야 한다(M). B4-5. 기록물을 열람하고자 하는 사용자의 아래와 같은 정보를 관리할 수 있어야 한다(M). 사용자 아이디 사용자 이름 소속 처리과 열람 일시 열람 사유 B4-6. 모든 사용자는 대상 기록물에 대한 현재 상태(반출입 여부)를 검색 할 수 있어야 한다 (M). B4-7. 내부 사용자 및 외부 사용자는 대상 기록물에 대해 열람예약을 할 수 있어야 한다 (O). B4-8. 관리자는 기록물의 목록, 열람 이력의 목록을 엑셀의 형태로 제공받을 수 있어야 한다 (M). B4-9. 내부 사용자는 모든 검색결과에 대하여 엑셀의 형태로 제공받을 수 있어야 한다(M). B4-10. 내부 사용자 및 외부 사용자는 서비스 내에서 기록물 열람사유서를 등록 할 수 있어야 한다(M). B4-11. 관리자는 기록물 열람사유서에 대한 처리과별, 사용자별, 일자별로 조회 및 관리할 수 있어야 한다(M). B4-12. 관리자는 내부 사용자 및 외부 사용자가 열람예약한 기록물에 대한 통제를 할 수 있어야 한다. 또한 열람 불가 사유를 통보할 수 있어야 한다(M). B4-13. 대상 기록물에 대한 붙임자료의 유무정보 및 형태에 대한 정보를 제공할 수 있어야 한다(M). B4-14. 내부 사용자는 비공개 기록물도 검색이 가능해야 한다. 단, 외부 사용자는 비공개 기록물의 경우 검색되지 않아야 한다(M).

282

B5. 정수점검 서비스

B5-1. 차세대 기록관리시스템 Preservation Service Layer와 API호출로 연계 가능 해야 한다 (M). B5-2. 관리자의 권한은 기관 내 정수점검담당자와 기록연구사에게 부여해야 한다(M). B5-3. 차세대 기록관리시스템 Preservation Service Layer와 연계하여 해당 기관 내 서고에 위치해 있는 기록물의 목록을 조회할 수 있어야 한다(M). B5-4. 대상 기록물을 처분일정을 구분하여 목록을 관리할 수 있어야 한다(M). B5-5. 관리자는 서고내 비전자기록물에 대한 정수점검 일정 계획을 서고별, 처리과별 등의 임의 옵션을 통해 수립할 수 있어야 한다(O). B5-6. 정수점검 일자와 범위, 정수점검을 수행한 담당자의 정보를 관리할 수 있어야 한다 (M). B5-7. 기록물 정수점검에 필요한 RFID리더기, 바코드리더기 등의 디바이스와 연계할 수 있어야 한다(O). B5-8. 정수점검시 기록물의 보존상자, 상태 등을 기재할 수 있어야 한다(M). B5-9. 서고배치 오류에 의한 기록물 또는 누락 기록물에 대한 목록을 별도로 관리할 수 있어야 한다(M). B5-10. 정수점검 처리 결과를 실시간으로 차세대 기록관리시스템 Preservation Service Layer와 연계하여 반영할 수 있어야 한다(M).

B6. 지적재산권관리 서비스

B6-1. 차세대 기록관리시스템 Preservation Service Layer와 API호출로 연계 가능 해야 한다 (M). B6-2. 관리자의 권한은 기관 내 기록물 지적재산권 담당자 또는 기록연구사에게 부여해야 한다. 사용자의 권한은 처리과 담당자에게 부여해야 한다(M). B6-3. 기록물에 대한 저작권 정보를 등록할 수 있어야 한다. 또한 저작권의 수정이력사항을 관리할 수 있어야 한다(M). B6-4. 기록물에 대한 아래와 같은 저작권 형태를 관리할 수 있어야 한다(M). 창작 양도 취득 상속 B6-5. 기록물별 아래와 같은 권리의 Creative Commons License를 관리할 수 있어야 한다 (M). 저작자표시 비영리 변경금지 동일조건 변경 허락 B6-6. 기록물별 아래와 같은 조합의 Creative Commons License를 관리할 수 있어야 한다

283

(M). 저작자표시 저작자표시 + 비영리 저작자표시 + 비영리 + 변경금지 저작자표시 + 비영리 + 동일조건 변경 허락 저작자표시 + 변경금지 저작자표시 + 동일조건 변경 허락 B6-7. 사용자는 기록물의 저작권 정보, Creative Commons License를 검색 및 조회할 수 있어야 한다(M).

B7. 기록물이관 서비스

B7-1. 차세대 기록관리시스템 Preservation Service Layer와 API호출로 연계 가능해야 한다 (M). B7-2. 관리자의 권한은 기관 내 기록물 이관 담당자 또는 기록연구사에게 부여해야 하며, 사용자의 권한은 기관 내 처리과 담당자에게 부여해야 한다(M). B7-3. 관리자 및 사용자는 이관할 기록물의 목록을 엑셀의 형태로 업로드, 다운로드 할 수 있어야 한다(M). B7-4. 관리자는 사용자가 등록한 이관대상 기록물 목록을 확인하고, 목록에 대한 의견을 작성하여 다시 사용자에게 회신할 수 있어야 한다(M). B7-5. 관리자는 사용자가 등록한 이관대상 기록물 목록 중 전체보류 또는 부분보류를 할 수 있어야 한다(M). B7-6. 관리자는 사용자가 등록한 이관대상 기록물 목록 중 일괄이관 또는 부분적으로 이관 목록을 선별할 수 있어야 한다(M). B7-7. 관리자는 서고 내 비전자기록물에 대한 정수점검 일정 계획을 서고별, 처리과별 등의 임의 옵션을 통해 수립할 수 있어야 한다(M). B7-8. 관리자는 이관목록 대상 실물의 상태 정보를 작성하여 사용자에게 회신할 수 있어야 한다(M).

B8. 분류체계 서비스

B8-1. 차세대 기록관리시스템 Preservation Service Layer와 API호출로 연계 가능 해야 한다 (M). B8-2. 관리자의 권한은 기관 내 분류체계 담당자 또는 기록연구사에게 부여해야 하며, 사용자의 권한은 기관 내 처리과 담당자에게 부여해야 한다(M). B8-3. 관리자는 기관 내 수립된 분류체계를 등록, 수정, 삭제 할 수 있어야 한다(M). B8-4. 사용자는 분류체계 내 단위과제 신청 및 수정 등의 의견을 관리자에게 전달할 수 있어야 한다(M). B8-5. 관리자는 사용자의 의견을 접수하고 의견에 대한 처리결과를 사용자에게 회신할 수 있어야 한다(M). B8-6. 분류체계 등록, 수정 등의 변경사항 정보를 이력관리를 통하여 관리 할 수 있어야

284

한다(M). B8-7. 분류체계에 대한 처리과 의견, 의견처리결과, 의견기안자, 처리과명 등의 정보를 관리할 수 있어야 한다(M). B8-8. 관리자는 처리과 내 서무담당자 변경사항 등을 실시간으로 확인할 수 있어야 한다 (M). B8-9. 분류체계에 대한 수행주체, 수행절차, 근거유형, 협조부서, 근거상세내용 등에 대한 속성정보를 관리할 수 있어야 한다(M). B8-10. 관리자는 각 단위과제에 대한 관련법령, 자치법규, 관련규제 등의 유관정보를 관리할 수 있어야 한다(M).

B9. 공개재분류 서비스

B9-1. 차세대 기록관리시스템 Preservation Service Layer와 API호출로 연계 가능 해야 한다 (M). B9-2. 관리자의 권한은 기관 내 공개재분류 담당자 또는 기록연구사에게 부여해야 하며, 사용자의 권한은 기관 내 처리과 담당자에게 부여해야 한다(M). B9-3. 관리자는 기록물별 공개/비공개 여부를 처리과별, 제목, 생산년도, 종료년도, 기록물 유형별로 검색가능해야 한다(M). B9-4. 관리자는 서비스 내 공개재분류 대상의 목록을 선별하여 별도의 목록으로 제공받을 수 있어야 한다(M). B9-5. 관리자는 기록물 공개재분류 계획을 수립할 수 있어야 한다. 수립 계획 내에는 아래와 같은 정보가 포함하여야 한다(M). 공개재분류 수행주체 및 책임자 전체 기간 및 일정 원본 기록물 반출 여부 기록물 접근허가 여부 기록물 사본제작 여부 공개재분류심의회 구성 및 심의방법 B9-6. 개별 기록물의 공개/비공개 여부를 수정할 수 있어야 한다(M). B9-7. 비공개 대상정보의 내용을 업데이트 할 수 있어야 한다(M). B9-8. 관리자는 공개재분류에 대한 기준을 수립하여 사용자에게 배포할 수 있어야 한다 (M). B9-9. 공개재분류 기준서에는 아래와 같은 정보가 포함되어야 한다(M). 업무설명 및 소관부서 기록물 유형 관련 법규 및 판례 기존 공개 이력 재분류 검토의견 비공개 대상정보 B9-10. 기록물 유형별 검토서에는 아래와 같은 정보가 포함되어야 한다(M).

285

기록물 유형 생산부서 생산년도 검토결과 기록물 주요 내용 재분류 검토의견 B9-11. 공개재분류 심의회 일정 및 심의회 참여인원의 정보를 관리할 수 있어야 한다(O). B9-12. 공개재분류 결과를 차세대 기록관리시스템 Preservation Service Layer와 연계하여 반영할 수 있어야 한다(M).

B10. 조직관리 서비스

B10-1. 차세대 기록관리시스템 Preservation Service Layer와 API호출로 연계 가능해야 한다(M). B10-2. 관리자의 권한은 기관 내 조직관리 담당자 또는 기록연구사에게 부여해야 하며, 사용자의 권한은 기관 내 처리과 담당자에게 부여해야 한다(M). B10-3. 기관 내 행정조직에 대한 신설, 폐기 정보를 이력으로 관리해야 한다(M). B10-4. 현 기관 행정조직에 대한 정보를 실시간으로 반영해야 한다(M). B10-5. 조직 내 속해 있는 조직원에 대한 유형(정규직, 비정규직, 협력업체 직원 등)에 대한 정보를 관리해야 한다(M). B10-6. 사용자는 해당 처리과에 대한 조직 변경이력을 조회, 수정할 수 있으며, 이 수정사항은 이력으로 관리해야 한다(M). B10-7. 조직변천에 대한 내용을 한 눈에 볼 수 있는 시각화 리포팅을 제공해야 한다(M).

B11. 리드케이스관리 서비스

B11-1. 차세대 기록관리시스템 Preservation Service Layer와 API호출로 연계 가능해야 한다 (M). B11-2. 관리자의 권한은 기관 내 기록물 수집 담당자 또는 기록연구사에게 부여해야 하며, 사용자의 권한은 기관 내 처리과 담당자에게 부여해야 한다(M). B11-3. 수집 기록물은 아래와 같은 형태로 관리할 수 있어야 한다(M). 기증 구입 사본수집 구술채록 B11-4. 관리자는 기록물 수집 계획을 수립할 수 있어야 한다. 수립 계획 내에는 아래와 같은 정보를 포함하여야 한다(M). 소재정보 주요내용 수집필요성 B11-5. 수집자문위원회의 자문결과를 관리할 수 있어야 한다. 자문결과는 아래의 정보가

286

포함되어 있어야 한다(M). 수집계획의 적합성 수집범위의 주제선정의 타당성 특정 수집대상에 대한 가치평가 B11-6. 수집자문위원회 일정 및 자문위원, 감정평가위원의 정보를 관리할 수 있어야 한다 (M). B11-7. 관리자는 리드를 개발하여 수집 대상에 대한 리드 정보를 관리할 수 있어야 한다. 리드의 정보는 아래와 같은 내용이 포함되어 있어야 한다(M). 리드명 리드번호 소장자/소장처 소장자/소장처 소속 현재 소장자/소장처 연락처 주소 유형정보(개인, 단체) 리드상태(잠재적 소장자, 소장자, 기증예정자, 기증자, 기탁예정자, 기탁자, 위탁예정자, 위탁자, 매도 예정자, 매도자 등) 소장자/소장처의 약력과 수집 기록물과의 소장 히스토리, 관계 등 B11-8. 관리자 및 사용자는 리드를 개발하여 수집 대상에 대한 기록물 정보를 관리할 수 있어야 한다. 수집 기록물의 정보는 아래와 같은 내용이 포함되어 있어야 한다(M). - 수집기록물 생산자 기록물 유형 세부유형 기록물 규모/수량 수집기록물 상태 수집기록물 기록적 가치(유일본, 희귀본 등) 수집기록물 이미지 자료 B11-9. 관리자 및 사용자는 케이스맥락을 파악하기 위하여 수집 대상에 대한 리드접촉 정보를 관리할 수 있어야 한다. 리드접촉 정보는 아래와 같은 내용이 포함되어 있어야 한다(M). 접촉자 접촉일시 및 장소 접촉파일 최초작성일(작성자) 접촉파일 갱신일(갱신자) B11-10. 최종 리드정보를 차세대 기록관리시스템 Preservation Service Layer와 연계하여 반영할 수 있어야 한다(M)

B12. 지능형검색 서비스

287

B12-1. 차세대 기록관리시스템 Preservation Service Layer와 API호출로 연계 가능 해야 한다(M). B12-2. 기존 데이터 관계를 대상으로 지능형 검색이 가능하도록 온톨리지 모델링을 수행하고, 온톨리지에 적합한 인스턴스 생성 및 관리를 해야 한다(M). B12-3. Preservation Service Layer와 연동하여 UUID를 식별한 후 정보 자원간 연계를 통해 접근성을 개선해야 한다(M). B12-4. 사용자가 입력한 검색어, 페이지뷰, 유저플로우 등을 이력으로 남겨 관리할 수 있어야 한다(M). B12-5. 모든 사용자의 이력을 패턴화하여 관련된 검색어 및 관련 기록물을 추천해 줄 수 있어야 한다(O).

B13. 필수기록물관리 서비스

B13-1. 차세대 기록관리시스템 Preservation Service Layer와 API호출로 연계 가능해야 한다 (M). B13-2. 관리자의 권한은 기관 내 필수기록물 담당자 또는 기록연구사에게 부여해야 하며, 사용자의 권한은 기관 내 처리과 담당자에게 부여해야 한다(M). B13-3. Preservation Service Layer와 연동하여 필수기록물에 대한 위치 정보를 검색할 수 있어야 한다(M). B13-4. 필수기록물 목록을 엑셀형태로 다운로드하여 출력할 수 있어야 한다(M). B13-5. 필수기록물에 접근한 사용자 이력을 남겨 관리할 수 있어야 한다(M).

6. 차세대 중앙영구기록관리시스템 설계

6.1. 국가기록 클라우드 목표 모델 설계 방안

○ 차세대 전자기록관리 개념모델에서 도출된 통합형기록관리시스템(제3장 2.2 차세대 전자기록관리 재개념화 A2.3. 통합형기록관리시스템(Integrated System) 구축) 의 8가지 유형(Type1 ~ Type8)의 기록관리시스템을 구현하기 위한 클라우드 기반의 SaaS 플랫폼 시스템을 설계함

○ 중앙영구기록물관리시스템의 인프라를 차세대 클라우드 환경으로 전환하여 그 기반을 국가기록 클라우드 인프라로 활용 확산하는 방안을 제시함. 중앙영구기록관리시스템은 국가기록 클라우드 구축 전략 아래에서 설계되어야 하므로 국가기록 클라우드 시스템 설계를 선행함

가. 국가기록 클라우드 시스템 설계 전략

○ IT 자원 공유 최적화된 클라우드 기반 기록관리 공통 기반 제공함으로써 현행 기록관리 관련 시스템 구축 프로젝트 수행 시 다음의 문제를 해소하는 따라서 좀 더 효율적이고 유연한 업무 환경으로 변화 및 효율적인 배포방식을 필요로 함

288

중앙 배포 방식의 한계 : 시스템 유연성/확장성 부족

다양한 기록물 유형의 관리 어려움

OSS, 애자일 개발방법론, 마이크로서비스 아키텍처의 부상

<그림 291> 클라우드 기록관리 공통 기반 제공

○ 최신 기술 개방형 기술 표준 적용 및 보안성 강화

국가기록 클라우드 시스템을 구축/운영하기 위한 개방형 SW 기반의 서비스 환경 제공 필요

오픈소스 기반의 소프트웨어 및 기술 적용

<그림 292> 최신기술 및 개방형 기술 표준 적용

나. 국가기록 클라우드 클라우드 목표 모델

○ SaaS 플랫폼 기반 기록관리 서비스 장점

별다른 인프라 등을 설치할 필요 없이 어플리케이션 형태의 기록관리시스템 솔루션 제공 (SaaS)

289

Scale-out, 멀티테넌트, 프로비저닝 등의 플랫폼제공 및 상용 S/W, 시스템 S/W, 서버의 가상화

마이크로서비스, 설치비용 최소화, 손쉬운 커스터마이징 도구 및 모듈 제공으로 인한 기관맞춤 가능

Open Source 및 Open API를 이용한 커스텀화 제공 및 타 서비스와의 연동성 증대

<그림 293> SaaS 플랫폼 기반의 기록관리 서비스

○ SaaS 플랫폼 기능 구성

SaaS 플랫폼은 공통 기록관리 서비스를 관리하는 SaaS 관리영역과 기록관리 서비스 개발 및 실행 환경을 지원하는 PaaS 영역으로 구성됨

<그림 294> SaaS 관리영역 및 PaaS 영역

290

SaaS 관리 영역 및 PaaS 영역 기능 요건

SaaS 관리영역 PaaS 영역

· 통합사용자 관리서비스 정부기관의 다양한 사용자 정보의 동기화 처리 절차 · 통합인증 및 권한관리 · 어플리케이션 운영 기능 클라우드 내 서비스의 통합 인증, 계정 및 권한 어플리케이션 인스턴스 , 컨텐이터, Scale Out 관리 기능 등 어플리케이션 운영에 필요한 기본 관리 · 서비스 배포 기능 공통 업무 서비스를 신청, 배포, 실행할 수 있는 관리 절차 · 어플리케이션 개발 기능 · 서비스 카탈로그 어플리케이션 개발을 구성 및 지원하기 위한 메타정보를 기반으로 각 업무시스템 환경을 관리 기능 구성하는 기능 · Multi-Tenant · 인프라 제어 시스템 하나의 소프트웨어 및 자원을 여러 사용자가 IaaS 인프라 환경 구성 자동화 및 인터페이스 공유하는 기능 지원 기능 · 플랫폼 관리 SaaS 플랫폼을 유지하고 관리하는 기본 기능 · 실행 환경 관리 · 연계 게이트웨이 개발 프레임워크, WEB/WAS, DB 등 실행 SaaS 플랫폼과 연계 처리되는 모든 관리 정보 환경(서비스 팩) 에 필요한 관리 기능 관리 · 망 연계 망이 물리적으로 분리된 환경에서 자료 연계 기능 제공

<표 129> SaaS 관리영역 및 PaaS 영역 기능 요건

○ SaaS 플랫폼 > 기능 구성 방안

SaaS 플랫폼은 클라우드 공통서비스 환경에서 제공되는 기록관리 서비스의 서비스 환경 제공을 목적으로 하며, 통합사용자관리를 기반으로 하는 통합인증과 서비스 배포 및 관리 등 서비스 제공환경으로 구성되어 있음

291

SaaS 플랫폼 기능 설명

· 정부 디렉토리시스템의 조직/직원정보와 기관별 포탈의 통합사용자관리서비스 기반으로 한 통합인증 통합사용자관리 및 통합인증 서비스를 제공 · 디렉토리기능을 서비스화 하여 분산 효과를 가짐 · 통합인증(SSO)를 활용하여 외부 서비스 연계를 수행

· 서비스 구성을 위한 서비스 카탈로그 관리 및 제공 서비스 배포 및 관리 · 서비스 리포지토리 구성 및 관리 · 서비스 배포를 위한 인프라 환경 관리 기능과 연계

· 단일 시스템 자원을 다중 사용자/기관에게 서비스를 제공할 수 있는 multi-tenant 기능 제공 서비스 제공환경 구성 · 서비스를 위한 시스템 자원 구성 및 관리를 위해 IaaS 환경의 관리기능과 연계

· 기관 내부 포탈, 기관 기록물, 영상 자료 등 외부에서 생산되는 자료에 대한 서비스 연계 환경 제공 서비스 연계 환경 제공 · 연계 게이트웨이 및 통합인증(SSO)을 이용한 기록관리시스템 및 기관별 기록관리의 서비스 연계

· 어플리케이션 관리 및 서비스 환경 구성을 위한 자원 관리를 위한 솔루션 도입 자원 및 환경 관리를 위한 솔루션 · SaaS 플랫폼의 관리 기능과 솔루션 관리 기능의 연계 활용 · 공통 기능요건을 도출하여 솔루션 도입 또는 관련 기능 개발 시 기준 마련 필요

<표 130> SaaS 플랫폼 기능

○ SaaS 플랫폼 > 통합 사용자 관리 구성 방안

다양한 인증 수단에 대한 통합 인증 체계를 구성하고, 클라우드 외부 기관의 자체 인증 시스템과의 인증 연계를 위해 SAML 메시지 기반의 연계 표준을 구성함

또한 정부디렉토리를 원장으로 계정을 동기화하여 통합 계정 및 인증 정보를 구성

클라우드 내 서비스에 대한 접근 인가 및 서비스 사용 권한에 대해 계정 속성과 역할을 기반으로 관리

292

<그림 295> 통합 사용자 관리 구성 방안

○ SaaS 플랫폼 > 서비스 배포 구성 방안

클라우드 서비스 플랫폼의 서비스 배포 및 실행은 다음 절차를 따름

<그림 296> 서비스 배포 구성 방안

1) 부처/기관별 정보화담당관이 서비스 신청

2) 웹 데스크탑에서 서비스카달로그 항목 요청

293

3) 정보화담당관에게 서비스 카탈로그 항목을 기반으로 서비스 선택 요청

4) 요청된 카탈로그 정보를 서비스 리포지터리에서 취득

5) 선택된 서비스 카탈로그 내역을 서비스 배포기능에 전달

6) 서비스 배포기준에 따라 프로비저닝 준비

7) 서비스에 적합한 시스템 자원 및 AP 배포 요청

8) IaaS에 시스템 자원할당 요청 및 처리결과 수신

9) 할당된 시스템 자원에 AP 배포

10) 자원할당 및 AP 배포후 서비스 실행 요청

11) 서비스 실행 요청

○ SaaS 플랫폼 > 서비스 카탈로그 구성 방안

클라우드 서비스의 카탈로그는 메타정보를 기반으로 각 기록관리시스템을 담당하는 정보화 담당관이 서비스를 선택/조합하여 원하는 기록관리시스템의 환경을 구성할 수 있도록 제공하는 기능임

<그림 297> 서비스 카탈로그 구성방안

서비스 리포지토리에 있는 메타정보에 기반하여 구성된 서비스 카탈로그를 이용하여 정보화 담당관이 서비스를 선택 및 조합하는 기능

메타정보에는 서비스 이름, 필수 서비스여부, 서비스간 연관관계, 유사서비스간 그룹화 등의 정보가 포함됨

294

서비스 리포지토리 및 서비스 카탈로그는 클라우드 서비스 플랫폼 관리자가 관리함

서비스 카탈로그는 플랫폼 관리자가 운영정책을 반영하여 구성하며, 카탈로그의 제공 범위를 지정할 수 있음

○ SaaS 플랫폼 > 멀티테넌시 구축 모델

자원을 사용하는 구분에 따라 Multi-Tenant의 4가지 모델 구분하며 4단계 형식의 Multi-Tenant를 권장함

<그림 298> 멀티태넌시 구축모델

멀티태넌 시 설명 기능 내역 - 각각의 전용 어플리케이션을 각각 전용서버에 구축한 형태 조직별로 다른 1단계 인스턴스가 독립적 서버에서 운영되며 사용자별로 애플리케이션 코드도 별도로 관리된다 - 동일한 어플리케이션을 각 전용서버에 구축한 형태 사용자별 기능 2단계 커스터마이징 환경을 통해 이루어진다. 1단계보다 진화되었지만 여전이 관리 비용이 많이 소요 된다. - 동일한 어플리케이션을 모든 조직에서 공유해서 사용한다. 자원에 효율성은 3단계 좋지만 데이터 보안을 해결해야 하며, 중앙집중적 관리라 확장성이 떨어진다. - 3단계에서 확장이 가능한 분산 아키텍처 구조로 바꾼 모델이다. Tenant의 4단계 데이터를 분산 관리하며 재구성이 가능한 메타데이터로 각 Tenant별 커스터마이징을 지원

<표 131> 멀티태넌시 기능 내역

295

○ SaaS 플랫폼 > 연계 게이트웨이

서비스 연계 유형에 따라 데이터연계와 웹서비스 연계로 구분하며, 연계 서비스 대상에 따라 내/외부 연계로 구분할 수 있음. 각 연결 구간에 데이터 암호화를 적용하고, API 제공 서비스를 위해 PaaS 플랫폼에서 제공되는 API 게이트웨이를 이용함

<그림 299> 서비스 연계 구성도

○ PaaS 플랫폼 > 기능 구성 방안

PaaS 구성 방안은 서비스 자원 및 환경관리 영역은 다음 3가지 유형 형태로 정의함

PaaS 구성방안 설명

OpenShift Enterprise - RHEV 가상화 기반의 IaaS 플랫폼 기반

CloudFoundry - 가상화 기반의 IaaS 플랫폼 기반

OPEN PaaS [PaaS-TA] - OpenStack or RHEV IaaS 플랫폼 기반

<표 132> PaaS 구성방안

296

<그림 300> SaaS 플랫폼 및 PaaS 관계도

○ PaaS 플랫폼 > OpenShift Enterprise

OpenShift는 가상화 의존성 없이 구성가능 (RHEV, Xen, VMware, Hyper-v)

비용모델 : 서브스크립션 (Subscription)

다만 이 경우 IaaS 확장 기능(Auto-Scaling)에 대해서는 별도의 관리 시스템과의 연계 또는 기능 개발이 요구됨

<그림 301> OpenShift 적용 모델

297

○ PaaS 플랫폼 > CloundFoundry

국내 적용사례 없음

IaaS 영역을 PaaS에서 제어 가능 - 자동확장 (Auto-Scaling)

비용모델 : 라이선스 (License)

PaaS 영역에서 IaaS를 제어함으로 기존 클라우드영역에 구성 불가. (별도의 운영 풀 구성요구). 또한 가상화 플랫폼 Vmware / Open Stack 에 종속적. (RHEV 가상화 플랫폼에는 구성 불가)

<그림 302> CloudFoundry 적용 모델

○ PaaS 플랫폼 > Open PaaS [PaaS-TA]

NIA 에서 수행하고 있는 연구 과제 사업

전자정부 표준 프레임워크 기반의 Open PaaS[PaaS-TA] 개발

17년 02월 구축 완료후 서비스 확산 중

OPEN PaaS는 가상화 의존성 없이 구성가능 (RHEV, Xen, VMware, Hyper-v)

비용모델 : Community 버전

OpenStack을 통한 IaaS 플랫폼이 독립적으로 구축됨으로 기존의 클라우드 영역에 적용 불가. 또한 OpenStack 구축시 네트워크/스토리지/모니터링영역을 각각 독립적으로 구성 해야 함

298

<그림 303> Open PaaS 적용 모델

○ PaaS 플랫폼 > 종합

IaaS제어, 가상화 의존성, 비용모델, 운영사례등 4가지 측면에서 PaaS 플랫폼 구축 모델을 비교한 결과 기록관리 클라우드에 적합한 구축 모델은 Open PaaS를 기반으로 한 PaaS-TA 플랫폼을 적용함

서비스 자원 IaaS 가상화 비용 운영사례 비고 및 환경관리 제어 의존성 모델

별도의 관리 외부 - G-클라우드 IaaS 시스템과의 연계 OpenShift 기능 의존성 없음 구독 - 광주통전 또는 기능 개발이 Enterprise 연계 네트워크 요구 (예 Auto Scaling)

직접 VMware 라이선 국내 검증 사이트 CloudFoundry 국내 없음 제어 OpenStack 스 없음

직접 국내 연구과제로 제어 NIA개발 완료후, 시작하여 현재 OPEN PaaS 커뮤니 외부 의존성 없음 KOSCOM 등 서비스 기능 확장 [PaaS-TA] 티 기능 서비스 확산 중 계획으로 연계 연속성 보장

<표 133> PaaS 플랫폼 종합

299

○ PaaS 플랫폼 > Open PaaS [PaaS-TA] 플랫폼 개요

2014년 R&D 과제로 2017년 2월 개발 완료후 확산/구축 중 (사업명 : 전자정부 표준 프레임워크 기반의 Open PaaS 개발)

<그림 304> OpenPaaS 개요

<그림 305> OpenPaaS 단계별 계획 *KT G-Cloud 파스타 공공부문 대상 플랫폼 서비스 개시

SaaS 플랫폼의 PaaS 영역 기능과 OPEN PaaS[PaaS-TA] 기능들은 동일한 기능들이 존재 함. 따라서 기록관리 SaaS 플랫폼의 기능들은 Open PaaS[PaaS-TA] 기능들을 매핑하여 구현 가능함

300

<그림 306> Open PaaS를 활용한 SaaS 플랫폼 기능 구축

○ SaaS 플랫폼 > 세부 기능 정의

서비스 기능 세부기능 기능 설명 계정 접근 관리 사용자 계정별 접근제어기능 트래픽 제어 트래픽라우팅, QoS기능 Open API API Key 관리 각 개발자 어플리케이션을 위한 API Key관리 Gateway 클라우드 서비스 클라우드 서비스 연동 기능 연계 보안 API에 대한 인증 APP 동작 APP 시작/중지/재시작등 APP 관리기능 APP 등록 APP 메타데이터 및 이미지 등록 Open PaaS APP 실행 외부 요청에 대한 APP 서비스 APP 개발 APP 저장소 APP 메타데이터 및 이미지 통합 저장소

APP 패키징/배포 APP 빌드 및 패키징, 결과물 Deploy

APP APP 관리 APP 메타데이터 조회/수정 등 관리 메타데이터관리

APP 스케일업/다운 APP 컨텐이터 자원 확장 및 감소 처리 APP 확장 APP 스케일아웃/인 APP 인스턴스 수 확장 및 감소 처리

APP APP도메인 생성 및 저장, 관리 서비스라우팅관리 APP 서비스바인딩 APP 도메인 – APP 바인딩 및 언바인딩 Open PaaS APP 서비스 APP 서비스관리 APP 서비스라우팅 정보 업데이트, 라우팅 실행

APP 실행환경관리 APP 컨테이너 환경 구성 및 제어

301

서비스 기능 세부기능 기능 설명

공통서비스생성 새로운 공통서비스를 생성하는 개발 과정

공통서비스등록 생성된 공통서비스를 플랫폼에 등록

공통서비스 공통서비스설치 공통서비스를 플랫폼에 설치(분산 시스템 관리)

Open PaaS 공통서비스바인딩 공통서비스를 APP과 바인딩

공통서비스저장소 플랫폼 공통서비스의 통합 저장소

표준프레임워크 표준프레임워크 런타임 환경 구성 및 운영 공통서비스 언어(프레임워크) 팩(런타임) 필수 언어/프레임워크 런타임 환경 구성 및 운영 APP 확장 지원 WEB/WAS 핵심 Web/WAS 런타임 환경 구성 및 운영 데이터베이스 핵심 RDBMS서비스브로커 및 설치 프로그램

NoSQL DB 핵심 NoSQL DB 서비스브로커 및 설치 프로그램 공통서비스 팩 메세지큐 핵심 Message Queue서비스브로커 및 설치 프로그램 (제공형 API G/W API 포털 서비스브로커 및 설치 프로그램 대용량 저장소 대용량저장소(NAS) 서비스브로커 및 설치 프로그램

플랫폼도구 IDE 플러그인 통합개발환경의 PaaS지원 플러그인

Open PaaS 플랫폼템플릿생성/ 플랫폼 설치 템플릿의 제작 및 등록, 유지보수 관리 플랫폼설치 자동화 설치정합성 검증 설치 완료 후 자체 테스트 수행 환경별자동화실행모 IaaS 인프라 환경 구성 자동화 듈 G-클라우드플러그 G-클라우드인터페이스 모듈 인 IaaS플러그 인 OpenStack플러그인 OpenStack클라우드인터페이스 모듈 AWS 플러그인 AWS 클라우드인터페이스 모듈

IaaS연동 표준인터페이스관리 플랫폼 – IaaS간 표준 인터페이스 정의 및 관리

계정관리 플랫폼 사용자의 계정 관리

인증관리 접근계정에 대한 인증 처리 인증/권한관 권한관리 롤 기반 접근권한 제어 리 Open PaaS 보안정보처리 보안 데이터 암호화 저장, 복호화 서비스접근관리 테넌트/프로젝트 접근 제어 보안관리 인증정보 연동모듈 Auth2, LDAP인증처리 등

애플리케이션에 Tenant를 추가시 애플리케이션에서 Multi- 셀프 서비스 등록 일정 레벨의 셀프 서비스 등록하는 기능 Tenant

302

서비스 기능 세부기능 기능 설명 SaaS 애플리케이션은 테넌트당 사용자 수, 애플리케이션 등록 애플리케이션 옵션 및 사용 기간과 같은 요인을 등록 및 결재 및 결재 처리하는 기능 애플리케이션의 애플리케이션 등록이 늘어남에 따라 애플리케이션을 확장 및 관리 확장할 수 있는 기능

모니터링 애플리케이션과 모든 Tenant를 모니터하는 기능 Multi- Tenant 사용자가 어느 Tenant에 속하는지 판별 기능(특정 사용자 식별 테넌트에 속하는 사용자를 식별) 각 Tenant에게 적합한 기본적인 사용자 정의 레벨을 사용자 정의 지원하는 메커니즘을 제공 SaaS 애플리케이션에 SSO을 지원 기능(LDAP이나 인증 메커니즘 기타 디렉토리 서비스 ) 수집관리설정 미터링 정보 관리 항목 정의 및 수집 여부 관리 기능 수집정보 Open PaaS 정보 수집 관리 시간 설정 기능 기간(시간)설정 수집정보 보정 정책 수집된 정보의 값 보정을 위한 정책 정보 관리 정보관리 통계 Summary 측정된 데이터의 구분별 통합 데이터 관리 기능 처리 Tenant별 리소스 각 Tenant별로 리소스가 사용하는 현황 보고서 기능 미터링 사용량 현황 인스턴스 사용량 각 인스턴스별로 리소스가 사용하는 현황 보고서 현황 기능 서비스별 리소스 각 서비스별로 리소스가 사용하는 현황 보고서 기능 사용량 현황 일간, 주간, 월간 각 기간별(일간, 주간, 월간) 사용된 리소스 현황 사용량 보고서 기능 사용자 지정조건에 따른 사용량 사용자가 지정한 조건별 리소스 현황 보고서 기능 통계정보 연계 대상 관리 연계 요청 서비스 및 대상 서비스 정보 관리 연계 Endpoint 관리 연계 대상의 접속 지점 정보 연계 방식(데이터, 웹서비스, API)별 연계 처리 연계 방식 관리 연계 플로우 관리 게이트웨이 처리 상태 관리 메시지 송/수신 상태 및 요청 처리 결과 상태 관리 관리 로그 관리 연계 게이트웨이의 모든 이력이 담긴 로그 관리 통계 로그 기반 통계 기능 로그, 통계 및 실시간 서비스 상태 정보 기반 모니터링 연계 모니터링 게이트웨이 요청 메시지 수신 플랫폼 내/외부 연계 대상에 대한 요청 정보 수신 응답 수신 연계 요청에 대한 응답 수신 요청/응답 메시지 분석 기능 및 상태 정보에 대한 연계 처리 메시지 분석 응답(오류, 완료 등) 처리 응답 전달 요청 메시지 송신 서비스/시스템에 결과 메시지 전달 전송 구간 데이터 암호화 기능. 웹서비스의 경우 데이터 암호화 모듈 SSL등 WSS 적용 API 연계 API게이트웨이 OpenPaaS의 Open API Gateway 기능사용

<표 134> SaaS 플랫폼 세부 기능 정의

303

6.2. 중앙영구기록관리시스템 인프라 구축 방안

○ SaaS 플랫폼 기반의 차세대 통합형기록관리시스템(Integrated System)으로 이행하기 위해서는 먼저 국가기록원 자체의 인프라 자원을 가상화 통합하고 우선 IaaS 서비스를 제공하는 단계적으로 시행해야 함

가. 중앙영구기록관리시스템 시스템 설계 전략

○ IT 자원 공유 최적화된 클라우드형 아키텍처

<그림 307> 클라우드형 아키텍처 개요

가상화 기반 시스템 자원 풀을 만들어 사용자의 요청에 따라 즉시 제공하고 사용량 변동이나 요청에 따라 자원을 회수하거나 추가 할당하여 시스템 자원 활용률을 높이고 신규 인프라 자산 도입 비용, 전력비용, 그리고 상면 비용을 절감함

자원 할당과 회수가 용이한 표준 기반 가상 자원 풀 구축

분기별 자원 수요예측 기반 시스템 선 도입/구축

사용자 요청에 따라 필요 자원을 즉시 할당

사용 종료 또는 워크로드 변동에 따라 자원 회수 또는 추가 할당

자원의 동적 최적할당이 가능하여 자원 사용률 증대 및 신규

304

○ CAMS 클라우드형 아키텍처 기능 요건

CAMS 클라우드 기능 설계 설명

공유서비스 - 기관 업무에 자원 공유풀을 이용한 인프라 서비스를 제공

- 사용자는 웹 포탈을 통해 손쉽게 서비스를 요청 서비스 요청과 제공 - 요청 후 1일 이내에 서비스를 제공

- 사용자 포탈을 통해 서비스를 요청 하고 사용하는 시스템을 사용자 셀프 서비스 모니터링 하고 관리

- 표준 x86 서버를 기반으로 하는 가상화 자원 풀로 시작하여 인프라 서비스 제공 인프라 서비스(IaaS), 플랫폼 서비스 (PaaS)를 단계적으로 제공

- 초기에는 수작업으로 서비스를 제공하고 단계적으로 서비스 서비스 프로비저닝 및 관리 운영 관리를 자동화 (Auto Provisioning 등)

- WEB/WAS, DBMS 등 주요 SW를 공개 소프트웨어로 공개 SW 적용 점진적으로 전환함으로써 비용 절감

<표 135> CAMS 클라우드 기능 설계

○ CAMS 클라우드형 아키텍처 설계 원칙

국가기록원 차세대 CAMS 목표시스템 구축을 위한 차세대 인프라 설계 요건 정의를 통하여 4가지 설계 원칙을 도출하였음

설계 요건 정의

- 사용자 요구 또는 워크로드 변동에 따라 필요한 적정량의 자원할당 최적화로 비용 절감 자원을 할당 - 사용 중인 서비스에 영향 없이 자원을 추가 또는 일부 회수

- 사용자는 손쉽고 빠르게 서비스를 요청 민첩성 향상 - 요청 후 1일 이내 신규 할당/추가/회수 완료

- 자원 요청, 자원 할당/회수의 운영관리 효율을 극대화 하여 운영효율 향상 최소의 인력으로 운영

기관 기술표준 강화 - 기관 기술 표준 준수 및 지속적 강화 환경 제공

클라우드 서비스로 단계적 인프라 서비스(IaaS), 플랫폼 서비스(PaaS)로 단계적 발전 발전 기존 시스템 & 아키텍처에 큰 영향 없이 기능 확장, 발전

<표 136> CAMS 클라우드 설계 요건

305

정의된 설계 요건을 바탕으로 다음과 같이 4가지 설계 원칙을 도출함

설계 원칙 설명

- 자원 가상화 (VM, 파티셔닝), Thin Provisioning 동적 자원 할당 아키텍처 - 동적 자원 할당/추가/회수, VM 이동 - 수동/자동 프로비저닝 (워크플로우 기반 동적 최적화) - 자원 풀과 운영관리 시스템 분리 모듈 기반 아키텍처 (Modular - 운영관리 시스템은 기능 레퍼런스 모델 기반으로 설계하여 Architecture) 단계적 기능 확장, 고도화 - 자원 풀은 표준 랙 단위로 수평 확장

- 자원 풀은 모두 표준(기관 기술표준) 인프라로 구성 기술 표준 기반 시스템 구성 - 클라우드 운영관리 시스템도 표준 인프라/기술로 구성

서비스 & 프로세스 표준화, - 기술 표준을 준수하는 표준 서비스 제공 자동화 - 운영관리 프로세스 표준화. 단계적 자동화 & 셀프 서비스화

<표 137> CAMS 클라우드 설계 원칙

○ CAMS 클라우드 단계별 추진 방안

기 구축한 시스템에 변경이나 영향 없이 클라우드 서비스로 발전시킬 수 있도록 점진적 아키텍처 확장으로 단계별 구축을 추진 함

<그림 308> CAMS 인프라 단계별 발전 방향

306

○ 1단계(단기) CAMS 인프라 가상화 자원풀 구성 예상 비용

단위 : 백만원

구분 대전내부망 대전외부망 성남기록관 총합

서버통합 1,789 1,074 307 3,170

스토리지 3,520 1,020 820 5,360 통합

합계 5,309 2,094 1,127 8,530

<표 138> CAMS 인프라 가상화 자원풀 구성 예상 비용 (공개SW 전환 중 DB 마이그레이션 비용 제외)

나. 클라우드 서비스 역량확보

○ 클라우드 서비스를 제공하고 관리하기 위한 역량을 강화하기 위하여 요구되는 지식과 기술을 정의하고, 역량확보를 위한 방안을 수립해야 함. Cloud 역량 모델은 서비스 제공을 위한 전문적인 역량과 서비스 전반에 걸쳐 관리 및 운영을 수행하는 역량으로 구성되며, 각 영역별로 유사한 성격의 역량을 그룹으로 묶어 역량군(역량 Cluster)을 정의함

<그림 309> 국가기록원 클라우드 역량 모델

307

역량 역량군 정의 관련 역량 구분 사업모델 기획 기관이 필요로 하는 Cloud 서비스를 발굴하여 서비스 기획 서비스 기획 적용 가능한 서비스 모델을 기획하거나 전환 기술 컨설팅 계획을 기획하는 역량군 Migration 관리 서비스 기획에서 수립된 서비스 모델을 서비스 카탈로그 설계 서비스 고객에게 제공하기 위해구체적인 Cloud 서비스 아키텍처 모델링 서비스 설계 관리 역량 구조를 설계하고 Cloud 서비스를 구축을 미터링/빌링 설계 관리하는 역량군 Cloud 구축

Cloud 관리 시스템 운영 기관이 Cloud 서비스를 신청하고 사용 및 비용 서비스 운영 Cloud 고객 관리 정산을 위해 필요한 관리를 수행하는 역량군 Event 관리

서버 가상화 관리 Cloud Server 서비스 제공을 위해가상서버, 서버 관리 Cloud Server 시스템 SW 및 DC 기반설비에 대한 설계, 구현 시스템 SW 관리 및 관리를 수행하는 전문 기술적인 역량군 DC 기반 설비 관리

Cloud Storage 서비스 제공을 위해스토리지에 Cloud 대한 설계, 구현 및 관리를 수행하는 전문 스토리지 관리 Storage 기술적인 역량군 서비스 제공 역량 Cloud DR 서비스 제공을 위해 DR 구축과 DR 관리 Cloud DR Back up 구현에 대한 설계, 구현 및 관리를 Back up 관리 수행하는 전문 기술적인 역량군

Cloud Network 서비스 제공을 위해 Network NW 장비 관리 Cloud 및 보안 관리에 대한 설계, 구현 및 관리를 NW 가상화 관리 Network 수행하는 전문 기술적인 역량군 보안 관리

<표 139> 역량군 정의

○ 역량 확보방안

각 영역별 현재 역량 수준 진단을 통해 기술 확보 여부 정도와 외부 지원가능 정도를 파악하여, 역량 확보를 위한 실행방안 유형을 분류하고 분류된 유형에 따른 실행계획 수립이 필요함

클라우드 자원과 서비스 운영을 위해서 본 연구 「제1세부과제 차세대 전자기록관리의 개념설계와 정보거버넌스형 기능∙조직∙법제 구축 방안」의 3.3.5. 기술지원센터에서 제안하는 중앙기술지원센터와 같은 형태의 기술지원 조직이 전제되어야 함

308

방안 추진 과제 추진 내용 관련 역량 구분 -Cloud 자동화를 위한 workflow 정의 및 구현 NW관리/보안관 Cloud Workflow -Cloud 서비스 운영을 위해 개선해야 되는 기술적 리 자동화 TFT 개선 활동 이행 TFT 시스템 SW 관리 자체역량 -Cloud 서비스 운영을 위해 개선해야 되는 운영적 강화 Cloud 서비스 이벤트 관리 개선 활동 정의 및 이행 TFT 운영 체계 개선 보안관리 -운영 및 개선을 위해 필요한 표준, 절차 및 지침서 TFT 기반설비 관리 정의 서비스 기획 및 -서비스 모델을 기획하고 기술 모델을 수립하는 사업모델 기획 기술 컨설팅 인력 기획 전문 인력 확보 서비스 기획 확보 -기술 컨설팅을 위한 컨설턴트 확보 기술컨설팅 Cloud 고객 인력확보 관리/카탈로그 서비스 관리 인력 -Cloud 서비스 관리를 위한 서비스 품질 관리 및 설계 확보 과금 관련 전문 인력 확보 미터링/빌링 설계 -Open Source SW 적용 대상 선정하고 적용 방안을 Open Source 도출하는 컨설팅 추진 SW 시스템 SW 관리 -적용대상 선정 방법, 적용 공수 산정 방안, Risk 컨설팅 기술 컨설팅 식별 방안에 대한 지식 확보 추진 -DR 설계, 구축 및 운영에 대한 컨설팅 추진 Cloud DR 구축을 -DR 환경 구성 표준 지침, Assessment 방법론, DR DR 관리 위한 설계 컨설팅 구축에 대한 지식 확보 -Cloud Infra 서비스를 위한 Infra 환경 구축 Cloud 구축 Cloud Infra -Cloud 서비스 구축 프로젝트 know-how, 서버 및 서버관리 서비스 구축 Backup 장비 운영에 대한 기술 이전 Backup 관리 프로젝트 -Cloud Infra 서비스를 관리하기 위한 Cloud Cloud 수행 관리시스템 구축 관리시스템 운영 Cloud -Cloud 서비스 제공을 위한 서버/NW/스토리지 서버/NW 관리시스템 구축 가상화 및 자동화 관리 솔루션의 사용 능력및 Cloud 가상화 관리 포탈 개발/운영 기술 이전 스토리지 관리 <표 140> 클라우드 역량 확보를 위한 방안

다. 중앙기록관리시스템 자원 통합 방안

○ 가상화 자원 풀을 구성하기 위한 CAMS 클라우드 서버 자원 통합 방안

국가기록원 146대를 대상으로 전환 대상 서버 136대 식별

전환 대상 서버 136대 응용시스템 분석

서버 자원 가상화 통합 설계 방안

· 가상화 통합 전환 후 총 14대의 통합 서버 및 총 105.4 TB(Usable) 용량의 3대의 스토리지로 통합

309

서버 자원 가상화 통합 설계 기준은 다음과 같다

· 내부망/외부망 서버는 분리 통합을 원칙으로 함 · UNIX 서버는 Linux 서버로 U2L (Uinx2Linux 마이그레이션) 통합

· x86 서버는 Windows/Linux 구분 없이 표준 통합 x86 서버로 가상화 통합

· 운영 서버와 일반 개발 서버는 클러스터 분리

· DB 서버는 다른 서버와 클러스터 분리 구성 원칙

· OS 및 SW를 설치하기 위한 관리(프로비저닝) 서버는 별도로 분리하고

· 대전 내/외부망및 성남에 각각 1대씩 설치함(총3대의 x86서버- vCenter)

· HA 서버는 N + 1로 구성함 (N은 클러스터 그룹 통합)

서버 자원 가상화 통합 사이징

· 국가기록원 현재 서버 장비 분석을 통하여 TO-BE 서버 통합 필요 수량 및 디스크 용량을 산출함

○ CAMS 클라우드 스토리지 자원 통합

국가기록원 34대를 대상으로 전환 대상 스토리지 33대를 다음과 같이 식별함

전환 대상 스토리지 33대 응용시스템 분석

스토리지 자원 가상화 통합 설계 방안

스토리지 자원 가상화 통합 시 다음의 설계 기준 적용

- 내부망/외부망 스토리지는 분리 통합을 원칙으로 함 - 용량은 최적의 처리 능력을 보장하기 위해 통합 장비 최대치의 60%를 넘지 않도록 함 - 서비스 등급에 따라 Raid 구성 실 데이터 볼륨 : Raid 1 구성 내부복제 볼륨 : Raid 5(3D+1P) 구성 - 초당 IO 처리 능력은 Random Performance disk기준으로 200,000(공인기관 기준)이상의 장비를 선정

<표 141> 스토리지 자원 가상화 통합 설계 기준

○ CAMS 인프라 가상화 통합 예산

서버 예산

소프트웨어 예산

데이터 스토리지 예산

○ 중앙기록관리시스템(CAMS) 자원 통합 및 시스템 설계 상세 내용은 「첨부 중앙기록관리 시스템 인프라 설계 방안」 참조

310

6.3. 클라우드 환경 보안 구축 방안

가. 개요

○ 클라우드 보안

클라우드 컴퓨팅의 보안은 크게 기술적 보안과 운영적 보안으로 분류함. 주로 서비스 제공자와 관련된 기술적인 보안에는 인프라, 데이터, 스토리지, 통신이나 어플리케이션에 관련된 보안으로 구성됨. 반면 운영적 보안은 서비스 제공자와 이용자 모두와 관련된 보안으로 서비스 정책 수립이나 조직의 운영 방안, 자산 통제, 사고 관리, 서비스 연속성과 같은 요소들이 포함되어 있음. 이러한 클라우드 컴퓨팅의 보안과 관련하여 CSA(Cloud Service Alliance)에서는 2010년 3월 클라우드 컴퓨팅의 위협을 정리한 보고서 “Top Threats to Cloud Computing V1.0"을 발표함. 클라우드 서비스 핵심 보안 위협요소를 정리해보면 다음 [표 1]과 같다.[11] 안전한 클라우드 서비스 환경의 시스템 구축 및 운영을 위한 기술적 보안 요소를 도출 및 방안을 제시함

보안위협 위협내용

Ÿ 악성코드 감염 및 확산위협 가상화 취약점 상속 Ÿ 서비스 가용성 침해

정보위탁에 따른 정보 유출의 Ÿ 소유와 관리 분리에 따른 정보유출 위협 Ÿ 내부자에 의한 정보유출

사용 단말의 다양성과 분실에 Ÿ 단말기 분실 등에 의한 정보유출 따른 정보유출

자원 공유 및 집중화에 따른 Ÿ 시스템 장애 시 모든 고객의 서비스 중단 서비스 장애 Ÿ 중앙시스템 노출 시 DDoS등의 공격대상이 되기 쉬움

분산 처리에 따른 보안적용의 Ÿ 자원공유와 가상머신 동적 재배치로 인증/접근제어 복잡도 상승 어려움 Ÿ 분산 컴퓨팅 시스템에 일괄적인 인증/접근제어 적용의 어려움

Ÿ 정보유출시 책임소재 불분명 법규 및 규제의 문제 Ÿ 자원공유에 따라 감사증적이 어려움

<표 142> 클라우드 서비스의 보안 위협

○ 클라우드 보안요소

클라우드의 물리적인 구성으로는 Sever, Strogage, Network로 나누고 가상화 구성으로는 서버 가상화 하이퍼바이저(Sever Virtualization Hypervisor)와 저장소 가상화(Storage Virtualization)와 네트워크 가상화(Network Virtualization), 서버 관리(Service Management), 자원관리(Resource Management), (Provisioning), 모니터링(Monitoring) 으로 나눔. 클라우드 서비스 구성은 소프트웨어나 어플리케이션을 제공해주는 SaaS(Software as a Service), 어플리케이션 제작에 필요한 개발환경, SDK 등 플랫폼을 제공하는 PaaS(Platform as a Service), 서버, 스토리지, 네트워크, CPU, 메모리 등 각종

311

컴퓨팅 인프라 장비를 제공하는 IaaS(Infrastructure as a Service)로 나눔

클라우드 서버 가상화 하이퍼바이저는 소프트웨어로 물리 서버의 CPU와 디스크에 직접 상호작용을 하며, 가상서버의 운영체제를 위한 플랫폼 역할을 함. 각각의 가상 서버들을 완전히 독립적으로 운용하고 게스트 서버는 자체 OS에서 운영되기 때문에 리눅스 기반 게스트와 윈도우 기반 게스트를 동시 운영할 수도 있음. 하이퍼 바이저는 물리 서버의 자원을 모니터링하여, 가상 서버에서 어플리케이션이 구동 될 때, 물리 서버의 자원을 적 절한 가상 서버에 할당하여 줌

스토리지 가상화는 스토리지 시스템과 서버사이에 소프트웨어 또는 하드웨어 계층을 추가함으로써, 어플리케이션 구동 시 데이터를 찾기 위해 특정 드라이브, 파티션, 또는 스토리지 하위 시스템을 인식하지 않아도 되므로, 가용성과 부분 중단(interruption)에도 안전함. 또한 스토리지 용량의 자동 확장, 수동 프로비저닝의 수고를 덜어주고, 구동 중에도 어플리케이션 성능에 영향을 주지 않으면서 스토리지 자원의 업데이트가 가능함

네트워크 가상화란 기존 네트워크에 논리적인 구역을 만드는 것으로 네트워크에 있는 두 도메인을 물리적으로 연결하지 않고 터널을 만들어 두 도메인을 서로 연결하는 것으로서, 기존 물리적인 네트워크에 오버레이를 구축, 그 위에 새로운 네트워크를 구성함. 사용자가 특정 터널을 활성화 가능하게 하며 프로비저닝 기능을 제공함. 네트워크 가상화에는 호스트, 링크, 라우터, 스위치 가상화로 나눔. 클라우드 보안요소는 시스템 보안, 네트워크 보안, 데이터 보안, 어플리케이션 보안, 가상화 보안으로 구분함

<그림 310> 클라우드 보안 요소

312

○ 클라우드 요소 방안

구분 보안요소 방안

네트워크를 통해 물리서버 및 가상서버 접속 접근 제어 통제 방안으로 접근 제어 및 운영에 대한 사항을 수립한다. 시스템 보안 계정관리 대상의 물리서버 및 가상서버를 계정 관리 식별하고 접속하는 사용자들의 계정관리 방안을 수립한다. 네트워크 보안 장비의 구성 방안을 수립한다. 네트워크 보안 인프라 보안 네트워크 보안 관련 웹 구간 대상을 식별하고 구간 암호화 방안을 수립한다. DBMS 관리 및 계정관리 방안을 수립하고, 데이터 보안 DB 보안 보호대상 저장 데이터의 암호화 방안을 수립한다 웹 어플리케이션 구현 시 웹 취약점 점검 웹 취약점 방안을 수립한다. 어플리케이션 구현 시 시큐어코딩 방안을 어플리케이션 보안 시큐어 코딩 수립한다. 시스템 구축 시 개인정보 영향평가를 위한 기준 개인정보영향 평가 수립 가상화 구성환경을 안정적으로 운영하기 위한 가상화 보안 모니터링 모니터링 방안을 제시한다.

<표 143> 클라우드 요소 방안

나. 시스템 보안

○ 클라우드 서비스에서는 불특정 다수의 이용자가 가상화 기술로 구현된 IT 인프라를 통해 IT자원의 공유기능을 제공함

서비스 제공자는 가상화 기술 안에서 IT자원을 통합·재배치하여 활용성을 극대화하기 때문에 운영비용 절감 및 공간 절약의 효과를 기대할 수 있음

반면, 악성코드의 신속한 전파로 인한 감염 확산이나 하이퍼바이저에 대한 공격 등 새로운 보안 위협이 존재함. 특히, 가상화 시스템 장애 발생 시 신속한 시스템 복구를 위해 가상머신의 구동 이력을 이미지 형태로 저장·관리하기에 이미지 저장에 오류가 생길 경우, 전체 시스템의 완전한 복구가 어려울 수도 있음. 이용자의 서비스 가용성·지속성을 보장하기 위해서는 서비스를 이용하면서 생성된 이용자 데이터를 안전하게 저장·관리해야 함

○ 따라서 이용자의 데이터가 손실되거나 위·변조되어 서비스 이용을 제한받지 않도록 무결성을 보장해야 함. 또한, 시스템 자원을 통합·재분배하기 위해 구현된 가상화 시스템으로 악성

313

코드 감염이 확산되거나 물리자원에 동적으로 재배치되는 과정에서 발생할 수 있는 데이터의 손실 등에 대해 대책을 마련해야 함. 서비스 제공자는 기본적으로 시스템 백신 패치를 통한 주기적인 점검, 데이터 무결성 확보 대책 등 다음과 같은 정보보호 고려사항을 기반으로 시스템 보안을 강화함

구분 고려사항

· 시스템 유효성 점검을 위한 백신패치는 최신 버전으로 관리하고 주기적 실행 · 이용자 데이터의 무결성 보장을 위한 데이터 오류검사, 해시함수, 데이터 유효성 기본적 검사 등을 적용 시스템 · 사용되는 소프트웨어 및 데이터의 무결성을 주기적으로 점검하고, 필요에 따라 보안 소프트웨어 등의 사용을 재설계 · 악용 가능한 잠재적 시스템 취약점 정보는 밝히지 않고 관련 취약점의 접근이 발생 할 경우, 오류메시지 생성 등을 통해 관리

· 가상화 백신을 주기적으로 갱신하고 악성코드 확산 방지 대책을 마련 · 가상머신별 자원 사용량 제한하여 특정 가상머신의 자원이 남용되지 않도록 한다. 가상화 · 디스크를 분할하여 호스트와 가상영역 간의 경계를 명확하게 한다. 시스템 · 가상화 OS에 백신을 탑재하여 관리 보안 · Host OS 및 하이퍼바이저를 모니터링하고 이력관리 · 가상화 실행 이력은 스탭샷 등 이미지 형태로 저장·관리하는 방안을 고려하고 안전한 저장방법을 통해 관리 · 가상화 OS의 내·외부 데이터 이용에 대한 로그 정보를 관리

<표 144> 시스템 보안

○ 클라우드 서비스 이용자의 IT 자원공유, 다양한 무선 단말기의 원격 접속 등이 보편화됨에 따라 기존IT 서비스 환경보다 보안성이 강화된 사용자 인증 및 접근 관리가 필요함

서비스 제공자는 IT 자원에 접근이 허가된 이용자만이 서비스에 접속할 수 있도록 보장해야 함. 따라서 서비스 이용자의 제한된 영역에 대한 접근 시도와 같은 부적절한 행위에 대한 보안관제 방안 수립 필요

클라우드 서비스는 사용자의 자원에 대한 인증 및 접근 관리를 사용자 계정과 부여된 역할에 따라 접근 가능하도록 관리·감독함. 또한 어플리케이션과 시스템에 대한 사용자의 접근 권한에 따른 적절한 통제를 수행. 이에, 서비스를 이용하는 단말기의 원격 접속 제한, 계정의 책임 분할 및 권한 최소화 등의 적절한 대책 필요하므로, 서비스 및 데이터 접근 인증 및 시스템 접근보안에 대한 보안 대책을 수립함

314

구분 고려사항

· 서비스 연결을 승인하기 전에 모든 단말의 무선 접속은 정책에서 규정된 절차에 따라 인증하고, 접속로그를 관리하며 모니터링을 해야 한다. 원격접속 · 무선접속을 인증과 통신 세션의 기밀성·무결성을 보장하기 위해 암호 기술을 관리 및 제한 적용해야한다. · 내부정책에서 제한하는 모바일 단말의 통제 대책 마련 · 서로 다른 이용자 계정의 충돌을 최소화하기 위하여 접근을 허용하는 영역이나 권한 등을 분리해야 한다. · 이용자의 신분 및 지불 방식을 기술적으로 검증하는 방안을 적용해야 한다. · 사용자에 부여하는 역할·권한을 최소한의 범위로 제한해야 한다. 계정 분할 및 · 내부정책에서 규정한 계정관리 주기에 따라 점검하고, 시스템 이용자 권한 최소화 변경사항은 즉시 정책에 반영해야한다. · 이용자의 잘못된 로그인 시도가 규정된 횟수만큼 발생할 경우, 로그인을 제한한다. · 이용자 로그인이 성공적으로 수행되었을 경우, 지난 로그인 일시 및 관련 정보 공지를 고려해야한다. · 서비스상의 최대 세션 수, 계정 지역, 유형 등을 고려하여 세션을 정의하여 사용자 관리 세션 관리 · 하나의 사용자가 동시에 여러 세션을 소유하는 것을 제한한다. · 내부정책에서 규정한 활성화 허용 시간을

<표 145> 접근보안

○ 서비스 및 데이터 접근 인증

<그림 311> 서비스 및 데이터 접근 인증

315

○ 서비스 및 데이터 접근 인증 방안

구분 인증 영역 내용 및 대책

GPKI, GOTP 등 인증관련 정보가 계정 및 권한관리에 1 권한관리체계 연계되도록 구현 구간 암호화 영역에서 웹서비스의 신뢰성 확보와 암호화 통신을 2 구간 암호화 위한 SSL 적용 서비스 및 데이터 기존 온-나라 시스템과 동일한 사용자 인증 방식으로 인증서 3 접근 기반 및 일반계정 인증방식 제공

클라우드 통합사용자 관리 DB내 권한 DB로 권한 관리를 하며 클라우드 4 공통기반을 활용한 내의 서비스는 해당 권한 DB를 조회하여 사용자의 업무 권한을 사용자 인증 통제함(SSO)

온-나라 시스템 5 온-나라 시스템 내 자체 접근권한 관리에 따른 접근권한 통제 자체 접근권한

연계대상 업무관리 시스템과 연계 시스템간의 상호 연계 시 GPKI 서버 6 접근통제 인증서로 적용

<표 146> 서비스 및 데이터 접근 인증 방안

○ 시스템 접근보안 – 접근관리 정책 및 사용자 계정 분류

구성 내용 보안 방법

시스템 서버의 모든 권한을 가지며 1개만 담당자만 접근이 가능하도록 관리 관리자 존재 System 각 Application의 관리자로 권한을 Application 권한을 부여 받은 인원만 접근 가능 부여 받음 관리자 Application Application 개발을 위해 부여하고 Application 특성에 따른 차등적인 개발자 개발 종료 시 폐기 권한관리 및 접근제어 Application Application 운영을 위해 부여함 Application 특성에 따른 권한 제어 운영자 내부 사용자의 역할 및 권한에 따라 사용자의 목적에 따른 자원 허용 사용자 부여 일반 사용자로서 인가된 서버 일반 사용자 자원을 사용 외부기관 극히 한정된 서버자원의 사용 허가 인증 및 권한 관리를 통한 보안성 확보 사용자

<표 147> 시스템 접근보안

316

다. 네트워크 보안

○ 네트워크 정보보호 고려사항 : 클라우드 서비스에서는 서비스 이용자의 모든 정보와 이용자가 임대한 IT 자원이 인터넷 환경을 통해 제공되므로 보안이 강화된 네트워크 구축이 요구됨. 특히, 서비스 제공자는 지리적으로 분리된 다수의 데이터 처리 서버의 운영에 따른 안전한 데이터 송. 수신을 위한 통신 암호화를 적용하고, 네트워크 서비스 거부공격(DoS) 등에 대한 대응 방안을 마련해야 한다. 또한, 공공용 클라우드 서비스와 사설용 클라우드 서비스는 네트워크 구성에 따라 상이한 보안위협을 갖기 때문에 서비스 환경에 따라 적절한 대응 방안이 필요하다. 따라서 네트워크 보안강화를 위해 정보보호 고려사항은 다음과 같음

네트워크 트래픽 도청이나 데이터 유출 방지를 위해 통신 암호화

사용자의 네트워크 접속. 인증을 위한 신분확인 메커니즘 도입

네트워크 접속을 통한 데이터 송. 수신에 대한 부인방지 대책 마련

네트워크 가용성이 침해하는 서비스거부공격(DoS)에 대한 대책 마련

이기종 네트워크의 연동에 따른 보안

네트워크 장애에 대비하여 네트워크 분할 또는 이중화

네트워크 장애에 대비하여 보안관제 체계 구축 ○ 네트워크 보안 방안 : 접근제어 및 접근권한은 공유·협업 환경에 적합하도록 사람, 서비스, 데이터 요소를 고려하여 기준 정책 수립이 필요하며 이를 토대로 접근통제(NAC)의 네트워크 보안 기술 요소를 접목하여 기술요소 반영 방안 마련한다. 인증 영역에서 도출된 통합 인증 플랫폼 구축 시 접근제어, 접근권한에 대한 정책요소를 반영할 수 있도록 고려하여 정책 수립 필요하다. 접근통제와 같은 기술적 요소는 클라우드 환경에 적합한 기술과 솔루션에 대한 다각적인 검토 후 기술 요소 반영 방안 마련하고 서비스별 인증을 포함한 접근제어 및 접근 권한 등 보안 기술 요소에 따른 전자정부 클라우드 통합 접근권한 관리시스템 구축함

기술요소 방안 · 인증 환경 변화에 따른 접근권한 체계 수립 · 접근제어의 원칙 수립시 클라우드 환경을 고려한 요소 결정 접근제어 · 신분기반 정책, 직무기반 정책, 규칙기반 정책을 포괄하는 접근제어 정책 수립 · 서비스 , 사용자, 데이터 관점으로 분석 · 데이터의 경우 문서, 파일, 폴더 로 세분화 하여 정책 수립 · 문서의 경우 문서등급의 재검토 또는 수립 접근권한체계 · 사용자의 경우 Action에 대한 체계화 및 경우의 수를 수렵하여 확장성 있도록 시스템 및 정책 설계 · 서비스의 경우 저장소와 관련된 환경을 고려한 설계 · 기존 접근 통제 방식 및 접근 통제의 구간 정의 · 각 구간별 기술요소 검토 및 파악 접근통제(NAC) · 기술요소 검토에 따른 관련 솔루션 및 통제 기술의 클라우드 환경 적합성 파악

<표 148> 접근권한 관리시스템

317

라. 데이터 보안

○ 이용자의 안정적 서비스 접속, 이용을 보장하기 위해 서비스 이용에 따라 생성된 이용자 데이터를 안전하게 저장 관리 한다. 이용자 데이터는 데이터의 기밀수준에 따라 암호화하 여 안전하게 전송한 후 저장 관리하며 주기적으로 백업한다. 기밀 정도가 높은 중요 데이 터는 암호화할 뿐만 아니라, 클라우드 서버를 통과하지 못하도록 쿼리문을 활용하거나 관련 클라우드 서버의 접근 로그 기록 등을 자동화함. 데이터베이스의 접근제어 및 암호화를 통한 보안 대책을 수립함

○ DBMS 보안 적용 흐름도

<그림 312> DBMS 보안 적용 흐름도

○ DBMS 보안 적용 방안

구분 방안

계정관리 DBA 권한은 일반 사용자 사용금지

사용자가 DB 접속 시 DBA 통제 접근통제 클라이언트 IP 및 포트 접근 제한 적용

개인정보 데이터의 암호화 유틸리티를 이용한 암호화를 적용하여 개인정보 암호화 정보유출 방지

취약점 패치 DBMS 보안패치 적용하여 취약점 적용

<표 149> DBMS 보안 적용 방안

○ Data 암호화 방안

대칭키 또는 비대칭키를 이용해서 암·복호화를 수행해야 하는 경우 한국인터넷진흥원의 『암 호이용안내서』에서 정의하고 있는 암호화 알고리즘과 안전성이 보장되는 암호키 길이를 사용함

복호화 되지 않는 암호화를 수행하기 위해 해시함수를 사용하는 경우 안전한 해시 알고리즘과 솔트값을 적용하여 암호화해야 함

318

암호화 알고리즘 설명

개인정보에 대해 패스워드와 같이 암호화 후 복호화 하지 단방향 SHA-256 않아도 되는 데이터에 적용

개인정보에 대해 암호화하여 저장되며 복호화 되어 양방향 SEED 사용이 필요한 데이터에 적용

<표 150> 암호화 방안

난수 생성시 안전한 난수 생성 알고리즘을 사용해야 함. 국가정보원 “암호알고리즘 검 증기준 V2.0” 또는 FIPS 140-2 인증을 받은 암호모듈의 난수생성기와 256비트 이상의 시 드를 사용하여 난수를 생성함. 난수의 무작위성을 보장하기 위해 이전 난수 생성 단계 의 결과를 다음 난수생성 단계의 시드로 사용하는 의사난수생성기를 이용함

마. 어플리 케이션 보안

○ 웹 취약점 점검

정보시스템 소프트웨어 개발보안 가이드, OWAS_TOP10, 홈페이지 개인정보 노출방지 가이드라인을 참고하여 작성함. 취약점 점검을 통한 외부로의 시스템 노출을 피하고 문제점 분석을 통한 적절한 대응체계 수립으로 중요 데이터에 대한 손실을 예방하며 시스템에 대한 보안성 및 무결성을 강화함

점검 항목

항목 내용

관리자 페이지 등 사용자 인증이 필요한 페이지가 인증을 거치지 않고 접 인증우회 근이 가능한지 점검

게시판 등을 통해 XSS 취약점이 가능한지를 검사함. 가능한 경우 다른 사 용자의 세션정보가 노출되며, 이를 통하여 타 사용자의 권한으로 웹 서버 XSS 에 접근하여 수행이 가능(Cookie-sniffing, Cookie-Spoofing으로 발전)한지 점검 XSS를 이용하여 타인의 쿠키 값 및 세션 값을 확보할 수 있는 취약점 점 Cookie-sniffing 검 XSS를 이용하여 타인의 쿠키 값/세션 값을 확보하여 그 사용자의 권한으 Cookie-Spoofing 로 웹 서버에 로그인 할 수 있는 취약점 점검

웹 서버의 다운로드 스크립트를 이용하여 서버 시스템의 주요 파일(웹 소 파일 스 스크립트, 웹 서버 설정 파일 시스템 파일, 패스워드 파일 등)이 외부로 노출 될 수 있는지 점검

웹 서버에 파일 업로드를 시킴으로써 외부에서 웹 서버에 명령을 내릴 수 다운로드 있는 원인이 되는 취약점 점검

319

항목 내용

웹 서버와 공격자 혹은 타 사용자의 client 사이에서 패킷을 가로채어 내용 업로드 을 변조함으로써 홈페이지 게시판의 위/변조, DB정보의 획득 등에 사용되 는 취약점 점검

패킷 변조의 한 형태로 웹 서버로 전송되는 패킷을 가로채어 웹 서버와 패킷 변조 DB 서버간에 이루어지는 SQL 질의문을 원하는 형태로 조작함으로써 불법 적으로 로그인 하거나 DB정보를 빼 내올 수 있는 취약점 점검

관리자 페이지 등 사용자 인증이 필요한 페이지가 인증을 거치지 않고 접 SQL Injection 근이 가능한지 점검

<표 151> 점검 항목

○ 시큐어코딩 점검

정보시스템 구축, 운영 지침, 정보시스템 소프트웨어 개발보안 가이드(행정자치부), JAVA 시큐어 코딩 가이드(행정자치부)을 근거로 작성함. 개발 과정에서 발생할 수 있는 코드 상의 보안적 취약점을 최소화하며 사전의 점검 조치로 운영 및 유지보수 측면의 효율성을 제고함

유형 내용 프로그램 입력값에 대한 검증 누락 또는 부적절한 검증, 데이터의 잘못된 입력데이터 검증 및 형식지정으로 인해 발생할 수 있는 보안약점 표현 ※ SQL 삽입, 자원 삽입, 크로스사이트 스크립트 등 26개 보안기능(인증, 접근제어, 기밀성, 암호화, 권한관리 등)을 적절하지 않게 보안기능 구현 시 발생할 수 있는 보안약점 ※ 부적절한 인가, 중요정보 평문저장(또는 전송)등 24개 프로그램의 동작 과정에서 시간적 개념을 포함한 개념(프로세스 혹은 스레드 등)이나 시스템 상태에 대한 정보(자원 잠금이나 세션 정보)에 시간 및 상태 관련된 취약점 ※ 데드락(dead lock)이나 자원에 대한 경쟁조건, 또는 세션 고착 등 7개 에러를 처리하지 않거나, 불충분하게 처리하여 에러정보에 에러처리 중요정보(시스템 등)가 포함될 때 발생할 수 있는 보안약점 ※ 취약한 패스워드 요구조건, 오류메시지를 통한 정보노출 등 4개 타입변환 오류, 자원(메모리 등)의 부적절한 반환 등과 같이 개발자가 코드 오류 범할 수 있는 코딩오류로 인해 유발되는 보안약점 ※ 널 포인터 역참조, 부적절한 자원 해제 등 7개 중요한 데이터 또는 기능성을 불충분하게 캡슐화하였을 때, 인가되지 캡슐화 않는 사용자에게 데이터 누출이 가능해지는 보안약점 ※ 제거되지 않고 남은 디버그 코드, 시스템 데이터 정보노출 등 8개 의도된 사용에 반하는 방법으로 API를 사용하거나, 보안에 취약한 API를 API 오용 사용하여 발생할 수 있는 보안약점 ※ DNS Lookup에 의존한 보안결정, J2EE 직접 연결관리 등 7개

<표 152> 시큐어코딩 점검

320

사. 가상화 모니터 링

○ 모니터링 대상 : 가상화는 하드웨어 가상화, 스토리지 가상화, 네트워크 가상화가 있음. 하드웨어 가상화는 물리적인 서버의 효율적 사용을 위해서 하나의 서버를 논리적으로 분할하여 여러 개의 서버처럼 만드는 기술. 이 기술의 목적은 관리의 유용성과 비용 절감에 있으며 분할된 서버는 자체적으로 운영 체제나 어플리케이션을 실행할 수 있으므로 물리적인 컴퓨터와 동일 기능을 수행한다고 볼 수 있음

○ 가상 머신은 소프트웨어로만 구성되어 있으므로 하드웨어 리소스와 분리되어 사용하지는 못 함. 스토리지 가상화는 물리적인 저장 공간이나 논리적 저장 공간 안에 존재하면서 간소화된 논리적 스토리지 리소스 보기를 제공하는 추상계층이라 볼 수 있음. 정확한 의사 결정을 내리기 위해서 기업과 조직, 조직 내 사용자들은 엄청난 데이터를 사용하고 있고, 최근에는 클라우드 빅 데이터와 같은 이슈들도 주목받고 있기 때문에 데이터를 저장, 관리할 수 있는 스토리지의 운영이 무엇보다도 중요해지고 있음

스토리지 가상화는 어플리케이션에 영향을 미치지 않으면서 자원의 효율성을 증대시키기 때문에 많은 조직에서 여기에 주목하고 있음

네트워크 가상화는 물리적인 통신 자원들을 분할하여 여러 사용자에게 독립적으로 자원을 분배하는 기술을 의미함. 인터넷 환경에서 어플리케이션 수요에 능동적으로 대응하기 위해서는 네트워크에 대해서도 서버와 스토리지 수준의 가상화가 요구된다. 많은 기업들이 현재 이 기술의 개발에 집중하고 있음

가상화 기술은 가상화된 IT 자원에 대해 사용량을 모니터링할 수 있는 툴을 제공. 이 툴에 의해 사용량을 항상 모니터링하고 사용량에 따라 유연하게 자원할당이 가능. 따라서 도입 PaaS 플랫폼인 OpenShift의 모니터링 기능을 활용한 컨테이너의 상태를 모니터링하는 방안 제시

<그림 313> OpenShift

321

○ 주요 모니터링 기능

Project별 커뮤니티 환경 구성 기능

Project 별로 서로간의 리소스 간섭 없이 독립된 운영 공간 제공

각 Project가 사용할 수 있는 전체 Quota 설정

프로젝트 내에 구성한 각 개별 컨테이너에 대한 모니터링 제공

낮은 진입장벽과 개발환경 구성 및 운영 인력 지원의 효율화 제공

특정 컨테이너를 모니터링 하여 replica 개수 만큼 유지 및 서비스될 수 있도록 기능 제공

JVM 모니터링용 Console 제공

6.4 중앙영구기록관리시스템(CAMS) 기능 설계

가. 중앙영구기록관리시스템 기능 설계 전략

○ 인프라를 단계적으로 클라우드 IaaS 환경으로 전환한 후, 중앙영구기록관리시스템 아키텍처를 차세대 기록관리시스템 아키텍처로 교체하고 클라우드 SaaS 서비스 제공 시스템을 목표로 함

○ 현행 기능은 차세대 기록관리 서비스와 대응하여 흡수 또는 통합하여 구성

○ 인공지능 활용 분류 및 검색 등 확장 기능을 차세대 기록관리 아키텍처 상에서 추가 개발하도록 함

나. 중앙영구기록관리시스템의 차세대 기록관리 서비스 전환

○ 차세대 기록관리 서비스로 구성하기 위하여 현행 기능에 대응하는 차세대 기록관리 서비스로 통합 또는 분류하여 제시함

프로 차세대 대기능 중기능 소기능 설명 기록관리 세스 서비스 분류체 기록물분류 기록물분류기 기록물분류기준표 목록 및 P5 분류체계 계 관리 기준표 준표 상세내용 조회 기능 서비스 기록관 단위과제보 단위과제 보존기간 조정 신청을 B8 분류체계 단위과제접수 리기준 존기간관리 온.오프라인으로 접수 서비스 기준 신청한 단위과제를 접수파일 B8 분류체계 관리 단위과제조정 단위로 조회하여 보존기간을 서비스 조정/검수 하는 기능 조정처리 한 단위과제를 단위과제승인 B8 분류체계 접수단위로 확인 후 통보하는 통보 서비스 기능 파일생성 및 기관별단위과제보존기간조정신 B8 분류체계

다운로드 청단위로통보규격파일 및 서비스

322

프로 차세대 대기능 중기능 소기능 설명 기록관리 세스 서비스 엑셀파일다운로드기능 기관별 단위과제 보존기간 조정 단위과제 B8 분류체계 신청 단위로 통보한 조정 기준 승인 재통보 서비스 신청건의 재통보 기능 관리 기록관리기준표 등록 및 기록관리기 기록관리기준 P5 분류체계 외부시스템 기록관리기준 정보 준표관리 표관리 서비스 들여오기 기능

중앙행정기관 및 기록관리기준 B8 분류체계 지방자치단체의 표검색 서비스 기록관리기준표 조회 기능 기록물 생산현황을 직접연계를 생산현황 통한 수신이나 파일 업로드를 Business 인수 생산현황접수 관리 통해 기록물 생산현황을 Service 관리하는 기능 생산현황보고의 메타데이터를 Business 생산현황검수 확인 후 검수 Service 생산현황확정 생산현황보고 검수 완료 후 Business

(통보) 인수 및 반려를 선택 통보 Service 이관대상기록물에 대하여 B7 기록물이관 인수검토 접수 RMS,AMS,CAMS에 서비스 이관검토요청을 수행 접수완료된이관검토요청에대하 여기록물철별로승인작업을수행 B7 기록물이관 승인.통보처리 하며, 서비스 작업이완료된경우기관으로검토 결과를통보 이관기록물접 이관규격에 맞게 P4 입수 기록물인수 수 온.오프라인으로 파일을 인수 서비스 기관별, 회차별 이관기록물에 기록 육안검수 Business 대해 육안검수 대상을 확정 및 등록 대상 확정 Service 검수자에게 배정 검수 담당자별 검수 대상기록물 검수담당자 Business 배정 현황을 확인을 하고 배정현황 Service 취소할 수 있음 이관기록물검 이관접수완료 기록물에 대하여 B7 기록물이관

수 품질검사를 수행 서비스 전자기록물검 육안검수자의일일할당량대상기 Business

수 록물만조회및검수를진행 Service 육안검수가 완료한 기록물에 Business N차품질검사 대해 N차 품질검사를 진행 Service 접수번호별 이관기록물 기록물인수확 육안검수가 완료되었거나, 철별 B7 기록물이관

정 인수확정이 수행된 경우 최종 서비스 기록물을 인수확정 년도별 생산기관 수, 접수기록물 수, 인수기록물 수, B7 기록물이관 기록물현황 반려기록물 수를 확인할 수 서비스 있음 인수기록물수 인수된 기록물의 기본 P4 입수

정 메타데이터에 대한 수정을 진행 서비스

323

프로 차세대 대기능 중기능 소기능 설명 기록관리 세스 서비스 RFID태그발 Business 인수기록물의 RFID태그 발행 행 Service 인수기록물정 인수받은 기록물에 대한 Business

리의뢰 정리의뢰서를 작성 Service 직접 수집한 기록물로 이관 Business 인수 인수대장 시점의 인수인계정보 및 기록물 Service 수량정보를 관리 년도별 접수기관의 회차별 인수현황모니 목록승인 수량, 품질검사 상태, P3 포탈

터링 육안검수 상태, 인수 상태 등을 서비스 총괄적으로 확인 인수대상에 속하는 기록물이나, B7 기록물이관 미인수현황 아직 인수가 되지 않은 서비스 기록물의 현황을 확인 육안검수 생산기관별 생산기관별 육안검수 현황을 Business

현황 오류유형 확인 Service 인수기관별 전자기록물 총괄실적진척 Business 육안검수 진척도 수량 및 도 Service 진척률을 확인 검수자별 월간 육안검수 처리 Business 월간작업현황 현황을 확인 Service 검수자별 주간 육안검수 처리 Business 주간작업현황 기록 현황을 확인 Service 검수자별 일간 육안검수 처리 Business 등록 일간작업현황 현황을 확인 Service 조회 검수일자를 기준으로 검수일자별오 Business 오검수건에 대한 본문, 붙임별 검수유형 Service 오류유형 통계를 확인 생산기관접수 접수번호별 인수현황, 육안검수 Business 번호별검수현 결과 및 N차 품질검사 현황을 Service 황 확인 검수담당별 검수일자별품 검수정보(품질검사건수, Business 질검사진행현 완료건수, 오검수건수, Service 황 오검수률)등을 확인 일반문서 메타데이터를 등록, P1 기록 등록 일반기록물 일반문서 수정 서비스 역사기록물메타데이터를등록,수 P1 기록 역사기록물 정,삭제 서비스 총독부기록물 메타데이터를 P1 기록 총독부기록물 등록, 수정, 삭제 서비스 시청각기록물메타데이터를관리. 형태에따라추후디지털화작업시 시청각기록 P1 기록 시청각기록물 사진업로드화면,오디오입력화면 물 서비스 ,비디오 입력화면으로분기됨 발간등록번호 각 기관 담당자가 Business 정부간행물 신청 간행물발간등록 신청 Service 정부간행물등 발간번호를 생성 부여하여 Business

록 홈페이지로 전송 부여된 Service

324

프로 차세대 대기능 중기능 소기능 설명 기록관리 세스 서비스 발간등록번호에 대한 납본이 수행되었을 경우 메타데이터를 등록 발간등록번호, 발간주기등의 검색조건으로 정부간행물 폐간 Business 폐간신청 목록을 조회 일괄폐기시키는 Service 기능 발간주기, 간행물제목 등 Business 미송부간행물 검색을 통하여 미송부 간행물 Service 목록을 조회 납본처리 B6 해외기록물(일반기록물)에 대한 해외기록물 일반문서 지적재산권관 철, 건, 저작권을 등록 리 서비스 해외기록물 시청각기록물 P1 기록 시청각기록물 정보를 등록, 수정 등 관리하는 서비스 기능 B6 민간기록물(일반기록물)에 대한 민간기록물 일반문서 지적재산권관 기록 철, 건, 저작권을 등록 등록 리 서비스 민간기록물 시청각기록물 P1 기록 시청각기록물 정보를 등록, 수정 등 관리하는 서비스 기능 P4 입수 웹기록물 웹기록물 웹기록물을 이관함 서비스 RFID태그 등록기록물R 등록된 기록물에 대해 RFID Business

발행 FID태그발행 태그를 발행 Service

등록완료된 일반, 시청각 등 기록물정리 기록물정리의 Business 모든 기록물에 대해 기록물 의뢰 뢰 Service 정리의뢰를 수행

기록물 기록물정리 기록물정리인 정리의뢰서를조회하여의뢰대상 B7 기록물이관 정리 인수 수 기록물을인수처리 서비스 정리작업이 완료 된 기록물에 B7 기록물이관 철 라벨 출력 부착 할 라벨을 출력하거나 서비스 서고배치의뢰 보존상자편 제본 및 라벨이 부착된 Business 보존, 보존상자편성 처분 성 기록물에 보존상자를 편성 Service 상자라벨출 정리대상 기록물에 부착할 B7 기록물이관 상자라벨출력 력 보존라벨을 출력하는 기능 서비스 정리작업이 완료된 기록물의 Business 소독의뢰 소독의뢰 소독, 서고배치 의뢰 기능 Service 포맷관 문서보존포 생산부서별변 생산부서별로 문서보존 대상을 P11 리 맷변환 환 포맷변환작업을 실행하고, 디지털보존

325

프로 차세대 대기능 중기능 소기능 설명 기록관리 세스 서비스 포맷변환 진행상태를 조회하는 서비스 기능 생산부서, 단위과제(단위업무), 철제목 등 조회 조건으로 P11 기록물철별변 문서보존포맷 변환대상을 디지털보존 환 조회하여 기록물철 단위로 서비스 포맷변환요청 및 변환취소 등을 할 수 있는 기능 생산년도별, 보존기간별 P11 기록물철/건 기준으로 포맷변환현황 디지털보존 문서보존포맷 변환대상 및 서비스 변환작업 진행상태를 조회 생산부서별로 장기보존포맷 P11 장기보존포 생산부서별변 대상을 포맷변환작업을 디지털보존 맷변환 환 실행하고, 포맷변환 서비스 진행상태를 조회하는 기능 생산부서, 단위과제(단위업무), 철제목 등 조회 조건으로 P11 기록물철별변 장기보존포맷 변환대상을 디지털보존 환 조회하여 기록물철 단위로 서비스 포맷변환요청 및 변환취소 등을 할 수 있는 기능 생산년도별, 보존기간별 P11 기록물철/건 기준으로 포맷변환현황 디지털보존 문서보존포맷 변환대상 및 보존, 서비스 처분 변환작업 진행상태를 조회 생산년도별, 보존기간별 P11 포맷변환모 포맷변환모니 기록물철/건 기준으로 디지털보존 니터링 터링 장기보존포맷 변환대상 및 서비스 변환작업 진행상태를 조회 서고배치의뢰서 목록을 조회 후 인수, 서고에 배치 한 후 Business 서고 서고배치 서고배치 배치정보를 등록/관리하는 Service 기능 서고배치 완료 된 기록물을 P10 서고관리 서고재배치 조회하여 서고재배치 후 배치 서비스 정보를 등록/관리하는 기능 P9 서고정보를 조회하고 서고, 서고/서가정 비전자기록물 서가, 련, 단, 순을 보 스토리지 등록/관리하는 기능 서비스 RFID태그 재부착이 필요한 RFID태그재 Business 기록물을 조회하여 태그발행 및 발행 Service 발행이력을 관리하는 기능 P9 기록물을 보존시설, 비전자기록물 서고배치확인 기록물위치/상태정보를 스토리지 변경하는 기능 서비스 서고배치의 기록물 배치현황을 P9 서고배치현황 도식화하여 확인하는 기능 비전자기록물

326

프로 차세대 대기능 중기능 소기능 설명 기록관리 세스 서비스 스토리지 서비스 서고 가용량 측정을 위해 기록물 Business 기록물 유형별 두께 정보를 정보관리 Service 설정하는 기능 서고배치 대상 기록물을 시뮬레이션관 Business 가상으로 배치해 결과를 예측할 리 Service 수 있는 기능 각 부서에서 반출의뢰한 기록물 B2 반입반출 반출/반입 반출 목록을 조회하여 반출 처리하는 서비스 기능 각 부서에서 반입의뢰한 기록물 B2 반입반출 반입 목록을 조회하여 반출 처리하는 서비스 기능 반출의뢰서 기준으로 미반입 된 B2 반입반출 미반입현황 기록물이 존재하는 의뢰서를 서비스 조회하는 기능 반출의뢰서, 반입의뢰서, B2 반입반출 반출/입현황 관리번호를 기준으로 반출입 서비스 현황을 조회하는 기능 업무 이외의 상시 기록물 무단반출입제 B2 반입반출 이동을 위하여 반출입 체크를 외 서비스 제외하는 기능 반출입 의뢰서 별 기록물의 B2 반입반출 인계인수이력 반출입 인수인계 현황을 서비스 보존, 조회하는 기능 처분 서고 배치된 기록물 등의 정수점검스케 배치정보 및 수량을 점검하기 B5 정수점검 정수점검 줄링 위한 스케줄링을 서비스 등록/관리하는 기능 서고배치 된 기록물의 배치정보 B5 정수점검 정수점검 및 수량 등 점검 결과를 서비스 등록/관리하는 기능 서고점검스케 서고시설, 보안 등 서고점검 Business 서고점검 줄링 스케줄링을 등록/관리하는 기능 Service 서고 및 시설 등 서고 Business 서고점검 점검결과를 등록/관리하는 기능 Service 보존시설 변경으로 인해 기록물 Business 이송 이송스케줄링 등을 이송하기 위한 스케줄링을 Service 등록/관리하는 기능 이송 스케줄링 별로 대상을 Business 이송 반출의뢰하고 이송 처리하는 Service 기능 이송 유형별로 이송 대상의 Business 입고 입고 처리결과를 등록/관리하는 Service 기능 이송 유형별로 입고 처리된 Business 서고의뢰배치 기록물을 서고배치 의뢰하는 Service 기능 RFID관리 고정형리더기 고정형리더기의 가동/운영 상태 Business

327

프로 차세대 대기능 중기능 소기능 설명 기록관리 세스 서비스 변경 및 정보를 등록/관리하는 Service 기능 태그발행기 태그발행기 정보를 Business

등록 등록/관리하는 기능 Service 고정형리더기를 통하여 반출입이력조 Business 기록물이 서고에 반출입한 회 Service 이력을 조회하는 기능 고정형리더기를 통하여 이동한 고정형리더기 Business 기록물의 정보를 조회할 수 현황조회 Service 있는 기능 P9 보존시설 기준으로 현재 기록물위치 기록물위치별 비전자기록물 기록물위치별 현황을 조회하는 별현황 현황 스토리지 기능 서비스 P9 서고에 배치 완료된 기록물 비전자기록물 서고현황 서고현황 정보 조회기능 스토리지 서비스 관리전환번호 단위로 타 관리전환검 Business 관리전환검색 기관으로으로 관리전환 된 색 Service 기록물 목록 조회기능 기록물정리, 소독반출에서 Business 보존 소독 소독처리 소독의뢰 된 목록 조회, Service 소독처리 내역 등록기능 보존, 서고배치 정보가 존재하는 Business 처분 사독반출의뢰 기록물에 대하여 소독처리를 Service 위해 반출의뢰기능 기록물 상태검사(점 Business 상태검사 상태검사(점검)스케줄링을 검)스케줄링 Service 등록하고 대상을 선정하는 기능 스케줄링 된 상태검사(점검) 상태검사(점 Business 대상 기록물의 상태검사정보를 검) Service 입력하는 기능 기록물 상태검사(점검) 이력을 Business 상태검사검색 조회, 상태검사 조사표 Service 출력하는 기능 전자기록물에 대한 상태/정수점 Business 상태/정수점검 현황 조회, 검(전자) Service 상태/정수점검 수행기능

제본 제본 스케줄링을 등록하고 Business 제본 스케줄링 대상을 선정하는 기능 Service

328

프로 차세대 대기능 중기능 소기능 설명 기록관리 세스 서비스 스케줄링 된 제본 대상 Business 제본 기록물의 제본 처리 결과를 Service 입력하는 기능 탈산 탈산 스케줄링을 등록하고 Business 탈산 스케줄링 대상을 선정하는 기능 Service 스케줄링 된 탈산 대상 Business 탈산 기록물의 탈산 정보를 입력하는 Service 기능 복원 복원 스케줄링을 등록하고 Business 복원 스케줄링 대상을 선정하는 기능 Service 생산기관 및 각 팀에서 복원의뢰한 기록물을 접수하여 Business 복원의뢰접수 복원 스케줄링을 처리하는 Service 기능 스케줄링 된 복원 대상 Business 복원 기록물의 복원처리 정보를 Service 입력하는 기능 복원처리 완료된 기록물 목록 Business 복원결과조회 조회하는 기능 Service 디지털복원 디지털복원 디지털복원 스케줄링을 Business

(시청각) 스케줄링 작성하고 대상을 선정하는 기능 Service 디지털복원 스케줄링 목록을 Business 디지털복원 조회하여 디지털복원 결과를 Service 보존, 등록하는 기능 처분 복원대상으로 선정된 디지털복원 디지털복원 목록을 조회하여 Business

결과조회 복원 전 원본이미지와 Service 복원이미지를 조회하는 기능 디지털복제 디지털복원스케줄링을작성하고 Business 디지털복제 스케줄링 대상을선정하는기능 Service 디지털복제 스케줄링 목록을 Business 디지털복제 조회하여 디지털복제 결과를 Service 등록하는 기능 복제대상으로 선정된 디지털복제 디지털복제 목록을 조회하여 Business

결과조회 복제 전 원본이미지와 복제 Service 이미지를 조회하는 기능 보존처리( 보존처리 보존처리 스케줄링을 작성하고 Business

시청각) 스케줄링 대상을 선정하는 기능 Service 보존처리 스케줄링 목록을 Business 보존처리 조회하여 보존처리 결과를 Service 등록하는 기능 보존처리 의뢰된 보존처리 보존처리( 보존처리 Business 의뢰서 목록을 조회하여 인수 박물류) 인수 Service 처리하는 기능 보존처리 보존처리 스케줄링을 작성하고 Business

스케줄링 대상을 선정하는 기능 Service 보존처리 스케줄링 목록을 Business 보존처리 조회하여 보존처리 결과를 Service 등록하는 기능

329

프로 차세대 대기능 중기능 소기능 설명 기록관리 세스 서비스 보존처리 Business 보존처리 결과를 조회하는 기능 결과조회 Service 종이기록물 복제 복제 스케줄링을 작성하고 Business

복제 스케줄링 대상을 선정하는 기능 Service 외부복제의뢰 외부기관 종이기록물 복제 의뢰 Business

접수 접수하는 기능 Service 복제 스케줄링 목록을 조회하여 Business 복제 복제 결과를 등록하는 기능 Service 종이기록물 복제 완료된 기록물 Business 복제검색 검색, 복제처리서 내용을 Service 조회하는 기능 매체이전 매체이전 스케줄링을 작성하고 Business 매체이전 스케줄링 대상을 선정하는 기능 Service 매체이전 스케줄링 목록을 매체이전 Business 조회하여 매체이전 결과를 스케줄링 Service 등록하는 기능 매체이전 처리된 목록을 매체관리번호 Business 조회하고 매체관리번호를 부여 Service 부여하는 기능 보존매체수록 의견을 조회하여 매체수 보존매체수 보존매체수록 기록물 보존매체수록 Business 록 록조정 대상선정 조정의견을 등록할 수 있는 Service 기능 등록된 보존매체수록 조정의견을 취합하여 해당 Business 보존, 보존매체지정 처분 기록물의 보존매체를 지정하는 Service 기능 M/F촬영 대상 기록물을 M/F 촬영 Business M/F촬영 조회하여 스케줄링을 스케줄링 Service 등록/관리하는 기능 M/F 촬영된 원본 M/F를 서고 Business

배치의뢰 배치의뢰하는 기능 Service Business M/F 복제 M/F복제 관리 기능 Service M/F 촬영된 원본 M/F의 Business RFID태그발 RFID태그발행 및 이력 Service 행 조회기능 복제M/F 복제된 M/F의 RFID 태그발행 Business RFID태그발 및 발행이력 조회 기능 Service 행 M/F M/F 촬영계획서 목록을 Business 촬영계획서 조회하고 출력하는 기능 Service 조회 M/F 촬영된 M/F 기록물을 조회 할 Business 촬영기록물 수 있는 기능 Service 조회 스캐닝 대상 기록물을 조회하여 스캐닝 Business 스캐닝 스케줄링을 등록/고나리 하는 스케줄링 Service 기능 스캐닝 스캐닝 스케줄링 목록을 Business

330

프로 차세대 대기능 중기능 소기능 설명 기록관리 세스 서비스 조회하여 대상 기록물을 반출

및 스캐닝정보를 등록 할 수 Service

있는 기능

스캐닝 등록된 기록물 목록을 Business 스캐닝검사 조회하여 등록된 이미지를 Service 검사할 수 있는 기능

보존매체수록 보존매체수록 기록물의 Business RFID RFID태그를 발행 하는 기능 Service 태그발행 스캐닝 의뢰된 정부간행물 Business 스캐닝인수 목록을 조회하여 스캐닝 Service 인수하는 기능 M/F 촬영된 기록물을 스캐닝 하기 위해 열람실에 배치된 복제 M/F Business 복제 M/F를 대출의뢰 하여 대출의뢰 Service 스캐닝 완료 후 반입 처리하는 기능 서고배치 된 시청각기록물을 디지털화작 디지털화 Business 대상으로 디지털화 스케줄링 업 스케줄링 Service 등록/관리하는 기능 디지털화스케줄링목록을조회하 여기록물을반출,세부목록등록및 Business 디지털화 디지털화완료된전자파일을등록 Service 할수있는기능 DBD매체에 RFID 태그를 디지털 RFID Business 발행하고 서고배치 의뢰하는 태그발행 Service 보존, 기능 처분 MAM시스템과 연계하여 디지털화( 디지털화 디지털화를 수행하기 위해 Business

MAM) 스케줄링 스케줄링을 등록, 선정 및 Service 수정하는 기능 스케줄링 단위로 반출, 인수, 반입을 수행하고, 모든 건 Business 디지털화 메타데이터를 MAM으로 Service 전송하여 디지털화를 요청하여 수행 디지털화된 기록물의 이미지를 P11 보존매체관 보존매체정보 저장하기 위한 OD정보를 디지털보존 리 등록하는 기능 서비스 세부목록 등록이 완료된 P11 보존매체수록 시청각기록물의 디지털화된 디지털보존 계획서작성 전자파일을 보존매체에 서비스 수록하여 관리할 수 있는 기능 P11 보존매체수록 보존매체수록계획서 목록을 디지털보존 계획서현황 조회하고 출력하는 기능 서비스 수록 완료된 보존매체를 P11 OD복제 이중보존 및 활용을 위해 디지털보존 복제하는 기능 서비스 서고배치의뢰 원본/복제 보존매체를 보존하기 Business

331

프로 차세대 대기능 중기능 소기능 설명 기록관리 세스 서비스 위해 서고배치를 의뢰하는 기능 Service P11 보존매체수 보존매체수록 보존매체수록을 위한 디지털보존 록관리 스케줄링 스케줄링을 등록 서비스 비전자기록물의 전자화원문을 보존하기 위해 성남 전산실에 Business 보존매체수록 있는 DVD쥬크박스를 Service 이용하여 수록하는 기능 전자화원문 수록이 완료된 RFID Business DVD에 RFID 태그를 발행하여 태그발행 Service 부착할 수 있는 기능 전자화원문이 수록된 보존매체 DVD를 서고에 배치할 수 Business 서고배치의뢰 있도록 서고배치의뢰 기능을 Service 수행 비전자기록물 전자화원문 P11 보존매체수록 보존매체수록 결과를 조회하는 디지털보존 결과조회 기능 서비스 P11 매체수록결 매체수록결과 매체수록 판단 결과를 조회하는 디지털보존 과조회 조회 기능 서비스 기술분류체계의 계층업무에 기술/재 군/컬렉션관 P1 기록 기술분류 따라 군/계열 정보를 등록/관리 보존, 분류 리 서비스 처분 하는 기능 기술분류에 분류된 기록물을 기록물분류기 P1 기록 조회하고 재분류/분류해제, 준표 서비스 임시보관함으로 이동하는 기능 기술분류 생성, 수정, 이동 P1 기록 군계열이력 이력을 조회하는 기능 서비스 기록물분류이 기록물의 분류이력을 조회하는 P1 기록

력 기능 서비스 기술분류별 기록물 분류현황을 P1 기록 기술통계관리 조회하는 기능 서비스 기록물 기술 스케줄링을 기술 P1 기록 기술 등록하고 대상 기록물을 스케줄링 서비스 선정하는 기능 기술 스케줄링에 선정된 기록물을 조회하고 보존매체 P1 기록 내용요약 판단 및 매체의견, 내용요약 서비스 등을 등록하는 기능 기술 스케줄링에 선정된 기록물 반출의뢰, 인수 및 기술작업 B2 반입반출 반출의뢰 완료 후 서고에 반입 의뢰하는 서비스 기능 군/계열기술서를 조회하고 P2 분류체계 집합기술 작성하는 기능 서비스 기록물 기술/평가 작업중 B12 기능어/키워 발견된 기능어 및 키워드를 지능형검색 드등록 등록하는 기능 서비스 기능어/키워 기능어 및 키워드 용어 등록 B12

332

프로 차세대 대기능 중기능 소기능 설명 기록관리 세스 서비스 지능형검색 드등록현황 현황을 조회하는 기능 서비스 P11 기록물의 매체수록 여부를 매체수록판단 디지털보존 판단, 결과를 등록하는 기능 서비스 P11 매체수록결과 기록물의 매체수록판단 결과를 디지털보존 조회 조회하는 기능 서비스 군/계열 기술서의 홈페이지 기술서비스관 서비스 여부를 설정/관리하는 리 기능 서비스제목 서비스제목관 기록물의 서비스 제목을

관리 리 등록/관리하는 기능 공개재분류 시기가 도래한 공개재분류 B9 공개재분류 공개재분류 기록물을 대상으로 공개재분류 스케줄링 서비스 스케줄링을 등록하는 기능 최초재분류(3 30년 미경과 최초재분류 정보를 B9 공개재분류

0년미경과) 등록하는 기능 서비스 최초재분류(3 30년경과 최초재분류 정보를 B9 공개재분류

0년경과) 등록하는 기능 서비스 5년주기재분 30년미경과 5년주기재분류 B9 공개재분류 류(30년미경 정보를 등록하는 기능 서비스 과) 5년주기재분 30년경과 5년주기재분류 B9 공개재분류

보존, 류(30년경과) 정보를 등록하는 기능 서비스 처분 공개재분류 대상기록물 정보를 기록물공개분 B9 공개재분류 조회, 상시 철/건 공개재분류 류 서비스 결과를 등록하는 기능 공개재분류기 공개재분류기준서 B9 공개재분류

준서 등록/관리하는 기능 서비스 공개재분류 대상기록물을 B9 공개재분류 기록물반출 반출의뢰, 인수, 반출기록물을 서비스 반입의뢰 하는 기능 공개재분류현 기록물의 공개재분류 현황을 B9 공개재분류

황 조회하는 기능 서비스 공개재분류대 공개재분류 대상 기록물을 B9 공개재분류

상조회 조회하는 기능 서비스 보존기간재분류 시기가 도래한 보존기간재 보존기간재분 기록물을 대상으로 P6 처분일정

분류 류 스케줄링 보존기간재분류 스케줄링을 서비스 등록하는 기능 보존기간재분류 대상기록물의 보존기간재분 재분류 정보를 등록하고 Business

류 반출의뢰/인수/반입의뢰 하는 Service 기능 보존기간재분 기록물의 보존기간재분류 P3 포탈

류현황 현황을 조회하는 기능 서비스 폐기대상 기록물을 생산년도별 B3 평가 평가·폐기 대상현황 보존기간별 폐기대상 기록물 서비스

333

프로 차세대 대기능 중기능 소기능 설명 기록관리 세스 서비스 철수와 대체보존으로 인한 폐기대상 기록물현황을 조회 평가폐기 대상으로 생성된 기록물 철 중 당해년도에 B3 평가 대상선정 평가폐기 심사 대상 기록물을 서비스 선정하는 기능 평가폐기 대상 기록물의 B3 평가 의견등록 처리부서 및 전문요원의 의견을 서비스 등록하는 기능 평가폐기 심의회 개최를 위하여 심의서작성 및 B3 평가 평가심의 기록물평가심의회에서 결정한 서비스 심의결과등록를 등록하는 기능 생산기관과 협의 및 기록물평가심의회 및 B3 평가 대체보존 국가기록관리위원회의 서비스 보존, 심의결과를 반영하는 기능 보존기간만료 또는 대체보존 처분 B3 평가 결과반영 평가폐기 기록물에 대한 최종 서비스 평과 결과를 반영하는 기능 폐기처리 결과를 기록물 단위로 등록을 하고, 또한 폐기 B3 평가 폐기집행 기록물의 전자파일을 서비스 표준기록관리시스템에서 영구 삭제하는 기능

평가폐기 대상 기록물철수 및 B3 평가 폐기현황 심의의견별 기록물철수 현황 서비스 통계자료

검색 철,건 및 기간, 행위자, 분류 등 P3 포탈 검색 조건별 검색 활용 다양한 조건을 통한 검색 기능 서비스 메타항목 중 주요 항목 및 전자파일의 전문(full text) P3 포탈 전문검색 색인정보를 이용하여 지정한 서비스 단어로 관련 기록물을 검색하는 기능 활용 기록물 분류체계 또는 P3 포탈 분류체계검색 조직별분류체계를 기준으로 서비스 기록물 목록을 검색하는 기능 타 기록관으로부터 인수받은 기관간이수대 P3 포탈 기록물철,건 목록을 검색하는 상검색 서비스 기능 정부간행물을 검색하고 정부간행물검 P3 포탈 기본항목, 관리항목 및 색 서비스 첨부파일을 활용하게 하기

334

프로 차세대 대기능 중기능 소기능 설명 기록관리 세스 서비스 위한 기능 기록관에서 수집 등록한 행정박물의 보유 상태 및 P3 포탈 행정박물검색 행정박물에 기본항목 및 서비스 사진이미지 등 검색하는 기능 열람대장관 열람활 정보공개처리 정보공개청구서 목록 B1 원문공개 리(정보공 용 대장 조회/관리하는 기능 서비스 개청구) 정보공개청구 정보공개처리청구서를 B1 원문공개

서접수 등록/접수하는 기능 서비스 정보공개 처리를 위해 반출한 B1 원문공개 기록물반입 기록물을 관리번호 단위로 서비스 활용 조회하여 반입하는 기능 콘텐츠기획 업무관련 콘텐츠기획 B2 반입반출 콘텐츠기획 스케줄링을 작성 및 조회, 스케줄링 서비스 대상을 선정하는 기능 콘텐츠기획 스케줄링 대상 B2 반입반출 기록물반출 기록물 반출, 반입하는 기능 서비스 특수유형기록물의 홈페이지 홈페이지서 홈페이지서비 P14 내보내기 서비스 여부를 등록/관리하는 비스관리 스관리 서비스 기능 특수유형기록물의 홈페이지 홈페이지서비 P14 내보내기 서비스 여부 변경이력을 스이력 서비스 조회하는 기능 접근제한 기록물에 대하여 접근 기록물철 단위로 기록물 접근 P11 감사 접근관리 기록물철 사용자 또는 접근부서를 시스템관리 추적 지정하여 기록물 접근권한을 서비스 부여하는 기능 접근제한 기록물에 대하여 기록물건 단위로 기록물 접근 P11 기록물건 사용자 또는 접근부서를 시스템관리 지정하여 기록물 접근권한을 서비스 부여하는 기능 접근제한 기록물에 대하여 생산부서 단위로 기록물 접근 P11 통제 생산부서 사용자 또는 접근부서를 시스템관리

지정하여 기록물 접근권한을 서비스 부여하는 기능 P11 접근범위 현재 기록물의 접근범위에 대한 대상현황 시스템관리 재분류 현황을 제공하는 기능 서비스 처리과와 기록관에서 접근범위 P11 대상선정 지정이 잘 못 되어 있는 시스템관리 기록물을 등록하는 기능 서비스 접근범위재분류 대상으로 지정된 기록물에 대해 P11 의견등록 처리부서의견과 시스템관리 전문요원의견을 순차적으로 서비스 통제 처리하는 기능

335

프로 차세대 대기능 중기능 소기능 설명 기록관리 세스 서비스 P11 최종결과값을 시스템에 결과반영 시스템관리 반영하기 위한 기능 서비스 접근범위유형별 선정한 건수에 P11 접근범위재분 대하여 선정구분별로 재분류한 시스템관리 류현황 접근범위 유형별 통계건수를 서비스 조회하는 기능 기록관담당자 및 일반사용자의 P11 사용자별 감사추적 기록물 작업내용 및 일시 등을 시스템관리 추적 조회 확인할 수 있는 기능 서비스 기록관담당자 및 일반사용자의 P11 기록물별 기록물 접근이력 조회 확인할 시스템관리 추적 수 있는 기능 서비스 P11 기록물철의 이동현황을 위치추적 시스템관리 조회/확인할 수 있는 기능 서비스

추적데이터를 주기별로 P11 감사추적데이 문서화하는 기능을 수행하는 시스템관리 터 문서화 기능 서비스

<표 153 > 중앙기록관리시스템 현행 기능과 차세대 기록관리 서비스 대응

7. 차세대 영구기록관리시스템 설계

7.1. 영구기록물관리시스템 기능 요건 분석

가. 데이터 관리

구분 기능 요건

영구기록관리시스템은 “NAK/S 8 기록관리 메타데이터 표준”(이하 “메타데이터 표준”이라 한다)을 수용할 수 있도록 확장성 있게 구축되어야 한다.

영구기록관리시스템은 각 기록관리 업무 단계에 적합한 메타데이터를 제공하고 관리할 수 있는 기능을 제공하여야 한다. 메타데이터 영구기록관리시스템은 각각의 분류계층에 적용되는 메타데이터 요소를 확장할 수 있도록 구현하여야 한다. 기록의 유형별로 메타데이터 요소를 다르게 구성할 수 있어야 하며 변경할 수 있어야 한다. 메타데이터의 생성과 변경 등은 엄격한 통제를 위해 해당 권한이 있는 사용자에

336

구분 기능 요건 의해서만 실행 가능해야 하며, 모든 행위 내역은 감사 증적할 수 있어야 한다. 메타데이터의 중복 생산을 방지하기 위해, 기록물의 상위계층으로부터 메타데이터 요소를 상속받거나 동일한 메타데이터 요소를 재사용할 수 있어야 한다.

모든 메타데이터 요소는 필수 및 선택요소로 구분되어야 하며, 등록자가 필수 메타데이터 항목을 누락했을 경우, 이를 경고할 수 있어야 한다.

메타데이터 표준에 메타데이터 요소의 선택 값이 미리 정의되어 있는 경우, 사용자가 리스트에서 해당 값을 선택할 수 있는 사용자 인터페이스를 제공하여야 한다.

기록관리시스템으로부터 인수한 메타데이터는 영구기록관리시스템의 메타데이터로 재사용할 수 있어야 한다.

문자, 숫자, 날짜, 통화 등 사전에 정의 가능한 메타데이터 요소 값의 형식은 표준 형식으로 자동 생성하거나 변환할 수 있어야 한다.

메타데이터 요소 값의 입력범위는 초기 값을 변경할 수 있도록 구현하여야 하며, 입력범위를 초과한 오류에 대해서는 사용자에게 경고하고 처리되지 않도록 하여야 한다. 메타데이터의 생성 및 변경과 관련된 모든 행위에 대하여 행위자, 행위일시, 변경사유 등을 반드시 자동 또는 수동으로 입력되도록 구현하여야 한다. 메타데이터 메타데이터의 생성 및 변경과 관련된 모든 행위는 감사 증적할 수 있어야 한다.

메타데이터 요소 및 요소 값은 영구기록관리시스템을 통해 관리하고 검색 및 정렬이 가능하도록 지원하여야 한다.

기록물 활용을 위해 제공할 수 있는 메타데이터는 검색엔진과 같은 별도의 지원시스템과 연계가 가능하여야 한다.

사용자 및 사용자 그룹 별 접근 권한에 따라 접근할 수 있는 메타데이터 요소에 차이를 줄 수 있는 기능을 제공하여야 한다.

영구기록관리시스템은 검색의 정확성을 높이기 위하여 검색에 활용하는 메타데이터를 한정할 수 있는 필터링 기능을 제공하여야 한다.

영구기록물관리기관의 특성에 따라 메타데이터 표준에서 정의되지 않은 메타데이터 요소를 새로 추가할 수 있다.

영구기록관리시스템은 메타데이터, 분류체계, 기록관리기준 정보 등 기록물의 구조와 내용에 대한 정보를 축적하여 활용할 수 있어야 한다.

영구기록관리시스템은 스키마의 계층 구조를 가져오기(import)하거나 보내기(export)하는 기능을 제공할 수 있다.

영구기록관리시스템은 기록물의 공개재분류, 보존기간 재평가, 정리․기술, 보존포맷변환 등과 같이 기록관리 업무 수행과정에서 생산하거나 변경된 메타데이터와 그 변경 이력을 확인 및 관리할 수 있어야한다.

메타데이터 메타데이터의 등록․변경과 관련한 인터페이스에서는 다음 보기와 같은 기능이

337

구분 기능 요건

제공되어야 한다.

각각의 등록 인터페이스에서 입력해야 하는 메타데이터 요소는 필수 및 선택 옵션으로 구별되어야 한다.

필수 메타데이터 요소를 누락한 상태에서는 다음 단계로 진행할 수 없도록 하여야 한다.

계층별 기록물 분류와 기록물군, 기록물계열 등 계층별로 집합적 기술을 수행할 수 있는 기능을 지원하여야 한다. 외부시스템에서 분류체계를 내용과 구조의 훼손 없이 들여오기(import)할 수 있어야 한다. 사용자의 편의를 고려한 인터페이스로 분류체계를 표현할 수 있어야하며, 분류체계를 이용한 다양한 기록물 검색이 가능하여야 한다.

다계층으로 구성된 분류체계를 적용할 수 있어야 하며, 이 때 분류계층의 수가 제한되어서는 안 된다.

분류체계 아래에 기록물 관리의 기본 단위가 되는 기록물철을 둘 수 있어야 한다.

필요에 따라 기본 분류체계 외에 다른 분류체계를 추가로 관리할 수 있어야 하며 기록물의 다중 분류가 가능하도록 지원할 수 있어야 한다.

모든 분류계층은 식별 및 관리를 위한 고유 식별자를 부여받아야 하며, 고유 식별자는 분류체계 중복되지 않도록 자동으로 부여되어야 한다.

각각의 분류계층 이름은 명명규칙에 의해 통제되어야 한다.

분류체계 전체 및 분류체계 내의 각 계층에 대한 메타데이터를 기술할 수 있어야 한다.

각 분류계층에 부여된 메타데이터는 사용자 인터페이스로 제공되어야한다

하나의 전자기록물철 내에 포함시킬 수 있는 기록물의 수는 기본 값으로 제한하지 말아야 하나, 허가된 사용자에 한해, 선택적(업무적 또는 시스템의 성능적인 이유)으로 기록물 건수를 제한할 수 있어야 한다.

영구기록관리시스템으로 인수된 모든 기록물들은 최소한 한 개 이상의 분류계층에 포함되어야 한다.

영구기록관리시스템은 기록물 및 기록물의 집합(분류계층)에 대해 시스템 내에서 유일한 고유 식별자를 할당할 수 있어야 한다.

식별체계 할당된 고유 식별자는 메타데이터 요소로 저장, 관리, 검색될 수 있어야 한다.

식별자는 숫자, 알파벳, 한글 등의 조합을 지원할 수 있어야 한다.

식별자는 영구기록물관리기관이 정한 방식에 따라 영구기록관리시스템에 자동 할당 식별체계 방식으로 생성할 수 있어야 한다.

338

구분 기능 요건

식별체계의 구성, 의미, 사용방법 등에 대한 도움말 기능을 제공할 수 있다.

서로 다른 식별체계를 가진 기록물이 인수되었을 경우에도 영구기록관리시스템에서 정한 식별체계로의 변환이 가능하여야 한다.

식별자는 그 자체만으로 검색도구로써 활용될 수 있어야 한다.

복잡한 체계의 식별자의 경우, 간략한 형식으로 변환하여 사용자에게 제공할 수 있다.

<표 154> 데이터 관리 기능요건

나. 인수

구분 기능 요건

영구기록관리시스템은 외부시스템으로부터 기록물과 메타데이터를 시스템 간 연계 및 교환 규격에 따라 인수받을 수 있어야 한다.

영구기록관리시스템은 다양한 유형의 전자기록물을 그 유형과 수에 상관없이 시스템으로 인수할 수 있어야 한다.

외부 시스템에서 전자기록물을 들여오기(import)하는 경우, 해당 시스템과 직접 연계하여 온라인으로 전송받거나 오프라인으로 이관매체 등을 통해 접수한 파일을 직접 등록할 수 있는 기능을 제공해야 한다.

기록물 인수 시 메타데이터 오류, 바이러스 등 품질검사 및 기록물 검수 기능이 제공되어야 한다.

전자기록물 인수시 진본성, 무결성 등을 보장하기 위해 부여된 행정전자서명 및 인수 시점확인정보를 검증하고 그 결과를 관리할 수 있어야 한다. 인수되는 기록물에 부여된 행정전자서명의 장기 검증을 위해 전자서명장기검증체계와 연계하는 기능을 제공할 수 있다.

기록물 및 메타데이터에 오류가 있거나 진본성 확인이 어려운 경우, 오류사항 및 미비사항을 기록관에 통보하는 기능과 수정・보완된 기록물을 재인수받을 수 있는 기능을 제공하여야 한다.

인수 절차가 완료되면 기록물을 이관한 기관에게 인수 완료에 대한 정보를 제공할 수 있어야 한다.

영구기록관리시스템은 이관대상 기록물의 목록을 접수할 수 있어야 한다. 이관대상 기록물 목록과 실제 이관 받은 기록물을 비교할 수 있는 기능을 제공하여야

인수 한다. 전자적 형태로 생산되지 아니한 기록물을 인수받을 경우에 원본 및 목록일치 여부,

339

구분 기능 요건 물리적 상태확인 등을 할 수 있는 검수기능을 제공하여야 한다. 인수 완료된 기록물 현황에 대한 통계기능을 제공하여야 한다.

수집된 기록물 중 필요한 경우 기록물의 소유권 및 이용에 대한 법적인 권한을 관리하고 조회할 수 있어야 한다.

진본성 확인 및 오류검증이 완료된 전자기록물에 대한 접근은 시스템관리자에 의해 엄격하게 통제되어야 한다.

영구기록관리시스템은 전자기록생산시스템 또는 기록관리시스템으로부터 대량의 전자기록물을 일괄 인수할 수 있어야 한다.

전자기록물은 내용․구조․맥락의 훼손 없이 포맷과 연관관계를 유지한 상태로 인수하여야 한다. 기록물의 일괄 인수 시 메타데이터 또한 일괄 획득이 가능하여야 하며, 시스템은 오류 발생여부를 점검할 수 있어야 한다.

일괄 인수된 기록물과 메타데이터는 해당기관이 정한 방식에 따라 일관성 있게 등록되고 관리되어야 한다.

영구기록관리시스템은 기록관 및 특수기록관에서 이관 연장이나 조기이관 등을 요청할 경우 이관시기를 조정하여 이관목록을 확정할 수 있는 기능을 제공하여야 하며, 이관 연장한 기록물의 이관시기가 경과한 경우 이를 조회할 수 있는 기능을 제공하여야 한다.

영구기록관리시스템은 수집한 기록물에 대하여 인수된 기록물과는 별도의 기준으로 관리할 수 있어야 한다.

영구기록관리시스템은 수집된 기록물의 위치․소장자․연락처 등의 소장처(자) 정보, 수집을 완료하기까지의 협의․협상 과정 등을 명시한 접촉정보, 소유권 이전․부분 이전․위탁보관․조건부 사용권․유상 열람대상 등의 법적권한 정보를 관리할 수 있는 협약관리 기능을 제공하여야 하며, 협약관리에 대한 변경 이력은 메타데이터 등으로 관리되어야 한다.

수집한 기록물은 수집처 별로 검색하거나 정렬할 수 있어야 한다.

수집 수집을 완료한 기록물 현황의 통계기능을 제공하여야 한다.

수집한 기록물은 구입, 기증, 위탁 등의 수집 유형에 따라 관리될 수 있어야 하며, 협약관리와 연계되어야 한다.

수집한 기록물의 유형에 따라 사전에 정해진 형식으로 기증서, 확인서, 계약서 등을 출력하는 기능 제공이 권장된다.

수집한 기록물에 대한 법적인 권한을 확보하지 못한 경우에는, 그 활용범위에 대한 정보를 제공할 수 있어야 한다.

수집을 완료한 기록물은 그 관리 및 이용에 대한 법적인 권한을 관리 및 조회할 수 수집 있는 기능을 제공하여야 한다.

340

구분 기능 요건

수집한 기록물은 이관된 기록물과 통합적으로 검색 및 관리될 수 있어야 한다.

법적 권한과 관련된 협약서, 계약서, 증서 등은 관련 기록물 정보와 함께 저장할 수 있어야 한다.

이관 또는 수집된 모든 기록물은 해당기관이 정한 방식에 따라 시스템에 등록할 수 있어야 하며, 등록에 필요한 인터페이스를 제공하여야 한다.

기록물 계층별 메타데이터 등록이 가능하여야 한다.

등록 기록물 계층별로 해당 기관의 분류체계와 연계할 수 있어야 한다. 기록물의 메타데이터 상태는 등록 기능에서 확인 및 통제할 수 있어야한다.

등록된 기록물 데이터는 임의 수정, 삭제, 변경이 불가하여야 한다.

기록물은 등록과 동시에 고유의 식별자가 부여되어야 한다.

<표 155> 인수 기능요건

다. 저장과 보존처리

구분 기능 요건

저장장치 혹은 매체의 유형을 선택할 수 있어야 하고, 저장 공간이 충분한지 확인할 수 있어야 한다.

저장장치에 저장이 완료된 전자기록물은 관리를 위한 위치정보 등을 부여하고 메타데이터로 관리하여야 한다.

저장장치에 저장 시에는 저장 진행상태 및 완료 상태를 실시간 확인 기능을 제공할 수 있다.

영구기록물관리기관의 장기보존 정책에 따른 저장매체의 이전, 마이그레이션 수행 이력을 메타데이터로 관리할 수 있어야 한다.

해당 기관의 정책에 따라 하드웨어나 소프트웨어에 대한 마이그레이션을 수행할 수 저장 있어야 하며, 마이그레이션의 이력사항은 감사증적으로 관리하여야 한다.

저장공간 관리정책, 이용률, 전자기록물의 중요도 등에 따라 물리적인저장매체의 위치를 조정할 수 있어야 한다.

저장매체의 종류는 추가 및 변경이 가능하도록 조정할 수 있어야 한다.

저장매체의 재고현황과 이용 가능한 저장 용량을 모니터링 할 수 있어야 하며, 보고서 형식으로 출력할 수 있어야 한다.

저장을 위해 전자기록물이 전송되는 동안 발생한 오류가 있었는지 로그를 통해 확인할 수 있어야 한다. 저장 오류가 발생하는 경우 재전송할 수 있는 기능을 제공하여야 한다.

341

구분 기능 요건

일련의 저장 절차가 진행되는 동안 기록물과 메타데이터는 무결하게 유지되어야 한다.

저장이 완료된 후에도 전자기록물의 상태검사를 위해 저장장치에 수록된 전자파일에 대한 이용가능성ㆍ손상여부 등을 주기적으로 검사할 수 있는 기능 및 검사 도구를 제공해야 한다.

전자기록물의 상태검사 결과에 따라 오류 발생 시에는 오류사항의 처리와 관련된 조치내역을 관리하여야 하며, 장기보존포맷으로 재수록한 경우에는 행정전자서명 및 시점확인 정보를 추가할 수 있어야 한다.

저장장치의 이상 유무 등을 확인하고, 이상발생 시 관리자에게 통보해주는 기능을 제공해야 한다.

영구기록관리시스템은 장기보존을 위하여 기록물을 수록하고 있는 매체에 대한 매체의 종류와 수명, 기록물의 수록시기, 물리적 위치를 구분하여 제공하여야 한다.

수명 종료일이 도래하는 매체에 대해서는 사전에 알림메시지를 제공하여야 하며, 자동으로 매체이전 대상으로 분류될 수 있어야 한다. 매체이전을 위해 별도의 지원시스템이 존재하는 경우, 지원시스템과 연계하여 매체이전 과정에 대한 자동화가 권장된다. 매체이전

매체이전이 완료되면 매체의 수명 종료일에 따라 자동으로 다음 매체이전 시기가 설정되어야 한다.

영구기록관리시스템은 매체이전 일정과 관계없이 수동으로도 매체이전을 수행할 수 있어야 한다.

완료된 매체이전의 결과를 확인 및 출력할 수 있어야 한다.

영구기록관리시스템은 문서보존포맷과 장기보존포맷 변환을 위한 일련의 관리기능을 제공하여야 한다.

인수된 전자기록물이 보존포맷 형태가 아닌 경우, 해당 기록물을 보존포맷으로 변환할 수 있어야 한다.

영구기록관리시스템은 포맷변환을 위해 별도의 서브시스템을 구성하는경우, 이에 필요한 연계기능을 지원하여야 한다.

포맷변환 인수된 전자기록물을 일괄 또는 개별적으로 선택하여 보존포맷으로 재변환할 수 있어야 한다.

보존포맷에 대한 기술정보(technical information) 및 재현정보(reproduction information)를 담고 있는 메타데이터를 추가할 수 있는 기능을 제공해야 한다.

보존포맷으로 변환된 전자기록물과 변환되지 않은 전자기록물의 상태를 표시하여 관리자가 구분할 수 있어야 한다. 포맷변환 영구기록관리시스템은 포맷변환 전과 후의 전자기록물을 비교하여 무결성을 점검하는

342

구분 기능 요건 기능을 제공하여야 한다. 8 보존포맷의 생성, 오류, 관리에 대한 정보는 시스템 로그에 축적되어 감사증적에 이용될 수 있어야 한다.

포맷변환 중 오류가 발생한 경우, 다시 변환을 시도할 수 있는 기능을제공하여야 한다.

변환이 완료된 보존포맷은 저장매체로 개별 및 일괄 저장이 가능해야한다.

문서보존포맷과는 별도로 열람 서비스를 위한 포맷 변환을 지원할 수 있어야 한다.

관리정보의 현행화를 위해 장기보존포맷을 주기적으로 재변환하는 기능을 제공하여야 하며, 행정전자서명 및 시점확인 정보를 추가하여야한다.

전자서명의 유효성을 지속적으로 검증할 수 있는 장기검증시스템과연계를 위한 API를 지원하여야 한다.

재난에 대비하여 중요 전자기록물을 물리적으로 다른 저장매체에 백업하고 복구하는 기능을 제공해야 한다.

백업은 기록물건, 기록물철, 메타데이터와 함께 시스템 정보를 포함하여야 하며, 정기적이고 자동적인 백업 및 복구절차를 지원하여야 한다.

영구기록관리시스템은 다음과 같은 백업기능을 지정할 수 있어야 한다.

백업 및 시스템 관리자만이 진본성과 무결성이 보장된 백업본을 통해 복구할 수 있도록 복구 통제하고, 복구 후 데이터의 무결성을 검증하고 유지할 수 있는 기능을 제공해야 한다. 재난복구를 위해 기록물 및 메타데이터를 선택 또는 일괄적으로 복제하는 기능을 제공하여야 한다.

관리 정책에 따라 필요 시 백업된 매체로부터 부분 또는 전체를 복구할 수 있어야 한다.

복구가 불완전하게 이루어진 경우, 영구기록관리시스템은 이를 시스템 관리자에게 통보할 수 있어야 한다.

보존기간이 만료될 때까지 해당 전자기록물의 무결성이 지속적으로 보장될 수 있도록 보존 관리하여야 한다.

시스템 업그레이드, 마이그레이션, 변환 등 보존처리작업을 수행하는 경우 전자기록물의 데이터가 유실되거나 손상되지 않도록 하여야 한다. 전자기록물 보존관리 전자기록물의 손상 여부를 확인할 수 있어야 하고 손상된 전자기록물은 백업본 등을 이용하여 온전한 전자기록물로 대체할 수 있어야 한다.

전자기록물의 사본에 대해 메타데이터 표준에 따라 기록물 정보를 등록할 수 있도록 하여야 하며, “관계“ 메타데이터 요소를 이용하여 원본과 사본 등의 관계를 제공할 수 있어야 한다.

전자기록물 전자기록물의 수량, 용량 등에 대한 정수 여부와 기록물의 무결성 유지여부 등에 대한 보존관리 상태를 자동으로 점검하고 그 결과를 메타데이터로 관리할 수 있도록 기능을 제공할

343

구분 기능 요건 수 있다. 전자기록물의 상태를 검사하는 경우에는 저장장치에 수록된 전자파일에 대한 이용 가능성 및 손상여부 등에 대한 주기적 검사와 저장장치의 유무 등을 확인하여야 한다.

상태검사를 통하여 오류사항이 발견된 경우 즉시 복구하여야 하며, 오류사항의 처리와 관련된 조치내역을 관리하여야 한다.

영구기록관리시스템은 전자기록물과 비전자기록물의 메타데이터 요소를 서로 다르게 지정할 수 있도록 하여야 한다.

비전자기록물은 전자기록물과 동일하게 접근을 통제하고 그 정보를 보고서 형식으로 제공할 수 있는 기능을 제공하여야 한다. 비밀등급이 부여된 비전자기록물에 대한 보안 관제와 같은 물리적 모니터링을 위한 시스템과의 연계가 가능하여야 한다. 비전자기록물에 대한 접근은 물리적으로 보존하고 있는 서고관리 기능과 연계되어야 한다. 영구기록관리시스템은 비전자기록물의 디지털화 과정을 지원하여야 한다.

영구기록관리시스템은 비전자기록물의 소독․제본․탈산․복원․디지털화를 위한 처리 행위(보기: 작업스케줄링, 이력추적, 상태점검, 반출입관리, 처리결과 등록 등)를 비전자기록 관리할 수 있어야 한다. 물의 비전자기록물의 정수점검을 위해 정수점검계획서를 생성하고, 기록물 철별로 점검 보존관리 결과를 등록할 수 있어야 한다.

영구기록관리시스템은 비전자기록물의 관리를 위하여 서고관리 기능을 구현하여야 한다.

서고관리 기능에서는 기록물의 물리적 배치상태와 동일한 서가배치 정보를 입력․조회․변경할 수 있어야 한다.

입력된 서가배치 정보에 따라 보존 상자에 부착하는 라벨의 출력을 지원할 수 있어야 한다.

비전자기록물의 효율적 관리를 위한 시스템(바코드, RFID 등)이 구축․운용되는 경우, 서고관리 기능과 연계되어야 한다.

반입 및 반출 절차를 지원하고 현황을 관리할 수 있는 기능을 제공할 수 있어야 한다.

<표 156> 저장과 보존처리 기능요건

라. 처분

구분 기능 요건

영구기록관리시스템은 보존기간, 폐기일 등 처분기준의 요소를 추가하거나 삭제가 처분실행 가능하도록 구현되어야 한다.

344

구분 기능 요건

기록물에 대한 처분은 기록물철 단위로( 할당할 수 있어야 한다.

기록물철 내의 모든 기록물은 해당 기록물철에 할당된 처분기준을 상속받을 수 있도록 하여야 한다. 기록관리시스템에 적용된 보존기간을 영구기록관리시스템에서 처분행위의 기본 값으로 수용할 수 있어야 한다.

영구기록관리시스템은 처분행위에 필요한 다음과 같은 절차를 지원해야 한다.

권한이 부여된 담당자에 한해 기록물철의 처분동결 설정 기능을 제공하여야 한다.

처분동결이 설정된 기록물철은 일체의 처분행위를 실행할 수 없어야한다.

처분행위에 의해 변경된 일체의 정보는 메타데이터로 관리 및 검색될 수 있어야 한다.

영구기록관리시스템은 처분행위 유형별로 검색․정렬․목록보내기(export) 기능을 제공하여야 한다.

기록물에 대한 삭제 및 변경이 발생한 경우에는 다음의 사항을 수행하여야 한다. 기록물건이나 기록물철을 삭제 또는 변경할 때에는 다른 기록물건 또는 기록물철과의 맥락 관계 설정 여부를 처분업무 담당자가 확인할 수 있도록 관련 정보를 제공하여야 한다. 영구기록관리시스템은 보존기간이 만료된 기록물의 보존가치를 평가하여 보존기간을 재책정하거나 보류 또는 폐기로 구분하여 관리할 수 있어야 한다. 보존기간 영구기록관리시스템은 보류로 구분된 기록물을 주기적으로 보존가치를 재평가하는 재책정 및 기능을 제공하여야 한다. 보류 영구기록관리시스템은 생산기관의 의견조회 결과 및 기록물평가심의회심의결과를 관리하는 기능을 제공할 수 있다.

처분기준에 따라 폐기로 결정된 폐기대상 기록물 또는 기록물철은 별도 관리될 수 있어야 한다.

폐기대상 및 폐기 완료된 기록물철은 목록으로 조회할 수 있어야 하며, 보고서 형식으로 출력할 수 있어야 한다.

폐기 완료된 기록물건 및 기록물철의 경우에도 메타데이터는 삭제되지 않아야 하며, 폐기 폐기결과는 메타데이터 정보에 자동으로 기록되어야 한다. 폐기 대상 기록물의 폐기 실행은 폐기업무 담당자에 의해서만 수행되어야 한다.

폐기 실행은 1차 복구 가능한 삭제, 2차 완전삭제와 같이 단계별로 구분하여 실행할 수 있도록 기능을 제공할 수 있다. 전자기록물의 폐기 시에는 문서보존포맷, 장기보존포맷, 사본과 같은 해당 전자기록물의 모든 대안적 표현물도 함께 폐기되도록 해야 한다.

<표 157> 처분 기능요건

345

마. 공개관리 및 기록물 기술

구분 기능 요건

기록물 건 단위로 공개여부를 구분하여 관리할 수 있는 기능을 제공하여야 한다.

비공개기록물의 5년주기 재분류, 30년경과 비공개기록물의 재분류, 열람활용(정보공개청구) 등 기록관리 절차에 따라 기록물의 공개여부를 재분류할 수 있는 기능을 제공하여 한다. 생산부서 의견 조회, 공개재분류 심의(기록물공개심의회, 국가기록관리위원회) 등 기록물의공개재분류 검토 절차별 검토일시, 검토의견, 검토결과를 메타데이터로 공개관리 관리할 수 있다. 비공개 기록물 중 공개일시가 설정된 기록물에 대해 공개일시 알림, 재분류 검토 등의 기능을 제공할 수 있다. 부분공개 기록물에 대해 개인정보 등 비공개되어야 하는 정보를 제거하거나 숨김 처리를 한 부분공개 사본을 생성하고 관리하는 기능을 제공할 수 있다. 기록물 유형별로 ‘기록물 공개재분류 기준서’를 작성하고, 기록물철(건)별로 ‘기록물 공개재분류 검토서’를 작성하여 관리할 수 있는 기능을제공할 수 있다.

보존기록물의 공개 및 열람편의를 제공하기 위하여 기록물을 기술(記述)할 수 있는 기록물 기능을 제공하여야 한다. 기술 기록물의 계층별로 구조, 맥락 및 내용에 대한 정보를 표준화된 형식에 따라 기록할 수 있는 기능을 제공하여야 하며, 이를 메타데이터로 관리하여야 한다.

<표 158> 공개관리 및 기록물기술 기능요건 바. 검색 및 활용

구분 기능 요건

사용자가 키워드를 사용하여 전체 기록물을 통합 검색할 수 있도록 제공하여야 한다.

단순 키워드 검색에서 상세검색까지 다양한 검색기능을 제공하여야한다.

검색 기록물의 유형·일자·검색범위 등을 조건으로 검색할 수 있어야 한다. 서비스 검색 결과 기록물 목록은 사용자가 지정하는 메타데이터 요소별로 정렬될 수 있어야 한다.

검색 결과 목록은 인쇄 및 저장 가능한 포맷(ex. 엑셀 등)으로 보내기(export)할 수 있는 기능을 제공하여야 한다.

해당 기관의 분류체계에 따라 계층별로 브라우징할 수 있는 기록물검색 인터페이스를 제공하여야 한다.

분류체계에 따른 브라우징 검색 시는 해당되는 계층의 기록물과 메타데이터를

346

구분 기능 요건 제공하고, 상·하위 계층, 관련계층과 연계하여 편리하게 이동할 수 있어야 한다. 기록물 원문이 온라인에서 열람 가능한 상태라면 열람제공에 적합한 형태로 가공하여 검색 사용자에게 제공할 수 있어야 한다. 서비스 계층별 탐색 기능은 동작 시에 전체 시스템의 데이터 처리 성능을 저하시키지 않도록 설계되어야 한다.

영구기록관리시스템은 기본적으로 제공하는 검색도구 이외에 검색보조도구를 활용할 수 있도록 설계되어야 한다.

기관의 정책에 따라 시소러스, 전거제어, 온톨로지, 토픽맵 등을 검색보조도구로 활용할 수 있다.

검색 선택된 검색보조도구는 영구기록관리시스템에서 자동화된 방식으로 활용할 수 있도록 보조도구 설계되어야 한다.

검색 보조도구는 동작 시 영구기록관리시스템 전체의 데이터 처리 성능을 저하시키지 않도록 설계되어야 한다.

검색 보조도구는 사용자가 직관적으로 이용할 수 있는 인터페이스로제공하는 것이 바람직하다.

기관이나 조직의 특성, 열람 프로세스에 따라 열람업무를 지원할 수 있어야 한다.

공개가능한 모든 기록물에 대하여 열람 및 복제를 지원할 수 있어야 한다.

기록물 검색을 통해 편리하게 열람할 수 있는 인터페이스를 제공하여야 한다.

검색된 목록은 일부 또는 전체를 선택하여 인쇄 및 저장 가능한 형식으로 출력할 수 있어야 한다.

열람 원문을 제공하지 않는 비전자기록물에 대한 열람을 신청할 수 있어야하며, 열람 신청정보는 열람담당자에게 제공될 수 있어야 한다.

열람 신청된 기록물은 서고관리 기능과 연계되어 반출 또는 사본제작의뢰가 가능하여야 한다.

열람업무와 관련한 제반 현황을 확인할 수 있어야 하며, 오프라인 관리를 위한 현황출력 기능을 제공해야 한다.

원래의 전자기록물은 훼손되지 않게 유지하면서 개인정보 등의 민감한 정보를 제거하거나 숨김 처리를 하여 전자기록물의 부분공개사본을 생성할 수 있도록 허용해야 하며, 부분공개사본을 등록하여 관리할 수 있어야 한다.

외부 시스템과 기록물 목록정보 등을 연계하는 기능을 제공할 수 있다.

347

구분 기능 요건

접근이 허용된 사용자는 보고서를 화면으로 출력, 인쇄, 파일로 다운로드 할 수 있도록 해야 한다.

시스템이 처리한 모든 처분 행위에 대해 보고서를 생성할 수 있어야한다.

정기적인 시스템 운영 보고서, 각종 통계보고서, 일시적 필요에 의한 보고서 등을 생성할 수 있다.

보고서 및 기록물의 소장현황과 기록관리 업무현황에 대한 통계정보를 제공할 수 있어야 한다. 통계 관리 기록물의 통계는 숫자 및 그래픽 형식의 인터페이스를 제공하여야 한다.

기록물의 소장현황 통계는 다음의 조건에 따라 표현될 수 있어야 한다.

통계기능은 다음의 기록관리 업무현황에 대하여 정해진 조건에 따라 표현될 수 있어야 한다.

기관의 업무 특성에 따라 필요한 통계 기능이 쉽게 추가되도록 설계되어야 한다.

<표 159> 검색 및 활용 기능요건

사. 접근권한 및 감사증적

구분 기능 요건

영구기록관리시스템의 관리자는 특정 사용자 및 사용자그룹에 대하여 기록물, 기록물계층, 메타데이터, 시스템에 대한 접근을 제한할 수 있어야 한다.

사용자 및 사용자그룹의 접근권한은 사용자 프로파일에 저장하거나, 변경, 삭제, 비활성화를 할 수 있어야 한다.

사용자별로 정해진 기간 혹은 특정 시간대별로 시스템 사용이나 업무행위의 접근을 제한할 수 있어야 한다.

접근권한 사용자 보안등급에 따라 특정기능별로 접근을 제한할 수 있어야 한다. 관리 사용자 접근통제와 관련된 보안조치는 시스템관리자에 의해서만 부여될 수 있어야 한다. 모든 사용자의 접근은 자동으로 감사 증적을 남기고, 허가되지 않은 사용자의 접근은 관리자에게 경고 메시지로 제공되어야 한다.

분류계층의 상위 레벨에 접근할 수 있도록 설정된 사용자 권한은 하위 레벨에 대한 권한을 포함하도록 하여야 한다.

영구기록관리시스템은 사용자의 계정을 생성․유지․변경․삭제하고 해당 계정 정보를 관리하는 기능을 제공하여야 한다.

계정에 따라 기능별 접근권한을 다르게 설정할 수 있어야 한다.

사용자 계정은 그룹별로 정의하여 권한을 부여할 수 있어야 한다.

348

구분 기능 요건

영구기록관리시스템은 별도의 로그분석 도구를 이용하여 사용자별, 기록물별, 일자별 접근현황 통계를 작성할 수 있어야 한다.

영구기록관리시스템은 기록물 및 접근자를 기준으로 기록물 내용 및 목록정보로

접근권한 구분하여 관리하여 접근범위를 설정하는 기능을 제공하여야 한다. 관리 영구기록관리시스템은 생산․보존하고 있는 기록물에 대한 접근․접근시도에 관한 사항, 이력정보 등을 관리할 수 있는 기능을 제공하여야 한다.

접근이력, 처리상황 등의 관리 정보는 자동 생성되도록 해야 하며, 임의로 수정․삭제할 수 없도록 해야 한다.

영구기록관리시스템은 기록물, 분류체계, 메타데이터, 시스템에 대한 모든 종류의 접근을 감사증적 정보로 남겨야 하며, 이 경우 감사증적정보는 변경, 삭제 등 변경이 불가능한 형태로 생산․관리되어야 한다.

기록물 접근에 대한 감사증적 정보는 최소한 다음과 같은 요소들로 구성되어야 한다.

영구기록관리시스템은 다음의 행위들에 대한 감사증적 정보를 저장하고 검색할 수 있어야 한다. 감사증적을 위한 로그는 일정기간 유지할 수 있어야 하며, 선택적으로 별도 저장이 가능하여야 한다. 감사증적 감사증적 정보는 훼손 없이 표준화된 포맷으로 보내기(export)를 할 수 있어야 한다.

감사증적 정보는 다음과 같은 기준으로 보고서 형식의 출력을 지원하여야 한다.

전자기록물의 이동시 다음과 같은 정보를 자동으로 남겨야 한다.

영구기록관리시스템은 전자기록물의 인수 이후 진본성 및 무결성을 손상시키는 어떠한 행위에 대해서도 경고메시지를 통지하여야 하며 감사증적 정보를 남겨야 한다.

<표 160> 접근권한 및 감사증적

아. 시스템 관리

구분 기능 요건

시스템 운영체제에서 기본적으로 제공하는 다음과 같은 기능을 사용할 수 있어야 한다. 시스템 다양한 네트워크 환경에서 데이터 통신과 애플리케이션들의 상호 운용성을 지원할 수 운영 있는 메커니즘과 확장성을 지원해야 한다.

데이터 통신을 위해 필요한 신뢰할만한 애플리케이션 API와 프로토콜을 수용할 수 있어야 한다.

349

구분 기능 요건

서로 다른 네트워크 환경에 위치한 파일에 접근할 수 있도록 지원하여야 한다.

시스템 내의 민감한 정보자원을 보호할 수 있는 메커니즘과 확장성을제공하여야 한다.

영구기록관리시스템은 전체 시스템을 지속적으로 모니터링하고 시스템 설정의 변경을 통제할 수 있어야 한다.

시스템의 운영체제, 성능, 이용률에 대한 모든 정보를 감사증적 할 수 있도록 로그에 축적하여야 한다. 시스템 운영 저장장치, 데이터 이용률, 성능 등에 관한 정보를 정기적으로 수집하여 시스템적 통계를 제공하여야 한다.

재난으로부터 전자기록물의 손실을 방지하고 복구하기 위해 필요한 기능 혹은 서브시스템을 제공하여야 한다.

시스템 장애를 예방하고 대응하기 위해 예상되는 각종 위험요소를 상시 자동으로 모니터링하고 탐지할 수 있어야 한다.

시스템 장애 발생 시 자동으로 관리자에게 즉시 통보할 수 있어야 한다.

<표 161> 시스템 관리

7.2. 영구기록물관리시스템 해외 사례

가. ERA

○ 개요

NARA와 연방기관이 생산하고 있는 다양한 유형의 전자기록을 통합적인 구조로 관리하고 미래의 전자기록 환경에서 지속적으로 보존과 이용을 보장하기 위한 소프트웨어, 하드웨어, 메타데이터 모델, 접근도구 등의 통합체계 개발 프로젝트

○ 진행과정

1969 - 1993 : 형성과 정체, 그리고 회춘기

· 1970년부터 1988년 사이 6,000개의 데이터 파일이 NARA에 이관되어 초기 컴퓨터시스템에 평면 데이터베이스와 ASCII 레코드로 보관됨

· 1989년 전후로 보존과 관리를 위한 두 개의 새로운 시스템(APS, AERIC)을 개발하여 14,000개 이상의 전자기록을 입수함

1993 : 암스트롱 vs 대통령비서실(EOP)

350

· 1993년 NARA가 암스트롱 대 대통령비서실 소송의 공동피고가 되며 이메일 등 복잡한 유형의 전자기록 관리 이슈가 크게 부각됨

1998 : 전자정부가 미래의 아카이브에 투자

· 전자정부 환경 도래로 전자기록 생산이 증가하며 대시민 정보서비스 기술 등 발전하고, NARA는 2000년 클린턴 행정부 종료 시 이관될 전자기록의 방대한 양과 기술적 복잡성을 대비하여 ERA 프로그램(연구/협력)을 시작함

2000 : ERA 프로그램 관리사무소 개소

· NARA는 ERA 시스템 개발에 10년을 계획하고 컴퓨터과학, 정보관리, 정보기술, 도서관, 학술, 공공 부문의 주요 파트너를 선정하여 연구조사를 통해 NARA의 요구사항을 수립

2004 : 개발업체 선정, 자문위원회 설립

· 해리스와 록히드마틴은 1년 동안 ERA 시스템 프로토타입 설계 경쟁을 했고, 2005년 록히드 마틴이 선정됨

· 2005년 NARA는 ERA자문위원회 설립

· 2007년 4개 연방기관이 ERA 초기버전 도입(특허청, 원자력안전관리국, 노동통계소, 해군해양사무소)

2008 : 초기 운영 단계

· 2008년 6월 ERA 시스템의 초기운영능력(IOC) 테스트를 성공적으로 치루며, NARA의 연방기록 관리를 위한 업무 프로세스 지원 및 기본 인프라 제공

2009-2011 : 개발 최종 단계

· 2009년 1월 대통령 전자기록관리를 위한 ERA의 제2모듈 배포(아래 기능 추가)

· 2009년부터 2011년까지 연방기록을 NARA로 이관, 처리, 보존, 접근 제공하기 위한 추가기능 개발과 고도화 진행

· 2012년 말까지 연방정부의 모든 기관이 ERA시스템을 이용하여 영구보존 전자/비전자 기록의 이관 일정을 자복 이관을 실행하도록 함

○ 주요 내용

ERA는 “시스템의 시스템”이며, 다양한 법적 프레임워크에 의해 생산되는 기록물 관리를 위한 4가지 주요 기능(제출, 메타데이터, 보존, 접근)을 수행

351

<그림 314> ERA 핵심기능

ERA 시스템 요구사항

· 확장가능성(Extensibility) : 레코드 유형, 데이터 유형에 따른 쉬운 서비스 추가 기능

· 발전가능성(Evolvability) : 표준API와 인터페이스를 이용한 신기술 추가

· 이용가능성(Availability) : 핵심 기능을 이용 가능

· 규모확장성(Scalability) : 레코드 양이나 이용자 커뮤니티 성장에 따른 대응 · 보안성(Security) : 시스템과 시스템 자원의 보호

· 이용자 친화성(User Friendly) : 브라우저 인터페이스, 직관성, 장애인 이용 지원

ERA 시스템 아키텍처

· 서비스 지향 아키텍처(SOA) 패러다임, 메타데이터 모델, 콘텐츠 서버로 구성

· SOA는 Planets, 호주국립도서관, 포르투갈국립아카이브의 RODA 벤치마킹

· 콘텐츠 서버는 네덜란드왕립도서관에서 사용하는 IBM의 DIAS 기반 시스템에 포함된 “Contents Manager”를 벤치마킹

아키텍처 서비스 설계 원칙

· 기능에 해당하는 서비스와 이를 전달하는 ESB(Enterprise Service Bus)로 구분

· OAIS 모델 기반 업무 서비스 설계 – 입수(Ingest), 보존(Preservation), 접근(Access) · 업무 서비스 지원을 위한 로우레벨 서비스 설계

· 표준 기반 미들웨어를 사용하는 ESB를 통해 로우레벨 서비스를 업무 서비스로 제공

· 유연성 및 확장성-서비스의 추가 및 교체 가능

입수 프로세스(Ingest Process)

· DROID, Jhove, JAI, pCOS 등 파일 식별 툴과의 통합이 가능한 구조

· 상용솔루션(COTS, Commercial Off-The-Shelf), 무료/공개소프트웨어(FOSS, Free and Open Source Software)등의 툴로 만든 웹 서비스

352

· 기존 툴을 새로운 툴로 교체 가능 · 신규 툴 추가 가능

· 도서관 및 아카이브 커뮤니티에서 개발한 오픈소스 소프트웨어 적용 가능

ERA 시스템 특징

<그림 315> ERA 검색 및 접근 제공 프로세스

나. Preservica

○ 개요

TNA는 1838년 설립된 이래 Domesday Book 컬렉션, Manga Carta 컬렉션 등 대표 컬렉션부터 근대 정부문서까지 약 1천 1백만 건의 세계 최대 규모 기록물 소장

최근의 급변한 디지털 기술 환경은 디지털 기록의 영구적 저장 및 보존에 위협

TNA는 Preservica와의 파트너십을 통해 새로운 스토리지와 보존시스템을 개발

보존시스템은 효율적 저장, 관리, 현재 컬렉션을 디지털 파일로 마이그레이션하는 작업뿐만 아니라 전자 아카이브로의 역량을 획기적으로 확장하는 계기가 됨

기록물 장기보존을 위해 Preservica 활용

가장 진화한 OAIS 기반 상용 디지털 보존 소프트웨어, 다양한 오픈소스 활용

TNA 등 유럽 국립아카이브, EC, 예일대, MoMA, AP 등 도입

353

○ 주요 특징

검색포털 커스텀 쉬움(Easy to customize Public Access)

· Universal Access 모듈 제공

· CMIS(Content Management Interoperability Services) interface

입수 자동화(Automated Ingest)

· 클라우드 벌크 업로드 서비스 제공

OAIS의 확장(Active Preservation)

· 현재 활용 가능한 형식으로 공격적 이동

· 오래된 포맷 읽기도구 제공

데이터 관리 확장(Extensive Data Management)

· 컬렉션 계층 무제한 수용

· 메타데이터 스키마 관리/편집

· OAI-PMH 발행/수집

스토리지 유연성(Storage Flexibility)

· 클라우드 에디션 : Amazon RDS(고속), Amazon S3(저 레이턴 시), Amazon Glacier (저속)호환

· Copy Home 기능 제공 : 로컬 디스크 등 외부 FTP 서버로 내보내기 가능

보안 및 운영(Security and Administration)

· 각 레코드 단위의 이용자 역할 및 접근권한 제공

· 리포트 및 대시보드 제공(입수/접근/보존활동, 파일포맷/수량 통계)

· 이용자 인증(via Microsoft Active Directory Open LDAP and SAML) · 보안 운영 각 레코드 단위의 이용자 역할 및 접근권한 제공

다. Archivematica

○ 개요

OAIS 기반의 오픈소스 디지털 보존 소프트웨어로서 디지털 보존 각 단계의 개별 프로세스를 마이크로서비스 세분화하여 설계 및 처리

· METS, PREMIS, BagIt 등 표준 메타데이터 및 패키징 포맷을 지원

· 생성한 DIP를 AtoM, DSpace, ContentDM 등 널리 쓰이는 기록물 발행시스템과 연동하여 관리하는 기능을 제공함

· DROID, PRONOM 등 파일포맷 레지스트리와 보존정책 설정기능 지원

354

○ 주요 특징

각 마이크로서비스 단위별 오픈소스 소프트웨어를 컴포넌트 형태로 설계하여 활용

POWRR 및 COPTR 레지스트리의 평가에 따르면 Archivematica 주로 데이터 입수, 이관, 파일포맷 변환 단계에서 필요로 하는 대부분의 기능을 충실하게 제공

<그림 316> Archivematica Architecture

디지털 보존수행에 있어서 점점 더 많은 분산된 툴과 서비스를 필요로 함

<그림 317> Workflow

355

툴 이름 툴 개요 라이선스

Standard and script to package digital BagIt BSD License objects and metadata for archival storage bulk_extractor Disk image and file contents analysis tool Public domain Clam AV Anti-virus toolkit for Unix GNU GPL ElasticSearch Indexing and search Apache License 2.0 ExifTool Multimedia metadata extraction GNU GPL and Artistic License Convert a wide variety of audio and video FFmpeg GNU LGPL formats File format identification and validation FITS GNU LGPL software integration tool fido File format identification tool Apach License, Version 2.0 Seigfried File format identification tool Apache License, Version 2.0 JHOVE File format validation tool GNU LGPL MediaInfo Multimedia metadata extraction BSD(2-clause), Zlib Optical Character Recognition –read Tesseract Apache Licence Version 2 image files and convert to text Web-based archival description and access AtoM GNU GPL tool. GPL compatible Imagemagick Imagemagick Converts a wide variety of bitmap images license Coverts vector images to Scalable Vector Inkscape GNU GPL version 2 Graphic (SVG) format Network File System Access – allows NFS-common GNU GPL access to files on network storage devices. Python-xml Python binding fore libxml2 and libxslt GNU GPL Disk image management and extraction Common Public License / IBM The Sleuthkit toolkit Public License Checksum generation and verification md5deep GNU GPL scripts Command line interface (CLI) for the generation of DCE 1.1, ISO/IEC 11578:1996 UUID GNU GPL and IEFTF RFC-4122 compliant Universally Unique Identifier (UUID) Interface with computing gardware. Ubuntu Linux GNU GPL Ubuntu Linux server edition Utility called by Bagit to create AIP Zip Info-Zip license package Django is a high-level Python Web Django framework that encourages rapid BSD License development and clean, pragmatic desigh Gearman Gearman provides a generic application BSD Licese

356

툴 이름 툴 개요 라이선스

framework to farm out work to other machines or processes that are better suited to do the work 7-Zip is a file archiver with a high p7zip GNU GPL compression ratio The Unarchiver is an archive unpacker unar GNU GPL program

<표 162> Archivematica에 사용된 외부 오픈소스 툴

7.3. 영구기록물관리기관 기록관리 현황 조사

가. 영구기록물관리기관 설치 대상

○ 공공기록물 관리에 관한 법률은 “소관 기록물을 영구보존 및 관리하기 위하여 설치∙운영” 하여야 하는 기관으로서 중앙기록물관리기관(제9조), 헌법기관기록물관리기관(제10조), 지방기록물관리기관(제11조)을 지정하고 있다.

중앙기록물관리기관

제9조(중앙기록물관리기관) ① 기록물관리를 총괄·조정하고 기록물을 영구보존·관리하기 위하여 행정안전부장관은 그 소속으로 영구기록물관리기관을 설치·운영하여야 한다. <개정 2013.3.23., 2014.11.19., 2017.7.26.>

헌법기관기록물관리기관

제10조(헌법기관기록물관리기관) ① 국회, 대법원, 헌법재판소 및 중앙선거관리위원회는 소관 기록물의 영구보존 및 관리를 위하여 영구기록물관리기관을 설치·운영할 수 있다. 이 경우 영구기록물관리기관을 설치·운영하지 아니할 때에는 대통령령으로 정하는 바에 따라 중앙기록물관리기관에 소관 기록물의 관리를 위탁하여야 한다.

특별시, 광역시, 특별자치시, 도, 특별자치도

제11조(지방기록물관리기관) ① 특별시장·광역시장·특별자치시장·도지사 또는 특별자치도지사는 소관 기록물의 영구보존 및 관리를 위하여 특별시·광역시·특별자치시·도 또는 특별자치도(이하 "시·도"라 한다)의 조례로 정하는 바에 따라 영구기록물관리기관(이하 "시·도기록물관리기관"이라 한다)을 설치·운영하여야 한다.

357

특별시, 광역시, 특별자치시, 도, 특별자치도 교육청

② 특별시·광역시·특별자치시·도·특별자치도 교육감(이하 "시·도교육감"이라 한다)은 소관 기록물의 영구보존 및 관리를 위하여 시·도의 조례로 정하는 바에 따라 영구기록물관리기관(이하 "시·도교육청기록물관리기관"이라 한다)을 설치·운영할 수 있다. 이 경우 시·도교육감이 시·도교육청기록물관리기관을 설치·운영하지 아니할 때에는 대통령령으로 정하는 바에 따라 소관 기록물을 시·도기록물관리기관에 이관하여야 한다.

○ 영구기록물관리기관을 분류하면 그림과 같이 4개의 그룹으로 분류되고 이 중 지방기록물관리 기관은 특별시, 광역시·도, 특별자치시·도 및 해당 시도의 교육청을 포함하여 가장 많은 기관이 해당됨

<그림 318> 국가기록관리기관체계 *출처: 국가기록원>기록관리업무>기록관리 업무 안내>국가기록관리기관체계 http://www.archives.go.kr/next/manager/nationalArchivesOrgan.do

○ 가장 많은 기관이 속한 지방기록물관리기관을 대상으로 문헌을 통해 현황 조사를 실시함. 지방기록물관리기관은 공공기록물관리법에 의해 영구기록물관리기관을 설치하여야 하나 2017년 현재 건립 중인 서울기록원과 건립 계획을 수립한 경상남도를 제외한 지방기록물 관리기관은 설치 추진이 원활하지 못 한 상황인 것으로 분석됨

나. 지방기록물관리 인력 현황

○ 지방자치단체에 기록물관리 전문요원은 2016년 12월 말 기준 17개 시도에 100%, 17개 시도교육청 역시 100% 배치되어 있음. 영구기록물관리기관이 관할하는 기초자치단체의 경우 94% 기관, 58% 교육지원청에 배치되어 있음

358

지자체 교육청 구분 계 시도 시군구 시도교육청 교육지원청

대상 기관 438 17 228 17 176

배치 기관 352 17 215 17 103

배치 인원 374 34 219 18 103

배치 정원 377 34 217 18 108

배치 기관 비율 80.3% 100% 94.3% 100% 58.5%

<표 167> 지방기록물관리기관 기록물관리 전문요원 배치 현황 * 출처: 국가기록원, 기록관리 전문요원 배치현황

○ 지방기록물관리기관에 배치된 전문요원의 임용 형태는 중앙부처의 기록연구직 100%에 비교할 때 시도 및 시도교육청 모두 80%에 못 미치고 있음

연도 일반직(495명, 79.3%) 임기제(129명, 20.7%) 총계 시간선 기록연구직 행정/사서 기타 일반임기제 기관 택제

시ž도(17개) 34 27(79.4%) 2(5.8%) 5(14.8%)

시 ž군 ž구 (228개 ) 219 106(48.4%) 3(1.4%) 93(42.5%) 17(7.7%)

시ž도교육청(17개) 18 14(77.8%) 2(11.1%) 2(11.1%)

교육지원청(176개) 103 85(82.5%) 8(7.8%) 10(9.7%)

<표 168> 지방기록물관리기관 기록물관리 전문요원 채용 형태 및 현황 * 출처: 국가기록원, 기록관리 전문요원 배치현황

○ 영구기록물관리기관 설치를 주관할 시도 및 시도교육청에 전문요원은 1 ~ 2명 배치되어 있으나 이들은 기관 자체의 기록 관리와 영구기록물관리기관 설치에 관한 업무를 병행해야 하는 실정이며, 또한 몇 년간의 추진 기간을 고려할 때 임기제 고용형태는 업무 지속성을 저해하는 요소가 될 수 있음

○ 영구기록물관리기관은 관할 기록관과의 업무 협의와 협력 관계를 구축해야 하므로 관할 기록관에 역시 전문요원을 배치할 필요가 있음. 교육지원청은 58.5% 배치로 교육청에 영구기록물관리기관 설치 전 교육지원청의 기록물관리 인력과 조직 마련이 우선되어야 함

다. 지방기록물관리 업무 현황

○ 지방자치단체 대부분이 총무과나 시민봉사과에 기록관을 설치하고 기록관 운영규칙의 자체 내규를 마력하고 이게 근거하여 업무를 수행하고 있으며 해당 기록물관리과의 업무 내용은 공인 등록(재등록) 및 폐기, 산하기관 공인 등록(재등록) 및 폐기 승인, 기록물 정리

359

및 이관, 평가, 폐기, 기록물 생산현황 취합, 통보, 중요기록물, 보존매체 수록, 기록관리 기준표 운영, 기록관 시스템 운영, 기록물관리 기관 설치 및 운영지원, 정보공개 접수 및 배부, 정보공개 처리상황 모니터링 및 관리, 정보목록관리, 행정자료 수집, 관리계획 수립, 행정자료실 및 희망열람실 관리 운영, 비밀문서 등록, 접수, 문서(일반, 전자) 배부 및 우편물 수발 등의 사항이며, 도서 및 자료 수집을 수행하고 있음(안건호, 2011)

○ 총무과나 시민봉사과와 같은 소속 부서의 업무와 기록관리 업무는 물론 정보공개 청구 업무까지 병행하는 경우도 있어 영구기록물관리기관 설치 계획 수립과 추진을 수행하기 어려운 실정임. 이러한 현실은 지방기록관의 기록연구사를 인터뷰한 연구(이윤용, 2016)에서 한 참여자는 생산된 기록물 파악과 보존기간 지난 기록물 평가에만도 엄청난 시간이 소요 되는데 정보공개청구 뿐 아니라 기록관리와 관련 없는 업무까지 같이 하다 보니 그저 폐기에만 급급한 실정이라고 답변하였음

○ 업무의 전문성이 보장되지 않고 과도한 업무량은 영구기록물관리기관 설치 추진의 지연 요인이 됨

라. 영구기록물관리기관 근거 조례 제정 현황

○ 공공기록물관리법은 영구기록물관리기관 설치 운영을 지방기록물관리기관의 조례에 의해 할 것을 명시하고 있음. 따라서 영구기록물관리기관의 건립 계획과 함께 관할 기록물 관리에 관한 조례를 제정하여야 함

○ 서울시와 경상남도의 조례는 2017년 현재 시행되었으며, 타 시도의 조례는 예고된 바가 없음

제·개정종류 공포일자 공포번호 자치법규명

타법개정 2017.02.23 4143 서울특별시기록관운영규칙

제정 2014.01.09 5661 서울특별시기록물관리에관한조례

제정 2017.07.20 4327 경상남도 기록원 설치 및 운영에 관한 조례

<표 169> 시도 기록물관리 관련 조례 제정 현황

마. 영구기록물관리기관 설치 현황

○ 공공기록물관리법이 정한 영구기록물관리기관 설치 대상 기관 중 서울시와 경상남도가 현재(2017.10) 영구기록물관리기관 설치를 추진 중에 있음

○ 서울시기록원 건립 현황

추진 경과

· 서울기록원 건립 타당성 조사 이행(2013.4~6)

· 서울기록원 건립 추진 학술용역(2013.4~8)

360

· 서울기록원 건립 계획 수립(2013.6) · 서울기록원 건립 변경 계획 수립(2013.10)

· 시 공유재산 심의 및 중앙 투융자심의(2014.3)

· 서울기록원 건립 개선 계획 수립(2014.9) · 서울기록원 정보화전략계획(ISP) 수립 용역(2016.4~8)

· 서울기록화 수집전략 개발 용역(2016.9~12)

· 서울기록원 디지털 아카이브 구축 개발 용역 수행 중(2017.03~2017.12)

서울기록원은 정보화전략계획(ISP) 수립 용역(’16.4월~8월) 결과를 반영하여 시정 기록과 함께 시민기록의 적극적 수집·정리·보존·서비스로 시민 공감 디지털 아카이브를 목표로 중기 기록관리 정보화 사업 로드맵 추진 중

로드맵

· 1단계(2017년): 운영환경 기본 구축 - 서울기록원 직원용 영구기록관리 업무 시스템과 대시민용 서비스 시스템의 S/W 및 H/W 구축

· 2단계(2018년): 운영환경 안정화 – 유관시스템 연계 서비스 개발, 스토리지 및 백업 장비 증설, 영구기록물 이전

· 3단계(2019년): 서비스 고도화 – 비밀기록물 관리 기능 개발, 공개용 기록관리시스템 개발, 영구기록물 이전

주요 과제

· 지방자치단체 최초 디지털 영구기록관리체계 구축

· 서울 시정의 역사를 담은 기록물 원본을 사회적으로 공개

· 다양한 역사문화정보 자원과 연결되는 디지털 아카이브 구축

· 거버넌스를 지향하는 서울기록원 디지털 아카이브 구축

서울기록원 건축 개요

· 위 치 : 은평구 녹번동 산1-61호

· 건축규모 : 지하2층/지상5층(연면적 15,004㎡)

· 용 도 : 문서고, 전시실, 열람실, 시민체험실, 아카이브 자료실 등

· 기 간 : 2016.5 ~ 18.4 · 소요예산 : 49,895백만원

관리 대상 기관

361

합 계 서울시 자치구 공사 투자·출연기관 16개 5개 (서울의료원,서울연구원,서울산업진흥원, (서울메트로, 신용보증재단,세종문화회관,여성가족재단, 1개 25개 서울도시철도, 서울시복지재단,서울문화재단,시립교향악단, 47개 (본청, 본부, 자치구 서울시설공단, 자원봉사센터,서울디자인재단,서울장학재단, 사업소 등) 농수산식품공사, 평생교육진흥원,50플러스재단, SH공사) 서울디지털재단, 서울관광마케팅)

<표 170> 서울기록원 관리 대상 기관

서울기록원 목표 시스템

<그림 319> 서울기록원 목표 시스템 개념도

○ 경상남도 기록원 건립 추진 현황

추진 경과

· 지방기록물관리기관 설립 세부추진계획 수립(2015.2. 27) · 지방재정 투·융자 심사 및 정밀안전진단 용역(2015.3. ~ 5)

· 경상남도 공유재산심의회 심의 의결(2016.5.24.)

· 기본 및 실시설계 용역(2016.2. ~ 9.) · 일상감사 및 건축협의 완료(2016.10.7.)

· 공사계약(건축․전기․통신․소방 등)(2016.11.21.)

· 착공식 개최(2016.12.6.)

362

· 경상남도기록원 정보화전략계획(ISP)수립 사업(2017.04~08)

경상남도기록원 건축 개요

· 위 치 : 창원시 의창구 사림로 45번길 75 구.보건환경연구원

· 사업기간 : 2015년 ∼ 2017년 ※ 2017. 연말 개관예정

· 사업규모 : 6,459㎡(리모델링 5,676㎡, 증축 783㎡) 지하1층, 지상5층

· 사 업 비 : 127억원(건축 84, 전산장비20, 서고장비 20, 기타 3)

경상남도기록원 정보화전략계획에서 이행계획을 수립하여 다음과 같은 7대 이행과제를 도출하였음

· 영구기록물관리체계 기반 마련

· 경상남도기록원 영구기록관리시스템(AMS) 구축

· 기록정보서비스포털(홈페이지) 구축 · 기록정보서비스체계 구축

· 기록물수집범위 확대 방안마련

· 경상남도기록원 운영체계구축

· 도민, 도민아키비스트 교육 및 지원

경상남도기록원 목표 시스템 개념도

<그림 320> 경상남도기록원 목표 시스템 개념도

○ 기타 시도는 열악한 지방재정 여건, 과다한 국비지원 요청, 자치단체장의 관심 저조 등의 원인으로 인해 설립 계획이 가시화된 기관이 없음

○ 국가기록원이 ‘13년 상반기 실시한 지방 공공유휴시설 실태조사에 의하면 세종, 경기, 강원, 충북, 충남, 제주 6개 시도는 기존 공공기설 및 부지를 활용하여 설치를 추진할 계획이

363

있었으나 70% 이상의 국비 지원 요청으로 인해 추진되지 못 한 것으로 추정됨(유승우, 2013)

7.4. 영구기록관리시스템 기능 요건

가. 영구기록관리시스템의 기본 요건

○ 영구기록관리시스템은 차세대 기록관리시스템의 기능 요건을 필수 요건을 만족시켜야 하며 영구기록관리기관의 개별 상황에 따라 추가 요건을 선택할 수 있음

○ 시스템 구현 시 기록관리시스템 Preservation Service Layer의 필수(Mandatory) 서비스를 중심으로 기본(Essential) 서비스와 선택한 추가 요건을 위한 선택 서비스를 구현하도록 함

나. Preservation Service Layer 서비스 상세 기능

○ Preservation Service Layer는 기록 객체를 관리 및 보존하기 위한 기능군으로서 우선적으로 구현해야 하며 영구기록관리 최소 기능 구현에 필요한 기능을 제시하고자 함

○ 기능의 세부 요건과 Business Serviced Layer의 요건은 「첨부 영구기록관리시스템 기능 요건(안) 및 확산 전략」 참조

Service ID Program Name Description

Administration AD000 Service 서비스 설정 Administration AD001 System Environment 시스템 환경 설정 Administration AD002 Message 메시지 설정 Administration AD003 Code 공통코드 설정 Administration AD004 Popup 팝업 설정 Administration AD005 Glossary 용어사전 설정 Administration AD006 Entity Type 엔티티 타입 설정 Additional Contextual Administration AD007 Metadata 추가 맥락메타 설정 Administration AD008 Audit 감사추적 조회 Administration AD009 Audit API 감사추적 API Access Control AC001 Sign In 로그인 Access Control AC002 Frame 프레임 Access Control AC003 User 사용자 설정 Access Control AC004 User Group 사용자 그룹 설정 Access Control AC005 Role 권한 설정 Access Control AC006 Permission 퍼미션 설정 Access Control AC007 Menu By Role 권한별 메뉴 설정 Access Control AC008 Program 프로그램 설정

364

Service ID Program Name Description

Access Control AC009 Menu 메뉴 설정 Access Control AC010 Row Security 로우 보안 설정 Access Control AC011 Row Security By Role 권한별 로우 보안 설정 Access Control AC012 Access Control API 접근권한 API Classification Scheme CL001 Classification Scheme 분류체계 설정 Classification Scheme CL002 Class 분류자 설정 Classification Scheme CL003 Classify Records 기록물 분류 Record RC001 Record Explorer 기록물 탐색기 Record RC002 Add Aggregation 집합체 등록 Record RC003 View Aggregation 집합체 조회 Record RC004 Add Item 아이템 등록 Record RC005 View Item 아이템 조회 Record RC006 Level of Description 기술계층 설정 Record RC007 Component Function 컴포넌트 역할 설정 Workflow WF001 Job 작업 설정 Workflow WF002 Workflow 워크플로우 설정 Workflow WF003 Run Workflow 워크플로우 실행 Workflow WF004 Workflow Result 워크플로우 실행결과 Ingest IG001 Ingest Job API 입수 과제 API Ingest IG002 SIP Creator SIP 생성기 Disposal Freeze DF001 Disposal Freeze Event 처분동결 사건 등록 Disposal Freeze DF002 Disposal Freeze Degree 처분동결 차수 등록 Disposal Freeze DF003 Disposal Freeze Records 기록물 처분동결 Records Schedule RS001 General Records Schedule 일반 레코드스케줄 등록 Records Schedule RS002 Trigger 트리거 설정 Records Schedule RS003 RecordsSchedule 레코드스케줄 설정 Records Schedule RS004 Records Scheduling 레코드스케줄/아이템 매핑 Records Schedule RS005 Disposal Records 기록물 처분 Records Schedule RS006 Due Date Update API 처분예정일 수정 API Storage ST001 Repository 서고 서가 등록 Storage ST002 Container 컨테이너 등록 Storage ST003 Arrange Records 기록물 정리 Storage ST004 Arrange Containers 컨테이너 정리 Storage ST005 Storage 스토리지 관리 Long-term Preservation LT001 File Format 파일 포맷 설정 Long-term LT002 Property Group Preservation Long-term Preservation LT003 Migration Pathway

365

Service ID Program Name Description Long-term Preservation LT004 Software 소프트웨어 설정 Long-term LT005 Tools Preservation Long-term Preservation LT006 장기보존 계획 관리 Long-term LT007 포맷 변환 Preservation Long-term Preservation LT008 AIP 제작 Long-term LT009 AIP 유형 관리 Preservation Long-term Preservation LT010 매체수록 계획 관리 Long-term LT011 매체수록 대상 관리 Preservation Long-term Preservation LT012 매체이전 계획 관리 Long-term LT013 매체이전 대상 관리 Preservation Long-term Preservation LT014 장기보존 결과 보고서

<표 171> 영구기록관리시스템 Preservation Service 상세 기능

7.5. 기록물 보안 방안

가. 개요

○ OAIS 참조모형에서 유통되는 하나의 장기보존패키지(AIP)는 4가지 유형의 정보 객체의 집합체로 구성되어 있다. 보존의 대상이 되는 정보인 내용정보 (Content Information; CI), 내용에 대한 일종의 메타데이터인 보존기술정보 (Preservation Description Information; PDI), 내용정보와 보존기술정보를 묶거나 식별하기 위해 부여된 패키징 정보, 그 패키지를 검색할 수 있도록 패키지를 기술한 목록정보인 기술정보로 이루어져 있음. 내용정보와 보존기술정보는 하나의 단일한 패키지를 구성해 인캡슐레이션 하며 패키징정보를 통해서 캡슐안의 구성을 확인할 수 있음. 이렇게 패키징된 전체가 OAIS에 저장되고 보존되며 한편으로는 OAIS 내에 존재하는 정보패키지를 찾아내기 위해 필요한 기술정보를 정의함

내용정보는 보존해야할 정보 집합으로 표현정보를 동반하는 내용 데이터 객체

보존기술정보는 내용정보를 보존하는데 필요한 정보로서 4가지로 구분할 수 있음. 출처 정보(Provenance Information), 참조 정보(Reference Information), 인증 정보(Fixity Information), 맥락 정보(Context Information)임

· 출처 정보는 내용 정보의 모든 이력을 문서화한 정보로 내용 정보의 기원과 변화 이력, 접근 권한 등의 정보를 제공함

· 참조 정보는 내용 정보에 부여된 식별자 시스템을 확인하고 설명하는 정보

· 인증 정보는 인증되지 않은 방식으로 내용 정보 객체를 수정할 수 없도록 보호함

366

· 맥락 정보는 내용 정보의 생산 이유와 다른 정보와의 관계에 대한 정보

패키징정보(Packaging Information)는 내용정보와 보존기술정보 검색에 필요한 정보내용 정보와 보존기술정보 검색에 필요한 정보로써 내용정보와 보존기술정보의 논리적인 결합 관계를 나타내는 정보

기술정보(Descriptive Information about Package)는 원하는 내용정보가 어떤 패키지에 담겨 있는지 검색하는데 이용되는 정보

○ 인증(Fixity) 정의

보존된 기록물, 파일/객체가 시간이 지남에 따라 또는 전송 중에도 변경되었는지 확인하는 정보로, 무결성 이라도 한다. 인증 정보(Fixity Information)를 만들기 위해 가장 널리 사용되는 도구는 체크섬 (CRC와 같은) 및 암호화 해시 (MD5 및 다양한 SHA 알고리즘과 같은)이지만 예상되는 파일 크기 및 파일 수와 같은 기본 인증 정보를 제공하는 다른 방법도 있음

○ 인증 정보(Fixity Information)의 용도

첫째, 인증 정보가 개체와 함께 제공되면 이를 수집 대상으로 사용했음을 확인할 수 있음. 둘째, 해당 정보를 향후 인증 정보 확인 정보와 비교하여 파일이 변경되었거나 손상되었는지 여부를 알 수 있음. 셋째, 콘텐츠와 함께 인증 정보를 제공함으로써 사용자는 자신이 보유한 콘텐츠의 진위성과 신뢰성을 보장함

○ 인증 정보(Fixity Information)의 이점

손상되거나 다른 방식으로 변경된 디지털 파일 또는 개체의 복구 지원 : 디지털 개체 복사본이 여러 개있는 경우 올바른 복사본을 식별 한 다음 손상된 디지털 파일 또는 개체를 교체 할 수 있음

하드웨어 저하 모니터링 : 객체 세트에 대한 인증 정보에 대한 검사가 고속으로 실패하기 시작하면 이는 미디어 장애가 발생할 수 있다. 이는 스토리지 구성 요소의 하드웨어 특정 모니터링을 보완해야 함

파일이나 개체가 변경되지 않은 항목이나 항목의 일부 또는 사본을 다른 사람에게 제공 할 때 신뢰성 보장함

"기타"부분이 변경되지 않았음을 확인하면서 콘텐츠 파일 또는 개체의 일부에 대한 업데이트 허용함

ISO 16363 / TRAC 및 NDSA 디지털 보존 수준과 같은 요구 사항 또는 모범 운영 지침을 준수함

생산 또는 디지털화 프로세스 모니터링 지원함

출처 및 역사 기록 : 인증 정보를 유지 관리하고 기록함으로써 개체가 콘텐츠의 무결성에 대한 증거를 제공함

367

보존된 콘텐츠의 수명주기 관리에서 발생할 수 있는 전산 또는 인적 오류를 진단에 도움이 됨. 정기적으로 픽스 정보(fixity information)를 계산하고 초기 인증(fixity) 정보와 비교하면 파일의 변경 사항이나 손상에 대한 지속적인 문서가 제공되므로 작업자 오류 또는 시스 템 문제와 관련된 표면 문제를 해결하는 데 도움이 됨

○ 무결성 확인 방법

가능할 때마다 콘텐츠 제공 업체 또는 제작자가 콘텐츠 개체와 함께 인증 정보를 제출하도록 권장하고, 초기 인증 값을 얻은 후에는 초과 작업 시간에 대한 확신을 제공 할 수 있으므로 가능한 빨리 인증 정보를 기록하는 것이 중요함. 인증 정보가 전송의 일부로 제공되지 않은 경우, 자료를 수신하면 인증 정보를 작성함

전송에 대한 정보 확인 : 한 스토리지 시스템에서 다른 스토리지 시스템으로 데이터를 전송하면 디지털 컨텐츠가 손상 될 수 있다. 따라서 이동 될 때마다 콘텐츠의 수정 여부를 확인하는 것이 중요함. 데이터의 추가 복사본이 있다고 가정하면 인증 값을 다른 복사본의 인증 값과 일치하지 않는 파일이나 개체를 확인하여 복구 또는 복구 할 수 있는 기회로 사용함. 참고로 Robo-copy와 같은 일부 파일 복사 응용 프로그램은 검사 수정을 수행하거나 전송 워크플로의 일부로 자동으로 수행하도록 구성 할 수 있음

정기적인 간격으로 인증(Fixiting) 확인 : 전송 전후에 픽스틸러를 확인하는 것 외에도 정기적으로 디지털 파일과 개체의 컬렉션을 확인해야 한다. 일정한 간격으로 모든 객체의 인증 값을 확인하는 데 중점을 둔 시스템 및 접근 방법이 있다. 예를 들어 월별, 분기 별 또는 연간 일 수 있음. 더 자주 확인할수록 오류를 발견하고 복구 할 확률이 높아짐

스토리지 시스템에 대한 건물 안정성 검사 : 일부 스토리지 시스템은 데이터가 정기적으로 확인되도록 시스템에 인증되어 있다. 일부 시스템은 테이프의 파일 별 체크섬을 지원하며, 새로운 테이프 기술을 사용하면 데이터를 호스트로 다시 읽지 않고 테이프 시스템에서 블록 단위 체크섬의 유효성을 검사 할 수 있다. 일부 파일 시스템 (예 : ZFS)은 정기적으로 블록 수준의 인증 정보를 계산한다. 그러나 파일 시스템 체크섬은 파일 시스템을 통해 발생하는 문제를 수정하거나 기록하지 않음. 결과적으로 이러한 파일 시스템을 사용하더라도 콘텐츠에 대한 변경 사항 (개별 파일 삭제 포함)을 완전히 감지하려면 별도의 인증 데이터가 필요함. 그러나 파일 시스템 레벨 체크섬은 저장 매체 성능 저하를 탐지하는 데 사용되는 하나의 지표로 사용될 수 있음

프로세스 모니터링을 위한 인증정보 확인 : 디지털 오디오 및 비디오 분야에서 주목할 만한 몇 가지 컨텐츠 - 프로세스 또는 프로덕션 모니터링을 지원하는 인증 정보. 예를 들 어 개별 데이터 블록의 체크섬을 사용하면 감시자가 디지털 손상의 크기와 위치를 파악 할 수 있음. 이 정보는 보다 정확한 데이터 전송을 위해 조정 된 상황에서 매체에서 적절한 읽기를 얻으려는 시도를 알릴 수 있음

파일의 세그먼트 또는 부분에서 최종 사용자에게 세그먼트가 제공 될 때 또는 파일의 다른 부분이 변경 될 때의 결함 검사. 이 구현의 예에는 오디오 파일 내의 인코딩 된 오디오 데이터를 체크섬하거나 비디오 파일의 개별 프레임 레벨 체크섬을 체크섬하는 것이 포함됨

368

○ 인증 점검주기에 대한 고려 사항

이제는 모든 사람들이 인증물 수표를 실행하고 인증된 간격으로 모든 콘텐츠에 대한 인증 정보를 비교하지 않는 이유에 대해 스스로에게 물음. 그 질문에 대한 답변을 위해 우리는 자원 제약과 경우에 따라 정착 지원 부족을 검토해야함

저장 매체 : 일반적으로 인증 검사를 수행하면 미디어 및 미디어를 읽고 처리하는 기계 장치의 사용이 증가함. 일부 미디어의 경우 사용량이 예상되는 미디어 오류율에 영향을 줄 수 있음

처리량 : 정체성 검사 비율은 수표를 실행할 수 있는 속도, 선택한 수리 도구의 복잡성 및 리소스에 사용 가능한 리소스 (예 : CPU, 메모리, 대역폭)의 양에 따라 다름. 조작, 디지털 콘텐츠의 양이 늘어나면서 점검을 수행하는 인프라가 동일하게 유지되는 경우 이는 초크 포인트가 될 수 있음. 이와 같은 상황에서 인증 관념 검사 활동은 사용자에게 콘텐츠를 전달하는 것과 같은 다른 중요한 기능에 부정적인 영향을 줄 수 있음

파일 또는 개체의 개수 및 크기 : 숫자와 크기가 모두 증가하는 디지털 파일 및 개체의 규모에 따라 다양한 리소스 요구사항이 발생함

내용 및 프로세스의 중복 수준 : 시스템 디자인에 따라 중복 복사본에 대한 인증을 확인하기 위한 여러 가지 방법이 필요할 수 있음. 예를 들어, 인증 사본이 기본 사본과 보조 사본에 대해 이미 검사되고 있는 경우, 3차 사본을 자주 검사 할 필요가 없다고 결정할 수 있음. 마찬가지로 파생물이나 액세스 사본으로 사용되는 파일보다 보존 마스터로 사용되는 파일에 대해 다른 방법을 사용하는 것이 좋음

클라우드 스토리지 공급자와 같은 제 3 자의 보증 : 자신의 수표를 사용하는 대신 시스템에서 유지 관리하는 사본을 지속적으로 확인하는 것에 대한 제 3 자의 주장을 신뢰함. 클라우드 제공자가 지원하는 세부 사항과 얼마나 자주 그리고 얼마나 상세한 인증 점검이 수행되는지에 대해 이해하는 것이 중요함

파일 시스템 또는 개체 시스템 수준에서 다루기 : 파일 또는 개체 시스템 자체가 블록 수준에서 자주 검사를 수행하는 경우 또는 자동으로 유지관리 되는 것이 매우 중요함

인증 도구 (Fixity 정의 노력의 수준과 투자 수익률 Instrument) 예상과 다른 파일 크기는 낮은 수준의 노력과 낮은 수준의 세부 사항. 기대파일크기 문제의 표시기가 될 수 파일 크기는 Windows 탐색기 나 다른 (Expected File Size) 있습니다 (예 : 0 바이트 일반적인 도구에서 볼 수 있는 자동 생성 된 파일 강조 표시). 기술 메타 데이터입니다. 예상과 다른 파일 수는 낮은 수준의 노력과 낮은 수준의 세부 사항. 기대파일 수 파일이 패키지에서 추가 파일 수는 Windows 탐색기 나 다른 일반적인 (Expected File Count) 또는 삭제된다는 표시기가 도구에서 볼 수 있는 자동 생성 된 기술 메타 될 수 있습니다. 데이터입니다.

369

인증 도구 (Fixity 정의 노력의 수준과 투자 수익률 Instrument)

62/5000 낮은 수준의 노력과 중간 정도의 세부 수준. 오류 감지 코드, 일반적으로 변수이지만 일반적으로 32 또는 64 비트 인 CRC 네트워크 전송 중에 CRC 함수 값은 구현 및 분석이 비교적 사용됩니다. 쉽습니다.

적당한 수준의 노력과 높은 수준의 디테일. 해시 값을 계산하기위한 CPU 및 처리 요구 사항은 파일 크기에 따라 보통 수준에서 MD5 암호화 해시 함수 보통 수준까지 낮습니다. 이 해시 값의 출력 크기는 128 비트의 암호화 해시 값 중 가장 낮습니다.

적절한 수준의 노력, 높은 수준의 세부 사항 및 추가 된 보안 보증. 보다 높은 160 비트 SHA1 암호화 해시 함수 출력 해시 값으로 인해 SHA-1은 MD5보다 지정된 처리주기 CPU 및 처리 시간 동안 더 많은 상대 시간을 계산해야합니다.

높은 수준의 노력, 매우 높은 수준의 세부 사항 및 보안 보증 추가 256 비트의 출력 보다 안전한 암호화 해시 해시 값을 사용하면 SHA-256은 SHA256 함수 SHA-1보다 지정된 처리주기 CPU 및 처리 시간 동안 더 많은 상대 시간을 계산해야합니다.

<표 172> 인증도구 종류 ○ 정보를 저장하고 참조 할 위치

개체 메타 데이터 레코드 : 대부분의 경우 메타 데이터 레코드를 저장하고 관리 할 때마다 파일 또는 개체 인증 정보를 기록해야 함. 이러한 메타 데이터 레코드는 실제로 개별 파 일 또는 데이터베이스에 저장됨. 이는 장기간 객체 메타 데이터의 일부로 원래 제출되었 거나 생성 된 인증 정보를 유지 관리하는 데 특히 유용함

데이터베이스 및 로그 : 주어진 간격으로 실행하는 검사의 경우 개체 메타 데이터 레코드에 지속적으로 추가하고 싶지 않을 수 있음. 이 경우 필요할 때 되돌릴 수 있는 데이터베이스 및 로그에 인증 정보를 계속 실행하는 것이 좋음

콘텐츠 자체와 함께 인증정보를 보유하는 것이 좋음. 그렇게 하면 시스템의 다른 레이어에 문제가 있거나 일부 개체 집합을 전송하려는 경우에도 콘텐츠와 함께 이전의 인증 값이 기록함

370

파일의 일부에 대한 체크섬 인 경우 정보를 파일에 직접 저장하는 것이 좋음. 이는 파일 내에 하위 파일 인증 정보를 저장할 때만 의미가 있음. 전체 파일에 대한 인증 정보를 파일 자체에 추가하면 파일이 변경되므로 인증 값이 변경됨

○ “전자서명 장기검증”은 기록물관리기관이 보존 중인 전자기록물의 진본성과 무결성을 확인하기 위한 방법의 하나로, 행정전자서명 인증서를 장기적으로 검증하는 처리방식과 데 이터 규격을 정의한 것으로서 표준전문위원회 및 국가기록관리위원회의 심의를 거쳐 제 정한 공공표준이다. 전자기록물 전자서명 인증서 장기검증 기술규격(2008)을 참고하여 인 증정보 사용에 대래 언급함

나. 전자서명 장기검 증 개요

○ 일반사항

인증정보는 장기보존포맷의 진본성과 무결성을 검증하기 위해 기록물관리기관 인증서로 생성한 전자서명 데이터와 해당 기록물관리기관 인증서를 포함. 잠김 인증정보는 시 스템인증서(인증기관이 장기보존포맷 생성시스템에 발급한 인증서)로 생성한 전자서명 데이터와 해당 시스템인증서를 포함함

비고 전자서명 데이터는 장기보존포맷 인증정보에 포함된 인증서의 공개키 로 해당 전자서명 데이터를 복호화 하여 얻어낸 전자서명 당시의 해쉬(Hash)값과 장기보존포맷의 ‘서명된 객체(AM4)’의 모든 데이터(원문, 문서보존포맷, 메타데이터)에 대해 해쉬값을 생성하여 두 해쉬값을 비교함으로써 검증할 수 있음

○ 인증정보

장기보존포맷은 인증서 기반의 전자서명을 적용. 즉, 전자서명 인증을 받지 않은 사람은 그 문서의 내용을 변경할 수 없도록 함으로써 전자기록물의 무결성을 보장해주는 방법. 전자서명을 검증할 수 있도록 인증서는 인증서 버전, 인증서 일련번호, 인증서의 유효기간, 발급기관명 및 전자서명 알고리즘 정보 등을 포함. 장기보존포맷은 이러한 인증서 정보를 함께 넣어 객체를 생성. 전자서명의 적용범위는 장기보존포맷의 구성요소인 전자기록물 원문, 문서보존포맷, 장기보존포맷 메타데이터. 인증정보의 생성은 개인용인증서 또는 컴 퓨터용인증서가 아닌 기관용인증서를 사용하여 생성함

○ 잠김인증정보

잠김인증은 인증정보의 생성 및 검증절차와 동일하며 잠김인증의 전자서명 대상은 최종으로 수정된 장기보존포맷 인증정보의 전자서명 값. 잠김인증정보는 장기보존포맷을 생성하는 시 스템인증서를 사용. 기존 장기보존포맷에 적용된 인증정보는 수정된 장기보존포맷을 검증 할 수 DKQTD,A. 따라서 수정된 장기보존포맷에 잠김인증정보를 추가하여 수정된 장기보존포맷의 무결성을 보장해주어야 함

○ 장기검증

전자기록물을 장기보존 하는 경우 기록물의 진본성 및 무결성을 전자서명으로 검증하는

371

사례가 늘면서 전자서명에 대한 장기검증관리가 필요함. 전자서명을 적용한 전자기록물의 경우 전자서명에 사용된 인증서의 검증 가능기간은 현행 행정전자서명인증관리센터에서 발급하는 인증서의 유효기간범위 내이다. 이 유효기간이 지나면 인증서 검증이 불가능하여 전자서명이 효력을 상실하게 됨으로 기록물의 위변조 여부를 확인하기 어려움. 따라서, 인증서의 유효기간이 지나더라도 기록물의 전자서명에 사용된 인증서의 유효성을 계속적 으로 검증할 수 있는 시스템이 필요함

비고 이렇게 전자서명 인증서를 장기 검증할 수 있는 시스템은 ‘전자기록물전자서명 인증서 장기검증시스템’이라 부르며, 장기검증 방법에 대한 자세한 사항은 ‘NAK/TS 4-1:2011(v1.1) 전자기록물 전자서명 인증서 장기검증 기술규격(v1.1)’을 참조함

장기검증데이터의 검증을 위한 주요 처리 절차

· 장기검증데이터 검증 시 아래의 과정을 준수하여 모든 검증이 성공일 경우 특정 시점에서 전자서명용 인증서의 유효성을 보장할 수 있다. 그렇지 않은 경우 유효성을 보장할 수 없으며 해당 인증서를 이용하여 전자 서명한 데이터에 대한 유효성 역시 실패로 간주. 전자서명 인증서 장기검증데이터 검증의 세부 처리 절차는 아래와 같음

<그림 321> 장기검증데이터 검증의 세부처리 절차

372

8. 차세대 기록관리시스템 구축 이행 계획

8.1. 이행 계획

가. 확산 로드맵

○ 단계별 차세대 기록관리시스템의 구축과 확산 목표 이미지 수립

<그림 322> 차세대 기록관리시스템 확산 로드맵

나. 이행 단계별 주요 내용

○ 1단계 차세대 기록관리체계 도전

차세대 기록관리 프레임워크를 본격 개발하여 이용 가능한 환경 조성

영구기록물관리기관 중 우선적으로 구축 하고자 하는 기관에 시범적으로 개발하여 기록관리 프레임워크에서 공유

373

기관 구분 1단계 (2018 ~ 2020)의 내용

· 클라우드 기록관리시스템이 2017년부터 2019년까지 3차에 걸쳐 확산 완료 예정 중앙부처 · 클라우드 기록관리시스템 운영

· 중앙영구기록물관리시스템 서버와 스토리지를 통합하고 가상화 · 현행 중앙영구기록관리시스템 애플리케이션 및 데이터베이스 이전 국가기록원 · 차세대 기록관리 프레임워크로서 오픈소스 플랫폼을 구축하고 기록관리 서비스 개발 환경 조성

· 서울기록원 및 경상남도기록원과 같이 지방기록관 설립을 추진 중인 광역시도 영구기록물관리기관은 차세대 기록관리시스템 기능 요건을 고려하여 자체 개발 후 성과를 차세대 기록관리 프레임워크와 공유

시군구 현행 표준 기록관리시스템 운영

기타 현행 표준 기록관리시스템이나 기관에서 자체 개발한 기록관리시스템 운영 공공기관

<표 173> 차세대 기록관리체계 1단계

○ 2단계 차세대 기록관리시스템 성장

기관 구분 2단계 (2021 ~ 2022)의 내용

중앙부처 · 클라우드 기록관리시스템 운영

· 중앙영구기록물관리시스템의 인프라를 클라우드 IaaS로 고도화하고 향후 국가기록원 차세대 기록관리 클라우드로 발전시키기 위한 기반 인프라로 활용 · 차세대 기록관리 프레임워크 안정화 및 활성화

· 차세대 기록관리 프레임워크 안정화, 교육, 홍보 및 기술지원을 통해 광역시도의 차세대 영구기록관리시스템 구축 여건 마련 · 각 시도는 영구기록관리시스템에 대한 시도의 고유 요구사항에 따라 개발 광역시도 계획을 수립하여 추진 · 광역시도별 요구와 특성에 따라 클라우드 구축 또는 이용이 가능한 시도는 클라우드를 기반으로 구축하며, 또는 단독 서버 인프라 등 다양한 인프라 기반으로 차세대 기록관리 프레임워크의 오픈소스를 활용하여 구축

· 현행 표준 기록관리시스템 운영과 차세대 기록관리시스템 공존 · 차세대 기록관리 프레임워크 안정화, 교육, 홍보 및 기술지원을 통해 시범 시군구 기초자치단체에 차세대 기록관리시스템 구축 여건을 마련하고 추진 장려 · 기초자치단쳬 단독 추진 시 대다수 기관에서 단독 서버 아키텍처 상 구축 예상

기타 · 기존 구축한 표준 또는 자체 개발 기록관리시스템과 함께 신규 도입 또는 공공기관 고도화 예정인 공공기관에서는 차세대 기록관리 프레이워크를 활용하여 개발

<표 174> 차세대 기록관리체계 2단계

374

○ 3단계 차세대 국가기록관리체계 완성

기관 구분 3단계 (2023 ~ 2027)의 내용

· 범정부 클라우드 환경에서 기존 클라우드 기록관리시스템을 차세대 기록관리 중앙부처 SaaS로 교체 구축

· 국가기록 클라우드 체계 마련 · 중앙영구기록물관리시스템을 국가기록 클라우드 SaaS로 개발 · 국가기록 클라우드 SaaS 환경에서 제공되는 영구기록관리시스템 구축, 국가기록원 클라우드 이용이 불가한 지방기록물관리기관을 위한 영구기록관리 서비스 제공 · 차세대 기록관리 프레임워크에 지능적 행정 구현 확장 서비스 개발

· 영구기록관리시스템과 기록관시스템이 지방기록물관리기관의 클라우드 환경에서 SaaS로서 구축 운영 광역시도 · 영구기록물관리기관은 차세대 영구기록관리시스템을 단독 운영 등 · 다양한 형태의 영구기록관리시스템 구축

· 지방자치단체를 위한 범정부 클라우드에서 기록생산시스템과 함께 차세대 기록관리시스템 구축 운영 · 영구기록물관리기관의 프라이빗 클라우드에서 차세대 기록관리시스템 구축 시군구 운영 · 기관 단독 차세대 기록관리시스템 구축 운영 등 · 오픈소스 차세대 기록관리 프레임워크를 이용하여 구축

· 공공기관의 프라이빗/퍼블릭 클라우드 또는 단독 인프라 상에서 차세대 기타 기록관리시스템 구축 운영 공공기관 · 기관 자체 개발한 기록관리시스템 운영

<표 175> 차세대 기록관리체계 3단계

8.2. 이행 과제와 추진 전략

나. 추진 전략

○ 중앙영구기록관리시스템의 인프라를 단계적으로 클라우드 환경으로 전환 구축하고 이를 국가기록 클라우드 기반체계로 확장 구축

○ 중앙기록관리시스템은 애플리케이션은 IaaS 환경으로 이전하되, 수정 개발이 필요한 기능은 차세대 기록관리 프레임워크를 적용하여 신규 개발함으로써 점진적으로 교체. 지방기록물관리기관의 영구기록관리시스템 기본형이 개발된 뒤 이를 활용하고 추가 고유 기능을 개발하여 중앙기록관리시스템을 SaaS로 완성

○ 데이터세트관리시스템은 신규 개발이므로 차세대 기록관리 프레임워크를 이용하여 중앙기록관리시스템 클라우드 IaaS 상 또는 단독 시스템으로 우선 구축. 중앙기록관리시스템의

375

클라우드 SaaS 개발 시 데이터세트관리시스템과 통합하여 고도화

○ 지방기록물관리기관의 영구기록관리시스템은 도입 단계로서 서울기록원과 경상남도기록원 외에 구축 사례가 없기 때문에 시스템과 데이터 이전이 필요 없음. 따라서 신규 시스템 구축이 쉽기 때문에 차세대 기록관리 프레임워크 적용이 현 운영 중인 기록관리시스템 보다 수월하므로, 영구기록관리시스템으로부터 우선적으로 차세대 기록관리 프레임워크를 이용하여 개발

○ 중앙기록관리시스템 SaaS 개발 완료 후 프라이빗 클라우드 설립이 불가한 영구기록관리기관은 국가기록 클라우드 상에서 중앙기록관리시스템에서 개발된 서비스 모듈을 이용하고 고유 서비스 모듈을 추가하여 영구기록관리시스템 SaaS 개발. 프라이빗 클라우드 설립이 가능한 기관은 자체 클라우드에서 차세대 기록관리 프레임워크와 중앙기록관리시스템 개발 결과를 이용하여 구축

○ 각 기록관의 기록관리시스템은 지자체까지 보급되어 있으므로 빠른 시일 교체 구축 추진이 어려우며, 자료구축 및 전자기록 이관 결과 데이터량이 크기 때문에 이전으로 인해 시스템 개발 외의 비용 소요. 따라서 차세대 기록관리 프레임워크 안정화 이후 점진적 추진

나. 이행 과제

○ 차세대 기록관리체계의 완성을 위해서 5개 주요 과제 선정

행정정보 데이터세트 기록관리체계 구축

· 행정정보 데이터세트 관리를 현실화하기 위하여 기관 특성에 따라 점진적으로 기록관리 개시

· 데이터세트 관리를 효율화하고 일상 점검이 가능하도록 관리 시스템 개발 구축

차세대 중앙영구기록관리시스템 구축

· 중앙영구기록관리시스템의 인프라를 차세대 국가기록 클라우드 기반 체계로 확장 가능하도록 전환

· 국가 기록의 무결성, 진본성, 신뢰성, 이용가능성을 보장하는 영구기록관리시스템으로 재구축

차세대 영구기록관리시스템 구축

· 지방기록물의 체계적 관리를 위하여 차세대 기록관리 프레임워크를 활용하여 영구기록관리시스템의 기본 모델 개발

· 차세대 기록관리 프레임워크를 활용하여 영구기록물관리기관에서 시스템 구축이 가능 하도록 기술 지원

차세대 기록관리시스템 구축

· 기록 생산기관에서 차세대 기록관리 개념을 구현하는 차세대 기록관리시스템의 기본 모델 개발

· 차세대 기록관리 프레임워크를 활용하여 생산기관에서 기관 고유 요구에 맞춰 개발할

376

수 있도록 기술 지원

· 현행 기록관리시스템의 교체 구축 기술 지원

차세대 기록관리 프레임워크 구축

· 기록관리시스템과 영구기록관리시스템의 필수 서비스 모듈 개발

· 개발 표준 및 지침의 개발, 개발자 교육 및 홍보

· 오픈소스 정책 하 개발 커뮤니티의 개발 활동 지원

○ 주요 과제별 이행 과제를 도출하여 상호 관계 식별

<그림 323> 기록관리체계 구축 이행과제

8.3. 행정정보데이터세트 관리체계 구축 이행과제

가. 행정정보 데이터세트 기록화 사례 개발

○ 목적

다양한 유형의 기관에서 운영하고 있는 다양한 행정정보시스템의 데이터세트와 신기술 활용 결과 새롭게 등장한 데이터세트를 대상으로 실제 기록관리를 시행함으로써 현장에서 적용 가능한 기록관리 방안 수립

연차별 목표

377

연차 목표

1차년도 중앙행정기관 공동이용 시스템의 데이터세트 기록화

2차년도 지방자치단체 운영 시스템의 데이터세트 기록화

3차년도 공공기관 운영 시스템의 데이터세트 기록화

4차년도 특수 유형 데이터세트 기록화

5차년도 제4차 산업혁명 시대 데이터세트 기록화

<표 176> 행정정보 데이터세트 기록화 사례 개발 사업 연차별 목표

○ 주요 내용

[1차년도] 중앙행정기관 공동이용 시스템 데이터세트 기록화

· 중앙행정기관이 공동 이용하는 시스템(나이스교육정보시스템, 디지털예산회계시스템 등) 3개 이상 선별

· 시스템 상세 조사 및 분석

· 데이터세트 기록관리 적용과 평가

· 기록관리방안 개선 방안 수립

[2차년도] 지방자치단체 운영 시스템 데이터세트 기록화

· 지자체 3개 이상 선정, 지방행정업무 대표 시스템 5개 이상 선별

· 시스템 상세 조사 및 분석

· 데이터세트 기록관리 적용과 평가

· 기록관리방안 개선 방안 수립

[3차년도] 공공기관 데이터세트 기록화

· 공기업, 준정부기관 및 기타공공기관의 조직, 시스템 및 데이터 특성을 고려하여 3개 이상 기관, 5개 이상 시스템 선별

· 시스템 상세 조사 및 분석

· 데이터세트 기록관리 적용과 평가

· 기록관리방안 개선 방안 수립

[4차년도] 특수 유형 데이터세트 기록화

· 특수 유형(캐드캠데이터, 소셜미디어데이터 등) 데이터세트 조사

· 유형별 데이터세트 분석 후 기록화 대상 선별

· 특수 유형을 위한 기록관리 방안 수립

378

[5차년도] 제4차 산업혁명 시대 데이터세트 기록화

· 신기술 활용 결과 생성된 새로운 유형의 데이터세트 조사 · 데이터세트 유형 분석 후 기록화 대상 선별

· 특수 유형을 위한 기록관리 방안 수립

○ 소요 예산 : 총 560백만원

연차별 예산

연차 수행기간 예산(백만원) 목표

중앙행정기관 공동이용 시스템의 데이터세트 1차년도 2018.02 ~ 12 112 기록화 2차년도 2019.02 ~ 12 112 지방자치단체 운영 시스템의 데이터세트 기록화 3차년도 2020.02 ~ 12 112 공공기관 운영 시스템의 데이터세트 기록화 4차년도 2021.02 ~ 12 112 특수 유형 데이터세트 기록화 5차년도 2022.02 ~ 12 112 제4차 산업혁명 시대 데이터세트 기록화

<표 177> 행정정보 데이터세트 기록화 사례 개발 사업 연차별 예산

○ 산출내역

매년 112,000,000원

구 분 금 액 구 성 비 비 고 비 목 책 임 연 구 원 34,212,519 원 33.4 % 연 구 원 52,467,380 원 51.34 % 인건비 연 구 보 조 원 원 % 보 조 원 원 % 인건비 소계 86,679,899 원 84.82 % 국내여비 7,200,000 원 7.05 % 여비 국외여비 원 % 여비 소계 7,200,000 원 7.05 % 유 인 물 비 880,000 원 0.86 % 전 산 처 리 비 370,000 원 0.36 % 경비 시 약 및 재 료 비 원 % 회 의 비 1,100,000 원 1.08 % 임 차 료 원 % 교 통 통 신 비 180,000 원 0.18 % 감 가 상 각 비 원 % 경비 소계 9,730,000 원 9.52 % 일반관리비 5,784,594 원 5.66 %

총 원 가 102,194,493 원 100 %

379

나. 데이터세트관리시스템 구축

○ 목적

행정정보 데이터세트 기록관리체계 수립 및 근거 법령 개정에 맞추어 관리체계를 자동화 및 효율화하기 위한 시스템 개발

○ 주요 내용

생산기관이 데이터세트의 등록으로부터 평가 및 처분 등 데이터세트 전 생애주기에 걸쳐 수행하는 기록관리 행위를 관리하기 위한 기능 구현

영구기록물관리기관에서 생산기관의 데이터세트 관리 중 발생하는 문제점을 조기 발견하여 개선할 수 있도록 상시 점검 기능 및 생산기관과의 업무 협조 기능 구현

○ 수행기간 : 2021년 ~ 2022년(2년)

○ 소요 예산 : 총 559백만원

하드웨어 및 기반 소프트웨어 제외, 중앙영구기록물관리시스템 클라우드 자원 이용

○ 산출내역

데이터세트관리 시스템 구축 소프트웨어 개발비 산정 - 투입공수에 의한 방식 (소프트웨어사업대가산정가이드,2017.KOSA)

○ 투입공수에 의한 방식의 개발원가 산정 (단위 : 원)

평균임금 투입공수 한달일수 구분 금액 (2017년기준) (MM) (2017년기준)

기술사 452,611

특급기술자 391,068

고급기술자 305,353 12.0 20.8 76,216,109

중급기술자 239,506 13.0 64,762,422

초급기술자 191,320 13.0 51,732,928

직접인건비 합계 192,711,459

제경비(직접인건비의 110 ~ 120%) 120% 231,253,751

기술료([직접인건비 + 제경비]의 20 ~ 40%) 20% 84,793,042 직접경비 0 합 계 (부가세 별도) 508,758,252 부가세(VAT) 50,875,825 합 계 (부가세 포함) 559,600,000

380

다. 데이터세트 관리 고도화

○ 목적

클라우드 SaaS로 개발하여 차세대 중앙기록관리시스템과 통합하여 데이터세트관리시스템의 기능 확장 및 고도화

○ 주요 내용

데이터세트관리시스템을 안정화 및 기능 고도화

차세대 중앙기록관리시스템 SaaS의 서비스로 통합

○ 수행기간 : 2023년 ~ 2024년(2년)

○ 소요 예산 : 총 559백만원

○ 산출내역

"데이터세트 관리 고도화 구축“ 소프트웨어 개발비 산정 - 투입공수에 의한 방식

(소프트웨어사업대가산정가이드,2017.KOSA)

○ 투입공수에 의한 방식의 개발원가 산정 (단위 : 원)

평균임금 투입공수 한달일수 구분 금액 (2017년기준) (MM) (2017년기준)

기술사 452,611

특급기술자 391,068

고급기술자 305,353 12.0 20.8 76,216,109

중급기술자 239,506 13.0 64,762,422

초급기술자 191,320 13.0 51,732,928

직접인건비 합계 192,711,459

제경비(직접인건비의 110 ~ 120%) 120% 231,253,751

기술료([직접인건비 + 제경비]의 20 ~ 40%) 20% 84,793,042

직접경비 0

합 계 (부가세 별도) 508,758,252

부가세(VAT) 50,875,825

합 계 (부가세 포함) 559,600,000

381

라. 데이터세트 보존 체계 구축

○ 목적

국가적 기록으로서 보존 가치 높은 데이터세트 인수에 대비하여 장기보존 방안 및 이관 규격 연구를 바탕으로 데이터세트관리시스템에 인수 기능 구현

○ 주요 내용

데이터세트 장기보존 포맷 및 이관 지침 개발

데이터세트 인수 기능 구현 ○ 수행기간 : 2023년 ~ 2024년(2년)

○ 소요 예산 : 총 689백만원

○ 산출내역

"데이터세트 보존 체계 구축“ 소프트웨어 개발비 산정 - 투입공수에 의한 방식

(소프트웨어사업대가산정가이드,2017.KOSA)

○ 투입공수에 의한 방식의 개발원가 산정 (단위 : 원)

평균임금 투입공수 한달일수 구분 금액 (2017년기준) (MM) (2017년기준)

기술사 452,611

특급기술자 391,068

고급기술자 305,353 12.0 20.8 76,216,109

중급기술자 239,506 18.0 89,671,046

초급기술자 191,320 18.0 71,630,208

직접인건비 합계 237,517,363

제경비(직접인건비의 110 ~ 120%) 120% 285,020,836

기술료([직접인건비 + 제경비]의 20 ~ 40%) 20% 104,507,640

직접경비 0

합 계 (부가세 별도) 627,045,839

부가세(VAT) 62,704,584

합 계 (부가세 포함) 689,700,000

382

8.4. 차세대 중앙영구기록물관리시스템 구축 이행과제

가. 자원통합 및 가상화

○ 목적

현행 중앙영구기록물관리시스템의 서버 및 스토리지 통합하고 가상화함으로써 공간 및 전력 비용 절감, 자원최적화와 관리효율성 향상, 서버 유지보수 비용 절감, 신규 자원 요구에 빠르게 대응함으로써 업무 연속성 최대화함

○ 주요 내용

현행 국가기록원 대전 서버실, 성남기록관, 서울기록관에 위치한 서버와 스토리지 통합, 가상화 자원 풀 구성

웹서버, DB, 어플리케이션을 가상화 서버로 이전

○ 수행기간 : 2019년 ~ 2020년(2년)

○ 소요예산 : 8,530백만원

○ 산출내역

구분 대전내부망 대전외부망 성남기록관 총합

서버통합 1789 1074 307 3170

스토리지 통합 3520 1020 820 5360

합계 5309 2094 1127 8530

<표 182> 중앙영구기록물관리시스템 자원통합 가상화 산출내역

나. 클라우드 IaaS 구축

○ 목적

가상 자원 풀을 클라우드 IaaS로 전환 구축하여 중앙영구기록관리시스템의 인프라를 클라우드 환경으로 구축

○ 주요 내용

자원 할당 및 회수 자동화

사용자 셀프 서비스 포탈 구현

○ 수행기간 : 2021년 ~ 2022년(2년)

383

○ 소요예산 : 1,500백만원

다. 클라우드 SaaS 중앙영구기록관리시스템 구축

○ 목적

기록관리 프레임워크와 영구길고관리시스템 기본형 및 시범 기관 구축에 의해 개발된 서비스를 활용하여 영구기록관리시스템을 SaaS로 재개발

향후 지방기록물관리기관을 위한 영구기록관리시스템 SaaS 모델 기반 구축

○ 주요 내용

중앙영구기록관리시스템을 기록관리 프레임워크를 이용하여 재설계

차세대 영구기록관리시스템 기본형 및 시범 기관과 우선 추진 기관에 의해 개발된 비즈니스 레이어 서비스를 이용해 기능 구현

○ 수행기간 : 202년 ~ 2024년(2년)

○ 소요예산 : 1,500백만원

○ 산출내역

클라우드 SaaS 중앙영구기록관리시스템 구축 소프트웨어 개발비 산정 - 투입공수에 의한 방식

(소프트웨어사업대가산정가이드,2017.KOSA)

○ 투입공수에 의한 방식의 개발원가 산정 (단위 : 원)

평균임금 투입공수 한달일수 구분 금액 (2017년기준) (MM) (2017년기준)

기술사 452,611

특급기술자 391,068 고급기술자 305,353 24.0 20.8 152,432,218

중급기술자 239,506 48.0 239,122,790

초급기술자 191,320 48.0 191,013,888

직접인건비 합계 582,568,896

제경비(직접인건비의 110 ~ 120%) 120% 699,082,675

기술료([직접인건비 + 제경비]의 20 ~ 40%) 20% 256,330,314

직접경비 0 합 계 (부가세 별도) 1,537,981,885

부가세(VAT) 153,798,189

합 계 (부가세 포함) 1,691,700,000

384

8.5. 차세대 영구기록관리시스템 구축 이행과제

가. 차세대 기록관리시스템 구축 정보화전 략계획 수립

○ 목적

기록생산시스템과 기록보존시스템을 통합하여 기록 생산 시점부터 보존까지 생산 절차 간소화, 다양한 기록 유형 통합 관리, 중앙 및 지방 영구기록물관리기관의 공통 및 고유 업무 프로세스 재설계

기록의 생애주기에 기반을 두어 차세대 기록 개념을 구현하는 시스템 설계

○ 주요 내용

프로세스 재설계

· 생산기관 기록관리 업무 통합을 위한 프로세스 재설계

· 영구기록물관리기관의 업무 통합을 위한 업무 프로세스 재설계

· 정부 차원의 전자기록관리 통합관리체계 구축방안 설계

· 전자기록물 활용 활성화 방안 및 중장기 계획 수립

시스템 설계

· 전자문서, 데이터세트, 웹기록물, 멀티미디어 등의 기록 포착과 보존 기능

· 인공지능 활용 방안

· 생산기관 문서생산과 기록관리시스템의 통합 방안

· 차세대 전자기록 통합시스템 인프라 구축 방안

· 전자기록 통합관리 및 활용 방안

○ 수행기간 : 2018년(1년)

○ 소요 예산 : 683백만원

나. 차세대 영구기록관리시스템 구축

○ 목적

차세대 기록관리 프레임워크를 이용하여 영구기록관리시스템의 필수 기능 개발, 영구기록관리시스템을 구축하고자 하는 기관에서 확장 개발하도록 함

차세대 기록관리시스템 프레임워크에 기반을 두어 영구기록물관리시스템을 우선적으로 구축하고자 하는 기관과 업무 협의 및 기술지원을 제공함

시범 기관에서 차세대 기록관리시스템 프레임워크 적용 시 시행착오를 최소화하여 빠른 시일 내 시스템 구축할 수 있도록 지원

385

프레임워크 개발팀에 사용자 요구사항 및 오류 등 문제를 전달하고 협의하여 차세대 기록관리시스템 프레임워크의 업그레이드와 안정화 방안 수립

○ 주요 내용

차세대 기록관리 프레임워크를 이용하여 필수 기능으로 작동하는 기본형 영구기록관리시스템 개발

기본형 시스템을 이용한 개발 방안, 개발 지침 등 개발

완성된 서비스 모듈 소스는 기록관리 프레임워크 오픈 소스 생태계로 반환

차세대 영구기록관리시스템 서비스 개발

· 차세대 기록관리 프레임워크의 보존 레이어(Preservation Layer) 서비스 기반 개발 방법 교육

· 보존 레이어 적용 시 발생하는 문제 및 요구사항 업무 협의 및 분석

· 기관 고유 업무 레이어(Business Layer) 서비스 개발 표준 교육

· 시범 기관에서 개발 중 당면한 문제 해결 지원

차세대 프레임워크 구축 지원

· 시범 기관 개발 과정에서 발견된 오류와 해결 방안을 반영하여 프레임워크 안정화에 기여

· 사용자 및 개발자 요구사항 분석 및 개발팀과 협의하여 개선 방안 도출

· 영구기록물관리기관용 교육 및 산출물 문서화, 개발 표준 계획

○ 수행기간 : 2018년(1년)

○ 소요 예산 : 개발(총 533백만원) 구축 지원(총 148백만원)

○ 산출내역

386

차세대 영구기록관리시스템 서비스 개발 소프트웨어 개발비 산정 - 투입공수에 의한 방식 (소프트웨어사업대가산정가이드,2017.KOSA) ○ 투입공수에 의한 방식의 개발원가 산정 (단위 : 원) 평균임금 투입공수 한달일수 구분 금액 (2017년기준) (MM) (2017년기준) 기술사 452,611 특급기술자 391,068 고급기술자 305,353 12.0 20.8 76,216,109 중급기술자 239,506 12.0 59,780,698 초급기술자 191,320 12.0 47,753,472 직접인건비 합계 183,750,278 제경비(직접인건비의 110 ~ 120%) 120% 220,500,334 기술료([직접인건비 + 제경비]의 20 ~ 40%) 20% 80,850,122 직접경비 0 합 계 (부가세 별도) 485,100,735 부가세(VAT) 48,510,073 합 계 (부가세 포함) 533,600,000

차세대 영구기록관리시스템 구축 지원 소프트웨어 개발비 산정 - 투입공수에 의한 방식 (소프트웨어사업대가산정가이드,2017.KOSA)

○ 투입공수에 의한 방식의 개발원가 산정 (단위 : 원) 평균임금 투입공수 한달일수 구분 금액 (2017년기준) (MM) (2017년기준) 기술사 452,611 0 특급기술자 391,068 0

고급기술자 305,353 3.0 20.8 19,051,027

중급기술자 239,506 6.0 29,890,349

초급기술자 191,320 0 직접인건비 합계 48,944,376 제경비(직접인건비의 110 ~ 120%) 120% 58,733,251 기술료([직접인건비 + 제경비]의 20 ~ 40%) 20% 26,919,407 직접경비 0 합 계 (부가세 별도) 134,597,034

부가세(VAT) 13,459,703

합 계 (부가세 포함) 148,000,000

387

다. 차세대 영구기록관리시스템 확산

○ 목적

영구기록물관리시스템 구축 예정인 기관이 차세대 기록관리시스템 프레임워크을 활용하여 원활히 개발할 수 있도록 기술지원 전담 조직을 구성함

기관에서 기록관리시스템 프레임워크을 이용하여 효율적으로 시스템 개발이 가능하도록 지원

적용 중 발견된 오류, 개선사항 및 요구사항을 차세대 기록관리 프레임워크에 반영하여 조기 안정화

○ 주요 내용

구축 기관 시스템 기술지원

· 차세대 기록관리 프레임워크의 보존 레이어(Preservation Layer) 서비스 기반 개발 방법 교육

· 보존 레이어 적용 시 발생하는 문제 및 요구사항 업무 협의 및 분석

· 기관 고유 업무 레이어(Business Layer) 서비스 개발 표준 교육

· 구축 기관에서 개발 중 당면한 문제 해결 지원

차세대 프레임워크 개발 지원

· 구축 기관 개발 과정에서 발견된 오류와 해결 방안을 반영하여 프레임워크 안정화에 기여

· 사용자 및 개발자 요구사항 분석 및 개발팀과 협의하여 개선 방안 도출

· 영구기록물관리기관을 위한 교육 및 산출물 문서화, 개발 지침 및 표준 계획

○ 수행기간 : 2025년 ~ 2027년(3년)

○ 소요 예산 : 총 296백만원

○ 산출내역

388

영구기록물관리시스템 확산 소프트웨어 개발비 산정 - 투입공수에 의한 방식

(소프트웨어사업대가산정가이드,2017.KOSA)

○ 투입공수에 의한 방식의 개발원가 산정 (단위 : 원)

평균임금 투입공수 한달일 수 구분 금액 (2017년기준) (MM) (2017년기준)

기술사 452,611 0

특급기술자 391,068 0

고급기술자 305,353 6.0 20.8 38,108,054

중급기술자 239,506 12.0 59,780,698

초급기술자 191,320 0

직접인건비 합계 97,888,752

제경비(직접인건비의 110 ~ 120%) 120% 117,466,502

기술료([직접인건비 + 제경비]의 20 ~ 40%) 20% 53,838,814

직접경비 0

합 계 (부가세 별도) 269,194,068

부가세(VAT) 26,919,406

합 계 (부가세 포함) 296,100,000

라. 국가기록 클라우드 기반체계 구축

○ 목적

중앙영구기록관리시스템의 인프라의 IaaS 구축이 완료됨에 따라 이를 향후 영구기록관리시스템의 SaaS 구축의 인프라로 활용할 수 있도록 국가기록 클라우드 기반체계로 완성

○ 주요 내용

다수 기관이 자원 공유, 자동 배분이 가능한 IaaS 구축 완료

국가기록 클라우드 PaaS 구축, SaaS 환경 마련

○ 수행기간 : 2023년 ~ 2024년(2년)

○ 소요 예산 : 총 1,000백만원

389

마. 국가기록 클라우드 차세대 영구기록관리시스템 구축

○ 목적

클라우드 환경에서 운영하는 영구기록관리시스템을 구축하여 클라우드나 인프라가 준비되지 않은 지방기록물관리기관이 이용할 수 있게 함

○ 주요 내용

영구기록관리시스템 SaaS

○ 수행기간 : 2025년 ~ 2027년(3년)

○ 소요 예산 : 총1,600백만원

○ 산출내역

국가기록 클라우드 차세대 영구기록관리시스템 구축 소프트웨어 개발비 산정 - 투입공수에 의한 방식

(소프트웨어사업대가산정가이드,2017.KOSA)

○ 투입공수에 의한 방식의 개발원가 산정 (단위 : 원)

평균임금 투입공수 한달일 수 구분 금액 (2017년기준) (MM) (2017년기준)

기술사 452,611

특급기술자 391,068 고급기술자 305,353 36.0 20.8 228,648,326

중급기술자 239,506 36.0 179,342,093

초급기술자 191,320 36.0 143,260,416 직접인건비 합계 551,250,835

제경비(직접인건비의 110 ~ 120%) 120% 661,501,002 기술료([직접인건비 + 제경비]의 20 ~ 40%) 20% 242,550,367

직접경비 0 합 계 (부가세 별도) 1,455,302,205

부가세(VAT) 145,530,220

합 계 (부가세 포함) 1,600,800,000

390

8.6. 차세대 기록관리시스템 구축 이행 과제

가. 차세대 기록관리시스템 시범 구축

○ 목적

차세대 기록관리 프레임워크를 이용하여 기록관리시스템 필수 서비스 중심으로 개발하여 시범 구축, 각 기관에서 차세대 기록관리시스템으로 교체하여 구축하고자 할 때 활용하도록 함

○ 주요 내용

차세대 기록관리 프레임워크를 이용하여 필수 기능으로 작동하는 기본형 기록관리시스템 개발

기본형 시스템을 이용한 개발 방안, 개발 지침 등 개발

완성된 서비스 모듈 소스는 기록관리 프레임워크 오픈소스 생태계로 반환

○ 수행기간 : 2021년(1년)

○ 소요 예산 : 총 533백만원

○ 산출내역

차세대 기록관리시스템 시범 구축 소프트웨어 개발비 산정 - 투입공수에 의한 방식

(소프트웨어사업대가산정가이드,2017.KOSA)

○ 투입공수에 의한 방식의 개발원가 산정 (단위 : 원)

평균임금 투입공수 한달일수 구분 금액 (2017년기준) (MM) (2017년기준)

기술사 452,611

특급기술자 391,068

고급기술자 305,353 12.0 20.8 76,216,109 중급기술자 239,506 12.0 59,780,698 초급기술자 191,320 12.0 47,753,472 직접인건비 합계 183,750,278 제경비(직접인건비의 110 ~ 120%) 120% 220,500,334 기술료([직접인건비 + 제경비]의 20 ~ 40%) 20% 80,850,122 직접경비 0 합 계 (부가세 별도) 485,100,735 부가세(VAT) 48,510,073 합 계 (부가세 포함) 533,600,000

391

나. 차세대 기록관리시스템 구축

○ 목적

차세대 기록관리시스템 프레임워크에 기반을 두어 기록물관리시스템을 우선적으로 구축하고자 하는 기과 업무 협의 및 기술지원을 제공함

시범 기관에서 차세대 기록관리시스템 프레임워크 적용 시 시행착오를 최소화하여 빠른 시일 내 시스템 구축할 수 있도록 지원

프레임워크 개발팀에 사용자 요구사항 및 오류 등 문제를 전달하고 협의하여 차세대 기록관리시스템 프레임워크의 업그레이드와 안정화 방안 수립

○ 주요 내용

시범 기관 시스템 기술지원

· 차세대 기록관리 프레임워크의 보존 레이어(Preservation Layer) 서비스 기반 개발 방법 교육

· 보존 레이어 적용 시 발생하는 문제 및 요구사항 업무 협의 및 분석

· 기관 고유 업무 레이어(Business Layer) 서비스 개발 표준 교육

· 시범 기관에서 개발 중 당면한 문제 해결 지원

차세대 프레임워크 개발 지원

· 시범 기관 개발 과정에서 발견된 오류와 해결 방안을 반영하여 프레임워크 안정화에 기여

· 사용자 및 개발자 요구사항 분석 및 개발팀과 협의하여 개선 방안 도출

· 영구기록물관리기관용 교육 및 산출물 문서화, 개발 표준 계획

○ 수행기간 : 2021년(1년)

○ 소요 예산 : 총 173백만원

○ 산출내역

392

차세대 기록관리시스템 구축 소프트웨어 개발비 산정 - 투입공수에 의한 방식 (소프트웨어사업대가산정가이드,2017.KOSA)

○ 투입공수에 의한 방식의 개발원가 (단위 : 원) 산정 평균임금 투입공수 한달일 수 구분 금액 (2017년기준) (MM) (2017년기준) 기술사 452,611 특급기술자 391,068 고급기술자 305,353 20.8 중급기술자 239,506 12.0 59,780,698 초급기술자 191,320 0 직접인건비 합계 59,780,698 제경비(직접인건비의 110 ~ 120%) 120% 71,736,837 기술료([직접인건비 + 제경비]의 20 ~ 40%) 20% 26,303,507 직접경비 0 합 계 (부가세 별도) 157,821,042 부가세(VAT) 15,782,104 합 계 (부가세 포함) 173,600,000

다. 차세대 기록관리시스템 확산

○ 목적

차세대 기록관리시스템으로 전환 구축 예정인 기관이 차세대 기록관리시스템 프레임워크를 활용하여 원활히 개발할 수 있도록 기술지원 전담 조직의 구성

기관에서 기록관리시스템 프레임워크을 이용하여 효율적으로 시스템 개발이 가능하도록 지원

적용 중 발견된 오류, 개선사항 및 요구사항을 차세대 기록관리 프레임워크에 반영하여 조기 안정화

○ 주요 내용

구축 기관 시스템 기술지원

· 차세대 기록관리 프레임워크의 보존 레이어(Preservation Layer) 서비스 기반 개발 방법 교육

· 보존 레이어 적용 시 발생하는 문제 및 요구사항 업무 협의 및 분석

· 기관 고유 업무 레이어(Business Layer) 서비스 개발 표준 교육

· 구축 기관에서 개발 중 당면한 문제 해결 지원

393

차세대 프레임워크 개발 지원

· 구축 기관 개발 과정에서 발견된 오류와 해결 방안을 반영하여 프레임워크 안정화에 기여

· 사용자 및 개발자 요구사항 분석 및 개발팀과 협의하여 개선 방안 도출 · 기록관 담당자를 위한 교육 및 산출물 문서화, 개발 지침 및 표준 계획

○ 수행기간 : 2023년 ~ 2027년(5년)

○ 소요 예산 : 총 636백만원

○ 산출내역 : 2023년 ~ 2027년(5년)

차세대 기록관리시스템 확산 소프트웨어 개발비 산정 - 투입공수에 의한 방식

(소프트웨어사업대가산정가이드,2017.KOSA)

○ 투입공수에 의한 방식의 개발원가 산정 (단위 : 원)

평균임금 투입공수 한달일수 구분 금액 (2017년기준) (MM) (2017년기준)

기술사 452,611

특급기술자 391,068

고급기술자 305,353 20.8

중급기술자 239,506 20.0 99,634,496

초급기술자 191,320 30.0 119,383,680

직접인건비 합계 219,018,176

제경비(직접인건비의 110 ~ 120%) 120% 262,821,811

기술료([직접인건비 + 제경비]의 20 ~ 40%) 20% 96,367,997

직접경비 0

합 계 (부가세 별도) 578,207,985

부가세(VAT) 57,820,798

합 계 (부가세 포함) 636,000,000

394

8.7. 차세대 기록관리 프레임워크 구축 이행 과제

가. 차세대 기록관리 오픈소스 전략 구현 사업

○ 목적

2017년 ‘차세대 전자기록관리 모델 재설계’ 사업을 통해 수립된 차세대 전자기록관리 시스템 모델 구현

차세대 전자기록관리 시스템 확산을 위한 기록 오픈소스 활용 기반 마련

○ 주요 내용

[1차년도] 차세대 전자기록관리 시스템 프레저베이션 영역 필수 모듈 개발

· 기록서비스, 분류체계서비스, 입수서비스, 처분일정서비스, 처분동결서비스, 접근권한관리서비스, 시스템관리서비스, 워크플로우서비스

· 재사용가능한 전자기록관리 시스템 모듈을 정비하고, 오픈소스 발굴을 위한 전략 수립

[2차년도] 차세대 전자기록관리 시스템 프레저베이션 영역 선택 모듈 개발

· 콘텐츠서비스, 전자기록물 스토리지서비스, 비전자기록물 스토리지서비스, 디지털보존서비스, 포탈서비스, 전거관리서비스, 내보내기서비스, 필수기록물관리서비스

· 오픈소스 확산을 위한 깃허브(GitHub) 사이트 계정 오픈과 소프트웨어 소스 및 문서 업로드

[3차년도] 차세대 전자기록관리 시스템 비즈니스 영역 모듈 개발

· 원문공개서비스, 반입반출서비스, 평가서비스, 열람관리서비스, 정수점검서비스, 지 적 재 산권관리서비스, 기록물이관서비스, 공개재분류서비스, 조직관리서비스, 리드케이스관리서비스, 지능형검색서비스 등

· 오픈소스 공유를 위한 커뮤니티 구성과 교육 및 홍보방안 수립

○ 수행기간 : 2018년 ~ 2020년(3년)

세부 과제 수행기간(년)

제1과제 기록관리 응용소프트웨어 마이크로서비스화 2018 ~ 2020

제2과제 차세대 전자기록관리 플랫폼 구축 2019

제3과제 기록 오픈소스 생태계 기반 구축 2020

<표 191> 차세대 기록관리 오픈소스 전략 구현 사업 수행기간

395

○ 소요 예산 : 총 4,000백만원

세부 과제별 소요 예산

세부 과제 수행기간(년) 예산 (백만원)

제1과제 기록관리 응용소프트웨어 마이크로서비스화 2018 ~ 2020 3,000

제2과제 차세대 전자기록관리 플랫폼 구축 2019 500

제3과제 기록 오픈소스 생태계 기반 구축 2020 500

<표 192> 차세대 기록관리 오픈소스 전략 구현 사업 소요 예산

○ 산출내역

[제1과제] 기록관리 응용소프트웨어 마이크로서비스화

"제1과제 기록관리 응용소프트웨어 마이크로서비스화“ 소프트웨어 개발비 산정 - 투입공수에 의한 방식

(소프트웨어사업대가산정가이드,2017.KOSA) ○투입공수에 의한 방식의 개발원가산정 (단위 : 원) ※3개년합계 한달일 수 평균임금 투입공수 구분 (2017년기 금액 (2017년기준) (MM) 준) 기술사 452,611 0 특급기술자 391,068 24.0 195,221,146 고급기술자 305,353 24.0 20.8 152,432,218 중급기술자 239,506 24.0 119,561,395 초급기술자 191,320 97.0 386,007,232 직접인건비 합계 853,221,990 제경비(직접인건비의 110 ~ 120%) 110% 938,544,189 기술료([직접인건비 + 제경비]의 20 ~ 40%) 20.29% 363,549,358 직접경비 572,000,000 합 계 (부가세 별도) 2,727,315,538 부가세(VAT) 272,731,554 합 계 (부가세 포함) ※ 만단위 절사 3,000,000,000

○ 직접경비 (단위 : 원) 구분 산출내역 금액 SW구입 검색, AI, 빅데이터 엔진, 보존포맷, DBMS 등 500,000,000 6인x60회(1박2일기준) 출창여비 72,000,000 (200,000원x6인x60회=72,000,000원)

합 계 572,000,000

396

[제2과제] 차세대 전자기록관리 플랫폼 구축

"차세대 전자기록관리 오픈소스 전략 구현 사업" 정보전략계획 및 업무재설계(ISP/BPR)수립비 산정 - 투입공수에 의한 방식

(소프트웨어사업대가산정가이드,2017.KOSA)

○ ISP/BPR 컨설팅 대가 산정 (단위 : 원)

투입공 컨설턴트 한달일 수 구분 수 금액 평균임금 (2017년기준) (MM) 수석 컨설턴트 400,000 3 24,960,000

책임 컨설턴트 350,000 5 36,400,000

전임 컨설턴트 300,000 7 20.8 40,560,000

컨설턴트 250,000 7 36,400,000

보조 컨설턴트 200,000 8 33,280,000

직접인건비 합계 171,600,000

제경비(직접인건비의 110 ~ 120%) 110% 188,760,000

기술료([직접인건비 + 제경비]의 20 ~ 40%) 22.94% 82,666,584

직접경비 11,600,000

합 계 (부가세 별도) 454,626,584

부가세(VAT) 45,462,658

합 계 (부가세 포함) ※ 만단위 절사 500,000,000

○ 직접경비 (단위 : 원)

구분 산출내역 금액

정보전략마스터플랙보고서등8종x4부 보고서인쇄비 1,600,000 (50원x1,000매x4부x8종=1,600,000원)

5인x10회(1박2일기준) 출장여비 10,000,000 (200,000원x5인x10회=10,000,000원)

합 계 11,600,000

397

[제3과제] 기록 오픈소스 생태계 기반 구축

"제3과제 기록 오픈소스 생태계 기반 구축" 정보전략계획 및 업무재설계(ISP/BPR)수립비 산정 - 투입공수에 의한 방식

(소프트웨어사업대가산정가이드,2017.KOSA)

○ ISP/BPR 컨설팅 대가 산정 (단위 : 원)

한달일수 컨설턴트 투입공수 구분 (2017년기 금액 평균임금 (MM) 준) 수석 컨설턴트 400,000 3 24,960,000

책임 컨설턴트 350,000 5 36,400,000

전임 컨설턴트 300,000 6 20.8 34,320,000

컨설턴트 250,000 8 41,600,000

보조 컨설턴트 200,000 8 34,528,000 직접인건비 합계 171,808,000 제경비(직접인건비의 110 ~ 120%) 110% 188,988,800

기술료([직접인건비 + 제경비]의 20 ~ 40%) 22.78% 82,189,511

직접경비 11,600,000

합 계 (부가세 별도) 454,586,311

부가세(VAT) 45,458,631

합 계 (부가세 포함) ※ 만단위 절사 500,000,000

○ 직접경비 (단위 : 원)

구분 산출내역 금액

정보전략마스터플랙보고서등8종x4부 보고서인쇄비 1,600,000 (50원x1,000매x4부x8종=1,600,000원)

5인x10회(1박2일기준) 출장여비 10,000,000 (200,000원x5인x10회=10,000,000원)

합 계 11,600,000

나. 기록 오픈소스 고도화

○ 목적

차세대 기록관리 프레임워크 플랫폼과 생태계를 오픈소스 정책 하에서 운영 및 관리함으로써 안정적인 개발과 협력의 공간과 도구 제공

398

차세대 기록관리 프레임워크 오픈소스 생태계의 홍보와 교육으로 커뮤니티 활동 지원

산출물, 개발 표준의 관리로 오픈소스의 품질 유지

○ 주요 내용

차세대 기록관리 프레임워크 소스 버전 관리, 개발 산출물 및 개발 표준 관리

커뮤니티 회원 및 활동 관리, 생태계 홍보

프레임워크 소스의 품질 관리

○ 수행기간 : 2021 ~ 2022년(2년)

○ 소요예산 : 총 624백만원

○ 산출내역

기록 오픈소스 고도화 소프트웨어 개발비 산정 - 투입공수에 의한 방식

(소프트웨어사업대가산정가이드,2017.KOSA)

○ ISP/BPR 컨설팅 대가 산정 (단위 : 원)

한달일수 컨설턴트 투입공수 구분 (2017년기 금액 평균임금 (MM) 준)

기술사 452,611

특급기술자 391,068

고급기술자 305,353 20.8

중급기술자 239,506 24 119,561,395

초급기술자 191,320 24 95,506,944

직접인건비 합계 215,068,339

제경비(직접인건비의 110 ~ 120%) 110% 258,082,007

기술료([직접인건비 + 제경비]의 20 ~ 40%) 22.78% 94,630,069

직접경비

합 계 (부가세 별도) 567,780,415

부가세(VAT) 56,778,041

합 계 (부가세 포함) 624,500,000

399

다. 지능행정 서비스 고도화

○ 목적

차세대 기록관리 프레임워크의 개발 및 활용 현황을 점검하고 발전 방향 제시

개발 커뮤니티 및 기관에서 활용 성과물의 오픈소스 반영

자연어 처리 플랫폼 및 시청각기록물 영상인식 플랫폼, 시청각기록물 음성인식 플랫폼의 구축이 2022년 3단계까지 완료되고 서비스 API가 개발됨에 따라 인공지능 활용 API를 이용하여 차세대 기록관리 프레임워크의 비즈니스 레이어에서 작동하는 서비스 개발

기록정보 LOD 구축 사업의 3단계가 완료되어 감에 따라 기록정보 활용 애플리케이션 제작과 웹서비스 및 통합 검색 개발 여건이 조성됨에 따라 차세대 기록관리 프레임워크 기반 기록관리시스템이 LOD 기반 범국가적 공공기록 네트워크에 일원으로 참여

○ 주요 내용

지능행정 기반 구축

· 차세대 기록관리 프레임워크 소스 버전 관리, 개발 산출물 및 개발 표준 관리

· 프레임워크 소스 버전 관리

· 기관에서 프레임워크 기반으로 개발한 성과를 오픈 소스에 반영

· 시청각기록물의 영상인식에 의한 메타데이터 자동 포착, 레이블, 유해성 및 속성 검출, 감성 분석 서비스 개발

· 시청각기록물의 음성인식에 의한 메타데이터 자동 포착 · 자연어 처리 기술을 활용한 기록물 자동 분류 서비스 개발

· 차세대 기록관리 프레임워크의 비즈니스 레이어에서 기록관리시스템이나 영구기록물관리시스템 및 중앙영구기록물관리시스템의 지능행정 서비스로서 연계 동작하도록 개발

지능행정 서비스 개발

· 기록정보 LOD 구축 사업의 3단계가 완료되어 감에 따라 기록정보 활용 애플리케이션 제작과 웹서비스 및 통합 검색 개발 여건이 조성됨

· 차세대 기록관리 프레임워크 기반 기록관리시스템이 LOD 기반 범국가적 공공기록 네트워크에 일원으로 참여

시맨틱웹 서비스 개발

· 차세대 기록관리 프레임워크의 비즈니스 레이어에서 동작하여 기록관리시스템, 영구기록물관리시스템 및 중앙영구기록물관리시스템이 범국가적 공공기록 네트워크에 참여할 수 있는 LOD 활용 통합 검색 서비스

○ 수행기간 : 2023년 ~ 2027년(5년)

○ 소요예산 :

400

지능행정 기반 구축: 총 624백만원

지능행정 서비스 개발: 총 383백만원

시맨틱웹 서비스 개발: 총 241백만원

○ 산출내역

지능행정 기반 구축 소프트웨어 개발비 산정 - 투입공수에 의한 방식

(소프트웨어사업대가산정가이드,2017.KOSA)

○ ISP/BPR 컨설팅 대가 산정 (단위 : 원)

한달일수 컨설턴트 투입공수 구분 (2017년기 금액 평균임금 (MM) 준)

기술사 452,611

특급기술자 391,068

고급기술자 305,353 20.8

중급기술자 239,506 24 119,561,395

초급기술자 191,320 24 95,506,944

직접인건비 합계 215,068,339

제경비(직접인건비의 110 ~ 120%) 110% 258,082,007

기술료([직접인건비 + 제경비]의 20 ~ 40%) 22.78% 94,630,069

직접경비

합 계 (부가세 별도) 567,780,415

부가세(VAT) 56,778,041

합 계 (부가세 포함) 624,500,000

401

지능행정 서비스 개발 소프트웨어 개발비 산정 - 투입공수에 의한 방식 (소프트웨어사업대가산정가이드,2017.KOSA) ○ ISP/BPR 컨설팅 대가 산정 (단위 : 원) 한달일수 컨설턴트 투입공수 구분 (2017년기 금액 평균임금 (MM) 준) 기술사 452,611 특급기술자 391,068 고급기술자 305,353 8.0 20.8 50,810,739 중급기술자 239,506 8.0 39,853,798 초급기술자 191,320 12.0 47,753,472 직접인건비 합계 138,418,010 제경비(직접인건비의 110 ~ 120%) 110% 152,259,811 기술료([직접인건비 + 제경비]의 20 ~ 40%) 22.78% 58,135,564 직접경비 0 합 계 (부가세 별도) 348,813,384 부가세(VAT) 34,881,338 합 계 (부가세 포함) 383,600,000

시맨틱웹 서비스 개발 소프트웨어 개발비 산정 - 투입공수에 의한 방식 (소프트웨어사업대가산정가이드,2017.KOSA) ○ ISP/BPR 컨설팅 대가 산정 (단위 : 원)

한달일수 컨설턴트 투입공수 구분 (2017년기 금액 평균임금 (MM) 준) 기술사 452,611 특급기술자 391,068 고급기술자 305,353 4.0 20.8 25,405,370 중급기술자 239,506 6.0 29,890,349 초급기술자 191,320 8.0 31,835,648 직접인건비 합계 87,131,366 제경비(직접인건비의 110 ~ 120%) 110% 95,844,503 기술료([직접인건비 + 제경비]의 20 ~ 40%) 22.78% 36,595,174 직접경비 0 합 계 (부가세 별도) 219,571,043 부가세(VAT) 21,957,104 합 계 (부가세 포함) 241,500,000

402

8.8. 이행 과제 요약

1단계 2단계 3단계 예산 주관 사업 이행과제 18 19 20 21 22 23 24 25 26 27 (백만원) 부서 기술지원센터 중앙부처 기록화 사례 개발 112 (신규) 기술지원센터 지자체 기록화 사례 개발 112 (신규) 기술지원센터 기타기관 기록화 사례 개발 112 (신규) 기술지원센터 특수유형 기록화 사례 개발 112 데이터 (신규) 세트 기술지원센터 신유형 기록화 사례 개발 112 관리 (신규) 체계 기술지원센터 데이터세트관리시스템 구축 559 (신규) 기술지원센터 데이터세트 관리 고도화 559 (신규) 기술지원센터 데이터세트 보존 체계 구축 689 (신규) 소계 2,367 기술지원센터 자원통합 8,530 차세대 (신규) 중앙 기술지원센터 클라우드 IaaS 구축 1,500 영구 (신규) 기록 클라우드 SaaS 기술지원센터 1,500 관리 중앙영구기록관리시스템 구축 (신규) 시스템 소계 11,530

차세대 기록관리시스템 구축 기술지원센터 683 정보화전략계획 (신규)

차세대 영구기록관리시스템 기술지원센터 533 서비스 개발 (신규)

차세대 차세대 영구기록관리시스템 기술지원센터 148 영구 시범 구축 지원 (신규) 기록 차세대 영구기록관리시스템 기술지원센터 296 관리 확산 (신규) 시스템 국가기록 클라우드 기반체계 기술지원센터 1,000 구축 (신규) 국가기록 클라우드 차세대 기술지원센터 1,600 영구기록관리시스템 구축 (신규)

소계 4,260

403

1단계 2단계 3단계 예산 주관 사업 이행과제 18 19 20 21 22 23 24 25 26 27 (백만원) 부서

차세대 기록관리시스템 기술지원센터 533 시범 구축 (신규)

차세대 기록관리시스템 기술지원센터 차세대 173 기록관리 구축 (신규) 시스템 차세대 기록관리시스템 기술지원센터 636 확산 (신규)

소계 1,342

기록관리 응용 SW 기술지원센터 3,000 마이크로서비스화 (신규) 기술지원센터 기록 오플소스 플랫폼 구축 500 (신규) 기록 오픈소스 생태계 기반 기술지원센터 500 구축 (신규) 차세대 기술지원센터 기록 오픈소스 생태계 육성 624 기록관리 (신규) 프레임 기술지원센터 차세대 기록 오픈소스 고도화 624 워크 (신규) 기술지원센터 지능 행정 서비스 개발 383 (신규) 기술지원센터 시맨틱웹 서비스 개발 241 (신규)

소계 7,232

1단계 합계 14,230

2단계 합계 3,909

3단계 합계 7,232

총 계 54,371

404

1.1. 행정정보시스템 기록관리체계 설계

○ 이 연구는 행정정보시스템 6개를 선정하여 현장 조사 실시 수 행정정보시스템 조사 및 분석 방법론을 개발하였으며, 그 결과로서 행정정보 데이터세트 기록화 시사점을 도출하여 검토하여 데이터세트 기록관리체계를 설계하였음

○ 행정정보 데이터세트의 특성으로 인해 현행 기록관리 법령 및 표준에서 다루지 못 하였거나 위배되는 사항을 검토하여 법률 개선안을 제안하였음

○ 행정정보시스템의 개수와 유형, 특성이 중앙부처만도 18,00개를 넘기 때문에 향후 사례 연구로서 관리 방안을 실제 적용하여 관리체계를 개선해가는 지속적인 연구 개발이 요망됨

1.2. 차세대 기록관리시스템 설계

○ 기록관리 대상 유형의 확대, 자산으로서의 기록관리, 기록 개념 변화에 대응하여 시스템 설계 방향을 연구하여, 기관 업무에 빠르게 대응하여 개발 가능한 마이크로서비스 아키텍처 기반 모듈성의 확보, 다양한 기록 유형 수용이 가능한 데이터 모델, 이관 방식의 다변화, 공개소프트웨어 활용 시대에 부응함

○ 통합 기록관리시스템의 보존 계층과 업무 계층을 분리하고 각 계층 별 필수 및 선택 서비스를 설계하였음

1.3. 영구기록물관리시스템 설계

○ 차세대 기록관리시스템은 통합 시스템으로서 기록관용 시스템과 영구기록물관리기관 시스템이 공통 핵심 서비스를 공유하도록 설계하고 개발하는 편이 소프트웨어 품질 향상은 물론 개발 및 유지보수의 비용과 시간 절감 효과를 가져올 것으로 판단함

○ 이 연구는 영구기록물관리시스템의 기능 요건을 정리하고 차세대 서비스를 이용한 구성 방안을 제시하였음. 향후 영구기록물관리시스템의 기능 요건을 시스템 기능으로 개발하기 위하여 영구기록관리 프로세스 재정립과 시스템 설계를 위한 정보화전략계획을 시작

○ 중앙영구기록물관리시스템은 이미 현행화하여 운영되고 있으므로 점진적 차세대 모델 적용이 필요함. 차세대 기록관리 기반체계로 발전해가기 위하여 인프라 전환부터 선행하도록 계획하였음

405

5.1. 활용성과

세부과제명 차세대 전자기록관리 프로세스와 시스템 설계

세부과제책임자 오세라/ 네모아이씨티(주) / 전자기록관리, 소프트웨어 개발

가. 연구논문

번호 논문제목 저자명 저널명 집(권) 페이지 Impact 국내/ SCI여부 factor 국외

나. 학술발표

번호 발표제목 발표형태 발표자 학회명 연월일 발표지 국내/ 국제

기록관리 새 바람에 맞춰 다시 설계 제9회 1 발표 오세라 2017.11.04 서울 국내 하는 기록관리시스템 전국기록인대회

차세대 기록관리 2세부, 차세대 기록관리 2 발표 오세라 모델 재설계 1차 2017.05.19 성남 국내 프로세스와 시스템 모델 워크숍

차세대 기록관리 전자기록관리의 프로세스〮시스템 3 발표 임진희 모델 재설계 2차 2017.09.26 대전 국내 혁신의 방향 워크숍

다. 지적재산권

번호 출원/ 특허명 출원(등록)인 출원(등록)국 출원(등록)번호 IPC분류 등록 1

라. 정책활용

· 전자기록물 장기보존포맷 관련 법령 및 규격 재설계 시 참고 · 행정정보데이터세트 관련 법령 및 지침 재설계 시 참고

406

마. 타연구 /차기연구에 활용

· 기록관리시스템의 마이크로서비스 아키텍처 기반 개발 · 행정정보 데이터세트 시스템별 기록화 사례 연구 · 행정정보 데이터세트의 보존 방안 연구 · 인공지능 및 빅데이터 분석이 가능한 기록시스템 구축방안 연구

바. 언론홍 보 및 대국민교육

사. 기타

· 행정정보 데이터세트 기록관리를 위한 현장조사 결과 보고, 국가기록원 표준화작업반 회의, 발표 및 토의, 2017.07.05. · 행정정보 데이터세트 기록관리체계, 국가기록원 표준화작업반 회의, 발표 및 토의, 2017.10.25

5.2. 활용계획

○ 행정정보시스템 데이터세트 기록관리체계 활용

기관과 시스템을 선정, 행정정보 데이터세트 기록관리 적용 사례 발굴

행정정보 데이터세트 기록관리 지침 개발

공공기록물관리법 개정 기초 자료

○ 차세대 기록관리시스템 설계 성과 활용

차세대 기록관리 프레임워크로 개발하기 위한 기능 규격으로 활용

현행 기록관리시스템의 차기 버전 설계와 개발 기초 자료

○ 차세대 영구기록관리시스템 설계 성과 활용

차세대 중앙영구기록물관리시스템 구축 계획

지방 영구기록물관리시스템 기능 요건 및 구축 정책 수립 기초 자료

국가기록 클라우드 기반 체계 마련 및 확장 발전 계획 수립 자료

407

1. 인력 변경

○ 연구원 변경 (채승훈 연구원 퇴사로 배영란 연구원으로 교체)

○ 보조 연구원 추가 투입 (연구 보조 업무 증가에 따라 전담 인력 투입)

2. 연구비 예산 변경

○ 행정정보시스템 현장조사 및 업무 협의 증가로 전산처리비와 유인물비가 증가하여 교통통 신비로 충당함. (유인물비 48,000 증가, 전산처리비 74,000원 증가, 교통통신비 122,000 감소)

○ 부록 1 별첨

○ 1차 워크숍 발표자료(부록4 별첨)

오세라. ‘차세대 기록관리 프로세스와 시스템 모델’ 사업 소개

○ 2차 워크숍 발표자료(부록5 별첨)

임진희. ‘전자기록관리의 프로세스 시스템 혁신 방향’

○ 3차 워크숍 발표자료(부록6 별첨)

임진희. ‘차세대 전자기록관리시스템 설계’

○ 기록인대회 발표자료(부록7 별첨)

오세라. ‘기록관리 새 바람에 맞춰 다시 설계하는 기록관리시스템’

○ 연구 산출물

데이터베이스 분석 사전 요청서(별도 제출)

1차 기초조사표(별도 제출)

2차 기초조사표(별도 제출) 데이터세트관리기준표(별도 제출)

데이터세트관리기준표 작성 예시(별도 제출)

408

산림청 1차 기초조사표(별도 제출)

산림청 2차 기초조사표(별도 제출)

권익위 1차 기초조사표(별도 제출)

권익위 2차 기초조사표(별도 제출) KAIST 1차 기초조사표(별도 제출)

KAIST 2차 기초조사표(별도 제출) 특허청 1차 기초조사표(별도 제출)

특허청 2차 기초조사표(별도 제출)

국토부 1차 기초조사표(별도 제출)

국토부 2차 기초조사표(별도 제출)

화학물질안전원 1차 기초조사표(별도 제출)

화학물질안전원 2차 기초조사표(별도 제출) 산림청 기능 분석(별도 제출)

산림청 테이블 분석(별도 제출)

산림청 테이블 관계 분석(별도 제출)

권익위 테이블 분석(별도 제출)

권익위 테이블 관계 분석(별도 제출)

권익위 컬럼 분석(별도 제출)

KAIST 테이블 분석(별도 제출)

KAIST 테이블 관계 분석(별도 제출)

KAIST 컬럼 분석(별도 제출)

409

세부 연구과제 요약

과제 자동부여 공개가능여부 고유번호

주관과제명 차세대 기록관리 모델 재설계 연구 개발

제 2 세부과제명 차세대 전자기록관리 프로세스와 시스템 설계

성 명 오 세 라

연구책임자 소속 기관명 네모아이씨티(주)

전자우편 [email protected] 전화번호 010 9379 7240

○ 연구목표 (400 ～600자)

현행 전자기록관리 프로세스와 표준 시스템 분석 및 ICBM 기술 동향 분석을 통하여 시사점을 도출하고, 새 로운 기록관리 개념 및 신기술을 적용하기 위한 설계 방향 제시하며, 시스템 설계 방향에 따라 범정부 클라 우드 환경 차세대 기록관리시스템과 중앙영구기록물관리시스템 및 영구기록물관리시스템 설계하며, 다양한 기록 유형의 관리를 위하여 행정정보데이터세트 기록관리 체계 설계

○ 연구내용 (1000～1200자)

Ÿ 현행 전자기록관리 프로세스와 시스템 분석 현행 환경 분석을 위하여 현행 기록관리 프로세스와 시스템을 분석 밍 설계를 위한 시사점 도출 Ÿ 행정정보 데이터세트 기록관리체계 설계 시스템 유형별 6개 대표 시스템을 선정하여 시스템 및 데이터에 대한 현장 조사 및 시스템 분석. 분서 결과 데 이터세트 기록관리 시 고려할 시사점을 도출하였음. 조사 분석과정을 심화하여 시스템 조사 및 분석 방법론을 체계화하였음. 시사점을 고려하여 데이터세트관리기준표를 개발하고 데이터세트 관리 프로세스 및 관리시스템을 설계하였음. 데이터세트관리 실현에 필요한 관련 근거 법령 마련을 위하여 현행 공공기록물관리법을 검토하여 개선안 제시 Ÿ 차세대 기록관리시스템 설계 설계 방향으로서 모율화, 이관 형태 다양화, 상호운용성, 다양한 기록 유형 포괄 데이터구조, 쿨라우드 서비스화, 입수/보존/배포 패키지 구현 프로세스의 특징을 갖는 기록관리시스템의 서비스 모듈과 기능 요건 설계 Ÿ 중앙영구기록관리시스템 재설계 중앙영구기록관리시스템을 클라우드 환경 차세대 기록관리시스템으로 재설계 방안과 인프라 및 응용 설계 Ÿ 영구기록관리시스템 설계 차세대 기록관리시스템 서비스 모듈을 활용한 영구기록관리시스템 기능 요건과 구성방안 설계 및 구축 계획 수 립

410

○ 연구성과(응용분야 및 활용범위포함) (400 ～600자)

Ÿ 이 연구는 기록관리시스템 설계의 기본 방향과 설계 방향에 의거하여 독립적인 필수 및 선택 서비스와 서비스의 기능 요건을 설계하였음. 모듈화된 기록관리시스템의 서비스는 생산기관과 영구기록물관리기관 을 모두 포괄하는 서비스의 기본 모델로 통합 기록관리시스템의 개발 프레임워크로서 개발 생태계와 함 께 발전시키면 기록관의 다양한 요구를 수용하는 확장성 있는 시스템 개발의 토대로 활용할 수 있음 Ÿ 기록관리 프레임워크를 이용하여 영구기록물관리시스템을 개발할 수 있도록 영구기록물관리시스템의 기 능 요건 설계와 구성 방안 그리고 클라우드 환경에서의 이행 과제를 도출하였음 Ÿ 행정정보시스템 현장 조사를 통하여 데이터세트 기록화의 특성을 도츌하고 데이터세트 기록관리체계를 설계하였으며, 데이터세트 관리체계는 데이터세트관리기준표와 기록관리 구현 프로세스를 포함하고, 관리 체계의 구현을 위해 마련되어야 하는 법 및 제도의 개선방안을 제시하였음.

○ 참여연구원

성 명 소속/직위 성 명 소속/직위 오세라 네모아이씨티(주)/대표이사 박정식 ㈜알엠소프트/차장 권영숙 네모아이씨티(주)/부장 채영란 ㈜알엠소프트/차장 윤영하 네모아이씨티(주)/이사 원규진 ㈜알엠소프트/과장 신동수 ㈜에이더블유아이/대표이사 임승민 ㈜에이더블유아이/연구원

행정정보데이터세트, 클라우드, 기록관리시스템, 영구기록물관리시스템, 중앙영구기록물 한글 Keywords 관리시스템, 모듈성 (5개 내외) dataset, cloud, records management system, archive management system, central 영문 archive management system, modularity,

411