직접 구축·플랫폼 도입·하이브리드. 어떤 선택이든 치르는 대가가 있다. 4개 조직 사례에서 추출한 의사결정 프레임워크 — 역량·TCO·제약 우선순위.
7편 동안 우리가 현장에서 마주친 문제들은 하나같이 계획서에 없던 것들이었다.
일곱 편을 이어 붙이면 하나의 질문이 남는다.
이 모든 레이어를 직접 구축하고 운영할 것인가, 아니면 플랫폼을 선택할 것인가.
현장에서 이 질문은 이론이 아니다. 이 편은 증권사, 생명보험사, 에너지 IT서비스사, 통신사 등 4개 기업의 실제 사례에서 추출한 의사결정 프레임워크다.
우리가 본 한 증권사 AI 테크팀은 자체 RAG 에이전트를 직접 개발하다 결국 플랫폼을 선택했다. 플랫폼을 선택한 이후에는 계획에 없던 비용이 하나씩 모습을 드러냈다. 그리고 어떤 팀은 규제와 비용과 성능이 동시에 충돌하는 상황에서, 선택 자체를 보류하는 "결정 유보 전략"을 택했다.
F사는 직접 구축에서 플랫폼 전환으로 가며 라이선스 밖 비용 1억을 만났고, G사는 규제·비용·성능이 동시에 충돌해 결정을 보류했다. H사·L사는 각각 다른 조건에서 하이브리드 경로를 택했다. 이 네 조직 — F사, G사, H사, L사 — 의 선택을 순서대로 들여다본다.
세 가지 경로, 각각의 대가.
한 증권사 AI 테크팀(이하 증권사 F사)이 자체 RAG 에이전트 개발에 착수했다. 자체 보안 요건, 커스텀 데이터 구조, 내부 통제 — 이 팀이 직접 구축을 선택한 이유는 명확했다.
그런데 그 에이전트가 제대로 작동하는지 확인하려면, 외부 플랫폼의 SaaS 환경을 빌려야 했다.
내부 메일 제목이 당시 상황을 압축한다: "자체 개발 RAG 에이전트 테스트 이슈 및 개선 가이드 요청". 자체 개발한 에이전트의 개선 가이드를, 외부 플랫폼에 요청하는 상황이었다.
외부 검증 도구를 쓰는 것 자체가 문제는 아니다. 문제는 내부 팀이 자체 평가셋과 실패 기준을 보유하고 있지 않았다는 데 있다. 운영 임계값, 실패 케이스, 허용 오류율 — 이것을 내부에서 정의하고 재현할 수 없을 때, 자체 개발의 비용(시간과 인력)은 그대로이면서 자체 개발의 가치(통제권)는 줄어든다.
이 팀이 플랫폼으로 전환한 이유는 개발 속도가 아니라 운영 책임 범위였다. RAG 품질 평가, 접근통제, 배포 운영, 장애 대응까지 내부에서 모두 소화하기 어려웠기 때문이다. 테스트를 진행한 뒤, 온프레미스 플랫폼 본구축으로 방향을 전환했다.
직접 구축을 선택하기 전, 하나만 확인하면 된다.
"우리 팀이 만든 것을, 우리 팀이 검증하고 운영할 역량이 있는가?"
이 질문에 "아직 아니다"가 나온다면, 자체 구축의 전제 자체가 흔들린다.
같은 F사가 다음 단계로 넘어갔다. 자체 구축의 한계를 본 뒤, 온프레미스 플랫폼 도입을 결정하고 구축을 시작했다. 라이선스 비용과 초기 서버 구성은 계획에 있었다.
그런데 구축이 진행되면서, 처음 계획서에 없던 항목들이 나타났다.
모델 성능 이슈가 먼저였다. 처음 계획한 모델로는 목표 동시 사용자 수 기준에서 처리량이 미달했다. 선택지는 이분법이 아니다. GPU를 늘리기 전에 거쳐야 할 단계가 있다: 프롬프트·컨텍스트 최적화 → 모델 경량화(quantization) → serving 튜닝. 이 단계를 소화한 뒤에도 처리량이 미달할 때 GPU 증설이 선택지에 올라온다. 이 팀의 경우 GPU 증설 견적이 나왔다. 약 1억 원이었다.
거기서 끝나지 않았다. 개인정보 마스킹 처리를 위한 소형 LLM 서버도 별도로 필요하다는 것이 드러났다. 이 서버는 플랫폼 패키지에 포함되어 있지 않았다. 시장 가격으로 1,200만~1,300만 원이었다.
두 항목 모두 최초 도입 계획서에는 없었다.
온프레미스 AI 플랫폼의 총소유비용(TCO)은 라이선스와 초기 서버 구축만으로 구성되지 않는다. GPU 증설 비용(약 1억), 보안 처리용 모델 서버(1,200~1,300만), 그리고 운영 인력 비용 — 후자는 자체 관리 기준 관리형 대비 약 3배에 달한다[1]. 초기 견적에 포함되지 않은 항목들이 프로젝트 중반 이후 예산 위기를 만든다.
AI 플랫폼 TCO 분석에서 반복적으로 등장하는 패턴이 있다[2]. 라이선스·구독료는 전체 비용의 40% 미만이다. 나머지 60% 이상이 인력, 통합, 모니터링, 보안 감사 대응에서 나온다.
모델을 선택하면 그 모델이 요구하는 인프라가 따라온다. 보안 처리 방식을 선택하면 그 처리를 위한 별도 서버가 따라올 수 있다. 플랫폼 도입 비용은 라이선스가 아니라 TCO다.
"플랫폼 선택 전에 TCO 계산서를 만들어봤는가? 라이선스만 계산했는가?"
여기까지는 한 조직(F사)이 직접 구축에서 플랫폼으로 옮겨가는 과정이었다. 비용 충격은 전환 이후에 왔다. 그런데 우리가 본 다른 조직 중에는 시작 단계부터 단일 선택 자체가 불가능한 상황을 만난 곳도 있다.
한 대형 생명보험사(이하 생명보험사 G사) AI실의 상황을 들으면 처음에는 의아하게 느껴진다.
이 조직에는 두 개의 AI 환경이 동시에 운영되고 있었다. 탑다운으로 도입된 사내 AI 플랫폼이 하나. AI실이 직접 구현한 외부 클라우드 LLM 환경이 또 하나. 전자는 조직 차원에서 구축 비용을 지불했다. 후자는 AI실이 비용 절감과 성능을 이유로 직접 PoC를 돌리고 있는 환경이다.
사내 AI 플랫폼을 AI실에서는 쓰지 않는다.
이 상황이 개인의 선호 문제가 아닌 이유는 세 가지 제약이 동시에 작동하고 있기 때문이다. 한 꼭짓점은 규제(온프렘 보안 요건), 다른 두 꼭짓점은 비용(GPU 증설 불가)과 성능(온프렘 적합 모델 검증 필요)이다.
규제를 맞추려면 온프레미스가 필요하다. 온프레미스에는 GPU가 필요하다. 그런데 데이터센터에 전력이 부족해 GPU를 살 공간 자체가 없다. 그래서 외부 클라우드 LLM을 쓴다. 외부 LLM은 보안 규제와 충돌한다. 충돌을 해소하려면 다시 온프레미스로 가야 한다.
이 팀이 처한 특수한 상황에서, 세 꼭짓점을 모두 만족시키는 단일 선택지는 사실상 존재하지 않았다.
이 팀이 선택한 것은 결정 유보 전략이다. 지금은 외부 LLM으로 PoC를 유지하고, 국내 또는 글로벌 오픈소스 LLM의 성능이 특정 기준에 도달하면 온프레미스로 전환하겠다는 것이다. 단, 조건을 먼저 정의해 두었다 — 한국어 금융 QA 정확도 기준, p95 응답 기준, 내부망 배포 가능 모델 확보 시점. AI실이 분기별로 벤치마크를 갱신하고, 조건이 충족되면 인프라·보안·구매팀이 공동으로 전환 여부를 검토한다.
조건이 없는 대기는 전략이 아니라 방치다.
성공 지표 없는 PoC도 마찬가지다. 명확한 전환 기준 없이 기술만 검증하는 PoC는 기술 시연으로 끝날 가능성이 높다. 해결하려는 문제와 전환 조건이 PoC 착수 전에 정의되어야 한다. 국내 금융당국도 이 현실을 인식하고, 상용 AI와 오픈소스 AI를 보안 요건에 따라 구분 활용하는 이원 체계를 공식화했다[3].
탑다운으로 도입된 플랫폼이 현장 AI실에서 쓰이지 않는 것은 시스템 품질 문제가 아닐 수 있다. 구매 결정을 내린 조직과 실제로 쓰는 팀이 다른 제약 아래 있을 때, 이런 이중 구조가 만들어진다. 의사결정 레이어가 분리되어 있다는 신호다.
"우리 조직의 플랫폼 선택에서 규제·비용·성능 중 무엇이 가장 강한 제약인가? 전환을 결정할 구체적인 조건을 정의해 두었는가?"
F·G사에 이어 H사·L사 두 가지 사례를 더 살펴본다. IDC는 2028년까지 엔터프라이즈 AI 워크로드의 75%가 하이브리드 인프라에서 운영될 것으로 전망했다[4]. F사가 두 단계를 거치고 G·H·L사가 각자 경로를 택한 과정을 정리하면 선택 조건이 보인다.
한 에너지 IT서비스사(이하 에너지 IT서비스사 H사)는 VM 위에 K8s를 올리고, 그 위에 NVSwitch까지 구성하는 자체 아키텍처를 설계했다. 통제권을 최대한 내부에 두려는 선택이었다. 그런데 NVIDIA Fabric Manager가 VM 환경에서 설치되지 않는다는 기술 제약에 막혀 수 주일이 날아갔다. 국내 공개 레퍼런스는 극히 제한적이었다. 레드햇 코리아에 문의를 넣는 상황까지 갔다. 결국 고객사가 제공하는 OpenShift 클러스터를 그대로 쓰는 방향으로 전환했다.
"직접 구성 = 더 많은 통제권"이라는 전제가 기술 임계점에서 무너지는 순간이었다. 기술 임계점이란 설계 도면상으로는 타당하지만, 실제 환경(특정 버전의 K8s와 GPU 드라이버 간 호환성, 내부 보안 정책으로 인한 필수 라이브러리 설치 불가 등)에서 벽에 부딪히는 지점이다. — H사는 직접 구축 경로를 택했다가, 기술 임계점에서 하이브리드(고객사 제공 인프라 + 자체 소프트웨어 구성)로 전환했다.
다른 한편, 250개 채널 규모의 NLP 콜봇을 운영하는 한 통신사(이하 통신사 L사)는 생성형 AI 전환을 결정하면서 인프라 교체는 빼기로 했다. STT/TTS/콜 인프라를 그대로 두고, RAG와 LLM만 외부 플랫폼 API로 연동하는 하이브리드 구조였다. 이유는 두 가지였다. 여름 성수기 전에 전환을 완료해야 하는 기한 압박, 그리고 250채널 규모 인프라 교체의 리스크. "전부 바꿀 수 없을 때"의 현실적인 답이었다. — L사는 교체 불가 인프라 + 기한 압박이라는 조건에서 하이브리드를 택했다.
다섯 사례를 정리하면 세 가지 경로와 진입 조건이 나온다.
G사의 결정 유보는 세 경로 중 하나가 아니다. 규제·비용·성능이 동시에 충돌해 단일 선택이 불가능할 때, 전환 조건을 정의해 놓고 기다리는 방식이다. 조건을 정의하지 않은 채 기다리는 것과는 다르다.
직접 구축을 선택하기 전, 4가지를 먼저 확인한다:
4개 중 하나라도 "아니다"가 나온다면, 기술 임계점에 막힐 위험이 있다.
직접 구축을 선택하면, 검증과 운영 역량까지 내부에 쌓아야 한다. 그 역량이 없으면 외부에 기대게 된다. 플랫폼을 선택했다는 사실이 역설적으로 드러나는 시점이 바로 그때다.
플랫폼을 선택하면, 라이선스 이후에도 비용이 온다. GPU 용량은 누가 예측하는가? 개인정보 마스킹 실패는 누구의 책임인가? TCO는 계약서에 없다. 과정에서 드러난다.
그리고 플랫폼 도입에는 이탈 비용도 따른다. 우리가 여러 프로젝트를 거치며 반복해서 본 패턴이 하나 있다. 지식베이스 구조, 프롬프트 체인, 워크플로우, 권한 정책, 평가 로그가 특정 플랫폼에 묶이기 시작한다. "공급사를 바꾸고 싶을 때 바꿀 수 있는가"는 도입 계약서에 없는 질문이다. 한 클라우드 비용 조사에서는 IT 리더의 과반이 데이터 전송 비용을 공급사 전환의 주요 장벽으로 꼽았다[5]. 2년 뒤의 선택권을 지금 계약서에서 확인해야 한다.
하이브리드를 선택하면, 단일 선택보다 복잡한 경계가 생긴다. 레이어 간 데이터 정합성, 응답 지연, 보안 경계 — 이 경계를 설계하고 유지하는 것이 새로운 엔지니어링 과제가 된다. 장애가 났을 때 STT, 콜 라우팅, RAG, LLM API 중 어느 레이어가 병목인지 추적할 관측성 설계가 없으면 운영 책임이 공중에 뜬다.
결정을 유보하면, 다른 팀은 계속 움직이고 있다. 업계 조사들이 공통적으로 경고하는 패턴이 있다. AI 이니셔티브를 시작한 기업의 상당수가 운영 전환 이전에 중단한다. 조건이 없는 대기는 그 통계 안으로 들어가는 일이다.
어떤 경로든 공통 질문이 하나 있다.
2년 후에 이 선택을 유지하거나 전환하는 비용을 계산했는가?
처음에 던진 세 가지 질문으로 돌아오면:
1. 역량: 우리 팀이 만든 것을, 우리 팀이 검증하고 운영할 수 있는가?
2. TCO: 라이선스 외에 GPU, 보안 처리 모델, 운영 인력, 이탈 비용까지 포함한 3년 TCO를 계산했는가?
3. 제약 우선순위: 규제·비용·성능 중 무엇이 가장 강한 제약인가? 세 가지를 동시에 최적화하려 하고 있지는 않은가?
지금 팀이 플랫폼 선택 앞에 서 있다면, 이 다섯 가지 질문도 함께 확인한다.
검증·운영 역량과 3년 TCO 중 하나라도 답하지 못한다면, 플랫폼 선택보다 아키텍처 리뷰를 먼저 진행하는 편이 안전하다.
8편을 끝으로 Field Report 시리즈가 마무리된다.
1편의 15초 지연에서 시작해, 보안·GPU·RAG·에이전트·운영 전환·문서 파이프라인을 지나 플랫폼 선택까지. 각 편의 에피소드는 특정 팀의 실패이기도 하지만, 동시에 AI를 현장에 넣으려는 조직이라면 어느 시점에 반드시 마주치는 문제이기도 하다.
직접 구축을 선택한 팀이 외부 플랫폼에 검증을 요청하는 상황에 이르기도 하고, 플랫폼을 선택한 팀이 계획에 없던 1억짜리 GPU 증설을 검토하게 되기도 하며, 세 가지 제약이 동시에 충돌해서 선택 자체를 유보하는 팀도 있다.
어떤 경로든 공통점이 하나 있다. 계획에 없던 청구서는 결정을 미룬 자리에서 온다. 어디서 비용이 숨어 있는지, 어떤 선택이 어떤 대가를 치르는지 — 이것을 먼저 아는 것이 기술 선택 이전의 결정이다.
당신의 팀에서는 TCO 계산서를 누가 쥐고 있는가.
이 글의 사례들은 온프레미스 AI 구축 엔지니어링 팀의 운영 경험에서 추출했습니다. 고객사명과 담당자명은 모두 익명입니다.
[1] Gcore Learning, Kubernetes TCO Comparison — K8s 자체 관리 연간 TCO $335K vs 관리형 $113K, 약 3배 차이 (시뮬레이션 기반, T2) URL: https://gcore.com/learning/kubernetes-tco-comparison
[2] Forrester 연구 기반 TCO 분석 (mondaysys.com 인용, T2) — 라이선스·구독료는 전체 비용의 40% 미만; 인력·통합·모니터링·보안 감사가 나머지 60%+ 구성. 원본 Forrester TEI 보고서는 유료 게이트. URL: https://mondaysys.com/ai-total-cost-of-ownership/
[3] 금융위원회, 「금융권 생성형 AI 활용 지원방안」 2024.12 — 상용 AI와 내부망 설치형 오픈소스 AI를 보안 요건에 따라 구분 활용하는 이원(Two-track) 체계 공식화 (T1) URL: https://www.fsc.go.kr/no010101/83594
[4] IDC, AI Infrastructure: Balancing Data Center and Cloud Investments (2025) — 2028년까지 엔터프라이즈 AI 워크로드의 75%가 하이브리드 인프라 운영 전망 (T1) URL: https://www.intel.com/content/dam/www/central-libraries/us/en/documents/2025-02/idc-ai-infrastructure-balancing-dc-and-cloud-investments-brief.pdf
[5] Flexera, State of Cloud 2025 — 55%의 IT 리더가 데이터 전송·egress 비용을 공급사 전환 최대 장벽으로 지목 (T2, bigstack.co 경유 Flexera 인용) URL: https://www.bigstack.co/blog/managed-vs-unmanaged-kubernetes
올거나이즈는 금융·제조·공공·IT서비스 현장에서 온프레미스 AI의 도입 검토 → 운영 전환 → 장기 운영 파트너십을 하나의 흐름으로 설계해 왔습니다. 직접 구축·플랫폼 도입·하이브리드 각 경로의 실제 TCO와 전환 패턴을 기반으로, 지금 팀이 서 있는 지점부터 이야기를 시작할 수 있습니다.
