AI 프로젝트를 위한 실전 데이터모델링 패턴 7가지

by 전우석

전통적인 업무시스템 모델링은 보통 아래 흐름으로 정리됩니다.

• 업무 요구사항 → 개념/논리 모델 → 물리 모델 → 트랜잭션 중심 설계

AI 프로젝트에서는 여기에 추가 요구가 붙습니다.

• 학습 데이터(Training Data) 를 어떻게 구성·재사용할 것인가?
• 피처(Feature) 를 어떻게 정의하고, 버전별로 관리할 것인가?
• 실험(Experiment), 모델(Model), 메트릭(Metric) 은 어떻게 남길 것인가?
• 개인정보/규제 이슈가 있는 데이터를 어떻게 안전하게 학습에 쓰게 할 것인가?

즉, AI 프로젝트용 데이터모델링은

업무 + 분석 + AI/ML + 거버넌스 를 한 번에 품어야 하는 설계

입니다. 아래 7가지 패턴은 이런 요구를 “구조”로 잡기 위한 실전 패턴들입니다.

---

1. 왜 AI 프로젝트에는 “다른 스타일”의 모델링이 필요할까?

AI 모델은 “현재 상태”만으로 학습하지 않습니다.
대부분은 시간에 따른 변화(이벤트), 집계/윈도우 피처, 학습 데이터셋의 재현성, 모델 운영(서빙) 관점의 정합성, 그리고 규제 준수까지 요구합니다.

전통 OLTP 모델이 잘 다루는 영역:

• 트랜잭션 무결성
• 정규화 기반의 안정적 CRUD
• 업무 도메인 중심 설계

AI 모델링에서 추가로 필요한 영역:

• 재현 가능한 학습 데이터(데이터셋 버전)
• 피처 정의의 표준화/재사용(Feature Store)
• 서빙 환경과 학습 환경의 일치(Training–Serving Skew 방지)
• 실험/모델 계보(lineage) 관리(Model Registry)
• 민감 데이터 분리/비식별화(Privacy by design)

이 글의 패턴들은 “정답 스키마”가 아니라,
AI 운영 문제(재현성/정합성/거버넌스/확장성) 를 구조적으로 줄이기 위한 설계 프레임입니다.

---

2. 패턴 1: 피처 스토어(Feature Store) 모델링 패턴

2.1 언제 쓰는 패턴인가?

• 여러 AI 모델에서 공통 피처 재사용이 많을 때
• “이 피처 지난 프로젝트에서도 쓴 것 같은데…”가 반복될 때
• 실시간 점수/추천을 위해 온라인 피처 저장소가 필요할 때

2.2 핵심 엔터티 예시

• FEATURE_GROUP (피처 묶음: 고객일별행동, 상품_속성 등)
• FEATURE_DEFINITION (피처 정의: 이름, 타입, 로직, 윈도우 등)
• FEATURE_STORE (저장소: online/offline, 물리 위치)
• FEATURE_VALUE (실제 피처 값: 엔티티 키 + 값 + 기준시점)

예시 속성(정의 테이블):

• FEATURE_DEFINITION
• FEATURE_ID (PK)
• FEATURE_NAME (예: 고객7일방문횟수)
• DATA_TYPE, AGG_FUNC(SUM/COUNT/AVG…), WINDOW(7d/30d…)
• SOURCE_TABLE, SOURCE_COLUMN
• DESCRIPTION, OWNER_TEAM, QUALITY_RULES

2.3 모델링 포인트

• Definition(정의) 와 Value(값) 를 분리
• “어디서 만들어졌고, 어떤 로직인지”를 정의에 남겨 피처 재사용을 가능하게 함
• 그룹 단위로 도메인/주제 분리(관리 단위 확보)

2.4 체크리스트

• 피처 이름/정의/집계 로직이 메타데이터로 남아 있는가?
• 같은 피처를 여러 테이블에서 중복 계산하고 있지 않은가?
• 온라인(실시간)과 오프라인(배치) 피처의 정의가 정렬되어 있는가?

---

3. 패턴 2: 엔티티–이벤트 이원 모델(Entity–Event Dual Model)

3.1 언제 쓰는 패턴인가?

• 사용자 행동 로그(클릭/조회/구매/장바구니 등) 기반 피처가 많을 때
• 시계열(타임라인)을 기준으로 분석·예측을 하고 싶을 때

3.2 핵심 엔터티 구조

• CUSTOMER (정적/준정적 속성: 나이, 성별, 가입일 등)
• PRODUCT (상품 속성)
• EVENT_LOG (고객 행동 이벤트 로그)

EVENT_LOG 예시 컬럼:

