기초 프로젝트: Fandom-k

📢 프로젝트 소개

• 프로젝트 인원 : 프론트엔드 3명
• 기간 : 24.10.24 - 24.11.08
• 프로젝트 : 팬들이 좋아하는 아이돌에게 투표하고 후원할 수 있는 팬덤 플랫폼
• GitHub: https://github.com/FandomKteam5/main
• 협업 : GitHub, Notion, Discord
• 기술 스택 : React, CSS

 

👩🏻‍💻 내 역할

• 이달의 차트
• 투표 모달 + 크레딧 부족 모달 
• 발표 자료 제작

 

💻 프로젝트 과정

🔗 API 연동 – Swagger 기반 백엔드 API 사용

이번 프로젝트에서는 코드잇 측에서 제공한 Swagger 문서를 기반으로 한 API를 사용했습니다. Swagger 문서는 명세가 잘 정리되어 있었기 때문에, 빠르게 데이터 구조를 파악하고 프론트엔드에서 필요한 요청을 구현할 수 있었습니다.

🧩 컴포넌트 구조와 역할 분담

프로젝트는 다음과 같은 페이지 단위로 구성되어 있었으며, 각각을 컴포넌트 중심으로 분할하여 개발했습니다.

• 메인 랜딩 페이지
• 이달의 차트
• 후원하기
• 마이페이지

컴포넌트는 재사용성과 유지보수성을 고려하여 기능 단위로 나누었으며, 각 기능별 디렉토리 구조를 통해 파일 관리를 체계화했습니다.

---

🎓 문제 및 해결 과정

문제 (1) - 이달의 차트를 여자 아이돌 / 남자 아이돌로 분류하여 인기 순으로 정렬

1. 문제

차트는 남자/여자 아이돌로 분류되어야 했고, 인기 순으로 정렬된 리스트를 제공해야 했습니다. 또한 '더 보기' 버튼을 통해 리스트를 확장하는 UX를 구현해야 했습니다.

 

2. 해결방식

currentTab 상태를 활용해 ‘여자 아이돌’과 ‘남자 아이돌’ 탭을 구성하고, 선택된 탭에 따라 API에 gender 파라미터를 전달해 해당 그룹의 데이터를 필터링해 가져왔습니다.
응답받은 아이돌 리스트는 인기 순으로 정렬하여, 사용자에게 가장 관심도가 높은 아이돌이 상단에 노출되도록 구현했습니다.

 

3. 결과

성별에 따라 차트를 분리함으로써 UX 흐름이 명확해졌고, 사용자는 본인의 관심 그룹만 선택적으로 확인할 수 있어 탐색 속도가 향상되었습니다.

또한 '더 보기' 버튼을 통해 페이지네이션 없이 목록을 이어서 로드할 수 있도록 구성했지만, 항목 수가 10개 미만인 경우에도 버튼이 비활성화되지 않고 계속 표시되는 문제가 있었습니다.

 

→ 개선 방향 : 응답받은 데이터의 길이를 기준으로 더보기 버튼 노출 여부를 제어하거나, 서버 응답 내에 'hasMore' 플래그를 활용한 조건 분기 등을 통해 보다 안정적인 로딩 로직을 설계

 

문제 (2) - '차트 투표하기' 버튼 클릭 시 투표 모달창을 표시하여 사용자 참여 유도

1. 문제

투표 버튼 클릭 시 표시되는 모달(ChartModal)과, 크레딧이 부족할 경우 표시되는 모달(LackModal)이 연속적으로 열리는 구조에서 문제가 발생했습니다. 크레딧 부족 모달을 닫으면, 그보다 먼저 열렸던 투표 모달까지 함께 닫히는 현상이 있었고, 이는 모달의 상태 관리가 명확하게 분리되어 있지 않다는 점에서 사용자 경험에 혼란을 줄 수 있는 구조였습니다.

 

2. 해결방식

