엔터프라이즈 데이터를 지식 그래프로 관리하면 데이터는 (논리적으로) 중앙화·큐레이션·맥락화된다. 지식 그래프에서는 흥미로운 비즈니스 이벤트에서 비롯된 패턴을 채굴할 수 있다 — 패턴은 비즈니스에 대한 역사적 통찰을 주지만, 앞을 내다보는 데도 쓰인다. 이 장은 단순한 패턴 매칭에서 출발해 지식 그래프의 패턴으로 사기를 멈추고 더 나은 팀을 꾸리는 법, 그리고 그래프 데이터 과학으로 패턴 탐지를 증강하는 법을 다룬다.
온라인 사기는 유비쿼터스 컴퓨터 시스템 시대의 광범위하고 악성적인 문제다. 이 시스템들은 개인 삶의 가장 중요한 측면들을 담고 현대 비즈니스의 생명줄이므로, 개인이나 조직을 속이려는 범죄자에게 유혹적인 표적이다. 그 유혹의 수준은 눈이 시릴 정도다.
비싼 문제이고 지속적인 군비 경쟁을 요구한다. 그래서 사기 탐지의 한계적 개선조차 절대 달러 기준으로는 거대한 이득을 가져온다. 다행히 지식 그래프는 사기꾼에 맞선 방어를 구축하기에 훌륭한 플랫폼이다.
신용카드를 예로 들자. 거래 가치가 거대하고 카드·제공자 전반의 거래량이 사기꾼이 숨어 돈을 빨아낼 엄폐물이 되어 준다. 그림 10-1의 최근 구매 이력에는 사기 의심으로 조회된 거래와 거절된 거래까지 있다 — 결제 시스템은 불완전하고 인간 행동은 변덕스러워 누구에게나 가끔 일어나는 일이다. 정말로 수천 달러짜리 노트북을 사고 싶을 때도 있고, 휴가지라 외화 결제를 할 때도 있고, 카드를 도둑맞아 범죄자가 무단 사용 중일 때도 있다. 가용한 정보만으로는 좋은 고객인지, 곤경에 처한 고객인지, 사기꾼인지 알기 어렵다.
전통적으로 금융 회사들은 규칙 기반 전략을 썼다 — 특정 단어·계좌·위치를 검색해 위험 점수를 매기고, 알림을 사기 분석가에게 보내 수동 검토하게 한다. 이 해법은 느리고, 비싸고, 경직적이다. 반대로 지식 그래프로 고객의 더 넓은 연결 맥락을 이해하면 훨씬 많은 통찰을 규모 있게 얻는다.
그림 10-1의 테이블 데이터를 지식 그래프에 적재하는 것이 가치를 얻는 첫걸음이다. 선택된 그래프 데이터
모델(그림 10-2)에서는 고유 카드 번호를 가진 신용카드가 각 서브그래프의 중심이다. 카드로
(WITH) 이루어진 구매들이 둘러싸고, 각 Purchase는 NEXT
관계로 구매 이력을 만든다. 고객은 ACCOUNT_HOLDER로 카드에 연결되고, 주소에
LIVES_AT, 전화번호를 OWNS한다. 고객들은 각자 분리된
서브그래프에 존재하며 주소·전화번호를 서로 공유하지 않는다 — 그것이 모델의 기대다.
한 고객을 확대해 보는 것만으로는 지식 그래프를 검증할 수 없고, 모든 고객에 대해 그러기는 시간이 너무 든다. 완전히 알지 못하는 데이터셋을 파악하는 한 방법은 일반적 성질을 검증하는 것이다. 그래프의 사람 수를 질의하니 2,399,999개의 Person 노드가 있다(그림 10-3). 모델이 그림 10-2처럼 규칙적이라면 분리 서브그래프당 하나씩, 정확히 2,399,999개의 커뮤니티가 있어야 한다. 6장에서 본 커뮤니티 탐지 알고리즘으로 확인할 수 있다.
CALL gds.graph.project( 'fraud-wcc', ['Person','Phone','Address'], ['LIVES_AT','OWNS'] ) // 속성 데이터나 다른 노드·관계는 넣지 않는다. // 준비는 아주 짧은 시간이면 끝난다
CALL gds.louvain.stream('fraud-wcc') YIELD nodeId, communityId WITH gds.util.asNode(nodeId) AS person, communityId SET person.communityId = communityId
기대대로라면 2,399,999명이 분리 서브그래프에 있어 2,399,999개의 커뮤니티가 되어야 한다. 그런데 그래프에는 1,803,467개의 커뮤니티 식별자만 있다(그림 10-4) — 약 50만 개가 부족하다. 이것이 말해 주는 바는 어떤 커뮤니티들은 한 명 이상을 담고 있다는 것이다. 그 커뮤니티들은 무해할 수도, 아닐 수도 있다 — 더 알아볼 가치가 있다.
무슨 일이 벌어지는지 이해하려면 그래프를 샘플링해야 한다. 둘 이상의 Person 노드를 가진 커뮤니티를 파고드는 질의는 쉽게 만든다 — 전체 Person 수를 세고, 깊이 2~4의 Person 간 경로를 매치하여(작고 얌전한 서브그래프는 배제), 난수로 포함 여부를 결정해 전체가 아닌 샘플을 얻는다.
MATCH (:Person) WITH count(*) AS count MATCH (a:Person)-[*2..4]-(b:Person) WHERE rand() < 10.0/count RETURN a
실행 결과(그림 10-5)에는 서로 다르고 분리된 두 서브그래프가 나온다 — 둘 다 "전화와 카드를 소유하고 한 주소에 혼자 사는 한 사람"이라는 흔한 패턴과 사뭇 다르다. 그런데 이 패턴들이 사기일까? 여기에는 최소한 판단을 부트스트랩할 도메인 전문성(SME)이 필요하다 — 예컨대 분석가는 짧은 연쇄 Uber 승차나 고액 유사 거래의 버스트가 도난·복제 카드(또는 카드를 담은 전화)를 시사함을 안다.
카드 절도는 (사기꾼에게 동정은 필요 없지만) 스트레스가 심할 것이다 — 정당한 소유자가 곧 분실·침해를 알아채고 빠르게, 어쩌면 도둑질이 일어나기도 전에 취소한다. 범죄자 입장에서는 카드(또는 당좌대월이 있는 은행 계좌 같은 신용 한도)를 선의로 소유하는 편이 훨씬 낫다 — 시간을 들여 사기를 계획하고 수확을 극대화할 수 있다. 계좌를 정상적으로 운영하기만 하면 종종 더 높은 대출 한도로 보상받는다. 이것이 최종 사기의 이득을 수직으로 키운다. 나아가 설득력 있는 가짜 신원을 여럿 만들어 다수의 신용 한도에 접근하면 범죄를 수평으로 확장할 수 있다 — 그리고 대규모 사기를 저지를 때까지 정상 운영한다.
이 사기-링 패턴은 종래의 데이터 기술로는 포착하기 어렵지만 지식 그래프에서는 훨씬 쉬워진다 — 패턴이 반복된다: Person에서 공유 PhoneNumber를 거쳐 다른 Person으로, 공유 Address를 거쳐 다른 Person으로, 다시 공유 PhoneNumber로… 전체 사기 네트워크를 아우른다(그림 10-6).
CALL { MATCH ring=(p1:Person)-[:OWNS|LIVES_AT*5..]-(p2:Person) WHERE p1<>p2 RETURN ring } IN TRANSACTIONS OF 100 ROWS RETURN ring // 깊이 5 이상의 OWNS|LIVES_AT 경로. // p1<>p2 술어는 경로가 자신을 넘지 않게 해 // 사이클을 배제한다 — 링(또는 링 안의 링)을 // 찾으려면 그 술어를 빼면 된다. // IN TRANSACTIONS OF 100 ROWS는 효율적 실행을 // 위한 분할일 뿐 의미를 바꾸지 않는다
MATCH households=(p:Person)-[:LIVES_AT]->(:Address) <-[:LIVES_AT]-(:Person)-[:OWNS]->(:Phone) <-[:OWNS]-(p) RETURN households // 사기-링 질의의 단순화판 — 특정 경로 길이. // 변수 p의 재사용이 "같은 사람"이 공유 주소와 // 공유 전화 양쪽에 연결됨을 보장한다. // 현재 거래에 대해 실행하면 소지자가 평범한 // 가구임을 빠르게 확인 — 검사 하나를 더 통과해 // 거래 정당성에 대한 확신이 올라간다
큰 그래프에서 Example 10-4는 수 초~수 분이 걸릴 수 있지만 괜찮다 — 주기적으로(예: 시간·일 단위) 실행하는 분석 질의이기 때문이다. 합성 신원의 성장을 방치하면 사기꾼은 상당한 총 신용 한도를 쌓고, 제국이 감히 키울 수 있는 만큼 커지면 가용한 모든 신용을 급속히 소진하며 캐시아웃한다. 지식 그래프가 없으면 캐시아웃은 무작위적이고 막을 수 없어 보인다 — 신용은 인출된 채 미상환되고, 합성 신원에게 보낸 독촉장은 무응답이거나 그 주소에 실제로 사는 진짜 사람들을 괴롭힌다. 지식 그래프가 있으면 링 구조 한쪽의 캐시아웃으로 그 구조의 다른 모든 계좌를 매우 빠르게 찾아 차단하거나 정밀 조사할 수 있다 — 수백~수천 개의 연결 레코드만 고려하면 되는 저렴한 연산이라 필요하면 트랜잭션 흐름 안에서도 수행된다.
단, 연결된 신원이 모두 사기꾼은 아니다 — 사람들은 정당하게 주소를 공유하고, 현대에도 (특히 집·직장의 유선 전화라면) 전화번호를 공유한다. 가구를 사기로 낙인찍는 것은 대개 옳지 않으므로, 그림 10-7의 가구 패턴을 인지하고 Example 10-5 같은 확인 검사를 함께 운용해야 한다. 이런 패턴들을 알면(그리고 인간 전문성과 머신러닝으로 다른 패턴들을 발견하면) 결제 시스템에서 거래가 처리되는 동안 패턴을 검사해 일치하는 것을 거부할 수 있다.
프로덕션 배치에서 이 패턴들은 도메인 전문가가 표면화한다 — 그들은 그래프 알고리즘, 그래프 머신러닝, 시각화의 지원을 받아 자신의 지식과 경험으로 사기에 맞선 견고한 무기고를 유지한다. 이런 지식 그래프의 운영화의 열쇠는 카드의 서브그래프에 패턴을 매칭하는 것이다.
일반적으로 서브그래프-로컬 연산이 선호된다 — 지연이 매우 낮기 때문이다. 데이터가 카드 소지자의 지식 그래프로 저장되어 있으므로 거래 중에 각 고객 중심의 서브그래프에 빠르게 접근할 수 있고, 고려할 레코드 수가 상대적으로 적어 구매가 이루어지는 동안 의심 패턴을 검색할 수 있다 — 구매에 더해지는 지연은 최소이고, 사기 패턴을 잘 이해하고 있다면 좋은 보호를 제공한다. 특히 위험이나 가치가 높은 경우에는 더 넓은 그래프 영역에 걸친 집중적 패턴 매칭이나 서브그래프 위의 데이터 과학 프로세스를 돌릴 수도 있다 — 다만 수 밀리초에서 수 초까지 의사결정에 더해지므로 비교적 드물게 쓰고, 저지연 패턴 매칭이 일의 대부분을 처리하게 해야 한다. 서브그래프-로컬 매칭과 간헐적 그래프 알고리즘의 병용은 고객에 대한 지식을 자신과 고객을 사기로부터 보호하는 수단으로 바꾸는 효과적인 길이다.
Banking Circle은 이 장의 설명과 유사한 사기 관리 솔루션을 갖고 있다. 핵심은 결제에 연결된 계좌들의 지식 그래프다. Banking Circle은 커뮤니티 탐지로 ML 파이프라인의 피처를 생성해 고위험 고객 클러스터를 탐지한다. 지식 그래프 토폴로지는 ML 파이프라인의 핵심 입력으로, 가까운 이웃의 위험 점수, 조세 피난처까지의 거리, 알려진 사기꾼 같은 그래프 피처를 결합한다. 이는 Banking Circle의 사기 탐지 노력에 큰 긍정적 영향을 미쳤다 — 느리고 수동적인 프로세스를, 사기꾼이 제기하는 끊임없이 변하는 도전에 맞춰 진화할 수 있는 확장 가능하고 유연한 솔루션으로 바꿨다. 오늘날 Banking Circle은 그래프 알고리즘 실험을 계속하며 예측 모델을 더 조율할 그래프 피처의 추가를 계획하고 있다.
숙련된 인력을 채용·유지할 수 있는 조직은 시장에서 우위를 갖는다. 그러나 인력을 적절한 부서·프로젝트에 성공적으로 배치하는 도전이 남는다 — 부서·프로젝트는 특정 스킬 조합만이 아니라 서로 다른 수준의 연차와 경험을 요구하고, 가장 잘 운영되는 곳에는 (대체로) 잘 지내는 다양한 참여자들이 있다. 견고한 팀 만들기는 사소한 일이 아니지만 지식 그래프가 돕는다. 고성과 팀 구축에는 여러 차원이 있다 — 조직도(비용 센터·위치 포함), 전문성, 프로젝트 이력, 사회적 관계, 3차 스킬(예: 언어). 각각을 지식 그래프의 별도 계층으로 모델링하고 질의 시점에 결합해 정교한 질문에 답한다.
스킬을 찾을 가장 명백한 출발점은 조직도다. 위계뿐 아니라, 조직도가 아래로 퍼지는 지점에서 실무 커뮤니티나
프로젝트를 식별할 수 있고, 수직 위치로 재직 기간이나 역량 수준도 어느 정도 짐작된다. 조직도는 대개 한 명의
CEO에서 경영진을 거쳐 많은 실무자로 이어지는 트리인데, 트리는 그래프이므로 지식 그래프의 기본
계층으로 쉽게 들여올 수 있다. 그림 10-8에서 CEO Alice가 꼭대기에 앉고 SVP들이
REPORTS_TO 관계로 이어지며, 같은 패턴이 VP → 디렉터 → 개인 기여자(IC)까지
확장된다.
MATCH (:VP {name:'Harry'})<-[:REPORTS_TO*1..2]-(n) RETURN count(n) AS numberOfEmployees
인원 집계에서 비용 산출로 나아가는 것도 쉽고, HR 데이터로 그래프를 증강하는 것도 쉽다. 그러나 조직도는 조직의 의도된 구조일 뿐 — 실제 구조, 즉 일상적으로 어떻게 작동하는가의 근사에 불과하다. 대부분의 조직에는 포착되는 일도 드물고 실행에 옮겨지는 일은 더 드문 비공식 조직도 — 스킬과 솔루션 인도 경험에 기반해 사람들이 실제로 함께 일하는 방식 — 가 존재한다.
기초 수준에서 스킬 찾기는 단순하다 — MATCH (ic:IC)-[:HAS_SKILL]->(s:Skill
{name:'Java'}) RETURN ic.name이면 Java 경험자 이름이 나온다. 그러나 이 결과는 꽤 피상적이다 —
숙련도, 최근성, 실제 Java 프로젝트에의 노출에 대해 아무것도 말하지 않고, 스킬이 시간에 걸쳐
어떻게 쓰였는지의 맥락도 없다. 이름과 경험 시작 연도뿐이라면, 그 스킬이 마지막으로 언제 발휘되었는지도 모른
채 좋은 인력 배치 결정을 내리기 어렵다. 더 나은 길은 개인의 프로젝트 경험을 검사해 특정
스킬을 연마한 시간과 그 스킬이 쓰인 기간을 집계하는 것이다 — 그 연결된 맥락이 어떤 체크리스트보다 풍부한
역량의 뷰를 제공한다.
약간의 리팩터링 후 더 효과적인 지식 그래프가 나타난다(그림 10-11). 이 서브그래프에는
future-hr이라는 작업 프로그램이 여러 프로젝트로 분해되어 있다. 첫 프로젝트는
guns-brixton으로, 엔지니어 James가 Java·Neo4j·Linux로 수행한 솔로 작업으로
보인다 — (James)-[:PARTICIPATED_IN]-(guns-brixton)과
(guns-brixton)-[:REQUIRES]->(Neo4j)가 구조에 명시적이다. guns-brixton은 나가는
프로젝트 의존이 없고 다음 프로젝트 rock-casbah로부터 들어오는 DEPENDS 관계만
있으므로 프로그램의 개시 프로젝트임이 분명하다. 의존과 인력 구조는 의존이 없는 마지막 프로젝트
career-opportunities까지 이어진다. 프로젝트를 가로지른 특정 스킬과의 총
시간은 스킬 수준의 합리적 근사가 되고, 최근성은 그 스킬이 얼마나 최신인지 추론하게
해 준다.
MATCH (java:Skill {name:'Java'})<-[:REQUIRES]- (:Project)<-[:PARTICIPATED_IN]-(ic:IC) RETURN DISTINCT ic.name // 사람 → 프로젝트 → 스킬로 추이적 매칭
MATCH (:Skill {name:'Java'})<-[:REQUIRES]- (:Project)<-[:PARTICIPATED]-(e:Employee) CALL { WITH e MATCH (e)-[:PARTICIPATED]->(p:Project) RETURN collect(duration.inMonths(p.start, p.end) .months) AS duration } RETURN DISTINCT e.name, reduce(total=0, number in duration | total + number) AS monthsOfExperience // James·Hugo는 경험 많은 Java 개발자, // George는 조금 적다 (그림 10-12)
여기서 다른 가치 있는 프로덕션 용도로 그래프를 풍부화하는 길이 보인다 — 잠재된 스킬 지식을 표면화하는 데 이미 쓸모가 있고, 개인 프로필과 프로젝트 평가 등을 더하면 가장 도전적이거나 중요한 프로젝트에 최적의 인재를 배치하도록 돕는 지식 그래프 시스템을 만들 수 있다.
지금까지는 사람·프로젝트 데이터로 작업 패턴에 명시적으로 결부된 스킬을 발견했다 — 조직도 곳곳의 사람들이 프로젝트에서 일하고 재직으로 연차를 쌓는 전통적 조직 방식의 반영이다. 이런 지표는 가치 있는 신호지만 유일한 신호는 아니다. 특히 큰 조직에서 직원들은 조직도나 프로젝트 팀만이 아니라 특정 도구· 스킬을 둘러싼 장수하는 관심 커뮤니티로도 정렬한다. 이 커뮤니티의 전문가를 찾으면 조직도· 프로젝트 통계에 보완적인 신호가 되고, 어쩌면 비즈니스의 진짜 조직도라 할 수도 있다.
정보 노동자에게 현대 기업은 놀랄 만큼 평탄하다 — Slack, Microsoft Teams 같은 협업 시스템이 점대점 소통만이 아니라 장수 주제 중심의 커뮤니티 형성을 촉진한다. 그 안에는 남을 돕고자 하는 깊은 전문가와, 스킬을 높이거나 도움을 구하려 참여하는 사람들이 있다. 커뮤니티와 전문가가 발견되면 모두의 이익으로 증폭될 수 있다. 그러나 이런 플랫폼들은 사용자·대화·스레딩 이상의 구조화 데이터를 제공하지 않아, 좋은 정보나 전문가 찾기는 어렵고 입소문에 의존하게 된다 — 아직 업무 네트워크를 만들지 못한 신입에게 뚜렷이 불리한 편향이 생긴다. 협업 플랫폼 데이터를 계층으로 더해 지식 그래프를 풍부화하면 도움이 된다 — Slack·Teams 상호작용의 품질에 근거해 스킬 기록이 자동으로 갱신된다면 좋지 않겠는가?
협업 플랫폼의 모델은 지식 그래프와 매우 궁합이 좋고, 커뮤니티 탐지 같은 그래프 데이터 과학의 일부는 직원이
참여하는 채널에 이미 암묵적으로 들어 있다. Slack의 핵심 관용구의 지식 그래프 표현(그림 10-13)은
(:User)-[:WROTE]->(:Message)-[:POSTED_TO]->(:Channel)과
(:Message)-[:MENTIONS]->(:Skill) 같은 패턴을 허용해, 특정 스킬에 대해 쓰고
응답하는 사용자를 추이적으로 이해하게 한다. 채널·토픽의 구조 데이터도 담아 스킬에서 그 스킬을
보유한(적어도 논하는) 커뮤니티를 담은 채널로 일반화할 수 있다. 화이트보드에 그릴 도메인 그림과 거의
같을 만큼 단순하지만, 능력이 부족하지 않다.
MATCH (m:Message)-[:POSTED]->(c:Channel)-[:TOPIC]-> (s:Skill {name:'IL'})<-[:MENTIONS]-(m) MATCH (m)<-[:REPLY*]-(r:Message)<-[:POSTED]-(u:User) WITH u AS user, count(r) AS replies, s AS skill, collect(DISTINCT c.name) AS channel ORDER BY replies DESC RETURN skill.name, user.name, replies, size(channel) AS numberOfChannels // 특정 스킬의 원 게시물을 (채널 무관하게) 찾고, REPLY 관계의 경로로 대화 스레드를 얻은 뒤 // 응답 수로 내림차순 정렬 — 스킬, 참여 사용자, 응답 횟수, 참여 채널 수를 반환한다
이것이 일반화되면 조직의 전문가를 식별할 수 있다. 어떤 의미에서 전문성 그래프는 공식 조직도의 보완물이다. Andy Grove가 High Output Management 2판(Vintage Books)에서 말하듯, 직원은 조직도 덕분에 조직 권력(organizational power)을 갖거나 스킬 덕분에 지식 권력(knowledge power)을 갖는다 — 숙련된 관리자처럼 둘 다 가질 때도 있다. 지식 그래프는 이 두 축을 병합해 기업 인력에 대한 현저히 풍부한 이해를 주는 훌륭한 수단이다.
그림 10-13 같은 그래프는 개인에게도 대단히 유용하다 — 어떤 주제든 시스템이 프로젝트 위험과 시간을 줄이고 지식을 전수할 전문가를 쉽게 추천할 수 있다. 그리고 이런 시스템의 기초 지식은 직원의 프로젝트 이력이다. 개인은 자신의 프로젝트·스킬 이력을 돌아보며 경력의 대략적 방향을 감지할 수 있다.
MATCH (:Employee {name:'Rosa'})-[part:PARTICIPATED]-> (p:Project)-[r:REQUIRES]->(s:Skill) WITH p AS proj, s AS skill, part.end AS lastUsed, duration.inDays(part.start, part.end).days AS days RETURN skill.name AS skill, sum(days) AS daysOfExperience, max(lastUsed) ORDER BY daysOfExperience DESC // 스킬별 총 경험 일수와 마지막 사용일 — // 최근 쓴 스킬이 더 신선하다는 전제의 짧은 보고서
MATCH (me:Employee {name:'Rosa'})-[:PARTICIPATED]-> (:Project)<-[:PARTICIPATED]-(other:Employee) MATCH (other)-[:PARTICIPATED]->(:Project) -[:REQUIRES]->(s:Skill) WHERE NOT (me)-[:PARTICIPATED]->(:Project) -[:REQUIRES]->(s) WITH s AS skill, count(s) AS popularity RETURN DISTINCT skill.name, popularity ORDER BY popularity DESC // 프로젝트를 함께한 사람들이 이후 접했지만 // 나는 접하지 못한 스킬 = 배울 만한 것. // Rosa의 1순위는 Java (그림 10-16)
이 예제들은 중요한 HR 문제를 푸는 즉각적 가치를 주면서 더 정교한 분석의 기반도 된다. 예컨대 간단한 스킬 택소노미를 더하면 인력 배치를 일반화·특수화 수준에서 함께 추론할 수 있다 — databases라는 일반 스킬 vs NoSQL이라는 특수 스킬, 함수형 프로그래밍 vs F#처럼.
Example 10-10을 살짝 비틀면 관리자가 직원 기반 전체에서 특정 스킬·경험을 찾을 때 쓰는 바로 그 질의가 된다 —
개인의 이름 대신 스킬을 중심에 두는 것이다(Example 10-12:
(s:Skill {name:'Java'})를 축으로 직원별 경험 일수·최근 사용일을 내림차순 랭킹,
그림 10-17의 숙련 Java 개발자 목록). 결과 개선을 위해 스킬 외의 차원도 섞을 수 있다 — 서로 즐겁게 일하는
팀원들이 더 나은 결과를 낸다는 것은 잘 알려져 있으므로, 사회적 계층을 더하면 필요한 스킬의
조합만이 아니라 도전을 함께 껴안을 응집력 있는 팀을 꾸릴 수 있다. 프로젝트 구성원들이 서로의
협업 경험을 평가하게 하면, "팔로우"나 "좋아요"가 아니라 프로젝트 단위(또는 분기 단위)로 누가 누구와 잘 맞는지
점수화한 풍부한 소셜 네트워크가 생긴다(그림 10-18 — 교육 목적상 RATED 관계에 점수 리스트로 캡처).
UNWIND ["Rosa", "Hugo", "Eve", "Petra", "Mark"] AS candidate MATCH (me:Employee {name:candidate}) MATCH (me)-[r1:RATED]->(other:Employee) MATCH (me)<-[r2:RATED]-(other:Employee) WITH me.name AS myself, reduce(score = 0, r in r1.ratings | score + r) /size(r1.ratings) AS s1, reduce(score = 0, r in r2.ratings | score + r) /size(r2.ratings) AS s2, other.name AS them RETURN myself, them, (s1+s2)/2 AS score ORDER BY myself, score DESC // UNWIND가 리스트를 행으로 — 편리한 매개변수화. // 나가는/들어오는 평가 평균을 다시 2로 나눠 // 집계 궁합 점수를 얻는다 (그림 10-19)
UNWIND ["Rosa", "Hugo", "Eve", "Petra", "Mark"] AS candidate MATCH (me:Employee {name:candidate}) MATCH (me)-[r1:RATED]->(other:Employee) MATCH (me)<-[r2:RATED]-(other:Employee) WITH me AS myself, reduce(score = 0, r in r1.ratings | score + r) /size(r1.ratings) + reduce(score = 0, r in r2.ratings | score + r) /size(r2.ratings)/2 AS score, other AS them, r1, r2 WHERE score >= 5 RETURN myself, them, score, r1, r2 // 높은 상호 평가만 남기고 RATED 관계도 반환해 // 그래프를 시각적으로 렌더링 (그림 10-20) — // 훨씬 직관적인 뷰
이 예제의 점수 계산은 단순한 편이지만, 조직에 필요한 만큼 정교하게 만들면 된다. 어떤 산술을 고르든 소셜 그래프로 팀 구성을 미세 조정한다는 발상 자체가 견고한 기반이다.
스킬 지식 그래프의 이득은 인력 개발을 훌쩍 넘어선다 — 과거 결과에 근거해 진행 중 프로젝트의 예상 결과를 평가·추론하는 데도 쓸 수 있다. 그림 10-21은 두 미완(Incomplete) 프로젝트를 둘러싼 실무자와 관리자의 서브그래프를 보여준다. 인력 구성은 흥미로운 추론의 근거가 된다 — 부실한 관리자나 저숙련 인력은 부정적 영향을, 강한 관리 구조와 숙련 인력은 긍정적 효과를 낼 것이다. 실패한 프로젝트의 이력과 그 관리 사슬의 감을 잡으려면 다음 질의를 돌린다.
MATCH (p:Project)<-[:PARTICIPATED_IN]-(:IC)-[:REPORTS_TO*3..3]->(svp:SVP) WHERE p.rating < 30.0 RETURN svp, count(p) AS failedProjects ORDER BY failedProjects DESC // rating 속성은 완료 프로젝트에만 있고, 30.0 미만을 실패로 간주. // IC에서 정확히 3단계 위의 SVP로 매치 → SVP Lynn Smyth 휘하 팀들이 // 동료들보다 훨씬 자주 문제를 겪는 것으로 나타난다 (그림 10-22)
이 정도 소규모에서는 데이터가 거의 어떤 이야기든 하도록 만들 수 있다. Lynn의 이력을 더 파고들면 프로젝트 실패가 두드러지는 설득력 있는 이유 — 예컨대 실패한 프로젝트조차 가치를 갖는 연구 조직을 운영한다든가 — 가 있을지 모른다. 포트폴리오 일부가 어긋난 SVP는 Lynn만이 아니지만, 그녀의 경우가 다른 이들보다 다소 유의하다. 이런 전역 규모의 소진적 패턴 매칭은 비실용적이고 제한적이다 — 지식 그래프가 성공할 리더를 추천하거나 어긋날 프로젝트를 조기 경보해 준다면 훨씬 좋을 것이고, 그래프 데이터 과학이 그 도구를 준다.
6장에서처럼 첫걸음은 분석할 노드·관계·속성을 담은 프로젝션이다 — Employee·Project·Incomplete 노드와
PARTICIPATED_IN·REPORTS_TO 관계 전체, 그리고 Project 노드의 rating 속성만 취한다. 목표는 아직 완료되지 않은
프로젝트의 rating 속성을 예측해 예상 결과를 아는 것이다. 이어서
gds.alpha.pipeline.nodeRegression.create('projects-pipeline')으로 ML 파이프라인을
만들고, 7장과 같은 선언적 동선으로 노드 회귀(node regression)를 구성한다.
CALL gds.graph.project( 'projects', { Incomplete: {}, Project: { properties: ['rating'] }, Employee: {} }, { PARTICIPATED_IN: {orientation: 'UNDIRECTED'}, REPORTS_TO: {orientation: 'UNDIRECTED'} } ) CALL gds.alpha.pipeline.nodeRegression.addNodeProperty( 'projects-pipeline', 'fastRP', { embeddingDimension: 256, iterationWeights: [0, 1], mutateProperty:'fastrp-embedding', contextNodeLabels: ['Project'] } ) // fastRP가 Project 노드의 토폴로지를 // ML에 적합한 수치로 인코딩한다
CALL gds.alpha.pipeline.nodeRegression.selectFeatures( 'projects-pipeline', 'fastrp-embedding' ) // 조직 토폴로지가 중요하므로 임베딩을 피처로 CALL gds.alpha.pipeline.nodeRegression.configureSplit( 'projects-pipeline', { testFraction: 0.2 }) // 20%를 테스트용으로 예약 CALL gds.alpha.pipeline.nodeRegression.addRandomForest( 'projects-pipeline', { numberOfDecisionTrees: 10 }) // 랜덤 포레스트: 여러 결정 트리로 단일 트리 // 과적합을 막고 개별 예측을 종합한다 CALL gds.alpha.pipeline.nodeRegression.configureAutoTuning( 'projects-pipeline', { maxTrials: 100 }) // 계산이 충분히 저렴해 100회 반복 시도
CALL gds.alpha.pipeline.nodeRegression.train('projects', { pipeline: 'projects-pipeline', targetNodeLabels: ['Project'], modelName: 'projects-pipeline-model', targetProperty: 'rating', randomSeed: 1, concurrency: 4, metrics: ['MEAN_SQUARED_ERROR'] }) // Project 레이블 + rating 속성으로 훈련 — // 미완 프로젝트의 rating 예측을 준비한다
CALL gds.alpha.pipeline.nodeRegression.predict.stream( 'projects', { modelName: 'projects-pipeline-model', targetNodeLabels: ['Incomplete'] }) YIELD nodeId, predictedValue WITH gds.util.asNode(nodeId) AS projectNode, predictedValue AS predictedRating RETURN projectNode.name AS name, predictedRating ORDER BY predictedRating ASC LIMIT 10 // 예측 점수가 가장 나쁜 10개 프로젝트 (그림 10-23). // 후속 데이터 과학으로 실패 요인을 파거나, // 비즈니스 수준에서 발견을 확인 — 어느 쪽이든 // 조기 개입이 유익할 프로젝트의 지침을 얻는다
부서/리더·스킬셋별로 결과를 추적하고, 그래프에 담긴 과거 역량의 개념으로 미래 결과를 예측한다. 곤경에 처한 리더의 개선을 돕거나 장기 부진을 낳는 구조적 장벽을 식별하고, 지속적인 구조적·개인적 결함이 드러나면 조직 재설계의 출발점이 된다.
업스킬하려는 개인은 인도가 성숙해 새 구성원의 학습에 숨 쉴 공간이 있는 팀으로 항해할 수 있다. 기량을 증명하려는 개인에게는 스킬셋이 맞으면서 강한 팀에 합류하거나 흔들리는 팀을 보강할 기회가 명시적으로 보인다 — 어느 길이든 기대되는 바에 대한 현저히 나은 가시성을 얻는다.
이 지점에서 분명해지는 것 — 스킬 지식 그래프는 "Java와 Agile 5년"이라는 좁은 세계에서, 개인이 인도의 맥락 속 풍부한 스킬 이력을 갖는 세계로 데려간다. 개인의 과거와 미래의 경력 스킬이 모두 지식 그래프를 풍부하게 하여, 개인이 경력에서 최선을 얻도록 돕고 조직이 미래를 계획하도록 돕는다.
DXC Technology는 13만 명을 고용한 글로벌 IT 서비스 기업이다. 경쟁 시장에서 번성하려면 최고 수준의 컨설팅·인도 전문성을 위해 인재를 유치·유지·업스킬해야 했고, 조직에 가장 가치 있는 역할·경력 경로에 근거한 경력 개발 조언을 직원이 쉽게 추천받는 시스템을 원했다. 그러나 많은 대기업처럼 DXC에도 정보 사일로와 단절된 시스템들이 있었다 — 각자 가치는 있었지만 직원에게 연결된 뷰를 주지 못했고, 채용·승진과 경력 경로 설계에 어려움을 낳았다. 수요가 높을 때는 직원을 이직으로 잃었고, 인력 감축 시에는 준최적의 결정이 내려졌다. 이를 고치기 위해 DXC는 Career Navigator를 개발했다 — 사일로화된 데이터를 모두 연결하고 이 장의 예제들과 유사한 직원 지식 그래프에 기반해 지능적 추천을 생성한다. 직원의 모든 상호작용은 유사한 직원들의 스킬 진행(skill progression)에 근거한 추천으로 시작하는 애플리케이션이 매개한다 — 예컨대 소프트웨어 엔지니어에게는 유사 엔지니어들과의 스킬 격차에 근거해 스킬을 추천한다. Neo4j 그래프 데이터베이스와 GDS 라이브러리의 조합으로, 그래프 알고리즘이 유사 숙련 직원을 식별해 타인의 경력 진행의 프로토타입으로 삼는다. Career Navigator는 매우 성공적이어서 DXC는 이제 이를 고객에게 솔루션으로 판매하고 있다.
도메인의 패턴을 발굴하고 이해하는 것은 핵심적인 경쟁 차별화 요인이며, 패턴 탐지 지식 그래프는 그 능력을 여는 강력한 방법이다. 이 장의 예제들은 자신만의 패턴 탐지 지식 그래프를 세울 견고한 기반을 제공한다 — 인간 전문성과 그래프 데이터 과학의 통찰을 자유롭게 섞어 지식 그래프를 풍부화하고, 그 풍부해진 그래프를 온라인·분석 사용 사례 양쪽에 똑같이 유능하게 프로덕션 투입할 수 있다.
사기의 경제학이 그래프를 정당화한다. 미국 $5.8B(+70% YoY), $1당 $4.23의 추가 비용 — 한계 개선도 절대액으로는 거대하다. 규칙 기반(느리고 비싸고 경직)을 넘어, 연결 맥락이 좋은 고객·곤경의 고객·사기꾼을 구별한다.
일반 성질의 검증이 단서를 준다. 240만 명 vs Louvain 커뮤니티 180만 — 약 50만의 불일치가 다인 커뮤니티의 존재를 폭로한다. 샘플링(rand() < 10.0/count, 깊이 2~4)과 도메인 전문성으로 가구(무해)와 사기 링(합성 신원)을 판별한다.
사기꾼은 수직·수평으로 확장한다. 선의 소유→정상 운영→한도 상승(수직), 가짜 신원 다수(수평), 그리고 캐시아웃. OWNS|LIVES_AT*5.. 링 질의는 주기적 분석으로, 캐시아웃 시 링 전체 차단은 트랜잭션 흐름 안에서 — 저지연 로컬 매칭 우선, 데이터 과학은 드물게.
스킬은 체크리스트가 아니라 맥락이다. HAS_SKILL은 피상적 — 프로젝트 이력(REQUIRES/PARTICIPATED)의 집계 기간·최근성이 진짜 신호다. Slack 계층은 지식 권력을, 조직도는 조직 권력을 드러내며(Grove), 그래프가 두 축을 병합한다. 동료의 스킬 격차가 업스킬 추천이 되고, RATED 소셜 계층이 응집력 있는 팀을 만든다.
노드 회귀가 미래를 진단한다. FastRP 임베딩 → 랜덤 포레스트(트리 10개) → 오토 튜닝(100회) → MSE 훈련 → Incomplete 예측(최악 10개)의 선언적 파이프라인. Banking Circle은 커뮤니티 피처로 사기 ML을, DXC는 13만 직원의 Career Navigator를 세웠고 이제 고객에게 판다.
이 장의 기법들은 사기꾼의 소셜 네트워크나 동료·프로젝트의 비즈니스 네트워크에만 쓰이는 게 아니다. 다음 장에서는 공급망과 리스크 관리처럼 다양한 도메인에서 시스템 내 의존성의 패턴을 처리하는 법을 배운다 — 의존성 지식 그래프(11장, Dependency Knowledge Graphs)다.