• EVENT_ID (PK)
• CUSTOMER_ID (FK)
• PRODUCT_ID (FK, 필요시)
• EVENT_TYPE (VIEW, CLICK, CART, PURCHASE…)
• EVENT_TIME
• CHANNEL (WEB, APP, OFFLINE 등)
• CONTEXT_JSON (확장 필드)

3.3 모델링 포인트

• 엔티티(상태/현재값) 와 이벤트(행동/변화) 를 분리
• 이벤트 테이블은 Append Only(추가 전용) 로 두고,
• Feature Store나 집계 테이블에서 필요 시점에 집계해서 사용
• 이벤트는 “원본 로그”이므로 가급적 수정/삭제를 최소화(감사·재현성에도 유리)

3.4 체크리스트

• “상태”와 “행동”을 같은 테이블에 섞어두지 않았는가?
• 이벤트 로그에 최소 공통 컬럼(누가/언제/무엇/어디서)이 정의되어 있는가?
• 파티셔닝(날짜/시간)과 인덱스를 충분히 고려했는가?

---

4. 패턴 3: 마스터데이터 & 골든 레코드(MDM & Golden Record)

4.1 언제 쓰는 패턴인가?

• 고객/상품/계약 정보가 여러 시스템에 흩어져 있을 때
• “고객 1명을 여러 ID로 알고 있는” 상황이 잦을 때
• AI 모델 입력값으로 신뢰 가능한 대표 정보가 필요할 때

4.2 핵심 구조

• CUSTOMER_MASTER (골든 레코드: 통합 고객 기준 정보)
• CUSTOMER_SOURCE_MAP (소스 시스템 고객ID 매핑)
• CUSTOMER_ATTR_HISTORY (핵심 속성 이력: 등급, 직군, 상태 등)

4.3 모델링 포인트

• CUSTOMER_MASTER의 키는 전사 공통 ID로 관리
• 각 소스 시스템의 키는 CUSTOMER_SOURCE_MAP에 매핑
• AI 모델에서는 항상 골든 레코드 기준으로 피처를 가져오게 설계
  (모델 입력 기준점이 흔들리면 성능/해석/운영이 깨짐)

4.4 체크리스트

• 학습 데이터가 “어느 시스템 기준 고객인지” 명확한가?
• 골든 레코드 생성 규칙(우선순위/병합 규칙)이 문서화되어 있는가?
• 골든 레코드 변경이 어떤 피처/모델에 영향을 주는지 추적 가능한가?

---

5. 패턴 4: 학습 데이터 스냅샷 & 버전 관리

5.1 언제 쓰는 패턴인가?

• “지난 번 학습 데이터셋을 다시 써야 하는데…” 재현이 어려울 때
• 성능 변화가 “모델 때문인지/데이터 때문인지” 구분이 안 될 때
• 규제/감사 대응을 위해 학습 데이터 버전을 남겨야 할 때

5.2 핵심 엔터티 구조

• TRAINING_DATASET (데이터셋 메타)
• TRAINING_DATASET_VERSION (버전)
• TRAINING_TABLE_REF (물리 테이블/파티션/스냅샷 참조)

예시 속성:

• TRAINING_DATASET_VERSION
• DATASET_ID, VERSION_NO
• CREATED_AT, CREATED_BY
• FEATURE_DEF_VERSION, LABEL_DEF_VERSION
• SOURCE_SNAPSHOT_INFO (예: 2025-10-01 기준 스냅샷)
• FILTER_CONDITION, TIME_RANGE, SAMPLING_RULE
• HASH/FINGERPRINT (재현성 강화를 위한 지문)

5.3 모델링 포인트

• “학습에 사용한 테이블/파티션/조건”을 메타데이터로 남겨 재현 가능성 확보
• 모델 성능 이슈 발생 시
• 모델 문제인지
• 데이터 문제인지
• 라벨 정의 문제인지
  를 역추적 가능하게 설계

5.4 체크리스트

• 학습 데이터 범위(기간/필터)를 재현할 수 있는가?
• 어떤 피처/라벨 정의 버전을 사용했는지 남아 있는가?
• 감사 시 “이 모델은 이 데이터로 학습했다”를 증명할 수 있는가?

---

6. 패턴 5: 온라인–오프라인 정합성(Training–Serving Skew 방지)

6.1 언제 쓰는 패턴인가?

• 배치 학습(오프라인) + 실시간 서빙(온라인)을 함께 운영할 때
• “학습 때는 잘 나오는데 실서비스에서는 성능이 안 나오는” 문제가 있을 때

6.2 핵심 아이디어

