엔터프라이즈 LLM 개발 기업이 프로덕션 준비가 된 AI 시스템을 구축하는 방법

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

데모에서 프로덕션으로: 실제 엔터프라이즈 LLM의 문제

주요 이슈는 더 이상 LLM을 사용할 것인가의 여부가 아니라, 어떻게 데모를 관리되고 회복 탄력성 있는 (resilient) 시스템으로 전환하느냐 하는 것입니다. 2026년까지 대부분의 프랑스 대기업과 CAC 40 기업들이 최소 하나 이상의 LLM을 프로덕션(production)에서 운영하겠지만, 공식적인 AI 전략과 거버넌스 프레임워크(governance framework)를 갖춘 기업은 3분의 1 미만입니다.[4][6]

이 격차는 다음과 같은 형태로 나타납니다:[2][5][6][7]

불안정한 애플리케이션과 예상치 못한 청구서
데이터 처리 합의서(DPA) 없이 제3자 API를 통해 흐르는 민감한 데이터
혁신 팀과 CISO(정보보호최고책임자) / 규제 기관 간의 갈등

흔히 발생하는 "실패한 데모" 패턴은 다음과 같습니다:[2][7]

수천 번의 LLM 호출을 유발하여 크고 예상치 못한 비용을 발생시키는 루프(loops)
폴백 모델(fallback model)이 없는 상태에서의 제공업체 중단 또는 속도 제한(rate limits)
프롬프트(prompts)/컨텍스트(contexts) 로깅 부재로 인한 디버깅의 어려움
보안 검토 없이 비즈니스 팀에서 채택한 섀도우 AI(Shadow AI) 도구

이러한 문제를 해결하기 위해 LLMOps가 등장했습니다. LLMOps는 기존의 MLOps 배포 및 모니터링에 프롬프트 및 컨텍스트 관리, 모델 라우팅(model routing), 비용 제어, 그리고 인간 참여형(human-in-the-loop) 피드백을 추가합니다.[3] 또한 LLM은 기존 스택이 잘 처리하지 못하는 제약 사항(컨텍스트 윈도우(context windows), 도구 사용 에이전트(tool-using agents), 멀티 모델 포트폴리오)을 동반합니다.[3]

엔터프라이즈 LLM 파트너가 중요한 이유

전문적인 LLM 개발 기업은 일반적으로 다음과 같은 사항을 제공하기 위해 고용됩니다:[2][3][4][6][7]

참조 아키텍처 (공용 API vs 주권형(sovereign) vs 온프레미스(on-prem) vs 커스텀 모델)
라우팅, 관측성(observability), 그리고 롤백(rollback)을 위한 공유 게이트웨이 / LLMOps 레이어
GDPR, EU AI Act, NIS2와 정렬된 거버넌스 및 컴플라이언스(compliance) 프레임워크

이 기사의 나머지 부분에서는 아키텍처 선택(architecture choices), LLMOps 및 게이트웨이(gateways), 보안 및 거버넌스(security and governance), 참여 인력 및 역할, 그리고 파트너가 단일 유스케이스(use case)에서 포트폴리오로 확장하는 것을 어떻게 돕는지에 대해 다룹니다.

아키텍처 선택: API, 온프레미스(on-prem), 또는 맞춤형 엔터프라이즈 LLM

API 제공업체, 온프레미스, 맞춤형 모델 간의 선택

대부분의 기업은 LLM API로 시작합니다. 자체 모델을 학습시키고 서비스하는 네이티브 제공업체는 일반적으로 다음과 같은 사항을 제공합니다: [9]

강력한 모델 품질 및 툴링 (tooling)
성숙한 SDK 및 통합 (integrations)
아이디어에서 첫 번째 앱까지의 빠른 경로

그 후 라우팅 플랫폼(routing platforms)과 클라우드 마켓플레이스(cloud marketplaces)가 여러 모델과 제공업체를 노출하여, 기업이 비용, 지연 시간(latency), 신뢰성(reliability) 사이의 균형을 맞출 수 있도록 합니다. [9]

