가롱 Log

[Java] 최단거리 구하기 알고리즘 (가중치 있는 경우/ 없는 경우)

galong — Tue, 10 Feb 2026 16:40:53 +0900

1. 가중치가 없을 때 → BFS

모든 간선의 비용이 같을 때 (예: 한 칸 이동 = 1)

BFS는 가까운 노드부터 차례대로 탐색하기 때문에 처음 도착한 거리가 최단거리이다.

한 칸당 이동하는 데 드는 비용이 같고,

int[][] map 환경에서 A에서 B까지 가는 데에 걸리는 최단 거리를 구하는 문제가 나오면

다음과 같이 풀면 된다.

import java.util.*;

class Solution {
    static int[] dx = {1, -1, 0, 0};
    static int[] dy = {0, 0, 1, -1};

    public int bfs(int[][] map) {
        int n = map.length;
        int m = map[0].length;
        
        boolean[][] visited = new boolean[n][m];
        Queue<int[]> q = new LinkedList<>();
        
        q.offer(new int[]{0, 0, 1}); // x, y, 거리
        visited[0][0] = true;
        
        while(!q.isEmpty()) {
            int[] now = q.poll();
            int x = now[0];
            int y = now[1];
            int dist = now[2];
            
            if(x == n-1 && y == m-1) return dist;
            
            for(int i = 0; i < 4; i++) {
                int nx = x + dx[i];
                int ny = y + dy[i];
                
                if(nx >= 0 && ny >= 0 && nx < n && ny < m) {
                    if(!visited[nx][ny] && map[nx][ny] == 1) {
                        visited[nx][ny] = true;
                        q.offer(new int[]{nx, ny, dist + 1});
                    }
                }
            }
        }
        return -1;
    }
}

bfs로 풀어 Queue 선언
Queue에는 {start, end, distance} : start에서 end까지 가는데 움직인 거리 distance를 저장한다.
상하좌우 보면서 움직일 수 있고, 방문한 적이 없으면 다음 좌표와 distance+1를 해서 queue에 값을 추가한다.

시간 복잡도는 O(V+E)

2. 가중치가 있을 때 → 다익스트라

길마다 비용이 다를 때,

가장 현재까지 비용이 적은 노드부터 탐색 → PriorityQueue 사용

import java.util.*;

class Solution {
    static final int INF = Integer.MAX_VALUE;
    static ArrayList<int[]>[] graph; // {다음정점, 가중치}
    static int[] dist;
    
    // graph에 a -> b 까지 가는 거리 저장 
    graph = new ArrayList[n + 1];
		for (int i = 1; i <= n; i++) {
		  graph[i] = new ArrayList<>();
		}
		
		// 간선 추가 (u -> v, 비용 w)
		graph[u].add(new int[]{v, w});
    
    public void dijkstra(int start, n) {
	    PriorityQueue<int[]> pq = new PriorityQueue<>({o1, o2} -> {
		    return o1[1] - o2[1]; // 비용 기준 오름차순
	    });
	    
	    dist = new int[n+1];
	    Arrays.fill(dist, INF); // 초기화 : 모든 값을 INF로 채우기 
	    
	    dist[start] = 0; // 처음 시작 index는 거리 0
	    pq.offer(new int[]{start, 0}); // 정점, 비용
	    
	    while(!pq.isEmpty()){
		    int[] now = pq.poll();
		    int node = now[0];
		    int cost = now[1];
		    
		    // 이미 더 짧은 경로가 있으면 스킵
		    if(cost > distance[node]) continue;
		    
		    for(int[] next = graph[node]) {
			    int nextNode = next[0];
			    int weight = next[1];
			    
			    int newCost = cost + weight;
			    if(newCost < distance[nextNode]) {
				    distnace[nextNode] = newCost;
				    pq.offer(new int[]{nextNode, newCost});
			    }
			    
		    }
	    }
	    
    
    }
}

초기화 : graph에 a -> b 까지 가는 거리 저장
처음 시작 위치에서 각 위치까지 걸리는 최단 거리 구하기 (dijkstra)
- PriorityQueue<> 에 {nextNode, cost}를 저장해서 cost 기준으로 오름차순으로 정렬
- pq에 {start, 0}을 넣고 pq가 비지 않을 때까지(while)
  - 만약 현재 cost가 distance[node] 보다 크면 continue
  - node에서 갈 수 있는 nextNode(for문)
  - 현재까지 온 cost + nextNode로 가는 weight (newCost) 가 distance[nextNode] 보다 작으면 갱신 ⇒ 처음 시작(start) 위치에서 nextNode로 갈 수 있는 최단 거리 계산

시간 복잡도 O(E logV)

[TIL] 코테에서 자주 쓰는 StringBuilder 메서드 정리

galong — Mon, 12 Jan 2026 17:45:47 +0900

문자열을 반복해서 다뤄야 할때, String 대신 StringBuilder를 사용하면 시간을 단축할 수 있다.

String은 불변 객체이기 때문에, 반복적인 문자열 결합시 불필요한 객체 생성 → 시간 초과를 이어진다.

코테에서 피해야 할 실수

String s = "";
s += "a" // 시간초과 위험 높음

메서드 정리

1️⃣ append() : 문자열 추가

StringBuilder sb = new StringBuilder();
sb.append("hello");
sb.append(" ");
sb.append("world");

2️⃣ toString() : 최종 문자열로 변환

String result = sb.toString();

3️⃣ 길이 확인

int len = sb.length();

4️⃣ charAt() / setCharAt() — 특정 위치 접근 및 수정

charAt()

char c = sb.charAt(3);

setCharAt

sb.setCharAt(0, 'A); // 0번째 값 'A'로 치환

5️⃣ insert() / delete() — 삽입 및 삭제

insert()

sb.insert(2, "ABC"); // "hello" -> "heABCello"

delete()
- 인덱스 범위 (start, end)

sb.delete(1, 4); // "hello" -> "ho" , 1~3 길이 삭제

delete(-4) 같은 표현은 X
시작과 끝을 알려줘야함.

deleteCharAt()

sb.deleteCharAt(0); // 특정 문자 삭제

6️⃣ reverse() - 문자열 뒤집기

sb.reverse();

문자열 뒤집기
숫자 뒤집기

7️⃣ substring() - 문자열 부분 추출

인덱스 범위 : [start, end]

String sub = sb.subString(1,4);

⇒ String으로 반환함

8️⃣ 문자열 비교 시 주의점

sb.toString().equals("abc")

StringBuilder는 equals()로 문자열 비교 ❌
반드시 toString() 후 비교

MSA 환경에서 JitPack으로 공통 모듈 관리하기

galong — Sun, 11 Jan 2026 23:22:25 +0900

MSA 프로젝트에서 각 서비스마다 공통으로 사용하는 코드를 효율적으로 관리하기 위해 JitPack을 활용했습니다. 이 글에서 JitPack이 무엇인지와, 공통 모듈을 배포하고 서비스에 사용하는 방법을 정리해보려고 합니다.

Jitpack이란?

https://jitpack.io/

Jipack은 Git 저장소를 Maven / Gradle 의존성으로 바로 사용할 수 있게 해주는 패키지 배포 서비스이다.

일반적으로 공통 모듈을 여러 서비스에서 사용하려면 각 서비스에 직접 포함시키거나(코드중복), 사설 저장소를 구축해서 사용할 수 있다. 하지만 이 방식들은 모듈 변경 시 서비스 별로 동기화가 필요하거나 저장소 운영비용이 드는 단점이 있다.

Jitpack은 이러한 문제를 Git 저장소 기반 배포라는 방식으로 해결한다.

Jitpack 주요 기능

Jitpack은 다음과 같은 흐름으로 동작한다.

GitHub(GitLab 등)에 있는 저장소
특정 대그 또는 커밋
빌드 시점에 Jitpack이 직접 빌드
빌드 결과를 Maven Repository 형태로 제공

즉, Git 저장소에 태그만 찍으면, 바로 의존성으로 사용할 수 있다.

왜 MSA에서 JitPack을 사용했는가?

MSA 환경에서는 여러 서비스가 공통 코드를 공유하는 경우가 많다.

예를 들어,

공통 응답 객체 (ApiResponse, BaseEntity)
공통 예외 처리 (GlobalExceptionHandler, AppException, ErrorCode …)
공통 유틸 클래스 (PageableUtils, CursorUtils …)
인증/인가 관련 공통 로직 (UserRole, AuthUser… )

이 공통 모듈을 각 서비스에 직접 복사하거나, 서브 모듈로 관리하면

공통 코드 수정 시 모든 서비스에 반영 필요
서비스 간 버전 불일치
배포 및 관리 복잡도 증가

단점이 있다.

Jitpack을 사용하면

공통 모듈을 하나의 저장소로 관리
태그 기반으로 명확한 버전 관리
Gradle/Maven 의존성 추가만으로 즉시 사용 가능 (쉬움)

장점이 있어서 JitPack을 도입했다.

공통 모듈을 jitpack으로 배포하는 방법

1️⃣ 공통 모듈 프로젝트 생성

먼저, 여러 서비스에서 공통으로 사용할 코드를 하나의 모듈로 분리했다.

공통 응답 dto
BaseEntity
공통 예외 및 에러코드
swagger 설정
공통 유틸 클래스

등등

2️⃣ JitPack 배포를 위한 Gradle 설정

JitPack은 Git 저장소를 직접 빌드하기 때문에,

build.gradle에 선언된 라이브러리의 버전이 명확하게 정의되어있어야한다.

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-web:3.3.5'
    ...
}