기존에는 크레딧 부족 시 closeModal()을 호출해 두 모달이 모두 닫혔지만, 이 부분을 수정해 모달 상태를 분리 관리하도록 했습니다.
isOpen(투표 모달), showLackModal(크레딧 모달) 두 상태를 독립적으로 설정하고, 조건부 렌더링 또한 해당 상태에 따라 개별적으로 제어함으로써 모달 간 제어 충돌을 방지했습니다.

 

3. 결과

투표 흐름에서 모달 제어가 안정적으로 이루어져 UX 혼란이 줄어들었고, 두 모달의 닫힘 이벤트가 명확히 분리되면서 사용자 경험이 개선되었습니다.

 

→ 개선 방향 : 현재도 두 모달이 같은 DOM 트리 내에서 중첩 렌더링되고 있기 때문에, 향후에는 전역 상태로 모달을 통합 제어하는 방식을 도입

 

문제 (3) - API 요청 로직 모듈화 및 오류 처리

1. 문제

모든 API 요청 로직을 기능별로 분리해 모듈화하고, 요청마다 fetch, try-catch, response.ok 기반으로 예외 처리를 적용하여 일관된 요청 구조를 구축했습니다. 또한 커스텀 훅 useLoad를 활용해 로딩 및 에러 상태를 함께 처리할 수 있도록 구성했습니다. 이처럼 기본적인 구조화는 이루어졌지만, 이러한 구조가 프로젝트 전반으로 확장되지는 못했습니다. 다른 일부 컴포넌트에서는 여전히 try-catch 방식으로 직접 API 호출을 처리하거나, 상태 관리를 별도로 하지 않아 전체 흐름에서 로딩/에러 처리 방식의 일관성 부족과 코드 중복이 발생하는 상황이 있었습니다. 또한 에러 발생 시 사용자에게 제공되는 피드백은 대부분 alert() 또는 콘솔 로그 수준에 그쳐, UX 향상 측면에서는 아쉬움이 남았습니다.

 

2. 해결방식

API 요청 코드는 전반적으로 RankApi.js에서 일관되게 모듈화하여 관리했고, useLoad 커스텀 훅을 활용해 로딩 및 에러 상태 처리, 요청 흐름 제어를 간결하게 구성했습니다. 컴포넌트 내부의 중복되는 상태 관리 코드를 줄이고, 조건부 렌더링과 데이터 흐름도 명확하게 분리했습니다.

 

3. 결과

API 요청 흐름은 정리되어 유지보수성과 가독성이 높아졌고, 일부 컴포넌트에서는 훅을 통한 재사용도 가능해졌습니다.

 

→ 개선 방향

try-catch
장점:
- 직관적인 흐름 제어: 에러 발생 시 자동으로 catch로 흐름이 이동
- 예상치 못한 오류 포착 가능: 네트워크 에러, JSON 파싱 오류 등
- async/await과 함께 사용 시 동기적처럼 코드를 작성할 수 있어 가독성 향상
단점:
- 흐름 제어의 유연성이 부족하고, 성공/실패 외 상태를 표현하기 어려움
- catch 내부가 복잡해지기 쉬움 (에러 분기 로직 추가 필요)
- 의도된 실패도 에러로 처리되므로, 오류의 의미가 불명확해질 수 있음

Result 객체 반환 방식
장점:
- 성공/실패 여부를 명시적으로 분기 가능
- 상태 코드 기반으로 다양한 상황에 맞는 UX 피드백 처리 용이
- 에러를 예외가 아닌 데이터로 다룸으로써 로직 예측 가능
- 컴포넌트에서 try-catch 없이 로직 분기 가능 (코드 간결)
단점:
- 모든 API 요청 함수가 동일한 형식을 반환해야 하므로 코드 통일성 필요
- 에러 추적 시 try-catch보다 디버깅이 어렵게 느껴질 수 있음
- 성공/실패 분기 코드가 반복적으로 작성되어 장황해질 수 있음

커스텀 훅
장점:
- 로딩/에러/성공 상태를 하나의 훅에서 통합 관리 가능
- 반복되는 상태 관리 로직을 재사용 가능
- 컴포넌트는 UI에만 집중하고, 데이터 로직은 훅에서 분리 가능 (관심사 분리)
단점:
- 훅 설계가 복잡할 수 있음 (의존성, 내부 흐름 등 설계 고민 필요)
- 작은 프로젝트에서는 도입 비용이 클 수 있음
- 비동기 로직이 훅 내부에 숨겨져 있어 흐름 추적이 어려워질 수 있음

