LLM 개발 기업이 엔터프라이즈급의 보안이 확보된 프로덕션 시스템을 구축하는 방법

원래 CoreProse KB-incidents에 게시되었습니다.

1. 엔터프라이즈의 문제: 생성형 AI (GenAI) 데모에서 감사 가능한 시스템으로

2026년까지 CAC 40 기업의 83%가 최소 하나 이상의 LLM을 프로덕션(Production) 환경에서 운영하게 되겠지만, 여전히 많은 기업이 불투명한 동작, 취약한 거버넌스(Governance), 그리고 불안해하는 이사회와 규제 기관 문제에 직면해 있습니다.[2]

전문 LLM 기업들은 인상적인 데모와 통제 가능하고 감사 가능한(Auditable) 시스템 사이의 간극을 메우기 위해 존재합니다.

LLMOps가 등장한 이유는 "한 번 라이선스를 취득하면 영원히 실행한다"는 방식이 GPT급 시스템, Gemini, 또는 Dolly 스타일의 엔터프라이즈 모델과 같은 확률론적이고 지시 수행(Instruction-following) 모델에는 맞지 않기 때문입니다.[1][3] 이러한 시스템들은 다음과 같은 특징을 가집니다:

시간이 지남에 따라 동작이 표류(Drift)함
취약한 통합(Integration)이 누적됨
능동적인 관리 없이는 갑자기 너무 느려지거나 비용이 너무 많이 들 수 있음[1][3]

이제 엔터프라이즈 구매자들은 다음과 같은 기준으로 LLM 플랫폼을 평가합니다:

품질 (Quality): 정확도, 작업 완료율, 환각(Hallucination) 발생률
성능 (Performance): 실제 워크로드에서의 지연 시간(Latency) 및 처리량(Throughput)
안전성 (Safety): 유해 콘텐츠, 정보 유출, 정책 위반

LLMOps는 도입 과정을 일회성 API 호출이 아니라 품질, 비용 및 안전성에 대한 지속적인 측정과 제어로 재정의합니다.[3]

이와 병행하여, LLM 보안은 이제 모델, 데이터 파이프라인, 인프라(Infra), 인터페이스를 아우르는 엔드 투 엔드(End-to-end) 방식으로 이루어지며, 프롬프트 인젝션 (Prompt Injection), 학습 데이터 오염(Training-data poisoning), 모델 탈취, 그리고 공급망 리스크를 강조하는 OWASP Top 10 for LLMs와 같은 카탈로그의 안내를 받습니다.[4]

💼 현장의 일화

30명 규모의 한 핀테크 기업은 첫 번째 벤더의 "챗봇"이 감사(audit)를 통과하지 못하자(데이터 처리 기록, 재현 가능한 로그, 또는 레드팀(red-team) 증거 부재), 두 번째 부티크 LLM 기업을 고용했습니다. 두 번째 기업은 리스크 레지스터(risk register), 모델 카드(model cards), 추적 가능한 로그, 그리고 ISO-27001 통제 항목에 매핑된 롤백 계획(rollback plans)을 포함한 LLMOps + MLSecOps 런북(runbook)을 제시하며 승리했습니다.[2][7]

승리하는 기업들은 DevOps, MLOps, 보안, 그리고 법률을 하나의 맞춤형 인도 프로세스(delivery motion)로 결합하여, 자신들을 AI 시스템의 장기적인 운영자로 포지셔닝합니다.[1][7]

⚡ 미니 결론: 승리하는 제안은 "4주 만에 API를 연결해 드립니다"가 아니라, "우리가 이것을 수년간 안전하게 운영합니다"입니다.

2. 거버넌스(Governance), AI 법(AI Act), 그리고 규제 등급 설계

데모를 넘어, 거버넌스(governance)가 핵심이 됩니다. 시스템이 감사와 규제 심사를 통과할 수 있는가 하는 점입니다. 유럽에서 LLM 거버넌스는 GDPR과 EU AI Act에 의해 형성되며, 이는 개인정보 및 민감 데이터의 추적 가능성(traceability), 감사 가능성(auditability), 그리고 책임 있는 처리를 요구합니다.[2][11]

LLM 기업들에게 이것은 단순한 문서화의 문제가 아니라 아키텍처(architecture) 문제입니다.

