SOLID

SOLID는 객체 지향 프로그래밍 및 설계(OOP)에서 좋은 소프트웨어를 만들기 위해 지켜야 하는 5가지 핵심 설계 원칙의 앞 글자를 딴 약어입니다. 로버트 C. 마틴(Uncle Bob)이 2000년대 초반에 정립한 이 원칙들의 핵심 목적은, 시간이 지나도 유지보수가 쉽고, 확장성이 높으며, 변화에 유연하게 대처할 수 있는 코드를 만드는 것입니다. SOLID를 구성하는 원칙은 SRP, OCP, LIP, ISP, DIP입니다.

SRP

Single Responsibility Principle로 단일 책임 원칙입니다. 하나의 클래스는 단 하나의 책임(변경 이유)만을 가져야 한다는 것인데, 실무에서는 오직 하나의 액터(Actor, 기능 변경을 요청하는 집단)에 대해서만 책임을 져야 한다로 적용하는게 자연스럽습니다.

SRP가 적용된 예는 다음과 같습니다.

// 1. 로깅 전담 클래스 (변경 이유: 로그 포맷 변경, 저장소 변경 등)
class Logger {
    public log(message: string): void {
        const timestamp = new Date().toISOString();
        console.log(`[LOG] [${timestamp}] - ${message}`);
    }
}

// 2. 인증 전담 클래스 (변경 이유: JWT 도입, OAuth2 도입 등)
class AuthService {
    public authenticate(token: string): boolean {
        console.log(`토큰 유효성을 검증합니다: ${token}`);
        return true;
    }
}

// 3. 사용자 정보 관리 전담 클래스 (변경 이유: 프로필 비즈니스 로직 변경)
// 의존성 주입(DI)을 통해 외부에서 로거를 주입받아 사용합니다.
class UserService {
    private logger: Logger;

    constructor(logger: Logger) {
        this.logger = logger;
    }

    public updateProfile(userId: string, data: any): void {
        console.log(`사용자 ${userId}의 프로필을 업데이트합니다.`);
        
        // 자신의 책임이 아닌 로그 출력은 주입받은 Logger 객체에게 위임합니다.
        this.logger.log(`프로필 업데이트 완료 (UserId: ${userId})`);
    }
}

function run() {
    const logger = new Logger();
    const authService = new AuthService();
    const userService = new UserService(logger);

    // 각자 맡은 책임만 수행
    if (authService.authenticate("valid-token")) {
        userService.updateProfile("user_123", { name: "Gemini" });
    }
}

run();

SRP가 적용될 경우 잇점을 생각해 보면… <클래스가 작고 단순해져 유닛 테스트 작성이 매우 수월해 지고 각 클래스는 본연의 임무에만 집집하므로 코드가 단단해 집니다. 단단하다는 의미는 오류 발생이 적다는 것입니다.

OCP

Open-Closed Principle으로 개방-폐쇠 원칙입니다. 확장에는 개방되어 있고 변경에는 폐쇠되어 있어야 한다는 원칙인데요. 변경에는 폐쇠되어 있다(Closed for modi)라는 것은 신규 기능 추가 시 다른 기능에 대한 코드 수정은 금지한다이고 확장에는 개방되어 있다(Open for extension)는 신규 기능 추가 시 제약 없이 코드 작성 가능해야 한다는 것입니다. SRP 적용을 위한 구체적인 도구는 인터페이스와 추상 클래스입니다.

OCP가 적용된 예는 다음과 같습니다.

// 공통 인터페이스 정의 (이 틀은 변하지 않습니다)
interface PaymentMethod {
    pay(): void;
}

// 각 결제 수단은 인터페이스를 상속받아 구체적인 로직을 구현합니다.
class KakaoPay implements PaymentMethod {
    public pay(): void {
        console.log("카카오페이로 안전하게 결제합니다.");
    }
}

class NaverPay implements PaymentMethod {
    public pay(): void {
        console.log("네이버페이로 안전하게 결제합니다.");
    }
}

// 💡 새로운 결제 수단이 추가되어도 기존 코드를 건드릴 필요 없이 파일만 새로 만들면 됩니다 (확장에 열림)
class TossPay implements PaymentMethod {
    public pay(): void {
        console.log("토스페이로 안전하게 결제합니다.");
    }
}

