Platform Docs

Appearance

플랫폼 비전 — 데이터에서 의미로, 의미에서 성과로 ​

작성: 2026-09-14 · 상태: 방향 확정 — 세부 범위는 §9 미해결 결정에서 순차 확정 · 문서 라이브러리 완료 반영(2026-09-14)관련 문서: PLATFORM_NAMING.md(명칭) · SERVICE_BOUNDARIES.md(경계) · MODEL_GATEWAY_SCOPE.md(AI 완성) · FILE_STORE_SCOPE.md(저장 라우팅) · AI_FEATURE_REGISTRY.md(AI 기능 레지스트리) · DECISION_LOG.md(결정 이력)

1. 노스 스타 ​

흩어진 데이터를 의미망(온톨로지·지식 그래프)으로 승화하고, AI가 그 위에서 의미를 도출해 각 포털의 비즈니스 성과로 이어지게 하는 기반을 만든다.

플랫폼은 성과를 직접 만들지 않는다. 성과는 각 포털이 낸다. 플랫폼이 만드는 것은 그 앞단 — 데이터를 지식으로, 지식을 의미로 바꾸는 기반이다. 이 문서는 그 방향과 경계를 고정해, 이후 모든 설계 판단의 기준이 되게 한다.

2. 가치 사슬 ​

[데이터]  정형(포털 DB) · 비정형(FileStore) · 관계(프로세스) · 문서(가이드)
   │  수집 · 색인 · 구조화
   ▼
[지식]    온톨로지 · 지식 그래프 — 개념·관계·표준 용어의 의미망
   │  AI(검색 · RAG · 추론 · 완성)
   ▼
[의미]    통찰 · 근거 · 요약 · 분석 — "의미 있는 내용 도출"
   │  각 포털의 의사결정
   ▼
[성과]    비즈니스 성과 — 품질 · 자동화 · 비용 · 의사결정
단계내용담당
데이터정형·비정형·관계·문서를 각 소유자에 두고 수집·색인각 포털 · FileStore · RagService/ExploreGateway
지식개념·관계·용어를 표준 온톨로지로 정의하고 데이터에서 추출온톨로지 계층(§9에서 소유 확정)
의미검색·RAG·추론으로 근거 있는 통찰 도출ModelGateway + RagService/ExploreGateway
성과업무 의사결정·자동화·품질 개선각 포털

플랫폼이 책임지는 구간은 데이터 → 지식 → 의미까지이고, 의미 → 성과는 각 포털의 몫이다. 이 경계가 흐려지면 플랫폼이 업무 판단을 대신하게 되어, 지금까지 지켜온 소유권 원칙이 무너진다.

3. 플랫폼 구성요소 지도 ​

축구성요소역할
제어PortalConsole사용자·조직·인증·포털 접근권한·정책·AI 기능 등록·관측
표현UiPlatform + portal-foundation테마·UI·CSS 원천(패키지) + 릴리스·배포 통제
의미온톨로지·용어 표준개념·관계·표준 용어(현재는 번역 용어 사전)
저장FileStore비정형 파일 원본 보관·스캔·색인 발행 + 포털별 저장 라우팅(백엔드·정책 — 2026-09-15)
검색RagService · ExploreGateway문서 색인·벡터 검색·RAG·통합 검색
완성ModelGateway모델 접근·키·쿼터·비용·감사
업무각 포털 (…Center)업무 기능·메뉴·업무 데이터·업무 규칙
  • AI 계층은 별도 서비스가 아니라 완성 + 검색/RAG + 계약(ai-core) + 제어(기능 레지스트리)를 가로지르는 횡단 능력 계층이다(§5).
  • 운영 표면은 둘로 나뉜다 — 제어는 PortalConsole, 표현은 UiPlatform.

4. 핵심 원칙 (기존 결정과의 정합) ​

이 비전은 새 원칙을 만들지 않는다. 이미 확정된 결정들을 하나의 방향으로 묶은 것이다.

원칙내용근거
업무는 각 포털 소유업무 데이터·업무 규칙·프롬프트 내용·성과 판단은 각 포털이 소유한다MODEL_GATEWAY_SCOPE §3 · §8-1
공통기능은 Asset게시판·첨부파일·AI 유틸 같은 재사용 기능은 중앙 런타임·중앙 DB로 통합하지 않고 템플릿/Asset으로 제공한다DECISION_LOG 2026-08-20 · PLATFORM_NAMING §1
표현과 통제 분리테마·UI·CSS의 원천은 portal-foundation, 통제(릴리스·구독·배포)는 UiPlatformSERVICE_BOUNDARIES
서비스 분리 · 표면 통합실행은 각 플랫폼 서비스가 소유하고, 목록·정책·사용량의 운영 표면은 PortalConsole 한 곳으로 모은다DECISION_LOG 2026-09-14 · AI_FEATURE_REGISTRY
모델은 연결 대상기능은 모델을 모른다. 기능은 purpose만 알고, 모델 선택·교체·키 회전·쿼터는 플랫폼이 담당한다MODEL_GATEWAY_SCOPE §4 · §7
플랫폼은 실행하지 않는다문서·업무 로직을 중앙에서 실행하지 않는다. 이해·참조·색인·관측만 제공한다본 문서 §2

