Spring 주니어 시스템 설계 면접

페이지 번호 기반 방식은 page와 size 파라미터로 특정 페이지를 조회하며, Spring Data JPA의 Pageable 인터페이스를 사용해 구현합니다. 커서 기반 방식은 마지막 조회 항목의 ID를 기준으로 다음 데이터를 가져오는 방식으로 실시간 데이터 변경에 강합니다. 페이지 기반은 구현이 간단하고 특정 페이지 이동이 가능하지만, 데이터 변경 시 중복/누락이 발생할 수 있습니다. 커서 기반은 일관성은 높지만 특정 페이지로 직접 이동이 불가능합니다. Spring에서는 PageRequest.of(page, size, sort)로 Pageable 객체를 생성하고, Repository 메서드에서 Page<T>를 반환받아 사용합니다.

상품과 카테고리는 다대다(M:N) 관계이므로 중간 연관관계 테이블(ProductCategory)이 필요합니다. @ManyToMany를 사용하면 JPA가 자동으로 중간 테이블을 생성하지만, 추가 속성(등록일, 정렬순서 등)을 넣을 수 없고 쿼리 제어가 어렵습니다. 실무에서는 중간 엔티티를 명시적으로 생성하고 @OneToMany, @ManyToOne으로 분리하는 것이 권장됩니다. 이렇게 하면 중간 테이블에 추가 컬럼을 자유롭게 추가할 수 있고, 쿼리 최적화와 비즈니스 로직 추가가 용이합니다.

Access Token은 짧은 만료시간(15-30분)으로 API 요청 시 사용하며, Refresh Token은 긴 만료시간(7-14일)으로 Access Token 재발급에만 사용합니다. 이렇게 분리하면 Access Token 탈취 시 피해 기간을 최소화할 수 있습니다. Access Token은 클라이언트 메모리나 HttpOnly 쿠키에 저장하고, Refresh Token은 HttpOnly, Secure 속성의 쿠키에 저장하거나 서버 DB에 저장하여 관리합니다. Token 갱신 시에는 Refresh Token의 유효성을 검증하고 DB에 저장된 값과 비교한 후, 새로운 Access Token을 발급합니다. 필요시 Refresh Token도 함께 갱신하는 Refresh Token Rotation 전략을 사용할 수 있습니다.

@Cacheable은 메서드 결과를 캐시에 저장하고 다음 호출 시 캐시에서 반환하며, @CachePut은 항상 메서드를 실행하고 결과를 캐시에 업데이트합니다. @CacheEvict는 캐시를 삭제하는 데 사용됩니다. Cache-Aside 패턴은 캐시 미스 시 DB 조회 후 캐시에 저장하는 방식으로 읽기가 많은 경우 적합하며, Write-Through는 쓰기 시 캐시와 DB에 동시 저장하여 일관성을 보장합니다. 상품 정보 조회는 @Cacheable로 캐싱하고, 상품 수정 시 @CachePut 또는 @CacheEvict로 캐시를 갱신하거나 무효화합니다. TTL(Time To Live)을 설정하여 일정 시간 후 자동 만료되도록 하고, 중요한 데이터 변경 시에는 명시적으로 캐시를 삭제합니다.

다중 인스턴스 환경에서는 세션을 서버 메모리에 저장하면 인스턴스 간 공유가 안 되므로, Spring Session과 Redis를 사용하여 외부 저장소에 세션을 관리해야 합니다. 파일 업로드는 로컬 디스크 대신 S3, NAS 같은 공유 스토리지를 사용하거나 CDN을 활용합니다. @Scheduled 어노테이션으로 구현한 스케줄링 작업은 모든 인스턴스에서 중복 실행되므로, ShedLock 라이브러리나 Quartz Scheduler의 클러스터 모드를 사용하여 단일 실행을 보장합니다. 또한 로드밸런서를 앞단에 배치하여 트래픽을 분산하고, 데이터베이스 커넥션 풀 설정도 인스턴스 수에 맞게 조정해야 합니다. 로깅은 중앙 집중식 로그 수집 시스템(ELK 스택 등)을 구축하여 관리합니다.