Skip to content

리팩토링 필요성에 대한 회의

Jump to bottom
Ji Ho Jun edited this page Feb 19, 2026 · 1 revision

리팩토링이 필요하다고 생각하는 부분에 대해 의견 정리해오기

김희용

1. 성능 최적화

  • 무한 스크롤 로직 통일
  • 이미지 Lazy Loading 구현 등

2. 테스트 코드 작성 (유닛 테스트)

  • 리액트 컴포넌트의 내부 함수와 useEffect를 별도의 커스텀 훅으로 분리 => React Test Library 적극 활용, 컴포넌트 대상 혹은 커스텀 훅 대상으로 진행하는게 좋다고 생각합니다
  • 커스텀 훅 같은 경우 의존성들이 복잡하게 엮여있기 때문에 의도한대로 구현되고 작동하고 있는지 검증하는 과정이 필요하다고 생각합니다.

https://testing-library.com/docs/react-testing-library/setup/?ref=blog.viewinterhr.com#custom-render

3. 폴더 구조 변경

  • Feature 단위로 재구조화, FSD

https://joong-sunny.github.io/react/react7/

이지현

저는 포트폴리오에서 사용자 경험(UX)을 가장 강조하고 싶어요. 그 기반 위에 코드 가독성과 성능 최적화를 부차적으로 고려하고 있습니다.

사용자가 서비스를 이용할 때 버벅임 없이 자연스럽게 흐름을 따라갈 수 있도록하고, 단순한 편의성을 넘어서 서비스를 사용하는 과정 자체가 즐겁게 느껴지도록 만드는 게 목표예요.

1. Tanstack Query 도입

  • 모든 API 호출을 Tanstack Query로 마이그레이션
  • Prefetching으로 사용자 경험 개선
  • API 호출 횟수 감소
  • 코드량 감소 (try-catch 제거)

2. FSD(Feature-Sliced Design) 구조 도입

3. 성능 최적화

  • 무한 스크롤 최적화: Intersection Observer API로 개선 + 성능 비교
  • 낙관적 업데이트 (Optimistic Update): 좋아요/북마크 기능에 적용하여 즉각적인 피드백
  • 이미지 최적화: Lazy Loading + IntersectionObserver 조합
  • 리렌더링 최적화: React.memo + useMemo/useCallback 적용
  • 번들 사이즈 최적화: React.lazy로 코드 스플리팅

지호준

1. 성능 최적화

1-1. 코드로부터의 최적화

  • 원칙: 프로파일링 → 타겟팅 최적화(무작정 useMemo/useCallback 지양).
  • 불필요 재렌더: props 참조 안정화, React.memo/키 안정화, 컨텍스트 범위 최소화.
  • 무거운 리스트: 가상 스크롤(react-window 등), 무한 스크롤 로직 통일.
  • 콜백/값 메모: “참조 동일성”이 실제 비용 절감일 때만 useMemo/useCallback.

1-2. 실제 서비스에서의 최적화

  • 측정: Web Vitals(LCP/INP/CLS) 대시보드, Lighthouse 모빌 기준.
  • 이미지: lazy, 크기 명시, srcset/sizes, 캐시 헤더.
  • 번들: 코드 스플리팅/지연 로딩, 중복 의존 제거.
  • 네트워크: prefetch/prerender 전략, CDN 캐싱 확인.

2. 불필요한 주석 제거(코드 설명)

  • 코드는 코드로 설명 — 주석에 어떤 것만을 작성할지 논의가 필요.

3. any 타입 제거

  • 목표: any 제거로 타입 안전성·리팩토링 내성 강화.
  • tsconfig: noImplicitAny, strict 활성화(점진적 디렉터리별 허용 가능).
  • 유틸/훅에 제네릭 도입, 넓은 타입은 unknown + 내로잉으로 대체.

4. 에러 핸들링 불충분

  • 목표: console.error 위주 처리 → 중앙집중 에러 흐름으로 전환.
  • 전역: ErrorBoundary + 전역 에러 버스(예: emitError(err, context)).

