처음 만나서 바로 견적을 드리지 않는 이유 — 진단이 먼저인 이유

상담 요청을 받을 때 가장 자주 듣는 말이 있습니다. "먼저 견적부터 알 수 있을까요?" 자연스러운 요청입니다. 예산 범위를 먼저 확인하고 진행 여부를 결정하고 싶은 것입니다. 특히 IT 프로젝트나 개발 외주 경험이 있는 분들이 많이 묻습니다. 이전에 비용이 예상보다 크게 나온 적이 있거나, 처음 들은 금액과 최종 청구 금액이 달랐던 경험이 있어서입니다.

그런데 저는 이 요청에 바로 견적을 드리지 않습니다. 대신 "30분 진단을 먼저 하자"고 합니다.

처음에는 이 방식이 불편하게 느껴지는 분도 있습니다. "왜 견적도 안 내주고 시간부터 내야 하나"라는 느낌입니다. 또 "우리 상황이 특수해서 진단보다 먼저 예산 확인이 필요하다"는 분도 있습니다. 그 불편함이 이해됩니다. 그래서 왜 이 순서를 고수하는지, 이것이 고객에게도 왜 더 유리한지를 솔직하게 설명하겠습니다. 결론부터 말하면, 범위 없이 나온 견적은 아무도 믿을 수 없는 숫자입니다. 그 숫자를 기반으로 예산 계획을 세우면, 나중에 달라진 숫자가 훨씬 더 큰 불편함이 됩니다.

범위 없이 견적을 내면 생기는 일

"업무 자동화 견적을 알고 싶다"는 요청만으로는 범위를 알 수 없습니다. 무엇을 자동화하는지, 데이터가 어디에 있는지, 출력이 어떤 형태여야 하는지, 기존 시스템과 어떻게 연결해야 하는지 — 이 중 하나라도 불명확하면 금액을 말할 근거가 없습니다.

이것은 자동화 외주만의 문제가 아닙니다. IT 프로젝트 전반의 구조적인 문제입니다. PMI(미국 프로젝트관리협회)의 연구에 따르면, IT 프로젝트의 52%가 스코프 크립(초기 범위를 초과한 요구사항 추가)을 경험하며, 이로 인한 평균 예산 초과율은 27%에 달합니다. 35%의 외주 프로젝트가 스코프 크립으로 인해 20~30%의 예산 초과를 경험한다는 분석도 있습니다.

국내 상황도 다르지 않습니다. 동일한 요건서를 기반으로 받은 개발 외주 견적이 최대 10배 이상 차이나는 경우가 전체 외주 프로젝트의 60% 이상이라는 조사 결과가 있습니다. 견적 차이가 큰 이유 중 하나가 "범위를 어떻게 해석하느냐"의 차이입니다. 고객이 "기본 기능"이라고 생각하는 것과 개발사가 "기본 기능"이라고 생각하는 것이 다를 수 있습니다. 이 해석 차이가 나중에 추가 견적 요청이 되거나 분쟁이 됩니다.

분쟁이 생기는 이유는 대부분 금액이 아니라 범위 때문입니다. 처음부터 범위를 확정하지 않은 채로 금액만 정하고 시작하면, 이후에 서로의 해석이 달랐다는 것을 작업 중간에 확인하게 됩니다. 그 시점에는 이미 비용과 시간이 들어간 이후입니다.

범위가 불확실한 상태에서 견적을 내면 두 가지 선택지가 있습니다. 하나는 범위를 넓게 잡아 높은 금액을 제시하는 것이고, 다른 하나는 낮은 금액을 제시하되 나중에 범위가 확대되면 추가 견적을 청구하는 것입니다. 둘 다 고객에게 좋지 않습니다. 전자는 실제로 필요한 것보다 더 많은 비용을 내는 것이고, 후자는 시작할 때 몰랐던 비용이 나중에 생기는 것입니다. 후자의 방식이 특히 문제입니다. 처음 견적 금액이 전부라고 기대했는데 나중에 추가 청구가 오면, 고객 입장에서 신뢰가 깨집니다.

자동화 프로젝트에서 이 문제는 더 두드러집니다. "자동화"라는 단어 자체가 광범위합니다. 견적서 발행을 자동화한다고 했을 때, 고객사 내부 시스템에서 데이터를 가져와 발행까지 완전 자동화하는 것과, 기존 엑셀에 내용을 입력하면 PDF가 만들어지는 반자동화는 복잡도가 완전히 다릅니다. 같은 단어를 쓰지만 의미하는 것이 다릅니다. 이 차이를 진단 없이 견적 단계에서 확인하는 것은 불가능에 가깝습니다.

진단에서 실제로 확인하는 것들

30분 무료 진단에서 확인하는 것은 네 가지입니다.

