Dean83

[Spring Security] XSS 방어

Dean83 — Wed, 11 Feb 2026 14:32:58 +0900

XSS 방어는 사용자가 신뢰하는 웹사이트 내에서 악의적인 스크립트가 실행되지 않도록 막는 보안 전략이다. (JS 포함 HTML 등도 해당)

서버에서 설정 할 수 있는 항목은 크게 두가지로 생각해 볼 수 있다. (보통은 서버에서 html을 내려줄 일이 없으므로)

CSP (Content Security Policy) 설정
- 이 출처에서 온 리소스만 사용할 수 있도록 하는 설정
쿠키 이용시, HttpOnly, Secure 설정

CSP 설정 예

httpSecurity의 header 에 추가하는 설정
스크립트, 이미지 등의 출처를 명시해 두어, 해당 출처로 부터 온 데이터들만 사용 할 수 있도록 한다.
공백이 매우 중요하다. 하나의 설정이 끝나는 지점에 ; 를 적어두고 공백을 하나 띄워야 한다.
연속된 설정의 경우 다음 항목에 공백을 두어야 하고, 값 배정에도 공백을 두어야 한다.
- 예 : connect-src 공백 'self' 공백 https: 공백 wss:; 공백
여기서 self 의 의미는 프론트엔드가 서빙되고 있는 주소를 의미한다.

