05. 순환 참조

순환 참조는 의존 관계에 사이클이 생기는 상황으로 대표적으로 객체가 서로 양방향 참조를 하는 상황이 있다.

 

@Data
class Team {

	private long id;
	private String name;
	private List<Member> members;
}

@Data
class Member {

	private long id;
	private String name;
	private Team myTeam;
}

@Data
@NoArgsConstructor
@Entity(name = "team")
class TeamJpaEntity {

	@Id
	private String id;
	@Column
	private String name;
	@OneToMany(mappedBy = "myTeam")
	private List<MemberJpaEntity> members;
}

@Data
@NoArgsConstructor
@Entity(name = "member")
class MemberJpaEntity {

	@Id
	private String id;
	@Column
	private String name;
	@ManyToOne
	@JoinColumn(name = "my_team_id")
	private TeamJpaEntity myTeam;
}

@Service
class TeamService {

	@Autowired
	private MemberService memberService;
	
	...
}

@Service
class MemberService {

	@Autowired
	private TeamService teamService;
	
	...
}

 

JPA를 사용할 때 테이블을 토대로 엔티티를 만들다보면 두 번째 코드처럼 외래키를 양방향 매핑으로 작성하곤 했는데 이는 순환 참조에 해당하는 것이다!

 

스프링을 사용하면서 이러한 문제에 대해서 고민해본 적이 없었는데, 이렇게 코드를 작성하는 것 자체가 순환 참조의 위험성을 내포하고 있는 행위였다.

 

순환 참조는 소프트웨어 설계에서 피해야 하는 대표적인 안티패턴이다.

 

순환 참조의 문제점

앞선 SOLID 글에서 순환 참조는 의존성 전이 문제를 가지고 있었다. 이외에도 여러가지 문제점이 있다.

 

무한 루프

서로 양방향 참조를 하고 있으면 서로의 메소드를 호출할 수 있는데, 이때 무한 루프에 빠지게 된다. 근데, 이렇게 간단한 문제면 개발자가 조심하면 될 거 같다. 그러나 예상치 못한 곳에서 발생하기도 한다.

Team developerGroup = new Team(1, "developerGroup", new ArrayList<>());
developerGroup.getMembers().add(new Member(1, "foobar", developerGroup));
developerGroup.getMembers().add(new Member(2, "helloworld", developerGroup));

ObjectMapper objectMapper = new ObjectMapper();
String result = objectMapper.writeValueAsString(developerGroup);
System.out.println(result);

 

위의 예제는 아까 상호 참조가 있는 Team과 Member 객체를 활용한 예제이다. Team 객체는 Member 객체를 넣어 JSON 문자열로 변환한다.

 

 

Team, Member는 서로 메소드를 호출하는 코드도 없음에도 무한루프를 만들어 오류가 발생한다.

 

시스템 복잡도

조금 더 실무적인 문제.

 

‘팀 내 모든 팀원들의 월급을 합산해달라!’ 라는 요구사항이 있을 때 아래와 같이 코드를 작성할 수도 있게 되는 문제

@Data
class Team {

	private long id;
	private String name;
	private List<Member> members;
}

@Data
class Member {

	private long id;
	private String name;
	private Team myTeam;
	private int salary;
	
	// 팀내 누군가 팀원 모두의 월급에 접근한다.
	// ,,?
	public int calculateTeamMemberTotalSalary() {
		int result = 0;
		for (Member member : myTeam.getMembers()) {
			result += member.salary;
		}
		
		return result;
}

이러한 순환 참조로 인한 논리적 오류도 순환 참조를 없애서 해결할 수 있다.

// --- case 1
@Data
class Team {

	private long id;
	private String name;
	private List<Member> members;
}

@Data
class Member {

	private long id;
	private String name;
	private long myTeam;
	private int salary;
}
// ------------------

// --- case 2
@Data
class Team {

	private long id;
	private String name;
	// private List<Member> members;
}

@Data
class Member {

