Store에서 비동기 통신 분리하기 (feat. React Query)

Nov.12.2021 배민근

Web Frontend

안녕하세요, 저는 배민주문서비스팀의 Frontend Engineer 배민근입니다.

배민앱에서는 다양한 Web Frontend(이하 FE) 프로덕트들을 사용하고 있으며 요청사항이나 결제수단 등을 선택하는 주문하기 화면, 여러분이 지금까지 주문하신 것들을 볼 수 있는 주문내역 등 웹뷰로 된 화면을 심심치 않게 보실 수 있습니다. 주문 같은 경우에는 배민앱 내에서도 굉장히 오래전부터 있던 도메인이고, FE 특성상 기술이 빠르게 변화하므로 소위 Legacy 코드라 부르는 부분들이 많았습니다. 프로덕트의 개선과 생산성 향상을 위해 올해 저희가 가지고 있는 주문 FE 프로덕트의 개편을 준비했고 순차적으로 진행하고 있습니다.

오늘은 주문에서 사용하는 FE 프로덕트의 구조 개편을 준비하며 FE에서 사용하는 Store에 대해 개인적으로 고민했던 내용팀원들과 검토하고 논의했던 내용을 펼쳐보려고 합니다. 이 과정에서 생긴 여러 가지 의문과 도달한 생각, 그리고 React Query를 도입하기로 했던 배경에 대해 소개하고자 합니다.

본격적인 글에 앞서 먼저, FE를 개발하시는 분들에게 질문을 하나 드리면서 글을 시작하겠습니다.

“최근에 개발하면서 Store가 너무 비대해졌다고 느끼신 순간이 없으신가요?”

Store와 비동기 통신

먼저, 이 글에서 언급하는 Store는 별도 언급이 없다면 모두 Client Store라고 생각해 주시면 됩니다..!

Store를 한마디로 정의하면 전역 상태가 저장되고 관리되는 공간입니다. FE 개발할 때 보통 Redux, Mobx와 같은 상태 관리 라이브러리를 이용해 다루는 여러 상태와 이를 관리하는 코드들이라고 말할 수 있습니다.

제가 위에서 질문의 출발점은 FE 개발에서 전역 상태 관리를 위해서 Store를 사용하고 있는 것은 맞지만 상당 부분이 비동기 통신을 위해 쓰이고 있는 것 같다는 생각이었습니다. 개발하고 운영하는 프로덕트들에 빗대어 살펴보니 비동기 통신 자체와 이에 얽혀있는 다양한 정책들과 함께 Store의 역할이 너무 비대하고 이게 과연 Store의 본질이 맞는지 의문을 가지게 되었습니다.

저희가 예전에 많이 썼었던 Redux를 가지고 Store 예시와 함께 한 번 비동기 통신과 얽혀있는 코드를 살펴봅시다. Redux에서는 redux-saga, redux-thunk 등의 미들웨어를 통해, Mobx에서는 Flow를 통해 비동기 통신의 해법을 제공하고 있으며 아래 예시는 redux-saga를 사용한다는 가정으로 작성했습니다.

// Redux로 구현하는 Store 예시
export const FETCH_ORDER_REQUEST = 'FETCH_ORDER_REQUEST';
export const FETCH_ORDER_SUCCESS = 'FETCH_ORDER_SUCCESS';

export const fetchOrderRequest = createAction<number, string>(types.FETCH_ORDER_REQUEST, (page: string): number => {
  const parsed = Number.parseInt(page, 10);

  return Number.isNaN(parsed) ? 1 : parsed;
});

export const fetchOrderSuccess = createAction(types.FETCH_ORDER_SUCCESS, (order: OrderPayload) => order);

export const initialState: OrderState = {
  order: undefined,
  isFetching: false,
  ...
};

