21장. 로컬 AI를 쓰는 이유

1. 클라우드 AI만으로 충분하지 않은 순간

앞 장에서는 클라우드 AI를 운영할 때 필요한 설계를 살펴보았다.

클라우드 AI는 빠르게 시작하기 좋다.
모델을 직접 설치하지 않아도 되고, GPU 서버를 운영하지 않아도 되며,
API 호출만으로 요약, 분류, 번역, 문서 검색, 코드 분석 같은 기능을 만들 수 있다.

하지만 운영 환경에서 AI를 계속 사용하다 보면 이런 질문이 생긴다.

모든 AI 요청을 꼭 클라우드로 보내야 할까?
민감한 데이터도 외부 AI API로 보내도 될까?
사용량이 많아졌는데 비용을 계속 감당할 수 있을까?
인터넷이 끊기거나 외부 API 장애가 나면 어떻게 할까?
사내망에서만 동작하는 AI는 만들 수 없을까?

이때 등장하는 선택지가 로컬 AI다.

로컬 AI는 AI 모델을 외부 클라우드 API로 호출하는 대신,
개발 PC, 사내 서버, 온프레미스 환경, 또는 내부망 서버에서 직접 실행하는 방식이다.

흐름은 클라우드 AI와 다르다.

클라우드 AI는 보통 다음과 같다.

우리 서비스
→ 외부 클라우드 AI API
→ AI 모델 실행
→ 응답 반환

로컬 AI는 다음과 같다.

우리 서비스
→ 내부 AI 서버 또는 개발 PC
→ 로컬 모델 실행
→ 응답 반환

즉, AI 모델이 외부 클라우드에 있는 것이 아니라 우리가 관리하는 환경 안에 있다.

로컬 AI를 쓰면 데이터가 외부로 나가지 않는 구조를 만들 수 있고, 특정 작업에서는 비용을 줄일 수 있으며, 인터넷이 없어도 동작하는 AI 기능을 만들 수 있다.

하지만 로컬 AI가 항상 더 좋은 것은 아니다.

모델 성능, 하드웨어, 운영 난이도, 응답 속도, 동시 처리, 모델 관리 같은 새로운 문제가 생긴다.

이 장에서는 로컬 AI를 왜 쓰는지, 어떤 상황에 적합한지, 그리고 클라우드 AI와 무엇이 다른지 살펴본다.

2. 로컬 AI란 무엇인가

로컬 AI는 AI 모델을 직접 다운로드하거나 내부 서버에 배포해서 실행하는 방식이다.

여기서 “로컬”은 꼭 개인 노트북만 의미하지 않는다.

다음 환경이 모두 로컬 AI 범위에 들어갈 수 있다.

- 개발자 개인 PC
- 맥북이나 윈도우 노트북
- 사내 GPU 서버
- 온프레미스 서버
- 내부망 전용 AI 서버
- 클라우드 안에 직접 올린 오픈소스 모델 서버

중요한 기준은 “외부 AI API를 호출하느냐”가 아니라 “모델 실행 환경을 우리가 관리하느냐”다.

예를 들어 Ollama로 개발 PC에서 Llama 계열 모델을 실행한다면 로컬 AI다.

개발자 PC
→ Ollama 실행
→ 로컬 LLM 호출
→ 응답 생성

사내 서버에 오픈소스 모델을 올리고 내부 서비스에서 호출해도 로컬 AI에 가깝다.

사내 서비스
→ 내부 AI 추론 서버
→ 오픈소스 LLM 실행
→ 응답 반환

클라우드 위의 GPU 인스턴스에 직접 모델을 올리는 경우도 있다.

우리 AWS 계정의 GPU 서버
→ 직접 설치한 오픈소스 모델
→ 내부 API로 호출

이 경우 물리적으로는 클라우드에 있지만, 모델 운영은 우리가 직접 한다.
그래서 관리형 클라우드 AI와는 다르다.

