불변객체로 만드는 것이 항상 좋을까? - Value Object vs Reference Object

🌱 들어가기 전

이번 자동차 경주 미션을 진행하면서 레벨 1 때 했던 코드를 리팩터링을 하다 보니 페어와 '불변 객체로 만드는 게 어떠냐는 의견을 받았다.

당시 레벨 1 미션을 진행할 때는 불변 객체의 정의에 대해서 잘 알지 못했었고, 미션을 진행하면서 불변으로 만드는 게 여러 가지 이점이 있다는 걸 공부했었기 때문에 별 생각 없이 그렇게 진행하고자 했다.

public class Car {

    private static final int CAR_FORWARD_NUMBER = 4;

    private final CarName name;
    private final CarPosition position;

    ...

    public Car move(final int power) {
        if (power >= CAR_FORWARD_NUMBER) {
            final CarPosition newPosition = position.addPosition();
            return new Car(name, newPosition);
        }
        return new Car(name, position);
    }

   ...
}

그래서 move의 반환값도 새로운 Car를 생성해서 반환하게 된다. (Cars, CarName, CarPosition 모두 불변으로 만들었었다.)

 

하지만, 리뷰어님은 다음과 같은 피드백을 주셨다.

Car를 수학적인 값을 나타내는 오브젝트로 표현하고자 했다...?

처음에는 이 리뷰를 받고 제대로 이해하지 못해서 고생했다.

하지만 Value Object와 Reference Object에 대해 공부하다 보니 이게 어떤 리뷰인지 알게 되었는데, 이에 대해서 간단하게 포스팅을 해보고자 한다.

 

---

✔️ Value Object & Reference Object

프로그램을 가장 훌륭하게 작성하는 방법은 상태가 변경되는 오브젝트들과 수학적인 값을 나타내는 오브젝트들의 조합으로 표현하는 것이다. - 칸트 백

지금부터 우리는 '자동차'라는 객체를 설계하고자 한다.

자동차라는 객체는 '이름', '위치'라는 속성을 가지고 있고, 각각 역시 CarName, CarPosition이라는 객체로 표현하고 있다.

위와 같이 꽤나 귀여운 자동차를 생성하였다. 해당 자동차의 이름 (CarName)은 '져니', 위치 (CarPosition)은 0이다.

미션의 요구사항처럼 자동차 경주를 열고자 한다. 그렇다면 여러 개의 자동차가 추가될 것이다.

져니, 져니B, 져니C라는 자동차가 생겼다.

우리의 시스템에서 '져니'라는 자동차는 3개가 되는 것일까? 아니다.

'져니'라는 자동차는 오직 우리의 시스템에서 유일하게 식별 가능한 객체가 되는 것이며, 나는 이러한 도메인을 'Car'를 통해 표현하고 있다.

그리고, 우리는 이제부터 이것을 'Reference Object'라고 표현할 것이다.

 

그렇다면, 자동차 '져니'를 움직여보자.

자동차 '져니'의 위치는 변했다. 그리고, 그에 해당하는 위치값이 0에서 10으로 증가하였다.

하지만 위치가 10만큼 이동했다고 해서 그 자동차는 '져니'라는 자동차가 아니게 되는 것일까?

 

자동차로 비유하지 않아도, 실세계에서 사람을 예시로 들어보자.

내 나이가 23살에서 24살으로 변했더라도, 나는 그저 나일뿐이다.

내가 23살인지 24살인지는 나를 결정하는데 아무런 영향도 주지 않는다는 것이다.

 

우리의 자동차 시스템에서는 위치 값을 계속 추적할 필요가 없다. 그저 위치를 표현할 '값'일뿐이다.

그리고 우리는 이러한 것을 'Value Object'라고 말할 것이다.

 

---

✔️ 동일성 (Identity)와 동등성 (Equality)

Reference Object와 Value Object의 동일성과 동등성에 대해서 생각해보자.

 

우선, 기본적으로 동일성은 두 변수가 완전히 동일하다는 것을 의미한다.

그리고, 완전히 동일하다는 것은 메모리상에서 곧 동일한 객체를 가리키고 있는 것이다.

완전히 동일하기 때문에 ==을 통해서 비교 연산이 가능하다.

 

반면에 동등성의 경우, 두 개의 변수가 동일한 정보를 가지고 있는 것을 의미한다.

메모리상에서 동일한 객체를 가리키고 있지 않더라도, 각 객체의 내용이 동일하다면 동등하다.

우리는 이러한 동등성은 equals를 통해서 비교할 수 있다.

 

객체지향 시스템에서 객체에게 고유한 식별자를 부여하는 것이 일반적이다.

그리고, 우리는 이러한 식별자로 메모리 상의 주소를 사용할 수 있다.

즉, 객체를 구분하는 조건으로 메모리 상의 주소를 사용하자는 것이다.

 

