문서 분류 AI를 100건으로 시험했더니 90건을 맞혔다고 가정해 보겠습니다. 화면도 잘 작동하고 시연도 끝났습니다. 이제 같은 기능을 실제 서비스에 넣어 달라고 하면 개발사는 바로 견적을 낼 수 있을까요?

저라면 아직 내지 않습니다. 90%는 시험한 100건에서 나온 결과일 뿐, 매달 들어오는 전체 문서를 같은 조건으로 처리할 수 있다는 뜻은 아니기 때문입니다. 틀린 10건이 어떤 문서였는지, 한 건의 오류가 얼마짜리 문제를 만드는지, 사람이 몇 건을 다시 확인해야 하는지에 따라 개발 범위가 달라집니다.

PoC는 기술이 작동할 가능성을 확인하는 단계입니다. 본개발 견적에는 같은 결과를 실제 업무에서 반복하기 위해 무엇을 더 만들어야 하는지가 들어가야 합니다.

90%보다 먼저 분모를 봅니다

100건을 누가 골랐는지부터 확인해야 합니다. 글자가 선명한 표준 양식만 넣었는지, 실제로 자주 실패하는 손글씨·기울어진 스캔·복수 표·빈칸이 섞였는지에 따라 같은 90%의 의미가 달라집니다.

실제 업무에서는 문서 종류와 거래처가 계속 달라집니다. 월말에는 물량이 몰리고, 처음 보는 양식도 들어옵니다. PoC 표본이 이 분포를 반영하지 못하면 본개발에서 필요한 데이터 정리와 예외 처리 규모를 알 수 없습니다.

시험 세트와 지표를 기록하고 실제 배포 환경과 비슷한 조건에서 성능을 확인해야 합니다.[1] 견적을 위한 평가표에는 평균 정확도 하나보다 다음 항목이 필요합니다.

  • 실제 업무에서 차지하는 문서 유형별 수량
  • 정상 사례뿐 아니라 흐림, 누락, 중복 같은 실패 사례
  • 필드별 성공률과 실패 이유
  • 아직 시험하지 못한 거래처·기간·언어
  • 사람이 정답을 확정한 기준과 검토자

시험하지 않은 범위는 실패가 아니라 미확인입니다. 다만 미확인 범위에 고정 견적을 붙이면 개발사가 위험 비용을 넉넉히 더하거나, 계약 뒤 추가 비용을 요청할 가능성이 커집니다.

틀린 한 건의 무게가 서로 다릅니다

상품 설명의 띄어쓰기를 틀린 것과 계좌번호·금액·수량을 틀린 것은 같은 오류 한 건이 아닙니다. 전자는 사람이 나중에 고쳐도 되지만, 후자는 지급이나 출고 전에 반드시 막아야 합니다.

오류를 영향에 따라 나누면 필요한 기능이 보입니다.

오류의 영향처리 방식본개발에 필요한 항목
문장 표현이 어색함사후 수정 허용수정 화면과 이력
필수 값이 비어 있음담당자 확인 후 진행누락 감지와 검토 대기함
금액·계좌·수량이 의심됨자동 처리를 중단원문 대조, 승인과 알림
시스템에 중복 입력될 수 있음저장 전 차단중복 키와 재시도 규칙

AI 정확도가 같아도 자동 저장을 허용하는 서비스와 모든 결과를 사람이 승인하는 서비스의 개발비는 다릅니다. 중요한 값을 틀렸을 때 어디에서 멈추고 누구에게 보여줄지 결정해야 화면, 권한, 알림과 기록 범위를 계산할 수 있습니다.

사람 검토는 무료 예외 처리가 아닙니다

PoC에서는 담당자 한 명이 결과 100건을 확인해 줄 수 있습니다. 실제 운영에서 한 달에 2만 건이 들어오면 이야기가 달라집니다. 정확도가 90%여도 틀린 2천 건만 정확히 골라낼 수 없다면, 담당자는 2만 건을 다시 봐야 할 수 있습니다.

그래서 저는 AI가 맞힌 비율과 함께 다음 시간을 잽니다.

  • 담당자가 결과 한 건을 확인하는 시간
  • 원문을 다시 찾아 비교하는 시간
  • 오류를 수정하고 업무를 재개하는 시간
  • 담당자가 판단하지 못해 상위 승인자에게 보내는 비율

AI가 확신이 낮은 건을 잘 골라 검토함으로 보내는지도 확인해야 합니다. 사람이 5%만 검토하면 되는지, 사실상 전수 검토가 필요한지에 따라 자동화의 가치와 관리자 화면의 규모가 달라집니다.

월 사용량을 넣어야 운영비와 성능 범위가 나옵니다

