로그 관리 도구 선택: 검색·보존과 운영 비용

현재 로그 플랫폼이 데이터를 안정적으로 받고 필요한 검색도 처리한다면, 저는 교체보다 쿼리와 보존 정책부터 정리하겠습니다. 과도한 인덱싱, 긴 기간의 스캔, 적체 데이터 복구, 플랫폼 팀이 계속 관리하는 백엔드가 비용의 원인일 수 있습니다. GB 단가를 낮추는 것으로 해결되는 일은 그중 일부입니다.

기업 로그 관리 도구는 엔지니어가 매일 하는 작업을 따라가며 비교하는 편이 좋습니다. 요청 ID로 한 건을 찾고, 처음 보는 오류 문구를 검색하고, 서비스와 배포 버전별 실패를 집계하는 쿼리는 서로 다른 데이터 경로를 사용합니다. 수집량이 급증하고 여러 사람이 동시에 조사할 때도 필요한 검색을 끝낼 수 있는지, 팀이 그 운영 부담을 감당할 수 있는지가 선택을 가릅니다.

전담 로그 플랫폼 운영자가 없고 검색·알림·애플리케이션 조사를 빨리 제공해야 한다면 Guance 같은 관리형 플랫폼을 먼저 고려하겠습니다. Elastic이나 Loki 운영이 이미 성숙했고 쿼리도 현재 구조에 잘 맞는 팀이라면 기존 환경을 개선할 가치가 있습니다. 수집, 검색, 보존과 지속 운영을 살펴보면 이 판단을 구체화할 수 있습니다.

Guance 편집팀 · 2026년 10월 28일. 공식 문서에 근거한 비교이며 발행자인 Guance도 논의 대상입니다. 용량 예시는 명시한 가정으로 계산했고 동일 부하 성능 시험은 수행하지 않았습니다.

엔지니어가 실제로 실행할 쿼리부터 보기

기능 목록의 ‘검색 지원’만으로는 쿼리 처리 방식의 차이를 알기 어렵습니다.

Elasticsearch의 역색인은 검색 중심 작업에 적합하지만 필드를 어떻게 분석할지는 매핑에 달려 있습니다. message의 토큰 검색과 keyword 필드의 정확한 일치는 다릅니다. 이를 바꾸면 이전 후 결과도 달라질 수 있습니다. 기존 클러스터에 용량 문제가 있다면 동적 필드, 샤드, 복제본과 수명 주기 정책부터 확인할 수 있습니다. Elasticsearch 매핑

채택할 배포판과 기능의 라이선스도 확인해야 합니다. Elastic은 대상 무료 소스 코드에 AGPLv3 선택지를 추가했지만 모든 바이너리 배포판과 상용 기능의 조건이 같아진 것은 아닙니다. Elastic 라이선스

Loki는 라벨로 로그 스트림을 찾고 본문을 chunk에 저장합니다. 서비스, 환경, 클러스터처럼 안정적인 라벨로 먼저 범위를 좁히는 구조입니다. 요청 ID나 사용자 ID를 스트림 라벨로 쓰면 값이 바뀔 때마다 스트림이 늘어납니다. 이런 속성은 구조화 메타데이터에 보관할 수 있습니다. 본문 필터링도 가능하지만 전체 서비스를 대상으로 긴 과거 구간을 검색하는 작업은 알려진 서비스의 요청 조회보다 훨씬 많은 데이터를 스캔할 수 있습니다. Loki 구조화 메타데이터

가속 기능의 범위도 구분해야 합니다. 현재 Bloom 쿼리 가속은 조건에 맞는 구조화 메타데이터 필터를 대상으로 합니다. Loki와 GEL에서는 실험 기능이고 Grafana Cloud는 조건을 충족하는 고객을 위한 공개 미리 보기입니다. 모든 LogQL 표현식이 빨라진다는 전제로 계산할 수는 없습니다. 쿼리 가속

