현대 웹 애플리케이션 설계에서의 테이블 연관관계 vs 이벤트 기반 아키텍처: 종합적 트레이드오프 분석

서론

현대 소프트웨어 개발에서 데이터 모델링과 아키텍처 설계는 애플리케이션의 성능, 확장성, 유지보수성을 결정하는 핵심 요소입니다. 전통적으로 객체-관계 매핑(ORM) 프레임워크를 활용한 테이블 연관관계 설계가 주류였으나, 최근 대규모 분산 시스템의 요구사항 증가와 함께 이벤트 기반 아키텍처(Event-Driven Architecture)가 주목받고 있습니다.

 

본 글에서는 실무 경험과 이론적 분석을 바탕으로, 두 접근법의 기술적 트레이드오프를 심층적으로 분석하고, 각 방식이 적합한 상황과 의사결정 기준을 제시하고자 합니다.

---

1. 기술적 배경 및 현황 분석

1.1 테이블 연관관계 방식의 이론적 기반

테이블 연관관계 방식은 Edgar F. Codd의 관계형 모델(1970)을 기반으로 하며, 객체지향 프로그래밍과 관계형 데이터베이스 간의 임피던스 불일치(Impedance Mismatch) 문제를 해결하기 위해 발전되었습니다.

@Entity
public class Order {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    
    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "customer_id")
    private Customer customer;
    
    @OneToMany(mappedBy = "order", cascade = CascadeType.ALL, fetch = FetchType.LAZY)
    private List<OrderItem> orderItems = new ArrayList<>();
}

이 방식의 핵심은 객체 그래프 탐색(Object Graph Navigation)을 통한 직관적인 데이터 접근이며, JPA(Java Persistence API)의 영속성 컨텍스트가 제공하는 1차 캐시, 지연 로딩, 변경 감지 등의 기능을 활용할 수 있습니다.

 

1.2 이벤트 기반 아키텍처의 이론적 기반

이벤트 기반 아키텍처는 CQRS(Command Query Responsibility Segregation) 패턴과 이벤트 소싱(Event Sourcing) 개념을 기반으로 합니다. Martin Fowler와 Greg Young이 체계화한 이 패턴은 명령(Command)과 조회(Query)의 책임을 분리하여 각각을 최적화하는 것을 목표로 합니다.

// Command Model
@Entity
@Table(name = "members")
public class Member {
    @Id
    private Long id;
    private String name;
    private String email;
    
    public void updateName(String name) {
        this.name = name;
        // 도메인 이벤트 발행
        DomainEvents.publish(new MemberNameUpdatedEvent(this.id, name));
    }
}

// Query Model (이벤트로 구성됨)
@Entity
@Table(name = "user_profiles_view")
public class UserProfileView {
    @Id
    private Long id;
    private Long userId;
    private String displayName;    // Member 도메인에서 복제
    private String bio;           // Profile 도메인에서 복제
    private Integer followersCount; // Follow 도메인에서 복제
}

---

2. 개발 생산성 및 유지보수성 분석

2.1 초기 개발 복잡성

2.1.1 테이블 연관관계 방식

장점: 직관적이고 빠른 프로토타이핑

// 간단한 엔티티 설계로 빠른 개발 가능
@Entity
public class Order {
    @ManyToOne
    private Customer customer;
    
    @OneToMany(mappedBy = "order")
    private List<OrderItem> orderItems;
}

// 객체 그래프 탐색으로 직관적 접근
public String getCustomerName(Long orderId) {
    Order order = orderRepository.findById(orderId);
    return order.getCustomer().getName(); // 한 줄로 완성
}

 

단점: 숨겨진 복잡성

// 실제 프로덕션에서는 다양한 문제 해결 필요
@Entity
public class Order {
    @ManyToOne(fetch = FetchType.LAZY) // Lazy vs Eager 선택 고민
    @JoinColumn(name = "customer_id")
    private Customer customer;
    
    @OneToMany(mappedBy = "order", 
               cascade = CascadeType.ALL, // 영속성 전이 설정 복잡
               orphanRemoval = true,
               fetch = FetchType.LAZY)
    private List<OrderItem> orderItems;
}

// 성능 최적화를 위한 복잡한 쿼리 작성 필요
@Query("SELECT DISTINCT o FROM Order o " +
       "LEFT JOIN FETCH o.customer c " +
       "LEFT JOIN FETCH o.orderItems oi " +
       "LEFT JOIN FETCH oi.product p " +
       "WHERE o.orderDate BETWEEN :start AND :end")
