Java/Spring

질문 그럼, 자바 말고 다른 언어는 JVM 위에 올릴 수 없나요?

답변 포인트 가능합니다.

Kotlin, Scala, Groovy, Clojure 같은 언어도 JVM 바이트코드로 컴파일되어 JVM 위에서 실행됩니다.

질문 반대로 JVM 계열 언어를 일반적으로 컴파일해서 사용할 순 없나요?

답변 포인트 일부는 네이티브 컴파일이 가능합니다.

예를 들어 GraalVM Native Image를 사용하면 JVM 없이 실행 가능한 바이너리를 만들 수 있지만, 리플렉션이나 동적 로딩에서 제약이 생길 수 있습니다.

질문 VM을 사용함으로써 얻을 수 있는 장점과 단점에 대해 설명해 주세요.

답변 포인트 장점은 플랫폼 독립성, GC, 런타임 최적화, 안정성입니다.

단점은 JVM 구동 비용, 메모리 사용량, GC 튜닝 부담, 네이티브 대비 예측 어려운 지연 시간입니다.

질문 JVM과 내부에서 실행되고 있는 프로그램은 부모 프로세스 - 자식 프로세스 관계를 갖고 있다고 봐도 무방한가요?

답변 포인트 아닙니다.

JVM은 명세상 바이트코드를 실행하는 추상 머신입니다. 일반적인 구현에서는 실행 중인 JVM 인스턴스와 Java 애플리케이션이 하나의 운영체제 프로세스 안에서 동작합니다.

Java 프로그램이 JVM의 자식 프로세스로 별도 생성되는 구조는 아닙니다.

질문 그렇다면 컴파일 과정에서, final 키워드는 다르게 취급되나요?

답변 포인트 컴파일러는 final 제약을 검사합니다.

static final 기본형이나 문자열 상수처럼 컴파일 타임 상수인 경우 값이 사용하는 쪽에 인라인될 수 있습니다.

다만 모든 final이 성능 최적화로 직결되는 것은 아니고, 실제 최적화는 JIT가 런타임 정보를 바탕으로 수행하는 경우가 많습니다.

질문 왜 클래스는 단일 상속만 가능한데, 인터페이스는 2개 이상 구현이 가능할까요?

답변 포인트 클래스 다중 상속은 필드와 구현이 충돌하는 다이아몬드 문제가 생기기 쉽습니다.

인터페이스는 원래 상태 없이 계약 중심이었기 때문에 여러 개 구현이 가능했습니다.

Java 8 이후 default method가 생겼지만, 충돌 시 구현 클래스가 명시적으로 해결해야 합니다.

질문 의미만 들어보면 리플렉션은 보안적인 문제가 있을 가능성이 있어보이는데, 실제로 그렇게 생각하시나요? 만약 그렇다면, 어떻게 방지할 수 있을까요?

답변 포인트 가능합니다.

private 멤버 접근, 임의 클래스 로딩, 사용자 입력 기반 메서드 호출은 위험할 수 있습니다.

사용자 입력을 직접 클래스명이나 메서드명으로 쓰지 않고, 허용 목록을 두며, 접근 범위를 최소화하고, 모듈과 접근 제어를 지키는 방식으로 방어합니다.

질문 리플렉션을 언제 활용할 수 있을까요?

답변 포인트 DI 컨테이너의 객체 생성, 애노테이션 스캔, ORM 엔티티 매핑, JSON 직렬화/역직렬화, 테스트에서 private 필드 주입, 플러그인 구조처럼 런타임에 타입을 다뤄야 할 때 사용합니다.

질문 static 을 사용하면 어떤 이점을 얻을 수 있나요? 어떤 제약이 걸릴까요?

답변 포인트 인스턴스 없이 접근할 수 있어 유틸리티 함수, 상수, 공유 자원 표현에 편합니다.

하지만 객체지향적 다형성을 활용하기 어렵고, 전역 상태처럼 사용하면 테스트와 동시성 관리가 어려워질 수 있습니다.

질문 컴파일 과정에서 static 이 어떻게 처리되는지 설명해 주세요.