React Query
장점:
- 캐싱, 상태 관리, 리페칭, 에러 처리까지 자동화
- isLoading, isError, data, error 등의 상태를 즉시 활용 가능
- refetch, onSuccess, onError, onSettled 등 비동기 흐름을 세밀하게 제어 가능
- 서버 상태 관리를 전역적으로 처리 가능
단점:
- 개념이 많아 러닝 커브가 있음 (QueryKey, QueryClient 등)
- 프로젝트 초기 단계에서는 과한 설정일 수 있음
- React Query 자체 동작과 충돌 시 디버깅 어려움이 있음

Fandom-K 프로젝트에서는 요청 흐름을 단순화하고 빠르게 구현하기 위해 fetch + try-catch + response.ok 기반의 구조를 사용했습니다. 이는 단기간의 소규모 팀 프로젝트라는 상황에서 빠른 개발과 직관적인 구현에는 적합했지만, 상태별 분기 처리의 유연성 부족과 재사용 가능한 구조 설계의 어려움이라는 한계를 느꼈습니다.

특히 단순한 프로젝트일수록 요청 성공 여부 외에도 400, 409와 같은 HTTP 상태에 따라 명확한 사용자 피드백(UI 분기)이 필요하므로, 단일 catch 블록에서 모든 에러를 처리하는 방식보다는 try-catch 구조 안에 Result 객체 패턴을 함께 활용해 상태별 분기 처리를 명확히 하는 개선이 필요하다고 판단했습니다.

앞으로는 axios, 인터셉터, 커스텀 훅, Result 객체 패턴 등으로 API 요청 로직을 구조화하고 전역적으로 일관된 에러 핸들링 체계를 구성하여, UX의 정교함과 유지보수성까지 확보할 수 있는 방향으로 발전시키고자 합니다.

 

문제 (4) - 투표 후 상태 반영을 위한 window.location.reload() 처리

1. 문제

투표를 완료하더라도 차트 데이터에 즉시 반영되지 않았기 때문에 사용자 입장에서 "정상적으로 투표가 되었는지" 확인이 어려웠습니다. 이는 피드백 부족으로 인한 UX 손실로 이어졌습니다.

 

2. 해결방식

투표 성공 시 window.location.reload()를 호출하여 페이지 전체 새로고침으로 데이터 갱신했습니다.

 

3. 결과

정상 반영 여부를 즉시 확인할 수 있도록 UX 흐름을 보완했지만, 페이지 전체 리로드는 비효율적이고 사용자 경험 측면에서도 제한적인 방식이었습니다.

 

→ 개선 방향 : 상태 기반으로 투표 성공 시 차트 데이터만 refetch하여 새로고침 없이 실시간 반영되도록 개선 필요

---

🎓 배운 점/느낀 점

1. 사용자 경험(UX)에 대한 고민의 중요성

단순히 기능을 구현하는 데서 끝나는 것이 아니라, 사용자가 어떤 흐름으로 화면을 사용할지, 투표를 할 때 어떤 정보를 보고 싶은지, 실패했을 때 어떤 안내가 필요한지 등 사용자 입장에서 고민하면서 개발하는 것이 얼마나 중요한지 느꼈습니다. 특히 '투표하기' 버튼 위치, 모달 구성, 크레딧 부족 알림 등은 직접 경험하고 테스트하면서 반복적으로 개선할 수밖에 없었습니다.

 

2. 상태 관리와 구조화의 필요성

이번 프로젝트에서는 try-catch를 사용하여 API 요청 중 발생할 수 있는 오류를 처리했습니다. 하지만 다음과 같은 문제들이 반복적으로 발생했습니다. API 호출 코드가 여러 곳에 흩어져 있어 중복 로직이 많고, 유지보수가 어려웠으며, 에러가 발생했을 때 상태에 따른 UI 분기 처리가 미흡했고 로딩 중 상태와 실패 상태를 구분하지 못해 흐름이 복잡해졌습니다. 또한 alert()이나 console.log()로만 에러를 확인하는 등 피드백 방식이 단순하고 한정적이었습니다.

