오늘날 대규모 인프라 환경에서 발생하는 방대한 데이터를 관리하기 위해 로그 모니터링과 로그분석은 필수적인 요소가 되었습니다. OpenSearch(및 Elasticsearch)는 이 분야의 사실상 표준으로 자리 잡았으나, 이를 활용하는 엔지니어와 분석가들은 강력한 기능의 이면에 있는 ‘Query DSL’이라는 높은 진입 장벽을 마주하곤 합니다.
JSON 형식을 기반으로 하는 DSL은 검색 조건을 매우 정밀하게 정의할 수 있다는 장점이 있습니다. 하지만 쿼리가 복잡해질수록 로직이 깊게 중첩되어 가독성이 떨어지고 생산성이 저하되는 구조적 문제를 안고 있습니다. 특히 1분 1초가 급한 장애 상황이나 보안 침해 사고를 분석해야 하는 SIEM(보안 정보 및 이벤트 관리) 환경에서, 수십 줄의 JSON 괄호를 맞추는 작업은 민첩한 대응을 방해하는 실질적인 걸림돌이 됩니다.
이러한 문제를 해결하기 위해 등장한 것이 바로 PPL(Piped Processing Language)입니다. PPL이 제안하는 새로운 분석 방식을 살펴보기 전, 먼저 우리가 기존 DSL 환경에서 겪어온 실제적인 어려움들을 통해 왜 방식의 변화가 필요한지 짚어보겠습니다.
OpenSearch(및 Elasticsearch)는 검색 엔진 시장의 사실상 표준으로 자리 잡았지만, 데이터 분석가나 엔지니어들에게는 한 가지 큰 진입 장벽이 존재했습니다. 바로 Query DSL(Domain Specific Language)입니다.
DSL은 JSON(JavaScript Object Notation) 형식을 기반으로 하며, 검색 쿼리의 구조를 매우 정밀하게 정의할 수 있다는 강력한 장점이 있습니다. 하지만 이는 동시에 인간의 직관과는 거리가 먼 방식이기도 합니다. DSL은 쿼리가 복잡해질수록 JSON 객체가 깊게 중첩되는 특성이 있기 때문입니다.
예를 들어 단순한 GROUP BY 집계를 수행하려 해도 aggs안에 terms, 그 안에 다시 aggs를 정의해야 하는 피라미드 구조가 형성됩니다.
일반적으로 데이터를 탐색하는 과정은 "A를 찾고, B를 제외한 뒤, C로 묶어서 계산한다"라는 선형적인 사고를 따릅니다. 하지만 DSL은 이 모든 조건을 하나의 거대한 JSON 객체로 구조화해야 하므로, 작성과 수정 시 높은 집중력을 요합니다. 또한 로그를 분석하거나 장애 원인을 파악하는 긴급한 상황에서, 수십 줄의 JSON 괄호 짝들은 가독성과 생산성을 저하시키는 요인이 됩니다.
<예시 1.1: 지난 1시간 동안 500 에러가 발생한 상위 5개 IP 추출하기 위한 DSL문>
PPL은 이러한 구조적 복잡성을 해결하기 위해 등장했습니다. 이름에서 알 수 있듯이, 파이프(Pipe, |)를 통해 데이터를 순차적으로 처리하는 언어입니다.
PPL이 가져온 변화는 단순히 문법의 형태를 바꾼 수준에 그치지 않습니다. 데이터에 접근하는 패러다임 자체를 선언적 구조(JSON)에서 절차적 흐름(Pipeline)으로 전환시킨 것입니다. 이는 Unix와 Linux에서 익숙하게 사용되는 명령어 파이프라인 철학을 데이터 검색 엔진에 이식한 결과이기도 합니다.
이러한 방식의 변화 덕분에 사용자는 더 이상 복잡한 JSON의 계층 구조를 설계할 필요가 없습니다. 대신 "데이터를 가져오고, 필터링한 뒤, 통계를 낸다"는 인간의 자연스러운 사고 흐름에 맞춰 질의를 작성할 수 있게 되었습니다. 이는 결과적으로 쿼리 작성 시간을 단축시키고, 분석가의 의도를 더욱 명확하게 코드에 투영할 수 있게 해줍니다.
<예시 1.2: 예시 1.2와 동일한 로직을 PPL로 작성한 경우>
PPL을 도입해야 하는 이유는 단순히 쓰기 편해서가 아닙니다. 이는 데이터 분석의 접근성(Accessibility), 가독성(Readability), 유연성(Flexibility) 측면에서 근본적인 이점을 제공하기 때문입니다.
데이터 업계에서 SQL은 가장 보편적인 언어입니다. PPL은 SQL의 문법적 특성을 차용하여 접근성을 높였습니다. SELECT, WHERE, LIKE 등 익숙한 키워드를 그대로 사용하므로, 새로운 도구 도입에 따른 저항감을 최소화합니다.
PPL의 가장 강력한 무기는 | (파이프) 연산자입니다. 이는 쿼리를 논리적 단계로 분해합니다.
1단계: 전체 데이터 가져오기 (source=logs)
2단계: 필요한 부분만 남기기 (| where status=500)
3단계: 불필요한 필드 버리기 (| fields timestamp, message)
이처럼 하나의 문제를 단계별로 쪼개며 순차적으로 해결할 수 있습니다. 이러한 방식은 디버깅의 용이성도 증가시킵니다. DSL은 쿼리가 실패하면 전체 JSON 구조를 다시 살펴봐야 하지만, PPL은 파이프를 하나씩 끊어가며 어느 단계에서 데이터가 의도와 다르게 변형되었는지 즉시 확인할 수 있습니다.
OpenSearch의 집계(Aggregation) 기능은 강력하지만 DSL 작성이 매우 까다롭습니다. PPL은 이를 stats 명령어로 추상화했습니다.
기존 DSL 방식에서 집계를 하려면 버킷(Buckets)과 메트릭(Metrics)의 개념을 이해하고, 이를 JSON의 계층 구조로 쌓아 올려야 했습니다. 하지만 PPL은 이 복잡한 과정을 우리가 흔히 쓰는 SQL 스타일로 탈바꿈시켰습니다.
간단한 시나리오인 “카테고리별 평균 가격 구하기”를 DSL로 작성하면 aggs 안에 그룹핑을 위한 terms를 정의하고, 그 안에 다시 계산을 위한 aggs를 중첩해야 합니다.
평균을 구한다라는 쿼리의 의도보다 괄호와 같은 문법적 구조에 더 신경 써야 합니다. 그룹핑 조건이 늘어날수록 JSON은 기하급수적으로 깊어집니다.
반면 동일한 시나리오를 PPL로 작성하면 stats 이라는 명령어로 간단하게 표현할 수 있습니다.
stats: "집계를 시작하겠다"는 선언입니다.
avg(price): "무엇을 계산할지" 명시합니다. (Metric)
by category: "무엇을 기준으로 묶을지" 명시합니다. (Bucket)
단 한 줄의 코드로 DSL의 복잡한 로직을 완벽하게 대체할 수 있습니다.
데이터 분석을 하다 보면, 인덱스에 저장된 원본 데이터(Raw Data)만으로는 부족할 때가 많습니다.
- 용량이 bytes 단위로 저장되어 있어 보기 불편한 경우
- 파일 경로와 파일 이름이 하나의 필드에 있어 각각 분리해야 하는 경우
- 보낸 용량, 받은 용량만 있고 총 용량이 없는 경우
이를 해결하기 위해 데이터를 재색인(Reindexing)하는 것은 너무 복잡한 과정입니다. 하지만 PPL은 eval 명령어 하나로 쿼리 실행 시점에 필드를 즉석에서 생성합니다. 바이트 단위를 메가바이트로 변환하여 새로운 필드 size_mb를 만드는 로직은 eval 명령어와 간단한 연산자를 이용하여 작성할 수 있습니다.
원본 데이터에는 size_mb라는 필드가 존재하지 않습니다. 하지만 PPL이 실행되는 순간 계산되어, 마치 원래 있던 필드처럼 where 절에서 필터링 조건으로 사용하거나 fields로 출력할 수 있습니다.
PPL의 eval은 데이터 저장 구조(Schema)가 분석의 한계가 되지 않도록, 분석가에게 데이터를 재정의할 수 있는 강력한 권한을 부여하는 기능입니다.
앞서 PPL이 데이터 분석에 제공하는 근본적인 이점들을 살펴보았습니다. 하지만 이러한 장점들을 실무에 온전히 녹여내기 위해서는 PPL이 데이터를 처리하는 방식, 즉 문법의 구조를 정확히 이해하는 과정이 필요합니다.
PPL의 문법은 단순한 규칙의 나열이 아니라, 데이터의 흐름을 제어하는 그 자체입니다. 각 명령어는 이전 단계에서 넘어온 데이터를 가공하여 다음 단계로 넘겨주는 '필터' 역할을 수행합니다. 마치 공장의 컨베이어 벨트 위에서 원재료가 각 공정을 거쳐 완성품이 되는 것과 같은 원리입니다.
그럼 지금부터 데이터 분석 현장에서 가장 빈번하게 사용되는 6가지 핵심 명령어를 통해 PPL의 구조를 깊이 있게 살펴보겠습니다.
모든 PPL 쿼리의 시작점입니다. SQL의 FROM 절에 해당하지만, PPL에서는 search source=... 형태로 명시합니다.
단일 인덱스뿐만 아니라 와일드카드(*)를 사용하여 여러 인덱스를 동시에 조회할 수 있습니다.
search source=logs-* : 'logs-'로 시작하는 모든 인덱스 조회.
분석에 불필요한 데이터를 걸러내는 단계입니다. SQL의 WHERE 절과 동일합니다. where는 파이프라인의 가장 앞단에 위치시키는 것이 성능상 유리합니다. 처리해야 할 데이터의 총량을 줄여주기 때문입니다. where는 AND, OR, NOT 논리 연산자와 in, like 등의 비교 연산자를 모두 지원합니다.
원본 데이터에는 없지만 분석 시점에 필요한 새로운 데이터를 만들어냅니다. 기존 필드 값을 이용해 계산을 하거나 문자열을 조합하여 새로운 필드를 정의합니다.
SQL의 GROUP BY와 집계 함수를 합친 개념입니다.
문법: stats <function>(<field>) by <grouping_field>
집계함수: count, sum, avg, min, max와 같은 통계 분석에 필요한 함수를 제공합니다.
최종 사용자에게 보여줄 데이터를 다듬는 과정입니다. SELECT 절과 유사합니다. 수백 개의 필드 중 분석에 필요한 핵심 필드만 남깁니다 (+로 포함, -로 제외 가능).
rename: 기술적인 필드명(예: req_ts_ms)을 비즈니스 친화적인 이름(예: Response Time)으로 변경하여 가독성을 높입니다.
3.6. sort & head
sort: 데이터의 정렬 순서를 정합니다. - 기호를 붙이면 내림차순(DESC)이 됩니다. (sort -count)
head: SQL의 LIMIT와 같습니다. 상위 N개의 결과만 잘라냅니다. 대량의 데이터 분석 시 결과를 끊어서 확인하는 데 필수적입니다.
지금까지 PPL의 기본 개념과 주요 명령어들을 살펴보았습니다. 하지만 도구의 진정한 가치는 이론적인 문법을 아는 것에 그치지 않고, 이를 실제 복잡한 데이터 환경에 어떻게 적용하느냐에 있습니다.
이제 우리가 현업에서 흔히 마주할 수 있는 구체적인 시나리오들을 통해, PPL이 실무적인 문제들을 얼마나 직관적이고 효율적으로 해결하는지 단계별로 알아보겠습니다.
상황: 과도한 로그인 실패(401 Error) IP 식별
1) search source=access_logs: 엑세스 로그 전체를 가져옵니다.
2) where status = 401: 전체 로그 중 로그인 실패 로그만 남깁니다.
3) stats count() as fail_count by client_ip: IP 주소별로 실패 횟수를 집계합니다. 이제 데이터는 개별 로그가 아니라 'IP별 요약 정보'가 됩니다.
4) where fail_count > 50: 50회 이상 실패한 의심 IP만 필터링합니다. (집계 후 필터링 - SQL의 HAVING 절과 유사)
5) sort -fail_count: 가장 공격 빈도가 높은 IP를 최상단에 노출합니다.
상황: 상품 카테고리별 매출 현황과 평균 단가 확인
1) eval revenue = price * quantity: price와 quantity 필드를 곱하여, 원본 데이터에 없던 revenue(매출액) 필드를 실시간으로 계산해냅니다.
2) stats sum(revenue) as total_sales, avg(revenue) as avg_order_value by category: 카테고리 기준으로 총 매출(sum)과 평균 주문액(avg)을 동시에 계산합니다.
3) head 10: 상위 10개 카테고리만 추출하여 리포트용 데이터를 완성합니다.
상황: 지난 24시간 동안 웹 서버의 트래픽 변화
1) span(timestamp, 10m): 연속적인 시간 데이터를 10분 단위로 자릅니다.
2) stats count() as request_count by ...: 잘라낸 10분 단위별로 요청 수(count)를 셉니다.
결과: 이 쿼리의 결과는 그대로 라인 차트(Line Chart)나 바 차트(Bar Chart)로 시각화하기 완벽한 형태(X축: 시간, Y축: 횟수)가 됩니다.
PPL은 사용자가 직관적으로 쿼리를 작성할 수 있게 돕지만, 그 이면에서는 방대한 데이터를 처리하는 무거운 작업이 수행됩니다. 도구의 편리함이 시스템의 부하로 이어지지 않도록, 쿼리 효율성을 고려하는 분석 습관을 갖추는 것이 중요합니다
PPL 쿼리는 파이프라인 구조이기 때문에, 앞단에서 데이터의 크기를 줄일수록 전체 실행 속도가 기하급수적으로 빨라집니다.
1) where는 search 바로 뒤에 오는 것이 좋습니다.
데이터를 집계(stats)하거나 정렬(sort)한 뒤에 필터링하는 것은 낭비입니다. 불필요한 데이터를 메모리에 올리기 전에 where 절로 과감하게 잘라내야 합니다.
2) 필요한 필드만 명시하는 것이 좋습니다.
OpenSearch 문서는 수십, 수백 개의 필드를 가질 수 있습니다. fields 명령어를 사용하여 분석에 꼭 필요한 필드만 남기면 네트워크 전송량과 메모리 사용량을 획기적으로 줄일 수 있습니다.
PPL이 등장했다고 해서 기존의 DSL(Domain Specific Language)이 사라지는 것은 아닙니다. 두 언어는 태생적 목적이 다릅니다. 이 둘을 상호 보완적인 관계로 이해하고 적재적소에 사용하는 것이 좋습니다.
1) PPL을 써야 하는 경우 - 사람 중심, 탐색, Ad-hoc 분석, 운영/보안
PPL은 사람이 데이터를 봐야 하는 상황에 최적화되어 있습니다. 사고의 흐름이 끊기지 않고 빠르게 질문을 던지고 답을 얻어야 하는 상황입니다.
* 상황 A: 장애 발생 시 긴급 원인 분석
"지금 500 에러가 급증하는데, 특정 API에서만 발생하는 건가?" 긴급 상황에서 복잡한 JSON 괄호를 맞출 시간은 없습니다. PPL로 빠르게 필터링(where)하고 집계(stats)하여 원인을 좁혀나가야 합니다.
* 상황 B: 보안 위협 헌팅
"지난 1주일간 새벽 시간에만 접속한 관리자 계정이 있는가?" 데이터를 이리저리 돌려보고, 조건을 바꿔가며 숨겨진 패턴을 찾아내는 '탐색적 분석'에는 수정이 용이한 PPL이 압도적으로 유리합니다.
* 상황 C: 비개발 직군의 데이터 접근
기획자(PM), 마케터, 데이터 분석가가 직접 데이터를 추출해야 할 때. SQL에 익숙한 이들에게 JSON DSL을 학습시키는 것은 비효율적입니다. PPL은 이들에게 데이터 접근 권한을 열어주는 열쇠가 됩니다.
2) DSL을 써야 하는 경우
키워드: 기계 중심, 애플리케이션 개발, 정밀도, 검색 튜닝
DSL은 애플리케이션이 데이터를 조회할 때 최적화되어 있습니다. 코드로 구현되어 시스템의 일부로 동작하거나, 매우 정교한 검색 로직이 필요할 때 사용합니다.
* 상황 A: 검색 서비스 기능 구현
쇼핑몰 검색창, 자동 완성, 추천 시스템 등 최종 사용자에게 노출되는 기능을 개발할 때. Java, Python, Go 등의 클라이언트 라이브러리(SDK)는 객체 지향적인 JSON 구조(DSL)와 완벽하게 매핑됩니다. 코드로 쿼리를 조립하기에는 DSL이 훨씬 안정적입니다.
* 상황 B: 정교한 검색 랭킹 튜닝
function_score, boosting, slop 등 검색 품질을 미세하게 조정하는 기능은 DSL만이 100% 지원합니다. PPL은 '분석'에 강하지만 '검색 랭킹' 제어력은 약합니다.
* 상황 C: 초고성능 최적화가 필요한 고정 쿼리
수천만 건의 데이터를 0.1초 안에 조회해야 하는 API 백엔드. DSL은 필터 캐싱, 라우팅 제어 등 엔진 내부의 최적화 기능을 극한까지 활용할 수 있는 세밀한 옵션들을 제공합니다.\
3) 정리
지금까지 OpenSearch의 PPL(Piped Processing Language)에 대해 깊이 있게 살펴보았습니다. 과거에는 OpenSearch 데이터를 분석하려면 'JSON 괄호와의 싸움'을 피할 수 없었습니다. 하지만 PPL의 등장으로 이제 SQL을 아는 개발자, 데이터 분석가, 심지어 비개발 직군까지도 데이터와 직접 대화할 수 있는 길이 열렸습니다.
PPL이 가져온 변화는 명확합니다.
- 직관성: 사고의 흐름대로 파이프(|)를 연결하여 로직을 구현합니다.
- 생산성: 복잡한 집계 코드를 단 한 줄로 압축합니다.
- 협업: 누구나 읽고 이해할 수 있는 코드로 팀 간 커뮤니케이션이 원활해집니다.
여러분의 데이터 인프라에 OpenSearch가 있다면, 오늘 당장 복잡한 JSON 대신 PPL을 입력해 보시길 권합니다. 단순히 쿼리 언어를 바꾸는 것을 넘어, 데이터 속에 숨겨진 인사이트를 발견하는 속도가 달라질 것입니다.
Zenius SIEM의 개발을 담당하고 있습니다.
