47 KiB

Raw Blame History

온톨로지 구축 플랫폼 연구보고서

웹사이트 탐색 기반 자동 온톨로지 구축 시스템의 필요성, 구조, 기능 명세, 구축 이유

0. 보고서의 목적

이 보고서는 현재 개발 중인 AI 기반 온톨로지 구축 툴을 단순한 데이터 편집 도구가 아니라, 실제 상용화 가능한 웹사이트 탐색 기반 자동 온톨로지 구축 플랫폼으로 발전시키기 위한 연구 자료이다.

현재 시스템은 웹사이트에서 수집된 데이터로부터 엔티티와 클레임을 생성하고, 이를 사용자가 직접 확인하거나 수정할 수 있는 구조를 갖추고 있다. 그러나 화면상으로는 아직 다음과 같은 한계가 드러난다.

온톨로지가 어떤 과정으로 만들어졌는지 보이지 않는다.
AI가 어떤 근거로 엔티티와 관계를 추출했는지 확인하기 어렵다.
사이트 탐색, 페이지 분석, 스키마 설계, 품질 검증, 승인 절차가 분리되어 보이지 않는다.
사용자는 결과 목록은 볼 수 있지만, 시스템이 “지능적으로 구축한다”는 인상을 받기 어렵다.
현재 화면은 상용 플랫폼보다는 내부 관리자용 클레임 편집기에 가깝다.

따라서 이 보고서의 목적은 다음과 같다.

온톨로지 구축 시스템이 무엇을 해야 하는지 정리한다.
각 기능이 왜 필요한지 설명한다.
개발자와 기획자가 시스템의 구조를 이해할 수 있도록 교육 자료 역할을 한다.
현재 시스템을 상용화 가능한 수준으로 확장하기 위한 기능 명세를 제안한다.
“왜 이렇게 구축해야 하는가”에 대한 설득 논리를 제공한다.

1. 온톨로지란 무엇인가

1.1 온톨로지의 기본 의미

온톨로지는 어떤 분야의 지식을 컴퓨터가 이해할 수 있도록 개념, 속성, 관계로 구조화한 지식 체계이다.

일반적인 데이터베이스가 단순히 값을 저장한다면, 온톨로지는 그 값들이 서로 어떤 의미적 관계를 갖는지 표현한다.

예를 들어 향수 구독 사이트를 분석한다고 가정해보자.

단순 데이터는 다음과 같이 저장될 수 있다.

상품명: 포맨트 퍼퓸 코튼 허그
가격: 44,000원
브랜드: 포맨트
향 설명: 부드러운 머스크 파우더리 노트...

하지만 온톨로지는 이를 다음과 같이 구조화한다.

포맨트 퍼퓸 코튼 허그 → hasBrand → 포맨트
포맨트 퍼퓸 코튼 허그 → hasPrice → 44,000원
포맨트 퍼퓸 코튼 허그 → hasBaseNote → 머스크
포맨트 퍼퓸 코튼 허그 → belongsToCategory → 퍼퓸

이 차이가 중요하다.

단순 데이터는 사람이 읽을 수 있는 정보이고, 온톨로지는 기계가 추론하고 연결할 수 있는 지식 구조이다.

1.2 온톨로지의 핵심 구성 요소

온톨로지는 보통 다음 구성 요소로 이루어진다.

구성 요소	의미	예시
Entity	개별 대상	포맨트 퍼퓸 코튼 허그, 포맨트, 머스크
Entity Type	대상의 종류	Product, Brand, Note, Category
Predicate	관계 또는 속성	hasBrand, hasPrice, hasBaseNote
Claim	주어-술어-목적어 형태의 지식 단위	상품 A hasBrand 브랜드 B
Source	정보의 출처	특정 URL, 특정 문장
Confidence	신뢰도	0.84, 0.92
Schema	온톨로지의 설계 규칙	Product는 Brand를 가질 수 있다

현재 시스템에서 보이는 클레임 목록은 온톨로지의 일부에 해당한다. 그러나 상용 온톨로지 툴이 되려면 단순히 클레임을 보여주는 것에서 끝나면 안 된다. 그 클레임이 어디서 왔고, 왜 생성되었으며, 어떻게 검증되었고, 전체 지식 구조 안에서 어떤 위치에 있는지 보여줄 수 있어야 한다.

2. 현재 시스템의 상태와 문제점

2.1 현재 화면의 장점

현재 화면에는 이미 의미 있는 기반이 존재한다.

프로젝트 단위가 있다.
엔티티 수가 표시된다.
클레임 수가 표시된다.
Subject, Predicate, Object 구조를 직접 입력할 수 있다.
신뢰도 값이 있다.
소스 정보가 있다.
rule_candidate 같은 생성 방식 또는 상태 태그가 있다.

이는 온톨로지 구축의 핵심 데이터 구조에 어느 정도 접근하고 있다는 뜻이다. 즉, 완전히 잘못된 방향은 아니다.

문제는 기반 데이터는 있지만, 플랫폼 경험이 부족하다는 점이다.

2.2 현재 시스템의 핵심 문제

현재 화면은 사용자가 보기에는 다음과 같은 인상을 준다.

데이터가 수집되었고, 그 결과가 목록으로 나열되어 있다.
사용자는 그 목록을 수동으로 수정한다.

하지만 상용화된 AI 온톨로지 플랫폼은 다음 인상을 줘야 한다.

시스템이 사이트를 탐색하고,
페이지를 이해하고,
핵심 개체를 추출하고,
관계를 만들고,
품질을 검증하고,
사람이 승인하면,
온톨로지로 확정된다.

즉, 현재 시스템은 결과 화면은 있지만 과정 화면이 부족하다.

상용 플랫폼처럼 보이려면 “결과 목록”이 아니라 “지식 구축 공정”을 보여줘야 한다.

2.3 특히 개선이 필요한 부분

1. 자동 구축 과정이 보이지 않는다

사용자는 현재 클레임이 어떻게 만들어졌는지 알기 어렵다. 어떤 페이지에서 왔는지, 어떤 문장에서 추출되었는지, 어떤 룰 또는 AI 분석이 사용되었는지 명확히 보여야 한다.

2. 스키마 설계가 보이지 않는다

hasBrand, hasPrice, hasBaseNote 같은 Predicate가 사용되고 있지만, 이 관계들이 어디서 정의되었고 어떤 규칙을 갖는지 보이지 않는다.

3. 검증 절차가 약하다

AI가 만든 후보를 바로 온톨로지로 받아들이면 데이터 품질이 떨어질 수 있다. 후보, 승인, 반려, 보류 상태가 필요하다.

4. 품질 진단이 부족하다

