---
id: P-REINFORCE-AUTO-8E681E
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
github_commit: "[P-Reinforce] Continuous Worker - 엔티티 (Entities)"
---

# [[엔티티 (Entities)|엔티티 (Entities)]]

## 📌 한 줄 통찰 (The Karpathy Summary)
> 엔티티(Entities)는 소프트웨어 아키텍처 및 도메인 주도 설계(DDD)에서 핵심 업무 데이터와 이를 기반으로 동작하는 전사적인 핵심 업무 규칙을 캡슐화하는 고수준의 객체입니다 [1-3]. 이들은 아키텍처의 가장 중심 계층에 위치하며, 데이터베이스나 사용자 인터페이스(UI), 프레임워크와 같은 외부 요소에 전혀 의존하지 않고 독립적으로 존재합니다 [1, 4]. 본질적으로 시스템의 입출력 방식이나 외부 기술의 변화에 영향을 받지 않는, 비즈니스의 가장 핵심적이고 순수한 개념을 구체화합니다 [3-5].

## 📖 구조화된 지식 (Synthesized Content)
* **엔티티의 정의 및 식별성**
  도메인 주도 설계(DDD)에서 엔티티는 고유한 식별성(identity)을 갖는 객체로 정의되며, 오직 속성으로만 정의되는 값 객체(Value Object)와 엄격히 구분됩니다 [6]. 예를 들어, '고객(Customer)'은 고유한 정체성을 가진 엔티티에 해당하고, '배송지 주소'는 값 객체로 취급됩니다 [6]. 엔티티는 핵심 업무 데이터를 직접 포함하거나 쉽게 접근할 수 있으며, 이 데이터를 조작하는 업무 규칙 함수들을 인터페이스로 제공합니다 [2].

* **클린 아키텍처에서의 중심 역할**
  클린 아키텍처 구조에서 엔티티는 시스템의 가장 안쪽이자 중심인 도메인 계층에 위치합니다 [1, 7]. 외부의 어떠한 세부 사항(웹, 데이터베이스, 서드파티 프레임워크 등)으로 인해 오염되어서는 안 되며, 외부 계층에 대해 전혀 알지 못해야 합니다 [4, 8]. 이를 위해 엔티티 객체는 프레임워크 등에 의존하지 않는 오래된 방식의 간단하고 평범한 객체(plain old object) 형태로 유지되어야 합니다 [9, 10].

* **유스케이스(Use Cases)와의 관계**
  엔티티는 시스템에서 가장 범용적이고 높은 수준(고수준)을 갖는 개념입니다 [11]. 단일 애플리케이션에 특화된 저수준 개념인 유스케이스는 엔티티에 의존하고 엔티티의 핵심 업무 규칙을 호출하지만, 반대로 엔티티는 자신을 제어하는 유스케이스에 대해 아무것도 알지 못합니다 [5, 12]. 유스케이스는 엔티티로 들어오고 나가는 데이터 흐름을 조정하는 역할을 수행합니다 [13].

* **변경에 대한 독립성과 유의사항**
  엔티티는 전사적인 핵심 규칙을 담고 있기 때문에, 페이지 네비게이션이나 보안과 같은 외부 요구사항이 변경되더라도 엔티티가 변경될 가능성은 지극히 낮습니다 [3]. 또한, 엔티티와 애플리케이션의 요청/응답 모델이 상당히 많은 데이터를 공유하더라도, 두 객체의 목적이 완전히 다르므로 결코 결합(참조)해서는 안 됩니다 [14]. 이를 결합하면 공통 폐쇄 원칙과 단일 책임 원칙을 위배하게 되어 코드베이스를 오염시킵니다 [14].

## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.

## 🔗 지식 연결 (Graph)
- **Related Topics:** 도메인 주도 설계 (Domain-Driven Design), [[클린 아키텍처 (Clean Architecture)|클린 아키텍처 (Clean Architecture)]], [[유스케이스 (Use Cases)|유스케이스 (Use Cases)]], 값 객체 (Value Objects)
- **Projects/Contexts:** 엔터프라이즈급 소프트웨어 아키텍처 설계, VIPER 아키텍처 기반 iOS 애플리케이션 개발
- **Contradictions/Notes:** 엔티티와 시스템의 요청 및 응답 모델은 많은 데이터를 공유하기 때문에 서로 참조하거나 결합하려는 유혹에 빠지기 쉽지만, 이는 장기적으로 공통 폐쇄 원칙을 위반하고 코드베이스에 혼란을 초래하므로 엄격히 분리해야 한다고 경고합니다 [14].

---
*Last updated: 2026-04-18*
- Raw Source: 00_Raw/2026-04-20/엔티티 (Entities).md
---