백엔드 API의존성이 강한 프론트엔드

프로젝트를 진행하다 보면 다음과 같은 상황들이 발생합니다.

• 백엔드 API 개발 지연: 프론트엔드 기능 개발이 백엔드 API 개발 속도보다 빠를 때, API가 완성될 때까지 기다리지 않고 UI 개발을 계속하고 싶습니다.
• 다양한 응답 시나리오 테스트: 성공, 실패, 특정 에러 코드, 빈 데이터 등 다양한 API 응답에 따라 UI가 어떻게 반응하는지 쉽게 테스트하고 싶습니다.
• 부분적 실제 API 연동: 일부 API는 개발이 완료되어 실제 서버와 연동 테스트를 하고 싶지만, 다른 API들은 여전히 모킹이 필요한 상황입니다.
• 팀원 간의 모킹 설정 공유: 팀원마다 다른 모킹 설정을 사용하거나, 특정 상황에 맞는 모킹 설정을 쉽게 공유하고 싶습니다.

런타임에 MSW 핸들러 제어하기: Postman 의존성 탈출과 개발 생산성 수직 상승기

프론트엔드 개발 시 백엔드 API가 준비되지 않았거나, 특정 응답에 대한 UI 테스트가 필요할 때 API 모킹은 선택이 아닌 필수입니다.

현재 제가 속한 팀에서는 Postman을 통해 API를 관리하고 있습니다. Postman의 목 서버 기능은 유용하지만, 활성화하면 모든 API가 목을 바라보게 되어 실제 서버와 목 서버를 혼용할 수 없다는 치명적인 단점이 있었습니다. 또한 유료 플랜에 대한 부담과, API 스키마 변경 시 코드와 Postman 양쪽을 모두 수정해야 하는 번거로움은 계속해서 개발 생산성을 저해했습니다.

이런 이유에서 저는 MSW를 선택했습니다. **MSW(Mock Service Worker)**는 실제 네트워크 요청을 가로채 동작하기 때문에, 실제 API를 사용하는 것과 거의 동일한 개발 경험을 제공하는 훌륭한 라이브러리입니다.

<aside> 💡

📖 MSW (Mock Service Worker)란?

MSW는 **서비스 워커(Service Worker)**를 사용하여 네트워크 요청을 가로채는 API 모킹 라이브러리입니다. 서비스 워커는 웹 애플리케이션의 메인 스레드와 분리된 백그라운드 스레드에서 실행되며, 네트워크 프록시처럼 동작하여 나가는 요청을 감지하고 응답을 수정할 수 있는 기능을 제공합니다.

MSW의 주요 특징 및 장점:

• 네트워크 레벨 모킹: 실제 네트워크 요청을 가로채기 때문에, Workspace, axios 등 어떤 HTTP 클라이언트를 사용하든 동일하게 동작합니다. 애플리케이션 코드 변경이 거의 필요 없습니다.
• 실제 요청과 유사한 환경: 모킹된 API라도 실제 네트워크 요청처럼 개발자 도구의 네트워크 탭에 기록됩니다.
• 브라우저 및 Node.js 환경 지원: 브라우저 환경에서는 서비스 워커를, Node.js 환경에서는 다른 메커니즘을 사용하여 동일한 모킹 로직을 공유할 수 있습니다. (이 글에서는 브라우저 환경에 집중)
• 선언적 핸들러: 각 API 엔드포인트에 대한 모의 응답을 핸들러 함수로 깔끔하게 정의할 수 있습니다.

MSW를 사용하면 백엔드 의존성 없이 프론트엔드 개발을 진행하고, 다양한 시나리오를 손쉽게 테스트하며, 보다 안정적인 애플리케이션을 구축할 수 있습니다.

</aside>

하지만 MSW를 사용하면서도 풀리지 않는 몇 가지 숙제들이 있었습니다.

"아, 이 API는 실제 서버로 보내고, 저 API만 목(mock) 데이터를 받고 싶은데..."

"API 스키마가 바뀌어서 코드 타입은 고쳤는데, Postman에 가서 또 수정해야 하네..."

"에러 케이스 테스트하려고 핸들러 코드를 주석 처리하고 저장하는 일을 반복하는 게 너무 번거로워요."

이러한 문제들을 코드 레벨에서 모두 해결하고, 더 나은 개발 경험을 만들기 위해 msw-controller와 msw-controller-devtools를 개발하게 되었습니다.