> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sifi.life/llms.txt
> Use this file to discover all available pages before exploring further.

# 테이블 및 지식 저장소 구성

> 이 문서는 **[Genie Space](/blog/guides/genie-space/overview)** 섹션의 일부입니다.

***

## 개요

Genie Space의 응답 품질은 데이터 구성과 메타데이터의 풍부함에 **직접적으로 비례** 합니다. 이 가이드에서는 테이블 관리, 메타데이터 커스터마이징, 프롬프트 매칭, Knowledge Store의 구조를 상세히 설명합니다.

### 왜 데이터 구성이 가장 중요한가

Genie가 SQL을 생성하는 과정을 이해하면 데이터 구성의 중요성이 명확해집니다. 사용자가 "지난 달 매출 상위 5개 지역은?"이라고 질문하면, Genie는 내부적으로 다음 단계를 거칩니다:

1. **테이블 선택**: Knowledge Store에서 "매출"과 "지역"이 포함된 테이블을 찾음
2. **컬럼 매핑**: "매출" → `revenue` 컬럼, "지역" → `region` 컬럼으로 매핑
3. **비즈니스 로직 적용**: SQL Expression에 정의된 "매출" 계산식 참조
4. **SQL 생성**: 위 정보를 조합하여 `SELECT region, SUM(revenue) ... GROUP BY region ORDER BY ... LIMIT 5` 생성

이 과정에서 **컬럼 설명이 없으면** Genie는 컬럼명만으로 추론해야 하고, **동의어가 없으면** 한국어 "매출"과 영어 `revenue`를 연결하지 못하며, **SQL Expression이 없으면**"순매출"인지 "총매출"인지 판단할 수 없습니다.

> **주의**
> **핵심 원칙**: Genie의 정확도 문제 중 80% 이상은 LLM의 한계가 아니라 **Knowledge Store의 부족** 에서 비롯됩니다. 인스트럭션을 아무리 잘 써도, 테이블 메타데이터가 빈약하면 정확도가 올라가지 않습니다.

***

## 지식 저장소(Knowledge Store)란?

지식 저장소는 Genie가 정확한 응답을 생성하기 위해 참조하는 **모든 메타데이터와 비즈니스 로직의 총체** 입니다. 아래 요소들이 Knowledge Store를 구성합니다:

| 구성 요소               | 위치                             | 설명                         | 제한        |
| ------------------- | ------------------------------ | -------------------------- | --------- |
| **테이블/뷰**           | Configure > Data               | Genie가 쿼리할 데이터 소스          | 최대 30개    |
| **컬럼 설명**           | Configure > Data > 테이블 선택      | 각 컬럼의 비즈니스 의미              | 테이블당 무제한  |
| **동의어(Synonyms)**   | Configure > Data > 컬럼 선택       | 컬럼의 별칭                     | 컬럼당 무제한   |
| **텍스트 인스트럭션**       | Configure > Instructions       | 자연어 비즈니스 규칙                | 최대 200개   |
| **예제 쿼리**           | Configure > Instructions       | 질문-SQL 쌍                   | 최대 200개   |
| **SQL Expressions** | Configure > Data > Expressions | Measure, Filter, Dimension | 최대 200개   |
| **조인 관계**           | Configure > Data > Joins       | 테이블 간 연결 관계                | 무제한       |
| **프롬프트 매칭**         | Configure > Data > 컬럼 선택       | 입력값-데이터값 자동 매핑             | 컬럼당 1개 설정 |

> **참고**
> Genie는 사용자 질문을 받으면 이 Knowledge Store를 종합적으로 참조하여 최적의 SQL을 생성합니다. Knowledge Store가 풍부할수록 응답 정확도가 높아집니다. **모든 구성 요소가 LLM 프롬프트의 일부로 사용된다** 는 점을 기억하세요. 컬럼 설명에 "이 컬럼은 별로 중요하지 않다"고 쓰면 Genie가 그것을 그대로 참조합니다.

### Knowledge Store 구성 우선순위

처음부터 모든 요소를 완벽하게 채울 필요는 없습니다. 정확도 향상에 대한 기여도 순서로 접근하세요:

