AI 에이전트 도입 견적이 회사마다 다른 가장 큰 이유는 제품 가격이
아니라 ‘범위 정의(스코프)’에 있습니다. 무엇을 연동하고 어디까지
자동화하며 운영을 누가 맡느냐가 금액을 정하죠. 같은 제품이라도 이 범위를
다르게 잡으면 견적은 몇 배로 벌어집니다.

하반기 사업계획을 세우는 자리에서 자주 벌어지는 일이 있습니다. AI
도입을 예산 항목에 넣으려고 업체 몇 곳에서 견적을 받았는데, 같은
요구사항을 줬는데도 금액이 두세 배씩 차이 나는 경우죠.

숫자가 이렇게 벌어지면 예산을 얼마로 잡아야 할지 판단이 서지
않습니다. 어느 견적이 부풀려졌는지, 어느 쪽이 필요한 항목을 뺐는지
가려내야 하는데, 견적서만 봐서는 그 근거가 잘 드러나지 않거든요.

저희가 도입 상담에서 가장 먼저 하는 일도 이 금액 차이의 정체를 밝히는
작업입니다. 대부분은 제품이 비싸고 싼 문제가 아니라, 각 업체가 잡은
범위가 서로 다른 데서 옵니다. 그 범위를 같은 자로 맞추면 견적은 비교
가능한 숫자가 되죠.

AI 에이전트 도입
견적은 왜 회사마다 다른가요?

회사마다 견적이 다른 이유의 대부분은 범위 정의에서 옵니다. 견적서의
총액은 ‘무엇을, 어디까지, 얼마나’ 만들지를 금액으로 옮긴 결과라서, 그 세
물음을 다르게 잡으면 같은 제품도 다른 값이 나오죠.

여기에는 두 층의 차이가 겹쳐 있습니다. 하나는 도입하는 회사마다 처한
상황이 달라서 생기는 차이고, 다른 하나는 같은 회사에 견적을 낸
업체들끼리 범위를 다르게 해석해서 생기는 차이입니다.

앞의 차이는 자연스럽습니다. 연동할 시스템이 다섯 개인 회사와 한 개인
회사의 견적이 같을 수는 없으니까요. 문제는 뒤의 차이죠. 같은 회사에 같은
요구를 받고도 업체마다 값이 갈린다면, 범위를 읽는 기준이 서로 다르다는
신호입니다.

그래서 견적을 이해하려면 총액이 아니라 그 안에 담긴 범위부터 봐야
합니다. 범위를 구성하는 변수 몇 개를 알면, 어느 견적이 무엇을 포함하고
무엇을 뺐는지가 보이기 시작하죠.

견적 편차를 만드는
스코프 변수는 무엇인가요?

견적을 흔드는 범위 변수는 크게 네 가지입니다. 연동할 시스템의 수,
데이터를 정제하는 정도, 업무에 맞추는 커스터마이징 범위, 그리고 도입
이후 운영을 어디까지 맡느냐죠. 이 네 칸이 총액의 대부분을
결정합니다.

네 변수를 하나씩 뜯어 보면, 왜 같은 요구에도 금액이 벌어지는지가
드러납니다. 각 변수가 견적의 어느 칸을 얼마나 밀어 올리는지 아래에서
짚어 보겠습니다.

연동 시스템 수는 견적을
얼마나 흔드나요?

연동 대상 시스템의 수와 종류가 구축비를 가장 크게 움직입니다. ERP
하나만 붙이는 것과 ERP·CRM·그룹웨어·사내 DB를 함께 잇는 것은 개발·검증
공수가 전혀 다르거든요.

같은 ‘연동’이라도 방식에 따라 난이도가 갈립니다. 표준 API가 열려 있는
시스템은 붙이기 쉽지만, 오래된 사내 시스템이나 폐쇄형 ERP는 별도 개발이
필요해 공수가 뜁니다. 하마다랩스가 500개 이상 외부 시스템 연동을
다루면서 확인한 것도, 연동 개수보다 연동 난이도가 금액을 더 흔든다는
점이죠.

