Summary
- 저장소 구조, 커밋 이력, 클러스터 상태를 AI와 함께 분석해 2~8장에서 축적한 시스템 전체 회고
- 도구 선택과 자원 사용량을 되짚고 코드, 운영 문서, AI 컨텍스트가 함께 진화한 과정 확인
- Git의 이력, AI의 분석, 생성, Ops의 실행, 관측을 결합한 GitAIOps 운영 모델 정리
- 프로덕션 전환 제안과 실습 클러스터 정리, 최종 문서 갱신으로 전체 여정 마무리
Thoughts
- 이 책은 바이브코딩이나 AI 도구 강의처럼 이런 설정, 이런 프롬프트를 쓰라는 안내가 아니라, 운영 업무 도중 AI로 개선, 효율화할 수 있는 지점을 짚어주는 데 있음
- 조직마다 다른 AI 활용
- 다른 회사/조직의 인프라 엔지니어는 어떤 조건을 걸고 AI를 활용하는지에 대한 궁금증으로 시작
- 각자 환경이 다르기에 정답을 복제할 순 없음, 자기 조직에서 방법을 하나씩 쌓아가는 과정에 대한 가이드
- 그 축적을 개인 단위 기록이 아니라 팀 단위 작업 기록으로 어떻게 남기고 유지보수할지에 대한 인사이트
9장. GitAIOps, 살아있는 운영 표준의 탄생
- 완성된 저장소와 클러스터를 AI에게 분석시켜 지금까지 쌓인 기술, 결정, 운영 지식의 연결 확인
9.1 AI에게 저장소 분석시키기
- 사람의 기억 대신 저장소 구조, Git 이력, 실제 클러스터 상태를 근거로 현재 시스템 파악
9.1.1 저장소 구조 분석
- cc에게
현재 구성된 notiflex-platform 저장소 분석요청- 어플리케이션 분석(app/)
- Go서버, 3개의 엔드포인트, 외부연동(Valkey/Kafka/Otel-Tempo)
- 인프라 분석 (k8s/)
- SMB 인프라 (k8s/smb/): Gateway, Rollout 등 배포 및 운영 리소스 전반
- Enterprise 테넌트 (k8s/enterprise/): 별도 ns에 전용 운영 리소스 배포
- Kafka (k8s/kafka/): Strimzi Operator 기반 단일 브로커 kafka
- 모니터링(k8s/monitoring/): Loki/Tempo, PrometheusRule
- 4개의 노드풀(api-pool/worker-pool/ops-pool/default-pool)에 App of Apps 패턴 관리
- Github Actions 기바 CI/CD
- 3계층 문서 구조(CLAUDE.md, JOURNEY.md, docs/) 및 트러블슈팅
- 어플리케이션 분석(app/)
현재 구성된 notiflex-platform 저장소 분석
9.1.2 커밋 히스토리 분석
- cc에게
git 커밋 히스토리 기반 분석요청- 각 장의 실습 결과가 독립 산출물이 아닌 이전 구조 위에 이어진 작은 커밋의 누적
- Git 이력이 “무엇이 바뀌었는지”와 “어떤 순서로 아키텍처가 성장했는지”를 동시에 제공
git 커밋 히스토리 기반 분석
9.1.3 클러스터 현재 상태
- cc에게
현재 클러스터 상태 분석요청- ArgoCD Application의 Synced, Healthy 상태 > git과 동기화
- 4개의 노드풀, 5개 노드에 구성
현재 클러스터 상태 분석
9.2 쌓인 것들을 돌아보기
- 앞선 저장소 히스토리 분석으로 무엇이 있는지 확인완료, 왜 이렇게 되었는지를 분석
9.2.1 도구 선택 의사결정 종합
- cc에게
지금까지 쌓인것들 리뷰요청- 각 진행단계별 영역별 선택 도구와 이유 요약
- GKE 네이티브, 기존 생태계와의 결합, GitOps 선언 가능성이 반복적인 선택 기준
지금까지 쌓인것들 리뷰
9.2.2 자원 사용 현황과 의사결정 회고
- cc에게
현재 자원 사용량과 할당상태 분석요청- 초기의 default-pool에 CPU 과다하게 집중, 다만 실사용량이 높은것은 아니고 보수적인 리소스산정이 원인
현재 자원 사용량과 할당상태 분석
9.3 기대하지 않았던 효과
- 실습을 위해 쓴 문서가 사람의 기록을 넘어 AI가 다음 작업을 수행하는 운영 컨텍스트로 전환
9.3.1 살아있는 문서
- 일반적인 운영 문서는 별도의 Wiki/Notion/Confluence에 작성
- 작성 시점에는 일치하지만 시간이 지나면서 괴리(drift) 발생
- notiflex-platform의 문서는 코드와 같은 저장소에 위치, 쉬운 변경사항 업데이트 가능
9.3.2 사람이 보는 문서, AI가 읽는 문서
| 문서 | 대상 | 활용 방식 |
|---|---|---|
docs/JOURNEY.md | 사람 | 진행 점검, 결정 히스토리 검토 |
docs/architecture-decisions.md (ADR) | 사람과 AI | 결정 누적, 사람이 검토하고 AI가 의사결정 맥락으로 참조 |
CLAUDE.md | AI | AI에게 프로젝트 메타데이터 안내(매 대화 자동 로드) |
claude-context/ | AI | AI에게 현재 아키텍처 스냅샷 제공(자동 참조) |
.claude/memory/ | AI | AI가 작업 컨텍스트를 떠올리도록 |
settings.local.json | AI | AI의 명령 실행 동작 제어(자동 적용) |
command-guardrails/ | 사람과 AI | 위험 작업 절차서. 사람도 AI도 따라감 |
- 7건 중 6건이 AI 대상 문서
- 일반적인 운영 문서는 작성시점에만 유효하고 이후 유지보수가 이뤄지지않아 방치됨
- 현재 문서 구조는 AI를 위해 설계됐고, 매 작업마다 참고 및 업데이트가 이루어짐
9.3.3 이 구조가 만들어내는 것
- 기반 문서가 현행화되어 관리되기에 새로운 산출물 만들기 용이
- 온보딩 문서 만들어줘 > 현재 클러스터, 저장소 구조 기반 팀원용 가이드 생성
- 보안감사 보고서 만들어줘 > 보안 관련 리소스(netpol, RBAC, secret) 관리 상황 분석
- 운영 표준을 만드려는 별도 공수 대신 AI를 사용한 작업 이력으로 운영 표준 확립 가능
- AI활용 작업 이력의 패턴화 > GitAIOps
9.4 GitAIOps의 출현
- GitOps에 AI를 단순 추가한 것이 아니라 운영 전 과정에서 Git, AI, Ops가 상호 피드백하는 방식
9.4.1 Git + AI + Ops 연결 분석
- cc에게
Git, AI, Ops가 어떻게 연결되는지 분석요청- Git은 선언형 상태, 변경 이력, 의사 결정 등 모든 결정의 저장소
- AI는 코드와 문서 생성, 문제 분석, 작업 기록의 협업 파트너
- Ops는 Git 상태를 클러스터에 동기화하는 자동화 구조
- 운영 결과가 다시 Git의 문서와 설정으로 반영돼 다음 AI 작업의 컨텍스트가 되는 루프 구조
Git, AI, Ops가 어떻게 연결되는지 분석
9.4.2 GitOps와의 차이
- GitOps는 Git의 원하는 상태와 클러스터 실제 상태의 자동 수렴이 중심
- GitAIOps는 AI 기반 분석, 도구 비교, 변경 생성, 문서 갱신, 운영 회고까지 포함
| 항목 | GitOps | GitAIOps |
|---|---|---|
| YAML 작성 | 사람이 직접 | AI가 자연어로부터 생성 |
| 도구 선택 | 사람이 조사하고 결정 | AI가 추천하고 사람이 확인 |
| 문서화 | 별도로 해야 함(보통 빠짐) | AI와의 대화가 자동으로 기록 |
| 트러블슈팅 | 에러 메시지로 검색 | AI가 분석하고 해결책 제시 |
| 동기화 | Git → ArgoCD → 클러스터 | 동일 |
9.4.3 작위적이지 않다
- 처음부터 GitAIOps라는 구조를 설계한 것이 아니라 장별 문제를 해결하며 필요한 문서와 가드레일이 누적된 결과
- 배포 불안정 > ArgoCD + CI
- 장애 원인 파악 어려움 > 모니터링(Prometheus + Loki)
- 배포시 중단 발생 > Gateway API + Blue/Green
- 정합성, 보안, 안정성 > Valkey + Secret Manager+ Canary
- 규모 증가 > 멀티 노드 풀 + 멀티 테넌시
- 호출 지연 및 실패 대응 > 카프카 + 템포
- 이름보다 질문 > 비교 > 실행 > 검증 > 기록이라는 반복 패턴이 본질
9.4.4 진행 방향에 따라 달라지는 구조
- 운영 과정을 경험하며 아래 6가지 자산이 생성됨
- 영구 누적 자산 (CLAUDE.md, ADR, claude-context/, command-guardrails)
- 로컬 작업 자산 (.claude/MEMORY.md, settings.local.json)
- 의도적인 설계가 아닌 필요에 따라 추가, 실제 적용과정에서도 필요에 따라 자산 생성 및 관리
| 자산 | 도입 시점 | 목적 | 현재 상태 |
|---|---|---|---|
CLAUDE.md | 3장 | 자연어 규칙과 행동 가이드 | 적용 |
| 메모리 | 4장 | 작업 컨텍스트 단편 메모 | 적용(머신 로컬) |
docs/architecture-decisions.md (ADR) | 5장 | 결정 사항 누적 기록 | 적용 |
claude-context/ | 6장 | 현재 아키텍처의 전체 그림 | 적용 |
settings.local.json | 7장 | 명령 차단과 승인 권한 분리 | 미적용(학습 후 되돌림) |
command-guardrails/ | 8장 | 위험 작업 실행 절차서 | 적용 |
9.5 마무리: 다음 단계
- 실습 환경을 프로덕션 수준으로 발전시키기 위한 과제와 AI 협업 습관 정리
9.5.1 프로덕션 전환 제안
- cc에게
현재 실습 환경을 프로덕션으로 전환시 보완 대상 분석질문- 보안 및 정책 강화 필요: netpol, OPA/Kyverno/RBAC 세분화
- 스케일링 전략: pod단위(HPA)/node단위(CA)등 전무, Kafka/Valkey가 단일로 구성되 병목예상
- 비용/리소스/알림 최적화: 노드간 리소스 불균형/underutilized, 알림 체계 및 파이프라인 구성
현재 실습 환경을 프로덕션으로 전환시 보완 대상 분석
9.5.2 AI와 대화하는 습관
- 챕터를 누적하며 반복 숙달된 패턴들이 존재
- ‘왜?’를 먼저 묻는다
- xxx 구성해줘 대신 목적에 맞는 도구를 탐색하고 추천과 이유를 검토하여 진행
- 3-프롬프트 패턴 (탐색>비교>실행)
- ex) ArgoCD 구성해줘 대신 배포 자동화 도구 추천으로부터 시작
- 결정의 기록
- 도구 선정 이후 시간이 지나면 도입시 검토한 요소와 판단 근거가 휘발됨
- 같은 저장소안에 의사결정 기록이 남아있어 파악가능
- 한번에 하나씩 진행
- xxx 구성하고 xxx 구성하고 xxx도 만들어줘 대신 한번에 하나씩
- 단계별로 완료하고 검증하고 다음 단계로 진행하는것이 문제발생시 처리에 유리
- 검증의 습관화
- 작업의 완료 이후 정상적으로 동작하는지 검토 확인
- 본 교재에서는 result-template로 예상결과와 실제상황 대조
9.5.3 다시 처음부터
- 유사한?동일한 환경을 재구현시 누적된 기록문서로 인해 빠르고 안전한 작업 가능
- 이미 구성되었던 리소스는 탐색/비교 생략하고 바로 적용 가능
- ArgoCD 대신 flux, B/G 대신 바로 Canary 적용등 변형된 프롬프트 적용
- 가드레일이 쌓여 오작동 및 트러블 슈팅의 가속화
9.6 9장 가드레일 살펴보기
| 서브챕터 | 유형 | 참조 파일 | 역할 |
|---|---|---|---|
| 9.1 저장소 분석 | 실행 | prompt-guardrails/ch9/9.1-repo-analysis.md | 디렉터리 구조, 커밋, 클러스터 상태 조회 |
| 9.2 회고 | 실행 | prompt-guardrails/ch9/9.2-retrospective.md | 의사결정 종합, 자원 사용 분석 |
| 9.3 온보딩 | 실행 | prompt-guardrails/ch9/9.3-onboarding.md | 온보딩 문서 생성, Q&A |
| 9.4 GitAIOps | 실행 | prompt-guardrails/ch9/9.4-gitaiops.md | Git+AI+Ops 연결 분석 |
| 9.5 마무리 | 실행 | prompt-guardrails/ch9/9.5-wrap-up.md | 다음 단계 제안, 환경 초기화 |