PoC는 한 사람이 몇 건씩 천천히 시험하는 경우가 많습니다. 실제 서비스에서는 월말 오전에 수백 건이 몰리거나, 긴 문서 때문에 처리 시간이 늘어날 수 있습니다. 외부 AI API가 실패하면 재시도하면서 비용도 함께 증가합니다.

본개발 견적 전에는 최소·평균·피크 사용량을 나눠 계산해야 합니다.

  • 하루와 한 달의 예상 처리 건수
  • 동시에 들어오는 최대 요청 수
  • 문서 한 건의 평균·최대 길이
  • 허용할 수 있는 처리 시간
  • 실패 시 재시도 횟수와 대체 처리 방식
  • 건당 AI API·저장소·검색 비용

지연과 비용은 PoC에서 뒤로 밀리기 쉽지만 사전 운영 단계에서는 주요 설계 조건입니다.[2][3]

이 숫자가 있어야 개발사는 비동기 처리, 대기열, 캐시, 사용량 제한과 모델 구성을 정할 수 있습니다. 월 500건짜리 내부 도구와 하루 2만 건을 처리하는 서비스는 같은 화면을 보여도 다른 제품입니다.

데모 화면 뒤의 시스템 연동을 분리합니다

PoC에서는 엑셀 파일을 올리고 결과를 내려받는 데 성공하면 충분할 수 있습니다. 본개발에서는 ERP에서 주문을 읽고, 고객 정보를 확인하고, 결과를 저장한 뒤 담당자에게 알려야 할 수 있습니다.

이때는 AI 모델보다 다음 항목이 견적을 크게 바꿉니다.

  • 연동할 시스템에 공식 API가 있는가
  • 읽기와 쓰기 권한을 어떻게 나누는가
  • 고객·계약·가격 데이터의 접근 범위는 어디까지인가
  • 같은 요청이 두 번 들어왔을 때 중복 저장을 어떻게 막는가
  • AI가 틀렸을 때 원래 값으로 되돌릴 수 있는가
  • 누가 어떤 원문을 보고 값을 승인했는지 남길 수 있는가

PoC에서 실제 ERP 쓰기까지 모두 만들 필요는 없습니다. 대신 API 문서와 권한, 표본 응답을 확인해 연동 가능, 추가 협의 필요, 현재 방식으로 불가를 나눠야 합니다.[2]

확인하지 않은 연동을 견적서 한 줄에 ERP 연동 포함이라고 쓰면 양쪽이 서로 다른 범위를 상상합니다.

PoC 결과를 견적 요청서로 다시 씁니다

PoC 보고서가 정확도 90%, 성공에서 끝나면 개발사는 빠진 조건을 다시 조사해야 합니다. 저는 결과를 다음 네 구역으로 나눕니다.

구역기록할 내용견적 처리
확인됨실제 표본에서 검증한 기능과 조건확정 범위에 포함
본개발 필수권한, 검토 화면, 기록, 연동처럼 운영에 필요한 기능별도 작업으로 산정
조건부표본·API·정책 확인 뒤 결정할 항목선택안 또는 범위 견적
제외이번 계약에서 만들지 않을 기능과 데이터계약서에 명시

여기에 실패 유형별 결과, 월 사용량, 사람이 검토할 구간과 연동 시스템을 붙이면 개발사는 화면 수가 아니라 업무를 완료하는 데 필요한 범위를 계산할 수 있습니다.

불확실성이 큰 항목은 억지로 하나의 숫자로 만들지 않는 편이 낫습니다. 예를 들어 ERP API 확인 후 2주, API가 없으면 별도 방식 재협의처럼 전제와 범위를 함께 적습니다. 먼저 짧은 기술 조사로 미확인 항목을 줄인 뒤 본개발 견적을 확정할 수도 있습니다.

PoC 성공은 견적을 낼 수 있는 상태여야 합니다

정확도 90%는 좋은 출발점일 수 있습니다. 그러나 본개발을 결정하려면 어떤 10%가 실패했는지, 실제 물량에서 사람이 얼마나 검토할지, 지연과 건당 비용은 얼마인지, 어느 시스템까지 연결할지 알아야 합니다.

저는 PoC를 잘 작동했습니다로 끝내지 않습니다. 확인한 범위와 확인하지 못한 범위, 이번 계약에서 만들지 않을 범위를 나누고, 치명적인 오류의 중단 조건과 사람의 역할을 정한 뒤, 본개발 필수 항목을 별도로 적습니다.

그 문서가 나오면 개발사는 위험을 숨긴 고정가 대신 전제가 보이는 견적을 낼 수 있습니다. 고객도 무엇을 만들면 실제 업무에 쓸 수 있는지 알고 다음 투자를 결정할 수 있습니다. PoC의 마지막 산출물은 데모 영상이 아니라, 본개발 범위와 가격을 논의할 수 있는 근거여야 합니다.

출처