// 결제 매니저는 구체적인 클래스가 아닌 인터페이스(PaymentMethod)에만 의존합니다.
class PaymentManager {
    // 새로운 결제 방식이 아무리 늘어나도 이 메서드는 단 한 줄도 수정할 필요가 없습니다 (변경에 닫힘).
    public processPayment(paymentMethod: PaymentMethod): void {
        paymentMethod.pay();
    }
}

function runPaymentSystem() {
    const manager = new PaymentManager();

    const kakao = new KakaoPay();
    const toss = new TossPay(); // 새롭게 추가된 결제 수단

    manager.processPayment(kakao);
    manager.processPayment(toss); // 기존 결제 매니저 코드 수정 없이 그대로 확장 적용 가능
}

runPaymentSystem();

SRP의 장점을 생각해 보면… 새로운 기능을 추가할때 기존 코드 영향을 최소화 시키며 기능을 컴포넌트 단위로 개발하여 플러그인처럼 쉽게 추가하여 조립할 수 있다는 것입니다.

LSP

Liskov Substitution Principle으로 리스코프 치환 원칙입니다. OOP의 올바른 다형성 구현을 위한 상속 규칙을 정의한 것으로 서브 타입은 항상 슈퍼 타입을 대체할 수 있어야 한다와 자식 클래스는 부모 클래스의 추상 매서드만을 public으로 제공해야 한다는 것을 강조한 원칙입니다.

LSP가 적용된 예는 다음과 같습니다.

// 두 도형의 공통점은 '면적을 구할 수 있다'는 것뿐입니다.
interface Shape {
    getArea(): number;
}

// 직사각형은 자신의 성질에 맞게 구현합니다.
class Rectangle implements Shape {
    constructor(private width: number, private height: number) {}

    public setWidth(width: number): void {
        this.width = width;
    }

    public setHeight(height: number): void {
        this.height = height;
    }

    public getArea(): number {
        return this.width * this.height;
    }
}

// 정사각형도 자신의 성질에 맞게 구현합니다. 직사각형을 상속받지 않습니다.
class Square implements Shape {
    constructor(private side: number) {}

    public setSide(side: number): void {
        this.side = side;
    }

    public getArea(): number {
        return this.side * this.side;
    }
}

// 클라이언트는 구체적인 가로/세로 수정에 의존하지 않고, 
// 오직 '추상화된 Shape 인터페이스의 getArea 규약'에만 의존합니다.
function printArea(shape: Shape) {
    console.log(`면적: ${shape.getArea()}`);
}

const myRect = new Rectangle(5, 4);
const mySquare = new Square(5);

printArea(myRect);   // 면적: 20 (의도대로 동작)
printArea(mySquare); // 면적: 25 (의도대로 동작)

LSP을 고려할 때 체크해야할 것을 고민해 보면… 먼저 서브 클래스가 슈퍼 클래스의 매서드를 오버라이딩할 때 의미를 왜곡하지 않는가? 그리고 서브 클래스가 슈퍼 클래스의 예외 규약(전제 조건)을 깨지 않는가? 입니다. 아울러 상속은 행동의 일치성이 보장될때 사용되는 것이지 언어적 직관이 아닙니다. 즉, 정사각형은 직사각형을 상속받을 수 있는가라는 질문에서 속성은 상속받는 대상이 아니므로 정사각형은 직사각형을 상속받기에는 적합하지 않다입니다.

ISP

Interface Segregation Principle로 인터페이스 분리 원칙입니다. 클라이언트는 자신이 사용하지 않는 매서드에 의존하도록 강제되어서는 안된다는 원칙으로 하나의 만능 인터페이스를 만들지 말고 목적에 따라 여러 개의 인터페이스로 쪼개라는 것입니다.

ISP가 적용된 예는 다음과 같습니다.

// 역할을 얇게 쪼갠 역할 인터페이스들
interface Printer {
    print(): void;
}

interface Scanner {
    scan(): void;
}

interface FaxMachine {
    fax(): void;
}

// 보급형 프린터는 오직 'Printer' 인터페이스만 구현합니다. (깔끔)
class EconomicPrinter implements Printer {
    public print(): void {
        console.log("흑백으로 문서를 출력합니다.");
    }
}

