0. 핵심 요약

Chapter 3은 Human Phenotype Ontology(HPO)를 이용해 희귀질환 진단을 지원하는 첫 지식 그래프를 만드는 구현 장이다. 겉으로는 Neo4j와 Cypher 실습처럼 보이지만, 실제 핵심은 문제 정의 → 데이터 의미 이해 → 표현 모델 선택 → 적재와 품질 통제 → 질문과 추론의 설계 순서다. 임상의에게 필요한 것은 “그래프가 있다”는 사실이 아니라, 관찰한 표현형 조합에서 후보 질병을 찾고 그 연결의 출처·증거·작성일을 검토할 수 있는가이다.

이를 위해 장은 성격이 다른 두 HPO 원천을 결합한다. hp.owl은 표현형의 표준 정의와 subClassOf 계층을 제공하고, phenotype.hpoa는 질병–표현형 연관과 그 근거를 제공한다. 온톨로지의 표현력은 보존하되 관계별 메타데이터를 쉽게 탐색하려고 LPG와 Neo4j를 선택하고, Neosemantics로 RDF/OWL을 가져온다. 완성된 그래프는 직접 연결 질의뿐 아니라 상위 표현형 범주 아래의 하위 개념을 따라 암시적 후보까지 확장한다.

이 장은 개념 장이 아니라 구현 장이다. 그래서 이 리포트는 교재 Listing 3.5–3.28의 코드를 본문에 함께 싣고 한 줄씩 쉬운 말로 풀었다. §2.2는 같은 사실 하나를 RDF 세 방식과 LPG로 각각 적어 비교하고, §3은 온톨로지 적재부터 정제까지의 파이프라인을, §5–6은 추론과 근거 추적 질의를 다룬다.

아울러 이 회차의 학습 노트북 03_chapter_guide.ipynb가 모든 리스팅을 실제 Neo4j에서 끝까지 실행한 기록을 남겼다. 그 실측치를 책 값과 나란히 놓으면 재현에 관한 사실이 드러난다 — 적재 트리플은 899,558에서 926,450으로 늘었고, 진단 질의의 1위 후보는 그대로지만 2위 이하는 바뀌었으며, 책 표 3.3이 강조한 Hyperglycemia는 더 이상 내분비계 이상의 하위가 아니다. 코드는 그대로인데 결과가 달라지는 이 세 가지가 §3.4·4.2·5.2의 주제다.

1. 그래프보다 먼저 임상 질문을 고정한다

1.1 형식보다 어려운 것은 ‘같은 뜻인가’이다

XML, CSV, JSON 같은 형식 차이는 파서로 처리할 수 있다. 더 어려운 문제는 의미다. 제2형 당뇨병과 ketosis-resistant diabetes처럼 같은 개념이 다른 이름으로 나타나고, PE처럼 physical examination과 pulmonary embolism이라는 서로 다른 뜻을 가질 수 있다. necrosis와 lobular necrosis처럼 표현의 세분성도 다르다. 문자열을 정규화하는 것만으로는 이 차이를 안전하게 합칠 수 없다.

온톨로지는 표준 이름·식별자·동의어·속성·범주·관계를 정의한다. 각 원천의 로컬 필드를 온톨로지 개념에 매핑하면 서로 다른 원천이 같은 의미 좌표를 공유한다. 중요한 경계는 매핑도 하나의 주장이라는 점이다. 어떤 로컬 값이 어느 표준 개념과 같은지, 누가 언제 어떤 근거로 판단했는지를 추적해야 한다.

교재 §3.1의 의미 통합 설명을 발표자가 문제–매핑–통합 질의의 흐름으로 재구성.

1.2 목표는 자동 진단이 아니라 검토 가능한 후보 탐색이다

이 장의 대상 사용자는 질병을 진단하고 치료하는 임상의다. 특히 희귀질환은 한두 증상으로 식별하기 어렵고, 여러 표현형 특징의 조합과 문헌 근거를 함께 살펴야 한다. 따라서 지식 기반에는 두 가지가 필요하다. 첫째, 같은 기관·계통에 속하는 표현형 이상을 연결하는 맥락적 계층. 둘째, 질병과 표현형의 연관뿐 아니라 출처·증거·빈도·작성자를 추적할 수 있는 주석이다.

도메인에는 경계 사례도 있다. 제1형 당뇨병은 하나의 질병으로 식별될 수 있고, 다른 희귀 증후군에서 관찰되는 표현형 특징으로도 식별될 수 있다. 한 문자열에 역할을 억지로 합치지 않고 OMIM:222100과 HP:0100651처럼 서로 다른 표준 ID를 사용하면, 질문의 문맥에 따라 질병 노드와 표현형 노드를 구분할 수 있다.