로컬 AI는 AI 모델을 외부 관리형 AI API로 호출하지 않고,
개발 PC나 사내 서버처럼 우리가 관리하는 환경에서 직접 실행하는 방식이다.

3. 로컬 AI를 쓰는 가장 큰 이유는 데이터 통제다

로컬 AI를 쓰는 가장 큰 이유 중 하나는 데이터 통제다.

클라우드 AI를 사용할 때는 입력 데이터가 외부 AI API로 전송될 수 있다.

예를 들어 다음 데이터가 AI 요청에 포함될 수 있다.

- 고객 문의 내용
- 개인정보
- 결제 관련 정보
- 운영 로그
- 내부 소스 코드
- 장애 리포트
- 사내 정책 문서
- 회의록
- 보안 로그

물론 클라우드 AI 제공자도 기업용 보안 정책, 데이터 처리 정책, 리전 설정, 학습 사용 여부 제한 같은 기능을 제공할 수 있다.

하지만 조직에 따라서는 “외부로 보내는 것 자체”가 부담일 수 있다.

예를 들어 다음과 같은 데이터는 외부 AI API로 보내기 어렵다.

- 개인정보가 포함된 고객 상담 원문
- 내부 계정 정보가 포함된 운영 로그
- 공개되지 않은 소스 코드
- 보안 사고 분석 자료
- 계약서나 법무 문서
- 내부 인사 관련 자료

이런 경우 로컬 AI를 사용하면 데이터가 내부 환경 밖으로 나가지 않는 구조를 만들 수 있다.

민감 데이터
→ 내부 AI 서버
→ 로컬 모델 처리
→ 내부 시스템에 결과 저장

예를 들어 운영 로그 분석 기능을 생각해보자.

클라우드 AI 방식은 다음과 같다.

운영 로그
→ 개인정보/토큰 마스킹
→ 클라우드 AI API
→ 분석 결과 반환

로컬 AI 방식은 다음과 같다.

운영 로그
→ 내부 AI 서버
→ 로컬 모델 분석
→ 분석 결과 반환

로컬 AI라고 해서 보안 검토가 필요 없는 것은 아니다.
하지만 최소한 외부 전송 범위를 줄일 수 있다.

로컬 AI의 핵심 장점은 다음 원칙에 있다.

민감한 데이터는 내부에서 처리한다.
외부로 보낼 필요가 없는 데이터는 외부로 보내지 않는다.

4. 비용 절감이 가능할 수 있다

로컬 AI를 쓰는 또 다른 이유는 비용이다.

클라우드 AI는 보통 사용량 기반으로 비용이 발생한다.

요청 수 증가
→ 입력 토큰 증가
→ 출력 토큰 증가
→ 비용 증가

처음에는 비용이 작게 보일 수 있다.
하지만 사용량이 늘면 월 비용이 커질 수 있다.

예를 들어 다음과 같은 작업은 요청 수가 많을 수 있다.

- 모든 고객 문의 자동 분류
- 모든 채팅 메시지 유해성 검사
- 대량 로그 요약
- 개발 문서 전체 색인
- 반복적인 내부 챗봇 질문
- 코드 리뷰 자동 분석

이런 작업을 모두 클라우드 AI로 처리하면 비용이 계속 증가한다.

로컬 AI는 모델을 실행할 서버 비용은 발생하지만, 요청당 외부 API 비용은 줄일 수 있다.

비용 구조가 다르다.

예를 들어 하루 수십만 건의 간단한 분류 작업이 있다고 해보자.

입력:
짧은 고객 문의 또는 채팅 메시지

출력:
category, risk_level 정도의 짧은 결과

이 작업은 고성능 모델이 필요하지 않을 수 있다.
적절한 로컬 모델로 충분하다면 내부 서버에서 처리해 비용을 줄일 수 있다.

