26장. 클라우드 AI와 로컬 AI를 함께 쓰기

1. 하나만 선택할 필요는 없다

앞 장에서는 로컬 RAG를 만드는 방법을 살펴보았다.

로컬 RAG는 사내 문서, 운영 매뉴얼, 보안 정책, 개발 문서처럼 외부로 보내기 어려운 자료를 내부에서 검색하고, 로컬 LLM으로 답변을 생성하는 구조다.

로컬 RAG는 데이터 통제 측면에서 장점이 있다.
하지만 모든 작업을 로컬 AI로 처리하는 것이 항상 좋은 선택은 아니다.

로컬 AI에는 다음과 같은 한계가 있다.

- 모델 품질이 클라우드 고성능 모델보다 낮을 수 있다.
- 긴 문서나 복잡한 추론에 약할 수 있다.
- GPU, VRAM, 서버 운영 부담이 있다.
- 동시 요청 처리에 한계가 있다.
- 모델 업데이트와 장애 대응을 직접 해야 한다.

반대로 클라우드 AI에도 한계가 있다.

- 사용량이 많아지면 비용이 증가한다.
- 민감 정보를 외부로 보내기 어렵다.
- 외부 API 장애에 영향을 받을 수 있다.
- 지연시간이 길어질 수 있다.
- 특정 제공자에 종속될 수 있다.

그래서 실무에서는 둘 중 하나만 선택하기보다 함께 사용하는 구조가 현실적이다.

민감한 데이터:
로컬 AI

복잡한 분석:
클라우드 AI

반복적인 단순 작업:
로컬 AI

높은 품질이 필요한 초안:
클라우드 AI

외부 API 장애 시:
로컬 AI fallback

이렇게 클라우드 AI와 로컬 AI를 함께 사용하는 구조를 하이브리드 AI 구조라고 볼 수 있다.

이 장에서는 클라우드 AI와 로컬 AI를 어떻게 역할 분담할 수 있는지,
어떤 기준으로 모델을 선택할 수 있는지,
그리고 하이브리드 구조를 설계할 때 무엇을 주의해야 하는지 살펴본다.

2. 하이브리드 AI란 무엇인가

하이브리드 AI는 하나의 AI 제공 방식만 사용하지 않고, 작업의 성격에 따라 여러 AI 실행 환경을 조합하는 구조다.

예를 들어 다음과 같은 조합이 가능하다.

- 클라우드 LLM + 로컬 임베딩 모델
- 로컬 RAG + 클라우드 LLM
- 로컬 LLM + 클라우드 fallback
- 저비용 클라우드 모델 + 고성능 클라우드 모델
- 사내 GPU 서버 + 외부 AI API

하이브리드 AI의 핵심은 “어떤 요청을 어디로 보낼 것인가”를 판단하는 것이다.

사용자 요청
→ 데이터 민감도 확인
→ 작업 복잡도 확인
→ 비용 기준 확인
→ 지연시간 요구사항 확인
→ 로컬 또는 클라우드 모델 선택

예를 들어 고객 문의 요약 기능을 생각해보자.

문의 원문에 개인정보가 포함되어 있다면 바로 클라우드 AI로 보내기 부담스러울 수 있다.

이때 로컬에서 먼저 개인정보를 마스킹한 뒤 클라우드 AI로 요약할 수 있다.

고객 문의 원문
→ 로컬 마스킹
→ 개인정보 제거
→ 클라우드 AI 요약
→ 상담원 화면 표시

또는 간단한 문의는 로컬 모델이 요약하고, 복잡한 문의만 클라우드 모델로 보낼 수도 있다.

짧고 단순한 문의:
로컬 모델 요약

길고 복잡한 문의:
클라우드 고성능 모델 요약

하이브리드 AI는 특정 기술을 고집하는 구조가 아니다.
업무 목적, 보안, 비용, 품질, 속도에 따라 AI 실행 위치를 선택하는 구조다.

3. 하이브리드 AI가 필요한 이유

하이브리드 AI가 필요한 이유는 단순하다.

AI 기능마다 요구사항이 다르기 때문이다.

예를 들어 다음 작업들을 비교해보자.

