왜 Splunk는 비싼데도 기업들이 계속 사용할까?

SIEM(Security Information and Event Management) 솔루션을 이야기할 때 빠지지 않는 이름이 있다. 바로 Splunk다. 처음 Splunk 가격을 접하면 대부분 비슷한 반응을 보인다.

"로그 저장하는데 왜 이렇게 비싸?"

실제로 Splunk는 많은 기업이 도입을 고민하다가 가격 때문에 포기하는 제품으로도 유명하다. 그런데 이상한 점이 있다. 수많은 오픈소스 대안이 존재하는 지금도 여전히 많은 대기업과 금융권, 공공기관은 Splunk를 사용한다. 왜일까?

로그 저장소가 아니다

많은 사람들이 Splunk를 로그 저장소라고 생각한다. 하지만 Splunk를 단순 저장소로 보면 가격이 비싸게 느껴질 수밖에 없다. 실제로 Splunk가 제공하는 것은 저장소가 아니다.

로그 운영 플랫폼이다.

로그가 들어오면 무슨 일이 일어날까?

단순히 로그를 저장하는 시스템이라면 구조는 어렵지 않다.

애플리케이션에서 로그를 전송하고, 저장소에 넣은 뒤, 필요할 때 검색하면 된다. 하지만 실제 운영 환경에서는 로그가 저장되기 전과 저장된 이후에 훨씬 많은 일이 발생한다.

운영자는 단순히 로그를 보관하려는 것이 아니다. 로그를 이용해 다음과 같은 질문에 빠르게 답하고 싶어 한다.

• 지금 서버에 장애가 발생했는가?
• 장애가 발생했다면 어느 서비스에서 시작됐는가?
• 특정 시간대에 응답 시간이 느려진 원인은 무엇인가?
• 누가 관리자 계정에 로그인했는가?
• 평소와 다른 네트워크 트래픽이 발생했는가?
• 랜섬웨어나 계정 탈취의 징후가 있는가?

이 질문에 답하려면 로그를 받아서 저장하는 것만으로는 부족하다.

서로 다른 형식의 데이터를 수집하고, 필요한 필드를 추출하고, 검색할 수 있도록 인덱싱해야 한다. 이후에는 대시보드를 만들고, 조건을 만족하면 경보를 발생시키고, 실제 사고 대응 과정으로 연결해야 한다.

즉, 로그 시스템은 단순한 저장소가 아니라 다음 과정을 지속적으로 운영하는 시스템에 가깝다.

수집 → 정규화 → 저장 → 검색 → 탐지 → 대응

진짜 어려운 것은 검색이 아니라 운영이다

로그 플랫폼을 처음 검토할 때는 검색 속도나 저장 비용을 중심으로 비교하기 쉽다. 하지만 실제 운영이 시작되면 문제의 중심은 점차 달라진다.

예를 들어 하루 100GB의 로그를 처리하던 시스템이 서비스 확장으로 하루 1TB를 처리하게 됐다고 가정해 보자.

단순히 디스크 용량만 열 배로 늘리면 해결될 것 같지만, 실제로는 여러 문제가 함께 발생한다.

• 수집 구간에서 데이터가 밀리지 않는가?
• 특정 노드에 부하가 집중되지 않는가?
• 인덱스와 샤드 수는 적절한가?
• 검색 성능이 이전과 동일하게 유지되는가?
• 오래된 데이터는 언제 저비용 스토리지로 이동할 것인가?
• 데이터 보존 기간은 어떻게 적용할 것인가?
• 노드가 중단되었을 때 데이터가 유실되지 않는가?
• 업그레이드 중에도 서비스가 유지되는가?
• 장애가 발생했을 때 누가 원인을 분석하고 복구하는가?

데이터가 많아질수록 검색 엔진 자체보다 그 주변의 운영 정책이 더 중요해진다.

작은 규모에서는 엔지니어 한 명이 설정을 관리할 수 있다. 그러나 수십 개의 데이터 소스, 여러 부서의 사용자, 장기간의 데이터 보존, 실시간 경보가 결합되면 운영 복잡도는 빠르게 커진다.

그래서 기업이 로그 플랫폼을 선택할 때는 단순히 “로그를 검색할 수 있는가?”가 아니라 다음 질문까지 함께 고려해야 한다.

이 시스템을 3년 동안 안정적으로 운영할 수 있는가?

