파일 변환을 통한 지식 그래프 구축: 문서를 구조화된 데이터로 전환하기

지식 그래프는 학술적인 호기심 수준에서 검색 엔진, 추천 시스템, 기업 데이터 플랫폼의 핵심 구성 요소로 자리 잡았습니다. 그 힘은 엔터티, 관계, 속성을 기계가 읽을 수 있는 연결된 형식—주로 RDF(Resource Description Framework) 또는 JSON‑LD—으로 표현하는 데 있습니다. 그러나 지식 그래프에 공급되는 대부분의 정보는 PDF 연구 논문, Word 계약서, Excel 재고 목록, 레거시 보관 파일 등 비정형 또는 반정형 파일에 들어 있습니다. 의미, 출처, 법적 준수성을 잃지 않으면서 이러한 파일을 구조화된 트리플로 변환하는 일은 결코 사소한 엔지니어링 문제가 아닙니다.

이 글에서는 일상적인 사무 문서를 지식 그래프용 데이터로 바꾸는 완전하고 프로덕션 수준의 워크플로우를 단계별로 살펴봅니다. 왜 변환이 필요한지, 사전 준비, 실제 변환 기법, 검증, 프라이버시 보호, 그리고 최종적으로 결과물을 그래프 스토어에 적재하는 방법을 다룹니다. 가이드는 의도적으로 플랫폼에 구애받지 않지만, 필요 시 초기 포맷‑투‑포맷 단계에서 편리하고 프라이버시를 우선시하는 도구로 convertise.app을 참고합니다.

왜 파일 변환이 지식 그래프 구축에 중요한가

지식 그래프는 입력되는 데이터만큼이나 좋습니다. 원본이 지저분한 PDF, 스캔 이미지, 혹은 셀 병합이 난무한 스프레드시트인 경우, 다운스트림 추출 과정이 실패하거나 노이즈가 많은 트리플을 생성해 쿼리 정확도를 떨어뜨립니다. 적절한 파일 변환은 두 가지 핵심 목적을 수행합니다.

입력 정규화 – PDF를 검색 가능하고 텍스트가 풍부한 포맷(예: PDF‑A → 평문 텍스트 또는 HTML)으로 변환하면 OCR 병목 현상을 없앨 수 있습니다. 마찬가지로 레거시 Office 이진 파일(.doc, .xls)을 오픈‑XML 변형(.docx, .xlsx)으로 바꾸면 파서가 헤딩, 테이블, 메타데이터를 안정적으로 찾을 수 있습니다.
컨텍스트 메타데이터 보존 – 저자, 생성일, 버전, 사용자 정의 속성을 유지하는 변환 도구는 결과 RDF에 출처 정보를 자동으로 포함시킵니다. 지식 그래프에서 출처는 1급 시민이며, 신뢰 점수, 감사 추적, GDPR 같은 규제 준수에 필수적입니다.

정밀하게 변환이 이루어지면, 다운스트림 의미 추출 단계는 데이터를 어떻게 읽을지가 아니라 데이터가 무엇을 말하고 있는지에 집중할 수 있습니다.

의미 대상 이해하기: RDF, JSON‑LD, CSV

변환 캠페인을 시작하기 전에 목표 직렬화 포맷을 정의하세요. 각각의 강점은 다음과 같습니다.

RDF/Turtle – 복잡한 어휘, 맞춤형 온톨로지, 명시적인 주어‑서술어‑목적어 트리플이 필요할 때 최적입니다. SPARQL 쿼리의 공통 언어이기도 합니다.
JSON‑LD – JSON과 호환되는 표현으로, 링크드‑데이터 컨텍스트를 직접 포함합니다. 개발자 친화적이며 웹 API와 잘 어울리고, 풍부 스니펫을 제공하는 검색 엔진에서도 점점 지원이 늘고 있습니다.
CSV – 제품 카탈로그처럼 표형 데이터에서 지식 그래프를 구축할 경우, 잘 정돈된 CSV를 OpenRefine이나 W3C CSV on the Web 명세와 같은 도구로 바로 RDF에 매핑할 수 있습니다.

