[iOS] Singleton 싱글톤 패턴이란 무엇이고, 단점과 대안은 무엇인가?

What Is a Singleton and How To Create One In Swift

Are Singletons Bad

이 글은 위의 두 문서에 기반하여 직접 정리한 글입니다.😷

---

싱글톤 패턴은 소프트웨어 개발에 매우 널리 사용되는 디자인 패턴이지만, 안티패턴으로 고려되어진다. 그 이유를 살펴보자.

싱글톤 패턴이란 무엇인가

싱글톤 패턴은 클래스의 인스턴스가 단 하나만 생성되도록 하는 패턴이다.

프로그램에서 어떤 시점에서도 그 클래스의 인스턴스는 딱 하나만 존재하도록 보장하는 것이 싱글톤 패턴의 목적이다.

예를 들면, 애플의 프레임워크에서는 아래와 같은 객체들이 싱글톤으로 사용된다.

// Shared URL Session
let sharedURLSession = URLSession.shared

// Default File Manager
let defaultFileManager = FileManager.default

// Standard User Defaults
let standardUserDefaults = UserDefaults.standard

// Default Payment Queue
let defaultPaymentQueue = SKPaymentQueue.default()

전역 접근

싱글톤 패턴은 전역 접근(global access)이 가능하다는 특징이 있으며, 이것은 싱글톤 패턴의 부작용이기도 하다.

전역 접근은 “프로젝트의 모든 객체가 이 객체에 접근할 수 있음”을 의미한다. 이것은 편리하지만 그만큼의 부작용이 따른다.

싱글톤 패턴을 어떻게 만드는가

static 키워드를 사용해 만들 수 있다.

싱글톤 만들기 - (1) static 프로퍼티와 private 생성자

class NetworkManager {

    // MARK: - Properties

    static let shared = NetworkManager(baseURL: API.baseURL)

    // MARK: -

    let baseURL: URL

    // Initialization

    private init(baseURL: URL) {
        self.baseURL = baseURL
    }

}

• 생성자가 private이다.
  • 오직 클래스 자기 자신만이 자신의 인스턴스를 생성할 수 있다.
• shared 라는 이름의 static 상수 프로퍼티로 클래스의 인스턴스를 생성한다.
  • 이 프로퍼티를 통해 다른 객체들이 싱글톤 객체에 접근할 수 있다.
• static 프로퍼티는 이미 lazy로 동작하므로, lazy 키워드가 필요없다.

사용하기 (1)

func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey: Any]?) -> Bool {
    print(NetworkManager.shared)
    return true
}

싱글톤객체.shared 와 같이 사용하면 된다.

싱글톤 만들기 - (2) private static 클로저와 class 메서드

class NetworkManager {

    // MARK: - Properties

    private static var sharedNetworkManager: NetworkManager = {
        let networkManager = NetworkManager(baseURL: API.baseURL)

        // Configuration
        // ...

        return networkManager
    }()

    // MARK: -

    let baseURL: URL

    // Initialization

    private init(baseURL: URL) {
        self.baseURL = baseURL
    }

    // MARK: - Accessors

    class func shared() -> NetworkManager {
        return sharedNetworkManager
    }

}

위의 방법보다 약간 더 복잡한 방식이다.

• private static property를 클로저로 생성
  • 싱글톤 객체의 초기화를 클로저 내에서 진행한다. 이를 통해 싱글톤 객체에 대한 더 복잡한 초기화와 구성을 할 수 있다.
• shared() 클래스 메서드를 통해 싱글톤 객체에 접근할 수 있다.

사용하기 (2)

func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey: Any]?) -> Bool {
    print(NetworkManager.shared())
    return true
}

싱글톤객체.shared() 와 같이 사용하면 된다.

싱글톤 패턴의 단점 - 편의성 때문에 투명성을 희생하다

싱글톤을 사용하면 반드시 편의성 때문에 투명성을 희생하게 된다.

소프트웨어에서 “편의성”은 우선순위 상위에 존재하지 않는다. 즉 편의성보다 투명성이 더 중요하다.

예를 들어 프로젝트 내에서 사용자 관리를 해야 한다고 생각해 보자.
즉 사용자 객체가 생성되고 관리되어야 한다.
이 문제를 해결하기 위해 싱글톤 패턴을 사용한다면 - 한 번에 오직 한 명의 사용자만이 로그인할 수 있다.

싱글톤 패턴을 사용하는 것이 더 나을 때도 있지만, 단점이 장점보다 훨씬 많다. 처음에는 단점이 매우 미묘하기 때문에, 많은 개발자들이 싱글톤 패턴을 잘못 사용하게 된다.

