MSW로 프론트엔드 개발 생산성 높이기! - Mocking을 해야하는 이유

전체 개발 프로세스 중 요구 사항 분석 및 기획, 백엔드 개발, 프론트엔드 개발에 이르는 각각의 개발 과정은 크게 겹치지 않고 진행되는 것이 가장 이상적입니다. 왜냐하면, 개발 과정에서 도출되는 요구 사항이나 사용 가능한 인터페이스에 변경이 있으면 각 단계별 의존성에 따라 다시 작업해야 하는 경우가 발생하기 때문입니다.

따라서, 개발 과정이 다음과 같이만 진행된다면 요구 사항과 제공된 스펙에 따라 순조롭게 프론트엔드 개발을 진행할 수 있습니다.

하지만 현실적으로 프론트엔드와 백엔드가 병행하여 개발하게 되는 경우가 많습니다.

이때 프론트엔드에서 백엔드의 API를 활용해야 하는 것처럼, 백엔드 개발에 종속적인 부분이 있다면, 해당 부분이 완성되기 전까지는 프론트엔드 개발을 진행할 수가 없고 그 부분이 진행된 후에나 개발이 가능합니다. 심지어 추가적인 수정사항이 발생했는데 백엔드 개발에 의존성이 있는 부분에 수정이 필요하다면 이러한 비효율적인 과정을 반복 진행할 수 밖에 없습니다.

예상한 기간보다 API 개발에 시간이 더 필요해진 경우, 그 시간만큼 프론트엔드 개발자가 개발을 진행하지 못하는 상황이 발생합니다.

프론트엔드 개발자들은 개발, 테스트, 디버깅, 요구사항 변경 등 업무를 진행하다 보면 개발 완성도를 높이는데 있어 항상 시간의 부족함을 느낍니다. 이에 더해, 프론트엔드 개발은 프로젝트 완성 단계의 엔드포인트에 가깝기 때문에 더더욱 시간의 압박을 많이 받을 수 밖에 없습니다. 기간은 정해져 있고 상황은 촉박한데 API에 종속적인 개발이 많을수록, 개발 가능한 시간과 테스트에 쏟을 수 있는 시간은 줄어듭니다.

이러한 상황을 피하기 위해서 Mocking을 사용합니다.

Mocking? 좋아보이네요! 정말 그렇게 좋은가요?

기존에는 화면에 필요한 데이터의 상태를 애플리케이션의 내부 로직에 직접 Mocking 해서 필요한 화면에 붙이는 방식을 사용했습니다. 이렇게 작업하는 방식은 구현이 쉬워 빠르게 적용할 수 있다는 장점이 있지만 애플리케이션의 서비스 로직에 직접 Mocking을 해야하기 때문에 애플리케이션 서비스 로직을 수정해야 하고, HTTP 메소드와 네트워크의 응답 상태에 따라 각각 대응하기가 쉽지 않습니다.

반대로, Mock 서버를 별도로 만드는 방법도 있습니다. 이 방법은 웹 애플리케이션의 서비스 로직을 수정하지 않아도 되지만, 데이터 상태 구현에는 직접 Mocking 대비 비용 및 공수가 상당히 들어갑니다. 추가적으로 이를 로컬이 아닌 누군가에게 공유해야 한다면, Mock 서버를 원격으로 제공하기 위한 추가 환경 구성 작업 등에도 적지 않은 공수가 들어 효율적이지 않습니다.

이외에도 각 화면에 대한 테스팅 및 디버깅 시에 어려움이 발생한다는 것입니다.

결과물을 확인하고자 하는 인원이 담당 프론트엔드 개발자가 아니라면, 예를 들어 에러 화면을 보려고 해도 크롬 개발자 도구가 요청을 블록 처리할 가능성이 높아 특정 상태의 화면을 다른 살마에게 공유하기가 어렵고, 실제 API 스펙처럼 발생하는 상황을 모의하기 쉽지 않습니다.

또한, 대기, 로딩, 에러 등 API의 응답 상태에 따른 여러 가지 구현을 가지고 있을 경우 각 단위 개발은 어떻게 진행한다고 하더라도 실제 화면을 구성하기 위한 구현 단계에서는 각 케이스별로 임의의 상태를 만들어 보면서 개발하거나 그 자체를 디버깅하기에 어려움이 있습니다.

결국 우리에게 필요한 것은 실제 API를 사용하는 것처럼 네트워크 수준에서 Mocking하는 것입니다. 따라서 네트워크 요청 과정에서 Request에 대한 Mocking이 가능한 MSW를 찾아냈습니다.

다음 게시글에서는 MSW에 대해서 알아보겠습니다.

reference(https://tech.kakao.com/2021/09/29/mocking-fe/)