[데브코스] React-Task-App: Redux와 타입 안정성

React Task App 프로젝트 실습에 들어왔다. 프론트엔드 파트에 진입하자마자 C 언어를 먼저 다루고, Typescirpt와 React 개념만 간단히 짚은 후 곧바로 실습이 진행되어 다소 당황스럽기도 하다...이론을 충분히 다질 시간이 있을 줄 알았는데, 생각보다 빠르게 실전 위주로 들어가는 구성이라 긴장감이 넘치는 듯.

 

특히 Redux까지 다루는건 놀라움의 연속이다. Redux를 실습까지 적용해 본 경험은 없어 Redux의 상태 관리 흐름이 아직 완전히 와 닿지는 않지만, 구조를 이해하는데 집중하면서 하나씩 따라가는 중이다. 실습을 통해 왜 이런 도구들이 필요한지, React 컴포넌트 구조와 어떻게 연결되는지를 몸으로 익히는 단계라고 생각하고 열심히 해보기

 개발에서 자주 사용하는 디렉토리 및 파일 역할들을 정리해보았다.

 

🗂️components/

• UI를 구성하는 재사용 가능한 단위
• 주로 Presentational / Dumb Component로 로직보다 UI 중심

🗂️ hooks/

• React의 재사용 가능한 로직 단위(useToggle, useFetch, useAuth 등)
• 상태 관리, side effect 처리 등을 캡슐화

🗂️ store/

• 전역 상태 관리
• 여러 컴포넌트에서 공유하는 데이터 저장소

🗂️ types/

• typescript 타입 정의 모음
• 프로젝트 전반에서 일관된 타입 사용 가능

🗂️ lib/, libs/

• 외부 라이브러리 설정 또는 래퍼 함수
• Axios 인스턴스, firebase 설정, 날짜 처리 라이브러리 래퍼 등 외부 도구와의 연결 지점

🗂️ utils/

• 순수 함수 기반 유틸리티 모음
• 날짜 포맷터, 문자열 파서, 계산기 등 상태나 UI에 의존하지 않고 범용적으로 사용하는 함수

폴더 구조

---

🧩사용할 컴포넌트

src
├── App.css
├── App.tsx
├── assets
│   └── react.svg
├── components
│   ├── ActionButton
│   │   ├── DropDownForm
│   │   │   ├── index.css.ts
│   │   │   └── index.tsx
│   │   ├── index.css.ts
│   │   └── index.tsx
│   ├── BoardList
│   │   ├── SideForm
│   │   │   ├── index.css.ts
│   │   │   └── index.tsx
│   │   ├── index.css.ts
│   │   └── index.tsx
│   ├── EditModal
│   │   ├── index.css.ts
│   │   └── index.tsx
│   ├── List
│   │   ├── index.css.ts
│   │   └── index.tsx
│   ├── ListContainer
│   │   ├── index.css.ts
│   │   └── index.tsx
│   ├── LoggerModal
│   │   ├── LogItem
│   │   │   ├── index.css.ts
│   │   │   └── index.tsx
│   │   ├── index.css.ts
│   │   └── index.tsx
│   └── Task
│       ├── index.css.ts
│       └── index.tsx
├── hooks
│   └── redux.ts
├── index.css
├── main.tsx
├── store
│   ├── index.ts
│   ├── reducer
│   │   └── reducer.ts
│   └── slices
│       ├── boardSlice.ts
│       ├── loggerSlice.ts
│       └── modalSlice.ts
└── types
    └── index.ts

18 directories, 32 files

강사님께서는 폴더 하위 파일도 폴더명과 통일하여 작성하셨다(ex: List/List.tsx, List.css.ts).

 

다만 나는 컴포넌트를 폴더 단위로 분리한 시점에서, 해당 폴더 자체가 이미 하나의 컴포넌트를 대표하는 의미를 가진다고 보았다. 이런 관점에서, 파일명에 다시 폴더명을 반복하는 것이 다소 중복된 표현처럼 느껴졌다.

 

그래서 List/List.tsx 대신 List/index.tsx 구조를 선택했다. 이 방식은 import 경로를 더 간결하게 만들 수 있고, 컴포넌트의 진입점을 명확히 드러낸다는 장점이 있다. 또한 이전 프로젝트에서도 동일한 폴더명/index.tsx 구조를 반복적으로 사용해 왔기 때문에, 개인적으로도 가장 익숙하고 유지보수가 수월한 방식이었다.

 

이런 이유로 이번 프로젝트에서도 구성은 폴더 기준으로 하고, 내부 진입 파일은 index.tsx로 통일하여 관리하였다.

---

⬇️패키지 설치

