// ❌ "간단하고 깔끔하네요! 이렇게 쓰면 되겠네요?"
@Entity
public class User {
    @Id
    @GeneratedValue
    private Long id;
    
    private String name;
    
    @ElementCollection
    @CollectionTable(name = "user_hobbies")
    private Set<String> hobbies = new HashSet<>();
    // "취미 목록 저장하는 거니까 @ElementCollection 쓰면 완벽하겠네요!"
}

// ❌ "태그도 이렇게 저장하면 편하겠는데요?"
@Entity 
public class Post {
    @Id
    private Long id;
    
    @ElementCollection
    @CollectionTable(name = "post_tags")
    private List<String> tags = new ArrayList<>();
    // "포스트 태그들도 단순 문자열이니까 @ElementCollection으로!"
}

@Entity
@Getter
public class BlogPost {
    @Id
    @GeneratedValue
    private Long id;
    
    private String title;
    private String content;
    
    @ElementCollection  // 🚨 성능 폭탄이 설치됨!
    @CollectionTable(name = "post_tags", joinColumns = @JoinColumn(name = "post_id"))
    @Column(name = "tag")
    private Set<String> tags = new HashSet<>();
    
    public void addTag(String tag) {
        this.tags.add(tag);  // 🚨 이 한 줄이 재앙의 시작
    }
}

// 😱 실무에서 벌어지는 참사 시나리오
@Service
@Transactional
public class BlogService {
    
    public void addTagToPost(Long postId, String newTag) {
        BlogPost post = blogRepository.findById(postId).orElseThrow();
        
        // 기존 태그: ["Java", "Spring", "JPA", "Hibernate", "Database"]
        // 새 태그: "Performance" 추가
        post.addTag("Performance");
        
        // 🚨 JPA가 실행하는 SQL (실제 로그):
        // 1. 기존 태그들 모두 삭제
        // DELETE FROM post_tags WHERE post_id = 1
        
        // 2. 모든 태그를 다시 삽입 (기존 5개 + 새로운 1개 = 총 6개!)
        // INSERT INTO post_tags (post_id, tag) VALUES (1, 'Java')
        // INSERT INTO post_tags (post_id, tag) VALUES (1, 'Spring')  
        // INSERT INTO post_tags (post_id, tag) VALUES (1, 'JPA')
        // INSERT INTO post_tags (post_id, tag) VALUES (1, 'Hibernate')
        // INSERT INTO post_tags (post_id, tag) VALUES (1, 'Database')
        // INSERT INTO post_tags (post_id, tag) VALUES (1, 'Performance')
        
        // 😱 태그 1개 추가하려고 했는데 DELETE 1번 + INSERT 6번 실행!
        // 태그가 100개면? DELETE 1번 + INSERT 101번!
        // 태그가 1000개면? DELETE 1번 + INSERT 1001번!
    }
    
    public void removeTagFromPost(Long postId, String tagToRemove) {
        BlogPost post = blogRepository.findById(postId).orElseThrow();
        
        // 기존 태그: ["Java", "Spring", "JPA", "Hibernate", "Database", "Performance"]  
        // "Performance" 태그 제거
        post.getTags().remove(tagToRemove);
        
        // 🚨 또 다시 전체 교체!
        // DELETE FROM post_tags WHERE post_id = 1
        // INSERT INTO post_tags (post_id, tag) VALUES (1, 'Java')
        // INSERT INTO post_tags (post_id, tag) VALUES (1, 'Spring')
        // INSERT INTO post_tags (post_id, tag) VALUES (1, 'JPA') 
        // INSERT INTO post_tags (post_id, tag) VALUES (1, 'Hibernate')
        // INSERT INTO post_tags (post_id, tag) VALUES (1, 'Database')
        
        // 😱 태그 1개 삭제하려고 했는데 DELETE 1번 + INSERT 5번!
    }
    
    // 🚨 진짜 무서운 시나리오: 대량 태그 업데이트
    public void updatePostTags(Long postId, Set<String> newTags) {
        BlogPost post = blogRepository.findById(postId).orElseThrow();
        
        // 기존 태그 100개 → 새로운 태그 101개로 업데이트
        post.getTags().clear();
        post.getTags().addAll(newTags);
        
        // 🚨 실행되는 SQL:
        // DELETE FROM post_tags WHERE post_id = 1  (100개 삭제)
        // INSERT INTO post_tags... (101번 실행!)
        
        // 😱 데이터베이스가 울고 있습니다...
    }
}