| 우선순위    | 구성 요소                    | 정확도 기여도 | 이유                       |
| ------- | ------------------------ | ------- | ------------------------ |
| **1순위** | 컬럼 설명 + 동의어              | 매우 높음   | Genie가 올바른 컬럼을 선택하는 데 핵심 |
| **2순위** | SQL Expression (Measure) | 높음      | 비즈니스 지표의 정확한 계산식 보장      |
| **3순위** | 예제 SQL 쿼리                | 높음      | 복잡한 질문에 대한 "정답 패턴" 제공    |
| **4순위** | 프롬프트 매칭                  | 중간      | 한국어-영어 데이터 값 매핑          |
| **5순위** | 조인 관계                    | 중간      | 다중 테이블 사용 시 필수           |
| **6순위** | 텍스트 인스트럭션                | 보조적     | 글로벌 컨텍스트 제공              |

***

## 테이블 추가/제거

### 테이블 추가 절차

1. **Configure > Data** 메뉴로 이동합니다.
2. **Add** 버튼을 클릭합니다.
3. Unity Catalog 브라우저에서 Catalog > Schema > Table을 탐색합니다.
   * *화면 설명: 3단계 트리 구조의 카탈로그 브라우저가 나타나며, 검색 기능도 제공됩니다.*
4. 추가할 테이블/뷰를 선택하고 **Add** 를 클릭합니다.
5. Overview 탭에서 컬럼 정보를 확인합니다.
6. Sample data 탭에서 실제 데이터를 미리 확인합니다.

### 테이블 제거 절차

1. **Configure > Data** 에서 제거할 테이블을 찾습니다.
2. 테이블 우측의 **휴지통 아이콘** 을 클릭합니다.
3. 확인 다이얼로그에서 **Remove** 를 클릭합니다.

> **주의**
> 테이블을 제거하면 해당 테이블에 설정한 **컬럼 설명, 동의어, 프롬프트 매칭, SQL Expression이 모두 삭제** 됩니다. 임시로 비활성화하려면 제거 대신 컬럼을 숨기는 것을 고려하세요.

### 테이블 선택 가이드

| 권장 사항        | 비권장 사항         | 이유                        |
| ------------ | -------------- | ------------------------- |
| 5개 이하로 시작    | 10개 이상 한꺼번에 추가 | 테이블이 많으면 잘못된 테이블 선택 확률 증가 |
| 뷰(View) 활용   | 원본 테이블 직접 사용   | 뷰로 필요한 컬럼만 노출하면 정확도 향상    |
| 비정규화된 넓은 테이블 | 과도하게 정규화된 테이블  | 조인 수가 적을수록 Genie 정확도 향상   |
| 명확한 컬럼명의 테이블 | 약어/코드로 된 컬럼명   | 의미가 명확할수록 정확한 SQL 생성      |

***

## 컬럼 숨기기(Hide Columns)

불필요한 컬럼을 숨기면 Genie가 혼란을 줄이고 더 정확한 SQL을 생성합니다.

### 왜 컬럼 숨기기가 중요한가

Genie의 LLM은 모든 노출된 컬럼을 "사용 가능한 후보"로 간주합니다. 테이블에 50개 컬럼이 있고 그 중 10개만 비즈니스 질문에 관련이 있다면, Genie는 나머지 40개 중에서 잘못된 컬럼을 선택할 확률이 높아집니다. **신호 대 잡음 비율(Signal-to-Noise Ratio)** 을 높이는 것이 핵심입니다.

### 숨겨야 할 컬럼 유형

| 컬럼 유형               | 예시                                           | 숨기는 이유            |
| ------------------- | -------------------------------------------- | ----------------- |
| **내부 시스템 ID**       | `_id`, `_etl_timestamp`, `_row_hash`         | 비즈니스 의미가 없음       |
| **기술적 메타데이터**       | `created_by`, `modified_at`, `partition_key` | 사용자 질문과 무관        |
| **더 이상 사용하지 않는 컬럼** | `old_status`, `legacy_code`                  | 혼란 유발             |
| **민감 정보**           | `ssn`, `credit_card`, `password_hash`        | 보안 (단, UC 권한이 우선) |
| **중복 컬럼**           | `full_name`과 `first_name + last_name`        | 어떤 컬럼을 사용할지 혼동    |

### 숨기기 절차

