[DevOps] CI/CD부터 Kubernetes·GitOps까지, DevOps 기술 스택 흐름 정리
목차
git에서 한 단계 더 발전해 CI/CD(Continuous Integration / Continuous Delivery) 가 생겼다. 개발자가 테스트·빌드·다운로드·클라우드 배포를 매번 수동으로 하면 번거롭기 때문에 이를 자동화한 것이다.
이전에는 빌드 → 테스트 서버 확인 → 운영 서버 배포 순으로 진행했고, 배포 후 서버에 트래픽이 몰리면 다운될 수 있어 모니터링도 추가하게 된다.
각 서비스 규모가 커지면 마이크로서비스(Microservice) 로 분리하는 과정을 거치게 된다.
여러 프로세스를 잘 관리하는 것이 DevOps 의 역할이고, 이를 위해 Docker 와 Kubernetes 가 가장 많이 쓰인다.
어떤 기술이 있는지 파악하고, 어떤 문제를 해결하는지 이해한 뒤 적절한 시기에 적용한다. 너무 빠르면 오버 엔지니어링, 너무 늦으면 기술 부채가 된다.
서버를 관리한다는 것
자체 서버 운영
서버 주문 → 설치 → CPU/메모리/하드 조립 → 네트워크 연결 → OS 설치 → 계정 설정 → 방화벽 설치
- 서버를 설정하기 위해 많은 노력과 시간이 필요하다.
- 성능이 좋은 것을 미리 구매하고 효율적 사용을 위해 여러 애플리케이션을 설치한다.
Node.js를 자체 서버에서 관리한다고 하면:
시스템 유저·환경변수·방화벽 설정 → dependencies 설치 → Node.js 설치 → 소스 git clone → 패키지 설치 → 설정 → DB 마이그레이션 → 다중 서버면 프록시 설정 → 그제서야 실행 가능.
이전에는 서버 관리를 코드가 아닌 문서로 했기 때문에 특정 사람이나 그룹만 관리했는데, 코드로 관리하면 그 단점이 줄어든다.
가상머신만 있으면 일단 실행은 된다. 가상머신은 동작을 보장해주고, 하나의 서버에 여러 가상머신을 올려 쓸 수 있다.
클라우드와 PaaS
| 구분 | 예시 | 특징 |
|---|---|---|
| 클라우드 | AWS, Google Cloud, Azure | 하드웨어 파편화 해결, 가상화 환경으로 아키텍처 구성, 이미지 기반 다수 서버 상태 관리. 마치 전기처럼 편리하지만 서버 운영 문제는 여전히 남아있음 |
| PaaS | Heroku, Netlify, AWS Elastic Beanstalk, Google Cloud App Engine | 소스코드만으로 배포 가능, 일반화된 프로비저닝 제공(예: Heroku buildpacks). 단, 프로비저닝 과정에 직접 개입 불가 |
도커의 등장
- 컨테이너: 격리된 환경에서 작동하는 프로세스
- 리눅스 커널의 여러 기술(namespace, cgroups 등) 사용
- 하드웨어 가상화 기술보다 가벼움
- 이미지 단위로 프로세스 실행 환경을 구성
VM은 가상 OS에서 쓰는 메모리·CPU 점유율이 있는데, Docker는 그런 오버헤드가 없다.
도커가 가져온 변화
| 항목 | 내용 |
|---|---|
| 관리 편의성 | 클라우드 이미지보다 관리하기 쉬움 |
| 격리 | 다른 프로세스와 격리되어 가상머신처럼 사용하지만 성능 저하가 거의 없음 |
| 접근성 | namespace, cgroups, network 등 복잡한 기술을 몰라도 사용 가능 |
| 추적성 | 이미지 빌드 기록이 남음 |
| 재현성 | 코드와 설정으로 관리 → 재현 및 수정 가능 |
| 중립성 | 오픈소스 → 특정 회사 기술에 종속되지 않음 |
Docker를 본격 도입하면 4개의 앱을 각각 3개씩 띄워두는 식으로 구성한다.
Docker는 규모가 커지면 관리가 어려워질 수 있다. 컨테이너 빌드·실행까지는 편하게 해주지만, 배포 이후가 복잡해진다.
첫 번째 서버에 접속해서 docker stop → docker run 하면 서버가 하나씩 실행된다. 매번 하나하나 접속해야 해서 불편하다.
도커 그 이후 — 남은 문제들
서비스 검색은 어떻게?
프록시 서버 뒤에 웹서버가 한 대 있다. 사용자가 많아져 웹서버를 하나 더 추가하면 기존에 서버 하나를 보던 걸 2개를 보게 되는데, 이 설정을 한 땀 한 땀 다 해줘야 한다.
LoadBalancer 로 IP 설정을 추가하거나,
각 주소에 따라 보내는(nginx) 방식도 있다. 이 과정을 자동으로 해줄 수 없을까?
서비스 이상·부하 모니터링
App1이 한 대는 죽었지만 2대가 살아있으면 잘 되는 것처럼 보여서, 모니터링이 없으면 장애를 모를 수 있다.
컨테이너 오케스트레이션
서버가 죽으면 새로 띄워주는 프로그램을 짜다 보니 이 도구가 생겼다.
서버 3대가 있고 클러스터 라는 개념으로 마스터에 묶어둔다. 배포 명령을 내리면 알아서 배포해준다. 1,000대·2,000대가 되어도 자동으로 배포된다.
서버를 더 띄우고 싶으면 설정값을 2 → 3으로 바꾸기만 하면 서버가 한 대 더 뜬다. 3대 중 한 대에 문제가 생기면 다른 서버를 띄워준다.
여유가 가장 많은 서버에 배치해주는 것도 오케스트레이션이 자동으로 처리한다.
띄울 공간이 없으면 서버를 새로 만들어서 띄운다.
v1에서 v2로 배포했다가 다시 v1으로 롤백하려면 버전 값만 바꿔주면 된다.
매번 IP를 손으로 등록했던 서비스 등록도, 오케스트레이션은 IP가 생길 때마다 자동으로 중앙에 저장한다. 볼륨(NFS, EBS, Google Cloud 등)도 설정만 하면 자동으로 붙여준다.
도커가 나오면서 서버 관리가 편해졌지만 컨테이너를 하나하나 관리하기 어려워져 오케스트레이션이 나오게 되었다.
다양한 오케스트레이션이 나왔지만, 다른 도구를 쓸 때마다 그 기술 스택을 새로 공부해야 했다. 현재는 Kubernetes 가 사실상의 표준으로 자리잡았다.
쿠버네티스(Kubernetes)
- 컨테이너를 쉽고 빠르게 배포·확장하고 관리를 자동화해주는 오픈소스 플랫폼
- 1주일에 20억 개의 컨테이너를 생성하는 Google이 컨테이너 배포 시스템으로 쓰던 Borg 를 기반으로 만든 오픈소스
오픈소스 기여사: Google, Red Hat, Huawei, VMware, Microsoft, IBM, Intel 등 유명 기업이 모두 참여한다.
Kubernetes는 무한한 확장성을 제공하며, 리눅스 명령어를 직접 입력하지 않아도 된다. 리눅스를 잘 몰라도 Kubernetes만 알면 서버 관리가 가능해졌다.
사실상의 표준(de facto)이 되어 모든 회사가 공통적으로 쓰게 되었고, 도커도 Kubernetes 지원을 이후에 추가했다.
경쟁사 오케스트레이션 도구들도 껍데기만 다를 뿐 내부는 Kubernetes로 바뀌었다.
CNCF (Cloud Native Computing Foundation)
클라우드에 적합하게 개발하는 방법을 정의하는 재단.
이 모든 것들이 다 Kubernetes에서 돌아간다.
Docker vs Kubernetes 역할 정리
| 도구 | 역할 |
|---|---|
| Docker | 각 앱마다 필요한 환경을 컨테이너로 관리 |
| Kubernetes | 각 컨테이너의 배포를 중앙 관리 |
Kubernetes 안에서 Docker가 돌고 있고, 실제 배포 실행은 Docker가 담당한다.
배포 프로세스 개선 (2차 개선)
배포 프로세스 고민
| 질문 | 해결 방향 |
|---|---|
| 배포를 더 자주 할 수 있을까? | 더 작은 단위로 자주 배포하자 |
| 배포를 더 빠르게 할 수 있을까? | 소스 푸시 시 자동 배포 |
| 배포를 더 많이 할 수 있을까? | 테스트 서버를 늘리자 |
| 배포를 더 자유롭게 할 수 있을까? | 배포 권한을 확대하자 |
이전에는 git에 올리면 빌드와 배포가 하나로 이어졌는데,
Docker는 배포하면 무조건 빌드한다. Docker 이미지가 커밋마다 생성되므로, 필요할 때마다 이미 빌드된 이미지를 배포하면 된다.
2차 개선의 장점
- 모든 브랜치가 자동으로 빌드되어 Docker 이미지로 만들어짐 → 언제든 배포 가능한 이미지 대기 중
- 테스트·QA 시 원하는 서버를 사용하고 완료 후 종료, Jenkins에서 누가 몇 번 서버에서 어떤 브랜치를 테스트 중인지 확인 가능
- 진행 중인 테스트를 기다리지 않고 여러 테스트를 동시 진행 및 배포
- 테스트 서버 2대 → 5대로 확장
새로운 문제점
- 테스트 서버를 수동 관리해야 하는 불편함 (1번 서버: 로그인 테스트, 2번 서버: 결제 테스트…)
- 사용하지 않는 테스트 서버의 자원 낭비 (0~8시 종료)
- 테스트가 몰릴 경우 여전히 대기
- 배포 화면 입력 실수
- 테스트 완료 후 서버 회수 지연
- Jenkins는 괜찮았지만 획기적인 개선이 어려움
GitOps 도입
그래서 GitOps 를 도입했다. Git을 배포 설정의 단일 진실 공급원(source of truth)으로 사용하는 방식이다.
배포 시 이미지를 만들면 배포용 Git에도 푸시한다.
그러면 ArgoCD 가 읽어서 Kubernetes에 자동으로 배포해준다. 클라우드는 사용하고 싶은 만큼 사용 가능하기 때문에 거의 무제한으로 확장된다.
DevOps 역할
- 서비스 배포·지원·모니터링
- 배포 파이프라인 구성
- 더 자주, 더 빠른 릴리스
- Cloud (AWS, Google Cloud, Azure …) / Cloud Native
- 컨테이너 (Docker, Kubernetes …)
- 보안 (Network, IAM, Service Mesh …)
- 장애 대응
- IaC(Infrastructure as Code) — Terraform 등
- SRE — SLI, SLO 등
- 외부 서비스 — DataDog, NewRelic 등
덤 — 10주 실전압축 DevOps 스터디 (1회 이상 배포 경험 필)
