온톨로지·용어사전 소유 이관 계획 (PortalConsole → 별도 플랫폼 서비스)

작성: 2026-10-16 · 상태: 확정(2026-10-16) — §5 문안을 UiPlatform docs/DECISION_LOG.md(2026-10-16 "온톨로지 소유 이관")·docs/SERVICE_BOUNDARIES.md·docs/ONTOLOGY_SCOPE.md 에 반영했다(P0 완료). 실행 단계는 §6 P1~P5. 문서 위치: 이 계획은 구현 저장소(PortalConsole) 에 둔다 — 개정 대상(결정·경계 문서)은 UiPlatform 에 있으므로 개정 기록은 그쪽에 있다(P0 반영 완료). 관련 문서: UiPlatform docs/ONTOLOGY_SCOPE.md(2026-09-14 확정 · 2026-10-16 개정) · UiPlatform docs/SERVICE_BOUNDARIES.md(온톨로지 행) · UiPlatform docs/DECISION_LOG.md(2026-09-13 명칭 · 2026-09-14 온톨로지 · 2026-09-15 저장 라우팅 · 2026-10-11 용어집 중앙화 · 2026-10-16 소유 이관) · 이 저장소 docs/central-directory-integration.md

1. 결정할 것

온톨로지·용어사전의 원장(표 3개 · 감사 · 팩 발행 · REST/tRPC)을 새 플랫폼 서비스로 옮기고, PortalConsole 은 포털 등록 + 레일 하단 런처만 남긴다.

지금은 UiPlatform docs/ONTOLOGY_SCOPE.md(2026-09-14)가 표면 = PortalConsole 로 확정돼 있고 docs/SERVICE_BOUNDARIES.md 의 온톨로지 행도 같다. 따라서 이 계획의 첫 단계는 구현이 아니라 결정 개정이다.

2. 왜 바꾸는가

근거	내용
지식은 플랫폼 자산	소비자 3곳(ProcessCenter · DocumentLibrary · GuideCenter)이 이미 용어·연결을 동기화한다. 추출(ontology.extract)·색인 재발행·품질지표는 관리자 메뉴가 아니라 지식 제품의 로드맵이다(ONTOLOGY_SCOPE.md §7·§8)
표면 중복	용어사전이 콘솔 온톨로지 데스크와 ProcessCenter 전문용어사전 두 곳에서 편집된다(둘 다 같은 원장 호출 — terminologyService.ts → directorySyncService.createCentralGlossaryTerm). 소유를 옮기면 표면을 하나로 정리할 수 있다
콘솔 성격 보존	콘솔은 사용자·조직·포털 접근정책·등록의 제어평면이다. 지식 그래프 편집이 커지면 콘솔이 지식 제품이 된다

이미 확정된 원칙과의 관계: 2026-09-15 결정의 "서비스 분리 · 표면 통합" 중 표면을 콘솔에 두는 부분만 개정한다. 서비스 분리(소유) 원칙은 그대로 유지·강화된다.

3. 이관 대상 실측 (PortalConsole)

