26M26a
Git을 단일 진실 원천으로 두되, Git에 없는 “현재 상태”는 실시간 관측 데이터와 K8s API에서 가져오고, LLM은 변경 실행자가 아니라 “증거 기반 운영 판단 보조자”로 먼저 둔다.
즉, 1단계 목표는 자동 변경이 아니라 정확한 현황 파악, 영향도 분석, 장애 시 의사결정 지원, 인수인계 가능한 운영 지식 체계입니다.
1. 최신 경향을 반영한 큰 방향
최근 Platform Engineering 흐름은 단순히 개발자 포털을 만드는 것이 아니라, 공통 운영 능력, 표준 경로, 정책, 측정 체계, 자동화, 관측성, AI 보조 운영을 하나의 내부 플랫폼으로 묶는 방향입니다. CNCF Platform Engineering Maturity Model도 플랫폼을 사람·프로세스·정책·기술을 포함한 체계로 보고, 성숙도를 Investment, Adoption, Interfaces, Operations, Measurement 관점에서 봅니다. (tag-app-delivery.cncf.io)
또한 2025 DORA 리포트는 AI가 조직의 강점과 약점을 증폭시키는 역할을 하므로, AI 도구 자체보다 기반 프로세스와 운영 시스템이 더 중요하다고 설명합니다. 이 관점은 지금 고민하시는 방향과 정확히 맞습니다. LLM을 붙이기 전에 문서, 변경 이력, 메트릭, 로그, 토폴로지, 책임자, 백업 상태가 정리되어 있어야 LLM이 쓸모 있는 답을 냅니다. (도라)
GitOps는 이 체계의 핵심 축으로 두는 것이 맞습니다. OpenGitOps는 GitOps를 표준화된 방식으로 채택하기 위한 원칙과 모범 사례를 제시하고 있고, Argo CD는 Git에 정의된 원하는 상태와 실제 클러스터 상태를 지속적으로 비교해 drift를 탐지하고 수동 또는 자동 동기화할 수 있습니다. (OpenGitOps) (Argo CD)
다만 운영 관점에서는 “GitOps = 모든 것을 자동 적용”이 아닙니다. 특히 운영 중인 대규모 Data Lakehouse에서는 GitOps + 사전 검증 + 영향도 분석 + 승인 기반 적용 + 복구 계획이 핵심입니다.
2. 목표 아키텍처
개념적으로는 아래 구조를 목표로 잡는 것이 좋습니다.
[Git / Docs / Runbooks / Policies / Inventory]
│
│ versioned desired state
▼
[CI 검증 파이프라인]
- manifest/schema 검증
- policy 검증
- ArgoCD diff
- resource/capacity 검증
- backup/rollback 체크
│
▼
[ArgoCD / Jenkins / Ansible / Kubespray]
│
▼
[K8s / Cilium / AIStor / Longhorn or OpenEBS / Keycloak / CI-CD / Observability]
동시에,
[K8s API / Prometheus / Grafana / OpenSearch / ArgoCD / AIStor metrics / Cilium status]
│
▼
[운영 상태 저장소 + 검색/그래프/RAG]
│
▼
[Read-only SRE Copilot]
- 현 상태 요약
- 장애 시 증거 수집
- 변경 영향도 분석
- SOP 추천
- 복구 순서 제안
- 보고서 초안 생성여기서 중요한 점은 Git은 desired state, Prometheus/OpenSearch/K8s API/AIStor/Cilium은 live state, 장애 이력과 SOP는 learned state라는 점입니다. 이 세 가지를 분리해서 관리해야 합니다.
3. 반드시 갖춰야 할 구성 요소
3.1 Git 중심 운영 저장소 구조
엑셀을 대체하려면 단순히 문서를 Git에 넣는 것만으로는 부족합니다. 문서와 설정이 서로 연결되어야 합니다.
추천 저장소 구조는 다음과 같습니다.
| 저장소 | 역할 |
|---|---|
platform-iac | Kubespray, Ansible, OS 튜닝, Cilium, Keycloak, AIStor, Longhorn/OpenEBS 등 설치·운영 자동화 |
gitops-env | ArgoCD Application, ApplicationSet, Kustomize/Helm values, 환경별 manifest |
platform-policies | Kyverno/OPA/Gatekeeper/ValidatingAdmissionPolicy, NetworkPolicy, ResourceQuota 기준 |
ops-docs | SOP, 작업계획서, 장애분석서, 점검표, 인수인계 문서 |
ops-inventory | 클러스터, 노드, namespace, owner, 서비스, bucket/prefix, SLO, 백업정책, 의존성 |
runbook-automation | Jenkinsfile, Ansible playbook, 점검 스크립트, 진단 스크립트 |
aiops-knowledge | LLM Wiki, 요약 문서, 질의응답용 index 문서, 운영 판단 기준 |
문서는 Markdown으로 두되 반드시 front matter를 붙이는 것이 좋습니다.
---
doc_type: sop
service: aistor
component: storage
cluster: storage-prod
risk_level: high
owner_primary: platform-storage
owner_secondary: platform-sre
related_alerts:
- AIStorQuorumDegraded
- AIStor5xxSpike
related_dashboards:
- grafana/aistor-health
related_runbooks:
- runbooks/aistor/quorum-check.md
last_reviewed: 2026-05-25
review_cycle: quarterly
rto: 4h
rpo: 1h
---이런 메타데이터가 있어야 LLM/RAG가 “문서를 찾는 수준”을 넘어, 특정 장애나 변경에 맞는 문서를 정확히 연결할 수 있습니다.
3.2 운영 Inventory / CMDB를 Git 기반으로 재정의
엑셀 목록을 없애려면 운영 Inventory를 YAML/JSON/Markdown table로 Git에서 관리해야 합니다. 이게 없으면 변경 영향도 분석이 거의 불가능합니다.
최소한 아래 엔티티는 표준화해야 합니다.
| 엔티티 | 반드시 있어야 할 정보 |
|---|---|
| Cluster | 목적, 위치, K8s 버전, Cilium 버전, 운영/개발 구분, 담당자 |
| Node | 역할, rack/zone, NIC, disk, label, taint, pool, 장애 이력 |
| Namespace | owner, 용도, 사용자/팀, quota, network policy, backup 정책 |
| Workload | 서비스명, owner, 중요도, SLO, 의존 서비스, image, Git repo |
| Storage | PVC, StorageClass, Longhorn/OpenEBS/LocalPV 구분, backup 여부 |
| AIStor | object store, bucket, prefix, policy, owner, ILM, replication, inventory |
| Identity | Keycloak group, K8s RBAC, service account, MinIO policy 매핑 |
| Change | 변경 대상, 변경 사유, 영향 범위, rollback, 검증 결과 |
| Incident | 증상, 영향, 원인, 조치, 재발방지, 관련 SOP |
특히 사용자 2000명 이상, namespace/SA/Keycloak/MinIO policy가 얽힌 구조에서는 owner, criticality, data_path, backup_policy, restore_procedure, last_changed_by가 없으면 시간이 갈수록 운영 복잡도가 폭발합니다.
3.3 Policy as Code
운영 기준은 문서에만 있으면 안 됩니다. 가능한 것은 CI나 Admission 단계에서 막아야 합니다.
예를 들면 다음 기준입니다.
| 영역 | 정책 예시 |
|---|---|
| Namespace | owner/criticality/backup-policy label 없으면 reject |
| Workload | resource requests/limits 없으면 reject |
| Security | privileged pod, hostPath, hostNetwork 제한 |
| Image | Harbor 내부 registry만 허용, latest tag 금지 |
| Network | 기본 deny 후 필요한 egress/ingress만 허용 |
| Storage | 중요 workload는 backup-policy annotation 필수 |
| AIStor 접근 | bucket/prefix owner와 service account 매핑 필수 |
| 운영 변경 | change-id annotation 없는 운영 namespace 변경 금지 |
Kyverno는 Kubernetes-native policy engine으로 YAML/CEL 기반 정책, admission control, background scan, image verification, policy-as-code 관리를 지원합니다. (Kyverno) Kubernetes 자체도 ValidatingAdmissionPolicy를 통해 외부 webhook 없이 CEL 기반 검증을 API 서버 내부에 둘 수 있습니다. (Kubernetes)
현실적인 권장안은 이렇습니다.
| 정책 유형 | 추천 |
|---|---|
| 단순 검증 | Kubernetes ValidatingAdmissionPolicy |
| mutate/generate/cleanup/image 검증 | Kyverno |
| 복잡한 조직 정책, 외부 시스템 연계 | OPA/Gatekeeper 또는 별도 CI 검증 |
| 운영 초기 | audit/warn |
| 성숙 후 | enforce |
처음부터 강하게 막으면 운영팀이 우회하게 됩니다. 처음 1~2개월은 audit mode로 위반 현황을 보고, 반복 위반이 줄어든 정책부터 enforce로 올리는 방식이 좋습니다.
3.4 Observability + 상태 수집 계층
지금 Prometheus/Grafana/OpenSearch가 있으므로, 여기에 운영 판단용 상관관계 계층을 추가하는 것이 중요합니다.
OpenTelemetry는 traces, metrics, logs를 생성·수집·내보내기 위한 vendor-neutral framework입니다. (OpenTelemetry) 현재 환경에서는 다음 순서가 좋습니다.
- 기존 Prometheus/OpenSearch를 유지한다.
- K8s event, ArgoCD sync event, Jenkins build result, Git commit, AIStor admin/metric, Cilium status를 같은 시간축으로 연결한다.
- 장애 발생 시 “변경 직후인가?”, “특정 node/rack/EC set/pool인가?”, “Cilium drop/softIRQ/CPU/network와 동시 발생인가?”, “ArgoCD drift나 sync가 있었나?”를 자동으로 모은다.
- LLM은 이 증거 묶음을 요약하고, 관련 SOP와 과거 장애를 찾아 제시한다.
Google SRE 책에서도 alert는 원인보다 사용자 영향이나 임박한 문제 같은 “증상” 중심으로 단순하고 명확해야 한다고 설명합니다. (Google SRE) 따라서 LLM으로 모든 alert를 똑똑하게 해석하려 하기보다, 먼저 alert 품질을 정리해야 합니다.
3.5 Read-only SRE Copilot
당장 자동 변경을 하지 않는다는 전제에서는 다음 형태가 가장 안전합니다.
| 기능 | 1단계 권장 수준 |
|---|---|
| K8s 조회 | read-only |
| Prometheus 조회 | read-only |
| OpenSearch 로그 검색 | read-only |
| ArgoCD 상태 조회 | read-only |
| Git diff 분석 | read-only |
| AIStor 상태 조회 | read-only |
| Cilium 상태 조회 | read-only |
| Jenkins 실행 | 초기에는 금지 또는 dry-run만 |
| kubectl apply/delete | 금지 |
| 자동 복구 | 금지 |
| 변경안 생성 | PR 초안까지만 |
MCP는 LLM 애플리케이션과 외부 데이터/도구를 연결하기 위한 표준화된 방식이며, resources, prompts, tools 같은 개념을 제공합니다. 다만 MCP는 강력한 도구 실행 경로를 만들 수 있으므로, 명시적 동의와 접근 통제, tool safety가 중요합니다. (모델 컨텍스트 프로토콜) LangGraph 같은 프레임워크는 long-running, stateful agent, durable execution, human-in-the-loop에 적합하므로, 운영 자동화보다는 “상태 수집 → 판단 초안 → 사람 승인 → PR/작업계획 생성” 흐름에 먼저 쓰는 것이 좋습니다. (LangChain Docs)
4. 운영 프로세스 체계
4.1 표준 요청은 Golden Path로 처리
반복되는 요청은 티켓/수작업이 아니라 템플릿화해야 합니다.
예를 들면 다음입니다.
| 요청 유형 | Golden Path 산출물 |
|---|---|
| 사용자 namespace 생성 | namespace YAML, quota, RBAC, NetworkPolicy, service account, 기본 secret |
| Spark/Airflow/Jupyter runtime 제공 | 표준 manifest, resource class, SA, MinIO policy |
| MinIO bucket/prefix 권한 요청 | policy template, owner mapping, 만료일, 검토자 |
| 신규 서비스 온보딩 | catalog entry, dashboard, alert, runbook, backup policy |
| 계정/권한 변경 | Keycloak group, K8s RBAC, MinIO policy, audit trail |
| 배치/워크플로우 등록 | resource profile, queue/YuniKorn/Kueue 설정, SLO/우선순위 |
요청자는 포털이나 Git PR로 요청하고, CI가 검증한 후 운영자가 승인하는 방식이 좋습니다.
4.2 변경관리는 Git PR 중심
작업계획서는 문서로 끝나면 안 됩니다. PR과 연결되어야 합니다.
작업계획서에는 최소한 아래가 들어가야 합니다.
1. 변경 목적
2. 변경 대상
3. 변경 전 상태
4. 예상 영향 범위
5. 사전 점검 결과
6. 변경 절차
7. 검증 절차
8. rollback 절차
9. 관련 백업 상태
10. 중단 가능성 및 사용자 영향
11. 승인자
12. 변경 후 관찰 지표변경 PR이 올라오면 CI가 다음을 자동으로 검사해야 합니다.
| 검증 | 예시 |
|---|---|
| Manifest 검증 | kubeconform, kubectl dry-run |
| Policy 검증 | kyverno test, conftest |
| ArgoCD diff | 적용 시 변경될 리소스 목록 |
| Resource 검증 | CPU/memory/storage quota 초과 여부 |
| Network 영향 | NetworkPolicy/CiliumPolicy 변경 여부 |
| Storage 영향 | PVC, StorageClass, backup-policy 변경 여부 |
| Auth 영향 | RoleBinding, ClusterRoleBinding, Keycloak mapping 변경 여부 |
| AIStor 영향 | bucket/prefix/policy/ILM 변경 여부 |
| Rollback 가능성 | 이전 commit, 백업, 복구 절차 존재 여부 |
운영 중인 데이터와 사용자 시스템 영향도를 줄이려면 변경 전 자동 리포트가 반드시 필요합니다.
4.3 장애관리는 Timeline + Evidence 중심
장애 발생 시 LLM에게 바로 “원인이 뭐야?”라고 물으면 위험합니다. 먼저 증거 패키지를 만들어야 합니다.
장애 시 자동 수집해야 할 항목은 다음입니다.
| 영역 | 수집 항목 |
|---|---|
| 시간 | 최초 탐지, 사용자 영향 시작, 주요 이벤트 |
| K8s | node condition, pod restart, event, deployment change |
| Cilium | drop, policy verdict, endpoint 상태, BGP 상태, Hubble flow |
| AIStor | 5xx, quorum, EC set tolerance, drive offline, healing, scanner, latency |
| Network | NIC drop, softIRQ, conntrack, retransmit, DNS |
| Auth | Keycloak error, token validation, cert expiry, ingress TLS |
| CI/CD | 직전 ArgoCD sync, Jenkins job, Git commit |
| Storage | Longhorn/OpenEBS volume 상태, replica 상태, backup 상태 |
| User impact | 어떤 namespace, 어떤 workflow, 어떤 bucket/prefix 영향 |
장애분석서는 blameless postmortem 형태가 좋습니다. Google SRE의 postmortem 철학도 장애를 문서화하고, 원인을 이해하고, 재발 방지 조치를 남기는 것을 핵심으로 봅니다. 또한 postmortem은 처벌이 아니라 학습 기회여야 한다고 설명합니다. (Google SRE)
5. 현 상태 리포트 체계
매일 또는 주간으로 아래 리포트를 자동 생성하는 것을 추천합니다.
Cloud Native Data Lakehouse Daily/Weekly Health Report
1. Overall Status
- Green / Yellow / Red
- 주요 위험 3개
- 전일 대비 변화
2. Cluster Health
- API server / etcd / scheduler / controller-manager
- node not ready, disk pressure, memory pressure
- CoreDNS, Cilium, Ingress/Gateway
3. Storage Health
- AIStor capacity, drive/pool/node 상태
- EC read/write tolerance, quorum warning
- 4xx/5xx, latency, healing/scanner 상태
- Longhorn/OpenEBS volume 상태
4. Data Platform
- Spark, Trino, StarRocks, Airflow, JupyterLab
- queue backlog, failed job, user impact
5. Security/Auth
- Keycloak 상태
- cert 만료 예정
- privileged workload
- RBAC/SA/policy drift
6. GitOps/Change
- ArgoCD OutOfSync
- 최근 변경
- 실패한 sync
- pending PR
7. Backup/DR
- etcd 최신 backup
- Git/artifact/image backup
- PV backup
- restore test 결과
- RPO/RTO 위반 항목
8. Action Items
- 즉시 조치
- 7일 내 조치
- 구조 개선 과제이 리포트가 잘 나오면 담당자가 바뀌어도 “무엇이 정상이고 무엇이 위험한지” 빠르게 파악할 수 있습니다.
6. K8s 환경에서 백업 범위
Kubernetes 백업은 “etcd만 백업하면 된다”도 아니고, “PV만 백업하면 된다”도 아닙니다. 계층별로 나눠야 합니다.
Kubernetes 공식 문서에 따르면 모든 Kubernetes object는 etcd에 저장되며, control plane 노드 손실 같은 재해 상황에 대비해 etcd 백업이 중요합니다. etcd snapshot에는 민감 정보도 들어 있으므로 암호화해 보관해야 합니다. (Kubernetes)
6.1 백업 대상 계층
| 계층 | 백업 대상 | 권장 방식 |
|---|---|---|
| 0. 운영 원천 | Git repo, Jenkinsfile, ArgoCD app, Ansible, Kubespray inventory, SOP | Git mirror, 정기 export, 별도 저장소 |
| 1. Control Plane | etcd snapshot, kubeadm/kubespray config, 인증서, encryption config | etcd snapshot + 암호화 + off-cluster 보관 |
| 2. K8s 선언 상태 | CRD, CR, namespace, RBAC, NetworkPolicy, StorageClass, Secret metadata | GitOps 원천 + Velero 보조 |
| 3. Secret/PKI | Keycloak secret, Vault/KES, TLS cert, CA, token signing key | 별도 암호화 백업, 접근통제 |
| 4. Platform DB | Keycloak DB, Harbor DB, Nexus DB, Airflow DB, Argo/Jenkins state | DB-native backup + WAL/archive |
| 5. PV/PVC | Longhorn/OpenEBS/CNPG/KubeVirt/Jenkins/Harbor/Nexus 등 | CSI snapshot + storage-native backup |
| 6. Observability | Prometheus, Alertmanager, Grafana dashboard, OpenSearch index template | 설정은 Git, 데이터는 중요도별 보관 |
| 7. Registry/Artifact | Harbor image, Nexus artifact, Helm chart, binary mirror | registry/artifact backup + checksum |
| 8. AIStor 데이터 | bucket/object/version/ILM/inventory | AIStor 자체 replication/ILM/object-lock/inventory 체계 |
| 9. 운영 지식 | SOP, 장애이력, 작업계획, LLM Wiki, RAG index 원천 | Markdown 원본 Git 관리, index는 재생성 가능하게 |
Velero는 CSI snapshot API를 이용해 CSI-backed volume을 백업·복구할 수 있습니다. 다만 Kubernetes VolumeSnapshot은 CSI driver가 snapshot 기능을 구현했는지에 따라 가능 여부가 달라지므로, Longhorn/OpenEBS/기타 CSI별로 반드시 실제 restore test가 필요합니다. (Velero) (Kubernetes)
6.2 백업 정책 기준
| 대상 | RPO | RTO | 비고 |
|---|---|---|---|
| etcd | 1~4시간 | 수 시간 | 업그레이드/대규모 변경 전 필수 snapshot |
| Git/Docs | 거의 0 | 1시간 이내 | mirror와 immutable backup |
| Keycloak/CNPG | 5~15분 | 1~2시간 | WAL archive 필수 |
| Harbor/Nexus | 수 시간 | 4~8시간 | air-gap 환경에서는 매우 중요 |
| ArgoCD/Jenkins | 수 시간 | 2~4시간 | 설정은 Git, runtime state는 backup |
| Prometheus/OpenSearch | 중요도별 | 중요도별 | 모든 raw data를 동일 RPO로 볼 필요 없음 |
| AIStor object data | 업무별 | 업무별 | K8s backup이 아니라 AIStor DR/replication/ILM 영역 |
| Jupyter 사용자 홈 | 정책별 | 정책별 | 개인 sandbox 정책과 연결 |
| Spark shuffle/cache | 백업 불필요 | 재생성 | ephemeral로 분류 |
중요한 원칙은 restore test가 없는 백업은 백업으로 보지 않는 것입니다. 최소 월 1회는 “문서상 복구”가 아니라 실제 격리 환경에서 복구 검증을 해야 합니다.
7. 블록스토리지에 대한 판단
현재 환경에서 블록스토리지가 애매한 것은 자연스럽습니다. 대규모 Data Lakehouse에서는 모든 것을 하나의 블록스토리지로 해결하려고 하면 오히려 위험합니다.
권장 방향은 스토리지 용도를 세 계층으로 분리하는 것입니다.
7.1 권장 스토리지 분류
| 분류 | 용도 | 권장 스토리지 |
|---|---|---|
| Data Lake 원본 데이터 | 대규모 객체, Iceberg/Parquet, 분석 데이터 | AIStor/S3 |
| 재생성 가능한 고성능 로컬 데이터 | Spark shuffle, StarRocks cache, 임시 작업공간, containerd 일부 | LocalPV, OpenEBS LocalPV, node-local disk |
| 운영 플랫폼 상태 데이터 | Keycloak DB, CNPG, Harbor, Nexus, Jenkins, Airflow metadata, KubeVirt 일부 | Longhorn/OpenEBS Mayastor/Ceph RBD 등 replicated block |
| 백업/아카이브 | DB backup, PV backup, 문서, artifact backup | AIStor 또는 별도 backup target |
핵심은 이겁니다.
AIStor/S3를 영구 데이터 레이어로 보고, K8s 블록스토리지는 “운영 플랫폼 상태 저장소”와 “일부 VM/DB용”으로 제한하는 것이 안전합니다.
7.2 Longhorn 사용에 대한 현실적 판단
Longhorn은 운영 편의성이 좋고 recurring snapshot/backup을 지원합니다. Longhorn 공식 문서도 PVC나 StorageClass에 recurring job을 붙여 snapshot/backup을 자동 생성할 수 있고, delta backup 및 주기적 full backup 옵션을 제공합니다. (Longhorn)
다만 대규모 환경에서는 다음처럼 제한적으로 쓰는 것이 좋습니다.
| 용도 | Longhorn 적합도 |
|---|---|
| Keycloak/CNPG 같은 common platform DB | 가능하나 DB-native backup 병행 필수 |
| Jenkins/ArgoCD/Grafana 등 운영 도구 | 적합 |
| KubeVirt 소수 VM | PoC 후 가능 |
| 대규모 분석 워크로드의 고성능 I/O | 비추천 |
| Spark shuffle/cache | 비추천, local ephemeral 권장 |
| AIStor 데이터 경로 | 사용하면 안 됨 |
| 매우 큰 고변경률 DB | 신중, 성능·복구 검증 필수 |
Longhorn을 쓴다면 replica=3, node/disk anti-affinity, backup target, recurring backup, restore drill, volume별 성능 측정이 필수입니다.
7.3 OpenEBS/Mayastor/Ceph 계열 판단
| 후보 | 장점 | 주의점 |
|---|---|---|
| OpenEBS LocalPV | 단순, 빠름, 로컬 NVMe 활용 | 노드 장애 시 데이터 보호 없음 |
| OpenEBS Mayastor | NVMe 기반 성능 기대 | 운영 성숙도와 장애 대응 검증 필요 |
| Longhorn | 운영 편의성, 백업 기능, UI | 고성능/대규모 고변경률 workload에는 부담 가능 |
| Rook-Ceph/Ceph RBD | 범용성, 성숙도, block/file/object | 운영 복잡도 큼, 전담 역량 필요 |
| Isilon/NFS | 기존 자산 활용 | DB/고성능 block 용도로는 부담 가능 |
제 의견은 다음입니다.
- Common cluster의 핵심 운영 도구용 block storage는 Longhorn 또는 Mayastor 중 하나로 표준화합니다.
- DB는 CSI snapshot만 믿지 말고 DB-native backup을 반드시 병행합니다. CNPG라면 WAL archive와 base backup이 핵심입니다.
- Compute cluster의 분석 runtime은 가능한 stateless/ephemeral로 설계하고, 결과와 원본은 AIStor에 둡니다.
- KubeVirt가 중요해진다면 Longhorn/Mayastor/Ceph RBD를 별도 PoC로 비교해야 합니다. 이때 live migration, node failure recovery, snapshot, restore, 성능, 운영 복잡도를 같이 봐야 합니다.
- AIStor 백업을 같은 AIStor에만 두는 순환 의존성은 피해야 합니다. 최소한 다른 objectstore, warm tier, 별도 pool, 또는 외부 백업 영역을 분리해야 합니다.
8. LLM/RAG 체계는 이렇게 잡는 것이 좋음
단순 RAG 인덱싱만으로는 부족합니다. 운영 의사결정에는 “문서 검색”보다 “현재 상태 + 과거 이력 + 표준 절차 + 변경 이력 + 의존성”이 중요합니다.
권장 구조는 다음입니다.
| 계층 | 역할 |
|---|---|
| Raw Docs | Confluence export, vendor docs, SOP, 장애이력 원본 |
| Normalized Markdown | Git에 저장되는 정제 문서 |
| Metadata | service, component, version, owner, risk, reviewed date |
| Hybrid Search | OpenSearch BM25 + vector search |
| Reranker | 질문과 문서 조각의 관련도 재정렬 |
| Knowledge Graph | 서비스, namespace, node, bucket, owner, alert, runbook 관계 |
| Live Tools | K8s, Prometheus, OpenSearch, ArgoCD, AIStor, Cilium read-only 조회 |
| LLM Wiki | 사람이 읽을 수 있는 운영 요약, index, decision log |
| Agent Workflow | 상태 수집 → 근거 정리 → 판단 초안 → 사람 승인 |
LLM 답변은 항상 아래 형식으로 나오게 해야 합니다.
1. 결론
2. 판단 근거
3. 확인한 데이터
4. 관련 변경 이력
5. 관련 SOP
6. 영향 가능성이 있는 서비스/사용자/데이터
7. 즉시 조치
8. 추가 확인 필요 사항
9. 신뢰도LLM이 “그럴 것 같다”고 말하는 것은 운영에 쓸 수 없습니다. 반드시 “어떤 metric/log/event/doc/git commit을 봤는지”를 같이 내야 합니다.
9. 단계별 추진 로드맵
Phase 0. 2~4주: 기준 정리
목표는 “운영 체계의 뼈대”를 만드는 것입니다.
| 작업 | 산출물 |
|---|---|
| 운영 도메인 분류 | K8s, Cilium, AIStor, Keycloak, CI/CD, Observability, Storage |
| 문서 표준 정의 | SOP, 작업계획서, 장애분석서, 변경요청서 template |
| 메타데이터 표준 | owner, service, risk, backup-policy, criticality |
| Git repo 구조 확정 | platform-iac, gitops-env, ops-docs, policies 등 |
| Inventory 초안 | cluster/node/namespace/service/storage/bucket |
| 백업 현황 조사 | 현재 백업 대상, 누락 대상, restore 가능 여부 |
| 블록스토리지 분류 | durable / replicated / ephemeral 구분 |
이 단계에서는 자동화보다 표준화가 우선입니다.
Phase 1. 1~2개월: Git 기반 운영 원천화
| 작업 | 산출물 |
|---|---|
| Confluence 주요 문서 Markdown 변환 | Git 기반 ops-docs |
| 외부 vendor docs 정리 | 버전/출처/적용범위 포함 |
| SOP/작업계획서 템플릿 적용 | 신규 문서부터 강제 |
| Git PR 기반 변경관리 시작 | 변경 이력과 승인 이력 확보 |
| CI 문서 검증 | markdown lint, metadata check |
| K8s manifest 검증 | kubeconform, kubectl dry-run |
| Policy audit | Kyverno/OPA audit mode |
| ArgoCD drift 리포트 | OutOfSync 정기 리포트 |
이 단계의 목표는 “누가 봐도 현재 운영 기준이 Git에 있다”는 상태입니다.
Phase 2. 2~3개월: 현 상태 리포트와 영향도 분석
| 작업 | 산출물 |
|---|---|
| Prometheus/OpenSearch/K8s API 연결 | read-only 상태 수집기 |
| ArgoCD/Jenkins/Git 변경 이력 연결 | 변경-장애 상관관계 |
| AIStor/Cilium 핵심 metric 선정 | 5xx, quorum, drop, BGP, latency |
| Daily/Weekly health report 자동 생성 | 운영 리포트 |
| 변경 영향도 분석 v1 | Git diff 기반 영향 리포트 |
| 장애 evidence package | 장애 시 자동 수집 bundle |
| 과거 장애 문서 tagging | 유사 장애 검색 가능 |
이 단계가 되면 운영자는 장애 때 “어디부터 볼지”를 빠르게 좁힐 수 있습니다.
Phase 3. 3~6개월: Golden Path와 정책 강제
| 작업 | 산출물 |
|---|---|
| namespace 생성 Golden Path | 표준 YAML/PR 자동 생성 |
| 사용자 runtime Golden Path | Spark/Airflow/Jupyter 표준 제공 |
| MinIO/AIStor policy Golden Path | bucket/prefix 권한 요청 표준화 |
| Keycloak group ↔ namespace/RBAC 매핑 | 권한 운영 표준화 |
| Policy enforce 전환 | 반복 위반 정책부터 차단 |
| Backup policy 자동 점검 | backup 없는 중요 PVC 탐지 |
| Restore drill 정례화 | 월간/분기별 복구 훈련 |
이 단계의 목표는 “운영자가 매번 판단하지 않아도 되는 요청”을 줄이는 것입니다.
Phase 4. 6~12개월: 승인 기반 AIOps/Agentic Ops
| 작업 | 산출물 |
|---|---|
| Read-only SRE Copilot 운영 | 장애·변경 판단 보조 |
| LangGraph 기반 진단 workflow | 상태 수집 → 요약 → SOP 추천 |
| PR 자동 생성 | 변경안/rollback/검증 항목 초안 |
| ChatOps 연동 | 운영 질의응답, 보고서 생성 |
| Capacity forecasting | AIStor/K8s/namespace/resource 예측 |
| SLO 기반 우선순위 | error budget 기반 변경 제한 |
| 운영 성숙도 리포트 | 팀/서비스별 운영 점수 |
이 단계에서도 자동 적용은 제한적으로만 해야 합니다. 예를 들어 “read-only 진단 → PR 생성 → 사람 승인 → ArgoCD 적용” 흐름이 안전합니다.
10. 인수인계가 쉬운 운영 체계
담당자가 바뀌어도 빨리 올라오려면 문서가 많은 것보다 경로가 일정해야 합니다.
각 컴포넌트별로 아래 7개 문서는 반드시 있어야 합니다.
| 문서 | 내용 |
|---|---|
| Overview | 이 컴포넌트가 왜 있고 어떤 역할인지 |
| Architecture | 구성도, 의존성, HA 구조, 데이터 흐름 |
| Daily Check | 매일 확인할 지표와 정상 기준 |
| SOP | 정상 작업 절차 |
| Incident Runbook | 장애 유형별 대응 |
| Change Guide | 업그레이드/확장/설정변경 절차 |
| Backup/Restore | 백업 범위, 주기, 복구 절차, 검증 이력 |
컴포넌트별 우선순위는 다음이 좋습니다.
- AIStor
- Kubernetes control plane / etcd
- Cilium
- Keycloak
- ArgoCD/Jenkins/Bitbucket
- Harbor/Nexus
- Longhorn/OpenEBS/CNPG
- Prometheus/Grafana/OpenSearch
- Airflow/Spark/StarRocks/Trino/JupyterLab
11. 지금 당장 시작할 우선순위
가장 먼저 할 일은 아래 10개입니다.
| 우선순위 | 작업 |
|---|---|
| 1 | SOP/작업계획서/장애분석서 Markdown template 확정 |
| 2 | 모든 문서에 front matter 메타데이터 적용 |
| 3 | cluster/node/namespace/service/storage/bucket inventory 작성 |
| 4 | Git repo 구조 정리 |
| 5 | 변경 PR template과 작업계획서 연결 |
| 6 | K8s manifest/policy CI 검증 시작 |
| 7 | ArgoCD drift 정기 리포트 생성 |
| 8 | etcd/Git/Keycloak/Harbor/Nexus/Longhorn/AIStor 백업 현황표 작성 |
| 9 | Daily/Weekly Health Report 초안 자동 생성 |
| 10 | Read-only SRE Copilot의 데이터 소스 목록 확정 |
12. 최종 권장 운영 모델
제가 보기에는 귀사 환경은 아래 모델이 가장 맞습니다.
1. 운영 원칙
Git First
Docs as Code
Policy as Code
Observability as Evidence
Human-approved Automation
Restore-tested Backup
2. 운영 방식
표준 요청 = Golden Path
고위험 변경 = Git PR + 영향도 분석 + 승인
장애 대응 = Evidence Package + Runbook + Postmortem
권한 관리 = Keycloak group + K8s RBAC + MinIO policy 매핑
백업 관리 = 계층별 RPO/RTO + 정기 restore drill
3. AI 활용
초기: read-only 질의응답/요약/상관관계 분석
중기: 변경 영향도 분석/보고서/PR 초안
후기: 승인 기반 runbook 실행
금지: 무승인 자동 변경, 무근거 원인 단정
4. 스토리지 전략
AIStor = 영구 데이터 레이어
LocalPV = 재생성 가능한 고성능 임시 데이터
Longhorn/OpenEBS/Ceph = 제한된 운영 플랫폼 상태 데이터
DB = DB-native backup 필수
K8s backup = object data 보호 수단 아님가장 중요한 판단은 이것입니다.
지금은 자동화의 깊이보다 운영 판단의 정확도를 높이는 단계입니다.
먼저 Git, 문서, inventory, observability, backup, incident history를 하나의 체계로 묶고, 그 위에 LLM을 read-only 운영 보조자로 올리는 것이 맞습니다.
그 다음에 반복 작업을 Golden Path로 줄이고, 마지막에 승인 기반 자동화로 가는 순서가 안전합니다.
