배경
사전적으로 지표(indicator)란, 특정 이벤트와 관련된 변수 또는 관찰 결과를 의미한다.
A라는 이벤트 이후에 B가 늘 관찰된다면, B는 A의 지표라고 말할 수 있다.
우리가 개발하고 있는 이상 탐지 솔루션은 게임 내부의 이상을 관찰하기 위해 수많은 지표를 집계(ETL)한다.
예를들어 과도한 재화의 획득 이라는 이벤트를 관찰하기 위해, 상위 1% 유저 획득량이라는 지표를 집계한다.
문제
문제는 이상 이벤트의 유형이 너무나도 광범위하고, 이를 관찰하기 위한 지표가 계속 늘어남에 따라 발생했다.
지표의 집계 과정은 단순히 보면 (무엇을? 어떻게?)로 설명할 수 있는데,
ETL 관점에서 보면 무엇을은 Extract 대상이 되는 데이터, 어떻게는 Transform 방법론이라 볼 수 있다.
문제는 지표의 Transform 방식이 늘어남에 따라 각 지표를 구분 지어 부르는 것이 어려워진 것이다.
목표
여러 Transform을 일관된 패턴으로 구분할 수 있는. 직관적으로 이해되는 Naming Convention을 고안한다.
Transform Naming Convention
Concept: Transform Name = First Name + Last Name
- First Name(이름)은 가변적인, 현상을 해석하는 표현이다.
- 관측하고자 하는 추상적인 이벤트를 의미한다.
- 예를들어
과도한 횟수의 반복,과도한 수준의 합계,기획에서 벗어난 반복등등
- Last Name(성)은 고정된, 코드를 표현하는 규칙이다.
- 실제 코드에서 작동하는 집계 함수들의 나열이다.
- 예를들어
[계정별 획득 횟수][상위 1% 필터링][아이템별 평균]와 같이 실제 코드를 서술한다.
이렇게 지표의 이름을 해석적인 부분과 고정된 부분으로 나누는 이유는 이름이 필요한 이유가 (내부/외부)에 따라 극단적으로 다르기 때문이다. 추상적인 First Name은 외부에서 지표의 소비자에게 지표를 설명하는데 사용된다. 소비자에게 중요한 것은 오직 관측 대상이 되는 이벤트이기 때문이다. 온도라는 이벤트를 관측하기 위해 우리가 온도계 안에 수은의 높이라는 지표를 관측한다. 온도계를 소비하는 사람은 수은의 높이가 변하는 메커니즘에는 전혀 관심이 없다. 그래서 온도가 올랐어? 온도가 내려갔어? 소비자는 관측 대상에만 관심이 있을 뿐이다.
그러나 내부의 작업자들에게는 고정된 Last Name이 절실히 필요하다. 기존의 지표들이 미처 관측하지 못하는 회색 영역이 무한히 있기 때문에, 새로운 집계 방식은 지속해서 개발된다. 그런데 앞서서 다른 작업자가 개발해놓은 집계 방식들을 구체적으로 파악하지 않는다면 노하우가 쌓이지 못하고 중복 작업이 발생한다. 따라서 실제로 Line by line으로 작성된 코드를 살펴볼 필요 없이, 일관된 규칙으로 기존의 작업물들이 표현된 Last Name이 있는 것은 굉장히 중요하다.
물론 Last Name과 달리 First Name은 추상적이고 주관적인 영역이기 때문에 쉽게 발산할 수 있다. 따라서 신규로 새로운 Last Name이 개발될 때마다 적절한 First Name이 이미 없는지, 기존의 것을 조금 변경해서 커버할 수 있는지, 새로 발급한다면 어떻게 부를 것인지 꾸준한 리뷰와 관리가 필요하다. 하지만 이는 고객이 지표를 소비함에 있어 사용성을 결정하는 치명적인 부분이고, 지표의 가이드를 업데이트 한다는 측면에서 지속적인 운영 업무의 일환으로 가져가는 것은 당연하다고 생각한다.