SOLID 원칙 — 좋은 객체지향 설계의 다섯 가지 기준

SOLID 원칙. 좋은 객체지향 설계의 다섯 가지 기준. SRP·OCP·LSP·ISP·DIP를 안티패턴 코드와 개선 예제로 정리하고, 디자인 패턴·스프링과 어떻게 연결되는지까지 짚는다.

---

들어가며

지난 글에서 실무에서 자주 쓰는 디자인 패턴을 정리했다. 그런데 디자인 패턴은 하늘에서 떨어진 게 아니다.
그 밑에는 SOLID 라는 다섯 가지 설계 원칙이 깔려 있다.
전략 패턴이 왜 좋은지, 스프링이 왜 의존성 주입을 쓰는지를 설명하는 근거가 바로 SOLID다.

SOLID는 로버트 마틴(Robert C. Martin)이 정리한 객체지향 설계의 다섯 원칙의 머리글자다.

약자	원칙	한 줄 요약
S	단일 책임 (SRP)	클래스는 하나의 이유로만 변경돼야 한다
O	개방-폐쇄 (OCP)	확장에는 열려 있고, 변경에는 닫혀 있어야 한다
L	리스코프 치환 (LSP)	자식은 부모를 대체할 수 있어야 한다
I	인터페이스 분리 (ISP)	안 쓰는 메서드에 의존하게 하지 마라
D	의존성 역전 (DIP)	구체가 아니라 추상에 의존하라

SOLID는 규칙이 아니라 방향이다. 코드가 변경에 얼마나 유연한지를 보는 다섯 가지 렌즈다.

이 글에서는 각 원칙을 안티패턴 코드와 개선 코드로 비교하며 정리한다. 예시는 Java/Spring 기준이다.

---

S — 단일 책임 원칙 (Single Responsibility)

하나의 클래스는 하나의 책임만 가져야 한다. 다르게 말하면, 클래스가 변경되는 이유는 단 하나여야 한다.

아래 UserService는 사용자 등록, 이메일 발송, 로그 기록까지 다 한다.

// 안티패턴: 한 클래스가 여러 책임을 짊어짐
public class UserService {
    public void register(User user) {
        // 1. 사용자 저장 (DB 책임)
        userRepository.save(user);

        // 2. 환영 이메일 발송 (메일 책임)
        String html = "<h1>환영합니다 " + user.getName() + "</h1>";
        emailClient.send(user.getEmail(), html);

        // 3. 감사 로그 기록 (로깅 책임)
        Files.writeString(Path.of("audit.log"), "registered: " + user.getId());
    }
}

이 클래스는 세 가지 이유로 바뀐다. 이메일 양식이 바뀌어도, 로그 형식이 바뀌어도, DB가 바뀌어도 여기를 건드린다.
책임을 분리하면 이렇게 된다.

// 개선: 책임마다 클래스를 나눈다
public class UserService {

    private final UserRepository userRepository;
    private final WelcomeEmailSender emailSender;
    private final AuditLogger auditLogger;

    public void register(User user) {
        userRepository.save(user);       // 저장만
        emailSender.send(user);          // 이메일은 위임
        auditLogger.log("registered", user.getId());  // 로깅도 위임
    }
}

이제 이메일 양식이 바뀌면 WelcomeEmailSender만 고치면 된다. 각 클래스가 자기 책임에만 집중한다.

---

O — 개방-폐쇄 원칙 (Open-Closed)

확장에는 열려 있고, 변경에는 닫혀 있어야 한다. 새 기능을 추가할 때 기존 코드를 고치지 않고, 새 코드를 더하는 방식이어야 한다.

등급별 할인을 계산하는 코드를 보자.

// 안티패턴: 등급이 추가될 때마다 이 메서드를 수정
public int discount(Grade grade, int price) {
    if (grade == Grade.SILVER) return price * 5 / 100;
    else if (grade == Grade.GOLD) return price * 10 / 100;
    else if (grade == Grade.VIP) return price * 20 / 100;
    // 새 등급 추가 = 이 코드 수정 (변경에 열려 있음 → 위반)
    return 0;
}

새 등급이 생길 때마다 이 메서드를 수정해야 한다. 전략 패턴으로 추상화하면 변경 없이 확장할 수 있다.

// 개선: 정책을 인터페이스로 추상화
public interface DiscountPolicy {
    boolean supports(Grade grade);
    int calculate(int price);
}

@Component
public class VipDiscountPolicy implements DiscountPolicy {
    public boolean supports(Grade grade) { return grade == Grade.VIP; }
    public int calculate(int price) { return price * 20 / 100; }
}

새 등급은 DiscountPolicy 구현체를 추가하기만 하면 된다. 기존 코드는 닫혀 있다.
지난 글의 전략 패턴이 바로 OCP를 구현하는 도구다.

---

L — 리스코프 치환 원칙 (Liskov Substitution)

자식 타입은 언제나 부모 타입을 대체할 수 있어야 한다. 부모를 쓰던 자리에 자식을 넣었을 때 동작이 깨지면 안 된다.

유명한 반례가 "직사각형-정사각형" 문제다.

// 안티패턴: Square가 Rectangle을 상속
public class Rectangle {
    protected int width, height;
    public void setWidth(int w)  { this.width = w; }
    public void setHeight(int h) { this.height = h; }
    public int area() { return width * height; }
}

