Redux 에서 비동기 상태 변경 처리에 Redux-thunk 를 이용해야하는 이유

Redux는 기본적으로 동기적인 데이터 흐름을 다루기 위해 설계되었기 때문에, API 호출 같은 비동기 작업을 직접 처리하지 않는다.
redux-thunk는 Redux에서 비동기 작업을 관리할 수 있도록 도와주는 미들웨어라고 한다.

 

 

그런데 Redux 에서 굳이 Redux-thunk 를 활용하여 비동기 상태 변경 처리를 해야하는 이유가 궁금해졌다.

 

 

Redux 외부에서 API 요청을 주고 받고, 그 결과만 Redux로 보내어 상태를 업데이트 (dispatch) 해도 되는거 아닐까?

 

 

즉, 다음과 같은 코드를 작성하는 것과 비교했을 때 Redux-thunk 를 사용하는 것에 어떤 이점이 있는지 궁금해졌다.

// 컴포넌트에서 비동기 요청과 상태를 로컬로 관리하는 예시
const MyComponent = () => {
  const [loading, setLoading] = useState(false);
  const [error, setError] = useState(null);
  const dispatch = useDispatch();

  const fetchData = async () => {
    setLoading(true);
    try {
      const response = await apiRequest();
      dispatch(updateData(response.data)); // 요청 성공 시 상태 업데이트
    } catch (err) {
      setError(err.message); // 요청 실패 시 에러 상태 업데이트
    } finally {
      setLoading(false);
    }
  };

  useEffect(() => {
    fetchData();
  }, []);
};

redux-thunk를 활용하여 비동기 상태 변경 처리를 하는 이유

Redux Toolkit에서 redux-thunk를 활용하여 비동기 상태 변경 처리를 하는 이유는 비동기 작업의 전후 상태를 Redux에서 관리하고, 일관된 상태 관리 흐름을 유지하기 위해서이다. 외부에서 비동기 API 요청을 처리하고, 성공 시에만 Redux 상태를 업데이트하는 방식도 가능하지만, redux-thunk를 사용하면 다음과 같은 이점이 있다.

1. 로딩 상태와 에러 상태 관리

비동기 요청에는 주로 세 가지 상태가 존재한다.

• 요청이 시작됨 (loading 상태)
• 요청이 성공적으로 완료됨 (success 상태)
• 요청이 실패함 (error 상태)

예를 들어:

• redux-thunk를 사용하면, 비동기 작업의 각 단계에 따라 상태를 업데이트할 수 있다.
• API 호출이 시작되면 loading 상태를 true로 설정
• API 호출이 성공하면 loading을 false로 설정하고, 데이터를 상태에 저장
• API 호출이 실패하면 loading을 false로 설정하고, 에러 메시지를 상태에 저장

// slice.js
import { createSlice, createAsyncThunk } from '@reduxjs/toolkit';

// createAsyncThunk를 사용해 비동기 액션 생성
export const fetchData = createAsyncThunk(
'data/fetchData',
async (_, thunkAPI) => {
const response = await fetch('https://api.example.com/data');
const data = await response.json();
return data; // fulfilled 상태의 payload로 전달됨
}
);

// createSlice를 통해 리듀서와 액션 정의
const dataSlice = createSlice({
name: 'data',
initialState: {
data: null,
loading: false,
error: null,
},
reducers: {
// 동기 액션이 필요한 경우 여기에 추가할 수 있음
},
extraReducers: (builder) => {
builder
.addCase(fetchData.pending, (state) => {
state.loading = true;
state.error = null;
})
.addCase(fetchData.fulfilled, (state, action) => {
state.loading = false;
state.data = action.payload;
})
.addCase(fetchData.rejected, (state, action) => {
state.loading = false;
state.error = action.error.message;
});
},
});

export default dataSlice.reducer;

import React, { useEffect } from 'react';
import { useDispatch, useSelector } from 'react-redux';
import { fetchData } from './slice';

const DataComponent = () => {
  const dispatch = useDispatch();
  const { data, loading, error } = useSelector((state) => state.data);

  useEffect(() => {
    dispatch(fetchData());
  }, [dispatch]);

  if (loading) return <p>Loading...</p>;
  if (error) return <p>Error: {error}</p>;

  return (
    <div>
      <h1>Data</h1>
      <pre>{JSON.stringify(data, null, 2)}</pre>
    </div>
  );
};

export default DataComponent;

 