버전이 명시되지 않은 의존성이 있으면,

jitPack 빌드 과정에서 실패할 수 있으므로 주의해야한다.

3️⃣ 공통 모듈 변경 후 버전 관리

공통 모듈에 기능을 추가하거나 코드를 수정한 경우,

반드시 버전을 증가시켜야 한다.

예) 1.0.0 → 1.0.1 , 1.0.9 → 1.1.0

4️⃣ Git 태그 생성 및 Push

git commit 과 push 하고,

git tag 1.0.7{현재 버전}
git push origin 1.0.7{현재버전}

하면 github tag에 올라간다.

예시)

git commit -m "release: 1.0.7"
git push

git tag 1.0.7
git push origin 1.0.7

5️⃣ JitPack에서 배포 확인

GitHub에 태그가 올라가면, JitPack은 해당 태그를 기준으로 공통 모듈을 빌드하고 배포한다.

배포 및 빌드 상태는 아래 JitPack 페이지에서 확인할 수 있다.

해당 프로젝트의 {organization 이름}/{repository 이름} 을 검색해서 접근할 수 있다.

https://jitpack.io/

예시) KokKok-dev/Tablekok-common

빌드가 성공하면 해당 버전을 Gradle/ Maven 의존성으로 바로 사용할 수 있다.

서비스에서 JitPack 공통 모듈 사용하는 방법

1️⃣ JitPack Repository 추가

https://jitpack.io/

위 링크에서도 어떻게 사용하는지 방법을 알려준다.

먼저 서비스의 build.gralde에 JitPack 저장소를 추가한다.

repositories {
    mavenCentral()
    maven { url '<https://jitpack.io>' }
}

JitPack은 Maven Repository 형태로 동작하기 때문에 기존 mavenCentral() 설정과 함께 추가해주면 된다.

2️⃣ 공통 모듈 의존성 추가

다음으로 JitPack에 배포한 공통 모듈을 의존성으로 추가한다.

implementation 'com.github.KokKok-dev:Tablekok-common:1.0.0'

이때 사용하는 버전은 GitHub에 생성한 태그 버전과 동일해야 한다.

공통 모듈에 변경 사항이 생기면

태그 버전을 올리고, 서비스에서는 해당 버전만 변경해 적용하면 된다.

3️⃣ 공통 모듈 사용 예시

의존성 설정을 했으면, 공통 모듈에 정의된 클래스들을 일반 라이브러리처럼 바로 사용할 수 있다.

예시)

BaseEntity tablekok.entity 라이브러리에서 가지고 올 수 있다.

ApiResponse도 가지고 올 수 있다.

GlobalExceptionHandler도 가지고 올 수 있다.

모두 com.tablekok 패키지 하위에 정의된 것으로 그대로 사용할 수 있다.

[MSA] Spring Cloud 기반 MSA 아키텍처 개념 정리

galong — Wed, 7 Jan 2026 22:43:15 +0900

정리
- MSA 개념
- 모놀리식 vs MSA
- Spring Cloud
- Eureka
- FeignClient + LoadBalancing
- 서킷브레이커: Resilience4j
- API Gateway
- Spring Cloud Config

MSA란

Microservices Architecture(MSA) 는 하나의 애플리케이션을 여러 개의 독립적인 서비스로 분리하여 개발, 배포, 유지보수를 용이하게 하는 소프트웨어 아키텍처 스타일이다. 각 서비스는 특정 비즈니스 기능을 수행하며, 서로 독립적으로 배포되고 확장될 수 있다. 서비스 간의 통신은 HTTP/HTTPS, 메시지 큐 등을 통해 이루어진다.

특징

독립적인 배포 가능성: 각 서비스는 독립적으로 배포할 수 있으며, 다른 서비스에 영향을 주지 않고 업데이트할 수 있음
작은 팀 구성: 각 서비스는 작은 팀이 독립적으로 개발하고 관리할 수 있음
기술 스택의 다양성: 각 서비스는 적절한 기술 스택을 자유롭게 선택할 수 있음

모놀리식 아키텍처와 비교

왼: 모놀리식 아키텍처 / 오: msa 아키텍처

	모놀리틱 아키텍처	MSA
정의	* 하나의 큰 코드 베이스로 구성된 애플리케이션 * 모든 기능이 하나의 애플리케이션 내에 포함	* 여러 개의 독립적인 서비스로 구성된 애플리케이션 * 각 서비스는 특정 비즈니스 기능을 수행
장점	* 간단한 배포 * 단일 데이터베이스	* 확장성 * 독립적 배포 * 유연성 : 서비스별로 적합한 기술 스택을 선택할 수 있음
단점	* 확장성 부족 * 긴 개발 주기 * 유연성 부족	* 복잡성 증가 * 운영비용 증가 * 데이터 관리 : 분산된 데이터베이스로 인해 데이터 일관성 유지가 어려울 수 있음 * 네트워크 지연 : 서비스 간의 통신이 네트워크를 통해 이루어지므로 지연 시간이 발생할 수 있음 * 서비스마다 통신

Spring Cloud란?

마이크로서비스 개발을 위해 다양한 도구와 서비스를 제공하는 스프링 프레임워크의 확장이다.

주요 기능

서비스 등록 및 디스커버리: Eureka, Consul, Zookeeper
로드 밸런싱: Ribbon, Spring Cloud LoadBalancer
서킷 브레이커: Hystrix, Resilience4j
API 게이트웨이: Zuul, Spring Cloud Gateway
구성 관리: Spring Cloud Config
분산 추적: Spring Cloud Sleuth, Zipkin
메시징: Spring Cloud Stream

Eureka : 서비스 등록 및 디스커버리

넷플릭스가 개발한 서비스 디스커버리 서버로, 마이크로서비스 아키텍처에서 각 서비스의 위치를 동적으로 관리
주요 특징:
- 서비스 레지스트리: 모든 서비스 인스턴스의 위치를 저장하는 중앙 저장소
- 헬스 체크(Health check): 서비스 인스턴스의 상태를 주기적으로 확인하여 가용성을 보장

Ribbon : 로드 밸런싱

넷플릭스가 개발한 클라이언트 사이드 로드 밸런서로, 서비스 인스턴스 간의 부하를 분산
주요 특징:
- 서버 리스트 제공자: Eureka로부터 서비스 인스턴스 리스트를 제공받아 로드 밸런싱에 사용
- 로드밸런싱 알고리즘: 라운드 로빈, 가중치 기반 등 다양한 로드 밸런싱 알고리즘 지원
- Failover: 요청 실패 시 다른 인스턴스로 자동 전환

Hystrix : 서킷 브레이커

넷플릭스가 개발한 서킷 브레이커 라이브러리로, 서비스 간의 호출 실패를 감지하고 시스템의 전체적인 안정성을 유지
주요 특징:
- 서킷 브레이커 상태: 클로즈드, 오픈, 하프-오픈 상태를 통해 호출 실패를 관리
- Failback: 호출 실패 시 대체 로직을 제공하여 시스템 안정성 확보
- 모니터링: Hystrix Dashboard를 통해 서킷 브레이커 상태 모니터링

Resilience4j : 서킷 브레이커

Resilience4j는 자바 기반의 경량 서킷 브레이커 라이브러리로, 넷플릭스 Hystrix의 대안으로 개발
주요 특징:
- 서킷 브레이커: 호출 실패를 감지하고 서킷을 열어 추가적인 호출을 차단하여 시스템의 부하를 줄임
- Failback: 호출 실패 시 대체 로직을 실행하여 시스템의 안정성을 유지
- 타임아웃 설정: 호출의 응답 시간을 설정하여 느린 서비스 호출에 대응할 수 있음
- 재시도: 재시도 기능을 지원하여 일시적인 네트워크 문제 등에 대응할 수 있음

Zuul : API 게이트웨이

넷플릭스가 개발한 API 게이트웨이로, 모든 서비스 요청을 중앙에서 관리
주요 특징:
- 라우팅: 요청 URL에 따라 적절한 서비스로 요청 전달
- 필터: 요청 전후에 다양한 작업을 수행할 수 있는 필터 체인 제공
- 모니터링: 요청 로그 및 메트릭을 통해 서비스 상태 모니터링 할 수 있음

Spring Cloud Config : 구성관리

