곽코딩

카프카(Kafka) 기본 개념 정리 – 컨슈머와 리스너는 어떻게 다를까?

곽코딩루카 — Fri, 5 Dec 2025 17:36:27 +0900

목차
1. 카프카(kafka)란 무엇인가?
2. 초보 개발자가 가장 많이 헷갈리는 질문
3. 컨슈머와 리스너의 진짜 역할
4. 실제 동작 구조를 하나의 흐름으로 정리해보면
5. 헷갈리는 개념들을 한 번 더 정리하면
6. 카프카를 처음 도입하는 팀이라면

카프카(Kafka) 기본 개념 정리 – 컨슈머와 리스너는 어떻게 다를까?

최근에 회사 프로젝트에서 카프카(Kafka)를 도입하면서 가장 많이 부딪힌 부분이 바로 “컨슈머(Consumer)와 리스너(Listener)가 뭐가 다른가?”였다.
설계 문서를 보면 둘 다 메시지를 받고 처리하는 것처럼 보이는데, 실제로는 서로 완전히 다른 역할을 담당한다.
초보 개발자들이 가장 헷갈려 하는 부분이기도 해서, 처음 접하는 사람 기준으로 정리해본다.

1. 카프카(Kafka)란 무엇인가?

카프카는 여러 시스템 사이에서 데이터를 빠르고 안정적으로 전달하기 위한 메시지 스트리밍 플랫폼이다. 쉽게 말하면, 서비스들 사이에서 주고받는 데이터를 한 곳에 모아두고, 필요한 서비스가 가져다 쓰는 구조다.

HTTP API처럼 “서버 ↔ 서버”가 실시간으로 직접 통신하는 방식과 달리, 카프카는 중간 저장소(토픽) 에 데이터를 쌓아두고 다른 서비스가 이를 언제든 읽어갈 수 있게 만든다.
이 방식은 서비스 간 결합도를 낮추고, 장애나 지연이 생겨도 전체 시스템을 보호해주는 장점이 있다.

카프카의 핵심 구성 요소는 다음과 같다.

토픽(Topic) : 메시지를 종류별로 모아놓는 저장소
메시지(Message) : 실제 데이터
프로듀서(Producer) : 메시지를 카프카에 보내는 쪽
컨슈머(Consumer) : 메시지를 카프카에서 가져오는 쪽
브로커(Broker) : 카프카 서버
파티션(Partition) : 토픽을 병렬 처리하기 위해 쪼개놓은 단위
오프셋(Offset) : 메시지의 번호(위치)

여기까지는 공식 문서에서도 흔히 나오는 설명이지만, 문제는 이 다음 단계에서 많이 헷갈린다.

2. 초보 개발자가 가장 많이 헷갈리는 질문

카프카에서 메시지가 들어오면, 스프링 애플리케이션에 있는 리스너가 자동으로 실행된다.
이 때문에 흔히 이런 흐름을 상상하게 된다.

서비스 A가 메시지를 Kafka에 보냄
Kafka가 토픽을 확인한 뒤
스프링 서비스의 리스너에게 메시지를 “전달”해줌

하지만 실제 동작 방식은 이와 정반대다.
카프카는 메시지를 직접 보내주지 않는다.

3. 컨슈머와 리스너의 진짜 역할

3-1. 컨슈머(Consumer)란?

컨슈머는 카프카에서 메시지를 직접 가져오는 주체다.

중요한 사실은, Kafka는 메시지를 애플리케이션에게 “푸시”하지 않는다.

컨슈머가 지속적으로 “폴링(polling)”하여 메시지를 가져간다.

즉, “새 메시지 있나요?” 하고 Kafka에 계속 물어보는 역할을 담당하는 것이 컨슈머다.

이를 이해하는 순간 전체 구조가 확실히 잡힌다.

3-2. 리스너(Listener)란?

리스너는 스프링에서 제공하는 일종의 콜백 함수다.
컨슈머가 Kafka에서 메시지를 가져오면, 그 메시지를 전달받아서 비즈니스 로직을 처리하는 메소드가 바로 리스너다.

예를 들어 아래 코드처럼:

@KafkaListener(topics = "order-created")
public void handleOrder(String message) {
    // 메시지가 들어왔을 때 실행되는 로직
}

이 메소드 자체가 “리스너”다.
이 리스너는 메시지를 직접 읽지 않는다.
메시지를 읽는 행위는 컨슈머가 하고, 읽은 메시지를 리스너에게 전달해주는 역할을 스프링의 리스너 컨테이너가 대신한다.

4. 실제 동작 구조를 하나의 흐름으로 정리해보면

카프카를 처음 배울 때 가장 중요한 이해 포인트는 이 그림 하나로 정리된다.

Kafka  ← (pull) ←  Consumer  →  Listener 호출

흐름을 순서대로 보면 다음과 같다.

Producer가 Kafka의 특정 Topic에 메시지를 저장한다.
Spring 애플리케이션 내부의 Consumer가 Kafka에게 지속적으로 폴링한다.
Kafka에서 새 메시지가 발견되면 Consumer가 해당 메시지를 가져온다.
Consumer가 가져온 메시지를 Spring이 Listener 메소드에 전달한다.
Listener가 메시지를 기반으로 비즈니스 로직을 실행한다.

즉, 핵심은 카프카는 메시지를 직접 보내주지 않는다는 점이다.
메시지를 읽는 주체는 항상 컨슈머,
메시지를 처리하는 주체는 리스너다.

둘은 역할이 명확히 분리되어 있다.

5. 헷갈리는 개념들을 한 번 더 정리하면

● 카프카는 API 서버가 아니다

카프카에 “요청”을 보내는 것이 아니라,
Producer가 메시지를 보내고 Consumer가 가져가는 구조다.

● 리스너는 메시지를 읽지 않는다

리스너는 오직 “메시지가 전달되었을 때 실행되는 메소드”일 뿐이다.
실제 읽기(read)는 Consumer가 담당한다.

● 카프카는 push가 아니라 pull 방식이다

카프카가 Spring에 “보내주는 것처럼” 보이지만,
실제로는 스프링 내부의 Consumer가 카프카에서 계속 메시지를 가져오고 있을 뿐이다.

● Listener는 Spring이 만든 편의 기능

원래 Kafka에는 Listener라는 개념이 없다.
Spring Kafka가 Consumer에서 읽어온 메시지를 자동으로 메소드에 연결해주기 위해 만든 사용성 개선 기능이다.

6. 카프카를 처음 도입하는 팀이라면

실제 업무에서 카프카를 다루다 보면 Producer보다 Consumer가 훨씬 중요하다는 걸 느끼게 된다.
메시지 중복 처리, 오프셋 관리, 장애 복구 전략, 컨슈머 그룹 운영 등은 모두 Consumer 구조를 정확히 이해하는 것에서 출발한다.

특히 스프링을 사용한다면 “컨슈머가 메시지를 가져온 뒤 리스너에게 넘겨준다”는 구조를 명확히 이해하는 것이 전체 로직을 안정적으로 유지하는 데 큰 도움이 된다.

마무리

처음에는 나 역시 카프카가 메시지를 스프링 애플리케이션으로 직접 “보내주는” 방식이라고 오해했다.
하지만 내부 구조를 정확히 알고 나면, 컨슈머와 리스너가 왜 분리되어 있고 어떤 역할을 맡고 있는지 훨씬 명확하게 정리된다.

이 글이 카프카를 처음 접하는 개발자들에게 도움이 되길 바라며,
향후에는 실제 예제 코드와 함께 컨슈머 그룹 운영 방식, 파티션 전략, 재처리 로직 등 좀 더 깊은 내용을 다뤄볼 계획이다.

[Spring Boot] JUnit5 + Mockito 단위 테스트 기초 정리

곽코딩루카 — Thu, 27 Nov 2025 11:26:56 +0900

목차
0. 서론
1. 단위 테스트에서 우리가 하고 싶은 일
2. 아주 쉬운 예제로 시작해 보기
3. Mockito 기본 세팅
4. @Test, @DisplayName, @Nested – 테스트 구조 잡기
5. Mockito 기본 동작 – when/thenReturn, verify, verifyNoInteractions
6. 정리: 테스트 코드 작성 흐름
7. 마무리