// 🎯 Tag를 독립적인 엔티티로 설계
@Entity
@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class Tag {
    @Id
    @GeneratedValue
    private Long id;
    
    @Column(unique = true)
    private String name;
    
    @Builder
    public Tag(String name) {
        this.name = name;
    }
}

@Entity
@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class BlogPost {
    @Id
    @GeneratedValue
    private Long id;
    
    private String title;
    private String content;
    
    @OneToMany(mappedBy = "post", cascade = CascadeType.ALL, orphanRemoval = true)
    private List<PostTag> postTags = new ArrayList<>();
    
    // 🎯 비즈니스 메서드로 안전한 태그 관리
    public void addTag(Tag tag) {
        PostTag postTag = PostTag.builder()
                .post(this)
                .tag(tag)
                .build();
        this.postTags.add(postTag);
    }
    
    public void removeTag(Tag tag) {
        postTags.removeIf(postTag -> postTag.getTag().equals(tag));
    }
    
    public Set<String> getTagNames() {
        return postTags.stream()
                .map(postTag -> postTag.getTag().getName())
                .collect(Collectors.toSet());
    }
}

// 🎯 중간 테이블 엔티티
@Entity
@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@Table(name = "post_tags")
public class PostTag {
    @Id
    @GeneratedValue
    private Long id;
    
    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "post_id")
    private BlogPost post;
    
    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "tag_id")
    private Tag tag;
    
    @Builder
    public PostTag(BlogPost post, Tag tag) {
        this.post = post;
        this.tag = tag;
    }
}

// 🎯 개선된 서비스 코드
@Service
@RequiredArgsConstructor
@Transactional
public class BlogService {
    private final BlogRepository blogRepository;
    private final TagRepository tagRepository;
    
    public void addTagToPost(Long postId, String tagName) {
        BlogPost post = findPost(postId);
        Tag tag = tagRepository.findByName(tagName)
                .orElseGet(() -> tagRepository.save(Tag.builder().name(tagName).build()));
        
        post.addTag(tag);
        
        // 🎉 실행되는 SQL:
        // INSERT INTO post_tags (post_id, tag_id) VALUES (?, ?)
        // 단 1번의 INSERT만 실행! 기존 태그들은 건드리지 않음!
    }
    
    public void removeTagFromPost(Long postId, String tagName) {
        BlogPost post = findPost(postId);
        Tag tag = tagRepository.findByName(tagName).orElseThrow();
        
        post.removeTag(tag);
        
        // 🎉 실행되는 SQL:
        // DELETE FROM post_tags WHERE post_id = ? AND tag_id = ?
        // 단 1번의 DELETE만 실행! 다른 태그들은 안전함!
    }
}

@Entity
@Getter
public class UserPreference {
    @Id
    private Long userId;
    
    @ElementCollection
    @CollectionTable(name = "user_notification_settings")
    @Enumerated(EnumType.STRING)
    private Set<NotificationType> enabledNotifications = EnumSet.noneOf(NotificationType.class);
    
    // 🎯 설정값은 변경이 드물고, 종류가 제한적
    // 알림 타입: EMAIL, SMS, PUSH, IN_APP (최대 4개)
    // 사용자가 설정을 바꾸는 빈도: 월 1-2회 정도
    
    public void enableNotification(NotificationType type) {
        this.enabledNotifications.add(type);
        // 설정 변경이 드물어서 전체 교체 방식의 부담이 적음
    }
}

// 🎯 실제 사용 패턴
@Service
public class UserPreferenceService {
    
    public void updateNotificationSettings(Long userId, Set<NotificationType> newSettings) {
        UserPreference preference = findPreference(userId);
        
        // 전체 설정을 한 번에 변경 (일반적인 사용 패턴)
        preference.getEnabledNotifications().clear();
        preference.getEnabledNotifications().addAll(newSettings);
        
        // 🎉 4개 타입 전체 교체: DELETE 1번 + INSERT 3번 (괜찮은 수준)
    }
}

@Entity
@Getter  
public class Product {
    @Id
    private Long id;
    
    private String name;
    
    @ElementCollection
    @CollectionTable(name = "product_categories")
    @Enumerated(EnumType.STRING)
    private Set<ProductCategory> categories = new HashSet<>();
    
    // 🎯 상품 카테고리는 개수가 제한적이고 변경이 드뭄
    // 카테고리: ELECTRONICS, CLOTHING, BOOKS, SPORTS (제한된 enum)
    // 상품당 카테고리: 보통 1-3개
    // 변경 빈도: 상품 등록 시 1회, 이후 거의 변경 없음
}