실용적인 거버넌스 프로그램은 통상적으로 네 가지 기둥 위에 세워집니다:[2]

리스크 평가 (Risk assessment): 유스케이스(use-case) 카탈로그, 영향 분석, DPIA
역할 및 책임 (Roles and responsibilities): 비즈니스 소유자(business owner), 모델 소유자(model owner), 데이터 보호 책임자(DPO), 정보보호 최고책임자(CISO)
모델 생애주기 제어 (Model lifecycle control): 승인, 변경 관리, 폐기(decommissioning)
침해 사고 대응 (Incident response): 유출, 유해한 출력, 그리고 드리프트(drift)에 대한 플레이북(playbooks)

이러한 요소들은 아키텍처에 인코딩되어야 합니다: 무엇이 로그로 남는지, 어떤 식별자가 저장되는지, 프롬프트/출력이 어떻게 비식별화(redacted)되는지, 그리고 오버라이드(overrides)가 감사 추적(audit trails)에 어떻게 기록되는지 등이 포함됩니다.[2]

AI 법(AI Act)은 위험 기반 분류(최소, 제한, 고위험, 수용 불가능)를 도입하며 각기 다른 의무를 부여합니다.[11] LLM 기업들은 일반적인 유스케이스를 리스크 클래스(risk classes)에 명확하게 매핑할 필요가 있습니다. 예를 들면 다음과 같습니다:[11]

고객 지원 코파일럿 (Customer support copilot) → 일반적으로 콘텐츠 중재 (content-moderation) 업무를 포함하며 낮은 리스크 (limited risk) 수준임
언더라이팅 의사결정 지원 (Underwriting decision support) → 종종 **높은 리스크 (high risk)**를 가지며, 엄격한 테스트, 인간의 감독 (human oversight), 그리고 문서화가 필요함
보안 운영 어시스턴트 (Security operations assistant) → 핵심 인프라에 미치는 영향으로 인해 **높은 리스크 (high risk)**가 될 수 있음

높은 리스크를 가진 시스템이나 민감한 시스템은 확장된 거버넌스 (governance)를 필요로 합니다: 모델 동작 문서화 (model-behavior documentation), 데이터 출처 기록 (data-provenance records), 체계적인 테스트, 그리고 인간의 검토 및 이의 제기를 위한 명시적인 메커니즘이 필요합니다.[2][11]

💡 설계 단계부터 고려하는 거버넌스 (Governance-by-design) 스타터 키트

GDPR 및 AI Act (AI 법안)와 정렬된 템플릿을 도입하여 차별화하십시오:[2][11]

LLM에 특화된 DPIA (데이터 보호 영향 평가) 체크리스트
리스크 레지스터 (Risk-register) 스키마 (위협, 통제, 잔여 리스크)
모델 카드 (Model card) 및 평가 서류 (evaluation-dossier) 형식
프롬프트, 출력, 도구 호출 (tool calls)을 위한 불변의 감사 로그 (Immutable audit-log) 스키마

📊 미니 결론: 거버넌스를 하나의 제품으로 취급하십시오: 재사용 가능한 템플릿과 감사를 거의 일상적인 업무로 만드는 아키텍처를 결합하십시오.

3. 프로덕션급 플랫폼을 위한 LLMOps 및 MLSecOps 기반 기술

거버넌스가 정의되면, 이를 운영화 (operationalized)해야 합니다. LLMOps는 모델이 빠르고 정확하며 정책에 부합하도록 유지하기 위해 모델의 지속적인 "관리 및 공급 (care and feeding)"에 집중할 수 있도록 MLOps를 확장한 것입니다.[1][3]

견고한 엔터프라이즈 LLMOps 스택에는 일반적으로 다음이 포함됩니다:[1][3]

배포 워크플로 (Deployment workflows): 블루/그린 (blue/green), 카나리 (canary), 트래픽 분할 (traffic splitting)
구성 및 버전 관리 (Configuration + versioning): 프롬프트, 시스템 메시지, 도구 스키마를 아티팩트 (artifacts)로 관리
라우팅 (Routing): 정책 기반 모델 선택 (기본값은 소형 모델, 폴백(fallback)은 대형 모델)
텔레메트리 (Telemetry): 지연 시간 (latency), 토큰 사용량, 안전 위반, 사용자 피드백
자동 롤백 (Automated rollback): 오류율 또는 안전 사고 임계값 발생 시 복구