ClickHouse는 컬럼형 읽기와 집계에 더해 26.2부터 text index를 정식 제공합니다. 집계만 가능하고 전문 검색은 못 한다는 설명은 더 이상 맞지 않습니다. 쿼리가 텍스트 인덱스를 쓰는지는 토큰화, 인덱스 정의와 표현식에 따라 달라집니다. 버전, 테이블 구조와 검색 의미를 정한 뒤 과거 데이터의 첫 쿼리와 반복 쿼리를 비교해야 결과를 설명할 수 있습니다. ClickHouse 텍스트 인덱스

이 구조만으로 공통 성능 순위가 정해지지는 않습니다. 모두 로그 서비스의 기반이 될 수 있지만 필요한 쿼리에 따라 인덱스, 컴퓨팅과 유지보수가 달라집니다.

처리 위치가 데이터 경로를 바꾼다

수집 단계에서 필터링하는 것과 백엔드에서 버리는 것은 청구서와 데이터 경계에 서로 다른 영향을 줍니다. 업로드 전에 불필요한 로그를 제거하면 이후 전송과 수집을 줄일 수 있습니다. 원본 저장소에 쓴 뒤 필터링해도 이미 발생한 수집과 저장은 되돌릴 수 없습니다.

Guance의 로컬 Pipeline은 DataKit의 수집 시점에, 중앙 Pipeline은 중앙으로 업로드한 뒤 실행됩니다. 시각 파싱, 타입 변환, 마스킹과 필터는 이 위치에 맞춰 설정합니다. 민감 필드가 원래 환경을 떠나기 전에 처리되어야 한다면 해당 입력을 포함하는 로컬 경로가 필요합니다. 원본 파일, 버퍼와 잘못된 입력도 함께 다뤄야 합니다. 중앙 처리는 공통 변환에 유용하지만 이미 전송한 원문을 회수하지는 못합니다. Pipeline 실행 위치

SLS 데이터 변환 작업은 원본 Logstore를 소비하고 처리 결과를 대상 Logstore에 씁니다. 현재 새 버전 문서도 작업 안에서 필터링해도 원본 Logstore의 과금 대상 수집량은 줄지 않는다고 설명합니다. 이를 줄이려면 앞선 수집 단계의 필터를 사용합니다. Guance와 비교할 때도 처리 위치, 통과하는 입력, 실패한 기록의 목적지를 추적하면 차이를 이해할 수 있습니다. SLS 데이터 변환

필드 정리는 조사 결과에도 영향을 줍니다. 지연 시간이 문자열이면 문자열 정렬을 숫자 비교 대신 사용할 수 없습니다. 이벤트 시각을 제대로 파싱하지 않으면 늦게 재전송된 로그가 다른 시간대에 나타날 수 있습니다. 정상 입력, 필드 누락, 여러 줄, 잘못된 시각을 포함한 소수의 예제를 남기면 형식 변경의 영향을 이해하기 쉽습니다. 관리형 서비스를 선택해도 애플리케이션의 이런 약속은 계속 유지해야 합니다.

접근 방식으로 보존 기간을 나눈 뒤 용량 계산하기

모든 로그를 같은 기간 보관하면 시작은 쉽습니다. 하지만 감사 기록, 일상 디버깅과 빈번한 오류 조사에 필요한 대화형 검색 이력이 같을 필요는 없습니다.

하루 200 GB의 원본 로그 중 80%는 3일, 20%는 30일 보관한다고 가정하겠습니다. 지속적으로 수집해 정상 상태에 도달한 뒤의 보존량은 다음과 같습니다.

전체를 30일 보관: 200 × 30 = 6,000 GB
필요한 기간으로 분리: 200 × (80% × 3 + 20% × 30) = 1,680 GB

원본 데이터 기준 보존량이며 압축, 인덱스, 복제본, 임시 공간과 아카이브 요금은 빠져 있습니다. 특정 플랫폼 견적도 아닙니다. 보존 요구를 정리한 뒤 백엔드를 비교하면 구매할 용량 자체가 바뀐다는 뜻입니다. 한 엔진이나 객체 저장소에서 측정한 압축률을 모든 공급자의 요금에 그대로 적용할 수는 없습니다.

