중꺾마

async await 사용 시 promise 의 resolve 와 return; 차이

Z_Z — Tue, 10 Mar 2026 14:38:39 +0900

new Promise 로 return 을 하는 함수가 있다.

Promise 함수 내부에서 jquery 의 ajax 를 통해 api 요청을 한 후 count 값이 0일 경우 "return;" 을 사용했더니

promise 를 await 로 호출한 부분 이후의 로직이 실행되지 않았다.

이유는 new Promise 가 resolve 또는 reject 를 줄 때 까지 await 는 계속 대기하고 있기 때문에

이후 로직이 실행되지 않는다.

new Promise 함수 예시

function checkData() {
    return new Promise((resolve, reject) => {
        $.ajax({
            url: '/api/data',
            success: (response) => {
                if (response.dataCnt === 0) {
                    return;  // ❌ Promise resolve 안됨, await 대기
                }
                resolve(response);  // ✅ 올바른 방법
            }
        });
    });
}

// 호출
async function main() {
    const result = await checkData();  // dataCnt=0이면 여기서 영원히 대기!
    console.log('이 코드는 실행 안됨');  // ❌
}

해결 방법 3가지

1. resolve(undefined) 또는 return undefined;

success: (response) => {
    if (response.dataCnt === 0) {
        resolve();  // ✅ 빈 값으로 resolve
        // 또는 return undefined;  // ✅ Promise가 undefined로 resolve됨
    } else {
        resolve(response);
    }
}

2. 조건부 resolve(권장)

success: (response) => {
    if (response.dataCnt === 0) {
        resolve({ dataCnt: 0 });  // 명시적 상태 전달
        return;
    }
    resolve(response);
}

return; 이 아닌 resolve 상태 전달을 통해 await 에게 알려준다.
return; 을 하게 되면 함수만 종료되고 await 는 계속 대기상태에 빠진다.

3. async/await 으로 리팩토링(가장 깔끔)

async function checkData() {
    const response = await $.ajax({ url: '/api/data' });
    if (response.dataCnt === 0) {
        return { dataCnt: 0 };  // ✅ 자동으로 Promise resolve됨
    }
    return response;
}

3번째 방법은 new Promise 가 아닌 await + ajax 방식으로 바로 사용하는게 깔끔하다.
$.ajax() 는 Promise 를 반환하기 때문에 굳이 new Promise 를 사용할 필요가 없다.
return 하면 자동으로 Promise 가 resolve 된다.
new Promise 는 jQuery 이전 XMLHttpRequest 시대에 필요했던 패턴이라고 한다.

호출 측 처리

async function main() {
    const result = await checkData();
    if (result.dataCnt === 0) {
        console.log('데이터 없음');
        return;  // 여기서도 안전
    }
    console.log('데이터 처리:', result);  // ✅ 정상 실행
}

여기서 await 로 요청했을 때 정상적으로 처리된다.

img 태그 src 속성 아이폰 브라우저 CORS 문제 해결

Z_Z — Mon, 9 Mar 2026 13:21:42 +0900

Spring Boot, Thymeleaf 환경에서 URL 자체를 넘겨 HTML 의 img src 속성에 설정했다.

접근한 URL 과 불러오는 이미지 URL 자체의 도메인이 달랐기 때문에 CORS 문제가 터졌다.

안드로이드 폰에서는 이미지 자체를 잘 불러왔으나 아이폰에서는 안나와서 찾아보니

iOS 의 브라우저는 CORS 정책이 엄격하다고 한다.

그래서 여러가지 방법을 찾아보다가 가장 안정적이고 쉬운 방법은 backgroud-image css 설정을

사용해 화면에 보여주는걸로 해결했다.

처음에 시도했던 방법은 <object> 태그다.

Object 태그 사용 예시

<!-- 기존 object에 class 추가 -->
<object class="product-image thumbnail" 
        data="https://www.naver.com/image.jpg" 
        type="image/jpeg" 
        width="300" height="200">
  <img src="https://www.naver.com/image.jpg" alt="대체 이미지">
</object>

CSS background-image 사용 예시

<!-- 이렇게 하신 거죠? -->
<span th:style="'background-image: url(' + ${product.iconPath} + ')'"
      class="icon-span">
</span>

<object> VS span[background-image] 차이점 정리

항목	<object>	span + background-image
브라우저 CORS 검사	엄격 (iOS에서 차단)	없음 (CSS 백그라운드)
JS DOM 조작	내부 콘텐츠로 childNodes 에러	없음 (단순 CSS)
JS 에러 발생	null.childNodes 에러 가능	0% 발생
성능	별도 리소스 로드	CSS 단일 요청
iOS Safari 호환	SVG에서 문제 잦음	완벽
캐싱	별도 이미지 캐시	CSS 배경화면 캐시

background-image 장점

CORS 우회 : background-image 는 <img> 처럼 CORS 검사 안받는다.
JS 안전 : DOM 조작 없어서 childNodes 에러 0%
iOS 완벽 : Safari / Chrome 둘 다 문제없음
간단 : Thymeleaf 한 줄로 해결
유연 : hover, active 등 CSS 효과 무한

성능 최적화 팁

<span th:style="'background-image: url(' + ${product.iconPath} + ');background-size:contain'"
      class="icon-span"
      th:title="${product.name}"
      th:attr="data-icon=${product.iconPath}">
</span>

span + background-image 는 실무에서 크로스 브라우저 이미지 표시의 고전적인 최선책이다.

JS 에러도 없고 iOS 도 완벽하고 유지보수도 쉽다.

Spring Security OAuth2.0

Z_Z — Tue, 3 Mar 2026 13:40:23 +0900

1️⃣ OAuth 2.0이란 무엇인가?

OAuth 2.0은 권한 위임(Authorization) 프로토콜이다.

즉, 사용자의 비밀번호를 공유하지 않고 Access Token 을 이용해 다른 서버의 리소스(API) 에 접근하도록

하는 표준이다.

OAuth 2.0이 해결하는 문제

예를 들어 어떤 사이트에서 이런 버튼을 본적 있을것이다.

Google 로그인
Kakao 로그인
GitHub 로그인

이때 사용자는 아이디/비밀번호를 그 서비스에 직접 입력하지 않고

외부 인증 서버가 대신 인증을 해준다.

즉 구조는 이렇게 된다.

사용자 → 내 서비스 → Google 로그인 → Google 인증 → 내 서비스

내 서비스는 사용자의 비밀번호를 몰라도

Google 이 인증한 사용자라는 것만 확인하면 된다.

이것이 OAuth 2.0의 핵심 개념 = 권한 위임(Authorization Delegation)

2️⃣ OAuth 2.0 주요 구성요소