1. **Configure > Data** 에서 테이블을 선택합니다.
2. 숨길 컬럼의 **Visibility** 토글을 끕니다.
   * *화면 설명: 각 컬럼 행 우측에 눈 모양 아이콘이 있으며, 클릭하면 회색으로 변하면서 숨겨집니다.*
3. 숨긴 컬럼은 Genie가 SQL 생성 시 참조하지 않습니다.

> **팁**
> 테이블의 컬럼이 20개 이상이면, 사용자 질문에 관련된 핵심 컬럼 10-15개만 남기고 나머지는 숨기세요. 이것만으로도 정확도가 크게 향상됩니다.

***

## 메타데이터 커스터마이징

### 컬럼 설명 (Description) — Genie 정확도의 핵심

Space 전용 테이블/컬럼 설명을 추가할 수 있습니다. Unity Catalog의 원본 설명을 **덮어쓰지 않고**, Space에만 적용되는 별도의 설명을 관리합니다.

#### 왜 컬럼 설명이 가장 중요한가

Genie는 사용자 질문의 키워드를 컬럼과 매칭할 때, **컬럼명** 과 **컬럼 설명** 을 LLM 프롬프트의 일부로 사용합니다. 컬럼명이 `ord_sts`이고 설명이 없다면, Genie는 이것이 "주문 상태"인지 "주문 통계"인지 알 수 없습니다. 반면 설명에 "주문 상태. 가능한 값: 'pending', 'shipped', 'delivered', 'cancelled'"라고 적으면, Genie는 다음을 할 수 있습니다:

* "배송 완료된 주문" → `WHERE ord_sts = 'delivered'` 정확 매핑
* "취소된 주문 제외" → `WHERE ord_sts != 'cancelled'` 정확 매핑
* "주문 상태별 분포" → `GROUP BY ord_sts` 정확 선택

> **주의**
> **흔한 실수**: AI 자동 생성 설명을 검증 없이 사용하지 마세요. AI가 "This column stores the order status"라고 생성한 설명은 Genie에게 실질적인 도움이 되지 않습니다. **가능한 값, 단위, 비즈니스 정의** 가 포함되어야 합니다.

**좋은 컬럼 설명 작성 원칙:**

| 원칙             | 좋은 예시                                                                 | 나쁜 예시     |
| -------------- | --------------------------------------------------------------------- | --------- |
| **가능한 값 나열**   | `"주문 상태. 가능한 값: 'pending', 'shipped', 'delivered', 'cancelled'"`      | `"주문 상태"` |
| **비즈니스 의미 설명** | `"순매출. 총매출에서 할인과 반품을 제외한 금액 (단위: 원)"`                                 | `"매출"`    |
| **계산 방법 명시**   | `"고객 등급. 연간 구매액 기준 — Gold: 1000만원 이상, Silver: 500만원 이상, Bronze: 그 외"` | `"등급"`    |
| **데이터 형식 명시**  | `"주문일. YYYY-MM-DD 형식. 한국 시간(KST) 기준"`                                 | `"날짜"`    |

### 동의어(Synonyms) — 사용자 언어와 데이터의 다리

컬럼에 동의어를 추가하면 사용자가 다양한 표현으로 질문해도 올바른 컬럼을 찾습니다.

#### 왜 동의어가 필요한가

한국 기업 환경에서는 같은 개념을 다양한 방식으로 부릅니다. 영업팀은 "매출"이라고 하고, 재무팀은 "수익"이라고 하며, 경영진은 "세일즈"라고 합니다. 데이터베이스 컬럼명은 `revenue`입니다. 동의어를 등록하지 않으면 "수익"이나 "세일즈"로 질문했을 때 올바른 컬럼을 찾지 못합니다.

| 컬럼명                | 추가할 동의어                 |
| ------------------ | ----------------------- |
| `revenue`          | 매출, 수익, 매출액, sales, 세일즈 |
| `customer_count`   | 고객수, 고객 수, 회원수, 사용자수    |
| `order_date`       | 주문일, 주문 날짜, 구매일, 거래일    |
| `region`           | 지역, 권역, 리전, area, 영업구역  |
| `product_category` | 제품군, 상품 카테고리, 카테고리, 품목  |

> **팁**
> **동의어 수집 팁**: 실제 비즈니스 사용자 5명에게 같은 데이터를 어떻게 부르는지 물어보세요. 놀랍게도 같은 팀 내에서도 서로 다른 용어를 사용합니다. 이 다양한 표현을 모두 동의어로 등록하는 것이 정확도 향상의 지름길입니다.

