KR20220004573A - 온톨로지 기반 머신 리더블 레귤레이션 시각화 시스템 및 방법 - Google Patents

Abstract

본 발명은 온톨로지 기반 머신 리더블 레귤레이션 시각화 시스템 및 방법에 있어서, 자연어로 표현된 법령 또는 규정을 형태소분석을 통해 온톨로지 요소들로 구분한 후 온톨로지코드(OWL code; 이하 온톨로지 코드)로 변환하여 저장하는 온톨로지 DB; 출력요청정보가 수신되면 상기 출력요청정보에 따라 상기 온톨로지 DB에 저장된 자연어로 표현된 법령 또는 규정을 온톨로지 요소간 관계에 따라 상위 법령 또는 규정으로부터 하위 법령 또는 규정까지 온톨로지 트리구조로 표시하는 표시모듈;을 포함하는 온톨로지 기반 머신 리더블 레귤레이션 시각화 시스템 및 방법에 관한 것이다. 본 발명에 따르면, 개념검증 대상의 법·규정을 형태소 분석 등 딥러닝을 활용한 자연어처리를 수행하여, 수작업보다 빠른 시간내에 처리할 수 있는 시간 단축 효과로 효율적인 자원 사용을 위한 기반을 마련했으며, 온톨로지를 이용하여 법·규정 변경시 배포의 일관성과 효과적인 머신 실행가능 레귤레이션 구조를 완성한 온톨로지 기반 머신 리더블 레귤레이션 시각화 시스템 및 방법을 제공할 수 있다.

Description

온톨로지 기반 머신 리더블 레귤레이션 시각화 시스템 및 방법{System and method for Ontology-based machine-readable regulation visualization}

본 발명은 온톨로지 기반 머신 리더블 레귤레이션 시각화 시스템 및 방법에 관한 것으로, 보다 상세하게는 자연어로 표현된 법령 또는 규정을 형태소분석을 통해 온톨로지 요소들로 구분한 후 온톨로지코드(OWL code; 이하 온톨로지 코드)로 변환하여 저장하는 온톨로지 DB; 출력요청정보가 수신되면 상기 출력요청정보에 따라 상기 온톨로지 DB에 저장된 자연어로 표현된 법령 또는 규정을 온톨로지 요소간 관계에 따라 상위 법령 또는 규정으로부터 하위 법령 또는 규정까지 온톨로지 트리구조로 표시하는 표시모듈;을 포함하는 온톨로지 기반 머신 리더블 레귤레이션 시각화 시스템 및 방법에 관한 것이다.

본 발명은 머신 리더블 레귤레이션에 관한 것이다.

금융회사는 금융 관련 법규에 따라 정기적(월/분기/반기/연)으로 1,939종(‘18.6월말)의 업무보고서를 수작업 작성함에 따라 금융회사의 보고서 작성 부담이 과중하며, 이에 따른 지연 제출 및 작성 오류 가능성이 상존하는 상황이다

다양한 국가들에서는 이를 개선하기 위해 MRR(Machine Readable Regulation; 이하 MRR)에 대한 다양한 논의가 있었는데 반해 한국의 경우 경제규모나 기술발전 수준에 비해 미온적이다.

미진한 이유로는 한국의 고유한 규제체계의 문제, 이해집단의 반대 등을 예로들 수 있다.

RegTech의 상위개념이라고 할 수 있는 LegalTech의 사례를 중심으로 살펴보면 첫째, 현행 변호사법에서는 이익 금지조항이 존재하며, 이러한 금지조항에 따라 원천적으로 변호사가 아닌 자는 원칙적으로 LegalTech에 참여할 수 없다.

또한, LegalTech는 자본과 기술이 접목되어 있기 때문에 기업이나 공공기관이 참여해야 하지만, 한국의 경우 원칙적으로 자본의 유입이 불가하다.

투입된 자본에 대해서 개발된 결과물로 이익이 나게 된다면, 이는 변호사법 위반이 되기 때문에 자본이 투여될 수 없는 환경이다.

둘째, LegalTech에 대해 변호사들이 이익 감소를 우려하여 수용을 꺼려한다.

변호사는 다양한 업무를 수행하지만, 송무에 대한 업무가 대다수이고, 간단한 송무 업무는 LegalTech에서 이미 실현 가능하지만, 변호사의 업무가 감소함을 우려하여 LegalTech에 대한 인식이 좋지 않은 편이다.

상술한 바와 같은 같은 문제점을 해결하기 위해 안출된 본 발명의 목적은, 개념검증 대상의 법·규정을 형태소 분석 등 딥러닝을 활용한 자연어처리를 수행하여, 수작업보다 빠른 시간내에 처리할 수 있는 시간 단축 효과로 효율적인 자원 사용을 위한 기반을 마련했으며, 온톨로지를 이용하여 법·규정 변경시 배포의 일관성과 효과적인 머신 실행가능 레귤레이션 구조를 완성한 온톨로지 기반 머신 리더블 레귤레이션 시각화 시스템 및 방법을 제공하기 위함이다.

또한, 본 발명의 다른 목적은, 온톨로지(RDF, OWL)화되어 있는 법·규정을 웹 기술(Spring DATA JPA) 기술을 이용하여 머신 실행가능 레귤레이션의 자동화 실행가능성을 높였으며, 오픈API와 해쉬값을 활용한 위변조 방지를 위한 블록체인(HyperLedger Fabric)의 프로토타입 구성과 금융클라우드의 활용은 시스템 구성의 시간과 비용의 감소를 통한 효율적인 온톨로지 기반 머신 리더블 레귤레이션 시각화 시스템 및 방법을 제공하기 위함이다.

상기한 바와 같은 목적을 달성하기 위한 본 발명의 특징에 따르면, 본 발명인 온톨로지 기반 머신 리더블 레귤레이션 시각화 시스템은, 자연어로 표현된 법령 또는 규정을 형태소분석을 통해 온톨로지 요소들로 구분한 후 온톨로지코드(OWL code; 이하 온톨로지 코드)로 변환하여 저장하는 온톨로지 DB; 출력요청정보가 수신되면 상기 출력요청정보에 따라 상기 온톨로지 DB에 저장된 자연어로 표현된 법령 또는 규정을 온톨로지 요소간 관계에 따라 상위 법령 또는 규정으로부터 하위 법령 또는 규정까지 온톨로지 트리구조로 표시하는 표시모듈;을 포함한다.

또한, 상기 출력요청정보는, 클라이언트를 통해 입력된 검색정보를 포함하는 것을 특징으로 하고, 상기 표시모듈은, 상기 검색정보가 수신되면 상기 검색정보를 온톨로지 코드로 변환하고, 변환된 온톨로지 코드를 포함하는 하나 이상의 법령 또는 규정들을 검출하여 출력하는 것을 특징으로 한다.

또한, 상기 온톨로지 트리구조는, 상위 법령 또는 규정으로부터 하위개념인 조, 항, 호 순서로 연결되어 표시되는 것을 특징으로 한다.

또한, 본 발명인 온톨로지 기반 머신 리더블 레귤레이션 시각화 시스템은, 상기 표시모듈에 표시된 상기 온톨로지 DB에 저장된 자연어로 표현된 법령 또는 규정 중 어느 하나가 선택된 후 수정정보가 수신되면 상기 수정정보에 포함된 교체법령정보를 검출하고 검출된 교체법령정보를 형태소분석하여 온톨로지 요소들로 구분한 후 온톨로지코드로 변환하여 저장하는 수정모듈;을 더 포함하는 것을 특징으로 한다

상기한 바와 같은 목적을 달성하기 위한 본 발명의 또 다른 특징에 따르면, 본 발명인 온톨로지 기반 머신 리더블 레귤레이션 시각화 방법은, (a) 자연어로 표현된 법령 또는 규정을 형태소분석을 통해 온톨로지 요소들로 구분한 후 온톨로지코드(OWL code; 이하 온톨로지 코드)로 변환하여 온톨로지 DB에 저장하는 단계; (b) 출력요청정보가 수신되면 상기 출력요청정보에 따라 상기 온톨로지 DB에 저장된 자연어로 표현된 법령 또는 규정을 온톨로지 요소간 관계에 따라 상위 법령 또는 규정으로부터 하위 법령 또는 규정까지 온톨로지 트리구조로 표시하는 단계;를 포함한다.

또한, 상기 출력요청정보는, 클라이언트를 통해 입력된 검색정보를 포함하는 것을 특징으로 하고, 상기 (b)단계는, 상기 검색정보가 수신되면 상기 검색정보를 온톨로지 코드로 변환하고, 변환된 온톨로지 코드를 포함하는 하나 이상의 법령 또는 규정들을 검출하여 출력하는 것을 특징으로 한다.

또한, 상기 온톨로지 트리구조는, 상위 법령 또는 규정으로부터 하위개념인 조, 항, 호 순서로 연결되어 표시되는 것을 특징으로 한다.

또한, 본 발명인 온톨로지 기반 머신 리더블 레귤레이션 시각화 방법은, (c) 상기 (b)단계를 통해 표시된 상기 온톨로지 DB에 저장된 자연어로 표현된 법령 또는 규정 중 어느 하나가 선택된 후 수정정보가 수신되면 상기 수정정보에 포함된 교체법령정보를 검출하고 검출된 교체법령정보를 형태소분석하여 온톨로지 요소들로 구분한 후 온톨로지코드로 변환하여 저장하는 단계;를 더 포함하는 것을 특징으로 한다.

이상 살펴본 바와 같은 본 발명에 따르면, 개념검증 대상의 법·규정을 형태소 분석 등 딥러닝을 활용한 자연어처리를 수행하여, 수작업보다 빠른 시간내에 처리할 수 있는 시간 단축 효과로 효율적인 자원 사용을 위한 기반을 마련했으며, 온톨로지를 이용하여 법·규정 변경시 배포의 일관성과 효과적인 머신 실행가능 레귤레이션 구조를 완성한 온톨로지 기반 머신 리더블 레귤레이션 시각화 시스템 및 방법을 제공할 수 있다.

또한, 본 발명에 따르면, 온톨로지(RDF, OWL)화되어 있는 법·규정을 웹 기술(Spring DATA JPA) 기술을 이용하여 머신 실행가능 레귤레이션의 자동화 실행가능성을 높였으며, 오픈API와 해쉬값을 활용한 위변조 방지를 위한 블록체인(HyperLedger Fabric)의 프로토타입 구성과 금융클라우드의 활용은 시스템 구성의 시간과 비용의 감소를 통한 효율적인 온톨로지 기반 머신 리더블 레귤레이션 시각화 시스템 및 방법을 제공할 수 있다.

도 1은 본 발명의 실시예에 따른 MDA와의 관련성에 대해 CIM, PIM, 및 PSM 관점으로 설명하는 예시도
도 2는 DRR2에서 자료 구조 제작 과정과 규칙 제작과정에 대한 순서도
도 3은 본 발명의 바람직한 실시예에 따른 MDA 설계 프로세스에 대한 데이터 구조 제작과정과 규칙 제작과정에 대한 순서도
도 4는 본 발명의 바람직한 실시예에 따른 MDA의 자체 개발 CIM를 나타낸 예시도
도 5는 PoC에서 자연어 규제문장의 PIM으로의 변환 예를 나타낸 예시도
도 6은 본 발명의 실시예에 따른 머신 리더블 레귤레이션 생성 시스템의 구성을 나타낸 블럭도
도 7은 본 발명의 실시예에 따른 머신 리더블 레귤레이션 생성 방법의 생성 순서를 나타낸 순서도
도 8은 퍼블릭 vs 프라이빗 DLT 비교한 예시도
도 9은 형태소 분석 및 딥러닝 단계의 전체 분석 과정을 나타낸 예시도
도 10은 형태소 분석 및 딥러닝 단계의 전체 분석 과정을 나타낸 예시도
도 11은 형태소 분석 과정 프로세스를 나타낸 예시도
도 12는 형태소 분석결과를 나타낸 예시도임
도 13은 규제문장과 관련한 딥러닝 분석을 나타낸 예시도
도 14는 ANN 알고리즘 적용 Rule 존재 유무에 대해 성능을 판정한 정확도 결과를 나타낸 예시도
도 15는 RNN 알고리즘 적용 Rule 존재 유무에 대해 성능을 판정한 정확도 결과를 나타낸 예시도
도 16은 LSTM 알고리즘 적용 Rule 존재 유무에 대해 성능을 판정한 정확도 결과를 나타낸 예시도
도 17은 형태소 분석결과와 딥러닝 수행의 처리결과를 나타낸 예시도
도 18은 온톨로지 요소와 규제문장 여부를 보여주는 UI 구축한 형태를 나타낸 예시도
도 19는 본 발명의 실시예에 따른 온톨로지 기반 머신리더블 레귤레이션 시각화 시스템의 구성을 나타낸 블럭도
도 20은 본 발명의 실시예에 따른 온톨로지 기반 머신리더블 레귤레이션 시각화 방법의 제공 순서를 나타낸 순서도
도 19는 법령시각화에 대한 플로우(flow)를 보여주는 예시도
도 21은 법령 온톨로지의 전체 구조 가운데 일부인 법령에 해당되는 내용을 도식화한 예시도
도 22는 위해서는 온톨로지 내용과 금융DB 내용이 연계되어 매핑된 나타낸 예시도
도 23은 본 발명의 실시예에 따른 매핑 테이블을 이용한 온톨로지와 금융DB의 연동 시스템의 구성을 나타낸 블럭도
도 24는 본 발명의 실시예에 따른 매핑 테이블을 이용한 온톨로지와 금융DB의 연동 방법의 제공 순서를 나타낸 순서도
도 25는 생성된 두 개의 JPA Repository 클래스를 나타낸 예시도
도 26은 보고서 생성 REST API를 제공하는 자동생성된 Controller 클래스의 예를 나타낸 예시도
도 27은 MRR 시각화 관계망 내의 법령 검색화면을 나타낸 예시도
도 29은 보고 체계 시스템 개념 검증 프로세스의 전체 업무의 흐름을 나타낸 흐름도
도 30는 보고 체계 시스템별 업무 구분에 따른 시스템별 구성을 나타낸 예시도
도 31은 금융감독원 보고서 화면을 나타낸 예시도
도 32은 대시보드의 화면구성을 나타낸 예시도
도 33는 법령 변경 시 보고 체계 시스템 업무 프로세스를 나타낸 법령 변경 논리 구성도이다.

본 발명의 이점 및 특징, 그리고 그것들을 달성하는 방법은 첨부되는 도면과 함께 상세하게 후술되어 있는 실시예들을 참조하면 명확해질 것이다.

그러나 본 발명은 이하에서 개시되는 실시예들에 한정되는 것이 아니라 서로 다른 다양한 형태로 구현될 수 있으며, 단지 본 실시예들은 본 발명의 개시가 완전하도록 하고, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 발명의 범주를 완전하게 알려주기 위해 제공되는 것이며, 본 발명은 청구항의 범주에 의해 정의될 뿐이다. 명세서 전체에 걸쳐 동일 참조 부호는 동일 구성 요소를 지칭한다.

이하, 본 발명의 실시예들에 의하여 머신 리더블 레귤레이션 생성 시스템 및 방법을 설명하기 위한 도면들을 참고하여 본 발명에 대해 설명하도록 한다.

