조용한 개발 노트

32편에서는 대규모 트래픽 환경에서 Spring Web(MVC) 성능 튜닝 포인트를 요청 흐름 기준으로 정리했습니다.이번 글에서는 그 이론을 실제 운영 상황에 적용해,장애가 발생했을 때 Web 계층에서 어디부터 의심해야 하는가를 사례 중심으로 살펴보겠습니다.모든 사례는 요청이 어느 단계에서 멈췄는지를 기준으로 분석합니다.사례 1. 응답 시간이 갑자기 3배 이상 늘어났다증상에러는 없지만 평균/95% 응답 시간 급증DB, 외부 API는 정상1차 판단컨트롤러 이전 단계 병목 의심확인 포인트Filter / Interceptor에서 추가된 로직요청 로깅에서 Body 전체 출력 여부자주 발생하는 원인Filter에서 Request/Response Body 로깅대량 JSON을 문자열로 변환정리Filter/Interce..

31편에서는 Spring Security 운영 장애를 요청 흐름 기준으로 추적하는 방법을 살펴봤습니다.이번 글에서는 보안 단계를 통과한 이후,“Spring Web(MVC) 계층에서 실제로 성능 병목은 어디서 생기는가?”를 구조적으로 정리해보겠습니다.핵심은 단순합니다. 요청 하나가 지나가는 각 단계의 비용을 줄이는 것입니다.1. Web 성능 병목을 보는 기본 관점대규모 트래픽에서의 Web 성능 문제는 대부분 다음 질문으로 귀결됩니다.요청 하나당 처리 비용이 큰가?동시에 처리 가능한 요청 수가 적은가?Spring MVC 요청 흐름을 기준으로 보면, 병목은 보통 아래 지점에 집중됩니다.Filter / InterceptorArgumentResolver / ValidationHttpMessageConverter컨..

30편에서는 Spring Security 설정과 요청 흐름을 한 장 요약으로 정리했습니다.이번 글에서는 그 요약을 실제 운영 상황에 적용해,장애가 발생했을 때 어디부터 확인해야 하는가를 사례 중심으로 정리해보겠습니다.이 글의 목적은 “설정을 많이 아는 것”이 아니라, 문제 발생 시 추적 경로를 바로 떠올리는 것입니다.사례 1. 특정 시점부터 모든 요청이 401로 떨어진다증상정상 동작하던 API가 갑자기 전부 401컨트롤러 로그가 전혀 남지 않음1차 판단MVC 진입 전 차단Security Filter Chain 문제확인 포인트Authorization 헤더 유무JWT 만료(exp) 시각JWT 검증 키 변경 여부자주 발생하는 원인Access Token 만료 시간 단축 후 클라이언트 미반영서명 키 로테이션 후 ..

21편부터 29편까지 우리는 Spring Security를요청 흐름Filter Chain 구조JWT 인증성능과 운영보안 이벤트 설계관점에서 단계적으로 정리했습니다.이번 글에서는 이 내용을“실무에서 바로 참고할 수 있는 한 장 요약”형태로 정리합니다.1. Spring Security의 위치 요약Client → Security Filter Chain → DispatcherServlet → Spring MVC핵심은 이것입니다.Security는 MVC 이전에 동작Filter 기반 구조컨트롤러와 분리된 보안2. Security Filter Chain 핵심 구성구성 요소역할실무 포인트DelegatingFilterProxy서블릿 ↔ Security 연결시작 지점SecurityContextPersistenc..

26편에서는 Refresh Token의 필요성과 설계 이유를, 28편에서는 대규모 트래픽 환경에서의 Security 성능 포인트를 정리했습니다.이번 글에서는 보안을 “기능”이 아니라운영과 감사의 관점에서 바라보며, 어떤 보안 이벤트를, 언제, 어떻게 기록해야 하는지를 구조적으로 정리해보겠습니다.1. 왜 보안 이벤트 설계가 필요한가보안 사고는 보통 이렇게 시작합니다.이상한 로그인 알림토큰이 갑자기 무효화됨특정 계정에서 반복된 401/403이때 가장 먼저 드는 질문은:“무슨 일이 언제 어디서 일어났지?”입니다.이 질문에 답하려면, 보안 이벤트가 사전에 잘 정의되고 기록되어 있어야 합니다.2. 반드시 기록해야 할 보안 이벤트실무 기준으로 다음 이벤트들은 반드시 기록 대상으로 삼는 것이 좋습니다.로그인 성공로그..