선택은 변환 경로를 결정합니다. 예를 들어, 화학 물질 표가 포함된 PDF는 먼저 CSV로 렌더링한 뒤 RDF로 매핑하는 것이 최적일 수 있습니다. 계약서와 같은 Word 문서는 당사자, 날짜, 의무 등을 개별 엔터티로 유지하면서 직접 RDF 또는 JSON‑LD로 출력하는 것이 좋습니다.

시맨틱 추출을 위한 소스 파일 준비

원시 파일에는 추출 오류를 일으키는 장애물이 숨어 있는 경우가 많습니다. 체계적인 준비 단계가 큰 이득을 줍니다.

인코딩 조기 탐지 – 텍스트 파일은 UTF‑8, UTF‑16, 레거시 Windows‑1252 등 다양한 인코딩을 사용할 수 있습니다. Python의 chardet 같은 도구로 인코딩을 식별하고, 변환 전에 UTF‑8로 재인코딩하세요. 이는 RDF 리터럴에서 깨진 문자를 방지합니다.
줄바꿈 정규화 – CR, LF, CRLF 혼용은 특히 CSV 생성 시 줄‑단위 파서를 망가뜨립니다. dos2unix 등 유틸리티로 모두 LF(\n)로 변환하세요.
내장 미디어 분리 – PDF에는 차트, 서명 등 중요한 데이터를 담은 이미지가 삽입돼 있는 경우가 많습니다. pdfimages 혹은 클라우드 서비스를 사용해 이미지를 먼저 추출하고, 그래프에서 foaf:Image 또는 schema:ImageObject와 연결합니다.
복잡 레이아웃 평탄화 – 여러 페이지에 걸친 테이블, 병합 셀, 중첩 목록은 평탄화가 필요합니다. PDF용 Tabula, Word용 pandoc 등으로 테이블을 CSV로 내보내면서 컬럼 헤더를 유지합니다.
라이선스 및 권한 검증 – 콘텐츠 재활용 권한을 확인하세요. 제3자 문서인 경우 원본 라이선스 URL을 dcterms:license 트리플로 저장해 두는 것이 좋습니다.

이러한 사전 점검을 마치면 파일을 결정론적으로 변환할 준비가 된 것입니다.

문서를 구조화된 포맷으로 변환하기

아래는 가장 흔히 마주치는 세 종류의 소스 파일군에 대한 구체적인 변환 파이프라인 예시입니다.

1. PDF → Text/HTML → RDF 또는 JSON‑LD

Step 1 – 텍스트 추출: 시각적 계층(헤딩, 리스트, 테이블)을 보존하는 PDF‑to‑HTML 변환기를 사용합니다. 오픈소스 pdf2htmlEX는 CSS 클래스를 유지해 논리 구조와 매핑합니다.
Step 2 – 시맨틱 어노테이션: Apache Tika와 커스텀 정규식 패턴을 결합한 규칙 기반 엔진으로 헤딩을 schema:Article 섹션, 테이블을 schema:Table, 인라인 인용을 schema:CreativeWork 참조로 태깅합니다.
Step 3 – RDF 생성: 어노테이션된 HTML을 XSLT 또는 Python 스크립트에 넘겨 DOM을 순회하면서 각 섹션에 URI(_:section1)를 만들고 트리플을 방출합니다. 테이블 행 한 줄의 예시 트리플은 다음과 같습니다:

:compound123 a chem:Compound ;
    chem:hasName "Acetaminophen" ;
    chem:hasMolecularWeight "151.16"^^xsd:float ;
    dcterms:source <file:///documents/report.pdf#page12> .

Step 4 – JSON‑LD 패키징: 다운스트림 소비자가 JSON‑LD를 선호한다면, 동일 RDF 그래프를 공개 온톨로지에 매핑된 컴팩트 컨텍스트로 직렬화합니다.

2. Word (.docx) → Structured XML → RDF/JSON‑LD