0. 서론

@Mock, @InjectMocks, @ExtendWith, @Nested, @DisplayName까지 한 번에

요즘 스프링 개발을 하다 보면 “테스트 코드도 같이 작성해 주세요”라는 말을 자주 듣는다.
문제는 제대로 배워본 적이 없어서, 처음 테스트 코드를 보면 주술처럼 느껴진다는 점이다.

@ExtendWith(MockitoExtension.class)
@Mock
@InjectMocks
@Nested
@DisplayName
when().thenReturn(...)
verify(...)
verifyNoInteractions(...)

이런 것들이 한꺼번에 쏟아지면 “그냥 서비스 하나 더 만드는 게 빠르겠다”는 생각이 들 수도 있다.
이번 글에서는 내가 실제로 테스트 코드를 공부하면서 정리한 내용을 바탕으로, 위 어노테이션과 메소드들이 무엇을 하는지, 어떤 흐름으로 단위 테스트를 작성하면 되는지를 쉬운 예제와 함께 정리해 본다.

특히 JUnit5 + Mockito 조합을 기준으로 설명한다.

1. 단위 테스트에서 우리가 하고 싶은 일

단위 테스트의 목표는 결국 한 줄로 요약된다.

“이 메서드를 이렇게 호출했을 때, 이 결과와 이 동작이 일어나야 한다.”

조금 더 세분화하면:

파라미터 검증: 잘못된 값이 들어오면 예외가 발생해야 한다.
도메인/레포지토리 호출 검증: 내부적으로 어떤 메서드를 호출했는지 확인한다.
결과 검증: 리턴 값이 기대한 값인지 확인한다.

이걸 도와주는 도구가 바로
JUnit5(테스트 프레임워크)와 Mockito(가짜 객체, Mock 생성용 라이브러리)다.

2. 아주 쉬운 예제로 시작해 보기

실제 업무 코드는 도메인 규칙이 복잡해서 처음 학습용으로 쓰기엔 조금 무겁다.
그래서 최대한 단순한 예제를 하나 만들어 보자.

2-1. 예제 도메인: 사용자 인사말 서비스

UserRepository에서 사용자를 찾고
사용자 이름으로 “Hello {이름}” 메세지를 만들어주는 서비스

// src/main/java/.../User.java
public class User {
    private final Long id;
    private final String name;

    public User(Long id, String name) {
        this.id = id;
        this.name = name;
    }

    public Long getId() { return id; }

    public String getName() { return name; }
}







// src/main/java/.../UserRepository.java
public interface UserRepository {
    User findById(Long id);
}







// src/main/java/.../GreetingService.java
public class GreetingService {

    private final UserRepository userRepository;

    public GreetingService(UserRepository userRepository) {
        this.userRepository = userRepository;
    }

    public String getGreeting(Long userId) {
        if (userId == null) {
            throw new IllegalArgumentException("userId는 null일 수 없습니다.");
        }

        User user = userRepository.findById(userId);
        if (user == null) {
            throw new IllegalArgumentException("사용자를 찾을 수 없습니다.");
        }

        return "Hello " + user.getName();
    }
}

우리가 테스트하고 싶은 메서드는 GreetingService#getGreeting 하나다.

3. Mockito 기본 세팅 – @ExtendWith, @Mock, @InjectMocks

3-1. @ExtendWith(MockitoExtension.class)

@ExtendWith(MockitoExtension.class)
class GreetingServiceTest {
    ...
}

Unit5에서는 @ExtendWith를 통해 테스트에 “확장 기능”을 붙일 수 있는데,
MockitoExtension은 말 그대로 “Mockito를 쓸 수 있는 환경”을 만들어준다.

@Mock으로 가짜 객체를 만들 수 있게 해주고
@InjectMocks로 테스트 대상 객체를 생성할 때 Mock들을 자동으로 주입해 준다

라고 생각하면 된다.

3-2. @Mock – 가짜 객체 만들기

@Mock
UserRepository userRepository;

@Mock이 붙은 필드는 진짜 구현이 아니라 Mockito가 만들어주는 가짜 객체다.

실제 DB는 전혀 사용하지 않는다.
when(…).thenReturn(…) 형태로
“이 메서드가 호출되면 이런 값을 돌려줘”라고 지정해 줄 수 있다.
어떤 메서드가 어떻게 호출되었는지 기록해 두었다가 verify(…)로 검증할 수 있다.

3-3. @InjectMocks – Mock들을 끼워 넣어서 테스트 대상 생성

@InjectMocks
GreetingService greetingService;

GreetingService는 생성자에서 UserRepository를 받는다. (생성자주입)

public GreetingService(UserRepository userRepository) { ... }

테스트에서는 UserRepository를 @Mock으로 만들어두었기 때문에, 아래 코드와 동일한 효과가 난다

// Mockito가 내부적으로 해주는 일
greetingService = new GreetingService(userRepository);

즉,

@Mock → 부품(가짜 의존성)
@InjectMocks → 그 부품을 끼워 넣은 테스트 대상 객체(GreetingService 인스턴스) (System Under Test” = 테스트할 대상 클래스.)

라고 보면 된다.

4. @Test, @DisplayName, @Nested – 테스트 구조 잡기

4-1. @Test – 이 메서드는 테스트 함수다

@Test
void 성공_정상_사용자_인사말_반환() { ... }

JUnit5에게 “이 메서드는 테스트로 실행해 달라”고 알려주는 어노테이션이다.
@Test가 붙은 메서드만 테스트로 인식된다.

4-2. @DisplayName – 실행 결과에 보여줄 이름

@Test
@DisplayName("정상 사용자 ID를 넣으면 Hello {이름} 문자열을 반환한다")
void 성공_정상_사용자_인사말_반환() { ... }

DE나 콘솔에서 테스트가 실행될 때,
성공_정상_사용자_인사말_반환 대신 사람이 읽기 좋은 문장으로 표시해 준다.

실행 결과가 이렇게 보인다.

getGreeting
- 정상 사용자 ID를 넣으면 Hello {이름} 문자열을 반환한다

테스트 결과를 나중에 다시 볼 때, 어떤 시나리오였는지 한눈에 보인다.

4-3. @Nested – 테스트를 기능별로 묶기

@Nested는 “테스트를 그룹으로 묶고 싶을 때” 쓴다.

@Nested
@DisplayName("getGreeting 메서드")
class GetGreeting {

    @Test
    @DisplayName("정상 사용자 ID를 넣으면 Hello {이름} 문자열을 반환한다")
    void 성공_정상_사용자_인사말_반환() { ... }

    @Test
    @DisplayName("userId가 null이면 예외를 던지고 UserRepository는 호출하지 않는다")
    void 실패_userId_null() { ... }
}

실행 결과 계층도는 다음과 같이 정리된다.

getGreeting 메서드
- 정상 사용자 ID를 넣으면 Hello {이름} 문자열을 반환한다
- userId가 null이면 예외를 던지고 UserRepository는 호출하지 않는다

여러 메서드를 테스트할 때는 이렇게 기능 단위로 그룹을 나눠두면,
테스트 클래스가 커져도 구조가 눈에 잘 들어온다.

5. Mockito 기본 동작 – when/thenReturn, verify, verifyNoInteractions

이제 실제 예제 테스트 코드를 보면서 메소드들을 정리해 보자.

5-1. 성공 케이스 테스트

@ExtendWith(MockitoExtension.class)
class GreetingServiceTest {

    @Mock
    UserRepository userRepository;

    @InjectMocks
    GreetingService greetingService;

    @Nested
    @DisplayName("getGreeting 메서드")
    class GetGreeting {

