온프레미스 LLM, 망분리 환경에서 안전하게 운영하기

지금까지의 안내서는 "외부 LLM에 넣기 전에 비식별하라"를 전제했습니다. 하지만 어떤 데이터는 비식별을 해도 밖으로 내보내면 안 되고, 어떤 조직은 애초에 내부망이 인터넷과 분리돼 있어 클라우드 API를 부를 수조차 없습니다. 이럴 때 답은 데이터를 가공해 내보내는 게 아니라, 모델을 데이터가 있는 곳으로 가져오는 것입니다 — 온프레미스 LLM입니다.

🎯 이 장의 목표

데이터 경계·업무 품질·운영 역량으로 온프레미스 필요성을 판단할 수 있습니다.
용도·한국어·라이선스·하드웨어 제약을 함께 보고 모델 후보를 선택할 수 있습니다.
호환 API 연결과 업무 행동의 호환 여부를 다른 검증 대상으로 구분할 수 있습니다.
골든셋 비교·공급망 기록·롤백 조건으로 반입 후보를 검토할 수 있습니다.

온프레미스가 맞는가 — 먼저 판단

온프레미스는 공짜가 아닙니다. 하드웨어·운영 부담을 지는 대신 데이터 통제를 얻는 거래입니다.

상황	권장	이유
인터넷 분리 내부망	온프레미스만 가능	클라우드 호출 자체가 불가
비식별해도 못 내보내는 데이터	온프레미스	데이터가 조직 밖으로 안 나감
공개 자료·비민감 업무	클라우드	더 강한 모델을 손쉽게
대량·고난도 추론 필요	클라우드 또는 하이브리드	로컬 모델은 최상위 성능에 못 미침

📌 핵심

하이브리드도 선택지입니다. 민감 데이터가 닿는 단계(전사·비식별·1차 분류)는 온프레미스로, 공개 자료 기반 작업은 클라우드로 나눕니다. 판단 기준은 언제나 "이 데이터가 조직 밖으로 나가도 되는가"입니다.

1. 모델 선택 — 크기·양자화·한국어

로컬 모델은 세 축으로 고릅니다.

크기(파라미터): 클수록 똑똑하지만 무겁습니다. 7~8B는 일반 사무용 GPU/고사양 CPU에서 돌고, 14~32B는 전용 GPU가 필요합니다. 분류·요약 같은 정형 작업엔 중소형이면 충분합니다.
양자화: 가중치 정밀도를 낮춰 메모리를 줄입니다(예: Q4_K_M). 4비트 양자화면 8B 모델이 6GB 안팎에 들어갑니다 — 신고 전사의 INT8 양자화와 같은 발상입니다.
한국어: 한국어 성능은 크기와 별개입니다. 한국어를 잘하는지, 라이선스가 업무 사용을 허용하는지 반드시 확인합니다.

💡 팁

양자화가 왜 통하나 — 사진을 원본 화질에서 적당한 화질로 줄여 저장하면 파일은 작아지는데 눈으로는 차이를 거의 못 느끼는 것과 같습니다. 모델의 수많은 가중치 숫자를 성기게(예: 16비트 → 4비트) 저장해 메모리를 확 줄이되, 답 품질은 크게 상하지 않는 지점을 고르는 것입니다. 다만 너무 줄이면(2~3비트) 사진이 뭉개지듯 답도 흐트러지니, 4비트 안팎을 무난한 절충점으로 많이 씁니다.

레포 레이더의 로컬 LLM 도구(Ollama·llama.cpp·vLLM)로 모델을 받아 띄웁니다.

BASH

# Ollama — 가장 단순한 로컬 실행. 모델을 받아 OpenAI 호환 서버로 띄운다
ollama pull qwen2.5:7b          # 한국어 지원·경량 모델 예시(용도에 맞게 선택)
ollama run  qwen2.5:7b          # 대화형 확인
# 서버는 http://localhost:11434 에서 OpenAI 호환 /v1 엔드포인트를 연다

2. OpenAI 호환 API — 코드는 거의 그대로