하지만 로컬 AI가 항상 더 저렴한 것은 아니다.

다음 비용도 고려해야 한다.

- GPU 서버 구매 또는 임대 비용
- 전력과 냉각 비용
- 서버 운영 인력
- 모델 배포와 업데이트 비용
- 장애 대응 비용
- 모니터링 구성 비용

사용량이 적다면 클라우드 AI가 더 저렴할 수 있다.
사용량이 많고 반복적인 작업이라면 로컬 AI가 유리할 수 있다.

따라서 비용 비교는 단순히 “클라우드가 비싸다, 로컬이 싸다”로 보면 안 된다.

요청량이 적고 품질이 중요하다:
클라우드 AI가 유리할 수 있음

요청량이 많고 작업이 단순하다:
로컬 AI가 유리할 수 있음

민감 정보가 많다:
비용보다 보안 관점에서 로컬 AI를 고려

5. 인터넷 없이 동작하는 AI가 필요할 수 있다

로컬 AI는 인터넷 연결 없이도 동작할 수 있다.

물론 모델을 처음 다운로드하거나 업데이트할 때는 인터넷이 필요할 수 있다.
하지만 모델을 내부 환경에 준비해두면 외부 API 연결 없이도 사용할 수 있다.

이 특징은 다음 상황에서 중요하다.

- 외부 인터넷이 제한된 사내망
- 보안 구역
- 폐쇄망 환경
- 현장 장비
- 오프라인 개발 환경
- 외부 API 장애에 대비한 fallback

예를 들어 사내망에서만 동작하는 운영 도구가 있다고 해보자.

운영자
→ 내부 관리자 페이지
→ 내부 로그 조회
→ 로컬 AI 분석
→ 결과 표시

이 구조에서는 외부 AI API를 호출하지 않아도 된다.

또는 클라우드 AI 장애에 대비해 로컬 AI를 fallback으로 사용할 수도 있다.

1차:
클라우드 AI 호출

장애 발생:
로컬 AI로 간단한 요약 또는 분류 수행

결과:
품질은 낮을 수 있지만 기본 기능 유지

다만 로컬 AI는 모델 파일과 실행 환경을 미리 준비해야 한다.

- 모델 다운로드
- 실행 도구 설치
- 서버 리소스 확보
- API 서버 구성
- 모델 업데이트 방식 준비

오프라인 환경에서 로컬 AI를 운영하려면 모델 업데이트 절차도 중요하다.

외부망에서 모델 검증
→ 내부망 반입 승인
→ 내부 AI 서버 배포
→ 버전 기록

즉, 로컬 AI는 인터넷 없이 동작할 수 있다는 장점이 있지만, 그만큼 모델과 환경을 직접 관리해야 한다.

6. 사내망 환경에서 AI를 활용할 수 있다

많은 회사는 모든 시스템이 외부 인터넷과 자유롭게 연결되어 있지 않다.

특히 운영 시스템, 보안 로그, 내부 문서, DB 관리 도구는 사내망 안에서만 접근 가능하도록 구성되어 있을 수 있다.

이런 환경에서는 클라우드 AI를 직접 연결하기 어렵다.

사내망 데이터
→ 외부 AI API로 전송 불가

로컬 AI는 이런 환경에서 유용할 수 있다.

사내망 안에 AI 서버를 두면 내부 데이터에 접근하면서도 외부 전송 없이 AI 기능을 제공할 수 있다.

사내 문서
→ 내부 벡터DB
→ 내부 AI 서버
→ 사내 문서 검색 챗봇

또는 운영 로그 분석도 가능하다.

운영 로그
→ 내부 로그 시스템
→ 로컬 AI 분석 서버
→ 운영자 화면

사내망 AI에서 중요한 것은 권한 관리다.

내부에 있다고 해서 모든 사용자가 모든 문서를 봐도 되는 것은 아니다.

개발팀 문서
→ 개발팀만 검색 가능

