[k8s] Prometheus Operator vs 직접 설정: Kubernetes 모니터링 실전 비교 분석

목차

• 왜 이 비교가 중요한가: Kubernetes 모니터링에서 운영 비용이 갈립니다
• 쉽게 말해: Prometheus Operator vs 직접 설정의 핵심 차이
• 언제 어떤 방식을 고르면 좋은가
• Prometheus Operator가 잘 맞는 경우
• 직접 설정이 잘 맞는 경우
• 실전 구현 1: Prometheus Operator로 Kubernetes 모니터링 구성
• 실전 구현 2: Prometheus 직접 설정으로 구성하기
• Grafana 연동은 어떻게 보나
• ⚠️ 실제 겪었던 문제와 트러블슈팅
• 1. ServiceMonitor를 만들었는데 target이 안 잡힐 때
• 2. 직접 설정에서 scrape가 안 될 때
• 3. Grafana에 데이터가 안 보일 때
• 검증과 결과: 운영해보면 어떤 차이가 나나
• 자주 묻는 질문 정리
• Q1. 입문자는 어떤 방식부터 시작하는 게 좋을까요?
• Q2. 무조건 Operator가 정답인가요?
• Q3. Grafana까지 꼭 같이 써야 하나요?
• 정리: 지금 선택해야 한다면 저는 이렇게 갑니다

Prometheus Operator vs 직접 설정: Kubernetes 모니터링 실전 비교 분석

쿠버네티스 운영을 조금만 해보면 결국 만나게 되는 질문이 있습니다. Prometheus Operator vs 직접 설정, 대체 뭐가 더 낫냐는 거죠. 저도 처음엔 "Prometheus(프로메테우스, 시계열 메트릭 모니터링 시스템)면 그냥 띄우면 되는 거 아닌가?" 싶었는데, 실제로 홈랩과 운영 환경에서 둘 다 굴려보니 생각보다 차이가 꽤 크더라고요. 특히 Kubernetes 모니터링을 제대로 붙이려면 서비스 디스커버리(Service Discovery, 대상 자동 발견), 알림 규칙(Alerting Rules, 경고 조건), 그리고 Grafana 연동까지 자연스럽게 이어져야 하거든요.

이번 글에서는 제가 직접 삽질했던 경험을 바탕으로, Prometheus Operator 방식과 직접 설정 방식을 현실적으로 비교해보겠습니다. 단순히 "이게 더 최신이라 좋다" 같은 얘기는 빼고, 실제 운영 관점에서 어디가 편하고 어디서 귀찮아지는지 정리해볼게요.

Prometheus Operator와 직접 설정 방식이 쿠버네티스 클러스터 안에서 어떻게 다르게 배치되는지 보여주는 아키텍처 이미지입니다.

왜 이 비교가 중요한가: Kubernetes 모니터링에서 운영 비용이 갈립니다

모니터링은 처음 붙일 때보다 나중에 유지보수할 때 진가가 드러납니다. 초반에는 둘 다 잘 돌아가는 것처럼 보여요. 근데 클러스터가 커지고, 애플리케이션이 늘고, 팀원이 늘어나면 설정 방식의 차이가 운영 비용으로 바로 튀어나옵니다.

• 직접 설정은 구조를 깊게 이해하기 좋고, 제어권이 높습니다.
• Operator 방식은 선언형(Declarative, 원하는 상태를 정의하는 방식) 운영이 편하고 확장성이 좋습니다.
• 작은 홈랩에서는 직접 설정이 빠를 때도 있지만, 팀 단위 운영에서는 Operator가 훨씬 덜 피곤한 경우가 많습니다.

제가 처음 직접 설정으로 시작했을 때는 설정 파일 하나만 고치면 끝날 줄 알았거든요. 근데 대상 서비스가 늘어나고 scrape job이 많아지니까, 어느 순간 prometheus.yml이 점점 거대해졌습니다. 그때부터 "아 이건 사람이 계속 손으로 관리할 구조가 아니구나" 싶더라고요.

쉽게 말해: Prometheus Operator vs 직접 설정의 핵심 차이

쉽게 말해, Prometheus Operator는 Prometheus 자체를 쿠버네티스 리소스(Custom Resource, 사용자 정의 리소스)로 관리하게 해주는 방식입니다. 반대로 직접 설정은 Deployment, ConfigMap, ServiceAccount 같은 리소스를 직접 만들고, scrape 설정도 내가 직접 관리하는 방식입니다.

