순수 Java 객체 공유와 구현 교체

앞 글의 BoardConfig는 저장소와 해시 어댑터를 필드에서 한 번 만들고 두 서비스에 넘겼습니다. 그런데 같은 구성 객체를 쓴다고 해서 메서드가 돌려주는 객체가 저절로 공유되는 것은 아닙니다. 공유되는지는 객체를 어디서 몇 번 만들고 어떤 참조를 넘겼는지로 정해집니다.

호출마다 새 저장소를 만드는 실패

다음 테스트 전용 구성은 저장소가 필요할 때마다 new MemoryMemberRepository()를 실행합니다. 그래서 회원가입 서비스는 저장소 R#1에 저장하지만, 로그인 서비스는 새로 만든 R#2에서 회원을 찾습니다.

package board;

import board.member.InvalidCredentialsException;
import board.member.LoginService;
import board.member.MemberRegistrationService;
import board.member.MemberRepository;
import board.member.MemoryMemberRepository;
import board.member.PasswordHasher;
import board.member.SignUpCommand;
import board.member.TestPasswordHasher;
import org.junit.jupiter.api.Test;

import static org.assertj.core.api.Assertions.assertThat;
import static org.assertj.core.api.Assertions.assertThatThrownBy;

final class PerCallRepositoryConfigTest {
    @Test
    void 저장소를_호출마다_만들면_가입한_회원을_로그인에서_찾지_못한다() {
        var config = new PerCallRepositoryConfig();

        var registered = config.memberRegistrationService()
                .register(new SignUpCommand(
                        "[email protected]",
                        "회원",
                        "secret-1234"));

        assertThat(registered.id()).isPositive();
        assertThatThrownBy(() -> config.loginService().authenticate(
                "[email protected]", "secret-1234"))
                .isInstanceOf(InvalidCredentialsException.class)
                .hasMessage("invalid credentials");
    }

    private static final class PerCallRepositoryConfig {
        private final PasswordHasher passwordHasher =
                new TestPasswordHasher();

        MemberRegistrationService memberRegistrationService() {
            return new MemberRegistrationService(
                    memberRepository(), passwordHasher);
        }

        LoginService loginService() {
            return new LoginService(
                    memberRepository(), passwordHasher);
        }

        private MemberRepository memberRepository() {
            return new MemoryMemberRepository();
        }
    }
}

해시는 두 경로 모두 같은 TestPasswordHasher를 쓰도록 고정했습니다. 그러니 이 실패의 원인은 해시가 아니라, 저장 상태가 R#1과 R#2 두 개로 나뉜 데 있습니다. 순수 Java 메서드는 돌려준 객체를 기억해 두었다가 다시 주지 않습니다. 공유가 필요하다면 한 번 만든 참조를 필드에 두거나, 상위의 조립 코드에서 두 서비스 생성자에 같은 참조를 넘겨야 합니다.

그림의 두 구역은 같은 구성 객체에서 일어난 서로 다른 조립 호출입니다. 첫 호출은 새 저장소 R#1을 만들어 가입 서비스에 넣고, 둘째 호출은 또 다른 새 저장소 R#2를 만들어 로그인 서비스에 넣습니다. 두 구역 사이에는 상태를 잇는 선이 없으므로, 가입이 저장한 회원은 R#1에만 있고 R#2를 조회하는 로그인은 그 회원을 볼 수 없습니다.

한 구성 객체 안의 공유 범위

앞 글의 실제 BoardConfig는 members와 passwordHasher를 인스턴스 필드에서 초기화합니다. 그래서 같은 BoardConfig의 구성 메서드를 여러 번 호출하면 서비스 객체는 새로 생기지만, 각 생성자에는 같은 필드 참조가 넘어갑니다. 무엇이 언제 만들어지는지를 정리하면 다음과 같습니다.

구성 객체를 더 이상 아무도 참조하지 않더라도, 서비스가 저장소와 해시 어댑터를 참조하고 있으면 그 객체들은 계속 살아 있습니다. 이처럼 순수 Java 구성은 객체를 몇 번 만들고 어떤 참조를 함께 쓰는지는 분명하게 보여 주지만, 가비지 컬렉션의 시점이나 자원의 정리는 관리해 주지 않습니다.

구현 교체가 증명하는 것