=> 이렇게 하면 컴포넌트에서 로딩 스피너를 표시하거나, 에러 메시지를 사용자에게 보여주는 등 보다 풍부한 UX를 제공할 수 있다.

2. 상태의 일관성 유지

 

비동기 요청을 외부에서 처리하고 성공한 경우에만 Redux 상태를 업데이트하면, 상태 변화의 흐름이 Redux에서 관리되지 않기 때문에 상태의 일관성이 깨질 위험이 있다.

• 외부에서 API 요청이 성공했지만 Redux 상태 업데이트가 누락되거나, 네트워크 지연으로 인해 늦게 도착한 응답이 상태를 잘못 덮어쓰는 경우가 발생할 수 있다.
• Redux는 상태의 단일 진실 소스(single source of truth)로서 동작해야 하므로, 비동기 작업의 상태 변화를 일관되게 관리하는 것이 중요하다.
• redux-thunk를 사용하여 비동기 로직을 Redux 안에서 관리하면, 상태 변화가 Redux 흐름에 통합되어 상태의 일관성을 유지할 수 있다.

비동기 요청을 외부에서 처리하고 성공한 경우에만 Redux 상태를 업데이트할 때 발생할 수 있는 문제를 이해하려면, 상태의 일관성이 깨질 위험이 어떤 상황에서 발생할 수 있는지 살펴볼 필요가 있다.

 

1) 네트워크 지연 또는 실패로 인한 상태 불일치

예를 들어, 사용자가 두 번 연속으로 "데이터 로드" 버튼을 눌러 비동기 요청이 두 번 발생했다고 가정해 보자.

• 첫 번째 요청이 서버에 도달하지만 네트워크 지연으로 인해 응답이 늦어지고,
• 두 번째 요청은 빠르게 응답을 받아 성공적으로 데이터를 가져온다.

이 경우, 비동기 요청을 외부에서 처리하고 두 번째 요청의 성공 응답만 Redux 상태에 반영한다면 문제가 없어 보일 수 있지만, 나중에 첫 번째 요청이 응답을 반환할 경우 예상치 못한 결과가 발생할 수 있다.

예시

// 첫 번째 요청의 결과가 늦게 도착하여 상태를 덮어쓰는 상황
dispatch(fetchDataSuccess(secondResponseData)); // 두 번째 요청 결과
dispatch(fetchDataSuccess(firstResponseData));  // 첫 번째 요청 결과 (늦게 도착)

이렇게 되면 Redux 상태에는 가장 최신 상태가 아닌, 첫 번째 요청의 결과가 남게 된다. 사용자는 화면에서 오래된 데이터를 보게 되며, 상태의 일관성이 깨진 것을 느끼게 된다.

2) 여러 컴포넌트에서 동일한 비동기 작업을 사용할 때

Redux 상태는 여러 컴포넌트 간에 공유되기 때문에, 여러 컴포넌트에서 동일한 비동기 작업을 트리거하는 경우가 자주 발생한다. 예를 들어, 사용자가 로그인되어 있을 때 사용자 데이터를 가져오는 비동기 작업이 여러 컴포넌트에서 필요할 수 있다.

만약 비동기 요청을 외부에서 처리하고 성공한 경우에만 Redux 상태를 업데이트한다면, 여러 컴포넌트에서 비슷한 요청이 중복되거나 서로 충돌할 가능성이 높아진다.

예시

• 컴포넌트 A와 컴포넌트 B가 동시에 사용자 데이터를 요청한다고 가정한다.
• 두 컴포넌트는 서로 다른 타이밍에 API 요청을 수행하고 성공 시에만 Redux에 데이터를 업데이트한다.

이 경우, 컴포넌트 A의 요청과 컴포넌트 B의 요청이 동시에 성공할 수도 있고, 하나는 성공하고 하나는 실패할 수도 있다. 상태 업데이트가 비동기 요청의 성공 여부에만 의존할 경우, 각 요청의 응답 순서와 성공/실패 여부에 따라 Redux 상태가 예측할 수 없는 방식으로 변경될 수 있다.

이로 인해 데이터가 중복 요청되거나, 상태가 예상치 않게 덮어써지는 현상이 발생할 수 있다. redux-thunk와 같은 미들웨어를 통해 중앙에서 비동기 작업을 관리하면 이러한 중복 요청을 방지할 수 있다.

3) 상태 변화가 단일 진실 소스가 아닌 여러 곳에서 관리됨

