hello

GitLab에서 제작한 GitOps 초보자 가이드

Share
image

소개

소프트웨어 애플리케이션의 복잡도가 증가함에 따라 인프라에 대한 요구도도 함께 증가하고 있습니다. 인프라 팀은 다양한 서비스를 빠르고 안정적으로 제공해야 하지만, 인프라 구축은 여전히 수동 프로세스에 의존하는 경우가 많습니다. 이 문제를 해결하기 위한 핵심 접근 방식이 인프라 자동화이며, 그중 하나가 GitOps입니다.


1. 인프라 자동화의 필요성

  • 애플리케이션 개발은 CI/CD로 자동화되었지만 인프라 관리에는 여전히 사람이 개입.
  • 인프라팀은 복잡한 환경을 빠르고 대규모로 구축해야 하는 과제를 가짐.
  • 수동 구성은 오류가 발생하기 쉽고 비효율적.

2. IaC(Infrastructure-as-Code)의 한계

  • Ansible, Terraform 같은 IaC 도구는 자동화의 좋은 출발점.
  • 그러나 IaC 실행을 자동화하는 명확한 워크플로가 필요.
  • DevOps는 하루에도 수백 번 배포가 가능하지만, 인프라는 여전히 수동 프로비저닝이 많음.

3. 클라우드와 인프라 자동화

  • 클라우드는 대규모 인프라를 일관적으로 자동화할 수 있도록 지원.
  • 하지만 클라우드 서비스가 복잡해지면서 수동 배포의 비효율성은 여전히 존재.
  • 스크립트를 통한 배포가 가능하지만 반복성·표준화·검증 측면에서 한계가 있음.

4. GitOps를 통한 인프라 자동화

GitOps는 DevOps 모범 사례(버전 관리, 코드 검토, CI/CD)를 인프라 운영에 적용합니다.

GitOps의 핵심 아이디어

  • 인프라를 코드(IaC) 로 정의하고 Git 저장소에서 버전 관리
  • 모든 변경은 Merge Request(MR) 를 통해 반영
  • CI/CD 파이프라인이 자동으로 인프라 상태를 원하는 상태로 맞춤
  • 구성 드리프트(Config Drift)가 자동으로 수정됨

5. GitOps의 등장 배경

5.1 인프라 관리의 역사

  • 온프레미스 환경에서는 서버 구축이 대부분 수동으로 이루어짐.
  • 확장 시 동일한 서버를 반복적으로 구성해야 했음.

5.2 구성 관리(CM) 도구의 발전

  • 1세대 CM 도구(Puppet, Chef)
    • 서버 설정을 자동화했지만, 클라우드 네이티브 환경에서는 제약.
  • 2세대 CM 도구(Ansible, SaltStack)
    • VM 프로비저닝과 설정에는 유용하지만, 클라우드 네이티브 서비스 지원은 부족.

5.3 클라우드 네이티브 대응 도구

  • CloudFormation, ARM → 특정 클라우드에 종속.
  • Terraform → 멀티 클라우드 지원, 코드 버전 관리/검토 가능.

6. GitOps의 작동 방식

6.1 GitOps란?

  • Git 리포지토리를 단일 진실 소스(SSOT)로 사용하는 인프라 관리 방식.
  • 원하는 상태를 YAML/JSON으로 선언적으로 정의.

6.2 GitOps 주요 특징

  • IaC 정의: JSON/YAML 기반 선언적 코드
  • 버전 관리: Git이 변경 이력을 모두 추적
  • MR 기반 변경: 변경 사항은 병합 요청을 통해 승인
  • CI/CD 자동화: 코드 병합 시 자동으로 인프라 업데이트
  • 구성 드리프트 방지: 실제 상태와 코드가 불일치하면 자동 교정

7. GitOps의 장점

  • 협업 향상: 모든 변경은 MR을 통해 투명하게 관리
  • 배포 속도 향상: 수동 클릭 대신 코드 기반 자동화
  • 감사 용이성: 변경 이력이 Git에 축적
  • 위험 감소: 변경 롤백 가능, 코드 리뷰 기반 오류 예방
  • 오류 최소화: 반복 가능한 코드 기반 구성
  • 비용 절감: 자동화로 인력/시간/클라우드 리소스 절약
  • 보안 강화: CI/CD만 클라우드에 접근하면 됨
  • 규정 준수 개선: MR 프로세스를 통한 변경 관리

8. 일반적인 GitOps 도구

  • GitOps는 특정 제품이 아니라 프로세스와 문화에 가까움.
  • 주로 사용되는 기술:
    • Terraform
    • Ansible
    • Kubernetes
    • Git
    • CI/CD (GitLab CI, GitHub Actions, Jenkins 등)

9. GitOps와 Kubernetes

  • Kubernetes는 GitOps와 최적의 조합:
    • 컨테이너 기반 불변 인프라
    • 멀티 클라우드 지원
    • YAML 기반 선언적 구성
  • Terraform을 통해 클러스터/DB/네트워크 등 인프라까지 프로비저닝 가능.

10. 기존 클라우드 인프라에서의 GitOps

  • Kubernetes가 아니어도 GitOps 적용 가능.
  • VM 기반 환경에서도 Terraform + Ansible 조합으로 구성 가능.

11. GitOps 도입 모범 사례