2. 두 데이터 원천이 모델 선택을 결정한다

2.1 HPO는 ‘어휘’와 ‘주석’을 따로 준다

hp.owl은 RDF/XML로 직렬화된 OWL 온톨로지다. 각 표현형을 owl:Class로 정의하고 URI, 자연어 정의, 작성자·작성일, 외부 데이터베이스 상호참조, 동의어, rdfs:subClassOf를 제공한다. 이 가운데 계층은 나중에 “내분비계 이상” 같은 넓은 질문을 더 구체적인 표현형까지 확장하는 추론의 재료가 된다.

phenotype.hpoa는 TSV 형식의 주석 파일이다. 각 행은 질병 ID와 표현형 ID의 연관을 주장하며, PubMed나 OMIM 출처, IEA·PCS·TAS 증거 코드, 발현 시점, 빈도, 성별, 수정자, 큐레이터와 날짜를 함께 담는다. 이 정보는 질병이나 표현형 자체의 속성이 아니라 둘 사이 특정 연결의 속성이다.

교재 §3.1.2, 그림 3.5–3.6과 Listing 3.1–3.4의 의미를 새로 배치. 정의·계층은 표현형 노드에, 한 건의 연관을 뒷받침하는 근거는 질병–표현형 관계에 둔다. 원본 도형을 복제하지 않음.

2.2 RDF와 LPG는 요구를 기준으로 비교한다

RDF는 주어–술어–목적어 트리플을 기본 단위로 하며, W3C 표준과 웹 식별자, 상호운용, 풍부한 온톨로지 표현에 강하다. LPG는 노드와 개별 관계에 키–값 속성을 둘 수 있어 경로 순회와 관계 메타데이터 접근이 직관적이다. RDF가 “관계에 속성을 붙일 수 없다”는 단순 비교는 정확하지 않다. n항 관계, 명명 그래프, RDF-star처럼 문장에 대한 메타데이터를 표현하는 방법이 있으며, 대신 모델·질의·엔진 지원의 복잡성이 달라진다.

이 장의 사용자 질문은 특정 질병–표현형 연관의 출처·작성자·날짜를 비교하는 데 집중한다. 그래서 저자는 관계 속성을 직접 다루는 LPG와 Cypher를 선택하고, Neosemantics로 RDF/OWL 어휘와 일부 추론 기능을 Neo4j에 가져온다. 이는 “LPG가 RDF보다 낫다”가 아니라 표준 온톨로지를 입력으로 사용하면서 애플리케이션 질의는 관계 중심으로 최적화한 하이브리드 결정이다.

교재 §3.2.2, Listing 3.5–3.12의 구조를 관계 메타데이터라는 동일 질문으로 재구성. n항 관계는 Annotation 자원에서 질병·표현형으로 나가는 관계를, 명명 그래프는 문장 묶음의 맥락을, RDF-star는 인용된 트리플의 메타데이터를, LPG는 개별 관계의 키–값을 보여준다.

# 적는 법 — 이름 없는 노드(_:Annotation)를 만들어 질병·표현형·근거를 모두 매단다
_:Annotation rdf:type :PhenotypicAnnotation ;
    :forDisease        OMIM:222100 ;
    :phenotypicFeature HP:0410050 ;
    :source            PMID:9357814 ;
    :createdBy         "Nicole Vasilevsky" ;
    :creationDate      "2018-02-23"^^xsd:date .

# 꺼내는 법 (SPARQL) — 질병·표현형으로 그 노드를 먼저 찾고 나서 근거를 읽는다
SELECT ?source ?author ?date WHERE {
  ?annotation a :PhenotypicAnnotation ;
      :forDisease        OMIM:222100 ;
      :phenotypicFeature HP:0410050 ;
      :source ?source ; :createdBy ?author ; :creationDate ?date .
}

# 적는 법 (TriG) — 문장을 :Graph1 이라는 상자에 넣고, 상자에 근거를 붙인다
:Graph1 {
    OMIM:222100 :hasPhenotypicFeature HP:0410050
}
:Graph1
    :source       PMID:9357814 ;
    :createdBy    "Nicole Vasilevsky" ;
    :creationDate "2018-02-23"^^xsd:date .

# 꺼내는 법 (SPARQL) — 상자 안을 확인하고, 상자 바깥의 근거를 읽는다
SELECT ?source ?author ?date WHERE {
  GRAPH :Graph1 { OMIM:222100 :hasPhenotypicFeature HP:0410050 . }
  :Graph1 :source ?source ; :createdBy ?author ; :creationDate ?date .
}