@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
    ....
    
    http.sessionManagement(management ->
                    management.sessionCreationPolicy(SessionCreationPolicy.STATELESS))
            .headers(header -> header
                    .contentSecurityPolicy(csp -> csp
                            .policyDirectives(
                                    "default-src 'self'; " +
                                            "script-src 'self'; " +
                                            "script-src-attr 'none'; " +
                                            "script-src-elem 'self'; " +
                                            "object-src 'none'; " +
                                            "base-uri 'none'; " +
                                            "img-src 'self' data: https://*.ap-northeast-2.amazonaws.com; " +
                                            "form-action 'self' https://백앤드주소; "  +
                                            "connect-src 'self' https:백앤드주소 and 허용하는_서버_주소 나열 wss:; "+
                                            "frame-ancestors 'none'"
                            ))

default-src ‘self’;
- 기본정책으로, 따로 명시되지 않은 리소스는 같은 origin만 허용한다.
script-src ‘self’;
- 같은 서버의 javascript만 실행
script-src-attr ‘none’;
- 스크립트 내 인라인 이벤트 스크립트 차단 (예 : 버튼 클릭 이벤트)
script-src-elem ‘self’;
- <script src="">로 불러오는 JS 제한.
object-src ‘none’;
- Flash, plugin, object 태그 차단
- 거의 필수
base-uri ‘none’;
- <base href="주소"> 같은 경로 조작 차단
img-src ‘self’ data: S3도메인
- 이미지 파일은 나와 같은 도메인 혹은 S3에 있는 도메인만 허용
form-action ‘self’;
- 다른 사이트로 Form을 제출 할 수 없도록 제한
- https://백앤드주소 를 추가하여 OAuth가 리다이렉트 하는 경로를 추가할 수 있다 (폼로그인 OAuth는 거의 없음)
connect-src ‘self’ https: wss:;
- fetch, axios, WebSocket, SSE 허용 출처 설정
- https:, wss: 는 모든 연결을 허용
- 만일 특정 주소로 제한하고 싶다면, https://백앤드주소 https://외부api서버주소 등 연장하여 설정해야 한다.
  - wss://백앤드주소 이것도 마찬가지.
frame-ancestors ‘none’;
- 다른 사이트에서 내 사이트에 iframe 넣는것을 차단하여 클릭재킹 방어

[Entity] GeneratedValue 대신 TSID 사용하기

Dean83 — Tue, 10 Feb 2026 15:28:45 +0900

보통 Entity를 구성할 때 id 필드 값에 아래의 어노테이션을 사용할 때가 많다.

@GeneratedValue(strategy = GenerationType.IDENTITY)

이 경우, DB의 DDL 에도 아래와 구성을 해 주어야 한다.

id                BIGINT GENERATED BY DEFAULT AS IDENTITY

의미 부터 보자면, db에 값을 저장할때 id 값을 db 에서 자동으로 생성하여 증가 해주는것을 의미한다. (JPA에서 해주지 않는다)

이 경우 다음의 문제점이 발생한다.

대량의 bulk insert가 필요 할 때 bulk 동작을 JPA 및 hibernate가 수행하지 않고, 건별로 insert 쿼리를 날린다.
- 속도가 엄청나게 느리고 과부하가 걸린다.
- 데이터 1개를 입력 -> 증가된 ID 값을 받아옴 -> 다음 데이터 입력 을 해야 하므로 bulk insert가 수행되지 않는다.

따라서, @TSID 어노테이션 을 이용하여 프로그램 단에서 자동으로 ID를 생성해 주도록 한다.

이를 이용하려면 다음을 따라야 한다.

DDL 에서 GENERATED BY DEFAULT AS IDENTYTY 항목 삭제
Entity의 id 컬럼에서 @GeneratedValue 대신 @Tsid 어노테이션 이용
id 는 bigint (Long) 형으로 구성

build.gradle 에 추가

버전은 확인 필요 (작성 현 시점 기준 버전임)

  implementation 'io.hypersistence:hypersistence-utils-hibernate-63:3.15.1'

@Tsid 어노테이션 사용

엔티티의 ID 컬럼에 기존 @GeneratedValue(strategy=GenerationType.IDENTYTY) 대신 @Tsid 어노테이션 사용

	.....
    @Id
    @Tsid
    @Column(name = "id", nullable = false)
    protected Long id;
    
    .....

TSID 특징

Bigint (Long) 형 이다.
시간정보 + 랜덤값 을 이용하여 아이디를 생성한다.
시간순 정렬이 가능 하다

개발 단계라 실제 데이터가 없다면, 기존 데이터 삭제 -> 테이블 수정을 통해 Tsid를 사용할 수 있다.

그러나 만일 실제 데이터가 있는 상황이라면, 무턱대고 변경 할 수가 없다.

이를 해결하기 위해선 다양한 방법이 있겠으나, 나라면 bulk insert가 필요한 항목에 한해

Raw SQL을 통해 Bulk insert 를 수동으로 구현하여 운영 (기존 id 자동 생성 유지) 을 할 것 같다.

그러다 점차 해당 항목들이 많아 진다면, 그때는 Tsid를 도입하고, 기존 데이터는 점진적으로 새 테이블로 마이그레이션 수행을 할 것 같다.

따라서 처음부터 id 자동 생성 보다는 어플리케이션 에서 생성해 주는것이 좋다고 생각한다.

OAuth 연동

Dean83 — Fri, 6 Feb 2026 11:46:21 +0900

모바일일 경우에는 OAuth 연동을 모바일쪽에서 직접 구현 -> 해당 정보를 백앤드로 전달 해주었다. 웹페이지의 경우에도 그렇게 할 수 있으나 클라이언트 측에 키값이 존재한다는 점이 불안 요소가 있다. (물론 이를 보완할 수도 있다. 키값만 db에 저장한다든지, 서버가 전달 해준다든지 등등)

서버에서 OAuth를 연동할 경우 장점은,

키값 안전하게 보호
각기 다른 플랫폼에 OAuth 연동해도 연동이 일괄적으로 간편
- 이부분은 클라이언트 쪽에선 진짜...하나 추가될 때 마다 괴로웠음
- 스프링부트에서는 설정만 추가하고 필요하면 코드만 살짝 바꾸면 된다.

일단, 구글 기준으로 스프링부트에서 연동하는 내용을 정리해 둔다.

우선순위 부터 보자면

각 플랫폼의 dev 사이트에서 프로젝트 생성
프로젝트에서 OAuth 연동을 위한 콜백 Uri 지정
builld.gradle 에 라이브러리 추가
발급된 클라이언트ID, 비밀번호를 스프링부트의 환경변수에 삽입 및 application.yaml 설정
SecurityConfig 설정
연동 Service 코드 구현
JWT 연동하여 토큰 발급 후 프론트엔드에 전달

각 플랫폼의 dev 혹은 console 사이트에서 프로젝트 생성

이 부분 설정법은 금방 쉽게 찾을 수 있기 때문에 설정을 해주어야 한다는 사실만 기억하면 되고 여기선 다루지 않는다.

다만 아래 2가지는 기억하는게 좋다.

프로젝트에서 클라이언트 생성시, 웹 애플리케이션으로 생성할 것
웹 애플리케이션에서 승인된 리디렉션 URI에 주소값을 넣을것
- 구글 예 : 개발중일경우 : http://localhost:8080/login/oauth2/code/google
  - /login/oauth2/code/google 이게 항상 일치해야 한다.

Build.gradle 추가

Oauth2 를 위한 라이브러리가 있다.
각 플랫폼에 요청을 위한 uri가 security에 고정되어 있다.
- 구글 : http://localhost:8080/oauth2/authorization/google

implementation 'org.springframework.boot:spring-boot-starter-oauth2-client'

application.yaml 수정

Spring Security의 oauth2 항목을 설정해주면 된다.
다른 플랫폼과 연동시 단순히 registration, provider 쪽에 항목을 추가해주면 된다.
구글의 경우 provider 부분은 필수는 아니고 선택사항이다. 그러나 kakao 같은 경운 필수로 넣어야 한다.
provider 에 있는 각 주소들은 해당 플랫폼에서 제공하는 주소이니, 값의 변화가 없다.
scope 하단에 서버가 가져올 정보를 명시한다. 각 제공처 마다 다르니 주의할것.
- 구글의 경우 profile 을 추가 하면 이름을 가져 올 수 있다.
- 이를 가져오기 위해선 구글 콘솔 -> OAuth 에서 해당 정보를 가져오겠다는 것을 설정을 통해 해 주어야 한다.

server:
  forward-headers-strategy: framework

spring:
  security:
    oauth2:
      client:
        registration:
          google:
            client-id: ${GOOGLE_CLIENT_ID}
            client-secret: ${GOOGLE_SECRET}
            scope:
              - email
              - profile
        provider:
          google:
            authorization-uri: https://accounts.google.com/o/oauth2/v2/auth
            token-uri: https://oauth2.googleapis.com/token
            user-info-uri: https://www.googleapis.com/oauth2/v3/userinfo
            user-name-attribute: sub

server.forward-headers-strategy : framework
- OAuth 로그인시 각 OAuth 제공처 (예 : 구글 콘솔) 에서 설정한 Redirect Url 관련된 설정
- AWS에 서버를 올리고, 앞단에 nginx가 있을 경우, redirect url 이 원본 요청이 아니라 다른 url로 변경됨
  - 예 : appserver/api/xxx/xxx
- 이를 방지 하기 위한 설정으로, 물론 nginx 에도 설정을 따로 해주어야 함.
- Nginx, ALB등 백앤드가 뒤에 있을때, 변경된 주소가 아닌 클라이언트가 보낸 원래 요청 주소를 복원하는 설정임.

OAuthService 구현

OAuth2UserService 를 implement 하여 구현한다.
이메일이 없을경우 처리는 비즈니스 로직 부분이다.
필요하다면 profile 등 을 통해 이름을 가져올 수도 있다. (application.yaml 설정 및 각 서비스 도메인 설정 필요)

@Service
@RequiredArgsConstructor
public class OAuthService implements OAuth2UserService<OAuth2UserRequest, OAuth2User> {
    @Override
    public OAuth2User loadUser(OAuth2UserRequest userRequest) throws OAuth2AuthenticationException {
        OAuth2UserService<OAuth2UserRequest, OAuth2User> oAuth2UserService = new DefaultOAuth2UserService();
        OAuth2User oAuth2User = oAuth2UserService.loadUser(userRequest);
        Map<String,Object> attributes = oAuth2User.getAttributes();

        String email = (String) attributes.get("email");

        ....//비즈니스 로직 구현 부분

        return new DefaultOAuth2User(
                Set.of(new SimpleGrantedAuthority("ROLE_USER")),
                attributes,
                "sub"
        );
    }
}

SecurityConfig 설정 추가

oauth2Login 설정만 해주면 된다.
userService 에 위에 설정한 서비스를 넣어준다.
따로 csrf 설정이나 authorizeHttpRequests.requestMatchers 설정을 하지 않아도, Spring Security에서 별도로 다른 filter를 태운다
로그인 성공, 실패 콜백을 등록하여, 로그인 성공시 JWT 토큰 발급 등을 할 수 있도록 할 필요가 있다.

	....
    private final OAuthService oAuthService;
    private final OAuthSuccessHandler oAuthSuccessHandler;
    private final OAuthFailureHandler oAuthFailureHandler;
    ...

	@Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
    
                http.oauth2Login(oauth -> oauth.userInfoEndpoint(
                        info -> info.userService(oAuthService)                                              
                        .successHandler(oAuthSuccessHandler)
                        .failureHandler(jwtLoginFailureHandler)
                ))

				....

로그인 성공, 실패 핸들러

성공 핸들러 예만 첨부한다.
요점은, 토큰 발급 후 프론트엔드 에서 원하는 주소로 re-direct 해주어야 한다는 점이다. (실패시 에도 마찬가지)
redirect 할 때 토큰을 바로 노출하는건 좋지 않고, 쿠키에 넣어 전달 -> 클라이언트가 쿠키에서 가져와 처리 하는게 좋다 (프론트와 협의 필요)

@Component
@RequiredArgsConstructor
public class OAuth2SuccessHandler
        implements AuthenticationSuccessHandler {

    private final JwtProvider jwtProvider;

    public void onAuthenticationSuccess(HttpServletRequest request, 
    HttpServletResponse response, 
    Authentication authentication) throws IOException, ServletException {

        String token = jwtProvider.createToken(authentication);

        response.sendRedirect(
            "http://frontend.com/login?token=" + token
        );
    }
}

접근 테스트 (구글)

http://localhost:8080/login/oauth2/code/google 주소를 통해 브라우저로 접속하여 테스트 한다. (개발환경)
프론트엔드 페이지가 이미 구현완료 되었다면 프론트엔드를 통해 완료한다.

Cursor 기반 Paging 추가 정리(QueryDsl 기준)

Dean83 — Tue, 3 Feb 2026 16:11:04 +0900

https://dean83.tistory.com/285 여기에서 Paging 에 대한걸 간략하게 정리 하였다. 그러나 실제로는 Cursor 기반을 많이 사용하기도 하고, 좀 더 까다롭기도 하다. 이 부분 또한 위의 페이지에 정리 하려 하다가 너무 복잡해져 따로 정리한다.

예는 유저를 pageing 하는 예 이다.

중요한 내용 정리 먼저,

엔티티에 1:N, N:M 등 List 형태의 컬럼이 있을경우 해당 테이블과 fetch join을 하면 안된다.
- fetch join으로 인해 row의 갯수가 증가해 버린다 -> limit에 의해 의도치 않은 데이터 갯수가 생성된다.
- 예 ) 유저 조회가 메인인 경우, 유저에 roles 라는 List 컬럼이 있을경우
  - 동일 유저인데 role이 다를 경우 row 갯수 증가 -> 그러나 페이지네이션에선 동일한 유저이므로 limit보다 적은 유저 리턴
  - distinct를 걸어도 row 자체는 중복이 아니기 때문에 소용 없음.