Spring Cloud Config는 분산된 환경에서 중앙 집중식 설정 관리를 제공
주요 특징:
- Config 서버: 중앙에서 설정 파일을 관리하고 각 서비스에 제공
- Config 클라이언트: Config 서버에서 설정을 받아서 사용하는 서비스
- 설정갱신: 설정 변경 시 서비스 재시작 없이 실시간으로 반영

서비스 디스커버리 : Eureka

서비스 디스커버리란?

마이크로서비스 아키텍처에서 각 서비스의 위치를 동적으로 관리하고 찾아주는 기능을 한다. 각 서비스는 등록 서버(eureka)에 자신의 위치를 등록하고 각 서비스간의 통신도 이를 조회하여 위치를 찾는다. 주요 기능으로는 서비스 등록, 서비스 조회, 헬스 체크 등이 있다.

Eureka란?

넷플릭스가 개발한 서비스 디스커버리 서버
모든 서비스 인스턴스의 위치를 저장하는 중앙 저장소 역할을 하며, 서비스 인스턴스의 상태를 주기적으로 확인하여 가용성 보장
여러 인스턴스를 지원하여 고가용성을 유지할 수 있음

로드밸런싱 : 클라이언트 사이드 로드 밸런싱 개요

로드밸런싱이란?

로드 밸런싱은 네트워크 트래픽을 여러 서버로 분산시켜 서버의 부하를 줄이고, 시스템의 성능과 가용성을 높이는 기술을 의미한다. 서버 간 트래픽을 고르게 분배하여 특정 서버에 부하가 집중되는 것을 방지한다.

종류 : 클라이언트 사이드 로드 밸런싱, 서버 사이드 로드 밸런싱

클라이언트 사이드 로드 밸런싱이란?

클라이언트가 직접 여러 서버 중 하나를 선택하여 요청을 보내는 방식
클라이언트는 서버의 목록을 가지고 있으며, 이를 바탕으로 로드 밸런싱 수행

각 서비스 간의 통신 방법 중 FeignClient란?

FeignClient란?

FeignClient는 Spring Cloud에서 제공하는 HTTP 클라이언트로, 선언적으로 Restful 웹 서비스를 호출할 수 있음
Eureka와 같은 서비스 디스커버리와 연동하여 동적으로 서비스 인스턴스를 조회하고 로드 밸런싱 수행

주요 특징

선언적 HTTP 클라이언트 : 인터페이스와 어노테이션을 사용하여 REST API 호출
Eureka 연동
자동 로드 밸런싱 : Ribbon이 통합되어 있어 자동으로 로드 밸런싱 수행

예시 시나리오

Order 서비스는 Product 서비스를 호출하여 상품 정보를 가져옵니다. 이 과정에서 어떻게 동작하는지 설명하겠습니다.

Order 서비스 인스턴스: 1개
Product 서비스 인스턴스: 3개

Order 서비스 실행: Order 서비스가 실행되면 Eureka 서버에서 Product 서비스 인스턴스 목록을 가져옵니다.
Product 서비스 호출: Order 서비스에서 Product 서비스의 정보를 가져오기 위해 FeignClient를 사용하여 호출합니다.
Ribbon을 통한 로드 밸런싱: FeignClient는 Ribbon을 통해 3개의 Product 인스턴스 중 하나를 선택하여 호출합니다. 이 과정에서 Round Robin 알고리즘을 사용하여 요청을 순차적으로 분배합니다.
응답 처리: 선택된 Product 인스턴스에서 응답을 받아 Order 서비스에 반환하고, 최종적으로 클라이언트에 응답을 전달합니다.

서킷브레이커 : Resilience4j

서킷브레이커란?

마이크로서비스 간의 호출 실패를 감지하고, 시스템의 전체적인 안정성을 유지하는 패턴이다. 외부 서비스 호출 실패 시 빠른 실패를 통해 장애를 격리하고, 시스템의 다른 부분에 영향을 주지 않도록 한다.

상태 변화 : 클로즈드 → 오픈 → 하프-오픈

서킷 브레이커 상태:

클로즈드, 오픈, 하프-오픈 상태를 통해 호출 실패를 관리

클로즈드(Closed):
- 기본 상태로, 모든 요청을 통과시킵니다.
- 이 상태에서 호출이 실패하면 실패 카운터가 증가합니다.
- 실패율이 설정된 임계값(예: 50%)을 초과하면 서킷 브레이커가 오픈 상태로 전환됩니다.
- 예시: 최근 5번의 호출 중 3번이 실패하여 실패율이 60%에 도달하면 오픈 상태로 전환됩니다.
오픈(Open):
- 서킷 브레이커가 오픈 상태로 전환되면 모든 요청을 즉시 실패로 처리합니다.
- 이 상태에서 요청이 실패하지 않고 바로 에러 응답을 반환합니다.
- 설정된 대기 시간이 지난 후, 서킷 브레이커는 하프-오픈 상태로 전환됩니다.
- 예시: 서킷 브레이커가 오픈 상태로 전환되고 20초 동안 모든 요청이 차단됩니다.
하프-오픈(Half-Open):
- 오픈 상태에서 대기 시간이 지나면 서킷 브레이커는 하프-오픈 상태로 전환됩니다.
- 하프-오픈 상태에서는 제한된 수의 요청을 허용하여 시스템이 정상 상태로 복구되었는지 확인합니다.
- 요청이 성공하면 서킷 브레이커는 클로즈드 상태로 전환됩니다.
- 요청이 다시 실패하면 서킷 브레이커는 다시 오픈 상태로 전환됩니다.
- 예시: 하프-오픈 상태에서 3개의 요청을 허용하고, 모두 성공하면 클로즈드 상태로 전환됩니다. 만약 하나라도 실패하면 다시 오픈 상태로 전환됩니다.

Fallback 매커니즘

Fallback 메서드는 외부 서비스 호출이 실패했을 때 대체 로직을 제공하는 메서드

장점

시스템의 안정성을 높이고, 장애가 발생해도 사용자에게 일정한 응답을 제공할 수 있습니다.
장애가 다른 서비스에 전파되는 것을 방지합니다.

API Gateway

API 게이트웨이란?

클라이언트의 요청을 받아 백엔드 서비스로 라우팅하고, 다양한 부가 기능을 제공하는 중간 서버이다. 클라이언트와 서비스 간의 단일 진입점 역할을 하며, 보안, 로깅, 모니터링, 요청 필터링 등을 처리한다.

주요기능

라우팅: 클라이언트 요청을 적절한 서비스로 전달
인증 및 권한 부여: 요청의 인증 및 권한을 검증
로드 밸런싱: 여러 서비스 인스턴스 간의 부하 분산
모니터링 및 로깅: 요청 및 응답을 로깅하고 모니터링
요청 및 응답 변환: 요청과 응답을 변환하거나 필터링

Spring Cloud Gateway란?

Spring 프로젝트의 일환으로 개발된 API 게이트웨이로, 클라이언트 요청을 적절한 서비스로 라우팅하고 다양한 필터링 기능을 제공한다.

주요특징

동적 라우팅: 요청의 URL 패턴에 따라 동적으로 라우팅
필터링: 요청 전후에 다양한 작업을 수행할 수 있는 필터 체인 제공
모니터링: 요청 로그 및 메트릭을 통해 서비스 상태 모니터링

Spring Cloud Gateway 필터링

필터종류

Global Filter: 모든 요청에 대해 작동하는 필터
Gateway Filter: 특정 라우트에만 적용되는 필터

필터 구현

필터를 구현하려면 GlobalFilter 또는 GatewayFilter 인터페이스를 구현하고, filter 메서드를 오버라이드해야 합니다.

Config

Spring Cloud Config 란?

분산 시스템 환경에서 중앙 집중식 구성 관리를 제공하는 프레임워크이다. 애플리케이션의 설정을 중앙에서 관리하고, 변경 사항을 실시간으로 반영할 수 있다. Git, 파일 시스템, JDBC 등 다양한 저장소를 지원한다.

주요기능

중앙 집중식 구성 관리 : 모든 마이크로서비스의 설정을 중앙에서 관리
환경별 구성 : 개발, 테스트, 운영 등 환경별로 구성을 분리하여 관리
실시간 구성 변경: 설정 변경시 애플리케이션을 재시작하지 않고도 실시간으로 반영할 수 있따.

[Spring Boot] 토스페이먼츠 결제 연동 구현하기 - 2편

galong — Mon, 5 Jan 2026 22:04:33 +0900

이전 편에서는 토스페이먼츠 결제 플로우를 작성했습니다.

https://galong.tistory.com/34

이번 편에서는 결제 연동 구현한 것을 정리했습니다.

이 방식이 옳은 방식은 아닐 수도 있으므로, 참고만 부탁드립니다!

더 좋은 방식이 있으면 댓글도 부탁드립니다. ‍♀️

들어가며

이번 글에서는 토스페이먼츠 결제 위젯을 활용해

주문 → 결제 요청 → 결제 승인 → 결과 페이지 이동까지의 흐름을 정리했습니다.

