계통

항목	LPG 모델	RDF 모델
풀네임	Labeled Property Graph	Resource Description Framework
대표 질의 언어	GQL 계열 (Cypher)	SPARQL
기본 구조	Node + Relationship + Property	Subject + Predicate + Object (Triple)
관계 자체의 속성	강함. 엣지에 `amount`, `timestamp`, `channel`, `risk_score` 같은 속성을 직접 붙이기 쉽다	기본 RDF triple에서는 관계 속성 표현이 불편하다. RDF-star, reification, named graph 등을 써야 한다
주 사용처	애플리케이션 그래프, 추천, 경로 탐색, 네트워크 분석	시맨틱 웹, 온톨로지, linked data
핀테크 사기 탐지	적합	보통 덜 직관적
경로 탐색	강함	목적이 다소 다름 (SPARQL property path)
실시간 탐지	상대적으로 유리한 편	일반적으로 더 부하가 큼
온톨로지/의미 추론	약함	강함
표준 vocabulary 연계	약함	강함
규제/정책/개념 모델링	보통	적합
개발자 친화성	높음	낮은 편
금융권 일반 그래프 분석	더 실용적	특수 목적에 적합
	데이터베이스의 탐색 속도와 애플리케이션의 실시간 반응성, 다중 홉(Multi-hop) 탐색 지연 시간을 최소화	복잡한 이기종 데이터 통합, 마스터 데이터 관리, 규제 준수(Compliance) 및 금융권/헬스케어의 도메인 지식 체계화
	청크 간의 코사인 유사도 수치나 참조 관계를 엣지의 속성(Property)으로 직접 저장

RAG 파이프라인에서 지식 그래프를 활용할 때,
- 데이터의 연결 상태 자체를 탐색하고 엣지에 여러 파라미터를 저장해야 한다면 LPG가 유리하다.
- 데이터 간의 상하위 개념, 동의어, 규칙 등 복잡한 논리 구조를 시스템이 스스로 추론하게 만들려면 RDF Triple 구조가 적합하다.

User ──USES──> Device
User ──OWNS──> Account
Account ──TRANSFERRED {amount, timestamp}──> Account
Card ──USED_AT {amount, timestamp}──> Merchant
Device ──ACCESSED_FROM──> IP

관계	필요한 속성
계좌 → 계좌 송금	금액, 시간, 채널, 국가, 위험 점수
사용자 → 기기 사용	최초 사용일, 최근 사용일, 세션 수
카드 → 가맹점 결제	금액, 승인 시간, MCC, 위치
사용자 → IP 접속	접속 시간, ASN, VPN 여부
계좌 → 계좌 반복 송금	빈도, 누적 금액, 최근성

핀테크 유스케이스	LPG	RDF
이상거래 탐지	계좌, 사용자, 기기, IP, 가맹점 간 다단계 관계 탐색이 핵심
AML / 자금세탁 패턴 탐지	순환 송금, layering, shared device, mule account 탐지에 적합
보이스피싱 계좌 네트워크 분석	계좌 간 송금 경로와 클러스터 분석에 적합
카드 부정사용 탐지	카드-사용자-가맹점-위치-시간 관계 분석이 자연스러움
신용평가 보조 피처 생성	주변 노드, 중심성, 커뮤니티, 거리 기반 feature 생성 가능
고객 추천 / next best action	사용자-상품-행동 그래프에 적합
금융 상품 지식베이스		상품, 약관, 수수료, 규제 요건의 의미 관계 표현에 적합
규제/컴플라이언스 온톨로지		법령, 의무, 리스크 카테고리, 보고 요건 모델링에 적합
여러 금융기관 데이터 표준화		URI, vocabulary, ontology 기반 통합에 유리
감사 가능한 의미 모델		명시적 의미 정의와 표준 질의에 유리