중복 엔티티, 잘못된 관계, 출처 없는 클레임, 모순된 가격 같은 문제가 자동으로 표시되어야 한다.

5. 시각적 구조가 부족하다

온톨로지는 본질적으로 관계 그래프이다. 목록만으로는 온톨로지가 구축되고 있다는 느낌을 주기 어렵다. 그래프 뷰가 필요하다.

3. 온톨로지 구축 플랫폼의 목표 모델

3.1 이 시스템이 최종적으로 해야 하는 일

이 시스템의 최종 목표는 다음과 같이 정의할 수 있다.

사용자가 특정 웹사이트 또는 도메인을 입력하면, 시스템이 사이트를 탐색하고, 페이지를 분류하고, 핵심 개체와 관계를 추출하고, 사람이 검증할 수 있는 후보를 제시한 뒤, 승인된 항목을 온톨로지로 구축하는 플랫폼.

이를 단계로 나누면 다음과 같다.

1. 사이트 입력
2. 페이지 탐색
3. 페이지 유형 분류
4. 본문 정제
5. 엔티티 추출
6. 관계/클레임 생성
7. 중복/오류/모순 검증
8. 사용자 검토 및 승인
9. 온톨로지 반영
10. 그래프 확인 및 외부 Export

이 흐름이 화면과 기능에 드러나야 한다.

3.2 이 시스템이 단순 크롤러와 다른 점

일반 크롤러는 웹페이지에서 텍스트나 HTML을 가져온다.

하지만 온톨로지 구축 플랫폼은 단순히 데이터를 가져오는 것이 아니라, 데이터의 의미를 구조화해야 한다.

구분	일반 크롤러	온톨로지 구축 플랫폼
목적	웹페이지 수집	의미 구조 구축
결과	HTML, 텍스트, 이미지	엔티티, 관계, 스키마, 클레임
분석 수준	낮음	높음
사용자 작업	수집 URL 관리	지식 검증 및 승인
핵심 가치	데이터 확보	지식화, 추론 가능성, 재사용성

따라서 이 시스템은 단순 크롤러가 아니라 웹 기반 지식 자동 구조화 시스템으로 포지셔닝해야 한다.

4. 전체 시스템 구조 제안

상용화 가능한 온톨로지 구축 플랫폼은 다음과 같은 모듈 구조를 가져야 한다.

[Project Dashboard]
        ↓
[Source Explorer]
        ↓
[Build Pipeline]
        ↓
[Page Analysis Viewer]
        ↓
[Schema Designer]
        ↓
[Entity Extraction Engine]
        ↓
[Claim Builder]
        ↓
[Review & Approval Center]
        ↓
[Ontology Graph View]
        ↓
[Quality Inspector]
        ↓
[Export / API]

각 모듈은 독립적인 기능처럼 보이지만, 실제로는 하나의 흐름을 이룬다.

핵심은 사용자가 “결과 데이터”가 아니라 “구축 과정 전체”를 통제할 수 있게 만드는 것이다.

5. 기능 제안 및 상세 명세

5.1 Project Dashboard

기능명

Ontology Build Dashboard

목적

프로젝트의 전체 구축 상태를 한눈에 보여준다.

현재 시스템은 엔티티 수와 클레임 수 정도만 보여준다. 하지만 사용자는 이것만 보고는 프로젝트가 잘 진행되고 있는지 판단하기 어렵다.

대시보드는 온톨로지 구축의 관제탑 역할을 해야 한다.

주요 기능

전체 수집 URL 수
분석 완료 페이지 수
오류 페이지 수
엔티티 수
클레임 수
승인된 클레임 수
승인 대기 클레임 수
반려된 클레임 수
중복 엔티티 후보 수
모순 클레임 수
출처 없는 클레임 수
평균 신뢰도
온톨로지 품질 점수
최근 빌드 시간
최근 오류 로그

왜 필요한가

사용자는 복잡한 시스템을 사용할 때 가장 먼저 “현재 상태”를 알고 싶어 한다.

대시보드가 없으면 사용자는 다음 질문에 답할 수 없다.

지금 얼마나 수집되었는가?
분석은 끝났는가?
AI가 만든 후보 중 얼마나 승인되었는가?
데이터 품질은 좋은가?
오류는 어디서 발생했는가?

상용 플랫폼은 항상 전체 상태를 보여준다. 대시보드는 기능의 문제가 아니라 제품 신뢰도의 문제이다.

UI 제안

상단에는 핵심 지표 카드를 배치한다.

수집 URL 324개 | 분석 완료 281개 | 엔티티 1,284개 | 클레임 4,912개 | 승인율 63% | 품질 점수 78점

하단에는 다음을 배치한다.

최근 빌드 진행 상태
검토가 필요한 항목
오류 페이지 목록
품질 경고
최근 추가된 엔티티

5.2 Source Explorer

기능명

Source Explorer

목적

사이트를 탐색하고, 어떤 페이지를 온톨로지 구축 대상으로 삼을지 관리한다.

온톨로지 구축은 결국 좋은 소스에서 시작된다. 잘못된 페이지를 분석하면 잘못된 온톨로지가 만들어진다.

주요 기능

1. 시작 URL 등록

사용자가 분석할 사이트의 시작 URL을 입력한다.

예:

https://example.com/perfume

2. 사이트맵 자동 탐색

사이트 내부 링크를 수집하고 페이지 후보를 만든다.

3. 페이지 유형 분류

각 URL을 다음과 같이 분류한다.

상품 목록 페이지
상품 상세 페이지
브랜드 페이지
카테고리 페이지
리뷰 페이지
이벤트 페이지
약관/정책 페이지
로그인/장바구니 페이지
제외 대상 페이지

4. URL 패턴 규칙

사용자가 포함/제외 규칙을 지정할 수 있다.

예:

포함: /product/, /goods/, /item/
제외: /login/, /cart/, /event/, /terms/

5. 페이지 상태 관리

각 페이지는 상태를 가진다.

미수집 / 수집 완료 / 정제 완료 / 분석 완료 / 오류 / 제외

6. 페이지 미리보기

선택한 페이지의 원문 HTML, 정제 텍스트, 스크린샷, 메타데이터를 확인한다.

왜 필요한가

온톨로지 구축에서 가장 흔한 실패 원인은 “잘못된 소스 입력”이다.

예를 들어 향수 상품 온톨로지를 만들고 싶은데 이벤트 페이지, 장바구니 페이지, 리뷰 광고 문구, 푸터 메뉴까지 분석하면 다음과 같은 문제가 생긴다.

의미 없는 엔티티가 생성된다.
value, keyword, accord 같은 불완전한 값이 관계로 저장된다.
브랜드가 아닌 텍스트가 브랜드로 저장된다.
상품이 아닌 문장이 상품처럼 추출된다.