역할	설명
Resource Owner	사용자
Client	사용자의 리소스에 접근하려는 어플리케이션(우리 Spring 서버)
Authorization Server	로그인/동의를 받고 Access Token 을 발급하는 서버 (Keycloak, Auth Server)
Resource Server	API 서버

3️⃣ OAuth2 로그인 흐름 (Spring Security 기준)

사용자가 "Google 로그인" 클릭
Spring Security → Google 로그인 페이지 redirect(Google Authorization Server 로 redirect)
사용자가 Google 로그인
Google → authorization code 반환
=> Google 에서 로그인 후 Authorication Code 를 우리 시스템의 callback URL 로 반환
(/login/oauth2/code/google) 로 반환
Spring Security 서버 → access token 요청 (autho)
=> Spring Security 의 OAuth2LoginAuthenticationFilter 가 Authorication Code 를 Google 에 전송해
Access Token 획득
access token 으로 사용자 정보 요청
=> Access Token 으로 Google 사용자 정보(이메일, 프로필 등) 로드 후 세션 생성
Spring Security → 로그인 완료

사용자 → Spring Boot (/oauth2/authorization/google)
     ↓
Spring Security → Google Auth Server (리다이렉트)
     ↓
Google → Spring Boot (/login/oauth2/code/google?code=ABC123)  
     ↓  
Spring Security → Google (code=ABC123 → access_token 교환) ✓
     ↓
Spring Security → 사용자 정보 로드 → 로그인 성공!

요약

Authorization Code → Access Token → User Info

4️⃣ Spring Security에서 OAuth2

Spring Boot 에서는 spring-security-oauth2-client 로 쉽게 구현한다.

Spring Security 는 spring-boot-starter-oauth2-client 와 spring-security-oauth2 의존성을 추가하면

OAuth2 로그인을 쉽게 설정할 수 있다. 사용자가 소셜 로그인 버튼을 클릭하면

/oauth2/authorization/{provider} 로 요청이 가고, OAuth2LoginAuthenticationFilter 가 Authorization Code 를 받아

Access Token 을 교환한 후 사용자 정보를 로드한다.

주요 구성 요소

ClientRegistration: application.yml 에서 client-id, client-secret, redirect-uri 등을 등록한다.
OAuth2UserService: loadUser() 에서 외부 사용자 정보를 커스텀 처리(예 : DB 저장)
SecurityConfig: .oauth2Login() 으로 필터 체인에 OAuth2 를 추가하고, 성공/실패 핸들러를 정의한다.

application.yml 설정 예시

spring:
  security:
    oauth2:
      client:
        registration:
          google:
            client-id: your-client-id
            client-secret: your-secret
            redirect-uri: "{baseUrl}/login/oauth2/code/{registrationId}"

컨트롤러 없이도 로그인이 가능하다

접근 URL : /oauth2/authorication/google

5️⃣ OAuth2 vs JWT (헷갈리는 부분)

구분	OAuth2	JWT
역할	권한 위임 프로토콜	토큰 포맷
목적	외부 인증	인증 정보 전달
예	Google 로그인	access token

6️⃣ Spring Security에서 많이 사용하는 방식

OAuth2 Login
      ↓
사용자 정보 가져옴
      ↓
우리 DB에 사용자 저장
      ↓
JWT 발급
      ↓
JWT로 API 인증

즉

OAuth2 = 로그인
JWT = API 인증

7️⃣ OAuth2를 사용하는 대표 서비스

Google Login
Kakao Login
Naver Login
Apple Login
GitHub Login

Spring Security에서 OAuth2 핵심

외부 인증 서버에게 로그인을 맡기고
우리 서버는 토큰만 받아 인증 처리!

HandlerMethodArgumentResolver 란?

Z_Z — Wed, 7 Jan 2026 16:44:34 +0900

HandlerMethodArgumentResolver 란?

컨트롤러 메서드의 파라미터를 직접 해석해서 객체로 만들어주는 확장 포인트 인터페이스다

쉽게 말해, Spring MVC 에서 컨트롤러 메서드의 매개변수를 HTTP 요청에서 실제 인자 값으로

변환하는 인터페이스이다.

DispatcherServlet 이 HandlerMapping 에서 적절한 Mapping URL 을 찾아내고 HanlderAdapter 를 통해

적절한 컨트롤러 메서드를 호출한다.

여기서 컨트롤러 메서드를 호출하기 전 @RequestParam, @PathVariable, @RequestBody 등의 데이터들을

가공하거나 커스터마이징할 때 사용한다.

1️⃣ 왜 필요한가? (사용 이유)

@GetMapping("/users")
public String users(
    @RequestParam String id,
    @RequestHeader("Authorization") String token,
    HttpServletRequest request
)

❌ 문제점

컨트롤러마다 같은 파라미터 파싱 코드 반복
인증 정보, 사용자 정보, 헤더 값 처리 로직이 컨트롤러에 섞임
테스트 어려움 / 관심사 분리 안됨

그래서

컨트롤러 파라미터 하나로 의미 있는 객체를 자동 주입하고 싶을 때 HandlerMethodArgumentResolver를 사용한다.

2️⃣ HandlerMethodArgumentResolver 인터페이스

public interface HandlerMethodArgumentResolver {

    boolean supportsParameter(MethodParameter parameter);

    Object resolveArgument(
        MethodParameter parameter,
        ModelAndViewContainer mavContainer,
        NativeWebRequest webRequest,
        WebDataBinderFactory binderFactory
    ) throws Exception;
}

핵심 메서드 2개

메서드	역할
supportsParameter()	이 파라미터를 내가 처리할 수 있는지 판단
resolveArgument()	실제로 파라미터 객체를 만들어 반환

3️⃣ 동작 흐름 (중요 ⭐)

HTTP 요청
 ↓
DispatcherServlet
 ↓
HandlerMapping
 ↓
HandlerAdapter (Interceptor 처리 후 ArgumentResolver 체인 실행)
 ↓
컨트롤러 메서드 호출 전
 ↓
HandlerMethodArgumentResolver 목록 순회
   └ supportsParameter() == true ?
        └ resolveArgument() 실행
 ↓
컨트롤러 메서드 실행

컨트롤러는 파라미터 생성 과정을 전혀 모른다.

4️⃣ 실제 예제 (가장 이해 잘 되는 예)

목표

@GetMapping("/me")
public String me(@LoginUser User user) {
    return user.getName();
}

4-1️⃣ 커스텀 어노테이션

@Target(ElementType.PARAMETER)
@Retention(RetentionPolicy.RUNTIME)
public @interface LoginUser {
}

4-2️⃣ Resolver 구현

@Component
public class CustomResolver implements HandlerMethodArgumentResolver {

