VOIM 리팩토링: 싱글턴 패턴 도입기 (1~2단계)

Intro

1. 기존 문제점 분석

1. 다중 객체 생성 문제

// 각 서비스가 개별적으로 인스턴스화되어 상태가 불일치함
export const storageService = new StorageService();
export const settingsService = new SettingsService();
export const iframeService = new IframeService();

2. 의존성 관리 복잡성

// SettingsService 내부에서 직접 다른 서비스 참조
import { storageService } from "./storageService";

class SettingsService {
  async resetAllSettings(): Promise<void> {
    await storageService.resetAllSettings(); // 강한 결합
  }
}

3. 상태 불일치 발생

• 각 서비스가 개별적으로 Chrome Storage에 접근하며 서로의 상태를 모름
• 사용자 UI와 실제 설정 값 사이의 불일치가 발생함 (예: 폰트 크기 변경이 반영되지 않음)
• 특히 시각 장애인을 위한 접근성 관련 기능에서는 상태 동기화가 매우 중요했기에, 이 불일치는 UX 측면에서도 치명적이었습니다

2. 1단계: ServiceManager 클래스 설계 및 싱글턴 구현

📌 리팩토링 목표

• 모든 서비스 인스턴스를 중앙에서 관리하도록 설계
• 싱글턴 패턴을 통해 단 하나의 인스턴스만 유지하도록 구현
• ServiceManager가 초기화 로직을 포함하여 의존성 주입까지 처리함

구현 코드

export class ServiceManager {
  private static instance: ServiceManager | null = null;

  private storageService: StorageService;
  private settingsService: SettingsService;
  private iframeService: IframeService;

  private isInitialized: boolean = false;

  private constructor() {
    this.storageService = new StorageService();
    this.settingsService = new SettingsService();
    this.iframeService = new IframeService();
  }

  public static getInstance(): ServiceManager {
    if (!ServiceManager.instance) {
      ServiceManager.instance = new ServiceManager();
    }
    return ServiceManager.instance;
  }

  public async initialize(): Promise<void> {
    if (this.isInitialized) return;

    await this.storageService.loadInitialSettings();

    this.settingsService.setStorageService(this.storageService);
    this.iframeService.setStorageService(this.storageService);

    this.isInitialized = true;
  }

  public getStorageService(): StorageService {
    this.ensureInitialized();
    return this.storageService;
  }

  public getSettingsService(): SettingsService {
    this.ensureInitialized();
    return this.settingsService;
  }

  public getIframeService(): IframeService {
    this.ensureInitialized();
    return this.iframeService;
  }

  private ensureInitialized(): void {
    if (!this.isInitialized) {
      throw new Error("ServiceManager가 초기화되지 않았습니다. initialize()를 먼저 호출하세요.");
    }
  }
}

백그라운드 스크립트 초기화 변경

// src/background/index.ts
async function init() {
  try {
    const serviceManager = ServiceManager.getInstance();
    await serviceManager.initialize();

    initCommandListeners();
    initMessageListeners();
    initStorageListeners();
  } catch (error) {
    logger.error("백그라운드 스크립트 초기화 오류:", error);
  }
}

3. 2단계: 서비스 간 의존성 주입

리팩토링 전략

수정된 서비스들

StorageService

export class StorageService {
  private savedSettings: SavedSettings | null = null;
}

SettingsService

export class SettingsService {
  private storageService: StorageService | null = null;

  setStorageService(storageService: StorageService): void {
    this.storageService = storageService;
  }

  async resetAllSettings(): Promise<void> {
    if (!this.storageService) throw new Error("StorageService가 주입되지 않음");
    await this.storageService.resetAllSettings();
  }
}

IframeService

export class IframeService {
  private storageService: StorageService | null = null;

  setStorageService(storageService: StorageService): void {
    this.storageService = storageService;
  }
}

리스너 예시 (storageListeners.ts)

export function initStorageListeners(): void {
  chrome.storage.onChanged.addListener((changes, areaName) => {
    if (areaName !== "local") return;

    const manager = ServiceManager.getInstance();
    const storageService = manager.getStorageService();
    storageService.handleStorageChanges(changes);
  });
}

📌 구현 결과 요약

• 상태 일관성 확보: 모든 서비스가 ServiceManager를 통해 동일한 인스턴스를 참조
• 명확한 의존성 주입 구조: 설정과 storage 간의 결합도를 줄임
• 초기화 순서 제어: initialize() 시점 이후에만 서비스 접근 가능
• 테스트 가능성 향상: destroyInstance() 등을 통해 테스트 환경에서도 독립적인 초기화 가능

다음 단계 계획

3단계: 메시지 기반 통신 강화

• MessageService를 도입해 Background <-> Content 간 통신을 중앙화

4단계: 스토리지 접근 중앙화

• StorageService에서 캐싱 및 변경 알림을 제공하도록 개선

💡 리팩토링을 통해 얻은 인사이트

• 싱글턴 패턴은 전역 상태 관리에 효과적이다. 복수 인스턴스 생성으로 인한 상태 충돌을 예방할 수 있었다.
• DI(의존성 주입)는 테스트 가능성과 유연한 아키텍처 설계에 필수적이다. 향후 테스트와 확장성을 고려하면 반드시 도입해야 할 전략임을 체감했다.
• 초기화 순서의 통제는 서비스 안정성에 큰 영향을 미친다. 초기화 누락, 의존성 미주입 등의 문제를 명확히 방지할 수 있었다.
• 점진적인 리팩토링이 안정성과 생산성 모두를 높인다. 모든 코드를 한 번에 뜯어고치기보다, 단계적으로 개선하면서 기존 기능을 유지할 수 있었다.

마무리