No-Name

Java에서 하나의 공통 자원을 공유하려 할 때 static 키워드와 Singleton 패턴은 자주 비교됩니다.
두 방식은 비슷해 보이지만, 메모리 처리, 객체화 여부, 유지보수성에서 큰 차이가 있습니다.

이 글에서는 두 개념의 본질적인 차이와 언제 어떤 방식이 적합한지를 명확히 정리해드립니다.

✅ static이란?

• 클래스 로딩 시 Method Area에 한번만 할당
• 객체 생성 없이 클래스명으로 직접 접근 가능
• 공통 유틸리티나 상수 정의에 적합

public class Util {
    public static int add(int a, int b) {
        return a + b;
    }
}

Util.add(3, 5);  // 객체 없이 바로 사용

✅ Singleton이란?

Singleton 구현 방식은 내 블로그 - Java Singleton 패턴 설명 포스트를 참고해주세요.

• 객체를 하나만 생성하도록 보장하는 디자인 패턴
• 지연 생성(Lazy Initialization) 가능
• 상태를 유지할 수 있으며, 다형성 사용 가능

🧠 static vs Singleton 비교

✅ 언제 static을 쓰고 언제 Singleton을 써야 할까?

🔹 static이 적합한 경우

• 상태가 필요 없는 순수 유틸성 로직
• 계산기능, 공통 상수, 로그 포맷 등

🔹 Singleton이 적합한 경우

• 상태 저장이 필요한 공용 객체
• 의존성 주입이 필요한 서비스, DB 연결 등

🎯 결론

• static: 단순하고 빠르지만 유연하지 않음
• Singleton: 설계는 복잡하지만 유연성과 확장성이 좋음

상황에 맞는 선택이 유지보수성과 테스트 효율성을 크게 좌우합니다.

💡 PRG 패턴이란?

PRG(Post-Redirect-Get) 패턴은 웹 개발에서 POST 요청 후 직접 응답하지 않고, 다른 URL로 리다이렉트한 후 GET 요청을 유도하는 방식입니다.
즉, 사용자의 POST 요청 처리 후 바로 페이지를 반환하는 대신, 3XX Redirect 응답으로 GET 요청을 유도하는 구조입니다.

❗ 왜 PRG 패턴이 필요할까?

1. ⚠️ 새로고침으로 인한 중복 요청 방지

• PRG를 사용하지 않으면
  POST 요청 후 바로 HTML 페이지를 응답할 경우, 사용자가 새로고침(F5) 하면 같은 POST 요청이 서버에 다시 전송됨
• 예시:
  • 온라인 쇼핑몰에서 결제 후 새로고침 시 → 중복 결제 발생 가능 😨

2. 🧭 URL 공유 및 북마크가 불가능

• POST 요청은 URL에 직접 접근할 수 없기 때문에, 북마크나 공유가 불가능
• PRG 패턴은 GET 요청으로 연결되므로 URL 공유 및 즐겨찾기 가능

🔄 PRG 패턴 흐름도

[1] 사용자가 Form을 제출 → (POST)
        ↓
[2] 서버가 처리 후 Redirect 응답 (3xx) → /result
        ↓
[3] 브라우저가 자동으로 GET 요청 → /result
        ↓
[4] /result 페이지 렌더링

✅ PRG 패턴을 사용할 때 (권장 시나리오)

❌ PRG 패턴을 사용하지 않을 때 (위험)

🌐 프록시란 무엇인가요?

프록시(Proxy) 패턴은 다른 객체를 대신해 행동하는 객체를 말합니다.
가장 흔한 예로 우리가 자주 접하는 프록시 서버가 있습니다.
프록시는 클라이언트와 실제 서비스 객체 사이의 중계자 역할을 수행합니다.

프록시는 클라이언트가 직접 실제 객체에 접근하지 못하도록 중간에서 대리 처리하는 보호막입니다.

📘 프록시 패턴의 구조 (UML 클래스 다이어그램)

🔹 1. Service Interface

• 서비스의 공통 인터페이스를 정의합니다.
• 실제 객체와 프록시 객체가 모두 이 인터페이스를 구현합니다.

🔹 2. Proxy

• 실제 서비스 객체에 대한 **참조(Reference)**를 갖습니다.
• 클라이언트는 프록시를 통해 마치 진짜 서비스 객체처럼 사용할 수 있습니다.
• 프록시는 흐름 제어나 접근 제어만 담당하며 결과를 조작하지는 않습니다.

🔹 3. Real Service

• 실제로 비즈니스 로직을 처리하는 핵심 객체입니다.

🧠 활용 사례

✅ 장점 요약

• 🔐 보안성 향상: 실제 객체에 대한 직접 접근을 차단
• 🌐 원격 접근 지원: 원격 객체를 로컬처럼 다룰 수 있음
• ⚡ 성능 최적화: 무거운 객체를 캐싱 또는 지연 초기화 가능