	@Override
	public boolean supportsParameter(MethodParameter parameter) {
		System.out.println("parameter === "+parameter.getParameterName());
		System.out.println("parameter === "+parameter.getParameterType());
		System.out.println("parameter === "+parameter.getParameterType().equals(int.class));
		return parameter.hasMethodAnnotation(LoginUser.class);
	}

	@Override
	public Object resolveArgument(MethodParameter parameter, ModelAndViewContainer mavContainer,
			NativeWebRequest webRequest, WebDataBinderFactory binderFactory) throws Exception {
		HttpServletRequest request =
            (HttpServletRequest) webRequest.getNativeRequest();

        // 예: 세션에서 사용자 조회
        HttpSession session = request.getSession(false);
        return session != null ? session.getAttribute("LOGIN_USER") : null;
	}
}

4-3️⃣ Spring MVC에 등록

@Configuration
public class WebMvcConfig implements WebMvcConfigurer {
	
	@Autowired
	CustomResolver customResolver;
	
	@Override
	public void addArgumentResolvers(List<HandlerMethodArgumentResolver> resolvers) {
		resolvers.add(customResolver);
	}
}

4-4️⃣ 컨트롤러 사용

@GetMapping("/me")
public String me(@LoginUser User user) {
    return user.getName();
}

컨트롤러 메서드에 오기전에 파라미터에 대한 공통 작업들을 처리해놓으면 깔끔해진다.

5️⃣ 언제 쓰면 좋은가?

✅ 쓰면 좋은 경우

로그인 사용자 주입(@LoginUser)
JWT → User 객체 변환
공통 헤더 파싱( @ClientIp, @ApiVersion )
Request → 도메인 객체 변환 로직이 반복될 때

❌ 굳이 안 써도 되는 경우

단순 @RequestParam, @PathVariable
컨트롤러마다 다른 파싱 로직
일회성 처리

6️⃣ Spring Security 와의 관계 (중요)

public String test(@AuthenticationPrincipal UserDetails user)

➡ 내부적으로 HandlerMethodArgumentResolver 구현체가 있음

람다식이란?

Z_Z — Mon, 5 Jan 2026 14:12:02 +0900

1️⃣ 람다식이란?

JDK 1.8 부터 추가된 람다식(Lambda Expression)은 메서드를 하나의 식(Expression)으로 표현한것이다.

람다식은 함수를 간략하면서도 명확한 식으로 표현할 수 있다.

이러한 람다식은 메서드의 이름과 반환값을 제거할 수 있어 "익명함수" 라고도 한다.

기본 문법

(매개변수) -> { 실행문 }

예시

x -> x + 1
(a, b) -> a + b
() -> System.out.println("hello")

✔ 함수형 인터페이스(메서드가 1개인 인터페이스)를 구현할 때 사용

✔ 함수형 인터페이스는 @FuntionalInterface 어노테이션을 사용한다.

2️⃣ Spring에서 람다식이 쓰이는 이유

Spring 5 / Spring Boot 2 이후부터

XML 설정 ❌
익명 클래스 ❌
람다식 + DSL 스타일 ⭕

➡ 설정 코드가 짧아지고 가독성이 좋아짐

3️⃣ Spring Security에서 가장 많이 보는 람다식 형태

예전 방식 (익명 클래스 느낌)

http
    .authorizeRequests()
    .anyRequest().authenticated()
    .and()
    .formLogin();

람다식 방식 (Spring Security 5.4+ / 6)

http
    .authorizeHttpRequests(auth -> auth
        .anyRequest().authenticated()
    )
    .formLogin(form -> form
        .loginPage("/login")
    );

람다식 구조 뜯어보면

auth -> auth.anyRequest().authenticated()

auth : AuthorizationManagerRequestMatcherRegistry
-> : 람다식
내부에서 설정을 조립

public HttpSecurity authorizeHttpRequests(
        Customizer<AuthorizeHttpRequestsConfigurer<HttpSecurity>.AuthorizationManagerRequestMatcherRegistry> authorizeHttpRequestsCustomizer)
        throws Exception {
    ApplicationContext context = getContext();
    authorizeHttpRequestsCustomizer
        .customize(getOrApply(new AuthorizeHttpRequestsConfigurer<>(context)).getRegistry());
    return HttpSecurity.this;
}

// Customizer
@FunctionalInterface
public interface Customizer<T> {

	/**
	 * Performs the customizations on the input argument.
	 * @param t the input argument
	 */
	void customize(T t);

	/**
	 * Returns a {@link Customizer} that does not alter the input argument.
	 * @return a {@link Customizer} that does not alter the input argument.
	 */
	static <T> Customizer<T> withDefaults() {
		return (t) -> {
		};
	}

}

Customizer 형태로 제네릭을 받고 @FuntionalInterface 어노테이션을 통해 함수형 인터페이스로 설정했다.

customize(T t) 메서드는 return 값이 없는 set 메서드만 존재한다.

4️⃣ Spring에서 자주 쓰이는 람다식 형태들

① Consumer<T> 형태 (가장 흔함)

Consumer<HttpSecurity> consumer = http -> {
    http.csrf().disable();
};

// Consumer 내부
@FunctionalInterface
public interface Consumer<T> {

    void accept(T t);
    
    default Consumer<T> andThen(Consumer<? super T> after) {
        Objects.requireNonNull(after);
        return (T t) -> { accept(t); after.accept(t); };
    }
}

Consumer 는 인자값 한개만 받고 아무것도 리턴하지 않는다.

단어 뜻대로 소비자와 같이 인자값만 받아 처리하고 끝난다.

람다식으로는 T -> void 로 표현한다.

Spring 내부 메서드

void authorizeHttpRequests(Consumer<AuthorizeHttpRequestsConfigurer> configurer)

그래서 이렇게 쓴다

http.authorizeHttpRequests(auth -> {
    auth.anyRequest().authenticated();
});

② Runnable 형태

http.csrf(csrf -> csrf.disable());

③ Predicate / Function 형태

request -> request.getMethod().equals("GET")

Spring Security RequestMatcher 구현할 때 자주 등장한다.

5️⃣ @Bean 등록에서도 람다식 사용

CommandLineRunner

@Bean
CommandLineRunner runner() {
    return args -> {
        System.out.println("서버 시작!");
    };
}

ApplicationRunner

@Bean
ApplicationRunner runner() {
    return args -> {
        System.out.println("App 실행");
    };
}

6️⃣ Spring Scheduling에서 람다식

taskScheduler.schedule(
    () -> System.out.println("작업 실행"),
    new CronTrigger("0/10 * * * * *")
);

Runnable 을 람다로 전달

7️⃣ 핵심 요약