인사 문서
→ 인사팀과 일부 관리자만 검색 가능

보안 로그
→ 보안 담당자만 접근 가능

로컬 AI도 RAG를 만들 때는 권한 필터가 필요하다.

사용자 질문
→ 사용자 권한 확인
→ 권한 있는 문서만 검색
→ 로컬 모델로 답변 생성

AI 모델이 내부에 있더라도 권한 관리가 없으면 정보 유출이 발생할 수 있다.

로컬 AI는 외부 전송 위험을 줄여주지만, 내부 권한 문제까지 자동으로 해결해주지는 않는다.

7. 로컬 AI의 성능 한계

로컬 AI의 가장 큰 현실적인 한계는 성능이다.

클라우드 AI는 대규모 인프라와 고성능 모델을 기반으로 동작한다.
반면 로컬 AI는 우리가 가진 하드웨어와 모델에 따라 성능이 제한된다.

특히 LLM은 모델 크기가 클수록 많은 메모리와 연산 자원이 필요하다.

예를 들어 모델 크기를 단순히 보면 다음과 같은 차이가 있다.

작은 모델:
빠르고 가볍지만 복잡한 추론은 약할 수 있음

큰 모델:
더 좋은 답변을 만들 가능성이 있지만 GPU 메모리와 연산량이 많이 필요함

개발 PC에서 작은 모델을 실행하면 간단한 요약이나 문장 변환은 가능할 수 있다.
하지만 복잡한 코드 리뷰, 긴 문서 분석, 어려운 정책 질의에서는 클라우드 고성능 모델보다 품질이 떨어질 수 있다.

로컬 AI에서 자주 마주치는 한계는 다음과 같다.

- 응답 속도가 느리다.
- 긴 문서를 처리하기 어렵다.
- 동시 요청 처리 능력이 낮다.
- 한국어 품질이 모델마다 다르다.
- 복잡한 추론 성능이 부족할 수 있다.
- 코드 분석 품질이 기대보다 낮을 수 있다.
- 모델이 환각을 일으킬 수 있다.

또 하드웨어도 중요하다.

CPU만 사용:
실행은 가능하지만 느릴 수 있음

GPU 사용:
응답 속도가 개선되지만 VRAM이 중요함

VRAM 부족:
큰 모델 실행이 어렵거나 매우 느려짐

VRAM은 GPU가 사용하는 전용 메모리다.
로컬 AI에서는 모델을 GPU에 올려 실행할 때 VRAM 용량이 매우 중요하다.

로컬 AI는 클라우드 AI의 완전한 대체재라기보다, 특정 조건에서 유용한 선택지로 보는 것이 좋다.

8. 로컬 AI는 운영 부담이 있다

클라우드 AI는 모델 운영의 많은 부분을 클라우드 제공자가 담당한다.

하지만 로컬 AI는 우리가 직접 운영해야 한다.

직접 운영해야 하는 요소는 다음과 같다.

- 모델 다운로드
- 모델 버전 관리
- 실행 서버 구성
- GPU 드라이버 관리
- 추론 서버 배포
- API 서버 구성
- 동시 요청 처리
- 장애 대응
- 모니터링
- 로그 관리
- 보안 패치

개발자 개인 PC에서 테스트하는 수준이라면 어렵지 않을 수 있다.

예를 들어 Ollama를 설치하고 모델을 실행하는 것은 비교적 간단하다.

ollama run llama3

하지만 운영 서비스로 제공하려면 이야기가 달라진다.

사용자 여러 명이 동시에 요청한다.
모델 서버가 죽으면 복구해야 한다.
응답 시간이 느리면 원인을 찾아야 한다.
모델 버전을 바꾸면 품질을 다시 검증해야 한다.
GPU 메모리가 부족하면 서버를 증설해야 한다.

즉, 로컬 AI를 운영한다는 것은 작은 AI 인프라를 직접 갖는다는 뜻이다.