답변 포인트 static 멤버는 인스턴스가 아니라 클래스 단위로 관리됩니다.

바이트코드에서는 static 메서드 호출에 invokestatic이 사용됩니다.

static 필드는 클래스가 로딩되고 초기화될 때 준비되며, static final 컴파일 타임 상수는 인라인될 수 있습니다.

질문 예외처리를 하는 세 방법에 대해 설명해 주세요.

답변 포인트 직접 try-catch로 잡아 복구하거나, throws로 호출자에게 전파하거나, 더 의미 있는 예외로 감싸서 변환 후 던질 수 있습니다.

실무에서는 복구 가능하면 처리하고, 복구 불가능하면 적절한 계층에서 공통 처리합니다.

질문 CheckedException, UncheckedException 의 차이에 대해 설명해 주세요.

답변 포인트 checked exception은 컴파일 시점에 처리나 선언이 강제됩니다.

unchecked exception은 RuntimeException 계열로 강제되지 않으며, 주로 프로그래밍 오류나 복구하기 어려운 상황에 사용합니다.

질문 예외처리가 성능에 큰 영향을 미치나요? 만약 그렇다면, 어떻게 하면 부하를 줄일 수 있을까요?

답변 포인트 예외 객체 생성과 스택 트레이스 수집은 비용이 있습니다.

정상 제어 흐름에 예외를 사용하지 않고, 자주 발생하는 검증은 조건문으로 처리하며, 필요한 경우 예외 메시지와 로깅 범위를 적절히 조절해야 합니다.

질문 Synchronized 키워드가 어디에 붙는지에 따라 의미가 약간씩 변화하는데, 각각 어떤 의미를 갖게 되는지 설명해 주세요.

답변 포인트 인스턴스 메서드에 붙으면 this 객체 락을 사용합니다.

static 메서드에 붙으면 해당 클래스의 Class 객체 락을 사용합니다.

블록에 붙으면 괄호 안에 지정한 객체의 락을 사용합니다.

질문 효율적인 코드 작성 측면에서, Synchronized는 좋은 키워드일까요?

답변 포인트 단순하고 안전하지만 락 범위가 크거나 경쟁이 심하면 성능 저하가 생깁니다.

임계 영역을 작게 유지하고, 상황에 따라 더 세밀한 동시성 도구를 사용하는 것이 좋습니다.

질문 Synchronized 를 대체할 수 있는 자바의 다른 동기화 기법에 대해 설명해 주세요.

답변 포인트 ReentrantLock, ReadWriteLock, StampedLock, AtomicInteger, ConcurrentHashMap, Semaphore, CountDownLatch, CompletableFuture 등을 상황에 따라 사용할 수 있습니다.

질문 Thread Local에 대해 설명해 주세요.

답변 포인트 ThreadLocal은 각 스레드마다 독립적인 값을 보관하게 해주는 도구입니다.

같은 변수처럼 보여도 스레드별로 값이 분리됩니다.

인증 정보, 트랜잭션 컨텍스트 등에 쓰이지만, 스레드 풀 환경에서는 사용 후 제거하지 않으면 메모리 누수나 이전 요청 데이터 노출 위험이 있습니다.

질문 Stream과 for ~ loop의 성능 차이를 비교해 주세요,

답변 포인트 단순 반복에서는 for문이 오버헤드가 적어 더 빠를 수 있습니다.

Stream은 가독성과 조합성이 장점입니다.

성능은 데이터 크기, 연산 종류, 박싱 여부, 병렬화 가능성에 따라 달라집니다.

질문 Stream은 병렬처리 할 수 있나요?

답변 포인트 parallelStream()이나 stream().parallel()로 병렬 처리가 가능합니다.

내부적으로 공용 ForkJoinPool을 사용합니다.

CPU 바운드이고 데이터 분할이 쉽고 공유 상태가 없을 때 효과적이며, I/O 작업이나 작은 데이터에는 오히려 손해일 수 있습니다.

질문 Stream에서 사용할 수 있는 함수형 인터페이스에 대해 설명해 주세요.