export default handleActions<OrderState, OrderPayload>({
    [FETCH_ORDER_REQUEST]: (state): OrderState => ({
      ...state,
      isFetching: true,
    }),
    [FETCH_ORDER_SUCCESS]: (state, action: Action<OrderPayload>): OrderState => ({
      ...state,
      order: {
        ...action.payload,
      },
      isFetching: false,
    }),
    ...
  },
  initialState
);
// redux-saga를 활용한 비통기 통신 예시
export function* fetchOrder$() {
  try {
    const params = yield select(paramsSelector);
    const { data } = yield call(api.fetchOrder, params);
    yield put(fetchOrderSuccess(data));
    ...
  } catch (error) {
    ...
  }
}

export function* fetchOrderSuccess$(action: Action<OrderPayload>) {
  try {
    yield call(saveHistorys, action.payload);
  } catch (error) {
    ...
  }
}
...
export default function* order$() {
  yield all([
    takeLatest(FETCH_ORDER_REQUEST, fetchOrder$),
    takeLatest(FETCH_ORDER_SUCCESS, fetchOrderSuccess$),
    ...
  ]);
}

지금 우리의 Store는

위의 예시를 살펴보면 isFetching과 order라는 2개의 상태가 보입니다. 각각 API AJAX 동작의 상태와 API Response를 가지고 있는 공간입니다. 이를 우리의 프로덕트들에 대입해 생각해봅시다. 보통 프로덕트는 복잡하니 몇 개, 몇십 개 혹은 몇백 개의 API 동작마다 모두 AJAX 상태와 응답값을 바라보는 상태들이 생기게 됩니다. (현업에서 사용하는 코드라면 isError와 같이 더 많은 상태들이 있을 수도 있고요!) 이러한 것들을 모두 전역 상태에 넣는다니 굉장히 비효율적이고 불필요해 보이지 않나요? 또한, API 응답에서 받은 데이터의 조작과 가공까지 Store에서 담당하고 있거나 혹은 관련 코드를 호출하고 있을 것입니다.

위의 코드를 보고 Store는 상태를 관리하는 코드라고 떠오를까요, 아니면 API 통신을 담당하는 코드라고 떠오를까요? 이 질문에 더해 그러면 우리가 만드는 프로덕트가 Redux나 Mobx를 이용해 만든 코드들이 저런 API 통신이 많은지, 아니면 순수 Client의 상태와 관련된 코드가 한번 생각해 봅시다. 적어도 저는 Store에 API 통신과 그에 관련된 정책이 훨씬 많았던 것 같습니다. 그러면서 굉장히 Store가 API마다 관습적인 코드의 길이나 복잡함만 늘고 있다는 고민에 빠졌습니다.

그렇다면 이 시점에서 제가 최근 가졌던 Store에 대해 가졌던 의문을 의식의 흐름대로 정리해 보겠습니다.

  • 제가 위에서 Store의 정의는 ‘전역 상태가 저장되고 관리되는 공간’이라고 했는데 과연 우리가 만들고 쓰는 Store는 이에 부합하는 모습일까요?
  • 오히려 관성적으로 해당 라이브러리들을 사용하면서 비동기 통신을 위해 상태 관리 라이브러리를 쓰고 부가적으로 전역 상태 관리를 쓰고 있지 않을까요?
  • 이 때문에 불필요한 상태나 로직들이 많아지면서 Store가 너무 비대해지고 여러 비효율이 발생하고 있진 않을까요?
  • 우리가 프런트엔드에서 Redux나 Mobx같은 라이브러리를 사용하기로 했던 것은 비동기 통신이 아닌 전역 상태 관리를 위함인데 우리는 왜 굳이 이들을 비동기 통신에 활용하고 있을까요?
  • 더 나은 방법은 없었을까요?