주문서 진입 시 Payment 객체를 미리 생성해 서버 기준 결제 정보를 저장해두고, 결제 위젯 성공 이후에는 preparing 단계를 거치게 했습니다.
preparing 단계에서 파라미터로 받은 paymentKey와 amount 정보 등을 서버에 보내 검증했습니다.
그리고 외부 toss api 호출을 하여 최종 결제 승인을 요청합니다.
결제 승인 결과에 따라 success 또는 fail 화면을 client에게 보여줍니다.

1. checkout.html 구성하기

결제 연동 시작은 주문서 페이지(checkout.html) 입니다.

1-1. 주문서 진입 시 Payment 객체 생성

@PostMapping("/checkout")
public String checkout(@RequestParam("userId") Long userId, @RequestParam("orderId") UUID orderId,
	@RequestParam("orderName") String orderName, @RequestParam("amount") Long amount, Model model) {

	User user = userService.findByUser(userId);
	Order order = orderService.findByOrder(orderId);

	// Payment 객체 생성
	paymentPageService.createPayment(user, order);

	List<String> itemNames = order.getOrderItems()
		.stream()
		.map(oi -> oi.getMenuItem().getName())
		.collect(Collectors.toList());

	// view에 전달
	model.addAttribute("user", user);
	model.addAttribute("order", order);
	model.addAttribute("itemNames", itemNames);
	return "checkout"; 
}

주문서 페이지에 진입하면 서버에서는 Payment 객체를 생성합니다.

이 시점에 Payment를 생성하는 이유는 이후 결제 승인 단계에서 클라이언트 위변조 여부 검증을 위해 미리 생성합니다.

Payment.java

public class Payment extends BaseEntity {

	@Id
	@GeneratedValue(strategy = GenerationType.UUID)
	private UUID id;

	@ManyToOne(fetch = FetchType.LAZY)
	@JoinColumn(name = "user_id")
	private User user;

	@OneToOne
	@JoinColumn(name = "order_id")
	private Order order;

	private String tossOrderId;

	@Enumerated(EnumType.STRING)
	private PaymentType paymentType;

	private BigInteger amount;

	@Enumerated(EnumType.STRING)
	private PaymentStatus paymentStatus;

	@Column(name = "payment_key")
	private String paymentKey;

	@Enumerated(EnumType.STRING)
	private FailReason failReason;

	private String refundReason;

	private LocalDateTime approvedAt;
	
}

1-2. 결제 위젯 초기화 및 결제 요청

결제 요청 시 필요한 값들은 JavaScript에서도 사용해야해서

js 변수에는 /[[${...}]]/ 방식을 사용해서 저 3가지 값을 가지고 옵니다.

checkout.html

<script th:inline="javascript">
    /*<![CDATA[*/
    const totalAmount = /*[[${order.totalPrice}]]*/ 0;
    const orderId = /*[[${order.id}]]*/ '';
    const itemNames = /*[[${itemNames}]]*/ [];
    const orderName = itemNames.join(', ');
    const userId = /*[[${user.id}]]*/ 0;
    /*]]>*/

</script>

main() 함수에서는 토스페이먼츠 결제 위젯을 초기화하고,

결제 버튼 클릭 시 결제 요청을 수행합니다.

checkout.html

async function main() {
  const button = document.getElementById("payment-button");
  const coupon = document.getElementById("coupon-box");

  // ------ 결제위젯 초기화 ------
  const clientKey = "test_gck_docs_Ovk5rk1EwkEbP0W43n07xlzm";
  const tossPayments = TossPayments(clientKey);
  const widgets = tossPayments.widgets({customerKey: "eyOAk1FoZbRguExkPqAH_"});

  // ------ 주문의 결제 금액 설정 ------
  await widgets.setAmount({currency: "KRW", value: totalAmount});

  await Promise.all([
      widgets.renderPaymentMethods({selector: "#payment-method", variantKey: "DEFAULT"}),
      widgets.renderAgreement({selector: "#agreement", variantKey: "AGREEMENT"})
  ]);

  // ------ 쿠폰 체크 시 결제 금액 업데이트 ------
  coupon.addEventListener("change", async function () {
      const amountToPay = coupon.checked ? totalAmount - 5000 : totalAmount;
      await widgets.setAmount({currency: "KRW", value: amountToPay});
  });

  const successUrl = window.location.origin + "/preparing";
  const failUrl = window.location.origin + "/fail";

  // ------ 결제하기 버튼 클릭 시 결제 요청 ------
  button.addEventListener("click", async function () {
      await widgets.requestPayment({
          orderId: finalOrderId,
          orderName: orderName,
          successUrl: successUrl,
          failUrl: failUrl,
          customerEmail: customerEmail,
          customerName: customerName,
          customerMobilePhone: customerMobileReplace,
      });
  });
}

여기에서 주의해야할 점은

1. 결제 금액은 서버 기준 값 사용

await widgets.setAmount({ value: totalAmount });

서버에서 전달한 order.totalPrice 로 set.

2. successUrl을 /preparing 으로 설정

const successUrl = window.location.origin + "/preparing";

이러면 위젯에서 성공적으로 승인이 일어나면 /preparing 로 redirect 됩니다.

2. preparingUrl에서 결제 승인 요청을 처리하기

checkout 페이지에서 결제 위젯을 통해 사용자 정보 입력과 카드사 승인이 완료되면, 결제 위젯은 설정해둔 successUrl로 이동합니다.

이번 구현에서는 successUrl을 바로 성공 페이지로 두지 않고, 중간 단계인 preparingUrl을 거치도록 설계했습니다.

2-1. 카드사 승인 이후 preparingUrl 로 redirect

결제 위젯에서 카드사 승인이 완료되면 다음과 같은 파라미터와 함께 preparingUrl로 이동합니다.

paymentKey
orderId
amount
userId

이때 paymentKey 발급됩니다!

@GetMapping("/preparing")
public String preparing(Long userId, Model model) {
	model.addAttribute("userId", userId);
	return "preparing";
}

2-2. preparing.html

preparing.html 전체 코드

<body>
<h2>결제 준비중...</h2>
<p id="paymentKey"></p>
<p id="orderId"></p>
<p id="amount"></p>

<script>
    // 쿼리 파라미터 값이 결제 요청할 때 보낸 데이터와 동일한지 반드시 확인하세요.
    // 클라이언트에서 결제 금액을 조작하는 행위를 방지할 수 있습니다.
    const urlParams = new URLSearchParams(window.location.search);
    const userId = urlParams.get("userId");
    const paymentKey = urlParams.get("paymentKey");
    const orderId = urlParams.get("orderId");
    const amount = urlParams.get("amount");

    async function confirm() {
        const requestData = {
            paymentKey: paymentKey,
            orderId: orderId,
            amount: amount,
        };

        const response = await fetch("/v1/test/payment/confirm", {
            method: "POST",
            headers: {
                "Content-Type": "application/json",
            },
            body: JSON.stringify(requestData),
        });

        const json = await response.json();

        if (!response.ok) {
            // TossConfirmPageException 발생 → fail 페이지로 redirect
            window.location.href = `/fail&code=${json.code}&message=${encodeURIComponent(json.message)}`;
            return;
        } else {
            window.location.href = `/success&code=${json.code}&message=${encodeURIComponent(json.message)}&paymentKey=${paymentKey}&orderId=${orderId}&amount=${amount}`;
        }

        console.log("결제 승인 성공:", json);
    }

    confirm();

    const paymentKeyElement = document.getElementById("paymentKey");
    const orderIdElement = document.getElementById("orderId");
    const amountElement = document.getElementById("amount");

    orderIdElement.textContent = "주문번호: " + orderId;
    amountElement.textContent = "결제 금액: " + amount;
    paymentKeyElement.textContent = "paymentKey: " + paymentKey;
</script>

prearing.html은 결제 승인(confirm)을 서버에 요청하기 위한 중간 처리 페이지입니다.

<h2>결제 준비중...</h2>

이 화면이 잠깐 노출되는 동안,

클라이언트에서는 쿼리 파라미터로 전달받은 값들을 추출합니다.

const urlParams = new URLSearchParams(window.location.search);
const userId = urlParams.get("userId");
const paymentKey = urlParams.get("paymentKey");
const orderId = urlParams.get("orderId");
const amount = urlParams.get("amount");

이 값들은 신뢰할 수 있는 값이 아니라서 서버에서 반드시 검증을 해야합니다.

2-3. 결제 승인(confirm) 요청을 서버로 전달

preparingUrl에서는 서버에 paymentKey, orderId, amount를 requestBody에 담아 보냅니다.

const requestData = {
    paymentKey: paymentKey,
    orderId: orderId,
    amount: amount,
};

const response = await fetch("/v1/test/payment/confirm", {
    method: "POST",
    headers: {
        "Content-Type": "application/json",
    },
    body: JSON.stringify(requestData),
});

2-4. 서버: 토스에 결제 승인 요청

preparing 페이지에서 전달받은 paymentKey, orderId, amount를 기반으로 서버에서 토스 결제 승인 API를 호출합니다.