답변 포인트 대표적으로 Predicate는 조건 판단, Function은 변환, Consumer는 소비, Supplier는 공급, Comparator는 비교, BinaryOperator는 같은 타입 두 값을 하나로 합치는 역할을 합니다.

질문 가끔 외부 변수를 사용할 때, final 키워드를 붙여서 사용하는데 왜 그럴까요? 꼭 그래야 할까요?

답변 포인트 람다에서 캡처하는 지역 변수는 final 또는 effectively final이어야 합니다.

명시적으로 final을 붙이지 않아도 이후 값이 변경되지 않으면 사용 가능합니다.

이는 캡처된 값의 일관성과 동시성 문제를 줄이기 위한 제약입니다.

질문 finalize() 를 수동으로 호출하는 것은 왜 문제가 될 수 있을까요?

답변 포인트 finalize()는 호출 시점이 보장되지 않고 성능과 안정성 문제가 있어 사용이 권장되지 않습니다.

수동 호출은 일반 메서드 호출일 뿐 GC의 finalization을 의미하지 않습니다.

자원 정리는 try-with-resources와 AutoCloseable을 사용하는 것이 좋습니다.

질문 어떤 변수의 값이 null이 되었다면, 이 값은 GC가 될 가능성이 있을까요?

답변 포인트 가능성은 있지만 즉시 GC된다는 뜻은 아닙니다.

해당 객체를 참조하는 다른 참조가 없고 GC Root에서 도달할 수 없어야 수거 대상이 됩니다.

실제 회수 시점은 JVM이 결정합니다.

질문 본인이 hashcode() 를 정의해야 한다면, 어떤 점을 염두에 두고 구현할 것 같으세요?

답변 포인트 equals에 사용하는 필드와 일관되게 구성해야 합니다.

같은 값이면 같은 해시를 반환해야 하고, 해시 충돌을 줄이기 위해 주요 필드를 균형 있게 반영해야 합니다.

가능하면 불변 필드를 기준으로 작성하는 것이 좋습니다.

질문 그렇다면 equals() 를 재정의 해야 할 때, 어떤 점을 염두에 두어야 하는지 설명해 주세요.

답변 포인트 반사성, 대칭성, 추이성, 일관성, null 비교 false 규칙을 지켜야 합니다.

타입 비교 방식도 주의해야 하며, equals를 재정의하면 hashCode도 함께 재정의해야 합니다.

질문 후보 없이 특정 기능을 하는 클래스가 딱 한 개하면, 구체 클래스를 그냥 사용해도 되지 않나요? 그럼에도 불구하고 왜 Spring에선 Bean을 사용 할까요?

답변 포인트 단순히 구현체 교체 때문만은 아닙니다.

Bean으로 관리하면 생명주기 관리, 의존성 주입, AOP, 트랜잭션, 설정 관리, 테스트 대체, 싱글톤 관리 같은 컨테이너 기능을 사용할 수 있습니다.

질문 Spring의 Bean 생성 주기에 대해 설명해 주세요.

답변 포인트 Bean 정의를 읽고 객체를 생성한 뒤 의존성을 주입하고, aware 콜백, BeanPostProcessor, 초기화 콜백을 거쳐 사용 가능한 상태가 됩니다.

컨테이너 종료 시 destroy 콜백이 호출될 수 있습니다.

질문 프로토타입 빈은 무엇인가요?

답변 포인트 요청할 때마다 새 인스턴스를 생성하는 스코프입니다.

싱글톤 빈과 달리 Spring은 생성과 의존성 주입까지만 관리하고, 이후 소멸 생명주기는 클라이언트가 관리해야 합니다.

질문 @Aspect는 어떻게 동작하나요?

답변 포인트 Spring은 @Aspect로 정의된 클래스의 pointcut과 advice를 읽고, 대상 Bean에 프록시를 만들어 메서드 호출 전후에 advice를 실행합니다.

Spring AOP는 기본적으로 프록시 기반이라 Spring Bean의 메서드 호출에 적용됩니다.

