ELK 대안 선택: 로그 플랫폼에서 무엇을 바꿀 것인가
ELK, Elastic Observability, Loki, 클라우드 로그와 Guance를 인덱싱, 보존, 운영 책임과 되돌릴 수 있는 이전으로 비교합니다.
장애가 나서 오류 로그를 찾았는데도 요청 경로, 사용자 영향, 최근 배포를 확인하려면 여러 시스템을 더 열어야 합니다. 한편 플랫폼 팀은 샤드, mapping 충돌, 인덱스 수명 주기와 클러스터 업그레이드를 관리하느라 바쁩니다. 이런 상황이라면 ELK 대안을 검토할 이유가 분명합니다.
이 글의 비교 출발점은 Elasticsearch, Logstash, Kibana 중심의 자체 운영 로그 시스템입니다. APM, 인프라, RUM 등을 제공하는 Elastic Observability 전체를 단순한 로그 검색 제품으로 취급하지 않습니다. 발행자인 Guance 역시 후보 중 하나입니다. 공식 자료와 운영상 선택 기준을 정리했으며, 운영 규모의 성능 비교 실험은 수행하지 않았습니다.
먼저 바꿔야 할 계층을 정하기
| 경로 | 유지할 수 있는 자산 | 다시 검토할 일 |
|---|---|---|
| ELK / EFK 유지 | 쿼리, 필드 모델, Elasticsearch 경험 | 샤드, 용량, 수명 주기, 업그레이드, 백업과 복구 |
| Elastic Observability | Elastic 쿼리와 운영 방식 | 에디션, 배포 모델, APM 연동, 보존 기간, 과금 범위 |
| Loki + Grafana | Grafana 사용 경험, 서비스·클러스터별 로그 탐색 | 라벨, LogQL, 장기간 스캔, 연결할 데이터 소스 |
| SLS / CLS / LTS | 클라우드 리소스 로그와 기존 구매 경로 | 외부 수집, 클라우드 간 네트워크 비용, 식별자 매핑, 쿼리 |
| ClickHouse 기반 자체 개발 | SQL 분석과 데이터 엔지니어링 역량 | 수집, 스키마, 테넌트 분리, 권한, 알림, 조사 화면 |
| Guance | 지원되는 수집기와 서비스 식별자 | 필드 매핑, 로그·트레이스 연계, 권한, 비용, 이전 검증 |
주된 부담이 Elasticsearch 관리라면 관리형 서비스만으로도 해결될 수 있습니다. 쿼리 모델이 로그 사용 방식에 맞지 않는다면 저장·인덱싱 방식을 비교합니다. 여러 도구 사이에서 조사가 끊긴다면 검색창보다 전체 조사 과정을 평가해야 합니다.
인덱싱 방식은 비용과 검색 습관을 함께 바꾼다
Elasticsearch의 샤드 수, 복제본, mapping과 수명 주기 정책은 수집량과 쿼리 부하에 따라 조정해야 합니다. 필드 충돌은 수집이나 분석을 방해하고, 인덱스와 샤드가 늘면 관리할 항목도 늘어납니다. 쓰기 피크와 과거 로그 검색이 자원을 두고 경쟁할 때 서버 증설만으로 문제가 해결되지는 않을 수 있습니다. 실제 사용하는 쿼리를 가져와 최근 15분과 긴 과거 구간을 각각 시험하세요.
Loki는 주로 로그 스트림을 식별하는 라벨을 인덱싱합니다. 각 로그 본문 전체에 전통적인 전문 역색인을 만드는 방식은 아닙니다. 그렇다고 본문 검색을 못 하는 것은 아닙니다. LogQL로 로그 행을 필터링하고 파싱할 수 있습니다. 먼저 라벨로 스트림을 좁힌 다음 해당 로그를 처리한다는 차이가 있습니다. 서비스, 환경, 클러스터처럼 안정적인 라벨은 유용하지만 요청 ID를 매번 스트림 라벨로 만들면 높은 카디널리티가 생깁니다. 비용 절감 여부는 실제 스트림 수, 스캔 범위와 동시 쿼리로 확인해야 합니다.
ClickHouse는 로그 분석의 저장·쿼리 기반이 될 수 있습니다. 하지만 데이터베이스 하나가 완성된 로그 제품은 아닙니다. 수집과 파싱, 테넌트 분리, 접근 제어, 알림, 인터페이스, 업그레이드와 복구까지 계산해야 합니다. 같은 워크로드에서 시험하지 않고 데이터베이스 이름만으로 더 빠르거나 저렴하다고 단정할 수 없습니다.
로그를 모아도 조사 맥락은 저절로 연결되지 않는다
장애 조사에는 어느 서비스가 먼저 이상해졌는지, 느린 요청이 어떤 의존성에서 기다렸는지, 어떤 사용자가 영향을 받았는지, 배포·설정 변경·Pod 재시작이 함께 있었는지를 확인하는 과정이 필요합니다. 로그가 많다는 사실만으로 답을 얻지는 못합니다. 서비스명, 환경, 타임스탬프와 trace ID를 일관되게 관리하는 일이 대시보드 하나를 더 만드는 것보다 중요할 때도 있습니다.
Alibaba Cloud SLS와 Tencent Cloud CLS는 다른 클라우드와 데이터센터의 로그도 수집할 수 있습니다. 클라우드 사업자의 제품이라는 이유로 자체 클라우드만 볼 수 있다고 판단해서는 안 됩니다. 실제 수집 경로, 외부 전송 비용, 필드 매핑, 구매하고 구성한 제품에서 로그를 트레이스·사용자 경험과 연결할 수 있는지 확인하세요. 멀티클라우드라면 알림에서 로그, 트레이스, 영향 범위까지 한 번 직접 따라가 보는 편이 좋습니다.
이전 목록보다 보존 정책을 먼저 정하기
모든 로그의 보존 기간을 줄이면 당장 청구액이 줄 수 있지만 다음 장애나 감사에 필요한 증거도 잃을 수 있습니다. 거래, 오류, 감사, 디버그 로그를 나눠 수집 범위, 검색 가능 시점, 보존 기간과 삭제 요구사항을 정합니다. 그런 다음 수집 단계에서 제외할 필드, 즉시 검색할 데이터, 보관소에 둘 데이터를 선택합니다.
비교할 때는 같은 기간, 수집 바이트와 이벤트 수, 보존 기간, 쿼리 동시성과 복구 요구사항을 사용합니다. 인덱스나 스캔 요금, 보관 데이터 복원, 네트워크 전송, 지원, 병행 운영 비용도 포함해야 합니다. 사업 단위로 사용량을 나누면 데이터를 만드는 팀도 관리에 참여할 수 있습니다. 로그와 트레이스를 연결하면 조사 범위를 줄이는 데 도움이 되지만 이미 수집한 데이터의 요금이 자동으로 낮아지지는 않습니다.
Guance도 같은 조사 과정에서 평가하기
로그를 지표, 트레이스, RUM, Kubernetes, 이벤트와 함께 보려는 경우 Guance 로그 문서를 참고해 과거 장애가 있는 서비스 하나로 시작합니다. 필드, 서비스 식별자, 시간과 trace ID를 확인한 다음 화면 전환이 줄었는지 평가합니다. 수집 성공만으로 과거 인덱스, 쿼리 문법, 대시보드나 알림이 자동 이전된다고 볼 수는 없습니다.
AI를 평가할 때는 Agent 애플리케이션을 모니터링하는 일과 Obsy Agent Teams에 조사 작업을 맡기는 일을 구분합니다. 작업 문서는 산출물과 승인 요청을 설명합니다. 호출할 수 있는 도구, 접근 데이터, 허용 동작은 설정에 따라 달라집니다. 읽기 전용 조사부터 시작해 인용한 로그, 시간 범위와 가설을 엔지니어가 확인하세요. 제안이 곧 확정된 근본 원인은 아니며, 작업을 중지해도 이미 수행한 외부 변경이 되돌아가지는 않습니다.
서비스 하나로 이전 범위 검증하기
기존 ELK는 유지합니다. 통제된 환경에서 대표 서비스의 주요 로그를 후보 시스템에도 보내고 필요한 지표와 트레이스를 추가합니다. 수집기가 의도한 병행 전송을 지원하는지, 큐·재시도·중복·마스킹·추가 요금은 어떤지 확인합니다. 전송 목적지 추가가 애플리케이션이나 기존 파이프라인에 영향을 주지 않는다고 가정하지 마세요.
이어서 사용이 승인된 보존 데이터나 비식별화 자료로 과거 장애 세 유형을 검토합니다. 같은 오류를 찾는지, 요청과 사용자 영향으로 연결되는지, 기존 규칙과 새 규칙의 차이를 설명할 수 있는지 확인합니다. Agent Teams를 시험한다면 사용한 증거와 사람이 기각한 제안도 남깁니다. 한 번 그럴듯한 답을 얻은 것은 안정적인 성능의 증거가 아닙니다. 2주는 첫 검토 시점의 예시이지 이전 완료 기한이 아닙니다.
검토 이후 범위를 확대합니다. 핵심 거래와 오류, SLO에 영향을 주는 서비스 로그, 트레이스 연계가 필요한 로그부터 검증할 수 있습니다. 가치가 낮은 디버그 로그는 필터링, 짧은 보존, 보관소 이전을 별도로 결정합니다. 과거 인덱스를 유지하면서 새 시스템이 일부 조사를 맡을 수도 있습니다. 전환 전 중단 조건, 기존 수집 설정 복원 방법, 과거 데이터 접근 경로, 결과 승인 책임자를 정합니다.
검색과 운영 방식이 여전히 적합하면 기존 ELK를 개선합니다. Elastic을 유지하면서 신호를 넓히려면 Elastic Observability, Grafana와 라벨 중심 탐색이 맞으면 Loki를 검토합니다. 여러 시스템에 흩어진 증거를 모으는 것이 문제라면 Guance를 포함한 플랫폼을 같은 서비스에서 비교합니다. 실제 조사 경로, 데이터 요구사항과 총비용이 선택 기준입니다.
참고 자료
기술 자료 확인일: 2026년 10월 27일. 이전 절차는 평가 제안이며 실행한 시험 기록이 아닙니다.