List<Order> findOrdersWithDetails(@Param("start") LocalDate start, 
                                 @Param("end") LocalDate end);

 

2.1.2 이벤트 기반 방식

 

단점: 높은 초기 진입 장벽

// 초기 설정의 복잡성
@Entity
public class Member {
    // Command Model
}

@Entity
public class UserProfileView {
    // Query Model (별도 설계 필요)
}

@Component
public class UserProfileEventListener {
    // 이벤트 처리 로직 구현 필요
    @EventListener
    @Transactional
    public void handleMemberUpdated(MemberUpdatedEvent event) {
        // 동기화 로직 구현
    }
}

 

장점: 일관된 복잡성과 예측 가능한 성능

// 한번 구조가 잡히면 추가 기능 개발이 일관됨
@Service
public class UserProfileQueryService {
    
    public UserProfileDto getUserProfile(Long userId) {
        // 항상 동일한 패턴
        UserProfileView view = userProfileViewRepository.findByUserId(userId);
        return new UserProfileDto(view);
    }
    
    public List<UserProfileDto> searchUsers(String keyword) {
        // 복잡한 JOIN 없이 단순 조회
        return userProfileViewRepository.findByDisplayNameContaining(keyword)
            .stream()
            .map(UserProfileDto::new)
            .collect(toList());
    }
}

---

2.2 장기적 유지보수성

2.2.1 요구사항 변경 대응력

시나리오: "주문 목록에 고객 VIP 등급과 할인율을 추가로 표시해주세요"

테이블 연관관계 방식의 변경 과정:

// 1단계: Customer 엔티티 수정
@Entity
public class Customer {
    @Enumerated(EnumType.STRING)
    private VipGrade vipGrade; // 새 필드 추가
    
    public double getDiscountRate() {
        return vipGrade.getDiscountRate();
    }
}

// 2단계: 기존 쿼리들 모두 수정 (Breaking Change)
@Query("SELECT new OrderDto(o.orderNumber, c.name, c.vipGrade, c.vipGrade.discountRate) " +
       "FROM Order o JOIN Customer c ON o.customer.id = c.id " +
       "WHERE o.orderDate >= :startDate")
List<OrderDto> findOrdersWithCustomerGrade(@Param("startDate") LocalDate startDate);

// 3단계: DTO 클래스 수정 (기존 API 영향)
public class OrderDto {
    private String orderNumber;
    private String customerName;
    private VipGrade vipGrade;    // 새 필드
    private Double discountRate;  // 새 필드
    
    // 기존 생성자들 수정 필요, 하위 호환성 깨짐
}

// 영향 범위: 5개 레이어, 기존 기능 회귀 가능성 높음

 

이벤트 기반 방식의 변경 과정:

// 1단계: Customer 도메인에서 이벤트 추가
public class CustomerVipGradeUpdatedEvent {
    private Long customerId;
    private VipGrade vipGrade;
    private Double discountRate;
}

// 2단계: Query Model에 필드 추가 (기존 코드 무영향)
@Entity
public class OrderView {
    // 기존 필드들...
    private VipGrade customerVipGrade;  // 새 필드
    private Double customerDiscountRate; // 새 필드
}

// 3단계: 이벤트 리스너 추가
@EventListener
public void handleCustomerVipGradeUpdated(CustomerVipGradeUpdatedEvent event) {
    List<OrderView> orderViews = orderViewRepository.findByCustomerId(event.getCustomerId());
    orderViews.forEach(view -> {
        view.updateCustomerVipGrade(event.getVipGrade());
        view.updateCustomerDiscountRate(event.getDiscountRate());
    });
    orderViewRepository.saveAll(orderViews);
}

// 기존 조회 로직은 전혀 수정하지 않아도 새로운 데이터 포함
// 영향 범위: 최소화, 기존 기능 안전성 보장

---

3. 조직적 관점에서의 트레이드오프

3.1 팀 협업 및 개발 프로세스

3.1.1 테이블 연관관계 방식의 팀 협업

 

단점: 강한 결합으로 인한 팀 간 의존성

// 상황: 주문팀, 고객팀, 상품팀이 함께 개발
@Entity
public class Order {
    @ManyToOne
    private Customer customer;  // 고객팀 엔티티에 의존
    
