✅ 주인 객체란

@Entity
class User {
	@ManyToOne
	@JoinColumn(name = "team_id")
	var team: Team? = null
}

@Entity
class Team {
	@OneToMany(mappedBy = "team")
	val users: MutableList<User> = mutableListOf()
}

• JPA에서 외래키(FK)를 실제로 DB에 반영하는 쪽을 의미
• @JoinColumn이 선언된 엔티티가 주인 객체
• DB에 FK 값을 저장하려면 주인 객체 필드를 반드시 세팅해야함

✅ 편의 메서드의 역할

• 객체 그래프의 양방향 연관 관계를 일관성이 있게 유지하는 목적
• 주인 객체 여부와는 무관하게 어느 쪽에도 둘 수 있음
• 도메인 의미상 관계를 주도하는 쪽, 혹은 양쪽 모두에 둘 수 있음

✅ 편의 메서드 위치 설계 기준

• 도메인 주도
  • 누가 관계를 주도하는가를 기준으로 한쪽에 둠
  • 예) Order.addItem(item) → Order - OrderItem 관계
• 양쪽 모두 필요한 경우
  • 양쪽에서 관계 변경이 자연스럽게 발생한다면 양쪽에 둠
  • 서로 호출하게 하여 일관성 유지
• 실수 방지
  • FK 세팅을 빼먹을 가능성이 있다면 양쪽에 두는 것도 안전
  • 단, 무한루프를 방지하기 위한 조건 체크 필요

✅ FK 세팅 로직의 위치 설계

• 방식1) Team이 직접 FK 세팅

  @Entity
  class Team {
  	@OneToMany(mappedBy = "team", cascade = [Cascade.ALL], orphanRemoval = true)
  	val users: MutableList<User> = mutableListOf()
  	
  	fun addUser(user) {
  		users.add(user)
  		user.team = this
  	}
  }
  
  @Entity
  class User {
  	@ManyToOne
  	@JoinColumn(name = "team_id")
  	var team: Team? = null
  }
  

  • 직관적이고 간단함
  • 하지만 다른 엔티티와 관계를 맺을 경우 FK 세팅 로직이 중복될 가능성

• 방식2) 주인 객체에만 FK 세팅 두고 호출

  @Entity
  class Team {
  	@OneToMany(mappedBy = "team", cascade = [CascadeType.ALL], orphanRemoval = true)
  	val users: MutableList<User> = mutableListOf()
  	
  	fun addUser(user) {
  		users.add(user)
  		user.changeTeam(this)
  	}
  }
  
  @Entity
  class User {
  	@ManyToOne
  	@JoinColumn(name = "team_id")
  	var team: Team? = null
  	
  	fun changeTeam(team) {
  		this.team = team
  	}
  }
  

  • FK 변경 로직이 한 클래스에만 존재하여 중복 최소화
  • 다른 엔티티와 관계가 늘어나도 유지보수 용이

• 두 방식의 비교

  구분	Team이 직접 FK 세팅	주인 객체(User)에서 FK 세팅
  코드 간결성	✅ 직관적, 짧음	⭕ 약간 길어지지만 크게 차이 없음
  중복 방지	❌ 다른 엔티티에서 FK 세팅 로직 중복 발생	✅ FK 변경 로직 한 곳(User)에서만 관리
  유지보수성	❌ FK 변경 규칙 수정 시 모든 호출부 수정 필요	✅ 주인 객체 메서드만 수정하면 전역 적용
  도메인 의미 반영	⭕ "팀이 멤버를 모은다" 표현 자연스러움	⭕ "팀이 멤버를 모은다" + 주인 객체 규칙 준수
  확장성	❌ 관계 늘어나면 중복 폭발	✅ 확장 시에도 변경 최소화