HTTP를 통한 대용량 파일 캡처: ApiCatcher의 구현 방식

여러 iOS용 HTTPS 패킷 캡처 도구를 사용해 봤지만, 정적 리소스 파일 캡처를 지원하는 도구는 없었습니다. 요청이나 응답 본문이 특정 크기를 넘으면 그냥 버려지는 식이었죠. 파일 업로드 권한 문제를 해결하기 위해 요청의 전체 URL을 캡처해서 도메인과 프로젝트를 파악하려 해도 불가능했습니다.

ApiCatcher를 개발하면서 알게 된 사실인데, iOS는 네트워크 확장(Network Extension) 프로세스에 메모리 제한을 둡니다. 여러 자료에 따르면 시스템은 네트워크 확장 프로세스에 최대 약 50MB까지만 허용하며, 이를 초과하면 프로세스가 강제 종료됩니다. 다만 OS 버전에 따라 실제 임계값은 다를 수 있으며, 저희 테스트에서는 약 80MB까지도 정상 동작했습니다.

이러한 메모리 제약 때문에 대부분의 캡처 도구는 자체적인 패킷 폐기 전략을 구현하여 본문 크기가 일정 이상이면 요청을 버립니다.

ApiCatcher는 어떻게 이 문제를 해결했을까요?

핵심은 정적 리소스 파일의 경우 본문을 메모리에 버퍼링할 필요가 없다는 점입니다. 이러한 파일에 대해 본문 재작성이나 스크립트 수정이 필요한 경우는 거의 없기 때문에, ApiCatcher는 수신 버퍼에서 읽은 바이트를 곧바로 디스크에 스트리밍 방식으로 기록합니다. 메모리에는 보관하지 않습니다.

또 한 가지 중요한 점은, 대용량 HTTP 페이로드가 TCP 계층에서 작은 세그먼트로 분할된다는 사실입니다. 1MB 파일 전송도 약 64KB 크기의 TCP 세그먼트 여러 개로 나뉩니다. 각 세그먼트를 도착 즉시 디스크에 기록하면, 동시에 소비하는 메모리는 64KB에 불과하며 1MB 전체를 보관할 필요가 없습니다. 요청 또는 응답이 완료되면 데이터베이스 레코드에는 본문 대신 파일 경로만 저장합니다.

이 방식의 트레이드오프는 사용자가 요청 레코드를 삭제할 때 해당 본문 파일을 찾아 함께 삭제해야 하며, 데이터 정합성을 직접 관리해야 한다는 점입니다. 이것이 ApiCatcher의 데이터 삭제가 다소 느린 이유입니다. 하지만 삭제는 자주 사용하는 기능이 아니며, 1만 건 정도는 약 5초면 처리되므로 충분히 가치 있는 선택이라고 생각합니다.

대용량 파일 캡처 지원을 바탕으로, ApiCatcher는 이미지·비디오·오디오를 앱 내에서 직접 렌더링하고 원터치로 재생할 수 있습니다. 또한 전용 미리보기 및 일괄 내보내기 화면을 통해 테스트 자료를 손쉽게 추출할 수 있습니다.

iOS, Windows, macOS 세 플랫폼 모두에서 동일한 스트리밍 저장 방식을 적용했습니다. 데스크톱 환경에는 메모리 제한이 없지만, 이 설계는 모든 플랫폼에서 더 나은 성능을 제공합니다.

ApiCatcher for iOS 실행 화면:

ApiCatcher for macOS 실행 화면: