[이하나] Sprint6

[hnlee199]

프로젝트 마일스톤

• 데이터베이스 환경 설정 및 모델링
• xSpring Data JPA 환경 적용
• Entity 연관 관계 매핑
• 레포지토리와 서비스 계층에 JPA 적용
• Transaction 처리
• 페이지네이션과 정렬
• DTO의 적극적인 도입과 MapStruct의 활용
• BinaryContent 저장 로직 고도화
• 메타정보와 바이너리 정보 분리
• N+1 문제 해결

기본

• ERD와 클래스 다이어그램을 토대로 연관관계 매핑 정보를 표로 정리해보세요.(이 내용은 PR에 첨부해주세요.)

• Entity를 Controller 까지 그대로 노출했을 때 발생할 수 있는 문제점에 대해 정리해보세요.
  Entity와 API 스펙이 강하게 결합되어 DB 컬럼 하나만 수정해도 클라이언트 응답 규격이 깨지는 사이드 이펙트가 발생하며, 민감한 데이터가 의도치 않게 노출될 위험이 크. DTO 도입 시 변환을 위한 보일러플레이트 코드는 늘어나지만, 이를 통해 API 스펙의 독립성을 보장하고 도메인 모델과 유효성 검증 등 을 명확히 분리할 수 있어 장기적인 유지보수성과 보안성 측면에서 얻는 이점이 훨씬 크다.

심화

• N+1 문제가 발생하는 쿼리를 찾고 해결해보세요.

• 프로덕션 환경에서는 OSIV를 비활성화하는 경우가 많습니다. 이때 서비스 레이어의 조회 메소드에서 발생할 수 있는 문제를 식별하고, 읽기 전용 트랜잭션을 활용해 문제를 해결해보세요.

• 오프셋 페이지네이션과 커서 페이지네이션 방식의 차이에 대해 정리해보세요.
  오프셋 방식은 앞에서부터 얼마나 건너뛸지를 지정하므로 구현이 쉽고 번호판 형태의 UI에 적합하다. 하지만 데이터가 많아질수록 앞부분을 일일이 읽어야해서 성능이 급격히 느려진다. 또한 조회 도중 새 데이터가 추가되면 보던 데이터가 밀려 내려와 다음 페이지에서 중복 노출되는 문제가 발생한다. 반면 커서 방식은 마지막으로 본 데이터의 ID를 기준으로 다음을 찾는다. 인덱스를 타고 넘어가 대용량 데이터에서도 성능이 일정하게 유지된다. 하지만 커서 방식은 특정 페이지로 바로 건너뛰는 기능 구현이 어렵고, 정렬 조건이 복잡해질수록 쿼리 작성이 까다로워진다.

• 기존에 구현한 오프셋 페이지네이션을 커서 페이지네이션으로 리팩토링하세요.

• Entity와 DTO를 매핑하는 보일러플레이트 코드를 MapStruct 라이브러리를 활용해 간소화