Step 1 – OOXML 추출: .docx 파일은 document.xml을 포함한 ZIP 아카이브입니다. ZIP을 풀고 XML 파서를 이용해 파일을 읽습니다. Word의 스타일 계층(Heading1, Heading2 등)은 그래프 섹션과 깔끔히 매핑됩니다.
Step 2 – 테이블 정규화: <w:tbl> 요소를 추출해 CSV 행으로 변환한 뒤, 컬럼 헤더에 따라 schema:Product 혹은 schema:Event 엔터티를 만드는 매핑 스크립트에 넘깁니다.
Step 3 – 사용자 정의 속성 보존: Word 문서는 docProps/custom.xml에 사용자 정의 메타데이터를 저장합니다. 각각의 <property> 요소를 dcterms:description 혹은 도메인 전용 프레디케이트에 매핑합니다.
Step 4 – RDF 방출: Jinja2 같은 템플릿 엔진으로 XML 트리를 Turtle로 변환합니다. 각 단락은 schema:Paragraph와 schema:text 리터럴이 되고, 헤딩은 schema:headline을 가집니다.

3. Spreadsheet (XLSX/CSV) → CSV → RDF via Mapping Files

Step 1 – 통합 CSV 내보내기: XLSX는 xlsx2csv 혹은 pandas 라이브러리를 사용해 각 시트를 별도 CSV로 평탄화합니다. 날짜·숫자 등 셀 유형은 ISO‑8601 문자열이나 xsd 데이터 타입으로 변환합니다.
Step 2 – 매핑 사양 – YAML 또는 RML 형식의 매핑 파일을 작성해 각 컬럼을 RDF 프레디케이트에 매핑합니다. 예시:

mapping:
  - source: product_id
    predicate: schema:productID
  - source: price_usd
    predicate: schema:price
    datatype: xsd:decimal
  - source: release_date
    predicate: schema:datePublished
    datatype: xsd:date

Step 3 – 변환 엔진 – rmlmapper-java와 같은 RML 프로세서를 실행해 Turtle 트리플 스트림을 생성하고, 바로 적재합니다.

컨텍스트 보존, 온톨로지 정렬, URI 관리

구문적으로는 올바른 RDF를 생성했지만 의미가 모호한 트리플은 활용도가 떨어집니다. 의미를 유지하려면 다음 원칙을 따르세요.

안정적인 URI – DOI, ISBN, 혹은 문서 해시 + 섹션 번호와 같이 변하지 않는 속성을 기반으로 식별자를 생성합니다. 이후 파일명 변경 등에 흔들리지 않게 됩니다.
온톨로지 재사용 – 새로운 프레디케이트를 만들기 전에 Schema.org, FOAF, DC, 혹은 bio:Gene 같은 도메인 전용 온톨로지를 검색해 재사용합니다. 이는 상호 운용성을 높이고 매핑 작업을 줄여줍니다.
소스에 링크 – 항상 dcterms:source 트리플을 추가해 원본 파일 혹은 특정 페이지·섹션을 가리키게 합니다. 감사자와 사용자 모두 진위 확인에 크게 도움이 됩니다.
버전 주석 – 원본 문서가 버전 관리되고 있다면 schema:version 트리플에 Git 커밋 해시나 문서 개정 번호를 기록합니다.

대용량 코퍼스 처리: 배치 변환 전략

기업 환경에서는 매일 수천 개의 PDF와 스프레드시트를 처리해야 할 수 있습니다. 변환 파이프라인을 확장하려면 다음을 고려하세요.

청크 나누기 – 작업을 500~1,000 파일 단위 배치로 분할합니다. RabbitMQ, AWS SQS 같은 메시지 큐를 이용해 변환 작업을 워커 노드에 전달합니다.
무상태 워커 – 각 워커는 스토리지(S3 등)에서 파일을 가져와 컨테이너화된 툴체인(pandoc, pdf2htmlEX, 커스텀 스크립트)으로 변환하고, 결과 RDF를 트리플 스토어 엔드포인트에 푸시합니다.
멱등성 – 동일 파일에 대해 재실행해도 동일 RDF가 생성되도록 설계합니다. 소스 파일 해시와 생성된 그래프 해시를 저장하고, 해시가 일치하면 재적재를 건너뛰세요.
모니터링 및 재시도 – Prometheus 메트릭으로 변환 성공률을 추적합니다. 실패한 작업은 지수 백오프 방식으로 재시도하고, 영구 오류는 수동 검토를 위해 로그에 남깁니다.
convertise.app 활용 – 특히 CorelDRAW 파일을 SVG로 변환하는 등 자체 툴체인에 없는 포맷을 한 번에 변환할 때는 convertise.app이 빠르고 프라이버시 중심적인 다리 역할을 합니다.

