AI OCR 온프레미스 도입 전 확인할 7가지｜서버·GPU부터 운영까지

기업 내 OCR 도입을 알아보다 보면 자료를 외부로 내보낼 수 없는 규정 때문에 회사 안 서버에 직접 설치하는 방식(온프레미스)을 먼저 검토하게 되는 경우가 있습니다. 그런데 막상 안내를 받아 보면 제품 기능 설명은 비슷한데 준비해야 할 것은 공급사마다 다르게 이야기해서, 무엇을 기준으로 비교해야 할지가 잘 잡히지 않습니다. 이 글에서는 온프레미스로 OCR 솔루션을 도입할 때 도입 전에 정해 두면 좋은 항목을 계산 장비부터 운영 담당까지 순서대로 정리했습니다.

온프레미스 비교가 유독 어려운 이유

같은 제품을 두고도 어떤 곳은 장비부터 이야기하고 어떤 곳은 라이선스부터 이야기하다 보니, 표를 만들어 놓고도 칸이 잘 맞지 않는 경험을 하셨을 수 있습니다. 이렇게 되는 데는 배포 방식마다 준비물이 다르다는 사정이 있어서, 먼저 세 가지 방식이 각각 무엇을 요구하는지부터 나란히 놓고 보겠습니다.

클라우드 방식은 계정을 받으면 시작할 수 있어서 검토할 항목이 대체로 계약 조건과 자료 취급 범위에 모입니다. 반면 회사 안 서버에 설치하는 방식은 여기에 장비와 설치 환경, 운영 담당까지 더해지기 때문에, 비교 대상이 제품에서 우리 조직의 준비 상태로 넓어집니다.

표를 보시면 세 방식의 차이가 성능이 아니라 준비물에 있다는 점이 드러나는데, 그래서 도입 검토도 제품 기능을 견주기보다 아래 일곱 가지를 먼저 정리하는 편이 빠릅니다.

도입 전 확인할 7가지

아래 항목은 순서대로 확인하시는 편이 좋은데, 앞쪽에서 답이 정해지면 뒤쪽 선택지가 함께 좁아지기 때문입니다. 항목마다 무엇을 정해야 하는지와 정하지 않고 넘어갔을 때 어디에서 걸리는지를 함께 적었습니다.

1. 계산 장비 — 글자만 훑지 않고 문서를 통째로 보는 VLM(비전 언어 모델) 방식은 한 장을 처리하는 계산량이 커지는 쪽입니다. AI 계산을 빠르게 처리하는 장치인 GPU(그래픽 처리 장치)가 필요한 구성인지부터 확인합니다.

2. 처리량 기준 — 하루 몇 장을 몇 시간 안에 끝내야 하는지에서 역산하고, 월말에 몰리는 정산 문서처럼 평소와 피크가 다른 업무라면 피크를 기준으로 잡습니다.

3. 설치 환경 — 서버실 상면과 랙 공간, 전력과 발열을 미리 확인해 두지 않으면 장비가 들어와도 자리를 잡지 못해 일정이 밀립니다.

4. 업데이트 경로 — 외부 인터넷과 끊어 둔 망(폐쇄망)이라면 모델과 소프트웨어 갱신 파일을 어떤 절차로 반입하는지, 승인 주기가 어떻게 되는지를 함께 봅니다.

5. 운영 담당 — 장애가 났을 때 전산실이 보는지 공급사가 보는지, 원격 접속을 어디까지 허용할지를 정보보호 담당자와 미리 정해 둡니다.

6. 자료가 오가는 범위 — 원본 문서 이미지, 추출된 값, 사람이 확인하는 화면, 처리 기록, 학습 사용 여부 다섯 갈래로 나눠 각각 어디에 머무는지 확인합니다.

7. 늘어날 때와 되돌릴 때 — 문서 종류가 추가되면 장비를 더 붙여야 하는지, 나중에 혼합 방식으로 옮길 수 있는지를 계약 전에 확인해 둡니다.

이 가운데 세 번째와 다섯 번째는 제품을 고르는 문제가 아니라 조직 안에서 정해야 하는 문제라, 공급사를 바꿔도 그대로 남습니다. 그리고 온프레미스는 문서를 올린 날 바로 시작할 수 있는 클라우드와 달리 장비 준비와 설치 일정이 앞에 붙기 때문에, 시작 시점이 뒤로 밀린다는 점도 계획에 함께 반영해 두시는 편이 좋습니다.

AI OCR 온프레미스에 GPU가 꼭 필요한가요?

확인 사항 가운데 검토 초기에 가장 자주 막히는 항목이 계산 장비라, 이 절에서 조금 더 풀어 보겠습니다. 필요 여부를 한 마디로 잘라 말하기보다 어떤 경우에 영향이 커지고 어떤 경우에 덜한지를 나눠 보는 편이 판단에 도움이 됩니다.