5. AI 계층 상세 ​

5-1. 3층 구조 ​

[3] 포털 개별 기능 — AI를 써서 만든 도메인 기능 (비즈니스 분석 등)   ← 각 포털 소유
        ↑ 조합 · 호출
[2] AI 공통기능 — 모델을 이용해 구현한 재사용 기능 (번역·요약·RAG·실시간 번역)
        ↑ 연결                                                    ← portal-foundation(계약)
[1] 모델 연결 — LLM·임베딩 접근, 키·쿼터·비용·감사                    ← ModelGateway · RagService/ExploreGateway
층정의소유자
[1] 모델 연결모델 접근·키 격리·쿼터·비용·감사ModelGateway · RagService/ExploreGateway
[2] AI 공통기능모델을 써서 구현한 재사용 기능재사용 구현·계약 = portal-foundation(@hohyun94/portal-ai) · 등록·정책 = PortalConsole
[3] 포털 개별 기능자기 메뉴 안에서 AI를 조합해 만든 업무 기능각 포털

[3]은 무한히 조합된다 — 포털의 한 메뉴 기능이 번역·요약·RAG를 내부에서 조합해 "비즈니스 분석"을 만들고, 그 결과를 다시 다른 기능이 조합할 수 있다. 그래서 AI 기능 목록은 고정 enum이 아니라 열린 레지스트리여야 한다(AI_FEATURE_REGISTRY.md).

5-2. purpose가 통화(currency)다 ​

기능은 purposeId(예: process.version-summary)로 귀속되고, 사용량·쿼터·비용이 그 단위로 집계된다.

  • 모델 교체 = purpose ↔ 모델 매핑만 변경(기능 코드 무변경)
  • 중첩 조합 = 하위 호출도 각자 purpose로 귀속되어 집계가 정확히 남는다
  • 귀속 축 = 기능(purpose)이 기본, 메뉴별 집계는 포털이 보조 축을 얹는다

5-3. 개발자 경험(DX) ​

기능 개발자는 모델이 아니라 목적(purpose)을 선언한다.

개발자(purpose 선언) → ai-core SDK → ModelGateway(모델·키·라우팅·쿼터) → 실제 모델

개발자는 "어떤 모델을 쓸지"가 아니라 "어떤 기능을 만들지"에만 집중하고, 모델 제공·교체·모니터링·통제는 플랫폼이 담당한다. 이것이 AI 계층의 존재 이유다.

6. 데이터와 온톨로지 상세 ​

6-1. 데이터는 세 형태로 쌓인다 ​

형태예소유
정형 데이터각 포털 DB의 레코드(프로세스·게시판·사용자)각 포털
비정형 데이터첨부파일·문서·이미지FileStore(포털별 백엔드·정책으로 라우팅)
관계정보"이 문서는 이 프로세스에 속하고, 이 사용자가 승인하고, 이 조직에 귀속"각 포털의 프로세스·업무 데이터

관계정보가 정형과 비정형을 잇는 다리다.

정형(DB 레코드) ──관계──> 비정형(FileStore 파일)
      └─────────관계──> 조직·사용자(PortalConsole 원본)

6-2. 비즈니스 로직은 코드에만 있지 않다 ​

가이드·매뉴얼·SOP 같은 문서에도 업무 규칙이 자연어로 담긴다(GuideCenter + FileStore). 이것은 단순 첨부파일이 아니라 기계가 이해해야 할 지식이다.

가이드 문서(자연어 로직) → FileStore(원본) → RagService(색인·벡터) + 온톨로지(개념·관계)
   → AI(RAG·추론) — 문서에 담긴 로직을 근거로 답·분석

단, 플랫폼은 그 로직을 중앙에서 실행하지 않는다. 업무 로직의 실행은 각 포털이 소유하고, 플랫폼은 이해·색인·근거 제공까지만 담당한다.

6-3. 온톨로지는 양방향으로 만들어진다 ​

방향내용
하향식(표준)사람이 개념·관계·표준 용어를 정의한다 — 현재 glossary(번역 용어)가 이 씨앗
상향식(추출)쌓인 데이터·문서에서 개념과 관계를 발견한다(온톨로지 학습·지식 그래프 구축)

실제로는 표준 온톨로지가 뼈대를 잡고, 데이터에서 추출한 엔티티·관계가 살을 채운다. 그래야 데이터가 단순히 쌓이는 것이 아니라 계속 의미망으로 승화된다.

절차(확정, 2026-09-14): 표준 등록(사람) → 추출(자동, ontology.extract) → 승인(사람) → 색인 반영 → 용어팩 버전 배포. 범위·소유·저장·생성의 전문과 관계 유형 7종은 ONTOLOGY_SCOPE.md.

7. 운영 표면 ​