그래서 견적을 받을 때는 연동 대상을 목록으로 명시해야 합니다. ‘기존
시스템 연동 포함’이라는 한 줄로 넘어가면, 업체마다 그 범위를 다르게
상상해 총액이 벌어집니다. 시스템 이름과 개수를 못 박아야 같은 기준의
견적이 나오죠.

데이터 정제는 왜 숨은
비용이 되나요?

AI 에이전트는 회사의 데이터를 읽고 움직이는데, 그 데이터가 정리돼
있지 않으면 정제 작업이 먼저 들어갑니다. 흩어진 양식, 중복 기록, 비어
있는 값을 다듬는 이 작업이 견적서에 잘 드러나지 않는 숨은 비용이죠.

데이터 상태는 회사마다 천차만별이라 이 칸의 편차가 큽니다. 이미
표준화된 데이터를 가진 회사는 정제 공수가 적지만, 부서마다 다른 양식을
쓰는 회사는 초기 정리에만 상당한 시간이 들어가거든요.

업체가 데이터 상태를 확인하지 않고 낸 견적은 이 칸을 낙관적으로 비워
둔 경우가 많습니다. 나중에 ‘데이터 정리는 별도’라는 청구가 붙으면 예산이
흔들리죠. 견적 단계에서 데이터 샘플을 보여 주고 정제 범위를 함께 못 박는
편이 안전합니다.

정제 범위를 가늠하는 간단한 방법도 있습니다. 자동화하려는 업무의
데이터를 실제로 몇 건 열어 보는 것이죠. 값이 비어 있거나 양식이 제각각인
비율이 높으면 정제 공수가 크다는 신호라, 견적 전에 이 비율을 업체와
공유해 두면 편차가 줄어듭니다.

커스터마이징 범위는 어디서
갈리나요?

표준 기능을 그대로 쓰느냐, 우리 업무에 맞춰 고치느냐가 커스터마이징
범위입니다. 맞춤 개발이 넓어질수록 설계·개발·검증이 늘어 금액이
오르죠.

여기서 흔한 오해가 ‘많이 맞출수록 좋다’는 생각입니다. 하지만 표준
기능으로 충분한 업무까지 맞춤으로 태우면, 비용만 늘고 유지보수는 더
어려워지거든요. 필요한 곳만 맞추고 나머지는 표준을 쓰는 선 긋기가 견적을
지키는 열쇠입니다.

커스터마이징 범위는 요구사항을 얼마나 구체적으로 적었느냐에
좌우됩니다. 요구가 모호하면 업체는 위험을 감안해 크게 잡거나, 반대로
좁게 잡았다가 나중에 추가 비용을 청구하죠. 요구사항이 뾰족할수록 견적의
편차가 줄어듭니다.

경계를 긋는 요령은 ‘이 업무가 우리만의 방식인가’를 묻는 것입니다.
경쟁사와 다를 게 없는 일반 업무라면 표준 기능이 대개 맞고, 우리 회사의
규칙이 얽힌 업무만 맞춤으로 남기면 되죠. 이 질문 하나로 맞춤 범위의
절반이 정리되기도 합니다.

운영 범위를 견적에 넣었나요,
뺐나요?

도입 이후의 운영을 견적에 포함했는지 여부가 총액을 크게 가릅니다.
구축까지만 잡은 견적과 유지보수·모니터링·개선까지 잡은 견적은 애초에
다른 것을 재고 있는 셈이죠.

운영을 뺀 견적은 당장은 싸 보입니다. 그러나 에이전트는 도입하고
끝나는 도구가 아니라 운영하며 다듬는 시스템이라, 그 손을 내부가 지느냐
업체가 지느냐가 결정될 뿐 사라지지는 않죠. 운영 주체를 정하지 않은
견적은 비용을 뒤로 미뤄 둔 것에 가깝습니다.

그래서 견적을 비교할 때는 운영 포함 여부를 먼저 맞춰야 합니다. 한쪽은
구축만, 다른 쪽은 3년 운영까지 담은 견적을 총액으로만 견주면 착시가
생기거든요. 운영을 어떻게 계산에 넣는지는 3년
총소유비용(TCO) 계산법에서 따로 다룹니다.