**설정 방법:**

1. Configure > Data에서 테이블을 선택합니다.
2. 컬럼을 클릭하여 상세 패널을 엽니다.
3. **Synonyms** 필드에 쉼표로 구분하여 입력합니다.

***

## 프롬프트 매칭(Prompt Matching) 상세

프롬프트 매칭은 사용자의 입력 언어를 실제 데이터 값과 자동으로 매칭하는 기능입니다.

### 왜 필요한가?

| 사용자 입력 | 실제 데이터 값     | 프롬프트 매칭 없이    | 프롬프트 매칭 있으면          |
| ------ | ------------ | ------------- | -------------------- |
| "서울"   | "Seoul"      | 매칭 실패 → 결과 없음 | "서울" → "Seoul" 자동 변환 |
| "에이콘"  | "Acorn Inc." | 매칭 실패         | 자동 매칭                |
| "2분기"  | "Q2"         | 매칭 실패         | 자동 매칭                |

### 설정 방법

1. **Configure > Data** 에서 테이블을 선택합니다.
2. 프롬프트 매칭이 필요한 컬럼을 클릭합니다.
3. **Prompt Matching** 섹션에서 **Enable** 을 클릭합니다.
   * *화면 설명: 프롬프트 매칭을 활성화하면 해당 컬럼의 고유 값 목록이 로드되며, Genie가 사용자 입력과 데이터 값을 자동 매핑합니다.*

### 자동 값 매핑 vs 수동 매핑

| 방식            | 설명                        | 사용 사례                 |
| ------------- | ------------------------- | --------------------- |
| **자동 매핑**     | 컬럼의 고유 값을 Genie가 자동으로 인덱싱 | 값이 명확한 컬럼 (국가, 제품명 등) |
| **수동 정규식 패턴** | 사용자가 정규식으로 매칭 규칙 정의       | 약어, 다국어, 복합 패턴        |

### 정규식 패턴 예시

| 패턴                | 설명            | 매칭 결과                   |
| ----------------- | ------------- | ----------------------- |
| `서울\|Seoul\|SEL`  | 서울의 다양한 표현 매칭 | → "Seoul"               |
| `Q[1-4]\|[1-4]분기` | 분기 표현 매칭      | → "Q1", "Q2" 등          |
| `삼성.*\|Samsung.*` | 삼성 관련 회사 매칭   | → "Samsung Electronics" |

> **주의**
> 프롬프트 매칭은 **카디널리티(고유 값 수)가 낮은 컬럼** 에 적합합니다. 고유 값이 수만 개 이상인 컬럼(예: 주문번호)에는 사용하지 마세요. 인덱싱 시간이 길어지고 효과도 미미합니다.

***

## 조인 관계 정의

테이블 간 연결 관계를 명시적으로 정의합니다. Genie는 이 정보를 참고하여 정확한 JOIN 쿼리를 생성합니다.

### 왜 조인 관계를 명시적으로 정의해야 하는가

Genie는 조인 관계가 정의되지 않으면 **컬럼명의 유사성** 을 기반으로 추론합니다. `orders.customer_id`와 `customers.id`처럼 명확한 경우에는 잘 작동하지만, 다음과 같은 경우 잘못된 조인을 생성할 수 있습니다:

* 여러 테이블에 `id`라는 이름의 컬럼이 있을 때
* 조인 키가 `account_id`와 `acct_id`처럼 약간 다를 때
* 복합 키(2개 이상 컬럼)로 조인해야 할 때
* 조건부 조인(날짜 범위 등)이 필요할 때

이런 경우 명시적 조인 관계가 없으면 Genie가 **잘못된 테이블을 CROSS JOIN** 하거나, **중복 데이터를 생성하는 조인** 을 만들 수 있습니다.

### 설정 방법

**간단한 경우**— 컬럼 동등 구문 사용:

```
accounts.id = opportunity.accountid
```

**복합 키 조인:**

```sql theme={null}
orders.customer_id = customers.id AND orders.region = customers.region
```

**조건부 조인:**

```sql theme={null}
events.user_id = users.id AND events.event_date >= users.created_date
```