콘솔통제 대상
PortalConsole제어평면 — 사용자·조직·인증·포털 접근권한·정책·AI 기능 등록·정책·사용량
UiPlatform표현평면 — 공통 UI 테마·릴리스·배포(portal-foundation 수명주기)

AI 운영 표면의 뷰는 세 가지다 — 적용 현황(포털×기능), 사용량(포털×기능), 세팅(모델·키·색인·쿼터). 규격은 AI_FEATURE_REGISTRY.md.

플랫폼이 만든 문서(비전·결정·규격·보고서)를 축적해 조회하는 문서 라이브러리도 같은 원칙을 따른다 — 조회 표면은 PortalConsole(관리자 메뉴), 보관은 오브젝트 스토리지(R2 platform-docs/), 검색·질의는 후속으로 RagService 색인.

비정형 파일의 저장 라우팅(어느 백엔드에 어떤 보존·허용 형식·색인 발행 정책으로 둘지)은 FileStore가 소유하고, 그 운영 표면(목록·등록·진단)은 콘솔 관리자 메뉴가 갖는다 — 콘솔은 서버 간 호출로만 접근하고 파일 본문·자격증명은 소유하지 않는다(2026-09-15 · FILE_STORE_SCOPE.md).

8. 로드맵 ​

단계내용상태
기반게이트웨이 API 전용화 + 콘솔 관리 화면(모델·키·설정·사용량)✅ 완료
규격AI 기능 레지스트리 규격(열린 목록·요구 능력)✅ 완료
문서문서 라이브러리 — 보관=R2 platform-docs/(미구성 시 로컬 파일시스템) · 표면=콘솔 관리자 메뉴 · 게시 자동화=UiPlatform CI가 POST /api/library/v1/documents로 적재✅ 완료
지식온톨로지 범위·소유자·저장·생성 방식 확정✅ 완료 — ONTOLOGY_SCOPE.md (2026-09-14)
저장포털별 비정형 파일 저장 라우팅(백엔드·정책) 소유·표면 계약✅ 계약 완료 — FILE_STORE_SCOPE.md (2026-09-15) · 콘솔 파일 보관 데스크 구현은 ⏳
검색RagService·ExploreGateway의 콘솔용 관리·상태 API 계약⏳ 진행 — 경계 확정(A안, SEARCH_SCOPE.md) · 계약 초안 완료 · 실제 연결은 서비스 가용 후
능력ModelGateway 스트리밍 재개(실시간 번역 등)⏳ 조건부
승격포털 카탈로그의 고정 capabilities → 기능 레지스트리⏳ 다음

문서 단계 완료 근거(2026-09-14): PortalConsole #17(메뉴) · #18(로컬 파일시스템 폴백) · #19(CI 게시 REST 라우트) · #20(보관소 공급자 선택), UiPlatform #10(내보내기·게시 스크립트 + 워크플로) · #11·#13(결정 기록 정합). 게시된 문서는 platform-docs/{docId}/{version}/{file} 규약으로 쌓이고, 같은 코퍼스가 지식 단계의 첫 입력이 된다.

9. 결정 상태 ​

확정(2026-09-14 · ONTOLOGY_SCOPE.md · 2026-09-15 · SEARCH_SCOPE.md · FILE_STORE_SCOPE.md · DECISION_LOG.md)

#항목결정
1온톨로지 범위문서·프로세스에 실제 등장하는 개념·관계·용어. 공급원 = ProcessCenter 프로세스 정의 + GuideCenter 정책문서 + 사내 비정형 문서. 개별 업무 산출물은 범위 밖(다음 단계)
2온톨로지 소유자분할 소유 — 스키마·용어팩 = portal-foundation(Asset) · 표면 = PortalConsole · 실데이터 = 각 소유자
3지식 그래프 저장·색인어댑터 수집(원본 유지) + 기존 색인. 그래프 DB 신설 보류(재검토 조건 있음)
4온톨로지 생성 방식수동 뼈대 + 자동 살(제안 → 승인) · 관계 유형 7종 고정
5RagService ↔ ExploreGateway 경계오케스트레이션 = ExploreGateway · 색인·RAG·citation = RagService (2026-09-15, 실제 라우트로 검증 — SEARCH_SCOPE.md)
7포털별 파일 저장 라우팅소유 = FileStore(백엔드·정책·보존·ragPublishAllowed) · 표면 = PortalConsole(서버 간 프록시) · 콘솔은 파일 본문·자격증명 미소유 (2026-09-15 — FILE_STORE_SCOPE.md)

미해결

#항목쟁점
6개별 업무 산출물 수용특정 결재 건·실행 결과 보고서 등 인스턴스를 온톨로지에 태울지 — 전제는 복제가 아니라 참조·색인

항목 1~4는 ONTOLOGY_SCOPE.md(2026-09-14), 항목 5는 SEARCH_SCOPE.md(2026-09-15), 항목 7은 FILE_STORE_SCOPE.md(2026-09-15)에 근거·검증·계약이 있고, 결정 기록은 DECISION_LOG.md에 있다. 이 문서는 방향을 고정한다.