# 적는 법 — << >> 로 문장 하나를 통째로 감싸 그것을 다시 주어로 쓴다
<<OMIM:222100 :hasPhenotypicFeature HP:0410050>>
    :source       PMID:9357814 ;
    :createdBy    "Nicole Vasilevsky" ;
    :creationDate "2018-02-23"^^xsd:date .

# 꺼내는 법 (SPARQL-star) — 같은 << >> 표기로 바로 읽는다
SELECT ?source ?author ?date {
  <<OMIM:222100 :hasPhenotypicFeature HP:0410050>>
      :source ?source ; :createdBy ?author ; :creationDate ?date .
}

// 적는 법 — 화살표 안 중괄호에 키–값을 그대로 넣는다
(d {id: "OMIM:222100"})
  -[:HAS_PHENOTYPIC_FEATURE {
      source:       "PMID:9357814",
      createdBy:    "Nicole Vasilevsky",
      creationDate: "2018-02-23"
  }]->
(p {id: "HP:0410050"})

// 꺼내는 법 (Cypher) — 관계에 변수 r 을 붙이고 r 의 속성을 읽는다
MATCH (d)-[r:HAS_PHENOTYPIC_FEATURE]->(p)
WHERE d.id = "OMIM:222100" AND p.id = "HP:0410050"
RETURN r.source, r.createdBy, r.creationDate

3. 적재는 파일 복사가 아니라 의미 계약의 구현이다

3.1 CRISP-DM을 일곱 개의 산출물로 바꾼다

이 장은 Chapter 2의 CRISP-DM 변형을 구체적인 KG 구축 절차로 바꾼다. 비즈니스 이해에서는 대표 임상 질문을, 데이터 이해에서는 두 HPO 원천의 의미와 식별자를, 설계에서는 RDF/LPG 선택 근거를 남긴다. 구현은 온톨로지 적재와 주석 적재로 나뉘며, 정제 뒤 직접 질의와 계층 추론으로 사용 가치를 확인한다.

교재 그림 3.1–3.2, 3.7, 3.9–3.10의 전체 흐름을 산출물과 검증 지점 중심으로 통합 재구성. 각 단계가 남겨야 할 산출물은 대표 질문, 원천 계약, 모델 선택 근거, 적재 로그, 품질 점검과 재현 가능한 질의다.

^* 899,558은 Neo4j/APOC/n10s 5.20.0과 HPO 2025-02를 사용한 교재 실행값이다. 현재 릴리스의 정답 건수가 아니라 스냅샷 재현 기준선으로 사용한다.

// ① 그릇 만들기 (책 3.13) — Enterprise 전용 명령이다
CREATE DATABASE hpo IF NOT EXISTS

// ② 중복을 막는 장치 (책 3.14) — 단순 무결성 장치가 아니다.
//    uri 유일성이 있어야 n10s 가 온톨로지를 MERGE 로 '몇 번 돌려도 같게' 적재한다
CREATE CONSTRAINT n10s_unique_uri IF NOT EXISTS FOR (r:Resource) REQUIRE r.uri IS UNIQUE;
CREATE CONSTRAINT IF NOT EXISTS FOR (n:Resource) REQUIRE (n.id) IS UNIQUE;
CREATE INDEX disease_id   IF NOT EXISTS FOR (n:HpoDisease)   ON (n.id);
CREATE INDEX phenotype_id IF NOT EXISTS FOR (n:HpoPhenotype) ON (n.id);

// ③ 변환 규칙 정하기 (책 3.15) — 이 두 줄이 이후 모든 Cypher 의 생김새를 결정한다
CALL n10s.graphconfig.init();
CALL n10s.graphconfig.set({ handleVocabUris: "IGNORE" });   // 네임스페이스를 버린다
CALL n10s.graphconfig.set({ applyNeo4jNaming: True });      // 관계 타입을 대문자로

// ④ 적재 (책 3.16) — 딱 한 줄이다
CALL n10s.rdf.import.fetch("http://purl.obolibrary.org/obo/hp.owl", "RDF/XML");

// ⑤ 접합면 만들기 (책 3.17) — 이 장에서 가장 중요한 다섯 줄
MATCH (n:Resource)
WHERE n.uri STARTS WITH "http://purl.obolibrary.org/obo/HP"
SET n:HpoPhenotype,
    n.id = coalesce(n.id,
      replace(apoc.text.replace(n.uri, '(.*)obo/', ''), '_', ':'))

3.2 한 행을 한 건의 감사 가능한 주장으로 보존한다

교재의 Cypher는 TSV를 읽어 질병과 표현형을 MERGE하고, 관계가 만들어진 뒤 원시 필드와 사람이 읽을 설명을 순차적으로 추가한다. FOREACH(CASE …) 패턴은 값이 있는 필드만 설정해 null로 기존 값을 덮지 않는다. APOC 정규식은 biocuration에서 큐레이터와 날짜를 뽑고, 증거 코드 IEA·PCS·TAS를 설명으로 바꾼다.

// ① 질병 노드 만들기 (책 3.19)
LOAD CSV FROM 'https://mng.bz/qRyr' AS row
FIELDTERMINATOR '\t'
WITH row
SKIP 5                                        // 메타데이터 4줄 + 헤더 1줄을 건너뛴다
MERGE (dis:Resource:HpoDisease {id: row[0]})  // 같은 질병이 여러 행에 나오므로 MERGE
ON CREATE SET dis.label = row[1];             // 이름은 처음 만들 때만 채운다

// ② 질병 ↔ 표현형 잇기 (책 3.20)
LOAD CSV FROM 'https://mng.bz/qRyr' AS row
FIELDTERMINATOR '\t'
WITH row
SKIP 5
MATCH (dis:HpoDisease)   WHERE dis.id = row[0]   // TSV 0번 열 = OMIM:222100
MATCH (phe:HpoPhenotype) WHERE phe.id = row[3]   // TSV 3번 열 = HP:0410050
MERGE (dis)-[:HAS_PHENOTYPIC_FEATURE]->(phe)

// ③ 관계에 근거 붙이기 (책 3.22) — 열 8개를 그대로 관계 속성으로
LOAD CSV FROM 'https://mng.bz/qRyr' AS row
FIELDTERMINATOR '\t'
WITH row
SKIP 5
MATCH (dis:HpoDisease)-[rel:HAS_PHENOTYPIC_FEATURE]->(phe:HpoPhenotype)
WHERE phe.id = row[3] AND dis.id = row[0]
FOREACH(_ IN CASE WHEN row[4]  IS NOT NULL THEN [1] ELSE [] END | SET rel.source      = row[4])
FOREACH(_ IN CASE WHEN row[5]  IS NOT NULL THEN [1] ELSE [] END | SET rel.evidence    = row[5])
FOREACH(_ IN CASE WHEN row[6]  IS NOT NULL THEN [1] ELSE [] END | SET rel.onset       = row[6])
FOREACH(_ IN CASE WHEN row[7]  IS NOT NULL THEN [1] ELSE [] END | SET rel.frequency   = row[7])
FOREACH(_ IN CASE WHEN row[8]  IS NOT NULL THEN [1] ELSE [] END | SET rel.sex         = row[8])
FOREACH(_ IN CASE WHEN row[9]  IS NOT NULL THEN [1] ELSE [] END | SET rel.modifier    = row[9])
FOREACH(_ IN CASE WHEN row[10] IS NOT NULL THEN [1] ELSE [] END | SET rel.aspect      = row[10])
FOREACH(_ IN CASE WHEN row[11] IS NOT NULL THEN [1] ELSE [] END | SET rel.biocuration = row[11])

// ④ 사람이 읽을 수 있게 바꾸기 (책 3.23) — 약어를 문장으로, 출처를 링크로
CALL apoc.periodic.iterate(
  "MATCH (dis:HpoDisease)-[rel:HAS_PHENOTYPIC_FEATURE]->(phe:HpoPhenotype) RETURN rel",
  "SET rel.createdBy    = apoc.text.regexGroups(rel.biocuration, 'HPO:(\\w+)\\[')[0][1],
       rel.creationDate = apoc.text.regexGroups(rel.biocuration, '\\[(\\d{4}-\\d{2}-\\d{2})\\]')[0][1],
       rel.aspectName = CASE
         WHEN rel.aspect = 'P' THEN 'Phenotypic abnormality'
         WHEN rel.aspect = 'I' THEN 'Inheritance' END,
       rel.evidenceName = CASE
         WHEN rel.evidence = 'IEA' THEN 'Inferred from electronic annotation'
         WHEN rel.evidence = 'PCS' THEN 'Published clinical study'
         WHEN rel.evidence = 'TAS' THEN 'Traceable author statement' END,
       rel.url = CASE
         WHEN rel.source STARTS WITH 'PMID:' THEN
           'https://pubmed.ncbi.nlm.nih.gov/' + apoc.text.replace(rel.source, '(.*)PMID:', '')
         WHEN rel.source STARTS WITH 'OMIM:' THEN
           'https://omim.org/entry/' + apoc.text.replace(rel.source, '(.*)OMIM:', '') END",
  {batchSize: 1000})