그렇다면, 우리는 앞서서 Reference Object의 경우 시스템에서 유일하게 존재하고 있다고 했다.

유일하게 존재하기 때문에, 메모리 상에서도 오직 1개만 존재할 것이다.

그렇기 때문에 메모리 주소를 비교하는, 동일성을 비교할 수 있는, ==을 통해 비교를 할 수 있다.

처음 언급했던 Car 도메인이 여기에 해당한다. '져니' 자동차는 유일하기 때문에, Car는 곧 ==을 통해 비교가 되는 것이다.

 

반면에, Value Object의 경우 유일하게 존재할 필요가 없다.

'위치 0'을 나타내는 CarPosition만 생각하더라도 '져니', '져니B', '져니C'가 가지고 있다.

그렇기 때문에 CarPosition의 경우 동일한 값을 가져 동등할 수 있지만, 동일할 필요는 없어진다.

그래서 ==을 통해 비교하는 게 아닌, equals를 재정의하여 테스트해야 한다.

 

자, 이제 리뷰를 다시 보자.

Car를 불변 객체로 만들어 주시니, 이젠 동등성으로 비교해야 하는 객체처럼 보이네요.

불변 객체로 만들었기 때문에 위치가 변할 때마다 새로운 Car 객체가 생성되고 있다.

그래서 Car는 Reference Object가 아닌, Value Object였고, 등성으로 비교하는 객체처럼 보인다고 말씀해 주신 거였다.

 

---

✔️ 불변 객체와 Value, Reference Object

Value Object는 불변으로 만들어야 한다. 왜일까?

불변으로 만들면 기본적으로 동일한 객체임에도 다른 변수로 참조했을 때, 다른 변수가 상태가 변경되었을 때 만들어지는 버그를 줄일 수 있다. (다른 객체의 상태가 변경되었음을 알지 못하는 상태 - 버그를 잡기 어려워진다.)

 

Value Object는 만약 내부의 상태가 변경된다면, 기존 객체의 상태를 변경하지 않고, 새로운 객체를 생성해야 한다.

왼쪽처럼 내부의 값을 변경하는 게 아니라, 오른쪽처럼 완전히 새로운 객체를 반환하라는 것이다.

내부의 값이 변했을 때 굳이 기존의 객체를 참조해야 할까? 아무 의미가 없다.

굳이 위에서 언급한 버그 (보통 aliasing 문제라고 한다)의 위험성을 안고 갈 만큼 동일하게 가지고 있을 필요가 없는 것이다.

또한, 새로운 객체를 만들어 반환한다면 어차피 GC 대상이 될 것이다. 메모리적으로 생각해봤을 때도 부담이 없는 것이다.

 

Value Object의 경우 상태를 추적할 필요가 없기 때문에 비교적 변수를 접근할 때 안전하게 접근할 수 있다.

또한, 객체의 생명 주기 없이 내부의 값이 동일할 때까지만 유효하기 때문에 오류의 위험성도 없다.

 

하지만, Reference Object는 일반적으로 불변 객체가 아니다.

'Car'는 위치가 달라질 수 있다. Car는 움직일 수 있기 때문에, 계속해서 상태는 변경될 것이라는 것이다.

또한, 자동차 '져니'에 대해 추적하기 위해서, 항상 동일한 '져니' 객체가 시스템에서 전달되어야 한다.

시스템이 항상 동일한 자동차 객체를 공유하기 때문에, 별칭 문제는 피할 수가 없다.

이를 위해서 항상 Reference Object의 변경 사항을 추적해야 한다.

 

물론! Reference Object도 불변 객체로 만들 수 있다면 만들어도 좋다. (요구사항에 달려있는 것이다)

다만, 불변 객체로 만들기 위해서는 해당 객체의 내부 상태가 계속해서 변경되지 않을 경우에 하도록 하자.

미션 요구사항처럼 자동차 '져니'의 위치가 계속 바뀐다면, 불변 객체로 만드는 것이 개념적으로 이상하다. (일관성도 깨진다)

---

사실, 이럼에도 불변 객체가 더 좋다는 의견이 있을 것이다.

불변 객체가 주는 장점이 상당히 명확하기 때문이다.

하지만, 객체의 의미론적 설계로 봤을 때도 과연 좋은지... 현실세계를 잘 모델링한 것인가?의 관점이라면 아니라고 생각된다.

앞으로 미션하면서 무작정 불변으로 만들지 말고, 한 번 이러한 점들에 대해서 잘 따져봐야겠다...

 

Reference Object를 식별함으로서 시스템의 핵심 개념들의 생명 주기에 초점을 맞출 수 있다.
Value Object를 식별함으로서 도메인의 일부지만 중요하지 않은 개념들을 걸러낼 수 있다.