제7부 엔터프라이즈 운영과 MLOps
7.7 MLOps 라이프사이클과 관측성
7.7.1 이 장에서 배우는 것 / 선수 지식
7.1~7.5(그리고 보안 관점의 7.6)에서 엔터프라이즈 운영(NVAIE·k8s·DCGM·공유·보안)을 봤다. 이 장은 그것들을 MLOps 라이프사이클로 묶어 제7부를 마무리한다. MLOps는 ML/AI 시스템을 운영화하는 규율 — DevOps를 ML에 적용하되, ML 특유의 차이(데이터 의존·드리프트·재현성·지속 평가)를 다룬다. 핵심 메시지: "배포하고 잊기(deploy and forget)"는 ML에서 통하지 않는다 — 모델은 시간이 지나며 드리프트로 나빠지고, 데이터·세상이 변한다. 그래서 모니터링 → 재학습 → 재배포의 순환(데이터 플라이휠)이 필수다.
핵심 통찰: MLOps가 DevOps와 다른 것은 "데이터"와 "드리프트" 때문이다. 코드는 안 바뀌면 그대로지만, 모델은 데이터에 의존하고 입력 분포가 변하면(drift) 성능이 떨어진다 — 코드 한 줄 안 바꿔도. 그래서 ML은 "테스트 통과 후 배포 끝"이 아니라 지속 평가·드리프트 모니터링·피드백 재학습의 살아있는 루프다. 이 장은 그 루프를 세운다.
배우는 것:
- MLOps가 DevOps와 다른 이유 — 데이터 의존·드리프트·재현성·지속 평가.
- 파이프라인·버저닝 — 데이터·코드·모델·config 버저닝과 lineage, 모델용 CI/CD(평가 게이트), 오케스트레이션·레지스트리.
- 드리프트 모니터링 — 데이터 드리프트·개념 드리프트·성능 드리프트, LLM/RAG의 품질·환각·피드백.
- 생성형 AI 관측성 — 토큰·비용·지연·품질·안전(가드레일)·RAG 메트릭·트레이싱.
- 데이터 플라이휠 — production 피드백 → 큐레이션 → 재학습 → 재평가 → 재배포(6.1 라이프사이클의 순환).
선수 지식: 6.1(라이프사이클)·6.5·6.10(평가)·6.6(큐레이션·피드백)·6.4(재학습), 5.14·7.3(운영 메트릭), 6.11(안전 모니터링), 6.8(배포). 이 장은 제5~7부를 운영 루프로 묶는 종합이다. 다음은 제8부(자율주행). 환경은 production AI 시스템.
정직: MLOps 도구(파이프라인·레지스트리·드리프트 탐지·관측)는 풍부한 생태계·버전 의존이다(Kubeflow·MLflow·여러 관측 도구). 이 장은 변하지 않는 원리·루프·드리프트 개념을 가르치고 도구는 중립적으로. production AI 품질 모니터링은 어렵다(정답 없음·주관적) — 그 한계도 정직하게 다룬다.
7.7.2 MLOps는 왜 DevOps와 다른가
DevOps는 코드를 빌드·테스트·배포·운영한다. ML도 비슷해 보이지만 결정적 차이가 있다:
| 차이 | DevOps | MLOps |
|---|---|---|
| 의존 | 코드 | 코드 + 데이터 + config + 환경 |
| 재현성 | 코드 핀 | 데이터·코드·하이퍼·시드·환경 모두 핀(어려움) |
| 품질 | 테스트 통과(이진) | 지속 평가(품질·드리프트, 연속) |
| 시간 | 안 바뀌면 그대로 | 드리프트로 나빠짐(세상·데이터 변화) |
| 배포 후 | 운영 | 모니터링 → 재학습(deploy and forget 실패) |
세 가지 함의:
- ① 데이터가 1급 시민: 모델은 데이터에 의존하므로 데이터 버저닝·lineage(어느 데이터가 이 모델을 만들었나)가 코드만큼 중요. 데이터가 바뀌면 모델이 바뀐다.
- ② 드리프트로 모델 성능이 저하된다: 코드 안 바꿔도 입력 분포·세상이 변하면 모델 성능이 떨어진다(7.7.4). "한 번 배포 끝"이 아니라 지속 감시.
- ③ 재현성이 어렵다: 같은 모델을 재현하려면 데이터·코드·하이퍼파라미터·랜덤 시드·환경(라이브러리 버전)을 모두 고정해야 — DevOps보다 변수가 많다.
핵심: MLOps의 본질은 "ML 시스템을 살아있는 것으로 운영" 하는 것이다 — 배포가 끝이 아니라 모니터링·재학습 루프의 시작. 데이터와 드리프트가 이를 강제한다.
7.7.3 파이프라인·버저닝·재현성
MLOps는 라이프사이클(6.1)을 자동화·버저닝·재현 가능하게 만든다.
각 단계를 버저닝한다 — 데이터·코드·config·모델을 추적(lineage). 피드백은 재학습으로 루프를 이룬다.
핵심 구성:
- 버저닝·lineage: 데이터·코드·하이퍼파라미터·모델·config를 버전 추적. "이 production 모델은 어느 데이터·코드·하이퍼로 만들어졌나"를 재현·감사 가능하게. (모델 레지스트리·데이터 버저닝 도구.)
- 모델용 CI/CD + 평가 게이트: 코드/데이터 변경 시 자동 학습·평가 게이트(6.5·6.10의 품질·회귀·안전 지표가 임계 통과해야 배포). "테스트 통과"가 아니라 "모델 품질 통과". 카나리(6.8)로 점진 배포.
- 파이프라인 오케스트레이션: 데이터→학습→평가→등록→배포를 워크플로로(Kubeflow·MLflow류). 재실행·재현.
- 모델 레지스트리: 버전별 모델, staging/production 승급, 롤백.
- 재현성: 데이터·코드·환경·시드 고정. decontamination(6.6)으로 평가 정직성.
핵심: lineage(무엇이 무엇을 만들었나) 가 MLOps의 기반이다 — 모델이 나빠지면 어느 데이터·코드 때문인지 추적하고, 좋은 버전으로 롤백하며, 감사·규제(7.1)에 대응한다. 평가 게이트는 "품질이 통과해야 배포"로 회귀를 막는다.
7.7.4 드리프트 — 모델 성능이 저하되는 이유
MLOps의 핵심은 드리프트 모니터링이다. 코드를 안 바꿔도 모델 성능이 떨어지는 세 가지:
| 드리프트 | 무엇 | 예 |
|---|---|---|
| ① 데이터 드리프트(covariate shift) | 입력 분포가 학습 때와 달라짐 | 새 사용자층·새 용어·계절 변화 → 모델이 못 보던 입력 |
| ② 개념 드리프트(concept drift) | 입력↔출력 관계 자체가 변함 | 사기 패턴 변화·정책 변경 → 같은 입력의 정답이 바뀜 |
| ③ 성능 드리프트 | 위 결과로 정확도·품질이 시간에 따라 저하 | — |
'deploy and forget'이면 이 저하를 모른 채 품질 낮은 답을 계속 낸다 — 데이터·세상 변화(드리프트)로 분포가 어긋나 성능이 떨어진다.
드리프트 탐지:
- 입력 분포 모니터링: production 입력의 통계·임베딩 분포가 학습 분포에서 벗어나는지(데이터 드리프트).
- 성능 모니터링: 정답이 있으면(지연 라벨) 정확도 추적, 없으면 프록시(신뢰도·사용자 피드백·재시도율).
- 품질 샘플링: production 출력을 샘플링해 평가(LLM-judge·인간, 6.10).
- 피드백 루프: 사용자 피드백(좋아요/싫어요·수정·이탈)을 신호로.
LLM/RAG의 드리프트:
| LLM/RAG 특유 신호 | 내용 |
|---|---|
| groundedness·환각률(6.10) | RAG 답이 근거를 잃는지 |
| 답 품질·관련성 | 사용자 피드백·평가셋 회귀 |
| 지식 신선도 | 인덱스가 오래되면(6.9~6.10) 옛 정보 |
| 안전 | 가드레일 트리거율·탈옥 시도(6.11) |
production 정답이 없어 모니터링이 어렵다(프록시·샘플·피드백).
정직: production AI 품질 모니터링은 어렵다 — 실시간 정답(ground truth)이 없고 품질이 주관적이다. 그래서 프록시 지표(신뢰도·피드백·재시도)·샘플 평가·드리프트 통계를 조합하고, 인간 검토를 병행한다. "정확도 95%"를 production에서 실시간으로 알 수 없으니, 여러 약한 신호로 드리프트를 조기 포착한다.
7.7.5 생성형 AI 관측성
운영 메트릭(5.14·7.3)에 더해, 생성형 AI는 품질·비용·안전까지 관측한다:
| 관측 계층 | 내용 |
|---|---|
| 운영(5.14·7.3) | 지연(TTFT·TPOT·p99)·처리량·GPU 활용률(util)·큐 |
| 비용 | 토큰 사용량·요청당 비용·$/사용자(5.1) |
| 품질(6.10) | groundedness·답 관련성·사용자 피드백·환각률 |
| 안전(6.11) | 가드레일 트리거·탈옥 시도·차단율 |
| 트레이싱 | 요청 → 검색(RAG) → 생성 → 가드레일의 단계별 추적 |
활용률을 MLOps 관점으로: 7.3(DCGM)가 GPU 활용률 자체를 계측한다면, MLOps 레이어는 그 수치를 비용·용량 결정에 잇는다 — 활용률이 낮은 모델 서빙은 복제본 축소·MIG/MPS 공유(7.4·7.5)로, 활용률이 포화된 모델은 스케일아웃(7.3 오토스케일)으로. 배포별 GPU-시간당 처리 요청 수·활용률 대비 $/요청을 추적하면 "느려서 늘렸나 vs 활용을 못 해서 낭비했나"를 구분할 수 있다 — 순수 인프라 지표(7.3)와 순수 품질 지표(6.10) 사이의 빈틈을 메우는 것이 MLOps 관측의 역할이다.
트레이싱(tracing) 이 중요하다 — 생성형 시스템은 다단계(검색·생성·도구·가드레일)라, 한 요청이 어느 단계에서 느렸나·틀렸나를 단계별로 추적해야 진단된다(6.10의 RAG triad·5.14의 큐 vs 컴퓨트를 요청 단위로).
어느 단계가 병목·실패인지, groundedness·안전 결과까지 한 트레이스로 본다.
견해: 생성형 AI 관측은 "운영 + 비용 + 품질 + 안전"을 한 트레이스로 묶어야 한다. 지연만 보면 품질 저하를 놓치고, 품질만 보면 비용 폭증을 놓친다. 토큰·비용(5.1)·groundedness(6.10)·가드레일(6.11)을 운영 대시보드(7.3)에 통합해 종합적으로 본다.
7.7.6 데이터 플라이휠 — 순환
MLOps의 결실은 데이터 플라이휠 — production이 다음 모델을 더 좋게 만드는 순환(6.1 라이프사이클을 실행하는 엔진):
쓸수록 데이터가 쌓이고, 그 데이터로 모델이 좋아지는 선순환이다.
플라이휠의 동력:
- 실패 사례 수집: 사용자 불만·낮은 신뢰·가드레일 트리거·드리프트 알림을 모아 다음 학습/큐레이션 재료로.
- 재학습 트리거: 드리프트·성능 저하·새 데이터 충분 시 재학습(주기적 또는 임계 기반). RAG는 인덱스 갱신(6.10 신선도)이 더 비용이 낮고 빠른 대안.
- 평가 게이트·카나리: 재학습 모델이 회귀 없이 나아졌는지 확인 후 배포(6.5·6.10·6.8).
견해: 데이터 플라이휠이 AI 시스템의 장기 경쟁력이다 — 모델 자체보다 "쓸수록 좋아지는 루프"를 가진 쪽이 이긴다. 단 재학습이 항상 답은 아니다 — 지식 드리프트는 RAG 인덱스 갱신(비용이 낮고 빠름, 6.1·6.10)으로, 행동·능력 드리프트만 재학습으로. 그리고 재학습마다 평가 게이트·정직한 회귀 측정(6.5·6.10·6.6 decontam)으로 실제 나아졌는지 확인.
7.7.7 중간 점검 (체크포인트)
- [ ] MLOps가 DevOps와 다른 이유(데이터 의존·드리프트·재현성·지속 평가)를 설명한다.
- [ ] 버저닝·lineage(데이터·코드·모델)와 평가 게이트(품질 통과 후 배포)의 역할을 안다.
- [ ] 드리프트 세 종류(데이터·개념·성능)와 탐지(분포·성능·샘플·피드백), production 정답 없음의 어려움을 안다.
- [ ] 생성형 AI 관측(운영+비용+품질+안전+트레이싱)을 통합함을 안다.
- [ ] 데이터 플라이휠(피드백→큐레이션→재학습/인덱스갱신→재평가→배포)과 "재학습 vs RAG 갱신"을 구분한다.
증상→의심: 배포 후 시간 지나며 품질 저하 → 드리프트(deploy and forget) → 드리프트 모니터링·재학습/인덱스. 모델 재현 불가 → lineage·버저닝 없음 → 데이터·코드·환경·시드 핀. 품질 미달 모델이 배포됨 → 평가 게이트 없음 → 품질·회귀·안전 게이트. production 품질을 못 잼 → 정답 없음 → 프록시·샘플·피드백·인간. 지식만 오래됨 → 재학습 과투자 → RAG 인덱스 갱신(6.10). 요청 어디서 느린지/틀린지 모름 → 트레이싱 없음 → 단계별 트레이스. 재학습했는데 다른 능력 저하 → 회귀 미측정 → 게이트·decontam(6.5·6.6).
7.7.8 트레이드오프·대안
| 결정 | 트레이드오프 |
|---|---|
| 재학습 vs RAG 인덱스 갱신 | 행동/능력 변화·비쌈 vs 지식 신선도·비용이 낮고 빠름(6.1) |
| 주기 재학습 vs 트리거(드리프트) | 단순·낭비 가능 vs 효율·복잡 |
| 풀 평가 vs 프록시 모니터링 | 정확·비쌈·느림 vs 빠름·약한 신호 |
| 자동 재배포 vs 사람 게이트 | 빠름·위험 vs 안전·느림 |
| MLOps 플랫폼 vs 자체 조립 | 통합·종속 vs 유연·노동 |
견해: 드리프트 기반 트리거 + 평가 게이트 + 카나리가 균형이다 — 맹목적으로 주기 재학습(낭비)이나 deploy-and-forget(저하)이 아니라, 드리프트·피드백이 임계를 넘으면 재학습/인덱스 갱신하고 게이트·카나리로 안전하게. 지식 드리프트는 RAG 갱신(낮은 비용으로), 능력·행동 드리프트만 재학습. production 품질은 프록시·샘플·피드백을 조합하고 인간 검토를 병행 — 완벽한 실시간 정답은 없다.
비엔비디아 정직: MLOps는 도구·플랫폼 생태계가 방대하다(Kubeflow·MLflow·다양한 관측·드리프트 도구). 엔비디아의 기여는 GPU 가속 학습·추론·관측(DCGM)·NeMo/NIM 통합·AI Enterprise 지원이지, MLOps 규율·루프 자체는 도구 중립이다. 특정 플랫폼에 묶이지 말고 라이프사이클·드리프트·플라이휠의 원리를 이해해 자기 스택에 적용한다.
7.7.9 흔한 함정
- deploy and forget. 배포가 끝이라 여기면 드리프트로 모델 성능이 조용히 저하된다. 지속 모니터링·재학습 루프.
- lineage·버저닝 없음. 모델 재현·롤백·감사 불가, 무엇이 문제인지 추적 못 함. 데이터·코드·모델 버전 추적.
- 평가 게이트 없이 배포. 회귀·품질 저하·안전 위반이 production에 → 평가/회귀/안전 게이트·카나리(6.5·6.10·6.8).
- 드리프트 무시. 데이터·세상 변화로 성능 저하를 모른 채 품질 낮은 답 계속. 분포·피드백·샘플 모니터링.
- production 정답 가정. 실시간 ground truth가 없다 — 프록시·샘플·인간으로. "정확도 95%"를 실시간으로 못 잼.
- 모든 드리프트를 재학습으로. 지식 드리프트는 RAG 인덱스 갱신(낮은 비용으로, 6.10) — 능력·행동만 재학습.
- 운영만 관측, 품질·비용·안전 누락. 지연만 보면 품질·비용·안전 저하를 놓침 → 통합 관측·트레이싱.
- 재학습 회귀 미측정. 새 모델이 한 지표는 좋아지고 다른 능력은 저하(정렬세 6.5) — 게이트·decontam(6.6)으로 정직한 회귀.
7.7.10 연습문제
연습 1 (왜 다른가). "우리 모델은 테스트 통과 후 배포했으니 DevOps처럼 끝"이라는 주장을 반박하고, ML이 배포 후에도 관리가 필요한 이유를 데이터·드리프트로 설명하라.
정답
반박: ML은 코드만이 아니라 데이터에 의존하고, 세상·입력 분포가 변하면(코드 한 줄 안 바꿔도) 모델 성능이 떨어진다(드리프트) — DevOps의 "코드 안 바뀌면 그대로"가 성립 안 함. ① 데이터 드리프트: 새 사용자층·새 용어·계절 변화로 입력이 학습 분포에서 벗어남 → 모델이 못 보던 입력에 약해짐. ② 개념 드리프트: 입력↔출력 관계가 변함(사기 패턴·정책 변경) → 같은 입력의 정답이 달라져 학습 시점 모델이 틀림. ③ 성능 드리프트: 그 결과 정확도·품질이 시간에 따라 저하. "테스트 통과"는 배포 시점의 한 스냅샷일 뿐, production에서 데이터·세상이 변하면 모델 성능이 조용히 저하된다. 그래서 ML은 지속 모니터링(드리프트)·재학습 루프가 필요 — deploy and forget이 아니라 살아있는 시스템. + 재현성(데이터·코드·환경·시드)·지속 평가도 DevOps보다 어렵다.
연습 2 (드리프트 탐지). production에 정답(ground truth)이 실시간으로 없는 RAG 챗봇의 품질 저하를 어떻게 모니터링하나? 신호 넷을 제시하라.
정답
실시간 정답이 없으므로 약한 신호·프록시를 조합: ① 입력 분포 모니터링(데이터 드리프트) — production 질의의 통계·임베딩 분포가 인덱스/학습 분포에서 벗어나는지(새 주제·용어). ② 사용자 피드백(좋아요/싫어요·수정·재질문·이탈율·세션 길이) — 만족도 프록시. ③ 품질 샘플링 — production 출력을 샘플링해 LLM-judge·인간으로 groundedness·관련성 평가(6.10), 시간에 따른 추세. ④ RAG/안전 메트릭 — groundedness 점수·"근거 없음" 응답률·환각 탐지·가드레일 트리거율(6.10·6.11)·검색 recall 프록시. + 인덱스 신선도(문서 갱신 vs 인덱스). 이 신호들의 추세·이상으로 드리프트를 조기 포착하고, 임계 넘으면 샘플 평가·인간 검토·인덱스 갱신/재학습 트리거. 핵심: 단일 정답이 없으니 여러 약한 신호 + 샘플 + 인간으로 — production AI 품질 모니터링의 본질적 어려움을 인정하고 다층으로.
연습 3 (재학습 vs 인덱스). 사내 문서 RAG 봇이 (a) 새로 추가된 정책 문서를 모르고, (b) 응답 어조가 시간이 지나며 사용자 선호와 멀어졌다. 각각 재학습과 RAG 인덱스 갱신 중 무엇으로 푸나?
정답
(a) 지식 드리프트(신선도) → RAG 인덱스 갱신 — 새 정책 문서를 청킹·임베딩해 벡터DB에 추가/갱신(6.9~6.10)하면 검색이 최신 문서를 가져옴. 재학습 불필요·불리 — 지식을 가중치에 굳히면 갱신마다 재학습(비용이 크고 환각 안 줄임, 6.1). 비용이 낮고 빠른 인덱스 갱신이 정답. (b) 어조·행동 드리프트 → 재학습(LoRA·SFT, 6.4) 또는 프롬프트 조정 — 어조·스타일은 RAG(검색)로 안 되고 모델 행동의 문제. 사용자 선호 데이터를 모아 LoRA로 재학습하거나 시스템 프롬프트·정렬(6.5) 조정. 핵심 구분: 지식=RAG 인덱스 갱신(낮은 비용으로), 행동/능력/어조=재학습(6.1 적응 스펙트럼의 운영판). 둘 다 평가 게이트·회귀 측정(6.5·6.10) 후 카나리 배포. "모든 드리프트를 재학습"은 과투자 — 지식은 인덱스로.
연습 4 (관측·트레이싱). production RAG 시스템에서 "어떤 요청이 느리고 어떤 요청이 환각인지" 진단하려면 무엇을 관측·트레이싱해야 하나?
정답
트레이싱: 한 요청을 단계별로 추적 — 질의 → 임베딩 → 검색 → 리랭킹 → 생성 → 가드레일, 각 단계의 지연과 결과를 한 트레이스로. 느린 요청: 트레이스에서 어느 단계가 병목인지(예: 생성 800ms vs 검색 20ms → 생성이 병목, 5.14의 큐 vs 컴퓨트를 요청 단위로). 환각 요청: 트레이스에 groundedness 점수·검색된 문맥·가드레일 결과(6.10·6.11)를 기록 → 환각이면 검색이 관련 문맥을 못 줬나(context relevance), LLM이 문맥 무시했나(groundedness)를 RAG triad(6.10)로 국소화. 관측 통합: 운영(지연·처리량·GPU util 7.3) + 비용(토큰) + 품질(groundedness·피드백 6.10) + 안전(가드레일 트리거 6.11)을 한 대시보드로. 느린 요청은 운영 트레이스로, 환각은 품질 트레이스로 — 둘을 같은 요청 트레이스에서 봐야 "느리고 틀린" 요청도 진단. 트레이싱 없으면 다단계 시스템에서 어느 단계가 문제인지 모른다.
연습 5 (플라이휠). 사내 코드 어시스턴트의 데이터 플라이휠을 설계하라. production에서 무엇을 수집하고 어떻게 다음 모델을 개선하는가?
정답
플라이휠: ① 수집 — production에서 사용자 상호작용(수락/거부한 제안·수정한 코드·재시도·피드백), 실패 사례(낮은 신뢰·가드레일 트리거 6.11·드리프트 알림), 새 사내 코드·라이브러리. ② 큐레이션(6.6) — 수집 데이터를 정제·dedup·시크릿/PII 필터·라벨(수락된 제안=좋은 예시), decontamination(평가셋 누출 방지·정직성). ③ 개선 경로 구분: 지식(새 라이브러리·코드베이스) → RAG 인덱스 갱신(6.10, 낮은 비용으로); 스타일·도메인 패턴 → LoRA 재학습(6.4); 깊은 능력 → SFT. ④ 재평가(게이트) — 새 모델/인덱스를 평가셋으로 측정(코딩 품질 + 일반 능력 회귀, 정렬세 6.5) → 통과 시. ⑤ 카나리 배포(6.8) — 소수 트래픽에 먼저, 메트릭·피드백 확인 후 확대. ⑥ 모니터링 → (다시 ①). 동력: 쓸수록 수락/거부·수정 데이터가 쌓여 "무엇이 좋은 제안인가"를 학습 → 모델이 좋아짐 → 더 많이 쓰임(선순환). 핵심: 실패·피드백을 재료로, 지식은 인덱스·행동은 재학습, 게이트·카나리로 안전하게, 정직한 회귀 측정. 플라이휠이 장기 경쟁력.
7.7.11 요약 · 다음 장(제7부 마무리)
- MLOps는 ML 시스템을 살아있는 것으로 운영한다 — DevOps와 달리 데이터 의존·드리프트·재현성·지속 평가 때문에 "배포하고 잊기"가 통하지 않는다. 코드 안 바꿔도 데이터·세상 변화(드리프트)로 모델 성능이 저하된다.
- 버저닝·lineage(데이터·코드·모델, 재현·감사)와 평가 게이트(품질·회귀·안전 통과 후 배포·카나리)가 파이프라인의 기반.
- 드리프트(데이터·개념·성능)를 분포·피드백·샘플로 모니터링 — production 정답이 없어 어렵다(프록시·인간 병행). LLM/RAG는 groundedness·환각·피드백·신선도·안전.
- 생성형 AI 관측은 운영+비용+품질+안전을 트레이싱으로 통합 — 다단계(검색·생성·가드레일)를 단계별로.
- 데이터 플라이휠(피드백→큐레이션→재학습/인덱스갱신→재평가→배포)이 장기 경쟁력 — 지식은 RAG 갱신(낮은 비용으로), 행동·능력은 재학습, 게이트·정직한 회귀로.
- 제7부(엔터프라이즈 운영·MLOps, 7.1~7.7 + 7.6) 완료: AI Enterprise(지원·인증) → k8s GPU 운영(Operator·DCGM) → 가상화·공유(타임슬라이싱·vGPU·MPS·MIG) → AI 인프라 보안(7.6 — 공급망·접근통제·격리의 보안 함의) → MLOps(라이프사이클·드리프트·플라이휠). "AI를 조직이 안정·격리·안전·지속 가능하게 운영하는" 전 계층을 익혔다.
다음 장: 8.1 자율주행 컴퓨팅 요구와 중앙집중 아키텍처. 제8부(자율주행) 의 시작. 지금까지의 데이터센터·생성형 AI에서 차량이라는 실시간·안전 critical·전력 제약 엣지로 무게를 옮긴다 — 자율주행이 요구하는 컴퓨팅(센서 융합·실시간·중복화), 존(zone)/중앙집중 E/E 아키텍처, 그리고 DRIVE 플랫폼(8.2~)으로 이어지는 토대를 본다.