스코프는 왜 프로젝트
도중에 자꾸 커지나요?

범위는 정해 두어도 프로젝트가 진행되며 조금씩 넓어지는 경향이
있습니다. ‘이왕 하는 김에 이것도’라는 요청이 쌓이면서 초기 범위를
벗어나는 현상을 범위 변경(scope creep)이라고 부르죠.

이 현상은 특별한 실수가 아니라 흔한 패턴입니다. 프로젝트 관리
협회(PMI)의 조사에서도 범위 변경은 프로젝트 지연과 비용 초과의 단골
원인으로 반복 지적됐고, 조사 대상 프로젝트의 절반가량이 이를 경험한
것으로 나타났거든요.

범위가 커지면 견적은 자연히 흔들립니다. 처음 합의한 금액이 초기 범위
기준이었다면, 늘어난 범위만큼 추가 비용이 붙는 게 당연하죠. 다만 이
증가가 조금씩 스며들어 예산 초과로 드러날 때쯤엔 되돌리기 어렵다는 데
함정이 있습니다.

그래서 초기 범위를 문서로 못 박아 두는 일이 예산 방어의 첫 단추가
됩니다. 무엇이 범위 안이고 무엇이 밖인지 선이 그어져 있으면, 새 요청이
들어와도 ‘이건 추가 범위’라고 판단해 비용과 함께 결정할 수 있죠. 선이
없으면 모든 요청이 공짜처럼 흘러 들어옵니다.

같은 회사인데
왜 업체마다 견적이 다르게 나오나요?

같은 회사에 같은 요구를 줘도 업체마다 값이 갈리는 이유는, 각 업체가
빈 요구사항의 틈을 서로 다르게 메우기 때문입니다. 명세가 비어 있으면
업체는 저마다의 가정으로 그 칸을 채우죠.

예를 들어 ‘연동 포함’이라는 한 줄을 두고, 한 업체는 핵심 시스템 두
개만 떠올리고, 다른 업체는 사내 시스템 전체를 상상합니다. 같은 문장을
읽고도 머릿속 범위가 다르니 금액이 갈리는 겁니다.

가정이 낙관적인 업체일수록 견적은 싸게 나옵니다. 문제는 그 낙관이
계약 뒤에 추가 비용으로 돌아온다는 점이죠. 반대로 위험을 크게 잡은
업체는 비싸 보이지만, 실제로는 뺄 것 없이 정직하게 담았을 수도
있습니다.

그러니 견적의 높낮이만으로 우열을 가리면 위험합니다. 싼 견적이 범위를
뺀 것인지, 비싼 견적이 과잉으로 잡은 것인지는 안을 열어 봐야 알 수 있죠.
저희가 상담에서 견적서를 함께 뜯어 보자고 권하는 이유도 여기에
있습니다.

같은 요구서인데
견적이 세 개로 갈린 가상 사례

말로 설명한 범위 편차를 가상 사례로 그려 보겠습니다. 아래는 이해를
돕기 위한 가상 시나리오이며, 실제 고객사 데이터가 아닙니다.

한 중견 제조사가 ‘재고·발주 업무를 AI 에이전트로 자동화하고 싶다’는
한 줄 요구서를 세 업체에 보냈다고 해 보죠. 요구서에는 연동 대상도,
데이터 상태도, 운영 범위도 자세히 적혀 있지 않았습니다.

첫 업체는 핵심 ERP 한 개만 연동하고 표준 기능 위주로 잡아 가장 낮은
금액을 냈습니다. 데이터 정제와 운영은 ‘고객 제공’과 ‘별도 협의’로 빼
두었죠. 당장은 싸 보이지만, 실제로는 빠진 칸이 많은 견적입니다.

