# AI 컨설턴트가 자체 구축 SaaS 교체 범위를 산정하는 방법

> Published: 2026-07-31
> Updated: 2026-07-31
> Author: Mathias Nielsen
> Category: POS
> Canonical: https://finalpos.com/ko/blog/ai-saas

컨설턴트는 기능 목록을 기준으로 자체 구축 SaaS 교체 범위를 산정하지 않습니다. 모든 툴을 두 개의 계층으로 나누고, 오류 발생 시 치러야 할 비용을 기준으로 각 작업의 등급을 매기며, 코드가 아닌 검증 비용을 기준으로 가격을 책정합니다.

제값을 하는 컨설턴트라면 누구나 동일한 방식으로 자체 구축 SaaS 교체 범위를 산정합니다. 바로 각 툴을 눈에 보이는 부분과 매번 정확해야 하는 부분이라는 두 가지로 나누는 것입니다. SaaS(매월 구독료를 내고 사용하는 소프트웨어)는 대부분 기록 보관이라는 비교적 작은 핵심 영역 위에 화면, 워크플로, 보고서가 얹혀 있는 구조입니다. AI 덕분에 전반부를 재구축하는 비용은 훨씬 저렴해졌습니다. 하지만 프로젝트가 실패하는 지점은 후반부이며, 제대로 된 범위 산정 작업의 목적은 구독 비용 중 실제로 이 후반부에 해당하는 비중이 얼마나 되는지 측정하는 것입니다.

자체 구축 SaaS 교체 범위가 단계별로 어떻게 구성되는지, 그리고 의사 결정의 대부분을 좌우하는 단 하나의 질문을 아래에서 살펴보겠습니다. (아래 언급된 벤더명과 설문조사 수치는 발행일 기준이며, 특정 세부 사항은 참고용 스냅샷으로 확인해 주시기 바랍니다.)

## SaaS 교체 범위 산정서에는 실제로 어떤 내용이 담길까요?

기능 목록이 아닌, 수행해야 할 '작업 목록(jobs inventory)'이 들어갑니다. 컨설턴트는 해당 툴이 수행하는 모든 작업, 각 작업을 담당하는 사용자, 그리고 결과물이 잘못되었을 때 발생하는 상황을 정리합니다. 승인 라인, 대시보드, 폼 등은 한 열에 분류하고, 자금 이동, 재고 수량, 세금, 직원 기록 등은 다른 열에 분류합니다. 최종 결과물은 이와 같은 매핑 현황, 작업별 위험 등급, 그리고 해당 툴이 암묵적으로 연결되어 있는 모든 시스템의 목록입니다.

등급을 매길 때 던지는 질문이 핵심입니다. "이 결과물이 틀렸다면 어떻게 알아차릴 수 있으며, 그에 따른 비용은 얼마나 발생할까?" 오래된 대시보드 데이터는 한눈에 알아챌 수 있고 추가 비용이 들지 않습니다. 반면 잘못된 정산 총액은 세금 신고 시점에야 발견되며 막대한 실제 비용을 유발합니다.