항목	Prometheus Operator	직접 설정
설정 관리	ServiceMonitor, PodMonitor, PrometheusRule 같은 CRD 기반	prometheus.yml 직접 수정
초기 진입 난이도	처음엔 다소 생소함	개념만 알면 바로 시작 가능
확장성	매우 좋음	대상이 많아질수록 불편
운영 자동화	높음	낮음
문제 추적	리소스 구조 이해 필요	설정 파일 기준으로 단순함
팀 협업	표준화하기 좋음	작성자 의존도가 높아짐

여기서 중요한 포인트! 둘 중 하나가 절대적으로 우월하다기보다는, 클러스터 규모와 운영 방식에 따라 유리한 선택이 달라집니다. 저도 작은 테스트 클러스터에서는 직접 설정을 아직도 씁니다. 빠르게 확인하기 좋거든요.

언제 어떤 방식을 고르면 좋은가

Prometheus Operator가 잘 맞는 경우

• 여러 네임스페이스(namespace, 논리적 격리 단위)의 워크로드를 지속적으로 모니터링해야 할 때
• 팀원이 늘어나서 모니터링 리소스를 표준화해야 할 때
• Alertmanager(알림 관리자), Grafana, rules 관리를 함께 묶고 싶을 때
• Helm(헬름, 쿠버네티스 패키지 매니저) 기반 운영에 익숙할 때

직접 설정이 잘 맞는 경우

• 학습 목적이나 홈랩처럼 단순한 구조일 때
• Prometheus 내부 설정을 세밀하게 직접 다루고 싶을 때
• CRD를 추가하고 싶지 않을 때
• 문제 발생 시 설정 파일 한 장으로 빠르게 디버깅하고 싶을 때

사실 처음 배울 때는 직접 설정이 개념 잡기 좋습니다. Prometheus가 어떻게 scrape하고, 어떤 target을 찾고, 어떤 식으로 저장하는지 몸으로 익히게 되거든요. 반대로 운영 단계에서는 Operator가 진짜 편해집니다. 이거 써보면 "아, 사람이 yaml 몇 천 줄 들고 싸우면 안 되는구나" 싶습니다 ㅎㅎ

실전 구현 1: Prometheus Operator로 Kubernetes 모니터링 구성

제가 보통 가장 무난하게 시작하는 방식은 kube-prometheus-stack 차트를 쓰는 겁니다. Prometheus, Alertmanager, Grafana를 한 번에 올리기 좋고, 커뮤니티에서 널리 쓰는 편이라 자료도 많습니다.

1. 모니터링 전용 네임스페이스를 생성합니다.
2. Helm 저장소를 추가합니다.
3. 차트를 설치합니다.
4. ServiceMonitor로 수집 대상을 선언합니다.

kubectl create namespace monitoring
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
helm install monitoring prometheus-community/kube-prometheus-stack -n monitoring

설치가 끝나면 Prometheus와 Grafana가 함께 배포됩니다. 여기까지는 꽤 부드럽게 갑니다. 진짜 체감 포인트는 그 다음부터예요. 애플리케이션 하나 추가할 때마다 prometheus.yml을 직접 안 만지고, ServiceMonitor만 선언하면 되거든요.

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: sample-app
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app: sample-app
  namespaceSelector:
    matchNames:
      - app-space
  endpoints:
    - port: metrics
      path: /metrics
      interval: 30s

이 방식의 장점은 명확합니다. 애플리케이션 쪽 Service에 라벨만 잘 붙어 있으면, 모니터링 설정이 애플리케이션 배포 흐름에 자연스럽게 붙습니다. GitOps(Git옵스, Git 기반 선언형 운영) 하시는 분들이 Operator를 좋아하는 이유가 여기 있습니다.

ServiceMonitor가 서비스 라벨을 기준으로 메트릭 수집 대상을 찾아가는 흐름을 보여주는 구성 다이어그램입니다.

실전 구현 2: Prometheus 직접 설정으로 구성하기

이번엔 직접 설정입니다. 이 방식은 Prometheus가 어떻게 동작하는지 이해하기엔 정말 좋습니다. 저도 처음 구조를 배울 때는 이 방법으로 오래 굴렸습니다. 다만 규모가 커지면 금방 손이 많이 가더라고요.

1. Prometheus 설정을 담을 ConfigMap을 만듭니다.
2. RBAC(Role-Based Access Control, 역할 기반 권한 제어)를 설정합니다.
3. Deployment와 Service를 배포합니다.
4. targets 페이지에서 수집 상태를 확인합니다.