- 이후 별도로 ids를 통해 fetch join을 수행해야 한다.
Cursor은 정렬 조건과 동일한 필드를 사용한다.
- 만일 정렬 조건 필드가 name, email 등 여러개 일 경우, cursor 또한 각 조건과 부합한다.
- 즉, 클라이언트에서 정렬조건으로 name을 주었다면, cursor 또한 클라이언트에서 name 값을 준다.
Distinct를 사용하지 않는다

Service에서 호출하는 Repository 메서드 예 (메인 진입점)

public List<User> findAllUsers(UserCursorRequest request) {

        return findUserExpression(true)
                .where(
                        getEmailExpression(request),
                        getRoleExpression(request),
                        getLockedExpression(request),
                        cursorExpression(request)
                )
                .orderBy(orderByDirection(request), orderByDirection(request.sortDirection(), user.uuid))
                .limit(request.limit()+1)
                .fetch();
    }

Where 조건문을 완성해 주는 메서드를 호출하여 사용한다.
- 각 조건문이 null 일 경우에도 NPE 터지지 않고 처리해 줘서 상관없다.
orderby 조건문을 완성해주는 메서드를 호출하여 사용한다. 또한 id를 보조 커서로 사용한다.
limit 은 +1을 하여 nextCursor 정보 등을 담을 수 있도록 한다.
Slice가 아니라 List로 리턴하고, Service에서 Dto를 생성하여 컨트롤러로 리턴한다.
예에서는 일반쿼리(fetch join필요), Slice쿼리 두 경우가 다 있다보니 따로 Select 쿼리를 메소드로 분리하였다.

Repository의 Select 부분 예

private JPAQuery<User> findUserExpression(boolean isSlice)
    {
        JPAQuery<User> query = jpaQueryFactory
                                .select(user)
                                .from(user);

        //list 인 경우, slice 할때에는 fetch join을 쓰면 안된다. (limit 등 쿼리 select 오동작)
        if(isSlice)
        {
            query.join(user.userRoles, userRole);
            query.join(user.profile,profile);
            query.join(userRole.role,role);
        }
        else
        {
            query.join(user.userRoles, userRole).fetchJoin();
            query.join(user.profile,profile).fetchJoin();
            query.join(userRole.role,role).fetchJoin();
            query.distinct();
        }

        return  query;
    }

만일 Repository 에서 일반 select와 Paging을 둘 다 쓰고 있을경우, 그리고 엔티티에 1:N 관계의 List 멤버변수가 있을경우 fetch join을 하지 않기 위해 위와 같이 메서드로 따로 분리해 주었다.

