싱글턴 패턴 제대로 쓰는 법 – 전역 인스턴스의 정석

“딱 한 번만 만든 뒤, 모두가 함께 쓰자”

 

왜 싱글턴인가?

작고 단순한 CLI Todo 앱도 데이터 저장소‧로그 시스템‧설정 값 같은 공통 객체가 생깁니다. 매번 new를 호출해 중복 인스턴스를 만들면 메모리와 동기화 비용이 눈덩이처럼 불어나죠. 그래서 “전역에서 한 벌만” 쓰도록 보장하는 싱글턴 패턴이 등장했습니다. 실제로 Naver D2의 테스트 아티클도 “글로벌 객체를 싱글턴으로 만들면 목(Mock) 교체가 편하다”는 점을 강조합니다

---

대표 적용부위: TaskRepository

CLI Todo 앱에서 모든 명령이 접근하는 작업 목록 저장소를 예로 들어봅시다.

public class TaskRepository {
    private static final TaskRepository INSTANCE = new TaskRepository(); // eager 초기화

    private TaskRepository() { }    // 외부 생성을 막는다

    public static TaskRepository getInstance() {
        return INSTANCE;
    }

    // CRUD 메서드 …
}

• 장점: 전역 접근이 가능하면서도 메모리 누수를 방지.
• 주의: 테스트마다 상태가 남을 수 있으니, JUnit에서는 DI 컨테이너나 리플렉션으로 인스턴스를 교체해 주입하세요.

---

싱글턴 패턴 3가지 구현 전략

1. Eager Initialization – 클래스 로딩 시 즉시 생성
   • 단순‧Thread-safe.
   • 사용하지 않아도 인스턴스가 메모리를 차지.
2. Lazy Initialization + synchronized – 필요할 때 첫 생성
   

   public static synchronized TaskRepository getInstance() {
       if (instance == null) instance = new TaskRepository();
       return instance;
   }

   
   
   • 초기 부하 ↓, 하지만 매 호출마다 동기화 비용 ↑.
3. Enum Singleton (Effective Java 추천)
   

   public enum TaskRepository {
       INSTANCE;
       // 메서드 작성…
   }

   
   
   • 자바 직렬화·리플렉션 공격까지 자연스럽게 방어.
   • 단, 상속이 불가하므로 유연성이 약간 떨어진다.

 

 

Velog 인기 글에서도 위 세 가지를 비교하며 “Enum 방식이 가장 안전하다”는 결론을 자주 볼 수 있습니다

---

언제 쓰면 좋은가?

• 애플리케이션 전역에서 공통된 상태를 공유해야 할 때
  (예: 캐시, 로그어댑터, DB 커넥션 풀)
• 객체 생성 비용이 큰 리소스를 재사용하고 싶을 때
• 스레드 간 동일 자원을 보장해야 할 때

언제 피해야 할까?

• 글로벌 상태로 테스트가 어려워질 때 → DI가 더 낫습니다.
• 요청마다 다른 컨텍스트가 필요한 Web 애플리케이션.
• 동시성 제어가 까다로울 때: 잘못 구현하면 멀티스레드 환경에서 두 개 이상이 생성될 위험이 있습니다.

---

실전 팁

1. DI 프레임워크가 있다면 먼저 DI를 고려하세요. Spring Container 기본 스코프가 사실상 싱글턴입니다.
2. 테스트 코드에서 reset() 메서드나 리플렉션으로 인스턴스를 교체할 수 있도록 테스트 전용 훅을 마련해 두면 좋습니다.
3. 자바 17+라면 Record + Enum 싱글턴으로 불변성을 강화할 수 있습니다.

---

결론

싱글턴은 “전역 인스턴스”를 단순하면서도 강력하게 보장합니다. 그러나 글로벌 상태가 늘어날수록 시스템 결합도가 높아진다는 점을 잊지 마세요. “한 개만 있으면 되나?”를 스스로 묻고, 필요할 때만 신중히 적용하면 작고 단단한 Todo 앱부터 대규모 서버까지 든든한 뼈대를 마련할 수 있습니다.