해당 기능에 대한 최적화를 말씀해주셔서 저도 고민을 해볼 수 있어서 좋았습니다.
commentsId를 꺼낸 다음에, 한꺼번에 조회를 하는 방식은 어떤지 궁금합니다.
한꺼번에 조회를 한 다음 정리를 해주면 될 것 같다는 생각이 들었습니다.

List commentIds = comments.stream()
.map(Comment::getId)
.collect(Collectors.toList());

List replies = replyQueryRepositoryPort.findAllByCommentIdIn(commentIds);

👍 정말 좋은 고민이였습니다.

해당 기능에 현재 QueryDSL이 제공되는 문법에는 윈도우 함수 적용이 쉽지가 않습니다. 또한 댓글과 대댓글에 케이스는 하나의 댓글에 몇개의 대댓글을 가져올지 ROW 개수 제한도 포함되어야 합니다.

🤔 저는 선택적으로 Native Query를 사용해야 한다고 생각합니다!

수용님이 작성하신 부분에서 더 수정을 하자면

// limit 갯수 추가
List replies = replyQueryRepositoryPort.findAllByCommentIdIn(commentIds, 10);

SELECT *
FROM (
         SELECT *,
                ROW_NUMBER() OVER (PARTITION BY reply.comment_id ORDER BY reply.created_at ASC) as rn
         FROM reply
         WHERE reply.comment_id IN (:commentIds)
     ) ranked
WHERE rn <= (:limit)

이렇게 되면 하기 와 같이 DB에서 조회가 되며 (5개만 조회)

조회 후에는 Application 단에서 commentId에 맞게 매핑을 시켜주면 된다고 생각합니다.

음.. 결국 특정 DB에 종속되는 건데 ROW_NUMBER()가 대부분의 RDBMS가 지원한다고 하더라도
특정 버전 (ex. MySQL 8.0 미만)의 경우 ROW_NUMBER()를 지원하지 않습니다.

이런 경우는 배제하고 효율을 챙기는 게 좋을까요?? @merge-simpson @sweetykr7 @silberbullet @wch-os

*참고

관련 논의는 'JSON 필드 사용: reply 첫 페이지에 대해서만 JSON 필드에 중복으로 관리' 방식을 시도하는 것으로 이야기되었습니다.

👍 정말 좋은 고민이였습니다.

해당 기능에 현재 QueryDSL이 제공되는 문법에는 윈도우 함수 적용이 쉽지가 않습니다. 또한 댓글과 대댓글에 케이스는 하나의 댓글에 몇개의 대댓글을 가져올지 ROW 개수 제한도 포함되어야 합니다.

🤔 저는 선택적으로 Native Query를 사용해야 한다고 생각합니다!

수용님이 작성하신 부분에서 더 수정을 하자면

// limit 갯수 추가
List replies = replyQueryRepositoryPort.findAllByCommentIdIn(commentIds, 10);

SELECT *
FROM (
         SELECT *,
                ROW_NUMBER() OVER (PARTITION BY reply.comment_id ORDER BY reply.created_at ASC) as rn
         FROM reply
         WHERE reply.comment_id IN (:commentIds)
     ) ranked
WHERE rn <= (:limit)

이렇게 되면 하기 와 같이 DB에서 조회가 되며 (5개만 조회)

조회 후에는 Application 단에서 commentId에 맞게 매핑을 시켜주면 된다고 생각합니다.