KIE란 무엇인가: 문서에서 업무 데이터를 뽑아내는 핵심 정보 추출 완전 정리

KIE(Key Information Extraction)란, 문서에 적힌 내용 가운데 업무에 필요한 항목만 골라내어 키와 값의 쌍으로 구조화하고, 기존 업무 시스템에 그대로 입력할 수 있는 형태로 바꾸는 기술입니다.

KIE가 필요해진 배경

읽는 것만으로는 부족합니다.

문서 이미지를 텍스트로 바꾸는 기술은 오래전부터 있었고, 인쇄체 기준 정확도는 이미 충분히 높습니다. 그런데도 담당자의 업무는 크게 줄지 않았습니다. 인식 결과가 한 덩어리의 글자로 나오면, 그 안에서 사업자등록번호가 어디이고 대표자명이 어디인지는 결국 사람이 눈으로 찾아 시스템에 옮겨 적어야 하기 때문입니다. 해외 법인의 여신 심사 업무에서 신청 서류 한 건을 확인하고 입력하고 대조하는 데 21분 이상이 걸렸던 것도 같은 이유입니다. KIE는 이 지점을 겨냥한 기술입니다.

KIE의 정확한 정의: OCR과 무엇이 다른가

OCR과 KIE, 세 가지 축의 차이

첫째, 대상이 다릅니다. OCR은 이미지 위의 문자를 대상으로 삼습니다. KIE는 인식된 글자와 그 글자가 놓인 위치, 주변 항목명을 함께 대상으로 삼습니다.

둘째, 목표가 다릅니다. OCR의 목표는 적힌 글자를 빠짐없이 정확하게 옮기는 것입니다. KIE의 목표는 업무에 필요한 항목을 골라 값과 짝지어 내보내는 것입니다. 같은 문서에서 OCR은 사업자등록번호와 그 뒤의 숫자를 하나의 문자열로 내놓고, KIE는 사업자등록번호라는 키에 그 숫자가 값으로 연결된 데이터를 내놓습니다.

셋째, 성과지표가 다릅니다. OCR은 문자 단위 정확도로 측정합니다. KIE는 항목 단위의 완전 일치율과 사람이 수정한 비율로 측정합니다. 문자 정확도가 높아도 항목 연결이 어긋나면 업무에서는 오류로 처리되므로, 두 지표를 나누어 보는 편이 정확합니다.

두 기술은 대체 관계가 아닙니다. OCR이 읽지 못한 글자는 KIE도 추출할 수 없으므로, 인식 품질 위에 추출 구조를 올리는 순서가 맞습니다.

업무에 투입할 수 있는 KIE의 5가지 조건

실제 운영에 들어가는 KIE의 5가지 조건

첫째, 추출 항목이 업무 기준으로 정의되어 있어야 합니다. 모델이 뽑을 수 있는 항목이 아니라 담당자가 시스템에 입력해야 하는 항목이 기준입니다.

둘째, 서식이 바뀌어도 견뎌야 합니다. 같은 신청서라도 지점과 연도에 따라 배치가 달라지므로, 좌표를 고정하는 방식은 오래가지 못합니다.

셋째, 필기체와 체크박스, 도장이 섞인 문서를 처리할 수 있어야 합니다. 한 카드 금융기관의 검증에서 인쇄체와 필기체의 키값 추출 정확도가 모두 98%로 확인된 것은 이 조건을 만족했다는 뜻입니다.

넷째, 추출한 값의 위치를 되짚을 수 있어야 합니다. 원문 어디에서 나온 값인지 확인할 수 없으면 검수자가 다시 문서를 전부 읽게 됩니다.

다섯째, 검증 규칙이 함께 돌아야 합니다. 날짜의 앞뒤 관계, 금액의 합계, 서류 간 이름 일치처럼 업무가 요구하는 조건은 모델이 아니라 규칙으로 잡습니다.

KIE의 실제 적용 방법

추출 항목 정의가 먼저입니다

프로젝트의 첫 산출물은 모델이 아니라 항목 정의서입니다. 한 은행의 피해구제 업무 자동화에서도 피해구제신청서와 지급정지요청서, 사건사고사실확인원 등 서류별로 어떤 항목을 어떤 형식으로 추출할지 정의하는 작업이 선행되었습니다. 이 문서가 없으면 성능 평가의 기준 자체가 만들어지지 않습니다.

분류와 추출을 분리해서 설계합니다

여러 서류가 하나의 파일로 병합되어 들어오는 환경에서는 문서를 나누고 서식을 판별하는 단계가 먼저 필요합니다. 한 카드 금융기관 사례에서 초기 문서군 46종과 747개의 분류 코드 체계를 먼저 세운 뒤 추출로 넘어간 이유가 여기에 있습니다. 문서 분류 정확도가 97%로 확보된 다음에야 항목 추출이 안정적으로 동작합니다.

검증 규칙을 추출과 함께 돌립니다

추출된 값을 그대로 시스템에 넣으면 오류가 뒤에서 발견됩니다. 값이 나오는 시점에 규칙으로 걸러 두면 담당자에게 넘어가는 건수 자체가 줄어듭니다.

규칙은 세 종류로 나누어 잡습니다. 먼저 형식 검증입니다. 사업자등록번호의 자릿수, 날짜의 형식, 계좌번호의 구분 기호처럼 형태가 정해진 항목을 확인합니다. 다음은 관계 검증입니다. 신청일이 발급일보다 앞서지 않는지, 금액의 합계가 항목별 값의 합과 맞는지를 봅니다. 마지막은 문서 간 검증입니다. 신청서의 대표자명과 증빙서류의 대표자명이 같은지, 계좌번호가 통장 사본과 일치하는지를 대조합니다.

세 번째가 특히 중요합니다. 금융 심사 업무는 문서 한 장으로 끝나지 않고 여러 서류를 맞춰 봐야 한 건이 완결되기 때문입니다. 한 은행의 피해구제 자동화에서는 이 대조를 통해 항목 46건 가운데 1건의 불일치를 자동으로 찾아낸 사례가 확인되었습니다.

추출 항목을 버전으로 관리합니다

항목 정의서는 한 번 만들고 끝나지 않습니다. 서식이 개정되고 업무 규칙이 바뀌면 추출 항목도 따라 바뀝니다. 이때 정의서를 덮어쓰면 무엇이 언제 왜 바뀌었는지가 사라집니다.

실무에서 쓰는 방식은 변경이 생길 때마다 새 버전을 만들고 이전 버전을 남겨 두는 것입니다. 항목이 추가되었는지, 형식 힌트가 바뀌었는지, 하위 항목이 묶였는지를 메모와 함께 기록합니다. 그리고 같은 평가 문서로 이전 버전과 성능을 비교한 뒤 승인 절차를 거쳐 운영에 반영합니다.

이 절차가 있으면 변경이 성능을 떨어뜨렸을 때 곧바로 되돌릴 수 있고, 담당자가 바뀌어도 왜 이렇게 설정했는지가 문서로 남습니다.

국내 환경에서의 KIE

국내 금융과 공공 조직은 망분리 규정을 적용받는 경우가 많아 외부 API 호출이 제한됩니다. 따라서 온프레미스 구축이 가능한지가 기술 검토의 첫 관문이 됩니다. 여기에 더해 한글 워드프로세서 문서와 팩스로 접수된 저화질 스캔본, 관공서 서식 특유의 표 구조를 다뤄야 합니다. 국내 문서로 학습과 검증을 반복한 사업자가 유리한 지점입니다.

자주 묻는 질문