    @ManyToOne  
    private Product product;    // 상품팀 엔티티에 의존
}

// 문제점들:
// 1. 고객팀이 Customer 엔티티를 수정하면 주문팀 코드 영향
// 2. 상품팀이 Product 테이블 스키마 변경 시 주문팀 빌드 실패
// 3. 세 팀이 모두 같은 데이터베이스 스키마 공유 필요
// 4. 테스트 시에도 모든 팀의 테이블과 데이터 필요
// 5. 배포 시 순서 조율 필요 (의존성 때문에)

 

테스트 복잡성:

@Test
public class OrderServiceTest {
    
    @Test
    public void 주문생성테스트() {
        // 다른 팀의 엔티티들도 모두 준비해야 함
        Customer customer = Customer.builder()
            .name("홍길동")
            .email("hong@email.com")
            .vipGrade(VipGrade.GOLD)
            .build();
        customerRepository.save(customer);
        
        Product product = Product.builder()
            .name("테스트 상품")
            .price(BigDecimal.valueOf(10000))
            .category(productCategoryRepository.save(new Category("전자제품")))
            .build();
        productRepository.save(product);
        
        // 실제 테스트하려는 로직보다 설정이 더 복잡
        Order order = new Order(customer, product, 2);
        orderRepository.save(order);
        
        assertThat(order.getTotalAmount()).isEqualTo(BigDecimal.valueOf(20000));
    }
}

 

3.1.2 이벤트 기반 방식의 팀 협업

 

장점: 느슨한 결합으로 인한 팀 독립성

// 각 팀이 완전히 독립적으로 개발 가능

// 주문팀 (독립적)
@Entity
public class Order {
    private Long customerId;    // 단순 ID 참조
    private Long productId;     // 단순 ID 참조
}

@Entity  
public class OrderView {
    private String customerName;    // 고객팀 이벤트에서 복제
    private String productName;     // 상품팀 이벤트에서 복제
    private VipGrade customerGrade; // 고객팀 이벤트에서 복제
}

// 장점들:
// 1. 고객팀의 Customer 변경이 주문팀에 직접적 영향 없음
// 2. 각 팀이 독립적인 데이터베이스 사용 가능
// 3. 다른 팀 코드 없이도 단위 테스트 가능
// 4. 배포 순서 무관 (이벤트 버전 관리로 호환성 유지)
// 5. 각 팀이 최적화된 기술 스택 선택 가능

 

단순한 테스트:

@Test
public class OrderServiceTest {
    
    @Test
    public void 주문생성테스트() {
        // 단순한 ID만 있으면 테스트 가능
        Order order = new Order(1L, 2L, 2);  // customerId, productId, quantity
        orderRepository.save(order);
        
        assertThat(order.getCustomerId()).isEqualTo(1L);
        assertThat(order.getProductId()).isEqualTo(2L);
        assertThat(order.getQuantity()).isEqualTo(2);
        
        // 다른 팀의 복잡한 엔티티 생성 불필요
        // 테스트가 빠르고 안정적
    }
}

---

3.2 확장성 관점

3.2.1 수평적 확장 (Scale-out)

테이블 연관관계 방식의 한계:

// 모든 도메인이 하나의 데이터베이스에 강하게 결합
// 특정 테이블의 부하가 전체 시스템에 영향
// 샤딩(Sharding) 적용 시 연관관계로 인한 제약 발생

@Entity
public class Order {
    @ManyToOne
    private Customer customer;  // Customer와 Order가 다른 샤드에 있으면 JOIN 불가
}

// 마이크로서비스로 분리 시 복잡한 분산 트랜잭션 필요

 

이벤트 기반 방식의 유연성:

// 각 도메인을 독립적인 서비스로 분리 가능
// 도메인별 최적화된 데이터베이스 선택 가능
// 수평적 확장이 자연스럽게 가능

// User Service (독립적 확장)
@Service
public class UserService {
    private final UserRepository userRepository; // User 전용 DB
}

// Order Service (독립적 확장)  
@Service
public class OrderService {
    private final OrderRepository orderRepository; // Order 전용 DB
}

// Profile Service (독립적 확장, 읽기 최적화)
@Service
public class ProfileQueryService {
    private final UserProfileViewRepository repository; // Read-only DB (캐시/복제본)
}

---

4. 데이터 일관성 및 트랜잭션 관리