@Embeddable
@Getter
@AllArgsConstructor
@NoArgsConstructor
public class Address {
    private String street;
    private String city;
    private String zipCode;
}

@Entity
@Getter
public class Company {
    @Id
    private Long id;
    
    private String name;
    
    @ElementCollection
    @CollectionTable(name = "company_addresses")
    private List<Address> addresses = new ArrayList<>();
    
    // 🎯 회사 주소는 많아봐야 3-5개, 변경도 드뭄
    // 본사, 지사, 물류센터 등 제한적인 개수
}

// 🚨 안티패턴 1: 사용자 생성 태그
@Entity
public class BlogPost {
    @ElementCollection  // ❌ 사용자가 자유롭게 추가하는 태그들
    private Set<String> userTags;  // 무한히 늘어날 수 있음!
}

// 🚨 안티패턴 2: 댓글이나 리뷰
@Entity  
public class Product {
    @ElementCollection  // ❌ 댓글은 엔티티여야 함!
    private List<String> reviews;  // 작성자, 작성일 등 메타 정보 부족
}

// 🚨 안티패턴 3: 파일 경로나 URL
@Entity
public class User {
    @ElementCollection  // ❌ 사용자 업로드 이미지들
    private List<String> profileImages;  // 계속 추가/삭제됨, 성능 재앙
}

// 🚨 안티패턴 4: 로그나 이력 데이터
@Entity
public class Order {
    @ElementCollection  // ❌ 주문 상태 변경 이력
    private List<String> statusHistory;  // 시간순으로 계속 쌓이는 데이터
}

// 🚨 안티패턴 5: 외부 시스템 연동 데이터
@Entity
public class Product {
    @ElementCollection  // ❌ 외부 API에서 받아온 키워드들
    private Set<String> searchKeywords;  // 외부 시스템에 따라 변동성 큼
}

// ✅ 권한 시스템
@Entity
public class User {
    @ElementCollection
    @Enumerated(EnumType.STRING)
    private Set<Role> roles = EnumSet.noneOf(Role.class);
    // Role: ADMIN, USER, MODERATOR (고정된 3개)
}

// ✅ 알림 설정
@Entity  
public class UserSetting {
    @ElementCollection
    @Enumerated(EnumType.STRING)
    private Set<NotificationChannel> channels = EnumSet.noneOf(NotificationChannel.class);
    // NotificationChannel: EMAIL, SMS, PUSH (고정된 3개)
}

// ✅ 상품 속성
@Entity
public class Product {
    @ElementCollection
    @CollectionTable(name = "product_features")
    private Set<ProductFeature> features = new HashSet<>();
    // ProductFeature: WATERPROOF, WIRELESS, FAST_CHARGING (제한적)
}

// ✅ 태그 시스템 (재사용 가능)
@Entity
public class Tag {
    @Id
    private Long id;
    private String name;
}

@Entity
public class PostTag {
    @ManyToOne
    private Post post;
    @ManyToOne  
    private Tag tag;
}

// ✅ 파일 업로드
@Entity
public class UploadedFile {
    @Id
    private Long id;
    private String filename;
    private String url;
    
    @ManyToOne
    private User uploader;
}

// ✅ 로그 데이터
@Entity
public class UserActivityLog {
    @Id
    private Long id;
    private Long userId;
    private String activity;
    private LocalDateTime timestamp;
    
    // User와 직접 연관관계 없음 (성능상)
    // 별도 Repository로 배치 처리
}

// ✅ 이벤트 스트림
@Entity
public class OrderEvent {
    @Id
    private Long id;
    private Long orderId;
    private String eventType;
    private String eventData;
    private LocalDateTime occurredAt;
}

// 🚨 @ElementCollection 방식
@ElementCollection
private Set<String> tags;

// 평균 응답 시간: 847ms
// 실행 쿼리 수: DELETE 1번 + INSERT 21번 = 총 22번
// 메모리 사용량: 높음 (전체 컬렉션 로딩)

// ✅ @OneToMany 방식  
@OneToMany(mappedBy = "post")
private List<PostTag> postTags;

// 평균 응답 시간: 23ms (37배 빠름!)
// 실행 쿼리 수: INSERT 1번
// 메모리 사용량: 낮음 (필요한 것만 로딩)

// 🔍 프로젝트 전체 검색: "@ElementCollection"

