[Java] 다형성과 설계

Study/Java

[Java] 다형성과 설계

the.Dev.Cat 2026. 4. 9. 23:55

Java 기본 — 다형성과 설계

1. 좋은 객체 지향 프로그래밍이란?

객체 지향 프로그래밍(OOP)의 핵심 특징은 네 가지다.

이 중 가장 중요한 것이 다형성(Polymorphism)이다. 객체 지향 프로그래밍은 명령어의 목록으로 프로그램을 보는 절차적 시각에서 벗어나, 여러 독립된 단위인 "객체"들의 협력으로 세상을 파악한다. 각 객체는 메시지를 주고받으며 데이터를 처리한다.

좋은 객체 지향 설계가 추구하는 것은 유연하고 변경이 용이한 소프트웨어다. 레고 블록을 조립하듯, 키보드나 마우스를 교체하듯, 컴포넌트를 쉽게 바꿀 수 있는 구조가 목표다. 이것이 대규모 소프트웨어 개발에서 OOP가 널리 쓰이는 이유다.

2. 다형성의 실세계 비유 — 역할과 구현

다형성을 이해하는 가장 직관적인 방법은 "역할과 구현"으로 세상을 구분하는 것이다. 실세계와 객체 지향이 1:1로 딱 맞아 떨어지지는 않지만, 개념을 잡는 데 좋은 출발점이 된다.

운전자와 자동차

운전자는 Car라는 역할(인터페이스)만 알면 된다. K3, 아반떼, 테슬라 모델3 중 어느 차에 타더라도 시동을 켜고 가속하는 방법은 동일하다. 차의 내부 구조(엔진이 전기인지 가솔린인지)를 몰라도 운전할 수 있다. 차가 바뀌어도 운전자는 영향을 받지 않는다.

공연 무대

로미오와 줄리엣 공연에서 "로미오 역할"을 장동건이 맡을 수도 있고 원빈이 맡을 수도 있다. 역할(인터페이스)이 바뀌지 않는다면 구현(배우)은 자유롭게 교체할 수 있다. 이것이 다형성의 핵심 직관이다.

3. 역할과 구현을 분리하면 생기는 것들

세상을 역할과 구현으로 구분하면 세 가지 이점이 생긴다.

이점	설명
단순해진다	클라이언트는 역할(인터페이스)만 알면 된다. 구현의 복잡한 내부를 몰라도 된다.
유연해진다	구현 대상의 내부 구조가 변경되어도 클라이언트는 영향을 받지 않는다.
확장이 쉬워진다	구현 대상 자체를 새로운 것으로 교체해도 클라이언트 코드는 변경이 없다.

자바 언어에서의 매핑

객체를 설계할 때는 역할(인터페이스)을 먼저 정의하고, 그 역할을 수행하는 구현 객체를 만드는 순서로 진행해야 한다. 인터페이스를 안정적으로 잘 설계하는 것이 핵심이다. 인터페이스 자체가 변하면 클라이언트, 서버 모두에 큰 변경이 발생하기 때문이다.

4. 객체의 협력 — 클라이언트와 서버

혼자 있는 객체는 없다. 객체 세계에서 모든 객체는 협력 관계에 있다.

클라이언트: 요청하는 쪽
서버: 응답하는 쪽

하나의 객체가 클라이언트인 동시에 서버가 될 수도 있다. 수많은 객체 클라이언트와 객체 서버가 서로 협력 관계를 이루며 하나의 프로그램이 완성된다.

5. 자바 언어의 다형성 — 오버라이딩과 런타임 바인딩

자바에서 다형성은 오버라이딩(Overriding)을 통해 구현된다. 부모 타입의 참조 변수로 자식 객체를 가리킬 때, 실제로 실행되는 메서드는 참조 변수의 타입이 아니라 실제 객체의 타입에 따라 결정된다. 이를 동적 디스패치(Dynamic Dispatch) 또는 런타임 바인딩이라고 한다.

Driver는 Car 인터페이스에만 의존한다. car.startEngine()을 호출할 때 JVM은 car 변수가 실제로 가리키는 객체(K3Car 또는 Model3Car)를 확인하고, 그 클래스에서 오버라이딩된 메서드를 실행한다. 이것이 다형성의 본질이다.

클라이언트를 변경하지 않고, 서버의 구현 기능을 유연하게 변경할 수 있다.

클래스 상속 관계에서도 동일하게 적용된다. 부모 클래스를 상속받은 자식 클래스가 메서드를 오버라이딩하면 다형성과 동적 바인딩이 작동한다.