MLSecOps는 보안과 컴플라이언스 (compliance)를 이 라이프사이클에 도입합니다: 학습 및 추론 데이터 보호, 적대적 공격 (adversarial attacks) 완화, 그리고 개발, 배포, 모니터링 전반에 걸친 정책 강제화를 수행합니다.[7] 이는 다음 사항들을 명시적으로 다룹니다:

편향성 및 공정성 (Bias and fairness) 문제
개인정보 및 지식재산권 (IP) 유출
악성코드 및 유해 콘텐츠 생성
공급망 취약점 (Supply-chain vulnerabilities) [7]

LLMOps, MLSecOps, 그리고 기존의 SecOps를 결합하면, 보안 통제 항목을 나중에 덧붙이는 것이 아니라 CI/CD 과정에서 코드로서 표현(controls as code)할 수 있습니다. [7][8] 예를 들어:

# 의사 파이프라인 (Pseudo-pipeline): LLM 릴리스
stages:
  - security_static
...

⚠️ 핵심 실천 사항: 안전성(Safety) 및 거버넌스 게이트(Governance gates)를 LLM 서비스를 빌드하고 배포하는 것과 동일한 파이프라인 내에서 강력한 차단 요소(Hard blockers)로 만드십시오. [7][3]

이를 위해서는 데이터 과학, DevOps, 보안, IT 등 다학제적 팀이 LLM 플랫폼을 중심으로 공유된 런북(Runbooks)과 SLO(서비스 수준 목표: 지연 시간, 에러율, 안전 사고 예산)를 운영해야 합니다. [1][7]

⚡ 소결론: 당신은 단순한 챗봇을 판매하는 것이 아닙니다. 운영(Ops)과 보안(Sec)이 내장된 살아있는 LLM 플랫폼을 판매하는 것입니다.

4. 보안 아키텍처: 위협 모델에서 가드레일(Guardrails)까지

운영 중추(Operational backbone)가 갖춰졌다면, 보안 아키텍처는 LLM 특유의 위협을 엔드 투 엔드(End-to-end)로 다루어야 합니다. LLM 보안은 다음 사항들을 보호합니다:

모델 아티팩트 (Model artifacts)
데이터 파이프라인 (학습, 검색, 로깅)
런타임 인프라 (Runtime infrastructure)
사용자 인터페이스 및 에이전트 (User interfaces and agents) [4]

AI 보안 태세 관리 (AI-security-posture-management) 도구는 이러한 자산의 목록을 작성하고 위험을 평가하는 데 도움을 줍니다. [4]

프롬프트 인젝션 (Prompt injection), 데이터 포이즈닝 (Data poisoning), 모델 유출 (Model exfiltration)과 같은 위협은 OWASP Top 10 for LLM 애플리케이션에 공식화되어 있으며, 기본 위협 모델에 포함되어야 합니다. [4][6] 실무적인 관점은 다음과 같습니다:

계층 (Layer)	위협 (Threat)	통제 (Control)
프롬프트 계층 (Prompt layer)	프롬프트 인젝션 (Prompt injection)	입력 필터, 콘텐츠 샌드박스, 허용 목록 (Allow-list)
...

보안 모범 사례는 생성 모델의 예측 불가능성을 제한하기 위해 결정론적 검증 (Deterministic validation)과 엄격한 액세스 제어를 강조합니다. [6] 기술로는 다음이 포함됩니다:

JSON 스키마 검증 (JSON-schema validation) 및 정규 표현식 가드 (Regex guards)
민감한 작업 앞단의 정책 엔진 (예: OPA)
도구 및 데이터에 대한 강력한 인증 및 세분화된 권한 부여 (Granular authorization) [6]

CISO(정보보호최고책임자)의 관점에서, LLM은 어떤 AI 리스크를 수용, 완화 또는 전가할지 결정하기 위해 자산 식별(Asset discovery), 위협 모델링(Threat modeling), 그리고 영향 분석(Impact analysis)을 재검토할 것을 요구합니다. [5] 그 새로움은 전반적인 거버넌스 규율이 아니라 벡터(Vectors)에 있습니다. [5]

