API 계층 재설계 제안과 팀 단위 점진 전환
제안 및 이관
문제
Server Action 기반 API 계층에 세 문제가 겹쳐 있었습니다. 요청이 순차 처리되어 클라이언트에서 병렬로 묶어도 네트워크 워터폴을 피할 수 없었고, 빌드 시 생성된 액션 ID로 참조되어 배포 직후 구버전 클라이언트의 요청이 실패하는 Version Skew가 배포마다 발생했습니다. 일반 HTTP 요청이 아니어서 MSW 같은 서드파티 라이브러리와 호환이 떨어져 E2E와 스토리북이 각자 다른 방식으로 응답을 대신 만들고 있었습니다.
선택
기존 방식을 유지하면 변경은 가장 적지만, 워터폴이 Server Action의 요청 처리 방식 자체에서 오므로 사용법으로는 풀리지 않고 Version Skew와 모킹 문제도 남습니다. Route Handler로 바꾸면 세 문제는 풀리지만 zod와 TanStack Query 래퍼를 새로 만들어야 하고 타입 안정성에 별도 처리가 필요합니다. 그래서 기존 개발 구조와 다르지 않으면서 부가 기능을 갖춘 기술을 찾았습니다. tRPC는 기존 zod, TanStack Query를 그대로 쓰면서 HTTP 위에서 배치 병렬 요청과 캐싱을 지원하고 MSW도 그대로 동작해, 이를 교체 대상으로 제안했습니다.
실행
트레이드오프를 정리해 제안하고 팀 방향으로 채택 — 도메인 단위로 점진 이관하고, 완료 후 기존 인프라를 전량 제거
전환 후에야 가능해진 tRPC-MSW 모킹 환경을 구축해 E2E와 스토리북을 단일 핸들러 세트로 통합하고, 개발 서버에서도 모킹이 동작하게 구성
결과
순차로 처리되던 초기 요청이 배치로 병렬 처리되면서, 로그인 후 첫 화면의 전체 데이터 요청 시간이 49% 감소
배포 직후 요청이 실패하던 일이 사라졌고, 팀 전체 도메인 전환을 운영 중단 없이 완료. 신규 API는 핸들러 하나로 E2E와 스토리북이 함께 동작
