문서 분류 자동화, AI 구축 전에 정할 업무 범위

안녕하세요. 사랑받는 IT 프로덕트의 첫걸음, 똑똑한개발자입니다.

오늘의 인사이트 요약

• 문서 종류를 구분하는 일과 내용을 추출하는 일은 다릅니다.

• 여러 서류가 합쳐진 파일은 분리 기준부터 정합니다.

• 모르는 문서와 잘못 분류한 문서를 처리할 화면도 필요합니다.

메일이나 공유 폴더로 들어온 서류를 매번 열어 담당자에게 나누다 보면, 문서 분류를 AI에 맡길 수 있을지 고민하게 됩니다. 파일 이름만으로 구분하기 어렵고 거래처마다 양식도 다르다면 본문을 읽고 종류를 판단하는 작업부터 자동화 후보로 살펴볼 수 있습니다.

다만 문서를 분류했다고 업무가 끝나지는 않습니다. 내용을 추출해 시스템에 입력할지, 담당자가 확인하도록 전달할지에 따라 개발 범위가 달라집니다. 오늘은 문서 분류 자동화를 의뢰하기 전에 정할 대상과 처리 범위를 알아보겠습니다.

1. 분류와 후속 작업을 나눠야 합니다

어떤 서류인지 판단하는 일부터 정해야 합니다

문서 분류는 입력받은 파일이나 페이지가 어떤 종류인지 판단하는 작업입니다. 견적서인지 발주서인지 구분하는 것과 그 안의 품목·수량을 읽어내는 것은 다릅니다. 후자는 항목 추출에 해당하며, 추출한 값으로 발주를 등록하는 일에는 별도의 업무 규칙과 시스템 연결이 필요합니다.

견적 요청에 문서 자동 처리라고만 적으면 업체마다 다른 결과를 예상할 수 있습니다. 한쪽은 분류 이름을 보여주는 화면까지, 다른 쪽은 담당자 배정과 시스템 입력까지 포함할 수 있기 때문입니다. 입력 파일과 최종 결과를 한 쌍으로 적어두면 비교할 범위가 명확해집니다. 기존 파일을 이동하는지, 복사본을 만드는지도 함께 정하세요.

예를 들어 보겠습니다.
발주서를 받으면 종류만 표시하고 구매 담당자에게 전달하는 방식과, 품목을 추출해 발주 초안을 만드는 방식은 서로 다른 개발 범위입니다. 문서 종류가 같아도 두 번째 방식에는 항목 검토와 입력 결과 확인이 추가됩니다.

똑똑한개발자팀은 처음부터 모든 서류를 자동 처리하기보다 분류 뒤 이어지는 업무가 분명한 문서부터 고르는 편이 좋다고 생각합니다. 담당자가 실제로 덜 하게 될 일을 확인할 수 있기 때문입니다. 종류가 정해진 뒤 사용할 추출 모델을 연결하는 구성은 Microsoft의 문서 모델 안내에서 구체적으로 살펴보실 수 있습니다.

2. 파일과 문서의 단위를 구분해야 합니다

한 파일에 서류가 몇 개 들어오는지 확인해야 합니다

첨부 파일 하나가 문서 하나라는 전제부터 확인하세요. 여러 장짜리 발주서와 참고 자료를 하나의 PDF로 받기도 하고, 같은 종류의 서류가 연달아 스캔되어 들어오기도 합니다. 파일 전체에 이름 하나를 붙이는 방식으로는 담당자가 처리할 개별 문서를 구분하기 어려울 수 있습니다.

페이지마다 분류하면 해결될 것 같지만, 문서가 여러 페이지로 이어질 때는 어느 페이지까지 한 묶음인지도 알아야 합니다. 앞장에만 제목이 있고 뒤에는 표만 있는 서류라면 문서의 시작과 끝을 잘못 나눌 수 있습니다. 실제 수신 방식에 맞춰 한 파일·페이지별·문서 묶음별 처리 중 필요한 결과를 정해야 합니다.

Microsoft Document Intelligence의 사용자 지정 분류 모델은 파일 전체, 페이지별, 자동 문서 분할 방식을 구분합니다. v4.0의 기본 splitMode는 none이므로, 여러 문서를 자동으로 나누려면 auto 설정이 필요합니다. 문서 분할 설정에서 각 방식이 반환하는 범위를 비교해 보세요.

개발사에 전달할 샘플에도 실제 들어오는 파일 구성을 담는 편이 좋습니다. 깨끗한 단일 서류만 주고 견적을 받았다가 합본 파일까지 처리하려 하면 분리 화면과 검수 항목이 늘어납니다. 비슷한 양식, 스캔 방향이 다른 문서, 경계를 판단하기 어려운 묶음을 따로 표시하면 어디까지 자동 처리할지 논의하기 쉽습니다.

3. 판단이 어려운 문서의 경로를 정해야 합니다

검토 대기와 분류 완료를 구분해야 합니다

처음 정한 종류에 없는 문서도 들어올 수 있습니다. 이런 파일을 기존 분류 중 하나에 억지로 넣으면 잘못된 담당자에게 전달되거나 엉뚱한 추출 작업이 시작됩니다. 검토 대기 상태를 두고 자동 처리에서 제외할 조건을 정하는 이유입니다. 낮은 신뢰도뿐 아니라 처음 보는 문서 형식도 점검 대상으로 삼을 수 있습니다.

분류 모델의 신뢰도 점수는 자동 처리 여부를 판단하는 참고값입니다. 높게 나왔다고 업무 결과가 항상 맞는다고 볼 수는 없습니다. 실제 문서로 정답과 비교한 뒤 어느 경우를 사람이 확인할지 정하세요. Microsoft도 지정한 분류에 속하지 않는 문서가 예상되면 점수 임계값이나 기타 분류를 검토하도록 안내합니다. 다른 모델에도 같은 임계값을 그대로 적용할 수 있는 것은 아닙니다.

수정할 때 되돌릴 업무도 확인해야 합니다

담당자가 분류 이름을 바꿀 때 이미 배정된 업무를 되돌릴지도 정해야 합니다. 잘못 분류한 원본, 수정한 결과, 처리 상태를 함께 볼 수 있어야 후속 작업의 정정 범위를 판단할 수 있습니다. 자동 분류 결과와 최종 확정 결과를 구분해 남기면 다음 개선 때도 원인을 살펴보기 편합니다.

똑똑한개발자팀은 사람이 수정하는 경로까지 구축 범위에 포함하는 것이 중요하다고 봅니다. 분류 화면만 만들면 담당자가 오류를 발견한 뒤 다시 수작업으로 연락하고 파일을 옮길 수 있기 때문입니다. 견적에는 검토 목록, 수정 권한, 담당자 변경, 다시 처리할 작업을 어디까지 포함하는지 적고, 검수할 때도 이 순서대로 직접 처리해 보세요.

문서 업무에 맞는 자동화 범위를 정해야 합니다

서류를 자동으로 나누고 싶어도 어디까지 맡겨야 할지 막막할 수 있습니다. 똑똑한개발자는 업무 분석부터 시스템 개발·운영 개선까지 연결해 AX 프로젝트를 진행합니다. 기존 시스템에 API가 있는지, 문서가 어디로 들어오는지 등 현재 업무 환경에 맞춰 연결 방식을 검토합니다.

처음에는 분류와 담당자 전달까지만 검증하고, 이후 필요한 항목 추출로 범위를 넓힐 수도 있습니다. 현재 문서 업무에 맞는 자동화 범위와 시스템 연결을 고민하고 계신다면 아래 똑똑한개발자 링크로 편하게 이야기 남겨주세요. 감사합니다. :)