역할과 구현 분리

객체는 데이터와 동작을 함께 가진 Java 인스턴스입니다. 한 객체가 일을 끝내려고 다른 객체를 쓰면 두 객체 사이에 의존성(dependency)이 있다고 말합니다. 예를 들어 회원가입 서비스는 회원을 저장해야 하므로 회원 저장소에 의존합니다. 역할은 "무엇을 할 수 있는가"를, 구현은 "그 일을 어떻게 하는가"를 나타내며, Java에서는 보통 인터페이스로 역할을, 클래스로 구현을 표현합니다.

이 장은 역할과 객체 연결을 설명하기 위해 Spring 없이 순수 Java로 진행합니다. 1장에서 만든 애플리케이션의 회원가입을 다시 나누어 보지만, 이 장의 예제가 1장의 파일과 그대로 합쳐져 빌드된다는 뜻은 아닙니다. 1장의 코드는 그대로 두고, 이 장에서는 설명에 필요한 부분만 새로 작게 만듭니다.

회원가입 요구사항

게시판의 회원가입은 이메일이 이미 쓰이고 있는지 확인하고, 원문 비밀번호를 해시한 뒤, 이메일과 이름, 비밀번호 해시를 가진 회원을 저장하는 순서로 진행됩니다. 이 순서에 등장하는 기술은 바뀌는 이유가 서로 다릅니다. 저장 방식은 메모리에서 데이터베이스로 바뀔 수 있고, 해시 알고리즘은 보안 정책에 따라 바뀔 수 있습니다. 서비스 안에서 두 구현을 직접 만들면, 어느 쪽이 바뀌든 서비스를 고쳐야 합니다.

public interface MemberRepository {
    boolean existsByEmail(String email);
    Member save(Member member);
}

public interface PasswordHasher {
    String hash(String rawPassword);
}

MemberRepository는 이메일 중복 확인과 저장이라는 일만 정하고, Map을 쓰는지 SQL을 쓰는지는 드러내지 않습니다. PasswordHasher도 해시라는 역할만 정하고 구체적인 알고리즘은 드러내지 않습니다. 호출하는 쪽은 이 두 인터페이스만 알면 됩니다.

이 장에서는 메모리 저장소를 지금 고른 구현으로 쓰고, JDBC 저장소와 PBKDF2 해시는 나중에 구성에서 고를 수 있는 운영용 구현 후보로 둡니다. 다음 글에서 다룰 TestPasswordHasher는 테스트 전용 구현 후보이며, 이 글에서는 이름만 등장합니다. 이 구현은 항상 같은 결과를 내고 일부러 안전하지 않게 만들기 때문에 실제 비밀번호에는 절대 쓰지 않습니다.

구현을 직접 고르는 문제

다음 코드는 그대로 실행할 완성 예제가 아니라, 직접 생성하는 방식과 주입받는 방식을 비교하기 위한 축약 스케치입니다. 1장의 명령 객체와 검증은 일부러 빼고, TestPasswordHasher도 이름만 빌려 씁니다.

public final class MemberRegistrationService {
    private final MemberRepository members =
            new MemoryMemberRepository();
    private final PasswordHasher passwordHasher =
            new TestPasswordHasher();

    public Member register(
            String email,
            String name,
            String rawPassword
    ) {
        if (members.existsByEmail(email)) {
            throw new DuplicateEmailException(email);
        }
        String passwordHash = passwordHasher.hash(rawPassword);
        return members.save(Member.signUp(email, name, passwordHash));
    }
}

코드에 new가 있다는 것 자체가 문제는 아닙니다. 수명이 짧고 바뀔 일이 없는 값 객체나 내부 도우미를 그 자리에서 만드는 것은 자연스럽습니다. 이 코드의 문제는 저장 기술과 해시 정책처럼 바뀔 가능성이 큰 선택, 그리고 그 객체들을 얼마나 오래 쓸지라는 수명 관리까지 서비스 안으로 들어와 있다는 점입니다. register의 업무 순서는 저장 구현이나 해시 알고리즘과 상관이 없는데도, new MemoryMemberRepository()와 new TestPasswordHasher() 때문에 구현을 바꿀 때마다 서비스를 고쳐야 합니다.

