IT의 IT 블로그

사이드 프로젝트 | NBA Game Picker (3) - 경기 목록과 상세 페이지 설계 본문

카테고리 없음

사이드 프로젝트 | NBA Game Picker (3) - 경기 목록과 상세 페이지 설계

IT의 IT 블로그 2026. 5. 8. 14:54

안녕하세요.

 

지난 글에서는
NBA Game Picker 프로젝트를 왜 만들었고,
어떤 방향으로 설계했는지 정리했고,

 

이후에는
홈 화면을 어떻게 구조화하고 컴포넌트로 분리했는지 정리했습니다.

 

이번 글에서는 그다음 단계로 진행한

경기 목록 페이지(/games)와 경기 상세 페이지(/games/[gameId]) 구현 과정

을 정리해보려고 합니다.

 

홈 화면이 오늘 볼 만한 경기를 빠르게 보여주는 역할이었다면,
이번에 만든 두 페이지는

 

추천 → 비교 → 상세 확인

으로 이어지는 흐름을 만드는 작업이었습니다.

1. 홈 화면 다음에 필요했던 것

홈 화면만 있을 때도
오늘 경기, 추천 경기, 팀 순위, 득점 리더처럼
핵심 정보는 어느 정도 한 화면에서 볼 수 있었습니다.

 

하지만 실제로 서비스를 사용한다고 생각해보면
아쉬운 점이 분명히 있었습니다.

 

예를 들면 이런 흐름입니다.

  • 오늘 경기가 여러 개 있을 때 전체를 보고 싶다
  • 추천 점수가 높은 경기들을 빠르게 비교하고 싶다
  • 특정 경기 하나를 더 자세히 보고 싶다
  • 왜 이 경기가 추천 경기인지 근거를 확인하고 싶다

즉, 홈 화면은 요약과 진입 역할에는 적합했지만
전체를 비교하거나 하나를 깊게 확인하는 흐름까지는 부족했습니다.

 

그래서 다음 단계로

  • /games → 전체 경기 목록
  • /games/[gameId] → 경기 상세 정보

이 두 페이지를 추가하게 되었습니다.

2. 각 페이지의 역할 정리

이번 작업에서는 먼저
각 페이지가 어떤 역할을 가지는지부터 정리했습니다.

 

홈 (/)

오늘 가장 볼 만한 경기와 핵심 정보 요약

경기 목록 (/games)

오늘 경기 전체를 추천 점수 기준으로 빠르게 비교

경기 상세 (/games/[gameId])

선택한 경기를 왜 봐야 하는지 더 자세히 설명

이렇게 나누고 나니
페이지마다 어떤 정보를 보여줘야 하는지 기준이 분명해졌습니다.

 

특히 상세 페이지는
단순히 경기 정보를 다시 보여주는 것이 아니라,

 

“추천의 근거를 납득시키는 페이지”

가 되어야 한다고 생각했습니다.

3. 경기 목록 페이지에서 정리한 것

/games 페이지는
그냥 홈 화면의 리스트를 크게 늘려놓는 느낌으로 만들고 싶지는 않았습니다.

이 페이지에서 중요하게 본 것은

전체 경기를 빠르게 훑고 우선순위를 정할 수 있느냐

였습니다.

 

그래서 목록 페이지에서는 아래 정보가 바로 보이도록 구성했습니다.

  • 경기 시간
  • 팀 매치업
  • Watchability Score

목록 페이지의 목적은
깊게 읽는 것이 아니라 빠르게 비교하는 것이기 때문에,
정보량을 과하게 넣기보다 핵심만 먼저 보이도록 설계했습니다.

 

또 홈에서 사용하던 경기 데이터 구조를 그대로 재사용하면서
홈 → 목록 흐름도 자연스럽게 이어지도록 했습니다.

 

즉, 홈에서는 일부 경기만 요약해서 보여주고
/games에서는 그 데이터를 전체 목록 형태로 확장하는 방식입니다.

4. 경기 상세 페이지에서 중요했던 부분

상세 페이지는 목록보다 더 중요하다고 생각했습니다.

 

이 프로젝트의 핵심은
단순히 경기 정보를 보여주는 것이 아니라
**“오늘 어떤 경기를 보면 좋을지 추천하는 것”**이기 때문입니다.

 

그래서 상세 페이지에서는
경기 시간이나 팀 이름만 보여주는 것이 아니라
추천 근거를 설명할 수 있는 정보가 필요했습니다.

 

현재 상세 페이지에는 다음과 같은 내용을 넣었습니다.

  • 경기 시간
  • away / home 팀
  • Watchability Score
  • 추천 이유
  • 최근 5경기 비교
  • 평균 득점
  • 평균 실점
  • 시즌 승률
  • 최근 맞대결

즉, 이 페이지는
“경기 정보를 보여주는 화면”이면서 동시에

 

“왜 이 경기가 추천되는지 설명하는 화면”

이 되도록 구성했습니다.

 

홈에서 사용자가 가질 수 있는 질문은 보통 이런 형태입니다.

  • 왜 이 경기가 높은 점수지?
  • 단순히 인기 팀 경기라서 추천된 건가?
  • 실제로 접전 가능성이 높은가?
  • 최근 흐름이 좋은 팀들인가?

상세 페이지는 이런 질문에 답해주는 구조를 목표로 했습니다.

5. App Router 기준으로 연결하기

이번 작업에서 기술적으로 가장 중요했던 부분 중 하나는
Next.js App Router 기준으로 라우팅 구조를 정리한 것이었습니다.

 