구분	내용
Spring 람다식	Java 람다식 + Spring DSL 설정
기본 형태	(args) -> { 실행문 }
가장 흔한 타입	Consumer<T>
주 사용처	Security, WebFlux, Scheduler, Bean 등록
장점	코드 간결, 가독성 ↑, XML 제거

HttpSession 생명주기 (SecurityContextHolderFilter, HttpSessionSecurityContextRepository)

Z_Z — Wed, 31 Dec 2025 10:17:38 +0900

1️⃣ HttpSession 이란?

Servlet 컨테이너(Tomcat) 가 관리하는 서버 측 세션 객체
클라이언트당 1개
식별자는 JSESSIONID 쿠키
Spring Security 는 필요할 때만 HttpSession 을 사용(기본 설정)
보통 Spring Security 인증 성공 후 SecurityContextRepository 를 통해 인증정보를 저장한다.

2️⃣ HttpSession은 언제 생성될까?

❌ 자동 생성되지 않는다

HttpSession 은 요청이 왔다고 해서 무조건 생성되지 않는다.

// HttpServletRequest request
request.getSession(false); // 세션 없으면 null
request.getSession();      // 없으면 생성

✅ 생성되는 대표적인 경우

① 로그인 성공 시 (가장 대표적)

Spring Security 가 인증에 성공하고 인증정보를 세션에 저장하려는 순간에 생성된다.
HttpSessionSecurityContextRepository 가 대표적이다.
기본적으로 Spring Security 6 부터는 SecurityContextRepository 에 직접적으로 인증객체(Authentication) 을 저장해줘야 한다.

➡ SuccessHandler 내부

본인은 SuccessHandler 에 SecurityContextRepository 에 저장하는 로직을 넣었다.

// SuccessHandler
public class CustomAuthenticationSuccessHandler extends SavedRequestAwareAuthenticationSuccessHandler {
	private final SecurityContextRepository securityContextRepository;

	private SecurityContextHolderStrategy securityContextHolderStrategy = SecurityContextHolder
		.getContextHolderStrategy();
	
	public CustomAuthenticationSuccessHandler(SecurityContextRepository securityContextRepository) {
		this.securityContextRepository = securityContextRepository;
	}
    
    @Override
	public void onAuthenticationSuccess(HttpServletRequest request, HttpServletResponse response,
			Authentication authentication) throws ServletException, IOException {
		//set session registry
		sessionRegistry.registerNewSession(RequestContextHolder.currentRequestAttributes().getSessionId(), authentication.getPrincipal());

		SecurityContext context = securityContextHolderStrategy.createEmptyContext();
		context.setAuthentication(authentication);
		securityContextRepository.saveContext(context, request, response);
    }
    
}

➡ HttpSessionSecurityContextRepository 내부

// HttpSessionSecurityContextRepository 내부

@Override
public void saveContext(SecurityContext context, HttpServletRequest request, HttpServletResponse response) {
    SaveContextOnUpdateOrErrorResponseWrapper responseWrapper = WebUtils.getNativeResponse(response,
            SaveContextOnUpdateOrErrorResponseWrapper.class);
    if (responseWrapper == null) {
        saveContextInHttpSession(context, request);
        return;
    }
    responseWrapper.saveContext(context);
}

private void saveContextInHttpSession(SecurityContext context, HttpServletRequest request) {
    if (isTransient(context) || isTransient(context.getAuthentication())) {
        return;
    }
    SecurityContext emptyContext = generateNewContext();
    if (emptyContext.equals(context)) {
        HttpSession session = request.getSession(false);
        removeContextFromSession(context, session);
    }
    else {
        boolean createSession = this.allowSessionCreation;
        HttpSession session = request.getSession(createSession);
        setContextInSession(context, session);
    }
}

② 세션에 값을 명시적으로 저장할 때

아래처럼 saveContextInHttpSession 메서드 내에 request.getSession(createSession); 가 존재한다.

if (emptyContext.equals(context)) {
    HttpSession session = request.getSession(false);
    removeContextFromSession(context, session);
}
else {
    boolean createSession = this.allowSessionCreation;
    HttpSession session = request.getSession(createSession);
    setContextInSession(context, session);
}

if (emptyContext.equals(context)) {} 를 통해 같은 SecurityContext 가 존재하면 존재하는 HttpSession 을 호출한다.

아닐 경우 새로운 HttpSession 을 넘겨 새로 생성하고 "setContextInSession(context, session)" 을 통해

"SPRING_SECURITY_CONTEXT" 라는 이름으로 HttpSession 에 setAttribute 설정한다.

public static final String SPRING_SECURITY_CONTEXT_KEY = "SPRING_SECURITY_CONTEXT";
private String springSecurityContextKey = SPRING_SECURITY_CONTEXT_KEY;

private void setContextInSession(SecurityContext context, HttpSession session) {
    if (session != null) {
        session.setAttribute(this.springSecurityContextKey, context);
        if (this.logger.isDebugEnabled()) {
            this.logger.debug(LogMessage.format("Stored %s to HttpSession [%s]", context, session));
        }
    }
}

생성 흐름 요약

[요청]
 ↓
SecurityContextRepository 가
"세션에 인증정보 저장 필요"
 ↓
HttpSession 생성
 ↓
JSESSIONID 쿠키 응답에 포함

3️⃣ HttpSession은 언제 설정(값 저장)될까?

핵심 저장 대상

SecurityContext
즉, Authentication 인증 객체

로그인 성공 시 흐름

1️⃣ 사용자가 로그인 요청

2️⃣ 인증 성공 → Authentication 생성

3️⃣ SecurityContext 에 저장

private SecurityContextHolderStrategy securityContextHolderStrategy = SecurityContextHolder
		.getContextHolderStrategy();
SecurityContext context = securityContextHolderStrategy.createEmptyContext();
context.setAuthentication(authentication);

4️⃣ SecurityContextHolderFilter 종료 시점

5️⃣ HttpSessionSecurityContextRepository.saveContext()

private final SecurityContextRepository securityContextRepository;
public CustomAuthenticationSuccessHandler(SecurityContextRepository securityContextRepository) {
    this.securityContextRepository = securityContextRepository;
}

securityContextRepository.saveContext(context, request, response);

// HttpSessionSecurityContextRepository 내부
public static final String SPRING_SECURITY_CONTEXT_KEY = "SPRING_SECURITY_CONTEXT";
private String springSecurityContextKey = SPRING_SECURITY_CONTEXT_KEY;
private void setContextInSession(SecurityContext context, HttpSession session) {
    if (session != null) {
        session.setAttribute(this.springSecurityContextKey, context);
        if (this.logger.isDebugEnabled()) {
            this.logger.debug(LogMessage.format("Stored %s to HttpSession [%s]", context, session));
        }
    }
}