OpenSearch가 있는데 왜 Splunk를 사용할까?

OpenSearch 역시 대용량 데이터를 저장하고 검색하는 데 강력한 도구다. 라이선스 비용 부담이 상대적으로 낮고, 인프라와 데이터 구조를 조직의 요구에 맞게 직접 설계할 수 있다는 장점이 있다.

특히 검색 엔진과 분산 시스템을 운영할 수 있는 엔지니어가 충분한 조직이라면 높은 자유도는 큰 장점이 된다.

하지만 자유도가 높다는 것은 반대로 말하면 결정해야 할 것도 많다는 뜻이다.

OpenSearch를 직접 운영할 때 결정해야 하는 것

• 클러스터를 몇 개의 노드로 구성할 것인가?
• 샤드와 레플리카 수를 어떻게 정할 것인가?
• 날짜별 인덱스를 어떤 단위로 생성할 것인가?
• Hot, Warm, Cold 데이터를 어떻게 구분할 것인가?
• 오래된 인덱스의 보존과 삭제 정책을 어떻게 적용할 것인가?
• 스냅샷은 어디에, 얼마나 자주 생성할 것인가?
• 클러스터 장애 시 복구 절차는 무엇인가?
• 버전 업그레이드를 어떤 방식으로 진행할 것인가?
• 사용자와 조직별 데이터 접근 권한을 어떻게 나눌 것인가?
• 탐지 규칙과 경보 상태를 어디에서 관리할 것인가?

각 기능은 구현할 수 있다. 하지만 구현 가능하다는 것과 안정적으로 운영할 수 있다는 것은 다른 문제다.

OpenSearch를 선택한다는 것은 검색 엔진을 도입하는 동시에, 그 검색 엔진을 중심으로 자체 로그 플랫폼을 만들어 나가는 선택에 가깝다.

Splunk는 무엇을 제품으로 제공할까?

Splunk의 강점은 단순히 데이터를 검색할 수 있다는 데 있지 않다.

로그를 수집하고, 필드를 추출하고, 검색하고, 시각화하고, 경보를 발생시키는 전 과정을 하나의 운영 체계 안에서 제공한다는 점이 중요하다.

조직은 Splunk를 이용해 다음과 같은 작업을 비교적 일관된 방식으로 수행할 수 있다.

• 다양한 데이터 소스 연결
• 로그 수집 상태 확인
• 필드 추출과 데이터 정규화
• 검색 쿼리 작성
• 대시보드 구성
• 탐지 규칙과 경보 설정
• 사용자와 역할별 접근 권한 관리
• 보안 이벤트 조사
• 사고 대응 과정 연결
• 앱과 콘텐츠를 활용한 기능 확장

물론 Splunk를 도입한다고 모든 운영 문제가 자동으로 해결되는 것은 아니다. Splunk 역시 데이터 모델링, 검색 최적화, 보존 정책, 인프라 구성에 대한 운영 경험이 필요하다.

다만 많은 기능을 직접 조합해 플랫폼을 만드는 대신, 이미 제품화된 운영 방식을 사용할 수 있다는 차이가 있다.

이것이 Splunk의 높은 가격을 단순한 저장 비용만으로 비교하기 어려운 이유다.

검색 엔진과 운영 플랫폼의 차이

OpenSearch와 Splunk를 동일한 기준으로만 비교하면 양쪽의 장단점이 명확하게 보이지 않는다.

OpenSearch는 검색과 분석을 위한 기반 기술에 가깝고, Splunk는 그 기반 기술 위에 운영과 분석 경험을 제품으로 구성한 플랫폼에 가깝다.

따라서 어떤 제품이 무조건 더 좋다고 말하기는 어렵다.

플랫폼을 직접 설계하고 운영할 역량이 충분하다면 OpenSearch의 자유도와 비용 구조가 큰 장점이 된다. 반대로 빠른 구축과 표준화된 운영, 기술 지원이 중요하다면 Splunk가 더 합리적인 선택이 될 수 있다.

기업이 계산하는 것은 라이선스가 아니라 총비용이다

기업은 기술을 선택할 때 제품 가격만 계산하지 않는다.

실제 비용은 다음 항목을 모두 합친 총소유비용, 즉 TCO에 가깝다.

총비용 =
라이선스 비용
+ 인프라 비용
+ 구축 비용
+ 운영 인력 비용
+ 장애 대응 비용
+ 업그레이드 비용
+ 교육 비용
+ 기회비용

