삽질로그

통합테스트에서 DB 데이터 초기화 방법

왜 DB 데이터 초기화가 필요할까?테스트 간 데이터 오염을 방지하고 독립적인 테스트 환경을 보장하기 위해서다.처음 프로젝트를 진행하면서 테스트가 간헐적으로 실패하는 현상을 겪었는데,원인을 찾아보니 이전 테스트에서 생성된 데이터가 남아있어서 발생한 문제였다.예를 들어 findAll() 메서드를 테스트할 때 예상한 결과는 3개였는데 실제로는 5개가 나오는 식이었다.**테스트 격리(Test Isolation)**의 중요성을 깨달은 순간이었다.각 테스트는 다른 테스트의 영향을 받지 않아야 한다는 기본 원칙을 지켜야 했다.주요 초기화 방법들1. @Transactional + @Rollback@SpringBootTest@Transactionalclass UserServiceTest { @Test ..

프로젝트에서 성능 이슈가 계속 발생해서 Redis 캐싱을 적용해보기로 했다.생각보다 전략이 다양했다.정리해보자.캐싱 전략들전략 설명 장점 단점 사용 시기Cache-Aside애플리케이션이 직접 캐시 관리필요한 데이터만 캐싱, 장애 격리첫 요청 느림, 복잡한 코드읽기 중심 애플리케이션Write-Through캐시와 DB 동시 저장데이터 일관성 보장쓰기 성능 저하일관성이 중요한 시스템Write-Behind캐시 먼저, DB는 나중빠른 쓰기 성능데이터 손실 위험고성능 쓰기가 필요한 경우Read-Through캐시가 DB 조회 대행간단한 애플리케이션 코드캐시 의존성 증가읽기 패턴이 단순한 경우실제로 써본 Cache-Aside 패턴@Servicepublic class UserService { @Autowir..

최근 프로젝트에서 Spring Security와 JWT를 활용한 인증 시스템을 구현하면서 여러 보안 이슈들을 마주하게 되었습니다.단순히 JWT를 발급하고 검증하는 것을 넘어서, 실제 운영 환경에서 고려해야 할 보안 요소들이 생각보다 많았습니다.오늘은 제가 직접 경험하고 학습한 Spring Security JWT 구현 시 반드시 고려해야 할 보안 사항들을 정리해보겠습니다.1. JWT 서명 알고리즘 선택과 키 관리안전한 서명 알고리즘 사용처음 JWT를 구현할 때 HS256 알고리즘을 사용했는데, 이후 RS256으로 변경하게 되었습니다.그 이유는 다음과 같습니다:// 권장하지 않는 방식 (HS256)@Componentpublic class JwtTokenProvider { private final Str..

기능적으로는 동일함 - 모두 스프링 컨테이너에 Bean 등록의미적 차이가 핵심 - 코드 가독성과 유지보수성예외 처리에서 차이 - @Repository만 특별한 기능 있음[어노테이션별 특징]@Component가장 기본적인 어노테이션범용적으로 사용다른 세 개 어노테이션의 부모격@Componentpublic class UtilComponent { // 유틸리티성 클래스}@Service비즈니스 로직 처리Service 계층에서 사용@Component를 상속받음@Servicepublic class UserService { // 비즈니스 로직}@Repository데이터 접근 계층DAO 클래스에 사용예외 변환 기능 추가 (중요!)@Repositorypublic class UserRepository { ..

커넥션 풀이란?DB 연결을 미리 생성해서 풀에 저장요청 시 풀에서 가져다 쓰고 반납매번 새로 생성/삭제하는 오버헤드 제거풀 사이즈가 중요한 이유너무 작으면: 대기 시간 증가, 성능 저하너무 크면: 메모리 낭비, DB 부하 증가적절한 균형점 찾는 것이 핵심기본 설정 공식최소 풀 사이즈 = CPU 코어 수최대 풀 사이즈 = CPU 코어 수 × 2 ~ 4[홈페이지 제작 기준 설정값]소규모 개인 홈페이지최소: 2-5개최대: 10-20개동시 접속자 50명 이하중소규모 회사 홈페이지최소: 5-10개최대: 20-50개동시 접속자 100-500명대규모 서비스최소: 10-20개최대: 50-100개 이상부하 테스트 필수HikariCP 설정 예시# application.ymlspring: datasource: hik..