질문 설명만 들어보면 인터셉터만 쓰는게 나아보이는데, 아닌가요? 필터는 어떤 상황에 사용 해야 하나요?

답변 포인트 필터는 Spring MVC 이전 단계에서 모든 요청에 적용해야 하는 작업에 적합합니다.

예를 들어 인코딩 처리, CORS, 보안 필터 체인, 요청/응답 래핑, 로깅처럼 DispatcherServlet 전 단계에서 처리해야 하는 기능은 Filter가 자연스럽습니다.

컨트롤러 기반 인증 체크나 요청 처리 시간 측정은 Interceptor가 적합합니다.

질문 여러 요청이 들어온다고 가정할 때, DispatcherServlet은 한번에 여러 요청을 모두 받을 수 있나요?

답변 포인트 DispatcherServlet 객체는 보통 하나지만, 서블릿 컨테이너의 여러 스레드가 동시에 같은 DispatcherServlet의 service 로직을 호출해 요청을 처리합니다.

따라서 DispatcherServlet 자체는 공유되므로 상태를 두면 안 됩니다.

질문 수많은 @Controller 를 DispatcherServlet은 어떻게 구분 할까요?

답변 포인트 애플리케이션 시작 시 @RequestMapping, @GetMapping 같은 매핑 정보를 HandlerMapping이 등록합니다.

요청 URL, HTTP 메서드, 파라미터, 헤더 조건 등을 기준으로 적절한 핸들러를 찾습니다.

질문 영속성은 어떤 기능을 하나요? 이게 진짜 성능 향상에 큰 도움이 되나요?

답변 포인트 영속성 컨텍스트는 엔티티를 관리하며 1차 캐시, 동일성 보장, 변경 감지, 쓰기 지연을 제공합니다.

성능 향상에 도움이 되는 경우도 있지만, 핵심은 객체 상태 변경을 트랜잭션 안에서 자연스럽게 DB 변경으로 반영하게 해주는 관리 기능입니다.

질문 N + 1 문제에 대해 설명해 주세요.

답변 포인트 처음 1번의 쿼리로 N개의 엔티티를 가져온 뒤, 연관 엔티티를 조회하면서 N번의 추가 쿼리가 발생하는 문제입니다.

fetch join, EntityGraph, batch size, DTO 조회 등으로 해결할 수 있습니다.

질문 @Transactional(readOnly = true)는 어떤 기능인가요? 이게 도움이 되나요?

답변 포인트 읽기 전용 트랜잭션임을 Spring과 하위 기술에 알려 최적화 여지를 줍니다.

JPA에서는 flush 모드 조정으로 변경 감지 비용을 줄이는 데 도움이 될 수 있고, DB에 따라 읽기 전용 힌트로 활용될 수 있습니다.

다만 무조건 큰 성능 향상을 보장하지는 않습니다.

질문 그런데, 읽기에 트랜잭션을 걸 필요가 있나요? @Transactional을 안 붙이면 되는거 아닐까요?

답변 포인트 읽기에도 트랜잭션이 필요한 경우가 있습니다.

같은 작업 범위에서 일관된 읽기를 보장하거나, Lazy Loading이 필요한 경우, 복수 쿼리 간 일관성이 필요한 경우 유용합니다.

단순 단건 조회에서는 없어도 동작할 수 있지만 서비스 정책상 읽기 트랜잭션을 명시하는 경우가 많습니다.

질문 별 기능이 없는 것 같은데, 어떻게 Spring 에서는 Annotation 이 그렇게 많은 기능을 하는 걸까요?

답변 포인트 애노테이션 자체가 기능을 수행하는 것은 아닙니다.

Spring이 리플렉션과 클래스패스 스캔으로 애노테이션을 읽고, Bean 등록, 의존성 주입, 프록시 생성, 요청 매핑 같은 동작을 수행하기 때문에 기능이 생깁니다.

질문 Lombok의 @Data를 잘 사용하지 않는 이유는 무엇일까요?

답변 포인트 @Data는 getter, setter, toString, equals, hashCode 등을 한 번에 생성합니다.