품질 보증: 검증, SHACL, 자동 테스트

변환 후에는 구문적·의미적 정확성을 모두 검증해야 합니다.

구문 검사 – RDF를 rapper(Redland) 같은 파서에 통과시켜 Turtle이나 JSON‑LD의 형식 오류를 잡습니다.
Shape 제약 (SHACL) – 기대하는 그래프 구조를 SHACL 형태로 정의합니다. 예를 들어 제품 카탈로그에서는 schema:price가 소수점(decimal)이어야 하고, schema:productID가 비어 있지 않은 문자열이어야 하며, schema:availability는 제어된 어휘 중 하나여야 합니다.
SPARQL 일관성 테스트 – 중요한 트리플이 존재함을 확인하는 ASK 쿼리를 작성합니다(예: 모든 schema:Person에는 schema:name이 있어야 함). CI 파이프라인에 이 쿼리를 자동화합니다.
라운드‑트립 테스트 – RDF를 인간이 읽을 수 있는 포맷(CSV 등)으로 다시 변환하고, 원본 파일과 diff 도구로 비교합니다. 작은 차이는 공백 손실이나 숫자 반올림 오류를 드러낼 수 있습니다.

프라이버시, 라이선스, 윤리적 고려사항

개인 데이터가 포함된 파일을 변환할 때는 GDPR, CCPA 등 관할 규정을 반드시 준수해야 합니다.

데이터 최소화 – 지식 그래프에 필요한 필드만 추출합니다. PDF에 전체 주소가 들어 있어도 그래프에서 도시와 국가만 필요하다면 나머지는 버립니다.
가명화 – 이메일, 전화번호 등 직접 식별자를 별도의 솔트와 함께 해시 처리합니다. 매핑 파일은 보안 금고에 별도 보관해 감사 용도로만 사용합니다.
라이선스 전파 – 원본 문서의 라이선스 URL을 dcterms:license 트리플로 포함합니다. Creative Commons 라이선스인 경우 파생 엔터티마다 해당 정보를 전파합니다.
보존 정책 – 변환된 RDF의 보존 기간을 결정하고, 특히 민감한 계약서와 같은 경우 원본 문서의 연령에 따라 자동 만료를 구현합니다.

지식 그래프 스토어로 변환 데이터 적재하기

클린 RDF를 확보했다면 마지막 단계는 그래프 데이터베이스에 로드하는 일입니다. 네이티브 트리플 스토어(Blazegraph, GraphDB)와 속성‑그래프 시스템(Neo4j + RDF 플러그인) 간 차이가 있습니다.

벌크 로드 – 대부분의 스토어는 INSERT DATA 전체 구문이나 Turtle/NT 파일을 직접 읽는 벌크 로더를 지원합니다. 논리적 접근 제어를 위해 graph:finance, graph:research처럼 논리적 네임드 그래프로 파티셔닝합니다.
스트리밍 적재 – 연속 파이프라인인 경우, 각 배치가 끝날 때마다 SPARQL 1.1 UPDATE와 INSERT 문을 사용합니다. Kafka 커넥터를 이용하면 실시간으로 트리플을 스트리밍할 수 있습니다.
인덱싱 – 제목·초록 등 검색이 잦은 리터럴에 전체 텍스트 인덱스를 활성화합니다. 일부 스토어는 schema:geo 프레디케이트에 대한 지오 인덱스도 제공해 주소 데이터 검색에 유용합니다.
쿼리 검증 – 로드 후에는 실제 운영 시나리오를 반영한 베엔치마크 쿼리를 실행합니다(예: “2020년 이후 체결된 계약 중 상장 기업인 상대방을 찾는다”). 응답 시간과 결과 완전성을 확인합니다.

실전 예시: 연차 보고서를 지식 그래프로 전환하기

시나리오: 재무 분석가가 기업의 지난 10년 연차 보고서에 나타난 “순이익”을 모두 조회하고 싶습니다. 보고서는 PDF 형식으로 제공됩니다.

