고객 문의를 분류하는 AI를 외주로 만든다고 가정해 보겠습니다. PoC에서는 실제 문의 100건 중 90건을 맞혔습니다. 이제 발주자는 이 결과를 보고 본계약을 할지 결정해야 합니다.

본개발을 시작하기 전에 견적을 받는 것은 당연합니다. 다만 PoC의 90%를 본계약서에 그대로 옮겨 적는 것은 다른 문제입니다. PoC는 정해진 데이터에서 가능성을 확인한 결과이고, 본서비스에는 처음 보는 문의와 새 상품, 바뀐 정책이 계속 들어오기 때문입니다.

그래서 PoC와 본계약은 같은 성공률을 사는 계약이 아닙니다. PoC는 계속 투자해도 되는지 판단할 근거를 사고, 본계약은 그 근거를 제품으로 만들 범위와 기간, 중간 산출물과 운영 방법을 정하는 계약에 가깝습니다.

PoC 견적과 본계약 견적은 답하는 질문이 다릅니다

PoC 견적은 작은 실험의 경계를 정합니다. 어떤 데이터를 몇 건 시험할지, 얼마 동안 개선할지, 무엇을 성공으로 볼지, 마지막에 어떤 자료를 받을지 합의합니다. 정확도를 가능한 수준까지 끌어올리는 동시에 어디에서 실패하는지 찾는 단계입니다.

PoC가 끝나면 시연 화면만 남아서는 부족합니다. 평가에 쓴 데이터와 기준, 실패 유형, 처리 시간과 비용, 아직 확인하지 못한 범위가 함께 나와야 합니다.[1] 그래야 발주자가 진행·방향 전환·종료 중 하나를 근거를 갖고 고를 수 있습니다.

본계약 견적은 그다음 질문에 답합니다. 실제 사용자가 쓸 화면, 기존 시스템 연동, 권한과 기록, 사람의 검토, 배포와 운영을 어디까지 만들 것인지 가격과 기간으로 바꿉니다. 흐름을 짧게 쓰면 다음과 같습니다.

PoC 견적 → PoC 결과 → 본계약 견적·계약 → 단계별 개발

일정상 두 견적을 먼저 받아야 한다면 본계약 가격에 PoC 통과를 전제로 한 범위와 결과에 따라 다시 산정할 항목을 나눠 적을 수 있습니다. 중요한 것은 견적을 미루는 일이 아니라, 아직 확인하지 않은 위험을 확정 범위인 것처럼 숨기지 않는 일입니다.

90%는 조건을 붙여야 계약 문장이 됩니다

PoC의 90%에는 분모가 있습니다. 어느 기간의 문의를 골랐는지, 새 상품과 오탈자·복합 질문이 들어갔는지, 누가 정답을 정했는지에 따라 같은 숫자의 의미가 달라집니다.

본계약에서도 수치를 전혀 정할 수 없다는 뜻은 아닙니다. 합의한 평가 세트와 측정 방법에서는 분류 정확도 90% 이상 같은 인수 기준을 둘 수 있습니다. 대신 아직 들어오지 않은 모든 문의에서 같은 수치가 계속 유지된다고 약속하기는 어렵습니다. 배포 전 시험은 통제된 환경에서 이뤄지고, 실제 운영에는 동적으로 바뀌는 입력과 예상하지 못한 출력이 생기므로 배포 뒤 측정이 필요합니다.[2]

틀린 한 건의 무게도 다릅니다. 일반 문의의 분류를 놓친 것과 환불·결제 문의를 잘못 자동 처리한 것은 같은 오류 한 건이 아닙니다. 계약의 성능 조건에는 평균 정확도와 함께 다음 항목이 들어가야 합니다.

  • 평가할 데이터의 기간·주제·언어와 제외 범위
  • 금액·계정·권한처럼 틀리면 안 되는 항목의 별도 기준
  • 확신이 낮거나 처음 보는 입력을 사람에게 보내는 조건
  • 운영 중 성능을 다시 재는 주기와 개선 범위

사람의 검토 시간까지 재야 자동화 범위가 보입니다

예를 들어 PoC는 100건으로 했지만 실제 업무에는 월 2만 건이 들어올 수 있습니다. 정확도가 90%여도 틀린 2천 건만 정확히 골라낼 수 없다면 담당자는 2만 건을 다시 봐야 할 수 있습니다. 이 경우 숫자는 높아도 자동화 효과는 작습니다.

그래서 저는 AI가 맞힌 비율과 함께 다음 시간을 재는 걸 추천합니다.

  • 결과 한 건을 확인하는 시간
  • 원문을 다시 찾아 비교하는 시간
  • 오류를 고치고 업무를 재개하는 시간
  • 담당자가 판단하지 못해 상위 승인자의 답을 기다리는 시간

이 시간을 PoC에서 재면 본계약에 필요한 검토 화면과 인원, 자동 처리 범위를 계산할 수 있습니다. 90% 자동화라는 표현보다 80%는 자동 처리하고 20%는 1분 안에 검토한다는 조건이 제품과 견적을 훨씬 구체적으로 만듭니다.

본계약은 중간 산출물과 선택 지점으로 나눕니다

AI 프로젝트의 불확실성을 계약서의 한 문장으로 없앨 수는 없습니다. 대신 본계약을 기간과 산출물로 나눌 수 있습니다.

예를 들어 첫 단계에서는 실제 데이터 연결과 평가 세트를 만들고, 다음 단계에서는 검토 화면과 업무 시스템 연동을 붙입니다. 마지막 단계에서는 사전 운영 환경에서 성능·비용·복구 절차를 확인합니다. 각 단계마다 다음 산출물, 인수 기준, 대금, 다음 단계 진행 여부를 함께 정합니다.

중간 결과가 기준에 못 미칠 때의 처리도 시작 전에 적어야 합니다. 종료 조건과 정산 방식, 소스 코드, 데이터 구조, 프롬프트·모델 설정, 평가 세트와 결과, 설치·운영 문서를 어디까지 넘길지 정합니다. 그러면 발주자는 결과를 보고 같은 개발사와 계속할지, 다른 개발사를 찾을지, 인하우스로 가져갈지 선택할 수 있습니다. 기간을 제한한 단계, 산출물에 연결한 마일스톤, 종료와 인수인계를 미리 두는 방식은 애자일 계약에서 쓰는 위험 관리 패턴입니다.[3]

이 구조에서 본계약 견적은 이미 존재합니다. 다만 한 번에 모든 돈과 판단을 잠그지 않고, 확인 가능한 결과가 나오는 지점마다 다음 투자를 결정합니다.

애매한 성공은 고칠 수 있는 구조로 다룹니다

문의 주제와 문서 양식은 계속 바뀝니다. 기존 기반 모델의 새 버전이 나오거나 외부 API 정책이 달라질 수도 있습니다. 미래의 변화를 모두 맞히겠다는 약속보다, 변화를 발견하고 반영할 수 있는 구조가 필요합니다.

  • 프롬프트·모델·평가 세트의 버전을 함께 기록합니다.
  • 새 주제와 실패 사례를 평가 세트에 추가할 수 있게 합니다.
  • 확신이 낮은 결과는 자동 실행하지 않고 검토함으로 보냅니다.
  • 분류, 검색, 검토, 업무 시스템 연동을 나눠 한 부분씩 바꿀 수 있게 합니다.
  • 운영 결과를 보고 유지보수 범위와 다음 프로젝트를 다시 결정합니다.

저라면 이 항목을 정확도 보완 한 줄로 견적서에 넣지 않습니다. 무엇을 측정하고, 어느 부분을 바꾸며, 변경 뒤 어떤 시험을 통과해야 하는지까지 작업 단위로 나눕니다. 그래야 유지보수가 끝없는 튜닝이 아니라 결과를 확인할 수 있는 개발이 됩니다.

외주 개발사가 약속할 수 있는 경계를 봅니다

이 글이 다루는 AI 외주는 기존의 범용 기반 모델을 API나 관리형 서비스로 연결해 업무 제품을 만드는 프로젝트입니다. 기반 모델 자체를 처음부터 학습하는 사업은 필요한 데이터·컴퓨팅·연구 범위가 달라 별도 프로젝트로 봐야 합니다.

기존 모델을 쓰는 개발사가 직접 통제할 수 있는 것은 미래의 모든 답이 아닙니다. 어떤 데이터를 연결할지, 결과를 어떻게 평가할지, 위험한 답을 어디서 멈출지, 사람의 수정 내용을 어떻게 반영할지, 다른 시스템과 안전하게 연동할지가 개발 범위입니다.

PoC의 90%는 본계약의 보증서가 아닙니다. 그렇다고 의미 없는 숫자도 아닙니다. 그 수치가 나온 조건과 실패를 풀어 쓰면 본계약의 범위, 단계별 인수 기준, 중단 조건과 유지보수 계획을 정할 수 있습니다.

발주자가 PoC 뒤에 받아야 할 것은 성공했습니다라는 보고가 아닙니다. 지금 계약해도 되는 범위와 아직 약속할 수 없는 범위, 다음 판단을 위해 넘겨받을 산출물이 분명한 본계약 견적입니다.

출처