예외 처리는 되었지만, 각 컴포넌트마다 개별적으로 API 호출과 에러 처리를 하다 보니 전체적인 코드 일관성이 부족했고, 특히 네트워크 지연이나 백엔드 오류가 발생했을 때 문제 해결이 어렵고 디버깅이 반복적으로 필요했습니다.

이러한 문제를 해결하기 위해 API 요청 로직을 기능 단위로 모듈화하여 /services/RankApi.js 파일에 따로 분리해 관리했습니다. 각 요청 함수는 fetch 기반으로 구성하고, response.ok를 통해 HTTP 상태를 체크한 뒤, try-catch로 예외를 처리하고 response.json()으로 파싱하는 구조로 통일했습니다. 이처럼 API 요청 코드를 한 곳에 모아두자 컴포넌트에서는 간단하게 함수만 호출하는 방식으로 구현할 수 있게 되었고, 코드의 재사용성과 유지보수성이 크게 향상되었습니다.

또한, 커스텀 훅을 사용한 경험은 제한적이었으며, 프로젝트 전체에서 공통적으로 사용한 커스텀 훅은 반응형 처리를 위한 useWindowSize 하나뿐이었습니다. 이 훅은 뷰포트 크기에 따라 페이지 상태(MOBILE, TABLET, DESKTOP)를 구분하는 용도로 사용되었으며, API 호출이나 상태 관리를 위한 구조화된 커스텀 훅은 도입하지 못했습니다.

이 경험을 통해 API 요청 흐름을 컴포넌트 바깥으로 분리하고 공통화하는 구조의 중요성을 크게 느꼈습니다. 다음 프로젝트에서는 API 요청을 axios 기반으로 전환하고 요청/응답 인터셉터를 활용하거나, 커스텀 훅을 통해 isLoading, error 상태를 한 곳에서 관리할 수 있는 구조를 설계해보고자 합니다. 이러한 구조화는 코드 개선을 넘어서 전체 애플리케이션의 안정성과 협업 효율성까지 높여줄 수 있는 중요한 개발 습관임을 체감했습니다.

 

3. 협업의 어려움과 책임감

기획 당시 역할을 나눠 진행했지만, 중도에 팀원이 빠지는 상황이 발생하면서 기대만큼 일이 진행되지 않는 상황에서도 유연하게 대처하는 능력의 중요성을 체감했습니다. 비록 직접 구현하지 않더라도, 팀원이 맡은 기능이 어떻게 동작하는지 구조를 이해하고 있어야 비상시에 빠르게 인계받고 대응할 수 있다는 걸 느꼈습니다.

---

😢 아쉬운 점

1. 비즈니스 로직과 API 구조에 대한 사전 이해 부족

초기에는 Swagger 문서를 기반으로 기능을 구현했지만, 백엔드 API의 사용 방식이나 응답 구조를 명확히 이해하지 못한 채 개발을 시작해 초반에 시간이 많이 소요되었습니다. 앞으로는 개발 전 API 명세와 흐름에 대해 좀 더 깊게 이해하고 시작하는 습관이 필요하다고 느꼈습니다.

 

2. 투표 결과 실시간 반영 미흡

투표 후 차트에 반영되는 내용이 즉시 확인되지 않아, 페이지 전체를 새로고침하는 방식(window.location.reload)으로 처리했습니다. 이는 UX와 성능 모두에서 한계가 있는 방식이었고, 처음부터 상태 기반 리렌더링 구조로 설계했더라면 더 자연스럽고 효율적인 사용자 경험을 제공할 수 있었을 것입니다.

 

3. 테스트 및 QA가 부족했던 점

