길리랩blog

SPARQL로 RDF 데이터를 질의하는 법 — 문법부터 배포 패턴까지

SPARQL의 SELECT/CONSTRUCT 문법, HTTP 프로토콜과 결과 포맷, curl·Python 호출 예시, 공개 엔드포인트·자체 호스팅·OBDA 배포 패턴을 비교한다

2026-08-12 · 최초 발행 2025-11-26

RDF 트리플로 데이터를 쌓았다면, 다음 질문은 그것을 어떻게 꺼내느냐다. SPARQL(SPARQL Protocol and RDF Query Language)은 웹에 공개된 RDF 데이터를 표준화된 방식으로 질의·전송·결과수집하기 위한 언어·프로토콜·결과포맷 규정의 집합이다. 지식그래프, 오픈데이터 포털, 메타데이터 허브 같은 분산 웹 리소스에 일관된 질의를 수행하고 통합 분석을 가능하게 하는 핵심 표준으로, SQL의 SELECT-FROM-WHERE 패턴과 비슷한 문법을 쓰면서도 HTTP 기반 프로토콜과 결과 포맷 표준화로 애플리케이션 간 상호운용성을 확보한다.

언어이자 프로토콜이자 포맷 규정

SPARQL이라는 이름 아래 실제로는 세 가지가 함께 정의돼 있다.

  • SPARQL 언어: RDF 그래프에 대한 패턴 매칭 질의 언어. SELECT, CONSTRUCT, ASK, DESCRIBE 네 형태가 있고 WHERE 절에서 트리플 패턴과 필터로 그래프 매칭을 수행한다.
  • SPARQL 프로토콜: HTTP 기반 요청·응답 규격. application/sparql-query, application/sparql-update 콘텐츠 타입을 지원하고 GET/POST 전송, HTTP Accept 헤더를 통한 결과 포맷 협상을 규정한다.
  • SPARQL 결과 포맷: SELECT·ASK 결과용 JSON/XML/CSV/TSV, 그래프 결과(CONSTRUCT·DESCRIBE)용 Turtle·N-Triples·RDF/XML·JSON-LD 같은 RDF 직렬화가 표준화돼 있다.

질의 대상은 기본 그래프(Default Graph)와 명명 그래프(Named Graph)로 구성된 RDF Dataset이며 FROM/FROM NAMED 절로 쿼리 스코프를 지정한다. 이 프로토콜을 구현하는 HTTP 서비스가 SPARQL 엔드포인트이고, Triple Store부터 GRDDL 변환 파이프라인, SQL↔SPARQL 매핑(OBDA)까지 다양한 백엔드가 뒤에 붙을 수 있다.

이렇게 언어·프로토콜·포맷을 표준으로 묶어 채택하면 이기종 시스템 간 통합 비용을 30~50% 절감할 수 있다(환경 의존).

애플리케이션에서 엔진까지, 한 장으로 보는 구조

애플리케이션이 SPARQL 엔진을 거쳐 여러 형태의 데이터 소스를 질의하고 표준 포맷으로 결과를 돌려받는 흐름은 다음과 같다.

⤢✕HTTP(S)SPARQL ProtocolQuery ParsingAlgebra & OptimizationResults JSON/XML/CSV/TSVRDF Graph(Turtle/JSON-LD)ApplicationSPARQL EngineQuery Planner(RDF DataTriple Store/Graph DB)GRDDL Pipeline(XML/HTML → RDF)SQL-SPARQL Mapping(OBDA/R2RML)

입력은 SELECT/CONSTRUCT/ASK/DESCRIBE/UPDATE 질의와 GET/POST 중 선택한 HTTP 메서드다. 처리는 파싱→대수 변환→최적화→백엔드 접근(트리플 인덱스, GRDDL, OBDA)→결과 직렬화 순서로 이뤄지고, 출력은 표준 결과 포맷이며 오류가 나면 표준 HTTP 코드와 예외 메시지를 반환한다.

문법이 지원하는 것들