        @Test
        @DisplayName("정상 사용자 ID를 넣으면 Hello {이름} 문자열을 반환한다")
        void 성공_정상_사용자_인사말_반환() {
            // given
            Long userId = 1L;
            User user = new User(userId, "치영");

            // userRepository.findById(1L)가 호출되면 user를 반환하도록 설정
            when(userRepository.findById(userId))
                    .thenReturn(user);

            // when
            String result = greetingService.getGreeting(userId);

            // then
            assertEquals("Hello 치영", result);

            // userRepository.findById(1L)가 실제로 한 번 호출되었는지 검증
            verify(userRepository).findById(userId);

            // 그 외 다른 메서드는 호출되지 않았는지 검증
            verifyNoMoreInteractions(userRepository);
        }
    }
}

여기서 중요한 포인트만 짚어보자.

when(…).thenReturn(…)

when(userRepository.findById(userId))
        .thenReturn(user);

Mock 객체는 실제 구현이 없기 때문에 우리가 동작을 “설정”해줘야 한다.
“테스트 중에 userRepository.findById(1L)가 호출되면,
user 객체를 돌려줘라” 라는 뜻이다.

assertEquals(기대값, 실제값)

assertEquals("Hello 치영", result);

JUnit의 기본 검증 메소드
기대값과 실제값이 같으면 성공, 다르면 실패

verify(mock).메서드(인자)

verify(userRepository).findById(userId);

“테스트를 실행하는 동안 userRepository.findById(1L)가 호출되었는지” 확인
Mock 객체는 모든 호출을 기록해 두었다가,
verify가 그 기록을 검사한다고 생각하면 이해가 쉽다.

메소드 형태가 조금 햇갈릴 수 있는데 이렇게 이해하면 쉽다.
userRepository객체를 verify메소드로 검증하라 findById메소드가 호출되었는지!

verifyNoMoreInteractions(userRepository);

위에서 검증한 호출(여기서는 findById) 외에
다른 메서드가 호출되면 테스트를 실패시킨다.
“의도한 것 이외의 추가 호출이 없어야 한다”는 걸 강하게 보장하고 싶을 때 사용한다.

5-2. 실패 케이스 – 파라미터 검증과 assertThrows, verifyNoInteractions

이번에는 userId가 null일 때를 테스트해 보자.

@Nested
@DisplayName("getGreeting 메서드")
class GetGreeting {

    @Test
    @DisplayName("userId가 null이면 예외를 던지고 UserRepository는 호출하지 않는다")
    void 실패_userId_null() {
        // when & then
        IllegalArgumentException ex = assertThrows(
                IllegalArgumentException.class,
                () -> greetingService.getGreeting(null)
        );

        assertEquals("userId는 null일 수 없습니다.", ex.getMessage());

        // 어떤 메서드도 호출되면 안 된다.
        verifyNoInteractions(userRepository);
    }
}

여기서 새로 나온 것들을 보면:

assertThrows

IllegalArgumentException ex = assertThrows(
        IllegalArgumentException.class,
        () -> greetingService.getGreeting(null)
);

“이 코드를 실행했을 때 반드시 IllegalArgumentException이 발생해야 한다”는 의미
예외가 발생하지 않거나 다른 예외가 발생하면 테스트는 실패한다.
발생한 예외 객체를 반환해 주기 때문에, 메시지도 검증할 수 있다.

assertEquals

assertEquals("userId는 null일 수 없습니다.", ex.getMessage());

이 한 줄은 **“예외 메시지가 내가 기대한 문자열과 정확히 같은지”**를 검증하는 코드다.

verifyNoInteractions

verifyNoInteractions(userRepository);

해당 Mock 객체에 대해 어떠한 메서드 호출도 없어야 한다는 검증이다.
userId == null이면 서비스 메서드는 바로 예외를 던지고 끝나야 하기 때문에
findById 같은 호출이 일어나면 안 된다.
이런 상황에 verifyNoInteractions를 사용하면 “파라미터 검증에서 바로 빠져나왔는지”까지 확인할 수 있다.

6. 정리: 테스트 코드 작성 흐름

이제까지 나온 내용을 정리하면,
JUnit5 + Mockito로 단위 테스트를 작성할 때 대략 이런 흐름으로 코드를 짤 수 있다.

테스트 클래스 기본 구조
- @ExtendWith(MockitoExtension.class)로 Mockito 활성화
- @Mock으로 의존성(Repository, 외부 서비스 등) 가짜 객체 생성
- @InjectMocks로 테스트 대상 서비스 생성
- 기능별로 @Nested + @DisplayName으로 그룹화
성공 케이스
- given
  - when(mock.method(...)).thenReturn(...)로 Mock 동작 설정
- when
  - 서비스 메서드 호출
- then
  - assertEquals, assertThat 등으로 결과 검증
  - verify(mock).method(...)로 필요한 호출이 있었는지 검증
  - verifyNoMoreInteractions(mock)로 불필요한 추가 호출 방지
실패 케이스(파라미터 검증, 예외)
- assertThrows로 특정 예외가 발생하는지 확인
- 예외 메시지까지 assertEquals로 검증
- verifyNoInteractions(mock)로 내부 호출이 전혀 없었는지 확인

테스트 코드도 결국 “코드”이기 때문에,
한 번에 완벽하게 이해하려고 하기보다는
이런 작은 예제에서 흐름을 익히고,
실제 업무 코드에 하나씩 적용해 보는 게 제일 빠른 것 같다.

7. 마무리

이번 글에서는 다음 내용을 중심으로 정리했다.

@ExtendWith(MockitoExtension.class), @Mock, @InjectMocks가 각각 어떤 역할을 하는지
@Nested, @DisplayName으로 테스트 구조를 어떻게 잡으면 좋은지
when().thenReturn(), verify(), verifyNoInteractions(), verifyNoMoreInteractions() 같은 Mockito 메서드들이 실제로 어떤 상황에서 쓰이는지
assertThrows, assertEquals를 이용해 예외와 결과를 어떻게 검증하는지

처음 테스트 코드를 볼 때는 문법 하나하나가 낯설지만,
실제로는 “서비스가 어떤 메서드를 호출해야 하고, 어떤 결과를 내야 하는지”를 코드로 정리한 것뿐이다.

실제 프로젝트에서도 오늘 사용한 예제 패턴 그대로:

파라미터 검증 실패 케이스
정상 흐름(성공 케이스)
레포지토리/도메인 메서드 호출 여부 검증

을 쌓아 나가다 보면, 어느 순간 테스트 코드를 짜는 게 자연스러워질 것이다.

필요하다면 다음 글에서는
Spring Boot 환경에서 @SpringBootTest와 Mock 없이 실제 Bean을 띄워 놓고 검증하는 통합 테스트,
혹은 도메인 레벨에서 엔티티/VO만 가지고 순수 자바 단위 테스트를 작성하는 방법도 정리해 볼 예정이다.

Git Rebase vs Merge, HEAD·base·hash까지 한 번에 이해하기

곽코딩루카 — Thu, 13 Nov 2025 10:31:16 +0900

1) 왜 리베이스를 쓰나?

히스토리를 직선(Linear)으로 정리하고 싶을 때
충돌을 커밋 단위로 깔끔하게 해결하고 싶을 때
저장소가 Fast-forward only 정책일 때(merge 커밋 없이 병합)

핵심 한 줄 : 내(feature) 커밋들을 최신 dev 뒤로 다시 붙여 병합을 깔끔하게 만든다.

2) 그림으로 보는 rebase와 merge

아래 그림들을 순서대로 넣으세요.

2-1. 분기된 상태 (리베이스/병합 전)

이 상태에서 feature는 예전 dev(C) 를 기준으로 작업된 상태입니다.

2-2. Rebase 후 (feature를 dev 최신 뒤로 재배치)

feature의 커밋들이 dev 최신 뒤로 다시 쌓임(D→D’, E→E’).
바뀌는 건 feature이고, dev는 움직이지 않습니다.

2-3. Merge 결과 (FF가 아닐 때는 merge 커밋 G 생성)

리베이스 없이 바로 병합하면 merge 커밋(G) 이 생깁니다.
히스토리가 “분기-합류” 모양으로 남아, 로그가 복잡해질 수 있습니다.

3) HEAD / base / hash — 꼭 알아야 할 내부 개념

