@Async 비동기로 호출 시에 SecurityContext 전달하기 - Spring Security, Thread Pool

😓 문제상황

배경

프로젝트에서 Request시에 RTT가 오래 걸리는 API가 있어서

Request가 들어오고 해당 쓰레드에서 비동기로 새로운 쓰레드를 만들어서 작업을 위임하고

Response를 바로 내리는 프로세스가 있었다. 

FLOW

 

Spring Security로 Request한 유져의 정보를 Thread 단위로 관리하고 있어서

SecurityContextHolder.MODE_INHERITABLETHREADLOCAL 로 설정하여 부모 쓰레드에서 파생된 자식 쓰레드에 SecurityContext가 전파될 수 있도록 설정하였다 

 

상황 - 비동기 쓰레드의 SecurityContext(인증정보)가 완전 꼬임 👅

Local에서 개발할 때는 Request한 유져의 인증정보가 있는 SecurityContext가 비동기 쓰레드로 넘어가는데

개발 완료하고, Dev 서버에 배포하면 비동기 쓰레드의 SecurityContext가 다른 유져인 것이다!

심지어 매번 같은계정으로 Request 여러번 할때마다 여러번 랜덤의 유져가 비동기 쓰레드의 SecurityContext에서 발견되었다!!!

(JVM인데 Local에서는 되고, Dev에서는 안된다?? 가 사실 말이 안되는 건데 뒤에서 말하지만, 사실 없지않아 속았다)

---

🔎 문제의 Config

위와 같은 문제의 상황에서 쓰레드 관련 Config를 살펴보면

 

Spring Security Mode

@Configuration
@EnableWebSecurity
@RequiredArgsConstructor
public class SpringSecurityConfig {

    @PostConstruct
    public void init() {
    	SecurityContextHolder.setStrategyName(SecurityContextHolder.MODE_INHERITABLETHREADLOCAL);
    }
    ...생략

}

 

Spring Security는 인증/인가 정보를 SecurityContext에 Thread 별로 가지게된다

 

Thread별로 가지게되는 SecurityContext

 

좀 더 자세히 말하면

SecurityContext는 SecurityContextStrategy로 Wrapping 되어서 strategy 안에 ThreadLocal 타입으로 존재한다

SecurityContextHolderStrategy 구현체 4개

Strategy는 4개의 구현체가 있는데

Spring config 시점에 MODE를 하나 선택하면 전략패턴으로 strategy가 선정이된다

각 strategy 기반으로 SecurityContext를 관리하는 방식이 다르다

• MODE_THREADLOCAL : 현재 쓰레드에 종속된 ThreadLocal 객체에 SecurityContext  저장 (default)
• MODE_INHERITABLETHREADLOCAL : 생성되는 자식 쓰레드가 부모 쓰레드의 SecurityContext 상속 받을 수 있음
• MODE_GLOBAL : 앱 전체에 한개의 SecurityContext를 생성 공유 for 단일 유져
• MODE_PRE_INITIALIZED : 앱 시작 때 SecurityContext 미리 초기화

-> 프로젝트는 자식쓰레드가 부모 쓰레드의 SecurityContext를 받아서 비동기 작업을 해야했어서 MODE_INHERITABLETHREADLOCAL을 선택했다

Async Config

@EnableAsync
@Configuration
public class AsyncConfig implements AsyncConfigurer {

    @Override
    public Executor getAsyncExecutor() {
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();

        int corePoolSize = Runtime.getRuntime().availableProcessors(); // CPU 코어 수에 맞춰 스레드 풀 크기 설정
        int maxPoolSize = corePoolSize * 2; // 최대 풀 크기 - CPU 코어 수의 두 배
        int queueCapacity = 500; // 큐 용량 설정

        executor.setCorePoolSize(corePoolSize);
        executor.setMaxPoolSize(maxPoolSize);
        executor.setQueueCapacity(queueCapacity);
        executor.setThreadNamePrefix("AsyncExecutor-");

        ... 중략

        executor.initialize();

        return executor
    }

}

 

@Async 어노테이션이 붙은 메서드가 호출 시

아래의 스펙의 Thread Pool에서 

• Core Pool Size : 항상 유지 되는 최소 스레드 개수 - CPU 코어수에 맞게
  • 작업이 없더라도 이 숫자 만큼은 항상 생성되어 대기 상태 유지