즉 정리하면

SecurityContext는 요청 중엔 ThreadLocal
요청 종료 시 HttpSession에 저장

4️⃣ 이후 요청에서 HttpSession은 언제 사용될까?

클라이언트 요청이 오면

브라우저가 JSESSIONID 쿠키 전송
Tomcat이 기존 HttpSession 조회
SecurityContextHolderFilter 실행
HttpSessionSecurityContextRepository.loadContext()
ThreadLocal(SecurityContextHolder)에 복원

5️⃣ HttpSession은 언제 소멸될까?

✅ ① 로그아웃 시

/logout

기본 동작

SecurityContextHolder.clearContext()
HttpSession.invalidate();

✅ ② 세션 타임아웃

기본값: 30분 (Tomcat)

server:
  servlet:
    session:
      timeout: 30m

➡ 지정 시간 동안 요청이 없으면 자동 소멸

✅ ③ 서버 재시작

메모리 세션 → 전부 소멸
(Redis, JDBC 세션이면 유지 가능)

❌ 단순 요청 종료 ≠ 세션 소멸

요청이 끝나도 세션은 살아 있다

6️⃣ 전체 생명주기 한눈에 보기

[첫 요청]
 ↓
세션 없음
 ↓
로그인 성공
 ↓
HttpSession 생성
 ↓
SecurityContext 저장
 ↓
JSESSIONID 발급
--------------------------------
[다음 요청]
 ↓
JSESSIONID 전달
 ↓
세션 조회
 ↓
SecurityContext 복원 (ThreadLocal)
 ↓
요청 처리
 ↓
ThreadLocal 비움
--------------------------------
[로그아웃 / 타임아웃]
 ↓
HttpSession.invalidate()
 ↓
세션 소멸

7️⃣ Spring Security 6 관련 중요한 옵션

세션 정책

http
    .sessionManagement(session -> session
        .sessionCreationPolicy(SessionCreationPolicy.IF_REQUIRED)
    );

정책	설명
ALWAYS	무조건 생성
IF_REQUIRED	필요할 때만 (기본값)
NEVER	생성하지 않음
STATELESS	아예 사용 안 함 (JWT)

8️⃣ 요약 한 줄 정리

HttpSession은 로그인 성공 등 “서버가 상태를 저장해야 할 순간”에 생성되고,
SecurityContext는 요청 종료 시 세션에 저장되며,
로그아웃·타임아웃·서버 종료 시 소멸된다.

SessionManagementFilter 는 매 요청마다 인증된 세션인지를 어떻게 판단하나? (Feat. SecurityContextHolderFilter)

Z_Z — Wed, 17 Dec 2025 13:51:29 +0900

SessionManagementFilter 는 로그인 인증 시점과 인증된 사용자의 재 요청일 경우 실행되는 필터이다.

SessionManagementFilter 는 "세션 자체" 를 보고 인증 여부를 판단하지 않고, SecurityContext 안

Authentication 인증 객체의 상태를 보고 판단한다.

1️⃣ 핵심 결론 한 줄 요약

SessionManagementFilter 가 "인증된 세션인가?" 를 확인하는 방법은

SecurityContextHolder.getContext().getAuthentication()

여기서 가져온 Authentication 이

null 이 아니고

isAuthenticated() == true

AnonymousAuthenticationToken 이 아님

이면 인증된 사용자 요청으로 본다.

2️⃣ 왜 “세션”을 직접 안 볼까?

Spring Security 에서 인증 상태의 단일 기준은 오직 이것이다.

SecurityContext → Authentication

세션은 단지 SecurityContext 를 저장하는 저장소일 뿐이다.

[HttpSession]
   └── SPRING_SECURITY_CONTEXT
           └── SecurityContext
                   └── Authentication

세션이 있어도 Authentication 이 없으면 ❌
세션이 없어도 (JWT 등) Authentication 이 있으면 ⭕

3️⃣ SessionManagementFilter 내부 흐름 (중요)

public class SessionManagementFilter extends GenericFilterBean {
	static final String FILTER_APPLIED = "__spring_security_session_mgmt_filter_applied";
	...
    
    if (request.getAttribute(FILTER_APPLIED) != null) {
        chain.doFilter(request, response);
        return;
    }
    request.setAttribute(FILTER_APPLIED, Boolean.TRUE);
    if (!this.securityContextRepository.containsContext(request)) {
    	Authentication authentication = this.securityContextHolderStrategy.getContext().getAuthentication();
        if (this.trustResolver.isAuthenticated(authentication)) {
        	...
        }
    }
}

Filter 에서 가장 먼저 확인하는건 요청 속성(request attribute)을 확인하여 이미 처리된 인증인지를 판단한다.

✔ 처리된 인증인지를 판단하는 요청 속성

static final String FILTER_APPLIED = "__spring_security_session_mgmt_filter_applied";

if (request.getAttribute(FILTER_APPLIED) != null) {
    chain.doFilter(request, response);
    return;
}
request.setAttribute(FILTER_APPLIED, Boolean.TRUE);

Http Request 의 속성을 확인하여 Filter 에 대한 내용이 존재하는지 판단하여 이미 처리된 인증인지 판별한다.

인증되지 않았다면 인증시작 전 setAttribute 를 통해 인증을 했다라고 속성값을 설정한다.

✔ HttpSession 에 SpringSecurityContext 의 KEY 값 존재 여부 판단

if (!this.securityContextRepository.containsContext(request)) {
	Authentication authentication = this.securityContextHolderStrategy.getContext().getAuthentication();
	...	
}

// HttpSessionSecurityContextRepository 의 내부로직
public static final String SPRING_SECURITY_CONTEXT_KEY = "SPRING_SECURITY_CONTEXT";
private String springSecurityContextKey = SPRING_SECURITY_CONTEXT_KEY;

@Override
public boolean containsContext(HttpServletRequest request) {
    HttpSession session = request.getSession(false);
    if (session == null) {
        return false;
    }
    return session.getAttribute(this.springSecurityContextKey) != null;
}

여기서 인증절차 확인인 Request 요청정보에 Security 속성값이 존재할 경우 SecurityContextHolder 에서

SecurityContext 안에 있는 Authentication 인증객체를 불러온다.

✔ Authentication 인증 객체를 불러온 후 인증된 요청인지 확인한다.

if (this.trustResolver.isAuthenticated(authentication)) {
	try {
        this.sessionAuthenticationStrategy.onAuthentication(authentication, request, response);
    }
}

// AuthenticationTrustResolver 내부로직
public interface AuthenticationTrustResolver {
	...
    default boolean isAuthenticated(Authentication authentication) {
		return authentication != null && authentication.isAuthenticated() && !isAnonymous(authentication);
	}
}