일반적인 Where 조건절 예

   private BooleanExpression getEmailExpression(UserCursorRequest request)
    {
        return StringUtils.hasText(request.emailLike()) ? user.email.like(request.emailLike()) : null;
    }

BooleanExpression을 리턴한다.
null이 아닌경우 조건에 맞는 문장리턴, null일 경우 null을 리턴한다.

Cursor Where 조건절 예

private BooleanExpression cursorExpression(UserCursorRequest request) {
        if (request.cursor() == null || request.idAfter() == null) {
            return null; // 최초 페이지 → 커서 조건 없음
        }

        if(request.sortDirection() == UserSortDirection.ASCENDING)
            return cursorExpressionAsc(request);

        return cursorExpressionDesc(request);
    }

    private BooleanExpression cursorExpressionDesc(UserCursorRequest request)
    {
        switch (request.sortBy())
        {
            case name:
                return profile.name.lt(request.cursor())
                        .or(
                                profile.name.eq(request.cursor())
                                        .and(user.uuid.lt(request.idAfter()))
                        );
            case email:
                return user.email.lt(request.cursor()).
                        or(
                                user.email.eq(request.cursor())
                                        .and(user.uuid.lt(request.idAfter())
                        ));
            case role:
            case isLocked:
                return user.uuid.lt(request.idAfter());
            case createdAt:
                Instant cursorTime = Instant.parse(request.cursor());
                return user.createdAt.lt(cursorTime)
                        .or(
                                user.createdAt.eq(cursorTime)
                                        .and(user.uuid.lt(request.idAfter())
                        ));
            default:
                return null;
        }
    }

    private BooleanExpression cursorExpressionAsc(UserCursorRequest request)
    {
        switch (request.sortBy())
        {
            case name:
                return profile.name.gt(request.cursor())
                        .or(
                                profile.name.eq(request.cursor())
                                        .and(user.uuid.gt(request.idAfter()))
                        );
            case email:
                return user.email.gt(request.cursor()).
                        or(
                                user.email.eq(request.cursor())
                                        .and(user.uuid.gt(request.idAfter())
                                        ));
            case role:
            case isLocked:
                return user.uuid.gt(request.idAfter());
            case createdAt:
                Instant cursorTime = Instant.parse(request.cursor());
                return user.createdAt.gt(cursorTime)
                        .or(
                                user.createdAt.eq(cursorTime)
                                        .and(user.uuid.gt(request.idAfter())
                                        ));
            default:
                return null;
        }
    }

정렬 조건이 Desc 이냐, Asc 이냐에 따라 검색 조건이 달라진다. (값이 커야 하는지 작아야 하는지 조건이 달라지기 때문)
또한 정렬 조건이 여러개 일 경우, Cursor 또한 여러 조건값이 될 수 있기 때문에 이를 고려해야 한다.
Cursor 비교값과 결과가 동일할 경우가 있을 수 있기 때문에 후행에 or 절을 이용하여 보조커서(보통 ID)를 이용해 조건을 걸어준다.
최초 검색 조건에는 Cursor 등이 없으므로 예외처리를 해주어야 한다.

OrderBy 예

private OrderSpecifier orderByDirection(UserCursorRequest request)
    {
        switch (request.sortBy())
        {
            case name:
                return orderByDirection(request.sortDirection(), profile.name);
            case email:
                return orderByDirection(request.sortDirection(), user.email);
            case role:
                return orderByDirection(request.sortDirection(), role.name);
            case isLocked:
                return orderByDirection(request.sortDirection(), user.locked);
            case createdAt:
                return orderByDirection(request.sortDirection(), user.createdAt);
            default:
                return null;
        }
    }

    private OrderSpecifier orderByDirection(UserSortDirection direction, ComparableExpressionBase field)
    {
        if(direction == UserSortDirection.ASCENDING)
            return field.asc();

        return field.desc();
    }

OrderSpecifier를 리턴한다.
어떤 필드든 정렬 조건을 리턴하는 메소드를 이용한다. (정렬 조건이 여러개 올 수 있기 때문에 각 이 메소드를 호출한다)

Service 예

@Transactional(readOnly = true)
    public CursorResponseUserDto getAllUsers(UserCursorRequest request)
    {
        //QueryDsl 메서드 호출
        List<User> users = userRepository.findAllUsers(request);
        boolean hasNext = false;
        String nextCursor = null;
        UUID idAfter = null;
        //JpaRepository 기본 메서드 count 호출
        Long totalCount = userRepository.count();
        
         if(users.size() > request.limit())
        {
            hasNext = true;
            users.remove(users.size() - 1);
            idAfter = users.get(users.size() - 1).getUuid();
            nextCursor = getNextCursor(request, users);
        }
        return CursorResponseUserDto.builder()
                .data(orderedUsers.stream()
                        .map(x -> UserDto.builder()
                                .user(x)
                                .build()).toList())
                .hasNext(hasNext)
                .nextCursor(nextCursor)
                .nextIdAfter(idAfter)
                .totalCount(totalCount)
                .sortDirection(request.sortDirection().name())
                .sortBy(request.sortBy().name())
                .build();

    }

    private String getNextCursor(UserCursorRequest request, List<User> users)
    {
        switch (request.sortBy())
        {
            case name:
                return users.get(users.size() - 1).getProfile().getName();
            case email:
                return users.get(users.size() - 1).getEmail();
            case role:
                return users.get(users.size() - 1).getUserRoles().get(0).getRole().getName().name();
            case isLocked:
                return users.get(users.size() - 1).getLocked().toString();
            case createdAt:
                return users.get(users.size() - 1).getCreatedAt().toString();
            default:
                return null;
        }
    }

Slice를 이용하지 않고 따로 Dto를 통해 결과를 리턴한다.
Repository 조회 수가 limit 보다 적을경우 next 는 없다고 간주하여 처리한다.
Cursor의 경우 정렬조건이 여러개 일 수 있으므로 이에 각각 해당하는 값을 넣어준다.

