프로젝트 핵심 경험 ‐ 김다영(FE)

안녕하세요, Q-Lab 프로젝트의 유일한 프론트엔드 개발자 김다영입니다!
저는 이 글에서 프로젝트에서 잡았던 핵심 목표와 실제로 얻은 경험에 대해 소개해드리고,
각 주차별 상세 경험에 대해 소개하고자 합니다.

---

프로젝트 핵심 목표

리액트를 사용한 프로젝트 완성 경험

제가 프로젝트를 시작하기 전에 잡은 핵심 목표는 리액트를 사용한 프로젝트 완성 경험, 단 한가지였습니다.
어찌보면 프로젝트 경험 자체가 목표라고 생각해도 무방할 정도로 단순 명료한 목표입니다.
제가 이렇게 단순한 목표를 설정한 이유는 다름아닌 저의 배경 때문입니다.

• 비전공자 : 디자인과 졸업, 게임 기획자 경력 1년
• 개발 경험 x : 자바스크립트 3개월 학습, 네이버 부트캠프.

개발자로서의 프로젝트 경험도 없었고, 리액트 사용 경험도 없었기에
저는 이 두가지 경험만 얻어가도 이번 프로젝트는 성공적이라고 생각했습니다.
실제로 제가 프로젝트를 끝마치고 최종적으로 배운 것은 아래와 같습니다.

프로젝트를 통해 배운 것

프로젝트

• 개발자로서 프로젝트를 어떻게 진행하는지
• 프론트엔드 개발자가 백엔드 개발자랑 어떻게 협업을 하는지
• 스프린트를 어떻게 관리하고, 이슈를 어떻게 배정하는지
• 플레닝 포커를 통한 작업에 대한 메타인지
• 깃허브를 통해 어떻게 협업하는지
• api 설계는 어떤 방식으로 하는지

리액트

• 서버상태와 로컬상태에 대한 이해
• 리액트 훅에 대한 이해: useState, useEffect, useRef
• 상태에 대한 이해: rerendering, props drilling, State Lifting
• 관심사 분리에 대한 이해
• 컴포넌트 설계에 대한 이해

---

프로젝트 경험 요약

5주간 진행된 프로젝트를 요약하자면 아래와 같습니다. 상세한 경험은 각 주차별 페이지에서 확인할 수 있습니다.

주차	경험	상세 페이지
1주차	프로젝트 기획 , 일정 수립, 디자인, 협업 전략 수립, 기술 스텍 선정	Week1
2주차	api 설계 , 기술 스택 정하기, 서버 상태 학습, react query 적용	Week2
3~5주차	기능 집중 구현	Week 3~5
6주차	리팩토링	Week 6

1주차

1. 프로젝트 기획 및 협업 전략 수립

   • 어떤 서비스를 만들 것인가?
     • 현실적인 문제를 해결하는 서비스 (사용자 공감을 얻을 수 있는 서비스)
     • 기술적 도전이 있는 서비스
   • 어디까지 만들 것인가?
     • 1-2주차에 핵심기능 / 3-5주차에 부가 기능 추가
     • 핵심 기능: 쿼리 실행, 테이블 보기
     • 부가 기능: 테이블 추가/수정, 랜덤 데이터 추가, 예시 쿼리 추가

2. 백로그 작성 방식

   트러블 슈팅 : 작업 시간 예측 → 플래닝 포커로 작업 시간 메타인지를 개선

   • 관리 도구: GitHub + Excel (시각적 편리함)
   • 마일스톤 단위: 기능별로 구분
   • 이슈 단위: 작업 시간 2~5시간 단위로 쪼개기

3. 의사소통 개선

   • 기술 논의 중 이해가 어려운 경우, 대화를 중단하고 질문하여 팀원과의 이해를 맞춤
   • 팀원들의 피드백으로 더 빠르고 정확한 의사소통 가능

4. GitHub 협업 전략

   트러블 슈팅 : 피처 브랜치는 반드시 부모 브랜치에서 분기→ 피처 브랜치 간 분기는 커밋 관리가 어려움

2주차

1. Headless UI와 Tailwind CSS 도입
   • 프론트엔드 작업 속도를 높이기 위해 Tailwind와 shadcn 라이브러리 사용.
2. 서버 상태 학습 및 React Query 도입
   • 서버 상태와 로컬 상태의 개념을 학습하며 상태 분리의 중요성을 이해.
   • 서버 상태를 직접 관리하는 어려움을 깨닫고 React Query를 도입
3. 모킹 경험
   • API 의존성을 줄이고, 개발 효율성을 높이기 위해 axios-mock-adapter를 활용한 모킹 도입
4. API 설계 및 기술 학습
   • API 설계를 진행 후 이를 노션에 문서화
   • 배포 후 API 응답 형식이 문서와 달라 디버깅에 많은 시간을 소모
   • 교훈: 스웨거, 네트워크 탭, API 문서를 모두 확인하기 & 모킹의 중요성을 인식

3-5주차

1. sub key를 사용한 일부 fetch
   • 서브 키를 통해 세부 데이터를 효율적으로 가져오는 경험
2. 성급한 추상화
   • 커스텀 훅(useCustomMutation) 작성 후, 범용성과 유연성 부족으로 불편함 발생
   • 타입 정의의 복잡성과 동적 쿼리 키 생성의 제한.
   • 교훈 : 추상화는 반복된 코드 속 공통점을 충분히 파악한 뒤 이점이 있는 경우 진행
3. refetch 사용기
   • invalidateQueries : 효율적인 데이터 갱신에 적합
   • refetch : 즉각적인 데이터 갱신이 필요할 때 유용
     • 특정 쿼리 타입에만 실행하도록 조건을 추가
4. 리액트의 고유한 키값
   • new Date().getTime()으로 생성한 키를 사용해 React의 key 경고 발생.
   • 서버에서 생성된 ID 사용. 서버 ID가 없을 경우, UUID와 객체 문자열 변환을 조합해 고유 키 생성.
5. 상태는 어디에 둘까?
   • 부모에서 포커스 상태를 관리하자 자식 컴포넌트 전체가 리렌더링되어 깜빡이는 현상 발생
   • 상태를 자식(shell)으로 이동해 독립적으로 관리
   • 교훈 : 상태는 최대한 사용하는 컴포넌트에 두어 불필요한 리렌더링을 방지
6. 비즈니스 로직을 훅으로 분리하자
   • 반복적으로 사용되는 쉘 관련 비즈니스 로직을 커스텀 훅으로 분리
   • 관심사를 분리해 코드 재사용성과 가독성 향상
7. 할 수 있는 것과 할 수 없는 것을 구분하기
   • 내가 할 수 있는 작업량을 정량적인 시간으로 측정 (일주일에 20시간)
   • 불가능한 작업은 적극적으로 팀원의 도움 요청하기