4.1 ACID 속성과 데이터 일관성

4.1.1 테이블 연관관계 방식

 

장점: 강한 일관성 보장

@Service
@Transactional
public class OrderService {
    
    public void createOrder(CreateOrderCommand command) {
        Customer customer = customerRepository.findById(command.getCustomerId())
            .orElseThrow(() -> new CustomerNotFoundException());
            
        Product product = productRepository.findById(command.getProductId())
            .orElseThrow(() -> new ProductNotFoundException());
            
        // 재고 확인 및 차감
        product.decreaseStock(command.getQuantity());
        
        // 주문 생성
        Order order = new Order(customer, product, command.getQuantity());
        orderRepository.save(order);
        
        // 모든 변경사항이 하나의 트랜잭션에서 원자적으로 처리
        // 성공하면 모두 커밋, 실패하면 모두 롤백
    }
}

 

단점: 분산 환경에서의 제약

// 여러 마이크로서비스에 걸친 트랜잭션은 복잡한 분산 트랜잭션 필요
// 2PC(Two-Phase Commit) 프로토콜의 복잡성과 성능 저하
// 서비스 간 강한 결합으로 인한 장애 전파

 

4.1.2 이벤트 기반 방식

 

단점: 최종 일관성(Eventual Consistency)

@Service
@Transactional
public class OrderService {
    
    public void createOrder(CreateOrderCommand command) {
        // 1. 주문 생성 (로컬 트랜잭션)
        Order order = new Order(command.getCustomerId(), command.getProductId());
        orderRepository.save(order);
        
        // 2. 이벤트 발행
        eventPublisher.publishEvent(new OrderCreatedEvent(order));
        
        // 3. 다른 도메인의 업데이트는 비동기적으로 처리
        // → 일시적으로 데이터 불일치 가능
    }
}

@EventListener
@Transactional
public void handleOrderCreated(OrderCreatedEvent event) {
    // 재고 차감은 별도 트랜잭션에서 처리
    // 실패 시 보상 트랜잭션(Saga Pattern) 필요
    try {
        productService.decreaseStock(event.getProductId(), event.getQuantity());
    } catch (InsufficientStockException e) {
        // 주문 취소 이벤트 발행
        eventPublisher.publishEvent(new OrderCancelledEvent(event.getOrderId()));
    }
}

 

장점: 시스템 가용성과 확장성

// 부분적 장애가 전체 시스템에 미치는 영향 최소화
// 각 서비스의 독립적 확장 가능
// 비동기 처리를 통한 응답성 향상

@Component
public class OrderViewEventListener {
    
    @EventListener
    @Retryable(maxAttempts = 3, backoff = @Backoff(delay = 1000))
    public void handleOrderCreated(OrderCreatedEvent event) {
        try {
            // Query Model 업데이트
            OrderView orderView = createOrderView(event);
            orderViewRepository.save(orderView);
        } catch (Exception e) {
            // 실패 시 재시도, 최종 실패 시 Dead Letter Queue로 처리
            deadLetterQueueService.send(event);
        }
    }
}

---

5. 기술적 복잡성 비교

5.1 쿼리 복잡성

5.1.1 테이블 연관관계 방식

// 단순해 보이지만 실제로는 복잡한 쿼리 최적화 필요
@Repository
public interface OrderRepository extends JpaRepository<Order, Long> {
    
    // N+1 문제 해결을 위한 복잡한 Fetch Join
    @Query("SELECT DISTINCT o FROM Order o " +
           "LEFT JOIN FETCH o.customer c " +
           "LEFT JOIN FETCH o.orderItems oi " +
           "LEFT JOIN FETCH oi.product p " +
           "WHERE o.orderDate BETWEEN :startDate AND :endDate")
    List<Order> findOrdersWithDetails(@Param("startDate") LocalDate startDate,
                                     @Param("endDate") LocalDate endDate);
    
    // 카테시안 곱 문제로 인한 성능 저하 위험
    // 메모리 사용량 예측 어려움
    // 쿼리 실행 계획의 변동성
}

// 복잡한 조건이 추가될 때마다 쿼리 복잡도 기하급수적 증가
@Query("SELECT o FROM Order o " +
       "JOIN FETCH o.customer c " +
       "JOIN FETCH o.orderItems oi " +
       "JOIN FETCH oi.product p " +
       "JOIN FETCH p.category cat " +
       "WHERE c.vipGrade = :vipGrade " +
       "AND p.category.name = :categoryName " +
       "AND o.orderDate >= :startDate " +
       "AND o.totalAmount >= :minAmount")
