API_Mocking_library[Mock Service Worker]
reference
kakao Tech Blog:Mocking으로 생산성까지 챙기는 FE 웹개발
프론트엔드 개발 과정의 현실
전체 개발 프로세스 중 요구 사항 분석 및 기획, 백엔드 개발, 프론트엔드 개발에 이르는 각각의 개발 과정은 크게 겹치지 않고 진행되는 것이 가장 이상적일 것 입니다. 왜냐하면, 개발 과정에서 도출되는 요구 사항이나 사용 가능한 인터페이스에 변경이 있으면, 각 단계별 의존성에 따라 다시 작업해야 하는 경우가 발생하기 때문입니다.
따라서, 개발과정이 다음과 같이만 진행된다면 요구 사항과 제공된 스펙에 따라 순조롭게 프론트엔드 개발을 진행할 수 있습니다.
하지만 현실은, 많은 시간을 프론트엔드와 백엔드를 병행하여 개발하게 되는 경우가 많습니다.
이때 프론트엔드에서 백엔드의 API를 활용해야 하는 것처럼, 백엔드 개발에 종속적인 부분이 있다면, 해당 부분이 완성되기 전까지는 프론트엔드에서 개발을 진행할 수 없고, 그 부분이 진행된 후에나 개발이 가능합니다. 심지어 추가적인 수정사항이 발생했는데 백엔드 개발에 의존성이 있는 부분에 수정이 필요하다면, 이러한 비효율적인 과정을 반복 진행할 수밖에 없습니다.
만약, 이러한 부분을 해결해줄 수 있는 대안이 없다면 심할 경우 아래와 같은 상황이 펼쳐질 수 있다고 개인적으로 생각됩니다.
기획자: ~작업은 어떻게 진행 중이신가요?
프론트엔드 개발자: 그게... 아직 API가 준비되지 않아서 다음주 까지 기달려야 합니다.
프론트엔드 개발자: 백엔드 때문에 프론트 개발 진행이 안되네요... 🤬 (업무와 밀접한 관련이 있고 일정 압박등으로 인해 스트레스가 심한 경우 욕설이 나올 것 같다고 예상됨)
백엔드 개발자: 그럼 당신이 백엔드 개발을 하시던가요! 🤬 (백엔드 개발자도 개발자만의 사정이 있기 때문에 협업이 어려워 질 것 이라 예상됨)
제가 실제 협업에서 일해보지는 않았지만, 협업을 할 때 위와 관련된 상황에 대해 생각해보지 않았다면 협업하면서 일하는 것이 어려울 것 같다고 생각됩니다. 또한, 다툼이 있었다면 백엔드 부서와의 관계도 좋지 않게 될 것 같고요. mocking을 활용해서 개발을 진행하지 않으면 시간이 계속 지체될 것 같다고 생각됩니다.
mock(mocking)
kakao Tech Blog 글에 의하면 기존에도 mocking을 통해 사전 개발을 진행했었고 그 것에 대한 장단점은 아래와 같다고 합니다.
- 화면에 필요한 데이터의 상태를 애플리케이션의 내부 로직에 직접 Mocking 해서 필요한 화면에 붙이는 방식
- 장점: 구현이 쉬워 빠르게 적용할 수 있다
- 단점: 애플리케이션의 서비스 로직에 직접 Mocking을 해야 해 애플리케이션 서비스 로직을 수정해야 하고, HTTP 메소드와 네트워크의 응답 상태에 따라 각각 대응하기가 쉽지 않다.
- Mock 서버를 별도로 만드는 방법
- 장점: 웹 애플리케이션의 서비스 로직을 수정하지 않아도 된다.
- 단점: 데이터 상태 구현에는 직접 Mocking 대비 비용 및 공수가 상당히 들어가며, 이를 로컬이 아닌 누군가에게 공유해야 한다면, Mock 서버를 원격으로 제공하기 위한 추가 환경 구성 작업 등에도 적지 않은 공수가 들어 효율적이지 않다.
- 기존 Mocking의 또 다른 문제점
- 각 화면에 대한 테스팅 및 디버깅 시에 어려움이 발생한다.
- 결과물을 확인하고자 하는 인원이 담당 프론트엔드 개발자가 아니라면, 예를 들어 에러 화면을 보려고 해도 크롬 개발자 도구가 요청을 블록 처리할 가능성이 높아 특정 상태의 화면을 다른 사람들에게 공유하기가 어렵고, 실제 API 스펙처럼 발생하는 상황을 모의하기가 쉽지 않다.
- 대기, 로딩, 에러 등 API의 응답 상태에 따른 여러 가지 구현을 가지고 있을 경우, 각 단위 개발은 어떻게 진행한다고 하더라도 실제 화면을 구성하기 위한 구현 단계에서는 각 케이스별로 임의의 상태를 만들어 보면서 개발하거나 그 자체를 디버깅하기에 어려움이 있다.
위를 종합하면, 협업하면서 원활히 개발을 진행하기 위해 필요한 Mocking의 수준은 실제 API를 사용하는 것처럼 네트워크 수준에서 Mocking하는 것입니다. 이와 같은 고민을 가지고 찾아보던 중 MSW(Mock Service Worker, 네트워크 요청 과정에서 Request에 대한 Mocking이 가능)를 알게 되었고 추가적으로 카카오 기술 블로그 글도 접하게 되었습니다.
MSW?
- MSW는 Mock Service Worker의 약자
- 서버의 네트워크 요청을 가로채서 모의 응답(Mocked Response)을 보내주는 역할을 하는 API Mocking 라이브러리
- Mock 서버를 구축하지 않아도 API를 네트워크 수준에서 Mocking 할 수 있음
- Service Worker를 통해 HTTP 요청을 가로채기 때문에 API Mocking이 가능함
service worker
Service Worker는 웹 애플리케이션의 메인 스레드와 분리된 별도의 백그라운드 스레드에서 실행시킬 수 있는 기술 중 하나이며, Service Worker 덕분에 애플리케이션의 UI Block 없이 연산을 처리할 수 있습니다.
이러한 특징으로 인해, Service Worker는 다음과 같은 기능에 많이 사용되고 있습니다.
- 네트워크가 원활할 때 동기화를 시켜주는 백그라운드 동기화 기능이나, 높은 비용의 계산을 처리할 때 또는 푸시 이벤트를 생성할 때 주로 사용됨
- MSW의 동작 방식과 관계되어 있는, 네트워크 요청을 가로채는 행위도 수행할 수 있음
- Service Worker가 애플리케이션과 서버 사이에서 Request를 가로채서 직접 Fetch에 대한 컨트롤도 할 수 있기 때문에 색다른 작업이 가능해짐
- 예를 들어, HTTP Request와 Response를 보고 캐싱 처리를 한다든지, 필요하다면 로깅을 한다든지 하는 여러 가지 새로운 동작을 만들어 낼 수 있음
- MSW도 이 과정을 통해서 Request를 가로채서 Response를 Mocking 하는 원리를 사용함
Service Worker의 사용이 제한되는 경우도 있습니다.
- Service Worker는 대부분의 모던 브라우저에서 지원하고 있으나, IE와 같은 일부 브라우저에서는 지원하고 있지 않음
- 기본적으로 localhost가 아닌 환경이라면 HTTPS 보안 프로토콜 환경이 필요함
- Service Worker는 중간에서 네트워크로 연결을 가로채고 조작할 수 있는 강력한 기능을 갖고 있기 때문에, Service Worker에서는 HTTPS가 기본적으로 제공되는 환경에서만 사용할 수 있음
즉, MSW는 Service Worker를 기반으로 모의 API를 만들어내기 때문에 다른 프론트엔드에서 사용하는 수많은 라이브러리나 프레임워크에 종속적이지 않고 호환성에 문제없이 동작합니다.
동작 원리
- 브라우저에 service worker 설치
- 설치 이후부터는 브라우저에서 실제 이루어지는 요청을 service worker가 가로챔
- service worker에서는 해당하는 실제 요청을 복사해서 MSW에게 해당 요청과 일치하는 모의 응답을 제공받고, 이를 브라우저에 그대로 전달
이러한 과정을 통해서, 실제 서버 존재 여부와 상관없이 실제 요청으로 이어지지 않고 예상할 수 있는 요청에 대해 Mocking이 가능해집니다. 이렇게 Mocking이 가능해지면 API가 아직 준비되지 않았어도 다음과 같은 개발 방식을 선택할 수 있습니다.
MSW를 활용한 개발 방식
- 기획자가 요구 사항을 전달
- 프론트엔드 개발자와 백엔드 개발자가 API 스펙을 합의하고, 백엔드 개발자는 프론트엔드 개발자에게 API의 스펙을 제공
- 프론트엔드 개발자는 MSW를 통해 네트워크 레벨에서의 Mocking을 진행한 후, 애플리케이션을 개발
API 없이도 프론트엔드 개발자는 높은 완성도를 갖고 있는 수준에서 기획자와 미리 프론트엔드 애플리케이션을 확인하며 피드백을 주고받고, 그 사이 백엔드 개발자는 API 개발을 진행합니다. 이후 백엔드 개발자가 API를 제공하면, 프론트엔드 개발자는 별다른 작업 없이 MSW를 스위치 오프(NODE_ENV 설정)만 하면 Production으로 배포할 수 있는 형태의 개발 과정을 통해 개발을 진행할 수 있습니다.
MSW는 디버깅이 필요한 상황에서도 좋은 시너지를 만들어 낼 수 있습니다.
예를 들어, 특정 API 응답을 기준으로 에러가 발생해 디버깅이 필요한 상황이라면, 기존 서비스 로직을 전혀 건드리지 않고 오로지 MSW에서 Mocking을 만들어 내서 쉽게 디버깅할 수 있습니다.
더 나아가, 이러한 장점은 기획자 등의 다른 누군가에게 각 화면을 공유하고 피드백을 받아야 하는 상황이 발생했을 때에도, 추가적으로 MSW에서 해당 상황을 만들어낼 수 있도록 작업을 해 둔다면 별다른 서비스 로직의 수정 없이도 MSW를 통해 제공이 가능해집니다.
프론트엔드 개발 시 MSW 활용을 통해 얻을 수 있는 장점
- 낮은 진입장벽으로 빠른 적용이 가능
- 별도의 환경 없이 네트워크 요청에 대한 모의 가능
- API에 종속성 없이 완성도 높은 수준의 사전 개발 가능
- 네트워크 상태에 따른 디버깅을 위해 활용 가능
