"고객 문의를 AI로 자동화하고 싶다"고 여러 곳에 연락하면 견적이 놀랄 만큼 벌어집니다. 몇백만 원짜리 제안과 몇억 원짜리 제안이 같은 요청에 대해 나옵니다. 둘 중 하나가 틀린 게 아닙니다. 업체가 보고 있는 일의 크기가 다릅니다.
참고로 위시켓이 2024년 2분기부터 1년간 플랫폼에 의뢰된 AI 프로젝트를 분석한 자료에서는 평균 비용이 3,090만 원, 평균 개발 기간이 77일이었습니다(전자신문 보도). 평균일 뿐이고, 실제 견적은 이보다 훨씬 넓게 퍼집니다.
견적이 벌어지는 이유: 업체 유형이 다르다
AI 도입을 맡는 곳은 크게 네 부류입니다. 같은 요청을 받아도 각자 자기가 하는 일의 단위로 바꿔서 견적을 냅니다.
| 유형 | 견적에 들어가는 일 | 기간 | 맞는 경우 |
|---|---|---|---|
| 컨설팅 · 진단형 | 업무 인터뷰, 전사 과제 발굴, 로드맵, 우선순위 | 수개월 | 어디서부터 할지 회사 차원에서 정해야 할 때 |
| 구축형(SI) | 요구사항 정의, 시스템 설계, 개발, 통합 테스트 | 수개월 | 여러 시스템을 묶는 큰 프로젝트 |
| 구독형(SaaS) | 만들어진 도구의 월 이용료와 설정 | 수일~수주 | 업무가 도구의 기본 기능에 맞을 때 |
| 기능 단위 개발형 | 정해진 기능 하나를 기존 서비스에 연결 | 수일~수주 | 할 일이 분명하고 연결할 시스템이 있을 때 |
어느 유형이 맞는지는 우리 쪽에서 범위가 얼마나 정해져 있느냐에 달렸습니다. 범위가 정해지지 않은 채 연락하면 컨설팅형은 진단부터 하자고 하고, 기능 단위 개발형은 가장 작은 범위로 가정합니다. 그래서 견적이 열 배씩 벌어집니다.
요청서에 없으면 업체가 가정한다
업체는 모르는 부분을 가정으로 채우고, 가정이 불확실할수록 기간과 금액에 여유를 붙입니다. 요청서에 무엇이 빠졌을 때 견적이 어떻게 움직이는지 정리하면 이렇습니다.
| 요청서에 빠진 것 | 업체의 가정 | 견적에 미치는 영향 |
|---|---|---|
| 하루 처리 건수 | 많을 수도 있다 | 서버 · AI 이용료를 넉넉하게 잡는다 |
| 실제 문의 예시 | 유형이 다양할 것이다 | 분류 · 학습 작업을 크게 잡는다 |
| 연결할 시스템과 접근 방법 | 연결 방법을 새로 만들어야 할 수도 있다 | 연동 개발을 별도로 잡는다 |
| 예외 처리 기준 | 담당자 인터뷰가 필요하다 | 진단 기간을 넣는다 |
| 틀렸을 때 영향 | 정확도를 아주 높여야 한다 | 검증 · 평가 작업을 크게 잡는다 |
| 성공 기준 | 끝이 정해지지 않았다 | 수정 반복분을 넣는다 |
반대로 이 내용이 요청서에 있으면 업체들이 같은 일을 보고 견적을 냅니다. 금액이 다르더라도 무엇 때문에 다른지 비교할 수 있게 됩니다.
요청서에 넣을 여덟 가지
1. 자동화할 업무를 한 문장으로
"고객센터 AI 도입"은 범위가 끝없이 늘어납니다. "로그인한 고객이 배송 상태를 물으면 주문 시스템에서 찾아 답한다"처럼 누가, 무엇을 물으면, 무엇을 보고, 어떻게 답하는지를 한 문장으로 씁니다.
2. 지금 처리하는 순서와 건수
담당자가 지금 이 일을 어떤 순서로 하는지 3~5단계로 적고, 하루 또는 한 달 건수를 적습니다. 대략이라도 괜찮습니다. 건수는 AI 이용료와 서버 비용을 계산하는 기준이 됩니다.
3. 실제 요청 예시 10건
가장 중요한 자료입니다. 실제로 들어온 문의 · 주문 · 서류를 10건 정도 모읍니다. 이름과 연락처는 가립니다. 쉬운 것만 고르지 말고 애매했던 것을 꼭 섞습니다. 업체가 이걸 보면 AI가 할 수 있는 범위를 바로 판단합니다.
4. 연결할 시스템과 접근 방법
AI가 참고해야 할 정보가 어디에 있는지 적습니다. 쇼핑몰 솔루션 이름, 예약 프로그램 이름, 자체 관리자 화면인지 엑셀인지. 다른 프로그램이 정보를 가져갈 방법(API)이 있는지 모르면 "모름"이라고 적어도 됩니다. 모른다는 것도 정보입니다.
5. 예외 처리 기준
"이런 경우엔 사람이 처리한다"는 기준을 적습니다. 환불 요청, 단체 예약, 불만 문의처럼 AI에게 맡기지 않을 경우를 정해 두면, 업체는 그 부분을 사람에게 넘기는 구조로 설계하고 정확도에 들어가는 비용을 줄일 수 있습니다.
6. 틀렸을 때 생기는 일
AI가 틀리면 무슨 일이 생기는지 적습니다. "잘못된 배송 날짜를 안내하면 고객이 다시 문의한다" 정도와 "잘못 입력하면 세금 신고가 틀어진다"는 필요한 검증 수준이 다릅니다. 영향이 큰 일은 사람이 확인한 뒤 확정하는 구조로 시작하면 비용과 위험이 같이 줄어듭니다.
7. 성공 기준
무엇이 좋아지면 성공인지 숫자로 적습니다. "문의부터 답변까지 걸리는 시간", "사람에게 넘어가는 비율", "한 건 처리 시간" 같은 것입니다. 지금 값을 모르면 도입 전에 일주일만 재 두자고 적어도 충분합니다.
8. 예산 범위, 일정, 하지 않을 것
예산 범위와 원하는 시작 시기를 적습니다. 그리고 이번에 하지 않을 것을 적습니다. "이번에는 배송 조회만, 환불은 다음 단계"처럼 쓰면 업체가 범위를 부풀리지 않습니다.
그대로 복사해 쓰는 양식
[AI 도입 견적 요청서]
1. 자동화할 업무
- (누가) ______ 이(가) (무엇을 물으면/보내면) ______ ,
(무엇을 보고) ______ (어떻게 처리) ______ 한다.
2. 지금 처리 순서와 건수
- 순서: ① ______ ② ______ ③ ______
- 건수: 하루 약 ___ 건 / 한 달 약 ___ 건
- 한 건 처리 시간: 약 ___ 분 (모르면 "모름")
3. 실제 요청 예시: 첨부 ___ 건 (개인정보 가림, 애매했던 건 포함)
4. 연결할 시스템
- 정보가 있는 곳: ______ (솔루션 이름 / 자체 개발 / 엑셀)
- 외부 연결 방법(API): 있음 / 없음 / 모름
5. 사람이 처리할 예외
- ______ , ______ , ______
6. 틀렸을 때 영향
- ______
7. 성공 기준(재는 숫자)
- ______ 을(를) ______ 에서 ______ 로
8. 예산 · 일정 · 이번에 하지 않을 것
- 예산 범위: ______ / 시작 희망: ______
- 이번에 하지 않을 것: ______
받은 견적을 비교할 때
요청서를 같은 내용으로 보냈다면 견적서에서 다음 세 가지를 비교합니다.
- 사람이 확인하는 구간이 어디인지. 처음부터 전부 자동으로 하겠다는 제안은 검증 비용이 숨어 있거나, 위험이 고객 쪽에 남아 있습니다.
- 정확도를 어떻게 재는지. 실제 예시로 만든 평가 기준이 있는지 봅니다. 없으면 "좋아졌다"를 판단할 방법이 없습니다. AI 기능의 견적과 기간이 왜 정확도 목표에 따라 달라지는지는 AI 기능 견적은 왜 자꾸 어긋날까에 정리했습니다.
- 출시 뒤 운영비. AI 이용료, 서버, 수정 요청을 매달 어떻게 받는지 확인합니다. 개발비가 싸도 운영비 구조가 불분명하면 1년 합계는 더 커질 수 있습니다.
요청서를 쓰다가 3번(실제 예시)이나 4번(연결할 시스템)에서 막힌다면, 지금은 AI보다 업무 기록을 먼저 정리할 단계일 수 있습니다. AX 시작 전 10분 자가진단으로 먼저 확인해 보세요.