질의 표현력 측면에서는 SELECT-FROM-WHERE 패턴에 PREFIX, FILTER, OPTIONAL, UNION, VALUES, BIND, 서브쿼리, 집계(AVG, COUNT 등), ORDER BY, LIMIT/OFFSET을 쓸 수 있다. 속성 경로(Property Path), 경로 길이 제약, 레이블·언어 태그 처리 같은 그래프 탐색 최적화 기능도 제공한다.

프로토콜과 상호운용성 측면에서는 HTTP 기반 요청·응답 규격이 브라우저·서버·배치 환경 간 호환성을 확보하고, 콘텐츠 협상과 캐시 헤더로 네트워크 효율을 개선하며, 오류 시 400/500 계열 코드로 표준화된 핸들링이 가능하다.

결과 포맷 표준화는 SELECT 결과의 JSON/XML/CSV/TSV, 그래프 결과의 Turtle/JSON-LD 같은 RDF 직렬화를 제공하고, 스트리밍 전송과 LIMIT/OFFSET 기반 페이지네이션으로 대용량 결과를 처리할 수 있다.

이기종 데이터 소스 통합에서는 RDF 네이티브 저장소, GRDDL을 통한 문서→RDF 추출, R2RML/OBDA 기반 SQL 가상화로 단일 질의면을 제공하며, SERVICE 절을 통한 페더레이션 질의로 여러 엔드포인트를 한 쿼리에서 통합할 수 있다.

추론과 엔테일먼트 측면에서는 RDFS/OWL 엔테일먼트 레짐을 적용할 수 있고, 정적 전개(Materialization)와 질의 시 추론(On-the-fly) 사이에 트레이드오프가 있다. 추론 깊이와 규칙 설정으로 정확도와 성능의 균형을 조정한다.

실제 질의문으로 보면

SELECT-FROM-WHERE 기본

PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX dct:  <http://purl.org/dc/terms/>

SELECT ?person ?name ?created
FROM <https://example.org/graph/people>
WHERE {
  ?person a foaf:Person ;
          foaf:name ?name ;
          dct:created ?created .
  FILTER(LANGMATCHES(LANG(?name), "en"))
}
ORDER BY DESC(?created)
LIMIT 20

FROM은 질의에 쓸 기본 그래프를 지정하며 다중 FROM으로 병합할 수 있다. WHERE는 트리플 패턴과 FILTER로 조건을 지정하고, OPTIONAL/UNION으로 결측·대안 경로를 처리한다.

CONSTRUCT로 그래프 결과 만들기

PREFIX ex: <http://example.org/schema#>

CONSTRUCT {
  ?p a ex:RecentPerson ;
     ex:label ?name .
}
WHERE {
  ?p a ex:Person ; ex:name ?name ; ex:updated ?ts .
  FILTER(?ts >= "2025-01-01T00:00:00Z"^^xsd:dateTime)
}
LIMIT 100

curl로 프로토콜 호출하기

curl이 설치돼 있고 공개 SPARQL 엔드포인트에 접근할 수 있다고 가정한다.

# SELECT 결과를 JSON으로 수신
curl -H 'Accept: application/sparql-results+json' \
     -H 'Content-Type: application/sparql-query; charset=utf-8' \
     --data-binary @query.rq \
     https://query.wikidata.org/sparql

엔드포인트 정책에 따라 User-Agent를 지정하고 레이트 리밋을 지켜야 한다. 구문 오류가 있으면 400 Bad Request, 타임아웃이나 과부하 시에는 503 Service Unavailable이 돌아올 수 있다.

Python(SPARQLWrapper)으로 호출하기

Python 3.10+, pip install SPARQLWrapper>=2.0 환경을 전제한다.

from SPARQLWrapper import SPARQLWrapper, JSON

sparql = SPARQLWrapper("https://query.wikidata.org/sparql")
sparql.setReturnFormat(JSON)
sparql.setQuery("""
SELECT ?item ?itemLabel WHERE {
  ?item wdt:P31 wd:Q146 .
  SERVICE wikibase:label { bd:serviceParam wikibase:language "ko,en". }
}
LIMIT 5
""")
results = sparql.query().convert()
for b in results["results"]["bindings"]:
    print(b["item"]["value"], b["itemLabel"]["value"])

요청이 들어온 뒤 벌어지는 일

