지식 그래프로 건초 더미 속 바늘 찾기: Fraud Detection (사기 탐지)

• Machine Learning

편집자 주: 이 프레젠테이션은 다음에서 제공되었습니다.타완다 유잉 at 연결: 클라우드 개발자를 위한 그래프 2021.

저는 Deep Learning Café라는 스타트업에서 Machine Learning 엔지니어로 일하고 있어요. Google Cloud Platform을 사용해서 대부분의 인공 지능 및 Machine Learning 시스템을 클라우드 환경에서 실행하는 일을 담당하고 있죠. 기술, 과학, 그리고 아프리카에 대한 저의 관심을 바탕으로, Neo4j와 AI가 아프리카 대륙이 직면한 복잡한 문제들을 해결할 수 있는 기회를 엿보고 있어요. 그래서 이번에는 저희 회사가 겪었던 사기 문제와 Neo4j가 어떻게 해결책이 되었는지 공유하려고 해요.

문제: 위조품 및 상습범

“매일 수천 개의 위조품이 남아프리카 공화국으로 수입됩니다.”
– 남아프리카 국세청

남아프리카 공화국, 특히 제가 살고 있는 요하네스버그 거리를 걷다 보면 위조품을 마주치지 않기가 더 어려울 정도예요. 그만큼 심각한 문제죠.

저희 고객은 국제 법률 회사의 지적 재산권 변호사인데, 위조품이 포함된 상품을 수입하는 사람이나 회사에 대한 정보가 담긴 문서 데이터베이스를 가지고 있었어요. 고객은 빠르고 안정적으로 상습범을 식별하는 방법을 원했죠. 여러 항구를 통해 똑같은 브랜드를 수입하는 사람들을 말이에요. 2년, 3년, 심지어 그 이상의 기간에 걸쳐 이런 반복 위반자를 추적하는 건 정말 어려운 일이었어요. 새로운 정보가 들어왔을 때, 2년 전의 상습범을 빠르게 파악하는 게 필요했죠.

사용 가능한 데이터

고객은 업무 현장이나 항만 관리, 경찰 보고서 등에서 매일 쏟아지는 100개 이상의 문서에서 핵심 정보를 식별해야 했어요. 이 문서에는 수입업자의 이름, 주소, 전화번호, 이메일 주소, 그리고 가장 중요한 건 그들이 국내로 들여온 브랜드가 포함되어 있었죠. 왜냐하면 동일한 브랜드를 두 번 이상 수입해야 반복 위반자로 간주되기 때문이에요.

변호사가 읽어내기에는 문서의 양이 너무 방대했고, 데이터도 구조화되어 있지 않았어요. 누가 상습범인지 기억할 수는 있겠지만, 수년에 걸쳐 수천 개의 문서에 기록되기 시작하면 상습범을 식별하는 건 거의 불가능해지죠. 게다가 회사를 대신해서 수입하는 사람이 여러 명일 경우에는 더 어려워져요. 정확히 동일한 전화번호, 유사한 이메일 주소, 혹은 같은 주소를 포함하는 데이터처럼 공통점을 찾아야 하거든요. 하지만 사람이 이 모든 정보를 분류하는 건 너무 힘든 일이에요.

제안된 솔루션

고객은 수기 문서와 전자 문서를 즉시 처리해서 재범자의 단서를 식별할 수 있는 방법을 원했어요. 그리고 우리가 상습범을 식별하는 데 도움이 될 만한 흥미로운 내용을 발견하면, 문제를 더 자세히 조사하고 잠재적으로 상습범을 체포하는 데 도움이 되는 알림을 이메일로 받고 싶어 했죠. 이게 바로 저희가 생각한 이상적인 솔루션이었어요. 위 이미지에서 제안된 솔루션을 보면 간단해 보이지만, 실제로 시작하고 나면 제대로 실행하는 게 훨씬 더 복잡하다는 걸 곧 알게 되었죠. 결국 Neo4j가 이 문제를 단순화하고 해결하는 데 큰 역할을 했어요.

올바른 데이터베이스 선택

당시 저희 팀은 Google Cloud Platform과 Python에 익숙한 개발자 3명으로 구성되어 있었기 때문에, 문제를 해결하려면 저희가 가진 기술을 활용해야 했어요. 미리 결정된 기술 중에서 가장 어려운 부분은 이 특정 상황에 적합한 데이터베이스를 찾는 거였죠.

그 당시 스타트업에서 무슨 일이 일어나고 있었는지 배경 설명을 좀 드리자면, 저는 그때 팀에서 경험이 가장 적은 멤버였어요. 업계 경험이 더 많은 두 명의 수석 엔지니어가 SQL 데이터베이스나 문서 데이터베이스를 살펴보자고 제안했죠. 하지만 저는 이 문제 때문에 그런 솔루션 중 하나를 구현하기 어려울 거라는 느낌을 받았어요.