둘째 업체는 사내 시스템 전체 연동과 폭넓은 맞춤 개발을 상상해 가장
높은 금액을 냈습니다. 요구서가 모호하니 위험을 크게 잡은 겁니다.
실제로는 그만큼의 범위가 필요 없을 수도 있어, 과잉으로 부푼 견적일
가능성이 있죠.

셋째 업체는 연동 대상과 데이터 상태를 되물은 뒤, 1차로 두 시스템만
잡고 운영 6개월을 포함한 중간 금액을 냈습니다. 범위를 확인하고 낸 이
견적이 오히려 가장 비교하기 쉬운 기준이 되죠. 세 금액의 차이는 제품값이
아니라 각자가 그린 범위의 차이였습니다.

이 사례가 보여 주는 건 분명합니다. 요구서가 비어 있으면 견적은 업체
수만큼 갈리고, 요구서가 채워지면 세 견적이 같은 자 위에 서죠. 편차를
줄이는 열쇠는 업체가 아니라 우리가 건네는 요구서에 있습니다.

견적서를 받으면
무엇부터 확인해야 하나요?

견적서를 받으면 총액보다 ‘무엇이 포함됐는지’부터 확인해야 합니다.
포함 범위와 제외 항목, 가정과 전제를 먼저 읽어야 그 숫자의 의미가
잡히거든요.

확인할 항목은 몇 개로 추릴 수 있습니다. 아래 목록을 견적서 옆에 두고
하나씩 대조하면, 빠진 칸과 부풀린 칸이 눈에 들어옵니다.

• 연동 대상 — 어떤 시스템을 몇 개, 어떤 방식으로 잇는지
  명시됐는가
• 데이터 정제 — 데이터 정리 작업이 포함인가, 별도 청구인가
• 커스터마이징 — 표준 기능과 맞춤 개발의 경계가 그어져 있는가
• 운영·유지보수 — 도입 후 운영이 몇 개월·어느 범위까지 포함인가
• 전제와 가정 — ‘고객 제공’, ‘별도 협의’ 같은 조건이 어디에 붙어
  있는가

이 중 가장 자주 비어 있는 칸이 전제와 가정입니다. ‘데이터는 고객이
제공’, ‘추가 연동은 별도 협의’ 같은 작은 글씨가 실제로는 예산을
좌우하죠. 이 조건들을 형광펜으로 표시하며 읽는 습관이 나중의 추가 비용을
막습니다.

총액이 비슷한 두 견적이라도 안심하긴 이릅니다. 겉으로 금액이 같아도
한쪽은 운영을 담고 다른 쪽은 커스터마이징을 담았다면, 우리에게 필요한
범위를 채운 쪽이 실제로는 더 나은 견적이거든요. 총액이 아니라 ‘우리
요구와 겹치는 범위’가 판단의 기준이 되죠.

포함 범위가 흐릿한 견적은 다시 요청하는 편이 낫습니다. 구체적인
명세를 다시 받아 두면 계약 뒤 분쟁의 씨앗이 줄고, 무엇보다 업체 간
비교가 가능해집니다.

여러 견적을
같은 기준으로 비교하려면 어떻게 하나요?

여러 견적을 비교하려면 먼저 범위를 같은 자로 맞춰야 합니다. 총액을
나란히 놓기 전에, 각 견적이 담은 범위를 같은 표에 정리해 빈칸을 드러내는
순서죠.

방법은 범위 항목을 세로로 세우고 업체를 가로로 놓아 표를 만드는
것입니다. 각 칸에 포함·제외·별도를 적으면, 어느 업체가 무엇을 뺐는지가
한눈에 보입니다. 아래는 비교 방식을 보여 주기 위한 가상 예시이며, 실제
견적 데이터가 아닙니다.

표로 정리하면 총액의 착시가 걷힙니다. B 업체가 가장 싸 보여도 데이터
정제와 운영이 빠져 있다면, 그 두 칸을 채운 실제 비용은 A·C를 넘어설 수
있죠. 같은 범위로 환산해야 진짜 순위가 나옵니다.