위 인증된 요청의 조건이 만족된다면 SessionAuthenticationStrategy 를 실행한다.

4️⃣ SessionAuthenticationStrategy가 뭐냐?

SessionManagementFilter 는 직접 처리하지 않고 아래 전략들에게 위임한다.

주요 전략들

전략	역할
SessionFixationProtectionStrategy	세션 고정 공격 방어
ConcurrentSessionControlAuthenticationStrategy	동시 세션 제한
RegisterSessionAuthenticationStrategy	SessionRegistry 등록
CompositeSessionAuthenticationStrategy	위 전략들 묶음

5️⃣ “한 번만” 실행되는 이유 (중요 포인트)

SessionManagementFilter 는

이미 처리된 인증이면 다시 실행하지 않습니다.

이를 위해 요청 속성(request attribute)을 사용한다.

static final String FILTER_APPLIED = "__spring_security_session_mgmt_filter_applied";
private void doFilter(HttpServletRequest request, HttpServletResponse response, FilterChain chain)
			throws IOException, ServletException {
    if (request.getAttribute(FILTER_APPLIED) != null) {
        chain.doFilter(request, response);
        return;
    }
    request.setAttribute(FILTER_APPLIED, Boolean.TRUE);
}

같은 요청 안에서 중복 실행 ❌
로그인 성공 직후 딱 한 번만 ⭕

6️⃣ 그럼 “로그인 성공 시점”은 어떻게 감지할까?

로그인 성공 흐름

UsernamePasswordAuthenticationFilter
   ↓ (인증 성공)
SecurityContextHolder에 Authentication 저장
   ↓
SessionManagementFilter 실행
   ↓
"오, Authentication 이 생겼네?"
   ↓
SessionAuthenticationStrategy 실행

로그인 인증필터가 먼저 인증
그 결과를 SessionManagementFilter 가 감지
여기서 SessionAuthenticationStrategy 전략들을 통해 동일 세션 관리 등을 처리한다.

7️⃣ 그럼 다음 요청에서 인증은 어떻게 복구되나?

인증된 사용자가 새로운 요청을 또 보냈을 경우 SecurityContextHolderFilter 가

HttpSessionSecurityContextRepository 에서 HttpSession 내 SecurityContext 를 조회하여 확인한다.

요청 시작 시 흐름 (매 요청마다 반복)

[클라이언트 요청]
   ↓
SecurityContextHolderFilter
   ↓
HttpSessionSecurityContextRepository
   ↓
HttpSession에서 SecurityContext 조회
   ↓
SecurityContextHolder.setContext()

SecurityContextHolderFilter 내부 로직

public class SecurityContextHolderFilter extends GenericFilterBean {
    private void doFilter(HttpServletRequest request, HttpServletResponse response, FilterChain chain)
                throws ServletException, IOException {
        if (request.getAttribute(FILTER_APPLIED) != null) {
            chain.doFilter(request, response);
            return;
        }
        request.setAttribute(FILTER_APPLIED, Boolean.TRUE);
        Supplier<SecurityContext> deferredContext = this.securityContextRepository.loadDeferredContext(request);
        try {
            this.securityContextHolderStrategy.setDeferredContext(deferredContext);
            chain.doFilter(request, response);
        }
        finally {
            this.securityContextHolderStrategy.clearContext();
            request.removeAttribute(FILTER_APPLIED);
        }
    }
}

✔ this.securityContextRepository.loadDeferredContext(request);

SecurityContextRepository 내 SecurityContext 를 가져온다.

✔ this.securityContextHolderStrategy.setDeferredContext(deferredContext);

가져온 SecurityContext 를 해당 워커 스레드 내 SecurityContextHolder 에 set 하여 설정한다.

새로운 요청이 들어와도 SecurityContextHolder 를 통해 해당 스레드에도 SecurityContext 를 설정한다.

요청 예 (일반 API 호출)

[클라이언트 요청 + JSESSIONID]
   ↓
SecurityContextHolderFilter
   ↓
HttpSessionSecurityContextRepository.loadContext()
   ↓
HttpSession에서 SecurityContext 조회
   ↓
SecurityContextHolder.setContext(context)

결과

이전 로그인 정보가 그대로 복구
이후 필터들은 이미 인증된 요청으로 인식

Spring Security6 SecurityContextHolderFilter 동작과 ThreadLocal Clear 시점

Z_Z — Tue, 16 Dec 2025 16:26:46 +0900

Spring Security 6 시점에서 SecurityContextHolderFilter 로 변경되었고, SecurityContextHolderFilter 는

사용자의 HTTP 요청이 들어왔을 때 SecurityContext 를 불러와 워커 스레드의 ThreadLocal 에 저장한다.

1️⃣ Tomcat 워커 스레드와 요청 처리

클라이언트 → HTTP 요청
Tomcat 워커 스레드 하나가 요청을 할당받는다.
Tomcat 의 메인 쓰레드는 어플리케이션 실행만 담당한다.
이 워커 스레드는 요청 수명 동안 재사용됨(Thread Pool)

그래서 ThreadLocal 정리가 매우 중요함

2️⃣ SecurityContextHolderFilter의 역할 (Spring Security 6 핵심)

Spring Security 6 부터는 예전의 SecurityContextPersistenceFilter 대신

SecurityContextHolderFilter 가 사용된다.

요청 시작 시

[요청 진입]
→ SecurityContextHolderFilter

1. SecurityContextRepository 에서 SecurityContext를 로드한다.

보통 HttpSessionSecurityContextRepository
또는 JWT / Stateless 방식이면 다른 구현체

2. SecurityContextHolder.setContext(context)

내부적으로 ThreadLocal 에 저장됨

public class SecurityContextHolderFilter extends GenericFilterBean {
	
    ...
    
	@Override
	public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
			throws IOException, ServletException {
		doFilter((HttpServletRequest) request, (HttpServletResponse) response, chain);
	}

	private void doFilter(HttpServletRequest request, HttpServletResponse response, FilterChain chain)
			throws ServletException, IOException {
		if (request.getAttribute(FILTER_APPLIED) != null) {
			chain.doFilter(request, response);
			return;
		}
		request.setAttribute(FILTER_APPLIED, Boolean.TRUE);
		Supplier<SecurityContext> deferredContext = this.securityContextRepository.loadDeferredContext(request);
		try {
			this.securityContextHolderStrategy.setDeferredContext(deferredContext);
			chain.doFilter(request, response);
		}
		finally {
			this.securityContextHolderStrategy.clearContext();
			request.removeAttribute(FILTER_APPLIED);
		}
	}
}

try {} 문 바로 위쪽에 securityContextRepository 에서 SecurityContext 를 로드한다.