고객 문의 1건 요약
장애 로그 원인 분석
사내 보안 문서 검색
채팅 메시지 유해성 분류
임원 보고서 초안 작성
실시간 방송 자막 보정

이 작업들은 모두 AI를 사용할 수 있지만, 요구사항은 다르다.

하나의 모델로 모든 요구사항을 만족시키기는 어렵다.

고성능 클라우드 모델은 품질은 좋지만 비용과 데이터 전송 문제가 있다.
로컬 모델은 데이터 통제에 좋지만 복잡한 추론 품질이 부족할 수 있다.
작은 모델은 빠르지만 긴 문서 분석에는 약할 수 있다.

따라서 기능별로 적절한 AI 실행 위치를 선택해야 한다.

빠르고 단순한 작업:
작은 로컬 모델

품질이 중요한 작업:
고성능 클라우드 모델

민감 정보가 있는 작업:
로컬 모델 또는 마스킹 후 클라우드 모델

반복 요청이 많은 작업:
로컬 모델 또는 캐시

실패해도 되는 보조 기능:
클라우드 AI 단독 가능

실패하면 안 되는 기능:
fallback 구조 필요

하이브리드 AI는 복잡해 보이지만, 실무 요구사항을 반영하면 자연스럽게 등장하는 구조다.

4. 데이터 민감도에 따른 분리

하이브리드 AI에서 가장 먼저 볼 기준은 데이터 민감도다.

AI에게 보내는 데이터에 민감 정보가 포함되어 있다면 외부 클라우드 AI로 바로 보내기 어렵다.

민감 정보에는 다음이 포함될 수 있다.

- 이름
- 전화번호
- 이메일
- 결제 정보
- 계정 정보
- 인증 토큰
- 세션 ID
- 운영 로그
- 내부 소스 코드
- 보안 정책
- 비공개 회의록

데이터 민감도에 따라 처리 방식을 나눌 수 있다.

예를 들어 고객 문의 요약 기능은 다음처럼 구성할 수 있다.

고객 문의 원문
→ 개인정보 탐지
→ 이름, 전화번호, 이메일 마스킹
→ 클라우드 AI 요약

반대로 보안 로그 분석은 로컬 AI로 제한할 수 있다.

보안 로그
→ 내부 AI 서버
→ 로컬 모델 분석
→ 보안 담당자에게 결과 표시

중요한 원칙은 다음이다.

AI 모델을 선택하기 전에,
먼저 데이터가 어디까지 이동해도 되는지 정해야 한다.

모델 성능보다 데이터 처리 기준이 먼저다.

5. 작업 복잡도에 따른 분리

두 번째 기준은 작업 복잡도다.

작업이 단순하면 작은 모델이나 로컬 모델로도 충분할 수 있다.

예를 들어 다음 작업은 비교적 단순하다.

- 짧은 문장 분류
- 감정 분류
- 스팸 여부 판단
- 문의 유형 분류
- 짧은 요약
- 키워드 추출

이런 작업은 출력도 짧고, 복잡한 추론이 필요하지 않은 경우가 많다.

{
  "category": "payment",
  "priority": "high"
}

반대로 다음 작업은 복잡하다.

- 장애 로그와 배포 이력을 함께 보고 원인 후보 분석
- 여러 정책 문서를 종합해 답변
- 대형 PR 코드 리뷰
- 법무 문서 요약
- 임원 보고서 초안 작성
- 장기 대화 맥락을 고려한 답변

이런 작업은 고성능 모델이 필요할 수 있다.

작업 복잡도에 따라 다음처럼 나눌 수 있다.

예를 들어 고객 문의를 먼저 로컬 모델로 분류한 뒤, 복잡한 문의만 클라우드 모델로 넘길 수 있다.

고객 문의 입력
→ 로컬 모델로 유형 분류
→ 단순 문의는 로컬 요약
→ 복잡하거나 중요도 높은 문의는 클라우드 모델 분석

이 구조는 비용을 줄이면서 품질도 확보할 수 있다.

6. 비용에 따른 분리

세 번째 기준은 비용이다.

모든 요청을 고성능 클라우드 모델로 보내면 비용이 커진다.

특히 요청량이 많은 기능은 비용이 빠르게 증가한다.