본 발명은, 클라이언트로부터 유선 또는 무선으로 자연어로 표현된 법령 또는 규정이 입력되면 입력된 법령 또는 규정을 기록매체에 기록된 프로그램을 통해 인식할 수 있는 언어로 변환하는 시스템 및 방법에 관한 것이다.

우선 개념을 정리하자면, 본 발명의 전반에 걸쳐 기재된 온톨로지란 원래 철학 용어인‘존재론’의 의미이며, 논리 이론에서 차용해 온 개념이다.

영국 등에서 MRR 표현을 위해 OWL 등 온톨로지 언어를 사용하고 있다.

온톨로지란 “an explicit specification of a conceptualization”, 즉 세상에 존재하는 개념을 기계가 이해할 수 있는 형태로 모델링하는 방법 중 하나이며 개념 모델링의 방법이다.

온톨로지 언어로는 그 표현력에 따라 XML, RDF, DAML (by DARPA), DAML+OIL, OWL의 순으로 표현이 더욱 풍부하다.

특히 OWL은 논리 규칙 표현 여부에 따라 OWL DL, OWL Lite 등으로 분류되며, 인스턴스 값만을 따로 관리하기 위해 OWL Instance를 가질 수 있다.

온톨로지 언어는 대체로 다음과 같이 구성된다.

Entity: 개념에 등장하는 모든 구성 요소의 통칭

Class: 객체의 의미를 가짐 (예: 법령, 금융기관 등)

Individual: Class 의 인스턴스의 의미 (예: 제63조 1항, xx은행 등)

Object Property: 관계성의 의미 (예: 감독(금융감독기관, 금융기관)에서 ‘감독’)

Data Property: 객체들의 속성의 의미 (예: 금융기관의 상호명, 주소 등)

금융법령과 같은 텍스트로부터 온톨로지를 자동으로 제작하는 방법은 없다.

그러나 대체로 다음과 같은 원칙을 따른다.

Class: 명사형

Subclass, Superclass 존재 가능

Individual: 명사형 또는 문장으로 특정 class의 실제값

Object Property: 3형식 이상의 동사형이 해당할 가능성이 높으며, 이때 문장 상에 등장하는 주어는 Class Domain, 목적어는 Class Range 일 수 있다.

Data Property: 명사형으로 Class를 특징지어주는 것이며 문장 상에서 Class Domain과 함께 등장할 가능성이 높다.

온톨로지(특히 OWL, RDF) 제작 지원 도구로는 Protιgι, OntoEdit 이 가장 대표적이며, 이들을 대체로 Open API를 제공하므로 추후 MRR 시스템 내에서 호출이 가능하다.

온톨로지 시각화 도구로는 VOWL, OWLVIZ 가 가장 대표적이다.

규제문장 분석 및 온톨로지 시각화 하기 위해서는 아래와 같은 과정이 필요하다.

1, 자연어 문장을 분석하기 위해서는 형태소 분석이 필요하다.

규제 문장을 분석하기 위해서는 자연어 처리 기술이 필요하다.

자연어(自然語, Natural Language)란 의사소통의 목적으로 사용되고 있는 언어로서 인공적으로 제작되거나 인위적인 조작을 가한 것이 아닌 역사적으로 자연스럽게 점증 발전되어온 언어이다.

따라서, 자연어는 현대에 탄생하여 급격하게 발전되어온 컴퓨터(기계)가 이해하기 쉽게 구조화된 언어가 아니다.

컴퓨터는 자연어가 사용된 이후에 개발된 것이지만, 역시 자연어를 잘 이해하도록 구조화되어 있지 않다.

2. 문장 단위의 비정형 데이터는 단어 단위로 분리해야 한다.

비정형 데이터는 컴퓨터가 처리하기에는 매우 복잡한 형태로 되어 있으므로 정형데이터 또는 그와 유사한 형태로 변환해야 한다.

자연어로 된 비정형 데이터를 정형 데이터로 변환하기 위한 첫 번째 단계는 형태소 분석 과정이다.

형태소 분석은 전체 텍스트를 최소 의미 단위인 형태소로 분리하는 과정이다.

예를 들어 ‘전자문서가 생성된 이후 서명자가 지급인 본인임을 확인 가능’과 같은 문장이 입력되었다고 할 때, 컴퓨터는 이 문장 전체를 하나의 단위로 취급할 수는 없다.

하나의 단위로 취급하려면 그 단위가 많은 경우에 반복적으로 사용되어야 하는데, 위의 문장이 다시 사용될 일은 많지 않기 때문이다.

따라서 숫자형 데이터가 각 단위별로 의미 단위인 0~9 중 하나를 판별하듯이, 자연어 데이터도 반복적으로 사용되는 의미 단위를 파악해야 한다.

3. 분리된 각각의 단위는 문서에서 반복적으로 사용됨을 알 수 있다.

명사인 ‘전자문서, 서명자, 지급인, 본인, 확인, 가능’은 물론 형식적 의미를 갖는 형태소인 ‘-가, -ㄴ, -이-, -ㅁ, -을’들은 한국어 문장에서 반복적으로 사용되는 형태이다.

이들은 이후 머신러닝 단계에서 제한된 한국어 어휘 목록에 속하는 것으로 각각에 대하여 고유 식별 번호를 붙여 숫자로 변환하여 정형데이터처럼 사용할 수 있다.

4. 비정형 데이터를 숫자 형태의 정형 데이터로 치환한다.

형태소 분석된 텍스트 데이터는 정형 데이터와 유사하게 처리할 수 있다.

형태소 분석이 이루어지면 숫자로 표현되는 정형 데이터로 만들 수 있다.

예를 들어 1열은 ‘아이’, 2열은 ‘점심’, 3열은 ‘저녁’, … 으로 지정하고 각 위치에 해당 단어가 사용되었는지를 기록함. 예를 들어, ‘점심’의 위치는 [ , 2]가 되고, 첫 문장은 해당 위치에 ‘1’을, 두 번째 문장은 ‘0’을 주어 단어 출현 여부를 기록한다.

이와 같이 분류된 텍스트 문장은 단위가 형태소 단위로 빈도 계산이 된 것이므로 이후 머신러닝 및 딥러닝 과정에서 문장의 어휘를 이용한 분류 문제에 적용될 수 있다.

오픈소스 형태소 분석기로는 10여 가지 정도 있음

형태소 분석기는 개발에 최소 수 년의 시간이 소요되므로 개발 기관은 비공개로만 운영해 왔다.

그러나 최근 빅데이터에 대한 민간의 관심이 높아지기 시작한 2010년 이후 오픈 소스로 배포되는 버전들이 나타나기 시작하였다.

오픈소스 형태소분석기를 관리하는 Koalanlp에는 11개의 공개된 형태소분석기가 등재되어 있다.

상위에서 언급된 RHINO는 공개 버전이며, 본 발명에 사용된 RHINO는 비공개 버전(v3.7.3)으로 수행했고, 공개 버전과 비공개버전은 동일한 인터페이스를 가진다.

머신러닝은 인간의 학습능력을 컴퓨터상에서 재현하는 기술이다.

머신러닝은 인간이 모든 규칙을 세워야 하는 부분에 대하여 자동으로 규칙을 찾는 알고리즘이다.

머신러닝은 검색엔진, 스팸검출, 마케팅 예측, DNA 분석, 음성 및 문자 패턴 인식 등 광범위한 분야에서 사용되고 있다.

본 발명에서 사용하는 신경망 알고리즘은 뇌의 신경세포와 유사한 구조를 가지고 있으며, 그 기본 단위는 다음과 같다.

하나의 뉴런, 즉 노드에 여러 개의 설명변수들이 들어오고, 이것이 일정한 수준 이상이 되면 가중치를 받아 출력되게 하는 구조이다.

인간의 뇌에 수많은 뉴런이 있듯이 위와 같은 노드를 여러 개 연결하여 최적의 값을 구하는 것이 신경망의 기본적인 알고리즘이다.

신경망은 입력층(Input Layer), 은닉층(Hidden Layer), 출력층(Output Layer)로 구성되어 있다.

입력 노드는 독립변수 및 출력 노드는 종속변수에 대응되며, 은닉 노드는 임의로 구성한다.

특정 기억을 자주 떠올리면 시냅스가 활성화되어 잘 기억하는 것에서 착안한 것으로, 각 노드를 완전 연결시킨 뒤, 학습 데이터가 어떠한 연결선과 노드를 거치는지를 파악하여 노드의 가중치를 결정한다.

은닉층이 둘 이상인 모델을 딥러닝이라고 한다.

관계형 DB를 프로그램에서 사용할 때 기존의 JDBC 또는 Mapper 방식(MyBatis 등)은 DB 의존성이 높아 생산성이 낮고 유지보수가 힘들며 다양한 DBMS 벤더에 따른 호환성 문제가 발생한다.

영속(persistence)적인 데이터를 위해 데이터베이스가 사용됨. 프로그램의 아키텍처에서 데이터에 영속성을 부여해주는 계층으로 영속성 계층(persistence layer)가 있다.

데이터베이스와의 연결을 위한 persistence layer를 구현하기 위하여 초기에 널리 사용되어온 JDBC 대신에 최근에는 JDBC 프로그래밍의 복잡성 또는 유지보수 어려움 없이 개발의 신속성, 유지보수 용이성, 구동의 안정성이 높은 Persistence Framework가 널리 사용된다.

Persistence Framework는 Mybatis와 같은 SQL Mapper 방식과 Hibernate와 같은 ORM(Object-Relational Mapping) 방식으로 나눌 수 있다.

SQL Mapper 방식은 JDBC의 문제점은 해결하지만 ORM과 비교하여 아래와 같은 문제점을 가지고 있다.

SQL Mapper 방식은 객체 필드를 직접 SQL을 사용하여 매핑해주는 방식으로 SQL을 이용하여 CRUD(Create, Read, Update, Delete) 용 질의를 작성하는데, DB 스키마의 변경 등이 발생할 때 SQL 문을 변경해야 하므로 객체지향 언어인 JAVA로 개발함에도 DB 의존성이 높아져 개발 생산성이 떨어지고 유지보수가 어렵다.

또한, SQL을 직접 사용하기 때문에 Oracle, MySQL, MS SQL Server 등과 같이 다른 DBMS 제품을 사용하는 경우에 제품마다 다른 SQL 문의 차이로 인하여 호환성 문제가 발생한다.

ORM(Object-Relational Mapping) 방식은 DB 데이터를 객체로 변환하여 객체 중심 개발을 가능하게 함으로써 SQL Mapper 방식이 가지는 문제를 해결하며, ORM 방식의 Java 표준인 JPA(Java Persistence API)가 제공된다.

ORM 방식은 SQL 문을 작성하는 대신 DB 컬럼과 객체의 필드를 매핑해 주고, 이 객체를 통해 DB를 액세스한다.

ORM 방식을 사용하게 되면 질의를 직접 생성하는 것이 아니고 생성된 객체를 가지고 메소드를 이용하여 DB를 다루기 때문에 객체 중심의 개발이 되어 생산성과 유지보수성이 높아진다.

ORM 방식을 사용하면 SQL 대신 JPQL과 같은 DB 독립적인 언어를 사용하기 때 DB 의존성이 없어진다.

단, JPQL로 표현할 수 없는 복잡한 질의의 경우에 Native SQL을 사용할 수 있다.

ORM을 위한 JAVA 표준인 JPA 기반의 다양한 개발 도구들이 존재한다.

Java JPA는 여러 ORM 전문가가 참여한 EJB 3.0 스펙 작업에서 기존 EJB ORM이던 Entity Bean을 JPA라고 바꾸고 JavaSE, JavaEE를 위한 영속성(persistence) 관리와 ORM을 위한 표준을 모아 인터페이스로 제공한다.

JPA는 ORM 표준 인터페이스 기술이고, 구현체로서 Hibernate, OpenJPA, EclipseLink, TopLink Essentials 등이 있다.

Spring Framework 기반의 JPA로서 Spring Data JPA가 있음. Spring Framework는 Rod Johnson이 EJB의 여러 문제를 해결하여 엔터프라이즈 어플리케이션 개발을 용이하게 하기 위한 목적으로 만든 오픈소스 애플리케이션 프레임워크이다.

JPA 질의 방식들은 다양한 방법들이 존재하는데 Query method 방식이 메소드 이름 작성만으로 DB를 액세스할 수 있는 프로그램을 개발할 수 있게 함으로써 개발 및 유지보수 측면에서 큰 장점을 가진다.

MDA의 개념, 등장배경, 기본 구조 및 PoC와의 관련성에 대해 다음과 같이 개관을 제시한다.

MDA(Model-driven architecture)는 OMG(Object Management Group, 객체 관리 그룹)가 제안한 독립적인 소프트웨어 자동화 기술이다.

이상적으로는 코드를 자동으로 생성하도록 하기 위한 기술이며 이를 위해 모델을 종속적으로 설계하지 않고, 객관적(플랫폼 독립적으로)으로 설계한 후 플랫폼에 맞춰서 모델에 따른 코드를 생산하려는 접근법이다.

MDA 등장은 CORBA의 복잡성, 기존 미들웨어 한계, 및 개발 패러다임 변화로 인해 등장하게 되었다.

MDA 기본 구조는 다음과 같이 CIM (Computation-independent model), PIM (Platform-independent model), PSM (Platform-specific model), 및 Code의 순서로 구조를 갖고 있다.

본 PoC와의 MDA 관련성에 대해 도 1과 같이 CIM, PIM, 및 PSM 관점으로 설명할 수 있다.

DRR2 사례에서는 자료 구조(data structure) 및 규칙(rule) 표현에 대해 설명하고 있다.

DRR2에서 자료 구조 제작 과정과 규칙 제작과정은 도 2와 같다.

DRR2 사례를 요약하면 다음과 같다.

SHACL은 closed world에서의 지식 표현에, OWL은 open world에서의 지식 표현에 강점을 가진다.

SHACL은 결론←조건 (...하려면 응당 ...해야 한다) 형태의 표현을, OWL에서는 조건→결론 (...하면 ...가 된다) 형태의 표현을 채택하고 있다.

그러나 SHACL이나 OWL이나 설명논리(descriptive logic)에 집중하는 표현법을 사용하므로 절차적 지식(procedural knowledge)으로 표현해야 하는 비즈니스 룰 표현에는 한계가 있다.

따라서 본 PoC에서는 별도의 규칙 표현 방법을 개발하였다.

본 PoC에서의 MDA 설계 프로세스는 도 3과 같다.

본 PoC에서는 문형추출 meta rule 기반의 MRR 요소 추출기와 LSTM기반의 규제문장 판정기로 MDA과정을 지원한다.

즉, 반자동 생성기를 통해서 자연어 문장을 PIM으로 옮기는 시간과 노력을 단축하고, 일관성 점검을 할 수 있다.

본 PoC에서 MDA의 자체 개발 CIM은 도 4와 같다.

자체 개발 PIM로 자연어 규제문장 및 RULE을 컴포넌트로 개발한다.

본 PoC에서 자연어 규제문장의 PIM으로의 변환 예는 도 5와 같다.

각 RULE의 표현이 PSM에서는 컴포넌트로 개발될 것이다.

자체 개발 PSM으로 매핑 테이블 작성과 ORM을 수행한다.

본 PoC에서 매핑 테이블 작성과 ORM 프로세스는 다음과 같다.