여기까지 왔을 때 제가 도달한 생각은 ‘어쩌면 기존에 우리가 FE에서 사용하고 있는 전역 상태 관리 방법들은 API 통신과 서버 상태 관리에 어쩌면 적정기술이 아닐 수도 있겠다.‘ 입니다. 우리가 Redux, Mobx와 같은 라이브러리를 왜 쓰는지에 물었을 때 당연하게도 전역 상태 관리라는 답변이 나오실 것입니다. 제가 처음에 드렸던 질문을 다시 상기해 봅시다. 위 코드와 정리한 의문들을 찬찬히 살펴보면 우리가 실제로 Store를 비대하게 사용하고 있다는 생각이 들지 않으시나요?

적정기술이 아닐 수도 있다는 의문이 들었으니 개발자로서 과연 적합한 대안이 있을지 검토를 해보고 싶었습니다. 그러기 위해서 먼저, 제가 해결하고자 하는 문제가 무엇일까 생각을 해보고 아래와 같이 정리해 보았습니다.

  1. Store에서 비동기 통신을 걷어내고 온전한 Client Side 전역 상태 관리로 탈바꿈
  2. 각종 API 통신과 sync를 맞춰야 하므로 Store 밖에서 서버와 관련된 상태 관리방안 마련
  3. 2번이 가능하면서도 서버와 관련된 상태는 마치 전역 상태처럼 사용할 수 있어야 함

React Query

위의 모든 고민과 배경을 뒤로하고 저희가 선택한 적정기술은 React Query 입니다. React Query는 Server State를 관리하는 라이브러리로 React 프로젝트에서 Server와 Client 사이 비동기 로직들을 손쉽게 다루게 해주는 도구입니다. 아래는 공식 홈페이지에서 제공하는 React Query의 기능을 한 문장으로 설명한 것입니다.

Fetch, cache and update data in your React and React Native applications all without touching any “global state”.

React Query는 Server State를 다룬다고 위에서 설명했는데 여기서 Server State란 공식 홈페이지에서 아래와 같이 설명하고 있습니다.

  • Client에서 제어하거나 소유되지 않은 원격의 공간에서 관리되고 유지됨
  • Fetching이나 Updating에 비동기 API가 필요함
  • 다른 사람들과 공유되는 것으로 사용자가 모르는 사이에 변경될 수 있음
  • 신경 쓰지 않는다면 잠재적으로 “out of date”가 될 가능성을 지님

Server State의 사례를 들어보자면, 배민앱에서 사용자가 주문을 넣는다면 주문 데이터가 생성됩니다. 이 주문 데이터는 1. 서버와 DB에서 관리되는 데이터이고, 2. Client에선 모르는 데이터이므로 API를 통해 받아와야 하며, 3. 해당 주문을 가게 사장님께서 접수/취소하는 등 상태를 변경할 수 있고 4. 주문이 진행중에서 배달완료로 변경되었는데 Client에서 최초 Fetch 후 신경 쓰지 않는다면 진행중으로 유지될테니 데이터가 “out of date” 될 수 있습니다. 이런 Server State의 특성상 Client에서는 캐싱, 데이터 업데이트 및 관리, lazy load와 같은 최적화, 받아온 데이터를 어떻게 공유해서 사용할 것인가 등 여러 가지 문제에 부딪히게 됩니다.

React Query는 Server State를 관리하기 위한 최고의 라이브러리 중 하나라고 소개하고 있으며, 실제로도 데이터 Fetching, 백그라운드에서 데이터 업데이트, Optimistic Updates, 캐싱과 Key를 통한 전역 상태와 같은 사용 등 많은 유용한 기능을 제공하고 있습니다. 그럼 이 시점에서 React Query를 사용한 예시를 한 번 살펴봅시다. React Query에선 API 통신을 위한 여러 함수를 useQuery와 같은 Hook 인터페이스로 제공합니다. 그래서 React Hooks를 써보셨다면 도입도 어렵지 않고 사용도 간편하며, 코드도 우리가 사용하던 기존 방식보다 훨씬 간결합니다.

import React from "react";
import ReactDOM from "react-dom";
import { QueryClient, QueryClientProvider, useQuery } from "react-query";
import { ReactQueryDevtools } from "react-query/devtools";