자산	현재	이관 후
화면	client/src/components/OntologyDesk.tsx 545줄(개념·용어·관계·팩 한 화면)	새 서비스 화면(콘솔 탭 제거, 런처만)
원장 표	directory_glossary_terms(concept_id·scope·status·aliases·evidence·category·priority·is_active + 인덱스 4) · directory_ontology_relations(from_node_id·to_node_id·relation_type·evidence·confidence + 인덱스 4) · directory_content_term_links(content_key=portalId:entityType:entityId·term_id·surfaces·detected_by·occurrences·deleted_at tombstone + 인덱스 4)	새 서비스 DB(스키마·인덱스·tombstone 의미 동일)
서버	glossary.ts 490 · contentTermLinks.ts 340 · ontologyRelations.ts 179 · ontologyPack.ts 93 · glossaryPack.ts 101 → 새 서비스로 이동. translationService.ts 92 는 이관하지 않는다 — 번역 실행(프롬프트·POST /api/directory/v1/translation, scope translation:invoke)은 콘솔 소유다(2026-10-11). 콘솔은 지식 서비스의 승인 용어를 서버 간 호출로 읽는 소비자가 된다(표기·정의 복제 금지)
노출 API	REST GET /api/directory/v1/ontology/pack · GET /glossary/matching-terms · POST /glossary/term-proposals · GET/POST/DELETE /content-term-links (scope glossary:read · glossary:write) + tRPC glossaryTerms · createGlossaryTerm · updateGlossaryTerm · ontologyRelations · ontologyPack · contentTermLinks	새 서비스가 같은 경로·같은 스키마로 제공(소비자 무수정 목표)
감사	directory_audit_logs — entity_type ONTOLOGY, action CREATE_ONTOLOGY_TERM · SET_ONTOLOGY_TERM_STATUS, 스냅샷 암호화(auditEncryption)	새 서비스 감사(과거 행 이관 여부는 §11)
마이그레이션	MySQL 0030_directory_glossary_terms · 0035_directory_glossary_metadata · 0040_content_term_links · 0045_directory_glossary_category / PG 0003 · 0009_ontology_glossary_fields · 0010_ontology_relations · 0013_content_term_links · 0018	새 서비스 마이그레이션으로 재작성
시드	docs/glossary-seed-terms.json + scripts/seed-glossary-terms.mjs	새 서비스 시드
계약	@hohyun94/portal-ai 용어팩과 모양 일치 관례(콘솔이 패키지를 import 하지 않는다)	계약 골든 테스트를 새 서비스로 옮겨 비교 유지
등록	portal_configurations(ui-center · file-store 선례) + server/applicationType.ts	새 서비스를 PLATFORM_SERVICE 로 등록(접속권한 매트릭스 제외 규칙 그대로)

4. 새 서비스 경계 (확정)

• 이름: OntologyService (2026-10-16 확정). 2026-09-13 명칭 규칙상 플랫폼 서비스는 기능 접미사이고 …Center 는 소비 포털이다.
• 배포 주소: ontology.rlab.monster (Coolify 앱 — 가족 도메인 관례: process·directory·ui-center·documents.rlab.monster).
• 저장소: ~/projects/OntologyService (로컬 main — 2026-10-16 P1a 초기 커밋).
• 소유: 개념·용어·관계·연결 원장, 감사, 팩 발행, REST/tRPC, 자체 DB, 자체 관리자 인증.
• 비소유: 개별 프로세스 정의(ProcessCenter) · 문서 본문(FileStore·DocumentLibrary·GuideCenter) · 모델 호출·색인 실행(ModelGateway·RagService/ExploreGateway) · 번역 실행(콘솔 소유, 2026-10-11).
• 콘솔 잔여: 포털 등록·접근정책·레일 하단 런처, 중앙 번역 서비스(지식 서비스의 승인 용어를 읽어 번역 팩 구성), AI 기능 레지스트리의 표시·정책 프록시(실행은 각 서비스).

5. 결정 개정 문안 (P0 반영 완료 — UiPlatform 커밋 참조)

아래는 반영된 문안이다. 실제 문안은 UiPlatform docs/DECISION_LOG.md(2026-10-16 두 항목) · docs/SERVICE_BOUNDARIES.md(온톨로지 행·저장 라우팅 개정) · docs/ONTOLOGY_SCOPE.md(헤더 개정·§3·§4·§5·§6·§8)에 들어갔다. 유일한 변경: 번역 실행(translationService.ts)은 이관 대상에서 제외(2026-10-11 결정 유지) — 콘솔이 지식 서비스의 승인 용어를 서버 간 호출로 읽는다.

5-1. UiPlatform docs/DECISION_LOG.md 새 항목

## 2026-1x-xx · 온톨로지 소유 이관 — 원장은 OntologyService, 콘솔은 등록·런처

결정: 온톨로지·용어사전의 표·감사·팩 발행·REST 원장을 새 플랫폼 서비스로 이관한다. PortalConsole 은 포털 등록과 레일 하단 런처만 남긴다. 경로·응답 스키마·scope 이름은 유지해 소비자 3곳이 주소만 바꾼다.

이유: 소비자 3곳(ProcessCenter·DocumentLibrary·GuideCenter)·추출·색인 로드맵은 콘솔 관리자 메뉴와 수명주기가 다르고, 용어사전 편집 표면이 콘솔과 ProcessCenter 두 곳으로 갈려 있다. 2026-09-15 결정의 "서비스 분리 · 표면 통합" 중 표면 위치만 개정한다.

영향: ONTOLOGY_SCOPE.md §3·§6 개정 · SERVICE_BOUNDARIES.md 온톨로지 행 교체 · 콘솔 온톨로지 탭 제거 + 런처 · 소비자 env ONTOLOGY_BASE_URL 신설.