온프레미스로 옮길 때 가장 큰 걱정이 "코드를 다 다시 짜야 하나"인데, 그렇지 않습니다. 로컬 서버 대부분이 OpenAI 호환 API를 제공하므로, 기존 코드에서 base_url만 로컬로 바꾸면 됩니다.

표준 콘센트에 비유하면, 제조사가 달라도 플러그 모양이 같으면 그대로 꽂히는 것과 같습니다. 여러 로컬 서버가 OpenAI의 요청·응답 형식을 똑같이 따르기로 하면서 이 형식이 사실상 공용 규격이 됐고, 그래서 접속 주소만 로컬로 바꿔도 나머지 코드는 콘센트에 꽂히듯 그대로 동작합니다.

PYTHON

from openai import OpenAI

# 클라우드였다면: OpenAI() — 여기선 base_url만 로컬로. 데이터가 밖으로 안 나간다
client = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama")  # 키는 형식상

resp = client.chat.completions.create(
    model="qwen2.5:7b",
    messages=[
        {"role": "system", "content": "너는 소방 민원 분류 보조다. 주어진 유형에서만 고른다."},
        {"role": "user",   "content": "화재 관련 민원인가요? ..."},
    ],
    temperature=0.1,   # 분류·검산 작업은 낮게 — 재현성 확보
)
print(resp.choices[0].message.content)

RAG·분류 파이프라인의 LLM 호출부를 이 한 줄로 바꾸면 온프레미스로 이전됩니다. 평가 도구도 마찬가지입니다 — RAG 평가의 promptfoo는 ollama:chat:모델명 또는 apiBaseUrl로 로컬 모델을 그대로 평가합니다.

3. 검증 — 로컬 모델은 클라우드보다 약하다

온프레미스의 대가는 성능입니다. 중소형 로컬 모델은 최상위 클라우드 모델보다 약하고, 특히 환각·지시 이탈·한국어 미묘함에서 차이가 납니다. 그래서 "돌아간다"와 "믿고 쓸 만하다"는 다릅니다 — 반드시 검증합니다.

앞서 만든 골든셋과 회귀 평가를 그대로 씁니다. 클라우드 모델에서 재던 같은 골든셋을 로컬 모델로 돌려 점수 차이를 정량화합니다.

YAML