const queryClient = new QueryClient();

export default function App() {
  return (
    <QueryClientProvider client={queryClient}>
      <Example />
    </QueryClientProvider>
  );
}

function Example() {
  const { isLoading, error, data, isFetching } = useQuery("repoData", () =>
    fetch(
      "https://api.github.com/repos/tannerlinsley/react-query"
    ).then((res) => res.json())
  );

  if (isLoading) return "Loading...";

  if (error) return "An error has occurred: " + error.message;

  return (
    <div>
      <h1>{data.name}</h1>
      <p>{data.description}</p>
      <strong>👀 {data.subscribers_count}</strong>{" "}
      <strong>✨ {data.stargazers_count}</strong>{" "}
      <strong>🍴 {data.forks_count}</strong>
      <div>{isFetching ? "Updating..." : ""}</div>
      <ReactQueryDevtools initialIsOpen />
    </div>
  );
}

const rootElement = document.getElementById("root");
ReactDOM.render(<App />, rootElement);

위의 코드에 있는 useQuery는 데이터를 불러오기 위해 사용하는 함수입니다. Unique Key와 비동기 동작이 맵핑되어 있으며, 여기서 설정한 Unique Key를 통해 다른 곳에서도 해당 query의 결과를 꺼내올 수 있습니다. 이 함수의 반환값은 객체이며 isFetching, isSuccess와 같은 동작의 상태, 결과인 data, 에러가 발생했을 때 쓰는 error 등 이 API 동작에 대한 여러값과 함수를 가지고 있습니다. 또한, useQuery의 동작에 대해서 여러 가지 config들을 줄 수 있습니다. onSuccess, onError와 같이 데이터 Fetching 이후 실행할 동작을 넣어줄 수도 있으며, 아래 예시와 같이 refetchInterval을 주어 Polling 같이 동작하게 만들 수도 있습니다. 또한, Polling이나 이 query 동작 자체를 enabled와 같은 옵션으로 켜고 끌 수도 있습니다. 모든 config와 query 반환값 객체의 모든 것을 소개해 드리기에는 글이 너무 길어질 것 같아 생략하지만, 굉장히 많은 유용한 인터페이스들을 가지고 있습니다.

// react-query Polling
export const useFetchMultipleDeliveryStatus = useQuery(
  'fetchMultpleDeliveryStatus',
  (): AxiosPromise<ServerResponse<FetchMultipleDeliveryStatusResponse>> => fetchMultipleDeliveryStatus(...),
  {
    enabled: ...,
    refetchInterval: REFETCH_INTERVAL,
    onSuccess: data => {
          ...
    },
    ...
  }
);

위에서 제가 찾고 있는 적정기술의 조건 중 하나는 서버와 관련된 상태는 마치 전역 상태처럼 사용할 수 있어야 한다는 것이었습니다. React Query에서는 QueryClient를 사용하면 React Query가 Client에서 관리하는 Server State들을 Key를 통해 꺼내서 사용할 수 있습니다. 이렇게 사용할 수 있는 배경에는 React에서 제공하는 Context를 내부적으로 사용하고 있으니 궁금하시면 GitHub Repo에서 코드를 참고하시면 궁금증 해결에 도움이 되실 거 같습니다.

아래는 useMutation과 함께 React Query에서 그것을 어떻게 지원하는지에 대한 예시입니다. useMutation에 대해 간단히 설명하자면 서버의 데이터 변경 요청을 할 때 사용하는 함수로, Create, Update, Delete 요청과 같이 API 통신으로 Server State에 Side Effect가 일어나는 경우에 사용합니다.

function Example() {
  const queryClient = useQueryClient();

    const addTodoMutation = useMutation(
    newTodo => axios.post('/api/data', { text: newTodo }),
    {
      onMutate: async (newTodo: string) => {
        ...
        const previousTodos = queryClient.getQueryData<Todos>('todos')

        if (previousTodos) {
          queryClient.setQueryData<Todos>('todos', {
            ...
          })
        }
        ...
      },
      ...
      onSettled: () => {
        queryClient.invalidateQueries('todos')
      },
    }
  )
  ...
}