// 고급형 복합기는 필요한 인터페이스들을 다중 상속(구현)하여 조합합니다.
class AllInOnePrinter implements Printer, Scanner, FaxMachine {
    public print(): void { console.log("컬러로 문서를 출력합니다."); }
    public scan(): void { console.log("고화질로 스캔합니다."); }
    public fax(): void { console.log("팩스를 보냅니다."); }
}

// 클라이언트 함수도 거대한 인터페이스 전체에 의존하지 않고, 
// 자기가 딱 필요한 얇은 인터페이스에만 의존하게 됩니다.
class OfficeWorker {
    // 이 직원은 오직 스캔 기능만 필요로 합니다.
    public doScanJob(scanner: Scanner) {
        scanner.scan();
    }
}

const worker = new OfficeWorker();
const premiumMachine = new AllInOnePrinter();
const ecoMachine = new EconomicPrinter();

worker.doScanJob(premiumMachine); // 정상 작동

// 💡 애초에 스캔 기능이 없는 ecoMachine은 타입 검사 단계에서 걸러지므로 
// 컴파일 에러를 통해 잠재적 버그를 사전에 방지할 수 있습니다.
// worker.doScanJob(ecoMachine); // 컴파일 에러 발생!

ISP이 적용될 경우 장점을 생각해 보면… 인터페이스 별로 잘 나눠져 있다면 해당 인터페이스의 변경에 따른 구현 클래스 변경이 최소화된다는 것입니다. 참고로 SRP는 클래스에 대한 단일 책임을 강조한다면 ISP는 인터페이스의 단일 책임을 강조하는 원칙입니다.

이 원칙에 대한 체크 사항은 인터페이스를 구현하는 클래스에서 인터페이스의 매서드 중 빈칸 또는 예외로 처리하는 경우가 있다면 ISP 위반일 가능성이 높습니다.

DIP

Dependency Inversion Princlple로 의존 역전 원칙입니다. 고수준 모듈은 저수준 모듈으 구현에 의존해서는 안된다는 것으로 고수준이나 저수준 모두 별도의 추상화된 모듈에 의존해야 한다는 것입니다. 전통적인 모듈 방식의 개발은 고수준 모듈이 저수준 모듈에 의존했지만 DIP을 준수하면 저수준과 고수준 모듈 간의 의존은 제거되고 두 모듈이 별도의 추상화 모듈에 의존하게 됩니다. 즉 의존 방향 역전됩니다.

DIP가 적용된 예는 다음과 같습니다.

// 고수준 모듈과 저수준 모듈이 모두 의존할 중심 틀입니다.
interface MessageSender {
    sendMessage(message: string): void;
}

// [저수준 모듈] 새로운 알림 수단이 추가되어도 인터페이스만 맞춰서 만들면 됩니다.
class NaverSmsService implements MessageSender {
    public sendMessage(message: string): void {
        console.log(`[네이버 API] SMS 전송: ${message}`);
    }
}

// [저수준 모듈] 
class KakaoTalkService implements MessageSender {
    public sendMessage(message: string): void {
        console.log(`[카카오 API] 알림톡 전송: ${message}`);
    }
}

// [고수준 모듈]

class NotificationService {
    // 💡 구체적인 클래스가 아닌, 추상화된 인터페이스(MessageSender)에만 의존합니다.
    private messageSender: MessageSender;

    // 외부에서 의존성을 주입(Dependency Injection)받도록 설계합니다.
    constructor(messageSender: MessageSender) {
        this.messageSender = messageSender;
    }

    public sendNotification(message: string): void {
        this.messageSender.sendMessage(message);
    }
}

// 클라이언트 사용

function run() {
    // 1. 네이버 SMS를 사용하고 싶을 때
    const naverSms = new NaverSmsService();
    const service1 = new NotificationService(naverSms);
    service1.sendNotification("안녕하세요! 네이버 SMS입니다.");

    // 2. 카카오톡으로 수단을 바꾸고 싶을 때 (NotificationService의 코드는 전혀 변경 없음)
    const kakaoTalk = new KakaoTalkService();
    const service2 = new NotificationService(kakaoTalk);
    service2.sendNotification("안녕하세요! 카카오톡 알림입니다.");
}

run();

이 DIP 원칙의 장점을 생각해 보면… 비지니스 로직(고수준 모듈)의 변경 없이 저수준 모듈을 변경하기 용이해 집니다.