# promptfooconfig.yaml — 같은 골든셋으로 클라우드 vs 로컬 나란히 비교
providers:
  - id: openai:chat:qwen2.5:7b        # 로컬(Ollama)
    config: { apiBaseUrl: http://localhost:11434/v1, apiKey: ollama }
  - openai:gpt-4o-mini                # 클라우드 기준선(연결 가능할 때만)
defaultTest:
  assert:
    - type: llm-rubric
      value: 처분·과태료를 단정하지 않고 근거를 제시한다
# tests: 22편에서 만든 골든셋 그대로

점수 차가 업무 허용 범위 안이면 온프레미스로 갑니다. 범위를 벗어나면 더 큰 모델, 프롬프트 개선, 또는 하이브리드를 검토합니다 — "로컬이니까 이 정도는 감수"는 안 됩니다. 소방 업무의 품질 기준은 인프라가 아니라 현장이 정합니다.

허용 범위를 어떻게 가르는지 구체화하면 이렇습니다(가상 예). 같은 골든셋 20문항을 클라우드와 로컬에 나란히 돌렸더니 로컬이 몇 문항에서 조문 인용을 빠뜨렸다고 합시다. 이때 중요한 건 '몇 개 틀렸나'보다 어떤 문항이 틀렸나입니다 — 빠뜨린 게 민원 답변처럼 틀리면 안 되는 유형이면 로컬은 아직 이르고, 내부 참고용 요약이면 감당할 만합니다. 숫자 하나가 아니라 '어느 업무에 쓸 것인가'로 허용선을 정합니다.

⚠️ 흔한 실수

로컬 모델은 한 번에 넣을 수 있는 입력 길이(컨텍스트 창)가 클라우드보다 짧은 경우가 많습니다. 클라우드에서 잘 돌던 긴 RAG 문맥을 그대로 로컬에 넣으면 뒷부분이 조용히 잘려 근거가 누락될 수 있으니, 이전할 때 입력 길이 한도도 함께 확인하세요.

4. 폐쇄망 반입 — 공급망도 점검한다

인터넷 분리망은 모델·라이브러리를 온라인으로 받을 수 없어, 외부에서 받아 반입합니다. 이 경로 자체가 보안 지점입니다.

TEXT

- [ ] 모델 가중치·라이브러리를 공식 출처에서만 받았습니다(체크섬 확인).
- [ ] 반입 파일을 검역망에서 악성코드 검사 후 내부망에 들였습니다.
- [ ] 모델 라이선스가 공공·업무 사용을 허용하는지 확인했습니다.
- [ ] 오프라인 설치가 되도록 의존성을 함께 반입했습니다(온라인 설치 시도 차단).
- [ ] 반입 버전·출처·체크섬을 기록으로 남겼습니다.

💡 팁

로컬 LLM 도구·모델도 소프트웨어 공급망의 일부입니다. "로컬이라 안전"이 아니라, 반입하는 것이 무엇인지 아는 것이 안전입니다.

운영 루틴 한 장

언제	무엇을	통과 기준
도입 검토 시	온프레미스 vs 클라우드 판단	"데이터가 밖으로 나가도 되는가" 기준
모델 선정 시	골든셋으로 클라우드 대비 품질 측정	업무 허용 범위 안
모델·버전 교체 시	골든셋 회귀	이전 대비 하락 없음
반입 시	공급망 체크리스트	출처·체크섬·검역 전부 통과

▸ 소방 활용 포인트

인터넷과 분리된 내부망이나 가장 민감한 데이터에도 데이터를 밖으로 내보내지 않고 AI를 활용할 수 있게 하고, base_url 한 줄 교체로 기존 파이프라인을 그대로 이전합니다. 단 로컬 모델의 품질은 반드시 검증하고, 온프레미스라도 "AI는 참고, 최종 판단은 사람"이라는 원칙은 그대로입니다.

설계 판단

배치 위치는 최신 모델을 얻는 문제만이 아니라 데이터·품질·운영 책임의 경계를 정하는 문제입니다. 로컬이라는 이유만으로 안전·적합한 판정을 내리지 않습니다.

방식	맞는 상황	트레이드오프	사람이 확인할 것
클라우드 기준선 유지	외부 전송이 허용되고 품질·운영 편의가 우선인 때	제공자·네트워크·계약 경계에 의존	전송 가능한 자료와 보존 조건
온프레미스 전용	자료가 조직 밖을 벗어나지 않아야 하고 내부 운영 역량이 있을 때	모델·하드웨어·패치·공급망을 직접 책임	골든셋 품질과 반입 이력
업무별 분리	민감 업무와 공개 자료 업무의 경계가 명확할 때	라우팅·평가·로그 구조가 복잡해짐	업무별 허용 환경과 오라우팅 신호

💡 팁

API 호환은 행동 호환이 아닙니다. 같은 요청 형식을 받아도 입력 길이, 구조화 출력, 도구 호출, 거절 표현은 달라질 수 있습니다. 연결 성공 뒤에 같은 골든셋으로 업무 계약을 다시 검증하는 이유입니다.

운영 시나리오

아래는 특정 제품·기관의 실제 사건이 아닌 가상 운영 연습입니다. 성능 수치를 지어내기보다 기준선과 행동 차이를 재현하는 과정에 초점을 둡니다.

가상 시나리오 1: 긴 RAG 근거의 뒷부분이 조용히 빠진 경우

탐지: 로컬 후보는 응답을 내놓았지만, 골든 질문의 필수 출처가 특히 긴 문맥에서 반복해 빠졌습니다.
원인 가설: 호환 API는 정상 응답했지만 로컬 모델의 입력 길이 한계와 토큰 계산 차이 때문에 뒷부분 근거가 잘렸다고 봅니다.
대응: 해당 업무의 자동 출력을 멈추고, 실제 입력 토큰·자림 로그·검색 조각 순서를 확인합니다. 근거 수를 무조건 줄이지 않고 청킹·검색 범위·사람 확인 후보를 비교합니다.
재발 확인: 첫·중간·마지막 근거가 모두 필수인 합성 픽스처를 재실행해 각 출처가 응답에 연결되는지 확인한 후 담당자가 활용 범위를 승인합니다.

가상 시나리오 2: 폐쇄망 반입 묶음의 기록이 서로 맞지 않은 경우

탐지: 반입 목록의 모델·런타임·토크나이저 버전과 실제 검역 환경의 파일 지문·라이선스 기록이 일치하지 않았습니다.
원인 가설: 반입 묶음을 다시 만드는 과정에서 의존성 하나가 바뀌었지만 명세서와 체크섬은 예전 값을 유지했다고 봅니다.
대응: 반입을 거부하고 기존 검증 버전을 유지합니다. 공식 출처에서 묶음을 재구성하고 파일 목록·라이선스·체크섬·의존성 정보를 하나의 승인 기록으로 묶습니다.
재발 확인: 네트워크가 없는 검증 환경에서 새 묶음의 설치·기동·골든셋·롤백을 재현하고, 전 단계 기록을 사람이 확인한 뒤에만 반입합니다.

한계와 리스크

리스크	발생 조건	영향	완화·사람 승인
로컬 로그·백업의 민감정보 누적	입력·응답·디버그 자료를 내부망이라는 이유로 제한 없이 남김	내부 권한자나 백업 경로를 통한 노출 가능성	본문 로깅을 최소화하고 보존·접근·폐기를 보안 담당자가 승인
약한 모델의 자신 있는 오답	연결 성공을 품질 통과로 오해함	근거 누락·구조화 출력 깨짐·범위 밖 답변	같은 골든셋과 필수 단언을 비교하고 업무 담당자가 허용 범위 승인
공급망·라이선스 표류	모델·런타임·의존성의 출처·버전·사용 조건을 같이 고정하지 않음	반입 후 재현 불가·보안 위험·사용 조건 위반	검역 환경에서 명세·지문·라이선스를 대조하고 반입 책임자 승인

자주 묻는 질문

Q. 내부망에서 돌아가면 보안 검토가 끝나나요?

아닙니다. 계정·로그·백업·모델 반입·관리자 권한이 새로운 공격·노출 경로가 됩니다. 네트워크 위치와 데이터·운영 통제를 별도로 검토합니다.

Q. OpenAI 호환 API로 연결되면 기존 기능이 그대로 보장되나요?

아닙니다. 요청·응답 모양이 비슷하다는 뜻이지 입력 길이, 도구 호출, 구조화 출력, 거절 행동이 같다는 뜻은 아닙니다. 업무 픽스처로 다시 확인합니다.

Q. 더 큰 모델이면 항상 더 나은 선택인가요?

그렇지 않습니다. 필요 업무의 품질, 지연, 메모리, 전력, 라이선스, 운영 여력을 함께 봅니다. 최종 선택은 골든셋의 항목별 실패와 업무 허용 범위로 합니다.

Q. 폐쇄망 모델은 어떻게 갱신하나요?

공식 출처에서 구성한 반입 묶음을 검역·검증 환경에서 먼저 재현합니다. 명세·체크섬·라이선스·골든셋·롤백을 확인한 뒤 책임자 승인으로 내부망에 반입합니다.

핵심 정리

온프레미스는 배치 위치이며 보안·품질·운영의 자동 보증이 아닙니다.
API 호환 뒤에도 입력 길이·근거·구조화 출력·거절 행동을 다시 검증합니다.
반입 묶음은 모델만이 아니라 런타임·토크나이저·의존성·라이선스의 고정된 집합입니다.
품질이 허용 범위에 들지 않으면 로컬이라는 이유로 타협하지 않고 활용 범위를 줄입니다.

다음 단계

개인정보 비식별 파이프라인: 내부 모델에 전달하는 자료의 놓침·준식별자·가명 대응표 경계를 설계합니다.
RAG 운영 평가: 로컬·기준선 모델을 같은 골든셋과 필수 단언으로 비교합니다.
안전한 AI 운영 도구: 모델·런타임·관측·공급망 요소를 어떤 운영 층에 놓을지 확인합니다.

사람 검토 체크리스트