Fetch Join을 위한 처리

일반적인 Paging 에선 Fetch join을 하면 안된다. 따라서 이후 fetch join을 통해 데이터를 한번 더 가져와야 한다. (N+1 방지)
결국 Entity에서 List 형태로 멤버변수를 갖고 있다면 2번의 쿼리를 하게 되는 셈이다.

Repositoty 예

    //N+1 을 해결하기 위한 페이지네이션 후속 쿼리
    @Override
    public List<User> findUsersByIds(List<UUID> ids) {
        return findUserExpression(false)
                .where(user.uuid.in(ids))
                .fetch();
    }

ids를 통해 in 을 이용하여 모든 항목을 fetch join 하여 가져온다.

Service 예 (Fetch Join 예)

@Transactional(readOnly = true)
    public CursorResponseUserDto getAllUsers(UserCursorRequest request)
    {
        //QueryDsl 메서드 호출
       ...

        //userroles n+1 해결을 위해 fetch join을 해오기 위한 부분
        List<UUID> ids = users.stream().map(User::getUuid).toList();
        if(ids.isEmpty())
            return new CursorResponseUserDto(
                    null,
                    nextCursor,
                    idAfter,
                    hasNext,
                    totalCount,
                    request.sortBy().name(),
                    request.sortDirection().name());

        //fetch join 후 정렬이 깨짐
        List<User> fetchedUsers = userRepository.findUsersByIds(ids);

        //uuid를 key로 하는 userMap을 생성 -> 정렬된 리스트를 재구성할떄 사용
        Map<UUID, User> userMap = fetchedUsers.stream()
                .collect(Collectors.toMap(User::getUuid, u -> u));

        //ids 는 paging 조건에 맞는 정렬형태. userMap에서 가져와 기존 정렬된 형태로 복구
        List<User> orderedUsers = ids.stream().map(userMap::get).toList();

       ...

    }

1차로 Repository에서 Paging된 데이터를 조회한다.
이 List 에서 id 값만 따로 추출한다.
추출한 id값들을 인자로 하여 fetch join을 진행하는 repository 메서드를 호출한다.
fetch join된 결과는 정렬되지 않으므로, 기존 id List 순서 기준으로 값을 재배치 하여 원본 순서를 맞춘다.
이를 이용해 controller에 리턴한다.

임시 비번 발급 후 비교할때 주의점(PasswordEncoder)

Dean83 — Mon, 2 Feb 2026 14:14:19 +0900

실제 회원가입 등 비밀번호 저장을 DB에 할 때에는 PasswordEncoder 의 encode 메서드를 이용해서 저장만 하지, 실제 비교할 일은 거의 없었다. 보통은 이미 구현이 되어 있는 DaoAuthenticationProvider 에서 인증을 해주기 때문이다.

임시번호 발급시 다양한 방법으로 확인 및 구현이 가능하겠으나, 현재 나의 경우는 DaoAuthenticationProvider 을 상속받아 구현하는 구현체를 만들어서 이곳에서 비교를 해야 하는 상황이다.

(만일 아이디 / 비번이 아닐경우 다른 Provider를 사용할 수 있고, 이 경우, AuthenticationManager 구현체를 디버깅 걸어서 확인필요)

알맞게 임시 비밀번호를 발급하고 입력했음에도 계속하여 로그인 실패가 나서 그 이유를 찾아보니, 다음과 같았다.

PasswordEncoder 를 이용해 암호화 할 때 마다 값이 바뀐다. (BCryptEncoder)
PasswordEncoder 를 통해 matches 메서드를 이용해 사용자 입력값과 암호화된 비밀번호를 매칭한다.
- 여기서 인자값 순서가 중요하다. 1번째 인자값이 사용자 입력값 (암호화 안된 순수 텍스트)
- 2번째 인자값이 암호화된 비밀번호 이다.

이거 순서가 중요한거 모르고 계속 헤맸어서 기록용으로 남겨둔다.

참고로, DaoAuthentication 을 상속받아 구현한 예는 아래와 같다.

public class CustomDaoAuthenticationProvider extends DaoAuthenticationProvider {
    @Override
    protected void additionalAuthenticationChecks(UserDetails userDetails,
                                                  UsernamePasswordAuthenticationToken authentication) throws AuthenticationException {

        String normalPassword = authentication.getCredentials().toString();
        CustomUserDetails customUserDetails = (CustomUserDetails) userDetails;
        boolean normalPasswordMatches = getPasswordEncoder().matches(normalPassword, customUserDetails.getPassword());
        if(normalPasswordMatches == false) {
            Instant temporaryPasswordCreatedAt = customUserDetails.getTemporaryPasswordCreatedAt();
            String temporaryPassword = customUserDetails.getTemporaryPassword();

            if(temporaryPasswordCreatedAt == null
                    || StringUtils.hasText(temporaryPassword) == false
                    || Instant.now().minus(3, ChronoUnit.MINUTES).isAfter(temporaryPasswordCreatedAt)) {
                throw new BadCredentialsException("Bad credentials");
            }

            boolean tempPasswordMatches = getPasswordEncoder().matches(normalPassword,
                    temporaryPassword);

            if(tempPasswordMatches == false) {
                throw new BadCredentialsException("Bad credentials");
            }
        }
    }
}

Hexagonal Architecture 일부적용 및 느낀점

Dean83 — Fri, 30 Jan 2026 15:21:59 +0900

스프링부트를 하면서, Hexagonal Architecture 에 대한 고민을 했던 기억이 있어 내용을 정리해 둔다.

고민시점

도메인 위주로 패키지를 나누어 둠 (혹시 모를, 추후 MSA 전환을 대비)
도메인 A 에서 도메인 B의 Service나 Repository를 주입받아 이용하는곳이 있었음.
이 연관관계를 깨고 싶었음.

이 시점에 고민을 했었고, 실제 완전한 Hexagonal 은 아니어도, 어느정도 의미있게 분리를 했다고 생각한다.

