온톨로지 범위·소유·저장·생성
작성: 2026-09-14 · 상태: 확정(2026-09-14) — PLATFORM_VISION.md §9-1~4에 대한 결정. 결정 기록은 DECISION_LOG.md(2026-09-14 "온톨로지 범위·소유·저장·생성 확정")에 있다. 개정: 2026-10-16 — 소유 이관 확정: 원장·승인 표면 = OntologyService(별도 플랫폼 서비스), 콘솔 = 포털 등록·레일 하단 런처. 기록 DECISION_LOG.md(2026-10-16 "온톨로지 소유 이관"), 이관 절차·검증·롤백은 PortalConsole docs/ontology-ownership-move-plan.md(P0~P5). 관련 문서: PLATFORM_VISION.md(§6 데이터·온톨로지 · §9 미해결) · AI_FEATURE_REGISTRY.md(기능·능력) · MODEL_GATEWAY_SCOPE.md(모델 연결) · SERVICE_BOUNDARIES.md(온톨로지 행) · DECISION_LOG.md(결정 이력)
1. 왜 지금 정하는가
가치 사슬의 병목이 지식 단계다. 데이터(포털 DB·FileStore·문서)와 의미(AI) 사이에 의미망이 없으면 AI는 매 질문마다 문맥을 처음부터 다시 읽는다. 어휘와 관계가 고정되면 같은 질문에 일관된 용어·관계로 답하고, 문서·포털 사이 비교가 가능해진다.
이미 갖춰진 것:
| 자산 | 내용 | 상태 |
|---|---|---|
| 씨앗 | glossary(PortalConsole 번역 용어) — 개념·동의어·번역의 최소 형태 | 운영 중 |
| 코퍼스 | 문서 라이브러리(플랫폼 문서 HTML/PDF) · FileStore(가이드·SOP 원본) | 운영 중 |
| 소비자 | RagService·ExploreGateway(색인·검색) · 각 포털 업무 기능 | 일부 운영 |
| 연결 | ModelGateway(완성·임베딩, x-purpose 귀속) | 운영 중 |
즉 정의할 대상(개념·관계)과 검증할 코퍼스가 이미 있고, 정의만 없어서 AI가 매번 임시로 의미를 만드는 상태다.
1-1. 데이터 공급원 (확정)
| # | 공급원 | 성격 | 온톨로지에서의 역할 |
|---|---|---|---|
| 1 | ProcessCenter 업무프로세스 정의 | 정형(프로세스·게시본·노드) | 관계의 앵커 — 유형은 사전에 정의, 개별 정의는 참조 노드 |
| 2 | GuideCenter 사내정책문서 | 비정형(자연어 업무 규칙) | 개념·관계·용어 추출 코퍼스 |
| 3 | 사내 비정형 문서 | 비정형 | 개념·관계·용어 추출 코퍼스 |
유입 경로(확정): 정책·비정형 문서의 정본은 FileStore(원본 보관·스캔·색인 발행)이고, 추출·검색은 FileStore가 발행한 색인을 단일 입력으로 받는다. Document Library는 "플랫폼 생성 문서" 전용을 유지(역할 확장 없음)하고, 플랫폼 문서는 보조 코퍼스로 같은 색인에 얹는다.
| 데이터 | 정본(보관) | 표면 |
|---|---|---|
| 프로세스 정의 | ProcessCenter | ProcessCenter |
| 정책문서·사내 비정형 문서 | FileStore | FileStore · 각 포털 |
| 플랫폼 문서(설계·결정·규격·보고서) | Document Library(R2 platform-docs/, 미구성 시 로컬) | PortalConsole 문서 라이브러리 |
개별 업무의 산출물(특정 결재 건·실행 결과 보고서·회의록 등 인스턴스)은 이번 범위 밖이다. 각 포털의 업무 데이터이므로 플랫폼이 복제·소유하지 않으며, 수용 여부는 다음 단계에서 결정한다(수용하더라도 복제가 아니라 참조·색인 형태).
2. 결정 1 — 범위
| 후보 | 내용 | 평가 |
|---|---|---|
| A | 번역 용어만 유지(현행) | 씨앗은 유지되지만 AI가 의미망을 얻지 못한다 ❌ |
| B | 문서·프로세스에 실제 등장하는 개념·관계 | 검증 가능한 범위이고 코퍼스가 이미 있다 ✅ 확정 |
| C | 전사 온톨로지(모든 도메인 선제 정의) | 정의·유지 비용이 크고 근거 없는 추측이 지식으로 굳는다 ❌ |
확정: B(2026-09-14). 첫 범위를 세 축으로 고정한다.
| 축 | 정의 | 예 |
|---|---|---|
| 개념(Concept) | 업무·문서에서 반복 등장하는 명사적 단위 | process.version(게시본) · document.approval(문서 승인) |
| 관계(Relation) | 개념 사이의 방향 있는 연결 | document.version belongsTo process.version · approval requiresRole org.admin |
| 용어(Term) | 개념의 표기·동의어·정의·출처 | "게시본" = version = "게시 버전" · 출처: glossary:123 |
초기 범위 밖(명시): 추론 규칙 엔진 · 시점·버전 그래프(bitemporal) · 다국어 개념 정합 · 자동 반영 · 개별 업무의 산출물(실행 인스턴스·결재 건·생성 보고서 등 — 다음 단계).
2-2. 정형(프로세스 정의) 처리 — 확정: 방식 2
| 방식 | 내용 | 평가 |
|---|---|---|
| 1 | 프로세스 전체를 참조만 (정의도 ProcessCenter 소유) | 어휘가 사전에 없어 문서와 정의를 잇기 어렵다 ⚠️ |
| 2 (확정) | 종류(게시본·노드·승인 등)는 온톨로지 개념으로 정의 + 개별 프로세스 정의는 ProcessCenter 참조 노드 | 어휘 통일과 단일 진실공급원을 함께 얻는다 ✅ |
| 3 | 개별 프로세스까지 온톨로지에 직접 등록 | 같은 프로세스가 두 곳에 생겨 어긋난다(이중 관리) ❌ |
방식 2를 택한 이유: 문서에 "게시본"이라는 단어가 나올 때 뜻이 통일되어야 하고(종류는 사전이 정의), 개별 프로세스 데이터는 ProcessCenter가 단일 진실공급원으로 남아야 하기 때문이다.
2-1. 최소 스키마 (초안)
// (1) 정의된 개념 — 유형·용어. 온톨로지가 정의한다.
{
"conceptId": "process.version",
"label": "게시본",
"aliases": ["버전", "version", "게시 버전"],
"definition": "프로세스의 확정 게시 단위",
"scope": "process-center",
"source": { "kind": "process-type", "ref": "process-center:process_version" },
"status": "approved"
}
// (2) 참조 노드 — 개별 프로세스 정의. 온톨로지가 정의하지 않고 가리키기만 한다(정의는 ProcessCenter 소유).
{
"conceptId": "process-center:process_version:5678",
"source": { "kind": "portal-entity", "ref": { "portalId": "process-center", "entityType": "process_version", "id": "5678" } },
"status": "approved"
}
// (3) 관계 — 양 끝이 정의된 개념이든 참조 노드든 모두 연결할 수 있다.
{
"relationId": "r-0f1c",
"from": "document.version",
"to": "process.version",
"type": "appliesTo",
"evidence": { "kind": "doc", "ref": "platform-docs/ai-feature-registry/v2026-09-14/ai-feature-registry.html" },
"confidence": 0.82,
"status": "proposed"
}status는proposed(추출 제안) →approved(사람 승인) →deprecated로만 간다.- 승인된 항목만 색인·검색·AI 문맥에 쓴다.
evidence가 없는 관계는 승인 대상이 아니다(근거 없는 지식 금지). scope는 소유 포털(플랫폼 공통이면platform).
3. 결정 2 — 소유자
| 후보 | 평가 |
|---|---|
| A | PortalConsole 단독 |
| B | portal-foundation 단독 |
| C | 분할 소유 |
확정: C(2026-09-14).
| 대상 | 소유자 | 근거 |
|---|---|---|
| 표준 스키마·용어팩(개념·관계 정의 배포) | portal-foundation — 초기엔 기존 @hohyun94/portal-ai의 하위 모듈, 커지면 @hohyun94/portal-ontology로 분리 | 2026-08-20 "공통기능은 통합 운영이 아닌 Asset 제공" |
| 운영 표면(용어·개념 조회/등록, 후보 승인, 감사) | OntologyService(2026-10-16 개정) — 舊 PortalConsole 관리자 메뉴 온톨로지 | 2026-09-14 "운영 표면은 콘솔 한 곳" → 2026-10-16 "표면은 지식 서비스 한 곳, 콘솔은 등록·런처" |
| 개념·관계 실데이터 | 각 소유자(포털 DB · FileStore · 문서 라이브러리) | 업무 데이터 소유권 |
| 실행(추출 완성·색인) | ModelGateway(추출) · RagService/ExploreGateway(색인·검색) | 서비스 분리 · 표면 통합 |
플랫폼은 온톨로지를 실행하지 않는다 — 정의·보관·검증 표면만 갖고, 업무 규칙 실행은 각 포털이 한다(비전 §2 경계).
개정 (2026-10-16) — 표면 위치. "운영 표면은 콘솔 한 곳"은 표면을 한 곳에 모은다는 뜻으로 유지하되, 그 한 곳을 콘솔 관리자 메뉴에서
OntologyService(별도 플랫폼 서비스)로 옮겼다. 콘솔은 포털 등록(PLATFORM_SERVICE)·레일 하단 런처와 번역 실행(2026-10-11, 지식 서비스의 승인 용어를 서버 간 호출로 읽음)만 갖는다. 콘솔 DB(glossary확장)에 두기로 한 저장 위치도 지식 서비스 DB로 이동한다(§4 표 참조).
4. 결정 3 — 저장·색인
| 후보 | 평가 |
|---|---|
| A | 중앙 그래프 DB 신설(예: Neo4j) |
| B | 어댑터 수집(각 소유자 원본 유지) + 기존 색인에 태움 |
확정: B(2026-09-14). 저장 위치를 다음처럼 나눈다.
| 데이터 | 저장 | 비고 |
|---|---|---|
| 표준 용어·개념 | OntologyService DB(2026-10-16 개정, 舊 PortalConsole DB) — glossary 테이블을 개념 용어 중심으로 확장 | 이미 있는 스키마를 확장(새 테이블 신설 최소화) |
| 문서·프로세스 개념·관계 | 각 소유자 원본 유지 + 색인 발행은 기존 경로 재사용(FileStore 발행 → RagService/ExploreGateway 색인) | 플랫폼이 업무 데이터를 복제·소유하지 않는다 |
| 승인 이력(감사) | OntologyService 감사 로그(2026-10-16 개정) | actor·근거 문서·시각 · 과거 행 이관 방식은 이관 계획 §11 |
재검토 조건(그때 그래프 DB를 다시 본다): ① 포털 간 다단계 관계 질의가 실제 요구가 될 때 ② 승인된 관계가 수만 건을 넘어 조회 지연이 문제가 될 때.
4-1. glossary 확장 — 개념 용어 중심 (확정)
기존 glossary는 번역 전용(소스 언어 → 대상 언어)이다. 그런데 3 공급원에서 추출되는 것은 번역이 아니라 개념(표기·동의어·정의·소속)이므로, glossary를 개념 용어 중심으로 확장하고 번역은 선택 필드로 내린다.
| 지금 | 확장 후 | |
|---|---|---|
| 정체 | 번역 용어 사전 | 개념 용어 + (선택) 번역 |
| 필드 | sourceLocale · targetLocale · 번역문 | + conceptId · label · aliases · definition · scope · status · evidence · translations[] |
| 유입 | 사람이 수동 등록 | 사람 수동 + 3 공급원 추출(승인 후) |
// 확장 후 예 — 기존 번역 용어는 "개념 + 번역"으로 승격된다
{
"conceptId": "process.version",
"label": "게시본",
"aliases": ["버전", "게시 버전"],
"definition": "프로세스의 확정 게시 단위",
"scope": "process-center",
"status": "approved",
"evidence": { "kind": "doc", "ref": "..." },
"translations": [{ "locale": "en", "text": "published version" }]
}이렇게 해야 "게시본"이라는 용어가 프로세스 정의에서도, 정책문서에서도, 플랫폼 문서에서도 하나의 개념으로 합쳐진다. 새 테이블을 만들지 않고 기존 테이블을 확장한다.
5. 결정 4 — 생성 방식
| 후보 | 평가 |
|---|---|
| A | 수동만(사람이 전부 정의) |
| B | 자동만(추출 즉시 반영) |
| C | 수동 뼈대 + 자동 살(제안 → 승인) |
확정: C(2026-09-14). 절차를 다섯 단계로 고정한다.
- 표준 등록(사람) — 지식 서비스 화면에서 개념·용어를 등록한다(
status: approved, 2026-10-16 개정 — 舊 콘솔). 기존glossary용어를conceptId로 승격하는 것이 첫 작업이다. - 추출(자동) — 문서·업무 데이터에서 개념·관계 후보를 뽑는다. 실행은 ModelGateway 경유(
x-purpose: ontology.extract, 임베딩은rag.embedding)로 하고, 결과는status: proposed로만 저장한다. - 승인(사람) — 지식 서비스 화면에서 후보를 검토해 승인/거부한다(2026-10-16 개정 — 舊 콘솔). 승인 시
evidence(근거 문서 링크)와actor가 감사 로그에 남는다. - 반영 — 승인된 항목만 색인 재발행 대상이 된다.
- 배포 — 용어팩은 버전 단위로 배포한다(포털이 특정 버전을 고정할 수 있게).
금지 항목: 자동 반영 · 승인 없는 색인 반영 · 근거 없는 관계 승인 · 플랫폼이 업무 로직을 실행하는 것.
이 단계에서 늘어나는 AI 기능(레지스트리 등록 대상): ontology.extract(개념·관계 추출), 이후 필요 시 ontology.link(기존 개념 사이 관계 후보 제안). 두 기능 모두 capabilities: ["completion"](+ retrieval)로 등록하고, 추출 결과가 제안일 뿐임을 label에 드러낸다(예: "온톨로지 후보 추출").
5-1. 용어 생애주기 — 하향식 + 상향식 (확정)
하향식(표준): 사람이 등록 → glossary에 approved로 들어간다
상향식(추출): 3 공급원에서 후보를 뽑는다
├ ProcessCenter 정의 → 레이블·유형명(게시본·노드·승인자) 수집
└ 정책·비정형 문서 → 명사구(부서장 승인·보안 등급) 추출
→ proposed → 사람 승인 → approved두 방향이 만나는 곳이 glossary(§4-1)이고, 승인된 것만 색인·검색·AI 문맥에 쓴다.
5-2. 범위 판정 기준 (확정)
자동 추출이 범위를 마음대로 넓히지 못하게, 범위 진입은 사람·표준이 판정하고 자동은 후보만 낸다.
| 구분 | 기준 |
|---|---|
범위 진입(approved) | ① glossary에 등록된 용어 ② 문서의 제목·표제어(heading)로 등장 ③ ProcessCenter 프로세스 정의의 유형 |
후보 생성(proposed) | "N회 이상 등장하는 명사구" — 승인 전에는 범위 밖 |
5-3. 관계 유형 — 고정 7종 (확정)
열린 유형은 지식이 오염되므로 소수 고정 집합으로 시작하고, 필요하면 용어팩 버전으로 확장한다.
| 유형 | 뜻 | 예 |
|---|---|---|
isA | 상위·하위 | 게시본 isA 프로세스 산출물 |
partOf | 구성 | 노드 partOf 게시본 |
belongsTo | 귀속 | 문서 belongsTo 부서 |
appliesTo | 적용 | 정책문서 appliesTo 프로세스 게시본 |
references | 참조 | 비정형문서 references 정책문서 |
requiresRole | 요구 권한 | 승인 requiresRole 부서장 |
precedes | 순서 | 노드1 precedes 노드2 |
6. 반영 체크리스트
문서 반영(완료)
- [x]
PLATFORM_VISION.md§9-1~4 확정 표기 · §8 지식 단계 상태 갱신 · §6-3 생성 절차 연결 - [x]
DECISION_LOG.md에 결정 기록(이유·영향·후속 조치) - [x]
SERVICE_BOUNDARIES.md에 온톨로지 소유 행 추가(표면=콘솔 · 스키마=Asset · 실데이터=각 소유자) → 2026-10-16 개정: 표면 =OntologyService - [x]
AI_FEATURE_REGISTRY.md§4 능력 매트릭스에ontology.extract반영
구현(진행)
- [x] PortalConsole
glossary스키마 확장 — 개념 필드(concept_id·scope·status·aliases·evidence)·번역 선택화·검증 분리 (PortalConsole #24)- 적용: MySQL 은
pnpm db:ensure-ontology-glossary(멱등) 또는pnpm db:push· PostgreSQL 은 마이그레이션0009_ontology_glossary_fields
- 적용: MySQL 은
- [x] PortalConsole 관리자 메뉴 온톨로지 — 개념 목록·상태 필터·등록·승인 흐름 (PortalConsole #25)
- [x] 감사 기록 — 등록·상태 변경을
directory_audit_logs(entity_type=ONTOLOGY)에 남기고 스냅샷은 암호화 (PortalConsole #26) - [x] 관계 축 — 확정 7종 유형·개념/참조 노드 저장·계약(PortalConsole #27) · 데스크 관계 섹션(목록·승인·등록)(PortalConsole #28)
- [x] 용어팩 Asset —
@hohyun94/portal-ai에 개념·관계·용어팩 계약과 승인 필터 (portal-foundation #14) - [x] 용어팩 배포 경로 — 승인된 것만 담는 내보내기(tRPC +
GET /api/directory/v1/ontology/pack) (PortalConsole #29)
소유 이관(2026-10-16 확정)
- [x] 결정 개정(P0) —
DECISION_LOG.md(2026-10-16 "온톨로지 소유 이관") ·SERVICE_BOUNDARIES.md온톨로지 행 교체 · 이 문서 §3·§4·§5·§8 표기 - [ ]
OntologyService신설(P1) — 스키마·마이그레이션·REST/tRPC(동일 경로·동일 응답 스키마)·감사·시드·자체 관리자 인증 - [ ] 데이터 이관(P2) —
directory_glossary_terms·directory_ontology_relations·directory_content_term_links이관 + 팩 지문(translationPackVersion·packVersion) 대조 - [ ] 소비자 3곳 절체(P3) — ProcessCenter·DocumentLibrary·GuideCenter (env
ONTOLOGY_BASE_URL, scope 이름 유지) - [ ] 콘솔 표면 전환(P4) — 온톨로지 탭 제거 → 레일 하단 런처 · 구 경로 폐기(P5)
- [ ] 중복 편집 정리 — ProcessCenter 전문용어사전(
TerminologyManager.tsx)을 읽기 전용 또는 지식 서비스 링크로 - 절차·검증·롤백: PortalConsole
docs/ontology-ownership-move-plan.md(§6 단계표 · §7 절체 매트릭스 · §9 검증 기준 · §10 롤백)
남은 것
- [ ] 승인 이력 조회 화면 — 감사 기록을 지식 서비스 화면에서 시간순으로 보기(2026-10-16 개정 — 舊 온톨로지 데스크)
- [ ] FileStore 색인 발행 경로에 온톨로지 추출 입력 연결(
ontology.extract) — 검색 단계(색인) 선행 — 계약 초안은 §8 - [ ] RagService/ExploreGateway 색인 계약에 개념·관계 발행 경로 추가 — §9-5 경계 확정 선행(
SEARCH_SCOPE.md)
7. 남은 실행 질문 (범위 확정 후)
| # | 질문 | 왜 필요한가 |
|---|---|---|
| 1 | 추출 품질을 어떻게 측정하는가 — 승인율, 거부 사유 태깅? | 품질 기준이 없으면 승인 절차가 형식이 된다 |
| 2 | 승인 화면이 근거 문서 링크를 함께 보여줄 수 있는가 | 근거 없는 승인은 지식이 아니라 추측이다 |
| 3 | 색인 재발행은 승인 즉시인가 배치인가 | 즉시면 지연·비용이, 배치면 신선도가 문제가 된다 |
첫 코퍼스(확정): 3 공급원을 그대로 시작점으로 삼는다 — ProcessCenter 프로세스 정의(관계의 앵커) + GuideCenter 사내정책문서 + 사내 비정형 문서. 정책·비정형 문서는 FileStore 색인을 경유하고, 플랫폼 문서(문서 라이브러리)는 보조 코퍼스로 같은 색인에 얹는다.
8. 추출·색인 연결 계약 (초안)
ontology.extract 가 어디서 무엇을 받아 무엇을 내는지 — 검색 경계 확정(SEARCH_SCOPE.md)에 맞춘 초안이다.
| 단계 | 내용 |
|---|---|
| 입력 | ① 색인된 문서 청크(RagService 색인 — 파일 경로 기반 배치가 원본을 읽는다) ② 승인된 표준 용어·개념(온톨로지, 범위 진입 판정의 기준) ③ ProcessCenter 프로세스 정의의 유형·식별자(관계 앵커) |
| 실행 | ModelGateway 경유(x-purpose: ontology.extract, 임베딩은 rag.embedding) — 게이트웨이가 모델·키·쿼터·감사를 담당하고 추출기는 purpose만 안다 |
| 출력 | 개념·관계 후보(status: proposed) — 근거(evidence: {kind, ref})와 신뢰도(0~1)를 함께 낸다. 승인 전에는 색인·검색에 쓰지 않는다 |
| 승인 | 지식 서비스 화면에서 검토 → 승인·폐기(2026-10-16 개정 — 舊 콘솔 온톨로지 데스크). 승인·폐기는 감사 기록에 남는다(구현 완료) |
| 반영 | 승인된 개념·관계만 용어팩(GET /api/directory/v1/ontology/pack)과 색인 문맥에 들어간다 |
남은 결정 2개
| # | 항목 | 쟁점 |
|---|---|---|
| 1 | 공유 스토리지 경로 규약 | FileStore 원본 위치를 RagService 색인 입력(파일 경로)과 어떻게 맞출지 — 같은 볼륨 마운트 · 오브젝트 스토리지에서 내려받기(색인 전 임시 경로) · FileStore 가 발행 시 경로 목록을 넘기기 |
| 2 | 재발행 시점 | 승인 즉시(신선·비용 큼) vs 배치(저렴·지연) — §7 의 질문과 같은 문제 |
하지 않는 것: 자동 반영(승인 없이 색인 반영) · 근거 없는 후보 승인 · 플랫폼이 업무 규칙을 실행하는 것.