편하지만 불필요한 setter로 객체 불변성이 깨지고, JPA 연관관계에서 toString 순환 참조나 equals/hashCode 문제가 생길 수 있습니다.

필요한 애노테이션만 명시적으로 쓰는 편이 안전합니다.

질문 혹시 Netty에 대해 들어보셨나요? 왜 이런 것을 사용할까요?

답변 포인트 Netty는 비동기 이벤트 기반 네트워크 애플리케이션 프레임워크입니다.

Servlet 기반 요청-스레드 모델보다 비동기 I/O와 이벤트 루프를 활용하기 좋습니다.

고성능 네트워크 서버, WebFlux, gRPC, 프록시, 게임 서버 같은 곳에서 사용될 수 있습니다.

질문 List<Integer>는 왜 List<Number>의 하위 타입이 아닌가요?

답변 포인트 이를 허용해 List<Integer>를 List<Number>로 본다면 Number를 받는 코드가 Double을 추가할 수 있고, 원래 Integer 목록의 타입 안전성이 깨집니다. 그래서 Java의 일반적인 제네릭 타입은 무공변입니다.

읽기만 필요한 경우에는 List<? extends Number>로 공통 상한을 표현할 수 있지만, 어떤 구체 타입의 목록인지 모르므로 null 이외의 값을 안전하게 추가할 수 없습니다.

질문 ? extends T와 ? super T는 언제 사용하나요?

답변 포인트 값을 주로 읽는 생산자에는 ? extends T, T 값을 넣는 소비자에는 ? super T를 사용한다는 PECS 원칙으로 설명할 수 있습니다.

? extends T에서는 값을 T로 읽을 수 있지만 구체 타입을 모르므로 추가가 제한됩니다. ? super T에는 T와 그 하위 타입 값을 넣을 수 있지만 읽은 값은 일반적으로 Object로만 안전하게 다룰 수 있습니다.

질문 왜 new T(), new T[]와 instanceof List<String>를 사용할 수 없나요?

답변 포인트 타입 소거 후에는 JVM이 T의 실제 생성자나 배열의 런타임 컴포넌트 타입을 알 수 없습니다. 배열은 런타임에 컴포넌트 타입을 검사하는 reified 구조라 소거되는 제네릭과 직접 결합하면 타입 안전성을 보장하기 어렵습니다.

instanceof List<?>처럼 런타임에 확인 가능한 타입은 사용할 수 있습니다. T 객체 생성이 필요하면 Class<T>, Supplier<T>나 팩터리를 명시적으로 전달하는 방식을 사용할 수 있습니다.

질문 타입 소거가 된다면 reflection으로 제네릭 타입을 어떻게 읽을 수 있나요?

답변 포인트 소거된 실행 타입과 별도로 컴파일러가 선언부의 generic signature를 클래스 파일 메타데이터에 남길 수 있습니다. 그래서 필드나 메서드 선언에 적힌 타입은 getGenericType(), getGenericParameterTypes() 등으로 확인할 수 있습니다.

그러나 지역 변수로 생성한 일반 객체의 실제 타입 인자는 보통 알 수 없습니다. 익명 하위 클래스나 구체 상속 선언처럼 타입 인자를 상위 타입 signature에 남기는 패턴은 별도의 경우입니다.

질문 CPU 연산이 많은 작업도 가상 스레드를 많이 만들면 빨라지나요?

답변 포인트 아닙니다. 동시에 실행할 CPU 연산 수는 코어 수에 제한되며 가상 스레드는 연산을 더 빠르게 수행하는 기술이 아닙니다. CPU 집약 작업은 코어 수에 맞춘 제한된 병렬성과 작업 분할이 더 중요합니다.

CPU 작업을 무제한 가상 스레드로 만들면 스케줄링과 컨텍스트 전환 비용만 늘 수 있습니다. 가상 스레드의 장점은 주로 작업 시간이 I/O 대기로 구성된 환경에서 나타납니다.

질문 가상 스레드를 사용하면 race condition을 신경 쓰지 않아도 되나요?