예를 들어 Splunk 라이선스 비용이 연간 1억 원이라고 가정하면 처음에는 매우 비싸 보인다.

하지만 OpenSearch 기반의 자체 플랫폼을 운영하기 위해 다음과 같은 비용이 계속 발생할 수 있다.

• 클러스터를 운영하는 엔지니어
• 수집 파이프라인을 개발하는 엔지니어
• 대시보드와 경보를 관리하는 담당자
• 야간과 휴일의 장애 대응
• 버전 업그레이드와 마이그레이션
• 검색 성능 저하에 대한 분석과 튜닝
• 장애로 탐지가 지연되었을 때 발생하는 손실

반대로 이미 검색 엔진과 분산 시스템 운영 인력을 보유한 기업이라면 Splunk의 라이선스 비용이 더 큰 부담으로 느껴질 수 있다.

결국 비용 비교는 다음처럼 단순하지 않다.

Splunk 라이선스 비용 vs OpenSearch 라이선스 비용

실제로는 다음을 비교해야 한다.

Splunk를 도입하고 운영하는 총비용 vs OpenSearch 기반 플랫폼을 직접 구축하고 유지하는 총비용

비싼 이유는 사람이 하기 싫은 일을 제품화했기 때문이다

운영 경험이 쌓일수록 기술 자체보다 사람의 시간과 책임이 더 비싸다는 점을 체감하게 된다.

로그 수집, 필드 추출, 인덱스 관리, 검색 최적화, 경보 설정, 대시보드 구성은 각각 따로 보면 구현하기 어려운 기능만은 아니다.

문제는 이러한 기능을 한 번 만드는 것이 아니라 계속 유지하는 것이다.

새로운 데이터 소스가 추가되면 파서를 수정해야 한다. 데이터량이 증가하면 인덱스 구조를 다시 검토해야 한다. 조직이 커지면 권한 정책을 세분화해야 한다. 서비스가 변경되면 대시보드와 경보 조건도 바뀐다.

그리고 장애가 발생하면 운영 조직은 다음 질문에 답해야 한다.

• 데이터가 유실됐는가?
• 수집이 중단된 시점은 언제인가?
• 검색 결과가 정확한가?
• 경보가 누락되지는 않았는가?
• 동일한 장애가 다시 발생하지 않도록 무엇을 바꿔야 하는가?

Splunk가 판매하는 것은 개별 기능만이 아니다.

반복되는 운영 작업과 시행착오를 줄여 주는 제품화된 경험이다.

그런데 왜 기업들은 OpenSearch로 이동할까?

Splunk가 운영 측면에서 장점이 있더라도 데이터가 계속 증가하면 비용 구조가 문제가 될 수 있다.

과거에는 일부 핵심 시스템의 로그만 수집했다면, 최근에는 애플리케이션 로그, 보안 로그, 네트워크 로그, 클라우드 감사 로그, 사용자 행위 로그 등 수집 대상이 빠르게 늘어나고 있다.

처음에는 하루 수십 GB였던 데이터가 수백 GB 또는 수 TB로 늘어날 수 있다. 데이터 증가가 곧 비용 증가로 이어지는 구조에서는 어느 순간 운영 편의성보다 비용 부담이 더 커진다.

그래서 기업들은 여러 가지 대안을 검토한다.

• 일부 데이터만 Splunk에 저장
• 중요도가 낮은 데이터는 별도 저장소로 분리
• 오래된 데이터를 저비용 스토리지로 이동
• OpenSearch 기반 플랫폼과 병행
• 검색 빈도가 낮은 데이터는 필요할 때만 조회
• 조직의 요구에 맞는 자체 로그 플랫폼 구축

즉, Splunk를 완전히 제거하고 OpenSearch로 이동하는 선택만 존재하는 것은 아니다.

중요도와 사용 빈도에 따라 저장소를 나누거나, Splunk와 다른 플랫폼을 함께 사용하는 혼합 구조도 가능하다.

어떤 조직에 무엇이 더 적합할까?

제품의 우열보다 조직의 상황이 더 중요하다.

Splunk가 잘 맞을 가능성이 높은 조직