> **팁**
> 조인 관계를 정의하지 않으면 Genie가 컬럼명을 기반으로 **추론** 합니다. 대부분 정확하지만, 컬럼명이 모호한 경우(예: 여러 테이블에 `id` 컬럼이 있는 경우) 명시적 정의가 필요합니다.

***

## SQL 표현식 (SQL Expressions)

비즈니스 로직을 재사용 가능한 **Measure, Filter, Dimension** 으로 정의합니다. 텍스트 인스트럭션보다 SQL로 명확하게 정의하는 것이 더 정확한 결과를 얻을 수 있습니다.

### 왜 SQL Expression이 텍스트 인스트럭션보다 우선인가

텍스트 인스트럭션에 "순매출은 총매출에서 할인과 반품을 빼세요"라고 쓰면, LLM이 이를 해석하여 SQL을 만들어야 합니다. 해석 과정에서 `SUM(amount) - SUM(discount) - SUM(refund)`가 될 수도 있고, `SUM(amount - discount - refund)`가 될 수도 있습니다. 결과가 다릅니다.

SQL Expression으로 `SUM(amount) - SUM(discount) - SUM(refund) AS net_revenue`라고 정의하면, Genie는 해석할 필요 없이 **그대로 SQL에 삽입** 합니다. 따라서:

* **정확도**: 비즈니스 로직이 100% 보장됨
* **일관성**: 누가 어떻게 질문해도 같은 계산식 적용
* **검증 가능**: SQL이 명시적이므로 검증이 쉬움

| 유형            | 용도         | 예시                                                               |
| ------------- | ---------- | ---------------------------------------------------------------- |
| **Measure**   | 지표/메트릭 정의  | `SUM(order_total) AS total_revenue`                              |
| **Filter**    | 자주 사용하는 필터 | `status = 'active' AND created_at > '2025-01-01'`                |
| **Dimension** | 분석 차원 정의   | `CASE WHEN age < 30 THEN 'Young' ELSE 'Senior' END AS age_group` |

### SQL Expression 작성 예시

| 비즈니스 요구사항     | 유형        | SQL Expression                                                                                                                                                                  |
| ------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| "순매출" 지표      | Measure   | `SUM(amount) - SUM(discount) - SUM(refund) AS net_revenue`                                                                                                                      |
| "활성 고객" 필터    | Filter    | `last_purchase_date >= DATE_ADD(CURRENT_DATE(), -90)`                                                                                                                           |
| "매출 구간" 차원    | Dimension | `CASE WHEN revenue < 1000000 THEN 'Small' WHEN revenue < 10000000 THEN 'Medium' ELSE 'Large' END AS revenue_tier`                                                               |
| "전년 동기 대비" 지표 | Measure   | `SUM(CASE WHEN YEAR(order_date) = YEAR(CURRENT_DATE()) THEN amount ELSE 0 END) - SUM(CASE WHEN YEAR(order_date) = YEAR(CURRENT_DATE()) - 1 THEN amount ELSE 0 END) AS yoy_diff` |

> **참고**
> SQL 표현식은 최대 **200개** 까지 추가할 수 있습니다. 텍스트 인스트럭션으로 "순매출은 총매출에서 할인과 반품을 빼세요"라고 쓰는 것보다, SQL Expression으로 정확한 공식을 정의하는 것이 훨씬 안정적입니다.

***

## 실전 시나리오: 전자상거래 Space 구축 예시

한 전자상거래 기업이 Genie Space를 구축하는 과정을 예시로 설명합니다.

**1단계 — 테이블 구성**: `orders`, `customers`, `products` 3개 테이블을 추가하고, 필요 없는 `_etl_timestamp`, `_partition_key` 같은 기술 컬럼을 숨김 처리합니다.

**2단계 — 컬럼 설명**: 주요 컬럼에 비즈니스 설명을 추가합니다.

* `orders.status` → "주문 상태. 가능한 값: 'pending'(결제 대기), 'paid'(결제 완료), 'shipped'(배송중), 'delivered'(배송 완료), 'cancelled'(취소), 'refunded'(환불)"
* `orders.amount` → "주문 금액 (부가세 포함, 단위: 원). 할인 적용 전 금액"
* `customers.tier` → "고객 등급. Gold: 연간 구매 1,000만원 이상, Silver: 500만원 이상, Bronze: 그 외"

