43MB 앱을 0.05MB 웹페이지로 바꾼 개발자의 실험

43MB 앱을 0.05MB 웹페이지로 바꾼 개발자의 실험

IT & AI 뉴스 썸네일

여행 일정과 PDF를 확인하려고 43MB짜리 앱을 설치해야 했던 개발자가 같은 정보를 웹페이지로 다시 만들었어요. 콘텐츠를 받은 앱은 124MB까지 커졌지만, 새 HTML 페이지 자체는 0.05MB에 그쳤어요. 앱 설치가 정말 필요한지 제품 기획 단계에서 다시 묻게 하는 사례예요. 1

핵심 요약

구분	핵심	왜 볼 만한가요
앱 구조	Travelbound는 서버에서 받은 텍스트, 이미지, PDF 링크를 화면에 표시했어요	네이티브 앱이 필요한 기능과 웹으로 충분한 기능을 구분할 수 있어요
분석 방법	루팅한 Android 가상 기기와 HTTP Toolkit으로 네트워크 요청을 확인했어요	앱의 데이터 흐름을 조사하는 현실적인 과정을 볼 수 있어요
웹 변환	Ruby 스크립트가 JSON을 받아 정적 HTML을 주기적으로 만들어요	작은 자동화만으로 문서형 앱을 웹으로 옮긴 사례예요
사용자 경험	웹에서는 복사, 인쇄, 저장, 검색, 북마크를 바로 쓸 수 있어요	브라우저의 기본 기능이 별도 앱 기능보다 유용할 수 있어요

1. 문서형 앱을 웹페이지로 다시 만들었어요

개발자 Dan Q는 자녀의 공연예술학교 여행 정보를 보려고 Travelbound 앱을 설치했어요. 앱이 제공하는 핵심 정보는 일정, 숙박 안내, 이미지, PDF였어요. 대부분 서버에서 내려받은 문서형 콘텐츠였고, 기기 센서나 오프라인 연산처럼 네이티브 앱이 꼭 필요한 기능은 보이지 않았어요. 반면 Google 계정과 연결된 추적 데이터를 전송하고 다른 여행 상품을 광고하는 기능은 들어 있었어요. 2

그는 Android Studio에서 가상 기기를 만들고 rootAVD와 Magisk를 사용해 루트 권한을 확보했어요. 인증서 고정이 적용된 통신을 살펴보기 위해 HTTP Toolkit도 연결했어요. 이 과정에서 앱이 여행 그룹의 공유 사용자 이름과 비밀번호를 조합한 URL로 API를 호출한다는 점을 확인했어요. 응답 JSON에는 일정과 파일, 광고 데이터, 화면에 쓸 HTML 조각이 함께 들어 있었어요. 2

JSON에서 필요한 정보만 골랐어요

대체 페이지는 Ruby 스크립트로 만들었어요. 스크립트가 최신 JSON을 받아 일정과 PDF 링크를 HTML로 변환하고, `inspirations`라는 이름의 광고 데이터는 결과 페이지에 넣지 않았어요. 이미지 주소의 유효 기간이 짧아서 Cron으로 JSON을 주기적으로 갱신했어요. 페이지는 기존 여행 그룹과 같은 비밀번호로 보호했어요.

728x90

크기 차이는 분명했어요. 원본 앱은 처음 설치할 때 43MB였고 콘텐츠를 받은 뒤 124MB까지 늘었어요. 새 웹페이지의 HTML은 0.05MB였어요. 이미지를 모두 선택해 내려받아도 추가 용량은 35MB였어요. 사용자는 앱과 웹 중 원하는 방식을 고를 수 있었어요. 2

브라우저가 이미 제공하는 기능이 많아요

웹 버전에서는 텍스트를 복사하고 페이지를 인쇄하거나 저장할 수 있어요. 검색과 북마크도 별도 개발 없이 쓸 수 있어요. Android 앱 설치가 어려운 기기에서도 주소만 열면 돼요. 접근성은 별도 감사를 거치지 않았지만, 표준 HTML을 쓰면 브라우저와 보조 기술이 제공하는 기능을 활용하기 쉬워요.

이 사례가 모든 앱을 웹으로 바꿔야 한다는 뜻은 아니에요. 카메라, 블루투스, 백그라운드 처리, 강한 오프라인 지원처럼 기기 기능을 깊게 쓰는 서비스에는 네이티브 앱이 알맞아요. 하지만 서버의 문서를 읽어 보여주는 제품이라면 앱스토어 배포와 설치 용량을 먼저 떠안을 이유가 적어요.

왜 중요한가요

제품을 시작할 때 화면 목록보다 전달할 정보와 필요한 기기 기능을 먼저 나눠보면 좋아요. 텍스트, 이미지, 파일 링크가 중심이라면 반응형 웹만으로 요구사항을 충족할 수 있어요. 홈 화면 아이콘이나 독립 실행 화면이 필요하면 PWA도 검토할 수 있어요. 앱스토어 심사와 버전 배포를 거치지 않고 서버의 콘텐츠를 바로 고칠 수 있다는 점도 운영 부담을 줄여줘요.

보안에서는 다른 교훈도 보여요. 원문 사례의 API는 여행 그룹이 공유하는 자격 증명을 URL 경로에 결합했어요. URL은 서버 로그, 프록시, 분석 도구, 브라우저 기록에 남을 수 있어 민감한 값을 담기 어려워요. 제품을 웹으로 만들든 앱으로 만들든 짧게 만료되는 토큰과 적절한 권한 분리가 필요해요.

개발팀은 네이티브 기능 목록, 오프라인 요구, 푸시 알림 필요성, 접근성, 설치 부담을 표로 비교해 볼 수 있어요. 네이티브 전용 요구가 거의 없다면 웹을 먼저 만든 뒤 실제 사용 과정에서 필요한 기능만 추가하는 편이 비용과 복잡도를 줄여줘요. Travelbound를 바꾼 실험은 브라우저가 가진 기본 기능을 제품 기능으로 제대로 계산해야 한다는 점을 구체적인 숫자로 보여줘요. 1

참고 자료

1. Android 앱을 웹페이지로 바꿔본 과정 — GeekNews
2. Your ‘App’ Could Have Been a Webpage — Dan Q