규제 대상 산업(의료, 금융, 국방)의 경우, 원시 데이터(raw data)를 외부 API로 전송하는 것이 허용되지 않는 경우가 많습니다. [5][10] 현재 온프레미스 및 소버린 플랫폼(sovereign platforms)을 사용하면 Llama 또는 Mistral과 같은 모델을 기업 내부 또는 해당 지역의 인프라 내에서 실행할 수 있으며, 대화형 어시스턴트에 적합하도록 최적화된 지연 시간과 처리량(throughput)을 제공합니다. [10]

아키텍처 스펙트럼 (Architecture spectrum)

퍼블릭 API LLM (Public API LLMs) – 가장 빠른 시작이 가능하지만, 데이터 레지던시(data residency)에 대한 제어가 제한적임 [9]
소버린 / 프라이빗 클라우드 (Sovereign / private cloud) – 지역 내 호스팅, 더 강력한 데이터 및 액세스 제어 [4][6]
온프레미스 LLM (On-prem LLMs) – 네트워크 경계 및 보안 태세(security posture)에 대한 완전한 제어 [10]
맞춤형 모델 (Custom models) – 엄격한 거버넌스 하에 독점 데이터(proprietary data)로 조정(adapted)되거나 사전 학습(pre-trained)됨 [1]

맞춤형 도메인 특화 모델

고위험, 고가치 유스케이스(신용, 의료 결정, 산업 제어)의 경우, 기업은 Mistral과 같은 파트너와 함께 도메인 특화 모델을 공동 개발합니다. [1] 이러한 프로젝트는 다음과 같은 특징을 가집니다: [1][10]

독점 코퍼스(proprietary corpora)를 사용한 미세 조정(fine-tune) 또는 사전 학습(pre-train)
엄격한 데이터 격리(data isolation) 및 감사 가능성(auditability) 강제
규제 및 지연 시간에 따라 온프레미스, 소버린 클라우드 또는 온디바이스(on-device)에 배포

커스터마이징(Customization) 옵션은 다음과 같은 연속적인 스펙트럼 상에 존재합니다:[1][3]

프롬프팅 전용 (Prompting only) – 일반 모델(general models)에 시스템 프롬프트(system prompts)와 퓨샷 예시(few‑shot examples)를 적용
인스트럭션 튜닝 / 어댑터 (Instruction tuning / adapters, LoRA, QLoRA) – 가벼운 동작 적응(behavior adaptation)
태스크 특화 파인튜닝 (Task‑specific fine‑tuning) – 도메인 코퍼스(domain corpora, 예: 계약서, 임상 기록) 활용
전체 사전 학습 (Full pre‑training) – 매우 드물며, 매우 전문화된 요구사항이나 소버린(sovereign) 요구사항을 위해 수행

엔터프라이즈 LLM 기업들은 보통 프롬프팅과 RAG로 시작하며, 지표(metrics)나 컴플라이언스(compliance) 요구사항이 추가적인 복잡성을 정당화할 때에만 파인튜닝(fine‑tuning) 단계로 격상합니다.[1][3]

규제 및 소버린(sovereignty) 동인

유럽에서는 규제와 소버린(sovereignty) 요소가 아키텍처를 결정적으로 형성합니다. EU AI Act는 금융, 의료 및 핵심 인프라 분야의 많은 LLM 기반 시스템을 고위험(high‑risk)으로 분류하여, 통제 및 적합성 평가(conformity assessments)를 요구합니다.[4][6]
GDPR 및 NIS2는 데이터 거주성(data residency), 액세스 및 사고 대응(incident response)에 관한 의무를 추가합니다.[5][7]

이는 다음과 같은 패턴으로 이어집니다:[4][5][6][7][10]

로그, 임베딩(embeddings) 및 학습 데이터를 위한 EU 전용 또는 국가별 호스팅
데이터 출처(data provenance) 및 추론 동작(inference behavior)에 대한 상세한 감사 추적(audit trails)
규제가 엄격한 섹터에서의 소버린(sovereign) 또는 온프레미스(on‑prem) 배포 선호