서버 이벤트 방식 고민

자료를 리턴받는 콜백 개념이 필요했으므로, fire-forget인 이벤트와는 맞지않다고 생각했다.
충분히 큰 규모였다면 kafka 나 MQ 처럼 외부 서비스를 구성해 볼수도 있겠지만, 현재는 시작단계여서 오버스펙이었다.
또한 백앤드는 클라이언트와 다르게 수많은 클라이언트를 대상으로 하기도 하고, 역할 분리 등이 엄격하다고 느꼈다.
그러나 사실 서버 이벤트 방식도 고민을 했었고, 충분히 적용해볼 만 하다고도 생각된다.
대략적으로 구상한 방법은,
- 도메인 A 에서 "나 이 자료 필요해" 라고 이벤트 발생
- 도메인 B 에서 해당 이벤트 수신 후 DB 조회 등 작업 수행
- 도메인 B 에서 "자료 여기있어" 라고 이벤트 발생
- 도메인 A 에서 이 이벤트를 수신하여 실제 비즈니스 로직 수행
실제 이 방식은 C#을 이용했을때 많이들 사용했던 방식이고, 사실 delegate를 이용하여 조금 모습이 다르긴 하다만, 충분히 반영해봐도 좋다고 생각한다.

다시 돌아와서, 내가 적용했던 Hexagonal 내용을 정리하자면,

도메인 A에서만 사용할 Dto 생성
Port 인터페이스 생성
Adapter 클래스 생성

이 정도로만 구성을 끝냈다. 원래대로라면 좀 더 복잡하지만, 어짜피 Springboot 라는 조건하에 굳이 순수 Java 코딩을 해야 하는 부분들은 필요 없다고 생각 했다.

실제 각각 어떤것을 적용했냐 하면,

Dto 생성

도메인 A에서만 사용할 Dto로, 외부 데이터를 이용하여 구성한다.
이를 통해 도메인 A 에서는 외부 자료형 등에 영향을 받지 않고, 내부 도메인 Dto만 바라볼 수 있어 결합도가 낮아진다.

Port 인터페이스 생성

외부 통신을 정의한 인터페이스로, 위에서 정의한 Dto를 리턴하는 메서드를 정의만 해 둔다.

Adapter 클래스 생성

사실상 핵심이라고 볼 수 있다. Port를 구현한 클래스로, 실제 외부 통신을 수행하게 된다.
역할은, 비즈니스 로직을 제외하고 순수 외부 통신 -> Dto로 데이터를 변환하여 리턴만 한다.
외부 통신 및 외부에서 쓰는 자료형을 리턴받기 때문에 더러워 질 수 밖에 없다.
그러나 외부의 영향을 받는 모든것들을 이곳에 모아둠으로서, 도메인 A에 있는 다른 모든 항목들은 영향을 받지 않고 분리된다.
여기서 B 도메인의 Service를 주입받아, 메소드 호출 및 리턴 자료형을 도메인 A에 사용하는 Dto로 변환 하였다.
도메인 A 에 있는 Service에서 이 Adapter를 주입받아 호출하여 사용한다.

물론 도입 과정에서 Dto가 중복되는 점 (클래스는 다르나 내용은 같은점) 등 많은 고민이 있었으나 나름 좋은 경험이었다고 생각된다.

Application.yaml 값 불러오기 (Class에 매핑)

Dean83 — Thu, 29 Jan 2026 15:57:02 +0900

어딘가에 기록을 해 둔거 같은데...찾을수가 없어서 다시 기록해 둔다.

다양한 방법으로 yaml 에 있는 값을 불러올 수 있으나, 여기서는 Class 혹은 Record에 매칭 하는 방법을 기준으로 정리해둔다.

application.yaml에 다음과 같이 정의되어 있다면,

...
jwt:
  secret: ${JWT_SECRET_KEY}
  access_key_expiration: 600000
  refresh_key_expiration: 1209600000
  issuer: "test-server"
...

아래와 같이 클래스 및 맴버변수로 매핑할 수 있다.

@Getter
@Setter
@Configuration
@ConfigurationProperties(prefix = "jwt")
public class JwtProperties {
    private String issuer;
    private Long accessKeyExpiration;
    private Long refreshKeyExpiration;
    private String secret;
}

이렇게 별도로 클래스로 떼어 매핑하는 이유는, 역할 분리를 하기 위함이다.
record로 매핑할 경우 불변이 되므로 좀 더 좋은 매핑이 될것으로 생각된다.

Cache, RefreshToken 용 Redis를 쓸 경우.

Dean83 — Thu, 29 Jan 2026 14:46:34 +0900

Redis를 통해 Cache와 RefreshToken을 둘다 관리하는 경우, 설정이 헷갈릴 수 있어 정리해 둔다.

일단 요약하자면,

1개의 Redis를 띄워 각각 cache, token용으로 나누어 운용 가능
단, database를 나누어야 함.
- 예 : 0번은 cache용, 1번은 token용
- 기본적으로 0 ~ 15까지 제공
application.yaml 설정을 통해 둘중 하나의 config는 자동으로, 하나의 config는 수동으로 설정해야 함.
- 둘중 무얼 수동으로 설정할 지는 자유이다.
- 수동으로 설정할때 주의점은, bean 이름을 반드시 명시해야 한다는 점이다.
- 기본 bean 으로 사용할 경우 application.yaml의 설정을 덮어 쓴다
- RefreshToken 용 config 수동 설정 예


@Configuration
@RequiredArgsConstructor
public class TokenRedisConfig {

    private final RedisProperties redisProperties;

