Antigravity Agent
9148c358d0
Topic_Agent/Topic_Blog/Topics/Topics_Biz/Topics_Meeting/Topics_Rag의 마크다운 지식 문서를 Topic_General/Topic_Programming/Topic_Graphic/Topic_Business 4개 카테고리로 재분류. - 중복 제거: frontmatter의 status:duplicate/merged + duplicate_of/redirect_to 필드로 자기 자신을 중복으로 선언한 리다이렉트 stub 1032개 제거, 완전 동일 내용 파일 472개 제거, 동일 파일명·다른 내용 충돌 시 더 큰(완전한) 버전만 유지(162개 제거) — 총 1639개 중복 제거. - 분류: 폴더 단위로 명확한 항목(AI_and_ML/Coding/Architecture 등 → Programming, Comfyui/Visual_Effects → Graphic, Topics_Biz/Topics_Meeting/사업 등 → Business, Poetic_Blog_Writing/창의성/Game_Design 등 → General)은 폴더 우선순위로, 나머지 혼재 폴더(Topic_Agent/Topic_Blog/Topics 루트/Thinking & Reasoning/Other/UI_UX_Assets)는 title/tags 키워드 스코어링으로 파일 단위 분류(불명확한 경우 General로 폴백). 원본 폴더명은 "From_*" 서브폴더로 보존해 추적 가능성 유지. - 최종 배치: Programming 2784 / General 1608 / Graphic 285 / Business 249 = 4926개 문서. - 에이전트 운영 상태(.astra/.agent/.obsidian/sessions/memory/_company/docs/lessons/_shared/src)는 지식 콘텐츠가 아니므로 재분류 대상에서 제외하고 원위치 유지. - Topics/Topic_email(상위 보호 폴더 Topic_email과 파일명 100% 중복) 삭제 — 보호 폴더 자체는 미변경. - 완전히 비게 된 Topic_Agent/Topic_Blog/Topics_Biz/Topics_Rag 폴더 제거.
29 lines
3.4 KiB
Markdown
29 lines
3.4 KiB
Markdown
---
|
|
category: Architecture
|
|
tags: [auto-wikified, technical-documentation, architecture]
|
|
title: Entity (엔티티)
|
|
description: "엔티티(Entity)는 애플리케이션에서 데이터베이스 모델이나 순수한 비즈니스 규칙을 표현하는 핵심 데이터 구조이다 [1-3]."
|
|
last_updated: 2026-05-04
|
|
---
|
|
|
|
# Entity (엔티티)
|
|
|
|
## 📌 Brief Summary
|
|
엔티티(Entity)는 애플리케이션에서 데이터베이스 모델이나 순수한 비즈니스 규칙을 표현하는 핵심 데이터 구조이다 [1-3]. 현대 소프트웨어 개발 및 실전 아키텍처에서는 엔티티를 API 입출력을 담당하는 DTO(Data Transfer Object)와 엄격하게 분리하여 관리하는 것을 핵심 패턴으로 삼는다 [1-3]. 이를 통해 데이터베이스 스키마와 외부 API 스펙 간의 결합도를 낮추고 대규모 시스템의 유지보수성을 확보할 수 있다 [2-4].
|
|
|
|
## 📖 Core Content
|
|
* **역할 및 위치:**
|
|
실무 아키텍처에서 엔티티는 주로 TypeORM, Prisma, Drizzle(NestJS 환경) 또는 JPA(Spring Boot 환경)와 같은 도구의 데코레이터/어노테이션을 통해 데이터베이스 모델로 정의되며, 서비스(Service) 계층에서 사용된다 [2, 5, 6]. 특히 헥사고날 아키텍처(Hexagonal Architecture)에서는 도메인(Domain) 계층에 위치하여 어떠한 외부 프레임워크나 라이브러리에도 의존하지 않는 순수한 형태로 존재해야 한다 [3].
|
|
* **DTO와의 명확한 분리:**
|
|
프로젝트 초기에는 엔티티와 DTO의 구조가 매우 유사해 보일 수 있으나, 시간이 지나고 애플리케이션이 확장됨에 따라 두 객체의 구조는 필연적으로 달라지게 된다 [1, 2]. 따라서 엔티티는 데이터베이스 스키마 및 도메인 표현에만 집중하고, DTO는 API를 넘나드는 데이터의 형태를 정의하는 용도로 역할을 분리해야 한다 [1, 2].
|
|
* **데이터 변환 및 계약 유지:**
|
|
엔티티를 애플리케이션의 다른 계층이나 외부로 전달할 때는 매퍼(Mapper)를 통해 DTO로 데이터를 변환하는 과정을 거쳐야 한다 [3]. 소비 계층(Consuming layer)에는 인터페이스 계약에 기반한 DTO만 반환함으로써 핵심 엔티티를 격리 및 보호할 수 있다 [4].
|
|
|
|
## ⚖️ Trade-offs & Caveats
|
|
* **직접 노출 시의 위험성 (안티 패턴):**
|
|
컨트롤러(Controller)에서 엔티티를 클라이언트에게 직접 노출하는 것은 심각한 안티 패턴이다 [2]. 엔티티를 직접 반환하면 내부 데이터베이스 필드 구조가 외부에 그대로 유출될 뿐만 아니라, 애플리케이션이 DB 스키마에 완전히 종속(Lock-in)되게 된다 [2]. 이로 인해 추후 데이터 모델이 변경될 때 외부 API 스펙까지 파괴될 위험이 있으며, API 변경에 막대한 비용이 발생하게 된다 [2, 3].
|
|
* **보일러플레이트 코드와 복잡성 증가:**
|
|
엔티티와 DTO를 분리하고 변환하는 패턴은 아키텍처를 견고하게 만들지만, 개발자가 작성하고 유지보수해야 할 보일러플레이트 코드(예: 중복되어 보이는 DTO 클래스 및 매핑 로직)를 증가시킨다는 단점이 있다 [7]. 소규모 팀이나 단순한 프로젝트에서는 이러한 엄격한 분리 구조가 오히려 비즈니스 가치 창출보다 프레임워크 배선(wiring) 작업에 더 많은 비용을 소모하게 만들 수 있다 [7, 8].
|
|
|
|
---
|
|
*Last updated: 2026-05-03* |