- 모든 채팅 메시지 분석
- 모든 고객 문의 자동 분류
- 모든 PR 코드 리뷰
- 모든 문서 요약
- 사내 챗봇의 반복 질문

이런 작업은 다음 방식으로 비용을 줄일 수 있다.

- 단순 작업은 로컬 모델로 처리한다.
- 반복 질문은 캐싱한다.
- 고성능 모델은 필요한 경우에만 사용한다.
- 입력 데이터를 줄인다.
- 로컬 모델로 1차 처리 후 클라우드 모델로 보강한다.

예를 들어 문서 검색 챗봇에서 모든 질문을 고성능 모델로 보내지 않을 수 있다.

간단한 FAQ 질문:
로컬 RAG 답변

복잡한 정책 비교 질문:
클라우드 고성능 모델 사용

문서에 답이 없는 질문:
LLM 호출 없이 문서 없음 안내

또는 코드 리뷰에서도 분리할 수 있다.

작은 PR:
로컬 코드 모델로 1차 리뷰

중요 PR:
클라우드 고성능 모델로 추가 리뷰

자동 생성 파일:
AI 리뷰 제외

비용 최적화의 핵심은 “무조건 싼 모델을 쓰는 것”이 아니다.

비용이 낮아도 품질이 부족하면 업무에 쓸 수 없다.
품질이 좋아도 모든 요청에 쓰면 비용이 커진다.

하이브리드 AI는 필요한 곳에 필요한 수준의 모델을 사용하는 구조다.

7. 지연시간에 따른 분리

네 번째 기준은 지연시간이다.

AI 기능마다 허용 가능한 응답 시간이 다르다.

예를 들어 고객 문의 요약은 몇 초 정도 걸려도 괜찮을 수 있다.

상담원:
요약 버튼 클릭
→ 3~5초 후 요약 표시

하지만 실시간 채팅 필터링은 더 빠른 응답이 필요하다.

채팅 메시지 입력
→ 즉시 위험 여부 판단
→ 노출 여부 결정

실시간 방송 자막이나 번역은 지연시간이 더 중요하다.

방송 음성 입력
→ 자막 생성
→ 번역
→ 화면 표시

이런 기능에 외부 클라우드 AI를 사용하면 네트워크 지연과 모델 응답 시간이 문제가 될 수 있다.

지연시간 기준으로 나누면 다음과 같다.

실시간성이 높을수록 로컬 처리나 경량 모델이 유리할 수 있다.

하지만 로컬 모델 품질이 부족하다면 하이브리드 구조를 사용할 수 있다.

실시간 1차 처리:
로컬 모델

사후 정밀 분석:
클라우드 모델

예를 들어 실시간 방송 자막에서는 로컬 STT나 경량 모델로 빠르게 1차 결과를 만들고, 이후 클라우드 모델로 보정하는 구조를 생각할 수 있다.

방송 음성
→ 로컬 STT 1차 변환
→ 빠른 자막 표시
→ 클라우드 AI로 사후 보정 또는 요약

지연시간이 중요한 기능은 품질만 보고 모델을 선택하면 안 된다.

8. 기본은 로컬, 고성능은 클라우드

하이브리드 AI의 한 가지 전략은 “기본은 로컬, 어려운 작업은 클라우드”다.

이 방식은 다음 상황에 적합하다.

- 비용을 줄이고 싶다.
- 대부분의 요청은 단순하다.
- 일부 요청만 고성능 모델이 필요하다.
- 민감 정보는 먼저 내부에서 처리하고 싶다.

예를 들어 고객 문의 처리 시스템을 생각해보자.

1. 고객 문의가 들어온다.
2. 로컬 모델이 문의 유형을 분류한다.
3. 단순 문의는 로컬 모델이 요약한다.
4. 복잡하거나 중요도가 높은 문의는 클라우드 모델로 보낸다.
5. 상담원이 최종 검토한다.

이 구조는 비용과 품질을 함께 고려한다.

단순 문의 80%:
로컬 처리

복잡 문의 20%:
클라우드 처리

장점은 다음과 같다.