• Max Pool Size : 최대 쓰레드 개수 - corerPoolSize 의 2배
• Queue Capacity : 작업 큐의 사이즈 - 500
  • Core Pool Size가 넘어가면 Queue에 들어가게 되고, 
  • Queue가 꽉차면 MaxPoolSize 만큼 쓰레드가 확장

Pool에 Thread가 생성안되어있으면 생성 / 생성되어있으면 재사용 하게 된다

 

---

✌ 재현해보기

사실 제일 이해가 안되었던 부분은 Local 환경에서는 되고, Dev 환경에서는 안되는 것이 제일 이상했다

Thread는 결국 가상 머신 위에서 JVM에 의해 만들어지는데, OS 영향을 받지 않을 것이기 때문이다

 

Spring Security에 대해서 좀 더 deep dive한 후에 

로그를 찍어보며 차근히 다시 살펴보기로 하였다

 

실험환경

기존 Async Config로는 Thread Pool 의 쓰레드 개수가 많아서 로그 찍기가 어려울거 같아서 아래와 같이 세팅했다

• Core Pool Size : 2개
• Max Pool Size : 2개

즉 그냥 쓰레드 2개로만 실험해보았다

 

플로우는 아래와 같고

 

Request -> 부모쓰레드(Servelet Request로 생성된 쓰레드) -> 부모쓰레드에서 비동기 메서드 호출 -> 부모쓰레드 Response 동시에 자식 비동기 쓰레드 실행

Request -> 부모쓰레드(Servelet Request로 생성된 쓰레드) -> 부모쓰레드에서 비동기 메서드 호출 -> 부모쓰레드 Response 동시에 자식 비동기 쓰레드 실행

 

API 호출을 유져 로그인을 바꿔가며 아래의 순서로 4번 호출하여 4개의 부모자식 쓰레드 정보를 얻을 수 있었다

1. 직원A 계정으로 API 호출
2. 직원B 계정으로 API 호출
3. 직원A 계정으로 API 호출
4. 직원A 계정으로 API 호출

2025-01-10 18:40:04.215 [http-nio-8080-exec-2] - [test] -----------PARENT Thread----------- [test]
2025-01-10 18:40:04.215 [http-nio-8080-exec-2] - [test] parent-thread-id=33
2025-01-10 18:40:04.215 [http-nio-8080-exec-2] - [test] parent-thread-name=http-nio-8080-exec-2
2025-01-10 18:40:04.215 [http-nio-8080-exec-2] - [test] parent-thread-state=RUNNABLE
2025-01-10 18:40:04.229 [http-nio-8080-exec-2] - [test] SecurityContext=SecurityContextImpl [Authentication=직원A]
2025-01-10 18:40:04.229 [http-nio-8080-exec-2] - [test] Locale=ko_KR
2025-01-10 18:40:04.229 [http-nio-8080-exec-2] - [test] --------------------------- [test]

2025-01-10 18:40:04.242 [AsyncExecutor-1] - [test] -----------Child @ASYNC Thread----------- [test]
2025-01-10 18:40:04.242 [AsyncExecutor-1] - [test] child-thread-id=53
2025-01-10 18:40:04.242 [AsyncExecutor-1] - [test] child-thread-name=AsyncExecutor-1
2025-01-10 18:40:04.242 [AsyncExecutor-1] - [test] child-thread-state=RUNNABLE
2025-01-10 18:40:04.242 [AsyncExecutor-1] - [test] SecurityContext=SecurityContextImpl [Authentication=직원A]
2025-01-10 18:40:04.242 [AsyncExecutor-1] - [test] Locale=null
2025-01-10 18:40:04.242 [AsyncExecutor-1] - [test] --------------------------- [test]



2025-01-10 18:40:11.153 [http-nio-8080-exec-3] - [test] -----------PARENT Thread----------- [test]
2025-01-10 18:40:11.153 [http-nio-8080-exec-3] - [test] parent-thread-id=34
2025-01-10 18:40:11.153 [http-nio-8080-exec-3] - [test] parent-thread-name=http-nio-8080-exec-3
2025-01-10 18:40:11.153 [http-nio-8080-exec-3] - [test] parent-thread-state=RUNNABLE
2025-01-10 18:40:11.153 [http-nio-8080-exec-3] - [test] SecurityContext=SecurityContextImpl [Authentication=직원B]
2025-01-10 18:40:11.153 [http-nio-8080-exec-3] - [test] Locale=ko_KR
2025-01-10 18:40:11.153 [http-nio-8080-exec-3] - [test] --------------------------- [test]

