안녕하세요. 와디즈 앱개발팀 입니다.
와디즈 앱개발팀에서 개발 생산성을 높이기 위해 Mocking 방식을 도입했어요. 오늘은 이에 관해 설명하고자 합니다.
도입 배경
대부분 많은 개발이 요구사항, 기획 -> Backend 개발 -> App 개발로 진행됩니다.
따라서 요구사항이 계속 변경될 경우, 이는 Backend 개발과 App 개발 시간에 많은 영향을 주게 됩니다. 특히 App 개발은 Backend 개발 일정에 많은 영향을 받게 되는데요, Backend 개발 일정을 계속 기다리는 것은 빠른 의사결정을 하기에 어려움이 있습니다. 시간이 많이 들기 때문이죠.
“좀 더 유연한 방법으로 개발하는 방법이 없을까?”
고민 끝에 Backend API 개발시간 영향을 최소한으로 받을 수 있도록 Mocking System 도입을 생각했어요. Mocking System 도입은 많은 시간적 이득을 기대하게 했어요. 기존 방식에서 앱개발자는 Backend 개발자와 같이 협의한 API 스펙을 정의하고, Backend 개발자가 Mockup 데이터를 세팅하기까지 많이 기다려야 했거든요.
Mocking System 도입 시 Backend 개발과 APP 개발이 병렬로 진행됩니다.
Mocking System 도입하기
기획 단계
2022년 하반기 진행된 메인 개편에서 Mocking System을 도입했습니다. 기획 단계부터 빠른 prototype을 진행하여 어떻게 동작하는지 확인했어요. 구성원들과 함께 확인하며 구체적인 피드백을 받았는데요, 덕분에 빠르게 의사결정을 할 수 있었습니다.
개발 단계
Backend 개발자도 Mockup 데이터 세팅을 위해 따로 시간을 쓰지 않아도 되었습니다. 앱개발자들도 정의된 API Spec에 따라 Mockup과 API Spec을 정의하여 다양한 케이스를 테스트할 수 있었어요. 강제로 Error 정의도 가능해졌습니다. 덕분에 Backend 개발자에게 따로 Error를 요청하지 않아도 대응할 수 있었지요. Mocking System 도입으로 Backend와 App 개발이 병렬로 가능해졌습니다.
어떤 Mocking System을 사용했는가
앱개발팀에선 Mocking System으로 OHHTTPStubs (iOS) 를 사용했어요.
OHHTTPStubs
OHHTTPStubs는 네트워크 요청에 대한 stub을 쉽게 작성하기 위해 만들어진 라이브러리입니다.
- 특정 요청에 대한 응답을 가짜 네트워크 데이터(json 파일, swift의 Data 타입 등)로 지정해 받을 수 있어요.
- 다양한 네트워크 상태에 대한 테스트를 할 수 있어요.
- API 종속성 없이 네트워크 요청 및 응답 처리 로직을 사전 개발할 수 있습니다.
- NSURLSession 혹은 그것을 wrapping 하는 라이브러리와 compatible 합니다.
- OHHTTPStubs 라이브러리가 메모리에 로드될 때 HTTPStubs라는 싱글톤 객체가 자동으로 메모리에 로드됩니다.
- URLSession을 통해 API를 호출하면 HTTPStubs가 request 메서드를 swizzling 하여 가로챕니다.
- 가로챈 URLRequest 데이터와 등록된 stub을 매칭하여 URLSession에 미리 정의해놓은 response를 전달합니다.
구현 예시
다음과 같이 stub 함수를 호출하면 HTTPStubs라는 싱글톤 객체의 인스턴스에 해당 stub이 등록됩니다. 이후 일반적인 네트워크 요청과 마찬가지로 URLSession을 통해 요청을 보내면 등록된 stub의 condition block에서 해당 요청이 stub으로 치환될 요청인지 판단합니다. 맞을 경우, 이를 HTTPStubs가 가로채어 미리 작성해 놓은 응답을 내려주게 되지요. 이때 응답에 대해 요청의 성공 및 실패 여부, 지연 시간을 지정할 수 있어요. 3G, 와이파이 등 다양한 네트워크 환경도 지정할 수 있고요.
위 코드와 같이 condition에 들어갈 block을 직접 구현해도 됩니다. OHHTTPStubs에서 제공하는 matcher function들을 조합하여 condition을 정의해도 되고요.
아래와 같이 stub 함수를 호출하면 Request에 대한 Response를 수정할 수 있어요.
위와 같이 구현한다면 API 호출에서 따로 수정 없이 개발이 가능합니다. 덕분에 결괏값을 앱개발자가 바꿔가며 테스트할 수 있었어요. 즉, 독립적인 개발을 할 수 있었습니다.
지금까지 mocking system을 도입하는 과정과 예시를 정리해보았는데요,
이 시스템을 통해 얻을 수 있는 효용에 대해 정리하며 글을 마칩니다.
- 새로운 기능이 어떻게 구현될지, 빠른 prototype을 통해 기획 단계에서 미리 확인할 수 있어요. 덕분에 구체적인 피드백을 통한 의사결정이 가능합니다.
- 개발 과정에서 Backend와 App의 병렬 협업을 촉진하여 서로 독립적으로 작업할 수 있어요. 결과적으로 생산성이 향상됩니다.
- 강제로 Error를 정의하여 예상되는 오류에 미리 대응 할 수 있습니다.
감사합니다😊
궁금한 내용이 남아 있나요? 👀
앱개발팀의 조직 문화가 궁금하다면? 👉 클릭
앱개발팀에 와디즈 칭찬 릴레이 주인공이? 👉 클릭