**3단계 — 동의어**: `revenue` → 매출, 수익, 세일즈 / `customer_count` → 고객수, 회원수

**4단계 — SQL Expression**:

* Measure: `SUM(amount) - SUM(discount) - SUM(refund_amount) AS 순매출`
* Filter: `status NOT IN ('cancelled', 'refunded')` (유효 주문)
* Dimension: `CASE WHEN amount >= 100000 THEN '고가' WHEN amount >= 50000 THEN '중가' ELSE '저가' END AS 주문_구간`

**5단계 — 프롬프트 매칭**: `region` 컬럼에 "서울" → "Seoul", "부산" → "Busan" 매핑 활성화

이 5단계를 완료하면 벤치마크 정확도가 보통 50% → 80% 이상으로 향상됩니다.

***

## Metric View 활용

Metric View는 지표(Metric), 차원(Dimension), 집계(Aggregation)를 **Unity Catalog 수준에서 정의** 하는 기능입니다. SQL Expression이 Space 내부에서만 적용되는 반면, Metric View는 카탈로그에 등록되므로 여러 Space에서 재사용할 수 있습니다.

| 비교 항목      | SQL Expression    | Metric View            |
| ---------- | ----------------- | ---------------------- |
| **범위**     | 해당 Space에만 적용     | Unity Catalog 전체에서 재사용 |
| **관리**     | Space 관리자가 관리     | 데이터 엔지니어/분석가가 관리       |
| **일관성**    | Space마다 다르게 정의 가능 | 조직 전체에서 동일한 정의 보장      |
| **적합한 경우** | Space 특화 로직       | 조직 표준 KPI (매출, 고객수 등)  |

> **팁**
> 조직의 **핵심 KPI(매출, 이익, 고객수 등)** 는 Metric View로 정의하고, Space별 특수한 지표만 SQL Expression으로 추가하는 것이 이상적입니다. 이렇게 하면 "A Space에서는 매출이 이렇게 계산되고, B Space에서는 다르게 계산된다"는 불일치를 방지할 수 있습니다.

***

## 흔한 데이터 구성 실수와 디버깅

| 증상                    | 원인                         | 디버깅 방법                         |
| --------------------- | -------------------------- | ------------------------------ |
| "매출"을 질문하면 엉뚱한 컬럼을 선택 | 여러 테이블에 비슷한 이름의 컬럼 존재      | 불필요한 테이블/컬럼 제거, 동의어로 정확한 컬럼 지정 |
| 조인 결과가 뻥튀기(데이터 중복)    | 1:N 관계에서 잘못된 조인 키          | 명시적 조인 관계 정의, 뷰로 사전 조인         |
| "서울 매출"을 질문하면 결과 없음   | 데이터에는 "Seoul"로 저장          | 프롬프트 매칭 활성화                    |
| 필터 조건이 누락되어 삭제 데이터 포함 | Genie가 `is_deleted` 조건을 모름 | Filter 타입 SQL Expression 추가    |
| 날짜 필터가 잘못 적용          | "지난 달"의 SQL 해석이 부정확        | 인스트럭션에서 날짜 표현의 SQL 함수 정의       |

***

## 데이터 구성 베스트 프랙티스

| 항목                 | 권장 사항                                   |
| ------------------ | --------------------------------------- |
| **테이블 수**          | 5개 이하로 시작, 필요 시 점진적 확장                  |
| **컬럼 설명**          | 가능한 값, 단위, 계산 방법 포함. **모든** 주요 컬럼에 작성   |
| **동의어**            | 한국어/영어 모두 등록. 부서별로 다른 용어도 포함            |
| **숨김 컬럼**          | 비즈니스 의미 없는 컬럼은 모두 숨김. 20개+ 컬럼이면 핵심만 남기기 |
| **프롬프트 매칭**        | 카디널리티가 낮은 카테고리 컬럼에 적용                   |
| **조인 관계**          | 모호한 경우 반드시 명시적 정의                       |
| **SQL Expression** | 핵심 비즈니스 지표는 Measure로 정의                 |
| **뷰 활용**           | 복잡한 조인/변환은 뷰로 사전 처리                     |
| **Metric View**    | 조직 표준 KPI는 Metric View로 카탈로그 수준에서 정의    |