어떤 업무인가입니다. "자동화하고 싶다"는 요청이 실제로 어떤 작업인지를 직접 파악합니다. 같은 "보고서 자동화"라도, 데이터가 어디에 있고 보고서가 어떤 형식이어야 하느냐에 따라 난이도가 완전히 달라집니다. 이것은 설명만으로는 한계가 있고, 실제 업무를 보거나 화면을 공유해야 파악이 됩니다.

반복성과 규칙성입니다. 자동화는 규칙이 정해져 있고 반복되는 업무에 효과가 큽니다. 매번 판단이 달라지는 업무는 자동화가 어렵습니다. "이 업무가 자동화 가능한가"의 핵심 판단 기준이 여기에 있습니다. 진단에서 30분 동안 이 기준을 확인합니다.

데이터 상태입니다. 자동화의 재료는 데이터입니다. 그 데이터가 어디에 어떤 형태로 있는지, 정제가 필요한지, 기존 시스템과의 연결이 가능한지를 확인합니다. 엑셀 파일이 한 폴더에 규칙적으로 쌓이는 환경과, 여러 사람이 각자 다른 폴더에 다른 형식으로 저장하는 환경은 자동화 접근 방식이 완전히 달라집니다.

기대치와 현실의 간극입니다. 자동화로 기대하는 결과와 실제로 구현 가능한 결과 사이의 차이를 진단에서 먼저 확인합니다. 가트너의 2025년 보고서에 따르면, 기업 AI 프로젝트의 약 60%가 개념 증명(PoC) 단계에서 중단됩니다. 기대와 현실 사이의 간극을 미리 좁히지 않으면 프로젝트는 중간에 멈출 가능성이 높습니다. 진단에서 이 간극을 확인하고 조정하는 것이 이후 프로젝트의 방향을 결정합니다.

이 네 가지를 30분 안에 파악하면, 범위를 특정할 수 있습니다. 범위가 특정되면 견적을 낼 수 있습니다.

진단은 처음 만나서 상대 업무를 이해하는 과정이기도 합니다. 상담자 입장에서는 어떤 회사가 어떤 방식으로 일하는지, 사용하는 도구가 무엇인지, 담당자가 어떤 사람인지를 파악하는 시간입니다. 이 정보가 구축 방향에 영향을 줍니다. 예를 들어 담당자가 엑셀을 능숙하게 다루는 사람이라면, 새 도구보다 엑셀 기반으로 자동화를 연결하는 것이 인수인계가 훨씬 쉽습니다. 이 판단은 담당자와 직접 대화해봐야 알 수 있습니다.

진단 후에 "해볼 수 있다"고 판단된 경우에도, 즉시 구축으로 넘어가지 않습니다. 범위를 문서로 정리하고, 고객이 확인하고 확정하는 과정을 거칩니다. 이 단계에서 "이것도 포함이 되는가"라는 질문이 나오면, 포함 여부를 명확히 합니다. 이 과정이 계약 전에 이루어지기 때문에, 나중에 "그때 말했잖아요"나 "저는 포함인 줄 알았어요" 같은 상황이 생기지 않습니다.

실제 사례에서 확인한 것 — 진단이 달랐다면 어떻게 됐을까

보험 보장분석표 자동화 사례를 예로 들겠습니다. 보험 보장분석표 자동화 사례에서 설계사분이 처음 표현한 것은 "보장분석표 작성을 줄이고 싶다"는 것이었습니다. 범위만 놓고 보면 광범위합니다. 새 프로그램을 도입해야 하는 것인지, 기존 방식을 바꿔야 하는 것인지, 어떤 수준의 자동화가 필요한지가 불분명합니다.

진단에서 확인한 것은 훨씬 구체적이었습니다. 작업의 핵심 병목은 보험사별로 다른 형식의 담보 정보를 자체 스프레드시트 양식에 맞게 매핑하고 입력하는 과정이었습니다. 새로운 시스템이나 플랫폼이 필요한 것이 아니라, 기존에 쓰던 스프레드시트 구조에 맞게 입력 과정만 자동화하면 됐습니다. 새 툴을 배울 필요가 없었고, 기존 양식을 바꿀 필요도 없었습니다.

이 판단이 없었다면 어떻게 됐을까요. "보장분석 자동화"라는 큰 범위를 잡고 시작했을 것입니다. 새 시스템을 만들거나, 기존 스프레드시트를 바꾸는 방향으로 갔을 가능성이 있습니다. 불필요한 기능이 포함됐을 것이고, 결과물의 규모와 비용이 달라졌을 것입니다. 진단에서 범위를 좁혔기 때문에, 실제로 필요한 것에만 집중한 구축이 됐습니다. 결과는 1~3시간 걸리던 작업이 10분으로 줄었습니다.

