기본 콘텐츠로 건너뛰기

월리를 찾아라: 문서에서 단어 분류

그림책 속 수많은 사람들 중에서 월리를 찾는 것처럼 문서의 수많은 단어들 중에서 원하는 단어를 찾는 일은 쉬운 일이 아닙니다.
아니 월리를 찾는 것이 더 쉬울지도 모르겠습니다.
요즘 회사들 사이에 Digital Transform(이하 DT)가 유행하고 있습니다. DT는 회사가 가지고 있는 문서들을 디지털 데이터로 변환하는 것을 말합니다. 4차 산업혁명의 핵심 기술인 AI를 활용하기 위해서 말이죠.
수많은 문서들 그리고 같은 의미를 가지는 다른 표현들. DT를 하기 앞서 이러한 단어들의 표준화가 진행되어야 합니다.
용어들의 표준화를 하기 위해 표준 용어 사전집이 필요합니다. 전국 사투리를 수집하고자 한다면 우선 서울 표준어를 정한 뒤 같은 의미를 가지는 사투리를 쭉 나열할 수 있습니다. 경상도/전라도/충청도/강원도/제주 사투리....
서울 태생인 아내가 같은 의미를 가지는 단어를 하나여야만 한다고 이야기하던 일이 생각납니다.
경상도 출신인 저는 사투리도 중요하다고 반론을 했었습니다. 우리가 계산하고 나갈 때 식당 주인아주머니께서 저희를 보더니 빙긋 웃었습니다.
이렇듯 같은 의미를 가지는 용어들을 표준 용어집을 이용하여 표준 용어로 바꾸어 줍니다.
장치 문서
표준 용어집
위 표준 용어집을 이용하면 아래와 같이 바뀌게 될 것입니다.
이제 표준화된 용어를 분류하여 사전에 정의해둔 분류체계로 변환을 해야 합니다.
분류 체계
분류체계에 맞는 Value와 UOM(단위)를 찾아 채워줘야 합니다.
Value와 UOM을 찾아 어떤 분류 체계에 속하는지 자동으로 채워주면 좋겠지만 이것은 대단히 어려운 작업이 될 거라 생각됩니다.
따라서 사용자가 Value와 UOM에 맞는 분류 체계를 선택하도록 합니다.
분류 체계 선택 후에 문서에서 값을 읽어 채워주면 아래와 같이 됩니다.
분류 체계에 맞게 값이 채워진 화면
위 데이터가 사용자가 원하는 최종 데이터입니다.