따라서 Source Explorer는 단순히 URL을 보여주는 기능이 아니다. 이것은 온톨로지 품질을 결정하는 첫 번째 필터이다.

설득 포인트

AI 분석이 아무리 좋아도, 입력 데이터가 엉망이면 결과도 엉망이 된다. 온톨로지 시스템에서 Source Explorer는 “AI보다 앞단의 품질 관리 장치”이다.

5.3 Build Pipeline

기능명

Ontology Build Pipeline

목적

수집에서 온톨로지 반영까지의 전체 과정을 단계별로 실행하고 상태를 보여준다.

주요 단계

Step 1. Source Crawl
Step 2. Page Clean
Step 3. Page Classification
Step 4. Entity Extraction
Step 5. Claim Generation
Step 6. Deduplication
Step 7. Validation
Step 8. Human Review
Step 9. Ontology Commit
Step 10. Export

각 단계의 기능

Step 1. Source Crawl

웹사이트에서 HTML, 메타데이터, 링크를 수집한다.

Step 2. Page Clean

본문과 무관한 영역을 제거한다.

메뉴
푸터
광고
추천 상품
장바구니 영역
로그인 영역
반복 UI

Step 3. Page Classification

페이지 유형을 분류한다.

예:

이 페이지는 상품 상세 페이지이다.
이 페이지는 브랜드 소개 페이지이다.
이 페이지는 리뷰 목록 페이지이다.

Step 4. Entity Extraction

핵심 개체를 추출한다.

예:

Product: 포맨트 퍼퓸 코튼 허그
Brand: 포맨트
Price: 44,000원
Note: 머스크

Step 5. Claim Generation

추출된 엔티티를 관계로 연결한다.

예:

포맨트 퍼퓸 코튼 허그 hasBrand 포맨트
포맨트 퍼퓸 코튼 허그 hasPrice 44,000원

Step 6. Deduplication

중복 엔티티를 감지한다.

예:

포맨트 퍼퓸 코튼 허그
FORMENT Cotton Hug Perfume
코튼 허그 퍼퓸

이 세 개가 같은 상품인지 판단한다.

Step 7. Validation

스키마 위반, 모순, 출처 누락을 검사한다.

Step 8. Human Review

AI가 만든 후보를 사용자가 승인 또는 반려한다.

Step 9. Ontology Commit

승인된 항목만 정식 온톨로지에 반영한다.

Step 10. Export

외부 시스템에서 사용할 수 있도록 내보낸다.

왜 필요한가

현재처럼 결과 목록만 있으면 사용자는 시스템이 내부에서 어떤 일을 했는지 알 수 없다. 하지만 파이프라인이 있으면 사용자는 각 단계의 성공 여부와 실패 원인을 확인할 수 있다.

파이프라인은 상용 플랫폼에서 매우 중요하다.

그 이유는 다음과 같다.

복잡한 작업을 단계별로 이해할 수 있다.
오류가 어느 단계에서 발생했는지 알 수 있다.
재실행할 단계를 선택할 수 있다.
처리 속도와 비용을 관리할 수 있다.
사용자에게 “자동 구축 시스템”이라는 인상을 준다.

설득 포인트

온톨로지 구축은 한 번의 AI 호출로 끝나는 작업이 아니다. 수집, 정제, 분류, 추출, 검증, 승인이라는 공정이다. 따라서 이 시스템은 채팅형 AI가 아니라 지식 생산 파이프라인으로 설계되어야 한다.

5.4 Page Analysis Viewer

기능명

Page Analysis Viewer

목적

AI가 페이지를 어떻게 해석했는지 확인하는 화면이다.

주요 기능

원문 페이지 보기
정제된 본문 보기
추출된 엔티티 보기
생성된 클레임 보기
근거 문장 하이라이트
HTML 영역 기반 추출 위치 표시
재분석 버튼
잘못된 추출 삭제
추출 근거 수정
페이지별 분석 로그 확인

예시 화면 구조

왼쪽: 원문/정제 본문
오른쪽: 추출 결과
하단: 생성된 클레임과 근거 문장

예:

본문 문장:
“포맨트 퍼퓸 코튼 허그는 부드러운 머스크 파우더리 노트가 특징입니다.”

추출 결과:
Product: 포맨트 퍼퓸 코튼 허그
Note: 머스크
Claim: 포맨트 퍼퓸 코튼 허그 hasBaseNote 머스크
Confidence: 0.84

왜 필요한가

AI가 만든 결과를 신뢰하려면 근거가 있어야 한다.

사용자는 다음을 알고 싶어 한다.

이 엔티티는 어느 문장에서 나왔는가?
이 관계는 왜 생성되었는가?
이 값이 실제 페이지에 존재하는가?
AI가 추론한 것인가, 규칙으로 뽑은 것인가?

근거가 없으면 사용자는 결과를 신뢰하기 어렵다. 특히 온톨로지는 단순 텍스트 생성이 아니라 지식 구조 구축이기 때문에, 근거 추적이 필수이다.

설득 포인트

AI 자동화의 핵심은 “AI가 다 해준다”가 아니다. 상용 시스템에서 중요한 것은 “AI가 왜 그렇게 판단했는지 검토할 수 있다”이다. Page Analysis Viewer는 AI 결과를 검증 가능한 지식 후보로 바꾸는 장치이다.

5.5 Ontology Schema Designer

기능명

Ontology Schema Designer

목적

온톨로지의 구조를 정의한다.

AI가 아무 관계나 만들게 두면 온톨로지는 금방 오염된다. 어떤 종류의 엔티티를 허용할지, 어떤 관계를 허용할지, 어떤 값 타입을 허용할지 사전에 정의해야 한다.

주요 기능

1. Entity Type 정의

예:

Product
Brand
Category
Note
Ingredient
Price
SubscriptionPlan
Review

2. Predicate 정의

예:

hasBrand
hasPrice
hasTopNote
hasMiddleNote
hasBaseNote
belongsToCategory
hasIngredient
hasSubscriptionPlan

3. 관계 규칙 정의

예:

Product hasBrand Brand
Product hasPrice Price
Product hasBaseNote Note
Product belongsToCategory Category

4. 값 타입 정의

예:

Price.value: number
Price.currency: KRW
Product.name: string
Product.url: url

5. 필수 속성 정의

예:

Product는 name이 필수이다.
Product는 sourceUrl이 필수이다.
Claim은 evidenceText가 필수이다.

6. 금지 규칙 정의

예:

빈 문자열을 Entity로 저장하지 않는다.
value, keyword, accord 같은 일반 필드를 독립 Claim으로 저장하지 않는다.
브랜드가 아닌 사이트명을 Brand로 저장하지 않는다.

