복잡한 상태관리에 대처하는 방법

프로젝트 초기에는 Recoil을 사용하여 전반적인 상태 관리를 진행했습니다. Recoil은 간단한 API와 빠른 학습 곡선을 가지고 있어 초기 개발 속도를 높이는 데 큰 도움이 되었습니다. 하지만 프로젝트가 확장되면서 실시간 상태 관리와 API 통신 효율화라는 새로운 요구사항이 발생했고, 이를 해결하기 위해 Redux Toolkit과 RTK Query를 도입하게 되었습니다.

---

Recoil은 가볍고 직관적인 상태 관리 도구로 시작하기에는 적합했습니다. 하지만 시간이 지나면서 다음과 같은 한계가 점차 드러났습니다.

1. 실시간 상태 업데이트의 어려움
   프로젝트에서는 Stomp 프로토콜을 사용하여 실시간으로 상태를 업데이트해야 했습니다. 하지만 Recoil로 이를 처리하려면 여러 구독과 상태 업데이트 로직을 직접 작성해야 했고, 상태가 복잡해질수록 관리가 어려워졌습니다. 이로 인해 코드의 복잡성이 증가했고, 협업 과정에서도 어려움이 있었습니다.

2. 서버 상태와 클라이언트 상태 간의 불일치
   Recoil은 클라이언트 중심의 상태 관리 도구로, 서버와의 데이터 동기화를 직접 처리해야 했습니다. API 호출 결과를 상태에 저장하고 캐싱 로직을 따로 작성해야 했기 때문에 반복되는 코드가 많아졌고, 유지 보수성이 떨어졌습니다.

3. 비동기 로직 관리의 불편함
   비동기 작업(예: API 호출)의 상태(로딩, 성공, 실패)를 관리하려면 상태를 따로 정의하고 업데이트해야 했습니다. 이러한 작업이 쌓이다 보니 코드가 장황해지고 가독성이 떨어졌습니다.

---

이러한 문제를 해결하기 위해 Redux Toolkit을 도입했습니다. Redux Toolkit은 상태 관리를 중앙 집중화할 수 있을 뿐만 아니라, 비동기 로직을 일관성 있게 처리할 수 있는 기능을 제공합니다.

1. 중앙 집중화된 상태 관리
   Redux Toolkit은 Store를 중심으로 상태를 관리하며, 실시간 데이터 변경 사항을 쉽게 구독하고 업데이트할 수 있었습니다. Stomp로부터 데이터를 받아 Store에 저장하고 필요한 컴포넌트로 전달하는 과정이 간소화되었습니다.

2. 코드 일관성과 유지 보수성 향상
   createSlice를 사용하여 상태 정의와 관련 로직을 한 곳에서 관리할 수 있었습니다. 상태 업데이트와 관련된 로직이 잘 구조화되면서 협업 과정에서의 혼란도 줄어들었습니다.

3. 미들웨어를 통한 실시간 데이터 처리
   Redux의 미들웨어를 활용하여 Stomp 메시지를 수신하고 상태를 업데이트하는 작업을 분리했습니다. 이를 통해 비즈니스 로직과 상태 관리 로직이 명확히 구분되었습니다.

---

상태 관리 전환과 함께 RTK Query를 도입하여 API 통신을 효율적으로 관리했습니다. RTK Query는 Redux Toolkit의 일부로 제공되는 데이터 페칭 라이브러리로, 클라이언트와 서버 간의 데이터를 쉽게 동기화할 수 있도록 돕습니다.

1. 내장된 캐싱 및 데이터 관리
   RTK Query는 기본적으로 요청 결과를 캐싱하며, 동일한 요청이 발생하면 캐시 데이터를 반환합니다. 이를 통해 불필요한 API 호출을 줄이고, 데이터가 항상 최신 상태를 유지하도록 보장했습니다.

2. 로딩 상태 및 에러 처리 자동화
   데이터 페칭 과정에서 로딩 상태나 에러를 따로 관리하지 않아도 되었으며, 기본적으로 제공되는 로직을 활용할 수 있었습니다. 이로 인해 API 관련 코드가 간결해지고 생산성이 높아졌습니다.

1. 실시간 상태 관리의 간소화 Stomp로부터 전달받은 실시간 데이터를 Store에서 중앙 집중화하여 관리하므로, 컴포넌트에서 구독 및 업데이트 로직이 간단해졌습니다. 결과적으로 실시간 데이터 처리가 훨씬 명확해지고 효율적이었습니다.
2. API 통신 로직의 일관성 RTK Query를 통해 API 호출과 관련된 모든 작업(로딩, 성공, 실패 상태 처리)을 일관된 방식으로 관리할 수 있었습니다. 반복적인 코드 작성이 줄어들고 가독성이 크게 향상되었습니다.
3. 팀 내 협업 생산성 향상 상태 관리와 API 로직이 잘 구조화되면서, 팀원들이 상태나 데이터를 다룰 때의 진입 장벽이 낮아졌습니다. 또한, 상태와 API 로직이 분리되어 유지 보수가 더 쉬워졌습니다.

Redux Toolkit과 RTK Query는 많은 장점을 제공했지만, 완벽한 솔루션은 아니었습니다.

1. 복잡한 상태 구조 프로젝트 규모가 커지면서 Store 내 상태 구조가 복잡해질 수 있었습니다. 이를 해결하기 위해 Slice를 더 세분화하고, 비즈니스 로직과 UI 상태를 분리하는 등의 설계 노력이 필요했습니다.
2. 초기 설정의 복잡성 Redux Toolkit과 RTK Query의 초기 설정은 Recoil에 비해 더 많은 작업이 필요했습니다. 하지만 장기적인 유지 보수성과 확장성을 고려했을 때 충분히 투자할 만한 가치가 있었습니다.

Redux Toolkit과 RTK Query는 실시간 상태 관리와 효율적인 API 통신을 처리해야 하는 프로젝트에서 매우 유용한 도구였습니다. Recoil에서 Redux로 전환하면서 코드 일관성과 유지 보수성을 크게 향상시켰고, 특히 Stomp 프로토콜을 통한 실시간 데이터 관리와 GET 요청 처리에서 효과적인 결과를 얻을 수 있었습니다.