AI 솔루션 도입, 사서 쓸 것인가 만들 것인가 — 구독과 자체 구축을 가르는 5가지 기준
AI 솔루션 도입을 검토하는 회사들은 대체로 같은 순서로 움직입니다. 데모를 봅니다. 화면이 좋습니다. 한 달 파일럿을 돌립니다. 나쁘지 않습니다. 그리고 여섯 달 뒤, 결제는 매달 나가는데 실제로 그 화면을 여는 사람은 두세 명입니다.
반대쪽 경로도 결말이 비슷합니다. “우리 업무에 맞는 걸 직접 만들자”고 결정하고 개발사 세 곳에서 견적을 받습니다. 금액이 열 배 차이 납니다. 어느 쪽 설명이 맞는지 판단할 사람이 사내에 없습니다. 그래서 가장 싼 곳을 고르고, 여섯 달 뒤 처음부터 다시 시작합니다.
두 실패는 원인이 같습니다. 사서 쓸 것인지 만들 것인지를 정하지 않은 채 제품부터 봤다는 것입니다. 이 판단을 먼저 끝내면 뒤따르는 결정 대부분은 자동으로 정리됩니다. 반대로 이 판단을 건너뛰면, 어떤 제품을 고르든 어떤 개발사를 쓰든 같은 자리로 돌아옵니다.
디비컨설팅은 100건 이상의 웹·앱·플랫폼 구축 프로젝트를 수행해 왔습니다. 삼성물산 홈닉(주거 플랫폼 앱), GS건설 엘리시안 리조트(리조트 웹·앱 통합 구축), 하나투어 하나오픈챗(여행 상담 채팅 서비스), LS일렉트릭 테크스퀘어(산업 B2B 거래 플랫폼), 가천대학교 학사관리 시스템처럼 실사용자가 매일 쓰는 시스템을 만들어 왔고, 50개 이상의 글로벌 파트너사와 함께 일합니다. 아래 기준은 일반론이 아니라 그 과정에서 반복적으로 확인한 판단 지점입니다.
도입이 실패하는 두 가지 경로
산 경우 — 데모에서는 보이지 않던 것
구독형 솔루션의 데모는 그 제품이 가장 잘하는 시나리오를 보여줍니다. 문제는 우리 회사의 실제 업무가 그 시나리오와 얼마나 겹치느냐입니다. 겹치는 부분이 크면 훌륭한 선택입니다. 겹치는 부분이 절반이면, 나머지 절반은 결국 사람이 손으로 메웁니다.
실무에서 이탈이 생기는 지점은 대체로 세 곳입니다. 첫째, 우리 데이터를 넣는 순간 답변 품질이 떨어집니다. 데모 데이터는 정리되어 있었고 우리 데이터는 그렇지 않기 때문입니다. 둘째, 사내 시스템과 연결되지 않아 결국 두 화면을 번갈아 보게 됩니다. 셋째, 쓰는 사람이 늘수록 계정 요금이 같이 늘어나서, 전사 확대 시점에 비용이 다시 안건으로 올라옵니다.
이미 구독형을 사기로 방향을 잡았다면, 계약 전에 확인할 항목은 해외 AI 제품 도입, 계약 전에 벤더에게 물어야 할 12가지에 따로 정리해 두었습니다.
만든 경우 — 견적서에서는 보이지 않던 것
자체 구축은 반대의 함정이 있습니다. 개발 자체는 대체로 끝납니다. 멈추는 곳은 그 앞과 뒤입니다.
앞에서는 데이터가 발목을 잡습니다. “사내 문서를 학습시켜 답하게 하자”는 요구는 한 문장이지만, 실제로는 문서가 어디에 흩어져 있는지, 어떤 버전이 최신인지, 누가 무엇을 볼 권한이 있는지를 먼저 정리해야 합니다. 이 정리는 개발사가 대신해 줄 수 없습니다. 회사 내부를 아는 사람이 결정해야 하는 일이기 때문입니다.
뒤에서는 운영이 발목을 잡습니다. AI 기능은 출시하고 끝나는 기능이 아닙니다. 오답이 나왔을 때 누가 고치는지, 모델을 바꿀 때 기존 답변 품질이 유지되는지, 사용량이 늘 때 호출 비용이 어떻게 변하는지가 계속 따라옵니다. 견적서에 이 항목이 없으면 그 금액은 완성 금액이 아니라 착수 금액입니다. 견적이 갈리는 구조는 AI Agent 개발 비용, 왜 견적이 열 배씩 차이 나는가에서 항목별로 다뤘습니다.
공통 원인 — 기준 없이 제품부터 봤다
두 경우 모두, 비교를 시작한 시점에 이미 답이 정해져 있었습니다. 어떤 팀이 데모를 먼저 봤으면 사는 쪽으로, 어떤 팀이 개발사를 먼저 만났으면 만드는 쪽으로 기울었습니다. 제품은 판단의 결과여야 하는데 판단의 출발점이 된 것입니다. 순서를 되돌리는 기준이 아래 다섯 가지입니다.
사야 하는가, 만들어야 하는가 — 다섯 가지 기준
기준 1. 그 업무가 우리의 차별점인가
경쟁사도 똑같이 하는 업무라면 사서 쓰는 편이 거의 항상 낫습니다. 회계 처리, 일정 조율, 일반 문서 요약, 회의록 정리 같은 것들이 여기 해당합니다. 이런 업무를 직접 만들면, 남들이 월 구독료로 해결한 것을 우리는 개발비와 운영 인력으로 해결하게 됩니다.
반대로, 그 업무 방식 자체가 우리 회사가 돈을 버는 이유라면 사는 순간 차별점이 사라집니다. 견적 산출 로직, 매칭 기준, 심사 기준, 고객 등급 판정 같은 것들입니다. 이런 판단 규칙은 시장에 나와 있는 제품이 알 수 없는 영역이고, 알게 되는 순간 경쟁사도 같은 것을 쓸 수 있게 됩니다.
기준 2. 데이터가 회사 밖으로 나가도 되는가
이 질문은 취향의 문제가 아니라 규정의 문제입니다. 개인정보, 고객사와 맺은 비밀유지 조항, 업권별 규제, 모회사 정책 중 하나라도 “외부 전송 불가”에 걸리면 구독형은 후보에서 빠집니다. 국내 리전 여부, 학습 데이터 사용 여부, 로그 보관 기간은 계약서에서 확인해야 하는 항목이지 영업 담당자의 구두 답변으로 넘어갈 항목이 아닙니다.
다만 “나가면 안 된다”는 답이 곧 “우리가 직접 개발해야 한다”는 뜻은 아닙니다. 통제해야 하는 것은 데이터의 위치와 접근 권한이지 개발 인력의 국적이 아닙니다. 이 구분은 외주 개발 보안, 소스코드는 어디까지 안전한가에서 접근 권한 설계 기준으로 다뤘습니다.
기준 3. 사내 시스템과 붙어야 하는가
AI가 답을 잘 만드는 것과, 그 답이 업무에 실제로 반영되는 것은 다른 문제입니다. 결과를 사람이 복사해서 ERP나 그룹웨어에 다시 입력해야 한다면, 그 도구는 업무를 줄인 것이 아니라 한 단계 추가한 것입니다. 실제 이탈의 상당수가 여기서 발생합니다.
기준은 단순합니다. 읽기만 하면 되는가, 쓰기까지 해야 하는가. 읽기만 필요하다면 구독형으로도 대부분 해결됩니다. 사내 시스템에 값을 쓰는 순간부터는 권한, 감사 로그, 실패 시 롤백까지 설계해야 하고, 그 지점부터 구축 영역으로 넘어갑니다.
기준 4. 쓰는 사람이 늘면 요금이 어떻게 되는가
구독형 대부분은 계정당 과금입니다. 10명이 쓸 때는 저렴하고, 전사 300명으로 확대하는 순간 계산이 달라집니다. 도입 검토 시점의 인원이 아니라 성공했을 때의 인원으로 3년 총액을 계산해 보는 것이 정확합니다.
자체 구축은 반대 곡선입니다. 초기 투입이 크고, 인원이 늘어도 비용이 비례해서 늘지는 않습니다. 두 곡선이 만나는 지점이 우리 회사의 예상 사용 규모보다 앞에 있으면 구축이, 뒤에 있으면 구독이 유리합니다. 여기서 흔한 실수는 구축 쪽 계산에 운영·유지보수를 빼놓는 것입니다. 그 항목을 빼면 어떤 계산이든 구축이 이깁니다.
기준 5. 3년 뒤에도 우리가 통제할 수 있어야 하는가
업무에 깊이 들어간 도구일수록 벗어나기 어렵습니다. 벤더가 가격 정책을 바꾸거나, 제품 방향을 틀거나, 서비스를 종료할 때 우리에게 무엇이 남는지를 도입 전에 확인해야 합니다. 축적한 데이터를 표준 형식으로 내보낼 수 있는지, 그 데이터에 우리가 만든 판단 규칙이 함께 담기는지가 핵심입니다.
자체 구축의 실질적인 가치는 여기 있습니다. 소스코드와 데이터가 발주사에 귀속되면, 3년 뒤 방향을 바꿀 때 다시 처음부터 시작하지 않아도 됩니다.
| 판단 항목 | 구독형 솔루션 | 자체 구축 |
|---|---|---|
| 초기 투입 | 낮음 | 높음 |
| 시작까지 걸리는 시간 | 짧음 | 김 |
| 우리 업무에 맞는 정도 | 제한적 | 맞출 수 있음 |
| 사내 시스템 연동 | 벤더 정책에 종속 | 설계 가능 |
| 인원이 늘 때 비용 | 계정 수에 비례 | 인원과 무관 |
| 데이터 위치 통제 | 제한적 | 가능 |
| 중단 시 남는 것 | 없음에 가까움 | 코드와 데이터가 자산으로 남음 |
| 소스코드 소유권 | 없음 | 발주사 귀속 |
다섯 기준 중 세 개 이상이 구축 쪽을 가리키면 만드는 것이 맞습니다. 두 개 이하라면 사는 편이 낫고, 그 예산은 도입 후 정착과 교육에 쓰는 편이 회수가 빠릅니다. 어느 업무부터 손댈지가 아직 정리되지 않았다면 AI를 도입해도 달라지지 않는 이유 — 업무 진단에서 출발하는 이유를 먼저 보시는 편을 권합니다.
만들기로 했다면, 발주 방식이 결과를 가릅니다
구축으로 결론이 났다면 다음 질문은 “어디에 맡길 것인가”입니다. 여기서 많은 회사가 국내 개발사와 해외 개발사의 단가만 비교합니다. 하지만 실제로 비용을 가르는 변수는 단가가 아니라 요구사항을 누가 정의하고 누가 책임지는가입니다.
| 국내 개발사 | 해외 직접 발주 | 한국 PM + 글로벌 개발팀 | |
|---|---|---|---|
| 개발 단가 | 높음 | 낮음 | 낮음 |
| 요구사항 정의 책임 | 개발사 | 발주사 본인 | 한국 PM |
| 커뮤니케이션 언어 | 한국어 | 영어 | 한국어 |
| 발주사 담당자 투입 시간 | 보통 | 매우 많음 | 적음 |
| 재작업 리스크 | 낮음 | 높음 | 낮음 |
| 총비용 관점 | 비쌈 | 기대만큼 안 싸다 | 실질 절감 |
해외 직접 발주가 기대만큼 저렴하지 않은 이유는 단가가 아니라 가운데 열에 있습니다. 요구사항 정의 책임이 발주사에게 넘어오기 때문입니다. AI 프로젝트에서는 이 부담이 일반 개발보다 더 큽니다. “무엇을 만들지”뿐 아니라 “어디까지 자동으로 판단하게 할지”, “틀렸을 때 어떻게 처리할지”까지 정의해야 하기 때문입니다.
사내에 그 정의를 해 줄 기술 담당자가 있다면 해외 직접 발주도 가능한 선택입니다. 없다면 단가가 아무리 낮아도 총비용은 올라갑니다. 정의되지 않은 요구사항은 반드시 재작업으로 돌아오기 때문입니다. IT 아웃소싱에서 세 번째 열이 존재하는 이유가 이것입니다. 한국인 PM이 한국어로 요구사항을 정의하고 일정을 책임지며, 개발은 검증된 글로벌 팀이 맡습니다.
디비컨설팅이 통제하는 방식
- 상담 및 요구 분석 — 비즈니스 목표와 기술 요구사항을 한국어로 문서화합니다. AI 프로젝트에서는 여기에 자동 판단 범위와 오답 처리 기준까지 포함됩니다. 뒤에서 생기는 재작업 대부분이 이 단계에서 제거됩니다.
- 개발팀 구성 — 요구사항에 맞춰 전담팀을 2~4주 내에 구성합니다. 채용이 아니라 배정이므로 시작 시점이 예측 가능합니다.
- 프로젝트 개발 — 애자일 방식으로 진행하고 진척을 투명하게 공유합니다. 발주사 담당자가 하루를 개발팀 조율에 쓰지 않아도 되는 구조입니다.
- 테스트 및 배포 — QA 절차를 거쳐 배포합니다. AI 기능은 기능 통과 여부만이 아니라 답변 품질 기준까지 함께 확인합니다.
- 운영 및 유지보수 — API 명세, DB 스키마, 배포 절차를 문서와 함께 인계하고 장기 지원을 이어갑니다. 다섯 번째 기준에서 말한 “3년 뒤에도 통제 가능한가”에 대한 답이 이 단계입니다.
발주 전에 정해야 할 항목을 문서 형태로 준비하고 싶다면 요구사항 정의서, 어디까지 써야 할까와 AI Agent 개발 외주, 발주 전에 반드시 정해야 하는 5가지를 함께 보시면 됩니다.
실제로 구축한 시스템들
AI 기능이 실제로 붙는 자리는 데모 화면이 아니라 이미 사용자가 매일 쓰고 있는 업무 시스템입니다. 디비컨설팅이 구축한 시스템의 일부입니다.
- 삼성물산 — 홈닉, 주거 플랫폼 앱
- GS건설 — 엘리시안 리조트, 리조트 웹·앱 통합 구축
- 하나투어 — 하나오픈챗, 여행 상담 채팅 서비스
- LS일렉트릭 — 테크스퀘어, 산업 B2B 거래 플랫폼
- 직방 — 호갱노노, 부동산 데이터 서비스
- 교보생명 — 사내벤처(글펍), 커뮤니티 서비스
- 가천대학교 — 학사관리 시스템
- 센터필드 · 센트로폴리스 · 그랑서울 — 프라임 오피스 빌딩 관리 시스템
교육, 금융·핀테크, 헬스케어, 제조·물류, 이커머스, 스마트빌딩·IoT 영역의 구축 경험이 있습니다. 더 많은 사례는 포트폴리오에서 보실 수 있고, B2B 플랫폼에 판단 로직을 얹는 방식은 B2B 플랫폼에서 매칭 담당자를 AI Agent로 바꾸면에서 다뤘습니다.
이런 기업에 적합합니다
- 자동화하려는 업무가 회사의 차별점이고, 시장 제품으로는 그 판단 규칙을 담을 수 없는 경우
- 규정이나 고객사 계약 때문에 데이터를 외부로 보낼 수 없는 경우
- ERP·그룹웨어·사내 DB에 값을 기록하는 데까지 자동화해야 하는 경우
- 전사 확대를 전제하고 있어 계정당 과금이 3년 총액에서 불리해지는 경우
- 기술 요구사항을 정의해 줄 담당자가 사내에 없어, 요구 정의부터 맡길 파트너가 필요한 경우
반대로, 권하지 않습니다
- 경쟁사와 똑같은 일반 업무를 자동화하려는 경우. 문서 요약, 회의록 정리, 일정 조율은 구독형이 훨씬 빠르고 쌉니다. 만들면 손해입니다.
- “일단 AI를 도입해 보자”에서 출발한 경우. 해결할 업무가 지정되지 않은 프로젝트는 무엇을 만들어도 성과를 증명할 수 없습니다. 업무 진단이 먼저입니다.
- 운영 예산 없이 구축 예산만 잡은 경우. AI 기능은 출시 시점이 아니라 운영 중에 품질이 결정됩니다. 유지보수 계획이 없으면 구축하지 않는 편이 낫습니다.
- 3개월 안에 전사 적용까지 끝내야 하는 경우. 범위를 좁히지 않는 한 이 일정은 지켜지지 않습니다. 그 경우 구독형으로 시작하고, 검증된 뒤에 구축을 검토하시는 편을 권합니다.
자주 묻는 질문
해외 개발팀이라면 의사소통은 어떻게 되나요?
발주사는 한국인 PM하고만 한국어로 소통합니다. 요구사항 정의, 일정 관리, 검수는 PM의 책임입니다. 영어로 개발팀과 직접 조율하실 일은 없습니다. AI 프로젝트에서 특히 중요한 부분인데, 자동 판단 범위나 오답 처리 기준 같은 항목은 미묘한 뉘앙스가 결과를 바꾸기 때문입니다.
비용은 어떻게 산정되나요?
등급별 단가에 투입 기간을 곱하는 방식이며, 기획·디자인·개발·QA·배포·유지보수를 항목별로 구분해 제시합니다. AI가 포함된 프로젝트는 여기에 모델 호출 비용과 운영 항목이 별도로 표기됩니다. 한 덩어리 총액만 적힌 견적서는 어느 회사의 것이든 비교가 불가능하니 항목별 분리를 요청하시는 편이 좋습니다.
기획서가 없는데 견적을 받을 수 있나요?
가능합니다. 해결하려는 문제, 주요 사용자, 필수 기능 3~5개, 일정과 예산 범위만 있으면 개략 견적을 드립니다. 오히려 이 단계에서 상담하시는 편이 낫습니다. 사야 할 일인지 만들어야 할 일인지부터 같이 정리할 수 있기 때문입니다.
시작한 뒤에 팀 규모를 조정할 수 있나요?
가능합니다. 전담팀, 장기 협업, 인력 단위, 프로젝트 단위 중에서 선택하실 수 있고 진행 중 조정도 됩니다. AI 프로젝트는 초기 검증 단계와 확장 단계의 필요 인력이 다른 경우가 많아, 이 유연성이 실제 총비용에 영향을 줍니다.
완성된 결과물의 소스코드는 누구 것인가요?
발주사에 귀속됩니다. API 명세, DB 스키마, 배포 절차 문서까지 인계해 드립니다. 다섯 번째 판단 기준에서 자체 구축의 실질적 가치가 “3년 뒤에도 남는 자산”이라고 말씀드렸는데, 소유권과 문서가 함께 넘어가지 않으면 그 자산은 성립하지 않습니다. 계약서에서 반드시 확인하셔야 하는 항목입니다.
정리
AI 솔루션 도입의 성패는 어떤 제품을 고르느냐가 아니라 사서 쓸 일인지 만들 일인지를 먼저 구분했느냐에서 갈립니다. 차별점이 아니고, 데이터가 밖으로 나가도 되고, 읽기만 하면 되고, 사용 인원이 적고, 3년 뒤 바꿔도 상관없다면 사서 쓰십시오. 그중 셋 이상이 반대라면 만들어야 하고, 그때 총비용을 결정하는 것은 개발 단가가 아니라 요구사항을 한국어로 정의하고 책임질 사람이 있느냐입니다. 그 사람이 사내에 없다면, 그 역할까지 포함해서 발주하는 것이 가장 싸게 가는 길입니다. AI Agent 개발 상담은 아이디어 단계에서도 가능합니다.
무료 진단
우리 조직에 맞는 AI 도입, 어디서 시작해야 할까요?
도구 도입 전에 업무 구조 진단이 먼저입니다. 반복 업무와 판단 업무를 구분하는 것부터 함께 정리해 드립니다.
업무 구조 진단부터 시작 · 영업일 기준 24시간 이내 회신 · 상담 무료