그래서 팀은 다음 질문에 답해야 한다.

- 누가 모델 서버를 운영할 것인가?
- 장애가 나면 누가 대응할 것인가?
- 모델 업데이트는 어떻게 할 것인가?
- 사용량이 늘면 어떻게 확장할 것인가?
- 로그와 비용은 어떻게 추적할 것인가?
- 보안 패치는 누가 관리할 것인가?

로컬 AI는 외부 API 비용과 데이터 전송 부담을 줄일 수 있지만, 운영 책임은 내부로 들어온다.

이 점을 명확히 이해해야 한다.

9. 로컬 AI가 잘 맞는 작업

로컬 AI는 모든 AI 작업에 적합하지 않다.

하지만 잘 맞는 영역은 분명하다.

첫 번째는 민감 정보가 포함된 작업이다.

- 운영 로그 요약
- 보안 로그 분석
- 내부 코드 설명
- 사내 문서 요약
- 개인정보 포함 가능성이 있는 상담 데이터 처리

두 번째는 반복적이고 단순한 작업이다.

- 짧은 문장 분류
- 태깅
- 간단한 요약
- 텍스트 정제
- 키워드 추출

이런 작업은 고성능 클라우드 모델이 아니어도 충분할 수 있다.

세 번째는 내부 개발 보조다.

- 코드 설명
- 로컬 문서 검색
- README 초안
- 테스트 데이터 생성
- 간단한 스크립트 작성

네 번째는 오프라인 또는 폐쇄망 환경이다.

- 외부 API 호출이 제한된 사내망
- 보안 구역
- 인터넷이 불안정한 현장 환경

다섯 번째는 클라우드 AI fallback이다.

클라우드 AI 장애
→ 로컬 AI로 간단한 응답 제공
→ 핵심 업무 흐름 유지

로컬 AI가 잘 맞는 작업을 정리하면 다음과 같다.

로컬 AI는 “클라우드 AI보다 항상 낮은 품질”이라고 단정할 필요는 없다.
하지만 모델과 하드웨어에 따라 한계가 있으므로, 작업별로 검증해야 한다.

10. 로컬 AI가 잘 맞지 않는 작업

로컬 AI가 적합하지 않은 경우도 있다.

첫 번째는 최고 수준의 답변 품질이 필요한 경우다.

- 복잡한 법무 문서 분석
- 복잡한 장애 원인 추론
- 높은 정확도가 필요한 코드 리뷰
- 임원 보고서 초안
- 여러 문서를 종합한 전략 분석

이런 작업은 고성능 클라우드 모델이 더 좋은 결과를 낼 수 있다.

두 번째는 동시 요청이 많은 사용자 서비스다.

개발 PC나 작은 GPU 서버에서 동시 사용자 수를 많이 처리하기는 어렵다.

사용자 1명:
응답 가능

사용자 100명 동시 요청:
대기열 증가
응답 지연
서버 부하 증가

세 번째는 긴 컨텍스트가 필요한 작업이다.

로컬 모델은 모델에 따라 한 번에 처리할 수 있는 입력 길이가 제한적일 수 있다.

긴 회의록 전체
긴 장애 로그 전체
대형 PR 전체 diff
여러 정책 문서 전체

이런 경우 입력을 줄이거나 RAG 구조를 사용해야 한다.

네 번째는 운영팀이 모델 서버를 관리할 여력이 없는 경우다.

로컬 AI는 직접 운영해야 한다.
팀에 GPU 서버 운영 경험이나 모델 배포 경험이 없다면 초기에는 클라우드 AI가 더 현실적일 수 있다.

다섯 번째는 최신 모델을 빠르게 활용해야 하는 경우다.

클라우드 AI는 최신 모델을 API로 바로 사용할 수 있는 경우가 많다.
로컬 AI는 모델을 직접 가져오고 검증하고 배포해야 한다.