가져온 SecurityContext 를 setDeferredContext(deferredContext) 를 통해 ThreadLocal(기본 전략)에 저장한다.

이후 filterChain 에 걸린 모든 Filter / Controller / Service 의 동일 스레드에서 접근 가능하다.

3️⃣ Filter Chain 전체에서의 사용

이후 필터

AuthenticationFilter
AuthorizationFilter
Custom Filter
Controller
Service
Repository

모든 같은 워커 스레드에서 실행되므로

SecurityContextHolder.getContext().getAuthentication()

를 사용하면 항상 동작한다.

4️⃣ 요청 종료 시 – finally에서 정리

이 부분이 핵심이다.

SecurityContextHolderFilter 내부 구조

try {
    // SecurityContext 로드 → ThreadLocal 저장
    filterChain.doFilter(request, response);
} finally {
    //   반드시 실행됨
    SecurityContextHolder.clearContext();
}

왜 반드시 clear 해야 할까?

Tomcat 워커 스레드는 다음 요청에도 재사용된다.
ThreadLocal 에 남아 있으면 다른 사용자가 이전 사용자 인증정보를 참조하는 치명적인 보안 이슈가 발생한다.

✔ 필터 체인이 정상 종료되든
✔ 예외가 발생하든

→ finally 에서 무조건 해당 워커 스레드의 SecurityContextHolder 정보를 제거

5️⃣ Spring Security 6에서의 정확한 정리 타이밍

요청 시작
→ SecurityContext 로드
→ ThreadLocal 저장
→ FilterChain 전체 실행
→ finally 에서 ThreadLocal clear
→ Tomcat 스레드 반환

6️⃣ 한 문장으로 요약

Spring Security 6 에서 SecurityContextHolderFilter 는 요청 시작 시 SecurityContext 를 ThreadLocal에 저장하고,

필터 체인이 끝난 후 finally 블록에서 반드시 ThreadLocal 을 비워 Tomcat 워커 스레드 재사용 시 보안 문제를 방지한다.

Spring Security ConcurrentSessionFilter, SessionManagementFilter

Z_Z — Tue, 16 Dec 2025 15:09:24 +0900

ConcurrentSessionFilter 와 SessionManagementFilter 는 세션 기반 보안과 관련 있지만, 역할과 책임이 명확히 다르다.

1️⃣ SessionManagementFilter

"이 요청의 세션 상태가 정상적인가?" 를 관리하는 필터이다.

SessionManagementFilter 는 사용자 로그인 인증 시점과 인증된 요청 진입 시에 동작한다.

~~SessionManagementFilter 는 사용자가 인증되었을 시점에 SessionAuthenticationStrategy 들을~~

~~실행시켜준다.~~

Spring Security 6 부터는 기본 설정에서 SessionManagementFilter 가 아닌 각 인증 필터(예: UsernamePasswordAuthenticationFilter) 가 직접 SessionAuthenticationStrategy 를 호출하는 방식으로 이동해서,

매 요청마다 세션을 강제로 읽지 않도록 개선되었다.

수행하는 주요 기능

✅ 1. 세션 고정 공격(Session Fixation) 방어

로그인 성공 시
- 기존 세션을 새 세션으로 교체 또는 세션 ID 변경

sessionManagement()
    .sessionFixation().changeSessionId();

✅ 2. 인증 이후 세션 정책 적용

인증된 사용자가 새 요청을 보낼 때
세션이 존재해야 하는지 / 생성 가능한지 판단

.sessionCreationPolicy(SessionCreationPolicy.IF_REQUIRED)

✅ 3. 세션 무효 상태 감지

이미 만료되었거나 invalid 된 세션으로 접근 시
설정된 전략(SessionAuthenticationStrategy) 실행

✅ 4. Concurrent Session 제어와 연결점

Spring Security 에 maximumSessions() 설정이 있을 경우
내부적으로 ConcurrentSessionControlAuthenticationStrategy 호출

즉, SessionManagementFilter 는 "로그인 시점의 세션 정책 총괄 관리자" 이다.

동작 시점

시점	설명
로그인 성공 직후	세션 고정 방지, 신규 세션 발급
인증된 요청 진입	세션 상태 검증

2️⃣ ConcurrentSessionFilter

이미 존재하는 모든 세션에 대해, 요청이 들어올 때마다 해당 세션이 만료(expire) 되었는지 SessionRegistry 를 통해 조회한다.
ConcurrentSessionFilter 는 로그인 시점이 아니라 모든 요청마다 검사한다.

핵심 역할

동시 로그인 제한(maximumSession)이 걸린 상태에서

이미 만료 처리된 세션으로 요청이 들어왔는지 검사

수행하는 주요 기능

✅ 1. SessionRegistry 기반 세션 검증

현재 요청의 세션 ID 기준으로 SessionRegistry 에서 세션 상태 검사

✅ 2. 만료된 세션이면 즉시 차단

다른 로그인으로 인해 expire 처리된 세션이라면
- 로그아웃 처리 (SecurityContextHolder 비움)
- SessionInformationExpiredStrategy 실행

SessionManagementFilter 가 "특정 세션을 만료 상태로 표시" 했다면, ConcurrentSessionFilter 는 그 이후 들어오는 요청마다

세션 만료 상태를 보고 만료된 세션은 로그아웃 처리를 한다.

http
  .sessionManagement()
  .maximumSessions(1)
  .expiredUrl("/session-expired");

✅ 3. 요청 단위 필터

로그인 시점 ❌
모든 요청마다 검사 ⭕

동작 시점

시점	설명
매 요청마다	현재 세션이 유효한지 확인
동시 로그인 발생 후	이전 세션 차단

3️⃣ 둘의 차이 요약 (아주 중요)

구분	SessionManagementFilter	ConcurrentSessionFilter
주 목적	세션 정책 적용	동시 로그인 세션 차단
실행 시점	인증 성공 시 + 요청 진입 시	모든 요청
세션 생성/교체	⭕	❌
세션 만료 여부 검사	간접	직접
SessionRegistry 사용	간접	직접
maximumSessions 연관	정책 설정	실제 차단

4️⃣ Spring Security 6 기준 필터 체인 위치

SecurityContextHolderFilter
  ↓
LogoutFilter
  ↓
ConcurrentSessionFilter   ← 여기!
  ↓
SessionManagementFilter
  ↓
AuthenticationFilter

5️⃣ 한 문장으로 정리

SessionManagementFilter
- “로그인 후 세션을 어떻게 만들고 유지할지 결정하는 관리자”
ConcurrentSessionFilter
- “이미 만료된 세션으로 접근하는 사용자를 현관에서 차단하는 경비”

브라우저 렌더링 과정

