Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/main/java/com/kustacks/kuring/club/adapter/in/web/ClubQueryApiV2.java`:
- Around line 78-114: The JWT handling between getClubs and getClubDetail is
inconsistent; update getClubDetail to match getClubs by removing the thrown
InvalidStateException and only setting loginUserId when
jwtTokenProvider.validateToken(jwt) returns true (i.e., if bearerToken != null
then extractAuthorizationValue(...), call validateToken(jwt) and if valid set
loginUserId = Long.parseLong(jwtTokenProvider.getPrincipal(jwt)), otherwise
leave loginUserId null), so getClubDetail uses the same silent fallback behavior
as getClubs (unless you intend to require authentication—if so, make getClubs
throw instead).
- Line 82: The code calls Long.parseLong(jwtTokenProvider.getPrincipal(jwt))
(used to set loginUserId at least in ClubQueryApiV2) which can throw
NumberFormatException if the JWT subject isn't a numeric string; add handling by
validating or parsing safely: either change JwtTokenProvider.getPrincipal() to
return a Long (or an Optional<Long>) if you can guarantee numeric subjects, or
wrap the parse in a try/catch that catches NumberFormatException and translates
it into a controlled response (e.g., throw a custom authentication/validation
exception or return a 401/400) so the service does not propagate 500; apply the
same fix for the other occurrence at the second parse around line 113.

In
`@src/main/java/com/kustacks/kuring/club/adapter/in/web/dto/ClubDetailResponse.java`:
- Around line 28-58: The null-check in ClubDetailResponse.from is ineffective
because ClubQueryService.getClubDetail always returns a
ClubDetailResult.Location instance even when all location fields are null; fix
this in ClubQueryService.getClubDetail by changing the logic that constructs
ClubDetailResult.Location so it returns null when all constituent fields
(building, room, lon, lat) are null/absent, i.e., only create new
ClubDetailResult.Location(...) when at least one of those fields is non-null;
keep ClubDetailResponse.from as-is so it will receive a true null when there is
no location.

In
`@src/main/java/com/kustacks/kuring/club/adapter/out/persistence/ClubQueryRepositoryImpl.java`:
- Around line 31-58: The cursor check in searchClubs currently uses
idAfterCursor(cursor) which only applies club.id.gt(Long.parseLong(cursor)),
causing missing rows when sort order is not by id; update idAfterCursor (or
create a new method used by searchClubs) to decode a composite cursor that
includes the last sort key and lastId (e.g. "lastKey|lastId") and produce a
boolean expression matching keyset pagination: for sortBy "name" produce
(club.name.gt(lastName).or(club.name.eq(lastName).and(club.id.gt(lastId)))) and
for "recruitEndAt" produce
(club.recruitEndAt.gt(lastEndAt).or(club.recruitEndAt.eq(lastEndAt).and(club.id.gt(lastId)))),
falling back to club.id.gt(lastId) for id-only sort; ensure searchClubs uses
getOrderSpecifiers(sortBy) and the new composite cursor predicate so ordering
and cursor logic align.
- Around line 180-183: The idAfterCursor method currently calls
Long.parseLong(cursor) without handling NumberFormatException; update
idAfterCursor(String cursor) to validate or safely parse the cursor (e.g.,
try-catch NumberFormatException or use a numeric-checked parse) and if parsing
fails return null (or an appropriate empty predicate) instead of letting the
exception propagate; ensure you keep the existing behavior of returning null for
null/"0" and use the parsed long value with club.id.gt(...) when parsing
succeeds.
- Around line 39-58: The projection is mapping club.posterImagePath into the
ClubReadModel's 4th constructor parameter (iconImageUrl), which is semantically
incorrect; pick one resolution and implement it consistently: either add an
iconImagePath field to the Club entity and use club.iconImagePath in the
QClubReadModel projection inside ClubQueryRepositoryImpl, or rename/change
ClubReadModel's 4th parameter to posterImageUrl and update
QClubReadModel/constructor usages accordingly so the projected field names and
entity fields match (references: ClubQueryRepositoryImpl, QClubReadModel,
club.posterImagePath, ClubReadModel constructor).

In
`@src/main/java/com/kustacks/kuring/club/application/port/in/ClubQueryUseCase.java`:
- Line 15: getClubDetail 메서드의 파라미터 중 userToken과 loginUserId가 중복되어 책임 경계가 모호합니다:
ClubQueryUseCase 인터페이스의 getClubDetail(Long id, String userToken, Long
loginUserId)에서 userToken이 단순 식별용이라면 userToken을 제거하고 loginUserId만 사용하도록 시그니처를
변경하고, 컨트롤러/시큐리티 레이어에서 토큰을 파싱해 loginUserId를 전달하도록 수정하세요; 만약 userToken이 외부 API 호출
등 별도 목적이라면 getClubDetail 선언에 해당 의도를 주석으로 명확히 남기고 getClubs(Long id, Long
loginUserId)와의 일관성을 위해 다른 메서드들도 같은 패턴(userToken 포함)으로 맞추거나 인터페이스 설계 문서를 업데이트하세요.

In
`@src/main/java/com/kustacks/kuring/club/application/service/ClubQueryService.java`:
- Around line 55-82: The current mapping in ClubQueryService iterates
cursorBasedList.getContents() and calls clubQueryPort.countSubscribers(...) and
clubQueryPort.existsSubscription(...) per club causing N+1 queries; instead add
port methods to fetch subscriber counts and subscription existence in bulk
(e.g., clubQueryPort.countSubscribersByClubIds(List<Long> clubIds) returning a
Map<Id,Integer> and clubQueryPort.findSubscribedClubIdsByUser(Long userId,
List<Long> clubIds) returning a Set<Id>), call those once before the stream,
then construct each ClubItemResult using the pre-fetched counts and subscription
set (replace per-item calls to countSubscribers and existsSubscription with
lookups into the returned collections).
- Around line 109-133: The code in ClubQueryService always constructs a new
ClubDetailResult.Location even when all location fields are null, causing
ClubDetailResponse.from()'s result.location() to be non-null with all-null
fields; change the return construction in ClubQueryService so you only create
and pass a new ClubDetailResult.Location when at least one of dto.getBuilding(),
dto.getRoom(), dto.getLon(), dto.getLat() is non-null (otherwise pass null),
ensuring Location is null for clubs without location data.

---

Nitpick comments:
In
`@src/main/java/com/kustacks/kuring/club/adapter/out/persistence/ClubQueryRepositoryImpl.java`:
- Around line 200-220: The current calculateRecruitmentStatus method returns
RECRUITING when start and end are both null and isAlways is false; change this
to return a safer default (e.g., introduce ClubRecruitmentStatus.UNKNOWN and
return UNKNOWN) when start==null && end==null && Boolean.FALSE.equals(isAlways),
update the ClubRecruitmentStatus enum to include UNKNOWN, adjust any
callers/tests that expect RECRUITING for missing period data, and ensure
calculateRecruitmentStatus still handles the existing branches (ALWAYS, BEFORE,
CLOSED, RECRUITING) unchanged otherwise.

In
`@src/main/java/com/kustacks/kuring/club/application/port/in/dto/ClubItemResult.java`:
- Around line 10-11: ClubItemResult uses String for the category and division
fields while ClubDetailResult uses the domain enums ClubCategory and
ClubDivision, causing inconsistency; change the types of the category and
division fields in ClubItemResult to ClubCategory and ClubDivision respectively,
then update any mappers (e.g., where ClubItemResult is populated) and unit tests
to pass/format the enums consistently (or add clear javadoc if the String choice
was intentional) so both DTOs represent the same domain types.

In
`@src/main/java/com/kustacks/kuring/club/application/port/out/dto/ClubDetailDto.java`:
- Around line 42-83: Remove the unused QueryDSL projection by deleting the
`@QueryProjection` annotation from the ClubDetailDto constructor declaration in
ClubDetailDto; ensure no other code relies on QClubDetailDto (the repository
ClubQueryRepositoryImpl.findClubDetailById constructs ClubDetailDto from Tuple),
and remove any unused import of com.querydsl.core.annotations.QueryProjection or
unused generated QClubDetailDto artifacts if present.

In
`@src/main/java/com/kustacks/kuring/club/application/service/ClubQueryService.java`:
- Line 97: getClubDetail 메서드의 userToken 파라미터가 사용되지 않으므로 사용자 토큰이 향후 필요하다면
ClubQueryService.getClubDetail(Long id, String userToken, Long loginUserId) 선언과
메서드 구현에 "// TODO: userToken will be used for X" 주석을 추가하고 호출부에 전달되는 값을 유지하되 사용
시점을 명시하세요; 필요 없다면 인터페이스와 구현에서 userToken 파라미터를 제거(메서드 시그니처 변경)하고, 관련 호출부들(및 테스트)을
찾아 모두 수정하여 컴파일 오류가 없도록 하세요.

In
`@src/test/java/com/kustacks/kuring/club/application/service/ClubQueryServiceTest.java`:
- Around line 43-75: The field mockReadModels in ClubQueryServiceTest is
immutable after initialization but not declared final; change its declaration to
add the final modifier (i.e., make the List<ClubReadModel> mockReadModels field
final) so the intent is explicit and the compiler enforces immutability of the
reference; locate the field by the symbol mockReadModels in the
ClubQueryServiceTest class and update its declaration accordingly.
- Around line 112-113: The test sets clubQueryPort.countClubs(...) to return 2
while searchClubs returns 3 items, which is inconsistent; update the mock return
of countClubs in the test (the when(clubQueryPort.countClubs(category,
divisionList)).thenReturn(...)) so that totalCount is at least the size of the
list returned by ClubQueryService.searchClubs (e.g., change to 3) or
alternatively reduce the mocked searchClubs result to match the count, ensuring
totalCount >= returned list size.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In
`@src/main/java/com/kustacks/kuring/club/adapter/out/persistence/ClubPersistenceAdapter.java`:
- Around line 64-99: countSubscribersByClubIds and findSubscribedClubIds
currently load full ClubSubscribe entities (risking lazy-load of club and OOM)
and aggregate in memory; change to repository-level aggregation/projection
queries that return clubId and count/exists directly. Add methods on
clubSubscribeRepository (e.g., findSubscriberCountsByClubIds(List<Long> clubIds)
with a `@Query` selecting s.club.id AS clubId, COUNT(s) AS cnt GROUP BY s.club.id
and findSubscribedClubIdsByUser(List<Long> clubIds, Long loginUserId) with a
`@Query` selecting s.club.id where s.user.loginUserId = :loginUserId) and adapt
countSubscribersByClubIds and findSubscribedClubIds to call those repo methods
and convert the projection results into Map<Long,Integer> / Map<Long,Boolean>
without loading full entities.

In
`@src/main/java/com/kustacks/kuring/club/application/service/ClubQueryService.java`:
- Around line 161-181: The cursor parsing in cursorCondition breaks when club
names contain '|' because it uses split("\\|") and then
Long.parseLong(parts[1]); update the parsing logic (not generateCursor) to
locate the last '|' via lastIndexOf('|'), extract the id as the substring after
that last delimiter and parse it to Long, and treat the prefix (name) as
everything before that last delimiter so names containing '|' are preserved and
parsing never attempts to parse non-numeric parts; adjust any null/empty checks
and exception handling accordingly in the method that currently performs
split("\\|") (cursorCondition).

In
`@src/test/java/com/kustacks/kuring/club/application/service/ClubQueryServiceTest.java`:
- Around line 200-204: 테스트 getClubs_withoutLogin에서 잘못된 메서드를 검증하고 있으므로
verify(clubQueryPort, never()).existsSubscription(...) 대신 로그인 없을 때 구독 관련 조회가
호출되지 않음을 검증하도록 변경하세요; 구체적으로 ClubQueryServiceTest의 getClubs_withoutLogin에서
verify(clubQueryPort, never()).findSubscribedClubIds(anyLong()) 를 추가하거나
existsSubscription 검증을 삭제하고 findSubscribedClubIds 호출 부재를 검증하여 비로그인 경로에서
findSubscribedClubIds가 호출되지 않음을 확인하십시오.

---

Duplicate comments:
In
`@src/main/java/com/kustacks/kuring/club/adapter/out/persistence/ClubQueryRepositoryImpl.java`:
- Line 47: The code maps Club.posterImagePath into the 4th parameter of
ClubReadModel (which is semantically iconImageUrl) causing a mismatch used later
by ClubQueryService (r.getIconImageUrl()); fix by making the mapping explicit
and correct: either pass club.getIconImageUrl() into the ClubReadModel
constructor (or add a getIconImageUrl() on Club that returns posterImagePath if
that is the intended source), or adjust the ClubReadModel constructor/parameter
order so the field names match; update ClubQueryRepositoryImpl to use the
correct symbol (iconImageUrl/getIconImageUrl) instead of posterImagePath so
ClubQueryService.r.getIconImageUrl() remains valid.

---

Nitpick comments:
In
`@src/main/java/com/kustacks/kuring/club/adapter/out/persistence/ClubQueryRepositoryImpl.java`:
- Around line 257-268: The order specifier for "recruitEndDate" duplicates the
CASE logic already implemented in recruitmentGroup(now); modify
getOrderSpecifiers to call recruitmentGroup(now) instead of inlining the
CaseBuilder: obtain the CaseBuilder/Expression from recruitmentGroup(now) (as
used by cursorCondition) and use it as statusOrder, then yield the same
OrderSpecifier array (statusOrder.asc(), club.recruitEndAt.asc().nullsLast(),
club.id.asc()); this removes duplication and ensures both cursorCondition and
getOrderSpecifiers share the same recruitmentGroup logic.

In
`@src/main/java/com/kustacks/kuring/club/application/service/ClubQueryService.java`:
- Around line 44-65: Avoid calling rootUserQueryPort.findRootUserByEmail when
email is null: in getClubs (and mirror the same change in getClubDetail) guard
the DB call with an email null check so you only call
rootUserQueryPort.findRootUserByEmail(email) when email != null, otherwise keep
loginUserId as null; locate the usage around Optional<RootUser> optionalRootUser
= rootUserQueryPort.findRootUserByEmail(email) and the mapping to loginUserId
(RootUser::getId) and modify control flow so the optional lookup is skipped for
null email and the rest of the method uses the existing loginUserId variable
unchanged.

In
`@src/test/java/com/kustacks/kuring/club/application/service/ClubQueryServiceTest.java`:
- Around line 51-52: The field mockReadModels in ClubQueryServiceTest should be
declared final since it’s a test fixture that is never reassigned; update the
declaration of mockReadModels to be private final List<ClubReadModel>
mockReadModels to reflect immutability and follow test convention, ensuring no
other code tries to reassign it.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In
`@src/main/java/com/kustacks/kuring/club/adapter/out/persistence/ClubPersistenceAdapter.java`:
- Around line 48-58: The findSubscribedClubIds method causes an N+1 due to lazy
Club loading when calling sub.getClub().getId(); update the repository method
findByClubIdInAndRootUserId (used by
ClubPersistenceAdapter.findSubscribedClubIds) to avoid lazy fetches by either:
1) adding an `@Query` that JOIN FETCHes cs.club so the Club entities are loaded in
one query, or 2) replacing the derived finder with a projection query that
directly selects the club id (e.g. SELECT cs.club.id FROM ClubSubscribe cs WHERE
cs.club.id IN :clubIds AND cs.rootUser.id = :rootUserId) and return List<Long>
to eliminate entity hydration.

In
`@src/main/java/com/kustacks/kuring/club/application/port/in/dto/ClubListCommand.java`:
- Around line 16-18: The division parsing currently maps and trims tokens but
does not remove empty entries, causing blank strings to appear for inputs like
", ,"; update the logic in ClubListCommand that builds the division list (the
stream starting from Arrays.stream(division.split(","))) to filter out empty or
blank tokens after trimming (e.g., call a filter that rejects strings where
isEmpty/isBlank returns true) before collecting toList so no empty tokens are
included.

In
`@src/main/java/com/kustacks/kuring/club/application/service/ClubNotificationService.java`:
- Around line 49-50: In findDeadlineClubs() in ClubNotificationService replace
the direct call to LocalDateTime.now() with a Clock-backed time: add a final
Clock field injected via the service constructor (or existing constructor), then
call LocalDateTime.now(clock) inside findDeadlineClubs() and pass that to
clubQueryPort.findNextDayRecruitEndClubs(...); ensure the Clock bean configured
in TimeConfig is used so behavior/tests become deterministic and consistent with
AlertService.

In `@src/main/java/com/kustacks/kuring/club/domain/ClubRecruitmentStatus.java`:
- Around line 21-36: The from method in ClubRecruitmentStatus
(ClubRecruitmentStatus.from(start,end,isAlways,now)) must guard against a null
now to avoid NPEs; add an explicit null check at the start of the method (e.g.,
if now == null) and throw a clear, consistent domain validation exception (for
example IllegalArgumentException or the project’s domain validation exception)
with a descriptive message so callers get a predictable error when now is
missing before proceeding with the existing isAlways/start/end logic.

In
`@src/main/java/com/kustacks/kuring/message/application/port/out/dto/NoticeMessageDto.java`:
- Line 53: The mapping uses String.valueOf(notice.getId()) which will produce
the literal "null" if notice.getId() is null; change the mapping to explicitly
handle a null id (e.g., set id to null or throw) instead of relying on
String.valueOf so the subsequent Assert.notNull(id, ...) at line 33 can work
correctly; locate the builder call setting .id(...) in NoticeMessageDto (the
.id(...) expression using notice.getId()) and replace it with an explicit
null-check (notice.getId() == null ? null : String.valueOf(notice.getId())) or
fail early with a clear exception.

In
`@src/main/java/com/kustacks/kuring/user/adapter/in/web/dto/UserClubSubscriptionRequest.java`:
- Line 6: The UserClubSubscriptionRequest DTO currently only uses `@NotNull` on
the id field allowing 0 or negative values; update the id validation in
UserClubSubscriptionRequest to enforce a positive lower bound (e.g., add
`@Positive` or `@Min`(1) to the Long id field) so only values > 0 are accepted, and
ensure any validation imports/annotations are added to the class.

In
`@src/main/java/com/kustacks/kuring/user/adapter/in/web/UserClubSubscriptionApiV2.java`:
- Around line 48-57: Remove the unused FCM token parameter from the controller
methods: delete the `@RequestHeader`(FCM_TOKEN_HEADER_KEY) String userToken
parameter from both addSubscription(...) and deleteSubscription(...) in
UserClubSubscriptionApiV2 (or alternatively implement its use if the FCM token
is required by business logic); update any related method signatures, callers,
and imports to match the new signatures so compilation and API consistency
remain intact.

In
`@src/main/resources/db/migration/V260217__Alter_club_subscribe_to_root_user.sql`:
- Around line 3-4: The migration currently issues an unconditional DELETE FROM
club_subscribe which risks production data loss; change the migration in
V260217__Alter_club_subscribe_to_root_user.sql to either (A) perform a safe
guard that checks for existing rows in club_subscribe (e.g., SELECT COUNT(*) and
RAISE EXCEPTION / abort the migration if count > 0) so the migration fails fast
when data exists, or (B) remove the destructive DELETE and instead implement a
separate backfill/cleanup migration that safely migrates or archives records
before deletion; locate the DELETE FROM club_subscribe statement and replace it
with the chosen guarded-check or split into a non-destructive backfill
migration.

---

Nitpick comments:
In
`@src/main/java/com/kustacks/kuring/club/adapter/out/persistence/ClubQueryRepositoryImpl.java`:
- Around line 28-37: Add the `@Transactional`(readOnly = true) annotation to the
findClubsBetweenDates method in ClubQueryRepositoryImpl so its transactional
read-only intent matches other query methods; locate the method named
findClubsBetweenDates(LocalDateTime start, LocalDateTime end) and annotate it
with `@Transactional`(readOnly = true) (ensure the import for
org.springframework.transaction.annotation.Transactional is present).

In
`@src/main/java/com/kustacks/kuring/club/adapter/out/persistence/ClubSubscribeRepository.java`:
- Around line 21-27: The repository method countSubscribersByClubIds returns
List<Object[]> which forces index-based casting in callers; replace this with a
type-safe projection by defining a projection (interface or record) such as
ClubSubscriberCount with methods getClubId() and getCount(), update the JPQL in
countSubscribersByClubIds to select cs.club.id as clubId and COUNT(cs) as count,
and change the return type to List<ClubSubscriberCount> so callers can use typed
accessors instead of Object[] indexing.

In
`@src/main/java/com/kustacks/kuring/club/application/port/in/dto/ClubDetailCommand.java`:
- Around line 3-7: ClubDetailCommand's clubId should be null-guarded at creation
to fail fast; add a canonical constructor for the record ClubDetailCommand that
checks clubId != null and throws an IllegalArgumentException (or a
domain-specific validation exception) with a clear message if null, so callers
get early validation instead of downstream errors.

In
`@src/main/java/com/kustacks/kuring/club/application/port/out/dto/ClubDetailDto.java`:
- Line 31: The ClubDetailDto class has the Boolean field isAlways declared with
package-private visibility; change its access modifier to private to match the
other DTO fields' encapsulation and maintain consistency in ClubDetailDto.
Locate the isAlways field in class ClubDetailDto and make it private, and ensure
any existing getter/setter methods (e.g., getIsAlways/isAlways or setIsAlways)
remain accessible or are added/updated accordingly so external code uses the
public accessors rather than the field directly.

In
`@src/main/java/com/kustacks/kuring/club/application/service/ClubCommandService.java`:
- Line 32: Rename the field countSubscriptionsQueryPort in ClubCommandService to
a name that reflects the port's broader role (e.g., clubSubscriptionQueryPort)
and update all call sites to use the new name: replace usages of
countSubscriptionsQueryPort.countSubscriptions(...) with
clubSubscriptionQueryPort.countSubscriptions(...) and
countSubscriptionsQueryPort.existsSubscription(...) with
clubSubscriptionQueryPort.existsSubscription(...); ensure the constructor (or
any injection point) and any imports/assignments that reference
countSubscriptionsQueryPort are updated to the new identifier so the
ClubSubscriptionQueryPort is consistently named across the class.

In
`@src/main/java/com/kustacks/kuring/worker/notification/ClubNotificationScheduler.java`:
- Around line 19-30: The scheduled task in
ClubNotificationScheduler.sendClubDeadlineNotifications can run concurrently on
multiple instances causing duplicate notifications; wrap the execution of
clubNotificationUseCase.sendDeadlineNotifications with a distributed lock or
leader-election check (e.g., use ShedLock, Redis lock, Zookeeper, or your
cluster's leader API) so only the instance holding the lock runs the send logic,
ensure the lock is acquired before calling sendDeadlineNotifications and always
released (or use a library-managed lock/annotation) and log/skipped execution
when the lock is not obtained.

In `@src/test/java/com/kustacks/kuring/acceptance/UserAcceptanceTest.java`:
- Line 65: UserAcceptanceTest currently relies on a hardcoded TEST_CLUB_ID = 1L
which breaks if seed data changes; replace this static constant by creating or
fetching a test club during test setup and use its returned ID in tests (e.g.,
add a createTestClub() helper called from the `@BeforeAll/`@BeforeEach setup that
creates a club via the same service/repository used in production and stores the
resulting ID in a non-final field like testClubId), then update all usages of
TEST_CLUB_ID (including the cases around the 537-579 area) to reference this
dynamic testClubId so tests no longer depend on brittle seeded IDs.

In `@src/test/java/com/kustacks/kuring/archunit/DependencyRuleTests.java`:
- Around line 183-185: The adapter layer rule built with
withAdaptersLayer("adapter") currently only declares
.outgoing("out.persistence"), so violations in the club.adapter.in.web boundary
are not checked; update the rule that defines withAdaptersLayer("adapter") in
DependencyRuleTests to also include the incoming boundary for the web adapter
(e.g., add an incoming("in.web") or equivalent call before/outside the outgoing
call) so that the club.adapter.in.web package is enforced alongside
out.persistence.

In
`@src/test/java/com/kustacks/kuring/club/application/service/ClubNotificationServiceTest.java`:
- Around line 72-80: Add a `@SuppressWarnings`("unchecked") to suppress the
unchecked-cast warning when casting the ReflectionTestUtils.getField result to
Map<String, String> in ClubNotificationServiceTest; specifically annotate the
smallest possible scope (the local variable declaration or the test method
containing the cast) so the cast of ReflectionTestUtils.getField(... ) to
Map<String, String> for the variable data does not emit a compiler warning while
keeping scope minimal.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In
`@src/main/java/com/kustacks/kuring/club/adapter/out/persistence/ClubQueryRepositoryImpl.java`:
- Around line 112-123: The loop in ClubQueryRepositoryImpl that iterates over
tuples and assigns String variables instagram, youtube, etc. overwrites previous
URLs for the same ClubSnsType, causing data loss; change the implementation to
collect all URLs per type (e.g., use a Map<ClubSnsType, List<String>> or three
List<String> fields) instead of single String fields, populate the lists inside
the loop when t.get(clubSns.type) and t.get(clubSns.url) are present, and then
adapt the method's return value or DTO construction to expose lists (or a
concatenated/structured representation) for instagram/youtube/etc so multiple
URLs are preserved rather than only the last one.

---

Outside diff comments:
In `@src/test/java/com/kustacks/kuring/archunit/DependencyRuleTests.java`:
- Around line 183-185: 테스트에서 Club 웹 어댑터(in.web)에 대한 incoming 검증이 빠져 있어 경계 위반을 놓칠
수 있으니 DependencyRuleTests의 해당 규칙 체인(현재
withAdaptersLayer("adapter").outgoing("out.persistence").and())에 Club의 incoming
어댑터 검증을 추가하여 .incoming("in.web") 또는 적절한 incoming 식별자(예: "in.web")를 포함하도록 수정하고,
필요하면 .and() 체인을 맞춰 Club 관련 규칙 블록에 포함시켜 테스트가 in.web으로부터의 접근을 올바르게 차단/허용하는지 검증하게
하세요.

---

Nitpick comments:
In
`@src/main/java/com/kustacks/kuring/club/adapter/out/persistence/ClubQueryRepositoryImpl.java`:
- Around line 47-70: searchClubs currently returns results without a
deterministic order; update the Querydsl chain in searchClubs (the
queryFactory.select(new QClubReadModel(...))...from(club).where(...).fetch()) to
append an orderBy clause (e.g., orderBy(club.id.asc())) so results are
consistently ordered by club.id (use club.id in the QClubReadModel selection to
locate the field).

In
`@src/main/java/com/kustacks/kuring/club/adapter/out/persistence/ClubSubscribeRepository.java`:
- Around line 21-27: Replace the raw List<Object[]> return in
ClubSubscribeRepository.countSubscribersByClubIds with a type-safe projection
(create an interface or DTO like ClubSubscriberCount with
getClubId()/getCount()) and change the `@Query` to return
List<ClubSubscriberCount>; also add a named parameter annotation
`@Param`("clubIds") to the method signature so the parameter is explicitly bound.
Locate the method countSubscribersByClubIds and update its return type and
parameter annotation, and create the projection type used by the repository.

In `@src/test/java/com/kustacks/kuring/archunit/DependencyRuleTests.java`:
- Around line 198-208: The test's DisplayName and method intent don't match the
actual ArchUnit rule: method testPackageDependencies (and its DisplayName "테스트
페키지 의존성 검증") only asserts that classes in "com.kustacks.kuring.user.domain.."
must not depend on "com.kustacks.kuring.user.application.."; rename the
DisplayName (and optionally the test method) to something like "user.domain
should not depend on user.application" or expand the rule to cover all package
dependency checks you intended; also fix the typo "페키지" if keeping a Korean name
so the label accurately reflects the assertion using the existing
resideInAPackage("com.kustacks.kuring.user.domain..") and
resideInAnyPackage("com.kustacks.kuring.user.application..") references.