Guance의 일반 로그 인덱스는 순서대로 조건을 비교해 처음 일치한 인덱스를 적용합니다. 보존과 접근 요구에 따른 분리에 사용할 수 있습니다. 현재 일반 인덱스는 default를 포함해 최대 6개이고 추가 생성은 활성화 신청이 필요합니다. 애플리케이션마다 인덱스를 만드는 대신 소스, 서비스와 환경은 필드로 남기는 편이 적합합니다. 로그 인덱스

장기 보존은 접근 방식도 정해야 합니다. Guance 표준 저장 기간에는 임의 시간 범위를 조회할 수 있지만 장기 저장의 단일 쿼리는 최대 24시간을 다룹니다. 가끔 하루치 감사 기록을 찾는 일과 매달 전체를 집계하는 일은 다른 요구입니다. 후자는 필요한 쿼리가 가능한 저장 방식으로 계산해야 합니다. 데이터 저장 정책

수집한 GB와 인덱스에 남긴 이벤트 수 구분하기

상용 SaaS와 클라우드 로그 서비스는 백엔드 운영을 줄여 주지만 같은 단위로 과금하지 않습니다. 수집, 인덱싱 이벤트, 스캔, 아카이브 복원, 처리와 전송이 별도 항목일 수 있습니다. Elastic Cloud Hosted와 Serverless도 구매 방식이 다르므로 도입할 서비스를 정한 뒤 가격표를 적용합니다. Elastic 가격

Datadog은 로그 수집과 인덱싱을 구분합니다. ‘하루 50 GB’만으로는 계산하기 어렵습니다. 각 이벤트가 1 KB(10³바이트)라면 약 5천만 건, 4 KB라면 약 1,250만 건입니다. 같은 바이트 양에서 이벤트 수가 네 배 차이 나고 인덱싱 비율과 보존 기간도 요금을 바꿉니다. 이 예제는 GB = 10⁹바이트, KB = 10³바이트이며 실제로는 이벤트 크기 분포를 사용해야 합니다. Datadog 로그 과금, 로그 사용량과 가격

Datadog Standard 인덱스의 이벤트를 줄여도 수집량은 되돌릴 수 없습니다. 제외한 기록을 나중에 찾을 수 있는지는 별도로 구성한 아카이브 등의 경로에 달려 있습니다. 복원 시간과 요금도 접근 요구에 맞춰야 합니다. 로그 인덱스와 필터

Flex는 컴퓨팅과 저장을 분리해 설정하는 다른 선택지이지만 현재 모니터 쿼리는 지원하지 않습니다. 이곳에 이력을 보관해도 Standard 로그 모니터의 동작이 그대로 유지되지는 않습니다. 인덱싱 비용과 함께 검색 가능한 기록, 계속 실행할 규칙을 고려해야 합니다. Flex Logs 범위

SLS, CloudWatch Logs, Azure Monitor Logs와 CLS도 전체 경로를 계산합니다. 한 클라우드에 작업이 모인 팀은 기존 신원 관리, 리소스 수집과 대응 절차를 활용해 연결 작업을 줄일 수 있습니다. 다른 클라우드나 온프레미스 소스도 지원될 수 있지만 네트워크, 자격 증명, 외부 전송과 계정 간 접근에는 추가 비용과 운영이 따릅니다.

로그를 찾은 뒤 조사까지 끝낼 수 있는가

로그 모니터링 도구는 저장과 검색뿐 아니라 탐지 결과를 온콜 대응으로 전달해야 합니다. 서비스·환경·상태별 규칙에는 안정적인 필드가 필요합니다. 평가 구간과 늦게 도착한 데이터의 관계는 알림 시점에 영향을 줍니다. 알림 수는 줄었어도 필요한 증거가 다른 시간대로 흩어져 있다면 작업이 끝난 것이 아닙니다.

