Spring 애플리케이션이 컨트롤러나 서비스 내부의 중단점에 도달하기 전에 403 또는 401 응답을 반환할 때, 문제는 개발자가 검사하려는 로직이 아니라 요청 실행에 앞서 작동한 권한 부여 계층에 있을 수 있습니다. IntelliJ IDEA는 실행 중인 애플리케이션의 실제 보안 규칙을 검사한 다음, SecurityConfig를 수정하거나 애플리케이션을 다시 시작하지 않고 디버깅 세션 동안 요청에 일시적으로 신원과 권한을 부여하는 방법을 제공합니다.
이 기능은 IntelliJ IDEA Ultimate의 Spring Debugger 플러그인에 포함되어 있으며 2026.2 버전부터 사용할 수 있습니다. Security inlays는 디버거가 실행되는 동안 기본적으로 표시되며, 애플리케이션이 로컬에서 실행 중인지 원격 JVM에서 실행 중인지와 관계없이 사용할 수 있습니다.
먼저 경로가 실제로 요구하는 사항을 확인하세요
편집기 또는 HTTP 파일 내부의 인터페이스는 엔드포인트에 적용되는 역할 및 권한 기반 요구 사항을 표시하며, hasRole 및 hasAuthority를 기반으로 하는 규칙도 포함합니다. 여기서 IntelliJ IDEA는 설정 파일을 읽는 데만 의존하지 않고, Spring 컨텍스트가 초기화된 후 JVM 내부의 실제 SecurityFilterChain을 검사합니다. 여러 SecurityFilterChain, 매처 순서, 활성 프로파일 또는 설정의 조건부 등록이 최종 결과에 영향을 미칠 때 이는 중요합니다.
일부 사용자 지정 AuthorizationManager 구현에서처럼 특정 규칙을 역할 목록으로 변환할 수 없으면 해당 규칙은 알 수 없음 상태로 표시되고 관련 보안 설정 코드로 연결되는 링크가 나타납니다. 이 경우 역할 목록에 기반한 자동 열기는 제공되지 않으며 SecurityConfig를 직접 확인해야 합니다.
디버깅 세션 중 경로 일시적으로 열기
Unlock 작업은 두 가지 옵션을 제공합니다. 첫 번째 옵션은 요청을 해당 경로에 필요한 역할 집합을 가진 인증된 요청으로 전달하며, 보호된 경로 뒤의 컨트롤러 또는 서비스 로직을 테스트하려는 경우에 적합합니다. 두 번째 옵션에서는 사용자 이름과 사용자 지정 권한 목록을 지정할 수 있습니다. 예를 들어 admin과 ROLE_ADMIN 및 ROLE_MANAGER를 사용하여 특정 권한 집합에서 애플리케이션이 어떻게 동작하는지 테스트할 수 있습니다.
작업을 실행하면 디버거는 실행 중인 애플리케이션의 SecurityContext 내부에 TestingAuthenticationToken 객체를 생성합니다. hasRole 및 hasAuthority 검사와 SecurityContextHolder.getContext().getAuthentication(), 그리고 Principal 또는 Authentication 매개변수는 개발자가 지정한 신원과 권한을 확인합니다. 이 작업은 애플리케이션 코드나 설정 파일을 변경하지 않으며, Spring Boot DevTools를 통한 프로세스 내부 재시작을 포함해 애플리케이션을 다시 시작하면 모든 열기가 사라집니다. 경로를 수동으로 잠근 경우에도 마찬가지입니다.
영향은 IntelliJ IDEA에서 보낸 요청에만 국한되지 않습니다. 특정 경로에 대한 GET을 열면 curl, Postman 또는 브라우저처럼 동일한 URI와 HTTP 메서드에 접근하는 모든 클라이언트에 영향을 줍니다. 컨트롤러 정의에서 경로 패턴을 열었다면 해당 패턴과 일치하는 모든 값이 포함될 수 있습니다. 따라서 작업이 끝나는 즉시 경로를 다시 잠그거나 디버깅 세션을 종료해야 하며, 특히 애플리케이션이 네트워크를 통해 접근 가능한 경우에는 더욱 그렇습니다.
Unlock이 우회하지 않는 것은 무엇인가요?
이 작업은 Spring Security 전체를 비활성화하지 않으며 CSRF 보호도 우회하지 않습니다. POST, PUT 또는 DELETE 요청에 유효한 CSRF 토큰이 필요한 경우 CsrfFilter는 계속 요청을 거부할 수 있습니다. 또한 범위는 Servlet 스택에서 AuthorizationFilter를 통한 엔드포인트 권한 부여로 제한되며, AuthorizationWebFilter를 사용하는 Spring WebFlux는 지원하지 않습니다.
@PreAuthorize, @PostAuthorize 및 @Secured와 같은 메서드 수준의 보호 요구 사항을 직접 표시하거나 열 수 있는 인터페이스도 없습니다. 그러나 SecurityContext에 주입된 권한은 이후 메서드 보안 인터셉터에서 읽을 수 있으므로, 부여된 권한이 조건을 충족한다면 @PreAuthorize로 보호되는 서비스 호출이 통과할 수 있습니다. 이는 IntelliJ IDEA가 메서드 자체의 보호를 열었다는 뜻이 아니라, 검사가 동일한 인공 인증 컨텍스트를 읽었다는 뜻입니다.
신원 제한과 테스트 도구 통합
디버거가 생성하는 신원은 TestingAuthenticationToken 내부의 문자열 사용자 이름이며, 애플리케이션의 UserDetails나 사용자 객체의 사용자 지정 유형이 아닙니다. 따라서 @AuthenticationPrincipal이 붙은 매개변수는 null을 반환할 수 있습니다. 이는 IDEA-389767이라는 번호로 알려진 문제이며, 문서가 게시된 시점에 2026.2 버전에 영향을 주고 있었습니다.
Principal 또는 Authentication을 매개변수 유형으로 사용할 수 있지만, JwtAuthenticationToken과 같은 구체적인 유형에 의존하면 주입된 객체가 해당 유형에 속하지 않기 때문에 IllegalStateException이 발생할 수 있습니다. 또한 claims, credentials, 세션에 연결된 신원 또는 특정 인증 토큰 유형에 의존하는 부분은 결과가 달라지거나 실패할 수 있습니다.
경로를 연 대상과 동일한 실행 중인 애플리케이션이라면 통합된 .http 파일이나 curl, Postman 및 테스트 프레임워크에서 들어오는 요청에도 열기가 적용됩니다. 그러나 자동화된 워크플로 또는 AI 에이전트에 의존하는 워크플로에서는 현재 작업을 실행할 프로그래밍 방식의 키가 없습니다. JetBrains는 2026.3 버전에 MCP 도구와 이에 연결된 스킬을 추가할 계획이지만, 현재 버전에서는 IDE 내부에서 먼저 수동으로 클릭해야 합니다.
이 방식이 중요한 이유
여기서 실질적인 가치는 보안을 비활성화하는 것이 아니라, 다른 환경으로 전달될 수 있는 임시 설정 파일 변경을 남기지 않고 개발자가 테스트하려는 로직에서 권한 부여 계층을 분리하는 데 있습니다. 반면 열기는 실행 중인 프로세스에 적용되는 일시적인 보안 변경이며 IDE 요청에만 국한된 로컬 모의가 아닙니다. 따라서 이를 실제 인증 테스트의 대안이 아니라 범위가 통제된 디버깅 도구로 간주해야 하며, 사용하기 전에 영향을 받는 경로, 메서드 및 클라이언트를 확인해야 합니다.
또한 원격 애플리케이션에서 경로를 열어도 이 기능은 로그에 메시지를 기록하지 않으며 Actuator를 통해 표시되는 지표도 제공하지 않는다는 점에 유의해야 합니다. 문서에 따르면 상태는 애플리케이션에 연결된 IDE 내부의 인터페이스를 통해서만 확인할 수 있습니다. 필요하지 않을 때는 IntelliJ IDEA의 Registry에서 spring.debugger.security.enabled 설정을 사용하여 Security inlays를 비활성화할 수 있습니다.