생성자로 협력자 받기

서비스가 구현을 직접 만들지 않고 생성자로 받으면, 역할을 쓰는 코드와 구현을 고르는 코드를 나눌 수 있습니다. 아래 코드에서 앞과 달라진 곳은 필드의 new 초기화가 사라지고 생성자가 생긴 것입니다. 필드 타입은 여전히 두 인터페이스이며, Objects.requireNonNull은 구현을 넘기지 않은 실수를 서비스 객체를 만드는 순간 NullPointerException으로 드러냅니다.

import java.util.Objects;

public final class MemberRegistrationService {
    private final MemberRepository members;
    private final PasswordHasher passwordHasher;

    public MemberRegistrationService(
            MemberRepository members,
            PasswordHasher passwordHasher
    ) {
        this.members = Objects.requireNonNull(
                members, "members must not be null");
        this.passwordHasher = Objects.requireNonNull(
                passwordHasher, "passwordHasher must not be null");
    }

    // register의 업무 코드는 앞과 같다.
}

필요한 객체를 생성자로 바깥에서 넘겨받는 방식을 생성자 주입(constructor injection)이라고 합니다. 이것은 Spring 전용 문법이 아니라 평범한 Java 사용법이며, main 메서드나 테스트 준비 코드에서 구현을 직접 만들어 생성자에 넘기는 수동 구성도 완전히 올바른 방법입니다.

Spring은 애플리케이션이 커졌을 때 이 일을 대신해 줍니다. 등록된 빈 정의와 그 빈의 스코프(scope)에 따라 빈을 만들고 설정하고 연결하며, 초기화와 종료 콜백도 스코프에 따라 호출합니다. 예를 들어 프로토타입(prototype) 스코프의 빈은 초기화한 뒤 넘겨주고 나면 종료 콜백이 자동으로 호출되지 않습니다. 또 Spring이 관리하는 것은 서비스나 저장소처럼 빈으로 등록한 객체뿐이며, register 도중에 만들어지는 Member 같은 객체까지 모두 빈이 되는 것은 아닙니다.

연결이 끝난 뒤 요청이 들어오면 서비스는 저장소와 해시 객체를 직접 호출합니다. 의존성 주입 자체가 두 객체 사이의 호출을 매번 가로채지는 않습니다. 다만 뒤에서 배울 Spring AOP나 트랜잭션, 보안을 위한 프록시(proxy)를 따로 구성하면, 프록시를 거쳐 들어온 호출에 부가 기능이 끼어들 수 있습니다.

그림의 위쪽은 서비스가 두 역할 인터페이스에만 의존하고, 구현 클래스들이 그 역할을 구현하는 관계를 보여 줍니다. 가운데 상자들은 구현을 고르고 주입하는 일과 요청 시점의 호출이 서로 다른 일임을, 아래쪽 표는 역할마다 지금 고른 구현과 앞으로의 운영 후보를 보여 줍니다. 마지막 표는 생성자 주입을 썼다는 것만으로 설계 원칙이 지켜졌다고 볼 수 없는 이유를 정리하며, 이어지는 절에서 자세히 설명합니다.

변경 방향 읽기

회원가입 서비스는 "회원 저장"과 "비밀번호 해시"라는 업무 역할을 씁니다. Map이나 JDBC, PBKDF2 같은 기술은 서비스를 만드는 코드에 들어오지 않게 합니다. 그런데 생성자 주입을 썼다고 해서 다음 원칙들이 저절로 지켜지지는 않습니다.

주입은 이런 판단을 돕는 구조일 뿐입니다. 역할 인터페이스가 지나치게 크거나 서비스가 여러 업무를 함께 맡고 있다면, 생성자 주입을 쓰더라도 원칙은 여전히 깨질 수 있습니다. OCP와 DIP는 OCP·DIP와 생성자 주입의 경계에서 다시 자세히 다룹니다.