- 클라우드 AI 호출 수를 줄일 수 있다.
- 민감 정보를 먼저 내부에서 정리할 수 있다.
- 고성능 모델은 필요한 경우에만 사용한다.
- 장애 시 로컬 처리만으로 최소 기능을 유지할 수 있다.

하지만 주의할 점도 있다.

로컬 모델이 복잡한 문의를 제대로 구분하지 못하면, 클라우드 모델로 보내야 할 요청을 놓칠 수 있다.

로컬 모델 오판:
중요 문의를 단순 문의로 판단
→ 낮은 품질의 답변 생성
→ 업무 오류 가능

따라서 라우팅 기준은 검증해야 한다.

- 로컬 모델의 분류 정확도
- 중요 요청 누락률
- 클라우드 전환 기준
- 사람이 수동으로 재분석 요청할 수 있는 버튼

“기본은 로컬, 고성능은 클라우드” 전략은 비용 최적화에 좋지만, 라우팅 품질이 중요하다.

9. 기본은 클라우드, 민감 정보만 로컬

반대 전략도 있다.

기본은 클라우드 AI를 사용하고, 민감 정보가 포함된 작업만 로컬 AI로 처리하는 방식이다.

이 방식은 다음 상황에 적합하다.

- 클라우드 AI 품질을 주로 활용하고 싶다.
- 민감 데이터 처리만 제한하고 싶다.
- 로컬 AI 운영 범위를 최소화하고 싶다.
- 빠른 개발과 운영 안정성이 중요하다.

예를 들어 사내 AI 업무 비서를 만든다고 해보자.

일반적인 질문은 클라우드 AI로 처리한다.

사용자:
REST API와 GraphQL 차이 알려줘.

처리:
클라우드 AI 사용

하지만 운영 로그나 내부 보안 문서가 포함된 요청은 로컬 AI로 처리한다.

사용자:
이 보안 로그에서 이상 징후를 요약해줘.

처리:
로컬 AI 사용

이 구조에서는 먼저 입력 데이터의 민감도를 판단해야 한다.

입력 분석
→ 개인정보, 토큰, 내부 코드 포함 여부 확인
→ 민감도 높음: 로컬 AI
→ 민감도 낮음: 클라우드 AI

장점은 다음과 같다.

- 대부분의 작업에서 클라우드 고성능 모델을 활용할 수 있다.
- 로컬 AI 운영 범위를 줄일 수 있다.
- 민감 정보 처리만 내부로 제한할 수 있다.
- 도입 초기에 현실적이다.

하지만 민감도 판단이 어렵다는 문제가 있다.

사용자 입력 안에 개인정보가 있는가?
로그 안에 토큰이 있는가?
코드 안에 비밀키가 있는가?
문서 내용이 외부 전송 가능한가?

자동 탐지만으로는 완벽하지 않을 수 있다.

따라서 다음을 함께 고려해야 한다.

- 정규식 기반 개인정보 탐지
- 비밀키 패턴 탐지
- 문서 등급 메타데이터
- 사용자 선택
- 관리자 정책
- 기본적으로 보수적인 처리

“기본은 클라우드, 민감 정보만 로컬” 전략은 빠른 도입에 좋다.
하지만 민감도 분류 정책이 반드시 필요하다.

10. AI Gateway로 모델 선택을 중앙화하기

하이브리드 AI를 제대로 운영하려면 모델 선택 로직을 중앙화하는 것이 좋다.

서비스 코드 곳곳에서 직접 로컬 모델과 클라우드 모델을 선택하면 관리가 어려워진다.

나쁜 구조는 다음과 같다.

고객 문의 서비스:
직접 클라우드 AI 호출

로그 분석 서비스:
직접 로컬 AI 호출

문서 검색 서비스:
직접 모델 선택

코드 리뷰 서비스:
직접 다른 AI API 호출

이렇게 되면 문제가 생긴다.

- 모델 변경이 어렵다.
- 비용 정책이 흩어진다.
- 로그 형식이 제각각이다.
- 권한과 보안 기준이 달라진다.
- fallback 처리가 중복된다.
- 품질 평가가 어려워진다.

좋은 구조는 AI Gateway 또는 AI Service Layer를 두는 것이다.