![자체 구축 SaaS 교체에서의 인터페이스 계층과 인프라 계층을 비유하기 위해 톱니바퀴 무브먼트와 분리된 시계 케이스](https://hy9joxwes0n0bta4.public.blob.vercel-storage.com/media/43399b6a-0d29-48b6-84dd-88ef01fcb193/generated/2426ce685d3a484a-two-layers-watch-case-and-movement.png)

## 제품을 왜 두 계층으로 나누어야 할까요?

AI가 한 계층의 구축 비용을 파격적으로 줄인 반면, 다른 계층은 거의 건드리지 못했기 때문입니다. 인터페이스 계층(폼, 대시보드, 내부 툴, 승인 워크플로)은 이제 빠르게 재구축할 수 있습니다. 최신 모델은 몇 시간 만에 실제로 작동하는 웹 앱을 만들어내며, 이는 우리가 [GPT-5.6이 실제로 작동하는 POS를 구축할 수 있는지](/blog/can-chatgpt-5-6-build-a-working-pos) 실험했을 때 확인한 결과이기도 합니다. 하지만 인프라 계층은 다릅니다. 결제 처리, PCI 준수(PG사가 강제하는 카드 보안 규정), 동시성 상황에서의 재고 관리(두 개의 계산대에서 마지막 남은 1개 수량을 동시에 판매하는 경우), 대사가 맞물리는 보고서(은행 입금액과 일치하는 합계) 등이 여기에 해당합니다. 이 계층이 어려운 이유는 코드가 길어서가 아닙니다. '대략 맞음'은 아무런 가치가 없으며, 정합성을 증명하는 비용이 코드를 생성하는 비용보다 훨씬 더 많이 들기 때문입니다.

더 뛰어난 모델이 나온다고 해서 이러한 제약이 사라지는 것은 아닙니다. 병목 현상은 코드 생성에 있는 것이 아니라 검증과 법적·재무적 책임에 있으므로, 정직한 범위 산정은 검증 작업의 가격을 측정합니다. 코드를 생성하는 것이 데모라면, 검증하는 것은 정산서인 셈입니다.

## Klarna의 SaaS 교체 사례가 실제로 입증한 것은 무엇일까요?

"SaaS를 AI로 대체했다"며 가장 크게 주목받았던 사례는 알고 보면 범위 산정에 관한 교훈입니다. 2024년 말 Klarna의 CEO는 AI 대대적 개편의 일환으로 Salesforce와 Workday 사용을 중단한다고 발표했고, 언론 헤드라인은 AI가 SaaS를 완전히 대체하고 있다고 보도했습니다. 그러나 후속 보도에 따르면 구체적인 사실은 다소 달랐습니다. Klarna는 HR을 다른 벤더로 이전하고, CRM 니즈는 대체 툴과 내부 연결 코드의 조합에 AI를 레이어 형태로 얹어 해결한 것으로 나타났습니다[¹](https://www.cxtoday.com/crm/klarna-didnt-replace-salesforce-it-replaced-them-with-alternative-saas-apps/). 핀테크 분야에서 가장 공격적으로 AI 프로그램을 운영하는 정식 인가 은행조차 원장 시스템(System of record: 비즈니스 데이터의 최종 원본)은 검증된 플랫폼에 그대로 두고 주변부 위주로 재구축한 것입니다.

이는 용기가 부족해서가 아니었습니다. 범위 산정이 제 역할을 한 결과였습니다.

## 어떤 지표가 교체 프로젝트의 타당성을 입증할까요?

먼저 낭비를 줄이고, 그 다음에 구축해야 합니다. 4,000만 개 이상의 관리 라이선스 데이터를 바탕으로 작성된 Zylo의 2026 SaaS Management Index에 따르면, 직원 1인당 연간 SaaS 지출 중간값은 9,455달러이며 라이선스의 평균 36%가 미사용 상태인 것으로 나타났습니다. 또한 IT 부서가 직접 관리하는 비율은 15%에 불과하고 현업 부서가 SaaS 지출의 81%를 통제하고 있는 것으로 파악되었습니다[²](https://zylo.com/news/2026-saas-management-index). 컨설턴트는 무언가를 제안하기에 앞서 이러한 지표를 기준으로 사용 중인 스택을 평가합니다. 미사용 계정을 해지하고, 중복되는 툴을 통합한 뒤에야 비로소 재구축 후보를 추려냅니다.

![자체 구축 SaaS 교체 범위를 산정하기 전에 소프트웨어 구독 지출을 감사하는 비즈니스 소유주](https://hy9joxwes0n0bta4.public.blob.vercel-storage.com/media/43399b6a-0d29-48b6-84dd-88ef01fcb193/generated/217ba90d450941db-software-spend-audit-review.png)

최종 후보에 오르는 툴은 공통적인 특성을 지닙니다. 정기 구독 비용이 높고, 작업의 대부분이 인터페이스 계층에 위치하며, 장애 발생 시 영향 범위가 작다는 점입니다. 프로젝트 승인은 구독 비용 증가 속도가 구축 및 유지보수 비용보다 빠르고, '반드시 정확해야 하는' 모든 작업은 타사가 이미 안정적으로 운영 중인 인프라 위에 유지될 수 있을 때 이루어집니다.

## 이러한 범위 산정에서 POS는 어디에 위치할까요?

스펙트럼에서 가장 가혹하고 오차가 용납되지 않는 지점에 위치합니다. POS(point of sale)는 버튼 그리드와 장바구니 형태로 보여 인터페이스 중심 프로젝트처럼 보이기 때문에 사업주들은 대시보드처럼 범위를 산정하면 될 것이라 생각합니다. 하지만 실제 비율은 반대입니다. 결제 화면은 전체 제품의 극히 일부분일 뿐이며, 나머지는 결제 처리, 인증된 대면 카드 결제 단말기, 두 대의 계산대에서 동시 판매가 일어나도 정상 유지되는 재고 관리, 세금 규정, 대사가 맞물리는 일마감 보고서입니다. POS에서 오류가 발생하면 매일 '돈'에 관한 오류가 발생하는 것입니다.

따라서 컨설턴트는 Klarna가 원장 범위를 산정한 것과 동일한 방식으로 POS 재구축 범위를 산정합니다. 즉, 커스텀 인터페이스와 검증된 인프라를 조합하는 방식입니다. 예전에는 이러한 분리를 위해 개발 팀이 필요했습니다. 하지만 이제는 하나의 제품 카테고리가 되었습니다. Final의 Build 기능은 자연어 프롬프트를 [미리 보고 배포할 수 있는 결제 플로우](https://finalpos.com/help/getting-started-with-build)로 변환해 주며, [MCP를 통해 자체 AI를 연결](/blog/is-final-pos-an-ai-wrapper)하여 동일한 커머스 인프라를 기반으로 구축할 수도 있습니다. 결제, 재고, 보고서 및 하드웨어는 이미 검증된 계층 위에 그대로 유지됩니다.

![커스텀 결제 시스템 뒷단의 커머스 인프라 계층을 보여주는 카페 카운터의 로고 없는 태블릿 POS 및 카드 리더기](https://hy9joxwes0n0bta4.public.blob.vercel-storage.com/media/43399b6a-0d29-48b6-84dd-88ef01fcb193/generated/4fc7d285553fafbd-unbranded-tablet-pos-counter-checkout.png)

## 그렇다면 자체 구축 SaaS 교체 범위를 어떻게 산정해야 할까요?

모든 툴을 두 계층으로 나누고, 감지되지 않은 오류 결과물이 유발할 비용을 기준으로 각 작업의 등급을 매기며, 코드가 아닌 검증 작업의 가격을 측정하세요. 인터페이스와 워크플로는 자유롭게 재구축하되, 원장 시스템은 타사가 정확성을 보장해 주는 인프라 위에 남겨두어야 합니다. **내부에서 툴을 재구축하기 전 반드시 스스로에게 물어보세요. "이 결과물이 잘못되었을 때 얼마나 빨리 알아차릴 수 있는가?"** 그에 대한 답이 "빠르지 않다"라면 해당 작업은 검증된 인프라에 맡겨야 합니다.

그리고 스택 중 재구축하고자 하는 영역이 커머스 부문이라면, 현재 모델이 스스로 구축할 수 있는 것과 구축할 수 없는 것이 무엇인지 솔직하게 살펴보는 것부터 시작해 보세요. [실제 POS 구축 사례를 다룬 Claude vs ChatGPT vs Gemini 비교](/blog/claude-vs-chatgpt-vs-gemini-pos) 글이나, [Gemini 3.6 Flash를 활용해 커스텀 POS를 구축하는 방법](/blog/gemini-3-6-flash-no-code-pos)에서 소개하는 두 가지 노코드 방식을 참고하실 수 있습니다.

## FAQ

**Q: SaaS 구독을 유지하는 것보다 소프트웨어를 자체 구축하는 것이 더 저렴한가요?**
A: 대시보드, 폼, 내부 워크플로처럼 인터페이스 비중이 높은 툴의 경우 AI 활용 구축으로 개발 비용이 절감되어 더 저렴한 경우가 많습니다. 그러나 결제나 회계와 같은 원장 시스템의 경우 코드를 작성하는 비용이 아니라 정확성을 증명하는 비용이 크기 때문에 더 저렴해지는 경우가 드뭅니다.

**Q: Klarna가 실제로 Salesforce와 Workday를 AI로 대체했나요?**
A: 언론 헤드라인에서 시사한 방식은 아니었습니다. 후속 보도에 따르면 Klarna는 핵심 기록을 검증된 플랫폼 위에 유지한 채, 대체 벤더 및 AI가 레이어로 올려진 내부 툴로 전환한 것으로 확인되었습니다.

**Q: 절대 자체 구축하지 말아야 할 것은 무엇인가요?**
A: 잘못된 결과물이 감지되기 어렵고 감지되었을 때 막대한 비용이 발생하는 항목들입니다. 즉 결제 처리, 회계 장부, 세금 계산, 컴플라이언스 보고 등입니다. 대신 검증된 인프라 위에 인터페이스만 재구축하는 것이 좋습니다.

**Q: 컨설턴트는 어떤 SaaS 툴을 먼저 교체할지 어떻게 결정하나요?**
A: 먼저 낭비 요소(미사용 라이선스, 중복 툴)를 정리한 다음, 기록 보관보다는 화면 및 워크플로 작업이 대부분인 고비용 툴을 후보로 추려냅니다.

**Q: AI가 스스로 작동하는 POS를 만들 수 있나요?**
A: 아니요. 결제 화면 인터페이스는 생성할 수 있지만 결제 처리, 인증된 카드 리더기, 부하 상황에서도 정확성을 유지하는 재고 관리 등은 그 하단에 실제 커머스 인프라가 갖춰져야 합니다.