List<Order> findComplexOrders(/* 많은 파라미터들 */);

 

5.1.2 이벤트 기반 방식

// 단순하고 예측 가능한 쿼리
@Repository
public interface OrderViewRepository extends JpaRepository<OrderView, Long> {
    
    // 모든 필요한 데이터가 이미 하나의 테이블에 있음
    List<OrderView> findByOrderDateBetween(LocalDate startDate, LocalDate endDate);
    
    List<OrderView> findByCustomerVipGradeAndProductCategoryName(
        VipGrade vipGrade, 
        String categoryName
    );
    
    // 복잡한 조건도 단순한 WHERE 절로 처리
    @Query("SELECT o FROM OrderView o " +
           "WHERE o.customerVipGrade = :vipGrade " +
           "AND o.productCategoryName = :categoryName " +
           "AND o.orderDate >= :startDate " +
           "AND o.totalAmount >= :minAmount")
    List<OrderView> findComplexOrderViews(
        @Param("vipGrade") VipGrade vipGrade,
        @Param("categoryName") String categoryName,
        @Param("startDate") LocalDate startDate,
        @Param("minAmount") BigDecimal minAmount
    );
    
    // JOIN 없음, 성능 예측 가능, 인덱스 최적화 용이
}

---

5.2 캐싱 전략

5.2.1 테이블 연관관계 방식의 캐싱 복잡성

// 복잡한 객체 그래프의 캐싱 전략
@Entity
public class Order {
    @ManyToOne
    private Customer customer;
    
    @OneToMany
    private List<OrderItem> orderItems;
}

// 문제점들:
// 1. 어느 수준까지 캐싱할 것인가? (Order만? Customer까지? OrderItem까지?)
// 2. Customer가 변경되면 관련된 모든 Order 캐시 무효화 필요
// 3. Lazy Loading과 캐시의 상호작용 복잡성
// 4. 2차 캐시(Second Level Cache) 설정의 복잡성

@Cacheable("orders")
public Order findOrderById(Long id) {
    return orderRepository.findById(id); // Customer는 캐시되나? OrderItem은?
}

// 캐시 무효화 전략의 복잡성
@CacheEvict(value = {"orders", "customers", "orderItems"}, allEntries = true)
public void updateCustomer(Customer customer) {
    // 연관된 모든 캐시를 무효화해야 함
}

 

5.2.2 이벤트 기반 방식의 단순한 캐싱

// 단순하고 명확한 캐싱 전략
@Entity
public class OrderView {
    // 모든 필요한 데이터가 하나의 엔티티에 있음
}

@Service
public class OrderQueryService {
    
    @Cacheable("orderViews")
    public OrderViewDto getOrderView(Long orderId) {
        OrderView orderView = orderViewRepository.findById(orderId);
        return new OrderViewDto(orderView);
    }
    
    // 캐시 무효화도 단순
    @CacheEvict("orderViews")
    public void evictOrderView(Long orderId) {
        // 해당 주문 뷰만 무효화하면 됨
    }
}

// 이벤트 기반 캐시 갱신
@EventListener
public void handleOrderUpdated(OrderUpdatedEvent event) {
    // 특정 주문 뷰만 갱신
    cacheManager.evict("orderViews", event.getOrderId());
}

---

6. 실무 적용 가이드라인

6.1 테이블 연관관계 방식이 적합한 경우

// 1. 데이터 일관성이 절대적으로 중요한 도메인 (금융 거래 등)
// 2. 복잡한 트랜잭션 처리가 빈번한 경우
// 3. 팀의 JPA/이벤트 아키텍처 경험이 부족한 경우

@Entity
public class BankTransaction {
    @ManyToOne
    private Account fromAccount;
    
    @ManyToOne
    private Account toAccount;
    
    // 금융 거래는 강한 일관성이 필수
    // 이체 중 시스템 장애 시 원자성 보장 필요
}

@Service
@Transactional
public class BankTransferService {
    