빈칸이 많은 견적은 협상의 출발점이 됩니다. ‘이 칸을 포함하면
얼마인가’를 되물으면, 총액 흥정이 아니라 범위 조정으로 대화가
흐르거든요. 이 방식이 예산을 지키면서도 필요한 범위를 확보하는
길입니다.

환산 작업이 번거롭게 느껴질 수 있지만, 이 한 장이 이후의 모든 협상을
떠받칩니다. 범위표가 있으면 내부 보고도, 업체와의 조율도 같은 문서를
놓고 진행되니 말이 엇갈리지 않죠.

업종과 규모에
따라 어느 스코프 변수가 커지나요?

네 스코프 변수는 어느 회사에나 있지만, 업종과 규모에 따라 유독 크게
부푸는 칸이 다릅니다. 우리 회사에서 어느 칸이 급소인지 알면 견적을 미리
가늠할 수 있죠.

제조·물류는 연동할 시스템이 많아 연동 칸이 가장 먼저 부풉니다.
ERP만이 아니라 생산·창고 시스템까지 맞물려 있어, 연동 대상을 몇 개로
잡느냐가 총액을 크게 가르죠.

고객 응대가 많은 유통·서비스는 운영 칸이 급소입니다. 도입 자체보다
매일 쏟아지는 문의를 에이전트가 처리하며 다듬는 운영이 길게 이어져,
운영을 포함했는지가 견적을 좌우하거든요.

규제가 강한 업종은 커스터마이징 칸이 커집니다. 데이터 보관·접근 통제
같은 규정을 맞추려면 표준 기능만으로는 부족해 맞춤 개발이 늘죠. 이런
조직은 온프레미스 여부까지 범위에 넣어 견적을 받는 편이 정확합니다.

규모가 작을수록 급소 칸은 하나로 좁혀집니다. 시스템이 단순해 대개
한두 변수만 관리하면 되죠. 그래서 소규모 도입은 급소 칸 하나를 정확히
정의하는 것만으로도 견적 편차를 크게 줄일 수 있습니다.

예산을 지키려면 범위를
어떻게 좁히나요?

예산이 정해져 있다면 범위를 전부 담기보다, 효과가 큰 업무부터 좁혀
시작하는 편이 낫습니다. 범위를 한 번에 넓히면 구축비가 부풀고 정착이
늦어져 예산을 넘기기 쉽거든요.

좁히는 기준은 ‘반복이 많고 규칙이 뚜렷한 업무’입니다. 이런 업무는
자동화 효과가 빨리 드러나 예산 대비 성과를 보여 주기 좋죠. 반대로 예외가
많고 판단이 필요한 업무는 뒤로 미뤄 단계로 넓히는 편이 안전합니다.

단계로 나누면 견적도 단계로 받을 수 있습니다. 1차 범위의 성과를
확인한 뒤 2차 범위를 결정하면, 큰 예산을 한 번에 걸지 않고도 도입을
이어갈 수 있죠. 이 접근은 예산 승인 자리에서도 저항이 적습니다.

좁게 시작하되, 나중에 넓힐 것을 처음부터 염두에 두는 편이 낫습니다.
확장을 가정해 초기 구조를 잡으면, 2차에서 다시 짓는 낭비 없이 붙이기만
하면 되거든요. 1차에서 두 시스템만 연동하더라도 나중에 붙일 시스템을
미리 가정해 두는 식이죠.

이 관점은 초기 견적에도 반영됩니다. 확장 여지를 열어 둔 설계는 1차
구축비가 조금 더 들 수 있지만, 2차·3차 확장 비용을 낮춰 3년 총비용에서는
오히려 유리한 경우가 많습니다. 그래서 견적을 받을 때 ‘지금 범위’와 ‘확장
시 범위’를 나눠 물어 두면 예산 지도가 한결 또렷해지죠.

범위를 예산 항목으로 옮기는 절차가 필요하시면 하반기 IT
예산 편성 절차를 참고하시면 도움이 됩니다. 범위 정의가 곧 예산의
뼈대라서, 둘을 함께 설계하면 승인 과정이 매끄러워지죠.

범위 편차를 예산
근거로 바꾸려면 어떻게 하나요?