싱글톤 패턴의 가장 중요한 단점은 편의성 때문에 투명성을 희생한다는 것이다. 지난 예제와 같이, 시간이 지날수록 싱글톤 객체에 접근하는 객체를 추적할 수 없게 된다. 그리고, 더 중요한 것은, 싱글톤 객체의 프로퍼티를 수정하는 객체들도 추적할 수 없게 된다.

프로젝트에서 싱글톤 객체를 사용하면서 당신은 기술부채(technical debt)를 만들기 시작하게 된다. 싱글톤은 접근하기 너무 쉽기 때문에 바이러스처럼 퍼져나가는 경향이 있다. 싱글톤 객체가 어디에서 쓰이고 있는지 추적하는 것은 어려우며, 크고 복잡한 프로젝트에서 싱글톤을 제거하는 것은 리팩토링 지옥이 될 수 있다. 싱글톤 패턴이 한 번 프로젝트에 사용되기 시작하면, 더 많은 싱글톤 없이 프로젝트를 나아가게 하는 것이 어려워진다.

싱글톤의 또 다른 단점은 테스트이다. 싱글톤 객체에 의존하는 객체는 강한 결합으로 인해 단위 테스트가 어려워진다.

싱글톤 패턴을 조금 더 투명하게 사용하는 법

싱글톤 객체를 필요로 하는 객체에게 의존성 주입 방식으로 싱글톤 객체를 전달하면 좀더 투명하게 사용할 수 있다.

클래스의 인터페이스가 자신의 의존성을 설명하게 되기 때문이다. 즉, 클래스가 자신을 생성하기 위해 어떤 객체들을 필요로 하는지 명확하게 보여준다. 프로젝트 구조는 유연하고 느슨하게 결합된 것처럼 보일 수 있지만, 실제로는 전혀 그렇지 않다.

싱글톤 패턴의 대안 - 의존성 주입 (dependency injection)

싱글톤을 대체할 수 있는 것은 의존성 주입이다.

의존성 주입의 가장 중요한 장점은 투명성(transparency) 이다. 이는 싱글톤의 장점인 편의성보다 더 나은 장점이다.

예를 들어, 어떤 객체가 역할을 수행하는 데에 user객체를 필요로 한다면, 그 user객체는 의존성으로서 주입되어야 한다. 코드로 작성하자면 아래와 같다.

class User {
    var firstName = ""
    var lastName = ""
}

class NetworkController {

    let user: User

    init(user: User) {
        self.user = user
    }

}

의존성 주입 방식은 스니펫을 통해, 모든 개발자들이 NetworkController를 사용할 때 유효한 User 인스턴스에 의존할 것임을 알 수 있다.

이는 참조로 객체를 전달하는 방법(passing an object by reference)으로도 알려져 있다.

의존성 주입은 당장은 덜 편리할지 몰라도, 장기적으로 큰 이익이 된다. 코드 기반의 명확성을 더해주기 때문에 어떤 객체가 어떤 객체에 의존하고 있는지를 정확하게 보여준다.

또한 의존성 주입이 덜 편리하다는 점이 이점이 되기도 한다. 당신이 더 신중하게 결정하도록 만들기 때문이다. NetworkController 객체가 User 객체에 대해 직접 접근하는 대신, 이름과 비밀번호만 전달하는 걸로 충분할 수도 있지 않은가? 이처럼 의존성 주입은 타입의 요구사항을 정의하기 위한 매우 유용한 도구가 된다.

결론

싱글톤 패턴 자체에 본질적인 문제가 있는 것은 아니다. 싱글톤은 제대로 사용된다면 본질적으로 나쁘지 않다.

하지만 대부분의 개발자들이 “편리함”이라는 잘못된 이유 때문에 싱글톤 패턴을 사용하는 것이 문제인 것이다. 싱글톤 객체는 아무데서나 마음대로 접근하라고 만든 객체가 아니다.

싱글톤 패턴의 목적은 편리함이 아니라, 어떤 시점에도 클래스의 인스턴스가 단 한개만 존재하도록 보장하는 것이다. 싱글톤을 사용할 때는 이 목적을 반드시 염두에 두어야 한다.

정리하자면, 싱글톤 패턴은 매우 매우 제한적으로 사용되어야 한다.

만약 당신이 싱글톤 객체를 만드려고 한다면, 잠시 멈춰서 다른 선택지가 없는지 생각해봐야 한다. 싱글톤을 만드는 이유가 편리함 때문이라면, 싱글톤을 만들어서는 안된다.