base(출발점): 브랜치가 어느 커밋에서 갈라졌는지. rebase는 이 출발점을 최신으로 바꾸는 작업.
HEAD: 지금 내가 보고/작업 중인 위치를 가리키는 포인터(내 “현재 페이지”).
hash: 커밋의 고유 ID(SHA-1). 내용/부모/작성자/시간이 포함되어 조금만 바뀌어도 값이 달라짐.
- rebase로 부모(출발점)가 바뀌면 D→D′ 처럼 새 커밋이 만들어지고, 해시도 달라집니다.

4) 실전: 팀에서 쓰는 안전한 절차(FF-only 기준)

GitLab + SourceTree 기준. 콘솔 예시도 같이 둡니다.

dev 최신화

git checkout dev
git pull origin dev

2. feature를 dev로 rebase (feature 브랜치에서 실행)

git checkout feature/xxx
git rebase dev

# 충돌 시:
# 파일 수정 → 저장
git add <해결한 파일들>
git rebase --continue
# 반복...

3. (필요 시) 원격 feature 갱신
리베이스하면 커밋 해시가 바뀌므로 보통 force-with-lease를 씁니다.

git push --force-with-lease origin feature/xxx

4. dev로 병합(FF)

git checkout dev
git pull origin dev     # 혹시 또 dev가 변했는지 한 번 더 최신화
git merge --ff-only feature/xxx
git push origin dev

참고: FF-only 가 아니라면 --ff-only 대신 일반 merge 로 진행 가능하지만, merge 커밋이 생길 수 있습니다.

5) 리베이스 vs 병합, 언제 어떤 걸 쓰나?

리베이스 + FF 병합
- 히스토리를 직선으로 유지하고 싶을 때
- 커밋 단위로 충돌을 명확히 처리하고 싶을 때
- FF-only 정책인 저장소(보호 브랜치)에서 사실상 표준
리베이스 없이 병합(merge)
- 히스토리 재작성 없이 안전하게 가고 싶을 때
- 대신 merge 커밋이 쌓일 수 있음
- 팀 합의/정책에 따라 선택
GitLab MR에서 Rebase / Squash & Merge
- MR 화면에서 “Update branch / Rebase” 버튼으로 dev 최신 반영
- “Squash & merge”로 커밋 압축 후 머지 → 로그 간결화
- 보호 브랜치 정책에 잘 맞음

6) 자주 묻는 질문(FAQ)

Q1. 리베이스만 하고 바로 dev를 푸시하면 안 되나요?
A. 안 됩니다. 리베이스는 feature만 바뀌고 dev는 그대로입니다. dev가 바뀌려면 dev에서 feature를 병합(FF) 해야 합니다.

Q2. 리베이스 중에도 충돌이 나나요?
A. 납니다. 다만 커밋별로 재적용(replay) 되기 때문에, 어느 커밋에서 깨졌는지 명확하게 보고 해결할 수 있습니다. 해결 후 git rebase --continue.

Q3. 해시가 왜 바뀌나요?
A. 커밋 해시는 부모 커밋, 내용, 작성자/시간 등을 기반으로 계산됩니다. rebase로 부모(출발점)가 바뀌면 커밋이 새로 생성되기 때문에 해시도 바뀝니다.

Q4. 공유 브랜치를 rebase해도 되나요?
A. 일반적으로 공유(public) 브랜치 리베이스는 금지합니다. 히스토리 재작성으로 동료에게 피해를 줄 수 있기 때문입니다. 개인 feature 브랜치에서만 리베이스하세요.

Q5. force와 force-with-lease 차이는?
A. --force는 무조건 덮어쓰고, --force-with-lease는 내가 파악한 최신 상태일 때만 덮어써서 다른 사람 작업을 덮는 사고를 줄여줍니다.

7) 용어 정리(초급 개발자용)

Commit(커밋): 특정 시점의 변경 스냅샷.
Hash(해시): 커밋의 고유 ID(SHA-1). 커밋의 “주민번호”.
Branch(브랜치): 커밋을 가리키는 이름(책갈피). 예: dev, feature/xxx
HEAD: 현재 내가 보고/작업 중인 위치(포인터).
base(출발점): 브랜치가 갈라져 나온 커밋. rebase는 이 출발점을 최신으로 바꾸는 과정.
merge(병합): 두 갈래를 합치는 작업. 대상 브랜치의 포인터가 이동.
rebase(리베이스): 내 커밋들을 다른 출발점 위에 다시 쌓는 작업. 내 브랜치만 변함.
Fast-forward(FF): merge 커밋 없이 포인터만 앞으로 이동하는 병합.
Conflict(충돌): 같은 부분을 다르게 수정해서 Git이 자동 병합을 못 하는 상태.
Remote / origin: 원격 저장소 / 기본 원격 이름.
Upstream: 내 브랜치가 추적하는 원격 브랜치(예: origin/dev).

마무리

리베이스는 내 브랜치의 출발점(base)을 최신으로 바꾸는 것이고,
병합은 대상 브랜치의 포인터를 실제로 움직여 합치는 것입니다.
팀 정책이 FF-only라면 “리베이스 → (FF) 머지” 흐름이 가장 깔끔합니다.
보호 브랜치/CI 규칙이 있다면 MR에서 Rebase + Squash & merge로 동일한 효과를 낼 수 있습니다.

[DDD] Value Object의 동일성과 동등성 완벽 이해하기 Value Object의 동일성과 동등성 완벽 이해하기

곽코딩루카 — Wed, 22 Oct 2025 11:21:17 +0900

DDD(도메인 주도 설계)에서 Value Object(VO) 는 도메인 모델을 설계할 때 꼭 등장하는 개념입니다.
하지만 많은 개발자들이 “VO가 뭐야?” 혹은 “동등성으로 비교한다는 게 무슨 뜻이야?”라는 부분에서 헷갈려하죠.
오늘은 이 개념을 실제 코드와 함께 명확히 정리해보겠습니다.

Value Object란?

Value Object(VO) 는 고유한 ID가 없고,

그 값 자체로 동일성을 판단하는 객체입니다.

즉, 값이 같다면 다른 객체여도 “같은 것으로 본다”는 의미예요.
대표적인 예로는 Money(금액), Address(주소), Email(이메일) 같은 객체가 있습니다.

동일성과 동등성의 차이

자바에서는 객체를 비교할 때 두 가지 기준이 있습니다.

구분의미자바 비교 방식

동일성 (Identity)	메모리 상에서 같은 객체인가?	==
동등성 (Equality)	내부 값이 같은가?	equals()

예시로 이해하기

Money m1 = new Money(1000, "KRW");
Money m2 = new Money(1000, "KRW");

m1 == m2 → 틀림 (메모리 주소가 다름)
m1.equals(m2) → 같음 (값이 같음)

즉, VO는 값이 같으면 같은 객체로 본다는 원칙을 따릅니다.
그래서 VO에서는 항상 equals()와 hashCode()를 재정의해야 합니다.

예시 코드 — Money VO

public class Money {

    private final int amount;
    private final String currency;

    public Money(int amount, String currency) {
        this.amount = amount;
        this.currency = currency;
    }

    public Money add(Money other) {
        if (!currency.equals(other.currency)) {
            throw new IllegalArgumentException("통화 단위가 다릅니다.");
        }
        return new Money(this.amount + other.amount, currency);
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (!(o instanceof Money)) return false;
        Money money = (Money) o;
        return amount == money.amount &&
               Objects.equals(currency, money.currency);
    }

    @Override
    public int hashCode() {
        return Objects.hash(amount, currency);
    }
}

특징 정리

id가 없습니다.
값이 같으면 같은 객체로 취급합니다.
불변(Immutable) 객체로 설계합니다.
→ 한 번 생성되면 내부 값이 변하지 않습니다.

또 다른 예 — Address VO

@Embeddable
public class Address {
    private String city;
    private String street;
    private String zipcode;

    protected Address() {} // JPA 기본 생성자