• 로그 플랫폼을 빠르게 구축해야 하는 조직
• 자체 검색 엔진 운영 인력이 부족한 조직
• 보안 분석과 사고 대응 기능이 중요한 조직
• 여러 부서가 동일한 플랫폼을 사용해야 하는 조직
• 벤더 기술 지원과 검증된 운영 방식을 중요하게 보는 조직
• 라이선스 비용보다 구축 속도와 운영 안정성이 중요한 조직

OpenSearch가 잘 맞을 가능성이 높은 조직

• 대규모 데이터를 비용 효율적으로 저장해야 하는 조직
• 검색 엔진과 분산 시스템 운영 경험이 있는 조직
• 자체 데이터 파이프라인과 분석 시스템을 보유한 조직
• 제품의 제약보다 높은 커스터마이징 자유도가 필요한 조직
• 로그 이외의 검색 서비스에도 동일한 기술을 활용하려는 조직
• 장기적으로 자체 플랫폼 역량을 확보하려는 조직

자체 로그 엔진이 잘 맞을 가능성이 높은 조직

• 특정 데이터와 검색 패턴에 극단적인 최적화가 필요한 조직
• 기존 검색 엔진의 비용이나 구조적 제약이 큰 조직
• 장기간 엔진을 개발하고 운영할 전문 인력이 있는 조직
• 로그 플랫폼 자체가 핵심 사업 경쟁력인 조직

자체 엔진은 가장 높은 자유도를 제공하지만, 가장 많은 개발 비용과 시간이 필요한 선택이기도 하다.

국내 시장에서는 어떨까?

국내 환경에서는 제품 기능뿐 아니라 운영 방식과 지원 체계도 중요한 선택 기준이 된다.

특히 다음과 같은 요구사항이 자주 함께 고려된다.

• 총소유비용
• 온프레미스와 폐쇄망 지원
• 데이터 주권
• 국내 규제와 감사 대응
• 빠른 기술 지원
• 기존 보안 시스템과의 연동
• 고객 환경에 맞는 커스터마이징
• 장기간의 데이터 보존
• 장애 발생 시 원인 분석과 현장 대응

이러한 요구 때문에 글로벌 제품뿐 아니라 OpenSearch 기반 플랫폼이나 국내에서 개발된 로그 분석 플랫폼도 함께 검토된다. 현재 나 역시 로그 분석 플랫폼을 개발하는 팀에서 일하고 있다. 그러다 보니 단순히 검색 성능이 높은 제품보다 수집, 저장, 분석, 운영, 비용이 전체적으로 균형을 이루는지가 더 중요하다는 생각을 하게 된다.

벤치마크에서 빠른 시스템이 실제 운영에서도 항상 좋은 시스템은 아니다. 데이터가 지속적으로 증가하는 상황에서 안정적으로 수집할 수 있어야 하고, 장애가 발생했을 때 복구할 수 있어야 하며, 운영자가 필요한 정보를 빠르게 찾을 수 있어야 한다. 결국 중요한 질문은 어떤 제품이 가장 유명한가가 아니다.

우리 조직의 데이터 규모, 운영 역량, 예산, 보안 요구사항에 가장 적합한 선택은 무엇인가?

마치며

Splunk와 OpenSearch는 모두 로그를 저장하고 검색할 수 있지만, 제품이 해결하려는 문제의 범위에는 차이가 있다. OpenSearch는 높은 자유도와 확장성을 제공하는 검색·분석 기반 기술에 가깝다. Splunk는 수집부터 분석, 경보, 보안 운영까지 연결하는 운영 플랫폼에 가깝다. 그래서 Splunk의 가격을 단순히 저장 용량이나 검색 성능만으로 평가하면 비싸게 느껴질 수밖에 없다. 기업이 Splunk를 통해 구매하는 것은 저장 공간만이 아니다.

장애를 더 빨리 찾고, 보안 사고를 더 빠르게 분석하고, 운영 과정의 시행착오를 줄이는 방법을 구매한다.

반면 데이터 규모가 매우 크거나 자체 운영 역량이 충분한 조직은 OpenSearch와 자체 플랫폼을 통해 더 높은 비용 효율성과 자유도를 얻을 수 있다. 결국 선택의 핵심은 제품의 절대적인 우열이 아니다. 라이선스 비용, 인프라 비용, 운영 인력, 장애 대응, 구축 속도, 데이터 규모를 모두 포함해 우리 조직의 총비용과 운영 목표를 함께 판단해야 한다.