저는 먼저 SQL 데이터베이스를 살펴봤어요. 이전에도 사용해 본 적이 있었거든요. SQL은 관계형 데이터베이스이기 때문에 관계형 데이터를 다루는 데 아주 좋지만, 몇 가지 어려움이 있었어요. 주소나 중요한 이름 같은 엔터티에 대한 스키마를 설정하는 방법을 결정하는 데 어려움이 있었죠. 예를 들어, 해당 법인을 확장하기로 결정했거나 차량 번호판 번호나 ID 번호가 반복 위반자를 식별하는 데 중요하다는 걸 깨닫게 되면 어떻게 될까요? 경고를 통해 해당 정보를 얻으려면 테이블의 스키마를 다시 작업하고 모든 **쿼리**를 다시 작성해야 한다는 의미가 되죠. 구현은 빠르겠지만 유지 관리에 문제가 생길 거예요. 저희는 고객 측에서 유지 관리할 수 있는 솔루션이 필요했거든요.

다음으로 문서 데이터베이스를 살펴봤는데, 좀 더 유연성이 있었어요. 일반적으로 MongoDB 같은 걸 살펴봤는데, 이 데이터베이스가 다양한 문서의 **스키마**를 식별하고 나중에 데이터를 쉽게 결합하는 측면에서 얼마나 유연한지에 매료되었죠. 유연성 측면에서는 매력적이었지만, 가장 큰 문제는 정보를 얻을 수 있는 **쿼리**를 작성하거나 생성하는 작업이 매우 복잡해진다는 거였어요. 본질적으로 문서 데이터베이스는 관계 유지를 위해 만들어진 게 아니거든요. 데이터베이스의 목적 자체가 아니니까요. 단일 컬렉션을 매우 빠르게 검색한 다음, **쿼리**와 관련된 것으로 식별된 문서에서 필요한 정보를 추출하도록 구축되었죠. 서로 다른 컬렉션 사이에 링크를 만들고, 이 모든 엔터티를 사용해서 반복 위반자를 신속하게 식별해야 하는 순간 **쿼리**가 완전히 복잡해졌어요. 장기적으로 저희를 괴롭힐 관계형 기능을 가져오기 위해 많은 코드를 작성해야 했죠. 버그가 들어올 기회를 만들 수 있는 이 모든 코드를 유지 관리해야 할 거예요. 로펌이 발전하거나 범죄자가 따라잡아 시스템을 속이는 방법을 찾아내더라도 이 문제의 역동적이고 변화하는 성격을 실제로 해결할 수 없는 상황에 놓일 수도 있었죠.

왜 Neo4j인가?

당시 Neo4j에 대한 저의 배경은 학계에서 시작됐어요. 강사님이 저희가 만들고 있는 모델 앱의 데이터베이스로 Neo4j를 써보라고 강력하게 추천했을 때였죠. 그때 처음으로 SQL과 Neo4j를 전문적으로 사용하게 됐어요. 저는 두 가지를 처음부터 배우면서 어떤 게 더 좋은 솔루션인지 비교하고 있었는데요. 제가 알아낸 건 Neo4j가 관련성이 높은 데이터를 처리할 때 정말 직관적이라는 거였어요. Cypher 쿼리도 정말 직관적이고요. SQL 쿼리와 Cypher 쿼리를 동시에 배우고 있었는데, Cypher를 배우고 Neo4j에서 원하는 쿼리를 얻는 게 훨씬 쉽다는 걸 금방 알게 됐어요. 그때 Neo4j에 깊은 인상을 받았고, 이게 바로 우리가 찾던 솔루션이라는 걸 깨달았죠.

Neo4j는 제가 보기에도 정말 강력한 도구였어요. 다양한 용도로 활용할 수 있는 잠재력이 보였거든요. 적응력도 뛰어나 보였고요. 시스템이 계속 작동하는 방식에 영향을 주는 그래프 스키마를 정의해야 했지만, 틀에 갇힌다는 느낌은 전혀 없었어요. 요구 사항이나 고객의 니즈가 바뀌어도 다양한 관계, 엔티티, 또는 Node를 추가해서 쿼리를 조정할 수 있는 여지가 충분했으니까요.

전반적으로 Neo4j를 사용하면서 가장 좋았던 점 중 하나는 그래프가 시각적으로 얼마나 매력적인지에 대한 고객들의 만족도였어요. 단순히 테이블과 열을 보는 게 아니라, 데이터를 그래프 형식으로 시각화해서 보여주니까 고객들이 정말 직관적으로 이해하고 좋아하더라고요. 그래프를 보면서 상습범과 그들이 언급된 모든 문서를 쉽게 식별할 수 있다는 점을 특히 마음에 들어 했어요. 한눈에 여러 문서와 개체 유형에 걸쳐 연결된 잠재적인 범죄 조직을 찾을 수 있다는 것도요. 저희는 이미 Neo4j가 우리가 사용하고 싶은 솔루션이라고 확신했고, 고객들도 마찬가지였죠.