참조 멀티 모델 아키텍처 (Reference multi‑model architecture)

유연성, 소버린(sovereignty) 및 비용을 조화시키기 위해, 파트너들은 종종 다음과 같은 곳으로 라우팅하는 중앙 게이트웨이(central gateway)를 구현합니다:[2][10]

외부 API (External APIs): 민감도가 낮은 작업(일반적인 요약, 코드 생성)용
온프레미스 / 소버린 모델 (On‑prem / sovereign models): 인사(HR), 재무 및 규제 대상 워크로드용
파인튜닝된 도메인 모델 (Fine‑tuned domain models): 고가치 유스케이스(예: 언더라이팅)용[1][10]

상위 수준의 라우팅 의사코드(pseudocode):

def route_request(req: LLMRequest):
    meta = classify_request(req)  # 민감도(sensitivity), 도메인(domain), 지연 시간 SLO(latency_slo)
    if meta.sensitivity == "high":
...

이 게이트웨이 중심 설계는 주권 제약 사항(sovereignty constraints)을 충족하면서 로깅(logging), 정책 집행(policy enforcement), 라우팅(routing) 및 비용 제어를 중앙 집중화합니다.[2][4][6]

LLMOps 및 AI 게이트웨이: 대규모 환경에서 LLM을 운영 가능하게 만들기

실제 환경에서의 LLMOps란 무엇인가?

아키텍처가 구축되면, 과제는 규모(scale)와 신뢰성(reliability)의 문제가 됩니다. LLMOps는 MLOps를 확장하여 다음을 포함합니다:[3]

프롬프트(prompts), 에이전트(agents) 및 도구(tools)를 일급 아티팩트(first-class artifacts)로 버전 관리
컨텍스트 조립(Context assembly) (RAG, 도구, 메타데이터) 및 컨텍스트 창(context-window) 예산 관리
포트폴리오 수준의 추론 관리(inference management) (비용, 지연 시간, 속도 제한)
비즈니스 작업 및 안전 기준에 대한 지속적인 평가(continuous eval)

LLMOps는 데이터 과학(data science), 엔지니어링(engineering) 및 IT 간의 협업을 유지하면서도, LLM 특화 자산과 워크플로우를 중심으로 운영합니다.[3]

제어 평면(control plane)으로서의 AI 게이트웨이

AI 게이트웨이는 애플리케이션과 LLM 제공업체 사이를 중재하며, 다음과 같은 제어 평면(control plane) 역할을 수행합니다:[2]

모델 및 벤더 간의 라우팅(routing) 및 부하 분산(load-balancing)
보안(security), 인증(auth) 및 데이터 비식별화(data redaction)
관찰 가능성(observability) 및 FinOps

일반적인 API 게이트웨이와 달리, AI 게이트웨이는 토큰(tokens), 컨텍스트 창(context windows) 및 LLM 특유의 장애 모드(failure modes)를 이해합니다.[2] 현대적인 게이트웨이와 온프레미스(on-prem) 플랫폼은 낮은 지연 시간과 높은 처리량(throughput), 상세한 메트릭(metrics)을 제공하여 다양한 사용 사례를 지원하는 내부 플랫폼에 적합합니다.[2][10]

핵심 게이트웨이 기능[2][3]

중앙 집중식 모델 라우팅 및 동적 폴백(dynamic fallback)
속도 제한(rate limiting) 및 지수 백오프(exponential backoff)
개인정보(PII) 및 비밀 정보(secret) 비식별화를 포함한 프롬프트/응답 로깅
대시보드 및 알림을 위한 실시간 비용 추정
모델 및 프롬프트를 위한 피처 플래그(feature flags) 및 A/B 테스트

관찰 가능성(Observability) 및 평가

엔터프라이즈 파트너들은 일반적으로 다음과 같은 기능을 갖춘 로깅 및 모니터링 계층을 추가합니다:[2][3][5][7]

프롬프트, 컨텍스트 소스, 모델 버전 및 메타데이터 캡처
데이터 분류(data classification) 및 비식별화(redaction) 정책 적용
경로(route) 및 테넌트(tenant)별 지연 시간, 토큰 사용량 및 오류 유형 추적