• 오프라인과 온라인에서 쓰는 피처는 “같은 의미/정의/로직”이어야 함
• 구조적으로는 다음처럼 정리됩니다.
• FEATURE_DEFINITION (공통 정의)
• OFFLINE_FEATURE_VALUE (배치/분석용)
• ONLINE_FEATURE_VALUE (실시간 서빙용)

6.3 모델링 포인트

• 정의는 한 곳에 모으고(Definition 단일화),
• 온라인/오프라인은 물리 저장 구조만 다르게 가져가되 의미는 동일하게 유지
• 가능하면 같은 ETL/ELT 코드 기반으로 offline/online을 동시에 생성할 수 있게 설계

6.4 체크리스트

• 온라인 피처와 오프라인 피처 정의가 1:1로 매핑되는가?
• 정의가 코드에만 있고, 데이터 모델/메타데이터에는 없는가?
• Skew 발생 시 어느 계층(정의/생성/서빙)에서 차이가 났는지 추적 가능한가?

---

7. 패턴 6: 실험·모델 메타데이터(Experiment & Model Registry)

7.1 언제 쓰는 패턴인가?

• 실험을 많이 하는데 “어떤 세팅이 좋았는지” 나중에 기억이 안 날 때
• 여러 버전 모델을 운영/롤백해야 하는 상황이 자주 있을 때

7.2 핵심 엔터티 구조

• EXPERIMENT (실험 단위)
• EXPERIMENT_RUN (실행 기록: 파라미터/결과)
• MODEL_REGISTRY (배포 가능한 모델 정보)
• MODEL_VERSION (모델 아티팩트 버전)
• METRIC (평가 지표)

7.3 모델링 포인트

• 실험(Experiment)과 모델(Model)을 분리
• 하나의 실험에서 여러 모델 버전이 나올 수 있고
• 한 모델 버전이 여러 실험에서 재사용될 수도 있음
• 각 RUN마다 반드시 남길 것:
• 입력 데이터셋 버전
• 피처/라벨 정의 버전
• 하이퍼파라미터
• 결과 메트릭(Accuracy, F1, ROC-AUC 등)
• 코드/컨테이너 버전(재현성)

7.4 체크리스트

• 서비스 중인 모델이 어떤 실험·데이터·코드 버전에서 나왔는지 알 수 있는가?
• 롤백 시 이전 버전과 세팅을 재현할 수 있는가?
• 실험 기록이 위키/노트에만 있고 DB에는 없는가?

---

8. 패턴 7: 개인정보 비식별화 & 민감 데이터 분리

8.1 언제 쓰는 패턴인가?

• 고객/환자/금융 정보 등 민감 데이터를 AI 학습에 사용해야 할 때
• 내부·외부 규제/컴플라이언스를 준수해야 할 때

8.2 핵심 구조

• PERSONAL_DATA (민감 정보 영역: 이름, 주민번호, 연락처 등)
• ANONYMIZED_KEY_MAP (원본 키 ↔ 익명 키 매핑, 별도 보안 영역)
• ANONYMIZED_DATA (익명 키 기준 비식별 데이터)

8.3 모델링 포인트

• 원본 식별자와 학습에 쓰는 키를 분리
• 예: CUSTOMER_ID(업무용) → ANON_ID(학습용)
• ANONYMIZED_KEY_MAP은
• 별도 스키마/별도 DB/별도 권한으로 관리
• 접근 로그, 암호화, 최소권한 원칙 필수
• 모델 학습 파이프라인이 원본 식별자 영역을 직접 만지지 않도록 설계

8.4 체크리스트

• 학습/평가/배포에 “굳이 필요 없는” 민감 속성이 포함되어 있지 않은가?
• 비식별화 전/후 데이터 정합성 검증이 가능한가?
• 규제 변경 시 어떤 데이터/모델에 영향이 가는지 추적 가능한가?

---

9. 실무에서 7가지 패턴을 적용하는 순서 제안

AI 플랫폼/프로젝트 초기에 전부 한 번에 도입하기보다, 보통 아래 순서를 추천합니다.

1) 패턴 2 + 3 (엔티티–이벤트, MDM/골든 레코드)

• 전통 시스템 + 분석/AI를 동시에 고려한 기본 토대

2) 패턴 1 + 4 (피처 스토어, 학습 데이터 버전 관리)

• 피처 재사용과 학습 재현성 확보

3) 패턴 5 (온라인–오프라인 정합성)

• 실시간/배치 혼합 구조에서 “운영 성능”을 좌우하는 핵심

4) 패턴 6 + 7 (실험/모델 메타데이터, 비식별화)

• 규모가 커지고 규제/운영 복잡도가 올라갈 때 정식 도입

---