로컬 AI가 잘 맞지 않는 상황은 다음과 같다.

- 최고 수준의 추론 품질이 필요하다.
- 동시 사용자가 많다.
- 긴 입력을 자주 처리한다.
- 운영 인력이 부족하다.
- 모델 업데이트를 자주 해야 한다.
- 초기 구축보다 빠른 출시가 중요하다.

이런 경우에는 클라우드 AI를 먼저 사용하거나, 하이브리드 구조를 고려하는 것이 좋다.

11. 클라우드 AI와 로컬 AI는 경쟁 관계가 아니다

클라우드 AI와 로컬 AI를 둘 중 하나만 선택해야 한다고 생각할 필요는 없다.

실무에서는 둘을 함께 쓰는 구조가 더 현실적이다.

예를 들어 다음처럼 역할을 나눌 수 있다.

민감 정보 포함:
로컬 AI

일반 질의:
클라우드 AI

단순 분류:
저비용 로컬 모델

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

클라우드 장애:
로컬 fallback

이런 구조를 하이브리드 AI 구조라고 볼 수 있다.

요청 수신
→ 데이터 민감도 확인
→ 작업 복잡도 확인
→ 비용 기준 확인
→ 로컬 또는 클라우드 모델 선택

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

개인정보가 포함된 원문은 로컬에서 먼저 처리할 수 있다.

고객 문의 원문
→ 로컬 AI 또는 규칙 기반 마스킹
→ 개인정보 제거
→ 클라우드 AI로 요약

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

간단한 문의:
로컬 모델 분류

복잡한 문의:
클라우드 모델 분석

RAG에서도 하이브리드가 가능하다.

사내 문서 검색:
내부 벡터DB에서 처리

답변 생성:
민감도 낮은 문서는 클라우드 AI
민감도 높은 문서는 로컬 AI

중요한 것은 작업별로 적절한 위치를 선택하는 것이다.

클라우드 AI는 빠르고 품질 좋은 모델을 쉽게 사용할 수 있게 해준다.
로컬 AI는 데이터 통제와 비용 구조에서 장점이 있다.

둘은 경쟁 관계가 아니라 역할이 다른 도구다.

12. 로컬 AI를 도입하기 전에 확인할 것

로컬 AI를 도입하기 전에 먼저 질문해야 할 것이 있다.

무작정 로컬 모델을 설치하는 것보다, 목적과 기준을 먼저 정해야 한다.

예를 들어 “운영 로그 분석을 로컬 AI로 하고 싶다”고 해보자.

그러면 다음처럼 정리할 수 있다.

목적:
운영 로그를 외부 AI API로 보내지 않고 내부에서 분석한다.

데이터:
서버 로그, 에러 메시지, 요청 ID, 일부 내부 URL

민감 정보:
토큰, 세션 ID, 사용자 식별자 포함 가능

작업:
에러 원인 후보 정리, 확인 항목 추천

품질 기준:
원인 확정이 아니라 운영자 보조 초안

운영 방식:
내부 AI 서버에서 실행

fallback:
로컬 AI 실패 시 수동 로그 분석

이렇게 정리하면 로컬 AI 도입이 필요한 이유와 범위가 분명해진다.

13. 로컬 AI 도입의 현실적인 순서

로컬 AI를 처음 도입할 때는 작게 시작하는 것이 좋다.

처음부터 전사 AI 시스템을 만들려고 하면 어렵다.

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

1. 개발 PC에서 로컬 모델을 실행해본다.
2. 간단한 요약이나 분류 작업을 테스트한다.
3. 사내 문서 일부로 로컬 RAG를 만들어본다.
4. 응답 품질과 속도를 측정한다.
5. 팀 내부 도구로 제한적으로 사용한다.
6. 내부 서버에 배포해 API 형태로 제공한다.
7. 권한, 로그, 모니터링을 추가한다.
8. 클라우드 AI와 역할을 나눈다.