비교 항목	Node + Rel + Prop (LPG)	Subject + Pred + Object (RDF Triple)
표준 및 생태계	DB 벤더 주도 (Neo4j 등)	W3C 표준 (GraphDB, Stardog 등)
관계 속성 표현	엣지에 Key-Value 속성 직접 추가 가능	기본적으로 불가능 (우회 기법 필요)
주요 목적	고속 그래프 탐색 및 서브그래프 패턴 매칭	데이터 의미 표준화 및 온톨로지 기반 논리 추론
질의어 (Query)	Cypher, Gremlin	SPARQL
RAG 적용 포인트	청크 간의 구조적 관계, 유사도 가중치 등 단순 메타데이터 연결 위주	도메인 특화 사전 구축, 동의어 처리, 규칙 기반의 복잡한 지식 추론 위주

LPG
- Node + Relationship + Property 구성
- property 가 수천개까지도 붙을수 있고 property 각각의 이름도 각자 알아서 지정
- 서로 다른 시스템간의 공통된 포맷을 만들기 어렵다
  - 프로퍼티 명칭을 맞추고 매핑하는데 비용이 든다
  - ‘나이’ 속성을 표현할 때, 개발자에 따라 age, Age, user_age 등으로 제각각 정의할 수 있다
- LIKE json
- 데이터 구조 관리가 느슨하고 파편화되기 쉽다
- 단일 시스템 내에서 애플리케이션 개발과 로컬 연산 속도를 중시하는 로드맵
RDF
- subject, predicate, object 구성 (Triple)
- 하나의 레코드 당 subject, predicate, object 의 3요소로 고정 (sql 로 치면 컬럼 3개)
- 서로 다른 시스템간의 데이터를 규격화하기가 상대적으로 편하다
  - 전역적으로 합의된 표준 온톨로지의 URI (예: http://xmlns.com/foaf/0.1/age)를 술어(Predicate) 자리에 강제함으로써 데이터의 포맷과 의미를 동시에 규격화한다
- 3원소 구조 고정 + 식별자를 URI로 제한을 통해, 데이터 자체를 표준화하고 시스템 간에 결합(Data Integration)하는 전사적 시맨틱 레이어 구축에 유리

MATCH (u:User)-[r:TRANSFERRED]->(i:Item)
RETURN u, i, r.why, r.timestamp

PREFIX : <http://example.org/>
 
SELECT ?user ?item ?why ?timestamp
WHERE {
  ?event a :Transfer ;
         :has_sender ?user ;
         :has_receiver ?item ;
         :why ?why ;
         :timestamp ?timestamp .
}

# rdf*
PREFIX : <http://example.org/>
 
SELECT ?user ?item ?why ?timestamp
WHERE {
  << ?user :transferred ?item >> :why ?why ;
                                 :timestamp ?timestamp .
}

상황: User가 Item을 전송(transferred)했다. (이유: Purchase, 시간: 2026-06-27)

이때 LPG 에서는 레코드는 1개. edge (relationship) 이 property 2개만 가지면 된다.

RDF 에서는 좀 복잡함. RDF의 대원칙은 “선(Predicate)에는 어떠한 데이터도 쑤셔 넣을 수 없다”.

그래서 n-ary(다항) 관계 방식은 편법을 쓴다. ‘전송했다’는 선 자체를, 뭉뚱그려 ‘전송 이벤트’라는 가상의 노드(동그라미)로 승격시켜버린다. 선을 노드로 바꾼 뒤, 그 가상 노드에서 여러 가닥의 선을 뻗어 나가는 방식으로 구조를 뜯어고치는 것이다.

RDF 데이터베이스(트리플 스토어)에는 딱 3개의 컬럼(Subject, Predicate, Object)만 존재하며, 이 1개의 관계를 표현하기 위해 아래와 같이 총 5줄의 레코드가 물리적으로 저장된다.

LPG 레코드를 RDF 레코드로 바꾸려면, 아래가 성립한다.

1개의 LPG 레코드, k개의 edge property, n & m 개의 node property
$3 + k + n + m$ 개의 RDF 레코드
- 이때 3은 (Subject + Pred + Object)
- 시작 노드, 끝 노드의 선언까지 포함한다면, $5 + k + n + m$
  - LPG에서 (u:User) 노드에 라벨을 부여할 때, RDF에서는 이 라벨 부여 또한 (u) (rdf:type) (User)라는 하나의 독립적인 트리플 명제로 취급한다

lpg에서 relationship 이 transferred, used_at 이 있다고 하자. 이때 각각은 property

transferred: why, timestamp

를 가진다. 이 데이터가 rdf 에서 표현되면 어떻게 되지?

주어 (Subject)	술어 (Predicate)	목적어 (Object)	이 레코드(Row)가 존재하는 이유
`:event_01`	`rdf:type` (타입)	`:Transfer`	1. 가상 노드 생성: “event_01이라는 노드를 새로 만들 건데, 이건 ‘전송’ 행위를 뜻하는 노드다.”
`:event_01`	`:sender` (보낸 주체)	`:User`	2. 출발점 연결: “그 전송 행위를 한 주체는 User다.”
`:event_01`	`:receiver` (받은 대상)	`:Item`	3. 도착점 연결: “그 전송 행위의 대상은 Item이다.”
`:event_01`	`:why` (이유)	`"Purchase"`	4. 속성 달기 1: “그 전송 행위가 일어난 이유는 Purchase다.”
`:event_01`	`:timestamp` (시간)	`"2026-06-27"`	5. 속성 달기 2: “그 전송 행위가 발생한 시간은 2026-06-27이다.”

사용 케이스

분 (Use Case)	핵심 목적	주요 분석 패턴 및 기술	비즈니스 기대 효과	LPG에서 보는 관계
이상 거래 및 사기 탐지 (Fraud Detection & AML)	자금 세탁(AML) 및 조직적 사기 네트워크 실시간 차단	- N-hop 순환 고리(Circular Flow) 추적 - 단일 디바이스/IP에 연결된 합성 신원 군집 식별	실시간 사기 적발률 향상 및 금융 사고 피해액 최소화
대안 신용 평가 (Alternative Credit Scoring)	금융 이력 부족자(Thin Filer) 대상 정교한 리스크 산출	- 그래프 알고리즘(PageRank, Louvain) 활용 - 기존 불량 채무자와의 네트워크 중심성 및 거리 측정	기존 모델의 사각지대 해소 및 안전한 대출 취급액 증대
실시간 상품 추천 (Real-time Recommendation)	고객 행동 및 네트워크 기반 초개인화 금융 상품 제안	- 협업 필터링(Collaborative Filtering)의 그래프 경로 치환 - 실시간 조회/매수 패턴(예: 특정 ETF 구매 경로) 매칭	금융 상품 교차 판매(Cross-selling) 적중률 및 전환율 극대화
고객 360도 뷰 (Customer 360)	사내 분산된 시스템의 이기종 고객 트랜잭션 데이터 통합	- 단일 식별자 기반 전사 데이터 지식 그래프 구축 - 계좌, 대출, 카드 간 자산 융통 흐름 다차원 모니터링	통합 자산 관리(PFM) 서비스 고도화 및 이탈 위험 징후 포착
부정거래 탐지	여러 계정이 같은 기기, 같은 IP, 같은 카드 BIN, 같은 주소를 공유하는지 탐색			사용자–계좌–카드–기기–IP–가맹점–거래
AML / 자금세탁 탐지	순환 송금, layering, shell company network, mule account chain 탐지			계좌–송금–수취계좌–법인–실소유자
계정 탈취 / ATO 탐지	평소와 다른 기기/IP가 기존 위험 네트워크와 연결되는지 탐지			사용자–로그인–디바이스–IP–위치–세션
KYC / Entity Resolution	같은 실체가 여러 계정으로 쪼개져 있는지 식별			고객–전화번호–주소–이메일–신분증–법인
신용/리스크 네트워크 분석	특정 부실 차주와 연결된 네트워크 리스크 탐색			차주–보증인–법인–대표자–거래처
고객 360 / 추천	고객 관계와 행동 기반으로 다음 상품 추천 또는 세그먼트 분석			고객–상품–거래–행동–상담–채널
조사관용 Case Graph	개별 알림을 사람이 조사할 수 있게 관계 그래프로 시각화			Alert–거래–고객–계좌–증거

song-ps

Explorer

main

계통

사용 케이스

Graph View

Table of Contents