@ResponseBody
@PostMapping("/v1/test/payment/confirm")
public ResponseEntity<BaseResponseDto<?>> confirmPayment(@RequestBody ConfirmPaymentPageRequestDto requestDto) {
	ConfirmPaymentPageResponseDto response = paymentPageService.confirmPayment(requestDto);
	return ResponseEntity.ok(BaseResponseDto.success("결제 요청을 승인합니다.", response));
}

@Transactional
@Override
public ConfirmPaymentPageResponseDto confirmPayment(ConfirmPaymentPageRequestDto requestDto) {
    String orderIdWithTimestamp = validateAndExtractOrderId(requestDto.getOrderId());
    Order order = findOrderOrThrow(orderIdWithTimestamp);

    validatePaymentStatus(order); // 1. payment 객체 상태가 PENDING 인지 확인
    Payment payment = findPaymentByOrderOrThrow(order);
    validateAmount(payment, requestDto.getAmount()); // 2. 서버에 담긴 값과 같은지 확인

    ConfirmPaymentPageResponseDto responseDto;

    try {
        responseDto = tossPaymentWebClient.confirmPayment(requestDto); // 3. 토스 서버에 결제 승인 요청

    } catch (TossConfirmPageException ex) {
        paymentTransactionService.markPaymentFailed(payment); // 3-1. 결제 실패 시 payment 객체 결제 상태 FAILED로 변경
        throw ex;
    }

    updatePaymentAndOrder(payment, order, responseDto, orderIdWithTimestamp); // 4. 최종결제 승인 후, payment 객체와 order 객체 상태 변경

    return responseDto;
}

validatePaymentStatus()
- payment 객체 상태가 PENDING 인지 검증합니다.
validateAmount()
- 이 함수에서 이전에 생성해둔 Payment에 저장된 amount 값과 client가 보낸 amount 값이 같은지 검증합니다.
- 클라이언트의 금액 조작을 방지하기 위해 검증합니다.
- 토스 승인 요청 전에 반드시 서버 기준 값으로 검증을해야합니다.
토스 서버에 결제 승인 요청.

2-5. 토스 결제 승인 API 호출

앞 단계에서 결제 금액과 결제 상태를 모두 검증했다면,

이제 서버는 토스 페이먼츠에 최종 결제 승인을 요청합니다.

try {
    responseDto = tossPaymentWebClient.confirmPayment(requestDto); // 3. 토스 서버에 결제 승인 요청
}

토스 결제 승인 API 호출 방식

public ConfirmPaymentPageResponseDto confirmPayment(ConfirmPaymentPageRequestDto requestDto) {
    String widgetSecretKey = secretKey;
    String authorizations =
        "Basic " + Base64.getEncoder().encodeToString((widgetSecretKey + ":").getBytes(StandardCharsets.UTF_8));

    return webClient.post()
        .uri("/payments/confirm")
        .contentType(MediaType.APPLICATION_JSON)
        .header("Authorization", authorizations)
        .bodyValue(requestDto)
        .retrieve()
        .onStatus(status -> !status.is2xxSuccessful(), clientResponse ->
            clientResponse.bodyToMono(TossErrorResponseDto.class)
                .flatMap(error -> Mono.error(
                    new TossConfirmPageException(error.getCode(), error.getMessage())
                ))
        )
        .bodyToMono(ConfirmPaymentPageResponseDto.class)
        .block();
}

/payments/confirm API는 Secrekt Key를 사용해 인증합니다.

이 키는 절대 클라이언트에 노출되면 안됩니다.

webClient 비동기 방식으로 외부 api를 요청했습니다.

만약 토스 서버에서 승인 실패 응답이 내려오면 TossConfirmPageException() 커스텀 예외처리를합니다.

실패 시

catch (TossConfirmPageException ex) {
    paymentTransactionService.markPaymentFailed(payment); // 3-1. 결제 실패 시 payment 객체 결제 상태 FAILED로 변경
    throw ex;
}

토스 결제 승인 요청 중 오류가 나거나, 서버 검증 단계에서 문제가 발생되면 결제는 실패 처리됩니다.

markPaymentFailed() 함수를 실행됩니다.

이 경우 서버에서는

Payment 상태를 FAILED로 변경
실패 사유(failReason) 기록

그 후 preparing 페이지는 실패 응답을 받고 사용자를 fail 페이지로 이동시킵니다.

보통 카드 잔액 부족, 네트워크 오류, 토스 승인 거절 등의 이유로 실패가 일어납니다.

3. 결제 승인 결과 여부에 따라 successUrl/failUrl 이동

updatePaymentAndOrder(payment, order, responseDto, orderIdWithTimestamp); // 4. 최종결제 승인 후, payment 객체와 order 객체 상태 변경

토스의 결제 승인 API가 정상적으로 응답하면,

서버는 해당 결제를 최종 승인된 결제로 기록합니다.

Payment 상태를 PAID로 변환하고
토스에서 발급한 paymentKey 저장
Order 상태도 결제 완료 상태로 변경

승인 결과에 따른 클라이언트 이동 처리

preparing.html

if (!response.ok) {
    // TossConfirmPageException 발생 → fail 페이지로 redirect
    window.location.href = `/fail&code=${json.code}&message=${encodeURIComponent(json.message)}`;
    return;
} else {
    window.location.href = `/success&code=${json.code}&message=${encodeURIComponent(json.message)}&paymentKey=${paymentKey}&orderId=${orderId}&amount=${amount}`;
}

서버에서 결제 승인과 상태 변경이 모두 완료되면, preparing 페이지의 JavaScript는 응답 결과에 따라 사용자를 success 페이지로 이동시킵니다.

@GetMapping("/success")
public String success(Model model) {
    model.addAttribute("userId", userId);
    return "success";
}

@GetMapping("/fail")
public String fail(Model model) {
    model.addAttribute("userId", userId);
    return "fail";
}

서버의 응답에 따라 successUrl로 갈 수도 있고, failUrl로 갈 수도 있습니다.

위 코드는 사용자에게 페이지 보여주는 controller입니다.

회고

처음에 결제 플로우를 이해하는 데 시간을 많이 썼습니다. Payment 객체에는 어떤 필드 값들이 필요하고, 결제 상태는 어떤 단계로 둘 것인지, 클라이언트 금액 위변조 방지는 어떻게 할지, Payment 객체는 언제 생성하는지 등 여러 가지를 고민하며 구현했습니다. 이 과정에서 팀원과 처음으로 페어프로그래밍을 진행했는데, 각자가 생각한 결제 플로우 의견을 얘기하면서 구현해 나간 점에서 많이 배우고 기억에 오래 남았습니다.

튜터님 피드백에서는 최종 결제 승인이 났는데 서버 오류로 인해 서버에서 처리가 제대로 이루어지지 않은 경우나, 중복 결제 요청이 발생하는 경우를 고려해서 고도화해보면 좋겠다는 피드백을 남겨주셨습니다. 튜터님의 피드백을 듣고 단순히 “결제가 된다”는 결과보다, 언제 어떤 상태를 서버가 책임져야 하는지 좀 더 고민하게 됐습니다. 아직 모든 예외 상황을 완벽하게 처리된 코드는 아니지만, 결제 시스템에서 서버가 맡아야 할 역할과 책임을 인식하게 된 경험이라는 점에서 의미있는 프로젝트였습니다.

[SpringBoot] 토스페이먼츠 결제 플로우 이해하기 - 1편

galong — Sun, 4 Jan 2026 21:16:53 +0900

1차 프로젝트 때 결제 파트를 담당했습니다.

결제는 처음이라 우선 결제 플로우를 이해하는 것에 집중했습니다.

이번 프로젝트에서는 PG사로 토스페이먼츠(Toss Payments)를 선택했고,

공식 개발자 가이드가 상세하고 친절하게 설명이 잘 되어 있어서 구현 과정에서 많은 도움을 받을 수 있었습니다.

https://docs.tosspayments.com/guides/v2/payment-widget/integration

결제 연동 과정에서 고민했던 부분은

orderId와 amount 값을 언제 서버에 저장해야 할까?
- 결제 요청 이전에 저장하는지
- 결제 승인 이후에 저장하는지
카드사 승인 이후 바로 successUrl로 이동하는 것이 맞을까?
- 카드사 승인 완료 이후 무조건 successURL로 이동하게 되어있습니다.
- 하지만 이 시점은 아직 토스 서버에 최종 결제 승인(confirm)을 요청하기 전 단계입니다.
- 이 상태에서 사용자에게 곧바로 "결게 성공" 화면을 보여주는 것이 사용자 경험 측면에서 적절한가에 대한 의문이 들었습니다.

이 2가지 였습니다.

이 고민을 고려하여 다음과 같이 구현했습니다.

주문서 페이지 진입 시점에 서버에서 Payment 객체를 미리 생성
- orderId, amount 값을 서버에 선저장
- 클라이언트에서 전달받은 값이 아닌, 서버 기준 데이터를 신뢰
카드사 승인 이후 successUrl 대신 preparingUrl로 이동
- 이 단계에서는 아직 "결제 성공"으로 처리하지 않음
- paymentKey를 파라미터로 전달
preparingUrl에서 토스 서버에 최종 결제 승인 요청
- paymentKey, orderId, amount 를 기준으로 결제 확정
- 승인 성공 시에만 결제 성공 상태로 변경

