-
Notifications
You must be signed in to change notification settings - Fork 0
김다영‐ 2주차 경험
api 설계 , 기술 스택 정하기, 서버 상태 학습, react query 적용 2주차에는 api 설계 및 기술 적용을 위한 학습을 주로 했습니다.
- headless UI?
- 서버상태에 대한 이해
- 모킹 경험
- api 설계
- 2주차 개발 문서 리스트
혼자 프론트엔드이고, 개발 경험도 많지 않았기에 빠른 속도를 위해 tailwind와 headless ui 라이브러리를 도입하기로 결정했습니다.headless ui는 tailwind와의 호환성을 고려하여 Headless UI 와 shadcn 사이에서 고민했는데, 더 많은 컴포넌트를 제공하는 shadcn으로 최종 결정을 했습니다.
기존에 저는 서버상태, 로컬상태에 대한 이해가 전혀 없었기에 서버상태 관리 라이브러리와 전역상태 관리 라이브러리의 필요성과 차이점에 대해서 잘 몰랐습니다. 이에 프론트엔드 디자인 변천사를 쭉 정리했고 공부를 했습니다.
이렇게 공부를 하면서 왜 상태가 중요해졌는지 알게 되었고, 왜 로컬과 서버상태를 분리하게 되었는지도 이해하게 되었습니다.
이런 공부를 통해 서버상태를 직접 관리하는게 정말 힘든 일이라는 것을 알게 되었고, 이에 리액트 쿼리를 공부하고 도입하게 되었습니다.
API 의존성을 줄이고, API가 준비되기 전에 프론트엔드 개발도 진행할 수 있도록 모킹을 활용했습니다. 서버와 통신하기 위한 HTTP 클라이언트 라이브러리로는 axios를 선택했는데, 이에 axios-mock-adapter과 msw 사이에서 고민을 했습니다. 다만 저는 처음으로 모킹을 해봤기 때문에 다소 설정이 간단한 axios-mock-adapter를 선택했습니다.
| 기준 | axios-mock-adapter | MSW |
|---|---|---|
| 설정 난이도 | 간단 | 비교적 복잡 |
| 대상 | Axios 전용 | 모든 HTTP 클라이언트 (Axios 포함) |
| 네트워크 계층 모사 | 없음 (Axios 요청 내부에서 동작) | 있음 (실제 네트워크 계층처럼 동작) |
| 테스트 환경 | 로컬 테스트, 단위 테스트 | 브라우저 + Node.js, 통합 테스트 |
| 확장성 | Axios에 종속 | 범용적이고 확장 가능 |
| 실제 환경 시뮬레이션 | 불가능 | 가능 |
팀원들과 함께 API 설계를 진행하며, 어떤 방식으로 데이터를 주고받을지 논의하고 이를 노션에 정리하여 문서화하였고, 이를 보면서 프론트엔드 api 함수를 구현했습니다.
API 설계 단계에서는 모든 것을 명확히 정의했다고 생각했지만, 배포 이후 백엔드에서 제공한 API 형식이 문서와 다르게 전달되는 상황이 발생했습니다. 초기에는 API가 다르게 올 가능성을 전혀 고려하지 않았고, 이로 인해 문제가 어디에서 발생했는지 알지 못한 채 디버깅에 많은 시간을 소모했습니다. 특히 모킹(Mock) 단계에서는 문제가 없었기 때문에 더 혼란스러웠습니다.
이후 백엔드 개발자와 함께 살펴보니 문서와 다르게 구현되어 있었다는 것을 알게되었습니다. 이 경험을 통해 API 문서만 믿지 말고, 스웨거와 개발자 도구 네트워크 탭도 함께 봐야한다는 교훈을 얻을 수 있었습니다. 거기에 모킹이 거의 필수라는 것을 깨달았습니다.