11.1 모든 인프라를 코드로 정의

  • 선언적 방식 선호 (원하는 상태를 정의)
  • 기존 인프라를 IaC로 역설계(import) 필요

11.2 단계적 구현

  • 처음부터 모든 인프라를 자동화할 필요 없음
  • 점진적으로 GitOps로 이동

11.3 자동화할 수 없는 작업은 문서화

  • 외부 시스템, 수동 승인 등은 문서로 관리
  • 문서도 Git에 포함하여 저장/검토

11.4 코드 검토 및 MR 프로세스 구축

  • 필수 리뷰어 설정
  • 초기에는 “선택적 검토”, 이후 “필수 검토” 도입
  • GitLab 오픈소스 규칙 참고 가능

11.5 다수 환경(DTAP) 운영

  • Dev → Test → Approval → Prod 순으로 점진적 배포
  • 불변 이미지 사용을 권장하여 구성 드리프트 최소화

11.6 CI/CD를 클라우드 리소스의 단일 접근 지점으로 설정

  • 개발자가 직접 클라우드 환경에 접근할 필요 제거
  • 사고 방식 전환: 직접 접근 → 자동화 파이프라인 중심

11.7 리포지토리 전략 수립

  • 하나의 리포지토리 or 서비스별 리포지토리
  • 고려 사항:
    • 보안
    • 종속성
    • 규모
  • Git branch 전략(Feature Branching) 활용

11.8 변경 사항을 작게 유지

  • 작은 커밋 단위는 이해/검토/롤백이 쉬움

12. GitOps + Terraform 기반 CI/CD

12.1 코드 검증 단계

  • terraform validate
  • JSON/YAML 린터 실행
  • 검증 실패 시 빌드 중단 및 알림

12.2 배포 단계

  • terraform apply
  • CloudFormation의 update-stack 등 활용
  • 인프라 상태를 선언한 코드와 일치시키는 자동화

13. 참고 예시

  • GitOps-Demo Group
    • Terraform 보안 권장 사항
    • 주요 클라우드 제공업체별 코드 샘플
    • 데모 재현 가이드 제공

14. 인프라 자동화의 미래

  • GitOps는 기존 IaC를 DevOps 워크플로에 자연스럽게 통합한 방식.
  • 자동화·반복성·표준화·보안성을 크게 개선.
  • 인프라 유지관리를 자동화하여 개발 배포 주기와 동일한 속도를 유지 가능.
  • 수동 접근을 최소화하여 보안 강화.

결론

GitOps는 인프라를 코드로 정의하고 Git 기반 프로세스를 통해 자동화하는 강력한 접근 방식입니다. 이를 통해:

  • 빠르고 일관된 인프라 배포
  • 안전하고 투명한 변경 관리
  • 높은 개발자 경험
  • 비용 절감 및 운영 효율성 향상

을 실현할 수 있습니다.

Read more

LLM 시대, 프롬프트 엔지니어링보다 '도메인 전문성'이 더 강력한 무기인 이유

최근 AI 도구들이 비약적으로 발전하면서 '프롬프트 엔지니어링'이라는 기술적 기법에 많은 관심이 쏠렸습니다. 하지만 실제 현업에서 LLM을 극한으로 활용해 고도의 결과물을 만들어내는 사람들의 공통점은 정교한 프롬프트 템플릿을 쓰는 능력이 아니라, 해당 분야에 대한 깊은 '도메인 전문성'을 갖추고 있다는 점입니다. 많은 이들이 LLM이 지식의 격차를 줄여준다고

By JHL

AI 코딩 에이전트 도입 시 고려해야 할 보안 제어 프레임워크: 속도와 안전의 균형 잡기

최근 Claude Code나 Kiro와 같은 AI 코딩 에이전트들이 단순한 코드 완성을 넘어, 자연어 프롬프트 하나로 수십 개의 PR을 생성하고 인프라를 수정하는 수준까지 발전했습니다. 하지만 이러한 생산성 향상은 '기계적 속도'라는 트레이드오프를 동반합니다. AI 에이전트는 조직의 보안 리스크나 컴플라이언스를 이해하지 못한 채 오직 '작업 완료'에만 최적화되어

By JHL

AI 벤치마크의 '포화 상태'와 평가 지표의 유효기간: 우리는 무엇을 믿어야 하는가

최근 LLM의 성능이 비약적으로 상승하면서, 역설적으로 우리가 모델의 성능을 측정하는 '자' 자체가 무용지물이 되는 현상이 가속화되고 있습니다. arXiv에 게재된 "When AI Benchmarks Plateau: A Systematic Study of Benchmark Saturation" 연구는 우리가 흔히 신뢰하는 벤치마크 점수가 왜 더 이상 모델 간의 변별력을 제공하지 못하는지, 그리고 이른바 '

By JHL

AI 에이전트 시대의 엔드포인트 보안: 실행 권한을 넘어 '행위 거버넌스'로

DevOps.com을 통해 Airlock Digital이 발표한 'Agentic AI Control & Governance' 솔루션 소식을 접했습니다. 이번 발표의 핵심은 단순히 '어떤 AI 소프트웨어를 실행할 것인가'라는 기존의 화이트리스트 방식(Application Control)을 넘어, 실행 중인 AI 에이전트가 '실제로 어떤 명령을 내리고 어떻게 행동하는가'를 실시간으로 제어하겠다는

By JHL