리팩토링 방식 논의

  • 우선순위 정해서 같이 작업해나가는 방식으로 진행

  • 리팩토링용 브랜치를 하나 만들어서 에픽 -> 이슈 + task -> dev 브랜치로 머지

    브랜치 관리를 전략적으로 하지 못했던 부분이 아쉬웠음

리팩토링 우선 순위

  • 팀원끼리 소통을 활발히 하며 집중력 있게 진행해야하는 작업들과 그렇지 않은 작업들을 구분
  • 위 기준으로 학기 중 진행할 작업과 방학 중 진행할 작업으로 분류 (방학 중이 조금 더 밀도 있게 진행할 수 있다고 판단)

리팩토링 근거 및 판단 기준

폴더구조 변경

  • 가시적으로 보기에는 우선순위라고 보이기는 함
  • 구현량이 이미 있어서 바꿔도 복잡한건 그대로인데 지금 시점에서 굳이 개선을 해야할까…?
    • 퍼포먼스를 올리는게 우선순위라고 생각
  • 폴더구조 전체를 바꾸기보다 룰(프로젝트 상황에 맞게끔)을 정해서 필요한 부분을 바꾸는건 어떨지
    • 일관성없는 애들을 가다듬자

테스트코드 작성

  • 코드에서 useEffect 의존성 복잡도 증가 → 불필요한 리렌더링을 확인하고 싶었다 → 페이지 코드를 훅 단위로 분리 → 테스트 코드로 훅 단위 동작 검사

리액트 쿼리 도입

  • 에러 핸들링도 충분히 해결될 듯함
  • 테스트가 필요함, 실제로 어느정도 개선이 되는지 눈에 지표로 보이면 좋겠음
  • 코드가 줄어들고 캐싱으로 인한 사용자 경험의 개선(?)이 도입의 이유가 되지않을까
  • 엣지 케이스(ex. 에러처리)에 대한 표준화

any 타입 제거, 불필요한 주석 제거

  • 성능 최적화와 관련없는걸 먼저 해결하는게 어떨까
  • 주석은 어떤 기준으로 써야하는가? 라는 의문이 들었으나…. 주석 제거하는걸로

성능최적화

  • 서비스 완성도를 높이기 위한 과정이지 않을까~

리팩토링 작업 계획

학기 중이기 때문에 각자할 수 있는 부분과 비교적 간단한 리팩토링을 1차 개선으로 한다. 그리고 비교적 복잡한 작업이나 논의가 많이 필요한 작업들은 2차 개선으로 정한다.

1차 개선

  1. 문서화 → 리드미 먼저?
    1. 위키를 통해서 정리
    2. PR을 근거 기반으로 자세히 쓰면 좋곘다.
  2. 폴더 구조 개선
    1. 큰 단위 개선이 아닌 룰을 정해 작지만 유의미한 복잡도 개선
  3. any 타입 제거 → 타입안정성 강화
  4. 불필요한 주석 제거 (코드에 대한 설명)
    1. 이것도 룰이 필요함
    2. 없애자!

2차 개선

  1. Tanstack Query 도입
    1. 에러 핸들링 불충분
    2. 낙관적 업데이트 (Optimistic Update): 좋아요/북마크 기능에 적용하여 즉각적인 피드백
  2. 성능 최적화
    1. 이미지 최적화: Lazy Loading + IntersectionObserver 조합
    2. 무한 스크롤 최적화: Intersection Observer API로 개선 + 성능 비교
    3. 리렌더링 최적화: React.memo + useMemo/useCallback 적용
    4. 번들 사이즈 최적화: React.lazy로 코드 스플리팅
  3. 테스트 코드 (유닛 테스트 기준) 작성

리팩토링 기간

  • 1차 서비스 운영 기간인 26년 02월 안으로 마무리!

프로젝트 바로가기

리팩토링 회의록

리팩토링 내용 문서

Clone this wiki locally