// ⑤ 안 쓰는 것 치우기 (책 3.24)
CALL apoc.periodic.iterate(
  "MATCH (n:Resource) RETURN id(n) AS id",
  "MATCH (n) WHERE id(n) = id
     AND NOT 'HpoPhenotype' IN labels(n)
     AND NOT 'HpoDisease'   IN labels(n)
   DETACH DELETE n",
  {batchSize: 10000})
YIELD batches, total RETURN batches, total

하지만 이 구현에는 중요한 보존성 경계가 있다. 관계를 MERGE (dis)-[:HAS_PHENOTYPIC_FEATURE]->(phe)처럼 질병–표현형 쌍만으로 합치면, 같은 쌍에 서로 다른 출처·작성일의 주석이 여러 건 있어도 하나의 관계가 된다. 이후 모든 일치 관계에 속성을 설정하면 마지막 처리 행의 값이 앞선 근거를 덮을 수 있다. 장의 개념 목표인 “주석별 provenance”를 구현하려면 주석 ID를 별도 노드로 승격하거나, 관계의 고유 키를 모델에 포함하고 행 수 보존 테스트를 두어야 한다.

교재 Listing 3.19–3.24와 저장소 import_hpo.py 감사를 바탕으로 재구성. 같은 질병–표현형 쌍의 주석이 여러 건이면 관계 식별자 없이 MERGE한 한 관계에 마지막 값이 덮일 수 있다는 구현 위험은 발표자의 코드 감사 결과다.

3.3 책의 결과와 현재 실행 결과는 분리한다

교재 결과는 Neo4j 5.20.0, APOC 5.20.0, Neosemantics 5.20.0과 2025년 2월 HPO를 기준으로 한다. 저장소의 학습 노트북은 2026-06-23 HPOA 메타데이터를 확인했으며, “latest” URL을 쓰면 데이터가 계속 바뀐다. 따라서 노드·관계 수와 상위 질병 목록이 책과 다른 것은 곧바로 오류가 아니라 데이터 드리프트일 수 있다. 재현하려면 온톨로지·주석의 릴리스 URL과 체크섬을 함께 고정해야 한다.

또한 교재 Listing 3.18의 중간 상태 질의는 최종 정제 후 실행하면 실패한다. 이는 동일 코드가 어떤 시점에 실행됐는지가 결과의 일부라는 뜻이다. 실습 저장소의 파일 번호는 최종 교재보다 +3 오프셋이 있고, 일부 업스트림 파일은 중복 또는 0바이트라 study.toml의 [mapping.listings.ch03]가 정본이다.

3.4 직접 돌려 보면 숫자가 이만큼 달라진다

이 회차의 학습 노트북 src/ch03/03_chapter_guide.ipynb는 책의 리스팅을 실제 Neo4j에 처음부터 끝까지 실행한 기록이다. 앞 절의 “드리프트가 있을 수 있다”는 말을 추상으로 두지 않고, 실측치를 책 값과 나란히 두면 무엇이 얼마나 움직이는지 눈으로 보인다.

소요 시간도 실습 준비에 직결된다. 대부분의 단계는 1초 안팎이고 온톨로지 적재(3.16)가 9.5초, 질병 노드·관계 생성(3.19·3.20)이 각 3초 남짓이다. 그런데 관계에 속성을 붙이는 3.22 한 단계만 약 8분(496초) 걸린다. 28만 5천 개 관계에 FOREACH 여덟 개를 배치 처리 없이 돌리기 때문이다. 전체를 처음부터 다시 만들면 9분 남짓 걸리므로, 시연 중에 이 셀을 실행하면 안 된다.

4. 그래프는 표현형 조합을 후보 경로로 바꾼다

4.1 직접 연결은 답보다 검토 경로를 준다

첫 질의는 OMIM:222100 제1형 당뇨병 노드에 직접 연결된 표현형을 가져온다. 질문은 “이 질병의 증상은 무엇인가”다.

// 책 3.25 — 한 질병에서 뻗어 나가는 모든 표현형
MATCH path=(dis:HpoDisease)-[:HAS_PHENOTYPIC_FEATURE]->(phe:HpoPhenotype)
WHERE dis.id = "OMIM:222100"
RETURN path

노트북 재실행 결과 OMIM:222100에는 표현형 8개가 달려 있다 — Autoimmunity, Decreased circulating 1,5 anhydroglucitol concentration, Diabetes mellitus, Hyperglycemia, Ketoacidosis, Polydipsia, Polyphagia, Polyuria. 다음(그림 6)에서 중심 노드를 둘러싼 별 모양이 이것이다.

이어 임상의가 환자에게서 성장 지연(HP:0001510), 큰 무릎(HP:0030866), 감각신경성 청각 장애(HP:0000407), 소양증(HP:0000989)을 추가로 관찰했다고 가정한다. 위 목록에 없는 증상들이다. 이제 질문이 뒤집힌다 — “이 질병의 증상은?”이 아니라 “이 증상 조합을 가진 질병은?”이다. 그래프에서는 화살표를 반대로 따라가기만 하면 되는 같은 질의다. 두 번째 질의는 다섯 표현형과 연결된 질병을 모으고, 겹치는 특징 수를 내림차순으로 정렬한다.

// 책 3.26 — 증상 조합에서 질병 후보로
MATCH (phe:HpoPhenotype)
WHERE phe.label IN [
  "Growth delay", "Large knee",
  "Sensorineural hearing impairment", "Pruritus",
  "Type I diabetes mellitus"
]
WITH phe
MATCH path=(dis:HpoDisease)-[:HAS_PHENOTYPIC_FEATURE]->(phe)
UNWIND dis AS nodes
RETURN dis.id AS disease_id,
       dis.label AS disease_name,
       collect(phe.label) AS features,
       count(nodes) AS num_of_features
ORDER BY num_of_features DESC, disease_name
LIMIT 5

교재의 2025년 2월 스냅샷에서는 다섯 특징을 모두 공유하는 Odontochondrodysplasia 2 with hearing loss and diabetes(OMIM:619269)가 첫 후보로 나타난다. 그다음 후보는 세 개 또는 두 개의 특징을 공유한다. 그래프의 가치는 질병 이름만 반환하는 데 있지 않다. 어떤 표현형 경로가 점수를 만들었는지, 각 관계에 어떤 출처·증거·빈도가 있는지 다시 열어볼 수 있다.

교재 §3.4, Listing 3.25–3.26과 표 3.2를 경로와 겹침 수 중심으로 재구성. 선은 후보 랭킹에서 공유 주석의 존재만 나타내며 관계 방향은 그림 2의 질병→표현형을 따른다. 질병명과 수치는 HPO 2025-02 교재 스냅샷이다. 표기 주의 — 교재와 현재 HPOA 데이터는 모두 Ondontochondrodysplasia로 적혀 있고, 이 리포트 본문은 OMIM:619269의 정식 표기 Odontochondrodysplasia를 쓴다. 노트북을 직접 돌리면 데이터 원문 표기가 그대로 출력된다.

4.2 같은 질의를 지금 돌리면 2위 이하가 바뀐다

§3.4의 노트북으로 똑같은 책 3.26 질의를 2026-06-23 HPOA에서 다시 돌린 결과다. 결론(1위)은 그대로지만 그 아래는 상당히 달라졌다.

세 가지를 읽어야 한다. 첫째, 진단 결론은 견고하다 — 다섯 특징을 모두 공유하는 1위는 16개월이 지나도 그대로다. 둘째, 3개 공유 후보가 두 건 새로 생겼다. 교재에서는 3개 공유가 1건뿐이라 2위가 도드라져 보였지만, 지금은 3개 공유가 3건이라 “2위와 3위의 격차”라는 인상 자체가 사라진다. 셋째, 3-methylglutaconic aciduria VIII의 OMIM 번호가 614700에서 617248로 바뀌었다 — 질병 식별자조차 고정된 상수가 아니다.

이것이 §3.3이 말한 드리프트의 실물이다. 슬라이드에 표 8만 띄우고 “이 목록이 나옵니다”라고 말하면, 청중이 노트북을 돌렸을 때 다른 화면을 보고 코드가 틀렸다고 생각하게 된다. 결과를 보여줄 때는 반드시 어느 릴리스에서 나온 값인지 함께 적어야 한다.

5. 계층은 저장되지 않은 포함 관계를 질의한다

5.1 직접 사실과 암시적 포함을 분리한다

“내분비계 이상(Abnormality of the endocrine system, HP:0000818)과 관련된 질병은?”이라는 질문을 생각해 보자. 어떤 질병은 이 상위 범주에 직접 주석되어 있지만, 더 많은 질병은 갑상선 생리 이상(HP:0002926), 갑상선기능저하증(HP:0000821), 갑상선종(HP:0000853)처럼 검증된 하위 표현형에 연결되어 있다. 직접 관계만 조회하면 후자를 놓친다.

