BMT란 무엇인가: 자사 문서로 솔루션을 검증하는 방법 완전 정리
BMT(Benchmark Test)란, 도입을 검토하는 조직이 자사의 실제 업무 문서와 미리 정한 평가 기준으로 여러 후보 솔루션을 같은 조건에서 처리시켜 성능을 비교하고 도입 여부를 판단하는 검증 절차입니다.
BMT가 필요한 이유
공개된 점수와 우리 문서에서의 점수는 다릅니다.
솔루션 검토 자리에서 가장 흔하게 오가는 숫자가 정확도입니다. 그런데 같은 제품이 어떤 문서에서는 99%를 내고 어떤 문서에서는 80% 초반에 머무릅니다. 실제 검증 사례를 보면, 신고 서식의 표 구조 복원은 99% 이상으로 확인되었지만 다층 헤더와 병합이 겹친 행정 문서에서는 같은 항목이 80% 아래로 내려갔습니다. 문서 유형 분류도 금융 문서군에서 97% 수준이 나온 사례와 공공 문서군에서 89.1%가 나온 사례가 함께 존재합니다.
이 격차는 제품의 우열이 아니라 문서의 성격에서 나옵니다. 그래서 공개된 벤치마크 점수나 제안서에 적힌 정확도만으로 도입을 결정하면, 운영에 들어간 뒤 예상과 다른 결과를 만나게 됩니다. BMT는 이 위험을 도입 전에 옮겨 놓는 절차입니다.
BMT의 정확한 정의: PoC와 무엇이 다른가
BMT와 PoC, 세 가지 축의 차이
첫째, 대상이 다릅니다. BMT는 여러 후보 제품을 대상으로 삼습니다. 같은 문서를 같은 조건으로 던져 성능을 나란히 비교하는 것이 목적입니다. PoC는 하나의 솔루션을 대상으로 삼아 실제 업무 흐름에 붙였을 때 동작하는지를 확인합니다.
둘째, 목표가 다릅니다. BMT의 목표는 선택입니다. 어느 제품이 우리 문서에서 더 나은지를 판단합니다. PoC의 목표는 설계입니다. 업무 규칙과 예외 처리, 시스템 연계를 어떻게 구성할지를 확정합니다.
셋째, 성과지표가 다릅니다. BMT는 문서 유형 분류 정확도, 항목 단위 완전 일치율, 표 구조 유사도처럼 제품 간 비교가 가능한 지표를 씁니다. PoC는 건당 처리 시간과 사람이 손댄 비율, 예외 건 비중처럼 운영 관점의 지표를 씁니다. 실제 금융 사례에서는 BMT 단계에서 완전 일치율 목표를 90%로 잡고 문서 분류와 항목 추출 성능을 측정한 뒤, 이후 단계에서 운영 기준을 확정하는 순서로 진행되었습니다.
두 절차는 대체 관계가 아닙니다. BMT로 후보를 좁히고 PoC로 운영 설계를 확정하는 순서가 일반적입니다. 다만 문서군이 단순하고 후보가 하나로 좁혀져 있다면 두 절차를 합쳐 진행하기도 합니다.
결과를 신뢰할 수 있게 만드는 BMT의 6가지 설계 원칙
실제 진행에 들어가는 BMT의 6가지 설계 원칙
첫째, 평가 문서를 업무 분포에 맞춰 뽑아야 합니다. 잘 나온 문서만 모아 평가하면 도입 후에 점수가 떨어지고, 어려운 문서만 모으면 제품 간 차이가 드러나지 않습니다. 실제 접수 비중을 반영해 문서 종류와 상태를 섞어 구성하십시오. 한 금융 사례에서는 초기 문서군 46종을 정리한 뒤 평가 대상으로 50종을 선정했고, 한 공공 사례에서는 문서 8건에서 평가 요소 302개를 뽑아 측정했습니다.
둘째, 정답셋을 먼저 만들어야 합니다. 어떤 항목의 정답이 무엇인지 사람이 확정해 두지 않으면 점수를 계산할 수 없습니다. 이 작업이 BMT에서 가장 시간이 많이 드는 부분이고, 여기서 대충 넘어가면 이후 모든 비교가 흔들립니다.
셋째, 지표를 미리 정의해야 합니다. 정확도라는 말은 제품마다 다른 계산을 가리킵니다. 완전 일치를 볼지 유사도 기반으로 볼지, 표는 구조 유사도로 볼지, 분류는 어떤 단위로 셀지를 문서로 확정하고 시작하십시오.
넷째, 예외 문서를 반드시 포함해야 합니다. 도장이 표를 침범한 문서, 팩스 헤더가 여러 겹 쌓인 문서, 값이 비어 있어 판단이 필요한 문서를 넣어야 제품 간 차이가 드러납니다. 정상 문서만으로는 대부분의 제품이 비슷한 점수를 냅니다.
다섯째, 조건을 동일하게 맞춰야 합니다. 같은 파일, 같은 해상도, 같은 항목 정의로 진행해야 비교가 성립합니다. 한쪽에만 추출 기준을 세밀하게 잡아 주면 결과는 제품 성능이 아니라 준비 시간의 차이를 보여 주게 됩니다.
여섯째, 처리 환경까지 함께 확인해야 합니다. 정확도가 같아도 내부 설치가 불가능하거나 필요한 가속기 규모가 지나치게 크면 도입할 수 없습니다. 성능 지표와 배포 요건을 같은 표에 놓고 판단하십시오.
BMT의 실제 진행 방법
문서 수집과 항목 정의를 먼저 끝냅니다
BMT의 첫 산출물은 평가 결과가 아니라 문서 목록과 항목 정의서입니다. 어떤 서식을 몇 건 넣을지, 각 서식에서 어떤 항목을 어떤 형식으로 추출할지를 확정해야 비교의 기준이 생깁니다.
이 단계에서 분류 체계도 함께 정리하는 편이 좋습니다. 한 금융 사례에서는 문서군을 정리하면서 747개 규모의 분류 코드 체계를 세운 뒤 추출 검증으로 넘어갔습니다. 분류가 정의되지 않은 상태에서 추출 성능만 재면, 실제 운영에서 발생할 병목을 놓치게 됩니다.
측정과 해석을 분리합니다
측정은 기계적으로 하고 해석은 따로 합니다. 점수가 낮게 나온 항목이 제품의 한계 때문인지, 정답셋의 정의가 모호했기 때문인지, 원본 문서 자체에 근거가 없었기 때문인지를 구분해야 합니다.
실제로 값이 비어 있는 칸이 해당 없음인지 기재 누락인지 스캔 손실인지 문서 안에서 판단할 근거가 없는 경우가 있습니다. 이런 항목을 오답으로 계산하면 제품 평가가 아니라 문서 품질 평가가 됩니다. 판단 불가 항목은 별도로 분류해 두고 운영 규칙으로 처리 방향을 정하는 편이 맞습니다.
국내 환경에서의 BMT
국내 금융과 공공에서 BMT를 진행할 때 가장 먼저 부딪히는 것은 문서를 어디서 처리할 것인가입니다. 망분리 환경에서는 평가용 문서를 외부로 반출할 수 없으므로, 후보 제품이 내부에 임시 설치되어 검증을 진행할 수 있는지를 먼저 확인해야 합니다. 이 조건을 충족하지 못하는 제품은 성능과 무관하게 평가 자체가 불가능합니다.
문서 형식 조건도 함께 봅니다. 한글 워드프로세서 문서와 관공서 서식, 팩스 접수본이 평가 대상에 포함되는지 확인하십시오. 공개된 예시 문서로 측정한 값과 자사 접수함의 문서로 측정한 값은 다르게 나옵니다. BMT의 존재 이유가 바로 그 차이에 있습니다.
자주 묻는 질문
참고는 됩니다. 다만 공개 평가셋과 자사 문서는 구성이 다르므로 순위가 그대로 재현되지 않습니다. 도입 판단은 자사 문서로 측정한 결과로 하시기 바랍니다.
문서군의 다양성에 따라 다릅니다. 서식 50종 규모로 진행한 금융 사례가 있고, 문서 8건에서 평가 요소 302개를 뽑아 진행한 공공 사례가 있습니다. 건수보다 실제 접수 분포를 반영했는지가 중요합니다.
필요합니다. 정답이 확정되지 않으면 점수를 계산할 수 없고 제품 간 비교도 성립하지 않습니다. BMT에서 가장 품이 드는 작업이지만 생략할 수 없습니다.
업무에 따라 다릅니다. 값을 시스템에 입력하는 업무라면 항목 단위 완전 일치율을, 표가 본문인 문서라면 표 구조 유사도를, 접수 자동화라면 문서 유형 분류 정확도를 우선 지표로 두시기 바랍니다.
가능합니다. 후보 제품을 내부에 임시 설치해 진행하는 방식이면 문서를 외부로 반출하지 않고 검증할 수 있습니다.
대개는 그 사이에 한 단계가 더 있습니다. 업무 규칙과 예외 처리, 시스템 연계를 확정하는 검증 단계를 거친 뒤 운영 전환으로 넘어가는 흐름이 일반적입니다.