Janu is Developing

[Dalmuri] 맡김 API 호출해서 감정 분석하기 - WebClient를 이용해서

JanuDev — Fri, 3 Apr 2026 16:45:36 +0900

[Dalmuri] Java로 Google Cloud Nature Language API 호출해서 감정 다이어리 만들기

API 연결 후기 : 코드 짜는것보다 초기 세팅이 훨씬 더 어렵다.. 여럽다기보단 방법도 많고 읽어야 하는 공식 문서도 많아서, 정작 내가 원하거나 필요한 정보를 찾는데 더 시간이 오래 걸린 것

janudev.tistory.com

진짜 드럽고 치사한 세상이다... 거렁뱅이 개발자들은 개발 어떻게 하라고 맨날 과금타령 하는질 모르겠다. 난 클로드 코드도 돈아까워서 그냥 잼민이+클로드 고문하고 있는데...인텔리제이 1년치 요금도 대학교 계정으로 40퍼 할인받는것도 덜덜 떨면서 결제하고 있는데... 그리고 게시글 작성 기준일로 환율도 장난아니게 높아서 가격 더올랐을거다...

우리나라 환율도 박살났는데 일본은 섭종하나요,,,,?

기존 게시글 보면 알겠지만 원래 맡김 API를 사용해서 감정 분석을 하고 싶었다... 왜냐? 공짜니까.

근데 그 타이밍에 API가 고장나서 문의를 드렸고 다른 대체품이 있을까 검색하다가 Google 자연어 분석 API를 알게 되었고... 그걸 활용하려고 고생 하면서 Google colud에 내 프로젝트 생성했고.. 권한 설정했고.. pom.xml에 의존성 추가하고 어쩌구 저쩌구 한건데...

이제 과금되서 돈 내고 사용하란다!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

그냥 여러가지 공부했다고 정신승리하련다...

1. 맡김 API란?

https://matgim.ai/public-api/

데이탄소프트라는 회사에서 출시한 API 서비스인데, 다양한 인공지능 API를 사용할 수 있는 서비스라고 한다. 실제로 감정 분석 API 말고도 다양한 API들이 있다.

심지어 비속어 추출 API 이런것도 있다. 이런걸 무료로 풀어주는게 너무 감사할 따름...

완벽한 무료는 아니고, 한달에 100회 이상은 만원 + a로 과금이 된다.

근데 플젝을 사용할 나나 내 친구들이 매일매일 일기를 쓸 정도로 부지런하지 않기 때문에(ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ) 안심하고 과금 버전 사용할 수 있을거다. 친구들아 고마워!

2. 개발 순서

기존의 Google 자연어 분석 API를 싹 다 주석처리하고 거기에 새로이 맡김 API를 사용할 것이기 때문에 controller, service는 새로이 생성될 필요는 없다.

다만 Google에선 자체적으로 의존성을 추가시켜서 객체를 본인들이 생성해줬는데(Sentiment, LanguageServiceClient와 같이)

맡김은 그런거 없어서 내가 직접 객체를 생성해야 한다.

(1) MatgimResponseDTO 객체 생성

맡김 API에서 다음과 같은 json 형식으로 가져오기 때문에 이것과 동일한 구조의 DTO를 만든다.

import com.fasterxml.jackson.databind.PropertyNamingStrategies;
import com.fasterxml.jackson.databind.annotation.JsonNaming;
import lombok.*;
import java.util.List;

@Getter
@Setter
@ToString
@NoArgsConstructor
@AllArgsConstructor
@JsonNaming(PropertyNamingStrategies.SnakeCaseStrategy.class)
public class MatgimResponseDTO {
    private boolean success;
    private Result result;

    @Getter
    @Setter
    @ToString
    @NoArgsConstructor
    @AllArgsConstructor
    @JsonNaming(PropertyNamingStrategies.SnakeCaseStrategy.class)
    public static class Result {
        private DocumentScore documentScore;
        private List<SentenceScore> sentenceScore;
    }

    @Getter
    @Setter
    @ToString
    @NoArgsConstructor
    @AllArgsConstructor
    @JsonNaming(PropertyNamingStrategies.SnakeCaseStrategy.class)
    public static class DocumentScore {
        private double score;
        private double posScore;
        private double negScore;
    }

    @Getter
    @Setter
    @ToString
    @NoArgsConstructor
    @AllArgsConstructor
    @JsonNaming(PropertyNamingStrategies.SnakeCaseStrategy.class)
    public static class SentenceScore {
        private String sentence;
        private double score;
    }

}

참고로

@JsonNaming(PropertyNamingStrategies.SnakeCaseStrategy.class)

이건 Java객체의 camelCase와 Json 객체의 snake_case를 서로 매핑시켜주는 설정이다.

외부에서 들어오는 snake_case형식의 Json 데이터를 Java의 caleCase로 필드에 자동으로 매핑(역직렬화)해줄 수 있다.

현재 클래스는

public class MatgimResponseDTO {  // 최상위 부모 클래스
    // 내부 클래스
    class Inner {}          // ❌ static 없음
    static class Inner2 {}  // ✅ static 있음
}

이런 구조이다.

public class MatgimResponseDTO(최상위 클래스) : 부모 클래스라는 개념이 없음. 독립적인 파일 단위, 어디서든 new MatgimResopnseDTO()로 바로 생성할 수 있음.
public class inner : MatgimResponseDTO라는 '집' 안에서만 살 수 있는 클래스. 반드시 MatgimResponseDTO가 먼저 생성되어야 한다. static이 없는 내부 클래스일 때만(=public class Inner일때만) 외부 클래스 객체(MatgimResponseDTO)가 있어야 생성할 수 있다.
public static class Result(내부 클래스에 static이 있는 경우) : 이름표는 MatgimResponseDTO.Result를 달고 있지만 실제론 new MatgimResponseDTO.Result()로 혼자 태어날 수 있음

그렇다면 public class와 public static class의 차이는?

public class : 외부 클래스의 인스턴스가 먼저 생성되야만 존재할 수 있는 클래스. 단 최상위 클래스의 경우 외부 클래스라는 개념도 없다(ex. MatgimResponseDTO)
public static class : public class 내부에서만 쓸 수 있는 정적 클래스. 여기선 public Static class Result, public static class DocumentScore, public static class SentenceScore가 있다. 일반 클래스처럼 혼자 생성 가능하며 주로 DTO 계층 구조를 만들 때 권장된다.

"내부 클래스일 때" static 없으면 “부모 없이는 못 태어남” → MatgimResponseDTO에선 해당 없음(애초에 내부 클래스가 아니기 때문)
static 있으면 “혼자 태어날 수 있음”

MatgimResponseDTO
 └── Result
      └── DocumentScore
      └── SentenceScore

여기서 MatgimResponseDTO는 최상위 클래스로 부모가 없다.

Result, DocumentScore, SentenceScore은 MatgimResponseDTO 안에 포함된 내부 클래스.

Result 나 DocumentScore을 static으로 선언해야 하는 이유는

독립적 인스턴스화 : Jackson이 JSON을 Java객체로 바꿀 때, 외부 클래스인 MatgimResponseDTO를 먼저 만들지 않고도 내부의 Result객체를 생성할 수 있어야 한다.
메모리 효율 : static이 아니면 내부 클래스 객체는 자신을 감싸고 있는 외부 클래스의 정보를 항상 들고 있어야 한다. DTO처럼 단순 데이터를 담는 용도라면 이런 연결 고리는 메모리 낭비만 초래한다.
구조적 그룹화 : 관련 있는 데이터 구조(Result, Score)를 따로 만들지 않고 하나의 파일 안에서 논리적으로 묶어 관리할 수 있어 가독성이 좋아진다.

따라서 static이 붙지 않는 내부 클래스는 부모(외부)가 있어야 태어날 수 있는 자식이고, static class는 부모 집 안에 살지만 자기 차와 열쇠를 따로 가지고 있는 독립된 성인이라 볼 수 있다.

(2) WebClient 설정

실무에서 RestTemplate를 이용해서 외부 API와 연결하는게 표준이었는데, 요즘 RestTemplate 쓰는것도 구시대적이라 권장되지 않는다고 한다. ~~(그래서 선배가 리팩토링 하다가 기존 코드 다 이상해져서 롤백한건 안비밀)~~

그래서 초장부터 그냥 RestTemplate말고 좀 더 좋은게 뭐가 있을지 생각하다가 WebClient라는걸 발견했다. WebClient는 비동기 및 비차단 통신을 효율적으로 처리하는 반응형 Http client라고 한다.

비동기, 논블로킹(Non-Blocking) 방식 : WebClient는 Reactive Stack을 기반으로 한다. API요청을 보낸 뒤 응답이 올 때 까지 스레드가 대기(Block)하지 않고 다른 일을 할 수 있다. 적은 수의 스레드로 훨씬 많은 동시 요청을 할 수 있기 때문에 서버의 처리량이 획기적으로 늘어난다.
싱글톤(Singleton)으로 관리되는 재사용성 : @Bean으로 등록하면 스프링 컨테이너가 WebClient 객체를 딱 하나만 만들어서 관리한다. 리소스를 절약하고 설정을 공유할 수 있다.
유연한 확장성: 나중에 타임아웃 설정, 로깅용 필터, 특정 API 전용 인증 헤더 추가 등등을 builder에 한줄만 추가하면 된다. 또한 한번 빌드된 WebClient는 상태가 변하지 않으므로 여러 스레드에서 동시에 사용해도 안전하다.
가독성과 유지보수 : .retrieve().bodyToMono(MatgimResponseDTO.class) 이거 한줄이면 API응답인 snake_case를 우리가 만든 camelCase로 자동 변환해준다.

참고로 스레드(thread)란?

하나의 프로세스 안에서 독립적으로 실행되는 '작은 실행 단위'

쉽게 비유하자면 "일꾼"이다. 자바 애플리케이션(서버)이라는 식당에서 손님의 주문을 받고 요리해서 서빙까지 하는 직원 한 명이 곧 스레드 하나라고 생각하면 된다.

스레드가 많으면? 일꾼이 많으니 동시에 여러 손님을 응대할 수 있지만, 일꾼마다 월급(메모리 점유)을 줘야 하고 관리하기가 힘들어짐
스레드가 적으면? 서버가 사용하는 메모리가 적고 가볍지만, 일꾼이 모자라면 손님들이 줄을 서서 기다려야함

❌ Thread 1개

요청1 → 끝나야 → 요청2 → 끝나야 → 요청3 느림

✔ Thread 여러 개

요청1
요청2
요청3
동시에 처리  빠름

그럼 프로세스(process)란?

시스템에서 실행 중인 프로그램

이제 왜 최근에 RestTemplate가 아닌 WebClient가 사용되는지 이제 알겠다~

1️⃣ pom.xml에 의존성 추가

<!-- webClient -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-webflux</artifactId>
</dependency>

2️⃣ WebCientConfig 작성하기

@Configuration
public class WebClientConfig {

    @Bean
    public WebClient MatgimWebClient(){
       return WebClient.builder()
               .defaultHeader(HttpHeaders.CONTENT_TYPE, MediaType.APPLICATION_JSON_VALUE)
               .build();
    }
}

@Configuration : 스프링이 시작될 때 Configuration 어노테이션을 읽어서 설정을 실행함. 자바의 일반 클래스가 아닌 스프링 시스템의 설계도 역할
@Bean : 다른 서비스 클래스에서 new WebClient()를 매번 할 필요 없이 스프링이 미리 만들어준 이 객체를 "주입(@Autowired)"바당 쓸 수 있음(싱글톤 패턴)
public WebClient MatgimWebClient() : 생성될 객체의 타입은 WebClient, 이 Bean의 이름은 MatgimWebClient
WebClient.builder() : WebClient 객체를 만들기 위한 조립 도구(Builder)를 꺼내는 단계
defaultHeader(HttpHeader.CONTENT_TYPE, MediaType.APPLICATION_JSON_VALUE) : 클라이언트로 보내는 모든 요청은 기본적으로 JSON임을 명시함)
build() : 설정을 마친 최종 객체가 생성되어 스프링 컨테이너에 보관됨

3️⃣ API 호출하기

String body = request.getText();
Map<String,String> bodyMap = new HashMap<>();
bodyMap.put("document", body);

MatgimResponseDTO result = webClient.post()
        .uri(matgimUrl)
        .header("Content-Type", "application/json")
        .header("x-auth-token", matgimApiKey)
        .bodyValue(bodyMap)
        .retrieve()
        .bodyToMono(MatgimResponseDTO.class)
        .block();

이제 service단에서 API 호출부를 작성하면 된다.

요청 데이터 준비

String body = request.getText(); // 사용자가 보낸 일기 내용 등을 가져옴
Map<String, String> bodyMap = new HashMap<>();
bodyMap.put("document", body); // API가 원하는 {"document": "내용"} 형식으로 만듦

호출부 작성

MatgimResponseDTO result = webClient.post() // 1. POST 방식
        .uri(matgimUrl) // 2. 목적지 주소(URL) 설정
        .header("Content-Type", "application/json") // 3. JSON 데이터라고 알림
        .header("x-auth-token", matgimApiKey) // 4. 인증 키를 헤더에 담음
        .bodyValue(bodyMap) // 5. 준비한 데이터를 몸체(Body)에 실음
        .retrieve() // 6. 이제 요청을 쏨
        .bodyToMono(MatgimResponseDTO.class) // 7. 받은 JSON을 아까 만든 DTO 객체로 자동 변환
        .block(); // 8. 결과가 올 때까지 기다림 (동기적 처리)

