낙관적 업데이트로 사용자 경험 개선하기

안녕하세요, 노머스 프론트엔드 팀 김민영입니다.

이번 글에서는 낙관적 업데이트를 적용하여 사용자 경험을 개선한 방식을 공유해보고자 합니다.

Jotai로 관리되고 있던 서버 데이터 상태

fromm 앱은 팬과 아티스트가 소통하는 커뮤니티 기능인 채널 서비스를 제공합니다. 기존에는 채널의 모든 데이터 상태를 Jotai로 관리했습니다. 예를 들어, 미디어 포스트 API를 요청해 데이터를 Atom에 저장하고, 좋아요 버튼을 누르면 Atom의 데이터를 수정해 다시 반영하는 방식이었습니다. 이 방식은 여러 이점도 있었지만, 가장 큰 문제는 데이터 정합성 불일치와 유지보수하기 어려워지는 치명적인 단점이 있었습니다.

이로 인해 필요한 시점에 매번 전역 데이터를 초기화해야 했고, 그 타이밍 이슈로 결국 빈 배열이 되어 데이터가 아예 보이지 않는 이슈를 초래하게 되었습니다.서버 응답과 상관없이 일단 클라이언트 값이 먼저 변경되면서 문제가 발생했기 때문입니다. 예를 들어, 사용자가 댓글 스택뷰에서 ‘좋아요’를 눌러 UI가 변경되었지만, 실제 서버 요청이 실패한 상태에서 스택뷰를 닫았다가 다시 열면 ‘좋아요’가 반영되지 않아 사용자가 오류로 인식하는 상황이 발생했습니다.

이 문제를 해결하기 위해 서버 상태와 클라이언트 상태를 분리하기로 결정했습니다. 서버를 통해서 받아오는 데이터는 @tanstack/react-query 에서만 관리하고, 클라이언트에서만 사용하는 데이터는 Jotai로 관리하자는 결론을 내렸습니다. 이를 통해 코드 유지보수 시 복잡성을 줄이고, 데이터를 일관적으로 관리하며, 데이터 정합성 불일치 문제를 해결할 수 있을 것으로 기대했습니다.

기존의 Jotai로 관리하던 서버 상태를 @tanstack/react-query 로 수정하는 과정에서 @tanstack/react-query의 낙관적 업데이트(Optimisic Update)에 대해 알게되었고, 이를 서비스에 적용하게 되었습니다.

낙관적 업데이트?

낙관적 업데이트(Optimistic Update)는 서버 API 응답을 받기 전에 UI를 먼저 변경하는 방식입니다. 서버로부터 결국 성공 응답을 받을 것이라고 낙관적으로 가정하는 것입니다. 이를 통해 사용자에게 더 빠르고 반응성 높은 경험을 제공할 수 있습니다.

하지만 낙관적 업데이트를 무조건 적용하는 것이 좋을까요?

포스트 작성/삭제/좋아요, 댓글 작성/삭제/신고/좋아요 등 @tanstack/react-query를 적용해야 할 서버 상태는 매우 많았습니다.

이 모든 부분에 낙관적 업데이트를 적용하는 것이 좋은지 의문이 들었습니다. 예를 들어, 댓글 작성 input에 금칙어를 입력하면 API 요청 시 에러가 반환됩니다. 금칙어 에러일 경우, 텍스트가 input에 그대로 남아있고 토스트 메시지가 뜹니다. 만약 댓글 작성에 낙관적 업데이트를 적용하면, 댓글이 이미 작성된 것처럼 보여 사용자에게 혼란을 줄 수 있습니다. 결국 기능마다 다르게 판단하여 상황에 따라 적절하게 적용하는 것이 중요하다는 것을 깨달았습니다.

낙관적 업데이트 방식

저희 팀은 포스트, 댓글, 답글 등 좋아요/좋아요 취소 기능에 낙관적 업데이트를 적용하기로 결정했습니다.

저희가 구현한 미디어 포스트 좋아요 기능의 낙관적 업데이트 방식은 다음과 같습니다.

• mutationFn 정의하기
  • 좋아요, 좋아요 취소 기능은 여러번 빠르게 클릭 시 다수의 API 요청이 갈 수 있으므로 디바운스(debounce)를 적용하여 API 요청을 처리했습니다.

    mutationFn: (isLike: boolean) => debouncedMutationFn({ isLike }),

• onMutate 정의하기 : onMutate 는 mutation이 수행되기 전에 실행되는 함수입니다.
  
  • 1️⃣ queryClient.cancelQueries 처리: 낙관적 업데이트와 별개로 관련 데이터의 refetch가 발생하면 데이터 도착 타이밍이 엇갈려 예상과 다른 이전 데이터를 보게 될 수 있습니다. 이를 방지하기 위해 queryClient.cancelQueries를 호출합니다. 예를 들어, 사용자가 ‘좋아요’ 버튼을 누름과 동시에 포스트 데이터가 refetch되는 상황에서 낙관적 업데이트가 먼저 적용된 후 refetch가 일어나면 이전 UI 상태가 다시 보이는 문제가 발생할 수 있습니다.
  • 2️⃣ 이전 데이터 return : queryClient.getQueryData를 통해 이전 데이터를 가져와 context에 저장하고 반환합니다.
  • 3️⃣ 낙관적 업데이트 : queryClient.setQueryData 를 통해 변경될 데이터 (nextData)를 미리 업데이트 해줍니다.

    onMutate: async (isLike: boolean) => {
        await queryClient.cancelQueries({ queryKey: getMediaPostKey }); // 1️⃣
        
        const previousData = queryClient.getQueryData<MediaPostVo['post']>(getMediaPostKey);  // 2️⃣ 
        
        if (!previousData) return;
        
        const nextData = () => isLike ? likeById(previousData) : dislikeById(previousData);
        queryClient.setQueryData(getMediaPostKey, nextData); // 3️⃣
    
        return { previousData };
    },

• onError 정의하기 : onError는 mutation이 실패했을 때 호출되는 함수입니다.
  • setQueryData를 통해 context에 저장해 둔 이전 데이터를 다시 세팅하여 UI를 복구합니다.

    onError: (_err, _vars, context) => {
        if (context?.previousData) {
            queryClient.setQueryData(getMediaPostKey, { ...context.previousData });
        }
    }

• onSettled 정의하기 : onSettled는 요청 성공 또는 실패한 후 항상 실행되는 함수입니다.
  • queryClient.invalidateQueries 를 호출하여 최종적으로 서버 데이터를 동기화합니다.

    onSettled: () =>
        queryClient.invalidateQueries({ queryKey: getMediaPostKey }),

공식문서에 나와있는 onSettled 정의는 이번 작업에서 제외했습니다. 그 이유는 무한스크롤로 구현되어 있는 리스트에서 정확한 해당 페이지의 querykey에 필요한 id 값을 알지 못하기 때문입니다. 또한, 댓글 스택뷰를 다시 열거나 해당 포스트 탭을 눌렀을 때 최신화하도록 설정해두었기 때문에 onSettled 시 queryClient.invalidateQueris 가 불필요하다고 판단했습니다.

낙관적 업데이트 적용 전 화면

낙관적 업데이트 적용 결과 화면
✅ 디바운스 적용
✅ 낙관적 업데이트 적용

에러 발생 시 화면

추가적으로 고민한 부분

invalidateQueries vs refetchQueries

댓글 스택뷰가 열릴 때마다 최신 데이터를 보여주기 위해 고민했던 다양한 방법을 소개하려 합니다. @tanstack/react-query에서 쿼리 데이터를 관리하는 두 가지 주요 방법은 refetchQueries와 invalidateQueries입니다. 이 둘은 쿼리 데이터를 갱신하는 방식에서 중요한 차이를 보입니다.

