채팅 기록 조회 API 개발

[ckdals4600]

관련 이슈

• close 채팅 기록 조회 API 개발 #140

PR 설명

• 사용자가 채팅방 입장 시 이전 대화 내역을 최신순으로 조회하는 API 개발
• 대용량 데이터 처리를 고려하여 No-Offset 페이징(무한 스크롤) 방식을 적용

작업 내용

1. API 명세 구현 (ChatController)

• Endpoint: GET /v1/chats/{chatId}
• Params: lastId(커서, 첫 조회 시 null), size(기본 20)
• Response: MessagesRes (메시지 목록, 다음 페이지 여부, 마지막 ID 반환).
  • • 메시지 목록(messages) 내부에 링크 목록(links)이 포함되며, 각 링크는 summary(요약 내용) 필드를 가집니다.

      {
        "success": true,
        "status": "OK",
        "message": "채팅 기록을 가져오는데 성공했습니다.",
        "data": {
          "messages": [
            {
              "id": 105,
              "content": "JPA N+1 문제는 Batch Size로 해결할 수 있습니다. 아래 글을 참고하세요.",
              "type": "AI",
              "feedback": "LIKE",
              "time": "2024-10-31 14:30:00"
              "links": [
                 {
                   "id": 12,
                   "title": "JPA N+1 문제 해결 가이드",
                   "url": "https://example.com/jpa-n-plus-1",
                   "imageUrl": "https://example.com/image.png",
                   "summary": "JPA에서 지연 로딩으로 인해 발생하는 N+1 문제의 원인과 해결 방법을 다룹니다."
                 }
              ]
            },
            {
              "id": 104,
              "content": "N+1 문제가 뭐야?",
              "type": "USER",
              "time": "2024-10-31 14:31:00"
              "links": []
            }
          ],
          "hasNext": true,
         "lastId": 104
        }
      }

• Validation: size 파라미터에 대한 최소(1)/최대(50) 검증 로직을 @Validated로 적용함.

2. 아키텍처 및 비즈니스 로직

복잡한 JOIN으로 인한 성능 저하를 막기 위해 단계별 조회 및 메모리 조립 전략을 사용했습니다.

• 1단계: 메시지 조회 (MessageQueryService)
  • No-Offset 페이징(id < lastId)을 사용하여 메시지 목록을 빠르게 조회합니다.
  • Message와 Link 관계는 default_batch_fetch_size 설정을 통해 IN 쿼리로 최적화했습니다.
• 2단계: 요약 정보 일괄 조회 (SummaryQueryService)
  • 조회된 메시지들에서 Link 목록을 추출합니다.
  • findAllByLinkInAndSelectedTrue를 호출하여, 관련된 **대표 요약(Selected Summary)**들을 단 한 번의 쿼리(IN 절)로 가져옵니다.
• 3단계: 데이터 조립 (MessageService)
  • 조회된 요약 리스트를 Map<LinkId, Summary> 형태로 변환하여 메모리에 올립니다.
  • 메시지-링크-요약 정보를 매핑하여 최종 MessageDto를 생성합니다.

3. 메시지-링크 연관관계 리팩토링 (성능 최적화)

• Entity 수정 (Message):
  • 기존 List<Long> linkIds를 삭제하고 @ManyToMany (List<Link>) 관계로 변경하여 객체 지향적인 설계를 적용함.
  • @JoinTable 적용: 연결 테이블(message_link)을 매핑하기 위해 별도의 중간 엔티티 클래스(예: MessageLink)를 생성하지 않고, 어노테이션만으로 간결하게 다대다 관계를 풀어냄.
  • Cascade 옵션을 미설정하여 메시지 삭제가 원본 링크 데이터에 영향을 주지 않도록 함.
• N+1 문제 해결 (application.yml):
  • default_batch_fetch_size: 100 설정을 추가함.
  • 복잡한 JOIN FETCH 없이도 연관된 링크 엔티티를 IN 쿼리로 묶어서 조회하여, 페이징 시 메모리 이슈를 방지하고 쿼리 성능을 최적화함.

4. Repository 및 성능 최적화

• No-Offset Paging:
  • WHERE m.id < :lastId 조건을 사용하여 데이터 양이 늘어나도 조회 속도가 유지되도록 함.
• Query 최적화 (MessageRepository):
  • Feedback은 @OneToOne이므로 LEFT JOIN FETCH를 유지하되, Links는 Batch Fetching을 활용하므로 JOIN을 제거하여 쿼리를 단순화함.

3. Entity 및 DTO 구조 개선

• Entity (Message):
  • List<Long> linkIds를 제거하고 @ManyToMany(List<Link>) 관계로 변경하여 객체 그래프 탐색이 가능하도록 수정했습니다.
  • @JoinTable을 사용하여 중간 엔티티 클래스 없이 깔끔하게 매핑했습니다.
• DTO (LinkCardRes, MessageRes):
  • 링크 정보를 보여주는 LinkCardRes에 summary 필드를 추가했습니다.
  • 팩토리 메서드를 통해 Link와 Summary 엔티티를 조합하여 DTO로 변환하도록 구현했습니다.

4. 테스트 작성

• Integration Test (ChatIntegrationTest):
  • API 호출 시 메시지, 링크, 그리고 **요약 내용(summary)**까지 정상적으로 JSON 응답에 포함되는지 검증했습니다.
• Unit Test (MessageServiceTest):
  • summaryQueryService가 호출되어 링크에 맞는 요약 정보를 가져오는지(Map핑 로직) 검증했습니다.
  • 중복된 링크가 있을 때 불필요한 중복 조회가 발생하지 않는지 확인했습니다.
• Repository Test (SummaryRepositoryTest):
  • IN 쿼리를 통해 여러 링크의 대표 요약본이 한 번에 조회되는지 확인했습니다.

[github-actions]

📊 코드 커버리지 리포트

Overall Project	88.62% -0.43%	🍏
Files changed	92.35%	🍏

File	Coverage
LinkController.java	100%	🍏
Sentiment.java	100%	🍏
MessageQueryService.java	100%	🍏
ChatFacade.java	100%	🍏
SummaryQueryService.java	95% -5%	🍏
ChatController.java	77.36% -22.64%	❌
MessageService.java	74.31%	🍏

[ckdals4600]

링크 제공 시 요약 정보 포함(#158) 작업에 의존성이 존재합니다.

[Goder-0]

채팅의 시간, 피드백 여부 등도 포함되어야 할 것 같습니다. 어떻게 생각하시나요?

[ckdals4600]

채팅의 시간, 피드백 여부 등도 포함되어야 할 것 같습니다. 어떻게 생각하시나요?

채팅 생성 시간을 전달하도록 수정하였습니다.
다만 피드백 여부에 대해서는 현재 AI 메세지인 경우에만 LIKE, DISLIKE, NONE으로 3가지 종류로 전달 중에 있습니다. 해당 부분에 대해서 추가적인 수정을 말씀하신 건가요?

[Goder-0]

다만 피드백 여부에 대해서는 현재 AI 메세지인 경우에만 LIKE, DISLIKE, NONE으로 3가지 종류로 전달 중에 있습니다. 해당 부분에 대해서 추가적인 수정을 말씀하신 건가요?

PR의 본문에 포함안된 부분이 있어, 포함이 안되는것으로 착각했습니다.