public class Square extends Rectangle {
    // 정사각형은 가로=세로여야 하므로 둘 다 바꿈
    public void setWidth(int w)  { this.width = w; this.height = w; }
    public void setHeight(int h) { this.width = h; this.height = h; }
}

겉보기엔 "정사각형은 직사각형의 일종"이라 맞아 보인다. 하지만 이 코드는 깨진다.

void resize(Rectangle r) {
    r.setWidth(5);
    r.setHeight(4);
    assert r.area() == 20;   // Rectangle이면 통과, Square면 16 → 실패!
}

Rectangle을 기대한 코드에 Square를 넣으면 결과가 달라진다. 치환이 안 되는 것이다.
상속 관계가 "is-a"처럼 보여도, 행위가 일관되지 않으면 상속하면 안 된다는 게 LSP의 교훈이다.
이 경우엔 상속 대신 둘을 분리하거나 불변 객체로 설계하는 게 맞다.

---

I — 인터페이스 분리 원칙 (Interface Segregation)

클라이언트는 자신이 쓰지 않는 메서드에 의존하면 안 된다. 거대한 인터페이스 하나보다, 작고 구체적인 인터페이스 여러 개가 낫다.

// 안티패턴: 만능 인터페이스
public interface Machine {
    void print(Document doc);
    void scan(Document doc);
    void fax(Document doc);
}

// 구형 프린터는 인쇄만 되는데, 안 쓰는 메서드를 억지로 구현
public class OldPrinter implements Machine {
    public void print(Document doc) { /* 정상 */ }
    public void scan(Document doc) { throw new UnsupportedOperationException(); }
    public void fax(Document doc)  { throw new UnsupportedOperationException(); }
}

OldPrinter는 스캔·팩스를 못 하는데도 빈 구현이나 예외를 강제로 떠안는다. 인터페이스를 잘게 쪼개면 해결된다.

// 개선: 기능별로 인터페이스를 분리
public interface Printer { void print(Document doc); }
public interface Scanner { void scan(Document doc); }
public interface Fax     { void fax(Document doc); }

// 필요한 것만 구현
public class OldPrinter implements Printer {
    public void print(Document doc) { /* 인쇄만 */ }
}

// 복합기는 여러 개를 구현
public class AllInOne implements Printer, Scanner, Fax {
    public void print(Document doc) { /* ... */ }
    public void scan(Document doc)  { /* ... */ }
    public void fax(Document doc)   { /* ... */ }
}

각 클래스가 필요한 능력만 구현한다. 안 쓰는 메서드에 묶이지 않는다.

---

D — 의존성 역전 원칙 (Dependency Inversion)

고수준 모듈이 저수준 모듈에 의존하면 안 된다. 둘 다 추상(인터페이스)에 의존해야 한다. SOLID의 마지막 글자이자, 스프링의 핵심이다.

// 안티패턴: 고수준(주문)이 저수준(구체 결제 구현)에 직접 의존
public class OrderService {
    private final KakaoPayClient payClient = new KakaoPayClient();  // 구체 클래스에 못박힘

    public void order() {
        payClient.pay();   // 결제사 바꾸면 이 코드도 바뀐다
    }
}

OrderService가 KakaoPayClient라는 구체 클래스를 직접 만든다. 결제사를 바꾸려면 주문 로직을 고쳐야 한다.
추상에 의존하도록 뒤집으면 이렇게 된다.

// 개선: 추상(인터페이스)에 의존
public interface PayClient {
    void pay();
}

@Service
public class OrderService {

    private final PayClient payClient;   // 인터페이스에만 의존

    // 구현체는 외부에서 주입받는다 (스프링 DI)
    public OrderService(PayClient payClient) {
        this.payClient = payClient;
    }

    public void order() {
        payClient.pay();   // 어떤 구현체든 상관없다
    }
}

OrderService는 PayClient라는 추상에만 의존하고, 실제 구현체(KakaoPayClient, TossPayClient)는 스프링이 주입한다.
스프링의 의존성 주입(DI)이 바로 DIP의 구현체다. 우리가 생성자 주입을 쓸 때마다 사실 DIP를 실천하고 있는 셈이다.

---

마치며

SOLID는 시험에 나오는 암기 과목이 아니라, 코드를 보는 다섯 가지 질문에 가깝다.

• 이 클래스는 한 가지 이유로만 바뀌는가? (SRP)
• 기능을 추가할 때 기존 코드를 안 고치고 되는가? (OCP)
• 자식을 부모 자리에 넣어도 안 깨지는가? (LSP)
• 안 쓰는 메서드에 묶여 있지 않은가? (ISP)
• 구체 클래스가 아니라 인터페이스에 의존하는가? (DIP)

그리고 SOLID는 디자인 패턴과 한 몸이다. OCP를 지키려다 보면 전략 패턴이 나오고, DIP를 지키려다 보면 의존성 주입이 나온다.
패턴은 SOLID를 구현하는 구체적인 방법이고, SOLID는 그 패턴들이 왜 좋은지를 설명하는 원리다.

물론 모든 코드에 SOLID를 100% 적용할 필요는 없다. 과하게 추상화하면 오히려 읽기 어려운 코드가 된다.
중요한 건 "지금 이 코드가 변경에 약한 지점은 어디인가"를 묻고, 거기에만 원칙을 적용하는 감각이다.

---

참고 출처

• Robert C. Martin, 『클린 아키텍처(Clean Architecture)』
• Robert C. Martin, "The Principles of OOD" — http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
• Baeldung: SOLID Principles — https://www.baeldung.com/solid-principles