이러한 로그는 모니터링 및 오프라인 평가 파이프라인(evaluation pipelines)에 입력됩니다. 후보 모델과 프롬프트는 프로모션(promotion) 전 선별된 데이터셋을 통해 점수가 매겨지며, 이는 비결정성(non-determinism)과 추적 가능성(traceability)에 대한 규제 요구 사항을 고려할 때 매우 중요합니다.[3]\lbrack6\rbrack\lbrack7\rbrack

게이트웨이 스켈레톤(skeleton) 예시:

def handle_request(http_req):
    norm = normalize(http_req)
    enforce_authz(norm.user, norm.scope)
...

그 후 LLMOps는 이를 CI/CD, 환경 관리 및 롤백(rollback)으로 감쌉니다:[3]

LLMOps 라이프사이클 체크리스트\lbrack3\rbrack

합성 데이터(synthetic data) 또는 마스킹된 데이터로 초기화된 Dev/stage/prod 환경
자동화된 테스트가 포함된 Git 기반의 프롬프트, 에이전트(agents) 및 RAG 파이프라인
카나리 배포(Canary deployments) 및 안전한 롤백 절차
도메인 데이터셋 및 안전성 테스트 스위트(safety test suites)에 대한 지속적인 오프라인 평가

보안, 거버넌스 및 컴플라이언스를 일급 설계 제약 조건으로 취급

엔드 투 엔드(end-to-end) 규율로서의 LLM 보안