// ✅ 안전한 사용 (유지 가능)
@ElementCollection
@Enumerated(EnumType.STRING)  
private Set<Role> roles;  // ← 고정된 enum, 변경 드뭄

// ⚠️ 위험한 사용 (검토 필요)
@ElementCollection
private List<String> tags;  // ← 동적 추가/삭제, 개수 제한 없음

// 🚨 즉시 변경 필요
@ElementCollection  
private List<String> comments;  // ← 댓글은 엔티티여야 함!

// 1. 로그 분석: 실행되는 SQL 쿼리 확인
logging:
  level:
    org.hibernate.SQL: DEBUG
    org.hibernate.type.descriptor.sql.BasicBinder: TRACE

// 2. APM 도구로 응답 시간 측정
// - 스카웃 APM, 핀포인트, 제니퍼 등
// - @ElementCollection 사용하는 API의 응답 시간 체크

// 3. 데이터베이스 성능 지표 확인  
// - 실행 쿼리 수 (INSERT/DELETE 폭증 체크)
// - 테이블 스캔 여부 확인

// 🔴 1순위: 사용자 생성 데이터 (즉시 변경)
// Before
@ElementCollection
private Set<String> userTags;

// After  
@OneToMany(mappedBy = "post", cascade = CascadeType.ALL, orphanRemoval = true)
private List<PostTag> postTags = new ArrayList<>();

// 🟡 2순위: 빈번한 변경이 발생하는 컬렉션
// Before
@ElementCollection
private List<String> categories;

// After - 카테고리가 제한적이면서 변경이 드물다면
@ElementCollection
@Enumerated(EnumType.STRING)
private Set<CategoryType> categories;  // String → Enum으로 제한

// 🟢 3순위: 안정적이지만 개선 여지가 있는 컬렉션
// 성능 측정 후 필요시에만 변경

// 🎯 커스텀 어노테이션으로 성능 측정
@Target(METHOD)
@Retention(RUNTIME)
public @interface MonitorElementCollection {
    String value() default "";
}

@Aspect
@Component
public class ElementCollectionMonitor {
    
    @Around("@annotation(monitor)")
    public Object monitorPerformance(ProceedingJoinPoint joinPoint, 
                                   MonitorElementCollection monitor) throws Throwable {
        
        long startTime = System.currentTimeMillis();
        
        try {
            return joinPoint.proceed();
        } finally {
            long executionTime = System.currentTimeMillis() - startTime;
            
            if (executionTime > 100) {  // 100ms 초과 시 경고
                log.warn("@ElementCollection 성능 이슈 감지: {}ms - {}",
                        executionTime, monitor.value());
            }
        }
    }
}

// 사용법
@MonitorElementCollection("블로그 태그 추가")
public void addTagToPost(Long postId, String tag) {
    // @ElementCollection 사용하는 메서드에 적용
}

// 🎯 코드 리뷰 체크리스트
/**
 * @ElementCollection 사용 검토 사항
 * 
 * ✅ 체크할 항목들:
 * 1. 컬렉션 요소가 값 타입(String, Enum, @Embeddable)인가?
 * 2. 컬렉션 크기가 제한적인가? (보통 10개 이하)
 * 3. 변경 빈도가 낮은가? (월 1-2회 이하)
 * 4. 독립적인 생명주기가 필요하지 않은가?
 * 5. 복잡한 쿼리나 조인이 필요하지 않은가?
 * 
 * ❌ 피해야 할 패턴들:
 * - 사용자가 자유롭게 추가/삭제하는 데이터
 * - 댓글, 리뷰 등 메타데이터가 필요한 경우  
 * - 파일 업로드, 이미지 URL 등 외부 리소스
 * - 로그, 이력 등 시계열 데이터
 * - 검색, 필터링이 자주 필요한 데이터
 */

@ElementCollection  // ← 이 어노테이션이 있으면 위 체크리스트 검토!
private Set<String> someCollection;

// 🎯 핵심 원칙: 명확한 기준만 정하기
// 1. Enum 컬렉션 → @ElementCollection OK
// 2. 동적 String 컬렉션 → @OneToMany 사용
// 3. 의심되면 @OneToMany 선택

@ElementCollection
@Enumerated(EnumType.STRING)
private Set<UserRole> roles;  // ✅ OK - 고정된 enum

@OneToMany(mappedBy = "user")  
private List<UserTag> tags;   // ✅ OK - 동적 데이터는 안전하게