문서를 통째로 보는 방식일수록 계산 장비의 영향이 커지므로, 필요한지 여부보다 처리량 기준으로 검토하시는 편이 정확합니다.

글자 영역을 찾아 문자로 바꾸는 방식은 상대적으로 가벼운 계산으로도 돌아가지만, 문서 한 장을 통째로 보고 항목과 값을 함께 판단하는 방식은 한 장에 드는 계산이 늘어납니다. 그래서 같은 제품이라도 하루 수백 장을 다루는 경우와 수만 장을 다루는 경우에 권장되는 구성이 달라집니다.

공급사에 물어보실 때는 GPU가 필요한지를 예와 아니오로 묻기보다 처리량을 맞추려면 어떤 구성이 필요한지를 물어보시는 편이 낫습니다. GPU 없이 도는 구성이 있는지, 있다면 같은 문서를 처리할 때 시간이 어떻게 달라지는지도 함께 확인하시면 비교가 됩니다. 과금이 장비 기준인지 처리량 기준인지도 이때 확인해 두면 나중에 증설할 때 계산이 쉬워집니다.

공급사에 확인할 질문

앞의 항목을 우리 상황에 맞춰 정리하고 나면 공급사에 보낼 질문이 자연스럽게 만들어지는데, 질문이 구체적일수록 돌아오는 답도 비교 가능한 형태가 됩니다. 아래는 업종을 가리지 않고 공통으로 쓰이는 질문들입니다.

1. 예상 처리량 기준으로 권장하는 구성은 무엇이며, 그 기준은 어떤 조건에서 산정한 것인지

2. 외부와 끊어 둔 망에서 모델과 소프트웨어를 갱신하는 절차는 어떻게 되는지

3. 장애가 발생했을 때 대응 방식과 원격 접속 범위는 어디까지인지

4. 원본 문서 이미지와 처리 기록은 어디에 얼마나 남는지

5. 담당자가 확인 목록에서 고친 내용이 다음 문서에 반영되는 구조인지

6. 문서 종류가 늘어날 때 추가로 필요한 작업은 무엇인지

특히 5번 질문은 운영 부담과 바로 연결되는데, 확인한 결과가 다음 처리에 반영되는 액티브 러닝 방식이라면 담당자가 같은 오류를 반복해서 고치지 않아도 되기 때문입니다.

PoC 설계에서 빠뜨리기 쉬운 것

검토가 어느 정도 좁혀지면 실제 문서로 시험해 보게 되는데, 이때 조건을 어떻게 잡느냐에 따라 결과가 크게 달라집니다. 실제 운영과 가까운 조건을 만드는 것이 목적이므로, 아래 네 가지는 빠뜨리지 않으시는 편이 좋습니다.

1. 문서 종류를 실제만큼 섞습니다 — 거래명세서 한 종류로만 시험하면 서식이 여러 갈래인 상황이 드러나지 않으므로, 손해사정서나 진료비 세부산정내역서처럼 구조가 다른 문서를 함께 넣습니다.

2. 품질이 나쁜 문서를 일부러 넣습니다 — 도장이 글자 위에 겹쳐 찍힌 계약서, 팩스로 들어와 흐릿해진 스캔본, 칸이 합쳐진 표를 넣어야 확인 목록으로 넘어가는 비율을 가늠할 수 있습니다.

3. 처리량은 피크 기준으로 잡습니다 — 평소 물량으로만 시험하면 월말에 문서가 몰릴 때 무슨 일이 생기는지가 확인되지 않습니다.

4. 사람이 확인하는 동선까지 넣습니다 — 정산팀이나 보험심사팀 담당자가 확인 목록을 열어 고치는 과정까지 포함해야 실제 운영 시간이 나옵니다.

이렇게 설계하면 뽑아야 하는 항목이 공급가액인지 상병코드인지에 따라 결과가 달라지는 지점까지 함께 보이기 때문에, 도입한 뒤에 조건을 다시 맞추는 일이 줄어듭니다.

확인한 내용을 도입 계획으로 옮기기

여기까지 정리하고 나면 남는 일은 우리 조직이 어느 항목에서 막히는지를 문서로 적어 두는 것입니다. 같은 내용을 공급사마다 반복해서 설명하지 않아도 되고, 받은 답을 나란히 놓고 비교할 수 있게 됩니다.

배포 방식과 별개로 자주 확인하게 되는 것이 시작 시점입니다. 서식을 미리 등록해 두어야 하는 제품은 문서 종류마다 준비 기간이 따로 붙지만, 샘플 문서를 보고 추출 항목을 먼저 만들어 주는 AI 위자드 방식이라면 그 기간이 줄어듭니다. 페이퍼스고 AI도 회사 안 서버에 설치하는 방식을 지원하며, 추출한 값은 시스템끼리 자동으로 주고받는 통로인 API로 ERP나 RPA에 그대로 넘길 수 있습니다.