범위별로 정리한 견적표는 그대로 예산 근거 자료가 됩니다. 하반기
사업계획에서 ‘AI 도입에 얼마’를 적어 낼 때, 총액 하나가 아니라 범위별
금액과 그 근거를 함께 제시하면 승인이 수월해지죠.

경영진이 예산에서 확인하는 것은 숫자 자체보다 그 숫자의 근거입니다.
‘왜 이 금액인가’에 ‘이 범위를 담았기 때문’이라고 답할 수 있으면, 삭감
논의가 부결이 아니라 범위 조정으로 흐르거든요. 범위표가 그 답의 재료가
됩니다.

예산을 범위 단계로 쪼개 두면 승인권자에게 선택지를 줄 수도 있습니다.
1차 필수 범위는 얼마, 2차 확장 범위는 얼마로 나눠 제시하면, 전액이
아니라 단계별로 결재할 수 있죠. 이 방식이 큰 예산을 한 번에 통과시키는
부담을 덜어 줍니다.

예산 문서에 범위 근거를 붙이는 방법은 앞서 소개한 예산 편성 절차와
이어집니다. 핵심은 하나죠. 범위를 먼저 정하고 그 위에 금액을 얹어야,
예산이 흔들려도 어느 범위를 조정할지 답이 나온다는 것입니다.

너무 싸거나
너무 비싼 견적, 어떻게 읽어야 하나요?

가격이 극단으로 치우친 견적은 범위 신호로 읽어야 합니다. 너무 싼
견적은 무언가 빠졌다는 신호고, 너무 비싼 견적은 필요 이상으로 넓게
잡았다는 신호일 때가 많거든요.

치우친 견적에서 확인할 위험 신호는 몇 가지로 정리됩니다.

• 지나치게 낮은 총액 — 데이터 정제·운영·연동 난이도를 비워 둔 경우가
  많다
• 항목 없는 뭉뚱그린 금액 — ‘일체 포함’처럼 범위가 안 보이는 견적은
  사후 청구 위험
• 과도한 커스터마이징 — 표준으로 될 업무까지 맞춤으로 잡아 금액이 부푼
  경우
• 무기한 운영 포함 — 실제로는 범위가 불명확해 나중에 축소되는
  경우

위험 신호가 보인다고 그 업체를 바로 배제할 일은 아닙니다. 오히려 그
칸을 근거로 질문하면 진짜 범위가 드러나죠. ‘이 금액에 데이터 정제가
포함인가요’라는 한 마디가 견적의 실체를 여는 열쇠입니다.

견적의 높낮이가 성과를 담보하지는 않는다는 점도 기억할 대목입니다.
비싼 견적이 반드시 좋은 결과로 이어지지 않고, 싼 견적이 반드시 부실한
것도 아니죠. 결국 범위와 근거가 맞물리는지가 판단의 축입니다.

계약 뒤 범위가
바뀌면 비용은 어떻게 관리하나요?

도입을 하다 보면 범위가 바뀌는 일이 생깁니다. 이때 비용이 새지
않으려면, 범위 변경을 그때그때 말로 처리하지 말고 절차로 다루는 장치를
마련해야 하죠.

가장 흔한 장치가 변경 관리 조항입니다. 초기 범위를 벗어나는 요청이
생기면 그 영향과 추가 비용을 문서로 정리해 승인받고 진행하는 규칙이죠.
이 규칙이 있으면 범위 변경이 조용한 예산 초과로 번지지 않습니다.

변경을 전부 막자는 뜻은 아닙니다. 운영을 하다 보면 더 나은 범위가
보이기 마련이고, 그런 변경은 오히려 효과를 키우죠. 관건은 변경 자체가
아니라, 변경의 비용과 효과를 눈에 보이게 결정하는 데 있습니다.

계약 단계에서 변경 절차를 미리 정해 두면 나중이 편합니다. 추가 범위의
단가 기준, 승인 라인, 반영 방식을 계약서에 한 문단으로 넣어 두면, 변경이
생겨도 다툼 없이 처리되거든요. 저희가 계약 전에 이 조항을 함께 점검하는
이유도 예산을 끝까지 지키기 위해서입니다.

