[파이널 과제] NovelCraft 웹소설 창작 플랫폼 개발 프로젝트 Day 1

https://github.com/Hot6-NovelCraft/Hot6-NovelCraft

GitHub - Hot6-NovelCraft/Hot6-NovelCraft

 

1. 전반적인 설계 방향: "유연성과 독립성"
이번 독서 기록 시스템의 핵심은 내부 플랫폼 데이터와 외부 수동 입력 데이터의 공존입니다.

연관관계의 최소화 (ID 직접 참조): JPA의 연관관계 매핑(@ManyToOne 등) 대신 userId, novelId를 Long 값으로 직접 참조했습니다. 이는 마이크로서비스로의 확장성을 고려하고, 도메인 간의 결합도를 낮추어 유지보수성을 높이기 위한 전략적 선택입니다.

관심사의 분리: Library(서재)는 소유 여부를 검증하고, ReadingRecord(독서 기록)는 실제 행위를 기록합니다. 서비스 계층에서는 이를 조합하여 '내 서재에 있는 책만 기록 가능하게' 하는 비즈니스 로직을 구현했습니다.

2. 주요 기술 선택 이유 (Technical Decision)
Query Projection과 Java Record 사용
이유: CalendarDailyResponse, MonthlyStatResponse 등 통계와 조회를 위한 데이터 구조에 Java 17의 Record를 적극 활용했습니다.

사용 포인트: 불변성(Immutability)을 보장하고 Boilerplate 코드를 줄임으로써, 데이터 전달 객체(DTO)의 본연의 역할에 집중했습니다.

다중 조건 동적 쿼리 (JPQL + Null Handling)
이유: findByCondition 메서드에서 date와 novelId의 유무에 따라 필터링이 달라져야 했습니다.

사용 포인트: QueryDSL 도입 전, 복잡하지 않은 동적 쿼리를 JPQL의 (:param IS NULL OR r.field = :param) 패턴으로 해결하여 의존성을 최소화하고 가독성을 확보했습니다.

Stream API를 활용한 시계열 데이터 가공
이유: 캘린더 조회 시 기록이 없는 날짜도 0의 값으로 응답해야 합니다.

사용 포인트: DB에서 모든 날짜를 채워오는 대신, 기록이 있는 데이터만 조회한 후 Java의 LocalDate.datesUntil()을 사용하여 메모리 상에서 시계열 데이터를 완성했습니다. 이는 DB 부하를 줄이고 로직의 명확성을 높입니다.

3. 트러블슈팅 (Troubleshooting)
이슈: 통계 데이터의 부정확성 및 미래 날짜 조회 방지
상황: 사용자가 미래의 월에 대한 통계를 요청하거나, 기록이 없는 달을 조회할 때 예상치 못한 응답이 발생할 가능성이 있었습니다.

해결: 

1.  YearMonth.isAfter(YearMonth.now())를 통해 미래 날짜 요청 시 INVALID_STAT_DATE 예외를 던지도록 방어적 로직을 추가했습니다.
2.  double dailyAverage 계산 시 0으로 나누는 오류(ArithmeticException)를 방지하기 위해 totalReadPages == 0 체크 로직을 삽입하고, 소수점 첫째 자리까지 반올림하여 데이터 가독성을 높였습니다.

이슈: 플랫폼 도서 기록 시 데이터 정합성 검증
상황: RecordSource.PLATFORM인 경우 시스템 내의 소설 정보를 참조해야 하지만, 사용자가 임의의 novelId를 보낼 위험이 있었습니다.

해결: LibraryRepository를 통해 해당 유저의 서재에 존재하는 소설인지 먼저 검증하는 단계를 createReadingRecord 서비스 로직 최상단에 배치하여 데이터 무결성을 확보했습니다.

4. 오늘의 한줄평
단순히 CRUD를 구현하는 것을 넘어, '사용자가 1년 치 데이터를 한 번에 조회하면 DB와 네트워크에 어떤 영향을 줄까?'를 고민하여 DATE_RANGE_TOO_LARGE 예외 처리를 넣은 점은 아주 좋은 선택인것 같습니다. 앞으로는 통계 로직이 무거워질 경우를 대비해 DB 단에서 GROUP BY를 처리하는 방식과 현재처럼 애플리케이션에서 처리하는 방식의 성능 차이를 비교해보는 것도 좋은 성장이 될 것같습니다.