    public void transfer(Long fromAccountId, Long toAccountId, BigDecimal amount) {
        Account fromAccount = accountRepository.findById(fromAccountId);
        Account toAccount = accountRepository.findById(toAccountId);
        
        fromAccount.withdraw(amount);  // 출금
        toAccount.deposit(amount);     // 입금
        
        BankTransaction transaction = new BankTransaction(fromAccount, toAccount, amount);
        transactionRepository.save(transaction);
        
        // 모든 작업이 하나의 트랜잭션에서 처리되어야 함
    }
}

 

6.2 이벤트 기반 방식이 적합한 경우

// 1. 마이크로서비스 아키텍처를 고려하는 경우
// 2. 여러 팀이 독립적으로 개발해야 하는 경우
// 3. 실시간 분석이나 이벤트 스트리밍이 필요한 경우

// 전자상거래, 소셜 미디어, 콘텐츠 플랫폼 등
@Entity
public class UserActivityLog {
    private Long userId;
    private String activityType;
    private Map<String, Object> metadata;
    private LocalDateTime timestamp;
}

@Service
public class UserActivityService {
    
    public void recordActivity(UserActivityCommand command) {
        // 사용자 활동 기록 (높은 처리량 필요)
        UserActivityLog log = new UserActivityLog(command);
        activityLogRepository.save(log);
       
        // 여러 도메인에서 이 이벤트를 구독
       eventPublisher.publishEvent(new UserActivityRecordedEvent(
           command.getUserId(),
           command.getActivityType(),
           command.getMetadata()
       ));
   }
}

// 추천 시스템에서 활용
@EventListener
public void handleUserActivityRecorded(UserActivityRecordedEvent event) {
   userRecommendationService.updateUserPreferences(event);
}

// 분석 시스템에서 활용
@EventListener
public void handleUserActivityRecorded(UserActivityRecordedEvent event) {
   analyticsService.recordUserBehavior(event);
}

// 알림 시스템에서 활용
@EventListener
public void handleUserActivityRecorded(UserActivityRecordedEvent event) {
   if (event.getActivityType().equals("PURCHASE")) {
       notificationService.sendPurchaseConfirmation(event.getUserId());
   }
}

 

6.3 하이브리드 접근법

실무에서는 프로젝트의 다양한 영역에 따라 두 방식을 혼합하여 사용하는 것이 효과적입니다.

// 핵심 비즈니스 도메인: 이벤트 기반
@Entity
@Table(name = "user_profiles_view")
public class UserProfileView {
    private Long userId;
    private String displayName;
    private Integer followersCount;
    private Integer postsCount;
    // 높은 조회 빈도, 성능 중요
}

// 마스터 데이터: 연관관계 방식
@Entity
public class Category {
    @OneToMany(mappedBy = "category")
    private List<Product> products;
    // 변경 빈도 낮음, 관리 편의성 중요
}

// 설정 데이터: 연관관계 방식
@Entity
public class UserSettings {
    @OneToOne
    @JoinColumn(name = "user_id")
    private User user;
    
    private Boolean emailNotificationEnabled;
    private String language;
    private String timezone;
    // 단순한 일대일 관계, 복잡성 낮음
}

// 트랜잭션 데이터: 상황에 따라 선택
@Entity
public class Order {
    private Long userId;  // 이벤트 기반 (성능 중요)
    
    @OneToMany(mappedBy = "order", cascade = CascadeType.ALL)
    private List<OrderItem> orderItems;  // 연관관계 (강한 응집성)
}

---

7. 마무리

 

현대 소프트웨어 개발에서 완벽한 코드는 없다고 생각합니다. 테이블 연관관계와 이벤트 기반 아키텍처 모두 각각의 장단점을 가지고 있으며, 상황에 따른 적절한 선택이 중요합니다.

 

하지만, "왜 중요 도메인끼리 테이블 연관관계를 맺어야 하는가?"라는 근본적인 질문에 대한 답은 명확합니다. 실제로는 맺지 않는 것이 더 좋은 경우가 많습니다. 연관관계는 개발 초기의 편의성을 제공하지만, 시스템이 성장하면서 오히려 제약이 되는 경우가 빈번합니다. '확장성' 과 '추상화' 에 대한 깊은 고민이 필요합니다.

 

따라서 도메인의 중요도와 비즈니스 임팩트가 클수록, 이벤트 기반 아키텍처를 통한 느슨한 결합을 고려해야 하며, 이는 Netflix, Uber, Amazon과 같은 대규모 서비스들이 실제로 채택하고 있는 검증된 접근법입니다.

---