테크커런트

Java에서 반복적으로 작성해야 하는 메서드들, 예를 들어 getter, setter, toString, 생성자 같은 것들로 인해 코드가 길어지는 것이 고민이신가요?

Lombok은 이러한 반복 코드를 어노테이션 한 줄로 자동 생성해주는 강력한 라이브러리입니다. 이 글에서는 Lombok의 주요 어노테이션을 한 번에 정리해드립니다.

💡 Lombok 설정 방법

// build.gradle
configurations {
    compileOnly {
        extendsFrom annotationProcessor
    }
}

dependencies {
    annotationProcessor 'org.projectlombok:lombok'
    compileOnly 'org.projectlombok:lombok'

    testAnnotationProcessor 'org.projectlombok:lombok'
    testCompileOnly 'org.projectlombok:lombok'
}

🧩 주요 Lombok 어노테이션 정리

🔹 @Getter, @Setter

• 클래스나 필드에 사용 가능
• 접근자(getter), 설정자(setter) 자동 생성

@Getter
@Setter
private String name;

🔹 @NoArgsConstructor, @AllArgsConstructor, @RequiredArgsConstructor

• 생성자 자동 생성
  • @NoArgsConstructor → 기본 생성자
  • @AllArgsConstructor → 모든 필드 포함 생성자
  • @RequiredArgsConstructor → final 필드 + @NonNull 필드만 포함

@RequiredArgsConstructor
private final String name;

🔹 @ToString

• toString() 메서드를 자동 생성
• 특정 필드를 제외할 수 있음

@ToString(exclude = "password")
private String password;

🔹 @EqualsAndHashCode

• equals() 및 hashCode() 자동 생성
• callSuper = true 옵션으로 부모 클래스 필드 포함 여부 설정 가능

🔹 @Data

• @Getter, @Setter, @ToString, @EqualsAndHashCode, @RequiredArgsConstructor 를 한 번에 적용

✅ 정리

💡 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 패턴을 사용하지 않을 때 (위험)

🔎 접근자(Accessor)란?

객체 지향 프로그래밍(OOP)에서는 객체가 가진 **프로퍼티(속성)**에 직접 접근하기보다,
메서드를 통해 안전하게 접근하는 것을 권장합니다.
이때 사용하는 메서드가 바로 **접근자(Accessor)**입니다.

✅ 접근자가 필요한 이유

user.name = "Steve";  // ❌ 직접 접근

이처럼 필드에 직접 접근하게 되면:

• 데이터 무결성을 보장할 수 없고,
• 나중에 로직을 추가하거나 디버깅하기 어려워집니다.

→ 그래서 우리는 Getter와 Setter를 통해 간접 접근을 유도합니다.

🧩 Getter / Setter 정의

• Getter: 특정 속성 값을 읽을 때 사용
• Setter: 특정 속성 값을 변경할 때 사용

✅ Java 예시

public class User {
    private String name;
    private int age;

    // Getter
    public String getName() {
        return name;
    }

    // Setter
    public void setName(String name) {
        this.name = name;
    }

    public int getAge() {
        return age;
    }

    public void setAge(int age) {
        this.age = age;
    }
}

→ 위와 같이 getName(), setName() 메서드를 통해
외부에서 안전하게 name 필드를 조회/수정할 수 있습니다.

📚 정리

접근자는 객체 캡슐화의 핵심이며,
이 원칙을 지킴으로써 객체의 상태를 안정적으로 관리할 수 있습니다.

📋 본문

오늘은 많은 백엔드/프론트엔드 개발자분들이 헷갈려하는 개념, Stateful과 Stateless의 차이점에 대해 설명드리려 합니다.
서버 아키텍처를 설계할 때 정말 자주 나오는 주제이니, 끝까지 읽어보시면 많은 도움이 되실 거예요!

✅ 1. 정의부터 확실하게!

✅ 2. 장단점 비교

🔹 Stateful

• 장점:
  • 로그인 상태 유지 등 기능 구현이 쉬움
  • MMORPG 같은 실시간 상호작용 서비스에 유리
• 단점:
  • 서버에 리소스 부담
  • 서버 간 세션 공유 어려움 → Scale-out 불리

🔹 Stateless

• 장점:
  • 서버 확장, 로드밸런싱, 캐시 활용 용이
  • REST API, 클라우드 환경에 적합
• 단점:
  • 매 요청 시 상태 정보 포함 → 네트워크 자원 사용 ↑
  • 클라이언트 측 부담 ↑

✅ 3. 서비스 예시로 이해하기