2025-01-10 18:40:11.153 [AsyncExecutor-2] - [test] -----------Child @ASYNC Thread----------- [test]
2025-01-10 18:40:11.153 [AsyncExecutor-2] - [test] child-thread-id=58
2025-01-10 18:40:11.153 [AsyncExecutor-2] - [test] child-thread-name=AsyncExecutor-2
2025-01-10 18:40:11.153 [AsyncExecutor-2] - [test] child-thread-state=RUNNABLE
2025-01-10 18:40:11.153 [AsyncExecutor-2] - [test] SecurityContext=SecurityContextImpl [Authentication=직원B]
2025-01-10 18:40:11.153 [AsyncExecutor-2] - [test] Locale=null
2025-01-10 18:40:11.153 [AsyncExecutor-2] - [test] --------------------------- [test]


2025-01-10 18:40:12.153 [http-nio-8080-exec-4] - [test] -----------PARENT Thread----------- [test]
2025-01-10 18:40:12.153 [http-nio-8080-exec-4] - [test] parent-thread-id=35
2025-01-10 18:40:12.153 [http-nio-8080-exec-4] - [test] parent-thread-name=http-nio-8080-exec-3
2025-01-10 18:40:12.153 [http-nio-8080-exec-4] - [test] parent-thread-state=RUNNABLE
2025-01-10 18:40:12.153 [http-nio-8080-exec-4] - [test] SecurityContext=SecurityContextImpl [Authentication=직원A]
2025-01-10 18:40:12.153 [http-nio-8080-exec-4] - [test] Locale=ko_KR
2025-01-10 18:40:12.153 [http-nio-8080-exec-4] - [test] --------------------------- [test]

2025-01-10 18:40:12.153 [AsyncExecutor-1] - [test] -----------Child @ASYNC Thread----------- [test]
2025-01-10 18:40:12.153 [AsyncExecutor-1] - [test] child-thread-id=53
2025-01-10 18:40:12.153 [AsyncExecutor-1] - [test] child-thread-name=AsyncExecutor-1
2025-01-10 18:40:12.153 [AsyncExecutor-1] - [test] child-thread-state=RUNNABLE
2025-01-10 18:40:12.153 [AsyncExecutor-1] - [test] SecurityContext=SecurityContextImpl [Authentication=직원A]
2025-01-10 18:40:12.153 [AsyncExecutor-1] - [test] Locale=null
2025-01-10 18:40:12.153 [AsyncExecutor-1] - [test] --------------------------- [test]



2025-01-10 18:40:13.153 [http-nio-8080-exec-5] - [test] -----------PARENT Thread----------- [test]
2025-01-10 18:40:13.153 [http-nio-8080-exec-5] - [test] parent-thread-id=36
2025-01-10 18:40:13.153 [http-nio-8080-exec-5] - [test] parent-thread-name=http-nio-8080-exec-5
2025-01-10 18:40:13.153 [http-nio-8080-exec-5] - [test] parent-thread-state=RUNNABLE
2025-01-10 18:40:13.153 [http-nio-8080-exec-5] - [test] SecurityContext=SecurityContextImpl [Authentication=직원A]
2025-01-10 18:40:13.153 [http-nio-8080-exec-5] - [test] Locale=ko_KR
2025-01-10 18:40:13.153 [http-nio-8080-exec-5] - [test] --------------------------- [test]

2025-01-10 18:40:13.153 [AsyncExecutor-2] - [test] -----------Child @ASYNC Thread----------- [test]
2025-01-10 18:40:13.153 [AsyncExecutor-2] - [test] child-thread-id=58
2025-01-10 18:40:13.153 [AsyncExecutor-2] - [test] child-thread-name=AsyncExecutor-2
2025-01-10 18:40:13.153 [AsyncExecutor-2] - [test] child-thread-state=RUNNABLE
2025-01-10 18:40:13.153 [AsyncExecutor-2] - [test] SecurityContext=SecurityContextImpl [Authentication=직원B]
2025-01-10 18:40:13.153 [AsyncExecutor-2] - [test] Locale=null
2025-01-10 18:40:13.153 [AsyncExecutor-2] - [test] --------------------------- [test]

 

🚨🚨🚨🚨🚨🚨🚨

