DEEP Ops
한 줄로 하면 문서 AI를 도입한 다음에,
업무가 바뀔 때마다 재개발 없이 담당자가 직접 고치고 검증하는
문서 AI 운영 플랫폼이에요.
한눈에 보기
- DEEP Ops는 문서 AI 운영 플랫폼이에요
- 2026년 9월 2일에 출시했어요
- 법령·양식이 바뀌어도 재개발이 없어요
- 현업이 자연어로 추출 기준을 바꿔요
- 같은 문서로 비교하고 승인 후 배포해요
- MLOps는 모델을, VLM Ops는 업무 기준을 봐요
- 성능 지표는 넷, 핵심은 무개입률이에요
"그거 재작년에 자동화한 거 아니었나요?"
문서 AI를 도입한 담당자라면 한 번쯤 들어 봤을 말이에요.
잘 돌아가던 시스템이 어느 날 항목 하나 앞에서 멈추고, 견적서가 다시 오고,
회의에서 저 질문이 나옵니다.
KDL은 지난 9월 2일에 DEEP Ops를 출시했어요.
💡
문서 AI에는 왜 별도의 운영 플랫폼이 필요할까요?
이 글에서는 잘 돌아가던 문서 AI가 시간이 지나면서 왜 멈추는지,
운영 과정에서 실제로 무엇을 관리해야 하는지, 그리고 DEEP Ops가
이 문제를 어떻게 해결하는지 순서대로 설명해 볼게요.
정확도가 아니라 변경이 문제였어요
저희가 실제로 자주 접하는 문의 중 하나가 이런 경우예요.
타사의 문서 AI를 구축해 2년 가까이 잘 사용해 왔는데, 어느 날 업무 기준이 바뀌면서 문제가 생깁니다.
“고시가 개정돼서 지원 대상 기준일 항목이 추가됐는데, 기존 시스템에서는 이 항목을 못 읽어요.”
처음 구축했을 때는 문제가 없었어요. 당시 정해진 문서와 항목은 잘 처리하고 있었으니까요. 하지만 새 항목이 추가되자 기존 시스템만으로는 대응하기 어려워집니다.
시스템이 멈추는 이유는 정확도가 아니에요.
그 항목을 읽으라고 배운 적이 없는 거죠. 이런 일은 생각보다 자주 생깁니다.
법령·고시가 개정될 때
상품이나 심사 기준이 바뀔 때
거래처가 새 양식으로 서류를 보낼 때
추출 결과의 변경 근거와 적용 시점을 남겨야 할 때
결국 문서 AI를 오래 운영할수록 중요한 건 처음 구축했을 때의 정확도만이 아닙니다.
업무가 바뀌었을 때 얼마나 빠르게 기준을 수정하고, 검증하고, 다시 운영에 반영할 수 있는지가 함께 중요해져요.
항목 하나에 왜 몇 주가 걸릴까요?
기존 OCR 방식에서 추출 항목을 하나 추가하면 이런 순서를 밟아요.
단계 | 하는 일 | 누가 |
|---|---|---|
1 | 바뀐 양식의 실제 문서 수집, 정답 라벨링 | 고객 |
2 | 개발사 요청, 견적, 내부 품의 | 고객 |
3 | 모델 수정과 검증 | 개발사 |
4 | 운영 환경 재배포 | 개발사 |
5 | 그동안 해당 항목 수기 처리 | 현업 |
짧으면 몇 주, 길면 두 달이에요.
이 때, KDL이 주목한 건 기간이 아니라 구조였어요.
도입 성과는 한 번 나오고 끝나는데, 변경 비용은 업무가 바뀔 때마다 반복해서 나가요. 시간이 갈수록 문서 AI가 성과 항목이 아니라 비용 항목으로 보이기 시작합니다.
이건 담당자가 벤더를 잘못 고른 결과가 아니에요.
그 시점의 OCR이 변경이라는 걸 전제하지 않고 설계됐기 때문이에요.
도입 단계에서 뭘 봐야 하는지는 OCR API만 붙이면 자동화일까? 'AI 직원'을 만드는 5가지 도입 기준에 정리해 뒀는데, 이 글은 그 다음 단계 이야기예요.
처음엔 KDL도 재학습으로 풀었어요
솔직히 KDL도 초반에는 같은 방식이었어요.
변경 요청이 오면 데이터를 받아서 다시 학습시키고 다시 배포했죠.
그런데 고객사 프로젝트에서 적용 범위가 넓어지니까 문제가 달라졌어요.
부서마다 필요한 추출 항목이 다르고, 품질 기준이 다르고, 쓰는 프롬프트가 달랐어요. 하나를 바꾸면 다른 데 어떤 영향이 가는지 계속 봐야 했고요.
그때 깨달은 게 있어요. 저희가 관리해야 할 건 모델이 아니었어요.
MLOps가 관리하는 건 모델,
문서 AI에서 바뀌는 건 업무 기준
소프트웨어 업계는 이런 문제를 여러 번 겪었고,
그때마다 운영 체계를 하나씩 만들었어요.
체계 | 관리 대상 | 변경 주체 |
|---|---|---|
DevOps | 코드 | 개발자 |
MLOps | 모델과 학습 데이터 | 머신러닝 엔지니어 |
LLMOps | 프롬프트와 컨텍스트 | AI 엔지니어 |
VLM Ops | 추출 스키마와 업무 기준 | 현업 담당자 |
위에서 아래로 읽으면 관리 대상이 옮겨 가는 게 보여요.
코드에서 모델로, 모델에서 프롬프트로요.
문서 AI에서 실제로 바뀌는 건 모델이 아니에요.
법령이 바뀌고, 심사 기준이 바뀌고, 뽑아야 할 항목이 바뀌어요.
바뀌는 건 업무 기준이에요.
그래서 MLOps만으로는 안 풀려요. MLOps는 훌륭한 체계지만 관리 대상이 모델 파라미터예요. 업무 기준이 바뀌었을 때 MLOps가 내놓는 답은 결국 재학습이에요. 그런데 현업이 원하는 건 "이 항목도 같이 뽑아 주세요" 한 문장이에요.
VLM Ops, 문서 AI를 위한 운영 체계
이 빈칸을 채우려고 KDL이 정의한 게 VLM Ops예요.
시각언어모델을 실제 기업 업무에 배포하고 조정하고 품질을 관리하는 운영 체계예요.
VLM 자체는 아래에서 다뤘어요.
VLM Ops가 자산으로 관리하는 건 네 가지고, 여기에 버전이 붙어요.
모델 — 어떤 VLM을 쓰는가
프롬프트 — 무엇을 어떻게 읽으라고 지시했는가
추출 스키마 — 어떤 항목을 어떤 형식으로 뽑는가
품질 기준 — 어디까지를 통과로 보는가
핵심은 재사용이에요.
한 업무에서 검증이 끝난 조합을 저장해 뒀다가 다른 부서, 다른 업무에 가져다 써요.
현장에서 나온 평가 결과와 검수 피드백은 다시 품질 개선에 들어가고요.
전사 AI 플랫폼 관점에서 보면 이게 왜 필요한지 분명해져요. 기업이 AI 플랫폼을 만들 때 모델 서빙과 데이터 파이프라인까지는 설계하는데, 문서 계층은 비어 있는 경우가 많아요. 문서는 부서마다 양식이 다르고 규정 따라 수시로 바뀌어서, 중앙에서 한 번 만들어 두면 끝나는 자산이 아니거든요.
이 흐름은 저희만 보는 게 아니에요.
전 세계 지능형 문서처리 시장: 올해 39억 달러 → 2033년 297억 달러 전망
국내 공공 문서, hwp에서 hwpx 개방형 형식으로 전환 정책 시작
과기정통부 AI 특화행정서비스 사업 올해 착수
문서를 AI가 쓸 수 있는 형태로 계속 관리해야 하는 시대가 온 거예요. 그런데 체계만 있으면 담당자가 쓸 수 있을까요. 아니에요. 그래서 제품으로 만들었어요.
DEEP Ops, 그 체계를 제품으로
DEEP Ops는 VLM Ops를 실제로 쓸 수 있게 만든 문서 AI 운영 플랫폼이에요.
문서 AI를 도입한 이후에 바뀌는 업무 기준에 맞춰, 고객이 직접 시스템을 수정하고 성능까지 검증할 수 있는 플랫폼이요. 하는 일은 세가지예요.
하는 일 | 어떻게 | 예를 들면 |
|---|---|---|
바꾼다 | 추출 항목과 조건을 자연어로 수정 | "신청서에서 기준일도 같이 뽑아 주세요" |
비교한다 | 바꾸기 전 버전과 바꾼 버전을 같은 문서에 돌려서 결과를 나란히 확인 | 새 항목은 잘 나오는지, 기존 항목은 안 깨졌는지 |
남긴다 | 모든 변경을 버전으로 저장, 문제 생기면 이전 버전으로 복구 | 언제 누가 무엇을 왜 바꿨는지 |
이미 KDL 제품을 쓰고 계신 분들은 DEEP Agent랑 뭐가 다른지 궁금하실 텐데요.
DEEP Agent | DEEP Ops | |
|---|---|---|
역할 | 문서를 읽고 업무를 처리 | 그 문서 AI가 일하는 방식을 바꾸고 |
쓰는 사람 | 업무 담당자 | 운영 담당자 |
한 줄로 | 일을 한다 | 일하는 방식을 바꾼다 |
DEEP Agent : 문서를 읽고 업무를 처리하는 AI 직원
DEEP Ops : 그 AI 직원의 일하는 방식, 검증, 관리
작동은 단순해요. 담당자가 자연어로 추출 기준을 바꾸면 새 버전으로 저장되고, 기존 버전과 같은 문서로 결과를 비교한 뒤, 승인을 거쳐 배포돼요. 단계별 화면 흐름은 출시 안내 글에 정리해 뒀으니 여기서는 그 뒤에 있는 원칙을 말씀드릴게요.
자연어로 바꿔도 승인 없이는 안 나가요
자연어로 바꿀 수 있다고 해서 누구나 운영 중인 시스템을 마음대로 바꾸게 하는 게 이 제품의 목적은 아니에요. 역할이 나뉘어 있어요.
구간 | 누가 |
|---|---|
법령·양식이 바뀌었다는 걸 알아채기 | 고객 조직 |
자연어로 기준 정하기 → 버전 남기기 → 성능 비교 → 승인 절차 | DEEP Ops |
최종 배포 시점 결정 | 고객 조직 |
이 구조에서 제일 크게 달라지는 건 변경 주체예요.
공급사와 AI 개발자가 하던 일을 고객 현업이 직접 해요. 필요한 것도
신규 학습 데이터가 아니라 실제 문서와 추출 기준이면 되고,
데이터가 밖으로 나갈 일도 없어요.
그래서 이렇게 말할 수 있게 됐어요. 바꾸는 횟수에 더 이상 비용이 붙지 않아요.
사전 등록한 양식이 아니어도 읽어요
추출 기준은 필요한 만큼 다시 정의해요
업무 흐름은 필요한 만큼 구성해요
저희는 이 방식이 기존 신규 구축 방식보다
최소 50퍼센트 이상 비용을 줄일 거라고 기대하고 있어요.
운영 성능은 무개입률로 잽니다
여기가 제일 실무적인 부분이에요. 구축할 때 정확도는 계약서에 적혀요. 그런데 운영 중인 성능은 대부분 조직이 안 재요. 뭘 재야 하는지 정한 적이 없거든요.
지표 | 정의 | 답하는 질문 |
|---|---|---|
전체 정확도 | 모든 필드가 정답과 일치한 문서의 비율 | 손 안 대도 되는 문서가 몇 건인가 |
필드 정확도 | 정답과 일치한 필드의 비율 | 흔히 말하는 인식률 |
평균 지연시간 | 문서 한 건 처리에 걸리는 평균 시간 | 업무 시간 안에 끝나는가 |
무개입률 | 사람 검토 없이 끝난 처리 건의 비율 | 실제로 사람 손이 얼마나 줄었는가 |
넷 중에 도입 효과를 제일 정직하게 보여 주는 건 무개입률이에요.
왜냐면요. 필드 정확도 95퍼센트인 시스템이 있다고 해 볼게요. 문서 한 건에 필드가 20개면 한 건마다 평균 한 개가 틀려요. 그러면 담당자는 결국 모든 문서를 열어 봐야 해요. 정확도 95퍼센트인데 무개입률은 0에 가까운 상황이 실제로 생겨요.
문서 AI를 이미 쓰고 계시다면 첫 질문은 이거예요. 우리는 무개입률을 재고 있나요.
지금 쓰는 문서 AI, 무개입률이 몇 퍼센트인지 아시나요?
실제 문서 샘플 기준으로 현재 무개입률을 측정해 드려요.
DEEP Ops가 필요한 이유
숫자만으로는 DEEP Ops가 어디에 필요한지 잘 와닿지 않을 수 있어요.
지금부터 제조 품질 업무를 예로 들어 순서대로 보여 드릴게요.
제조 현장에서 자주 다루는 문서 중 하나가 소재 입고 시 함께 들어오는
시험성적서(CoA)와 검사증명서예요. 협력사마다 양식이 다르고, 인장강도·항복강도·연신율·경도 같은 실측값에 도장, 수기 메모, QR 등이 함께 들어갑니다.
지금은 이래요
검토자가 하는 일 | 방식 |
|---|---|
규격 최소값과 실측값 대조 | 성적서마다 눈으로 |
단위·유효자리 맞추기 | 다시 계산 |
로트 번호, 서명 확인 | 전 항목 전수 검토 |
판정 결과 QMS 입력 | 검토가 끝나야 가능 |
검토가 밀리면 입고가 밀려요.
그런데 이 시간의 대부분은 판단이 아니라 읽고 맞춰 보는 시간이에요.
문서 AI를 도입하면 이렇게 돼요
성적서를 올리면 필요한 항목을 문서 AI가 추출합니다.
강관 검사증명서 한 장을 기준으로 테스트했을 때는 증서번호, 발행일, 규격, 치수, 등급, 열처리, 인장강도, 항복강도, 연신율, 경도 등 29개 필드가 자동으로 잡혔어요.
담당자는 필요한 필드와 추출 기준을 정하면 됩니다.
항목 | 도입 후 |
|---|---|
로트, 강도, 연신율, 경도 등 추출 | 자동 |
규격 최소값과 실측값 대조 | 자동 |
단위 정규화·계산 | 자동 |
로트·히트 번호 누락 확인 | 자동 |
검토자가 확인하는 것 | 예외 항목만 |
QA 검토를 없애는 게 목적은 아니에요.
모든 성적서를 사람이 처음부터 끝까지 보는 대신, 기준값에 근접하거나 단위가 다르거나 값이 누락된 문서만 확인하는 구조로 바꾸는 것이 핵심이에요.
DEEP Ops로 운영하면 여기서 한 번 더 달라져요
규격이 개정되고, 새로운 협력사가 다른 양식의 성적서를 보내고, 고객 요구에 따라 확인해야 할 항목도 추가됩니다.
기존 방식에서는 이런 변화가 생길 때마다 개발과 검증이 다시 필요했습니다.
DEEP Ops에서는 업무 기준 자체를 운영 중에 바꿉니다.
자연어로 기준을 바꿔요.
"인장강도 실측값이 규격 최소값 415MPa 이상이면 합격, 미만이면 불합격으로 표기"처럼 새로운 판정 기준을 추가합니다.변경 내용을 버전으로 남겨요.
규격 개정 반영같은 메모와 함께 새 버전이 만들어지고, 이전 버전도 그대로 보관됩니다.같은 문서로 변경 전후를 비교해요.
기존 버전과 새 버전을 같은 성적서에 적용해 새 항목이 제대로 추출되는지, 기존 항목에는 영향이 없는지 확인합니다.승인한 버전만 운영에 반영해요.
검증이 끝난 버전만 배포되고, 언제 누가 무엇을 바꿨는지도 기록으로 남습니다.
예를 들어 새 버전에서는 인장강도 실측값 471MPa가 기준 415MPa와 비교돼 ‘합격’으로 판정되는지 바로 확인할 수 있어요.
핵심은 새로운 기능 하나를 추가하는 데 있지 않습니다.
규격이나 양식이 바뀔 때마다 다시 개발하는 대신, 담당자가 기준을 수정하고 검증해 운영을 이어갈 수 있다는 것이에요. 제조기록서(BPR), 검사성적서, 설비 점검표처럼 기준값과 실측값을 비교하는 문서라면 같은 방식으로 적용할 수 있습니다.
금융의 심사 기준이 바뀌거나 공공의 행정 기준이 달라질 때도 구조는 같아요.
판정 기준을 필요한 만큼 바꾸고, 비교하고, 검증하는 것. 그게 DEEP Ops가 하는 일입니다.
다른 사례도 있어요
조직 | 업무 | 도입 전 | 도입 후 | 무개입률 |
|---|---|---|---|---|
대형 생명보험사 | 퇴직연금 지급 심사 (월 15,000건, 법정 기한 퇴직일+4일) | 건당 12분 이상, 전수 검산 | 예외 8%만 검토, 검산 92% 감소, 리드타임 66% 단축 | 92% |
금융그룹 해외법인 | 여신 서류 심사 (현지어, 월 18,000건) | 건당 21분 이상 | 예외 11%만 검토 | 89% |
광역자치단체 | 행정 문서 구조화 (생성형 AI 플랫폼) | 문서 내 구조 요소를 개별 확인·구조화 | 구조 요소 302/302 검출, 텍스트 유사도 98.8% | 94% |
행정기관 | 경정청구서 문서 이해 검증 | 문서별 문항을 직접 확인·추출 | 33개 문서, 361개 문항 추출 정확도 95% 이상 | 90% |
공공 투자기관 | 투자기업 사후관리 DB 구축 | 등기부등본을 건별 확인해 필요 정보 구조화 | 법인등기부등본 9,410건 구조화 | 88% |
고객사 보안 정책에 따라 사명은 제외하고 측정 조건과 함께 정리했어요.
광역자치단체 사례는 사람의 검토를 줄이는 업무와는 성격이 조금 달라요. 행정 문서를 생성형 AI가 활용할 수 있는 구조 데이터로 전환한 사례로, 구조 요소 302개를 모두 검출했고 텍스트 유사도는 98.8%, 표 구조 유사도는 79.18%였습니다.
문서마다 목표 지표는 다르지만 공통점은 하나예요.
문서를 한 번 잘 읽는 것에서 끝나는 게 아니라, 실제 업무에 맞춰 계속 운영할 수 있어야 한다는 것.
벤치마크로 확인된 것
운영 체계를 말하기 전에, 그 위에서 돌아가는 모델이 어디까지 검증됐는지도 짚고 갈게요.
시점 | 벤치마크 | 결과 |
|---|---|---|
2026년 3월 | OCRBench v2 영어 부문 | 1위, 68.1점. 2위 Gemini 3 Pro와 4.7점 차이. 아시아 기업 최초 |
2026년 3월 | LlamaIndex ParseBench | 1위, 76.4점. 2위 Gemini 3 Flash 75.0 |
2024년 | Edison Awards 엔지니어링 툴 부문 | Gold Prize. 아시아 최초 |
OCRBench v2는 문서 인식과 추출뿐 아니라 구조 파싱, 계산, 이해, 추론까지 일곱 항목을 함께 보는 벤치마크예요. 저희 모델은 특히 파싱과 계산과 이해 항목에서 격차를 벌렸어요. 글자를 읽는 능력보다 문서 구조를 이해하고 판단하는 능력에서 앞선 결과예요.
ParseBench에서 가장 크게 앞선 항목은 시각적 위치 근거예요. 뽑아낸 값이 원문 어디에 있는지를 얼마나 정확히 짚느냐를 보는 항목인데, 금융이나 공공에서 AI 결과를 받아들일 때 제일 먼저 확인하는 게 바로 이거예요. 결과만 주는 게 아니라 근거를 같이 주느냐요.
우리 조직은 어떤지 8가지로 확인해 보세요
문서 AI를 이미 운영하고 계시다면 답해 보세요.
추출 항목 하나 추가하는 데 며칠 걸리나요
그 변경을 실행하는 건 현업인가요, 개발사인가요
변경 전후 성능을 같은 문서로 비교해 본 적 있나요
지난 1년간 추출 기준을 몇 번 바꿨고 각각 얼마 들었나요
무개입률을 재고 있나요
변경 이력이 내부 감사 요구를 견딜 수 있나요
문제 생겼을 때 이전 버전으로 돌아갈 수 있나요
다른 부서가 같은 문서 AI를 쓰려면 처음부터 다시 구축하나요
답하기 어려운 게 셋 이상이면, 지금 필요한 건 더 정확한 모델이 아니라 운영 체계예요.
셋 이상 걸리셨다면
여덟 항목을 그대로 가져와서 우리 조직 기준으로 같이 점검해 드려요.
자주 묻는 질문
MLOps를 이미 운영하는데 별도로 필요한가요?
관리 대상이 달라요. MLOps는 모델과 학습 데이터를, 문서 AI 운영은 추출 스키마와 업무 기준을 관리해요. 법령이나 서식이 바뀌었을 때 MLOps의 답은 재학습인데, 현업에 필요한 건 추출 기준 한 줄 변경인 경우가 대부분이에요. 대체 관계가 아니라 층위가 다른 관계예요.
기존 MLOps 파이프라인과 같이 쓸 수 있나요?
네. DEEP Ops가 관리하는 건 스키마와 프롬프트와 품질 기준이고, 모델 학습과 서빙은 기존 파이프라인이 맡아요. 다루는 자산이 겹치지 않아서 병행이 자연스러워요.
무개입률은 어떻게 산정하나요?
전체 처리 건수를 분모로, 사람 검토 없이 끝난 건수를 분자로 둬요. 중요한 건 뭘 검토로 볼지 먼저 정하는 거예요. 신뢰도가 낮아 자동 분류된 예외 건, 문서 간 대조에서 불일치가 나온 건, 담당자가 그냥 열어 본 건을 각각 어떻게 셀지요. 기준 없이 나온 무개입률은 비교가 안 돼요.
다른 부서로 확장할 때 처음부터 다시 해야 하나요?
한 업무에서 검증 끝난 모델, 프롬프트, 추출 스키마, 품질 기준을 자산으로 저장해 두고 다른 부서에 재사용하는 게 VLM Ops의 목적이에요. 문서 종류가 완전히 다르면 새 스키마 정의가 필요하지만, 처음 구축할 때보다는 적게 들어요.
변경 이력이 내부 감사 기준을 충족하나요?
스키마 내용이 실제로 바뀔 때만 새 버전이 생기고, 이전 버전은 덮어쓰지 않고 남아요. 뭘 언제 왜 바꿨는지 버전별로 남고요. 조직마다 감사 항목이 다르니 필요한 로그 항목과 보존 기간은 구축할 때 같이 확인하는 게 좋아요.
공공기관 hwp 문서도 되나요?
네. hwp와 hwpx 행정 문서의 구조화는 경기도청과 광역자치단체 생성형 AI 플랫폼 구축에서 검증했어요. 법령과 고시 개정에 맞춰 추출 기준을 바꾸는 운영 방식은 공공에서 특히 자주 필요한 기능이에요.
읽는 AI에서 일하는 AI로, 그리고 계속 일하는 AI로
문서 AI는 글자를 읽는 단계를 지나 업무를 하는 단계로 왔어요. 분류하고, 뽑고, 대조하고, 시스템에 넘기는 일을 AI 직원이 해요.
그런데 직원은 채용으로 끝나지 않아요. 규정이 바뀌면 알려 줘야 하고, 업무가 늘면 설명해 줘야 해요. AI 직원도 똑같아요. 일을 시작하게 만드는 게 도입이고, 기준이 바뀐 뒤에도 계속 제대로 일하게 만드는 게 운영이에요.
우리 조직 문서 AI, 무개입률부터 확인해보세요
실제 문서 샘플로 현재 무개입률을 측정하고, 변경 대응 범위를 표로 정리해 드려요.