    public Address(String city, String street, String zipcode) {
        this.city = city;
        this.street = street;
        this.zipcode = zipcode;
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (!(o instanceof Address)) return false;
        Address address = (Address) o;
        return Objects.equals(city, address.city) &&
               Objects.equals(street, address.street) &&
               Objects.equals(zipcode, address.zipcode);
    }

    @Override
    public int hashCode() {
        return Objects.hash(city, street, zipcode);
    }
}

그리고 아래와같이 엔티티에서 포함시켜 사용합니다

@Entity
public class Member {
    @Id @GeneratedValue
    private Long id;
    private String name;

    @Embedded
    private Address address;
}

이 경우 Member는 Entity,
Address는 Value Object입니다.

Entity vs Value Object 비교

구분EntityValue Object

식별자(ID)	있음	없음
비교 기준	동일성 (ID)	동등성 (값)
가변성	변경 가능	불변
DB 매핑	@Entity	@Embeddable
예시	주문(Order), 회원(User)	주소(Address), 금액(Money), 이메일(Email)

VO를 설계할 때 주의할 점

항상 불변(Immutable) 으로 만들 것
→ setter 금지, 생성자에서만 값 설정
equals() / hashCode() 반드시 재정의
→ 값 기반 비교를 위해 필요
비즈니스 규칙은 VO 안으로 응집
→ 예: Email 형식 검증, 금액 계산 등

정리

동일성(Identity) → 같은 객체인가? (==)

동등성(Equality) → 값이 같은가? (equals())

VO는 “값이 같으면 같은 객체로 본다.”
즉, 동등성으로 판단하는 객체다.

반면 Entity는 ID가 같으면 같은 객체로 본다.
즉, 동일성으로 판단하는 객체다.

마무리 한 줄

VO는 단순한 데이터 컨테이너가 아니라,

도메인의 의미를 담고, 불변성과 동등성을 보장하는 ‘작은 규칙의 단위’다.

[DDD] 자바에서의 참조 공유와 (Value Object, Entity) 정리

곽코딩루카 — Fri, 17 Oct 2025 10:28:00 +0900

들어가며

DDD(Domain-Driven Design)를 공부하다 보면 “밸류(Value Object)는 불변 객체여야 한다”는 말을 자주 듣습니다.
그런데 막상 자바 코드로 보면 “왜 불변이어야 하지?”, “참조 공유가 왜 문제지?” 같은 의문이 생기죠.

이 글에서는

자바의 참조 구조(Stack, Heap)
참조 공유 문제의 원리
불변 객체로 해결하는 이유
DDD에서 밸류(Value Object)와 엔티티(Entity)의 차이
를 실제 예제 코드와 함께 명확히 정리해보겠습니다.

// 금액
class Money {
    private int value;

    public Money(int value) {
        if (value < 0) throw new IllegalArgumentException();
        this.value = value;
    }
    public int getValue() { return value; }
    public void setValue(int value) { this.value = value; } // ❗ 가변 포인트
    @Override public String toString() { return "Money(" + value + ")"; }
}

// 주문 목록
class OrderLine {
    private final String productName;
    private final Money price; // 같은 인스턴스를 그대로 참조
    private final int quantity;

    public OrderLine(String productName, Money price, int quantity) {
        this.productName = productName;
        this.price = price; // ❗ 방어적 복사 없음 → 참조 공유 발생
        this.quantity = quantity;
    }
    public Money getPrice() { return price; }
    public int total() { return price.getValue() * quantity; }
   
}

자바의 메모리 구조: Stack과 Heap

자바는 데이터를 저장할 때 두 가지 영역을 사용합니다.

구분저장 위치예시저장 내용

Stack	메서드 호출 시 생기는 임시 공간	Money price = new Money(1000);	변수명과 참조값(주소)
Heap	new로 만든 객체들이 저장되는 공간	new Money(1000)	객체의 실제 데이터(필드 값)

즉,

Money price = new Money(1000);

이 한 줄의 실행 결과는 다음과 같습니다 (아래참고)

[Stack]           [Heap]
price ───► [ Money 객체 | value = 1000 ]

Stack에는 참조값(reference),
Heap에는 객체의 실제 데이터(value) 가 저장됩니다.

참조 공유(Reference Sharing) 문제란?

자바의 참조형 변수는 객체를 가리키는 주소값을 저장합니다.
이 때문에 여러 변수가 같은 객체를 동시에 참조할 수 있습니다.

Money price = new Money(1000);
OrderLine line = new OrderLine(price);
price.setValue(2000); //   외부에서 금액 변경

이때 메모리 구조는 이렇게 됩니다.

[Stack]
price ─┐
       └──► [Heap] Money 객체 { value = 2000 }
line.price ─┘

price와 line.price가 같은 객체(Heap 주소) 를 가리키고 있어서
한쪽을 수정하면 다른 쪽에도 영향을 줍니다.

이걸 참조 공유 문제(reference aliasing) 라고 합니다.

불변 객체(Immutable Object)로 해결하기

OrderLine이 외부에서 받은 Money 객체를 그대로 저장하면,
참조 공유 때문에 외부 변경이 내부에도 영향을 줍니다.

해결 방법: OrderLine 내부에 복사본을 만들어 보관합니다.

class Money {
    private int value;

    public Money(int value) { this.value = value; }
    public int getValue() { return value; }
    public void setValue(int value) { this.value = value; }
}

class OrderLine {
    private final Money price;

    public OrderLine(Money price) {
        // ✅ 불변처럼 동작하도록 복사본 생성
        this.price = new Money(price.getValue());
    }

    public Money getPrice() { return price; }
}

DDD의 밸류(Value Object)란 무엇인가?

밸류(Value Object) 는 “도메인 안의 개념을 값으로 표현하는 객체”입니다.
즉, ‘누구인지’보다 ‘무엇인지’가 중요한 객체입니다.

구분엔티티(Entity)밸류(Value Object)

구분 기준	고유 ID로 구분	값의 동등성으로 구분
동일성 판단	id가 같으면 동일	모든 필드 값이 같으면 동일
상태 변경	가능 (mutable)	불변 (immutable)
예시	주문(Order), 회원(User)	금액(Money), 주소(Address), 주문번호(OrderNo)

밸류 타입 예시: OrderNo

주문 번호를 단순히 String으로 저장하면 도메인 의미가 드러나지 않습니다.
그래서 도메인 의미를 담은 밸류 타입을 만듭니다.

public record OrderNo(String value) {
    public OrderNo {
        if (!value.matches("^ORD-\\d{8}-\\d{4}$"))
            throw new IllegalArgumentException("잘못된 주문번호 형식입니다.");
    }
}

record는 자바 16부터 추가된 불변 객체 전용 문법으로,
모든 필드가 final이며, equals/hashCode도 자동으로 값 기반으로 생성됩니다.

사용 예:

OrderNo id = new OrderNo("ORD-20251017-0001");
Order order = new Order(id);

이제 코드를 보지 않아도
OrderNo라는 타입 이름만으로 이게 주문번호라는 의미를 바로 알 수 있습니다.

밸류 객체와 엔티티 객체의 차이

구분엔티티(Entity)밸류(Value Object)

존재 이유	시스템 안에서 “고유한 존재”	도메인 개념을 “값으로 표현”
식별자	있음 (id 필드)	없음
동등성 판단	식별자 비교 (id.equals())	값 비교 (equals() 모든 필드)
상태 변화	허용	불변
사용 예	주문(Order), 사용자(User)	금액(Money), 이메일(Email), 주문번호(OrderNo)

실전 예시

@Entity
public class Order {
    @Id
    private OrderNo id;

    @Embedded
    private Money totalAmount;

    public Order(OrderNo id, Money totalAmount) {
        this.id = id;
        this.totalAmount = totalAmount;
    }
}

→ DB에는 VARCHAR 값으로 저장되지만,
코드에서는 OrderNo, Money로 표현되어 의미가 살아 있는 도메인 모델이 됩니다.

마무리 요약

개념핵심 요약