또 다른 사례가 있습니다. 업무 지시 스프레드시트 자동화 사례에서 고객이 처음 표현한 것은 "업무 지시 관리를 어떻게든 해결하고 싶다"는 것이었습니다. 새 툴을 도입해야 하는 것인지, 프로그램을 만들어야 하는 것인지가 불분명한 요청이었습니다. 진단에서 확인한 결과, 새 툴을 도입할 필요가 없었습니다. 이미 쓰던 스프레드시트에 ChatGPT와 Claude를 연결해 지시사항이 자동으로 기록·정리되는 흐름을 만드는 것으로 해결됐습니다.

두 사례 모두, 처음 요청만 보면 범위가 모호했습니다. 진단에서 실제 병목을 찾아 범위를 좁혔기 때문에 명확한 구축이 가능했습니다. 그리고 두 경우 모두 기존에 쓰던 도구와 방식을 최대한 유지하는 방향이 가장 적합했습니다. 이것은 진단 없이는 알 수 없는 정보입니다.

진단에서 얻은 정보는 구축 방향에만 영향을 주는 것이 아닙니다. 인수인계 방식과 구축 이후 운영 방법에도 영향을 줍니다. 담당자가 어떤 수준의 기술 이해도를 가지고 있는지, 어떤 방식으로 시스템을 배우는 것이 편한지를 진단에서 파악합니다. 이 정보를 바탕으로 구축 후 인수인계 방법과 설명 수준을 조정합니다. 같은 시스템도 담당자에 따라 인수인계 방식이 달라져야 합니다.

진단에서 "안 됩니다"가 나오는 경우

진단이 항상 구축으로 이어지는 것은 아닙니다. 진단 결과 "이 방식으로는 안 됩니다" 또는 "자동화보다 다른 방법이 더 낫습니다"가 나오는 경우도 있습니다.

데이터가 너무 비정형적인 경우입니다. 매번 내용과 판단이 완전히 다른 업무는 규칙을 잡을 수 없어서 자동화가 어렵습니다. AI가 발전하면서 비정형 데이터 처리 범위가 넓어졌지만, 그래도 매번 다른 상황 판단이 필요한 업무는 자동화보다 사람이 더 잘합니다.

업무 빈도가 낮은 경우입니다. 1년에 한두 번 하는 작업이라면 자동화 구축 비용이 절감 효과보다 클 수 있습니다. 자동화는 반복 빈도가 높을수록 투자 회수가 빠릅니다.

현재 방식보다 더 효율적인 수동 방법이 있는 경우입니다. 가끔 작업 절차를 조금만 바꾸거나, 기존 도구의 기능을 활용하는 것만으로도 충분한 경우가 있습니다. 이 경우 구축 없이 간단한 조언으로 마무리되기도 합니다.

이런 경우에도 진단은 의미가 있습니다. "이 업무는 안 된다"를 알게 되면, 자동화에 맞는 다른 업무를 찾거나, 다른 접근 방법을 생각해볼 수 있습니다. 가능성 없는 프로젝트에 비용을 쓰는 대신, 가능한 곳에 집중하는 것이 훨씬 낫습니다. 진단에서 "안 된다"고 말하는 것이 저에게는 영업 기회를 잃는 일이지만, 고객에게는 시간과 비용을 아끼는 일입니다. 이것이 재구매로 이어지는 이유이기도 합니다.

진단에서 "안 됩니다"가 나왔던 실제 유형을 보면, 공통점이 있습니다. 데이터가 여러 사람의 머릿속에만 있고 어디에도 기록되지 않은 경우입니다. 업무 담당자가 매번 상황을 보고 임기응변으로 처리하는 방식이라, 규칙 자체가 없는 경우입니다. 이 경우 자동화를 붙이기 전에 업무 자체를 기록 가능한 형태로 만드는 것이 먼저입니다. 이런 판단이 나오면 자동화 대신 업무 흐름 재설계를 제안합니다. 때로는 그것이 더 빠른 경로입니다.

진단 후 범위 확정까지의 흐름

진단 이후 프로세스는 이렇게 진행됩니다.

진단(30분)에서 업무 파악과 가능 여부를 확인합니다. 자동화가 가능하다면, 구체적으로 어떤 범위로 구축할지를 정합니다. 이 시점에서 "여기까지가 이번 구축 범위"가 명확해집니다. 범위가 확정되면 고정 금액으로 견적을 드립니다. 이 금액은 구축 완료 시까지 달라지지 않습니다.

범위 확정 이후에는 파일럿(2주 단위)으로 실제 구축을 시작합니다. 작게 시작하고 실제로 작동하는 것을 확인하면서 확장하는 방식입니다. 이 방식이 가능한 것도 처음에 범위를 명확히 잡았기 때문입니다. 범위가 불분명한 채로 시작하면 어느 수준에서 완성이라고 볼 수 있는지 기준이 없습니다.

