08 Local&Cloud LLM
08 Local&Cloud LLM
1. Note
- 결국 문제는 예산과 비용
- 백엔드 개발자의 역할을 조금더 넓게 봐야할 듯 한 느낌.
- 원하는 내용에 맞게 단순하게 개발하고 확인받는게 아니라
- 뭔가 전체적인 흐름이나 회사의 시스템에 맞는
- 다양한 방법론적인 내용으로 접근해야하는게 아닐까.
- 어떤 언어를 쓸 수 있냐 보다, 이 상황을 어떻게 대처할 것 인가?
- 클라우드 타입과 로컬방식을 하이브리드로 사용하는게 중요할 듯!
2. LLM 방식
1. 클라우드 API 방식 (OpenAI, Claude 등)
- 작동원리
- Spring Boot ↔ 인터넷(HTTPS) ↔ 외부 서버(OpenAI/Anthropic)
- 모델은 전부 외부에 있고 우리는 API 호출만 하는 구조
- 주요특징
- GPT 계열이나 Claude 같은 고성능/최신 모델을 별도의 설치 없이 API 호출만으로 즉시 활용할 수 있음
- 인프라 관리 부담( GPU, 모델 파일, 메모리 최적화) 같은 복잡한 운영 요소를 직접 관리할 필요가 없음
- 사용량이 증가해도 클라우드 제공자가 자동으로 처리하기 때문에 트래픽 대응이 수월
- API Key만 발급받으면 바로 개발에 적용할 수 있어 초기 세팅 비용이 매우 낮고, 도입 속도가 빠름
- 한계점
- 토큰 기반 과금 구조이기 때문에 요청이 많아질수록 비용이 빠르게 증가할 수 있음
- 인터넷 연결 상태에 따라 서비스 품질이 영향을 받으며, 장애 시 대응이 어려움
- 외부 서버와 통신하는 왕복 시간이 포함되기 때문에 완전한 실시간 처리가 어려움
- 민감한 데이터가 외부 서버로 전달되는 구조이기 때문에 보안 정책상 제한이 있을 수 있음(개인정보등)
2. 로컬 모델 방식 (Ollama + Spring AI)
- 작동원리
- Spring Boot ↔ 로컬 호스트(localhost:11434) ↔ Ollama Runtime
- 내 PC/서버 안에서 모델이 직접 실행
- 주요특징
- 모든 요청과 응답이 내부에서 처리되기 때문에 보안과 프라이버시 측면에서 매우 유리함.
- 인터넷 연결이 없어도 AI 기능을 사용할 수 있어 폐쇄망 환경에서도 활용할 수 있음
- 초기 하드웨어 투자 이후에는 호출당 비용이 발생하지 않기 때문에 장기적으로 비용 절감 효과가 있음
- 원하는 모델을 선택하거나, 특정 목적에 맞게 튜닝하는 등 유연한 운영이 가능함
- 한계점
- GPU가 없거나 성능이 낮으면 응답 속도가 느려지고, 사용할 수 있는 모델 크기에도 제한이 생김
- GPT-4급 이상의 초대형 모델은 로컬 환경에서 운용하기 현실적으로 어려움
- 모델 다운로드, 버전 관리, 메모리 최적화 등 직접 관리해야 할 요소가 많음
- 트래픽이 증가하면 서버를 직접 증설해야 하므로 클라우드처럼 자동 확장이 어려움
3. 스프링 AI와 LLM
- 구조 자체는 어차피 인터페이스화가 되어 있어 무엇을 쓰던 차이가 없음.
1 2 3 4
chatClient.prompt() .user("안녕") .call() .content(); - 설정(Configuration) 레벨에서 차이
1 2 3 4 5 6 7 8 9 10 11
# 클라우드 spring: ai: openai: api-key: xxx # Ollama spring: ai: ollama: base-url: http://localhost:11434
3. LLM 방식의 선택
1. 클라우드 방식이 좋은 상황 (OpenAI / Anthropic 같은 API 사용)
- 최고 수준의 지능과 성능이 필요한 경우
- GPT-4o나 Claude 3.5 Sonnet 같은 최신 모델은 매우 높은 수준의 결과를 제공함
- 이런 성능은 현재 로컬 환경에서 재현하기 어렵기 때문에,
- 서비스의 핵심 경쟁력이 “AI 결과 품질”에 있다면 클라우드 모델을 사용하는 것이 훨씬 안정적
- 하드웨어 자원이 부족한 환경
- 로컬 모델을 안정적으로 운영하려면 GPU, 충분한 RAM, 모델 로딩 시간 등 여러 인프라 조건이 필요함
- 이 경우 클라우드는 이미 최적화된 인프라 위에서 모델이 실행되기 때문에,
- 별도의 하드웨어 투자 없이도 높은 성능을 바로 활용할 수 있음
- 빠른 시장 검증과 배포 (Time-to-Market)
- 서비스 초기 단계에서는 “완벽한 구조”보다 “빠르게 사용자 반응을 확인하는 것”이 더 중요함
- 클라우드는 즉시 연결이 가능하고, 모델 세팅이나 튜닝 없이도 바로 사용할 수 있어 개발 속도를 크게 단축
- 개발 단계에서는 시행착오를 빠르게 반복하는 것이 중요한데, 이 과정에서 클라우드 방식이 큰 장점을 가짐
- 트래픽이 적어 초기 비용이 낮은 경우
- 서비스 초반에는 사용량이 많지 않기 때문에 API 비용도 비교적 낮은 수준에서 유지
- 서버를 직접 구축하고 관리하는 시간과 비용(운영, 모니터링, 장애 대응 등)이 더 크게 느껴질 수 있음
- 일정 수준 이상의 트래픽이 발생하기 전까지는 클라우드를 사용하는 것이 전체적인 비용과 리소스 측면에서 더 효율적
2. 로컬 방식이 좋은 상황 (Ollama 같은 로컬 실행 방식)
- 비용 부담 없이 반복 실험이 필요한 초기 개발 단계
- 아이디어를 검증하는 프로토타입 단계에서는 프롬프트를 수백~수천 번 수정하면서 결과를 비교해야 하는 경우가 많음
- 이때 클라우드 API를 사용하면 호출마다 비용이 누적되지만,
- 로컬 모델은 실행 횟수에 따른 추가 비용이 없기 때문에 훨씬 자유롭게 실험을 반복할 수 있음
- 민감한 데이터를 반드시 내부에서만 처리해야 하는 경우 (Security First)
- 의료 정보, 금융 데이터, 사내 기밀 문서처럼 외부로 절대 유출되면 안 되는 데이터를 다룰 때
- 모든 요청과 응답이 내부 서버에서 처리되기 때문에,
- 외부 API 전송에 대한 보안 리스크를 원천적으로 차단할 수 있음
- 오프라인 환경 또는 폐쇄망에서 동작해야 하는 경우
- 인터넷 연결이 제한되거나 아예 없는 환경에서는 클라우드 API 자체를 사용할 수 없음
- 공공기관 내부망, 군 관련 시스템, 네트워크가 불안정한 현장 환경에서는 로컬 모델이 사실상 유일한 선택지
- 고빈도·고트래픽의 단순 요청이 반복되는 서비스
- 텍스트 분류, 키워드 추출, 간단한 요약처럼 비교적 가벼운 작업이 대량으로 반복되는 경우,
- 클라우드 API는 호출 횟수에 따라 비용이 급격히 증가함
- 로컬 방식은 초기 인프라만 갖추면 이후에는 요청이 늘어나도 비용 증가가 제한적
- AI 모델의 동작 원리나 시스템 구조를 깊이 있게 이해하려는 경우
- 로컬 환경에서는 모델이 CPU/GPU 자원을 어떻게 사용하는지,
- 프롬프트에 따라 어떤 식으로 응답이 달라지는지 직접 관찰할 수 있음
- 단순히 API를 사용하는 수준을 넘어, AI 시스템 자체를 이해하고 튜닝하고 싶은 경우에 매우 유용
This post is licensed under CC BY 4.0 by the author.