[LLM] 로컬 LLM(Llama 3 등)을 활용한 개인정보 보호 및 인프라 비용 절감

LLM을 서비스에 붙이기 시작하면 처음에는 기능 구현이 재미있습니다. 그런데 운영 단계로 들어가면 다른 문제가 보이기 시작합니다. 바로 개인정보와 비용입니다. 저희 팀도 클라우드 LLM을 사용하다가 어느 순간 로컬 LLM을 검토하게 된 경험이 있습니다.

로컬 LLM 도입을 검토하게 된 운영 환경 문제

초기에 저희 서비스는 외부 LLM API를 사용하고 있었습니다. 상담 요약, 로그 분석, 내부 운영 도구 자동화 같은 기능이었는데 GPT 계열 모델을 API 형태로 호출하는 구조였습니다.

처음에는 큰 문제가 없었습니다. 하지만 트래픽이 조금 늘어나면서 두 가지 문제가 동시에 보이기 시작했습니다. 개인정보 이슈와 API 비용이었습니다. 체감상 그렇습니다.

당시 내부 서비스 기준으로 LLM 요청이 초당 10에서 20 정도 발생했습니다. RPS 기준으로 보면 그렇게 높은 숫자는 아닙니다. 하지만 하루 토큰 사용량이 약 250만 토큰 정도까지 올라갔습니다.

월 비용으로 계산하면 약 1500달러 수준이었습니다. 기능 하나에 이 정도 비용이 지속적으로 발생한다는 것은 운영 입장에서 부담이 되더군요.

또 하나의 문제는 개인정보였습니다. 일부 요청에는 고객 이름, 이메일, 주문 정보 같은 데이터가 포함되었습니다. 물론 마스킹 처리를 하고 있었지만 운영 경험상 이런 부분은 항상 불안합니다. 

 

특히 민감했던 데이터 유형

로그를 분석해보니 다음 데이터가 LLM으로 전달되는 경우가 있었습니다.

고객 이메일, 주문 ID, 내부 사용자 ID, 상담 대화 내용 같은 정보였습니다. 이런 데이터는 외부 API로 전송되는 순간 관리 포인트가 늘어납니다. 생각보다 자주 발생합니다.

그래서 팀 내부에서 로컬 LLM 도입을 검토하기 시작했습니다.

 

Llama 3 기반 로컬 LLM 도입 의사결정 과정

로컬 LLM 도입을 검토하면서 두 가지 방법을 비교했습니다. 외부 LLM을 계속 사용할지 아니면 로컬 LLM을 구축할지였습니다. 이 부분은 팀 내부에서 꽤 논쟁이 있었습니다.

 

방법 A 외부 LLM API 유지

장점은 명확합니다. 인프라 관리가 필요 없습니다. 모델 업데이트나 GPU 관리 같은 것도 신경 쓸 필요가 없습니다.

또 하나 장점은 성능입니다. 최신 모델을 바로 사용할 수 있습니다. 복잡한 reasoning이나 코드 생성 같은 작업에서는 확실히 품질이 좋습니다.

하지만 단점이 있습니다. 비용이 계속 발생합니다. 그리고 데이터가 외부로 나갑니다. 보안 검토를 계속 해야 합니다.

 

방법 B 로컬 LLM 구축

장점은 두 가지입니다. 개인정보 보호와 비용입니다.

데이터가 내부 네트워크 안에서만 처리됩니다. 그리고 GPU 서버만 운영하면 추가 비용 없이 요청을 처리할 수 있습니다.

단점도 있습니다. 인프라 운영이 필요합니다. GPU 관리, 모델 배포, 메모리 튜닝 같은 작업이 생깁니다.

결론적으로 저희는 일부 기능을 로컬 LLM으로 이전하기로 결정했습니다. 특히 개인정보가 포함된 요청을 우선적으로 옮겼습니다. 

 

Llama 3 로컬 LLM 실전 구축 방법

로컬 LLM 구축에서 가장 중요한 것은 모델 실행 환경입니다. 저희는 Kubernetes 환경에서 GPU 노드를 사용했습니다. Llama 3 모델을 Ollama 기반으로 운영했습니다.

이 방식의 장점은 배포가 단순하다는 점입니다. 컨테이너 기반으로 모델을 운영할 수 있습니다.

version: '3'

services:
  llama:
    image: ollama/ollama
    container_name: llama3
    ports:
      - "11434:11434"
    volumes:
      - ollama:/root/.ollama

    # 운영 팁
    # 모델 캐시 디렉토리는 반드시 볼륨으로 분리합니다
    # 안 그러면 컨테이너 재시작 때 모델 다시 다운로드 됩니다

    deploy:
      resources:
        reservations:
          devices:
            - capabilities: [gpu]

volumes:
  ollama:

Spring Boot에서 로컬 LLM 호출

API 서버에서는 HTTP 방식으로 로컬 LLM을 호출했습니다. 구조는 외부 LLM API와 거의 동일합니다.

@Service
public class LocalLlmService {

    private final WebClient webClient = WebClient.create("http://llama:11434");

    public String generate(String prompt){

        // 운영 팁
        // timeout 반드시 설정합니다
        // 모델이 로드되는 순간 latency 튈 수 있습니다

        return webClient.post()
                .uri("/api/generate")
                .bodyValue(prompt)
                .retrieve()
                .bodyToMono(String.class)
                .block();
    }
}

처음 배포했을 때 latency가 약 800ms에서 1200ms 정도 나왔습니다. 외부 API보다 조금 느렸습니다.

하지만 내부 네트워크에서 처리되기 때문에 안정성은 좋았습니다. 체감상 장애 포인트가 줄어들었습니다.

로컬 LLM 운영의 현실적인 결론

로컬 LLM을 도입한다고 해서 모든 문제가 해결되는 것은 아닙니다. 생각보다 운영 포인트가 많습니다.

GPU 메모리 관리, 모델 업데이트, inference 성능 튜닝 같은 작업이 계속 필요합니다. 특히 모델 로딩 시간이 길어질 수 있습니다.

하지만 개인정보 보호 측면에서는 확실히 장점이 있습니다. 데이터가 외부로 나가지 않는다는 점은 운영팀 입장에서 마음이 편합니다.

비용 측면에서도 장점이 있습니다. GPU 서버 한 대로 하루 수십만 요청을 처리할 수 있습니다. 토큰 기반 비용이 없다는 점은 꽤 큰 차이입니다.

결론적으로 모든 LLM을 로컬로 옮길 필요는 없습니다. reasoning이 필요한 작업은 여전히 외부 모델이 좋습니다.

하지만 개인정보가 포함된 작업이나 단순 처리 작업은 로컬 LLM이 꽤 현실적인 선택입니다.