src/main/java/eatda/repository/cheer/CheerTagRepository.java (2)

10-10: 파라미터 이름이 혼동을 줄 수 있습니다 (Store 타입인데 storeId 명명).

메서드 시그니처상 Store 엔티티를 받으므로, 변수명은 store가 적절합니다.

아래와 같이 변수명만 정리해 주세요.

-    List<CheerTag> findAllByCheerStore(Store storeId);
+    List<CheerTag> findAllByCheerStore(Store store);

---

10-10: DB 레벨 DISTINCT + 프로젝션으로 중복/페이로드 최소화 제안

현재는 모든 CheerTag 엔티티를 로드한 뒤 응답 단계에서 distinct 처리합니다. 태그 수가 많을 경우 불필요한 엔티티 로딩과 메모리 사용이 발생할 수 있어, DB에서 곧바로 DISTINCT 이름 목록을 가져오는 프로젝션 메서드를 추가하는 방안을 권장합니다.

예시 (Repository에 보강):

// import 필요:
// import eatda.domain.cheer.CheerTagName;
// import org.springframework.data.jpa.repository.Query;
// import org.springframework.data.repository.query.Param;

@Query("""
    select distinct ct.name
    from CheerTag ct
      join ct.cheer ch
    where ch.store = :store
""")
List<CheerTagName> findDistinctNamesByCheerStore(@Param("store") Store store);

Service 변경 예시:

- List<CheerTag> cheerTags = cheerTagRepository.findAllByCheerStore(store);
- return TagsResponse.from(cheerTags);
+ List<CheerTagName> tagNames = cheerTagRepository.findDistinctNamesByCheerStore(store);
+ return new TagsResponse(tagNames); // record의 canonical ctor 활용

필요하시다면 관련 DTO/테스트까지 포함한 패치 제안 드리겠습니다.

src/test/java/eatda/controller/store/StoreControllerTest.java (1)

157-174: 태그 조회 컨트롤러 테스트 케이스 적절 (정상 시나리오). 추가 시나리오 확장을 제안합니다.

현재 케이스는 단일 Cheer에 부착된 2개 태그의 반환을 검증합니다. 다음 보강을 고려해 주세요:

• 동일 가게의 여러 Cheer에 중복 태그가 존재할 때, 응답이 중복 없이 dedup됨을 검증
• 해당 가게에 태그가 하나도 없을 때 빈 리스트를 반환하는지 검증

추가 예시:

@Test
void 음식점_태그가_없으면_빈_리스트를_반환한다() {
    Store store = storeGenerator.generate("상호명", "주소");
    TagsResponse response = given()
            .when()
            .get("/api/shops/{storeId}/tags", store.getId())
            .then()
            .statusCode(200)
            .extract().as(TagsResponse.class);

    assertThat(response.tags()).isEmpty();
}

@Test
void 여러_응원에_중복_태그가_있어도_중복없이_반환한다() {
    Member member = memberGenerator.generate("u1");
    Store store = storeGenerator.generate("상호명", "주소");
    Cheer cheer1 = cheerGenerator.generateCommon(member, store, "img-1");
    Cheer cheer2 = cheerGenerator.generateCommon(member, store, "img-2");
    cheerTagGenerator.generate(cheer1, List.of(CheerTagName.CLEAN_RESTROOM, CheerTagName.INSTAGRAMMABLE));
    cheerTagGenerator.generate(cheer2, List.of(CheerTagName.CLEAN_RESTROOM));

    TagsResponse response = given()
            .when()
            .get("/api/shops/{storeId}/tags", store.getId())
            .then()
            .statusCode(200)
            .extract().as(TagsResponse.class);

    assertThat(response.tags())
            .containsExactlyInAnyOrder(CheerTagName.CLEAN_RESTROOM, CheerTagName.INSTAGRAMMABLE);
}

사소한 사항: GET 요청에 contentType(JSON) 지정은 불필요하므로 제거해도 무방합니다.

src/main/java/eatda/service/store/StoreService.java (1)

58-63: 기능은 정합. 성능 최적화를 위해 DB에서 DISTINCT 태그명만 조회하는 방안을 고려해 주세요.

현재는 모든 CheerTag 엔티티를 읽어와 앱 레이어에서 distinct 처리합니다. 태그/응원 데이터가 많을 때 비용이 커질 수 있습니다.

리포지토리에 findDistinctNamesByCheerStore(Store store)(DISTINCT name 프로젝션)를 추가하고, 아래처럼 단순화할 수 있습니다.

- Store store = storeRepository.getById(storeId);
- List<CheerTag> cheerTags = cheerTagRepository.findAllByCheerStore(store);
- return TagsResponse.from(cheerTags);
+ Store store = storeRepository.getById(storeId);
+ List<CheerTagName> tagNames = cheerTagRepository.findDistinctNamesByCheerStore(store);
+ return new TagsResponse(tagNames);

추가적으로, 읽기 전용 메서드와 동일한 일관성을 위해 getStoreImages에도 @Transactional(readOnly = true) 부여를 고려할 수 있습니다. 필수는 아니며 선택 사항입니다.

src/test/java/eatda/service/store/StoreServiceTest.java (1)

161-178: 교차 가게 격리 검증 테스트 추가 제안

현재 테스트는 하나의 가게에 한정되어 있어, 다른 가게의 태그가 섞여 들어오지 않는지(리포지토리 where 조건)도 함께 보장하면 좋습니다.

