Summary
- 클라우드와 컨테이너의 확산으로 개발자는 코드뿐만 아니라 배포/운영/인프라 까지 이해가 필요해짐
- k8s와 GitOps는 현대 인프라의 표준이며, AI를 결합한 GitAIOps는 인프라 구축 및 운영을 더욱 자동화
- 에이전트형 AI를 협업도구로 사용해 가상의 스타트업을 직접 구축하고 성장시키는 실습 진행
Thoughts
- 개발자도 인프라를 잘 알아야 한다는 부분에는 큰 공감
- 개발자 또한 배포/로그/모니터링/CICD를 알아야 협업/장애대응시 대처가 빠르기에 동의하는 부분
- GitAIOps가 기존 GitOps 대비 얼마나 다른지, 본질적으로 다른건지는 의문
- 운영과정에 대한 책(AWS,k8s,GitOps 등)이나 개발 중 AI 활용에 대한 책(바이브코딩,Spec Driven 등)은 종종 보았음
- AI 에이전트를 운영 프로세스에 녹여내는 과정에 대한 방법론/책은 없었기에 기대가 됨
- 아직까진 새로운 패러다임이라기보단 GitOps의 단점을 보완하는 느낌이라 추가로 어떤 문제를 해결하는지 실습을 진행해봐야 알것 같음
- Guardrail의 유지 관리가 GitAIOps의 품질을 결정할 것 같음
- Claude Code의 SKILL로 제공되는 부분을 실습자의 환경에 따라 유사하게 작동되도록 구성한듯함
- 세션마다 초기화되는 AI 컨텍스트를 CLAUDE.md/가드레일 파일로 보완한다는점에서 하네스 엔지니어링과 비슷한가 싶음
- Garbage In/Garbage Out이니 이러한 가드레일의 작성 및 관리도 익혀둬야할 부분이라고 생각함
여기 레포에 guardrails이라고 부르는 시스템이 기존 클로드코드 SKILLS 활용이랑 같은거야?
그럼 이 방식이 SKILLS보다 어떤 장점이 있어?
1. AI 시대, 개발자의 인프라
1.1 개발자에게 인프라가 다가온 시대
- 클라우드와 컨테이너의 확산으로 인해 개발자가 배포,운영,인프라까지 이해해야하는 시대가 되었음
1.1.1 DevOps 문화의 확산
- 과거에는 개발 조직과 운영 조직이 분리되어있었음
- You build it, you run it, 만든사람이 운영하는 문화가 확산되어 개발자가 운영까지 책임지게 됨
- 코드작성 이후 배포, 모니터링, 로그확인, 장애대응, CI/CD 등등..
1.1.2 클라우드 네이티브 전환
- 클라우드 환경에서 서버를 직접 수동으로 셋팅하는 대신 코드로 관리하는것의 보편화
- 콘솔 작업 대신 Terraform, k8s YAML 등을 통해 코드로 정리하고 git 으로 관리 > 재현/ 추적 가능성 높아짐
- K8s Manifest, Helm chart, CI/CD pipeline, 모니터링 구성등 다양한 분야에서 코드화 관리
1.1.3 풀스택의 범위 확장
- 풀스택 개발자는 기존 프론트+백 을 넘어서 배포, 운영, 인프라까지 포함
- 서비스 개발 뿐만 아니라 컨테이너화>배포>트래픽>로그>장애및복구 까지 흐름 이해필요
1.2 쿠버네티스, 클라우드 인프라의 공통 언어
- 개발자의 인프라 공부 시작점으로 쿠버네티스를 추천함
1.2.1 왜 쿠버네티스인가
- 특정 클라우드에 종속되지 않음: AWS(EKS), GCP(GKE), Azure(AKS), 온프레미스 환경에서도 이름만 다를뿐 동일한 방식으로 사용하고 운영할 수 있음
- 클라우드 운영체제: 프로세스, 파일시스템, 네트워크등을 추상화한 운영체제(리눅스)처럼, 쿠버네티스는 배포, 스토리지, 네트워킹, 보안등을 추상화하여 제공
- 개념이 인프라 전반과 겹침: 인프라 운영에서 필요한 개념이 다른 플랫폼에서도 동일하게 활용가능
- 애플리케이션 배포(Deployment, Pod)
- 트래픽 라우팅(Service, Ingress)
- 설정 및 비밀정보(ConfigMap, Secret)
- 자동 확장(HPA)
- 모니터링과 로그 관리
- 이러한 개념들은 다른 컨테이너 기반 플랫폼(ECS/CloudRun/ContainerApps)에서도 유사함
1.2.2 가파른 학습 곡선
- 쿠버네티스 자체보다는 주변 생태계가 방대하여 선택지/학습 난이도가 높음
- 운영 과정에서 선택해야 하는 많은 도구
- 모니터링(Prometheus, Datadog 등)
- 로그 수집(ELK, Loki)
- 배포 전략(Rolling Update, Blue/Green, Canary)
- GitOps(ArgoCD, Flux)
- 시크릿 관리
- 메시지 큐(Kafka, RabbitMQ 등)
- 트래픽 관리(Ingress, Gateway API)
- 도구 선택 이후에도 설치/설정/연동/운영/문서화 등 각 도구에 대한 숙련 필요
1.2.3 AI라는 새로운 동료
- 에이전트형 AI를 통해 코드 작성을 넘어 직접 명령 수행, 파일 수정, 오류 분석이 가능
- 도구 추천 및 선택 이유, 설치와 설정 수행, 설치 중 에러 분석 수정, 정상 동작 확인 가능
- 모든 선택지를 검토하는것 대신 우리 환경에 적절한 도구를 빠르게 찾고 구축 가능
1.3 GitOps에서 GitAIOps로
- GitOps가 배포를 자동화하였다면, GitAIOps는 인프라 구축/운영/문서화까지 자동화
1.3.1 GitOps: 선언적 관리의 시작
- Git 저장소를 SSOT(Single Source of Truth)로 삼아 인프라를 선언적으로 관리
- 기존 방식은 서버에 접속하여 직접 배포하며, 작업 이력 관리가 어렵고 반복작업/실수가 많음
- GitOps 방식을 통해 원하는 인프라 상태를 코드화하여 저장하면, 실제 상태가 동기화됨
- 배포 자동화 : Git Push만으로 배포
- 변경 이력 관리 : Git 로그가 곧 배포 기록
- 쉬운 롤백 : Git Revert로 이전 상태 복원
- 코드 리뷰 : 인프라도 PR 기반으로 검토
- 재현성 : Git만 있으면 동일한 환경 재구성 가능
1.3.2 GitOps만으로는 부족한 이유
- 배포작업은 자동화 가능하지만, 배포 내용 준비/설정/운영 부담은 사람이 담당함
- YAML을 직접 작성해야 함
- Deployment, Service, ConfigMap, Secret, HPA 등 여러 파일을 관리
- Helm 템플릿과 values 파일도 직접 유지
- 모니터링, 로깅, 알림까지 모두 설정
- 장애 분석도 사람이 메트릭과 로그를 직접 확인
- 문서화는 나중으로 밀려 쉽게 누락
1.3.3 AI가 채우는 빈자리
- 에이전트형 AI를 통해 부족한 자리를 메꿀 수 있음
- 매니페스트 생성: 자연어로 의도를 전달하면 완성된 구성코드 (manifest) 생성 가능
- 장애 분석: Pod 상태, 로그, 이벤트를 분석하여 원인과 해결 방법 제안
- 문서화: 작업 과정과 의사결정을 자동 기록 / 설정 이유와 변경 내역까지 문서로 정리
1.3.4 GitAIOps: Git + AI + Ops
- GitOps는 “선언하면 배포된다”, GitAIOps는 “말하면 배포/운영/관리까지 자동화된다”
| GitOps | GitAIOps |
|---|---|
| 사람이 YAML 작성 | AI가 자연어로 YAML 생성 |
| Git Push → 자동 배포 | 동일 |
| 사람이 로그 분석 | AI가 로그 분석 및 해결책 제안 |
| 사람이 문서 작성 | AI가 작업과 동시에 문서 생성 |
| 사람이 수동 검증 | AI가 클러스터 상태와 문서 비교 |
1.4 이 책의 구성과 실습 흐름
실습 위주로 구성되어 각 문제상황>클로드코드에 지시>결과확인>깃 커밋의 패턴으로 진행
1.4.1 이 책의 흐름
- 앞 장에서 만든 환경을 다음장에서 확장하는 구조
| 구간 | 장 | 핵심 |
|---|---|---|
| 도입 | 1장 | AI 시대, 개발자의 인프라 |
| 환경구성 | 2장 | GKE + 클로드 코드 + 첫 배포 |
| SMB | 3~5장 | GitOps, CI, 관측 가능성, 무중단 배포 |
| 전환기 | 6장 | 캐시, 보안, Canary |
| 엔터프라이즈 | 7~8장 | 규모 확장, 고도화 |
| 종합 | 9장 | GitAIOps: 살아있는 운영 표준 |
1.4.2 실습 환경
- GKE/Claude Code 기반으로 진행하지만 다른 환경에서도 동일하게 구성 가능
1.4.3 이 책의 저장소
- 가이드 저장소(Book_GitAIOps), 실습 후 완성 프로젝트 저장소(notiflex-platform)
1.5 Notiflex 스타트업 시나리오 소개
- 가상의 스타트업 Notiflex의 성장과정에 따라, 서비스 규모별 인프라 발전 실습
1.5.1 Notiflex란?
- Notiflex는 고객 서비스에서 발생한 이벤트를 이메일·SMS·푸시로 전달하는 B2B 알림 SaaS 플랫폼.
1.5.2 성장 타임라인
- 처음부터 완벽한 구성이 아닌 비즈니스 성장에 맞춰 필요한 기술을 하나씩 도입
| 단계 | 해결 과제 |
|---|---|
| 2장 (창업) | GKE에 API 서버 하나를 배포 |
| 3장 (첫 고객) | GitOps와 CI/CD 도입으로 배포 자동화 |
| 4장 (서비스 장애) | 모니터링·로그를 구축해 관측 가능성 확보 |
| 5장 (성장 시작) | 무중단 배포 도입 |
| 6장 (전환기) | 캐시, 시크릿 관리, 배포 전략 개선 |
| 7장 (대형 고객) | 인프라 확장, 고객별 환경 분리 |
| 8장 (대규모 운영) | 이벤트 기반 아키텍처, 분산 트레이싱, 배치 자동화 |
| 9장 (회고) | 지금까지의 코드와 설정, 문서를 AI가 분석해 운영 표준 완성 |
1.5.3 여러분의 역할
- Notiflex의 DevOps 엔지니어가 되어 서비스를 처음부터 함께 성장시키는 역할 수행
1.6 가드레일: 클로드 코드가 정확하게 동작하는 이유
- 가드레일(Guardrail) 설정을 통해 자유롭게 작업을 막고 검증된 절차와 기준에 따라 작업을 수행함
1.6.1 CLAUDE.md와 가드레일
- 클로드 코드는 프로젝트 루트의 CLAUDE.md 파일을 읽고 동작 규칙으로 삼음
- 가이드의 CLAUDE.md는 입력된 자연어를 참조파일과 매칭하여 답변 제시
- 의사결정 가이드(decision-guides/): 도구 선택 근거
- 실행 가드레일(prompt-guardrails/): 실행 지침, 사전 조건, 단계별 절차, 트러블 슈팅
- 결과 템플릿(result-templates/): 검증 체크리스트, 결과 일치도 체크
1.6.2 3단계 흐름: 탐색 → 비교 → 실행
- 자연어 질문을 던지면 유형에 따라 해당하는 파일이 참조되어 도구 선택부터 실행까지 단계적 진행
- 탐색(의사결정 가이드 기반 적정도구 추천) > 비교 (의사결정 가이드 기반 대안 비교) > 실행 (실행 가드레일 기반 작업 수행 및 결과 템플릿 기반 검증)
1.6.3 왜 가드레일이 필요한가
- 인프라 작업은 작은 설정 오류도 큰 장애로 이어지기 때문에 강력한 검증 절차 필요