참조 공유	여러 변수가 같은 객체 주소를 가리켜서 한쪽 변경이 다른 쪽에 영향을 주는 문제
불변 객체	내부 상태를 변경할 수 없는 객체. 참조 공유로부터 안전함
밸류(Value Object)	도메인 개념을 값으로 표현하는 불변 객체. ID 없음
엔티티(Entity)	고유 식별자를 갖고, 상태가 변해도 같은 객체로 인식되는 존재

정리하면,

자바의 객체는 참조로 다뤄지기 때문에 참조 공유가 필연적으로 발생합니다.
따라서 DDD에서의 밸류 객체는 불변 객체(Immutable Object) 로 만들어
참조 공유의 부작용을 원천 차단하고,
도메인의 의미가 드러나는 안전한 모델링을 구현하는 것입니다.

[Java기술면접] ArrayList vs LinkedList 차이 및 시간 복잡도란?

곽코딩루카 — Mon, 8 Sep 2025 23:25:05 +0900

시간 복잡도란?

어떤 코드/알고리즘이 얼마나 빨리 동작하는지를 나타내는 단위예요.
그런데 "몇 초" 같은 절대 시간이 아니라, 데이터 양(n)이 늘어날 때 연산 횟수가 얼마나 늘어나는지를 보는 거예요.

즉, 성능의 성장률을 나타낸 것.

O(1), O(n) 이건 뭔데?

O(...) 표기법 = Big-O 표기법이라고 부르고, 최악의 경우에 연산이 얼마나 걸리는지 표현한다.

자주 나오는 예시

O(1) : 데이터 개수와 상관없이 항상 일정한 시간.
→ "한 번에 바로 찾는다."
예: 배열에서 arr[5]처럼 인덱스로 값 꺼내기.
O(n) : 데이터 개수(n)에 비례해서 시간이 늘어남.
→ "처음부터 끝까지 다 뒤져야 한다."
예: 배열에서 "값이 7인 원소 찾기" (최악의 경우 전부 확인해야 함).
O(log n) : 데이터가 늘어나도 조금만 늘어남.
→ "이진탐색처럼 반씩 줄여가며 찾는다."
O(n²) : 데이터가 10개면 100번, 100개면 1만 번.
→ "이중 반복문."

ArrayList vs LinkedList 예시로 이해하기

ArrayList: 내부적으로 동적 배열 기반. (연속된 메모리 블록)
LinkedList: 내부적으로 이중 연결 리스트 기반. (노드와 포인터)

실제 성능 측정

두 리스트에 대해 실제 메서드 동작 시간을 측정한 그래프이다.

조회(get)시에는 arraylist가 우위 지만 삽입/삭제(add/remove) 시에는 linkedlist가 뛰어난 성능을 보여준다.

ArrayList 접근 (O(1))
→ "책장에서 5번째 칸에 있는 책 바로 뽑기." (인덱스로 바로 접근 가능)
LinkedList 접근 (O(n))
→ "책장 맨 앞에서부터 하나씩 넘겨서 5번째 책까지 가야 함." (앞에서 순서대로 따라가야 함)

표를 쉽게 보면

핵심 요약:

O(1) = 바로 찾음 (빠름, 데이터 크기와 무관)
O(n) = 데이터가 많아질수록 느려짐 (하나하나 확인)
시간 복잡도 = "데이터가 커질 때 걸리는 시간의 증가 속도"

참고:

https://inpa.tistory.com/entry/JCF- -ArrayList-vs-LinkedList-특징-성능-비교 [Inpa Dev ‍ :티스토리]

GPT5

[Java 기술면접] ConcurrentModificationException 발생

곽코딩루카 — Mon, 8 Sep 2025 23:05:02 +0900

이건 자바 면접에서 정말 자주 나오는 ConcurrentModificationException 문제이다.

List<String> list = new ArrayList<>(Arrays.asList("a","b","c"));

for (String s : list) {
  if (s.equals("n")) {
    list.remove(s);   // 여기서 문제 !!
  }
}

1. 왜 오류가 날까?

for-each 문은 내부적으로 Iterator를 사용해 리스트를 순회합니다.
그런데 순회 도중에 list.remove(s)로 직접 리스트를 수정하면,
Iterator가 감지 → ConcurrentModificationException 발생.

즉, “Iterator로 순회 중인데, 너 몰래 리스트를 건드렸다”라는 상황이다.

2. 안전하게 수정하는 방법

방법 1) Iterator 사용

List<String> list = new ArrayList<>(Arrays.asList("a","b","c"));

Iterator<String> it = list.iterator();
while (it.hasNext()) {
    String s = it.next();
    if (s.equals("n")) {
        it.remove();   //  안전: Iterator의 remove는 허용
    }
}

방법 2) removeIf (Java 8+)

가장 깔끔하고 요즘 가장 많이 씀

List<String> list = new ArrayList<>(Arrays.asList("a","b","c"));
list.removeIf(s -> s.equals("n"));

방법 3) 새로운 리스트로 필터링

List<String> list = new ArrayList<>(Arrays.asList("a","b","c"));
List<String> filtered = list.stream()
                            .filter(s -> !s.equals("n"))
                            .toList();   // Java 16+에서는 불변 리스트 반환

면접 답변 예시

“for-each는 내부적으로 Iterator를 쓰는데, 순회 중에 list.remove()를 호출하면 ConcurrentModificationException이 발생합니다. 안전하게 제거하려면 Iterator의 remove()를 사용하거나, Java 8 이후엔 removeIf 메서드를 쓰는 게 일반적입니다.”

[SourceTree]소스트리 조직(organization) 저장소 403 오류 발생 해결

곽코딩루카 — Mon, 12 May 2025 14:04:26 +0900

소스트리(Sourcetree)를 설치 후 깃허브(Github)의 저장소들을 클론(clone)할 때 문제가 발생하였습니다.

유효한 소스 경로 URL이 아닙니다.

1. 문제발생

소스트리(Sourcetree)를 설치 후 깃허브(Github)의 저장소들을 클론(clone)할 때 문제가 발생하였습니다.

유효한 소스 경로 URL이 아닙니다.

1. 문제발생

분명히 존재하는 저장소인데 해당 URL을 찾지 못하는 것이 이상했습니다. 개인(private) 저장소들은 정상적으로 탐색되었기 때문에 조직(organization) 저장소라는 점이 수상했습니다. 문제 원인은 소스트리 어플리케이션이 조직에 대한 접근 승인이 되지 않았던 것이었습니다.

2. 해결방법

다음과 같은 과정을 통해 문제를 해결할 수 있습니다.

Settings > Applications > Authorized OAuth Apps

해당 경로로 접근하여 소스트리 어플리케이션을 선택합니다.

이미지 아래 빨간 네모 칸에 grant 버튼을 눌러 해당 어플리케이션 접근을 승인합니다.

[Spring Security] 해시란? Salt란? BCrypt이해하기

곽코딩루카 — Mon, 12 May 2025 01:14:07 +0900

안녕하세요, 이번 글에서는 실무에서도 많이 사용하는 BCrypt 해시 알고리즘에 대해 정리해보려고 합니다.
단순히 라이브러리만 사용하는 것을 넘어서, 왜 써야 하는지, 어떻게 동작하는지 까지 이해하는 것이 목표입니다.

비밀번호 저장은 "암호화"가 아니라 "해시"로

많은 분들이 비밀번호를 암호화해서 저장한다고 말하지만, 정확히는 "해시(Hash)" 해야 합니다.

구분해시 (Hash)암호화 (Encryption)

방향성	단방향 (복호화 불가)	양방향 (복호화 가능)
사용 목적	비교용, 위조 방지	데이터 보호
비밀번호 저장에 적합?	예	아니오

암호화는 키가 유출되면 누구나 복호화할 수 있기 때문에 비밀번호 저장용으로는 부적절합니다.
따라서 우리는 복호화가 불가능한 단방향 해시 함수를 사용해야 합니다.

해시(Hash)란?

입력값(비밀번호 등)을 고정된 길이의 문자열로 변환하는 함수

복호화가 불가능함
같은 입력 → 항상 같은 출력
대표 알고리즘: SHA-256, SHA-1, MD5, BCrypt

