---
slug: core-concepts
title: "핵심 개념: Event · Entity · Tag"
description: "저장하면 셋이 생긴다. 누가 만드는지를 알면 무엇을 신경 쓸지가 보인다. entity가 왜 검색을 살리고 tag를 왜 붙이나."
lang: ko
---


# 02. 핵심 개념: Event · Entity · Tag

AiAkiv에 뭔가를 저장하면 세 가지가 생긴다. **누가 만드는지**를 알면 무엇을 신경
쓸지가 보인다.

| | 무엇 | 누가 만드나 | 신경 쓸 정도 |
|--|------|-----------|------------------|
| **Event** | 데이터에 대한 설명(사건 한 조각) | **사용자 입력** | ▽ 저장한 것 자체 |
| **Entity** | 데이터에 나오는 주요 개념 | AI 생성 + 사용자 추가 | ● 중요: 검색이 여기서 산다 |
| **Tag** | 데이터의 추가 검색어 | AI 생성 + 사용자 추가 | ● 중요: 골라 보는 축 |

## Event: 사용자가 저장한 설명

저장 한 번이 Event 하나다. "전투를 턴제로 바꿨다"를 저장하면 그게 한 Event가 된다.
**Event는 사용자가 입력한 설명 그 자체다.** 저장하면 AiAkiv가 여기에 **짧은 요약**과
**Entity**를 자동으로 붙인다. 검색은 요약을 주고, 더 자세히 필요하면 원문을 꺼낸다.

중요한 건 Event가 **혼자 있지 않다**는 것이다. 아래 Entity와 Tag로 서로 엮인다.
그 엮임이 AiAkiv의 전부다.

## Entity: 왜 중요한가

**Entity는 사건에 등장하는 개체다.** 사람, 기능, 파일, 개념을 말한다. "전투를 턴제로
바꿨다"에서는 `전투 시스템`, `턴제`가 Entity다. 저장할 때 **자동으로 추출**된다
(NER).

왜 중요한가: **Entity가 사건과 사건을 이어 준다.**

- "전투 시스템"이라는 Entity를 공유하는 사건이 5개면, 그 5개가 한 줄기로 엮인다.
  → "전투 시스템 어떻게 바뀌었어?"에 그 줄기가 통째로 답이 된다.
- 인벤토리 사건과 세이브 사건이 같은 `직렬화 스키마` Entity를 공유하면, "왜 둘이
  같이 바뀌었어?"에 그 공유 Entity가 답이 된다.

**딱 하나 지킬 것: 한 이름 원칙.** 같은 대상은 늘 같은 이름으로 부른다.
"세이브 포맷"과 "저장 형식"을 섞으면 Entity가 둘로 갈라져 연결이 끊긴다. 이름만
일관되면 그래프가 저절로 엮인다. (→ [저장하기](saving))

## Tag: 왜 중요한가

**Tag는 사용자가 붙이는 라벨이다.** Entity가 "누가·무엇이 등장했나"라면, Tag는 "이건
어떤 종류의 사건인가"다. `결정` / `버그` / `밸런스` / `회고` 같은 것이다.

왜 중요한가: **나중에 골라 보는 축이 된다.**

- "결정만 모아 봐" / "버그 이력만": Tag가 있어야 이렇게 잘라 본다.
- 성격(결정/버그…) + 주제(전투/세이브…)를 같이 붙이면 교차로 좁힐 수 있다.

**Tag는 AI가 저장 시 몇 개 제안**하고, **사용자가 더하거나 고칠 수 있다.** AI 제안을
그대로 두든 손보든, 이 작은 관여가 검색 품질로 돌아온다.

## 한눈에

- **Event**는 사용자가 저장한 설명이다. 요약·Entity는 AI가 붙인다.
- **Entity**는 사건과 사건을 잇는다(AI 추출 + 사용자 추가). **한 이름으로** 저장해야 검색이 잘 된다.
- **Tag**는 축이다. AI가 제안하고 사용자가 손질한다. 나중에 골라 볼 때 산다.

## 다음

- 이 개념들을 살리는 저장법 → [저장하기](saving)
- Entity와 Tag로 검색하기 → [검색하기](searching)