이러한 구조로 구현했습니다.

이를 기반으로 구현한 내용을 정리해보겠습니다!

전체 플로우

전체적으로 보면 이런 시퀀스다이어그램입니다.

하나씩 뜯어봅시다!

1. 주문서 진입 시 Payment 객체 생성

toss에서 결제 요청과 승인 사이에 데이터 무결성을 확인하기 위해 orderId와 amount를 서버에 임시 저장했습니다.

status pending인 Payment객체를 생성하고 {orderId, amount} 값을 저장했습니다.

2. 결제 위젯 렌더링 및 결제 요청

그 후에 주문서에서 결제 위젯을 렌더링하고, 결제 정보를 입력합니다. (결제수단 선택)

3. 카드사 승인 후 preparingUrl 이동

사용자가 입력한 정보와 카드사 승인을 받으면 preparingUrl로 이동합니다.

preparingUrl에서 paymentKey와 orderId, amount를 쿼리파라미터로 받습니다.

토스 개발자 가이드에서는 카드사 승인 이후 success.html 또는 fail.html로 바로 이동하도록 안내하고 있습니다.

하지만 이 시점은 토스 서버에 최종 결제 승인(confirm)을 요청하기 전 단계입니다. 그럼에도 불구하고 사용자에게 “결제 성공” 화면을 보여주는 플로우가 사용자 경험 측면에서 다소 어색하다고 느꼈습니다.

그래서 카드사 승인과 최종결제 승인을 분리하기 위해 preparingUrl을 추가했습니다.

4. preparingUrl에서 결제 승인 검증

preparingUrl에서는 쿼리파라미터로부터 받은 paymentKey와 orderId, 결제 금액 등을 서버에 보냅니다.

서버에서는 toss한테 결제 승인 api를 보내기 전에 client로부터 받은 amount 값과 payment 객체의 amount 파라미터의값이 같은지 검증합니다.

같으면 toss한테 결제 승인 API를 날리고, 같지 않으면 failUrl로 redirect합니다.

5. 결제 승인 성공 / 실패 처리

서버는 toss한테 승인 API를 요청한 후, 승인이 나면 preparingUrl → successUrl로 redirect하고, payment 객체에

payment_key 를 저장하고, status를 PAID 로 변경합니다.

승인 실패가 일어나면 failUrl로 redirect되고, status를 FAILED로 변경합니다.

보통 실패하는 경우는 카드에 돈이 없는 경우나, 네트워크 오류로 인한 실패입니다.

다음 글은 구현하는 글을 가지고오겠습니다.

@OneToOne 관계에서 mappedBy 쪽은 fetch.Lazy 적용이 안되는 문제

galong — Mon, 8 Dec 2025 19:36:31 +0900

배경

public class Store extends BaseEntity {
    . 
    .

    @OneToOne(mappedBy = "store", cascade = CascadeType.ALL, orphanRemoval = true, fetch = FetchType.LAZY)
    private ReservationPolicy reservationPolicy;
}

public class ReservationPolicy extends BaseEntity {
    .
    .
    .
    @OneToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "store_id")
    private Store store;
}

Store과 ReservationPolicy는 일대일 양방향 관계이다.

Store entity에서는 mappedBy=”store” 라고 정의함으로서 ReservationPolicy entity에서 store 변수에 연관관계를 맺고자 했다.

이렇게 하면 결과:

store 테이블에는 reservationPolicy_id 컬럼이 없고,

reservationPolicy 테이블에는 store_id가 있다.

문제는 여기서부터다.

Store entity를 조회하는데 1:1 매핑이 되어있었던 ReservationPolicy도 함께 조회가 된다.

private Store findStore(UUID storeId) { // 여기서 store 조회
    return storeRepository.findById(storeId)
        .orElseThrow(() -> new AppException(StoreErrorCode.STORE_NOT_FOUND));
}

fetch.LAZY 를 해줬는데도, store에 수정이 일어나면 그 하위 자식인 reservationPolicy도 조회된다. (hibernate select)

상태변경 controller, service에서 그 어디도 getReservationPolicy() 하는 함수는 없는데 왜 조회가 되는걸까?