• @reduxjs/toolkit: Redux 공식 툴킷
• redux: 상태관리를 위한 기본 Redux 라이브러리
• clsx: 조건부 className을 깔끔하게 조합해주는 유틸
• @vanilla-extract/css: css-in-typescript 라이브러리
• @vanilla-extract/css-utils: splinkles같은 유틸리티 스타일 시스템을 구성할 때 사용하는 보조 모듈
• @vanilla-extract/vite-plugin: vite에서 vanilla-extract를 사용할 수 있도록 하는 빌드 플러그인
• react-icons: 아이콘 
• uuid: 고유 식별자(UUID) 생성 유틸
• react-beautiful-dnd: 드래그 앤 드롭 인터랙션 구현을 위한 라이브러리

❌@vanilla-extract/vite-plugin 의존성 충돌 문제

vite를 @latest로 설치했는데, @vanilla-extract/vite-plugin은 vite@^5.0.0 || ^6.0.0 까지만 지원해서 발생하는 문제였다.

 

✅해결방법:

vite 버전을 호환 버전으로 낮췄다.

npm install vite@^6

 

❌react-beautiful-dnd 의존성 충돌 문제

두 번째 충돌은 react-beautiful-dnd가 react 19를 지원하지 않아서 생긴 충돌이다(deprecated 됨).

 

✅해결방법:

대체 라이브러리를 사용하거나, React 버전을 낮추어 해결할 수 있다. 우선 강의와 실습 환경을 맞추기 위해 react-beautiful-dnd를 사용해야 했기에 react를 18로 낮추어 해결했다.

npm install react@18 react-dom@18

 

해결!

---

⚛️Redux 기본 설정

redux는 애플리케이션의 전역 상태를 관리하기 위한 라이브러리이다. React에서는 기본적으로 props, state를 통해 컴포넌트 간 상태를 전달하고 공유할 수 있지만, 애플리케이션 규모가 커질수록 상태가 여러 컴포넌트에 분산되고 의존 관계가 복잡해지면서 관리가 어려워진다. 이러한 문제를 해결하기 위해 Redux와 같은 상태 관리 라이브러리를 사용한다.

 

Redux 흐름

Redux의 핵심 특징은 상태 변경 흐름이 한 방향으로만 이루어진다는 점이다. 

컴포넌트에서 특정 동작이 발생하면, action이라는 객체가 생성되고, 이 action은 dispatch의 함수를 통해 reducer로 전달된다. reducer는 전달받은 action의 type을 기준으로 기존 상태를 바탕으로 새로운 상태를 반환하고, 이 결과가 redux store에 저장된다.

 

이처럼 상태가 예측 가능한 단일 흐름을 따라 변경되기 때문에, store의 값이 업데이트되면 해당 상태를 구독하고 있는 컴포넌트들은 자동으로 리렌더링된다. 이는 상태 변화의 원인을 추적하기 쉽고, 디버깅에 유리한 구조를 만든다.

 

Slice

Redux Toolkit을 사용하는 경우, reducer를 직접 작성하기보다는 slice를 생성하는 방식이 일반적이다.

 

CreateSlice를 사용하면 초기 상태, reducer 로직, 그리고 action 생성까지 한 번에 정의할 수 있어 Redux를 보다 간결하고 실용적으로 사용할 수 있다.

import { createSlice } from "@reduxjs/toolkit";
import type { ITask } from "../../types";

type TModalState = {
    boardId : string;
    listId: string;
    task: ITask;
}
const initialState:TModalState = {
    boardId: "board-0", 
    listId: "list-0", 
    task:{
        taskId: "task-0",
        taskName: "task 0", 
        taskDescription: "task description",
        taskOwner: "John"
    }
}

const modalSlice = createSlice({
    name: 'modal', 
    initialState,
    reducers:{

    }
})

export const modalReducer = modalSlice.reducer;

먼저 createSlice를 Redux Toolkit에서 import하고, 모달에서 다른 task의 정보 타입을 Itask 인터페이스로 분리하여 불러왔다. 상태의 구조를 타입으로 명확히 정의하여, 상태 변경 시 타입의 안정성을 확보함.

 

initialState는 Redux Store에 저장될 초기 상태값이다. 모달은 특정 task를 기준으로 열리기 때문에, boardId, listId, task 정보를 기본값으로 포함하고 있다. 실제 프로젝트에서는 모달이 열릴 때 action을 통해 이 값들이 동적으로 변경된다.

 

createSlice는 slice의 이름, 초기 상태, 그리고 상태를 변경하는 reducer 함수들을 하나의 객체로 묶어 정의한다. 현재는 reducer가 비어 있지만, 추후 모달을 열거나 닫는 동작 등의 reducer을 여기에 추가한다.

 

