2. 어떤 LLM을 쓸 것인가 — 환경별 선택 가이드

자율 SRE를 만들겠다고 마음을 먹으면, 가장 먼저 부딪히는 질문이 있다. "어떤 LLM을 쓸 것인가."

이 질문에 대한 답은 기술이 아니라 보안이 결정한다.

운영 데이터를 외부에 보낼 수 있으면 Claude API를 쓰면 된다. 더 쉽고, 더 빠르고, 품질도 좋다. 데이터가 사내를 벗어나면 안 되는 환경이면 로컬 빅모델을 사내 GPU에 올려야 한다. 세팅은 복잡하지만 보안 문제가 없다.

이 편에서는 두 경로를 SRE 업무 관점에서 비교한다.

SRE가 알아야 할 LLM 기초

LLM 전문가가 될 필요는 없다. 운전을 하는 데 엔진 설계를 알 필요 없는 것처럼, SRE가 LLM을 도구로 쓰기 위해 알아야 할 건 세 가지다.

• 파라미터. 모델이 학습한 "지식의 양"이다. 7B(70억 개)짜리와 70B(700억 개)짜리는 추론 능력이 다르다. 단일 시스템 로그 분석은 30B급으로 가능하지만, 여러 시스템을 종합하는 복합 RCA는 70B 이상이나 Claude급이 필요하다.
• 토큰. LLM이 읽고 쓰는 단위다. 영어 1단어가 약 1~1.5토큰, 한국어 1글자가 약 1~2토큰이다. SRE 실무에서 중요한 감각은 이거다. Nginx access log 100줄이 대략 2,000~3,000토큰. syslog 100줄이 약 2,500~4,000토큰. JSON 알림 1건이 100~200토큰.
• 컨텍스트 윈도우. 모델이 한 번에 읽을 수 있는 토큰의 최대치다. 이게 SRE 업무에서 결정적인 차이를 만든다.

컨텍스트 윈도우가 32K면 전처리된 로그 기준으로 대략 1,000줄 정도를 넣을 수 있다. 200K면 로그 + 설정 파일 + Runbook + 과거 장애 이력까지 한꺼번에 넣을 수 있다. 다만 이건 서비스 특성에 따라 크게 달라진다. 로그 한 줄이 짧은 access log와 JSON 구조의 구조화 로그는 줄당 토큰 수가 몇 배 차이 나기 때문에, 본인 환경의 로그를 실제로 토큰 카운터에 넣어보는 게 가장 정확하다. 복합 장애 분석에서 이 컨텍스트 차이는 크다.

경로 A: Claude API

데이터를 외부에 보낼 수 있는 환경이면 이쪽이 정답에 가깝다.

세팅이 단순하다. Python SDK 설치하고 API 키 하나 넣으면 끝이다. GPU도 필요 없고, 모델 관리도 필요 없다. Anthropic이 알아서 한다.

import anthropic
 
client = anthropic.Anthropic()
message = client.messages.create(
    model="claude-sonnet-4-20250514",
    max_tokens=4096,
    messages=[{"role": "user", "content": prompt}]
)

이 코드 한 줄로 200K 컨텍스트, 최고 수준의 추론 능력, 한국어 지원을 쓸 수 있다.

모델 선택도 단순해지고 있다. 예전에는 작업별로 모델을 나눠 쓰는 게 일반적이었는데, 최근에는 Sonnet 급 모델의 성능이 이전 세대 최상위 모델을 넘어서면서 "그냥 하나의 좋은 모델로 전부 처리하는 게 낫다"는 방향으로 바뀌고 있다. 모델을 나누면 관리 포인트가 늘어나고, 작업별 라우팅 로직도 짜야 하는데, 성능 차이가 크지 않으면 복잡도만 올라가는 거다. SRE 자동화 용도라면 Sonnet 하나로 로그 분류부터 RCA, 포스트모템 작성까지 커버하는 게 현실적이다.

비용 최적화 방법도 있다. 프롬프트 캐싱을 쓰면 반복되는 시스템 프롬프트 부분의 비용을 줄일 수 있고, 급하지 않은 분석(포스트모템 작성 등)은 배치 API로 50% 할인을 받을 수 있다.

실제 SRE 용도의 비용을 추산해보면 이렇다. 하루 장애 알림 10건을 분석한다고 하자. 알림당 입력 2,000토큰(전처리된 로그) + 시스템 프롬프트 500토큰 + 출력 1,000토큰. Sonnet 기준으로 알림당 약 $0.02. 하루$0.2, 월 $6. 여기에 복잡한 RCA가 주 2\~3건 발생하면 추가$5~10. 포스트모템 자동 작성이 월 4~5건이면 추가 $3\~5. 합치면 월$15~25 수준이다. 이건 꽤 저렴하다.

실시간 감시까지 넣으면 비용이 올라간다. 10분 단위로 로그 배치를 보내면 하루 144회 호출. 서버 10대를 감시하면 하루 1,440회. 이 정도면 월 $100~200이 된다. 그래서 실시간 감시는 경로 B(로컬 모델)가 유리하고, 경로 A는 알림 기반 분석에 집중하는 게 현실적이다.

경로 B: 로컬 빅모델