원인? : 양방향 @OneToOne 에서 mappedBy 지정한 객체에서 fetch.LAZY 적용안됨

    public class Store extends BaseEntity {
        @OneToOne(mappedBy = "store", cascade = CascadeType.ALL, orphanRemoval = true, fetch = FetchType.LAZY)
        private ReservationPolicy reservationPolicy;

    public class ReservationPolicy extends BaseEntity {
        @OneToOne(fetch = FetchType.LAZY)
        @JoinColumn(name = "store_id")
        private Store store;

결론부터 말하면 @OneToOne 양방향 관계에서 mappedBy 사용한 데에서 fetch.LAZY 적용이 안된다. fetch.EAGER로 매번 하위 자식까지 다 조회를한다.

보통 양방향 OneToOne에서 외래키의 주인이 아닌 상대 entity에 mappedBy 설정을 해줘야한다.

외래키 주인이 아닌 Store entity에서 mappedBy = “store” 를 설정해준 상태이다.

그래서 Store가 수정될 때 ReservationPolicy도 조회가 됐다.

왜 안되는가

Hibernate가 지원하지 않음!!!

이 경고문을 좀 더 빨리 봤다면 삽질의 시간을 줄일 수 있지 않았을까. 엉엉.

@OneToOne 연결에서 소유하지 않는 측에 FetchType.LAZY를 지정하면 로드에 영향을 주지 않습니다. 관련 엔티티는 FetchType.EAGER가 정의된 것처럼 로드됩니다.

@OneToOne 에서 연관관계 주인이 아닌 객체에 mappedBy를 한다.

이 때 mappedBy를 한 객체(Store) 테이블에는 연관관계 주인 (ReservationPolicy) 에 대한 id 컬럼이 없다.

db 관점으로 보았을 때 연관관계 주인이 아닌 Store 테이블에서는 reservationPolicy_id 컬럼이 없어서 storeRepository.findById(storeId) 를 했을 때, Store 테이블만 읽어서 연관관계의 엔티티가 존재하는지 안하는지 확인하기 어렵다.

그래서 확인하기 위해 하위 자식도 조회하는게 아닐까 싶다. (내생각..)

정리

mappedBy의 속성 값은 외래 키의 주인인 상대 Entity의 필드명을 의미한다.
양방향 @OneToOne 에서는 mappedBy 속성을 사용한 객체가 조회될 때, 그 객체와 연관된 객체도 함께 조회된다. (fetch.EAGER)
즉, 양방향 @OneToOne 에서 mappedBy 속성을 사용한 객체에 fetch.LAZY는 적용되지 않는다.

[Spring Boot] 장바구니 기능 Redis( Hash 구조) 사용하여 리팩토링

galong — Mon, 24 Nov 2025 18:00:38 +0900

1차 프로젝트에서 구현했던 장바구니 단순 CRUD에 Redis를 적용해서 빠른 조회가 가능하도록 리팩토링을 진행했습니다. 이 과정을 기록하고자 합니다.

들어가기에 앞서 1차 프로젝트 주제는 음식 주문 관리 플랫폼으로 "배민 서비스"와 비슷하게 동작한다고 생각하면됩니다.

장바구니에는 하나의 가게에 대해서만 메뉴 아이템을 담을 수 있습니다. 이미 다른 가게의 메뉴가 담겨져 있고 새로 추가하려고하는 메뉴가 다른 가게라면 replace true/false 여부로 장바구니의 내용을 변경할 수 있습니다. 그리고, 이미 장바구니에 존재한 메뉴 아이템을 또 담으면 그 만큼 수량을 증가시킵니다.

RedisTemplate Hash 방식으로 장바구니 정보 redis에 저장

장바구니처럼 부분 수정이 빈번하게 일어나는 데이터에는 Hash 방식이 성능상 좋다고 한다.

Redis Hash는 하나의 키 아래에 여러 개의 필드(Field)와 값(Value) 쌍을 저장하는 구조이다. Redis Hash는 내부적으로 해시 테이블로 구현되어 있어, 특정 필드에 접근하거나 갱신하는 연산이 O(1)의 시간 복잡도를 가진다.

만약 String 타입이었다면 : 장바구니 전체 목록을 Redis String 타입에 하나의 거대한 JSON 문자열로 저장했다면, 수량 하나를 변경할 때마다 전체 JSON을 덮어씌워야 한다.
하지만 Hash 타입이라면 : 변경된 아이템 정보만 생성하거나 수정해서 HSET 만 추가하면 된다.

이를 위해, 2개의 정보를 redis에 저장해야한다.

cart:meta
- cart:meta 키는 장바구니 아이템 목록이 저장된 메인키 cart:user:{id}와 쌍을 이루는 보조 키
- 가게 ID, 가게 이름, Cart ID 저장
- String 구조
- 장바구니에 어떤 가게의 메뉴아이템이 담겨져 있는지 알고 있어야 해서 필요한 정보이다.
cart:user
- cart:user 키는 장바구니 아이템 목록
- menu ID, RedisCartItem 객체를 Value로 저장
- Hash 구조

만약 사용자 ID가 1 이고, 장바구니에 아이템이 두 개 있을 때, 예) 짬뽕 2개, 탕수육 1개

Redis Key	Field	Value(Json)
cart:meta:1	String	{"storeId": "s1 ...", "storeName": "중국집 만리장성", "cartId": "c1..."}

Redis Key	Field	Value(Json)
cart:user:1	e705... (짬뽕 ID)	{"menuName": "짬뽕", "unitPrice": 6000, "quantity": 2, ...}
cart:user:1	a3f2... (탕수육 ID)	{"menuName": "탕수육", "unitPrice": 20000, "quantity": 1, ...}

이렇게 저장된다.

수정된 코드

RedisConfig.class

Redis Hash 및 Value 저장을 위한 Spring RedisTemplate 빈
Key와 HashKey는 **StringRedisSerializer**로 설정하여 가독성을 높였고, Value와 HashValue는 GenericJackson2JsonRedisSerializer로 설정하여 자바 객체(DTO)를 JSON 형태로 Redis에 직렬화/역직렬화

@Bean
public RedisTemplate<String, Object> cartHashRedisTemplate(
    RedisConnectionFactory connectionFactory) {
    RedisTemplate<String, Object> template = new RedisTemplate<>();
    template.setConnectionFactory(connectionFactory);

    // Key/HashKey 직렬화 (cart:user:1, uuid)
    template.setKeySerializer(new StringRedisSerializer());
    template.setHashKeySerializer(new StringRedisSerializer());

    // Value/HashValue 직렬화 (RedisCartItem 객체)
    // Hash Value를 Object로 설정하여 RedisCartItem을 저장합니다.
    template.setValueSerializer(new GenericJackson2JsonRedisSerializer());
    template.setHashValueSerializer(new GenericJackson2JsonRedisSerializer());

    template.afterPropertiesSet();
    return template;
}

RedisCartMeta.class

장바구니 전체의 메타 정보 (가게 ID, 가게 이름, Cart DB ID)를 담는 DTO

@Builder
@Setter
@Getter
@NoArgsConstructor
@AllArgsConstructor
public class RedisCartMeta implements Serializable {

    private static final long serialVersionUID = 3L;
    private UUID storeId;
    private String storeName;
    private UUID cartId;

}

RedisCartItem.class

장바구니 내 개별 아이템 정보 (메뉴 ID, 수량, 가격)를 담는 DTO

@Builder
@Setter
@Getter
@NoArgsConstructor
@AllArgsConstructor
public class RedisCartItem implements Serializable {

    private static final long serialVersionUID = 2L;

    private UUID menuItemId;
    private String menuName;
    private BigInteger unitPrice;
    private int quantity;

    public static RedisCartItem fromEntity(CartItem ci) {
        return new RedisCartItem(
            ci.getMenuItem().getId(),
            ci.getMenuItem().getName(),
            ci.getMenuItem().getPrice(),
            ci.getQuantity()
        );
    }
}

RedisKeys.class

Redis 키 패턴 (cart:user:%d, cart:meta:%d)과 TTL 상수를 중앙 관리하는 클래스

public final class RedisKeys {

    public static final long CART_TTL_MINUTES = 30;

    // 키 패턴 정의
    private static final String CART_KEY_FORMAT = "cart:user:%d";
    private static final String CART_META_KEY_FORMAT = "cart:meta:%d";

    private RedisKeys() {
    }

    public static String getCartKey(Long userId) {
        return String.format(CART_KEY_FORMAT, userId);
    }

    public static String getCartMetaKey(Long userId) {
        return String.format(CART_META_KEY_FORMAT, userId);
    }
}

Service에서 CRUD

Read

Read-Through 전략
Redis Hash와 Meta 정보가 모두 있으면 캐시 히트로 응답하고, 하나라도 없으면 DB에서 조회 후 Redis에 다시 저장(Cache Warming)하여 다음 요청에 대비한다.

@Override
@Transactional(readOnly = true)
public CartResponseDto getCart(UserAuth userAuth) {
    Long userId = userAuth.getId();
    String cartKey = RedisKeys.getCartKey(userId);
    String cartMetaKey = RedisKeys.getCartMetaKey(userId);

    // Redis Hash에서 모든 항목 조회 (HGETALL)
    Map<Object, Object> hashEntries = cartHashRedisTemplate.opsForHash().entries(cartKey);

    if (!hashEntries.isEmpty()) {
        // 메타 정보 조회
        RedisCartMeta meta = (RedisCartMeta) cartHashRedisTemplate.opsForValue()
            .get(cartMetaKey);
        log.info("meta: {}", meta);

        // 메타 정보도 있다면 완전한 캐시 히트
        if (meta != null) {
            List<RedisCartItem> redisItems = hashEntries.values().stream()
                .filter(o -> o instanceof RedisCartItem)
                .map(o -> (RedisCartItem) o)
                .collect(Collectors.toList());

            return CartResponseDto.fromRedisItems(meta, redisItems);
        }
    }

    // 캐시 미스 (Cache Miss) 또는 Redis에 데이터가 없을 경우 DB 조회 (Read-Through)
    Cart dbCart = findByUserId(userId);

    //  DB 데이터로 Redis Hash를 채움 (Cache Warming)
    Map<String, RedisCartItem> redisMap = new HashMap<>();
    dbCart.getItems().forEach(ci -> {
        RedisCartItem redisItem = RedisCartItem.fromEntity(ci);
        redisMap.put(ci.getMenuItem().getId().toString(), redisItem);
    });

    if (!redisMap.isEmpty()) {
        cartHashRedisTemplate.opsForHash().putAll(cartKey, redisMap); // 새로 갱신

        //  메타 정보 저장 (누락된 로직 추가)
        RedisCartMeta meta = new RedisCartMeta(dbCart.getStore().getId(),
            dbCart.getStore().getName(),
            dbCart.getId());
        cartHashRedisTemplate.opsForValue().set(cartMetaKey, meta);

        // TTL 설정
        cartHashRedisTemplate.expire(cartKey, RedisKeys.CART_TTL_MINUTES, TimeUnit.MINUTES);
        cartHashRedisTemplate.expire(cartMetaKey, RedisKeys.CART_TTL_MINUTES, TimeUnit.MINUTES);
    }

    return CartResponseDto.from(dbCart);
}

Create

Write-Through 전략
DB에 아이템을 추가/갱신한 후, Redis Hash에 해당 아이템만 HSET으로 갱신하고, 메타 정보도 SET하여 TTL을 연장한다.
replace=true 시에는 DB 저장 전에 기존 Redis 키를 삭제하여 캐시를 초기화한다.

@Override
@Transactional
public CartResponseDto addItem(UserAuth userAuth, AddCartItemRequestDto req, boolean replace) {
    User user = userService.findByUser(userAuth);

    String cartKey = RedisKeys.getCartKey(user.getId());
    String cartMetaKey = RedisKeys.getCartMetaKey(user.getId());

    MenuItem menu = menuItemService.findById(req.getMenuItemId());
    if (menu.getIsSoldout()) {
        throw new MenuItemSoldOutException();
    }
    UUID menuId = menu.getId();

    // 장바구니가 없는 경우 새 생성
    Cart cart = cartRepository.findByUserId(user.getId())
        .orElse(Cart.of(user, menu.getStore()));

    // 장바구니가 있고 다른 가게인 경우
    if (cart.getStore() != null && !cart.getStore().getId().equals(menu.getStore().getId())) {
        if (replace) {
            cart.clear();
            cart.setStore(menu.getStore());

            cartHashRedisTemplate.delete(cartKey);
            cartHashRedisTemplate.delete(cartMetaKey);
        } else {
            throw new CartStoreConflictException();
        }
    }

    // 이미 존재하면 수량 합산, 없으면 새 아이템 추가
    cart.addItem(menu, req.getQuantity());
    Cart savedCart = cartRepository.save(cart);

    // 장바구니 아이템 Entity에서 Redis용 스냅샷 DTO 생성
    CartItem addedItem = savedCart.getItems().stream()
        .filter(ci -> ci.getMenuItem().getId().equals(menuId))
        .findFirst().orElseThrow(CartItemNotFoundException::new);

    RedisCartItem redisItem = RedisCartItem.fromEntity(addedItem);

    // Hash 구조에 해당 필드만 갱신
    cartHashRedisTemplate.opsForHash().put(cartKey, menuId.toString(), redisItem);

    //  메타 정보 저장 (Write-Through)
    RedisCartMeta meta = new RedisCartMeta(savedCart.getStore().getId(),
        savedCart.getStore().getName(),
        savedCart.getId());
    cartHashRedisTemplate.opsForValue().set(cartMetaKey, meta);

    cartHashRedisTemplate.expire(cartKey, RedisKeys.CART_TTL_MINUTES, TimeUnit.MINUTES);
    cartHashRedisTemplate.expire(cartMetaKey, RedisKeys.CART_TTL_MINUTES, TimeUnit.MINUTES);

    return CartResponseDto.from(savedCart);
}

Update

Write-Through 전략
DB에서 수량을 변경 후 저장하고, Redis Hash에서 해당 메뉴 ID의 Field만 HSET으로 덮어쓴다. ⭐️
Redis의 정보를 모두 수정할 필요 없이 해당 메뉴 Field만 수정하는 것이 장점.
매번 TTL을 갱신하여 장바구니 만료 시간을 연장한다.

@Override
@Transactional
public CartResponseDto updateItemQuantity(UserAuth userAuth, UUID menuItemId, int quantity) {
    Long userId = userAuth.getId();
    String cartKey = RedisKeys.getCartKey(userId);
    String cartMetaKey = RedisKeys.getCartMetaKey(userId);

    Cart cart = findByUserId(userId);
    CartItem item = getCartItem(menuItemId, cart);

    if (quantity <= 0) {
        throw new InvalidCartQuantityException();
    }
    item.updateQuantity(quantity);
    Cart saved = cartRepository.save(cart);

    CartItem updatedItem = getCartItem(menuItemId, saved);
    RedisCartItem redisItem = RedisCartItem.fromEntity(updatedItem);

    cartHashRedisTemplate.opsForHash().put(cartKey, menuItemId.toString(), redisItem);

    cartHashRedisTemplate.expire(cartKey, RedisKeys.CART_TTL_MINUTES, TimeUnit.MINUTES);
    cartHashRedisTemplate.expire(cartMetaKey, RedisKeys.CART_TTL_MINUTES, TimeUnit.MINUTES);

    return CartResponseDto.from(saved);
}

Delete

deleteItem()

Write-Through 전략
DB에서 아이템을 삭제하고, 장바구니가 비지 않았다면 Redis Hash에서 해당 메뉴 ID의 Field만 HDEL로 빠르게 제거한다.
TTL도 연장

deleteCart()

Cache Evict 전략
DB에서 Cart 엔티티를 삭제한 후, cart:user와 cart:meta 두 키를 Redis에서 즉시 삭제하여 캐시를 무효화한다.

@Override
@Transactional
public void deleteItem(UserAuth userAuth, UUID menuItemId) {
    Long userId = userAuth.getId();
    String cartKey = RedisKeys.getCartKey(userId);
    String cartMetaKey = RedisKeys.getCartMetaKey(userId);

    Cart cart = findByUserId(userId);
    CartItem item = getCartItem(menuItemId, cart);

    cart.removeItem(item.getId());
    if (cart.getItems().isEmpty()) { // 장바구니에 메뉴가 없으면 장바구니 삭제
        cartRepository.delete(cart);

        cartHashRedisTemplate.delete(cartKey);
        cartHashRedisTemplate.delete(cartMetaKey);
    } else {
        cartRepository.save(cart);

        cartHashRedisTemplate.opsForHash().delete(cartKey, menuItemId.toString());

        cartHashRedisTemplate.expire(cartKey, RedisKeys.CART_TTL_MINUTES, TimeUnit.MINUTES);
        cartHashRedisTemplate.expire(cartMetaKey, RedisKeys.CART_TTL_MINUTES, TimeUnit.MINUTES);
    }
}

@Override
@Transactional
public void deleteCart(UserAuth userAuth) {
    Long userId = userAuth.getId();
    String cartKey = RedisKeys.getCartKey(userId);
    String cartMetaKey = RedisKeys.getCartMetaKey(userId);

    Cart cart = findByUserId(userId);
    cartRepository.delete(cart);

    cartHashRedisTemplate.delete(cartKey);
    cartHashRedisTemplate.delete(cartMetaKey);
}

요청 시간 결과

조회

처음 조회(183ms)

40ms

처음에만 hibernate 하여 db에서 정보를 조회하지만, 이후에는 Redis 캐시에서 계속 값을 가지고 온다.

redis에도 meta정보와 user 정보가 잘 들어간 것을 확인할 수 있다.

트랜잭션 커밋 지연 @TransactionalEventListener로 해결

galong — Sun, 23 Nov 2025 21:59:38 +0900

2차 프로젝트에서 주문 도메인을 맡게 되었습니다. 개발하는 과정에서 마주했던 트러블 슈팅을 해결했던 경험을 기록하고자 합니다.

배경

Order Service에서 주문을 생성하는 과정에서 order 정보를 저장하고, 외부 서비스 Delivery Service에 배송 생성 FeignClient 요청한다. Delivery생성에서는 해당 주문이 실제 있는지 Order Service에 FeignClient 요청하는 상황이다.

Order Service -- feignClient: createDelivery() --> Delivery Service -- feignClient: getOrderDetail() --> Order Service

이런 상황이다. Order Service가 Delivery Service에 의존하고, Delivery Service가 Order Service에 다시 의존하는 양방향 의존성이 발생한다.

발생한 문제

이런 구조에서 Order Service가 방금 저장한 orderId를 전달했음에도 불구하고, Delivery Service의 검증 Not Found 오류 발생하는 문제가 생겼다.

feign.FeignException$NotFound: [404] ... "해당 주문을 찾을 수 없음"

원인

커밋 지연 : Order Service의 트랜잭션이 아직 커밋되지 않아, Delivery Service가 Order Service의 DB를 조회할 때 (Order Service의 getOrder호출 시) Dirty Read를 허용하지 않는다면해당 주문을 찾지 못한 상황이다.

@TransactionalEventListener 로 해결

ApplicationEventPublisher 와 @TransactionalEventListener 를 통해 해결했다.

1. 이벤트 발생 : 주문 생성 완료 후, ApplicationEventPublisher를 통해 OrderCreatedEvent를 발행

2. 실행 분리 : DeliveryNotifier 클래스로 delivery 생성 호출하도록 역할 분리

3. @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT) 을 통해 Order Service의 DB 트랜잭션이 성공적으로 커밋되고 영구 저장된 직후에 OrderCreatedEvent를 리스너하여 배달 생성 로직 실행