4번째 호출을 보면

직원B 계정으로 API 호출했는데,

비동기 자식 쓰레드의 SecurityContext가 직원B 인 것을 확인할 수 있다.

🚨🚨🚨🚨🚨🚨🚨

 

분명 Spring Security에서 자식 쓰레드로 SecuritContext 전파하는 설정을 했는데????????

 

여기서 멘붕이 와서 한동안 많은 자료들을 찾아보고 선임과 다양한 토론을 했었다

---

🤔 MODE_INHERITABLETHREADLOCAL에 대한 의심 그리고 Thread Pool 

자료를 더 찾아보고, 디버깅을 해보니 

Thread가 생성되는 시점에 SecurityContext를 넣어주는 것까지 확인을했다

중요한건 Thread가 생성되는 시점이었다

 

위 실험에서 Thread Pool에서 사용할 수 있는 비동기 쓰레드는 2개다

 

처음에

Spring init 시점에 Executor가 Thread Pool에 CoreSize 만큼 쓰레드를 만들어놓는다?

고 생각했다

 

하지만 실제 런타임에서 디버깅을 해보니

 

1. 직원A 계정으로 API 호출 -> 비동기 @Async 메서드 호출 -> AsyncExecutor-1 쓰레드 생성(직원A) -> Pool에 반납
2. 직원B 계정으로 API 호출 -> 비동기 @Async 메서드 호출 -> AsyncExecutor-2 쓰레드 생성(직원B) -> Pool에 반납
3. 직원A 계정으로 API 호출 -> 비동기 @Async 메서드 호출 -> AsyncExecutor-1 쓰레드 재사용 (직원A) -> Pool에 반납
4. 직원A 계정으로 API 호출 -> 비동기 @Async 메서드 호출 -> AsyncExecutor-2 쓰레드 재사용 (직원B) -> Pool에 반납

 (실험을 위해 위의 4개의 호출은 Local환경에서 시간차를 두고 4번 호출)

 

JVM마다 설정이 다를 수 있지만 (추후 공부거리다)

• Spring이 init할때는 ThreadPool이 비어있다가
• 비동기 메서드 첫 호출 기점으로 쓰레드를 생성해서 Pool에 넣어주기 시작
• MODE_INHERITABLETHREADLOCAL은 생성! 시점에 Thread에 SecurityContext 넣어주는 것이기 때문에
• 3,4번 호출 때는 Thread 재사용이므로 적용되지 않음 

 

그렇다면 3,4번 호출 때는 비동기 쓰레드들의 SecurityContext가 null이어야하지 않은가? 싶은데

 

 

• 2번 AsyncExecutor-2가 종료될 때 남아있는 직원 B 인증정보가
• 4번 호출일 때 AsyncExecutor-2가 재사용되면서
• 부모쓰레드와 자식비동기쓰레드의 SecurityContext가 불일치

비동기 쓰레드가 Pool에 반환될때 SecurityContext를 지워주지 않는다!!

 

 

서블릿 Request로 생성된 부모쓰레드에서는 SecurityContext가

자식 쓰레드 SecurityContext와 다르다면 각 쓰레드의 차이점은 무엇이고 각 쓰레드에서의 생명주기는 무엇인지 공부해봐야했다

---

🤔 SecurityContext의 생명주기

결론부터 말하자면, Servelet Request로 생성된 쓰레드 내에서만 Spring Security가 자동으로 유효하게 관리해준다

Architecture :: Spring Security

 

Spring Security는 인증/인가를 처리하고 SecurityContext를 세팅하는 데에 Filter를 사용한다

HTTP Request가 아래와 같이 Filter를 껴서 진행이 되는데

1. 클라이언트가 HTTP Request를 전송하면, Servelet 컨테이너(Tomcat 등)가 요청 수신
2. Servelet 컨테이너는 내부적으로 쓰레드 Pool을 유지하고 Pool에서 쓰레드를 꺼내서 요청에 할당
3. Servlet 컨테이너가 요청을 Filter에 전달
4. 각 Filter를 지나면서 Filter에 할당된 작업이 Servelet Request/Response 기반으로 처리
5. 모든 Filter 지나면 Spring Controller에 전달
6. 응답은 요청시 거쳤던 Filter들을 역순으로 지나서 Servelet 컨테이너로 반환
7. Servelet 컨테이너는 응답을 Serialize하여 HTTP Response로 클라이언트에게 반환