.block()의 의미: 원래 WebClient는 비동기(Non-blocking)로 동작하지만, 여기서 .block()을 쓰면 응답이 올 때까지 다음 코드로 넘어가지 않고 기다린다. 왜냐면

double score = result != null ? result.getResult().getDocumentScore().getScore() * 2.5 : 0;
        score = Math.max(-1, Math.min(1, score));

        double positive = result != null ? result.getResult().getDocumentScore().getPosScore() : 0;
        double negative = result != null ? result.getResult().getDocumentScore().getNegScore() : 0;
        double magnitude = (Math.abs(positive) + Math.abs(negative)) * 5;

        response.setScore(score);
        response.setMagnitude(magnitude);
        return ResponseEntity.ok(response);

이 로직 때문에.. 기존에 google api에선 감정을 score과 magnitude로 분리해서 보내줬는데, 맡김은 긍정적인 감정, 부정적인 감정의 점수만 알려준다. 그래서 그걸 score과 magnitude로 변환한 개인적인 로직이다... 이 부분은 필수는 아니다!

[참고 문헌]

https://m.blog.naver.com/seek316/223337685249

[Java] Spring Boot - WebClient 사용하기

WebClient란? WebClient는 Spring Boot 애플리케이션에서 HTTP 요청을 만드는 데 사용되는 강력...

blog.naver.com

https://coding-factory.tistory.com/279

[Java] 자바 Thread(스레드) 사용법 & 예제

Thread란? 하나의 프로세스 내부에서 독립적으로 실행되는 하나의 작업 단위를 말하며, 세부적으로는 운영체제에 의해 관리되는 하나의 작업 혹은 태스크를 의미합니다. 스레드와 태스크(혹은 작

coding-factory.tistory.com

모르는 단어 정리_ WSL2, Ubuntu, WireGuard, VPN

JanuDev — Mon, 30 Mar 2026 16:53:07 +0900

Tailscale과 Nginx보다가 그냥 간단하게 정리하고 공부하고싶어서 쓴 글...

1. WSL2(Windows Subsystem for Linux2)

Window안에서 리눅스를 "진짜처럼" 실행할 수 있도록 하는 기능.

Window PC 하나로 Windows + Linux 둘 다 쓸 수 있는 환경이다.

[ Windows ]
     ↓
[ WSL2 (가벼운 가상머신 느낌) ]
     ↓
[ Linux (Ubuntu 등) ]

원래 리눅스는 별도로 설치해야 하는데, WSL2는 Window안에서 리눅스를 바로 실행할 수 있도록 해준다.

	WSL1	WSL2
방식	번역 방식	진짜 리눅스 커널 사용
속도	느림	빠름
호환성	제한적	거의 완벽

그래서 현재는 무조건 WSL2를 사용하는 상태.

실제 Linux 커널을 Window 안에서 실행하기 때문에

Docker 실행 가능
Linux 명령어 100% 실행 가능
서버 개발 환경 그대로 재현

이 가능하다.

서버 환경은 대부분 Linux이기 때문에 WSL2가 있으면 Mac이 없어도 Linux가 개발 가능하거나 배포 환경과 동일하게 테스트 할 수 있다.

ex)

Java + Spring 서버 실행
Node.js 서버
DB(PostgreSQL 등)

전부 WSL2안에서 돌린다.

2. Ubuntu

(모른다기 보단 그냥 다시 한번 정리해서 짚고 넘어가는 정도)

리눅스의 운영체제(OS)의 한 종류.

Window → 윈도우 OS

macOS → 애플 OS

Linux → 여러 종류가 있음. 그 중 하나가 Ubuntu인 것.

리눅스는 오픈소스이기 때문에 여러 팀/회사들이 자기 스타일로 만든 버전들이 있다.

3. VPN(Virtual Private Network)

인터넷 위에서 "가상의 사설 네트워크(전용망)"를 만드는 기술

일반 인터넷

내 PC → (공개 인터넷) → 서버

VPN을 사용하면

내 PC → (암호화 터널) → VPN 서버 → 인터넷 → 서버

중간 구간이 암호화된 터널로 보호된다.

주로 (1) 보안 문제, (2) IP 숨김(내 실제 IP대신 VPN서버 IP 사용), (3) 네트워크 우회(지역제한 서비스 접근)를 목적으로 사용한다.

쉽게 말하면 "비밀 터널"

ex)

회사 내부망 접속
해외에서 한국 사이트 접속
카페 Wifi에서 안전하게 로그인

4. WireGuard

VPN을 구현하는 "프로토콜(방식)" 중 하나

그러니까 VPN = 개념

WireGuard = 그걸 만드는 기술 중 하나

기존 VPN 방식이 openVPN, IPSec 등이 있었는데, 이것들의 문제점은... 설정이 복잡하고 속도가 느리고 코드가 무겁다.

그래서 WireGuard는 (1) 매우 빠르고(최신 암호화 알고리즘 사용), (2) 코드가 간단하고(약 4000줄), (3) 설정이 쉽다(key 기반 구조)

Client (Private Key)
   ↓
[ 암호화 ]
   ↓
Server (Public Key로 검증)

SSH(전하지 않은 네트워크를 통해 원격 컴퓨터에 접속하여 명령어를 실행하거나 파일을 전송할 때, 키 기반 인증(SSH Key)의 암호화 기술을 사용하여 데이터를 보호하는 네트워크 프로토콜)랑 비슷한 구조.

라즈베리파이4 서버 구축기 - (4) 외부에서 내 프로젝트 접속하기

JanuDev — Mon, 30 Mar 2026 16:36:08 +0900

기존에 내가 게시글에서

(4) 외부 접속 설정 (선택)

1. 공유기 포트포워딩 설정 예) 80 포트를 라즈베리파이의 80 포트로 포워딩

2. DDNS 설정 (선택): 외부에서 접속할 수 있도록 도메인 주소 할당 (No-IP, DuckDNS 등 사용)

3. SSL 적용 (선택): certbot으로 Let's Encrypt 인증서 설정하면 HTTPS 접속 가능...(생략)

....뭐 이런식으로 썼었는데, 이것도 AI한테 물어봐서 정보를 얻은거라 확실하진 않아서 내가 직접 찾아봤다.

Let's Encrypt 인증서란?

무료로 HTTPS 보안 연결을 가능하게 해주는 인증서 발급기관.

인터넷에선 보안을 위해 데이터를 암호화 해주는 HTTPS 인증서를 사용해야 한다(이건 기존의 나도 알고 있던것). HTTPS를 쓰면 데이터가 암호화되고, 로그인 정보 및 쿠키가 보호된다.

웹페이지가 HTTPS가 되려면 서버에 인증서가 있어야 하는데, 이 인증서는 (1) 이 서버가 진짜임을 증명 (2) 암호화 통신 시작을 위한 키 제공 등의 역할을 하고 있다.

Let's Encrypt : 인증서를 발급해주는 기관(CA), 실제 인증서를 만들어서 내려줌
Certbot : 인증서를 자동으로 받아오는 프로그램. Let's Encrypt에 요청 보내고 인증서 받아서 서버 설치하고 만료되면 자동 갱신까지 해주고....

그러다가 Tailscale를 알게됬다.

Tailscale이란?

WireGuard 프로토콜을 기반으로 한 현대적인 매쉬 VPN솔루션으로, 복잡한 네트워크 설정없이 장치 간 안전하고 빠른 연결을 제공한다. 뭔 말인지 이해 안간다면, "집 밖에서도 집 안에 있는것처럼 접속하게 만들어주는 도구"라고 설명할 수 있을 것이다.

기존의 방식은

다른 장소 → 인터넷 → 공유기(포트포워드) → 라즈베리파이(홈서버)

의 방법을 이용하기 때문에 외부 접속 시 포트포워드 설정, 공인IP 및 DDNS 설정, 보안 등의 번거로움이 있었다.

Talescale은 공유기, 포트포워딩 등의 선행 작업이 모두 무시된다.

1️⃣ 가짜 내부 네트워크를 만듦

집이든 회사든 어느 장소든 상관 없이 모든 기기를 같은 네트워크에 있는 것처럼 만들어주는데, 그래서 홈서버에는 Tailscale 전용 IP가 생긴다.

100.x.x.x (Tailscale 전용 IP)

2️⃣ 그 주소로 바로 접속 가능

터미널(리눅스, 윈도우 powershell, 맥)에서 다음과 같이 작성하면 열린다.

ssh pi@100.x.x.x

단 저렇게 하면 당연히 일반 사용자들은 들어올 수 없기 때문에.... 난 Tailscale Funnel 무료 버전을 사용하기로 했다.

1. 라즈베리파이에 웹서버 실행

npm run dev, http://localhost:3000 등으로 라즈베리파이 네부에서 접속이 되어 있어야 한다.

2. Tailscale 설치

라즈베리파이 os에서 curl명령어를 쓸 수 있으므로

curl -fsSL https://tailscale.com/install.sh | sh

를 작성하고, 설치 후

sudo tailscale up

를 통해 로그인 창이 뜨면 로그인을 한다.

3. Funnel 활성화

sudo tailscale funnel 3000

라즈베리파이의 3000번 포트를 외부에 공개하겠다는 뜻으로, 각 포트에 맞게 작성하면 된다.

4. URL 생성 확인

명령을 실행하면

https://xxxx.ts.net

가 나오는데, 이게 바로 외부에서 접속 가능한 URL이다.

다만 나의 경우 Vite + Typescript + React를 사용한 web단과 Spring Boot를 사용한 WAS단이 따로 나뉘어져 있기 때문에 리버스 프록시(Nginx)를 사용해야 한다.

외부 (https://xxx.ts.net)
        ↓
     nginx
   ├─ /        → React (정적 파일)
   └─ /api     → Spring Boot (8080)

전체 단계는 다음과 같다.

(1) React 빌드

(2) NGINX 설치

(3) NGINX 설정

(4) Spring Boot 실행

(5) Tailscale Funnel 연결

1. React 빌드

라즈베리 파이에서 react 프로젝트를 빌드한다.

npm run build

결과는 다음과 같을거다.

dist/
 ├─ index.html
 ├─ assets/

2. nginx 설치

sudo apt update
sudo apt install nginx -y

설치 확인은

nginx -v

로 확인한다.

3. nginx 설정

설정 파일 열기

sudo nano /etc/nginx/sites-available/default

기존 내용 다 지우고 아래로 교체한다.

server {
    listen 80;
    server_name _;

    # React (프론트)
    root /home/pi/project/dist;
    index index.html;

    location / {
        try_files $uri /index.html;
    }

    # Spring Boot (백엔드)
    location /api/ {
        proxy_pass http://localhost:8080/;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

중요 포인트는, root경로를 내 dist 폴더 위치로 바꾸는 것이다.

root /home/pi/project/dist;

4. nginx 재시작

sudo systemctl restart nginx

5. Spring Boot 실행

maven 빌드 명령어를 실행해서 jar 파일을 만드는 것이 핵심이다.

mvn clean package

clean : 이전에 빌드했던 찌꺼기 파일을 지움
package: 소스 코드를 컴파일하고 테스트를 걸쳐 target폴더 안에 .jar파일을 생성함

성공 시 target/ 폴더 안에 프로젝트명-0.0.1-SNAPSHOT.jar과 같은 파일이 생성된다. 그리고 이 파일을 라즈베리파이 컴퓨터로 보내야 한다.

# 형식: scp [파일경로] [사용자]@[라즈베리파이IP]:[복사할경로]
scp target/*.jar pi@raspberrypi.local:/home/pi/project/app.jar

위 명령어 작성 시 내 pc에 있던 jar파 일이 라즈베리파이의 /home/pi/project/폴더로 app.jar라는 이름으로 복사된다.

6. Tailscale Funnel 연결

sudo tailscale funnel 80

[참고 자료]

https://velog.io/@zvyg1023/Certbot-ssl-%EC%9D%B8%EC%A6%9D%EC%84%9C-%EB%B0%9C%EA%B8%89%EB%B0%9B%EA%B8%B0

Let's Encrypt - Certbot으로 ssl 인증서 발급받기

이제 본격적인 https 세팅을 시작해볼 것이다. Let's Encrypt 라는 비영리 기관을 통해 무료로 SSL 인증서를 발급받을 수 있다. 인증서 발급을 위해 Certbot을 사용해보자. 1. certbot 설치하기 Certbot 설치는

velog.io

https://devopslog.tistory.com/169

Tailscale 가이드 - 안전한 매쉬 VPN 활용법

Tailscale의 핵심 개념, VPN 정의, 동작 방식, 설치 및 구성 방법, 엔드포인트 관리, 포트 제어, 다른 단말 접속, 그리고 보안 설정 방법Tailscale이란?Tailscale은 WireGuard 프로토콜을 기반으로 한 현대적인

devopslog.tistory.com

https://www.youtube.com/watch?v=vCM-demQ4MY

https://github.com/jacking75/NewbieGameServerProgrammerLearningMaterials/blob/main/Tailscale.md

NewbieGameServerProgrammerLearningMaterials/Tailscale.md at main · jacking75/NewbieGameServerProgrammerLearningMaterials

뉴비 게임 서버 프로그래머를 위한 학습 자료. Contribute to jacking75/NewbieGameServerProgrammerLearningMaterials development by creating an account on GitHub.

github.com

https://cwpack0730.tistory.com/117

[NGINX] nginx reverse proxy

1. 개요현재 매 월마다 서비스 정기점검을 진행하고 있다. 보통 새벽시간대에 점검을 진행하는데 이 때 일반 사용자는 점검중인 서비스에 접근할 수 없도록 점검 페이지로 이동해야 하며, 개발

cwpack0730.tistory.com

람다식이란?

JanuDev — Thu, 29 Jan 2026 11:47:51 +0900

자바 쓰다가 처음 보는 꼬라지가 있었는데...

그게 람다식이라고 하길래 남겨본다.

UserDTO user = jdbcTemplate.queryForObject(
    sql,
    new Object[]{userId},
    (rs, rowNum) -> {   // 람다
        UserDTO u = new UserDTO();
        u.setUserCd(rs.getString("USER_CD"));
        u.setUserId(rs.getString("USER_ID"));
        u.setUserNm(rs.getString("USER_NM"));
        u.setPassword(rs.getString("PASSWORD"));
        u.setBgColor(rs.getString("BG_COLOR"));
        u.setTextColor(rs.getString("TEXT_COLOR"));
        u.setInsertDatetime(rs.getString("INSERT_DATETIME"));
        return u;
    }
);

() -> {} 이런 형태는 처음 보는거 같다. 뭔가 낮설다.

1. 람다식이란

익명함수의 일종으로, 함수를 이름 없이 짧게 쓰는 문법(자바 8부터 사용 가능)

원래라면 클래스를 따로 만들거나 메소드를 길게 써야 하지만, 즉석에서 간단히 작성할 수 있게 되었다.

2. 람다식의 문법

$$(파라미터) -> { 실행문 }$$

위와 같이 실행된다.

파라미터(rs, rowNum) : 메소드에서 전달받는 인자. 타입은 컴파일러가 알아서 추론하므로 생략 가능.
화살표(->) : 뒤 실행문 {} 을 실행한다는 의미
실행문({}) : 실제로 수행할 코드 블럭. 실행문이 한줄이면 자바스크립트처럼 return으로 생략도 가능.

3. 람다식 사용 조건

근데 생각보다 사용할 수 있는 상황이 그렇게 많진 않은 것 같다.

함수형 인터페이스여야 한다

함수형 인터페이스란? 메소드가 딱 1개만 있는 인터페이스

@FunctionalInterface
public interface MyFunc {
    void doSomething();
}

저렇게 메소드가 1개인 인터페이스는 괜찮은데, 2개 이상인 경우 어느것을 실행해야 하는지 몰라서 멈추게 된다.

인터페이스	메서드	의미
Runnable	run()	실행만
Comparator<T>	compare()	비교
Predictate<T>	test()	조건
Function<T, R>	apply()	변환
Consumer<T>	accept()	사용만
Supplier<T>	get()	제공

클래스, 추상클래스 안된다! 인터페이스만 오직 되는것

안되는 경우들 :

interface B {
    void a();
    void b();   // ❌
}

interface Test {
    int calc(int x, int y);
}

(x, y) -> x + y ✔
(x) -> x ❌

4. 람다식의 장단점

✅ 장점

코드 간결해짐 : 익명클래스를 만들 때 필요한 반복적인 코드가 사라진다.
가독성 향상 : 불필요한 선언부가 줄기 때문에 코드가 명확해진다.
병렬 처리 유리 : 람다를 Stream API와 함께 사용하면 데이터 컬렉션을 훨씬 쉽고 빠르게(병렬로)처리할 수 있다.

❌ 단점

디버깅 어려움: StackTrace에서 찾기 어렵다,
재사용 불가능: 똑같은 로직이어도 다른곳에서 필요하면 복사하거나 별도의 메소드 분리가 필요하다.
람다 남용 시 가독성 저해
재귀 호출에 부적합

[Spring] JWT 이용해서 로그인 기능 만들기 - 필터 작성

JanuDev — Wed, 7 Jan 2026 17:16:44 +0900

공부용이기 때문에 복잡한 로직은 넣지 않고 최대한 단축해서 작성하려 했는데 내용이 너무 길다..

직전까지 JWT토큰을 이용해서 로그인하는것 까진 성공했으니, 이젠 클라이언트 요청으로부터 토큰값을 받아 controller로 요청을 보내는 JWT Filter 기능을 적용해볼거다.

기존에 filter을 적용하지 않았을 땐 무조건 403 forbidden에러가 발생했는데, 왜냐면 사용자의 신원을 확인하는 로직(= SecurityContext에 Authentication을 아직 구현 안함)이 없어 무조건 권한이 없다는 return값을 출력하도록 냅뒀기 때문이다...

그래서 이제부터 Filter 적용기를 써내려본다...

필터를 타는 순서

모든 요청들은

쿨라이언트 요청

→ SecurityFilterChain

→ 여러 Spring Security 필터들

→ JwtAuthenticationFilter

→ FilterSecurityInterceptor (authorizeHttpRequests 설정을 기반으로 권한 검사)

→ 컨트롤러

를 거쳐서 Controller로 진입한다.

그리고 SecurityConfig는 필터들의 순서표를 만든다.

1. SecurityFilterChain

기존에 만들어둔 filterChain이 있었다.

@Bean
public SecurityFilterhain filterChain (HttpSecurity http, JwtProvider jwtProvider) throws Exception {
  http
    // 허용 범위(권한 설정)
    .authorizeHttpRequests(auth -> auth
            .requestMatchers(HttpMethod.POST, "/login").permitAll()     // 로그인은 허용
            .anyRequest().authenticated()                               // 그 외는 인증 필요
    )

    // CSRF 및 CORS 설정
    .csrf(csrf -> csrf.disable())      // REST API이므로 CSRF 끄기
    .cors(Customizer.withDefaults())   // CORS 설정 허용

    // 헤더 설정
    .headers(headers -> headers.frameOptions(frameOptions -> frameOptions.disable()))
    
    //////// 추가! //////////
    // 세션 설정(jwt 필수 설정)
    .sessionManagement(session -> session.sessionCreationPolicy(SessionCreationPolicy.STATELESS))

    // jwt필터 설정
    .addFilterBefore(new JwtAuthenticationFilter(jwtProvider),
      UsernamePasswordAuthenticationFilter.class);


  return http.build();
}

이제 여기서 세션 설정과 jwt 필터 설정을 추가해야 한다.

(1) 세션설정

전통적인 로그인 방식	JWT 로그인 방식
아이디, 비번 로그인	로그인 성공시
서버가 세션(session)을 생성	서버가 JWT 토큰을 생성
서버 메모리에 '이 사람 로그인됨'을 저장	서버는 아무것도 하지 않음
브라우저는 세션 ID를 쿠키로 들고 다님	클라이언트가 매 요청마다 토큰을 들고옴

전통적인 로그인 방식은 아이디, 비밀번호 입력 후 로그인 시 서버에서 세션Session을 생성하는데, JWT방식에선 세션은 아무 일도 하지 않고 클라이언트로부터 넘어온 토큰값을 인증해야 한다.

만약 세션 설정을 끄지 않으면

Spring Security가 몰래 세션을 만들 수 있다
JWT + 세션이 섞인다
로그아웃, 만료, 인증 흐림이 꼬인다

그렇기 때문에 JWT를 쓴다면 세션은 STATELESS로 놔두어야 한다.

.sessionManagement(session -> session.sessionCreationPoplicy(SessionCreationPolicy.STATELESS))

sessionManagement() : 세션 관리 기능 설정의 시작점
session.sessionCreationPolicy : 서버가 세션을 언제 생성할지 설정
SessionCreationPolicy.STATELESS : 세션 생성 및 사용 비활성화(주로 JWT 로그인 시 사용됨)

(2) JWT 필터 설정

.addFilterBefore(new JwtAuthenticationFilter(jwtProvider), 
  UsernamePasswordAuthenticationFilter.class);

addFilterBefore(A, B) : B필터가 실행되기 바로 직전에 A필터 먼저 실행
JwtAuthenticationFilter(jwtProvider) : 토큰 인증 검사 - 사용자가 보낸 JWT 토큰이 유효한지 검사하는 커스텀 필터
UsernamePasswordAuthenticationFilter : Spring Security의 기본 필터, 아이디와 비밀번호를 로그인 시 확인하는 필터

2. JwtProvider

JwtAuthenticationFilter를 거칠 때 JwtProvider를 건네야 한다. 왜냐면 JwtAuthenticationFilter에서 토큰에 대한 유효성 검사와 사용자 정보 추출 및 인증 객체 생성이 이루어지기 때문인데, 그 메소드가 JwtProvider에 있기 때문이다.

@Component
public class JwtProvider {

    private final UserDetailsServiceImpl userDetailsServiceImpl;

    private Key secretKey = Keys.secretKeyFor(SignatureAlgorithm.HS256);

    public JwtProvider(UserDetailsServiceImpl userDetailsServiceImpl) {
        this.userDetailsServiceImpl = userDetailsServiceImpl;
    }

    /**
     * JWT 토큰 생성
     * */
    public String createAccessToken (Authentication authentication) {

        UserDetailsDTO principal = (UserDetailsDTO) authentication.getPrincipal();
        String userId = principal.getUserId();
        List<String> roles = principal.getAuthorities().stream().map(GrantedAuthority::getAuthority).toList();

        Date now = new Date();
        Date expiry = new Date(now.getTime() + ACCESS_TOKEN);

        return Jwts.builder()
                .setSubject(userId)
                .claim("role", roles)
                .setIssuedAt(now)
                .setExpiration(expiry)
                .signWith(secretKey, SignatureAlgorithm.HS256)
                .compact();

    }

    /**
     * 토큰 유효성 검사
     * */
    public boolean validateToken (String token) {
        try {
            Jwts.parserBuilder()
                    .setSigningKey(secretKey)
                    .build()
                    .parseClaimsJws(token);
            return true;
        } catch (Exception e) {
            return false; // 만료되었거나 서명이 틀린 경우
        }
    }

    /**
     * 사용자 정보 추출 및 인증 객체 생성
     * */
    public Authentication getAuthentication (String token) {
        Claims claims = Jwts.parserBuilder()
                .setSigningKey(secretKey)
                .build()
                .parseClaimsJws(token)
                .getBody();
        UserDetails userDetails = userDetailsServiceImpl.loadUserByUsername(claims.getSubject());
        return new UsernamePasswordAuthenticationToken(userDetails, "", userDetails.getAuthorities());
    }

}

토큰이 만료되었거나, 서명이 일치하지 않거나, 형식이 잘못된 경우 모두 false를 반환한다.

지금 필터링 과정에서 필요한건 validationToken메소드와 getAuthentication 메소드이다.

JwtProvider는 JWT의 생명주기(생성, 검증, 정보추출)를 관리하는 클리스이다.

private final UserDetailsServiceImpl userDetailsServiceImpl;

private Key secretKey = Keys.secretKeyFor(SignatureAlgorithm.HS256);

public JwtProvider(UserDetailsServiceImpl userDetailsServiceImpl) {
    this.userDetailsServiceImpl = userDetailsServiceImpl;
}

JwtProvider에 UserDetailsService가 필요한 이유는

토큰을 생성할 때
사용자를 검증하고 인증객체를 반환할 때

사용자의 디테일한 전체 정보(사용자가 활성화 상태인지, 계정이 잠겼는지, 권한이 있는지 등)을 UserDetailsService에서 가져올 수 있기 때문이다.

(1) 토큰 유효성 검사

 public boolean validateToken (String token) {
    try {
        Jwts.parserBuilder()
                .setSigningKey(secretKey)
                .build()
                .parseClaimsJws(token);
        return true;
    } catch (Exception e) {
        return false; // 만료되었거나 서명이 틀린 경우
    }
}

클라이언트가 가져온 토큰이 진짜인지, 유효기간이 지났는지 확인하는 메소드

setSigningKey(secretKey) : 우리가 만든 secretKey를 끼워 넣음
build() : JWT 파서(Parser) 생성
parseClaimsJws(token) : 토큰을 열어서 해석 시도

해석이 성공하면 유효한 토큰 = 즉 true를 내뱉고, 그렇지 않은 경우 false를 내뱉는다.

가장 중요한 점은 서버가 가지고 있는 secretKey와 토큰 뒤에 붙은 서명이 일치하는지를 확인하여 위변조를 방지하는 것.

(2) 인증 정보 추출(사용자 검증)

토큰이 유효하다면, 토큰 안에 적힌 사용자 ID(Subject)를 보고 DB에서 실제 정보를 가져와 시큐리티용 신분증을 만든다.

public Authentication getAuthentication (String token) {
    Claims claims = Jwts.parserBuilder()
            .setSigningKey(secretKey)
            .build()
            .parseClaimsJws(token)
            .getBody();
    UserDetails userDetails = userDetailsServiceImpl.loadUserByUsername(claims.getSubject());
    return new UsernamePasswordAuthenticationToken(userDetails, "", userDetails.getAuthorities());
}

Claims : 토큰 내부의 데이터(Claims)를 꺼냄
userDetaisServiceImple.loadUserByUsername(claims.getSubject()) : 토큰 주인(Subject)의 ID로 DB에서 사용자 정보를 로드함
new UsernamePasswordAuthenticationToken() : 스프링 시큐리티 내부에서 사용할 인증 객체(=신분증)를 생성하여 반환

3. JwtAuthenticationFilter

@RequiredArgsConstructor
public class JwtAuthenticationFilter extends OncePerRequestFilter {

    private final JwtProvider jwtProvider;

    /**
     * JWT 인증 Filter 처리 로직
     */
    @Override
    protected void doFilterInternal (
        @NonNull HttpServletRequest request,
        @NonNull HttpServletResponse response,
        @NonNull FilterChain filterChain
    ) throws ServletException, IOException {
        
        // 1. 요청 헤더에서 토큰 추출
        String accessToken = resolveToken(request);
        
        // 2. 토큰이 유효한지 검증
        if (accessToken != null && jwtProvider.validateToken(accessToken)) {
            // 토큰이 유효하다면 인증 객체를 가져와서 SecurityContext에 담음
            Authentication auth = jwtProvider.getAuthentication(accessToken);
            SecurityContextHolder.getContext().setAuthentication(auth);
        }
        
        // 3. 다음 필터로 넘김
        filterChain.doFilter(request, response);
    }

    // 헤더에서 "Bearer"를 제외한 실제 토큰만 꺼내는 메소드
    private String resolveToken(HttpServletRequest request) {
        String bearerToken = request.getHeader("Authorization");
        if (StringUtils.hasText(bearerToken) && bearerToken.startsWith("Bearer")) {
            return bearerToken.substring(7);
        }
        return null;
    }

}

resolveToken은 실제 토큰값을 꺼내는 메소드고, 진짜 핵심은 doFilterInternal부분이다.

OncePerRequestFilter 상속 : 사용자의 요청 한 번당 딱 한번만 실행되는 필터 라는 뜻. 요청이 내부적으로 다른 서블릿으로 포워딩되어도 인증 로직이 중복으로 실행되지 않게 보장한다.

@Override
protected void doFilterInternal (
    @NonNull HttpServletRequest request,
    @NonNull HttpServletResponse response,
    @NonNull FilterChain filterChain
) throws ServletException, IOException {

    // 1. 요청 헤더에서 토큰 추출
    String accessToken = resolveToken(request);

    // 2. 토큰이 유효한지 검증
    if (accessToken != null && jwtProvider.validateToken(accessToken)) {
        // 토큰이 유효하다면 인증 객체를 가져와서 SecurityContext에 담음
        Authentication auth = jwtProvider.getAuthentication(accessToken);
        SecurityContextHolder.getContext().setAuthentication(auth);
    }

    // 3. 다음 필터로 넘김
    filterChain.doFilter(request, response);
}

resolveToken : 클라이언트가 보낸 Http 헤더(Authorization: Bearer <토큰>)에서의 앞에 Bearer 글자를 떼어내고 순수 토큰값만 추출
validationToken(accessToken) : JwtProvider에게 이 토큰에 대한 검증을 요청함
getAuthentication(accessToken) : 토큰이 진짜라면 JwtProvider가 DB를 조회해 사용자 정보를 가져오고, 스프링 시큐리티용 신분증(=Authentication)을 만듦
SecurityContextHolder.getContext().setAuthetication(auth) : 서버의 임시 메모리(SecurityContext)에 이 신분증을 넣어둠. 이 과정을 통해 이 요청이 끝날 때까지 서버는 "인증된 사용자"라고 인식함
filterChain.doFilter() : 필터의 검증 후 다음 필터로 넘어가도록 요청을 넘김

참고! protected란?

같은 패키지에 있는 모든 클래스, 혹은 다른 패키지에 있더라도 해당 클래스를 상속받은 자식 클래스에서 사용할 수 있도록 접근을 허용하는 접근 제한자. 자세한건 여기 참조.

24.05.22 | 8일차 정리 - Object , Class | Notion

부자되게 해주세용

confirmed-clave-f2a.notion.site

참고! 패키지란?

= 폴더 단위.

예를 들어 com.dalmuri와 example.dalmuri는 서로 다른 패키지이다.

  java
 ├─   com.dalmuri
 │   └─ ...
 └─   example.dalmuri

그럼 com.dalmuri와 com.example은

  com
 ├─   dalmuri
 │   └─ ...
 └─   example
     └─ ...

com까진 같은 패키지로 공유하지만 그 뒤부턴 다른 패키지로 분류된다.

참고! 왜 no usage가 뜰까

저렇게 no usage가 뜨는 이유? 호출을 안하는데 사용이 되는거 같다...

호출의 주체가 '나'가 아닌 '프레임워크'이기 때문 : SecurityConfig에서 .addFilterBefore()라고 등록하면 Spring Security 프레잌워크가 내부적으로 필터 체인을 돌리면서 이 메소드를 대신 호출한다
리플렉션 기반 동작? : IntelliJ의 Usage추적 기능은 주로 소스 코드상에서 직접적으로 명시된 호출부를 찾는데, 프레임워크 내부 깊숙한 곳에서 일어나는 호출은 검색 결과에 잡히지 않는다.

// 헤더에서 "Bearer"를 제외한 실제 토큰만 꺼내는 메소드
private String resolveToken(HttpServletRequest request) {
    String bearerToken = request.getHeader("Authorization");
    if (StringUtils.hasText(bearerToken) && bearerToken.startsWith("Bearer")) {
        return bearerToken.substring(7);
    }
    return null;
}

클라이언트에서 토큰을 보낼 때 'Bearer dfkldfkdjkldlf...'이런식으로 보내도록 작성을 하였으므로 substring(7)을 통해 진짜 토큰값을 추출한다.

... 이 과정을 다 걸쳐서 통과해야 드디어 Controller에 갈 수 있다!

[참고 자료]

https://ittrue.tistory.com/129

[Java] 자바 패키지(Package)와 임포트(Import) 개념 정리 및 활용

패키지 (Package) 자바에서 패키지란 특정한 목적을 공유하는 클래스와 인터페이스의 묶음을 의미한다. 즉, 서로 관련 있는 클래스들을 묶어 효과적으로 관리하기 위해 사용한다. 자바의 패키지는

ittrue.tistory.com

Axios를 써보자

JanuDev — Tue, 6 Jan 2026 16:28:55 +0900

JWT 로그인 구현중 클라이언트로부터 서버로 request를 보낼 때 앞으로 무조건 header에 발급된 토큰값을 집어넣으라는데...

 const response = await fetch('http://localhost:3001/login', {
   method : 'POST',
   headers : {
     'Content-Type' : 'application/json',
     'Authorization' : 토큰어쩌구저쩌구
   },
   body : JSON.stringify(user)
 })

매번 이렇게 작성할 수 없는 노릇이라 찾아보니 Axios를 사용하라고 하신다.

Axios는 회사에서도 사용해봤는데 솔직히 무슨 뜻인진 잘 모르고 다른분들 다 쓰길래 나도 따라쓴 격이라 나도 이번에 제대로 공부해볼겸.. Axios에 대해 공부해본다.

Axios 공식 웹사이트는 여기

1. Axios란

브라우저와 Node.js에서 사용할수 있는 Promise 기반의 Http 클라이언트 라이브러리로

자바스크립트 내에서도 fetch API가 있지만

자동 파싱 : 서버로부터 받은 JSON 데이터를 자동으로 JavaScript객체로 변환시킴(JSON.parse 안해도 됨)
요청, 응답을 중간에 가로챔(Interceptor)

의 이유로 정말 많이 쓰인다.

사실 나도 Jwt 토큰을 집어넣기 위해서라도 request때 인터셉트가 필요하다...

2. 구조

1. request 구조

{
  method: 'get',	// 필수
  url: '/example',     // 필수
  baseURL: '',
  haeaders: {},
  params: {},
  data: {},
  timeout: 0
}

우리가 메소드로 나눠쓸 뿐 하나의 객체로 정리된다.

가장 대표적인 4개의 메소드로 작성해보자.

1️⃣Get

axios.get(url, config)

이렇게 쓸 수 있다.

axios.get('/users', {
  params: { page: 1 },
  headers: {
    Authorization: 'Bearer 토큰'
  }
})

이렇게 작성하면, request객체는

{
  method: 'get',
  url: '/users',
  params: { page: 1 },
  headers: { Authorization: 'Bearer 토큰' }
}

이렇게 정리된다.

2️⃣Post

axios.post(url, data 객체, config)

로 쓰인다.

axios.post(
  '/login',
  { id: 'admin', pw: '1234' },
  { timeout: 3000 }
)

이렇게 작성하면

{
  method: 'post',
  url: '/login',
  data: { id: 'admin', pw: '1234' },
  timeout: 3000
}

이런식으로 내부구조가 잡혀진다.

3️⃣Delete

axios.delete(url, config)

Delete는 원래 data 자리가 없기 때문에 작성하고 싶으면 다음과 같이 써야 한다.

axios.delete('/example', {
  data : { reason: '탈퇴' }
}

4️⃣Put

axios.put(url, data, config)

위와 동일하다!

2. .then(), catch.(), finally.()

request를 보낸 뒤 성공/실패/항상 실행 여부에 따라 뒤에 .then(), .catch(), .finally()를 덧붙힐 수 있다.

axios.post('/example', {
  name: 'Fred',
  last: 'Flintstone',
})
.then (function (response){
  // 성공 핸들링
  console.log(response)
})
.catch (function (error){
  // 에러 핸들링
  console.log(error)
})
.finally(function (){
  // 항상 실행되는 영역
})

1️⃣.then() — 성공했을 때

요청&응답이 성공했을 때 실행할 함수를 작성하는 영역. 성공한 Promise만 받는다.

2️⃣.catch() — 실패했을 때

요청&응답이 실패했을 때 실행할 함수를 작성하는 영역. 실패한 Promise만 받는다.

error = {
  message: '',
  response: {
    status: 404,
    data: {},
    headers: {}
  }
}

에러 객체는 다음과 같이 생겼는데, 그래서

.catch(error => {
  console.log(error.response.status)
  console.log(error.response.data)
})

이런식으로 작성할 수 있겠다.

3️⃣finally — 성공이든 실패든 무조건

finally의 용도는

로딩 종료
버튼 다시 활성화
스피너 끄기

와 같이 결과와 상관 없이 실행할 때 정리하는 담당을 한다.

3. response 구조

response = {
  data: 서버가 준 실제 데이터 
  status: 200,
  headers: {},
  config: 내가 보낸 설정,
}

response 객체는 서버에서 가져온 데이터를 화면에 뿌리거나 상황을 확인하는 용도의 정보들이 담겨 있다.

4. Axios 인스턴스 - 공통

Axios를 사용하기 위해선 공통 인스턴스에 대한 기본 설정이 필요하다.

const apiInstance = axios.create({
  baseURL: '요청 보낼 백단의 URL',
  timeout: 30000, // 밀리세컨초 기준
})

왜냐면 단순히 api.get('/example')로 사용할 수도 있지만 매번 반복하기엔 관리가 너무 불편하고 비효율적이다.

모든 요청마다 전체 url을 작성해야 함
서버 주소가 바뀌면 모든 코드를 수정해야 함
공통적인 헤더(인증 토큰 등)를 매번 설정해야 함

인스턴스를 만들어야 공통설정을 한 곳에 모아두고 재사용할 수 있다.

1️⃣axios.create()

나만의 커스텀된 Axios 객체. 새로운 axios 인스턴스 생성할 때 사용한다.
인스턴스 설정 파일 한곳에 작성하면 여러 컴포넌트에서 사용할 수 있다.

2️⃣baseURL

모든 API 요청 앞에 붙는 주소
실제 호출될 땐 apiInstance.get('/example')과 같이 상대 경로만 적으면 된다.

3️⃣timeout

요청을 보낸 후 서버로부터 응답이 올 때 까지 기다리는 최대 시간(밀리초 단위)
서버에 문제가 생겨 응답이 오지 않을 때 무한적 기다리지 않고 연결을 끊어 브라우저의 리소스를 보호한다(30000 = 30초)

5. Axios 인스턴스 - 인터셉터

요청을 보내기 직전 혹은 응답을 받은 직후에 특정 로직을 실행할 수 있다.

apiInstance.interceptors.request.use((config) => {
  const token = localStorage.getItem('accessToken')
  if (token) {
    config.headers.Authorization = `Bearer ${token}`
  }
  return config
}, (error) => Promise.reject(error))

apiInstance : 위에서 만든 커스텀 axios(axios.create()로 생성된 커스텀 axios)
interceptors : 요청/응답 흐름 중간에 끼어듦
request : 요청단계, 즉 서버로 날아가기 직전에 실행한다는 의미 (↔ interceptors.response)
use : '이 가로채기 규칙을 등록한다'는 뜻. 함수를 Axios에 맡기는 행위
localStorage.getItem('accessToken') : 기존 로직에서 로컬스토리지에 저장했던 accessToken을 가져옴. 이 토큰은 jwt에서 발급
config.header.Authorization : 요청 헤더의 Authorization 항목에 'Bearer 토큰값'을 작성 axios 구현 이유
return config : 설정이 완료된 config를 반환 - 실제 요청이 서버로 출발
Promise.reject(error) : 에러 발생 시 Promoise.reject로 반환

위 인터셉트를 통해 서버로 가는 모든 클라이언트 요청에 토큰 인증값을 넣을 수 있다!

[참고 자료]

https://axios-http.com/kr/docs/example

기본 예제 | Axios Docs

기본 예제 Axios를 사용하기 위한 기본 예제 참고: CommonJS 사용법 require()를 이용한 CommonJS를 사용하는 동안 TypeScript 타이핑(인텔리센스 / 자동 완성)을 사용하려면, 다음 방법을 쓰세요. const axios = r

axios-http.com

https://velog.io/@shin6403/React-axios%EB%9E%80-feat.-Fetch-API

[React] axios란? (feat. Fetch API)

# Intro 리액트는 효율적인 UI 구현을 위한 라이브러리이다. HTTP Client(HTTP 상에서 커뮤니케이션을 하는 자바 기반 컴포넌트)를 내장하고 있는 Angular와는 다르게, 리액트는 따로 내장 클래스가 존재

velog.io

https://chihoya.tistory.com/28

Ajax, Axios란??

Ajax Asynchronous Javascript and XML(비동기식 자바스크립트와 xml)의 약자이다. 서버와 비동기적으로 데이터 주고받는 JS기술을 의미한다. Ajax를 이해하기 위해선 Server를 알아야한다. 왜? Ajax는 서버랑 통

chihoya.tistory.com

[Spring] JWT 이용해서 로그인 기능 만들기

JanuDev — Wed, 31 Dec 2025 16:30:12 +0900

JWT = 양파

자꾸 공부하면 공부할수록 뭔 양파마냥 알아야 할게 자꾸 나온다.. 미쳐버릴지경

어떻게 구현할거냐면

사용자 검증 UserDetailsService
비밀번호 비교 PasswordEncoder
Authentication 객체 생성
JWT 발급
클라이언트에 토큰 전달
Filter 구현

순서대로 작성할 예정이다.

작성 순서

@Service
@RequiredArgsConstructor
@Slf4j
public class AuthService {

    private final AuthenticateHandler authenticateHandler;
    private final JwtProvider jwtProvider;
    private final UserDetailsServiceImpl userDetailsServiceImpl;

    public TokenDTO login(LoginRequestDTO request) {
        PasswordEncoder passwordEncoder = new BCryptPasswordEncoder();

        /*
        * (1) 사용자 검증(UserDetailsService)
        * */
        UserDetailsDTO userDetails = (UserDetailsDTO) userDetailsServiceImpl.loadUserByUsername(request.getUserId());

        /*
        * (2) 비밀번호 비교(PasswordEncoder)
        * */
        if (!passwordEncoder.matches(request.getPassword(), userDetails.getPassword())) {
            throw new BadCredentialsException("비밀번호가 일치하지 않아!(T_T)");
        }

        /*
        * (3) Authentication 객체 생성
        * */
        Authentication authentication = authenticateHandler.authenticate(request);

        // (4) JWT 발급
        String accessToken = jwtProvider.createAccessToken(authentication);

        // (5) 클라이언트에 토큰 전달
        return new TokenDTO(accessToken);
    }

}

1. 사용자 검증

DB에서 유저 정보를 조회하고 UserDetails 객체를 만든다. ex) 이 username을 가진 유저가 있나요? → UserDetailsImpl 만들어서 스프링 시큐리티에 제공한다.

로그인은 2단계로 이루어지는데, 첫번째는 사용자 검증(Authentication 준비), 두번째는 비밀번호 검증(Authentication 완료) 단계이다.

사용자 검증은 "너가 누군지", 즉 이 userId를 가진 사람이 실제로 존재하는지, 그리고 DB에 등록된 사용자인지 검증을 한다.

비밀번호 검증은 "진짜 너가 맞는지"를 확인하는 단계이다.

이 2단계가 섞이면 위험하기 때문에 시큐리티는 일부러 나눠놨다.

역할	책임
UserDetailsService	이 사용자가 존재하는지
UserDetails	이 사용자의 정보는 무엇인지
AuthenticationProvider	비밀번호가 맞는지
SecurityContext	로그인 완료 후 상태 저장

그리하여 사용자 검증 단계에선

❌ 로그인 성공 처리 안 함
❌ 세션/JWT 안 만듦
⭕ “이 사람이 누구인지 설명서만 전달”

를 처리하면 된다.

코드에 대한 설명은 너무 길어져서 따로 분리했다.

2. 비밀번호 비교

입력한 비밀번호를 암호화했을 때 DB의 암호값고 동일한지 확인한다.

사실 이 과정은 Authentication 과정이 있으면 굳이 필요하진 않다고 하는데.. 그냥 공부차 작성한다.

PasswordEncoder passwordEncoder = new BCryptPasswordEncoder();

if (!passwordEncoder.matches(request.getPassword(), userDetails.getPassword())) {
  throw new BadCredentialsException("비밀번호가 일치하지 않아!");
}

(1) PasswordEncoder

비밀번호를 안전하게 암호화하고, 입력된 비밀번호와 저장된 암호회된 비밀번호를 비교하는 인터페이스

public interface PasswordEncoder {
	
　　// 비밀번호를 단방향 암호화
　　String encode(CharSequence rawPassword);
	
　　// 암호화되지 않은 비밀번호(raw-)와 암호화된 비밀번호(encoded-)가 일치하는지 비교
　　boolean matches(CharSequence rawPassword, String encodedPassword);
	
　　// 암호화된 비밀번호를 다시 암호화하고자 할 경우 true를 return하게 설정
　　default boolean upgradeEncoding(String encodedPassword) { return false; };
}

이런식으로 구성되어 있고, PasswordEncoder 구현 클래스는 4개가 있다.

BcryptPasswordEncoder : BCrypt 해시 함수를 사용하여 비밀번호를 암호화
Argon2PasswordEncoder: Argon2 해시 함수를 사용해 비밀번호를 암호화
Pbkdf2PasswordEncoder : PBKDF2 해시 함수를 사용하여 비밀번호를 암호화
SCryptPasswordEncoder : SCrypt 해시 함수를 사용해서 비밀번호 암호화

여기서 BCryptPasswordEncoder를 이용했다. 단순한 해싱이 아닌 솔트(Salt)라는 렌덤 데이터를 추가하여 보안성을 높인다. 동일한 비밀번호도 암호화에 따라 결과값이 달라지기 때문에 원래 비밀번호를 알아내기 매우 어렵다.

(2) matches(평문, 암호문)

저장된 암호문(userDetails.getPassword())에서 사용됬던 솔트(Salt)값을 추출한다. 추출된 솔트와 입력받은 평문 비밀번호를 결합하여 다시 해싱한 후, 그 결과가 저장된 암호문과 같은지 확인한다.

(3) BadCredentialsException

Spring Security에서 제공하는 표준 예외로, 자격증명(id/pw)이 유효하지 않을 때 발생한다. 사용자의 id에 해당하는 패스워드가 일치하지 않을 때, 사용자의 아이디가 전달되지 않을 때 등등!

이 예외가 발생하면 보통 Spring Security의 인증 필터가 이를 가로채서 로그인 실패 페이지로 리다이렉트하거나, 401 unauthorized 에러 응답을 보내게 된다

3. Authentication 객체 생성

private final AuthenticateHandler authenticateHandler;
Authentication authentication = authenticateHandler.authenticate(request);

Authentication 객체를 생성하는 과정은 "이 사용자가 정말 우리 회원이 맞는지 시스템적으로 최종 승인 도장을 찍는 과정"이라고 생각하면 된다.

Authentication 객체란?

Spring Security에서 Authentication은 현재 로그인한 사용자의 신원 보증서이다.

Principal: 사용자의 아이디 혹은 사용자 객체
Credentials: 비밀번호(인증에 사용된 증거)
Authorities: 사용자가 가진 권한
Authenticated: 인증 여부(T/F)

(1) AuthenticationManager 수동 생성

@Bean
public AuthenticationManager authenticationManager() throws Exception {
  return authenticationConfiguration.getAuthenticationManager();
}

AuthenticationManager은 "인증 센터의 총책임자"이다. 말 그대로 인증(Authentication)을 처리하는 관리자인데, 사용자가 로그인을 시도하면 그 정보가 맞는지 확인한다.

예전 Spring Security는 WebSecurityConfigurerAdapter이라는걸 상속받으면 자동으로 AuthenticationManager을 생성해줬는데, 요즘은(5.7버전 이상)은 컴포넌트 기반 설정으로 바뀌면서 보안상의 이유로 자동 Bean 생성은 안해주고 개발자가 명시해야 한다고 한다.............

그래서 Bean으로 등록을 해줬다.

AuthenticationConfiguration : 스프링이 내부적으로 만들어둔 인증 설정 정보
.getAuthenticationManager() : 이미 설정된 정보(UserDetailsService, PasswordEncoder 등)를 바탕으로 완성한 "총책임자(Manager)"를 꺼내오는 과정

(2) AuthenticationHandler

@Service  
@Slf4j
@RequiredArgsConstructor
public class AuthenticateHandler {

    private final AuthenticationManager authenticationManager;

    public Authentication authenticate (LoginRequestDTO request) {
        try {
            return authenticationManager.authenticate(
                    new UsernamePasswordAuthenticationToken(
                            request.getUserId(),
                            request.getPassword()
                    )
            );
        } catch (BadCredentialsException e) {
            log.warn("인증 실패 - 사용자: {} (잘못된 비밀번호)", request.getUserId());
            throw e;
        } catch (UsernameNotFoundException e) {
            log.warn("인증 실패 - 사용자: {} (존재하지 않는 계정)", request.getUserId());
            throw e;
        } catch (Exception e) {
            log.error("인증 중 오류 발생 - 사용자: {}", request.getUserId(), e);
            throw e;
        }

    } // authenticate

}

1️⃣ UsernamePasswordAuthenticationToken() 생성

사용자가 보낸 아이디와 비밀번호를 담은 인증 요청용 토큰을 먼저 만든다.

이때는 아직 검증되지 않았기 때문에 setAuthenticated(false) 상태인 일종의 로그인 신청서와같다.

2️⃣ AuthenticationManager.authenticate() 호출

이 "신청서"를 AuthenticationManager에게 전달한다.

관리자는 내부적으로 등록된 AuthenticationProvider들을 찾아 이 아이디와 비밀번호가 진짜 맞는지 확인한다.

3️⃣ 최종 Authentication 객체 반환(인증 완료)

내부 검증(비밀번호 비교 등)이 성공하면, 사용자의 권한(Roles)과 상세 정보가 포함된 새로운 Authentication 객체를 반환한다.

이 객체는 setAuthenticatted(true)상태이며, 이제 시스템 어디서든 "이 사람은 믿을 수 있는 사용자다" 라고 인정받게 된다.

4. JWT 발급

@Component
public class JwtProvider {

    private Long ACCESS_TOKEN;

    private Key secretKey = Keys.secretKeyFor(SignatureAlgorithm.HS256);

    public String createAccessToken (Authentication authentication) {

        UserDetailsDTO principal = (UserDetailsDTO) authentication.getPrincipal();
        String userId = principal.getUserId();
        List<String> roles = principal.getAuthorities().stream().map(GrantedAuthority::getAuthority).toList();

        Date now = new Date();
        Date expiry = new Date(now.getTime() + ACCESS_TOKEN);

        return Jwts.builder()
                .setSubject(userId)
                .claim("role", roles)
                .setIssuedAt(now)
                .setExpiration(expiry)
                .signWith(secretKey, SignatureAlgorithm.HS256)
                .compact();

    }

}

createAccessToken : 새로운 토큰을 생성하는 메소드

ACCESS_TOKEN : application.yml 혹은 properties에서 설정된 만료시간 값을 가져온다
secretKey : 서명(Signature)을 위한 키. HS256알고리즘에 적합한 안전 키를 자동으로 생성.
Keys.secretKeyFor는 서버가 재시작될 때 마다 새로운 키를 생성한다.

(1) 사용자 정보 추출(Payload 준비)

authentication.getPrincipal() : 앞선 단계에서 생성했던 인증 객체에서 사용자 상세정보를 꺼냄(UserDetailsDTO). 토큰 내부에 저장할 사용자 ID와 권한목록을 준비

(2) JWT 토큰 생성

setSubject : 토큰의 식별자. 보통 사용자 고유 아이디를 넣음
claim("role", roles) : 표준 필드 외에 개발자가 추가하고 싶은 정보를 넣음
setIssuedAt(now) : 토큰 발행 시간
setExpiration(expiry) : 토큰 만료 시간
signWith(secretKey, SignatureAlgorithm.HS256) : 암호화 서명. 준비한 secretKey와 HS256알고리즘을 사용해 토큰이 위조되지 않음을 증명하는 서명. 가장 중요한 보안 단계
compact() : 모든 설정을 마치고 최종적으로 header.payload.signature 형태의 긴 문자열을 반환

5. 클라이언트에 토큰 전달

return new TokenDTO(accessToken);

6. Filter 구현

이것도 설명 길어질 것 같아서 따로 게시글 만들었다.

만났던 오류 사항

1. java.lang.StackOverflowError

메소드 호출이 너무 깊어져서 스택 메모리가 가득 찼을 때 발생하는 에러이다.

at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:216) ~[spring-aop-6.1.10.jar:6.1.10]
	at jdk.proxy3/jdk.proxy3.$Proxy69.authenticate(Unknown Source) ~[na:na]
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) ~[na:na]
	at java.base/java.lang.reflect.Method.invoke(Method.java:580) ~[na:na]

이게 무한반복되는걸 확인했다.

AuthenticateHandler와 같이 Authentication과 관련된 과정에서 무언가가 무한반복해서 호출하는거라는건 어림짐작 할 수 있었다.

Spring AOP 프록시와 관련된 재귀문제라고 한다.

GPT의 추가설명

1. 프록시 객체 ($Proxy69)

$Proxy69.authenticate는 @Service나 @Component와 같은 Spring Bean에 트랜잭션(@Transactional)이나 보안(AOP)과 같은 부가 기능이 적용될 때, **Spring이 원본 객체 대신 생성하여 주입하는 대리 객체(Proxy)**입니다.
당신의 코드에서는 AuthenticationManager 빈이 이 프록시 객체로 주입된 것입니다.

2. 프록시의 invoke

JdkDynamicAopProxy.invoke는 이 프록시 객체의 메서드(여기서는 authenticate)가 호출될 때 항상 먼저 실행되는 Spring AOP의 핵심 로직입니다. 이 로직은 부가 기능을 처리한 후 원본 객체의 메서드를 호출합니다.

3. 무한 재귀 (Stack Overflow)

StackOverflowError가 발생했다는 것은 다음과 같은 순환 호출 구조가 발생했다는 의미입니다.

시작: AuthService (또는 외부) $\rightarrow$ 프록시 AuthenticationManager의 authenticate() 호출
프록시: JdkDynamicAopProxy.invoke 실행
문제: invoke 로직이 **원본 AuthenticationManager**를 호출하는 대신, 어떤 경로를 통해 다시 1번 단계로 돌아가 프록시 객체의 authenticate()를 재호출합니다.

