온프레미스 vs 클라우드 LLM 배포 판단 매트릭스: 기업 AI 서비스는 어디에 올려야 할까
정답부터 말하면, 기업 AI 서비스의 기본값은 ‘일단 퍼블릭 LLM API로 빠르게 만든다’가 아니라 ‘업무와 데이터 등급을 나눈 뒤 배포 위치를 다르게 둔다’입니다. 공개 FAQ 챗봇, 마케팅 문안 초안, 내부 지식 검색처럼 위험이 낮은 기능은 퍼블릭 API나 관리형 클라우드가 현실적입니다. 반면 고객 식별정보, 계약서 원문, 상담 녹취, 인사·재무 문서, 폐쇄망 업무 시스템이 들어오면 VPC·프라이빗 클라우드·온프레미스·하이브리드 구조를 검토해야 합니다. 온프레미스가 항상 더 안전하거나 더 저렴한 것은 아니며, 클라우드가 항상 위험한 것도 아닙니다. 핵심은 데이터가 어디를 지나가고, 누가 로그를 보관하며, 장애와 모델 업데이트 책임을 누가 지는지입니다.
PoC 단계에서는 API 키 하나로 챗봇을 붙일 수 있습니다. 하지만 실서비스가 되면 질문이 달라집니다. 고객이 업로드한 PDF가 외부 모델로 나가도 되는가, 상담 로그를 몇 년 보관해야 하는가, 임베딩 벡터도 개인정보로 봐야 하는가, 응답 지연이 매출에 영향을 주는가, 모델 장애가 나면 고객센터와 영업팀 업무가 멈추는가. 이 글은 스타트업 대표, 정부지원사업 수행팀, PM, 마케터, 비기술 임원이 LLM 배포 방식을 판단할 수 있도록 퍼블릭 API, 프라이빗 클라우드/VPC, 온프레미스, 하이브리드 구조를 실무 기준으로 비교합니다.
1. 먼저 ‘어떤 AI 업무인가’를 나눠야 한다
LLM 배포 논의가 꼬이는 가장 흔한 이유는 챗봇, RAG, 문서 요약, AI 에이전트를 한 덩어리로 보기 때문입니다. 같은 LLM을 써도 공개 홈페이지 FAQ와 내부 계약서 검토 도구의 위험은 완전히 다릅니다. 배포 위치를 정하기 전에는 기능명이 아니라 데이터 흐름과 업무 영향도를 먼저 적어야 합니다.
| 업무 유형 | 들어가는 데이터 | 실패 시 영향 | 1차 후보 |
|---|---|---|---|
| 공개 FAQ·마케팅 초안 | 공개 웹페이지, 제품 설명, 일반 문구 | 브랜드 품질 저하, 오답 문의 증가 | 퍼블릭 API 또는 관리형 클라우드 |
| 고객 상담 챗봇 | 고객명, 연락처, 주문·계약 정보, 상담 로그 | 개인정보 노출, 민원, CS 혼선 | VPC·프라이빗 클라우드, 마스킹, 하이브리드 |
| 사내문서 RAG | 정책, 매뉴얼, 영업자료, 회의록, 권한별 문서 | 부서 간 정보 노출, 잘못된 의사결정 | VPC, 권한 연동 RAG, 일부 온프레미스 |
| 계약서·법무·인사 검토 | 계약 조건, 급여, 평가, 법률 의견 | 기밀 유출, 법적 분쟁, 내부 통제 위반 | 프라이빗 클라우드 또는 온프레미스 우선 검토 |
| AI 에이전트 | CRM, ERP, 그룹웨어, 결재, 이메일, 파일 저장소 | 잘못된 실행, 권한 남용, 데이터 삭제·발송 | 하이브리드, 도구 게이트웨이, 강한 감사 로그 |
| 대량 배치 요약·분류 | 반복 문서, 로그, 티켓, VOC | 비용 폭증, 처리 지연, 품질 편차 | 사용량에 따라 API, 클라우드 GPU, 온프레미스 비교 |
PoC의 질문은 ‘될까?’입니다. 운영의 질문은 ‘민감데이터를 어디까지 보낼 수 있고, 비용과 장애를 누가 책임질 것인가?’입니다.
2. 네 가지 배포 선택지의 현실적인 차이
① 퍼블릭 LLM API
OpenAI, Anthropic, Google, 기타 모델 API처럼 인터넷을 통해 모델을 호출하는 방식입니다. 초기 개발 속도와 모델 품질 면에서 가장 유리합니다. GPU를 직접 운영하지 않아도 되고, 모델 업데이트도 제공자가 처리합니다. 단점은 입력·출력·로그·장애·요금 정책을 외부 제공자의 조건에 맞춰야 한다는 점입니다. 주요 기업용 API는 고객 데이터를 기본적으로 모델 학습에 사용하지 않는다고 명시하는 경우가 많지만, 보관 기간, 남용 탐지 로그, 리전, 미리보기 기능, 하위 처리자, Zero Data Retention 적용 가능 여부는 서비스와 계약에 따라 다릅니다. ([openai.com](https://openai.com/enterprise-privacy/?utm_source=openai))
② 프라이빗 클라우드 또는 VPC 기반 관리형 LLM
AWS Bedrock, Microsoft Foundry·Azure OpenAI, Google Vertex AI 같은 관리형 서비스를 VPC, PrivateLink, Private Endpoint, Private Service Connect 등과 묶어 쓰는 방식입니다. 인터넷 공개 경로를 줄이고, 클라우드 계정·네트워크·IAM·KMS·로그 정책 안에서 AI 기능을 운영할 수 있습니다. AWS는 Bedrock VPC 엔드포인트로 VPC 내부에서 프라이빗 연결을 만들 수 있다고 설명하고, Microsoft는 Foundry Tools 리소스에 Private Endpoint를 사용해 public endpoint 연결을 차단하고 온프레미스 네트워크에서도 VPN 또는 ExpressRoute로 연결할 수 있다고 안내합니다. Google Cloud도 Vertex AI 온라인 추론과 Vector Search에서 Private Service Connect 기반 선택지를 제공합니다. ([docs.aws.amazon.com](https://docs.aws.amazon.com/bedrock/latest/userguide/vpc-interface-endpoints.html?utm_source=openai))
③ 클라우드 GPU 셀프호스팅
퍼블릭 클라우드의 GPU 인스턴스에 오픈소스 또는 상용 모델을 직접 올리는 방식입니다. 모델 서버, 추론 엔진, 오토스케일링, GPU 드라이버, 컨테이너, 모니터링을 직접 책임집니다. 데이터는 내 클라우드 계정 안에 둘 수 있지만, 관리형 API만큼 간단하지 않습니다. 모델 품질이 충분하고 사용량이 예측 가능하며 팀에 MLOps 역량이 있으면 유효하지만, 작은 팀이 단순히 ‘데이터가 불안하다’는 이유만으로 선택하면 운영 부담이 빠르게 커집니다.
④ 온프레미스 또는 폐쇄망 LLM
사내 데이터센터, 고객사 전산실, 망분리 환경에 GPU 서버와 모델을 직접 두는 방식입니다. 데이터 반출이 불가능하거나, 국내·기관·고객사 정책상 외부 API 호출 자체가 금지되는 경우 검토합니다. 장점은 통제권입니다. 단점은 통제권만큼 책임도 커진다는 것입니다. GPU 구매·감가상각, 전력·냉각, 장애 대응, 보안 패치, 모델 업데이트, 취약점 대응, 백업, 관측성, DR, 라이선스 검토를 모두 운영 범위에 넣어야 합니다.
⑤ 하이브리드
실무에서는 하이브리드가 가장 자주 등장합니다. 예를 들어 민감정보 탐지와 마스킹은 내부에서 처리하고, 비식별화된 문장만 고성능 외부 모델로 보내는 구조가 가능합니다. 또는 사내문서 검색과 권한 검사는 VPC 안에서 수행하고, 최종 자연어 생성만 퍼블릭 API에 맡길 수 있습니다. 반대로 간단한 분류·라우팅은 로컬 소형 모델로 처리하고, 고난도 추론은 외부 프론티어 모델을 호출할 수도 있습니다. 하이브리드는 비용과 품질의 균형점이 될 수 있지만, 데이터 흐름이 복잡해지므로 로그·권한·감사 설계를 대충 하면 오히려 위험해집니다.
3. 데이터 등급별 1차 배포 후보
국내 기업은 개인정보보호법, 고객사 보안 심사, 내부 정보보호 규정, 정부지원사업 보안 산출물까지 함께 고려해야 합니다. 개인정보보호위원회는 생성형 AI 수명주기 각 단계에서 개인정보 처리와 보호 이슈를 체계화한 안내서를 공개했고, 공공부문 AI 도입에서도 입력·출력·학습데이터 과정의 개인정보 유출 방지와 접근권한 관리, 필터링 같은 안전조치를 언급했습니다. ([privacy.go.kr](https://www.privacy.go.kr/front/bbs/bbsView.do?bbsNo=BBSMSTR_000000000049&bbscttNo=20836&utm_source=openai))
| 데이터 등급 | 예시 | 권장 출발점 | 필수 통제 |
|---|---|---|---|
| L0 공개 데이터 | 홈페이지, 제품 소개, 공개 보도자료 | 퍼블릭 API 가능 | 출처 표시, 금칙어, 품질 평가 |
| L1 내부 일반 데이터 | 업무 매뉴얼, FAQ, 교육자료 | 퍼블릭 API 또는 VPC | 접근권한, 로그 보관, 문서 최신성 관리 |
| L2 개인정보 포함 | 상담로그, 회원정보, 주문내역 | VPC·프라이빗 클라우드, 마스킹 후 API | 비식별화, 보관기간, 삭제 요청 처리, DPA 검토 |
| L3 영업비밀·계약·인사 | 계약서, 제안가, 급여, 평가, 법무 검토 | 프라이빗 클라우드 또는 온프레미스 검토 | 권한별 RAG, 감사 로그, 반출 승인, 암호키 관리 |
| L4 폐쇄망·규제 핵심 | 망분리 업무, 기관 내부문서, 고위험 의사결정 | 온프레미스 또는 폐쇄형 하이브리드 | 망연계 정책, 오프라인 업데이트, 운영자 분리, 정기 점검 |
여기서 중요한 점은 ‘문서 원문’만 데이터가 아니라는 것입니다. 임베딩 벡터, 검색 결과, 프롬프트, 모델 응답, 사용자 피드백, 관리자 수정 로그, 오류 로그도 모두 관리 대상입니다. RAG를 준비한다면 LLM 데이터 거버넌스 기준처럼 데이터 수명주기와 권한 기준을 먼저 정리해두는 편이 안전합니다.
4. 온프레미스 vs 클라우드 LLM 판단 매트릭스
아래 표는 ‘어느 방식이 더 좋다’가 아니라 ‘어떤 조건에서 위험이 커지는가’를 보기 위한 매트릭스입니다. 각 항목을 1~5점으로 매기고, 우리 조직에서 중요한 항목에 가중치를 두면 됩니다. 금융·의료·공공·대기업 납품형 B2B라면 데이터 통제와 감사 가능성의 가중치가 높고, 초기 SaaS라면 출시 속도와 모델 품질, 비용 예측성이 더 중요할 수 있습니다.
| 판단 기준 | 퍼블릭 API | VPC·프라이빗 클라우드 | 온프레미스 | 하이브리드 |
|---|---|---|---|---|
| 초기 개발 속도 | 가장 빠름 | 보안·네트워크 설정 필요 | 가장 느림 | 설계가 필요하지만 단계적 도입 가능 |
| 최신 모델 품질 | 대체로 유리 | 제공 모델 범위에 의존 | 선택 모델 품질에 제한 가능 | 고난도 작업만 외부 모델 사용 가능 |
| 데이터 통제권 | 계약·정책 의존 | 클라우드 계정·네트워크 통제 강화 | 가장 강함 | 데이터 등급별 분리 가능 |
| 운영 책임 | 애플리케이션 중심 | 앱·네트워크·클라우드 보안 책임 증가 | 모델·GPU·인프라까지 직접 책임 | 경계별 책임 정의가 필수 |
| 비용 구조 | 사용량 기반 OPEX | 사용량+클라우드 리소스 OPEX | CAPEX+운영비+인력비 | 민감도와 사용량별 최적화 가능 |
| 지연시간 | 외부 네트워크와 모델 대기열 영향 | 리전·전용 연결로 개선 가능 | 내부망에서는 유리할 수 있으나 GPU 포화 위험 | 라우팅 설계에 따라 편차 큼 |
| 감사·로그 | 제공자 기능과 자체 로그 조합 | 클라우드 감사 로그 연계 용이 | 직접 설계해야 함 | 전 구간 상관관계 추적이 핵심 |
| 폐쇄망·고객사 심사 | 불리할 수 있음 | 심사 조건에 따라 가능 | 가장 설명하기 쉬움 | 외부 호출 차단 구간을 분리해야 함 |
| 스케일 확장 | 간단하지만 비용 급증 가능 | 클라우드 용량과 쿼터 관리 필요 | 증설 리드타임 큼 | 피크는 클라우드, 상시는 내부 처리 가능 |
실무적으로는 다음 세 질문 중 두 개 이상에 ‘예’라면 온프레미스 또는 폐쇄형 하이브리드를 진지하게 검토해야 합니다. 첫째, 원문 데이터가 외부 네트워크로 나가면 안 되는가. 둘째, 고객사 또는 규정상 외부 API 호출 자체가 보안 심사에서 막히는가. 셋째, LLM 사용량이 높고 예측 가능해서 GPU 활용률을 지속적으로 유지할 수 있는가. 반대로 이 세 조건이 모두 아니라면 처음부터 온프레미스 장비를 사는 결정보다 VPC·프라이빗 클라우드·마스킹 기반 API가 더 합리적일 수 있습니다.
5. 비용은 ‘토큰 단가’가 아니라 TCO로 봐야 한다
2026년 온프레미스와 클라우드 생성형 AI 비용 논의는 단순 API 단가 비교보다 CAPEX, OPEX, 장비 수명, GPU 활용률, 인력 운영비를 함께 보는 방향으로 정리되고 있습니다. 다만 벤더 백서마다 가정이 다르기 때문에 특정 숫자를 그대로 가져오기보다 우리 서비스의 실제 요청량, 피크 패턴, 응답 길이, 재시도율, 모델 업데이트 빈도를 넣어 계산해야 합니다. ([lenovopress.lenovo.com](https://lenovopress.lenovo.com/lp2368-on-premise-vs-cloud-generative-ai-total-cost-of-ownership-2026-edition?utm_source=openai))
| 비용 항목 | 클라우드·API에서 보는 것 | 온프레미스에서 보는 것 | 놓치기 쉬운 질문 |
|---|---|---|---|
| 추론 비용 | 입력·출력 토큰, 모델별 단가, 캐시 | GPU 감가상각, 동시 처리량, 활용률 | 평균 응답 길이가 길어지면 월 비용이 얼마나 늘어나는가 |
| RAG 비용 | 임베딩 API, 벡터DB, 검색, 재랭킹 | 벡터DB 서버, 색인 배치, 스토리지 | 문서 업데이트 주기가 짧은가, 권한별 색인이 필요한가 |
| 운영 인력 | API 연동·모니터링·프롬프트 운영 | MLOps, GPU, 보안, 네트워크, 장애 대응 | 담당자가 퇴사하면 누가 복구할 수 있는가 |
| 보안·컴플라이언스 | DPA, 리전, 로그, 키 관리, 접근통제 | 물리보안, 패치, 취약점, 감사 증적 | 고객사 보안 심사 자료를 누가 작성하는가 |
| 장애·DR | 제공자 SLA와 멀티 리전 설계 | 예비 장비, 백업, 이중화, 부품 조달 | 모델 서버가 멈추면 업무가 몇 시간까지 견딜 수 있는가 |
월 비용을 단순화하면 다음과 같습니다. LLM 운영비 = 추론 비용 + 임베딩·검색 비용 + 로그·관측성 비용 + 보안·컴플라이언스 비용 + 운영 인력비 + 장애 대응 비용입니다. API 비용만 보이면 온프레미스가 싸 보이고, GPU 견적만 보면 클라우드가 비싸 보입니다. 하지만 실무에서는 이용량이 낮은 온프레미스 GPU가 가장 비싼 선택이 되기도 하고, 통제 없는 API 호출이 월말 비용 폭탄이 되기도 합니다.
- 온프레미스가 유리해질 수 있는 경우: 사용량이 높고 예측 가능하며, 동일한 모델을 장기간 쓰고, 내부 운영팀이 있으며, 데이터 반출 제한이 명확한 경우.
- 클라우드·API가 유리한 경우: 사용량이 아직 검증되지 않았고, 최신 모델 품질이 중요하며, 출시 일정이 빠듯하고, GPU 운영 인력이 없는 경우.
- 하이브리드가 유리한 경우: 민감도 높은 데이터와 낮은 데이터가 섞여 있고, 일부 업무는 지연시간이 중요하지만 일부 업무는 품질이 더 중요한 경우.
6. 지연시간은 배포 위치보다 병목 분해가 먼저다
온프레미스에 두면 무조건 빠르고, 외부 API는 무조건 느리다는 식의 판단은 위험합니다. LLM 응답속도는 네트워크 왕복 시간, 인증·권한 검사, RAG 검색, 재랭킹, 프롬프트 길이, 모델 큐 대기, 토큰 생성 속도, 스트리밍 UI, 재시도 정책이 합쳐진 결과입니다. 내부망에 모델을 둬도 GPU가 포화되면 느리고, 외부 API를 써도 프롬프트를 줄이고 캐시를 적용하면 충분히 빠를 수 있습니다. 세부 병목을 보는 방법은 LLM 응답속도 최적화 가이드와 함께 검토하면 좋습니다.
| 병목 지점 | 증상 | 개선 방향 |
|---|---|---|
| 프롬프트 과다 | 입력 토큰 증가, 비용·지연 동시 증가 | 문서 청킹, 요약 캐시, 컨텍스트 압축 |
| RAG 검색 지연 | 모델 호출 전 대기 길어짐 | 인덱스 튜닝, 하이브리드 검색, 재랭킹 범위 제한 |
| 모델 큐 대기 | 피크 시간 응답 급증 | 쿼터 증설, 모델 라우팅, 배치·온라인 분리 |
| 네트워크 경로 | 특정 지역·망에서 느림 | 리전 선택, 전용 연결, 프라이빗 엔드포인트 |
| 에이전트 도구 호출 | CRM·ERP 호출이 누적되어 느림 | 도구 호출 상한, 병렬화, 승인 단계 분리 |
7. 보안 판단: ‘학습에 쓰이나’보다 넓게 봐야 한다
많은 기업이 첫 질문으로 ‘우리 데이터가 모델 학습에 쓰이나요?’를 묻습니다. 중요한 질문이지만 그것만으로 충분하지 않습니다. OpenAI, AWS, Microsoft, Google 같은 주요 제공자는 기업용 서비스에서 고객 입력·출력을 기본적으로 모델 학습에 쓰지 않거나 고객의 허가 없이는 학습·파인튜닝에 사용하지 않는다고 설명합니다. 그러나 실제 도입에서는 데이터 보관 기간, 남용 탐지 로그, 사람 검토 가능성, 리전, 키 관리, ZDR 적용 가능 여부, 미리보기 기능의 제한, 하위 처리자, 계약상 삭제 요청 절차까지 확인해야 합니다. ([openai.com](https://openai.com/enterprise-privacy/?utm_source=openai))
또 하나의 보안 축은 LLM 애플리케이션 자체입니다. OWASP의 LLM 애플리케이션 보안 자료는 프롬프트 인젝션, RAG를 통한 악성 지시 삽입, 과도한 에이전트 권한 같은 위험을 반복해서 강조합니다. 이는 모델을 온프레미스에 둔다고 사라지지 않습니다. 내부 문서에 악성 문구가 들어가 검색되는 순간, 사내 RAG도 프롬프트 인젝션의 영향을 받을 수 있습니다. ([genai.owasp.org](https://genai.owasp.org/llm-top-10/?cat=253&utm_source=openai))
- 입력 데이터: 개인정보·영업비밀·계약 조건이 포함되는가.
- 중간 데이터: 임베딩, 검색 결과, 프롬프트 조합본, 캐시가 어디에 저장되는가.
- 출력 데이터: 모델 응답이 고객에게 바로 나가는가, 사람 검토가 있는가.
- 로그 데이터: 원문 프롬프트와 응답을 그대로 저장하는가, 마스킹하는가.
- 권한 데이터: 사용자가 볼 수 없는 문서가 RAG 검색에 섞이지 않는가.
- 도구 권한: AI 에이전트가 조회만 하는가, 수정·발송·삭제도 하는가.
8. 운영 책임: 누구의 장애인가
NIST AI RMF와 생성형 AI 프로파일은 AI 시스템을 수명주기 전반에서 거버넌스와 위험관리 대상으로 보고, 실제 배포 환경과 유사한 조건에서 성능·보증 기준을 측정하며, RAG·파인튜닝 같은 적용 방식과 제3자 생성형 AI 기술의 사고 대응 책임을 문서화할 것을 제시합니다. 이 관점에서 배포 방식은 기술 선택이 아니라 책임 배분표입니다. ([nist.gov](https://www.nist.gov/itl/ai-risk-management-framework?utm_source=openai))
| 운영 영역 | 퍼블릭 API | VPC·프라이빗 클라우드 | 온프레미스 |
|---|---|---|---|
| 모델 가용성 | 제공자 장애+내 앱 장애를 함께 관리 | 제공자 서비스와 내 클라우드 구성을 함께 관리 | 모델 서버·GPU·네트워크까지 직접 관리 |
| 모델 업데이트 | 모델 버전 변경 영향 테스트 필요 | 배포 모델·리전·쿼터 관리 필요 | 새 모델 검증, 양자화, 배포, 롤백 직접 수행 |
| 보안 패치 | 앱·키·권한 중심 | 앱+클라우드 IAM·네트워크 중심 | OS, 드라이버, 런타임, 모델 서버까지 포함 |
| 품질 평가 | 프롬프트·모델 변경 시 회귀 테스트 | 동일 | 모델 자체 변경과 서버 설정까지 평가 |
| 비용 통제 | 토큰·요청량·사용자별 쿼터 | 토큰+클라우드 리소스 | GPU 활용률, 증설, 전력, 인력비 |
| 감사 대응 | 제공자 증적+자체 로그 | 클라우드 감사 로그와 연계 | 전부 자체 증적화 |
특히 AI 에이전트는 단순 챗봇보다 운영 책임이 큽니다. 모델 응답만 기록하면 부족하고, 어떤 문서를 검색했는지, 어떤 도구를 호출했는지, 어떤 권한으로 CRM이나 ERP에 접근했는지, 비용이 어느 고객사·부서에서 발생했는지까지 남겨야 합니다. 이런 운영 기준은 AI 에이전트 관측성 가이드와 함께 설계하는 편이 좋습니다.
9. 실무에서 많이 쓰는 하이브리드 패턴
패턴 A. 민감정보 제거 후 외부 모델 호출
고객명, 전화번호, 주민등록번호, 계좌번호, 이메일, 계약금액 같은 값을 내부 프록시에서 탐지·마스킹한 뒤 외부 모델을 호출합니다. 응답을 받은 뒤 필요하면 내부 시스템에서 원래 값을 복원합니다. 단, 마스킹 품질이 낮으면 위험이 남고, 문맥만으로 개인이 식별되는 경우도 있어 주의해야 합니다.
패턴 B. RAG와 원문은 내부, 생성은 외부
원문 문서와 벡터DB는 VPC 또는 온프레미스에 두고, 검색 결과 중 필요한 최소 문단만 외부 모델에 보냅니다. 이 구조는 초기 SaaS와 B2B 업무 도구에서 현실적입니다. 다만 검색 결과 자체가 민감정보라면 외부 전송 전에 다시 등급 판단을 해야 합니다.
패턴 C. 소형 로컬 모델로 라우팅, 고성능 모델로 추론
간단한 의도 분류, 욕설·PII 탐지, 내부/외부 라우팅은 로컬 소형 모델로 처리하고, 복잡한 보고서 작성이나 추론은 고성능 API를 호출합니다. 비용과 보안 사이의 균형을 잡을 수 있지만, 라우터 모델이 잘못 분류하면 민감데이터가 잘못된 경로로 갈 수 있으므로 샘플링 감사가 필요합니다.
패턴 D. AI 에이전트 도구 게이트웨이
LLM이 ERP, CRM, 그룹웨어를 직접 호출하지 않게 하고, 중간에 도구 게이트웨이를 둡니다. 이 게이트웨이는 허용된 액션, 파라미터 검증, 사용자 권한, 승인 필요 여부, 호출 횟수 제한, 감사 로그를 관리합니다. 에이전트가 ‘메일 보내기’나 ‘계약 상태 변경’ 같은 액션을 할 때는 사람 승인 단계를 두는 것이 안전합니다.
패턴 E. 온라인은 안정 경로, 배치는 비용 최적 경로
고객이 기다리는 실시간 챗봇은 지연이 낮은 관리형 API나 VPC 경로를 쓰고, 야간 문서 요약·분류 배치는 클라우드 GPU나 온프레미스 여유 자원을 활용합니다. 같은 기능도 온라인과 배치의 요구사항이 다르므로 하나의 배포 방식으로 묶을 필요가 없습니다.
10. 도입 전 체크리스트
A. 퍼블릭 API를 계속 써도 되는 경우
- 원문 데이터가 공개 정보이거나 내부 일반 정보 수준이다.
- 개인정보·영업비밀은 사전에 제거하거나 샘플 데이터만 사용한다.
- API 약관, 학습 사용 여부, 보관 기간, 삭제 정책을 확인했다.
- 월 사용량 상한, 사용자별 쿼터, 비용 알림을 설정할 수 있다.
- 모델 장애 시 수동 업무 또는 대체 모델로 우회할 수 있다.
B. VPC·프라이빗 클라우드로 올릴 시점
- 고객사 보안 심사에서 public endpoint 호출을 문제 삼는다.
- 데이터는 클라우드 안에 둘 수 있지만 인터넷 공개 경로는 줄여야 한다.
- IAM, KMS, 감사 로그, 네트워크 보안그룹을 기존 클라우드 정책과 맞춰야 한다.
- RAG 원문, 벡터DB, 관리자 로그를 같은 계정·리전 정책 안에서 관리해야 한다.
- 서비스가 이미 AWS, Azure, GCP 중 하나에 운영되고 있어 네트워크 통합 효과가 있다.
C. 온프레미스를 검토해야 하는 경우
- 계약·규정·고객사 정책상 데이터 외부 반출이 불가능하다.
- 망분리 또는 폐쇄망에서만 동작해야 한다.
- GPU와 모델 서버를 24시간 안정적으로 운영할 인력이 있다.
- 장비 구매 후에도 모델 품질이 서비스 요구사항을 충족한다.
- 업데이트, 취약점, 백업, DR, 감사 증적을 자체적으로 운영할 예산이 있다.
D. 어떤 방식을 택해도 필요한 문서
- 데이터 흐름도: 입력, 검색, 프롬프트, 응답, 로그, 삭제 경로.
- 모델 사용 정책: 허용 업무, 금지 데이터, 사용자 권한, 검토 절차.
- 비용 산정표: 요청 수, 평균 토큰, 피크, 캐시, 임베딩, 벡터DB, 로그 비용.
- 장애 대응표: 모델 장애, 네트워크 장애, 비용 한도 초과, 보안 사고 대응.
- 평가 데이터셋: 정확도, 환각, 보안 위반, 응답속도, 비용을 반복 측정할 샘플.
11. 정부지원사업·초기 SaaS에서의 현실적 권장안
정부지원사업이나 초기 SaaS MVP에서는 처음부터 온프레미스 GPU 서버를 구매하는 결정보다, 데이터 등급을 낮추고 실사용 지표를 검증하는 편이 대체로 안전합니다. 사업계획서에는 ‘향후 고객사 보안 요구에 따라 VPC 또는 온프레미스 전환 가능 구조’라고 쓰되, 실제 1차 구현은 마스킹된 샘플 데이터, API 사용량 제한, 관리자 로그, 삭제 기능, 접근권한을 갖춘 형태로 시작할 수 있습니다.
다만 B2B 납품 대상이 금융, 공공, 제조 보안망, 의료, 대기업 내부 시스템이라면 초기부터 아키텍처 로드맵을 분리해야 합니다. 예를 들어 1단계는 클라우드 API 기반 데모, 2단계는 VPC 기반 RAG, 3단계는 고객사별 온프레미스 옵션으로 구분합니다. 이렇게 하면 MVP 예산을 과도하게 쓰지 않으면서도 고객사 보안 심사에서 ‘나중에 다시 만들겠습니다’가 아니라 ‘전환 가능한 구조로 설계했습니다’라고 설명할 수 있습니다.
관리자 화면도 빠뜨리면 안 됩니다. AI 기능은 프론트 챗봇보다 운영 화면이 중요합니다. 어떤 사용자가 어떤 문서를 물었는지, 어떤 모델을 호출했는지, 비용이 얼마나 나왔는지, 민감정보 필터가 작동했는지, 사람이 수정한 답변은 무엇인지가 보여야 합니다. 이런 운영 화면이 없으면 배포 위치와 상관없이 실서비스 운영이 어려워집니다.
12. AgentMit/BizMit 관점의 제안
AgentMit은 퍼블릭 API, VPC, 온프레미스 중 하나를 무조건 권하지 않습니다. 먼저 업무 유형과 데이터 등급을 나누고, 그다음 RAG 원문 저장소, 벡터DB, 모델 호출 경로, 관리자 로그, 비용 한도, 권한 구조를 함께 봅니다. BizMit처럼 SaaS·업무 자동화·관리자 대시보드·AI 에이전트가 결합되는 프로젝트에서는 LLM 자체보다 주변 시스템 설계가 더 중요해지는 경우가 많습니다.
이미 PoC를 만들어본 팀이라면 다음 산출물부터 정리해보십시오. 데이터 등급표, 현재 API 호출 로그, 평균 입력·출력 토큰, 고객사 보안 요구사항, 예상 월 사용자 수, RAG 대상 문서 목록, 관리자에게 필요한 감사 항목입니다. 이 자료가 있으면 배포 방식 논의가 추상적인 보안 논쟁이 아니라 비용·지연시간·운영 책임을 비교하는 의사결정으로 바뀝니다. RAG, AI 에이전트, 내부 업무 시스템 연동까지 포함해 설계와 구현 검토가 필요하다면 AgentMit에 아키텍처 리뷰 또는 MVP 구현 범위를 문의할 수 있습니다.
FAQ
Q1. 기업 챗봇은 무조건 온프레미스 LLM으로 구축해야 안전한가요?
아닙니다. 공개 FAQ, 마케팅 초안, 일반 고객 응대처럼 민감정보가 거의 없는 업무는 퍼블릭 API도 충분할 수 있습니다. 다만 개인정보, 계약서, 내부 결재 문서, 의료·금융·인사 데이터가 포함되면 VPC, 프라이빗 클라우드, 온프레미스, 데이터 마스킹을 함께 검토해야 합니다.
Q2. 퍼블릭 LLM API를 쓰면 입력한 데이터가 모델 학습에 사용되나요?
주요 기업용 API와 엔터프라이즈 상품은 기본적으로 고객 입력·출력을 모델 학습에 사용하지 않는다고 명시하는 경우가 많습니다. 그러나 서비스 종류, 계약, 리전, 보관 기간, 남용 탐지 로그, 미리보기 기능 여부에 따라 조건이 다를 수 있으므로 도입 시점의 약관과 DPA를 반드시 확인해야 합니다.
Q3. 온프레미스 LLM이 클라우드 API보다 비용이 저렴해지는 기준은 무엇인가요?
대체로 호출량이 높고 예측 가능하며 GPU 활용률을 유지할 수 있고, 내부에 MLOps·보안·인프라 운영 인력이 있을 때 검토 가치가 커집니다. 반대로 사용량이 들쭉날쭉하거나 최신 모델 품질이 중요하고 운영 인력이 부족하면 API 또는 관리형 VPC가 더 현실적일 수 있습니다.
Q4. RAG 시스템은 모델만 온프레미스에 두면 보안 문제가 해결되나요?
해결되지 않습니다. 원문 문서, 임베딩, 벡터DB, 검색 로그, 프롬프트, 출력, 관리자 다운로드 로그까지 모두 데이터 흐름에 포함됩니다. 특히 RAG는 문서 권한을 검색 시점에 다시 확인하고, 퇴사자·부서이동·고객사별 접근권한을 반영해야 합니다.
Q5. 초기 SaaS나 정부지원사업 MVP에서는 어떤 배포 방식을 권장하나요?
처음부터 온프레미스 GPU를 사기보다 데이터 등급을 낮추고, 마스킹·샘플 데이터·사용량 제한·관리자 로그를 갖춘 클라우드 API 또는 VPC 구조로 시작하는 편이 현실적입니다. 단, 사업 특성상 폐쇄망·국내 리전·고객사 보안 심사가 필수라면 MVP 단계부터 하이브리드 전환 로드맵을 견적과 산출물에 포함해야 합니다.
참고 자료
이 글은 특정 벤더의 가격이나 성능을 단정하지 않고, 공개 문서에서 확인 가능한 보안·프라이버시·네트워크·위험관리 기준을 의사결정 프레임으로 재구성했습니다. 참고한 주요 자료는 NIST AI RMF와 생성형 AI 프로파일, OWASP LLM Top 10, 주요 클라우드·LLM 제공자의 기업용 데이터 처리 문서, 개인정보보호위원회의 생성형 AI 개인정보 처리 안내서, 2026년 온프레미스·클라우드 AI TCO 비교 자료입니다. ([nist.gov](https://www.nist.gov/itl/ai-risk-management-framework?utm_source=openai))