후속 조치: 데이터 이관 검증 리포트 · 소비자 3곳 절체 · 구 경로 폐기 · 편집 표면 단일화(ProcessCenter 전문용어사전 정리).

5-2. UiPlatform docs/SERVICE_BOUNDARIES.md 온톨로지 행 교체 문안

| **온톨로지**(개념·관계·용어 = 플랫폼 지식망) | 스키마·용어팩 = portal-foundation Asset · 원장·조회·등록·승인 표면 = **OntologyService**(2026-1x-xx) · 실데이터 = 각 소유자(ProcessCenter 프로세스 정의 · FileStore 문서) · 추출·색인 = ModelGateway · RagService/ExploreGateway · 등록·런처 = PortalConsole |

5-3. UiPlatform docs/ONTOLOGY_SCOPE.md §6 체크리스트 갱신 — "표면 = 콘솔" 문구를 "표면 = 새 서비스, 콘솔 = 등록·런처" 로 바꾸고, 구현 항목의 주체를 새 서비스로 옮긴다. 과거 이력(PortalConsole #24~#29)은 기록으로 그대로 둔다.

6. 이관 단계

단계	산출물	게이트	롤백
P0 결정 개정	§5 문안 커밋(UiPlatform) + 기준값 수집(표별 행 수 · updated_at 최대 · 팩 지문 baseline)	문서 게시 CI	커밋 되돌리기(코드 무변경)
P1 새 서비스 부트스트랩	P1a ✅ 저장소 ~/projects/OntologyService — 스키마(4표)·마이그레이션(MySQL/PG)·원장 코드 이식·감사 암호화 이식 · P1b ✅ 소비자 REST 13라우트(콘솔과 동일 경로·scope·응답 스키마) + 포털 키 인증 · 관리자 REST 13경로(용어·후보·관계·팩 내보내기·승인 이력·연결) + x-directory-admin-key 인증 · 게이트 check 0 · test 66 · build 0 · 키 저장소(ontology_api_keys — 발급·회전·중지) · 용어 시드 · 관리자 화면(portal-foundation PortalAdminShell — 용어사전·승인 대기·관계·팩·이력·키) · P1 완료(관리자 계정·세션 포함)	새 서비스 check·test·build	서비스 미오픈(콘솔 현행 유지)
P2 데이터 이관	일회 복사 + 행 수·팩 지문·승인 필터 결과 대조 리포트	대조 불일치 0	콘솔 원장 그대로(쓰기 차단 없음)
P3 소비자 3곳 절체	ONTOLOGY_BASE_URL 신설(미설정 시 DIRECTORY_BASE_URL 폴백) · scope 이름 유지 · 각 repo 테스트	각 repo 로컬 게이트 + 실연결 1회	env 한 줄로 원복
P4 콘솔 표면 제거	온톨로지 탭 삭제 → 레일 하단 런처(FileStore 패턴) · 구 tRPC/REST 폐기 예고 1릴리스	콘솔 check·test·build	탭 복구(런처 유지)
P5 구 경로 폐기	콘솔 REST/tRPC 제거 · 문서 확정(INTEGRATION_STATUS.md · PortalConsole central-directory-integration.md)	전체 게이트	구 경로는 P4까지 유지

순서 원칙: 데이터 이관(P2)과 소비자 절체(P3) 사이에 쓰기 동결 창을 두지 않는다 — 콘솔이 계속 쓰기를 받는 동안 복사하고, 절체 직전에 한 번 더 증분 복사한다(마지막 커서 = updated_at 최대값).

7. 소비자 절체 매트릭스

repo	옮기는 파일	env	scope	검증
ProcessCenter	server/termLinkSync.ts · directorySyncService.ts · repositories/directoryGlossaryRepository.ts · services/terminologyService.ts · client/src/components/TerminologyManager.tsx(편집 표면 정리 대상)	DIRECTORY_BASE_URL + 포털 키(PORTAL_CONSOLE_* 호환 유지)	glossary:read · glossary:write	termLinkSync.test.ts · terminologyRouter.test.ts
DocumentLibrary	server/termLinkSync.ts · termLinkDirectory.ts · contentTermService.ts · termSearchService.ts · directory-api.ts	같음(키 비면 파이프라인·스케줄러 비활성)	같음	termLinkSync.test.ts · contentTermService.test.ts
GuideCenter	server/termLinkSync.ts · termLinkDirectory.ts · contentTermService.ts · termSearchService.ts · translationGlossary.ts · directoryAuth.ts · directorySync.ts	DIRECTORY_BASE_URL(기본값 https://directory.rlab.monster)	같음	termLinkSync.test.ts · translationGlossary.test.ts
공통(화면)	portal-foundation PortalTerm · PortalTermList 툴팁(0.6.168)이 호출하는 엔드포인트	—	glossary:read	툴팁이 새 주소를 보는지 확인 — 같은 경로 제공이 절체 조건

8. 인증·키 경계

• 지금: PortalConsole 이 PORTAL_API_KEYS_JSON(scope glossary:read · glossary:write)으로 소비자를 검증하고, 일부 서비스는 콘솔이 서명한 JWT(audience·scope)를 받는다.
• 이관 후: 키 발급·검증 주체가 새 서비스로 이동한다. scope 이름은 그대로 두어 소비자 env·권한 문서를 재사용한다. 콘솔은 포털 등록·접근정책만 소유한다.

키 값에 대한 규칙 (운영에서 자주 헷갈리는 지점)

질문	답
새 서비스용 키를 새로 발급하나?	아니다. 각 소비자가 지금 콘솔로 보내는 키를 같은 값 그대로 새 서비스의 PORTAL_API_KEYS_JSON 에 등록한다.
소비자끼리 같은 키를 쓰나?	아니다 — 포털마다 자기 키를 쓴다(현행 유지). 그래야 호출 포털 귀속(portalId)과 유출 격리가 된다.
콘솔과 새 서비스의 PORTAL_API_KEYS_JSON 이 같아야 하나?	설정은 서비스별 독립이고, 담는 키 값만 같다. 이관 기간에는 같은 키를 양쪽에 등록해 소비자가 어느 쪽을 보든 통과하게 한다.
키에 다른 scope(directory:read 등)가 함께 있어도 되나?	무해하다 — 새 서비스는 자기 라우트의 scope 만 검사한다. 반대로 키에 glossary:* 가 없으면 403 insufficient_scope 다.
원본 키 값은 어디서 얻나?	콘솔 DB 에는 해시만 있다. 각 소비자 앱(Coolify)의 env 에서 가져온다 — DIRECTORY_PORTAL_API_KEY(구 이름 PORTAL_CONSOLE_PORTAL_API_KEY · PORTAL_CONSOLE_API_KEY 도 호환).

• 전환: 소비자는 키를 바꾸지 않는다 — 주소(DIRECTORY_BASE_URL → ONTOLOGY_BASE_URL)만 바꾼다. 절체 완료 후 콘솔 쪽 키에서 glossary:* scope 를 회수한다.
• 서비스별 전용 키(최소 권한 분리)로 쪼개는 일은 이관 후 별건이다(소비자 코드·배포 변경이 필요하다).
• JWT 로 접근하는 소비자가 있으면 이관 후 서명 주체가 새 서비스로 바뀐다 — 현재 3곳(ProcessCenter·DocumentLibrary·GuideCenter)은 API 키 경로다.

9. 검증 기준 (이관 성공)

1. 표 3개의 행 수 · updated_at 최대값 · status='approved' 필터 결과가 콘솔과 동일.
2. 팩 지문 동일 — 번역 팩 translationPackVersion(sha256)과 온톨로지 팩 packVersion·개념/관계 수.
3. REST 4종 골든 응답 대조 — data.skipped(미승인 용어)와 tombstone(소프트 삭제) 의미가 유지된다.
4. 소비자 3곳 테스트 통과 + 실연결 1회(용어 매칭 push → 원장 반영 → pull 확인).
5. 감사 1건(승인)이 새 서비스 감사에 남고 콘솔과 중복 기록되지 않는다.
6. 화면 — 툴팁에 정의가 뜨고, 새 표면에서 승인·폐기가 동작한다.

10. 롤백·중단 조건

• P3·P4 는 env 한 줄로 되돌아가야 한다(폴백을 P5까지 유지).
• 중단: 팩 지문 불일치 · 소비자 테스트 실패 · 감사 이력 단절 · 소비자 한 곳이라도 실연결 실패 · 데이터 행 수 차이 1건 이상 · 툴팁 정의 미표시.

11. 선행·미결

• ONTOLOGY_SCOPE.md §8 미결 2건(공유 스토리지 경로 규약 · 색인 재발행 시점)은 추출·색인 연결 전에 확정한다.
• 그래프 DB 미신설 결정과 재검토 조건(다단계 관계 질의 · 수만 건 조회 지연)은 새 서비스로 승계한다.
• ✅ 감사 이력 연속성 — 확정(2026-10-16): 복사. P2 에서 콘솔 directory_audit_logs 의 entity_type='ONTOLOGY' 행을 새 서비스 표(directory_audit_logs)로 옮긴다 — 표 이름·컬럼·봉투 키·AAD 가 같아 스냅샷이 그대로 복호화된다. 콘솔 원본은 이력 추적용으로 남긴다.
• ✅ 감사 봉투 키 — 확정(2026-10-16 승인): 콘솔과 같은 값 주입. 과거 행 복호화가 목적이라 PORTAL_CONSOLE_ENVELOPE_MASTER_KEY(+_LEGACY_MASTER_KEYS)를 같은 값으로 넣는다. 키가 두 곳에 존재하게 되므로 이관 완료 후 회전 계획을 세운다(런북 §1-2).
• ✅ 파일 보관 탭 제거(2026-10-16) 는 2026-09-15 결정("운영 표면은 콘솔")과 어긋나 있었고, P0 에서 같은 절차로 개정 기록했다 — DECISION_LOG.md(2026-10-16 "파일 보관 표면 전환") · SERVICE_BOUNDARIES.md 저장 라우팅 개정.
• ✅ 번역 실행 의존성 — 확정(2026-10-16): 마지막 팩 캐시. 콘솔이 OntologyService 에서 번역 팩을 읽도록 바뀌는 P3 에서 캐시를 붙인다 — 마지막으로 성공한 팩을 남겨 두고, 지식 서비스가 답하지 못하면 그 팩으로 번역을 계속한다(캐시조차 없으면 용어 없이 번역하고 그 사실을 응답에 남긴다). GuideCenter GUIDE_TRANSLATION_PROVIDER=local 폴백과 같은 정신이다.
• ProcessCenter 의 용어 편집 표면(TerminologyManager.tsx)은 이관과 함께 읽기 전용 또는 새 서비스 링크로 정리해 중복 편집을 없앤다.

12. 하지 않는 것

업무 데이터(프로세스 정의·문서 본문) 이관 ❌ · 추론 규칙 엔진·bitemporal ❌ · 콘솔의 포털 접근정책·등록 이관 ❌ · 승인 없는 자동 반영 ❌ · 중앙 그래프 DB 신설 ❌(별도 결정 사항).

13. 실행 현황

1. ✅ P0 완료(2026-10-16) — 이 문서를 확정으로 전환하고 §5 문안을 UiPlatform docs/DECISION_LOG.md(2026-10-16 두 항목) · docs/SERVICE_BOUNDARIES.md · docs/ONTOLOGY_SCOPE.md 에 반영했다. 같은 커밋에서 파일 보관 표면 전환도 개정 기록(§11).
2. 🟡 P1a 완료(2026-10-16) — 새 저장소 ~/projects/OntologyService 를 세우고 데이터 계층을 이식했다. 표 3개 + 감사 로그 스키마(drizzle/schema.{ts,mysql,pg}.ts), 양쪽 방언 마이그레이션 생성(PG 0000_eminent_sphinx, MySQL 0000_flippant_the_hunter), 원장 코드 5종·인프라 5종 이식(출처 주석 포함), 이식 테스트 8파일 39건 통과, check 0 · build 0. 로컬 git(main) 초기 커밋 완료.
3. 🟡 P1b 진행(2026-10-16) — 소비자 REST 표면을 옮겼다: server/portalRoutes.ts(라우트 13개 — 용어 CRUD·번역팩·온톨로지팩·매칭사전·후보 등록/조회/승인·컨텐츠 연결 GET/POST/DELETE) + portalAccess.ts(포털 키·scope) + app.ts(express) + apiKeys.ts(PORTAL_API_KEYS_JSON). 콘솔의 라우트 계약 테스트 2파일을 그대로 가져와 통과(10파일 50건, check 0 · build 0) — 경로·scope·응답 스키마 동일성의 근거다. 중앙 번역(POST /translation)은 옮기지 않았다(2026-10-11 결정).
4. 🟡 P1b 관리자 표면(2026-10-16) — server/adminRoutes.ts 로 /api/ontology/v1/admin/* 13경로를 열었다: 용어 목록·등록/수정·비활성/완전삭제, 후보 목록·승인·폐기, 관계 목록·등록·폐기, 팩 내보내기, 승인 이력, 연결 검토·해제. 인증은 전용 헤더 x-directory-admin-key(ONTOLOGY_SERVICE_ADMIN_API_KEYS_JSON, 콘솔 이름 폴백)이고 키가 설정되지 않았으면 503 이다(설정 누락을 자격증명 오류로 위장하지 않는다 — 콘솔의 2026-09-30 교훈). 관리자 쓰기는 updated_by 를 ONTOLOGY_SERVICE 로 남겨 이관 뒤 출처를 구분한다. 계약 테스트 adminRoutes.test.ts 10건 포함 11파일 60건 통과(check 0 · build 0).
5. 🟡 P1c 진행(2026-10-16) — ⑴ 키 저장소: ontology_api_keys 표 + server/apiKeyStore.ts, 관리자 경로 GET/POST /keys·POST /keys/:keyId/rotate·PATCH /keys/:keyId·DELETE /keys/:keyId. 원문 키는 발급·회전 응답에서 한 번만 보이고 해시만 저장하며(접두사 otk_), 인증은 환경변수 키 + 저장 키를 함께 본다 — 키 저장소 장애는 503(401로 위장하지 않는다). ⑵ 용어 시드: scripts/seed-glossary-terms.mjs(pnpm seed:glossary, ONTOLOGY_BASE_URL·ONTOLOGY_PORTAL_API_KEY, 콘솔 이름 폴백) — --dry-run 으로 38개 표준 표기 확인. 게이트 12파일 66건 통과(check 0 · build 0).
6. 🟡 P1c 관리자 화면(2026-10-16) — client/ 에 portal-foundation PortalAdminShell 기반 React 앱을 세웠다(콘솔과 같은 룩). 탭 3개: 용어사전(목록·등록·수정·비활성) · 승인 대기(후보 승인 — 표준 번역·정의를 채워 확정 — 과 폐기) · 소비 포털 키(발급·회전·중지·삭제, 원문 1회 노출). 관리자 키는 브라우저 세션 저장소에만 두고 x-directory-admin-key 로 보낸다(콘솔과 같은 방식). 빌드는 vite build → dist/public 이고 서버가 정적으로 서빙한다. 남은 화면은 관계(목록·등록·폐기) · 팩·이력(내보내기·승인 이력)이다.
7. ✅ 확정(2026-10-16) — ⑴ 번역 팩 폴백: 마지막 팩 캐시(§11 — P3 에서 콘솔에 캐시를 붙인다) ⑵ 배포는 사용자가 담당하고, 마이그레이션은 배포가 자동 적용한다(start = migrate → index, RUN_MIGRATIONS_ON_START=false 로 해제).
8. ✅ P1 완료(2026-10-16) — 관리자 화면 여섯 탭(용어사전·승인 대기·관계·팩·이력·소비 포털 키·관리자 계정)과 계정 로그인(세션 JWT 8시간·scrypt 해시)까지 붙었다. 실제 DB로 계정 생성→로그인→토큰 인증→401→정리를 확인했다. 다음은 P2(데이터·감사 이력 복사)다.
9. ✅ 결정 확정(2026-10-16 승인) — ⑴ 원격 저장소 github.com:hohyun94/OntologyService(비공개) ⑵ DB 토폴로지 PostgreSQL A안(§14) ⑶ 감사 이력 복사(§11) ⑷ 감사 봉투 키 콘솔과 같은 값(§11) ⑸ 번역 팩 폴백 마지막 팩 캐시(§11 · P3 에서 콘솔에 캐시) ⑹ 배포는 운영자 담당, 스키마는 시작 명령이 자동 적용
10. ✅ P2 실행 방식(2026-10-16 승인) — 운영자가 로컬에서 1회 pnpm p2:migrate(+절체 직전 --since 증분, --verify-only 대조). 절차: docs/ontology-move-runbook.md §2.
11. ✅ P3 방식(2026-10-16 승인) — 순차 절체(ProcessCenter → DocumentLibrary → GuideCenter → 콘솔 번역) · 키는 그대로, 주소만 바꾼다 · 롤백 = env 한 줄(런북 §3).
12. ✅ P4 시점(2026-10-16 승인) — 절체 후 1주 관찰 뒤 콘솔 탭 제거·런처 전환, ProcessCenter 용어사전은 쓰기 제거 + OntologyService 링크(런북 §4).
    • ✅ 콘솔 표면 완료(2026-10-17) — 관리자 메뉴 온톨로지 탭 제거, 등록된 ontology 포털(PLATFORM_SERVICE)을 레일 하단 OntologyService 런처로 전환. OntologyDesk 자산은 롤백용으로 유지.
13. ✅ 배포 자산(2026-10-16) — OntologyService 에 Dockerfile(2단계)·.dockerignore·docker-compose.onprem.yml 추가. 폐쇄망 번들은 온라인 안정화 후(런북 §6).

남은 일: P2 실행(운영자) → P3 순차 절체 → P4 표면 전환 중 ProcessCenter 용어사전 쓰기 제거 → P5 구 경로 폐기. 콘솔 메뉴·런처 전환은 완료했다. P2 런북은 작성 완료 — docs/ontology-move-runbook.md.

14. DB 토폴로지와 준비 절차 (확정 — PostgreSQL · A안)

확정(2026-10-16): PostgreSQL · A안 — 같은 서버에 논리 DB ontology + 계정 ontology_service. 아래는 그 근거와 준비 절차다.

결론: 새 클러스터(서버)는 필요 없다. 같은 PostgreSQL 서버에 「별도 논리 DB + 전용 계정」을 만든다.계정만 새로 만들고 콘솔과 같은 논리 DB 를 쓰는 것은 안 된다 — 이 서비스는 이관 호환을 위해 표 이름을 콘솔과 똑같이(directory_glossary_terms·directory_ontology_relations·directory_content_term_links·directory_audit_logs) 유지하므로, 같은 이름 공간에 계정만 추가하면 CREATE TABLE 이 기존 표와 충돌한다.

집안 관례도 같다 — FileStore docs/SHARED_POSTGRES_DATABASE.md("the shared PostgreSQL instance with its own logical database and database user"), ProcessCenter MULTI_PLATFORM_DEPLOYMENT.md(.../processcenter).

안	내용	평가
A (권장)	같은 서버 + 새 논리 DB ontology + 전용 계정 ontology_service	관례와 일치 · 최소 권한 분리 · 이관 복사가 한 SQL 문 ✅
B	같은 논리 DB 안의 별도 스키마 ontology(+ search_path)	충돌은 피하지만 설정·운영이 복잡하고 계정 분리 효과가 약하다 ⚠️
C	표 이름에 접두사(ontology_*)를 붙여 콘솔 DB 공유 (FileStore 방식 file_store_*)	계정만 추가하면 되지만 "표 이름 동일" 규칙을 깨 복사·문서·테스트에 이름 매핑이 생긴다 ⚠️

• A안 준비 절차 (PostgreSQL 예)

-- 같은 서버에서 관리자 계정으로 한 번
CREATE DATABASE ontology;
CREATE ROLE ontology_service LOGIN PASSWORD '<secret>';
GRANT ALL PRIVILEGES ON DATABASE ontology TO ontology_service;

마이그레이션은 배포가 적용한다 (2026-10-16 확정). 새 서비스의 시작 명령이 node dist/migrate.js && node dist/index.js 라, Coolify 가 배포하면 스키마가 함께 반영된다 — 운영자가 psql 로 들어갈 필요가 없다. RUN_MIGRATIONS_ON_START=false 로 끌 수 있다. 배포(앱 생성·env·도메인)는 사용자가 담당한다.

손으로 확인하고 싶을 때만:

DATABASE_DIALECT=postgresql \
DATABASE_URL='postgresql://ontology_service:<secret>@<same-host>:5432/ontology' \
pnpm migrate

• MySQL 이면 "스키마 = 데이터베이스"이므로 A안이 그대로 CREATE DATABASE ontology 다(콘솔과 같이 pnpm db:generate → db:push 관례를 쓴다).
• P2 복사는 같은 서버라 INSERT INTO ontology.<표> SELECT * FROM <콘솔 논리 DB>.<표> 한 문장으로 끝난다(다른 서버면 두 연결을 쓰는 스크립트가 필요). 복사 실행 계정은 콘솔 논리 DB 읽기 권한만 있으면 된다.
• 봉투 암호화 키(PORTAL_CONSOLE_ENVELOPE_MASTER_KEY)는 콘솔과 같은 값을 넣어야 복사한 감사 스냅샷이 복호화된다(§11).