하지만 SHA-256, MD5는 빠르게 계산되기 때문에 Brute-force 공격에 취약합니다.

그래서 나온 것이 BCrypt

BCrypt는 Blowfish 알고리즘을 기반으로 만든 비밀번호 저장용 해시 함수입니다.
다음과 같은 특징을 가집니다:

특징설명

Salt 내장	매번 다른 salt를 생성하여 같은 비밀번호도 다른 해시 생성
Cost factor 지원	연산 횟수를 조절해 공격을 어렵게 함
복호화 불가능	철저한 단방향 해시
결과 문자열에 정보 포함	salt, cost, 해시값을 모두 문자열에 포함
Spring Security 기본값	BCryptPasswordEncoder로 바로 사용 가능

Salt란?

Salt는 해시 전에 붙이는 무작위 문자열입니다.

같은 비밀번호라도 다른 salt를 사용하면 완전히 다른 해시값이 생성됩니다.

사용자입력값Salt해시결과

userA	password123	abc123	XYZ...
userB	password123	zxc987	QWE...

이렇게 하면 해커가 사전 만들어둔 레인보우 테이블로 역추적하는 것을 방지할 수 있습니다.

레인보우 테이블이란?

자주 사용되는 비밀번호에 대한 해시값을 미리 계산해서 저장해둔 테이블

예:

123456 → e10adc3949ba59abbe56e057f20f883e  
qwer1234 → ab56b4d92b40713acc5af89985d4b786

→ 해시만 보고도 어떤 비밀번호인지 알아낼 수 있음
→ Salt를 쓰지 않으면 이 공격에 매우 취약합니다.

단순화한 레인보 테이블

그런데 궁금하죠?

"같은 비밀번호라도 매번 해시값이 달라진다며?

그럼 로그인할 때 어떻게 비교해요?"

여기서부터가 BCrypt의 핵심 기술입니다.

BCrypt는 해시 안에 salt를 포함시킨다!

BCrypt로 비밀번호를 해싱하면 다음처럼 생긴 문자열이 나옵니다:

$2a$10$WqRf8g1D33tX6SPZzAsT0OZADZ5POZNUKj2HNGIrBxkOcLCUo3GcK

구간 의미

$2a$	알고리즘 버전
10$	Cost factor (2¹⁰ = 1024번 반복)
WqRf8g1D33tX6SPZzAsT0O	22자리 salt
나머지	최종 해시값 (salt + 비밀번호 해싱 결과)

로그인할 때 비교는 어떻게 하나? (스프링 JAVA)

passwordEncoder.matches("입력한 비밀번호", "DB에 저장된 해시값");

matches() 내부에서는 다음 과정을 수행합니다:

저장된 해시값에서 salt, cost 정보를 추출
입력한 비밀번호 + 추출된 salt → 같은 방식으로 다시 해싱
새로 계산한 해시값과 기존 해시값이 일치하면 로그인 성공

✔️ 즉, BCrypt는 비교에 필요한 모든 정보(salt 포함)를 해시 문자열에 내장해놓습니다.
❌ 별도로 salt를 저장하거나 비교할 필요가 없습니다.

정리

질문핵심 요약

왜 비밀번호는 암호화가 아니라 해시해야 하나요?	복호화되면 안 되니까
해시만 저장해도 괜찮나요?	salt를 쓰면 안전합니다
같은 비밀번호인데 해시값이 매번 다른 이유는?	salt가 무작위로 들어가기 때문입니다
그럼 어떻게 비교하나요?	해시 안에 salt가 포함되어 있고, 이를 기반으로 재해싱하여 비교합니다

BCrypt는 단순히 "라이브러리를 쓰면 되는 기술"이 아닙니다.
원리까지 이해해야 보안 사고 없이 안전한 서비스를 설계할 수 있습니다.
오늘 포스팅이 여러분의 보안 지식에 도움이 되었길 바랍니다!

Spring Security 기반 CSRF 공격 실습 및 방어 방법 정리

곽코딩루카 — Sun, 4 May 2025 02:43:21 +0900

유튜브 영상도 촬영하였습니다. 아래 영상을 참고하면서 블로그글을 참고해주세요.

CSRF (Cross-Site Request Forgery)란?

CSRF (Cross-Site Request Forgery) 사이트 간 요청 위조는 웹 애플리케이션의 취약점을 악용하는 공격 방식 중 하나로, 사용자가 의도하지 않은 요청을 수행하게 만드는 공격입니다.

CSRF 공격의 목적은 사용자가 웹 애플리케이션에서 인증된 세션을 가지고 있는 상태에서, 공격자가 의도한 행동을 사용자로 하여금 실행하게 하는 것입니다.

이는 사용자가 현재 로그인한 세션을 이용하여 악의적인 요청이 서버에 전달되도록 하여, 사용자의 의도와 무관하게 데이터 변경, 거래 발생 등의 작업이 수행되게 만듭니다.

CSRF(Cross-Site Request Forgery)의 동작 원리

CSRF 공격이 성공하기 위해서는 아래의 조건을 충족해야 합니다.

CSRF 공격이 성공하기 위한 조건

사용자 인증

사용자가 공격 대상 웹사이트에 로그인하여 유효한 세션 쿠키를 가지고 있어야 합니다.
이 세션 쿠키는 공격자가 생성한 악성 요청에 포함되어 서버에서 인증된 요청으로 인식됩니다.

쿠키

쿠키 기반으로 서버 세션 정보를 획득할 수 있어야 합니다.

요청의 구조 이해

공격자는 서버가 어떤 URL 패턴과 요청 파라미터를 사용하는지 알고 있어야 합니다.
예를 들어, 사용자의 계좌에서 돈을 이체하는 요청이 POST /transfer 엔드포인트를 사용하고, amount와 recipient이라는 파라미터를 요구하는 경우, 공격자는 이 정보를 알고 있어야 합니다.

CSRF 공격이 일어나기 위한 조건

사용자가 이미 인증된 상태여야 함 (세션, 쿠키 기반 로그인)
브라우저가 자동으로 쿠키를 함께 전송
공격자가 form, img, script 태그 등을 통해 요청을 유도

실습: CSRF 공격을 재현해보기

SecurityConfig.java

package com.luca.csrf.config;

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity;
import org.springframework.security.core.userdetails.User;
import org.springframework.security.core.userdetails.UserDetails;
import org.springframework.security.core.userdetails.UserDetailsService;
import org.springframework.security.crypto.factory.PasswordEncoderFactories;
import org.springframework.security.crypto.password.PasswordEncoder;
import org.springframework.security.provisioning.InMemoryUserDetailsManager;
import org.springframework.security.web.SecurityFilterChain;

@Configuration
@EnableWebSecurity
public class SecurityConfig {

    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        http
            .csrf(csrf -> csrf.disable()) // CSRF 보호 기능을 비활성화 (실습을 위해 OFF) //Spring Security는 기본적으로 CSRF 공격 방지를 위해 폼 요청에 토큰을 요구함.
            .authorizeHttpRequests(auth -> auth
                    .requestMatchers("/login","/css/**").permitAll() // /login,/css로 시작하는 경로는 누구나 접근 가능
                    .anyRequest().authenticated()                             //그 외에 모든 요청은 인증된 사용자만 접근 가능
            )
            .formLogin(form -> form
                    .loginPage("/login")  //로그인 폼 URL을 커스텀
                    .defaultSuccessUrl("/post",true) //로그인 성공 후 이동할 페이지 설정
                    .permitAll()  //로그인 폼 자체는 인증 없이 누구나 접근 가능
            );
        return http.build();
    }

    @Bean
    public UserDetailsService userDetailsService() {
        //메모리에 사용자 정보 하나 생성
        //비밀번호를 단순 인코딩 (실습용). 실제 서비스에서는 BCrypt 같은 강력한 해시 사용 권장
        UserDetails user = User.withDefaultPasswordEncoder()
                .username("user")
                .password("1234")
                .roles("USER")
                .build();
        // DB 없이 메모리에서 사용자 인증 정보를 관리함 (간단한 테스트 용도에 적합)
        return new InMemoryUserDetailsManager(user); // 메모리 기반 사용자 저장소 반환
    }

    @Bean
    public PasswordEncoder passwordEncoder() {
        return PasswordEncoderFactories.createDelegatingPasswordEncoder();
    }
}