Z_Z — Thu, 11 Dec 2025 15:16:43 +0900

브라우저가 클라이언트로부터 요청을 받고 서버로부터 리소스를 받아 처리하는 과정이다.

1. 클라이언트가 서버에 접근 (HTTP Request)

사용자가 URL 을 입력하거나 링크를 클릭하면 브라우저는 다음을 수행한다.

DNS 조회 → IP 주소 획득
서버와 TCP 연결
HTTPS 면 SSL/TLS 핸드셰이크
서버에 HTTP 요청 전송(GET /index.html)

2. 서버가 HTML, CSS, JS 등 리소스를 응답

서버는 요청된 HTML 문서를 먼저 보내고,

HTML 에 링크된 CSS/JS/이미지 파일들을 동시에 추가 요청하게 된다.

3. HTML 파싱 → DOM 트리(DOM Tree) 생성

HTML 문서는 문자열이므로 이를 분석해 DOM(Document Object Model) 트리를 만든다.

예:

<html>
  <body>
    <div>Hello</div>
  </body>
</html>

→ DOM Tree 예 (단순화)

HTML
 └─ BODY
     └─ DIV
         └─ "Hello"

DOM Tree 는 자바스크립트가 조작할 수 있는 브라우저 내부의 메모리 구조다.

4. CSS 파싱 → CSSOM 트리(CSS Object Model Tree) 생성

CSS 파일도 문자열이므로 브라우저는 이를 파싱해 CSSOM 을 만든다.

예:

div { color: red; }

CSSOM Tree 예:

Stylesheet
 └─ Rule: div
        └─ color: red

5. DOM + CSSOM 합침 → Render Tree(렌더 트리) 생성

이제 브라우저는 DOM 과 CSSOM 을 결합해 실제 화면에 표시할 요소만 포함한 렌더 트리를 만든다.

✔ display: none 은 렌더트리에 포함되지 않음

✔ visibility: hidden 은 포함되지만 보이지 않는 상태로 렌더링된다.

렌더 트리 예:

RenderRoot
 └─ RenderBlock(html)
      └─ RenderBlock(body)
           └─ RenderText(div, style: color:red)

6. Layout(레이아웃 또는 Reflow)

렌더 트리가 만들어지면, 이제 브라우저는 각 요소의 크기(width / height), 위치(x,y) 를 계산한다.

화면에 요소가 어디에 배치되는지
요소마다 박스 모델(Box Model) 을 계산
CSS 속성(Flex, Grid, position, margin 등) 모두 반영

️ 7. Painting(페인팅)

계산된 렌더 트리를 기반으로 픽셀 단위로 화면에 그리기 시작한다.

배경색
텍스트
테두리
그림자
이미지

등을 GPU / CPU 가 그려서 실제 화면에 표시한다.

⚙️ 8. JavaScript 실행 (파싱 + 실행)

HTML 파싱 도중 <script> 태그를 만나면

JS 파일 다운로드
JS 파싱(AST 생성 → 바이트코드)
JS 실행

기본적으로 JS 는 DOM 생성 작업을 중단시키는 블로킹 요소

→ async/defer로 비동기 로딩 가능

JS가 DOM 을 변경하면

레이아웃(Layout) 대규모 재계산(Reflow)
페인팅(Paint) 재수행(Repaint)

이 발생할 수 있다.

Javascript 파싱/실행은 브라우저의 JS 엔진(Chrome V8 등) 이 처리하며, 파싱 과정에서 실제로 "바이너리 형태"로 변환된다.

1. JavaScript 파싱은 브라우저의 JS 엔진이 한다.

Chrome → V8 엔진
Edge → V8
Firefox → SpiderMonkey
Safari → JavaScriptCore

2. 파싱 과정에서 AST(추상 구문 트리)를 만든 뒤, 즉시 수행 가능한 최적화된 "중간 바이트코드(Bytecode)" 로 변환된다.

즉, 자바스크립트는 바이너리 코드(=기계어 코드) 로 "미리 컴파일" 하지는 않지만 엔진 내부에서

실행하기 위한 바이트코드 형태로 변환된다.

브라우저 엔진은 이 바이트코드를 JIT(Just-In-Time) 컴파일러로 필요한 부분만 네이티브 머신 코드로 변환해 실행한다.

자바스크립트 엔진의 실제 작동 흐름

브라우저는 HTML 을 파싱하다가 <script> 태그를 만나면

→ JS 엔진에게 그 스크립트를 넘겨준다.

1. 코드 읽기 (Parsing)
문자열 형태의 JavaScript 코드를 읽는다.

2. 토큰화(Tokenization / Lexing)
코드를 의미 있는 조각(token) 으로 분리한다.

예)

let x = 10;

→ ["let", "x", "=", "10", ";"]

3. 구문 분석(Parsing) → AST 생성

Token을 기반으로 AST(추상 구문 트리)를 만든다.

예)

VariableDeclaration
 └─ Identifier(x)
 └─ Literal(10)

4. AST → 중간 바이트코드(Bytecode) 생성

JS 엔진(예: V8 의 Ignition 인터프리터)이 AST 를 바이트코드로 변환한다.

바이트코드는 실제 CPU 기계어가 아니라 엔진이 이해하는 일종의 "가벼운 기계어" 라고 보면 된다.

5. JIT 컴파일 → 네이티브 머신 코드로 최적화

실행 중 자주 호출되거나 반복되는 함수는 JS 엔진의 JIT 컴파일러가 바로 기계어(native code) 로 컴파일한다.

단계	설명
HTML 파싱 중 JS 발견	JS 엔진에게 코드 전달
Lexing	토큰으로 분리
Parsing	AST 생성
바이트코드 생성	엔진 내부 실행용 코드(바이너리 형태)
JIT 컴파일	자주 쓰는 함수는 기계어로 변환
실행	최적화된 방식으로 코드 실행

이후 화면 업데이트가 일어나는 과정

JS, CSS 변경, DOM 변경이 발생하면 브라우저는 아래를 수행한다.

DOM 변경 → 렌더 트리 영향 → Reflow & Repaint
CSS 변경 → CSSOM 변경 → Render Tree 업데이트
스크롤 / 애니메이션 → 계속 Repaint
requestAnimationFrame → 1초에 60프레임 목표

전체 흐름 요약 (최종)

1. 서버 요청/응답 (HTML, CSS, JS 다운로드)
2. HTML 파싱 → DOM 생성
3. CSS 파싱 → CSSOM 생성
4. DOM + CSSOM → Render Tree 생성
5. Layout(Reflow): 요소 위치/크기 계산
6. Painting: 화면에 픽셀 렌더링
7. JavaScript 실행 (필요 시 DOM 업데이트)