매핑 테이블(Mapping table) 작성기를 통해 머신 리더블 레귤레이션 정보와 금융DB 정보를 연계한다.

금융DB는 금융사의 특정 data dictionary(즉 PSM)로 정의되었고 SQL로 코딩되었을 것이다.

PoC에서는 표준 금융 DB를 사용하였고, 이것이 사전에 정의 가능하다고 보았기 때문에 매핑 테이블과 ORM으로 해결하였으나, 추후에는 PIM을 배포하면 각 금융사(또는 에이전트 회사)가 이에 맞게 PSM을 제작하도록 해야 할 것이다.

분산원장(DLT; Distributed Ledger Technology) 모델 개념

DLT(Distributed Ledger Technology)는 중앙관리 시스템 없이 서로 통신할 수 있는 network 환경에서 모든 참여기관들이 동일한 원장의 데이터를 공유하는 기반 기술이다.

데이터 송수신 및 관리 시스템 구축에 필요한 비용과 시간을 절약 가능하고, 실시간으로 갱신되는 정보 확인가능하다.

PKI(Public Key Infrastructure)기반의 데이터 암호화로 데이터 신뢰성 확보 가능하다.

분산원장 도입 시

(현재 도입 기준) DLT가 어떤 효과를 거둘 수 있는지를 파악하기 위하여 도입 의사결정기준 필요하다.

(미래 도입 기준) DLT 거래 속도 문제 해결을 위한 샤딩(Sharding), 라이덴(Raiden), 작업증명방식 개선(PoS) 등으로 극한 속도를 요구하는 경우를 제외한 광범위한 기술로 발전 예상한다.

(DLT 유형) DLT의 거버넌스(플랫폼 유지보수)에 따라 퍼블릭, 프라이빗, 컨소시엄 DLT 유형에 선택해야 한다.

(DLT 플랫폼) DLT는 아직 표준화가 되지 않은 미성숙 기술로 다양한 플랫폼이 경쟁하고 있어 적합한 SW 선택이 필요하다.

(보안) DLT 자체는 보안성이 높은 기술이지만, DLT 시스템 구현을 위해서는 다양한 보안 요소를 고려해야 한다.

(규제) 논쟁중인 규제 이슈

개인정보 침해 우려(개인정보ㆍ민감정보 공유)

거래기록 파기의무(거래정보 삭제 불가)

사고 발생 시 법적 책임주체 모호

중앙 집중화된 전산환경을 기반으로 한 전자금융거래법과 상충

(비용) 기존시스템의 DLT로 전환비용과 비용절감 효과를 비교 필요하다.

오픈소스로 도입 비용은 낮으나, 운용 단계에서 비용 증가한다.

* 오픈소스 유지보수 비용, 개발자 부족, 레거시 연계 비용, DLT 자체 보안성과는 별개로 시스템 보안 비용 발생

** 저장용량 비교 : 비트코인 블록용량(145GB) vs 유가증권 DB용량(2392GB)

DLT의 비용 측면은 시스템 비용 절감보다는 DLT 생태계에서 발생하는 새로운 가치를 통해 사용자의 비용 부담을 최소화하는 것이다.

클라우드 서비스는 인터넷을 통해 다양한 컴퓨팅 서비스를 제공한다.

On Premise 대비, 관리의 일정 부분을 Cloud 서비스 공급자가 수행하거나 관리 툴을 제공하여 관리 Point 감소한다.

필요에 따라 빅데이터, 금융보안 요건 등 특정 조건을 만족할 수 있는 특화 서비스를 제공받아 업무 구현에 집중할 수 있다.

소규모 자본과 인력의 스타트업의 경우, Cloud 기반의 devops 구축이 일반화되어 있다.

클라우드를 활용한 DLT 인프라 구성은 여러 참여 노드를 빠르게 구축하는 방법으로 대두된다.

코스콤 금융 클라우드는 금융 서비스 전용 클라우드로서 최고 수준의 보안 및 안전성을 보장한다.

코스콤 금융 클라우드에서 PoC 시스템을 구축하여 PoC 환경 구축 기간을 단축시키고, 향후 상용 서비스에 필요한 확장성을 검증할 수 있다.

코스콤 금융 클라우드에서 제공하는 관리 서비스 및 관리 도구를 이용하면 On-Premise 대비 관리 비용을 절감할 수 있다.

API Gateway 처럼 특화된 서비스를 이용하여 불필요한 관리를 줄이고 업무에 집중할 수 있다.

API(Application Programming Interface)는 어떠한 응용 프로그램에서 데이터를 주고 받기 위한 방법을 의미하며 공개 API와 비공개 API로 나뉘고 정보를 요청하고 받는 방식에 대한 규격을 의미하며 이 중에서 오픈 API는 플랫폼의 기능 또는 컨텐츠를 외부에서 쓸 수 있도록 웹 프로토콜(HTTP)로 호출할 수 있게 개방(open)한 API를 의미한다.

네이버맵, 카카오맵, 구글맵 같은 지도 분야뿐 아니라 SNS, 음악, 비즈니스, 날씨, 쇼핑 등에서 이용 중이며 금융결제원의 통합계좌조회 API, 코스콤의 open api platform과 같이 공공 분야에서도 활용된다.

본 발명의 오픈 API는 금융 클라우드의 API Gateway를 적용하여 유연한 RESTful API 유지 관리, 백엔드 서비스 트랙픽 제어, 안전한 API 사용자 인증, API 사용량 모니터링 대시보드 제공할 수 있다.

본 발명에서의 MRR 구성

도 6은 본 발명의 실시예에 따른 머신 리더블 레귤레이션 생성 시스템의 구성을 나타낸 블록도이다.

도 6을 참고하면 본 발명인 머신 리더블 레귤레이션 생성 시스템은, 변환모듈(110), 추출모듈(120), 판단모듈(130) 및 결합모듈(140)을 포함한다.

변환모듈(110)은, 자연어로 표현된 법령 또는 규정이 입력되면 형태소 분석을 통해 문장을 정형 데이터와 유사한 형태소로 변환한다.

여기서, 상기 형태소 분석은, 하나의 어절에서 연속된 명사가 검출된 경우 하나 이상의 명사를 붙여 하나의 명사로 분석한다.

추출모듈(120)은, 상기 변환모듈(110)을 통해 형태소로 변환된 문장에 대하여 명사와 동사를 메타언어 형태로 치환하고 온톨로지 구성요소를 추출한다.

여기서, 상기 추출모듈(120)은, 메타언어 형태로 치환된 문장의 문형분석을 통해 기 분석된 문형조건과 같은 문형을 갖고 있는 문장만을 별도로 저장하고, 문형조건과 같은 문형을 갖는 문장에 대하여 문형사전에 기록된 위치정보를 이용하여 온톨로지 구성요소를 추출한다.

판단모듈(130)은, 상기 변환모듈(110)을 통해 형태소로 변환된 문장에 대하여 딥러닝 판별을 통해 규제문장 존재여부를 판단한다.

여기서, 상기 딥러닝 판별은, 기 작성된 학습데이터를 딥러닝 알고리즘을 통해 누적 저장하여 판정모델을 만든 후 상기 판정모델과의 비교를 통해 규제문장의 존재여부를 판단한다.

그리고, 상기 규제문장의 존재여부는, 딥러닝 알고리즘을 통해 문자를 식별가능한 숫자로 변경 후 데이터 패딩(Data Padding)과정을 통해 각 문장의 크기를 동일하게 만들어 판정모델을 생성하고 메타언어로 치환된 문장과 비교하여 규제문장의 존재여부를 판단한다.

결합모듈(140)은, 및 상기 추출모듈(120)을 통해 추출된 온톨로지 구성요소 추출 결과와 상기 판단모듈(130)을 통해 규제문장 존재여부 판단 결과를 결합한다.

도 7은 본 발명의 실시예에 따른 머신 리더블 레귤레이션 생성 방법의 생성 순서를 나타낸 순서도이다.

도 7을 참고하면, 우선 자연어로 표현된 법령 또는 규정이 입력되면 형태소 분석을 통해 문장을 정형 데이터와 유사한 형태소로 변환한다(s110).

여기서, 상기 형태소 분석은, 하나의 어절에서 연속된 명사가 검출된 경우 하나 이상의 명사를 붙여 하나의 명사로 분석한다.

그 다음, 상기 (s110)단계에서 형태소로 변환된 문장에 대하여 명사와 동사를 메타언어 형태로 치환하고 온톨로지 구성요소를 추출한다(s120).

여기서, 상기 (s120)단계는, 메타언어 형태로 치환된 문장의 문형분석을 통해 기 분석된 문형조건과 같은 문형을 갖고 있는 문장만을 별도로 저장하고, 문형조건과 같은 문형을 갖는 문장에 대하여 문형사전에 기록된 위치정보를 이용하여 온톨로지 구성요소를 추출한다.

그 다음, 상기 (s110)단계에서 형태소로 변환된 문장에 대하여 딥러닝 판별을 통해 규제문장 존재여부를 판단한다(s130).

여기서, 상기 딥러닝 판별은, 기 작성된 학습데이터를 딥러닝 알고리즘을 통해 누적 저장하여 판정모델을 만든 후 상기 판정모델과의 비교를 통해 규제문장의 존재여부를 판단한다.

또한, 상기 규제문장의 존재여부는, 딥러닝 알고리즘을 통해 문자를 식별가능한 숫자로 변경 후 데이터 패딩(Data Padding)과정을 통해 각 문장의 크기를 동일하게 만들어 판정모델을 생성하고 메타언어로 치환된 문장과 비교하여 규제문장의 존재여부를 판단한다.

마지막으로, 상기 (s120)단계에서 추출된 온톨로지 구성요소 추출 결과와 상기 (s130)단계에서 규제문장 존재여부 판단 결과를 결합한다.

MRR 전체설계에 대한 흐름은 크게 PoC에 해당하는 MRR을 작성하고 이를 토대로 규제 기반 분석을 실시하는 것이다.

첫 번째 미션으로서, 자연어로 표현된 법령을 기계(컴퓨터)가 읽을 수 있도록 MRR 코드화 하고, 이후의 절차는 다음과 같음. 본 발명에서 MRR은 DRR 프로젝트와 동일하게 OWL형태의 온톨로지 유형을 고려한다.

첫째, 규제문장을 분석하기 위해 자연어처리(형태소 분석, 문형 분석, 규제문장 선정)을 통한 규제문장을 추출한다.

둘째, MRR 요소인 Class (Domain, Range), Object Property, Data Propoerty, Individual들을 추출한다.

셋째, 금융 법령 전문가들이 추출된 MRR 요소를 참고하여 OWL 온톨로지 형태의 MRR을 작성 후 게재한다.

두 번째의 미션인 규제기반분석(MER)을 위해 법령의 내용을 시각화하고, ORM을 이용해 보고서 생성을 위한 금융DB 검색 프로그램을 생성한다.

첫째, 앞서 구축한 MRR을 바탕으로 법령을 시각화한다(VOWL 활용).

둘째, Mapping Table 작성기를 통해 MRR의 보고서 생성 유관 정보와 금융 DB를 매핑하고 그 결과를 파일로 생성한다.

셋째, 정합성검증에 대한 API를 개발하여 보고서 DB의 내용에 대해 정합성 검토를 하여 그 결과를 표출한다.

넷째, 일부 시나리오에 대해 법령의 변경(추가, 삭제, 수정) 발생에 따른 변경 분석을 수행한다.

MRR PoC 의 코스콤 금융 Cloud 구성안

MRR PoC에서는 총 11대의 VM으로 구성하여, 실제 물리적으로 분리된 참여기관의 상태를 반영한다.

참여기관 6, DB 1, 관리 1, 웹 1, WAS 1, GPU 1

고사양의 CPU 처리를 요하는 딥러닝, visual OWL을 위한 별도의 서버(GPU) 구성

외부에서 접속할 수 있는 공인 IP는 웹 서버로 한정하여 보안 및 관리에 초점

VM 사이에서의 내부 통신이 가능토록 하여 불필요한 외부 통신 감소

머신 리더블 레귤레이션 PoC의 분산원장(DLT; Distributed Ledger Technology) 적용방안

인프라는 코스콤 금융 클라우드를 사용하여 관리 및 시간의 효율성 향상

DLT는 Hyperledger fabric을 사용하여 원장, 트랜잭션, 스마트 컨트랙트 등의 통합 관리

코스콤 Fabric API Server를 통해 비즈니스 업무가 DLT로의 처리를 허용

보고지시, 보고서 생성 스마트 컨트랙트를 이용하여 금감원과 금융기관의 업무보고 처리

Hyperledger Fabric

고도의 기밀성, 탄력성, 유연성 및 확장성을 제공하는 DLT 솔루션

MSP를 이용한 회원/신원관리, 채널을 통한 프라이버시, 저장소 지원, 체인코드 지원 등의 특징이 있다.

엔터프라이즈 환경에서 투명한 정보 공유 및 거래비용 절감 가능하다.

Hyperledger Fabric은 private DLT로, 퍼블릭과 비교하여 도 8과 같은 특징 및 기능 지원

스마트 컨트랙트를 통해 응용프로그램이 DLT 원장(KVS)으로의 처리가 가능하여 참여기관 사이에서의 데이터의 전송 및 공유, 증적 데이터 생성 등의 업무를 처리할 수 있다.

Fabric Server

코스콤이 보유한 DLT 관리 및 체인코드 관리 Restful API Server

응용 프로그램이 DLT 관리 및 DLT에 설치된 스마트 컨트랙트 처리 등을 하기위해 Fabric Server의 호출 필요하다.

MRR PoC 의 DLT 설계

Node 구성

총 7대의 Node로 구성(금감원 1, 금융사 5, 관리 1)

각각의 node는 하나의 Peer*와 Fabric Server가 존재

peer : 블록체인 네트워크 내의 노드를 나타내는 논리적 단위로서 DLT, 상태 DB, 체인코드를 보유함, 트랜잭션 보증 역할을 하는 Endorser와 블록체인과 상태 DB를 갱신하는 Committer로 구분한다.

채널 구성

하나의 보고지시 채널(6개 Node Join), 5개의 보고서관리 채널(금감원과 각각의 금융기관Node) 로 구성한다.

보고지시 채널은 금감원 및 전 금융기관이 데이터를 공유가능하나, 보고서관리 채널은 해당 채널에 속한 2개의 기관만이 데이터를 공유하기 때문에 기밀성 유지한다.

채널 : 논리적으로 분리한 블록체인 네트워크. 한 개의 네트워크 안에 독립된 여러 채널이 가능. 각 채널은 동일한 블록체인 원장을 보유하여 기밀성을 유지할 수 있다.

데이터 구조

DLT 내 수행되는 스마트 컨트랙트는 보고지시 및 보고서 관리로 구분한다.

보고지시는 금감원이 금융기관에게 보고서를 생성하도록 지시할 수 있는 항목으로 구성한다.

보고서관리는 금융기관이 금감원에게 전송할 보고서의 일부 항목 및 hash 값으로 구성한다.

Node 내 업무 흐름

상기 데이터 구조를 토대로, 금감원은 보고지시 스마트 컨트랙트 이용, 금융기관은 보고서 생성 스마트 컨트랙트를 이용하여 데이터를 저장 및 조회 처리하여 업무 수행한다.

MRR로서의 온톨로지를 구축하기에 앞서, 벤치마킹대상 온톨로지 모델을 검토하였다.

FIBO의 등장으로 금융규제 관련 여러 온톨로지 모델들이 개발되고 있는바, 대표적으로 FRO(Financial Regulation Ontology)와 FIRO(Financial Industry Regulation Ontology)가 존재한다.

FRO: FIBO 및 LKIF(Legal Knowledge Interchange Format)를 기반 오픈 소스 온톨로지

FIRO: 규제에　대한　지식을　표준에　기반하여　작성된 규제 온톨로지 (by GRCTC)

상기 두 온톨로지가 FIBO를 기반으로 한다는 점과 규제 기간 서비스를 제공한다는 공통점이 있다.

검토결과, 다음과 같은 온톨로지가 일부 본 PoC와 관련 있는 것으로 파악된다.

PoC 대상 법령을 분석함

PoC 대상은 4개의 법령과 4개의 보고서로 구성되며, 대상 법령은 <그림 #>과 같은 계층구조를 가지고 있다.

일반적으로 헌법, 법령(법률 → 시행령 → 시행규칙), 행정규칙(훈령, 예규, 고시), 자치법규(조례, 규칙) 등의 순으로 권한 위임이 이루어진다.

금융관련 법률 역시 이와 유사한 구조를 가져 헌법, 법령, 규칙 등의 순으로 권한 위임이 이루어지는 계층구조를 가진다.

PoC 대상 법령은 전자금융거래법 42조, 전자금융거래법 시행령 24조, 전자금융감독규정 63조, 전자금융감독규정시행세칙 10조 및 11조가 해당된다.

전자금융거래법령의 경우 인용(citation) 법령이 존재하는 바 하는 경우로 인해 하위 법령을 추가하여 분석을 수행한다.

또한, PoC 대상 보고서로는 대차대조표, 경영지도기준 보고서, 직불전자지급수단 발행 및 이용현황, 선불전자지급수단 발행 및 이용현황을 분석한다.

PoC 맞춤형 형태소분석기 개발 설계

본 발명에서 자체 개발한 형태소 분서기를 이용하여 개발하였다.

본 발명에서는 형태소 분석을 위하여 자체 개발한 RHINO 형태소 분석기를 사용하였다.

RHINO는 Real Hangul INput Object의 약자로 경희대학교 발명팀에서 개발한 형태소 분석기이다.

설계상 한글의 분석에 최적화되어 있는 구조를 가지고 있으며, 특히 맥락에 따른 분석 기능이 탁월하다.

예를 들어, ‘나는 하늘을 나는 새를 봅니다’의 두 ‘나는’은 형태적으로는 동일하지만 하나는 ‘날+는’, 다른 하나는 ‘나+는’으로 분석되며, 품사도 ‘동사+관형사형전성어미’, ‘대명사+조사’로 상이하다.

RHINO는 이러한 경우 문장의 앞뒤 관계를 살펴 이러한 동음이의 어절을 잘 분석한다.

정확도와 속도가 높음. 일반적인 상황에서 정확도는 95~98%를 유지하며, 속도는 초당 100,000~400,000 어절을 분석한다.

RHINO는 공개 버전과 비공개 버전이 있으며, 공개버전은 GitHub에서 다운로드 또는 파이썬 pip 명령어로 받을 수 있다.

본 발명에 적절히 운영되도록 형태소 분석기의 사전을 구성하였다.

자연어 처리의 기초가 되는 형태소 분석기를 본 발명팀에서 직접 제작하였으므로 프로젝트의 목적에 맞게 어휘의 추가 및 기능의 추가를 할 수 있고, 다른 과정과의 연계를 완벽히 이룰 수 있다.

본 발명에서는 어휘 추가의 예로 ‘선불전자지급수단’, ‘여신전문금융회사’, ‘금융규제민원포털’ 등이 있다.

전문용어는 도메인마다 매우 방대하나 해당 도메인이 아니면 사용되지 않아 기본 사전에는 등록되어 있지 않고 별도로 추가해주어야 한다.

어휘를 추가하는 방법은 쉬운 경우도 있지만 형태소분석기의 구조에 따라 어려운 경우도 있음. RHINO 역시 총 6개의 사전이 있으며, 어휘의 성격에 따라 적절히 전문용어를 입력하였다.

기능 추가의 예로는 연속된 명사를 하나의 명사로 Re-Tagging하는 기능을 들 수 있는데, ‘금융행정지도’의 경우에는 전문용어도 아니므로 하나의 어휘로 등록되기 어려운 어휘이다.

금융 도메인인 본 발명의 온톨로지 분석에서는 성격상 한 어절에서 연속된 명사는 하나의 구성요소로 삼는 것이 바람직한 경우가 많다.

따라서 일반 형태소 분석 과정으로 ‘금융행정지도’가 ‘금융+행정+지도’로 분석되었다고 하더라도 이들을 다시 붙여 하나의 단위로 간주할 필요가 있다.

이에 하나의 어절에서 연속된 명사들은 다시 붙여 하나의 명사로 분석하게 하는 기능을 추가하였다.

본 발명에 적절히 대응되도록 형태소 분석기의 기능을 추가하였다.

기능 연계는 해당 프로그램에 대한 이해를 얼마나 잘 하고 있는지와 관계된다.

RHINO를 이용하여 형태소 분석하는 방법은 가장 기본적인 모든 형태소를 보이는 것으로부터 특정형태소만 가져오기, 특정형태소만 가져오면서 동사류에 어말어미를 부착하기, 전체형태소를 가져오면서 품사정보도 가져오기, 원문의 어절 정보도 같이 가져오기 등 다섯 가지가 있다.

이러한 사용상의 자세한 부분을 잘 조절하여 이후의 문형분석과 머신러닝 단계에서 가장 좋은 결과를 낼 수 있도록 하였다.

(딥러닝 기반의) 규제 문장 인식기 설계

온톨로지 구성요소를 추출하고, 딥러닝으로 구성요소의 적격성을 판정하였다.

본 발명에서 자연어 처리를 수행하는 근본적인 목적은 각 문장에서 온톨로지 구성요소를 추출하고, 추출된 구성요소가 본 도메인의 내용에 해당하는지를 판별하기 위한 것이다.

이를 통하여 금융 규제 문장에서 최대한 자동화되게 온톨로지 구성 요소를 추출하고자 하는 것이다.

형태소 분석 및 딥러닝 단계의 전체 분석 과정은 도 9와 같다.

규제문장의 입력, 형태소 분석 및 메타언어로 치환, 딥러닝으로 판별, 및 두 결과의 결합 순으로 전체 프로세스가 진행된다.

도 9에 기재된 ① 단계에서는 앞에서 언급한 바와 같이 금융 도메인의 법령 또는 규정이 입력되면 형태소 분석을 통해 문장을 정형 데이터와 유사한 형태소로 변환하는 과정이다.

문장 전체가 하나의 분석 단위가 될 수 없으므로 반복되어 사용되는 작은 단위인 형태소 단위로 문장을 분리하는 것이 형태소 분석이다.

이 과정을 통해 이후의 기계적으로 진행되는 과정이 정형 데이터를 처리하는 과정과 유사하게 원만히 진행될 수 있다.

② 단계에서는 형태소로 변환된 문장에 대하여 명사와 동사를 실제 형태는 없애고, NOUN과 VERB라는 추상화된 메타언어 형태로 치환한다.

문형 분석 단계에서는 구체적으로 사용된 어휘가 무엇인지가 중요한 것이 아니라, 단순히 명사와 동사가 사용되었는지 여부가 중요하다.

따라서 명사에 해당하는 어휘는 NOUN을, 동사에 해당하는 어휘는 VERB로 대체하는 것이다.

치환된 문장, 즉 메타언어에 대하여 Meta Rule 기반 문형분석을 수행하여 기 분석된 문형 조건과 같은 문형을 가지고 있는 문장만 별도로 저장한다.

문형 조건을 통과한 문장에 대하여 문형사전에 기록된 위치정보를 이용하여 온톨로지 구성요소를 추출한다.

③ 단계에서는 형태소로 변환된 문장에 대하여 딥러닝 판별을 수행함. 판별의 목적은 각 문장이 규제 문장을 가지고 있는지를 예측하는 것이다.

이 과정은 ① 단계의 RHINO 형태소 분석 과정이 마쳐진 후에 ② 단계의 Meta Rule 변환과는 별개로 진행된다.

기 작성된 학습 데이터 SET를 딥러닝 알고리즘으로 훈련하여 판정 모델을 만들고, 이를 이용하여 새로운 문장이 들어왔을 때 해당 문장이 온톨로지 분석 대상인지 여부를 가려내고자 하는 것이 목적이다.

결과로 해당 문장이 규제 문장이 포함하고 있으면 1, 그렇지 않으면 0으로 분류되어 이후 작업자가 해당 문장을 분석 대상으로 여기고 유념해 볼 것인지를 빠르게 판단할 수 있다.

④ 단계에서는 ② 단계의 Meta Rule 변환을 통한 온톨로지 구성요소 추출 결과와 ③ 단계의 딥러닝을 이용한 규제 문장 존재 판정 여부를 결합한다.

② 단계를 거쳐 온톨로지 구성요소가 추출되었다고 하더라도 실제로는 규제 문장이 아닌데 추출 과정을 진행한 것일 수 있다.

이 단계에서는 딥러닝 판정 결과를 토대로 문형 분석 과정에서 규제 문장의 문형으로 간주된 것이라도 다시 한 번 검토하여 규제 문장이 없는 것으로 판정될 경우 문형 분석 결과가 이후의 단계로 진행되지 않게 한다.

위의 내용을 전자금융감독규정이 들어온 경우로 예를 들어보면 도 10과 같다.

규제 문장이 들어올 경우 RHINO 형태소분석기는 이를 최소 의미 단위인 형태소로 분리한다.

분리된 형태소는 문형분석기를 이용하여 규제 문장인지를 확인하고, 확인이 되면 문형의 위치 정보를 이용하여 각 온톨로지 구성요소 class, property, range, domain 등을 분리한다.

한편 머신러닝 쪽에서는 규제 문장으로 학습데이터 SET를 구축하고, 딥러닝 알고리즘으로 이를 학습하여 각 문장에 규제 문장이 존재하는지를 판정하는 모델을 만든다.

사용하는 딥러닝 알고리즘은 텍스트 문장 판정에 좋은 성능을 보이는 순환신경망 계열 알고리즘인 RNN과 LSTM을 고려할 수 있다.

규제 문장의 온톨로지 요소 추출기 설계

형태소 분석 과정은 분석 대상 입력, 분석 대상 법령의 형태소 분석, Class와 Property의 인식으로 나뉜다.

상기 과정은 형태소 분석 과정과 딥러닝을 이용한 분석 과정으로 나뉘며, 형태소 분석 과정 프로세스만 살펴보면 도 11과 같다.

형태소 분석 과정은 다음의 과정을 거친다.

분석 대상 입력 → 분석 대상 법령의 형태소 분석 → Class, Property 인식

우선, 금융 도메인의 규제 문장을 입력한다.

본 발명에서 사용되는 입력 문장은 전자금융과 관련된 금융 도메인의 문장이다.

전자금융과 관련된 규제 내용을 기계가 파악하여 관련 기관에 전달하여 현재의 재무 상태와 관련 규제 내용을 비교해서 처리가 되어야 하는 부분들이 고려되어야 하므로 전자금융거래법과 같은 내용이 입력문의 주된 내용이다.

그 다음, 입력된 규제 문장에 대하여 형태소 분석을 수행한다.

입력된 분석 대상 규제 문장은 다음과 같은 형태소 분석을 수행 받게 된다.

입력 텍스트는 먼저 띄어쓰기 단위인 어절 단위로 분리되고, 어절 단위의 내용 각각에 대하여 형태소 분석이 이루어진다.

형태소는 항상 어절 단위와 같거나 그보다 작으므로 먼저 어절 단위로 분리해 형태소 분석이 용이하게 만든다.

다음으로 언어 단위에서 가장 작은 단위인 형태소 단위로 나누어 반복적인 언어 단위가 가능한 많이 발견되게 한다.

반복적인 단위가 많이 발견될수록 두 문장이 실질적으로 같은 내용의 문장인지 여부가 쉽게 파악된다.

이에 위의 첫 번째 문장에서 첫 번째 어절 ‘제63조’는 ‘제+63+조’로 분리되고, 각 형태소의 품사도 태깅이 됨. ‘제’는 접두사(XPN), ‘63’은 숫자(SN), ‘조’는 의존명사(NNB)이다.

최소 의미 단위로 분리된 형태소는 반복된 단위로서 이후 정형데이터로 바뀔 수 있으며, 태깅된 품사는 메타언어로 변환할 때와 문형 분석 시 대상 요소 여부를 알게 해주는 정보를 제공한다.

마지막으로, 입력 문장에서 온톨로지의 Class와 Property를 인식한다.

형태소 분리된 각 문장은 전처리 과정을 통해 메타언어로 변환되어 문형분석을 받을 수 있게 한다.

메타언어라 함은 문형을 구성하는 주요 어휘인 명사와 동사에 대하여 구체적인 사용 어휘를 밝히지 않고 명사와 동사 각각이 쓰였는지 만을 알 수 있게 기록한 것을 말한다.

이렇게 함으로써 소수의 문장 유형만으로 다양하게 표현된 문장을 비교 검색할 수 있다.

문형 분석을 수행하는 궁극적인 목적은 문형 사전에 기록된 주요 어휘의 위치 정보를 이용하여 주요 어휘를 추출하고자 하는 데 있다.

여기서 주요 어휘라 함은 온톨로지를 구성하는 요소로서, Class와 Property 요소를 말한다.

문형 분석이 이루어질 수 있도록 해당 도메인의 전문가가 문형 사전을 미리 구축 해두어야 한다.

문형정보 사전은 각 문형조건을 제시하고, 각 조건에서 Class Domain, Class Range, Object Property, Data Property가 어느 위치에 있는지를 명시한 사전이다.

여기서 위치라 함은 해당 문형 조건의 명사 혹은 동사 중 몇 번째가 해당 온톨로지 구성 요소인지를 밝힌 것을 말한다.

예를 들어, Class Domain이 NOUN1이라 하면 해당 문형에서 두 번째로 나타나는 명사가 Class Domain인 것을 말하고, 위치의 숫자는 0부터 시작한다.

도 12는 형태소 분석결과를 나타낸 예시도이다.

도 12를 참고하면, 첫 번째 문형조건의 의미는 다음과 같다.

문형 조건은 ‘ANY NOUN1 이(가/은/는), ANY NOUN2를(을) VERB1’으로서 ANY 조건으로 시작하고 있음. ANY 조건은 어떠한 표현이 와도 뒤에 기록된 내용이 오기까지는 PASS해야 한다는 것을 말한다.

따라서 이 문형 조건은 앞에 어떤 단어든 올 수 있으며, 명사로 시작하여(NOUN1) 조건문이 시작됨을 말하고 있다.

그 다음으로는 조사가 오는데 조사로는 -이, -가, -은, -는 중 어느 것이 와도 동일하게 처리한다.

그 다음에 또 다시 ANY 규칙이 있어 어떠한 어휘가 와도 넘기며(PASS), 다시 두 번째 명사(NOUN2)가 와야 한다.

그리고 목적격 조사 ‘-를’ 또는 ‘-을’이 오고, 마지막으로 동사 ‘하다’가 와야 함을 말하고 있다.

그 우측에서는 온톨로지 구성요소가 문형 조건의 어떤 위치에 속하는지를 명세하고 있다.

Class Domain은 첫 번째 명사 NOUN1 자리에 있는 것이다.

Class Range는 두 번째 명사 NOUN2 자리에 있는 것이다.

Object Property는 VERB1 자리에 있는 것임을 말하고 있다.

Data Property에 해당하는 것은 존재하지 않는다.

구체적인 문장으로 예를 들면 다음과 같다.

‘제1조(목적) 이 규정은 「전자금융거래법」(이하 "법"이라 한다) 및 동법 시행령(이하 "시행령"이라 한다)에서…’라는 문장이 입력되었다고 할 때 우선 조건문 탐색에 도움이 되지 않는 요소는 삭제한다.

삭제 대상 요소는 접두사, 숫자, 관형사, 부사 등 이다.

그 결과 문장은 ‘(목적) 규정은 「전자금융거래법」(이하 "법”이라 한다) 동법 시행령(이하 "시행령”이라 한다)에서…’로 변환한다.

전처리 두 번째 단계는 형태소 분석 과정이다.,

형태소 분석 단계는 각 어절을 최소 의미 단위로 분리하는 것이다.

동시에 한 어절 내에서 연속된 명사는 분리하지 않고 Re-Tagging하여 하나의 명사로 변환한다.

전처리 세 번째 단계는 괄호 안의 내용을 제거하는 것이다.

괄호 안의 내용은 본문의 내용을 보충하는 것으로서 문장의 맥락에 직접 연결되지 않는다.

따라서 이들을 삭제하여 조건문 탐색에 지장이 없도록 한다.

괄호 내용 삭제는 한 문장 안에 여러 번 나타날 수 있으므로 반복적으로 수행한다.

다음으로 입력문을 메타언어로 변환함. 명사는 NOUN으로, 동사는 VERB로 변환하여 나타난 순서에 따라 인덱스를 부여한다.

메타언어로 변환된 문장에 대하여 문형조건 사전을 탐색하여 문형 조건에 해당하는지, 해당한다면 어떠한 문형 조건에 해당하는지를 검색한다.

현재의 입력문은 메타언어 변형 결과 ‘NOUN0 은 NOUN1 NOUN2 이 NOUN3 에 VERB0 NOUN4를 NOUN5’가 되었다.

이 메타언어에 맞는 문형을 탐색하면 ‘NOUN1 이/가/은/는 ANY NOUN2 을/를 NOUN3’가 발견된다.

입력문의 메타언어에서 조건문의 ANY에 해당하는 부분이 있음. 이는 온톨로지 구성 요소 찾기에는 도움이 되지 않으므로 이 부분은 삭제해야 한다.

예를 들어, ‘제1조 이 규정은 「전자금융거래법」 및 동법 시행령에서 금융위원회에 위임한 사항과 그 시행에 필요한 사항 및 다른 법령에 따라’와 같은 문장이 입력되었을 때, ‘「전자금융거래법」’부터 ‘다른’까지는 ANY에 해당하는 부분이므로 삭제하는 것이다.

최종 남겨진 문장에서 Class와 Property를 추출한다.

현재 남겨진 문장은 규칙에 해당하는 부분만 남겨진 것이므로, 최초 문형 조건에서 Class, Property가 있는 것으로 지정된 부분을 찾아 해당 어휘를 가져오는 작업이다.

아래의 예는 최종 남은 문장이 ‘이 규정은 법령에 따라’이고 해당 문형은 ‘ANY NOUN1 이/가/은/는 ANY NOUN1 에/에게 VERB0’이다.

Class Domain에 속하는 것은 NOUN1, Class Range에 속하는 것은 NOUN0, Object Property에 속하는 것은 VERB0이므로, 이에 해당하는 어휘 ‘규정’, ‘법령’, ‘따르다’를 각각 추출한다.

규제 문장 판정을 위하여 딥러닝 분석을 실시한다.

형태소 분석 과정과는 별개로 딥러닝 분석 과정이 수행되며, 그 진행 과정은 아래와 같이 분석 대상 문장으로 학습데이터 SET를 구축하여 딥러닝 알고리즘으로 규제 문장 여부를 판별하는 모델을 생성하는 과정이다.

도 13은 규제문장과 관련한 딥러닝 분석을 나타낸 예시도이다.

금융 도메인의 규제문장으로 학습데이터 SET를 구축하였다.

본 발명에서 사용되는 금융 도메인의 규제문장으로 다음의 법령문을 학습데이터 SET로 삼았다.

금융규제 운영규정

전자금융감독규정

전자금융감독규정 시행세칙

전자금융거래법 시행령

전자금융거래법

위의 학습데이터 SET은 전체 6,429건 중 75%인 4,821 문장이고, 나머지는 25%의 문장은 훈련된 모델의 정확도를 확인하는 데 사용되었다.

형태소 분석된 데이터로 학습데이터 SET를 아래와 같이 구축하였다.

학습데이터 각 문장은 id, 본문, is_rule 3개의 칼럼으로 구성되어 있다.

id는 학습데이터 각각에 대한 고유 식별 번호이다.

본문은 학습데이터 원 텍스트의 내용이다.

is_rule은 온톨로지 구성 요소를 갖추고 있어 분석 대상인지를 전문가가 기록한 내용으로 분석 대상이면 1, 그렇지 않으면 0이다.

학습 데이터의 문장에 대하여 형태소 분석을 수행하였다.

학습 데이터를 생성하기 위하여 어떠한 문장이 사용되었는지를 형태소 분석으로 파악한다.

하나의 문장을 변형 없이 학습할 경우, 문장 전체가 하나의 종류가 되기 때문에 패턴 학습이 올바로 이루어지지 않는다.

하나의 문장에 사용된 어휘가 무엇인지를 분석하여 사용된 어휘가 비슷한지를 통하여 패턴 학습이 이루어지도록 해야 한다.

이에 학습 데이터 SET에 대하여 형태소 분석을 수행하였다.

형태소 분석 대상으로는 실질형태소만 취하였다.

문형 분석 및 문형인지에 도움을 주는 형태소만 추출하였다.

실질형태소는 모두 취하며, 형식형태소는 의미가 크고, 사용빈도가 높은 것만 채택하였다.

기호류는 문장구분에 도움 되는 것 외에는 모두 제외하였다.

사용된 실질 형태소는 명사(NNG), 고유명사(NNP), 대명사(NP), 동사(VV), 형용사(VA), 어근(XR), 관형사(MM), 부사(MAG), 접속사(MAJ), 감탄사(IC)이다.

사용된 형식형태소는 부정지정사(VCN), 연결어미(EC), 종결어미(EF), 명사형전성어미(ETN), 관형사형전성어미(ETM), 주격조사(JKS), 보격조사(JKC), 관형격조사(JKG), 부사격조사(JKB), 보조사(JX), 마침표,물음표,느낌표(SF)이다.

형태소 분석 결과 예시는 다음과 같다.

각각의 문장을 어절 단위로 분리함

분리된 어절에 대하여 형태소 분석을 수행함

태깅된 품사의 종류를 보고, 위에서 제시된 품사 태그 종류만 남겨 놓음

딥러닝 분석을 위하여 데이터 전처리를 수행하였다.

딥러닝 알고리즘은 문자열 형태를 직접 받지 못하고 숫자로 변형해야 한다.

예를 들어 문장에 ‘금융, 법령, 조항’이라는 3개의 어휘가 있다면 각각을 ‘101, 2133, 35’와 같이 식별할 수 있는 숫자로 변형해야 한다.

숫자의 배당은 전체 텍스트에서 사용된 빈도를 기준으로 고빈도 어휘가 낮은 숫자를 받도록 한다.

문자열을 숫자로 변형하는 과정을 데이터 토크나이징(Data Tokenizing)이라고 한다.

숫자로 변형된 문자열은 다시 데이터 패딩(Data Padding) 과정을 거친다.

데이터 패딩 과정은 모든 각 문장을 동일한 크기로 만들어주는 것이다.

크기가 작은 문장은 앞에 ‘0’을 붙여 지정된 크기로 동일하게 만든다.

크기가 큰 문장은 앞에서부터 제거하여 동일한 크기로 만들며, 뒤에서부터 제거할 수도 있다.

복수의 딥러닝 알고리즘의 성능을 비교하여 LSTM 알고리즘을 선택하였다.

전처리 된 데이터를 복수의 딥러닝 알고리즘을 적용해 최적 알고리즘을 선정하였다.

사용된 알고리즘은 ANN, RNN, LSTM 3개 알고리즘이다.

ANN 알고리즘 적용 Rule 존재 유무에 대해 성능을 판정한 결과는 도 14와 같다.

10번 반복 수행한 결과 4번째 반복에서 가장 좋은 성능을 보였다.

테스트데이터의 정확도 확인에서 96.6%의 정확도를 보였음

RNN 알고리즘 적용 Rule 존재 유무에 대해 성능을 판정한 결과는 도 15와 같다.

10번 반복 수행한 결과 3번째 반복에서 가장 좋은 성능을 보였다.

테스트데이터의 정확도 확인에서 96.7%의 정확도를 보였다.

LSTM 알고리즘 적용 Rule 존재 유무에 대해 성능을 판정한 결과는 도 16과 같다.

10번 반복 수행한 결과 3번째 반복에서 가장 좋은 성능을 보였다.

테스트데이터의 정확도 확인에서 97.1%의 정확도를 보였다.

위, 3개 딥러닝 알고리즘의 성능을 비교해본 결과 큰 차이 없이 비슷하게 좋은 성능을 보였다.

본 발명에서는 LSTM을 사용하기로 하였는데, LSTM이 법 규정 문장과 같이 긴 문장 분류에 일반적으로 더 성능이 좋으며, 실제 본 발명 데이터를 이용한 비교 실험에 있어서도 근소하게나마 더 좋은 성능을 보였기 때문이다.

최적 LSTM 모델을 생성

선정된 LSTM 알고리즘에 대하여 최적의 옵션, 즉 최적 하이퍼파라미터를 찾아 가장 좋은 성능을 내는 모델을 생성하였다.

탐색한 하이퍼파라미터는 유사 어휘 사용을 위한 Embedding 층을 위한 사용 어휘의 수를 설정하는 Embedding Dimension, 은닉층의 깊이를 설정하는 Hidden Layer, 각 은닉층에서의 노드의 수를 설정하는 Hidden Layer Node로 총 세 가지이다.

Embedding Dimension은 100개, Hidden Layer는 1개, Hidden Layer Node는 16개가 최적으로 판정되었으므로 이에 따라 모델이 생성되었다.

모델 생성에 사용된 딥러닝 플랫폼은 Tensorflow 1.16, Keras 2.2.4 버전이다

Keras는 Tensorflow를 사용하기 쉽게 만들어주는 Wrapper 패키지이다.

Input 층은 학습데이터에서 사용된 2,330개의 단어 종류가 노드로 구성된다.

Embedding 층은 유사한 단어는 같은 숫자를 갖도록 하는 것으로서 학습 데이터에서 사용된 문장이 그대로 실제 데이터에서 사용되지 않아도 비슷한 문장임을 판별하게 한다.

출력층의 노드는 하나로서 Rule이 존재할 것인지를 확률로 계산하여 Y/N 방식으로 판정한다.

형태소 분석 결과와 딥러닝 수행 결과를 결합

형태소 분석 결과와 딥러닝 수행 결과를 결합하여 온톨로지 작업을 수행하는 전문가가 보다 빠르고 편리하게 작업을 할 수 있도록 하였다.

형태소 분석의 처리 결과는 도 17와 같이 산출된다.

온톨로지 요소 추출기를 제작

이상의 과정을 자동화하여 진행할 수 있는 프로그램을 제작하였다.

특히 온톨로지 구성 요소 추출 결과와 딥러닝 판정 결과를 결합해 제시함으로 최종 작성자가 빠르게 작업할 수 있도록 지원한다.

각 문장에서 온톨로지 주요 구성요소인 Class Domain, Class Range, Object Property, Data Property 4개 요소를 추출하고, 딥러닝 모델로 Rule이 있을 것으로 추정되는 문장을 예측하는 프로그램을 제작한다.

온톨로지 작업 시 추출기의 내용을 보고 작업을 보다 수월하게 할 수 있게 하는 것이 목적이다.

도 18은 온톨로지 요소와 규제문장 여부를 보여주는 UI 구축한 형태를 나타낸 예시도이다.

각 구성요소의 기능은 아래와 같다.

① 원 텍스트에 문형 조건 규칙을 적용하여 Class와 Property 요소를 추출하는 과정을 진행하는 버튼

② 딥러닝 분석을 통해 Rule이 존재할 것으로 예측된 문장을 찾는 과정을 진행하는 버튼

③ 저장된 Class와 Property 요소를 화면에 출력하는 버튼

④ 현재의 진행 상태를 보여주는 창

⑤ 원문의 내용을 보여 주는 결과창

⑥ Class Domain에 속하는 어휘를 보여주는 결과창

⑦ Class Range에 속하는 어휘를 보여주는 결과창

⑧ Object Property에 속하는 어휘를 보여주는 결과창

⑨ Data Property에 속하는 어휘를 보여주는 결과창

⑩ 문장에 존재하는 모든 명사를 보여주는 결과창

⑪ Rule 존재 여부를 보여주는 결과창. Rule이 있을 것으로 예상되면 1

도메인 전문가의 OWL 코드 생성 설계

도메일 전문가가 추출된 온톨로지 요소와 기계(machine)가 추정한 규제문장 판정 결과를 바탕으로 온톨로지 코드(owl)를 작성한다.

예를 들면, 온톨로지 요소들인 Clas Property Rule 등을 구분한 후 사람이 개입해 기계코드인 owl을 도출한다.

온톨로지 솔루션(Protιgι)을 이용하여, 온톨로지 언어(OWL code) 생성한다.

이를 바탕으로 시각화, 정합성검사, 보고서 생성, 법령분석이 가능하게 된다.

머신 리더블 레귤레이션 시각화 설계

도 19는 본 발명의 실시예에 따른 온톨로지 기반 머신리더블 레귤레이션 시각화 시스템의 구성을 나타낸 블럭도이다.

도 19를 참고하면, 본 발명인 온톨로지 기반 머신리더블 레귤레이션 시각화 시스템은, 온톨로지DB(210), 표시모듈(220) 및 수정모듈(230)을 포함한다.

온톨로지 DB(210)는, 자연어로 표현된 법령 또는 규정을 형태소분석을 통해 온톨로지 요소들로 구분한 후 온톨로지코드(OWL code; 이하 온톨로지 코드)로 변환하여 저장한다.

표시모듈(220)은, 출력요청정보가 수신되면 상기 출력요청정보에 따라 상기 온톨로지 DB(210)에 저장된 자연어로 표현된 법령 또는 규정을 온톨로지 요소간 관계에 따라 상위 법령 또는 규정으로부터 하위 법령 또는 규정까지 온톨로지 트리구조로 표시한다.

여기서, 상기 출력요청정보는, 클라이언트를 통해 입력된 검색정보를 포함한다.

그리고, 표시모듈(220)은, 상기 검색정보가 수신되면 상기 검색정보를 온톨로지 코드로 변환하고, 변환된 온톨로지 코드를 포함하는 하나 이상의 법령 또는 규정들을 검출하여 출력한다.

또한, 상기 온톨로지 트리구조는, 상위 법령 또는 규정으로부터 하위개념인 조, 항, 호 순서로 연결되어 표시된다.

수정모듈(230)은, 상기 표시모듈(220)에 표시된 상기 온톨로지 DB(210)에 저장된 자연어로 표현된 법령 또는 규정 중 어느 하나가 선택된 후 수정정보가 수신되면 상기 수정정보에 포함된 교체법령정보를 검출하고 검출된 교체법령정보를 형태소분석하여 온톨로지 요소들로 구분한 후 온톨로지코드로 변환하여 저장한다.

도 20은 본 발명의 실시예에 따른 온톨로지 기반 머신리더블 레귤레이션 시각화 방법의 제공 순서를 나타낸 순서도이다.

도 20을 참고하면, 우선, 자연어로 표현된 법령 또는 규정을 형태소분석을 통해 온톨로지 요소들로 구분한 후 온톨로지코드(OWL code; 이하 온톨로지 코드)로 변환하여 온톨로지 DB(210)에 저장한다(s210).

그 다음, 출력요청정보가 수신되면 상기 출력요청정보에 따라 상기 온톨로지 DB(210)에 저장된 자연어로 표현된 법령 또는 규정을 온톨로지 요소간 관계에 따라 상위 법령 또는 규정으로부터 하위 법령 또는 규정까지 온톨로지 트리구조로 표시한다(s220).

여기서, 상기 출력요청정보는, 클라이언트를 통해 입력된 검색정보를 포함한다.

그리고, (s220)단계는, 상기 검색정보가 수신되면 상기 검색정보를 온톨로지 코드로 변환하고, 변환된 온톨로지 코드를 포함하는 하나 이상의 법령 또는 규정들을 검출하여 출력한다.

또한, 상기 온톨로지 트리구조는, 상위 법령 또는 규정으로부터 하위개념인 조, 항, 호 순서로 연결되어 표시된다.

마지막으로, (s220)단계에 표시된 상기 온톨로지 DB(210)에 저장된 자연어로 표현된 법령 또는 규정 중 어느 하나가 선택된 후 수정정보가 수신되면 상기 수정정보에 포함된 교체법령정보를 검출하고 검출된 교체법령정보를 형태소분석하여 온톨로지 요소들로 구분한 후 온톨로지코드로 변환하여 저장한다.

이를 자세히 설명하면 아래와 같다.

구축한 온톨로지를 바탕으로 시각화는 법령 내용을 직관적으로 파악할 수 있고, 법령 분석을 용이하게 하기 위함이다.

도 21는 법령시각화에 대한 플로우(flow)를 보여준다.

먼저, 온톨로지 요소 시각화는 온톨로지 DB를 통해 VOWL로 변환한 후에 온톨로지 트리를 나타내고 있다.

또한 법령 변경에 따른 시각화는 기존 법령 기준의 보고서를 변경된 법령 기준 보고한다.

도 22는 법령 온톨로지의 전체 구조 가운데 일부인 법령에 해당되는 내용을 도식화 하였다.

대 메뉴로는 법령 온톨로지 기능과 법령변경분석과 법령 정합성 기능을 가지고 있다.

예를 들면, 법령은 조, 항, 호를 가지고 있고, 조, 항, 호는 각각의 하위요소를 가지고 있음을 보여준다.

온톨로지의 단어들에 대하여 다른 색을 적용하였으며, 도형부분을 클릭하면, 좌측에 해당 법령의 전문을 보여 줌으로써, 사용자 편의성을 증진하였다.

ORM 설계

온톨로지 정보를 이용하여 보고서를 생성하기 위해서는 온톨로지 내용과 금융DB 내용이 연계되어야 하기 때문에 ORM 기술이 필요하다.

보고서 생성을 자동화하기 위하여 온톨로지 내용과 금융DB 내용의 연계 정보를 보관하는 온톨로지-금융DB 매핑정보를 입력으로 ORM을 사용해 보고서 생성용 JAVA jar 프로그램을 생성한다.

도 23은 본 발명의 실시예에 따른 매핑 테이블을 이용한 온톨로지와 금융DB의 연동 시스템의 구성을 나타낸 블록도이다.

도 23을 참고하면, 본 발명인 매핑 테이블을 이용한 온톨로지와 금융DB의 연동 시스템은, 온톨로지DB(210), 테이블생성모듈(310), 보고서수신모듈(320) 및 보고서갱신모듈(330)을 포함한다.

온톨로지DB(210)는, 자연어로 표현된 법령 또는 규정을 형태소분석을 통해 온톨로지 요소들로 구분한 후 온톨로지코드(OWL code; 이하 온톨로지 코드)로 변환하여 저장한다.

테이블생성모듈(310)은, 클라이언트로부터 테이블 양식 정보가 수신되면 상기 테이블 양식 정보에 포함된 하나 이상의 항목별로 온톨로지코드를 매핑하여 매핑요청테이블을 생성한다.

보고서수신모듈(320)은, 상기 테이블생성모듈(310)을 통해 생성된 매핑요청테이블을 금융사서버로 송신하고, 상기 금융사서버로부터 상기 매핑요청테이블에 해당하는 보고서 데이터를 수신하고 수신된 보고서데이터를 보고서 DB에저장한다.

또한, 상기 금융사서버는, 상기 매핑요청테이블을 수신하면 상기 항목별로 온톨로지코드에 맞춰 금융DB에 저장된 값을 매칭하는 것을 특징으로 한다.

보고서갱신모듈(330)은, 클라이언트를 통해 보고서 DB에 저장된 보고서데이터 중 어느 하나가 선택되면 선택된 보고서데이터에 해당하는 금융DB로부터 수신받아 보고서를 갱신한다.

또한, 상기 보고서 갱신모듈(330)은, 갱신된 보고서데이터의 해시값과 해당 금융사의 블록체인에 기 저장된 해시값을 비교하여 일치하면 최종데이터를 보고서 DB에 저장한다.

도 24는 본 발명의 실시예에 따른 매핑 테이블을 이용한 온톨로지와 금융DB의 연동 방법의 제공 순서를 나타낸 순서도이다.

도 24를 참고하면, 우선, 자연어로 표현된 법령 또는 규정을 형태소분석을 통해 온톨로지 요소들로 구분한 후 온톨로지코드(OWL code; 이하 온톨로지 코드)로 변환하여 온톨로지DB(210)에 저장한다(s310).

그 다음, 클라이언트로부터 테이블 양식 정보가 수신되면 상기 테이블 양식 정보에 포함된 하나 이상의 항목별로 온톨로지코드를 매핑하여 매핑요청테이블을 생성한다(s320).

그 다음, 상기 테이블생성모듈을 통해 생성된 매핑요청테이블을 금융사서버로 송신하고, 상기 금융사서버로부터 상기 매핑요청테이블에 해당하는 보고서 데이터를 수신하고 수신된 보고서데이터를 보고서 DB에 저장한다(s330).

여기서, 상기 금융사서버는, 상기 매핑요청테이블을 수신하면 상기 항목별로 온톨로지코드에 맞춰 금융DB에 저장된 값을 매칭한다.

그 다음, 클라이언트를 통해 보고서 DB에 저장된 보고서데이터 중 어느 하나가 선택되면 선택된 보고서데이터에 해당하는 금융DB로부터 수신받아 보고서를 갱신한다(s340).

여기서 (s340)단계는, 갱신된 보고서데이터의 해시값과 해당 금융사의 블록체인에 기 저장된 해시값을 비교하여 일치하면 최종데이터를 보고서 DB에 저장한다.

이를 자세히 설명하면 아래와 같다.

도 25는 생성된 두 개의 JPA Repository 클래스인 온톨로지 내용과 금융DB 내용이 연계되어 매핑된 나타낸 예시도이다.

ORM 채택 이유는 매핑테이블 정보를 입력받아 금융사 DB로부터 보고서 생성에 필요한 자료를 불러오는 작업의 자동화에 가장 적합한 방식으로 판단되기 때문이다.

ORM을 활용함으로써 현 PoC 대상 보고서에서는 DB를 검색하기 위해 별도의 수동 작업이 필요 없다.

Java ORM 표준인 JPA 를 준수하는 방법들(Raw JPA, QueryDSL, Spring Data JPA) 중 Query Method를 제공하는 Spring Data JPA 방법을 선택하여 금융 DB 액세스를 위한 클래스를 자동 생성한다.

Query Method로 DB 액세스를 위한 질의를 컬럼명과 조건 키워드의 조합으로 쉽게 생성한다.

금융DB의 컬럼으로 매핑이 힘든 보고서 필드는 @Query annotation으로 처리해 코드를 생성한다.

JPA Entity와 Repository 클래스를 기반으로 RESTful 인터페이스를 갖는 보고서 생성 jar 파일을 만들기 위하여 spring boot 기반으로 Service 클래스와 Controller 클래스도 자동 생성한다.

보고서 생성을 위해서는 보고서 포맷 정보를 담고 있는 보고서 정보 CSV를 입력으로 받아 해당 포맷에 맞게 Service 클래스를 생성한다.

DB 테이블 스키마 정보를 담고 있는 데이터 입력 정보를 최소화하여 개발하였다.

DB 테이블을 JAVA 객체인 JPA Entity로 표시하기 위해서는 DB 테이블의 스키마 정보가 필요하다.

사용되는 정보를 최소화하기 같이 네 가지 정보만 사용한다.

보고서 작성에 필요한 보고서 정보를 보고서 포맷 유형을 일반화하여 데이터 입력 정보를 결정함으로써 확장성을 높인다.

보고서 포맷 유형은 기본형(BASIC)과 이중계층형(TWO_LAYERS)의 두 가지를 지원한다.

기본형은 세부 구조가 없이 단일 계층에 (name, values) 쌍의 배열이 나오는 것이고, 이중계층형은 상위는 (name, items) 쌍의 배열이고, 각 items가 (name, values)의 배열을 갖는 구조이다.

보고서 포맷에 추가적인 세부 유형으로 그룹별 출력이면 [GROUP], 아니면 필요한 내역에 따라 BASE(당기), PREVIOUS(전기), DIFFERENCE(증감)을 명시한다.

예를 들어, 당기와 전기만 필요하면 [BASE;PREVIOUS], 증감도 필요하면 [BASE;PREVIOUS;DIFFERENCE]로 명시. 이 때, BASE는 생략 가능하다.

보고서 필드와 DB 테이블의 컬럼 사이의 매핑 정보를 보고서 항목의 다양한 계산 방법을 수용할 수 있도록 유연성 있게 개발한다.

보고서 항목 JSON 표기는 보고서 항목을 JSON 포맷에 나타낼 때 항목 이름을 표기하는 것으로서 TWO_LAYERS 보고서 포맷인 경우 상위 계층과 하위 계층의 이름을 “/”로 구분하여 이어서 표시하였다.

보고서 세부 속성이 GROUP인 경우 항목 값들을 그룹 별로 나타내야 하기 때문에 그룹명을 출력하기 위해 보고서 항목 타입이 GROUPS인 항목이 반드시 존재해야 하며 그룹명들의 값이 사용자 입력 텍스트로 주어진다.

해당 보고서의 다른 항목들은 NUMBER_BY_GROUPS 또는 STRING_BY_GROUPS와 같은 타입을 가진다.

GROUPS인 항목의 사용자 입력 텍스트는 “그룹명:그룹코드”의 쌍이 표시될 순서대로 주어지는데, 예를 들면, “기명식:01;무기명식:02”의 값을 가진다.

사용자 텍스트 입력은 GROUPS 항목처럼 상수 값을 입력하거나 또는 질의를 통해 값을 계산해야 할 때 사용 되는 조건식을 입력하기 위해 사용된다.

DB 스키마 정보를 이용해 DB 테이블의 각각에 대해 JPA Entity 클래스를 생성한다.

Entity 클래스 생성 시 클래스 이름은 테이블 이름의 Camel 표기명 앞에 EntityFor를 붙임. 예를 들어, 테이블 이름이 dpay_appr_list_tbl인 경우 EntityForDpayApprListTbl이 된다.

Entity 클래스 선언 앞에는 @Entity 주석을 사용하여 Entity임을 알리고, @Table 주석을 사용하여 대응되는 DB 테이블명을 적어줌. Hibernate에서 Camel 표기법 ‘_’를 사용하는 snake 표기법으로 자동 변환을 해주기 때문에 DB 테이블명은 dpayApprListTbl과 같이 Camel 표기법으로 적어준다.

Entity의 필드들은 DB 테이블의 컬럼을 나타내는데, 모든 컬럼을 나열하지 않고 보고서 작성에 사용되는 컬럼들과 Entity에 꼭 나타나야 하는 주키(primary key)만 나열함으로써 Entity를 간결하게 표시한다.

엔트리 필드 명은 DB 테이블 컬럼 이름의 Camel 표기명이다.

주키가 단일 컬럼으로 구성된 경우에는 필드 앞에 @Id 주석을 추가하여 주키임을 표시하고, 복수 개의 컬럼으로 구성된 경우에는 각각의 대응되는 필드 앞에 @Id 주석을 달고, 이 필드들로 구성된 PrimaryKey라는 내부 클래스를 추가로 만들어 준다.

JPA Entity 각각에 대해 JPA Repository 클래스를 보고서-DB 매핑 정보를 이용해 생성한다.

보고서 필드와 DB 테이블의 컬럼이 일대일로 대응되는 경우에는 Spring Data JPA Repository의 메소드 명명 규칙에 따라 질의 조건에 맞는 메소드 이름을 생성한다.

Poc 대상 보고서 4개 유형에서 보고서 필드와 DB 테이블의 컬럼이 일대일 대응 시에 발생하는 질의 조건은 모두 날짜 조건들로서 두 가지로 분류할 수 있다.

하나는 POINT 질의로 지정일에 대한 검색이고 다른 하나는 RANGE 질의로 지정기간에 대한 검색임. 전자의 경우 findBy + 날짜조건_컬럼 + Equals로 후자의 경우에는 findBy + 날짜조건_컬럼 + Between으로 메소드 이름을 생성한다.

위에서 만든 JPA Repository의 메소드는 질의 조건에 맞는 튜플들의 모든 컬럼을 반환한다.

따라서, 질의 조건이 동일한 경우에는 메소드를 반복적으로 만들지 않고 하나만 생성하고, 메소의 반환 타입은 해당 Entity 클래스명이 된다.

보고서 필드와 DB 테이블의 컬럼이 일대일로 대응되지 않는 경우에는 질의문을 사용하여 필요한 값을 구해야 한다.

이를 위해 각 보고서 필드에 대해 질의문을 작성하고 그 질의문을 수행시키기 위한 메소드를 생성한다.

메소드 이름은 find + “보고서 필드 이름”로 명명하여 의미를 쉽게 알 수 있게 한다.

메소드의 반환형은 보고서 필드의 타입에 따라 NUMBER는 Long, STRING은 String, NUMBER_BY_GROUPS는 List<Object[]> 형으로 부여한다.

여기서 Object[]은 하나의 튜플을 나타내며 배열의 원소가 튜플 원소 하나에 매핑되며 Group 마다 하나의 튜플이 반환되므로 List로 받는다.

질의문의 작성은 그룹화를 통한 집계 값을 구하는 경우와 그룹화 없이 집계 값을 구하는 경우로 구분되며, 그룹화 없이 집계 값을 구하는 경우에는 “SELECT 집계함수(집계컬럼) FROM DB테이블 WHERE 조건문”으로 질의문을 구성하고, 그룹화가 있는 경우에는 “SELECT 그룹화컬럼, 집계함수(집계컬럼) FROM DB 테이블 WHERE 조건문 GROUP BY 그룹화컬럼”으로 구성한다.

조건문에서 날짜 조건의 경우에는 지정일 조건은 “날짜조건_컬럼 = ?1”으로 지정기간 조건은 “날짜조건_컬럼 BETWEEN ?1 AND ?2”로 생성함. 여기서 ?1, ?2는 파라메터를 받기 위한 장소를 나타낸다.

보고서-DB 매핑 정보에 주어진 사용자 입력 조건은 날짜 조건에 AND로 연결하여 최종 조건문이 생성된다.

Repository 메소드의 형식 파라메터들은 날짜 조건에 따라 날짜 조건이 없으면 “()”, 지정일 조건은 “(String baseMonth)”, 지정기간 조건은 “(String startDate, String endDate)”로 생성된다.

도 22는 각각 자동으로 생성된 BalanceTblRepository와 DpayApprListTblRepository를 보여주고, 전자는 query method에 의한 메소드만 가지고 있고, 후자는 @Query 주석을 사용한 질의 메소드를 포함한다.

보고서 하나에 대해 Spring Service 클래스를 보고서 정보와 보고서-DB 매핑 정보를 이용하여 생성한다.

Service 클래스의 이름은 서비스를 사용하기 위한 REST API URL의 이름 뒤에 Service를 붙여서 명명한다.

보고서의 각 필드에 대해 그 필드 값을 구하기 위해 사용되는 해당 Repository의 메소드를 호출한 후 반환 값을 가공하여 보고서를 나타내는 Java 객체의 해당 필드에 값을 저장한다.

사용되는 Repository들에 대해서 여러 번 사용되더라도 repository 객체를 하나씩만 선언하고, Spring의 의존객체 자동주입을 위해 @Autowired 주석을 추가한다.

몇 개의 보고서 필드들이 하나의 DB 테이블의 컬럼들과 일대일로 대응되는 경우에는 동일 Repository의 동일 메소드를 호출한 후 반환 Entity 객체로부터 대응되는 필드를 추출하게 된다.

이 때, 효율적인 수행을 위하여 메소드를 한 번만 호출함으로써 질의 수행 횟수를 줄인다.

메소드를 호출할 때 질의 조건 유형에 따라 사용자가 입력한 날짜 조건 값을 전달하여 호출함. 날짜 조건이 없으면 “()”로, 지정일 조건이면 “(baseMonth)”로, 지정기간이면 “(startDate, endDate)”로 호출한다.

보고서의 유형이 그룹별 출력이면 보고서 필드 중에 타입이 GROUPS인 필드에 대해 Service 클래스가 호출되어 처리될 때 먼저 (그룹명, 그룹코드)의 리스트를 LinkedHashMap으로 유지한다.

LinkedHashMap은 그룹을 순서대로 유지하면서도 그룹명으로부터 그룹코드를 빠르게 찾을 수 있다.

보고서 유형이 그룹별 출력일 때, GROUPS 필드 외의 필드들은 STRING_BY_GROUP 또는 NUMBER_BY_GROUP 유형의 필드로서 그룹 별로 값들을 추출한다.

STRING_BY_GROUP은 보고서-DB 매핑 정보에 있는 사용자 입력 텍스트에서 그룹별 문자열을 추출한다.

STRING 유형은 집계가 되지 않는 값이므로 GROUP BY문을 사용한 SQL 문으로는 표현할 수 없는 것이다.

NUMBER_BY_GROUP은 보고서의 GROUPS 필드에 나열된 그룹명의 순서와 동일한 순서로 값을 출력한다.

이를 위해 GROUPS 필드를 처리할 때 만들었던 LinkedHashMap 구조의 리스트를 사용한다.

보고서 유형에 보고서 포맷 유형 세부 속성에 따라 당기뿐만 아니라 전기와 증감 내역도 보고서에 기입한다. 예를 들면, 세부 속성이 없으면 디폴트로 당기에 해당하는 내역만 출력하고, [basic:previous]이면 당기와 전기, [basic:previous:difference]이면 당기, 전기, 증감을 모두 출력한다.

전기에 대한 필드 값들을 구할 때, 날짜 조건은 보고서 주기의 분기, 반기, 연간 여부에 따라 월 또는 월의 말일 값을 사용한다.

Java의 YearMonth 클래스의 atEndOfMonth() 메소드를 사용함으로 월에 따른 말일의 차이에 따른 문제를 해결한다.

REST API를 받아 해당되는 보고서를 JSON 형태로 반환하는 Controller 클래스 생성한다.

Controller 클래스는 호출된 url에 따라 해당 보고서를 생성하는 Service 클래스와 연결시켜주는 역할을 한다.

spring framework를 사용함으로써 자동주입으로 간결한 코드가 생성된다.

다음 도 26은 자동생성된 Controller 클래스를 보여준다.

Controller 클래스는 전체 프로그램에 하나만 존재한다.

보고 체계 시스템 영역

보고 체계 시스템은 기능적으로 크게 3가지로 구분하여 설계

보고서UI: 금융감독원 담당자가 보고서의 생성을 지시하고 열람 및 모니터링 하는 기능과 금융사 담당자가 보고서를 생성하고 열람하고 제출하는 기능을 수행하는 웹 기반 화면

보고서 오픈 API: 물리적으로 분리된 금융사 시스템과 금융감독원 시스템 간의 보고서 데이터를 보안적으로 안전하게 송수신하는 기능을 수행하는 API

금융사 API: 금융사 시스템 내에 상주하여 금융감독원의 보고서 생성 지시를 인지하고 금융 DB로부터 보고서 데이터를 추출하고 금융감독원 시스템으로 전달하는 기능을 수행하는 API

MRR 개념 검증 구현 내용

현행 법·규정과 보고서의 체계

MRR 시각화

PoC 대상 법령에 대해 트리구조가 표현된다.

작성된 OWL 파일이 생성되면 전체적인 법령 체계를 한눈에 볼 수 있다.

법령 - 조 - 항 - 호 의 순서로 나타난다.

MRR 구성요소의 상세 사항을 시각화하여 볼 수 있고, 관계를 이해할 수 있다.

클래스, 프로퍼티, 인디비주얼 등 표현이 되어 있다.

각 구성요소 간의 관계가 어떻게 되어 있는지 시각적으로 표현한다.

OWL로 작성된 MRR에 포함된 법령을 검색하고, 법령의 구성요소를 볼 수 있다.

복잡한 법령 전체는 구조 한눈에 보기 어려우므로, 법령 검색기능이 제공되어 원하는 법령을 검색하고 법령의 상세 내용을 볼 수 있다.

또한 우측 하단의 검색어를 입력하면 해당하는 법령, 보고서 또는 MRR 요소들이 검색되고, 필요한 경우 확대하여 볼 수 있다.

원하는 법령을 검색하고 버튼을 클릭하면 해당하는 법령으로 확대가 된다.

POC 이후 전체 법령을 시각화 한다면 구조가 더 크고, 복잡하므로 검색기능은 필수이다.

MRR시각화에 지속적으로 UI 개발이 진행된다면 가시성을 높이고 사용자가 더 이해하기 쉽도록 구성 가능하다.

도 27은 MRR 시각화 관계망 내의 법령 검색화면을 나타낸 예시도이다.

법령 등 선택한 MRR요소에 관련한 OWL 코드와 PIM으로 표현된 규칙을 표현한다.

MRR에 핵심인 OWL코드를 통해 MRR에 활용되는 모든 정보가 담긴 OWL코드 바로 확인 가능하다.

세부사항 클릭 시 선택한 법령에 대해서 이름, 도메인, 범위, 법령 상세내용을 확인할 수 있다.

법령 세부사항 내의 커멘트 클릭시 정합성 시뮬레이션 페이지로 이동한다.

MRR 시각화 도움말

도움말 페이지를 제공하여 MRR에 대한 이해와 전체 프로세스를 이해할 수 있도록 도움을 준다.

MRR의 핵심이 되는 온톨로지에 대한 설명을 포함한다.

시스템을 이용하는데 발생할 수 있는 의문 사항을 해결할 수 있는 사용 가이드 및 도움말을 제공한다.

규제법령 분석하고 특정 보고서 내용의 정합성 판단

MRR 시각화 페이지에서 검색한 법령에 대해서 각 금융기관 보고서의 정합성을 테스트해 볼 수 있다.

변경되지 않은 현재 법령 기준으로 각 보고서의 정합성을 판단 가능하다.

해당 법령에 포함되는 여러 변수들(총자산, 총부채, 미상환잔액, 가맹점 수 등)이 최신화 되어 데이터베이스에 있어야 함. 이는 제출기한에 맞춰서 금융기관으로부터 보고를 받기 때문에 금감원 데이터베이스 데이터가 있다는 가정을 한다.

법령의 구조가 더욱 복잡해질 경우 더욱 고도화된 룰 세트와 판정로직이 적용되어야 하며, 일부 법령에 대해서는 불가할 수 있다.

추가 개발 시 현행법령 기준으로 앞으로 금융기관의 재무상태가 어떻게 변할지 가정하고 시뮬레이션 해보는 것도 가능하다.

법령 텍스트 원문을 기계가 실행가능 하도록 변환

이는 수식과 관련되어 사용자의 이해도 어렵지 않고, 변경 시뮬레이션도 간편하다.

현행 법령 기준 : 보고서 정합성 판정과 비교해 보았을 때, 법령에서의 기준 수치, 값을 변경했을 때 금융기관이 어느 정도 부합하는지 시뮬레이션 가능하다.

법령의 구조가 더욱 복잡해질 경우 더욱 고도화된 룰 세트와 판정로직이 적용되어야 하며, 일부 법령에 대해서는 불가할 수 있다.

법령 변경 분석

법령 변경분석 메뉴에서는 현재의 MRR 화면으로부터 시작하여 변경하려는 법령을 검색하여 찾는다.

하단의 바를 클릭하여 변경예정인 법령 텍스트를 불러온다.

향후 법령의 양이 늘어나게 될 경우 MRR 시각화와 유사하게 검색/선택 기능이 필요하다.

변경하려는 부분을 선택한다.

법령의 추가, 삭제, 수정이 가능하다.

법령을 수정할 때 사용자가 편의를 위한 에디터를 적용할 수 있다.

법령을 변경한다.

불러온 법령에서 변경 예정 사항을 삭제/추가한 후 수정 버튼을 클릭하면 변경 예정인 법령이 저장된다.

변경 법령으로 인한 MRR 요소 변화를 반영한다.

법령 분석 시작 버튼을 누르면 AI, 형태소분석 프로그램이 저장된 법령을 분석한다.

분석 프로그램을 API로 실행 요청한다.

본 발명에는 유지보수 관리 측면에서 학습을 새롭게 수행하고 모델을 변경하고자 할 때를 위해 관리자 페이지를 별도로 구성할 필요가 있다.

시작 클릭하면 분석이 실행된다.

본 발명에는 법령의 양이 확대되므로 시간이 다소 소요될 수 있다.

대기시간 중 진행 상황을 표시해 줄 별도 UI가 필요하다.

변경 예정인 텍스트가 저장된 이후 저장된 텍스트를 AI가 자연어처리를 한다.

자연어 처리를 통해 규정에 대한 문장들을 추출한다.

추출한 문장에서 MRR 구성요소를 판별한다.

MRR 구성요소가 화면에 표시된다.

생성되어 화면에 표시된 MRR 요소를 참고하여 전문가가 protege를 활용해 OWL을 생성한다.

protege를 MRR 시스템에 내재화하여 OWL 생성까지 자동화가 가능하다.

따라서 사용자는 법령 원문을 수정하면 변경된 MRR 결과를 받기까지 전자동화가 가능하다.

OWL 생성이 완료되면 현행 MRR 시각화와 변경예정인 MRR시각화 화면이 나타난다.

구조적으로 큰 변화가 있는 경우에는 사용자가 쉽게 알 수 있지만 그렇지 않은 경우 변경된 내용이 있는 곳을 강조하여 나타낸다.

법령 변경 사실을 일괄적으로 금융기관에 공지한다.

본 발명에는 공지하는 프로세스는 따로 분리를 할 수 있다.

매핑 테이블 작성기

현행 법령을 분석 및 OWL로 생성하고, 이를 금융기관 DB와 매핑시키기 위해 매핑 테이블을 작성한다.

매핑테이블이 한번 구성되면 추가적으로 반복해서 작성할 필요는 없으나, 기존에 없던 신설 법령이 추가될 경우 새롭게 테이블을 매핑 해야한다.

매핑 된 테이블은 생성된 jar와 함께 금융기관으로 전달된다.

OWL에서 추출된 프로퍼티에 매핑해야 할 목록을 나타낸다.

금융기관 DB를 연결하기 위해 각 프로퍼티별로 매핑한다.

CSV 생성 버튼 클릭을 하면 서버로 csv파일이 생성된 후에 저장된다.

ORM

table_info.csv와 MRR-금융DB 매핑 정보가 저장되면 ORM에서는 금융DB에서 관련 자료를 가져오는 프로그램을 자동 생성한다.

java 생성파일 버튼 클릭을 하면, java 프로그램을 통해 매핑된 테이블과 jar를 생성한다.

java 프로그램을 통해 매핑된 테이블과 jar를 배포한다.

보고 체계 영역

보고 체계 시스템 개념 검증 프로세스

도 29는 보고 체계 시스템 개념 검증 프로세스의 전체 업무의 흐름을 나타낸 흐름도이다.

정기적인 보고서 제출 시점(년간/반기/분기)에 스케쥴링에 의한 자동 배치를 통하거나 금융감독원 담당자가 보고서 웹 화면에서 비정기적으로 보고서의 생성을 지시한다.

보고서 생성 지시는 금융감독원 블록체인을 통해 전체 금융사의 블록체인에 지시 명령을 저장한다.

금융사 담당자는 보고서 웹 화면을 통해 금융감독원으로부터의 정기적/비정기적인 보고서 생성 지시를 확인하고 보고서 생성을 수행한다.

보고서 생성 수행은 해당 금융사의 블록체인에 생성 명령을 저장한다.

금융사 시스템에 있는 금융사 API 프로그램이 블록체인에 저장된 생성 명령을 자동으로 인지하여 생성을 수행. 보고서 데이터 생성 수행 과정은,

MRR 시스템에서 기 생성된 보고서 데이터 추출 프로그램의 변경 여부를 판단하여 금융사 서버로 다운로드

다운로드한 프로그램을 실행

금융감독원에서 지시받은 보고서 데이터를 금융사 DB로부터 추출

추출된 보고서 데이터의 해시값을 해당 금융사의 블록체인에 저장

추출된 보고서 데이터의 정합성 검증을 수행하고 그 결과를 포함한 최종 데이터를 보고서 DB에 저장

금융사 담당자가 데이터 검수를 위해 생성된 보고서를 열람하는데 이 때 블록체인에 기 저장된 해시값을 조회하고 보고서 DB에 저장된 보고서 데이터의 해시값을 비교하는 위변조 검증을 통해 일치하면 보고서 화면 노출

금융사 담당자가 보고서 데이터 확인 후 금융감독원에 제출

금융감독원 담당자는 금융사로부터 제출받은 보고서를 열람하는데 이 때도 블록체인에 기 저장된 해시값을 조회하고 보고서 DB에 저장된 보고서 데이터의 해시값을 비교하여 위변조 검증을 통해 일치하면 보고서 화면 노출

보고 체계 시스템별 업무 구분

도 30는 보고 체계 시스템별 업무 구분에 따른 시스템별 구성을 나타낸 예시도이다.

금융감독원 시스템

보고서 UI: 금융감독원 및 금융사 관리자가 보고서 관련 업무를 처리를 위해 이용하는 웹 화면

보고서 Open API: MRR 시스템으로부터 수신한 보고서 데이터 추출용 프로그램의 변경 여부를 판단하고 해당 프로그램을 금융사 시스템에 다운로드하며 생성된 보고서 데이터를 금융사 시스템으로부터 수신받아 정합성을 검증하고 보고서 DB에 저장하기 위한 API

블록체인 망: 금융감독원의 보고서 생성 지시 정보를 저장하고 모든 금융사와 이를 공유

금융사 시스템

금융사 API: MRR 시스템으로부터 보고서 데이터 추출용 프로그램을 다운로드 및 실행하여 금융사 DB로부터 보고서 데이터를 추출하고 금융감독원 시스템으로 송신하기 위한 API

API Gateway

금융사 API가 금융감독원의 보고서 Open API를 호출할 때 중계 역할을 하는 시스템

보고서 Open API 호출 시 직접적인 주소를 노출하지 않고 감출 수 있도록 보안적인 지원

운영 시점에 보고서 Open API 호출 주소가 변경되어도 금융사 API는 변경이 없고 API Gateway 내 매핑 주소만 변경하면 되므로 실시간 변경 반영이 가능

물리적으로 분리되어 있는 금융감독원 시스템과 금융사 시스템 간의 보안적으로 안전한 데이터 통신을 지원

보고 체계 금융감독원 업무 프로세스

보고서 생성 지시: 금융감독원 담당자가 금융사에 보고서 생성을 지시

보고서 열람: 금융사에서 제출한 보고서를 열람하여 보고서 데이터 검토

보고서 데이터 위변조 검증: 보고서 열람 시 블록체인에 저장된 보고서 데이터 해시값과 보고서 DB에 저장된 보고서 데이터 해시값을 비교하여 위변조 여부 검증

보고서 정합성 검증: 금융사에서 생성된 보고서 데이터 저장 시점에 해당 데이터의 법령 규정 위반 여부를 판단하여 보고서 데이터와 함께 정합성 검증 결과를 저장

법령 변경 알림 기능: 법령의 변경 발생 시 MRR로부터 통보 받아 보고서 화면에서 인지할 수 있도록 알림을 표시하고 상세 내용을 화면에 출력

보고 체계 금융사 업무 프로세스

보고서 데이터 추출 프로그램 처리: 블록체인 저장된 보고서 생성 명령을 자동 인지하여 보고서 데이터 추출 프로그램의 변경 여부를 판단하고 변경 시 다운로드 한 후 프로그램 기동

보고서 생성/열람/제출: 금융사 담당자가 금융감독원으로부터 지시 받은 보고서를 생성하고 생성된 보고서를 열람한 후 제출

보고서 데이터 해시값 저장: 금융사 DB로부터 추출된 보고서 데이터를 SHA256 해시 알고리즘을 이용한 암호화된 값을 블록체인에 저장하여 보고서 열람 시 위변조 검증에 이용

금융감독원 보고서 화면

도 31은 금융감독원 보고서 화면을 나타낸 예시도이고, 도 32는 대시보드의 화면구성을 나타낸 예시도이다.

금융감독원에서 생성 지시한 보고서의 제출 현황을 권역별로 제출/미제출 건수에 대해 막대 그래프로 표현한다.

기준연월과 주기에 따라 좀 더 세분화된 검색을 통해 권역별로 제출/미제출 비율을 비교 검토 가능하다.

권역별 막대 그래프를 선택하면 하위에 제출대상 건수, 제출/미제출 건수에 대한 상세 목록을 노출하여 권역별로 미제출 상황을 파악 가능하다.

경영지도기준 추이

경영지도기준 보고서의 데이터를 기반으로 최근 3년간의 추이를 선형 그래프로 표현한다.

기준연월과 권역에 따라 경영지도기준 보고서 데이터의 추이를 검토하여 데이터의 유효성 및 오류 가능성 등을 판단 가능하다.

경영지도기준 보고서의 각 항목별 추이 그래프를 통해 항목 간의 데이터 크로스 검증한다.

보고서 생성 지시

정기적인 보고서 생성 지시는 주기(년간/반기/분기)에 따라 스케줄러에 의해 자동으로 진행되지만, 비정기적으로 보고서의 생성 지시 혹은 재지시를 하기 위한 화면이다.

원하는 금융사에 특정 기준연월에 대해 특정 보고서 생성을 지시한다.

보고서 생성 지시에 대한 블록체인 정보 확인 가능하다.

하단의 보고서 생성 지시 이력 목록의 각 항목을 클릭하여 정렬 가능하다.

전자금융보고서 관리

기준연월, 권역, 금융사, 보고서 종류, 주기, 상태 등을 검색조건으로 하여 금융사에서 제출한 보고서 목록을 조회한다.

금융사의 보고서 생성 수행에 대한 블록체인 정보 확인 가능하다.

보고서 열람을 통해 금융 법령 규정에 부합하는지 확인하여 해당 보고서 생성 재지시 필요여부 판단한다.

하단 목록은 각 항목 클릭을 통해 오름차순/내림차순 정렬 가능하다.

보고서 검색 시 각 목록에 대한 정합성을 확인하여 위반 시 해당 데이터 라인은 붉은 색으로 표현한다.

법령 변경 공지 알람

MRR 시스템에서 법령의 변경이 발생했을 때 보고서 시스템에서 자동으로 인지 가능하도록 하는 알람 기능

최근 3일 이내에 등록된 변경 공지사항의 수를 노출

클릭 시 변경 공지사항의 목록을 최근 순으로 볼 수 있고 선택 시 상세한 내용을 보여준다.

보고서 열람

금융사에서 제출한 보고서를 양식에 따라 열람

보고서 열람 시 금융사가 보고서 데이터를 생성하는 시점에 블록체인에 저장한 보고서 데이터의 해시값과 현재 열람하는 시점의 보고서 데이터에 대한 해시값을 비교 검토하여 보고서 위변조를 검증

보고서 화면 하단에 두 해시값을 노출하여 명시적으로 비교

정합성 위반 보고서의 경우 열람 시 화면 상단에 규정 위반에 대한 상세 내용을 노출

보고서 열람을 통해 금융 법령 규정에 부합하는지 판단

금융사 보고서 화면

전자금융보고서 관리

기준연월, 보고서 종류, 상태 등을 검색조건으로 하여 해당 금융사의 보고서 상태별 보고서 목록을 조회

보고서 생성 수행에 대한 블록체인 정보 확인 가능

보고서 생성 시 MRR 시스템으로부터 해당 보고서의 규정 위반 여부를 검증하여 그 결과를 DB에 함께 저장

생성 또는 제출한 보고서는 양식에 따라 열람 가능

경영지도기준 추이

경영지도기준 보고서의 데이터를 기반으로 최근 3년간의 추이를 선형 그래프로 표현

기준연월과 항목에 따라 경영지도기준 보고서 데이터의 추이를 검토하여 데이터의 유효성 및 오류 가능성 등을 판단 가능

경영지도기준 보고서의 각 항목별 추이 그래프를 통해 항목 간의 데이터 교차 검증

보고서 열람

금융사가 생성 또는 제출한 보고서를 양식에 따라 열람

보고서 열람 시 해당 금융사가 보고서 데이터를 생성하는 시점에 블록체인에 저장한 보고서 데이터의 해시값과 현재 열람하는 시점의 보고서 데이터에 대한 해시값을 비교 검토하여 보고서 위변조를 검증

보고서 화면 하단에 두 해시값을 노출하여 명시적으로 비교

보고서 열람을 통해 금융 법령 규정에 부합하는지 확인하고 미부합 시 해당 보고서를 재생성 수행이 가능

법·규정 변경 영향 분석

법령 변경 시 보고 체계 시스템 업무 프로세스

도 33은 법령 변경 시 보고 체계 시스템 업무 프로세스를 나타낸 법령 변경 논리 구성도이다.

MRR 시스템에서 보고체계 시스템에 법령 변경 정보를 전달하면 금융감독원 및 금융사 보고서 화면에 동일하게 공지사항 알람을 표지하여 담당자가 인지하고 변경된 내용을 확인할 수 있도록 한다.

법령 변경의 내용이 보고서 양식에 영향을 주는 내용인 경우, 즉 보고서의 주기, 제출기한 일수, 보고서 폐지 등인 경우 보고체계 시스템에 해당 정보를 전달하여 스케쥴러에 의한 자동 보고서 생성 지시 프로그램에 반영되도록 한다.

법령 변경에 대한 보고서 생성 지시부터 이후의 과정은 일반적인 작업 수행과정 절차로 진행한다.

보고서 출력항목의 변화를 주는 경우 MRR 시스템으로부터 해당 변경 사항에 대한 상세 내용을 수신 받아 보고서 화면에 알람 공지한다.

보고서의 항목에 발생한 변화의 내용을 반영한 머신 실행가능 레귤레이션을 통해 생성된 보고서 추출용 프로그램을 금융사 시스템에 다운 받아 웹 서버를 기동시키고 금융사 DB로부터 보고서 데이터를 다시 추출 및 생성하여 금융감독원의 보고서 DB에 저장한다.

항목의 변화가 발생하여 재생성한 보고서는 열람을 통해 보고서 항목의 추가/변경/삭제에 대한 결과를 확인 가능하다.

보고서 출력항목의 변화를 주지 않는 경우, MRR 시스템으로부터 해당 변경 사항에 대한 상세 내용을 수신 받아 보고서 화면에 알람 공지한다.

본 발명이 속하는 기술분야의 통상의 지식을 가진 자는 본 발명이 그 기술적 사상이나 필수적인 특징을 변경하지 않고서 다른 구체적인 형태로 실시될 수 있다는 것을 이해할 수 있을 것이다. 그러므로 이상에서 기술한 실시예들은 모든 면에서 예시적인 것이며 한정적이 아닌 것으로 이해해야만 한다. 본 발명의 범위는 상기 상세한 설명보다는 후술하는 특허청구의 범위에 의하여 나타내어지며, 특허청구의 범위의 의미 및 범위 그리고 그 균등 개념으로부터 도출되는 모든 변경 또는 변형된 형태가 본 발명의 범위에 포함되는 것으로 해석되어야 한다.

110: 변환모듈 120: 추출모듈
130: 판단모듈 140: 결합모듈
210: 온톨로지DB 220: 표시모듈
230: 수정모듈 310: 테이블생성모듈
320: 보고서수신모듈 330: 보고서 갱신모듈

Claims (8)

1. 자연어로 표현된 법령 또는 규정을 형태소분석을 통해 온톨로지 요소들로 구분한 후 온톨로지코드(OWL code; 이하 온톨로지 코드)로 변환하여 저장하는 온톨로지 DB;
   출력요청정보가 수신되면 상기 출력요청정보에 따라 상기 온톨로지 DB에 저장된 자연어로 표현된 법령 또는 규정을 온톨로지 요소간 관계에 따라 상위 법령 또는 규정으로부터 하위 법령 또는 규정까지 온톨로지 트리구조로 표시하는 표시모듈;을 포함하는 온톨로지 기반 머신 리더블 레귤레이션 시각화 시스템.
2. 제1항에 있어서, 상기 출력요청정보는,
   클라이언트를 통해 입력된 검색정보를 포함하는 것을 특징으로 하고,
   상기 표시모듈은,
   상기 검색정보가 수신되면 상기 검색정보를 온톨로지 코드로 변환하고, 변환된 온톨로지 코드를 포함하는 하나 이상의 법령 또는 규정들을 검출하여 출력하는 것을 특징으로 하는 온톨로지 기반 머신 리더블 레귤레이션 시각화 시스템.
3. 제1항에 있어서, 상기 온톨로지 트리구조는,
   상위 법령 또는 규정으로부터 하위개념인 조, 항, 호 순서로 연결되어 표시되는 것을 특징으로 하는 온톨로지 기반 머신 리더블 레귤레이션 시각화 시스템.
4. 제1항에 있어서,
   상기 표시모듈에 표시된 상기 온톨로지 DB에 저장된 자연어로 표현된 법령 또는 규정 중 어느 하나가 선택된 후 수정정보가 수신되면 상기 수정정보에 포함된 교체법령정보를 검출하고 검출된 교체법령정보를 형태소분석하여 온톨로지 요소들로 구분한 후 온톨로지코드로 변환하여 저장하는 수정모듈;을 더 포함하는 것을 특징으로 하는 온톨로지 기반 머신 리더블 레귤레이션 시각화 시스템.
5. (a) 자연어로 표현된 법령 또는 규정을 형태소분석을 통해 온톨로지 요소들로 구분한 후 온톨로지코드(OWL code; 이하 온톨로지 코드)로 변환하여 온톨로지 DB에 저장하는 단계;
   (b) 출력요청정보가 수신되면 상기 출력요청정보에 따라 상기 온톨로지 DB에 저장된 자연어로 표현된 법령 또는 규정을 온톨로지 요소간 관계에 따라 상위 법령 또는 규정으로부터 하위 법령 또는 규정까지 온톨로지 트리구조로 표시하는 단계;을 포함하는 온톨로지 기반 머신 리더블 레귤레이션 시각화 방법.
6. 제5항에 있어서, 상기 출력요청정보는,
   클라이언트를 통해 입력된 검색정보를 포함하는 것을 특징으로 하고,
   상기 (b)단계는,
   상기 검색정보가 수신되면 상기 검색정보를 온톨로지 코드로 변환하고, 변환된 온톨로지 코드를 포함하는 하나 이상의 법령 또는 규정들을 검출하여 출력하는 것을 특징으로 하는 온톨로지 기반 머신 리더블 레귤레이션 시각화 방법.
7. 제5항에 있어서, 상기 온톨로지 트리구조는,
   상위 법령 또는 규정으로부터 하위개념인 조, 항, 호 순서로 연결되어 표시되는 것을 특징으로 하는 온톨로지 기반 머신 리더블 레귤레이션 시각화 방법.
8. 제5항에 있어서,
   (c) 상기 (b)단계를 통해 표시된 상기 온톨로지 DB에 저장된 자연어로 표현된 법령 또는 규정 중 어느 하나가 선택된 후 수정정보가 수신되면 상기 수정정보에 포함된 교체법령정보를 검출하고 검출된 교체법령정보를 형태소분석하여 온톨로지 요소들로 구분한 후 온톨로지코드로 변환하여 저장하는 단계;를 더 포함하는 것을 특징으로 하는 온톨로지 기반 머신 리더블 레귤레이션 시각화 방법.
   
   

Images