✅ 4. 기술적 이슈 요약

✅ 5. 마무리 요약

• Stateful: 기능 구현은 쉽지만 서버에 부담, 확장성 떨어짐
• Stateless: 구현 복잡하지만 성능, 확장성, 클라우드에 유리
• 선택 기준: 서비스의 실시간성/확장성/안정성에 따라 결정!

🌐 프록시란 무엇인가요?

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

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

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

🔹 1. Service Interface

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

🔹 2. Proxy

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

🔹 3. Real Service

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

🧠 활용 사례

✅ 장점 요약

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

⚠️ 단점도 존재합니다

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

💡 실제 사용 예

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

스프링에서 수동으로 빈을 등록 할때 @Configuration 클래스 안에 @Bean을 사용한다. 왜 그런지 살펴보자.

● @Configuration 안에 @Bean을 사용하는 이유, proxyBeanMethods

 - @Bean 어노테이션을 이용한 수동 빈 등록

스프링에선 일반적으로 컴포넌트 스캔을 이용해 자동으로 빈을 등록하는 방법을 이용한다. 하지만 @Bean 어노테이션을 사용해 수동으로 빈을 등록해야 할 때도 있다.

• 개발자가 직접 제어가 불가능한 라이브러리를 활용할 때
• 애플리케이션 전 범위적으로 사용되는 클래스를 등록할 때
• 다형성을 활용하여 여러 구현체를 등록해야 할 때

 @Bean을 이용한 수동 빈 메소드는 스프링 빈 안에만 구현되어 있다면 모두 동작한다. 하지만 스프링은 @Bean은 반드시 @Configuration 어노테이션 활용하도록 하는데, 그 이유는 @Configuration에 특별한 부가 기능이 적용되기 때문이다.

●  @Configuration 에 적용되는 프록시 패턴

- @Configuration 어노테이션 안에는 @Component 어노테이션이 붙어 있어 @Configuration이 붙어있는 클래스 역시 스프링 빈으로 등록이 된다. 그럼에도 스프링이 @Configuration을 만든 이유는 CGLib으로 프록시 패턴을 적용해 수동으로 등록하는 스프링 빈이 반드시 싱글톤으로 생성됨을 보장하기 위해서다.

public class Resource {}

위 클래스를 @Component를 이용해 자동으로 빈 등록을 한다면 스프링이 해당 크래스의 객체의 생성을 제어하게 되고(제어의 역전, IoC) 하나의 객체만 생성되도록 컨트롤 할 수 있다. 하지만 위의 클래스를 @Bean을 이용해 직접 빈으로 등록해준다고 하면, 우리는 다음과 같이 해당 빈 등록 메소드를 여러 번 호출할 수 있게 된다.

@Configuration
public class MyBeanConfiguration { 

    @Bean 
    public Resource resource() {
        return new Resource(); 
    } 
    
    @Bean 
    public MyFirstBean myFirstBean() { 
        return new MyFirstBean(resource()); 
    } 
    
    @Bean 
    public MySecondBean mySecondBean() { 
        return new MySecondBean(resource()); 
    } 
}

 실수로 위와 같이 빈을 생성하는 메소드를 여러 번 호출 했다면 불필요하게 여러 개의 빈이 생성이 된다. 스프링은 이러한 문제를 방지하고자 @Configuration이 있는 클래스를 객체로 생성할 때 CGLib을 사용해 프록시 패턴을 적용한다. 그래서 @Bean이 있는 메소드를 여러 번 호출하여도 항상 동일한 객체를 반환하여 싱글톤을 보장한다.

@Configuration
public class MyBeanConfigurationProxy extends MyBeanConfiguration {

    private Object source;

    @Override
    public Resource resource() {
        if (resource == null) {
            source = super.resource();
        }
        return source;
    }

    @Override
    public MyFirstBean myFirstBean() {
        return super.myFirstBean();
    }

    @Override
    public MySecondBean mySecondBean() {
        return super.mySecondBean();
    }
}

 CGLib은 상속을 통해 프록시를 구현하므로 위와 같이 프록시가 구현 됬다고 이해 할 수 있다. 물론 이렇게 생성이 되는건 아니라 내부 클래스를 사용하는 등의 차이가 있으므로 이해를 돕기 위한 코드로 보면 된다.

●  싱글톤 여부를 제어하기 위한 proxyBeanMethods

 대부분 @Bean에 의한 수동 빈 등록을 할 때 싱글톤으로 생성되기를 원한다. 하지만 @Bean 메소드를 호출할 때 의도적으로 매번 다른 객체가 생성되기를 바랄 수 있다. 그럴 경우엔 @Configuration 어노테이션이 갖고 있는 proxyBeanMethods를 false로 주면 된다.

