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

AI 에이전트 시대의 코드 호스팅: Cursor ‘Origin’은 왜 등장했나

AI 코딩 도구로 빠르게 성장한 Cursor가 이제 코드 에디터를 넘어 코드 호스팅 영역까지 확장하고 있습니다. 2026년 8월 17일 Cursor는 Origin이라는 새로운 코드 호스팅 서비스를 early beta로 공개했습니다. 쉽게 말하면 GitHub처럼 Git 저장소를 만들고, 코드를 올리고, Pull Request(PR)를 만들고 리뷰할 수 있는 서비스입니다. 그런데 단순히 "Cursor가 GitHub 비슷한

By JHL

코딩 에이전트에 1,000억 토큰을 써보니, 병목은 모델 밖에 있었다

Codex 화면에 집계된 누적 사용량은 약 866억 토큰이었다. Claude는 내가 확인할 수 있었던 로컬 머신의 집계값만 합쳐도 약 127억 토큰이었다. 다만 Claude는 여러 워크스테이션과 서버에서 사용했고, 중간에 사용량 데이터를 한 번 날려버리기도 했다. 누락된 머신과 기간을 감안하면 실제 사용량은 300억 토큰을 넘었을 가능성이 높다. 여기에 Ollama Cloud로 사용한 GLM, Qwen

By JHL

AI가 짜준 코드가 배포 속도를 높였다면, 이제는 '신뢰성 가드레일'을 세울 때입니다

최근 많은 팀이 AI 코딩 어시스턴트나 에이전트를 도입하면서 코드 생산 속도가 비약적으로 상승했습니다. 하지만 속도가 빨라졌다는 것은 그만큼 잠재적인 결함이 프로덕션 환경으로 유입되는 속도 또한 빨라졌음을 의미합니다. DevOps.com의 이번 글은 AI가 생성한 코드의 특성과 그로 인해 발생하는 새로운 유형의 리스크, 그리고 이를 제어하기 위한 '신뢰성 가드레일(Reliability Guardrails)

By JHL

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

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

By JHL