마지막으로 slice에서 생성된 reducer을 export하여, redux store에 등록할 수 있게 한다. Redux Toolkit을 사용하면 reducer와 action을 개별적으로 관리할 필요 없이, slice 단위로 상태 로직을 구성할 수 있다는 점이 큰 장점이다.

 

Redux Store 구성

//redux store용 파일

import { configureStore } from "@reduxjs/toolkit";
import reducer from "./reducer/reducer";

const store = configureStore({
    reducer
})

export default store

redux toolkit에서는 애플리케이션 전역 상태 관리를 위해 하나의 store을 생성하고, 여러 slice에서 정의한 reducer들을 이 store에 등록한다.

 

configureStore는 redux toolkit에서 제공하는 store 생성 함수로, 기존 redux의 createStore 보다 설정이 간결하고 기본적인 미들웨어와 개발자 도구 설정이 자동으로 포함된다.

 

이 파일에서는 store 생성 역할만 담당하도록 구성했고, 실제 reducer 조합 로직은 별도의 파일로 분리했다. 이렇게 하면 store의 설정과 상태 구조 정의를 명확하게 구분할 수 있기 때문에 프로젝트 규모가 커졌을 때 관리하기 수월하다.

 

Root Reducer 구성

import { boards } from "../slices/boardSlice";
import { loggerReducer } from "../slices/loggerSlice";
import { modalReducer } from "../slices/modalSlice";

const reducer = {
    logger: loggerReducer,
    boards: boards,
    modal: modalReducer
}

export default reducer;

위 코드는 여러 slice에서 정의한 reducer들을 하나의 객체로 묶는 root reducer 역할을 한다. 객체의 각 key는 redux store에 저장될 상태의 이름이 되며, value는 해당 상태를 관리하는 reducer 함수이다.

 

정리

정리하면, 최종 상태는 다음과 같은 형태가 된다.

state = {
  logger: ...,
  boards: ...,
  modal: ...
}

• slice 단위로 상태 로직을 분리-> 책임이 명확
• reducer를 별도의 파일로 관리->store 설정 코드가 단순해짐
• 상태 구조가 코드로 바로 드러나, useSelector 사용 시 예측 가능

위와 같은 설계적 장점이 있는 구조이고, 추후 slice가 추가 되더라도 reducer 객체에 항목만 추가하면 되기 때문에 확장성 측면에서 유리하다.

---

⚛️Redux Hooks

// redux store용 파일
import { configureStore } from "@reduxjs/toolkit";
import reducer from "./reducer/reducer";

const store = configureStore({
    reducer
})

configureStore을 통해 redux store을 생성한다. 이 때 전달한 reducer 객체의 구조가 전역 상태 트리의 형태가 된다.

 

export type RootState = ReturnType<typeof store.getState>;
export type AppDispatch = typeof store.dispatch;

• RootState: store.getState의 반환 타입을 기반으로 전역 상태의 타입을 자동으로 추론한다. reducer 구조가 변경되더라도 타입을 직접 수정할 필요가 없다는 장점이 있다.
• AppDispatch: store에서 사용하는 dispatch 함수의 타입을 그대로 가져와 정의한다. 이후 thunk나 async action이 추가되더라도 올바른 타입 추론을 유지할 수 있다.

import { useDispatch, useSelector, type TypedUseSelectorHook } from "react-redux";
import type { AppDispatch, RootState } from "../store";

기본으로 제공되는 useSelector, useDispatch는 타입 정보가 충분하지 않기 때문에, 이번 프로젝트에서는 전역 타입을 적용한 커스텀 훅을 만들어 사용하였다.

export const useTypedSelector: TypedUseSelectorHook<RootState> = useSelector;

TypedUseSelectorHook<RootState>를 사용해 useSelector가 반환하는 state의 타입을 RootState로 고정했다. 이로 인해 컴포넌트에서 state를 조회할 때 자동 완성과 타입 체크가 정확하게 동작한다.

export const useTypedDispatch = () => useDispatch<AppDispatch>();

useDispatch 역시 AppDispatch 타입을 명시적으로 적용했다. 이를 통해 dispatch 시 잘못된 action이나 payload를 전달하는 실수를 컴파일 단계에서 방지할 수 있다.

---

 

프로젝트 세팅 단계라 방심했는데 후반으로 갈수록 타입 관련 내용들이 한꺼번에 등장하면서 체감 난이도가 확 올라간듯...redux와 typescript를 함께 적용해, 단순히 기능을 구현하는 것 이상으로 타입 구조를 이해하는 데 더 많은 에너지가 필요하다고 느껴진다..

 

타입 때문에 혼란스러운 순간도 있었지만, Redux의 전체적인 흐름과 Rootstate, Dispatch 타입을 통해 상태 변경을 안전하게 관리하는 것을 배울 수 있었다.