PostController.java

package com.luca.csrf.post.controller;

import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.ResponseBody;

@Controller
public class PostController {

    @GetMapping("/post")
    public String postForm() {
        return "post";
    }

    @PostMapping("/post")
    @ResponseBody
    public String submitPost(@RequestParam("content") String content) {
        System.out.println("작성된 글: " + content);
        return "글 작성 완료!";
    }

    @GetMapping("/login")
    public String loginPage() {
        return "login";
    }
}

<!DOCTYPE html>
<html xmlns:th="http://www.thymeleaf.org">
<body>
<h1>로그인</h1>
<form method="post" th:action="@{/login}">
    <input type="text" name="username" placeholder="user" />
    <input type="password" name="password" placeholder="1234" />
    <button type="submit">로그인</button>
</form>
</body>
</html>

post.html

<!DOCTYPE html>
<html xmlns:th="http://www.thymeleaf.org">
<body>
<h1>게시글 작성</h1>
<form action="/post" method="post">
  <input type="text" name="content" value="정상 글입니다." />

  
  <button type="submit">작성</button>
</form>
</body>
</html>

build.gradle

plugins {
	id 'java'
	id 'org.springframework.boot' version '3.4.5'
	id 'io.spring.dependency-management' version '1.1.7'
}

group = 'com.luca'
version = '0.0.1-SNAPSHOT'

java {
	toolchain {
		languageVersion = JavaLanguageVersion.of(17)
	}
}

configurations {
	compileOnly {
		extendsFrom annotationProcessor
	}
}

repositories {
	mavenCentral()
}

dependencies {
//	implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
	implementation 'org.springframework.boot:spring-boot-starter-security'
	implementation 'org.springframework.boot:spring-boot-starter-thymeleaf'
	implementation 'org.springframework.boot:spring-boot-starter-web'
	implementation 'org.thymeleaf.extras:thymeleaf-extras-springsecurity6'
	compileOnly 'org.projectlombok:lombok'
//	runtimeOnly 'com.mysql:mysql-connector-j'
	annotationProcessor 'org.projectlombok:lombok'
	testImplementation 'org.springframework.boot:spring-boot-starter-test'
	testImplementation 'org.springframework.security:spring-security-test'
	testRuntimeOnly 'org.junit.platform:junit-platform-launcher'
}

tasks.named('test') {
	useJUnitPlatform()
}

1. 정상적인 게시글 작성 테스트

먼저, 아래와 같은 간단한 로그인 및 게시글 작성 기능이 있는 웹 애플리케이션을 준비했습니다.

로그인 페이지: /login
게시글 작성 페이지: /post

사용자 정보는 메모리 기반 사용자 저장소를 사용하고 있으며, user / 1234 계정으로 로그인할 수 있습니다.

로그인 후 /post 페이지에서 글을 작성하면 서버에서는 정상적으로 글 내용을 로그에 출력합니다.

2. 공격자 사이트 접근 (evil.html)

이제 공격자가 만든 사이트(evil.html)를 준비해봅니다. 예를 들어, “쿠폰 받기”라는 문구로 유인하는 단순한 HTML 페이지입니다.

<!-- evil.html -->
<h2>쿠폰 1000원 받기!</h2>
<form action="http://localhost:8080/post" method="POST">
    <input type="hidden" name="content" value="  해커의 글  " />
    <button type="submit">쿠폰 받기</button>
</form>

사용자가 이 페이지를 방문해 버튼을 클릭하면 브라우저는 현재 로그인된 세션 쿠키를 자동으로 첨부하여 /post로 POST 요청을 보내게 됩니다.

결과적으로 사용자의 의도와 상관없이 “ 해커의 글 ” 이라는 내용이 A 사이트에 등록됩니다.

3. CSRF 공격이 실제로 성공한 이유

사용자는 이미 A 사이트에 로그인한 상태였고,
브라우저는 세션 쿠키를 자동으로 전송했기 때문에,
서버는 이를 정상적인 요청으로 인식하게 됩니다.

CSRF 방어 방법 정리

CSRF Token (기본)	서버에서 토큰 발급, 클라이언트에서 폼/헤더에 담아 전송	가장 강력한 방어	AJAX 요청 시 수동 삽입 필요
Referer 체크	요청의 출처(도메인) 확인	구현 간단	일부 브라우저에서 헤더 없음
CAPTCHA	사용자가 직접 입력 or 클릭	자동 요청 차단	UX 저하 가능

첫번째 방어 방법인 CSRF Token을 사용해 보겠습니다.

@Configuration
@EnableWebSecurity
public class SecurityConfig {

    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        http
//            .csrf(csrf -> csrf.disable()) // CSRF 보호 기능을 비활성화 (실습을 위해 OFF) //Spring Security는 기본적으로 CSRF 공격 방지를 위해 폼 요청에 토큰을 요구함.
            .authorizeHttpRequests(auth -> auth
                    .requestMatchers("/login","/css/**").permitAll() // /login,/css로 시작하는 경로는 누구나 접근 가능
                    .anyRequest().authenticated()                             //그 외에 모든 요청은 인증된 사용자만 접근 가능
            )
            .formLogin(form -> form
                    .loginPage("/login")  //로그인 폼 URL을 커스텀
                    .defaultSuccessUrl("/post",true) //로그인 성공 후 이동할 페이지 설정
                    .permitAll()  //로그인 폼 자체는 인증 없이 누구나 접근 가능
            );
        return http.build();
    }

...그외 소스들 냅둘것

csrf 부분을 주석을 넣어줍니다. 스프링 시큐리티는 기본적으로 csrf보호 기본값이 적용됩니다.

CSRF 토큰을 폼에 삽입 (Thymeleaf)

Spring Security는 HTML 폼에서 CSRF 토큰을 자동으로 처리할 수 있도록 지원합니다. Thymeleaf를 사용한다면 아래와 같이 <input type="hidden">으로 쉽게 삽입할 수 있습니다:

<form action="/post" method="post">
  <input type="text" name="content" value="정상 글입니다." />
  <input type="hidden" th:name=\"${_csrf.parameterName}\" th:value=\"${_csrf.token}\" />
  <button type="submit">작성</button>
</form>

4. evil.html 공격 다시 시도

앞서 사용했던 evil.html 파일을 다시 실행한 뒤 쿠폰 받기 버튼을 클릭해봅니다.

하지만 이번에는 결과가 다릅니다. 서버는 다음과 같은 응답을 반환합니다:

HTTP 403 Forbidden

왜 차단됐을까?

Spring Security는 이제 모든 POST 요청에 대해 CSRF 토큰이 포함되었는지를 검사합니다.
evil.html에서는 CSRF 토큰이 포함되어 있지 않기 때문에, 서버는 이 요청을 악의적인 것으로 간주하고 차단합니다.

1.Spring Security에서 CSRF 토큰은 이렇게 동작합니다 1.토큰 생성 시점 사용자가 최초로 GET 요청(예: /post, /login)으로 접근하면 Spring Security는 내부적으로 CsrfTokenRepository를 통해 고유한 토큰을 생성합니다.

기본 구현체는 HttpSessionCsrfTokenRepository이며, 이 토큰은 서버 세션에 저장됩니다.

2.토큰 전달 방식 Thymeleaf를 사용한다면 ${_csrf.parameterName}과 ${_csrf.token} 값을 통해 Spring Security가 세션에서 가져온 토큰을 <form>에 자동으로 삽입해줍니다.

3.토큰 검증 사용자가 POST, PUT, DELETE 요청을 보내면, CsrfFilter가 요청에 포함된 토큰과 세션에 저장된 토큰을 비교합니다. 둘이 일치하면 요청 허용, 불일치하거나 누락되면 403 Forbidden.

참고 :
https://pixx.tistory.com/344
https://jaykaybaek.tistory.com/29

https://innovation123.tistory.com/243