구축이 진행되는 중에 새로운 요청이 생기는 경우가 있습니다. "이것도 되면 좋겠다"는 추가 기능 요청입니다. 이런 경우 확정된 범위 안에 있는 것인지 아닌지를 먼저 확인합니다. 범위 안이면 추가 비용 없이 진행합니다. 범위 밖이라면 별도로 논의합니다. 이 구분이 명확하기 때문에 추가 비용 여부를 언제든 확인할 수 있습니다.

이 구조가 가능한 것이 진단에서 범위를 먼저 잡기 때문입니다. 범위 없이 시작했다면 "이것도 포함이냐 아니냐"를 매번 논의해야 합니다.

구축이 완료된 이후에는 운영 담당자가 직접 관리할 수 있도록 인수인계를 합니다. 그것이 구축의 완성입니다. 납품 이후에도 돌아가는 시스템을 목표로 하기 때문에, 인수인계 없이 "다 만들었습니다"로 끝내지 않습니다. 이 접근 방식의 배경은 인수인계까지가 구축입니다에서 더 자세히 설명했습니다.

진단은 고객에게도 손해가 없는 구조

30분 무료 진단은 비용이 없습니다. 시간 비용이 드는 것이 사실이지만, 이 30분이 이후의 프로젝트 전체에 영향을 줍니다.

진단에서 얻는 정보들이 있습니다. 자동화가 가능한지 여부, 어떤 방식이 적합한지, 대략의 범위와 복잡도, 비슷한 사례가 있는지입니다. 이 정보들이 이후 견적과 계획의 기반이 됩니다. 진단 없이 바로 견적부터 시작하면, 이 정보 없이 숫자만 나옵니다.

진단으로 "안 됩니다"가 나오면 30분만 쓰고 끝납니다. 진단 없이 계약부터 하고 중간에 "안 된다"는 것을 알게 되는 것보다 훨씬 낫습니다.

자동화 외주를 맡기기 전에 확인해야 할 체크리스트는 자동화 외주 맡기기 전에 확인해야 할 7가지에서 정리해뒀습니다. 진단과 범위 확정 외에도, 계약 조건과 인수인계 관점에서 챙겨야 할 것들이 여러 가지 있습니다. 외주를 처음 맡겨보는 경우라면 먼저 읽어보시기를 권합니다.

처음 30분이 전체 방향을 정합니다

견적보다 진단이 먼저인 것은 절차를 복잡하게 만들려는 것이 아닙니다. 처음 30분에 투자해서 이후 프로젝트 전체가 방향을 잃지 않게 하는 것입니다. 범위를 확정한 다음에 나오는 견적은 실제로 쓸 수 있는 숫자이고, 그 견적은 구축이 완료될 때까지 달라지지 않습니다.

지금까지 진행한 구축 사례 모두, 진단에서 파악한 범위와 실제 구축 범위가 일치했습니다. 중간에 방향이 바뀐 적이 없습니다. 이것이 가능한 것이 진단에서 범위를 충분히 잡기 때문입니다. 사례마다 처음 요청은 막연했지만, 진단에서 실제 병목을 찾아 범위를 좁혔습니다. 그 결과 구축이 끝났을 때 고객이 기대했던 것과 실제 결과가 일치했습니다.

진단을 예약할 때 미리 준비하면 도움이 되는 것이 있습니다. 자동화하고 싶은 업무를 한 가지 골라두는 것입니다. 여러 가지를 한 번에 해결하려 하면 30분 안에 범위를 잡기 어렵습니다. 가장 반복 빈도가 높고 가장 시간이 많이 드는 업무 하나를 먼저 가져오시면, 진단이 더 구체적으로 진행됩니다. 그 하나에서 시작해서 이후에 확장하는 것이 처음부터 여러 가지를 한 번에 묶어 시도하는 것보다 현실적으로 빠른 경우가 많습니다.

준비가 없어도 됩니다. "무엇을 해야 할지 모르겠다"는 상태로 오셔도 됩니다. 그것을 파악하는 것이 진단의 역할이기도 합니다. 이미 명확한 문제 정의가 있으시다면 더 빠르게 진행됩니다. 진단 전에 업무를 화면으로 보여주실 수 있다면 가장 좋습니다. 어떤 도구로 어떤 방식으로 일하는지를 직접 보면 10분 안에 파악이 됩니다.

자동화 구축을 고려하고 계신다면, 먼저 30분 진단으로 시작해보세요. 가능성과 범위를 먼저 파악한 다음에 결정해도 늦지 않습니다. 진단 결과 "지금은 아닌 것 같다"는 결론이 나와도 그것이 더 나은 선택입니다.

30분 무료 진단 신청하기 — 영업 전화 없이, 가능 여부와 적합한 방법을 먼저 말씀드립니다.