PDF 수집 – PDF를 연도별 키로 S3 버킷에 저장합니다.
사전 점검 – pdfinfo로 각 파일이 PDF/A‑1b(아카이브)인지 확인합니다. pdf2htmlEX로 HTML로 변환하면서 헤딩을 보존합니다.
테이블 추출 – HTML 클래스 table 중 “Profit”이라는 단어가 포함된 테이블을 찾아 tabula-java로 CSV로 내보냅니다.
RDF 매핑 – 각 연도마다 schema:FinancialStatement 엔터티를 만들고, 행마다 schema:Revenue, schema:NetProfit, schema:OperatingExpense 트리플을 생성하도록 RML 매핑을 작성합니다. 숫자는 xsd:decimal 타입으로 캐스팅합니다.
출처 추가 – prov:wasGeneratedBy를 사용해 변환 스크립트 버전과 원본 PDF S3 URI를 기록한 prov:Activity와 연결합니다.
검증 – 모든 schema:FinancialStatement에 schema:NetProfit이 존재하도록 SHACL 형태를 실행합니다. 누락된 경우 로그에 남겨 수동 검토합니다.
적재 – Turtle를 GraphDB에 graph:annual_reports 네임드 그래프로 로드합니다. schema:financialMetric 리터럴에 대한 전체 텍스트 인덱스를 활성화합니다.
쿼리 – 다음 SPARQL을 실행합니다:

SELECT ?year ?netProfit WHERE {
  GRAPH <graph:annual_reports> {
    ?stmt a schema:FinancialStatement ;
          schema:year ?year ;
          schema:NetProfit ?netProfit .
  }
}
ORDER BY ?year

이제 분석가는 PDF를 일일이 열어보지 않고도 연도별 순이익 목록을 정렬된 형태로 손쉽게 얻을 수 있습니다.

파일‑to‑그래프 변환 최적 실천 체크리스트

목표 직렬화 정의 (RDF/Turtle, JSON‑LD, CSV) → 초기 변환 계획 수립
인코딩·줄바꿈 정규화 → 숨겨진 문자 오류 방지
내장 미디어 별도 추출 → foaf:Image 등으로 링크
중간 단계에 오픈 포맷 사용 (HTML, CSV) → 파이프라인 가시성 확보
원본 메타데이터 보존 (저자, 생성일, 라이선스) → 출처 트리플 자동 생성
안정적, 네임스페이스‑aware URI 생성 → 불변 식별자 활용
기존 온톨로지 재사용 → 상호 운용성 강화
SHACL·SPARQL ASK 로 자동 검증 → 품질 보증 파이프라인 구축
개인 데이터 최소화·가명화 → 프라이버시 규정 준수
라이선스 명시 → 모든 파생 엔터티에 dcterms:license 포함
대용량 배치 처리 시 무상태 워커·멱등 설계 → 안정적 확장
성공률 모니터링·로그 보관 → 운영 가시성 확보
특수 포맷 변환이 필요할 때 convertise.app 활용 → 코드 없이 빠른 전환

결론

일상적인 사무 파일을 지식 그래프용 데이터로 바꾸는 일은 파일 포맷 다루기와 시맨틱 웹 베스트 프랙티스를 결합한 체계적인 과정입니다. 변환을 데이터 품질 파이프라인의 첫 관문으로 보고, 인코딩 정규화, 구조 단서 추출, 출처 보존, SHACL 검증을 단계별로 수행하면 잡음이 많은 PDF와 스프레드시트를 깔끔하고 쿼리 가능한 그래프로 만들 수 있습니다.

그 결과는 다음과 같습니다. 다운스트림 분석이 빨라지고, 감사자는 투명한 출처 정보를 얻으며, 기업은 동일한 구조화 데이터를 검색, 추천, AI 모델 등에 재활용할 수 있습니다. 비정형 문서량이 계속 늘어가는 지금, 파일 변환을 통한 지식 그래프 구축 역량은 데이터 엔지니어, 기록 보존 담당자, 그리고 숨겨진 가치를 끌어내고자 하는 모든 사람에게 필수적인 기술이 될 것입니다.

지식 그래프를 위한 파일 변환: 문서를 구조화된 데이터로 전환하기