Redux의 핵심 원칙 중 하나는 단일 진실의 소스(single source of truth)이다. 상태가 중앙에서 일관되게 관리되어야만 애플리케이션이 예측 가능한 상태로 유지될 수 있다.

하지만 비동기 요청이 외부에서 관리되고, 성공 시에만 Redux에 결과를 업데이트하면 상태 변화가 Redux 외부와 내부 양쪽에서 발생하게 된다. 이로 인해 상태의 변경 흐름이 명확하지 않으며, 상태가 예측 불가능하게 된다.

3. 중앙 집중식 비동기 로직 관리

redux-thunk를 사용하면 모든 비동기 로직이 Redux의 액션 생성 함수 안에 정의되므로, 비동기 작업이 어디서 발생하고 상태가 어떻게 변화하는지 코드 구조가 더 명확해진다. 비동기 요청을 외부에서 처리할 경우, 요청 위치가 여기저기 흩어질 수 있어 코드 유지보수가 어려워질 수 있다.

 

만일 외부에서 요청을 처리하고 성공할 때만 상태를 업데이트하면, Redux에서는 요청 중에 상태가 어떻게 변했는지 알 수 없기 때문에 상태 변화의 전체 흐름을 추적하기 어려워진다. 특히 loading 상태와 error 상태가 Redux에 반영되지 않는다면, UI에서 로딩 스피너를 표시하거나 에러 메시지를 보여주는 등의 처리가 불가능해질 수 있다.

예시

만약 Redux에서 loading 상태를 관리하지 않는다면, 로딩 상태를 표시하려면 다음과 같은 방식으로 컴포넌트 내부에서 useState로 관리해야 할 수 있다.

// 컴포넌트에서 비동기 요청과 상태를 로컬로 관리하는 예시
const MyComponent = () => {
  const [loading, setLoading] = useState(false);
  const [error, setError] = useState(null);
  const dispatch = useDispatch();

  const fetchData = async () => {
    setLoading(true);
    try {
      const response = await apiRequest();
      dispatch(updateData(response.data)); // 요청 성공 시 상태 업데이트
    } catch (err) {
      setError(err.message); // 요청 실패 시 에러 상태 업데이트
    } finally {
      setLoading(false);
    }
  };

  useEffect(() => {
    fetchData();
  }, []);
};

 

이 경우 loading과 error 상태가 Redux의 중앙 상태 관리 흐름에 포함되지 않아, 다른 컴포넌트에서 이 상태를 공유할 수 없게 된다. 또한 Redux DevTools에서 상태 변화의 흐름을 확인할 수 없어 디버깅이 어려워질 수 있다.

4. Redux DevTools와의 연동

redux-thunk를 사용하면 Redux DevTools에서 액션의 흐름을 추적할 수 있다. pending, fulfilled, rejected 등의 액션이 순서대로 디스패치되는 과정을 시각적으로 확인할 수 있어, 비동기 작업을 더 쉽게 디버깅할 수 있다.

5. 액션 체이닝 및 상태에 따른 비동기 로직 처리

redux-thunk를 사용하면 Redux 상태에 따라 조건부 비동기 작업을 수행할 수 있다. 예를 들어, 특정 상태일 때만 API 요청을 보내거나, 이전 요청의 결과에 따라 새로운 요청을 보내는 로직을 구현할 수 있다.

   export const conditionalFetchData = () => {
     return (dispatch, getState) => {
       const { data } = getState();
       if (!data) {
         dispatch(fetchData());
       }
     };
   };

이와 같이 redux-thunk를 사용하면 비동기 작업이 Redux 상태 관리의 일환으로 통합되며, 더 일관되고 체계적인 상태 관리를 할 수 있다. Redux의 장점인 단일 진실 소스를 유지하면서, 비동기 로직의 전후 상태를 일관되게 관리할 수 있다는 점이 큰 이점이다.

결론

redux-thunk를 사용하여 비동기 작업을 Redux 내부에서 처리하면, 요청의 시작, 성공, 실패 상태를 Redux에서 일관되게 관리할 수 있다. 이는 상태의 일관성을 보장하고, 비동기 로직을 예측 가능하게 만들어 준다. redux-thunk와 같은 미들웨어를 통해 비동기 작업을 중앙에서 관리하는 것이 복잡한 애플리케이션에서 상태 일관성을 유지하는 데 매우 중요하다.