데이터가 밖으로 나가면 안 되는 환경이면 이쪽이다. 통신사, 금융, 공공 같은 곳에서는 선택의 여지가 없다.

Ollama나 vLLM으로 오픈소스 모델을 사내 GPU에 올린다. Ollama는 설치가 간단하고 개인 실습에 좋다. vLLM은 프로덕션 서빙에 적합하다. 동시 요청 처리, 배치 추론, 모니터링 기능이 있다.

모델 선택은 GPU 메모리가 결정한다.

현재 SRE 용도로 쓸 만한 오픈소스 모델을 꼽으면 이렇다.

• Qwen3-30B-A3B. MoE(Mixture of Experts) 구조라서 전체 파라미터는 30B지만 실제 활성화되는 건 3B다. 추론 속도가 빠르면서도 품질이 꽤 괜찮다. RTX 4090 하나에 올라간다. 한국어 성능도 좋다.
• Qwen2.5-72B. A100이 있다면 이게 가장 무난하다. Claude에는 못 미치지만, RCA나 로그 분석을 충분히 할 수 있는 수준이다. 128K 컨텍스트를 지원한다.
• Llama 3.1-70B. 영문 로그 분석에 강하다. 128K 컨텍스트. 다만 한국어 성능은 Qwen보다 떨어진다. 한국어 Runbook이 많은 환경이면 Qwen이 나을 수 있다.

양자화는 Q4가 기본이다. Q4로 양자화하면 모델 크기가 원본의 약 25%로 줄어든다. 72B 모델도 A100 하나에 올릴 수 있다. SRE 로그 분석에서 Q4와 FP16의 품질 차이는 크지 않다. 로그 패턴 인식은 정밀한 수치 계산이 아니라 패턴 매칭에 가까워서, 양자화 손실 영향이 적다.

경로 B의 함정 — 추론 서버도 운영해야 한다

경로 B를 선택하면 한 가지를 더 생각해야 한다. LLM 추론 서버 자체가 운영 대상이 된다는 거다.

장애 대응 시스템이 장애를 감지하고 분석하려면, 추론 서버가 살아있어야 한다. 그런데 새벽 3시에 장애가 터졌는데, 추론 서버도 같이 죽어있으면? 장애를 잡아야 하는 시스템이 장애를 못 잡는 아이러니가 발생한다.

그래서 경로 B에서는 이런 것들을 추가로 고려해야 한다.

• 추론 서버 모니터링. GPU 사용률, 추론 지연, 요청 큐 길이를 Prometheus로 수집한다. vLLM은 /metrics 엔드포인트를 제공한다.
• 모델 업데이트. 새 모델 버전이 나오면 어떻게 교체할 것인가. 블루-그린 배포처럼 새 모델을 별도 인스턴스에 올리고, 테스트 후 전환하는 전략이 필요하다.
• GPU 장애 대응. GPU가 죽으면 어떻게 할 것인가. 예비 GPU가 있으면 좋고, 없으면 임시로 Claude API로 전환하는 fallback 구조를 만들어둘 수 있다. "평소에는 보안 때문에 로컬, 비상시에만 외부 API"라는 하이브리드 전략이다.

경로 A는 이런 고민이 없다. Anthropic이 서버를 운영하니까. 이게 경로 A가 "더 쉽다"고 말하는 이유다.

Microsoft는 LLM으로 20,000시간을 절감했다

Microsoft가 2025년 Build에서 Azure SRE Agent를 발표했다. LLM의 추론 능력으로 로그와 메트릭을 분석해서 RCA를 수행하고, 자연어 명령으로 Azure 리소스를 관리하는 서비스다.

흥미로운 건 이걸 내부에서 먼저 쓰고 있었다는 점이다. Microsoft 내부 프로덕트 팀에서 적용해 20,000시간 이상의 엔지니어링 시간을 절감했다고 한다. PagerDuty, Datadog, New Relic 등과 MCP로 연동되고, 자연어로 "이 VM의 CPU 사용률 추이를 보여줘"라고 하면 된다.

이건 경로 A의 프로덕션 사례다. 클라우드 API형 LLM을 운영 도구에 연동해서, 엔지니어가 수동으로 하던 진단과 분석을 자동화한 거다. 20,000시간이라는 숫자가 인상적이다. 팀 규모를 모르니 직접 비교는 어렵지만, 방향성은 명확하다.

두 경로 비교 — SRE 작업별

◎ 우수, ○ 양호, △ 제한적, ✗ 불가

핵심은 이거다. 기술적으로는 Claude가 거의 모든 면에서 우위다. 하지만 보안 요구사항이 경로를 결정한다. "이 로그를 외부에 보내도 되나?"라는 질문에 "아니오"가 나오면 경로 B밖에 없다.

어느 쪽을 고르든, 이 다음부터 다루는 아키텍처 — 전처리, 프롬프트, Agent, 안전장치 — 는 전부 공통이다.

다음 편에서는 운영 데이터를 LLM에 먹이는 방법을 다룬다. 같은 모델, 같은 프롬프트라도 입력 데이터 품질에 따라 분석 결과가 완전히 달라진다. 전처리 파이프라인, 컨텍스트 전략, RAG, 그리고 알림이 LLM에 도달하는 연동 아키텍처를 설계한다.