이외에도 위 예시에 Invalidation에 대한 코드도 있는데 Create, Update, Delete와 같이 Mutation 요청 시 서버에 값이 변하므로 React Query에 들고 있는 Server State는 낡은(stale) 데이터가 되게 됩니다. 이때 QueryClient에서 제공하는 invalidation 메서드들을 사용한다면 해당 Key를 들고 있는 Query들이 refetch가 발생하게 할 수 있습니다.

지금까지 CRUD 요청 1개에 대해서 이것저것 동작하는 것들을 보았는데, 그렇다면 한 페이지 혹은 컴포넌트에서 여러 API에서 데이터를 Fetching 해야 하는 경우라면 어떻게 해야 할까요? React Query를 사용한다면 FE 개발자분들은 아무것도 신경 쓰실 필요 없습니다. 저희가 useEffect가 용도에 따라 필요하다면 1개씩 더 추가하는 것처럼 아래와 같이 useQuery도 필요한 만큼 추가하시면 React Query에서 알아서 병렬처리해 동시성을 극대화해줍니다. (이 경우에 만약 Hook에서 제한하는 규칙에 위반된다고 한다면 useQueries를 찾아보세요!)

function App () {
  // The following queries will execute in parallel
  const usersQuery = useQuery('users', fetchUsers)
  const teamsQuery = useQuery('teams', fetchTeams)
  const projectsQuery = useQuery('projects', fetchProjects)
  ...
}

이외에도 Infinite scroll을 위한 useInfinityQuery 등 여러함수와 다른 유틸리티들도 제공합니다. 개인적으로는 서버와 Create, Update, Delete와 같은 요청이 많은 프로덕트에는 Optimistic Updates 적용하는 것도 구현 측면이나 UX 측면에서도 아주 유용했습니다.

지금까지 React Query에 대해 간략한 컨셉과 useQuery 정도만 소개해 드렸고, 이외에 React Query에 흥미가 생기셨다면 자세한 건 공식문서가 잘 되어있으니 참고하시면 좋을 것 같습니다. 또, React Query는 Stale While Revalidate라는 RFC 5861에 대한 구현체이고 이외에 SWR와 같은 다른 라이브러리도 존재하니 궁금하시면 비슷한 역할의 다른 라이브러리와도 비교해보면 혹시 React Query와 같은 목적의 라이브러리 도입에 도움이 되실 것 같습니다.

React Query를 도입한 후 Store와 Component는

저희는 최근 주문 FE 프로덕트 구조를 크게 개편하면서 React Query를 적용했고, 지난 9월 말에 주문내역에 개편한 구조가 반영되어 운영에 배포되었습니다. React Query로 비동기 통신을 일임한 후 Store는 팝업 등 여러 UI 상태 관리, 인증 정보 관리 등 Client 전반에 전역으로 관리되는 상태만 가지고 본래의 목적에 맞게 잘 사용되고 있습니다. 아래는 React Query 방식 비동기 통신이 적용된 예시입니다.

// 비동기 통신 관련 코드 (with React Query)
export const useFetchOrder = <T>(
  orderNo: string,
  options?: UseQueryOptions<ServerResponse<FetchOrderResponse>, AxiosError<ErrorResponse>, T>
): UseQueryResult<T, AxiosError<ErrorResponse>> =>
  useQuery('fetchOrder', (): Promise<ServerResponse<FetchOrderResponse>> => fetchOrder(orderNo), options);

