AI 자동화 견적은 어떻게 잡아야 할까

AI 자동화 문의가 들어오면 가장 먼저 흔들리는 지점이 견적입니다. "메일 분류 자동화 하나면 얼마예요?"라고 물었을 때, 기능 이름 하나만 듣고 금액을 던지면 거의 항상 범위가 터집니다.

여기서 판단 기준은 기능 개수가 아니라 입력 데이터가 얼마나 지저분한지, 예외 상황이 얼마나 많은지, 실패했을 때 사람이 어디서 잡아줘야 하는지예요. 같은 "자동화"라도 주문 메일 20건 정리와 사람 승인까지 포함된 재고 발주 자동화는 난도가 전혀 다릅니다.

예를 들어 매일 오전 9시에 메일함에서 주문서 PDF를 읽고, 구글 시트에 입력하고, 누락 건은 담당자에게 슬랙으로 알린다는 자동화를 생각해 볼게요. 겉으로는 한 줄이지만, 실제 견적은 메일 포맷 확인, PDF 품질 점검, 입력 필드 매핑, 예외 알림, 수정 라운드, 월간 점검 비용까지 나눠야 맞습니다.

기능보다 범위를 먼저 쪼개야 합니다

자동화 견적은 보통 네 덩어리로 보는 편이 덜 틀어집니다.

덩어리	무엇이 들어가나	빠지면 생기는 문제
발견/설계	현재 업무 흐름 파악, 입력/출력 정의, 예외 상황 정리	만들고 나서 "이 케이스는 왜 안 돼요?"가 폭발합니다.
초기 구축	프롬프트, 도구 연결, 테스트 플로우, 기본 UI	기능은 돌아가는데 실제 업무에는 못 붙습니다.
수정 라운드	사용자 피드백 반영, 규칙 보정, 로그 확인	첫 데모 뒤에 손이 너무 많이 갑니다.
운영/유지	모델 비용, 실패 건 처리, 월간 점검, 권한 관리	설치 후 방치돼서 신뢰를 잃습니다.

표 다음에 꼭 붙여야 할 말이 하나 있어요. 한 번 설치라는 표현은 고객에게는 편하지만 공급자에게는 위험합니다. 자동화는 돌아가기 시작한 뒤에 진짜 예외가 드러나는 경우가 많기 때문입니다.

예시 견적은 이렇게 나누는 편이 낫습니다

아래는 시장 평균이 아니라, 범위를 어떻게 쪼개야 하는지 보여주는 예시 견적입니다.

항목	예시 작업	예시 견적 감각
설계/요건 정리	메일 포맷 4종 분석, 시트 필드 확정, 실패 조건 정의	별도 고정비
1차 구축	메일 읽기, 정보 추출, 시트 입력, 실패 알림	프로젝트 본체 비용
수정 2회	담당자 피드백 반영, 추출 규칙 보정	포함 횟수 명시
월 운영	로그 검수, 토큰 비용, 실패 건 재처리	월 구독 또는 점검 패키지

이렇게 적어 두면 고객도 초기 구축비와 월 운영비를 분리해서 이해합니다. 반대로 전부 한 줄 금액으로 뭉치면, 나중에 수정 횟수와 유지보수 범위에서 계속 다툼이 생깁니다.

모델 비용보다 실패 비용이 더 크게 남을 때가 많습니다

OpenAI 가격 페이지를 보면 모델과 도구 비용은 구조적으로 계산할 수 있습니다. 그런데 실제 외주에서 더 크게 남는 건 종종 토큰 비용이 아니라 실패 처리 비용입니다.

예를 들어 이런 경우죠.

PDF 품질이 들쭉날쭉해서 사람이 다시 봐야 할 때
고객이 말하지 않았던 예외 포맷이 뒤늦게 튀어나올 때
승인 절차를 빼먹어서 잘못된 결과가 바로 반영될 때

그래서 견적에서는 LLM 호출비보다 검수 루프와 승인 지점을 먼저 적는 편이 낫습니다. 모델이 좋아질수록 자동화 범위는 넓어지지만, 실패 비용이 0이 되지는 않습니다.