이 무한 루프의 원인은 앞선 답변에서 설명드렸듯이, AuthenticationManager 빈을 정의하는 과정(SecurityConfig)과 이를 사용하는 커스텀 인증 로직(AuthenticateHandler 또는 AuthService) 간의 의존성 주입(DI) 충돌이나 설정의 중복 때문입니다.

결론 :

오류 발생 지점은 AuthenticationManager의 authenticate()의 호출 과정

원인은 Spring Security의 설정과 커스텀 로직 간의 순환 참조(Circular Dependency)

DB에서 직접 사용자정보 조회(getUserDetails)
비밀번호를 직접 비교(passwordEncoder.matches)
authenticatHandler.authenticate(request)를 통해 다시 인증 시도
즉, 로그인 로직 안에서 Spring Security의 인증을 '수동' + '자동'으로 동시에 돌리면서 인증 과정이 자기 자신을 계속 호출하여 stackOverflow 발생 (길어져서 접은글 작성)

authenticateHandler.authenticate() 안에서 무슨 일이 일어났나?

AuthenticateHandler는 내부에서 보통 이런 걸 하고 있어:

authenticationManager.authenticate(authenticationToken);

즉, Spring Security의 표준 인증 프로세스(AuthenticationManager) 를 다시 호출함

Spring Security는 이 인증을 어떻게 처리하나?

