SOLID 트러블슈팅 실전 가이드

SOLID 원칙 위반 시 발생하는 실제 문제들과 해결 방법을 다룹니다. 각 원칙별로 흔히 발생하는 안티패턴과 리팩토링 전략을 코드로 보여드립니다.

---

---

들어가며

이 글에서는 SOLID 트러블슈팅 실전 가이드에 대해 상세히 알아보겠습니다. 총 12가지 주요 개념을 다루며, 각각의 개념에 대한 설명과 실제 코드 예제를 함께 제공합니다.

목차

1. SRP_위반_God_Class_리팩토링
2. OCP_위반_if_else_지옥_탈출
3. LSP_위반_예외_처리_문제_해결
4. ISP_위반_Fat_Interface_분리
5. DIP_위반_의존성_역전_적용
6. SRP_테스트_불가능한_코드_개선
7. OCP_Enum_Switch_리팩토링
8. LSP_Null_반환_예외_처리
9. ISP_Adapter_패턴_활용
10. DIP_Service_Locator_안티패턴_제거
11. SOLID_종합_리팩토링_Before_After
12. SOLID_실전_체크리스트

---

1. SRP 위반 God Class 리팩토링

개요

하나의 클래스가 너무 많은 책임을 가지면 유지보수가 어려워집니다. 단일 책임 원칙으로 분리하는 방법을 알아봅니다.

코드 예제

// Before: God Class
class UserManager {
  saveUser(user: User) { /* DB 저장 */ }
  sendEmail(user: User) { /* 이메일 발송 */ }
  generateReport(user: User) { /* 리포트 생성 */ }
}

// After: SRP 적용
class UserRepository {
  save(user: User) { /* DB 저장 */ }
}
class EmailService {
  send(user: User) { /* 이메일 발송 */ }
}
class ReportGenerator {
  generate(user: User) { /* 리포트 생성 */ }
}

설명

각 클래스가 하나의 명확한 책임만 가지도록 분리하여 변경에 대한 영향도를 최소화합니다. 테스트와 유지보수가 훨씬 쉬워집니다.

---

2. OCP 위반 if else 지옥 탈출

개요

새로운 타입 추가 시마다 if-else를 수정하면 OCP 위반입니다. 다형성으로 확장에는 열려있고 수정에는 닫혀있게 만듭니다.

코드 예제

// Before: OCP 위반
function calculateDiscount(type: string, price: number) {
  if (type === 'vip') return price * 0.8;
  if (type === 'member') return price * 0.9;
  return price;
}

// After: OCP 적용
interface DiscountStrategy {
  calculate(price: number): number;
}
class VipDiscount implements DiscountStrategy {
  calculate(price: number) { return price * 0.8; }
}
class MemberDiscount implements DiscountStrategy {
  calculate(price: number) { return price * 0.9; }
}

설명

전략 패턴을 사용하여 새로운 할인 정책 추가 시 기존 코드 수정 없이 새 클래스만 추가하면 됩니다. 확장성이 크게 향상됩니다.

---

3. LSP 위반 예외 처리 문제 해결

개요

자식 클래스가 부모 클래스의 계약을 위반하면 예상치 못한 버그가 발생합니다. 리스코프 치환 원칙을 준수하는 방법을 알아봅니다.

코드 예제

// Before: LSP 위반
class Rectangle {
  setWidth(w: number) { this.width = w; }
  setHeight(h: number) { this.height = h; }
}
class Square extends Rectangle {
  setWidth(w: number) { this.width = this.height = w; } // 예상과 다름!
}

// After: LSP 적용
interface Shape {
  area(): number;
}
class Rectangle implements Shape {
  constructor(private width: number, private height: number) {}
  area() { return this.width * this.height; }
}
class Square implements Shape {
  constructor(private side: number) {}
  area() { return this.side * this.side; }
}

설명

상속 대신 인터페이스를 사용하여 각 도형이 독립적으로 동작하도록 합니다. 치환 시 예상치 못한 동작이 발생하지 않습니다.

---

4. ISP 위반 Fat Interface 분리

개요

사용하지 않는 메서드를 강제로 구현하게 만드는 비대한 인터페이스는 ISP 위반입니다. 작고 명확한 인터페이스로 분리합니다.

코드 예제

// Before: ISP 위반
interface Worker {
  work(): void;
  eat(): void;
  sleep(): void;
}
class Robot implements Worker {
  work() { /* 작업 */ }
  eat() { throw new Error('로봇은 먹지 않음'); } // 불필요한 구현
  sleep() { throw new Error('로봇은 자지 않음'); }
}

