[Feature]: 댓글 깊이와 아키텍처

[devikae]

Package Scope

• Add to an existing package
• New package

Package name: com.ikae.snowthing.domain.comment

Overview

댓글/대댓글 조회 시 전체 데이터를 한 번에 가져오는 구조라 댓글 수가 많아지면 메모리와 응답 속도에 부담이 됩니다.
대댓글 깊이 제한, 삭제 시 카운트 처리, 정렬 기준 등 미비한 부분들을 함께 정리하고자 합니다.

Current Problems

1. 전체 조회로 인한 응답 및 메모리 부하
   • 현재 getCommentsByPost는 페이징 없이 특정 글의 모든 댓글을 한 번에 메모리에 올려 조립합니다.
   • 댓글이 많이 달린 글에서는 응답 크기가 커지고 메모리 사용량이 늘어납니다.
2. 대댓글 계층 깊이 미제한
   • 대댓글의 ID를 parentId로 넣으면 계층이 3단계 이상으로 깊어질 수 있어 UI 표현에 문제가 생깁니다.
3. 삭제 처리 및 카운트 불일치
   • 부모와 대댓글이 모두 삭제되어도 빈 노드가 응답에 남을 수 있습니다.
   • 내용이 없는 삭제된 댓글까지 commentCount에 잡혀 실제 읽을 수 있는 댓글 수와 차이가 납니다.
4. 동일 생성 시각 정렬 불안정
   • created_at만으로 정렬할 경우 동일 시각에 등록된 댓글들의 순서가 일정하지 않을 수 있습니다.

Describe the solution you'd like

1. 조회 방식 개선 (루트 페이징 + 대댓글 프리뷰)
   • 루트 댓글은 20개 기준으로 페이징하고, 대댓글은 상위 5개까지만 함께 조회합니다.
   • 5개를 넘는 대댓글은 GET /api/v1/comments/{commentId}/replies로 분리하여 조회하도록 변경합니다.
2. 2단계 계층 고정
   • 대댓글에 답글을 달아도 최상위 루트 댓글의 ID를 바라보도록 평탄화합니다.
   • 루트 댓글 1개당 대댓글 수는 최대 100개로 제한합니다.
3. 삭제 및 카운트 정리
   • 부모와 자식이 모두 삭제된 노드는 목록에서 제외합니다.
   • post.comment_count와 replyCount는 실제 유효한 댓글 수만 집계합니다.
4. 정렬 기준 고정
   • ORDER BY created_at ASC, comment_id ASC로 정렬 기준을 명확히 합니다.

Additional context