49일차

1. 배운 내용

복습

도커와 AWS를 이용해서 AWS 서버에 도커를 설치하고 이미지를 받아서 배포하는 작업을 했다.

2. 실제 작업한 내용

CI/CD 개념 학습

CI/CD에 이미 표준과 같은 흐름들이 자리 잡은 것들이 있다.
CI를 github action으로 처리하고 쿠버네티스(그 사이에 GitOps CD 구성)로 CD를 완성하는 구조가 가장 표준의 흐름처럼 보인다.
쿠버네티스는 상태 기계와 피드백 루프가 핵심이며 항상 목표한 상태를 유지하는 목적으로 CD를 담당한다. 이 목적에 맞게 쿠버네티스의 핵심 기능들을 플러그 인해서 사용하는 생태계가 갖추어 있는 것 같다.

정리하면
[ 1. 소스 코드 관리 (SCM) ]
• Git / GitHub / GitLab
│
▼ (Code Push / PR)
[ 2. 지속적 통합 (CI: Continuous Integration) ]
• 빌드 및 테스트 자동화: GitHub Actions / GitLab CI / Jenkins
• 아티팩트 저장소 (Registry): Docker Hub / AWS ECR / GitHub Packages
│
▼ (Container Image Push)
[ 3. 배포 선언 및 형상 관리 (GitOps / CD 구성) ]
• 선언적 설정 저장소: Git (Manifest Repository)
• 동기화 엔진: Argo CD / Flux CD
│
▼ (Desired State Sync)
[ 4. 지속적 배포 및 운영 (CD: Continuous Deployment) ]
• 오케스트레이션 엔진: Kubernetes (K8s)
• 런타임 및 인프라: containerd / CNI (Calico/Cilium) / CSI (Persistent Storage)
│
▼ (Feedback Loop)
[ 5. 관측 가능성 (Observability & Monitoring) ]
• 메트릭/로그/트레이싱: Prometheus / Grafana / OpenTelemetry

이런 흐름이고 여기에 최근에는 AI가 더해져서 "경험적"으로 안전한 흐름을 자동적으로 구축하고 관리하는 시스템이 되어 가고 있는 것 같다.

3. 소감

개발과는 다른 개념이고 기반 지식들이 어느 정도 필요해서 적응이 조금 느린 분들이 있는 것 같다.
공부를 하면서 "예측-관찰"의 차이를 결정하는 것 또한 목적과 관련되어 있고 행동자체도 목적이 여러 개가 있는 걸 분리할 수 있었는데 이를 어떻게 설계하면 좋을 지에 대해서 아직 더 정리가 필요할 것 같다.