교재는 먼저 자식에서 부모로 향하는 [:SUBCLASSOF*1..3] 경로를 역방향으로 탐색해 상위 범주 아래의 하위 표현형을 찾고, 이어 n10s.inference.nodesInCategory로 이 계층을 따라 질병을 포함한다. 반환된 질병–표현형 주석은 원래 그래프에 명시적으로 존재하지만, 상위 범주와 질병의 포함 관계는 계층 규칙에서 도출된다. 교재 표 3.3은 재현성을 위해 5개 질병 화이트리스트로 제한한 부분집합이고, 저장소 Listing 3.31은 화이트리스트 대신 SKIP 100 LIMIT 5를 사용하므로 표시 결과가 같지 않다.

// 책 3.27 — 계층을 손으로 훑는다
MATCH (p:HpoPhenotype)<-[:SUBCLASSOF*1..3]-(n:HpoPhenotype)
WHERE p.id = "HP:0000818"
RETURN p, n

// 책 3.28 — 같은 일을 Neosemantics 프로시저에 맡기고, 그 결과로 질병까지 끌어온다
MATCH (cat:HpoPhenotype {label: "Abnormality of the endocrine system"})
CALL n10s.inference.nodesInCategory(cat, {
    inCatRel: "HAS_PHENOTYPIC_FEATURE",   // 질병을 표현형에 잇는 관계
    subCatRel: "SUBCLASSOF"})             // 하위 개념을 잇는 관계
YIELD node AS dis
MATCH (dis)-[:HAS_PHENOTYPIC_FEATURE]->(phe:HpoPhenotype)
RETURN dis.label AS disease, collect(DISTINCT phe.label) AS features
ORDER BY size(features) ASC, disease

교재 §3.5, Listing 3.27–3.28과 표 3.3의 의미를 직접 사실과 암시적 포함으로 구분해 재구성. 화살표는 HPO 저장 방향과 같은 하위→상위 SUBCLASSOF이며, 세 예시는 HPO Ontology Service 2026-06-23 기준 HP:0000818의 2–3단계 하위임을 확인했다. 추론은 새 임상 사실을 만들지 않고 기존 주석의 질의 범위를 넓힌다.

5.2 더 넓은 결과가 더 정확한 결과는 아니다

계층 추론은 검색 누락을 줄이지만 품질을 자동 보장하지 않는다. 1..3 깊이는 구현자가 정한 범위이고, 더 깊은 하위 개념을 놓칠 수 있다. 반대로 범위를 무제한으로 넓히면 너무 일반적인 상위 개념을 통해 관련성이 약한 후보가 늘 수 있다. 또한 HPO와 주석은 불완전하게 갱신되므로 “연결 없음”을 “관련 없음”으로 해석해서는 안 된다.

노트북이 이 두 문장을 숫자로 확인했다. HP:0000818의 하위 표현형은 깊이 1\~3으로 세면 256개, 깊이 제한을 풀면 474개다. 즉 책 3.27의 *1..3은 실제 계층의 절반가량만 본다. 무엇을 놓치는지도 구체적이다. 책 표 3.3에 나오는 Transient neonatal diabetes mellitus는 HP:0000818에서 4단계 아래라 *1..3으로는 잡히지 않는다. 3.28이 프로시저를 쓰는 이유가 바로 이것이다.

따라서 결과에는 직접 연결인지 계층으로 포함됐는지, 어떤 SUBCLASSOF 경로를 따라왔는지, 어느 HPO 릴리스를 썼는지를 함께 표시해야 한다. 임상의가 추론 경로를 검토할 수 없다면 추론의 설명 가능성은 저장소 내부에만 머문다.

6. 신뢰도는 가장 짧은 미검증 구간에서 무너진다

6.1 네 게이트가 후보 결과의 감사 경로를 만든다

첫째, 원천 게이트에서 릴리스·컬럼·식별자·체크섬을 고정한다. 둘째, 의미 게이트에서 질병과 표현형 역할, HPO ID, 동의어와 계층 방향을 표본 감사한다. 셋째, 적재 게이트에서 원천 행 수가 노드·관계·주석으로 어떻게 변했는지, 중복과 결측이 어떻게 처리됐는지 비교한다. 넷째, 사용 게이트에서 대표 질의를 재현하고 직접·추론 결과와 임상 판단의 경계를 확인한다.

교재의 데이터 품질 강조와 Chapter 3 구현 감사를 운영 통제 관점으로 재구성. 게이트 통과는 의료적 타당성의 자동 증명이 아니라 임상의가 검토할 후보와 근거를 만들었다는 뜻이다.

6.2 근거 화면은 이미 만들 수 있다