    @Bean(name = "refreshTokenRedisConnectionFactory")
    public RedisConnectionFactory redisConnectionFactory() {
        RedisStandaloneConfiguration config =
                new RedisStandaloneConfiguration(
                        redisProperties.getHost()
                        , redisProperties.getPort());

        config.setDatabase(1);

        GenericObjectPoolConfig<StatefulConnection<?, ?>> poolConfig = new GenericObjectPoolConfig<>();
        poolConfig.setMaxTotal(redisProperties.getLettuce().getPool().getMaxActive());
        poolConfig.setMaxIdle(redisProperties.getLettuce().getPool().getMaxIdle());
        poolConfig.setMinIdle(redisProperties.getLettuce().getPool().getMinIdle());
        poolConfig.setMaxWait(redisProperties.getLettuce().getPool().getMaxWait());

        LettucePoolingClientConfiguration clientConfig = LettucePoolingClientConfiguration.builder()
                .poolConfig(poolConfig)
                .commandTimeout(redisProperties.getConnectTimeout())
                .build();

        return new LettuceConnectionFactory(config, clientConfig);
    }

    @Bean(name = "tokenRedisTemplate")
    public RedisTemplate<String,String> tokenRedisTemplate(RedisConnectionFactory redisConnectionFactory) {
        RedisTemplate<String,String> redisTemplate = new RedisTemplate<>();
        redisTemplate.setConnectionFactory(redisConnectionFactory);
        redisTemplate.setKeySerializer(new StringRedisSerializer());
        redisTemplate.setValueSerializer(new StringRedisSerializer());

        return redisTemplate;
    }
}

RedisProperties 는 https://dean83.tistory.com/418 여기에 정리해 놓은것 처럼, yaml 에 있는 설정을 매핑한 클래스 이다.
GenericObjectPoolConfig를 이용하기 위해 아래의 라이브러리를 gradle에 추가해야 한다.
기본적인 redis 동작 설정 (pool 개수 등), 타임아웃을 포함해야 한다.

implementation 'org.apache.commons:commons-pool2'

RefreshToken을 관리하는 Repository 예

redisTemplate을 주입받아 이를 통해 redis에 저장
참고로 별도의 서비스를 구현하여 repository에 접근할 경우 @Transactional은 쓰지 않는다.
- Redis에선 일반적인 Transactional과 개념이 다름

@Repository
public class RefreshTokenRedisRepository {

    private final StringRedisTemplate redisTemplate;

    public RefreshTokenRedisRepository(StringRedisTemplate redisTemplate) {
        this.redisTemplate = redisTemplate;
    }

    public void save(Long userId, String refreshToken, long ttlMs) {
        String key = "refresh_token:" + userId;
        redisTemplate.opsForValue()
                .set(key, refreshToken, ttlMs, TimeUnit.MILLISECONDS);
    }

    public String find(Long userId) {
        return redisTemplate.opsForValue()
                .get("refresh_token:" + userId);
    }

    public void delete(Long userId) {
        redisTemplate.delete("refresh_token:" + userId);
    }
}

Security 에서 Role 적용시 헷갈리는 부분 정리

Dean83 — Wed, 28 Jan 2026 15:04:12 +0900

보통, User의 Role을 이용할 경우, enum을 통해서 ADMIN, USER 처럼 정의하고 이용하게 된다. DB에도 이렇게 저장된다.
그러나 권한 확인 메소드인 hasRole 같은 경우에는 자동으로 앞에 "ROLE_" 문자열을 붙여서 비교하게 된다.

사용자 인증 할때 보통 Custom 한 UserDetails 를 구현한 구현체 구성을 하게 되는데, 오버라이드 한 메소드 중 아래 메소드에서

"ROLE_" 문자열을 붙여줘야 한다.

@Override
public Collection<? extends GrantedAuthority> getAuthorities() {
    if(userDto == null)
        return List.of();

    return List.of(new SimpleGrantedAuthority("ROLE_" + userDto.getRole()));
}

이제 이 경우, 어느 Role 에서는 ROLE_가 붙고, 어디서는 enum값 그대로 쓸 수 있는지 헷갈리게 된다.

간략히 요약하자면,

SecurityContext에 저장된 항목 : ROLE_ 가 붙어 있음
그외 개발자가 개발한 API, 엔티티 등 항목 : ROLE_가 붙어있지 않음

다시 요약하자면,

DB, 엔티티에는 Enum에서 명시한 Role 이름 그대로.
UserDetails를 구현한 구현체에서 ROLE_ 문자열 붙이기
이후 SecurityContext 에 저장된 Role을 가져올 경우에는 ROLE_이 붙어있음 (GrantedAuthority 관련된 항목들)
- 단, SecurityContext에 Dto를 저장했다면, 해당 Dto에 있는 role 은 enum 그대로
- Authentication의 getPrincipal 메소드는 ROLE_
hasRole() 메서드를 이용하는 경우에는 자동으로 ROLE_가 붙음

SSE 예제

Dean83 — Wed, 14 Jan 2026 17:17:01 +0900

이론부분은 https://dean83.tistory.com/412 이부분을 보면 된다.

별도로 build.gradle에 추가할 필요는 없다. (대부분 starter-web은 이미 추가 되어 있다)

Async 및 TaskExecutor 설정

이 부분은 https://dean83.tistory.com/393 에서 자세히 다루었다.

@Configuration
@EnableAsync
@EnableScheduling
public class AsyncConfig {

    @Bean("sseExecutor")
    public TaskExecutor sseTaskExecutor() {
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        executor.setCorePoolSize(10);
        executor.setMaxPoolSize(50);
        executor.setQueueCapacity(1000);
        executor.setThreadNamePrefix("sse-");
        executor.initialize();
        return executor;
    }
}

전송 데이터 정의 예

SSE는 text 기반이므로, 직렬화가 가능해야 한다.

@Getter
@AllArgsConstructor
public class NotificationEvent {
    private String id;
    private String type;
    private String message;
}

SSE 이벤트 데이터 엔티티 예 (DB 저장용)

서버가 재부팅 되거나 클라이언트 재접속 등 이슈가 발생했을때 이어서 동작할 수 있도록 DB에 내용 저장

@Entity
@Table(name = "sse_event")
@Getter
@NoArgsConstructor
@AllArgsConstructor
@Builder
public class SseEventEntity {

    @Id
    private String eventId;

    private String eventType;
    private String targetGroup;