Guance에서는 일관된 trace_id로 로그와 트레이스를 연결하고 관련 호스트, 컨테이너와 Pod로 조사를 이어갈 수 있습니다. 해당 신호가 이미 수집되고 식별자와 시각이 맞으며 대상 데이터가 보존 기간 안에 있어야 합니다. 기본 제공 탐색 경로는 자체 링크와 여러 권한 체계를 연결하는 작업을 줄입니다. 애플리케이션은 여전히 업무 맥락을 남겨야 합니다. 로그·트레이스 연계 · 트레이스 상세

Elastic, Loki나 ClickHouse로 같은 흐름을 만들 수도 있습니다. 수집, 쿼리 화면, 알림, 신원·권한, 업그레이드와 복구를 어떻게 서비스로 묶을지, 누가 유지할지까지 계산합니다. 플랫폼 팀이 성숙한 구성을 이미 운영한다면 추가 작업은 작을 수 있습니다. 업무 운영자가 새로 맡는다면 비용을 0으로 놓아서는 안 됩니다.

AI 지원은 증거 정리와 기록을 읽는 부담을 줄일 수 있지만 설명에는 원본 이벤트가 필요합니다. 보안 탐지도 공통 저장소만으로 완성되지 않습니다. 탐지 규칙, 위협 정보, 사건 처리와 대응 통합은 각자 범위가 있습니다. 외부 자동화 동작에는 권한, 실패 처리와 복구 수단이 필요합니다. 데이터를 재사용하더라도 제공해야 할 결과는 각각 정의해야 합니다.

이전할 가치는 중단할 수 있는 운영으로 판단하기

저는 먼저 현재 플랫폼에서 해결할 수 있는 문제를 해결하겠습니다. Elasticsearch 매핑과 수명 주기, Loki 라벨, 수집 측 필터와 보존 정책은 이전 전에 개선할 가치가 있습니다. 필요한 쿼리가 안정적으로 동작하고 월 요금 차이로 변경 작업을 회수할 수 없다면 현재 환경을 유지하는 것도 합리적입니다.

기반 구조를 직접 관리해야 하고 용량·업그레이드·복구를 지속해서 맡을 수 있는 팀에는 자체 운영의 가치가 있습니다. 데이터와 대응이 한 클라우드에 모여 있다면 기본 로그 서비스가 간단할 수 있습니다. 전담 백엔드 운영자 없이 로그·알림·신호 간 조사를 빨리 제공해야 한다면 Guance를 완성된 서비스로 비교하겠습니다. 실제로 줄일 수 있는 백엔드 운영과 통합 작업이 그 가치입니다.

로그를 자체 환경에 두어야 한다면 그 환경에서 제공할 수 있는 배포 방식부터 선택합니다. Guance Deployment Plan과 자체 운영 엔진 모두 고객 측 리소스와 운영 분담을 계산해야 하며 SaaS 단가는 프라이빗 배포 견적이 아닙니다. 백업, 지원 인력의 접근과 외부 호출도 데이터 경로에 포함합니다. Guance 배포 방식

같은 범위로 총비용을 계산합니다.

월 운영 비용 = 제품 사용료 + 유지할 인프라 + 지속 운영·지원
             + 추가 쿼리·복원·네트워크 요금
첫해 비용 = 12 × 월 운영 비용 + 일회성 이전·병행 운영 비용

엔지니어링 시간과 현금 지출은 나누고 이미 발생한 투자를 신규 구매 비용으로 다시 세지 않습니다. 이전 효과를 볼 때는 여전히 유지할 수집기, 업무 필드, 쿼리, 알림과 과거 데이터 접근을 빼야 합니다. 표준 프로토콜은 수집을 도와도 이런 자산까지 자동으로 옮기지는 않습니다.

Guance, 상용 SaaS, 자체 운영과 클라우드 서비스를 모두 팀에 필요한 쿼리·보존·제공 범위로 견적 냅니다. 같은 작업을 충족하면서 지속 부담을 줄이고 예산과 데이터 위치 요구에 맞는 것이 선택할 가치가 있는 로그 플랫폼입니다.