[Java] 싱글톤 패턴의 활용과 한계

베하~

BTC 블랙아웃입니다!

 

 

지난 포스팅에서는 싱글톤 패턴의 구현 방법과 취약점 그리고 대응 방법에 대해 살펴봤습니다. 이번 포스팅에서는 싱글톤 패턴의 활용 사례, 그리고 그 한계에 대해 깊게 다뤄보고자 합니다.

---

지난 포스팅

https://btcd.tistory.com/1300

[Java] 싱글톤 패턴 구현하는 방법

 

https://btcd.tistory.com/1304

[Java]싱글톤 패턴 깨트리는 방법 및 대응 방법

---

1. 싱글톤 패턴의 활용

싱글톤 패턴은 '단 하나'의 인스턴스만을 유지해야 하는 경우에 주로 활용됩니다. 예를 들면,

• 데이터베이스 연결 객체: DB 연결은 자원을 많이 소모하는 작업이기 때문에, 여러 번 연결을 생성하는 것보다는 하나의 연결을 재사용하는 것이 좋습니다.
• 로깅: 여러 부분에서 공통적으로 사용하는 로그 객체를 하나만 생성해, 성능과 메모리 사용을 최적화할 수 있습니다.
• 캐시: 공유 자원으로서의 캐시를 관리할 때 싱글톤 패턴이 유용합니다.

 

2. 싱글톤 패턴의 한계

하지만 이렇게 유용한 싱글톤 패턴에도 단점이 있습니다.

• 전역 상태: 싱글톤은 애플리케이션 내의 전역 상태를 만들 수 있어, 상태 관리가 복잡해질 수 있습니다.

💡 사례: 서비스 내에서 사용자 세션을 싱글톤으로 관리하는 경우, 사용자 A와 B가 동시에 로그인을 시도했을 때 B의 세션 데이터가 A의 것으로 덮어쓰여 버릴 수 있습니다.
결과: 사용자 A는 사용자 B의 데이터에 접근할 수 있게 되는 보안 문제가 발생합니다.

• 테스트 어려움: 단위 테스트를 진행할 때 싱글톤 객체는 전역 상태 때문에 다른 테스트 케이스에 영향을 줄 수 있습니다.

💡 사례: 싱글톤 객체가 DB 연결을 관리하는 경우, 단위 테스트 중에 실제 데이터베이스에 접근해야 할 상황이 발생할 수 있습니다.
결과: 단위 테스트가 아닌 통합 테스트가 되어버리며, 테스트가 느려지고 데이터베이스에 부정적인 영향을 미칠 수 있습니다.

• 확장성 제한: 상속이나 확장이 어려워질 수 있습니다.

💡 사례: 싱글톤 객체를 확장하려고 할 때, 다른 부분의 코드에 영향을 주지 않고 확장하기 어렵습니다. 예를 들어, 데이터베이스 연결을 관리하는 싱글톤 객체를 확장하여 로깅 기능을 추가하려고 하면, 다른 부분에서 데이터베이스 연결만을 기대하고 사용하던 코드에 문제가 발생할 수 있습니다.
결과: 기존 코드를 많이 수정해야 하는 유지 보수의 부담이 증가합니다.

3. 싱글톤 패턴의 한계 극복 전략

싱글톤의 테스트 어려움과 확장성의 한계를 극복하기 위해, 많은 개발자들은 의존성 주입(Dependency Injection) 패턴을 선호하게 되었습니다. 이는 객체의 생성과 조립을 외부 컨테이너가 담당하도록 하는 패턴으로, 객체 간의 느슨한 결합을 통해 유연성과 확장성을 향상시킬 수 있습니다.

 

---

결론적으로, 싱글톤 패턴은 특정 상황에서는 매우 강력한 도구로 작용할 수 있지만, 그 한계 또한 확실합니다. 따라서 패턴을 적용할 때에는 그 한계와 장점을 함께 고려하여, 애플리케이션의 상황에 맞게 가장 적합한 설계 방법을 선택해야 합니다.

이상으로 포스팅을 마치겠습니다.

감사합니다!