6. 예제 1 — 다형성 없이 설계했을 때의 문제

다형성이 왜 필요한지 이해하기 위해, 인터페이스 없이 구체 클래스에 직접 의존하는 코드를 먼저 살펴본다.

초기 설계: Driver가 K3Car에 직접 의존

public class K3Car {
    public void startEngine() {
        System.out.println("K3Car.startEngine");
    }
    public void offEngine() {
        System.out.println("K3Car.offEngine");
    }
    public void pressAccelerator() {
        System.out.println("K3Car.pressAccelerator");
    }
}

public class Driver {
    private K3Car k3Car;

    public void setK3Car(K3Car k3Car) {
        this.k3Car = k3Car;
    }
    public void drive() {
        System.out.println("자동차를 운전합니다.");
        k3Car.startEngine();
        k3Car.pressAccelerator();
        k3Car.offEngine();
    }
}

이 설계의 문제는 새로운 차(Model3Car)가 추가되는 순간 Driver 클래스를 직접 수정해야 한다는 것이다.

Model3Car 추가 시 Driver가 받는 영향

public class Driver {
    private K3Car k3Car;
    private Model3Car model3Car; // 추가

    public void setK3Car(K3Car k3Car) { this.k3Car = k3Car; }

    public void setModel3Car(Model3Car model3Car) { // 추가
        this.model3Car = model3Car;
    }

    public void drive() {
        System.out.println("자동차를 운전합니다.");
        if (k3Car != null) {  // 분기 추가
            k3Car.startEngine();
            k3Car.pressAccelerator();
            k3Car.offEngine();
        } else if (model3Car != null) {
            model3Car.startEngine();
            model3Car.pressAccelerator();
            model3Car.offEngine();
        }
    }
}

차량 종류가 늘어날수록 Driver 코드에 필드, 세터, 분기문이 계속 추가된다. 새로운 차량(NewCar)이 추가될 때마다 클라이언트인 Driver가 영향을 받는 것이다. 이것이 구체 클래스에 직접 의존했을 때의 한계다.

차량 종류가 N개이면 Driver에 N개의 필드, N개의 세터, drive() 안에 N개의 분기가 생긴다. 유지보수가 사실상 불가능해진다.

7. 예제 3 — 인터페이스로 역할과 구현 분리

다형성을 활용하면 클라이언트 코드의 변경 없이 구현 객체를 교체할 수 있다. Driver가 구체 클래스가 아닌 Car 인터페이스에만 의존하도록 설계를 바꾼다.

Car 인터페이스 정의

public interface Car {
    void startEngine();
    void offEngine();
    void pressAccelerator();
}

구현 클래스

public class K3Car implements Car {
    @Override
    public void startEngine() { System.out.println("K3Car.startEngine"); }
    @Override
    public void offEngine() { System.out.println("K3Car.offEngine"); }
    @Override
    public void pressAccelerator() { System.out.println("K3Car.pressAccelerator"); }
}

public class Model3Car implements Car {
    @Override
    public void startEngine() { System.out.println("Model3Car.startEngine"); }
    @Override
    public void offEngine() { System.out.println("Model3Car.offEngine"); }
    @Override
    public void pressAccelerator() { System.out.println("Model3Car.pressAccelerator"); }
}

Driver — 인터페이스에만 의존

public class Driver {
    private Car car;  // Car 인터페이스 타입으로 선언

    public void setCar(Car car) {
        System.out.println("자동차를 설정합니다: " + car);
        this.car = car;
    }

    public void drive() {
        System.out.println("자동차를 운전합니다.");
        car.startEngine();
        car.pressAccelerator();
        car.offEngine();
    }
}

런타임에 구현 객체를 교체

public class CarMain1 {
    public static void main(String[] args) {
        Driver driver = new Driver();

        // K3 선택
        Car k3Car = new K3Car();
        driver.setCar(k3Car);
        driver.drive();

        // K3 → Model3 교체 (Driver 코드 변경 없음)
        Car model3Car = new Model3Car();
        driver.setCar(model3Car);
        driver.drive();
    }
}

이 코드에서 핵심은 Driver 클래스의 코드가 단 한 줄도 바뀌지 않았다는 것이다. setCar(Car car) 메서드의 파라미터 타입이 Car 인터페이스이므로, Car를 구현한 어떤 객체든 주입할 수 있다.

런타임 동작 원리