입력 단계에서는 쿼리를 수신하고 OAuth2·JWT·키 기반 인증·인가를 확인하며 요청 크기 상한을 검증한다. Accept 헤더를 파싱해 결과 직렬화를 결정하고 타임아웃·쿼리 코스트 가드를 확인한다.

처리 단계에서는 파싱 오류가 있으면 400을 반환하고, 조인 순서·인덱스 선택 같은 대수 최적화를 적용한다. 백엔드 접근은 트리플 스토어 인덱스(SPO, POS 등), GRDDL 변환 캐시, OBDA SQL 변환과 DB 최적화 힌트를 활용한다.

출력 단계에서는 스트리밍 인코딩과 페이지네이션으로 부분 결과를 전송해 서버 자원을 보호하고, 결과 서명·무결성 옵션과 ETag/Cache-Control 같은 캐시 헤더를 설정한다.

일관성·락 측면에서 읽기 질의는 다중 버전 스냅샷 일관성을 제공하는 사례가 많아 업데이트와의 충돌이 최소화된다. SPARQL Update(INSERT/DELETE/LOAD/CLEAR)의 트랜잭션 지원 여부는 구현체에 따라 다르므로, 대량 업데이트는 배치·락 정책을 별도로 설계해야 한다.

실무에서는 이렇게 쓰인다

  • 공공 오픈데이터 포털 통합: 여러 기관의 RDF 카탈로그를 페더레이션으로 통합 질의하고, 메타데이터 품질 검증과 자동 카탈로깅을 구현한다.
  • 엔터프라이즈 지식그래프: 제품·고객·프로세스 온톨로지 기반 연계 분석을 하고, CONSTRUCT로 도메인별 뷰 그래프를 생성한다.
  • 문서·로그 메타데이터 인덱싱: GRDDL·마이크로데이터 추출로 문서를 RDF로 변환하고, SPARQL로 거버넌스 규칙 준수 여부를 점검한다.
  • 관계형 DB 가상화(OBDA): R2RML/온톱(Ontop)으로 SQL 테이블을 가상 RDF로 노출해 애플리케이션이 SPARQL 단일 인터페이스만 쓰게 한다.
  • 검색·추천·질의응답: 속성 경로와 레이블 서비스로 개체 링크를 강화하고, 사용자 질의 의도에 따른 그래프 탐색 기반 추천을 구현한다.

배포 패턴

패턴 성능 확장성 일관성 안정성 운영 편의
공개 SPARQL 엔드포인트 활용 네트워크·레이트리밋 영향, 변동성 존재 프로바이더 종속 읽기 중심, 엔테일먼트 정책 외부 의존 SLA 미보장 사례 존재 운영 부담 최소
사내 트리플 스토어 호스팅 로우레턴시, 튜닝 여지 큼 수평/수직 확장 옵션 다양 트랜잭션·스냅샷 일관성 구성 가능 모니터링·백업으로 안정성 제어 초기 구축·운영 비용 존재
OBDA(가상화, SQL→SPARQL) DB 성능에 의존, 조인 폭넓음 DB 스케일 전략 활용 소스 DB 일관성 준수 DB 성숙도 수준의 안정성 RDF 중복 저장 불필요, 매핑 관리 필요

공개 엔드포인트는 운영 부담이 가장 적지만 SLA를 보장받기 어렵고, 사내 트리플 스토어는 튜닝 여지가 크지만 구축·운영 비용을 감수해야 한다. OBDA는 RDF를 별도로 저장하지 않아도 되지만 매핑 관리라는 새로운 운영 부담이 생긴다.

세 배포 패턴 중 요구사항에 맞는 것을 고르되, 타임아웃·페이지네이션·레이트리밋·엔테일먼트 정책은 어떤 패턴을 선택하든 운영 레벨에서 엄격히 관리해야 한다. 동일 쿼리를 소스 교체만으로 재활용하고 페더레이션으로 신규 소스를 무중단으로 편입할 수 있다는 점, SELECT-FROM-WHERE에 익숙한 팀이라면 질의 개발·디버깅 시간을 줄일 수 있다는 점도 표준을 채택하는 실질적인 이유다.

SPARQLRDF질의 언어지식그래프페더레이션