// 🎯 팀 컨벤션 문서화
/**
 * @ElementCollection 사용 기준
 * 
 * ✅ 허용 케이스:
 * - Enum 기반 설정값 (권한, 알림설정 등)
 * - @Embeddable 값 객체 (주소, 좌표 등) 
 * - 최대 10개 이하의 고정적 문자열
 * 
 * ❌ 금지 케이스:
 * - 사용자 입력 기반 태그/카테고리
 * - 파일 경로, URL 등 외부 리소스
 * - 댓글, 리뷰 등 메타데이터가 필요한 경우
 */

// 🎯 코드 템플릿 제공
// ElementCollection 템플릿
@ElementCollection
@CollectionTable(name = "entity_name_values", 
                joinColumns = @JoinColumn(name = "entity_id"))
@Column(name = "value")  
private Set<String> values = new HashSet<>();

// OneToMany 템플릿  
@OneToMany(mappedBy = "parent", cascade = CascadeType.ALL, orphanRemoval = true)
private List<ChildEntity> children = new ArrayList<>();

// 🎯 아키텍처 테스트로 강제
@ArchTest
static ArchRule element_collection_should_only_be_used_with_enums_or_embeddables =
    fields().that().areAnnotatedWith(ElementCollection.class)
            .should().haveRawType(Set.class).orShould().haveRawType(List.class)
            .andShould().beAnnotatedWith(Enumerated.class)
            .orShould().haveRawTypeAssignableTo(Collection.class)
            .because("@ElementCollection은 Enum이나 @Embeddable과만 사용해야 합니다");

// 🎯 정적 분석 도구 연동 (SonarQube 규칙)
// "ElementCollectionWithStringCollection": @ElementCollection에 String 컬렉션 사용 금지
// "ElementCollectionSizeLimit": @ElementCollection 사용 시 크기 제한 체크

// 🎯 성능 테스트 자동화
@SpringBootTest
public class ElementCollectionPerformanceTest {
    
    @Test
    public void elementCollection_performance_should_not_degrade() {
        StopWatch stopWatch = new StopWatch();
        
        stopWatch.start();
        // @ElementCollection 사용하는 작업 실행
        elementCollectionService.addMultipleItems(entityId, items);
        stopWatch.stop();
        
        // 100ms 이상 걸리면 테스트 실패
        assertThat(stopWatch.getTotalTimeMillis()).isLessThan(100);
    }
}

// 🚨 문제 상황
@Entity
public class User {
    @ElementCollection(fetch = FetchType.LAZY)  // 지연 로딩 설정했는데도...
    private Set<String> hobbies;
}

@Service  
public class UserService {
    public List<UserDto> getAllUsers() {
        List<User> users = userRepository.findAll();
        
        return users.stream()
                .map(user -> UserDto.builder()
                        .name(user.getName())
                        .hobbies(user.getHobbies())  // 🚨 N+1 쿼리 발생!
                        .build())
                .toList();
    }
}

// 🎯 해결책 1: Fetch Join 사용
@Query("SELECT u FROM User u LEFT JOIN FETCH u.hobbies")
List<User> findAllWithHobbies();

// 🎯 해결책 2: DTO 프로젝션 활용  
@Query("SELECT new UserDto(u.name, h.hobby) FROM User u LEFT JOIN u.hobbies h")
List<UserDto> findAllUserDtos();

// 🎯 해결책 3: 두 단계 조회
public List<UserDto> getAllUsers() {
    // 1. User 먼저 조회
    List<User> users = userRepository.findAll();
    List<Long> userIds = users.stream().map(User::getId).toList();
    
    // 2. hobbies 일괄 조회  
    Map<Long, Set<String>> hobbiesMap = userRepository.findHobbiesByUserIds(userIds);
    
    // 3. 조합
    return users.stream()
            .map(user -> UserDto.builder()
                    .name(user.getName())
                    .hobbies(hobbiesMap.get(user.getId()))
                    .build())
            .toList();
}

// 🚨 문제 상황: 두 사용자가 동시에 태그 수정
// User A: ["Java", "Spring"] → ["Java", "Spring", "JPA"] 
// User B: ["Java", "Spring"] → ["Java", "Spring", "Hibernate"]
// 결과: 마지막 수정만 남고 나머지는 사라짐!

// 🎯 해결책 1: 버전 관리 (@Version)
@Entity
public class BlogPost {
    @Version
    private Long version;  // 낙관적 락
    
    @ElementCollection
    private Set<String> tags;
    
    // 태그 추가 시 전체 교체가 아닌 개별 관리로 변경 필요
}