서비스 기능
→ AI Gateway
→ 로컬 AI
→ 클라우드 AI
→ fallback 모델

서비스 코드는 AI Gateway에 기능 목적과 입력 정보를 전달한다.

{
  "feature": "inquiry_summary",
  "input": {
    "message": "고객 문의 원문..."
  },
  "sensitivity": "medium",
  "userRole": "cs_manager"
}

AI Gateway는 내부 정책에 따라 모델을 선택한다.

if sensitivity == high:
    local model

else if feature == simple_classification:
    cheap model

else if feature == incident_analysis:
    high quality cloud model

else:
    default model

AI Gateway의 역할은 다음과 같다.

- 모델 선택
- 프롬프트 템플릿 관리
- 민감 정보 마스킹
- 비용 기록
- 사용량 제한
- 응답 검증
- fallback 처리
- 로그 표준화
- 모델 변경 이력 관리

처음부터 거대한 AI Gateway를 만들 필요는 없다.

초기에는 코드 내부의 공통 모듈로 시작해도 된다.

초기:
aiService.ts

확장:
ai-gateway 내부 API

운영:
모델 라우팅, 비용 제한, 권한, 감사 로그 포함

중요한 것은 AI 호출 정책을 서비스마다 흩어놓지 않는 것이다.

11. 모델 라우터 설계

하이브리드 AI의 핵심 구성 요소는 모델 라우터다.

모델 라우터는 요청을 보고 어떤 모델을 사용할지 결정한다.

판단 기준은 다음과 같다.

- 기능 유형
- 데이터 민감도
- 입력 길이
- 출력 품질 요구사항
- 사용자 등급
- 비용 제한
- 현재 장애 상태
- 응답 시간 요구사항

예를 들어 다음과 같은 라우팅 규칙을 만들 수 있다.

function selectModel(request) {
    if (request.sensitivity === "high") {
        return "local-secure-model";
    }

    if (request.feature === "chat_message_classification") {
        return "local-fast-model";
    }

    if (request.feature === "incident_analysis") {
        return "cloud-high-quality-model";
    }

    if (request.inputTokens > 20000) {
        return "cloud-long-context-model";
    }

    if (request.monthlyBudgetUsage > 0.8) {
        return "low-cost-model";
    }

    return "default-cloud-model";
}

이 코드는 단순한 예시다.

실제 운영에서는 더 많은 조건이 필요할 수 있다.

- 특정 모델 장애 여부
- 사용자의 요청 횟수
- 문서 등급
- 기능별 허용 모델 목록
- 관리자가 강제로 선택한 모델
- 실험군과 대조군

모델 라우터를 만들 때 주의할 점은 너무 복잡하게 시작하지 않는 것이다.

처음에는 단순한 규칙으로 충분하다.

1단계:
기능별 모델 지정

2단계:
민감도 기준 추가

3단계:
비용 기준 추가

4단계:
fallback과 A/B 테스트 추가

모델 라우터는 운영하면서 점진적으로 발전시키는 것이 좋다.

12. fallback 구조 설계

하이브리드 AI에서는 fallback 구조를 만들기 좋다.

fallback은 기본 모델이나 기본 처리 방식이 실패했을 때 사용하는 대체 경로다.

예를 들어 클라우드 AI가 장애를 일으킬 수 있다.

클라우드 모델 호출
→ timeout
→ fallback 모델 사용

또는 로컬 모델이 너무 느릴 수 있다.

로컬 모델 대기열 증가
→ 클라우드 모델로 우회

fallback 설계는 기능별로 달라야 한다.

예를 들어 문서 검색 챗봇은 다음처럼 fallback할 수 있다.

정상:
문서 검색 + AI 답변 생성

LLM 실패:
관련 문서 목록만 표시

검색 실패:
관련 문서를 찾지 못했다고 안내

권한 문제:
접근 가능한 문서가 없다고 안내

fallback을 만들 때 중요한 것은 사용자가 현재 상태를 이해할 수 있게 하는 것이다.

나쁜 메시지는 다음과 같다.

오류가 발생했습니다.

좋은 메시지는 다음과 같다.

AI 답변 생성에 실패했습니다.
대신 관련 문서 검색 결과를 표시합니다.

AI 기능은 실패할 수 있다.
하이브리드 구조의 장점은 실패 시 다른 경로를 선택할 수 있다는 것이다.

13. 하이브리드 구조의 보안 주의사항

하이브리드 AI는 강력하지만 보안 설계가 더 중요해진다.

로컬과 클라우드를 함께 쓰면 데이터 이동 경로가 복잡해지기 때문이다.

예를 들어 다음 구조를 생각해보자.

고객 문의 원문
→ 로컬 마스킹
→ 클라우드 AI 요약
→ 결과 저장

이 구조에서는 다음을 확인해야 한다.

- 로컬 마스킹이 제대로 되었는가?
- 마스킹 전 원문이 로그에 남지 않는가?
- 클라우드로 보내는 데이터에 민감 정보가 남아 있지 않은가?
- 요약 결과에 개인정보가 다시 포함되지 않는가?

또 다른 예를 보자.

사내 문서 검색
→ 내부 벡터DB
→ 검색 결과 일부를 클라우드 AI로 전달

이 구조에서는 검색된 문서가 외부로 나간다.

따라서 문서 등급에 따라 클라우드 전송 가능 여부를 판단해야 한다.

public:
클라우드 전송 가능

internal:
정책에 따라 가능

confidential:
로컬 처리

restricted:
AI 처리 금지 또는 별도 승인

하이브리드 AI 보안 원칙은 다음과 같다.

- 데이터 등급을 먼저 판단한다.
- 민감 데이터는 기본적으로 로컬 처리한다.
- 클라우드 전송 전 마스킹한다.
- 문서 권한 필터를 적용한다.
- 로그에 원문을 남기지 않는다.
- 모델 선택 이유를 기록한다.
- 사용자가 볼 수 없는 데이터는 어떤 모델에도 전달하지 않는다.

하이브리드 구조에서는 “어느 모델을 썼는가”뿐 아니라 “왜 그 모델로 보냈는가”도 추적할 수 있어야 한다.

14. 하이브리드 구조의 운영 지표

하이브리드 AI를 운영하려면 지표를 잘 봐야 한다.

단순히 전체 AI 요청 수만 보면 부족하다.

다음 지표가 필요하다.

- 로컬 모델 요청 수
- 클라우드 모델 요청 수
- 기능별 모델 사용 비율
- fallback 발생 횟수
- 모델별 응답 시간
- 모델별 실패율
- 모델별 비용
- 로컬 서버 CPU/GPU 사용률
- 로컬 서버 큐 대기 시간
- 민감 데이터 요청 비율

예를 들어 대시보드에서 다음을 볼 수 있어야 한다.

고객 문의 요약:
로컬 70%
클라우드 30%

장애 로그 분석:
로컬 40%
클라우드 60%

문서 검색 챗봇:
로컬 85%
클라우드 15%

이 지표를 보면 운영 방향을 판단할 수 있다.

클라우드 사용 비율이 너무 높음:
비용 증가 가능

로컬 fallback이 자주 발생:
로컬 모델 품질 또는 성능 문제

로컬 큐 대기 시간이 증가:
GPU 서버 증설 또는 요청 제한 필요

고성능 모델 사용이 많음:
라우팅 기준 재검토 필요

하이브리드 구조에서는 기술 지표와 비용 지표를 함께 봐야 한다.

하이브리드 AI는 선택지가 많은 만큼 관찰 지표도 중요하다.

15. 하이브리드 AI 적용 예시: 고객 문의 처리

고객 문의 처리는 하이브리드 AI를 적용하기 좋은 예시다.

고객 문의에는 개인정보가 포함될 수 있고, 문의 유형도 다양하다.

기본 흐름은 다음과 같이 만들 수 있다.

고객 문의 수집
→ 개인정보 탐지
→ 로컬 마스킹
→ 로컬 모델로 1차 분류
→ 복잡도 판단
→ 단순 문의는 로컬 요약
→ 복잡 문의는 클라우드 모델 요약
→ 상담원 검토

예를 들어 문의가 짧고 단순하면 로컬 모델로 처리한다.

문의:
하트 충전했는데 반영이 안 됐어요.