단, 이 규칙은 특정 사이트의 예외를 하드코딩하는 방식이면 안 된다. 더 근본적인 원칙은 다음과 같다.

의미적 주체가 아닌 UI 라벨, 필드명, 단순 속성 키, 빈 값, 반복 템플릿 텍스트는 엔티티 또는 클레임의 대상으로 승격하지 않는다.

왜 필요한가

스키마가 없으면 AI는 매번 다른 기준으로 정보를 추출한다.

예를 들어 어떤 페이지에서는 브랜드를 Brand로 저장하고, 다른 페이지에서는 brand라는 단어 자체를 Entity로 저장할 수 있다. 어떤 페이지에서는 가격을 문자열로 저장하고, 다른 페이지에서는 Price 엔티티로 저장할 수 있다.

이렇게 되면 온톨로지는 점점 사용할 수 없는 데이터 덩어리가 된다.

설득 포인트

온톨로지에서 스키마는 건물의 설계도와 같다. 설계도 없이 벽돌을 쌓으면 건물이 아니라 잔해가 된다. AI 추출 결과는 벽돌이고, 스키마는 그 벽돌을 어떤 구조로 쌓을지 결정하는 기준이다.

5.6 Entity Extraction Engine

기능명

Entity Extraction Engine

목적

페이지에서 핵심 개체를 자동으로 추출한다.

주요 기능

상품명 추출
브랜드명 추출
가격 추출
카테고리 추출
설명문 추출
노트 추출
성분 추출
옵션 추출
이미지 URL 추출
단위/통화 정규화
후보 신뢰도 계산
동일 엔티티 병합 후보 생성

추출 방식

Entity Extraction Engine은 한 가지 방식에만 의존하면 안 된다. 다음 방식이 혼합되어야 한다.

1. 구조 기반 추출

HTML 구조, CSS Selector, DOM 위치를 이용한다.

예:

.product-title
.price
.brand-name

장점은 빠르고 정확하다. 단점은 사이트 구조가 바뀌면 깨질 수 있다.

2. 패턴 기반 추출

정규식이나 텍스트 패턴을 이용한다.

예:

\d{1,3}(,\d{3})*원

가격, 날짜, 용량, 할인율 같은 값에 유용하다.

3. AI 기반 추출

문맥을 이해해야 하는 정보에 사용한다.

예:

“부드러운 머스크와 파우더리한 잔향” → Note: 머스크, 파우더리

4. 룰 기반 후처리

AI가 뽑은 결과를 스키마 규칙과 금지 규칙으로 정리한다.

왜 필요한가

온톨로지의 품질은 엔티티 추출 품질에 크게 좌우된다.

엔티티가 잘못 추출되면 이후 생성되는 모든 관계도 잘못된다.

예를 들어 상품명이 잘못 잡히면 다음과 같은 잘못된 관계가 생긴다.

“부드러운 머스크 파우더리 노트...” hasBrand 포맨트

이것은 상품이 아니라 설명문이 주어가 된 잘못된 클레임이다.

설득 포인트

좋은 온톨로지는 좋은 엔티티에서 시작된다. 관계 추출보다 먼저 중요한 것은 “무엇을 독립된 대상으로 볼 것인가”를 정확히 결정하는 일이다.

5.7 Claim Builder

기능명

Claim Builder

목적

추출된 엔티티들을 주어-술어-목적어 구조로 연결한다.

주요 기능

Subject 선택
Predicate 선택
Object 선택
신뢰도 계산
근거 문장 저장
출처 URL 저장
생성 방식 저장
중복 클레임 감지
모순 클레임 감지
후보 상태 관리

Claim 데이터 구조 예시

{
  "subject": "포맨트 퍼퓸 코튼 허그",
  "predicate": "hasBrand",
  "object": "포맨트",
  "sourceUrl": "https://example.com/product/123",
  "evidenceText": "포맨트 퍼퓸 코튼 허그...",
  "confidence": 0.91,
  "createdBy": "rule+ai",
  "status": "candidate"
}

현재 화면에서 개선해야 할 점

현재 화면에는 [object Object]가 보이는 항목이 있다. 이것은 매우 중요한 문제이다.

사용자는 온톨로지 데이터를 직접 읽고 검토해야 한다. 그런데 Object가 사람이 읽을 수 없는 형태로 표시되면 시스템에 대한 신뢰가 떨어진다.

개선 방향은 다음과 같다.

잘못된 표시: [object Object]
올바른 표시: 44,000원
더 좋은 표시: 44,000원 (KRW, Price)

왜 필요한가

온톨로지는 결국 Claim의 집합이다. 하지만 모든 Claim이 동일하게 중요한 것은 아니다.

각 Claim에는 다음 정보가 반드시 따라야 한다.

이 관계가 어디에서 왔는가?
어떤 근거 문장이 있는가?
얼마나 신뢰할 수 있는가?
AI가 만든 것인가, 룰이 만든 것인가?
사람이 승인했는가?

이 정보가 없으면 Claim은 단순한 추측 데이터가 된다.

설득 포인트

Claim Builder는 온톨로지의 생산 공장이다. 여기서 잘못된 관계가 대량으로 생성되면 뒤에서 아무리 수정해도 품질을 회복하기 어렵다. 따라서 Claim은 생성 즉시 근거, 신뢰도, 상태, 생성 방식을 함께 가져야 한다.

5.8 Review & Approval Center

기능명

Review & Approval Center

목적

AI가 만든 후보를 사람이 검토하고 승인한다.

주요 기능

후보 목록
승인 목록
반려 목록
보류 목록
신뢰도 낮은 항목 우선 보기
중복 후보 우선 보기
모순 후보 우선 보기
출처별 필터
Predicate별 필터
Entity Type별 필터
일괄 승인
일괄 반려
변경 이력 기록

상태 정의

candidate: AI 또는 룰이 생성한 후보
approved: 사람이 승인한 정식 항목
rejected: 사람이 반려한 항목
pending: 검토 보류 항목
archived: 더 이상 사용하지 않는 항목

왜 필요한가

AI가 만든 결과를 바로 온톨로지에 반영하면 위험하다.

특히 초기 시스템에서는 다음 문제가 자주 발생한다.

설명문이 상품으로 저장된다.
필드명이 엔티티로 저장된다.
같은 상품이 여러 개로 중복 저장된다.
가격 정보가 다른 페이지에서 충돌한다.
광고 문구가 속성으로 저장된다.

따라서 자동화와 인간 검토 사이의 균형이 필요하다.

설득 포인트