AI가 SecOps(보안 운영) 내부에서—경보 분류(Alert triage), 조사 요약, 또는 플레이북 초안 작성 등을 위해—사용될 때, SOC(보안 운영 센터) 팀은 네트워크와 엔드포인트에 대한 지속적인 가시성을 확보해야 하며, AI의 동작이 사고 대응(Incident-response) 프로세스와 일치하도록 보장해야 합니다. [8]

💡 가드레일 패턴 (Guardrail pattern)

영향력이 큰 도구(예: "사용자 비활성화", "IP 차단")의 경우, 동작을 가드레일 서비스로 감싸야 합니다: [6]

LLM이 동작을 JSON 형식으로 제안합니다.
스키마 검증기(Schema validator)가 타입/범위를 강제합니다.
정책 엔진(Policy engine)이 사용자, 컨텍스트, 리스크를 확인합니다.
그제서야 SOAR 또는 티켓팅 API가 호출됩니다.

📊 소결론: LLM을 강력하지만 신뢰할 수 없는 구성 요소로 취급하고, 결정론적인(Deterministic) 보안 메커니즘으로 둘러싸야 합니다.

5. 데이터 주권, 온프레미스(On-Prem) LLM, 그리고 배포 모델

보안, 거버넌스, 그리고 배포는 밀접하게 결합되어 있습니다. 민감하거나 규제 대상인 데이터를 보유한 많은 조직은 퍼블릭 클라우드 API에 의존할 수 없으며, 대신 자체 키를 사용하여 온프레미스 또는 엄격하게 제어되는 배포 방식을 요구합니다. [10]

이는 금융, 의료, 그리고 핵심 인프라 분야에서 흔히 나타납니다.

현대적인 온프레미스 플랫폼은 보안이 유지되면서도 여전히 빠를 수 있음을 보여줍니다. 최적화된 배포 방식은 엔터프라이즈 지원을 유지하면서도 단일 가상 CPU에서 약 10ms의 지연 시간(Latency)과 350 RPS 이상의 처리량을 기록했다고 보고되었습니다. [10]

이는 "보안 == 느림"이라는 관념에 도전합니다.

Mistral과 같은 벤더들은 다음과 같은 도메인 특화 AI를 강조합니다: [9]

엄격한 데이터 격리 (Data isolation)
주권 및 지역적 데이터 경계 (Sovereign and regional data boundaries)
감사 및 규제 기관에 대응 가능한 거버넌스

LLM 기업으로서 귀하가 제공해야 할 전형적인 배포 옵션은 다음과 같습니다: [9][10]

온프레미스 (On-prem): 에어갭(Air-gapped) 또는 프라이빗 데이터 센터 GPU 클러스터
프라이빗 클라우드 (Private cloud): 지역 거주성(Regional residency)을 보장하는 싱글 테넌트 VPC
온디바이스/엣지 (On-device/edge): 엔드포인트 또는 산업용 장비를 위한 양자화된(Quantized) 모델

💡 디자인 팁 (Design tip): 참조 아키텍처(Reference architectures)에서 deployment_mode = {on_prem|private_cloud|saas}를 일급 변수(First-class variable)로 취급하고, 이를 바탕으로 로깅(Logging), 라우팅(Routing), 백업 패턴을 도출하십시오. [10]

성숙한 거버넌스 프레임워크는 각 모드에서의 데이터 흐름을 반드시 다루어야 합니다. 프롬프트(Prompts), 검색된 문서(Retrieved docs), 로그(Logs), 출력(Outputs), 그리고 모니터링 이벤트(Monitoring events)는 보존(Retention), 액세스(Access), 국가 간 전송(Cross-border transfer)에 관한 명확한 규칙이 필요합니다. [2][11]

⚡ 소결론 (Mini-conclusion): "우리는 귀사의 하드웨어(Metal) 위에서, 귀사의 키(Keys)를 사용하여, 완전한 원격 측정(Telemetry) 및 감사(Audits)와 함께 이를 실행합니다"라고 말할 수 있을 때, 규제 대상 고객으로부터의 신뢰도가 높아집니다.

6. 도메인 특화 커스텀 (Domain-Specific Customization): RAG, 파인튜닝 (Fine-Tuning), 그리고 소유권