로컬 처리:
category = payment
priority = medium
summary = 하트 충전 후 미반영 문의

반대로 긴 상담 이력이나 분쟁성 문의는 클라우드 모델로 보낼 수 있다.

문의:
여러 차례 결제와 환불, 고객 불만, 운영 정책 확인 필요

처리:
마스킹 후 클라우드 고성능 모델로 요약
상담원 검토 후 사용

이 구조의 장점은 다음과 같다.

- 개인정보를 먼저 제거할 수 있다.
- 단순 문의 비용을 줄일 수 있다.
- 복잡 문의는 품질 좋은 모델을 사용할 수 있다.
- 상담원이 최종 검토하므로 위험이 낮다.

주의할 점은 다음과 같다.

- 마스킹 실패 가능성
- 로컬 분류 모델의 오판
- 클라우드 전송 기준
- 상담원 수정률 모니터링
- 원문 로그 저장 정책

고객 문의 처리는 AI가 최종 결정을 내리기보다 상담원을 돕는 구조가 안전하다.

16. 하이브리드 AI 적용 예시: 사내 문서 검색

사내 문서 검색도 하이브리드 구조와 잘 맞는다.

문서 등급에 따라 로컬과 클라우드를 나눌 수 있다.

공개 가능한 일반 문서:
클라우드 AI 답변 가능

내부 전용 문서:
로컬 RAG 답변

보안 제한 문서:
AI 답변 금지 또는 별도 승인

기본 흐름은 다음과 같다.

사용자 질문
→ 사용자 권한 확인
→ 문서 등급 확인
→ 내부 벡터DB 검색
→ 문서 등급에 따라 로컬 또는 클라우드 모델 선택
→ 답변 생성
→ 출처 표시

예를 들어 개발 문서 검색은 로컬 RAG로 처리할 수 있다.

질문:
배포 실패 시 rollback 절차 알려줘.

처리:
내부 배포 매뉴얼 검색
→ 로컬 LLM 답변
→ 출처 표시

반면 외부 공개 가능한 기술 문서 요약은 클라우드 모델을 사용할 수 있다.

질문:
공개 API 문서 기준으로 인증 방식 요약해줘.

처리:
클라우드 LLM 답변 가능

문서 검색에서 가장 중요한 것은 권한과 출처다.

- 사용자가 볼 수 있는 문서만 검색한다.
- 답변에 사용한 문서 제목을 표시한다.
- 문서에 없는 내용은 답하지 않는다.
- 민감 등급 문서는 클라우드로 보내지 않는다.

하이브리드 문서 검색은 강력하지만, 문서 메타데이터 관리가 필수다.

문서마다 다음 정보가 있어야 한다.

- 문서 제목
- 소유 부서
- 수정일
- 문서 등급
- 접근 가능 역할
- 클라우드 전송 가능 여부

메타데이터가 없으면 안전한 하이브리드 라우팅을 하기 어렵다.

17. 하이브리드 AI 적용 예시: 장애 로그 분석

장애 로그 분석은 하이브리드 AI 설계가 특히 중요하다.

운영 로그에는 민감 정보가 포함될 수 있다.

- 사용자 ID
- IP 주소
- 세션 ID
- 인증 토큰
- 내부 API URL
- DB 에러 메시지
- 서버명

따라서 로그 원문을 그대로 클라우드 AI로 보내는 것은 위험할 수 있다.

하이브리드 구조는 다음처럼 만들 수 있다.

운영 로그
→ 로컬 필터링
→ 토큰, 세션, 개인정보 제거
→ 에러 패턴 추출
→ 로컬 모델 1차 분석
→ 필요 시 마스킹된 요약만 클라우드 모델로 전달

예를 들어 로컬에서 먼저 로그를 정리한다.

원본 로그:
2026-05-05 10:01:22 userId=12345 token=abc.def.ghi payment callback timeout...

정제 후:
2026-05-05 10:01:22 [userId] [token] payment callback timeout...

그다음 클라우드 모델에는 정제된 정보만 보낸다.

마스킹된 로그
배포 시각
에러 발생 시각
관련 서비스명
발생 빈도

이 구조의 장점은 다음과 같다.

