싱글톤 패턴의 유혹과 함정: 왜 모던 아키텍처는 의존성 주입(DI)을 선택했는가?

📌 이 글의 핵심 내용

  • 싱글톤(Singleton) 패턴이 '안티 패턴'으로 불리는 이유 (테스트와 결합도 문제)
  • 제어의 역전(IoC)과 의존성 주입(DI)을 통한 우아한 해결책
  • GoF의 '싱글톤 패턴'과 Spring/NestJS의 '싱글톤 빈(Bean)'의 결정적 차이
  • 테스트 가능한 코드를 위한 리팩토링 예제

객체 지향 프로그래밍(OOP)을 처음 배울 때 가장 먼저 접하는 디자인 패턴 중 하나가 바로 싱글톤(Singleton)입니다. "애플리케이션 전체에서 단 하나의 인스턴스만 존재함을 보장한다"는 개념은 데이터베이스 연결이나 설정 관리자 등을 만들 때 매우 매력적으로 들립니다.

하지만 실무 경험이 쌓일수록 개발자들은 고전적인 싱글톤 패턴을 기피하게 됩니다. 왜 그럴까요? 그리고 Spring이나 NestJS 같은 모던 프레임워크는 이 문제를 어떻게 해결했을까요?

싱글턴 패턴, 의존성 주입

1. 고전적 싱글톤의 치명적 단점 (Anti-Pattern)

우리가 흔히 Java나 C++ 교과서에서 배우는 getInstance() 방식의 싱글톤은 현대 애플리케이션 개발에서 독이 될 수 있습니다.

① 숨겨진 의존성 (Hidden Dependency)

가장 큰 문제는 의존 관계가 코드 내부에 숨어버린다는 것입니다.