27편에서는 JWT 인증을 실무에서 어떻게 설계해야 하는지를 패턴과 실수 중심으로 정리했습니다.이번 글에서는 그 설계를“트래픽이 많아졌을 때 어디서 병목이 생기고, 무엇을 줄여야 하는가”라는 관점에서 살펴보겠습니다.보안은 강화할수록 성능 비용이 증가합니다. 이 글의 목표는 보안을 유지하면서도 병목을 만들지 않는 지점을 명확히 짚는 것입니다.1. Security 성능 병목은 어디서 생길까대규모 트래픽 환경에서 Security로 인한 병목은 대부분 다음 지점에서 발생합니다.토큰 검증 비용Security Filter Chain 과도한 실행인증/인가 판단의 반복외부 시스템(인증 서버, DB) 의존즉,요청마다 수행되는 작업의 “개수와 비용”이 핵심입니다.2. Access Token 검증 비용 줄이기JWT 기반 인..

26편에서는 Stateless 인증 환경에서 Refresh Token이 왜 필요한지를 보안·운영·UX 관점에서 정리했습니다.이번 글에서는 그 개념을 실무 설계 패턴으로 구체화하고, 현장에서 자주 발생하는 실수 사례를 함께 정리해보겠습니다.1. 실무에서 가장 많이 쓰는 JWT 기본 패턴실무에서 가장 안정적으로 쓰이는 기본 패턴은 다음과 같습니다.Access Token: 짧은 만료(5~15분)Refresh Token: 긴 만료(2주~1개월)Access Token → Authorization 헤더Refresh Token → HttpOnly 쿠키이 패턴의 핵심은탈취 가능성이 높은 토큰과 보호가 필요한 토큰을 분리하는 것입니다.2. 패턴 #1 – Refresh Token Rotation가장 권장되는 보안 패턴입니..

25편에서는 Security · MVC 실무 설정에서 자주 발생하는 실수들을 요청 흐름 기준으로 정리했습니다.이번 글에서는 JWT 기반 Stateless 인증 환경에서 항상 함께 등장하는 질문을 다뤄보겠습니다.Access Token만 쓰면 안 될까? 왜 굳이 Refresh Token이 필요할까?이 질문의 답은 편의성이 아니라 보안과 운영의 균형에 있습니다.1. Stateless 인증의 기본 전제JWT 기반 인증은서버가 인증 상태를 저장하지 않는다는 전제를 가집니다.즉,요청마다 토큰을 보내고요청마다 토큰을 검증합니다.이 구조는서버 확장에 유리하고세션 동기화가 필요 없으며클라우드 환경에 적합하지만, 토큰이 유출되면 바로 위험해진다는 단점도 함께 가집니다.2. Access Token만 사용할 때의 문제만약 A..

24편에서는 Security · MVC · Exception을 요청 기준으로 하나의 흐름으로 통합 정리했습니다.이번 글에서는 그 흐름을 바탕으로, 실무에서 가장 자주 발생하는 Security · MVC 설정 실수를증상원인해결 방법순서로 정리해보겠습니다.실수 #1. 토큰이 있는데도 401이 나온다증상Authorization 헤더에 JWT가 있음하지만 항상 401 Unauthorized원인JWT 인증 필터가 Security Filter Chain에 등록되지 않음필터 순서가 AuthorizationFilter 뒤에 위치Bearer prefix 누락 또는 형식 오류해결JWT 인증 필터가 SecurityContextPersistenceFilter 이후에 위치하는지 확인AuthorizationFilter 이전에 인..

12편부터 23편까지 우리는 Spring MVC 요청 흐름 위에DispatcherServletHandlerMapping / HandlerAdapterArgumentResolver / ValidationHttpMessageConverterExceptionResolverSpring Security Filter ChainJWT 인증 흐름을 하나씩 분리해서 살펴봤습니다.이번 글에서는 이 모든 요소를“요청 하나가 들어왔을 때 실제로 어떤 경로를 타는가”라는 관점에서 하나의 흐름으로 통합해보겠습니다.1. 전체 요청 흐름 한 줄 요약Client → Security Filter Chain → DispatcherServlet → HandlerMapping → HandlerAdapter ..