실제로 많이 틀어지는 장면도 비슷합니다. 첫 미팅에서 "대충 이런 식이면 돼요"라고 넘어갔는데, 막상 착수하고 나니 PDF 형식이 다섯 가지였고, 담당자별 승인 규칙도 달랐고, 실패했을 때 누가 다시 처리할지도 안 정해져 있는 경우가 많아요. 이때 견적이 무너지는 건 모델이 약해서가 아니라, 처음에 어디까지 자동화인지를 문장으로 닫지 않았기 때문입니다.

견적서에 반드시 들어가야 하는 문장

포함되는 입력 채널이 무엇인지
예외 건은 어떤 방식으로 사람에게 넘기는지
수정 라운드가 몇 회까지인지
월 운영에 무엇이 포함되는지

이 네 줄이 없으면 처음엔 싸게 따온 것 같아도 나중에 남는 게 거의 없습니다. 특히 API 비용만 월 과금으로 두고, 로그 확인과 프롬프트 보정은 서비스 범위에 안 써두면 공급자가 계속 무상으로 떠안게 됩니다.

이런 견적은 대체로 위험합니다

위험 신호	왜 문제인가	대안
"자동화 하나 99만 원"처럼 기능만 적힌 경우	입력 구조와 예외가 안 보입니다.	입력/출력/예외 세 줄을 먼저 받기
수정 횟수 미기재	데모 이후 범위가 계속 늘어납니다.	1차, 2차 수정까지만 명시
월 운영비 없음	설치 후 장애 대응이 공중에 뜹니다.	최소 점검 플랜이라도 분리

표 아래 반례도 같이 봐야 합니다. 아주 단순한 내부 자동화는 정말 고정비 한 줄로 끝나는 경우도 있습니다. 다만 그때도 입력 포맷과 실패 처리 범위는 적어 두는 편이 안전합니다.

많이 망하는 실수도 몇 가지가 정해져 있습니다.

샘플 데이터 2~3개만 보고 전체 예외를 다 안다고 가정하기
저장, 발송, 승인까지 한 번에 자동화 범위에 넣기
운영 담당자와 로그 확인 책임자를 정하지 않고 넘기기

이 셋은 초반엔 빨라 보여도, 실제로는 수정비와 무상 대응 시간을 크게 키웁니다.

고객이 "그냥 챗GPT 붙이면 되지 않나요?"라고 물을 때

이 질문이 나오면 설명을 길게 하지 않는 편이 낫습니다. 보통은 아래 순서로 답하면 됩니다.

모델 호출은 한 부분일 뿐이라고 말한다
실제 업무 연결은 데이터 정리와 예외 처리에서 비용이 나온다고 말한다
그래서 구축비와 운영비를 나눠서 본다고 말한다

이렇게 답하면 기술 설명보다 견적 구조를 먼저 이해시키기 좋습니다.

견적 끝에서 자주 나오는 질문

토큰 비용만 계산하면 되지 않나요?

거의 항상 부족합니다. 실제 프로젝트에서는 테스트, 실패 건 검수, 예외 대응 시간이 더 크게 잡히는 경우가 많습니다.

수정 1~2회는 그냥 해주는 게 낫지 않나요?

작은 수정이라면 그럴 수 있습니다. 문제는 수정의 기준을 안 적어두면 작은 수정이 계속 누적된다는 점입니다.

월 운영비를 꼭 받아야 하나요?

자동화가 실제 업무에 붙는 순간부터는 운영이 생깁니다. 비용을 따로 받지 않더라도 범위는 반드시 분리해 둬야 합니다.

숫자로 다시 보는 방법

한 프로젝트에서 남길 월 마진이나 필요한 고객 수를 거꾸로 보려면 목표 금액 계산기에 월 목표 매출과 기간을 넣어 보세요. 자동화 외주는 한 건 얼마보다 월 유지매출이 몇 건에서 만들어지는가를 보는 순간 견적 감각이 달라집니다.