Spring Security는 인증을 시작하면:

AuthenticationManager 실행
AuthenticationProvider 호출
UserDetailsService.loadUserByUsername() 호출
(AOP / Filter / Security 설정에 따라)
커스텀 로그인 로직(AuthService.login())을 다시 타게 됨

그래서 무슨 일이 벌어졌나? (무한 루프)

AuthService.login()
 └ authenticateHandler.authenticate()
     └ AuthenticationManager.authenticate()
         └ Spring Security 인증 시작
             └ AuthService.login() 다시 호출
                 └ authenticateHandler.authenticate()
                     └ AuthenticationManager.authenticate()
                         └ ...

끝없는 회전목마
➡️ StackOverflowError 발생

문제를 해결하기 위해선 AuthenticationManager을 사용하지 않고, 이미 코드에선 직접 비밀번호 검증을 하고 있기때문에 인증 객체를 수동으로 생성하라고 하는데...

public class AuthService {

    private final JdbcTemplate jdbcTemplate;
    private final AuthenticateHandler authenticateHandler;
    private final JwtProvider jwtProvider;

    public TokenDTO login(LoginRequestDTO request) {
        PasswordEncoder passwordEncoder = new BCryptPasswordEncoder();
        UserDetailsImpl userDetails = getUserDetails(request);

      if (!passwordEncoder.matches(request.getPassword(), userDetails.getPassword())) {
           // 비밀번호가 일치하지 않다면
           throw new BadCredentialsException("비밀번호가 일치하지 않아!(T_T)");
        }
        Authentication authentication = authenticateHandler.authenticate(request);
        String accessToken = jwtProvider.createAccessToken(authentication);
        return new TokenDTO(accessToken);
    }

근데 난 공부중이므로 AuthenticationManager을 사용해보고 싶다.

1️⃣ UserDetailsService 구현 클래스 생성

@Service
@RequiredArgsConstructor
@Slf4j
public class UserDetailsServiceImpl implements UserDetailsService {

    public final JdbcTemplate jdbcTemplate;

    @Override
    public UserDetails loadUserByUsername(String userId) {
        String sql = "SELECT * FROM dalmuri.\"USER\" WHERE \"USER_ID\" = ?"; // 여기 에러는 무시 가능
        UserDetailsImplDTO userImpl = new UserDetailsImplDTO();

        try {
            UserDTO user = jdbcTemplate.queryForObject(
                    sql,
                    new Object[]{userId},
                    (rs, rowNum) -> {   // Mapper
                        UserDTO u = new UserDTO();
                        u.setUserCd(rs.getString("USER_CD"));
                        u.setUserId(rs.getString("USER_ID"));
                        u.setUserNm(rs.getString("USER_NM"));
                        u.setPassword(rs.getString("PASSWORD"));
                        u.setBgColor(rs.getString("BG_COLOR"));
                        u.setTextColor(rs.getString("TEXT_COLOR"));
                        u.setInsertDatetime(rs.getString("INSERT_DATETIME"));
                        return u;
                    }
            );
            if (user == null) {
                throw new UsernameNotFoundException("사용자 정보 없음: " + userId);
            }
            userImpl.setUserCd(user.getUserCd());
            userImpl.setUserId(user.getUserId());
            userImpl.setUserNm(user.getUserNm());
            userImpl.setPassword(user.getPassword());
            userImpl.setBgColor(user.getBgColor());
            userImpl.setTextColor(user.getTextColor());
            userImpl.setInsertDatetime(user.getInsertDatetime());
            return userImpl;
        } catch (Exception e) {
            e.printStackTrace();
            throw new UsernameNotFoundException("사용자 정보 없음: " + userId);
        }
    }
}

그리고 기존 AuthService.java에 있던 DB호출로직은 삭제

//    private UserDetailsImpl getUserDetails (LoginRequestDTO request) {
//        String sql = "SELECT * FROM dalmuri.\"USER\" WHERE \"USER_ID\" = ?"; // 여기 에러는 무시 가능
//
//        User user = jdbcTemplate.queryForObject(
//                sql,
//                new Object[]{request.getUserId()},
//                (rs, rowNum) -> {   // Mapper
//                    User u = new User();
//                    u.setUserCd(rs.getString("USER_CD"));
//                    u.setUserId(rs.getString("USER_ID"));
//                    u.setUserNm(rs.getString("USER_NM"));
//                    u.setPassword(rs.getString("PASSWORD"));
//                    u.setBgColor(rs.getString("BG_COLOR"));
//                    u.setTextColor(rs.getString("TEXT_COLOR"));
//                    u.setInsertDatetime(rs.getString("INSERT_DATETIME"));
//                    return u;
//                }
//        );
//
//        if (user == null) {
//            throw new UsernameNotFoundException("사용자 정보 없음: " + request.getUserId());
//        }
//
//        return new UserDetailsImpl(user);
//    }

왜 삭제하냐면, AuthService에서 같이 생성했기 때문에 getUserDetails 메소드는 UserDetailsService 인터페이스를 상속받지 않는다(AuthService가 UserDetailsService를 상속받지 않음)

2️⃣ User을 UserDetails로 변환

@Getter
@Setter
@ToString
public class UserDetailsDTO implements UserDetails {

    private String userCd;
    private String userId;
    private String userNm;
    private String password;

    private String bgColor;
    private String textColor;
    private String insertDatetime;

    /*
    * 1. Lombok 어노테이션을 사용해도 UserDetails에서 요구하는 인터페이스는 직접 작성해야 한다.
    * */

    private final String role = "ROLE_USER";

    @Override
    public String getUsername() {
        return userId;
    }

    @Override
    public String getPassword() {
        return password;
    }

    @Override
    public Collection<? extends GrantedAuthority> getAuthorities() {
        // 고정 반환
        return List.of(new SimpleGrantedAuthority(this.role));
    }

    /**
     * 형식적인 요소들 : true로 고정
     * */
    @Override
    public boolean isAccountNonExpired() {
        return true;
    }

    @Override
    public boolean isAccountNonLocked() {
        return true;
    }

    @Override
    public boolean isCredentialsNonExpired() {
        return true;
    }

    @Override
    public boolean isEnabled() {
        return true;
    }

}

기존에 만들었던 UserDTO

@Getter
@Setter
@ToString
@NoArgsConstructor
@AllArgsConstructor
public class UserDTO {

    private String userCd;
    private String userId;
    private String userNm;
    private String password;

    // 있으나 없으나
    private String bgColor;
    private String textColor;
    private String insertDatetime;

}

3️⃣ AuthService.java 로직 수정

기존 로직

public class AuthService {

    private final JdbcTemplate jdbcTemplate;
    private final AuthenticateHandler authenticateHandler;
    private final JwtProvider jwtProvider;

    public TokenDTO login(LoginRequestDTO request) {
        PasswordEncoder passwordEncoder = new BCryptPasswordEncoder();

        UserDetailsImpl userDetails = getUserDetails(request);

        if (!passwordEncoder.matches(request.getPassword(), userDetails.getPassword())) {
            // 비밀번호가 일치하지 않다면
            throw new BadCredentialsException("비밀번호가 일치하지 않아!(T_T)");
        }

        Authentication authentication = authenticateHandler.authenticate(request);

        String accessToken = jwtProvider.createAccessToken(authentication);

        return new TokenDTO(accessToken);
    }

    private UserDetailsImpl getUserDetails (LoginRequestDTO request) {
        String sql = "SELECT * FROM dalmuri.\"USER\" WHERE \"USER_ID\" = ?"; // 여기 에러는 무시 가능
        User user = jdbcTemplate.queryForObject(
                sql,
                new Object[]{request.getUserId()},
                (rs, rowNum) -> {   // Mapper
                    User u = new User();
                    u.setUserCd(rs.getString("USER_CD"));
                    u.setUserId(rs.getString("USER_ID"));
                    u.setUserNm(rs.getString("USER_NM"));
                    u.setPassword(rs.getString("PASSWORD"));
                    u.setBgColor(rs.getString("BG_COLOR"));
                    u.setTextColor(rs.getString("TEXT_COLOR"));
                    u.setInsertDatetime(rs.getString("INSERT_DATETIME"));
                    return u;
                }
        );

        if (user == null) {
            throw new UsernameNotFoundException("사용자 정보 없음: " + request.getUserId());
        }

        return new UserDetailsImpl(user);
    }

}

새로 고친 로직

@Service
@RequiredArgsConstructor
@Slf4j
public class AuthService {

    private final AuthenticateHandler authenticateHandler;
    private final JwtProvider jwtProvider;
    private final UserDetailsServiceImpl userDetailsServiceImpl;

    public TokenDTO login(LoginRequestDTO request) {
        PasswordEncoder passwordEncoder = new BCryptPasswordEncoder();

        UserDetailsDTO userDetails = (UserDetailsDTO) userDetailsServiceImpl.loadUserByUsername(request.getUserId());

        if (!passwordEncoder.matches(request.getPassword(), userDetails.getPassword())) {
            // 비밀번호가 일치하지 않다면
            throw new BadCredentialsException("비밀번호가 일치하지 않아!(T_T)");
        }

        Authentication authentication = authenticateHandler.authenticate(request);

        String accessToken = jwtProvider.createAccessToken(authentication);

        return new TokenDTO(accessToken);
    }

[참고 자료]

https://velog.io/@corgi/Spring-Security-PasswordEncoder%EB%9E%80-4kkyw8gi

[Spring Security] PasswordEncoder란?

Spring Security 5.3.3 버전에서 지원하는 PasswordEncoder에 대해 간략히 알아봅니다.

velog.io

https://coding-start.tistory.com/153

Spring boot - Spring Security(스프링 시큐리티) 란? 완전 해결!

오늘 포스팅할 내용은 Spring Security이다. 사실 필자는 머리가 나빠서 그런지 모르겠지만, 아무리 구글링을 통해 스프링 시큐리티를 검색해도 이렇다할 명쾌한 해답을 얻지 못했다. 대부분 이론적

coding-start.tistory.com

[Spring] JWT 이용해서 로그인 기능 만들기 - 사용자 검증

JanuDev — Wed, 31 Dec 2025 10:07:50 +0900

너무 길어져서 설명 따로 분리한다.

@Service
@RequiredArgsConstructor
@Slf4j
public class AuthService {

    private final AuthenticateHandler authenticateHandler;
    private final JwtProvider jwtProvider;
    private final UserDetailsServiceImpl userDetailsServiceImpl;