이로 인해 Delivery Service 호출 시 Not Found 문제를 해결했다.

이 과정에서 전달되는값이 있는데,

퍼블리쉬 이벤트와 이벤트 리스너 사이에 전달되는 값 : OrderCreatedEvent

기존엔 savedOrder를 전달을 했다. 하지만 리스너를 사용할 땐 따로 객체(OrderCreatedEvent)를 만들어서 사용하는 이유는 뭘까?

트랜잭션 이벤트 리스너를 사용하면서 OrderCreatedEvent 레코드를 따로 만들었다. 이유는 이벤트 리스너는 호출자 트랜잭션이 커밋된 후에 실행된다. 즉 이벤트 리스너가 실행될 때, createOrder메서드 내의 로컬 변수들 (예:savedOrder객체 자체)은 이미 소멸되었거나Spring 세션 관리 영역에서 벗어났을 수 있다. 따라서 OrderCreatedEvent에 필요한 데이터 (ID, Hub Id, Vendor Id 등) 단순한 값을 복사하여 담아두고, 이벤트 리스너가 실행될 때는 이 복사된 값을 사용하여 전달한다.

@Autowired 사용 후 "오토와이어링할 수 없습니다." 오류 해결 방법

galong — Sun, 23 Nov 2025 16:42:19 +0900

테스트코드 작성하는데 @Autowired 어노테이션으로 해당 bean을 가지고 오려고하는데 위와 같이

"오토와이어링할 수 없습니다. 'ProductService' 타입의 bean을 찾을 수 없습니다. " 라는 오류가 떴다.

시도 1 : @Service, @SpringBootTest 어노테이션 잘 썼는지 확인

@Service
@RequiredArgsConstructor
public class ProductService {

Service 파일에 @Service 어노테이션도 잘 붙여줬는데 왜 bean으로 등록이 되지 않았다고 뜨는걸까.

시도 2: gradle clean하고 다시 build

해도 안된다.

시도 3: 폴더 구조가 잘되어 있는지 확인하자

1) ProductService 위치 : com.example.locking 폴더 밑에 있는지 확인

2) 메인 클래스 위치 : @SpringBootApplication이 붙은 메인 클래스가 가장 상위 패키지 (Base Package) 에 위치하는지 확인한다.

...

Item 관련 파일을 item 폴더에 옮겼을 때 LockingApplication도 같이 옮겼나 보다 ..

현재 메인 클래스가 com.example.locking.item과 같은 하위 패키지에 들어가 있어, 상위 패키지인 com.example.locking의 다른 Bean들(예: ProductService)을 찾지 못하고 Bean 누락 오류가 발생한 것이다.

LockingApplication을 locking 폴더 밑으로 리팩토링했더니 해결됐다!