구현

마지막으로, 실제로 Neo4j를 어떻게 구현했는지 공유할게요. 위에 있는 이미지는 신디케이트를 식별하는 데 사용했던 그래프 구조인데요. 이미지가 선명하진 않지만, 여기서 주목할 점은 저희가 한 가지 유형의 관계만 사용했다는 거예요. 앞으로 어떻게 진화할지, 문제가 어떻게 바뀔지에 대해 너무 많은 가정을 하고 싶지 않았기 때문에, 가장 좋은 결과를 얻을 수 있는 가장 간단한 형태를 선택한 거죠. 그래서 관계 유형을 하나만 사용하는 아이디어를 택했어요. 기본적으로 프로세스는 특정 문서를 검토하고, 그 문서 내에서 식별된 엔티티를 추출한 다음, 이 브랜드가 이 문서에서 언급됐다거나, 이 사람이 이 문서에서 언급됐다는 식으로 Graph Database 측에서 관계를 구축하는 방식이었어요.

결과적으로, 그래프를 통해 데이터베이스에 이미 있는 엔티티를 빠르게 식별하고, 이 엔티티가 언급된 다른 위치와 해당 문서에서 언급될 수 있는 다른 사람을 알아내는 게 정말 쉬워졌어요. 해당 문서에 언급된 다른 이메일 주소일 수도 있고, 관심 있는 다른 엔티티일 수도 있고요. 이렇게 간단한 구조 덕분에 쿼리 구현도 정말 간단했죠.

저희는 고객에게 솔루션을 빠르게 제공할 수 있었고, 고객도 정말 만족했어요. 저희처럼 고객들도 다른 요구 사항을 가지고 돌아오더라도 문제없이 처리된다는 점을 좋아했고요. 진행하면서 그래프의 구조를 변경할 수 있었고, 이런 신디케이트가 어떻게 작동하는지, 어떤 종류의 정보를 추적해야 하는지에 대해 더 많이 이해하기 시작했죠.

저희 고객은 저희가 구축한 Knowledge Graph를 계속해서 구축할 수 있어요. 저희는 인공지능과 기본적인 Natural Language Processing을 사용해서 관련성이 있는 모든 항목을 찾고, 문서에서 모든 항목을 추출해서 이 기본적인 Knowledge Graph를 구축했죠. 그런 다음 고객에게 수동으로 주석을 추가할 수 있는 도구를 제공했어요. 이게 바로 상습범을 추가하는 아이디어의 배경이에요. 문서에 반드시 추출되거나 표시될 필요는 없지만, 고객이 반복 위반자를 명확하게 식별하고 이들이 신디케이트 내에서 실제로 어떻게 작동하는지 돕는 데 관련된 특정 정보를 추가하는 거죠.

이 덕분에 기존 Knowledge Graph 위에 훨씬 더 복잡하고 강력한 쿼리를 구축하고, 입력하는 수동 데이터를 활용하고, 고객의 지식 기반을 지속적으로 확장할 수 있다는 아이디어가 가능해졌어요. 이걸 통해 더 복잡한 쿼리를 실행하고 반복 위반자가 누구인지 더 효율적이고 안정적으로 식별할 수 있게 된 거죠.

결론

저희의 Knowledge Graph 사용 사례가 여러분에게 도움이 되고, Graph Database를 얼마나 쉽게 구현할 수 있는지에 대한 아이디어를 얻으셨기를 바라요. 마지막으로 말씀드리고 싶은 점은 Neo4j 솔루션을 볼 때 가장 큰 문제는 '이걸 클라우드 환경에서 어떻게 실제로 작동시킬 수 있을까?'였는데요. Neo4j AuraDB가 이 문제 해결에 큰 도움이 됐기 때문에, 해당 솔루션을 한번 살펴보시는 걸 추천드려요. 다시 한번, 저희의 경험이 여러분에게 몇 가지 아이디어를 주고, 그래프를 시작하는 게 얼마나 쉬운지 보여드렸기를 바랍니다.

클라우드에서 Neo4j의 Graph Database에 평생 무료로 액세스할 수 있다는 걸 알고 계셨나요?
지금 가입하고 Neo4j AuraDB 무료 버전을 시작해보세요!

• Deep Learning 카페
• GCP
• Machine Learning
• 건초 더미 속의 바늘
• NoSQL
• 남아프리카
• SQL

---

에이치시스템즈의 LogTree는 Neo4j 기반 GraphRAG 플랫폼으로, 데이터를 자동으로 지식그래프화하고 자연어 질의로 즉시 답을 제공합니다.

👉 에이치시스템즈 홈페이지