FilterChainProxy > SecurityFilterChain > SecurityFilter

Spring Bean과 Servelet Filter를 연결해주는 DelegatingFilterProxy가 가지고 있는

Spring Security의 FilterChainProxy가 살펴봐야할 메인이다

FilterChainProxy를 까보면, 

• 프로젝트에서 빈으로 등록한 SecurityFilter 목록을 가짐
• SecurityFilter 목록을 chain으로 리스트로 가져서, 요청이 SecurityFilter들을 통과하도록 관리
• 개발자가 커스텀한 인증 SecurityFilter 빈을 통과하면서 securityContext가 세팅됨

그리고 Response가 내려갈 때 

finally! context clear

securityContext를 clear해주면서

Thread 반환하기전에 SecurityContext가 있는 ThreadLocal이 깔끔해지는 것이다!

• Servlet Filter를 Spring Security가 SecurityContext 생성/소명 시키는데에 사용
• Servelet Request로 생성된 쓰레드 내에서는 SecurityContext는 Spring Security FilterChainProxy에 의해 자동으로 생성 -> 소멸

 

😮 그렇다면 @Async로 호출하는 비동기 쓰레드는?

비동기 쓰레드는 Servelet Request로 만들어져서 Filter를 타지 않는

개발자가 커스텀한 Thread Pool에서 관리되는 Thread이다

 

즉, 비동기 쓰레드는 Servlet Request/Response도 아니고 Filter를 타는 것도 아니다

쓰레드를 Pool에 반환전에 자동으로 SecurityContext를 clear해주는 FilterChainProxy 도 안 탄다는 것이다

 

그래서 

1. 직원A 계정으로 API 호출 -> 비동기 @Async 메서드 호출 -> AsyncExecutor-1 쓰레드 생성(직원A) -> Pool에 반납
2. 직원B 계정으로 API 호출 -> 비동기 @Async 메서드 호출 -> AsyncExecutor-2 쓰레드 생성(직원B) -> Pool에 반납
3. 직원A 계정으로 API 호출 -> 비동기 @Async 메서드 호출 -> AsyncExecutor-1 쓰레드 재사용 (직원A) -> Pool에 반납
4. 직원A 계정으로 API 호출 -> 비동기 @Async 메서드 호출 -> AsyncExecutor-2 쓰레드 재사용 (직원B) -> Pool에 반납

4번 호출 때, 쓰레드 재사용이므로 SpringSecurity는 SecurityContext를 넘겨주지 않았고

2번에서 쓰인 AsyncExecutor-2에 남아있는 직원B가 그대로 쓰인것이다

 

그렇다면 3번 호출때도 사실 운이 좋아서 부모쓰레드랑 자식쓰레드의 SecurityContext가 일치한것이다

 

😮  아 그래서?? Local 개발 환경에서 미리 못잡았나?

Local 개발환경에서는 통상적으로

• 한사람의 계정으로만 가지고 API 테스트
• 비동기 쓰레드에 모두 같은 사람의 SecurityContext가 잔여
• 어차피 한사람의 계정만 쓰므로 부모쓰레드와 자식 비동기 쓰레드가 인증정보가 달라질 케이스 발견 못함

Dev 서버로 배포후에는

• 여러 테스터들이 다수의 계정으로 API 테스트하면서 위의 문제로 장애 발생

그래서 Local 개발환경에서는 되고, Dev 서버에서는 안된다고 생각한건데

알고 보니까 현상은 같았고, 여러 계정을 고려하며 Local에서 테스트하지 않았기 때문에 생긴일이었다

 

---

🤣 원인 정리

원인을 그래서 다시 요약해보자면

👉 ThreadPool에 존재하는 Thread 개수가 Core Pool Size 미만인 경우

• Thread가 지속 `생성`되므로, Spring Security Mode 설정에 따라 부모 SecurityContext 전달
• 자식 비동기 쓰레드에서 부모 쓰레드의 인증정보를 가지고 정상 동작
• 비동기 쓰레드이므로, ServeletFilter를 타지 않음 -> Thread 반환시점에 SecutiryContext가 clear되지 않음

👉 ThreadPool에 존재하는 Thread 개수가 Core Pool Size를 달성했거나, Max Pool Size 만큼 커진 경우

