서론: 데이터 무결성을 지키는 숨은 앵커, 약 엔티티
데이터베이스 설계자들은 종종 "모든 테이블에 ID(Auto Increment)를 부여해야 하는가?"라는 딜레마에 빠집니다. 편의상 대리 키(Surrogate Key)를 남발하다 보면, 데이터 간의 논리적 종속성이 흐려져 고아 데이터(Orphaned Data)가 발생하는 원인이 됩니다. 여기서 약 엔티티(Weak Entity)의 개념이 중요해집니다. 약 엔티티는 단순한 이론적 개념이 아니라, 부모 데이터가 삭제될 때 자식 데이터도 함께 정리되도록 강제하는 '데이터 수명 주기 관리'의 핵심 장치입니다. 본 글에서는 ER 모델링의 약 엔티티 개념을 현대적인 RDBMS와 NoSQL 환경에서 어떻게 재해석하고 적용해야 하는지 실무적 관점에서 파헤칩니다.
핵심 원리: 복합 키(Composite Key)와 식별 관계의 이해
약 엔티티를 이해하는 가장 좋은 예시는 '호텔'과 '객실'입니다. '101호'라는 객실 번호는 전 세계에 수만 개가 존재합니다. 즉, '101호'는 'A호텔'이라는 문맥(Context) 없이는 식별될 수 없습니다.
식별 관계(Identifying Relationship)의 실체
ER 다이어그램에서 이중 사각형으로 표현되는 약 엔티티는 실제 SQL로 변환될 때 복합 기본 키(Composite Primary Key)로 구현됩니다.
PRIMARY KEY (Hotel_ID, Room_Number)
이처럼 강 엔티티(호텔)의 기본 키를 자신의 기본 키 일부로 포함하는 것을 '식별 관계'라고 합니다. 이는 데이터베이스 엔진에게 "호텔이 없으면 방도 존재할 수 없다"는 강력한 제약 조건을 선언하는 것입니다.
CREATE TABLE 전략과 ON DELETE CASCADE
실무에서 약 엔티티를 구현할 때 가장 중요한 것은 외래 키(FK) 옵션입니다. 약 엔티티 테이블 생성 시 ON DELETE CASCADE 옵션을 반드시 고려해야 합니다. 이는 부모 데이터(강 엔티티)가 삭제될 때, 별도의 로직 없이도 관련된 약 엔티티 데이터가 자동으로 삭제되게 하여 데이터 무결성을 보장합니다. 이는 애플리케이션 레벨에서 일일이 데이터를 지우는 수고를 덜어주고 트랜잭션 관리를 단순화하는 효율적인 방법론입니다.
최신 트렌드: MSA와 NoSQL 시대의 약 엔티티
2025년의 데이터 환경은 관계형 데이터베이스(RDBMS)와 NoSQL이 공존하고 있습니다. 이 환경 변화에 따라 약 엔티티를 다루는 방식도 진화했습니다.
NoSQL에서의 약 엔티티: 임베딩(Embedding)
MongoDB와 같은 문서 지향(Document-oriented) 데이터베이스에서는 약 엔티티를 별도의 컬렉션(테이블)으로 쪼개지 않고, 강 엔티티의 문서 내부에 배열(Array)이나 내장 객체(Embedded Document)로 저장하는 패턴을 선호합니다. 예를 들어, '주문(Order)' 문서 안에 '주문 상세(Order Items)'를 포함시키는 것입니다. 이는 조인(Join) 비용을 없애 읽기 성능을 극대화하는 전략으로, 약 엔티티의 '종속성' 개념을 물리적 저장 구조로 일치시킨 사례입니다.
ORM(JPA/Hibernate)과 복합 키의 딜레마
현대적인 웹 개발에서 JPA와 같은 ORM 프레임워크를 사용할 때, 복합 키를 사용하는 약 엔티티는 구현의 복잡성을 높입니다(@EmbeddedId 등 사용 필요). 때문에 최근 실무 트렌드는 약 엔티티의 개념은 유지하되, 물리적 구현은 비식별 관계(Non-identifying Relationship)와 대리 키(UUID/Auto Increment)를 사용하는 방향으로 우회하기도 합니다. 즉, 논리적으로는 약 엔티티지만, 물리적으로는 독립적인 ID를 부여하여 개발 편의성을 높이는 하이브리드 접근 방식이 주류를 이루고 있습니다.
실무 적용 및 최적화: 성능을 고려한 설계
약 엔티티 설계를 실제 프로젝트에 적용할 때 고려해야 할 성능 포인트입니다.
- 인덱스(Index) 전략: 약 엔티티는 강 엔티티의 키를 포함하므로, 조인 연산이 빈번하게 발생합니다. 복합 키를 구성하는 컬럼 순서(Ordering)가 조회 쿼리의 성능을 좌우하므로,
WHERE절에 자주 사용되는 컬럼을 인덱스 선두에 배치해야 합니다. - 이력 관리(History) 데이터: '변경 이력'이나 '로그' 데이터는 대표적인 약 엔티티입니다. 이들은 데이터 양이 방대하므로 파티셔닝(Partitioning)을 적용할 때, 강 엔티티의 키(예: 생성일자, 사용자ID)를 기준으로 파티션 키를 설계하면 관리 효율성이 높아집니다.
전문가 제언 (Expert Insight)
💡 Database Architect's Tip
"비즈니스 식별자와 시스템 식별자를 구분하세요."
초보 설계자가 가장 많이 하는 실수는 비즈니스 로직상의 약 엔티티(예: 주문 상세)를 구현하기 위해 무조건 복합 키(Composite Key)를 고집하는 것입니다. 복합 키는 데이터 정합성 측면에서는 완벽하지만, 프론트엔드에서 데이터를 호출하거나 API를 설계할 때 URL이 복잡해지는 단점(예: /orders/1/items/5)이 있습니다. 시스템 유연성을 위해서는 내부적으로는 대리 키(Surrogate Key, 예: Item_UUID)를 PK로 사용하고, Unique Constraint(복합 유니크 제약조건)를 통해 약 엔티티의 성격을 논리적으로 강제하는 것이 현대적인 마이크로서비스 아키텍처(MSA)에 더 적합한 모델링 패턴입니다.
결론: 도구는 변해도 원칙은 변하지 않는다
AI가 SQL을 작성해주고 NoSQL이 스키마리스(Schemaless)를 외치는 시대에도, '데이터 간의 관계'를 정의하는 엔티티 모델링의 본질은 변하지 않았습니다. 약 엔티티 개념을 정확히 이해한다는 것은 단순히 ER 다이어그램을 잘 그리는 것을 넘어, 데이터의 생명주기와 무결성을 시스템 차원에서 보증한다는 것을 의미합니다. 프로젝트의 규모와 사용하는 기술 스택(RDBMS vs NoSQL)에 맞춰 약 엔티티를 유연하게 적용(복합 키 사용 혹은 임베딩)하는 능력이야말로, 주니어와 시니어 엔지니어를 가르는 중요한 척도가 될 것입니다.