답변 포인트 가상 스레드도 Thread이므로 공유 가변 상태의 visibility, atomicity와 순서 문제는 그대로 발생합니다. 불변 객체, 락, atomic 클래스와 동시성 컬렉션 같은 동기화 수단이 여전히 필요합니다.

오히려 동시에 실행 가능한 작업 수가 크게 늘어 공유 상태와 외부 자원의 경합이 더 잘 드러날 수 있으므로 부하 테스트와 제한 정책이 중요합니다.

질문 가상 스레드를 풀링하지 않는다면 외부 시스템의 동시 요청 수는 어떻게 제한하나요?

답변 포인트 가상 스레드는 희소한 작업자 자원이 아니라 작업 자체를 표현하므로 작업마다 생성합니다. 외부 서비스가 동시에 20개 요청만 처리할 수 있다면 Semaphore(20)처럼 그 자원의 용량을 직접 표현하는 동시성 제한을 둡니다.

DB 커넥션 풀도 획득 가능한 연결 수로 자연스럽게 동시성을 제한합니다. 다만 연결을 기다리는 가상 스레드와 요청 큐가 지나치게 쌓이지 않도록 timeout, 전체 요청 상한과 backpressure도 함께 고려해야 합니다.

질문 Pinning은 무엇이며 synchronized를 피해야 하나요?

답변 포인트 Pinning은 가상 스레드가 blocking되어도 carrier를 놓지 못해 플랫폼 스레드까지 함께 묶이는 현상입니다. 장시간·빈번하게 발생하면 가상 스레드의 확장성을 떨어뜨릴 수 있습니다.

JDK 23 이하에서는 synchronized 내부 blocking이 주요 원인이었지만 JDK 24의 JEP 491로 이 제약이 제거됐습니다. 현재 JDK에서는 native·FFM 실행 중의 장시간 blocking, 그 코드가 호출한 Java callback의 blocking과 드문 class loading·initialization 대기 같은 잔여 사례를 관측해야 합니다. 반대로 짧은 native 호출까지 성능 문제로 단정하거나 synchronized를 무조건 ReentrantLock으로 바꾸는 조언도 적절하지 않습니다.

질문 가상 스레드에서 ThreadLocal을 사용할 때 무엇을 주의해야 하나요?

답변 포인트 가상 스레드도 ThreadLocal을 지원하지만 수십만 개의 가상 스레드마다 큰 객체나 캐시를 보관하면 총메모리 사용량이 커집니다. 플랫폼 스레드 풀의 소수 작업자에게 데이터를 저장한다는 기존 가정도 더 이상 맞지 않을 수 있습니다.

요청 범위 데이터는 수명을 짧게 유지하고 반드시 정리하며, 라이브러리와 JDK 버전이 지원한다면 명시적인 컨텍스트 전달이나 더 적합한 범위 관리 수단을 검토해야 합니다.

질문 자동 구성이 적용되지 않을 때 어떻게 확인하나요?

답변 포인트 debug 모드나 Condition Evaluation Report에서 해당 자동 구성과 Bean 조건이 왜 일치하거나 불일치했는지 확인합니다. 클래스패스 누락, 프로퍼티 값, 기존 사용자 Bean, 애플리케이션 타입과 자동 구성 제외 여부를 순서대로 확인합니다.

단순히 패키지 스캔 범위만 확인해서는 해결되지 않을 수 있습니다. 자동 구성 후보가 등록됐는지와 조건 평가 결과를 함께 봐야 합니다.

질문 Component Scan과 자동 구성은 같은 기능인가요?

답변 포인트 아닙니다. Component Scan은 지정한 패키지에서 @Component, @Service, @Configuration 같은 클래스를 찾아 Bean 정의로 등록합니다.

자동 구성은 AutoConfiguration.imports에 등록된 별도 후보를 불러와 클래스패스, Bean과 프로퍼티 조건에 따라 적용합니다. @SpringBootApplication이 두 기능을 함께 활성화하므로 같은 동작처럼 보일 수 있습니다.