@Configuration(proxyBeanMethods = false)
public class MyBeanConfigurationProxy extends MyBeanConfiguration {

    private Object source;

    @Override
    public Resource resource() {
        if (resource == null) {
            source = super.resource();
        }
        return source;
    }

    @Override
    public MyFirstBean myFirstBean() {
        return super.myFirstBean();
    }

    @Override
    public MySecondBean mySecondBean() {
        return super.mySecondBean();
    }
}

https://mangkyu.tistory.com/234

 기존의 스프링 MVC에서는 xml을 활용하여 Bean을 등록하고 있었다.

 하지만 프로젝트의 규모가 커짐에 따라 사용하는 요소들은 xml에 등록하는 것이 상당히 번거로워 져서 어노테이션 기반의 Bean 등록 방법이 탄생하게 되었다. Bean을 등록하기 위한 @Bean, @Component, @Configuration 어노테이션에 대하여 알아보자.

● Spring Bean이란?

- 스프링에서 스프링의 DI Container에 의해 관리되는 POJO(Plain Old Java Object)를 Bean이라고 부른다. 이러한 Bean들이 스프링을 구성하는 핵심 요소이다.

• POJO(Plain Old Java Object)로써 스프링 애플리케이션을 구성하는 핵심 객체이다.
• 스프링 IoC 컨테이너(또는 DI 컨테이너)에 의해 생성 및 관리된다.
• class, id, scope, constructor-arg 등 주요 속성으로 지닌다.

● 스프링 빈 구성요소

- class : Bean으로 등록할 Java 클래스

- id : Bean의 고유 식별자

- scope : Bean을 생성하기 위한 방법(singleton, prototype 등)

- constructor-arg : Bean 생성 시 생성자에 전달할 파라미터

- property : Bean 생성 시 setter에 전달할 인수

● Spring Bean 등록 방법(@Bean, @Configuration, @Component)

다음과 같은 클래스를 스프링 컨테이너에 등록 해보자.

public class Resource {}

 이 클래스를 빈으로 등록하기 위해선 명시적으로 설정 클래스에서 @Bean 어노테이션을 사용해 수동으로 스프링 컨테이너에 빈을 등록하는 방법이있다. @Configuration 어노테이션을 클래스에 붙여주면 된다. @Bean을 사용해 수동으로 빈을 등록할 때에는 메소드 이름으로 빈 이름이 결정된다.

@Configuration
public class ResourceConfig {

	@Bean
    public Resource resource() {
    	return new Resource();
    }
}

 스프링 컨테이너는 @Configuration이 붙어있는 클래스를 자동으로 등록해두고, 해당 클래스를 파싱해서 @Bean이 있는 메소드를 찾아 빈을 생성한다. 다른 임의의 클래스를 만들어 @Bean을 붙인다고 되는것이 아니고, 반드시 @Bean을 사용하는 클래스에는 @Configuration 어노테이션을 활용하여 해당 클래스에서 Bean을 등록하고자 함을 명시해 줘야 한다.

수동으로 빈을 직접 등록해야 하는 상황이라면 다음과 같은 기준으로 한다.

• 개발자가 직접 제어가 불가능한 라이브러리를 활용할 때
• 애플리케이션 전 범위적으로 사용되는 클래스를 등록할 때
• 다형성을 활용하여 여러 구현체를 등록해야 할 때

 만약 우리가 객체를 JSON메시지로 변경하기 위해 Gson과 같은 외부 라이브러리를 사용한다고 하자. 그러면 해당 클래스를 싱글톤 빈으로 등록해 줘야 1개의 객체만 생성하여 여러 클래스가 공유함으로 메모리 상의 이점을 얻을 수 있다. 그런데 해당 클래스는 우리가 만든게 아니라 가져다 사용하는 클래스 일 뿐 불가피하게 @Bean으로 등록 해줘야만 한다.

@Bean을 사용하는 이점은 한 눈에 파악하여 유지보수하기가 쉽기 때문이다. 예를 들자면 구현체를 빈으로 등록 할때 어떠한 구현체들이 빈으로 등록됬는지 파악하기 위해서 @Configuration 클래스만 찾아보면 되기 때문이다.

● Component