프로젝트 후반부에는 일정에 쫓겨 충분한 QA나 사용자 테스트를 거치지 못하고 배포된 부분이 있었습니다. 기능적으로는 구현되었지만, 다양한 브라우저나 모바일 화면에서의 테스트 부족으로 인해 UI가 깨지는 등의 문제가 있었고, 이후 수정이 필요가 있다고 느꼈습니다.
다음 프로젝트에서는 테스트 계획도 개발 초기부터 같이 세우고, 여유를 확보하는 방향으로 관리해야겠다고 느꼈습니다.

 

4. 커밋 및 코드 리뷰 습관 부족

첫 팀 프로젝트이다 보니, 커밋 메시지 관리나 PR(PR 요청)을 주기적으로 올리는 습관이 제대로 잡혀 있지 않았습니다. 각자 맡은 기능 구현에 집중하느라 코드 리뷰 문화도 잘 정착되지 못했고, 그 결과 코드 전반에 대한 팀원 간의 이해도가 부족해지는 상황도 발생했습니다.

특히 저는 작업에 몰입하느라 PR을 계획한 만큼 자주 올리지 못했고, 팀원들과 진행 상황을 충분히 공유하지 못한 점이 아쉬움으로 남았습니다. 앞으로는 작업을 일정한 단위로 나누어 PR을 더 자주 올리고, 주기적으로 진행 상황을 공유하는 습관을 들이려 합니다. 더 나은 협업을 위해 코드 리뷰 참여도 의식적으로 챙겨야 한다는 필요성을 강하게 느꼈습니다.

 

5. 성과 전달력 부족

다른 팀들의 발표를 보며, 단순히 기능을 잘 구현하는 것뿐만 아니라 과정과 문제 해결의 흐름을 명확하게 설명하고, 결과로 도출한 인사이트를 전달하는 능력도 중요하다는 걸 실감했습니다. 저희 팀은 기술적 구현에 치중하다 보니, 진행 과정이나 성과를 정리해 발표하는 데에는 다소 부족한 면이 있었습니다. 다음 프로젝트에서는 구현과정뿐만 아니라, 왜 이런 결정을 내렸는지, 어떤 문제를 어떻게 풀었는지를 정리하고 효과적으로 발표하는 훈련을 병행할 예정입니다.

 

6. 공통 컴포넌트 설계 부족

프로젝트를 진행하며 UI 요소나 기능이 중복되는 경우가 있었지만, 공통 컴포넌트로 추상화하지 않고 각자 개별적으로 구현하는 일이 많았습니다.

예를 들어 버튼, 카드, 리스트 항목 등은 구조와 스타일이 유사했지만 팀원마다 각자 새롭게 컴포넌트를 만들면서 중복 코드가 발생했고, 스타일도 일관되지 않았습니다. 이로 인해 수정이 필요한 경우 모든 컴포넌트를 개별적으로 고쳐야 하는 비효율과 UI 일관성 유지가 어렵다는 문제가 발생했습니다.

 

7. 팀 회의 참여 부족으로 인한 협업 어려움

프로젝트 진행 중 정기적인 팀 회의에 대부분의 팀원들이 잘 참여하지 않았고, 실제 회의에는 팀장과 저만 참석하는 경우가 많았습니다. 회의 참여도가 낮다 보니 기획이나 진행 상황을 함께 정리하고 공유하기가 어려웠고, 결정 또한 원활하게 이루어지지 않는 경우가 많았습니다.

특히, 중도에 한 명이 팀에서 하차했는데, 해당 팀원이 후반부에 하차 했음에도 어디까지 구현했는지 전혀 파악할 수 없는 상태였고, 다른 팀원도 프로젝트 후반까지 회의에 거의 참여하지 않아 코어데이(공동 작업일)에도 모습을 보이지 않았습니다. 이로 인해 최종적으로 작업물을 머지하는 과정에서 충돌을 방지하고 일관된 코드 흐름을 유지하는 데 어려움이 있었고, 협업으로서의 완성도를 높이는 데에도 제약이 있었습니다.

다음 협업 프로젝트에서는 초기부터 회의 참여율 관리와 역할 분담 명확화, 그리고 주기적인 작업 공유를 습관화하여 팀 전체가 하나의 방향으로 움직일 수 있도록 체계를 갖추는 데 더 신경 쓰고자 합니다.