상용 AI 시스템에서 중요한 것은 완전 자동화가 아니라 통제 가능한 자동화이다. 사람이 모든 것을 직접 입력하면 비효율적이고, AI가 모든 것을 확정하면 위험하다. Review & Approval Center는 이 둘 사이의 안전장치이다.

5.9 Ontology Graph View

기능명

Ontology Graph View

목적

온톨로지를 관계 그래프로 시각화한다.

주요 기능

엔티티 노드 표시
관계 엣지 표시
Predicate별 색상 구분
Entity Type별 노드 모양 구분
신뢰도 낮은 관계 강조
출처 없는 관계 표시
특정 엔티티 중심 그래프 보기
고립 노드 탐지
과도하게 연결된 노드 탐지
노드 클릭 시 상세 정보 표시
그래프 필터링

예시

[포맨트 퍼퓸 코튼 허그]
    ├─ hasBrand → [포맨트]
    ├─ hasPrice → [44,000원]
    ├─ hasBaseNote → [머스크]
    └─ belongsToCategory → [퍼퓸]

왜 필요한가

온톨로지는 본질적으로 표가 아니라 그래프이다.

목록 화면만으로는 다음을 파악하기 어렵다.

어떤 엔티티가 중심인가?
어떤 관계가 많이 연결되어 있는가?
고립된 엔티티가 있는가?
잘못 연결된 관계가 있는가?
특정 상품이 어떤 의미망을 갖는가?

그래프 뷰가 있으면 사용자는 온톨로지를 직관적으로 이해할 수 있다.

설득 포인트

그래프 뷰는 단순히 보기 좋은 기능이 아니다. 온톨로지의 본질을 드러내는 기능이다. 목록은 데이터를 보여주지만, 그래프는 지식 구조를 보여준다.

5.10 Ontology Quality Inspector

기능명

Ontology Quality Inspector

목적

구축된 온톨로지의 품질을 자동 진단한다.

주요 기능

중복 엔티티 수
관계 없는 엔티티 수
출처 없는 클레임 수
신뢰도 낮은 클레임 수
스키마 위반 항목 수
모순 관계 수
잘못된 Predicate 사용 수
빈 값 객체 수
타입 불일치 수
품질 점수 산출
수정 권장 목록 제공

품질 점수 예시

전체 품질 점수: 78 / 100

감점 요인:
- 중복 엔티티 후보 31개
- 출처 없는 클레임 12개
- 스키마 위반 8개
- 신뢰도 0.7 미만 클레임 44개
- 고립 엔티티 19개

왜 필요한가

온톨로지는 시간이 지나면서 오염될 수 있다. 특히 자동 추출 시스템은 대량 데이터를 생성하기 때문에, 사람이 모든 항목을 직접 확인하기 어렵다.

따라서 시스템이 먼저 문제를 찾아줘야 한다.

설득 포인트

온톨로지의 가치는 양이 아니라 신뢰도에서 나온다. 클레임이 10만 개 있어도 그중 절반이 틀리면 쓸 수 없다. Quality Inspector는 온톨로지를 “많은 데이터”가 아니라 “믿을 수 있는 지식”으로 만들기 위한 핵심 기능이다.

5.11 Extraction Strategy Manager

기능명

Extraction Strategy Manager

목적

페이지 유형별로 어떤 방식으로 정보를 추출할지 설정한다.

주요 기능

CSS Selector 기반 추출 규칙
정규식 기반 추출 규칙
AI 기반 추출 규칙
룰 기반 Predicate 생성
페이지 유형별 전략 설정
AI 사용 여부 설정
Fast / Balanced / Accurate 모드
실패 시 fallback 전략
추출 로그 확인

추출 전략 예시

상품 상세 페이지:
- 상품명: CSS Selector 우선
- 가격: 정규식 + CSS Selector
- 브랜드: CSS Selector 우선, 실패 시 AI
- 설명문: 본문 정제 후 AI
- 향 노트: AI + 사전 매칭

왜 필요한가

모든 정보를 AI에게 맡기면 비용과 시간이 증가한다. 반대로 모든 것을 규칙으로 처리하면 사이트가 조금만 달라져도 실패한다.

따라서 좋은 시스템은 다음처럼 움직여야 한다.

명확한 구조 데이터 → 규칙 기반
패턴이 뚜렷한 값 → 정규식 기반
문맥 이해가 필요한 정보 → AI 기반
최종 품질 관리 → 스키마 검증

설득 포인트

AI는 만능 추출기가 아니라 문맥 해석 도구이다. 빠르고 명확한 작업은 규칙이 처리하고, 애매하고 의미 해석이 필요한 부분만 AI가 처리해야 한다. 그래야 속도, 비용, 정확도를 모두 잡을 수 있다.

5.12 Export / API Center

기능명

Ontology Export Center

목적

구축된 온톨로지를 외부 시스템에서 활용할 수 있도록 내보낸다.

주요 기능

JSON Export
CSV Export
RDF/Turtle Export
Graph Export
REST API
GraphQL API
승인된 항목만 Export
출처 포함 Export
신뢰도 포함 Export
버전별 Export

왜 필요한가

온톨로지는 구축 자체가 목적이 아니다. 구축된 지식을 다른 시스템에서 활용할 수 있어야 한다.

예를 들어 다음과 같이 활용할 수 있다.

AI 검색 시스템
추천 시스템
상품 비교 시스템
챗봇 지식 베이스
GraphRAG 기반 질의응답
내부 데이터 분석
개인화 서비스

설득 포인트

Export가 없으면 온톨로지는 플랫폼 내부에 갇힌 데이터가 된다. API와 Export는 온톨로지를 실제 비즈니스 가치로 연결하는 출구이다.

6. 사용자 경험 관점에서의 개선 방향

6.1 현재 메뉴 구조의 문제

현재 메뉴는 기능이 나열되어 있지만, 사용자가 온톨로지를 구축하는 흐름을 직관적으로 이해하기 어렵다.

현재 인상은 다음과 같다.

대시보드
프로젝트 생성
참고 소스
크롤 진행
자율 연구
온톨로지 편집
관계도 맵
결과 검토

이 구조도 나쁘지는 않지만, “자동 구축 파이프라인”의 흐름이 강하게 드러나지는 않는다.

6.2 추천 메뉴 구조

Dashboard
Source Explorer
Build Pipeline
Page Analysis
Schema Designer
Entity Manager
Claim Review
Graph View
Quality Inspector
Export / API
Settings

한국어로는 다음과 같이 구성할 수 있다.

대시보드
소스 탐색
구축 파이프라인
페이지 분석
스키마 설계
엔티티 관리
클레임 검토
그래프 보기
품질 진단
내보내기 / API
설정

왜 이렇게 바꿔야 하는가

