Overview
다중 사용자 상태 충돌 문제를 전역 상태 기반 구조로 재설계하고, 협업 기준을 정의해 UI 충돌을 제거.
전역 상태 구조 설계
Recoil 기반, 사용자 상태를 단일 source로 통합
상태 기반 API 호출
상태 기반 호출로 데이터 동기화 문제 해결
커스텀 Hook 구조
상태-API 흐름 캡슐화
협업 기준 정의
FE/BE/디자인 간 공통 흐름 정리
Problem
상태 기준 부재 → API 호출 난립 → 데이터 불일치
- 동일 요청 중복 호출
- 여러 사용자 동시 접속 환경에서, 사용자별 데이터가 혼재됨
- UI 상태 불일치
Solution
[상태 → API 호출] 구조로 재정의
- 기준 정의: “상태가 변경되면 API 호출”
- 상태를 단일 기준으로 통합
- API 호출 조건을 상태에 종속
- 해결:
- 전역 상태 선언
- 상태 기반 API hook 설계
- 컴포넌트 → 상태 → API 흐름으로 변경
- 결과:
- 데이터 흐름 단일화
- 상태 충돌 제거
Implementation
Recoil 기반 전역 상태 설계
- 상태 변화 → API 호출 트리거
- 날짜 선택 상태 전역 관리
- 상태 변경 시 API 자동 실행
- 결과 상태 재저장 → UI 반영
Problem Solving
상태 기반 데이터 흐름으로 구조 통합
- 문제: 상태와 API 호출 분리
- 원인: 컴포넌트 단위 로직 분산
- 해결:
- 전역 상태 중심 구조 설계
- 상태 변경 → API 호출 구조 정의
- 데이터 흐름 단일화
- 결과:
- 상태 충돌 80% 감소
- 데이터 일관성 확보
- 기능 확장 시 영향 범위 축소
협업 기준 부재 → UI 변경 충돌 발생
- 문제:
- UI를 FE팀의 단독 판단으로 수정
- 디자인팀과 사전 합의 없음
- 원인:
- 협업 기준 부재
- 사용자 흐름 기준 공유 없음
- 해결:
- UI 변경 전 사전 공유
- 사용자 흐름 기준 논의
- 변경 이유 문서화
- 결과:
- 불필요한 수정 감소
- 디자인-개발 충돌 감소
- 인사이트:
- 개인적인 판단에 자만 금물.
Insight
개인 판단 → 기준 기반 협업으로 전환
- 충돌 상황: 일정 우선 → 소통 생략 → FE팀과 디자인팀의 충돌 발생
- 개선:
- 변경 전 공유
- 사용자 기준 정의
- 팀 합의 후 반영
- 인사이트:
- 협업은 기술 문제가 아니라 기준의 문제!
스크린샷
Result
Outcomes
다중 사용자 상태 충돌 제거 → 주요 기능 오류 0건 유지
API 호출 구조 개선 → 중복 호출 감소 → 서버 부담 감소
협업 충돌 문제 해결 → 생산성 향상
Before / After Metrics
상태 충돌 발생률
100% → 20%Before100%
After80% 감소
기능 추가 시 수정 범위
5파일 수 → 2파일 수Before5파일 수
After60% 감소
Recoil 기반 상태 구조 설계 → 동시 사용자 환경 API 호출 안정화 · Portfolio · Sojin Lee