// 🎯 해결책 2: @OneToMany로 변경하여 개별 관리
@Entity
public class BlogPost {
    @OneToMany(mappedBy = "post", cascade = CascadeType.ALL, orphanRemoval = true)
    private List<PostTag> postTags;
    
    public void addTag(String tagName) {
        PostTag newTag = PostTag.builder()
                .post(this)
                .tagName(tagName)
                .build();
        this.postTags.add(newTag);
        // 개별 INSERT로 동시성 문제 해결
    }
}

// 🚨 문제: 특정 태그를 가진 포스트 검색이 느림
@Query("SELECT p FROM BlogPost p JOIN p.tags t WHERE t IN :tags")
List<BlogPost> findByTagsIn(List<String> tags);
// @ElementCollection으로는 복잡한 쿼리 최적화가 어려움

// 🎯 해결책: 정규화된 테이블 구조로 변경
@Entity
public class Tag {
    @Id
    private Long id;
    
    @Column(unique = true, nullable = false)
    private String name;
    
    // 인덱스 최적화
    @Column(name = "name", columnDefinition = "VARCHAR(100) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin")
    private String name;
}

// 복잡한 태그 검색 쿼리 최적화 가능
@Query("""
    SELECT DISTINCT p FROM BlogPost p 
    JOIN p.postTags pt 
    JOIN pt.tag t 
    WHERE t.name IN :tagNames 
    AND p.status = 'PUBLISHED'
    ORDER BY p.createdAt DESC
    """)
List<BlogPost> findPublishedPostsByTagNames(List<String> tagNames);

// 📈 Before vs After 측정 대시보드
@Component
public class ElementCollectionMetrics {
    private final MeterRegistry meterRegistry;
    
    // 1. 응답 시간 측정
    @EventListener
    public void measureResponseTime(ElementCollectionOperationEvent event) {
        Timer.Sample sample = Timer.start(meterRegistry);
        
        // 작업 수행 후
        sample.stop(Timer.builder("element.collection.operation")
                .tag("operation", event.getOperation())
                .tag("collection.size", String.valueOf(event.getCollectionSize()))
                .register(meterRegistry));
    }
    
    // 2. 쿼리 수 측정
    @EventListener  
    public void countQueries(HibernateQueryEvent event) {
        Counter.builder("hibernate.query.count")
                .tag("query.type", event.getQueryType())
                .tag("operation", "element.collection")
                .register(meterRegistry)
                .increment();
    }
    
    // 3. 메모리 사용량 추적
    public void trackMemoryUsage() {
        Gauge.builder("element.collection.memory.usage")
                .register(meterRegistry, this, ElementCollectionMetrics::getMemoryUsage);
    }
}

// 📊 실제 개선 결과 예시
/**
 * 개선 전 (@ElementCollection):
 * - 평균 응답시간: 245ms
 * - 평균 쿼리 수: 12개 (DELETE 1 + INSERT N)
 * - 메모리 사용량: 높음 (전체 컬렉션 로딩)
 * - 에러율: 3.2% (동시성 문제)
 * 
 * 개선 후 (@OneToMany):
 * - 평균 응답시간: 18ms (13.6배 개선)
 * - 평균 쿼리 수: 1개 (단일 INSERT/DELETE)
 * - 메모리 사용량: 낮음 (필요시만 로딩)
 * - 에러율: 0.1% (동시성 문제 해결)
 */

// 🎯 코드 리뷰 시간 단축
// Before: @ElementCollection 성능 이슈 리뷰에 평균 30분
// After: 명확한 가이드라인으로 리뷰 시간 5분

// 🎯 버그 수정 시간 단축  
// Before: @ElementCollection 관련 버그 추적에 평균 4시간
// After: 명확한 쿼리 패턴으로 디버깅 시간 30분

// 🎯 신규 기능 개발 속도 향상
// Before: 컬렉션 설계 고민으로 개발 지연
// After: 가이드라인 따라 빠른 의사결정

// @ElementCollection 사용 현황 체크
// 성능 지표 측정 (응답시간, 쿼리수)
// 변경 빈도와 데이터 크기 분석

// Enum + 고정적 → @ElementCollection 유지
// String + 동적 → @OneToMany로 변경
// 대용량 + 복잡 → 별도 테이블 + 배치처리

// 1순위: 성능 문제 있는 곳부터
// 2순위: 새 기능부터 올바른 패턴 적용
// 3순위: 팀 가이드라인 정립