배포 방식이 결정되면, 가치는 도메인 지식을 내재화하는 것에서 나옵니다. 엔터프라이즈급의 영향력은 순정 모델(Vanilla models)에서 나오는 경우가 드물며, RAG와 파인튜닝(Fine-tuning)을 통해 창출됩니다. [3][9]

RAG: 광범위하거나 빈번하게 변경되는 코퍼스(Corpora, 예: 정책, 지식 베이스(KBs), 티켓)에 가장 적합
지시문/정책 파인튜닝 (Instruction/policy finetune): 안정적인 동작과 안전 규범을 위해 사용
태스크 특화 파인튜닝/사전 학습 (Task-specific finetune/pre-train): 좁고 위험도가 높은(High-stakes) 작업을 위해 사용

Mistral이 설명하는 것과 같은 커스텀 모델 프로그램은 사전 학습(Pre-training), 사후 학습(Post-training), 그리고 파인튜닝(Finetuning)을 통해 독점 데이터(Proprietary data)를 프런티어 모델(Frontier models)과 결합하여, 정책 및 워크플로와 정렬된 도메인 특화 시스템을 생성합니다. [9]

규제 산업 분야에서는 단순히 API 액세스를 임대하는 것이 아니라, 커스텀된 모델 아티팩트(Model artifacts)와 배포 환경을 직접 소유함으로써 컴플라이언스(Compliance)를 단순화하고 개인정보 보호 및 동작 보증을 강화할 수 있습니다. [2][9]

💼 예시: 법률 코파일럿 (Legal copilot)

법률 사무소는 다음과 같은 요소들을 결합할 수 있습니다:

내부 지식 베이스 및 판례 데이터베이스에 대한 RAG
안전 규범이 정렬된 지시문 파인튜닝 (초안에 고객 식별 텍스트 포함 금지, 보수적인 언어 사용)
암호화된 벡터 스토어(Vector stores) 및 서명된 코퍼스(Signed corpora)를 포함한 온프레미스(On-prem) 배포

LLM 기업은 커스텀화를 다음과 같은 지속적인 루프로 구성해야 합니다: [3][9]

피드백 수집
품질/안전 평가(Evals) 수행
재학습(Retrain), 재순위화(Re-rank), 또는 프롬프트 조정
재배포 및 모니터링

프롬프팅 (Prompting)이나 RAG (검색 증강 생성)에 의존할 것인지, 아니면 파인튜닝 (Finetuning)을 수행할 것인지를 결정할 때는 정확도 (Accuracy), 지연 시간 (Latency), 안전 사고율 (Safety-incident rate), 그리고 비용 (Cost)과 같은 LLMOps 지표에 근거해야 합니다. 그래야만 추가되는 복잡성이 측정 가능한 이득에 의해 정당화될 수 있습니다.[1][3]

⚠️ 경험 법칙 (Rule of thumb)[3]

강력한 RAG + 프롬프팅을 사용함에도 여전히 품질 목표를 달성하지 못하고 작업이 안정적이라면 → 파인튜닝을 고려하십시오.
요구 사항이 자주 변경되거나 데이터가 극도로 민감하다면 → RAG와 거버넌스 (Governance)에 의존하고 대규모 파인튜닝은 미루십시오.

📊 소결론: 일회성 파인튜닝이 아니라, 평가 스위트 (Eval suites), 재학습 주기 (Retraining cadence), 그리고 명확한 모델 소유권 약관을 포함한 "도메인 프로그램"을 제안하십시오.

7. 운영 모델: SLO, 비용, 그리고 장기적 보안 태세

이전의 모든 차원들은 운영 모델에서 하나로 수렴됩니다. 엔터프라이즈 배포의 성패는 SLO (서비스 수준 목표, Service Level Objectives)에 달려 있습니다. 즉, 지연 시간 (Latency), 처리량 (Throughput), 가용성 (Availability), 그리고 품질 (Quality)에 대한 명시적인 목표를 설정해야 하며, 제약이 있는 환경이나 온프레미스 (On-prem) 인프라에서도 이러한 목표가 유지됨을 증명해야 합니다.[3][10]

로컬 환경에서 높은 RPS (초당 요청 수)와 낮은 지연 시간을 입증하는 참조 아키텍처 (Reference architectures)는 설득력이 있습니다.[10]

내부 코파일럿 (Internal copilot)을 위한 SLO 예시: