클라이언트 상태관리 vs 서버 상태관리: 로그인/회원가입 및 지출 관리 시스템 구현 회고

 

최근에 진행한 '개인 지출 관리' 프로젝트에서 탠스택쿼리(TanStack Query)를 활용해

회원가입/로그인 기능과 지출 관리 기능을 구현했습니다.

 

프로젝트를 하면서 드는 의문점은

인증/인가, 데이터 CRUD를 탠스택 쿼리를 쓰면서 서버에서 상태를 관리하게 되었고

그럼 현재 프로젝트에서 굳이 리덕스를 써서 클라이언트 상태관리를 할 필요가 없겠네? 였습니다.

 

굳이 클라이언트 상태 관리할게 있다면 사용자의 로그인상태나, 사용자의 정보 정도...?

근데 탠스택 쿼리로 기능 구현이 충분히되는데 리덕스로 같은 작업을 2번이나 할 필요가 있을지 의문이 들었습니다.

 

진지하게 의문을 갖고 튜터님께 찾아가 위의 내용에 대해 질문을 드렸습니다.

 

돌아온 튜터님의 말씀은,

"사실 현재 프로젝트에서는 크게 클라이언트 상태관리가 중요하지 않다."라고 말씀하셨고

"클라이언트 상태관리는 쇼핑몰에서 일시적으로 물건을 잠시 담아두는 장바구니 기능에 사용이 되고,

물건을 담아두었다가 실제로 구매를 하려고 버튼을 눌렀을 때 서버로 전송이 되는 것이다"라는

구체적인 답변을 주셨습니다.

 

또한 현재 저의 고민에 대해 엄청 칭찬을 해주셨습니다.

현업에서는 쿼리만 써서 프로젝트를 하지 않고 클라이언트 상태관리와 서버 상태관리를 섞어서

종합적으로 프로젝트를 만들기 때문에 각각 어디에 적합한지 생각해보는 것이 중요하다고 말씀해주셨습니다.

 

 

이 과정을 통해 배운 점과 클라이언트 상태 관리와 서버 상태 관리의 차이점을 중점적으로 다뤄보겠습니다.

 

 

프로젝트 요구사항

기능 요구사항

1. 회원가입/로그인 기능 구현
   • JWT 인증 서버를 사용해 인증된 사용자만 서비스를 이용할 수 있도록 구현.
2. 지출 데이터 관리
   • json-server를 이용해 지출 데이터의 CRUD 기능 구현.
   • 지출 데이터에 생성한 사용자의 정보를 포함.
3. API 호출
   • fetch 대신 axios 사용.
4. 서버 상태 관리
   • 지출 데이터 관련 API 통신 시, 탠스택쿼리(TanStack Query) 사용.
   • 지출 데이터의 상태 관리는 Props-drilling, Context API, Redux 사용 대신 TanStack Query 사용.

 

구현 과정

1. 회원가입/로그인 기능

JWT 인증 서버를 이용해 회원가입과 로그인 기능을 구현했습니다. 인증된 사용자만 지출 관리 시스템에 접근할 수 있도록 설정했습니다.

1. 회원가입: 사용자 정보를 서버로 전송해 회원가입 처리.
2. 로그인: 서버로부터 JWT 토큰을 받아 로컬 스토리지에 저장. 이후 API 요청 시 이 토큰을 사용해 인증 처리.

2. 지출 데이터 관리

json-server를 사용해 지출 데이터의 CRUD 기능을 구현했습니다. 지출 데이터에는 생성한 사용자의 정보도 포함시켰습니다.

1. 생성(Create): 새로운 지출 데이터를 생성하고 서버에 저장.
2. 조회(Read): 서버에서 지출 데이터를 받아와 화면에 표시.
3. 수정(Update): 기존 지출 데이터를 수정하고 서버에 반영.
4. 삭제(Delete): 지출 데이터를 삭제하고 서버에서 제거.

3. 탠스택쿼리 사용

지출 데이터의 상태 관리는 탠스택쿼리를 사용해 서버 상태를 효율적으로 관리했습니다.

1. 데이터 페칭 및 캐싱: 서버에서 데이터를 받아와 캐싱, 필요 시 재사용.
2. 자동 갱신: 데이터 변경 시 자동으로 UI 업데이트.
3. 에러 및 로딩 상태 관리: 데이터 요청 중 발생하는 로딩 및 에러 상태 관리.

 

클라이언트 상태 관리 vs 서버 상태 관리

1. 클라이언트 상태 관리

클라이언트 상태는 UI의 상태, 사용자 입력 등 일시적인 데이터를 관리합니다. 예를 들어:

• UI 상태: 모달 창 열림/닫힘, 폼 입력 상태 등.
• 일시적인 데이터: 사용자 입력 값, 로컬에서만 필요한 데이터 등.

리덕스(Redux)나 Context API를 사용해 클라이언트 상태를 관리합니다. 주로 다음과 같은 특징이 있습니다:

• 즉각적인 반응성: 사용자 인터랙션에 빠르게 반응.
• 전역 상태 관리: 애플리케이션 전반에서 필요한 상태 관리.

2. 서버 상태 관리

서버 상태는 서버에서 받아온 데이터, 즉 백엔드와의 통신을 통해 얻어지는 데이터를 관리합니다. 예를 들어:

• 사용자 정보: 로그인한 사용자 정보, 인증 토큰 등.
• 지출 데이터: 서버에서 받아온 지출 데이터 등.

탠스택쿼리와 같은 라이브러리를 사용해 서버 상태를 관리합니다. 주로 다음과 같은 특징이 있습니다:

• 데이터 페칭 및 캐싱: 서버에서 데이터를 받아와 캐싱, 필요 시 재사용.
• 자동 갱신: 데이터 변경 시 자동으로 UI 업데이트.
• 에러 및 로딩 상태 관리: 데이터 요청 중 발생하는 로딩 및 에러 상태 관리.

 

회고

탠스택쿼리를 사용해 회원가입/로그인 및 지출 관리 기능을 구현하면서 클라이언트 상태 관리와 서버 상태 관리의 역할을 명확히 구분할 수 있었습니다. 이를 통해 애플리케이션의 복잡도를 줄이고, 보다 효율적으로 상태를 관리할 수 있었습니다.

 

앞으로의 계획

• 상태 관리 최적화: 클라이언트 상태 관리는 리덕스나 Context API를 계속 사용하되, 더 효율적인 구조를 고민해볼 예정입니다.
• 탠스택쿼리 활용 확대: 다른 서버 데이터 관리에도 탠스택쿼리를 적극적으로 활용해볼 계획입니다.

 

이번 경험을 통해 클라이언트와 서버 상태 관리의 차이를 명확히 이해할 수 있었고, 이를 통해 더 나은 애플리케이션을 만들 수 있었습니다. 앞으로도 상태 관리에 대한 이해를 바탕으로 더욱 효율적인 개발을 진행해 나가겠습니다.