질문 사용자가 같은 타입의 Bean을 등록하면 자동 구성은 어떻게 되나요?

답변 포인트 해당 자동 구성이 @ConditionalOnMissingBean을 사용한다면 조건이 불일치해 기본 Bean 등록을 건너뜁니다. 이것이 사용자 설정이 자동 구성보다 우선하도록 만드는 대표적인 back-off 방식입니다.

모든 자동 구성이 같은 조건을 사용하는 것은 아니므로 타입, 이름, 검색할 ApplicationContext 범위와 평가 순서를 공식 문서나 Condition Evaluation Report로 확인해야 합니다.

질문 직접 만든 라이브러리에 자동 구성을 제공하려면 어떻게 하나요?

답변 포인트 현재 Spring Boot에서는 @AutoConfiguration 클래스를 만들고 필요한 조건을 선언한 뒤 JAR의 META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports에 클래스 이름을 등록합니다. 필요한 일반 의존성을 모은 별도 Starter를 함께 제공할 수 있습니다.

자동 구성 패키지를 Component Scan 대상으로 삼거나 내부 구현 Bean을 공개 API처럼 노출하지 않아야 합니다. Spring Boot 2.6 이하의 오래된 자료는 spring.factories 등록 방식을 설명할 수 있으므로 대상 Boot 버전을 확인해야 합니다.

질문 주인이 아닌 쪽만 수정하면 어떻게 되나요?

답변 포인트 메모리의 반대쪽 참조나 컬렉션은 바뀌어도 DB 관계 업데이트를 결정하는 주인 값이 변경되지 않았으므로 flush 시 기대한 외래 키나 조인 테이블 변경이 발생하지 않을 수 있습니다.

반대로 주인만 수정하면 DB는 갱신되지만 현재 객체 그래프의 반대쪽은 이전 상태로 남을 수 있습니다. 두 방향을 함께 갱신하는 편의 메서드를 한쪽에 두고 일관되게 사용하는 것이 좋습니다.

질문 Cascade REMOVE와 orphanRemoval은 어떻게 다른가요?

답변 포인트 Cascade REMOVE는 부모 엔티티에 수행한 remove 작업을 자식에게 전파합니다. orphanRemoval은 부모가 살아 있어도 자식 참조를 null로 바꾸거나 컬렉션에서 제거해 관계를 끊으면 해당 자식을 삭제 대상으로 만듭니다.

orphanRemoval은 부모가 자식의 생명주기를 독점하는 OneToOne·OneToMany 관계에 적합합니다. 공유되거나 독립적으로 존재해야 하는 엔티티에는 적합하지 않습니다.

질문 관계 종류별로 연관관계의 주인은 어떻게 결정되나요?

답변 포인트 양방향 일대다·다대일에서는 외래 키를 매핑하는 다대일 쪽이 주인이고 ManyToOne에는 mappedBy를 지정할 수 없습니다. 양방향 일대일은 외래 키 기반이면 그 키를 매핑한 쪽이, 조인 테이블 기반이면 @JoinTable을 선언한 쪽이 주인이며 반대쪽이 mappedBy로 참조합니다.

다대다에서는 어느 쪽도 주인이 될 수 있지만 한쪽만 주인으로 정하고 반대쪽이 mappedBy로 참조합니다. 실무에서는 다대다 조인 테이블에 추가 속성이나 수명 관리가 필요한 경우가 많아 연결 엔티티로 풀어내기도 합니다.

질문 CascadeType.ALL을 모든 연관관계에 적용하면 어떤 문제가 생길 수 있나요?

답변 포인트 부모의 persist, merge와 remove가 의도하지 않은 독립 엔티티까지 전파될 수 있습니다. 특히 여러 부모가 공유하는 엔티티나 다대다 관계에서 remove 전파는 다른 데이터의 참조와 수명을 깨뜨릴 위험이 있습니다.

두 엔티티의 생성·수정·삭제 생명주기가 실제로 동일한지 확인하고 필요한 cascade 종류만 선택해야 합니다. 대량 cascade는 예상하지 못한 SQL과 락 범위를 만들 수 있으므로 실행 SQL도 확인해야 합니다.