운영 그래프는 Pbkdf2PasswordHasher를 고르고, 단위 테스트는 필요한 서비스에 TestPasswordHasher를 직접 넘길 수 있습니다. 두 서비스가 PasswordHasher 역할에만 의존하므로, 역할이 그대로인 동안 어떤 구현을 쓸지는 구성 쪽에서만 정합니다. 각각의 주장을 무엇으로 확인했는지 정리하면 다음과 같습니다.

같은 PasswordHasher 객체를 넘기는 것은 지금 그래프의 선택일 뿐, 모든 구현이 따라야 하는 규칙은 아닙니다. 반대로 두 구현이 같은 역할을 구현한다고 해서 서로가 만든 저장 문자열을 해석할 수 있다는 보장도 없습니다.

그림의 위쪽이 바로 그런 경우입니다. TestPasswordHasher와 Pbkdf2PasswordHasher는 같은 PasswordHasher를 구현하지만 서로 다른 형식의 문자열을 만들며, {test} 형식으로 저장된 값을 PBKDF2의 matches로 검증하면 형식 검사에서 false가 됩니다. 구성에서 구현을 바꾸어도 서비스의 소스가 그대로라는 것은, 이미 저장된 {test} 값이 $pbkdf2-sha256$v1$ 어댑터에서 검증된다는 뜻도, 데이터를 옮기지 않고 운영 중에 구현을 갈아 끼울 수 있다는 뜻도 아닙니다. 이 메모리 예제는 새 BoardConfig를 만들면 저장 상태도 새로 시작하므로 그런 이전 과정을 보여 주지 않으며, 두 형식을 함께 받아 주는 호환 처리도 넣지 않습니다. 그림의 가운데는 config G#1이 R#1과 H#1을 한 번 만들고 새 서비스 S#1, S#2, S#3에 같은 참조를 넘기며, 새 config G#2는 독립된 그래프를 시작한다는 것을 보여 줍니다.

순수 Java 구성의 한계

객체 그래프 하나를 올바르게 조립했다고 해서 동시 접근, 원자적 중복 방지, 트랜잭션, 영속화, 외부 자원의 정리가 해결되지는 않습니다. 또 다른 코드가 별도의 저장소나 구성 객체를 만들면 또 다른 그래프가 생기므로, 실제 진입점이 어떤 config를 쓰는지도 함께 확인해야 합니다. 다음 글에서는 같은 역할과 구현을 Spring 컨테이너로 옮기며, 빈 후보 선택과 스코프의 규칙은 그때 따로 살펴봅니다.

정리

• 같은 구성 객체를 쓴다고 객체가 저절로 공유되지 않으며, 공유 여부는 어디서 몇 번 만들고 어떤 참조를 넘겼는지로 정해집니다.
• 메서드가 호출될 때마다 저장소를 새로 만들면 가입과 로그인이 서로 다른 상태를 보게 됩니다.
• 순수 Java 구성은 객체의 생성 횟수와 참조 공유를 보여 주지만, 수명이나 자원 정리는 관리하지 않습니다.
• 역할에만 의존하면 구현을 바꿀 때 서비스의 소스는 그대로지만, 이미 저장된 데이터의 형식이 호환되는지는 따로 확인해야 합니다.
• 이 장에서 공유의 범위는 config 인스턴스마다 만들어지는 객체 그래프이며, JVM 전체에 하나뿐인 객체가 아닙니다.

연습 문제

1. 두 config 사이의 상태

같은 config에서는 회원가입 뒤 로그인이 성공하고, 서로 다른 두 config 사이에서는 회원 상태가 보이지 않는다는 테스트를 작성하세요. 그 결과를 "JVM 전역 싱글톤"이 아니라 "config 인스턴스마다의 객체 그래프"라는 말로 설명합니다.

2. 변수에 새 config를 대입하면

첫 config에서 얻은 가입 서비스의 참조를 변수에 들고 있다가, config 변수에 new BoardConfig()를 다시 대입했습니다. 이미 들고 있는 가입 서비스가 쓰는 저장소도 바뀔까요?

다음 글 Spring 컨테이너 전환에서는 같은 역할과 구현을 Spring 컨테이너로 옮기고, 컨테이너가 빈 후보를 고르고 스코프를 관리하는 규칙을 순수 Java 구성과 비교합니다.