그래프가 이기는 문제 넷

한 줄 요약

사기 고리, 순환 송금, 허브, 추천 — 네 문제의 공통점은 답이 한 행에 있지 않고 행들 사이에 있다는 것이다. 표로 풀면 자기 조인이 쌓이고, 그래프로 풀면 패턴 한 줄이다. 그리고 넷 다 그럴듯한 오답이 있어서, 패턴을 어떻게 좁히느냐가 실력이다.

왜 이게 필요했나

사기 조사팀이 "같은 휴대폰으로 가입한 계정" 을 찾아 달라고 했다. 표로는 uses_device 를 device_id 로 자기 조인하면 된다. 그런데 결과에 도서관 공용 단말이 잡혔다. 여섯 명이 같은 기기를 썼지만 서로 아무 관계가 없다. "같은 주소" 도 마찬가지다 — 다섯 식구가 한 주소에 산다. 진짜 고리는 기기와 주소를 둘 다 함께 쓴다. 조건이 하나 늘 때마다 SQL 은 조인이 하나 더 늘고 GROUP BY 가 복잡해진다. Cypher 는 패턴에 선 하나를 더 긋는다.

MATCH (d:Device)<-[:USES]-(p:Person)-[:LIVES_AT]->(a:Address)WITH d, a, collect(DISTINCT p.id) AS members WHERE size(members) >= 4RETURN d.id, a.id, members

어떻게 동작하나

순환 송금. 돈이 A → B → C → A 로 돌아오면 자금 세탁이나 돌려막기다. MATCH p = (a:Account)-[:TRANSFER*3..5]->(a) 가 그 모양이다. 그런데 이대로 돌리면 정상 송금으로 우연히 만들어진 순환이 잔뜩 나온다 — 친구끼리 밥값을 돌려주다 보면 삼각형은 흔하다. 그래서 금액 조건을 건다: WHERE all(r IN relationships(p) WHERE r.amount >= 500000). 또 하나, 같은 순환이 출발 노드 수만큼 반복해 나온다. 세 노드 순환이면 세 번. 가장 작은 id 에서 시작하는 것만 남기면 하나가 된다.

허브. 차수(degree)가 유난히 높은 노드다. MATCH (a:Account)-[t:TRANSFER]-() RETURN a.id, count(t) ORDER BY count(t) DESC 한 줄인데, 이 목록의 1위는 대개 사기가 아니라 급여 계좌다. 수백 곳으로 보내는 것은 회사가 하는 일이다. 차수는 어디를 들여다볼지를 정해 줄 뿐, 판단은 방향(보내기만 하는가, 받기만 하는가)과 상대의 성격이 한다.

추천. "나와 같은 것을 산 사람들이 산, 내가 아직 안 산 것" 은 그래프에서 두 걸음이다.

MATCH (me:Person {id: 27})-[:BOUGHT]->(:Product)<-[:BOUGHT]-(other)-[:BOUGHT]->(rec:Product)WHERE other <> me AND NOT (me)-[:BOUGHT]->(rec)RETURN rec.id, count(DISTINCT other) AS score ORDER BY score DESC LIMIT 5

count(DISTINCT other) 인 이유가 있다. 나와 상품 셋이 겹치는 사람은 이 패턴에서 세 번 나온다. DISTINCT 가 없으면 취향이 비슷한 한 사람이 점수를 세 배로 밀어 올린다. NOT (me)-[:BOUGHT]->(rec) 를 빼면 내가 이미 산 것을 추천한다 — 실제 서비스에서 가장 흔한 추천 사고다.

실무에서 진짜 중요한 것

첫째, 패턴은 좁히는 것이 실력이다. 기기 공유만 보면 공용 단말이, 주소 공유만 보면 가족이 잡힌다. 순환도 금액 없이 보면 밥값이 잡힌다. 그럴듯한 오답을 하나씩 떼어 내면서 조건을 더하는 것이 그래프 질의를 쓰는 일이다.

둘째, 결과를 세는 방식을 정해 둔다. 같은 순환이 k 번 나오고, 같은 사람이 여러 상품으로 겹친다. 정규화(가장 작은 id 에서 시작, DISTINCT)를 질의에 넣지 않으면 숫자가 매번 달라 보고서가 흔들린다.

셋째, 그래프는 후보를 뽑고 판단은 사람이 한다. 허브 1위가 급여 계좌인 것처럼, 그래프 질의는 "여기를 보라" 까지다. 차수·순환·공유가 겹치는 자리를 표로 만들어 조사팀에 넘기는 것이 실제 산출물이고, 다음 실습의 마지막 단계가 그 보고서다.