객체 그래프

객체와 객체가 연결된 모양을 객체 그래프(object graph)라고 합니다. 이 장의 회원가입 객체 그래프는 세 가지 관계로 읽을 수 있습니다.

[타입/소스 선언]
구현 저장소 클래스 ──implements──> MemberRepository
구현 해시 클래스 ──implements──> PasswordHasher

[구성 시점: 구현 선택과 주입]
MemberRegistrationService ←──inject── 두 역할 객체

[요청 시점: 메서드 호출]
MemberRegistrationService ──call──> MemberRepository
MemberRegistrationService ──call──> PasswordHasher

implements는 소스 코드의 타입 선언을, inject는 구성 시점에 구현을 골라 연결하는 일을, call은 요청 시점의 실행 흐름을 나타냅니다. 수동 구성이든 Spring 구성이든 구현을 JDBC 저장소와 PBKDF2 해시로 바꾸어도 서비스가 보는 역할은 같습니다.

그림은 이 세 관계가 서로 다른 시점에 일어난다는 것을 나누어 보여 줍니다. 구성은 요청보다 먼저 객체 그래프를 완성하고, 요청은 완성된 그래프를 씁니다. 그림 아래쪽은 수동 구성도 순수 Java로 충분히 올바르다는 것과, Spring 컨테이너는 등록된 빈만 관리하며 한 주입 지점에 맞는 후보가 하나로 정해지거나 @Qualifier 등으로 구분되어야 한다는 것을 보여 줍니다. 인터페이스만 보고 구현이 마법처럼 정해지는 것은 아닙니다. 마지막 체크리스트는 구현을 바꾸기 전에 무엇이 바뀌는지, 서비스가 정말 필요한 메서드만 역할에 남겼는지, 구현 선택을 사용 사례 밖으로 옮겼는지, 각각을 어떤 테스트로 확인할지를 차례로 점검하게 합니다.

정리

• 역할은 인터페이스로, 구현은 클래스로 나타내며, 서비스는 역할에만 의존하게 합니다.
• new 자체가 나쁜 것은 아니며, 바뀔 가능성이 큰 구현의 선택과 수명 관리가 사용 사례 안에 들어올 때 밖으로 옮깁니다.
• 생성자 주입은 Spring 전용 기능이 아니라 평범한 Java 사용법이고, main이나 테스트에서 직접 연결하는 수동 구성도 올바른 방법입니다.
• Spring은 등록된 빈만 스코프에 따라 만들고 연결하며, 의존성 주입 자체는 요청 시점의 호출을 가로채지 않습니다.
• 생성자 주입을 썼다고 DIP, OCP, SRP가 저절로 지켜지지는 않으므로 의존 방향과 변경 이유를 따로 확인합니다.

연습 문제

1. 환영 알림 역할 추가하기

회원가입 뒤에 환영 메일을 보내야 한다고 해 봅시다. 서비스 안에 new EmailSender()를 넣지 말고, void welcome(Member member) 메서드 하나를 가진 WelcomeNotifier 역할을 정의하세요. 알림은 저장소가 저장된 회원을 정상적으로 돌려준 뒤에만 한 번 호출하고, 저장이 예외로 끝나면 호출하지 않아야 합니다. 테스트용 구현은 메일을 보내지 않고 받은 회원과 호출 횟수만 기록합니다. 알림까지 회원가입과 하나로 묶는 기능은 이번 조건에 없습니다. 이렇게 했을 때 서비스의 회원가입 순서가 어떻게 읽히는지 설명하세요.

2. 구현 교체와 역할 변경

메모리 저장소를 JDBC 저장소로 바꾸는 일과, MemberRepository에 findByEmail 메서드를 새로 추가하는 일은 각각 어떤 코드를 바꾸게 하나요?

다음 글 순수 Java 회원가입에서는 이 설계를 Spring 없이 실행할 수 있는 코드로 만듭니다.