Feature/#9 10 대회 투표 현황 조회 api 개발 by pykido · Pull Request #74 · PNUops/opus-backend

pykido · 2026-02-12T04:12:57Z

🔥 연관된 이슈

close: #9
close: #10

📜 작업 내용

대회 투표 랭킹 조회 API를 구현하였습니다.
|

팀별 투표 수 집계 및 Dense Ranking을 적용하였습ㄴ비다.
투표 0개 팀을 LEFT JOIN을 활용하여 포함시켰습니다.

대회 투표 통계 조회 API를 구현하였습니다.

총 투표 수, 투표자 수, 1인당 평균 투표 수를 반환하도록 구현하였습니다.

💬 리뷰 요구사항

대회 투표 랭킹 조회 API 관련 내용

TeamRepository의 랭킹 쿼리가 다소 복잡합니다. Team 기준 시작 + LEFT JOIN TeamVote + LEFT JOIN ContestTrack으로 투표 0개 팀과 trackName까지 한방에 가져오도록 했습니다.
쿼리를 이렇게 한 이유는 서비스 코드의 가독성을 위해서입니다. 쿼리에서 trackName까지 해결하면 서비스에서 ContestTrackRepository 주입 없이 dense ranking 로직만 담당하고자 하였습니다.
처음에는 Object[]로 받았는데 인덱스 캐스팅이 불안정해서, JPQL DTO 매핑 방식으로 변경했습니다. Projection 인터페이스 도입도 고려했지만 파일이 하나 더 느는 것 대비 이점이 크지 않은 듯하여 현재 방식을 선택했습니다.
이 트레이드오프가 적절한지 혹은 다른 방법이 있으시다면 자유롭게 의견 부탁드립니다-!

✨ 기타

다들 화이팅입니다!

Copilot

Pull request overview

관리자 페이지에서 대회 투표 현황(랭킹/집계) 을 조회할 수 있도록 API/쿼리/응답 DTO 및 문서를 추가한 PR입니다.

Changes:

대회 투표 랭킹 조회 API (GET /contests/{contestId}/ranking) 및 Dense Ranking 적용
대회 투표 집계 조회 API (GET /contests/{contestId}/votes/statistics) 추가 (총 투표 수/투표자 수/평균)
관련 DTO/테스트/REST Docs/Asciidoc 문서 보강

Reviewed changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
src/main/java/com/opus/opus/modules/team/application/TeamQueryService.java	랭킹/집계 조회 서비스 로직 및 dense ranking 적용 추가
src/main/java/com/opus/opus/modules/team/domain/dao/TeamRepository.java	대회별 팀 투표수 집계 쿼리(LEFT JOIN) 추가
src/main/java/com/opus/opus/modules/team/domain/dao/TeamVoteRepository.java	대회별 총 투표수/투표자수 집계 쿼리 추가
src/main/java/com/opus/opus/modules/contest/api/ContestController.java	관리자용 랭킹/집계 조회 엔드포인트 추가
src/main/java/com/opus/opus/modules/contest/application/dto/response/ContestRankingResponse.java	랭킹 응답 DTO 신규 추가
src/main/java/com/opus/opus/modules/contest/application/dto/response/ContestVoteStatisticsResponse.java	집계 응답 DTO 신규 추가
src/test/java/com/opus/opus/team/application/TeamQueryServiceTest.java	랭킹/집계 통합 테스트 케이스 추가
src/test/java/com/opus/opus/restdocs/docs/ContestApiDocsTest.java	랭킹/집계 API REST Docs 스니펫 생성 테스트 추가
src/main/java/com/opus/opus/docs/asciidoc/contest.adoc	랭킹/집계 API 문서 섹션 추가

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2026-02-12T04:17:29Z

src/main/java/com/opus/opus/modules/team/domain/dao/TeamVoteRepository.java

+    @Query("SELECT COUNT(vote) " +
+            "FROM TeamVote vote " +
+            "JOIN vote.team team " +
+            "WHERE team.contestId = :contestId AND vote.isVoted = true")
+    long countTotalVotesByContest(Long contestId);


집계 쿼리가 isVoted=true인 모든 레코드를 카운트하고 있어, (대회 투표기간이 변경될 수 있는 구조라면) 현재 설정된 투표기간 밖에서 생성된 투표까지 포함될 수 있습니다. 이 API가 '투표 기간에 행해진 투표만 집계' 요구사항을 만족해야 한다면 vote.createdAt을 contest.voteStartAt~voteEndAt 범위로 제한하도록 Contest 조인/기간 조건을 추가하는 방향을 검토해주세요.

투표 생성 시점에 이미 기간 검증을 하니 집계 시 기간 필터는 불필요하다고 느꼈는데 (쿼리가 불필요하게 복잡해지므로), 방어적으로 기간 조건을 추가해야할지가 고민이네요...

그런데 투표 기간이 아니라면 투표가 불가능 할 텐데(UI적으로 불가로 알고 있어요), 이 부분을 고려해야 하나 생각이 드네요
집계 쿼리에 내용이 추가되면 그 만큼 성능적인 부분에서 문제가 있을테니까요