최종 데이터를 추출할 때 앞서 말한 표준 용어집은 의미가 없어 보입니다.
Value와 UOM에 맞는 분류 체계를 선택했기 때문에 값을 추출하여 분류 체계에 채워주기만 하면 됩니다. 딱히 표준 용어집이 쓰일 곳이 없습니다.
한 문서에서 분류 체계대로 데이터를 추출한 후 다른 문서에서도 똑같이 데이터를 추출한다고 생각해 봅시다.
그러면 Value와 UOM에 맞는 분류 체계 선택 작업을 또다시 해줘야 합니다. 사람들은 반복 작업을 무척이나 싫어합니다.
그래서 Value와 UOM에 맞는 분류 체계 선택 작업의 내용(분류 체계: 텍스트 영역, 이하 템플릿)을 저장하여 재활용할 수 있도록 합니다.
같은 양식의 문서들 즉 글자의 위치를 똑같고 Value와 UOM의 값이 바뀌는 문서들에 대해서는 저장한 템플릿을 100% 활용할 수 있습니다.
하지만 이렇게 저장한 템플릿은 글자 위치, 스케일이 다른 유사한 양식의 문서들에 대해서는 무용지물이 됩니다.
이런 유사 양식의 문서들을 처리하기 위해 많은 템플릿을 저장하여 사용하는 방식을 이용합니다.
새롭게 작업할 문서가 들어왔다고 생각해봅시다.
이제 템플릿을 많이 만들어 두었기 때문에 마음이 든든합니다. 문서 양식에 맞는 템플릿을 선택하여 적용하기만 하면 되기 때문입니다.
그런데 템플릿이 1000개나 됩니다. 1000개나 되는 템플릿을 일일이 열어 문서와 양식이 맞는지 확인하는 작업을 하고 싶진 않습니다.
쌓아둔 템플릿에서 문서와 양식이 맞는 것을 찾는 작업을 자동으로 하고 싶습니다.
템플릿에는 Value와 UOM의 위치 정보 그리고 분류 체계 정보만을 가지고 있습니다.
이것만으로는 쌓아둔 템플릿에서 작업 문서 양식과 가장 일치하는 것을 찾기는 부족합니다.
문서 양식을 정의할 수 있는 중요한 요소를 템플릿에 저장해 두어야 합니다.
표준 용어집의 내용들이 문서 양식을 정의하는데 중요한 요소가 됩니다.
따라서 템플릿을 저장할 때 표준 용어집으로 찾은 텍스트의 영역 정보를 추가해 줍니다.
표준 용어: 텍스트 영역 좌표 이제 템플릿의 표준 용어: 텍스트 영역 좌표 중 작업 문서에서 텍스트 영역 좌표에서 텍스트를 추출하여 표준 용어와 일치하는지 확인합니다.
모든 템플릿에서 등록한 표준 용어들 중 몇 개가 작업 문서에 나타나는지 양식 유사도를 매깁니다.
유사도가 가장 높은 템플릿을 사용자에게 추천해 주고 사용자는 이것을 이용하여 작업합니다. 사실 템플릿 유사도가 100% 되는 일은 거의 없습니다.
작업 진행 중에도 새로운 문서 양식에 대한 템플릿을 등록해 줍니다.
이렇게 템플릿을 쌓아두면 향후에는 100%에 근접하는 유사도를 가진 템플릿으로 작업을 수월하게 진행할 수 있을 겁니다.
(다들 이렇게 생각합니다.
이 글을 쓰면서 템플릿의 유사도는 문서에 적용할 표준 용어의 수와 표준 용어집에 있는 용어들 사이의 유사도에 영향을 받는다는 생각이 들었습니다.
아쉽지만 그리고 당연한 이야기지만 100% 유사도를 가진 템플릿을 만들 수는 없습니다.)
활발한 두뇌 활동을 하고 나서 한숨 돌리고 쉬는 중에 문서에 나타나는 표준 용어를 분류 체계의 LEVEL과 연결할 있도록 하면 좋겠다고 합니다.
분류 체계상의 LEVEL은 사람들이 많은 속성들을 체계적으로 분류하려고 나눈 것이고 표준 용어집은 문서에 나타나는 말들의 유의어 사전입니다. 둘 사이에는 아무런 연관성이 없습니다.
서로 다른 두 세계를 연결하기 위해 허공에 다리를 놓을 수는 있습니다.
바로 LEVEL에 표준 용어를 매칭시켜주는 것입니다. 단 효용성에 대해서는 제 머리로는 계산이 안됩니다. 삐리삐리 퍽~~~
어쨌든 문서 내의 표준 용어와 LEVEL을 연계시켰다면 분류 체계 내의 LEVEL와 Value, UOM과 연계 시켜주는 작업도 필요할 것 같습니다.
이유는 아마도 사용자들의 머리에는 이런 그림이 들어 있을 겁니다.
추출한 분류 체계를 선택하면 문서에서 분류 체계 내용에 해당하는 부분이 표시되길 바랄 것 같습니다.
이렇게 하기 위해서는 앞서 말한 것처럼 LEVEL과 Value, UOM을 연계시키는 것이 필요합니다.
이 연계 작업을 자동화시키면 좋겠지만 추출한 데이터의 모호성 때문에 쉽지만은 않습니다.
추출 용어 TOP, BOTT, DRUM은 문서에서 각각 2번씩 나타납니다. 따라서 추출 당시에는 OPER. TEMP 혹은 OPER. PRESS에 속하는지 알 수 없습니다.
그리고 OPER. TEMP, OPER. PRESS는 TOP, BOTT, DRUM과 연결이 되기 때문에 1:N의 관계를 가지게 됩니다.
이들 용어들은 모든 용어를 추출한 후에 용어들의 연관 관계를 추정하여 연계를 시킬 수 있습니다.
용어들 간의 연관 관계 추정을 자동으로 하고 싶지만 양식에 따라 달라지니 쉽지 않고 경우에 맞게 개발을 진행할 수도 있습니다.
다만 경우의 수가 얼마가 될지 모르니 너무 막연하고 머리가 지끈거립니다.
마지막으로 길게 설명한 문서, 표준 용어집, 분류 체계 간의 관계를 아래 내용으로 정리할 수 있습니다.

댓글

이 블로그의 인기 게시물

80040154 오류로 인해 CLSID가 {xxxx-...}인 구성 요소의 COM 클래스 팩터리를 검색하지 못했습니다.

