[프로젝트 회고] 7STARBALL Meeting 테스트 환경과 Security 설정

들어가며

Meeting 기능을 구현한 뒤 테스트를 붙이면서 생각보다 많은 시간을 쓴 부분이 Security 설정이었다.

일반적인 서비스 테스트라면 Service에 Mock Repository를 주입하고 검증하면 된다. 하지만 Controller 테스트나 통합 테스트에서는 인증된 사용자가 필요했다.

Meeting 기능에는 “내가 참여한 모임”, “내가 호스트인 모임”, “모임 참여/취소”처럼 로그인 사용자 정보가 중요한 API가 많았다.

그래서 테스트 환경에서 인증 흐름을 어떻게 다룰지 정리해야 했다.

테스트에서 인증 사용자가 필요한 이유

Meeting API 중 일부는 인증 없이 조회할 수 있었다.

하지만 다음 기능들은 사용자 정보가 필요했다.

• 내 모임 조회
• 모임 참여
• 모임 참여 취소
• 모임 생성
• 모임 수정

실제 운영에서는 JWT나 SecurityContext를 통해 사용자 정보를 가져오지만, 테스트에서 매번 실제 로그인 과정을 태우는 것은 비효율적이었다.

그래서 테스트용 Mock 사용자 주입 방식을 만들었다.

WithMockCustomUser

테스트에서 사용할 커스텀 인증 사용자를 만들기 위해 WithMockCustomUser와 SecurityContext 설정 팩토리를 구성했다.

목표는 테스트 코드에서 다음처럼 사용할 수 있게 하는 것이었다.

@WithMockCustomUser
@Test
void joinMeeting_success() {
    ...
}

이렇게 하면 테스트마다 복잡한 인증 준비 코드를 반복하지 않아도 된다.

테스트는 본래 검증하려는 기능에 집중해야 한다.
인증 준비 코드가 너무 길면 테스트 의도가 흐려진다.

TestSecurityConfig

테스트 환경에서는 실제 SecurityConfig를 그대로 사용하기 어려운 경우가 있다.

특히 필터 체인, JWT 검증, 외부 인증 흐름이 포함되면 Controller 테스트가 너무 무거워질 수 있다.

그래서 테스트에서 필요한 수준으로 Security 설정을 재정의했다.

이때 고민한 점은 “보안을 완전히 무시해도 되는가?”였다.

결론적으로 테스트 목적에 따라 다르다고 생각했다.

• Controller의 요청/응답을 검증하는 테스트에서는 필터를 단순화할 수 있다.
• 인증/인가 자체를 검증하는 테스트에서는 실제 Security 흐름에 가깝게 테스트해야 한다.

Meeting 테스트에서는 기능 로직 검증이 목적이었기 때문에, Mock 사용자 기반으로 인증된 상태를 만들어주는 방식을 선택했다.

테스트 데이터 구성

Meeting 테스트에서는 상태별 데이터가 필요했다.

• RECRUITING
• ONGOING
• FULL
• COMPLETED

그리고 태그, 참여자, 장소, 호스트 정보도 필요했다.

처음에는 테스트마다 데이터를 직접 만들었지만, 반복이 많아졌다. 그래서 테스트 유틸과 설정 클래스를 만들어 공통 데이터를 생성하도록 정리했다.

테스트 데이터 생성도 코드 품질에 영향을 준다.
데이터 준비가 복잡하면 테스트를 작성하기 싫어지고, 결국 테스트가 줄어든다.

인증 없이 접근 가능한 API

Meeting 목록과 상세 조회는 인증 없이도 접근 가능해야 했다.

그래서 GET /meetings, GET /meetings/{id} 같은 조회 API는 SecurityConfig에서 permitAll로 열어두는 작업도 함께 했다.

이 부분은 서비스 요구사항과도 연결된다.

사용자는 로그인하지 않아도 모임 목록을 둘러볼 수 있어야 하고, 참여나 생성 같은 행동을 할 때만 로그인이 필요하다.

보안 설정은 단순히 막는 것이 아니라, 사용자 흐름에 맞게 열고 닫는 작업이라는 생각이 들었다.

배운 점

이번 작업을 통해 테스트 환경 구성도 개발의 중요한 일부라는 것을 느꼈다.

기능 구현만큼이나 테스트를 쉽게 작성할 수 있는 구조를 만드는 것이 중요했다.

특히 인증이 들어가는 API는 테스트 난이도가 급격히 올라간다.
그래서 Mock 사용자, TestSecurityConfig, 테스트 데이터 유틸을 잘 구성해두면 이후 기능 테스트가 훨씬 편해진다.

마무리

Meeting 테스트 환경을 정리하면서 Spring Security와 테스트의 관계를 조금 더 이해할 수 있었다.

운영 코드의 보안 흐름과 테스트 코드의 단순화 사이에서 균형을 잡는 것이 중요했다.

앞으로 인증이 필요한 기능을 만들 때는 기능 구현과 동시에 테스트에서 인증 사용자를 어떻게 주입할지도 함께 설계해야겠다고 느꼈다.