로그는 시스템의 ‘블랙박스’다. 장애가 터졌을 때 로그 파이프라인이 제대로 갖춰져 있지 않으면, 원인 분석에 몇 시간이 아니라 며칠이 걸리기도 한다. 로그 수집 스택을 선택할 때 가장 많이 맞붙는 조합이 ELK(Elasticsearch + Logstash + Kibana)와 Loki + Promtail + Grafana다. 둘 다 프로덕션에서 검증된 오픈소스이지만, 설계 철학과 운영 비용이 전혀 다르다. 이 글에서는 두 스택을 실무 관점에서 비교하고, 어떤 상황에 무엇을 선택해야 하는지 기준을 정리한다.

ELK 스택의 구조와 특징

ELK는 Elasticsearch(저장·검색), Logstash(수집·변환), Kibana(시각화)의 세 컴포넌트로 구성된다. 최근에는 Logstash 대신 경량 수집기인 Filebeat/Fluentd를 쓰는 경우가 많아 ‘Elastic Stack’이라고도 부른다.

핵심 특징은 전문 인덱싱(full-text indexing)이다. 로그를 수집하는 시점에 필드별로 역인덱스를 생성한다. 덕분에 임의의 키워드로 밀리초 단위 검색이 가능하지만, 그 대가로 디스크와 CPU를 많이 소모한다. 일반적으로 원본 로그 대비 1.5~3배의 디스크 공간이 인덱스로 사용된다.

# Filebeat로 Nginx 로그 수집 예시 (filebeat.yml)
filebeat.inputs:
  - type: log
    enabled: true
    paths:
      - /var/log/nginx/access.log
    fields:
      service: nginx
      env: production

output.elasticsearch:
  hosts: ["https://es-node:9200"]
  index: "nginx-logs-%{+yyyy.MM.dd}"
  username: "${ES_USER}"
  password: "${ES_PASS}"

Logstash를 거칠 경우 Grok 패턴으로 비정형 로그를 구조화할 수 있다. 예를 들어 Nginx 액세스 로그를 %{COMBINEDAPACHELOG} 패턴으로 파싱하면, clientip·verb·response 등의 필드가 자동 추출된다. 이 정도의 전처리 능력은 Loki만으로는 쉽게 흉내내기 어렵다.

Loki + Promtail + Grafana의 구조와 특징

Loki는 Grafana Labs가 만든 로그 집계 시스템으로, Prometheus의 설계 철학을 로그에 적용했다. 가장 큰 차이는 로그 내용을 인덱싱하지 않는다는 점이다. 대신 job, instance, namespace 같은 메타데이터 레이블만 인덱싱하고, 실제 로그 라인은 압축(Snappy/gzip)된 청크로 오브젝트 스토리지(S3, GCS, 로컬 파일시스템 등)에 저장한다.

검색 시에는 레이블로 대상 청크를 좁힌 뒤, 청크 내부에서 정규식이나 파이프라인 필터로 필터링한다. 인덱스 크기가 극단적으로 작아지기 때문에 스토리지 비용이 ELK 대비 1/5~1/10 수준으로 내려가는 경우가 많다.

# Promtail 설정 예시 (promtail-config.yaml)
server:
  http_listen_port: 9080

positions:
  filename: /tmp/positions.yaml

clients:
  - url: http://loki:3100/loki/api/v1/push

scrape_configs:
  - job_name: nginx
    static_configs:
      - targets:
          - localhost
        labels:
          job: nginx
          env: production
          __path__: /var/log/nginx/access.log
    pipeline_stages:
      - regex:
          expression: '(?Pd{3}) (?Pd+)'
      - labels:
          status:

쿼리 언어는 LogQL로, PromQL과 유사한 문법을 사용한다. 예를 들어 {job="nginx"} |= "500" | rate([5m])는 Nginx 로그에서 5xx 에러 발생률을 실시간으로 계산한다. Grafana와 통합하면 메트릭(Prometheus)과 로그(Loki)를 같은 대시보드에서 상관 분석할 수 있어 장애 대응 속도가 눈에 띄게 빨라진다.

ELK vs Loki 핵심 비교

항목 ELK (Elastic Stack) Loki + Promtail + Grafana
인덱싱 방식 전문 역인덱스 (모든 필드) 레이블 메타데이터만 인덱싱
검색 속도 임의 키워드 검색 빠름 레이블 필터 이후 정규식 스캔
스토리지 비용 높음 (원본 대비 1.5~3배) 낮음 (압축 + 오브젝트 스토리지)
운영 복잡도 높음 (JVM 튜닝, 샤드 관리) 낮음 (스테이트리스, 수평 확장 용이)
구조화 파싱 수집 시점 파싱 (Grok, ECS) 쿼리 시점 파싱 (LogQL 파이프라인)
메트릭 연동 별도 설정 필요 Prometheus와 네이티브 통합
라이선스 SSPL (일부 기능 유료) AGPLv3 (오픈소스)
대표 적합 환경 비정형 로그 분석, 컴플라이언스 Kubernetes/클라우드 네이티브

비용과 운영 부담의 현실