apiVersion: v1
kind: ConfigMap
metadata:
  name: prometheus-config
  namespace: monitoring
data:
  prometheus.yml: |
    global:
      scrape_interval: 30s
    scrape_configs:
      - job_name: 'kubernetes-pods'
        kubernetes_sd_configs:
          - role: pod
        relabel_configs:
          - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
            action: keep
            regex: true
          - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path]
            action: replace
            target_label: __metrics_path__
            regex: (.+)
          - source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port]
            action: replace
            regex: ([^:]+)(?::\d+)?;(\d+)
            replacement: $1:$2
            target_label: __address__

apiVersion: apps/v1
kind: Deployment
metadata:
  name: prometheus
  namespace: monitoring
spec:
  replicas: 1
  selector:
    matchLabels:
      app: prometheus
  template:
    metadata:
      labels:
        app: prometheus
    spec:
      serviceAccountName: prometheus
      containers:
        - name: prometheus
          image: prom/prometheus
          args:
            - --config.file=/etc/prometheus/prometheus.yml
          ports:
            - containerPort: 9090
          volumeMounts:
            - name: config
              mountPath: /etc/prometheus
      volumes:
        - name: config
          configMap:
            name: prometheus-config

직접 설정의 핵심은 relabel_configs를 이해하는 겁니다. 이 부분이 처음엔 진짜 벽처럼 느껴집니다. 저도 여기서 꽤 오래 멈췄었어요. 왜 target이 안 잡히는지 몰라서 annotation(어노테이션, 메타데이터) 오타 하나 찾겠다고 한참 봤던 기억이 납니다.

대신 이 방식은 구조가 명확합니다. 어떤 설정이 왜 들어갔는지 한 줄씩 따라갈 수 있어요. 학습용으로는 정말 좋습니다.

Grafana 연동은 어떻게 보나

Grafana 연동은 두 방식 모두 어렵지 않습니다. 차이는 연결보다도 대시보드와 데이터소스(Data Source, 데이터 공급원) 관리 방식에서 납니다. Operator 스택을 쓰면 Grafana가 함께 올라오는 경우가 많아서 시작이 빠릅니다. 직접 설정은 Prometheus만 먼저 올리고 Grafana를 따로 배포하는 흐름이 일반적입니다.

kubectl port-forward svc/monitoring-grafana -n monitoring 3000:80
kubectl port-forward svc/prometheus -n monitoring 9090:9090

Grafana에서 Prometheus URL을 연결한 뒤, Kubernetes 관련 대시보드를 붙이면 CPU, 메모리, Pod 재시작 수, 노드 상태 등을 한눈에 볼 수 있습니다. 드디어 됐다! 하는 순간이 여기서 오죠. 숫자가 그래프로 보이기 시작하면, 그전까지는 안 보이던 병목이 갑자기 눈에 들어옵니다.

⚠️ 실제 겪었던 문제와 트러블슈팅

여기서부터가 진짜 운영입니다. 설치보다 문제 해결이 더 중요하거든요.

1. ServiceMonitor를 만들었는데 target이 안 잡힐 때

• Service 라벨과 ServiceMonitor selector가 일치하는지 확인합니다.
• metrics 포트 이름이 ServiceMonitor의 endpoints.port와 같은지 봅니다.
• namespaceSelector가 실제 애플리케이션 네임스페이스를 포함하는지 체크합니다.

이건 제가 꽤 자주 겪었습니다. 특히 포트 번호가 아니라 포트 이름으로 매칭한다는 걸 놓치면 한참 헤매게 됩니다.

2. 직접 설정에서 scrape가 안 될 때

• Pod annotation 키가 정확한지 봅니다.
• RBAC 권한이 충분한지 확인합니다.
• Prometheus UI의 Status > Targets에서 에러 메시지를 먼저 봅니다.

처음엔 Prometheus 로그부터 뒤졌는데, 실제로는 Targets 화면이 더 빠르더라고요. 여기서 중요한 포인트! 모니터링 장애는 대개 설정 오타나 권한 누락에서 시작합니다.

3. Grafana에 데이터가 안 보일 때

• Prometheus 데이터소스 URL이 맞는지 확인합니다.
• Prometheus 쿼리(PromQL, 프로메테우스 질의 언어)에서 메트릭이 실제로 조회되는지 먼저 봅니다.
• 시간 범위(Time Range)가 너무 짧지 않은지 확인합니다.

