디자인 패턴, 안티 패턴, 그리고 싱글톤을 바라보는 균형 잡힌 시각
소프트웨어 개발의 역사는 문제 해결의 역사라고 할 수 있다. 개발자들은 끊임없이 복잡한 문제를 마주하고, 이를 반복적으로 해결하면서 자연스럽게 축적된 경험과 방법론을 체계화해왔다. 이 과정에서 태어난 것이 바로 **디자인 패턴(Design Pattern)**이다. 디자인 패턴은 특정한 코드 조각이라기보다는, 비슷한 맥락에서 반복적으로 등장하는 문제를 해결하기 위해 검증된 설계 아이디어에 가깝다. 흔히 “GoF(Gang of Four)” 책에서 정리된 패턴들을 떠올리지만, 그것만이 전부는 아니다. 실제 업계에서는 책에 실리지 않은 패턴도 자주 쓰이고, 같은 패턴이 다른 이름으로 불리기도 한다. 중요한 것은 특정 코드나 클래스 다이어그램을 외우는 것이 아니라, 맥락에 맞는 해결 원리를 이해하고 응용하는 것이다.
그런데 흥미로운 점은, 어떤 방식이 자주 쓰이더라도 그것이 반드시 좋은 방법은 아니라는 것이다. **안티 패턴(Anti-Pattern)**이라는 개념은 바로 이런 아이러니에서 출발한다. 안티 패턴은 업계에서 흔히 쓰이지만, 결과적으로는 문제를 해결하기보다는 더 크게 만드는 접근 방식을 뜻한다. 즉, “자주 쓰인다”는 점에서는 디자인 패턴과 비슷하지만, “효율성과 적합성이 떨어진다”는 점에서 결정적으로 다르다. 단기적으로는 편리해 보여도, 장기적으로 유지보수성·확장성을 심각하게 해치게 되므로 피해야 하는 방식이 된다.
이 지점에서 가장 많이 논의되는 주제가 바로 **싱글톤(Singleton)**이다. 싱글톤은 전통적으로 디자인 패턴 중 하나로 분류된다. 특정 클래스의 인스턴스를 프로그램 전체에서 단 하나만 유지하도록 보장하는 방식이다. 하지만 많은 개발자들은 이것을 오히려 안티 패턴에 가깝다고 본다. 왜냐하면 싱글톤은 사실상 전역 변수의 객체지향 버전에 불과하기 때문이다. 코드 전반에 싱글톤이 남용되면 구조가 무너지고, 의존성이 얽히며, 테스트가 어려워진다. 특히 SOLID 원칙에 위배된다는 비판은 오래도록 제기되어 왔다. 1990년대 말과 2000년대 초에는 이런 논쟁이 절정에 달했고, “싱글톤은 안티 패턴이다”라는 주장이 적지 않았다.
그러나 시간이 지나면서 이 문제를 바라보는 시각은 좀 더 현실적으로 변했다. 실제로 하나만 존재해야 하는 객체는 소프트웨어 시스템 안에 반드시 존재한다. 파일 시스템 관리자, 리소스 매니저, 설정 관리자 등이 그렇다. 대규모 제품을 만들면서 “싱글톤을 전혀 쓰지 않는다”는 것은 거의 불가능에 가깝다. 게다가 의존성 주입(DI) 같은 현대적인 프레임워크 역시, 내부적으로는 싱글톤 스코프를 활용해 객체 생명주기를 관리한다. 즉, “나는 싱글톤을 쓰지 않는다”라고 말하는 개발자조차도 사실은 프레임워크에 내장된 싱글톤 덕분에 편리함을 누리고 있는 경우가 많다.
결국 싱글톤은 본래 디자인 패턴으로 출발했으며, 잘못 사용될 때만 안티 패턴처럼 기능한다. 문제는 개념 그 자체가 아니라 사용 방식과 남용 여부다. “싱글톤은 무조건 안티 패턴이다”라는 주장은 지나치게 단순화된 시각이다. 중요한 것은 맥락이다. 어떤 상황에서는 싱글톤이 필수적이고, 또 다른 상황에서는 대안을 고려해야 한다. 마치 약이 되기도 하고 독이 되기도 하는 것처럼, 싱글톤은 어떻게 사용하느냐에 따라 그 가치가 달라진다.
1. 디자인 패턴
•
반복적으로 발생하는 문제를 해결하기 위해 정형화된 설계 아이디어
•
GoF 패턴이 대표적이지만, 그것만이 정답은 아님
•
맥락과 필요에 따라 변형·활용하는 것이 핵심
2. 안티 패턴
•
자주 쓰이지만 결과적으로 문제를 키우는 방식
•
더 나은 대안이 있음에도 비효율적 접근을 고집하는 경우
•
단기적 편리함 
장기적 유지보수성 악화
장기적 유지보수성 악화3. 싱글톤 논쟁
•
다수설: 디자인 패턴이다
•
소수설: 안티 패턴이다 (특히 90~2000년대 초에 활발했던 주장)
4. 싱글톤을 안티 패턴으로 보는 이유
•
전역 변수의 OOP 버전에 불과
•
남용 시 코드 구조 붕괴, 테스트 어려움
•
SOLID 원칙 위배 논란 존재
5. 현실 속 싱글톤의 필요성
•
반드시 하나만 있어야 하는 객체 존재 (파일 시스템, 리소스 매니저 등)
•
대규모 제품에서 “싱글톤 0개”는 사실상 불가능
•
외부 프레임워크도 싱글톤 스코프를 내부적으로 사용
6. 결론
•
싱글톤은 본래 디자인 패턴
•
하지만 잘못 쓰면 안티 패턴처럼 작동
•
중요한 것은 “무조건 좋다/나쁘다”가 아니라 맥락과 절제된 사용
•
디자인 패턴: 업계 합의된 문제 해결 방법론
•
안티 패턴: 자주 쓰이지만 비효율적이고 더 나은 대안이 있는 방식
•
싱글톤: 본래 디자인 패턴이지만, 남용하면 안티 패턴처럼 변질됨