- 민감 로그 원문을 외부로 보내지 않는다.
- 로컬 모델로 빠르게 1차 분석할 수 있다.
- 복잡한 원인 추론은 클라우드 모델을 활용할 수 있다.
- 운영자가 최종 판단한다.

장애 로그 분석에서 AI는 원인을 확정하는 도구가 아니다.

AI는 다음을 정리해주는 보조 도구로 보는 것이 안전하다.

- 가능한 원인 후보
- 추가 확인 항목
- 영향 범위 추정
- 임시 대응 방안
- 관련 로그 패턴

최종 원인 판단과 조치는 사람이 해야 한다.

18. 하이브리드 AI 도입 순서

하이브리드 AI는 처음부터 복잡하게 만들 필요가 없다.

추천하는 도입 순서는 다음과 같다.

1. 클라우드 AI로 빠르게 PoC를 만든다.
2. 실제 사용량과 비용을 측정한다.
3. 민감 데이터가 포함된 기능을 식별한다.
4. 반복적이고 단순한 작업을 찾는다.
5. 로컬 AI로 대체 가능한 기능을 실험한다.
6. AI 호출 공통 모듈을 만든다.
7. 모델 라우팅 기준을 추가한다.
8. fallback 구조를 만든다.
9. 로그와 비용 대시보드를 통합한다.
10. 기능별 품질 평가를 운영한다.

처음부터 AI Gateway, 로컬 GPU 서버, 멀티 클라우드 모델 라우팅까지 한 번에 만들려고 하면 부담이 크다.

작게 시작하는 것이 좋다.

1단계:
클라우드 AI 단일 모델

2단계:
공통 AI Client 도입

3단계:
로컬 모델 일부 기능 적용

4단계:
민감도 기반 라우팅

5단계:
fallback과 비용 최적화

6단계:
AI Gateway 서비스화

하이브리드 AI는 운영 경험이 쌓이면서 자연스럽게 발전시키는 구조다.

19. 하이브리드 AI 설계 체크리스트

하이브리드 AI를 설계할 때는 다음 항목을 점검하면 좋다.

이 체크리스트는 하이브리드 구조가 복잡해질수록 중요해진다.

특히 다음 두 가지는 반드시 지켜야 한다.

1. 사용자가 볼 수 없는 데이터는 어떤 모델에도 전달하지 않는다.
2. 클라우드로 나가면 안 되는 데이터는 라우팅 전에 차단한다.

하이브리드 AI는 유연하지만, 유연하다는 이유로 데이터 흐름이 불분명해지면 위험하다.

20. 정리

클라우드 AI와 로컬 AI는 둘 중 하나만 선택해야 하는 관계가 아니다.

클라우드 AI는 빠르게 시작하기 좋고, 고성능 모델을 쉽게 사용할 수 있으며, 운영 부담이 상대적으로 낮다.
하지만 비용, 외부 의존성, 데이터 전송 문제가 있다.

로컬 AI는 데이터 통제와 반복 작업 비용 절감, 사내망 활용에 유리하다.
하지만 모델 품질, 하드웨어, 동시 요청, 운영 부담이라는 한계가 있다.

하이브리드 AI는 이 둘의 장점을 조합하는 방식이다.

민감 정보:
로컬 처리

일반 질의:
클라우드 처리

단순 반복 작업:
로컬 또는 저비용 모델

복잡한 분석:
고성능 클라우드 모델

장애 상황:
fallback 모델 사용

하이브리드 AI를 잘 설계하려면 AI Gateway 또는 공통 AI 처리 계층이 필요하다.
모델 선택, 프롬프트, 비용 기록, 응답 검증, fallback, 로그 정책을 중앙에서 관리해야 한다.

중요한 것은 어떤 모델이 가장 좋은지가 아니다.
업무 목적, 데이터 민감도, 비용, 품질, 지연시간, 운영 부담을 기준으로 적절한 실행 위치를 선택하는 것이다.

이 장에서 기억해야 할 핵심은 하나다.

하이브리드 AI는 클라우드와 로컬 중 하나를 고르는 타협안이 아니라,
데이터와 작업의 성격에 따라 가장 적절한 AI 실행 위치를 선택하는 운영 전략이다.

26장 핵심 요약