src/main/java/com/opus/opus/modules/team/domain/dao/TeamRepository.java

src/main/java/com/opus/opus/modules/team/domain/dao/TeamVoteRepository.java

src/test/java/com/opus/opus/team/application/TeamQueryServiceTest.java

Copilot · 2026-02-12T04:17:30Z

src/main/java/com/opus/opus/modules/team/domain/dao/TeamRepository.java

+    @Query("SELECT new com.opus.opus.modules.contest.application.dto.response.ContestRankingResponse(" +
+            "team.id, team.teamName, team.projectName, track.trackName, COUNT(vote.id)) " +
+            "FROM Team team " +
+            "LEFT JOIN TeamVote vote ON vote.team = team AND vote.isVoted = true " +
+            "LEFT JOIN ContestTrack track ON team.trackId = track.id " +


Repository 레이어(dao)가 ...application.dto.response.ContestRankingResponse(컨트롤러 응답 DTO)에 직접 의존하고 있어 계층/모듈 결합도가 커집니다. 이 쿼리 전용 Projection 인터페이스/DTO를 dao 패키지에 두거나, repository는 필요한 원시 값만 반환하고 service에서 응답 DTO로 매핑하는 방식으로 분리하는 것이 유지보수에 더 안전합니다.

dto가 상위 계층인 application에 의존하고 있어서 문제가 될 수 있을 거 같습니다!
Projection을 dao 패키지에 둔다면 계층 분리 측면에서 이득일 수 있겠네요!
Repository(dao 계층) → TeamRankingProjection(dao 계층) ← Service(application 계층)

1. 기존 방식 (Repository에서 응답 DTO 직접 의존)

TeamRepository.java

@Query("SELECT new com.opus.opus.modules.contest.application.dto.response.ContestRankingResponse(" + "team.id, team.teamName, team.projectName, track.trackName, COUNT(vote.id)) " + "FROM Team team ...") List<ContestRankingResponse> findTeamRankingByContestId(Long contestId);

2. 변경 후 방식 (Projection 인터페이스로 계층 분리)

TeamRankingProjection.java (dao 패키지 내에 둠)

public interface TeamRankingProjection { Long getTeamId(); String getTeamName(); String getProjectName(); String getTrackName(); Long getVoteCount(); }

TeamRepository.java

@Query("SELECT team.id AS teamId, team.teamName AS teamName, " + "team.projectName AS projectName, track.trackName AS trackName, " + "COUNT(vote.id) AS voteCount " + "FROM Team team " + "LEFT JOIN TeamVote vote ON vote.team = team AND vote.isVoted = true " + "LEFT JOIN ContestTrack track ON team.trackId = track.id " + "WHERE team.contestId = :contestId " + "GROUP BY team.id, team.teamName, team.projectName, track.trackName " + "ORDER BY COUNT(vote.id) DESC") List<TeamRankingProjection> findTeamRankingByContestId(Long contestId);

TeamQueryService.java

public List<ContestRankingResponse> getTeamRanking(Long contestId) { contestConvenience.getValidateExistContest(contestId); List<TeamRankingProjection> votesPerTeam = teamRepository.findTeamRankingByContestId(contestId); return applyDenseRanking(votesPerTeam); }

위 방식에 대해 다른 분들의 의견이 궁금합니다!

말씀하신대로 dto매핑을 사용하면 상위 패키지를 의존하는것 같습니다.

projection을 사용거나

queryservice에서는 상위 패키지 의존을 허용하거나

레포지토리용 dto를 새로 정의하고 ContestRankingResponse로 매핑하는 방법이 있을것 같습니다.

현재는 랭킹을 계산하면서 응답 객체를 한번 더 만들기 때문에 3번을 사용해도 괜찮지 않을까 생각합니다.

저도 성재님 의견에서는 3번이 더 좋을 것 같습니다

그런데 저는 DAO에서 Response를 반환하게 된 이유, 고려했던 다른 방안이 궁금합니다!
Repository용 DTO가 생긴다면 저희 프로젝트의 하나의 고려사항이 더 생긴다는 의미인데, 해당 결론이 날 때까지의 과정이나 해당 DTO가 위치할 곳 등 최적화를 위해 고민했던 부분들이 알고 싶어요!

제가 고려했던 방안은 다음과 같습니다.

Projection 인터페이스 사용

DTO를 정의하여 응답값을 한 번에 생성

QueryDSL 사용

통계 API와 같이 다소 복잡한 쿼리를 사용하는 부분에서 가독성과 효율을 챙기는 방법이 무엇인지 고민하였습니다. QueryDSL은 작업 사이즈가 커지고, 최근 보안 이슈로 관리 중단되어 장기적 의존이 부담스러워 제외하였습니다. 1번과 2번 중에서는, Repository에서 application 계층의 응답 DTO를 직접 반환하는 것이 계층 간 결합을 만든다는 점이 걸렸지만, Projection 인터페이스도 파일이 하나 더 느는 것 대비 이점이 크지 않다고 판단하여 2번을 선택했었습니다.

하지만 성재님 의견처럼 Repository용 DTO를 dao 패키지에 별도 정의하고, 서비스에서 응답 DTO로 매핑하는 방식이 계층 분리도 지키면서 가장 깔끔할 것 같습니다. 해당 방향으로 수정해보겠습니다!

# Conflicts: # src/main/java/com/opus/opus/modules/contest/api/ContestController.java # src/main/java/com/opus/opus/modules/team/domain/dao/TeamRepository.java # src/test/java/com/opus/opus/restdocs/docs/ContestApiDocsTest.java

sjmoon00

수고하셨습니다~
코드를 이해하기 쉽게 작성하신것 같아요!

src/main/java/com/opus/opus/modules/team/domain/dao/TeamRepository.java

src/main/java/com/opus/opus/modules/team/application/TeamQueryService.java

JJimini

수고하셨습니다! comment 확인부탁드려요~!

src/main/java/com/opus/opus/modules/team/application/TeamQueryService.java

JJimini · 2026-02-16T13:19:38Z

src/main/java/com/opus/opus/modules/team/application/TeamQueryService.java

+
+    private List<ContestRankingResponse> applyDenseRanking(List<ContestRankingResponse> votesPerTeam) {


Dense Ranking을 사용했다고 하셨는데, 기획적으로 논의가 완료된 부분인지 궁금합니다!
개인적으로는 Ranking이 좀 더 일반적으로 사용되지 않나 생각이 들어서요~!

저희 MVP 단계부터 Dense Ranking을 사용하기로 기획 논의가 완료된 상태입니다!

다만 말씀하신 것처럼 일반적인 대회 순위에서는 Standard Ranking(1224 방식)이 더 보편적일 수 있을 것 같아요.
이 부분은 회의 때 한번 논의해보면 좋을 것 같습니다!

src/test/java/com/opus/opus/restdocs/docs/ContestApiDocsTest.java

JJimini

수고하셨습니다~

pykido added 9 commits February 12, 2026 00:16

feat : 투표 랭킹 조회 API 구현 완료

64ad72c

feat : 투표 집계 API 구현 완료

b5fd39f

refactor : 변수명 간단 수정

e57d1a7

test : 서비스 테스트 코드 작성 완료

e538822

test : 서비스 테스트 코드 작성 완료 - 2

80e67e1

refactor : 쿼리문 바꾸기

6e3283f

test : 테스트 코드 작성 완료

31d2759

test : restdocs 테스트 코드 작성 완료

bbbe412

refactor : 메서드 위치 변경

2ab31b8

pykido requested review from JJimini, Copilot, myeowon and sjmoon00 February 12, 2026 04:12

pykido self-assigned this Feb 12, 2026

pykido added the ⭐️ 기능 구현 새로운 기능을 구현 label Feb 12, 2026

Copilot started reviewing on behalf of pykido February 12, 2026 04:13 View session

Copilot AI reviewed Feb 12, 2026

View reviewed changes

pykido added 4 commits February 12, 2026 13:22

refactor : 사용하지 않는 파일 정리

621b455

refactor : 사용하지 않는 파일 정리

a264c55

refactor : final 붙이기

ae03f17

sjmoon00 approved these changes Feb 16, 2026

View reviewed changes

JJimini reviewed Feb 16, 2026

View reviewed changes

pykido added 6 commits February 17, 2026 18:00

refactor : Repository용 DTO 생성 후 매핑

88ed7b1

refactor : 2차 정렬 조건 추가

0447891

test : 2차 정렬 조건 테스트 추가

db217ff

test : dao용 dto 생성 후 리팩토링 (2차)

c616ea5

refactor : private static 메서드화시키기

e9c18d3

refactor : adoc에 실패 케이스 추가

b4589d1

pykido mentioned this pull request Feb 17, 2026

Feature/#8 프로젝트 등록현황 조회 api 구현 #75

Open

JJimini approved these changes Feb 18, 2026

View reviewed changes


		private List<ContestRankingResponse> applyDenseRanking(List<ContestRankingResponse> votesPerTeam) {

Conversation

pykido commented Feb 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🔥 연관된 이슈

📜 작업 내용

💬 리뷰 요구사항

✨ 기타

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Copilot AI Feb 12, 2026

Choose a reason for hiding this comment

Uh oh!

pykido Feb 12, 2026

Choose a reason for hiding this comment

Uh oh!

JJimini Feb 16, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Copilot AI Feb 12, 2026

Choose a reason for hiding this comment

Uh oh!

pykido Feb 12, 2026

Choose a reason for hiding this comment

1. 기존 방식 (Repository에서 응답 DTO 직접 의존)

2. 변경 후 방식 (Projection 인터페이스로 계층 분리)

Uh oh!

sjmoon00 Feb 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

JJimini Feb 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pykido Feb 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sjmoon00 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

JJimini left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

JJimini Feb 16, 2026

Choose a reason for hiding this comment

Uh oh!

pykido Feb 17, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

JJimini left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Comments

pykido commented Feb 12, 2026 •

edited

Loading

sjmoon00 Feb 16, 2026 •

edited

Loading

JJimini Feb 16, 2026 •

edited

Loading

pykido Feb 17, 2026 •

edited

Loading