ELK의 가장 큰 진입 장벽은 Elasticsearch 클러스터 운영이다. 노드당 최소 8GB RAM을 권장하고, JVM 힙 설정과 샤드 수 최적화가 잘못되면 GC 지옥에 빠진다. 일 수십 GB 이상의 로그를 처리하려면 핫-웜-콜드 티어를 구성해야 하고, ILM(Index Lifecycle Management) 정책도 꼼꼼히 세워야 한다. 관리형 서비스인 Elastic Cloud나 AWS OpenSearch를 쓰면 운영 부담이 줄지만, 비용이 크게 늘어난다.

Loki는 상대적으로 가볍다. 단일 바이너리 모드로 소규모 환경에서 시작해, 마이크로서비스 모드로 컴포넌트별 수평 확장이 가능하다. 스토리지를 S3에 위임하면 클러스터 자체는 스테이트리스해져 운영 난이도가 뚝 떨어진다. 다만 카디널리티가 높은 레이블(예: 사용자 ID, 요청 UUID를 레이블로 쓰는 경우)을 사용하면 Loki의 인덱스가 폭발적으로 증가하는 안티패턴이 있으므로 주의해야 한다.

실전 선택 기준과 팁

다음 질문에 답해 보면 선택이 쉬워진다.

  • 이미 Prometheus + Grafana를 쓰고 있는가? → Loki가 자연스러운 확장이다. 동일 Grafana 인스턴스에서 로그-메트릭-트레이스를 통합 관리할 수 있다(Grafana Tempo까지 더하면 완전한 관측성 삼각형).
  • 비정형 로그 분석, 감사 로그 장기 보관, 규제 컴플라이언스가 필요한가? → ELK가 적합하다. Elasticsearch의 풍부한 쿼리 DSL과 Kibana의 Lens/Maps 기능은 Grafana가 따라오기 어렵다.
  • Kubernetes 환경인가? → Loki + Promtail (또는 Alloy)이 DaemonSet으로 배포하기 편하고, 파드 레이블을 자동으로 Loki 레이블로 매핑해 준다.
  • 팀에 JVM/Elasticsearch 전문가가 없는가? → Loki가 초기 진입 장벽이 훨씬 낮다.

둘을 혼용하는 사례도 있다. 애플리케이션 런타임 로그는 Loki로 빠르게 수집하고, 보안·감사 로그만 ELK로 별도 적재해 장기 보관하는 패턴이다. 운영 부담과 비용 효율 사이의 타협점을 찾는 방식이다.

레이블 설계 팁: Loki에서는 레이블을 env, service, namespace, pod 수준으로 최소화하는 것이 기본 원칙이다. 레이블 종류가 10개를 넘어가면 인덱스 크기와 쿼리 지연이 동시에 늘어난다.

마무리

ELK와 Loki는 같은 문제를 서로 다른 철학으로 푼다. ELK는 ‘수집 시점에 모든 것을 인덱싱해 빠른 검색을 제공’하고, Loki는 ‘저장 비용을 최소화하고 쿼리 시점에 파싱’한다. 어느 쪽이 낫다고 단정 지을 수 없고, 팀의 기술 스택, 로그 볼륨, 예산, 운영 인력에 따라 최적해가 달라진다. 핵심은 로그 파이프라인 없이 운영하는 것이 가장 위험하다는 점이다. 작게 시작하더라도 반드시 구축하자.

자주 묻는 질문

Q. Loki에서 특정 에러 메시지를 전체 텍스트 검색할 수 있나요?
A. 가능합니다. LogQL의 라인 필터(|= "error message") 또는 정규식 필터(|~ "timeout|refused")로 텍스트 검색이 됩니다. 단, Elasticsearch처럼 역인덱스를 사용하지 않기 때문에 레이블로 대상 청크를 먼저 좁혀야 성능이 나옵니다. 레이블 없이 전체 로그 풀스캔은 매우 느립니다.

Q. ELK를 소규모 팀이 운영할 수 있는 최소 사양은 어느 정도인가요?
A. 일 로그 5GB 이하라면 노드 1~3대, 각 8GB RAM, 4코어로 시작할 수 있습니다. 단일 노드 개발 환경은 4GB RAM으로도 가능하지만, 프로덕션에서는 반드시 복제본 1개 이상을 확보해야 데이터 유실을 막을 수 있습니다. ILM로 30일 이후 데이터를 자동 삭제하거나 스냅샷으로 아카이빙하는 정책을 처음부터 설계해 두세요.

Q. Grafana Loki와 Grafana Cloud Logs는 어떻게 다른가요?
A. Grafana Loki는 자체 호스팅하는 오픈소스 소프트웨어이고, Grafana Cloud Logs는 Grafana Labs가 Loki를 기반으로 제공하는 완전 관리형 SaaS입니다. 소규모 사용량은 무료 티어로 시작할 수 있으며, 운영 인프라 없이 바로 사용할 수 있다는 장점이 있습니다. 데이터 주권 또는 컴플라이언스 요건이 있다면 자체 호스팅 Loki를 선택하세요.