다양한 metric의 필요성

얼마 전 특정 보안 제품 활용 교육 의뢰가 있었다. 엘라스틱 기반으로 개발했다는 설명을 듣고 어렵지 않겠다 싶어 수락. 그런데 제품을 살펴보니 데이터 집계 유형이 'Count' 밖에 없네?

엘라스틱의 다양한 메트릭 유형들

같은 데이터를, 형태를 바꿔가며 다양하게 바라보는 과정을 거치면 자연스럽게 데이터에 대한 이해도를 높일 수 있다.

응답코드 500 상태의 개수 변화

응답코드 500 상태의 로그 Count와 변수 길이에 대한 Sum 메트릭의 변화는 어떤 차이를 말해주는 것일까?

응답코드 500 상태의 변수 길이 변화

로그 Count와 접속 IP의 Cardinality(Unique Count) 메트릭 차이를 통해 알 수 있는 것은 무엇일까?

로그/동접자 발생 추이

해당 제품으로는 이런 사례 제시가 불가능했다. 뒤늦게 고사하려 했으나 지인 찬스 때문에 그냥 진행(..) 결국 VIM, 정규표현식과 엑셀을 이용한 데이터 전처리/시각화 교육만 하다 왔다.

특정 제품 교육인데 해당 제품이 등장하지 않는, (그렇다고 엘라스틱을 활용하기도 난처한) 돈 받고 하는 입장에서 매우 매우 어색한 교육. -_-

집계 유형에 'Unique Count'라도 추가할 수 없느냐 물었는데 난색을 보이더라. 개발은 잘 모르지만 구현이 쉽지는 않은 모양. 그저 개발 난이도 문제일까?

사실은 돈 문제 그리고

사용자의 의지 문제. 연말 예산 소진하느라 급하게 구축된, 예산 규모도 뻔한 상황에서 적극적인 사용 의지 없으면 그 해 실적 하나 보태주고 끝날 확률 99%.

예산 규모가 크다 한들, 사용 의지가 부족하면 상황은 별로 달라지지 않는다.

수년 전 엘라스틱 형님뻘인 solr 기반의 SIEM 구축 과정을 지켜본 적이 있다. 그때 물 건너온 빅데이터에 대한 열기가 하도 뜨거워서 발주 담당자들이 책 끼고 다니면서 공부할 정도.

하지만 그렇게 구축된 제품은 그때나 지금이나 Count 집계만 지원하더라. 수단이 목적이 되어버린 흔한 케이스

왜 기능을 추가하지 않을까? 사용자가 요구하지도 않는 기능 때문에 일부러 어려운 길로 갈 필요는 없으니까. 결정적으로 개발자는 뭐가 좋은지 알기 어렵다.

사진앱을 만들어보자. 사진앱은 누구나 목적과 사용 결과를 예상할 수 있고, 예상을 벗어나면 실망이란 걸 해볼 수 있다. (실망을 해야 개선해야겠다는 생각도 하게 됨) 개발자가 사용자 관점에서 접근할 수 있다는, 개발자와 사용자의 간극이 크지 않다는 얘기. 반면 보안은? 보안 분야에 대한 사용자 경험을 보유한 개발자가 얼마나 될까? 보안 제품에서 발생하는 로그를 분석하면서 제품의 한계를 경험해본 개발자가 얼마나 될까? 결국 제품 개발자와 실제 사용자 사이의 간극이 벌어질 수 밖에 없다.

사용자는 왜 요구하지 않을까? 장비 활용보다는 구축이 훨씬 인정받기 쉬우니까.

자사에는 적합하나 갖추기 어렵고 상급자를 설득하기도 어려운 자체 시스템을 구축하려고 노력하기보다는 그 명성을 의심받지 않을 고급제품을 구입해 쓰려고 하는 성향을 보이게 된다

그렇게 구축된 제품은 사용자의 자극을 받을 일이 없고, 그 상태에서 사용자 역량과 본연의 목적은 영원히 제품 한계에 갇혀버린다. 그래서 사용자 의지가 중요. 좋은 제품도, 나쁜 제품도 결국 사용자가 만든다.

좋은 시나리오는 충분한 분석 경험에서 나온다. 분석 경험은 데이터가 있어야 쌓을 수 있다. 그런데 그 데이터는 어디에 있을까?

관련 글

• 데이터 노가다 실수담
• 데이터 분석이 쉬워지는 비법
• 기술이 쉬워지는 두 가지 기준