요구사항을
어떻게 적어야 견적 편차가 줄어드나요?

견적 편차를 가장 크게 줄이는 방법은 요구사항을 구체적으로 적는
것입니다. 업체가 상상으로 채우던 칸을 우리가 먼저 채우면, 견적은 같은
전제 위에서 나오죠.

요구사항이라고 해서 기술 문서일 이유는 없습니다. 우리 업무를 잘 아는
담당자가 평범한 문장으로 적어도 충분하죠. 관건은 형식이 아니라, 앞서 본
네 변수를 빠짐없이 담았느냐에 있습니다.

• 자동화 대상 업무 — 어떤 업무를 하루·월 몇 건 처리하는지
• 연동 시스템 — 이름·개수·연동 방식(표준 API 유무)
• 데이터 상태 — 어디에, 어떤 형태로, 얼마나 정리돼 있는지
• 맞춤 범위 — 표준으로 될 부분과 반드시 우리 방식이어야 하는 부분
• 운영 방식 — 도입 후 운영을 내부가 지는지 업체에 맡기는지
• 예산 상한과 일정 — 얼마 안에, 언제까지 필요한지

예산 상한을 적는 것을 꺼리는 경우가 많은데, 오히려 밝히는 편이
낫습니다. 상한을 알면 업체가 그 안에서 우선순위를 잡아 범위를 제안하니,
예산 밖 견적으로 서로 시간을 버리지 않게 되죠.

명세가 준비되면 상담의 질도 달라집니다. 빈손으로 시작한 상담보다,
업무와 시스템 목록을 들고 온 상담이 훨씬 빠르게 범위와 금액으로
정리되거든요. 저희가 도입 문의를 받을 때 현재 업무와 시스템을 먼저
여쭙는 까닭도 여기에 있습니다.

예산 확정 전에 범위를
어떻게 합의하나요?

예산을 확정하기 전에 도입 범위를 문서로 합의해 두면 견적의 편차가
크게 줄어듭니다. 요구사항과 포함 범위를 정리한 한 장이 있으면, 모든
업체가 같은 기준으로 견적을 내거든요.

합의 문서에 담을 최소 항목은 앞서 본 네 변수입니다. 연동 대상 목록,
데이터 상태와 정제 범위, 맞춤과 표준의 경계, 운영 포함 범위를 적으면
업체가 상상으로 채울 칸이 사라지죠.

이 문서는 완벽할 이유가 없습니다. 초안 수준이라도 범위를 적어 업체와
함께 다듬으면, 오히려 우리가 놓친 항목을 업체 경험으로 채울 수 있거든요.
관건은 범위를 말이 아니라 글로 고정하는 일입니다.

합의된 범위는 계약서의 기준이 됩니다. 나중에 ‘이건 범위 밖’이라는
다툼이 생겨도, 문서에 적힌 범위로 돌아가 판단할 수 있죠. 범위 합의는
예산을 지키는 장치이자 분쟁을 줄이는 장치입니다.

한 번 만들어 둔 합의 문서는 다음 도입에도 재활용됩니다. 2차·3차
프로젝트에서 범위 항목만 갈아 끼우면 되니, 매번 백지에서 시작하지 않아도
되죠. 범위를 문서로 남기는 습관이 쌓일수록 견적을 받고 비교하는 일이
빨라집니다.

어떤 범위부터 담아야 예산 안에서 효과를 낼지 함께 정리하고 싶으시면
도입 문의로 현재 시스템
환경과 자동화하고 싶은 업무를 보내 주세요. 범위 정의부터 견적 비교
기준까지 같이 맞춰 드립니다.

자주 묻는 질문

견적을 요청하기 전에 무엇을 준비하면 편차가
줄어드나요?