public void processOrder() { // 이 메소드만 봐서는 DatabaseManager가 필요한지 알 수 없음 // 코드 깊숙한 곳에서 전역 상태를 끌어다 씀 (강한 결합) DatabaseManager.getInstance().connect(); }

함수의 시그니처(파라미터)만 보고는 이 함수가 무엇을 필요로 하는지 알 수 없습니다. 코드를 한 줄 한 줄 다 읽어봐야만 "아, 여기서 DB를 쓰는구나" 하고 알 수 있습니다.

② 단위 테스트(Unit Test)의 지옥

싱글톤은 전역 상태(Global State)를 가집니다. 테스트 A에서 싱글톤 객체의 데이터를 변경하면, 그 상태가 테스트 B에도 그대로 남아있습니다.

  • 테스트 순서에 따라 결과가 달라지는 비결정적(Non-deterministic) 테스트가 됩니다.
  • 가짜 객체(Mock)로 대체하기가 매우 어렵습니다. getInstance()는 static 메소드라 오버라이딩이 안 되기 때문입니다.

2. 해결책: 의존성 주입 (Dependency Injection)

이 문제를 해결하기 위해 등장한 것이 DI(Dependency Injection)입니다. 객체가 필요한 의존성을 스스로 찾거나 만들지 않고, "외부에서 넣어주는(주입하는)" 방식입니다.

public class OrderService { private final DatabaseManager dbManager; // 생성자를 통해 외부에서 주입받음 (명시적 의존성) public OrderService(DatabaseManager dbManager) { this.dbManager = dbManager; } public void processOrder() { dbManager.connect(); } }

이제 OrderService는 DatabaseManager가 싱글톤인지, 매번 새로 생성되는지 알 필요가 없습니다. 그저 누군가 넣어준 것을 쓸 뿐입니다. 이를 통해 느슨한 결합(Loose Coupling)이 달성됩니다.

3. 프레임워크의 마법: Singleton Registry

"그럼 싱글톤은 아예 안 쓰나요? 객체를 매번 생성하면 메모리 낭비 아닌가요?"

여기서 중요한 개념이 등장합니다. GoF의 싱글톤 패턴은 지양하지만, 스프링 컨테이너가 관리하는 싱글톤 빈(Singleton Bean)은 적극 권장합니다.

구분 GoF 싱글톤 패턴 스프링 싱글톤 빈
구현 방식 static 메소드, private 생성자 등 코드 레벨에서 강제 평범한 클래스(POJO)를 컨테이너가 1개만 생성해서 관리
테스트 용이성 나쁨 (Mocking 어려움) 좋음 (그냥 인터페이스로 갈아끼우면 됨)
결합도 강한 결합 (Tight Coupling) 느슨한 결합 (Loose Coupling)

Spring이나 NestJS 같은 IoC 컨테이너는 애플리케이션 시작 시 객체를 딱 한 번만 생성해서 보관(Registry)하고 있다가, 필요로 하는 곳에 주입해 줍니다. 개발자는 싱글톤 구현 코드를 짤 필요 없이 @Component나 @Injectable만 붙이면 됩니다.

4. Mock 객체를 이용한 테스트 예시

DI를 사용하면 테스트가 얼마나 쉬워지는지 보겠습니다.

@Test void orderTest() { // 1. 실제 DB 대신 가짜(Mock) 객체 생성 DatabaseManager mockDb = Mockito.mock(DatabaseManager.class); // 2. 의존성 주입 (생성자에 가짜를 넣음) OrderService service = new OrderService(mockDb); // 3. 테스트 실행 service.processOrder(); // 4. 검증: connect()가 호출되었는지 확인 verify(mockDb).connect(); }

만약 고전적 싱글톤을 썼다면 mockDb를 주입할 방법이 없어 실제 DB 연결을 시도하다가 테스트가 실패했을 것입니다.

5. 결론

싱글톤은 "필요악"이 아니라 "컨테이너의 역할"입니다.

객체를 하나만 유지하고 싶다면, 코드를 복잡하게 꼬아서 싱글톤 패턴을 구현하지 마십시오. 대신 DI 컨테이너에게 그 역할을 위임하고, 여러분의 코드는 순수한 POJO(Plain Old Java Object) 상태로 유지하십시오. 그것이 유연하고 테스트 가능한 아키텍처로 가는 지름길입니다.

이 블로그의 인기 게시물

Docker 컨테이너 'Connection Refused' (Errno 111) 오류 해결 가이드

이미지
🎯 타겟 독자: Docker 입문자, 컨테이너를 띄웠으나 localhost 로 접속이 안 되는 백엔드 개발자, MSA(마이크로서비스) 구축 중 통신 오류를 겪는 엔지니어. 📝 요약: Docker 접속 오류(Errno 111)의 90%는 애플리케이션이 '0.0.0.0'이 아닌 '127.0.0.1' 로 바인딩 되어 있거나, 포트 포워딩(-p) 설정이 누락되어 발생합니다. 이 글에서는 네트워크 인터페이스의 차이를 이해하고, 외부 접속을 허용하는 올바른 설정법을 정리합니다. 1. 문제 정의: "컨테이너는 떴는데 접속이 안 돼요" Docker 입문자들이 가장 흔하게 겪는 상황입니다. docker ps 로 확인하면 상태(STATUS)는 분명히 Up 인데, 브라우저나 Postman으로 접속하면 즉시 연결이 거부됩니다. curl: (7) Failed to connect to localhost port 8080: Connection refused Python: ConnectionRefusedError: [Errno 111] Connection refused 이 문제는 방화벽 때문이 아닙니다. "누구의 요청을 들을 준비가 되었는가(Listen Address)" 에 대한 설정이 잘못되었기 때문입니다. 2. 원인 분석: 127.0.0.1의 함정 핵심은 Loopback(127.0.0.1) 과 Any Address(0.0.0.0) 의 차이입니다. 로컬 PC에서 개발할 때 서버를 localhost 로 띄우는 건 보안상 좋은 습관입니다. 하지만 Docker 컨테이너는 독립된 IP를 ...
자세한 내용 보기

Redis 캐싱 전략 완벽 가이드: Look Aside부터 Write Back까지 (DB 부하 줄이기)

이미지
🎯 타겟 독자: 사용자가 몰릴 때마다 DB CPU가 100%를 치는 상황을 겪는 백엔드 개발자, Redis를 단순히 get/set 으로만 쓰고 있는 주니어 엔지니어. 📝 요약: 캐시(Cache)는 성능 향상의 치트키지만, 잘못 쓰면 데이터 불일치(Inconsistency) 라는 재앙을 부릅니다. 이 글에서는 가장 대중적인 Look Aside(Lazy Loading) 패턴과 쓰기 성능을 극대화하는 Write Back 패턴의 작동 원리, 장단점, 그리고 언제 무엇을 써야 하는지 명확한 기준을 제시합니다. 1. 캐싱 패턴이 왜 중요한가요? "그냥 Redis에 넣으면 되는 거 아닌가요?"라고 묻는다면 반은 맞고 반은 틀립니다. 캐시를 데이터베이스(DB)와 어떤 순서로 연동하느냐에 따라 시스템의 데이터 정합성 과 성능 이 완전히 달라지기 때문입니다. 2. 패턴 ① Look Aside (Lazy Loading) - 국룰 전략 현업에서 80% 이상 사용되는 가장 일반적인 읽기 전략입니다. 캐시를 옆(Aside)에 두고 필요할 때만 데이터를 가져옵니다. 작동 순서 앱이 데이터를 찾을 때 먼저 캐시(Redis)를 찌릅니다. 캐시에 데이터가 있으면(Cache Hit) 바로 반환합니다. (DB 부하 0) 없으면(Cache Miss) DB에서 조회 하여 가져옵니다. 가져온 데이터를 캐시에 저장 하고 반환합니다. public User getUser(Long id) { // 1. 캐시 조회 User user = redisTemplate.opsForValue().get("user:" +...
자세한 내용 보기

브라우저 렌더링 원리: Reflow와 Repaint 최적화 가이드 (CRP 심층 분석)

이미지
📌 핵심 요약 CRP(Critical Rendering Path) 의 5단계: DOM → CSSOM → Render Tree → Layout → Paint 성능의 주범 Reflow(Layout) 와 Repaint 의 차이점 애니메이션 성능 최적화: 왜 top/left 대신 transform 을 써야 하는가? (GPU 가속과 Composite) "사용자가 주소창에 URL을 입력하고 엔터를 쳤을 때, 화면에 네이버 메인이 뜨기까지 무슨 일이 일어나는가?" 이 질문은 네트워크 관점(DNS, TCP/IP)에서도 답변할 수 있지만, 프론트엔드 개발자라면 렌더링 엔진(Rendering Engine)이 HTML과 CSS를 해석해서 픽셀로 바꿔주는 과정, 즉 CRP(Critical Rendering Path)를 설명할 수 있어야 합니다. 이 원리를 알아야 "왜 리액트가 Virtual DOM을 쓰는지", "왜 애니메이션이 버벅이는지" 이해할 수 있습니다. 1. 렌더링 파이프라인 (The Pipeline) 브라우저는 다음 5단계를 거쳐 화면을 그립니다. DOM 트리 생성: HTML 문서를 파싱 하여 태그 간의 관계(부모-자식)를 트리 구조로 만듭니다. CSSOM 트리 생성: CSS 파일과 인라인 스타일을 파싱 하여 스타일 규칙 트리를 만듭니다. Render Tree 생성: DOM과 CSSOM을 결합하여 "실제로 화면에 표시될 노드" 만 추려냅니다. Layout (Reflow): 각 노드가 화면의 어느 위치에, 어떤 크기(px) 로 배치될지 기하학적 계산을 수행합니다. ...
자세한 내용 보기