상용툴은 메뉴만 봐도 사용자가 전체 작업 흐름을 이해할 수 있어야 한다.

현재는 사용자가 “어디서 시작해서 어디로 가야 하는지” 조금 헷갈릴 수 있다. 반면 위 구조는 다음 흐름을 자연스럽게 만든다.

소스 탐색 → 구축 실행 → 페이지 분석 → 스키마 관리 → 후보 검토 → 그래프 확인 → 품질 진단 → Export

즉, 메뉴 자체가 온톨로지 구축 과정의 교육 자료가 된다.

7. 데이터 모델 제안

7.1 Project

{
  "id": "project_001",
  "name": "PerfumeSubscribe_new",
  "domain": "Perfume",
  "status": "active",
  "createdAt": "2026-05-15"
}

7.2 SourcePage

{
  "id": "page_001",
  "projectId": "project_001",
  "url": "https://example.com/product/123",
  "pageType": "product_detail",
  "crawlStatus": "crawled",
  "analysisStatus": "analyzed",
  "cleanText": "...",
  "errorMessage": null
}

7.3 Entity

{
  "id": "entity_001",
  "projectId": "project_001",
  "type": "Product",
  "name": "포맨트 퍼퓸 코튼 허그",
  "normalizedName": "포맨트 퍼퓸 코튼 허그",
  "sourcePageIds": ["page_001"],
  "confidence": 0.92,
  "status": "candidate"
}

7.4 Predicate

{
  "id": "predicate_001",
  "name": "hasBrand",
  "subjectType": "Product",
  "objectType": "Brand",
  "description": "상품이 특정 브랜드에 속함을 나타낸다."
}

7.5 Claim

{
  "id": "claim_001",
  "subjectEntityId": "entity_product_001",
  "predicateId": "predicate_hasBrand",
  "objectEntityId": "entity_brand_001",
  "sourcePageId": "page_001",
  "evidenceText": "포맨트 퍼퓸 코튼 허그...",
  "confidence": 0.91,
  "createdBy": "rule_candidate",
  "status": "candidate"
}

7.6 ValidationIssue

{
  "id": "issue_001",
  "projectId": "project_001",
  "targetType": "claim",
  "targetId": "claim_001",
  "issueType": "schema_violation",
  "severity": "warning",
  "message": "Product hasBrand의 object는 Brand 타입이어야 합니다."
}

8. 시스템이 반드시 지켜야 할 설계 원칙

8.0 기존 오픈소스 기반 엔진 존중 원칙

현재 구축되어 있는 시스템은 처음부터 모든 기능을 직접 만든 것이 아니라, 여러 오픈소스 프로젝트를 검토하고 기능별로 가장 적합한 부분을 선별하여 조합한 구조이다. 즉, 현재의 기본 엔진은 단순한 임시 구현물이 아니라, 이미 어느 정도 검증된 오픈소스 기반 기능들을 활용해 구성된 결과물이다.

따라서 향후 기능 확장이나 구조 개선을 진행할 때, 기본 엔진 영역은 가능한 한 현재 작업되어 있는 내용을 최대한 활용하는 것을 원칙으로 한다.

여기서 말하는 기본 엔진 영역은 다음을 포함한다.

웹 크롤링 및 페이지 수집 엔진
HTML 정제 및 본문 추출 로직
페이지 분석 전처리 구조
엔티티 후보 추출 로직
클레임 후보 생성 로직
룰 기반 후보 판정 구조
기존 데이터 저장 구조
현재 동작 중인 API 및 내부 처리 흐름

중요한 점은, 새로운 기능을 추가한다고 해서 기존 엔진을 쉽게 폐기하거나 대체해서는 안 된다는 것이다. 이미 검토된 오픈소스의 장점을 활용한 부분은 시스템의 기반 자산으로 보아야 한다.

다만 다음 경우에는 수정을 검토할 수 있다.

현재 엔진에 해당 기능이 아예 없는 경우
현재 구조로는 요구 기능을 구현하기 어려운 경우
성능, 정확도, 안정성에 명확한 문제가 확인된 경우
기존 오픈소스 기반 구현이 현재 제품 방향과 충돌하는 경우
유지보수 비용이 지나치게 커지는 경우

이 경우에도 즉시 임의로 변경하는 것이 아니라, 먼저 문제점과 수정 필요성을 정리하고 승인을 받은 뒤 수정해야 한다.

즉, 앞으로의 개발 원칙은 다음과 같다.

기존 엔진은 최대한 재사용한다.
부족한 기능은 그 위에 확장한다.
문제가 있는 부분만 근거를 제시하고 승인 후 수정한다.
검증된 오픈소스 기반 구조를 무리하게 다시 만들지 않는다.

이 원칙은 개발 속도와 안정성을 동시에 확보하기 위해 중요하다. 온톨로지 구축 플랫폼은 크롤링, 정제, 추출, 검증, 저장, 시각화 등 많은 기능이 연결된 복합 시스템이다. 이미 동작하는 기반을 무리하게 갈아엎으면, 새로운 기능을 추가하기보다 기존 기능을 다시 복구하는 데 시간을 낭비할 수 있다.

따라서 본 보고서에서 제안하는 Dashboard, Source Explorer, Build Pipeline, Page Analysis Viewer, Schema Designer, Quality Inspector 등의 기능은 기존 엔진을 부정하고 새로 만들자는 의미가 아니다. 오히려 현재 엔진을 제품화 가능한 플랫폼 구조로 감싸고, 부족한 관리·검증·시각화·승인 기능을 보강하자는 방향이다.

정리하면 다음과 같다.

현재의 오픈소스 기반 엔진은 플랫폼의 기반 자산으로 유지한다. 새로운 개발은 이 엔진을 최대한 활용하는 방향으로 진행하며, 기능 부재나 명확한 문제가 있는 경우에만 승인 절차를 거쳐 수정한다.

8.1 원문 보존 원칙

AI가 분석하기 전의 원문 HTML과 정제 텍스트를 보존해야 한다.

이유는 다음과 같다.

추출 결과를 검증할 수 있다.
추후 알고리즘 개선 시 재분석할 수 있다.
데이터 출처를 추적할 수 있다.

8.2 근거 연결 원칙

모든 Claim은 가능하면 sourceUrl과 evidenceText를 가져야 한다.

근거 없는 Claim은 신뢰할 수 없다.

8.3 후보와 확정 분리 원칙

AI가 만든 결과는 즉시 확정하지 않는다.

AI 생성 → candidate
사용자 승인 → approved
사용자 반려 → rejected

이 구조가 있어야 사람이 통제할 수 있다.

8.4 스키마 우선 원칙

AI가 만든 결과도 스키마를 통과해야 한다.

