SPARQL 기초와 RDF 파이프라인 실습: 지식 그래프를 SQL 대신 써야 하는 이유

핵심 메시지

• SQL은 테이블의 행을 조건에 맞춰 훑는 방식이라, 관계가 많아질수록 정규화와 조인이 늘어 질의문이 복잡해진다.
• SPARQL은 '주어-서술어-목적어' 트리플 패턴을 맞춰 찾기 때문에 관계 중심 탐색에서 훨씬 짧은 코드로 같은 결과를 얻는다.
• WHERE 안의 조건들은 순서대로 후보를 좁혀 나가며, 앞 줄에서 걸러진 결과 위에서 다음 조건이 적용된다.
• CONSTRUCT는 검색 결과로 새로운 그래프를 만들고, FILTER는 값 조건을, OPTIONAL은 빠진 속성이 있어도 결과를 살리는 역할을 한다.
• CSV를 RDF로 옮길 때는 객체를 가리키는 URI와 단순 값인 리터럴을 구분해야 하며, 외부 식별자와의 연결은 owl:sameAs로 처리한다.

쉽게 이해하기

지식 그래프를 다룰 때 가장 먼저 부딪히는 질문은 '왜 익숙한 SQL을 두고 새 질의 언어를 배워야 하느냐'다. 서울대 산업공학과 DSBA 연구실의 온톨로지 스터디 실습 영상은 이 질문에서 출발해, 같은 검색을 두 언어로 각각 어떻게 표현하는지 나란히 보여준다.

예로 든 문제는 단순하다. 특정 저자가 쓴 이상 탐지 논문을 찾는 것이다. SQL에서는 저자와 키워드처럼 한 논문에 여러 값이 붙는 관계를 표에 담기 위해 테이블을 쪼개는 정규화가 필요하고, 그 결과 검색할 때마다 조인을 여러 번 걸어 흩어진 식별자를 다시 맞춰야 한다. 질의문이 길고 복잡해지는 이유다.

지식 그래프는 같은 정보를 '누가 썼다', '어떤 키워드를 갖는다' 같은 관계의 묶음으로 저장한다. SPARQL은 이 묶음을 패턴으로 맞춰 찾기 때문에, 물음표를 붙인 변수 자리에 조건에 맞는 값이 차례로 채워진다. 앞 줄에서 특정 저자의 논문으로 후보가 좁혀지면 다음 줄의 키워드 조건은 그 좁혀진 후보 안에서만 적용되는 식이다.

문법의 기본 뼈대는 PREFIX, SELECT, WHERE다. SELECT와 WHERE의 역할은 SQL과 거의 같고, PREFIX는 길게 반복되는 URI를 짧은 별칭으로 줄여 코드를 읽기 쉽게 만든다. 여기에 결과로 새 그래프를 그리는 CONSTRUCT, 특정 연도 이후처럼 값의 범위를 거르는 FILTER, 논문에 DOI가 없더라도 나머지 정보는 가져오게 하는 OPTIONAL이 더해진다.

후반부 실습은 실제 파이프라인이다. rdflib로 온톨로지 파일을 읽어 트리플 저장소를 만들고, pandas로 읽은 표 데이터를 한 행씩 트리플로 바꿔 넣는다. 이때 다른 객체와 이어질 수 있는 값은 URI로, 제목이나 연도처럼 그 자체가 속성인 값은 리터럴로 구분해 넣어야 한다. 마지막에는 각 저자가 가진 외부 연구자 식별자를 owl:sameAs로 연결해, 서로 다른 출처의 정보를 같은 대상으로 묶는 방법까지 다룬다.

주요 인사이트

• 정규화는 저장 효율을 높이지만 검색을 어렵게 만든다. 관계가 많은 데이터일수록 테이블을 쪼갠 대가를 조인으로 치르게 되는데, 그래프 모델은 애초에 관계를 일급 시민으로 다뤄 이 비용을 피한다.
• SPARQL의 변수 바인딩은 계층적으로 작동한다. 조건을 나열하는 순서가 곧 후보를 좁혀 가는 순서이므로, 질의문을 읽을 때도 위에서 아래로 범위가 줄어든다고 생각하면 이해가 쉽다.
• FILTER는 이미 변수에 값이 묶인 뒤에만 쓸 수 있다. 바인딩되지 않은 변수에 조건을 걸면 오류가 나는데, 이는 질의 순서를 설계할 때 실무적으로 자주 걸리는 지점이다.
• 세미콜론과 마침표의 차이가 코드 길이를 크게 바꾼다. 세미콜론으로 이으면 앞의 주어가 그대로 유지되지만, 마침표로 문장을 끝내면 다음 줄에서 주어를 다시 써야 한다.
• URI 값은 시각화할 때 주소 전체가 그대로 노출돼 읽기 어렵다. 그래서 실습에서는 BIND와 문자열 처리로 앞부분을 잘라내고 이름만 남기는 방식을 쓴다.

자주 묻는 질문

관련 AI 소식