// After: ISP 적용
interface Workable { work(): void; }
interface Eatable { eat(): void; }
interface Sleepable { sleep(): void; }
class Robot implements Workable {
  work() { /* 작업 */ }
}
class Human implements Workable, Eatable, Sleepable {
  work() { /* 작업 */ }
  eat() { /* 식사 */ }
  sleep() { /* 수면 */ }
}

설명

인터페이스를 역할별로 분리하여 클라이언트가 필요한 메서드만 구현하도록 합니다. 불필요한 의존성이 사라집니다.

---

5. DIP 위반 의존성 역전 적용

개요

구체 클래스에 직접 의존하면 변경에 취약해집니다. 추상화에 의존하여 결합도를 낮추는 방법을 알아봅니다.

코드 예제

// Before: DIP 위반
class EmailNotification {
  send(msg: string) { /* 이메일 발송 */ }
}
class UserService {
  private notification = new EmailNotification(); // 구체 클래스에 의존
  notify(msg: string) { this.notification.send(msg); }
}

// After: DIP 적용
interface Notification {
  send(msg: string): void;
}
class EmailNotification implements Notification {
  send(msg: string) { /* 이메일 발송 */ }
}
class UserService {
  constructor(private notification: Notification) {} // 추상화에 의존
  notify(msg: string) { this.notification.send(msg); }
}

설명

의존성 주입을 통해 추상화에 의존하도록 변경합니다. SMS, Push 등 다른 알림 방식으로 쉽게 교체할 수 있습니다.

---

6. SRP 테스트 불가능한 코드 개선

개요

여러 책임이 뒤섞인 코드는 단위 테스트가 불가능합니다. SRP를 적용하여 테스트 가능한 코드로 만듭니다.

코드 예제

// Before: 테스트 불가능
class OrderProcessor {
  process(order: Order) {
    const db = new Database(); // 하드코딩된 의존성
    db.save(order);
    const email = new EmailSender();
    email.send(order.userEmail);
    const logger = new Logger();
    logger.log('주문 처리 완료');
  }
}

// After: 테스트 가능
class OrderProcessor {
  constructor(
    private repo: OrderRepository,
    private emailer: EmailService,
    private logger: Logger
  ) {}
  process(order: Order) {
    this.repo.save(order);
    this.emailer.send(order.userEmail);
    this.logger.log('주문 처리 완료');
  }
}

설명

의존성을 외부에서 주입받아 각 책임을 분리합니다. Mock 객체를 사용한 독립적인 단위 테스트가 가능해집니다.

---

7. OCP Enum Switch 리팩토링

개요

enum과 switch문은 새로운 타입 추가 시 모든 switch를 수정해야 합니다. 다형성으로 해결하는 방법을 알아봅니다.

코드 예제

// Before: OCP 위반
enum PaymentType { CARD, CASH, CRYPTO }
function processPayment(type: PaymentType, amount: number) {
  switch(type) {
    case PaymentType.CARD: return processCard(amount);
    case PaymentType.CASH: return processCash(amount);
    case PaymentType.CRYPTO: return processCrypto(amount);
  }
}

// After: OCP 적용
interface PaymentProcessor {
  process(amount: number): void;
}
class CardPayment implements PaymentProcessor {
  process(amount: number) { /* 카드 결제 */ }
}
class CashPayment implements PaymentProcessor {
  process(amount: number) { /* 현금 결제 */ }
}
const processor: PaymentProcessor = new CardPayment();
processor.process(10000);

설명

각 결제 방식을 독립적인 클래스로 분리하여 새로운 결제 수단 추가 시 기존 코드를 전혀 수정하지 않아도 됩니다.

---

8. LSP Null 반환 예외 처리

개요

부모 메서드가 null을 반환하지 않는데 자식이 null을 반환하면 LSP 위반입니다. Null Object 패턴으로 해결합니다.

코드 예제

// Before: LSP 위반
class UserFinder {
  find(id: string): User { /* User 반환 */ }
}
class CachedUserFinder extends UserFinder {
  find(id: string): User | null { // null 반환 가능 - 계약 위반!
    const cached = cache.get(id);
    return cached || null;
  }
}

// After: LSP 적용 (Null Object)
class NullUser extends User {
  isNull() { return true; }
}
class CachedUserFinder extends UserFinder {
  find(id: string): User {
    const cached = cache.get(id);
    return cached || new NullUser(); // 항상 User 타입 반환
  }
}

설명