Product hasBrand Brand = 허용
Product hasBrand Price = 오류
빈 문자열 hasPrice 44,000원 = 오류

8.5 혼합 추출 원칙

모든 것을 AI로 처리하지 않는다.

빠른 추출: CSS Selector
정형 값: Regex
문맥 해석: AI
최종 검증: Schema

8.6 사람이 읽을 수 있는 표시 원칙

화면에는 내부 객체가 그대로 표시되면 안 된다.

나쁜 예: [object Object]
좋은 예: 44,000원
더 좋은 예: 44,000원 · KRW · Price

8.7 품질 점수화 원칙

온톨로지 상태를 사람이 감으로 판단하게 하면 안 된다. 품질 지표를 수치화해야 한다.

9. 개발 우선순위 제안

1단계: 현재 시스템을 상용툴처럼 보이게 만드는 최소 개선

우선순위가 가장 높다.

[object Object] 표시 문제 해결
클레임 상세 패널 추가
sourceUrl/evidenceText 표시
candidate/approved/rejected 상태 추가
클레임 필터 추가
신뢰도 낮은 항목 정렬
대시보드 지표 강화

2단계: 자동 구축 흐름을 보여주는 기능

Build Pipeline 화면 추가
단계별 진행률 표시
페이지별 상태 표시
재실행 버튼 추가
오류 로그 추가

3단계: 소스 탐색과 페이지 분석 강화

Source Explorer 추가
페이지 유형 분류
원문/정제 본문 보기
추출 근거 하이라이트

4단계: 스키마 설계와 검증 강화

Entity Type 관리
Predicate 관리
관계 규칙 관리
스키마 위반 검사

5단계: 그래프와 품질 진단

Graph View
Quality Inspector
중복/모순/고립 노드 탐지

6단계: Export/API

JSON Export
CSV Export
RDF/Turtle Export
REST API

10. 현재 화면을 기준으로 한 구체적 개선 제안

현재 화면에서 가장 먼저 개선해야 할 부분은 다음과 같다.

10.1 클레임 목록 개선

현재는 문장, Predicate, Object가 섞여 보인다. 다음처럼 카드형으로 개선하는 것이 좋다.

[Candidate] 포맨트 퍼퓸 코튼 허그
hasBrand → 포맨트
Confidence 0.83 · Source: forment · Evidence 있음
[승인] [반려] [상세보기]

10.2 클레임 상세 패널 추가

클레임 클릭 시 오른쪽 패널에서 다음을 보여준다.

Subject
Predicate
Object
Entity Type
Source URL
Evidence Text
Created By
Confidence
Validation Result
History

10.3 Source 연결 강화

현재 소스: forment 정도로 보이지만, 실제로는 더 많은 정보가 필요하다.

사이트명
URL
페이지 제목
페이지 유형
수집 시간
분석 시간
원문 보기

10.4 신뢰도 활용 강화

신뢰도는 단순 표시가 아니라 행동을 유도해야 한다.

예:

0.9 이상: 자동 승인 후보
0.7~0.9: 일반 검토
0.7 미만: 우선 검토 필요

10.5 잘못된 값 표시 방지

[object Object] 같은 값은 반드시 렌더링 계층에서 방어해야 한다.

표시 함수는 object 타입을 감지해 사람이 읽을 수 있는 label, name, value를 우선 사용해야 한다.

11. 이 시스템이 지향해야 할 제품 정체성

이 시스템은 단순한 웹 크롤러가 아니다.

또한 단순한 데이터 편집기도 아니다.

이 시스템은 다음과 같이 정의하는 것이 좋다.

웹사이트를 탐색하고, 페이지의 의미를 분석하며, 핵심 개체와 관계를 추출하고, 검증 가능한 온톨로지로 구축하는 AI 기반 지식 구조화 플랫폼.

제품 메시지는 다음과 같이 잡을 수 있다.

웹사이트를 지식 그래프로 바꾸는 AI 온톨로지 구축 플랫폼

또는

크롤링을 넘어, 웹 데이터를 의미 구조로 전환하는 온톨로지 자동 구축 도구

12. 왜 이 방향이 상용화에 유리한가

12.1 단순 크롤러는 차별화가 어렵다

크롤러는 이미 많다. HTML을 가져오고 텍스트를 추출하는 수준만으로는 제품 경쟁력이 약하다.

12.2 단순 AI 추출도 차별화가 어렵다

LLM에게 “이 페이지에서 상품명과 가격을 뽑아줘”라고 하는 기능만으로도 부족하다. 이것은 누구나 만들 수 있다.

12.3 온톨로지 구축 플랫폼은 더 높은 가치가 있다

온톨로지는 단순 데이터보다 활용 범위가 넓다.

검색
추천
질의응답
분석
개인화
지식 그래프
GraphRAG
자동 보고서 생성
도메인 지식 관리

즉, 이 시스템의 진짜 가치는 “데이터 수집”이 아니라 “의미 구조화”에 있다.

12.4 사용자는 자동화와 통제를 모두 원한다

기업 사용자는 AI가 자동으로 해주는 것을 원하지만, 동시에 잘못된 결과를 통제할 수 있기를 원한다.

따라서 다음 구조가 중요하다.

AI 자동 생성 + 사람이 검증 + 시스템이 품질 진단

이 구조를 갖추면 단순 AI 도구보다 신뢰도가 높아진다.

13. 핵심 결론

현재 시스템은 온톨로지 구축의 데이터 구조를 일부 갖추고 있지만, 아직 상용 플랫폼처럼 보이기에는 부족하다.

가장 큰 문제는 기능의 부재라기보다 온톨로지가 구축되는 과정이 사용자에게 보이지 않는 것이다.

상용화 가능한 플랫폼으로 발전하려면 다음 방향으로 가야 한다.

목록 편집 중심에서 구축 파이프라인 중심으로 전환한다.
클레임 결과만 보여주지 말고 추출 근거를 보여준다.
스키마 설계 기능을 추가해 AI 추출의 기준을 만든다.
후보와 승인 데이터를 분리해 검증 가능한 워크플로우를 만든다.
그래프 뷰로 온톨로지의 관계 구조를 보여준다.
품질 진단으로 데이터 신뢰도를 관리한다.
Export/API로 실제 활용 가치를 만든다.

한 문장으로 정리하면 다음과 같다.

이 시스템은 “웹페이지에서 데이터를 긁어오는 도구”가 아니라, “웹사이트를 탐색해 의미 있는 지식 구조로 변환하고, 검증 가능한 온톨로지로 확정하는 플랫폼”이 되어야 한다.

14. 최종 권장 개발 방향

당장 모든 기능을 한 번에 만들 필요는 없다. 그러나 제품 방향은 처음부터 명확해야 한다.

