LINE DEVELOPER DAY 2021에서 이주홍 님이 발표하신 SHIELD: LINE Timeline을 어뷰저로부터 보호하기 세션 내용을 옮긴 글입니다. 참고로 LINE Timeline은 현재 LINE VOOM으로 이름이 변경됐습니다.
들어가며
안녕하세요. Shield Dev 팀 이주홍입니다. 이번 글에서는 어뷰저(abuser)로부터 LINE VOOM(구 Timeline)을 보호하고 있는 SHIELD를 소개하겠습니다. SHIELD는 어뷰징 검출과 NLP를 이용한 텍스트 필터링, 텍스트 필터 에이전트, 어뷰징 페널티 히스토리 관리 기능으로 구성된 솔루션으로 2019년 2월에 LINE VOOM에서 코멘트를 이용한 어뷰저를 막기 위해 개발하기 시작했습니다. 2019년 3월, LINE VOOM에 첫 번째 모델을 적용했고, 2020년에는 스토리와 생일 축하 카드에 모델을 추가해 다양한 형태의 어뷰저를 검출하고 있습니다. 앞으로도 LINE의 튼튼한 방패가 되기 위해 지속적으로 모델을 추가할 계획입니다.
글은 어뷰징을 검출해야 하는 이유와 어뷰징 사례를 소개하고, SHIELD에서 어떻게 어뷰저를 찾고 있는지 설명한 뒤, SHIELD로 검출한 어뷰저 현황과 현재 진행하고 있는 사항을 공유하는 순서로 진행하겠습니다.
어뷰징을 검출해야 하는 이유와 어뷰징 사례
어뷰징을 왜 검출해야 할까요? 사용자는 자신이 보고 싶은 것만 보면서 편안하게 서비스를 사용하고 싶어 합니다. 무의미한 광고나 의미 없는 댓글, 욕설과 같이 자신을 불쾌하게 만드는 내용을 보고 싶어 하지 않습니다. 만약 LINE을 사용하면서 원치 않게 이런 내용을 접하고 부정적인 감정이 든다면 LINE 사용자가 줄어들 수 있겠죠. 따라서 서비스를 제공할 때 이런 내용을 제거해 사용자가 기분 좋은 감정을 유지할 수 있도록 만들어야 합니다.
실제로 코멘트를 어뷰징에 이용한 사례를 살펴보겠습니다. 먼저 한 시간 동안 2,000번 이상의 코멘트를 생성한 사용자가 있었습니다. 아마 광고가 목적이었겠죠. 두 번째로 단순한 숫자 세기 코멘트를 짧은 시간 동안 여러 개 남긴 경우가 있었습니다. 예를 들어 1부터 100까지의 숫자를 코멘트로 하나씩 남기는 경우입니다. 의도는 알 수 없지만 생각보다 많이 발생하는 사례입니다. 세 번째로 내용을 전혀 알 수 없는 무의미한 문장을 짧은 시간 동안 아무렇게나 여러 개 남기는 경우입니다. 이 역시 의도는 알 수 없지만 어뷰징 사례라고 할 수 있습니다.
SHIELD에서 어뷰저를 검출하는 방식
그럼 SHIELD에서 어뷰저를 검출하기 위해 어떤 방법을 사용하고 있는지 소개하겠습니다.
SHIELD의 목표 아키텍처
아래는 현재 구축해 나가고 있는 SHIELD의 목표 아키텍처를 나타낸 그림입니다.
가장 아래에 LINE에 쌓이는 여러 로그 데이터를 실시간으로 처리할 수 있는 레이어를 두고, 그 위에 중간 과정의 데이터를 쌓는 데이터 스토리지를 배치한 뒤, 그 위에 데이터 분석 레이어와 이상 검출(anomaly detection) 레이어를 올리는 것을 목표로 개발하고 있습니다. 현재 데이터 인프라와 규칙 기반 어뷰징 검출(rule base abusing detection), ML 기반 어뷰징 검출(machine learning base abusing detection) 컴포넌트가 작동하고 있습니다. 향후 애그리게이션(aggregation) 모듈을 통해 애그리게이션 테이블을 생성해서 ML 모델에서 사용할 계획입니다.
SHIELD의 작동 흐름
SHIELD는 규칙 기반 모델과 ML 기반 모델, 두 가지 모델이 있습니다. 두 모델 모두 워크플로는 비슷합니다.
각 방식을 좀 더 자세히 살펴보겠습니다.
규칙 기반 모델
먼저 규칙 기반은 서비스 팀의 요청으로 시작합니다. 요청이 들어오면 해당 내용을 분석해서 분석 결과를 공유합니다. 공유 과정에서 한계점(threshold)을 설정하는 튜닝 작업을 거치며, 튜닝 과정에서 해당 규칙을 폐기할 수도 있습니다. 만약 폐기하지 않는다면 어뷰저 징계로 이어집니다.
규칙 기반 모델은 현재 LINE VOOM과 스토리, 생일 축하 카드 서비스에서 활동하는 어뷰저를 검출하고 있습니다. VOOM에서는 16개의 케이스를 검출하고 있으며, 스토리와 생일 축하 카드 서비스에서는 각각 하나의 케이스를 검출하고 있습니다.
ML 기반 모델
ML 기반은 외부 요청이 아닌 내부 연구 활동으로 시작합니다. 알고리즘을 조사하고 구현한 뒤 모니터링 팀과 협업해 검증하고 튜닝합니다. 이후 과정은 규칙 기반과 동일합니다. 규칙 기반 모델과 다른 점이 있다면 ML 기반은 경고(alert) 시스템에서도 사용한다는 점입니다. 경고 시스템은 징계가 아니라 경고를 위한 시스템으로 현재까지는 분석 리포트만 발행하고 있습니다. 추후 경고 시스템에서 검출한 이상 사례를 분석해 일정한 패턴을 찾아 징계로 연동하는 것이 목적입니다.
ML 기반 모델에는 자체 개발한 Density_based 모델과 DBSCAN, Autoencoder, Isolation forest 모델을 구현해 놓았습니다. Density_based와 DBSCAN은 징계에 사용하고 있고, Autoencoder 모델은 경고 시스템에서 사용하고 있습니다. 추후 Isolation forest 모델을 경고 시스템에 적용할 예정입니다.
Density_based 모델
Density_based 모델은 앞서 말씀드린 대로 팀에서 자체 개발한 모델로, 특정 시간대에 발생한 사용자들의 사용량에 따라 어뷰저를 검출하는 모델입니다. 표준 편차를 이용해 셀을 만들어서 각 셀 안에 포함된 사용자의 수에 따라 셀이 정상인지 아닌지를 판단합니다. 비정상 셀이라도 주변에 정상 셀이 특정 수 이상 존재한다면 정상 셀로 변경됩니다. 이해를 돕기 위해 아래 그림과 함께 설명하겠습니다.
위 그림에서 점은 사용자를 나타내며 초록색 점은 정상, 빨간색 점은 비정상 사용자를 의미합니다. 연두색으로 칠해진 셀은 정상 셀이며, 오른쪽 그림의 노란 셀처럼 비정상 셀이라도 세 개 이상의 정상 셀로 둘러싸여 있다면 정상 셀로 변경되면서 해당 셀에 포함돼 있던 사용자 역시 정상 사용자로 변경됩니다.
Density_based 모델은 규칙을 찾아내서 그 규칙에 적용되기 직전까지만 어뷰징하는 지능적 어뷰저를 막기 위해 사용합니다. 아래 왼쪽 그림에서 보이듯 일반 사용자(초록색 원)는 하나의 클러스터처럼 모여 있지만 어뷰저는 따로 떨어져 있는데요. 이때 어뷰저 중에서는 규칙(빨간 선)을 명백하게 넘어서는 어뷰저가 있고, 규칙을 벗어나진 않지만 일반 사용자와는 떨어져 중간에 위치하는 어뷰저가 있습니다. 가운데 그림은 이를 히스토그램으로 표현한 것입니다.
위 오른쪽 그림은 규칙(빨간 선)을 넘어서지 않는 경계 안에서 사용량을 조절하며 어뷰징을 하는 어뷰저를 나타낸 것으로, Density_based 모델은 이런 어뷰저를 검출하기 위해 사용합니다.
DBSCAN
DBSCAN은 밀도 기반의 클러스터링 알고리즘입니다. 다른 클러스터링 알고리즘과는 다르게 클러스터의 수를 미리 설정할 필요가 없습니다. 다양한 모양의 클러스터를 찾을 수 있고 클러스터에 해당하지 않는 이상을 쉽게 검출할 수 있습니다.
DBSCAN에서는 이상을 검출하기 위해 epsilon(기준점으로부터의 거리)과 minPts(epsilon 값을 반경으로 그린 원 안의 점의 수), 두 가지 하이퍼 파라미터를 사용합니다. 아래 왼쪽 그림과 같이 어떤 점을 기준으로 삼고 epsilon 값을 반경으로 원을 그려서 그 원 안에 minPts 이상의 점이 포함되면 그 점은 코어 포인트(core point)가 됩니다. epsilon 값으로 원을 그렸을 때 그 안에 minPts 이상의 점이 포함되지는 않지만, 어떤 코어 포인트에서 그린 원 안에 포함되는 점은 보더 포인트(border point)라고 부릅니다. 마지막으로 어떤 기준도 만족하지 못하는 점은 노이즈 포인트(noise point)라고 부르며, DBSCAN에서는 이 노이즈 포인트를 이상으로 검출합니다.
DBSCAN 모델과 Density_based 모델로 어뷰저를 검출하면 결과는 비슷합니다. 다만 Density_based 모델에서 표준편차를 사용하다 보니 어뷰저를 놓치는 경우가 가끔 발생했습니다. 특히 사용량이 적은 새벽 시간대에는 표준편차가 커지면서 셀의 크기가 커지고, 그에 따라 셀 안에 포함되는 사용자 수가 많아지면서 어뷰저를 어뷰저로 검출하지 못하는 경우가 발생했습니다. 이를 보완하기 위해 사용자를 클러스터로 묶어 처리하는 DBSCAN을 추가했습니다.
Autoencoder
Autoencoder는 인코더와 디코더로 구성되는 모델입니다. 입력을 넣으면 인코더와 디코더를 거치면서 입력과 비슷한 형태의 출력이 나오는데 이때 입력과 출력의 차가 크면 이상으로 판단합니다. 구현이 쉽고, 이상 검출을 직관적으로 할 수 있습니다. 아래 그림과 같이 입력을 초록색으로 설정하고 Autoencoder에 넣으면 인코더와 디코더를 거치면서 입력과 비슷한 연두색 출력이 나옵니다. 같은 모델에 초록색 입력이 아닌 빨간색 입력을 넣으면 노란색이 출력되면서 입력과 출력의 격차가 커집니다. 이런 특성을 이상 검출에 이용합니다.
어뷰저가 어떤 행동을 할지 알 수 없는 상황에서 서비스 팀의 요청이 지연된다면 그 사이에 많은 어뷰징이 발생하면서 사용자의 편의를 해칠 수 있습니다. 이에 어뷰징을 미리 검출하기 위해 Autoencoder를 이용한 경고를 도입했습니다.
Isolation forest
Isolation forest는 밀도나 거리를 사용하지 않고 결정 트리(decision tree) 기반으로 데이터를 랜덤하게 나눠 고립시키는 방법을 사용합니다. 이때 이상 데이터는 일반 데이터에 비해 양이 적기 때문에 쉽고 빠르게 고립되는 특징이 있습니다. Isolation forest는 높은 차원의 데이터에 적용하기 좋습니다.
아래 오른쪽 그림은 일반 데이터에서 이상 데이터가 고립될 때까지 분할하는 모습이고, 왼쪽은 이상 데이터가 고립되는 모습입니다. 일반 데이터는 밀집돼 있어 하나를 고립시키기 위해 6번을 나눠야 했지만 이상 데이터는 3번 만에 고립되는 것을 볼 수 있습니다.
특정 이상 행동에 국한되지 않고 전반적으로 주요 이상 행동의 사용 패턴을 찾아내기 위해 Isolation forest을 경고에 적용할 예정입니다.
인프라 히스토리
다음으로 어뷰징을 검출하기 위해 로그 스트림 인프라를 변경한 히스토리를 공유하겠습니다. 처음(2019년)에는 LINE 공통 DW(data warehouse)를 사용하다가 실시간에 가까운 검출을 위해 2020년에 Elastic Search를 도입했고, 2021년에 다시 Clickhouse로 변경해 사용하고 있습니다.
LINE 공통 DW는 대부분의 LINE 로그가 저장돼 있는 곳으로 사용자들이 편리하게 사용할 수 있습니다. Elastic Search는 데이터의 저장부터 시각화까지 쉽게 구현할 수 있는 검색 엔진입니다. Clickhouse는 칼럼 기반 DB로 빠르게 응답할 수 있다는 것이 특징입니다.
아래는 각 인프라의 장단점을 정리한 내용입니다.
LINE 공통 DW의 경우 데이터의 다양성과 지속성에서 장점이 있지만, 데이터를 적재하기까지 시간이 오래 걸리며 다른 두 인프라에 비해 응답 속도가 느리다는 단점이 있습니다. Elastic Search는 빠른 적재 속도와 검색 속도가 장점이나 대용량 데이터를 종합(aggregation)하기가 어렵다는 단점이 있습니다. Clickhouse는 빠른 응답 속도와 쉬운 종합(aggregation)이 장점이지만 적용 사례를 비롯한 참고 자료가 부족하다는 단점이 있습니다.
현재 Clickhouse를 사용하는 이유는, 앞서 설명한 장단점 때문이라기보다는 그동안 사용 목적에 맞지 않는 인프라를 사용하다가 이제 그 목적에 맞게 변경했다고 하는 게 정확한 설명입니다. LINE 공통 DW는 보통 실시간 처리보다는 안정적으로 데이터를 분석하기 위해 사용합니다. Elastic Search는 말 그대로 검색에서 탁월한 성능을 보이기 때문에 뛰어난 검색 능력을 활용한 분석에 사용하며, 실제 상용 제품에서는 다양한 이상 검출 및 분석 툴도 제공하고 있는데요. 사내에서 사용하는 버전에서는 그 기능을 활용할 수 없었고 처리 방식이 SHIELD에서 추구했던 방식과 맞지 않았습니다. Clickhouse는 앞서 설명한 장점과 더불어 SHIELD에서 처리하고자 하는 방식과 잘 맞아서 도입했고, 현재 다양하게 테스트해 보고 있습니다.
SHIELD 검출 결과
아래는 2021년 상반기에 LINE VOOM에서 검출한 어뷰저 결과 그래프입니다. 2월과 3월에는 규칙 기반 모델로 검출한 사례가 많았고, 6월에는 ML 기반 모델로 검출한 사례가 많았습니다. 결과에서 나타나듯 규칙 기반 모델과 ML 기반 모델이 서로의 단점을 보완하며 LINE을 더욱 안전하게 보호하고 있습니다.
아래는 스토리와 생일 축하 카드에서 어뷰징을 검출한 결과입니다. 아무래도 두 서비스는 LINE VOOM보다 사용자가 적기 때문에 어뷰징 검출 사례도 적습니다.
향후 계획
앞으로 좀 더 많은 규칙과 ML 기반 모델을 만들어서 어뷰저 없는 LINE을 만들기 위해 노력할 것입니다. 또한 사용하기 편하고 보기 좋은 경고 시스템을 구축해 사용 편의성을 높일 계획이며, 부정적인 사용자 행동에 대한 점수 시스템을 만들어서 LINE에서 좋지 못한 행동을 하는 사용자들을 좀 더 쉽게 찾을 수 있도록 개선할 예정입니다.
SHIELD의 슬로건은 'Make brighter green for LINE'입니다. 앞으로 좀 더 밝고 쾌적한 LINE을 만들기 위해 끊임없이 노력하겠습니다. 긴 글 읽어주셔서 감사합니다.