const OrderHistory: React.FC = () => {
  ...
  const fetchOrderResult: UseQueryResult<ServerResponse<FetchOrderResponse>, AxiosError<ErrorResponse>> = useFetchOrder(orderNo, {
    onSuccess: (fetchOrderResultData: ServerResponse<FetchOrderResponse>) => {
      ...
    },
    onError: (err: AxiosError<ErrorResponse>) => {
      ...
    },
  });
  ...

  useEffect(() => {
    ...
  }, [fetchOrderResult.data]);
  ...
};

Store는 주문내역을 개편하면서 실제 적용 사례를 기준으로 말씀드리면, 원래 방식이라면 구현하기 위해서 아주 많은 Store 코드가 필요했을 것이지만 2~3개의 Store만 남았습니다. 또한, 순수 Client 상태를 관리하는데 Store를 사용할 수 있어 Store의 코드도 굉장히 간단해졌습니다. 기존에 Mobx와 Flow를 사용하던 방식이라면 OrderStore와 같은 Store로 뽑고 결과 data를 Store의 state로 관리한 다음 Flow를 활용해 해당 값을 받는 인터페이스를 만들고 Component에서 호출하고 state를 구독해 결과를 전달받는 식으로 작동했을 것입니다. 위에 Store 코드가 없는 이유도 주문정보를 불러오는 데 관여하는 Store가 없어서입니다. Store의 코드량이 굉장히 줄어든 것을 보고 기존에 우리가 Store에 API 응답값을 굉장히 많이 넣었다는 것을 다시 한번 느꼈습니다.

Component는 조금 더 비대해지긴 했으나 onSuccess와 onError 같은 것들을 service layer로 빼고 나니 기존에 Store에서 제공해 주는 인터페이스를 호출하는 코드와 거의 비슷한 규모가 되어 마치 React Hooks를 활용한 Container Component를 구현한 느낌이었습니다. 또한, React Query에서 제공하는 기본 기능으로 key만 같으면 어디서 조회하든 같은 값을 가지고 갱신하고 하므로 여러 컴포넌트에서 참조하는 전역 상태처럼 쓰는데도 무리가 없었습니다.

하지만 단점도 있다고 느꼈는데 이 전보다 코드 구조를 훨씬 잘 짜야 한다는 것입니다. Redux와 비교하자면 Redux가 가지고 있는 개발 패턴, 선언적인 구문들이 모두 없어지면서, 비동기 로직들이 프로젝트 설계에 신경 쓰지 않았다면 정말 추후 관리나 확장이 어려워질 정도로 Component에 유착된다든지 아니면 어디서 쓰이고 있는지 파악이 더 힘들어질 수 있을 것 같다는 생각도 들었습니다.

마치며, 요즘 Frontend 는 말이죠

부제로 선정한 ‘우리는 스토어를 스토어답게 쓰고 있나요?‘ 에 대한 나름의 고찰을 지금까지 길게 전달드렸습니다. React Query가 좋으니 사용하자는 말이 아니라 우리가 Store를 이렇게 구현했는지에 대한 고민을 시작으로 기존 구현 방법에 의문이 들었는지, React Query를 선택했는지까지 이어지는 고민의 과정을 공유해드리고 싶었습니다.

트렌드가 계속 바뀌는 Frontend 개발에 있어서 기술의 적합성과 최신성은 끊임없이 검토하고 필요하다고 판단되면 조심히 때론 과감히 시도해야 한다고 생각합니다. 하지만 여기에 명확한 Why 즉, 이유, 의도가 필요하다고 생각하고, 제가 적은 글이 우리가 왜 React Query를 도입하기로 했는지에 대한 Why입니다. Why가 명확한 엔지니어링을 통해 만든 설계, 기술, 개발이 좋은 사용자 경험으로 이어질 것이라 저는 믿습니다.

언제나 더 나은 방법이 나올 수도 있으니까요!

비슷한 고민을 하셨던 분, 이 글의 제목이나 내용 전개에 흥미를 느끼셨던 분들께 새로운 인사이트를 전달할 수 있었길 바라며 여기까지 긴 글 읽어주셔서 감사합니다.