현재 페이지 구조는 다음과 같습니다.

src/app
├─page.tsx
└─games
├─page.tsx
└─[gameId]
└─page.tsx
 

여기서

  • src/app/games/page.tsx → /games
  • src/app/games/[gameId]/page.tsx → /games/:gameId

역할을 합니다.

 

처음에는 [gameId] 폴더를 사용하는 방식이 조금 낯설었지만,
정리하고 나니 오히려 페이지 역할이 더 명확하게 느껴졌습니다.

 

특히 gameId를 기준으로 상세 데이터를 연결하는 흐름이 생기면서
목록 → 상세 이동 구조가 자연스럽게 이어졌습니다.

6. 상세 데이터는 mock 기반으로 구성

현재 단계에서는 아직 실제 API를 연결하지 않고
mock 데이터 기반으로 상세 페이지를 구성했습니다.

 

이렇게 진행한 이유는 이전과 같습니다.

  • UI 구조를 먼저 잡기 위해
  • 상세 페이지에서 어떤 데이터가 필요한지 먼저 정리하기 위해
  • 실제 API 형태와 무관하게 화면 흐름을 먼저 검증하기 위해

현재는 gameDetailMap 형태로 상세 데이터를 관리하고 있습니다.

 

예를 들어

  • lakers-warriors
  • celtics-bucks

같은 경기 id를 기준으로
각 경기의 상세 데이터를 연결하는 방식입니다.

 

이 과정에서 중요했던 점은

홈 데이터, 목록 데이터, 상세 데이터의 id를 일관되게 맞추는 것

이었습니다.

 

이 부분이 정리되자
홈에서 누른 경기 카드와 목록에서 누른 경기 카드가
같은 상세 페이지로 자연스럽게 연결될 수 있었습니다.

7. 구현하면서 느낀 점

1) 목록 페이지와 상세 페이지는 역할이 다르다

처음에는 둘 다 경기 데이터를 보여주는 페이지라고 생각했지만,
직접 만들어보니 성격이 확실히 달랐습니다.

  • 목록 페이지 → 빠르게 비교
  • 상세 페이지 → 추천 근거 설명

즉, 같은 데이터라도
어떤 페이지에서 보여주느냐에 따라 배치 방식이 달라져야 했습니다.

2) 추천 근거를 설명하는 상세 화면

홈 화면에서 추천 경기를 강조하는 것만으로는
추천 서비스라고 말하기 어렵다고 느꼈습니다.

 

진짜 중요한 것은

상세 페이지에서 그 추천을 어떻게 설명하느냐였습니다.

 

그래서 이번 작업은
단순히 페이지를 추가한 것이 아니라

추천 중심 서비스 구조를 한 단계 더 확장한 작업

이라고 생각합니다.

3) 목록과 상세를 연결하는 id 기준

지금은 아직 실제 API를 연결한 단계가 아니라서,
복잡한 식별자 체계를 만드는 것보다

 

서로 연결되는 데이터끼리 id를 일치시키는 것

이 훨씬 중요했습니다.

 

현재는 간단한 문자열 id를 사용하고 있지만,
이후 실제 API를 연결하게 되면
외부 경기 id를 기준으로 더 안정적인 구조로 확장할 계획입니다.

8. 현재까지의 흐름

지금까지 정리된 흐름은 다음과 같습니다.

1단계

홈 화면 대시보드 구성

2단계

홈 화면 구조 분리 및 컴포넌트화

3단계

경기 목록 페이지 추가

4단계

경기 상세 페이지 추가

즉, 이제는 단순히 홈 화면 하나만 있는 프로젝트가 아니라

홈 → 목록 → 상세

로 이어지는 기본 흐름이 갖춰진 상태입니다.

9. 현재 기준 프로젝트 구조 일부

이번 작업 이후 기준으로 보면
프로젝트는 대략 다음과 같은 흐름으로 확장되고 있습니다.

src
├─app
│ ├─page.tsx
│ └─games
│ ├─page.tsx
│ └─[gameId]
│ └─page.tsx
│
└─features
└─nba
├─components
├─data
│ ├─home
│ └─games
├─lib
└─types
 

이 구조를 통해

  • 홈에 필요한 데이터
  • 목록에 필요한 데이터
  • 상세에 필요한 데이터

를 역할 기준으로 계속 확장할 수 있게 되었습니다.

10. 다음 단계

현재까지 홈, 목록, 상세까지 연결하면서
서비스의 기본 흐름은 어느 정도 정리되었습니다.

 

다음 단계에서는

  • Watchability Score를 설명하는 /about-score 페이지
  • 상세 페이지 데이터 확장
  • favorites 기능
  • 상태 관리 구조 정리
  • 실제 API 연결 준비

등으로 확장해보려고 합니다.

 

특히 다음 단계에서는
단순히 페이지를 더 만드는 것이 아니라,

 

추천 점수의 기준을 더 설득력 있게 보여주는 방향

으로 발전시키는 것이 핵심이라고 생각합니다.

11. 마무리

이번 작업을 통해 느낀 점은
홈 화면만으로는 서비스가 완성되지 않는다는 것이었습니다.

 

사용자가 실제로 탐색하고 선택하려면

  • 전체를 비교할 수 있는 목록 페이지
  • 선택 근거를 확인할 수 있는 상세 페이지

가 반드시 필요했습니다.

 

결국 추천 서비스의 핵심은

정보를 많이 보여주는 것이 아니라,

 

사용자가 선택할 수 있게 흐름을 설계하는 것

이라는 점을 다시 느꼈습니다.