이건 별거 아닌데 은근 자주 나옵니다. 수집은 되고 있는데, 대시보드 시간 범위가 안 맞아서 "왜 빈 화면이지?" 하고 멍해지는 경우가 있거든요. 저도 몇 번 당했습니다 ㅎㅎ

검증과 결과: 운영해보면 어떤 차이가 나나

결론부터 말하면, Prometheus Operator vs 직접 설정은 단순한 기능 비교가 아니라 운영 방식의 선택에 가깝습니다.

관점	Operator	직접 설정
빠른 시작	Helm 기반으로 빠름	구성요소를 이해하면 빠름
변경 관리	리소스 단위로 분리되어 편함	중앙 설정 파일이 비대해지기 쉬움
문제 분석	CRD 구조 이해가 필요	설정 파일 기준으로 직관적
확장 운영	유리함	점점 수동 작업 증가
학습 가치	운영 패턴 학습에 좋음	Prometheus 내부 구조 학습에 좋음

제가 실제로 써보니까, 작은 테스트 환경에서는 직접 설정이 부담이 적었습니다. 반면 운영 서비스가 두세 개를 넘어가고, 여러 네임스페이스에 exporter(exporter, 메트릭 노출 구성요소)가 붙기 시작하면 Operator 쪽이 확실히 편해집니다. 특히 팀원이 함께 건드리는 순간부터 차이가 커져요.

Grafana 대시보드와 Prometheus 타깃 상태 화면을 함께 보여주는 결과 검증 이미지입니다.

자주 묻는 질문 정리

Q1. 입문자는 어떤 방식부터 시작하는 게 좋을까요?

제가 추천하는 순서는 이렇습니다. 먼저 직접 설정으로 구조를 이해하고, 운영에는 Operator를 쓰는 방식입니다. 둘 중 하나만 알면 나중에 막힐 때 원인 파악이 어렵더라고요.

Q2. 무조건 Operator가 정답인가요?

그건 아닙니다. 싱글 클러스터 홈랩이나 짧은 실험 환경에서는 직접 설정이 더 가볍고 빠를 수 있습니다. 특히 CRD 추가를 최소화하고 싶다면 여전히 좋은 선택입니다.

Q3. Grafana까지 꼭 같이 써야 하나요?

필수는 아니지만, 실전에서는 거의 같이 갑니다. Prometheus가 수집과 저장을 담당하고, Grafana가 시각화를 담당하니까 역할이 깔끔하게 나뉘거든요.

정리: 지금 선택해야 한다면 저는 이렇게 갑니다

Kubernetes 모니터링을 장기적으로 운영할 계획이라면 저는 대체로 Operator를 권합니다. 선언형 리소스로 관리되고, 팀 협업에도 잘 맞고, 알림 규칙과 확장도 편하거든요. 반대로 학습 목적이 강하거나, 작은 홈랩에서 구조를 이해하고 싶다면 직접 설정으로 한 번 부딪혀보는 것도 아주 좋습니다. 저도 그렇게 배우면서 삽질 좀 했습니다. 근데 그 삽질 덕분에 지금은 문제가 생겨도 어디를 먼저 봐야 하는지 감이 오더라고요.

혹시 지금 Prometheus Operator vs 직접 설정 사이에서 고민 중이시라면, 질문을 이렇게 바꿔보시면 결정이 쉬워집니다. "내가 지금 배우고 싶은가, 아니면 오래 운영하고 싶은가?" 이거거든요. 답이 전자면 직접 설정, 후자면 Operator 쪽이 보통 맞습니다.

두 방식의 장단점과 추천 사용 시나리오를 한눈에 요약한 인포그래픽 이미지입니다.

다음 글에서는 Alertmanager(알림 관리자)와 Slack 같은 채널 연동, 그리고 PromQL 기초 쿼리를 다뤄볼 예정입니다. 이전 글에서 exporter 구성 방법을 보셨다면 이번 내용이 더 잘 이어질 거예요. ✅

📚 함께 읽으면 좋은 글

• Kubernetes PodSecurity 도입 전후 비교: 보안 강화 사례 연구
• Karpenter 오토스케일러 1년 사용 후기: 비용 절감과 성능 최적화 회고
• StatefulSet vs Deployment: 상태 저장 애플리케이션 배포 비교
• Grafana Cloud 비용 분석, 자체 Prometheus로 돌아간 이유