refetchQueries는 강제로 데이터를 ‘다시 가져오는’ 동작을 수행합니다. 즉, 호출되면 캐시 상태와 상관없이 무조건 데이터를 서버로부터 새로 요청합니다. 따라서 refetch는 특정 시점에 최신 데이터가 반드시 필요한 경우에 유용합니다.

반면, invalidateQueries는 데이터를 ‘무효화하는’ 동작입니다. 특정 쿼리 데이터를 “오래된(stale) 상태”로 표시하고, 이 쿼리를 관찰하는 컴포넌트가 마운트될 때 최신 데이터를 다시 가져오게 됩니다. 이렇게 하면 불필요한 네트워크 요청을 줄이고, 사용자가 캐시된 데이터를 먼저 보면서 더 빠른 반응성을 느낄 수 있게 해줍니다.

댓글 스택뷰는 사용자 경험이 중요한 기능이므로 unmount 시 invalidateQueries를 호출하는 방식을 선택하였습니다. 이 방식을 통해 사용자는 스택뷰를 다시 열었을 때 캐시된 기존 데이터가 즉시 화면에 표시되어 로딩 시간을 줄일 수 있었고, 그 사이 백그라운드에서 최신 데이터가 업데이트되어 자연스럽게 화면이 갱신되는 매끄러운 경험을 제공할 수 있었습니다. 이처럼 최신화 방식은 프로젝트의 특성과 요구사항에 따라 적절하게 설정하는 것이 좋습니다.

쿼리키 관리 방법

Jotai에서 @tanstack/react-query 로 전환하며 쿼리 키 관리 방식도 변경되어 저희의 방식을 공유합니다.

기존에는 사용하는 곳마다 키를 일일이 적어주는 방식이었다면, 변경된 방식은 다음과 같습니다.

export const QueryKeys = {
  // 댓글
  comment: {
      rootKey: ['getComment'],
      detailKey: ({ tab, commentId }: { tab: TabT; commentId?: number }) => ['getComment', { tab, commentId }]
  },
  ...
  
  // 미디어
  mediaPost: {
      rootKey: ['getMediaPost'],
      detailKey: ({ postId }: { postId: number }) => ['getMediaPost', { postId }]
  },
  
	...
}

하나의 QueryKeys 라는 Constant 객체를 만들어 그 내부에 각 키에 맞는 이름(ex. comment)을 설정하여 내부에 rootKey, detailKey 로 나누어 관리했습니다. 한곳에 모아서 쿼리 키를 관리하다 보니 유지보수성이 좋아졌고, 쿼리 키를 잘못 입력하는 실수도 방지할 수 있었습니다.

// 사용하는 곳 예시
const getMediaPostKey = QueryKeys.mediaPost.detailKey({ postId });

마무리하며

이번 포스트에서는 fromm 채널 서비스의 서버데이터를 @tanstack/react-query 로 관리하게 된 배경부터 낙관적 업데이트, 쿼리 키 관리 방식까지 공유드렸습니다.

Jotai로 관리하던 초기 문제부터 최적의 쿼리 키를 찾아 적용하기까지 수많은 고민과 시행착오가 있었습니다. 그 결과, 데이터 정합성 이슈를 해결하고, ‘좋아요’와 같은 핵심 기능에 대한 사용자의 반응 속도가 체감될 만큼 빨라졌습니다. 이 모든 과정이 더 나은 서비스를 향한 저희 팀의 끊임없는 노력이었다고 생각합니다.

앞으로도 노머스 프론트엔드 팀은 단순히 새로운 기능 개발 뿐만 아니라, 사용자 경험 개선과 데이터 안정성을 위해 지속적으로 노력할 것입니다. 꾸준히 발전해나가는 fromm 채널 서비스 많은 관심과 기대 부탁드립니다!

감사합니다 😃

현재 프론트엔드 팀은 함께 서비스의 품질을 높이기 위해 고민하고 함께 성장해나갈 개발자를 찾고 있습니다!
관심 있으신 분들은 아래에 있는 채용페이지를 통해 언제든지 지원 부탁드립니다. 🤗