    @Lob
    private String payload;

    private LocalDateTime createdAt;
}

이벤트 저장 및 조회 서비스 예

@Service
@RequiredArgsConstructor
public class EventStoreService {

    private final SseEventRepository repository;
    private final ObjectMapper objectMapper = new ObjectMapper();

    public void save(String eventId, String eventType, String group, Object payload) {
        try {
            repository.save(
                SseEventEntity.builder()
                    .eventId(eventId)
                    .eventType(eventType)
                    .targetGroup(group)
                    .payload(objectMapper.writeValueAsString(payload))
                    .createdAt(LocalDateTime.now())
                    .build()
            );
        } catch (JsonProcessingException e) {
            throw new RuntimeException(e);
        }
    }

    public List<SseEventEntity> findAfter(String lastEventId, String group) {
        return repository.findByEventIdGreaterThanAndTargetGroup(
            lastEventId, group
        );
    }
}

클라이언트 정보 저장 클래스 예

SseEmitter 를 관리하는 측에서 이 정보를 토대로 생성/삭제 등 관리

@Getter
@AllArgsConstructor
public class ClientSubscription {
    private String clientId;
    private String group;
    private Set<String> eventTypes;
    private SseEmitter emitter;
}

SseEmitter 관리

Sse 생성 및 관리 코드 예제이다.

@Component
@RequiredArgsConstructor
public class SseEmitterManager {

    private static final long TIMEOUT = 60 * 60 * 1000;
    private static final int MAX_CONNECTION = 1000;

    // clientId 기준으로 관리 (정책적으로 단일 연결)
    private final Map<String, ClientSubscription> clients = new ConcurrentHashMap<>();

    private final SseReplayService replayService;

    public SseEmitter create(
        String clientId,
        String group,
        Set<String> eventTypes,
        String lastEventId
    ) {
        if (clients.size() >= MAX_CONNECTION) {
            throw new IllegalStateException("Max SSE connections exceeded");
        }

        // 기존 연결 정리 (중복 로그인 / 재연결 대비)
        remove(clientId);

        SseEmitter emitter = new SseEmitter(TIMEOUT);

        ClientSubscription subscription =
            new ClientSubscription(clientId, group, eventTypes, emitter);

        clients.put(clientId, subscription);

        emitter.onCompletion(() -> remove(clientId));
        emitter.onTimeout(() -> remove(clientId));
        emitter.onError(e -> remove(clientId));

        //핵심: emitter 생성 직후 재전송 트리거
        replayService.replay(subscription, lastEventId);

        return emitter;
    }

    public Collection<ClientSubscription> getAll() {
        return clients.values();
    }

    public Optional<ClientSubscription> get(String clientId) {
        return Optional.ofNullable(clients.get(clientId));
    }

    public void remove(String clientId) {
        ClientSubscription client = clients.remove(clientId);
        if (client != null) {
            client.getEmitter().complete();
        }
    }
}

비동기 전송 및 필터링 서비스

구독한 항목 혹은 유저 그룹별 필터링 하여 전송 대상을 선정, 비동기로 전송

@Service
@RequiredArgsConstructor
public class SseSendService {

    private final SseEmitterManager manager;
    private final EventStoreService storeService;

    @Async("sseExecutor")
    public void publish(
        String eventType,
        String targetGroup,
        Object payload
    ) {
        String eventId = UUID.randomUUID().toString();

        // 1️⃣ DB 저장
        storeService.save(eventId, eventType, targetGroup, payload);

        // 2️⃣ 필터링 후 전송
        manager.getAll().stream()
            .filter(c -> c.getGroup().equals(targetGroup))
            .filter(c -> c.getEventTypes().contains(eventType))
            .forEach(c -> send(c, eventId, eventType, payload));
    }

    private void send(
        ClientSubscription client,
        String eventId,
        String eventType,
        Object payload
    ) {
        try {
            client.getEmitter().send(
                SseEmitter.event()
                    .id(eventId)
                    .name(eventType)
                    .data(payload)
            );
        } catch (IOException e) {
            client.getEmitter().complete();
        }
    }
}

주기적으로 연결 정리

스케줄러를 통해 heartbeat을 보내고 정리한다.

@Component
@RequiredArgsConstructor
public class SseHeartbeatScheduler {

    private final SseEmitterManager manager;

    @Scheduled(fixedRate = 30_000)
    public void heartbeat() {
        manager.getAll().forEach(c -> {
            try {
                c.getEmitter().send(
                    SseEmitter.event()
                        .name("heartbeat")
                        .data("ping")
                );
            } catch (IOException e) {
                c.getEmitter().complete();
            }
        });
    }
}

재전송 서비스 예

@Service
@RequiredArgsConstructor
public class SseReplayService {

    private final EventStoreService storeService;

    @Async("sseExecutor")
    public void replay(
        ClientSubscription client,
        String lastEventId
    ) {
        if (lastEventId == null) return;

        List<SseEventEntity> events =
            storeService.findAfter(lastEventId, client.getGroup());

        events.stream()
            .filter(e -> client.getEventTypes().contains(e.getEventType()))
            .forEach(e -> send(client, e));
    }

    private void send(ClientSubscription client, SseEventEntity e) {
        try {
            client.getEmitter().send(
                SseEmitter.event()
                    .id(e.getEventId())
                    .name(e.getEventType())
                    .data(e.getPayload())
            );
        } catch (IOException ex) {
            client.getEmitter().complete();
        }
    }
}

컨트롤러 예

@RestController
@RequestMapping("/api/sse")
public class SseController {

    private final SseEmitterManager sseEmitterManager;

    public SseController(SseEmitterManager sseEmitterManager) {
        this.sseEmitterManager = sseEmitterManager;
    }

    @GetMapping("/subscribe")
    public SseEmitter subscribe(
            @RequestHeader(value = "Last-Event-ID", required = false) String lastEventId,
            @RequestParam String userId
    ) {
        return sseEmitterManager.subscribe(userId, lastEventId);
    }
}