처음 실습은 Ollama나 LM Studio 같은 도구로 시작할 수 있다.

개발 PC
→ 로컬 모델 실행
→ 간단한 질문 테스트
→ API 호출 테스트

그 다음 내부 문서를 연결해볼 수 있다.

Markdown 문서
→ 임베딩 생성
→ 로컬 벡터DB 저장
→ 질문
→ 관련 문서 검색
→ 로컬 모델 답변

처음부터 완벽한 답변 품질을 기대하면 안 된다.

로컬 AI 도입 초기에는 다음을 확인하는 것이 중요하다.

- 우리 데이터에서 어느 정도 쓸 만한가?
- 응답 속도는 업무에 지장이 없는가?
- 모델 크기에 따른 차이는 어떤가?
- 한국어 답변 품질은 어떤가?
- 긴 문서를 잘 처리하는가?
- 하드웨어 자원은 어느 정도 필요한가?

효과가 확인되면 그다음 운영 구조를 고민하면 된다.

14. 로컬 AI에서도 보안과 운영은 필요하다

로컬 AI는 데이터가 외부로 나가지 않는다는 장점이 있다.

하지만 그렇다고 보안이 자동으로 해결되는 것은 아니다.

내부 AI 서버가 있다면 그 서버도 보호해야 한다.

- 누가 AI 서버를 호출할 수 있는가?
- 어떤 문서에 접근할 수 있는가?
- 요청 로그는 남기는가?
- 민감 정보는 마스킹하는가?
- 모델이 접근할 수 있는 파일 경로는 제한되어 있는가?
- 관리자 기능과 일반 사용자 기능이 분리되어 있는가?

로컬 AI에서 특히 조심해야 할 것은 내부 데이터 접근 범위다.

예를 들어 로컬 AI가 파일 시스템에 접근할 수 있다면 위험하다.

나쁜 구조:
AI가 서버의 모든 디렉터리를 읽을 수 있음

좋은 구조:
허용된 문서 디렉터리만 읽을 수 있음

DB 조회도 마찬가지다.

나쁜 구조:
AI 도구가 운영 DB 전체 조회 가능

좋은 구조:
읽기 전용 계정
허용된 테이블만 접근
민감 컬럼 마스킹
쿼리 제한

로컬 AI는 외부 전송 위험은 줄이지만, 내부 권한 상승이나 과도한 데이터 접근 위험은 여전히 존재한다.

운영 관점에서도 로그와 모니터링이 필요하다.

- 요청 수
- 응답 시간
- 실패율
- 모델별 사용량
- GPU 사용률
- 메모리 사용량
- 큐 대기 시간
- 사용자별 사용량

클라우드 AI는 제공자가 모델 실행 환경을 관리해준다.
로컬 AI는 이 부분까지 직접 봐야 한다.

15. 로컬 AI와 온프레미스 AI의 차이

로컬 AI와 온프레미스 AI는 비슷하게 쓰일 때가 많다.

하지만 약간 구분해서 이해하면 좋다.

로컬 AI는 넓은 표현이다.

- 개인 PC에서 실행하는 AI
- 사내 서버에서 실행하는 AI
- 내부망에서 실행하는 AI
- 직접 운영하는 클라우드 GPU 서버의 AI

온프레미스 AI는 보통 회사가 직접 관리하는 물리 서버나 내부 데이터센터에서 AI를 운영하는 방식을 말한다.

사내 데이터센터
→ GPU 서버
→ AI 모델 배포
→ 내부 서비스에서 호출

예를 들어 개발자가 맥북에서 Ollama를 실행하는 것은 로컬 AI다.
하지만 온프레미스 AI라고 부르지는 않는다.

반면 회사 IDC에 GPU 서버를 두고 사내 AI 서비스를 운영한다면 온프레미스 AI에 가깝다.