아래와 같은 테스트 추가를 고려해 주세요:

@Test
void 다른_가게_태그는_포함되지_않는다() {
    Member member = memberGenerator.generate("111", "[email protected]", "nickname1");
    Store target = storeGenerator.generate("농민백암순대", "서울 강남구 대치동 896-33");
    Store other = storeGenerator.generate("석관동떡볶이", "서울 성북구 석관동 123-45");

    Cheer cheerInTarget = cheerGenerator.generateCommon(member, target);
    Cheer cheerInOther = cheerGenerator.generateCommon(member, other);

    cheerTagGenerator.generate(cheerInTarget, List.of(CheerTagName.INSTAGRAMMABLE));
    cheerTagGenerator.generate(cheerInOther, List.of(CheerTagName.ENERGETIC));

    TagsResponse response = storeService.getStoreTags(target.getId());

    assertThat(response.tags()).containsExactly(CheerTagName.INSTAGRAMMABLE);
}

src/main/java/eatda/controller/store/TagsResponse.java (1)

3-13: 클라이언트 일관성을 위해 정렬 추가 제안

현재 distinct 이후의 순서는 데이터 조회 순서에 의존합니다(쿼리 정렬 미보장 시 비결정적일 수 있음). 응답의 안정성을 위해 enum 이름 기준 정렬을 권장합니다.

다음과 같이 정렬을 포함하는 변경을 제안합니다:

 package eatda.controller.store;

 import eatda.domain.cheer.CheerTag;
 import eatda.domain.cheer.CheerTagName;
 import java.util.List;
+import java.util.Comparator;

 public record TagsResponse(List<CheerTagName> tags) {

     public static TagsResponse from(List<CheerTag> cheerTags) {
         List<CheerTagName> cheerTagNames = cheerTags.stream()
                 .map(CheerTag::getName)
                 .distinct()
+                .sorted(Comparator.comparing(Enum::name))
                 .toList();
         return new TagsResponse(cheerTagNames);
     }
 }

src/main/java/eatda/controller/store/StoreController.java (2)

45-49: 코드 스타일 일관성: 인라인 반환으로 통일 제안

바로 위 이미지 엔드포인트처럼 인라인 반환으로 통일하면 가독성이 좋아집니다.

아래처럼 단순화할 수 있습니다:

 @GetMapping("/api/shops/{storeId}/tags")
 public ResponseEntity<TagsResponse> getStoreTags(@PathVariable long storeId) {
-    TagsResponse response = storeService.getStoreTags(storeId);
-    return ResponseEntity.ok(response);
+    return ResponseEntity.ok(storeService.getStoreTags(storeId));
 }

---

40-49: 캐싱 고려(옵션): 읽기 많은 엔드포인트는 Cache-Control 혹은 서버 캐시 적용 검토

태그/이미지 조회는 변경 빈도 대비 조회가 많은 성격입니다. 짧은 TTL의 HTTP 캐시 헤더나 서버측 캐시(e.g., @Cacheable) 적용을 고려하면 비용을 줄일 수 있습니다.

src/test/java/eatda/fixture/CheerTagGenerator.java (1)

19-23: 배치 저장으로 왕복 최소화 제안(saveAll 활용)

여러 태그를 개별 save로 저장하는 대신 saveAll로 한번에 처리하면 테스트 성능과 간결함이 개선됩니다.

다음과 같이 변경을 제안합니다:

 public List<CheerTag> generate(Cheer cheer, List<CheerTagName> tagNames) {
-    return tagNames.stream()
-            .map(name -> cheerTagRepository.save(new CheerTag(cheer, name)))
-            .toList();
+    return cheerTagRepository.saveAll(
+            tagNames.stream()
+                    .map(name -> new CheerTag(cheer, name))
+                    .toList()
+    );
 }

추가로 가독성을 위해 가변 인자 오버로드도 고려해 볼 수 있습니다(선택):

public List<CheerTag> generate(Cheer cheer, CheerTagName... tagNames) {
    return generate(cheer, List.of(tagNames));
}

src/test/java/eatda/document/store/StoreDocumentTest.java (2)

233-244: 문서 스니펫 구성 적합 — 응답 필드 최소 계약을 명확화

tags 배열만 노출하는 단순 계약을 잘 반영했습니다. enum 값이라는 점을 설명에 명시하면 독자가 이해하기 더 쉽습니다.

아래처럼 설명을 보강하는 것을 제안합니다:

 RestDocsResponse responseDocument = response()
         .responseBodyField(
-                fieldWithPath("tags").type(ARRAY).description("음식점 태그 목록")
+                fieldWithPath("tags").type(ARRAY).description("음식점 태그 목록 (CheerTagName enum 값 목록)")
         );

---

256-259: path 변수 바인딩 방식 일관화 제안

다른 테스트(GetStoreImages 등)와 동일하게 pathParam을 사용하는 스타일로 통일하면 가독성이 좋아집니다(기능 차이는 없음).

다음과 같이 변경할 수 있습니다:

- given(document)
-         .contentType(ContentType.JSON)
-         .when().get("/api/shops/{storeId}/tags", storeId)
-         .then().statusCode(200);
+ given(document)
+         .contentType(ContentType.JSON)
+         .pathParam("storeId", storeId)
+         .when().get("/api/shops/{storeId}/tags")
+         .then().statusCode(200);

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.