지금까지 “임상의가 근거를 열어볼 수 있어야 한다”를 반복했다. 그것이 실제로 어떤 모습인지 보여주는 것이 교재 §3.4의 연습문제다 — “Listing 3.26의 질의를 확장해 evidence_name, evidence_description, source, url을 포함한 관계 속성까지 조회하라.” 노트북이 이 문제를 풀어 두었다.

// 책 3.26 + 관계 속성 — 후보와 '왜 그렇게 판단했는지'를 함께 반환한다
MATCH (phe:HpoPhenotype) WHERE phe.label IN $features
MATCH (dis:HpoDisease)-[rel:HAS_PHENOTYPIC_FEATURE]->(phe)
WITH dis, count(DISTINCT phe) AS matched,
     collect({feature: phe.label, evidence: rel.evidenceName,
              description: rel.evidenceDescription, source: rel.source,
              url: rel.url, curator: rel.createdBy, date: rel.creationDate}) AS grounds
RETURN dis.id AS disease_id, dis.label AS disease, matched, grounds
ORDER BY matched DESC, disease

달라진 것은 한 군데뿐이다. 관계에 rel이라는 이름을 붙이고, rel.source·rel.url·rel.createdBy를 함께 담았다. 실행 결과는 이렇게 나온다.

OMIM:619269  Ondontochondrodysplasia 2 with hearing loss and diabetes — 특징 5개 일치
  · Pruritus
      증거   : Published clinical study
      출처   : PMID:32101163  ->  https://pubmed.ncbi.nlm.nih.gov/32101163
      큐레이션: probinson (2021-06-20)
  · Growth delay                     (이하 3건 동일 근거)
      ...

OMIM:618500  Holoprosencephaly 12 with or without pancreatic agenesis — 특징 3개 일치
  · Growth delay
      증거   : Published clinical study
      출처   : PMID:31006513  ->  https://pubmed.ncbi.nlm.nih.gov/31006513
      큐레이션: probinson (2023-03-16)
  · Sensorineural hearing impairment
      증거   : Inferred from electronic annotation
      출처   : OMIM:618500   ->  https://omim.org/entry/618500
      큐레이션: skoehler (2019-09-07)

여기서 두 후보의 성격이 갈린다. 1위 후보는 다섯 특징이 전부 같은 논문 하나(PMID:32101163)에서 왔다. 즉 이 증후군을 기술한 단일 임상 연구가 근거다. 2위 후보는 근거가 섞여 있다 — 하나는 Published clinical study(PMID:31006513 — 사람이 논문을 읽고 기록), 둘은 Inferred from electronic annotation(OMIM:618500 텍스트를 기계가 파싱). 같은 “3개 일치”라도 근거의 무게가 다르다.

겹침 수만 보면 이 차이가 보이지 않는다. §4.2의 “단순 겹침 수는 증거 질을 가중하지 않는다”는 경고가 추상이 아닌 이유가 이것이고, §2.2에서 LPG를 고른 결정이 최종적으로 값을 치르는 지점이기도 하다. RDF였다면 이 화면을 만들기 위해 n항 관계·명명 그래프·RDF-star 중 하나로 우회해야 했다.

6.3 이 장은 임상 의사결정 지원의 개념 증명이다

교재 사례는 HPO 데이터 위에서 질의와 추론이 어떻게 작동하는지 보여주는 교육용 예시다. 환자 EHR의 실제 수집·동의·권한·비식별화, 부정 표현형, 발현 시점, 환자군별 빈도, 임상 검증, 규제와 책임 배분은 다루지 않는다. 따라서 결과를 “진단”이라고 표현하기보다 검토 가능한 후보 생성으로 제한해야 한다.

7. 온톨로지·LPG·추론은 질문에 필요한 만큼만 쓴다

7.1 기술 이름이 아니라 지식 질문으로 선택한다

7.2 최소 파일럿은 질문–스냅샷–그래프–근거 화면이다

첫 파일럿은 거대한 의료 온톨로지 플랫폼이 아니다. 대표 임상 질문 3개와 기대 경로를 정의하고, 같은 날짜의 hp.owl과 phenotype.hpoa를 고정한다. 필요한 HPO 하위 범위만 적재하고, 주석 다중성을 보존하는 모델을 선택한다. 직접 질의와 계층 추론의 결과를 분리해 표시하고, 원 출처와 경로를 한 번에 열 수 있는 검토 화면을 만든다.

중단 기준도 함께 둔다. 표준 ID 매핑 오류가 허용 범위를 넘거나, 주석 건수 보존이 설명되지 않거나, 추론 후보가 임상의 검토 시간을 줄이지 못하거나, 릴리스 갱신 때 회귀 결과를 설명할 수 없다면 범위를 줄이거나 모델을 바꾼다.

7.3 토론 질문