car.startEngine()이 호출되면 JVM은 car 변수가 실제로 참조하는 객체(K3Car 또는 Model3Car)를 확인하고, 해당 클래스에서 오버라이딩된 메서드를 실행한다. 컴파일 타임에는 Car 인터페이스의 메서드를 호출하는 것처럼 보이지만, 런타임에는 실제 구현체의 메서드가 실행된다.

8. OCP(Open-Closed Principle) 원칙

OCP는 SOLID 원칙 중 하나로, 좋은 객체 지향 설계의 핵심 원칙이다.

앞서 만든 Driver + Car 구조가 OCP를 잘 지키는 코드다.

확장에 열려 있다

새로운 차량(NewCar)을 추가하려면 Car 인터페이스를 구현하는 새 클래스를 만들기만 하면 된다. Car 인터페이스를 구현한 모든 객체는 Driver가 즉시 사용할 수 있다. 이것이 확장에 열려 있다는 의미다.

변경에 닫혀 있다

새로운 차량이 추가될 때 Driver 클래스의 코드는 전혀 수정하지 않아도 된다. 핵심 비즈니스 로직을 담은 클라이언트 코드가 변경되지 않는다.

변하는 부분과 변하지 않는 부분

구분	코드	변경 여부
핵심 로직 (클라이언트)	`Driver`	변경 없음
구현 추가	`NewCar implements Car`	새 파일 추가
설정/조립 (main)	`main()`	변경 필요

main()처럼 전체 프로그램을 설정하고 조율하는 부분은 OCP를 지키더라도 변경이 필요하다. 이 부분은 어쩔 수 없다. OCP의 목표는 핵심 비즈니스 로직을 담은 코드를 보호하는 것이다.

9. 전략 패턴(Strategy Pattern)

앞서 설계한 코드는 디자인 패턴 중 가장 중요한 패턴 중 하나인 전략 패턴을 그대로 구현한 것이다.

전략 패턴은 알고리즘(전략)을 클라이언트 코드의 변경 없이 쉽게 교체할 수 있는 패턴이다.

구성 요소	자동차 예제	역할
전략 인터페이스	`Car`	알고리즘의 공통 계약 정의
구체적인 전략	`K3Car`, `Model3Car`	인터페이스를 구현한 실제 알고리즘
컨텍스트 (클라이언트)	`Driver`	전략을 사용하는 쪽, 변경되지 않음

스프링(Spring)의 핵심 개념인 제어의 역전(IoC)과 의존관계 주입(DI)도 결국 이 전략 패턴, 즉 다형성을 활용하는 것이다. 스프링을 사용하면 공연 무대의 배우를 선택하듯 구현체를 편리하게 교체할 수 있게 된다.

10. 역할과 구현 분리의 한계

역할과 구현을 분리하는 것이 만능은 아니다. 한 가지 중요한 한계가 있다.

역할(인터페이스) 자체가 변하면, 클라이언트와 서버 모두에 큰 변경이 발생한다.

자동차 인터페이스를 비행기 인터페이스로 변경해야 한다면?
USB 인터페이스 규격이 바뀐다면?
공연의 대본 자체가 바뀐다면?

이것이 인터페이스를 안정적으로 잘 설계하는 것이 중요한 이유다. 인터페이스를 처음부터 신중하게 설계해야 나중에 발생하는 변경 비용을 최소화할 수 있다. 인터페이스를 자주 바꾸는 것은 역할과 구현을 분리한 이점을 상쇄시켜 버린다.

11. 정리 — 다형성이 중요한 이유

관점	설명
유연성	실행 시점에 구현 객체를 유연하게 변경할 수 있다
확장성	클라이언트 코드 수정 없이 새로운 구현을 추가할 수 있다
OCP	확장에는 열려 있고, 변경에는 닫힌 설계가 가능하다
디자인 패턴	대부분의 디자인 패턴은 다형성을 활용한다 (전략, 템플릿, 데코레이터 등)
스프링	IoC, DI 모두 다형성을 기반으로 동작한다

다형성을 제대로 활용하려면 세 가지를 기억하면 된다.

역할(인터페이스)을 먼저 설계한다.
클라이언트는 역할에만 의존한다. 구체 클래스에 의존하지 않는다.
인터페이스를 안정적으로 설계한다. 한번 정한 인터페이스는 잘 바꾸지 않는다.

다형성이 가장 중요하다. 디자인 패턴 대부분은 다형성을 활용하는 것이다. 스프링의 핵심인 IoC, DI도 결국 다형성을 활용하는 것이다.