    public TokenDTO login(LoginRequestDTO request) {
        PasswordEncoder passwordEncoder = new BCryptPasswordEncoder();

        /*
        * (1) 사용자 검증(UserDetailsService)
        * */
        UserDetailsDTO userDetails = (UserDetailsDTO) userDetailsServiceImpl.loadUserByUsername(request.getUserId());

        /*
        * (2) 비밀번호 비교(PasswordEncoder)
        * */
        if (!passwordEncoder.matches(request.getPassword(), userDetails.getPassword())) {
            throw new BadCredentialsException("비밀번호가 일치하지 않아!(T_T)");
        }

        /*
        * (3) Authentication 객체 생성
        * */
        Authentication authentication = authenticateHandler.authenticate(request);

        // (4) JWT 발급
        String accessToken = jwtProvider.createAccessToken(authentication);

        // (5) 클라이언트에 토큰 전달
        return new TokenDTO(accessToken);
    }

}

여기서 첫번째 순서 설명!

UserDetailsDTO userDetails = (UserDetailsDTO) userDetailsServiceImpl.loadUserByUsername(request.getUserId());

(1) UserDetailsDTO

DB에서 꺼낸 데이터는 일반적으로 날것 그대로의 정보이다.

그래서 USER 테이블 = 현실 세계의 사용자 데이터이다.

반면에

UserDetails = 스프링 시큐리티가 이해하는 '인증용 인간'이다.

DB → UserDTO (그냥 데이터)
UserDTO → UserDetailsDTO (인증용 객체)

그리고 UserDetailsDTO는 UserDetails 인터페이스를 가져와서 구현하기 때문에 어차피 UserDTO와 합쳐서 사용하진 못한다.

@Getter
@Setter
@ToString
public class UserDetailsDTO implements UserDetails {

    private String userCd;
    private String userId;
    private String userNm;
    private String password;

    // 있으나 없으나
    private String bgColor;
    private String textColor;
    private String insertDatetime;

    /*
    * 1. Lombok 어노테이션을 사용해도 UserDetails에서 요구하는 인터페이스는 직접 작성해야 한다.
    * */

    private final String role = "ROLE_USER";

    @Override
    public String getUsername() {
        return userId;
    }

    @Override
    public String getPassword() {
        return password;
    }

    @Override
    public Collection<? extends GrantedAuthority> getAuthorities() {
        // 고정 반환
        return List.of(new SimpleGrantedAuthority(this.role));
    }

    /**
     * 형식적인 요소들 : true로 고정
     * */
    @Override
    public boolean isAccountNonExpired() {
        return true;
    }

    @Override
    public boolean isAccountNonLocked() {
        return true;
    }

    @Override
    public boolean isCredentialsNonExpired() {
        return true;
    }

    @Override
    public boolean isEnabled() {
        return true;
    }

}

1️⃣ public class UserDetailsDTO implements UserDetails

UserDetails는 Spring Security가 사용자 정보를 다루기 위해 강제로 요구하는 인터페이스이다.

이 인터페이스를 구현했다는건 “이 객체는 로그인한 사용자로 써도 된다”는 뜻.

기존의 UserDTO와 분리한 이유.

2️⃣ 필드부 작성

보안에 직접 관여하는건 아니지만 각 프로젝트별로 필요한 User의 정보를 작성한다.

3️⃣ 권한(role) 설계 - private final String role = "ROLE_USER"

Spring Security는 권한 이름이 반드시 ROLE_로 시작해야 한다.

USER ❌
ROLE_USER ⭕️

지금 내 프로젝트의 경우 권한은 딱히 없어서... 그냥 ROLE_USER로 박아뒀다. 나중에 필요하면 바뀔수도...? 아직은 계획x

4️⃣ 핵심 메소드

getUsername() : Spring Security가 "이 사용자의 아이디가 무엇인가" 라고 물을 때 호출된다. 보통 userId를 반환하는게 정석(정답은 아님~)
getPassword() : DB에서 저장된 암호화된 비밀번호를 가져온다. 인증 과정에서 PasswordEncoder.matches()에 사용됨
getAuthorities() : "이 사용자의 권한을 정의"
- GrantedAuthority : 권한 인터페이스
- SimpleGrantedAuthority : 가장 기본의 구현체

5️⃣ 계정 상태 관련 메소드

보통 형식적인 요소들이기 때문에 true로 고정한다.

public boolean isAccountNonExpired() { return true; } : 계정 만료 여부
public boolean isAccountNonLocked() { return true; } : 계정 잠김 여부. 로그인 실패 5회 정책만들 때 사용
public boolean isCredentialsNonExpired() { return true; } : 비밀번호 만료 여부. 90일마다 변경 정책 때 사용
public boolean isEnabled() { return true; } : 계정 활성화 여부. 탈퇴, 휴면 계정 처리할 때 사용

저런거 만들면 좋긴 한데.. 내 프로젝트는 제약이 없는 후리(?)한 스타일을 추구하기 때문에 따로 구현하진 않았다.

누가 장난질하면 나중에라도 개발을 할려나..?

(2) UserDetailsServiceImpl

지피티의 고견으로는 이 부분이 Spring Security 인증의 "심장"부분이라 하신다.

이렇게까지 거창한 표현을 쓸줄이야...

@Service
@RequiredArgsConstructor
@Slf4j
public class UserDetailsServiceImpl implements UserDetailsService {

    public final JdbcTemplate jdbcTemplate;