이 책에서는 로컬 AI를 넓은 의미로 사용한다.
즉, 외부 관리형 AI API에 전적으로 의존하지 않고, 우리가 직접 모델 실행 환경을 관리하는 방식을 포함한다.

16. 로컬 AI를 바라보는 현실적인 관점

로컬 AI는 매력적이다.

- 데이터가 외부로 나가지 않는다.
- 요청당 API 비용을 줄일 수 있다.
- 인터넷 없이도 동작할 수 있다.
- 내부 시스템과 가깝게 붙일 수 있다.
- 모델을 직접 제어할 수 있다.

하지만 동시에 현실적인 한계도 있다.

- 모델 품질이 기대보다 낮을 수 있다.
- 하드웨어 비용이 크다.
- GPU 운영이 필요할 수 있다.
- 동시 요청 처리가 어렵다.
- 모델 업데이트와 배포를 직접 해야 한다.
- 장애 대응도 직접 해야 한다.

그래서 로컬 AI를 “클라우드 AI를 대체하는 완벽한 해답”으로 보면 안 된다.

더 현실적인 관점은 다음과 같다.

클라우드 AI:
빠르게 시작하고, 고품질 모델을 쉽게 사용한다.

로컬 AI:
민감 정보, 비용, 내부망, 반복 작업에 활용한다.

하이브리드 AI:
작업의 성격에 따라 클라우드와 로컬을 나누어 사용한다.

예를 들어 다음 구조가 실무적으로 자연스럽다.

1. 처음에는 클라우드 AI로 빠르게 PoC를 만든다.
2. 실제 효과가 있는 기능을 운영에 붙인다.
3. 비용이 큰 반복 작업을 찾는다.
4. 민감 정보가 많은 기능을 분리한다.
5. 일부 기능을 로컬 AI로 전환한다.
6. 클라우드 AI와 로컬 AI를 함께 쓰는 모델 라우터를 만든다.

AI 도입에서 중요한 것은 특정 기술을 고집하는 것이 아니다.
업무 목적, 보안, 비용, 품질, 운영 역량에 맞는 방식을 선택하는 것이다.

17. 정리

로컬 AI는 AI 모델을 외부 클라우드 API로 호출하지 않고, 개발 PC나 사내 서버처럼 우리가 관리하는 환경에서 직접 실행하는 방식이다.

로컬 AI를 쓰는 가장 큰 이유는 데이터 통제다.
고객 문의, 운영 로그, 내부 코드, 사내 문서처럼 외부로 보내기 어려운 데이터를 내부에서 처리할 수 있다.

또 사용량이 많고 반복적인 작업에서는 비용 절감 효과를 기대할 수 있다.
요청당 클라우드 API 비용을 줄이고, 내부 서버 자원을 활용할 수 있기 때문이다.

인터넷 연결이 제한된 환경이나 사내망에서도 로컬 AI는 유용하다.
모델과 실행 환경을 내부에 준비해두면 외부 AI API 없이도 요약, 분류, 문서 검색 같은 기능을 제공할 수 있다.

하지만 로컬 AI에는 분명한 한계도 있다.

클라우드 AI보다 모델 품질이 낮을 수 있고, 하드웨어 요구사항이 높을 수 있으며, 동시 요청 처리와 운영 관리가 어렵다.
GPU, VRAM, 모델 버전, 추론 서버, 모니터링, 장애 대응을 직접 신경 써야 한다.

따라서 로컬 AI는 클라우드 AI의 단순한 대체재가 아니다.
민감 정보 처리, 비용 절감, 내부망 활용, fallback 같은 특정 목적에 맞게 사용하는 것이 좋다.

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

로컬 AI는 “클라우드 AI를 쓰지 않는 방식”이 아니라,
데이터 통제와 비용, 내부망 요구사항에 맞춰 AI 실행 위치를 직접 선택하는 방식이다.

21장 핵심 요약