보안과 거버넌스는 모델, 데이터, 인프라(infra) 및 UX를 포함하는 전체 LLM 스택에 걸쳐 있습니다.[7\rbrack 클래식한 제어 방식(네트워크 세분화, IAM, 암호화)은 필수적이지만, 프롬프트 인젝션(prompt injection), 데이터 포이즈닝(data poisoning) 또는 모델 유출(model exfiltration) 문제를 완전히 해결하지는 못합니다.[7\rbrack\lbrack8\rbrack

OWASP의 LLM Top 10은 다음과 같은 위험을 강조합니다:[7\rbrack\lbrack8\rbrack

사용자 또는 검색된 콘텐츠를 통한 프롬프트 인젝션 및 탈옥(jailbreaks)
미세 조정(fine-tuning) 또는 RAG 소스에서의 학습 데이터 포이즈닝
잘못 구성된 API 또는 사이드 채널(side channels)을 통한 모델 또는 데이터 유출
모델 가중치(weights), 라이브러리 및 벡터 DB에서의 공급망 침해(supply chain compromise)

엔터프라이즈 LLM을 위한 보안 기본 원칙

CISO(정보보호최고책임자)는 먼저 LLM이 어디에서 사용되는지, 어떤 데이터에 접촉하는지, 그리고 누가 이에 접근하는지를 매핑해야 합니다.[5\rbrack 이는 다음을 의미합니다:[5\rbrack\lbrack7\rbrack

엔드 투 엔드 AI 데이터 흐름도 (수집 → 저장 → 추론 → 로그)
각 단계에서의 인증(authentication), 인가(authorization) 및 암호화 재평가

민감한 도메인(금융, 인사(HR), 의료)의 경우, 조직은 반드시 다음을 강제해야 합니다:[5\rbrack\lbrack6\rbrack

데이터 분류 (Data classification) 및 최소 권한 액세스 (least‑privilege access)
프롬프트 (prompts), 임베딩 (embeddings) 및 로그 (logs)에 대한 전송 중 및 저장 시 암호화 (Encryption in transit and at rest)
직원의 AI 사용에 대한 거버넌스 (허용된 사용 사례, 외부 API에 대한 규칙)

거버넌스 측면에서 GDPR, EU AI Act 및 NIS2는 다음을 요구합니다: [4][6][7]

모델, 프롬프트 및 데이터 소스로의 출력물 추적 가능성 (Traceability)
학습 데이터, 미세 조정 (fine‑tuning) 및 평가에 대한 문서화
핵심 분야를 위한 사고 대응 (Incident response) 및 회복 탄력성 (resilience)

LLM을 위한 거버넌스 기둥 (Governance pillars) [4][6]

추적 가능성 (Traceability) – 입력, 모델 및 출력을 연결하는 세밀한 로그
감사 가능성 (Auditability) – 데이터셋, 튜닝 절차 및 테스트 결과에 대한 증거
책임 있는 사용 (Responsible use) – 인간의 감독, 공정성 및 설명 가능성에 대한 정책

AI-SPM 및 엔터프라이즈 패턴

AI 보안 태세 관리 (AI Security Posture Management, AI-SPM) 도구는 현재 다음과 같은 기능을 수행합니다: [7][8]

AI 자산 인벤토리 관리 (모델, 게이트웨이, 벡터 스토어, 에이전트)
설정 오류 (misconfigurations) 및 위험한 데이터 흐름 탐지
프롬프트 인젝션 (prompt injection), 남용 패턴 및 비정상적 사용 모니터링

엔터프라이즈 LLM 기업은 다음과 같은 방식을 통해 보안과 거버넌스를 내재화합니다: [5][7][10]

분리된 환경 (개발/스테이징/운영, 별도의 네트워크 존)
고위험 워크로드를 위한 온프레미스 (On-prem) 또는 소버린 (sovereign) 배포 [4][10]
프롬프트, 데이터 소스 및 결정에 대한 상세하고 변경 불가능한 (immutable) 감사 로그 [6][7]
AI 특화 사고 대응 런북 (runbooks) 및 플레이북 (playbooks)

그 결과, 실제 운영 측면에서 안전하면서도 감사인과 규제 기관에 대해 방어 가능한 AI 시스템이 구축됩니다.

사람과 협업: LLM 개발자, 플랫폼 팀 및 파트너

LLM 개발자의 부상

이러한 시스템을 인도하기 위해서는 전문화된 역할이 필요합니다. LLM 개발자는 단순한 채팅 API를 넘어 제품에 LLM을 통합하는 데 집중하는 소프트웨어 엔지니어입니다. [11] 이들은 다음을 결합합니다: [11]

백엔드 엔지니어링 (Backend engineering) 및 오케스트레이션 (orchestration)
프롬프트 (Prompt) 및 에이전트 (agent) 설계
RAG, 청킹 (chunking) 및 벡터 검색 (vector search) 전략
내부 API 및 워크플로 (workflows)와의 도구 통합 (Tool integration)
평가 (Evaluation), 가드레일 (guardrails) 및 성능 최적화 (performance optimization)

이들은 보통 데이터 사이언티스트 (data scientists), DevOps, 그리고 IT 부서와 함께 LLMOps 또는 플랫폼 팀 내에서 활동합니다. [3][11]

일화: 내부 LLM 플랫폼 팀

한 유럽 은행은 중앙 LLM 플랫폼 스쿼드(squad)를 구성했습니다: LLM 개발자 2명, 데이터 엔지니어 1명, 보안 엔지니어 1명, 그리고 프로덕트 오너 (product owner) 1명으로 구성되었습니다. 6개월 이내에 이들은 다음을 인도했습니다: [1][4][11]

보안 AI 게이트웨이 (secure AI gateway)
3개의 도메인 특화 RAG 어시스턴트 (domain‑specific RAG assistants)
내부 평가 도구 (Internal evaluation tooling)

이들은 맞춤형 모델 작업 및 규제 관련 주제에 대한 학습을 위해 외부 벤더와 협력했습니다.

엔터프라이즈 LLM 파트너와 협업하기

외부 LLM 개발 기업은 다음과 같은 역량을 제공함으로써 내부 팀을 보완합니다: [1][4]

심도 있는 도메인 모델링 전문 지식 (리스크, 헬스케어, 제조)
게이트웨이, 관측성 (observability) 및 FinOps를 위한 검증된 플레이북 (hardened playbooks) [2][3]
내부 AI 역량 센터 (Centers of Excellence, CoEs) 구축을 위한 교육 및 지원 [1][4]