원문보기 .NET 으로 만든 응용프로그램에서 com 객체를 호출한 경우 Windows7 64bit 에서 제목과 같은 에러가 발생했다. Win32 COM 과 .NET 프로그램간의 호환성 때문에 생긴 문제였다. 원인은 .NET 실행시 JIT 컴파일러에 의해 최적화된 기계어로 변환되기 때문.. Win32 COM은 컴파일시.. Win32 COM에 맞춰 빌드 속성에서 하위버전으로 맞춰 컴파일을 다시하는 방법도 있지만 메인 프로젝트가 .NET이라면 참조되는 모든 프로젝트를 다 바꿔야할 노릇.. 또 다른 방법은 COM+를 이용하여 독립적으로 만드는 것이다. 분리시키는 방법은 아래 주소해서 확인할 수 있다. http://support.microsoft.com/kb/281335 나의 경우는 Win32 COM DLL을 64비트 .NET 프로그램에서 참조하니 COM 객체를 제대로 호출하지 못하였습니다. 그래서 .NET 프로그램의 Target Machine을 x86으로 설정하니 제대로 COM 객체를 호출하였습니다.

[Pyinstaller] 실행 파일 관리자 권한 획득하기

고객사에서 일부 사용자에게서 프로그램 오류가 발생한다며 아래와 같이 에러 캡처를 보내왔습니다. 프로그램에서 로그를 남기기 위해 로그 파일을 생성하는데 권한의 문제로 로그 파일을 생성하지 못해 프로그램 오류가 발생한 것 같습니다. 처음에는 Python 코드에서 관리자 권한을 요청하는 코드를 넣으려고 했는데, 실제로 Stackoverflow를 찾아보면 이런 내용이 나옵니다. 프로그램이 관리자 권한으로 실행되지 않았다면 관리자 권한으로 다시 프로그램을 실행시키는 코드입니다. import os import sys import win32com.shell.shell as shell ASADMIN = 'asadmin' if sys.argv[-1] != ASADMIN: script = os.path.abspath(sys.argv[0]) params = ' '.join([script] + sys.argv[1:] + [ASADMIN]) shell.ShellExecuteEx(lpVerb='runas', lpFile=sys.executable, lpParameters=params) sys.exit(0) 하지만 개인적으로 이런 방식은 마음에 들지 않았고 조금 더 찾아보니 Pyinstaller로 exe 파일을 만들 때 옵션을 설정하여 관리자 권한을 요청하도록 할 수 있다고 합니다. --uac-admin을 옵션에 추가하면 프로그램 실행 시 관리자 권한을 요청할 수 있습니다. pyinstaller.exe --uac-admin sample.py 하지만 안타깝게도 이 방식은 원하는 대로 동작하지 않았습니다. 마지막으로 manifest 파일을 이용하여 시도해보았습니다. spec 파일을 이용하여 pyinstaller로 빌드하면 <실행 파일 이름>.manifest 라는 파일이 생성됩니다. 파일에서 아랫부분을 찾아볼 수 있습니다. <security> <re

초간단 프로그램 락 걸기

프로그램에 락을 걸 일이 생겨났다. 하드웨어 락을 걸면 쉬울텐데 그 정도는 아니고 프로그램의 실행 날짜를 제한 해 달라고 한다. 그래서 파일(license.lic)을 가지고 락을 걸리고 결정을 했다. 요구 사항은 아래와 같다. 1. license.lic 파일이 없으면 프로그램을 실행 할수 없게 한다. 2. 지정한 날짜를 넘어서는 프로그램을 실행 할수 없게 한다. 3. 사용자가 시스템 날짜를 되돌렸을때 인식하여 프로그램을 실행 할수 없게 한다. 음.... 1.번 문제는 사용자가 프로그램을 실행하기 위해서 license.lic 파일을 받아야만 한다. license.lic 파일에는 최근 실행 날짜/종료날짜 이런식으로 적도록 한다.(물론 내용은 암호화 한다.) 최근 실행날짜는 프로그램이 실행때마다 업데이트 하도록 하고 시스템 날짜와 비교하여 시스템 날짜가 최근 실행 날짜보다 이전의 날짜면 시스템 날짜를 되돌렸다고 인식하도록 한다.(3.번 문제 해결) 시스템 날짜와 종료 날짜를 비교하여 시스템 날짜가 종료 날짜를 넘으면 프로그램을 실행 할수 없도록 한다.(2.번 문제 해결)