	private long id;
	private String name;
	private Team myTeam;
	private int salary;
}
// ------------------

 

case1과 case2의 코드를 보면 서로의 순환 참조를 없애버렸다. 이렇게 함으로 case1의 경우 자연스레 Team 클래스 내에 위 요구사항을 구현해야겠다고 생각하게 되고, case2의 경우는 Service 객체를 두어 팀별로 Member에 접근하여 각각 멤버 별로 급여를 받아올 수 있다.

 

가능한 한 도메인 모델들에 단일 진입점을 만들어 필요한 객체가 있을 때 단방향으로 접근하도록 만들자.

 

메모리 누수 - 마크 앤 스윕 알고리즘

객체 참조 횟수가 0보다 크면 가비지 컬렉션이 삭제 대상으로 인식하지 못해 메모리 누수가 발생한다고 일반적으로 알려져있다. 하지만, 실제로는 그렇지 않다고 한다.

 

mark-and-sweep 이라는 알고리즘으로 동작해 루트 노드(전역 변수, 스택 변수 등)에서 접근하지 못하면 삭제 대상으로 보고 삭제하기 때문이다.

 

순환 참조 해결법

확실한 방법은 순환 참조를 만들지 말자.

 

불필요한 참조 제거 - 양방향 참조가 꼭 필요한지 고민하기

@Data
@NoArgsConstructor
@Entity(name = "team")
class TeamJpaEntity {

	@Id
	private String id;
	@Column
	private String name;
	// 꼭 필요한 코드일지?
	@OneToMany(mappedBy = "myTeam")
	private List<MemberJpaEntity> members;
}

@Data
@NoArgsConstructor
@Entity(name = "member")
class MemberJpaEntity {

	@Id
	private String id;
	@Column
	private String name;
	@ManyToOne
	@JoinColumn(name = "my_team_id")
	private TeamJpaEntity myTeam;
}

 

이러한 양방향 참조가 꼭 필요없다. 사실 teamId를 가지고 member를 식별하여 팀 별 멤버 리스트를 가져올 수 있다.

 

간접 참조 활용 - 참조를 없애고 식별자를 두자

@Data
@NoArgsConstructor
@Entity(name = "team")
class TeamJpaEntity {

	@Id
	private String id;
	@Column
	private String name;
	@OneToMany(mappedBy = "myTeam")
	private List<MemberJpaEntity> members;
}

@Data
@NoArgsConstructor
@Entity(name = "member")
class MemberJpaEntity {

	@Id
	private String id;
	@Column
	private String name;
	@ManyToOne
	@JoinColumn(name = "my_team_id")
	private long myTeamId;
}

 

시스템 복잡도를 해결하기 위한 case1, case2 코드와 유사하다.

 

공통 컴포넌트 분리 - 순환 코드를 추출해버리자

 

양쪽 서비스에 있던 공통 기능을 하나의 컴포넌트로 분리해버리는 것이다. 그리고 양쪽이 공통 컴포넌트에 의존하도록 바꾼다. 이러한 방식을 통해 단일 책임 원칙을 더욱 준수하게 된다.

 

이벤트 기반 시스템 사용 - 이벤트 큐를 구독하도록 설계를 변경하자

1. 시스템에서 사용할 중앙 큐를 만든다.
2. 필요에 따라 컴포넌트들이 중앙 큐를 구독하게 한다.
3. 컴포넌트들은 수행 중 다른 컴포넌트에 시켜야 할 일이 있으면 큐에 이벤트를 발행한다.
4. 이벤트가 발행되면 큐를 구독하고 있는 컴포넌트들이 반응한다.
5. 컴포넌트는 이벤트를 확인하고 자신이 처리해야 할 이벤트이면 이를 처리한다.
6. 컴포넌트들은 자신이 처리하지 않아도 되는 이벤트라면 무시한다.

컴포넌트들이 서로 상호 의존하지 않고 이벤트로 이뤄지게 만든다. 이러한 이벤트 방식은 스프링의 ApplicationEvent, ApplicationEventPublisher, EventListener 로 구현할 수 있다. 꼭, 스프링 아니어도 중앙화된 큐만 있어도 된다.

 

이러한 방식의 프로그래밍을 이벤트 기반 프로그래밍(EDP; Event-driven Programming)이라고 한다.

 

양방향 매핑

도메인 설계를 하다가 어쩔 수 없이 나오는 순환 참조에만 사용하자.

 

도메인 객체, 영속성 객체를 나누어 도메인 객체는 순환 참조가 이루어지지 않게하고 영속성 객체가 양방향 매핑을 하는 것은 모범 사례가 될 순 있으나 JPA 엔티티만 가지고 양방향 매핑은 모범 사례가 되기 어렵다.

 

순환 참조를 만들지 않으면 ‘연관관계의 주인’ 같은 개념이 필요 없어짐.

 

상위 수준의 순환 참조

객체 간 순환 참조를 넘어 패키지, 시스템 수준의 순환 참조는 더 큰 문제다.

 

API 시스템에 직접 의존한 상황, 시스템을 직접 호출하는 상황, 패키지가 독립이지 못한 상황 등 순환 참조를 피하자.