수동으로 직접 빈을 등록 하는 작업은 빈으로 등록하는 클래스가 많아 질수록 상당한 시간을 차지하고 생산력 저하로 이루어질 것이다. 이때 스프링에서 특정 어노테이션이 있는 클래스를 찾아 빈으로 등록해 주는 컴포넌트 스캔 기능이 있다.

 스프링은 컴포넌트 스캔(Component Scan)을 이용해 @Component 어노테이션이 있는 클래스들을 찾아 빈으로 등록을 한다. 우리가 직접 개발한 클래스를 빈으로 편리하게 등록 해야만 하는 경우에는 @Component 어노테이션을 활요하면 된다.

public class Resource {}

@Component를 갖는 어노테이션으로는 @Controller, @Service, @Repository 이 있으며 @Configuration도 @Component를 갖고 있다.

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Component
public @interface Configuration {

    @AliasFor(annotation = Component.class)
    String value() default "";

    boolean proxyBeanMethods() default true;

}

 스프링은 기본적으로 컴포넌트 스캔을 이용한 자동 빈 등록 방식을 권장한다. 또한 직접 개발한 클래스는 @Component를 통해 해당 클래스를 빈으로 등록함을 노출하는 것이 좋다. 이유는 해당 클래스에 있는 @Component만 보면 해당 빈이 등록이 되도록 설정 되었는지를 파악 할수 있기 때문이다. 위와 같이 수동으로 해야하는 경우를 제외한 대부분의 경우 자동 등록 방식을 사용하자.

그리고 @Component를 이용하면 Main 또는 App 클래스에서 @ComponentScan으로 컴포넌트 스캔 범위를 지정해 줘야한다. 그러나 SpringBoot를 이용한다면 @SpringBootConfiguration에 기본적으로 포함되어 있어 별도의 설정이 필요 없다.

● 간단 정리

 - @Bean, @Configuration

• 수동으로 스프링 컨테이너에 빈을 동록하는 방법
• 개발자가 직접 제어가 불가능한 라이브러리를 빈으로 등록할 때 불가피하게 사용
• 유지보수성을 높이기 위해 애플리케이션 전 범위적으로 사용되는 클래스나 다형성을 활용하여 여러 구현체를 빈으로 등록 할 때 사용
• 1개 이상의 @Bean을 제공하는 클래스의 경우 반드시 @Configuration을 명시해 줘야 싱글톤이 보장된다.

 - @Component

• 자동으로 스프링 컨테이너에 빈을 등록하는 방법
• 스프링의 컴포넌트 스캔 기능이 @Component 어노테이션이 있는 클래스를 자동으로 찾아 빈으로 등록한다.
• 대부분의 경우 @Component를 이용한 자동 등록 방식을 사용하는 것이 좋다.
• @Component 하위 어노테이션으로 @Configuration, @Controller, @Service, @Repository  등이 있다.

https://mangkyu.tistory.com/75?category=761302 

Java에서 자주 마주치는 static 키워드, 정확히 어떤 역할을 하고 어떻게 동작할까요?
이번 포스트에서는 static 키워드의 메모리 구조, 특징, 사용 예시까지 한 번에 정리해 드립니다.

✅ static이란?

• static은 클래스 로딩 시 메모리에 한번만 할당되고,
  프로그램이 종료될 때까지 공유되고 유지되는 자원입니다.
• 객체를 생성하지 않아도 클래스명으로 직접 접근할 수 있다는 것이 특징입니다.

🧠 static의 메모리 구조

🔸 static은 GC의 대상이 아니며, 모든 인스턴스가 공유합니다.

📌 static 변수/메소드 특징

• 클래스 변수 (모든 객체가 공통으로 사용)
• 객체 생성 없이도 사용 가능 (클래스명.변수, 클래스명.메서드)
• 자주 사용하면 메모리 누수 위험 존재 (GC가 해제하지 않음)

✅ Java 코드 예시

public class Calculator {
    public static String calName = "myBoard";

    public static int add(int x, int y) {
        return x + y;
    }

    public int min(int x, int y) {
        return x - y;
    }
}

☑ 사용 예시

Calculator.add(5, 1);  // ✅ 객체 없이 사용 가능
Calculator.min(5, 1);  // ❌ 오류 (static 아님)

Calculator cal = new Calculator();
cal.add(5, 1);  // 가능은 하지만 ❗비권장
cal.min(5, 1);  // 정상 사용

⚠ static 사용 시 주의사항

• 전역 상태처럼 작동하므로 남용 시 테스트 어려움, 의존성 증가
• 웹 서버 환경에서는 동시성 이슈 발생 가능성
• 주로 공용 유틸성 클래스 또는 상수 선언에 사용