연동 대상 시스템 목록, 자동화하려는 업무와 처리량, 데이터의 대략적
상태를 정리해 함께 전달하면 편차가 줄어듭니다. 업체가 상상으로 채우던
칸을 실제 정보로 메우게 되니, 견적이 같은 기준 위에서 나오죠. 요구가
구체적일수록 나중의 추가 비용도 함께 줄어듭니다.

견적서에 ‘별도 협의’라고 적힌 항목은 어떻게 다뤄야
하나요?

‘별도 협의’는 대개 그 항목이 아직 총액에 안 들어갔다는 표시입니다.
예산을 잡을 때는 이 항목들의 대략적 상한을 미리 물어 두는 편이 안전하죠.
협의로 미뤄 둔 칸이 많은 견적일수록, 계약 뒤 실제 금액이 올라갈 여지가
큽니다.

소규모 도입인데도 범위 정의를 문서로 만들 필요가
있나요?

규모가 작을수록 오히려 한 장짜리 범위 문서가 값을 합니다. 항목이 적어
금방 정리되고, 그 한 장이 업체 간 비교와 계약 기준을 동시에 해 주거든요.
큰 표가 아니라 네 변수만 적어도 편차를 크게 줄일 수 있습니다.

POC(파일럿)를 먼저 하면 견적 편차를 줄일 수
있나요?

작은 POC로 연동 난이도와 데이터 상태를 실측하면, 본도입 견적의 가장
흔들리는 칸이 단단해집니다. 가정으로 잡던 공수를 실제 숫자로 바꾸니 업체
간 편차도 함께 좁혀지죠. 예산을 크게 걸기 전에 불확실성을 줄이는
방법입니다.

업체가 제시한 범위가 우리 회사에 과한지 어떻게
판단하나요?

표준 기능으로 충분한 업무까지 맞춤 개발로 잡혀 있는지 확인하면
됩니다. 당장 필요하지 않은 연동이나 예외 처리가 초기 범위에 들어가
있다면, 그 항목을 뒤 단계로 미룰 수 있는지 물어보세요. 과한 범위는
단계로 나누는 것만으로도 초기 금액이 내려갑니다.

견적 비교에서 가격 외에 무엇을 함께 봐야 하나요?

운영 지원의 범위, 연동 경험, 데이터 보안 방식을 함께 봐야 합니다.
같은 금액이라도 운영을 함께 지느냐, 우리 업종의 시스템을 다뤄 봤느냐에
따라 도입 이후의 부담이 달라지거든요. 가격은 여러 판단 축 가운데 하나일
뿐입니다.

참고 자료

• PMI(프로젝트 관리 협회), “Pulse of the Profession” — 범위 변경(scope
  creep)이 프로젝트 지연·비용 초과의 흔한 원인으로 반복 보고되며, 조사
  대상 프로젝트의 절반가량이 범위 변경을 경험한 것으로 발표: https://www.pmi.org/
• 가트너 IT 용어집(Gartner IT Glossary), “Total Cost of Ownership
  (TCO)” — 도입 비용을 구축뿐 아니라 운영·기간까지 포함해 종합적으로
  평가하는 개념(운영 범위 포함 여부가 견적 비교의 핵심임을 뒷받침): https://www.gartner.com/en/information-technology/glossary/total-cost-of-ownership-tco
• 하마다랩스 자체 도입 상담 관찰(2026년, 세일즈): 동일 요구사항에도
  업체별 견적이 두세 배 벌어지는 주원인이 범위 해석 차이라는 반복 패턴 —
  익명 집계, 특정 고객 사례 아님
• 하마다랩스 플랫폼·회사 소개(500개 이상 외부 시스템 연동·온프레미스
  배포 지원): https://www.hamadalabs.com/platform
  · https://www.hamadalabs.com/about

작성자

김명선 — 하마다랩스 윈디플로 세일즈 매니저. AI 에이전트 도입 비용·ROI
산정, 구독과 구축의 비용 비교, 운영 단계의 숨은 비용, 계약·SLA 점검을
실제 구매 의사결정 기준으로 다룹니다. 범위를 먼저 정의해 예산 초과를
막는 데 초점을 둡니다. 회사 소개: https://www.hamadalabs.com/