조용한 개발 노트

이 글은 Spring Security 공식 문서를 기반으로, 인증이 끝난 후 생성된 Authentication이 어디에 저장되고, 어떻게 전파되는지를 SecurityContext 중심으로 설명합니다.SecurityContext를 이해하지 못하면, 비동기 처리, 멀티스레드 환경, 배치 작업에서 보안 이슈를 피할 수 없습니다.들어가며Spring Security를 사용하다 보면 한 번쯤은 이런 코드를 보게 됩니다.Authentication authentication = SecurityContextHolder.getContext().getAuthentication();이 코드는 단순해 보이지만, 그 뒤에는 중요한 질문이 숨어 있습니다.이 Authentication은 어디에서 온 것일까?이 질문에 답하는 것..

12편에서는 @Transactional(readOnly = true)가“쓰기 방지 규칙이 아니라 의도를 표현하는 힌트”라는 점을 살펴봤습니다.이제 트랜잭션 시리즈에서 가장 많은 실무 사고를 만드는 조합,트랜잭션 + 비동기로 넘어가겠습니다.많은 개발자가 다음과 같은 코드를 자연스럽게 작성합니다.@Transactionalpublic void process() { saveOrder(); asyncService.sendMessage(); // @Async}그리고 이렇게 기대합니다.“비동기 작업도 같은 트랜잭션 안에서 실행되겠지?”하지만 이 기대는거의 항상 틀립니다.1. 충돌의 출발점: ThreadLocal1편에서 다뤘듯이, Spring Transaction은ThreadLocal을 기반으로 동작합니다...

3편에서는 @Transactional이“메서드 실행 전후를 감싸는 프록시 기반 AOP”로 동작한다는 사실을 살펴봤습니다.이제 한 단계 더 깊은 질문으로 들어가야 합니다.왜 하필 ‘메서드’일까?트랜잭션은 클래스나 블록 단위로 관리하면 안 됐을까?이 질문에 답하면,왜 트랜잭션이 서비스 계층에 있어야 하는지왜 유스케이스 단위 설계가 중요한지왜 트랜잭션이 커지면 위험해지는지가 한 번에 연결됩니다.1. 트랜잭션 경계는 ‘시작과 끝’이 명확해야 한다트랜잭션의 본질은 아주 단순합니다.“어디서 시작해서, 어디서 끝나는가”이 경계가 명확하지 않으면,어디까지 롤백해야 하는지어떤 리소스를 묶고 있는지를 결정할 수 없습니다.Spring 공식 문서는 이 경계를“메서드 호출”로 정의합니다.왜냐하면 메서드는:명확한 진입 지점이 있..

2편에서는 Spring Transaction의 핵심 추상화인PlatformTransactionManager가 왜 인터페이스로 설계되었는지를 살펴봤습니다.이제 다음 질문으로 자연스럽게 이어집니다.그럼 @Transactional은 정확히 언제 트랜잭션을 시작하고, 언제 끝낼까?이 질문에 답하지 못하면,왜 어떤 메서드는 트랜잭션이 안 걸리는지왜 내부 호출에서는 동작하지 않는지왜 예상과 다른 시점에 커밋되는지를 끝까지 설명할 수 없습니다.1. @Transactional은 메서드가 아니다많은 개발자가 @Transactionl을“메서드 위에 붙이는 어노테이션”으로만 이해합니다.하지만 Spring 공식 문서에서 @Transactionl은AOP 설정 정보입니다.즉,어노테이션 자체가 트랜잭션을 시작하지 않고Spring이..

Spring에서 트랜잭션을 처음 접하면 대부분 이렇게 사용합니다.@Transactionalpublic void service() { // 비즈니스 로직}하지만 시간이 지나면 자연스럽게 이런 질문이 생깁니다.트랜잭션은 대체 어디에 저장돼 있을까?그리고 왜 비동기에서는 전파되지 않을까?이 질문의 핵심에는ThreadLocal이라는 선택이 있습니다.이번 글에서는 Spring Transaction 공식 문서를 기준으로,“왜 트랜잭션은 ThreadLocal로 관리될 수밖에 없었는가”를 설계 관점에서 풀어보겠습니다.1. 트랜잭션은 ‘기능’이 아니라 ‘상태’다많은 개발자가 트랜잭션을“commit / rollback을 해주는 기능”으로 인식합니다.하지만 Spring 공식 문서에서 트랜잭션은“현재 실행 흐름에 묶인 ..