가장 먼저 해야 할 것은 다음이다.

1. Build Pipeline 화면 추가
2. Page Analysis Viewer 추가
3. Claim Review 구조 개선
4. Schema Designer 기본형 추가
5. Quality Inspector 기본형 추가

이 다섯 가지가 들어가면 시스템의 인상이 크게 달라진다.

현재는 “클레임을 편집하는 화면”처럼 보이지만, 위 기능들이 들어가면 “웹사이트를 분석해 온톨로지를 자동 구축하는 플랫폼”으로 보이기 시작한다.

15. 부록: 핵심 기능 요약표

기능	목적	핵심 가치
Dashboard	전체 상태 확인	제품 신뢰도
Source Explorer	분석 대상 관리	입력 품질 관리
Build Pipeline	구축 단계 실행	자동화 체감
Page Analysis Viewer	추출 근거 확인	AI 결과 신뢰성
Schema Designer	구조 규칙 정의	데이터 일관성
Entity Extraction Engine	핵심 개체 추출	온톨로지 기초 품질
Claim Builder	관계 생성	지식 구조화
Review Center	후보 검증	통제 가능한 자동화
Graph View	관계 시각화	온톨로지 체감
Quality Inspector	품질 진단	신뢰 가능한 지식
Strategy Manager	추출 방식 제어	속도/비용/정확도 균형
Export/API	외부 활용	비즈니스 가치

16. 부록: 한 문장 제품 정의 후보

웹사이트를 지식 그래프로 바꾸는 AI 온톨로지 구축 플랫폼
크롤링 데이터를 의미 구조로 전환하는 자동 온톨로지 빌더
웹페이지를 탐색하고, 엔티티와 관계를 추출해 검증 가능한 지식 베이스로 만드는 플랫폼
AI 기반 웹 지식 구조화 및 온톨로지 구축 도구
웹 데이터를 수집하는 것을 넘어, 의미를 구축하는 온톨로지 플랫폼

17. 부록: 개발자에게 전달할 핵심 프롬프트 초안

다음은 개발자 또는 코딩 에이전트에게 전달할 수 있는 작업 지시 요약이다.

현재 온톨로지 구축 툴은 엔티티와 클레임 목록을 보여주는 수준에 머물러 있어 상용 플랫폼처럼 보이지 않는다.
목표는 웹사이트를 탐색해 페이지를 수집하고, 정제하고, 페이지 유형을 분류하고, 엔티티와 클레임을 추출하며, 사용자가 근거를 검토한 뒤 승인된 항목만 온톨로지로 확정하는 AI 기반 온톨로지 구축 플랫폼으로 확장하는 것이다.

우선 다음 기능을 추가한다.

1. Build Pipeline 화면
- Source Crawl, Page Clean, Page Classification, Entity Extraction, Claim Generation, Deduplication, Validation, Human Review, Ontology Commit, Export 단계 표시
- 각 단계별 상태, 진행률, 오류 수, 재실행 버튼 제공

2. Page Analysis Viewer
- 원문 HTML, 정제 텍스트, 추출 엔티티, 생성 클레임, 근거 문장을 한 화면에서 확인
- 클레임별 evidenceText와 sourceUrl 표시

3. Claim Review 개선
- candidate, approved, rejected, pending 상태 도입
- 신뢰도, 출처, 생성 방식, 검증 결과 표시
- [object Object] 표시 문제 제거
- 사람이 읽을 수 있는 label/name/value 우선 표시

4. Schema Designer 기본형
- Entity Type, Predicate, Subject Type, Object Type, 값 타입, 필수 여부 정의
- 스키마 위반 검사에 활용

5. Quality Inspector 기본형
- 중복 엔티티, 출처 없는 클레임, 스키마 위반, 신뢰도 낮은 항목, 고립 엔티티 표시

중요 원칙:
- AI 생성 결과는 즉시 확정하지 말고 candidate로 저장한다.
- 모든 Claim은 sourceUrl, evidenceText, confidence, createdBy, status를 가져야 한다.
- 스키마에 맞지 않는 Claim은 validation issue로 표시한다.
- UI에는 내부 object를 그대로 출력하지 말고 사람이 읽을 수 있는 문자열로 렌더링한다.
- 이 시스템은 단순 크롤러가 아니라 웹사이트를 의미 구조로 변환하는 온톨로지 구축 플랫폼이다.

47 KiB Raw Blame History

온톨로지 구축 플랫폼 연구보고서

웹사이트 탐색 기반 자동 온톨로지 구축 시스템의 필요성, 구조, 기능 명세, 구축 이유

0. 보고서의 목적

1. 온톨로지란 무엇인가

1.1 온톨로지의 기본 의미

1.2 온톨로지의 핵심 구성 요소

2. 현재 시스템의 상태와 문제점

2.1 현재 화면의 장점

2.2 현재 시스템의 핵심 문제

2.3 특히 개선이 필요한 부분

1. 자동 구축 과정이 보이지 않는다

2. 스키마 설계가 보이지 않는다

3. 검증 절차가 약하다

4. 품질 진단이 부족하다

5. 시각적 구조가 부족하다

3. 온톨로지 구축 플랫폼의 목표 모델

3.1 이 시스템이 최종적으로 해야 하는 일

3.2 이 시스템이 단순 크롤러와 다른 점

4. 전체 시스템 구조 제안

5. 기능 제안 및 상세 명세

5.1 Project Dashboard

기능명

목적

주요 기능

왜 필요한가

UI 제안

5.2 Source Explorer

기능명

목적

주요 기능

1. 시작 URL 등록

2. 사이트맵 자동 탐색

3. 페이지 유형 분류

4. URL 패턴 규칙

5. 페이지 상태 관리

6. 페이지 미리보기

왜 필요한가

설득 포인트

5.3 Build Pipeline

기능명

목적

주요 단계

각 단계의 기능

Step 1. Source Crawl

Step 2. Page Clean

Step 3. Page Classification

Step 4. Entity Extraction

Step 5. Claim Generation

Step 6. Deduplication

Step 7. Validation

Step 8. Human Review

Step 9. Ontology Commit

Step 10. Export

왜 필요한가

설득 포인트

5.4 Page Analysis Viewer

기능명

목적

주요 기능

예시 화면 구조

왜 필요한가

설득 포인트

5.5 Ontology Schema Designer

기능명

목적

주요 기능

1. Entity Type 정의

2. Predicate 정의

3. 관계 규칙 정의

4. 값 타입 정의

5. 필수 속성 정의

6. 금지 규칙 정의

왜 필요한가

설득 포인트

5.6 Entity Extraction Engine

기능명

목적

주요 기능

추출 방식

47 KiB

Raw Blame History