• ThreadPool 전략/상황에 의해 Thread가 재사용될 수 있음
• Thread가 `재사용`되므로, Spring Security Mode(`생성`시점에 적용)가 적용안되어 부모 SecurityContext 전달 안됨
• 비동기 쓰레드이므로, ServeletFilter를 타지 않음 -> Thread 반환시점에 SecutiryContext가 clear되지 않음 -> 처음 쓰레드 생성 시의 SecurityContext가 계속 잔여
• 이전 사용에서 SecurityContext가 clear되지 않았으므로, 남아있는 SecurityContext사용하여 로직 실행

---

💡 해결책

해결해야될 지점는 두가지였다

• Thread Pool에서 비동기 Thread 재사용 시에 Spring Security가 SecurityContext 못넘겨주는 지점
• 비동기 Thread가 Pool로 반환될 때, 해당 쓰레드의 ThreadLocal인 SecurityContext가 clear 안되는 지점

 

일단 ThreadPool을 만들고 비동기 쓰레드들을 관리하는 Executor에 조치를 해줘야겠다고 생각해서 서칭했더니

😄 DelegatingSecurityContextExecutor 빈 등록

Executor를 wrapping해서 DelegatingSecurityContextExecutor를 빈으로 등록해주면

 

Proxy 역할을 해서

• Thread가 생성되고, 재사용되는 시점에 부모 쓰레드의 SecurityContext와 strategy를 자식 비동기 쓰레드에 세팅
• Thread가 Pool에 반환되는 시점에 쓰레드의 SecurityContext를 clear한다

@EnableAsync
@Configuration
public class AsyncConfig implements AsyncConfigurer {

    @Override
    public Executor getAsyncExecutor() {
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();

        int corePoolSize = Runtime.getRuntime().availableProcessors(); // CPU 코어 수에 맞춰 스레드 풀 크기 설정
        int maxPoolSize = corePoolSize * 2; // 최대 풀 크기 - CPU 코어 수의 두 배
        int queueCapacity = 500; // 큐 용량 설정

        executor.setCorePoolSize(corePoolSize);
        executor.setMaxPoolSize(maxPoolSize);
        executor.setQueueCapacity(queueCapacity);
        executor.setThreadNamePrefix("AsyncExecutor-");

        ... 중략

        executor.initialize();

        return new DelegatingSecurityContextExecutor(executor); // 수정!!
    }

}

 

 

😄 MODE_INHERITABLETHREADLOCAL -> MODE_THREADLOCAL 로 수정

DelegatingSecurityContextExecutor 가 Thread 생성/재활용 시에 SecurityContext 전달을 모두 커버하고 있다면,

SecurityContext strategy를 굳이 MODE_INHERITALBETHREADLOCAL로 설정하여 생성 시에 SecurityContext 전달을 중복처리 할 필요가 없다

 

더 나아가 객체의 책임 입장에서 본다면, 

자식 비동기 쓰레드가 자신의 SecurityContext에 대한 결정을 부모 쓰레드의 Config가 결정해주는 것이 아니라

자식 비동기 쓰레드 자신의 Config 즉, AsyncConfig에서 정하는 것이 객체지향적으로도, 관리 포인트 적으로도 더 옳은거 같다

 

그래서 SecurityContext가 생성된 쓰레드 안에서만 전파 범위를 한정하는 MODE_THREADLOCAL로 수정해주었다

@Configuration
@EnableWebSecurity
@RequiredArgsConstructor
public class SpringSecurityConfig {

    @PostConstruct
    public void init() {
    	SecurityContextHolder.setStrategyName(SecurityContextHolder.MODE_THREADLOCAL); // 수정!!
    }
    ...생략

}

 

그러한 이유에서 Spring Security는 MODE_THREADLOCAL을 default값으로 설정하고 있는거 같다

즉, PostConstruct도 안해도 된다는 것!

 

---

👐 마치며

이번 Spring Security 이슈 해결을 통해서 Filter, Thread Pool 동작원리 / Servelet 컨테이너의 기여 시점 등을 추가로 알게된거 같다. 

그리고 결국 Spring Security는 이런것들 기반으로 만들어진 라이브러리일 뿐

Low level의 기반기술에 대해서 좀 더 학습하는 시간을 가져야겠다고 생각했다

다음에는 Thread Pool을 관리하는 Executor Service 구조와 원리

Servlet이 HTTP request를 어떻게 처리하는지에 에 대해서 좀더 깊게 공부해보고자 한다