컨설팅과 솔루션 구축, 무엇을 사야 하나 — 계약 형태별 장단점

AI 도입을 결정한 경영자가 다음으로 맞닥뜨리는 질문은 보통 이것이다. "컨설팅 업체에 맡길 것인가, 아니면 개발사에 솔루션을 발주할 것인가." 그런데 이 질문은 틀을 잘못 잡은 경우가 많다. 자문(컨설팅)과 구축(개발)은 양자택일이 아니라 거의 모든 AI 도입 프로젝트에서 순서대로, 때로는 동시에 필요한 두 단계다. 진짜로 결정해야 하는 것은 "누구에게 맡길 것인가"가 아니라 "어떤 계약 형태로 맡길 것인가"다. 같은 일을 시간당 요금으로 계약하는지, 고정가로 계약하는지, 매달 일정 분량을 사두는 리테이너로 계약하는지에 따라 비용 초과의 책임이 누구에게 가는지, 그리고 중간에 범위가 바뀌었을 때 무슨 일이 생기는지가 완전히 달라진다.

계약 형태는 네 가지로 좁혀진다

업계 가이드들을 종합하면 AI 프로젝트에 쓰이는 계약 구조는 크게 네 가지로 정리된다.

시간당 계약(타임 앤 머티리얼)은 실제로 들어간 시간과 비용을 그대로 청구하는 방식이다. 무엇을 만들지가 아직 불확실하고 범위가 바뀔 가능성이 큰 탐색 단계에 맞는다. 장점은 유연성이지만, 단점은 예산을 미리 가늠하기 어렵다는 점이다. 컨설팅 가격 비교 자료들은 공통으로 이 방식이 주 단위로 비용이 들쭉날쭉할 수 있다고 지적한다.

고정가 계약은 산출물과 기한을 미리 정하고 그 값에 맞춰 금액을 고정한다. 범위가 명확히 정의된 프로젝트, 예컨대 특정 업무 하나를 자동화하는 파일럿이나 진단 보고서 작성에 적합하다. 비용 초과의 위험을 업체가 떠안는 구조이기 때문에, 업체는 보통 15~25% 수준의 여유분을 금액에 미리 얹어둔다. 반대로 고객이 중간에 요구사항을 바꾸면 추가 청구가 뒤따르기 쉽다.

리테이너는 매달 일정 시간이나 작업량을 미리 구매해두는 방식이다. 범위가 계속 바뀌는 지속적 자문이나 운영 단계의 개선 작업에 맞고, 비용이 매달 일정하다는 장점이 있다. 다만 전체 프로젝트의 총비용이 고정돼 있지 않고, 특정 기능이 언제까지 완성된다는 보장도 없다. 한 업계 자료는 리테이너가 일회성 프로젝트보다는 지속되는 관계에 더 잘 맞는다고 설명한다.

완제품형 서비스(프로덕타이즈드)는 앞의 세 가지와 결이 다르다. 매번 처음부터 설계하는 대신, 같은 방식으로 반복해 배포할 수 있는 틀을 미리 만들어두고 그 틀에 고객의 데이터를 끼워 넣는 방식이다. 업계에서는 AI가 구현 속도를 끌어올리면서 순수 시간당 과금 모델의 수익성이 같이 눌리고 있다고 보는 시각이 있고, 이 때문에 컨설팅펌들이 반복 가능한 방법론과 템플릿을 상품처럼 포장하는 쪽으로 옮겨가고 있다는 분석도 나온다. 고객 입장에서는 가격이 더 예측 가능하고 도입 속도가 빠르지만, 그만큼 자사 업무에 맞춘 미세조정의 폭은 좁아진다.

한 프로젝트에서 계약 형태가 바뀌는 것이 정상이다

여기서 흔히 놓치는 지점이 있다. 네 가지 중 하나를 골라 프로젝트 전체에 적용해야 한다는 생각이다. 실제로는 업계에서 반복해 관찰되는 패턴이 따로 있다. 아직 무엇을 만들지 불확실한 탐색·진단 단계는 리테이너나 소규모 고정가로 짧게 계약하고, 그 단계에서 범위가 명확해지면 실제 구축은 고정가로 전환하고, 시스템이 배포된 이후 운영·개선 단계는 다시 리테이너로 돌아가는 식이다. 하나의 업체와 처음부터 끝까지 같은 조건으로 계약하는 경우보다, 단계마다 계약 형태를 바꾸는 경우가 오히려 정석에 가깝다.