⚠️ 단점도 존재합니다

• 🐢 초기 응답 지연: lazy initialization 시 응답 속도 저하
• 🧩 구조 복잡성 증가: 객체 구조가 복잡해질 수 있음

💡 실제 사용 예

• 웹 프록시 서버
• 스프링 AOP 프록시
• 데이터베이스 연결 풀 (Connection Proxy)
• 보안 접근 필터

🎯 개발자라면 꼭 알아야 할 디자인 패턴! MVC란?

**MVC(Model-View-Controller)**는 소프트웨어 개발에서 **관심사의 분리(Separation of Concerns)**를 구현하는 대표적인 디자인 패턴입니다.

• 비즈니스 로직과 화면, 입력 제어를 독립적으로 구성할 수 있어 유지보수성이 매우 뛰어납니다.

📌 MVC 구성 요소

🔹 Model (모델)

• 앱이 다뤄야 할 데이터와 비즈니스 로직을 담당합니다.
• 데이터가 변경되면 일반적으로 뷰(View)와 컨트롤러(Controller)에 알려줍니다.
• ✅ 예: 품목 이름, 가격, 수량 등 쇼핑 리스트의 항목 데이터

🔹 View (뷰)

• 사용자에게 보여지는 UI를 담당합니다.
• 데이터를 직접 처리하지 않고, 모델에서 전달받은 데이터만 표시합니다.
• ✅ 예: 쇼핑 항목 리스트를 표 형태로 보여주는 HTML 화면

🔹 Controller (컨트롤러)

• 사용자의 **입력(클릭, 요청 등)**을 받아,
  적절한 모델을 호출하고 뷰를 갱신하는 역할을 합니다.
• ✅ 예: "장바구니에 담기" 버튼 클릭 → 컨트롤러가 해당 품목을 모델에 추가하고, 뷰를 새로고침

🛒 MVC 예제 - 쇼핑 리스트 앱

쇼핑리스트 앱을 예로 들면 다음과 같이 MVC로 나눌 수 있어요.

✅ MVC 패턴의 장점

• 🔧 유지보수가 쉬움: 각 구성 요소가 독립적이라 변경이 용이
• 🧩 협업에 유리: 역할 분리가 명확해 프론트/백엔드 개발자 협업에 이상적
• 🚀 재사용성과 확장성 증가

MVC패턴, 디자인패턴, 모델뷰컨트롤러, Model View Controller, 백엔드기초, 소프트웨어아키텍처, 쇼핑리스트예제, Java MVC, Spring MVC, 웹개발패턴

✔️ 싱글톤이란?

싱글톤(Singleton) 패턴은 클래스의 인스턴스를 단 하나만 생성하도록 보장하는 디자인 패턴입니다.
객체가 계속해서 생성되는 것처럼 보여도, 실제로는 최초에 생성된 하나의 인스턴스만을 반환합니다.

💡 싱글톤 구현 예제 (Lazy Initialization 방식)

public class Singletone {

    private static Singletone singletone;

    // 생성자를 private으로 막아 외부에서 new로 생성 불가
    private Singletone() {}

    public static Singletone getInstance() {
        if (singletone == null) {
            singletone = new Singletone();
        }
        return singletone;
    }
}

📌 핵심 포인트:

• private static 으로 클래스 내부에 단 하나의 인스턴스를 보관
• 외부에서 new Singletone() 호출 불가능 (생성자 private)
• getInstance() 메서드를 통해서만 인스턴스에 접근 가능
• 필요할 때만 초기화하는 지연 초기화(Lazy Initialization) 방식 사용

⚠️ 싱글톤 패턴 사용 시 주의사항

1. 객체를 2개 이상 생성하지 않도록 철저히 차단해야 함
   • 생성자를 private으로 감춰야 함
2. 상태를 유지하지 않는 Stateless 설계가 중요
   • 필드를 통해 상태를 가지면 여러 사용자 간 충돌 위험
   • 예: 웹 애플리케이션에서 사용자별 데이터를 필드로 저장하면 큰일 남 😱
3. Spring을 사용한다면 걱정할 필요 없음
   • 기본적으로 모든 Bean은 싱글톤 범위로 관리됨
   • @Component, @Service, @Repository 등 사용 시 자동 적용
4. 공유되지 않는 데이터는 지역 변수 또는 ThreadLocal 사용
   • 예: 사용자 요청에 따른 데이터를 처리할 때는 필드 대신 메서드 파라미터 사용

🧠 결론

• 싱글톤은 자원을 절약하고, 전역적으로 동일한 인스턴스를 공유할 수 있어 유용합니다.
• 그러나 잘못 사용할 경우 상태 공유로 인한 오류 발생 가능성이 있으므로, Stateless 설계를 철저히 해야 합니다.
• Spring에서는 기본이 싱글톤이지만, 상태 관리만 잘 하면 안전하게 사용 가능!