Null Object 패턴을 사용하여 항상 유효한 객체를 반환합니다. 클라이언트 코드에서 null 체크가 불필요해집니다.

---

9. ISP Adapter 패턴 활용

개요

외부 라이브러리의 비대한 인터페이스를 그대로 사용하면 ISP 위반입니다. Adapter로 필요한 부분만 노출합니다.

코드 예제

// Before: ISP 위반
import { HugeExternalLibrary } from 'external-lib';
class MyService {
  constructor(private lib: HugeExternalLibrary) {} // 100개 메서드
  doWork() {
    this.lib.method1(); // 실제로는 1-2개만 사용
  }
}

// After: ISP 적용 (Adapter)
interface SimpleInterface {
  doSomething(): void;
}
class ExternalLibAdapter implements SimpleInterface {
  constructor(private lib: HugeExternalLibrary) {}
  doSomething() { this.lib.method1(); }
}
class MyService {
  constructor(private adapter: SimpleInterface) {}
  doWork() { this.adapter.doSomething(); }
}

설명

Adapter 패턴으로 필요한 기능만 노출하는 간단한 인터페이스를 만듭니다. 의존성이 최소화되고 테스트가 쉬워집니다.

---

10. DIP Service Locator 안티패턴 제거

개요

Service Locator는 숨겨진 의존성을 만들어 DIP를 위반합니다. 명시적인 의존성 주입으로 개선합니다.

코드 예제

// Before: Service Locator 안티패턴
class ServiceLocator {
  static get<T>(key: string): T { /* 서비스 반환 */ }
}
class OrderService {
  process() {
    const repo = ServiceLocator.get<OrderRepo>('repo'); // 숨겨진 의존성
    repo.save();
  }
}

// After: 명시적 DI
interface OrderRepository {
  save(order: Order): void;
}
class OrderService {
  constructor(private repo: OrderRepository) {} // 명시적 의존성
  process(order: Order) {
    this.repo.save(order);
  }
}
const service = new OrderService(new OrderRepoImpl());

설명

생성자를 통해 의존성을 명시적으로 주입받습니다. 클래스의 의존성이 명확해지고 테스트와 유지보수가 쉬워집니다.

---

11. SOLID 종합 리팩토링 Before After

개요

모든 SOLID 원칙을 위반한 레거시 코드를 단계적으로 개선하는 실전 예제입니다.

코드 예제

// Before: 모든 SOLID 위반
class OrderManager {
  createOrder(data: any) {
    // 검증, 저장, 이메일, 로깅 모두 한곳에 (SRP 위반)
    if (data.type === 'vip') { /* 타입별 분기 */ } // OCP 위반
    const db = new MySQL(); // 구체 클래스 의존 (DIP 위반)
  }
}

// After: SOLID 준수
interface OrderRepository { save(order: Order): void; }
interface NotificationService { notify(order: Order): void; }
class OrderService {
  constructor(
    private repo: OrderRepository,
    private notifier: NotificationService
  ) {}
  create(order: Order) {
    this.repo.save(order);
    this.notifier.notify(order);
  }
}

설명

각 책임을 분리하고, 추상화에 의존하며, 확장 가능한 구조로 변경합니다. 유지보수성과 테스트 용이성이 크게 향상됩니다.

---

12. SOLID 실전 체크리스트

개요

코드 리뷰 시 SOLID 원칙 위반 여부를 빠르게 체크할 수 있는 실용적인 가이드입니다.

코드 예제

// SOLID 위반 체크리스트
class CodeReview {
  checkSRP(cls: any): boolean {
    // 클래스명에 'Manager', 'Handler'가 있나? (위험 신호)
    // 메서드가 5개 이상인가? (책임 과다 의심)
    return cls.methods.length <= 5;
  }

  checkOCP(fn: Function): boolean {
    // if-else, switch가 많은가? (확장성 부족)
    return !fn.toString().includes('switch');
  }

  checkDIP(cls: any): boolean {
    // new 키워드가 생성자 밖에 있나? (구체 의존)
    return !cls.toString().match(/new \w+\(/g);
  }
}

설명

실제 코드 리뷰에서 사용할 수 있는 휴리스틱입니다. 이 체크리스트로 SOLID 위반 코드를 빠르게 발견할 수 있습니다.

---

마치며

이번 글에서는 SOLID 트러블슈팅 실전 가이드에 대해 알아보았습니다. 총 12가지 개념을 다루었으며, 각각의 사용법과 예제를 살펴보았습니다.

관련 태그

#TypeScript #SOLID #Refactoring #DesignPatterns #CleanCode