    @Override
    public UserDetails loadUserByUsername(String userId) {
        String sql = "SELECT * FROM \"USER\" WHERE \"USER_ID\" = ?"; // 여기 에러는 무시 가능
        UserDetailsDTO userImpl = new UserDetailsDTO();

        try {
            UserDTO user = jdbcTemplate.queryForObject(
                    sql,
                    new Object[]{userId},
                    (rs, rowNum) -> {   // Mapper
                        UserDTO u = new UserDTO();
                        u.setUserCd(rs.getString("USER_CD"));
                        u.setUserId(rs.getString("USER_ID"));
                        u.setUserNm(rs.getString("USER_NM"));
                        u.setPassword(rs.getString("PASSWORD"));
                        u.setBgColor(rs.getString("BG_COLOR"));
                        u.setTextColor(rs.getString("TEXT_COLOR"));
                        u.setInsertDatetime(rs.getString("INSERT_DATETIME"));
                        return u;
                    }
            );

            if (user == null) {
                throw new UsernameNotFoundException("사용자 정보 없음: " + userId);
            }

            userImpl.setUserCd(user.getUserCd());
            userImpl.setUserId(user.getUserId());
            userImpl.setUserNm(user.getUserNm());
            userImpl.setPassword(user.getPassword());
            userImpl.setBgColor(user.getBgColor());
            userImpl.setTextColor(user.getTextColor());
            userImpl.setInsertDatetime(user.getInsertDatetime());
            return userImpl;

        } catch (Exception e) {
            e.printStackTrace();
            throw new UsernameNotFoundException("사용자 정보 없음: " + userId);
        }
    }

1️⃣ public class UserDetailsServiceImpl implements UserDetailsService

UserDetailsService 또한 Spring Security가 로그인 시 무조건 호출하는 서비스이다.

사용자가 아이디 + 비밀번호 입력
Spring Security가 UserDetailsService를 찾음
loadUserByUsername(username)을 자동으로 호출

따라서 개발자가 따로 호출하지 않아도 자동으로 연결된다.

이걸 지금 implement한 이유는 그 안의 loadUserByUsername을 오버라이드해서 사용할려고.

2️⃣ JDBCTemplate 선택 이유

JDBCTemplate는 동기 처리가 가능하고, 예외 흐름이 명확하며, 트랜잭션과 디버깅이 쉽다. 이거 사용 안하면 Supabase SDK를 사용하는 수밖에 없는데, 그거 설치하고 세팅하기까지 또 엄청 오래 걸릴것이 당연지사, Kotlin 비동기식 + SDK 업데이트도 필요하기 때문에 이것저것 귀찮음 이슈로 JDBCTemplate를 선택했다...

3️⃣ public UserDetails loadUserByUsername

절대로 임의의 메소드가 아니고, UserDetailsService에 내장되어 있는 메소드이다.

Spring Security 내부에서 AuthenticationManager → UserDetailsService.loadUserByUsername()을 실행한다.

로그인 버튼을 누르면 무조건 실행됨!

4️⃣ SQL작성문

String sql = "SELECT * FROM \"USER\" WHERE \"USER_ID\" = ? ";

참고로 큰따옴표 "USER"로 작성해야 하므로(PostgreSQL을 사용함, 테이블명 & 컬럼명을 대문자로 함) 이스케이프 문자 \를 "앞에 반드시 사용해준다.

이런식으로 빨간색 표시와 함께 에러 문구가 뜨긴 하는데, sql은 잘도 돌아간다. 이게 싫으면 DB설계 때 소문자로 하던가ㅎ

jdbcTemplate.queryForObject(sql, param[], RowMapper)

queryForObject: 데이터베이스 쿼리를 실행하여, 단 하나의 객체를 조회할 때 사용하는 메소드. 단건 조회에 최적합. 결과가 0행이거나 2행 이상일 경우 예외 반환, 정상인 경우 UserDTO 객체 하나 반환

첫번째 인자 : 실행할 SQL. ?는 아직 값이 없는 자리
두번째 인자 : 파라미터 배열. SQL의 첫번째 ?에 이 배열의 첫번째 값인 userId를 넣어달라는 뜻
세번째 인자 : 람다식 RowMapper

(rs, rowNum) -> {...} : RowMapper의 인터페이스 구현. 원래 형태는

public UserDTO mapRow(ResultSet rs, int rowNum)

rs(ResultSet) : DB에서 조회한 현재 행. 커서가 이미 해당 행에 위치해 있음

rowNum : 몇번째 행인지(0부터 시작), query()에서 여러 행 처리할 때 유용

람다식 내부에선 UserDTO를 반환하는 작업을 할것이다.

(rs, rowNum) -> {   
    UserDTO u = new UserDTO();
    u.setUserCd(rs.getString("USER_CD"));
    u.setUserId(rs.getString("USER_ID"));
    u.setUserNm(rs.getString("USER_NM"));
    u.setPassword(rs.getString("PASSWORD"));
    u.setBgColor(rs.getString("BG_COLOR"));
    u.setTextColor(rs.getString("TEXT_COLOR"));
    u.setInsertDatetime(rs.getString("INSERT_DATETIME"));
    return u;
}

그니까 사실 이건,

new RowMapper<UserDTO>() {
    @Override
    public UserDTO mapRow(ResultSet rs, int rowNum) throws SQLException {
        UserDTO u = new UserDTO();
        u.setUserCd(rs.getString("USER_CD"));
        u.setUserId(rs.getString("USER_ID"));
        u.setUserNm(rs.getString("USER_NM"));
        u.setPassword(rs.getString("PASSWORD"));
        u.setBgColor(rs.getString("BG_COLOR"));
        u.setTextColor(rs.getString("TEXT_COLOR"));
        u.setInsertDatetime(rs.getString("INSERT_DATETIME"));
        return u;
    }
}

이거랑 똑같은 뜻이다.

람다에 대한 설명은 여기에...

5️⃣ 객체 반환

SQL로부터 반환된 객체 값을 userDetailsDTO에 넣어서 원래 메소드 UserDetailsDTO userDetails로 반환한다.

[참고 자료]

https://programmer93.tistory.com/68

Spring Security UserDetails, UserDetailsService 란? - 삽질중인 개발자

Spring Security - UserDetails , UserDetailsService UserDetails 란? Spring Security에서 사용자의 정보를 담는 인터페이스이다. Spring Security에서 사용자의 정보를 불러오기 위해서 구현해야 하는 인터페이스로 기본

programmer93.tistory.com

https://velog.io/@cyseok123/%EC%8B%9C%ED%81%90%EB%A6%AC%ED%8B%B0%EC%97%90-%EC%B6%94%EA%B0%80%ED%95%98%EA%B8%B0

[Spring] Spring-Security / UserDetails와 UserDetailsService 커스터마이징

UserDetails와 UserDetailsService 를 이용한 스프링 시큐리티 커스터마이징

velog.io

[Spring] Spring Security 맛보기

JanuDev — Thu, 11 Dec 2025 00:04:22 +0900

미루고 미루던 Spring Security를 슬슬 공부할 때가 된 듯 하다.... 그날이 왔도다

Spring 흐름에 대한 간단한 설명

Spring 흐름에 대한 자세한 설명

1. Spring Security란

Spring Security는 Spring 기반의 애플리케이션의 보안을 담당하는 스프링 하위 프레임워크이다.

로그인, 보안을 위한 인증 • 인가들을 개발하기 위해선 Spring Security를 많이 사용한다.

2. Spring Security 원리

Spring Security의 흐름은 다음과 같다.

요청(Request) → 필터(Filter) → 인증(Authentication) → 인가(Authorization)

(1) 요청(Request)

여기서 요청(Request)란 클라이언트가 서버로 보내는 모든 HTTP 요청을 의미한다.

서버는 한 번 인증했다고 해서 계속 로그인 상태임을 기억하지 않고, 기억력이 없는 존재(Stateless)로 설계된다.

따라서 요청이 들어올 때 마다 "이 요청을 보낸 사람이 아까 그 사용자라는 증거가 어딨지" 라는 생각을 하는데, 그 증거가 바로 JWT 토큰이고, 그걸 검사하는 것이 JWTFilter이다.

CRUD와 같은 여러 RestfulAPI 요청이 들어올 때 마다, Authorization 헤더에 있는 JWT를 JWTFilter가 매번 확인한다.

(2) 필터(Filter)

요청이 들어오면 필터 체인(Filter Chain)이 여러 필터들을 나열해서, 요청이 들어올 때 마다 이 필터들을 줄줄이 검사하게 된다.

대표적인 필터는 아래와 같다.

UsernamePasswordAuthenticationFilter(일반 로그인) : 폼 기반 인증 처리 - LoginRequest와 같은 ID/PW 요청을 처리하고 Authentication 객체를 생성한다.
JWTAuthenticationFilter / JWTAuthorizationFilter(JWT 로그인) : JWT 기반 인증 처리 - 요청 헤더의 JWT 토큰을 추출하여 사용자를 인증한다(사용자가 구현하는 필터).
SecurityContextPersistenceFilter : 인증 정보 유지 - 인증 성공 후 SecurityContext에 Authentication 객체를 저장하거나 조회한다. 요청이 시작될 때 이전에 저장된 SecurityContext가 있다면 읽어서 불러오고(JWT에선 보통 비활성화됨) 요청이 끝나면 SecurityContext를 clear(삭제)한다.
ExceptionTranslationFilter : 예외 처리 - 인증 및 인가 예외를 처리하고 적절한 HTTP 응답 코드를 반환한다.
FilterSecurityInterceptor(마지막 권한 체크) : 최종 인가 처리 - 리소스 접근 전 마지막으로 권한(Authority)을 확인하여 인가(Authorization)를 결정한다. - 일반 Interceptor과 헷갈리지 말것.

참고

Persistence : 지속성, 끈기
SecurityContext : 스프링 시큐리티에서 "지금 이 요청을 보낸 사람에 대한 인증(로그인)정보가 들어 있는 작은 가방" 같은 느낌. 스프링에서 JWT같은 인증 과정을 걸쳐서 "인증된 사용자"임이 확인이 되면, 그 인증 결과를 SecurityContext에 보관한다. 이 SecurityContext 안에 들어 있는 정보는 Authentication 객체이다.
Authentication 객체 : 인증의 결과를 담고 있는 핵심 객체. 누가 요청했는지(username), 그 사람의 권한(ROLE_USER, ROLE_ADMIN), 인증이 됬는지(Boolean) 이 들어있다.
Authentication 객체의 역할 - GPT피셜

1. 사용자 정보 (Principal & Credentials)
Principal (주체): 현재 시스템에 접근하려는 사용자를 나타냅니다. 보통 사용자 이름(username), 사용자 ID, 또는 사용자 상세 정보(UserDetails) 객체 자체가 될 수 있습니다.
Credentials (자격 증명): 사용자의 비밀번호나 토큰과 같이 사용자가 자신이 주장하는 사람임을 증명하는 데 사용되는 정보입니다. 인증이 완료된 후에는 보안을 위해 이 정보는 보통 지워집니다.
2. 인증 상태 (Authenticated)
isAuthenticated() 메서드를 통해 이 객체가 나타내는 사용자가 인증되었는지(true) 또는 인증 전인지(false) 상태를 나타냅니다.
3. 권한 정보 (Authorities)
인증된 사용자가 가진 권한 목록(GrantedAuthority)을 담고 있습니다. 예를 들어, ROLE_ADMIN, ROLE_USER 등의 정보를 담고 있어, 이후 인가(Authorization) 단계에서 사용자가 특정 리소스에 접근할 수 있는지 판단하는 근거가 됩니다.

필터가 차례 차례 요청을 넘기는데, 필터 중간에 인증이 완료된다면 뒤의 필터들은 인증이 완료된 유저 정보(SecurityContext)를 그대로 사용한다.

따라서 인증이 완료됬다면 SecurityContext 생성 & Authentication 객체가 저장된다.

(3) 인증(Authentication)

1) AuthenticationManager가 진짜로 로그인을 검증

로그인 시도(아이디/비밀번호 인증)가 들어오면 AuthenticationManager가 등장에서 다음을 수행한다.

유저 정보(loadUserByUsername) 가져오기
비밀번호 확인
성공하면 Authentication 객체 생성
SecurityContext에 저장

이걸로 "로그인 됨" 상태가 만들어진다.

2) SecurityContext에 사용자 정보 저장

SecurityContext는 "이번 요청에서 인증된 유저 정보 저장소"이다.

인증에 성공하면 Authentication 객체를 저장
컨트롤러에서 @AuthenticationPrincipal 같은 것을 쓰면 그 정보를 읽을 수 있다.
요청이 끝나면 사라진다.

즉, 한 번의 요청 동안만 로그인 상태를 유지하는 임시 메모장과 같은 것이다.

+ 내 코드를 바탕으로 한 Spring Security이의 흐름

단계	주체	동작	결과
1. 요청 생성	Client	사용자 이름과 비밀번호를 담아 로그인 요청(/login)	LoginRequestDTO
2. 인증 요청	AuthService	LoginRequest를 기반을 인증 전 토큰(UsernamePasswordAuthenticatoinToken) 생성	Authentication 객체(Unauthenticated)
3. 인증 위임	LoginHandler	토큰을 AuthenticationManager에게 전달
4. 인증 수행	AuthenticationManager	요청을 처리할 수 있는 AuthenticationProvider에게 위임
5. 사용자 로드	AuthenticationProvider	UserDetailService를 통해 DB에서 사용자 정보(UserDetails) 로드
6. 검증	AuthenticationProvider	PasswordEncoder로 비밀번호 비교
7. 성공, 실패	AuthenticationProvider	성공 시 권한이 담긴 인증 완료 토큰 반환	Authentication 객체(Authenticated)
7. 컨텍스트 저장	AuthService	인증 완료된 Authentication 객체를 SecurityContextHandler에 저장	인증 정보 유지

(4) 인가(Authorizatoin) - 권한 체크

필터 체인의 마지막 쯤에서 FilterSecurityInterceptor가 "이 유저가 이 URL에 접근할 권한이 있는가?"를 체크한다.

ROLE_USER는 /mypage 가능
ROLE_ADMIN은 /admin 가능

권한이 없으면 403 Forbidden.

주의!
FilterSecurityInterceptor과 일반 HandlerInterceptor를 헷갈리지 말것.
• FilterSecurityInterceptor : 인증 및 인가 단계에서 실행 및 완료
• 일반 HandlerInterceptor : DispatcherServlet이 핸들러를 찾은 직후, 컨트롤러 실행 '직전'에 동작함

이렇게 이해하면 되겠다

3. Spring MVC 전체 요청 흐름

Client → Filter → DispatcherServlet → Interceptor → Controller

맞다. 이게 내가 원래 공부했던 Spring MVC 패턴이다. 여기에 대입해서 설명할거다.

클라이언트가 요청을 보냄
"서블릿 필터"가 먼저 실행됨 ← 여기에 위에서 설명한 Spring Security Filter chain들 있어요
DispatcherServlet이 요청을 잡음
Interceptor가 동작
Controller 실행
응답 반환...

즉 앞서 말한 Spring Security의 흐름은 "Filer Chain"의 내부 모습을 확대해서 본 것이라 봐도 무방하다.

Interceptor에 대한 정리에 대한 글

DispatcherServlet이란? (복습 겸)

웹 요청이 들어오면 Spring MVC는 그걸 어느 컨트롤러에서 처리해야 하는지 연결해야 하는데, 그 흐름을 조종하는 친구가 DispatcherServlet이다.

Filter → 학교 정문 경비 아저씨
DispatcherServlet → 교무실에서 “이 학생 어디 반으로 보내야 하지?” 정리하는 교사
Controller → 실제 수업(비즈니스 로직)을 담당하는 반

MVC 요청 흐름에서 DispatcherServlet은 중심 허브이다.

DispatcherServlet의 역할은 다음과 같다.

URL을 보고 어떤 Controller을 호출해야 하는지 결정
Controller 실행
Controller가 반환 값을 ViewResolver로 전달
최종 JSON, HTML을 만들어서 응답 완성

참고로 Dispatch는 급파하다, 파견하다의 의미를 가지고 있으며 받은 요청을 어딘가로 빨리 보내는 서블릿이라는 뜻이다.

Spring이 없는 Java 런타임은 컨트롤러가 존재하지 않기 때문에 서블릿 객체를 생성하고 그것을 web.xml에 일일히 다 등록해야 했는데, DispatcherServlet은 이러한 단점을 해결해준다.

서블릿에 대한 개념은 여기 참조

[참고 자료]

https://mangkyu.tistory.com/76

[SpringBoot] Spring Security란?

대부분의 시스템에서는 회원의 관리를 하고 있고, 그에 따른 인증(Authentication)과 인가(Authorization)에 대한 처리를 해주어야 한다. Spring에서는 Spring Security라는 별도의 프레임워크에서 관련된 기능

mangkyu.tistory.com

https://prao.tistory.com/entry/Spring-Security-Spring-Security%EC%99%80-JWT-%EC%A0%81%EC%9A%A9-%EA%B3%BC%EC%A0%95

[Spring Security] Spring Security와 JWT 적용 과정

사이드 프로젝트를 진행하면서 Spring Security와 JWT를 적용하여 회원 기능을 완성하는 역할을 맡게 되었다.JWT는 프로젝트에 적용시켜본 경험이 있으나 Spring Security는 처음이었고 Spring Security와 JWT

prao.tistory.com

https://jiwon.oopy.io/1cfde91b-5fd3-4851-9419-9045d971d2cf

Spring Security 구조 이해하기

Spring Security란?

jiwon.oopy.io

https://velog.io/@seculoper235/2.-DispatcherServlet-%EC%9D%B4%EB%9E%80

2. DispatcherServlet 이란?

드디어 시작되는 DispatcherServlet!해당 클래스는 Servlet의 중심이자, Spring MVC의 중심이다.이것을 이해하는 것이 곧 Spring MVC를 이해하는 것과 같다고 할 수 있을 정도로 중요한 요소이다 : )그럼 한번

velog.io

티스토리에서 수식 쓰기

JanuDev — Wed, 10 Dec 2025 17:04:50 +0900

티스토리에 딱히 수식을 쓰는 기능이 없는 것 같아서 찾다가 쓴 글

1. 블로그 관리 > 스킨 편집 > html 편집 클릭

2. <head>태그 안에 수식 관련 script 붙여넣기

<script src="https://polyfill.io/v3/polyfill.min.js?features=es6"></script>
<script id="MathJax-script" async src="https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-mml-chtml.js"></script>

그냥 이거 복붙해서 붙여넣기하고 저장하면 된다.

저기에 붙여넣으면 된다.

3. 수식 작성하기

수식 작성하는데 도움 받을 수 있는 사이트는 여기다.

https://editor.codecogs.com/

Equation Editor for online mathematics - create, integrate and download

Download svg gif png pdf emf 5 pt 9 pt 10 pt 12 pt 18 pt 20 pt 50 80 100 110 120 150 200 300 Transparent White Black Red Green Blue Inline Block WordPress phpBB Tiny Wiki url url encoded xml pre doxygen html latex Formatted string containing your Equation

editor.codecogs.com

이런식으로 작성해서 확인할 수 있다.

참고로 LaTeX 문법을 통해서 수식을 작성해야 한다.

1️⃣ 텍스트 사이에 수식을 작성할 경우

\(여기 안에 수식을 써야 한다 \)

$여기 안에 수식을 써야 한다. a_x$

저렇게 \( 과 )\ 사이에 작성해야 한다.

2️⃣ 인라인, 디스플레이 수식

인라인 수식은 일반 텍스트의 줄 안에 삽입되는데, 텍스트의 흐름을 끊기지 않고 문장과 함께 한 줄에 표시도힌다.

텍스트와 함께 왼쪽 정렬에 따른다.

수열의 $x$ 번째 항은 $a_x$ 이다.

저렇게 단일 달러 기호로 감싼다 ($...$)

디스플레이 수식은 텍스트 줄에서 분리되어 독립적인 단락처럼 표시된다. 수식의 위아래로 공백이 생긴다.

페이지나 문서 영역의 중앙에 정렬된다.

$$a_x$$

$$a_x$$

이렇게 보인다.

참고로 티스토리에선 인라인 수식은 인식이 안되는데 디스플레이 수식은 인식이 되는듯 하다. 그래서 1️⃣ 와 같은 방법으로 작성한다.

3️⃣LaTeX 기본 문법

기능	명령어	결과	설명
윗첨자(지수)	a^x	$a^x$	캐럿^ 뒤 문자가 윗첨자가 된다
아랫첨자(첨자)	a_x	$a_x$	언더바_ 뒤의 문자가 아랫첨자가 된다
여러 문자	a^{xy} 또는 a_{xy}	$ a^{xy} 또는 a_{xy} $	두 글자 이상은 중괄호{}에 묶어야 한다
제곱근	\sqrt{x}	$\sqrt{x}$	\ 이건 반드시 붙여야 한다.
n제곱근	\sqrt[n]{x}	$\sqrt[n]{x}$	대괄호[n]을 차수로 지정한다

[참고 자료]

https://ysryuu.tistory.com/23

[Blog] 티스토리에서 수식 추가하기

머신러닝, 딥러닝 관련 포스팅을 위해서는 수식이 필요할 때가 종종 있을 것이다.티스토리에서 쉽게 수식을 추가하는 방법에 대해 포스팅해보겠다. 1. 티스토리 스킨 설정티스토리 설정 -> 스킨

ysryuu.tistory.com

https://devjino.tistory.com/324

[팁] tistory 수학 기호 넣기

블러그 관리 -> 꾸미기 -> 스킨편집 -> html 편집 html 편집의 head부분에 다음의 코드를 넣어 줍니다. 사용 방법은 다음 페이지 참고합니다. https://ko.wikipedia.org/wiki/%EC%9C%84%ED%82%A4%EB%B0%B1%EA%B3%BC:TeX_%EB%AC

devjino.tistory.com