질문 단방향과 양방향 연관관계 중 무엇을 선택해야 하나요?

답변 포인트 두 방향 탐색이 실제 도메인 로직에 필요하지 않다면 단방향이 상태 관리가 단순합니다. 양방향은 반대 방향 탐색이 빈번하고 객체 모델에 자연스러울 때 선택하되 두 참조의 일관성을 유지해야 합니다.

방향성과 fetch 전략은 별개입니다. 양방향으로 만든다고 필요한 데이터가 자동으로 효율적으로 조회되는 것은 아니므로 쿼리와 로딩 전략을 따로 설계해야 합니다.

질문 여러 SecurityFilterChain이 같은 요청과 일치하면 모두 실행되나요?

답변 포인트 아닙니다. FilterChainProxy가 가장 먼저 일치한 체인 하나만 선택하므로 /api/**처럼 구체적인 matcher를 가진 체인을 범용 체인보다 앞에 둬야 합니다.

앞쪽 체인이 일치하면 뒤쪽 체인의 필터는 실행되지 않습니다. 체인마다 인증 방식과 필터 구성이 독립적일 수 있으므로 DEBUG 로그와 실제 요청으로 선택 결과를 확인해야 합니다.

질문 AuthenticationManager, ProviderManager와 AuthenticationProvider는 어떻게 다른가요?

답변 포인트 AuthenticationManager는 필터가 인증을 요청하는 진입점 인터페이스이고, ProviderManager는 가장 일반적인 구현입니다. ProviderManager는 자신이 가진 여러 AuthenticationProvider에 인증을 위임합니다.

각 AuthenticationProvider는 특정 Authentication 타입을 지원하고 실제 자격 증명 검증과 사용자 조회를 수행합니다. 지원하지 않으면 다음 provider가 시도할 수 있고, 성공하면 인증된 Authentication을 반환하며 실패하면 AuthenticationException을 발생시킵니다.

질문 JWT 기반 stateless API라면 Spring Security가 필요 없나요?

답변 포인트 아닙니다. Spring Security 필터가 매 요청의 bearer token을 추출하고 서명, 만료, issuer와 audience를 검증한 뒤 Authentication을 만들어 권한 규칙에 사용할 수 있습니다.

Stateless는 인증 정보를 서버 세션에 지속하지 않는다는 뜻입니다. 요청 동안에는 SecurityContext가 필요하고, 토큰 폐기·refresh token·사용자 상태를 별도 저장한다면 시스템 전체가 완전히 무상태인 것도 아닙니다.

질문 인증 실패와 권한 부족은 필터 체인에서 어떻게 다른 응답으로 처리되나요?

답변 포인트 인증 정보가 없거나 유효하지 않으면 AuthenticationEntryPoint가 인증 절차를 시작합니다. Form Login은 로그인 페이지로 redirect할 수 있고 Basic·Bearer API는 일반적으로 401을 반환합니다. 이미 인증됐지만 필요한 권한이 없으면 AccessDeniedHandler가 보통 403을 반환합니다.

ExceptionTranslationFilter가 보안 예외를 이러한 처리기로 연결하지만, 인증 필터 자체에서 실패한 경우에는 해당 필터의 failure handler가 직접 응답할 수도 있으므로 필터 종류와 위치를 확인해야 합니다.

질문 커스텀 인증 필터는 체인의 어디에 추가해야 하나요?

답변 포인트 고정된 한 위치를 외우기보다 필터가 필요로 하는 선행 보안 단계와 이후 소비자를 기준으로 결정합니다. 인증 필터라면 exploit protection과 컨텍스트 준비 이후, 인가보다 앞에서 Authentication을 만들어야 합니다.

addFilterBefore, addFilterAfter, addFilterAt으로 기준 필터와의 상대 위치를 명시하고, 같은 필터가 Servlet 컨테이너와 SecurityFilterChain 양쪽에 중복 등록되지 않았는지도 확인해야 합니다.