이 틀에서 보면 "컨설팅이냐 솔루션 구축이냐"라는 질문 자체가 재구성된다. 질문은 "이 업체가 컨설팅사인가 개발사인가"가 아니라 "지금 단계에서 범위가 얼마나 확정돼 있는가"다. 범위가 불확실하면 시간 단위로 작게 계약해 탐색하고, 범위가 확정되면 고정가로 전환해 리스크를 넘기는 쪽이 어느 업체를 고르든 통하는 원칙이다.

직접 만들 것인가, 사서 쓸 것인가

계약 형태와 별개로 더 근본적인 결정이 있다. 이 기능을 자체적으로 만들 것인가, 이미 나와 있는 제품을 쓸 것인가다. 한 AI 도입 자문 자료가 제시하는 판단 기준이 실무적이다. 경쟁사가 같은 기성 제품을 사서 똑같이 쓴다면 우리 회사의 경쟁 우위가 사라지는가를 묻는 것이다. 답이 "그렇다"라면 그 기능은 이미 범용 상품이 된 영역이고, 사서 쓰는 쪽이 대개 맞다. 반대로 우리 회사의 경쟁력이 고유한 데이터나 그 업무를 다뤄온 축적된 노하우에서 나온다면, 시간이 더 들어도 직접 만들거나 깊이 맞춘 협업을 하는 쪽이 투자할 가치가 있다. 실제로는 이메일 초안 작성이나 회의록 정리, 단순 문의 분류처럼 어느 회사나 비슷한 범용 업무는 기성 제품으로 충분한 경우가 많고, 자사 가격 정책이나 거래처 등급처럼 그 회사만의 로직이 들어가는 업무일수록 맞춤 구축의 값어치가 커진다.

계약서에 반드시 넣어야 할 것

어느 계약 형태를 고르든 공통으로 확인해야 할 조항이 몇 가지 있다. 첫째는 산출물이 무엇인지 모호한 말이 아니라 구체적인 문서·시스템·기능 이름으로 적혀 있는지다. 둘째는 프로젝트의 종료 지점이 시스템을 배포하는 순간인지, 아니면 안정화까지 포함하는지다. 셋째는 업체가 만든 코드와 학습된 모델, 설정값을 실제로 가지고 나올 수 있는지, 그리고 그 인수 작업이 며칠 안에 어떤 형식으로 이뤄지는지다. 해외 사례 중에는 유럽의 한 보험사가 외부 AI 자문 계약을 재협상한 사례가 소개된 적이 있는데, 처음 계약서에는 단계별 지급 조건과 학습된 모델에 대한 지식재산권 조항이 빠져 있었고, 이를 재협상한 뒤에야 비용을 줄이고 모델과 코드에 대한 소유권을 확보했다고 알려져 있다. 이 사례는 컨설팅사 쪽에서 소개한 내용이라 독립적으로 검증된 수치는 아니지만, 계약 초기에 소유권과 지급 조건을 명시하지 않으면 나중에 재협상이라는 비용이 추가로 든다는 구조 자체는 여러 업계 가이드가 공통으로 지적하는 지점이다.

한국 기업이 고르는 법

한국의 중소·중견기업이 이 결정을 할 때 가장 흔한 실수는 업체의 이름표(컨설팅펌인지 개발사인지)로 먼저 고르는 것이다. 더 효과적인 순서는 반대다. 지금 우리가 하려는 일의 범위가 얼마나 확정돼 있는지를 먼저 판단하고, 그에 맞는 계약 형태를 고른 다음, 그 형태를 제공할 수 있는 업체를 찾는 것이다. 탐색 단계인데 고정가 계약을 서두르면 업체가 떠안을 위험을 금액에 미리 반영해 비싸지고, 범위가 이미 확정된 구축 단계인데 시간당 계약을 유지하면 예산이 끝없이 늘어난다. 계약 형태를 프로젝트의 단계에 맞춰 바꿔간다는 전제를 처음부터 업체와 공유해두면, 중간에 재계약을 두고 다투는 일도 줄어든다.